Writing variable to PIC via UART

[ed_reardon]

Hi all,

I've designing a signal conditioning circuit for an instrument however the micro is going to need to be calibrated in the field for setting offsets and span of the sensor,  my idea is to use UART via an RS232 interface and writing some very simple VB type software with the serial commands to update these variables in the field.

For example I will defining (as intergers):

-mVOffset
-mVSpan
-mVHalfScale

There is also an I2C DAC driving a current output which will need to be trimmed.

The variables will be used to drive mathematical functions in the PIC for conditioning the output, I can find lots online about doing basic read/write to LCDs etc online but precious little about updating and storing variables.

I know very little about serial interfacing with PICs so forgive me if this is a stupid question! 

Am I trying to do the impossible here?

Any help welcome!

Cheers,
Ed

[BrianHG]

You shouldn't have any trouble.  Make sure the PIC you choose has a UART and use the UART pins for simplicity sake, otherwise you will end up fiddling with an assembly software UART.  Also, if you are using the PIC's internal oscillator, and your hardware's PCB is run typically at room temperature, keep the baud rate down, like 19200 or below, otherwise, use at least a ceramic resonator or crystal for the clock.  Note that some of the newer PICs have better precision internal clocks, but be careful here...

Also, if your serial programming cable is short, you may still be able to get away with +5v TTL RS-232 voltage levels, but, protect your RX & TX pins on your programming connector.

Good Luck.

[elecman14]

Should be fairly simple read the value in from the uart, parse what you read in and cast the value to use it for your math. If you want the value to retain between power cycles store it to eeprom. Then just recall the value on startup and store it in a variable somewhere.  Some pics have built in eeprom that can be written from code. If not you can use a SPI or I2C external eeprom. Keep in mind most eeprom have a limited number of writes before they fail.

If you break the problem down into simple steps it makes it more manageable

• Read the datasheet and figure out what registers need to be set for uart, TRISX, OSCON, etc.. (new versions of MPLAB may also be able to do this)
• get the uart to act as a loopback
• Get the eeprom read/write working if you need it. You can use the RS232 to debug
• Keep doing simple steps that can be validated

Good luck.

[ed_reardon]

Great stuff guys, this is very helpful.

Power cycling may be an issue, (these units will be used in remote outstation locations where power interruptions may present an issue), external non-volitile may be the best option here, this will only be for a handful of units so cost isn't a great factor.

Now I need to learn how to interface a PIC with an external memory, oh this is a rabbit hole isn't it, time to suck it up and learn it

[BrianHG]

How much storage memory do you need?
Also, depending on the resolution of your DAC, there are now PICs with DACs and of course there always have been the PWMs.

[BrianHG]

• get the uart to act as a loopback

Yes,  I find this extremely useful when I interface my hardware with my FreeBasic code.  My FB code is able to automatically verify and check if what's being sent was received correctly...

BHG.

[Brutte]

I'd suggest using a USB uC. Microchip provides an off the shelf bootloader and CDC or HID so this should be easier than doing your own UART, CRC, etc.

Use an internal eeprom for storing data, if possible. You can also store data in flash, some PICs support that.

Another thing is the DAC. If you only need offsets then use PWM. The unloaded low-pass RC filter has the steady state output voltage that is proportional to PWM factor.
0% -> 0V
50% - > VCC/2
100% -> VCC

[ed_reardon]

Cheers again all.

The DAC could be replaced with PMW & R-C I need to output 0-2v scale against the conditioning, it'll be driving an voltage-current convertor IC designed for 4-20mA signalling, load on the micro being negligible. The mA output isn't required to be incredibly tightly controlled as the signalling is only used as a crude trim in process rather than a super-accurate analysis.

More to research, thank you all for your input!

[Buriedcode]

Although external EEPROM's arguably will have more write cycles than on-board memory, unless you need > 128bytes, it will be easier to just use the EEPROM on the PIC.
Of course writing to non-volatile memory is a bit silly if you're updating it constantly, but for calibration/trim/firmware revision values that are updating on average.. every day?  Its all good.

Some 8-bit PIC's have an 8-bit DAC built in.  8-bit isn't exactly stellar and I generally opt for external DAC's, but it depends on the requires resolution. Those devices also tend to have an on-board reference which can be 2.048/4.096. It has a pretty terrible tolerance, but again, if you're not after <2% precision you can just set it to 2.048 and the output will be the value you give it multiplied by 8mV. (say you give it a byte of '54' decimal, voltage should be: 8 * 54 = 432mV.

More complicated, but ultimately low part count solution (not trying to throw too much at you at once here):
Should you wish to have high resolution using PWM and a filter, in order to reduce the filter requirements, you can choose a PIC with two PWM outputs, and restrict them to 6-bit.  Using a 64/1 resistor 'adder'
You can effectively get a 12-bit PWM DAC, whilst pushing its frequency up allowing a simple two-pole filter.

Edit, just realised I've probably gone too far here, just throwing idea's out!

[rcbuck]

I would suggest using a PIC with built in EEPROM. It will be easier than external memory. You just need to search the Microchip website and find one with enough memory and math capabilities to do the job. A lot of the PICs can't do high level math. You would want one with built-in multiply and divide hardware.

As for lifetime of EEPROM, I just quickly pulled up the PIC16F883 data sheet. This is what it says.

High Endurance Flash/EEPROM cell:
- 100,000 write Flash endurance
- 1,000,000 write EEPROM endurance
- Flash/Data EEPROM retention: > 40 years

However, this PIC doesn't have built-in multiply and divide hardware. You should not attempt your project with a PIC that doesn't have the math hardware.

Just my 2 cents.

[BrianHG]

However, this PIC doesn't have built-in multiply and divide hardware. You should not attempt your project with a PIC that doesn't have the math hardware.

Just my 2 cents.

Why?  The C compiler doesn't care, it will just use a little more program rom and cycles to compute and I don't think ed_reardon's project needs multiple million multiplies per second.  Even the cheapest 8 bit pic's today run at 8 mips with the internal oscillator & PLL and will achieve over 100k multiplies / sec if needed.  The spread on the speed for divide is greater though.

That aside, if ed_reardon requires hundreds of writes/day while still using, say, 1k of flash;
a) he may choose to save the contents to ram and only update the flash once a minute or so.
b) save to contents in ram and add a backup battery.  Even with the smallest lithium coin cell, putting the PIC to sleep once the main power goes out, the battery will retain the ram in the PIC for a decade or more.  Also, now you get the battery backup ability of keeping the processor on for a second or more to do whatever you want before putting it to sleep if the main power goes out.

