This is Issue 707 moved from a Google Code project.
Added by 2011-11-09T08:49:40.000Z by [email protected].
Please review that bug for more context and additional comments, but update this bug.

Original labels: Type-Defect, Priority-Medium

Original description

All the other bootloaders should be compilable using no more than what was downloaded as the Arduino Environment similar to way optboot does it.

This is Issue 1055 moved from a Google Code project.
Added by 2012-09-30T08:09:30.000Z by [email protected].
Please review that bug for more context and additional comments, but update this bug.

Original labels: Type-Enhancement, Priority-Medium

Original description

What steps will reproduce the problem?

1. There have been requests for a tutorial on modifying pins_arduino.h to meet the needs of custom-designed boards.
2. pins_arduino.h is not well documented internally.

The attached diffs add a bunch of comments (only! No actual code changes!) to variants/standard/pins_arduino.h explaining what it does and approximately how it works. This should make it a bit less confusing for a moderately skilled programmer to make their own variant.

This is Issue 774 moved from a Google Code project.
Added by 2012-01-05T07:11:07.000Z by [email protected].
Please review that bug for more context and additional comments, but update this bug.

Original labels: Type-Enhancement, Priority-Medium, Component-Core

Original description

What change would like to see?
Atmega 1280s, 2560s support multiple SPI buses and it would be very handy to be able to use them.

Why?
I'm on the arducopter team and in the APM2 hardware we use one SPI bus for the dataflash, and another for the MPU6000 (sensor that provides 3d accelerometer, gyro and magnetometer) and barometer.

Would this cause any incompatibilities with previous versions? If so, how can these be mitigated?
Yes, it might in that I believe you lose a serial port if you use it as an SPI. This means we might need to be smart about whether one of the serial ports (Serial3?) or SPI2 exists because both couldn't be used at the same time.

This is Issue 765 moved from a Google Code project.
Added by 2011-12-30T06:41:46.000Z by [email protected].
Please review that bug for more context and additional comments, but update this bug.

Original labels: Type-Defect, Priority-Medium

Original description

In using arduino as an ISP to program ATtiny13, I came across this issue in wiring.c where an incorrect macro is being used for the TIMER overflow.

# if defined(__AVR_ATtiny24__) || defined(__AVR_ATtiny44__) || defined(__AVR_ATtiny84__)

SIGNAL(TIM0_OVF_vect)
# else

SIGNAL(TIMER0_OVF_vect)
# endif

Checking iotn13.h, the timer overflow macro is TIM0_OVF_vect for __AVR_ATtiny13__ as well!

I am using Arduino 1.0 on a MAC OSX (The same is true even on glnx86).

This is Issue 1065 moved from a Google Code project.
Added by 2012-10-07T14:50:44.000Z by ElektorEmbedded.
Please review that bug for more context and additional comments, but update this bug.

Original labels: Type-Defect, Priority-Medium

Original description

What steps will reproduce the problem?

call tone(13,32768,100);

What is the expected output? What do you see instead?

Expected output: a 100 ms burst of a 32768 Hz square wave.
Real output: nothing.

The reason is an overflow in the calculation of toggle_count in the function tone. Overflow occurs for frequencies > 32767 Hz. Line 339:

  toggle_count = 2 * frequency * duration / 1000;

should be

  toggle_count = 2 * (long)frequency * duration / 1000;

What version of the Arduino software are you using? On what operating
system? Which Arduino board are you using?

Arduino 1.0.1 on Windows 7 and an Arduino Uno board

Regards,
Clemens

This is Issue 637 moved from a Google Code project.
Added by 2011-09-10T16:11:30.000Z by [email protected].
Please review that bug for more context and additional comments, but update this bug.

Original labels: Type-Defect, Priority-Medium

Original description

What steps will reproduce the problem?

If more data is received over Serial than the buffer can hold (or is not processed in time due to whatever blocking reason)

It is not difficult to add a counter in the Serial ringbuffer to count the lost characters. A function overflow() can be called to retrieve this counter.

see - http://arduino.cc/forum/index.php/topic,71833.msg538108.html#msg538108

This is Issue 248 moved from a Google Code project.
Added by 2010-05-06T18:47:09.000Z by [email protected].
Please review that bug for more context and additional comments, but update this bug.

Original labels: Type-Enhancement, Priority-Medium, Component-Core, Milestone-Post-1.0

Original description

What change would like to see?

An API for listening to the pin change interrupts.

This is Issue 169 moved from a Google Code project.
Added by 2010-01-03T23:18:20.000Z by [email protected].
Please review that bug for more context and additional comments, but update this bug.

Original labels: Type-Enhancement, Priority-Medium, Component-Core, Milestone-Post-1.0

Original description

What change would like to see?

The core should define the timer interrupt handlers and provide an API for registering a listener.

Why?

For example, the Servo library and the tone() function can't both be linked into a sketch because
they both define a timer 1 comparison interrupt handler.

Would this cause any incompatibilities with previous versions? If so, how
can these be mitigated?

There may be some timing issues.

This is Issue 813 moved from a Google Code project.
Added by 2012-02-10T18:07:05.000Z by [email protected].
Please review that bug for more context and additional comments, but update this bug.

Original labels: Type-Defect, Priority-Medium

Original description

On the 328 and more modern, you can read temperature and voltage. These are useful for many sensors. There's some simple code in the tinker.it repo for using them. We should add voltageRead() and temperatureRead() functions by wrapping these in a quick processor type check.

http://code.google.com/p/tinkerit/wiki/SecretThermometer

http://code.google.com/p/tinkerit/wiki/SecretVoltmeter

This is Issue 369 moved from a Google Code project.
Added by 2010-10-05T13:09:08.000Z by [email protected].
Please review that bug for more context and additional comments, but update this bug.

Original labels: Type-Enhancement, Priority-Medium, Component-Core

Original description

What change would like to see?

The addition of the powerEnable() and powerDisable() functions from Wiring:
http://wiring.org.co/reference/powerDisable_.html
http://wiring.org.co/reference/powerEnable_.html

Why?

To allow for power-saving and improve compatibility with Wiring.

This is Issue 376 moved from a Google Code project.
Added by 2010-10-13T15:04:34.000Z by [email protected].
Please review that bug for more context and additional comments, but update this bug.

Original labels: Type-Enhancement, Priority-Medium

Original description

I needed more flexible access to the serial receive buffer, without having to copy it to a local buffer. I implemented peek(uint8_t offset) and remove(uint8_t count) in 0018 for my own use. peek() allows me to look at any position in the buffer (< the number of bytes available) without removing data from the buffer. remove() allows me to remove multiple bytes from the buffer at once without having to loop with read() and available().

Patch against 0018 attached.

EDIT: The original issue from google code has been solved. This issue is still open to keep track of uploading problems using USBAsp programmer, see comments below for details.

This is Issue 388 moved from a Google Code project.
Added by 2010-10-28T20:36:23.000Z by [email protected].
Please review that bug for more context and additional comments, but update this bug.

Original description

What steps will reproduce the problem?

1. Wire up a connection between the Arduino Duemilanove and Mega 2560
2. Upload ArduinoISP (from IDE 021) to Arduino Duemilanove
3. Upload a new bootloader to a Mega 2560 via the 'programmer'

What is the expected output? What do you see instead?
After uploading, the mega should accept new sketches.

What version of the Arduino software are you using? On what operating
system? Which Arduino board are you using?

Arduino 021. Arduino Duemilanove as ArduinoISP (version from IDE 021), Arduino Mega 2560 as target hardware. Windows 7 64 bit.

Please provide any additional information below.
See http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1287952386 for original post of issue.

This is Issue 1022 moved from a Google Code project.
Added by 2012-08-30T14:00:13.000Z by [email protected].
Please review that bug for more context and additional comments, but update this bug.

Original labels: Type-Enhancement, Priority-Medium, Component-SoftwareSerial

Original description

What change would like to see?

From Ed Baafi. The ability for SoftwareSerial to use the same pin for RX and TX (half-duplex). See: https://github.com/Modkit/Arduino/commits/new-extension for a possible implementation.

It would be good if this worked well / simply if you only wanted to either transmit or receive, but not both.

Why?

To reduce pin usage.

Would this cause any incompatibilities with previous versions? If so, how
can these be mitigated?

This is Issue 902 moved from a Google Code project.
Added by 2012-04-26T04:40:25.000Z by [email protected].
Please review that bug for more context and additional comments, but update this bug.

Original labels: Type-Defect, Priority-Medium

Original description

What steps will reproduce the problem?

1. see below
   2.
   3.

