Graphing Temperatures from the MAX6675 on PIC32

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

Turns out graphing temp data is pretty simple.

Using the standard Graphics Library from Microchip just to display the output right now. Ultimately it’s working pretty much as necessary to show temperature graphically. I need to be able to adjust the top/bottom a little better using some formulas to come up with a scaling percentage dynamically to make it fit the minimum and maximum possible temperatures into the display without squishing it too much. Additionally I need to decide how quickly to scroll from left to right and possibly a way to redraw scrolling backwards to see starting graphs and archive the raw data to be reanalyzed later possibly zooming etc.

The input to the system is using a development board by Ryan J McLaughlin (dot com). The board was designed to be connected up to Arduino microprocessors but I figured out it could be plugged up directly to a PIC32 too. I decided I needed an easy to interface board with a thermocouple socket already on the board and this one fit the bill nicely.

image

Right now it blinks the status LED every time it makes a reading which is somewhere around 2-3 times per second.

MAX6675 with PIC32MX795F512L

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

As I mentioned earlier I’m using the USB Starter Kit II, the PIC32 Expansion Board, the SSD1926 PicTail Plus board, and a Truly 3.2″ 320×240 LCD display board to develop the roaster system. This has resulted in some “fun” trying to figure out which pins are really going where on the board and the PicTail cards that you can build your own circuits on. Occasionally some of the pins are not exactly labeled the right way or else there are a few pins that are wired together on the circuit boards making you unable to use one of the pins that are wired together or in some cases both cannot be used etc.

I’ve been working through various demos and trying to understand some of the libraries and still trying to identify all of the pins on the expansion board that are already attached to the LCD / graphics chip. So far I have not found any that involved the SPI1 Pins, which I’m sure is incorrect now.

I’ve now managed to get real time readings to occur while using SPI2 instead of SPI1. Originally I was using pins B2 (SS1), C4 (SDI1) , and D10 (SCK1). to communicate with the MAX6675 thermocouple. When the system launched it would begin to read temperatures from those pins properly but only while in animate debug mode. As soon as I would let it run in full speed to get to a break point later it would be partially or completely erroneous in the received readings. I’ve now switched it to the SPI2 pins and using G9 (SCK1), and G7 (SDI1). (The MAX6675 does not use the SDO pins since it only transmits readings and does not receive using SPI data)

I’m now opening the SPI port to communicate with the MAX6675 using 16bit word mode:
OpenSPI2(SPI_MODE16_ON | SPI_SMP_ON | SPI_CKE_ON | MASTER_ENABLE_ON | CLK_POL_ACTIVE_HIGH | SEC_PRESCAL_8_1 | PRI_PRESCAL_16_1, SPI_ENABLE);

[After I clean up all the “Dead code” that I’ve been testing various things with I’ll insert some additional SPI stuff HERE]

Which appears to work properly talking to the MAX6675. Further I’ve gotten the text to display on the screen of the current temperature where it runs a rolling average of the last 3 readings updating the screen after each additional reading. At the moment it flips on one of the starter kit’s LEDs based on the temperature when it needs to heat and turns it off when it’s reached a preset temperature.

I need to work more on getting the LCD display to show the activity that is going on in terms of heating/cooling and run a timer to begin estimating what stage the roast would be in based on temperatures and time-wise. Additionally I’ll need to figure out how to graph the temperature across the bottom of the screen too. I’m thinking screen real estate is somewhat limited so I may want to upgrade the LCD to the wider board to move some of the data to the side leaving a larger graph area to represent the roast curves.

I’m not dead… And finally having SPI progress.

By | | , , , , ,
Leave a comment

So with all the holidays and other things going on I didnt get to spend much time working on the roaster. In addition due to the complications with the SPI not working all this time I wasn’t feeling very motivated.

Last night after spending hours over many days reading blogs of people who regularly participate on Microchip’s forums I finally managed to get the MAX6675 to start transmitting actual temperature data to the PIC32. I’m not entirely sure why it works now but need to emphasize that it only works OUTSIDE my prototype roaster programming. In other words it is literally a single purpose program that reads a single temperature value from the MAX6675 chip.

It seemed almost reliable by reporting similar temperatures most of the time for each reading for air temperatures and then goes up when I press the thermocouple against my hand and then drops significantly when I press it against a cold soda can. There was a rare spike to 120 plus degrees here and there but infrequently. Otherwise the temperatures appear to be pretty close.

