Sooo generally annoyed with sensors I decide to take a different direction, SD Memory. Fun things happen with SD Memory. You rip one open and you’ll usually find a single little flash memory chip and some other chip in front of it. I haven’t identified the “guts” yet but that’s not really important. What’s important is that generally you talk to that little flash memory chip using SPI (usually unless you wanna pay for licensing fees to use the direct SDIO method it sounds like. Crazy licensing costs = faster SD Memory. Free method = slow access. If you need every bit of speed you can get then you’ll likely need that expensive method. If you can buffer up data internally and then write it out later then you’ll use the SPI method). This is likely to be preferred to have a built in memory chip to buffer items up just like working with a document on your computer. It then isn’t until you save the file that it then transfers it from the internal memory out to the SD memory for transportation to the PC.
There is not much to it other than that except for having some structures that issue a few reads and writes to find a spot on the chip and make a file name and fill the file full of stuff. That portion is the “FAT” portion that makes you able to read it on a computer etc. This slows things down considerably in an SPI Method. Apparently people have experimented with reading/writing to the SD memory chip with no
After a few days of poking at it and moving a couple wires around I’ve now managed to get it to make a file… and I can see that file on a PC. The problem is I can’t get it to put anything INSIDE the file. It just keeps getting stuck on the portion where it’s expanding the size of the file… further it’s been quite a pain that any SD memory sample code out there is written focused on the 3xx series PIC32 and from looking at the various forums my issues are pretty common. Most people get the 3xx series working just fine. Many people seem to get files with no contents on 6xx and 7xx series PIC32s.
The only published successful people I’ve found seem to be commercial product developers who don’t want to share any code samples clarifying how to handle the failures properly. The only exception I’ve found was some code modified by the user bmorse on mypic32.com. His code appears to be modified to work specifically at 60mhz and using SPI2 which worked for initial testing to ensure I had things wired properly. I needed to put a pull up resistor on the CS and the DO of SD to SDI2 on PIC32 and everything started working properly.
I’m now trying to isolate the portion of the code that affects the timing to increase the system speed back up to 80 mhz and scale the SPI back down again. To assist in this department I’ve procured a FT232 UART to USB Com port chip on a breakout board from SparkFun. This board is commonly used to take the UART output of various text and data from the running PIC and interact with it in the terminal window instead of watching the raw data on the debug watch. I’ve learned that the watch window often “messes up” a lot of SPI states by constantly inspecting the information. The idea is that it interrupts the normal state (data waiting etc) flags due to having read it for the watch window blocking the rest of the circuit from detecting it.
I’ve also obtained a DS3234 clock. At time time I only have the one I2C DS1307 clock and I may wish to eliminate the I2C bus unless I come up with something else that needs it. Even if I use I2C elsewhere it seems as if 5 volt I2C is more of a rarity meaning I can’t really use that bus for other things anyway.