Not interrupting at the expected rate? (via MPLAB sim)

RoGuE_StreaK · Joined: 02 Feb 2010 Posts: 73

Hi, I've finally gotten simulation happening under MPLAB so I can time various functions etc., but it's indicating that my interrupt routine isn't happening at the rate I calculate?

PIC: 18F2620 with 20MHz crystal, 1/4cycle
Compiler: CCS 4.057
MPLAB IDE 8.53

Timer0 interrupt is set to RTCC_INTERNAL|RTCC_8_bit, which by my calculations should be:
20MHz => 5MHz cycle
5,000,000 / 256 = interrupt every 51.2us

but according to MPLAB sim's stopwatch, it's happening about every 102.2 - 102.6us?

Can anyone tell if I've done something wrong here? Code stripped back, still getting the same timing; Interrupt sets flags for which ADC channel to read, and whether to read, plus servicing of the debounce system and an LED PWMing up and down.

.h file:

Ttelmah · Joined: 11 Mar 2010 Posts: 19506

First comment. Have you set the frequency in the simulator to 20MHz. This has to be done separately, and unless it is, the simulator's idea of speed will not be what is expected...

Now some comments on the code.
First, read the data sheet about the ADC. Should 'ADC_CLOCK_INTERNAL' be used at 20MHz.....

Second, the adc readings will take a lot of time. Consider changing your state machine, so that this time is also handled by the interrupt. So, something like:

RoGuE_StreaK · Joined: 02 Feb 2010 Posts: 73

Thanks Ttelmah, I'll have a closer look at your code tonight when I get home from work.

Sim clock is definitely set to 20MHz.

RE: ADC clock, I'm pretty fuzzy on that bit, I've mainly just been looking for examples on the forum and trying to implement them; found the TAD vs Device Operating Frequencies table, but it doesn't list 20MHz as such, it lists 22.86MHz with 16TOSC, does this mean I should set the ADC clock to ADC_CLOCK_DIV_16?

My theory for the state machine (as it were) was to toggle through the setting and getting of the ADC based on interrupt, so I'd set a channel, wait til the next interrupt, read the channel, wait, etc.; as from my rough research people seemed to reckon about 20us between setting and reading was the way to go? But obviously I'll go with your method if you think it's the better way (pretty sure I noticed things being skipped along the way with my method).

On a related note, is there any way to force an interrupt to return to the START of a main loop, rather than the point where it interrupted? I guess that's the point of your do_action flag, to make sure it doesn't skip a function when it returns to main past where that function is, ensuring the next interrupt doesn't increment things before they've been looped to?

Ttelmah · Joined: 11 Mar 2010 Posts: 19506

The table in the data sheet, lists _maximum_ clock rates for a given divisor. So you can use DIV_16 fine.

There are a whole sequence of things that happen with the ADC. Internally, the ADC value is read from a capacitor inside the chip. This takes time to charge to get near to the actual voltage outside (depends on the source impedance, the internal resistances, the capacitor value itself, and how close you want it to get.....). The capacitance, and resistances inside the chip vary with PIC model. The sequence is:

1) Connect the external voltage to the capacitor (set_adc_channel).
2) Wait for the capacitor to charge.
3) Start the ADC conversion
4) Wait for the conversion to finish, and read the result.

Now on old PICs '2' was typically around 10uSec, to charge within 0.5 of a 'bit' level. On your chip it is only 1.2uSec, but longer acquisition is generally 'better', but at a cost in sample speed...
The simple 'read_adc' instruction puts '3' and '4' together in one instruction, or can be split using the constants I show.

The time between '3', and '4', is 11 cycles of the ADC clock, plus one processor instruction cycle. So with processor clock/16, will take (16*11)+4 clock cycles (180). 11.25uSec.
It is entirely down to whether you want to save time in the instruction loop, whether it is 'easier' to simply let the standard CCS instruction do it's default operation, or trigger the reading, and then actually take the result on the next pass. You can reduce the states used by one, by simply combining the 'select' operations with the 'reading' operations, selecting the new channel, as soon as the reading has been taken.

Best Wishes

