Tag Archives: UART

Writing to SD memory…

By | | , , , , , , ,
Leave a comment

Soo… the latest update… I had wired in the SD memory stick reader and had been testing it separate from the main roaster program. I’ve found having a “dedicated” programs for a particular sensor with the rest of the sensors and displays attached but not initialized has resulted in easier testing and troubleshooting.  Occasionally it works right away but other times conflicts come up.  Generally once I have manage to confirm it works without the other code running I at least have a reasonable assumption that it may actually work and is wired properly.   Since I’m pretty new to the whole wiring these things up it’s a pretty good idea to test my wiring out.  So far I’ve actually done pretty well reading enough about each sensor to figure out what I need to make it work the first time.  If I go too long not getting it to work I try to disconnect everything else and run it by itself which usually helps me identify conflicting pin usage that I didn’t see initially.

So far I tend to find issues with the LCD interface / graphic chip / memory config chip to conflict with a particular pin here and there.  If it works without the LCD boards attached it obviously has a much smaller number of pins from the new sensor to try to find a conflict with. Usually by the time I isolate the LCD away from the system I’ve managed to throw together code that works within minutes of starting things up again.
My last success with the SD memory was short lived because I discovered there were pins that I had not noticed on the SSD1926 that apparently do something even though I’m in 8 bit mode instead of 16 bit.  They seem to have ended up being connected when I was trying to check my Write Protect and Card Detect pins.   It took probably about 3 hours of looking at the schematic for the graphics board assembly to figure out which wires (15 minutes) it was and then find some (the rest of the time) that were not being used already.   Since I am using 8 bit communication instead of  the 16 bit mode I would have assumed them to be “dormant” and potentially available.   Not quite sure what is going on with that since I have not obtained the data sheet for the SSD1926 chip yet.

I had an unexpected guest show up early in the week and didnt get much time to work on this.  After making a few adjustments to the wiring I got it up and writing to the SD with the LCD attached.  This weekend I got it loaded inside the Coffee Roaster programming.  I ran into a few initialization problems that resulted in a momentary “stream of gibberish” coming out the UART port that I was using for watching status of some of the code I was troubleshooting with in a terminal window.  It seemed as if the system had a baud rate to the com port of the computer that suddenly “shifted” up and down a few times in the middle of the machine starting up and then returned to normal. After I removed some of the apparently duplicate excess code from the init area it resumed working normally.

I then had to move the “write to SD” down through the startup past the time and date retrieval area.  This results in accurate time/date stamps on the file now being written to the SD memory card.  I then began to modify the SD demo write into a command that builds the buffer data using a sprintf template inserting date and time on a line separated by commas and a few sections (with 0.00’s right now) for sensor data as well.  I’m going to bundle the write commands up into a function so that I can insert it into roaster loop as a external function.  Every time it samples the temperatures and other future sensors it will shove it into the call to the “write to SD” function where it will get formatted and append to the file it created during the initialization of a new roast loop.

As I said, I havent had much time to work on it this past week but probably tonight and tomorrow I’ll get significantly closer to figuring that part out and probably test running the roaster with nothing in it just to get some temperaturee logging as it goes up/down for a few seconds and then exit the roast to close it to check the accuracy. Then when I’m sure that’s working I’ll try to do a regular roast with it out in the kitchen and see if I can get “good numbers” that I can post.

If I can get that working then the next step will be to get a “file management” function going to come up with names of files to make them unique and maybe let me load the data into the system to preview it on a graph on the PIC32 LCD as well as delete files. THEN I get to start figuring out how to program it to control things by itself based on my normal data.  😀

Close Encounters of the SD Memory Kind…

By | | , , ,
1 Comment

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.