Question: How to do 3x RA8875 displays on an Arduino Due.

[Jim-McDonald]

I know you've tested/used quite a few RA8875 display variants now but I can't find/remember you having tried multiple displays at the same time from a single board?

Of course there is the issue categorised as "other SPI devices". Is it more correct to say "other TYPES of SPI devices" (EG RA8875 + SD Card) or do multiple RA8875 (no SD Cards) also cause issues?

I'm just thinking about a little sub-project that calls for 3x Displays (ER-TFTM043-3 in this case, 480x272). As the Arduino Due has pins 4, 10 & 52 for SS and a decent amount of memory & processing power I can't think of any issues apart from the multiple SPI devices on a single bus that stands in the way.

(I suppose you could use the hardware SPI for 1st display and software SPI library for 2nd & 3rd? Lots more pins used though and not very elegant).

It would be good (time permitting) for you to do a Wiki page entry of a Arduino powering multiple RA8875's please!

[sumotoy]

If you use my isolator circuit for each display it's possible. However you should take care of this: 1) Power up all display externally, too much current for any Arduino or whatever. 2) Keep SPI line as short as possible, or put the isolators circuit very near CPU. 3) You should choose legacy CS pin for DUE (check DUE datasheet, 10 and 52 I already know it's fine). 4) All display must share the same SCLK,MOSI,MISO (trough isolators) 5) All display needs a different RST pin (can be any unused pin) The library it's multiple instance compatible, this mean that you connect all display (with SPI isolator/buffer) in the same SPI lines but with different RST and CS pin). RA8875 tft1 = RA8875(4, 3); RA8875 tft2 = RA8875(10,4); RA8875 tft3 = RA8875(52,5); and of course: tft1.begin(RA8875_480x272); tft2.begin(RA8875_480x272); tft3.begin(RA8875_480x272);

I do not use any buffer inside library so (even with large display and tiny cpu) it doesn't use so much memory. Soft SPI it's not a good option, it's slow and as I said this library it's multiple instances compatible

[Jim-McDonald]

Understood, thanks.

To confirm, a block diagram showing external power supplies to the three displays, controlled by three separate RESET lines (with Interrupts for the touch panel) and the three 74HC125's (each with separate SS/CS).

Edit: Added three hard Reset lines. Another edit to add three Interrupt lines.

Flash Support?

WerkAG recently mentioned using Flash in an Issue recently and I'll need to store images/assets in Flash too ( Winbond 128Mbit Flash W25Q128FV ! ).

Whilst the Arduino documentation makes it clear that the Due can use Pins 4, 10 and/or 52 for hardware SPI... is that true? Can you not use any free pin (set to Output) as SS? (or is this only now changed with the new SPI "transactions" way of doing things).

If you can't use any Output Pin for SS, what do you recommend as the best solution for a 4th (5th, 6th etc) SPI Device?

[sumotoy]

In the schema you forgot to pullup every CS line! You can use any pin only for RESET, not for CS, this is an hardware limitation of the CPU and it's strictly related on how the SPI it's handled internally. Why you don't get a Teensy 3.2 for that work? it has more CS pin and it's faster than DUE (also it cost much less).

[Jim-McDonald]

In the schema you forgot to pullup every CS line!

It's just a functional block diagram (IE just showing inputs/outputs of blocks), so doesn't have any resistors, caps etc. Gives maximum clarity.

You can use any pin only for RESET, not for CS, this is an hardware limitation of the CPU and it's strictly related on how the SPI it's handled internally.

Yes, that was my initial thought but it still bugs me that it's not strictly true.

I suspect the hardware limitations are really on the MOSI/MISO/SCLK and not SS. Yet the documentation (of SPI library for example) does strongly imply the SS is limited too (4, 10 & 52 for Due). After all, when you think about it, why would SS be hardware limited?

Here is a quote from Arduino SPI reference page.

It is, however, possible to use any pin as the Slave Select (SS) for the devices. For example, the Arduino Ethernet shield uses pin 4 to control the SPI connection to the on-board SD card, and pin 10 to control the connection to the Ethernet controller.

Yes they use 4 & 10 in their example but if you take it strictly that means it would only work on Due yet those shields coexist and work on Uno's etc.

