# Question
Title: how to build rc transmitter and receiver with an old rc transmitter
I've got an Arduino Mega, an Arduino Nano, two NRF24L01 wireless modules and a old Multiplex Transmitter system.

I want to get the PWM signal and send it to the other arduino which should control the servos and the motor controller.

Is there a good instruction or know somebody how to do that easily?

I need it for a rc plane and the range should be 1km.

# Answer
If you are controlling an RC plane, you should probably just buy a transmitter and receiver specifically designed for that. They are cheap and reliable and will generate PWM signals on their own.

If you must use an Arduino for some reason, NRF24L01 are not going to cut it as they are not powerful enough to reach 1 km. You should probably look into something like an XBee Series 1. With about 60 mW transmit power, its range is up to 1.6 km.
> 1 votes

---
Tags: arduino-mega, pwm, arduino-nano, wireless
---


# Question
Title: How to power a Seeeduino Stalker v2.3 - water proof with charger instead of solar panel
I am currently coding on a Seeeduino Stalker v2.3 - water proof kit.

http://www.seeedstudio.com/wiki/Seeeduino\_Stalker\_-\_Waterproof\_Solar\_Kit

It is sold with a solar panel to recharge the battery. Unfortunately, I will not have a lot of light where my sensor will be installed and I would like to power the board with a charger from 110V-220V plug and keep the battery only for potential power shortage.

My questions are:

1. What is the best option for connection and charger?
2. I have a previous Arduino Uno charger (9V-1A). Would it work with some linear regulator? What wiring should I use?
3. Any recommendation for a Li-Ion battery that could I buy and that would last longer than this 3.7 V at 1000mA?

Thank you for your help :)

# Answer
> 1 votes
1. To be as little invasive as possible, I'd remove just the solar panel and replace it with a power supply with the same typical voltage (5.5V) and at least the same typical power output (0.5W). It should not be too difficult, nor too expensive. Any USB charger that can provide 5V should do. You can just cut the USB connector and attach the wires to the board. Or be more elegant and create an adapter. Either way should work. And the price should be about a couple of bucks.
2. Yes, I think it would work, although linear regulators 9V -\> 5V are really inefficient. See my proposed solution from the previous point.
3. On ebay there's plenty of options, but they might not fit in the box of the seeduino. You have to compare the dimensions of the battery vs whatever extra space might be available.

# Answer
> 0 votes
1. You can charge the battery and power the board, via USB. The CN3063 requires between 4.4V to 6V, so not a huge range of options besides a 5v wall-wart
2. No. 9V would be too high.
3. How many mains power failures / brownouts do you get, where you live?

---
Tags: power
---


# Question
Title: unresolved overloaded function type for Wire.onReceive
I am attempting to make an I2C slave out of my Arduino and I can't get past the Wire.onReceive function. Here is my code. The documentation says to just add a function that has the style of void myHandler(int bytes) but I can't figure out why my readPI function does not meet these requirements.

```
    #include "piCom.h"
    #include "WireAddresses.h"
    #include <Wire.h>

    pi::pi(){
       Wire.begin(NB_INFO); // is 0x04
       Wire.onReceive( readPI );
       //Wire.onRequest(sendPI);
    }

    void pi::readPI(int byteCount){
       while( Wire.available() ){

             ref_IMU = Wire.read();

       }//end while

    }//end readPI

    void pi::sendPI(){

       Wire.write(1);
       //use to send pressure info to pi

    }//end sendPI

    //double pi::getref_IMU(){return ref_IMU;}

```

then here is the error

```
piCom.cpp: In constructor 'pi::pi()':
piCom.cpp:7: error: no matching function for call to'TwoWire::onReceive(<unresolved overloaded function type>)'
 Wire.onReceive( readPI );
                        ^

no matching function for call to 'TwoWire::onReceive(<unresolved overloaded function type>)'

```

Any help is greatly appreciated.

# Answer
> 2 votes
```
    void pi::sendPI(){

```

That is a class function (method) which has an implicit **this** pointer. You can't use it as a static ISR.

In general, classes cannot implement ISRs for this reason. There are a few workarounds, one being to make it a **static** class function. However then it will affect the entire class, not just one instance.

---
Tags: arduino-mega, i2c
---


title: Use TSL2561 and DS1307 RTC together

text:
# Question
Title: Use TSL2561 and DS1307 RTC together
I want to use a TSL2561 light sensor and a DS1307 RTC and a couple of other sensors like DS18B20, AS3935, ML8511, MQ135, 433 mhz sender together with an Arduino. However on Adafruit I read this today (Quote from Adafruit)

> You may be wondering, how is it OK to connect a 3.3V chip like the TSL2561 to 5.0V data pins like the Arduino? Isn't that bad? Well, in this specific case its OK. I2c uses pullup lines to the 3.3V power pin, so the data is actually being sent at 3.3V. As long as all the sensors/device on the i2c bus are running on 3.3V power, we're fine. However, don't use a 5.0v powered i2c device (like the DS1307) with pullups at the same time as a 3.3V device like the TSL2561! If you want to use this sensor with a datalogger that uses the DS1307, remove any/all of the pullup resistors from the DS1307 SDA/SCL pins. The pullups built into the TSL2561 will then be active and keep the voltage at 3.3V which is safe for both the RTC and the sensor.

I don't really understand the meaning of this. What am I supposed to do? It tells me to remove the pullup lines on the RTC, but what are they and where can I find them? Are there any other sensors where I have to do this? If I don't remove the pullup lines, will I damage anything? Can someone clarify those things to me?

# Answer
> 2 votes
You can use the DS1307 itself just fine, but you are probably using a breakout board. These boards have (pull-up) resistors on it that will pull-up the I2C lines to 5v, while you only want 3.3v. This will not damage the arduino, but could damage chips like the TSL2561, that can only handle 3.3v.

On the board you indicated you are using, you need to remove R2 and R3

Other 5v sensor breakout might also have pull-ups to 5v. Easiest way to check, is to connect 5v and ground, and then measure the voltage on the SDA and SCL pins. If it's 5v, then it has pull-up resistors that need to be removed.

---
Tags: sensors, i2c, pull-up
---


# Question
Title: How does the Arduino handle serial buffer overflow?
How does the Arduino handle serial buffer overflow? Does it throw away the newest incoming data or the oldest? How many bytes can the buffer hold?

# Answer
> 16 votes
For hardware serial ports you can see in HardwareSerial.cpp that the buffer size varies depending on the amount of RAM available on the particular AVR:

```
#if (RAMEND < 1000)
    #define SERIAL_BUFFER_SIZE 16
#else
    #define SERIAL_BUFFER_SIZE 64
#endif

```

For a software serial port in SoftwareSerial.h the receiver buffer size `_SS_MAX_RX_BUFF` is defined as 64 bytes. In both cases it stops attempting to insert received data into the queue when it is full, so you could get a mix to old and new data depending on how you're retrieving data from the queue.

Ideally it would be best to ensure the buffer always gets emptied in a prompt manner to avoid the buffer filling. Maybe take a look at timers and implementing a simple state machine if your problem is related to other code blocking the main loop.

# Answer
> 7 votes
## Receiving

You can see from the source of HardwareSerial that if an incoming byte finds the ring buffer full it is discarded:

```
inline void store_char(unsigned char c, ring_buffer *buffer)
{
  int i = (unsigned int)(buffer->head + 1) % SERIAL_BUFFER_SIZE;

  // if we should be storing the received character into the location
  // just before the tail (meaning that the head would advance to the
  // current location of the tail), we're about to overflow the buffer
  // and so we don't write the character or advance the head.
  if (i != buffer->tail) {
    buffer->buffer[buffer->head] = c;
    buffer->head = i;
  }
}

```

> I get the impression that if I transmit data to the Arduino and don't have an active "puller" of data on the Arduino side then if more data arrives than can fit in the buffer, it will be discarded. Can you confirm that?

Yes it will be discarded. There is no software or hardware flow control, unless you implement your own.

However with a 64-byte buffer, and receiving data at (say) 9600 baud, you get one byte every 1.04 ms, and thus it takes 66.6 ms to fill up the buffer. On a 16 MHz processor you should be able to check the buffer often enough that it doesn't fill up. All you really have to do is move the data from the HardwareSerial buffer to your own, if you don't want to process it right now.

You can see from the `#if (RAMEND < 1000)` check that the processors with 1000+ bytes of RAM get the 64-byte buffer, the ones will less RAM get the 16-byte buffer.

---

## Sending

Data that you write is placed in a same-sized buffer (16 or 64 bytes). In the case of sending if the buffer fills up the code "blocks" waiting for an interrupt to send the next byte out the serial port.

If interrupts are turned off this will never happen, thus you do **not** do Serial prints inside an Interrupt Service Routine.

---
Tags: serial
---


