text:
Getting a long avrdude error while uploading a simple sketch to arduino uno
This is the error which shows up after the sketch is compiled and starts uploading.
Is there some sort of fix to this problem?
There are no shields connected to it, not even I/O pins are being used, just trying the simple Blink sketch.
NOTE : It was working find before and then it started acting crazy
    Binary sketch size: 1,084 bytes (of a 32,256 byte maximum)
C:\Program Files (x86)\Arduino\hardware/tools/avr/bin/avrdude -CC:\Program Files (x86)\Arduino\hardware/tools/avr/etc/avrdude.conf -v -v -v -v -patmega328p -carduino -P\\.\COM3 -b115200 -D -Uflash:w:G:\Temp\build5658632448223358877.tmp\Blink.cpp.hex:i

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

         System wide configuration file is "C:\Program Files (x86)\Arduino\hardware/tools/avr/etc/avrdude.conf"

         Using Port                    : \\.\COM3
         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 "G:\Temp\build5658632448223358877.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.27s

avrdude: 1084 bytes of flash written
avrdude: verifying flash memory against G:\Temp\build5658632448223358877.tmp\Blink.cpp.hex:
avrdude: load data flash data from input file G:\Temp\build5658632448223358877.tmp\Blink.cpp.hex:
avrdude: input file G:\Temp\build5658632448223358877.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: . [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]
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: # [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]
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: . [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]
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: . [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]
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: . [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]
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: . [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]
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: . [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]
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: . [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]
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: . [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]
avrdude: Recv: . [10]
### | 100% 0.20s

avrdude: verifying ...
avrdude: 1084 bytes of flash verified
avrdude: Send: Q [51]   [20]
avrdude: Recv: . [14]
avrdude: Recv: . [10]

avrdude done.  Thank you.

Did you try turning verbose output off?

Actually that did work, Thanks ;) But is there something wrong with the arduino and what does the verbose mean ? THanks

I see no error in this output. I can just that avrdude was called with -v -v -v -v which tells it to be very verbose. You have to remove that option (IIRC you can do this in Arduino IDE preferences dialog, otherwise you can take a look at avrdude.conf file , find this option and change it)

This is not an error. AVRDude is running with the Verbose flag on. Verbose in English means:

using or expressed in more words than are needed.

In the Arduino IDE:


text:
Arduino communicating back and forth with PHP server
I am researching to find the best method to work with in order to control the arduino from a web interface (hosted on a web server using PHP) and also sending data from arduino to webserver and save to mySql.
2 methods which I have found that a lot use are save the data to a text file or in the url.
Which is the best or are there any better methods?

How much data are you sending back and forth?

If you are sending large amounts of data, you might consider sending it in chunks, and processing the data as you receive it.

How are the server and the Arduino physically connected?

I would suggest your best bet would be to pass messages back and forth via JSON, via Get/Post http request.
So to send data, you send a POST request (to the PHP server) with your data in JSON in the content.  To get instructions, you send a GET request to the PHP server and get a contents field with JSON in it.

Upvote for technology invented after 1999

It sounds like your first need is a way to send the bytes back and forth.  A secondary question will be what that data should consist of (eg: text commands, binary commands, etc).  Let's tackle the "how" first.
You have described two dynamics to the communication between server and Arduino:

The arduino "sends data to the server" where PHP code will save it
to MySQL; if your Arduino can be an internet client (eg: has an
ethernet or wifi interface), it could use GET or POST (or PUT) HTTP calls to
php code.  GET is easiest, but normally GET calls shouldn't change the server, only
query it -- but many people make exceptions for small devices and small
amounts of data which can be encoded in the URL.
The web server "controls the Arduino".  Unless the Arduino sets up
an internet server, it is going to have to poll the web server from
time to time to find out what it should do (ie: to be controlled).
It can pretty easily use a GET to fetch some text which it can
interpret.

I'm guessing that HTTP will be the easiest path for communicating, because you probably understand that if you are a PHP programmer, and because it can often get through firewalls more easily if that matters; but a simple TCP socket or UDP datagrams are also possible.
Once you can send blocks of bytes between the server and the Arduino, you can focus on what those bytes should contain.  That could be simple text commands, or some binary protocol, or even the MQTT protocol transactions that another answer references.  You haven't given enough info to help select the protocol and format, so I'm assuming you are mostly looking at this time for the method of communicating, as described above.  If you want to ask about the format of what to send back and forth once you have the data flowing, please make that a new question.  You can test the basics by just sending a "Hello" text string between server and Arduino.

Another method is to use MQTT. That's a protocol often used for embedded messaging. Find here the (one of the?) arduino client.
As a server you can install mosquitto either on the same system running the web server, or on a different one.
Than the communication logic with php will be done with mosqitto-php
advantages:

decoupling the web server(s) from the arduino(s)
lightweight protocol for the arduino
easy interface with more applications (eg, storing data in mysql, independently of the web server, or any new in the future)

disadvantages:

few more work setting up the mosquitto server.

If it's not too much data, a textfile as a database should suffice, if you want something more scalable; I'm quite impressed with node.js: http://weworkweplay.com/play/raspberry-pi-nodejs/

Buy a uart wifi such as WiFly series chip. You can control e chip via UART AT command. The chip capable of sending http post get to/from a server.
See this guide as an example
http://the.machini.st/posts/35

source: Stack Exchange

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

sort: votes


text:
Arduino - My problem is when the condition is greater than 900.00 it will continue the loop and do the code below once
I want is to stop the loop and when it read  Greater than 900.00 again it will do task again.
I need condition. When it back to greater than 900.00 the code below will do task and then it will stop. And when it will reach the condition again it will do the code again and it will stop .. Please help me
void loop(){
  float reading = analogRead(LIGHTSENSORPIN); //Read light level
  float square_ratio = reading / 1023.0;      //Get percent of maximum value (1023)
  square_ratio = pow(square_ratio, 2.0);      //Square to make response more obvious

  analogWrite(LEDPIN, 255.0 * square_ratio);  //Adjust LED brightness relatively
  analogWrite(LED_BUILTIN, 255.0 * square_ratio);  //Adjust LED brightness relatively
  Serial.println(reading);                    //Display reading in serial monitor

if(reading >= 900.00){

  digitalWrite(smDirectionPin, LOW); //Writes the direction to the EasyDriver DIR pin. (LOW is counter clockwise).
    /*Turns the motor fast 1600 steps*/
      for (int i = 0; i < 400; i++){
    digitalWrite(smStepPin, HIGH);
    delayMicroseconds(700);
    digitalWrite(smStepPin, LOW);
    delayMicroseconds(700);
}
}

  delay(1000);

}

You need to also store the old reading. Then change the if to if(oldReading<900.00 and reading>=900.00)

how can i store the old reading??

Please post your code, instead of an image.

Sir can u please modify my code to do that?

anybody can help?? please..

how can i store the old reading??  the first line in loop() stores  a reading .... the second line did something with that reading and stored the result

