message:
Adafruit_NeoPixel define pin for different setups

I am looking for a way of defining multiple pins for my RGB strips. Currently the defined variable is set with the pin within it. This works just fine if I only had one RGB strip connected to the Arduino but I have 4 so I will need to define.

I currently run this code here:

    #include <Adafruit_NeoPixel.h>
    #include <avr/power.h>

    int rgb1 = 18;
    int rgb2 = 17;
    int LEDs = 11;
    int ledFadeTime = 5;

    Adafruit_NeoPixel strip1 = Adafruit_NeoPixel(LEDs, rgb1, NEO_GRB + NEO_KHZ800);
    Adafruit_NeoPixel strip2 = Adafruit_NeoPixel(LEDs, rgb2, NEO_GRB + NEO_KHZ800);

    void setup() {
      strip1.begin();
      strip1.show(); // Initialize all pixels to 'off'
      strip2.begin();
      strip2.show(); // Initialize all pixels to 'off'
    }

    void loop() {
      rgbFadeInAndOutStrip1(0, 0, 255, ledFadeTime); // Blue
      rgbFadeInAndOutStrip2(255, 0, 0, ledFadeTime); // red
    }

    void rgbFadeInAndOutStrip1(uint8_t red, uint8_t green, uint8_t blue, uint8_t wait) {
      for(uint8_t b = 0; b <255; b++) {
         for(uint8_t i=0; i < strip1.numPixels(); i++) {
            strip1.setPixelColor(i, red * b/255, green * b/255, blue * b/255);
         }

         strip1.show();
         delay(wait);
      };

      for(uint8_t b=255; b > 0; b--) {
         for(uint8_t i = 0; i < strip1.numPixels(); i++) {
            strip1.setPixelColor(i, red * b/255, green * b/255, blue * b/255);
         }
         strip1.show();
         delay(wait);
      };
    };

    void rgbFadeInAndOutStrip2(uint8_t red, uint8_t green, uint8_t blue, uint8_t wait) {
      for(uint8_t b = 0; b <255; b++) {
         for(uint8_t i=0; i < strip2.numPixels(); i++) {
            strip2.setPixelColor(i, red * b/255, green * b/255, blue * b/255);
         }

         strip2.show();
         delay(wait);
      };

      for(uint8_t b=255; b > 0; b--) {
         for(uint8_t i = 0; i < strip2.numPixels(); i++) {
            strip2.setPixelColor(i, red * b/255, green * b/255, blue * b/255);
         }
         strip2.show();
         delay(wait);
      };
    };

Which works when trying out just one out of the 2. But when the LEDs fade out it has a pause (i still see a hint of blue on the strip). If i comment all the code out for the second strip2 and run that, it pulses just fine without the hint of blue or the delay to start bright again.

What could I be doing incorrectly?

body:
The “hint of blue on the strip” is a consequence of your second loop in `rgbFadeInAndOutStrip1()` ending with the test `b > 0`.  Because of that, the last `strip1.setPixelColor()` call sets the color to (0,0,1), a faint blue, instead of (0,0,0), off.  Here is some revised code that works ok:

    #include <Adafruit_NeoPixel.h>
    #include <avr/power.h>
    enum { rgbPin1=8, rgbPin2=7, LEDcount=11, ledFadeTime=5};

    Adafruit_NeoPixel strip1 = Adafruit_NeoPixel(LEDcount, rgbPin1);
    Adafruit_NeoPixel strip2 = Adafruit_NeoPixel(LEDcount, rgbPin2);

    void setup() {
      strip1.begin();
      strip1.show(); // Initialize all pixels to 'off'
      strip2.begin();
      strip2.show(); // Initialize all pixels to 'off'
    }

    void loop() {
      rgbFadeInAndOutStrip1(0, 0, 255, ledFadeTime); // Blue
      rgbFadeInAndOutStrip2(255, 0, 0, ledFadeTime); // red
    }

    void fadeStrip(Adafruit_NeoPixel *strip, int bval, int bdir, uint8_t red, uint8_t green, uint8_t blue, uint8_t wait) {
      for(uint8_t b=0; b<255; ++b) {
        bval += bdir;
        for(uint8_t i=0; i<strip->numPixels(); ++i) {
          strip->setPixelColor(i, red * bval/255, green * bval/255, blue * bval/255);
        }
        strip->show();
        delay(wait);
      }
    }

    void rgbFadeInAndOutStrip1(uint8_t red, uint8_t green, uint8_t blue, uint8_t wait) {
      fadeStrip(&strip1, -1, 1,   red, green, blue, wait);
      fadeStrip(&strip1, 255, -1, red, green, blue, wait);
    }

    void rgbFadeInAndOutStrip2(uint8_t red, uint8_t green, uint8_t blue, uint8_t wait) {
      fadeStrip(&strip2, -1, 1,   red, green, blue, wait);
      fadeStrip(&strip2, 255, -1, red, green, blue, wait);
    }

