Ultibo port of Asphyre / Platform eXtended Library now on GitHub

Releases, updates and announcements from the Ultibo team.
captbill
Posts: 70
Joined: Tue Aug 16, 2016 5:47 am

Re: Ultibo port of Asphyre / Platform eXtended Library now on GitHub

Postby captbill » Sun Nov 27, 2016 8:28 am

Sorry for the delay, I wanted to have a look at this first before commenting.


Please don't waste too much time!! It's a total mess yet. I thought it was a bit further along. I rushed it out so more capable eyes can look over my shoulder. I have a "real" commit coming shortly.

I think this is the right approach and it fits with other units in PXL like the PXL.Boards.Soft unit (which implements software or bit banged SPI and UART etc) so adding a PXL.Boards.Mpsse to represent the FTDI devices as a GPIO seems correct.

I don't know if you'll need the TFTDISystemCore class in this case, it might make more sense to accept an instance of TCustomSystemCore if you need the timing routines it provides. That way those functions could come from any platform that has the required implementation.


Here has been my struggle: getting the correct class model determined. Looks like there needs to be a TFTDIvirtualClass --> TMPSSEvirtualClass ---> TMPSSE_SPI, TMPSSE_i2c, TMPSSE_etc... type of model. TFTDI does the basic initialization of the chip and establishes timing configuration settings. TMPSSE has a secondary initialization stage. This starts the mpsse engine itself vs the default operation (basic init of the FTDI chip). I want to have this modeled correctly to accommodate all the features of the chip in the future AND get a nice melding with the PXL library.

My idea to build directly into the PXL library (inside out) vs a TFTDIbase from scratch got me tied in knots.

As far as I understand the FTDI devices can actually represent lots of device types (GPIO, SPI, I2C etc) using this protocol so there is room for expansion once you get the concepts sorted out and working.


This is where I realized the model isn't feeling right for FTDI. It needs to branch earlier, from TCustomSystemCore forward with it's own TFTDIbase and TMPSSEbase virtual classes it appears. Also, I started the project in the Ultibo IDE which was a no no and only confused the issue with learning PXL. This uses the D2xx.dll so is strictly a normal Lazarus PXL library application. This little detail escaped me at first.

I have a lot of these issues sorted and am getting a good idea, I hope, of a solid strategy with the model.

Best Regards,
Bill
captbill
Posts: 70
Joined: Tue Aug 16, 2016 5:47 am

Re: Ultibo port of Asphyre / Platform eXtended Library now on GitHub

Postby captbill » Sun Nov 27, 2016 7:37 pm

Here has been my struggle: getting the correct class model determined. Looks like there needs to be a TFTDIvirtualClass --> TMPSSEvirtualClass ---> TMPSSE_SPI, TMPSSE_i2c, TMPSSE_etc... type of model. TFTDI does the basic initialization of the chip and establishes timing configuration settings. TMPSSE has a secondary initialization stage. This starts the mpsse engine itself vs the default operation (basic init of the FTDI chip). I want to have this modeled correctly to accommodate all the features of the chip in the future AND get a nice melding with the PXL library.


Ok. Scratch that idea. There, instead, needs to be a TCustomD2xx and TCustomMpsse abstract classes in the PXL.Boards.Types unit something like this:

Code: Select all

  TCustomD2xx = class abstract
  protected
  public
  //standard init sequence for a basic D2xx setup
  //Use for the FT232h bit bang mode, for example
  //use for non-mpsse applications such as for older/simpler FTDI chips
  end;

  TCustomMpsse = class abstract (TCustomGPIO)
  protected
  public
  //custom init sequence for mpsse specific use
  //Use for the ft2232h and ft4232h or any mpsse capable chips
  end;


This is how PXL is intended to be used, I'm learning, just like the PXL.Boards.Soft unit outlines beatifully. The TCustomD2xx abstract class will handle the initialization for non-mpsse uses, such as the older/legacy chips, or for using the "classic functions" UART via the D2xx unit. TCustomMpsse abstract class will provide basic initialization for the newer chips with mpsse like ft2232h and ft4232h.

Then I can make the TMpsseSPI(TCustomPortSPI), TMpsseI2C(TCustomPortI2c), and TMpsseUART(TCustomPortUART) etc.

By this evening I should have a more legible repo happening at GitHub. I also will make a new thread, specific for this project.
haiqu
Posts: 252
Joined: Mon Oct 31, 2016 5:09 am
Location: Brisbane

Re: Ultibo port of Asphyre / Platform eXtended Library now on GitHub

Postby haiqu » Sun Nov 27, 2016 7:54 pm

Nice work. This was one of the forward projects I had considered as well. Glad you took it on, I'm swamped.
Make mine a Pi with source.
Gavinmc42
Posts: 1420
Joined: Sun Jun 05, 2016 12:38 pm
Location: Brisbane, Australia

Re: Ultibo port of Asphyre / Platform eXtended Library now on GitHub

Postby Gavinmc42 » Wed Dec 14, 2016 8:03 am

Probably just because the bouncing boxes is setup for 8 bit color depth and QEMU doesn't support that, not sure if the real PL110 LCD controller does or not.