# Question
Title: How to empty the buffer for Serial port?
I have a Yun that accepts commands via the bridge (note the below code is part of a very simple virtual keyboard that accepts commands then runs `Keyboard.println` on them:

```
#include <stdlib.h>
#include <string.h>
HardwareSerial *port;

void setup() {
  port = &Serial1;
  port->begin(9600);
}

void loop() {
  if (port->available()) {
    String cmd = port->readString();

    if(cmd.length() > 1){
      String instruction = cmd;
      int arg_comma_index = 0;
      arg_comma_index = instruction.indexOf(",");
      String func = instruction.substring(0, arg_comma_index);
      String args = instruction.substring(arg_comma_index + 1, instruction.length() + 1 );

      Keyboard.begin();
      Keyboard.println(args);
      Keyboard.end();
    }
    port->read(); // Try to throw away whatever's left to prevent looping (which is still happening).
  }
}

```

If I send it a short string:

* The first time, immediately after starting the sketch, it works.
* The second time, it works but loops anywhere from 1-5 times.
* The third time, it loops more times still.
* If I leave the device running (even if not operating it), the number of times it loops goes up *when* I finally do send it an instruction. I'm seeing 20-75 loops after less than 15 minutes of uptime.

Clearly the loops where no instruction is being received are still building up something here. I've tried:

* Restarting the port each `void loop()`.
* Flushing the port at the top and/or bottom of each `void loop()`.
* Setting `cmd = ""` at the end of each `void loop()`.
* Checking `peek()`, `available()`, and `readString()` \- after I send it one instruction, they return the same values every single time they loop.

# Answer
It's quite simple to empty the serial buffer - you just read all the data that is in the buffer and throw it away:

```
while (port->available()) {
    port->read();
}

```
> 1 votes

# Answer
I wouldn't be using readString myself. In fact I wouldn't be using the String class at all. `readString` keeps reading until it times out (by default after one second), so it may read more - or less even - than you want. It will also introduce a one-second delay while it sits around waiting for that second to elapse.

You are much better off doing a non-blocking loop, and then processing data when you get a known delimiter, like a newline or comma, or whatever you designate as "ending the stream". Example code that uses a newline delimiter:

```
// how much serial data we expect before a newline
const unsigned int MAX_INPUT = 50;

void setup ()
  {
  Serial.begin (115200);
  } // end of setup

// here to process incoming serial data after a terminator received
void process_data (const char * data)
  {
  // for now just display it
  // (but you could compare it to some value, convert to an integer, etc.)
  Serial.println (data);
  }  // end of process_data

void processIncomingByte (const byte inByte)
  {
  static char input_line [MAX_INPUT];
  static unsigned int input_pos = 0;

  switch (inByte)
    {

    case '\n':   // end of text
      input_line [input_pos] = 0;  // terminating null byte

      // terminator reached! process input_line here ...
      process_data (input_line);

      // reset buffer for next time
      input_pos = 0;
      break;

    case '\r':   // discard carriage return
      break;

    default:
      // keep adding if not full ... allow for terminating null byte
      if (input_pos < (MAX_INPUT - 1))
        input_line [input_pos++] = inByte;
      break;

    }  // end of switch

  } // end of processIncomingByte

void loop()
  {
  // if serial data available, process it
  while (Serial.available () > 0)
    processIncomingByte (Serial.read ());

  // do other stuff here like testing digital input (button presses) ...

  }  // end of loop

```

In my example code you would do whatever-it-is you want in `process_data` which is called once an entire line arrives. Then you don't need to discard incoming data (empty the serial buffer), which seems to me to be a bad idea anyway.
> 1 votes

# Answer
How do you send your commands, char by char or one shot ?

If there is nothing to read, `port->available()` may return -1 error code after 1 sec, but you already checked, isn't it ? Anyway, you should check if it returns something `> 0` instead of something `!= 0`.

Note that `readString()` doesn't take any parameter (https://www.arduino.cc/en/Reference/StreamReadString). I suspect this function not acting as `read()` to decrease the number returned by `available();` If you want to catch \n, use `readStringUntil('\n')` instead (https://www.arduino.cc/en/Serial/ReadStringUntil).

Try to put the full code (**with the loop**) given by Majenko at the end of your loop() function.

```
#include <stdlib.h>
#include <string.h>
HardwareSerial *port;

void setup() {
  port = &Serial1;
  port->begin(9600);
}

void loop() {
  if (port->available() > 0) {
    String cmd = port->readString();

    if (cmd.length() > 1) { // Why not 0 ?
      String instruction = cmd;
      int arg_comma_index = 0;
      arg_comma_index = instruction.indexOf(",");
      String func = instruction.substring(0, arg_comma_index);
      String args = instruction.substring(arg_comma_index + 1, instruction.length() + 1 );

      Keyboard.begin();
      Keyboard.println(args);
      Keyboard.end();
    }
    while (port->available() > 0) {
        port->read();
    }
  }
}

```
> 0 votes

---
Tags: serial, arduino-yun
---


# Question
Title: Does any board provide more than 1024 analog input values?
The Arduino boards provide an analog input range of 0V to 5V which translates to 0 to 1023 integer values. The range is determined by the on-board ADC, which in the case of the Uno is a 10 bit ADC (2^10 = 1024).

Do any of the official boards have a larger (\>10 bits) ADC? Do any boards provide a wider range of analog input values?

# Answer
AVR-based Arduinos only have 10-bit ADCs, but the ATSAM3X in the Due has 12-bit ADCs. Additionally, it is possible to interface to higher-resolution external ADCs via I2C or SPI.
> 7 votes

# Answer
How much accuracy do you really need? If it's just 1 or 2 extra bits of resolution you are after, you might be able to achieve that with a bit of oversampling.

Basically, you take a ton of readings and average them. It only works if there is at least a few mV of random noise in your signal or in your ADC, and if your input signal bandwidth is low enough to be averaging samples together.

Otherwise, go with a dedicated ADC chip.
> 5 votes

# Answer
They all do with oversampling. You can evaluate the quality of doing this for your own use.
> 0 votes

---
Tags: analogread
---


# Question
Title: Analog input weirdness (barrel connector vs USB power)
I noticed that my Arduino Mega performs differently in how it presents values from say analog input A0, depending on whether it is being powered by USB or by a fresh 9V battery wired and connected through the barrel connector.

There must be some sort of difference to what happens when both USB and the barrel connector are employed vs. just USB being used for power.

To be specific, when running just on USB power, the analog inputs seem to flicker more allowing for oversampling and measurements beyond the 10 bit accuracy of the DAC. In fact with analogReference(DEFAULT) it is possible with 64x oversampling to see 100uV level changes when only USB power is employed. Note that these changes are not just noise, they actually correspond to 100uV level changes in the input connected to A0 with high correlation.

As soon as I connect the barrel connector, the picture changes significantly. Values coming out of the ADC seem to pretty much snap and there is far less flicker. The ADC becomes, well, discrete and you get your 1,024 levels and that's about it. There may be a tiny bit of flicker as you increase or decrease voltage and approach the next increment, but this is not significant enough to actually increase the ADC resolution reliably.

Even going so far as setting the analogReference to EXTERNAL while the barrel connector is employed and connecting the AREF pin to the 5v connector directly, which by the way reads at 5.004 V (unlike the 4.992 V it reads when USB is powering the device) still reproduces the problem.

Summary: Effectively, when running on USB power only I can oversample the analog inputs and get significantly more than 10-bit resolution. While when running using the barrel connector, with the USB still attached, I can only get the 10-bit resolution natively provided by the ADC.

If anyone has any ideas on what is causing this difference in behavior, I am all ears. If I failed to explain anything or perhaps created some confusion, I would be more than happy to clarify.

Note: This is an authentic Arduino Mega board.

# Answer
Looking at the schematic the barrel plug has a couple of linear voltage regulators (top left of schematic), while the USB input just has a couple of MOSFETs (bottom right of schematic) which are basically just there to switch off the USB power if there is something plugged into the barrel jack (and also maybe provide a little input protection). So the Arduino is relying on the USB power to be pre-regulated. For the most part this is correct, but USB voltage can vary widely depending on the cable length (voltage drop), the power source it is connected to (no two computers or wall warts are the same), and how many devices are the same hub (if connected to a computer or hub). I would not rely on the two power sources being matched at all.

The flicker you are talking about sounds like the power coming from USB could have significant ripple. I doubt that the USB power is allowing you to "oversample". The way ADCs in AVRs work is they have a reference voltage and when sampling, will give you a reading of where the voltage is between 0 and the voltage reference. With a 10-bit ADC there are ~1000 steps, so to measure 100uV changes, you would have to have a 100 mV reference voltage, which according to the datasheet (p.379), the minimum is 1.0 V. Basically, it is physically impossible for the Arduino Mega to measure those kinds of changes.

What is more likely to be happening is that you are probably getting some weird aliasing between the ripple frequency of your USB voltage and the sampling frequency of your code. The best way to debug this kind of thing would be to pull out an oscilloscope and check if and how much ripple is coming off the USB power.

If accuracy is important to your project, and being able to accept both power inputs is a requirement, you might look into maybe getting your own external voltage reference and piping it into VREF. Otherwise, I would stick to only using the barrel plug as it is regulated and will be consistent.
> 1 votes

---
Tags: arduino-mega
---


title: Emulating 1-wire device(s)

text:
# Question
Title: Emulating 1-wire device(s)
What I want to do is make a ATTiny IC become a slave on the 1-wire bus, with its own S/N and command list for its specific functions.

What I want to know is if I can use the one wire library from the arduino site to send data as a slave.

For example, you can have a slave in one room with multiple types of sensors which would report to the master on requested information, or the master can tell it to control something like blinds.

**Question** Would I have to monitor the bus line and respond to a request from the master and also take into consideration the way a normal sensor would send data? What frequency should I run the slave at to get the best functionality?

I won't use parasitic power, as a note.

# Answer
> 3 votes
As far as I know, the 1-wire library you linked in your question allows only to act as a master, not a slave.

I've just released a library to turn an Arduino board into a 1-wire slave, here: https://github.com/neuoy/OneWireArduinoSlave (edit: moved here https://gitea.youb.fr/youen/OneWireArduinoSlave). I use it in my custom home automation system, and it works flawlessly in my setup (the 1-wire master, a DS9490R, is connected to a laptop via USB, and also provides power to the Arduino, which is an Arduino Uno). The library handles low level details: match rom, byte send and receive (which is actually quite hard to get right, mostly impossible without a logic analyzer). The rest is up to you.

It's entirely implemented with interrupts, all communications are performed in background, you can execute other code as usual, in parallel, and are notified by callbacks when bytes are received etc. Sending bytes to the master is also asynchronous.

I also know at least one other library exists, https://github.com/MarkusLange/OneWireSlave, as commented above by Ryu\_hayabusa. It didn't work for me (don't know if it's because of my hardware setup or for another reason), but it definitely work for others, so also worth a try. It seems this library is not implemented with interrupts, so your program is blocked while waiting for master activity (which is perfectly acceptable in a lot of scenarios).

---
Tags: sensors, library, attiny, 1-wire
---


# Question
Title: Reading a part of bitmap image on Arduino
I'm pretty much a beginner when it comes to programming and have only recently started learning C++. Right now I'm stuck trying to covert a bitmap into a binary array. This is for a Robotics competition I've entered. The bitmap is a 54\*96 pixel monochromatic 1 bpp image. I'm confused with the offset positions while trying to read the header. This is the code I've written so far and would greatly appreciate any help. I think the error lies in increment of the `lineNo` variable which needs to be in hex, but how to increment such values?

What I want to ultimately achieve is to read only some parts of the bitmap particularly the boxes with cross on them (see image below). How do I find out the pixel locations?

```
#include <SD.h>
#include <SPI.h>
File bMap;
File Text;
void setup()
{
  Serial.begin(9600);
  while (!Serial) {
    ;
  }
  Serial.print("Initializing SD card...");
  pinMode(10, OUTPUT);
  if (!SD.begin(4)) {
    Serial.println("initialization failed!");
    return;
  }
  Serial.println("initialization done.");
  int height = 0;
  int width = 0;
  int  bitmapOffset = 0xa;
  bMap = SD.open("map.bmp", FILE_READ);
  Text = SD.open("test.txt", FILE_WRITE);
  \\bMap.seek(0xa);
  \\bitmapOffset = bMap.read();
  \\Serial.println(bitmapOffset, BIN);
  \\Serial.println(bMap, HEX);
  bMap.seek(0x16);
  for (int i = 0; i < 4; i++) {
    height += (bMap.read() << (8 * i));
    Serial.println(height);
    int lineNo;
    int fileposition = 0;
    for (lineNo = 0; lineNo < height; lineNo++)
      fileposition = bitmapOffset + (lineNo);
    bMap.seek(fileposition);
    //Serial.print(lineNo);
    Serial.print(fileposition);
    //Serial.print(bitmapOffset);

  }

  bMap.seek(0x12);
  for (int i = 0; i < 4; i++) {
    width += (bMap.read() << (8 * i));
    Serial.println(width);
    if (Text) {
      Text.println(height, width);
      Text.close();
    }
  }
}

void loop() {}

```

# Answer
Any coordinate in a bitmap (note: the term bitmap here \[all lower case\] refers to the concept of a grid of pixels, not the Windows BMP file format which I will always refer to as BMP all in capitals) can easily be calculated as long as you know the width. The height is only needed to stop you going too far.

Any pixel offset in a buffer of pixels is calculated as `y * width + x` assuming a *left-right / top-down* pixel arrangement in the buffer.

The information you are really interested in with your bitmap is actually considerably less than is in the BMP that you show. Your BMP is 56x96 pixels, but the information you actually care about is actually only in a resolution of 7x12 blocks.

It would be far simpler if you could pre-process the provided BMP on a PC to create an array of 84 entries each with a different tag or value to represent what it is. Your image there could then be represented as the array:

```
{ 3, 3, 3, 3, 3, 3, 3,
  3, 1, 0, 0, 0, 1, 3,
  3, 0, 0, 0, 0, 1, 3,
  0, 0, 1, 1, 0, 0, 3,
  3, 2, 1, 0, 0, 0, 3,
  3, 1, 0, 0, 1, 0, 3,
  3, 0, 1, 0, 0, 0, 3,
  3, 0, 0, 0, 2, 0, 3,
  3, 0, 0, 1, 0, 0, 3,
  3, 1, 1, 0, 1, 0, 3,
  3, 0, 0, 0, 0, 0, 3,
  3, 3, 3, 0, 3, 3, 3 };

```

Where 0 is an open white space, 1 is a closed black space, 2 is a black space with a cross and 3 is a border space.

The two crosses would then be calculated as `(1,4) = 4 * 7 + 1 = 29` and `(4,7) = 7 * 7 + 4 = 53`.

Working with BMP files is somewhat more tricky. They come in multiple depths and multiple bit arrangements, as well as different versions with different header sizes. They also have different padding requirements for different line lengths and bit depths, and are generally a rather nasty file format all round.

And on top of that they are upside down. BMP is the only file format I know of where 0,0 is at the bottom left instead of the top left. Consequently you have to invert all your Y coordinates to make sense of it, and parsing a BMP file from the top down is really slow because you have to keep jumping backwards in the file.

So it would be much better if you could write a program on a PC using software which already understands the BMP format and can render it into a buffer for your program to then parse each block to work out what it is and build up a small 84 byte file of the actual information you need for your robot.

If you must read the BMP file directly on the Arduino then I have code you use to help you. It's not designed for the Arduino but for the chipKIT boards (though it's very similar) and is designed as part of my DisplayCore framework for chipKIT (and other more powerful) boards, but you are welcome to take whatever bits you like, or just use bits to give you more insight into how BMP files work. You can get the code from Github here: https://github.com/MajenkoLibraries/DisplayCore/tree/master/ImageReaders/BMPFile

