PLEASE HELP WITH ADC PIC16F877A

[neko efecktz]

Thanks DTJ and dannyf.
I knew about the coding practices having minimal code in a header file but just wanted to get away from the hi-tech version that had 3 .h files and 2 .c files while the whole thing had some major problems that even I as a newbie could see.
max delay of 255 ms and less for micro seconds and having to use the delay.c file just to use milli seconds.

See my post from  Yesterday at 12:12:31 PM
The note was taken from the delay.h file
Ian.m recommended  to look at an instruction Manual Yesterday at 11:47:43 AM     

See http://www.gamedev.net/page/resources/_/technical/general-programming/organizing-code-files-in-c-and-c-r1798

I have downloaded it into a Word document which will allow me to easily add notes etc for future reference.
There is a link to an updated version but it looks the same except diagrams are now in B/W instead of colour / color    ?? why change it when it was ok ??
and a couple of places I found quote marks "   " added
kept the original version.

DTJ.
I will try putting a while(1) into the code and see what happens.

tick tick tick "time passing" tick tick

No different, only getting  "DC VOLTs = +02.5"with about 4.72V applied
and "DC VOLTs = +01.8"   with 3.269 volts applied.
grounding the input gives "DC VOLTs = +00.0"
The error is non linier.
The values I gave last night were after I had modified the code to try to get more accurate values.
I have since changed back to original values

        Volt_Char[0] =  DisplayVolt/1000 + 48;          // I had changed 1000 to 500
        Volt_Char[1] = (DisplayVolt/100)%10 + 48;   // I had changed 100 to 50
        Volt_Char[3] = (DisplayVolt/10)%10 + 48;     // I had changed 10 to 5

but other similar examples I found were using the 1000, 100, 10
can anyone tell me what the purpose of the % is for???

here is the code I'm using
//********************** READ AND DISPLAY ADC VALUE ****************************
else if (FAULT_7==0)
{
        char  Volt_Char[5], DisplayVolt, InVolt;                  // sample code didn't have this line but i get errors if I take it out.
        ADC_Init();                                                             // Volt_Char[5]  is the 5 correct. I substituted [2] and it still worked .
        InVolt = ADC_Read(0); //Read Analog Channel 0
        DisplayVolt = InVolt *2;
        Volt_Char[0] =  DisplayVolt/1000 + 48;
        Volt_Char[1] = (DisplayVolt/100)%10 + 48;
        Volt_Char[3] = (DisplayVolt/10)%10 + 48;
       
       
        Lcd_Init();               // initialize LCD
        Lcd_Clear();              // clear LCD
        Lcd_Set_Cursor(1,1);
        Lcd_Write_String ("DC VOLTs = +    ");  // DISPLAY TO READ
        Lcd_Set_Cursor (1,13);                   //"DC VOLTS = +00.0"
        Lcd_Write_Char(Volt_Char[0]);
        Lcd_Write_Char(Volt_Char[1]);
        Lcd_Write_String(".");
        Lcd_Write_Char(Volt_Char[3]);
 
        DelayMs(500);   // Hold for 500 ms
        while(1); //Infinite Loop
    }
//********************** END READ AND DISPLAY ADC VALUE ************************


I'm currently using
Product Version: MPLAB X IDE v2.10
would it be an advantage to go to  MPLAB IDE v8 or at my level of non expertise stick with what I have for the moment.


Thank you for all your help so far and in the future.
BILL.

[neko efecktz]

Just been doing some checking.
OBSERVATION...
Input AN0 is selected        InVolt = ADC_Read(0); //Read Analog Channel 0
Input pin has a measured voltage on it of 4.88 volts. not applied to it, coming out of it.
Input pin AN1 - AN7 all have 0 volts coming out.

Changed active input     input  AN1 is selected        InVolt = ADC_Read(1); //Read Analog Channel 0
Input pin has a measured voltage on it of 4.88 volts. not applied to it, coming out of it.
Input pin AN1 - AN7 all have 0 volts coming out.
However

Using input 1   InVolt = ADC_Read(1);
 I am still getting the same reading for 4.89Volts in, displays "DC VOLTS = +02.5"
for 3.12 volts in I am reading "DC VOLTS = +00.4"

using input 6  InVolt = ADC_Read(6);
 I am still getting the same reading for 4.89Volts in, displays "DC VOLTS = +02.5"
for 3.12 volts in I am reading "DC VOLTS = +00.4"

