Blink Does Not Work ( Correctly ) -- Advanced User

Solved I think :o it was the analyzer in the library with the candle stick see #24. Read the whole thread for pure entertainment.

Begin original post ===>

Blink is the Hello World of the Arduino. So would it be a surprise if it did not work? It sure surprises me. It does seem broken. Now in my case I am running it faster than the standard demo, but not real fast. I have tried a lot of code with a lot of variations, but for the basics:

while ( true ) { digitalWrite( ledPin, HIGH ); // turn the LED on (HIGH is the voltage level) delayMicroseconds( 5000 ); // wait digitalWrite( ledPin, LOW ); // turn the LED off by making the voltage LOW delayMicroseconds( 5000 ); // wait }

I get a blink all right but the timings are not right, typically a glitch every 81.92 ms. I am blinking about every ms or so and timings are off by say 10%.

If you think blink works please look at: http://www.opencircuits.com/Blinking_Blues and tell me where I went wrong. Insightful suggestions may be tried out by me. It would be nice to rebuild confidence in this iconic program.

Edit... Glitch may be misleading readers in this case a glich is just one in a long series of square waves where the period is about 10% different from what would be expected from the code and from about 90% of the other square waves in this aproximate 82 ms period. You have to follow the link to get enough info to even begin to have a hope of fully understanding the problem.

(deleted)

Right, but this does not explain why many pulses are “good” and then eveny 81 ms or so one is “bad”. Code should run loop in same time every time if delaymicro… is ok.

And not sure where you get 5us this is 500 to 5000 us.

A while loop demands near full attention of MCU, delay strangles the MCU, timer0 interrupt needs to run (smoothly?) in the background. 2 layers of blocking going on.

Use millis() or micros() for your timing interval instead of delay and this problem should disappear.

Cannot really use milli for this as time is too short. In any case if you check the web page you will see that I have tried it with micros ( for the short time ) and with interrupts on/off. My write up may not have made this clear, I will add a bit more explanation.

Took a look at your signals … I think it could be the trigger level. Is this adjustable? I use the Logic Pro 8 and it has 3 trigger voltage settings (wish it was variable), but it does affect how many (if any) glitches that may appear or if it can capture the signal. The problem with the purple trace seems to be a drop-out near the end of the last pulse.

May need to see the signal quality with an oscilloscope.

russ_hensel:
Blink Does Not Work ( Correctly ) – Advanced User

Dubious statements are dubious.

russ_hensel:
Blink is the Hello World of the Arduino. So would it be a surprise if it did not work?

If you try to do it in a very strange way, then no, it would not be a surprise if it doesn’t work as expected.

russ_hensel:
It does seem broken.

The actual blink examples are not broken. Nor is yours.

russ_hensel:
Now in my case

The only factual statement of your post.

russ_hensel:
I am running it faster than the standard demo, but not real fast.

"Fast’ is relative. Define what you mean by fast.

russ_hensel:
while ( true ) {
digitalWrite( ledPin, HIGH ); // turn the LED on (HIGH is the voltage level)
delayMicroseconds( 5000 ); // wait
digitalWrite( ledPin, LOW ); // turn the LED off by making the voltage LOW
delayMicroseconds( 5000 ); // wait
}

Where is the rest of your code. Snippets rarely contain the actual problem.

russ_hensel:
I get a blink all right but the timings are not right, typically a glitch every 81.92 ms.

What do you mean by glitch? What measurements are you making to come up with a precise number like 81.92ms?

russ_hensel:
I am blinking about every ms or so and timings are off by say 10%

If this code is bilnking every ms, there is a bigger issue. That is not how this code should be working.

That said. I took your vague code snippet, removing the incorrect comments, and created this one:

const int ledPin=13;

void setup() {
  pinMode(ledPin, OUTPUT);
}

void loop() {
   while ( true ) {
       digitalWrite( ledPin, HIGH );   // turn the LED on 
       delayMicroseconds( 5000 );      // wait 
       digitalWrite( ledPin, LOW );    // turn the LED off
       delayMicroseconds( 5000 );      // wait 
    }
}

When I look on my oscilloscope, I see a very sharp, nearly perfect, square wave with no glitches. Either your measurement technique is flawed or you left out the offending code.

Newfile1: Multiple cycle capture with frequency, duty cycle, and pulse width turned on.

Newfile2: About 1 minute of infinite persistence

P.S. This is the wrong forum for this type of issue. I would expect an “Advanced User” to have read the forum descriptions.

I think that you are looking at the wrong channel, the signal being measured is on channel 3 ( channels start at 0, channel 2 is just noise and induced signal. The cursors in the image you copied are at the good pulses, cursor 1 through 4. In the signals of this case the glitch is not a little pulse, but a pulse that is stretched by about 1 ms, the exact timings are in the spreadsheet.

It is not the analyzer trigger, the problems happen 10’s of ms away from the trigger point and occur even if I capture without a trigger.

I have looked at it with a scope, but the 10% stretch in one pulse is more than even my digital scope can catch, the analyzer is much better for that.

In this case the stretch is about 1ms the analyzer is good to about 20 us .02 ms.

I’m not familiar with your analyzer, but I’m referring to the trigger voltage (reference signal), not time base or sample frequency. Your logic analyzer will internally have a comparator and it will be creating an output signal based on if the input signal is > or < a reference signal.

If this reference voltage is near any noise level or logic level at the input, then a false output would occur. Make sure your input isn’t loaded by other probes or devices and that there’s good grounding.

[quote author=James C4S date=1483500979 link=msg=3068453] Dubious statements are dubious. If you try to do it in a very strange way, then no, it would not be a surprise if it doesn't work as expected. The actual blink examples are not broken. Nor is yours. The only factual statement of your post. .... blan blah blah [/quote]

In reply I am not going to go quote by qote, especially against one so well informed. Dubious statements are dubious is called a tautology, much like arrogance is arrogance. Having gotten thru this lets try to address any substantive points.

The code Bald E found strange including the comments is the 101 example for the arduino, found under examples, but run with micro sec instead of milli sec. The wrong comments are in fact those left over from that example which I copied, rather than rewrite. I did make some additions. I think Bald E, may have missed the text at the link I posted which said "Some remnants of the old comments are still in there."

Careful reading is always good when programming.

"Fast' is relative, true, and as you can see from my post here ( no need to go to the link ) the half period is 5000us. So there you have a number on it.

Where is the rest of the code, well there are about 500 lines in the main code, so if you follow the wiki link you will find an additional link to all of it. Just press a few buttons.

Q. What do you mean by glitch? What measurements are you making to come up with a precise number like 81.92ms? A. -- well again see the link, I used a logic analyzer. You can see them yourself if you want to all the data is there -- but with the analyzer data you also need to download its code ( link also there )

Statement: That said. I took your vague code snippet, removing the incorrect comments, and created this one: Response: If you think the "incorrect comments" caused a problem, I can assure you they did not. Nor did your while ( true ) which my subroutine did require but not loop() which basically is while( true )

Looked at your scope pics. We may have the same scope! In any case I have scoped this sort of output for years and the pics do look nice, on my scope too! But this is a bit too subtle for the scope to catch. That is why I used a logic analyzer. I will post a few more pictures there that may help. I tested both the scope and the analyzer with an oscillator to try to be sure that problem was not an artifact.

Perhaps you can suggest which forum to post in, note that I claim the problem is with the arduino environment, I am not asking what is wrong with the posted code ( although I am open to any thoughtful answer ).

Do you find that your sort of answer encourages others interested in the arduino, beginner or advanced ( I have been programming for most of the time you have been alive, if you picture is not a fake ) or makes you better liked or looked up to on the forums?

Edit.... Since my response I have checked out BE's Blog and he does not seem like such a bad guy, even a good guy. Did I catch him at a bad time. Not sure, cannot explain.

Further Edit... EB suggested I was in wrong forum this is clearly for beginners but "For problems with the Arduino itself" so I used it. About a page down is a forum for "...bugs you found" and unless someone can do a good job of explaining what I did wrong, I will probably post there as well.

dlloyd:
I’m not familiar with your analyzer, but I’m referring to the trigger voltage (reference signal), not time base or sample frequency. Your logic analyzer will internally have a comparator and it will be creating an output signal based on if the input signal is > or < a reference signal.

If this reference voltage is near any noise level or logic level at the input, then a false output would occur. Make sure your input isn’t loaded by other probes or devices and that there’s good grounding.

Thanks, good advice, but I have looked at all of this and measurement are consistent even with triggering off. You will note that the code runs “forever” so it does not really matter where you start –
Except for the phase, and except that when using micros there is supposed to be a roll over about ever 70 minutes.

russ_hensel: Statement: That said. I took your vague code snippet, removing the incorrect comments, and created this one: Response: If you think the "incorrect comments" caused a problem, I can assure you they did not.

I apologize for that one. It has been so long since I looked at the original blink, I didn't realize how silly the comments were. (or they changed recently, which I doubt.)

russ_hensel: Nor did your while ( true ) which my subroutine did require but not loop() which is while( true )

I compiled the snippet you provided as best as I could. I made measurements and verified it is working correctly.

Either something else in your code is causing a problem, or you are measuring it incorrectly.

I will not hunt around your website or wiki page looking for the extra details. Provide code that demonstrates the issue.

russ_hensel: But this is a bit too subtle for the scope to catch. That is why I used a logic analyzer.

Another confusion point. This method is the opposite of how measurement debug works. You might observe a strange effect on a logic analyzer, but you would rely on the oscilloscope to see the analog characteristics. Ideally, you would use an oscilloscope with high analog bandwidth and a much faster sampling rate than the logic analyzer.

This situation is a near classic example of the logic analyzer missampling data. Which is what I verified with my oscilloscope. Since the last post, I have left my board running with a Duration trigger set for less than 5ms. The idea being that the hardware trigger circuit (which doesn't have the same hold-off as either the scope's A/D or LA's samplers) would detect a glitch.

It hasn't triggered yet.

Tested on Uno, loaded pin 13 with 100nF cap and 330 ohm in parallel and connected to GND in an attempt to re-create glitches near trigger level (set to 1.2V).

The signals (deglitch filter disabled) ... |500x248

Same signal zoomed ... Note: The pattern of glitches and quantity varied and was sporadic. Could also get good logic signal for multiple cycles. |500x245

Deglitch filter enabled: 1 sample ... Note: Clean signal forever. No changes made to hardware. |500x277

Another good example of the “bike shed effect” ?

…R

Robin2:
Another good example of the “bike shed effect” ?

Could be, though some of the answers are thoughtful, and some people have actually tried to look at the situation. I am learning again how hard it is to communicate, especially when people think they already know what I am saying instead of reading it.

dlloyd: Tested on Uno, loaded pin 13 with 100nF cap and 330 ohm in parallel and connected to GND in an attempt to re-create glitches near trigger level (set to 1.2V).

The signals (deglitch filter disabled) ... |500x248

Same signal zoomed ... Note: The pattern of glitches and quantity varied and was sporadic. Could also get good logic signal for multiple cycles. |500x245

Deglitch filter enabled: 1 sample ... Note: Clean signal forever. No changes made to hardware. |500x277

Interesting. I think that my word glitch is still throwing people off, and was ill chosen by me. The effect is not normally at the trigger point, but at random in about any 90 ms segment of the signal and is the stretching of one cycle by about 1ms ( typically on one side of the pulse ). I sometimes have to run the cursors along the signal to find it but have always found it in the test I have conducted.

You seem to have some nice gear there. I think I will take a better look at the pulse beginning though that is not where I have found the problem.

In reply to James C4S and others I have compiled his code to run on pin6 my analyzer channel 3. The code in its entirety is:

const int ledPin=6;

void setup() {
pinMode(ledPin, OUTPUT);
}

void loop() {
while ( true ) {
digitalWrite( ledPin, HIGH ); // turn the LED on
delayMicroseconds( 5000 ); // wait
digitalWrite( ledPin, LOW ); // turn the LED off
delayMicroseconds( 5000 ); // wait
}
}

In the attached gif focus on channel 3, that is pin6 The cursor measurement for 1,2,3,4 are all about 10.1 ms, a value which seems “right”. But at cursor 5,6 you can see a pulse of period 11.060 ms. This is the “glitch” ( bad term here ) that I am talking about. It repeats about every 80 ms. This sort of behavior with some different details has been present in every test I have conducted.

I did look at the rise and fall time on my scope, it is about 20 ns. I cannot catch this stretched pulse on my scope, but looking for a 1 ms discrepancy across 80 ns is not really easy on a scope. I did use the single sweep option and mess with a bunch of the variables. Right now I trust the logic analyzer for this more than the scope, you can try to present an argument for why I should not. I have to confess I have not tried my old 100 mhz analog scope on this guy.

My gif does not show up inline, sorry do not know how to do that on this forum yet.

I wonder if the fact that there are 1000 microseconds in a millisecond, but 1024 clock ticks, explains the results you are seeing? micros() and millis() do not return every possible value from 0 up. There are steps, where the adjustment is made to accommodate the discrepancy between humans with 10 fingers and computers with 2 states.

I think that only affects millis, as micros can update by 4 every 64 system clocks.

The digitalWrites all add some delay as the code behind it checks the state of the IO pin setup before it changes it I believe. Try this, using direct port manipulation vs the digitalWrite code:

const byte ledPin=6; // only need byte here

void setup() {
  pinMode(ledPin, OUTPUT);
}

void loop() {
   while ( true ) {
       PORTD = PORTD | 0b01000000   // turn the LED on 
       delayMicroseconds( 5000 );      // wait 
       PORTD = PORTD & 0b10111111    // turn the LED off
       delayMicroseconds( 5000 );      // wait 
    }
}

and then as a next step can use blink without delay method vs delay().

and then as a next step can use blink without delay method vs delay().

Since the Arduino is doing nothing useful anyway, I really don't see that as a logical next step.