What is the expected output? What do you see instead?

n/a

What version of the Arduino software are you using? On what operating
system? Which Arduino board are you using?

1.0, Uno.

Please provide any additional information below.

Shouldn't the option to disable TX or RX be written into SoftSerial?

This is Issue 581 moved from a Google Code project.
Added by 2011-08-16T21:58:53.000Z by [email protected].
Please review that bug for more context and additional comments, but update this bug.

Original labels: Type-Enhancement, Priority-Medium, Component-Core

Original description

This is basically the current turnOffPWM() function in wiring_digital.c. We should just rename it and expose it in the API.

This is Issue 1067 moved from a Google Code project.
Added by 2012-10-09T11:13:00.000Z by [email protected].
Please review that bug for more context and additional comments, but update this bug.

Original labels: Type-Defect, Priority-Medium

Original description

What steps will reproduce the problem?
1.Create any Sketch that uses progmem Data greater 64kB.
2.Compile & Download it using Arduino1.0.1 (Does all without any Error)
3.The Sketch crashes immediately after Reseting the Board.

What is the expected output? What do you see instead?

I expectet at least that the Sketch starts to run, but no Line of Code is ever executed. It stucks immediately after Reset altough Compiling and Downloading worked without any Error, so no debugging is possible!!

What version of the Arduino software are you using? On what operating
system? Which Arduino board are you using?

Arduino1.0.1 Version of May 12/2012 on Windows 7 32Bit.
Board: Arduino Mega2560.

Please provide any additional information below.

I checked out different AVR-Toolchains including the newest one, but that didn't solved the Issue. (But created other ones ;O( )
I use the lates Bootloader available here
https://github.com/arduino/Arduino-stk500v2-bootloader

You can use this Sketch to test the Issue:
https://github.com/arduino/Arduino-stk500v2-bootloader/tree/master/test/bigprogram

This is Issue 187 moved from a Google Code project.
Added by 2010-01-15T23:00:14.000Z by [email protected].
Please review that bug for more context and additional comments, but update this bug.

Original labels: Type-Defect, Priority-Medium, Component-Core

Original description

When IRQs are disabled at the time when timer0 overflows, micros() will
return wrong results.

What steps will reproduce the problem?

1. call t1=micros() just before a overflow of timer0
2. disable IRQ
3. wait after overflow of timer0 and after TCNT0 > 0
4. call t2=micros()
5. enable IRQ
6. call t3=micros()

now t2 is smaller than t1 because the ISR TIMER0_OVF_vect in wiring.c has
not been called and the overflow handling in micros() is wrong:

wrong, because it only works when t==0:
if ((TIFR0 & _BV(TOV0)) && (t == 0))
t = 256;

much better, but doesn't handle longer times with disabled IRQs:
if (TIFR0 & _BV(TOV0))
t += 256;

best: see attachment of patch

What is the expected output?
t1=2010104
t2=2010116
t3=2010124
ovl1=0 ovl2=1 novl2=0
t2-t1=12 t3-t1=20 t3-t2=8

What do you see instead?
t1=2010104
t2=2009092
t3=2010124
ovl1=0 ovl2=1 novl2=1
t2-t1=-1012 t3-t1=20 t3-t2=1032

What version of the Arduino software are you using? On what operating
system? Which Arduino board are you using?
I'm using Arduino-17 with Windows XP+SP3 and Arduino Duemilanove-328.

Please provide any additional information below.
The attachment "MicrosTimerOverflowTest.pde" contains a test case which
reproduces the problem. t2 must always be greater than t1.

The patch "wiring.patch" contains a fix which corrects the problem and also
solves the missing timer overflows problem when IRQs are disabled for a
longer time, as long as micros() is called at least once between two timer
overflows (around 1 microsecond on a ATmega 16Mhz).

This is Issue 618 moved from a Google Code project.
Added by 2011-09-01T13:50:50.000Z by [email protected].
Please review that bug for more context and additional comments, but update this bug.

Original labels: Type-Defect, Priority-Medium

Original description

What steps will reproduce the problem?

Building with gcc 4.5.3 for ATmega8 the "PE" is redefined in pins_arduino.c line 72. The previous declaration is in file iom8.h in line 516, is the PE bit of UCSRA. With ATmega328 where is no problem as the PE bit is renamed.
An easy solution is to move PE, PF, PG, PH, PJ, PK, and PL definitions from lines 72-78 in pins_arduino.c to line 82, inside the ATmega1280 block, as these ports exist only in arduino mega boads.

What version of the Arduino software are you using? On what operating
system? Which Arduino board are you using?

I am using 1.0beta2 with arduino-uno under debian-linux.

Please provide any additional information below.

In the 1.x version of Arduino language the SerialEvent() is supported. Although the opinions agree to disagree about the usefulness I would like to propose an improvement on it.

To fire SerialEvent() there is a call in main() that does something like

SerialEventRun()
{
if (Serial.Available()) SerialEvent();
}

for a Mega this is done for every port.

I would like to propose to pass the number of bytes seen by available() as a parameter to SerialEvent() as then the latter does not need to call the available function keeping the eventhandling shorter.

SerialEventRun()
{
int count = Serial.Available();
if (count) SerialEvent(count);
}

of course the Mega does this four times reusing the var count.

The programmer implementing SerialEvent(int count) can use count and does not need to call available(). Which removes one function call per serialEvent, might add up.

A more elaborated discussion can be found on the forum:

• http://arduino.cc/forum/index.php/topic,139353.0.html -

Regards,
Rob

This is Issue 558 moved from a Google Code project.
Added by 2011-06-10T14:31:23.000Z by [email protected].
Please review that bug for more context and additional comments, but update this bug.

Original labels: Type-Defect, Priority-Medium

Original description

What steps will reproduce the problem?

1. Call tone(13,31). You will see a very fast blinking on the LED.
2. Call tone(13,30). You will see a seemingly continuously lit LED (it actually is a very high frequency blink).
   Any frequency below 31Hz will reproduce the problem.

What is the expected output? What do you see instead?
Expect to see the correct frequency, but a much higher one is seen instead (using an oscilloscope). Also observed on other digital pins.

What version of the Arduino software are you using? On what operating
system? Which Arduino board are you using?
Tried on Arduino UNO and Nano with ATMega328,
using Arduino 0022 on linux.

When using Stream::readBytesUntil() and specifying a non-printable ASCII target byte (such as 0xFE) the function does not stop reading bytes when the target is encountered. However, when a printable ASCII byte value is specified as the target (such as 0x71 or 'q') the function does stop reading bytes as expected.

This seems to occur because in the function source the following comparison is made:

int c = timedRead();
if (c < 0 || c == terminator) break;

The variable "c" must be an int since timedRead() returns an int that is -1 if no data is available to read. The 2 byte signed int value for -1 (0xFFFF) can be differentiated from the single byte value 0xFF which could be a possible valid returned read byte from the stream. In its returned int form this value would be 0x00FF and would be interpreted as 255 rather than -1 in any logic test (such as c<0 as seen in the first part of the logic test in the code above). However, when performing an equality test (such as in the second part of the logic test above) between a two byte int value ("c") and a single byte char value (such as "terminator") the test only evaluates true if the values match and correspond to a printable ASCII character. The test fails if the values correspond to a non-printable ASCII character, even if they match. This may be related to a larger issue involving the primitive equality test when comparing variables of different types.

To extend the ability of Stream::readBytesUntil() to function for non-printable target bytes suggest the following change in the source:

if (c < 0 || (char)c == terminator) break;

By casting "c" to a char in the second part of the logic test the test will evaluate true if the byte values match regardless of whether they correspond to printable ASCII characters or not.

This is Issue 247 moved from a Google Code project.
Added by 2010-05-06T18:33:13.000Z by [email protected].
Please review that bug for more context and additional comments, but update this bug.

Original labels: Type-Enhancement, Priority-Medium, Component-Core

Original description

What change would like to see?

portRead() and portWrite() functions. Although given that the pins in the ports aren't necessarily all
available or contiguous, we'll have to figure out some of the details.

Why?

So you can read and write the whole port at once - for speed, and eliminating some potential
problems.

This is Issue 934 moved from a Google Code project.
Added by 2012-05-31T09:24:58.000Z by Love.Nystrom.
Please review that bug for more context and additional comments, but update this bug.

Original labels: Type-Defect, Priority-Medium

Original description

Arduinos equipped with the Atmel16u2 for USB communications
do not exhibit the behavior of a properly installed COM port.

