Hi, I was wondering whether anybody else is struggling using the Ticker object? I setup a Ticker function which seems to work for a while then after several minutes will stop working. Also if I try to change an attached functions parameters the Ticker also seems to stop working although if I reset mbed it will start to work again. I'm using two Ticker objects, one called every 5us and the other variable, which may be the problem. Any ideas? If not then is there anyway to reset/restart my program running from main() again after I've altered the parameters?

I've had no problems with Tickers. You'll need to show us your source to progress your problem :)

If the ticker interval is less than the time it takes for your callback to execute, you will have issues. Since 5uS is a pretty short time, your callback should at most be only a few lines of code...

You might try experimentally lengthening the ticker interval to see if that makes a difference.

My callback is 6 lines of code. I am basically reading the A/D convertor at its maximum rate and displaying the level on an LED. The Ticker calls the following function:-

void check() { float a;

a=level; low=(a<0.24); high=(a>0.61); oc=(a>=0l.24 && a<=0.61); if (pc.readable()) setup(); }

I assume that interrupts aren't disabled during the call. If so is it possible to disable them to give the function longer to execute?

Thanks

Hi Lee,

a code snippet doesn't help that much as it doesn't show the full context.

For example, your example appears to show your function void check() as a Ticker callback yet the function prototype for a ticket callback is void func(void); which doesn't match your code.

Have a read of this thread which may help you understand the context of Ticker callbacks. The reason I suggest this is your "callback" above has if (pc.readable()) setup(); } in it that suggests some form of output is going on inside a Ticker callback.

The best way to show the code is to publish the program and then provide a link to it. That way we can see the code and it's context. A lot of the forum posts regarding "my program suddenly stops working after N minutes" always seem to boil down to the way people are using callbacks (Ticker, InterruptIn, etc).

Just for the heck of it, I tried your code snippet. As expected, it won't execute in 5 uS. I was able to make it go in 6uS, however, just to show how close to the edge it is :-)

I suggest you try Andy's approach of having the ticker simply set a flag, then shift the bulk of the processing to the main program.

Here's what I used for the test:

#include "mbed.h"

DigitalOut myled(LED1);
Ticker testticker;
Serial pc(USBTX, USBRX); // tx, rx

float level = 0;
float low;
float high;
int oc;

void setup () {
    wait_us(1);
}

void check() { 
    float a;

    a=level;
    low=(a<0.24);
    high=(a>0.61);
    oc=(a >= 1.24 && a<=0.61);
    if (pc.readable()) setup();
 }

int main() {
    // Hangs if time is < 6 us
    testticker.attach_us(&check, 6);
    
    while(1) {
        myled = 1;
        wait(0.2);
        level += 0.1;
        myled = 0;
        wait(0.2);
    }
}

When the ticker is set to run at 6 uS or above, LED1 flashes continually. When set to 5 uS or below, LED1 stays on constantly, indicating the stream of ticker calls is chewing up all the CPU cycles.

- hb

Hi, thanks for your help, most appreciated. I have now removed the check routine from the Ticker and placed it in a loop in main which seems to have done the trick. Trying to have two tickers going at such a rate is obviously too much as your little test program shows Hexley. I am only just beginning really and testing out how fast I can get things to go! Looks like my LCD scope running at 200Khz isn't really going to happen after all if I'm struggling just to get a logic probe and signal generator working.

Hi again. Just wondering how you are timing the code? It would be useful to see how often I am now checking the analogue input now that it is in a while loop just to give me an idea of the sample rate.

Lee

You can't use AnalogIn for such sampling intervals. Ive had sampling rates using one of the other ADC routines (not the mbed AnalogIn0 and using a while loop and the lowest I've done is about 7us per sample. It would be nice to have a faster interrupt/timer resolution too..

Hi, I have just published the program at:-

http://mbed.org/users/leejarcher/programs/analogicprobe/llrbma

It works but wondering what kind of sampling rate I'm getting. Aliasing is pretty obvious on square waves of over a few Khz because the open circuit(middle LED) lights but this undersampling will allow the logic probe to detect signals well above a few Mhz, just ignore the fact the open circuit LED lights for high frequency signals but for lower frequencies the unit should be pretty accurate.

Add a 1M1 resistor from P20 to v+ and a 820K from P20 to gnd. Then a 10K from P20 to the probe tip. An optional capacitor could be added from P20 to gnd to act as an anti-aliasing filter. P18 outputs the sine wave and P26 the pulse/square wave.

Using a terminal program you can set the sine and pulse frequencies etc. These will be stored and the unit can then be used stand alone. Otherwise default values are used.

Finally I will try and add a pulse detect for LED4 using InterruptIn if I can get over the problems of the first attempt!

You should be able to measure the time between samples by using a Timer. Start the timer outside your main loop, then do a timer.read_us() every time you sample the input. The difference in timer readings will give you the sampling interval in microseconds.

Tried what you said and get a 74us response, going to take the reading of the serial port out of the loop and if it speeds things up I can add it into a another slow Ticker.