While this should work I would also like to point you to CELL.
Either as command for VERTEX2F or as parameter for VERTEX2II.

With this you can combine icons of the same size into one binary.
For a project I combined 9 54x20 images into one image and converted it to L8 format.

#define MEM_BUTTONS 0x00005500 /* buttons, 54x180 L8, 9 cells , 9720 / 0x25f8 */
#define HANDLE_BUTTONS 5

/* somwhere in init() */
EVE_cmd_inflate(MEM_BUTTONS, buttons, sizeof(buttons));

/* part of the static display-list that is injected with cmd_append */
EVE_cmd_dl(BITMAP_HANDLE(HANDLE_BUTTONS));
EVE_cmd_dl(BITMAP_SOURCE(MEM_BUTTONS));
EVE_cmd_dl(BITMAP_SIZE(EVE_NEAREST, EVE_BORDER, EVE_BORDER, 54, 20));
EVE_cmd_dl(BITMAP_LAYOUT(EVE_L8, 54, 20));

/* part of the dynamically generated display-list */
EVE_cmd_dl(DL_BEGIN | EVE_BITMAPS);
EVE_cmd_dl(BITMAP_HANDLE(HANDLE_BUTTONS));
EVE_cmd_dl(TAG(10));
EVE_cmd_dl(CELL(1));
EVE_cmd_dl(VERTEX2F(46, 110));
EVE_cmd_dl(TAG(11));
EVE_cmd_dl(CELL(2));
EVE_cmd_dl(VERTEX2F(46, 175));

This has two advantages, first is it uses less of RAM_G for odd-resolution images, that is anything not divisible by 8.
And then the packed binary is smaller so it uses less space in your controller and is transferred faster over SPI.

Well, and yes of course you can easily change the icon on the fly, even use this for animations.

I un-installed the older EAB and also removed the directory for it to make the installation of 1.6.0 as clean as possible.
First observation, EAB installs to C:\Users\Public\Documents\EVE Asset Builder now.

Flash Programmer:
The "Detect" button works now from the GUI, including "Measure Writing Speed".
After detect is finished it immediately switches over to "PROGRAM" though so you only have a second to read the result of the reading speed analyses.
There is a "BACK" button to get back to the detection results which works fine.
But I would prefer to select "PROGRAM" myself.
Annother issue is, when you use "DETECT", "BACK", "PROGRAM" and then "BACK" again, the results of the "DETECT" are gone.

For Progflash.exe the "detect" option is still undocumented and has been changed from the last version.
It requires an additional parameter now, "all" or "except_writing":
ProgFlash_1_6 MPSSE detect except_writing

In "PROGAM" we still do not have an option to verify the contect of the flash against a given file.
Instead we have "UPDATE&VERIFY" now which works just fine but is not the same thing.
The new version of Progflash.exe also does not have this option, or at least "Progflash module MPSSE verify flash.bin" does not do anything while "ProgFlash module MPSSE write flash.bin verify" and "ProgFlash module MPSSE update flash.bin verify" do work.
Can we please also have a non-destructive verify only option?

"ERASE" works a lot better now, it actively switches the FLASH to BASIC mode now if it is in FAST mode.
So I can erase the chips from the Adesto with EAB now but they still do not work with the provided unified.blob.


Annother observation, the commands used to play the logo animation at the end and they do not do this anymore.
I consider this to be a good thing since at least the two USB interfaces I have could not supply a larger panel since both only have a single 3.3V linear regulator on them.
However, all commands still end up to configure the BT81x to display an empty display list with a black screen and activated backlight at the end.
This is about the worst case possible as an all black screen means the display logic itself will draw the most power while this is not obvious to the user since the panel still is almost black.
I am only using a 4.3" module but the LDO still heats up.
Now take a 7" module that draws around 150mA for the logic alone when all black and 500mA or more or the backlight.
Not only is this beyond what a normal USB port allows, this means the LDO on the UBS/SPI interface needs to dissipate 1.1W of excess power.
And now consider that the near future will bringt 10" modules that will draw more power for the backlight and the logic.

Please do at least deactivate the backlight or even better also leave the panel logic in limbo set PCLK to zero.


Off to more testing...

Is it possible that you have a second init function somewhere else?
In your first example REG_PCLK should not have been written to and therefore the display should have stayed dark.
And now REG_PCLK is not written in the snippet shown and it still works?

Also the init is missing the basic display-list from the manual but this is not the issue.

Push.

Although I am all alone with this so far I added four more chips to the list that I just tested.
This time the first 256 MBit chips, Macronix seem to be the only company that manufacures these
in a  SOIC 208 mil package.

Oh, I also sorted the list and added the manufacturer as it was grown a bit now.

Most of the chips I have tested in the socket now, so I can retest these.
The test now is to connect a USB/SPI interface to my EVE3-43G and use progflash.exe from the command line:

progflash module MPSSE write flash.bin
progflash module MPSSE detect except_writing
progflash module MPSSE erase

Currently I am using the progflash.exe that was part of the EVE Asset Builder 1.6.0 RC1 archive, it identifies itself as "BT81X Flash Programming Utility v1.1".

I couldn't work out how the DMA would deal with the Modulo 4096 on the address it was writing to but with what you guys have described above, it isn't necessary. The DMA would just write to REG_CMDB_WRITE each time!!

