Hi all, here's our AT90USB core for the Arduino IDE, including a LUFA-based bootloader that's been slimmed down, and allows bootloader entrance by holding a pin low during power-on.

https://github.com/DynamicPerception/ArduinoAT90USB

Supports AT90USB646/7, AT90USB1286/7, and 1287 USBKEY (Atmel bootloader)

The only thing we haven't tested thus far is USB OTG, but we'll be done testing that soon.  USB works fine, the multiple serials work fine, PCInts, HW Ints, etc.

Feedback, or suggestions, are much appreciated.


EDIT: Apologies, although I searched first, I just realized that I had already posted this.  I can't delete this post, so if one of the mods would, that would be awesome.

Hi Mike,

Sorry for the delay!

The issue is not really debouncing, but the checkInput() method does a lot more than that - you'll note that it handles escalating values the longer an input is held, dealing with returning back to menus from screens, etc.  To handle a sixth input will be a bit more complex, because you probably want that input to behave like two of the other inputs. (e.g. emulate INCREASE or DECREASE based on direction of turn.)  The best way to do this will be to modify the OMMenuMgr library file and make _checkAnalog() a protected virtual, and then sub-class the OMMenuMgr library, providing your new _checkAnalog() function to properly return the button type.  This way, you can make your own _checkAnalog() method that returns one of BUTTON_NONE, BUTTON_FORWARD, BUTTON_BACK, BUTTON_INCREASE, BUTTON_DECREASE, BUTTON_SELECT based on how your inputs are read.

You may also want to make setAnalogButtonPins() virtual as well, so you can pass the correct information in without hard-coding it.  If you're still interested in doing this, I can make these virtual changes to the core library so that you won't have to worry about upgrades later.  BTW, the new home for this library is: https://github.com/DynamicPerception/OMLibraries

!c

Hi all,

We recently started working with the AT90USB646 series of uC's on a project, as they perfectly fit the bill for us.  To this end, we wanted to keep compatibility with the Arduino environment for our customers.  While there appeared to be a few other attempts to add support, they didn't really work for us, so we created a little patch.

One of the big problems for us was the Atmel bootloader, and the original LUFA bootloader, were fairly complex in initiating the bootloader.  We include a modified LUFA CDC bootloader that automatically goes into the bootloader at start-up, but will automatically start the program if PF0 is high.  This way, you can simply attach a button to PF0 and press it during power-on to start the bootloader for firmware update.  We also needed a bootloader indicator, so PC6 is flashed while in the bootloader (you can attach an LED, LCD backlight, etc.)  The new bootloader is also at around 4k, freeing more flash space.

Everything is available here: https://github.com/DynamicPerception/ArduinoAT90USB

If people like it, we can look at doing a merge and pull request with the core Arduino project.

!c

Hi Korstian,

The code I included in my latest response should be added to the putch() function.  With RS485 you must tell the transceiver when to go into transmit mode, and you do that whenever you are sending data back.  Since putch() is used to push each byte out down the serial channel, you add the control over the DE/RE line to that function, and make sure to account for the proper amount of time it takes the driver to push out the byte before disabling transmit mode. 

There's a complete working implementation of the bootloader in the source package you can download from here: http://dynamicperception.com/software/motion-engine you could simply modify the putch() function to use your correct DE/RE pin and then "make nanoMoCo"

I get this error tho;

 error: cannot convert 'StringSumHelper' to 'char*' for argument '1' to 'void wltl(char*)'

Code:

void wltl(char *logmessage) { // write line to log
          if(DEBUG){
            Serial.print(hour());
            Serial.print(":");
            Serial.print(minute());
            Serial.print(":");
            Serial.print(second());
            Serial.print(":");
            Serial.println(logmessage);
          }
}

And I call it with this;

Code:

  wltl("IP Address: " + String(ip[0]) + "." + String(ip[1]) + "." + String(ip[2]) + "." + String(ip[3]));

The WLTL routine is suppose to make live easier, to centrally controll weather or not to write log items to disc, or add time stamps.

How can you convert a complex object like String to a char pointer?

You can't.

"ABC"  is a const char[3].  Get the plus operators out of your argument, as I said earlier. 

Consider the following, as has already been indicated to you by majenko (get rid of String):

Code:

char logmsg[100];
sprintf(logmsg, "IP Address: %d.%d.%d.%d", ip[0], ip[1], ip[2], ip[3]);

wltl(logmsg);

Your life will be simpler, and your sketch will be smaller.

 

Have you considered just using the MsTimer2 library which already handles Timer4 on Leonardo?

http://playground.arduino.cc/Main/MsTimer2

That is, using it on the Leonardo works fine, as it substitutes Timer4 for Timer2

You are not passing five arguments, you are passing one argument and using the overloaded + operator of the String class to construct that argument.  Stop putting that operator in the argument, either construct your new string first, or pass multiple strings as multiple arguments.

If you just need a starting reference point, consider attaching a hall effect sensor to the housing, and a small magnet to the dial, such that the magnet is directly over the hall effect sensor at 360'.  Then, you can just move in either direction until the magnet is directly over the sensor at startup.