Web searches provide evidence that you can have as many CS/SS as you have spare pins for EG Uno with two SPI devices - CS on Pins 9 & 10

Alas I don't have the items at hand to try it myself :(

Why you don't get a Teensy 3.2 for that work? it has more CS pin and it's faster than DUE (also it cost much less).

Major props to Paul Stoffregen and the Teensy products!

However, for me, there are factors at play and I'll list some of them so you know I'm not dismissing it as an option out of hand.

1. I have an Udoo Quad - which has a Quad core 1GHz ARM9 as well as a Due on a single board (with inter processor communications). This board will act as Gateway to a network of Due's linked by CANbus...
2. CANbus (Teensy is one of the few other mCU boards that supports CANbus at all BUT it only has one controller and the Due has two controllers. First Bus is for inter-node communication, Second Bus is to connect to external devices such as Motor Controllers). Note: Paul has contributed to CANbus API library etc.
3. I have Due's but no Teensy's. Standardising on Due's makes the project overall simpler (single code base, single hardware stocking for spares/replacements/testing etc)
4. Speed... not much in it but the Due is actually faster (84MHz) than Teensy 3.2 (72MHz - although it could be overclocked).
5. Other aspects... Due wins on Memory (512+96 vs 256+64), Shields, Libraries, Pins etc. Teensy 3.2 does have some wins of it's own such as ADC, EEPROM etc.

However if it wasn't for the Udoo Quad (with Due on board) key component of my project and the single CANbus controller I would probably switch to Teensy.

[sumotoy]

The SPI use of CS it's strictly related to the processor used, on AVR the SPI speed it's so low and internal CPU it's so basic that virtually any pin can be used, on arm processor the internal architecture it's much modern and the SPI speed are much faster, for example on teensy you can reach over 30Mhz, this force to use pins that are in the same ports for serial communications (not in all cases, there's many variations like use of DMA,internal architecture enhancements,etc.). DUE has also an optional SPI extended mode where cs pins are automatically handled, my library support this too and pin limitations reasons are obvious. Btw, if you are forcing slow speed on SPI, you can try use different pins, the drawback is that CS pin should be low before the spi stream and high after (in short, but things are more complicated in real life since there's to wait the clock, etc.) but this is insured only when the pin that generate stream it's in the same cpu port of the cpu or the architecture has been optimized for this. Of course there's techniques to go around this (adding a delay after cs and before pull it up) but I would not raccomand. I will leave apart considerations about Teensy vs DUE, I can only say that DUE has very buggy core libraries (you can see when it compile) and the SPI has several bugs (still not solved) that drived me crazy in the past, expecially when SPI mode 1,2 or 3 it's used, in my library haved to use some workaround for this reason, Paul did a great work to get rock solid core libraries (in next version I will introduce a DMA option foe SPI on Teensy). The SPI transactions has been developed (by Paul) to prevent SPI devices in the same line to interfere between each other, has nothing to do with CS pin limitations, but brings many nice features like SPI speed modulation, INT workarounds, etc. In your particular case it's a life saver. Why you need SPI isolator? 2 main reasons, the RA8875 SPI lines are weak so the isolator works also as buffer, second, RA8875 works in SPI mode 3 and most SPI devices works in SPI mode 0. Now talk about Flash, the RA8875 has a secondary internal SPI bus that uses DMA to access SPI flash and should be really fast, this in theory since the Flash chip has to be programmed in advanced and then soldered on Easrising board, this doesn't add any other cs pin since it rely on the RA8875 secondary bus, I support it but I really haven't tried deeply! I will like to solder an adaptor to avoid solder/desolder continuosly! Putting Flash in the same SPI bus, you'll need another CS pin! As I wroted in the wiki, send images to RA8875 it's a slow business, I cannot avoid this, it's an hardware limitation of the RA8875, for b11 I spent weeks to get a fast way to transfer font data on screen, it worked at the end but it's not applicable to color data so if you have in mind to transfer big image data on screens remember that it can be a bit slow.

[Jim-McDonald]

Thanks Max

