text:
How to reset Arduino Uno over BLE?
I'm working on wireless uploader for Arduino over BLE.
I've managed to make it working for Arduino Mega 2560 using GPIO and HM-10 AT commands to control GPIO pins. I'm using pretty the same schematics to perform reset just like for USB is done (wire GPIO to capacitor, resistor and MCU reset pin). The problem that it does work for Mega 2560 and it does not work for Uno.
Here is log file for Mega 2560:
2015-09-05 14:53:01.055 xctest[59735:7704704] [DEBUG  ] [   ]: BleSerialDevice: open()
2015-09-05 14:53:01.055 xctest[59735:7704704] [DEBUG  ] [   ]: Connecting to service=0xFFE0, rx=0xFFE1, tx=0xFFE1
2015-09-05 14:53:01.055 xctest[59735:7704704] [INFO   ] [   ]: Start discovering peripherals ...
2015-09-05 14:53:01.056 xctest[59735:7704704] [DEBUG  ] [   ]: Waiting for peripheral to be discovered ...
2015-09-05 14:53:01.326 xctest[59735:7704747] [INFO   ] [   ]: Found peripheral: <CBPeripheral: 0x100407e30 identifier = D92ECAAB-51A5-44D5-8C6C-536CD797867E, Name = "BleIos", state = disconnected>
2015-09-05 14:53:01.326 xctest[59735:7704747] [DEBUG  ] [   ]: Stop scanning
2015-09-05 14:53:01.326 xctest[59735:7704747] [INFO   ] [   ]: Connecting to <CBPeripheral: 0x100407e30 identifier = D92ECAAB-51A5-44D5-8C6C-536CD797867E, Name = "BleIos", state = disconnected>
2015-09-05 14:53:01.548 xctest[59735:7704747] [DEBUG  ] [   ]: Connected to peripheral <CBPeripheral: 0x100407e30 identifier = D92ECAAB-51A5-44D5-8C6C-536CD797867E, Name = "BleIos", state = connected>
2015-09-05 14:53:01.551 xctest[59735:7704747] [TRACE  ] [   ]: Discovered services for peripheral <CBPeripheral: 0x100407e30 identifier = D92ECAAB-51A5-44D5-8C6C-536CD797867E, Name = "BleIos", state = connected>
2015-09-05 14:53:01.551 xctest[59735:7704747] [DEBUG  ] [   ]: Discovered service <CBService: 0x10020d510>
2015-09-05 14:53:01.692 xctest[59735:7704747] [TRACE  ] [   ]: Discovered characteristics for service <CBService: 0x10020d510>
2015-09-05 14:53:01.693 xctest[59735:7704747] [TRACE  ] [   ]: Discovered characteristic <CBCharacteristic: 0x1001076a0>
2015-09-05 14:53:01.693 xctest[59735:7704747] [DEBUG  ] [   ]: Tx characteristic supports WriteWithResponse: NO
2015-09-05 14:53:01.693 xctest[59735:7704747] [TRACE  ] [   ]: Subscribing to Rx value
2015-09-05 14:53:01.704 xctest[59735:7704704] [INFO   ] [   ]: Connected successfully
2015-09-05 14:53:01.705 xctest[59735:7704704] [DEBUG  ] [   ]: WiringProtocol:open: releasing DTR/RTS
2015-09-05 14:53:01.705 xctest[59735:7704704] [TRACE  ] [   ]: Waiting until subscribed to Rx value ...
2015-09-05 14:53:02.932 xctest[59735:7704747] [DEBUG  ] [IN ]: Updated notifications state for RX characteristic: isNotifying=YES
2015-09-05 14:53:02.971 xctest[59735:7704704] [DEBUG  ] [OUT]: Sending 8 bytes
2015-09-05 14:53:02.972 xctest[59735:7704704] [TRACE  ] [OUT]: Send: A [0x41] T [0x54] + [0x2B] P [0x50] I [0x49] O [0x4F] 2 [0x32] 1 [0x31]
2015-09-05 14:53:02.972 xctest[59735:7704704] [TRACE  ] [OUT]: BLE sending bytes range from 0 length 8
2015-09-05 14:53:03.027 xctest[59735:7704704] [DEBUG  ] [   ]: WiringProtocol:open: asserting DTR/RTS
2015-09-05 14:53:03.027 xctest[59735:7704704] [DEBUG  ] [OUT]: Sending 8 bytes
2015-09-05 14:53:03.028 xctest[59735:7704704] [TRACE  ] [OUT]: Send: A [0x41] T [0x54] + [0x2B] P [0x50] I [0x49] O [0x4F] 2 [0x32] 0 [0x30]
2015-09-05 14:53:03.028 xctest[59735:7704704] [TRACE  ] [OUT]: BLE sending bytes range from 0 length 8
2015-09-05 14:53:03.083 xctest[59735:7704704] [DEBUG  ] [   ]: Draining for 300 ms ...
2015-09-05 14:53:03.083 xctest[59735:7704704] [TRACE  ] [IN ]: Start reading
2015-09-05 14:53:03.341 xctest[59735:7704746] [TRACE  ] [IN ]: Rx value received 9 bytes: O [0x4F] K [0x4B] + [0x2B] P [0x50] I [0x49] O [0x4F] 2 [0x32] : [0x3A] 1 [0x31]
2015-09-05 14:53:03.341 xctest[59735:7704747] [TRACE  ] [IN ]: Rx value received 9 bytes: O [0x4F] K [0x4B] + [0x2B] P [0x50] I [0x49] O [0x4F] 2 [0x32] : [0x3A] 0 [0x30]
2015-09-05 14:53:03.385 xctest[59735:7704704] [TRACE  ] [IN ]: Finish reading
2015-09-05 14:53:03.385 xctest[59735:7704704] [TRACE  ] [IN ]: Ble clear buffer
2015-09-05 14:53:03.385 xctest[59735:7704704] [DEBUG  ] [IN ]: Drained 18 bytes
2015-09-05 14:53:03.386 xctest[59735:7704704] [DEBUG  ] [OUT]: Sending 7 bytes
2015-09-05 14:53:03.386 xctest[59735:7704704] [TRACE  ] [OUT]: Send: . [0x1B] . [0x01] . [0x00] . [0x01] . [0x0E] . [0x01] . [0x14]
2015-09-05 14:53:03.386 xctest[59735:7704704] [TRACE  ] [OUT]: BLE sending bytes range from 0 length 7
2015-09-05 14:53:03.387 xctest[59735:7704704] [DEBUG  ] [IN ]: Reading 1 bytes ...
2015-09-05 14:53:03.387 xctest[59735:7704704] [TRACE  ] [IN ]: Start reading
2015-09-05 14:53:03.453 xctest[59735:7704747] [TRACE  ] [IN ]: Rx value received 1 bytes: . [0x00]
2015-09-05 14:53:03.453 xctest[59735:7704747] [TRACE  ] [IN ]: Ignoring single 0x00 char
2015-09-05 14:53:03.454 xctest[59735:7704746] [TRACE  ] [IN ]: Rx value received 17 bytes: . [0x1B] . [0x01] . [0x00] . [0x0B] . [0x0E] . [0x01] . [0x00] . [0x08] A [0x41] V [0x56] R [0x52] I [0x49] S [0x53] P [0x50] _ [0x5F] 2 [0x32] t [0x74]
2015-09-05 14:53:03.455 xctest[59735:7704704] [TRACE  ] [IN ]: Finish reading
2015-09-05 14:53:03.455 xctest[59735:7704704] [TRACE  ] [IN ]: Receive: . [0x1B]
2015-09-05 14:53:03.456 xctest[59735:7704704] [DEBUG  ] [IN ]: Read 1 bytes, actually received 17 bytes
2015-09-05 14:53:03.456 xctest[59735:7704704] [TRACE  ] [IN ]: 16 bytes in incoming buffer remaining for next receive
2015-09-05 14:53:03.456 xctest[59735:7704704] [DEBUG  ] [IN ]: Reading 1 bytes ...
2015-09-05 14:53:03.456 xctest[59735:7704704] [TRACE  ] [IN ]: Having current receive buffer: . [0x01] . [0x00] . [0x0B] . [0x0E] . [0x01] . [0x00] . [0x08] A [0x41] V [0x56] R [0x52]  ... +6 bytes
2015-09-05 14:53:03.457 xctest[59735:7704704] [TRACE  ] [IN ]: Start reading
2015-09-05 14:53:03.457 xctest[59735:7704704] [TRACE  ] [IN ]: Finish reading
2015-09-05 14:53:03.457 xctest[59735:7704704] [TRACE  ] [IN ]: Receive: . [0x01]
2015-09-05 14:53:03.457 xctest[59735:7704704] [DEBUG  ] [IN ]: Read 1 bytes, actually received 16 bytes
2015-09-05 14:53:03.458 xctest[59735:7704704] [TRACE  ] [IN ]: 15 bytes in incoming buffer remaining for next receive
2015-09-05 14:53:03.458 xctest[59735:7704704] [DEBUG  ] [IN ]: Reading 1 bytes ...
2015-09-05 14:53:03.458 xctest[59735:7704704] [TRACE  ] [IN ]: Having current receive buffer: . [0x00] . [0x0B] . [0x0E] . [0x01] . [0x00] . [0x08] A [0x41] V [0x56] R [0x52] I [0x49]  ... +5 bytes
2015-09-05 14:53:03.459 xctest[59735:7704704] [TRACE  ] [IN ]: Start reading
2015-09-05 14:53:03.459 xctest[59735:7704704] [TRACE  ] [IN ]: Finish reading
2015-09-05 14:53:03.459 xctest[59735:7704704] [TRACE  ] [IN ]: Receive: . [0x00]
2015-09-05 14:53:03.459 xctest[59735:7704704] [DEBUG  ] [IN ]: Read 1 bytes, actually received 15 bytes
2015-09-05 14:53:03.460 xctest[59735:7704704] [TRACE  ] [IN ]: 14 bytes in incoming buffer remaining for next receive
2015-09-05 14:53:03.460 xctest[59735:7704704] [DEBUG  ] [IN ]: Reading 1 bytes ...
2015-09-05 14:53:03.460 xctest[59735:7704704] [TRACE  ] [IN ]: Having current receive buffer: . [0x0B] . [0x0E] . [0x01] . [0x00] . [0x08] A [0x41] V [0x56] R [0x52] I [0x49] S [0x53]  ... +4 bytes
2015-09-05 14:53:03.460 xctest[59735:7704704] [TRACE  ] [IN ]: Start reading
2015-09-05 14:53:03.461 xctest[59735:7704704] [TRACE  ] [IN ]: Finish reading
2015-09-05 14:53:03.461 xctest[59735:7704704] [TRACE  ] [IN ]: Receive: . [0x0B]
2015-09-05 14:53:03.461 xctest[59735:7704704] [DEBUG  ] [IN ]: Read 1 bytes, actually received 14 bytes
2015-09-05 14:53:03.461 xctest[59735:7704704] [TRACE  ] [IN ]: 13 bytes in incoming buffer remaining for next receive
2015-09-05 14:53:03.462 xctest[59735:7704704] [DEBUG  ] [IN ]: Reading 1 bytes ...
2015-09-05 14:53:03.462 xctest[59735:7704704] [TRACE  ] [IN ]: Having current receive buffer: . [0x0E] . [0x01] . [0x00] . [0x08] A [0x41] V [0x56] R [0x52] I [0x49] S [0x53] P [0x50]  ... +3 bytes
2015-09-05 14:53:03.462 xctest[59735:7704704] [TRACE  ] [IN ]: Start reading
2015-09-05 14:53:03.462 xctest[59735:7704704] [TRACE  ] [IN ]: Finish reading
2015-09-05 14:53:03.462 xctest[59735:7704704] [TRACE  ] [IN ]: Receive: . [0x0E]
2015-09-05 14:53:03.463 xctest[59735:7704704] [DEBUG  ] [IN ]: Read 1 bytes, actually received 13 bytes
2015-09-05 14:53:03.463 xctest[59735:7704704] [TRACE  ] [IN ]: 12 bytes in incoming buffer remaining for next receive
2015-09-05 14:53:03.463 xctest[59735:7704704] [DEBUG  ] [IN ]: Reading 1 bytes ...
2015-09-05 14:53:03.463 xctest[59735:7704704] [TRACE  ] [IN ]: Having current receive buffer: . [0x01] . [0x00] . [0x08] A [0x41] V [0x56] R [0x52] I [0x49] S [0x53] P [0x50] _ [0x5F]  ... +2 bytes
2015-09-05 14:53:03.463 xctest[59735:7704704] [TRACE  ] [IN ]: Start reading
2015-09-05 14:53:03.463 xctest[59735:7704704] [TRACE  ] [IN ]: Finish reading
2015-09-05 14:53:03.464 xctest[59735:7704704] [TRACE  ] [IN ]: Receive: . [0x01]
2015-09-05 14:53:03.464 xctest[59735:7704704] [DEBUG  ] [IN ]: Read 1 bytes, actually received 12 bytes
2015-09-05 14:53:03.464 xctest[59735:7704704] [TRACE  ] [IN ]: 11 bytes in incoming buffer remaining for next receive
2015-09-05 14:53:03.464 xctest[59735:7704704] [DEBUG  ] [IN ]: Reading 1 bytes ...
2015-09-05 14:53:03.464 xctest[59735:7704704] [TRACE  ] [IN ]: Having current receive buffer: . [0x00] . [0x08] A [0x41] V [0x56] R [0x52] I [0x49] S [0x53] P [0x50] _ [0x5F] 2 [0x32]  ... +1 bytes
2015-09-05 14:53:03.465 xctest[59735:7704704] [TRACE  ] [IN ]: Start reading
2015-09-05 14:53:03.465 xctest[59735:7704704] [TRACE  ] [IN ]: Finish reading
2015-09-05 14:53:03.465 xctest[59735:7704704] [TRACE  ] [IN ]: Receive: . [0x00]
2015-09-05 14:53:03.465 xctest[59735:7704704] [DEBUG  ] [IN ]: Read 1 bytes, actually received 11 bytes
2015-09-05 14:53:03.465 xctest[59735:7704704] [TRACE  ] [IN ]: 10 bytes in incoming buffer remaining for next receive
2015-09-05 14:53:03.466 xctest[59735:7704704] [DEBUG  ] [IN ]: Reading 1 bytes ...
2015-09-05 14:53:03.466 xctest[59735:7704704] [TRACE  ] [IN ]: Having current receive buffer: . [0x08] A [0x41] V [0x56] R [0x52] I [0x49] S [0x53] P [0x50] _ [0x5F] 2 [0x32] t [0x74]
2015-09-05 14:53:03.466 xctest[59735:7704704] [TRACE  ] [IN ]: Start reading
2015-09-05 14:53:03.466 xctest[59735:7704704] [TRACE  ] [IN ]: Finish reading
2015-09-05 14:53:03.466 xctest[59735:7704704] [TRACE  ] [IN ]: Receive: . [0x08]
2015-09-05 14:53:03.466 xctest[59735:7704704] [DEBUG  ] [IN ]: Read 1 bytes, actually received 10 bytes
2015-09-05 14:53:03.467 xctest[59735:7704704] [TRACE  ] [IN ]: 9 bytes in incoming buffer remaining for next receive
2015-09-05 14:53:03.467 xctest[59735:7704704] [DEBUG  ] [IN ]: Reading 1 bytes ...
2015-09-05 14:53:03.467 xctest[59735:7704704] [TRACE  ] [IN ]: Having current receive buffer: A [0x41] V [0x56] R [0x52] I [0x49] S [0x53] P [0x50] _ [0x5F] 2 [0x32] t [0x74]
2015-09-05 14:53:03.467 xctest[59735:7704704] [TRACE  ] [IN ]: Start reading
2015-09-05 14:53:03.467 xctest[59735:7704704] [TRACE  ] [IN ]: Finish reading
2015-09-05 14:53:03.468 xctest[59735:7704704] [TRACE  ] [IN ]: Receive: A [0x41]
2015-09-05 14:53:03.468 xctest[59735:7704704] [DEBUG  ] [IN ]: Read 1 bytes, actually received 9 bytes
2015-09-05 14:53:03.468 xctest[59735:7704704] [TRACE  ] [IN ]: 8 bytes in incoming buffer remaining for next receive
2015-09-05 14:53:03.468 xctest[59735:7704704] [DEBUG  ] [IN ]: Reading 1 bytes ...
2015-09-05 14:53:03.468 xctest[59735:7704704] [TRACE  ] [IN ]: Having current receive buffer: V [0x56] R [0x52] I [0x49] S [0x53] P [0x50] _ [0x5F] 2 [0x32] t [0x74]
2015-09-05 14:53:03.469 xctest[59735:7704704] [TRACE  ] [IN ]: Start reading
2015-09-05 14:53:03.469 xctest[59735:7704704] [TRACE  ] [IN ]: Finish reading
2015-09-05 14:53:03.469 xctest[59735:7704704] [TRACE  ] [IN ]: Receive: V [0x56]
2015-09-05 14:53:03.469 xctest[59735:7704704] [DEBUG  ] [IN ]: Read 1 bytes, actually received 8 bytes
2015-09-05 14:53:03.469 xctest[59735:7704704] [TRACE  ] [IN ]: 7 bytes in incoming buffer remaining for next receive
2015-09-05 14:53:03.469 xctest[59735:7704704] [DEBUG  ] [IN ]: Reading 1 bytes ...
2015-09-05 14:53:03.470 xctest[59735:7704704] [TRACE  ] [IN ]: Having current receive buffer: R [0x52] I [0x49] S [0x53] P [0x50] _ [0x5F] 2 [0x32] t [0x74]
2015-09-05 14:53:03.470 xctest[59735:7704704] [TRACE  ] [IN ]: Start reading
2015-09-05 14:53:03.470 xctest[59735:7704704] [TRACE  ] [IN ]: Finish reading
2015-09-05 14:53:03.470 xctest[59735:7704704] [TRACE  ] [IN ]: Receive: R [0x52]
2015-09-05 14:53:03.470 xctest[59735:7704704] [DEBUG  ] [IN ]: Read 1 bytes, actually received 7 bytes
2015-09-05 14:53:03.471 xctest[59735:7704704] [TRACE  ] [IN ]: 6 bytes in incoming buffer remaining for next receive
2015-09-05 14:53:03.471 xctest[59735:7704704] [DEBUG  ] [IN ]: Reading 1 bytes ...
2015-09-05 14:53:03.471 xctest[59735:7704704] [TRACE  ] [IN ]: Having current receive buffer: I [0x49] S [0x53] P [0x50] _ [0x5F] 2 [0x32] t [0x74]
2015-09-05 14:53:03.471 xctest[59735:7704704] [TRACE  ] [IN ]: Start reading
2015-09-05 14:53:03.471 xctest[59735:7704704] [TRACE  ] [IN ]: Finish reading
2015-09-05 14:53:03.472 xctest[59735:7704704] [TRACE  ] [IN ]: Receive: I [0x49]
2015-09-05 14:53:03.472 xctest[59735:7704704] [DEBUG  ] [IN ]: Read 1 bytes, actually received 6 bytes
2015-09-05 14:53:03.472 xctest[59735:7704704] [TRACE  ] [IN ]: 5 bytes in incoming buffer remaining for next receive
2015-09-05 14:53:03.472 xctest[59735:7704704] [DEBUG  ] [IN ]: Reading 1 bytes ...
2015-09-05 14:53:03.472 xctest[59735:7704704] [TRACE  ] [IN ]: Having current receive buffer: S [0x53] P [0x50] _ [0x5F] 2 [0x32] t [0x74]
2015-09-05 14:53:03.472 xctest[59735:7704704] [TRACE  ] [IN ]: Start reading
2015-09-05 14:53:03.473 xctest[59735:7704704] [TRACE  ] [IN ]: Finish reading
2015-09-05 14:53:03.473 xctest[59735:7704704] [TRACE  ] [IN ]: Receive: S [0x53]
2015-09-05 14:53:03.473 xctest[59735:7704704] [DEBUG  ] [IN ]: Read 1 bytes, actually received 5 bytes
2015-09-05 14:53:03.473 xctest[59735:7704704] [TRACE  ] [IN ]: 4 bytes in incoming buffer remaining for next receive
2015-09-05 14:53:03.473 xctest[59735:7704704] [DEBUG  ] [IN ]: Reading 1 bytes ...
2015-09-05 14:53:03.474 xctest[59735:7704704] [TRACE  ] [IN ]: Having current receive buffer: P [0x50] _ [0x5F] 2 [0x32] t [0x74]
2015-09-05 14:53:03.474 xctest[59735:7704704] [TRACE  ] [IN ]: Start reading
2015-09-05 14:53:03.474 xctest[59735:7704704] [TRACE  ] [IN ]: Finish reading
2015-09-05 14:53:03.474 xctest[59735:7704704] [TRACE  ] [IN ]: Receive: P [0x50]
2015-09-05 14:53:03.474 xctest[59735:7704704] [DEBUG  ] [IN ]: Read 1 bytes, actually received 4 bytes
2015-09-05 14:53:03.474 xctest[59735:7704704] [TRACE  ] [IN ]: 3 bytes in incoming buffer remaining for next receive
2015-09-05 14:53:03.475 xctest[59735:7704704] [DEBUG  ] [IN ]: Reading 1 bytes ...
2015-09-05 14:53:03.475 xctest[59735:7704704] [TRACE  ] [IN ]: Having current receive buffer: _ [0x5F] 2 [0x32] t [0x74]
2015-09-05 14:53:03.475 xctest[59735:7704704] [TRACE  ] [IN ]: Start reading
2015-09-05 14:53:03.475 xctest[59735:7704704] [TRACE  ] [IN ]: Finish reading
2015-09-05 14:53:03.475 xctest[59735:7704704] [TRACE  ] [IN ]: Receive: _ [0x5F]
2015-09-05 14:53:03.476 xctest[59735:7704704] [DEBUG  ] [IN ]: Read 1 bytes, actually received 3 bytes
2015-09-05 14:53:03.476 xctest[59735:7704704] [TRACE  ] [IN ]: 2 bytes in incoming buffer remaining for next receive
2015-09-05 14:53:03.476 xctest[59735:7704704] [DEBUG  ] [IN ]: Reading 1 bytes ...
2015-09-05 14:53:03.476 xctest[59735:7704704] [TRACE  ] [IN ]: Having current receive buffer: 2 [0x32] t [0x74]
2015-09-05 14:53:03.476 xctest[59735:7704704] [TRACE  ] [IN ]: Start reading
2015-09-05 14:53:03.477 xctest[59735:7704704] [TRACE  ] [IN ]: Finish reading
2015-09-05 14:53:03.477 xctest[59735:7704704] [TRACE  ] [IN ]: Receive: 2 [0x32]
2015-09-05 14:53:03.477 xctest[59735:7704704] [DEBUG  ] [IN ]: Read 1 bytes, actually received 2 bytes
2015-09-05 14:53:03.477 xctest[59735:7704704] [TRACE  ] [IN ]: 1 bytes in incoming buffer remaining for next receive
2015-09-05 14:53:03.477 xctest[59735:7704704] [DEBUG  ] [IN ]: Reading 1 bytes ...
2015-09-05 14:53:03.477 xctest[59735:7704704] [TRACE  ] [IN ]: Having current receive buffer: t [0x74]
2015-09-05 14:53:03.478 xctest[59735:7704704] [TRACE  ] [IN ]: Start reading
2015-09-05 14:53:03.478 xctest[59735:7704704] [TRACE  ] [IN ]: Finish reading
2015-09-05 14:53:03.478 xctest[59735:7704704] [TRACE  ] [IN ]: Receive: t [0x74]
2015-09-05 14:53:03.478 xctest[59735:7704704] [DEBUG  ] [IN ]: Read 1 bytes, actually received 1 bytes
2015-09-05 14:53:03.478 xctest[59735:7704704] [TRACE  ] [IN ]: Ble clear buffer
2015-09-05 14:53:03.479 xctest[59735:7704704] [DEBUG  ] [   ]: Found programmer: 'PGMTYPE_AVRISP'