To parse your bitmap into an array you would have to take each 8x8 block of pixels and work out what shape is in it - whether it's all black, all white, a cross, or a border piece.
> 2 votes

---
Tags: arduino-mega
---


# Question
Title: Reading states of multiple toggle switches
I'm working on modifying this example from the Arduino website to read the state of 3 toggle (SPDT) switches. If I have one toggle switch hooked up, my sketch works as expected...the sketch will log the state of the switch in the serial debugger every-time the state changes, and only when the state changes.

However, if I add in two more switches, the serial debugger will continuously output my log messages, without detecting if the state has changed.

Here's the code from my sketch:

```
const int  switchOnePin = 2;    // digital in 2 (pin the switch one is attached to)
const int  switchTwoPin = 3;    // digital in 3 (pin the switch two is attached to)
const int  switchThreePin = 4;  // digital in 4 (pin the switch three is attached to)

int switchOneState = 0;         // current state of the switch
int lastSwitchOneState = 0;     // previous state of the switch

int switchTwoState = 0;
int lastSwitchTwoState = 0;

int switchThreeState = 0;
int lastSwitchThreeState = 0;

void setup() {
  // initialize serial communication at 9600 bits per second:
  Serial.begin(9600);

  int switchOneState = 0;         // current state of the switch
  int lastSwitchOneState = 0;     // previous state of the switch switch pins as an input
  pinMode(switchOnePin, INPUT);
  pinMode(switchTwoPin, INPUT);
  pinMode(switchThreePin, INPUT);
}

void loop() {

  // read the switch input pins:
  switchOneState   = digitalRead(switchOnePin);
  delay(50);
  switchTwoState   = digitalRead(switchTwoPin);
  delay(50);
  switchThreeState = digitalRead(switchThreePin);

  // compare the switchState to its previous state
  if (switchOneState != lastSwitchOneState) {
  // if the state has changed, increment the counter
    if (switchOneState == HIGH) {
    // if the current state is HIGH then the button
    // went from off to on:
    Serial.println("Switch one is on");
  }
  else {
    // if the current state is LOW then the button
    // went from on to off:
    Serial.println("Switch one is off");
  }

  if (switchTwoState != lastSwitchTwoState) {
    if (switchTwoState == HIGH) {
    Serial.println("Switch two is on");
  }
  else {
    Serial.println("Switch two is off");
  }

  if (switchThreeState != lastSwitchThreeState) {
    if (switchThreeState == HIGH) {
    Serial.println("Switch three is on");
  }
  else {
    Serial.println("Switch thre is off");
  }
 }
}
  // Delay a little bit to avoid bouncing
  delay(50);
}
// save the current state as the last state,
//for next time through the loop
lastSwitchOneState   = switchOnePin;
lastSwitchTwoState   = switchTwoPin;
lastSwitchThreeState = switchThreePin;
}

```

And here's what my circuit looks like:

Does anyone have any insight into what I may be doing wrong? I'm not quite sure if it's a circuit or a sketch issue (or both).

**EDIT** I tried adding a delay of 50ms between each digital input read, but that still did not seem to help the problem.

# Answer
The problem was two pronged---both the copy/paste error that @Gerben pointed out, as well as the incorrect if-else statements that @BrettAM pointed out. Below is the working code:

```
const int  switchOnePin = 2;    // digital in 2 (pin the switch one is attached to)
const int  switchTwoPin = 3;    // digital in 3 (pin the switch two is attached to)
const int  switchThreePin = 4;  // digital in 4 (pin the switch three is attached to)

int switchOneState = 0;         // current state of the switch
int lastSwitchOneState = 0;     // previous state of the switch

int switchTwoState = 0;
int lastSwitchTwoState = 0;

int switchThreeState = 0;
int lastSwitchThreeState = 0;

void setup() {
    //initialize serial communication at 9600 bits per second:
    Serial.begin(9600);

    int switchOneState = 0;         // current state of the switch
    int lastSwitchOneState = 0;     // previous state of the switch switch pins as an input
    pinMode(switchOnePin, INPUT);
    pinMode(switchTwoPin, INPUT);
    pinMode(switchThreePin, INPUT);
}

void loop() {
    // read the switch input pins:
    switchOneState   = digitalRead(switchOnePin);
    switchTwoState   = digitalRead(switchTwoPin);
    switchThreeState = digitalRead(switchThreePin);

    // compare the switchState to its previous state
    if (switchOneState != lastSwitchOneState) {
        // if the state has changed, increment the counter
        if (switchOneState == HIGH) {
        // if the current state is HIGH then the button
        // went from off to on:
            Serial.println("Switch one is on");
        } else {
            // if the current state is LOW then the button
            // went from on to off:
            Serial.println("Switch one is off");
        }
    }

    if (switchTwoState != lastSwitchTwoState) {
        if (switchTwoState == HIGH) {
            Serial.println("Switch two is on");
        } else {
            Serial.println("Switch two is off");
        }
    }

    if (switchThreeState != lastSwitchThreeState) {
        if (switchThreeState == HIGH) {
            Serial.println("Switch three is on");
        } else {
            Serial.println("Switch thre is off");
        }
    }

    // Delay a little bit to avoid bouncing
    delay(50);

    // save the current state as the last state,
    //for next time through the loop
    lastSwitchOneState   = switchOneState;
    lastSwitchTwoState   = switchTwoState;
    lastSwitchThreeState = switchThreeState;
}

```
> 5 votes

# Answer
```
lastSwitchOneState   = switchOnePin;
lastSwitchTwoState   = switchTwoPin;
lastSwitchThreeState = switchThreePin;

```

should be

```
lastSwitchOneState   = switchOneState;
lastSwitchTwoState   = switchTwoState;
lastSwitchThreeState = switchThreeState;

```
> 4 votes

---
Tags: serial
---


title: Why is my interrupt code not working?

text:
# Question
Title: Why is my interrupt code not working?
### Background

I'm trying to write code to read signals from a six-channel RC receiver on an Arduino Mega 2560. Currently I am keeping the code to just read one channel to make things easy to troubleshoot. The problem is my shared variable is not updating, leading me to believe that my interrupt service routine is not detecting any rising edges.

I thought my receiver was broken, so I tested it using the standard Arduino attach interrupt function. It worked perfectly, so my receiver is fine.

I used Serial.print() to see if my volatile channel variable was updating (that is, change its value to the channel 1 flag value). It was not updating, so my ISR must be wrong. You can find the original code in the blog post.

What's wrong? I'm out of ideas.

```
#include <PinChangeInt.h>

//Pin assignment
#define channel1PIN 10

//Bit flags
#define Channel1FLAG 1

//Flag holder
volatile uint8_t bFLAGUPDATESHARED;

//Shared variables: Accessed by the interrupt service routine and read in 'void loop'.
volatile uint16_t unCHANNEL1SHARED;

//Start time variables: These are used to set the start time of the rising edge of
//a pulse. They are only accessed by the ISR, and thus they are unsigned integers and
//not volatiles.

uint32_t ulCHANNEL1START;

void setup()
{
  Serial.begin(9600);
  Serial.print("RC Channel PWM Read Interrupt Test");

  //PinChangInt library function. Used to set attach interrupts.
  PCintPort::attachInterrupt(channel1PIN, calcCHANNEL1, CHANGE);
}

void loop()
{
  //In-loop variables to hold local copies of channel inputs.
  //This is static so it retains values between call loops.
  static uint16_t unCHANNEL1IN;

  //The in-loop copy of the bSHAREDFLAGUPDATE volatile flag holder
  static uint8_t bFLAGUPDATELOCAL;

  //Check to see if any channels have received signals. If so, copy
  //shared variables to local in loop variables.
  if (bFLAGUPDATESHARED)
  {
    //Switch off interrupts when I copy shared variables to local variables
    noInterrupts();

    bFLAGUPDATELOCAL = bFLAGUPDATESHARED;

    if (bFLAGUPDATELOCAL & Channel1FLAG)
    {
      unCHANNEL1IN = unCHANNEL1SHARED;
    }

    bFLAGUPDATESHARED = 0;
    interrupts();
  }

  Serial.println(unCHANNEL1IN);

  //Clear local update flags copy as all values have been copied to local variables
  bFLAGUPDATELOCAL = 0;
}

void calcCHANNEL1()
{
  if (digitalRead(channel1PIN) == HIGH)
  {
    //If pin goes high, start timer and set ulCHANNEL1START to timer start
    ulCHANNEL1START = micros();
  }
  else
  {
    //If it is not rising, it must be falling so set shared
    //variable to current time-start time
    unCHANNEL1SHARED = (uint16_t)(micros() - ulCHANNEL1START);

    //Tell that channel 1 has received a signal
    bFLAGUPDATESHARED |= Channel1FLAG;
  }
}

```

# Answer
> 4 votes
Only **some** ports on the Atmega2560 support pin-change interrupts, specifically ports B, E (bit 0), J (bits 0 to 6) and K.

Looking at the reference schematic that means that these pins on the board are supported:

```
     Chip
Name  Pin  Pin on board
-----------------------

Port B

PB0 - 19 - D53 (SS)
PB1 - 20 - D52 (SCK)
PB2 - 21 - D51 (MOSI)
PB3 - 22 - D50 (MISO)
PB4 - 23 - D10
PB5 - 24 - D11
PB6 - 25 - D12
PB7 - 26 - D13

Port E

PE0 - 2 - D0 (RXD0)

Port J

PJ0 - 63 - D15 (RXD3)
PJ1 - 64 - D14 (TXD3)
PJ2 to PJ6 - not connected on board

Port K

PK0 - PK7 - (89 - 82)  - A8 - A15

```

Thus you can see that D10 to D12, which you say works, are in that list. Other random ones would not be.

---

### SoftwareSerial

