text:
Sensors and leds. This need resistors? and how?
I have a project with leds and sensors, this is my first project in Arduino and I want to know if it need resistors and how and where?
I use 16-Bit I/O Expander MCP23017 for leds and multiplexer CD4051 for sensors LM35

I'm downvoting this because it never should be asked. By the time you're ready to do the project you've outlined, you would know the answer to this. You aren't ready to build this project yet. Why do people think they can do this? It's like trying to copy the Mona Lisa without knowing how to mix paint.

You will definitely need resistors for each LED connected to MCP23017 circuits.
This is necessary because without resistor the following is likely to happen:

burn each LED that is lit on as it would be fed too much current
burn the MCP23017 because it is rated for 125mA maximum (20mA per output pin)

The resistor to use normally depends on the color of each LED as those LEDs have different electrical charasteristics.
Typically one LED (3 or 5mm) needs no more than 20mA to be lit (lower current such as 10mA is generally provides enough light).
One other important LED characteristic is its forward voltage, which depends on the color.
This link will help you calculate the "ideal" resistor for each LED.
For the sensors part, I see no reason to use any resistor to connect them to 4051 circuits.
One last important point is related to the use of I2C bus by the MCP23017 circuits. I2C bus is "open drain" and thus requires pullup resistors for both SCL and SDA lines.

Doesn't the I2C library (Wire.h) use the internal pull-up resistors?

@Gerben: You want external pull-ups.

@IgnacioVazquez-Abrams thank you. Much appreciated.


text:
How to store IR data needed for AC controll in less space?
I'm trying to controll an AC unit but the issue is space - right now, I store the data like this:
consts PROGMEM unsigned int Signal_Heat_Fan0_Temp30[] = {233,636,17884,3032,8944,500,496,492,1496,524,472,548,452,544,448,552,444,552,444,548,444,552,444,552,1436,556,444,552,444,548,1440,552,472,524,472,520,1472,492,1496,520,1468,556,1436,552,1440,552,444,548,448,548,444,552,448,548,448,548,448,548,472,524,468,524,472,524,476,520,472,520,476,520,476,520,472,524,472,552,444,548,452,548,444,552,444,548,448,548,444,552,448,544,452,544,448,552,472,524,468,524,472,524,472,524,472,520,476,520,476,520,472,524,1468,552,1436,556,1436,556,1436,552,2944,3028,8920,548,1440,552,448,548,472,524,468,524,472,524,472,472,524,516,476,552,444,548,1444,552,444,548,448,552,440,556,440,556,1432,556,1440,548,452,544,1444,552,1464,524,1464,472,1520,524,1464,556,1436,552,1440,552,1436,556,440,552,448,548,444,552,1440,552,1440,552,1464,524,472,496,496,472,524,520,476,548,444,552,448,552,1440,548,1440,556,1432,556,1440,548,448,548,444,552,448,548,472,524,472,524,1464,472,524,472,524,516,476,552,444,552,444,552,1440,552,1440,552,1436,556,1436,552};
consts PROGMEM unsigned int Signal_Heat_Fan0_Temp29[] = {233,636,17896,3032,8916,552,468,524,1468,524,468,500,496,472,528,520,476,544,448,552,444,552,444,548,1440,556,440,552,448,548,1440,552,444,548,452,544,1444,548,1468,524,1464,472,1520,520,1468,552,444,552,448,548,444,552,444,548,448,548,444,552,444,556,444,548,448,548,444,552,448,544,472,524,472,524,472,524,472,468,528,520,476,544,448,552,444,552,444,548,444,556,440,556,444,548,448,548,444,552,444,552,444,548,452,544,476,524,472,524,468,524,472,492,1496,520,1472,548,1440,556,1440,548,2944,3032,8916,552,1436,552,444,552,444,548,452,544,448,548,476,524,468,524,472,524,472,492,1496,520,476,524,472,548,448,552,444,552,1440,548,1440,548,448,548,1440,556,1440,548,1440,552,1464,524,1464,500,1496,520,1468,552,1440,548,444,556,444,552,444,548,1440,552,1440,548,1444,544,476,524,472,524,472,524,468,524,472,492,1496,524,476,548,1444,548,1440,548,1444,552,444,552,444,548,448,548,444,552,448,544,1448,544,476,524,468,524,472,524,472,492,504,516,1472,548,1444,552,1440,548,1440,548};
consts PROGMEM unsigned int Signal_Heat_Fan0_Temp28[] = {233,636,17880,3056,8912,524,476,544,1444,552,444,548,448,552,440,556,440,556,444,552,444,548,444,552,1440,552,444,552,468,524,1468,524,468,472,524,520,1476,544,1444,548,1440,556,1432,556,1440,548,448,548,444,552,448,548,448,548,472,524,472,520,472,524,472,496,500,472,524,492,504,544,452,548,444,552,444,552,444,548,448,552,440,556,444,548,448,548,444,552,448,544,452,544,476,524,472,524,468,524,472,524,472,492,500,520,476,548,452,544,448,552,444,552,1440,548,1440,552,1440,552,1440,548,2944,3028,8924,544,1444,552,468,524,472,496,500,492,504,516,476,552,444,548,452,548,444,552,1440,548,444,552,444,552,1444,548,444,552,1440,548,1444,544,476,520,1472,492,1496,520,1468,552,1444,548,1440,552,1436,552,1440,552,1440,552,444,548,452,544,476,520,1468,524,1468,492,1496,520,480,544,448,548,448,552,444,548,444,552,444,548,452,548,1440,552,1436,552,1444,544,476,520,476,524,468,524,472,496,500,492,1496,524,476,544,452,548,444,552,444,548,448,548,1444,548,1440,552,1440,548,1444,520};
consts PROGMEM unsigned int Signal_Heat_Fan0_Temp27[] = {233,640,17892,3032,8916,552,448,548,1464,528,468,528,468,468,528,468,528,520,472,552,444,552,444,552,1440,548,448,548,444,556,1436,552,444,552,444,552,1436,552,1444,548,1468,492,1496,472,1516,552,448,548,448,548,448,548,444,552,444,552,444,552,440,556,444,552,444,548,444,552,448,548,448,548,472,524,472,524,468,468,528,472,524,520,472,524,472,552,448,548,448,548,444,552,444,548,448,548,444,556,440,552,448,548,444,552,444,552,448,544,472,524,472,528,1464,468,1520,520,1472,552,1436,556,2944,3028,8912,556,1440,548,448,548,444,552,448,548,448,548,444,552,472,520,472,524,472,524,1464,472,528,488,508,544,448,552,444,552,1436,556,1436,552,448,548,1440,548,1440,556,1440,548,1440,552,1464,524,1464,472,1524,544,1444,552,444,552,448,548,444,552,1440,548,1440,552,1444,548,444,552,448,544,472,524,472,524,468,500,1492,492,1500,548,452,544,1440,556,1436,552,444,552,444,552,444,548,448,548,448,548,1444,548,472,524,468,524,472,524,472,472,528,468,1520,520,1468,552,1440,552,1436,552};
consts PROGMEM unsigned int Signal_Heat_Fan0_Temp26[] = {233,640,17884,2980,8992,528,472,524,1464,472,524,520,476,548,444,556,440,556,444,548,444,552,444,552,1440,552,440,556,444,548,1440,552,444,552,468,524,1468,528,1460,472,1520,548,1444,548,1440,556,444,548,448,548,444,552,444,552,444,552,444,552,444,552,444,548,448,548,472,524,468,524,472,472,528,468,528,488,504,548,448,552,444,548,444,556,440,556,444,548,444,552,444,552,444,548,448,548,448,552,444,548,448,548,472,524,472,520,472,524,472,472,524,520,1468,548,1444,552,1440,552,1436,556,2944,3024,8920,552,1440,552,444,548,444,552,448,548,468,524,472,528,472,468,524,468,528,520,1472,548,444,556,444,548,1440,552,444,548,1440,556,1440,548,444,552,1440,548,1444,552,1464,492,1496,520,1472,548,1440,556,1440,548,1440,552,444,552,444,552,444,548,1440,552,1444,548,1440,548,472,524,472,472,524,472,520,520,480,544,452,548,1440,548,448,548,1440,552,1440,552,444,548,448,548,448,552,444,552,468,524,1464,524,472,472,528,468,524,468,528,544,452,548,1440,556,1436,552,1440,548,1440,556};
consts PROGMEM unsigned int Signal_Heat_Fan0_Temp25[] = {233,644,17892,3028,8916,552,444,548,1440,556,440,552,448,548,444,552,444,548,448,548,448,548,472,528,1464,468,528,520,472,548,1448,544,444,556,440,556,1440,548,1440,548,1440,556,1440,548,1440,552,448,544,472,528,472,524,468,468,528,468,528,544,448,552,444,552,444,552,444,552,444,552,444,552,444,548,444,552,444,552,444,552,448,548,444,552,468,524,472,524,472,524,468,472,524,472,528,520,476,544,448,552,444,548,448,548,444,556,440,556,444,548,444,552,1440,548,1440,556,1440,548,1468,548,2920,3052,8920,472,1516,548,452,548,444,552,444,548,448,548,444,556,440,556,444,548,448,548,1440,548,452,544,448,552,1440,548,472,524,1464,472,1516,552,448,544,1444,552,1444,548,1440,552,1436,552,1440,552,1440,552,1440,548,1464,528,472,496,500,468,524,520,1472,548,1440,556,1436,552,444,552,444,556,440,552,444,552,444,552,1436,552,448,544,452,548,1468,524,1464,468,528,520,472,552,448,548,448,548,448,548,1440,548,448,548,444,552,444,556,444,548,444,552,1440,548,1440,552,1464,500,1496,548};

The first item is the length of the array and the rest is data I can send with IRemote library with the raw send libray. I've mapped most of the buttons and now I'm at
Sketch uses 95.286 bytes of program storage space

Is there a better encoding that could take less space? I'd like to add at least 3 times more commands to the Sketch, but I'm already at 37% on an Arduino Mega.
I know ideally I should generate the array, not store it, but I haven't gotten that far (yet, I'm working on it) and for me this is an interesting issue.
Thank you!

Edit 1: Code uploaded on GitHub - https://github.com/vladbabii/SamsungACIrControll/tree/master/AC_IrControll

What do the numbers represent?

The sequence of 0 and 1 time-encoded that make up an IR transmission to set something. The lines in the post are for heat mode, and temperature 25 to 30. I read the data with an IR sensor from the AC remote, and resend it to control the AC. In this case I am using IRemote library, but there is also IRLib. There are alot of tutorials and demos on youtube if you want to see how it works, but if you want I can post more code.

I thought so.  So the times don't have to be 100% accurate then I guess - you just have a set number of "ballpark" figures - around 500, around 1500, around 3000, etc. Do you really need to store the actual times in that case, or just a representation of the time?

It looks like there's a standard preamble of ~600, ~1800, ~3000, ~9000 and then a sequence of ~500 and ~!500 to represent 0 and 1, and that makes it even easier

So i should find sequences of numbers that appear often in the code and just save that as a number. The timings do not have to be 100% accurate, I did 10 reading of each value, stored to logs, then did the average with a script to get the current options. I could modify the script to search for patterns and find what numbers never appear anywhere and generate a map for that... Thank you for the idea!

If you take ~500 as a 0 and ~1500 as a 1 and ignore the preamble (hard code that separately) you could encode those binary 1 and 0 values as binary in just a handful of bytes.  For instance the first entry would encode to: 0x10, 0x00, 0x10, 0x41, 0x55, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x55, 0x74, 0x00, 0x01, 0x00, 0x51, 0x55, 0x54, 0x05, 0x40, 0x01, 0x54, 0x00, 0x40, 0x05, 0x50

I've uploaded the whole code to GitHub if you want to take a look. I will update the code again after I add your optimization to it.

I have analysed your codes with a small Lua script:
function pairsByKeys (t, f)
  local a = {}
  -- build temporary table of the keys
  for n in pairs (t) do
    table.insert (a, n)
  end
  table.sort (a, f)  -- sort using supplied function, if any
  local i = 0        -- iterator variable
  return function () -- iterator function
    i = i + 1
    return a[i], t[a[i]]
  end  -- iterator function
end -- pairsByKeys

nums = {233,636,17884,3032,8944,
-- and so on ...
548,444,552,444,556,444,548,444,552,1440,548,1440,552,1464,500,1496,548}

uniq = { }

for k, v in ipairs (nums) do
  if uniq [v] then
    uniq [v] = uniq [v] + 1
  else
    uniq [v] = 1
  end -- else
