Fault in ADC module?

blackcattech · Post by **blackcattech** » Fri Mar 16, 2012 8:47 am

I'm writing some code for the PIC18F14K22 which uses AN7 as an analogue input. On compiling the code I got an error that AN7 wasn't defined. On checking it seems AN0-6 and 8-11 are defined, but not AN7.

Looking deeper, the ADC module seems to have a mistake when it comes to defining channels.

It defines AN7 if the processor define sets _adc = 8, sets AN8 to 11 if _adc=12 and AN12 to 15 if _adc=16.

Now, surely what is missing here is that if, for example, _adc=16, then only AN12 to 15 will get defined and not AN7 to 11. I'd have thought it should check if _adc was greater than a value, not equal to?

Has anyone else come across this? I've updated to the latest version of SE but the module is the same.

Jerry Messina · Post by **Jerry Messina** » Fri Mar 16, 2012 10:19 am

I think there was a discussion about this a while back.

The pic18 ADC hardware has changed over time and the module hasn't kept up (it's from 2007). The last time I counted, I think there were over 14 different ADC modules, so it's easy to see why. I'd take a look at the datasheet and compare that to the chip you're using just to make sure it matches up ok. You'll likely find other things in that module that don't fit the K series part too.

Personally, I'm not sure that the ANx constants really get you very much. The adc channel is just a four or five bit value from 00000-11111, so you can just use that channel number in place of 'ANx'. I suppose you can argue that it could help detect valid settings, and I suppose that's true if you felt like going through all 200+ chips and 14 different ADC's and fixing it. So far, nobody's jumped up to volunteer.

From my experience, it doesn't usually take long to find out you've specified the wrong channel.

blackcattech · Post by **blackcattech** » Fri Mar 16, 2012 11:22 am

Yes, it does seem a bit pointless that all it does is give ANx the value x. It would be more useful if it flashed up a preprocessor message if you tried to specify a channel that didn't exist on that PIC.

I wonder if it is a hang-over from PIC16 days when selecting a channel could be more complicated and varied a lot between PICs.

I must admit I seem to be finding problem after problem with Swordfish on this prototype - I'm seeing issues at the moment with the DelayUS and DelayMS routines - they seem to be giving delays longer than the values I'm entering. I have set Clock at the start and am running at the correct oscillator speed.

For example, I've just reduced a delay from 500us to 250us and the corresponding pulse has reduced from about 2.2 msec to 1.1 msec... All I'm doing is turning an LED on and taking an ADC reading so the pulse should have only reduced by 250us.

I like Swordfish but I'm starting to think I've had enough of having to find compiler-related problems and want a language that just works so I can concentrate on fixing problems in my code...

Jerry Messina · Post by **Jerry Messina** » Fri Mar 16, 2012 12:53 pm

I must admit I seem to be finding problem after problem with Swordfish on this prototype - I'm seeing issues at the moment with the DelayUS and DelayMS routines - they seem to be giving delays longer than the values I'm entering. I have set Clock at the start and am running at the correct oscillator speed.

Care to post the code? Using the SE version, MPSIM and a 14K22, DelayUS and DelayMS measure pretty darn close to what they should be.

I like Swordfish but I'm starting to think I've had enough of having to find compiler-related problems and want a language that just works so I can concentrate on fixing problems in my code...

I hear your pain. When you find that compiler, please let me know. They all have learning curves, and the ones I know of that don't have any issues also don't have any features. It seems the libraries are always a problem, esp. any that are hardware-related.

blackcattech · Post by **blackcattech** » Mon Mar 19, 2012 9:35 am

I've had a chance to look in to this in more detail and it seems I was partly mistaken. I'm working on a system which pulses an IR LED periodically. I'm eventually going to do this via an ISR but for now I'd hard-coded the delays. The pulse rates I was getting were far lower than expected with the delays I'd put in.

However, the issues appears to be that reading the ADC and a few simple if-then commands must have a much higher code-load than I expected. Increasing the clock rate gets closer to the expected pulse rate so the delay commands must be about right and it is simply that the rest of the code is taking much longer to execute than expected.

I guess this is one problem coming from C to Basic, you have less understanding as to what is actually going on so it is harder to estimate speeds and what part of the code needs optimising.

Jerry Messina · Post by **Jerry Messina** » Mon Mar 19, 2012 10:17 am

Well, the nice thing is that all the source files are right there so you can see what's going on.

Most things translate very efficiently... some better than their C counterparts. After compiling you can use the IDE Assembler View (F2) to take a look at the asm output. Very instructive even if you're not an asm programmer (and I'm not).

Looking at the source, the ADC.Read() call has a built in acquisition delay that defaults to 20us + overhead which can be even larger if you're running with a slow clock (add 24us @ 4MHz according to the comments).

If you want max performance and need to do other things in that time, I'd separate out the triggering/waiting for the ADC into two routines.