It's likely this affects all devices not equipped with the
FTDI USB serial converter chip, though I can't confirm if
the bug is expressed on e.g UNO R1/R2, or newer Windows
(that may have an updated 'usbser' driver).

What steps will reproduce the problem?

1. Attach an UNO R3 to USB on a WinXP box.
2. Probably affect all the Atmel8u2/16u2 USB programs.

What is the expected behavior ?

Expected DBT_DEVICEARRIVAL.DBT_DEVTYP_PORT (e.g 'COM7')
This is the notification for a properly installed COM port,
whether it's physical or virtual.

What do you see instead ?

Only DBT_DEVICEARRIVAL.DBT_DEVTYP_DEVICEINTERFACE
?\USB#Vid_2341&Pid_0043#749343030303517191D0
#{a5dcbf10-6530-11d2-901f-00c04fb951ed}
This is merely a raw USB device with no specific properties.

What version of the Arduino software are you using?

Affects all versions I've checked.

On what operating system?

Misbehavior present on WinXP, can't confirm other versions.

Which Arduino board are you using?

Duemilanove, Nano, and UNO R3
The bug is present with UNO, not with 2oo9 and Nano.

Best Regards
Love Nystrom
Senior software engineer

Attachments:

1. FINDINGS.txt Annotated log of a few device attachments.
2. DevNfyTest.rar Source and executable for notification logger.

Additional info (sorry abt the wrapped lines, not my fault):

--------------------------------------------------------------------

LOG of WM_DEVICENOTIFICATION for different Arduinos and Upload BUBs

--------------------------------------------------------------------

Duemilanove attached

[W.T.F] WM_DEVICECHANGE.DBT_DEVNODES_CHANGED (7) lp=$0
[W.T.F] DBT_DEVICEARRIVAL (5) - Interface '?\USB#Vid_0403&Pid_6001#A900ceDU#{219d0508-57a8-4ff5-97a1-bd86587c6c7e}'
[W.T.F] DBT_DEVICEARRIVAL (5) - Interface '?\USB#Vid_0403&Pid_6001#A900ceDU#{a5dcbf10-6530-11d2-901f-00c04fb951ed}'
[W.T.F] WM_DEVICECHANGE.DBT_DEVNODES_CHANGED (7) lp=$0
[W.T.F] WM_DEVICECHANGE.DBT_DEVNODES_CHANGED (7) lp=$0
[W.T.F] DBT_DEVICEARRIVAL (5) - Interface '?\FTDIBUS#VID_0403+PID_6001+A900ceDUA#0000#{4d36e978-e325-11ce-bfc1-08002be10318}'
[W.T.F] DBT_DEVICEARRIVAL (5) - Interface '?\FTDIBUS#VID_0403+PID_6001+A900ceDUA#0000#{86e0d1e0-8089-11d0-9ce4-08003e301f73}'
[W.T.F] DBT_DEVICEARRIVAL (3) - Port 'COM3'
[W.T.F] WM_DEVICECHANGE.DBT_DEVNODES_CHANGED (7) lp=$0

Duemilanove detached

[W.T.F] WM_DEVICECHANGE.DBT_DEVNODES_CHANGED (7) lp=$0
[W.T.F] WM_DEVICECHANGE.DBT_DEVNODES_CHANGED (7) lp=$0
[W.T.F] DBT_DEVICEREMOVECOMPLETE (5) - Interface '?\FTDIBUS#VID_0403+PID_6001+A900ceDUA#0000#{86e0d1e0-8089-11d0-9ce4-08003e301f73}'
[W.T.F] DBT_DEVICEREMOVECOMPLETE (3) - Port 'COM3'
[W.T.F] DBT_DEVICEREMOVECOMPLETE (5) - Interface '?\FTDIBUS#VID_0403+PID_6001+A900ceDUA#0000#{4d36e978-e325-11ce-bfc1-08002be10318}'
[W.T.F] DBT_DEVICEREMOVECOMPLETE (5) - Interface '?\USB#Vid_0403&Pid_6001#A900ceDU#{219d0508-57a8-4ff5-97a1-bd86587c6c7e}'
[W.T.F] DBT_DEVICEREMOVECOMPLETE (5) - Interface '?\USB#Vid_0403&Pid_6001#A900ceDU#{a5dcbf10-6530-11d2-901f-00c04fb951ed}'

UNO R3 attached (Presents itself only as a generic USB device)

[W.T.F] WM_DEVICECHANGE.DBT_DEVNODES_CHANGED (7) lp=$0
[W.T.F] DBT_DEVICEARRIVAL (5) - Interface '?\USB#Vid_2341&Pid_0043#749343030303517191D0#{a5dcbf10-6530-11d2-901f-00c04fb951ed}'
[W.T.F] WM_DEVICECHANGE.DBT_DEVNODES_CHANGED (7) lp=$0

UNO R3 detached

[W.T.F] WM_DEVICECHANGE.DBT_DEVNODES_CHANGED (7) lp=$0
[W.T.F] DBT_DEVICEREMOVECOMPLETE (5) - Interface '?\USB#Vid_2341&Pid_0043#749343030303517191D0#{a5dcbf10-6530-11d2-901f-00c04fb951ed}'
[W.T.F] WM_DEVICECHANGE.DBT_DEVNODES_CHANGED (7) lp=$0

Nano attached

[W.T.F] WM_DEVICECHANGE.DBT_DEVNODES_CHANGED (7) lp=$0
[W.T.F] DBT_DEVICEARRIVAL (5) - Interface '?\USB#Vid_0403&Pid_6001#10KP0585#{219d0508-57a8-4ff5-97a1-bd86587c6c7e}'
[W.T.F] DBT_DEVICEARRIVAL (5) - Interface '?\USB#Vid_0403&Pid_6001#10KP0585#{a5dcbf10-6530-11d2-901f-00c04fb951ed}'
[W.T.F] WM_DEVICECHANGE.DBT_DEVNODES_CHANGED (7) lp=$0
[W.T.F] WM_DEVICECHANGE.DBT_DEVNODES_CHANGED (7) lp=$0
[W.T.F] DBT_DEVICEARRIVAL (5) - Interface '?\FTDIBUS#VID_0403+PID_6001+10KP0585A#0000#{4d36e978-e325-11ce-bfc1-08002be10318}'
[W.T.F] DBT_DEVICEARRIVAL (5) - Interface '?\FTDIBUS#VID_0403+PID_6001+10KP0585A#0000#{86e0d1e0-8089-11d0-9ce4-08003e301f73}'
[W.T.F] DBT_DEVICEARRIVAL (3) - Port 'COM10'
[W.T.F] WM_DEVICECHANGE.DBT_DEVNODES_CHANGED (7) lp=$0
[W.T.F] WM_DEVICECHANGE.DBT_DEVNODES_CHANGED (7) lp=$0
[W.T.F] WM_DEVICECHANGE.DBT_DEVNODES_CHANGED (7) lp=$0

Nano detached

[W.T.F] WM_DEVICECHANGE.DBT_DEVNODES_CHANGED (7) lp=$0
[W.T.F] WM_DEVICECHANGE.DBT_DEVNODES_CHANGED (7) lp=$0
[W.T.F] DBT_DEVICEREMOVECOMPLETE (5) - Interface '?\FTDIBUS#VID_0403+PID_6001+10KP0585A#0000#{86e0d1e0-8089-11d0-9ce4-08003e301f73}'
[W.T.F] DBT_DEVICEREMOVECOMPLETE (3) - Port 'COM10'
[W.T.F] DBT_DEVICEREMOVECOMPLETE (5) - Interface '?\FTDIBUS#VID_0403+PID_6001+10KP0585A#0000#{4d36e978-e325-11ce-bfc1-08002be10318}'
[W.T.F] DBT_DEVICEREMOVECOMPLETE (5) - Interface '?\USB#Vid_0403&Pid_6001#10KP0585#{219d0508-57a8-4ff5-97a1-bd86587c6c7e}'
[W.T.F] DBT_DEVICEREMOVECOMPLETE (5) - Interface '?\USB#Vid_0403&Pid_6001#10KP0585#{a5dcbf10-6530-11d2-901f-00c04fb951ed}'

Modern Device BUB 2 attached