[JPortici]

You shouldn't have any trouble.  Make sure the PIC you choose has a UART and use the UART pins for simplicity sake, otherwise you will end up fiddling with an assembly software UART.

what is this? 1994?
Nah, kidding. i have a product that is just an uart "switch" that i wanted to be the cheapest possible so i went on with software uarts all over the place
yeah, no kidding: having to fiddle with i2c, the baseline is out of the question so you have at least one uart and one mssp (spi/i2c)...

Anyway, if the chip has an EEPROM or self programmable flash, so again, everything beyond the baseline, save the data there, and reload!

my usual software has (this is platform independant)

-a table of default settings, written in flash.
-if one cell of the internal/external eeprom doesn't have a specific value (different than 255, the erased state) write the default settings into internal/external eeprom
-load settings from eeprom in ram for use

then the communication protocol in uart has commands to
-read location x of ram (pointing at settings memory)
-writing location x of ram with data y (pointing at settings memory)
-storing ram into eeprom, as eeprom can be written a finite number of times

and you just do this. when you receive a character you put it in a buffer and compose your message. then a routine analize the message and decide if it's valid and then excecute the action

However, this PIC doesn't have built-in multiply and divide hardware. You should not attempt your project with a PIC that doesn't have the math hardware.

that's true only if you want to do floating point.. or you have tight regulation cycles. i have many products using pic16/pic18 doing a bonanza of 16/32 bit math, including divisions. who cares? the sample rate is in the lowe kHzr range, the signal is in the Hz - tens of Hz range. if it takes 500u/1ms to complete the whole calculation loop nothing happens.

[BrianHG]

what is this? 1994?
Nah, kidding. i have a product that is just an uart "switch" that i wanted to be the cheapest possible so i went on with software uarts all over the place
yeah, no kidding: having to fiddle with i2c, the baseline is out of the question so you have at least one uart and one mssp (spi/i2c)...

Using a PIC with comparitor inputs, and a software UART, I did make a proper balanced RS485 transceiver (only using the PIC comparitor input as a true differential line receiver and switching the same 2 pins to output generating a differential line driver.) back in the early 2000's which ran a multi-node temp, humidity sensors + led display & push buttons, at 2400 baud networked through a 8 story apartment building on unshielded phone cables, error free!  Cant do that with the UART unless you want to add a RS-485 transceiver IC on each PCB.

Well, back on topic, for 8 bit PICs, assuming you don't want an only 8-pin version, PIC16LF18323-I/SL would be my guess as to a cheap available entry device for project.
OOPS- make that the PIC16F18324-I/SL for 5v support and availability, PIC16F18324-I/P if you want a DIP package...

[JPortici]

Using a PIC with comparitor inputs, and a software UART, I did make a proper balanced RS485 transceiver (only using the PIC comparitor input as a true differential line receiver and switching the same 2 pins to output generating a differential line driver.) back in the early 2000's which ran a multi-node temp, humidity sensors + led display & push buttons, at 2400 baud networked through a 8 story apartment building on unshielded phone cables, error free!  Cant do that with the UART unless you want to add a RS-485 transceiver IC on each PCB.

very clever i will keep that in mind if i don't want/have space to use a transceiver

Well, back on topic, for 8 bit PICs, assuming you don't want an only 8-pin version, PIC16LF18323-I/SL would be my guess as to a cheap available entry device for project.
OOPS- make that the PIC16F18324-I/SL for 5v support and availability, PIC16F18324-I/P if you want a DIP package...

that would be my first choice too, but i'll start using them in products if and when the electrical specification will be properly characterized. Until then the 16f1823 family will still be my go-to all-round small 8bit (same with 18f26k22 that will be eventually substituted with 18f26k40)

[Brutte]

However, this PIC doesn't have built-in multiply and divide hardware. You should not attempt your project with a PIC that doesn't have the math hardware.

As pointed out, int8*int8 routine occupies perhaps 30 words and you need only one in whole firmware. That is close to nothing. Of course then there is a speed penalty but as muls are only a small fraction of opcodes executed in a code flow, I do not think a PIC with or without mul makes a measureable difference. As for division of ints, that is rare as hen's teeth in a firmware. Still, another 40 words if needed.

[rcbuck]

that's true only if you want to do floating point..

Yes, that is true. Just re-read his post and see he is dealing with integers.