Tag Archives: time

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.  😀

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.

Let me tell you about the time….

By | | , , , , ,
Leave a comment

So I’ve ordered a plethora of stuff lately. Yesterday the 5×7 magnifier came. I’m figuring out I have no place to work on this stuff properly so it’s sort of wedged on my desk, and then today a box from Mouser showed up. In it I’ve determined I purchased the wrong AC adapter…. so now I need to order another one but this is for a slightly later stage so it can wait a little. Plus I believe I have a power supply I used on a fan to keep the air moving in my indoor orchid tray and lights area that is not being used currently due to a different setup that I’ve already stripped the ends off that I could then use with the relay board I received from Bulgaria. I’ll probably find something else to use that power supply for later anyway.

Anyway, TODAY the Mouser box arrived. In it were a variety of 0603 sized capacitors. For those that don’t know what that means… they are .06 inches by .03 inches or approximately 1.5mm by .77mm give or take a few hundredths of a milimeter.

Today I learned that fluxes are awesome when soldering SMT devices. I managed to mount my 32.768 6pF crystal and some of the 11pF 0603 capacitors from the selection but it was an adventure. I’ve lost approximately 4-5 of them into the rug somewhere now. Two are now securely attached to the board. I got the first one out ok but lost the second one immediately. I got a third one out but it didnt make it to the table and went straight for the rug. I recovered one of them from the rug and then tried to get it soldered onto the board. Two of them blew away using the hot air system. Once I got a corner tacked down properly it went much smoother. After allowing things to cool off I mounted the USB II Microchip board back into the IO board and connected to my LCD and fired it up. Immediately the clock on the display started ticking off seconds.

I had quite a bit of difficulty getting the soldering stuff going. I looked up temperatures for things on Wikipedia and ended up grossly under heating things up. I ended up looking up the soldering station’s manual on the internet since I couldn’t actually find it right now due to the bags and bags and boxes of parts and shipping materials everywhere. Once I finished looking that over things melted much more easily and started acting more normally. Once I started packing the parts away into boxes I discovered the real manual buried in the pile.

As mentioned the timer is running just fine. I am waiting a few hours to see how far off the time is from my computer to get an idea of whether this has a slight or a significant drift. So far it looks quite good. Time will have to tell. ULTIMATELY being REASONABLY close over a few minutes is fine. In the final project I will be using a DS3232 I think it is as a time source to populate the microchip “RTCC” after powering the system down and then turning it back on. Microchip for whatever reason built a system that has marketing towards it having a Real Time Clock built in. The problem is it doesn’t keep time when you turn it off due to having no backup battery of any kind. As a result it needs to be set every time you apply power to the system and then take it away when you turn it off.

Since I intend to hook this to the internet / router eventually I will try to implement a NTP client to set time into the DS3232 and then from there into the Microchip PIC32 while it runs. I’ve now manually adjusted the clock to be in sync (visibly anyway) with an atomic clock synced clock I have here immediately next to it. I set it at 10:12 so I will check it again in a few hours. The longer it seems stable the less I’ll have to make it lookup from the Dallas chip…..

I believe tomorrow I will be getting some ambient temperature, humidity, and barometric pressure sensors as well as a few other sensors I may or may not be experimenting around with too in this and other projects. So far 10 minutes in the clocks still seem synced so we’ll see what happens over the next few hours and overnight.

Oh… and Microchip never replied to my “technical support” request to get an idea what they suggested. I think the details I’ve found on the internet meant several different options of crystal and capacitor combo were ok and what they DESIGNED it with was not very common to find. I managed to find what it sounded like it was designed for though and so far so good.

I should start mounting the header pins this weekend and start hooking things to some of the external sensors to start getting readings into the programming. Once that happens I can start porting my PIC24 code over making a few adjustments and then start programming the roast curve tracking portion.