text:
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.

Have you tried to reflash the bootloader? Is it blinking with your current sketch, or a previous sketch?

Any sketches? Does that mean you've tested something really simple, like blink? http://arduino.cc/en/tutorial/blink#.UxXkwF6IuWY

Yes I tried blink !

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.

check the fuses as well

@zmo: checking the fuses is somewhat pointless. They're not actual fuses which can break, but PTC resistors which self-repair.

The fuses referred to control processor behaviour. They are not PTC resistors and don't self-repair. See the datasheet for the processor under the "fuses" section.

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.

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.

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).


text:
Arduino motor shield orange/white pin usage
I have an Arduino motor shield like this one plugged into my Mega board.

I would like to know some more information about the orange and white pin blocks on the board. The Arduino website 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!

The Arduino forum has some info you might find useful: http://forum.arduino.cc/index.php?topic=94474.0

Thanks @akellyirl, that is definitely helpful. Not what I was hoping for, but I'm not surprised... I'll just have to extend the 3-wire cable from the servo with individual connectors to go to separate pins on the Arduino as necessary. (I don't particularly want to splice the connector) Oh well!

For what it's worth, Adafruit do a Motor Shield that brings out pins for 2 servos: http://learn.adafruit.com/adafruit-motor-shield-v2-for-arduino/overview

TWI = Two Wire Interface (the other 2 pins are power and gnd). This is just a renaming of a possibly incomplete implementation of I²C bus, see: http://en.wikipedia.org/wiki/I%C2%B2C#Derivative_technologies

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 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.

...which pins are mapped to the data pins etc.

The shield page provides a schematic

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

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.

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

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

The power outputs of L298 intended to drive the motor are the blue screw connectors.

@bladepanthera also remember when you see the tilde ~ on an Arduino board, they are reminding us these pins support PWM. Also, when using connectors, the concept of "in" and "out" are suggestions. I'd rather see A2, A3 to remind us it is capable of analog input.

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.

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.

source: Stack Exchange

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

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

sort: votes


text:
What are the FLASH_ARRAY/FLASH_TABLE macros in this code?
In this code 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});

After further digging, this appears to be from Mikal Hart's Flash library.
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.

Could you add an explanation of the macros within the answer? This answer contains only a link and won't be of much use, if the link goes offline.

Cybergibbons, this is nice, handy and useful, but this adds definitely a non trivial overhead: it's encapsulating an object within a full instance. When you only got 2k of RAM, every byte is precious.

The flash array is from Mikal Hart's flash library as you show, and what it does is that they declare an array or a matrix (table) object in the PROGMEM memory:
#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 which is a replacement for the PROGMEM macro, simplifying the whole stuff:
// 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. In case you want to keep a code compatible with older version of avr-gcc, here's a post that offers macros to deal with both systems.

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


text:
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.

You probably want to use a thermocouple. It'll give you the ability to measure much higher temps than regular temperature sensor. You'll also need a IC like the MAX6675 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.

Page 6 of the datasheet 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.

One of the options to measure high temperatures would be to use thermocouples. This table provides a basic description of the types and the corresponding temperatures that they can sense.
A simple search led me to these components.

Thermocouple Type-K Glass Braid Insulated - A mid range thermocouple
Thermocouple Amplifier MAX31855 breakout board - 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.

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

This is an image of the thermocouple interfaced with the Arduino.


text:
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.

If I understand you correctly, you want to store the data recorded from an Arduino Uno through serial on a Raspberry Pi?

not necessarily the Pi, but in my case, yes

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!


text:
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)

your second option pinMode(pinnumber,input) is placing the pin in the "third state" of the pin, which is also called "high impedency". It's basically like if the pin was not connected to the circuit, like a ohmmeter does.

