Sorry, I have not had time (or energy) to fully review the PRs yet.
I’d love for that to be true, but I believe that because of the speed optimisation stuff there are issues. Specifically, retaining TCR state and pending RX count - each instance thinks it knows the state, but another one may have messed with it…
The "more fun" stuff is trying to improve the use of some of the cameras supported on Zephyr on board like Arduino Giga or Portenta H7 or currently with Arduino Nicla Vision.It‘d be great if you or someone else could do a review and / or test, especially with T3.x, but no hurry on this niche case … keep on with the “more fun” stuff
with 
as @mjs513 can attest to as well 
. Will also try it at some point, hopefully soon to try some of these cameras with the Teensy board. But so far there are no Video subsystems like CSI, or FlexIO supported for the Teensy boards...
void ILI9341_t3n::waitTransmitComplete(void) {
uint32_t tmp __attribute__((unused));
// digitalWriteFast(2, HIGH);
while (pending_rx_count) {
if ((_pimxrt_spi->RSR & LPSPI_RSR_RXEMPTY) == 0) {
tmp = _pimxrt_spi->RDR; // Read any pending RX bytes in
pending_rx_count--; // decrement count of bytes still levt
}
}
_pimxrt_spi->CR = LPSPI_CR_MEN | LPSPI_CR_RRF; // Clear RX FIFO
// digitalWriteFast(2, LOW);
}pending_rx_count, but there are so many possible paths that it just seemed easier to do that than "hope" all paths end in a waitTransmitComplete(). As it's just a few memory accesses any loss of efficiency that aren't dealt with by the compiler optimisation should be very minor.dma_state flags did need a bit of cleaning up for consistency between ILI9341, GC9A01A and ST77xx drivers, but nothing too major. As you say, there's actually very little point in knowing if DMA initialisation has happened, because another driver (specifically my re-working of the ST77xx one) will almost certainly trample on your setup at some point. You can still rely on any values set up in the _dmasettings[] array, as that is not shared. So any asynchronous updates just need to copy the required settings to the DMA registers, which will add only a few µs. Also, only a single DMA channel is allocated for all displays on each SPI bus, and then only if asynchronous updates are used. Previously, one was allocated per display; as there are only 16 available with current Teensyduino, and 32 in all, Probably the audio library? I forget which object it is, but one of the sources has a couple of DMAChannels outside of any class so they don't get discarded despite never being used.
#include <SPI.h>
#include <ILI9341_t3n.h>
#include <ili9341_t3n_font_ComicSansMS.h>
#define ILI9341_RST 8
#define ILI9341_DC 9
#define ILI9341_CS 10
ILI9341_t3n tft = ILI9341_t3n(ILI9341_CS, ILI9341_DC, ILI9341_RST);
void setup() {
Serial.begin(9600);
tft.begin();
tft.setRotation(3);
tft.fillScreen(ILI9341_BLACK);
while (!Serial) ;
tft.setTextColor(ILI9341_WHITE); tft.setTextSize(1);
tft.enableScroll();
tft.setScrollTextArea(0,0,120,240);
tft.setScrollBackgroundColor(ILI9341_GREEN);
tft.setCursor(180, 100);
tft.setFont(ComicSansMS_12);
tft.print("Fixed text");
tft.setCursor(0, 0);
tft.setTextColor(ILI9341_BLACK);
for(int i=0;i<20;i++){
tft.print(" this is line ");
tft.println(i);
delay(100);
}
tft.fillScreen(ILI9341_BLACK);
tft.setScrollTextArea(40,50,120,120);
tft.setScrollBackgroundColor(ILI9341_GREEN);
tft.setFont(ComicSansMS_10);
tft.setTextSize(1);
tft.setCursor(40, 50);
for(int i=0;i<20;i++){
tft.print(" this is line ");
tft.println(i);
delay(500);
}
}
void loop(void) {
}
github.com
void ILI9341_t3n::scrollTextArea(uint8_t scrollSize) {
uint16_t awColors[scroll_width];
for (int y = scroll_y + scrollSize; y < (scroll_y + scroll_height); y++) {
readRect(scroll_x, y, scroll_width, 1, awColors);
writeRect(scroll_x, y - scrollSize, scroll_width, 1, awColors);
}
fillRect(scroll_x, (scroll_y + scroll_height) - scrollSize, scroll_width,
scrollSize, scrollbgcolor);
}Accurate documentation … wouldn’t it be lovely?!
while (!Serial) ;scrollText method to enable scrolling down as well as up, but of course you’d have to call it yourself, because text wrapping or newlines only cause upwards scrolling.while(!Serial) ; feature is indeed in many example sketches - they’re examples, not useful standalone code. Although not useful in the ScrollTest case, many PCs don’t enumerate USB fast enough to catch the first lines of output, so it’s very useful during development, but then confuses many people when their code ”doesn’t run” when connected to a simple power supply, or they don’t start the serial monitor. There are dozens of posts on this forum where folk have been caught out that way. There is no “right” answer, except to be aware of the possibility in others’ code.If you think this is 'fairly easy' - can you provide a modified code to scroll forward and backward?
There is no hard rule on this... It really depends on which display control chip is used and in some cases whose display...
I typically add the above line with a timeout... Like: while (!Serial && (millis() < 5000)) {}
It should not be too difficult, but personally I am busy playing on other stuff...
Well, it's "fairly easy" for those who are happy digging around in the guts of the libraries!
ScrollTest example which shows how to scroll both up and down, and also checks that MISO is connected and working. I've done a pull request, but I know @KurtE has other stuff on his plate, so it may take a little while before he can take a look at it.