You can see confirmation on the page for SoftwareSerial where it says:

> Not all pins on the Mega and Mega 2560 support change interrupts, so only the following can be used for RX: 10, 11, 12, 13, 14, 15, 50, 51, 52, 53, A8 (62), A9 (63), A10 (64), A11 (65), A12 (66), A13 (67), A14 (68), A15 (69).

This is because SoftwareSerial uses pin-change interrupts to detect incoming serial data, and thus the disclaimer on that page about which pins it will work with.

---

### Atmega2560 pin-outs

---

> PinchangeInt should work on any digital pin

Note that the Atmega328P (as used in the Uno) has less ports, and all are available for pin-change interrupts on that board.

# Answer
> 2 votes
On the ATmega1280/2560, only ports B, J, F, and K have pin change interrupt capability. These map approximately to pins 10 through 15, 50 through 53, and A6 through A15 (although part of port J is unmapped to Arduino pins, therefore PCINT11 through PCINT15 are unavailable on the Arduino Mega/Mega 2560).

---
Tags: arduino-mega, pins, pwm, interrupt
---


# Question
Title: Using STL vector to create an array causes an error
I have installed the STL for arduino, and it has been working fine. Then I tried to create a vector using a custom class, and it gave me a massive error message. When using it on primitive data types (ex. int) it works fine, but in any one of my own classes (including classes from sample code) it gives this error:

```
Arduino: 1.6.3 (Windows 8.1), Board: "Arduino Uno"

Build options changed, rebuilding all

C:\Program Files (x86)\Arduino\hardware\tools\avr/bin/avr-g++ -c -g -Os -w - fno-exceptions -ffunction-sections -fdata-sections -fno-threadsafe-statics -MMD   -std=gnu++11 -mmcu=atmega328p -DF_CPU=16000000L -DARDUINO=10603 -  DARDUINO_AVR_UNO -DARDUINO_ARCH_AVR -IC:\Program Files   (x86)\Arduino\hardware\arduino\avr\cores\arduino -IC:\Program Files   (x86)\Arduino\hardware\arduino\avr\variants\standard   C:\Users\OWNER\AppData\Local\Temp\build7240665633604233053.tmp\Navigation.cpp -o    C:\Users\OWNER\AppData\Local\Temp\build7240665633604233053.tmp\Navigation.cpp.o

In file included from c:\program files     (x86)\arduino\hardware\tools\avr\avr\include\vector:33:0,

                 from Navigation.ino:2:

c:\program files (x86)\arduino\hardware\tools\avr\avr\include\stl_construct.h: In instantiation   of 'void std::__destroy_aux(_ForwardIterator, _ForwardIterator, __false_type)   [with _ForwardIterator = Obstacle*]':

c:\program files (x86)\arduino\hardware\tools\avr\avr\include\stl_construct.h:78:55:   required  from 'void std::__destroy(_ForwardIterator, _ForwardIterator, _Tp*) [with  _ForwardIterator = Obstacle*; _Tp = Obstacle]'

c:\program files (x86)\arduino\hardware\tools\avr\avr\include\stl_construct.h:83:51:   required from 'void std::_Destroy(_ForwardIterator, _ForwardIterator) [with _ForwardIterator = Obstacle*]'

c:\program files (x86)\arduino\hardware\tools\avr\avr\include\stl_construct.h:115:27:   required  from 'void std::destroy(_ForwardIterator, _ForwardIterator) [with _ForwardIterator = Obstacle*]'

c:\program files (x86)\arduino\hardware\tools\avr\avr\include\stl_vector.h:284:42:   required from 'std::vector<_Tp, _Alloc>::~vector() [with _Tp = Obstacle; _Alloc = std::allocator<Obstacle>]'

Navigation.ino:36:23:   required from here

c:\program files (x86)\arduino\hardware\tools\avr\avr\include\stl_construct.h:66:22: error: 'destroy' was not declared in this scope, and no declarations were found by argument-dependent lookup at the point of instantiation [-fpermissive]

     destroy(&*__first);

                  ^

c:\program files (x86)\arduino\hardware\tools\avr\avr\include\stl_construct.h:114:13: note: 'template<class _ForwardIterator> void std::destroy(_ForwardIterator, _ForwardIterator)' declared here, later in the translation unit

 inline void destroy(_ForwardIterator __first, _ForwardIterator __last) {

             ^

Error compiling.

```

**EDIT:** Here is the code:

```
#include <iterator>
#include <vector>
#include <pnew.cpp>

class Test {
public:
    int i;
};
std::vector<Test> test;

```

Change the last line to

```
std::vector<Test&> test

```

and:

```
        Arduino: 1.6.3 (Windows 8.1), Board: "Arduino Uno"

C:\Program Files (x86)\Arduino\hardware\tools\avr/bin/avr-g++ -c -g -Os -w -fno-exceptions -ffunction-sections -fdata-sections -fno-threadsafe-statics -MMD -std=gnu++11 -mmcu=atmega328p -DF_CPU=16000000L -DARDUINO=10603 -DARDUINO_AVR_UNO -DARDUINO_ARCH_AVR -IC:\Program Files (x86)\Arduino\hardware\arduino\avr\cores\arduino -IC:\Program Files (x86)\Arduino\hardware\arduino\avr\variants\standard C:\Users\OWNER\AppData\Local\Temp\build7240665633604233053.tmp\Navigation.cpp -o C:\Users\OWNER\AppData\Local\Temp\build7240665633604233053.tmp\Navigation.cpp.o

In file included from c:\program files (x86)\arduino\hardware\tools\avr\avr\include\vector:35:0,

                 from Navigation.ino:2:

c:\program files (x86)\arduino\hardware\tools\avr\avr\include\stl_vector.h: In instantiation of 'class std::_Vector_alloc_base<Obstacle&, std::allocator<Obstacle&>, true>':

c:\program files (x86)\arduino\hardware\tools\avr\avr\include\stl_vector.h:101:8:   required from 'struct std::_Vector_base<Obstacle&, std::allocator<Obstacle&> >'

c:\program files (x86)\arduino\hardware\tools\avr\avr\include\stl_vector.h:155:7:   required from 'class std::vector<Obstacle&>'

Navigation.ino:36:24:   required from here

c:\program files (x86)\arduino\hardware\tools\avr\avr\include\stl_vector.h:89:8: error: forming pointer to reference type 'Obstacle&'

   _Tp* _M_start;

        ^

c:\program files (x86)\arduino\hardware\tools\avr\avr\include\stl_vector.h:90:8: error: forming pointer to reference type 'Obstacle&'

   _Tp* _M_finish;

        ^

c:\program files (x86)\arduino\hardware\tools\avr\avr\include\stl_vector.h:91:8: error: forming pointer to reference type 'Obstacle&'

   _Tp* _M_end_of_storage;

        ^

c:\program files (x86)\arduino\hardware\tools\avr\avr\include\stl_vector.h:94:8: error: forming pointer to reference type 'Obstacle&'

   _Tp* _M_allocate(size_t __n)

        ^

c:\program files (x86)\arduino\hardware\tools\avr\avr\include\stl_vector.h:96:8: error: forming pointer to reference type 'Obstacle&'

   void _M_deallocate(_Tp* __p, size_t __n)

        ^

c:\program files (x86)\arduino\hardware\tools\avr\avr\include\stl_vector.h: In instantiation of 'class std::vector<Obstacle&>':

Navigation.ino:36:24:   required from here

c:\program files (x86)\arduino\hardware\tools\avr\avr\include\stl_vector.h:165:23: error: forming pointer to reference type 'std::vector<Obstacle&>::value_type {aka Obstacle&}'

   typedef value_type* pointer;

                       ^

c:\program files (x86)\arduino\hardware\tools\avr\avr\include\stl_vector.h:166:29: error: forming pointer to reference type 'std::vector<Obstacle&>::value_type {aka Obstacle&}'

   typedef const value_type* const_pointer;

                             ^

c:\program files (x86)\arduino\hardware\tools\avr\avr\include\stl_vector.h:167:23: error: forming pointer to reference type 'std::vector<Obstacle&>::value_type {aka Obstacle&}'

   typedef value_type* iterator;

                       ^

c:\program files (x86)\arduino\hardware\tools\avr\avr\include\stl_vector.h:168:29: error: forming pointer to reference type 'std::vector<Obstacle&>::value_type {aka Obstacle&}'

   typedef const value_type* const_iterator;

                             ^

c:\program files (x86)\arduino\hardware\tools\avr\avr\include\stl_vector.h:178:49: error: forming pointer to reference type 'Obstacle&'

   typedef std::reverse_iterator<const_iterator> const_reverse_iterator;

                                                 ^

c:\program files (x86)\arduino\hardware\tools\avr\avr\include\stl_vector.h:179:43: error: forming pointer to reference type 'Obstacle&'

   typedef std::reverse_iterator<iterator> reverse_iterator;

                                           ^

c:\program files (x86)\arduino\hardware\tools\avr\avr\include\stl_vector.h:189:16: error: no members matching 'std::vector<Obstacle&>::_Base {aka std::_Vector_base<Obstacle&, std::allocator<Obstacle&> >}::_M_allocate' in 'std::vector<Obstacle&>::_Base {aka struct std::_Vector_base<Obstacle&, std::allocator<Obstacle&> >}'

   using _Base::_M_allocate;

                ^

c:\program files (x86)\arduino\hardware\tools\avr\avr\include\stl_vector.h:190:16: error: no members matching 'std::vector<Obstacle&>::_Base {aka std::_Vector_base<Obstacle&, std::allocator<Obstacle&> >}::_M_deallocate' in 'std::vector<Obstacle&>::_Base {aka struct std::_Vector_base<Obstacle&, std::allocator<Obstacle&> >}'

   using _Base::_M_deallocate;

                ^

c:\program files (x86)\arduino\hardware\tools\avr\avr\include\stl_vector.h:191:16: error: no members matching 'std::vector<Obstacle&>::_Base {aka std::_Vector_base<Obstacle&, std::allocator<Obstacle&> >}::_M_start' in 'std::vector<Obstacle&>::_Base {aka struct std::_Vector_base<Obstacle&, std::allocator<Obstacle&> >}'

   using _Base::_M_start;

                ^

c:\program files (x86)\arduino\hardware\tools\avr\avr\include\stl_vector.h:192:16: error: no members matching 'std::vector<Obstacle&>::_Base {aka std::_Vector_base<Obstacle&, std::allocator<Obstacle&> >}::_M_finish' in 'std::vector<Obstacle&>::_Base {aka struct std::_Vector_base<Obstacle&, std::allocator<Obstacle&> >}'

   using _Base::_M_finish;

                ^

c:\program files (x86)\arduino\hardware\tools\avr\avr\include\stl_vector.h:193:16: error: no members matching 'std::vector<Obstacle&>::_Base {aka std::_Vector_base<Obstacle&, std::allocator<Obstacle&> >}::_M_end_of_storage' in 'std::vector<Obstacle&>::_Base {aka struct std::_Vector_base<Obstacle&, std::allocator<Obstacle&> >}'

   using _Base::_M_end_of_storage;

                ^

In file included from c:\program files (x86)\arduino\hardware\tools\avr\avr\include\iosfwd:22:0,

                 from c:\program files (x86)\arduino\hardware\tools\avr\avr\include\iterator:35,

                 from Navigation.ino:1:

c:\program files (x86)\arduino\hardware\tools\avr\avr\include\stl_alloc.h: In instantiation of 'class std::allocator<Obstacle&>':

Navigation.ino:36:24:   required from here

c:\program files (x86)\arduino\hardware\tools\avr\avr\include\stl_alloc.h:638:22: error: forming pointer to reference type 'Obstacle&'

   typedef _Tp*       pointer;

                      ^

c:\program files (x86)\arduino\hardware\tools\avr\avr\include\stl_alloc.h:639:22: error: forming pointer to reference type 'Obstacle&'

   typedef const _Tp* const_pointer;

                      ^

c:\program files (x86)\arduino\hardware\tools\avr\avr\include\stl_alloc.h:658:8: error: forming pointer to reference type 'Obstacle&'

   _Tp* allocate(size_type __n, const void* = 0) {

        ^

Navigation.ino: In constructor 'std::vector<_Tp, _Alloc>::vector(const allocator_type&) [with _Tp = Obstacle&; _Alloc = std::allocator<Obstacle&>; std::vector<_Tp, _Alloc>::allocator_type = std::allocator<Obstacle&>]':

Navigation.ino:36:24: note:   when instantiating default argument for call to std::vector<_Tp, _Alloc>::vector(const allocator_type&) [with _Tp = Obstacle&; _Alloc = std::allocator<Obstacle&>; std::vector<_Tp, _Alloc>::allocator_type = std::allocator<Obstacle&>]

In file included from c:\program files (x86)\arduino\hardware\tools\avr\avr\include\vector:35:0,

                 from Navigation.ino:2:

c:\program files (x86)\arduino\hardware\tools\avr\avr\include\stl_vector.h: In instantiation of 'std::_Vector_base<_Tp, _Alloc>::~_Vector_base() [with _Tp = Obstacle&; _Alloc = std::allocator<Obstacle&>]':

c:\program files (x86)\arduino\hardware\tools\avr\avr\include\stl_vector.h:240:16:   required from 'std::vector<_Tp, _Alloc>::vector(const allocator_type&) [with _Tp = Obstacle&; _Alloc = std::allocator<Obstacle&>; std::vector<_Tp, _Alloc>::allocator_type = std::allocator<Obstacle&>]'

Navigation.ino:36:24:   required from here

c:\program files (x86)\arduino\hardware\tools\avr\avr\include\stl_vector.h:117:21: error: 'struct std::_Vector_base<Obstacle&, std::allocator<Obstacle&> >' has no member named '_M_deallocate'

   ~_Vector_base() { this->_M_deallocate(_Base::_M_start, _Base::_M_end_of_storage - _Base::_M_start); }

                     ^

c:\program files (x86)\arduino\hardware\tools\avr\avr\include\stl_vector.h:117:21: error: '_M_start' is not a member of 'std::_Vector_base<Obstacle&, std::allocator<Obstacle&> >::_Base {aka std::_Vector_alloc_base<Obstacle&, std::allocator<Obstacle&>, true>}'

c:\program files (x86)\arduino\hardware\tools\avr\avr\include\stl_vector.h:117:83: error: '_M_start' is not a member of 'std::_Vector_base<Obstacle&, std::allocator<Obstacle&> >::_Base {aka std::_Vector_alloc_base<Obstacle&, std::allocator<Obstacle&>, true>}'

   ~_Vector_base() { this->_M_deallocate(_Base::_M_start, _Base::_M_end_of_storage - _Base::_M_start); }

                                                                                ^

c:\program files (x86)\arduino\hardware\tools\avr\avr\include\stl_vector.h:117:83: error: '_M_end_of_storage' is not a member of 'std::_Vector_base<Obstacle&, std::allocator<Obstacle&> >::_Base {aka std::_Vector_alloc_base<Obstacle&, std::allocator<Obstacle&>, true>}'

c:\program files (x86)\arduino\hardware\tools\avr\avr\include\stl_vector.h: In instantiation of 'std::_Vector_alloc_base<_Tp, _Allocator, true>::_Vector_alloc_base(const allocator_type&) [with _Tp = Obstacle&; _Allocator = std::allocator<Obstacle&>; std::_Vector_alloc_base<_Tp, _Allocator, true>::allocator_type = std::allocator<Obstacle&>]':

c:\program files (x86)\arduino\hardware\tools\avr\avr\include\stl_vector.h:110:54:   required from 'std::_Vector_base<_Tp, _Alloc>::_Vector_base(const allocator_type&) [with _Tp = Obstacle&; _Alloc = std::allocator<Obstacle&>; std::_Vector_base<_Tp, _Alloc>::allocator_type = std::allocator<Obstacle&>]'

c:\program files (x86)\arduino\hardware\tools\avr\avr\include\stl_vector.h:240:16:   required from 'std::vector<_Tp, _Alloc>::vector(const allocator_type&) [with _Tp = Obstacle&; _Alloc = std::allocator<Obstacle&>; std::vector<_Tp, _Alloc>::allocator_type = std::allocator<Obstacle&>]'

Navigation.ino:36:24:   required from here

c:\program files (x86)\arduino\hardware\tools\avr\avr\include\stl_vector.h:85:53: error: using invalid field 'std::_Vector_alloc_base<_Tp, _Allocator, true>::_M_start'

     : _M_start(0), _M_finish(0), _M_end_of_storage(0)

                                                     ^

c:\program files (x86)\arduino\hardware\tools\avr\avr\include\stl_vector.h:85:53: error: using invalid field 'std::_Vector_alloc_base<_Tp, _Allocator, true>::_M_finish'

c:\program files (x86)\arduino\hardware\tools\avr\avr\include\stl_vector.h:85:53: error: using invalid field 'std::_Vector_alloc_base<_Tp, _Allocator, true>::_M_end_of_storage'

c:\program files (x86)\arduino\hardware\tools\avr\avr\include\stl_vector.h: In instantiation of 'std::vector<_Tp, _Alloc>::~vector() [with _Tp = Obstacle&; _Alloc = std::allocator<Obstacle&>]':

Navigation.ino:36:24:   required from here

c:\program files (x86)\arduino\hardware\tools\avr\avr\include\stl_vector.h:284:42: error: '_M_start' was not declared in this scope

   ~vector() { destroy(_M_start, _M_finish); }

                                          ^

c:\program files (x86)\arduino\hardware\tools\avr\avr\include\stl_vector.h:284:42: error: '_M_finish' was not declared in this scope

Error compiling.

```