"digitWrite"? Don't you mean "digitalWrite"?

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 ["Input and Output" section], I never tried more). If you need more current, use a transistor (this 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.

Thanks, the current also comes from the IO pins of Arduino. Therefore, i don't think 40mA limit will be a issue.

@rajat Doing some sort of LED matrix ? Be careful, assuming you plug (for example) a high current LED between two pins (at least without a proper current limiting resistor), you could still damage the chip. Not even mentioning the case where you create a short circuit.

It is a pressure sensor matrix, it has 10 16:1 multiplexers. The current only comes from the Arduino USB cable and no external power supply.Therefore, i don't think high current will be a issue. Can you shed some light on what possibly can cause a short circuit?

@rajat something like that would create a short if pin "1" and "2" are connected : pinMode(pinnumber1,OUTPUT); pinMode(pinnumber2,OUTPUT); digitalWrite(pinnumber1,LOW); digitalWrite(pinnumber2,HIGH); PS : do not try this at home, do not harm innocent arduini, do not sue me, etc...

i was doing exactly this right now. Runs to check if innocent Arduino is fine. Thank god, it's fine :). Why would this damage the Arduino ? So, we can't supply any current when the pin is configured as OUTPUT?

PS (oops too late for edit) : read "connected directly", just to prevent any misunderstanding

@rajat If you do as I (do not) suggest, basically it's like plugging a wire between the + and -/0/GND poles of your battery/power supply. Except here the wire is your chip. If there is (sufficient) resistance between the pins you should be ok. But I'm starting to suspect some confusion here, maybe you could post another question with (the relevant part of) your schematic.

let us continue this discussion in chat

I was a bit surprised by the 6/9mA number. Turns out you’re correct for the Arduino Due, but for the AVR based Arduinos (Uno, etc), which I suspect are still in the vast majority, that number is more like 40mA.

@microtherion Indeed, I was similarly mistaken originally (see the editing history), the Due uses a rather different chip than the other Arduini.

Setting a digitalPIN to LOW give 0V. Not GND!!


text:
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);

}

Well, this question has been wisely answered in an answer to Stack Overflow question C: differences between char pointer and array.
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, 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, the __flash qualifier is a third solution ;-)

I totally agree on the "simpler is better" - the array s far clearer. I just always get interested when something isn't immediately obvious.

F() returns FlashStringHelper which is essentially the same, but using PSTR() works fine (as long as you bring the consts inside a function).

indeed, I actually suggested first the PSTR() macro but changed to F() before submitting, because your consts are global ones in your Q, so I preferred to stick with the one that should work in both contexts.

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.


text:
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.

You'll need something like the Ethernet Shield to connect your Arduino Uno to a LAN.
As for webserver functionality, the Webserver Example sketch does the bulk of what you need.

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 to the Arduino Wifi shield.

it's easier to let the arduino just emit periodic UDP packets with the relevant data and have another computer do the heavy lifting of hosting the webserver (and it can do logging)

It's important to note that many new users to Arduino don't realise quite how small it is, and how limited a web server you can build. Don't even expect anything near to a home router's config pages in complexity.

UDP is great, but don't forget that UDP is open to packet loss. If you need each and every sample you'd need to make sure you send it multiple times. Then you'd also need to timestamp or identify it. So UDP can become cumbersome. The Original Poster requested info on implementing a Server. The data sent can be as little as just the temperature value. We shouldn't assume a fancy Webpage is required.

@akellyirl with a direct connection and one-way traffic (or connected to a switch with store-and-forward) there will be no packet loss unless the cable is bad

The Arduino Yún has been made with this use case in mind. The Bridge library 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


text:
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).

That's a symptom that maybe just the MCU pin 3 is damaged. But it would help to know how your initial circuit (the one that may have caused the damage) and the blinking circuits were wired. Could you please post some schematics?

If your Arduino board holds the MCU in a socket (like the Uno), and you have a spare ATmega laying around, you can try and replace the MCU and test it again with your blinking program to see if pin 3 makes the LED blink. Just to check, you do have current limiting resistors between your IO pins and your LEDs, and you aren't (and weren't) drawing more than 20mA from each pin and 200mA overall from your MCU, right?