end -- for

count = 0

for k, v in pairsByKeys (uniq) do
  print (string.format ("%8i = %3i", k, v))
  count = count + 1
end

print ("count = ", count)

Results:
     233 =   6
     440 =  18
     444 = 154
     448 =  86
     452 =  20
     468 =  42
     472 = 103
     476 =  27
     480 =   2
     488 =   2
     492 =  15
     496 =   8
     500 =  10
     504 =   4
     508 =   1
     516 =   4
     520 =  41
     524 =  97
     528 =  26
     544 =  39
     548 = 189
     552 = 196
     556 =  56
     636 =   3
     640 =   2
     644 =   1
    1432 =   3
    1436 =  24
    1440 =  91
    1444 =  26
    1448 =   2
    1460 =   1
    1464 =  21
    1468 =  16
    1472 =   8
    1476 =   1
    1492 =   1
    1496 =  12
    1500 =   1
    1516 =   3
    1520 =   5
    1524 =   1
    2920 =   1
    2944 =   5
    2980 =   1
    3024 =   1
    3028 =   4
    3032 =   4
    3052 =   1
    3056 =   1
    8912 =   2
    8916 =   4
    8920 =   3
    8924 =   1
    8944 =   1
    8992 =   1
   17880 =   1
   17884 =   2
   17892 =   2
   17896 =   1
count =     60

Assuming there is some jitter I rounded them to the nearest 50:
for k, v in ipairs (nums) do

  v = math.floor (v / 50)    -- <--- add this
  v = v * 50                 -- <--- add this
  if uniq [v] then
    uniq [v] = uniq [v] + 1
  else
    uniq [v] = 1
  end -- else
end -- for

Results:
     200 =   6
     400 = 258
     450 = 219
     500 = 411
     550 = 252
     600 =   6
    1400 = 146
    1450 =  60
    1500 =  10
    2900 =   6
    2950 =   1
    3000 =   9
    3050 =   2
    8900 =  11
    8950 =   1
   17850 =   6
count =     16

So, 16 different lengths.

So now you can use 4 bits per code (and a lookup table) rather than 16 bits.
Also see TV-B-Gone design notes for how they compressed the IR codes for lots of TV brands into a small table in an ATtiny85.

I think you can safely replace all values with either 500 or 1400 (except for the preamble). So you can store them in 1 bit per code. Secondly the first 118 values seem to be identical, and after those values there seems to be another preamble (?). After this another 26 values are identical. So you could store the first part (146 values) only once. (Also try leaving it out completely and see if the AC unit still accepts it)

Good idea. We'll have it down to a few dozen bytes soon. :)

Do you need all of the data accessible at once? How about storing it on a file device or external memory? SDcards are slow but huge. FRAM devices a fast but not as huge and typically aren't formatted for a file system. They act more like an independent memory space accessed by a function. (The Adafruit product is one example; I'm sure there are more).

It's a good idea to use FRAM or something simillar. Havent thought of that yet, I will look into it. I only need to be able to fetch one row at a time to send it over IR.

Then an external memory device should work well for you.

