[must]

Unless there's a requirement in the datasheet that the latch pin must be high while clocking data in, I don't see the difference.

Unless you're just commenting on the comments being a little misleading...

For reference, here's a (rather long) thread in these forums about NewSoftSerial where the interrupt bug was discovered and documented.  Also included is the assembly work-around that I came up with.

NewSoftSerial Library: An AFSoftSerial update

You solved the problem by upgrading the compiler to avr-gcc 4.3.2.

Version 4.3.0 (included with arduino-0012 and 0013) has a number of serious bugs - particularly in the OSX version.  One of which is producing bad code whenever a function is called from inside an ISR. Basically the bug is that the generated code fails to preserve all of the affected registers in the ISR before calling the function.  This leads to register corruption and all kinds of unpredictable behavior.

If you CAN use delay() here, you should be able to get better results with delayMicroseconds(1000)

I'm not sure if that would be a good idea in my case.  The reason being that the delayMicroseconds() function disables interrupts for the entire duration of the delay.  This differs from delay() in that interrupts are only disabled during the short calls to millis() inside the loop.

Another part of my application involves "listening" for RFID tags at 9600 baud with the hardware UART.  Having interrupts disabled for a full millisecond might cause me to drop a bit or miss a start bit and loose an entire byte.  Or maybe I'm misunderstanding something and the hardware UART wouldn't be affected by disabled interrupts?

I guess I could simply make a non-interrupt-blocking clone of delayMicroseconds() for my use since I'm not concerned if my timing is off by a microsecond or two.

Thanks for the reply.

It looks like the main difference is your first point.  Comparing the delay() source between 0012 and 0013 shows the slight difference of "<" vs. "<=".

0012

Code:

void delay(unsigned long ms)
{
      unsigned long start = millis();
      
      while (millis() - start < ms)
            ;
}

0013

Code:

void delay(unsigned long ms)
{
      unsigned long start = millis();
      
      while (millis() - start <= ms)
            ;
}

This explains the (significant) difference I was seeing.  I guess I'll have to shift to an elapsed-time rather than a countdown method.  At least then it won't be affected by any other future timing changes.

Thanks.

I've been working on a RFID entry system and I've noticed something odd with Arduino-0013.  It seems that the same code runs slower when built with 0013 vs. 0012 (or 0011).  My application has an asynchronous processing loop to handle user feedback in the form of a status LED and a piezo buzzer while not blocking the main program execution.  The thing that originally alerted me to the speed difference was that my status beeps (3 short beeps) played noticeably slower.  So I made a simple test case that demonstrates the difference.

The following sketch simply blinks an LED on pin 13 by calling a "service" routine that manages the state of the LED.  The main loop does nothing but call the service routine and then a delay(1).  In my real program there are other service routines that are called as well.

Code:

byte ledPin =  13;    // led control pin
int ledDelay = 75;   // The duration of the on/off time
int  ledDelayCounter=0;
boolean ledState = false;


void setup()
{
  pinMode(ledPin,OUTPUT);
  SetLedState(ledState);
  ledDelayCounter=ledDelay;
}


void SetLedState(boolean currentState)
{
  digitalWrite(ledPin,ledState);
}


void ServiceLed()
{
  boolean done=false;
  
  ledDelayCounter-=1;
  if (ledDelayCounter <= 0) {
    ledState = ! ledState;
    SetLedState(ledState);
    ledDelayCounter = ledDelay;
  }
}


void loop()
{
  ServiceLed();
  delay(1);
}