# Answer
> 0 votes
```
std::vector<Test&> test

```

Yes, well I doubt you can make a vector of references. A vector of **pointers** I could believe.

See, for example: https://stackoverflow.com/questions/922360/why-cant-i-make-a-vector-of-references

---
Tags: programming, c++
---


# Question
Title: How to setup Arduino Wifi Shield with Red Bear Lab BLE Shield?
I'm new to Arduino shields.

I'm trying to stack these two shields on an arduino uno for a home automation project.

1 - Arduino Wifi Shield:

2 - Red Bear Lab BLE shield: http://redbearlab.com/bleshield/

I have pin contention, between the two shields: The WiFi shield uses pins: 4, 7, 10, 11, 12, 13. The BLE shield uses pins: 10, 11, 12, 13.

Is there a hardware or software way to allow the two shields to work together?

I saw in a similar thread, someone reccomended a go-between shield: https://www.sparkfun.com/products/11002, would this be something that I could use in this case?

If it's not possible, are there other shields that will work together?

Thanks

# Answer
> 1 votes
The way the Arduino talks to each of the shields is by first telling the device that it wants to communicate with it, and then by exchanging information with that device. The Arduino uses 3 pins, 11, 12, and 13, to communicate to both the shields, and a 4th pin which it uses to select which of the devices it wants to use. This way the Arduino can use connect to two shields at once, by just selecting one at a time

