Yup. Maple's Hardware SPI1 is in the same D13-10 as the Arduino's hardware SPI. This shield uses D8 for CS, so you'll have to manually control selecting the SD card - which is done in the SdFat library, but on D10.
Has any user created a SD memory shield/library from the Arduino to the Maple?
(149 posts) (39 voices)-
Posted 4 years ago #
-
Do we need to use pullup resistors when connecting the card to SPI?
Posted 4 years ago # -
I just wrote and article for my blog that uses this SDfat library for the Maple. I posted code examples and snapshots of my code on how I went about implementing it and the SD card shield I used:
http://thesolarpowerexpert.com/an-open-source-high-speed-data-logger/
Posted 4 years ago # -
thanks for the great post!
Posted 4 years ago # -
Hi,
I have been successfully using the library with a regular 1GB microSD card but I have not been able to use it with a 4GB microSD HC card. Both of the cards are formatted to FAT32 and have exactly the same content. Anyone knows why this could be?
Also, is there a way to speed up the process of reading/writing to memory? Using this library, I don't manage to get over 92KB/s. I understand that there are faster and slower SD cards. However it seems that even the slowest SD cards should be able to do close to 2MB/s which is 20 times faster. Has anybody managed to use it faster than this?
Thanks!
Posted 4 years ago # -
I believe HSDC cards are different from ordinary SD cards. I may be incorrect, but Wikipedia seems to confirm that:
http://en.wikipedia.org/wiki/Secure_DigitalOrdinary SD card is up to 2GB.
Wikipedia says that SDHC cards use a "slightly different communication protocol".Posted 4 years ago # -
I was confused because early in this discussion someone was saying that they got the library to work with SDHC cards as well...
Posted 4 years ago # -
Hello polpia-
Can you please create a link to the earlier post in this discussion (which is now four pages long) which confuses you? This will help other people respond more quickly.
For example, the link to your last past is:
http://forums.leaflabs.com/topic.php?id=112&page=4#post-6356
The hash (#) symbol at the end of each post is a hyperlink to that specific post. Depending on your OS, just right click (or command click, etc) and then select "copy link address". Then paste the earlier post URL into your next reply.
Is the hash mark documented in the user docs? For a long time I did not know how to refer to specific posts.
I hope this is a useful post. Thanks!
Stephen from NYC (full disclosure: I am not a member of the LeafLabs staff)
Posted 4 years ago # -
Sorry, here is the link:
http://forums.leaflabs.com/topic.php?id=112&page=2#post-1112
Also, in terms of speed, I depurated my code a little and now I can read at 158KB/s. This is still way under the lowest specification for SD cards (which is 0.9MB/s); does anyone have an idea why this happens?
Thanks
Posted 4 years ago # -
Hi Popla: Sorry I can't be much help, only to comment that I see the same problem. It takes my code at least 5ms to write a 512B block to a 2Gb uSD card, which is only 100kB/sec. I know that the card can be read & written MUCH faster than this, because I can transfer files to/from a PC via USB card reader, at a much faster rate. My code is writing RAW, just a loop with SPI transfers. Playing with the SPI clock etc has no effect on the transfer rate, implying that the bottleneck is on the card. So I'm stumped ...
Posted 4 years ago # -
I have started looking through the library to see if there is any way to optimize the read and write functions for the specific use I make of them. I'll post stuff as soon as I figure out. If anyone has done this before and could give us some pointers, that would be great!
Meanwhile, you may want to try (if you are not doing it yet) to read with a bigger buffer instead of doing multiple reads. In my case this helped a great deal.
Posted 4 years ago # -
my guess would be that its because the SPI port on those cards is crippled. The high speed port is actually SDIO, not SPI. It is super convenient that you can r/w those cards over SPI, but I bet to get the supported max speed out of them youd need SDIO. I dont know this for sure.
Maple Native and Maple RET6 both support SDIO in the hardware, but there is not library support for it yet. If you start developing the SDIO libs, let us know!
Posted 4 years ago # -
poslathian - my very quick skim of the SD specifications isn't conclusive.
The 'Simplified Specifications' (which are free) remove some critical pieces of information including the SPI timing diagrams. BUT, the specification does seem to say that there are faster modes which apply SPI. So maybe the SD cards start at a standard low-speed, then the host and SD card have a negotiation process to choose a higher speed (there seems to be commands to support some of this). It may be that there library doesn't negotiate a higher speed, or the SD card and library fail to reach an agreement.
The 'Simplified' specs isn't very pleasant to read, and I am not certain they explain enough to do a better job. I assume there is some stuff somewhere explaining what is possible, but I haven't found it yet.
(health warning: it was a quick skim of the SD spec, and the 'Simplified' SD specifications, e.g. Simplified_Physical_Layer_Spec.pdf has been somewhat crippled)
Posted 4 years ago # -
Thanks guys!
I have been trying to optimize the library over the last couple days achieving (very) minor improvements; I am still very far from something close to the specs of the SD cards in terms of speed. I'll keep to it for a while longer to see if I can make some more progress.
So far, the thing that help the most was to make Sd2Card class inherit from HardwareSPI. That way the class itself initializes with the SPI and that saves some time. Overall, though, this only improved the speed approximately by 8% on the first read (when the spi connection is initialized) and around 1.5% for further readings (I am measuring with 500kB files). So, no big deal. Other things that minimally (to the order of less than 0.5%) helped were to initialize and operate the chip selector pin with atomic functions (gpio_write_bit and gpio_set_mode).
I am currently looking at the file system part to see if there is something there that could potentially slow down the operation of the card. As poslathian suggested, I might also look into using SDIO (since I use one of the RET6 boards). However, I have talked to people who achieved better results with an AVR micro reading SD over SPI so I suspect that there is room for improving the library as is (hopefully). We'll see if I can figure it out though...
Wish me luck ;)
Posted 4 years ago # -
polpla,
good luck! do keep us posted, and be sure to send us any pull requests you think we might want to merge in.
Posted 4 years ago #
Reply »
You must log in to post.