message:
Grove sensors without a Grove shield

There exists a large variety of sensors in the [Grove System][1]. Usually these are accessed via a special shield (Grove base shield).

Can I access these sensor directly without a shield. In particular I am interested in using them with an Arduino Pro Mini. My guess is that one definitely needs the 5V version of the Mini, but other than this? How fiddly is it to use these sensors directly?

I am interested in using the [Grove dust sensor][2], but I am also would like to operate a [Grove 4 digit display][3].

  [1]: http://www.seeedstudio.com/wiki/GROVE_System
  [2]: http://www.seeedstudio.com/wiki/Grove_-_Dust_Sensor
  [3]: http://www.seeedstudio.com/wiki/Grove_-_4-Digit_Display

body:
Grove sensors use a special socket, a 4 pin JST with two power lines and two data. you would have to make your own board/terminal to get them to connect to a mini.

What you could do is use a [Grove proto board](http://www.seeedstudio.com/wiki/Grove_-_Protoshield), which converts the JST terminals onto .1" pins suitable for connecting to the Mini. There is also a litle proto area if you want it.

You could also use an [adapter cable](http://www.seeedstudio.com/depot/grove-to-4-pin-254-female-jumper-wire5-pcs-pack-p-1020.html?cPath=178_179), which would not have a bulky protoboard along with it. The terminals could be soldered directly to the Mini.


sender: user

sender: assistant

body:
![Groove Schematic][1]
*[From the wiki](http://www.seeedstudio.com/wiki/File:Stem-diagram-sign.jpg)*.

Above is a schematic of a Groove shield. You can see that each of the connectors has two digital pins connected to it and then V (5V) and G (GND). The last two you can connect normally to an Arduino. The first two you connect to the pins that are used in your sketch.

Say it says to connect the connector to the top left DIGITAL pin on the board (D6/D7). You'll 7want to connect the pins as followed: Black → GND, Red → 5V, White → D7, and Yellow → D6.
****
Notes:

 - The shield overlaps the pins (i.e. 3-4, 4-5), so that might make things confusing. I think that is a design flaw. If it needs two pins, *it should have two connectors*. In the current state, you can connect two things together. **I don't really know how to figure out if it uses all of the ports attached or not. If you don't have to, I would try not to overlap any two grooves.** You would do this by using two digital ports for every groove "module."
 - **You'll also need to have a [adapter cable](http://www.seeedstudio.com/depot/grove-to-4-pin-254-female-jumper-wire5-pcs-pack-p-1020.html?cPath=178_179) (Link from *TheDoctor's* Answer.)**
 - For analog connections, it applies the same way as digital. G is ground, V is 5v, and A# is an analog pin.

****
## Inferencing it:
There's no real cookie cutter way to connect to them. However, the [wiki](http://www.seeedstudio.com/wiki/GROVE_System) seems to be a decent resource once you figure out how to navigate it. The [dust sensor you mentioned](http://www.seeedstudio.com/wiki/Grove_-_Dust_Sensor) seems to ONLY use digital pin 8. It was connected to the D7/D8 connector on the Groove shield, so the yellow wire could be ignored since it was never used in the sketch.

It's hard to do much with this system: it's poorly documented and not uniform at all. Plus, some boards could cause problems that could even lead to damaging components. I would say look at something else.

 - [This dust sensor](https://www.sparkfun.com/products/9689) seems pretty good, minus the documentation. On [this blog](https://www.sparkfun.com/products/9689), they say to do this:

> Sharp pin 1 (V-LED)   => 5V (connected to 150ohm resister) Sharp pin 2
>
> (LED-GND) => Arduino GND pin Sharp pin 3 (LED)     => Arduino pin 2
>
> Sharp pin 4 (S-GND)   => Arduino GND pin Sharp pin 5 (Vo)      =>
>
> Arduino A0 pin Sharp pin 6 (Vcc)     => 5V

I can't seem to find the cord for it, but I'm sure there are many others like this online. (It lists the cable needed: a 6-pin, 1.5mm pitch connector. That doesn't seem too hard to find).

 - Here is a [4x7 segment display](https://www.sparkfun.com/products/9483) for much cheaper. It does use a lot of pins and need resistors, but multiplexing and resistors aren't that hard to figure out. That's outside of the scope of this question. There might be some other board with a built in IC for controlling a display like that, but I can't seem to find one now.

  [1]: https://i.stack.imgur.com/vxc2g.jpg


body: I'm pretty sure you could just take the signal cable from the dust sensor and plug it directly into your mcu digital pin of choice and then wire the Vcc and Gnd as well.  I'm working with a CO2 sensor and don't really want the shield overhead.


message:
Is my Arduino dead or is it just its processor?

I have a problem with my Arduino. I can't upload any sketches to it (it gives me the error `avrdude: verification error; content mismatch`), but the LEDs are still blinking. Do you think that the whole Arduino is dead or is it just the chip ?

EDIT : I tried an other USB cable but it changed nothing.

EDIT : Here is the output of verbose mode while uploading :

    Taille binaire du croquis : 1 084 octets (d'un max de 32 256 octets)
    /Applications/Arduino.app/Contents/Resources/Java/hardware/tools/avr/bin/avrdude -C/Applications/Arduino.app/Contents/Resources/Java/hardware/tools/avr/etc/avrdude.conf -v -v -v -v -patmega328p -carduino -P/dev/cu.usbmodem641 -b115200 -D -Uflash:w:/var/folders/56/7b6d3xm14n31kjrw8609ywjw0000gn/T/build1168987322216849272.tmp/Blink.cpp.hex:i

    avrdude: Version 5.11, compiled on Sep  2 2011 at 18:52:52
             Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
             Copyright (c) 2007-2009 Joerg Wunsch

             System wide configuration file is "/Applications/Arduino.app/Contents/Resources/Java/hardware/tools/avr/etc/avrdude.conf"
             User configuration file is "/Users/trevorannedenise/.avrduderc"
             User configuration file does not exist or is not a regular file, skipping

             Using Port                    : /dev/cu.usbmodem641
             Using Programmer              : arduino
             Overriding Baud Rate          : 115200
    avrdude: Send: 0 [30]   [20]
    avrdude: Send: 0 [30]   [20]
    avrdude: Send: 0 [30]   [20]
    avrdude: Recv: . [14]
    avrdude: Recv: . [10]
             AVR Part                      : ATMEGA328P
             Chip Erase delay              : 9000 us
             PAGEL                         : PD7
             BS2                           : PC2
             RESET disposition             : dedicated
             RETRY pulse                   : SCK
             serial program mode           : yes
             parallel program mode         : yes
             Timeout                       : 200
             StabDelay                     : 100
             CmdexeDelay                   : 25
             SyncLoops                     : 32
             ByteDelay                     : 0
             PollIndex                     : 3
             PollValue                     : 0x53
             Memory Detail                 :

                                      Block Poll               Page                       Polled
               Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
               ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
               eeprom        65    20     4    0 no       1024    4      0  3600  3600 0xff 0xff
                                      Block Poll               Page                       Polled
               Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
               ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
               flash         65     6   128    0 yes     32768  128    256  4500  4500 0xff 0xff
                                      Block Poll               Page                       Polled
               Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
               ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
               lfuse          0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
                                      Block Poll               Page                       Polled
               Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
               ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
               hfuse          0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
                                      Block Poll               Page                       Polled
               Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
               ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
               efuse          0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
                                      Block Poll               Page                       Polled
               Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
               ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
               lock           0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
                                      Block Poll               Page                       Polled
               Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
               ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
               calibration    0     0     0    0 no          1    0      0     0     0 0x00 0x00
                                      Block Poll               Page                       Polled
               Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
               ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
               signature      0     0     0    0 no          3    0      0     0     0 0x00 0x00

             Programmer Type : Arduino
             Description     : Arduino
    avrdude: Send: A [41] . [80]   [20]
    avrdude: Recv: . [14]
    avrdude: Recv: . [03]
    avrdude: Recv: . [10]
    avrdude: Send: A [41] . [81]   [20]
    avrdude: Recv: . [14]
    avrdude: Recv: . [04]
    avrdude: Recv: . [10]
    avrdude: Send: A [41] . [82]   [20]
    avrdude: Recv: . [14]
    avrdude: Recv: . [04]
    avrdude: Recv: . [10]
    avrdude: Send: A [41] . [98]   [20]
    avrdude: Recv: . [14]
    avrdude: Recv: . [03]
    avrdude: Recv: . [10]
             Hardware Version: 3
             Firmware Version: 4.4
    avrdude: Send: A [41] . [84]   [20]
    avrdude: Recv: . [14]
    avrdude: Recv: . [03]
    avrdude: Recv: . [10]
    avrdude: Send: A [41] . [85]   [20]
    avrdude: Recv: . [14]
    avrdude: Recv: . [03]
    avrdude: Recv: . [10]
    avrdude: Send: A [41] . [86]   [20]
    avrdude: Recv: . [14]
    avrdude: Recv: . [03]
    avrdude: Recv: . [10]
    avrdude: Send: A [41] . [87]   [20]
    avrdude: Recv: . [14]
    avrdude: Recv: . [03]
    avrdude: Recv: . [10]
    avrdude: Send: A [41] . [89]   [20]
    avrdude: Recv: . [14]
    avrdude: Recv: . [03]
    avrdude: Recv: . [10]
             Vtarget         : 0.3 V
             Varef           : 0.3 V
             Oscillator      : 28.800 kHz
             SCK period      : 3.3 us

    avrdude: Send: A [41] . [81]   [20]
    avrdude: Recv: . [14]
    avrdude: Recv: . [04]
    avrdude: Recv: . [10]
    avrdude: Send: A [41] . [82]   [20]
    avrdude: Recv: . [14]
    avrdude: Recv: . [04]
    avrdude: Recv: . [10]
    avrdude: Send: B [42] . [86] . [00] . [00] . [01] . [01] . [01] . [01] . [03] . [ff] . [ff] . [ff] . [ff] . [00] . [80] . [04] . [00] . [00] . [00] . [80] . [00]   [20]
    avrdude: Recv: . [14]
    avrdude: Recv: . [10]
    avrdude: Send: E [45] . [05] . [04] . [d7] . [c2] . [00]   [20]
    avrdude: Recv: . [14]
    avrdude: Recv: . [10]
    avrdude: Send: P [50]   [20]
    avrdude: Recv: . [14]
    avrdude: Recv: . [10]
    avrdude: AVR device initialized and ready to accept instructions

    Reading | avrdude: Send: u [75]   [20]
    avrdude: Recv: . [14] . [1e] . [95] . [0f] . [10]
    ################################################## | 100% 0.00s

    avrdude: Device signature = 0x1e950f
    avrdude: Send: V [56] . [a0] . [03] . [fc] . [00]   [20]
    avrdude: Recv: . [14]
    avrdude: Recv: . [00]
    avrdude: Recv: . [10]
    avrdude: Send: V [56] . [a0] . [03] . [fd] . [00]   [20]
    avrdude: Recv: . [14]
    avrdude: Recv: . [00]
    avrdude: Recv: . [10]
    avrdude: Send: V [56] . [a0] . [03] . [fe] . [00]   [20]
    avrdude: Recv: . [14]
    avrdude: Recv: . [00]
    avrdude: Recv: . [10]
    avrdude: Send: V [56] . [a0] . [03] . [ff] . [00]   [20]
    avrdude: Recv: . [14]
    avrdude: Recv: . [00]
    avrdude: Recv: . [10]
    avrdude: reading input file "/var/folders/56/7b6d3xm14n31kjrw8609ywjw0000gn/T/build1168987322216849272.tmp/Blink.cpp.hex"
    avrdude: writing flash (1084 bytes):

    Writing | avrdude: Send: U [55] . [00] . [00]   [20]
    avrdude: Recv: . [14]
    avrdude: Recv: . [10]
    avrdude: Send: d [64] . [00] . [80] F [46] . [0c] . [94] a [61] . [00] . [0c] . [94] ~ [7e] . [00] . [0c] . [94] ~ [7e] . [00] . [0c] . [94] ~ [7e] . [00] . [0c] . [94] ~ [7e] . [00] . [0c] . [94] ~ [7e] . [00] . [0c] . [94] ~ [7e] . [00] . [0c] . [94] ~ [7e] . [00] . [0c] . [94] ~ [7e] . [00] . [0c] . [94] ~ [7e] . [00] . [0c] . [94] ~ [7e] . [00] . [0c] . [94] ~ [7e] . [00] . [0c] . [94] ~ [7e] . [00] . [0c] . [94] ~ [7e] . [00] . [0c] . [94] ~ [7e] . [00] . [0c] . [94] ~ [7e] . [00] . [0c] . [94] . [9d] . [00] . [0c] . [94] ~ [7e] . [00] . [0c] . [94] ~ [7e] . [00] . [0c] . [94] ~ [7e] . [00] . [0c] . [94] ~ [7e] . [00] . [0c] . [94] ~ [7e] . [00] . [0c] . [94] ~ [7e] . [00] . [0c] . [94] ~ [7e] . [00] . [0c] . [94] ~ [7e] . [00] . [0c] . [94] ~ [7e] . [00] . [00] . [00] . [00] . [00] $ [24] . [00] ' [27] . [00] * [2a] . [00] . [00] . [00] . [00] . [00] % [25] . [00] ( [28] . [00] + [2b] . [00] . [00] . [00] . [00] . [00]   [20]
    avrdude: Recv: . [14]
    avrdude: Recv: . [10]
    #####avrdude: Send: U [55] @ [40] . [00]   [20]
    avrdude: Recv: . [14]
    avrdude: Recv: . [10]
    avrdude: Send: d [64] . [00] . [80] F [46] # [23] . [00] & [26] . [00] ) [29] . [00] . [04] . [04] . [04] . [04] . [04] . [04] . [04] . [04] . [02] . [02] . [02] . [02] . [02] . [02] . [03] . [03] . [03] . [03] . [03] . [03] . [01] . [02] . [04] . [08] . [10]   [20] @ [40] . [80] . [01] . [02] . [04] . [08] . [10]   [20] . [01] . [02] . [04] . [08] . [10]   [20] . [00] . [00] . [00] . [07] . [00] . [02] . [01] . [00] . [00] . [03] . [04] . [06] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [11] $ [24] . [1f] . [be] . [cf] . [ef] . [d8] . [e0] . [de] . [bf] . [cd] . [bf] . [11] . [e0] . [a0] . [e0] . [b1] . [e0] . [ea] . [e3] . [f4] . [e0] . [02] . [c0] . [05] . [90] . [0d] . [92] . [a2] 0 [30] . [b1] . [07] . [d9] . [f7] . [11] . [e0] . [a2] . [e0] . [b1] . [e0] . [01] . [c0] . [1d] . [92] . [ab] 0 [30] . [b1] . [07] . [e1] . [f7] . [0e] . [94] . [0c] . [02] . [0c] . [94] . [1b] . [02] . [0c] . [94] . [00] . [00]   [20]
    avrdude: Recv: . [14]
    avrdude: Recv: . [10]
    ######avrdude: Send: U [55] . [80] . [00]   [20]
    avrdude: Recv: . [14]
    avrdude: Recv: . [10]
    avrdude: Send: d [64] . [00] . [80] F [46] . [80] . [91] . [00] . [01] a [61] . [e0] . [0e] . [94] . [b8] . [01] h [68] . [ee] s [73] . [e0] . [80] . [e0] . [90] . [e0] . [0e] . [94] . [e5] . [00] . [80] . [91] . [00] . [01] ` [60] . [e0] . [0e] . [94] . [b8] . [01] h [68] . [ee] s [73] . [e0] . [80] . [e0] . [90] . [e0] . [0e] . [94] . [e5] . [00] . [08] . [95] . [80] . [91] . [00] . [01] a [61] . [e0] . [0e] . [94] y [79] . [01] . [08] . [95] . [1f] . [92] . [0f] . [92] . [0f] . [b6] . [0f] . [92] . [11] $ [24] / [2f] . [93] ? [3f] . [93] . [8f] . [93] . [9f] . [93] . [af] . [93] . [bf] . [93] . [80] . [91] . [06] . [01] . [90] . [91] . [07] . [01] . [a0] . [91] . [08] . [01] . [b0] . [91] . [09] . [01] 0 [30] . [91] . [0a] . [01] . [01] . [96] . [a1] . [1d] . [b1] . [1d] # [23] / [2f] - [2d] _ [5f] - [2d] 7 [37]   [20] . [f0] - [2d] W [57] . [01] . [96] . [a1] . [1d] . [b1] . [1d]   [20] . [93] . [0a] . [01] . [80] . [93]   [20]
    avrdude: Recv: . [14]
    avrdude: Recv: . [10]
    ######avrdude: Send: U [55] . [c0] . [00]   [20]
    avrdude: Recv: . [14]
    avrdude: Recv: . [10]
    avrdude: Send: d [64] . [00] . [80] F [46] . [06] . [01] . [90] . [93] . [07] . [01] . [a0] . [93] . [08] . [01] . [b0] . [93] . [09] . [01] . [80] . [91] . [02] . [01] . [90] . [91] . [03] . [01] . [a0] . [91] . [04] . [01] . [b0] . [91] . [05] . [01] . [01] . [96] . [a1] . [1d] . [b1] . [1d] . [80] . [93] . [02] . [01] . [90] . [93] . [03] . [01] . [a0] . [93] . [04] . [01] . [b0] . [93] . [05] . [01] . [bf] . [91] . [af] . [91] . [9f] . [91] . [8f] . [91] ? [3f] . [91] / [2f] . [91] . [0f] . [90] . [0f] . [be] . [0f] . [90] . [1f] . [90] . [18] . [95] . [9b] . [01] . [ac] . [01] . [7f] . [b7] . [f8] . [94] . [80] . [91] . [02] . [01] . [90] . [91] . [03] . [01] . [a0] . [91] . [04] . [01] . [b0] . [91] . [05] . [01] f [66] . [b5] . [a8] . [9b] . [05] . [c0] o [6f] ? [3f] . [19] . [f0] . [01] . [96] . [a1] . [1d] . [b1] . [1d] . [7f] . [bf] . [ba] / [2f] . [a9] / [2f] . [98] / [2f] . [88] ' [27] . [86] . [0f] . [91] . [1d]   [20]
    avrdude: Recv: . [14]
    avrdude: Recv: . [10]
    ######avrdude: Send: U [55] . [00] . [01]   [20]
    avrdude: Recv: . [14]
    avrdude: Recv: . [10]
    avrdude: Send: d [64] . [00] . [80] F [46] . [a1] . [1d] . [b1] . [1d] b [62] . [e0] . [88] . [0f] . [99] . [1f] . [aa] . [1f] . [bb] . [1f] j [6a] . [95] . [d1] . [f7] . [bc] . [01] - [2d] . [c0] . [ff] . [b7] . [f8] . [94] . [80] . [91] . [02] . [01] . [90] . [91] . [03] . [01] . [a0] . [91] . [04] . [01] . [b0] . [91] . [05] . [01] . [e6] . [b5] . [a8] . [9b] . [05] . [c0] . [ef] ? [3f] . [19] . [f0] . [01] . [96] . [a1] . [1d] . [b1] . [1d] . [ff] . [bf] . [ba] / [2f] . [a9] / [2f] . [98] / [2f] . [88] ' [27] . [8e] . [0f] . [91] . [1d] . [a1] . [1d] . [b1] . [1d] . [e2] . [e0] . [88] . [0f] . [99] . [1f] . [aa] . [1f] . [bb] . [1f] . [ea] . [95] . [d1] . [f7] . [86] . [1b] . [97] . [0b] . [88] ^ [5e] . [93] @ [40] . [c8] . [f2] ! [21] P [50] 0 [30] @ [40] @ [40] @ [40] P [50] @ [40] h [68] Q [51] | [7c] O [4f] ! [21] . [15] 1 [31] . [05] A [41] . [05] Q [51] . [05] q [71] . [f6] . [08] . [95] x [78] . [94] . [84] . [b5]   [20]
    avrdude: Recv: . [14]
    avrdude: Recv: . [10]
    ######avrdude: Send: U [55] @ [40] . [01]   [20]
    avrdude: Recv: . [14]
    avrdude: Recv: . [10]
    avrdude: Send: d [64] . [00] . [80] F [46] . [82] ` [60] . [84] . [bd] . [84] . [b5] . [81] ` [60] . [84] . [bd] . [85] . [b5] . [82] ` [60] . [85] . [bd] . [85] . [b5] . [81] ` [60] . [85] . [bd] . [ee] . [e6] . [f0] . [e0] . [80] . [81] . [81] ` [60] . [80] . [83] . [e1] . [e8] . [f0] . [e0] . [10] . [82] . [80] . [81] . [82] ` [60] . [80] . [83] . [80] . [81] . [81] ` [60] . [80] . [83] . [e0] . [e8] . [f0] . [e0] . [80] . [81] . [81] ` [60] . [80] . [83] . [e1] . [eb] . [f0] . [e0] . [80] . [81] . [84] ` [60] . [80] . [83] . [e0] . [eb] . [f0] . [e0] . [80] . [81] . [81] ` [60] . [80] . [83] . [ea] . [e7] . [f0] . [e0] . [80] . [81] . [84] ` [60] . [80] . [83] . [80] . [81] . [82] ` [60] . [80] . [83] . [80] . [81] . [81] ` [60] . [80] . [83] . [80] . [81] . [80] h [68] . [80] . [83] . [10] . [92] . [c1] . [00] . [08] . [95] . [cf] . [93] . [df] . [93] H [48] / [2f] P [50] . [e0] . [ca] . [01] . [86] V [56] . [9f] O [4f]   [20]
    avrdude: Recv: . [14]
    avrdude: Recv: . [10]
    ######avrdude: Send: U [55] . [80] . [01]   [20]
    avrdude: Recv: . [14]
    avrdude: Recv: . [10]
    avrdude: Send: d [64] . [00] . [80] F [46] . [fc] . [01] 4 [34] . [91] J [4a] W [57] _ [5f] O [4f] . [fa] . [01] . [84] . [91] . [88] # [23] i [69] . [f1] . [90] . [e0] . [88] . [0f] . [99] . [1f] . [fc] . [01] . [e8] Y [59] . [ff] O [4f] . [a5] . [91] . [b4] . [91] . [fc] . [01] . [ee] X [58] . [ff] O [4f] . [c5] . [91] . [d4] . [91] f [66] # [23] Q [51] . [f4] / [2f] . [b7] . [f8] . [94] . [8c] . [91] . [93] / [2f] . [90] . [95] . [89] # [23] . [8c] . [93] . [88] . [81] . [89] # [23] . [0b] . [c0] b [62] 0 [30] a [61] . [f4] / [2f] . [b7] . [f8] . [94] . [8c] . [91] . [93] / [2f] . [90] . [95] . [89] # [23] . [8c] . [93] . [88] . [81] . [83] + [2b] . [88] . [83] / [2f] . [bf] . [06] . [c0] . [9f] . [b7] . [f8] . [94] . [8c] . [91] . [83] + [2b] . [8c] . [93] . [9f] . [bf] . [df] . [91] . [cf] . [91] . [08] . [95] H [48] / [2f] P [50] . [e0] . [ca] . [01] . [82] U [55] . [9f] O [4f] . [fc] . [01] $ [24] . [91] . [ca] . [01]   [20]
    avrdude: Recv: . [14]
    avrdude: Recv: . [10]
    ######avrdude: Send: U [55] . [c0] . [01]   [20]
    avrdude: Recv: . [14]
    avrdude: Recv: . [10]
    avrdude: Send: d [64] . [00] . [80] F [46] . [86] V [56] . [9f] O [4f] . [fc] . [01] . [94] . [91] J [4a] W [57] _ [5f] O [4f] . [fa] . [01] 4 [34] . [91] 3 [33] # [23] . [09] . [f4] @ [40] . [c0] " [22] # [23] Q [51] . [f1] # [23] 0 [30] q [71] . [f0] $ [24] 0 [30] ( [28] . [f4] ! [21] 0 [30] . [a1] . [f0] " [22] 0 [30] . [11] . [f5] . [14] . [c0] & [26] 0 [30] . [b1] . [f0] ' [27] 0 [30] . [c1] . [f0] $ [24] 0 [30] . [d9] . [f4] . [04] . [c0] . [80] . [91] . [80] . [00] . [8f] w [77] . [03] . [c0] . [80] . [91] . [80] . [00] . [8f] } [7d] . [80] . [93] . [80] . [00] . [10] . [c0] . [84] . [b5] . [8f] w [77] . [02] . [c0] . [84] . [b5] . [8f] } [7d] . [84] . [bd] . [09] . [c0] . [80] . [91] . [b0] . [00] . [8f] w [77] . [03] . [c0] . [80] . [91] . [b0] . [00] . [8f] } [7d] . [80] . [93] . [b0] . [00] . [e3] / [2f] . [f0] . [e0] . [ee] . [0f] . [ff] . [1f] . [ee] X [58] . [ff] O [4f] . [a5] . [91] . [b4] . [91] / [2f] . [b7]   [20]
    avrdude: Recv: . [14]
    avrdude: Recv: . [10]
    ######avrdude: Send: U [55] . [00] . [02]   [20]
    avrdude: Recv: . [14]
    avrdude: Recv: . [10]
    avrdude: Send: d [64] . [00] < [3c] F [46] . [f8] . [94] f [66] # [23] ! [21] . [f4] . [8c] . [91] . [90] . [95] . [89] # [23] . [02] . [c0] . [8c] . [91] . [89] + [2b] . [8c] . [93] / [2f] . [bf] . [08] . [95] . [cf] . [93] . [df] . [93] . [0e] . [94] > [3e] . [01] . [0e] . [94] . [97] . [00] . [c0] . [e0] . [d0] . [e0] . [0e] . [94] . [80] . [00]   [20] . [97] . [e1] . [f3] . [0e] . [94] . [00] . [00] . [f9] . [cf] . [f8] . [94] . [ff] . [cf] . [0d] . [00]   [20]
    avrdude: Recv: . [14]
    avrdude: Recv: . [10]
    ### | 100% 0.21s

    avrdude: 1084 bytes of flash written
    avrdude: verifying flash memory against /var/folders/56/7b6d3xm14n31kjrw8609ywjw0000gn/T/build1168987322216849272.tmp/Blink.cpp.hex:
    avrdude: load data flash data from input file /var/folders/56/7b6d3xm14n31kjrw8609ywjw0000gn/T/build1168987322216849272.tmp/Blink.cpp.hex:
    avrdude: input file /var/folders/56/7b6d3xm14n31kjrw8609ywjw0000gn/T/build1168987322216849272.tmp/Blink.cpp.hex contains 1084 bytes
    avrdude: reading on-chip flash data:

    Reading | avrdude: Send: U [55] . [00] . [00]   [20]
    avrdude: Recv: . [14]
    avrdude: Recv: . [10]
    avrdude: Send: t [74] . [00] . [80] F [46]   [20]
    avrdude: Recv: . [14]
    avrdude: Recv: . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff]
    avrdude: Recv: . [10]
    #####avrdude: Send: U [55] @ [40] . [00]   [20]
    avrdude: Recv: . [14]
    avrdude: Recv: . [10]
    avrdude: Send: t [74] . [00] . [80] F [46]   [20]
    avrdude: Recv: . [14]
    avrdude: Recv: . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff]
    avrdude: Recv: . [10]
    ######avrdude: Send: U [55] . [80] . [00]   [20]
    avrdude: Recv: . [14]
    avrdude: Recv: . [10]
    avrdude: Send: t [74] . [00] . [80] F [46]   [20]
    avrdude: Recv: . [14]
    avrdude: Recv: . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff]
    avrdude: Recv: . [10]
    ######avrdude: Send: U [55] . [c0] . [00]   [20]
    avrdude: Recv: . [14]
    avrdude: Recv: . [10]
    avrdude: Send: t [74] . [00] . [80] F [46]   [20]
    avrdude: Recv: . [14]
    avrdude: Recv: . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff]
    avrdude: Recv: . [10]
    ######avrdude: Send: U [55] . [00] . [01]   [20]
    avrdude: Recv: . [14]
    avrdude: Recv: . [10]
    avrdude: Send: t [74] . [00] . [80] F [46]   [20]
    avrdude: Recv: . [14]
    avrdude: Recv: . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff]
    avrdude: Recv: . [10]
    ######avrdude: Send: U [55] @ [40] . [01]   [20]
    avrdude: Recv: . [14]
    avrdude: Recv: . [10]
    avrdude: Send: t [74] . [00] . [80] F [46]   [20]
    avrdude: Recv: . [14]
    avrdude: Recv: . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff]
    avrdude: Recv: . [10]
    ######avrdude: Send: U [55] . [80] . [01]   [20]
    avrdude: Recv: . [14]
    avrdude: Recv: . [10]
    avrdude: Send: t [74] . [00] . [80] F [46]   [20]
    avrdude: Recv: . [14]
    avrdude: Recv: . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff]
    avrdude: Recv: . [10]
    ######avrdude: Send: U [55] . [c0] . [01]   [20]
    avrdude: Recv: . [14]
    avrdude: Recv: . [10]
    avrdude: Send: t [74] . [00] . [80] F [46]   [20]
    avrdude: Recv: . [14]
    avrdude: Recv: . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff]
    avrdude: Recv: . [10]
    ######avrdude: Send: U [55] . [00] . [02]   [20]
    avrdude: Recv: . [14]
    avrdude: Recv: . [10]
    avrdude: Send: t [74] . [00] < [3c] F [46]   [20]
    avrdude: Recv: . [14]
    avrdude: Recv: . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff]
    avrdude: Recv: . [10]
    ### | 100% 0.16s

    avrdude: verifying ...
    avrdude: verification error, first mismatch at byte 0x0000
             0x0c != 0xff
    avrdude: verification error; content mismatch
    avrdude: Send: Q [51]   [20]
    avrdude: Recv: . [14]
    avrdude: Recv: . [10]

    avrdude done.  Thank you.