using input 7   InVolt = ADC_Read(7);
 I am still getting the same reading for 4.89Volts in, displays "DC VOLTS = +02.5"
for 3.12 volts in I am reading "DC VOLTS = +00.4"

BILL

[Ian.M]

ADC non-linearity is usually a result of mis-configuring the ADC, or not allowing enough settling time before each conversion, or excessive input impedance. 
Also, you need to look at the raw ADC results, so it would be a good idea to display them.  (Hint: look up UTOA in appendix A of the XC8 manual)

Lets see your current schematic.  I also strongly recommend packaging your project and attaching it as we need to see your current code anyway, and that will make it much easier for us if we want to build it to check any changes we propose.

[neko efecktz]

Gidday IAN,
Sorry about the delay,
had to go shopping and get a hair cut. took longer than I expected.
I found we can't send .rar files but that's all I have.
I had a time limited version of winzip but it requires purchase to keep using it.
I changed the extension from .zip to .rar in hope of fooling the system.
It used to work but not sure now days

well here goes.

BILL

[Ian.M]

No problems.  IZARC handled your archive seamlessly even with the mismatched extension.  I dumped WinZip many many moons ago.  IZARC is freeware, the licence permits commercial use, and it can do just about everything WinZip can.

What about the schematic? Preferably in 16 colour GIF or PNG format for best resolution with minimum file size.

[neko efecktz]

IAN,
I don't have a schematic done to my exact pin layout and I will try to do one tonight
I have a version of Proteus that I can print from but have only tried once.might take a while.
I have someone calling in shortly for an hour or so then it will be dinner time.
I will start on the drawing as soon as I post this.

Could you tell me what general part of the world you hail from?

I'm from NZ living in Australia for 40 years.
BILL

[Ian.M]

Your code documents the LCD connections adequately.  If Proteus is too much of a PITA, just sketch the  ADC input circuits in BLACK ink on WHITE paper and scan it then reduce to greyscale then 16 colour GIF at a usable resolution. 

N.B. Photos of schematics are rarely satisfactory unless the camera is held rigidly directly over the center of the schematic at a minimum distance of 5x the diagonal paper size, zoomed in to fill the image, under shadow-free noon daylight equivalent lighting

I've already found one bug - main.c line 158:

Code: [Select]

    TRISA =    0b00000;   // UNUSED A/D TO BE SET AS REQUIREDwhich means your AN0 - AN4 ADC inputs are all configured as OUTPUTS!
That certainly wont work for reading analog voltages.

[neko efecktz]

Thanks IAN,
just tried changing TRISA = 0b11111;

still reading 2.5 volts instead of 4.8 whatevwer volts
I thought that they were all turned on as analog
this is part of the code I downloaded.
After changing TRISA the 4.8volts from A0 has gone, but now all of PORTA has about 355mV output

void ADC_Init()
{
  ADCON0 = 0x41; //ADC Module Turned ON and Clock is selected
  ADCON1 = 0xC0; //All pins as Analog Input
                 //With reference voltages VDD and VSS
}

will keep trying
Thank you
BILL.

[Ian.M]

After changing TRISA the 4.8volts from A0 has gone, but now all of PORTA has about 355mV output

That's normal with a 10Meg DVM on an O/C input pin.  See datasheet section 17.2:

parameter D060 (IIL Input Leakage Current), I/O ports, max. +/-1 uA, VSS <= VPIN <= VDD, pin at high-impedance.

1uA through 1Meg is 1V.

[neko efecktz]

here is the schematic.
As I said only tried the program out once before.
A lot of mucking about in hyper_space but i got there.

[Ian.M]

We needed to know about the analog input circuits you were using.  How were you applying the 3.12V you mentioned?

Unless you are doing something weird involving current or resistance sensing,  normal PIC ADC inputs should always be connected to a voltage source, and to maintain the specified accuracy it should have a source impedance of less than 2.5K (required to maintain 1/2 LSB error limit with max +/-1uA leakage current).  If you leave the ADC inputs floating they will certainly give weird results. Due to the current surge required to charge the internal hold capacitor, the reading for a floating pin or one with excessive source impedance will almost certainly not correspond to the pin voltage as measured with a DVM.  A capacitor to ground at the pin >= 0.25uF (for this family) will ensure that the voltage at the pin does not change by more than 1/2 LSB during sampling, which helps stabilize the reading if you are violating the source impedance limit.
You can and should ground unused ones by clearing both their Port and Tris bits.   

[neko efecktz]

Ian.

