text:
How to troubleshoot the Arduino Mini and Arduino usb2serial?
I am trying to get an Arduino Mini (R5, mega 328p) working.
Just connecting it to power has following effect: the on-board LED lights up. It's the power-on-led, I presume.
Since other Arduino devices often come with the blink-example pre-flashed I hooked up a LED to pin 13 - result: no blinking.
Curiously, connecting the LED to pin 12: blinking
Does the Mini come pre-flashed with a blink 'sketch' that blinks pin 12 instead of 13?
To test uploading I've connected it to an Arduino USB2Serial module. The module is labeled with 'made in Italy' and has printed 'USB2SERIAL LIGHT' on it where the LIGHT is overwritten with a blue marker.
I've connected it like described in the arduino mini guide.
In the IDE I've selected the board 'Arduino Mini' and the '328' CPU.
Unfortunately, uploading fails with:
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 1 of 10: not in sync: resp=0x00
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 2 of 10: not in sync: resp=0x00

The external reset is connected like in the guide. But I also tried to manually press the reset button (immediately before the upload, or long press and release after upload button is clicked). Still, the same error.
When the manual reset is pressed the pin-12-blinking stops for a while (perhaps the bootloader is then executed) but then starts again.
The Arduino2serial has 3 LEDs. The ON-LED lights up when connected to the USB. When hitting the upload button in the IDE, the RX-LED flashed shortly one time after a while. That's it.
Thus my question: How to I troubleshoot this? Can I test the arduino usb2serial on its own? What's up with the pin-12 blinking of the mini?
In case this matters, I am on Fedora Linux, uploading to other Arduino devices (Uno, Micro) works as expected.
update usb2serial: I just hooked up the Arduino usb2serial and connected the TX/RX pins via a jumper cable - a minicom session then results in text being displayed and the rapid flashing of the RX/TX LEDs. Disconnecting RX/TX again shows no display of any text inside minicom, and no flashing of the RX/TX LEDs.
I used following command line:
$ minicom -D /dev/ttyACM0 -b 115200

Thus, the usb2serial module seems to work.
update: I've checked all the jumper cables and there was a faulty one. With that replaced flashing works. After hitting the reset-button. The 'ext reset' pin is connected but the remote-reset does seem to work. Anyways, hitting the reset-button is easy-enough, for now.
final update: The root cause for remote-reset (a.k.a. auto reset) that the capacity of the used capacitor was too small. After exchanging it with a 100 nF one (as specified in the guide) the remote-reset works as expected. That means just hitting the upload button in the IDE automatically resets the device and the sketch is uploaded.

Did you try uploading just after reset?

@IgnacioVazquez-Abrams, yes, I did - ultimately, the root cause was a cable (cf. update) - now, the point when I hit the reset-button is relatively non-time-critical.

The remote reset is done through the DTR line, iirc, so if that is not wired, reset won't work. You can refer to the schematics for UNOR3, to reproduce the wiring.

@Igor, the 'ext reset' pin of the USB2Serial 'mirrors the DTR line of the virtual serial device on the computer' - and was connected to the reset pin of the Mini. Problem was that out of a mistake I used a too small capacitor (< 100 nF). With 100 nF the software-reset works as expected.

As always, it makes sense to check the parts in isolation, if possible.
Host system (Linux):

Tail the system log for errors
Check that ModemManager does not occupies the /dev/ttyACM0 device

USB2Serial:

Connect it via USB to the host without anything else connected -> the ON-LED should be on, the RX/TX LEDs should be off, the system log should display some udev progress messages (including vendor ids), the system should have a new serial device, e.g. /dev/ttyACM0
Open the serial port with a terminal (e.g. via minicom -D /dev/ttyACM0 [-b baudrate], disable local echo and type something -> nothing should be displayed
Connect the RX/TX pins to each other with a jumper cable -> typing in the terminal session should now result in rapid flashing of the TX/RX LEDs and the echoing of the text

Arduino Mini:

Connect just the minimum, e.g. just power from a 9V battery/5V power supply and the reset pin to +5 (with a 10KOhm resistor in series) -> the power-on led should turn on
The chance is high that the device comes with a pre-flashed blink examples that either uses pin 12 or 13 -> connect external LEDs to pin 12 and 13 (in series with 220 Ohm resistors) -> one LED blinks after power on
Hit the reset button on the mini -> any LED blinking should stop for a while and then continue

Arduino Mini with USB2Serial:

Make sure that both RX/TX pairs are crosslinked (like a nullmodem cable), i.e. RX <-> TX and TX <-> RX.
Follow the mini guide on arduino.cc or arduino.org it includes a picture of the cabling
Verify that the capacitor connected between the USB2Serial 'ext reset' pin and the Mini reset pin has a capacity of 100 nF, otherwise, the auto-reset might not work
In case the automatic reset does not work, press the on-board-reset-button just before the upload
In case the error persists, check for dodgy cables with a multi-meter

IDE:

Make sure that it works with 'easier' stuff, e.g. flashing to a Uno (the Uno is easier because the USB-2-Serial part is integrated)
Enable verbose logging during upload (in the preferences)
Update the IDE in case it is very old


text:
Did I break my new Arduino Leonardo Eth by restarting it?
I just bought a new Arduino Leonardo Eth, and, it was working perfectly.
I probably uploaded about 30 different sketches, and it did everything as expected.
The basic sketch was using the fade demo on pin 9 to ground with a LED attached.
I was then curious on how long the unit takes to restart, so, I unplugged the USB and put it back in.
When it started back up, the LED was on solid. I then restarted it again, and I honestly can't remember the state of it.
When I plug it in, it gets detected in the Arduino application and I see the port, but, after about 20 seconds, I get a popup on Windows saying about a malfunctioning USB device.
Pressing reset on the Arduino or unplugging/plugging it back does the same - I get about 20 seconds, and then it "goes bad".
Even if I am real quick in the IDE, or press restart after compiling/before upload, it just hangs.
I'm really annoyed with myself if I did break it, but, I'm not really sure what else I could have done differently... after all, there isn't an off switch.
Does anyone know what I have done, and, is there anyway to fix it?

Can you communicate with it via ISP?

@IgnacioVazquez-Abrams I just read another post about bricked Arduinos, and I am going to give that a shot... Honestly, this is my first official arduino device - I have purchased a few low end Arduino Micro compatible units, but, I am not sure that they have the ISP function... This is my first experience with arduino/electronics, and I do feel a little out of my depth! ... I was hoping there is a certain combination of restart button pushes to factory reset or similar! I'm traveling at the moment, but will try again normally and look at ISP when I get home

You should be able to use my board detector sketch on one of your other Arduinos to check out the problem board.
See also Have I bricked my Arduino Uno? Problems with uploading to board
Also my bootloader uploader sketch will reflash bootloaders on quite a few devices. I'm assuming that the "Arduino Leonardo Eth" has the same bootloader as the Leonardo.
Hmmm - I see that the "Arduino Leonardo Eth" is from Arduino.org, not Arduino.cc. The bootloader is probably slightly different. I'm really not an expert on what those boards use.

Before worrying too much, try the approach of holding down Reset and then uploading a sketch, letting go of Reset as the sketch starts to actually upload.

Comment by William Hilsum

I didn't realise there was a difference between .org and .cc, and, I guess by using the leonardo template from .cc, I broke "something". The moment I downloaded the IDE from .org, & uploaded with the eth template , it worked flawlessly. I guess there are some changes between leonardo and leonardo eth. I wanted an arduino with ethernet, so I didn't need a separate shield. No idea if I picked the right "side" after reading all the crap with cc vs org!

That is very annoying that the split of the Arduino camps now produces a support nightmare for people who just want to use their virtually identical products, but have to go through this.
Thanks for the update.

Sorry to sound dumb, what's the difference between Arduino.org and Arduino.cc? The Leonardo Eth was from a trusted supplier (Farnell) and I didn't know there was a difference here! I thought it was just one was a community and one was the company... Anyway, as for the "cheap" Arduinos, I just bought them from eBay and have never actually used them, ... Being honest, I'm not even really sure how to right now/there is only headers/no pins, so, I have to look in to that when I have more time! I'll give the reset thing a try though. Thank you....

It's worth saying, I have a theory... I read from the Arduino troubleshooting page that it doesn't auto start if it gets a signal - I am wondering if the first time I connected, it was simply "empty" and worked, the second time, my machine/vmware/something intercepted the call and tried to do something causing it to pause. This doesn't explain why it gets detected and disconnected straight after uploading though.

The Leonardo presents as a USB device initially so you can upload a sketch to it. After a certain time (mine took around 9 seconds) it exits the bootloader, and that USB device "goes away". Then it runs your sketch. If your sketch does not open Serial, a keyboard or mouse, then it is no longer a USB device. So this is expected behaviour.

what's the difference between Arduino.org and Arduino.cc - various of the original Arduino founders have had a dispute about who owns the "Arduino" name. See, for example: Arduino Wars: Group Splits, Competing Products Revealed?

Thanks so much, and found a really good answer on here shortly after writing that... I used the Arduino download from cc, I used Leonardo as the base... I just downloaded it from .org and now have the Leonardo eth template - I am guessing that as much as it worked, it may not have done a lot of good! I swear the .cc download only had ~2 drivers, the .org one needed around 10 - I hope it hasn't screwed anything up on my pc...

Please let us know how this turns out, so that the question may eventually have an answer that will help other people. :)

Unfortunately, I can't find a bloody USB cable when I need one :( Guess I'm going to have to wait to do this at work! I certainly will share back!

This isn't exactly the correct answer, but, you pushed me on to the correct thing, so, if you can modify/add the following, it may help others... I didn't realise there was a difference between .org and .cc, and, I guess by using the leonardo template from .cc, I broke "something". The moment I downloaded the IDE from .org, & uploaded with the eth template , it worked flawlessly. I guess there are some changes between leonardo and leonardo eth. I wanted an arduino with ethernet, so I didn't need a separate shield. No idea if I picked the right "side" after reading all the crap with cc vs org!

I added your remarks for the benefit of future readers.

Difference between Arduino.cc and Arduino.org

source: Stack Exchange

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

sort: votes


text:
Lost Source Sketch
I wrote an interface to a radio about 1-year ago. I have since rebuilt that machine. Is there any way to retrieve the code. Now I do not expect it to be sources code.
I know the radio code still works as I tried it the other day. Part of the problem is that I am using about 30 wires all on the rear end of the card
and  have to figure out which pins that they go to in my radio. My interface has two DB25 connectors. And the decoder 2 of 5 negative going signals.

Asusming the lock bits on the MCU haven't been set, you can use avrdude to download the contents of flash and EEPROM to your system. From there you can use avr-objdump to disassemble the .hex file and try to figure out how it works. I recommend looking at the disassembly of a .elf file from a current project as well as having both the avr-gcc and avr-libc documentation as well as the ATmegaXXX0 datasheet close at hand at all times.

Once you have the .hex file off the chip you can do this to diassemble it: avr-objdump -j .sec1 -d -m avr3 myfile.hex

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


text:
Arduino for Wi-Fi hotspot?
I want to create a Wi-Fi hotspot and redirect all connections to a custom login page.
I would like to know if the Arduino Yún is a good choice in this case?

Better use a regular router and flash DD-WRT or OpenWRT to it (check the supported router list on their websites). Next use something like NoCatSplash, to create a captive portal with login.
Arduino's just are not fast enough for this. Arduino Yuns are typically more expensive.

Did you know that operating system the Yun runs is OpenWRT?  It's no slower or faster than most home routers since it uses the very same chip that many of them do.

Thank's ! I have also read Raspberry PI could be a good choice ?

Mikrotik has some really nice routers / switches that will be able to do what you want for a very reasonable price and fairly good performances.

Raspberry + SD card + power adapter + usb-wifi module. So more expensive than a typical router. Also since both wifi and ethernet go over usb on the Pi, the maximum speed is reduced.

Here is a project where I make a Yun into a hotspot and even have it act like a captive portal so users can control things though the Yun...
http://wp.josh.com/2014/05/01/a-platform-for-casual-encounters-with-interactive-technology/
Even though it does work, I can not recommend using the Yun for something like this unless you have no other choice. It is just not a good platform and you end up wasting huge amounts of time on unnecessary problems.
Much better to use something like a BeagleBone or Raspberry PI to handle to Wifi stuff. You can then connect these to a normal Arduino if necessary to deal with your hardware.

So how to have a hotspot (like mikrotik)
and also control hardware using raspberry pi? What is the server I can use? @bigjosh


text:
Uploading to atmega328 over serial with arduino bootloader running at 2MHz
I want to run an atmega328 on a breadboard at 2MHz and upload to it via the serial pins (pins 2 and 3). So I am setting the clock divide by 8 fuse bit to enable this, meaning the atmega runs at 2MHz eith the 16MHz crystal. But I can't upload, probably because the bootloader is not expecting the clock to be running at 2MHz. The baud rates are probably mismatched by 8 times, the IDE is trying to upload at 57600 but since the bootloader code is not aware its being clocked at 2MHz, its probably running 8 times too slow. I've messed around a bit with the arduino conf files changing baud rates but had no joy. I was wondering if anyone knows how to do this off the top of their head.
Thanks, Pete