Note, since I ran tests on an Uno rather than a Leonardo, I attached pixel strings to pins 7 and 8 rather than 17 and 18.  I used `enum` to define constants, rather than declaring constants as variables, and factored some common code into functions rather than reduplicating it.

Following is another program (which I call neocycle6) you can use to test two strips.  Note, it only counts colors down to 1 rather than 0 because I like the effect of leftover pixels glowing faintly.  Also note: the round boards I used have only 7 LEDs each, so I set `PixelCount` to 7, not 11; this uses pins 7 and 8, not 17 and 18; I don't drive the brightness beyond 77 since the LEDs are so bright anyway; and it doesn't have an
`#include <avr/power.h>` statement, which you can add if needed.

    // Drive 2 sets of 7 ea. WS2812 NeoPixels through sets of colors.
    // jw 11 September 2015
    #include <Adafruit_NeoPixel.h>

    // Select pin# connected to NeoPixels strand, and number of NeoPixels.
    enum { PixelPinA=7, PixelPinB=8, PixelCount=7 };
    // Create a NeoPixels device structure
    Adafruit_NeoPixel pixelA = Adafruit_NeoPixel(PixelCount, PixelPinA);
    Adafruit_NeoPixel pixelB = Adafruit_NeoPixel(PixelCount, PixelPinB);

    void setup() {
      byte i, j=0;
      pixelA.begin();               // Init. NeoPixel data structure
      pixelB.begin();               // Init. NeoPixel data structure
    }

    uint8_t c=1, d=1, p=0, v=1;
    void loop() {
      c += d;
      if (c>76)
        d = -1;                     // Go down when done going up
      else {
        if (c<2) {                  // Set up for next pixel
          d = 1; p = (p+1)%PixelCount;
          if (!p) ++v;              // Rotate the weights to next color
        }
      }

      pixelA.setPixelColor(p, c*(v&1), c*((v&2)/2), c*((v&4)/4));
      pixelB.setPixelColor(p, c*((v&2)/2), c*(v&1), c*((v&4)/4));
      pixelA.show();               // Show updated colors
      pixelB.show();               // Show updated colors
      delay(9 + 300/c);            // Ramp small numbers more slowly
    }


sender: user

message:
How to Store 2 analogRead values and read using EEPROM for Arduino Uno?

Trying to write 2 values coming from `analogread(A0)` and `analogread(A1)` by `EEPROM.write`  and retrieve the values by `EEPROM.read`. I tried the following sketch for each write and read. However, could not get the values. Any help please.

For writing to EEPROM:

    #include <EEPROMex.h>
    int addr = 0;
    int array[] = {0, 0};
    char a;
    void setup() {
    }
    void loop() {
     array[0] = analogRead(0) / 4;
     array[1] = analogRead(1) / 4;
     EEPROM.write(addr, a);
     addr = addr + 1;

     if (addr == 512) {
      addr = 0;
     }

     delay(100);
    }

