Tennsy 4.1 loop delay issue

Projects Programming
1

Just received a Teensy 4.1 board.
While programming I discovered that a "for loop" does not work as expected.
If I replace the for loop with a delay statement, it does what is expected.
The attached code has the counter enabled and is the one that is a problem.
If I comment out the counter and use the delay statement it works.
Also attached is the screen shot of both.

'int count = 0;'

'void setup()'
'{'
'pinMode (2, OUTPUT);'
}

'void counter()'
'{'
'for (count = 0; count <200; count++);'
'}'

'void loop()'
'{'
'digitalWrite (2, HIGH);'
'counter();'
'//delay (1);'
'digitalWrite (2, LOW);'
'counter();'
'//delay (1);'
'}'

the first screen shot shows the unexpected behavior. The second is as expected.

image
image1514×241 16.1 KB

image
image1525×282 18.1 KB

2

What are you expecting this to do? Counting from 0 to 200 is going to take way less time than 1ms.

3

If it were me I'd put both in the same code. High and Low with counter followed by High and Low with delay. That way you can get an insight into both at the same time.
The "for" loop will definitely not take 1ms

4

Todd,
Thanks for the reply. It does not matter what the number is in the for
loop, 200, 2000 or 20000. It always be haves the same.
I even tried just incrementing a variable to some high number expecting
a delay but still acts the same.
What I am attempting to do is set a known delay that the delay statement
will not do.
I started out with a program I had written for the MRK WIFI 1010. I
adjusted timing for the differences in processor speed, but noticed that
the for loop I had for the MRK does not work for the Teensy, no matter
what I make it.

5

I tried that suggestion. The delay statement does what it is susposed to
do but the for loop always gives the strange behavior.

6

No of course not,

for (count = 0; count <200; count++);

nothing is done during the for loop other than incrementing the variable, which thereafter is never used, so the whole thing gets optimized away, in other words never gets compiled nor executed. If you would at least print the end result of 'count' there would be some chance of it having any meaning, though it will still pass within microseconds, but as it stands, it doesn't have any meaning. and the pre-compiler will just dismiss the whole function (or at least it should)
how about

for (count = 0; count <200; count++) delayMicroseconds(10);

??

7

Thank you for the reply,
I did not think about that. I assumed the for loop counted no matter what.
I will use your suggestion.
Thanks again

8

Deva,
Thanks for the information.
Tried your suggestion...it works....thanks

9

Still It is weird that after every 9 pulse it Stops for 1us

10

If you really need an accurate square wave you should probably use a timer interrupt for half the desired period and just toggle the output. Or you may be able to just use the tone() function.

11

The tone() function is rather inaccurate since it converts frequency back to wavelength in an integer division. Personally i think the tone() function will make any note sound out of tune.

That is the way. Of course the tone() function does use timer1 as well, but yeah..

12

If all that's required is a square wave, it could probably be done with one of the hardware's PWM modes. Don't even need an interrupt for that.

1 Like
13

I agree but I wasn't sure if it would support the frequency(s) OP needs.

14

isn't that just using the same resource ? a hardware timer. To me in some ways it's the same.

it can only be multiples or parts of multiples of the clockspeed. If the default PWM frequency doesn't suffice you can set the registers.

15

Nope. Assuming the dividers and counters can be configured to give the frequency you need (I have not yet dug into the Teensy 4.1 processor's datasheet - it's an NXP IMXRT1062DVJ6), then using a PWM mode is superior. You don't suffer the random latency of handling the interrupt and entering the ISR (which shows as jitter on the signal's edges) or the extra latency of the ISR code itself.

16

Not familiar with your test equipment, but it looks like the "I/O Standard" is incorrect ... the threshold is set to 5.0V TTL -> 1.58V (but its a 3.3V MCU)

image

From the datasheet:

image
image883×273 14.5 KB

17

Hmm i just saw now that in your oscilloscope you call the signal DMX512, if that is what you are trying to do (Send a DMX frame ?) then you (and we) are on the wrong track. and you should use the UART instead. There are good working libraries available for doing that already, no need to re-invent the wheel.

18

Thanks for the reply,
I already have the DMX512 send resolved. What I am attempting to do is
build a DMX512 Capture design. I want to capture an entire DMX stream
and inspect it offline. I have a real world failure I am trying track
down the cause.

19

Again, using the UART for reception is the most reliable, though finding the 'break' can be a bit tricky. Mind you i find an AVR is an easier MCU for reception, since the size of the FIFO on other boards can be an obstruction.

20

This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.