PIC programming

[explicitlyrics]

Hello people, I was wondering if anybody has much experience of PIC programming? (if you don't then I don't want to waste your time by reading on!)

I'm currently embarking on a home brew beer making device as part of a university project, it is going to have a PIC 18F4550 as its brain. The aim is to have a device that can control the beer making process over a period of time to a set of predefined specs. I have been getting to grips with PIC's over the last few days and have learnt a great deal (though there is still tons more) and I had a few questions about the best way to do some things. I am programming in the C18 compiler that comes with MPLAB and have got to the light flashing and button sensing stage.

My main question is about USB interfacing, I want to be able to modify the settings of the device via USB so that you can easily change the brewing time/temperature/... by just plugging the device into a computer. I am currently running with a USB bootloader on the chip so that it is easy to reprogram the PIC having recompiled the source code. However, if this was ever used by somebody other than a PIC expert it would be far from easy so I want to have USB communcations such that a PC application can quickly change the values of certain variables. Is it possible to change variables that are stored in the PIC between power cycles, or is it just the firmware that remains after a reset? In which case I guess I would also need an SD card or something in order to store information which then adds further complication. Anyway, to stop myself waffling I would love to know the best way to change variables in the PIC such that the timer can be modified easily from USB (or will the source just need recompiling/flashing?)?

Another question was about the timing of the processes, I am currently planning on using interrupts to measure time and ensure that temperatures are kept accurate. Is 1 second a reasonable period of time for the interrupt such that it can measure time over a period of several days yet also do it over an hour or so.

Really not sure where to start with designing and planning things so would be great to discuss with somebody who has a clue! At least Ive managed to get the PIC to a stage where C programming is possible, slow but steady!

Thanks

[TAKTAK]

well i was going to scan in my notes on PICs... but you seem to be alot further than me (ALevel)

and mine are for a 16F84

but i wouldn't have thought the temperature would fluctuate much within 1 second so you should get away with a interrupt of 3 seconds or so...

and for different temperatures/times you could always have it set so when input 1 is high then it runs a different code or when input 2 is high it runs a different code

then have the different code with your altered variables...

it is a way to do it.. but it doesn't give as much control...

[Gerrard]

It's been a few years since I've programmed a PIC back at uni, and to be honest, I wasn't much good at it then!

I used the PIC 16FXX series rather than the 18FXX, but I don't recall if they had any memory. I have a feeling they might have memory for the code and for general use. For the projext I was doing (a height/acceleration/GPS recorder for "amateur" rockets), I ended up using a MMC card to setup the parameters. The idea was to write a program on the PC that would write various parameters at the start of the card, and use the rest of it to record the data. I think I used this method rather than connect the PIC to the PC somehow because I was using the card to store data anyway. When started up, the PIC would read these parameters off the card (I was cheap and used the onboard 8-bit ADC to record, so it was to give the best limits). And you are right, it was a bit of a pain to get it to work at first, but when I eventually found the right documents, reading and writing to a MMC card wasn't too complex.

EDIT: Ok, I have found the data-sheet for the 18F4550 here, which I would guess you already have. Now, in section 7 it mentions Data EEPROM Memory; non-volatile memory separate from the program memory, and sounds just like what you need. However, it only has 256 bytes, although going by your "brief" that should be enough. I never tried USB interfaces (although I do have some spec sheets in my project folder for some reason, so I might have considered it at some point), but I would imagine you might be able to program it into the PIC to read data from the USB into this memory and read it as and when needed. Don't know if that's helped much, but I'm really out of touch with this stuff now, so won't be able to help you with coding etc., but there does seem like plenty of information in that data sheet to help. Good luck

[TheAnimus]

Oh how i love hte PICs.

As has been said the 18F4550 has 256 BYTEs of 'data' EEPROM. This should be more than enough for persisting data between power cycles. If not consider something that provides a few k via I2C as it would be a lot easyer than messing around with SD.

