body:
I started recently working with a uBlox Neo 6M GPS module (data sheet [http://www.u-blox.com/images/downloads/Product_Docs/NEO-6_DataSheet_(GPS.G6-HW-09005).pdf][1]). I connected it to an Arduino Uno as shown:

GPS  Arduino
VCC-- 3.3V
RX -- D11
TX -- D10
GND-- GND

I tried this example code from TinyGps++ (of course, changing the pins and the gpsbaud to 9600, which is the gps' default).

<!-- language: c -->

    #include <TinyGPS++.h>
    #include <SoftwareSerial.h>
    /*
       This sample sketch demonstrates the normal use of a TinyGPS++ (TinyGPSPlus) object.
       It requires the use of SoftwareSerial, and assumes that you have a
       4800-baud serial GPS device hooked up on pins 4(rx) and 3(tx).
    */
    static const int RXPin = 10, TXPin = 11;
    static const uint32_t GPSBaud = 9600;

    // The TinyGPS++ object
    TinyGPSPlus gps;

    // The serial connection to the GPS device
    SoftwareSerial ss(RXPin, TXPin);

    void setup() {
      Serial.begin(115200);
      ss.begin(GPSBaud);
      Serial.println(F("DeviceExample.ino"));
      Serial.println(F("A simple demonstration of TinyGPS++ with an attached GPS module"));
      Serial.print(F("Testing TinyGPS++ library v. ")); Serial.println(TinyGPSPlus::libraryVersion());
      Serial.println(F("by Mikal Hart"));
      Serial.println();
    }

    void loop() {
      // This sketch displays information every time a new sentence is correctly encoded.
      while (ss.available() > 0)
        if (gps.encode(ss.read()))
          displayInfo();
      if (millis() > 5000 && gps.charsProcessed() < 10) {
        Serial.println(F("No GPS detected: check wiring."));
        while(true);
      }
    }

    void displayInfo() {
      Serial.print(F("Location: "));
      if (gps.location.isValid()) {
        Serial.print(gps.location.lat(), 6);
        Serial.print(F(","));
        Serial.print(gps.location.lng(), 6);
      } else {
        Serial.print(F("INVALID"));
      }

      Serial.print(F("  Date/Time: "));
      if (gps.date.isValid()) {
        Serial.print(gps.date.month());
        Serial.print(F("/"));
        Serial.print(gps.date.day());
        Serial.print(F("/"));
        Serial.print(gps.date.year());
      } else {
        Serial.print(F("INVALID"));
      }

      Serial.print(F(" "));
      if (gps.time.isValid()) {
        if (gps.time.hour() < 10) Serial.print(F("0"));
        Serial.print(gps.time.hour());
        Serial.print(F(":"));
        if (gps.time.minute() < 10) Serial.print(F("0"));
        Serial.print(gps.time.minute());
        Serial.print(F(":"));
        if (gps.time.second() < 10) Serial.print(F("0"));
        Serial.print(gps.time.second());
        Serial.print(F("."));
        if (gps.time.centisecond() < 10) Serial.print(F("0"));
        Serial.print(gps.time.centisecond());
      } else {
        Serial.print(F("INVALID"));
      }
      Serial.println();
    }

However, I do not get the GPS LED to blink, as well as my Arduino's RX LED, so the module is not transmitting any data. This is the output from the code:

    A simple demonstration of TinyGPS++ with an attached GPS module
        Testing TinyGPS++ library v. 0.92
        by Mikal Hart

        Location: INVALID  Date/Time: 0/0/2000 00:00:00.00
        Location: INVALID  Date/Time: 0/0/2000 00:00:00.00

Thanks!

  [1]: http://www.u-blox.com/images/downloads/Product_Docs/NEO-6_DataSheet_(GPS.G6-HW-09005).pdf

title: uBlox Neo 6M GPS module not responding

Answers: 4

body:
Try to connect your GPS module with an FTDI cable directly to the Serial-Port of your computer (and read it with screen or any other terminal program). Once that works, proceed with the Arduino.
And check what your GPS-module not blinking does mean. Usually it says there is no 'fix', which means it does not see enough satellites. The output you showed would fit into that theory. Which would mean everything is ok, except your module is not seeing the sky...

body:
The Neo 6M takes a bit of time to fix when first powered on. If your board is fitted with a small battery it will most probably be flat and will take an hour or two to charge up. It is there to provide charge to the EEPROM and the onboard RTC.

Also check that the leads on the battery are not shorting.

You do not get a valid data sentence out of the GPS until the RTC can sync time.

The Error message that you got from Mike Hart routine first says that there is not enough data to do a FIX and second the Date Time is not syncing.

body:
1) Try outside or near the window.
because the signal may not reach inside a house.

2)Check the connection.

3) Print the number of satellites connection to know the device is connectied by
```
Serial.println(gps.satellites.value());
```
Good luck!!!

body:
After 2 days of troubleshooting I found the solution

 1. Use 3.3 volt external supply
 2. Use voltage dividers to make 3.3 volt compatible to module
 3. go outside(open space)

That's it


body:
I am thinking about building a circuit that is literally going to take 11 of the 14 digital pins of an `UNO` to communicate with an SD card and an external EEPROM chip (EEPROM programmer).

Using 4 shift registers and the SD card, I will have 1 digital pin left.  Well, I'm also reserving pins 0/1 for serial communication.

Anyway, I need to read some external buttons and I have the 6 analog pins that I haven't touched.

I will only need about 4-5 push buttons in my design so they should fit nicely on A0+.

So, my question is, will I run into any issues doing this?  Or, are the analog inputs better left for true analog reading?

Thanks.

title: Is it wise to use analog input pins to read digital buttons?

Answers: 2

body: If you have no use for analog pins there is no problem. A5/A6 are used for I²C (on the Uno).

body:
The Analog pins are essentially identical in functionality to digital pins when used as digital I/O.

If desired you could "be clever" and use an analog input in analog mode to read multiple keys using one pin. eg using 10k, 22k, 39k, 82k, 150k in series with 5 buttons from V+ to pin and a say 4k7 to ground would result in 5 voltages which were easily distinguished using an analog read. This is a very very old technique indeed and allows far more than 5 keys on one input pin. THere are limitations which can be discussed if required.

R1 ... R5 correspond to buttons 1...5

Vout = V+ x Rb / (Rb + Rbutton)

Example only

Rb = 39k
R1 = 10k
R2 = 22k
R3 = 39k
R4 = 82k
R5 = 150k

Gives

 - The % of V+ in column 2 when a button is pressed.

 - The voltage in column 3 with V+ = 5V

Delta-V is the difference between that key and the one below - very ample clearance.

![enter image description here][1]

![enter image description here][2]

  [1]: https://i.stack.imgur.com/F9KCN.jpg
  [2]: https://i.stack.imgur.com/Cq9kc.jpg


body:
I am using Arduino IDE to program my ATmegas with bootloaders. I can directly manipulate ports, use timers, interrupts, PWM pins and timers, etc. Everything is working.

But this question arises: Does the Arduino IDE differ from AVR Studio in terms of using C or C++ on an ATmega chip?

I know AVR Studio has some features or something. My question is not about that. My question is that I am coding everything, not using extra libraries, features etc.

title: Is Arduino IDE enough to program with C or C++?

Answers: 2

body:
In terms of the core language features, there's virtually no difference. In the background, the Arduino IDE and Atmel/AVR Studio both use [GCC][1] to compile the code.

GCC is an excellent toolset which supports all the core language features of C++. Admittedly, the version which currently comes with the Arduino IDE is a little old, so it doesn't support C++11 onwards. However, a lot of C++11 features are not very relevant or useful for microcontroller programming anyway (e.g. threading).

You're also likely to use the same standard library for both, which is [AVR Libc][2]. It provides pretty much all the standard C functionality that you're likely to use in an AVR project. It doesn't include the C++ stuff though, such as streams, containers, and algorithms. These tend to be very resource-hungry though, so are best avoided anyway.

The major difference is basically flexibility. Atmel/AVR Studio is designed to let you work on a wide range of projects and customize the build to suit very specific needs. You can also use alternative libraries with it more easily. In theory, the Arduino IDE can be modified in similar ways, but it's a major hassle because it provides no GUI to do it.

It's also important to note that the Arduino IDE does a number of non-standard things, such as re-organising declarations and including libraries in strange ways. It's designed to be more user-friendly, but often ends up just getting in the way. There are usually ways to work around those issues though.

  [1]: https://gcc.gnu.org/
  [2]: http://www.nongnu.org/avr-libc/

body:
It is unclear exactly what you are asking. The Arduino is different to most computers - it has NO OS (if you exclude the bootloader).

You can use a c/c++ compiler which translates your code to machine code. If you include libraries this may include machine code which someone else has compiled into a library.

You could write 100% of your code in assembler and produce exactly the same result.
Even in the good (bad?) old days of the 1970s before we had compilers on microprocessors it was common to have prewritten code (libraries) for common functions.

You haven't lived until you have written your own assembler (hand coded).


body: I know and I can program any AVR microcontroller with Arduino IDE and Arduino Uno board. Can I use Arduino board with AVR Studio? Or I have to buy an AVR Development board?

title: Can I program AVR Microcontrollers using Arduino Development board with AVR Studio?

Answers: 2

body: You can use Atmel Studio to write code for the MCU(s) on the Arduino boards. If the IDE itself does not support *uploading* the code to the Arduino then it is still possible to use AVRDUDE or BOSSA to upload it via the command line.

body:
There is an [Arduino plugin](http://www.visualmicro.com/) available for AVR Studio, which allows you to upload sketches to an Arduino, just like you would with the Arduino IDE. I think this also enables you to upload plain C/C++ files created with the standard AVR tools.

Alternatively, if you have an AVR ISP programmer, you can use this to upload compiled C/C++ to the Arduino from AVR studio without needing the Arduino plugin.


body:
Im using a Arduino Mega 2560, and I tried to connect a us-100 ultrasonic sensor for distance measurement.

I connected it as shown in the image ![connection][1]

 The code I used was:

    const int trigger=6;
    const int echo=7;
    float distance;
    void setup(){
    Serial.begin(9600);
    pinMode(trigger,OUTPUT);
    pinMode(echo,INPUT);
    }
    void loop(){
    // Trigger US-100 to start measurement
    // Set up trigger
    digitalWrite(trigger,LOW);
    delayMicroseconds(5);
    // Start Measurement
    digitalWrite(trigger,HIGH);
    delayMicroseconds(10);
    digitalWrite(trigger,LOW);
    // Acquire and convert to mtrs
    distance=pulseIn(echo,HIGH);
    distance=distance*0.0001657;
    // send result to UART
    Serial.println(distance);
    delay(50);
    }

But It won't work, as in the only output i get is 0.00 cm as shown in the image ![sm][2]

 Can someone tell me if I'm doing something wrong(also, i tried putting two probes between the vcc and one of the gnd pins, and a resistance was shown.This should mean the sensor isn't broken.yes?)? this is my first time using arduino and I greatly appreciate help to fix this.

  [1]: https://i.stack.imgur.com/SfgzB.jpg
  [2]: https://i.stack.imgur.com/jjsjG.jpg

title: US-100 Ultrasound sensor doesn't work on Arduino mega 2560

Answers: 1

body:
Have you removed the "Serial Data Mode" shunt to put the device in "Pulse Width Mode"?

On the other hand, perhaps the "Serial Data Mode" would actually work better for your application?

Where I work, we have a coding style that strongly encourages
all "magic numbers" to be documented
with a link to the website it came from
or a reference to the book and page it came from.

Would something like this work for you?:

    void loop(){
        // Trigger US-100 to start measurement
        // at least 50 us high, then set it low,
        // as recommended by
        // https://www.bananarobotics.com/shop/US-100-Ultrasonic-Distance-Sensor-Module
        digitalWrite(trigger,HIGH);
        delayMicroseconds(50);
        digitalWrite(trigger,LOW);
        // Acquire
        unsigned long echo_microseconds = pulseIn(echo,HIGH);
        // debugging
        serial.println( echo_microseconds );
        Serial.println(F(" microseconds"));
        // conversion factor from
        // https://www.bananarobotics.com/shop/US-100-Ultrasonic-Distance-Sensor-Module
        unsigned long distance_mm = echo_microseconds * 34 / 100 / 2;
        Serial.print(distance_mm);
        Serial.println(F(" mm"));
        delay(50);
    }

It might be easier to use the Ping library as described at
[Arduino-Info: UltraSonic Distance Measurement][1].