For reading from EEPROM is:

    #include <EEPROM.h>
    int address = 0;
    int value[2];
    void setup() {
     Serial.begin(9600);

     while (!Serial) {
      ;
     }
    }
    void loop() {
     value = EEPROM.read(address);
     Serial.print(address);
     Serial.print("\t");
     Serial.print(value[0]);
     Serial.print("\t");
     Serial.print(value[1]);
     Serial.println();
     address = address + 1;

     if (address == 512) {
      address == 0;
     }

     delay(500);
    }

sender: assistant

body:
You write the read value directly to `value`, while value is actually and array. Try this instead.

    void loop() {
     value[0] = EEPROM.read(address);
     value[1] = EEPROM.read(address + 1);
     Serial.print(address);
     Serial.print("\t");
     Serial.print(value[0]);
     Serial.print("\t");
     Serial.print(value[1]);
     Serial.println();
     address = address + 2;

     if (address == 512) {
      address = 0;
     } // not address==0;

     delay(500);
    }


body:
<!-- language-all: lang-C++ -->

See [Reading and Writing Data Structures to EEPROM](http://playground.arduino.cc/Code/EEPROMWriteAnything).

    EEPROM.write(addr,a);

You can't *directly* write arrays. See the link for how to do it.

Example code:

    #include <EEPROM.h>
    #include <EEPROMAnything.h>

    int array[2];
    int addr=0;

    void setup()
    {
    }

    void loop()
    {
      array[0] = analogRead(0)/4;
      array[1] = analogRead(1)/4;
      EEPROM_writeAnything(addr, array);
      addr += sizeof (array);

      if(addr >= 512)
        exit (1);

      delay(100);
    }

Your posted code is a bit flawed anyway. You know EEPROM has a limited life? If you have a sketch that writes to EEPROM indefinitely you will wear it out.

My code above stops once it reaches address 512.


body:
EEPROM can store one byte at a location. To store value of int, it requires two consecutive location. For double, it requires four memory location. I have written code to store and read, int & double to and from built-in EEPROM. Modify as per your need.

    /*
      StackExchange Question: "How to Store 2 analogRead values and read using EEPROM for Arduino uno?"
      Question Id: 15910 (http://arduino.stackexchange.com/questions/15910/how-to-store-2-analogread-values-and-read-using-eeprom-for-arduino-uno)
      Author: Anurag S. Vasanwala (AnuragVasanwala@gmail.com)

      Tested on Arduino Version 1.6.7

      Description:  This sketch helps to store and read, Integer & Double to and from built-in EEPROM.
      Objectives:
        + Write Integer @ Specified Address (Fn: EEPROM_Write_Int)
          + Conversion from Integer to Byte Array
          + Store Bytes
        + Read Integer from Specified Address (Fn: EEPROM_Read_Int)
          + Read Bytes
          + Conversion from Byte Array to Integer
        + Write Double @ Specified Address (Fn: EEPROM_Write_Double)
          + Conversion from Double to Byte Array
          + Store Bytes
        + Read Double from Specified Address (Fn: EEPROM_Read_Double)
          + Read Bytes
          + Conversion from Byte Array to Double
     */
    #include <EEPROM.h>

    // MACRO : Combines FROM_BYTES into TO_OBJECT of datatype "DATATYPE"
    #define CombineBytes(FROM_BYTES, DATATYPE, TO_OBJECT) \
      TO_OBJECT = *((DATATYPE *)FROM_BYTES);

    // MACRO : Splits FROM_DATA of DATATYPE into equivalent byte array TO_BYTES
    #define GetBytes(FROM_DATA, DATATYPE, TO_BYTES) \
      *((DATATYPE *)TO_BYTES) = FROM_DATA;

    // Writes Integer's equivalent bytes to Address and Address + 1
    void EEPROM_Write_Int(unsigned int Address, int Data)
    {
      // Get the size of datatype to write number of bytes
      const byte SizeOf_DataType = sizeof(int);

      // Create tem buffer to get Bytes of Datatype
      byte Temp_Buffer[SizeOf_DataType];

      // Call macro to store byte array into Temp_Buffer from Data
      GetBytes(Data, int, Temp_Buffer);

      // Write number of bytes to memory location specified in Address and so on
      for(byte Index = 0; Index < SizeOf_DataType; Index++)
      {
        EEPROM.write(Address + Index, Temp_Buffer[Index]);
      }
    }

    // Reads two bytes from Address and Address + 1 and returns equivalent int
    int EEPROM_Read_Int(unsigned int Address)
    {
      // Get the size of datatype to write number of bytes
      const byte SizeOf_DataType = sizeof(int);

      // Create tem buffer to get Bytes of Datatype
      byte Temp_Buffer[SizeOf_DataType];

      int Result;

      // Read number of bytes from memory location
      for(byte Index = 0; Index < SizeOf_DataType; Index++)
      {
        Temp_Buffer[Index] = EEPROM.read(Address + Index);
      }

      // Call macro to combine bytes into equivalent to int
      CombineBytes(Temp_Buffer, int, Result);

      return Result;
    }

    // Writes Double's equivalent bytes to Address, Address + 1, Address + 2 and Address + 3
    void EEPROM_Write_Double(unsigned int Address, double Data)
    {
      // Get the size of datatype to write number of bytes
      const byte SizeOf_DataType = sizeof(double);

      // Create tem buffer to get Bytes of Datatype
      byte Temp_Buffer[SizeOf_DataType];

      // Call macro to store byte array into Temp_Buffer from Data
      GetBytes(Data, double, Temp_Buffer);

      // Write number of bytes to memory location specified in Address and so on
      for(byte Index = 0; Index < SizeOf_DataType; Index++)
      {
        EEPROM.write(Address + Index, Temp_Buffer[Index]);
      }
    }

    // Reads four bytes from Address, Address + 1, Address + 2 and Address + 3 and returns equivalent double
    double EEPROM_Read_Double(unsigned int Address)
    {
      // Get the size of datatype to write number of bytes
      const byte SizeOf_DataType = sizeof(double);

      // Create tem buffer to get Bytes of Datatype
      byte Temp_Buffer[SizeOf_DataType];

      double Result;

      // Read number of bytes from memory location
      for(byte Index = 0; Index < SizeOf_DataType; Index++)
      {
        Temp_Buffer[Index] = EEPROM.read(Address + Index);
      }

      // Call macro to combine bytes into equivalent to double
      CombineBytes(Temp_Buffer, double, Result);

      return Result;
    }

    void setup()
    {
      // Initialize Serial @ 9600 baud
      Serial.begin(9600);

      // Print size of datatype just for reference
      /* Serial.print("Size of byte = ");
      Serial.println(sizeof(byte));
      Serial.print("Size of int = ");
      Serial.println(sizeof(int));
      Serial.print("Size of float = ");
      Serial.println(sizeof(float));
      Serial.print("Size of double = ");
      Serial.println(sizeof(double)); */

      int myInt1 = -290;
      int myInt2;
      double myDbl1 = 23.41;
      double myDbl2;

      // Write myInt1 @ 100 memory location; It requires 2 consequtive memory location to store integer
      EEPROM_Write_Int(100, myInt1);

      // Read integer located @ memory location 100 and assign it to myInt2
      myInt2 = EEPROM_Read_Int(100);
      Serial.println(myInt2);

      // Write myInt1 @ 200 memory location; it requires 4 consequtive memory location to store double
      EEPROM_Write_Double(200, myDbl1);

      // Read double located @ memory location 200 and assign it to myDbl2
      myDbl2 = EEPROM_Read_Double(200);
      Serial.println(myDbl2);
    }

    void loop()
    {

    }

> This code is successfully tested on Arduino Version "1.6.7".


message:
Function not successfully reading sensor registers

I'm trying to write a library for an accelerometer/magnetometer sensor.  The sensor is a LSM303D chip (https://www.pololu.com/file/0J703/LSM303D.pdf).

I've written a function, `readRegister()` (below) that's supposed to get the data from the sensor.  However, I put in many different registers into the function into the function, but it always returns the same number.  That number changes every time I unplug my Arduino from my computer.

    byte fp::readRegister(byte register_address, int numBytes) {
      Wire.requestFrom(register_address, numBytes);
      byte c;
      Serial.println(Wire.read());
      while (Wire.available()) {
        c = Wire.read();
      }
      Serial.print("0x");
      Serial.print(register_address, HEX);
      Serial.print("\t");
      Serial.print(c);
      Serial.print("\t");
      Serial.println(millis());
      return c;
    }

Here's an example of the problem output:

    0x8 190 2
    0x9 190 3
    0xA 190 11

And here is something more like what I'd expect:

    0x8 193 [time]
    0x9 189 [time]
    0xA 195 [time]

Here is the Git repo with the rest of the code: https://github.com/fpdotmonkey/fp_accel

Thank you in advance for your help.

body:
<!-- language-all: lang-C++ -->

      Wire.requestFrom(register_address, numBytes);
      byte c;
      Serial.println(Wire.read());
      while (Wire.available()) {
        c = Wire.read();
      }

This has a number of problems. For one thing your (I presume) debugging print consumes the data from Wire.read, so when you go to get it into c, you have already printed it. In other words, you are reading byte #1 and printing it, but using byte #2. This seems an odd thing to do.

Next, what is this doing?

      while (Wire.available()) {
        c = Wire.read();
      }

You are reading an indefinite number of bytes, and retaining the last one. Why?

Possible rework:

    byte fp::readRegister(byte register_address, int numBytes) {
      Wire.requestFrom(register_address, numBytes);
      byte c = Wire.read()
      Serial.println(c);
      Serial.print("0x");
      Serial.print(register_address, HEX);
      Serial.print("\t");
      Serial.print(c);
      Serial.print("\t");
      Serial.println(millis());
      return c;
    }

---

> Here is the Git repo with the rest of the code: https://github.com/fpdotmonkey/fp_accel

From your linked code:

      byte xlm = readRegister(fp::OUT_X_L_M, 1);
      byte xhm = readRegister(fp::OUT_X_H_M, 1);
      byte ylm = readRegister(fp::OUT_Y_L_M, 1);
      byte yhm = readRegister(fp::OUT_Y_H_M, 1);
      byte zlm = readRegister(fp::OUT_Z_L_M, 1);
      byte zhm = readRegister(fp::OUT_Z_H_M, 1);

You have the wrong end of the stick here.

      Wire.requestFrom(register_address, numBytes);

You request from the **I2C address** - that is the device address. The register is something else.

Judging by the datasheet you first have to send the register address, and then request the data. Something along the lines of:

    byte fp::readRegister(byte register_address, int numBytes) {
      Wire.beginTransmission (DEVICE_ADDRESS);
      Wire.write (register_address);
      Wire.endTransmission (false);  // repeated start
      Wire.requestFrom(DEVICE_ADDRESS, 1);
      byte c = Wire.read()
      Serial.println(c);
      Serial.print("0x");
      Serial.print(register_address, HEX);
      Serial.print("\t");
      Serial.print(c);
      Serial.print("\t");
      Serial.println(millis());
      return c;
    }

Similarly for writing to a register:

    void fp::writeRegister(byte register_address, byte val) {
      Wire.beginTransmission(DEVICE_ADDRESS);
      Wire.write (register_address);
      Wire.write(val);
      Wire.endTransmission();
    }

This is untested because I don't have the device here, but I know that what you had won't work. To check the actual device address run the [I2C scanner](http://www.gammon.com.au/i2c) I mentioned before.


message:
Sampling rate issue

I have an Arduino code which runs decently.

    // Read in 10-bits Magnetic Encoder AEAT-6010-A06  into Arduino Uno
    // Sampling

    // Declarate

    const int CSn = 4; // Chip select
    const int CLK = 7; // Clock signal
    const int DO = 8; // Digital Output from the encoder which delivers me a 0 or 1, depending on the bar angle..
    int analogPin = 3;
    int val = 0;
    unsigned int sensorWaarde = 0;

    void setup() {
      Serial.begin(115200);
      //Fix de tris

      pinMode(CSn, OUTPUT);
      pinMode(CLK, OUTPUT);
      pinMode(DO, INPUT);

      //Let's start here
      digitalWrite(CLK, HIGH);
      digitalWrite(CSn, HIGH);
    }

    void loop() {

      val = analogRead(analogPin);
      // val = val - 670;
      sensorWaarde = readSensor();
      delayMicroseconds(1); //Tcs waiting for another read in
    }

    unsigned int readSensor() {
      unsigned int dataOut = 0;

      digitalWrite(CSn, LOW);
      delayMicroseconds(1); //Waiting for Tclkfe

      //Passing 10 times, from 0 to 9
      for (int x = 0; x < 10; x++) {
        digitalWrite(CLK, LOW);
        delayMicroseconds(1); //Tclk/2
        digitalWrite(CLK, HIGH);
        delayMicroseconds(1); //Tdo valid, like Tclk/2
        dataOut = (dataOut << 1) | digitalRead(DO); //shift all the entering data to the left and past the pin state to it. 1e bit is MSB
      }

      digitalWrite(CSn, HIGH); //
      Serial.print(dataOut);
      Serial.print("");
      Serial.print(" ");
      Serial.println(val);
      Serial.print(" ");

      delay(2);
      return dataOut;

    }

From the delay data i assumed that i will be having approximately a sampling rate of 500 Hz, however it seems that the sampling rate is approximately 300+- Hz, without a proper confirmation.

My system is to be run in a Magnetic Encoder by Avago, but i have difficulties determining the sampling rate.

If possible, may i know what code should i use to indicate the time and sampling number?

body:
<!-- language-all: lang-C++ -->

At 115200 baud your serial prints will take 1/11520 seconds per byte.

---

    Serial.print("");

What does that do?

---

I count 14 bytes here:

      Serial.print(dataOut);  // 5 bytes, say
      Serial.print("");       // zero bytes, lol
      Serial.print(" ");      // one byte
      Serial.println(val);    // 5 bytes + cr/lf = 7 bytes
      Serial.print(" ");      // 1 byte

Multiply 1/11520 (0.0000868) by 14 and you get 1215 µs.

---

Now add in your delays:

      delay(2);  // 2000 µs

---

And this:

     for (int x = 0; x < 10; x++) {
        ...
        delayMicroseconds(1); //Tclk/2
        ...
        delayMicroseconds(1); //Tdo valid, like Tclk/2
      }

Another 20 µs.

---

      val = analogRead(analogPin);   // 104 µs
      ...
      delayMicroseconds(1); // 1 µs

---

Total:

    1215 + 2000 + 20 + 104 + 1 = 3340 µs

Inverse:

    1 / 0.003340 = 299

---

So yes, I would expect around 299 iterations per second. That isn't counting the time for the other code to execute.

---

### Suggestions

* Get rid of the serial prints
* Get rid of `delay(2)`


message:
Control servo motors with buttons and via web application

I have this assignment and I have been tinkering a long time about it. I need to make a simulation of a parking lot where servos would represent the ramps.

I will be using 2 Arduinos running the same script, one representing the entry ramp and the other one the exit.
Servos are controlled by reading a json request of an web application and manually by buttons. I have connected two LED's when the buttons are pressed. I would also need to make state when servo would be always up or always down (that would represent the off times of parking lot), should I add extra buttons for that? Any idea would be appreciated.

The problem I'm having with this project is that servos are not responding well on push buttons. They are shaking and very slow moving. And I think that it isn't a good solution to move the servos while they are sending application request because it can lead to conflict. Please help me there.

I have written pretty major piece of script, but it still needs adjusments. Any help is welcomed.
Here is the code:

    #include<Servo.h>
    #include<Ethernet.h>
    #include <SPI.h>

    Servo myservo;
    byte mac[] = { 0xDE, 0xAD, 0xBE, 0xEF, 0xFE, 0xED };
    char server[] = "ramp-rampcontrol.rhcloud.com";
    EthernetClient client;
    IPAddress ip(192,168,1,17);

    int button_5 = 5;
    int button_6 = 6;
    const int ledPin = 3;
    const int ledPinG = 2;
    int time = 5*1000;
    int val=0;
    String content = "";
    boolean begin1 = false;

    void setup() {

    Serial.begin(9600);
    pinMode(button_5, INPUT);
    pinMode(button_6, INPUT);
    pinMode(ledPin, OUTPUT);
    pinMode(ledPinG, OUTPUT);
    myservo.attach(9);
    if (Ethernet.begin(mac) == 0) {
    Serial.println("Failed to configure Ethernet using DHCP");
    // no point in carrying on, so do nothing forevermore:
    // try to congifure using IP address instead of DHCP:
    Ethernet.begin(mac, ip);
    }
    // give the Ethernet shield a second to initialize:
    delay(1000);
    Serial.println("connecting...");

    // if you get a connection, report back via serial:
    if (client.connect(server, 80)) {
    Serial.println("connected");
    // Make a HTTP request:
    client.println("GET /api/actions?parking_id=39 HTTP/1.1");
    client.println("Host: ramp-rampcontrol.rhcloud.com");
    client.println("Connection: close");
    client.println();
    }
    else {
    // kf you didn't get a connection to the server:
    Serial.println("connection failed");
     }
    }

    void loop()
    {

    val = digitalRead(button_5);
    if (val == HIGH)
    {
      performServoAction("up");

          digitalWrite(ledPin, HIGH);
          delay(1000);
          digitalWrite(ledPin, LOW);
          delay(1000);

    }

    val = digitalRead(button_6);
    if (val == HIGH)
    {
      performServoAction("down");

          digitalWrite(ledPinG, HIGH);
          delay(1000);
          digitalWrite(ledPinG, LOW);
          delay(1000);
     }

     while(client.available()) {
     char c = client.read();
        if(c == '{'){
          begin1 = true;
        }

      if (begin1) {
        content += c;
       }

      if (c == '}') {
          break;
        }
     }

      if (!client.connected()) {
        Serial.println();
        Serial.println("disconnecting.");
        client.stop();
        performAction();
      }
      }

    bool performServoAction(String action_type) {
    if (action_type == "up") {
        Serial.println("doing up");
        myservo.write(95);
        delay(time);
       // lastRampStatus = action_type ;
       // notifyServerAboutAction("true", action_id);
        return true;
      }

      if (action_type == "down") {
        Serial.println("doing down");
        myservo.write(135);
        delay(time);
        //lastRampStatus = action_type;
      // notifyServerAboutAction("true", action_id);
        return true;
      }
    }

     void performAction() {
      int nstart = content.indexOf("action_id") + 12;
      int nend = content.indexOf(",", nstart);
      String actionID = content.substring(nstart, nend);

        int nstart1 = content.indexOf("action_type") + 14;
       //Get position of "action_type" in a string, increment by 13
        (length of 'action_type":"')
        int nend1 = content.indexOf("\"", nstart1); // Get next position
        of '"' starting from nstart
        String actionType = content.substring(nstart1, nend1);
        //Return substring between this position
        performServoAction(actionType);
        Serial.println(nstart1);
        Serial.println(nend1);
        Serial.println(actionID);
        Serial.println(actionType);
        Serial.println(content);
    }

body:
Instead of using:

`myservo.write(135);`

You should use:

`myservo.writeMicroseconds();`

https://www.arduino.cc/en/Reference/ServoWriteMicroseconds


message:
Why when I press the reset button

it takes 2 second before I see my sketch start?
The model of Arduino is UNO, and the text in serial communication.

body: Because first the bootloader is executed and takes 2 seconds (or more on a Leonardo) to time out when it doesn't receive a proper response from the computer.


message:
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][1].

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.

[1]: https://www.arduino.cc/en/Guide/ArduinoMini

body:
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][1] or [arduino.org][2] 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