As you say yourself, the AVR & ARM hardware is different and gets all mixed up in the various online documentation (which in turn led me to false hope!). In the last few hours I thought I'd check the SAM3X8E documentation to get a definitive answer.

There is a 4th CS pin (NPCS3), and even a 2nd hardware SPI (again with 4 CS pinouts). Alas they aren't mapped in the Arduino Due implementation (IE they are on the processor but not used on the board. Given most Pins carry several functions you'd think they could have done a few more!).

It seems there are only two options left open:

1. Switch to Teensy for the nodes that need >3 SPI devices (which is only going to be 1, possibly 2) 2. Implement an SPI Multiplexer (4 CS's would allow 15 but as only 3 CS are mapped that tops out at 7 devices I guess as the Multiplexer itself is a device and claims an address). There are loads of these little things around (MAX350, LTC1391 etc). Needless to say I'm aware of them but don't have any

However, if your library isn't SPI Multiplexer aware then that isn't going to help!

_I don't suppose this is of enough interest to you to explore further is it Max? :) _

------------

SPI Flash

I can see that 3 displays and >3 SPI devices might not have a wide audience. However SPI Flash I'm sure will be very useful to many people.

Therefore I think it best to start a separate discussion on this.

[sumotoy]

Multiplexing CS it's definetively not an option, you will mess up all SPi timings! Apart that I think that SPI library itself block the use of not-legacy CS pin, at list the Teensy does, so this it's a big limitation to use a multiplexer. Maybe you can share one of the cs pin by using a nand port? There's a chip called MCP23s017 from microchip that allows 8 SPI devices in the same SPI line, included CS pin, it's a technology called HAEN, I wroted the library for that and works really well. Paul writed a very good Flash library, but recently I'm more attracted by FRAM.

[Jim-McDonald]

Ok, that makes sense (that a Multiplexer gains you devices but at the huge expense of timings... bandwidth/timings are critical on a multi-display setup of course).

That leaves switching this node in my project (with three displays & two other SPI devices) to Teensy 3.2 then.

Thanks for your time in considering the problem!

[sumotoy]

wait, maybe there's a better way to do that. The SPI devices are enabled/disabled by CS pin and we already know that there's some limitations about witch pin to use. But using some old-school logic you can even reduce CS pin to 2 and extend SPI devices by 8/16! How? You can use OR ports, if you can use 3 port and connect 3 input (one for each OR) together and to one CS from CPU, the out of each OR port goes to CS of each display. Take a look to this simulator http://academo.org/demos/logic-gate-simulator/ It remain 3 OR inputs, when are HI, all the out are HI so CS are disabled but as soon one of this inputs goes LOW the CS pass trough the port and reach the display. In this way you have to include in your software a routine that control OR ports before you access by SPI, since it's just a semaphore it will not interfere with SPI timings. Jus be sure to choose OR ports that have enough bandwidth.

[Jim-McDonald]

Ok, I'll use some basic logic IC's then to solve the "need 5 SS, only have 3 SS". Thanks.

Could you do a little experiment? I assume you still have to hand several 5"/7" RA8875 displays on your workbench.

Could you put three displays on one Due and run the your usual benchmarks/demo? It would be interesting to see if the Due is powerful enough to feed three displays at the same time - even better if you video it!

[sumotoy]

Sorry I can't, I have several display but the workbench it's just a unique custom board with piggyback for different processors, I can test only 1 display vs SD, Audio Board and as piggyback I have several MCU but not DUE since it's too big and won't fit, I refuse to work with breadboard, the SPI speed are simply too high. My time it's also limited to weekends and just few hours.

[Jim-McDonald]

That sounds a most interesting setup!

I'll let you know if/when I get a multi-monitor setup working and take video of it for you.

I also thought a small library sat on top of your "base" RA8875 library could handle a multi-monitor setup and provide some features like spanning (hard) & mirroring (easy) etc. Not thought it all the way through yet. (If it works well, you can roll the features into your library if you wish)

The upcoming Teensy ++ 3 looks interesting and would indeed leave the Due in the dust (onboard SD Card, 2x CAN, 2-3 SPI, higher clock, more memory etc etc). I may go for that rather than mess with logic IC's to fudge the SPI/SS issue I have. I can wait a few months.