Changed a couple of lines to get coloured bouncing boxes in QEMU ;)

Code: Select all

 FillRect(X,Y,Width,Height,(Element) + 1);   
 
 FramebufferProperties.Depth:=16;           


Not great colours and still rectangles on left half the screen.
Buffer.Depth must be 16, using 8,24,32 give greyscale.

Framebuffer probably expecting colour in RGB 565 format?
User avatar
Ultibo
Site Admin
Posts: 2079
Joined: Sat Dec 19, 2015 3:49 am
Location: Australia

Re: Ultibo port of Asphyre / Platform eXtended Library now on GitHub

Postby Ultibo » Wed Dec 14, 2016 8:52 am

Gavinmc42 wrote:Framebuffer probably expecting colour in RGB 565 format?

That would be correct, in 16bit mode it will expect the colours to be RGB 565 format.

The bouncing boxes would need a couple of other modifications to make it work correctly in 16bit mode, FillRect() and ClearScreen() would need to use FillWord instead of FillChar and the calculation of PixelOffset would need to take account of the change to two bytes per pixel.

There might be a couple more changes as well but it could be a good exercise to experiment with.
Ultibo.org | Make something amazing
https://ultibo.org
Gavinmc42
Posts: 1420
Joined: Sun Jun 05, 2016 12:38 pm
Location: Brisbane, Australia

Re: Ultibo port of Asphyre / Platform eXtended Library now on GitHub

Postby Gavinmc42 » Thu Dec 15, 2016 1:01 am

Thanks Garry, that should be enough clues to figure it out.
I have not confirmed timing but it does look like it is doing 60fps?

It is interesting that the higher level code I used in the Mandelbrot code had no problem with colour and screen size.
Guess that points out the main reason why high level code programming is used ;)
You have to be more careful at framebuffer coding and know exactly what you are doing ie RTFM.
Gavinmc42
Posts: 1420
Joined: Sun Jun 05, 2016 12:38 pm
Location: Brisbane, Australia

Re: Ultibo port of Asphyre / Platform eXtended Library now on GitHub

Postby Gavinmc42 » Thu Dec 15, 2016 5:31 am

Swapped FillChar to Fillword and I get square blocks ;) Colours seem better too?
Still only half screen and has horrible flicker, but that is probably PC related.
FRAMEBUFFER_FLAG_SYNC?

No idea on the timing results. sometimes it displays rubbish other times nothing.

This should be all in another post but hey that's what search is for.
Maybe QEMU bugs?
But it is not really Ulitbo bug? are we going to write Pi code that is emulated on a PC?
I guess the better QEMU works, the faster Ultibo aps can be made?

Would be interesting to compare QEMU speeds to actual Pi hardware, but it seems fast enough now.
Any Pascal benchmarks?
Attachments
blocks.jpg
blocks.jpg (90.52 KiB) Viewed 1325 times
develone
Posts: 274
Joined: Wed Dec 28, 2016 7:40 pm
Location: El Paso Tx USA

Re: Ultibo port of Asphyre / Platform eXtended Library now on GitHub

Postby develone » Mon May 15, 2017 2:28 pm

Hello All,

Was looking for benchmarks for the RPI and came across this post.

http://www.geeks3d.com/20160322/tested-raspberry-pi-3-vs-raspberry-pi-2-cpu-and-gpu-benchmarks-burn-in-test/


I believe others have stated that we need a heat sink, if you are running the RPi fairly hard.

I think this shows that the temps on the RPi are quite hi.
Is there any of these benchmarks in Ultibo?
Cheers,
pik33
Posts: 788
Joined: Fri Sep 30, 2016 6:30 pm
Location: Poland
Contact:

Re: Ultibo port of Asphyre / Platform eXtended Library now on GitHub

Postby pik33 » Mon May 15, 2017 6:05 pm

Get a retromachine player, run it @ Pi3 without a heatsink. There is a temperature displayed on the status bar and you will see it going fast to 80C, and this player is still far from loading the CPU at 100%

100% CPU load in RPi3 without a heatsink will throttle it to 600 MHz while still being near 80C.

New Ultibo has better power managment so the temperatures are not high in normal cpu load.

This case is my friend :) https://kamami.pl/obudowy-do-raspberry- ... ieska.html keeping even the overclocked Pi3 far from 80C
User avatar
Ultibo
Site Admin
Posts: 2079
Joined: Sat Dec 19, 2015 3:49 am
Location: Australia

Re: Ultibo port of Asphyre / Platform eXtended Library now on GitHub

Postby Ultibo » Mon May 15, 2017 11:47 pm

develone wrote:Is there any of these benchmarks in Ultibo?

There aren't really any benchmarks in Ultibo because being bare metal means you can do whatever you want with the hardware and that will ultimately determine things like temperature and utilization.

As of the latest Ultibo release the average temperature has been greatly reduced but individual results will vary greatly, remember also that the GPU is in the same SoC package and so any work it performs will add to the heat generated overall.
Ultibo.org | Make something amazing
https://ultibo.org

Return to “Ultibo”

Who is online

Users browsing this forum: No registered users and 1 guest