That's all assuming you're using ATmega's...

Or, if you don't have a socketed ATmega or an extra one lying around, you may want to acquire a whole other arduino and test with that to see if you can replicate the behavior. You don't necessarily need to buy the exact same model as the one you're experiencing the problem with, but that would be the best way to identify a problem with your code running on your original board.

Could you tell what you have plugged to each of pins 2 to 11? You may get erratic behavior (if not worse) if you source or sink too much current through many pins altogether (Arduino total current limits).

My wiring for testing = using a voltmeter.
The wiring for the actual project is running an array of electromagnets through motorbridges with never more than one pin on at a time. The set-up has worked for weeks with no bugs. It is bread-boarded, so I figured that was the problem at first. However the behavior is reproducible when only connect to a voltmeter.

It is an Arduino Uno, and I replaced the chip using a similar Atmega chip but not the same (ATMEGA328-PU 1135 to a ATMEGA328-PU 1036). The replacement has a different firmware (Duemilanove I think). I could get the blinker test program to run without a hitch, but the new chip doesn't handle serial communications well (something my project relies on) so I couldn't get it to work with my original code.

Here's the actual project here, if that will help anything.

The 4-digit number is a date code. You replaced it with the same chip made almost a year earlier.

imho, breadboards are for only the first moments of a design. Please please please get and use a sensor shield: https://www.google.com/search?q=sensor+shield Fritzing is also invaluable for illustrating circuits.

@e2r2i2k2 Do you use your voltmeter directly between the pin and the ground? It's not the right way to measure a voltage, you should at least put a resistor between the pin and the ground.

@e2r2i2k2 did you flash the UNO bootloader onto the ATmega after you replaced it? By the way, is there a reason why you replaced it?

@jfpoilpret I replaced the chip for debugging. And yes, I was using a current limiting resistor for volt testing. I'm short of a one part to put together a bootloader installer set-up, so I'll try that when the part comes.

If you require a current limiting resistor for voltage testing then your DMM is damaged :/

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.


text:
How cold or hot can my Arduino Uno get?
The Arduino Uno Page 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).

Importantly, have you considered that the temperatures quoted in weather reports is a shade air temperature? If you place an Arduino in the sun, the temperature according to the weather report might be 40ºC, the board could get up to 80,100 or even 120ºC.

@Cybergibbons Most projects outdoors would be placed in an enclosure that doesn't allow sunlight.

How does an enclosure stop sunlight? The enclosure will get hot instead of the board, but you can get extreme temperatures.

@Cybergibbons It would still help and serve as insulation as long as it wasn't opaque. For my situation though, it's in a garage.

so what is the conclusion? is Raspberry pi suitbale or arduino at such high temperatures?

It's not that big of deal. The ATmega 328p datasheet states this:

Temperature range: -40 to 85 degrees celsius.

The same goes for the USB chip on the Uno (ATmega 16u2 for UNO R3).
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.

Values from datasheets commonly mentioned under "Absolute maximum" are absolute maximum, there is no engineering tolerance there. The manufacturer will not guarantee operation outside those boundaries and anything can happen if you do operate the device outside them. You may be lucky, but why wouldn't they mention the higher spec in the datasheet? Wider spec means wider possible application than competing components and possibly more revenue.