[1]: https://www.arduino.cc/en/Guide/ArduinoMini
[2]: http://labs.arduino.org/Getting+Started+with+Arduino+Mini


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

body:
You should be able to use my [board detector](http://www.gammon.com.au/forum/?id=11633) sketch on one of your other Arduinos to check out the problem board.

See also <https://arduino.stackexchange.com/questions/13292/have-i-bricked-my-arduino-uno-problems-with-uploading-to-board>

Also my [bootloader uploader](http://www.gammon.com.au/bootloader) 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.


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

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


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

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

<strike>Arduino's just are not fast enough for this.</strike> Arduino Yuns are typically more expensive.


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


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

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


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

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


message:
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 [![Oscilloscope image][1]][1]

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

 at 9600 Baud

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

[![RS232 - 3 letters][1]][1]

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

[![RS232 - one byte][2]][2]

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

[![One RS232 byte][3]][3]

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

---

Also see <https://arduino.stackexchange.com/questions/1569/what-is-serial-begin9600/>

  [1]: https://i.stack.imgur.com/sJ7kd.png
  [2]: https://i.stack.imgur.com/T6R1D.png
  [3]: https://i.stack.imgur.com/mQOaS.jpg


message:
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][1] 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][2] as requested.

  [1]: http://github.com/jeroendoggen/Arduino-MMA7361-library
  [2]: http://www.freescale.com/files/sensors/doc/data_sheet/MMA7361L.pdf

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