Edit the programmers.txt file somewhere inside the arduino folder. Duplicate the avrisp section. Replace avrisp. with avrispslow. or something, and change the .name=AVR ISP with .name=AVR ISP Slow. Add avrispslow.speed=7200 and avrispslow.program.speed=7200. Restart the IDE. You should now have a new item in the Boards=>Programmers menu.

Thanks, thats basically what I was looking for but in the end it didn't work. I believe the reason is that my PC do that baud rate without certain extra measures which are not practical (ie using new style termios2 struct for serial access). So I ended up using Ignacios method.

Unprogram the CKDIV8 fuse and add the following to the sketch instead, near the beginning:
#include <avr/power.h>

void setprescaler(void) __attribute__ ((naked)) \
  __attribute__ ((section(".init1")));

void setprescaler(void)
{
  clock_prescale_set(clock_div_8);
}

This will do essentially the same thing as the fuse, but won't interfere with the bootloader.

Is there not a risk to running the atmega out of its SOA even if only for a few cycles? I guess I could use that technique while working on the project and change to fuse divider for 'production' but I was wondering if theres either a setting in the IDE to modify the serial speed during upload, or a easy way to set the baud in the bootloader, even if it means recompiling it.

What voltage are you running it at, 1.8V?

If you are running at 1.8V, I don't see how you can be using a serial upload, because the voltages will be too high. If you are running at 5V you can do what Ignacio Vazquez-Abrams suggested.

No I'm initially trying at 5v just to get it working before dropping to 3.6, the project has a SD card (currently unplugged) which determines the voltage. So I also have to work on it at 3.6 to avoid damage to the SD. I use the usbasp and today, I bricked 2 atmega328s. I only have one left until my next order turns up. What's happening is if I forget to switch the usbasp back to 5v before uploading, the fuses get set to 0, setting the reset pin to disable, bricking the chip. PITA.

Don't know why this happens but it does (I get an error at the end of upload about fuse settings not matching, despite code upload apparently succeeding). Since I need 3.3v for SD I have to clock lower than 12MHz but only have 16MHz crystals hence divider bit. Plan is to use serial instead of USBASP to avoid fuse bits being touched during upload. All works fine if I disable clock divider, so problem is related to speed.

The maximum characterized speed for 3.3V is 13.3MHz, but many people report success at 16MHz with AVR devices, myself included (I have a ATmega1284P connected to a 3.3V display and a 16MHz crystal, no prescaler). Although I did make myself a passive level shifter so that I can keep my programmer at 5V.

Thanks, I ended up doing this for reasons explained above. Ill set the fuse and remove the divider code when the code is done.

There's no need to remove the prescale code; once the fuse is set it will become a no-op.


text:
Going from arduino & sketch to production
I've got a little proof of concept thing going here with an arduino & Ethernet shield. The basic idea is for it to ping out much like a heartbeat monitor every so often so I can see if my house still has internet connectivity.
The arduino works nicely and does exactly what I want. I've ordered a board to be made with just the basic components needed and now want to put the code on to it. They gave me an option to load the code (Dragon AVR) during checkout and I'd love to try that out. So, the question is - how on earth do I package up code for something like that? I've seen a number of people ask the same thing for large manufacturing scales / similar setup where they don't fancy using the arduino & IDE as a programmer.
I've asked around on IRC and various other places but nobody seems to be able to give me specific and clear advice on whether it's possible and how to go about doing it.

Don't forget to also provide the fuse settings. Fuses on the Arduino are different from those that are set when the chips leave the factory.

@Gerben how would I be able to define that?

Not sure. It's just 3 bytes, so you can just send them the three values I suppose.

"Intel Hex" is pretty much an industry standard and I'm quite certain the .hex files produced by the GNU AVR tools is Intel Hex format. Your vendor is almost certainly prepared to load your sketch from the .hex file.

Have to agree. But it can't hurt to ask if they can support the ELF file as well.

Thank you, thank you, thank you for not replying with "easy" and that's it! If you don't mind me asking, the hex file that is produced when I load my sketch onto the arduino should be "build ready"? I.e just ship them that?

Or how do I generate the ELF? Sorry guys!

