Go Down

Topic: Arduino Leonardo - bug? (Read 3 times) previous topic - next topic

Steph

You're doing a lot of direct addressing of the AVR ports. Have you checked the Leonardo schematic or the ATMega32U4 datasheet to verify that the AVR ports you are addressing match up to the pins on the leonardo? The 32u4 is very different from the ATMega328 on the UNO, so any sketch that is directly manipulating the AVR ports would need to be rewritten when moving from one uC to the other.

As for the sketch size swelling when you switch from UNO to Leonardo, most of that is due to the USB CDC and HID libraries which are automatically included on the Leonardo board. It's around 2 to 3k difference.

Finally, some of the differences in Serial.xxxx will probably boil down to being due to the Leonardo's serial port being a virtual CDC port so it's using different code than the hardware serial port on the UNO.

But going back to the problems in your sketch, I think it's mainly because the direct port manipulation seems to be configured for the UNO. Eg. the LED is arduino pin 13 on both boards, but it's not the same port/pin from an AVR point of view: On the Uno it's B5, on the Leonardo, it's C6. Almost everything else is different too - the ADC is very different, with the first 6 analog ports on portF then the rest scattered around the other ports.

DuaneB

Its quite interesting to see just how different the two chips are -

Atmega168/328 based Arduinos
http://arduino.cc/en/Hacking/PinMapping168

Atmega 32u4 Leonardo -
http://arduino.cc/en/Hacking/PinMapping32u4

Lots of audio projects that use direct port access and PWM outputs will not work without porting, including my own - as I found out last night.

Duane B

rcarduino.blogspot.com


guruevi

Just discovered another weirdness using the above script.

I send timestamps basically non-stop. At some point the Arduino stops transmitting because the hosts buffers are full (TXLED is off) - fine. If I empty the host buffers, it refills them, stops transmitting again. There seems to be some weird software-based flow control on the USB interface?

Then if I leave it in that state for a couple of minutes (buffers are full, no transmission) I get weird garbage back from the Arduino - I empty the host buffers by reading them really fast and then the Arduino seems to have randomly skipped Serial.write() calls between two Serial.write(10). While this is impossible for a processor to skip it's instructions I think maybe some type of buffer is getting overwritten somewhere even though I do have the Serial.flush() call?

Offending byte stream returned:
223
243
10
192
223
243
10
20
195
182


todicus

guruevi, did you ever find an explanation for this flow control weirdness?

Go Up