Estimating processing capacity

[micrometal]

I am trying to measure the elapsed time between two events, in the region of 20 to 30 minutes apart, to a roughly 1msec precision. I have a clock crystal oscillator (32768kHz) and a 7-stage binary divider delivering clock pulses to a 20X2 at nominally 4msec intervals and I am counting the pulses using the following code (some code omitted for clarity) ...

        setfreq        m64                ' Run at 64MHz
        hsersetup    B9600_64, 1            ' 9600 baud, background mode
        hintsetup    %00000010            ' Interrupt on falling edge on B.1
        setintflags    OR %00000010, %00000010

        state = 0                      ' Initial condition
        low        clk_gate            ' Inhibit timer count
      
main:    if hserflag > 0 then goto BT_in    ' Check for background Bluetooth msg
        if state = 2 then                ' Counting clock pulses
            if clk_in = 1 and latch = 0 then
                inc    clock0               ' Counter uses three bytes
                if clock0 = 0 then : inc clock1 : endif
                if clock1 = 0 then : inc clock2 : endif
                latch = 1                ' Prevent double counting
            endif
            if clk_in = 0 and latch = 1 then
                latch = 0                ' Unlatch for next pulse
            endif
            goto main
        endif
        if state = 0 then                ' Set up initial conditions
            
        endif
        if state = 1 then                ' Prepare to start
        endif
        if state = 3 then                ' Prepare to finish
        endif
        if state = 4 then                ' Hold data for retrieval
        endif
        goto main                    ' Main loop

As you can see other tasks have to be performed, such as processing Bluetooth commands received in the background and counting and debouncing a second (interrupt) input, and I am wondering how much processing I can do before the main counting loop is impacted; I cannot afford to miss any timing pulses. I know that "how much processing" is difficult to quantify, so an alternative question could be "How can I detect that a count has been missed?"

 

[papaof2]

Debounce? Use an external 555 timer as a one shot timer. With the proper intervals set, it will only deliver one pulse per period IF an input pulse is present. No need to tie up the PICAXE with something the 555 can probably do better.
I know we like to keep the minimum parts count and power use, but a CMOS 555 is a near-zero-power device when waiting.

Processing Bluetooth? Effectively you're processing serial with hardware but that is a potential bottleneck. How many characters? What speed? How long between data bursts?

How many things are likely to happen at or close to "the same time"? That can all add up -

I don't know if anyone has ever done real world loading like that to see how much can be processed at (almost) the same time before there is data loss of some type. Be nice to have a spreadsheet that you could fill in cells for: BT y/n, speed, # characters and so forth and get a calculation of "17% of processing capacity used", Interrupt type X y/n and get "5%% of processing capacity used per interrupt." GOSUB "1/2 of 1% of capacity used for each GOSUB" and also for all the other calls...
That would be an incredibly useful reference but it would take LOTS of testing and whatever the original sheet contained would get "Can you add: bit-bang serial, ADC, READTEMP, etc., etc.?"

 

[inglewoodpete]

You don't mention the accuracy you require with your timer or the chip you are using. Since you use "SetIntFlags" and "SetFreq M64", I'm assuming it's an X2 of some sort. I have successfully used the background timer with 100mS intervals and interrupts enabled, which leaves plenty of time for foreground tasks, including background hSerial with the scratchpad. However, don't use Delays anywhere or loops in the Interrupt routine.

 

[micrometal]

Thanks inglewoodpete - that is the sort of answer that I was looking for. I am using a 20X2, and using timer3 to avoid using Pause. The circuit seems to be working well on the test bench but I don't have the experience to get a feel for the margins. I don't want to add more hardware because I am limited for space.

 

[inglewoodpete]

Thanks inglewoodpete - that is the sort of answer that I was looking for. I am using a 20X2, and using timer3 to avoid using Pause. The circuit seems to be working well on the test bench but I don't have the experience to get a feel for the margins. I don't want to add more hardware because I am limited for space.

Use SetTimer and SetIntFlags rather than Timer 3. Zero and Enable the timer at the start of the period. Test for TOFlag in the interrupt routine and increment your timer words/bytes if set. Clear TOFlag and reinitialise the interrupt flags ("SetIntFlags") on exit. At the end of the period, disable the timer, read your timer variables.

 

[oracacle]

Pulse output and debouce without using pause on X2

After recent posts in another thread, I got to thinking that after jumping through a few extra hoops, using a timer to allow for a sudo multi tasking situation could be achieved. It a little more granular than I am used to. Using the settimer instead of timer3 should be possible but i haven't...

picaxeforum.co.uk

You can decide without pause using timer 3 machine you don't need the 555 for that.

Iirc hippy did a timer a few years ago that would get you the acceptance you need. I'm not at home so don't have any example code ATM

 

[Buzby]

A few years ago I did a project where I used 'settimer' to generate interrupts at 1mS, i.e a thousand interrupts per second !.
It was a race timing project, but seems similar to what you need.

This was on 28X2 because it needed lots of pins. Obviously it ran at 64Mhz. Even at 64Mhz I knew I could not spend much time in the interrupt processing.

To see how long my interrupt routine was using, I set a pin high at the start of the routine, and set it low at the end of the routine. By viewing the pin on an oscilloscope it was possible to get a feel for how much time was spent in the interrupt. My interrupt routine had about 80 lines of code and used most of the available 1mS.

I also wired a couple of LEDs, one toggling to show main loop activity, and the other showing interrupt activity. This gave me an at-a-glance indication that the system was working OK.

There are a few gotchas when writing interrupt routines running at such high speeds, although if your interrupt is at 4mS you may not face the same problems as I had at 1mS. The main problem was serial comms in the main loop.

One thing to watch out for is what sensors you are using to detect events. Some of the photosensors I tried had response times in the 10's of mS, obviously no use if you a trying to measure with 1mS resolution !.

 

[micrometal]

A few years ago I did a project where I used 'settimer' to generate interrupts at 1mS, i.e a thousand interrupts per second !.
It was a race timing project, but seems similar to what you need.

Yes - that is similar to my situation, except that my interrupts occur around once a second, and are quickly serviced, and it is the main processing loop that needs to maintain a 4msec responsiveness. But none of this is going to approach 80 lines of code so that makes me fell pretty confident. That is exactly the sort of information that I was looking for.

Bluetooth communications are incoming single byte commands and 6-byte responses. The application will be useful even if the result data is not transmitted until after the timing period is over, but interim results would be nice-to-have. It was while considering this that I realised that I could not think of a way to conclusively test if the timing loop had been compromised, or enough experience to make a sensible judgement, hence this question to the forum. I do toggle an LED in the timing loop every time that clock0 equals zero (removed from the snippet in the first post) and another LED when an interrupt is received (using the timer3 trick that I had found already in oracacle's post) and all looks good there.

[Edit : Forgot to mention that the interrupts are generated by a Hall effect sensor; no photo cells involved.]