Editing Blinking Blues

Jump to navigation Jump to search

Warning: You are not logged in. Your IP address will be publicly visible if you make any edits. If you log in or create an account, your edits will be attributed to your username, along with other benefits.

The edit can be undone. Please check the comparison below to verify that this is what you want to do, and then save the changes below to finish undoing the edit.

Latest revision Your text
Line 1: Line 1:
'''Blink Does Not Work?'''  Having some trouble with arduino blink.  Write up here.  Draft still working on this but if you can figure it out contact me [[User:Russ_hensel]].
+
Having some trouble with arduino blink.  Will write up here.  Draft now, not enough to really be of use to anyone but me.
  
 
= Origin =
 
= Origin =
  
I have been messing about with steppers and simple drivers for some time.  Recently I put a logic analyzer into use and noticed that the switching wave forms were a bit off.  Simplifying this I went back to the basic blink and took a look at it.  It also had some anomalies.  This began an investigation of various blink code and the results.  So far I have not found code that gives good results.  In this investigation I am focusing on using pulses with half periods of 500 and 5000 micro ( not milli ) seconds.
+
I have been messing about with steppers and simple drivers for some time.  Recently I put a logic analizer into use and noticed that the switching wave forms were a bit off.  Simplifying this I went back to the basic blink and took a look at it.  It also had some anomolies.  This began an investigation of various blink code and the results.  So far I have not found code that gives good results.  In this investigation I am focusing on using pulses with half periods of 500 and 5000 micro ( not milli ) seconds.
 
 
 
 
== The Analyzer Did It ==
 
 
 
 
 
Right now it looks like the problem is the dangerous prototype logic sniffer.  I will be editing all of this later and contact the dangerous prototype folks.
 
 
 
= A Quick Version ( no so many details ) =
 
 
 
[[Blinking Blues Quick Version]]
 
  
 
= Blink =
 
= Blink =
Line 21: Line 11:
 
The blinks I worked with for this investigation were all in the 1 to 10 ms or so period time frame.  I used only the microsecond built in functions.  I expected that the timings would:
 
The blinks I worked with for this investigation were all in the 1 to 10 ms or so period time frame.  I used only the microsecond built in functions.  I expected that the timings would:
  
* be repeatable in the range of a few microseconds.  There are some delays in parts of the code but they should be repeatable.
+
* be repeatable in the range of a few microseconds.
* be accurate in the range of 10 to 20 microseconds.  I would only expect ( I could be wrong ) that the accuracy of the call to microsecond functions should have this sort of accuracy.
+
* be accurate in the range of 10 to 20 microseconds.
 
 
=== Before You Answer ===
 
 
 
I have been doing this for a long time.  I may have made a simple mistake but I, at least, do not think it likely.  There is a lot of data here and in the links.  Do not assume it is missing if you have not looked for it.  Do notice I have shifted everything to the microsecond ( 500 and 5000 ) time scale.  I am not claiming that this does not work well with milliseconds, I have not tested that.
 
 
 
I know the waveforms look good on a scope.  It takes more careful analysis than a scope, or at leas most scopes give.  I found the first problems by eye, but even now that I know what I am looking for I often have to use the cursors on the logic analyzer to find the problems.
 
  
 
== What I Found ==
 
== What I Found ==
  
 
* I found glitches in the waveform of up to 1 or more milliseconds ( 1000 microseconds )
 
* I found glitches in the waveform of up to 1 or more milliseconds ( 1000 microseconds )
* Often the glitches would repeat every 81.92 milliseconds or so.  Interestingly enough if I divide this time by 16 e6 I get 512 which is more or less a magic number.
+
* Often the glitches would repeat every 81.92 milliseconds or so.  Interestingly enough if I divide this time by 16 e 16 I get 512 which is more or less a magic number.
  
 
== What I Tried ==
 
== What I Tried ==
Line 45: Line 29:
 
=== Issues Investigated ===
 
=== Issues Investigated ===
  