You might find the
[Arduino Forum: Measuring Distances with Ultrasonic Sensors][2]
thread educational.

  [1]: http://arduino-info.wikispaces.com/UltraSonicDistance
  [2]: http://forum.arduino.cc/index.php?topic=130925.0


body:
In the process of trying to make a small system that will last a while on 4 AA batteries, I've reduced my Arduino project to a barebones system that when asleep draws a tiny amount of current from the batteries.

However, to achieve this, I found it would be necessary to cut power to the two attached peripheral devices (connected to an ATMega328P-PU). One of them is an I2C device, and the other is a serial device, and both are attached to the hardware serial/I2C pins as appropriate.

In terms of powering the peripherals, the bases of two transistors are connected to two of the digital pins, and power to them is controlled from code via these transistors. Both devices are 5V, and when the system is running the total current draw is around 200mA.

Basically this setup works, however I'm getting "random" system hanging and essentially an unreliable project. Sometimes when I power it up it will work as normal, but then hang and not sleep. Other times, it will sleep, but then freeze after waking or just get stuck during waking (which I can tell because the serial device powers up first and does nothing, but the I2C device remains off).

My best guess is the root of the cause is either something to do with the serial communication being interrupted by sleeping the MPU (I'm using the maximum power saving sleep, which is woken by an external interrupt on pin 2), or possibly some sort of power problem (sudden current draw from battery?) that occurs when the peripherals are powered on in code (though I don't know how I should test this).

So far, I've tried calling `Serial.end()` before sleeping the MPU, and `Serial.being(9600)` on waking, and have scattered `delay(1000)`s throughout to ensure everything has enough time to get running, but the problem still remains.

Does anyone have any pointers on things I could change/test, or an alternative approach I could take to make the same power savings?

EDIT: Some more details

The transitors used are TIP 120's. The connections are essentially an exact copy of the image here: https://ctheds.files.wordpress.com/2007/10/tip120.jpg, except the resistors used are 560 Ohms (just what I had to hand, no other reason, didn't think it would change anything).

The I2C peripheral is a 20x4 LCD (which I believe is HD44780 compliant). The serial device is an GT511C3 fingerprint sensor. I don't believe either of them have any automatic power saving features, though I haven't looked for such things in the documentation explicitly.

The exact code I use to call sleep is

    set_sleep_mode(SLEEP_MODE_PWR_DOWN);
    sleep_enable();
    sleep_mode();

which I'm lead to believe is the lowest power mode, and aside from this problem works well for my system.

title: Unstable system when controlling power to serial peripheral devices and sleeping

Answers: 2

body:
I hear great things about the cosa core for Arduino. It's a fantastic alternative Arduino core and exposes the power management capabilities of the micro-controller that are not exposed by the standard Arduino core.

You might find it is too different for your experience but then again it is excellent and worth a look.

