The biggest time waster for D-DAQ is writing out data to the displays. Now that I think I'm understanding how each of the separate processes are working together, I'm figuring out the timing for the software end to operate in worse case scenario, which is where I cannot utilize all 3 SPI channels simultaneously but instead have to serially access them. That being said, knowing how fast the design needs to sample it's 14 analog and 2 digital inputs is crucial.

The SPI bus will be running at 1:4 P-Bus, which is running 1:1 with SYSCLK. The ADC unit can convert up to 1 Msps, which is much greater than I need. I know some daq's run 20 Ksps or higher, but right now I will not be going that fast. How fast can I run it though without affecting display output?

SYSCLK is generated through a 4x multiplier of the external oscillator, which I'm setting at 16.368 MHz. This easily gives me the same frequency for my SPI bus. From what I've read, running the SPI bus at more than 50% duty cycle risks stalling the CPU. Now as I understand it the SPI bus operates "independently" of the CPU, i.e. it's not like bit banging where each bit requires CPU time, so once the SPIxBUF is written to or filled, a SPI transfer is initiated and the CPU continues on it's merry way. How long does it take to write to the buffer though?

Worse case scenario, I assume it takes an equal number of cycles as there are bits. This being said, lets run some numbers. 16.368 MHz (or bits), 50% (aka 1:2) DC, share that with 3 displays, and it takes 16 bits of data to represent 1 pixel. This leaves me with 682,000 pixel/sec (excluding any overhead, et al) per display at which I can write out per display. Sounds like plenty, but a 128x160 display has 20,480 pixels so this equates to ~33 fps; well below my desires 60 fps. Well, since I cannot spend my day writing to the displays and I have to sample the ADC as well, I have to figure out how much of the display I can update in one go before I have to attend to other things on the microcontroller.

20 Ksps is very respectable in my ignorant opinion, but again too high I feel. As I will probably be doing some light data smoothing, there is computational overhead that has to be factored in. So let's halve that to 10 Ksps. Those 682K pixels cannot just all be blindly written out but have to have some pauses so I can service the ADC unit and if I do that at 10 Ksps, that drops how many pixels I can write out in one go. Recall that the SPI bus is operating at 50% DC so this means I double the result, or halve the division, 10 Ksps. Either way, that gives me ~136 pixels before servicing the ADC or something else. My "needle" on a gauge face is ~175 pixels depending on the angle it is drawn and I have to erase it before drawing a few one. Ouch!

Well, halving that to 5 Ksps won't even let me re-draw a needle and I do have various pieces of text/numbers to update on the display. As such, right now it seems like I have to drop down to 2 Ksps to start with because I will also be doing many other things that influence the overhead of writing out pixel data. There is hope though!

I have this tid bit from a chart in the SPI-specific datasheet:

It appears to take 1 to 3 SPI bus clock cycles to complete a write to SPIxBUF. Why a range? Well, after 5 SPI clock cycles, the chart shows the user can write new data. If it took only 1 clock to write new contents to the buffer, then the latter 3 bits would be overwritten, no? If I treat this detail as a duty cycle rather than a fixed time constant/delay, then after 10 clock cycles, I can write new data to the buffer in a 16-bit transfer. As the chart is for an 8-bit transaction, I will have to test the accuracy of this theory since I'll be doing 16-bit transactions, the max the SEPS525 display driver will accept in one transaction.

This holds a lot of hope because I have everything *but* the SPI bus running 1:1 with P-Bus which is again, 1:1 with SYSCLK: any cycles the SPI bus isn't occupying the CPU means I have 4x that for calculations, IRQ servicing, ADC sampling, et al. Fingers crossed.