* Was the logic sniffer the glitched one:  Do not think so, I generated a square wave on an oscillator at 1KHz ( period 1 ms ) and looked for glitches in it.  Nothing found.
+
* Was the logic sniffer the glitched one:  Do not think so, I generated a square wave on an ossicalator at 1KHz ( period 1 ms ) and looked for glitches in it.  Nothing found.
* Used different versions of the code, take a look at my code posted here.
 
* Used 2 different types of arduino
 
* Used different arduino exe, 1.6.1 and 1.8.0
 
* Used both 5000 us and 500 us as test delay.
 
  
 
== Things Yet to Try ==
 
== Things Yet to Try ==
Line 60: Line 40:
 
= Some Results =
 
= Some Results =
  
In the image below the data from the arduino is being measured on channel 3, the test signal from the oscillator is on channel 5 and the rest are grounded or some sort of junk I have not gotten rid of. Click on it to go to a page with the image and then again to go full size which I did not do here to reduce the clutter.  This measurement shows the good pulses.  I typically use the sniffer cursors 1 to 4 for four consecutive good pulses.  A good pulse is one very near the desired one, for example aiming at 10.00 ms I may get 10.120 ms.  I actually expect some extra time ( perhaps not this much ) as there is some overhead in the routine.  A bad pulse is typically off by much more ( 11.360 ms ).  Bad pulses are identified by eye then tested using cursors 5 through 10.  In both cases the good and the bad are consistent across many periods.  The most consistent result is that bad pulses are separated by about 81.92 ms.  And 81.92 / 16 meg Hz = 256 * some power of 10.  That it comes out at the magic number of 512 seems very significant, but I am not sure why yet.
 
 
[[File:measure1.gif|600x300px]]
 
 
Bad pulse from the same test run ( or one with similar timings ):
 
 
[[File:Measure2.gif|600x300px]]
 
 
Table of results, just a sample from one setup, much more data in the files.
 
 
{| class="wikitable"
 
|-valign="top"
 
|Routine
 
|Half Period
 
|Good Periods
 
|Bad Periods
 
|Delta Bad
 
<!--------------------------------
 
|-valign="[[Use C for PIC Programming!]]top"
 
|Routine
 
|An experiment as a possible wiki for BoostC, If it gets big it should find its own home somewhere else.
 
|[[Special:Export/BoostC tiny Wiki]]
 
<!-------------------------------->
 
|-valign="top"
 
|blink_classic
 
|5.000 ms
 
|10.120 ms
 
|11.360 ms
 
|81.940 ms
 
<!-------------------------------->
 
|-valign="top"
 
|
 
|
 
|10.300 ms
 
|11.300 ms
 
|
 
<!-------------------------------->
 
|-valign="top"
 
|
 
|
 
|10.100 ms
 
|
 
|
 
<!--------------------------------
 
|-valign="top"
 
|[[BoostC from the Fourm]]
 
|
 
|[[Special:Export/BoostC from the Fourm]]
 
 
<!--------------------------------
 
|-valign="[[Use C for PIC Programming!]]top"
 
|Routine
 
|An experiment as a possible wiki for BoostC, If it gets big it should find its own home somewhere else.
 
|[[Special:Export/BoostC tiny Wiki]]
 
<!-------------------------------->
 
 
<!-----------end of table--------------------->
 
  
|}
+
[[File:measure1.gif]]
  
  
 
== More Results in Files ==
 
== More Results in Files ==
  
You can check out my results using these files or starting from scratch.  I am still working on these timings so files may change, but I am putting up some versions now ( Jan 3 2017 )
+
* Arduino Code -- I keep adding to it, but the old subroutines that have been timed are not changed.
 
