Reply To: Suggested refinements

[Anonymous]

Thank you for your very thorough reply.

Although the actual transfer speeds may be the same, I’d still have thought that the time spent by the CPU would overall be less if transferring say, 64 bytes instead of 2 x 32 bytes. Although the difference maybe small there is the set up times for a transfer from the SD card to the CPU and then from the CPU to the DAC chip. Just the act of calling any method (eg rack.read() or dcs_low()) takes CPU cycles to push / pull parameters from the stack and make the jump. When using the Due-only SPI extensions, that difference in CPU time should be greater though probably not an awful lot.

This is probably all nit-picking. I’m not sure what percentage difference it would make.

I’ll be using the Sparkfun MP3 shield so I’m not sure that the channel selection capability of the Due helps. If I understand correctly, the shield uses specific output pins of the Due which can’t be changed without soldering a new connection. However, what does help is the ability of the Due to specify that a transfer will comprise of several bytes through the use of the SPI_CONTINUE parameter, eg:
It’s possible to send more than one byte in a transaction by telling the the transfer command to not deselect the SPI device after the transfer :

void loop(){
//transfer 0x0F to the device on pin 10, keep the chip selected
SPI.transfer(10, 0xF0, SPI_CONTINUE);
//transfer 0x00 to the device on pin 10, keep the chip selected
SPI.transfer(10, 0×00, SPI_CONTINUE);
//transfer 0x00 to the device on pin 10, store byte received in response1, keep the chip selected
byte response1 = SPI.transfer(10, 0×00, SPI_CONTINUE);
//transfer 0x00 to the device on pin 10, store byte received in response2, deselect the chip
byte response2 = SPI.transfer(10, 0×00);
}

The parameter SPI_CONTINUE ensures that chip selection is keep active between transfers. On the last transfer SPI_CONTINUE is not specified as it’s the last byte transferred.

The above excerpt was taken from: http://arduino.cc/en/Reference/DueExtendedSPI

In my case I will be running a stepper motor concurrently with playing music. Since the VLSI chip has a 2kbyte buffer, it is not a real-time device and can be handled with a lower priority than the motor which must receive a pulse at a specific time so as to maintain a specific velocity or acceleration. So for my specific case, what I am planning is to use a timer for generating the next motor pulse. I would then have a simple loop that polled the VLSI chip to see if I needed to send more data. Since the motor would be driven by a timer-based interrupt, it would have top priority by interrupting any step involving music playback.

What I’m not sure about is the best method of checking when to send more data to the VLSI chip. Constantly calling digitalRead(MP3_DREQ) would seem to be the least efficient. Testing the specific bit on the port would seem to be faster, but what I might do is have a timer-driven interrupt that simply sets a flag. My main loop would then need simply check the status of that flag. Although the triggering of that timer would interrupt any currently executing step involving the motor, the time taken for the method to be called that only sets one flag should be insignificantly small. Using a timer would also give me the flexibility of less frequent transfers too if I so wanted. However there is a downside of increased complexity with having too many timers. Maybe I should just keep it simple by testing elapsed time instead of using a timer.

Your views would be very welcome.

Thanks for the link to the forum discussion re. the Ethernet and MP3 shields connected to a Due. If I have understood correctly, you say that the use of the new SPI_CONTINUE parameter has no real world benefit. Is that correct? According to the Arduino page I listed above:

The chip selection is handled automatically by the SPI controller, the transfer command implies the following:

Select device by setting pin 4 to LOW
Send 0xFF through the SPI bus and return the byte received
Deselect device by setting pin 4 to HIGH

So from reading the other forum I think you made your conclusion from reading the source code whereas the above implies that the chip is automatically selecting / deselecting which maybe is not evident from reading the Arduino source code.