RoGuE_StreaK · Joined: 02 Feb 2010 Posts: 73

Thanks Ttelmah, I've tried your code (with a couple of fixes) and I still get the same timing, so tried completely stripping it down to nothing but a while loop and an interrupt, and I still get the same timing:

RoGuE_StreaK · Joined: 02 Feb 2010 Posts: 73

OK I get the "phase==last" bit now, did some reading on "enum", essentially instead of saying "0,1,2,3", you are giving it readable names, "select,start,read,last". So "last" should always occur anyway if do_action == false. Unless it hangs on "adc_vals[Adc_channel] = read_adc(ADC_READ_ONLY)" if there is nothing to read from?

But yeah, the issue still remains that even the simplest of code with an interrupt is giving me a 2* difference from what I expect under the sim's stopwatch.

Ttelmah · Joined: 11 Mar 2010 Posts: 19506

OK.
The reason here is very simple. You are not turning the prescaler 'off'.
If you look at the data sheet, you will find that the clock always routes through the prescaler, with the 'default' value here (0), giving clock/2. To turn the prescaler completely off, a separate bit in the timer register has to be set (PSA).

setup_timer_0(RTCC_INTERNAL|RTCC_8_bit|RTCC_DIV_1);

Best Wishes

RoGuE_StreaK · Joined: 02 Feb 2010 Posts: 73

Oh. Huh. I just kinda "assumed", based on code that I'd found around the place, that there'd be no prescaler if I didn't specify one. Lesson learnt; never assume anything in this game!

Oh well, learned a few other things along the way as well, which should give me a bit more of a footing as I progress with this. For one, I realised that I don't really need to sample my ADC anywhere near as often as I had it set up previously, I reckon maybe 10 samples per second for each channel should do the trick for what I need. And for getting some baseline figures from this procedure, I should probably store to an array in SRAM, then kill everything off and dump the data via printf, as printf takes waaaaay too long to be doing it inline. I only need a couple of seconds of data for various typical scenarios to see what kind of processing I need to do on my data.

Thanks for your help Ttelmah, and I appreciate that you try to "nudge" rather than spoon-feed.

RoGuE_StreaK · Joined: 02 Feb 2010 Posts: 73

I'll post my next query here as it relates to a few of Ttelmah's points raised about the ADC and also printf times, figured it's best to continue in one place where all of the info is in one thread.

Interrupt is all sorted now, I actually tweaked things a bit so I'm again using an RTCC_DIV_2, but this time I know that's what I'm doing, and have managed to tweak the counter with a preloaded value that gives me almost exactly the interrupt frequency I was after, 16kHz (getting 62.4uS interrupt now).

As stated in my last post, I need to get some baseline reading from the ADC system in order to determine what kind of maths I need to do for the rest of my project. But if I want to do, say, 100 samples per second (*3, for X,Y and Z of the accelerometer), it wouldn't work trying to send this data straight out via a printf. I really need to store a certain amount of data, then dump the lot to the PC after shutting down the ADC system etc.

What I'm not sure of is how much data I should be expecting? The 18F2620 I'm using has 4KB of SRAM. I assume some of that will be taken up by general processing (though I'll be stripping the system right back to be ONLY the ADC state system), so say for argument's sake that there's 3KB free. The ADC is set to 8bit, as is the storing array. Does this mean that each sample is a BYTE, and so there should be room for 3000 samples? So 3 sets of samples (X,Y,Z), each sampling 100 times a second, giving ten seconds worth of recording before I stop the ADC, plug in the serial cable, and press a button to start a printf dump? Or am I out be a factor of 8, or worse?

I want to "put it through the motions" while sampling at the same rate as it would "for real", instead of how I last tried to sample data, which was just running a while loop and printf'ing on the fly; obviously a much slower rate than what I want to be sampling at, but I didn't realise that until Ttelmah pointed out how much time it takes to send the data.

Oh, on that note, what's a "safe" baud rate? I was just using the default 9600, is 57600 or 115200 fine?

Thanks for any help or pointers, I tried searching for answers but either no-one is doing store-and-dumps in this manner or I don't know what the correct terms are.