setup(){ ....
......
}
float old_reading=0;
loop() {
float reading = analogRead(LIGHTSENSORPIN); //Read light level
// ... do this always (maybe empty)
// in your code it is LED shining and printing
if ((old_reading<=900) && (reading>900)) {
   // ... do this just just once when reading goes over 900 up
   // in your code it is manipulating motor
   }
old_reading=reading;
// ... do this always , but after special part (maybe empty)
// in your code it is just delay
}

So on begining old_reading is just zero, but being declared outside loop, it keeps its value between different runs of loop.
the if (condition) does not hit, as reading is less than 900 (if it starts with more then 900, see next part)
the end with old_reading=reading; makes old_reading to be the last known value of reading
when reading goes Greater than 900 for first time, the old_reading is Less or Equal 900 (as it was the last value of reading before it crossed 900 up.

so the if (condiotion) is true and you start moving motor

then (on the end) you set old_reading=reading; and old_reading is also larger then 900

while reading stays over 900 in next loops, the old_reading does so, and therefore the if (condition) does not hit - (old_reading<=900) is not true

when reading falls down 900 or lower, the if(condition) also does not hit, but after that the old_reading=reading; makes old_reading less or equal 900

and so we are at the start again, skipping the part after if(condition) until reading gets Greater than 900 (then we run motor, set old_reading to something greater than 900 and we already was here and know, how it works :)

Thank you sir gilhad... i appreciate your time and effort doing this.. keep helping others

:) This is just basic programming (not even about Arduino) - you really should read more articles/books about programming and read examples and shorter programs and try to understand it by yourself - it will give much more understanding. I suggest to read arduino.cc and/or other sites about arduino and about programming for beginers. Really pays off in long term :)

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


text:
MPU6050 Accelerometer freezes/glitches after acceleration
I am trying to do rotational vector calculation using a MPU6050 chip which actually work really well with not too much drift when I rotate the MPU slowly. However, when I accelerate too much, e.g. change direction in my slow rotations or just slightly tap the breadboard with my finger, the values completely go nuts.
I am using an ESP8266 chip to control the chip and I have tried multiple libraries for reading the Gyro/Accelerometer values which all have more or less the same behaviour.
My accelerometer readings from the Serial plotter, before and after the light tap to the breadboard:

Gyroscope does the same thing. The MPU is new (just arrived in the mail few hours ago), I power it using 3.3V and use 3.3V GPIO logic from the ESP chip.
Does anyone know what could be causing this?

I think the key word here is "breadboard". Hardly a stable environment for signals...

@Majenko should I try it on a PCB? I thought so too but why does the problem always occur when the acceleration changes, and immediately goes away after I restart everything?

Probably the sudden change in acceleration makes one of the connections move and communication gets out of sync in some way, or makes the chip get a bad instruction that changes some random setting.

@Majenko Okay, I am going to try to put the circuit on a PCB and see if that helps. Thank you for the suggestion.

@Majenko I have soldered everything now and everything is working perfectly now, thank you so much I have been at this for hours! Thank you very much! It only starts doing this again when I pull so hard on it that the power cable disconnects :D

Your problems are (most likely) related to loose connections in the breadboard. Sudden movements can cause power to be interrupted briefly, or data signals to become corrupted.
Breadboards aren't great for prototyping anything that moves, even slightly.

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


text:
CH340G and CP2102 devices not recognized with Thinkpad L380
I have three different devices, none of them gets recognized on my new Thinkpad L380 running Windows 10:

Arduino Nano Clone with CH340G chip (USB2Serial)
NodeMCU (Lolin V3) with CH 340G chip (USB2Serial)
NodeMCU (ESP-WROOM-32) with CP2102 chip (USB2UART)

All three of them are recognized properly both on my desktop computer running Windows 10 (on USB 2.0 ports) as well as on my other laptop (Acer Switch Alpha 12, Win10, USB 3.0 port).
But even after hours of trying I was not able to connect those devices to my Thinkpad.
Things I've tried so far:

Of course, simply installing the Arduino IDE and try plug'n'play
Downloading and installing the CH340G driver from the official website
Disabling Secure Boot, enabling testsigning mode and reinstalling the CH340G driver
For the CP2102 device I only tried installing the driver under "normal" Windows (e.g. no testsigning enabled) since it also worked that way on my desktop computer

I have to admit that it's been a while since I set up the drivers on my other laptop and desktop computer, but I cannot remember that there was anything unusual I had to do back then.
Does anybody else know about problems regarding Thinkpad laptops? At first I thought USB 3.0 might be the problem, but the Acer laptop works just fine with the USB 3.0 port.
Update
Somehow the laptop now at least recognizes the Arduino Nano clone in the device manager and I can choose the COM port in the Arduino IDE. I can't tell what made the difference. All I did was to plug in a dongle for a wireless mouse in the USB ports to verify that they are working with "normal" devices and afterwards the Nano was recognized at least with a yellow "!" in the device manager. I then was able to uninstall the CH340 drivers and reinstall them. The device manager now displays the Nano as correctly installed.
But uploading a sketch fails. It outputs the errors:
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 9 of 10: not in sync: resp=0x0a
avrdude: ser_send(): write error: sorry no info avail
avrdude: ser_recv(): read error: Access denied

The RX LED is faintly blinking in red at the beginning of the process, then the upload seems to get stuck until the error messages are displayed.
The NodeMCU Lolin V3 with the same CH340 chip is still not recognized, though.
Serial communication (with the Serial monitor of the Arduino IDE) is now possible. I uploaded the "ASCIITable" example using my Desktop PC, connected the Arduino to the ThinkPad and could successfully read the output over the serial interface.

Using the CP2102 drivers from silabs will fail if your CP2102 is fake (as about 80% are). There are special "hacked" drivers you need (no idea where they are, I use Linux which never has any of these issues).

Since the driver works on my Desktop Computer, I assume this should not be the problem. Anyway it would still not explain the behavior of the CH340G devices.

I recently bought a cheap USB 2.o hub.
Turns out that the CH340G devices are recognised if I plug them in the hub rather than in the laptop directly. Maybe this helps somebody else who is searching for a solution, even though I can't explain why the hub is making a difference.


text:
Accessing one code using another code on RobotDyn Uno+WiFi board
Ok so I've been trying to do this for quite some time now. Still couldn't get it to work. I am trying to read a ESP8266 WiFi program from a normal Arduino Uno program. I've seen some people do this:
#include <SoftwareSerial.h>

Then
SoftwareSerial esp8266(2,3);

Let me see a working example of this?
Thanks for everything.

it is an additional Serial interface called esp8266. You can print to it and read from it by Stream functions. What else? https://www.arduino.cc/reference/en/language/functions/communication/stream/

Thanks, so from what I perceive, Stream is a library? If it is, I would go include it.

Stream is a common class from which Serial, SoftwareSerial and similar are derived

You can't 'access code'. You can write sketches to communicate for example over Serial or SoftwareSerial. You connect the pins of Serial interfaces RX to TX and let sketch in one MCU read or parse what the sketch in other MCU sent over Serial with print or write.

I am using this board:
Link I bought the board from
The WiFi shield is integrated with the board, so I think no need to connect the PINs?