When I return to my roaster program there appears to be something significantly wrong with the speed it communicates with a potential “shift” to the left. If I drop off several of the rightmost (0) bits the resulting numbers are what they are supposed to be with a random wrong bit mixed in. About 60% of the time the results are completely erroneous no matter what. I’m pretty sure now that there is a setting somewhere affecting the communication speed that I’ve lost track of that is disrupting things.

I’ve found that adding some longer delays around the CS changes seems to make the temperatures returned significantly more stable eliminating the 100 plus degree spikes and need to try them out in the roaster code too.

Ugh… they really should sell a manual for this thing.

By | | , , , , ,
Leave a comment

On my way through the I2C problems I downloaded the PIC32 Family Reference Manual from Microchip. I was looking things up and it wasn’t so bad due to it being broken into different sections. There was one section on I2C so I mainly focused on it. I then started figuring out that perhaps it would be nice to search around for things across the whole manual. At that point I discovered that you cannot join each chapter/section together to form a big master PDF file.

I then started considering actually just printing it out instead but realized it was kind of big. I then decided I wanted it to be bound together and began looking at Staples to have them just do the whole binding thing into a single book with a stiff cover on it. I started uploading files one at a time (because they don’t have a bulk upload function)… and then discovered that they don’t have all the chapters/sections written yet. There is probably like 4-5 sections that simply don’t exist. You have no idea what they talk about because there is no master index yet. Reading through the manual there are sections that have been revised in 2007, 2008, 2009, etc. They’ve been working on writing the manual for almost 4 years now and STILL are not done yet.

I decided if it wasn’t complete I wasn’t going to take it to Staples and have them bind it together. Instead I’ve now been printing it out for the past few days on my laser printer and binding it using those plastic coils. I’ve now made it to section 20 printing duplex pages. I think there’s about 10 more sections to go. It’s getting pretty close to a ream of paper it looks like. I’m going to do the 5/6/7xx family data sheet too I think since I reference that a lot. That’s another 230+ pages (130ish double sided… not sure the exact number of pages it is off the top of my head)

I’m also considering getting the pin out graphic (or making my own) and colorizing it and having it blown up to print on a wide 30-40 some inch color plotter. It’s really difficult to program all these things without looking up which pins are being used on the starter kit. It’s FURTHER complicated not knowing how the starter kit hooks to the header pins and the various accessories. There also seems to be several pins that probably do not connect at all making things even more fun!

I’m “taking a break” from coding for the moment. I’m trying to use SPI to get it talking to one of the temperature sensors. I’ve got it initializing the SPI area and it SEEMS to be talking to the sensor. I had worked on another sensor earlier and it downloaded calibration data from the eeprom but none of it seems to mathematically make sense. Everything seems to be off pretty significantly. The only thing I can think of is I’m off a few decimals or something somewhere in the process. I think I really need to start printing out more sensor data sheets and start comparing them side by side with the manuals for the PIC32. There is something wrong with the reading process where it seems to hang sometimes and not others. The eeprom read comes back with the same numbers each time when I randomly bounce around in any order so it SEEMS to work but I can’t really get anything usable out of it yet.

I also discovered another problem at the end of last month. Apparently on the 30th and 31st of the month the real time clock doesnt show the right date. I can set it into the clock chip and back out. When it goes into the PIC32’s clock it converts it back to a 1. It is my guess now that there is some sort of Decimal / Binary / BCD / Hex conversion problems.

At the sound of the beep the current time is….

By | | , , ,
Leave a comment

So this weekend I consulted with another person on the Microchip.com Forums page about their I2C routines they had mentioned. After reading through their routines I looked at mine and found pretty much nothing different logistically except that he was accessing the bits directly rather than through the Peripheral Library. I scratched my head and modified the open command to use direct bits for the options I was enabling and suddenly noticed I had data in one of the slots with no collisions while running in regular mode that was always empty previously.

I had set the system up with a series of breakpoints to test I2C at full speed in one location and then break at the beginning of another set of data requests after closing everything out and resetting it. I always failed the first request and then worked in the second ones ONLY while they were in Debug mode. The second requests were always empty like the first one when they were allowed to run full speed / non debug. With this piece of success I then duplicated the change into my main routine instead of the initial test one and suddenly I had a full array of time and date filled and running properly.

While getting ready to blog this I was thinking of a title to use. The first thing that came to mind was the “Time Lady” that you could get the current time by dialing one of those XXX-1212 numbers in the phone book. She would say something like “At the sound of the beep the current time is 3:00…..exactly” or something like that. Upon googling to find the phrase she used I found this article. At the tone the time lady will be gone