[W.T.F] WM_DEVICECHANGE.DBT_DEVNODES_CHANGED (7) lp=$0
[W.T.F] DBT_DEVICEARRIVAL (5) - Interface '?\USB#Vid_0403&Pid_6001#A40119EJ#{219d0508-57a8-4ff5-97a1-bd86587c6c7e}'
[W.T.F] DBT_DEVICEARRIVAL (5) - Interface '?\USB#Vid_0403&Pid_6001#A40119EJ#{a5dcbf10-6530-11d2-901f-00c04fb951ed}'
[W.T.F] WM_DEVICECHANGE.DBT_DEVNODES_CHANGED (7) lp=$0
[W.T.F] WM_DEVICECHANGE.DBT_DEVNODES_CHANGED (7) lp=$0
[W.T.F] DBT_DEVICEARRIVAL (5) - Interface '?\FTDIBUS#VID_0403+PID_6001+A40119EJA#0000#{4d36e978-e325-11ce-bfc1-08002be10318}'
[W.T.F] DBT_DEVICEARRIVAL (5) - Interface '?\FTDIBUS#VID_0403+PID_6001+A40119EJA#0000#{86e0d1e0-8089-11d0-9ce4-08003e301f73}'
[W.T.F] DBT_DEVICEARRIVAL (3) - Port 'COM8'
[W.T.F] WM_DEVICECHANGE.DBT_DEVNODES_CHANGED (7) lp=$0

Modern Device BUB 2 detached

[W.T.F] WM_DEVICECHANGE.DBT_DEVNODES_CHANGED (7) lp=$0
[W.T.F] WM_DEVICECHANGE.DBT_DEVNODES_CHANGED (7) lp=$0
[W.T.F] DBT_DEVICEREMOVECOMPLETE (5) - Interface '?\FTDIBUS#VID_0403+PID_6001+A40119EJA#0000#{86e0d1e0-8089-11d0-9ce4-08003e301f73}'
[W.T.F] DBT_DEVICEREMOVECOMPLETE (3) - Port 'COM8'
[W.T.F] DBT_DEVICEREMOVECOMPLETE (5) - Interface '?\FTDIBUS#VID_0403+PID_6001+A40119EJA#0000#{4d36e978-e325-11ce-bfc1-08002be10318}'
[W.T.F] DBT_DEVICEREMOVECOMPLETE (5) - Interface '?\USB#Vid_0403&Pid_6001#A40119EJ#{219d0508-57a8-4ff5-97a1-bd86587c6c7e}'
[W.T.F] DBT_DEVICEREMOVECOMPLETE (5) - Interface '?\USB#Vid_0403&Pid_6001#A40119EJ#{a5dcbf10-6530-11d2-901f-00c04fb951ed}'
[W.T.F] WM_DEVICECHANGE.DBT_DEVNODES_CHANGED (7) lp=$0

This is Issue 506 moved from a Google Code project.
Added by 2011-03-19T17:41:49.000Z by [email protected].
Please review that bug for more context and additional comments, but update this bug.

Original labels: Type-Defect, Priority-Medium, Component-Core

Original description

Hi there,

currently Wire (through twi_init()) enables by default the internal pullups of the uC.

As all 16MHz runs at 5V this means that with pullups enabled signals will have a 5 volt on logic level. Unfortunately, as many I2C devices runs at 3 Volts and aren't 5Volts tolerant, sending 5V signals to them is clearly a very bad idea.

I would propose making the pullpus enabling optional and off by default. In my experience, people overlook the fact that Wire does enable the pullups causing possible problems on the I2C devices used.