message:
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"*.

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

[![Pin 13 being flashed][1]][1]

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.

[![Optiboot upload process][2]][2]

*(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](https://github.com/Optiboot/optiboot)
* [AVR061: STK500 Communication Protocol](http://www.atmel.com/Images/doc2525.pdf)
* [AVR068: STK500 Communication Protocol version 2](http://www.atmel.com/Images/doc2591.pdf)
* <https://arduino.stackexchange.com/questions/13292/have-i-bricked-my-arduino-uno-problems-with-uploading-to-board>
* [AVR Downloader/UploaDEr - avrdude](http://savannah.nongnu.org/projects/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.

---

<!-- language-all: lang-C++ -->

## 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'

  [1]: https://i.stack.imgur.com/py9om.png
  [2]: https://i.stack.imgur.com/9htH8.png


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

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


body:
In my opinion, a perfect solution for the "*As a PIN goes high I need to trigger an event*" problem is brought by **[interrupts][1]**. In the [official documentation][2] 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][3]) 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][4], 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][5] (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][6]. 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).

  [1]: https://en.wikipedia.org/wiki/Interrupt
  [2]: http://playground.arduino.cc/Code/Interrupts
  [3]: https://www.google.it/search?q=arduino interrupt handling&ie=utf-8
  [4]: http://gammon.com.au/interrupts
  [5]: https://en.wikipedia.org/wiki/Ethernet_frame
  [6]: https://www.google.it/search?q=perl client server example&ie=utf-8


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

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


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

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

 1. **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.
 2. **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.
 3. **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.


body:
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][1], using this library you can easily simulate your Ultrasonic sensor in Proteus and can design your code. It will save you from hardware testing.

  [1]: http://www.theengineeringprojects.com/2015/02/ultrasonic-sensor-library-proteus.html


message:
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'?

body:
The reset procedure for the Arduino Uno works this way:

1. If supported, toggle USB DTR/RTS or if not, open the Serial port at 1200 baud & close it
2. 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:

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

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