Unfortunately it sounds like technology has caught up with the Time Lady. She was always there ready to serve us. RIP Time Lady.

Next up figuring out why my time in the CORNER of the LCD (not the memory slot being fed to the PIC32 RTCC) is showing funny things. Apparently there is some sort of Binary/Decimal/Hex/Whatever craziness going on. I need to find all the references and place Decimal to Binary conversions and hooking up SPI sensors.

Progress on I2C

By | | , , , ,
Leave a comment

So I previously had tried to get things working using a PIC24 and had both the thermocouple and a battery backed real time clock interfaced and communicating as well as some other items over SPI and I2C. Over time I decided I needed to focus on the PIC32 due to the memory, speed, and ease of interfacing with an LCD. I thus ordered the development kits for the PIC32 and a series of other parts and started this blog about them since I had to start over.

I have so far had tremendous problems with the I2C on the PIC32 hardware. In addition I seemed to show slightly more success with the other sensors over the RTC chip in particular. The RTC was provided by SparkFun as a breakout board. It does not have the pull up resistors on the break out board so it can be chained on to something that already has them… or else you need to insert your own resistors and power between the holes on the breakout board and the microprocessor pins.

After digging through an old box full of parts scavenged off of computers and an old 32 Port Audio Mixer that was destroyed while I was moving due to falling off the lift gate as I was finishing moving out of an old house I lived in. I’ve managed to create an I2C bus using a ribbon cable with some connectors pressed into it close together. I was then able to use a female header socket with some long pins and plug the DS1307 breakout into it for SDA and SCL. On the second connector I inject power into the other side of a header (the resistors are too thin to make contact in the normal connector for some reason). I then connect the third connector to the PIC32 pins using Female to Male jumper wire. Due to the length of the pins on the female header connectors I am able to clip the probes for a Logic Analyzer to the system.

After trying and trying and changing resistor values etc I was getting nowhere. I measure 5 volts on the I2C pins and with other sensors I could get confirmation of the bus going from on to off occasionally. With the RTC chip I was stuck at on. I had no idea what was happening and finally after several days of banging my head I yanked the backup battery out of the RTC.

Sparkfun claims that they have pre-programmed the time on the RTC and they are thus ready to be used/read etc without requiring time to be placed on the chip to start the oscillator. They also comment somewhere in the pages about how it should last about 9 years on the lithium battery provided blah blah. Apparently this is not entirely accurate. I have stumbled across several people commenting on the system NOT being programmed on their boards. In my case it turns out that the RTC chip simply is “hung” possibly caused by a malfunction of the battery. Upon removing the battery I noticed that it had “exploded” in one of the corners like they typically do when they get old. There was some rusted/acid crusted bits and leakage on the surface of the battery AND on the circuit board. I plugged it in again and ran some testing to it and it appeared to be accepting programming from the PIC32. After going to Radio Shack looking for a new battery I cleaned up the board and installed the new battery. The programming seems to stick now and all is well having provided a new battery. The old battery is currently reporting .8V instead of the normal 3.3v and is generally rusted and fouled up.

Unfortunately this story does not have freedom from flaws. It turns out that while running the routines normally I get results of either 0x0000 or 0x00FF. When I force it to debug mode, however, things appear normal displaying hours/minutes/seconds/date/month/year/etc in the appropriate slots and upon returning form debug mode back to normal show in the spaces I forced it to display the text. Further when I try to program it into a demo program Microchip wrote it seems as if the year is actually the “date”, the date is the “day of the week”, the month is the correct month, the hours and minutes dont make any sense. I’m not sure what is going on there. Taking a wild guess I’m thinking the date/year thing being weird is coincidental and that in reality there is perhaps some sort of Hex vs BCD problem going on.

Since I have achieved some level of success at this point though I am going to do a commit to the SVN repository on my server at home to make sure I don’t lose this code. I can see, with the Logic Analyzer, that the SCL and SDA pins switch from 0 to 5v and 5v to 0v from time to time so I know the pull up is functioning. What is troublesome is that the SCL pin never appears to have a functioning clock signal. Immediately after applying a Start command it appears to register a bus collision. I cannot figure out why this is happening and it further baffles me that I could program AND read I2C data without a functional I2C bus.

I was reading on the Microchip forums about how they, apparently, recently changed the I2C Library on the PIC32 making it function different than the PIC24. This is causing significant problems for PIC32 users. It seems to have something to do with the Idle state not being checked on the PIC32 causing collisions or something like that. How exactly this applies to what I’m doing I’m not sure because while the symptoms are the same it does not seem to follow the same circumstances.