I did some research, and found that the selection pin on the WiFi shield (which I believe is the same as yours: https://www.arduino.cc/en/Main/ArduinoWiFiShield) are pins 10 and 4; pin 4 for the SD card selection, and pin 10 for the WiFi selection. Now since pin 10 is used as a selection pin for both the WiFi shield and the BLE shield, you run into some problems: both the boards will be selected at the same time when pin 10 is used. In this case, you can use the Sparkfun go-between board you linked.

I've never used it myself, but it appears to be able to change what pin is attached where on the shield it's attached to. In this case, you want to put the WiFi shield on the bottom, then the Sparkfun go-between shield, then the BLE on the top. You want to set up the go-between shield to change pin numver 10 to another pin that's not being used (any pin but 11, 12, 13, 7, 4, or 10).

In the Arduino code you will at some point declare which pin is being used to select which board. In this case, set the WiFi selection to 10 (default), the SD card selection to 4 (default), and the BLE selection to whatever pin you changed pin 10 from with the go-between shield. This way, when you select the shield on pin 10, it will only select one shield, rather than two.

---
Tags: bluetooth, wifi
---


title: Arduino Motor Shield

text:
# Question
Title: Arduino Motor Shield
It seems that I can't get the DC Motor function to work while also having servos driven off the other ports :(

```
#include "Arduino.h"
#include <Servo.h>

int pinI1=8;//define I1 interface
int pinI2=11;//define I2 interface
int speedpinA=9;//enable motor A
int pinI3=12;//define I3 interface
int pinI4=13;//define I4 interface
int speedpinB=10;//enable motor
int spead =220;//define the spead of motor

Servo SteeringServo;  // create servo object to control a servo

void setup()
{
  // Steering servo pin setup
  SteeringServo.attach(5);  // attaches the servo on pin 9 to the servo object

  pinMode(pinI1,OUTPUT);
  pinMode(pinI2,OUTPUT);
  pinMode(speedpinA,OUTPUT);
  pinMode(pinI3,OUTPUT);
  pinMode(pinI4,OUTPUT);
  pinMode(speedpinB,OUTPUT);

  Serial.begin(9600);

}

void forward()
{
     analogWrite(speedpinA,spead);//input a simulation value to set the speed
     analogWrite(speedpinB,spead);
     digitalWrite(pinI4,HIGH);//turn DC Motor B move clockwise
     digitalWrite(pinI3,LOW);
     digitalWrite(pinI2,LOW);//turn DC Motor A move anticlockwise
     digitalWrite(pinI1,HIGH);
}
void backward()//
{
     analogWrite(speedpinA,spead);//input a simulation value to set the speed
     analogWrite(speedpinB,spead);
     digitalWrite(pinI4,LOW);//turn DC Motor B move anticlockwise
     digitalWrite(pinI3,HIGH);
     digitalWrite(pinI2,HIGH);//turn DC Motor A move clockwise
     digitalWrite(pinI1,LOW);
}
void left()//
{
     analogWrite(speedpinA,spead);//input a simulation value to set the speed
     analogWrite(speedpinB,spead);
     digitalWrite(pinI4,HIGH);//turn DC Motor B move clockwise
     digitalWrite(pinI3,LOW);
     digitalWrite(pinI2,HIGH);//turn DC Motor A move clockwise
     digitalWrite(pinI1,LOW);
}
void right()//
{
     analogWrite(speedpinA,spead);//input a simulation value to set the speed
     analogWrite(speedpinB,spead);
     digitalWrite(pinI4,LOW);//turn DC Motor B move anticlockwise
     digitalWrite(pinI3,HIGH);
     digitalWrite(pinI2,LOW);//turn DC Motor A move clockwise
     digitalWrite(pinI1,HIGH);
}
void stop()//
{
     digitalWrite(speedpinA,LOW);// Unenble the pin, to stop the motor. this should be done to avid damaging the motor.
     digitalWrite(speedpinB,LOW);
     delay(1000);

}

void loop()
{
  left();
  delay(15000);
  stop();
  right();
  delay(1000);
 stop();
 // delay(2000); Already commented out
  //forward();
 // delay(2000);
 // stop();
// backward();
  delay(12000);
  stop();
}

```

# Answer
> 1 votes
Your code:

```
int speedpinA=9;//enable motor A
...
int speedpinB=10;//enable motor
...
 analogWrite(speedpinA,spead);//input a simulation value to set the speed
 analogWrite(speedpinB,spead);

```

See https://www.arduino.cc/en/reference/servo

> On boards other than the Mega, use of the library **disables analogWrite() (PWM) functionality on pins 9 and 10**, whether or not there is a Servo on those pins.

(My emphasis).

So, you can't do that, exactly. Perhaps choose other pins for the analogWrite, pins that analogWrite supports, that are not 9 and 10.

---
Tags: motor, servo, arduino-motor-shield
---


title: Run an Arduino without a PC

text:
# Question
Title: Run an Arduino without a PC
I would like to use an Arduino to make tasks in my life automatic - maybe to rotate every morning a motor, or to open a door.

So, can I run an Arduino as solo with no pc needed? Can i connect it to the Internet and can I setup software like PHP and Apache on it to control it over the internet? Has it any protocols like SSH like a normal server?

As an example: I will send over any protocol a signal to my Arduino with a certification and then the Arduino would run a function...

Is that possible?

thanks ahead

# Answer
> 3 votes
> I will use arduino to make tasks in my life automatic maybe to let rotate every morning a motor or to open the door.

That's the kind of thing it's designed for.

> So i will ask can i run arduino as solo so no pc needed,

Yes, you only need a PC to program it, once programmed it will run without the PC.

> Can I connect it to the internet

Yes, there are Ethernet and WiFi shields available for connecting it to a network.

> and can I setup PHP and Apache on it to control it over it; has it any protocols like SSH like an normal server ?

No. The Arduino isn't powerful enough to run software like that. You would normally connect it via the network / internet to a server to process data. It would just receive simple instructions or send data to the server for processing.

> as example: I will send over any protocol a signal to my Arduino with a certification and then the Arduino is running a function...

I assume by "a certification" you want to run SSL on the Arduino. That's not going to happen since it's way too underpowered for that. As I mentioned earlier, the Arduino would connect to a server on the internet to receive its instructions, or you could interface to it directly within your local network (say from a smart phone) through a simple web server interface (very simplistic due to lack of memory - a few buttons and text, that sort of thing).

---
Tags: programming, remote-control
---


# Question
Title: Which wireless technology should I use for my outside "check-if-door-is-open" project?
I want to connect a magnetic door open/closed sensor to a device that can transmit (or be queried for, whichever) the state of the door to a hub inside (probably RaspberryPi). The outside unit should...

1. Operate on as little power as possible (outside unit will consist of board, open/closed sensor, power, and transmitter)
2. Be able to transmit from my back yard to inside my house (~15 meters to house & 1 or 2 walls).

I am new to this and pretty **confused as to whether I should use BLE, Zig/xbee, or 2.4ghz rf** (is that different? I am not even sure...).

Other considerations are cost (of course) and ease of use. I am a novice with hardware & want something easy to get up and running.

# Answer
> 5 votes
I agree with @Gerben \- the **nRF24L01+** would probably be the most suitable for your application. It should have enough range to go 15m through a few walls, and the cost is about as cheap as you can get.

You can pick up cheap Chinese clone modules (not real nRF24L01+ but another chip that operates exactly the same) for around $2 each on eBay. I by them by the bag full.

There are a few good libraries around for controlling them with an Arduino so programming really isn't much of a problem.

They even have the advantage that they can operate in a mesh network mode if you ever expand your system to incorporate other things.

The connection to the module is a simple 5-wire SPI interface - SDC, MOSI, MISO, Chip Enable and Command Select pins, so you don't even need to mess with lots of wires.

You can read more about using them here: http://playground.arduino.cc/InterfacingWithHardware/Nrf24L01

The best library in existence is the RF24Network library: https://github.com/maniacbug/RF24Network

If you are looking for something more self-contained and stand-alone, you might look at the **ESP8266** modules which are a programmable WiFi module. They can either interface with an Arduino to be controlled through *AT* commands, which is quite nasty, or they can be programmed directly using an Arduino-like API which can be obtained here: https://github.com/esp8266/Arduino

These modules are a little more expensive, but that cost is offset by not then needing an Arduino in the mix as well. The NodeMCU is probably the easiest to work with since it contains the USB serial interface on board like an Arduino. It also has its own *Lua* based programming environment if you don't mind learning another new language, but you can use it with the Arduino API for ESP8266 above.

The ESP8266 is also supported by the beta version of UECIDE

---
Tags: bluetooth, xbee, wireless
---


# Question
Title: Is there any way that the values here be converted to another variable and not string?
```
int val1 =(mfrc522.uid.uidByte[0]);
int val2 =(mfrc522.uid.uidByte[1]);
int val3 =(mfrc522.uid.uidByte[2]);
int val4 =(mfrc522.uid.uidByte[3]);

String valA=String(val1);
String valB=String(val2);
String valC=String(val3);
String valD=String(val4);
uID=valA+valB+valC+valD;

```

The function above with `mfrc522.uid.uidByte[x]` is from the `MFRC522.h` Library by Miguel Balboa and it is initialized as byte there. But when I initialize the val1 to val4 as byte, the desired number doesn't appear. I don't intend to print the uID to serial (as someone may suggest that to readily print to serial as it converts it automatically to some ASCII strings), but instead in the `client.print()` of the Ethernet library along with other codes. I want to save it into another "greater" variable in terms of speed and memory allocation. The Arduino community warns about the use of `String` as it uses additional decoding which is not needed as well as may crash Arduino and make Arduino run out of memory. And somehow, I experience some lagging or hanging in the serial, which I thought maybe due to the use of Strings variable. Please help me. I've read some `sprintf()` concatenations and `free()` but not well documented, I'm quite confused on their explanations. :)

# Answer
> 1 votes
`sprintf()` is a nicer way to do that (imo), however, there's nothing wrong with what you've done-- if you don't have a ton more code, I'd continue to use it.

It's simple and that's a lot more important that speed most of the time. Also, the likely memory usage isn't enough to worry about.

In my experience, once I got past 1500 bytes SRAM (dynamic) memory usage, I ran into trouble. But my projects have a ton of code. I've read through the `String` class code and it's totally reasonable-- you're not likely to experience lag there.

My bet is that the lag is due to the timeout period, try making it smaller.

# Answer
> 0 votes
The UidByte\[\] is a 10 character array, loaded with the tag ID (this is an RFID reader) by the library.

Your code is attempting to put a character value into integer variables.

What you mean to do (I think) is to read the string as a number - this would be `val=atoi(mfrc522.uid.uidByte)` which relies on there being only numeric data in the ID string - or at least, will only read the leading numbers (if any). Also, there are 10 characters in the string - if you want to limit this to 4 you will need slightly more code.

If you have a tag on which you set the ID then this is usable, for your tags at least; but you can't rely on numeric uid's being universal.

If your intent is, as you say, to include it in a longer string, then the overhead of atoi is completely unnecessary and you should just handle it as a string. I think you have misunderstood the warnings about strings, there isn't a problem just handling short chunks of fixed-length data as strings, and I think you are inadvertently causing trouble by extra conversions.

---
Tags: arduino-uno, string, memory-usage
---


# Question
Title: Can a shift register be used to extend the Arduino pins when an ethernet shield is mounted on the Arduino?
I am currently working on a wireless home automation system. The system is connected to a wireless network in the home via the ethernet cable connected the ethernet shield and router. Hence, I need more pins on the Arduino to connect the appliances to be controlled in the home.

# Answer
> 3 votes
You can control a shift register with shiftOut or bit-banged SPI.

My page about SPI has a small library that does bit-banged SPI.

It is also possible to control a shift register using the **same** pins (MOSI/MISO/SCK) that the Ethernet interface uses, as long as you use a different SS (slave select) pin for your shift register. This may not be practical if the Ethernet card is active all the time. It is probably easier to do the bit-banged SPI or use `shiftOut`.

---
Tags: arduino-uno, ethernet
---


# Question
Title: Is my Arduino dead or is it just its processor?
I have a problem with my Arduino. I can't upload any sketches to it (it gives me the error `avrdude: verification error; content mismatch`), but the LEDs are still blinking. Do you think that the whole Arduino is dead or is it just the chip ?

EDIT : I tried an other USB cable but it changed nothing.

EDIT : Here is the output of verbose mode while uploading :