Capacitors vary a lot more then 8%, particularly if they're a cheaper tempco dielectric. Y5V/Z5U are specified to -22 % to +56 % over the range of 10 °C to 55 °C, and they're probably only 20% accurate parts to begin with (precision capacitors are expensive, and why bother when it's for decoupling). Also, the Uno uses a resonator, not a crystal (PN: CSTCE16MOV53-R0), which  has ±0.5% initial accuracy, and ±0.3% over -20 to +80°C. While the ATmega328P can operate up to 20 Mhz, this can potentially cause baud-rate error issues.

Probably the biggest issue with cold temperatures is the fact that almost all battery chemistries completely crap out in the cold. Similar problems are also likely to happen with the electrolytic capacitors, which are likely only 0°-85° parts.

@jippie All I'm saying is that going -41 degrees isn't going to kill your chip. It's not great for it, but if you go only a few degrees under specs a few times a year, it should be fine. I'll clarify my answer.

@FakeName Most projects out in the cold [for capacitors] won't need that much precision, especially for the main use on the Arduino. However, you are right. I'll add that to my answer. Also for the batteries, that is included under the other components not on the board will happily run in the temperatures. However, you are right.

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.

You can spray or brush the board with Conformal Coating to prevent moisture problems.  Cover any connector openings first to prevent contact problems. https://www.mouser.com/Search/Refine.aspx?Keyword=conformal+coating

For hot temperature, just follow the datasheet.
For low temperature, I remember someone last year trying to overclock a UNO with liquid nitrogen so I guess you won't ever meet any problems with low temps :-)
In his blog, 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.

Wow. 65 MHz on the Uno.

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.

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.


text:
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?

car batteries are 12.5V most arduinos can take 12.5V, add a fuse/surge protector and you're set

Auto batteries are 13.8v optimal, but the actual voltage can vary on its charge condition, physical condition, and power load. While the built-in regulator on most Arduino boards can step this down, it may result in high temperatures (if no heatsink on the on-board regulator); and the electrical noise from the vehicle ignition/devices may cause havoc on data transfers to/from the Ardiuno. A suitably rated buck converter with appropriate filtering would probable be the best choice.

@ratchetfreak I agree with Ron. It'll probably overheat, especially in the summer.

@Ron I agree. One thing to note: IIRC the onboard Uno regulator has some sort of heat sink build into the PCB that's designed to cool it from beneath.

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

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, overheating, etc.

10 for 11$ right now on eBay. Sounds good to me.

@0xF2 You can get single ones for $0.99 so don't fall for than "cheap" ten piece package

While a better idea than a linear regulator, bear in mind that LM2596 switchers have a quiescent current of around 5ma (possibly more in a given implementation) which is a many times the power consumption of a sleeping or even slowly clocked ATmega.

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

Can you please elaborate a bit more about how to attach one of the two or how they work/what they do?

A usb car charger normally has a bullet connector (thats what I have always called it) that goes into the cigarette lighter (12v accessory) socket on the car.  And it converts it to 5v and you can plug in a usb phone charger or in this case Arduino cable.

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.

Akafugu

"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.

A linear regulator is a poor choice - between this and the one on the Arduino itself, over half of the consumed energy will simply be wasted as heat.  All that is really being accomplished here is (possibly) some input protection and moving some of the heat dissipation off board rather than concentrating it all in the on-board regulator.

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

Smart Power Base
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

images are broken

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.


text:
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
}

I have recorded the actual RESET pulse at serial connect (it is about 1 ms, depending on trigger levels).

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.

I understand that, however this is affecting my script because it means the script plots garbage at the start, my question is can I stop this from occuring. From where I see it, it is something I need to change in the Arduino sketch first.

I removed millis() and used a counter instead inside my loop. However when I try to send a start signal to my serial port, using ser.write('S') on Python, the arduino doesn't receieve it

You could try putting something in your setup function, like while (Serial.read() != 'S');

It's fine on the Arduino end of things, when I open the serial monitor, it happily prints, the problem is in Python, when I try to send the 'S' byte, the serial port appears not to receive it.

Take a look at if(Serial)
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:

Have Python send something to Arduino after it connects.
Wait until this is received in setup(): if (Serial.available() > 0) {...}
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);
    }

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.


text:
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?

What platform are you on?

@jippie Peppermint Linux

Does ls -l /dev/ttyACM* list the exact device that is mentioned in the error message, and is this the exact device set in the Arduino IDE under Tools => Serial Port?

/dev/ttyACM1 was the port to the board until it got disconnected. So in short, when I click upload, it starts uploading then stops half way through and prints out the error message mentioned in the question above. I know the IDE is what is disconnecting the board. What I want to know is why!