Just finished dinner,
I am feeding the known voltage directly into the ADC pin.
no series, no shunting.
The two input voltages I was working with are from one of those power supplies that piggyback onto a breadboard.
It is being supplied by a 9V 1A switch mode plug packs.
They are supposed to be 5.00v and 3.30v but they are cheep ones and not very good.
When I first started playing with PICs I started using a 5V 2A plug pack directly and then found it was putting out just over 6.1 volts.
Quickly put that one away.

At the moment I am measuring 4.99V at the input pin with my dvm and displaying 02.5V.
this is with  TRISA = 0b00001 only AN0 set to input.

BILL.

[Ian.M]

So what's the raw ADC result?
It should be 1023 (decimal) or 0x03FF (hex) with AN0 tied to Vdd  and 0 with AN0 tied to Vss, all with the ADC configured for internal references: Vdd as Vref+ and Vss as Vref-.
If its anything else the chip's suspect.

Code: [Select]

    {
        unsigned int V, DisplayVolt, i;
        char Volt = "00.0";
        char buf[10];
        V = ADC_Read(0); //Read Analog Channel 0
        DisplayVolt = V * 2;
        Volt[0] = (DisplayVolt/1000) + 48;
        Volt[1] = (DisplayVolt/100)%10 + 48;
        Volt[3] = (DisplayVolt/10)%10 + 48;
        Lcd_Init();               // initialize LCD
        Lcd_Clear();              // clear LCD
        Lcd_Set_Cursor(1,1);
        Lcd_Write_String ("test");
        Lcd_Set_Cursor(2,1);
        sprintf (buf, "volts = : %a",i);
        Lcd_Write_String(2,5,Volt);
        DelayMs(500);   // Hold for 500 ms



        while(1); //Infinite Loop
    }
        DisplayVolt = V * 2;
is suspect.  1023*2 is 2046.  Your display routine would show that as "2.04"
Try:

Code: [Select]

DisplayVolt = (V * 625U+312U)>>7; // scale by 1000 * 5.00/1024 with rounding

[neko efecktz]

Ian,
I was starting to suspect the chip myself

that large section of code you sent back is from an early attempt at getting it all running.
in the files I uploaded today and i think in the one I uploaded the other day they were rem'd out as a block with /*     */
the correct one is just below it in the code.
 I added the line
    DisplayVolt = (V * 625U+312U)>>7; // scale by 1000 * 5.00/1024 with rounding
 substituting InVolt for V.
now it is only displaying 02.2

How do I check the raw ADC
I have set up a break point on line 343 (may be changed since I sent it to you.
run the program
hover the mouse over key words ie. InVolt, Display_Volt etc
I'm not finding anything that looks like   1023 (decimal) or 0x03FF (hex)

if I hover over Volt_char[x]
I get 5 lines representing the 5 parts to the array
Volt_char[0] = 0;   0x30
Volt_char[1] = 2;    0x32
Volt_char[2] = nul;  0x00
Volt_char[3] = 2;    0x32
Volt_char[4] = nul;  0x00
the display is showing 02.   the last digit is not showing

[neko efecktz]

just thought of why the last digit was missing
I was stopping the program before it had a chance to display it.

BILL,

[Ian.M]

Ah, I was using PFE, (an editor that doesn't do syntax hiliting) as I didn't have MPLAB X open, so I missed the fact it was commented out.   
This chunk?

Code: [Select]

//********************** READ AND DISPLAY ADC VALUE ****************************
else if (FAULT_7==0)
{
        char  Volt_Char[5], DisplayVolt, InVolt;
        ADC_Init();           
        InVolt = ADC_Read(0); //Read Analog Channel 0
        DisplayVolt = InVolt *2;
        Volt_Char[0] =  DisplayVolt/1000 + 48;
        Volt_Char[1] = (DisplayVolt/100)%10 + 48;
        Volt_Char[2] = (DisplayVolt/10)%10 + 48;
               
        Lcd_Init();               // initialize LCD
        Lcd_Clear();              // clear LCD
        Lcd_Set_Cursor(1,1);
        Lcd_Write_String ("DC VOLTz = +    ");  // DISPLAY TO READ
        Lcd_Set_Cursor (1,13);                  //"DC VOLTS = +00.0"
        Lcd_Write_Char(Volt_Char[0]);
        Lcd_Write_Char(Volt_Char[1]);
        Lcd_Write_String(".");
        Lcd_Write_Char(Volt_Char[2]);
 
        DelayMs(500);   // Hold for 500 ms
       // while(1); //Infinite Loop
    }
//********************** END READ AND DISPLAY ADC VALUE ************************
That works a bit differently as I see you aren't stuffing the decimal point into the string. However if InVolt doesn't contain what you expect, something's badly borked.

You may want to insert a line:

Code: [Select]

NOP(); where you want to be able to put a breakpoint, as due to a peculiarity of the debug silicon known as 'breakpoint skidding' it stops on the instruction *AFTER* the breakpoint address.

Applying voltages directly to the ANn] analog pins while they were configured as output pins wasn't very kind to it.  If you haven't got a 'known good' spare PIC, disconnect AN0, set all ANn]pins as inputs (bad practice to leave them floating but if a pin is borked tying it to either rail may cause more problems), and try again using a ANn] pin you haven't previously messed with!  Don't forget to change the code to match the pin you've chosen.