+
* Results spreadsheet
* Arduino Code -- I keep adding to it, but the old subroutines that have been timed are not changed. It consists of 4 files that need to be unzipped into a directory called Blinkers and then opened with the arduino software.  It is hosted on a google drive at: [https://drive.google.com/file/d/0B4yCTDKKk1cYUnV1MkRuZ0p6VzQ/view?usp=sharing Blinkers]
+
* Sniffer project files.
* Results spreadsheet: contains some of the measurements I have taken from the logic sniffer. It is in open office format. [https://drive.google.com/file/d/0B4yCTDKKk1cYUnV1MkRuZ0p6VzQ/view?usp=sharing]
 
* Sniffer project files. They are all zip and hosted on a google drive at: [https://drive.google.com/file/d/0B4yCTDKKk1cYMU02ZGgzRU5uanc/view?usp=sharing].  These files can be opened with the logic sniffer software found at [https://www.lxtreme.nl/ols/#download  Logic sniffer software download]
 
  
 
= Test Setup =
 
= Test Setup =
Line 133: Line 54:
 
Logic sniffer is the dangerous prototypes single board device http://dangerousprototypes.com/docs/Logic_Sniffer_101
 
Logic sniffer is the dangerous prototypes single board device http://dangerousprototypes.com/docs/Logic_Sniffer_101
  
Measurement taken using the cursor measurement, finding some good pulses at the beginning and then visually scanning, then measuring for bad pulses later on.  All recorded to a spreadsheet, that is uploaded to the web, see section above.
+
Measurement taken using the cursor measurement, finding some good pulses at the beginning and then visually scanning, then measuring for bad pulses later on.  All recorded to a spreadsheet, that will be uploaded here.
  
 
= Code Samples =
 
 
 
For those who do not want to look at the full code here are some of the variations I tried.
 
While I made these subroutines I modified them only a little from the originals in the examples.  Some remnants of the old comments are still in there.
 
 
void blink_classic() {    // lightly modified from the classic blink example
 
    Serial.println( F( "blink_classic()" ) );
 
    set_interrupts( );    // this will turn the interrupts on or off depending on some global
 
                          // value I have tried it both ways
 
  // blink modified to use same variables as blink without delay
 
  // modified to be a subroutine and to use micros despite the names
 
  while ( true ) {
 
      digitalWrite( ledPin, HIGH );  // turn the LED on (HIGH is the voltage level)
 
      delayMicroseconds( 5000 );      // wait  -- this value was varied for different tests
 
      digitalWrite( ledPin, LOW );    // turn the LED off by making the voltage LOW
 
      delayMicroseconds( 5000 );      // wait  -- this value was varied for different tests
 
    }
 
}
 
 
And one other ( more in the full routine )
 
 
    void blink_without_delay(  ) {
 
      Serial.println( F( "blink_without_delay()" ) );
 
      set_interrupts(  );  // so it can be tried with and without interrupts
 
      while ( true ) {
 
              // here is where you'd put code that needs to be running all the time.
 
           
 
              // check to see if it's time to blink the LED; that is, if the
 
              // difference between the current time and last time you blinked
 
              // the LED is bigger than the interval at which you want to
 
              // blink the LED.
 
              unsigned long currentMillis = micros();  // but using micros here usually with interval of 500 to 5000
 
           
 
              if ( currentMillis - previousMillis >= interval ) {
 
                // save the last time you blinked the LED
 
                previousMillis = currentMillis;
 
           
 
                // if the LED is off turn it on and vice-versa:
 
                if (ledState == LOW) {
 
                  ledState = HIGH;
 
                } else {
 
                  ledState = LOW;
 
                }
 
                // set the LED with the ledState of the variable:
 
                digitalWrite( ledPin, ledState );
 
              }
 
            }
 
    }
 
  
 
= Who I Told =
 
= Who I Told =
  
== What ==
 
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:
 
<pre>
 
  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
 
    }
 
</pre>
 
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.
 
 
== Who ==
 
 
Some via email, but only web references here.
 
  
* Arduino Forum  http://forum.arduino.cc/index.php?topic=445889.0
 
* http://www.righto.com
 
* https://github.com/z3t0
 
  
 
== Not Yet, but On My List ==
 
== Not Yet, but On My List ==
  
 
= Links I Looked Over =
 
= Links I Looked Over =

Please note that all contributions to OpenCircuits may be edited, altered, or removed by other contributors. If you do not want your writing to be edited mercilessly, then do not submit it here.
You are also promising us that you wrote this yourself, or copied it from a public domain or similar free resource (see OpenCircuits:Copyrights for details). Do not submit copyrighted work without permission!

Cancel Editing help (opens in new window)