Tag Archives: SD Memory

TechToys SSD1963 eval kit on a PIC32 I/O Expansion Board

By | | , , , , ,
Leave a comment

Now that I’ve gotten all the leaks taken care of on my new aquarium I decided I should at least figure out if the new SSD1963 eval kit with 7 inch 800×480 LCD that came from TechToys. com.hk works. Officially it is listed on the site as SSD1963EVK-R3B + 7″ WVGA color TFT with Touch Panel Part #: SSD1963EVK-R3B-TY700TFT and as of July 2011 was listed as a bundle price of $119 USD plus shipping. This includes the LCD, SSD1963 board with a cable between them, and 40 jumper cables.

This kit is intended for a development board created by TechToys that fits the connector perfectly. On that board you can then place a PIC32 starter kit. For my purposes this is not usable because I do not need the devices on that board such as the MP3 player. I also need to add a variety of I2C and SPI devices for sensing environmental conditions. For my project sticking with the PIC32 I/O expansion board is the best bet.

I decided I would leave the original breakout boards attached and wire the LCD and graphics chip on. I removed the Microchip Graphic boards from the side and popped out the riser card. To properly find the wiring you need to use you need to consult both the schematic for the Multimedia Evaluation Kit for Microchip PIC32 Starter Kit and the Evaluation Kit for SSD1963QL9. You are looking at the diagrams for MCU interface and SSD1963 EVK Interface. What you will find is that not all of the pins are diagrammed through to both sides. They need wired through though and the correct connections can be determined elsewhere on the schematic. Wire everything from the SSD1963 EVK Interface diagram and then add onto it the Reset, LE and other pins. Once you do this you end up… with a mess:

Then I began the process of trying to compile the modified MultiApp Demo. I selected one of the hardware profile includes for the 7 inch LCD and SSD1963 that involved a PIC32MX795 and tried to compile it. I’ve read about people potentially having to modify when using a Graphics Library higher than 2.0. Turns out this was not the reason I had errors. Instead I needed to fix the driver file because it mentioned parts I was not using and didnt match the name of the driver. I commented out a few lines and uncommented the lines that matched the actual names from the driver. It reports not having a compatible Controller prior to that and worked fine following that. However, the tech toys modifications stopped other graphic apps from compiling so you need to do a diff comparison to figure out changes necessary to newer libraries.

Once the lines were commented out I compiled, uploaded and launched the app. Success was short. Within a few moments I realized while pressing around on the touch screen calibrating the corners and pressing to save the calibration I noticed that the program didnt continue any further. Stepping through a debug I noticed it was at a point waiting for the EEPROM to respond. That’s when it hit me. TechToys sells a development board which happens to include an Atmel SPI EEProm. On the Microchip boards this is found on the graphics board because they expect you to change graphics boards potentially with your own and they supply it on their graphics board.  For TechToys it’s on their development board and not with the graphics boards.

Upon removing the microchip boards I thus no longer have an EEPROM. Upon playing around I found that pressing in the upper right corner instead of calibrating results in the board eventually skipped the write and reload of the calibration and jumped to the home page though I had issues reproducing this reliably. Ultimately just to test it working I ended up triggering buttons about 2/3 of the way from the bottom to trigger the lower buttons and then gradually moving up until it selected another item.  The various graphical items displayed and I managed to get some of the apps to launch though not be able to control them very well.  All that mattered to me is it technically worked as wired.

From what I can see there is an acceptable write speed to the LCD for setting up a coffee roaster control screen but I will need to test further once I can store the configuration data and switch to the original roaster program on the larger screen. I’m thinking I should actually be able to store this to a file on a SD memory stick instead of an EEPRom. Both are SPI but will require a different process to read/write but there’s been others who have done so without much issue into a config.ini file.

More logging… and floating math.

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

Two nights ago I managed to finally get the screen that shows graphs to draw the current temperature up in the corner on top of the graph.  Most of the problem was figuring out how to convert the “float” numbers to characters.

