realtime beginner question

Starting to play realtime with QNX6. Iwant to toggle a digital IO pin at a fixed frequency and can’t get it straight. The system is almost idle when I try this (embedded system, no Photon). The test app writes directly to the hardware and I use nanospin() between the shots (1ms delay). Should it work good? What I get isn’t straight :frowning:
Thanks

What level of jitter are you seeing? Try upping the priority of your program (you can use the ‘on’ utility to start it at a higher priority). Note that nanospin() actually spins so you will appear to lockup your system if you don’t have an exit case or higher-level shell running.

Hey starless,

You might wanna check out the tick-tock articles Mario has written:
http://www.qnx.com/developer/articles/

Greetz,

Martin.

If you don’t mind it running as root privilleged then it could hook the system timer interrupt dirrectly as this is pretty much running at 1 KHz. That way, you dodge the (questionable) compensating code of the timer system.

It’s quite easy, have a good read of InterruptAttach() and related docs.

Please expand. I think I disagree ;-) but want to make sure I really understand what you mean.

Yeah. I think I disagree as well ;-)

I changed my program a bit after reading the Tick-Tock article;) I now use nanospin()with multiples of clock_actual.nsec (from ClockPeriod()). And it works better!
From prio 25r and up, I get a clean signal. But I get a frequency ~10% slower than expected: ~ 450Hz instead of 500Hz… prio 63r didn’t help.
I then tried to speed up the clock period to 100000 ns. Nanospinning() 10 times the clock_actual.nsec should give the same results as above, but the frequency dropped again: ~400Hz and the signal “dances” a bit. Trying to get a 5kHz freq at this clock rate produced a 4167 Hz signal. Speeding it up to 10000ns and spinning 100 times the actual clock period produced an very unstable signal.
I don’t think the loop itself can create the time drift (or can it?):

for(i = 0 ; i <= nbr_shots ; i++)
{
outval = !outval;
wWriteGPIOPin(uGPIOBase, GPIO_IO0, outval, PIN_STATUS);
nanospin( &delay );

// Loop version to make sure wWriteGPIOPin() doesn’t cause the time drift…
// Produces the exact same results as the code above…
//out8(388, 0x5);
//nanospin( &delay );
//out8(388, 0x4);
//nanospin( &delay );
}

Is it possible to get a 500Hz (or 5kHz) frequency using this approach?
Thanks!

What is the processor? If it’s Pentium or above your probleme is somewhat unrelated to ClockPeriod() because nanospin doesn’t use OS timer but instead does a BUSY LOOP (wouach) on a counter inside the CPU that increment every clock (very precise). It reads the counter with ClockCycles().

If it’s below Pentium the counter doesn’t exists and emulated by the OS with a precision down to ClockPeriod().

My guess is you CPU is below Pentium?

How long is the train of pulses lasting?. How much jitter is acceptable in your case?

Excellent tick-tock articles, most of my qnx timer knowledge comes from them. :slight_smile:

Umm, I guess I got it wrong. I was thinking that the ClockPeriod() value should be 1 kHz, not the 6 digit value it defaults to. I guess the real problem is the help docs don’t give an example of retriving the value then setting a timer to a multiple of it.

What might be a nice new timer type is one that is is garanteed to be a multiple of the ClockPeriod(. Maybe a new clockid_t of CLOCK_HARDTIME would be in order. Speaking of which I never made sense of CLOCK_MONOTONIC.