In addition this weekend I obtained some LCD screen protectors (typically used for GPS) and removed the original covering provided by Microchip and installed the new protector. It is a lot smoother and easier to read the screen. I should be able to record the video on the screen without it being distorted once I get the I2C (and some SPI) sorted out and working.

Further shipping… I2C problems

By | | , , , ,
4 Comments

So I received my new order with a few more sensors, memory sockets, and a new set of cables that were Female/Female. Not only did I have problems with the shipping involving the first order going to the wrong city and being REALLY slow…. THIS TIME I purposely switched to FedEx and bumped it to Next Day delivery because I was tired of waiting for things. My package “went walking in Memphis” or perhaps went on safari in the Jungle Room or something. Apparently FedEx had mechanical problems and as a result my package did not leave the Memphis hub until after the time it was already due to be delivered to my door in California. It was thus NOT next day.

Once I finally received it I figured I’d start off with attempting to read the real time clock chips I have using I2C. The PIC32 has built in hardware commands for accessing I2C so normally this shouldn’t be too difficult following the address strings and writing/reading according to the patterns required in the datasheet. This even further so since I managed to get it working on a PIC24 in the past so I’m not completely clueless in the I2C (or SPI or One Wire) world.

I tried a few things making adjustments and generally did not get anywhere. I’ve checked the voltage on the bus and I do indeed have 5 volts. At first I had only 4.8 volts due to the LCD backlight sucking most of the power off the USB port. I dug out the AC adapter I ordered and plugged it into the system and brought the power up the rest of the way and all was normal voltage wise. As I change the resistors and play with the speed of the bus I go from having NO responses to 0x00 responses to 0xFF responses… to 0x01 responses. ONCE I managed to get some numbers out of it that made absolutely no sense at all. They were returning things like 80 for the seconds and some 140 something for other things… 12 for others that should have been something else. It was just all over the place.

I don’t have an oscilloscope to try to look at anything closer and one of my co-workers said he had an old scope but no leads anymore. Since I knew I’d need to order some new leads if I borrowed his scope I started digging around to see what’s out there to see what I wanted to do. I have since that expedition ordered a logic analyzer that supposedly I can decode/time/process/log/graph/whatever all the various I2C channel data. I’m not entirely sure how exactly I do this still since documentation is a bit rough to come by properly on the internet the is explicitly involving I2C and the capabilities. It generally just mentions these things in passing and shows a screen shot.

In addition I run into a possible problem having Windows XP x64 bit and having had to host my PIC32 development work out of a virtualized XP 32 bit with USB pass through and trying to get some drivers installed so this should be fun.

I’m still waiting for the logic analyzer to ship. I ordered it on the 9th (here and at the seller’s location during their business day). The seller has updated the order status to “processing”. They indicate they typically ship within 1 to 3 business days. They are located in China so it’s “tomorrow” there now. It was ordered with UPS Worldwide Express delivery so it is SUPPOSED TO be “next day” delivery. I’m not sure how the next day works exactly in terms of time zones. Is it next day shippers time zone? Next day from calendar time/date between both of us? I just don’t know how that one works since I’ve only had the one package from Bulgaria and a couple more from Thailand in this project and neither was the spendy UPS.

I’m guessing if it ships “today” in China it will ship Thursday the 12th China time while it is still Wednesday the 11th here. It will then arrive to me Friday the 13th (sheesh) US time giving them about a day and a half for delivery. I could be entirely wrong though…. doubt it. I just don’t see how they could get something from China to Northern California that quickly. I mean they have what appears to be a 3 hour flight inside China to another airport and from there straight on to San Francisco for 12 hours. With time zone differences etc it appears that flights leaving there around 4 PM China time arrive in the US in San Francisco at 11:30 in the morning “the same day” Pacific Time. From there it would be a normal in the US “overnight” delivery. Actual flights are probably 4-8 hours later. It would catch a smaller flight to Sacramento overnight and then continuing onwards up to where I live for delivery the following day since they seem to fly UPS packages into the local airport whether it’s ground or next day air etc from Sacramento.

Guess we’ll see what happens. I’m guessing I’ll need to sign for it since it’s an international delivery. Everything I’ve gotten international so far required a signature. Other people I’ve talked to said the same things with their international deliveries. Perhaps there is some sort of rules saying someone needs to sign for stuff coming from out of the country. I won’t be here because they’ve quoted around 10am as their delivery time guarantee. I’ll have to sign for it and leave the “door hanger/sticky” for Monday I guess unless I can pick it up after work at the airport when I get the sticky at lunch time when I’m home.

