Unfortunately I can not repost directly, I am not making backups of the posts here. :-)
And I checked the wayback machine, no backup there either.

Well, now we know.

Hello Rudolph,


OK, so working again, thank you.

Apologizes, but I`m unable to restore them. Are you able to repost?

Best regards

BRT Community Admin

Well, let's try. :-)

Do you have a chance to restore the couple of posts that got lost?

Hello Rudolph,


We are working through updating the version. Are you able to post OK now?

Thanks

BRT Community Admin

Hello, it has been a few days since there was a rollback on the forum and nothing new got posted since then.
What happened?

Hi,

Thanks for your question,

We'll check with our R&D team on this and will let you know as soon as possible,

Best Regards, BRT Community

Hi,

Is it possible to tweak some files to add a new platform and a new host to ESD software?
Because when I'm exporting sources, there are not my new platform dependent files.
I'm working on Renesas Synergy Platform.
I've edited EVE_config.h, target.config and export.config.

Or supported platforms are hardcoded in the ESD software?
thx.

What worked best for me across several different MCUs and ready-to-use FT81x/BT81x modules are 74LVC2G17 / 74VHC1G12 buffers and 56R series resistors.

The slew rate / drive strength settings are a bit counter intuitive.
ST for example has "Maximum output speed" settings for the STM32 with levels "Low" / "Medium" / "High" and "Very High".
But using "Very High" is not necessarily the correct idea.
Ideally you match the output to your transmission line impedance.

Analog voodoo in digital transmissions. :-)

For very long I had the luxury of getting away with ignoring the issue.
First my controllers were on the slower side and did not have any settings while driving the lines rather strong,
then I had an issue with a controller having too weak outputs at 3.3V, so I added external buffers as drivers.

Next I learned that my library was not playing well with the Teensy 4 which uses a RT1062, the usuable SPI clock was surprisingly low.
As the Teensy 4 is typically used with Arduino, the settings are made by the classes.
And when I figured out how to change the settings in order to configure for a higher speed, I learned that by default the pins
already were configured for the highest setting.
Using a lower setting worked better - or raising the series resistance.

Hello,

Thank you for the update.

In cases where the SPI connection is long and there is no possibility to shorten it significantly, we would normally suggest adjusting the slew rate and drive strength characteristics of the MCU SPI port to help improve transmission quality. But please do keep us updated with how your testing goes.

Best Regards,
BRT Community

The SPI clock is actually 10 MHz, not 12 as previously stated.  That seemed reasonable, and I was considering increasing it since the FT813 can support up to 30 MHz.  However, due to the mechanicals of the system, the ribbon cable connecting the main board to the display looks like it's 16 to 18 inches.  I don't know what this translates to as far as a max SPI clock speed, but maybe 10 MHz is pushing the envelope.

I was going to run a test with a lower clock speed, but identified a separate problem/bug in the application firmware.  The code that initiates the SPI transaction to get touch tag was not checking the return code from the SPI library call that executes the transaction; it just set the flag indicating that a tag had been read and thus no longer available to read.  The application was locking up on a particular screen, and when it stopped responding to touch, the interrupt was firing, the flags indicated a new touch tag was available, but there was no SPI transaction to read the tag, even though that code is executed unconditionally.  This indicated a failure in the SPI library call (this is on an NXP RT1064, by the way).  I moved the line of code that cleared the touch tag available flag to the point where the call had to have succeeded, which will force a retry on failure.  I could not reproduce the lockup scenario after making this change.

What's peculiar about this is that I was also no longer able to reproduce the 300 ms gap when refreshing the main screen, but that has nothing to do with touch tags.  I'm wondering if moving around the cable to check length affected performance somehow.  These issues do appear to be related to the SPI port at the micro.

With regard to the interrupt handler, it does not include any SPI transactions.  The concern was that an interrupt could occur in the middle of sending commands to the coprocessor in preparation for updating the display.  The interrupt handler just sets a flag indicating that an interrupt has occurred, and the application idle loop picks up on that and reads the interrupt flags when the command coprocessor is idle.

I am going to continue to test, and will post logic analyzer logs along with images if I see issues.