Tag Archives: PIC32

SSD1963 now available in VGDD 5.1

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

I’ve had a few conversations by email with the author of VGDD. He has quite good English knowledge and we’ve come up with a few background similarities that has made it pretty interesting to discuss the product here and there. A few times I’ve mentioned something I’ve done by modifying some of the files that came with the program or discussed something I’d like to see and it turns out he just did it in the next version he’s releasing in a day or two or intended people to be able to do what I had done in a future version that could fully support it easily.

Most of the time we’ve talked it’s been because I’ve looked at the PIC32 sitting on the table and I keep thinking of how I really need to get that touch screen going. I then sit down and update the program and end up building a bunch of screens and compiling things and discover a bunch of weird little bugs and he quickly fixes them and releases a new version.

A couple nights ago I roasted 4 batches of an Ethiopian coffee and found a couple more glitches in my Arduino roast profile and the cooling cycle but it’s getting better. It got me thinking about VGDD again, which I had upgraded to 5.0 a few weeks back, and it turns out there was a 5.1 version now. This time he’s now included TechToys Ultima R4.1 board that includes an SSD1963 controller on it. If you haven’t looked at it before this board accepts a Microchip PIC32 Starter Kit board and has a variety of other things built on such as the SSD1963, an MP3 Decoder, a footprint for a wireless network card and a few other connections. Combined with a 7 inch touch panel it’s about $139 + tax right now.  It seems to be an excellent product but I just think that it was a move in the wrong direction to squish so much into one board. Instead I would have rather it been made to be modular to let you enable/disable sections of it to use those pins in your own ways. I’ve been using the SSD1963 EVK 3B board hooked to my PIC32 expansion IO board for the initial testing I’ve done.  It ends up around $99 w/ a 7 inch touch screen.

My early little touch screen using Microchip brand boards was a lot more money and to get a 7 inch screen today with the new Epson controller would be about twice what I spent for the SSD1963.  The original little screen was pretty good to see what the roast was doing when I first started trying to build a coffee roaster but it was just too small.  This is why I started trying to build a 7 inch touch version of my roast controller which allowed a whole lot more to be done on the screen.

While I had gotten the SSD1963 working in some of the older VGDD versions by hacking the XML files I was not having the same luck with 5.0.  With version 5.0 of VGDD I kept getting errors when I compiled and had issues with the screen not working as I expected when I finally got it to compile and I didn’t have a lot of time to work on it.  Seeing SSD1963 in the Ultima board being supported in 5.1 I figure I just need to ensure I configure the wiring from the EVK board I have to mimic that of the Ultima board I should be able to get it to compile.

Lately (on the Arduino side) due to some changes with the serial output of the project and my attempts at adding more functions to the processing GUI I’ve found that I’ve managed to break the PID/LOG communication to the processing GUI and forgot to commit a copy to my home code repository server and there’s too many changes to really figure out which area got messed up without a lot of work. As a result that lack of visualization is really starting to become an issue so I’m really going to start trying to develop the PIC32 side more to at least process the output of the Arduino and run the touch screen to display it all.

I’m oncall for work this weekend but I hope to be able to verify the wiring with the Ultima schematic and make sure I cable up the EVK board properly and get a screen or two going again using VGDD. I’ll post the wiring info once I get it going.

Pretty on the outside and ugly on the inside prototype

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

So I’ve been busy doing a bunch of computer maintenance and looking into other things I’ve neglected while building the roaster so it’s been a bit slow.  I decided I wanted to start gluing corners together and drilling some holes to see how the case goes together so I can eventually get back to fixing the issues with the roast controller case.  Over the past several weeks I soldered together all of the boards, made wiring harnesses and figured out a bunch of “oops” moves I had made designing things when I got rushed for time.

Turns out I was not able to get stand offs locally in the sizes I had wanted so the heights are all screwed up where I placed holes on the outside surfaces.  I also forgot to specifically allocate power for the exhaust fan in the original design BUT I did have “Spare” pins allocated. The fan I ordered also was not the right size for the hole template I had used (Inside fan dimension vs outside screw / case dimension)… neither of them were actually labeled right the way every other fan I have is sized.

So with everything screwed or harnessed in place this is what I have for the Arduino…

The Arduino wired for Coffee Roaster control

It is a MEGA2560 mounted on a Crib for Arduino.  On top is an Ethernet Shield w/ microSD slot.  Then I used a variety of crimped headers to connect to some of the pins on the MEGA and on the ethernet shield.  I have twenty five lines in the bundle going to the Arduino.  I had some spare 10 strand cables from a project at Halloween and no 25 strand cables to use so I used one of those cable wraps to keep the all together after connecting DB25 to one end and header pins to the other.  Once the lid for the crib for Arduino is in place it then connects to the back of the enclosure.