body:
It's possible you have a non-fatal problem

 - check power
 - check connections
 - reflash the Arduino bootloader

If your Arduino has a socketed microcontroller you can try swapping it out with one that has the bootloader preloaded.


body:
I've faced this problem several times!
If you are using arduino UNO, make sure to remove any serial connected device on the (Tx,RX) pins. Upload your sketch, then connect them back again.
It's because the arduino UNO has on serial pins which is used for uploading the code, there will be a conflict if there was a device that is connected to the serial the same time you upload the code.


body:
This happened to me with a bare-bones Arduino. I disconnected everything and it still happens. I don't know what the cause is but you definitely will need to reflash the bootloader or replace the chip.

It isn't a connection or power issue, and it isn't related to having devices connected to pins 0/1 (although that can also cause problems, it will give a different error).


body: I had faced similar problems and the solution that worked for me was to power the burning circuit with the Arduino onboard 5 volt. 3.3 Volt does work but at times it gives these errors especially while burning the bootloader.


message:
Arduino motor shield orange/white pin usage

I have an Arduino motor shield like this one plugged into my Mega board.

![Arduino motor shield][1]

I would like to know some more information about the orange and white pin blocks on the board. The [Arduino website][2] has the following information, but it doesn't give any explanation of what is best to use them for or which pins are mapped to the data pins etc.

 - TinkerKit connectors for two Analog Inputs (in white), connected to A2 and A3.
 - TinkerKit connectors for two Aanlog Outputs (in orange in the middle), connected to PWM outputs on pins D5 and D6.
 - TinkerKit connectors for the TWI interface (in white with 4 pins), one for input and the other one for output.