Here is Uno log file:
2015-09-05 15:51:34.667 xctest[60180:7754033] [DEBUG  ] [   ]: BleSerialDevice: open()
2015-09-05 15:51:34.667 xctest[60180:7754033] [DEBUG  ] [   ]: Connecting to service=0xFFE0, rx=0xFFE1, tx=0xFFE1
2015-09-05 15:51:34.667 xctest[60180:7754033] [INFO   ] [   ]: Start discovering peripherals ...
2015-09-05 15:51:34.668 xctest[60180:7754033] [DEBUG  ] [   ]: Waiting for peripheral to be discovered ...
2015-09-05 15:51:35.411 xctest[60180:7754082] [INFO   ] [   ]: Found peripheral: <CBPeripheral: 0x1003335d0 identifier = D92ECAAB-51A5-44D5-8C6C-536CD797867E, Name = "BleIos", state = disconnected>
2015-09-05 15:51:35.412 xctest[60180:7754082] [DEBUG  ] [   ]: Stop scanning
2015-09-05 15:51:35.412 xctest[60180:7754082] [INFO   ] [   ]: Connecting to <CBPeripheral: 0x1003335d0 identifier = D92ECAAB-51A5-44D5-8C6C-536CD797867E, Name = "BleIos", state = disconnected>
2015-09-05 15:51:35.676 xctest[60180:7754084] [DEBUG  ] [   ]: Connected to peripheral <CBPeripheral: 0x1003335d0 identifier = D92ECAAB-51A5-44D5-8C6C-536CD797867E, Name = "BleIos", state = connected>
2015-09-05 15:51:35.678 xctest[60180:7754084] [TRACE  ] [   ]: Discovered services for peripheral <CBPeripheral: 0x1003335d0 identifier = D92ECAAB-51A5-44D5-8C6C-536CD797867E, Name = "BleIos", state = connected>
2015-09-05 15:51:35.678 xctest[60180:7754084] [DEBUG  ] [   ]: Discovered service <CBService: 0x10011fff0>
2015-09-05 15:51:35.836 xctest[60180:7754084] [TRACE  ] [   ]: Discovered characteristics for service <CBService: 0x10011fff0>
2015-09-05 15:51:35.836 xctest[60180:7754084] [TRACE  ] [   ]: Discovered characteristic <CBCharacteristic: 0x10040b8f0>
2015-09-05 15:51:35.836 xctest[60180:7754084] [DEBUG  ] [   ]: Tx characteristic supports WriteWithResponse: NO
2015-09-05 15:51:35.837 xctest[60180:7754084] [TRACE  ] [   ]: Subscribing to Rx value
2015-09-05 15:51:35.846 xctest[60180:7754033] [INFO   ] [   ]: Connected successfully
2015-09-05 15:51:35.846 xctest[60180:7754033] [TRACE  ] [   ]: DTR/RTS supported by Serial, resetting
2015-09-05 15:51:35.846 xctest[60180:7754033] [TRACE  ] [   ]: Waiting until subscribed to Rx value ...
2015-09-05 15:51:36.655 xctest[60180:7754082] [DEBUG  ] [IN ]: Updated notifications state for RX characteristic: isNotifying=YES
2015-09-05 15:51:36.682 xctest[60180:7754033] [DEBUG  ] [OUT]: Sending 8 bytes
2015-09-05 15:51:36.682 xctest[60180:7754033] [TRACE  ] [OUT]: Send: A [0x41] T [0x54] + [0x2B] P [0x50] I [0x49] O [0x4F] 2 [0x32] 1 [0x31]
2015-09-05 15:51:36.682 xctest[60180:7754033] [TRACE  ] [OUT]: BLE sending bytes range from 0 length 8
2015-09-05 15:51:36.735 xctest[60180:7754033] [DEBUG  ] [OUT]: Sending 8 bytes
2015-09-05 15:51:36.736 xctest[60180:7754033] [TRACE  ] [OUT]: Send: A [0x41] T [0x54] + [0x2B] P [0x50] I [0x49] O [0x4F] 2 [0x32] 0 [0x30]
2015-09-05 15:51:36.736 xctest[60180:7754033] [TRACE  ] [OUT]: BLE sending bytes range from 0 length 8
2015-09-05 15:51:36.788 xctest[60180:7754033] [DEBUG  ] [   ]: Draining for 300 ms ...
2015-09-05 15:51:36.788 xctest[60180:7754033] [TRACE  ] [IN ]: Start reading
2015-09-05 15:51:37.053 xctest[60180:7754082] [TRACE  ] [IN ]: Rx value received 9 bytes: O [0x4F] K [0x4B] + [0x2B] P [0x50] I [0x49] O [0x4F] 2 [0x32] : [0x3A] 1 [0x31]
2015-09-05 15:51:37.053 xctest[60180:7754082] [TRACE  ] [IN ]: Rx value received 9 bytes: O [0x4F] K [0x4B] + [0x2B] P [0x50] I [0x49] O [0x4F] 2 [0x32] : [0x3A] 0 [0x30]
2015-09-05 15:51:37.093 xctest[60180:7754033] [TRACE  ] [IN ]: Finish reading
2015-09-05 15:51:37.093 xctest[60180:7754033] [TRACE  ] [IN ]: Ble clear buffer
2015-09-05 15:51:37.093 xctest[60180:7754033] [DEBUG  ] [IN ]: Drained 18 bytes
2015-09-05 15:51:37.094 xctest[60180:7754033] [DEBUG  ] [OUT]: Sending 2 bytes
2015-09-05 15:51:37.094 xctest[60180:7754033] [TRACE  ] [OUT]: Send: 0 [0x30]   [0x20]
2015-09-05 15:51:37.094 xctest[60180:7754033] [TRACE  ] [OUT]: BLE sending bytes range from 0 length 2
2015-09-05 15:51:37.095 xctest[60180:7754033] [DEBUG  ] [IN ]: Reading 1 bytes ...
2015-09-05 15:51:37.096 xctest[60180:7754033] [TRACE  ] [IN ]: Start reading
2015-09-05 15:51:37.450 xctest[60180:7754084] [TRACE  ] [IN ]: Rx value received 1 bytes: . [0x00]
2015-09-05 15:51:37.450 xctest[60180:7754084] [TRACE  ] [IN ]: Ignoring single 0x00 char
2015-09-05 15:51:37.450 xctest[60180:7754084] [TRACE  ] [IN ]: Rx value received 2 bytes: . [0x14] . [0x10]
2015-09-05 15:51:37.452 xctest[60180:7754033] [TRACE  ] [IN ]: Finish reading
2015-09-05 15:51:37.452 xctest[60180:7754033] [TRACE  ] [IN ]: Receive: . [0x14]
2015-09-05 15:51:37.452 xctest[60180:7754033] [DEBUG  ] [IN ]: Read 1 bytes, actually received 2 bytes
2015-09-05 15:51:37.453 xctest[60180:7754033] [TRACE  ] [IN ]: 1 bytes in incoming buffer remaining for next receive
2015-09-05 15:51:37.453 xctest[60180:7754033] [DEBUG  ] [IN ]: Reading 1 bytes ...
2015-09-05 15:51:37.454 xctest[60180:7754033] [TRACE  ] [IN ]: Having current receive buffer: . [0x10]
2015-09-05 15:51:37.454 xctest[60180:7754033] [TRACE  ] [IN ]: Start reading
2015-09-05 15:51:37.454 xctest[60180:7754033] [TRACE  ] [IN ]: Finish reading
2015-09-05 15:51:37.455 xctest[60180:7754033] [TRACE  ] [IN ]: Receive: . [0x10]
2015-09-05 15:51:37.455 xctest[60180:7754033] [DEBUG  ] [IN ]: Read 1 bytes, actually received 1 bytes
2015-09-05 15:51:37.455 xctest[60180:7754033] [TRACE  ] [IN ]: Ble clear buffer
2015-09-05 15:51:37.455 xctest[60180:7754033] [DEBUG  ] [OUT]: Sending 3 bytes
2015-09-05 15:51:37.456 xctest[60180:7754033] [TRACE  ] [OUT]: Send: A [0x41] . [0x81]   [0x20]
2015-09-05 15:51:37.456 xctest[60180:7754033] [TRACE  ] [OUT]: BLE sending bytes range from 0 length 3
2015-09-05 15:51:37.457 xctest[60180:7754033] [DEBUG  ] [IN ]: Reading 1 bytes ...
2015-09-05 15:51:37.457 xctest[60180:7754033] [TRACE  ] [IN ]: Start reading
2015-09-05 15:51:37.701 xctest[60180:7754084] [TRACE  ] [IN ]: Rx value received 1 bytes: . [0x00]
2015-09-05 15:51:37.701 xctest[60180:7754084] [TRACE  ] [IN ]: Ignoring single 0x00 char
2015-09-05 15:51:38.451 xctest[60180:7754082] [TRACE  ] [IN ]: Rx value received 5 bytes: h [0x68] e [0x65] l [0x6C] l [0x6C] o [0x6F]