Wiring Harness connecting to the back of the controller enclosure

As you may notice the sockets I was using for connecting the power out are the type that snap in.  The majority of these will not snap into most laser cut plastic sheets and instead are designed for aluminum cases.  The plug to the right on the other hand screws in.  These work great with a variety of thicker locations.  The fan was originally going to be on the inside with a wire cover on the outside but with the wrong size fan hole in use I had the wrong cover to fit the fans that I had that would fit the hole.

For the DB25 connectors it turned out good that I had decided to use a cut out pattern  that had the holes on the side for the anchoring hex nuts rather than just having them cut out so that I could mount them to the socket and anchor the connector.  Since the stand offs were too short they don’t allow me to anchor the PCBs to the bottom plate.  Instead I had to screw them to the back plate using normal screws and with the burnt circles on the laser cut work I had to use some washers too to keep it sturdy.  This is what the back plate looks like.

Rear Panel of controller

This panel includes – One non-filtered switched 15Amp Power Entry module, 2 snap in 15 amp convenience plugs, 1 5VDC fan, 2 DB-25.  The left one is the main guts for the LCD, TRIAC control, potentiometers, thermocouple, and a variety of other sensors.  The right includes all the non-essential stuff for backlighting all the buttons on the button pad and a few other things including spare wiring.  You cna see just a screw on the right since it was relatively intact and so it won’t block the DB25 plug being used.  The right DB25 has washers and screws in place.  These are primarily used to attached the PCB in place attached to the back side.

Next up is the inside view of the electronics area:

Rear View of the Back Panel

Rear view of the back panel.  I need to shrink up the crimp connectors around the wire  (they shrink like heat shrink tubing but is actually much firmer).  Also the connector on the right side (the switched power entry module) should have the screws more securely fastened with nuts and washers but this is mainly just a test to ensure it all fits together and then allow me to focus on some programming for a while to see if I can get more working and develop menus etc.  The clear acrylic bar is used to anchor the corners better.  I need to change the locations of the screws since I could not find screws the size I wanted without spending way too much for large quantities of them on the internet and having them shipped to me etc.  The thermocouple board on the right had the same issue with the stand offs so it is just floating loose in there right now.  I need to find somewhere to get the Omron thermocouple sockets where I dont need to order them by the 1000s since it looks like Ryan McLaughlin has stopped selling things on his site when they (used to) have problems getting the newer MAXIM thermocouple chip.  They’re all over the place now but he hasn’t restarted his store up so I don’t know the deal there.

Here is the view down into the enclosure from above:

Top view into enclosure

With the cover on:

Front panel installed on enclosure

Front panel running

Front Panel Running

When I send it back out again for a new case I hope to have a different board to install that will be switching the smaller breakout boards being designed onto the circuit board as well as add a power supply and possibly having an arduino board mated on top of the circuit board perhaps to bring more of the electronics inside.  I might want to try to get a Digilent board perhaps to try converting to it as a transition between Arduino and PIC32 before I completely switch to a dedicated PIC32.

I’ve also been looking at possibly creating a dedicated PC application to communicate with it directly via USB and over ethernet.  I am toying around with the “QT/QML” language but havent gotten too far with it.  I may just go back to Processing though.

Ahh the smell of progress… roasting coffee!

By | | , , , , ,
Leave a comment

So as I mentioned yesterday I roasted some coffee.  This time (except for manual control of the fan) the roaster did it all by itself.  I had given it a handicap of limiting power to the heater only to 85% of the capacity but it appears to have worked ok.  The Arduino roaster controller worked well enough considering the state it is in.  Power control from the Arduino worked for manual potentiometer signaling the fan speed and a data array of settings for the heat controlled the roast automatically trying to maintain the temperature.

I’m going to increase the power again to 90%.  The room temperature was around 45-50 degrees since I roasted it out in my garage so I think it did pretty well getting to temperature.  I’ve also bumped the fan up slightly to a higher maximum.

I will need to get a button controller going soon so that I can force the system from automatic into manual mode so I can quickly shut down heat if necessary without having the laptop connected while letting the fan continue to run.  I’ve got a CAD type design of a PCB going that has a button controller but I haven’t ACTUALLY prototyped it out on some RadioShack boards.  I do have some etch-able boards here to try a toner transfer to build out some controls.  I still need some carbide drill bits though for drilling the through hole parts and the jumper connectors.  If I had SMD header pins I think I actually have all the parts I’d need to build a 6 or 7 button analog pin matrix.  I may need a couple more resistors though to pull that off.  I’m pretty sure I could get at least 4 buttons though.

The power control system had started to get out of control with the heat sinks so I had to beef it up some.  Before anyone says it I know the large heat sink is on upside down.  I didn’t want to drill the board before I was sure it was going to work so those bottom pins are sticking out the top.  I’ll probably run it like this for a little while until I make a permanent board though.

