polpla
Member
Hi guys, sorry for the late response. I put together a short tutorial about how to use DMA to speed up the transmission rate of SPI on the Maple.
It can be found here: http://polplaiconesa.com/tutorials/SPI+DMA.html
Hope it is helpful!
I used something similar to create a faster version of SDFat Library but (since I have never done it before) I am unsure about how to share it with the world. Does anybody have some guidance on this matter?
Thanks!
polpla
Member
Okay, I created a github repository with the code!
Let me know if you would like to help improve the code. The most urgent thing is to add DMA to the writing functions, right now I have only implemented it in the reading ones.
Hope it is helpful!
Find the code here: https://github.com/polpla/Maple-SDFat-DMA
manitou
Member
polpla, thanks for the code. I have tested block read performance with a simple sketch using card.readBlock() at various SPI speeds and compared with non-DMA with mapleSDfat library. SD block is 512 bytes.
SPI speed DMA non-DMA
1.225MHz 0.8mbs 0.7mbs
4.5MHz 3.3mbs 1.3mbs
9MHz 6.0mbs 1.6mbs
18MHz 8.2mbs 1.6mbsI don't think you need DMA_CIRC_MODE, and you can get by with just a one byte ack[] array if you disable DMA_MINC_MODE. I tested the library with both of these modifications, and DMA reads still seemed to work.
I also tried simple card.writeBlock() tests which worked with the mapleSDfat library, but I got errors when doing write using the polpla library?? I'm still trying to figure out what's different, as I was going to try to add DMA for writes ??
Here is what I was going to add to Sd2Card::writeData()
#ifdef DO_DMA_WRITE
dma_setup_transfer(DMA1, DMA_CH3, &SPI1->regs->DR, DMA_SIZE_8BITS, (uint8_t *)src,
DMA_SIZE_8BITS,
(DMA_MINC_MODE | DMA_FROM_MEM | DMA_TRNS_CMPLT | DMA_TRNS_ERR));
dma_attach_interrupt(DMA1, DMA_CH3, DMAEvent);
dma_set_priority(DMA1, DMA_CH3, DMA_PRIORITY_VERY_HIGH);
dma_set_num_transfers(DMA1, DMA_CH3, 512);
dmaActive = true;
dma_enable(DMA1, DMA_CH3);
while(dmaActive) delayMicroseconds(1);
dma_disable(DMA1, DMA_CH3);
#else
for (uint16_t i = 0; i < 512; i++) {
spiSend(src[i]);
}
#endif
manitou
Member
I was able to get rid of the write errors in polpla's lib by spinning on status_
while((status_ = spiRec()) == 0xff);
I also got DMA write's to work with one channel. Here is my current version of Sd2Card.cpp
http://pastebin.com/AxSGGxDb
I only did low-level card.writeBlock and card.readBlock tests.Here are current results for various SPI frequencies, including raw (unconnected) SPI speeds and Arduino UNO SD performance data.
unconnected SPI performance (transfer 1000 bytes)
maple spi maple spi/dma
SPI clock read/write read/write
1.125MHz .85mbs 1.125mbs
2.25MHz 1.35mbs 2.25mbs
4.5MHz 1.8mbs 4.5mbs
9MHz 2.2mbs 8.9mbs
18MHz 2.2mbs 17.8mbs
SD/SPI block (512 bytes) read/write Arduino SD/RTC shield
maple spi maple spi/dma
SPI clock read write read write
1.125MHz 0.75mbs 0.64mbs 1mbs 0.84mbs
2.25MHz 1.1mbs 0.91mbs 1.86mbs 1.36mbs
4.5MHz 1.4mbs 1.2mbs 3.19mbs 2.0mbs
9MHz 1.6mbs 1.25mbs 5.1mbs 2.6mbs
18MHz 1.6mbs 1.3mbs 7.1mbs 3.06mbs
arduino avr328/16MHz
SPI SD (with OPTIMIZE_HARDWARE_SPI)
SPI clock read/write read write
2MHz 1.57mbs 1.4mbs 1.2mbs
4MHz 2.6 mbs 2.3mbs 1.7mbs
8MHz 3.8mbs 3.4mbs 2.1mbs
micah
Member
Manitou, how much of your SD performance results do you think could be attributed to the card itself?
I'll let you know if I can do > 10 mbps write with a card I've used for multichannel audio. I have a few of these amazing MEMS microphones that respond all the way up to ~60-80 kHz. I'm hoping to be able to capture in at least the 50-60 kHz range. I want to be able to play back at slower rates and still hear ambient noise in the ultrasound (without it sounding muddy).
Here's my inspiration: http://www.youtube.com/watch?v=o-l7_olNr0k#t=2m50s
Yes, that trombone playing a diatonic scale is actually a bird, slowed down several times over.
manitou
Member
> how much of your SD performance results do you think could be attributed to the card itself?
The SD card internal speed is certainly a factor. I was using an old SanDisk 2GB SD card, which didn't have a class/speed rating on it. I couldn't find any specs for that card.
The "unconnected SPI speeds" will be your upper limit.
micah
Member
I must have jacked up my units during earlier calculations (i.e. the 10 Mbps number)... With 2 samples per period at 70000 Hz, I'd need 2 samples*70000 Hz * 12 bits/sample = 2.0 Mbps.
It might even be possible to do stereo... or surround sound ; )
Just for reference, this table shows "Max SPI transfer speeds" of > 17.9 Mbps for all the varieties of SD cards listed, and many of them are listed at ~50 Mbps. So theoretically it shouldn't be too hard to find a card that could take advantage of the "unconnected rate".
Rich Simmons
Member
If I could tailgate on the much higher level discussion above, with a pretty basic question about SPI communications with ADC and DACs, ideally using HardwareSPI. I'd like to write to a Linear Tech LTC 1659 12-bit DAC.
HardwareSPI seems only to have 8-bit write. For 12-bit I guess you'd send a second byte and throw away the least bits. The LT data sheet shows that the /CS chip select line needs to transition high-to-low at the start of the transfer, and low-to-high at the end -- that is, after the 12th bit has been received. I can't see how HardwareSPI::write()can do this. Looking at the waveforms, I see the clocks and the data, but 1_NSS is always low.
So the questions.... Does HardwareSPI offer a way to control the number of bits transferred, and the timing of the 1_NSS active signal?
Here's what I'm using
void setup() {
spi.begin(SPI_18MHZ, MSBFIRST, 3);
}
void loop() {
SerialUSB.println("DAC Data Out");
delay(1500);
int8 DACByte;
DACByte=0x128;
spi.write(ADCByte);
}
Thanks again for all the help!
Rich Simmons
mbolivar
LeafLabs
So the questions.... Does HardwareSPI offer a way to control the number of bits transferred, and the timing of the 1_NSS active signal?
No(t yet) on both counts, and the SPI peripherals on STM32 only support 8- and 16-bit data frames.
You can specify SPI_DFF_16_BIT in the flags argument to turn on 16-bit mode if you turn the SPI on via spi_master_enable(). That doesn't help with your NSS problems, though.
The CS/NSS pin needs to be toggled in software as the hardware has been setup in HardwareSPI so it won't do that because of how data is transferred to the SPI peripheral. You'll need to set the pinMode of the CS pin like this in the setup:
pinMode(9, OUTPUT);
digitalWrite(9, HIGH);
I'm using pin 9 as an example NSS pin, and remember after setting the output to put the level you need it to be for idling. And before and after your transfer you'll need to set the pin low and high like this.
digitalWrite(9, LOW);
spi.write(ADCByte);
digitalWrite(9, HIGH);
Now we'll get to the length of how much you need to send. The problem with the SPI hardware it only supports 8-bit and 16-bit frames, this is a minor issue. The good news is, the device you're using (I believe, I don't have access to the hardware and have only taken a look at the datasheet) doesn't care if it's sent 16 bytes, as long as the information it wants is contained in the 'last' 12 bytes of the 16 bytes, so you should be able to do this:
uint16 ADCByte=0x0128)
digitalWrite(9, LOW);
spi.write(ADCByte<<8);
spi.write(ADCByte);
digitalWrite(9, HIGH);
That should be able to do it then. Let me know how it goes.
You must log in to post.