Arrival, sort of.

By | | ,
Leave a comment

I finally received the package after the carrier redirected it up here. I’m happy to finally have my stuff but I had a problem. So one of the drawbacks to SparkFun’s website is when you put stuff in your shopping cart they… don’t always stay there. As a result I added and added and added the jumper cables I needed time after time and apparently on the umpteenth time adding it to my cart due to indecisiveness about the other components I ended up adding the Male to Female cables. I needed Female to Female. I didn’t double check F/F on the jumpers after it was in my cart and now I have 100 female to male cables.

I ended up using some jumpers off old circuit boards and hard drives to link the two cables together on the male end to hook one of the sensors up with the female ends. I’m having difficulty getting the information off the first sensor to appear on the LCD due to the way it converts the text for display… I need to rethink this a little more and spend some time experimenting on it but I THINK it’s working getting the data. I could be wrong but some of the logic tests seem to show it getting data. I’ve just been rather tired the past few days and havent been able to fully think about it in between working and other things so I hope to do so this weekend.

I ordered several other sensor boards from SparkFun and a few other parts that can be used in the project at some point in addition to the RIGHT jumper cables so I don’t have to connect 2 of them together. In addition I can probably use these jumpers for something else later as a sort of extension cable or something.

THIS time SparkFun shipped my package on the same business day they got the order. I bumped it to Overnight shipping because I want to be sure I had it this weekend. It shows it having been picked up in Boulder and due for arrival by 3 tomorrow. I won’t be here so as long as I don’t need to sign for it it’ll be here when I come home. Guess it’ll be 1 day this time rather than 6 business days or something.

Where oh where has my little package gone.

By | |
1 Comment

Oh where oh where can it be!

So TODAY the package tracking says that it was delivered to the sort facility at zipcode xxx9x. I live in xxx8x. It was last updated as out for delivery. I’m guessing that someone will update it tonight indicating that it is being redirected to the correct post office. Otherwise the post office will end up delivering it to SOMEONE in the wrong zipcode.

Thankfully there are no streets the same as mine down there. It’s not that far away so it should (if caught correctly in time) be redirected up here. Ultimately it will probably be delayed an extra day because of this. The address on the paperwork sent via email shows the correct xxx8x zipcode so it’s just a sort/electronic OCR problem probably…

The preheater arrived as expected in great condition just like the soldering system arrived a few weeks ago from the same vendor.

More ordering, waiting, soldering stuff.

By | | ,
Leave a comment

I have begun soldering rows of header pins to the boards for the IO expansion as well as a few sensor boards. The PIC32 IO Expansion board does not have any of the IO pins installed when you buy one. It only has the two card edge connector sockets. I’ve gotten them all soldered on now and am waiting for an order to come from SparkFun for a few more sensors.

The fun thing with SparkFun appears to be they suck at shipping. I ordered something Monday night. Tuesday one would expect them to process it. Wednesday I received an email indicating my order had shipped. Wednesday night the carrier had no record of the shipment. Thursday they claimed to have been electronically notified of a shipment but had not scanned it so they may or may not have it in transit. It COULD BE at SparkFun still OR it could be in transit. Friday came and went. The shipping method I chose I researched and it takes a guaranteed 2 days to arrive where I live. They DO deliver on Saturday. Nothing came today. The tracking info STILL says that electronic info has been received.

Soooo it’s now 5 business days into ordering. I’m going to be really pissed off if they havent shipped it yet and it’s just sitting around packaged and labeled and not handed over for delivery yet. On Monday I’m supposed to get the infrared pre-heater in and some solder paste for smd stuff.

Regarding the time experiment it appears there is a drift of a second every couple of hours. It is close enough for a normal roast use but several hours later you can see a 1 second different. If I want the time to track continuously it needs some adjustments. Once I get a few things dealt with I’m going to confirm the quality of the solder joints using some of the rework soldering stuff and clean some things up first and then try a different combination of crystal and capacitors for good measure if it doesnt help resoldering things like that for a good connection.

I need to get some spray (or paint on) flux remover for the board and some brushes to clean it up better…. also my stuff that’s supposed to be here Monday has disappeared from UPS’s website. It now shows billing information received. I’m guessing the sender re-uploaded my tracking stuff with a new order he shipped resetting my tracking back to zero. Until they scan it somewhere else along the way it won’t show up probably.