For future reference, copying what Microchip do on their demo boards - i.e .a 10K pot between Vdd and Vss with 0.1uF cap to Vss from its wiper, and a 1K resistor between the wiper and the ADC input - is a far better choice for testing. The 1K resistor prevents any damage if the pin is set as output.  It doesn't quite meet the ADC input impedance specs so it may be out a count or two

[neko efecktz]

I tried several other inputs. No Good.
Looks like as you said, I may have fried the analog inputs.
But would eight damaged inputs all behave the same and give the same results?
Will try to pick up some more chips over the next few days.
I'll let you know how I go.

Thanks for all of your help.
BILL...

[Ian.M]

It depends what's happened to the pin's I/O circuits.   All the ANn pins have a MOSFET transmission gate (a type of analog switch) that connects them one at a time to the actual ADC module input.  If one of those transmission gates is damaged, all other ADC inputs will be affected.  Try tying /MCLR low to hold all I/O pins tristate and go round the ANn pins checking if any are stuck high or low or have excessive leakage current. 

I've taken the HiTech C v9.83 LCD/ADC demo for a PIC16F877A on a PICdem 2 Plus board, ported it to XC8, improved its ADC code for a 10 bit result and changed it to  display the raw ADC result and the voltage to 2 DP using fixed point maths.  You'd have to alter the pin definitions in LCD.h to suit your board, but I thought it would help to have some simple code to run the ADC so you can be reasonably confident the hardware is good.

Here's the main loop so you can see how simple outputting a voltage to the LCD can be:

Code: [Select]

unsigned int adres, last_value;
unsigned int volts, decivolts;
unsigned char outString[20];


Code: [Select]

   last_value=-1; // Force update on first pass
while(1){
  adres=ReadADC(0);
if(adres!=last_value)
{
    volts=( // scale to voltage as fixed point, 2DP, with rounding.
                adres*(unsigned long)(MAXVOLTAGE*100)
                +ADCMAX/2
              )/ADCMAX;
         decivolts=volts%100; // extract decimals
volts=volts/100; //extract integer volts

lcd_clear();
sprintf(outString,"AN0: %3.3Xh, %u.%2.2uV",adres,volts,decivolts);
lcd_puts(outString);
}
last_value=adres;
}

N.B. I haven't got the hardware available to test the port at the moment - I've been careful not to mess up the ADC settings and have simulated it thoroughly so it *should* be O.K.  Its a MPLAB 8 zipped project because I couldn't be arsed to port it to MPLAB X !

[neko efecktz]

Thanks Ian,
I tried your suggestion with tying MCLR down.
Here are the results.
ALL ANALOG AS INPUT                            UP TO >1.0V ON EACH PIN MY HAND PROXIMITY TO THE METER LEAD CAUSES TO TO GO UP
ALL ANALOG AS OUTPUT                         UP TO >1.0V ON EACH PIN MY HAND PROXIMITY TO THE METER LEAD CAUSES TO TO GO UP
AN4 AS INPUT ALL OTHERS AS OUTPUT UP TO >1.0V  ON EACH PIN    DITTO
AN4 AS OUTPUT ALL OTHERS AS INPUT UP TO >1.0V  ON EACH PIN    DITTO

WHILE THE PICKIT3 WAS CONNECTED THE VOLTAGES WERE ALL DOWN AROUND 70mV

I have some work to do around the house today but I will look at using the code you uploaded.
I will also look at RS COMPONENTS for some more chips.
Is there much work in conversion from PIC16F877A to PIC16F887?
I know that the CLK1/OSC1 and CLK2/OSC2 are shared with RA6 & RA7. and MCLR is shared with RE3