[https://github.com/mikaelpatel/Cosa][1]

  [1]: https://github.com/mikaelpatel/Cosa

body:
Using an NPN transistor to control power to a peripheral may be problematic.

An NPN transitor would presumably be used as a `low-side switch` interrupting the peripheral's ground line, however, even when turned on this will have a non-trivial voltage drop.

Most logic level definitions are asymmetric, ie, the maximimum legal voltage for a logic "0" is relatively low. If you insert the voltage drop of a bipolar transistor into a peripheral's ground line, then it may be borderline unable to drive a fully legal '0' to the ATmega, which is reference to the lower true ground and would see the peripheral's ground difference added to its output voltage.

A better approach would be to use either a high-side switch (as there is typically more room between the minimum legal '1' and the supply) or else to use an FET switch which would have a much lower voltage drop.

Also keep in mind that most IC's are not specified to tolerate lasting I/O voltages much outside of the range of their power suppliers, and in fact their protection diodes may mean that application of such voltages effectively powers them through the I/O pin.  So before turning off power to a peripheral, you probably want the ATmega software to assert all shared I/O lines towards the side of the peripheral supply which is not being disconnected, ie, for a low side switch drive everything high and for a high side switch drive everything low.

Finally, the process of power cycling could potentially confuse peripheral interface engines and it is possible that some error flags set in this process might never be cleared.  So you may want to clear the flags of and generally re-initialize your USART, I2C, etc on resume.


body:
I am currently working on reading pressure values using a tekscan a201 sensor. The sensors I have are limited to 25lbs.

My plan is to use eight on these sensors of them with a arduino Mega. Since I am measuring the resistance, I am thinking of making a 8 similar voltage divider circuits and grabbing the voltage reading via arduinos analog pins.

At the moment, I am not sure how to convert these readings to engineering units. Any ideas?

title: Pressure Sensor and Arduino

Answers: 2

body:
I have not previously met the Flexscan sensors but from the datasheet it appears that there are versions of the A201 rated at 100 pounds are you committed to the 25 lbf version?

[**A201 datasheet here**](https://www.google.co.nz/url?sa=t&rct=j&q=&esrc=s&source=web&cd=3&ved=0CEkQFjAC&url=http://www.tekscan.com/pdf/FLX-A201-force-sensor.pdf&ei=cszJVOrPJZLN8gWU_4Bw&usg=AFQjCNGNy5nCyCNgagOzaIMfsUIpSFlRGg&sig2=_D791hWWRz5tzqHSp0zcxg&bvm=bv.84607526,d.dGY&cad=rja)

Here is a [**15 page user manual**](https://www.google.co.nz/url?sa=t&rct=j&q=&esrc=s&source=web&cd=5&ved=0CFUQFjAE&url=http://www.tekscan.com/pdf/FLX-FlexiForce-Sensors-Manual.pdf&ei=cszJVOrPJZLN8gWU_4Bw&usg=AFQjCNGCYZTma0vkXT0e2BsH7Y07yQ_tcw&sig2=ZMxG630bjh44caLTmokRJg&bvm=bv.84607526,d.dGY&cad=rja) thatexplains how to produce a voltage output using a single opamp per sensor - bottom of page 9.

[Many idea starters **here**](https://www.google.co.nz/search?q=tekscan+a201&biw=1745&bih=977&source=lnms&tbm=isch&sa=X&ei=cszJVOrPJZLN8gWU_4Bw&ved=0CAYQ_AUoAQ)

_____________

What is your application and why do you wish to use these sensors. These seem to be a low accuracy alternative to eg load cells and seem to be expensive for what you get. If you need 8 for your task a loadcell based solution may e cheaper.

body:
I decided go with the voltage divider approach as it seemed simple enough. The sensors themselves needed to be calibrated, which took me a while as I didn't have the required weights.

After the calibration, I used the line of best fit approach to find an equation that translated voltage to force.


body:
I am designing a board for my electronics project and i am using a number of ATTiny85 for it. The ATTiny's will be SMD so i will not be able to remove them for programming.

Moreover all of the pins of my uCs will be used for connections (apart from reset).

Is it possible in this case to achieve that, any ideas and suggestions are welcome

EDIT: Well, Vcc and Ground will be common, i will be using an external oscillator for all of them, the reset pin will be free, the other three pins will be used for gpio communication between the attinys.
I am connecting about 10 attiny in a daisy chain kind of thing

title: Programming an Array of ATTiny

Answers: 2

body:
Well you need access to pins 0 & 1 to program them, so you either do it off-board, or design in a way to access them - perhaps a PCB hole you can wire to temporarily, or a link you can fit/remove that changes the connection.

You will probably need to program them before the rest of the board gets filled up?

You havn't said what you will be connecting to these pins nor how many is an "array" which kind of limits how specific we can be here!

body:
As long as whatever you're connecting the MISO, MOSI, and SCK pins to doesn't mind being driven externally, you can still program the ATTiny in-circuit - just break out those pins with reset to a standard 6 pin header and program them that way.

If one or more of those pins can't be driven externally (eg, because they're connected to another device that drives them and has no output disable), you'll need to add a tristate buffer IC between the MCU and the other device, or some jumpers you can remove when you want to program them.


body:
(This might be more of a common C question)

I want to test several conditions in an IF-sentence

    if(variable) {            // fastest check
      if(register) {          // a bit slower
        if(read_peripheral) { // very slow check
          // [do something]
        }
      }
    }

It seems obvious that I want to start with the fastest check, and move on to the slower ones afterwards, potentially avoiding to check them if the above was false.

Now since I need to check quite a few conditions, I'd like to know if the following is the same, or if all conditions will be evaluated prior to making a decision?

    if(variable && register && read_peripheral) {
      // [do something]
    }

title: Chain of, or one big if sentence

Answers: 1

body:
Putting them all in a single condition like that is absolutely fine. C/C++ uses "short circuit evaluation" which means it will stop as soon as it's determined the outcome. If everything is combined using logical AND operators (&&) then that means it will stop as soon as one of them evaluates to false.

For example:

     if (blah() && foo()) { ... }

If `blah()` returns false, it will never call `foo()` at all because it already knows the overall outcome is false.

The reverse happens with the logical OR operator (||):

     if (blah() || foo()) { ... }

If `blah()` returns *true* in this case, it won't call `foo()`. That's because it already knows the overall outcome is true.


body:
I bought a HC-06 Module for my Arduino Uno the other day, yesterday it arrived and I'm having trouble using it with the Arduino IDE.

I set it up, connecting 5V, GND and RX/TX crossed. After a bit of searching, it shows up on the bluetooth settings on the macbook. When I click "connect", it fails, after I click "Options", then set the Pin to 1234 it says "Connected". The LED on the HC-06 is still blinking (which is OK I guess, since I'm not yet communicating).

I have a Sketch running on the Uno that prints out some text. When I open the serial monitor (after connecting like above) it works, displaying the values I expect. However, after closing the serial monitor the HC-06 changes to "not connected" on the mac.

Also, if I try to upload code via the Arduino IDE it states: `avrdude: ser_open(): can't open device "/dev/tty.HC-06-DevB": Resource busy
ioctl("TIOCMGET"): Inappropriate ioctl for device` or throws a `processing.app.SerialException: Fehler beim Öffnen des seriellen Ports "/dev/tty.HC-06-DevB".` (German for "Error while opening Serial Port "/dev...." ").

Do I have to configure the HC-06 or the Arduino IDE in any way to make this work, and, if so, how can I do that?

**Edit:**
I've also connected TX and RX uncrossed, though that alone doesn't solve the problem.

Thanks in advance for your Support!

title: Can't program Arduino via Bluetooth (HC-06) with a Mac

Answers: 4

body:
If I remember correctly, you do not want to cross TX and RX.

Usually, you cross TX/RX because you are looking at it from the opposite side - the PC's TX is the Arduino's RX and vice-versa.

However, in the case of BlueTooth, the HC-06 has the same perspective as the Arduino - TX (transmit) is TX on the HC-06, since that is what the HC-06 transmits (over Bluetooth).

Also, if you are connect your Arduino via USB, the TX & RX are also connected via USB; I don't know if this would cause cross-talk. It shouldn't (so long as you don't send to your Arduino using Bluetooth AND USB at the same time), but it may. Also, as you're programming the Arduino using Bluetooth, you may get the Arduino's responses coming back to you via Bluetooth.

ADDITIONAL:

Go read http://arduino.cc/en/Hacking/Bootloader?from=Tutorial.Bootloader - this is all about the bootloader.

It seems from that that current bootloaders run at 19200, some older ones run at 9600. There are commands to program the speed on HC-06 - instructions can be found at http://www.instructables.com/id/AT-command-mode-of-HC-05-Bluetooth-module/ (this covers the hc-06 too).

Based on the bootloader tutorial, I think you have "less than a second" (only two specific boards are mentioned, so this is a best guess; I am amazed that it is this long, I expected a few milliseconds). If you have a USBISP, you could compile and upload a new firmware, with settings more to your liking - this is outside the scope of this article.

Another option is to create a completely separate uploader - an AtTiny could do it. Connect the AtTiny to the serial port, and then get the AtTiny to reset and program the board, or even program it via ICSP. This is a lot of work, and also outside the scope of this article.

body: Regarding the ability to upload, that is correct - you won't be able to upload code via Bluetooth. In addition to providing a serial connection, the USB connection does something extra (hold reset, I think), when you upload via serial-over-usb.

body:
The on-board USB-to-serial pulses the reset line to start the bootloader. HC-0x don't have the extra signal available that USB uses for that so you'll have to manually reset the Arduino just as - or very slightly after - you click to start the upload on your Mac; you may need to experiment to get the timing right, but once you know it, it isn't hard to do. Keep Rx & Tx crossed as you do for Bluetooth terminal communication. And even with all that, I've never achieved anything like USB upload speeds (baud rate for baud rate) using Bluetooth.

Update:<br>
In brief, it could be timing, baud-rate, or pairing.

I find it easy to get the timing: hold reset / click (and let go) the upload button / release reset. It doesn't need to be so fast that it's a challenge to coordinate but do it faster than counting seconds.

Your HC-06's baud rate will have to match the baud-rate your boot-loader expects. It looks like Uno's bootloader's use 19200 baud (and there are some way older ones that used 9600). My bare, pre-programmed chips' boot-loaders from Adafruit.com use 57600 baud. Your `preferences.txt` file should contain a line like 'atmega328o.upload.speed=115200'; assuming you're able to upload via USB, then use this baud rate for the HC-06. (The path to your preferences file is displayed on the Arduino IDE's preferences dialog.)

The 'Resource busy' message sounds like your Mac isn't paired with your HC-06. In the MacOS Bluetooth System Preferences pane, pair the Mac with the HC-06 and be sure HC-06's LED is on steady (not blinking).

body:
After dealing with the problem for several hours I unexpectedly solve the problem.

The HC-06's LED keep blinking after I entered the "1234" code. In my case (I'm using Windows 10), the HC-06 status changed to "connected" for few seconds and then changed to "Paired". Once I opened the correct COM port to receive data from the HC-06 to my PC computer, the LED changed to solid ON. Then I was able to catch data from my Arduino UNO. As soon as I closed the COM port in my PC (I used CoolTerm), the LED changed to blinking back again. The COM port I used to receive the data was the one indicated with direction "Outgoing" in the PC's Bluetooth settings. So, I was expecting the HC-06 to behave as my Bluetooth speakers or my Bluetooth headphones: Always connected. I was wrong and it cost me several hours of testing.

In my firsts tests I focused opening the COM port with direction "Incoming". Nothing happened here and I lost a lot of time. I tested my wiring between the arduino and the HT-06 module by changing the device name from "HC-06" to "ArduinoBT01" and it worked.

This is the sketch I used to receive data form the Arduino via Bluetooth:

[![enter image description here][1]][1]

This is the CoolTerm's window capture:

[![enter image description here][3]][3]

Mysteriously, the CoolTerm speed setting is 14400bps but the speed in the device manager for COM34 is 9600bps. After triying opening many times the COM34 port with 9600bps I got this error in CoolTerm:

"An error occurred while attempting to open the port".
"1168: Error 1168"

So, it only works with 14400 bps. Crazy!!

I hope this helps.

Sorry for bugs in my English.

  [1]: https://i.stack.imgur.com/HKL3M.jpg
  [2]: https://i.stack.imgur.com/3J3A6.jpg
  [3]: https://i.stack.imgur.com/XOD8q.jpg
  [4]: https://i.stack.imgur.com/5laAg.jpg


body: I'd like to use an Arduino Yún in a somewhat outdoor environment (in a metal box on a truck).  I think I've seen that the temperature requirements of the Uno are -40 °C to +85 °C, but I can't find that information about the Yún.  It would be nice to know where to find information about the temperature and humidity safe working requirements for every Arduino model.

title: What are the environmental requirements of an Arduino?

Answers: 1

body:
The AtMega32u4 (the chip that drives the Arduino Yun) has an operating requirement of -40 to +85, so if you go outside that range, you will definitely void warranty (which is not to say it will break, of course!). See datasheet at http://www.atmel.com/devices/atmega32u4.aspx

A datasheet for the AR9331 seems to say that it only works down to 0°C ( http://www.eeboard.com/wp-content/uploads/downloads/2013/08/AR9331.pdf page 305, "Commercial Case Temperature") - this seems awfully high for a minimum temperature.

While that does not mean that, inside that range, you are safe, I would *GUESS* that you probably are - I would guess that the AtMega32u4 or AR9331 is going to be the most delicate part in there.

Of course, to get a definitive answer, you (or someone) would have to check the specs on each part.


body: if I solder the jumper pads on the adafruit cc3000 for use with the Arduino Mega will it still work fine with the Uno?

title: Adafruit CC3000 jumper pads

Answers: 1

body:
**This module is designed to be "plug in and go"** without access to anything except the connector pads at the board edge. While there are a number of pads on the face of the board these are for "experts only" access and are unneeded for normal operation.

The only soldering required should be the addition of a 9 pin row of pins to allow the CC3000 module to be plugged into a solderless breadboard or a socket. If this is all you do then the module will work directly and interchangeably with  Arduino Uno, Leonardo/Micro & Mega. These are the only Arduino versions that a full library is available for so far. ADAFruit promise more versions will be supported "sometime".

Additional information is available from
 [WIRELESS / WIFI / ADAFRUIT HUZZAH CC3000 WIFI BREAKOUT WITH ONBOARD ANTENNA](http://www.adafruit.com/product/1469)

Solder on connector and go ...

[**Larger version of photo here** makes pin use clear - + see link above](https://i.stack.imgur.com/9uoaZ.jpg)

![enter image description here][1]

_____________________

Example use [**weather station**](https://learn.adafruit.com/wifi-weather-station-arduino-cc3000)

[**Low power use tutorial**](https://learn.adafruit.com/low-power-wifi-datalogging)

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

Example use [**wireless lamp**](https://learn.adafruit.com/wireless-power-switch-with-arduino-and-the-cc3000-wifi-chip)

[**Library**](https://learn.adafruit.com/adafruit-cc3000-wifi/cc3000-library-software)


body:
I am looking for the source and/or proper definition for the int() function.
I have searched through the source in Arduino.app, without much success.

The reference gives a terse explanation

 int(x)
  x: a value of any type
  Converts a value to the int data type

Passing 1, '1' or 49 returns the int 1. I haven't tested other types.

This seems to be an Arduino specific function - it doesn't seem to be in any c/c++ library.

Answers: 1

body:
`int(x)` is not a function but **another way to perform an explicit cast** of `x` to an `int`. It is part of the C++ language itself, that is why you could not find it in a library.

This is not Arduino-specific.

In C and C++ you can cast a value to an int by doing this:

    int y = (int) x;

**C++** has extended this notation by allowing to do it this way, which is equivalent:

    int y = int(x);

You can find this [in more details][1] in C++ language reference.

  [1]: http://en.cppreference.com/w/cpp/language/explicit_cast


body:
I am working on a project that needs to drive a relay board. I'm looking at the ETHERNET board with PoE and according to the documentation here (http://arduino.cc/en/Main/ArduinoBoardEthernet) the output of the PoE module is 9V.

Is that the voltage to expect out of the Vin pin?

The Relay board that I want to use (http://numato.com/downloads/dl/file/id/29/product/47/user_manual.pdf) specifies that it wants a 7-12V power supply.

I want to confirm that this is the case so I can use the voltage out of the PoE and I don't need to add a separate DC power supply to this system.

title: What is Vin for the EthernetPOE board?

Answers: 2

body:
I wouldn't expect you to take any power from V-**in**-, but it actually seems like you can!

If you take a look at the [schematic][1] for the Rev.3 Arduino Ethernet, you can see the power rails from Ethernet is connected to Vin. (`V1+`, `V1-`, `V2+`, `V2-` --> `Vin` in the leftmost part of the schematic)

  [1]: http://arduino.cc/en/uploads/Main/arduino-ethernet-R3-schematic.pdf

body:
Your question is a little confusing, so let me give you a couple pieces of information.

First things first - the VIn pin on the Arduino is strictly for power going to the Arduino board, you shouldn't be drawing power from this pin. The documentation in the link you sent is a little misleading on this - it's basically saying 9v is coming OUT of the PoE module, and going IN to the VIn on the Arduino itself. If you wanted to tap into this 9v power, you should connect to the PoE module VOut instead.

PoE by default can deliver 37-57 volts or 42-57 volts, depending on what type of PoE you're using (which 802.3 specification). [Wikipedia](http://en.wikipedia.org/wiki/Power_over_Ethernet#Standard_implementation) has a good overview of this information.

That being said, the Arduino Ethernet board you're using can't handle this voltage by itself - unless these boards have changed, they require an additional [PoE module](http://store.arduino.cc/product/X000002), which is basically just a DC-to-DC buck converter that will convert the high PoE voltage down to 9v or 12v. At this point, the Arduino's built-in converter can consume that 9 or 12v and distribute it at 5v across the board.

Now, to your problem - you want to power a relay that requires 7-12v. You could theoretically connect the relay to the VOut of the PoE module, giving you 12v. However, if the relay draws too much power for too long, you will either get brownouts (and your Arduino will restart) or potentially damage the Arduino board. Unless the relay draws a lot of current or is being powered for extended periods, you should be fine. If you want to be more thorough, you could put a large capacitor between your PoE module and the relay.

You should NOT try to connect the relay directly to the PoE VOut, as the voltage will be far too high.


body:
I'm just starting off with using the Arduino and was learning about PWM
(http://arduino.cc/en/Tutorial/PWM).
Below is what my circuit looks like.

![enter image description here][1]

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

Below is the very simple code.

    const int pinNine = 9;    // LED connected to digital pin 9

    void setup() {
      // initialize serial communications at 9600 bps:
      Serial.begin(9600);
      // set the digital pins as outputs
      pinMode(pinNine,OUTPUT);
    }

    void loop() {
      analogWrite(pinNine, 0);
    }

I was expecting my LED to not be lighted as its a 0% duty cycle. I even change the pinNine outputValue to (64, 127, etc) but for some reason the LED is always lighted. Any ideas?

_____________________________________________

title: Issue with PWM output pin

Answers: 4

body:
I have a few things you could try:

 1. Remove `pinMode(pinNine, OUTPUT)`, this is only used for digitalWrite(), the PWM controller might be affected by this.
 2. Did you select the correct Arduino Chip in the IDE? Arduino maps pin 9 to a hardware pin (PB1 for UNO), which is not consistent between different boards
 3. Try inserting a `delay(100)` after `analogWrite(...)`. I'm not sure if the analogWrite call restarts the PWM cycle, resulting in very fast switching that might be seen as 'always on'

Other than that, your sketch seems to be correct. I assume the black wire in the breadboard is wired to Ground, correct?

body:
Added at top:

**Your code runs correctly on a $US3 Arduino Nano** :-)

It seems extremely likely that you have a hardware problem of some sort.

If you have a voltmeter you can try these easy checks.
I carried these out to be sure that I got what was expected and the results are as you would expect them to me. Use a meter set to DC Volts - typical common meter circuitry averages the PWM well.

1. Remove LED etc connection to pin 9.
Measure the voltage from the 5V pin to ground. If powered from USB this will usually be slightly below 5V.

2. Run your code with the analogWrite set to 128 ie

   analogWrite(pinNine, 128);

3. Measure the voltage on pin 9 relative to ground. It should be close tohalf the voltage on the 5V pin in 1. above. This is because the analogWrite value is controlled by PWM with values from 0 to 255. 128/255 ~= 50% so output is 50% of Vref = 5V by default. in a 5V system.

4. Set analogWrite to

        analogWrite(pinNine, 25);

5. The voltage on pin9 should be about 10% of the voltage on the 5V pin.

IF you get approximately the voltages shown in 3. and 5. your code is working OK and your hardware is OK.  If not then 'summat aglae'.

Try another analog pin.

Check that the red wire to the LED goes to UNO ground.

The voltmeter is a surer way of checking that the LED is as you can see actual numeric values that result.

____________________

**OLDER:**

It always helps greatly if you show PIN IDs on photos so people can be confident re what you have done.

If you view the whole UNO-R2-R3 connector with numbering it is obvious that the important pinouts are the same.
If however you view part of the connector with no numbering/ pin names shown,  then on the R3 there are additional pins on the ARef end of the connector which make comparisons'more difficult).

You APPEAR to have an Arduino UNO R3
It would help if you gave actual model and weblink in future "just in case it matters". .

You appear to have connected to pin 9  (as you intended to)
Pin 9 has PWM capability, as required.
It seems that your code should work.

Thusly

![enter image description here][1]

IF the red wire connects to ground the circuit seems electrically correct.
Does it?

Code LOOKS OK.

Try digital write on / off on pin 9 to see if LED changes and that the port behaves as expected. A bad port pin is possible.

What pin is serial on?

Try another pin with PWM capability to see if it changes.

____________________

ARDUINO UNO R3 from [UNO home page](http://arduino.cc/en/Main/arduinoBoardUno)

The connector pinouts vary widely between models of UNO.

![enter image description here][2]

  [1]: https://i.stack.imgur.com/lC2XS.jpg
  [2]: https://i.stack.imgur.com/ErT8E.jpg

body:
Flat side of LED is `-`. This means that your white wire is on `-` side and your red wire on `+` side. Therefore your power rail connection is reversed... and therefore your LED is ON when you send `0` on PWM. By the way, you will set the LED OFF by writing `255` on PWM.

Solution: connect power rails correctly and everything will be back to normal.

body:
Ok, it seems my understanding of the PWM was wrong. I tried the circuit and code from here (http://arduino.cc/en/Tutorial/Fade) and it worked as expected (fade in and out).

Actually when i wrote my original code i was expecting the LED to blink. So, as i got closer to 255 i was expecting it to spend more time being 'lit', as compared to 0 where it should spend less time being 'lit'.

> I even change the pinNine outputValue to (64, 127, etc) but for some
> reason the LED is always lighted.

It being lighted makes sense. What i missed out was it being dimmer when the value was lower.

Thanks for all your help..


body:
As a programmer I am new and lack some knowledge in electronic and I will appreciate the help.

I wish to connect 3 Adafruit NeoPixel NeoMatrix 8x8 - 64 RGB LED Pixel Matrix (https://www.adafruit.com/products/1487) can some one please provide me a scheme how to connect/tile 3 these NeoMatrix 8x8 to one Arduino Uno.

Thanks a lot

title: Tile NeoPixel NeoMatrix 8x8

Answers: 3

body:
On [**the page that you cite**](https://www.adafruit.com/products/1487) they say

If, say, you need MORE blinky, **you can chain these together.**

 - For the second shield, connect the DIN connection to the first panel's DOUT.

 - Also connect a ground pin together

 - and power with 5V.

 - There you go!

You can chain as many as you'd like although after 4 or more panels you may run low on RAM if you're using an UNO. Watch your power usage too, you may need a 5V 10A power supply for so many of these!

________________

Related:

They also say:

 - There is a single data line with a very timing-specific protocol. Since the protocol is very sensitive to timing, it requires a real-time microconroller such as an AVR, Arduino, PIC, mbed, etc. It cannot be used with a Linux-based microcomputer or interpreted microcontroller such as the netduino or Basic Stamp.

 Our wonderfully-written Neopixel library for Arduino supports these pixels! As it requires hand-tuned assembly it is only for AVR cores but others may have ported this chip driver code so please google around.

 An 8MHz or faster processor is required.

body:
On the products page, they link to the [Neopixel Uberguide][1], which should really contain what you need :-)

The good thing about the NeoPixels is that they can be chained, since each pixel is supplied with VCC, GND, Data in and Data out. Data out of LED1 will be data in for LED2, and afaik you can make infinitely long chains this way

  [1]: https://learn.adafruit.com/adafruit-neopixel-uberguide

body:
I found the http://fastled.io/ libary to be a useful and well documented (https://github.com/FastLED/FastLED/wiki/Overview) alternative to Adafruit's NeoPixel library.

FastLED has some clever compression of palettes, and many other nice features that might save you valuable memory when using many neopixels.


body:
I am working on a project that involves sending motion sensing data wirelessly from an arduino to computer. Sensor readings have to be transmitted continuously (say every mili second). I am not sure if Xbee is my bet. I came across [this link][1]
which suggest s that there should be atleast 10 ms delay between packets if you're using xbees.

What are your experiences with xbees? I don't want to waste money.

  [1]: http://www.faludi.com/projects/common-xbee-mistakes/p://

title: Getting sensor data wirelessly from arduino to PC

Answers: 1

body:
Xbee costs about 1000INR. They are really expensive. You should buy HC-05 module, which costs about 320INR.
You can easily interface them with Bluetooth of your Laptop using Processing Application.

You can even use ESP8266 ESP-01 Wireless Module. They Cost about 3$.
Wireless module gets connected with your router. [this][2] tutorial will help you to start. You can by this module from [here][4].

nRF24l01+ modules can not be interfaced with Laptop...

  [2]: http://www.instructables.com/id/ESP8266-Wifi-Temperature-Logger/
  [4]: http://www.banggood.com/ESP8266-Remote-Serial-Port-WIFI-Transceiver-Wireless-Module-p-947259.html?p=IY04239401772014128X


body:
I have a RFID module using NXP RC522 chipset.
![Chipset][1]

I have no idea that is it correct the module using 27.120 mHz
![27.120 mHz][2]

And I have 4 IC card,

A) 0005302176, (Blue color tag, come with the RFID module)
B) 0008846830 134,65006 (White card, come with the RFID module)
C) 0004189112 063,60344 (White card)
D) White card, no number print on the card. Only this card UID can be read.

![4 IC Cards][3]

Here is the pinout
![Pinout][4]
Which I connected to Arduino UNO R3

     RFID         UNO R3
(Pin Name, Pin)    (Pin)
SDA        1        10
SCK        2        13
MOSI       3        11
MISO       4        12
IRQ        5        -No Connect-
GND        6        Ground
RST        7        9
3.3V       8        3.3V

PS: I am using this library, and this example.

PS: The serial return this information `MFRC522 Software Version: 0x91 = v1.0`

  [1]: https://i.stack.imgur.com/nnf3b.jpg
  [2]: https://i.stack.imgur.com/qSZxU.jpg
  [3]: https://i.stack.imgur.com/cRJ2j.jpg
  [4]: https://i.stack.imgur.com/SkJaH.jpg

title: Unable to read the IC Card UID

Answers: 2

body:
Check your power source, if you are powering the module from arduino/USB=>part or something like that, there can be not much power for the module.
Also you can try powering it 5v (not 3,3 as they should be powered by reference).

In my case I have had problems reading some types of cards, and I have solved that problems by giving better power supply, also higher power supply than in reference for some of the cards.

"By magic" the cards that were not working started working as a charm.

Also you should check if the cards you are using are all  ISO14443 A

Only that kind of cards is compatible with that reader.
So if you got type B, or other type of ISO cards, that will not be working.
Some of them may use different frequency, there is a bunch of standards around.

Also as said before the cards can be damaged, or could be corrupted if you tried reading UID while writing to the card, the problem is known , and in that case you can damage the UID.

I hope it helps you.
cheers

body: The MFRC522 reader is for 13.56 Mhz tags; these tags normally dont have the UID printed on them, in my experience. 125khz cards, however, usually have their SNs printed on them; as you can see all the cards that didnt work, have a 10 digit SN that seems to follow the same pattern. These card SNs can't be read by the MFRC522, as they follow a different protocol. When you buy a tag/card, make sure that its a 13.56 Mhz tag (look for Mifare tags), if you want the MFRC522 to be able to read it.


body:
Situation:

Mac OS, Arduino IDE 1.5.6r2

I've got a sketch with several files, all classic .cpp and .h source and header files except the main sketch file. As the project goes more complex I started to generate code automatically by another program. Now I have hard times integrating the generated code it into my sketch. The arduino IDE seems to load the code on opening the sketch. After that, the source files aren't beeing checked for external changes by the IDE (as I would expect it from a real editor like *vim*). On top of that, when I verify my code the IDE seems to save the files from RAM into a temporary build directory ignoring the contents of the sketch directory further. So if I let my code generator change a source file while the sketch is opened in the IDE, the changes won't reach the build. I had to close the IDE and reopen it. The next thing I tried is to include my autogenerated file from an existing and opened code file inside the IDE. But the IDE ignores files, which aren't opened completely. Hence, the file is missing in the build directory.

Is there a trick to let the IDE take the code unknown to itself along into the build directory? Or how else can I deal with this situation? I don't want to close and open the IDE a hundred times a day.

title: Good way to get automatically generated code into a sketch

Answers: 1

body:
According to the release notes starting with V1.5.2 of the IDE you can verify and upload from the command line.

You could use your favorite editor and then use the command line to do the arduino build/upload instead of the IDE.

See: https://github.com/arduino/Arduino/blob/ide-1.5.x/build/shared/manpage.adoc

I have not used it so I can't say if it work well or not.


body:
I downloaded the RTClib library from <https://github.com/adafruit/RTClib>.  In every provided example, `#include <Wire.h>` is written immediately above `#include "RTClib.h"` at the top of the sketch.

Why is this necessary?  I know the RTClib library requires the functionality of the Wire library but, if this is the case, why can't I just `#include <Wire.h>` at the top of RTClib.h?  I have tried the latter, even using just the following sketch, but my sketch failed to compile.

RTClib.h:

    // Code by JeeLabs http://news.jeelabs.org/code/
    // Released to the public domain! Enjoy!

    #ifndef _RTCLIB_H_
    #define _RTCLIB_H_

    #include <Wire.h>
    ...

    #endif // _RTCLIB_H_

Sketch:

    #include "RTClib.h"
    void setup() {}
    void loop() {}

title: RTClib library dependency on Wire library

Answers: 1

body:
Not getting too formal here, The arduino IDE looks at which libraries are included in the top level sketch when deciding what libraries to include in the compilation.

It would make sense for only RTClib.h to include Wire.h yes, but the IDE does not get the information to add Wire to the compilation list that way. It is a quirk of the IDE that makes implementing libraries that use other libraries a bit more painful.


body:
Me and my friend recently built a Breadboard Arduino. It switches on fine, and the LED changes a bit. I have added a 5V FTDI cable, but it wouldn't upload, trying to fix this, I used my friends 5V FTDI Basic USB-To-Serial converter chip, thinking this would upload fine, as it was new, but it still wouldn't upload, giving the very long error:

    Arduino: 1.5.8 (Windows XP), Board: "Arduino Duemilanove or Diecimila, ATmega328"

    Build options changed, rebuilding all

    C:\Program Files\Arduino/hardware/tools/avr/bin/avr-g++ -c -g -Os -w -fno-exceptions -ffunction-sections -fdata-sections -fno-threadsafe-statics -MMD -mmcu=atmega328p -DF_CPU=16000000L -DARDUINO=158 -DARDUINO_AVR_DUEMILANOVE -DARDUINO_ARCH_AVR -IC:\Program Files\Arduino\hardware\arduino\avr\cores\arduino -IC:\Program Files\Arduino\hardware\arduino\avr\variants\standard C:\DOCUME~1\George\LOCALS~1\Temp\build7021919583125132986.tmp\sketch_jan31a.cpp -o C:\DOCUME~1\George\LOCALS~1\Temp\build7021919583125132986.tmp\sketch_jan31a.cpp.o

    C:\Program Files\Arduino/hardware/tools/avr/bin/avr-gcc -c -g -Os -w -ffunction-sections -fdata-sections -MMD -mmcu=atmega328p -DF_CPU=16000000L -DARDUINO=158 -DARDUINO_AVR_DUEMILANOVE -DARDUINO_ARCH_AVR -IC:\Program Files\Arduino\hardware\arduino\avr\cores\arduino -IC:\Program Files\Arduino\hardware\arduino\avr\variants\standard C:\Program Files\Arduino\hardware\arduino\avr\cores\arduino\hooks.c -o C:\DOCUME~1\George\LOCALS~1\Temp\build7021919583125132986.tmp\hooks.c.o

    C:\Program Files\Arduino/hardware/tools/avr/bin/avr-gcc -c -g -Os -w -ffunction-sections -fdata-sections -MMD -mmcu=atmega328p -DF_CPU=16000000L -DARDUINO=158 -DARDUINO_AVR_DUEMILANOVE -DARDUINO_ARCH_AVR -IC:\Program Files\Arduino\hardware\arduino\avr\cores\arduino -IC:\Program Files\Arduino\hardware\arduino\avr\variants\standard C:\Program Files\Arduino\hardware\arduino\avr\cores\arduino\WInterrupts.c -o C:\DOCUME~1\George\LOCALS~1\Temp\build7021919583125132986.tmp\WInterrupts.c.o

    C:\Program Files\Arduino/hardware/tools/avr/bin/avr-gcc -c -g -Os -w -ffunction-sections -fdata-sections -MMD -mmcu=atmega328p -DF_CPU=16000000L -DARDUINO=158 -DARDUINO_AVR_DUEMILANOVE -DARDUINO_ARCH_AVR -IC:\Program Files\Arduino\hardware\arduino\avr\cores\arduino -IC:\Program Files\Arduino\hardware\arduino\avr\variants\standard C:\Program Files\Arduino\hardware\arduino\avr\cores\arduino\wiring.c -o C:\DOCUME~1\George\LOCALS~1\Temp\build7021919583125132986.tmp\wiring.c.o

    C:\Program Files\Arduino/hardware/tools/avr/bin/avr-gcc -c -g -Os -w -ffunction-sections -fdata-sections -MMD -mmcu=atmega328p -DF_CPU=16000000L -DARDUINO=158 -DARDUINO_AVR_DUEMILANOVE -DARDUINO_ARCH_AVR -IC:\Program Files\Arduino\hardware\arduino\avr\cores\arduino -IC:\Program Files\Arduino\hardware\arduino\avr\variants\standard C:\Program Files\Arduino\hardware\arduino\avr\cores\arduino\wiring_analog.c -o C:\DOCUME~1\George\LOCALS~1\Temp\build7021919583125132986.tmp\wiring_analog.c.o

    C:\Program Files\Arduino/hardware/tools/avr/bin/avr-gcc -c -g -Os -w -ffunction-sections -fdata-sections -MMD -mmcu=atmega328p -DF_CPU=16000000L -DARDUINO=158 -DARDUINO_AVR_DUEMILANOVE -DARDUINO_ARCH_AVR -IC:\Program Files\Arduino\hardware\arduino\avr\cores\arduino -IC:\Program Files\Arduino\hardware\arduino\avr\variants\standard C:\Program Files\Arduino\hardware\arduino\avr\cores\arduino\wiring_digital.c -o C:\DOCUME~1\George\LOCALS~1\Temp\build7021919583125132986.tmp\wiring_digital.c.o

    C:\Program Files\Arduino/hardware/tools/avr/bin/avr-gcc -c -g -Os -w -ffunction-sections -fdata-sections -MMD -mmcu=atmega328p -DF_CPU=16000000L -DARDUINO=158 -DARDUINO_AVR_DUEMILANOVE -DARDUINO_ARCH_AVR -IC:\Program Files\Arduino\hardware\arduino\avr\cores\arduino -IC:\Program Files\Arduino\hardware\arduino\avr\variants\standard C:\Program Files\Arduino\hardware\arduino\avr\cores\arduino\wiring_pulse.c -o C:\DOCUME~1\George\LOCALS~1\Temp\build7021919583125132986.tmp\wiring_pulse.c.o

    C:\Program Files\Arduino/hardware/tools/avr/bin/avr-gcc -c -g -Os -w -ffunction-sections -fdata-sections -MMD -mmcu=atmega328p -DF_CPU=16000000L -DARDUINO=158 -DARDUINO_AVR_DUEMILANOVE -DARDUINO_ARCH_AVR -IC:\Program Files\Arduino\hardware\arduino\avr\cores\arduino -IC:\Program Files\Arduino\hardware\arduino\avr\variants\standard C:\Program Files\Arduino\hardware\arduino\avr\cores\arduino\wiring_shift.c -o C:\DOCUME~1\George\LOCALS~1\Temp\build7021919583125132986.tmp\wiring_shift.c.o

    C:\Program Files\Arduino/hardware/tools/avr/bin/avr-g++ -c -g -Os -w -fno-exceptions -ffunction-sections -fdata-sections -fno-threadsafe-statics -MMD -mmcu=atmega328p -DF_CPU=16000000L -DARDUINO=158 -DARDUINO_AVR_DUEMILANOVE -DARDUINO_ARCH_AVR -IC:\Program Files\Arduino\hardware\arduino\avr\cores\arduino -IC:\Program Files\Arduino\hardware\arduino\avr\variants\standard C:\Program Files\Arduino\hardware\arduino\avr\cores\arduino\abi.cpp -o C:\DOCUME~1\George\LOCALS~1\Temp\build7021919583125132986.tmp\abi.cpp.o

    C:\Program Files\Arduino/hardware/tools/avr/bin/avr-g++ -c -g -Os -w -fno-exceptions -ffunction-sections -fdata-sections -fno-threadsafe-statics -MMD -mmcu=atmega328p -DF_CPU=16000000L -DARDUINO=158 -DARDUINO_AVR_DUEMILANOVE -DARDUINO_ARCH_AVR -IC:\Program Files\Arduino\hardware\arduino\avr\cores\arduino -IC:\Program Files\Arduino\hardware\arduino\avr\variants\standard C:\Program Files\Arduino\hardware\arduino\avr\cores\arduino\CDC.cpp -o C:\DOCUME~1\George\LOCALS~1\Temp\build7021919583125132986.tmp\CDC.cpp.o

    C:\Program Files\Arduino/hardware/tools/avr/bin/avr-g++ -c -g -Os -w -fno-exceptions -ffunction-sections -fdata-sections -fno-threadsafe-statics -MMD -mmcu=atmega328p -DF_CPU=16000000L -DARDUINO=158 -DARDUINO_AVR_DUEMILANOVE -DARDUINO_ARCH_AVR -IC:\Program Files\Arduino\hardware\arduino\avr\cores\arduino -IC:\Program Files\Arduino\hardware\arduino\avr\variants\standard C:\Program Files\Arduino\hardware\arduino\avr\cores\arduino\HardwareSerial.cpp -o C:\DOCUME~1\George\LOCALS~1\Temp\build7021919583125132986.tmp\HardwareSerial.cpp.o

    C:\Program Files\Arduino/hardware/tools/avr/bin/avr-g++ -c -g -Os -w -fno-exceptions -ffunction-sections -fdata-sections -fno-threadsafe-statics -MMD -mmcu=atmega328p -DF_CPU=16000000L -DARDUINO=158 -DARDUINO_AVR_DUEMILANOVE -DARDUINO_ARCH_AVR -IC:\Program Files\Arduino\hardware\arduino\avr\cores\arduino -IC:\Program Files\Arduino\hardware\arduino\avr\variants\standard C:\Program Files\Arduino\hardware\arduino\avr\cores\arduino\HardwareSerial0.cpp -o C:\DOCUME~1\George\LOCALS~1\Temp\build7021919583125132986.tmp\HardwareSerial0.cpp.o

    C:\Program Files\Arduino/hardware/tools/avr/bin/avr-g++ -c -g -Os -w -fno-exceptions -ffunction-sections -fdata-sections -fno-threadsafe-statics -MMD -mmcu=atmega328p -DF_CPU=16000000L -DARDUINO=158 -DARDUINO_AVR_DUEMILANOVE -DARDUINO_ARCH_AVR -IC:\Program Files\Arduino\hardware\arduino\avr\cores\arduino -IC:\Program Files\Arduino\hardware\arduino\avr\variants\standard C:\Program Files\Arduino\hardware\arduino\avr\cores\arduino\HardwareSerial1.cpp -o C:\DOCUME~1\George\LOCALS~1\Temp\build7021919583125132986.tmp\HardwareSerial1.cpp.o

    C:\Program Files\Arduino/hardware/tools/avr/bin/avr-g++ -c -g -Os -w -fno-exceptions -ffunction-sections -fdata-sections -fno-threadsafe-statics -MMD -mmcu=atmega328p -DF_CPU=16000000L -DARDUINO=158 -DARDUINO_AVR_DUEMILANOVE -DARDUINO_ARCH_AVR -IC:\Program Files\Arduino\hardware\arduino\avr\cores\arduino -IC:\Program Files\Arduino\hardware\arduino\avr\variants\standard C:\Program Files\Arduino\hardware\arduino\avr\cores\arduino\HardwareSerial2.cpp -o C:\DOCUME~1\George\LOCALS~1\Temp\build7021919583125132986.tmp\HardwareSerial2.cpp.o

    C:\Program Files\Arduino/hardware/tools/avr/bin/avr-g++ -c -g -Os -w -fno-exceptions -ffunction-sections -fdata-sections -fno-threadsafe-statics -MMD -mmcu=atmega328p -DF_CPU=16000000L -DARDUINO=158 -DARDUINO_AVR_DUEMILANOVE -DARDUINO_ARCH_AVR -IC:\Program Files\Arduino\hardware\arduino\avr\cores\arduino -IC:\Program Files\Arduino\hardware\arduino\avr\variants\standard C:\Program Files\Arduino\hardware\arduino\avr\cores\arduino\HardwareSerial3.cpp -o C:\DOCUME~1\George\LOCALS~1\Temp\build7021919583125132986.tmp\HardwareSerial3.cpp.o

    C:\Program Files\Arduino/hardware/tools/avr/bin/avr-g++ -c -g -Os -w -fno-exceptions -ffunction-sections -fdata-sections -fno-threadsafe-statics -MMD -mmcu=atmega328p -DF_CPU=16000000L -DARDUINO=158 -DARDUINO_AVR_DUEMILANOVE -DARDUINO_ARCH_AVR -IC:\Program Files\Arduino\hardware\arduino\avr\cores\arduino -IC:\Program Files\Arduino\hardware\arduino\avr\variants\standard C:\Program Files\Arduino\hardware\arduino\avr\cores\arduino\HID.cpp -o C:\DOCUME~1\George\LOCALS~1\Temp\build7021919583125132986.tmp\HID.cpp.o

    C:\Program Files\Arduino/hardware/tools/avr/bin/avr-g++ -c -g -Os -w -fno-exceptions -ffunction-sections -fdata-sections -fno-threadsafe-statics -MMD -mmcu=atmega328p -DF_CPU=16000000L -DARDUINO=158 -DARDUINO_AVR_DUEMILANOVE -DARDUINO_ARCH_AVR -IC:\Program Files\Arduino\hardware\arduino\avr\cores\arduino -IC:\Program Files\Arduino\hardware\arduino\avr\variants\standard C:\Program Files\Arduino\hardware\arduino\avr\cores\arduino\IPAddress.cpp -o C:\DOCUME~1\George\LOCALS~1\Temp\build7021919583125132986.tmp\IPAddress.cpp.o

    C:\Program Files\Arduino/hardware/tools/avr/bin/avr-g++ -c -g -Os -w -fno-exceptions -ffunction-sections -fdata-sections -fno-threadsafe-statics -MMD -mmcu=atmega328p -DF_CPU=16000000L -DARDUINO=158 -DARDUINO_AVR_DUEMILANOVE -DARDUINO_ARCH_AVR -IC:\Program Files\Arduino\hardware\arduino\avr\cores\arduino -IC:\Program Files\Arduino\hardware\arduino\avr\variants\standard C:\Program Files\Arduino\hardware\arduino\avr\cores\arduino\main.cpp -o C:\DOCUME~1\George\LOCALS~1\Temp\build7021919583125132986.tmp\main.cpp.o

    C:\Program Files\Arduino/hardware/tools/avr/bin/avr-g++ -c -g -Os -w -fno-exceptions -ffunction-sections -fdata-sections -fno-threadsafe-statics -MMD -mmcu=atmega328p -DF_CPU=16000000L -DARDUINO=158 -DARDUINO_AVR_DUEMILANOVE -DARDUINO_ARCH_AVR -IC:\Program Files\Arduino\hardware\arduino\avr\cores\arduino -IC:\Program Files\Arduino\hardware\arduino\avr\variants\standard C:\Program Files\Arduino\hardware\arduino\avr\cores\arduino\new.cpp -o C:\DOCUME~1\George\LOCALS~1\Temp\build7021919583125132986.tmp\new.cpp.o

    C:\Program Files\Arduino/hardware/tools/avr/bin/avr-g++ -c -g -Os -w -fno-exceptions -ffunction-sections -fdata-sections -fno-threadsafe-statics -MMD -mmcu=atmega328p -DF_CPU=16000000L -DARDUINO=158 -DARDUINO_AVR_DUEMILANOVE -DARDUINO_ARCH_AVR -IC:\Program Files\Arduino\hardware\arduino\avr\cores\arduino -IC:\Program Files\Arduino\hardware\arduino\avr\variants\standard C:\Program Files\Arduino\hardware\arduino\avr\cores\arduino\Print.cpp -o C:\DOCUME~1\George\LOCALS~1\Temp\build7021919583125132986.tmp\Print.cpp.o

    C:\Program Files\Arduino/hardware/tools/avr/bin/avr-g++ -c -g -Os -w -fno-exceptions -ffunction-sections -fdata-sections -fno-threadsafe-statics -MMD -mmcu=atmega328p -DF_CPU=16000000L -DARDUINO=158 -DARDUINO_AVR_DUEMILANOVE -DARDUINO_ARCH_AVR -IC:\Program Files\Arduino\hardware\arduino\avr\cores\arduino -IC:\Program Files\Arduino\hardware\arduino\avr\variants\standard C:\Program Files\Arduino\hardware\arduino\avr\cores\arduino\Stream.cpp -o C:\DOCUME~1\George\LOCALS~1\Temp\build7021919583125132986.tmp\Stream.cpp.o

    C:\Program Files\Arduino/hardware/tools/avr/bin/avr-g++ -c -g -Os -w -fno-exceptions -ffunction-sections -fdata-sections -fno-threadsafe-statics -MMD -mmcu=atmega328p -DF_CPU=16000000L -DARDUINO=158 -DARDUINO_AVR_DUEMILANOVE -DARDUINO_ARCH_AVR -IC:\Program Files\Arduino\hardware\arduino\avr\cores\arduino -IC:\Program Files\Arduino\hardware\arduino\avr\variants\standard C:\Program Files\Arduino\hardware\arduino\avr\cores\arduino\Tone.cpp -o C:\DOCUME~1\George\LOCALS~1\Temp\build7021919583125132986.tmp\Tone.cpp.o

    C:\Program Files\Arduino/hardware/tools/avr/bin/avr-g++ -c -g -Os -w -fno-exceptions -ffunction-sections -fdata-sections -fno-threadsafe-statics -MMD -mmcu=atmega328p -DF_CPU=16000000L -DARDUINO=158 -DARDUINO_AVR_DUEMILANOVE -DARDUINO_ARCH_AVR -IC:\Program Files\Arduino\hardware\arduino\avr\cores\arduino -IC:\Program Files\Arduino\hardware\arduino\avr\variants\standard C:\Program Files\Arduino\hardware\arduino\avr\cores\arduino\USBCore.cpp -o C:\DOCUME~1\George\LOCALS~1\Temp\build7021919583125132986.tmp\USBCore.cpp.o

    C:\Program Files\Arduino/hardware/tools/avr/bin/avr-g++ -c -g -Os -w -fno-exceptions -ffunction-sections -fdata-sections -fno-threadsafe-statics -MMD -mmcu=atmega328p -DF_CPU=16000000L -DARDUINO=158 -DARDUINO_AVR_DUEMILANOVE -DARDUINO_ARCH_AVR -IC:\Program Files\Arduino\hardware\arduino\avr\cores\arduino -IC:\Program Files\Arduino\hardware\arduino\avr\variants\standard C:\Program Files\Arduino\hardware\arduino\avr\cores\arduino\WMath.cpp -o C:\DOCUME~1\George\LOCALS~1\Temp\build7021919583125132986.tmp\WMath.cpp.o

    C:\Program Files\Arduino/hardware/tools/avr/bin/avr-g++ -c -g -Os -w -fno-exceptions -ffunction-sections -fdata-sections -fno-threadsafe-statics -MMD -mmcu=atmega328p -DF_CPU=16000000L -DARDUINO=158 -DARDUINO_AVR_DUEMILANOVE -DARDUINO_ARCH_AVR -IC:\Program Files\Arduino\hardware\arduino\avr\cores\arduino -IC:\Program Files\Arduino\hardware\arduino\avr\variants\standard C:\Program Files\Arduino\hardware\arduino\avr\cores\arduino\WString.cpp -o C:\DOCUME~1\George\LOCALS~1\Temp\build7021919583125132986.tmp\WString.cpp.o

    C:\Program Files\Arduino/hardware/tools/avr/bin/avr-ar rcs C:\DOCUME~1\George\LOCALS~1\Temp\build7021919583125132986.tmp/core.a C:\DOCUME~1\George\LOCALS~1\Temp\build7021919583125132986.tmp\hooks.c.o

    C:\Program Files\Arduino/hardware/tools/avr/bin/avr-ar rcs C:\DOCUME~1\George\LOCALS~1\Temp\build7021919583125132986.tmp/core.a C:\DOCUME~1\George\LOCALS~1\Temp\build7021919583125132986.tmp\WInterrupts.c.o

    C:\Program Files\Arduino/hardware/tools/avr/bin/avr-ar rcs C:\DOCUME~1\George\LOCALS~1\Temp\build7021919583125132986.tmp/core.a C:\DOCUME~1\George\LOCALS~1\Temp\build7021919583125132986.tmp\wiring.c.o

    C:\Program Files\Arduino/hardware/tools/avr/bin/avr-ar rcs C:\DOCUME~1\George\LOCALS~1\Temp\build7021919583125132986.tmp/core.a C:\DOCUME~1\George\LOCALS~1\Temp\build7021919583125132986.tmp\wiring_analog.c.o

    C:\Program Files\Arduino/hardware/tools/avr/bin/avr-ar rcs C:\DOCUME~1\George\LOCALS~1\Temp\build7021919583125132986.tmp/core.a C:\DOCUME~1\George\LOCALS~1\Temp\build7021919583125132986.tmp\wiring_digital.c.o

    C:\Program Files\Arduino/hardware/tools/avr/bin/avr-ar rcs C:\DOCUME~1\George\LOCALS~1\Temp\build7021919583125132986.tmp/core.a C:\DOCUME~1\George\LOCALS~1\Temp\build7021919583125132986.tmp\wiring_pulse.c.o

    C:\Program Files\Arduino/hardware/tools/avr/bin/avr-ar rcs C:\DOCUME~1\George\LOCALS~1\Temp\build7021919583125132986.tmp/core.a C:\DOCUME~1\George\LOCALS~1\Temp\build7021919583125132986.tmp\wiring_shift.c.o

    C:\Program Files\Arduino/hardware/tools/avr/bin/avr-ar rcs C:\DOCUME~1\George\LOCALS~1\Temp\build7021919583125132986.tmp/core.a C:\DOCUME~1\George\LOCALS~1\Temp\build7021919583125132986.tmp\abi.cpp.o

    C:\Program Files\Arduino/hardware/tools/avr/bin/avr-ar rcs C:\DOCUME~1\George\LOCALS~1\Temp\build7021919583125132986.tmp/core.a C:\DOCUME~1\George\LOCALS~1\Temp\build7021919583125132986.tmp\CDC.cpp.o

    C:\Program Files\Arduino/hardware/tools/avr/bin/avr-ar rcs C:\DOCUME~1\George\LOCALS~1\Temp\build7021919583125132986.tmp/core.a C:\DOCUME~1\George\LOCALS~1\Temp\build7021919583125132986.tmp\HardwareSerial.cpp.o

    C:\Program Files\Arduino/hardware/tools/avr/bin/avr-ar rcs C:\DOCUME~1\George\LOCALS~1\Temp\build7021919583125132986.tmp/core.a C:\DOCUME~1\George\LOCALS~1\Temp\build7021919583125132986.tmp\HardwareSerial0.cpp.o

    C:\Program Files\Arduino/hardware/tools/avr/bin/avr-ar rcs C:\DOCUME~1\George\LOCALS~1\Temp\build7021919583125132986.tmp/core.a C:\DOCUME~1\George\LOCALS~1\Temp\build7021919583125132986.tmp\HardwareSerial1.cpp.o

    C:\Program Files\Arduino/hardware/tools/avr/bin/avr-ar rcs C:\DOCUME~1\George\LOCALS~1\Temp\build7021919583125132986.tmp/core.a C:\DOCUME~1\George\LOCALS~1\Temp\build7021919583125132986.tmp\HardwareSerial2.cpp.o

    C:\Program Files\Arduino/hardware/tools/avr/bin/avr-ar rcs C:\DOCUME~1\George\LOCALS~1\Temp\build7021919583125132986.tmp/core.a C:\DOCUME~1\George\LOCALS~1\Temp\build7021919583125132986.tmp\HardwareSerial3.cpp.o

    C:\Program Files\Arduino/hardware/tools/avr/bin/avr-ar rcs C:\DOCUME~1\George\LOCALS~1\Temp\build7021919583125132986.tmp/core.a C:\DOCUME~1\George\LOCALS~1\Temp\build7021919583125132986.tmp\HID.cpp.o

    C:\Program Files\Arduino/hardware/tools/avr/bin/avr-ar rcs C:\DOCUME~1\George\LOCALS~1\Temp\build7021919583125132986.tmp/core.a C:\DOCUME~1\George\LOCALS~1\Temp\build7021919583125132986.tmp\IPAddress.cpp.o

    C:\Program Files\Arduino/hardware/tools/avr/bin/avr-ar rcs C:\DOCUME~1\George\LOCALS~1\Temp\build7021919583125132986.tmp/core.a C:\DOCUME~1\George\LOCALS~1\Temp\build7021919583125132986.tmp\main.cpp.o

    C:\Program Files\Arduino/hardware/tools/avr/bin/avr-ar rcs C:\DOCUME~1\George\LOCALS~1\Temp\build7021919583125132986.tmp/core.a C:\DOCUME~1\George\LOCALS~1\Temp\build7021919583125132986.tmp\new.cpp.o

    C:\Program Files\Arduino/hardware/tools/avr/bin/avr-ar rcs C:\DOCUME~1\George\LOCALS~1\Temp\build7021919583125132986.tmp/core.a C:\DOCUME~1\George\LOCALS~1\Temp\build7021919583125132986.tmp\Print.cpp.o

    C:\Program Files\Arduino/hardware/tools/avr/bin/avr-ar rcs C:\DOCUME~1\George\LOCALS~1\Temp\build7021919583125132986.tmp/core.a C:\DOCUME~1\George\LOCALS~1\Temp\build7021919583125132986.tmp\Stream.cpp.o

    C:\Program Files\Arduino/hardware/tools/avr/bin/avr-ar rcs C:\DOCUME~1\George\LOCALS~1\Temp\build7021919583125132986.tmp/core.a C:\DOCUME~1\George\LOCALS~1\Temp\build7021919583125132986.tmp\Tone.cpp.o

    C:\Program Files\Arduino/hardware/tools/avr/bin/avr-ar rcs C:\DOCUME~1\George\LOCALS~1\Temp\build7021919583125132986.tmp/core.a C:\DOCUME~1\George\LOCALS~1\Temp\build7021919583125132986.tmp\USBCore.cpp.o

    C:\Program Files\Arduino/hardware/tools/avr/bin/avr-ar rcs C:\DOCUME~1\George\LOCALS~1\Temp\build7021919583125132986.tmp/core.a C:\DOCUME~1\George\LOCALS~1\Temp\build7021919583125132986.tmp\WMath.cpp.o

    C:\Program Files\Arduino/hardware/tools/avr/bin/avr-ar rcs C:\DOCUME~1\George\LOCALS~1\Temp\build7021919583125132986.tmp/core.a C:\DOCUME~1\George\LOCALS~1\Temp\build7021919583125132986.tmp\WString.cpp.o

    C:\Program Files\Arduino/hardware/tools/avr/bin/avr-gcc -w -Os -Wl,--gc-sections -mmcu=atmega328p -o C:\DOCUME~1\George\LOCALS~1\Temp\build7021919583125132986.tmp/sketch_jan31a.cpp.elf C:\DOCUME~1\George\LOCALS~1\Temp\build7021919583125132986.tmp\sketch_jan31a.cpp.o C:\DOCUME~1\George\LOCALS~1\Temp\build7021919583125132986.tmp/core.a -LC:\DOCUME~1\George\LOCALS~1\Temp\build7021919583125132986.tmp -lm

    C:\Program Files\Arduino/hardware/tools/avr/bin/avr-objcopy -O ihex -j .eeprom --set-section-flags=.eeprom=alloc,load --no-change-warnings --change-section-lma .eeprom=0 C:\DOCUME~1\George\LOCALS~1\Temp\build7021919583125132986.tmp/sketch_jan31a.cpp.elf C:\DOCUME~1\George\LOCALS~1\Temp\build7021919583125132986.tmp/sketch_jan31a.cpp.eep

    C:\Program Files\Arduino/hardware/tools/avr/bin/avr-objcopy -O ihex -R .eeprom C:\DOCUME~1\George\LOCALS~1\Temp\build7021919583125132986.tmp/sketch_jan31a.cpp.elf C:\DOCUME~1\George\LOCALS~1\Temp\build7021919583125132986.tmp/sketch_jan31a.cpp.hex

    Sketch uses 450 bytes (1%) of program storage space. Maximum is 30,720 bytes.

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

    C:\Program Files\Arduino/hardware/tools/avr/bin/avrdude -CC:\Program Files\Arduino/hardware/tools/avr/etc/avrdude.conf -v -v -v -v -patmega328p -carduino -PCOM8 -b57600 -D -Uflash:w:C:\DOCUME~1\George\LOCALS~1\Temp\build7021919583125132986.tmp/sketch_jan31a.cpp.hex:i

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

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

             Using Port                    : COM8
             Using Programmer              : arduino
             Overriding Baud Rate          : 57600
    avrdude: Send: 0 [30]   [20]
    avrdude: Send: 0 [30]   [20]
    avrdude: Send: 0 [30]   [20]
    avrdude: ser_recv(): programmer is not responding
    avrdude: stk500_recv(): programmer is not responding
    avrdude: stk500_getsync() attempt 1 of 10: not in sync: resp=0x01
    avrdude: Send: 0 [30]   [20]
    avrdude: ser_recv(): programmer is not responding
    avrdude: stk500_recv(): programmer is not responding
    avrdude: stk500_getsync() attempt 2 of 10: not in sync: resp=0x01
    avrdude: Send: 0 [30]   [20]
    avrdude: ser_recv(): programmer is not responding
    avrdude: stk500_recv(): programmer is not responding
    avrdude: stk500_getsync() attempt 3 of 10: not in sync: resp=0x01
    avrdude: Send: 0 [30]   [20]
    avrdude: ser_recv(): programmer is not responding
    avrdude: stk500_recv(): programmer is not responding
    avrdude: stk500_getsync() attempt 4 of 10: not in sync: resp=0x01
    avrdude: Send: 0 [30]   [20]
    avrdude: ser_recv(): programmer is not responding
    avrdude: stk500_recv(): programmer is not responding
    avrdude: stk500_getsync() attempt 5 of 10: not in sync: resp=0x01
    avrdude: Send: 0 [30]   [20]
    avrdude: ser_recv(): programmer is not responding
    avrdude: stk500_recv(): programmer is not responding
    avrdude: stk500_getsync() attempt 6 of 10: not in sync: resp=0x01
    avrdude: Send: 0 [30]   [20]
    avrdude: ser_recv(): programmer is not responding
    avrdude: stk500_recv(): programmer is not responding
    avrdude: stk500_getsync() attempt 7 of 10: not in sync: resp=0x01
    avrdude: Send: 0 [30]   [20]
    avrdude: ser_recv(): programmer is not responding
    avrdude: stk500_recv(): programmer is not responding
    avrdude: stk500_getsync() attempt 8 of 10: not in sync: resp=0x01
    avrdude: Send: 0 [30]   [20]
    avrdude: ser_recv(): programmer is not responding
    avrdude: stk500_recv(): programmer is not responding
    avrdude: stk500_getsync() attempt 9 of 10: not in sync: resp=0x01
    avrdude: Send: 0 [30]   [20]
    avrdude: ser_recv(): programmer is not responding
    avrdude: stk500_recv(): programmer is not responding
    avrdude: stk500_getsync() attempt 10 of 10: not in sync: resp=0x01

    avrdude done.  Thank you.

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

The light on the USB-To-Serial board lights once for each failed upload, but the sketch won't upload. I am trying to upload the blink sketch. The chip I am using is an Atmel AtMega328P-PU. All answers greatly appreciated.

title: Home-made Arduino not receiving data

Answers: 3

body: I solved this by using an empty Uno-Board as a 'bridge' between the PC and the Bareduino (empty means with no controller chip). Just connect this guy via USB to the PC and then connect RX/TX, Ground, and Reset to your Bareduino. Just works fine for me.

body: I would upload a blink sketch using the method Stephan suggested then plug it back into your breadboard.  If it runs the blink sketch then the problem is in your programming method, but  it is more likely there is something wrong in the setup.  Problems could be using the wrong crystal for your setup, mis-wired or loose connection, or having your chip turned around (happens more often than you think).  If it does run I would make sure that you are using all USB-to-Serial converter with all the wires used and having a resister on the reset pin.

body:
The likely causes of failure are

 - Wrong baud rate: you're already using 57600, the most common one.
 - Rx and Tx cross connected: try connecting them the other way round.
 - Wrong clock clock frequency in the chip: The tools usually assume an AtMega328 runs at 16MHz.
 - Chip is not in bootloader/programming state, in the very first seconds after releasing the reset button or powering the arduino, the bootloader is listening for instructions to start reprogramming the chip via serial communication, if there is none it will continue running the program on it. Hold reset -> Hold upload -> Release upload -> Release reset.

The above assumes, of course, that you have a working board. If that isn't certain, follow @Nathan's advice to plug in a chip pre-programmed with a Blinky sketch to confirm it. I use a combined Blinky and HelloWorld sketch to prove both the basic functioning and the serial I/O in one test.

A couple of these are handy to keep around, too, for proving there is power or a logic HIGH where you expect it:

![LED with resistor][1]

           LED with current-limiting resistor on the cathode

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


body:
I'm developing a low power project based on Atmega328p which among other things uses a DHT22 to measure air humidity. DHT22 spec says that it consumes 50uA when idle. This is too high for me (I'm aiming at sub 10uA consumption for the whole device when in sleep mode) so I've figured out that I'll just power it from one of Atmega328p pins. This will give me the ability to turn it off or on at software level. DHT22 consumes only 1.5mA during measurement so I should be fine (a single Atmega's pin can safely provide up to 20mA). I've set up a following test circuit:

![schematic](https://i.stack.imgur.com/3AcJY.png)

The red wire powers DHT22, the blue one is for data transfer, the black one is GND and the 4.7k is a pull-up resistor.

My problem is that after I turn on the DHT22 using just:

    digitalWrite(4, HIGH);

the Atmega either resets or hangs or... successfully turns on the DHT22 and keeps working, but that happens about 10% of the time. My suspicion is that there is some current spike in the moment of supplying power to the DHT22. Unfortunately I don't have an oscilloscope to confirm this.

I've added a 220 ohm resistor between VCC pin of DHT22 and the pin 4 on the Arduino and it solved the problem. My question is: will it work like this reliably? Are humidity readings reliable when voltage is not stabilized (but stays within 3.3-5.5V range as required by the datasheet)? I could of course use a transistor to turn it on/off, but I'd like to keep it as simple as possible.

Why DHT22's datasheet doesn't mention this current spike? Here it is for reference: http://www.adafruit.com/datasheets/Digital humidity and temperature sensor AM2302.pdf

title: arduino resets or hangs after providing power to DHT22

Answers: 3

body:
The sensor is a large capacitive load. You need to improve decoupling of the CPU power supply.

A 10 uF between 5V and GND will help for the current spike and the resistor in series with the sensor will not be an issue (50 uA on 250 Ohm makes only 12.5 mV voltage drop once the sensor is started).

body:
The previous answers regarding adding decoupling capacitors are good.
You don't have to be concerned about the voltage drop across your 220 ohm resistor. MAC's answer states that only 12.5mv drop at 50uA (when not measuring).
**During measurement**, 1.5mA will result in 0.33v drop across the 220 ohm resistor. This should be noted, but is not a problem. The DHT22 data sheet shows that it will accept any supply voltage between 3.3v and 6v.
  Looks like you have a good design.

body:
Decoupling capacitors do help, as mentioned in the other answers.

Also, to get a good reading, after powering up your digital pin 4, a delay of maybe 100-500ms may be required to allow the DHT22 to stabilize. For better results, you can also perform multiple readings (call delay(dht.getMinimumSamplingPeriod()) between the readings) and average them.

It looks like you are using an Arduino Uno. For further power savings, you might consider using a Pro Mini and performing [some hardware modifications][1]. For software power saving techniques, there is no better resource than Nick Gammon's [Power saving techniques for microprocessors][2].

  [1]: http://www.home-automation-community.com/arduino-low-power-how-to-run-atmega328p-for-a-year-on-coin-cell-battery/
  [2]: http://www.gammon.com.au/forum/?id=11497


body:
Yes, you read that right.  An `Apple IIe`.

I have many retro computers and I was thinking that since the `Apple II` line of computers (especially the `IIe`) have pretty speedy serial ports that it should be somewhat simple to use an Arduino to send data to/from the Apple.

My issue is that all of my every-day computers are USB based with no RS232 serial.  I guess I could boot up an old Linux laptop that has a serial port but that seems too cumbersome given my limited desk space.  :-)

Anyway, I've Googled but I'm not finding anything.

Since most `Apple IIe` disk images are pretty small (<144k or so) they should fit pretty easily into, say, an Arduino DUE that I have.  Or better yet, using the DUE to mount as a USB device that could send over to the IIe would be great.

So, my question is, does anyone know of any site that explains how this could be done?

Thanks!

**EDIT**

OK, turns out it WAS pretty easy getting the Arduino DUE to send to the Apple IIe.  I simply connected 3 wires from TX1/TR1/GND to the Apple IIe serial port (SSC).

Now, when I launch ADT Pro and start sending, the IIe is receiving garbage.  Bunch of "9d9d9d9d" all over the place.

Here's my code:

    // ADT.ino

 int incomingByte = 0;

 void setup() {

  Serial.begin(9600);
  Serial1.begin(9600);

 }

 void loop() {

  if(Serial.available() > 0) {

   while(Serial.available() > 0) {

    incomingByte = Serial.read();

   }

   Serial1.write(incomingByte);
   delay(100);
  }

 }

The ADT Pro software is set to send the data over the USB port and it's obviously sending data to the IIe.  I'm just wondering if the formatting is wrong or something.

title: Has anyone used an Arduino to transfer software to an Apple IIe?

Answers: 1

body: You need to adapt the levels. Arduino Due operates on 0 - 3.3 V. Apple IIe is either on 0 - 5 V or +/- 12 V (depends which port you are using). There are standard ICs to do the level adaptation.


body:
I generally use sockets for AVRs in standalone circuits, but sometimes I sell my items and therefore I soldier the chip on the circuit. As you guess I can upgrade the code inside the chip with socket simply putting the chip out and putting it into the programmer board, but It doesn't work the same way with the ones which are soldiered on the circuit.

I know there are some ISP devices like USBtinyISP etc., but I want to be more professional and know exactly how an in system programmer work.

Do I have to use Avrdude If I design my own In system programmer? Isn't there any way that is more universal?

 I searched the internet for a long time and I found only hobbyist stuff. Can anyone explain or simply direct me to a good source that explains this topic? Thank you in advance.

title: In system programming for avr?

Answers: 2

body:
ISP works by using a serial connection (usually via the SPI and nRESET pins) to the MCU. The programmer talks to the device using the low-level protocol that the device expects, and connects to the host using a different, high-level protocol. The host then directs the programmer to perform the various programming actions on the device, and in turn the programmer reports to the host about its current status.

There are a number of programming protocols that already exist, such as the one described in AVR910. As long as both the connection type and the protocol itself are supported by AVRDUDE it will work transparently once the hardware is assembled.

Further details about ISP are available in both AVR910 as well as the "Serial Programming" section of the datasheet for the device in question.

body:
You can use an ISP using the Arduino UI - simply select your programmer (tools->programmer) then "upload using programmer" (under the file menu).

Alternatively, you could use a pre-programmed AVR to do the programming - see http://www.atmel.com/images/doc0943.pdf for the spec. I think an AtTiny would be enough, depending on how big your program is, you might need some external storage. You could set it up with a "read" and a "write" option, so you program your dev AVR normally, then use an AtTiny to suck the data off, then push it up to one of the others. This is left as an exercise to the reader.

In any case, you would just need access to the 6 pins - VCC(power), GND(ground), RST(reset), SCK(clock), MISO(master->slave) and MOSI (slave->master). Note that the RST pin has to go high/low at specific times during the programming, so if programming from another AVR, it will need to be a data pin.


body:
I want to design an Arduino shield with stackable headers, so it will allow other shields to be mounted on top of it.

![enter image description here][1]

I was wondering if these could be soldered automatically. Neither wave nor reflow soldering seems to be an option. Wave soldering would leave solder on the pins so they won't fit in sockets, and for reflow (pin-in-paste) the long pins will completely pull the paste from the holes.
Is hand-soldering the only way (making the board more expensive), or is there still another way? Would it be a good idea to supply the shield with the headers not mounted to save cost?
Or shouldn't I assume the average Arduino user has a soldering iron?

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

title: Can stackable Arduino headers be automatically soldered?

Answers: 2

body:
I would suggest using SMD headers on one side and through hole on the other side. One side with this: http://www.tracepartsonline.net/(S(30y0dp21y1rd0u3erv1mrrbw))/partdetails.aspx?Class=ASSMANN&ClsID=/F_ASSMANN/ASSMANN.010/ASSMANN.010.170/&PartID=10-18062010-079808
and one side with this: http://www.tracepartsonline.net/(S(30y0dp21y1rd0u3erv1mrrbw))/PartDetails.aspx?Class=ASSMANN&clsid=/F_ASSMANN/ASSMANN.010/ASSMANN.010.170/&ManID=ASSMANN&PartFamilyID=10-23062010-067691&PartID=10-23062010-067691&SrchRsltId=1&SrchRsltType=0

You will shift upper side a few mm from bottom side, and use glue to have upper side set in place and then reflow for soldering on both sides.

body: You might look at getting a solder stencil.  It is still hand soldering, but significantly faster than doing it completely by hand.  Another option would be a pick and place machine; there would be a significant upfront cost but it would be more automatic.


body:
According to my current (poor) understanding, only the PWM pins (with the ~) among the digital pins (ignoring Analog pins) can be passed to `analogWrite()`.  I understand the servo therefore - since interfaced by a variable voltage signal - must be connected to such a PWM pin.

 - Why is the humble Piezo Buzzer not bound to this condition?
 - Why can I connect the buzzer to a digital pin that is not PWM (and so should only be able to output binary LOW, HIGH voltage at some consistent frequency) and still achieve a varying sound by calls to the `tone()` function?
 - Surely under the limitations of being digital and non-PWM, the pin could only cause some consistent buzzer frequency?

I'm reading online that the Piezeo Buzzer does indeed require a PWM digital pin, but I can connect it to any digital pin on my Galileo gen2 and have it function seemingly correctly (differing tones produced).

Also, since slightly relevant; what exactly is the difference between a PWM digital pin and an analog pin, in terms of output? They both use PWM, right? Why can't even a PWM digital pin read analog input?

title: Why does a Piezo Buzzer not require a PWM digital pin (Gallileo Gen2)?

Answers: 2

body:
> Why does a Piezo Buzzer not require a PWM digital pin?

Tone() uses the microcontroller's hardware timers to control the related code function but do not use the hardware PWM features. The timer can be assigned to any pin that has a digital output capability.
Tone() sends a "rail to rail" square wave (50% duty cycle) to the selected pin

Slightly more lower level information here under [**Ugly details**](https://code.google.com/p/rogue-code/wiki/ToneLibraryDocumentation#Ugly_Details)
They say:

 - The library uses the hardware timers on the microcontroller to generate square-wave tones in the audible range.

 You can output the tones on any pin (arbitrary). The number of tones that can be played simultaneously depends on the number of hardware timers (with CTC capability) available on the microcontroller.

 ATmega8: 2 (timers 2, and 1)
 ATmega168/328: 3 (timers 2, 1, and 0)
 ATmega1280: 6 (timers 2, 3, 4, 5, 1, 0)

 The timer order given above is the order in which the timers are allocated. Timer 0 is a sensitive timer on the Arduino since it provides millis() and PWM functionality.

_____________

> ... what exactly is the difference between a PWM digital pin and an analog pin, in terms of output? They both use PWM, right? Why can't even a PWM digital pin read analog input?

There is a misconception there.
Analog pins are capable of Analog INPUT functionality .
"PWM" output is known as "analogWrite" but is actually a purely digital function and is not related to whether a pin has analog read functionality.
PWM out = analogWrite is available on pins which have associated PWM hardware.
The actual signal is a "rail to rail" square wave with a mark:space (on:off)that varies.   Filtering the PWM produces DC at the average DC level. PWM range is 0 to 255 (8 bits)

body:
The signals that you mention are of different nature.

1) The PWM signal is a digital signal (output voltage is either ground or supply) that is modulated in time. It has a fixed period and its duty cycle varies from 0% (always ground) for value 0, to 100% (always supply) for value 255, the middle value being a signal that switches between ground and supply with 50% of its period at ground and 50% of its period at supply.

2) A servo is controlled by a signal that has a fixed period of 20 ms and a pulse of varying duration (between 0.5 to 2.5 ms).

3) A tone for a buzzer has a variable period (or variable frequency - both being linked by the equation frequency * period = 1). The period is audible if is is between 0.06 ms (15 kHz) and 60 ms (15 Hz) (the exact value change from person to person. If the frequency is higher than 15 kHz, you are entering ultra-sonic.

All three signals are digital in their voltage and modulated in time. But the modulation is very different as indicated above and the Arduino driver is therefore different for each one.


body:
I'm in the process of buying a receiver and transmitter for my quad copter project. Would it be possible to use this receiver or a similar one to control the quad. I'm trying to read the signals using Pulse in. I'm inexperienced in RC and I only found one tutorial on how to do this.

I know that the receiver will have to be wired up to the analog pins on the arduino however, the receiver has an operating voltage of 3.5V-10V and an operating current of 100mA which exceeds the 40mA of the arduino board. I have seen videos of people using silar 2.4Ghz receivers on arduino Nanos without problems. Has anyone on this board done something similar and if so, can thou guide me?

title: Is it possible to use FrSky D8R-II Plus 8ch 2.4Ghz ACCST Receiver with an arduino Uno?

Answers: 1

body:
I've used plenty of receivers like this with arduino.

The operating current is not really an issue; It is drawing power off of the 5v line, not the digital pins, which is capable of 100mA. In any case they usually have an extra "bat" line that you could plug in to a BEC from one of your speed controllers, and then just connect signal and ground lines to the arduino.

pulseIn works, but not ideally (especially for quadcopters). reading with pulseIn tends to have quite a bit of noise, and runs slow. Those receivers pulse around 50-60Hz, so reading those signals with pulseIn (which has to wait for the signal to finish) will take too long. I say "too long" because in all the open source quad copter programs I've looked at the sensor-read/stabilize update loop needs to run at 100 Hz or more.

What you need to use is the interrupt functionality of the AVR. That way you can detect the time between changes in state of the input pulse without causing the rest of the program to stop. This can get somewhat complicated so I'm not going to write a tutorial here. I recommend you research it yourself and ask new, specific questions here if you have any.

It doesn't magically fix everything for you though; the Uno only has 2 external interrupts. I think most arduino based quads use arduino megas or Leonardos, which have more. I know the APM 2 board has a separate chip converting those 8 single channel PPM signals into a single 8 channel PPM signal that goes into the main controller, despite the fact that it is a mega.

You can look into Aeroquad and Multiwii for inspiration. ArduPilot is open source as well but their code is messier, which makes reading it much more difficult. I don't think it is impossible to use an Uno, but it will be difficult.


body:
I'm working on a project with 4 inputs and 7 possible outputs on an Arduino Uno.  Based on any combination of those inputs, I need to run a specific "loop" that will repeat until there is a change in ANY of the 4 inputs.  Specifically:

 - Input 1 = loop 1
 - Input 2 = loop 2
 - Input 3 = loop 3
 - Input 4 = loop 4
 - Input 2 and 3 = loop 5
 - Input 2 and 4 = loop 6
 - No input = do nothing

So I need to constantly read the 4 inputs and change output loops accordingly.  I have basic Arduino knowledge but am stumped.

This is what I've tried - I have 4 input pins and 8 output pins

    int outPin = 0;
    int inPin = 0;
    int CAR = 0;
    int pinRead = 0;

    void setup()
    {
     for (int outPin = 3; outPin < 11; outPin++);  {  //set pins 3 thru 10 as OUTPUT
       pinMode(outPin, OUTPUT);
      }

     for (int inPin = 9; inPin < 13; inPin++);  {    //set pins 9 thru 12 as INPUT
       pinMode(inPin, INPUT);
      }

    }

    void loop()
    {
      for (int CAR = 3; CAR <11; CAR++); {  //set all pins to LOW
       digitalWrite(CAR, LOW);
      }

      // BRAKE

        {while (digitalRead(9 == HIGH) && digitalRead(10 == LOW) && digitalRead (11 == LOW) && digitalRead(12 == LOW)) {
        digitalWrite(3, HIGH);
        digitalWrite(4, HIGH);
        digitalWrite(5, HIGH);
        digitalWrite(6, HIGH);
        digitalWrite(7, HIGH);
        digitalWrite(8, HIGH);
        digitalWrite(9, HIGH);
        digitalWrite(10, HIGH);

      }}

      // LEFT

        {while (digitalRead(9 == LOW) && digitalRead(10 == HIGH) && digitalRead(11 == LOW) && digitalRead(12 == LOW)) {
        digitalWrite(0, HIGH);
        delay (200);
        digitalWrite(1, HIGH);
        digitalWrite(3, HIGH);
        delay (200);
        digitalWrite(2, HIGH);
        delay (200);
        digitalWrite(0, LOW);
        digitalWrite(1, LOW);
        digitalWrite(2, LOW);
        digitalWrite(3, LOW);
        delay (200);

      // RIGHT

      }}

        {while (digitalRead(9 == LOW) && digitalRead(10 == LOW) && digitalRead(11 == HIGH) && digitalRead(12 == LOW)) {
        digitalWrite(5, HIGH);
        delay (200);
        digitalWrite(4, HIGH);
        digitalWrite(6, HIGH);
        delay (200);
        digitalWrite(7, HIGH);
        delay (200);
        digitalWrite(4, LOW);
        digitalWrite(5, LOW);
        digitalWrite(6, LOW);
        digitalWrite(7, LOW);
        delay (200);

      // HAZARD

      }}

        {while (digitalRead(9 == LOW) && digitalRead(10 == LOW) && digitalRead(11 == LOW) && digitalRead(12 == HIGH)) {
        digitalWrite(0, HIGH);
        digitalWrite(5, HIGH);
        delay (200);
        digitalWrite(1, HIGH);
        digitalWrite(4, HIGH);
        digitalWrite(5, HIGH);
        digitalWrite(6, HIGH);
        delay (200);
        digitalWrite(2, HIGH);
        digitalWrite(7, HIGH);
        delay (200);

          for (int CAR = 0; CAR < 8; CAR++); {  //set all pins to LOW
           digitalWrite(CAR, LOW);
        delay (200);}}

      // BRAKELEFT

      }

        {while ( digitalRead(9 == HIGH) && digitalRead(10 == HIGH) && digitalRead(11 == LOW) && digitalRead(12 == LOW)) {
        digitalWrite(0, HIGH);
        digitalWrite(5, HIGH);
        digitalWrite(6, HIGH);
        digitalWrite(7, HIGH);
        delay (200);
        digitalWrite(1, HIGH);
        digitalWrite(3, HIGH);
        delay (200);
        digitalWrite(2, HIGH);
        delay (200);
        digitalWrite(0, LOW);
        digitalWrite(1, LOW);
        digitalWrite(2, LOW);
        digitalWrite(3, LOW);
        delay (200);
        }
      }

      // BRAKERIGHT

        {while (digitalRead(9 == HIGH) && digitalRead(10 == LOW) && digitalRead(11 == HIGH) && digitalRead(12 == LOW)) {
        digitalWrite(0, HIGH);
        digitalWrite(1, HIGH);
        digitalWrite(2, HIGH);
        digitalWrite(5, HIGH);
        delay (200);
        digitalWrite(4, HIGH);
        digitalWrite(6, HIGH);
        delay (200);
        digitalWrite(7, HIGH);
        delay (200);
        digitalWrite(4, LOW);
        digitalWrite(5, LOW);
        digitalWrite(6, LOW);
        digitalWrite(7, LOW);
        delay (200);
        }
      }

      // NOTHING

        {while (digitalRead(9 == LOW) && digitalRead(10 == LOW) && digitalRead(11 == LOW) && digitalRead(12 == LOW)) {

           for (int CAR = 0; CAR < 8; CAR++); {  //set all pins to LOW
             digitalWrite(CAR, LOW); }}
        }
    }

title: Imbedded loops based on inputs

Answers: 1

body:
When you need repeating behaviour in an Arduino program, putting loops within the `loop()` function often isn't the best approach. It leads to a lot of confusing logic which is quite hard to get right, and becomes quite unwieldy to maintain.

A more effective approach would be something like a simple state machine. At the start of `loop()` you would check the input values and figure out which behaviour (or state) you want to execute: BRAKE, LEFT, RIGHT etc.. You might want to store this information in a variable somewhere, e.g. state `0` could be BRAKE, state `1` could be LEFT, and so on.

Next, you simply check what the state value is, and execute the appropriate instructions **once**. For example:

    switch (state)
    {
        case 0:
            // BRAKE instructions here...
            break;

        case 1:
            // LEFT instructions here...
            break;

        // etc...
    }

There's no need for any `while` loops because `loop()` is going to get called all the time anyway. There are two big advantages of this approach. First, you only need all the input conditions in one place, which makes the code easier to manage. And second, it means you can easily have your program doing other things later in `loop()` because it's no longer stuck in nested loops all the time.

----
As a side note, it's very important to mention that lines like this are incorrect:

    digitalRead(9 == HIGH)

What you're doing here is comparing the number `9` to `HIGH`, and then passing the result (which is 0) to the `digitalRead()` function. That means you're effectively only ever checking pin 0. What you actually want to do is pass `9` to the function, and then compare the overall result to `HIGH`, like this:

    digitalRead(9) == HIGH