BRT Community

Please login or register.

Login with username, password and session length
Advanced search  

News:

Welcome to the Bridgetek Community!

Please read our Welcome Note

Technical Support enquires
please contact the team
@ Bridgetek Support

Please refer to our website for detailed information on all our products - Bridgetek - Bridging Technology

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - darkjezter

Pages: 1 2 [3]
31
Discussion - EVE / Re: unified blob in BT815
« on: August 13, 2019, 08:51:39 PM »
For what it's worth...

I'm in the same situation here, and loosely following the advice here I was able to include the unified blob into my MCU firmware and then write it to the flash through the EVE.

After writing the blob to the first 4K of flash while in basic mode, I was able to successfully switch to full mode.

Not how I'd handle manufacturing, but enough to validate that the prototype is working.  A separate method for loading larger datasets to flash will need to come, and instead of using CANbus (which is also an option at my disposal) I'll probably have to do it through the MCU using the programming header for data transfer.

32
Discussion - EVE / EVE3 - Asynchronous display-list updates
« on: August 12, 2019, 08:57:47 PM »
Hello all!

I'm in the process of evaluating and integrating the EVE3 into a commercial handheld remote for robotics and came up with some neat tricks for doing partial screen updates.  I'm here to share what I've come up with, and am curious to find out if anyone is doing anything similar.

In a nutshell, I'm using RAM_G to store blocks of DL commands, which are assembled into a display list using CMD_APPEND.  Nothing too fancy so far, however, wanting to still be able to take advantage of the coprocessor's widgets, these display list blocks are assembled in RAM_DL, and then transferred to RAM_G using CMD_MEMCPY.  This allows display lists in RAM_G to be updated, and by using segmented blocks which are assembled for display, can tolerate blocks changing in size without too much difficulty.

The CMD_APPENDs to assemble the final display list are built in RAM_G during the block construction described above.  Combined, these work out quite well as the coprocessor can feed it's own FIFO from RAM_G with some care.

Now the black magic that makes this method asynchronous.  There is no way to know ahead of time to know exactly how many commands will appear in each display list block, so ultimately, the block must be built and then the size retrieved from RAM_CMD_DL, and this has to happen before we can build the CMD_MEMCPY to move the DL block to RAM_G.  However, the coprocessor can also modify commands in it's FIFO, and this is essentially the trick:
  • Tell coprocessor what to display in the DL block
  • Tell coprocessor to copy the resulting block length, modifying the next instruction
  • Tell coprocessor to copy that many bytes to a set destination in RAM_G

By having the coprocessor modify the contents of its own FIFO, this can all be set up in advance with the host MCU only busy while setting up the request.  Even if the coprocessor has to wait for a page-flip before it can build a new DL block, the only constraint in this case is available room in the FIFO.

I'd love to hear any thoughts, and am more than willing to share more specific detail to anyone interested.

Cheers!

Jesse

Pages: 1 2 [3]