[Question] ADC multiple reads and PIC16f1826

[murgui]

[temtronic]

OK most will not reply as it's a P 'program'....

Well they come from a busted program called Proteus! Please read the 1st sticky.

some points to ponder

0) get real hardware and wire it up ! be sure a 1Hz LED program works,then a 'Hello PC' program.No one here can FIX Proteus!!!

1) go back to standard RS232 serial and dump the results to a PC

2) use ONE thermocouple and get code working correctly for it

3) floating point is NOT required and will take 'forever' to do.

4) re: T[i]=(((float)(mesura[i])/1024.0)*5-227.89)/-1.9958;
the array T is a 16 bit integer so dumping a float into it is useless. I don't think the compiler will store a float there,just convert it back into int16.


that's just a start of it.....
Jay

[murgui]

The Proteus thing is just the I2C feedback. I think the question is fine as the problem is in the code, not the simulation.

I already have the hardware but I guess it won't work in the hardware if it doesn't even function properly in the simulation.

I set 1 ntc and it worked perfectly sending the temperature to an LCD so I suspect the problem may be in the ADC configuration.

I take notes about the float use .

[temtronic]

You 'assume' that Proteus is working 100% and that is NOT the case ! It is well known for bugs, errors and faulty DRCs that can easily give you false results that's why you need to get rid of it and use real hardware.
Proteus projects will 'work' 100% even though you do NOT connect a crystal and caps to the 'simulated' PIC !! So, if you made your hardware like that, it'd never work..yet...'it worked in the simulation'......

I have to stress

1) code a 1Hz LED program. get it to work. That will confirm the hardware is basically correct, that the compiler works, that the programmer is operational and thet the PICs fuses are OK.

You need to start from known, working code !!

Next step is to get communications to/from a PC. That's the simple 'Hello PC' program using the UART/max232 chips or TTL<>USB module. It's super important to be able to 'dump'(send), test data like ADC raw data,converted results and 'step xxx completed' messages to a PC. this way you can 'see' how the program is operating.

break down your code into smaller segments,confirm each works as expected(over the full range of inputs) before building more complicated code.


Jay

[murgui]

Fine, I will follow your advice

Thank you

[Ttelmah]

As separate comments:

What are you trying to do with the I2C?.

The standard sequence with I2C, is:

For write.
Start
Send device address/write bit
Send register address to use
Then send the data
Stop.

For read.
Start
Send device address/write bit
Send register address to use
Restart.
Send device address/read bit
Then read the data, with NACK on the last read
Stop.

You are not addressing the device you want to talk to. Either the I2C address, or the register address (there are some devices that will accept the lack of the latter, automatically starting from register 0, but you need the former on all I2C transactions....).

You are defining a 'slave address', but never sending it....

On Proteus, the current 'sticky' understates just how problematic this is. Time spent getting code 'working' in Proteus, is 99% wasted. Things that work perfectly in real chips, don't work in Proteus, and things that work in Proteus, don't work on real chips. Have a search here about this.

5.008, is 'worrying'. This was at best a beta version, pre-dating V5, really starting to work. This may well cause you problems. At the time when this was available, 4.141, was considered the 'working' compiler.

Have a look at this thread:
<http://www.ccsinfo.com/forum/viewtopic.php?t=54661>

Which shows an integer solution to volts from the ADC, and consider whether this could be applied to your task (it can...).

Then look at 'make8', much more efficient than your byte conversions.

[PCM programmer]

Fundamental problems:

You have no storage allocated for the arrays below:

[Ttelmah]

I have to extend on what I said earlier.
With the current I2C operations, things are definitely not going to work. As it stands the I2C bus direction will turn round, if the bottom bit of the first byte is a '1', so the transaction will then be invalid. What is being done is directly in breach of the I2C specification, which _requires_ the first byte after the start to be the address and direction control.

[Mike Walne]

[PCM programmer]

He's also using a couple of the upper ADC channels.
Specifically, channels 9 and 10 and he handles those in a separate loop.

[murgui]

Hello everyone!!
Excuse my tardiness, I'm pretty busy with the university work.

I'm very grateful with all the help you lend me.


I'm not addressing any direction because I was just trying to figure out if the information sent was correct and as Proteus captures the information without an address I didn't add it to the code. In addition, the slave definition was written for the future and I should comment it.

I will try to find and use the 4.141 version as you suggest. I casually had already seen that post and, in fact, based my code on it. Also looked for the make8, it's great!! thank you very much!!

The problem that was driving me crazy was, as I expected, in the array code as I didn't know well how to treat it. PCM's array length declaration was the advice I needed. Also, not reading all the ADC was a typo, thank you very much for pointing it out.

As I have already received my PICKit I can now start trying it in real hardware. Soon I will put a hand on it and I expect to get all running flawless.

I want to thank you very much for all the help, you are great guys!!

PS: Do you recommend any specific book about CCS C Compiler?

Thank you, Nicolas.

[Ttelmah]

Key thing to definitely have in your hand, is K&R. "The C programming language". This was the original book published by the authors of C. The second edition, had the initial extras that were introduced with ANSI C, and it is this that CCS most closely follows. Except for the tiny differences implicit in this being an 'embedded' language (so no file system unless you add one, direct access to the hardware, serial via a library, rather than an OS, and no actual 'command line' being passed to the program), CCS follows the syntax, and concepts in this 99.99%. As a 'reference' pretty vital, but not a good way to learn!.
There have been a couple of CCS specific books written, so possibly consider adding one of these.

You are now starting to see the dangers of Proteus (Isis). The ADC data is done by register injection, so doesn't care if the pin really does connect to a suitable voltage. This is a typical 'caveat'...

[murgui]

I also wanted to know about the resistance limitation when using the ADC, I've seen many forums saying that 2.5KOhms is the absolute maximum and I have a larger resistance.

For the temperature I have a voltage divider with the NTC in parallel with a 18.7KOhm and both in series with a 5KOhm. The ADC will register the voltage of the thermistor. The linked image will explain better.

http://postimg.org/image/bji164t35/

The PIC i'm planning to use is the 16f1826. I' ve been looking at the datasheet but I didn't find anything related.

[Ttelmah]

Re-read the ADC section of the data sheet!....

Section 16.4 'A/D acquisition requirements'. Line in heavy text in this!.

For your ADC up to 10K is OK. This does vary with chips, and most of the faster ADC's require lower impedances.

Be aware that for really good accuracy, an external Vref, will improve results hugely. The supply is not a good way to supply the ADC reference.

[murgui]

I hadn't seen that section, I'm such a newbie reading datasheets and sometimes I find myself lost looking for specific information.

Thank you very much! I will give a look to the external supply but i'm afraid it will create so many problems. I don't understand why the systems should be supplied independently.