Yes, the DMA does not have to deal with the Modulo 4096.
Yes, using REG_CMDB_WRITE for this works if you do not use a FT800/FT801.

But you still can write for example 1024 bytes of data with the DMA to RAM_CMD + 4080, this just works as the FIFO wraps around by itself.
The difference is that without REG_CMDB_WRITE you need to keep track of the offset in your programm and make
it wrap around to follow the FIFO, all my commands just do this now since regardless of DMA or not, after the command or the buffer is sent REG_CMD_WRITE needs to be written.

But yes, using REG_CMDB_WRITE instead is not only easier but also a little faster and takes less program-memory since you do not have to keep track of the offset anymore.
I have tested this now and this really is annother good reason to give up FT80x support.

One nice thing is that after transmitting the DMA buffer my end-of-dma interrupt now needs
to set REG_CMD_WRITE to make EVE start to process the buffer.
With REG_CMDB_WRITE the interrupt only raises CS and clears my dma-busy-flag.

Quote from: Rudolph on June 17, 2020, 10:22:24 AM

Oh, annother thing, avoid tag values below 10, for some reasons these do not give reliable touch events.

Is this really true!?  If so, I have a lot of code to revise.

I am not quite sure.
I tested this the last time back in January with an EVE3-43G and before that found this behaviour with FT813.
At a tag-value of 1 the value was toggeling between 0 und 1.
At a tag-value of 5 the value was toggeling between 4 und 5.
At a tag-value of 9 the value was toggeling between 8 and 9.
Using other values was stable: 2, 3, 4, 6, 7, 8, 11, 15 and 19.
It was reproduceable, I had seen this before and I got a bug-report regarding this.

I just setup a new test with an EVE3-50G and the value is stable.
It just is freaking stable - as it should be.
No idea why, could not explain it back then either, just reading REG_TOUCH_TAG has a rather low potential for failure.

So well, ignore this, sorry.

Though, I'm still at a loss as to the benefit of doing so with the exception of suppressing updates to REG_CMD_WRITE.

There is no benefit to write to RAM_CMD + offset over writing to REG_CMDB_WRITE.
Well okay, it works on FT80x as well.

But what is REG_CMDB_WRITE actually meant to be used for?
In AN_390 we find this:
"To offload work from the MCU for checking the free space in the circular buffer, the FT81x offers
two auxiliary registers “REG_CMDB_SPACE” and “REG_CMDB_WRITE” for bulk transfers. It
enables the MCU to write commands and data to the co-processor in a bulk transfer, without
computing the free space in the circular buffer and increasing the address. As long as the amount
of data to be transferred is less than the value in the register “REG_CMDB_SPACE”, the MCU is
able to safely write all the data to “REG_CMDB_WRITE” in one write transfer."

Well, when I started to play with EVE back in december 2015 I was using a VM800B35A with a FT800.
So no REG_CMDB_SPACE.
But I also did not have the issue that led to implementing REG_CMDB_WRITE, I never had to "offload work from the MCU for checking the free space" as my library never did check the free space.
That is a concept that I decided very early on to not copy from the original FTDI driver.
I still remember that I was very surprised when I found out that the FTDI driver was reading REG_CMD_READ and REG_CMD_WRITE on every single command to calculate the free space in the FIFO.

My library still does not calculate the free space in the FIFO and I am also not using REG_CMDB_SPACE.
My EVE_busy() function does only read REG_CMD_READ and compares that with my own "cmdOffset" var that all my commands update and that gets written to REG_CMD_WRITE.

And this works just fine since the FIFO is always empty anyways.

At least when writing a chunk of data of <4k for a new display list every 20ms.

So my library already has very low overhead and it supports FT80x as well, so I never really had to change
it to use REG_CMDB_WRITE, I never had the problem that lead to implementing it.
And even less so since I started to use DMA to transfer the display list to the cmd FIFO.

I plan to drop FT80x support with 5.0 of my library and this will happen when I implement support for BT817/BT818.
Switching over to REG_CMDB_WRITE then should save a few addtional clock cycles per command, like <10 or so.
Hmm, the longer I think about this the more I know that I need to test this. :-)


What could potentially benefit from REG_CMDB_WRITE and REG_CMDB_SPACE would be CMD_LOADIMAGE.

2k at 8MHz is ~3ms. (calculated with 12 bits per byte to account for the pauses between bytes)
I did a test a while back with a FT813 and decoding a 3867 bytes .png took 53ms.
And decoding a .jpg with 3903 bytes took 480µs

So sending a 64k .jpg in 2k chunks would mean that this would take about 96ms,
the FIFO would always be empty for the second packet.
At a theorethical 80Mhz for the SPI the transfer would take less time than the decoding.
I am sending the data in chunks of 3840 bytes now so 64k would take 17 chunks and a few bytes.
With about ~5.8ms for 3840 bytes and 17 times waiting for 0.5µs this is about 107ms.

So that would shave off about 10ms and not even with 10 images of 64k this would really make a noticeable difference.
At least not when you only load the images once when starting the program.

I wanted to calculate that for .png as well but decided after a couple of steps to not do it fully. :-)
Using .png is not really a valid option in the first place, even less so since we got ASTC.