The LED will blink significantly slower if the code is built under 0013 (it's really noticeable when you replace the LED with a beeper).  We're not talking a small difference here.  0013 seems to be blinking about 33% slower (or more).

So is the delay() function taking longer in 0013?  Or is there something else going on?  Changing the loop to have delay(3) in 0012 seems to match delay(1) in 0013.

I realize I can shift to a millis() based interval rather than using a count-down method, and I might do that at some point.  But the real question is what changed between 0012 and 0013 that caused the speed difference?

For reference this was all built and tested using the OSX version of the IDE with a both an Arduino NG and Diecimila - both with ATmega 168's at 16MHz.

The only "true" fix is to upgrade to a fixed version of avr-gcc (which mellis is looking into), or downgrading to an earlier version of the compiler (probably not desirable or possible without large amounts of work).  You're welcome to try and include avr-gcc 4.3.2 in you Arduino-0013 (or 0012) environment yourself to address the problem.

The compiler bug is that the generated code is failing to preserve all of the affected registers before calling a function from an ISR.  Why this is different from the Windows version, I don't know (that's why it's a bug).

My guess about the bug is that it has something to do with how the compiler optimizes the ISR code.  The generated code (on both platforms) ends up making the called ISR function an inline declaration replicated for each interrupt vector that is attached.  Before the code is placed inline, the registers are preserved on the stack. After the inline, the registers are restored from the stack.

The difference happens when the ISR code calls another function.  In that case it appears the OSX version is not expanding the potential calling tree to find all of the potentially affected registers.  So in essence it only preserves the registers used by the base ISR function instead of any others affected by the nested functions.

The short of it is that if your ISR doesn't call any functions (or utilize and Wiring calls), then the bug won't affect you.  Otherwise the only fix is an upgraded compiler (or very targeted work-arounds like I made for the NewSoftSerial code).

Well since it's a free, open-source project where all contributors provide their time without compensation, feel free to participate and take responsibility for converting the source files to cr/lf format for the Windows distribution since you're so concerned about it.

I'm talking about the actual input format of each line of the library source code. The Microsoft Windows versions of the source files should be terminated with Microsoft style linefeeds and carriage returns. The Unix/Linux version should be terminated with Unix line feeds. The Mac OS version should be terminated with whatever characters that text format requires -- probably line feeds.

That would sort of defeat the notion of a common set of source files.  Linux and OSX don't have any problems with the source files.  So why should there be a unique version of the source just to fix a Windows Notepad issue?

[after]

version: arduino-0012 (I think the bug is in 0011 as well)

There appears to be a bug with the preprocessing and the function prototyping.  Some functions that are defined with pass by reference parameters are skipped and do not get prototype definitions in the resulting .cpp file.

For example, take this simple sketch:

Code:

byte a;

void setup()
{
}

void loop()
{
  Function1(a);
  Function2(a);
}

Then add a second tab (or add this code after the loop() function:

Code:

void Function1(byte var) {
// This function gets a prototype
}

void Function2(byte &var) {
// This function doesn't get a prototype
  var=1;
}

Trying to compile this sketch will result in:

In function 'void loop()':
error: 'Function2' was not declared in this scope

This is because no prototype is generated for Function2, only for Function1.  Here is the resulting .cpp file:

Code:

#include "WProgram.h"
void setup();
void loop();
void Function1(byte var);
byte a;

void setup()
{
}

void loop()
{
  Function1(a);
  Function2(a);
}
void Function1(byte var) {
// This function gets a prototype
}

void Function2(byte &var) {
// This function doesn't get a prototype
  var=1;
}

int main(void)
{
      init();

      setup();
    
      for (;;)
            loop();
        
      return 0;
}

The work-around is to manually add the missing prototype declarations before the functions are referenced.  Overall it makes keeping your code organized in multiple tabs difficult since you don't (seem) to have any control of the order of the final assembled program.  If the prototyping was working correctly then the order wouldn't matter.

[following]

Arduino-0012
Mac OSX 10.4.11 PPC

When working on a project with multiple tabs in the IDE, the incorrect tab is displayed when compilation errors are reported.  Unless the error is in the first or last tab, the tab that is displayed is the one following the one with the error.  Note that this is only in the OSX version.  The Windows version (on XP SP3) doesn't seem to exhibit this bug.

Technically there's no reason you can't call setup() - but there's probably not any good reason to. If your setup does things that should only be done once at program start (like Serial.begin()), then it would be a really bad idea.

Putting a "return" in the loop() function won't do anything. The actual code that's generated by the IDE calls the loop() function in an infinite loop.

Here's the final coded generated for the "Blink" example program:

Code:

/*
 * Blink
 *
 * The basic Arduino example.  Turns on an LED on for one second,
 * then off for one second, and so on...  We use pin 13 because,
 * depending on your Arduino board, it has either a built-in LED
 * or a built-in resistor so that you need only an LED.
 *
 * http://www.arduino.cc/en/Tutorial/Blink
 */

#include "WProgram.h"
void setup();
void loop();
int ledPin = 13;                // LED connected to digital pin 13

void setup()                    // run once, when the sketch starts
{
  pinMode(ledPin, OUTPUT);      // sets the digital pin as output
}

void loop()                     // run over and over again
{
  digitalWrite(ledPin, HIGH);   // sets the LED on
  delay(1000);                  // waits for a second
  digitalWrite(ledPin, LOW);    // sets the LED off
  delay(1000);                  // waits for a second
}

int main(void)
{
      init();

      setup();
    
      for (;;)
            loop();
        
      return 0;
}

The "real" program that runs is the main() function. Note that it calls some Arduino core initialization that's not visible to the program (init()), calls your set() function, and then loops forever calling loop().

So there's no way to make the program "end". Besides, what would be the point of having a program end on a micorcontroller? If that happened the chip would just go "dead" until it got reset.

If you really want this behavior you can simply comment out the for loop in the main program template so it only calls loop() once (or change it to do something more radical like not call loop() at all):

hardware/cores/arduino/main.cxx

Code:

{
  potval = analogRead(potpin);            // reads the value of the potentiometer (value between 0 and 1023)
  potval = map(potval, 0, 1023, 0, 179);     // scale it to use it with the servo (value between 0 and 180)
  myservo.write(potval);                  // sets the servo position according to the scaled value
  delay(15);                           // waits for the servo to get there
}

What's with the open and close braces around this section? Did you intend to have some conditional before it?

The problem is that you need to charge your RC network completely before the transistor gets turned on and pulls the reset low. Remember that the pin your using to supply current to the RC network will stop sourcing current the instant the reset line is pulled low.

Basically you need a precharged circuit with a one-shot trigger. A simple 555 timer in a monostable circuit will do the job (+ a couple of transistors for signal inversion).

Here's an example you could use in place of the RC network (you'll still need the transistor to pull the reset line low).

http://www.doctronics.co.uk/555.htm#monostable

Note that the 555 timer wants a low pulse to start the timer. So you could add an inverting transistor, or simply do a digitalWrite(resetPin,LOW) to trigger it (but be careful how you initialize the pin to prevent accidental resets).

Or use the typical trick with the transistor, usually associated with the XBee wireless upload (an output pin drives a transistor that grounds the reset pin).

Another bad idea and explicitly recommended against by the Atmel engineers.

You can't use a digital pin on an ATmega chip to pull the reset pin low. This is because as soon as the reset is initiated, the digital pins get switched to a hi-Z mode and the reset pin will no longer be kept low. According to the datasheet, there is a minimum time that the rest pin must be held low for a proper reset to ensure that the chip is properly initialized. Since the digital pin will switch to the hi-Z state, there's no way to guarantee the proper reset duration.

This will work okay if an external source (such as the XBee) is the one pulling the reset line low.

So another option would be to build some kind of time controlled external one-shot that can be triggered and will pull the reset line low for a fixed amount of time. Something like a 555 timer or a transistor/RC circuit.