Another form of storage is the EEPROM. There are between 512 bytes and 4K of EEPROM per Arduino, depending on the model of Arduino - see https://www.arduino.cc/en/Reference/EEPROM
EEPROM is persistent when the power gets cut, and MAY or may not be overwritten when the program is changed - I have not tried. If it is not overwritten, you can write a sketch just to set it, then overwrite it with your IR sketch; otherwise, you may have to set up some way to "upload" the data into your sketch (e.g. if you press a special button, it will listen on the serial port, any bytes it reads it will write to the EEPROM.
If you have an ISP (aka ICSP) programmer such as the USBasp (see google), which are very inexpensive, then you can read/write the EEPROM directly - all you need is 6 pins exposed. You can also use the USBasp to reprogram an AtMega/AtTiny which is not on an Arduino board (this also gives you a little extra program space, since it no longer requires a bootloader).

source: Stack Exchange

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

sort: votes


text:
Arduino Leonardo Upload issue with ubuntu 14.04
I got a bare conductive board ( which is based on arduino leonardo ) . I was trying to upload a blink sketch using arduion 1.5.7. But its always failing and here is the log. I never work a leonardo before. Any ideas what is happing with this ?
Build options changed, rebuilding all

/home/achayan/Downloads/arduino-1.5.7/hardware/tools/avr/bin/avr-g++ -c -g -Os -w -fno-exceptions -ffunction-sections -fdata-sections -MMD -mmcu=atmega32u4 -DF_CPU=16000000L -DARDUINO=157 -DARDUINO_AVR_BARETOUCH -DARDUINO_ARCH_AVR -DUSB_VID=0x2A6E -DUSB_PID=0x8003 -DUSB_MANUFACTURER="Bare Conductive" -DUSB_PRODUCT="Touch Board" -I/home/achayan/Downloads/arduino-1.5.7/hardware/arduino/avr/cores/arduino -I/home/achayan/Downloads/arduino-1.5.7/hardware/arduino/avr/variants/leonardo /tmp/build5447563659949358969.tmp/Blink.cpp -o /tmp/build5447563659949358969.tmp/Blink.cpp.o
/home/achayan/Downloads/arduino-1.5.7/hardware/tools/avr/bin/avr-gcc -c -g -Os -w -ffunction-sections -fdata-sections -MMD -mmcu=atmega32u4 -DF_CPU=16000000L -DARDUINO=157 -DARDUINO_AVR_BARETOUCH -DARDUINO_ARCH_AVR -DUSB_VID=0x2A6E -DUSB_PID=0x8003 -DUSB_MANUFACTURER="Bare Conductive" -DUSB_PRODUCT="Touch Board" -I/home/achayan/Downloads/arduino-1.5.7/hardware/arduino/avr/cores/arduino -I/home/achayan/Downloads/arduino-1.5.7/hardware/arduino/avr/variants/leonardo /home/achayan/Downloads/arduino-1.5.7/hardware/arduino/avr/cores/arduino/wiring_analog.c -o /tmp/build5447563659949358969.tmp/wiring_analog.c.o
/home/achayan/Downloads/arduino-1.5.7/hardware/tools/avr/bin/avr-gcc -c -g -Os -w -ffunction-sections -fdata-sections -MMD -mmcu=atmega32u4 -DF_CPU=16000000L -DARDUINO=157 -DARDUINO_AVR_BARETOUCH -DARDUINO_ARCH_AVR -DUSB_VID=0x2A6E -DUSB_PID=0x8003 -DUSB_MANUFACTURER="Bare Conductive" -DUSB_PRODUCT="Touch Board" -I/home/achayan/Downloads/arduino-1.5.7/hardware/arduino/avr/cores/arduino -I/home/achayan/Downloads/arduino-1.5.7/hardware/arduino/avr/variants/leonardo /home/achayan/Downloads/arduino-1.5.7/hardware/arduino/avr/cores/arduino/wiring_digital.c -o /tmp/build5447563659949358969.tmp/wiring_digital.c.o
/home/achayan/Downloads/arduino-1.5.7/hardware/tools/avr/bin/avr-gcc -c -g -Os -w -ffunction-sections -fdata-sections -MMD -mmcu=atmega32u4 -DF_CPU=16000000L -DARDUINO=157 -DARDUINO_AVR_BARETOUCH -DARDUINO_ARCH_AVR -DUSB_VID=0x2A6E -DUSB_PID=0x8003 -DUSB_MANUFACTURER="Bare Conductive" -DUSB_PRODUCT="Touch Board" -I/home/achayan/Downloads/arduino-1.5.7/hardware/arduino/avr/cores/arduino -I/home/achayan/Downloads/arduino-1.5.7/hardware/arduino/avr/variants/leonardo /home/achayan/Downloads/arduino-1.5.7/hardware/arduino/avr/cores/arduino/wiring_shift.c -o /tmp/build5447563659949358969.tmp/wiring_shift.c.o
/home/achayan/Downloads/arduino-1.5.7/hardware/tools/avr/bin/avr-gcc -c -g -Os -w -ffunction-sections -fdata-sections -MMD -mmcu=atmega32u4 -DF_CPU=16000000L -DARDUINO=157 -DARDUINO_AVR_BARETOUCH -DARDUINO_ARCH_AVR -DUSB_VID=0x2A6E -DUSB_PID=0x8003 -DUSB_MANUFACTURER="Bare Conductive" -DUSB_PRODUCT="Touch Board" -I/home/achayan/Downloads/arduino-1.5.7/hardware/arduino/avr/cores/arduino -I/home/achayan/Downloads/arduino-1.5.7/hardware/arduino/avr/variants/leonardo /home/achayan/Downloads/arduino-1.5.7/hardware/arduino/avr/cores/arduino/WInterrupts.c -o /tmp/build5447563659949358969.tmp/WInterrupts.c.o
/home/achayan/Downloads/arduino-1.5.7/hardware/tools/avr/bin/avr-gcc -c -g -Os -w -ffunction-sections -fdata-sections -MMD -mmcu=atmega32u4 -DF_CPU=16000000L -DARDUINO=157 -DARDUINO_AVR_BARETOUCH -DARDUINO_ARCH_AVR -DUSB_VID=0x2A6E -DUSB_PID=0x8003 -DUSB_MANUFACTURER="Bare Conductive" -DUSB_PRODUCT="Touch Board" -I/home/achayan/Downloads/arduino-1.5.7/hardware/arduino/avr/cores/arduino -I/home/achayan/Downloads/arduino-1.5.7/hardware/arduino/avr/variants/leonardo /home/achayan/Downloads/arduino-1.5.7/hardware/arduino/avr/cores/arduino/hooks.c -o /tmp/build5447563659949358969.tmp/hooks.c.o
/home/achayan/Downloads/arduino-1.5.7/hardware/tools/avr/bin/avr-gcc -c -g -Os -w -ffunction-sections -fdata-sections -MMD -mmcu=atmega32u4 -DF_CPU=16000000L -DARDUINO=157 -DARDUINO_AVR_BARETOUCH -DARDUINO_ARCH_AVR -DUSB_VID=0x2A6E -DUSB_PID=0x8003 -DUSB_MANUFACTURER="Bare Conductive" -DUSB_PRODUCT="Touch Board" -I/home/achayan/Downloads/arduino-1.5.7/hardware/arduino/avr/cores/arduino -I/home/achayan/Downloads/arduino-1.5.7/hardware/arduino/avr/variants/leonardo /home/achayan/Downloads/arduino-1.5.7/hardware/arduino/avr/cores/arduino/wiring_pulse.c -o /tmp/build5447563659949358969.tmp/wiring_pulse.c.o
/home/achayan/Downloads/arduino-1.5.7/hardware/tools/avr/bin/avr-gcc -c -g -Os -w -ffunction-sections -fdata-sections -MMD -mmcu=atmega32u4 -DF_CPU=16000000L -DARDUINO=157 -DARDUINO_AVR_BARETOUCH -DARDUINO_ARCH_AVR -DUSB_VID=0x2A6E -DUSB_PID=0x8003 -DUSB_MANUFACTURER="Bare Conductive" -DUSB_PRODUCT="Touch Board" -I/home/achayan/Downloads/arduino-1.5.7/hardware/arduino/avr/cores/arduino -I/home/achayan/Downloads/arduino-1.5.7/hardware/arduino/avr/variants/leonardo /home/achayan/Downloads/arduino-1.5.7/hardware/arduino/avr/cores/arduino/wiring.c -o /tmp/build5447563659949358969.tmp/wiring.c.o
/home/achayan/Downloads/arduino-1.5.7/hardware/tools/avr/bin/avr-g++ -c -g -Os -w -fno-exceptions -ffunction-sections -fdata-sections -MMD -mmcu=atmega32u4 -DF_CPU=16000000L -DARDUINO=157 -DARDUINO_AVR_BARETOUCH -DARDUINO_ARCH_AVR -DUSB_VID=0x2A6E -DUSB_PID=0x8003 -DUSB_MANUFACTURER="Bare Conductive" -DUSB_PRODUCT="Touch Board" -I/home/achayan/Downloads/arduino-1.5.7/hardware/arduino/avr/cores/arduino -I/home/achayan/Downloads/arduino-1.5.7/hardware/arduino/avr/variants/leonardo /home/achayan/Downloads/arduino-1.5.7/hardware/arduino/avr/cores/arduino/HardwareSerial3.cpp -o /tmp/build5447563659949358969.tmp/HardwareSerial3.cpp.o
/home/achayan/Downloads/arduino-1.5.7/hardware/tools/avr/bin/avr-g++ -c -g -Os -w -fno-exceptions -ffunction-sections -fdata-sections -MMD -mmcu=atmega32u4 -DF_CPU=16000000L -DARDUINO=157 -DARDUINO_AVR_BARETOUCH -DARDUINO_ARCH_AVR -DUSB_VID=0x2A6E -DUSB_PID=0x8003 -DUSB_MANUFACTURER="Bare Conductive" -DUSB_PRODUCT="Touch Board" -I/home/achayan/Downloads/arduino-1.5.7/hardware/arduino/avr/cores/arduino -I/home/achayan/Downloads/arduino-1.5.7/hardware/arduino/avr/variants/leonardo /home/achayan/Downloads/arduino-1.5.7/hardware/arduino/avr/cores/arduino/Tone.cpp -o /tmp/build5447563659949358969.tmp/Tone.cpp.o
/home/achayan/Downloads/arduino-1.5.7/hardware/tools/avr/bin/avr-g++ -c -g -Os -w -fno-exceptions -ffunction-sections -fdata-sections -MMD -mmcu=atmega32u4 -DF_CPU=16000000L -DARDUINO=157 -DARDUINO_AVR_BARETOUCH -DARDUINO_ARCH_AVR -DUSB_VID=0x2A6E -DUSB_PID=0x8003 -DUSB_MANUFACTURER="Bare Conductive" -DUSB_PRODUCT="Touch Board" -I/home/achayan/Downloads/arduino-1.5.7/hardware/arduino/avr/cores/arduino -I/home/achayan/Downloads/arduino-1.5.7/hardware/arduino/avr/variants/leonardo /home/achayan/Downloads/arduino-1.5.7/hardware/arduino/avr/cores/arduino/HardwareSerial1.cpp -o /tmp/build5447563659949358969.tmp/HardwareSerial1.cpp.o
/home/achayan/Downloads/arduino-1.5.7/hardware/tools/avr/bin/avr-g++ -c -g -Os -w -fno-exceptions -ffunction-sections -fdata-sections -MMD -mmcu=atmega32u4 -DF_CPU=16000000L -DARDUINO=157 -DARDUINO_AVR_BARETOUCH -DARDUINO_ARCH_AVR -DUSB_VID=0x2A6E -DUSB_PID=0x8003 -DUSB_MANUFACTURER="Bare Conductive" -DUSB_PRODUCT="Touch Board" -I/home/achayan/Downloads/arduino-1.5.7/hardware/arduino/avr/cores/arduino -I/home/achayan/Downloads/arduino-1.5.7/hardware/arduino/avr/variants/leonardo /home/achayan/Downloads/arduino-1.5.7/hardware/arduino/avr/cores/arduino/HardwareSerial2.cpp -o /tmp/build5447563659949358969.tmp/HardwareSerial2.cpp.o
/home/achayan/Downloads/arduino-1.5.7/hardware/tools/avr/bin/avr-g++ -c -g -Os -w -fno-exceptions -ffunction-sections -fdata-sections -MMD -mmcu=atmega32u4 -DF_CPU=16000000L -DARDUINO=157 -DARDUINO_AVR_BARETOUCH -DARDUINO_ARCH_AVR -DUSB_VID=0x2A6E -DUSB_PID=0x8003 -DUSB_MANUFACTURER="Bare Conductive" -DUSB_PRODUCT="Touch Board" -I/home/achayan/Downloads/arduino-1.5.7/hardware/arduino/avr/cores/arduino -I/home/achayan/Downloads/arduino-1.5.7/hardware/arduino/avr/variants/leonardo /home/achayan/Downloads/arduino-1.5.7/hardware/arduino/avr/cores/arduino/Print.cpp -o /tmp/build5447563659949358969.tmp/Print.cpp.o
/home/achayan/Downloads/arduino-1.5.7/hardware/tools/avr/bin/avr-g++ -c -g -Os -w -fno-exceptions -ffunction-sections -fdata-sections -MMD -mmcu=atmega32u4 -DF_CPU=16000000L -DARDUINO=157 -DARDUINO_AVR_BARETOUCH -DARDUINO_ARCH_AVR -DUSB_VID=0x2A6E -DUSB_PID=0x8003 -DUSB_MANUFACTURER="Bare Conductive" -DUSB_PRODUCT="Touch Board" -I/home/achayan/Downloads/arduino-1.5.7/hardware/arduino/avr/cores/arduino -I/home/achayan/Downloads/arduino-1.5.7/hardware/arduino/avr/variants/leonardo /home/achayan/Downloads/arduino-1.5.7/hardware/arduino/avr/cores/arduino/HID.cpp -o /tmp/build5447563659949358969.tmp/HID.cpp.o
/home/achayan/Downloads/arduino-1.5.7/hardware/tools/avr/bin/avr-g++ -c -g -Os -w -fno-exceptions -ffunction-sections -fdata-sections -MMD -mmcu=atmega32u4 -DF_CPU=16000000L -DARDUINO=157 -DARDUINO_AVR_BARETOUCH -DARDUINO_ARCH_AVR -DUSB_VID=0x2A6E -DUSB_PID=0x8003 -DUSB_MANUFACTURER="Bare Conductive" -DUSB_PRODUCT="Touch Board" -I/home/achayan/Downloads/arduino-1.5.7/hardware/arduino/avr/cores/arduino -I/home/achayan/Downloads/arduino-1.5.7/hardware/arduino/avr/variants/leonardo /home/achayan/Downloads/arduino-1.5.7/hardware/arduino/avr/cores/arduino/USBCore.cpp -o /tmp/build5447563659949358969.tmp/USBCore.cpp.o
/home/achayan/Downloads/arduino-1.5.7/hardware/tools/avr/bin/avr-g++ -c -g -Os -w -fno-exceptions -ffunction-sections -fdata-sections -MMD -mmcu=atmega32u4 -DF_CPU=16000000L -DARDUINO=157 -DARDUINO_AVR_BARETOUCH -DARDUINO_ARCH_AVR -DUSB_VID=0x2A6E -DUSB_PID=0x8003 -DUSB_MANUFACTURER="Bare Conductive" -DUSB_PRODUCT="Touch Board" -I/home/achayan/Downloads/arduino-1.5.7/hardware/arduino/avr/cores/arduino -I/home/achayan/Downloads/arduino-1.5.7/hardware/arduino/avr/variants/leonardo /home/achayan/Downloads/arduino-1.5.7/hardware/arduino/avr/cores/arduino/HardwareSerial.cpp -o /tmp/build5447563659949358969.tmp/HardwareSerial.cpp.o
/home/achayan/Downloads/arduino-1.5.7/hardware/tools/avr/bin/avr-g++ -c -g -Os -w -fno-exceptions -ffunction-sections -fdata-sections -MMD -mmcu=atmega32u4 -DF_CPU=16000000L -DARDUINO=157 -DARDUINO_AVR_BARETOUCH -DARDUINO_ARCH_AVR -DUSB_VID=0x2A6E -DUSB_PID=0x8003 -DUSB_MANUFACTURER="Bare Conductive" -DUSB_PRODUCT="Touch Board" -I/home/achayan/Downloads/arduino-1.5.7/hardware/arduino/avr/cores/arduino -I/home/achayan/Downloads/arduino-1.5.7/hardware/arduino/avr/variants/leonardo /home/achayan/Downloads/arduino-1.5.7/hardware/arduino/avr/cores/arduino/IPAddress.cpp -o /tmp/build5447563659949358969.tmp/IPAddress.cpp.o
/home/achayan/Downloads/arduino-1.5.7/hardware/tools/avr/bin/avr-g++ -c -g -Os -w -fno-exceptions -ffunction-sections -fdata-sections -MMD -mmcu=atmega32u4 -DF_CPU=16000000L -DARDUINO=157 -DARDUINO_AVR_BARETOUCH -DARDUINO_ARCH_AVR -DUSB_VID=0x2A6E -DUSB_PID=0x8003 -DUSB_MANUFACTURER="Bare Conductive" -DUSB_PRODUCT="Touch Board" -I/home/achayan/Downloads/arduino-1.5.7/hardware/arduino/avr/cores/arduino -I/home/achayan/Downloads/arduino-1.5.7/hardware/arduino/avr/variants/leonardo /home/achayan/Downloads/arduino-1.5.7/hardware/arduino/avr/cores/arduino/WMath.cpp -o /tmp/build5447563659949358969.tmp/WMath.cpp.o
/home/achayan/Downloads/arduino-1.5.7/hardware/tools/avr/bin/avr-g++ -c -g -Os -w -fno-exceptions -ffunction-sections -fdata-sections -MMD -mmcu=atmega32u4 -DF_CPU=16000000L -DARDUINO=157 -DARDUINO_AVR_BARETOUCH -DARDUINO_ARCH_AVR -DUSB_VID=0x2A6E -DUSB_PID=0x8003 -DUSB_MANUFACTURER="Bare Conductive" -DUSB_PRODUCT="Touch Board" -I/home/achayan/Downloads/arduino-1.5.7/hardware/arduino/avr/cores/arduino -I/home/achayan/Downloads/arduino-1.5.7/hardware/arduino/avr/variants/leonardo /home/achayan/Downloads/arduino-1.5.7/hardware/arduino/avr/cores/arduino/WString.cpp -o /tmp/build5447563659949358969.tmp/WString.cpp.o
/home/achayan/Downloads/arduino-1.5.7/hardware/tools/avr/bin/avr-g++ -c -g -Os -w -fno-exceptions -ffunction-sections -fdata-sections -MMD -mmcu=atmega32u4 -DF_CPU=16000000L -DARDUINO=157 -DARDUINO_AVR_BARETOUCH -DARDUINO_ARCH_AVR -DUSB_VID=0x2A6E -DUSB_PID=0x8003 -DUSB_MANUFACTURER="Bare Conductive" -DUSB_PRODUCT="Touch Board" -I/home/achayan/Downloads/arduino-1.5.7/hardware/arduino/avr/cores/arduino -I/home/achayan/Downloads/arduino-1.5.7/hardware/arduino/avr/variants/leonardo /home/achayan/Downloads/arduino-1.5.7/hardware/arduino/avr/cores/arduino/main.cpp -o /tmp/build5447563659949358969.tmp/main.cpp.o
/home/achayan/Downloads/arduino-1.5.7/hardware/tools/avr/bin/avr-g++ -c -g -Os -w -fno-exceptions -ffunction-sections -fdata-sections -MMD -mmcu=atmega32u4 -DF_CPU=16000000L -DARDUINO=157 -DARDUINO_AVR_BARETOUCH -DARDUINO_ARCH_AVR -DUSB_VID=0x2A6E -DUSB_PID=0x8003 -DUSB_MANUFACTURER="Bare Conductive" -DUSB_PRODUCT="Touch Board" -I/home/achayan/Downloads/arduino-1.5.7/hardware/arduino/avr/cores/arduino -I/home/achayan/Downloads/arduino-1.5.7/hardware/arduino/avr/variants/leonardo /home/achayan/Downloads/arduino-1.5.7/hardware/arduino/avr/cores/arduino/HardwareSerial0.cpp -o /tmp/build5447563659949358969.tmp/HardwareSerial0.cpp.o
/home/achayan/Downloads/arduino-1.5.7/hardware/tools/avr/bin/avr-g++ -c -g -Os -w -fno-exceptions -ffunction-sections -fdata-sections -MMD -mmcu=atmega32u4 -DF_CPU=16000000L -DARDUINO=157 -DARDUINO_AVR_BARETOUCH -DARDUINO_ARCH_AVR -DUSB_VID=0x2A6E -DUSB_PID=0x8003 -DUSB_MANUFACTURER="Bare Conductive" -DUSB_PRODUCT="Touch Board" -I/home/achayan/Downloads/arduino-1.5.7/hardware/arduino/avr/cores/arduino -I/home/achayan/Downloads/arduino-1.5.7/hardware/arduino/avr/variants/leonardo /home/achayan/Downloads/arduino-1.5.7/hardware/arduino/avr/cores/arduino/new.cpp -o /tmp/build5447563659949358969.tmp/new.cpp.o
/home/achayan/Downloads/arduino-1.5.7/hardware/tools/avr/bin/avr-g++ -c -g -Os -w -fno-exceptions -ffunction-sections -fdata-sections -MMD -mmcu=atmega32u4 -DF_CPU=16000000L -DARDUINO=157 -DARDUINO_AVR_BARETOUCH -DARDUINO_ARCH_AVR -DUSB_VID=0x2A6E -DUSB_PID=0x8003 -DUSB_MANUFACTURER="Bare Conductive" -DUSB_PRODUCT="Touch Board" -I/home/achayan/Downloads/arduino-1.5.7/hardware/arduino/avr/cores/arduino -I/home/achayan/Downloads/arduino-1.5.7/hardware/arduino/avr/variants/leonardo /home/achayan/Downloads/arduino-1.5.7/hardware/arduino/avr/cores/arduino/Stream.cpp -o /tmp/build5447563659949358969.tmp/Stream.cpp.o
/home/achayan/Downloads/arduino-1.5.7/hardware/tools/avr/bin/avr-g++ -c -g -Os -w -fno-exceptions -ffunction-sections -fdata-sections -MMD -mmcu=atmega32u4 -DF_CPU=16000000L -DARDUINO=157 -DARDUINO_AVR_BARETOUCH -DARDUINO_ARCH_AVR -DUSB_VID=0x2A6E -DUSB_PID=0x8003 -DUSB_MANUFACTURER="Bare Conductive" -DUSB_PRODUCT="Touch Board" -I/home/achayan/Downloads/arduino-1.5.7/hardware/arduino/avr/cores/arduino -I/home/achayan/Downloads/arduino-1.5.7/hardware/arduino/avr/variants/leonardo /home/achayan/Downloads/arduino-1.5.7/hardware/arduino/avr/cores/arduino/CDC.cpp -o /tmp/build5447563659949358969.tmp/CDC.cpp.o
/home/achayan/Downloads/arduino-1.5.7/hardware/tools/avr/bin/avr-ar rcs /tmp/build5447563659949358969.tmp/core.a /tmp/build5447563659949358969.tmp/wiring_analog.c.o
/home/achayan/Downloads/arduino-1.5.7/hardware/tools/avr/bin/avr-ar rcs /tmp/build5447563659949358969.tmp/core.a /tmp/build5447563659949358969.tmp/wiring_digital.c.o
/home/achayan/Downloads/arduino-1.5.7/hardware/tools/avr/bin/avr-ar rcs /tmp/build5447563659949358969.tmp/core.a /tmp/build5447563659949358969.tmp/wiring_shift.c.o
/home/achayan/Downloads/arduino-1.5.7/hardware/tools/avr/bin/avr-ar rcs /tmp/build5447563659949358969.tmp/core.a /tmp/build5447563659949358969.tmp/WInterrupts.c.o
/home/achayan/Downloads/arduino-1.5.7/hardware/tools/avr/bin/avr-ar rcs /tmp/build5447563659949358969.tmp/core.a /tmp/build5447563659949358969.tmp/hooks.c.o
/home/achayan/Downloads/arduino-1.5.7/hardware/tools/avr/bin/avr-ar rcs /tmp/build5447563659949358969.tmp/core.a /tmp/build5447563659949358969.tmp/wiring_pulse.c.o
/home/achayan/Downloads/arduino-1.5.7/hardware/tools/avr/bin/avr-ar rcs /tmp/build5447563659949358969.tmp/core.a /tmp/build5447563659949358969.tmp/wiring.c.o
/home/achayan/Downloads/arduino-1.5.7/hardware/tools/avr/bin/avr-ar rcs /tmp/build5447563659949358969.tmp/core.a /tmp/build5447563659949358969.tmp/HardwareSerial3.cpp.o
/home/achayan/Downloads/arduino-1.5.7/hardware/tools/avr/bin/avr-ar rcs /tmp/build5447563659949358969.tmp/core.a /tmp/build5447563659949358969.tmp/Tone.cpp.o
/home/achayan/Downloads/arduino-1.5.7/hardware/tools/avr/bin/avr-ar rcs /tmp/build5447563659949358969.tmp/core.a /tmp/build5447563659949358969.tmp/HardwareSerial1.cpp.o
/home/achayan/Downloads/arduino-1.5.7/hardware/tools/avr/bin/avr-ar rcs /tmp/build5447563659949358969.tmp/core.a /tmp/build5447563659949358969.tmp/HardwareSerial2.cpp.o
/home/achayan/Downloads/arduino-1.5.7/hardware/tools/avr/bin/avr-ar rcs /tmp/build5447563659949358969.tmp/core.a /tmp/build5447563659949358969.tmp/Print.cpp.o
/home/achayan/Downloads/arduino-1.5.7/hardware/tools/avr/bin/avr-ar rcs /tmp/build5447563659949358969.tmp/core.a /tmp/build5447563659949358969.tmp/HID.cpp.o
/home/achayan/Downloads/arduino-1.5.7/hardware/tools/avr/bin/avr-ar rcs /tmp/build5447563659949358969.tmp/core.a /tmp/build5447563659949358969.tmp/USBCore.cpp.o
/home/achayan/Downloads/arduino-1.5.7/hardware/tools/avr/bin/avr-ar rcs /tmp/build5447563659949358969.tmp/core.a /tmp/build5447563659949358969.tmp/HardwareSerial.cpp.o
/home/achayan/Downloads/arduino-1.5.7/hardware/tools/avr/bin/avr-ar rcs /tmp/build5447563659949358969.tmp/core.a /tmp/build5447563659949358969.tmp/IPAddress.cpp.o
/home/achayan/Downloads/arduino-1.5.7/hardware/tools/avr/bin/avr-ar rcs /tmp/build5447563659949358969.tmp/core.a /tmp/build5447563659949358969.tmp/WMath.cpp.o
/home/achayan/Downloads/arduino-1.5.7/hardware/tools/avr/bin/avr-ar rcs /tmp/build5447563659949358969.tmp/core.a /tmp/build5447563659949358969.tmp/WString.cpp.o
/home/achayan/Downloads/arduino-1.5.7/hardware/tools/avr/bin/avr-ar rcs /tmp/build5447563659949358969.tmp/core.a /tmp/build5447563659949358969.tmp/main.cpp.o
/home/achayan/Downloads/arduino-1.5.7/hardware/tools/avr/bin/avr-ar rcs /tmp/build5447563659949358969.tmp/core.a /tmp/build5447563659949358969.tmp/HardwareSerial0.cpp.o
/home/achayan/Downloads/arduino-1.5.7/hardware/tools/avr/bin/avr-ar rcs /tmp/build5447563659949358969.tmp/core.a /tmp/build5447563659949358969.tmp/new.cpp.o
/home/achayan/Downloads/arduino-1.5.7/hardware/tools/avr/bin/avr-ar rcs /tmp/build5447563659949358969.tmp/core.a /tmp/build5447563659949358969.tmp/Stream.cpp.o
/home/achayan/Downloads/arduino-1.5.7/hardware/tools/avr/bin/avr-ar rcs /tmp/build5447563659949358969.tmp/core.a /tmp/build5447563659949358969.tmp/CDC.cpp.o
/home/achayan/Downloads/arduino-1.5.7/hardware/tools/avr/bin/avr-gcc -w -Os -Wl,--gc-sections -mmcu=atmega32u4 -o /tmp/build5447563659949358969.tmp/Blink.cpp.elf /tmp/build5447563659949358969.tmp/Blink.cpp.o /tmp/build5447563659949358969.tmp/core.a -L/tmp/build5447563659949358969.tmp -lm
/home/achayan/Downloads/arduino-1.5.7/hardware/tools/avr/bin/avr-objcopy -O ihex -j .eeprom --set-section-flags=.eeprom=alloc,load --no-change-warnings --change-section-lma .eeprom=0 /tmp/build5447563659949358969.tmp/Blink.cpp.elf /tmp/build5447563659949358969.tmp/Blink.cpp.eep
/home/achayan/Downloads/arduino-1.5.7/hardware/tools/avr/bin/avr-objcopy -O ihex -R .eeprom /tmp/build5447563659949358969.tmp/Blink.cpp.elf /tmp/build5447563659949358969.tmp/Blink.cpp.hex

Sketch uses 4,798 bytes (16%) of program storage space. Maximum is 28,672 bytes.
Global variables use 157 bytes (6%) of dynamic memory, leaving 2,403 bytes for local variables. Maximum is 2,560 bytes.
Forcing reset using 1200bps open/close on port /dev/ttyACM0
PORTS {/dev/ttyACM0, } / {} => {}
PORTS {} / {} => {}
PORTS {} / {/dev/ttyACM0, } => {/dev/ttyACM0, }
Found upload port: /dev/ttyACM0
/home/achayan/Downloads/arduino-1.5.7/hardware/tools/avr/bin/avrdude -C/home/achayan/Downloads/arduino-1.5.7/hardware/tools/avr/etc/avrdude.conf -v -v -v -v -patmega32u4 -cavr109 -P/dev/ttyACM0 -b57600 -D -Uflash:w:/tmp/build5447563659949358969.tmp/Blink.cpp.hex:i

avrdude: Version 6.0.1, compiled on Apr  3 2014 at 21:52:43
         Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
         Copyright (c) 2007-2009 Joerg Wunsch

         System wide configuration file is "/home/achayan/Downloads/arduino-1.5.7/hardware/tools/avr/etc/avrdude.conf"
         User configuration file is "/root/.avrduderc"
         User configuration file does not exist or is not a regular file, skipping

         Using Port                    : /dev/ttyACM0
         Using Programmer              : avr109
         Overriding Baud Rate          : 57600
         AVR Part                      : ATmega32U4
         Chip Erase delay              : 9000 us
         PAGEL                         : PD7
         BS2                           : PA0
         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  9000  9000 0x00 0x00
                                  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 0x00 0x00
                                  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  9000  9000 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  9000  9000 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  9000  9000 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  9000  9000 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 : butterfly
         Description     : Atmel AppNote AVR109 Boot Loader

Connecting to programmer: .avrdude: Send: . [1b]
avrdude: Send: S [53]
avrdude: Recv: C [43]

avrdude: ser_recv(): programmer is not responding
avrdude: butterfly_recv(): programmer is not responding

And My dmesg output is
[ 3616.984079] usb 4-2: new full-speed USB device number 11 using uhci_hcd
[ 3617.155216] usb 4-2: New USB device found, idVendor=2a6e, idProduct=8003
[ 3617.155224] usb 4-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 3617.155229] usb 4-2: Product: Touch Board
[ 3617.155234] usb 4-2: Manufacturer: Bare Conductive
[ 3617.158323] cdc_acm 4-2:1.0: This device cannot do calls on its own. It is not a modem.
[ 3617.158359] cdc_acm 4-2:1.0: ttyACM0: USB ACM device
[ 3617.166427] input: Bare Conductive Touch Board as /devices/pci0000:00/0000:00:1a.1/usb4/4-2/4-2:1.2/input/input22
[ 3617.166675] hid-generic 0003:2A6E:8003.0007: input,hidraw1: USB HID v1.01 Mouse [Bare Conductive Touch Board] on usb-0000:00:1a.1-2/input2