Both files are products of the compile/load process. If you're using the Arduino IDE, I can't help you much with the locations of those files (though I'm sure someone here knows, for whichever OS you use). I know the Eclipse IDE puts those files in a folder named for the board or configuration, within each particular project.

Whenever I program my chips using ICSP I always use the exact same .hex file that is output by the IDE. I hope you have an ICSP header on your board in case you ever need to change the code.

That sounds promising. Literally just lift the hex file and away we go? Is it that simple?

Check with your vendor to be sure, but probably, yes.


text:
What does serial data look like on an oscilloscope?
How I can find the data field on oscilloscope at 300 baud or at 9600 baud?
Could someone show me picture on oscilloscope plase.
This is the picture
at 9600 Baud

At google images, type scope rs232 into the search box.

I had these images lying around so here is an example of "Fab" being sent at 9600 baud:

And now a single byte (the letter "F"):

A - no data (Tx is high)
B - The "start bit". The line is taken low to tell the receiver that a character (byte) is commencing to be sent. The receiver waits for one and a half clock times before sampling the line.
C - First character arrives (the letter "F" or 0x46 or 0b01000110). There is no clock bit as such, the incoming data is simply sampled at the baud (transmission) rate. In contrast to SPI communication the data arrives least-significant bit first (in case you are not sending 8 bits per byte). Thus we see 01100010 (rather than 01000110).
D - The stop bit. This is always high, to ensure that we can distinguish between the end of this byte, and the start of the next one. Since the start bit is a zero, and the stop bit is a one, there is always a clear transition from one byte to the next.
E - The start bit for the next character.

The time for one bit is shown on the logic analyzer as 0.1041667 ms (that is, 0.0001041667 seconds). This agrees with the inverse of the baud rate:
1 / 9600 bits per second = 0.0001041667 seconds per bit

Looking at your photo, my guess is you have inverted logic here. That is, RS232 levels (where 5V is a 0-bit and 0V is a 1-bit). Thus (and this is a guess because all the bytes are close together):

I marked the start and stop bits, and put a dot for each bit inbetween.

Also see What is Serial.begin(9600)?

Note that there are quite a few different setting on serial, besides just the speed. Parity bits, Stop bits. Data size.


text:
Writing data from multiple sensors in burst mode to an Arduino Due
I need help developing a simple sketch that can read data simultaneously from 3 analog accelerometers and send it in 'burst mode' to be stored on an SD card, to reduce the effect of latency.
I used this library to get my accelerometers to work properly, but I'm just having difficulty coming up with a sketch in the code to getting all the acceleration data out in bursts.
Your help will be much appreciated.
What I meant by 'burst mode' is that all acceleration data from all three sensors connected to the Arduino should be saved at once to the file on the SD card (a temporary measure, as I'll have to send this data via Bluetooth to a base station as I build the system up to be able to receive more data from multiple Arduinos).
Although there would be a delay of about 1/10th of a second between each reading from the three sensors, the idea behind it is to be able to read and write off the data in this said simultaneous burst mode at a high sample rate (this will be adjusted with an oscilloscope at a later stage) to prevent data from being lost or chunked up.
Here is a link to the datasheet as requested.

We really need more information here - what does burst mode mean? Could you add a link to the accelerometer datasheet? Please do this by editing the original answer, not by adding a comment as this makes the question hard to read.

I'm not sure what the difficulty here is. You read some sensors, gather the data, and then write a line of text to a file, right?

Yes that's the basic idea. But i found out that I started to loose data as I added additional MMA7361 sensors to the sketch, so the advice I got was to edit my sketch in order for me to send of each set of data in 'bursts' before the current data is read thereby emptying the memory of any data to avoid errors resulting from data accumulation. I used the delay feature to ensure that all the data are read and sent before a new set is read again, but increasing the sampling rate of the board results in the present state of the sketch, large data chunks lost over a period

What you need to do instead is to declare an array buffer of the data type you need to send, and send it through Serial. The array buffer could be of any length of your choosing, then you reiterate through on a for loop till all the contents of the buffer are read out which is essentially the burst mode you require.


text:
What happens when code is uploaded using the bootloader?
When I upload a new sketch to my Arduino Uno using the Optiboot bootloader, what really happens?

What is sent to the Arduino?
How does it respond?
What does "not in sync mean"?
What is "in sync" anyway?

Note: This is intended as a "reference question".

very interesting post! Just a more question. Which software are you using to trace the serial communication (images) ?

It is the output of a Logic Analyzer, such as Saleae Logic 8. https://www.saleae.com/ Very nice little analyzer. Used to be 24 MHz sample rate for ~$125, 150. Current capture speeds are 100 and 500 MHz.

SPI, I2C & more >Most digital communication uses a particular protocol that specifies how information is transferred. The Logic software has protocol analyzers that can automatically decode SPI, I2C, serial, 1-Wire, CAN, UNI/O, I2S/PCM, MP Mode, Manchester, Modbus, DMX-512, Parallel, JTAG, LIN, Atmel SWI, MDIO, SWD, LCD HD44780, BiSS C, HDLC, HDMI CEC, PS/2, USB 1.1, Midi – or create your own

When you reset a Uno running the Optiboot loader, the bootloader first flashes pin 13 three times.

Top line (gray) is sent to the Arduino, middle line (orange) is sent from the Arduino.
While that is happening, the program avrdude running on your computer is sending a query to the device:
STK_GET_SYNC / CRC_EOP  (0x30/0x20)

The Arduino doesn't notice the first "get sync" because it is busy flashing pin 13. Once it is done it notices the "get sync" (it would be buffered by the serial hardware) and replies:
STK_INSYNC / STK_OK (0x14/0x10)

It looks like avrdude got a bit impatient, and timed out, because it tries again with the "get sync" query. This time Optiboot responds immediately.

The rest of the uploading is described in the next image. Example produced uploading the stock "Blink" program.

(Click on the image above for a larger version)

The steps are:

Query: Get Sync? Reply: In Sync.
Query: Get parameter? (major version) Reply: version 4.
Query: Get parameter? (minor version) Reply: version 4.
Set device parameters. The following device parameters are sent to the chip:
0x42  // STK_SET_DEVICE
0x86  // device code
0x00  // revision
0x00  // progtype: “0” – Both Parallel/High-voltage and Serial mode
0x01  // parmode: “1” – Full parallel interface
0x01  // polling: “1” – Polling may be used
0x01  // selftimed: “1” – Self timed
0x01  // lockbytes: Number of Lock bytes.
0x03  // fusebytes: Number of Fuse bytes
0xFF  // flashpollval1
0xFF  // flashpollval2
0xFF  // eeprompollval1
0xFF  // eeprompollval2
0x00  // pagesizehigh
0x80  // pagesizelow
0x04  // eepromsizehigh
0x00  // eepromsizelow
0x00  // flashsize4
0x00  // flashsize3
0x80  // flashsize2
0x00  // flashsize1
0x20  // Sync_CRC_EOP

Optiboot ignores all those and replies with In Sync/OK. :)
Set extended device parameters:
0x45  // STK_SET_DEVICE_EXT
0x05  // commandsize: how many bytes follow
0x04  // eeprompagesize: EEPROM page size in bytes.
0xD7  // signalpagel:
0xC2  // signalbs2:
0x00  // ResetDisable: Defines whether a part has RSTDSBL Fuse
0x20  // Sync_CRC_EOP

Optiboot ignores all those as well and replies with In Sync/OK.
Enter program mode. Reply: In Sync/OK.
Read signature. Optiboot replies with 0x1E 0x95 0x0F without actually reading the signature.
Write fuses (four times). Optiboot does not write the fuse but just replies In Sync/OK.
Load address (initially 0x0000). The address is in words (ie. a word is two bytes). This sets the address for where the next page of data will be written.
Program page (up to 128 bytes are sent). Optiboot replies "In Sync" immediately. Then there is a pause of about 4 ms while it actually programs the page. Then it replies "OK".
Load address (now 0x0040). This is address 64 in decimal, ie. 128 bytes from the start of program memory.
Another page is written. This sequence continues until all the pages are written.
Load address (back to 0x0000). This is for verifying the write.
Read page (up to 128 bytes are read). This is for verifying. Note that even if the verify fails, the bad data has already been written to the chip.
Leave programming mode.

What does "not in sync" mean?
As you can see from the above, every step through the programming sequence the Arduino is expected to reply with "In Sync" (0x14), possibly followed by some data, followed by "OK" (0x10).
If it is "not in sync" that means that avrdude did not get the "in sync" response. Possible reasons could be:

Wrong baud rate used
Wrong serial port selected in IDE
Wrong board type selected in IDE
No bootloader installed
Wrong bootloader installed
Board not configured to use the bootloader (in the fuses)
Some device plugged into pins D0 and D1 on the Arduino, interfering with serial commications
The USB interface chip (ATmega16U2) not working properly
Wrong clock for the board
Wrong fuse settings on the Atmega328P (eg. "divide clock by 8")
Board/chip damaged
Faulty USB cable (some USB cables provide power only, and are not for data, eg. cheap cables for USB fans)

What is "in sync"?
As mentioned above, the response "In sync" means that the Arduino (bootloader) is synchronised with the uploading program.

What protocol is being used?
The protocol is the STK500 protocol as documented by Atmel. See the references below.

References

Optiboot source code - GitHub
AVR061: STK500 Communication Protocol
AVR068: STK500 Communication Protocol version 2
Have I bricked my Arduino Uno? Problems with uploading to board
AVR Downloader/UploaDEr - avrdude

Note: STK500 Version 2 is not used in Optiboot, but it is included for information in case you are using boards like the Mega2560.

STK500 constants
/* STK500 constants list, from AVRDUDE */
#define STK_OK              0x10
#define STK_FAILED          0x11  // Not used
#define STK_UNKNOWN         0x12  // Not used
#define STK_NODEVICE        0x13  // Not used
#define STK_INSYNC          0x14  // ' '
#define STK_NOSYNC          0x15  // Not used
#define ADC_CHANNEL_ERROR   0x16  // Not used
#define ADC_MEASURE_OK      0x17  // Not used
#define PWM_CHANNEL_ERROR   0x18  // Not used
#define PWM_ADJUST_OK       0x19  // Not used
#define CRC_EOP             0x20  // 'SPACE'
#define STK_GET_SYNC        0x30  // '0'
#define STK_GET_SIGN_ON     0x31  // '1'
#define STK_SET_PARAMETER   0x40  // '@'
#define STK_GET_PARAMETER   0x41  // 'A'
#define STK_SET_DEVICE      0x42  // 'B'
#define STK_SET_DEVICE_EXT  0x45  // 'E'
#define STK_ENTER_PROGMODE  0x50  // 'P'
#define STK_LEAVE_PROGMODE  0x51  // 'Q'
#define STK_CHIP_ERASE      0x52  // 'R'
#define STK_CHECK_AUTOINC   0x53  // 'S'
#define STK_LOAD_ADDRESS    0x55  // 'U'
#define STK_UNIVERSAL       0x56  // 'V'
#define STK_PROG_FLASH      0x60  // '`'
#define STK_PROG_DATA       0x61  // 'a'
#define STK_PROG_FUSE       0x62  // 'b'
#define STK_PROG_LOCK       0x63  // 'c'
#define STK_PROG_PAGE       0x64  // 'd'
#define STK_PROG_FUSE_EXT   0x65  // 'e'
#define STK_READ_FLASH      0x70  // 'p'
#define STK_READ_DATA       0x71  // 'q'
#define STK_READ_FUSE       0x72  // 'r'
#define STK_READ_LOCK       0x73  // 's'
#define STK_READ_PAGE       0x74  // 't'
#define STK_READ_SIGN       0x75  // 'u'
#define STK_READ_OSCCAL     0x76  // 'v'
#define STK_READ_FUSE_EXT   0x77  // 'w'
#define STK_READ_OSCCAL_EXT 0x78  // 'x'

AVR061: STK500 Communication Protocol

Good point! I added a few references to the answer. Thanks.

Note that the verification process described here specifically uses a page read, which means that any bootloader supporting avrdude's default verify behavior is a bootloader which supports reading out the flash contents.

This extensive and descriptive program instruction and the analysis of Optiboot/STK500 is mind-blowingly awesome. Thank you, the great Nick Gammon!


text:
How do I send an arduino PIN state to a local PC using the ethernet connection?
As a PIN goes high I need to trigger an event that will send the IP or MAC of the arduino and the PIN state over the wired Ethernet to a local computer. I am using an Ethernet shield to send and receive from the arduino but I am stumped on how to send and process the information at the PC. I will have 42 Arduinos on the network all set to send PIN information over the wired Ethernet. Sounds simple but after a days research I am now looking at other solutions.  I currently have the faithful Uno with the network shield as my prototype. For the final install I can purchase any of the arduino range like the Yun,Duo etc. if this would help. Any direction would be welcomed.

Both of the comprehensive answers by Majenko and Damiano Verzulli are good, but I would be asking if you want to push or pull the information from the 42 Arduinos. To  push it you want to make them HTTP clients and have them contact a central server when the pin changes. To pull the information they need to be HTTP servers which a central client polls from time to time. It might be easier for the Arduinos to establish a telnet connection and send (push) information that way.

The simplest method is to set up a web server on your PC.  You haven't mentioned what OS you run (which is kind of critical), so looking into WAMP or LAMP ("Windows/Apache/MySQL/PHP", or "Linux/Apache/MySQL/PHP") is probably your best option.
Once you have a working web server you can pretty much use verbatim the Ethernet examples for connecting to a remote website ("Web Client").  That website would be your local PC address, and you send whatever parameters you want.
You then write a small PHP script (or whatever language you program your chosen web server in) to accept that web request and process it accordingly.
In general you never need to explicitly send the IP address since it is encapsulated as part of the actual socket connection information and is generally made available through various means to your web page (see $_SERVER in PHP for example).
If you want to get more "low level" and lighter weight then you would most likely be looking at writing a UDP server on your computer which receives UDP requests from the Arduinos and processes them as needed.  The content of a UDP request is entirely up to you, but programming a server for dealing with it is beyond the scope of an answer here - suffice it to say there are plenty of resources online available for all the major operating systems and programming languages on how to write UDP servers.

In my opinion, a perfect solution for the "As a PIN goes high I need to trigger an event" problem is brought by interrupts. In the official documentation I read: "...Arduino has two different kinds of interrupts: external, and pin change..." and the latter seems very suited for your needs. So my idea (but, please, be aware that I'm not at all an Arduino developer... yet) is to simply develop an "interrupt-handler routine", and properly attach such a routine to your PINs. There are plenty of details to analyze (as well as plenty of documentation about Arduino interrupt handling) but... the idea should be clear.
Please, while developing such a routine DON'T be tempted to push all of your networking code inside the routine itself: for reasons deeply and clearly explained by @NickGammon, interrupt handlers should be executed as fast as possible. Here follow an important part of Nick's article:

[...]
Hints for writing ISRs
In brief, keep them short! While an ISR is executing other interrupts cannot be processed. So you could easily miss button presses, or incoming serial communications, if you try to do too much. In particular, you should not try to do debugging "prints" inside an ISR. The time taken to do those is likely to cause more problems than they solve.
A reasonable thing to do is set a single-byte flag, and then test that flag in the main loop function. Or, store an incoming byte from a serial port into a buffer. The inbuilt timer interrupts keep track of elapsed time by firing every time the internal timer overflows, and thus you can work out elapsed time by knowing how many times the timer overflowed.
[...]

As for the "...will send the IP or MAC of the arduino and the PIN state over the wired Ethernet to a local computer...", @Majenko already answered that "source IP" and "source MAC" (of your Arduino) are not needed to be sent explicitely by your application, as if you're using an Ethernet shield (...and, on top of it, the IP protocol stack) it will be the shield itself in dealing with the "encapsulation" process, by which your data (the data "sent" by your own code) will be encapsulated in a proper Ethernet frame (that will include the source MAC) and a containing IPv4 packet (that will include the "source IP").

As for the "...send [the] state over the wired Ethernet to a local computer..." you're missing some very important details, like which operating system your local computer will be running and, more important, which programming language are you using to write your "server-application code".
The LAMP/WAMP approach proposed by @Majenko is relatively easy to implement, as the WebServer (Apache) will bring you a ready-made approach to handle network requests: afterall, you need a "server" application (an application "listening" to a socket, waiting for incoming messages/requests coming from network clients) and a web-server like Apache is exactly such an application.
Anyway, should you need something more specifically suited for your needs, nothing prevent you to write your own "server". There are plenty of libraries for plenty of programming-languages.
As I'm confident with PERL, I suggest you checking one of the many tutorial describing PERL client-server programming. Please note that PERL is a cross-platform language, supported also on Windows systems.
A final note: While implementing your "server-code", please check/consider if you need a "blocking server" (one who can handle only one single request at a time) or a "non-blocking server" (one who can handle multiple requests, coming from multiple arduinos, at the same time).


text:
get current time in nanoseconds
On Arduino due, Is this possible to get the current time in nano seconds?
At 84Mhz, I guess it will always be a multiple of ~12ns.
And a perfect solution would read a register/variable rather than call a function. Because I want to avoid the cost of calling a function which is in order of microseconds.
what about counting clocks since start of execution. is this possible?

Yes, it should be.  At least according to the Cortex M3 Technical Reference Manual that I think I downloaded from ARM.  (DDI0337E_cortex_m3_r1p1_trm.pdf)
In section 11.5 of said manual, there is a register called DWT_CYCCNT (Data Watchpoint and Trace Cycle Count Register) which is incremented once per clock cycle when the appropriate flag of the DTW_CTRL (DWT Control) register is set.
This flag is unset on reset of the CPU so it needs to be set manually (unless it is done by the Arduino IDE, but checking the header files of the IDE, it doesn't look like it as unlike many other CPU registers, there is no Arduino REG_ define for these registers).
This untested code should be usable as the basis for your own code.  I suggest you add some serial initialisation in there and dump the value of currentCycles to the serial log to test it.  I am away from my hardware at the moment so can only test that it compiles.
#define REG_DWT_CTRL (*(unsigned int*)0xE0001000U)      /* Data Watchpoint and Trace Control Register */
#define REG_DWT_CYCCNT (*(unsigned int*)0xE0001004U)    /* Data Watchpoint and Trace Cycle Count Register */

#define CYCCNTENA ( 1 << 0 )                            /* DWT CTRL Cycle Count Enable Bit */

void setup()
{
    REG_DWT_CTRL |= CYCCNTENA;
}

void loop()
{
    unsigned int currentCycles = REG_DWT_CYCCNT;
}

Edit:
Note that the counter is a 32 bit register, so at 84 MHz it will reset every 51.13 seconds.  It is a read only register so writing to it will have no effect (you cannot manually reset it that way).

You probably mean (*(volatile unsigned int*)...).


text:
Distance sensor - Not working on fabric surface
I am using ultrasonic HC-SO04, not giving reading on fabric. I lost many hours on testing my obstacle avoidance robot car in front of my sofa, every time it hits hard but works fine on other hard surfaces. Is there any other distance sensor which can detect soft objects like fabric from long or short distance?
Also looking any other accurate long distance cheap sensor which can work easily with Arduino. Please let me know.  Thanks

Ultrasonic uses sound, and fabric absorbs sound. IR distance sensors may be an alternative. Unless the sofa is also black :-) (not necessarily true, as black might still reflect IR)

There are three types of commercially viable sensors for small scale projects:

Ultrasonic sensors(HC-SO04 and similar): These sensors use ultrasound much like a submarine uses its sonar to locate things by sending out a sound wave(trigger pin) and then measuring the time it takes for the sound wave to bounce back by reading the echo.There are two problems with this sensor. It needs a pretty solid object to bounce sound of thus walls are good but cloth absorbs the sound wave and the echo never bounces back. The second is you can encounter ghost echos when the sound wave strikes a corner and creates a echo for an object that is not really there. These sensors typically have a range of around 250cm to 600cm however some sensors can sense up to 7 meters away. Thus while it has good range it can not reliably detect all things and you might have false positives on it as well.
IR(Infrared) Sensors: These work like the ultrasonic ones but with light instead of sound. The sensor sends out a pulse/beam of IR light and measures the time it takes to reflect the light pulse/beam. This sensor is much faster than the ultrasonic ones but they have a much smaller range than ultrasonic sensors with a normal range of about 1.5 meters. While they work on most obstacles some might be missed due to the ability of some materials to absorb the IR light pulse thus there is no echo to measure.
LIDAR(Laser Range Sensors): There are various models of these but the principle is the same as the IR sensor. These can have massive range but they also come in at a massive prices. You can find cheaper ones around I saw a model for $80 that has a 40 meter range.

Thanks @Namphibian for a detailed description, can you also mention when and where you found that LIDAR for $80? any link?

Sparkfun has the LIDAR-Lite v2 for ~$120, which sounds similar to this.  The previous version was about $80 but has been upgraded and is now more expensive. https://www.sparkfun.com/products/13680

I'd just like to add that not all IR sensors work that way.  Some have an IR led that shines a dot straight ahead and then it looks at that spot and based on the angle, determine the distance.  I'm pretty sure this is how the sharp ir sensors work, but I could be wrong.

@mwwalk my point number 2 covers this though I was not clear. I made some alterations.

@Namphibian I don't think you understood what I was saying but I don't think I said it very clearly.  Note that it doesn't really matter for this question and is a bit pedantic.  I was just saying that some IR sensors use the angle of the echo light rather than the time it takes to determine distance.  This is what the Sharp IR sensors do.

@mwalk noted. I was not aware of this difference. Will go read up about it as it seems a different way to approach the problem. Thanks a million!

If you are using HC-SR04 then I would suggest you to first check it out on simulation. I use Proteus software for simulation purposes and you should download the Ultrasonic Sensor Library for Proteus, using this library you can easily simulate your Ultrasonic sensor in Proteus and can design your code. It will save you from hardware testing.


text:
How to reset Arduino Uno over BLE just like over USB?
I'm working on wireless upload to Arduino and i've succeed for Mega2560. But when trying to upload to Uno it does not wait for upload commands. I'm doing reset using GPIO and HM-10 BLE module wired with capacitor and resistor and wired to MCU's reset pin just it's done for USB. I think it remembers somehow how it was reset - by pressing hardware RESET button, by USB DTR/RTS or other way. The problem is that when resetting for USB it waits for upload commands after reset and for BLE it does not.
I've viewed optiboot bootloader code but i'm not sure i understand it correctly. Any clue on how to do it?
Update1:
2015-09-05 15:51:36.682 xctest[60180:7754033] [TRACE  ] [OUT]: Send: A [0x41] T [0x54] + [0x2B] P [0x50] I [0x49] O [0x4F] 2 [0x32] 1 [0x31]
2015-09-05 15:51:36.682 xctest[60180:7754033] [TRACE  ] [OUT]: BLE sending bytes range from 0 length 8
2015-09-05 15:51:36.735 xctest[60180:7754033] [DEBUG  ] [OUT]: Sending 8 bytes
2015-09-05 15:51:36.736 xctest[60180:7754033] [TRACE  ] [OUT]: Send: A [0x41] T [0x54] + [0x2B] P [0x50] I [0x49] O [0x4F] 2 [0x32] 0 [0x30]
2015-09-05 15:51:36.736 xctest[60180:7754033] [TRACE  ] [OUT]: BLE sending bytes range from 0 length 8
2015-09-05 15:51:36.788 xctest[60180:7754033] [DEBUG  ] [   ]: Draining for 300 ms ...
2015-09-05 15:51:36.788 xctest[60180:7754033] [TRACE  ] [IN ]: Start reading
2015-09-05 15:51:37.053 xctest[60180:7754082] [TRACE  ] [IN ]: Rx value received 9 bytes: O [0x4F] K [0x4B] + [0x2B] P [0x50] I [0x49] O [0x4F] 2 [0x32] : [0x3A] 1 [0x31]
2015-09-05 15:51:37.053 xctest[60180:7754082] [TRACE  ] [IN ]: Rx value received 9 bytes: O [0x4F] K [0x4B] + [0x2B] P [0x50] I [0x49] O [0x4F] 2 [0x32] : [0x3A] 0 [0x30]
2015-09-05 15:51:37.093 xctest[60180:7754033] [TRACE  ] [IN ]: Finish reading
2015-09-05 15:51:37.093 xctest[60180:7754033] [TRACE  ] [IN ]: Ble clear buffer
2015-09-05 15:51:37.093 xctest[60180:7754033] [DEBUG  ] [IN ]: Drained 18 bytes
2015-09-05 15:51:37.094 xctest[60180:7754033] [DEBUG  ] [OUT]: Sending 2 bytes
2015-09-05 15:51:37.094 xctest[60180:7754033] [TRACE  ] [OUT]: Send: 0 [0x30]   [0x20]
2015-09-05 15:51:37.094 xctest[60180:7754033] [TRACE  ] [OUT]: BLE sending bytes range from 0 length 2
2015-09-05 15:51:37.095 xctest[60180:7754033] [DEBUG  ] [IN ]: Reading 1 bytes ...
2015-09-05 15:51:37.096 xctest[60180:7754033] [TRACE  ] [IN ]: Start reading
2015-09-05 15:51:37.450 xctest[60180:7754084] [TRACE  ] [IN ]: Rx value received 1 bytes: . [0x00]
2015-09-05 15:51:37.450 xctest[60180:7754084] [TRACE  ] [IN ]: Ignoring single 0x00 char
2015-09-05 15:51:37.450 xctest[60180:7754084] [TRACE  ] [IN ]: Rx value received 2 bytes: . [0x14] . [0x10]
2015-09-05 15:51:37.452 xctest[60180:7754033] [TRACE  ] [IN ]: Finish reading
2015-09-05 15:51:37.452 xctest[60180:7754033] [TRACE  ] [IN ]: Receive: . [0x14]
2015-09-05 15:51:37.452 xctest[60180:7754033] [DEBUG  ] [IN ]: Read 1 bytes, actually received 2 bytes
2015-09-05 15:51:37.453 xctest[60180:7754033] [TRACE  ] [IN ]: 1 bytes in incoming buffer remaining for next receive
2015-09-05 15:51:37.453 xctest[60180:7754033] [DEBUG  ] [IN ]: Reading 1 bytes ...
2015-09-05 15:51:37.454 xctest[60180:7754033] [TRACE  ] [IN ]: Having current receive buffer: . [0x10]
2015-09-05 15:51:37.454 xctest[60180:7754033] [TRACE  ] [IN ]: Start reading
2015-09-05 15:51:37.454 xctest[60180:7754033] [TRACE  ] [IN ]: Finish reading
2015-09-05 15:51:37.455 xctest[60180:7754033] [TRACE  ] [IN ]: Receive: . [0x10]
2015-09-05 15:51:37.455 xctest[60180:7754033] [DEBUG  ] [IN ]: Read 1 bytes, actually received 1 bytes
2015-09-05 15:51:37.455 xctest[60180:7754033] [TRACE  ] [IN ]: Ble clear buffer
2015-09-05 15:51:37.455 xctest[60180:7754033] [DEBUG  ] [OUT]: Sending 3 bytes
2015-09-05 15:51:37.456 xctest[60180:7754033] [TRACE  ] [OUT]: Send: A [0x41] . [0x81]   [0x20]
2015-09-05 15:51:37.456 xctest[60180:7754033] [TRACE  ] [OUT]: BLE sending bytes range from 0 length 3
2015-09-05 15:51:37.457 xctest[60180:7754033] [DEBUG  ] [IN ]: Reading 1 bytes ...
2015-09-05 15:51:37.457 xctest[60180:7754033] [TRACE  ] [IN ]: Start reading
2015-09-05 15:51:37.701 xctest[60180:7754084] [TRACE  ] [IN ]: Rx value received 1 bytes: . [0x00]
2015-09-05 15:51:37.701 xctest[60180:7754084] [TRACE  ] [IN ]: Ignoring single 0x00 char
2015-09-05 15:51:38.451 xctest[60180:7754082] [TRACE  ] [IN ]: Rx value received 5 bytes: h [0x68] e [0x65] l [0x6C] l [0x6C] o [0x6F]
2015-09-05 15:51:38.452 xctest[60180:7754033] [TRACE  ] [IN ]: Finish reading

Update 2 (this is uploading to Uno over USB log):
2015-06-29 16:34:10.829 xctest[36585:3703900] [TRACE  ] [   ]: DTR/RTS supported by Serial, resetting
2015-06-29 16:34:11.140 xctest[36585:3703900] [DEBUG  ] [IN ]: Draining ...
2015-06-29 16:34:11.392 xctest[36585:3703900] [DEBUG  ] [IN ]: Drain done
2015-06-29 16:34:11.392 xctest[36585:3703900] [DEBUG  ] [OUT]: Sending 2 bytes
2015-06-29 16:34:11.392 xctest[36585:3703900] [TRACE  ] [OUT]: Send: 0 [0x30]   [0x20]
2015-06-29 16:34:11.393 xctest[36585:3703900] [DEBUG  ] [IN ]: Receiving 1 bytes
2015-06-29 16:34:11.531 xctest[36585:3703900] [TRACE  ] [IN ]: Received: . [0x14]
2015-06-29 16:34:11.531 xctest[36585:3703900] [DEBUG  ] [IN ]: Receiving 1 bytes
2015-06-29 16:34:11.532 xctest[36585:3703900] [TRACE  ] [IN ]: Received: . [0x10]
2015-06-29 16:34:11.532 xctest[36585:3703900] [DEBUG  ] [OUT]: Sending 3 bytes
2015-06-29 16:34:11.532 xctest[36585:3703900] [TRACE  ] [OUT]: Send: A [0x41] . [0x81]   [0x20]
2015-06-29 16:34:11.533 xctest[36585:3703900] [DEBUG  ] [IN ]: Receiving 1 bytes
2015-06-29 16:34:11.535 xctest[36585:3703900] [TRACE  ] [IN ]: Received: . [0x14]
2015-06-29 16:34:11.536 xctest[36585:3703900] [DEBUG  ] [IN ]: Receiving 1 bytes
2015-06-29 16:34:11.536 xctest[36585:3703900] [TRACE  ] [IN ]: Received: . [0x04]
2015-06-29 16:34:11.536 xctest[36585:3703900] [DEBUG  ] [IN ]: Receiving 1 bytes
2015-06-29 16:34:11.536 xctest[36585:3703900] [TRACE  ] [IN ]: Received: . [0x10]
2015-06-29 16:34:11.537 xctest[36585:3703900] [DEBUG  ] [OUT]: Sending 3 bytes
2015-06-29 16:34:11.537 xctest[36585:3703900] [TRACE  ] [OUT]: Send: A [0x41] . [0x82]   [0x20]
2015-06-29 16:34:11.537 xctest[36585:3703900] [DEBUG  ] [IN ]: Receiving 1 bytes
2015-06-29 16:34:11.540 xctest[36585:3703900] [TRACE  ] [IN ]: Received: . [0x14]
2015-06-29 16:34:11.540 xctest[36585:3703900] [DEBUG  ] [IN ]: Receiving 1 bytes
2015-06-29 16:34:11.540 xctest[36585:3703900] [TRACE  ] [IN ]: Received: . [0x04]
2015-06-29 16:34:11.540 xctest[36585:3703900] [DEBUG  ] [IN ]: Receiving 1 bytes
2015-06-29 16:34:11.541 xctest[36585:3703900] [TRACE  ] [IN ]: Received: . [0x10]
2015-06-29 16:34:11.541 xctest[36585:3703900] [DEBUG  ] [   ]: STK500:initialize: n_extparms = 4
2015-06-29 16:34:11.541 xctest[36585:3703900] [DEBUG  ] [OUT]: Sending 22 bytes
2015-06-29 16:34:11.542 xctest[36585:3703900] [TRACE  ] [OUT]: Send: B [0x42] . [0x86] . [0x00] . [0x01] . [0x00] . [0x01] . [0x01] . [0x01] . [0x03] . [0xFF] . [0xFF] . [0xFF] . [0xFF] . [0x00] . [0x80] . [0x04] . [0x00] . [0x00] . [0x00] . [0x80] . [0x00]   [0x20]
2015-06-29 16:34:11.542 xctest[36585:3703900] [DEBUG  ] [IN ]: Receiving 1 bytes
2015-06-29 16:34:11.548 xctest[36585:3703900] [TRACE  ] [IN ]: Received: . [0x14]
2015-06-29 16:34:11.548 xctest[36585:3703900] [DEBUG  ] [IN ]: Receiving 1 bytes
2015-06-29 16:34:11.548 xctest[36585:3703900] [TRACE  ] [IN ]: Received: . [0x10]
2015-06-29 16:34:11.548 xctest[36585:3703900] [DEBUG  ] [OUT]: Sending 7 bytes
2015-06-29 16:34:11.549 xctest[36585:3703900] [TRACE  ] [OUT]: Send: E [0x45] . [0x05] . [0x04] . [0xD7] . [0xC2] . [0x00]   [0x20]
2015-06-29 16:34:11.549 xctest[36585:3703900] [DEBUG  ] [IN ]: Receiving 1 bytes
2015-06-29 16:34:11.552 xctest[36585:3703900] [TRACE  ] [IN ]: Received: . [0x14]
2015-06-29 16:34:11.552 xctest[36585:3703900] [DEBUG  ] [IN ]: Receiving 1 bytes
2015-06-29 16:34:11.552 xctest[36585:3703900] [TRACE  ] [IN ]: Received: . [0x10]
2015-06-29 16:34:11.553 xctest[36585:3703900] [DEBUG  ] [OUT]: Sending 2 bytes
2015-06-29 16:34:11.553 xctest[36585:3703900] [TRACE  ] [OUT]: Send: P [0x50]   [0x20]
2015-06-29 16:34:11.553 xctest[36585:3703900] [DEBUG  ] [IN ]: Receiving 1 bytes
2015-06-29 16:34:11.556 xctest[36585:3703900] [TRACE  ] [IN ]: Received: . [0x14]
2015-06-29 16:34:11.556 xctest[36585:3703900] [DEBUG  ] [IN ]: Receiving 1 bytes
2015-06-29 16:34:11.556 xctest[36585:3703900] [TRACE  ] [IN ]: Received: . [0x10]
2015-06-29 16:34:11.569 xctest[36585:3703900] Reading |                                                    | 0% 0ms
2015-06-29 16:34:11.570 xctest[36585:3703900] [DEBUG  ] [OUT]: Sending 2 bytes
2015-06-29 16:34:11.571 xctest[36585:3703900] [TRACE  ] [OUT]: Send: u [0x75]   [0x20]
2015-06-29 16:34:11.571 xctest[36585:3703900] [DEBUG  ] [IN ]: Receiving 5 bytes
2015-06-29 16:34:11.572 xctest[36585:3703900] [TRACE  ] [IN ]: Received: . [0x14] . [0x1E] . [0x95] . [0x0F] . [0x10]
2015-06-29 16:34:11.572 xctest[36585:3703900] Reading | ################################################## | 100% 2ms

Update 3:
i've modified bootloader (optiboot) to wait 4 seconds (instead of 1 second by default) and added blinking when character 0x41 (STK_GET_PARAMETER) arrives. Also i've uploaded 'echo' sketch to return what back everything that is sent to the board.
bootloader modifications (part):
// Set up watchdog to trigger after 4s
  watchdogConfig(WATCHDOG_4S); // 4ntoine: was WATCHDOG_1s

  /* Set LED pin as output */
  LED_DDR |= _BV(LED);

#ifdef SOFT_UART
  /* Set TX pin as output */
  UART_DDR |= _BV(UART_TX_BIT);
#endif

// #if LED_START_FLASHES > 0
  /* Flash onboard LED to signal entering of bootloader */
  // flash_led(2); // 4ntoine
// #endif

  /* Forever loop */
  for (;;) {
    /* get character from UART */
    ch = getch();

    if(ch == STK_GET_PARAMETER) {
      flash_led(2); // 4ntoine

      unsigned char which = getch();
      verifySpace();

      if (which == 0x82) {
         /*
           * Send optiboot version as "minor SW version"
           */
         putch(OPTIBOOT_MINVER);
      } else if (which == 0x81) {
           putch(OPTIBOOT_MAJVER);
      } else {
    /*
     * GET PARAMETER returns a generic 0x03 reply for
         * other parameters - enough to keep Avrdude happy
     */
    putch(0x03);
      }
    }

uploaded arduino sketch:
int LED = 13;

void setup() {
  // avoid misleading blinking
  pinMode(LED, OUTPUT);
  digitalWrite(LED, LOW);

  // to let us know when sketch starts
  Serial.begin(115200);
  Serial.write("hello");
}

void loop() {
  while (Serial.available()) {
    int incomingByte = Serial.read();
    Serial.write(incomingByte);
  }

}

log:
2015-09-13 20:52:57.011 xctest[55099:2968978] [INFO   ] [   ]: Found peripheral: <CBPeripheral: 0x100400af0 identifier = D92ECAAB-51A5-44D5-8C6C-536CD797867E, Name = "BleIos", state = disconnected>
2015-09-13 20:52:57.011 xctest[55099:2968978] [DEBUG  ] [   ]: Stop scanning
2015-09-13 20:52:57.012 xctest[55099:2968978] [INFO   ] [   ]: Connecting to <CBPeripheral: 0x100400af0 identifier = D92ECAAB-51A5-44D5-8C6C-536CD797867E, Name = "BleIos", state = disconnected>
2015-09-13 20:52:57.236 xctest[55099:2968989] [DEBUG  ] [   ]: Connected to peripheral <CBPeripheral: 0x100400af0 identifier = D92ECAAB-51A5-44D5-8C6C-536CD797867E, Name = "BleIos", state = connected>
2015-09-13 20:52:57.238 xctest[55099:2968989] [TRACE  ] [   ]: Discovered services for peripheral <CBPeripheral: 0x100400af0 identifier = D92ECAAB-51A5-44D5-8C6C-536CD797867E, Name = "BleIos", state = connected>
2015-09-13 20:52:57.238 xctest[55099:2968989] [DEBUG  ] [   ]: Discovered service <CBService: 0x10010d950>
2015-09-13 20:52:57.381 xctest[55099:2968989] [TRACE  ] [   ]: Discovered characteristics for service <CBService: 0x10010d950>
2015-09-13 20:52:57.381 xctest[55099:2968989] [TRACE  ] [   ]: Discovered characteristic <CBCharacteristic: 0x100304d10>
2015-09-13 20:52:57.382 xctest[55099:2968989] [DEBUG  ] [   ]: Tx characteristic supports WriteWithResponse: NO
2015-09-13 20:52:57.382 xctest[55099:2968989] [TRACE  ] [   ]: Subscribing to Rx value
2015-09-13 20:52:57.392 xctest[55099:2968940] [INFO   ] [   ]: Connected successfully
2015-09-13 20:52:57.392 xctest[55099:2968940] [TRACE  ] [   ]: DTR/RTS supported by Serial, resetting
2015-09-13 20:52:57.392 xctest[55099:2968940] [TRACE  ] [   ]: Waiting until subscribed to Rx value ...
2015-09-13 20:52:58.387 xctest[55099:2968989] [DEBUG  ] [IN ]: Updated notifications state for RX characteristic: isNotifying=YES
2015-09-13 20:52:58.408 xctest[55099:2968940] [DEBUG  ] [OUT]: Sending 8 bytes
2015-09-13 20:52:58.408 xctest[55099:2968940] [TRACE  ] [OUT]: Send: A [0x41] T [0x54] + [0x2B] P [0x50] I [0x49] O [0x4F] 2 [0x32] 1 [0x31]
2015-09-13 20:52:58.408 xctest[55099:2968940] [TRACE  ] [OUT]: BLE sending bytes range from 0 length 8
2015-09-13 20:52:58.463 xctest[55099:2968940] [DEBUG  ] [OUT]: Sending 8 bytes
2015-09-13 20:52:58.463 xctest[55099:2968940] [TRACE  ] [OUT]: Send: A [0x41] T [0x54] + [0x2B] P [0x50] I [0x49] O [0x4F] 2 [0x32] 0 [0x30]
2015-09-13 20:52:58.463 xctest[55099:2968940] [TRACE  ] [OUT]: BLE sending bytes range from 0 length 8
2015-09-13 20:52:58.518 xctest[55099:2968940] [DEBUG  ] [   ]: Draining for 300 ms ...
2015-09-13 20:52:58.518 xctest[55099:2968940] [TRACE  ] [IN ]: Start reading
2015-09-13 20:52:58.784 xctest[55099:2968989] [TRACE  ] [IN ]: Rx value received 9 bytes: O [0x4F] K [0x4B] + [0x2B] P [0x50] I [0x49] O [0x4F] 2 [0x32] : [0x3A] 1 [0x31]
2015-09-13 20:52:58.785 xctest[55099:2968989] [WARNING] [IN ]: Removing 'OK+PIO2:1' (9 bytes) from incoming buffer (9 bytes)
2015-09-13 20:52:58.785 xctest[55099:2968989] [WARNING] [IN ]: Got 0 bytes in incoming buffer
2015-09-13 20:52:58.786 xctest[55099:2968989] [TRACE  ] [IN ]: Rx value received 9 bytes: O [0x4F] K [0x4B] + [0x2B] P [0x50] I [0x49] O [0x4F] 2 [0x32] : [0x3A] 0 [0x30]
2015-09-13 20:52:58.786 xctest[55099:2968989] [WARNING] [IN ]: Removing 'OK+PIO2:0' (9 bytes) from incoming buffer (9 bytes)
2015-09-13 20:52:58.787 xctest[55099:2968989] [WARNING] [IN ]: Got 0 bytes in incoming buffer
2015-09-13 20:52:58.820 xctest[55099:2968940] [TRACE  ] [IN ]: Finish reading
2015-09-13 20:52:58.820 xctest[55099:2968940] [TRACE  ] [IN ]: Ble clear buffer
2015-09-13 20:52:58.821 xctest[55099:2968940] [DEBUG  ] [IN ]: Drained 0 bytes
2015-09-13 20:52:58.821 xctest[55099:2968940] [DEBUG  ] [OUT]: Sending 2 bytes
2015-09-13 20:52:58.821 xctest[55099:2968940] [TRACE  ] [OUT]: Send: 0 [0x30]   [0x20]
2015-09-13 20:52:58.821 xctest[55099:2968940] [TRACE  ] [OUT]: BLE sending bytes range from 0 length 2
2015-09-13 20:52:58.822 xctest[55099:2968940] [DEBUG  ] [IN ]: Reading 1 bytes ...
2015-09-13 20:52:58.822 xctest[55099:2968940] [TRACE  ] [IN ]: Start reading
2015-09-13 20:52:59.193 xctest[55099:2968978] [TRACE  ] [IN ]: Rx value received 1 bytes: . [0x00]
2015-09-13 20:52:59.193 xctest[55099:2968978] [TRACE  ] [IN ]: Ignoring single 0x00 char
2015-09-13 20:52:59.193 xctest[55099:2968978] [TRACE  ] [IN ]: Rx value received 2 bytes: . [0x14] . [0x10]
2015-09-13 20:52:59.194 xctest[55099:2968978] [WARNING] [IN ]: Got 2 bytes in incoming buffer
2015-09-13 20:52:59.194 xctest[55099:2968940] [TRACE  ] [IN ]: Finish reading
2015-09-13 20:52:59.195 xctest[55099:2968940] [TRACE  ] [IN ]: Receive: . [0x14]
2015-09-13 20:52:59.195 xctest[55099:2968940] [DEBUG  ] [IN ]: Read 1 bytes, actually received 2 bytes
2015-09-13 20:52:59.195 xctest[55099:2968940] [TRACE  ] [IN ]: 1 bytes in incoming buffer remaining for next receive
2015-09-13 20:52:59.196 xctest[55099:2968940] [DEBUG  ] [IN ]: Reading 1 bytes ...
2015-09-13 20:52:59.196 xctest[55099:2968940] [TRACE  ] [IN ]: Having current receive buffer: . [0x10]
2015-09-13 20:52:59.196 xctest[55099:2968940] [TRACE  ] [IN ]: Start reading
2015-09-13 20:52:59.196 xctest[55099:2968940] [TRACE  ] [IN ]: Finish reading
2015-09-13 20:52:59.197 xctest[55099:2968940] [TRACE  ] [IN ]: Receive: . [0x10]
2015-09-13 20:52:59.197 xctest[55099:2968940] [DEBUG  ] [IN ]: Read 1 bytes, actually received 1 bytes
2015-09-13 20:52:59.197 xctest[55099:2968940] [TRACE  ] [IN ]: Ble clear buffer
2015-09-13 20:52:59.198 xctest[55099:2968940] [DEBUG  ] [OUT]: Sending 3 bytes
2015-09-13 20:52:59.198 xctest[55099:2968940] [TRACE  ] [OUT]: Send: A [0x41] . [0x81]   [0x20]
2015-09-13 20:52:59.198 xctest[55099:2968940] [TRACE  ] [OUT]: BLE sending bytes range from 0 length 3
2015-09-13 20:52:59.199 xctest[55099:2968940] [DEBUG  ] [IN ]: Reading 1 bytes ...
2015-09-13 20:52:59.199 xctest[55099:2968940] [TRACE  ] [IN ]: Start reading
2015-09-13 20:52:59.268 xctest[55099:2968978] [TRACE  ] [IN ]: Rx value received 1 bytes: . [0x00]
2015-09-13 20:52:59.268 xctest[55099:2968978] [TRACE  ] [IN ]: Ignoring single 0x00 char
2015-09-13 20:53:02.955 xctest[55099:2968940] [ERROR  ] [OUT]: BLE read timeout: 3.000965 (timeout = 3.000000)
2015-09-13 20:53:02.955 xctest[55099:2968940] [TRACE  ] [IN ]: Finish reading
2015-09-13 20:53:02.955 xctest[55099:2968940] [TRACE  ] [IN ]: Ble clear buffer
2015-09-13 20:53:02.955 xctest[55099:2968940] [ERROR  ] [IN ]: STK500:receive: programmer is not responding
2015-09-13 20:53:02.956 xctest[55099:2968940] [DEBUG  ] [OUT]: Sending 3 bytes
2015-09-13 20:53:02.956 xctest[55099:2968940] [TRACE  ] [OUT]: Send: A [0x41] . [0x82]   [0x20]
2015-09-13 20:53:02.956 xctest[55099:2968940] [TRACE  ] [OUT]: BLE sending bytes range from 0 length 3
2015-09-13 20:53:02.956 xctest[55099:2968940] [DEBUG  ] [IN ]: Reading 1 bytes ...
2015-09-13 20:53:02.957 xctest[55099:2968940] [TRACE  ] [IN ]: Start reading
2015-09-13 20:53:03.018 xctest[55099:2968978] [TRACE  ] [IN ]: Rx value received 1 bytes: . [0x00]
2015-09-13 20:53:03.018 xctest[55099:2968978] [TRACE  ] [IN ]: Ignoring single 0x00 char
2015-09-13 20:53:03.280 xctest[55099:2968989] [TRACE  ] [IN ]: Rx value received 5 bytes: h [0x68] e [0x65] l [0x6C] l [0x6C] o [0x6F]
2015-09-13 20:53:03.280 xctest[55099:2968989] [WARNING] [IN ]: Got 5 bytes in incoming buffer
2015-09-13 20:53:03.281 xctest[55099:2968940] [TRACE  ] [IN ]: Finish reading

i can see blinking so the character arrives so the characters arrive correctly to the board. also i've tested wiring (sketch returns exactly the same as it was sent and it sends 'hello' after start). So i'm pretty sure:
1. characters arrive correctly to the bootloader
2. wiring is correct (as i can see back what i've sent - i'm using LightBlue mac app to open HM-10 as BLE device, subscribe to the characteristics and send characters and i can see it's changing to what i've sent).
3. bootloader waits for 4 seconds (i can see it in Arduino IDE terminal).
Update 4 :
my understanding now is that optiboot sets wrong baud rate for 115200 passed in bootloader mode as it replies with 0x11 and transmits characters correctly in sketch mode:
2015-09-17 09:39:25.628 xctest[60179:4253160] [TRACE  ] [IN ]: Rx value received 9 bytes: O [0x4F] K [0x4B] + [0x2B] P [0x50] I [0x49] O [0x4F] 2 [0x32] : [0x3A] 1 [0x31]
2015-09-17 09:39:25.628 xctest[60179:4253160] [WARNING] [IN ]: Got 9 bytes in incoming buffer
2015-09-17 09:39:25.629 xctest[60179:4253160] [TRACE  ] [IN ]: Rx value received 9 bytes: O [0x4F] K [0x4B] + [0x2B] P [0x50] I [0x49] O [0x4F] 2 [0x32] : [0x3A] 0 [0x30]
2015-09-17 09:39:25.629 xctest[60179:4253160] [WARNING] [IN ]: Got 9 bytes in incoming buffer
2015-09-17 09:39:25.630 xctest[60179:4253160] [TRACE  ] [IN ]: Rx value received 1 bytes: . [0x00]
2015-09-17 09:39:25.630 xctest[60179:4253160] [TRACE  ] [IN ]: Ignoring single 0x00 char
2015-09-17 09:39:27.351 xctest[60179:4253117] [TRACE  ] [IN ]: Finish reading
2015-09-17 09:39:27.351 xctest[60179:4253117] [TRACE  ] [IN ]: Ble clear buffer
2015-09-17 09:39:27.351 xctest[60179:4253117] [DEBUG  ] [IN ]: Drained 18 bytes
2015-09-17 09:39:27.352 xctest[60179:4253117] [DEBUG  ] [   ]: Draining incoming buffer (0 bytes)
2015-09-17 09:39:27.352 xctest[60179:4253117] [DEBUG  ] [OUT]: Sending 2 bytes
2015-09-17 09:39:27.352 xctest[60179:4253117] [TRACE  ] [OUT]: Send: 0 [0x30]   [0x20]
2015-09-17 09:39:27.353 xctest[60179:4253117] [TRACE  ] [OUT]: BLE sending bytes range from 0 length 2
2015-09-17 09:39:27.353 xctest[60179:4253117] [DEBUG  ] [IN ]: Reading 1 bytes ...
2015-09-17 09:39:27.353 xctest[60179:4253117] [TRACE  ] [IN ]: Start reading
2015-09-17 09:39:27.424 xctest[60179:4253160] [TRACE  ] [IN ]: Rx value received 1 bytes: . [0x00]
2015-09-17 09:39:27.424 xctest[60179:4253160] [TRACE  ] [IN ]: Ignoring single 0x00 char
2015-09-17 09:39:27.424 xctest[60179:4253149] [TRACE  ] [IN ]: Rx value received 2 bytes: . [0x11] . [0xFC]
2015-09-17 09:39:27.425 xctest[60179:4253149] [WARNING] [IN ]: Got 2 bytes in incoming buffer
2015-09-17 09:39:27.425 xctest[60179:4253117] [TRACE  ] [IN ]: Finish reading
2015-09-17 09:39:27.425 xctest[60179:4253117] [TRACE  ] [IN ]: Receive: . [0x11]
2015-09-17 09:39:27.425 xctest[60179:4253117] [DEBUG  ] [IN ]: Read 1 bytes, actually received 2 bytes
2015-09-17 09:39:27.426 xctest[60179:4253117] [TRACE  ] [IN ]: 1 bytes in incoming buffer remaining for next receive
2015-09-17 09:39:27.426 xctest[60179:4253117] [ERROR  ] [   ]: STK500:synchronize: attempt 1 of 3: no sync: received [0x11]
2015-09-17 09:39:27.426 xctest[60179:4253117] [DEBUG  ] [   ]: Draining incoming buffer (1 bytes)
2015-09-17 09:39:27.426 xctest[60179:4253117] [DEBUG  ] [OUT]: Sending 2 bytes
2015-09-17 09:39:27.427 xctest[60179:4253117] [TRACE  ] [OUT]: Send: 0 [0x30]   [0x20]
2015-09-17 09:39:27.427 xctest[60179:4253117] [TRACE  ] [OUT]: BLE sending bytes range from 0 length 2
2015-09-17 09:39:27.427 xctest[60179:4253117] [DEBUG  ] [IN ]: Reading 1 bytes ...
2015-09-17 09:39:27.427 xctest[60179:4253117] [TRACE  ] [IN ]: Start reading
2015-09-17 09:39:27.499 xctest[60179:4253160] [TRACE  ] [IN ]: Rx value received 1 bytes: . [0x00]
2015-09-17 09:39:27.499 xctest[60179:4253160] [TRACE  ] [IN ]: Ignoring single 0x00 char
2015-09-17 09:39:27.500 xctest[60179:4253160] [TRACE  ] [IN ]: Rx value received 2 bytes: . [0x14] . [0x10]
2015-09-17 09:39:27.500 xctest[60179:4253160] [WARNING] [IN ]: Got 2 bytes in incoming buffer
2015-09-17 09:39:27.500 xctest[60179:4253117] [TRACE  ] [IN ]: Finish reading
2015-09-17 09:39:27.501 xctest[60179:4253117] [TRACE  ] [IN ]: Receive: . [0x14]
2015-09-17 09:39:27.501 xctest[60179:4253117] [DEBUG  ] [IN ]: Read 1 bytes, actually received 2 bytes
2015-09-17 09:39:27.501 xctest[60179:4253117] [TRACE  ] [IN ]: 1 bytes in incoming buffer remaining for next receive
2015-09-17 09:39:27.501 xctest[60179:4253117] [DEBUG  ] [IN ]: Reading 1 bytes ...
2015-09-17 09:39:27.501 xctest[60179:4253117] [TRACE  ] [IN ]: Having current receive buffer: . [0x10]
2015-09-17 09:39:27.502 xctest[60179:4253117] [TRACE  ] [IN ]: Start reading
2015-09-17 09:39:27.502 xctest[60179:4253117] [TRACE  ] [IN ]: Finish reading
2015-09-17 09:39:27.502 xctest[60179:4253117] [TRACE  ] [IN ]: Receive: . [0x10]
2015-09-17 09:39:27.508 xctest[60179:4253117] [DEBUG  ] [IN ]: Read 1 bytes, actually received 1 bytes
2015-09-17 09:39:27.509 xctest[60179:4253117] [TRACE  ] [IN ]: Ble clear buffer
2015-09-17 09:39:27.509 xctest[60179:4253117] [DEBUG  ] [OUT]: Sending 3 bytes
2015-09-17 09:39:27.509 xctest[60179:4253117] [TRACE  ] [OUT]: Send: A [0x41] . [0x81]   [0x20]
2015-09-17 09:39:27.509 xctest[60179:4253117] [TRACE  ] [OUT]: BLE sending bytes range from 0 length 3
2015-09-17 09:39:27.510 xctest[60179:4253117] [DEBUG  ] [IN ]: Reading 1 bytes ...
2015-09-17 09:39:27.510 xctest[60179:4253117] [TRACE  ] [IN ]: Start reading
2015-09-17 09:39:27.574 xctest[60179:4253149] [TRACE  ] [IN ]: Rx value received 1 bytes: . [0x00]
2015-09-17 09:39:27.574 xctest[60179:4253149] [TRACE  ] [IN ]: Ignoring single 0x00 char
2015-09-17 09:39:31.325 xctest[60179:4253117] [ERROR  ] [OUT]: BLE read timeout: 3.000965 (timeout = 3.000000)
2015-09-17 09:39:31.326 xctest[60179:4253117] [TRACE  ] [IN ]: Finish reading
2015-09-17 09:39:31.326 xctest[60179:4253117] [TRACE  ] [IN ]: Ble clear buffer
2015-09-17 09:39:31.326 xctest[60179:4253117] [ERROR  ] [IN ]: STK500:receive: programmer is not responding
2015-09-17 09:39:31.327 xctest[60179:4253117] [DEBUG  ] [OUT]: Sending 3 bytes
2015-09-17 09:39:31.327 xctest[60179:4253117] [TRACE  ] [OUT]: Send: A [0x41] . [0x82]   [0x20]
2015-09-17 09:39:31.327 xctest[60179:4253117] [TRACE  ] [OUT]: BLE sending bytes range from 0 length 3
2015-09-17 09:39:31.328 xctest[60179:4253117] [DEBUG  ] [IN ]: Reading 1 bytes ...
2015-09-17 09:39:31.328 xctest[60179:4253117] [TRACE  ] [IN ]: Start reading
2015-09-17 09:39:31.399 xctest[60179:4253160] [TRACE  ] [IN ]: Rx value received 1 bytes: . [0x00]
2015-09-17 09:39:31.400 xctest[60179:4253160] [TRACE  ] [IN ]: Ignoring single 0x00 char
2015-09-17 09:39:35.173 xctest[60179:4253117] [ERROR  ] [OUT]: BLE read timeout: 3.000965 (timeout = 3.000000)
2015-09-17 09:39:35.173 xctest[60179:4253117] [TRACE  ] [IN ]: Finish reading
2015-09-17 09:39:35.174 xctest[60179:4253117] [TRACE  ] [IN ]: Ble clear buffer
2015-09-17 09:39:35.174 xctest[60179:4253117] [ERROR  ] [IN ]: STK500:receive: programmer is not responding
2015-09-17 09:39:35.174 xctest[60179:4253117] [DEBUG  ] [   ]: STK500:initialize: n_extparms = 3
2015-09-17 09:39:35.175 xctest[60179:4253117] [DEBUG  ] [OUT]: Sending 22 bytes
2015-09-17 09:39:35.175 xctest[60179:4253117] [TRACE  ] [OUT]: Send: B [0x42] . [0x86] . [0x00] . [0x01] . [0x00] . [0x01] . [0x01] . [0x01] . [0x03] . [0xFF] . [0xFF] . [0xFF] . [0xFF] . [0x00] . [0x80] . [0x04] . [0x00] . [0x00] . [0x00] . [0x80] . [0x00]   [0x20]
2015-09-17 09:39:35.175 xctest[60179:4253117] [TRACE  ] [OUT]: BLE sending bytes range from 0 length 20
2015-09-17 09:39:35.176 xctest[60179:4253117] [TRACE  ] [OUT]: BLE sending bytes range from 20 length 2
2015-09-17 09:39:35.177 xctest[60179:4253117] [DEBUG  ] [IN ]: Reading 1 bytes ...
2015-09-17 09:39:35.177 xctest[60179:4253117] [TRACE  ] [IN ]: Start reading
2015-09-17 09:39:35.224 xctest[60179:4253149] [TRACE  ] [IN ]: Rx value received 1 bytes: . [0x00]
2015-09-17 09:39:35.224 xctest[60179:4253149] [TRACE  ] [IN ]: Ignoring single 0x00 char

Should it work if i wire pins 0 and 1 at Uno to RX/TX (it does work for Mega2560)? Here is soft uart code from optiboot:
#ifndef SOFT_UART
#ifdef __AVR_ATmega8__
  UCSRA = _BV(U2X); //Double speed mode USART
  UCSRB = _BV(RXEN) | _BV(TXEN);  // enable Rx & Tx
  UCSRC = _BV(URSEL) | _BV(UCSZ1) | _BV(UCSZ0);  // config USART; 8N1
  UBRRL = (uint8_t)( (F_CPU + BAUD_RATE * 4L) / (BAUD_RATE * 8L) - 1 );
#else
  UCSR0A = _BV(U2X0); //Double speed mode USART0
  UCSR0B = _BV(RXEN0) | _BV(TXEN0);
  UCSR0C = _BV(UCSZ00) | _BV(UCSZ01);
  UBRR0L = (uint8_t)( (F_CPU + BAUD_RATE * 4L) / (BAUD_RATE * 8L) - 1 );
#endif
#endif

#ifdef SOFT_UART
  /* Set TX pin as output */
  UART_DDR |= _BV(UART_TX_BIT);
#endif

Should RX be set as input separately too (like Tx as output)? Why it tries to set 'Double speed'?

Eventually i've found the reason. And it was bug in HM-10 firmware.
In mode 0 it does not accept control commands and in modes 1 and 2 it accepts AT commands to control PIO and commands are look like 'AT+...', f.e. 'PIO set value 1 to pin 1' command is 'AT+PIO11' and change mode to 0 look like 'AT+MODE0'. I need mode 1 to set PIO to 1 and 0 to reset arduino board. The problem is that some of upload commands look like 'A [0x41] . [0x81]   [0x20]' (starts from 'A' too) and it makes HM-10 think it's control command which also starts from 'A'. If i add changing mode to 0 after pin control commands (in order to make HM-10 stop accepting control commands) it starts uploading:
2015-09-18 10:27:32.144 xctest[94852:4603627] [TRACE  ] [IN ]: Rx value received 9 bytes: O [0x4F] K [0x4B] + [0x2B] P [0x50] I [0x49] O [0x4F] 2 [0x32] : [0x3A] 1 [0x31]
2015-09-18 10:27:32.145 xctest[94852:4603627] [WARNING] [IN ]: Got 9 bytes in incoming buffer
2015-09-18 10:27:32.145 xctest[94852:4603627] [TRACE  ] [IN ]: Rx value received 9 bytes: O [0x4F] K [0x4B] + [0x2B] P [0x50] I [0x49] O [0x4F] 2 [0x32] : [0x3A] 0 [0x30]
2015-09-18 10:27:32.146 xctest[94852:4603627] [WARNING] [IN ]: Got 9 bytes in incoming buffer
2015-09-18 10:27:32.146 xctest[94852:4603627] [TRACE  ] [IN ]: Rx value received 8 bytes: O [0x4F] K [0x4B] + [0x2B] S [0x53] e [0x65] t [0x74] : [0x3A] 0 [0x30]
2015-09-18 10:27:32.147 xctest[94852:4603627] [WARNING] [IN ]: Got 8 bytes in incoming buffer
2015-09-18 10:27:32.147 xctest[94852:4603627] [TRACE  ] [IN ]: Rx value received 1 bytes: . [0x00]
2015-09-18 10:27:32.147 xctest[94852:4603627] [TRACE  ] [IN ]: Ignoring single 0x00 char
2015-09-18 10:27:32.207 xctest[94852:4603578] [TRACE  ] [IN ]: Finish reading
2015-09-18 10:27:32.208 xctest[94852:4603578] [TRACE  ] [IN ]: Ble clear buffer
2015-09-18 10:27:32.208 xctest[94852:4603578] [DEBUG  ] [IN ]: Drained 26 bytes
2015-09-18 10:27:32.208 xctest[94852:4603578] [DEBUG  ] [   ]: Draining incoming buffer (0 bytes)
2015-09-18 10:27:32.208 xctest[94852:4603578] [DEBUG  ] [OUT]: Sending 2 bytes
2015-09-18 10:27:32.208 xctest[94852:4603578] [TRACE  ] [OUT]: Send: 0 [0x30]   [0x20]
2015-09-18 10:27:32.209 xctest[94852:4603578] [TRACE  ] [OUT]: BLE sending bytes range from 0 length 2
2015-09-18 10:27:32.209 xctest[94852:4603578] [DEBUG  ] [IN ]: Reading 1 bytes ...
2015-09-18 10:27:32.209 xctest[94852:4603578] [TRACE  ] [IN ]: Start reading
2015-09-18 10:27:32.561 xctest[94852:4603630] [TRACE  ] [IN ]: Rx value received 1 bytes: . [0x00]
2015-09-18 10:27:32.561 xctest[94852:4603630] [TRACE  ] [IN ]: Ignoring single 0x00 char
2015-09-18 10:27:32.561 xctest[94852:4603627] [TRACE  ] [IN ]: Rx value received 2 bytes: . [0x11] . [0xFC]
2015-09-18 10:27:32.561 xctest[94852:4603627] [WARNING] [IN ]: Got 2 bytes in incoming buffer
2015-09-18 10:27:32.563 xctest[94852:4603578] [TRACE  ] [IN ]: Finish reading
2015-09-18 10:27:32.563 xctest[94852:4603578] [TRACE  ] [IN ]: Receive: . [0x11]
2015-09-18 10:27:32.563 xctest[94852:4603578] [DEBUG  ] [IN ]: Read 1 bytes, actually received 2 bytes
2015-09-18 10:27:32.563 xctest[94852:4603578] [TRACE  ] [IN ]: 1 bytes in incoming buffer remaining for next receive
2015-09-18 10:27:32.563 xctest[94852:4603578] [ERROR  ] [   ]: STK500:synchronize: attempt 1 of 3: no sync: received [0x11]
2015-09-18 10:27:32.564 xctest[94852:4603578] [DEBUG  ] [   ]: Draining incoming buffer (1 bytes)
2015-09-18 10:27:32.564 xctest[94852:4603578] [DEBUG  ] [OUT]: Sending 2 bytes
2015-09-18 10:27:32.564 xctest[94852:4603578] [TRACE  ] [OUT]: Send: 0 [0x30]   [0x20]
2015-09-18 10:27:32.564 xctest[94852:4603578] [TRACE  ] [OUT]: BLE sending bytes range from 0 length 2
2015-09-18 10:27:32.565 xctest[94852:4603578] [DEBUG  ] [IN ]: Reading 1 bytes ...
2015-09-18 10:27:32.565 xctest[94852:4603578] [TRACE  ] [IN ]: Start reading
2015-09-18 10:27:32.636 xctest[94852:4603627] [TRACE  ] [IN ]: Rx value received 1 bytes: . [0x00]
2015-09-18 10:27:32.636 xctest[94852:4603627] [TRACE  ] [IN ]: Ignoring single 0x00 char
2015-09-18 10:27:32.636 xctest[94852:4603627] [TRACE  ] [IN ]: Rx value received 2 bytes: . [0x14] . [0x10]
2015-09-18 10:27:32.636 xctest[94852:4603627] [WARNING] [IN ]: Got 2 bytes in incoming buffer
2015-09-18 10:27:32.638 xctest[94852:4603578] [TRACE  ] [IN ]: Finish reading
2015-09-18 10:27:32.638 xctest[94852:4603578] [TRACE  ] [IN ]: Receive: . [0x14]
2015-09-18 10:27:32.638 xctest[94852:4603578] [DEBUG  ] [IN ]: Read 1 bytes, actually received 2 bytes
2015-09-18 10:27:32.638 xctest[94852:4603578] [TRACE  ] [IN ]: 1 bytes in incoming buffer remaining for next receive
2015-09-18 10:27:32.639 xctest[94852:4603578] [DEBUG  ] [IN ]: Reading 1 bytes ...
2015-09-18 10:27:32.639 xctest[94852:4603578] [TRACE  ] [IN ]: Having current receive buffer: . [0x10]
2015-09-18 10:27:32.639 xctest[94852:4603578] [TRACE  ] [IN ]: Start reading
2015-09-18 10:27:32.639 xctest[94852:4603578] [TRACE  ] [IN ]: Finish reading
2015-09-18 10:27:32.640 xctest[94852:4603578] [TRACE  ] [IN ]: Receive: . [0x10]
2015-09-18 10:27:32.644 xctest[94852:4603578] [DEBUG  ] [IN ]: Read 1 bytes, actually received 1 bytes
2015-09-18 10:27:32.644 xctest[94852:4603578] [TRACE  ] [IN ]: Ble clear buffer
2015-09-18 10:27:32.645 xctest[94852:4603578] [DEBUG  ] [OUT]: Sending 3 bytes
2015-09-18 10:27:32.645 xctest[94852:4603578] [TRACE  ] [OUT]: Send: A [0x41] . [0x81]   [0x20]
2015-09-18 10:27:32.645 xctest[94852:4603578] [TRACE  ] [OUT]: BLE sending bytes range from 0 length 3
2015-09-18 10:27:32.645 xctest[94852:4603578] [DEBUG  ] [IN ]: Reading 1 bytes ...
2015-09-18 10:27:32.646 xctest[94852:4603578] [TRACE  ] [IN ]: Start reading
2015-09-18 10:27:32.711 xctest[94852:4603630] [TRACE  ] [IN ]: Rx value received 1 bytes: . [0x00]
2015-09-18 10:27:32.711 xctest[94852:4603630] [TRACE  ] [IN ]: Ignoring single 0x00 char
2015-09-18 10:27:32.711 xctest[94852:4603630] [TRACE  ] [IN ]: Rx value received 3 bytes: . [0x14] . [0x04] . [0x10]
2015-09-18 10:27:32.711 xctest[94852:4603630] [WARNING] [IN ]: Got 3 bytes in incoming buffer
2015-09-18 10:27:32.712 xctest[94852:4603578] [TRACE  ] [IN ]: Finish reading
2015-09-18 10:27:32.713 xctest[94852:4603578] [TRACE  ] [IN ]: Receive: . [0x14]
2015-09-18 10:27:32.713 xctest[94852:4603578] [DEBUG  ] [IN ]: Read 1 bytes, actually received 3 bytes
2015-09-18 10:27:32.713 xctest[94852:4603578] [TRACE  ] [IN ]: 2 bytes in incoming buffer remaining for next receive
2015-09-18 10:27:32.713 xctest[94852:4603578] [DEBUG  ] [IN ]: Reading 1 bytes ...
2015-09-18 10:27:32.713 xctest[94852:4603578] [TRACE  ] [IN ]: Having current receive buffer: . [0x04] . [0x10]
2015-09-18 10:27:32.714 xctest[94852:4603578] [TRACE  ] [IN ]: Start reading
2015-09-18 10:27:32.714 xctest[94852:4603578] [TRACE  ] [IN ]: Finish reading
2015-09-18 10:27:32.728 xctest[94852:4603578] [TRACE  ] [IN ]: Receive: . [0x04]
2015-09-18 10:27:32.728 xctest[94852:4603578] [DEBUG  ] [IN ]: Read 1 bytes, actually received 2 bytes
2015-09-18 10:27:32.729 xctest[94852:4603578] [TRACE  ] [IN ]: 1 bytes in incoming buffer remaining for next receive
2015-09-18 10:27:32.729 xctest[94852:4603578] [DEBUG  ] [IN ]: Reading 1 bytes ...
2015-09-18 10:27:32.729 xctest[94852:4603578] [TRACE  ] [IN ]: Having current receive buffer: . [0x10]
2015-09-18 10:27:32.729 xctest[94852:4603578] [TRACE  ] [IN ]: Start reading
2015-09-18 10:27:32.730 xctest[94852:4603578] [TRACE  ] [IN ]: Finish reading
2015-09-18 10:27:32.730 xctest[94852:4603578] [TRACE  ] [IN ]: Receive: . [0x10]
2015-09-18 10:27:32.730 xctest[94852:4603578] [DEBUG  ] [IN ]: Read 1 bytes, actually received 1 bytes
2015-09-18 10:27:32.730 xctest[94852:4603578] [TRACE  ] [IN ]: Ble clear buffer
2015-09-18 10:27:32.731 xctest[94852:4603578] [DEBUG  ] [OUT]: Sending 3 bytes
2015-09-18 10:27:32.731 xctest[94852:4603578] [TRACE  ] [OUT]: Send: A [0x41] . [0x82]   [0x20]
2015-09-18 10:27:32.731 xctest[94852:4603578] [TRACE  ] [OUT]: BLE sending bytes range from 0 length 3
2015-09-18 10:27:32.732 xctest[94852:4603578] [DEBUG  ] [IN ]: Reading 1 bytes ...
2015-09-18 10:27:32.732 xctest[94852:4603578] [TRACE  ] [IN ]: Start reading
2015-09-18 10:27:32.786 xctest[94852:4603627] [TRACE  ] [IN ]: Rx value received 1 bytes: . [0x00]
2015-09-18 10:27:32.786 xctest[94852:4603627] [TRACE  ] [IN ]: Ignoring single 0x00 char
2015-09-18 10:27:32.787 xctest[94852:4603627] [TRACE  ] [IN ]: Rx value received 3 bytes: . [0x14] . [0x04] . [0x10]
2015-09-18 10:27:32.787 xctest[94852:4603627] [WARNING] [IN ]: Got 3 bytes in incoming buffer
2015-09-18 10:27:32.788 xctest[94852:4603578] [TRACE  ] [IN ]: Finish reading
2015-09-18 10:27:32.788 xctest[94

I was working for Mega2560 since it uses different bootloader and upload commands do not start from 'A'. It's definitely HM-10 firmware bug as it can understand it's not control command since the second byte is not 'T'.
If i had oscilloscope i'd find the reason in 1 hour but for casual engineering i don't need it. I've reported a bug to HM-10 manufacturer but i'm not sure when they fix it. HM-10 firmware version is v532.

The reset procedure for the Arduino Uno works this way:

If supported, toggle USB DTR/RTS or if not, open the Serial port at 1200 baud & close it
The Atmega8u2 or Atmega16u2 (which is acting as the USB-UART bridge) detects one of these two events, and pulls PD7 (which is capacitively coupled to the pulled-up reset pin on the main Atmega328 IC) low, causing a low pulse on the reset pin, putting the Uno into bootloader mode.

Although microcontrollers do generally have a register which records the reset event reason (for example brownout detect, watchdog timer overflow, power-on reset or external reset) to allow for differentiation in startup routines, this isn't at play here because the Atmega328 can't know whether it was the Atmega8/16u2 which pulled the line low, or if you did it, or if it was a very focused beam of ionising radiation from outer space.
With this in mind, there are two possible reasons for the problem you are having:

The reset isn't actually happening. You can write your own code that has a particular startup routine to detect this, along with watching the reset pin with a scope to observe the pulse.
The onboard bootloader timeout is kicking in before you are passing data to it. From looking at the optiboot code (and the makefiles in the Arduino Github repo) it seems that you have a timeout of 1 second from reset to pass your first valid character to the bootloader. This is longer for other boards (8 seconds for the Arduino Leonardo, for example). Are you certain that you are getting data there that fast?

If the issue is a timing one (and you can't improve your timing), you could always consider flashing your own compiled version of Optiboot based on the Arduino makefile options for the atmega328 target but with an additional -DTIMEOUT_MS=XXXX in the CFLAGS definition, where XXXX is the timeout in ms chosen from the supported list of 500, 1000, 2000, 4000, 8000.

thank for the explanation. i'm not sure about 1200 baud rate magic. in arduino ide source code it just sets DTR/RTS to 1 and 0 in 50 ms and that's enough to reset the board. it's almost the same way i'm making Uno to reset (but i use HM-10 PIO as DTR with the same reset schematics). I'm 100% sure it actually reset and i can see 'hello' which runs in setup() in uploaded arduino sketch. what about timeout this can be the reason (i've updated the question with log). But this is the way i upload successfully to Mega2560. So you think arduino does not remember/know how reset was initiated?

i've updated the task with uploading over USB log. You can see after Send: A [0x41] . [0x81]   [0x20] interaction continues in contrast to uploading over BLE

Hmmm, interesting. The 1200 baud rate definitely works (just checked) but there seem to be two separate mechanisms it can use. In any case it is of no use to you here. The Mega2560 uses a different bootloader, but it also seems to have a 1 second timeout. The Atmega328 does remember how it was reset, but only between options such as brownout detect, watchdog timeout, new power on and external reset - it can't tell the difference between different resets using the external pin.

what command should be invoked within 1 second to let bootloader know it should not start the app and uploading is going to happen?

what about this optiboot source code snippet: // Adaboot no-wait mod   ch = MCUSR;   MCUSR = 0;   if (!(ch & _BV(EXTRF))) appStart(); it seems that in MCU status register EXTRF bit should be set to 1. who sets it?

The command to be sent is any command valid within the optiboot bootloader protocol. And if you take a look at the Atmega328 datasheet you'll see that Figure 10-1 shows the reset logic and the source of the 4 reset source bits in the MCU status register. That is to say that the Atmega328 sets that bit because it detected a reset event at the RESET pin.

ok, any suggestions what's the difference now between USB reset and BLE reset?

None - you can see that by observing that all resets via the reset pin set the EXTRF bit and so start the bootloader. The "USB reset" is just an external reset performed via an Atmega4/8u2. You can also see that you are entering the bootloader by observing the onboard LED flash when you trigger the BT Smart reset. Please read the datasheet carefully - I'm not here to tell you what is in it.

i'm not asking you what is in datasheet now: 'ok, any suggestions what's the difference now between USB reset and BLE reset?'. In fact you did not suggest any significant to help unfortunately

Let us continue this discussion in chat.

i've recompiled optiboot with 8 seconds wdt timeout (i'm sure it's 8 seconds actually as i should wait 8 seconds in Arduino IDE terminal now) and it does not help. i still have no response to Send: A [0x41] . [0x81]   [0x20]

Have you checked with a scope at the RX pin of the Atmega to see if the characters are actually arriving?

unfortunately i don't have a scope, but i've modified bootloader source code like this: if(ch == STK_GET_PARAMETER) {       flash_led(2); to see using LED if characters are arriving and 0x41 has arrived. i can see it blinks. also i've commendted #if LED_START_FLASHES > 0 block in order not to get LED blinking for that reason

In that case, without a scope I would continue using coded LED flashes to show you which blocks of code are / are not being executed so you can see where the error lies. This kind of debug is much easier with a scope or logic analyser, but your way will work. You could also try bootloading over USB to compare differences between the two approaches.

agree. i've updated my question with 'Update 3'.

how can i increase blink time?  it blinks so fast that i can't count how much times it blinks.

Take a look at the implementation of flash_led(). Is it using a WDT or other timeout? Or is it synchronous? Modify accordingly, or write your own function to replace it.

http://stackoverflow.com/questions/32599984/how-to-increase-optiboot-flash-led-time

authors: اسماعيل ابو عصيدة


text:
How to print a line with a variable in it?
I want to know if there is a way to write like in C programming:
  printf("the num is %d",num);

I know that to print a line or a variable the command will be Serial.println
when I write:
 Serial.println("the num is %d",num);

It's not working.
Is there a way to write it in just one line?

Serial.print("the num is "); Serial.println(num);

is how you do it with the Serial object. There is a printf in the library and it's a lot easier to use (as you already know) but a little bit more work to set up. Here is a simple program using printf:
// Define a file descriptor for the serial output:
static FILE uartout = { 0 };

// Declare our put-character function:
static int uart_putchar (char c, FILE *stream);

void setup() {
   // Fill in UART file descriptor with pointer to my char-out func.
   fdev_setup_stream(&uartout, uart_putchar, NULL, _FDEV_SETUP_WRITE);
   stdout = &uartout;

   Serial.begin(9600);   // open serial port, sets baud rate
}

void loop( void ){
   printf("Run time: %ld\n", millis());
   delay(1000);          // wait 1 sec
}

// My char output function
static int uart_putchar (char c, FILE *stream)
{
   if( c == '\n' )
      Serial.write('\r');
   Serial.write(c) ;
   return 0 ;
}

That's a nasty way to print a single text line.

For just one line? Of course it is!

right; for some reason I really didn't consider it could be useful when called many times

I use:
Serial.println("The temperature is " + String(temperature) + " degrees C");

With this solution you can't format the variable's value but I find this quick and dirty for debug messages.

I use it too and i think it's the easiest way.

You can try "extending" the Print class to include a printf() function.  It requires modification of the Arduino core to add it, and it's something I have been meaning to suggest to the Arduino guys as a permanent modification, but I often manually add a function such as this:
void Print::printf(const char *fmt, ...) {
    va_list va;
    va_start(va, fmt);
    char temp[1];
    uint32_t slen = vsnprintf(temp, 1, fmt, va);
    va_end(va);
    char out[slen + 2];
    va_start(va, fmt);
    vsnprintf(out, slen+1, fmt, va);
    va_end(va);
    print(out);
}

to my core.
It's not wonderfully efficient from a processing point of view - it first runs a vsnprintf() to a single byte target.  This allows it to work out how long the formatted string will need to be:

If the output was truncated due to this limit, then the return value is the number of characters (excluding the terminating null byte) which would have been written to the final string if enough space had been available.

So it then knows how much memory is needed to store the formatted string.  It then goes ahead and allocates that much memory on the stack and re-formats the string again into that newly allocated memory.  It can then go ahead and send that data to the serial port.
It's a "quick and dirty" hack, but it works.  A better solution would be to re-write the printf() parser in the function and instead of formatting to memory then printing, to format the data stream directly to the Serial device, thus saving the double-processing and memory allocation.
You can then quite happily do things like:
Serial.printf("The temperature is %d degrees C\n", temperature);


text:
How to calculate voltage?
I want to check each cell voltage using arduino.
and how to calculate dc current using CT Sensor using Arduino?

Is it a Mini or a Leonardo?

You have two problems here:

How to take 24 readings on an Arduino with only 6 analog inputs.
How to get the voltage in the range of 0 to 5 volts.

To take 24 readings you can use an analog multiplexer or two. For example the 74HC4051 (8 channels) or the 74HC4067 (16 channels). With both of those you could handle 24 channels.

To read the voltages you could successively read each cell, relative to ground (eg. the first one should be 2 V, the second should be 4 V, and so on up to 48 V).
Cells 1 and 2 are fine, they are lower than 5 V. Cells 3 to 24 are not. You need to set up a voltage divider to divide down the voltage into the range 0 to 5.
The formula for a voltage divider is:
Vout = Vin * R2/(R1+R2)

Let's make R1 to be 10k ohms, and solve for R2 (given that we want Vout to be 5).
R2 = Vout * R1/(Vin - Vout)
R2 = 5 * 10000 / (Vin - 5)

Plugging that into a spreadsheet we get:
Vin    R
6  50000
8  16667
10 10000
12  7143
14  5556
16  4545
18  3846
20  3333
22  2941
24  2632
26  2381
28  2174
30  2000
32  1852
34  1724
36  1613
38  1515
40  1429
42  1351
44  1282
46  1220
48  1163

These aren't particularly easy resistor values to work with, so we'll use standard values and calculate what the output voltage should be (with the spreadsheet):
Vin   R   volts   Scale
2
4
6   47000 4.9474  1.2128    <--- R2 is 47 k
8   16000 4.9231  1.6250    <--- R4 is 16 k
10  10000 5.0000  2.0000
12   6800 4.8571  2.4706
14   5100 4.7285  2.9608
16   4300 4.8112  3.3256
18   3600 4.7647  3.7778
20   3300 4.9624  4.0303
22   2700 4.6772  4.7037
24   2400 4.6452  5.1667
26   2200 4.6885  5.5455
28   2000 4.6667  6.0000
30   2000 5.0000  6.0000
32   1800 4.8814  6.5556
34   1600 4.6897  7.2500
36   1600 4.9655  7.2500
38   1500 4.9565  7.6667
40   1300 4.6018  8.6923
42   1300 4.8319  8.6923
44   1200 4.7143  9.3333
46   1200 4.9286  9.3333
48   1100 4.7568 10.0909

The "Scale" column will be explained in a moment.

Now we are ready to make up a circuit along these lines:

I haven't shown all the battery cells here - I don't have that much energy! But the principle is the same.

The 2V and 4V inputs we can read directly. From 6V upwards we need to apply the scaling factor from the voltage divider network.
That is shown in the "Scale" column above.
The formula for the voltage on the pin is:
float voltage = ((float) rawADC  + 0.5 ) / 1024.0 * Vref;

So assuming Vref is 5V, and you have a reading of 512, then you apply it like this:
 ( 512  + 0.5 ) / 1024.0 * 5 = 2.502 volts

Now you multiply by the scale factor above, so if this was the 34 V input, the scale factor would be 7.25, and the voltage from the battery would be:
2.502 * 7.25 = 18.14  volts

The stage is now set to work out each voltage:

Use the multiplexer "select" pins to choose one of the battery inputs
Take an analog reading
Scale it by the appropriate amount from the table
Work out what the charge in the cell is (by comparing it to the previous one)

For example, if the first cell read 1.9V and the second cell read 3.85V then you know that the difference is 3.85 - 1.9 which is 1.95 volts.

Thanks Nick for your great answer...!! :) Can you help me to calculate dc current using CT Sensor using Arduino?

I don't know much about CT sensors, but does a page like CT sensors - Interfacing with an Arduino not help?


text:
Output to LCD is sometimes shifted to the side
I have an Arduino Uno connected to a LCD. When I try to write to it using the LCD library and the following sketch, it will keep shifting the output around, sometimes drastically.
The sketch:
#include <LiquidCrystal.h>

LiquidCrystal lcd(12, 10, 11, 9, 8, 7, 6, 5, 4, 3, 2);

void setup ()
{
  lcd.begin (16, 2);
}

void loop ()
{
  lcd.clear ();
  lcd.home ();

  for (int i = 0; i < 2; i++)
  {
    for (int j = 0; j < 16; j++)
    {
      lcd.setCursor (j, i);
      lcd.print ("s");
    }
  }

  delay (1000);
}

You would expect it to print

SSSSSSSSSSSSSSSS
SSSSSSSSSSSSSSSS

But it will often print

SSSSSSSSSSSSSSS
SSSSSSSSSSSSSSS

As in, it skips the first line. And, occasionally, it will even print like this:

SSSSSSSSSSS
SSSSSSSSSSS

Is it the LCD's fault, or might there be something wrong with the way it is connected?
EDIT:
It is a common Hitachi HD44780-compatible LCD.
EDIT 2:
 Hopefully it is correctly wired up.

I don't understand that wiring.  What is that regulator doing over to the right, and what is it supposed to be wired to? Where is the power for the LCD coming from?  Where is the contrast trimmer?

@Majenko The regulator was meant to represent the power. I used that mistakenly (first time using Fritzing. Or doing schematics for that matter). I am not sure how to show the power coming in the breadboard view... What do you mean by contrast trimmer? AFAIK those are all the wire coming out of the LCD.

@Majenko Hopefully the new image makes more sense

Is that actually what you're powering the LCD from? Or are you really using a regulated 5V supply?

It is a regulated 5V supply. I just don't know how to show that in Fritzing

Ok, one last question before I conclude that I don't have a clue what's happening with your system:  What wire are you using to wire it all up? Type / length / connections, etc.

Er, dunno, standard wires? Like these: http://i.stack.imgur.com/y7eu5.jpg

Ok, I have exhausted all the ideas I have at the moment as to why it may not communicate 100%.  It may be down to the LCD possibly - try introducing small delays into your loop - maybe a ms or so after the setCursor - or try doing the setCursor twice in a row.

I had already tried that. It is most likely the LCD's fault, I just wanted to check for any oversight on my parts. Thanks for the help though.

Try running some example programs. If they work as expected, your LCD is not at fault. Try to use the example wiring (12, 11, 5, 4, 3, 2) and don't forget the contrast POT. Why aren't you supplying power (+5V) from the Arduino itself?

Why do all those lcd.setCursor? You cleared the screen, the library should write each letter next to the previous one.

@MKII Printing the same character over and over ("S", in your case) may be hiding some quirk of the LCD. Change the output line to lcd.print ((char) 65 + (32 * i) + j); . This will print capital letters (from 'A') on the top line and the lowercase equivalents on the bottom - that way you'll know immediately if it's shifting left or cuttting off the right.


text:
Serial comms failure after long time - can't open COM port
I've been using an Arduino UNO to log data: it's queried by a LabView VI over a VISA connection. It'll happily sit there and log for days, but very occasionally one of the VISA functions will fail.
After this, I can't open the COM port again (in LabView or elsewhere) and the only way to restore communication is to unplug and replug the USB cable. The Arduino hasn't crashed because I can see the other results of the program it's running working fine, but Serial comms are a gonner.
Has anyone experienced this? Do you know if this is an Arduino problem, a Labview problem, a Windows problem? Or something else?
I'm writing a minimum working example to try and catch this happening in the most simple code possible, but since the error usually takes several days to show up I can't tell you the results yet!

Which Arduino?

Good point: it's an Uno

In the end I found a solution, more or less through trial and error.
Labview default its VISA VIs to "asynchronous" mode: I found that by switching them to "synchronous" (right click on them and select "synchronous") this problem disappeared.
I think this is caused by the computer occasionally getting ahead of the Arduino and asking for the next measurement before it's finished receiving the first one. Switching to synchronous mode forces execution to wait until the VISA exchange is complete before it continues.

Good Job. That is a tough one to fine!

The assumption I am making is "VISA connection" is a PC operating VISA.
I have seen ports shut down on windows several times yet the same port works fine while in DOS.  My suggestion is try a different computer, that should narrow down your problem to which side of the connector is failing.

Cheers Gil, I did give it a shot on another computer and the problem was still there though. In the end I found a solution, I'll add it as an answer.