USB for the PIC, this will depend on the bootloader your using, last time i did this (we didn't have none of those fancy pancy EEPROM USB PICs, UV eraser FTW!) so i used a HID usb toolkit from Microchip themselfs. With this it makes it easy for the PIC to slowly (ie at keyboard, not say webcam) speeds.

Now back onto the storing data. I'd say that you don't actually always want or have to use the 'data' area of EEPROM, the reason for this is you can re-write your code memory. Often this makes accessing the data faster and easyer. If your writing only once in a blue moon, then use the PROGRAM memory, and implement the classic data table design pattern for storing the memory (appologies if your programming this in C rather than MASM, if you are, tell your course director they suck).

So just remeber that the PIC dosen't follow the awful design pattern of bluring program memory and data memory. By keeping them seperate it makes more much easyer programming, debugging and security. So you've got the EEPROM for Data. But there is NOTHING stopping you using the program memory via self modifying code if speed is really important.

As for the 1second, I'm guessing your running the PIC at 48Mhz, giving you a 12MHZ Instruction Cycle. So you want to use the TIMER1 for your interupt for sampling. As such choosing 1 second might be silly and make it harder work. (the way these interupts work is by 'counting' down a register, when it hits 0, the interupt fires). Is there a reason you need it to be as slow as 1 second?

[explicitlyrics]

Wow, thanks so much for your responses, I really didnt expect so many! To address a couple of your points:

The temperature probe I am using seems to integrate fairly well from what I have heard though havent actually started investigating that much yet. Hence I think Ill just use a fairly simple formula to determine what to do with the heater based on the temperature.

I will have an internal timer interrupt that fires every 1 / 3 / ? seconds to read temp and process what else needs doing. I only selected a second as there is significant thermal mass in the mixture for it to work slower without problems and I thought that would be easier for programming and wasting processor cycles. Why would a quicker interrupt help things? It would also be useful to have a round number so that timing becomes as accurate as possible (since with beer making even a short period of time can make a slight difference to taste).

Having a second for the interrupt period means that when controlling a couple of weeks in time period, you can use a float number to count. This then leaves space for 64 floats (which should be ample to control temperature variations wrt time) in the EEPROM. I would want the times/temps to be easily changeable without recompiling the code, hence the EEPROM seems like a great solution. Speed of reading the numbers is not important either within a few seconds so that should be fine.

I will then use an external interrupt on a high service level that can be used as an emergency stop button, this leaves me plenty more interrupts and timers so I will think about what else I could feasibly do with them.

I am programming in C, since whilst I can do some stuff in ASM, I wouldnt fancy doing it all in it!!!! ESP for my first real PIC experience!

Those are just my thoughts in response to what you have said, hopefully I can speak to Steve B to try and finalise some more points. Thanks again!!!

[bsodmike]

You can also consider the DOSonChip breakout board at SparkFun.com - it basically offers an 'easy' (or so they claim) interface between MCUs and SD cards. The data is dumped into text files which you can access on a PC.

I've used the 18Fs with the HITECH compilers. I've been using the HITECH compilers for a couple years now, tied with MPLAB too (unfortunately) but my programmer is a ICD2 PIC programmer, hence the need for MPLAB.

Something to consider: Use a FT232RL USB <-> serial IC. This way you don't have to mess with USB HID kits etc. You simply plug the USB cord into your Mac/PC and install the FTDI drivers (Free available for ALL platforms!). This will appear as a COM port/Virtual Serial port under Windows and in Mac under /dev/ and be listed as one of the more obvious ttyp's (or cu.usb something...)

You can then communicate with the PIC over serial for whatever needs to be done. The FT232RL chips I used (two in the example below):



Looks like you're on the right track with the help of everyone Let us know how it goes.

Out of curiosity, which Bloader do you have running ? I'm stuck to doing everything over ICSP...

[TheAnimus]

you can actually do that using the 18F4550's internal USB SIE quite easily.

When you implement yourself as a simple HID class, like a keyboard, all OSes should support it with no 'kernel' drivers.

Even linux can do that now without throwing the same hissy fit it used too!

My point about the TMR was for accuracy. Its actually quite hard to get EXACTLY a second, you can get proximately quite easily. But remeber the TMR interupts work simply by firing on overflow. You can divide the rate at which the register increments, but its still based on the clock (guesisng 48Mhz to make the USB easy) so make sure u don't shoot urself in the foot by needlessly speccing it as exactly a second

[Blitzen]

Do you mean changing the PIC variables post programming once the device is soldered in/mounted on the PCB?

If so, make a jig that will touch the contacts of the device once its mounted on the PCB. THat way, so long as you dont lock the program once flashed, it can be reflashed to contain different source.

If you mean having different programs available then, using MPLAB, the different sources can be loaded upon request.

Lastly, as you probably know, the PIC you are using is philips i believe so is pretty generic and very common.

[Steve]

What's clocking the PIC?

If it's an internal RC then the clock rate will vary with system temperature. I.e. 1 second won't be a second. It may be the case that you don't care about the accuracy to that degree. But if you do, you'll need a temperature compensated crystal oscillator as the clock source.

[explicitlyrics]

I think the internal oscillators are actually stable over a temperature range of 5degrees up to 35 degrees actually, but im using an external 20MHz Xtal so that will give me the 48MHz clock speed accurately.

You can set up the chip in CDC (comms device class) mode where the USB cable emulates a serial link and then regular serial communications will work. You can do it as an HID device, but then the communication is basically one way (though its quite fun to make a chip that randomly jumps the mouse all over the place and types garbage without people realising). You can do it as a generaic USB device, which is also quite easy and configurable. Finally, you can set it as an enhanced mode USB device with full functionality for every USB command possible, though this would need a lot of work.

I am currently struggling to decide between CDC and regular USB, since they both seem fairly easy to implement based on the example code, but I don't know about the PC programming side of things. All my programming experience is largely in some form of C/C+/C#, though I get the impression something much more high level might be useful for the user interface and stuff. Anyway any ideas about whether it is actually easy to send and receive USB commands, or should I just make the PIC seem like a virtual serial port?

Also WRT programming, I dont want to have jigs and stuff to do an entire reflash of the chip (though I guess I could just reflash the EEPROM when in bootloader mode). That has actually made a lot of the USB functionality largely irrelevant since I guess it must be quite easy to just flash EEPROM without touching anything else - though it is a bit more likely to cock up at some point no doubt....

[bsodmike]

CDC looks like the simplest way to go. Communication over a serial link in many platforms is also a relatively simple task, with device drivers doing all the 'hardwork'.

Which USB stack have you downloaded - is this from Microchip? I'd like to have a play with this at some point as well.

Thanks!

[explicitlyrics]

All of the USB stacks are available as samples on their website (searching for MCHPFSUSB will get you the files). I think I'll probably go with CDC then as I can then have some form of monitoring and debug-ing aswell if need be. There is also a preset bootloader which comes with it and just uses a different linker script to remap the reset and ISR vectors, uses 1 extra pin on the PIC as a form of low voltage programming mode.

Another question I have is about choice of programmer. I have borrowed a friends ICD2 to get it started, but now want something similar, though I'll be getting a clone of some sort. I cant see whether the PICkit2 is any different from the ICD2, other than the fact it is 5x cheaper. That said, the ICD2 clones on ebay seem to be around the &#163;30 mark. I am very tempted to make a PiCS style programmer, but itll cost me a load to get the board prototyped, hence buying one makes sense.

Any ideas between these ones:
http://cgi.ebay.co.uk/Microchip-MPLA...ayphotohosting
http://cgi.ebay.co.uk/FullSpeed-MPLA...QQcmdZViewItem
http://cgi.ebay.co.uk/Microchip-PIC-...ayphotohosting

and the official ones from farnell:
http://uk.farnell.com/9847170/semico...ochip-pg164120
http://uk.farnell.com/9945350/semico...p-pickit2promo

[bsodmike]

The best one I have come across is the Olimex ICD2 programmer from SparkFun.com - USA based though.

Thanks for the links.