```
Taille binaire du croquis : 1 084 octets (d'un max de 32 256 octets)
/Applications/Arduino.app/Contents/Resources/Java/hardware/tools/avr/bin/avrdude -C/Applications/Arduino.app/Contents/Resources/Java/hardware/tools/avr/etc/avrdude.conf -v -v -v -v -patmega328p -carduino -P/dev/cu.usbmodem641 -b115200 -D -Uflash:w:/var/folders/56/7b6d3xm14n31kjrw8609ywjw0000gn/T/build1168987322216849272.tmp/Blink.cpp.hex:i

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

         System wide configuration file is "/Applications/Arduino.app/Contents/Resources/Java/hardware/tools/avr/etc/avrdude.conf"
         User configuration file is "/Users/trevorannedenise/.avrduderc"
         User configuration file does not exist or is not a regular file, skipping

         Using Port                    : /dev/cu.usbmodem641
         Using Programmer              : arduino
         Overriding Baud Rate          : 115200
avrdude: Send: 0 [30]   [20]
avrdude: Send: 0 [30]   [20]
avrdude: Send: 0 [30]   [20]
avrdude: Recv: . [14]
avrdude: Recv: . [10]
         AVR Part                      : ATMEGA328P
         Chip Erase delay              : 9000 us
         PAGEL                         : PD7
         BS2                           : PC2
         RESET disposition             : dedicated
         RETRY pulse                   : SCK
         serial program mode           : yes
         parallel program mode         : yes
         Timeout                       : 200
         StabDelay                     : 100
         CmdexeDelay                   : 25
         SyncLoops                     : 32
         ByteDelay                     : 0
         PollIndex                     : 3
         PollValue                     : 0x53
         Memory Detail                 :

                                  Block Poll               Page                       Polled
           Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
           ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
           eeprom        65    20     4    0 no       1024    4      0  3600  3600 0xff 0xff
                                  Block Poll               Page                       Polled
           Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
           ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
           flash         65     6   128    0 yes     32768  128    256  4500  4500 0xff 0xff
                                  Block Poll               Page                       Polled
           Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
           ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
           lfuse          0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
                                  Block Poll               Page                       Polled
           Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
           ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
           hfuse          0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
                                  Block Poll               Page                       Polled
           Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
           ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
           efuse          0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
                                  Block Poll               Page                       Polled
           Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
           ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
           lock           0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
                                  Block Poll               Page                       Polled
           Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
           ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
           calibration    0     0     0    0 no          1    0      0     0     0 0x00 0x00
                                  Block Poll               Page                       Polled
           Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
           ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
           signature      0     0     0    0 no          3    0      0     0     0 0x00 0x00

         Programmer Type : Arduino
         Description     : Arduino
avrdude: Send: A [41] . [80]   [20]
avrdude: Recv: . [14]
avrdude: Recv: . [03]
avrdude: Recv: . [10]
avrdude: Send: A [41] . [81]   [20]
avrdude: Recv: . [14]
avrdude: Recv: . [04]
avrdude: Recv: . [10]
avrdude: Send: A [41] . [82]   [20]
avrdude: Recv: . [14]
avrdude: Recv: . [04]
avrdude: Recv: . [10]
avrdude: Send: A [41] . [98]   [20]
avrdude: Recv: . [14]
avrdude: Recv: . [03]
avrdude: Recv: . [10]
         Hardware Version: 3
         Firmware Version: 4.4
avrdude: Send: A [41] . [84]   [20]
avrdude: Recv: . [14]
avrdude: Recv: . [03]
avrdude: Recv: . [10]
avrdude: Send: A [41] . [85]   [20]
avrdude: Recv: . [14]
avrdude: Recv: . [03]
avrdude: Recv: . [10]
avrdude: Send: A [41] . [86]   [20]
avrdude: Recv: . [14]
avrdude: Recv: . [03]
avrdude: Recv: . [10]
avrdude: Send: A [41] . [87]   [20]
avrdude: Recv: . [14]
avrdude: Recv: . [03]
avrdude: Recv: . [10]
avrdude: Send: A [41] . [89]   [20]
avrdude: Recv: . [14]
avrdude: Recv: . [03]
avrdude: Recv: . [10]
         Vtarget         : 0.3 V
         Varef           : 0.3 V
         Oscillator      : 28.800 kHz
         SCK period      : 3.3 us

avrdude: Send: A [41] . [81]   [20]
avrdude: Recv: . [14]
avrdude: Recv: . [04]
avrdude: Recv: . [10]
avrdude: Send: A [41] . [82]   [20]
avrdude: Recv: . [14]
avrdude: Recv: . [04]
avrdude: Recv: . [10]
avrdude: Send: B [42] . [86] . [00] . [00] . [01] . [01] . [01] . [01] . [03] . [ff] . [ff] . [ff] . [ff] . [00] . [80] . [04] . [00] . [00] . [00] . [80] . [00]   [20]
avrdude: Recv: . [14]
avrdude: Recv: . [10]
avrdude: Send: E [45] . [05] . [04] . [d7] . [c2] . [00]   [20]
avrdude: Recv: . [14]
avrdude: Recv: . [10]
avrdude: Send: P [50]   [20]
avrdude: Recv: . [14]
avrdude: Recv: . [10]
avrdude: AVR device initialized and ready to accept instructions

Reading | avrdude: Send: u [75]   [20]
avrdude: Recv: . [14] . [1e] . [95] . [0f] . [10]
################################################## | 100% 0.00s

avrdude: Device signature = 0x1e950f
avrdude: Send: V [56] . [a0] . [03] . [fc] . [00]   [20]
avrdude: Recv: . [14]
avrdude: Recv: . [00]
avrdude: Recv: . [10]
avrdude: Send: V [56] . [a0] . [03] . [fd] . [00]   [20]
avrdude: Recv: . [14]
avrdude: Recv: . [00]
avrdude: Recv: . [10]
avrdude: Send: V [56] . [a0] . [03] . [fe] . [00]   [20]
avrdude: Recv: . [14]
avrdude: Recv: . [00]
avrdude: Recv: . [10]
avrdude: Send: V [56] . [a0] . [03] . [ff] . [00]   [20]
avrdude: Recv: . [14]
avrdude: Recv: . [00]
avrdude: Recv: . [10]
avrdude: reading input file "/var/folders/56/7b6d3xm14n31kjrw8609ywjw0000gn/T/build1168987322216849272.tmp/Blink.cpp.hex"
avrdude: writing flash (1084 bytes):

Writing | avrdude: Send: U [55] . [00] . [00]   [20]
avrdude: Recv: . [14]
avrdude: Recv: . [10]
avrdude: Send: d [64] . [00] . [80] F [46] . [0c] . [94] a [61] . [00] . [0c] . [94] ~ [7e] . [00] . [0c] . [94] ~ [7e] . [00] . [0c] . [94] ~ [7e] . [00] . [0c] . [94] ~ [7e] . [00] . [0c] . [94] ~ [7e] . [00] . [0c] . [94] ~ [7e] . [00] . [0c] . [94] ~ [7e] . [00] . [0c] . [94] ~ [7e] . [00] . [0c] . [94] ~ [7e] . [00] . [0c] . [94] ~ [7e] . [00] . [0c] . [94] ~ [7e] . [00] . [0c] . [94] ~ [7e] . [00] . [0c] . [94] ~ [7e] . [00] . [0c] . [94] ~ [7e] . [00] . [0c] . [94] ~ [7e] . [00] . [0c] . [94] . [9d] . [00] . [0c] . [94] ~ [7e] . [00] . [0c] . [94] ~ [7e] . [00] . [0c] . [94] ~ [7e] . [00] . [0c] . [94] ~ [7e] . [00] . [0c] . [94] ~ [7e] . [00] . [0c] . [94] ~ [7e] . [00] . [0c] . [94] ~ [7e] . [00] . [0c] . [94] ~ [7e] . [00] . [0c] . [94] ~ [7e] . [00] . [00] . [00] . [00] . [00] $ [24] . [00] ' [27] . [00] * [2a] . [00] . [00] . [00] . [00] . [00] % [25] . [00] ( [28] . [00] + [2b] . [00] . [00] . [00] . [00] . [00]   [20]
avrdude: Recv: . [14]
avrdude: Recv: . [10]
#####avrdude: Send: U [55] @ [40] . [00]   [20]
avrdude: Recv: . [14]
avrdude: Recv: . [10]
avrdude: Send: d [64] . [00] . [80] F [46] # [23] . [00] & [26] . [00] ) [29] . [00] . [04] . [04] . [04] . [04] . [04] . [04] . [04] . [04] . [02] . [02] . [02] . [02] . [02] . [02] . [03] . [03] . [03] . [03] . [03] . [03] . [01] . [02] . [04] . [08] . [10]   [20] @ [40] . [80] . [01] . [02] . [04] . [08] . [10]   [20] . [01] . [02] . [04] . [08] . [10]   [20] . [00] . [00] . [00] . [07] . [00] . [02] . [01] . [00] . [00] . [03] . [04] . [06] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [11] $ [24] . [1f] . [be] . [cf] . [ef] . [d8] . [e0] . [de] . [bf] . [cd] . [bf] . [11] . [e0] . [a0] . [e0] . [b1] . [e0] . [ea] . [e3] . [f4] . [e0] . [02] . [c0] . [05] . [90] . [0d] . [92] . [a2] 0 [30] . [b1] . [07] . [d9] . [f7] . [11] . [e0] . [a2] . [e0] . [b1] . [e0] . [01] . [c0] . [1d] . [92] . [ab] 0 [30] . [b1] . [07] . [e1] . [f7] . [0e] . [94] . [0c] . [02] . [0c] . [94] . [1b] . [02] . [0c] . [94] . [00] . [00]   [20]
avrdude: Recv: . [14]
avrdude: Recv: . [10]
######avrdude: Send: U [55] . [80] . [00]   [20]
avrdude: Recv: . [14]
avrdude: Recv: . [10]
avrdude: Send: d [64] . [00] . [80] F [46] . [80] . [91] . [00] . [01] a [61] . [e0] . [0e] . [94] . [b8] . [01] h [68] . [ee] s [73] . [e0] . [80] . [e0] . [90] . [e0] . [0e] . [94] . [e5] . [00] . [80] . [91] . [00] . [01] ` [60] . [e0] . [0e] . [94] . [b8] . [01] h [68] . [ee] s [73] . [e0] . [80] . [e0] . [90] . [e0] . [0e] . [94] . [e5] . [00] . [08] . [95] . [80] . [91] . [00] . [01] a [61] . [e0] . [0e] . [94] y [79] . [01] . [08] . [95] . [1f] . [92] . [0f] . [92] . [0f] . [b6] . [0f] . [92] . [11] $ [24] / [2f] . [93] ? [3f] . [93] . [8f] . [93] . [9f] . [93] . [af] . [93] . [bf] . [93] . [80] . [91] . [06] . [01] . [90] . [91] . [07] . [01] . [a0] . [91] . [08] . [01] . [b0] . [91] . [09] . [01] 0 [30] . [91] . [0a] . [01] . [01] . [96] . [a1] . [1d] . [b1] . [1d] # [23] / [2f] - [2d] _ [5f] - [2d] 7 [37]   [20] . [f0] - [2d] W [57] . [01] . [96] . [a1] . [1d] . [b1] . [1d]   [20] . [93] . [0a] . [01] . [80] . [93]   [20]
avrdude: Recv: . [14]
avrdude: Recv: . [10]
######avrdude: Send: U [55] . [c0] . [00]   [20]
avrdude: Recv: . [14]
avrdude: Recv: . [10]
avrdude: Send: d [64] . [00] . [80] F [46] . [06] . [01] . [90] . [93] . [07] . [01] . [a0] . [93] . [08] . [01] . [b0] . [93] . [09] . [01] . [80] . [91] . [02] . [01] . [90] . [91] . [03] . [01] . [a0] . [91] . [04] . [01] . [b0] . [91] . [05] . [01] . [01] . [96] . [a1] . [1d] . [b1] . [1d] . [80] . [93] . [02] . [01] . [90] . [93] . [03] . [01] . [a0] . [93] . [04] . [01] . [b0] . [93] . [05] . [01] . [bf] . [91] . [af] . [91] . [9f] . [91] . [8f] . [91] ? [3f] . [91] / [2f] . [91] . [0f] . [90] . [0f] . [be] . [0f] . [90] . [1f] . [90] . [18] . [95] . [9b] . [01] . [ac] . [01] . [7f] . [b7] . [f8] . [94] . [80] . [91] . [02] . [01] . [90] . [91] . [03] . [01] . [a0] . [91] . [04] . [01] . [b0] . [91] . [05] . [01] f [66] . [b5] . [a8] . [9b] . [05] . [c0] o [6f] ? [3f] . [19] . [f0] . [01] . [96] . [a1] . [1d] . [b1] . [1d] . [7f] . [bf] . [ba] / [2f] . [a9] / [2f] . [98] / [2f] . [88] ' [27] . [86] . [0f] . [91] . [1d]   [20]
avrdude: Recv: . [14]
avrdude: Recv: . [10]
######avrdude: Send: U [55] . [00] . [01]   [20]
avrdude: Recv: . [14]
avrdude: Recv: . [10]
avrdude: Send: d [64] . [00] . [80] F [46] . [a1] . [1d] . [b1] . [1d] b [62] . [e0] . [88] . [0f] . [99] . [1f] . [aa] . [1f] . [bb] . [1f] j [6a] . [95] . [d1] . [f7] . [bc] . [01] - [2d] . [c0] . [ff] . [b7] . [f8] . [94] . [80] . [91] . [02] . [01] . [90] . [91] . [03] . [01] . [a0] . [91] . [04] . [01] . [b0] . [91] . [05] . [01] . [e6] . [b5] . [a8] . [9b] . [05] . [c0] . [ef] ? [3f] . [19] . [f0] . [01] . [96] . [a1] . [1d] . [b1] . [1d] . [ff] . [bf] . [ba] / [2f] . [a9] / [2f] . [98] / [2f] . [88] ' [27] . [8e] . [0f] . [91] . [1d] . [a1] . [1d] . [b1] . [1d] . [e2] . [e0] . [88] . [0f] . [99] . [1f] . [aa] . [1f] . [bb] . [1f] . [ea] . [95] . [d1] . [f7] . [86] . [1b] . [97] . [0b] . [88] ^ [5e] . [93] @ [40] . [c8] . [f2] ! [21] P [50] 0 [30] @ [40] @ [40] @ [40] P [50] @ [40] h [68] Q [51] | [7c] O [4f] ! [21] . [15] 1 [31] . [05] A [41] . [05] Q [51] . [05] q [71] . [f6] . [08] . [95] x [78] . [94] . [84] . [b5]   [20]
avrdude: Recv: . [14]
avrdude: Recv: . [10]
######avrdude: Send: U [55] @ [40] . [01]   [20]
avrdude: Recv: . [14]
avrdude: Recv: . [10]
avrdude: Send: d [64] . [00] . [80] F [46] . [82] ` [60] . [84] . [bd] . [84] . [b5] . [81] ` [60] . [84] . [bd] . [85] . [b5] . [82] ` [60] . [85] . [bd] . [85] . [b5] . [81] ` [60] . [85] . [bd] . [ee] . [e6] . [f0] . [e0] . [80] . [81] . [81] ` [60] . [80] . [83] . [e1] . [e8] . [f0] . [e0] . [10] . [82] . [80] . [81] . [82] ` [60] . [80] . [83] . [80] . [81] . [81] ` [60] . [80] . [83] . [e0] . [e8] . [f0] . [e0] . [80] . [81] . [81] ` [60] . [80] . [83] . [e1] . [eb] . [f0] . [e0] . [80] . [81] . [84] ` [60] . [80] . [83] . [e0] . [eb] . [f0] . [e0] . [80] . [81] . [81] ` [60] . [80] . [83] . [ea] . [e7] . [f0] . [e0] . [80] . [81] . [84] ` [60] . [80] . [83] . [80] . [81] . [82] ` [60] . [80] . [83] . [80] . [81] . [81] ` [60] . [80] . [83] . [80] . [81] . [80] h [68] . [80] . [83] . [10] . [92] . [c1] . [00] . [08] . [95] . [cf] . [93] . [df] . [93] H [48] / [2f] P [50] . [e0] . [ca] . [01] . [86] V [56] . [9f] O [4f]   [20]
avrdude: Recv: . [14]
avrdude: Recv: . [10]
######avrdude: Send: U [55] . [80] . [01]   [20]
avrdude: Recv: . [14]
avrdude: Recv: . [10]
avrdude: Send: d [64] . [00] . [80] F [46] . [fc] . [01] 4 [34] . [91] J [4a] W [57] _ [5f] O [4f] . [fa] . [01] . [84] . [91] . [88] # [23] i [69] . [f1] . [90] . [e0] . [88] . [0f] . [99] . [1f] . [fc] . [01] . [e8] Y [59] . [ff] O [4f] . [a5] . [91] . [b4] . [91] . [fc] . [01] . [ee] X [58] . [ff] O [4f] . [c5] . [91] . [d4] . [91] f [66] # [23] Q [51] . [f4] / [2f] . [b7] . [f8] . [94] . [8c] . [91] . [93] / [2f] . [90] . [95] . [89] # [23] . [8c] . [93] . [88] . [81] . [89] # [23] . [0b] . [c0] b [62] 0 [30] a [61] . [f4] / [2f] . [b7] . [f8] . [94] . [8c] . [91] . [93] / [2f] . [90] . [95] . [89] # [23] . [8c] . [93] . [88] . [81] . [83] + [2b] . [88] . [83] / [2f] . [bf] . [06] . [c0] . [9f] . [b7] . [f8] . [94] . [8c] . [91] . [83] + [2b] . [8c] . [93] . [9f] . [bf] . [df] . [91] . [cf] . [91] . [08] . [95] H [48] / [2f] P [50] . [e0] . [ca] . [01] . [82] U [55] . [9f] O [4f] . [fc] . [01] $ [24] . [91] . [ca] . [01]   [20]
avrdude: Recv: . [14]
avrdude: Recv: . [10]
######avrdude: Send: U [55] . [c0] . [01]   [20]
avrdude: Recv: . [14]
avrdude: Recv: . [10]
avrdude: Send: d [64] . [00] . [80] F [46] . [86] V [56] . [9f] O [4f] . [fc] . [01] . [94] . [91] J [4a] W [57] _ [5f] O [4f] . [fa] . [01] 4 [34] . [91] 3 [33] # [23] . [09] . [f4] @ [40] . [c0] " [22] # [23] Q [51] . [f1] # [23] 0 [30] q [71] . [f0] $ [24] 0 [30] ( [28] . [f4] ! [21] 0 [30] . [a1] . [f0] " [22] 0 [30] . [11] . [f5] . [14] . [c0] & [26] 0 [30] . [b1] . [f0] ' [27] 0 [30] . [c1] . [f0] $ [24] 0 [30] . [d9] . [f4] . [04] . [c0] . [80] . [91] . [80] . [00] . [8f] w [77] . [03] . [c0] . [80] . [91] . [80] . [00] . [8f] } [7d] . [80] . [93] . [80] . [00] . [10] . [c0] . [84] . [b5] . [8f] w [77] . [02] . [c0] . [84] . [b5] . [8f] } [7d] . [84] . [bd] . [09] . [c0] . [80] . [91] . [b0] . [00] . [8f] w [77] . [03] . [c0] . [80] . [91] . [b0] . [00] . [8f] } [7d] . [80] . [93] . [b0] . [00] . [e3] / [2f] . [f0] . [e0] . [ee] . [0f] . [ff] . [1f] . [ee] X [58] . [ff] O [4f] . [a5] . [91] . [b4] . [91] / [2f] . [b7]   [20]
avrdude: Recv: . [14]
avrdude: Recv: . [10]
######avrdude: Send: U [55] . [00] . [02]   [20]
avrdude: Recv: . [14]
avrdude: Recv: . [10]
avrdude: Send: d [64] . [00] < [3c] F [46] . [f8] . [94] f [66] # [23] ! [21] . [f4] . [8c] . [91] . [90] . [95] . [89] # [23] . [02] . [c0] . [8c] . [91] . [89] + [2b] . [8c] . [93] / [2f] . [bf] . [08] . [95] . [cf] . [93] . [df] . [93] . [0e] . [94] > [3e] . [01] . [0e] . [94] . [97] . [00] . [c0] . [e0] . [d0] . [e0] . [0e] . [94] . [80] . [00]   [20] . [97] . [e1] . [f3] . [0e] . [94] . [00] . [00] . [f9] . [cf] . [f8] . [94] . [ff] . [cf] . [0d] . [00]   [20]
avrdude: Recv: . [14]
avrdude: Recv: . [10]
### | 100% 0.21s

avrdude: 1084 bytes of flash written
avrdude: verifying flash memory against /var/folders/56/7b6d3xm14n31kjrw8609ywjw0000gn/T/build1168987322216849272.tmp/Blink.cpp.hex:
avrdude: load data flash data from input file /var/folders/56/7b6d3xm14n31kjrw8609ywjw0000gn/T/build1168987322216849272.tmp/Blink.cpp.hex:
avrdude: input file /var/folders/56/7b6d3xm14n31kjrw8609ywjw0000gn/T/build1168987322216849272.tmp/Blink.cpp.hex contains 1084 bytes
avrdude: reading on-chip flash data:

Reading | avrdude: Send: U [55] . [00] . [00]   [20]
avrdude: Recv: . [14]
avrdude: Recv: . [10]
avrdude: Send: t [74] . [00] . [80] F [46]   [20]
avrdude: Recv: . [14]
avrdude: Recv: . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff]
avrdude: Recv: . [10]
#####avrdude: Send: U [55] @ [40] . [00]   [20]
avrdude: Recv: . [14]
avrdude: Recv: . [10]
avrdude: Send: t [74] . [00] . [80] F [46]   [20]
avrdude: Recv: . [14]
avrdude: Recv: . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff]
avrdude: Recv: . [10]
######avrdude: Send: U [55] . [80] . [00]   [20]
avrdude: Recv: . [14]
avrdude: Recv: . [10]
avrdude: Send: t [74] . [00] . [80] F [46]   [20]
avrdude: Recv: . [14]
avrdude: Recv: . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff]
avrdude: Recv: . [10]
######avrdude: Send: U [55] . [c0] . [00]   [20]
avrdude: Recv: . [14]
avrdude: Recv: . [10]
avrdude: Send: t [74] . [00] . [80] F [46]   [20]
avrdude: Recv: . [14]
avrdude: Recv: . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff]
avrdude: Recv: . [10]
######avrdude: Send: U [55] . [00] . [01]   [20]
avrdude: Recv: . [14]
avrdude: Recv: . [10]
avrdude: Send: t [74] . [00] . [80] F [46]   [20]
avrdude: Recv: . [14]
avrdude: Recv: . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff]
avrdude: Recv: . [10]
######avrdude: Send: U [55] @ [40] . [01]   [20]
avrdude: Recv: . [14]
avrdude: Recv: . [10]
avrdude: Send: t [74] . [00] . [80] F [46]   [20]
avrdude: Recv: . [14]
avrdude: Recv: . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff]
avrdude: Recv: . [10]
######avrdude: Send: U [55] . [80] . [01]   [20]
avrdude: Recv: . [14]
avrdude: Recv: . [10]
avrdude: Send: t [74] . [00] . [80] F [46]   [20]
avrdude: Recv: . [14]
avrdude: Recv: . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff]
avrdude: Recv: . [10]
######avrdude: Send: U [55] . [c0] . [01]   [20]
avrdude: Recv: . [14]
avrdude: Recv: . [10]
avrdude: Send: t [74] . [00] . [80] F [46]   [20]
avrdude: Recv: . [14]
avrdude: Recv: . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff]
avrdude: Recv: . [10]
######avrdude: Send: U [55] . [00] . [02]   [20]
avrdude: Recv: . [14]
avrdude: Recv: . [10]
avrdude: Send: t [74] . [00] < [3c] F [46]   [20]
avrdude: Recv: . [14]
avrdude: Recv: . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff]
avrdude: Recv: . [10]
### | 100% 0.16s

avrdude: verifying ...
avrdude: verification error, first mismatch at byte 0x0000
         0x0c != 0xff
avrdude: verification error; content mismatch
avrdude: Send: Q [51]   [20]
avrdude: Recv: . [14]
avrdude: Recv: . [10]

avrdude done.  Thank you.

```

# Answer
It's possible you have a non-fatal problem

* check power
* check connections
* reflash the Arduino bootloader

If your Arduino has a socketed microcontroller you can try swapping it out with one that has the bootloader preloaded.
> 11 votes

# Answer
I've faced this problem several times! If you are using arduino UNO, make sure to remove any serial connected device on the (Tx,RX) pins. Upload your sketch, then connect them back again. It's because the arduino UNO has on serial pins which is used for uploading the code, there will be a conflict if there was a device that is connected to the serial the same time you upload the code.
> 2 votes

# Answer
I had faced similar problems and the solution that worked for me was to power the burning circuit with the Arduino onboard 5 volt. 3.3 Volt does work but at times it gives these errors especially while burning the bootloader.
> 1 votes

# Answer
This happened to me with a bare-bones Arduino. I disconnected everything and it still happens. I don't know what the cause is but you definitely will need to reflash the bootloader or replace the chip.

It isn't a connection or power issue, and it isn't related to having devices connected to pins 0/1 (although that can also cause problems, it will give a different error).
> 0 votes

---
Tags: arduino-uno, uploading, atmega328
---