There was another 40 pin chip i think you mentioned one time, would you remember what it was?.

Thanks

BILL.

[Ian.M]

Tying /MCLR low disables the PIC, (assuming it isn't one that supports disabling /MCLR) so it doesn't matter what code you have in it.  I assume you were measuring between Vss and each pin.  The results indicate that none of the pins are hard-shorted to Vss or Vdd.  Repeat with the meter between Vdd and each pin and see if the voltages are similar which would indicate input leakage currents of around +/- 0.1uA, well within spec.

Its *REMOTELY POSSIBLE* there is a shorted transmission gate, but they are a lot harder to diagnose because only one is normally turned on at a time, for a very brief pulse for ADC sampling at the start of each conversion.  Just about the only way to detect that would be to set all possible inputs as Analog, and run code that samples the ADC as fast as possible discarding the result.  Pull the input being sampled high, then check all the other inputs with a scope.  If any have a brief high going pulse at the sample rate, that channel has a shorted transmission gate.   Repeat, sampling a different pin to reduce the possibillity you picked a bad channel to sample.

Other possibilities are that the 6.1V overvoltage on Vdd damaged the PIC.  This is extremely unlikely, unless that was just an average and the actual USB PSU output was very spiky as its rated for up to 5.5V normal operation and to withstand 7.5V without damage.

You can also get odd things happening if any of the Vdd or Vss pins are disconnected, or there isn't enough decoupling near the chip.  As a rough rule of thumb, use 0.1uF between Vdd and Vss right next to the chip at *EVERY* pair of Vdd and Vss pins.  The ADC converter pulls significant current spikes from +Vref and -Vref during operation so if the supply pins are poorly decoupled for internal Vref, you can get bogus results.

Are you 100% certain you have a 4MHz crystal installed?  Any crystal above 10MHz would result in your code not giving the ADC a long enough Tad, which is known to cause incorrect results.  Also a much lower crystal frequency can cause problems - if Tad is far too large, enough charge leaks off the sampling and successive approximation caps to give a bad result.

Otherwise, once you've eliminated low probability hardware problems, it must be a code issue, which is why I ported the HiTech PICdem 2 Plus code, so you'd have some sample code for the ADC that has a high probability of working.  You can either use its LCD routines, patching the pin and port definitions to match your board, or patch in your own LCD library.  It uses sprintf() for formatted output, which one generally avoids on small 8 bit systems because the printf routines are generally bloated overkill for most applications, however that gets you working fixed point display with a lot less user code than other options.

The PIC16F887 is fairly similar from a C programmer's point of view.  The ADC module is a little different - instead of selecting analog input configurations by row number from a table, each input has an individual control bit, (in the ANSEL and ANSELH SFRs).  The Vref+ and Vref- source selections also have individual control bits.  However once you've got it configured, you use it in the same way as on an '877A.   You don't need to worry about the differences in the oscillator pins - in any of the crystal modes or EXTRC they are '877A compatible. Its only if you use the internal oscillator that you get them back as extra I/O pins.  Generally one leaves RE3 configured as /MCLR, with an external pullup, but sometimes it can be convenient to make it an input.  However it must *NOT* be left floating.  I have one on a demo boad with a breadboard, so if you get stuck I am likely to be able to actually run your code on real hardware.

[neko efecktz]

IAN,
I have a bit of time to do some writing but still have some work around here to do.
The missus gets cranky if i spend too much time on line.
And wasting time and money on that bloody junk.
I tell her IT'S A HOBBY, women, cant live with them not allowed to shoot them.
I will see if I can insert your code into mine tomorrow morning.
or look at the full Hi-Tech code.

I will also fire up my old CRO , Tektronix-422 circa 1965 according the the dates on the pcbs.
has micro valves called Nuvistor
The 8056 Nuvistor used in the input amplifier of the 422 can be replaced by a MPF102 JFET.
It works so it might do the trick.

The 6.1 volts I mentioned was with my first project using PIC16F84A.
One night I was working late with this one and i accidently inserted the chip into the ZIF base back to front. power pins are dirrectly opposite each other in pin 5 and 14 the two middle pins.
Took a couple of minutes to figure out why the PICKIT-3 couldnt see the chip.
I spent some time trying to see if I had configured PICKIT-3 wrong.
Chip still works ok. is running a display inn front of me now.
Can't remember if that was with the 6.1v or not.

I have placed 4 bypass caps each 0.1uF in the board.
One each side of the chip and the others are about 30mm away basically at each end of the chip.
One of them is about 10mm from the 10uF tant cap.


Attached is a PDF of my board.
First double sided board in over 30 years but done with laser printer / iron on process.
It needed about 18 feed through links.
I have made a couple of mods to it and have put in a couple of bodge wires so I can fully use PORT B for the display and ICSP
I still have a little work to do on the revised version.
If I go for the PIC16F887 I would still use the same board and use MCLR as a reset as in the current board..

Thank you once again for your help.

BILL

[StillTrying]

it must *NOT* be left floating

Yep.
Before you give up on that chip go around it and check there's no floating inputs, it's easiest to just set them as outputs, - just one floating input digital or analog can make it go nuts.

[Ian.M]

The PCB layout doesn't look too bad.  At least its got enough decoupling.   I'd have used a topside ground plane, but I'm fussy that way!  I assume you've had other stuff running OK on that board.

A reversed supply could have FUBARed the whole ADC module  (or any other part of the chip), but usually on a current limited supply, that sort of mistake doesn't do any damage as the I/O pin ESD protection clamp diodes short out the supply.  The '877A has 33 I/O pins, each with clamp diodes with a max rating of 20mA so the odds ar it will survive if the supply current limit is under 660mA. 

Its probably not worth chasing down the remote possibility of a blown transmission gate with your scope - I'd jump straight to trying different code. or a different PIC if you have one handy.   

I generally buy chips for development three at a time - one to use, one for a spare , and one to keep in its packet till I need one that's 'factory fresh'.

[Ian.M]

Meanwhile I've been putting together a fast fixed point unsigned int to ASCII routine that avoids any use of the % modulo or / division operators (except for division by 2 because its not safe to right shift a signed number (implementation defined sign bit handling) and one cant assume char is unsigned).

The intention is to replace the slow/bloated printf in the HiTech based code I posted or the clumsy digit extraction with % and / by powers of 10 in your code.   Unfortunately I haven't commented it properly yet as the ancient DOS compiler I was testing it under doesn't support single line // comments.

Code: [Select]

/*************************************************************
* utoafp() - converts an unsigned integer to 5 digit ASCII
*    string with leading zeros and (optionally) inserts a
*    decimal point.
* Parameters:
*    n - unsigned integer to convert.
*    s - pointer to string buffer, min. 7 bytes.
*    p - places in front of the d.p.
*    dp - no. of decimal places, 0 won't insert a '.'.
* Returns:
*    pointer to the string or NULL if theres been an error
*    (i.e. if n is too big for the number of places p).
**************************************************************/
char* utoafp(unsigned int n, char* s, char p, char dp){
   const unsigned int subtbl[]={40000,4000,400,40,4};
   const char subtbl_len=sizeof(subtbl)/sizeof(unsigned int);
   char digit,e,t,j, *sp;
   unsigned int q;

   if(dp>5 || dp<0) return(NULL);
   if(p>5 || p<0) return(NULL);
   if(dp+p>5) return(NULL);

   sp=s; 
   for(j=5-p-dp;j<subtbl_len;j++){
      if(j==subtbl_len-dp) *(sp++)='.';
      digit=0;
      e=4;
      q=subtbl[j];
      do{
         if(n>=q){
            digit+=e;
            n-=q;
         }else{
            q>>=1;
            e/=2;
         }
      }while(e);
      if(digit>9) return(NULL);
      *(sp++)='0'+digit;
   }
   *sp=0;
   return(s);
}
Usage:

Code: [Select]

r=utoafp(1234, s, 2, 3);with s defined as an array of char and r as a pointer to char, will return a pointer to the string "01.234".  If you try to convert something that wont fit, it returns a NULL pointer.  It does NOT add a leading zero in front of the d.p. if the no. of places (p) in front of the d.p.  is 0.  if the decimal places (dp) is 0, it omits the d.p.

[neko efecktz]

Good morning Ian,
I have Just started to look at he Hi_Tech code you uploaded and there seems to be a file or two missing.
I think there is supposed to be a couple of  files called DELAY.C and LCD.H

*   LCD interface example
 *   Uses routines from delay.c
 *   This code will interface to a standard LCD controller
 *   like the Hitachi HD44780. It uses it in 4 or 8 bit mode

If You could find it and upload it I would appreciate it.

I ordered some chips today should be here in a couple of days.

Thanks for all your help.
BILL.