And My lsusb output
Bus 002 Device 002: ID 04f2:b179 Chicony Electronics Co., Ltd
Bus 002 Device 004: ID 18d1:4ee2 Google Inc. Nexus 4 (debug)
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 008 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 007 Device 002: ID 03f0:171d Hewlett-Packard Bluetooth 2.0 Interface [Broadcom BCM2045]
Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 011: ID 2a6e:8003
Bus 004 Device 002: ID 1d57:0008 Xenta
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub

Try the arduino.cc forums. Post your logs, and you MIGHT get an answer that'll work. The guys who developed the Leonardo got it to work with Ubuntu 10.04 without a special device driver. I use Ubuntu like you but not the magic 10.04 version and was forced to give up on the Leonardo despite heroic effort.
The problem is that 32u4 chip the Leonardo (and Micro) use. Instead of having a separate FTDI chip like a good ol' UNO, it handles USB on its own. With a bootloader on a Leonardo that enables only USB to be used (besides ICSP) Windows needs a funny .inf file to make it work. But Linux? In this case, Windows of a given version is Windows is Windows. Linux boxes are more like people in that each has its own personality, given the zillion distributions and versions thereof.
I'm convinced that the Leonardo developers merely got lucky with Ubuntu 10.04.

This is not an answer.

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


text:
What in the example code is different from my test code? LED matrix lights up differently
I'm trying to get my LED matrix to run Conway's Game of Life. After 4 different pin configurations, I've finally been able to run a separate test code, that lights all the LED's in order, and then turns them off in order (Code Below). I've written the entirety of GoL in C#, but the Arduino language is just different enough to where I can write sort of ok in it, but not enough to understand what's going wrong. I got a Game of Life code from here and it won't even light my LEDs, or when it does, it's incredibly dim, unlike my test code. I'll show my pin layout in the code. I've tried changing the pins in the GoL code, copying the setup from one to the other, and  but for the life of me, I can't seem to figure out why one would light up the LED's without a hitch, and the other is struggling. Can anybody see the changes I'd need to make that would make the GoL code at that link, work like this test code?
Here's my Test code that works fine:
int speed = 4; //the delay time in milliseconds