Moreover, tests (http://www.dsscircuits.com/articles/effects-of-varying-i2c-pull-up-resistors.html) have shown that internal pullups performs extremely bad in terms of signal quality and bus speed. So, they shouldn't been used anyway.

In case this is accepted, I'll gladly submit a patch for this.

Thanks,

Fabio Varesano

This is Issue 256 moved from a Google Code project.
Added by 2010-05-11T15:28:29.000Z by [email protected].
Please review that bug for more context and additional comments, but update this bug.

Original labels: Type-Enhancement, Priority-Medium, Component-Core, OpSys-All

Original description

What change would like to see?

Switching to delayMicroseconds() code here: http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1273573826

Why?

Making the function more accurate for compile-time-constant delays and generalizing it for any
CPU speed.

Would this cause any incompatibilities with previous versions? If so, how
can these be mitigated?

There could be some issues with very timing sensitive routines.

This is Issue 570 moved from a Google Code project.
Added by 2011-07-18T02:13:36.000Z by [email protected].
Please review that bug for more context and additional comments, but update this bug.

Original labels: Type-Enhancement, Priority-Medium, Component-Core

Original description

I would like to see the method begin() added to the Stream class.

I'm currently writing a hardware abstraction class that works with both HardwareSerial and NewSoftSerial (because they inherit from Stream) but i can't see how i can call the begin() method of either HardwareSerial or NewSoftSerial from within my class, leaving that task to the user and not being as abstract as it could be.

the MIDI class could benefit from this, as it could work with both HardwareSerial and NewSoftSerial, thus allowing more than one MIDI object.

I don't know if this enhancement would cause conflict with anything else, but i don't see it could cause any harm.

This is Issue 1031 moved from a Google Code project.
Added by 2012-09-03T19:30:50.000Z by [email protected].
Please review that bug for more context and additional comments, but update this bug.

Original labels: Type-Defect, Priority-High, Component-ATmega32U4

Original description

What steps will reproduce the problem?

1. Load Examples ... 04. Communcations... SerialEvent example
2. Add while (!Serial) ; after Serial.begin() in setup
3. Upload to a Leonardo board, type stuff in the serial monitor

What is the expected output? What do you see instead?

Expected: Get back what I typed
Actual: Got nothing back

What version of the Arduino software are you using? On what operating
system? Which Arduino board are you using?

Arduino 1.0.1 on MacOS X 10.7.4 with a Leonardo R3 board

Please provide any additional information below.

I believe serialEvent is never called. I tried renaming it to serialEvent1 and serialEvent2 without any effect.

This is Issue 164 moved from a Google Code project.
Added by 2010-01-02T00:48:44.000Z by [email protected].
Please review that bug for more context and additional comments, but update this bug.

Original labels: Type-Enhancement, Priority-Medium

Original description

What change would like to see?

The Print class could make use if its own block write method.

Why?

Some classes that use Print, such as Ethernet, can substantially benefit
from the block write.

Would this cause any incompatibilities with previous versions? If so, how
can these be mitigated?

If another class does not make use of the block write, the single byte
write is automatically used to write each byte from the block. There should
be no incompatibilities.

For example, printNumber already buffers, but then duplicates the
functionality of transmitting the bytes one at a time. It's simple to
change so the bytes are packed into the buffer in the correct order, so the
block write can be used:

void Print::printNumber(unsigned long n, uint8_t base, uint8_t sign)
{
        uint8_t buf[8 * sizeof(long) + 1]; // Assumes 8-bit chars.
        uint8_t digit, i;

        if (n == 0) {
                buf[sizeof(buf) - 1] = '0';
                i = sizeof(buf) - 1;
        } else {
                i = sizeof(buf) - 1;
                while (1) {
                        digit = n % base;
                        buf[i] = ((digit < 10) ? '0' + digit : 'A' + digit - 10);
                        n /= base;
                        if (n == 0) break;
                        i--;
                }
        }
        if (sign) {
                i--;
                buf[i] = sign;
        }
        write(buf + i, sizeof(buf) - i);
}

This also includes packing the sign into the buffer. This it can be called
like this:

void Print::print(long n)
{
        uint8_t sign=0;

        if (n < 0) {
                sign = '-';
                n = -n;
        }
        printNumber(n, 10, sign);
}

void Print::print(unsigned long n)
{
        printNumber(n, 10, 0);
}

Likewise, printing the newline is easy to change:

void Print::println(void)
{
        uint8_t buf[2]={'\r', '\n'};
        write(buf, 2);
}

Float printing requires a bit more effort, but it's also not too difficult
(especially if this already-tested code is just copied):

void Print::printFloat(double number, uint8_t digits)
{
  uint8_t sign=0;

  // Handle negative numbers
  if (number < 0.0) {
     sign = '-';
     number = -number;
  }

  // Round correctly so that print(1.999, 2) prints as "2.00"
  double rounding = 0.5;
  for (uint8_t i=0; i<digits; ++i)
    rounding /= 10.0;

  number += rounding;

  // Extract the integer part of the number and print it
  unsigned long int_part = (unsigned long)number;
  double remainder = number - (double)int_part;
  printNumber(int_part, 10, sign);

  // Print the decimal point, but only if there are digits beyond
  if (digits > 0) {
        uint8_t n, buf[5], count=1;
        buf[0] = '.';

        //write('.'); 
        // Extract digits from the remainder one at a time
        if (digits > sizeof(buf) - 1) digits = sizeof(buf) - 1;

        while (digits-- > 0) {
                remainder *= 10.0;
                n = (uint8_t)(remainder);
                buf[count++] = '0' + n;
                remainder -= n;
        }
        write(buf, count);
  }
}

This is Issue 650 moved from a Google Code project.
Added by 2011-09-22T20:33:15.000Z by [email protected].
Please review that bug for more context and additional comments, but update this bug.

Original labels: Type-Defect, Priority-Medium

Original description

When attempting to burn a bootloader using either the IDE Burn Bootloader option
or any of the Makefiles down in the hardware/arduino/bootloaders/xxx
the fuses will be burned and the flash erased but the bootloader is not burned
resulting in a non operational chip.

This behavior is easily reproducible on both windows and Ubuntu linux.
It is probably an issue other OSs and
potentially an issue with other USB ISP programmers.

This is not a permissions issue or a libusb installation/configuration issue.

This is due to an interaction between how the burning tool
(IDE or Makefile) is using avrdude, avrdude itself, libusb and the OS.

The crux of the problem is that two avrdude commands are being used to burn
a bootloader. One command to set the fuses and erase the flash and another
to burn the bootloader to the flash.
The 2nd avrdude command is failing because it can't locate the USB device.

Digging deeper, the problem is that when the avrdude command finishes
using the USB device, it resets the USB device.
This reset cause the USB device to have to go
through enumeration again. This enumeration takes time. If another avrdude
command runs before the enumeration is complete, it will not see the USB
device on the USB bus.

The reset cannot be removed because for some reason if the USB device is
not reset, it will fail to communicate properly. There is probably some
other issue either in the OS or libusb itself that is causing this issue.

In my view this really is an avrdude command issue or at least an
issue that avrdude could resolve.
I went so far as to enter a bug for it on savannah:
https://savannah.nongnu.org/bugs/?34339
So far, it was not well received as the avrdude maintainer
considers this to be an OS issue rather than an avrdude issue.

There are some options to work around this.

1. add a blind delay between the two avrdude commands (in IDE and Makefiles)
2. Update the avrdude code to poll for the devices for a few seconds
   rather than just look one time.
3. Alter the IDE and Makefiles to use a single avrdude command rather than two.
   arduino/Arduino#1)

Currently, it looks like there already is a 1 second blind delay in the IDE
code down in AvrdudeUploader.java in the burnBootloader() function.
The problem is that 1 second is not long enough.
From my experimentation on some of my machines, on Ubuntu 10.10
2 seconds seems to work. While I didn't fully test this
on Windows to find the exact time needed,
I can say that on my older 1.6Ghz Dell, it takes longer
than 2 seconds for the enumeration to complete.
The problem with these blind delays is that it slows down things for everyone
since the full wait is always done and there is no way to really know what
the best value to pick is.
arduino/Arduino#2)

It is possible to modify the avrdude code to be smarter to try to
poll "a while" looking for USB devices rather than just look one time.
I modified the code in usb_libusb.c to do this (it is only 7 lines of code)
and placed a patch for it in the savannah bug noted above.
This update works great, it polls the USB every 1/10 of second until
it finds the desired USB device - using a maximum delay of 3 seconds
(Probably should up this to 5 seconds.)
The nice thing is it will now only delay as long
as needed and only the full time if truely there is a problem. On my Ubuntu 10.10
machine the delay is just over 1 second.
But given the initial reception for updating avrdude to compensate
for the USB device behavior, this type of change probabaly will not be
accepted or at least may be well beyond the uno 1.0 release timeframe.
arduino/Arduino#3)

Perhaps the best way to deal with the issue is to avoid it
completely by changing things to burn the fuses and the bootloader
in a single avrdude command.
It is a vary small change to modify the java code and the Makefiles
to use a single avrdude comman rather than two.
Not only will doing this avoid the issue, but it will speed up
the bootloader burning process by avoiding the overhead of a blind
delay and the overhead of a second avrdude command.
It may also help in some cases with AutoReset issues on non USB
devices as there will no longer be a port close and re-open between
setting the fuses and burning the bootloade since it would all
now be done with a single call to avrdude.

I modified the optiboot Makefile in westfw's latest optiboot working tree
to do this as an example.
(See attachment). It was a very small change and this change
can and probably should be propagated through all the other Makefiles as well.
It is very simple and impacts no other code.

The JAVA code can easily do the same.
So down in burnBootLoader() rather than call avrdude() and then
Thread.sleep(1000)
Just build up a single List for both the fuses and the bootloader

I've attached an untested attempt at what that could look like.

This is Issue 273 moved from a Google Code project.
Added by 2010-06-07T03:48:36.000Z by [email protected].
Please review that bug for more context and additional comments, but update this bug.

Original labels: Type-Defect, Priority-Medium

Original description

What steps will reproduce the problem?

1. Make an array of at least a page of 0xFF in progmem.
2. Try to read it from inside your Arduino sketch.
3. Notice! The page will contain whatever the memory contents were the
   last time you programmed the chip!

What is the expected output? What do you see instead?
I expect to see a big long series of 0xff, and instead, I see whatever was
on the chip before.

What version of the Arduino software are you using? On what operating
system? Which Arduino board are you using?
I am using Arduino-0018 on Ubuntu, with a variety of Arduino boards.

Please provide any additional information below.

I first noticed this a few days ago:
http://forum.arduino.cc/index.php?topic=8814.msg72667#msg72667

I reported this upstream:
https://savannah.nongnu.org/bugs/?30061
but I noticed that there is a version of avrdude
in the arduino tree, so I figured I'd report it here as well.

I dug around the source, and I narrowed the issue down to
stk500_paged_write in stk500.c, there's a check for stk500_is_page_empty.
If the whole page consists of 0xFF, the page isn't written. This assumes
the page/chip has been erased. Autoerase is turned off in arduino, so this
is an incorrect assumption.

I commented out

/* Only skip on empty page if programming flash. */
if (flash) {
if (stk500_is_page_empty(addr, block_size, m->buf)) {
continue;
}
~~} ~~

in stk500.c, and this fixes the issue, increasing accuracy at the expense
of write speed.

EDIT:
Update: Commenting that section out doesn't actually appear to fix it. Sorry, errant test result on my side.

However, commenting out the line

commandDownloader.add("-D"); // don't erase

in app/src/processing/app/debug/AvrdudeUploader.java does fix this issue.

I'm not sure of how it usually works, if you usually wait for upstream to
fix, or whatnot, but I thought I'd let you know. Thanks!

This is Issue 367 moved from a Google Code project.
Added by 2010-10-03T05:59:53.000Z by [email protected].
Please review that bug for more context and additional comments, but update this bug.

Original labels: Type-Enhancement, Priority-Medium

Original description

init() in wiring.c currently does a series of sbi() calls to set bits in the configuration registers for timers, ADC, and etc.

There are two problems with this:

1. since the registers are all volatile, they get read and re-written for each bit, resulting in rather bulky code.
2. The code makes assumptions that the other bits in the register are already in the desired state, which need not be true (leading to http://code.google.com/p/arduino/issues/detail?id=364 for example.)

The attached code sets the desired state of the registers all 8 bits at once. Faster, smaller, and less prone to errors caused by unexpected initial states.

(I checked that the initial state of the registers in question is 0, and This compiles for all three platforms, and I checked that Fading.pde works on all PWM pins on an Uno, but making this sort of large change makes me nervous...)

This is Issue 632 moved from a Google Code project.
Added by 2011-09-08T21:07:23.000Z by [email protected].
Please review that bug for more context and additional comments, but update this bug.

Original labels: Type-Enhancement, Priority-Medium, Component-Core

Original description

It would be cool if the tone() function used hardware (PWM) output instead of interrupt-driven output when possible. This would allow for higher maximum frequencies when using the right pins.

This is Issue 780 moved from a Google Code project.
Added by 2012-01-07T16:57:14.000Z by [email protected].
Please review that bug for more context and additional comments, but update this bug.

Original labels: Type-Enhancement, Priority-Medium, Component-SoftwareSerial

Original description

Summary explains everything :)

This is Issue 334 moved from a Google Code project.
Added by 2010-08-22T01:00:36.000Z by [email protected].
Please review that bug for more context and additional comments, but update this bug.

Original labels: Type-Enhancement, Priority-Medium

Original description

What change would like to see?
I wanted to see clock_skew support.
Why?
Because slaves might needed to make some job that takes long time. So If we drive SCL low, than master knows that slave is busy.

Would this cause any incompatibilities with previous versions? If so, how
can these be mitigated?
No, it doesn't cause any incompatibility.

This is Issue 886 moved from a Google Code project.
Added by 2012-04-13T20:49:25.000Z by [email protected].
Please review that bug for more context and additional comments, but update this bug.

Original labels: Type-Defect, Priority-Medium

Original description

What steps will reproduce the problem?

1. Install LUFA101122
2. cd hardware/arduino/firmwares/arduino-usbserial
3. make

What is the expected output?

A file: Arduino-usbserial-mega.hex

What do you see instead?

avr-gcc (GCC) 4.5.3
Copyright (C) 2010 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Compiling C: Arduino-usbserial.c
avr-gcc -c -mmcu=atmega8u2 -I. -gdwarf-2 -DF_CPU=16000000UL -DF_CLOCK=16000000UL -DARDUINO_MODEL_PID=0x0001 -DBOARD=BOARD_USER -D USB_DEVICE_ONLY -D FIXED_CONTROL_ENDPOINT_SIZE=8 -D FIXED_NUM_CONFIGURATIONS=1 -D USE_FLASH_DESCRIPTORS -D INTERRUPT_CONTROL_ENDPOINT -D DEVICE_STATE_AS_GPIOR=0 -D USE_STATIC_OPTIONS="(USB_DEVICE_OPT_FULLSPEED | USB_OPT_REG_ENABLED | USB_OPT_AUTO_PLL)" -DAVR_RESET_LINE_PORT="PORTD" -DAVR_RESET_LINE_DDR="DDRD" -DAVR_RESET_LINE_MASK="(1 << 7)" -DTX_RX_LED_PULSE_MS=3 -DPING_PONG_LED_PULSE_MS=100 -Os -funsigned-char -funsigned-bitfields -ffunction-sections -fno-inline-small-functions -fpack-struct -fshort-enums -fno-strict-aliasing -Wall -Wstrict-prototypes -Wa,-adhlns=./Arduino-usbserial.lst -I../../ -std=gnu99 -Wundef -MMD -MP -MF .dep/Arduino-usbserial.o.d Arduino-usbserial.c -o Arduino-usbserial.o
In file included from Arduino-usbserial.h:45:0,
from Arduino-usbserial.c:37:
Descriptors.h:84:12: error: conflicting types for 'CALLBACK_USB_GetDescriptor'
./LUFA/Drivers/USB/HighLevel/../LowLevel/Device.h:205:13: note: previous declaration of 'CALLBACK_USB_GetDescriptor' was here
In file included from Arduino-usbserial.h:50:0,
from Arduino-usbserial.c:37:
./LUFA/Drivers/Board/LEDs.h:120:18: warning: "BOARD_USBFOO" is not defined
make: *** [Arduino-usbserial.o] Error 1

What version of the Arduino software are you using? On what operating
system? Which Arduino board are you using?

Version: git://github.com/arduino/Arduino.git

Linux, Ubuntu

Please provide any additional information below.

I have tried to compile with LUFA-120219 but it gave even more errors.

This is Issue 965 moved from a Google Code project.
Added by 2012-06-24T21:16:49.000Z by [email protected].
Please review that bug for more context and additional comments, but update this bug.

Original labels: Type-Enhancement, Priority-Medium, Component-SPI

Original description

What change would like to see?

The SPI class currently has a method attachInterrupt() that simplifies getting SPI transfer completes to trigger an interrupt. This does this:

void SPIClass::attachInterrupt() {
SPCR |= _BV(SPIE);
}

However there is no method to turn SPI into slave mode, which is where these interrupts would be useful. Suggest adding:

void SPIClass::setSlaveMode() {
pinMode(SS, INPUT);
SPCR |= _BV(SPE);
}

Why?

It seems unbalanced to have a method to do half the job of setting up an SPI slave - turning interrupts on. It would be more complete to also be able to go into slave mode.

Would this cause any incompatibilities with previous versions? If so, how
can these be mitigated?

There would be no incompatibilities because this method does not currently exist.

This is Issue 560 moved from a Google Code project.
Added by 2011-06-15T12:00:19.000Z by [email protected].
Please review that bug for more context and additional comments, but update this bug.

Original labels: Type-Defect, Priority-Low

Original description

What steps will reproduce the problem?

1. "make atmega8_isp" (assuming you've got updated source that has that target)

What is the expected output? What do you see instead?
expected output is to build a mega8 version of bootloader and download it to a mega8 chip via whatever programmer is configured. What happens is that the "isp" target always specifies a value for the "extended" fuse byte, which mega8 doesn't have, so avrdude issues an error message and quits.

Please use labels and text to provide additional information.

optiboot on atmega8 isn't "supported" specifically, so this may be slow to change. The workaround is to manually (cut & paste) run the equivalent avrdude commands without the EFUSE programming section.

This is Issue 466 moved from a Google Code project.
Added by 2011-01-23T16:08:36.000Z by [email protected].
Please review that bug for more context and additional comments, but update this bug.

Original labels: Type-Defect, Priority-Medium, Component-Core

Original description

Hi everybody,

Having now quite some experience in working with I2C devices I think that the current implementation of Wire lacks some very helpful routines to do something which is quite standard with I2C devices: write to a register and read from a register of the slave device (when arduino is the master).

The results is that, if you have a look at the various I2C devices Arduino libraries you'll see often the repetition of the following lines:

For slave register write:
Wire.beginTransmission(DEVICE_ADDRESS);
Wire.send(REG_ADDRESS);
Wire.send(VAL_TO_WRITE);
Wire.endTransmission();

For slave register read:
Wire.beginTransmission(DEVICE_ADDRESS);
Wire.send(REG_ADDRESS);
Wire.endTransmission();
Wire.beginTransmission(DEVICE_ADDRESS);
Wire.requestFrom(DEVICE_ADDRESS,NUM_BYTES_TO_READ);
int i = 0;
while(Wire.available()) { //ACC may send less than requested (abnormal)
buff[i] = Wire.receive(); // receive a byte
i++; }
Wire.endTransmission();

I saw code similar to that in almost all the I2C Arduino libs out there.. Of course, this results in huge code repetition if you are using more than one I2C device comporting increase in program memory and additional unneeded code complexity. This can also be seen in the Wire lib examples!

But let's make practical examples..

Example SFRRanger_reader in Wire lib examples:
// step 1: instruct sensor to read echoes
Wire.beginTransmission(112); // transmit to device arduino/Arduino#112 (0x70)
// the address specified in the datasheet is 224 (0xE0)
// but i2c adressing uses the high 7 bits so it's 112
Wire.send(0x00); // sets register pointer to the command register (0x00)
Wire.send(0x50); // command sensor to measure in "inches" (0x50)
// use 0x51 for centimeters
// use 0x52 for ping microseconds
Wire.endTransmission(); // stop transmitting

// step 3: instruct sensor to return a particular echo reading
Wire.beginTransmission(112); // transmit to device arduino/Arduino#112
Wire.send(0x02); // sets register pointer to echo arduino/Arduino#1 register (0x02)
Wire.endTransmission(); // stop transmitting

// step 4: request reading from sensor
Wire.requestFrom(112, 2); // request 2 bytes from slave device arduino/Arduino#112

// step 5: receive reading from sensor
if(2 <= Wire.available()) // if two bytes were received
{
reading = Wire.receive(); // receive high byte (overwrites previous reading)
reading = reading << 8; // shift high byte to be high 8 bits
reading |= Wire.receive(); // receive low byte as lower 8 bits
Serial.println(reading); // print the reading
}

digital_potentiometer example in Wire lib

Wire.beginTransmission(44); // transmit to device arduino/Arduino#44 (0x2c)
// device address is specified in datasheet
Wire.send(0x00); // sends instruction byte
Wire.send(val); // sends potentiometer value byte
Wire.endTransmission(); // stop transmitting

ADXL345 arduino driver, http://code.google.com/p/adxl345driver/

// Writes val to address register on device
void ADXL345::writeTo(byte address, byte val) {
Wire.beginTransmission(DEVICE); // start transmission to device
Wire.send(address); // send register address
Wire.send(val); // send value to write
Wire.endTransmission(); // end transmission
}

// Reads num bytes starting from address register on device in to _buff array
void ADXL345::readFrom(byte address, int num, byte _buff[]) {
Wire.beginTransmission(DEVICE); // start transmission to device
Wire.send(address); // sends address to read from
Wire.endTransmission(); // end transmission

Wire.beginTransmission(DEVICE); // start transmission to device
Wire.requestFrom(DEVICE, num); // request 6 bytes from device

int i = 0;
while(Wire.available()) // device may send less than requested (abnormal)
{
_buff[i] = Wire.receive(); // receive a byte
i++;
}
if(i != num){
status = ADXL345_ERROR;
error_code = ADXL345_READ_ERROR;
}
Wire.endTransmission(); // end transmission
}

ITG3200 http://code.google.com/p/itg-3200driver/

void ITG3200::writemem(byte _addr, byte _val) {
Wire.beginTransmission(_dev_address); // start transmission to device
Wire.send(_addr); // send register address
Wire.send(_val); // send value to write
Wire.endTransmission(); // end transmission
}

void ITG3200::readmem(byte _addr, int _nbytes, byte __buff[]) {
Wire.beginTransmission(_dev_address); // start transmission to device
Wire.send(_addr); // sends register address to read from
Wire.endTransmission(); // end transmission

Wire.beginTransmission(_dev_address); // start transmission to device
Wire.requestFrom(_dev_address, _nbytes);// send data n-bytes read
byte i = 0;
while (Wire.available()) {
__buff[i] = Wire.receive(); // receive DATA
i++;
}
Wire.endTransmission(); // end transmission
}

HMC5843 library https://launchpad.net/hmc58x3

void HMC5843::writeReg(unsigned char reg, unsigned char val) {
Wire.beginTransmission(HMC5843_ADDR);
Wire.send(reg); // send register address
Wire.send(val); // send value to write
Wire.endTransmission(); //end transmission
}

void HMC5843::getValues(float *x,float *y,float *z) {
int xr,yr,zr;
Wire.beginTransmission(HMC5843_ADDR);
Wire.send(HMC5843_R_XM); // will start from DATA X MSB and fetch all the others
Wire.endTransmission();

Wire.beginTransmission(HMC5843_ADDR);
Wire.requestFrom(HMC5843_ADDR, 6);
if(6 == Wire.available()) {
// read out the 3 values, 2 bytes each.
xr = Wire.receive();
xr = (xr << 8) + Wire.receive();
*x= ((float) xr) / x_scale;
yr = Wire.receive();
yr = (yr << 8) + Wire.receive();
*y = ((float) yr) / y_scale;
zr = Wire.receive();
zr = (zr << 8) + Wire.receive();
*z = ((float) zr) / z_scale;
// the HMC5843 will automatically wrap around on the next request
}
Wire.endTransmission();
}

Same happens for
http://interactive-matter.eu/2009/12/arduino-barometric-pressure-sensor-bmp085/
http://www.neufeld.newton.ks.us/electronics/?p=241
http://naneau.nl/2009/01/18/arduino-and-an-i2c-temperature-sensor/
http://bazaar.launchpad.net/~nxti2cdev/nxti2cdevice/trunk/view/head:/BaseNXTI2CDevice.cpp
http://www.arduino.cc/playground/Code/I2CEEPROM

and basically any code from Googleing "Arduino I2C" shows some examples of that.

Now, in the attached patch I implemented two simple functions which implements those functionalities. I'll gladly add documentation and write to the various maintainers of the I2C libs if this get inserted into Wire.

Interested in hearing your opinions,

Thanks,

Fabio Varesano

This is Issue 869 moved from a Google Code project.
Added by 2012-03-29T13:31:23.000Z by [email protected].
Please review that bug for more context and additional comments, but update this bug.

Original labels: Type-Defect, Priority-Medium, Component-Build

Original description

On some boards (maybe those with the FT232RL datecode 1138 (2011 week 38)), uploading seems to fail with the avrdude 5.10 in Arduino 1.0 using the "arduino" programmer type. With the stk500v1 protocol (which doesn't do the auto reset in avrdude), the upload seems to work: http://arduino.cc/forum/index.php/topic,81330.15.html

I wonder if the problem is with the timing of the delay for the auto-reset in the arduino programmer type in the new avrdude. Maybe this particular version of the FTDI hardware / drivers ignores pulses of less than a certain length of something similar.

This is Issue 822 moved from a Google Code project.
Added by 2012-02-19T10:48:47.000Z by [email protected].
Please review that bug for more context and additional comments, but update this bug.

Original labels: Type-Defect, Priority-Medium

Original description

What steps will reproduce the problem?

1. get the latest stk500v2 bootloader from https://github.com/arduino/Arduino-stk500v2-bootloader
2. Point your paths at the gcc tools included with Arduino, and try a "make mega2560"
3. Observe the size of the resulting image.

What is the expected output? What do you see instead?
In order to fit in the bootloader section, the image size needs to be less than 8192 bytes. Instead, it is over 9k!
A smaller image is produced if you compile under WINAVR_20100110.

Please use labels and text to provide additional information.
The compiler versions seems to make different decisions about when to inline functions. For minimal program size, it shouldn't be inlining functions at all (except for the most trivial.) -fno-inline-small-functions will stop this behavior and save space. Rather a lot of space; about 3kbytes when using gcc4.3.2

Diff attached.

This is Issue 535 moved from a Google Code project.
Added by 2011-05-07T17:10:42.000Z by [email protected].
Please review that bug for more context and additional comments, but update this bug.

Original labels: Type-Enhancement, Priority-Medium, Component-Core

Original description

These should be along the lines of the Processing equivalents, triggering the corresponding serialEvent() functions when the particular character or number of characters is read.

This is Issue 791 moved from a Google Code project.
Added by 2012-01-14T23:37:51.000Z by [email protected].
Please review that bug for more context and additional comments, but update this bug.

Original labels: Type-Enhancement, Priority-Medium

Original description

This is a code improvement request for the file twi.h.
When including twi.h in a cpp file it needs to be surrounded by extern "C" otherwise name mingling problems occur.
It would be better if twi.h used

#ifdef __cplusplus

extern "C" {
#endif

Why?
Developers start being confused and start using extern "C" for files that do not need it which may lead to lost time.
For instance wire.cpp contains:

extern "C" {
  #include <stdlib.h>
  #include <string.h>
  #include <inttypes.h>
  #include "twi.h"
}

only twi.h needs the extern "C"

Would this cause any incompatibilities with previous versions?
This will not cause any incompatibilities. I attached the modified twi.h which I tested in my environment.

This is Issue 486 moved from a Google Code project.
Added by 2011-02-26T20:06:51.000Z by [email protected].
Please review that bug for more context and additional comments, but update this bug.

Original labels: Type-Defect, Priority-Medium, Component-Core

Original description

From http://arduino.cc/forum/index.php/topic,53131.0.html:

"Hello..
there is a bug in twi.c which effectively disconnects TWI/I²C after an error in Slave Receiver mode.

The bug is in SIGNAL(TWI_vect) at case label TW_SR_DATA_NACK/TW_SR_GCALL_DATA_NACK

the wrong code is:
// nack back at master
twi_reply(0);

This should be:
twi_reply(1);

Explanation: See ATmegaxxx Documentation (doc8161.pdf) from Atmel. In Fig. 21-16 on page 236 the states $88 (TW_SR_DATA_NACK) and $98 (TW_SR_GCALL_DATA_NACK) are final states. There is nothing to "nack back at master". This has already been done! Unlike the $80 (TW_SR_DATA_ACK) and $90 (TW_SR_GCALL_DATA_ACK) states, there will be no $A0 state (TW_SR_STOP) to terminate. Table 21-4. on page 235 shows that if we now leave TWEA off, we will never be able again to be selected as receiver. Calling twi_reply(1) will set TWEA and thus allow further selection as slave."

This is Issue 750 moved from a Google Code project.
Added by 2011-12-14T20:35:06.000Z by [email protected].
Please review that bug for more context and additional comments, but update this bug.

Original labels: Type-Enhancement, Priority-Medium, Component-Examples

Original description

What change would like to see?

The SPI library examples should explain (and use) the pre-defined pin number constants MOSI, MISO, SCK, SS. Well, at least SS should be used on DigitalPotControl, instead of hard-coding pin 10.

Why?

Documenting and encouraging use of these constants will promote a coding style that makes sketches and liraries compatible with boards other than Uno.

Many sketches exist which will not work on Mega, and probably will not work on Due, Leonardo and other future boards, as well as 3rd party boards with different pinouts. Often authors will create their own #define statements for the SPI pins, because they are unaware that the core provides them automatically!

Would this cause any incompatibilities with previous versions? If so, how
can these be mitigated?

No incompatibilities. Long term, this change should greatly improve compatibility.

This is Issue 753 moved from a Google Code project.
Added by 2011-12-21T22:04:41.000Z by [email protected].
Please review that bug for more context and additional comments, but update this bug.

Original labels: Type-Enhancement, Priority-Medium, Component-IDE

Original description

What change would like to see?

Add the "-felide-constructors" flag to compilation of .cpp files.

Why?

This optimization is used by the string class.

Would this cause any incompatibilities with previous versions? If so, how
can these be mitigated?

To be investigated.

This is Issue 1096 moved from a Google Code project.
Added by 2012-11-04T20:44:19.000Z by [email protected].
Please review that bug for more context and additional comments, but update this bug.

Original labels: Type-Defect, Priority-Medium

Original description

The bootloader of Arduino Leonardo seems to not clear the USB interrupts before handing over to the main code.

To reproduce, create a minimal C-program like this:

int main(int argc, char* argv[])
{
    DDRC = 128;
    PORTC = 0;

    sei();

    while(1) {
        _delay_ms(100);
        PORTC = 128;
        _delay_ms(100);
        PORTC = 0;
    }

    return 0;
}

Compile and transmit using avr-gcc and avrdude.

The status LED should blink, but it doesn't. But if you remove the call to sei() it works as expected.

I've found that the USB interrupts are still enabled when main is entered, which causes an unimplemented interrupt handler to called. The workaround is to either implement the interrupt handler or disable USB interrupts before sei() is called.

This is Issue 868 moved from a Google Code project.
Added by 2012-03-29T13:10:59.000Z by [email protected].
Please review that bug for more context and additional comments, but update this bug.

Original labels: Type-Defect, Priority-High

Original description

We need a more informative error message for:

avrdude: stk500_getsync(): not in sync: resp=0x30

I get at least one request a week for what this means, from beginners. It's usually one of several things, but basically the fact that the Arduino isn't responding. We need a better error message for it.

What steps will reproduce the problem?

1. Not connecting the Arduino
2. Or a short circuit on the board
3. Or a damaged bootloader
4. Or many other things

What is the expected output?

"Your Arduino isn't responding. Check to see if it's connected, or if there is a short circuit on the board."

What do you see instead?

A line of terse, unfriendly programmer-speak:
avrdude: stk500_getsync(): not in sync: resp=0x30

This is Issue 510 moved from a Google Code project.
Added by 2011-03-23T05:33:55.000Z by [email protected].
Please review that bug for more context and additional comments, but update this bug.

Original labels: Type-Defect, Priority-Medium, Component-Core

Original description

What steps will reproduce the problem?
Use this code:

/*

Attach your interrupt signaling button to DPIN2
Attach you attachInterrupt button to DPIN13

Fire up the serial monitor:

The first number shows if the interrupt is currently attached.
The second number shows if the interrupt is in a signaled state, i.e. if it is prepared to fire off the ISR.
  Note that in normal operation, this interrupt ready flag is unset immediately upon call of the ISR.
The third number shows a count of the calls to isrSignal, within which it is incremented by 1.

Follow these steps:
Trigger your interrupt signaling button once. 
You will see that the interrupt is detached by (EIMSK & 0x1) being 0.
(EIFR & 1) will be 0, as the trigger flag is not seen at this point in the code: The interrupt triggers and the flag is cleared.
The count will be 1.

Trigger the interrupt signal button again. 
EIMSK & 1 will not change: The interrupt was already not attached.
EIFR & 1 will now be 1, because the interrupt flag signals regardless of whether an interrupt is attached.
The count will still be 1, as the ISR was not called due to the interrupt not being attached.

Now press your attachInterrupt button to cause the interrupt to be reattached.
EIMSK & 1 will be 1. The ISR is reattached.
EIFR & 1 will be 0: The flag has been cleared.
The count will be 2. This is wrong, it should be 1 as the ISR should only have been called 
  once: The first time the interrupt button was pressed. The second time the button was pressed,
  the interrupt was not attached, so the user does not expect intervening triggers of the interrupt
  to cause an immediate call to the ISR upon reattachment.

*/
# define INTERRUPT_SIGNAL_PIN 2
# define ATTACH_INTERRUPT_PIN 13

volatile boolean signaled = false;
volatile long signalCounter = 0;

void setup () {
  Serial.begin(115200);
  pinMode(INTERRUPT_SIGNAL_PIN,INPUT);
  pinMode(ATTACH_INTERRUPT_PIN,INPUT);
  attachInterrupt(0,isrSignal,RISING);
}

void loop () {
  if (digitalRead(ATTACH_INTERRUPT_PIN) == HIGH) {
    attachInterrupt(0,isrSignal,RISING);
  }
  Serial.print( EIMSK, BIN );
  Serial.print(' ');
  Serial.print( EIFR, BIN );
  Serial.print(' ');
  Serial.println( signalCounter );
}

void isrSignal () {
  detachInterrupt(0);
  signalCounter++;
  signaled = true;
}

What is the expected output? What do you see instead?
Explained in the comment in the code.

What version of the Arduino software are you using? On what operating
system? Which Arduino board are you using?
This issue is seen in version 0022 of the IDE on Windows XP using a Duemilanove. However, this issue has nothing to do with any of this: See below.

Please provide any additional information below.

The solution to this issue is to read the datasheet for certain Atmegas, for example the 1284P, which on page 69 says:

When changing the ISCn bit, an interrupt can occur. Therefore, it is recommended to first disable INTn by clearing its Interrupt Enable bit in the EIMSK Register. Then, the ISCn bit can be changed. Finally, the INTn interrupt flag should be cleared by writing a logical one to its Interrupt Flag bit (INTFn) in the EIFR Register before the interrupt is re-enabled.

This is in reference to attaching an interrupt and is in the EICRA subsection of the External Interrupts section.

The short version: The interrupt flag should be unset when an interrupt is attached, otherwise the ISR can be triggered immediately upon attachment.

The fix involves a modification to WInterrupts.c. Currently, there is a switch() full of #ifs, each condition containing a variation of the following two lines of code:

EICRA = (EICRA & ~((1 << ISC00) | (1 << ISC01))) | (mode << ISC00);
EIMSK |= (1 << INT0);

The first line sets EICRA, which determines under which interrupt triggers conditions an ISR will be triggered (RISING, FALLING, etc.). The second line activates the correct bit in EIMSK high, which enables the external interrupt pin.

The fix is the addition of two more lines of code:

EIMSK &= ~(1 << INT0); //Added
EICRA = (EICRA & ~((1 << ISC00) | (1 << ISC01))) | (mode << ISC00);
EIFR |= (1 << INTF0); //Added
EIMSK |= (1 << INT0);

The first added line makes sure that the external interrupt pin is disabled while changing the value of EICRA, as recommended in the datasheet. The second added line clears the interrupt triggered flag. It looks like the flag is being set by use of |=, but this is the correct method. See page 69: "Alternatively, the flag can be cleared by writing a logical one to it."

This fix is tested and fully working.

The first added line of code, which disables the external interrupt pin, is not required for this specific fix. However, it is recommended in the datasheet and seems to be able to help in certain fringe conditions.

This is Issue 628 moved from a Google Code project.
Added by 2011-09-06T21:02:07.000Z by [email protected].
Please review that bug for more context and additional comments, but update this bug.

Original labels: Type-Enhancement, Priority-Medium, Component-Core

Original description

Add #defines for RX and TX (and RX1, TX1, etc) so we know which pins are on the UART and used for communication with the computer.

This is Issue 1087 moved from a Google Code project.
Added by 2012-10-29T03:37:49.000Z by [email protected].
Please review that bug for more context and additional comments, but update this bug.

Original labels: Type-Defect, Priority-Medium

Original description

What steps will reproduce the problem?

1. create a speed setting for a programmer in the hardware/programmers.txt file
2. upload a sketch using the programmer
3. see that the speed is totally ignored for USB programmers

What is the expected output? What do you see instead?
apply the -b setting to Avrdude no matter if usb or serial programmers are used.

What version of the Arduino software are you using? 1.0.1
On what operating system? Mac
Which Arduino board are you using? Uno, NG, ProNano, custom

Please provide any additional information below.
Here is the source in AvrdudeUploader.java that shows the ignored -b parameter for USB based programmers:

private Collection getProgrammerCommands(Target target, String programmer) {
Map<String, String> programmerPreferences = target.getProgrammers().get(programmer);
List params = new ArrayList();
params.add("-c" + programmerPreferences.get("protocol"));

if ("usb".equals(programmerPreferences.get("communication"))) {
  params.add("-Pusb");
} else if ("serial".equals(programmerPreferences.get("communication"))) {
  params.add("-P" + (Base.isWindows() ? "\\\\.\\" : "") + Preferences.get("serial.port"));
  if (programmerPreferences.get("speed") != null) {
    params.add("-b" + Integer.parseInt(programmerPreferences.get("speed")));
  }
}