Code:

 if((!readString.indexOf("test") >0) && (!readString.indexOf("test2") >0))

See the operator precedence: http://en.cppreference.com/w/cpp/language/operator_precedence

Note that ! is a higher precedence than >.

Consider what happens when we parenthesize by precedence:

Code:

if( !(readString.indexOf("test")) >0 && !(readString.indexOf("test2")) >0 )

PaulS is right too:

Code:

readString.indexOf("test")) <= 0

is a much more readable test and faster to type.

Code:

    ledOn = HIGH;
    digitalWrite(LEDPin, lodOn);

This assures that the state of the LED and the value of ledOn never get out of sync.

I know that you think it won't happen, but it does. A month later, you make a change to the digitalWrite statement and forget to change the following statement, and you spend a long time trying to figure out what went wrong with such a simple change.

Stranger things have happened!  A good point.  In general, I would isolate the LED code out of the loop too, unless I didn't expect that I'd do much more in my sketch.  I hate seeing long loop/main functions.

This results in turning the LED off immediately after turning it on:

Code:

    buttonState = digitalRead(buttonPin);   //check if the pushbutton is pressed
    Serial.println(buttonState);            //print pushbutton condition to serial monitor
    currentMillis = millis();
    if (buttonState == HIGH) {                            //if pushbutton has been pressed:     
       if (currentMillis - previousMillis > ontime) {     //check if difference between current time       
         digitalWrite(LEDPin, HIGH);                      //and previous time is larger than the alarm time
         previousMillis = currentMillis;       
       }
    }
    digitalWrite(LEDPin, LOW);              //turn LED off

Note that you say "if button is high, set led pin high;" followed by "always set led pin low".  That "always" part (digitalWrite(LEDPin, LOW)) happens on every single loop.  Consider the following instead:

Code:

unsigned int debounceTime = 100;
unsigned long          onTime = 5000;


...


void loop() {

  static bool                     ledOn = false;
  static unsigned long buttonTm = 0;
  static unsigned long      ledTm = 0;

    // always debounce your inputs, but debouncing uses a different time counter
    // than your LED on, necessarily, as you want to be able to press the button
    // more than once every on period

  if( digitalRead(buttonPin) == HIGH && millis() - buttonTm > debounceTime ) {

    buttonTm = millis();

    if( ledOn ) {
        // LED is already on, turn it off
      digitalWrite(LEDPin, LOW);
      ledOn = false;
    }
    else {
       // LED is not on, turn it on
      digitalWrite(LEDPin, HIGH);
      ledOn = true;
      ledTm = millis();
   }
 }

 if( ledOn == true && millis() - ledTm >= onTime ) {
     // LED has been on long enough to turn off automatically
   digitalWrite(LEDPin, LOW);
   ledOn = false;
 }
}

Hope that helps.

 
   
 

I want the user to be able to specify a size. At compile time. Dynamic allocation would mean grow the array as elements are add()ed. String is telling us that kind of functionality is not without problems

A point of note You can't do that with a #define and the Arduino IDE as you intimated earlier.  Only the code in your sketch sees the #define, the library is different compilation unit, and does not see it with the standard arduino make process.  (Unless of course, you ask them to inline your code in their .ino or something.)

!c

Can you post the code?

8k LoC and 30+ files?  No. (And its why I didn't post it in programming questions, but it got moved here anyhow.)

I'm asking if anyone is aware of any known deviations between the two environments which would be helpful as I go bit by bit trying to create a minimal reproducible case to identify the culprit.  "No, none are known." Is a perfectly acceptable answer. =)

!c

Are you dealing with Hobby Servos, which use PWM for positioning control and do not have speed control, or Servos as in brushless DC motors with encoder feedback?

Since you talk about speed control, I'm pretty sure you can't be talking about Hobby servos - or, at least, hobby servos are a poor choice for your application whereas a standard DC brushed motor, stepper, or brushless servo is a better choice.  (A continuous rotation modified hobby servo might as well be a brushed DC motor optimized for torque->size.)

If you're using PWM drivers for dc brushed motors, you can simply analogWrite() the speeds to your PWM output pins, and they'll all move at different rates...  If you modify both the period and the duty cycle, you can achieve lower speeds (measured over a longer time) by increasing the period, with the resulting "rougher" movement than typical PWM, which never sees the motor come to a complete stop.  You can roll your own, or perhaps use one of the PWM libraries of late that let you control both the period and duty cycle.

!c

Hi all, I'm noticing that between OSX and Windows distributions of the same version of Arduino (1.0.1), I'm getting a variation in hex size for the same sketch built for Leonardo. 

On OSX, the sketch compiles to 28,542 bytes, but on Windows it compiles to 28,708.  (Which is too large for Leonardo.)  On 1.0.2 the sketch is even larger, but I'll chalk that up to feature bloat.

Is anyone aware of any differences in the core libraries, or the AVR GCC compiler (or its options) between OSX and Windows that would account for the additional 166 bytes of flash usage?

Thanks!

!c