Here is arduino sketch used for Uno:
void setup() {
  // put your setup code here, to run once:
  Serial.begin(115200);
  Serial.print("hello");

  pinMode(13, OUTPUT);
  digitalWrite(13, LOW);
}

void loop() {
  // put your main code here, to run repeatedly:

}

You can see Uno's bootloader skips waiting for upload commands and goes right to sketch (see 'hello' in incoming buffer).
Is it Uno's bootloader feature? Can i walkaround it by wiring GPIO directly to USB's DTR?
Update: can i wire HM-10 GPIO directly to pin 13 of USB's ATmega's (see schematics) to make HM's GPIO act exactly like USB's DTR?
Update2:
if uploading to Uno over USB if goes further after Send: A [0x41] . [0x81]   [0x20]:
2015-09-06 15:47:10.452 xctest[1042:33659] [TRACE  ] [OUT]: Send: 0 [0x30]   [0x20]
2015-09-06 15:47:10.453 xctest[1042:33659] [DEBUG  ] [IN ]: Receiving 1 bytes
2015-09-06 15:47:10.592 xctest[1042:33659] [TRACE  ] [IN ]: Received: . [0x14]
2015-09-06 15:47:10.592 xctest[1042:33659] [DEBUG  ] [IN ]: Receiving 1 bytes
2015-09-06 15:47:10.592 xctest[1042:33659] [TRACE  ] [IN ]: Received: . [0x10]
2015-09-06 15:47:10.592 xctest[1042:33659] [DEBUG  ] [OUT]: Sending 3 bytes
2015-09-06 15:47:10.592 xctest[1042:33659] [TRACE  ] [OUT]: Send: A [0x41] . [0x81]   [0x20]
2015-09-06 15:47:10.592 xctest[1042:33659] [DEBUG  ] [IN ]: Receiving 1 bytes
2015-09-06 15:47:10.596 xctest[1042:33659] [TRACE  ] [IN ]: Received: . [0x14]
2015-09-06 15:47:10.596 xctest[1042:33659] [DEBUG  ] [IN ]: Receiving 1 bytes
2015-09-06 15:47:10.596 xctest[1042:33659] [TRACE  ] [IN ]: Received: . [0x04]
2015-09-06 15:47:10.596 xctest[1042:33659] [DEBUG  ] [IN ]: Receiving 1 bytes
2015-09-06 15:47:10.596 xctest[1042:33659] [TRACE  ] [IN ]: Received: . [0x10]
2015-09-06 15:47:10.597 xctest[1042:33659] [DEBUG  ] [OUT]: Sending 3 bytes
2015-09-06 15:47:10.597 xctest[1042:33659] [TRACE  ] [OUT]: Send: A [0x41] . [0x82]   [0x20]
2015-09-06 15:47:10.597 xctest[1042:33659] [DEBUG  ] [IN ]: Receiving 1 bytes
2015-09-06 15:47:10.600 xctest[1042:33659] [TRACE  ] [IN ]: Received: . [0x14]
2015-09-06 15:47:10.600 xctest[1042:33659] [DEBUG  ] [IN ]: Receiving 1 bytes
2015-09-06 15:47:10.601 xctest[1042:33659] [TRACE  ] [IN ]: Received: . [0x04]
2015-09-06 15:47:10.601 xctest[1042:33659] [DEBUG  ] [IN ]: Receiving 1 bytes
2015-09-06 15:47:10.601 xctest[1042:33659] [TRACE  ] [IN ]: Received: . [0x10]
2015-09-06 15:47:10.601 xctest[1042:33659] [DEBUG  ] [   ]: STK500:initialize: n_extparms = 4
2015-09-06 15:47:10.601 xctest[1042:33659] [DEBUG  ] [OUT]: Sending 22 bytes
2015-09-06 15:47:10.601 xctest[1042:33659] [TRACE  ] [OUT]: Send: B [0x42] . [0x86] . [0x00] . [0x01] . [0x00] . [0x01] . [0x01] . [0x01] . [0x03] . [0xFF] . [0xFF] . [0xFF] . [0xFF] . [0x00] . [0x80] . [0x04] . [0x00] . [0x00] . [0x00] . [0x80] . [0x00]   [0x20]
2015-09-06 15:47:10.602 xctest[1042:33659] [DEBUG  ] [IN ]: Receiving 1 bytes
2015-09-06 15:47:10.604 xctest[1042:33659] [TRACE  ] [IN ]: Received: . [0x14]
2015-09-06 15:47:10.604 xctest[1042:33659] [DEBUG  ] [IN ]: Receiving 1 bytes
2015-09-06 15:47:10.605 xctest[1042:33659] [TRACE  ] [IN ]: Received: . [0x10]
2015-09-06 15:47:10.616 xctest[1042:33659] [DEBUG  ] [OUT]: Sending 7 bytes
2015-09-06 15:47:10.617 xctest[1042:33659] [TRACE  ] [OUT]: Send: E [0x45] . [0x05] . [0x04] . [0xD7] . [0xC2] . [0x00]   [0x20]
2015-09-06 15:47:10.617 xctest[1042:33659] [DEBUG  ] [IN ]: Receiving 1 bytes
2015-09-06 15:47:10.621 xctest[1042:33659] [TRACE  ] [IN ]: Received: . [0x14]
2015-09-06 15:47:10.621 xctest[1042:33659] [DEBUG  ] [IN ]: Receiving 1 bytes
2015-09-06 15:47:10.621 xctest[1042:33659] [TRACE  ] [IN ]: Received: . [0x10]
2015-09-06 15:47:10.621 xctest[1042:33659] [DEBUG  ] [OUT]: Sending 2 bytes
2015-09-06 15:47:10.622 xctest[1042:33659] [TRACE  ] [OUT]: Send: P [0x50]   [0x20]


text:
avrdude: ser_open(): can't open device "\\.\COM3"?
My computer cannot detect my Arduino Uno anymore,

Reset button- > L led light blinks and it turns on forever
Arduino 1.6.5: Tools->Port (greyed out) I remembered that previously it wasn't like this
Unable to upload any sketch codes into the Uno anymore
The existing code uploaded onto the Uno is FastLED(FirstLight) and it will work on my LEDs when I plugged them in

I have tried to .... but none fix my issue

Restart my computer
Press the reset button on the Uno
Using the device mananger to change COM ports
Device manager -> Other devices -> (nothing about Arduino Uno is found here)
Plugged Uno into another computer but still doesn't work
Reinstalled IDE

Problem shown in sketch,

avrdude: ser_open(): can't open device "\.\COM3": The system cannot find the file specified.
Problem uploading to board.  See http://www.arduino.cc/en/Guide/Troubleshooting#upload for suggestions.

Try to install the ardunio driver again. Connect your arduino to another pc & see if it is working or not.? or maybe try connecting any other serial device to your pc and check if it shows any com ports or not.?

I'm voting to close this question as off-topic because it has been abandoned for two years without any followup that could make it answerable ever being provided, and it has started to attract low quality responses.

I have experienced a similar issue after plugging in another Arduino device. I didn't set up my environment for a long time and thus forgot he iterates the COM-Index. Maybe this is too easy, but you didn't provide much information.
This solved my problem:
Open Arduino application > Tools > Port > Change to the target Port
If you are unsure which port to choose from: (on Windows)
Open Device Manager > Connections (COM & LPT) > Usb Serial Port (COM[x])
where "[x]" is the index you are looking for.

This is dangerously close to an "I'm having this problem too" response.  Changing the port seems unlikely to be a solution, since having the port menu greyed out suggests there are no valid choices there to choose.  The problem here would appear to be far more fundamental - an electrical fault, bad cable, or bad driver.

Try a different arduino w/ your first computer, see if that will work.

source: Stack Exchange

license: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/3.0/

sort: votes


text:
Arduino microphone
I have an arduino schematic from here
http://www.arduino-hacks.com/arduino-vu-meter-lm386electret-microphone-condenser/
I have a problem, the output of the circuit (the pin which is going to connect to the analog pin of the Arduino), from what I have measured has 4.5 V (I think it is a bit high). If I print on the serial it gives me something like 827, 826. However when I clap my hands near the microphone or put music on, the data that I get doesn't change a lot (like 1 -2 units). Should I worry about the schematic or about my microphone?
EDIT:
  After I rebuilt the circuit and when playing a song at a medium volume, I get values like this: 419-670. I think it is working, though I would like more opinions about these values (the output voltage is now around 3.20 V).