So for those of you keeping track… I went from this:

First working prototype in Radioshack Project Case

To this:

This is MUCH better for the following reason…heat sinks got out of control and all the wires were getting obnoxious:

Next Steps?

  1. Increase allowed power to heater
  2. Make button control pad.
  3. Tune PID.
  4. Improve CSV log system.
  5. Add automation to the Fan control.  Use mild PID triggered adjustments to the fan.  Coarse heat changes by heater.  Minor heat changes (a few degrees) by Fan.
  6. Add current sensor to judge wattage to the heater.
  7. Get profiles loading from SD memory using button pad to select them.
  8. Begin creating circuit to connect my original PIC32 project to the arduino over serial / rx/tx or other communication method.
  9. Complete 7 inch touch screen (I have a screen designed but it’s not entirely stable yet… the backlight flickers occasionally and the image stutters here and there but it’s there…)  I’ll upload a bitmap from the layout tool soon.
  10. Migrate most functions to PIC32 eventually.
  11. Build a final PCB.
  12. Get a case made for it.
  13. Roast lots of coffee.
  14. Brew it.
  15. Drink it.

Arduino roaster controller with zero crossing dimmer

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

With all the time I’ve put into the Pic32 roaster I’ve always had this nagging worry that any of my sensors may have had damage during testing. When you try to get something working and keep getting gibberish you need to find a way to rule that out. As a result I decided to purchase an Arduino a few months back to confirm everything works. Turns out (so far) that everything IS actually working and I didn’t damage any sensors.  In the months I’ve been working with the Arduino I’ve actually learned a few reasons why some of the sensors didnt work on the PIC32 the way I had programmed them because learning to program an Arduino is sooooooooooooooooo much easier and better documented for “average people” to figure out compared to reading the hundreds of pages of technical manual for the PIC32 that isn’t ACTUALLY even finished being written yet.  There is a ton of code out there to test every single sensor I’ve purchased so far on Arduino. In addition I decided it would be a great way to start the dimmer using zero crossing detection in a system that runs outside the PIC32 before I convert it.

My intention is to get basic functions working on Arduino, then get the PIC to talk to the Arduino to send it commands to switch power by itself while the PIC reads all the sensors and logs data and then decides what to do as it comes from the Arduino.  Finally it will eventually be migrated entirely to PIC32 when I learn more about the interrupts on PIC32. At the moment I’ve put together a board that takes in 120VAC and uses Q4015L5 Triacs and MOC3052 drivers to control power to two receptacles. It reads the zero cross on my power using a H11AA1 and gets an interrupt used to trigger power switching. During my initial testing I confirmed the zero cross detection circuit worked and switching the triacs manually on or off worked without  regard to the zero cross state. It unfortunately didn’t seem to actually switch automatically for some reason when I wanted it to dim.  After a few days of testing I realized the Arduino Mega and the Uno had the interrupt timer pins in different places.

Since this is the first mains power circuit I’ve worked on I started running it with a variac out in the garage (and then fed that out into the driveway at the end of an extension cord…) and gradually turned the power up from 0 to 120VAC testing each section as I built it to ensure nothing arced or got hot or burnt up.  During late November I hooked it to the Arduino and got it to begin adjusting fan and heater under PC control as well as using two separate knobs.  Later in December and January I got it to begin logging to SD memory and following a programmed profile.  After that I added a bunch of additional environmental sensors and mounted it in a RadioShack project case.

 

First working prototype in Radioshack Project Case

I’m now at a stage where I’m looking to consolidate the various sensor cards either down onto a circuit board or attached to a set of pins directly.  I’ve grown tired of accidentally unplugging random wires carrying it back and forth from the garage to my office area and out to the kitchen stove / vent at various stages.  My hope is to shrink it down to a much less complicated arrangement being mostly on a single circuit board and interfaced by a few short cables to the Arduino.  It’s a bit complicated currently and getting worse.

Jumble of Arduino stuff

For the Arduino I’m using the MEGA 2560.  It is attached to the power control box pictured above via the DB25 cable.  At this time the box only controls power but I’ve mapped out pins on the DB25 to use for future boards to allow sensor breakout boards from a variety of DIY electronics companies to plug into them.   I’ll break this out to various header pins that match various breakout boards so they can be directly attached.  I’ll probably also design positions for eventually soldering chips directly to a board later once I order them when I’m further along and jumper the headers into those sections.  This will let me test a circuit on the board while still ensuring it actually works with the breakout board first.  The board will be designed to replace the items in the RadioShack box using SMD parts in some cases where cheaper and more convenient to shrink the board down smaller.  I hope to have it all shrunk down and consolidated to a single board with a DB25 connector to get to an Arduino I’ll be mounting inside an Arduino Crib case.

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.

