An unexpected need emerged in my design, which is to control 2 slave SPI devices simultaneously. At first, of course, I was planning to to use the SPI Bus as usual and control both devices using the /CS pins so everything seemed fine.
By reviewing the datasheet of device A today, I noticed that it expects all of the data in one go, which means I cannot do the procedure I originally had planned:
1) Select device B
2) Read data from B
3) Unselect device B
4) Select device A
5) Write data from B
6) Unselect device A
7) Repeat until all data from B goes to A (around 1.1 Mbit)
The device A assumes that when its /CS goes high it's the end of data stream. Of course I cannot read everything from B in one ran and store them to MCU RAM, since the data are way bigger.
Naturally, the next thing that came to my mind is to use 2 separate master SPIs at the same time: select both chips, read on byte from B and feed it immediately to A.
So my questions are:
a) Is that possible using an ATmega32u4? It has a critical role in the overall design and changing to another MCU Would be a step back.
b) I read that the USART can act as a second SPI master. Is that viable and reliable? How hard is to implement?
c) If, unfortunately, is not possible and I have to change MCU, which one would you recommend? Note that the USB capability of ATmega32U4 is essential.
d) Is the new process (read from B, feed to A) likely to cause any unexpected behavior? Does not seem in my point of view, I am asking just in case since I am a new engineer.
Any other idea or direction is welcome! Thanks in advance.
UPDATE
In case it plays a significant role, Device A is an FPGA while B is an flash memory. The MCU has a dual role: Download the bitstream from the PC via USB and store it on the flash ROM / use the stored bitstream to configure the FPGA upon reset/power on. Both FPGA and flash use SPI. According to the datasheet of the FPGA (ice40 family, Lattice, "iCE40 Programming and Configuration" p.26), the image has to be programmed without interruption.
Best Answer
You might want to take a different approach altogether. Instead of attaching both the PROM and the FPGA to the µC as slave devices, attach the PROM directly to the FPGA, and allow the FPGA to boot in SPI master mode instead of SPI slave mode. Bonus: the booting will happen more quickly.
You'll still be able to access the PROM from the µC after the FPGA has booted for firmware updates or data storage, by passing the µC's SPI interface signals through the FPGA logic.