I needed to feed this into Microchip’s Graphics Library and accommodate “unicode” characters to get the “degree” symbol on the screen eventually.  Instead of typing a string as string=”Hello There”; it ends up being string={‘H’, ‘e’, ‘l’, ‘l’, ‘l’, ‘o’, ‘ ‘, ‘T’, ‘h’, ‘e’, ‘r’, ‘e’}; which ends up being an array of character values.

A float is a decimal number.  In this case 3 digits for hundreds, a decimal position, and 3 more digits for numbers.  The sensor is kicking out two digits and I’m adding readings together, averaging them, and then rounding up or down with the extra positions in some places.  The PIC32 unfortunately does not have a floating point calculation area in its brain resulting in it “compensating” for it by automatically sliding all the other numbers around using complicated things called mantissa and a few other things I really don’t want to deal with.

The reason I don’t want to deal with them is actually NOT because it is complicated (which it is) but because since it is compensating when you divide a float it has to do MANY cpu cycles for it to compensate and come up with the answer.  It is ACTUALLY easier to multiply the float by 100, 1000, 10,000 etc and insert that number into an integer data type.  Integers can be divided, multiplied, subtracted, etc without worrying about how the numbers line up and doing crazy compensating.  They just don’t end up with a decimal.

If you have a temperature of 175.25 degrees fahrenheit you multiply it by 1000 which equals 175250.  This maintains all of  required digits as a whole number and gives extra space for “rounding” down below.

The issue with the graphics library you need to use a font for every character and take into consideration symbols like degrees etc.  This means it is not simply just a “character” but you need to allocate for all the extra stuff.  This results in a larger space for each character.  To me it looks like a single character in XChar is actually two positions instead of one to leave extra room for the fancy characters to be allowed for.  To convert text strings or float numbers into characters that can be handled by the library you have to load them into an array.  This array to convert the above number (float averaged=175.25)  looks something like this:

int showtemp[8];
showtemp[0]=averaged*1000; //175250

showtemp[1]=showtemp[0]/100000; //175250/100000 = 1 in integer
showtemp[2]=showtemp[0]/10000-(showtemp[1]*10); //175250/10000 = 17.  and then 17- 1*10 = 7 in integer
showtemp[3]=showtemp[0]/1000-(showtemp[1]*100)-(showtemp[2]*10); 175250/1000 = 175 and then 175 – 1*100 – 7*10 = 5
showtemp[4]=showtemp[0]/100-(showtemp[1]*1000)-(showtemp[2]*100)-(showtemp[3]*10); // etc
showtemp[5]=showtemp[0]/10-(showtemp[1]*10000)-(showtemp[2]*1000)-(showtemp[3]*100)-(showtemp[4]*10);

temperaturetext[0]=showtemp[1]+48; // 1 + 48 = 49 = proper number for 1 in character
temperaturetext[1]=showtemp[2]+48;  // 7+ 48 = 55 or proper number for 7 in character
temperaturetext[2]=showtemp[3]+48; // etc
temperaturetext[3]=46; // 46 = proper number for a decimal.
temperaturetext[4]=showtemp[4]+48;  //etc
temperaturetext[5]=showtemp[5]+48;  //etc

 

the results in temperaturetext looks like {‘1′,’7′,’5′,’.’,’2′,’5′}

I roasted twice now using the new graph with actual temperatures listed up top and was planning on comparing the results but I accidentally corrupted the first file.  I’ve got one more batch of some coffee from Rwanda that I was testing with.  I’m getting pretty close to running out of coffee again so it’s time to order some more soon.  I was hoping to have something good from Ethiopia come up for sale but it’s still a little early for that.

Still working on… recognizing temperatures for various(rough) stages the roast is at vs some sort of mechanism to confirm a stage marking things like first / second etc.  Also need to get ambient weather information recorded and get other sensors going on it…. and make it pretier…. and of course get it hooked to higher voltage turning on and off the heat.

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.