You can't 'access code'. You can write sketches to communicate for example over Serial or SoftwareSerial. You connect the pins of Serial interfaces RX to TX and let sketch in one MCU read or parse what the sketch in other MCU sent over Serial with print or write.
The onboard connection on Uno+WiFi board is over Serial. So you can't use USB and connection to esp8266 at the same time. But you could use SoftwareSerial like other use it with esp8266, if you connect some pins (for example 6 and 7) of Uno headers to Serial of esp8266 which is accessible on the esp8266 header on the board.

So in order to communicate because Arduino sketch and the ESP8266 sketch, I must
[1] connect the TX and RX of Arduino to RX and TX of ESP8266
[2] use serial stream class to send and receive data between them
Am I correct?

RS and TX of esp8266 and Atmega are connected on board, if you set it on DIP switches. but then the connection to computer is out. all tutorials on Internet show you how to use SoftwareSerial to connect to esp8266 and have Serial connection over USB to computer. and you can achieve this SoftwareSerial connection with this board too. by wiring selected Atmega SoftwareSerial pins to RX and TX of esp8266 and setting the DIP switches to connect Serial of Atmega to computer over USB

So does it mean, if I use SoftwareSerial, I must use the external connection as it is required by the SoftwareSerial library and it does not occupy the physical USB serial port so I can still connect the board to computer?
If I don't want to use SoftwareSerial (and thus no need external wiring), what is the option I have to communicate between ESP8266 and Arduino sketches?

Switches 1 and 2 connect Atmega to esp8266. I recommend you to use this SoftwareSerial connection for developing the sketch. otherwise you would have hard time always switching the DIP switches for upload of sketch and you could not have debug prints in Serial Monitor.

A BIG thank you for your kind assistance and advice. I now have better understanding on how should I proceed.

a small note: the Mega+WiFi has it better. Atmega 2560 on board has more Serials so Serial3 can be connected to esp8266 and Serial to USB as usual

One more question. To upload sketch to ESP8266, I need to turn on DIP switch 5,6,7. To upload sketch to Atmega, I need to turn on DIP switch 3,4. So it means I still need to switch the DIP switches when I upload. Just in case I want to get rid of external wiring, I can turn on DIP switch 1,2? In the table it says Mega328+ESP8266 if 1,2 is ON, I guess it means Mega328 and ESP8266 can communicate if DIP is 1,2?

I'll take note on your advice on using Atmega2560 on board for my next project.

a good trick is uploading to esp8266 over WiFi with ArduinoOTA library. the you need to switch USB to esp8266 only if the OTA upload doesn't success

Thanks for the ArduinoOTA tips. I am running out of time for current project. Will definitely try it out on my next project. THANK YOU!!! You made my day.

Let us continue this discussion in chat.


text:
Arduino IDE - scope of the pre-processor "#define"
I'm creating an Arduino library and have 3 files - a "test.ino" program, and two library/class files: "testLibrary.h" and a "testLibrary.cpp".
The library makes use of some hardware-specific resources such as registers and ISRs that depend upon which I/O pin is used, and this should be done at compile time.
I would like to #define a pin number in the main program which, at compile time, is used in the library to determine which code sections are activated. Since this will be a standard Arduino library for use by others, it should compile and run without users having to change their compiler or #include path to make it work.
But it seems that the scope of #define in the main program/sketch does not extend to the library.
test.ino
#define PIN_NUMBER 3
#include "testLibrary.h"
void setup() {}
void loop() {}

testLibrary.h
#ifndef _TESTLIBRARY_h
#define _TESTLIBRARY_h
#ifndef PIN_NUMBER
#error PIN is not defined
#endif
class test {
public:
  test();
  ~test();
};
#endif

testLibrary.cpp
#include "testLibrary.h"
test::test(){}*
test::~test(){}

Compiling the above branches to "#error" using the Arduino IDE 1.8.13 and also using Visual Studio with Visual Micro.
Is there a way for me to have an Arduino library use a "#define" from the main sketch?

You actually didn't define PIN_NUMBER in your code. Or is that a copy&paste error?

You have two #endif but only one #if in testLibrary.h. This will cause a compilation error if you define PIN_NUMBER in your main code (test.ino) when it skips the #error in testLibrary.h. Maybe you did not notice the #endif without #if error? You can fix it by inserting #define _TESTLIBRARY_h as the first line of testLibrary.h. I.o.w. the scope of PIN_NUMBER will be global if you define it in test.ino. Try it.

It was indeed a copy-and-paste error, I put the first line of my code on the same line as the code-tags which meants that for each of my code snippets the first lines were missing. I've corrected that (@chrisl & StarCat)

You can use a library header file in more than one other libraries or applications. So the library header files should not be dependend on where they were used. Even if the preprocessor would allow defined local macros in included (header) files, it would be a very bad design. How can you know what the main app will do? That leads to horror errors for people using your lib.  If you need the value in the class, just add a property to the class and set it in the main code by your constant. The SoftwareSerial library does that to define the tx and rx pins for example.

Is there a special reason, why you want to use a define? The convention is to let the user provide such information as parameters for either the class constructor or the begin() method.

Since any pin on the Arduino can be used, I would need to define each and every INT or PCINT "ISR" in the library even though only one is needed, and that would preclude them being used elsewhere. Hence my wish of using a precompiler statement; if this value is passed as a parameter at runtime for this application it is too late.

does it work if you get rid of the cpp file (rename to .cpp.old)? I had to put a full library's code in the H file to get it recognizing defines before #including it. Works fine since the header file is just literally inserted into the ino at the point of the #include statement. Normally, code in the header is frowned up because it's easy to insert it more than once, but ino files are all concat'd together anyway, so there's no chance of that. Used in this way, it's just like pasting an extra ino file atop your sketch and works quite intuitively.

put another way: the error stems from testLibrary.cpp, not the header file, because as a different translation unit, the ino's macro isn't defined; it has to work as though the ino doesn't exist and the cpp and h file have all they need. afaik, there's simply no way to "pass" a value from an ino to a lib's cpp file.

Thanks for all the replies. I had feared as much, as the c++ documentation did lead me to  see that the scope of a "#define" is limited. @dandavis. In the end I am going to use the "BADISR_vect" as a catch-all and assume that the only undefined interrupt is the INTx or PCINTx for the pin, which will be passed to the library  as part of a "begin()" call at runtime. And instead of a compact series of "#define" statements that are computed at compile-time I'll have to use a more lengthy "switch(pin)" statement at runtime.

The scope of a #DEFINE macro is the translation unit. That is the current .c or .cpp file that is currently being compiled.
In you code PIN_NUMBER is defined in test.ino. The #include macro literaly copies the content of testLibrary.h into test.ino. So for the compiler this is working perfectly fine as PIN_NUMBER is defined.
Your testLibrary.cpp however is not happy with that. Including testLibrary.h for compilation lacks the definition of PIN_NUMBER.
The Arduino IDE is very limited and does not offer you a way to define PIN_NUMBER globally. This is usually done with the compiler argument -DPIN_NUMBER=3. All translation units will get this argument and thus the compilation would succeed. No need to define PIN_NUMBER in code.

Unfortunately adding a compiler argument is not a solution - the whole problem setting was due to attempting to make a standard library which any Arduino IDE user could simply download and include without having to make any subsequent changes.