Ordering…7 inch LCD using SSD1963 graphics board.

By | | , , ,
2 Comments

So I’ve decided that the regular Microchip development kit LCD touch screen it comes with is fine for watching results on but ultimately it stinks if I need to interact with the roaster at all.  The only way I’ll get away from this is to order a kit with a 7 inch LCD using SSD1963 graphics controllers.  Why?  One of the issues is really that I would need to interrupt the normal processing and switch control back and forth between various screens.  The PIC would then need to keep tracking the updates and logging them in the background but drawing anything I missed when I eventually go back to the other screen.  This would need to take place regardless if I did leave the screen during a roast but I’d rather keep an eye on everything while I’m changing things in a different portion of the roast control screens.

So to do this I’m attempting to use an SSD1963 graphic controller chip to squeeze a little bit more resolution out of things and going to send it to a 7″ touch screen module that I have on order.  I know there are plenty of projects out there that have demoed a 7 inch touch screen and other 640×480 and 800×480 LCD outputs driven by a PIC32.  MOST of them people keep trying to run video or turn the thing into a full resolution JPEG slideshow.

Everyone pretty much goes on and on about how a PIC32 can’t run much screen and it takes too much time to draw the screens.  Those that tend to say these things keep trying to get the PIC32 to stream video from somewhere which it is not the right kind of system to try that on.  When it involves only drawing graphs and buttons and text responses on the screen the system seems to run just fine in my opinion.  The way the graphics library seems to work these sort of updates are drawn in small sections.  It tells it to go to this position and draw text.  Go here and draw a line.  Go over there and put a dot.

My hope is that once I manage to convert a driver that works with the graphics library and get this thing up and running I can plan out which areas of the screen to update and find an acceptable balance and end up just spreading things out and enabling a few controls so that when I’m reviewing past information and configuring the upcoming roast it shows more resolution and then when it runs live it uses only what it can produce quickly on the screen.

I also think I need to start considering what sort of enclosure I need to use for mounting some prototype stuff into so I don’t have a pile of circuit boards spread out on the counter.  I’ll be needing to use some high voltage stuff soon so it’s safer to firmly mount connectors to a board and then safely mount a circuit board in a way that those ends won’t accidentally be bumped into.  I’m not sure where to begin with.  Obviously I’ll need to find something that I can purchase in single quantities.

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.

User interface work.

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

So at this point I’ve gotten annoyed with the other temperature sensor and decided I might as well move ahead with the functional part of the roaster.  This means the first thing I needed to do is draw a main menu for options.

Main Menu

As you can see this lists Manual and Auto Roast.  My plan is to make it where the first option simply gives you a few readings and then lets you “drive” by sliding the controls around.   I would make it log the information of what you set things to and what you got back from the system and perhaps let you “store” the settings to play them again as a profile.  That is where the next phase comes in, the Auto Roast.

I expect Auto Roast to be a portion of the system that would let you choose to either A) load a previous profile, or B) let the roaster pretty much run itself using a basic model of “drying” at a lower temperature for the first few minutes at a high fan speed and then begin to lower the fan speed and raise the temperature responding based on the time into the roast vs the temperature.  Expectations of driving first crack and the end of the roast based on a desired result would vary how it would work.  I’d anticipate some sort of yes/no 1/2/3/4 etc sort of question and answer series immediately before the roast activates.  While it would be mostly automatic you can step in at any time and seize control of a particular setting.

Main roasting screen

At this time the roasting system only monitors.  I have yet to work on actually connecting it directly to any of the controls on the roaster.  This will come later when there are more and better controls implemented.  Currently it simply shows bean temperature in Fahrenheit.  I will add the option to switch the temperatures on the Settings option from the main menu.  It also has a slighly inaccurate timer.  It seems to gain a second or two over the system clock in the corner every 40-60 seconds.  I need to work on the prioritization of the interrupts in the system and implement a series of if/else and/or case statements where I can service temperature, screen updates, and time tracking and use all of those checks as part of the delays required reading various sensors etc.  For example if it takes 100ns to service one sensor telling it to read a temperature or something but I need to wait 100ns to do another function then I can initiate the read request, perform the other function, and then return at the end to pickup the temperature result.  Some functions are more critical so they will take priority over other functions.  Those functions will take place on a tighter schedule while the other functions will “squeeze in” anywhere they can and take place based on a “true/false” tracking of whether they’ve run recently.  Once everything has run then everything will reset and things will start looping again.

The roast control system also has a series of buttons down the bottom for returning to the main menu, adding or removing time from the timer, as well as buttons for heat and fan control.  I expect to put more sensor readings as time goes on to display on the empty space.  I’m hoping to get the fan and heat controls to pop up over top of the roasting screen, allow adjustments, and then drop back to the bottom “tray”.