The software I wrote is quite complex, but I have encountered the following issue that makes programming very complex. This is a sort of warning of unexpected complexity. I would welcome any recommendations how to circumvent the problem.
In my application, I use SCP1000 SPI sensor. He is raising specific line periodially (DRDY), after this I have VERY SHORT period of time to read its register via SPI.
Everything is fine, until:
at the same time, serial flash and eeprom AT45 and AT25 are often accessed. One is 2MHz mode 0,0 another something else, and SCP1000 is mode 1,1 0.5MHz (or anything else, this is a general problem).
The trick is, when DRDY is raised by SCP1000 while CS is already high for AT45, in the ISR servicing the SCP1000 I have to: lower the CS of the AT45 (an this is hell of mess since there are 6 other things on the SPI), setup SPI, comm with SCP1000 then restore SPI state for AT45. The only trick is, AT45 is aborting 'continuous read' or 'continuous write' operation after CS is raised (by design of the chip: in order to protect the data). So there is one more solution: use cli() and sei() pairs around 'casual, blocking' SPI accesses. But this time, the time to read the whole chunk of data from AT45 is so long, while I cannot go into ISR in order to service SCP1000 on time.
General impression is that:
1. it is good to have 2 SPI interfaces, one for realtime, one for offline/blocking transactions.
2. the feature from AT91SAM7A3 that has special hardware module that excludes multiple CS lines to be active simultaneously would simplify the code considerably
3. When some devices need low-delay access via SPI (typically hi-tech digital sensors), they disallow the optimal use of serial flashes because the comms with eeproms must be done in pairs 'sigle address, few data' instead of 'address, data streeeeeeeeeam'.