In the answer to a similar question it’s suggested to put the #define in a header file that is then included into all the translation units (i.e., ino, c or cpp files) https://arduino.stackexchange.com/questions/23681/visibility-of-define-between-sketch-and-library


text:
Why PIN3 stays at 1v3 in a IR emitter project?
Here is my very simple IR emitter circuit.
OSI5FU5111C-40 is an infrared LED.

I am using the IRremote library from here
in this simple sketch,
#include <IRremote.h>
unsigned int raw[100]={... *SOME RAW SIGNAL* ...};
IRsend irsend;

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

void loop() {
  if (Serial.read() != -1) {
    for (int i = 0; i < 3; i++) {
      Serial.print("Start sending ...");
      irsend.sendRaw(raw, 100, 38);
      delay(40);
    }
  }
}

The problem is when I send 1 to serial monitor,
it outputs triple Start sending ... and LED emits no signal.
So I test the voltage between PIN3 and GND before and after sending the 1.
The voltage stays around 1V3.
Would someone please give me some advice? Thank you!

Just add a normal led instead of the ir-led, so you can at least see what is happening. Also note that when transmitting the led is pulsed at 38kHz, so your multimeter will some average voltage, and never the full 5 volt.

In addition to the duty cycle being averaged by a meter, the current drawn is likely enough that the output pin will be noticeably below the supply rail even during the fraction of time it is "on".  It should be noted that the LED itself is specified with a typical forward voltage of 1.35v so the anode of the LED will be limited to around that voltage, with the difference from the supply dropped across the resistor and the internal impedance of the ATmega.

You can also detect the IR with a cheap cell phone or digital camera.

A few things. As somebody else suggested, try a normal red LED and make sure that works first.
Note that your resistor is allowing too much current through the LED. A high-current LED might tolerate 20 mA (thousandths of an amp.) With a 47 ohm resistor, you're pumping 5/47, or about 106 mA into the LED, which is likely more than 5 times what it is designed to handle. You will quickly burn out your LED. You should use a 270 ohm resistor instead.
Also try just setting pin 3 to an output with this line:
pinMode(3, OUTPUT);

And then manually setting that pin to on:
digitalWrite(3, 1);

If the LED lights up, you know the pin is working correctly. Then use the code you posted with the same setup, and make sure your LED flashes. If THAT works, try putting your IR LED back in the circuit.

Bear in mind that ~1.5v is dropped across the LED, so only ~3.5v is going across the resistor. That means the current driving the LED is about 74 mA, which is below the rated maximum of 100 mA specified in the datasheet.

100 mA? Wowzers, that's a high current LED! (You'r right, I forgot to subtract out the voltage drop of the LED).

IR LEDs usually have a much higher If than visible light LEDs. Not that the pin is actually capable of sourcing that much, of course...

@IgnacioVazquez-Abrams - That's a good point -- attempting to draw that much current for any length of time is definitely not a good idea.

Thank you for all your comments. This is what I tried, I switched the IR LED to a normal LED, increased the resistor and tested with digitalWrite. It worked fine. Then I switched the sketch program without changing anything in the circuit. The LED failed to work. I tested PIN3 and GND without any circuit attached. The voltage reads 1.6v. Is there any chance the sketch is wrong

If you're using a high current LED, you can't drive it directly with an output pin. The absolute max current you can draw from an Arduino Mega pin is 40 mA. Not sure about other models. To protect the I/O pins on your Arduino, you shouldn't connect anything to ground with less than 125 ohms total resistance. Otherwise you risk burning out the driver for the I/O pin.

You should use an NPN transistor to drive the LED, with the Arduino output pin driving the base of the transistor through a resistor, and the LED connected between +5V and the collector (through your 47 ohm resistor.) Then connect the emitter to ground.

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


text:
How does one build a door motion sensor project with Arduino Uno board to send alerts to an Android Phone?

What are the materials I will need for the project? We want the project to work like this: When the door is opened, we get an alert to our Android Phone.
What is the circuit structure going to look like?
Which is simpler, GPRS, Bluetooth or Wifi to get the alert?
What is the best IDE to work on for this project?

If I could comment on this, I would say that this question really sounds like you haven't actually done any research to look into a solution.
But, in simple terms:

Arduino Uno, Android phone, GSM shield, contact sensor or limit switch
The sensor or switch needs to be connected to an I/O pin on the Arduino, and will probably need to be connected to 5V.
GSM(GPRS) is going to provide the most mobility
Arduino


text:
Changing direction of DC motor
i am working on a project which requires changing the direction of the DC motor using arduino. that is I want the DC motor to rotate clockwise when i press key 'A' and anti clockwise when i press key 'D' on my computer.
i have v+ and v- input wires from battery. i have connected one end of the DC motor to gnd of the battery. On the other end of DC motor i want to connect V+ and V- input from the battery to spin the DC motor in clockwise and anticlockwise respectively. I have used BC547 npn transistor.
i do not know how to change inputs (v+ to v- and vice-versa) using arduino when key is pressed.
is there any method other than H-bridge method to do so?
i use arduino uno.

I've used a double-pole-double-throw relay once to move a dc motor back and forth. Not ideal, but very easy to wire up, and foolproof. Just out of curiosity, what kind of battery are you using that has three terminals (GND, V+ and V-)?

When working with DC - no there's no other ways. You can physically reverse the connections with a relay, or you can use an H-bridge. Regardless of the way it might be constructed, a device which allows you to control the current direction electronically will be called an H-bridge. You get an H-bridge in the Arduino starter kit so there's no reason to fear it. They are easy to use.

@Gerben i have 2 battery packs. i have packaged it into one. i do not fear the use of Hbridge. but i dint want to make the circuit more bulky. so thot if there was an other method where u can achieve this without using Hbridge just by using arduino and transistors

Since you have both a V+ and V- you could just use 2 transitors. If you look at an H-bridge, you only need half the circuit. The only problem is that you need V- to disconnect the NPN transistor, and the arduino can only go as low as GND. So you'd need a second transitor to drive it. The same might also be needed for the PNP side, if the arduino voltage is regulated to a lower value than V+. I found this schematic applicable, but only use the left side, and replace the opto's with normal transisors.

@Gerben thast cool. post that as an answer. thank you much

Since you have both a V+ and V- you could just use 2 transitors. If you look at an H-bridge, you only need half the circuit.
The only problem is that you need V- to disconnect the NPN transistor, and the arduino can only go as low as GND. So you'd need a second transistor to drive it.
The same might also be needed for the PNP side, if the arduino voltage is regulated to a lower value than V+.
I found this schematic applicable, but only use the left side. The right side of the motor should be connected to ground (or the middle voltage of your battery). , and replace the opto's with normal transistors.