What I want to do is connect a servo up to the board and was hoping I could use one of the orange `OUT` blocks. I haven't been successful in finding any examples of this which leaves me in doubt as to whether it is possible or not. I would just plug it in, but I'm afraid of frying the shield/mega/servo. Probably an irrational fear, but I can't afford another one of any at the moment!

I don't know which pins in the block are assigned to the data, vcc and out, so if anyone know I would be grateful for the answer.

Also, just because it is annoying not to understand, what are the `TWI` connectors for?

I hope this isn't too general a question as I could really use some answers!

  [1]: https://i.stack.imgur.com/cKBqi.jpg
  [2]: http://arduino.cc/en/Main/ArduinoMotorShieldR3#.UxXT9vl_skI

body:
> I don't know which pins in the block are assigned to the data, vcc and
> out, so if anyone know I would be grateful for the answer.

Following the example on [TinkerKit's Custom Distance Sensor][1] page, we see that:

> If you look on the edge of the sensor, you can see the three pins,
> that are power (5V), ground and signal. The same as your TinkerKit!
> modules, just in a different order.
>
> The only difference is that the signal and ground cable are inverted.

So the order in the connector is Vcc Signal Ground.

Another way, and what I would do to be 100% sure, is measure resistance with a multimeter. If your meter has a continuity test feature, that's even better because it'll beep.

Anyway, put one end of the probe on pin 1 of the connector and the other end on GND and see if the resistance is very close to 0 ohms. If it's reading OL (Over-Limit) then that pin is not GND.

Put the probe on Vcc instead and it should show 0 ohm or beep. So now you know that pin is Vcc.

Do the same for the other pins and find out which one is ground. The third pin is your PWM output. It's connected to D5 or D6, check the continuity on those pins to see which one.

  [1]: http://www.tinkerkit.com/custom-distance-sensor/


body:
>...which pins are mapped to the data pins etc.

The shield page provides a [schematic](http://arduino.cc/en/uploads/Main/arduino_MotorShield_Rev3-schematic.pdf)

>I would like to know some more information about the orange and white pin blocks on the board

These have the reference printed on the board
![enter image description here][1]

----------

# TWI IN and TWI OUT #
They are the same and are both connected to the same I2C pins of Arduino (SCL, SDA). They are intended to help in case you want to connect more than one device.
![enter image description here][4]

----------

# OUT 5, OUT 6 #
Connected to Arduino pins 5 and 6 (PWM outputs)

![enter image description here][2]

----------

# IN 2, IN 3 #
Connected to Analog in A2 and A3

![enter image description here][3]

----------

The power outputs of [L298](http://www.st.com/st-web-ui/static/active/en/resource/technical/document/datasheet/CD00000240.pdf) intended to drive the motor are the blue screw connectors.

![enter image description here][5]

  [1]: https://i.stack.imgur.com/H7mnt.jpg
  [2]: https://i.stack.imgur.com/5YY7w.jpg
  [3]: https://i.stack.imgur.com/AK2nq.jpg
  [4]: https://i.stack.imgur.com/bAIkc.jpg
  [5]: https://i.stack.imgur.com/9zRaY.jpg


body:
You can use Thinkerkit pins(out ~5 and ~6) for controlling servos. Just need to do a bit of tweaking here. Hobby servo motors have got 3 pins orange(signal) , red(live+) in the middle, and brown(gnd-). But, the motor shield rev3 uses the middle pin for signal. To overcome this problem, swap the middle wire with the orange one on the servo plug.

There are three small latches that prevent wires coming out of the plug, use the tip of a needle and with little force slightly lift them up then pull out the wires from the servo plug, they should come off easily.

Remember to attach pin 5 or 6 in the arduino code. I used servo.h library.


body: Although the 'Orange' (Out) pins of the Deek-Robot Motor Shield can be used to drive a servo by swapping the '+5vdc' and 'Signal' wires at the servo harness plug it is best to not do as this.  This is because the current drive for the servo is drawn from the Arduino UNO.  Given that an individual servo can draw well in access of 125ma the current draw may/will exceed the current sink limitations of the associated Arduino UNO circuitry. It is best to use an external power source, properly filtered for electrical noise, as the current source for the servo(s).  This has been documented/recommended in multiple information sources.


message:
What are the FLASH_ARRAY/FLASH_TABLE macros in this code?

In this [code][1] for heating monitor, there appears to be macros called `FLASH_ARRAY` and `FLASH_TABLE`. I can't find any reference to them either in this code, Arduino, or on the Internet. What do they do?

    FLASH_ARRAY(byte, VARIABLE_DEVICE_TABLE,
        DEVICE_LADDNING_RETUR,
        DEVICE_LADDNING_UT,
        DEVICE_TANK1,
        DEVICE_TANK2,
        ...
        VARIABLE_ID_LOAD,
        VARIABLE_ID_TIME_EMPTY);

and

    FLASH_TABLE(byte, NUMBER_TEMP_TABLE, 7,
      {DEVICE_LADDNING_RETUR, 99,  5, 10,  7, MAIN_TYPE_TEXT_CELCIUS, 2},
      {DEVICE_LADDNING_UT,    99, 43, 10,  7, MAIN_TYPE_TEXT_CELCIUS, 2},
      ...
      {DEVICE_UTE,             0, 55, 15,  7, MAIN_TYPE_TEXT_CELCIUS_WITH_NEGATIVE, 103},
      {VARIABLE_ID_EFFECT,   114, 29, 10,  7, MAIN_TYPE_TEXT_VARIABLE, 2});

  [1]: https://code.google.com/p/heating-monitor/source/browse/HeatingMonitor/consts.h

body:
After further digging, this appears to be from Mikal Hart's [Flash library][1].

The reason this library was developed is:

> Storing static program data in flash/PROGMEM is a tricky part of
> Arduino programming. To save precious RAM, a novice user already at
> odds with unfamiliar C++ syntax must digest such daunting concepts as
> prog_char, PSTR(), PROGMEM, pgm_read_word(), etc. Even seasoned users
> get tripped up by the indirection and typecasting that are required to
> retrieve valid PROGMEM data. Add to that a couple of apparent bugs in
> the implementation, and it’s clear that PROGMEM is a complicated mess.
>
> I have written a new library, Flash, which abstracts away most of this
> complexity. It provides new String, Array, Table, and String Array
> types that make ROM-based data collections as easy to use as “normal”
> types. Each overrides the C++ [] operator, so to extract individual
> elements one uses familiar array access syntax:

Specifically, these are macros and a simple helper class to make it easier to create arrays and tables of values in program memory.

The two macros are declared as so:

    // Example: FLASH_ARRAY(float, temperatures, 98.1, 98.5, 99.1, 102.1);
    #define FLASH_ARRAY(type, name, values...) \
      static const type name##_flash[] PROGMEM = { values }; \
      _FLASH_ARRAY<type> name(name##_flash, sizeof(name##_flash) / sizeof(type));

    // Example: FLASH_TABLE(uint8_t, fonts, 7, {ON, OFF, ON, ON, OFF, ON, OFF}, {OFF, ON, OFF, ON, OFF, ON, OFF});
    #define FLASH_TABLE(type, name, cols, values...) \
      static const type name##_flash[][cols] PROGMEM = { values }; \
      _FLASH_TABLE<type> name((const PROGMEM type *)name##_flash, sizeof(name##_flash) / sizeof(name##_flash[0]), cols);

The helper functions include size and override the operator [] so that they can easily be accessed like so

    FLASH_ARRAY[0]

I disagree with zmo - this is more than boilerplate. The area of PROGMEM causes a lot of questions from Arduino users, and it is very easy to do things wrong when creating arrays in PROGMEM.

  [1]: http://arduiniana.org/libraries/flash/


body:
The flash array is from Mikal Hart's [flash library](https://github.com/mikalhart/Flash/blob/master/Flash.h#L39) as you show, and what it does is that they declare an array or a matrix (table) object in the PROGMEM memory:

<!-- language: lang-cpp -->

    #define FLASH_ARRAY(type, name, values...) \
    static const type name##_flash[] PROGMEM = { values }; \
    _FLASH_ARRAY<type> name(name##_flash, sizeof(name##_flash) / sizeof(type));

which is an instance of the `_FLASH_ARRAY` class defined in that same file, which is a facility to access PROGMEM/Flash memory.

Basically, it's a lot of boilerplate for what already does the `PSTR()` macro amongst other from `pgmspace.h`. I personally would avoid using that and prefer to use the original macros along with my own index and pointers.

BTW, except for some Arduono IDE magic, I don't think that can compile, as the `Flash.h` is not included.

EDIT:

To make another point against the `FLASH_TABLE`/`FLASH_ARRAY` boilerplate/overhead, since avc-gcc 4.8 has been introduced the [`__flash` qualifier](http://gcc.gnu.org/onlinedocs/gcc/Named-Address-Spaces.html) which is a replacement for the `PROGMEM` macro, simplifying the whole stuff:

<!-- language: lang-cpp -->

    // to use string literals without having to cast
    #define FSTR(X) ((const __flash char[]) { X })

    // create string pstr in the .progmem.data address space
    const __flash char* pstr = FSTR ("foo");

and no more use of the `pgm_read_*()` functions, you can now access the content of the flash memory using `*pstr`, as shown is [this thread](http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&p=1129848). In case you want to keep a code compatible with older version of avr-gcc, [here's a post](https://codereview.stackexchange.com/questions/33883/embedded-conditional-code-compaction) that offers macros to deal with both systems.


message:
How can I sense very high temperatures with Arduino?

I've seen many temperature sensors, but the highest temperature they go up to is 125 degrees C (257 degrees F). I want to reach *higher* temperatures than that. I'm thinking about rigging up a closed loop sensor for my soldering iron (for a convenient LCD display), but I can't find out how to sense the temperature of the tip due to the higher operating temperature than most sensors.

body:
One of the options to measure high temperatures would be to use [thermocouples][1]. This table provides a basic description of [the types][2] and the corresponding temperatures that they can sense.

A simple search led me to these components.

- [Thermocouple Type-K Glass Braid Insulated][3] - A mid range thermocouple
- [Thermocouple Amplifier MAX31855 breakout board][4] - Board to interface the thermocouple with the Arduino. This is needed as the voltage changes in the thermocouple are extremely small, and the rise is non-linear.

>This is how the board is connected to the thermocouple.
>![enter image description here][5]

There is also a [tutorial on Adafruit][6] that deals with using and interfacing thermocouples.

> This is an image of the thermocouple interfaced with the Arduino.
>![enter image description here][7]

  [1]: http://en.wikipedia.org/wiki/Thermocouple
  [2]: http://en.wikipedia.org/wiki/Thermocouple#Thermocouple_comparison
  [3]: https://www.adafruit.com/products/270
  [4]: https://www.adafruit.com/products/269
  [5]: https://i.stack.imgur.com/oV37Y.jpg
  [6]: http://learn.adafruit.com/thermocouple/
  [7]: https://i.stack.imgur.com/tvzG0.jpg


body:
You probably want to use a [thermocouple][1]. It'll give you the ability to measure much higher temps than regular temperature sensor. You'll also need a IC like the [MAX6675][2] to interface with it.

> The MAX6675 performs cold-junction compensation and digitizes the
> signal from a type-K thermocouple. The data is output in a 12-bit
> resolution, SPI™-compatible, read-only format.
>
> This converter resolves temperatures to 0.25°C, allows readings as
> high as +1024°C, and exhibits thermocouple accuracy of 8 LSBs for
> temperatures ranging from 0°C to +700°C.

![enter image description here][3]

[Page 6 of the datasheet][4] has the serial interface protocol information and. You can really just set the Chip Select line and it'll give you 16 bits of information, 12 of which will be the temperature.

  [1]: http://en.wikipedia.org/wiki/Thermocouple
  [2]: http://www.maximintegrated.com/datasheet/index.mvp/id/3149
  [3]: https://i.stack.imgur.com/pyNbk.gif
  [4]: http://datasheets.maximintegrated.com/en/ds/MAX6675.pdf


message:
Redirecting Arduino Serial Output to a File

I am integrating the MPU-6050 Accelerometer + Gyro sensor into a large project that contains 12 Arduino boards and 6 Raspberry Pis. At some point, I will have to load the output of my MPU-6050 sensor into another application through command line. The process is to be all done with Python and Bash (on the Raspberry Pi side), and so what I need is a way to store the output of my Arduino boards.

What I am currently looking at is the python program `ino`. I have used the product for about a year now, and as far as I am aware of, the only way to exit out of serial mode in `ino` is by closing the command-line window!

Is there a way I can achieve what I've discussed above? Essentially, all I want is a way to hold the output of my Arduino serial output so I can use it later in other parts of my project.

body:
Well, I don't know about your `ino` program, but here's how I'd do it:

get_serial.py

    import serial, sys

    with serial.Serial(port=sys.argv[1], baudrate=sys.argv[2]) as ser:
        while ser.isOpen():
            print(ser.readline())

The idea, here, is to print on `stdout` the data coming on the serial line:

    python get_serial.py /dev/ttyACM0 115200 > output.log

or you can do it this way:

get_serial.py

    import serial, sys

    with open(sys.argv[3]) as f:
        with serial.Serial(port=sys.argv[1], baudrate=sys.argv[2]) as ser:
            while ser.isOpen():
                f.write(ser.readline())

which is ran:

    python get_serial.py /dev/ttyACM0 115200 output.log

Hope this helps!


message:
A digital I/O pin as ground

I want an I/O pin to return current in a circuit, similarly to the function of ground.

Which of these will achieve what I require?

    pinMode(pinnumber, OUTPUT)
    digitalWrite(pinnumber, LOW)

or

    pinMode(pinnumber, input)

body:
Your first snippet is the correct solution.

    pinMode(pinnumber,OUTPUT)
    digitalWrite(pinnumber,LOW)

Be careful though, you can only sink up to 6mA or 9mA per pin (as per the [documentation][1] ["Input and Output" section], I never tried more). If you need more current, use a transistor ([this][2] looks like a good example, you just need to invert the output pin to `HIGH`).

When the pin is configured as input it is supposed to be high impedance, not what you want.

  [1]: http://arduino.cc/en/Main/ArduinoBoardDue
  [2]: http://learn.adafruit.com/adafruit-arduino-lesson-13-dc-motors/transistors


message:
Why can I not use pointers instead of array with PROGMEM?

I'm currently changing some libraries to use flash instead of RAM for string storage so that I do not run out of SRAM on a project.

Some strings in the library are declared in this manner:

    const char *testStringA = "ABC";

This is different to how I normally see this done:

    const char testStringB[] = "DEF";

However, I think that these two are equivalent when declared const and initialised in the declaration. Both work fine in code.

I attempted to move these to flash:

    const prog_char *testStringC PROGMEM = "GHI";

I then found that this didn't work. It was producing gobbledegook when printed.

However, following the more usual pattern of:

    const prog_char testStringD[] PROGMEM = "JKL";

works fine.

I can see in the disassembly:

    00000068 <testStringC>:
      68: 04 01                                               ..

    0000006a <_ZL11testStringD>:
      6a: 4a 4b 4c 00                                         JKL.

So it is clear the pointer and PROGMEM results in the string/array not being initialised.

Why is this?

Example code:

    #include <avr/pgmspace.h>

    const int BUFFER_LEN = 20;

    const char *testStringA = "ABC";
    const char testStringB[] = "DEF";
    const prog_char *testStringC PROGMEM = "GHI";
    const prog_char testStringD[] PROGMEM = "JKL";

    void setup()
    {
        Serial.begin(9600);
    }

    void loop()
    {
        char buffer[BUFFER_LEN];

        Serial.println(testStringA);
        Serial.println(testStringB);

        strncpy_P(buffer, testStringC, BUFFER_LEN);
        Serial.println(buffer);

        strncpy_P(buffer, testStringD, BUFFER_LEN);
        Serial.println(buffer);

        delay(1000);

    }

body:
What this line:

    const prog_char *testStringC PROGMEM = "GHI";

does is to write prologue code to copy the characters in the string to SRAM, and then initializes the *pointer* stored in flash to this SRAM location. You must load the pointer via normal means, and then dereference the pointer as usual.

    const char *str = pgm_read_word(&testStringC);
    Serial.println(str);

This line:

    const prog_char testStringD[] PROGMEM = "JKL";

creates the *array of characters* in flash, allowing you to access it as expected.


body:
Well, this question has been wisely answered in [an answer to Stack Overflow question *C: differences between char pointer and array*][1].

Basically, what you're declaring as PROGMEM with,

    const prog_char testStringD[] PROGMEM = "JKL";

is both the array and the memory it points to, that is, the elements of the array, both in current's scope stack. Whereas with:

    const prog_char* testStringC PROGMEM = "GHI";

you declare a PROGMEM pointer to a constant string that may stay elsewhere in memory, but not declared as a PROGMEM string.

Though I did *not* test that, but you should try to declare:

    const prog_char* testStringC PROGMEM = F("GHI");

to actually allocate the pointed string within the PROGMEM space. I *guess* it should be working, using Arduino's [`F()` macro][2], which adds a lot of boilerplate code to actually have the same result as the array declaration.

As said in comments, if not in a global context, the `PSTR()` macro could be used instead of the `F()` macro.

Simpler is better: use the array declaration, not the pointer one!

Cf [that other answer](https://arduino.stackexchange.com/a/614/379), the `__flash` qualifier is a third solution ;-)

  [1]: https://stackoverflow.com/a/1335836/1290438
  [2]: http://andybrown.me.uk/wk/wp-content/images//avr-gcc-4.7.0/WString.h


message:
Webserver on Arduino

How can I run a webserver in a Arduino Uno? I want to use my Arduino to monitor things in my home such as temperature. I want to be able to access this data through the internet.

body:
You'll need something like the Ethernet Shield to connect your Arduino Uno to a LAN.

As for webserver functionality, the [Webserver Example][1] sketch does the bulk of what you need.

![enter image description here][2]

For the "access this data through the internet" part, assuming you want access beyond your LAN; you'll need to perform Port Forwarding on your local router (i.e. allow the "Internet" to see your Arduino).

If you need wifi, then personally I prefer the [CC3300][3] to the Arduino Wifi shield.

  [1]: http://arduino.cc/en/Tutorial/WebServer
  [2]: https://i.stack.imgur.com/ju3X6.png
  [3]: https://www.adafruit.com/products/1469


body:
The [Arduino Yún][1] has been made with this use case in mind. The [Bridge library][2] allows your sketch to publish data such as sensor readings: this data is available through a REST api.

Say you want to publish the temperature of your living room: you'll write something like

`Bridge.put("living_room", String(19)); //celsius`

You can then access the data via web with a URL like

`http://arduino.local/data/get/living_room`

You can get all sensor readings without specifying the key name, with

`http://arduino.local/data/get`

  [1]: http://arduino.cc/en/Main/ArduinoBoardYun
  [2]: http://arduino.cc/en/Reference/YunBridgeLibrary


message:
All voltage directed to pin 3 when multiple pins are set to out put

I just finished testing a haptic device at university, and when I took it home I got the joy of finding the device not working. Here's what I can trace the problem to: when multiple pins are set to output (pin 2~11), pin 3 writes constantly to high and there is nothing I can do to make it stop.

Using a blinker program one pin at a time produces no problems, however when I run a blinker program that cycles through all pins, pin 3 is set to constant high. My actual code is similar in function but more complex. This program below though gets the same error.

    void setup()
    {
      for (int c =2; c<12; c++){
        pinMode(c, OUTPUT);
      }
    }

    void loop()
    {
      for (int c =2; c<12 ; c++){
         digitalWrite(c, HIGH);
         delay(100);
         digitalWrite(c, LOW);
         delay(100);
      }
    }

Is this a sign my arduino died? My device had been working for weeks on my prior code with no problem (and no updates).

body: It is probably a dead chip. Try getting a new ATmega chip for the Arduino (easily found online for ~$5) and see if that fixes it.


message:
How cold or hot can my Arduino Uno get?

[The Arduino Uno Page](http://arduino.cc/en/Main/arduinoBoardUno) doesn't say the temperatures that it can operate in. I'm thinking about placing it outdoors. How can I make sure my Arduino Uno is safe in weather that can reach -20 to 105 degrees Fahrenheit? (-26 to 40 degrees Celsius).

body:
**It's not that big of deal.** [The ATmega 328p datasheet](http://www.atmel.com/images/atmel-8271-8-bit-avr-microcontroller-atmega48a-48pa-88a-88pa-168a-168pa-328-328p_datasheet.pdf) states this:

> Temperature range: -40 to 85 degrees celsius.

The same goes for the [USB chip on the Uno (ATmega 16u2 for UNO R3)](http://www.atmel.com/Images/7799S.pdf).

That's inside your limits. It probably could go a bit colder than mentioned, but it'll shorten the length of the board a little bit.

However, there are some things that may go wrong:

 - EEPROM might not be stored as long in extreme temperatures. Keep this in mind if you're storing critical data.
 - The voltage regulator may not perform as well in hot conditions
 - The crystal oscillator may not produce exact values. However, I would imagine that a few hertz more or less wouldn't affect a 16 MHz processor. The tolerance is actually a little less than 1%. You may have some issues with serial (baud rate not correct). I would look into any communications like I2C also. (I don't know exactly how the clock line works... it might be fine for I2C.)
 - Resistors/capacitors may not produce the *exact* values. I'd imagine that the tolerance won't be more than 8% on resistors: most resistors are rated at 5% for normal temperatures. It does depend on the manufacturer. Capacitors do have a bigger tolerance, but their main purpose is to "smooth" a signal.
 - Extreme cooling/warming may cause minor expansion problems. (Note: it's fine once in a while, but not on an hourly basis of dropping 30 degrees.)
 - Other components (LCDs, etc.) should be kept in mind also when looking at the viability of keeping it outdoors.

So as long as all the other components not on the board will happily run in the temperatures that you need, you should be fine. Also, as with all engineering, values often have added "padding" built in. (i.e. 5% tolerance is often 3-4%, maximum 12V it can run on 12.5V, etc.)*

*What I mean by that is your Arduino won't explode when it's -41 degrees C. It's not great for it, but most likely you should be fine as long is it isn't a regular occurrence.


body:
For hot temperature, just follow the datasheet.

For low temperature, I remember someone last year trying to [overclock a UNO with liquid nitrogen][1] so I guess you won't ever meet any problems with low temps :-)

In [his blog][2], that person shows that he could run his UNO at 65 MHz by reducing temperature to -196°C.

Of course, the process was more complex than just reducing the temperature and checking what happens: a lot of improvements were performed on the board.

The blog explains very well how various components can react to cryogenic temperatures; the major issues seemed to be capacitors which capacitance **dramatically** reduces under low temperatures.

  [1]: http://blog.arduino.cc/2013/08/29/overclocking-arduino-with-liquid-nitrogen/
  [2]: http://3.14.by/en/read/arduino-liquid-nitrogen-overclocking


body:
Like everyone mentions, as long as you're in the shade, hot temperature probably doesn't matter too much as it's within the limits of the components.

I'm more worried about condensation in the mornings.  Water vapors will condense on electronics just like it does on grass.  You could try electrical epoxy to cover the circuit.  The Arduino doesn't run very hot, so the epoxy doesn't do much in terms of preventing it from cooling down.  But epoxy does keep water vapor condensation from being a problem.


body:
I agree with the advice to read the data sheets, but here is a personal answer to the question.

I installed a Raspberry Pi in an enclosure in which the existing Arduino survived last summer.

Even though they have the same overall temperature limits (except the communications section) it was the Pi that stopped working first.

The good news is that bringing it inside it booted right back up.

The temp/humidity went up to 140 F (like a hot car in Phoenix).

So in the end, the data sheet was right in terms of survival.  But I would suggest a more conservative approach, such as placing them into a white-painted enclosure to minimize the effects of the sun.

After removing the pi, the Arduino woke up like nothing happened, still outside.

These things are very resilient.


body:
If you must place your device outside, I would suggest a diecast box. The main heat generating component is probably the regulator (Think about it - at 12V, the reg drops 7V, where the micro runs on 5V or maybe 3V3). So running the lowest voltage into the arduino is recommended, I think its good to 7V (for a 5V unit). If you can connect a heat pathway from the chip surface to the case, good (Use heavy guage - at least 2mm thick). Take care you do not connect to the reg tab - use mica or thin mylar and heatsink paste (Avoid galvanic interations). Normal finned heatsinks on the outside of the box actually do the job of shedding heat to the atmosphere. This whole thing should be in a slatted wooden white painted container (A stevenson screen) so direct sun (and rain/dew) dont hit the containing box.
This would be a solution for extreme environments.
Remember that any heat build from the board must get to the box internal environment - using trapped air you get a very poor thermal contact. Then it has to get through the box and into the air again.
Dont forget that current sinks you use on the chip generate some (small) heat in the process.


message:
Powering Arduino with car batteries

Presumably, one powers an Arduino board with car batteries for long-term operation away from the power grid.

How can this be done, and what are the most (1) economic, and (2) reliable ways to do this? Specifically, do any additional risks to short the board with an extraneous discharge exist?

body: I'm a big fan of USB car chargers for things like this, or USB buck converter boards that you get from ebay.


body:
Use a switching regulator such as the [LM2596][1]. You can get a ready board from [eBay][2] for about US$1.

![Enter image description here][3]

Just set the output voltage to 5 V and feed the Vcc input of Arduino; this bypasses the onboard regulator.

The benefit is that unlike the linear onboard regulator, a switching regulator is very efficient which means less consumption and less generated heat on the regulator. An additional benefit is that it can withstand a higher input voltage (about 35 V for the specified regulator), just in case the circuit is used in a vehicle that has 24 V batteries.

The regulator has already several protections like for [short circuiting][4], overheating, etc.

  [1]: http://www.ti.com/product/lm2596
  [2]: http://en.wikipedia.org/wiki/EBay
  [3]: https://i.stack.imgur.com/HyLG8.jpg
  [4]: https://en.wikipedia.org/wiki/Short_circuit


body:
There is also the higher-end Akafugu breadboard power supply - takes input from 7V all the way to 35V, but costs 11$ apiece in the bargain.

![enter image description here][1]

[Akafugu][2]

  [1]: https://i.stack.imgur.com/IB0rt.jpg
  [2]: http://store.akafugu.jp/products/30


body:
"Practical Arduino book" has a very interesting circuit for this purpose: http://www.practicalarduino.com/projects/vehicle-telemetry-platform

Here is how I've recreated it:

It uses LM2940CT and huge electrolytic cap - even if supply voltage drops, you'll have about a second to shut down your Arduino gracefully (close files on SD properly, and so on).

"Arduino Cookbook" (2nd ed.) has a chapter with examples on how to reduce Arduino's power consumption to absolute minimum - have a look at it, too.


body:
Two more options - battery pack with convenient pre-made screw holes for Arduino, Raspberry.PI, and Beagle Board:

![Smart Power Base][1]

[Smart Power Base][2]

Kicking it up a notch - using a cordless drill's 18V battery.  The project is meant for R.PI, but it would work just as well on Arduino, as the power supply is USB

![Portable PI Power][3]

[Portable PI Power][4]

  [1]: https://i.stack.imgur.com/T0aHD.jpg
  [2]: http://www.makershed.com/product_p/mkmts01.htm
  [3]: https://i.stack.imgur.com/I9ct9.jpg
  [4]: http://makezine.com/projects/portable-pi-power-raspbery-pi-to-go/


body:
Standard car batteries are 12.6 volts there are 6 2.1V cells.  AGM batteries (i.e. Optima batteries, some interstates, and many other brands make AGM), in my experience with AGM batteries they are around 12.8 volts (I do not know the technical voltage).  Without the car running you do not need to worry about voltage spikes **AS LONG AS THE WIRES TO AND FROM THE BATTERY ARE SHORT**.  When the car is running the serpentine belt turns the alternator which is an AC generator.  The alternator is connected to a rectifier to change it back to DC and the unit has a voltage regulator.  When the car is running the alternator runs the electrical system and charges the battery.  When you connect to the battery while the car is running you are actually connected to the alternator.  When connected to the alternator there is a ton of electrical noise, voltage spikes, etc.

I have always had success connecting straight from the battery to the Arduino through its barrel jack connector, I have not tried any analog read function when the car is running.  On the Arduino website it recommends 7-12V, however the limits (as listed on the Arduino website below the recommended) are 6-20. I have actually experienced problems with lower input voltages.  If you feel uncomfortable just buy a 5 volt regulator and power through the usb.


message:
Arduino serial port reset in Serial monitor & Python

So am I using an Arduino with a shield to gain some voltage values for an ECG. I am then plotting that data in Python. However whenever I "observe" the serial port, be that through the Arduino serial monitor or in attempting to plot the values of time (using millis()) against ECG (voltage) the values reset, so millis() resets the zero, which is fine, except that some of the older values still show up. Now this is especially a problem in Python because it means the plot is malfunctioning at the start of the script, because it is plotting some of the older values and then after a couple of seconds it resets and the plot looks normal again.

To demonstrate this I have recorded it on video and put it on YouTube, here it is:

https://www.youtube.com/watch?v=dNpUakcRPec

Now initially I thought the problem was with Python or the Pyserial module so I labelled the video as such, but since it occurs in the serial monitor I realised the solution would be in the Arduino sketch. I have tried flushing, didn't work, I have tried even to not start the data till I send a start byte, but this didn't work on Python.

Ideally I could start the Python plotting script and it would skip, or ignore those initial values from the serial port before beginning again.

Here is the Arduino sketch I am using:

    #include <eHealth.h>

    unsigned long time;
    // The setup routine runs once when you press reset:
    void setup() {
      Serial.begin(9600);

    }

    // The loop routine runs over and over again forever:
    void loop() {

      float ECG = eHealth.getECG();
      time = millis();
      Serial.print(time);
      Serial.print(" ");
      Serial.print(ECG, 3);
      Serial.println("");

      delay(50);    // wait for 50 millisecond
    }

body:
Take a look at [if(Serial)][1]

That makes the Sketch wait for the serial port before continuing.

    void setup() {
    //Initialize serial and wait for port to open:
      Serial.begin(9600);
      while (!Serial) {
    ; // wait for serial port to connect.
      }
    }

I have a sneaking suspicion that may only work on the Leonardo.

If so you could try an alternative:

 1. Have Python send something to Arduino after it connects.

 2. Wait until this is received in setup(): if (Serial.available() > 0) {...}

 3. Execute the loop() normally

e.g.

    // send data only when you receive data:
        if (Serial.available() > 0) {
                // read the incoming byte:
                incomingByte = Serial.read();

                // say what you got:
                Serial.print("I received: ");
                Serial.println(incomingByte, DEC);
        }

  [1]: http://arduino.cc/en/Serial/IfSerial#.Uxhl8xARfxw


body: The Arduino is designed to reset when a Serial monitor or script connects to it. The best way to mitigate this would be to send the Arduino some kind of "start sending" signal when you connect to the serial port. It would then send the data when your script was ready.


body:
I the answer from @TheDoctor. An alternative is for the client listening on serial port to wait for a "successful reset" signal from the Arduino.

    void setup() {
    //Initialize serial and wait for port to open:
        Serial.begin(9600);
        while (!Serial) {
            ; // wait for serial port to connect.
        }
        Serial.println('reset successful')
    }

There are pros and cons to each solution. In the @TheDoctor solution, it seems like there is an edge cases where the Arduino is already sending when the client connects and you'll get some junk before the reset occurs.


message:
Arduino disconnecting at upload

This problem doesn't seen to be very common around the Arduino community.

Basically, what's happening is that as soon as I click the upload button, the Arduino IDE tells me that my Arduino board is not connected. What's strange though is that the python application ino is able to upload my code just fine, so my only guess is that there is something wrong with the IDE itself.

Here's a copy of the error message I am getting at the time of uploading the sketch:

> Binary sketch size: 444 bytes (of a 32,256 byte
> maximum)processing.app.SerialException: Error opening serial port
> '/dev/ttyACM1'.at processing.app.Serial.<init>(Serial.java:178)at
> processing.app.Serial.<init>(Serial.java:77)at
> processing.app.debug.Uploader.flushSerialBuffer(Uploader.java:77)at
> processing.app.debug.AvrdudeUploader.uploadViaBootloader(AvrdudeUploader.java:174)at
> processing.app.debug.AvrdudeUploader.uploadUsingPreferences(AvrdudeUploader.java:67)at
> processing.app.Sketch.upload(Sketch.java:1671)at
> processing.app.Sketch.exportApplet(Sketch.java:1627)at
> processing.app.Sketch.exportApplet(Sketch.java:1599)at
> processing.app.Editor$DefaultExportHandler.run(Editor.java:2380)at
> java.lang.Thread.run(Thread.java:744)Caused by:
> gnu.io.UnsupportedCommOperationException: Invalid Parameterat
> gnu.io.RXTXPort.setSerialPortParams(RXTXPort.java:213)at
> processing.app.Serial.<init>(Serial.java:163)... 9
> moreprocessing.app.debug.RunnerException: Error opening serial port
> '/dev/ttyACM1'.at
> processing.app.debug.Uploader.flushSerialBuffer(Uploader.java:101)at
> processing.app.debug.AvrdudeUploader.uploadViaBootloader(AvrdudeUploader.java:174)at
> processing.app.debug.AvrdudeUploader.uploadUsingPreferences(AvrdudeUploader.java:67)at
> processing.app.Sketch.upload(Sketch.java:1671)at
> processing.app.Sketch.exportApplet(Sketch.java:1627)at
> processing.app.Sketch.exportApplet(Sketch.java:1599)at
> processing.app.Editor$DefaultExportHandler.run(Editor.java:2380)at
> java.lang.Thread.run(Thread.java:744)

I am expecting to hear a few questions regarding this issue, so I'll go ahead and answer all the questions I can think of.

> *Is this the first time you trying to connect to the Arduino from this computer?*

No. In fact, I was able to upload the same source code just fine less than two hours ago.

> *Did you try a different USB cord?*

Yes, I did.

> *Can you upload the source code from a different computer?*

Yes, I can.

> *Have you tried removing and reinstalling the IDE?*

Yes, I have.

> *Have you tried a different USB port?*

Yes, I have.

What seems to be the problem here?

body:
First of all, you must test if the device that you are trying to access, actually exists. The device file may change when you replug the Arduino. The easiest way to accomplish that is to find the device name in the error message, in this case `/dev/ttyACM1`. Then check two things:

1. Does the device file exist in  the `/dev` tree? `ls -l /dev/ttyACM*`
2. Is the Arduino IDE configured to use the correct device? Check under `Tools` => `Serial Port`.

Maybe another application is using the device. When working on Linux, you can verify this with the following commands:

    $ lsof /dev/ttyUSB0
    COMMAND  PID     USER   FD   TYPE DEVICE SIZE/OFF      NODE NAME
    avrdude 7356   jippie    3u   CHR  188,0      0t0 266450197 /dev/ttyUSB0

or

    € fuser /dev/ttyUSB0
    /dev/ttyUSB0:         7356

Where of course you have to replace `/dev/ttyUSB0` with the device file as mentioned in the error message. In case of this question `/dev/ttyACM1`, but do notice that the number can change when you unplug the board for a moment and then replug it.

In both results, the `7356` is the PID of the process that is locking the device. In my example I was reading flash from the command line, so the output for your specific situation will be different. To identify the process, you can use:

    $ ps -fp 7356
    UID      PID  PPID  C STIME TTY          TIME CMD
    jippie  7698 28116  1 20:34 pts/8    00:00:00 avrdude -patmega1280 -carduino -P/dev/ttyUSB002 -b57600 -D -Uflash:r:/tmp/flash:i

or a more portable command:

    $ ps -ef | grep 7356
    jippie  7698 28116  1 20:34 pts/8    00:00:00 avrdude -patmega1280 -carduino -P/dev/ttyUSB002 -b57600 -D -Uflash:r:/tmp/flash:i


body:
Try setting the baud rate to 9600 in the Serial Monitor. You need a working serial port to open the Serial Monitor. Or go to >File >Preferences> and edit the preferences.txt (must close Arduino IDE before editing) "serial.debug_rate=9600"

I have several Arduino boards and had the exact same issue with the boards that use the Atmel mega8U2 as the USB - serial bridge. The boards with the FTDI USB bridge (SparkFun Red board, Pro mini) did not show the same problem. Setting the baud rate solved my problem.

There is a firmware upgrade for 8U2 that might fix it but I didn't want to risk making bricks. ;-)


body:
I have same problem after set baud rate to 14400.
For fix this I manual set serial.debug_rate=115200 in config file ~/.arduino/preferences.txt


body:
A pretty detailed troubleshooting guide is available at [arduino.cc][1]. Besides the checks already mentioned in the question and the answers, it is recommended to check that `serial.download_rate` is set to `19200` in `~/.arduino/preferences.txt`.

`19200` is the default baud rate used by most [bootloaders](https://www.arduino.cc/en/Hacking/Bootloader?from=Tutorial.Bootloader), so this doesn't apply if you don't use one, or use a modified version.

  [1]: https://www.arduino.cc/en/Guide/Troubleshooting2#toc8


message:
Two Timer Interrupts, One Incorrect?

I'm trying to replicate a waveform exactly using external and timing interrupts. I've got an external that's setup as a 0ms reference, TIMER1 which is used to determine on time, and TIMER2, which sets the low period. Unfortunately, I can't get the pin low for 2ms. TIMER2 must have something wrong with it, but I can't find it. Instead of banging my head against the wall, I thought I'd ask you guys. Anyone know the answer?

    //3 is interrupt for Timing
    //4 through 11 are Time dependent receivers
    //3-11 Pins 12-19

    //Current Serial Byte(Letter or Number)
    char incomingByte = 0;
    //Previous Byte in the Serial Chain
    char previousByte = 0;

    //Iterator for Interrupt Values
    volatile unsigned int maincount = 0;

    //Time of High Period or Timer Duration
    volatile unsigned int timerhigh;

    //Output Pin for Timer Waveform
    volatile unsigned int waveout;

    //Time for Timer Delay in milliseconds, default tim
    volatile unsigned int groundtime = 0;

    //Receiver Pins in an Array, except for 3, which serves as 0 source reference
    int pins[9] =
    {
      3,4,5,6,7,8,9,10,11
    };

    void rising()
    {
      // set up Timer 1
      TCCR1A = 0;  // normal mode
      TCCR1B = bit(WGM12) | bit(CS11);  // CTC, scale to clock / 8
      OCR1A = timerhigh;          // time before timer fires
      TIMSK1 = bit (OCIE1A);            // interrupt on Compare A Match
    }

    //Sets Pin Low, then sets up another timer interrupt for the jump back to high
    ISR(TIMER1_COMPA_vect)
    {
     //Brings Pin Low for Keypress
     //Serial.println("We're in Timer 1");
     pinMode(waveout,OUTPUT);
     digitalWrite(waveout, LOW);

     //Stop Timer 1
     TCCR1B = 0;                      // stop timer
     TIMSK1 = 0;                      // cancel timer interrupt

     //Disables Interrupts Before Messing
     cli();
     // set up Timer 2
     TCCR2A = 0;  // normal mode
     TCCR2B = 0;
     //  TCCR2A = bit(WGM21) | bit(CS21);  // CTC, scale to clock / 8
     TCCR2A = (1 << WGM21); //Enables CTC for timer
     TCCR2B = (1 << CS21); //Sets 8 bit prescaler
     OCR2A = groundtime;          // time before timer fires
     TIMSK2 = (1 << OCIE2A);

     //Cancel Rising Interrupt on D3
     EIFR = bit (INTF1);
     //Reenables interrupts
     sei();
    }

    //Timer Interrupt for Low Period
    ISR(TIMER2_COMPA_vect)
    {
    //Serial.println("WE'RE IN TIMER2");
    //Brings Output pin high
    digitalWrite(waveout, HIGH);

    //Stop Timer 2
    TCCR2B = 0;                      // stop timer
    TIMSK2 = 0;                      // cancel timer interrupt

    //Cancel Rising Interrupt on D3
     EIFR = bit (INTF1);
    }

    void setup() {
      // put your setup code here, to run once:

    //Sets all the pins for output use
    for(int i=0;i<8;i++)
    {
      pinMode(pins[i], INPUT);
    }

    //Sets Reference Pin as Input
    pinMode(3,INPUT);

    //Begins Serial
    Serial.begin(115200);

    //Cancels Timer 1
    TCCR1A = 0;  // normal mode
    TCCR1B = 0;  // stop timer
    TIMSK1 = 0;   // cancel timer interrupt

    //Cancels Timer 2
     TCCR2A = 0;
     TCCR2B = 0;                      // stop timer
     TIMSK2 = 0;                      // cancel timer interrupt
    detachInterrupt(1);

    }

    void loop() {

      //Time of Ground Drop(2 mS), Universal for all letters and offsets
      groundtime = 40000;     // spark time (4000 * 500 nS) = 2 mS

      // because of prescaler of 8, each unit is 500 nS (0.5 µS)

         if(Serial.available()> 0);
        {
       //Reads Serial Value and assigns to incomingByte
       incomingByte = Serial.read();
       attachInterrupt(1,rising,RISING);
        }
      //  noInterrupts ();  // atomic change of the time amount

       //In this area, we'll set the output pin to be used by the timing interrupt,
       //and the time delay off the default waveform present on pin 4

       //We can use switch case arrangement, don't know if that's the optimal setup though
     switch(incomingByte)
     {
       default:
       //Do Nothing
       break;

       //Cases FOR ALL THE LETTERS
       case 'a':
       break;
       case 'b':
       break;
       case 'c':
       break;
       case 'd':
       break;
       case 'e':
       break;
       case 'f':
       break;
       case 'g':
       break;
       case 'h':
       break;
       case 'i':
       break;
       case 'j':
       break;
       case 'k':
       break;
       case 'l':
       break;
       case 'm':
       break;
       case 'n':
       break;
       case 'o':
       break;
       case 'p':
       break;
       case 'q':
       break;
       case 'r':
       //Output pin 17 Frequency Pin 10
       //microseconds
       timerhigh=8000;
       waveout=9;
       break;
       case 's':
       break;
       case 't':
       break;
       case 'u':
       break;
       case 'v':
       break;
       case 'w':
       break;
       case 'x':
       break;
       case 'y':
       break;
       case 'z':
       break;

       //Cases FOR ALL THE NUMBERS
       case '0':
       break;
       case '1':
       break;
       case '2':
       break;
       case '3':
       break;
       case '4':
       break;
       case '5':
       break;
       case '6':
       break;
       case '7':
       break;
       case '8':
       break;
       case '9':
       break;

       //Cases FOR ALL THE PUNCTUATION
       case '.':
       break;
       case ',':
       break;
       case '!':
       break;
       case '"':
       break;
       case '#':
       break;
       case '$':
       break;
       case '%':
       break;
     }

    //Enables Rising Interrupt for 0ms detection
    //attachInterrupt(1,rising,RISING);

    //Reenables interrupts after offset time change
    //interrupts ();
    }

body:
Turns out the problem was that timer 0 and 2 on the arduino uno are 8 bit. Set a different prescaler and I'm golden

    // set up Timer 2
        TCCR2A = 0;  // normal mode
        TCCR2B = 0;
        //  TCCR2A = bit(WGM21) | bit(CS21);  // CTC, scale to clock / 8
        TCCR2A = (1 << WGM21); //Enables CTC for timer

        TCCR2B |= (1 << CS21);
        TCCR2B |= (1 << CS22); //Sets 256 bit prescaler
        TCCR2B |= (0 << CS20);
        OCR2A = groundtime;    // time before rising edge
        TIMSK2 = (1 << OCIE2A);
        //Cancel Rising Interrupt on D3
        EIFR = bit (INTF1);
        //Reinables interrupts


message:
Have I fried my A2 port?

I'm playing around with a SparkFun Redboard (essentially, an Arduino UNO).

I have a simple 5V sensor that I'd been trying to get to work with A2 and analogRead(). Nothing seemed to work. It's supposed to be cycling from 0 to 5V, which should give me values from 0 to 1023, and instead I get constant values of around 260.

In desperation, I tried using other ports. On A0, A1, and A3 I get the signals I expect. On A2, still nada.

So, the question. Is there something I could have done in configuring things that would have made A2 and only A2 stop reading correctly? If so, how can I reset it?

Or is there some other function that I might be using that could interfere with A2? Currently, I'm only using Serial over USB - could that interfere with A2?

Or could I simply have fried the port?

body: I wrote a simple program that used all six analog pins as digital outputs, and wired up an LED. All of the pins except A2 would blink the LED. So yes, it is fried.  Thanks.


message:
How much can an Uno be overclocked?

When running the board at room temperature (20 C) without any extra cooling mechanisms added, how much can the Arduino Uno be overclocked?

Also, what would I need to change/update to overclock the board?

body:
With no active cooling, most ATmega328P will run at 30MHz but you will need to up the supply voltage to ~6V. I have never done this on an Arduino board, just an ATmega328P.

I provided an external clock from a signal generator.

The only way to achieve a speed faster than 16MHz is to change the crystal/oscillator/clock input for one faster than 16MHz.

As this was just an experiment, I didn't alter f_cpu in boards.txt, so all timers etc. would be incorrect. Baud rates would also be incorrect - the only way to upload code was to change back to 16MHz.


message:
How to interface to LPG consumption meter

I have sourced an LPG consumption meter from China with pulse output. I am looking to hook the output up to an arduino to get the consumption metrics. Unfortunately there is not too much documentation available on the unit that I can find. The suppliers inform me that:

1. Black wire(signal 1)
2. Black wire(signal 2)
3. Red wire(earth wire)

So that's a start, I know the unit pulses a signal for every cubic meter of gas consumed.
What I'm wanting to know is:

1. What are the input [likely] voltages for the unit (or how could I establish this)?
2. How do I wire the unit to an arduino?
3. I can cook up a sketch to do the reading but what is the signal I am looking for?

The mechanical meter itself has a metallic strip on the 0 digit of the wheel (how it achieves the pulsing itself no doubt) so another approach would be something like this <http://phk.freebsd.dk/Gasdims/> which is a more accurate option. For this option any suggestions on what photoreflectors are available for the Arduino which could do the job.

![meter][1]
![output wiring - one red two black][2]

  [1]: https://i.stack.imgur.com/sHmUd.jpg
  [2]: https://i.stack.imgur.com/WTD8F.jpg

body:
Start with earthing the red (!?) wire to the ground of the arduino.
Apply 5 volts via a 10k resistor to one of the black wires and also connect the black wire to the arduino as well.
Basically :

    5V ----(10K resistor)---+---Black wire----( Gas Meter)-----ground
                            |
                            |
                            +--- arduino digital input

You should either get a high or a low signal. Try the other black wire, it might be inverted (as in high and then pulse low, vs low and then pulse high).

Failing that, pop the top off that cover and have a poke around. Might give you a clue as to what's what.


message:
Efficient algorithm/data structure to calculate moving averages

Currently I am developing a graphic LCD system to display temperatures, flows, voltages, power and energy in a heat pump system. The use of a graphic LCD means that half of my SRAM and ~75% of my flash have been used up by a screen buffer and strings.

I am currently displaying min/max/average figures for energy At midnight when the daily figure resets, the system checks if the consumption for the day is above or below the previous minimum or maximum, and stores the value. The average is calculated by dividing the cumulative energy consumption by the number of days.

I would like to display the daily average over the last week and month (4 weeks for simplicity) i.e. a rolling average. Currently this involves maintaining an array of values for the last 28 days and calculating an average over the whole array for monthly and last 7 days for weekly.

Initially I was doing this using an array of floats (as the energy is in the form "12.12kWh"), but this was using 28 * 4 bytes = 112 bytes (5.4% of SRAM). I don't mind having only a single decimal point of resolution, so I changed to using uint16_t and multiplying the figure by 100. This means that 12.12 is represented as 1212, and I divide by 100 for display purposes.

The size of the array is now down to 56 bytes (much better!).

There is no trivial way to reduce the figure down to a uint8_t that I can see. I could tolerate the loss of a decimal place ("12.1kWh" instead of "12.12kWh"), but consumption is frequently higher than 25.5kWh (255 being the highest value represented by a 8-bit unsigned integer). Consumption has never been below 10.0kWh or above 35.0kWh, so conceivably I could subtract 10 from the stored figures, but I know that one day we will exceed these limits.

I then tested code to pack 9-bit values into an array. This gives a range of 0-51.2kWh and uses 32 bytes in total. However, accessing an array like this is pretty slow, especially when you have to iterate over all values to calculate an average.

So my question is - is there a more efficient way of calculating a moving average with three windows - lifetime, 28 days and 7 days? Efficiency means smaller in terms of SRAM usage, but without the penalty of huge code. Can I avoid storing all values?

body:
you can use a different method, you keep the current average and then do

    average = (weight1*average+weight2*new_value)/(weight1+weight2);

it's not a true rolling average and has different semantics, but it may fit your needs nonetheless

for a more efficient calculation method for your 9 bits per value solution you could keep the 8 highest bits of the values in an array and separate out the least significant bits:

    uint8_t[28] highbits;
    uint32_t lowbits;

to set a value you need to split it out

    void getvalue(uint8_t index, uint16_t value){
        highbits[index] = value>>1;
        uint32_t flag = (value & 1)<<index;
        highbits|=flag;
        highbits&=~flag;
    }

resulting in 2 shifts an AND and an OR and a not

to calculate the average you can use various bit tricks to speed it up:

    uint16_t getAverage(){
        uint16_t sum=0;
        for(uint8_t i=0;i<28;i++){
            sum+=highbits[i];
        }
        sum<<=1;//multiply by 2 after the loop
        sum+=bitcount(lowbits);
        return sum/28;
    }

you can use an [efficient parallel bitcount][1] for the `bitcount()`

  [1]: https://stackoverflow.com/questions/3815165/how-to-implement-bitcount-using-only-bitwise-operators


body:
If your data has low standard deviation, then one method would be to sum values over the window, and then keep subtracting the mean from the sum, while adding the new value.

This would work well if there are *no outliers*, thereby leading to the aggregate error tending to zero over time.

    //Pseudocode

    count=0
    while new_reading and count<7:
        sum += new_reading        //Calculate the sum of first 7 values
        count++

    while new_reading:            //Loop till new readings available
        avg = sum / 7             //Calculate average
        sum -= avg                //Subtract average from sum
        sum += new_reading        //Add next reading to sum
        print avg


body: How about only storing the difference from the previous value? In electronics there is a similar concept called Delta Sigma converter, which is used for DA/AD converters. It relies on the fact that the previous measurement is reasonably near the current one.


body:
Why couldn't you just add the values together as soon as you obtain them. So what I mean is you get the value for day 1, you divide it by 1 and store it and the 1 somewhere. Then you multiply the 1 by the value and add it to the next value and divide them both by 2.

Doing this method would create a rolling average with two or three variable as I can think of. I would write some code but I am new to stackexchange so please bear with me.


body:
> is there a more efficient way of calculating a moving average with
> ... 28 days and 7 days?
...
> needing to remember 27 days of history ... ?

You might get close enough storing 11 values rather than 28 values,
perhaps something like:

    // untested code
    // static variables
    uint16_t daily_energy[7]; // perhaps in units of 0.01 kWh ?
    uint16_t weekly_energy[4]; // perhaps in units of 0.1 kWh ?

    void print_week_status(){
        Serial.print( F("last week's total energy :") );
        Serial.println( weekly_energy[0] );
        int sum = 0;
        for( int i=0; i<4; i++ ){
            sum += weekly_energy[i];
        };
        Serial.print( F("Total energy over last 4 complete weeks :") );
        Serial.println( sum );
        int average_weekly_energy = sum/4;
        int average_daily_energy = average_weekly_energy/7;
        Serial.print( F("Average daily energy over last 4 weeks :") );
        Serial.println( average_daily_energy );
    }
    void print_day_status(){
        Serial.print( F("Yesterday's energy :") );
        Serial.println( daily_energy[0] );
        Serial.print( F("average daily energy over the last 7 complete days: ") );
        int sum = 0;
        for( int i=0; i<7; i++ ){
            sum += daily_energy[i];
        };
        int average = sum/7;
        Serial.println( average );
    }

In other words, rather than storing every detail of every day for the last 27 days,
(a) store 7 or so values of detailed daily information for the past 7 or so days, and also
(b) store 4 or so "summarized" values of total or average information for each of the past 4 or so weeks.


message:
What overheads and other considerations are there when using a struct vs a class?

C on embedded systems has traditionally use structs to hold structured data.

Arduino brings C++ to the table, so we can use classes instead.

Lets say we have two different data structures which could be considered very similar:

    typedef struct
    {
     int valueOne;
     int valueTwo;
     int valueThree;
    } value_t;

and:

    class Value
    {
     public:
      int valueOne;
      int valueTwo;
      int valueThree;
    }

In terms of memory, what difference will this make?

I still see the struct technique being used heavily - why is this?

body:
As taken from the accepted answer from [When should you use a class vs a struct in C++?][1]

> The only difference between a class and a struct in C++ is that
> structs have default public members and bases and classes have default
> private members and bases. Both classes and structs can have a mixture
> of public and private members, can use inheritance, and can have
> member functions.
>
> I would recommend using structs as plain-old-data structures without
> any class-like features, and using classes as aggregate data
> structures with private data and member functions.

Memory wise the access modifier makes no difference and given the memory constraints of the Arduino, people are less likely to use classes with complex hierarchies, but prefer the POD structs anyway.

  [1]: https://stackoverflow.com/a/54596/731620


body:
Unlike C, an instance of a `struct` in C++ is an object in exactly the same way as an instance of a `class`. From the point-of-view of the compiled code, they are identical. Memory usage, alignment, access times etc. are exactly the same (i.e. there are no overheads).

From the programmer's point-of-view, there is a very minor difference. Members of a `struct` have public visibility by default, whereas members of a `class` have private visibility by default. Otherwise, all language features work the same on both, such as constructors/destructors, inheritance, polymorphism, templates, and operator overloading. You can even derive a `struct` from a `class`, and vice versa.

Despite the similarity, it's quite common to see people deliberately using a `struct` in C++ for very simple structures, e.g. where it only consists of a few data members, but no functions. A `class` would be used for anything more complex. This is purely a matter of convention or personal preference though, and can be used as a subtle indication of the structure's intended complexity.


body: As other answers have pointed out, your particular `struct` and `class` are indistinguishable performance wise (There are slight differences in the scopes of the type names, due to the way you defined your struct). The delineation in C++ is not between `struct` and `class`, but between types that are *POD (plain old data)* and types that are not, as explained in [this discussion](https://stackoverflow.com/questions/146452/what-are-pod-types-in-c).


body:
Note that

    typedef struct { ... } Foo;

is obsolete in C++ and you should just use

    struct Foo { ... };

It's not very clear in the answers but the other effect of structs is public inheritance by default vs private inheritance by default with classes.

As mentioned by others, using struct is generally a convention for POD types.

Also technically 'struct vs object' should be 'struct vs class' (as instantiating a struct or a class still gives an object).


body:
> In terms of memory, what difference will this make?

None. Structs and classes are the same thing, differing only in protection levels, and instantiating either creates an 'object'.

> still see the struct technique being used heavily - why is this?

Less typing if you're not trying to hide data members.


message:
Powering Arduino with Solar Panels

Clearly, an Arduino can be powered with solar panels.

 1. What is the most optimal configuration?
 2. Can you recharge and discharge at the same time?
 3. Is LiPO the best battery cache technology, or is there something more durable out there, for fielded deployment?
 4. What are the most economic, and reliable ways to do this?

body:
**First of all you want to buy some solar panels or cells.** Although they can be found on eBay for very cheap, but they not be as efficient as they say. I would say try to buy from a reputable dealer to see reviews on the product or trust that they work efficiently. Sparkfun datasheets are generally accurate and can be trusted.

 - Most optimal configuration: **Do not use a regulator and some sort of step-up booster.** Try the TPS61200 or TPS61202 chips. They will not *regulate* the voltage, they *boost* the voltage dynamically. This is much more efficient and therefore generates less heat. They work like a reverse voltage regulator, taking .3V to 5.5V and turning it into anywhere from 1.8V to 5V (xxx0) or 5V exactly (xxx2). Hack a USB B end and just connect the power lines to the Arduino.
 - Discharge/charge simultaneously: Yes, however I'm not sure how to. I believe that if you hook up a charger IC and a load, the voltage won't go through the battery, it will go through the path of least resistance. However, your battery wouldn't get charged then. This is outside the scope of the question, so I would recommend EE on how exactly to do this.
 - Is LiPO the best: **Try a Lithium-Ion Battery.** (A.K.A. Li-ion) According to [this site](http://www.androidauthority.com/lithium-ion-vs-lithium-polymer-whats-the-difference-27608/):
> Although the lithium-polymer battery is sleeker and thinner, lithium-ion batteries have a higher energy density and cost less to manufacture.

 Therefore, it seems like Li-ion is the best choice for you. **Note: Since you are dealing with very dense batteries that [if overvolted can go up into flames [Note: please mute your speakers!]](https://www.youtube.com/watch?v=SMy2_qNO2Y0&feature=youtu.be&t=2m), make *sure* to go with Sparkfun/Adafruit/etc...**

 - Economic way: If you don't mind a big "homemade" solar panel, go this way. Buy through eBay or a similar site solar *cells*. They are small plates that are connected to create a solar panel. Try looking for "grade B" or similar solar cells that work fine, they just may have minor imperfections. It won't be as pretty, but you'll save some cash.

See [this EE.SE post for more information](https://electronics.stackexchange.com/questions/85757/how-do-i-go-about-building-a-charger-circuit). One cool thing that I saw was:
> This is really cool. You can connect the Li-Ion voltage through an op-amp to generate a pulse wave, which can be picked up by your MPU to tell your bot to go charge –  Raaj Oct 18 '13 at 18:44

I'm not exactly sure how to do this, but it might be useful. I couldn't find anything online about it.