int pauseDelay = 1;    //the number of milliseconds to display each scanned line

//Pin Definitions
int rowA[] = {14,15,16,17,2,3,4,5};          //An Array defining which pin each row is attached to
                                     //(rows are common anode (drive HIGH))
int colA[] = {6,7,8,9,10,11,12,13};  //An Array defining which pin each column is attached to
                                     //(columns are common cathode (drive LOW))

//The array used to hold a bitmap of the display
//(if you wish to do something other than scrolling marque change the data in this
//variable then display)
byte data[] = {0,0,0,0,0,0,0,0};

//Setup runs once when power is applied
void setup()
{
  Serial.begin(9600);         //Open the Serial port for debugging
  for(int i = 0; i <8; i++){  //Set the 16 pins used to control the array as OUTPUTs
    pinMode(rowA[i], OUTPUT);
    pinMode(colA[i], OUTPUT);
  }
}

//repeats
void loop()
{
 //Example #1 - test pattern
 //Run a small test program which lights up each light in time
  test();

 //Example #2 - static image
 //Display a defined bitmap
/*
  data[0] = B10101010; //row 1s bit mask (1 LED is on 0 LED is off)
  data[1] = B01010101; //row 1s bit mask (1 LED is on 0 LED is off)
  data[2] = B10101010; //row 1s bit mask (1 LED is on 0 LED is off)
  data[3] = B01010101; //row 1s bit mask (1 LED is on 0 LED is off)
  data[4] = B10101010; //row 1s bit mask (1 LED is on 0 LED is off)
  data[5] = B01010101; //row 1s bit mask (1 LED is on 0 LED is off)
  data[6] = B10101010; //row 1s bit mask (1 LED is on 0 LED is off)
  data[7] = B01010101; //row 1s bit mask (1 LED is on 0 LED is off)
  showSprite(speed);
*/
 }

//An array to store power values to act as bit masks
const int powers[] = {1,2,4,8,16,32,64,128};

//Runs a pattern where each LED is lit one after another
void test(){
  for(int i = 0; i < 8; i++){
for(int ii = 0; ii< 8; ii++){
data[i] = data[i]+ powers[ii];   //Goes through each row of lights lighting each column one after another
showSprite(speed);
}
  }

  for(int i = 0; i < 8; i++){
   for(int ii = 0; ii< 8; ii++){
data[i] = data[i] - powers[ii];   //Goes through each row of lights turning off each column one after another
   showSprite(speed);
    }
  }
}

void showSprite(int speed2){
 for(int iii = 0; iii < speed2; iii++){                 //show the current frame speed2 times
  for(int column = 0; column < 8; column++){            //iterate through each column
       for(int i = 0; i < 8; i++){
           digitalWrite(rowA[i], LOW);                      //turn off all row pins
   }
   for(int i = 0; i < 8; i++){ //Set only the one pin
     if(i == column){     digitalWrite(colA[i], LOW);}  //turns the current row on
     else{                digitalWrite(colA[i], HIGH); }//turns the rest of the rows off
   }

   for(int row = 0; row < 8; row++){                    //iterate through each pixel in the current column
    int bit = (data[column] >> row) & 1;
    if(bit == 1){
       digitalWrite(rowA[row], HIGH);                   //if the bit in the data array is set turn the LED on
    }

   }
   delay(pauseDelay);                       //leave the column on for pauseDelay microseconds (too high a delay causes flicker)
  }
 }
}

I ended up using a different PIN layout, and the GoL code had the pins As anodes where they were Cathodes in the other code. Switched rows pins to Columns pins in the code and Problem solved.


text:
How to connect mini jack output to arduino mini pro and send sound to it?
I would like to connect arduino mini pro to mini jack output and send sound through it.
What would I need here, how can I connect the mini jack to arduino and how to send data of sounds (any library?) to that connected output?
EDIT
The sound source will be a music file ( streamed via bluetooth). I would like to be able to connect this output to a speaker and play (stream) music via bluetooth.
EDIT
Either mono or stereo will be good for me. My plan is to: stream the music via bluetooth to bluetooth module (for now I think about HC-06), send that data stream through arduino mini pro to the output mini jack.
Do I need in that case some kind of mp3/other format decoder module like VS1003B on ebay ?

@Majenko Edited.

@Majenko I added some information, I am trying to get some information on my possibilities here - that's the reason for my question.

What about this VS1053?

I do not recommend using the HC-06 chip. First of all, it is a serial chip, thus it sends text, not audio. You might be able to convert it to character codes on the phone side, but that'd be a lot of work. Also, the baud rate might not be high enough to keep up with what you want to do.

I have found docs that say the baud rate can be set up to 1382400 googledoc (of few others). Any alternative for this chip(non serial one) ?

I don't really know if there's one in breakout form for such a chip. Also, for those types of chips, they would be designed to provide a direct connection to a 3.5mm jack or to a decoder chip

@AnnonomusPenguin What about those type of integrated bluetooth mp3 decoder? ebay spk d bluetooth mp3 decoder

Yes, that'd be better. I can't give you much advice since a.) there's no datasheet so it'd be near impossible to give you correct advice and b.) that chip is beyond the scope of Arduino SE because it doesn't use an Arduino.

The Arduino Uno / Mini Pro is not really the right tool for the job. It has no native audio output such as a 3.5mm jack.
Having said that I am sure it can be done - but it won't be the best quality sound. I have no doubt that it can be achieved with one of the following methods:

using the tone() function.
by using a R-2R resistor ladder network and some sort of amplification circuit.

The Arduino Due and the Arduino M0 / M0 Pro both have inbuilt DAC's, meaning that they can output analog signals which can be used to drive a speaker circuit.
Another option is to use a Raspberry Pi which has a native 3.5mm audio jack.

Or you can use the PWM as a poor man's DAC. That's what the Mozzi sound synthesis library does.