Have you tweaked the potentiometer?

yes I have tweaked the potentiometer.Now after I rebuilt the circuit(correctly hopefully) it shows an output of aprox .3 20 V and the values I get on the Serial monitor varies like this (when playing a song on a medium volume): 419 -656 .I think I got it working though I would like more opinions regarding these values.Thank you for your reply I will edit the post.

The schematic seems to have both inputs of the opamp at 0V (the one connected to the microphone would actually swing a small amount ±). The opamp also seems to be running open loop, with no feedback and would have a very high gain.
This is poor circuit design, ideally the inputs should be biassed at Vcc/2. At best the output would be severely distorted.
I suggest you search for a more suitable circuit.

Actually, the LM386 is an audio amplifier, not an op-amp.  It doesn't behave the same way.  It is perfectly valid to wire it as shown in the link above - indeed, that is pretty much identical to some of the example circuits in the datasheet from TI.  With minimum parts like that you get a gain of 20.

What I would be more concerned about is the lack of any current limiting resistors on the LEDs... Those poor IO pins...

all_licenses: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/3.0/


text:
Drive 12V Piezo Buzzer (Arduino)
I want to drive this 12V piezo buzzer:
http://www.conrad.com/ce/en/product/130256/Kemo-L001-High-Freqeuncy-Piezo-Speaker-Component-12-24-V
This is the circuit I am using.

The Arduino is powered by a 12V DC adapter trough the DC IN jack.
I have tested the following code:
void setup() {
}

void loop() {
  int pinOut = 9;
  int freq = 10;
  int duration = 100;
  while(1)
  {
    for(int i=0; i<1000 ; i++)
    {
      tone(pinOut, freq*i, duration);
      delay(duration * 1);
      noTone(pinOut);
    }
  }
}