Are any devices / peripherals connected to the Arduino? If so, disconnect everything then try to program it.

Please consider switching to a more recent version of the IDE: version 1.5.6 has replaced buggy and old RXTX library with JSSC. Updating may not solve your problem, but at least it makes sure you're not facing old and already solved problems.

I'm having a similar situation on my older work computer.. I feel like it is the hardware on the computer (HP xw9400 Workstation) that is causing the the Arduino to keep connecting and diconnecting. Perhaps it is a low power signature coming in from the Arduino that the usb port "loses" the Arduino. I will try with another computer to see if this is the case.

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:

Does the device file exist in  the /dev tree? ls -l /dev/ttyACM*
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

If another application is using the device, how come I can still upload to the board from ino?

@FadiHannaAL-Kass Good question. Did fuser or lsof list a PID? Maybe there is something else going on.

@FadiHannaAL-Kass For example, I have a daemon running on my PC that queries my Arduino only every so many seconds. If I am attempting to program that Arduino, and the query comes along, then the program cycle fails. Maybe some serial monitoring program is running?

I have already used ls -al to make sure the device exists. I also unplugged the board and ran the command again to make sure I am looking for the right device. The Arduino IDE is pointing to the right port as well. When I upload and get the error message, the Tools --> Serial Port menu gets disables, so that's another way to know the device has been disconnected while uploading. lsofand fuser, however, don't list a PID, so now I also know no other application is interrupting the upload process!

I might be able to get away with Installing a new Linux version, but I want to be prepared in case this happens ever again

@FadiHannaAL-Kass Reinstalling Linux is not going to solve your issue. In the Windows world people reboot their system, reinstall their machine. In the Unix/Linux world, we figure out why things happen and fix them.

It most likely will, as I have performe the exact same process on a different Linux distro on the same machine, and everything worked fine

@FadiHannaAL-Kass isn't it more effective to figure out why things go wrong and subsequently fix them, rather than reinstalling your PC every time something happens that you don't understand (yet)?

exactly. that's why I said I want to be prepared in case this ever happens again

A pretty detailed troubleshooting guide is available at arduino.cc. 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, so this doesn't apply if you don't use one, or use a modified version.

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. ;-)

Does the baud rate in the serial monitor affect the uploading process? I'm not so sure it does but Arduino can be quirky sometimes ;)

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

Actually, setting the baud to 14400 is exactly where my issues started too.

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


text:
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 ();
}

Which MCU? What clock frequency?

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


text:
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?

Do you have an LED and resistor near you? Try blinking it using A2.

This is a very long-shot, but have you tried connecting all the other analog pins to ground while testing A2? Floating analog pins can sometimes cause problems (although it seems very unlikely in this case).

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.

The Redboards use soldered TQFP ATMega328, so unless you're interested in doing a SMT hot-air rework to replace the microcontroller, you're stuck with a dead pin. Luckily it could've been worse.


text:
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?

Do you want to be able to program your Arduino once it has been overclocked? In that case the answer is probably 0%.

You probably get a higher and more reliable performance improvement by reviewing your code and ditching some standard Arduino libraries.

See the following question

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.

Very interesting data about the actual clock rate supported. As for the only way to upload code, maybe it would be easier to use ISP instead of a serial boot loader in such a setup?


text:
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:

Black wire(signal 1)
Black wire(signal 2)
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:

What are the input [likely] voltages for the unit (or how could I establish this)?
How do I wire the unit to an arduino?
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.

Do you have a link to the gas meter documentation or the name of the meter?

Do you have access to an oscilloscope? That would make things very easy.

I have had some success using an SG-2BC as a photoreflector, details of my build are here https://github.com/Bra1nK/HomeMonitor/tree/master/Gas%20Meter%20Pulse%20Creator

Most connections into meters are open-collector or volt-free i.e. a relay or NPN transistor.

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.

thanks @dgriffith, I'll give it a bash. so you think the two black wires are the same signal inverted? Why bother?