text:
How can I speed up reading of an SD card?
I am working on a project using an Arduino as a web server.
Code:
webFile = SD.open("index.htm");
if (webFile) {
  while(webFile.available()) {
    client.write(webFile.read());
  }
webFile.close();

This sends data line by line, leading to a long time to load the webpage. Is there a faster way to load this page?

Yes, reading in a full sector at a time and writing in large pieces which a TCP stack can chop into full packets which can be left outstanding awaiting later acks would be preferable - but likely requires more buffer memory than you have.  This is why hanging a network interface on an Arduino is not only an unecessarily costly way to solve a problem,  but also a generally unwise one.

@ChrisStratton plz give me more information about how can do this

Switch to a platform with more memory.  Many of them are substantially cheaper anyway.

Take a look at the libraries produced by www.pjrc.com (teensy)

Well I have two ideas on the SD card side, though neither really seem great to me they could still help you. I read on the Arduino forum that the SD card R/W speeds generally come out to 600kB/s, I'm not really sure why, the Arduino SPI can go up to 8 MB/s and I didn't think there would be that much protocol/data-handling in SD.

Sector R/W - As Chris Stratton said, this is an obvious method, it's probably much faster to do sector reads. You may have to greatly change your code to implement it, but I imagine you'd see performance increase in the end. Apparently there's an unofficial library for it, though it seems to impart some potentially serious limitations.
RAM - This is the second thing that came to mind when thinking about the problem is that you could use external RAM, when not handling network transfers (Idling, should be most of the time) the Arduino transfers data to external SRAM which you add. SPI RAM is most likely the easiest to implement, but not likely to be any faster than an SD card. Parallel RAM is going to be difficult to implement, you'll likely need to write your own class/library, but it could be much faster than SPI RAM or an SD card.

I'm not actually sure if either of these would be any faster, it's all just theory and I hope others will share their thoughts. If you have trouble finding the download link for the SD Card library, it's right here. In that ZIP folder there's a file called SDCARD, just move that folder into your Arduino libraries folder on your computer.

how can get this library ?
i can't found it in google ?
@Unit_One

Adding external RAM to an ATmega is absurdly inefficient.  If you need more memory, use a processor which has that from the start.

When I said RAM, I meant SRAM specifically. Which I did mention. Of course DRAM is practically unusable on Arduino, but SRAM is practical.

Keeping in mind that I do not mean the use of external RAM to supplement the MCU's RAM, which is of course a terrible idea. But only to serve as a buffer for the data in the SD card.

No, adding external SRAM to an ATmega for buffering reads from an sdcard is an absurdly slow and expensive solution to a problem correctly solved by selecting an MCU with sufficient on-board buffer memory (and in the case of this need, on-board or inexpensively added network interface).

maybe you should use SdFat library; a library which is almost the same as the standard SD library, but also it can support Long Filenames.
I did some tests with read and write; it is most of the times > 60% faster!!
https://github.com/greiman/SdFat


text:
Problem to upload code
I tried to upload example code form arduino software and got error below. Two arduino attach with my computer running windows8.1. And These arduino using port 3 and port 4. The arduino using Port 3 is cordinator and arduino using port 4 is router.
I doesn't understand why error show COM1 is not available. I am not using COM1.
Arduino: 1.6.0 (Windows 8), Board: "Arduino Uno"

Sketch uses 1,030 bytes (3%) of program storage space. Maximum is 32,256 bytes.

Global variables use 9 bytes (0%) of dynamic memory, leaving 2,039 bytes for local variables. Maximum is 2,048 bytes.

C:\Program Files (x86)\Arduino/hardware/tools/avr/bin/avrdude -CC:\Program Files (x86)\Arduino/hardware/tools/avr/etc/avrdude.conf -v -patmega328p -carduino -PCOM1 -b115200 -D -Uflash:w:C:\Users\Jiya\AppData\Local\Temp\build1135139715306090793.tmp/Blink.cpp.hex:i

avrdude: Version 6.0.1, compiled on Apr  3 2014 at 23:12:16
         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                    : COM1
         Using Programmer              : arduino
         Overriding Baud Rate          : 115200
avrdude: ser_open(): can't open device "\\.\COM1": The system cannot find the file specified.

avrdude done.  Thank you.

Problem uploading to board.  See http://www.arduino.cc/en/Guide/Troubleshooting#upload for suggestions.

Board at COM1 is not available
Board at COM1 is not available
Board at COM1 is not available
Board at COM1 is not available
Board at COM1 is not available

  This report would have more information with
  "Show verbose output during compilation"
  enabled in File > Preferences.

(I'm assuming you're using the official Arduino IDE here.)
Before uploading a sketch, you need to select which port you want to upload to. Within the Arduino IDE, click on the Tools menu and open the Port submenu. Click on the port your Arduino is connected to, such as COM3 or COM4.
You also need to ensure the appropriate board type is selected in Tools -> Board.
You should then be able to and upload the sketch.

If all the other solutions don't work and you are on a Linux distro try sudo arduino and that should work, or follow these instructions: Getting Started With Arduino on Linux (Ubuntu)

It looks like the user is on a Windows machine – and on *nix even the super user can't open a nonexistent file :-)

Did you try with code bender. In my experience, uploading through the code bender works all the time even if it fails with Arduino IDE

On windows systems, COM1 is usually the system port, so you shouldn't use that for programming.
Try updating device drivers by going to device manager and right click on the COM3 and COM4 icons for the arduino boards.
If this keeps persisting then try reinstalling the ide and restarting your computer

Experience has taught me twice... to make sure you use the right cables.  I used a spare cable that ended up being a power brick charging cable, i.e. no data lines.  Make sure you use a decent USB cable - preferably one that asks you question on a cellphone when connected to a PC, so you know all the internal wires are there and working.

your kernel need to provide support to USB ACM.
CONFIG_USB_ACM=y

you can look for it at:
$ zcat /proc/config.gz | grep CONFIG_USB_ACM
CONFIG_USB_ACM=y

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


text:
Could someone explain this weird looking code, used to setup timers?
While looking at sketches other people have written, I occasionally come across code that looks somewhat like this:
TCCR1A = 0;
TCCR1B = 0;

TCNT1 = 34286;
TCCR1B |= (1 << CS12);
TIMSK1 |= (1 << TOIE1);

All I know is that is has something to with timing/timers (I think). How can I decipher—and create—code like this? What are TCCR1A, TCCR1B, TCNT1, CS12, TIMSK1, and TOIE1?

Don't know enough to answer but: http://electronics.stackexchange.com/questions/92350/what-is-the-difference-between-tccr1a-and-tccr1b, http://forum.arduino.cc/index.php?topic=134602.0, and http://stackoverflow.com/questions/9475482/pulse-width-modulation-pwm-on-avr-studio. Don't know if you've seen these already.

Download the "Complete" datasheet for your device from the Atmel website and read the chapters about timers. The datasheet is surprisingly good to read in my opinion.

This isn't weird looking. It's what normal MCU code actually looks like.
What you have here is an example of the concept of memory-mapped peripherals. Basically, the MCU hardware has special locations in the SRAM address space of the MCU assigned to it. If you write to these addresses, the bits of the byte written to address n control the behaviour of peripheral m.
Basically, certain banks of memory literally have little wires running from the SRAM cell to the hardware. If you write a "1" to this bit in that byte, it sets this SRAM cell to a logical high, which then turns on some portion of the hardware.
If you look into the headers for the MCU, there are great big tables of keyword<->address mappings. This is how things like TCCR1B etc... are resolved at compile time.
This memory-mapping mechanism is extremely broadly used in MCUs. The ATmega MCU in the arduino use it, as do PIC, ARM, MSP430, STM32 and STM8 MCU series, as well as lots of MCUs I'm not immediately familiar with.

Arduino code is the weird stuff, with functions that access the MCU control registers indirectly. While this is somewhat "nicer" looking, it's also much slower, and uses a lot more program space.
The mysterious constants are all described in great detail in the ATmega328P datasheet, which you really should read if you're interested in doing anything more then occationally toggling pins on an arduino.
Select excerpts from the datasheet linked above:

So, for example, TIMSK1 |= (1 << TOIE1); sets the bit TOIE1 in TIMSK1. This is achieved by shifting binary 1 (0b00000001) to the left by TOIE1 bits, with TOIE1 being defined in a header file as 0. This is then bitwise ORed into the current value of TIMSK1, which effectively set this one bit high.
Looking at the documentation for bit 0 of TIMSK1, we can see it is described as

When this bit is written to one, and the I-flag in the Status Register
  is set (interrupts globally enabled), the Timer/Counter1 Overflow
  interrupt is enabled. The corresponding Interrupt Vector (See
  ”Interrupts” on page 57) is executed when the TOV1 Flag, located in
  TIFR1, is set.

All the other lines should be interpreted in the same manner.

Some notes:
You may also see things like TIMSK1 |= _BV(TOIE1);. _BV() is a commonly used macro originally from the AVR libc implementation. _BV(TOIE1) is functionally identical to (1 << TOIE1), with the benefit of better readability.
Also, you may also see lines such as: TIMSK1 &= ~(1 << TOIE1); or TIMSK1 &= ~_BV(TOIE1);. This has the opposite function of TIMSK1 |= _BV(TOIE1);, in that it unsets the bit TOIE1 in TIMSK1. This is achieved by taking the bit-mask produced by _BV(TOIE1), performing a bitwise NOT operation on it (~), and then ANDing TIMSK1 by this NOTed value (which is 0b11111110).
Note that in all these cases, the value of things like (1 << TOIE1) or _BV(TOIE1) are fully resolved at compile time, so they functionally reduce to a simple constant, and therefore take no execution time to compute at runtime.

Properly written code will generally have comments inline with the code that detail what the registers being assigned to do. Here is a fairly simple soft-SPI routine I wrote recently:
uint8_t transactByteADC(uint8_t outByte)
{
    // Transfers one byte to the ADC, and receives one byte at the same time
    // does nothing with the chip-select
    // MSB first, data clocked on the rising edge

    uint8_t loopCnt;
    uint8_t retDat = 0;

    for (loopCnt = 0; loopCnt < 8; loopCnt++)
    {
        if (outByte & 0x80)         // if current bit is high
            PORTC |= _BV(ADC_MOSI);     // set data line
        else
            PORTC &= ~(_BV(ADC_MOSI));  // else unset it

        outByte <<= 1;              // and shift the output data over for the next iteration
        retDat <<= 1;               // shift over the data read back

        PORTC |= _BV(ADC_SCK);          // Set the clock high

        if (PINC & _BV(ADC_MISO))       // sample the input line
            retDat |= 0x01;         // and set the bit in the retval if the input is high

        PORTC &= ~(_BV(ADC_SCK));       // set clock low
    }
    return retDat;
}

PORTC is the register that controls the value of output pins within PORTC of the ATmega328P. PINC is the register where the input values of PORTC are available. Fundamentally, things like this are what happen internally when you use the digitalWrite or digitalRead functions. However, there is a look-up operation that converts the arduino "pin numbers" into actual hardware pin numbers, which takes somewhere in the realm of 50 clock cycles. As you can probably guess, if you're trying to go fast, wasting 50 clock cycles on an operation that should only require 1 is a bit ridiculous.
The above function probably takes somewhere in the realm of 100-200 clock cycles to transfer 8 bits. This entails 24 pin-writes, and 8 reads. This is many, many times faster then using the digital{stuff} functions.

Note that this code should also work with Atmega32u4 (used in Leonardo) as it contains more timers than ATmega328P.

+1 Excellent answer!! Could you please ellaborate a bit on what you mean by Arduino code is the weird stuff? What exactly is unique to Arduino code, that's not usually found in other platforms?

@Ricardo - Probably 90%+ of small-MCU embedded code uses direct register manipulation. Doing things with indirect utility functions is very much not the common mode of manipulating IO/peripherals. There are some toolkits for abstracting away hardware control (The Atmel ASF, for example), but that's generally written to compile away as much as possible to reduce runtime overhead, and almost invariably requires actually understanding the peripherals by reading the datasheets.

Basically, arduino stuff, by saying "here are functions that do X", without really bothering to reference the actual documentation or how the hardware is doing the things it does, is very much not normal. I understand it's value as a introductory tool, but except for quick prototyping, it's not really ever done in actual professional environments.

To be clear, the thing that makes arduino code unusual for embedded MCU firmware is not unique to arduino code, it's a function of the overall approach. Basically, once you have a decent understanding of the actual MCU, doing things properly (e.g. using hardware registers directly) takes little to no additional time. As such, if you want to learn real MCU dev, it's much better to just sit down and understand what your MCU is actually doing, rather then relying on someone else's abstraction, which tends to be leaky.

Basically, the whole arduino system is more or less designed to allow low-barrier-of-entry to non-programmers. It does this well, but at the same time it doesn't do a good job of forcing end-users to actually understand the hardware, simply because that is antithetical to low-barrier-of-entry. I recognize that this can (and is) a valuable stepping-stone for people on the road to learning software/MCU dev, but anyone using it should not be under any illusions that the arduino way is necessarily the best, or even sometimes a good way of doing what it does.

Note that I may be a bit cynical here, but a lot the behaviours I see in the arduino community are programming anti-patterns. I see a lot of "copy-paste" programming, the treating of libraries as black-boxes, and just general poor design practices in the community at large. Of course, I'm fairly active on EE.stackexchange, so I may have a somewhat slanted view, since I have some moderator tools, and as such see a lot of the closed questions. There is definitely a bias in the arduino questions I've seen there towards "tell me what to C&P to fix", rather then "why is this not working".

It's probably also worth noting that the very use of C++ is somewhat unusual. Most small MCU work is done in pure-C only.

Got it! It wasn't clear to me what you called indirect access to registers in Arduino, but now I know its the digitalWrite() kind of abstractions. It does reduce the barrier for entry, but later becomes a barrier for going forward. But your answer is a great step torwards removing that obstacle. At least for me.

@Ricardo - Yep. One of the things I really do like about arduino as a teaching tool is that it gives you a working environment for playing with the hardware directly, without having to deal with the often most irritating part: the initial bring-up. I've worked on platforms where all I had was a ISP and no working examples. Having to try to troubleshoot why the serial debug interface I was trying to get working without any real debugging interface is.... involved. Having a platform with easy-to-use serial libs is very nice.

TCCR1A is timer/counter 1 control register A
TCCR1B is timer/counter 1 control register B
TCNT1 is timer/counter 1's counter value
CS12 is the 3rd clock select bit for timer/counter 1
TIMSK1 is timer/counter 1's interrupt mask register
TOIE1 is the timer/counter 1 overflow interrupt enable
So, the code enables timer/counter 1 at 62.5 kHz and sets the value to 34286. Then it enable the overflow interrupt so when it reaches 65535, it will trigger the interrupt function, most likely labelled as ISR(timer0_overflow_vect)

CS12 has a value of 2 since it represents bit 2 of the TCCR1B register.
(1 << CS12) takes the value 1 (0b00000001) and shifts it left 2 times to get (0b00000100).
The order of operations dictates that things in () happen first, so this is done before the "|=" is evaluated.
(1 << CS10) takes the value 1 (0b00000001) and shifts it left 0 times to get (0b00000001).
The order of operations dictates that things in () happen first, so this is done before the "|=" is evaluated.
So now we get TCCR1B |= 0b00000101, which is the same as TCCR1B = TCCR1B | 0b00000101.
Since "|" is "OR", all the bits other than CS12 in TCCR1B are unaffected.


text:
Function that returns a Structure
I want to create a structure called CarSpeed it has 4 int FR,FL,BR,BL (FrontRight,..) ; and i would like to create a function that returns this structure :
ActualSpeed Readspeed(void)
{
   code to read the speed of the car(already done)
}

Can someone help me define a function that returns this structure  ? only the way how I should define it, the usual C way doesnt work :
typedefstruct CarSpeed{...}

and then
CarSpeed ActualSpeed;
ActualSpeed Readspeed(void){.. }

Since you're (probably) using a C++ compiler, it's usually easier to declare structures like this:
struct CarSpeed
{
    int fr, fl, br, bl;
};

(Note that there's no need for typedef.)
You can then return an instance of it directly from your function:
CarSpeed ReadSpeed()
{
    CarSpeed data;

    data.fr = ...;
    data.fl = ...;
    data.br = ...;
    data.bl = ...;

    return data;
}

You can call it from another function like this:
CarSpeed speed = ReadSpeed();

That will copy the contents of the structure into an object called speed. In this example, it's an 8 byte structure so it's a non-trivial copy. That shouldn't be a big problem unless you're calling it very frequently though.
As noted in another answer, using a pointer (or a reference) can be more efficient if necessary.

Thx, but I get this error :
nMotSet-Final:12: error: 'CarSpeed' does not name a type , maybe i should include the variable creation part in a .h file ?

If you mean the struct declaration, then it's essential to put that in a header file if you intend to call ReadSpeed() from a different file.

I would recommend to use pointers, it's faster and has the same result.
Something like this (disclaimer - I did not compile it):
typedef struct {
   int a;
   int b;
} pair;

int init_pair(pair *ptr) {
   if (!ptr)
      return -1;
   ptr->a = 6;
   ptr->b = 9;
   return 0;
}

int do_something() {
   pair mypair;
   return init_pair(&mypair);
}


text:
what is the use of "<<=" operator?
I recently read this piece of code and I dont know what is the use of "<<=" in the for loop:
for (mask = 0x01; mask>0; mask <<= 1) {
    if (data & mask){ // choose bit

This is the entire code:
//Created August 23 2006
//Heather Dewey-Hagborg
//http://www.arduino.cc

#include <ctype.h>

#define bit9600Delay 100
#define halfBit9600Delay 500
#define bit4800Delay 188
#define halfBit4800Delay 94

byte rx = 6;
byte tx = 7;
byte SWval;

void setup() {
  pinMode(rx,INPUT);
  pinMode(tx,OUTPUT);
  digitalWrite(tx,HIGH);
  delay(2);
  digitalWrite(13,HIGH); //turn on debugging LED
  SWprint('h');  //debugging hello
  SWprint('i');
  SWprint(10); //carriage return
}

void SWprint(int data)
{
  byte mask;
  //startbit
  digitalWrite(tx,LOW);
  delayMicroseconds(bit9600Delay);
  for (mask = 0x01; mask>0; mask <<= 1) {
    if (data & mask){ // choose bit
     digitalWrite(tx,HIGH); // send 1
    }
    else{
     digitalWrite(tx,LOW); // send 0
    }
    delayMicroseconds(bit9600Delay);
  }
  //stop bit
  digitalWrite(tx, HIGH);
  delayMicroseconds(bit9600Delay);
}

int SWread()
{
  byte val = 0;
  while (digitalRead(rx));
  //wait for start bit
  if (digitalRead(rx) == LOW) {
    delayMicroseconds(halfBit9600Delay);
    for (int offset = 0; offset < 8; offset++) {
     delayMicroseconds(bit9600Delay);
     val |= digitalRead(rx) << offset;
    }
    //wait for stop bit + extra
    delayMicroseconds(bit9600Delay);
    delayMicroseconds(bit9600Delay);
    return val;
  }
}

void loop()
{
    SWval = SWread();
    SWprint(toupper(SWval));
}

As stated in the other answers, the <<= operator shifts the byte to the left; however, the number '1'  after it specifies how far to shift it - so, 2 <<= 2 == 8.
Possibly clearer in binary:
00000001 <<= 1 == 00000010
00000010 <<= 1 == 00000100
00000001 <<= 2 == 00000100

In simpler terms mask <<= 1 is shorthand for mask = mask << 1
In general
variable operator= operand

is the augmented assignment operator which means
variable = variable operator operand

<< is the left bit-shift operator. That means it takes the binary contents of a number and moves everything left by a certain number of binary places (1 place in this case). <<= simply combines the left bit-shift with an assignment, so it takes the current value of mask, shifts it left, and then stores the result back in mask.
In this situation, the mask variable starts with a value of 1. The second time round the loop, it will be 10 (binary). Next time, it will be 100, and so on. Since mask is a byte (which is 8 bits), it will go all the way up to 10000000 and then stop. After that, the 1 effectively falls-off the left and mask ends up with a value of 0.
The purpose of this in the code you provided is to test each individual bit within the data parameter. It basically goes through from least- to most-significant and checks if each bit is 1 or 0. It will then pull an output pin HIGH or LOW (respectively) to match. This allows it to send the contents of the variable digitally to some other device.
Doing low-level binary (aka bit-wise) operations like this is very common in microcontroller programming. If you're not familiar with it then I'd definitely recommend looking up some tutorials online. It opens up a huge range of new possibilities for your projects.


text:
Problem with hc-05 bluettoth module
I wrote a simple program for controlling an LED using mobile. So, I bought the HC-05 bluetooth module configured it and then connected it to  the arduino.
This is the code that I wrote for it.
int ledPin1=13;
int state;
int flag=0;

void setup()
{
    pinMode(ledPin1, OUTPUT);
    digitalWrite(0,HIGH);

    second:
    Serial.begin(9600);
}

void loop()
{
    if(Serial.available() >0)
    {
        state = Serial.read();
        flag=0;
    }
    if (state == '0')
    {
        digitalWrite(ledPin1, LOW);
        if(flag == 0){
            Serial.println("led off");
            flag=1;
        }
    }
    if (state == '1')
    {
        digitalWrite(ledPin1, HIGH);
        if(flag == 0){
            Serial.println("led on");
            flag=1;
        }
    }
}

Everything is working cool with the serial monitor. But, I'm not able to control it using my mobile. I gave an input 1 in serial monitor and if showed "led on". the same thing appears on the commanding interface of the app used in the mobile. So, the bluetooth is transmitting information from the arduino to mobile but I'm not able to send commands from the mobile and control the led. I tried using various apps like  Blueterm, Ardudroid etc but, the situation remains the same.
What am I doing wrong? Is there something wrong with the code?
I'm using Arduino Uno.

Your android app might be sending extra characters like "end of line", which will cause the return value of Serial.read() to be other than 1 or 0 after the first byte. Nevertheless, it looks like it should still turn on or off the LED as soon as it reads the first byte, and do nothing when it reads the following bytes. I have used the "hyperterminal rs232" app successfully to send single characters, maybe give that I try to see if it helps and ensure it is configured at the correct baud rate.
I would recommend to send back to the serial stream the characters read, to ensure they have been received correctly, so I would change this:
if(Serial.available() >0)
{
    state = Serial.read();
    flag=0;
}

to:
if(Serial.available() >0)
{
    state = Serial.read();
    Serial.print(state);
    flag=0;
}

Edit:
Just realised this in setup():
digitalWrite(0,HIGH);

You are setting the receive pin of the UART peripheral to hight, so that is probably why you are not reading data from your phone.

Why don't you try making another code.
If you want to use library, use #include <SoftwareSerial.h>
Do not use digitalWrite(0, HIGH) in void setup(){...}
Declare ledPin = 13;
Use only pinMode and Serial.begin(9600) in void setup()
In loop() do ask if (Serial.available()){...}


text:
Turn on one by one the LEDs of a Neopixel rgb LEDs strip for each detection at the same distance from an Ultrasonic Distance Sensor (HC-SR04)
For this project I seek to create a counter of water glasses we drank throughout the day.
I use for this an Arduino UNO card, a Piezo buzzer and a Neopixel rgb LEDs strip (5 LEDs for this test).
Aside from the last 2 LEDs that only light up to indicate to the user that his presence is considered by the product, I would like that when the HC-SR04 first detects our glass of water between 0 and 5cm (cheers!), the first LED lights up and stays on. When the first LED is on and the HC-SR04 detects a second time our water glass is between 0 and 5cm, then the second LED lights up and stays on as well. And so on.
For each glass detected between 0 and 5cm, a slight sound sounds through the piezo buzzer.
By using the Adafruit Neopixel library (download here), I manage to make everything work as I see fit. However, I still have trouble programming if the LED n is on then the n+1 LED lights up at the next detection between 0 and 5cm, without all the LEDs lighting at the same time in a single detection.
I recently tried to use a boolean to identify when the LED n is true (ON/HIGH), but unsuccessfully. I leave you my code as is by thanking you for any help you can bring me.
See my layout and my code below:

#include <Adafruit_NeoPixel.h>

const int trigPin = 9;
const int echoPin = 10;
const int buzzer = 11;

#define dinPin 4
#define numLEDs 5

Adafruit_NeoPixel strip = Adafruit_NeoPixel(numLEDs, dinPin, NEO_GRB + NEO_KHZ800);

long duration;
int distance;

int blue;
int green;
int off;

boolean lightLED = false;

void setup() {
  strip.begin();
  strip.setBrightness(80);
  strip.show();

  pinMode(trigPin, OUTPUT);
  pinMode(echoPin, INPUT);
  pinMode(buzzer, OUTPUT);
  Serial.begin(9600);
}

void loop() {
  digitalWrite(trigPin, LOW);
  delayMicroseconds(2);

  digitalWrite(trigPin, HIGH);
  delayMicroseconds(10);
  digitalWrite(trigPin, LOW);

  duration = pulseIn(echoPin, HIGH);

  distance = duration * 0.034 / 2;

  uint32_t blue = strip.Color(0, 100, 255);
  uint32_t green = strip.Color(0, 255, 20);
  uint32_t off = strip.Color(0, 0, 0);

  ///////////////////////////////////////////////////////////
  // LED 1 + Buzzer
  ///////////////////////////////////////////////////////////

  if (distance <= 5) {

    if (! lightLED) {
      strip.setPixelColor(0, blue);
      strip.show();
      delay(0);
    }

    else {
      lightLED = false;
    }

    digitalWrite(buzzer, HIGH);
    tone(buzzer, 400, 100);
    delay(75);
    tone(buzzer, 600, 100);
    delay(75);
    tone(buzzer, 800, 100);
    delay(75);
    noTone(buzzer);

  }

  else {
    digitalWrite(buzzer, LOW);
  }

  ///////////////////////////////////////////////////////////
  // LED 2
  ///////////////////////////////////////////////////////////

  if (lightLED && distance <= 5) {

    lightLED = true;

    if (! lightLED) {
      strip.setPixelColor(1, blue);
      strip.show();
      delay(0);
    }
  }

  ///////////////////////////////////////////////////////////
  // DETECT USER PRESENCE
  ///////////////////////////////////////////////////////////

  if (distance >= 6 && distance <= 20) {
    strip.setPixelColor(3, green);
    strip.setPixelColor(4, green);
    strip.show();
    delay(0);
  }

  else {
    strip.setPixelColor(3, off);
    strip.setPixelColor(4, off);
    strip.show();
    delay(0);
  }

  // Voir la distance dans le moniteur
  Serial.print("Distance: ");
  Serial.println(distance);
}

Sorry for the code that is a bit rough, I am a beginner but I hope not to have lost you in my explanations (I lose myself in my code…).
Thanks,
Thibaut

You need to debounce the detection.

Thanks for answering @IgnacioVazquez-Abrams, can you be more explicit with a piece of code or something? As I said, I'm a beginner and I have trouble seeing what you mean.

Search for "debouncing" on Google.  There are many ways to do it in hardware or software.  I doubt you will find someone who has debounced a HC-SR04 in software for an Arduino, you will have to piece together bits from various sources.  Debouncing switches is probably the most common.  You might be a beginner, but if you have written that much you'll be able to write a debouncing function and it will be more 'fun' than copy and paste, because you will understand it.  If you get stuck though, come back with what you have.

Yes you're totally right @Matt :)
I'll see this as soon as possible and will come back here if I struggle to do what I want.
Similarly, I will not fail to share the result if it's successful. Thanks guys.

@Thib Can you share your solution here as an answer (which is encouraged in cases like this)?  I had a similar idea for combining range-detection with the WS2812 so I'm interested in how your project came out.


text:
When writing to SD card the file has all gibberish how do I fix it?
I am working on a class project where I am using a Teensy 3.5 with a Prop Shield with sensor attached that will be loaded into a rocket that I will launch and gather data from the altitude, pressure and temperature sensors and then read into an array and then dump at the peak of the height and when it hits the ground. I believe I have everything working when I test the code but when I open up the txt file I get what looks to be ASCII code but I don't know how to fix it.
Below is the code:
//import statements
#include <SD.h>
#include <SPI.h>
#include <Wire.h>
#include <Adafruit_MPL3115A2.h>

// global variable declarations
Adafruit_MPL3115A2 baro = Adafruit_MPL3115A2();

int seconds = 0;
int secondsPerTick = 0;
int counter = 0;
double pressure[15];
double heightA[15];
double temperature[15];
File myFile;
int tempNum;
const int chipSelect = BUILTIN_SDCARD;

//test to make sure program uploaded
void setup() {
  Serial.begin(9600);
  Serial.println("Adafruit_MPL3115A2 test!");
  while (!Serial){
}

  if (! baro.begin()) {
    Serial.println("Couldnt find sensor");
   return;
  }

if (!SD.begin(chipSelect)) {
    Serial.println("initialization failed!");
    return;
  }

while ( seconds < 5 ){

              double pascals = baro.getPressure();
              pressure[counter] = pascals;
              Serial.print(pascals/3377); Serial.println(" Inches (Hg)");

             double altm = baro.getAltitude();
              heightA[counter] = altm;
              Serial.print(altm); Serial.println(" meters");

             double tempC = baro.getTemperature();
              temperature[counter] = tempC;
              Serial.print(tempC); Serial.println(" *C");
              tempNum ++;

              secondsPerTick++; //increments seconds per tick
              if(secondsPerTick == 3){  //if its 3 reset "secondspertick" and increments "seconds"
                secondsPerTick = 0;
                seconds++;
              }
              counter++;

 }

myFile = SD.open("Sensor4.txt", FILE_WRITE);

   if(myFile) {
    Serial.print("Writing to file...");

    //cycle through the array and store it in the SD card
    myFile.write("Pressure Recordings(going up): ");
    for(int i=0; i< 15; i++){
      myFile.write(pressure[i]);
      }
    Serial.println('\n');

       //header for the height sensor recordings
   myFile.write("Height Recordings(going up): ");
    //cycle through the array and store it in the SD card
    for (int j = 0; j <15; j ++){
     myFile.write(heightA[j]);
    }
    Serial.println('\n');

    //header for the temperature sensor recordings
    myFile.write("Temperature Recordings(going up): ");
    Serial.println('\n');
    //cycle through the array and store it in the SD card
    for (int k = 0; k <15; k++){
     myFile.write(temperature[k]);
    Serial.println('\n');
   }

    // close the file:
    myFile.close();
    Serial.println("done.");
    }
   else {
    // if the file didn't open, print an error:
    Serial.println("error opening sensor_recordings.txt");
  }

     //as the rocket descends
while ( seconds > 5 ){

              double pascals = baro.getPressure();
              pressure[counter] = pascals;
              Serial.print(pascals/3377); Serial.println(" Inches (Hg)");

              myFile.write(pressure[counter]);

             double altm = baro.getAltitude();
              heightA[counter] = altm;
              Serial.print(altm); Serial.println(" meters");

             double tempC = baro.getTemperature();
              temperature[counter] = tempC;
              Serial.print(tempC); Serial.println(" *C");
              tempNum ++;

              secondsPerTick++; //increments seconds per tick
              if(secondsPerTick == 3){  //if its 3 reset "secondspertick" and increments "seconds"
                secondsPerTick = 0;
                seconds++;
              }
              counter++;

 }

myFile = SD.open("Sensor4.txt", FILE_WRITE);

   if(myFile) {
    Serial.print("Writing to file...");

    //cycle through the array and store it in the SD card
    myFile.write("Pressure Recordings(going down): ");
    for(int i=0; i< 15; i++){
      myFile.write(pressure[i]);
      }
    Serial.println('\n');

       //header for the height sensor recordings
   myFile.write("Height Recordings(going down): ");
    //cycle through the array and store it in the SD card
    for (int j = 0; j <15; j ++){
     myFile.write(heightA[j]);
    }
    Serial.println('\n');

    //header for the temperature sensor recordings
    myFile.write("Temperature Recordings(going down): ");
    Serial.println('\n');

    //cycle through the array and store it in the SD card
    for (int k = 0; k <15; k++){
     myFile.write(temperature[k]);
    Serial.println('\n');
   }

    // close the file:
    myFile.close();
    Serial.println("done.");
    }
   else {
    // if the file didn't open, print an error:
    Serial.println("error opening sensor_recordings.txt");
  }
 }

void loop() {

Here is what gets printed to the txt file:

€€€ƒ€ƒ‚ƒ€€„~ƒ‚€€€€ƒ€ƒ‚ƒ€€„~ƒ‚€ƒ‚‚‚„‡€„ƒ„……ƒ‚ƒ„Pressure Recordings: ƒ‚‚‚„‡€„ƒ„……ƒ‚ƒ„
  Height Recordings: 10010110010101111000Temperature
  Recordings: Å……ƒƒ…€€ƒ‡‚w
  Pressure Recordings: Å……ƒƒ…€€ƒ‡‚w
  Height Recordings: 000010100010111     Temperature Recordings:      Pressure Recordings: Å……ƒƒ…€€ƒ‡‚w     Height Recordings: 000010100010111     Temperature Recordings:      Pressure Recordings: Ã‡…„†…„…„ˆ†„„€†     Height Recordings: 000000000000000     Temperature Recordings:      Pressure Recordings: Ã‡…„†…„…„ˆ†„„€†     Height Recordings: 000000000000000     Temperature Recordings:      Pressure Recordings: Â†‰†‡…††‰…‰ˆˆ…ˆ Height Recordings: 000000000000000     Temperature Recordings:      Pressure Recordings: Â†‰†‡…††‰…‰ˆˆ…ˆ Height Recordings: 000000000000000     Temperature Recordings:      Pressure Recordings(going up): ÀŽ‘ŽŒŽŽHeight Recordings(going up): ///000/0/0/0///Temperature Recordings(going up): Pressure Recordings(going down): ÀŽ‘ŽŒŽŽHeight Recordings(going down): ///000/0/0/0///Temperature Recordings(going down): Pressure Recordings(going up): ½–™––•˜–••š™š—™Height Recordings(going up): ///////////////Temperature Recordings(going up): Pressure Recordings(going down): ½–™––•˜–••š™š—™Height Recordings(going down): ///////////////Temperature Recordings(going down):

I also don't know how I can get the data to be formatted to where it reads like:
Pressure(going up):----
Altitude(going up):---
Temperature(going up):---
Pressure(going down):----
Altitude(going down):---
Temperature(going down):---

If you want the data stored as text instead if binary, use myFile.print() instead of myFile.write().

You should convert double to String with this kind of code:
char[9] stringval;
dtostrf(doubleval, 8, 4, stringval);

where 8 is presicion and 4 is number of digits after point.
More info: http://forum.arduino.cc/index.php?topic=282250.0

How would I implement that into my code? Sorry I'm new to Arduino and all of this has been trial and error for the most part with lots of Googling


text:
How to combine 3.4ghz intel processor with arduino board
Im totally new to arduino but have some programming experience. I have an idea that i would like to realize but it requires way better hardware than what a standard arduino board offers. I would like to use my 3.4 ghz intel processor for example...
The question might seem very stupid to most people here but i actually did not find the answer anywhere (here, google, arduino website), but is it possible to combine the simplicity of arduino and the power of pc-level hardware without using a server? (The calculations should be made locally on the arduino).

How real time do you need things to be?
Arduino gives you very good control of timings because there is no operating system getting in the way switching between tasks in the background.
If you need hard real time then you need to work bare metal, mbed gives you a more processing power while still maintaining the ease of use and reliable tight timing. That will get you up to around 150 MHz with an FPU but still a long way from PC capabilities.
You can run bare metal code on any CPU but doing so without an easy to use set of libraries can have a very steep learning curve, I don't know of any faster systems that allow you to do this in an accessible way.
If you can live with a few ms of delay in the system then you can run something with an OS which opens up a lot more possibilities. The Pi is at the low end of the range in both price and performance. The odroid or beagleboard boards give you more power for more money but are still fairly good in terms of price. I'm not sure what exactly you want to do but four 2 GHz CPUs is enough to do quite a lot of number crunching if you can multi-thread the task.

It depends what you want to do.
An Arduino gives you are simple low cost board for interfacing to peripherals.  If you are interfacing to kit then you probably want to stick with a microprocessor because of its real time behaviour, its low cost and its simplicity.
If you then want to crunch numbers send the data back to a beast of a processor and crunch numbers, where you have features like floating point and clever stuff.
The two processors you talk about are both good at what they are aimed at, but not much use at the other.,
Looking at it another way, you are a farmer and have a tractor for ploughing the fields, a quad bike for chasing sheep, and a Porsche for nipping down the shops.  You could go shopping in the tractor same as you could try to plough the field with the Porsche, but you look a bit of a [fool].
You could look at Netduinos, ESP8226, ESP32, Pi's or PICs.
You can get a PC card that talks to an I2C bus and could control the microprocessors using that.

Of course you can combine it, but it depends what you need. If you say you need to do the calculations on the Arduino, and assuming the electronics will also be driven from the Arduino, I wonder what you want your 3.4 intel processor to do.
If you want to let the Arduino use the intel directly, that will be impossible or at least impractical. The number of pins used by the intel will be very high and the Arduino runs on 16 MHz so never can provide the intel with enough data to keep it busy.

Okay thanks, do you know if there any alternatives to arduino that would support heavier calculations then? Something like a pc-level motherboard but similar to arduino (so that you can easily combine different electronics, parts etc)

Within Arduino there is the Due which is like an arm processor and has more processor power but not close to a 3.4 intel either ... you could either go into the direction of raspberry pi, or maybe you should rethink your project. Like asking the question why you need a 3.4 GHz intel, why not do the calculations on a 'normal'  computer?

I am going to write a program that recognizes objects in a video in real time (probably at around 15 fps). Since it would be in real time the response should be as fast as possible, that is why id like to skip the streaming of data part. The goal is to make a robot that is independant of other devices so i cant have an usb connection either.

hmm actually, raspberry pi 3 has 1.2ghz that would probably suffice to be honest.

For video the Arduino will be too slow anyway. You need a lot of bandwidth for processing video. Probably the raspberry pi 3 is the way to go ... you could do the video processing on that, and leave the motor controls probably to the Arduino (if you need it when you have the raspberry).

Though the Raspberry Pi models are pretty anemic compared to regular PCs, they also do have a surprisingly decent GPU on them that may come in useful in applications such as image processing. And of course they have all the nice IO pins etc. like the Arduino. If you need PC-level power, you probably want to build your robot around a laptop.

authors: Дмитрий Беляков


text:
Analog reading via bluetooth
I am making a project in which I am trying to communicate the LDR values collected by one arduino(slave) to another arduino(master) via bluetooth. The readings of the LDR is displayed on the serial monitor.
The slave part of the arduino code :
 #include <SoftwareSerial.h>
  SoftwareSerial BTSerial(10, 11); // RX | TX
  #define ldrPin A0
  int ldrValue = 0;
  void setup() {
     pinMode(9, OUTPUT);  // this pin will pull the HC-05 pin 34 (key pin) HIGH to switch module to AT mode
     digitalWrite(9, HIGH);
     pinMode(ldrPin, INPUT);
     BTSerial.begin(9600);
     Serial.begin(9600);

   }
   void loop()
    {
     ldrValue = analogRead(ldrPin);
     BTSerial.println(ldrValue);
     Serial.println(ldrValue);
     delay(10);
    }

I tried getting the readings of LDR in serial monitor to check whether the readings are correct. The readings shown in Serial monitor were correct.
The code of master part of the project which receives the readings from slave :
#include <SoftwareSerial.h>
SoftwareSerial BTSerial(10, 11); // RX | TX
const byte numChars = 1024;
char receivedChars[numChars];   // an array to store the received data

boolean newData = false;

void setup() {
pinMode(9, OUTPUT);  // this pin will pull the HC-05 pin 34 (key pin) HIGH  to switch module to AT mode
digitalWrite(9, HIGH);
BTSerial.begin(9600);
Serial.begin(9600);
Serial.println("<Arduino is ready>");
}

void loop() {
   recvWithEndMarker();
   showNewData();
 }

void recvWithEndMarker() {
   static byte ndx = 0;
   char endMarker = '\n';
   char rc;

   while (BTSerial.available() > 0 && newData == false) {
     rc = BTSerial.read();

     if (rc != endMarker) {
        receivedChars[ndx] = rc;
        ndx++;
        if (ndx >= numChars) {
            ndx = numChars - 1;
        }
    }
    else {
        receivedChars[ndx] = '\0'; // terminate the string
        ndx = 0;
        newData = true;
      }
    }
  }

   void showNewData() {
      if (newData == true) {
       Serial.print("This just in ... ");
       Serial.println(receivedChars);
       delay(1000);
       newData = false;
    }
   }

But The serial monitor did not show the correct readings of LDR . Instead it showed something like this
<Arduino is ready>
 This just in ... 8
 This just in ... 3
 This just in ... 4
 This just in ... 3
 This just in ... 3
 This just in ... 3
 This just in ... 3
 This just in ... 4
 This just in ... 3
 This just in ... 4
 This just in ... 3
 This just in ... 3

I have referred this link for the Arduino serial communication:
Serial Input
Kindly help me out since it has been days since I have stuck up in this issue.
Thank you!

A byte is 8 bits, it can hold a maximum value of 255.  You can not store the number 1024 in a byte.  You might want to rethink the type on ndx.
If (ndx >= numChars) then why not set newData to true and print it out.  Something has gone wrong if it gets this far and you want to recover if you can.

Apart from those minor issues your code should work as you expect it to.  Do you have a printout of what the slave's serial output was?  (What you were expecting).  Could it be something to do with the differences between SoftwareSerial and Serial?
Edit:
I have just run a stubbed version of you code on a PC and it ran fine, so I'm going to point my finger at the SoftwareSerial link.  It could well be a misinterpretation of the interface it provides.

What was it? I hate not knowing and someone else may stumble on this thread and it saves them asking.


text:
Creating public instance of class in another class's initialization
I'm using several TM1637 displays to create timers, so I decided to make a Timer class. Every time I initialize an instance of the Timer class, I want it to create an instance of the TM1637Display class. So I started out with this, but the display object can't be accessed from within updateDisplay.
class Timer {
public:
    Timer(uint8_t CLK, uint8_t DIO) {
        TM1637Display display(CLK, DIO);
        ...
    }
    void updateDisplay() {
        ...
        display.setSegments(displayData);
    }
}

And if I do this I get the compile time error In constructor 'Timer::Timer(uint8_t, uint8_t)': src\main.cpp:16:37: error: no matching function for call to 'TM1637Display::TM1637Display()'
    TM1637Display display;
    Timer(uint8_t CLK, uint8_t DIO) {
        display(CLK, DIO);
        ...
    }

What should I try? Maybe make an empty pointer before the display instance is created with a public scope, assign the pointer to the display instance, then hand the updateDisplay function the pointer? That seems really convoluted.

As it's now in the first example, it's local variable in Timer constructor.
In the second one you have to use member initializer list in constructor as there is no default constructor in your display class.
class Timer {
public:
    Timer(uint8_t CLK, uint8_t DIO)
    : display(CLK, DIO) // constructor's initializer list
    {
        ...
    }
    void updateDisplay() {
        ...
        display.setSegments(displayData);
    }

    // member variable:
    TM1637Display display;
}

Thank you! I had never heard of initializer lists before.