Come to think of it, I'm not entirely confident about replacing the bottom opto, since battery-negative is below GND in your case. I think it should work, but I'm still quite new to this stuff.
Also make sure you add something like 1k resistors to the base of the transistors (that replace the opto's)

L298 IC is very popular way of doing it. IN1 IN2 to control direction, open circuit and breaking (short circuit of motor terminals). EN1 for PWM speed control.
Ready made module PCB widely available.
useful info
https://www.sparkfun.com/products/9670
http://forum.arduino.cc/index.php/topic,84439.0.html
Hope it helps.

Without using any other IC is there a way?

You could get 4 transistors and build your own H-bridge instead of one packaged in an IC.

Building a discrete H-bridge is non-trivial, so most will go with the IC solution.  The L298 works but has high internal losses and is not great for battery powered projects.  Something more modern like the TB6612FNG is more fragile but also far more efficient.

L298 boards has been around for long time, made by 50 factories and 200 resellers, thus, very good cost and easy available.  Lot of tutorials and examples. New MOS driver can have better several to ten percents turn-on lower power loss which is generally not significant for DIY uses as compared when battery life is very important for real commercial products. They are higher cost and less easily available.

Why is an H-bridge non-trivial to build? I could do it with 4 logic level MOSFETs connected to logic lines on an Arduino. Add a few logic gates and it would only need a forward/reverse control and an on/off control from the Arduino.

so hbridge is the only way i suppose. i did not want to make the circuit more bulky. thot if that could be achieved only through arduino. since i had v+ and v- inputs. any way u can switch these inputs other than physically doing it?

If small size is the requirement, you may want to take a look at this example (others has similar too), at bottom of page, there are small boards at 5 USD. http://www.pololu.com/category/11/brushed-dc-motor-drivers   The reason that external driver chip/transistor is needed is because drive current from Arduino UNO/ATMEGA2560 are source / sink 20mA, where small motor is about 100mA upward. Consider Arduino Pro Mini for small size.

Arduino can't handle motor level power directly. It also can't handle negative voltages directly. The Arduino can CONTROL a circuit to drive a motor forwards and backwards, but it can't drive the motor directly. Handling high power devices like motors takes external circuitry, period.

@DuncanC - you must select components, make sure your get the gate drive voltages, make sure you have flyback & ESD protection, make sure your switching will not result in shoot-through, etc.  Modern IC bridges accomplish a lot of that for you, and so are far more user-friendly when the goal is to make a motor spin rather than learn subtle lessons about power semiconductor usage.

@ChrisStratton, thanks for the explanation. "Lessons about power semiconductor usage" sounds like it might involve smoke and the smell of burning electrical components. Does the H-Bridge design illustration in Gerben's answer seem reasonable? Looks good to me, with diodes to prevent flyback, opto isolators to isolate the control and power sides, etc.


text:
MCU Type ATmega16U2 not avaliable in Eclipse AVR Plugin
I am following this guide. Now I want to create the Create the "ArduinoCore library". But when I am creating a new project, I can not select ATmega16U2 as MCU type.
But my Arduino Due R3-E and UNO SMD R3 both use ATmega16U2.
What shall I do O_o???

They may have it, but you don't actually use it.

What do you mean with this? Why do I not actually use it?

Although you can't do it with the Eclipse AVR plugin, you can change the firmware of the 16U2.

The ATmega16U2 on those boards isn't intended to be programmable by the end-user. It's only there to help convert from USB to TTL serial, which lets your computer communicate with the board's main microcontroller. It replaces the FTDI chip which was used on some older boards.
In the case of the Uno, the main microcontroller is the ATmega328. For the Due, it's the AT91SAM3X8E. If you want to program them from the Arduino IDE, you can usually just select the board by name from the drop-down menu.

Thank you very much for your answer. Like I said, I want to program arduino using eclipse. So when I am prompted to tell the MCU type and MCU frequency, it's about the main MCU and not the USB to TTL serial?

Yes, that's correct. It needs to know about the main MCU because different chips have different features, and that affects how it compiles some of the underlying Arduino code.


text:
How to Segment Accelerometer Signal at idle points
I'm using an 3 axis Accelerometer(GY-521) to get the acceleration data and also the gyroscope to get the gyro data. I want to segment the signals at the idle points so that i can get the segmented signal at the idle points.

Is there any algorithm or example code that i could use to segment this kind of signal?
Any help would be appreciated.
Thank You.

Can you clarify what you want the final result to look like?

Hi brett, i want the signal segments that are not in the idle state to be identified and analyze them. Im doing this to identify gestures through accelerometer and gyroscope.

There are many algorithms you can use. I would advise you to look carefully at the data and the "idle state" and see what is always different. Try everything you can think of and see what works best, or if one does everything you need just stop there.
It might be that you can just calculate if the accelerometer values go over a certain threshold, but that requires that either the orientation be know or the threshold being over 1g.
You could also calculate the rate at which the accerometer value is changing by subtracting the last value (the derivative if you are up on your calculus) and threshold that value, which might produce better results.
You could also calculate a running average and then compare the current value with that. If the numbers match (or are very close) then you can say the accelerometer has been idle. This has the effect of making a changing threshold relative to the most recent activity tuned by the average's response.
I doubt any of these will be perfect, so you might require the algorithm to say "idle" multiple times in a row before changing state from "active" to "idle", or something to that effect.


text:
Incorrectly Reading Serial Using RXTX in Ubuntu
I am reading Accelerometer signals connected to Arduino board through a serial interface. I am using the RxTx library and following is the code.
private void initializeSerial() {
    CommPortIdentifier portId = null;
    Enumeration portEnum = CommPortIdentifier.getPortIdentifiers();

    while (portEnum.hasMoreElements()) {
        CommPortIdentifier currentPortIdentifier = (CommPortIdentifier) portEnum.nextElement();
        for (String portName : PORT_NAMES) {
            if (currentPortIdentifier.getName().equals(portName)) {
                portId = currentPortIdentifier;
                break;
            }
        }
    }

    if (portId == null) {
        System.out.println("Port not found");
        return;
    }

    try {

        serialPort = (SerialPort) portId.open(this.getClass().getName(), 2000);
        serialPort
                .setSerialPortParams(115200, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE);

        input = new BufferedReader(new InputStreamReader(serialPort.getInputStream()));
        output = serialPort.getOutputStream();

        serialPort.addEventListener(this);
        serialPort.notifyOnDataAvailable(true);

    } catch (Exception e) {
        System.err.println("Initialization failed : " + e.toString());
    }
}

@Override
public void serialEvent(SerialPortEvent event) {
    if (event.getEventType() == SerialPortEvent.DATA_AVAILABLE) {
        try {
            String inputLine = input.readLine();
            String[] inputValues = inputLine.split(",");
            System.out.println(inputLine);

            if (inputValues.length == 10 && inputValues[0].equals("STX")
                    && inputValues[inputValues.length - 1].equals("ETX")) {

                double classid = 0;
                double accx = 0;
                double accy = 0;
                double accz = 0;
                boolean num_error = false;

                try {

                    classid = Integer.parseInt(txtClassID.getText());
                    accx = Double.parseDouble(inputValues[2]);
                    accy = Double.parseDouble(inputValues[4]);
                    accz = Double.parseDouble(inputValues[6]);
                    num_error = false;

                } catch (NumberFormatException numex) {
                    num_error = true;
                }

                if (recording) {

                    if (!num_error) {
                        gestureList.add(new double[] { classid, accx, accy, accz });
                        System.out.println("ClassID : " + classid + " \tAdding : "+ accx +","+ accy+","+ accz);
                    }

                    System.out.println("ClassID : " + classid + " \tAdding : " + accx + accy + accz);
                } else {
                    if (gestureList.size() > 0) {
                        gestureCollection.add(gestureList);
                        System.out.println("Segment :" + (gestureCollection.size()) + "   Items : "
                                + gestureList.size());
                        txtSegments.append("Segment " + (gestureCollection.size()) + "\tItems : "
                                + gestureList.size() + "\n");

                        // comboSegments.addItem(gestureCollection.size());

                        gestureList = new ArrayList<>();
                    }
                }

                txtRawData.append(inputLine + "\n");
            }
        } catch (Exception ex) {
            ex.printStackTrace();
        }
    }
}

The problem I have is that, I'm reading the values in Windows environment perfectly, without any issues. But in Ubuntu I get data that is damaged and partially read. Here is the Java console output when I did this in ubuntu.
These are correct readings.
STX,16564.00,16565.65,-352.00,-431.09,-17840.00,-17941.79,-178.64,-42.72,ETX
STX,16524.00,16562.53,-440.00,-431.76,-17848.00,-17934.75,-178.63,-42.73,ETX
STX,16572.00,16563.24,-420.00,-430.88,-17992.00,-17939.05,-178.64,-42.72,ETX
But I get readings like this too. (In a considerable amount)
STX,16580.00,16551.27,-432.00,-438.85,-17936.00,-17922.1724.00,16548.94,-380.00,-439.41,-17880.00,-17921.05,-178.61,-42.71,ETX
9-178.56,-42.75,ETX
.,-454.82,-17944.00,-17916.45,-178.54,-42.72,ETX
STX,16584.00,16558.19,-464.00,-465.68,-18007416.00,-446.99,-18008.00,-17935.43,-178.56,-42.71,ETX
Why does this happen, where I can read perfectly in Windows and Not in Ubuntu.
Any help please? Thank You.

Have you looked into what the default flow control modes are on each OS? try changing the code to enforce a particular mode and see if it has any effect.

Could you explain more on that Brett? Do you see any issue in my code?

No issues per say, but you never explicitly set the flow control mode and your errors look similar to what happens when the receive buffer becomes full and starts dropping characters. Flow control requests the sender stop for a bit while the buffer gets processed. Try using different flow control modes with this: http://show.docjava.com/book/cgij/code/data/j4pDoc/serialPort/rxtx/RXTXPort.html#setFlowControlMode(int)


text:
RGB LED Strips with Arduino
I am trying to control an RGB LED strip with an Arduino. I have followed the tutorials in both of these websites:
Using MOSFETs: https://learn.adafruit.com/rgb-led-strips?view=all

Using LED Amplifiers: http://www.instructables.com/id/LED-Strip-Controller-w-LED-Amp-Arduino/

I have tried both setups and none of them work for me. When I try the setup with the MOSFETs, I am able to control each color but the blue LEDs are dimmer than the red and green, and therefore I can't mix any colors with blue.

When I try the LED Amplifiers, I am not able to control any light at all. Only the blue LEDs light up but the red and green dont. Also the blue LEDs stay ON the whole time and the only way to turn them off is to disconnect them from the DC power source.
What am I doing wrong?

First of all, it's generally bad practice to have a wire with 5V that's black. Red is usually used in this scenario. Also, How dim are the blue LEDs? Not sure but you might have the terminals backwards and there might be enough voltage to trigger the breakdown voltage of the LEDs.

For the blue dimmer than the others, you may simply need to adjust the baseline duty cycle to match them.

@Funkyguy - that's the Vin pin, which would be whatever supply is used. Hopefully an external supply is being used, as indeed undervoltage would cause odd behavior, and the blue leds with the highest forward voltage would suffer first.

@Chris Stratton How can i modify the duty cycle such that all the led are at full brightness?

How are you powering the led strip? Blue leds require a higher voltage, so I suspect you are using something like a 9V power supply instead of a 12v one.

If you are not too invested in your current hardware, I'd suggest the adafruit neopixel. It has thorough tutorials, simple implementation and is highly scalable. No connection to company/product, just a user. http://www.adafruit.com/products/1460

Which MOSFETS are you using and what is the length of your LED strip? Also, what is the code you're using?

When dealing with LED most of the time you need an high amperage like 1.5-2.0A so it is not enough to have the right voltage if your power supply has a low amperage.

The LED strip with blue ones requires a higher current drive. Arduino output pins can drive only 20mA max(ideal). Try an external power source.

They do use an external power supply and a MOSFET. Also, an Uno can supply 40mA, not 20.

For the mosfet circuit. Are you using an external power supply? The reason why you cannot mix any color might be due to the fact that you're not providing enough current to the led strip, so it just work fine when turning on each channel individually. Check the current the led strip draws (which usually is provided as amp per channel per meter) and use a power supply that can provide enough current for it.
From the adafuit page

Connect a 9-12V power supply to the Arduino so that Vin supplies the high voltage to the LED strip. If you want, you can also just use a separate wire that connects to a power supply that provides about +12V. Make sure to connect the ground of that supply to the ground of the Arduino/MOSFETs!

Your 12 strip probably puts each set of 3 LEDs in series.  3 Red LEDs take about 6V to be fully on, while 3 blue LEDs take about 9V; when you have 12v the resistors absorb the rest of the voltage drop (higher value resistors are needed for the red LEDs if you want about the same current in each color).  Driving 3 in series is good - the same current travels through 3 LEDs producing 3 times as much light per amp than if each LED was separately driven.  (Or from another perspective, with 3 in series the LEDs get 6-9v and thethe resistors and power amp need to drop the 3-6v from a 12v supply, versus a single LED dropping 2-3v and the resistors and power amp dropping the other 9-10v).
All is good, if you are driving each color with close to 12v.
BUT - your LED amplifier may expect more than 5v inputs in order to be fully on (eg: if it uses conventional FETs).  Driving it with 5v may not fully turn on the LED driving transistors.  In that case, the LEDs may be seeing less than 12V.  The blue LEDs would be the first to suffer from this voltage sag.
Note that if this is the case, the LED amplifier may also overheat - the transistors dissipate more power when not fully on, which raises the temperatures, probably leading to shortened life at best, possibly release of the magic smoke that makes electronics work.
You can test this.  Disconnect the Arduino.  Connect the +12v to one of the inputs at a time.  If that color is now fully bright, then you have shown that 12v input fully turns on the driving transistor, but 5v does not.
(If your LED amplifier says it's designed to be driven by 5v, do not do this test.  Many of them however expect to be driven by the tail end of a previous strip, at roughly 12v)
An example of an LED amplifier which IS designed for 5v inputs: http://www.usledsupply.com/shop/rgb-mini-amplifier-ttl.html  I have not used this device and am not recommending it, just using it as an example.  Note that it appears that for this amplifier, you would connect the Arduino's +5 to the input (along with the PWM outputs from the Arduino), rather than ground - and the PWM sense would be reversed, with lower PWM values being brighter, because the amp would turn on when the output pin was low.

From the drawings in that instructable, you need the Arduino ground and the 12 volt ground connected together - perhaps the line you have marked "+3v or 5v" should really be ground?

What you are saying is true. Butthe +3v or 5v shoudn't be ground. Connecting the Ground from the power supply to the Arduino should make things work alot better.


text:
RGB LED strip with Arduino
I am trying to control an RGB LED strip with an Arduino. I have followed the tutorials in both of these websites:
Using MOSFETs: https://learn.adafruit.com/rgb-led-strips?view=all

Using LED Amplifiers: http://www.instructables.com/id/LED-Strip-Controller-w-LED-Amp-Arduino/

I have tried both setups and none of them work for me. When I try the setup with the MOSFETs, I am able to control each color but the blue LEDs are dimmer than the red and green, and therefore I can't mix any colors with blue.

When I try the LED Amplifiers, I am not able to control any light at all. Only the blue LEDs light up but the red and green dont. Also the blue LEDs stay ON the whole time and the only way to turn them off is to disconnect them from the DC power source.
What am I doing wrong?


text:
Odd RGB matrix behavior while using shift registers
so I'm playing around with an 8x8 RGB matrix using a 74HC595 shift register for each of the colors. I've done this before with single color matrices and everything worked fine, but here I'm getting some weir behavior that I can't really understand.
All 3 74HC595's are wired identically:
MR - 5v,
OE - Ground,
VCC - 5v,
GND - Ground
Latch and clock are shared between the registers.
The result:

This is not how it should look, do I have a timing issue somewhere? Thanks in advance!
The code:
int clock_pin = 3; // SH_CP
int latch_pin = 4; // ST_CP

int r_data_pin = 2;  // DS
int g_data_pin = A0;
int b_data_pin = A1;

int row1 = 5;
int row2 = 6;
int row3 = 7;
int row4 = 8;
int row5 = 9;
int row6 = 10;
int row7 = 11;
int row8 = 12;

const int row_count = 8;
const int col_count = 8;

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

  pinMode(row1, OUTPUT);
  pinMode(row2, OUTPUT);
  pinMode(row3, OUTPUT);
  pinMode(row4, OUTPUT);
  pinMode(row5, OUTPUT);
  pinMode(row6, OUTPUT);
  pinMode(row7, OUTPUT);
  pinMode(row8, OUTPUT);

  pinMode(clock_pin, OUTPUT);
  pinMode(latch_pin, OUTPUT);

  pinMode(r_data_pin, OUTPUT);
  pinMode(g_data_pin, OUTPUT);
  pinMode(b_data_pin, OUTPUT);

  digitalWrite(latch_pin, HIGH);
  digitalWrite(clock_pin, HIGH);

  digitalWrite(r_data_pin, HIGH);
  digitalWrite(g_data_pin, HIGH);
  digitalWrite(b_data_pin, HIGH);
}

namespace RGB {

typedef struct pixel {
  byte r;
  byte g;
  byte b;
};

}

int r_data[8][8] = {
  {0, 1, 1, 0, 0, 1, 1, 0},
  {1, 1, 1, 1, 1, 1, 1, 1},
  {1, 1, 1, 1, 1, 1, 1, 1},
  {0, 1, 1, 0, 0, 1, 1, 0},
  {0, 1, 1, 0, 0, 1, 1, 0},
  {1, 1, 1, 1, 1, 1, 1, 1},
  {1, 1, 1, 1, 1, 1, 1, 1},
  {0, 1, 1, 0, 0, 1, 1, 0}
};

int g_data[8][8] = {
  {0, 1, 1, 0, 0, 1, 1, 0},
  {1, 1, 1, 1, 1, 1, 1, 1},
  {1, 1, 1, 1, 1, 1, 1, 1},
  {0, 1, 1, 0, 0, 1, 1, 0},
  {0, 1, 1, 0, 0, 1, 1, 0},
  {1, 1, 1, 1, 1, 1, 1, 1},
  {1, 1, 1, 1, 1, 1, 1, 1},
  {0, 1, 1, 0, 0, 1, 1, 0}
};

int b_data[8][8] = {
  {0, 1, 1, 0, 0, 1, 1, 0},
  {1, 1, 1, 1, 1, 1, 1, 1},
  {1, 1, 1, 1, 1, 1, 1, 1},
  {0, 1, 1, 0, 0, 1, 1, 0},
  {0, 1, 1, 0, 0, 1, 1, 0},
  {1, 1, 1, 1, 1, 1, 1, 1},
  {1, 1, 1, 1, 1, 1, 1, 1},
  {0, 1, 1, 0, 0, 1, 1, 0}
};

void loop() {
  for (int row = 0; row < 8; row++) {
    digitalWrite(latch_pin, LOW);

    if (row == 0) digitalWrite(row1, HIGH);
    if (row == 1) digitalWrite(row2, HIGH);
    if (row == 2) digitalWrite(row3, HIGH);
    if (row == 3) digitalWrite(row4, HIGH);
    if (row == 4) digitalWrite(row5, HIGH);
    if (row == 5) digitalWrite(row6, HIGH);
    if (row == 6) digitalWrite(row7, HIGH);
    if (row == 7) digitalWrite(row8, HIGH);

    for (int i = 0; i < 8; i++) {
      digitalWrite(clock_pin, LOW);

      digitalWrite(r_data_pin, r_data[row][i]);
      digitalWrite(g_data_pin, g_data[row][i]);
      digitalWrite(b_data_pin, b_data[row][i]);

      digitalWrite(clock_pin, HIGH);
    }
    delay(1);
    if (row == 0) digitalWrite(row1, LOW);
    if (row == 1) digitalWrite(row2, LOW);
    if (row == 2) digitalWrite(row3, LOW);
    if (row == 3) digitalWrite(row4, LOW);
    if (row == 4) digitalWrite(row5, LOW);
    if (row == 5) digitalWrite(row6, LOW);
    if (row == 6) digitalWrite(row7, LOW);
    if (row == 7) digitalWrite(row8, LOW);
    digitalWrite(latch_pin, HIGH);
  }
}

Same hardware & software as before when it worked?  Just different display using 3 times the number of LEDs (Red, Green & Blue) to make white colored light?  I would first check the power supply to see if it can handle the new load with out dropping the voltage and causing all kinds of problems with the processor and peripheral logic.

@st2000 The arduino is powering everything, how can I use a separate power supply?

You should be able to power the Arduino separately from the 74HC595 (which are assumed to be driving the LEDs) if you connect the grounds of the two power sources together and the two power sources are of the same voltage.  However, it would be simpler to use a single power source with about twice the current capacity that you would expect to draw.  Other considerations: If you are using the Arduino's on board 5 volt regulator you need to stay under the upper current capacity of that regulator.  Again, this is assuming the problems you are having are related to a weak power source.

With out changing any hardware, consider changing the software to only light 1 or 2 LEDs to see if the Arduino acts as expected when using a smaller amount of current to light less LEDs.

@st2000 Figured out how to use an external power supply, sadly it's only 3.3V, tried to use it but I still get an incorrect "image". I have not added no resistors for the LED's, maybe I should? I get some minor flicker in LED's which should not light up.


text:
Problem when using Servo.h and WIre.h libraries
I have a project that consists of an Arduino, a NodeMCU and 2 servos. The NodeMCU is configured as master and the Arduino as slave. I have bidirectional flow of data between them.
In order to receive data from Arduino I use the requestFrom() function from the Wire.h library and I call this function in the NodeMCU loop every 100ms.
The problem is that the servos (which are connected to the Arduino to pins 10 and 11) twitch every approximatively 10s. If I change the interval at which the NodeMCU asks for data from Arduino to 200ms, the twitch interval for the servos changes to 20s.
Is there a buffer that gets full or what is happening? I think that the Wire.onRequest() handler from Arduino interferes with the PWM of the servos. Is there a workaround? Do you have any idea how to stop the servos from twitching? Perhaps make the libraries use different timers? Thanks in advance!
Code:
#include "Arduino.h"
#include <Wire.h>
#include <Keypad.h>
#include <Servo.h>

Servo servo_1;//up-down servo
Servo servo_2;//left-right servo

byte deg_1=0;
byte deg_2=0;

byte manual_move_mode = 0;

byte data_count = 0, master_count = 0;

const byte ROWS = 4;
const byte COLS = 4;

char hexaKeys[ROWS][COLS] = {
  {'1', '2', '3', 'A'},
  {'4', '5', '6', 'B'},
  {'7', '8', '9', 'C'},
  {'*', '0', '#', 'D'}
};

byte rowPins[ROWS] = {9, 8, 7, 6};
byte colPins[COLS] = {5, 4, 3, 2};

Keypad customKeypad = Keypad(makeKeymap(hexaKeys), rowPins, colPins, ROWS, COLS);

void setup() {
 Wire.begin(8);                /* join i2c bus with address 8 */
 Wire.onReceive(receiveEvent); /* register receive event */
 Wire.onRequest(requestEvent);
 Serial.begin(115200);           /* start serial for debug */
 Serial.println("Program Started");
 pinMode(13, OUTPUT);

 servo_1.attach(10);
 servo_1.write(0);
 servo_2.attach(11);
 servo_2.write(0);
}

void loop() {

 manual_move_servo();
 //send_keys();

}

// function that executes when data is received from master
void receiveEvent(int howMany) {
  String data="";
 while (0 <Wire.available()) {
    char c = Wire.read();      /* receive byte as a character */
    data += c;

  }
    Serial.println(data);   /* print the request data */

    if (data=="PIN_13_HIGH"){
    digitalWrite(13,HIGH);
   } else if (data == "PIN_13_LOW"){
    digitalWrite(13,LOW);
   }

    if (data=="MANUAL_TRUE"){
    manual_move_mode = 1;
   } else if (data == "MANUAL_FALSE"){
    manual_move_mode = 0;
   }
}

void requestEvent()
{
  char customKey = customKeypad.getKey();
  if (customKey){
    Serial.print("Transmission to NodeMCU begins...");
    Serial.println(customKey);
    Wire.write(customKey);  // sends hello string
  }
}

void manual_move_servo(){
  if (manual_move_mode == 1){
      char customKey = customKeypad.getKey();
  if (customKey=='2'){//move up
    //digitalWrite(13,HIGH);
    deg_1+=5;
    servo_1.write(deg_1);
  } else if(customKey=='8'){//move down
    //digitalWrite(13,LOW);
    deg_1-=5;
    servo_1.write(deg_1);
  } else if(customKey=='4'){//move left
    //digitalWrite(13,HIGH);
    deg_2+=5;
    servo_2.write(deg_2);
  } else if(customKey=='6'){//move right
    //digitalWrite(13,LOW);
    deg_2-=5;
    servo_2.write(deg_2);
  } else if(customKey=='*'){
    manual_move_mode = 0;//este nevoie sa trimitem inf asta spre nodemcu????? nu cred pentru ca nu comandam altceva in fctie de var asta cu nodemcu poate doar daca adaugam un led indicator pe interfata web
  }
  }
//ne asiguram ca nu trecem de intervalele impuse
  if (deg_1<=5){
    deg_1=5;//daca pun 0 se duce automat la 180(probabil se intercaleaza intervale)
  }

  if (deg_1>=180){
    deg_1=180;
  }

    if (deg_2<=5){
    deg_2=5;//daca pun 0 se duce automat la 180(probabil se intercaleaza intervale)
  }

  if (deg_2>=180){
    deg_2=180;
  }
}

/*void send_keys(){

    char customKey = customKeypad.getKey();

  if (customKey){
    Serial.println(customKey);
    Serial.print("Transmission to NodeMCU begins...");
    Wire.beginTransmission(47); // begin with device address 8
    Wire.write(customKey);  // sends hello string
    Wire.endTransmission();// stop transmitting
  }
}*/

Please show us your code. The servo library and the Wire library both make use of Interrupt Service Routines. The onRequest() callback function is called from an ISR. If it takes too long to execute the ISR of the servo motors might have to wait, thus the motors are twitching. At least that would be my theory.

You could drive the servos directly from two PWM pins, instead of using the Servo library which uses an ISR. I'd suggest using the pins 9 and 10, as those use timer1. See https://forum.arduino.cc/t/servo-motor-controlled-by-timer-1-to-prevent-jitter/483767

@chrisl I added the code for the Arduino

Please try to do the very minimum of work inside the onRequest() and onReceive() callback functions. These are called from an ISR. For the onRequest() read the keypad in the main code and just prepare a variable (declared as volatile), which you then just do Wire.write() with in the onRequest() callback function. Reading the keypad takes some time. Also be cautious with printing too much to Serial inside an ISR. If it fills the buffer it can block your entire code and the data will only be send after the ISR is left.

So if I remove code from the onRequest() and onReceive() the servos should stop twitching?

I'll try to use hardware PWM instead of timer interrupts for the servos but I do not really know how (i'm gonna read about this). I have used the ServoTimer2 library but that does not work so is the hardware PWM going to work( I believe it is a different concept?; does it also use timers?)

I managed to stop the servos from twitching by removing the keypad reading from the onRequest() function. Thanks a lot!


text:
FastLED fill_solid array
I'm having trouble in the fill_solid function with arrays. can you help give color to row3.
int row3[]={1,2,3};
uint8_t sizerow3 = sizeof(row3)/sizeof(row3[0]);

void solid(){
  fill_solid(leds[row3[3]], sizerow3, CRGB :: Red);
  LEDS. show();
}

This is my complete program.
Thank you

What is the problem with your code? Please add a detailed problem description

i need help how to turn on the leds from row1[] to row5[] in sequence. (per row not per pixel)

leds[row3[3]] is not what you think it is. That is selecting one single LED depending on what is in element 4 (index 3) of the 3-element array row3. Since there is no index 3 in a 3 element array (only indexes 0, 1 and 2) the value it returns to use as an index to the leds[] array is unknown.
fill_solid is designed to fill a single uninterrupted string of LEDs starting at LED n and progressing for a number of LEDs after that. To set random LEDs all to the same colour you should simply loop through your list of target LEDs and set the colours individually. Something like:
for (int i = 0; i < sizerow3; i++) {
    leds[row3[i]] = CRGB::Red;
}
LEDS.show();