When run I can hear the tones changing but is really really low. I have measured the voltage between buzzer pins and it is 12V (as expected) so the MOSFET seems to be properly working.
This piezo buzzer should be louder (I have tested it with this 12V tone generator http://www.kemo-electronic.de/en/Car/Modules/M048N-Ultrasonic-Generator.php )
I am making any mistake?
Thanks in advance!

resistance of the speaker?current limit?

If I mesure the piezo buzzer resistance with a multimeter I get like open circuit.

I have managed to make it a bit louder by placing a 1K resistor in parallel with the load (piezo buzzer).
What I am wondering now is why this resistor makes it louder and how to calculate the proper resistor value in order to have the loudest output.

It makes it louder because resistance is parallel reduces the value of the load resistance hence the overall resistance increases, increasing the current in the circuit.

Do you have a capacitance meter?

To maximize the power through the load you will need a maximum apparent power, try reducing the value of power-factor.

We want to see a schematic.  Cutesy wiring diagrams are not appreciated, especially when they are presented in place of a proper schematic.

The piezo buzzer capacitance is 10nF

The piezo element acts like a capacitor, not like a more-or-less resistive element as in a conventional speaker. You need to discharge the capacitor during the 'off' time or you just get a click and little sound after that. That's why your resistor helps. Push-pull would be much better, and an H-bridge would give you much more output (maybe too much for the speaker).
Also the IRZ44 is not specified to be driven from 5V (it's specified at 10V Vgs) so you may not get much current. Further, if you're trying to get 10's of kHz, you won't be able to drive the MOSFET gate that fast with a 1K resistor, in fact the Arduino may not be able to source enough current and you may have to use a gate driver.
If you can measure the capacitance and provide the frequency of interest, more specific recommendations would be possible. At 2kHz about 3K would be okay with a 10nF element, but that resistance would decrease with increasing resistance and with increasing capacitance, and at some point the power dissipation in the resistor will become excessive.
Edit: You can do something like the below with a 10nF/20kHz requirement:

simulate this circuit – Schematic created using CircuitLab
You could even duplicate the above circuit and add an inverter in series with one of the halves and get 24Vpp across the piezo, but you might want to use somewhat beefier transistors (Zetex perhaps).

I have measured the capacitance on the piezo buzzer pins and is 10nF. I want to generate sound arround 20kHz. How can I calculate the proper resistor value? Can you explain a little bit that "push-pull" solution?

See above edit. You can base a resistor value on the RC product being much less than half a cycle.

I have tested your circuit and the sound level is almost the same as mine (with the resistor in parallel with the piezo). There is any disadvantage of using my solution compared to yours?

Wasted power in the resistor is the disadvantage. Advantage is slightly cheaper, simpler. Your choice.

Based on your circuit, what do I have to change to drive the piezo at 40 kHz. Can you explain me how to calculate it? Thanks!

The usable frequency range of the speaker is 2500 - 45000 Hz. In your script, you sweep from 10Hz to 10kHz which is a bit low. Try to change the start frequency to a higher value:
void setup() {
}

void loop() {
  int pinOut = 9;
  int freq = 2500;
  int duration = 100;
  while(1)
  {
    for(int i=0; i<1000 ; i++)
    {
      tone(pinOut, freq+(i*50));
      delay(duration);
      noTone(pinOut);
    }
  }
}

With this script I get more tones (as expected) but the sound is not louder

Try to add an inductor (value from 10-50mH) in parallel to the piezo buzzer. This creates a resonant circuit and helpts to discharge the piezo in the off stage. For further Information see Link


text:
Programatic FOTA (Firmware-Over-The-Air) upgrades with Uno R3
I have been searching for a way to upgrade the sketch on my Arduino Uno wirelessly (preferable WiFi, but not a must). Does the Uno support such function?
If not - are there any other boards that might support it?
Also, to further extend on the problem - I wouldn't want to upload a new sketch through the Arduino IDE but rather do it programmatically (trying to integrate it with a version management system of my own).

The "Particle"  (was Spark Core) is an Arduino compatible ARM processor with inbuilt WiFi that supports program loading from "the cloud" and data transfer to and from elsewhere also by WiFi. Not cheap but reasonable. Shop - lots of goodies

http://lowpowerlab.com/blog/category/moteino/wireless-programming/ supports OTA firmware upgrade, though not via WiFi.

There's two ways you can go about this - hardware and software.
To do it in software would mean writing a new bootloader that supported whatever wireless medium you chose.  The bootloader might end up quite large and thus restrict the size of sketch you are able to support.  It may also require advanced programming techniques in order to fit it into memory.  Not a task for a beginner.
Doing it in hardware is easier but more restrictive.  You need a wireless medium that can emulate a serial device including the ability to perform a reset of the Arduino.  There are bluetooth interfaces for the Arduino that can perform this kind of functionality, but I am not aware of anything WiFi or Ethernet that even remotely comes close.
There are Arduino boards available with this kind of bluetooth interface built in.
A possible third option is something in between - you have two Arduinos (or some other external MCU based system, like an ATTiny for instance), the "target" and the "programmer".  The "programmer" is what is connected to the wireless and accepts instructions and commands over the air.  It is then capable of putting the "target" into bootloader mode (reset it) and pass data through to its serial port for programming.  It does mean the "target" isn't directly connected to the wireless though, so it is up to the "programmer" to support whatever wireless functionality is needed and communicate properly with the "target" to get it to do everything it should.  There is no way to do FOTA to the "programmer" though, so you're back at square one if you want to reprogram that...

ESP series WiFi chips would be able to update an Arduino's software. But I am not aware it has been done yet.

This is possible using stock ESP8266 and Arduino components. My question addresses this and provides the relevant links I have found. The alternate to what I'm doing is to flash the ESP8266 with some alternate firmware e.g. ESPLink, NodeMCU or uPython. ESPLink seems purpose built for over the air updates, but I have no experience with these.

There are plenty of examples of Arduinos being used to reprogram Arduinos:

Using an Arduino as an AVR ISP (In-System Programmer)
Standalone AVR ISP Programmer Shield Kit
Atmega chip stand-alone programmer to upload .hex files
Atmega bootloader programmer

So the obvious choice here is to have two chips. One does the real work, the other one programs the first one, when required.
The "programmer" chip could be written to read from a disk file, accept data over Ethernet, WiFi or whatever. And it could be programmed to reprogram the target chip at a certain time of day, or on command.
In this system the "main" chip gets on with whatever-it-is it is doing, and the "programmer" chip just monitors its source of new code.

Does the Uno support such function? If not - are there any other boards that might support it?

I don't know of any boards that directly support that. These boards are generally built as educational tools, not as ready to deploy in the field as robust auto-upgrading devices. For one thing, keeping things cheap enough for students to purchase, perhaps one for each student in a classroom of 30, was one of the design criteria.

It makes little sense to use another Arduino for this, as they don't have the needed connectivity either.  Rather, use the connectivity (WiFi, BLE, whatever) processor to reprogram the Arduino... or just use the connectivity processor instead of the ATmega Arduino, since most of these devices have far better support for self programming and more resources for processing messages in general.

You can wire an ESP32-based board or module to your Arduino, and use https://vcon.io for a remote OTA. vcon firmware can act as an AVR (and not just AVR) programmer, and reflash your Arduino remotely.
Also, as a side-effect, you'll get remote control capability for your Arduino. https://dash.vcon.io cloud service gives you device dashboard and an API for remote control and OTA.
Disclaimer: I do represent https://vcon.io product.

all_licenses: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/4.0/


text:
Newbie Question with 4 pin button
I suspect this is a very Naive question.
But the answer will teach me a lot.
Why does this circuit work when I connect the Digital Input (Digial Pin 2) to Pin 4 of the push button. But does not when I connect the push button to Pin 3. I missing something about how power flows when the button is pushed.
Ray K

Are you using the pin assignment convention of having pin 1 on the bottom left and counting up going counterclockwise?

Please clarify what pins you are talking about. In this case top-right, top-left, bottom-right and bottom-left would be a lot clearer.

Internally those little tactile switches look like this:

That means that the two pins on the same long side are connected together.  So you can use, when you hold the switch vertically as in the image on the page you link to the two left-hand pins are linked together, and the two right-hand pins are linked together.
So you can use either both the top pins, both the bottom pins, or the top left and bottom right or the top right and bottom left.
Using either both left hand pins or both right hand pins will be as if you were sat on the button and it was permanently pressed.

ok - so let say I do the silly thing, and I connect the 5V VCC and the Digital Input (Pin 2) on the same long side. Is there then constantly power flowing to the Digital Input - making it impossible to differentiate between keypresses?

Yep. That's it exactly.


text:
Problem with reading multiple potentiometer values on Arduino Uno
I'm working on an Arduino sketch that will read in values from two potentiometers. The code for this is below:
int lastPotentiometerOneValue = 0;
int lastPotentiometerTwoValue = 0;

void setup() {
  // initialize serial communication at 57600 bits per second:
  Serial.begin(57600);
}

void loop() {
  delay(10);
  readAndSendPotentiometerDataIfChanged();
}

void readAndSendPotentiometerDataIfChanged(void) {

  //Potentiometer One
  int newPotentiometerOneValue = analogRead(A0) / 10.2;
  if (newPotentiometerOneValue == lastPotentiometerOneValue) return;

  Serial.print("!pos1");
  Serial.print(newPotentiometerOneValue);
  Serial.print(";");
  lastPotentiometerOneValue = newPotentiometerOneValue;

  //Potentiometer Two
  int newPotentiometerTwoValue = analogRead(A1) / 10;
  if (newPotentiometerTwoValue == lastPotentiometerTwoValue) return;

  Serial.print("!pos2");
  Serial.print(newPotentiometerTwoValue);
  Serial.print(";");
  lastPotentiometerTwoValue = newPotentiometerTwoValue;
}

The schematic for my circuit is below (I've left out the code for reading the state of the push-button in my listing above, as that's in a separate method from the method that reads in the potentiometer data):

However, there seems to be a rather subtle error I'm experiencing. If I turn Potentiometer One, it will display the correct output in the serial monitor. If I turn Potentiometer Two, no value will be displayed. However, if I remove Potentiometer Two from the circuit board and turn Potentiometer One, then the serial monitor will display the Potentiometer Two as having the same data as Potentiometer Two.
I'm sure the problem is with my circuit, but I'm not quite sure what I'm doing wrong. Does anyone have some insight? Thank you!

One problem is that if the value for pot1 has not changed, the value for pot2 will never be sent, even if it has changed, due to the early return when checking the value of pot1. You could fix this by changing to:
void readAndSendPotentiometerDataIfChanged(void) {

  //Potentiometer One
  int newPotentiometerOneValue = analogRead(A0) / 10.2;
  if (newPotentiometerOneValue != lastPotentiometerOneValue) {
      Serial.print("!pos1");
      Serial.print(newPotentiometerOneValue);
      Serial.print(";");
      lastPotentiometerOneValue = newPotentiometerOneValue;
  }

  //Potentiometer Two
  int newPotentiometerTwoValue = analogRead(A1) / 10.2;
  if (newPotentiometerTwoValue != lastPotentiometerTwoValue) {
      Serial.print("!pos2");
      Serial.print(newPotentiometerTwoValue);
      Serial.print(";");
      lastPotentiometerTwoValue = newPotentiometerTwoValue;
  }
}

Worked beautifully! I realized that I was looking at a rather old code example that was based off of only one potentiometer (where those "return" statements came from).


text:
Arduino GPSlim 236
I'm looking to connect an old GPSlim236 device to my Arduino via serial comms. I have seen references online on how to connect the device but in the data sheet it says TTL level between 3V - 5V.  Does this mean that the GPS can automatically switch between logic level 5V -3V when needed?
Here is the link to data sheet for the GPS - http://www.holux.com/JCore/UploadFile/3205400.pdf

The datasheet says:

Power Supply
External Voltage: 5VDC +/- 10%

So I take that to mean you supply 5V to it.

Later on it says:

Transmit Data. From organizer to peripheral. (Voltage Level is 3.3V ~ 5.0V)

I presume that means that it will supply (or accept) 3.3V to 5V as a high level, and less than 3.3V as a low level. This is perfectly normal for an Arduino.

Does this mean that the GPS can automatically switch between logic level 5v -3v when needed ?

No I would not read it like that. If you read the datasheet for the Arduino processor chips it states things like an output high is a range of voltages, similar to what this device is saying. A "high" is not necessarily 5V exactly, it might be 4.7V, for example. However the Arduino input pins are similarly designed to take a range of voltages.

My confusion here is that the datasheet says 3-5v but what if I connect the device to a raspberry pi which (I think) only accepts 3v, would it still work?

Well, the datasheet says 5V +/- 10% for charging the internal battery. I'm not sure what your situation is if you are trying to run it from a Pi.

Hi Nick, thanks for the reply.  So does that mean if the GPS was connecting to a device that only accepted 3v as a logic high that it would work ? My confusion here is that the datasheet says 3-5v but what if I connect the device to a raspberry pi which (I think) only accepts 3v, would it still work ? Feel free to point me to a good document or source of information that can help me understand the difference between the different logic level.

See amended answer. If you want to connect it to a Pi, you may need level shifters, because the 5 V output would be too high for it.


text:
How to compile, upload and monitor via the Linux command line?
Interfacing an Arduino Uno (uploading etc.) with the Arduino IDE (using the Fedora package) works fine under Fedora 21.
But I rather want to use vim + make + vim-quickfix-mode etc.
How can I do that?
Preferably via the tools available from the Fedora repositories.
I assume that the IDE calls externals command line utilities for the uploading etc.
The equivalent to the IDE's serial monitor is probably connecting a terminal emulator (e.g. screen) to /dev/ttyACM0, right?
Perhaps there is a good example project one can look at the makefile?

Bumping as all of these answers are quite old As of Jun 05th 2021, the arduino-cli tool is extremely good. You can make a very simple 2 line Makefile in no time.

A great way to compile for and flash an Arduino device from the command line and integrate with Vim is to use PlatformIO Core (CLI).
Since it's written in Python it's easy to install even when it's not packaged for your Linux distribution. PlatformIO supports many microcontroller devices, not just Arduino ones. Thus, you don't have to switch your development environment when you target another platform. PlatformIO takes care of downloading the right toolchain (compiler etc.) for your target.
Example
Getting started with PlatformIO and an Arduino Pro Mini 3.3v clone on Fedora 35:
mkdir -p ~/local
cd ~/local
python -m venv platformio
source platformio/bin/activate
pip install platformio

This installs PlatformIO (CLI) in a virtual environment, i.e. its main command is then available from ~/local/platformio/bin/pio and pio is found in your PATH when the virtual environment is activated.
Next, we need to find the right board ID for setting up a new project:
pio boards arduino | less

That means search for Pro.*Mini in the listing. There are several versions of the Pro Mini, in our example the pro8MHzatmega328 (3.3 V, 8 MHz, ATmega328, 30 kb flash, 2 kB RAM) is the right one as can be validated by looking at the board markings as well as its voltage regulator, and CPU markings.
To set up a new project
mkdir ~/project/some_new_project
cd ~/project/some_new_project
pio project init --board pro8MHzatmega328 --ide vim

Which prints:
The current working directory /home/juser/project/arduino/pro-mini will be used for the project.

The next files/directories have been created in /home/juser/arduino/pro-mini
include - Put project header files here
lib - Put here project specific (private) libraries
src - Put project source files here
platformio.ini - Project Configuration File
Platform Manager: Installing atmelavr
Downloading  [####################################]  100%
Unpacking  [####################################]  100%
Platform Manager: atmelavr @ 3.4.0 has been installed!
Tool Manager: Installing platformio/toolchain-atmelavr @ ~1.70300.0
Downloading  [####################################]  100%
Unpacking  [####################################]  100%
Tool Manager: toolchain-atmelavr @ 1.70300.191015 has been installed!
The platform 'atmelavr' has been successfully installed!
The rest of the packages will be installed later depending on your build environment.

Project has been successfully initialized including configuration files for `vim` IDE.

For a first test one can copy a simple blink-led example using the usual setup()/loop() functions. It's possible to re-use an existing 'sketch' from the Arduino IDE, one just has to add #include <Arduino.h> at the top and place it under src/some-name.cc or src/some-name.cpp.
To compile everything:
pio run

Which prints:
Processing pro8MHzatmega328 (platform: atmelavr; board: pro8MHzatmega328; framework: arduino)
--------------------------------------------------------------------------------
Verbose mode can be enabled via `-v, --verbose` option
CONFIGURATION: https://docs.platformio.org/page/boards/atmelavr/pro8MHzatmega328.html
PLATFORM: Atmel AVR (3.4.0) > Arduino Pro or Pro Mini ATmega328 (3.3V, 8 MHz)
HARDWARE: ATMEGA328P 8MHz, 2KB RAM, 30KB Flash
DEBUG: Current (avr-stub) On-board (avr-stub, simavr)
PACKAGES:
 - framework-arduino-avr 5.1.0
 - toolchain-atmelavr 1.70300.191015 (7.3.0)
LDF: Library Dependency Finder -> https://bit.ly/configure-pio-ldf
LDF Modes: Finder ~ chain, Compatibility ~ soft
Found 5 compatible libraries
Scanning dependencies...
No dependencies
Building in release mode
Compiling .pio/build/pro8MHzatmega328/src/sos-switch.cc.o
Linking .pio/build/pro8MHzatmega328/firmware.elf
Checking size .pio/build/pro8MHzatmega328/firmware.elf
Advanced Memory Usage is available via "PlatformIO Home > Project Inspect"
RAM:   [          ]   0.4% (used 9 bytes from 2048 bytes)
Flash: [          ]   3.8% (used 1170 bytes from 30720 bytes)
========================= [SUCCESS] Took 0.51 seconds =========================

So for this example I created src/sos-switch.cc which is compiled to .pio/build/.../sos-switch.cc.o.
To upload (flash) the device:
pio run --target upload

As always, a common pitfall are the permissions of the USB device. For example, on Fedora, my USB2TTL serial device registers as /dev/ttyUSB0 with read-write permissions for just root:dialout. Thus, you have to add your user to the dialout group or adjust the permissions by other means.
Vim Quickfix Mode
For integrating with Vim's quickfix mode a simple makefile is sufficient, e.g.:

.PHONY: all
all: build

.PHONY: build
build:
    pio run

.PHONY: upload
upload:
    pio run --target upload

Thus, everything is built when :make is invoked in Vim, and there one can navigate the quickfix mode as usual.
Serial Monitoring
An easy way to monitor the serial interface is to use picocom, e.g.:
picocom --baud 9600 --echo --imap lfcrlf --noreset /dev/ttyUSB0

where:

--imap lfcrlf maps newline to carriage return + newline such that we can just write Serial.print("multi\nlines\n') instead of Serial.print("multi\r\nlines\r\n") in our program
--noreset tells picocom to not clear DTR - without it, when DTR is connected, the Anrdoid device is reset

Of course, one has to terminate picocom when uploading.

Alternatively, one can use the PlatformIO monitor command:
pio device monitor

In contrast to picocom, it doesn't require explicit mapping or DTR handling. However, as with picocom, it must be terminated when uploading/flashing. That means PlatformIO doesn't automatically suspends monitoring when pio run --target upload is invoked.
Closing Remarks

PlatformIO is currently packaged for Fedora and thus might be directly available in Fedora 36 or so
the classic Arduino IDE was packaged for Fedora, but isn't available anymore in Fedora 35 because of the big Java package exodus
there is also a PlatoformIO plugin for VSCode which seems to be quite popular

Nice answer. Re “--imap lfcrlf”: This is not needed if you use Serial.println(), which is the “Arduino way” of printing a new line.

@EdgarBonet yes, Serial.println() writes \r\n, thus we don't need the mapping if it's used exclusively. However, both the classic Arduino IDE and the PlatformIO monitor implicitly map \n to \r\n such that you get away with single \n. If you transmit \r\n you might end up with \r\r\n, which doesn't hurt. Even if your program uses Serial.println() you still might use \n in multi-line strings. Updated my answer to illustrate this point. However, for an end-user facing console, it makes sense to stick to \r\n and detect oversights by not having such a mapping.

I use the command-line interface to the arduino command.
I run it like this:
arduino --upload sketch/sketch.ino --port /dev/ttyUSB*

There is a page which describes other command-line tools, like inotool. That page also has an example Makefile. These alternatives seem enticing, but apparently, as of this writing, none of them work. I'm assuming this is due to some recent changes in Arduino IDE distribution files which they depend on.
Running arduino as above is a bit slow, because it has to load Java I guess, but at least it works. There is also an arduino-builder command that comes with the Arduino IDE distribution. As of this writing, it was not sufficiently well-documented for me to be able to figure out how to use it. For instance there are no example command lines in the README or in any of the tutorials I came across, and I couldn't figure out how to use it to upload code to the board. However, presumably it is able to give us a faster compile than arduino. The README also mentions being able to reuse object files from a previous compile, so there is some make-like functionality.

To view serial output I use something like
stty -F /dev/ttyUSB* 1000000 raw -clocal -echo
cat /dev/ttyUSB*

The number 1000000 should match the number you pass to Serial.begin() in your board code. You can also use screen if you have a board program which is appropriately interactive, or you can use whatever utility to write directly to the device. By the way, my Due shows up as /dev/ttyACM0 (rather than /dev/ttyUSB0 for the Uno).

Make sure you have a single *.ino file in the directory, as it does not seem to necessarily upload the one mentioned by the --upload parameter.

No X11 DISPLAY variable was set, but this program performed an operation which requires it.
For me

I would suggest Googling for Makefile projects. I did one a while back for the Blink program, by basically seeing what got generated by the IDE and replicating that in a more general way.
#
# Simple Arduino Makefile
#
# Author: Nick Gammon
# Date: 18th March 2015

# where you installed the Arduino app
ARDUINO_DIR = C:/Documents and Settings/Nick/Desktop/arduino-1.0.6/

# various programs
CC = "$(ARDUINO_DIR)hardware/tools/avr/bin/avr-gcc"
CPP = "$(ARDUINO_DIR)hardware/tools/avr/bin/avr-g++"
AR = "$(ARDUINO_DIR)hardware/tools/avr/bin/avr-ar"
OBJ_COPY = "$(ARDUINO_DIR)hardware/tools/avr/bin/avr-objcopy"

MAIN_SKETCH = Blink.cpp

# compile flags for g++ and gcc

# may need to change these
F_CPU = 16000000
MCU = atmega328p

# compile flags
GENERAL_FLAGS = -c -g -Os -Wall -ffunction-sections -fdata-sections -mmcu=$(MCU) -DF_CPU=$(F_CPU)L -MMD -DUSB_VID=null -DUSB_PID=null -DARDUINO=106
CPP_FLAGS = $(GENERAL_FLAGS) -fno-exceptions
CC_FLAGS  = $(GENERAL_FLAGS)

# location of include files
INCLUDE_FILES = "-I$(ARDUINO_DIR)hardware/arduino/cores/arduino" "-I$(ARDUINO_DIR)hardware/arduino/variants/standard"

# library sources
LIBRARY_DIR = "$(ARDUINO_DIR)hardware/arduino/cores/arduino/"

build:

    $(CPP) $(CPP_FLAGS) $(INCLUDE_FILES) $(MAIN_SKETCH) -o $(MAIN_SKETCH).o
    $(CC) $(CC_FLAGS) $(INCLUDE_FILES) $(LIBRARY_DIR)avr-libc/malloc.c -o malloc.c.o
    $(CC) $(CC_FLAGS) $(INCLUDE_FILES) $(LIBRARY_DIR)avr-libc/realloc.c -o realloc.c.o
    $(CC) $(CC_FLAGS) $(INCLUDE_FILES) $(LIBRARY_DIR)WInterrupts.c -o WInterrupts.c.o
    $(CC) $(CC_FLAGS) $(INCLUDE_FILES) $(LIBRARY_DIR)wiring.c -o wiring.c.o
    $(CC) $(CC_FLAGS) $(INCLUDE_FILES) $(LIBRARY_DIR)wiring_analog.c -o wiring_analog.c.o
    $(CC) $(CC_FLAGS) $(INCLUDE_FILES) $(LIBRARY_DIR)wiring_digital.c -o wiring_digital.c.o
    $(CC) $(CC_FLAGS) $(INCLUDE_FILES) $(LIBRARY_DIR)wiring_pulse.c -o wiring_pulse.c.o
    $(CC) $(CC_FLAGS) $(INCLUDE_FILES) $(LIBRARY_DIR)wiring_shift.c -o wiring_shift.c.o
    $(CPP) $(CPP_FLAGS) $(INCLUDE_FILES) $(LIBRARY_DIR)CDC.cpp -o CDC.cpp.o
    $(CPP) $(CPP_FLAGS) $(INCLUDE_FILES) $(LIBRARY_DIR)HardwareSerial.cpp -o HardwareSerial.cpp.o
    $(CPP) $(CPP_FLAGS) $(INCLUDE_FILES) $(LIBRARY_DIR)HID.cpp -o HID.cpp.o
    $(CPP) $(CPP_FLAGS) $(INCLUDE_FILES) $(LIBRARY_DIR)IPAddress.cpp -o IPAddress.cpp.o
    $(CPP) $(CPP_FLAGS) $(INCLUDE_FILES) $(LIBRARY_DIR)main.cpp -o main.cpp.o
    $(CPP) $(CPP_FLAGS) $(INCLUDE_FILES) $(LIBRARY_DIR)new.cpp -o new.cpp.o
    $(CPP) $(CPP_FLAGS) $(INCLUDE_FILES) $(LIBRARY_DIR)Print.cpp -o Print.cpp.o
    $(CPP) $(CPP_FLAGS) $(INCLUDE_FILES) $(LIBRARY_DIR)Stream.cpp -o Stream.cpp.o
    $(CPP) $(CPP_FLAGS) $(INCLUDE_FILES) $(LIBRARY_DIR)Tone.cpp -o Tone.cpp.o
    $(CPP) $(CPP_FLAGS) $(INCLUDE_FILES) $(LIBRARY_DIR)USBCore.cpp -o USBCore.cpp.o
    $(CPP) $(CPP_FLAGS) $(INCLUDE_FILES) $(LIBRARY_DIR)WMath.cpp -o WMath.cpp.o
    $(CPP) $(CPP_FLAGS) $(INCLUDE_FILES) $(LIBRARY_DIR)WString.cpp -o WString.cpp.o
    rm core.a
    $(AR) rcs core.a malloc.c.o
    $(AR) rcs core.a realloc.c.o
    $(AR) rcs core.a WInterrupts.c.o
    $(AR) rcs core.a wiring.c.o
    $(AR) rcs core.a wiring_analog.c.o
    $(AR) rcs core.a wiring_digital.c.o
    $(AR) rcs core.a wiring_pulse.c.o
    $(AR) rcs core.a wiring_shift.c.o
    $(AR) rcs core.a CDC.cpp.o
    $(AR) rcs core.a HardwareSerial.cpp.o
    $(AR) rcs core.a HID.cpp.o
    $(AR) rcs core.a IPAddress.cpp.o
    $(AR) rcs core.a main.cpp.o
    $(AR) rcs core.a new.cpp.o
    $(AR) rcs core.a Print.cpp.o
    $(AR) rcs core.a Stream.cpp.o
    $(AR) rcs core.a Tone.cpp.o
    $(AR) rcs core.a USBCore.cpp.o
    $(AR) rcs core.a WMath.cpp.o
    $(AR) rcs core.a WString.cpp.o
    $(CC) -Os -Wl,--gc-sections -mmcu=$(MCU) -o $(MAIN_SKETCH).elf $(MAIN_SKETCH).o core.a -lm
    $(OBJ_COPY) -O ihex -j .eeprom --set-section-flags=.eeprom=alloc,load --no-change-warnings --change-section-lma .eeprom=0 $(MAIN_SKETCH).elf $(MAIN_SKETCH).eep
    $(OBJ_COPY) -O ihex -R .eeprom $(MAIN_SKETCH).elf $(MAIN_SKETCH).hex

You would need to change ARDUINO_DIR at least, to reflect where you installed the IDE. If you use other things like the Wire library you would need to expand it somewhat to compile additional libraries. Again, you can use what the IDE generates itself to guide your changes.
The lines with the leading spaces above would need the tab character instead of spaces, as is normal for a Makefile.

An upload section in the make file would also be useful, to upload the compiled sketch to the arduino (using avr-dude).

That would definitely be useful. However as, so far, the IDE has met my needs for compiling and uploading, I am not strongly motivated to work out how to do it. :)

Take a look at Metamorphic answer for an easier solution

Someone suggested editing out the statement "I would suggest Googling for Makefile projects." on the grounds that people probably reached this page from Google anyway. However I think it is still a helpful suggestion, especially in direct response to the posted question. My answer gave one suggested way of achieving the result, a Google search may supply others.

What you need is a Makefile.  There are a few Makefile projects around for Arduino.  Googling for "Arduino Makefile" returns many results including what looks like a good one on Github: https://github.com/sudar/Arduino-Makefile
Compiling from the command line isn't trivial due to the way the Arduino IDE handles libraries.

The equivalent to the IDE's serial monitor is probably connecting a terminal emulator (e.g. screen) to /dev/ttyACM0, right?

For the serial monitor I would recommend minicom. It is a fully functional terminal emulator (vt102) on the command line.
minicom -D /dev/ttyACM0 -b 115200

... for example.

This Makefile is essentially a maintained version of the accepted answer. There is also a template project on GitHub that shows you how to set it up: https://github.com/ladislas/Bare-Arduino-Project

Official CLI tool
The arduino team is developing a cli client
https://github.com/arduino/arduino-cli
Announcement: https://blog.arduino.cc/2018/08/24/announcing-the-arduino-command-line-interface-cli/
You can do almost everything with this, from downloading boards and libraries, to compile and upload scripts. What's missing is the monitoring part (you can use Metamorphic's method using stty cat, It works!)
The commands are very similar to Metamorphic's answer since this tool is branching out of that one
Instructions in the Github repo and the man page:
    $ arduino-cli Arduino Command Line Interface (arduino-cli).

    Usage:   arduino-cli [command]

    Examples: arduino <command> [flags...]

    Available Commands:
      board         Arduino board commands.
      compile       Compiles Arduino sketches.
      config        Arduino Configuration Commands.
      core          Arduino Core operations.
      help          Help about any command
      lib           Arduino commands about libraries.
      sketch        Arduino CLI Sketch Commands.
      upload        Upload Arduino sketches.
      version       Shows version number of Arduino CLI.

If you want a fully compatible solution for your arduino project (yes, you can share your project with other people that use just plain Arduino IDE) you need to check amake a tool to simplify the cli of the arduino, I use it with Geany but others are using it with vi, Atom, etc.
It's inspired and the now dead Ino and Arturo projects; please take 5 minutes to test it and please give feedback.
Example use:
cd ~/Arduino/Blink/
[move to your arduino project folder]

amake -v uno Blink.ino
[to compile/verify your code]

amake -u uno Blink.ino /dev/ttyUSB0
[to upload your code to an arduino connected via USB]

It has some smart glue in there, it can remember the board and file, and even autodetect the usb of the board; so after a successfull "amake -v" command you can do this on the command line and it will work.
amake -v
[to compile/verify your code]

amake -u
[to upload your code to an arduino connected via USB]

If you use some IDE macros you can craft the compile and upload commands easily, for example using Geany IDE it will became:

Compile/Verify: cd %d; amake -v uno %f
Upload: cd %d; amake -u uno %f

You can get more help running just "amake" or "amake -h" once installed.
Also, it can support EVERY board/lib/programmer you have installed/configured in your Arduino IDE, yes, modern board like the Adafuit Trinket M0 / Arduino M0 etc...
Just fire your Arduino IDE, go to the board manager, install support and that's all, jut follow some simple instructions and your are set.
The board you have is not supported? not a problem, detect the fqbn (read the README.md file) and pass it along as the board name.
I'm looking for testers to grow up the number or board aliases and auto detection of the proper USB signatures.
Remember this is a private grown tool, now shared with the public, you know, just a programmer scratching it's itch...
Cheers.


text:
Loop though array values at end of each for loop cycle
I'm using the NeoPixel Ring from Adafruit and trying to pulse though and array of colors. However, I'm having trouble with having the loop go to the next color at the end of each pulse (end of loop). Here is what I currently have:
uint32_t color[] = {red, green, blue,yellow,teal,magenta};

void pulseUp(uint8_t speed){
  int fadeAmount = 10; //how much to increase each loop
  int n = 0; //get first color
  for(int b = 100; b >= 10; b = b - fadeAmount) { //start pulse for loop
    for (int i = 0; i < strip.numPixels(); i++) { //select all pixels
      strip.setPixelColor(i, color[n]); //set color from our array
      }
    strip.setBrightness(b); //set brightness based on b
    strip.show(); // send the changes to the strip
    delay(speed); //wait before running again
    //if at the end of the loop (brightness is 10) change color
    if (b == 10){
      if( n > 6){ //if we are at last color in our loop start over
        n = 0;
      }
      else{
        n++; //auto increment color value
      }
    }
  }
}

I'm sure the problem is with the if statements but not sure how to fix it.

Where is the loop for going through each color?

@IgnacioVazquez-Abrams I was trying to do it with an if statement and n++ instead of a loop.

if is not a looping statement.

I can't quite make out what your if test is supposed to be doing, but don't you want a loop within a loop? Like this?
uint32_t color[] = {red, green, blue,yellow,teal,magenta};

void pulseUp(uint8_t speed)
  {
  const int fadeAmount = 10; //how much to increase each loop
  for (int currentColor = 0; currentColor < 6; currentColor++)
    {
    for (int i = 0; i < strip.numPixels(); i++)
      { //select all pixels
      strip.setPixelColor(i, color[currentColor]); //set color from our array
      }
    for(int brightness = 100; brightness >= 10; brightness -= fadeAmount)
      { //start pulse for loop
      strip.setBrightness(brightness); //set brightness based on brightness
      strip.show(); // send the changes to the strip
      delay(speed); //wait before running again
      }  // end of brightness loop
    }  // end of colour loop
  }  // end of pulseUp

Yep, that's what I was trying to do. I tried something similar but must of had something off. Also what's the difference between int and const int ?

@BandonRandon: One can be changed, the other can't. Which means that the compiler can do things such as inlining the value.


text:
Arduino programmers for hire?
How do I best connect with Arduino programmers who are willing to design small projects for some extra cash?

are you talking about Free lancer   ?

The Arduino Forum has a Gigs and Collaborations section where such questions are welcome.


text:
Arduino Uno and Agilent ADNS-3080 not reading from SPI
I am trying to interface with a mouse sensor and am not able to get data back.
datasheet link
I have it still soldered to the original PCB but have cut the traces to pins 1-4,6,7 (NCS [SS], MISO, SCLK, MOSI, RESET, NPD [power down {set to 3.3v}])
PLEASE LET ME KNOW IF ANYTHING SEEMS WRONG HERE.
According to the Datasheet, by default the sensor is setup with the pull-up resistors enabled [pg. 29] which enables the open-drain, allowing me to directly connect NCS,MISO,SCLK,MOSI directly to the 5v microcontroller [pg. 15]. This also requires the SPI speed set to 500khz [pg. 10]. RESET is in a (10k)(10k+10k) resistor bridge.
SPI should be set to Mode3 as SCLK is normally high and data should be captured on the rising edge of the clock pulse [pg. 16]
Here is my code:
#include <SPI.h>
const int MOUSEVERSION = 0x00; //mouse version
const int CSmouse = 10;
const int mouseReset = 2;
char val;

void setup() {
  Serial.begin(9600);
  SPI.beginTransaction(SPISettings(500000, MSBFIRST, SPI_MODE3));
  pinMode(CSmouse, OUTPUT);
  pinMode(mouseReset, OUTPUT);
  digitalWrite(CSmouse, HIGH);
  //pull reset pin high for a half second to make sure mouse is ready to go after powering on [pg. 22]
  digitalWrite(mouseReset, HIGH);
  Serial.println("setup");
  delay(500); //half a second
  digitalWrite(mouseReset, LOW);
  Serial.println("end setup");
}

void loop() {
  Serial.println("Start loop");
  digitalWrite(CSmouse, LOW); //CS enable
  SPI.transfer(MOUSEVERSION); //0x00 = read register Product_ID, should reply 0x17
  delayMicroseconds(75);
  Serial.println(SPI.transfer(0)); //actually just gives 0
  delay(500);
}

You have SPI.beginTransaction but no SPI.begin().
SPI.begin() is needed to initialize the SPI hardware.
More details about SPI at SPI - Serial Peripheral Interface - for Arduino.

Thank you! I was under the impression that beginTransaction() superseded begin() since setClockDivider() and the like were depreciated.  That is what I get for assuming.


text:
Adafruit_NeoPixel define pin for different setups
I am looking for a way of defining multiple pins for my RGB strips. Currently the defined variable is set with the pin within it. This works just fine if I only had one RGB strip connected to the Arduino but I have 4 so I will need to define.
I currently run this code here:
#include <Adafruit_NeoPixel.h>
#include <avr/power.h>

int rgb1 = 18;
int rgb2 = 17;
int LEDs = 11;
int ledFadeTime = 5;

Adafruit_NeoPixel strip1 = Adafruit_NeoPixel(LEDs, rgb1, NEO_GRB + NEO_KHZ800);
Adafruit_NeoPixel strip2 = Adafruit_NeoPixel(LEDs, rgb2, NEO_GRB + NEO_KHZ800);

void setup() {
  strip1.begin();
  strip1.show(); // Initialize all pixels to 'off'
  strip2.begin();
  strip2.show(); // Initialize all pixels to 'off'
}

void loop() {
  rgbFadeInAndOutStrip1(0, 0, 255, ledFadeTime); // Blue
  rgbFadeInAndOutStrip2(255, 0, 0, ledFadeTime); // red
}

void rgbFadeInAndOutStrip1(uint8_t red, uint8_t green, uint8_t blue, uint8_t wait) {
  for(uint8_t b = 0; b <255; b++) {
     for(uint8_t i=0; i < strip1.numPixels(); i++) {
        strip1.setPixelColor(i, red * b/255, green * b/255, blue * b/255);
     }

     strip1.show();
     delay(wait);
  };

  for(uint8_t b=255; b > 0; b--) {
     for(uint8_t i = 0; i < strip1.numPixels(); i++) {
        strip1.setPixelColor(i, red * b/255, green * b/255, blue * b/255);
     }
     strip1.show();
     delay(wait);
  };
};

void rgbFadeInAndOutStrip2(uint8_t red, uint8_t green, uint8_t blue, uint8_t wait) {
  for(uint8_t b = 0; b <255; b++) {
     for(uint8_t i=0; i < strip2.numPixels(); i++) {
        strip2.setPixelColor(i, red * b/255, green * b/255, blue * b/255);
     }

     strip2.show();
     delay(wait);
  };

  for(uint8_t b=255; b > 0; b--) {
     for(uint8_t i = 0; i < strip2.numPixels(); i++) {
        strip2.setPixelColor(i, red * b/255, green * b/255, blue * b/255);
     }
     strip2.show();
     delay(wait);
  };
};

Which works when trying out just one out of the 2. But when the LEDs fade out it has a pause (i still see a hint of blue on the strip). If i comment all the code out for the second strip2 and run that, it pulses just fine without the hint of blue or the delay to start bright again.
What could I be doing incorrectly?

The WS2812 is very sensitive to timing on the data line, so your use of delay() function, which blocks, might be preventing the data stream from updating fast enough. You need need to do this in the "BlinkWithoutDelay" style or eventually you'll run into the situation where the WS2812 does random things because it's waiting for an update, which you've blocked with "delay" - see video... https://www.youtube.com/watch?v=3VZgaJBrZD8

The “hint of blue on the strip” is a consequence of your second loop in rgbFadeInAndOutStrip1() ending with the test b > 0.  Because of that, the last strip1.setPixelColor() call sets the color to (0,0,1), a faint blue, instead of (0,0,0), off.  Here is some revised code that works ok:
#include <Adafruit_NeoPixel.h>
#include <avr/power.h>
enum { rgbPin1=8, rgbPin2=7, LEDcount=11, ledFadeTime=5};

Adafruit_NeoPixel strip1 = Adafruit_NeoPixel(LEDcount, rgbPin1);
Adafruit_NeoPixel strip2 = Adafruit_NeoPixel(LEDcount, rgbPin2);

void setup() {
  strip1.begin();
  strip1.show(); // Initialize all pixels to 'off'
  strip2.begin();
  strip2.show(); // Initialize all pixels to 'off'
}

void loop() {
  rgbFadeInAndOutStrip1(0, 0, 255, ledFadeTime); // Blue
  rgbFadeInAndOutStrip2(255, 0, 0, ledFadeTime); // red
}

void fadeStrip(Adafruit_NeoPixel *strip, int bval, int bdir, uint8_t red, uint8_t green, uint8_t blue, uint8_t wait) {
  for(uint8_t b=0; b<255; ++b) {
    bval += bdir;
    for(uint8_t i=0; i<strip->numPixels(); ++i) {
      strip->setPixelColor(i, red * bval/255, green * bval/255, blue * bval/255);
    }
    strip->show();
    delay(wait);
  }
}

void rgbFadeInAndOutStrip1(uint8_t red, uint8_t green, uint8_t blue, uint8_t wait) {
  fadeStrip(&strip1, -1, 1,   red, green, blue, wait);
  fadeStrip(&strip1, 255, -1, red, green, blue, wait);
}

void rgbFadeInAndOutStrip2(uint8_t red, uint8_t green, uint8_t blue, uint8_t wait) {
  fadeStrip(&strip2, -1, 1,   red, green, blue, wait);
  fadeStrip(&strip2, 255, -1, red, green, blue, wait);
}

Note, since I ran tests on an Uno rather than a Leonardo, I attached pixel strings to pins 7 and 8 rather than 17 and 18.  I used enum to define constants, rather than declaring constants as variables, and factored some common code into functions rather than reduplicating it.
Following is another program (which I call neocycle6) you can use to test two strips.  Note, it only counts colors down to 1 rather than 0 because I like the effect of leftover pixels glowing faintly.  Also note: the round boards I used have only 7 LEDs each, so I set PixelCount to 7, not 11; this uses pins 7 and 8, not 17 and 18; I don't drive the brightness beyond 77 since the LEDs are so bright anyway; and it doesn't have an
#include <avr/power.h> statement, which you can add if needed.
// Drive 2 sets of 7 ea. WS2812 NeoPixels through sets of colors.
// jw 11 September 2015
#include <Adafruit_NeoPixel.h>

// Select pin# connected to NeoPixels strand, and number of NeoPixels.
enum { PixelPinA=7, PixelPinB=8, PixelCount=7 };
// Create a NeoPixels device structure
Adafruit_NeoPixel pixelA = Adafruit_NeoPixel(PixelCount, PixelPinA);
Adafruit_NeoPixel pixelB = Adafruit_NeoPixel(PixelCount, PixelPinB);

void setup() {
  byte i, j=0;
  pixelA.begin();               // Init. NeoPixel data structure
  pixelB.begin();               // Init. NeoPixel data structure
}

uint8_t c=1, d=1, p=0, v=1;
void loop() {
  c += d;
  if (c>76)
    d = -1;                     // Go down when done going up
  else {
    if (c<2) {                  // Set up for next pixel
      d = 1; p = (p+1)%PixelCount;
      if (!p) ++v;              // Rotate the weights to next color
    }
  }

  pixelA.setPixelColor(p, c*(v&1), c*((v&2)/2), c*((v&4)/4));
  pixelB.setPixelColor(p, c*((v&2)/2), c*(v&1), c*((v&4)/4));
  pixelA.show();               // Show updated colors
  pixelB.show();               // Show updated colors
  delay(9 + 300/c);            // Ramp small numbers more slowly
}


text:
How to Store 2 analogRead values and read using EEPROM for Arduino Uno?
Trying to write 2 values coming from analogread(A0) and analogread(A1) by EEPROM.write  and retrieve the values by EEPROM.read. I tried the following sketch for each write and read. However, could not get the values. Any help please.
For writing to EEPROM:
#include <EEPROMex.h>
int addr = 0;
int array[] = {0, 0};
char a;
void setup() {
}
void loop() {
    array[0] = analogRead(0) / 4;
    array[1] = analogRead(1) / 4;
    EEPROM.write(addr, a);
    addr = addr + 1;

    if (addr == 512) {
        addr = 0;
    }

    delay(100);
}

For reading from EEPROM is:
#include <EEPROM.h>
int address = 0;
int value[2];
void setup() {
    Serial.begin(9600);

    while (!Serial) {
        ;
    }
}
void loop() {
    value = EEPROM.read(address);
    Serial.print(address);
    Serial.print("\t");
    Serial.print(value[0]);
    Serial.print("\t");
    Serial.print(value[1]);
    Serial.println();
    address = address + 1;

    if (address == 512) {
        address == 0;
    }

    delay(500);
}

See Reading and Writing Data Structures to EEPROM.
EEPROM.write(addr,a);

You can't directly write arrays. See the link for how to do it.
Example code:
#include <EEPROM.h>
#include <EEPROMAnything.h>

int array[2];
int addr=0;

void setup()
{
}

void loop()
{
  array[0] = analogRead(0)/4;
  array[1] = analogRead(1)/4;
  EEPROM_writeAnything(addr, array);
  addr += sizeof (array);

  if(addr >= 512)
    exit (1);

  delay(100);
}

Your posted code is a bit flawed anyway. You know EEPROM has a limited life? If you have a sketch that writes to EEPROM indefinitely you will wear it out.
My code above stops once it reaches address 512.

You write the read value directly to value, while value is actually and array. Try this instead.
void loop() {
    value[0] = EEPROM.read(address);
    value[1] = EEPROM.read(address + 1);
    Serial.print(address);
    Serial.print("\t");
    Serial.print(value[0]);
    Serial.print("\t");
    Serial.print(value[1]);
    Serial.println();
    address = address + 2;

    if (address == 512) {
        address = 0;
    } // not address==0;

    delay(500);
}

If this fails try EEPROM.write(&addr,a); and EEPROM.read(&address);

address==0; ?

@NickGammon missed that one. Nice catch.

cant do anything with EEPROM_writeAnything.

I tried with EEPROM_writeAnything but only get one analogread output data. What should I do? Apparently I try to write 2 sensors voltage output in an experiment and then retrieve the stored values for data analysis.

I think these comments are targeted at @NickGammon answer, not mine.

What should I do? - you should amend your question, and post the code you tried.

An int is two bytes so you should be doubling your address increases, n'est pas?

@CharlieHanson address = address + 2;?

The OP uses an int array yet stores only the lowest significant byte into the EEPROM. Bad practice but goes unnoticed because the maximum value ever stored is only 255 (MAX_ADC / 4). The uninitiated could be misled into thinking one call each to EEPROM.write() and EEPROM.read() will magically store and retrieve a multibyte value. In hindsight my comment should have been clearer.

EEPROM can store one byte at a location. To store value of int, it requires two consecutive location. For double, it requires four memory location. I have written code to store and read, int & double to and from built-in EEPROM. Modify as per your need.
/*
  StackExchange Question: "How to Store 2 analogRead values and read using EEPROM for Arduino uno?"
  Question Id: 15910 (http://arduino.stackexchange.com/questions/15910/how-to-store-2-analogread-values-and-read-using-eeprom-for-arduino-uno)
  Author: Anurag S. Vasanwala (AnuragVasanwala@gmail.com)

  Tested on Arduino Version 1.6.7

  Description:  This sketch helps to store and read, Integer & Double to and from built-in EEPROM.
  Objectives:
    + Write Integer @ Specified Address (Fn: EEPROM_Write_Int)
      + Conversion from Integer to Byte Array
      + Store Bytes
    + Read Integer from Specified Address (Fn: EEPROM_Read_Int)
      + Read Bytes
      + Conversion from Byte Array to Integer
    + Write Double @ Specified Address (Fn: EEPROM_Write_Double)
      + Conversion from Double to Byte Array
      + Store Bytes
    + Read Double from Specified Address (Fn: EEPROM_Read_Double)
      + Read Bytes
      + Conversion from Byte Array to Double
 */
#include <EEPROM.h>

// MACRO : Combines FROM_BYTES into TO_OBJECT of datatype "DATATYPE"
#define CombineBytes(FROM_BYTES, DATATYPE, TO_OBJECT) \
  TO_OBJECT = *((DATATYPE *)FROM_BYTES);

// MACRO : Splits FROM_DATA of DATATYPE into equivalent byte array TO_BYTES
#define GetBytes(FROM_DATA, DATATYPE, TO_BYTES) \
  *((DATATYPE *)TO_BYTES) = FROM_DATA;

// Writes Integer's equivalent bytes to Address and Address + 1
void EEPROM_Write_Int(unsigned int Address, int Data)
{
  // Get the size of datatype to write number of bytes
  const byte SizeOf_DataType = sizeof(int);

  // Create tem buffer to get Bytes of Datatype
  byte Temp_Buffer[SizeOf_DataType];

  // Call macro to store byte array into Temp_Buffer from Data
  GetBytes(Data, int, Temp_Buffer);

  // Write number of bytes to memory location specified in Address and so on
  for(byte Index = 0; Index < SizeOf_DataType; Index++)
  {
    EEPROM.write(Address + Index, Temp_Buffer[Index]);
  }
}

// Reads two bytes from Address and Address + 1 and returns equivalent int
int EEPROM_Read_Int(unsigned int Address)
{
  // Get the size of datatype to write number of bytes
  const byte SizeOf_DataType = sizeof(int);

  // Create tem buffer to get Bytes of Datatype
  byte Temp_Buffer[SizeOf_DataType];

  int Result;

  // Read number of bytes from memory location
  for(byte Index = 0; Index < SizeOf_DataType; Index++)
  {
    Temp_Buffer[Index] = EEPROM.read(Address + Index);
  }

  // Call macro to combine bytes into equivalent to int
  CombineBytes(Temp_Buffer, int, Result);

  return Result;
}

// Writes Double's equivalent bytes to Address, Address + 1, Address + 2 and Address + 3
void EEPROM_Write_Double(unsigned int Address, double Data)
{
  // Get the size of datatype to write number of bytes
  const byte SizeOf_DataType = sizeof(double);

  // Create tem buffer to get Bytes of Datatype
  byte Temp_Buffer[SizeOf_DataType];

  // Call macro to store byte array into Temp_Buffer from Data
  GetBytes(Data, double, Temp_Buffer);

  // Write number of bytes to memory location specified in Address and so on
  for(byte Index = 0; Index < SizeOf_DataType; Index++)
  {
    EEPROM.write(Address + Index, Temp_Buffer[Index]);
  }
}

// Reads four bytes from Address, Address + 1, Address + 2 and Address + 3 and returns equivalent double
double EEPROM_Read_Double(unsigned int Address)
{
  // Get the size of datatype to write number of bytes
  const byte SizeOf_DataType = sizeof(double);

  // Create tem buffer to get Bytes of Datatype
  byte Temp_Buffer[SizeOf_DataType];

  double Result;

  // Read number of bytes from memory location
  for(byte Index = 0; Index < SizeOf_DataType; Index++)
  {
    Temp_Buffer[Index] = EEPROM.read(Address + Index);
  }

  // Call macro to combine bytes into equivalent to double
  CombineBytes(Temp_Buffer, double, Result);

  return Result;
}

void setup()
{
  // Initialize Serial @ 9600 baud
  Serial.begin(9600);

  // Print size of datatype just for reference
  /* Serial.print("Size of byte = ");
  Serial.println(sizeof(byte));
  Serial.print("Size of int = ");
  Serial.println(sizeof(int));
  Serial.print("Size of float = ");
  Serial.println(sizeof(float));
  Serial.print("Size of double = ");
  Serial.println(sizeof(double)); */

  int myInt1 = -290;
  int myInt2;
  double myDbl1 = 23.41;
  double myDbl2;

  // Write myInt1 @ 100 memory location; It requires 2 consequtive memory location to store integer
  EEPROM_Write_Int(100, myInt1);

  // Read integer located @ memory location 100 and assign it to myInt2
  myInt2 = EEPROM_Read_Int(100);
  Serial.println(myInt2);

  // Write myInt1 @ 200 memory location; it requires 4 consequtive memory location to store double
  EEPROM_Write_Double(200, myDbl1);

  // Read double located @ memory location 200 and assign it to myDbl2
  myDbl2 = EEPROM_Read_Double(200);
  Serial.println(myDbl2);
}

void loop()
{

}

This code is successfully tested on Arduino Version "1.6.7".


text:
Function not successfully reading sensor registers
I'm trying to write a library for an accelerometer/magnetometer sensor.  The sensor is a LSM303D chip (https://www.pololu.com/file/0J703/LSM303D.pdf).
I've written a function, readRegister() (below) that's supposed to get the data from the sensor.  However, I put in many different registers into the function into the function, but it always returns the same number.  That number changes every time I unplug my Arduino from my computer.
byte fp::readRegister(byte register_address, int numBytes) {
  Wire.requestFrom(register_address, numBytes);
  byte c;
  Serial.println(Wire.read());
  while (Wire.available()) {
    c = Wire.read();
  }
  Serial.print("0x");
  Serial.print(register_address, HEX);
  Serial.print("\t");
  Serial.print(c);
  Serial.print("\t");
  Serial.println(millis());
  return c;
}

Here's an example of the problem output:
0x8 190 2
0x9 190 3
0xA 190 11

And here is something more like what I'd expect:
0x8 193 [time]
0x9 189 [time]
0xA 195 [time]

Here is the Git repo with the rest of the code: https://github.com/fpdotmonkey/fp_accel
Thank you in advance for your help.

Could you show the rest of the code? Is there a Write.endTransmission()?

  Wire.requestFrom(register_address, numBytes);
  byte c;
  Serial.println(Wire.read());
  while (Wire.available()) {
    c = Wire.read();
  }

This has a number of problems. For one thing your (I presume) debugging print consumes the data from Wire.read, so when you go to get it into c, you have already printed it. In other words, you are reading byte #1 and printing it, but using byte #2. This seems an odd thing to do.
Next, what is this doing?
  while (Wire.available()) {
    c = Wire.read();
  }

You are reading an indefinite number of bytes, and retaining the last one. Why?
Possible rework:
byte fp::readRegister(byte register_address, int numBytes) {
  Wire.requestFrom(register_address, numBytes);
  byte c = Wire.read()
  Serial.println(c);
  Serial.print("0x");
  Serial.print(register_address, HEX);
  Serial.print("\t");
  Serial.print(c);
  Serial.print("\t");
  Serial.println(millis());
  return c;
}

Here is the Git repo with the rest of the code: https://github.com/fpdotmonkey/fp_accel

From your linked code:
  byte xlm = readRegister(fp::OUT_X_L_M, 1);
  byte xhm = readRegister(fp::OUT_X_H_M, 1);
  byte ylm = readRegister(fp::OUT_Y_L_M, 1);
  byte yhm = readRegister(fp::OUT_Y_H_M, 1);
  byte zlm = readRegister(fp::OUT_Z_L_M, 1);
  byte zhm = readRegister(fp::OUT_Z_H_M, 1);

You have the wrong end of the stick here.
  Wire.requestFrom(register_address, numBytes);

You request from the I2C address - that is the device address. The register is something else.
Judging by the datasheet you first have to send the register address, and then request the data. Something along the lines of:
byte fp::readRegister(byte register_address, int numBytes) {
  Wire.beginTransmission (DEVICE_ADDRESS);
  Wire.write (register_address);
  Wire.endTransmission (false);  // repeated start
  Wire.requestFrom(DEVICE_ADDRESS, 1);
  byte c = Wire.read()
  Serial.println(c);
  Serial.print("0x");
  Serial.print(register_address, HEX);
  Serial.print("\t");
  Serial.print(c);
  Serial.print("\t");
  Serial.println(millis());
  return c;
}

Similarly for writing to a register:
void fp::writeRegister(byte register_address, byte val) {
  Wire.beginTransmission(DEVICE_ADDRESS);
  Wire.write (register_address);
  Wire.write(val);
  Wire.endTransmission();
}

This is untested because I don't have the device here, but I know that what you had won't work. To check the actual device address run the I2C scanner I mentioned before.

I'm still experiencing the same problem.  Every register address I plug in returns the same value.

It would help to see the whole sketch and not just a function being called in an unknown way. It would also help to see your improved code. Are you sure you are communicating with the device? Can you do a WHO_AM_I and get back the right response? It's hard to debug a snippet.

Also confirm you have the right device address, and it is connected correctly. There is code to do that on my page about I2C - scroll down to the "I2C scanner".

My codebase, as well as the improved function, are in the Github link that is now in the original question.  When I try to read from WHO_AM_I, I get the same response as from every other register.

Well, see my amended reply. That is not how you access registers.

I've updated the code on Github to have what you've written as well as the address from your program, but I still get the same results.  I thought since the number it returns for every register is 255 that it may be the size of the type byte that is the problem, but I changed the function to return an int, and it did the exact same thing.  I know that the chip is good because I can get other people's libraries to run on it.

Please post the output of running the I2C scanner that I requested.

The first few lines of output, as well as the output of your I2C scanner, are here.  The chip I'm concerned with now is the 0x1D.  The 0x6B is the gyro sensor that's on the same board.

I see I made an error (or retained your error). The line which read Wire.requestFrom(register_address, 1); should have been Wire.requestFrom(DEVICE_ADDRESS, 1);. I fixed up my reply.


text:
Sampling rate issue
I have an Arduino code which runs decently.
// Read in 10-bits Magnetic Encoder AEAT-6010-A06  into Arduino Uno
// Sampling

// Declarate

const int CSn = 4; // Chip select
const int CLK = 7; // Clock signal
const int DO = 8; // Digital Output from the encoder which delivers me a 0 or 1, depending on the bar angle..
int analogPin = 3;
int val = 0;
unsigned int sensorWaarde = 0;

void setup() {
  Serial.begin(115200);
  //Fix de tris

  pinMode(CSn, OUTPUT);
  pinMode(CLK, OUTPUT);
  pinMode(DO, INPUT);

  //Let's start here
  digitalWrite(CLK, HIGH);
  digitalWrite(CSn, HIGH);
}

void loop() {

  val = analogRead(analogPin);
  // val = val - 670;
  sensorWaarde = readSensor();
  delayMicroseconds(1); //Tcs waiting for another read in
}

unsigned int readSensor() {
  unsigned int dataOut = 0;

  digitalWrite(CSn, LOW);
  delayMicroseconds(1); //Waiting for Tclkfe

  //Passing 10 times, from 0 to 9
  for (int x = 0; x < 10; x++) {
    digitalWrite(CLK, LOW);
    delayMicroseconds(1); //Tclk/2
    digitalWrite(CLK, HIGH);
    delayMicroseconds(1); //Tdo valid, like Tclk/2
    dataOut = (dataOut << 1) | digitalRead(DO); //shift all the entering data to the left and past the pin state to it. 1e bit is MSB
  }

  digitalWrite(CSn, HIGH); //
  Serial.print(dataOut);
  Serial.print("");
  Serial.print(" ");
  Serial.println(val);
  Serial.print(" ");

  delay(2);
  return dataOut;

}

From the delay data i assumed that i will be having approximately a sampling rate of 500 Hz, however it seems that the sampling rate is approximately 300+- Hz, without a proper confirmation.
My system is to be run in a Magnetic Encoder by Avago, but i have difficulties determining the sampling rate.
If possible, may i know what code should i use to indicate the time and sampling number?

At 115200 baud your serial prints will take 1/11520 seconds per byte.

Serial.print("");

What does that do?

I count 14 bytes here:
  Serial.print(dataOut);  // 5 bytes, say
  Serial.print("");       // zero bytes, lol
  Serial.print(" ");      // one byte
  Serial.println(val);    // 5 bytes + cr/lf = 7 bytes
  Serial.print(" ");      // 1 byte

Multiply 1/11520 (0.0000868) by 14 and you get 1215 µs.

Now add in your delays:
  delay(2);  // 2000 µs

And this:
 for (int x = 0; x < 10; x++) {
    ...
    delayMicroseconds(1); //Tclk/2
    ...
    delayMicroseconds(1); //Tdo valid, like Tclk/2
  }

Another 20 µs.

  val = analogRead(analogPin);   // 104 µs
  ...
  delayMicroseconds(1); // 1 µs

Total:
1215 + 2000 + 20 + 104 + 1 = 3340 µs

Inverse:
1 / 0.003340 = 299

So yes, I would expect around 299 iterations per second. That isn't counting the time for the other code to execute.

Suggestions

Get rid of the serial prints
Get rid of delay(2)

Wow, there's this kind of calculation. Thanks alot, that really2 helps alot!!! i just added, extra spaces for trial. Thank you


text:
Control servo motors with buttons and via web application
I have this assignment and I have been tinkering a long time about it. I need to make a simulation of a parking lot where servos would represent the ramps.
I will be using 2 Arduinos running the same script, one representing the entry ramp and the other one the exit.
Servos are controlled by reading a json request of an web application and manually by buttons. I have connected two LED's when the buttons are pressed. I would also need to make state when servo would be always up or always down (that would represent the off times of parking lot), should I add extra buttons for that? Any idea would be appreciated.
The problem I'm having with this project is that servos are not responding well on push buttons. They are shaking and very slow moving. And I think that it isn't a good solution to move the servos while they are sending application request because it can lead to conflict. Please help me there.
I have written pretty major piece of script, but it still needs adjusments. Any help is welcomed.
Here is the code:
#include<Servo.h>
#include<Ethernet.h>
#include <SPI.h>

Servo myservo;
byte mac[] = { 0xDE, 0xAD, 0xBE, 0xEF, 0xFE, 0xED };
char server[] = "ramp-rampcontrol.rhcloud.com";
EthernetClient client;
IPAddress ip(192,168,1,17);

int button_5 = 5;
int button_6 = 6;
const int ledPin = 3;
const int ledPinG = 2;
int time = 5*1000;
int val=0;
String content = "";
boolean begin1 = false;

void setup() {

Serial.begin(9600);
pinMode(button_5, INPUT);
pinMode(button_6, INPUT);
pinMode(ledPin, OUTPUT);
pinMode(ledPinG, OUTPUT);
myservo.attach(9);
if (Ethernet.begin(mac) == 0) {
Serial.println("Failed to configure Ethernet using DHCP");
// no point in carrying on, so do nothing forevermore:
// try to congifure using IP address instead of DHCP:
Ethernet.begin(mac, ip);
}
// give the Ethernet shield a second to initialize:
delay(1000);
Serial.println("connecting...");

// if you get a connection, report back via serial:
if (client.connect(server, 80)) {
Serial.println("connected");
// Make a HTTP request:
client.println("GET /api/actions?parking_id=39 HTTP/1.1");
client.println("Host: ramp-rampcontrol.rhcloud.com");
client.println("Connection: close");
client.println();
}
else {
// kf you didn't get a connection to the server:
Serial.println("connection failed");
 }
}

void loop()
{

val = digitalRead(button_5);
if (val == HIGH)
{
  performServoAction("up");

      digitalWrite(ledPin, HIGH);
      delay(1000);
      digitalWrite(ledPin, LOW);
      delay(1000);

}

val = digitalRead(button_6);
if (val == HIGH)
{
  performServoAction("down");

      digitalWrite(ledPinG, HIGH);
      delay(1000);
      digitalWrite(ledPinG, LOW);
      delay(1000);
 }

 while(client.available()) {
 char c = client.read();
    if(c == '{'){
      begin1 = true;
    }

  if (begin1) {
    content += c;
   }

  if (c == '}') {
      break;
    }
 }

  if (!client.connected()) {
    Serial.println();
    Serial.println("disconnecting.");
    client.stop();
    performAction();
  }
  }

bool performServoAction(String action_type) {
if (action_type == "up") {
    Serial.println("doing up");
    myservo.write(95);
    delay(time);
   // lastRampStatus = action_type ;
   // notifyServerAboutAction("true", action_id);
    return true;
  }

  if (action_type == "down") {
    Serial.println("doing down");
    myservo.write(135);
    delay(time);
    //lastRampStatus = action_type;
  // notifyServerAboutAction("true", action_id);
    return true;
  }
}

 void performAction() {
  int nstart = content.indexOf("action_id") + 12;
  int nend = content.indexOf(",", nstart);
  String actionID = content.substring(nstart, nend);

    int nstart1 = content.indexOf("action_type") + 14;
   //Get position of "action_type" in a string, increment by 13
    (length of 'action_type":"')
    int nend1 = content.indexOf("\"", nstart1); // Get next position
    of '"' starting from nstart
    String actionType = content.substring(nstart1, nend1);
    //Return substring between this position
    performServoAction(actionType);
    Serial.println(nstart1);
    Serial.println(nend1);
    Serial.println(actionID);
    Serial.println(actionType);
    Serial.println(content);
}

Do the servos behave when moving after receiving the json command? You have the program waiting for 5 seconds after the servo is told to move 'up' or 'down' -  I don't see where a conflict could creep in to cause the servos to move slowly.

They just vibrate, and they dont react to the push buttons. I'm starting to think that it may be a hardware problem.

I would start with just some servo example sketches and make sure you haven't made a simple mistake. It happens to us all.

Yeah sounds like the problem is servo issue just play with a servo example and then expand.

Instead of using:
myservo.write(135);
You should use:
myservo.writeMicroseconds();
https://www.arduino.cc/en/Reference/ServoWriteMicroseconds


text:
Why when I press the reset button
Why when I press the reset button it takes 2 second before I see my sketch start?
The model of Arduino is UNO, and the text in serial communication.

This is not a particularly helpful question. Reset button on what Arduino model? What is "some time"? A second? A minute? What is "output"? Text in the serial monitor? An LED flashing?

The model of Arduino is UNO and it takes 2-3 second and the text in the serial monitor. The output is the Sketch. I will say the question again Why when I press the reset button it takes 2 second before my Sketch stast?

Please edit your question to improve it with this new information. The question should stand on its own without having to skim through the comments. Thanks! And welcome to Arduino StackExchange. :)

Because first the bootloader is executed and takes 2 seconds (or more on a Leonardo) to time out when it doesn't receive a proper response from the computer.

You can set the fuses on the processor to not run the bootloader, in which case it will start a lot faster. However uploading sketches then is harder, as you have to use ICSP programming to do that.

Thanks for replay, but can tell me the reason of why it takes some time to start sketch ?

Because first the bootloader is executed and takes 2 seconds (or more on a Leonardo) to time out when it doesn't receive a proper response from the computer.