ADC Conversions

Hello,

I'm working on a Master/Slave network with a PC as the master (could be a PIC too though) and multiple PIC16F877's as the slaves. Each of these slaves is a configurable multi-purpose I/O module for use with automation and data aquisition.

Currently, when the Master requests an ADC result, the Slave does the conversion when asked for the result.

This is OK but I would like to have a conversion runnning in the background while at the same time listening for Master commands.

I'm using 5 of the PIC's ADC modules for interfacing off-board, but I want to have one of the other ADC modules measuring the pre-regulator input voltage (which should be between 9 to 12 volts). If the input voltage drops below 7 volts, all of the configuration values (I/O direction, output values) will be stored in E-squared in case the voltage only dips momentarily.

Anyway, if any buddy has some good ideas of how I can accomplish this repetitive ADC conversion while at the same time listening on the serial port at 9600 baud, please let me know.

It's not going to happen.

First the Datasheet is your best friend... study it. From there you will have gathered that the F877 does NOT have a heap of ADC modules (fig 11-1) it has just ONE which is multiplexed out to a number of inputs. Therefore you can only do ONE ADC conversion in background, you then need to service the result, switch to your next input and start the next conversion process. You can't do that whilst simultaneously doing Serial I/O.

Well... not strictly true... you can have an interrupt driven HARDWARE Serial routine running whilst doing all your data acquisition in forground. Or you can have your ADC's being serviced by interrupt whilst doing Hardware I/O in the main program. It's just not going to be successful with Software Serial I/O as it needs to keep strict timing.

You can of course have the ADC do a SINGLE background conversion whilst simultaneously performing Data I/O, you can then just pick up the result when you're ready for it.

Melanie

PS... Patience. Posting on a weekend when most folks are away and nudging me as to the absence of replies doesn't help. Not everyone works 24/7 like I seem to do nowadays... and even then may not have an answer, or the inclination, or the time to reply. If you see your message up in lights here, you've posted.

Actually, something appears to be awry... a 'Search' shows you've posted three times, yet only displays two results. A mail to Lester may be in order if one has dissappeared (unless you deleted it accidentally).

Thanks Melanie.

I didn't mean to pester you.

The list has been behaving a little strange for me the last couple of days and the fact that it said I had put three posts up and could only find two had me wondering.

I'll email Lester about it though.

Anyway, I do indeed understand how timing critical serial I/O is, and I do not want to upset that. However, I've found a way to implement what I was trying to accomplish using the USART example (USART.bas) that comes with PBP. I never could get that example working (if anybody knows of any known bugs please let me know) but I found a work around.

In my project, the Slave (PIC) is constantly listening for a start character that indicates that an ID name (2 characters) is coming next. I simply used HSERIN before with no timeout value. The program would just sit there until the start symbol appeared and then would proceed. I wanted to use the USART sample that's given with PBP and, within that code, tickle an external watchdog circuit with a pin on the PIC, but I couldn't get the sample code to work . However, I managed to accomplish what I wanted using HSERIN. What I've done now is implement a short (1ms) timeout at the point where I receive my first character. Before the HSERIN is performed I toggle the watchdog pin. If there is a timeout in 1ms (i.e. the start character is not received) I go back and listen again and toggle the watchdog pin again. The watchdog device I'm using requires a state change at least every 700ms or else it will drive MCLR low and reset the micro.

Now, regarding the AtoD converter. I don't mind doing 5 of my AtoD conversions on a need to know basis, but I do want to keep a constant eye on the pre-regulated input voltage. What I plan to do is initiate an AtoD conversion after 1 timeout (in the loop that looks for the start character) and then check to see the result at the next timeout. This would mean that I'd be doing an AtoD conversion every 2ms. This would take a back seat when servicing the serial commands (i.e. acting on them) but that's OK. I'm going to put a pretty good sized capacitor on the regulator's output to give me the time I need to "take care of business" in case the input voltage drops.

I'm not really going for speed with this project. I want something that is incredibly stable and error proof.

Anyways, as always, thanks again Melanie. If anybody else has any comments or suggestions feel free.

I don't see a problem with your 1mS toggle, but I do see a problem with big Capacitors on the outputs of regulators. Big C's tend to be seen as instantaneous dead-shorts and give regulators a hard-time on power-on, with series limiting resistors then give slow rise-times for the PIC's reset. If you can, put the big C on the regulators input.

Hi Melanie,

As usual, you're right. Having a large capacitor at the regulator's output probably wouldn't have posed too much of a problem with the regualtor I'm using (an LM2941) because it has built-in short circuit protection. I'm also using a supply supervisor which keeps MCLR low until the regulator's output reaches an acceptable/stable voltage. However, I should not tempt fate.

My original idea was that the large cap at the output would continue to supply the PIC with an acceptable voltage for a time even if the input suddenly died. This would give the opportunity to "get my house in order" before the input died. However, the large cap at the input will result in more or less the same thing. It will discharge slow enough so that if I consider 7.0 volts unacceptable, the cap will have about 1.5 volts or so to discharge before I start having problems.

Also, it allows me to even keep that cap off of my board if I like and connect it nearer to the power supply. For my purposes (delaying input voltage drop) this should be OK.

Thanks again Melanie.

Measuring the input Cap discharging is not the greatest way to do it. By the time you've detected a significant voltage drop to determine you've a power failure (taking into account the dips and peaks of your various loads), that failure has been around perhaps for several tens of milliseconds.

Consider the attached schematic. Here the failure is detected the moment it happens. C1 has not yet started to discharge and you've got those extra tens of mS to play with... one extra Diode is all it takes...

R1/R2 are just a voltage divider to ensure the PIC's ADC doesn't get more than +5v at it's input. Adjust the values to suit.

Hi Melanie,

I get it. The diode keeps the input capacitor from discharging through the voltage divider network or the input terminals and only allows it to discharge through the regulator and the load.

That's perfect and simple! Now why didn't I think of that?

I like solutions that are simple, they are almost always the best.

This reminds me of my first engineering job. A co-worker and I were given the task of autoconfiguring a power supply to supply 13.5 volts when one type of device was connected and to supply 15 volts when another type of device was connected. It had to be "pokey-okey" (idiot proof) and we couldn't use any jumpers or switches that the user could screw up. Well we had all kinds of semiconductors on this thing and we had run the cost up by about 6 dollars. Then, my supervisor took a look at it for a moment and suggested that we add another pin to the power supply's output connector and branch the power supply's output to 2 separate pins on that connector. One pin would get the straight 15 volts and the other would have two diodes inserted between the power supply output and the other connector pin. Now, the devices we connected to the power supply output connector had different connector types. So, we simply wired up one cable assembly to tap the 15 volt pin and the other cable assembly to tap the 13.6 volt pin. How simple is that?
The cable assemblies could only be connected to the device that they were intended for. Perfect!

To make a long story short, the project was on time and on budget (the first time in the company's history).

I learned my lesson early. Don't over-design!!! Bells and whistles are not worth compromising reliability and feature creep is the enemy!