message:
RSSI stop sketch on a gboard (atmega)

I have this function in my code and works fine (it returns a valid value, I put this value into a int variable outside function), but when end the function (or continue the code), my sketch stop/die...

    ///FUNCION PARA RSSI XBEE///
    byte rss() {  ///PARA RSSI
    union {byte B; char C;} atCmd[3];
    AtCommandRequest atCmdReq;
    AtCommandResponse atResp;
    byte respLen, *resp, dBm;
    strcpy(&atCmd[0].C, "DB");
    atCmdReq = AtCommandRequest(&atCmd[0].B);
    atResp = AtCommandResponse();
    xbee.send(atCmdReq);
    if (xbee.readPacket(5000)) {
       if (xbee.getResponse().getApiId() == AT_COMMAND_RESPONSE) {
           xbee.getResponse().getAtCommandResponse(atResp);
           if (atResp.isOk()) {
               respLen = atResp.getValueLength();
               if (respLen == 1) {
                   resp = atResp.getValue();
                   dBm = resp[0];
                      return dBm;
               }
               else {
                 //  Serial.println("Unexpected response");
               }
           }
           else {
             //  Serial.println("ERROR");
           }
       }
       else {
         //  Serial.println("Unknown response");
       }
    }
    else {
     //  Serial.println("No response");
    }
    }///fin rss()

¿Any tips?

body:
Your function is only returning a value when everything works OK. If an error occurs, the problem is reported to serial but it doesn't return anything. It seems likely that this could cause stack corruption which could make the program stop.

A simple solution would be to put `return 0;` (or some other number) just before the end of the function.


sender: user

message:
How to add Ultrasonic Sensor to the board?

I am making an RC car , have combined the **Arduino UNO R3** with the **AR 293d**, and pluged in the HC-SR04 sensor to the SRO4 hole at the left top corner in the below graph. However, besides one sensor  I **would like to add three more HC-SR04 sensor**.

Reference:
http://www.instructables.com/id/Simple-Arduino-and-HC-SR04-Example/

![enter image description here][1]

The problems are

1) is the board sufficient to plug three more sensor ?

2) or what extra board I need if not sufficient and how to combine those board

2) also, can I plug in other hole?

Thanks for helping

**Update: breadboard connection**

So I have to get a stuff like this?

http://www.tandyonline.co.uk/small-solderless-breadboard.html

and one more question, sorry for begin newbie, there are many holes on breadboard, which hole I should connect those three sensor on it, and the hold I should connect the breadboard with the AR-293D board?

And for programming, is there any way to get the pin at the breadboard as I have read some program before, the pin is assign with a number?

Thanks again for helping.

![enter image description here][2]

  [1]: https://i.stack.imgur.com/6TtmL.png
  [2]: https://i.stack.imgur.com/hni7b.png

sender: assistant

body:
1) Not really. You have so little space and you have to selder them. Try using wires

2) If you want it to be flexible use a sandard solderless breadoard on the center of the car and then with male-female jumperwires try connecting them.

3) The board has traces. That means some holes have a very specific purpose.

##Updated:

On every breadboard the holes are connected verticaly. For example, in the image from your breadboard you posted 1A, 1B, 1C, 1D and 1E are connected together.
If you would like to have all of the 3 sensors better use wires and then atach them on to your breadboard.

Here is a picture:
https://www.dropbox.com/s/3ij4w6eytio8p08/Screen 16-25-31.png?dl=0


message:
Serial Print, String And Variable On Same Line

How can I print to the serial monitor a string or just single character followed by a variable like "L 55"

body:
    int Var = 55;
    //Do it in 2 lines e.g.
    Serial.print("L ");     // String
    Serial.println(Var);    // Print Variable on same line then send a line feed


body:
For debug printing, you can define a macro to print both the name and value of a variable like this:

    #define PRINTLN(var) Serial.print(#var ": "); Serial.println(var)

which you then use like this:

    int x = 5;
    PRINTLN(x);

    // Prints 'x: 5'

--------------

Also this is nice:

    #define PRINT(var) Serial.print(#var ":\t"); Serial.print(var); Serial.print('\t')
    #define PRINTLN(var) Serial.print(#var ":\t"); Serial.println(var)

when used in a loop like so

    PRINT(x);
    PRINT(y);
    PRINTLN(z);

prints an output like this:

    x: 3 y: 0.77 z: 2
    x: 3 y: 0.80 z: 2
    x: 3 y: 0.83 z: 2


body:
Thanks a lot for your answers. I made this ...

    #define DEBUG  //If you comment this line, the functions below are defined as blank lines.
    #ifdef DEBUG    //Macros
      #define Say(var)    Serial.print(#var"\t")   //debug print, do not need to put text in between of double quotes
      #define SayLn(var)  Serial.println(#var)  //debug print with new line
      #define VSay(var)    Serial.print(#var " =\t"); Serial.print(var);Serial.print("\t")     //variable debug print
      #define VSayLn(var)  Serial.print(#var " =\t"); Serial.println(var)  //variable debug print with new line
    #else
      #define Say(...)     //now defines a blank line
      #define SayLn(...)   //now defines a blank line
      #define VSay(...)     //now defines a blank line
      #define VSayLn(...)   //now defines a blank line
    #endif


message:
ATMega328P-PU and 328P-AU

im planing to make my very own arduino design based on the Arduino PRO mini. I picked this board instead of the UNO mostly because it's way more simpler compared with the UNO since the USB-to-Serial part is missing. As many of you know the MINI uses the 328P-AU which is the SMD version of the 328P however since the AU version is too small for me i would like to use the PU (UNO's chip) instead. From the datasheets the only difference is a small change in the pins position. And the one million dollar question is: Is there any difference on those 2 chips? If i try to use the same design just with the PU model is it gonna work?

body: I would go with the PU version because you can work on a breadboard with it for testing. If you are going to make a surface mount this to a PCB then use the AU. Regarding the actual difference forgetting about form factor, there is none.


body: There is no difference as far as Arduino is concerned. I think the AU has a couple extra pins (analog ins), that you might want to route to header locations in a surface mount design, but if your design is based on an Uno, them you can also just leave those pins disconnected with no impact.


body:
The `-AU` and `-PU` suffixes on the part name indicate different packages. The former is used for the "32A" package (32-lead TQFP), and the latter is used for the "28P3" package (28-lead DIP). In plain English, the `-AU` is a surface-mount part, and the `-PU` is a breadboard-friendly chip.

As far as functionality, there is virtually no difference. The 32A package exposes pins for ADC6 and ADC7, which are not available on the 28P3 package, but they are otherwise identical. (Note that these pins are *only* used for the ADCs; they are not a member of any port, and thus cannot be used for digital I/O.)


message:
ModbusMaster.h - changing node

I'm using the ModbusMaster.h library on a project, with arduino-uno and a TTL/RS-485 converter, and the function has to identify the slave that it is communicating. The slaves goes from 1 to 16. After I've begun the connection,

    ModbusMaster node(1);
    node.begin(9600);

I have to send a message, and if this massage returns an error, I have to change the slave number, until I got an valid answer. But I didn't find any functions to close this connection, or to delete it, I even have tried,

    delete &node;

but it didn't work. I'm trying to close this connection so I could begin another one with another node, because I didn't find a function to change the slave number.

body:
Maybe this question is too old and the API has changed, so my answer is reference.

The ModbusMaster constructor does not accept parameters.

From reading the source code, the method `begin(uint8_t slave, Stream &serial)` just initializes variables and can be called again with a new `slave` value without the need to destroy the ModbusMaster object.

Reference:

[1] https://github.com/4-20ma/ModbusMaster/blob/master/src/ModbusMaster.cpp, line 61.


message:
I want a couple of servos to listen for P.C. input (data from OSC protocol), can I bypass having to use an Arduino?

...and whack a stripped usb cable straight into a prototype board?

by bypass having to use an arduino I mean any kind of sheild? polulu would be perfect but im trying to avoid needing any of this.

My issue for finding tutorials and documentation on the subject is not quite knowing what keywords to search for, could someone point me in the right direction?

body:
If I understand your question correctly you're asking if you can control servos with OSC and no microcontroller.

OSC is a protocol used for networking and communication between synthesizers, similar to midi in that, but totally different in the way OSC sends data which looks a bit like XML.

There's a couple of problems here:

**1.** *Servos will not respond to OSC-signals. You could use MAX/MSP to generate servo-pulses from the OSC. The problem arises whan you are going to send this to the servos using usb.*

**2.** *USB, a fast data-transmission technology, is not suitable to be connected straight into a servomotor.*

Arduino uses an atmega16u to transform the data from usb to serial (called a usb to serial programmer) for programming and communication. Then the microcontroller (atmega168/328) takes this and creates a pulse and a signal for the servo-motors.

**To control servos without a micro-controller using USB is impossible.**

It is be possible to control electronics using the serial-port and low-level coding. Used to do stuff like that on a Commodore 64 a time ago. Before these affordable, stable, reliable avr, arm and pic programming cards came out.

*A tip*: It is possible to load a program onto an atmega168/328 using a Arduino UNO or similar. Take the chip off of the programming card(ie. the Arduino UNO) and create a stripped down version, containing the micro-controller chip, 16kHz crystal, some capacitors and an usb to serial converter/ftdi-cable.

Regards

Krister Borge


body:
A build-your-own-duino isn't hard to do and it is quite inexpensive. It will make your life (or the part it you're about to spend creating custom hardware) much, much easier! I have built [Joao Alves' CSE-duino][1] for example and it has everything an UNO has except for:

- on-board USB (use an FTDI cable that has USB <-> Serial in the cable head)
- a 3.3v power supply; and
- an ISP (high-voltage programming) connector;

, none of which you should need to drive a servo.

  [1]: http://jpralves.net/cseduino/


message:
Is it possible to connect many arduino uno in one pc?

We have many Arduinos and we will be putting each of them in a cubicle. All of them are connected to only one PC. The PC will stand as a server were you can control your Arduino there.

body:
Yes, you can connect multiple Arduino UNO (USB) boards to a single PC. There's a simple way and a more advanced way to manage it.

The simple way is, having multiple boards plugged in, but using only one `Arduino Software` IDE to control one board at a time. (*IDE = Integrated Development Environment. Some elements of the Arduino system use non-standard technical terms.*) **Use the `Tools > Port` menu to select which one of the attached boards to control.** The selected board type and port appear in the lower right status bar.

A more advanced way to manage multiple boards, is to open multiple Arduino Software IDE instances -- each instance has its own independent `Tools > Port` setting. You could then edit, verify, and upload two different "sketches" (*programs*) to two different boards, without losing your place and without having to constantly change the Tools > Port setting. This would be convenient if you were developing a communications protocol between two or more boards.

**This multiple-ports technique won't work unless you launch another instance of the Arduino Software IDE, without closing the first one.** It isn't enough to use the `File` menu to open another window, because then you just get another window that shares the same `Tools > Ports` setting. Changing the ports setting on one window, changes the setting on all of the windows that belong to that instance. To support multiple boards at the same time, you have to actually launch the Arduino Software IDE again, without closing the first one, to create a second instance.

Usually you'd expect each window would represent a unique document, and they'd all be related to the application. But Arduino Software IDE has a hidden dependency between its windows. Whenever you restart the IDE, that opens a new and invisible *instance* of the IDE, where it remembers the board and port settings. If you use the File menu to open a new window, that new window is still part of the same IDE. So changing the `Tools > Port` setting on one window, changes that setting for all of the windows that belong to that instance of the IDE.

But if you restart the Arduino Software IDE (e.g. Windows Start Menu > Arduino-1.6.0), without closing the previously opened IDE, then you get a second instance. If you pay attention to the port setting visible on the lower right status bar of each window, you can distinguish which windows belong to which IDE instance.

Each time you launch the Arduino Software IDE, you start a new *instance* of the software, that can talk to one board. Each instance of the IDE can have an unlimited number of windows, but they all share the same Tools > Port setting. If you re-launch the Arduino Software IDE again without closing it first, then you get a second instance that can have a different Tools > Port setting, and thus control another board at the same time.

Verified on Windows 7, Arduino Software IDE 1.6.0, with two Arduino UNO revision R2 boards (firmware rev 0001), Arduino device driver 1.0.0.0.


body: I've run into the same question my self just on a Mac so in case anyone with Mac run into it: It is possible to connect and use many Arduinos to Mac at the same time. To do so run `$ open -n /Applications/Arduino.app/` which will open a second instance of the Arduino IDE and you'll be able to select the Board and Port of each one and open multiple Serial windows. Notice that each Serial window has the path to the serial device which will help you know which window connected to which Arduino.


body:
I connect multiple arduinos to my  ubuntu system. I use text editor to write code and upload code and read output from terminal.

List arduino devices

    $ ls /dev/ttyACM*
    /dev/ttyACM0    /dev/ttyACM1

To upload code to arduino

    # to arduino 1
    $ arduino --port /dev/ttyACM0 --board arduino:avr:uno --upload bt/bt.ino

     # to arduino 2
    $ arduino --port /dev/ttyACM1 --board arduino:avr:mega --upload bt/bt.ino

To check output

    $ screen /dev/ttyACM1 115200

    $ screen /dev/ttyACM0 9600


body: yes, you are only limited by the number of USB ports you have, however you have to consider is this is the best way to achieve what you are trying to do. You can get an ESP8266 device like the nodemcu, or something that gives you a wireless connection. With this, you can connect infinite number of devices to the central PC wirelessly. A Bluetooth module is also a good idea, it all depends on your budget and what you are trying to achieve.


message:
For the digital output pins, how is LOW different than no connection?

I am working with relays and I noticed that connecting the trigger pin to ground (or a digital pin set to LOW) is not the same as having the trigger connected to anything.  For the digital output pins, how is LOW different than no connection?  Is there actually a current flowing into the LOW pin, or is there a tiny current flowing into the relay?

Is Ground and LOW the same voltage?

body: Ground and LOW are very, very close in voltage. They are the same when no current is being sunk into the output (LOW sinks current from higher voltages, HIGH sources current to lower voltages), but the voltage rises as the current does (the output has a resistance of about 25ohm).


body:
*(Edit for clarification: I've assumed in this answer that you're asking about the difference between connecting the relay to ground/LOW vs. connecting the relay to nothing at all. I've also assumed by the word "trigger" that your relay has some kind of digital actuation built-in, such as a transistor, or that it's simply a Solid State Relay.)*

If something is unconnected, it is described as 'floating'. This means there could be random voltage spikes in it caused by nearby electromagnetic fields, making it appear to be switching on/off.

Connecting something to ground or LOW can stop this from happening by drawing away any induced currents.


message:
NodeJS (Galileo-IO) + Arduino sensor library

I've done some basic apps with NodeJS firmata where I can connect to my Arduino Uno and do the basics like reading a pin or doing a servo write. I'd like to go further and play with some different sensors from vendors like Adafruit.

Many such sensors appear to come with their own Arduino libraries. Using NodeJS firmata to communicate with my Uno, could I somehow use the sensor libraries? Maybe by including their header files in the Standard Firmata sketch before uploading or...? But then I don't know how I'd get at their methods from my NodeJS app.

Even better, I'd love a little direction on how to go about using an Arduino sensor library in a sketch, and use Galileo-IO to interact with the sensor that way, if possible.

body:
Including the header files for the libraries in the standard Firmata
sketch is only the first step. You will have to also modify the sketch in
order to actually _use_ the libraries. You will have to figure out a way
of interacting with the libraries through the Firmata protocol and
implement this in your modified version of the sketch. You will then
have to modify the JavaScript side to enable these new interactions.
That's where you will write the missing methods


message:
Arduino on ubuntu 14.4 gives "Broken pipe" and "Input/output error"

Im using arduino (R2) uno board and my pc is running 64bit ubuntu 14.4.
I was previously using arduino on ubuntu 10.04 for a long time and got no error. I recently moved to 14.4 from 10.4.

I installed arduino using this command

    $ sudo apt-get update && sudo apt-get install arduino arduino-core

later arduino appeared, but was not working. According to [this link][1], i was able to launch the IDE on mouse click. I then tried to upload servo examples, i get following errors.

    Binary sketch size: 1,056 bytes (of a 32,256 byte maximum)
    ioctl("TIOCMSET"): Broken pipe
    ioctl("TIOCMGET"): Input/output error

I get the same error for even an Led blinking program too.

**Update 1:** (after Edgar's comment)

on terminal i get

    ~$ /usr/share/arduino/hardware/tools/avr/bin/avr-g++ -c -g -Os -Wall -fno-exceptions -ffunction-sections -fdata-sections -mmcu=atmega328p -DF_CPU=16000000L -MMD -DUSB_VID=null -DUSB_PID=null -DARDUINO=105 -D__PROG_TYPES_COMPAT__ -I/usr/share/arduino/hardware/arduino/cores/arduino -I/usr/share/arduino/hardware/arduino/variants/standard -I/usr/share/arduino/libraries/Servo /tmp/build4933543797518254688.tmp/Sweep.cpp -o /tmp/build4933543797518254688.tmp/Sweep.cpp.o
    avr-g++: error: /tmp/build4933543797518254688.tmp/Sweep.cpp: No such file or directory
    avr-g++: fatal error: no input files
    compilation terminated.

But on the IDE, after enabling verbos i get

    /usr/share/arduino/hardware/tools/avr/bin/avr-g++ -c -g -Os -Wall -fno-exceptions -ffunction-sections -fdata-sections -mmcu=atmega328p -DF_CPU=16000000L -MMD -DUSB_VID=null -DUSB_PID=null -DARDUINO=105 -D__PROG_TYPES_COMPAT__ -I/usr/share/arduino/hardware/arduino/cores/arduino -I/usr/share/arduino/hardware/arduino/variants/standard -I/usr/share/arduino/libraries/Servo /tmp/build4933543797518254688.tmp/Sweep.cpp -o /tmp/build4933543797518254688.tmp/Sweep.cpp.o
    /usr/share/arduino/hardware/tools/avr/bin/avr-g++ -c -g -Os -Wall -fno-exceptions -ffunction-sections -fdata-sections -mmcu=atmega328p -DF_CPU=16000000L -MMD -DUSB_VID=null -DUSB_PID=null -DARDUINO=105 -D__PROG_TYPES_COMPAT__ -I/usr/share/arduino/hardware/arduino/cores/arduino -I/usr/share/arduino/hardware/arduino/variants/standard -I/usr/share/arduino/libraries/Servo -I/usr/share/arduino/libraries/Servo/utility /usr/share/arduino/libraries/Servo/Servo.cpp -o /tmp/build4933543797518254688.tmp/Servo/Servo.cpp.o
    /usr/share/arduino/hardware/tools/avr/bin/avr-gcc -c -g -Os -Wall -ffunction-sections -fdata-sections -mmcu=atmega328p -DF_CPU=16000000L -MMD -DUSB_VID=null -DUSB_PID=null -DARDUINO=105 -D__PROG_TYPES_COMPAT__ -I/usr/share/arduino/hardware/arduino/cores/arduino -I/usr/share/arduino/hardware/arduino/variants/standard /usr/share/arduino/hardware/arduino/cores/arduino/wiring_analog.c -o /tmp/build4933543797518254688.tmp/wiring_analog.c.o
    /usr/share/arduino/hardware/tools/avr/bin/avr-gcc -c -g -Os -Wall -ffunction-sections -fdata-sections -mmcu=atmega328p -DF_CPU=16000000L -MMD -DUSB_VID=null -DUSB_PID=null -DARDUINO=105 -D__PROG_TYPES_COMPAT__ -I/usr/share/arduino/hardware/arduino/cores/arduino -I/usr/share/arduino/hardware/arduino/variants/standard /usr/share/arduino/hardware/arduino/cores/arduino/avr-libc/malloc.c -o /tmp/build4933543797518254688.tmp/malloc.c.o
    /usr/share/arduino/hardware/tools/avr/bin/avr-gcc -c -g -Os -Wall -ffunction-sections -fdata-sections -mmcu=atmega328p -DF_CPU=16000000L -MMD -DUSB_VID=null -DUSB_PID=null -DARDUINO=105 -D__PROG_TYPES_COMPAT__ -I/usr/share/arduino/hardware/arduino/cores/arduino -I/usr/share/arduino/hardware/arduino/variants/standard /usr/share/arduino/hardware/arduino/cores/arduino/avr-libc/realloc.c -o /tmp/build4933543797518254688.tmp/realloc.c.o
    /usr/share/arduino/hardware/tools/avr/bin/avr-gcc -c -g -Os -Wall -ffunction-sections -fdata-sections -mmcu=atmega328p -DF_CPU=16000000L -MMD -DUSB_VID=null -DUSB_PID=null -DARDUINO=105 -D__PROG_TYPES_COMPAT__ -I/usr/share/arduino/hardware/arduino/cores/arduino -I/usr/share/arduino/hardware/arduino/variants/standard /usr/share/arduino/hardware/arduino/cores/arduino/wiring_digital.c -o /tmp/build4933543797518254688.tmp/wiring_digital.c.o
    /usr/share/arduino/hardware/tools/avr/bin/avr-gcc -c -g -Os -Wall -ffunction-sections -fdata-sections -mmcu=atmega328p -DF_CPU=16000000L -MMD -DUSB_VID=null -DUSB_PID=null -DARDUINO=105 -D__PROG_TYPES_COMPAT__ -I/usr/share/arduino/hardware/arduino/cores/arduino -I/usr/share/arduino/hardware/arduino/variants/standard /usr/share/arduino/hardware/arduino/cores/arduino/wiring_pulse.c -o /tmp/build4933543797518254688.tmp/wiring_pulse.c.o
    /usr/share/arduino/hardware/tools/avr/bin/avr-gcc -c -g -Os -Wall -ffunction-sections -fdata-sections -mmcu=atmega328p -DF_CPU=16000000L -MMD -DUSB_VID=null -DUSB_PID=null -DARDUINO=105 -D__PROG_TYPES_COMPAT__ -I/usr/share/arduino/hardware/arduino/cores/arduino -I/usr/share/arduino/hardware/arduino/variants/standard /usr/share/arduino/hardware/arduino/cores/arduino/wiring.c -o /tmp/build4933543797518254688.tmp/wiring.c.o
    /usr/share/arduino/hardware/tools/avr/bin/avr-gcc -c -g -Os -Wall -ffunction-sections -fdata-sections -mmcu=atmega328p -DF_CPU=16000000L -MMD -DUSB_VID=null -DUSB_PID=null -DARDUINO=105 -D__PROG_TYPES_COMPAT__ -I/usr/share/arduino/hardware/arduino/cores/arduino -I/usr/share/arduino/hardware/arduino/variants/standard /usr/share/arduino/hardware/arduino/cores/arduino/wiring_shift.c -o /tmp/build4933543797518254688.tmp/wiring_shift.c.o
    /usr/share/arduino/hardware/tools/avr/bin/avr-gcc -c -g -Os -Wall -ffunction-sections -fdata-sections -mmcu=atmega328p -DF_CPU=16000000L -MMD -DUSB_VID=null -DUSB_PID=null -DARDUINO=105 -D__PROG_TYPES_COMPAT__ -I/usr/share/arduino/hardware/arduino/cores/arduino -I/usr/share/arduino/hardware/arduino/variants/standard /usr/share/arduino/hardware/arduino/cores/arduino/WInterrupts.c -o /tmp/build4933543797518254688.tmp/WInterrupts.c.o
    /usr/share/arduino/hardware/tools/avr/bin/avr-g++ -c -g -Os -Wall -fno-exceptions -ffunction-sections -fdata-sections -mmcu=atmega328p -DF_CPU=16000000L -MMD -DUSB_VID=null -DUSB_PID=null -DARDUINO=105 -D__PROG_TYPES_COMPAT__ -I/usr/share/arduino/hardware/arduino/cores/arduino -I/usr/share/arduino/hardware/arduino/variants/standard /usr/share/arduino/hardware/arduino/cores/arduino/Stream.cpp -o /tmp/build4933543797518254688.tmp/Stream.cpp.o
    /usr/share/arduino/hardware/tools/avr/bin/avr-g++ -c -g -Os -Wall -fno-exceptions -ffunction-sections -fdata-sections -mmcu=atmega328p -DF_CPU=16000000L -MMD -DUSB_VID=null -DUSB_PID=null -DARDUINO=105 -D__PROG_TYPES_COMPAT__ -I/usr/share/arduino/hardware/arduino/cores/arduino -I/usr/share/arduino/hardware/arduino/variants/standard /usr/share/arduino/hardware/arduino/cores/arduino/HID.cpp -o /tmp/build4933543797518254688.tmp/HID.cpp.o
    /usr/share/arduino/hardware/tools/avr/bin/avr-g++ -c -g -Os -Wall -fno-exceptions -ffunction-sections -fdata-sections -mmcu=atmega328p -DF_CPU=16000000L -MMD -DUSB_VID=null -DUSB_PID=null -DARDUINO=105 -D__PROG_TYPES_COMPAT__ -I/usr/share/arduino/hardware/arduino/cores/arduino -I/usr/share/arduino/hardware/arduino/variants/standard /usr/share/arduino/hardware/arduino/cores/arduino/Print.cpp -o /tmp/build4933543797518254688.tmp/Print.cpp.o
    /usr/share/arduino/hardware/tools/avr/bin/avr-g++ -c -g -Os -Wall -fno-exceptions -ffunction-sections -fdata-sections -mmcu=atmega328p -DF_CPU=16000000L -MMD -DUSB_VID=null -DUSB_PID=null -DARDUINO=105 -D__PROG_TYPES_COMPAT__ -I/usr/share/arduino/hardware/arduino/cores/arduino -I/usr/share/arduino/hardware/arduino/variants/standard /usr/share/arduino/hardware/arduino/cores/arduino/WMath.cpp -o /tmp/build4933543797518254688.tmp/WMath.cpp.o
    /usr/share/arduino/hardware/tools/avr/bin/avr-g++ -c -g -Os -Wall -fno-exceptions -ffunction-sections -fdata-sections -mmcu=atmega328p -DF_CPU=16000000L -MMD -DUSB_VID=null -DUSB_PID=null -DARDUINO=105 -D__PROG_TYPES_COMPAT__ -I/usr/share/arduino/hardware/arduino/cores/arduino -I/usr/share/arduino/hardware/arduino/variants/standard /usr/share/arduino/hardware/arduino/cores/arduino/CDC.cpp -o /tmp/build4933543797518254688.tmp/CDC.cpp.o
    /usr/share/arduino/hardware/tools/avr/bin/avr-g++ -c -g -Os -Wall -fno-exceptions -ffunction-sections -fdata-sections -mmcu=atmega328p -DF_CPU=16000000L -MMD -DUSB_VID=null -DUSB_PID=null -DARDUINO=105 -D__PROG_TYPES_COMPAT__ -I/usr/share/arduino/hardware/arduino/cores/arduino -I/usr/share/arduino/hardware/arduino/variants/standard /usr/share/arduino/hardware/arduino/cores/arduino/new.cpp -o /tmp/build4933543797518254688.tmp/new.cpp.o
    /usr/share/arduino/hardware/tools/avr/bin/avr-g++ -c -g -Os -Wall -fno-exceptions -ffunction-sections -fdata-sections -mmcu=atmega328p -DF_CPU=16000000L -MMD -DUSB_VID=null -DUSB_PID=null -DARDUINO=105 -D__PROG_TYPES_COMPAT__ -I/usr/share/arduino/hardware/arduino/cores/arduino -I/usr/share/arduino/hardware/arduino/variants/standard /usr/share/arduino/hardware/arduino/cores/arduino/HardwareSerial.cpp -o /tmp/build4933543797518254688.tmp/HardwareSerial.cpp.o
    /usr/share/arduino/hardware/arduino/cores/arduino/HardwareSerial.cpp: In function ‘void store_char(unsigned char, ring_buffer*)’:
    /usr/share/arduino/hardware/arduino/cores/arduino/HardwareSerial.cpp:100:20: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
       if (i != buffer->tail) {
                        ^
    /usr/share/arduino/hardware/arduino/cores/arduino/HardwareSerial.cpp: In function ‘void __vector_18()’:
    /usr/share/arduino/hardware/arduino/cores/arduino/HardwareSerial.cpp:129:21: warning: unused variable ‘c’ [-Wunused-variable]
           unsigned char c = UDR0;
                         ^
    /usr/share/arduino/hardware/arduino/cores/arduino/HardwareSerial.cpp: In member function ‘void HardwareSerial::begin(long unsigned int, byte)’:
    /usr/share/arduino/hardware/arduino/cores/arduino/HardwareSerial.cpp:370:11: warning: unused variable ‘current_config’ [-Wunused-variable]
       uint8_t current_config;
               ^
    /usr/share/arduino/hardware/arduino/cores/arduino/HardwareSerial.cpp: In member function ‘virtual size_t HardwareSerial::write(uint8_t)’:
    /usr/share/arduino/hardware/arduino/cores/arduino/HardwareSerial.cpp:469:27: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
       while (i == _tx_buffer->tail)
                               ^
    /usr/share/arduino/hardware/tools/avr/bin/avr-g++ -c -g -Os -Wall -fno-exceptions -ffunction-sections -fdata-sections -mmcu=atmega328p -DF_CPU=16000000L -MMD -DUSB_VID=null -DUSB_PID=null -DARDUINO=105 -D__PROG_TYPES_COMPAT__ -I/usr/share/arduino/hardware/arduino/cores/arduino -I/usr/share/arduino/hardware/arduino/variants/standard /usr/share/arduino/hardware/arduino/cores/arduino/main.cpp -o /tmp/build4933543797518254688.tmp/main.cpp.o
    /usr/share/arduino/hardware/tools/avr/bin/avr-g++ -c -g -Os -Wall -fno-exceptions -ffunction-sections -fdata-sections -mmcu=atmega328p -DF_CPU=16000000L -MMD -DUSB_VID=null -DUSB_PID=null -DARDUINO=105 -D__PROG_TYPES_COMPAT__ -I/usr/share/arduino/hardware/arduino/cores/arduino -I/usr/share/arduino/hardware/arduino/variants/standard /usr/share/arduino/hardware/arduino/cores/arduino/Tone.cpp -o /tmp/build4933543797518254688.tmp/Tone.cpp.o
    /usr/share/arduino/hardware/tools/avr/bin/avr-g++ -c -g -Os -Wall -fno-exceptions -ffunction-sections -fdata-sections -mmcu=atmega328p -DF_CPU=16000000L -MMD -DUSB_VID=null -DUSB_PID=null -DARDUINO=105 -D__PROG_TYPES_COMPAT__ -I/usr/share/arduino/hardware/arduino/cores/arduino -I/usr/share/arduino/hardware/arduino/variants/standard /usr/share/arduino/hardware/arduino/cores/arduino/IPAddress.cpp -o /tmp/build4933543797518254688.tmp/IPAddress.cpp.o
    /usr/share/arduino/hardware/tools/avr/bin/avr-g++ -c -g -Os -Wall -fno-exceptions -ffunction-sections -fdata-sections -mmcu=atmega328p -DF_CPU=16000000L -MMD -DUSB_VID=null -DUSB_PID=null -DARDUINO=105 -D__PROG_TYPES_COMPAT__ -I/usr/share/arduino/hardware/arduino/cores/arduino -I/usr/share/arduino/hardware/arduino/variants/standard /usr/share/arduino/hardware/arduino/cores/arduino/USBCore.cpp -o /tmp/build4933543797518254688.tmp/USBCore.cpp.o
    /usr/share/arduino/hardware/tools/avr/bin/avr-g++ -c -g -Os -Wall -fno-exceptions -ffunction-sections -fdata-sections -mmcu=atmega328p -DF_CPU=16000000L -MMD -DUSB_VID=null -DUSB_PID=null -DARDUINO=105 -D__PROG_TYPES_COMPAT__ -I/usr/share/arduino/hardware/arduino/cores/arduino -I/usr/share/arduino/hardware/arduino/variants/standard /usr/share/arduino/hardware/arduino/cores/arduino/WString.cpp -o /tmp/build4933543797518254688.tmp/WString.cpp.o
    /usr/share/arduino/hardware/tools/avr/bin/avr-ar rcs /tmp/build4933543797518254688.tmp/core.a /tmp/build4933543797518254688.tmp/wiring_analog.c.o
    /usr/share/arduino/hardware/tools/avr/bin/avr-ar rcs /tmp/build4933543797518254688.tmp/core.a /tmp/build4933543797518254688.tmp/malloc.c.o
    /usr/share/arduino/hardware/tools/avr/bin/avr-ar rcs /tmp/build4933543797518254688.tmp/core.a /tmp/build4933543797518254688.tmp/realloc.c.o
    /usr/share/arduino/hardware/tools/avr/bin/avr-ar rcs /tmp/build4933543797518254688.tmp/core.a /tmp/build4933543797518254688.tmp/wiring_digital.c.o
    /usr/share/arduino/hardware/tools/avr/bin/avr-ar rcs /tmp/build4933543797518254688.tmp/core.a /tmp/build4933543797518254688.tmp/wiring_pulse.c.o
    /usr/share/arduino/hardware/tools/avr/bin/avr-ar rcs /tmp/build4933543797518254688.tmp/core.a /tmp/build4933543797518254688.tmp/wiring.c.o
    /usr/share/arduino/hardware/tools/avr/bin/avr-ar rcs /tmp/build4933543797518254688.tmp/core.a /tmp/build4933543797518254688.tmp/wiring_shift.c.o
    /usr/share/arduino/hardware/tools/avr/bin/avr-ar rcs /tmp/build4933543797518254688.tmp/core.a /tmp/build4933543797518254688.tmp/WInterrupts.c.o
    /usr/share/arduino/hardware/tools/avr/bin/avr-ar rcs /tmp/build4933543797518254688.tmp/core.a /tmp/build4933543797518254688.tmp/Stream.cpp.o
    /usr/share/arduino/hardware/tools/avr/bin/avr-ar rcs /tmp/build4933543797518254688.tmp/core.a /tmp/build4933543797518254688.tmp/HID.cpp.o
    /usr/share/arduino/hardware/tools/avr/bin/avr-ar rcs /tmp/build4933543797518254688.tmp/core.a /tmp/build4933543797518254688.tmp/Print.cpp.o
    /usr/share/arduino/hardware/tools/avr/bin/avr-ar rcs /tmp/build4933543797518254688.tmp/core.a /tmp/build4933543797518254688.tmp/WMath.cpp.o
    /usr/share/arduino/hardware/tools/avr/bin/avr-ar rcs /tmp/build4933543797518254688.tmp/core.a /tmp/build4933543797518254688.tmp/CDC.cpp.o
    /usr/share/arduino/hardware/tools/avr/bin/avr-ar rcs /tmp/build4933543797518254688.tmp/core.a /tmp/build4933543797518254688.tmp/new.cpp.o
    /usr/share/arduino/hardware/tools/avr/bin/avr-ar rcs /tmp/build4933543797518254688.tmp/core.a /tmp/build4933543797518254688.tmp/HardwareSerial.cpp.o
    /usr/share/arduino/hardware/tools/avr/bin/avr-ar rcs /tmp/build4933543797518254688.tmp/core.a /tmp/build4933543797518254688.tmp/main.cpp.o
    /usr/share/arduino/hardware/tools/avr/bin/avr-ar rcs /tmp/build4933543797518254688.tmp/core.a /tmp/build4933543797518254688.tmp/Tone.cpp.o
    /usr/share/arduino/hardware/tools/avr/bin/avr-ar rcs /tmp/build4933543797518254688.tmp/core.a /tmp/build4933543797518254688.tmp/IPAddress.cpp.o
    /usr/share/arduino/hardware/tools/avr/bin/avr-ar rcs /tmp/build4933543797518254688.tmp/core.a /tmp/build4933543797518254688.tmp/USBCore.cpp.o
    /usr/share/arduino/hardware/tools/avr/bin/avr-ar rcs /tmp/build4933543797518254688.tmp/core.a /tmp/build4933543797518254688.tmp/WString.cpp.o
    /usr/share/arduino/hardware/tools/avr/bin/avr-gcc -Os -Wl,--gc-sections -mmcu=atmega328p -o /tmp/build4933543797518254688.tmp/Sweep.cpp.elf /tmp/build4933543797518254688.tmp/Sweep.cpp.o /tmp/build4933543797518254688.tmp/Servo/Servo.cpp.o /tmp/build4933543797518254688.tmp/core.a -L/tmp/build4933543797518254688.tmp -lm
    /usr/share/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 /tmp/build4933543797518254688.tmp/Sweep.cpp.elf /tmp/build4933543797518254688.tmp/Sweep.cpp.eep
    /usr/share/arduino/hardware/tools/avr/bin/avr-objcopy -O ihex -R .eeprom /tmp/build4933543797518254688.tmp/Sweep.cpp.elf /tmp/build4933543797518254688.tmp/Sweep.cpp.hex
    Binary sketch size: 2,554 bytes (of a 32,256 byte maximum)
    /usr/share/arduino/hardware/tools/avrdude -C/usr/share/arduino/hardware/tools/avrdude.conf -v -v -v -v -patmega328p -carduino -P/dev/ttyACM0 -b115200 -D -Uflash:w:/tmp/build4933543797518254688.tmp/Sweep.cpp.hex:i

    avrdude: Version 6.0.1, compiled on Oct 21 2013 at 15:55:32
             Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
             Copyright (c) 2007-2009 Joerg Wunsch

             System wide configuration file is "/usr/share/arduino/hardware/tools/avrdude.conf"
             User configuration file is "/home/username/.avrduderc"
             User configuration file does not exist or is not a regular file, skipping

             Using Port                    : /dev/ttyACM0
             Using Programmer              : arduino
             Overriding Baud Rate          : 115200
    avrdude: ser_open(): can't open device "/dev/ttyACM0": No such file or directory
    ioctl("TIOCMGET"): Inappropriate ioctl for device

    avrdude done.  Thank you.

**Update 2:** (tried again, this time i get "broken pipe". Led 13 blinks like crazy and my servo sounds different, no movement but continues sound)

    .
    .
    .
    avrdude: avr_read(): skipping page 253: no interesting data
    avrdude: avr_read(): skipping page 254: no interesting data
    avrdude: avr_read(): skipping page 255: no interesting data
    avrdude: verifying ...
    avrdude: 2554 bytes of flash verified
    avrdude: Send: Q [51]   [20]
    avrdude: Recv: . [14]
    avrdude: Recv: . [10]

    avrdude done.  Thank you.

    /usr/share/arduino/hardware/tools/avr/bin/avr-g++ -c -g -Os -Wall -fno-exceptions -ffunction-sections -fdata-sections -mmcu=atmega328p -DF_CPU=16000000L -MMD -DUSB_VID=null -DUSB_PID=null -DARDUINO=105 -D__PROG_TYPES_COMPAT__ -I/usr/share/arduino/hardware/arduino/cores/arduino -I/usr/share/arduino/hardware/arduino/variants/standard -I/usr/share/arduino/libraries/Servo /tmp/build4258280580047414287.tmp/Sweep.cpp -o /tmp/build4258280580047414287.tmp/Sweep.cpp.o
      Using previously compiled: /tmp/build4258280580047414287.tmp/Servo/Servo.cpp.o
      Using previously compiled: /tmp/build4258280580047414287.tmp/wiring_analog.c.o
      Using previously compiled: /tmp/build4258280580047414287.tmp/malloc.c.o
      Using previously compiled: /tmp/build4258280580047414287.tmp/realloc.c.o
      Using previously compiled: /tmp/build4258280580047414287.tmp/wiring_digital.c.o
      Using previously compiled: /tmp/build4258280580047414287.tmp/wiring_pulse.c.o
      Using previously compiled: /tmp/build4258280580047414287.tmp/wiring.c.o
      Using previously compiled: /tmp/build4258280580047414287.tmp/wiring_shift.c.o
      Using previously compiled: /tmp/build4258280580047414287.tmp/WInterrupts.c.o
      Using previously compiled: /tmp/build4258280580047414287.tmp/Stream.cpp.o
      Using previously compiled: /tmp/build4258280580047414287.tmp/HID.cpp.o
      Using previously compiled: /tmp/build4258280580047414287.tmp/Print.cpp.o
      Using previously compiled: /tmp/build4258280580047414287.tmp/WMath.cpp.o
      Using previously compiled: /tmp/build4258280580047414287.tmp/CDC.cpp.o
      Using previously compiled: /tmp/build4258280580047414287.tmp/new.cpp.o
      Using previously compiled: /tmp/build4258280580047414287.tmp/HardwareSerial.cpp.o
      Using previously compiled: /tmp/build4258280580047414287.tmp/main.cpp.o
      Using previously compiled: /tmp/build4258280580047414287.tmp/Tone.cpp.o
      Using previously compiled: /tmp/build4258280580047414287.tmp/IPAddress.cpp.o
      Using previously compiled: /tmp/build4258280580047414287.tmp/USBCore.cpp.o
      Using previously compiled: /tmp/build4258280580047414287.tmp/WString.cpp.o
    /usr/share/arduino/hardware/tools/avr/bin/avr-ar rcs /tmp/build4258280580047414287.tmp/core.a /tmp/build4258280580047414287.tmp/wiring_analog.c.o
    /usr/share/arduino/hardware/tools/avr/bin/avr-ar rcs /tmp/build4258280580047414287.tmp/core.a /tmp/build4258280580047414287.tmp/malloc.c.o
    /usr/share/arduino/hardware/tools/avr/bin/avr-ar rcs /tmp/build4258280580047414287.tmp/core.a /tmp/build4258280580047414287.tmp/realloc.c.o
    /usr/share/arduino/hardware/tools/avr/bin/avr-ar rcs /tmp/build4258280580047414287.tmp/core.a /tmp/build4258280580047414287.tmp/wiring_digital.c.o
    /usr/share/arduino/hardware/tools/avr/bin/avr-ar rcs /tmp/build4258280580047414287.tmp/core.a /tmp/build4258280580047414287.tmp/wiring_pulse.c.o
    /usr/share/arduino/hardware/tools/avr/bin/avr-ar rcs /tmp/build4258280580047414287.tmp/core.a /tmp/build4258280580047414287.tmp/wiring.c.o
    /usr/share/arduino/hardware/tools/avr/bin/avr-ar rcs /tmp/build4258280580047414287.tmp/core.a /tmp/build4258280580047414287.tmp/wiring_shift.c.o
    /usr/share/arduino/hardware/tools/avr/bin/avr-ar rcs /tmp/build4258280580047414287.tmp/core.a /tmp/build4258280580047414287.tmp/WInterrupts.c.o
    /usr/share/arduino/hardware/tools/avr/bin/avr-ar rcs /tmp/build4258280580047414287.tmp/core.a /tmp/build4258280580047414287.tmp/Stream.cpp.o
    /usr/share/arduino/hardware/tools/avr/bin/avr-ar rcs /tmp/build4258280580047414287.tmp/core.a /tmp/build4258280580047414287.tmp/HID.cpp.o
    /usr/share/arduino/hardware/tools/avr/bin/avr-ar rcs /tmp/build4258280580047414287.tmp/core.a /tmp/build4258280580047414287.tmp/Print.cpp.o
    /usr/share/arduino/hardware/tools/avr/bin/avr-ar rcs /tmp/build4258280580047414287.tmp/core.a /tmp/build4258280580047414287.tmp/WMath.cpp.o
    /usr/share/arduino/hardware/tools/avr/bin/avr-ar rcs /tmp/build4258280580047414287.tmp/core.a /tmp/build4258280580047414287.tmp/CDC.cpp.o
    /usr/share/arduino/hardware/tools/avr/bin/avr-ar rcs /tmp/build4258280580047414287.tmp/core.a /tmp/build4258280580047414287.tmp/new.cpp.o
    /usr/share/arduino/hardware/tools/avr/bin/avr-ar rcs /tmp/build4258280580047414287.tmp/core.a /tmp/build4258280580047414287.tmp/HardwareSerial.cpp.o
    /usr/share/arduino/hardware/tools/avr/bin/avr-ar rcs /tmp/build4258280580047414287.tmp/core.a /tmp/build4258280580047414287.tmp/main.cpp.o
    /usr/share/arduino/hardware/tools/avr/bin/avr-ar rcs /tmp/build4258280580047414287.tmp/core.a /tmp/build4258280580047414287.tmp/Tone.cpp.o
    /usr/share/arduino/hardware/tools/avr/bin/avr-ar rcs /tmp/build4258280580047414287.tmp/core.a /tmp/build4258280580047414287.tmp/IPAddress.cpp.o
    /usr/share/arduino/hardware/tools/avr/bin/avr-ar rcs /tmp/build4258280580047414287.tmp/core.a /tmp/build4258280580047414287.tmp/USBCore.cpp.o
    /usr/share/arduino/hardware/tools/avr/bin/avr-ar rcs /tmp/build4258280580047414287.tmp/core.a /tmp/build4258280580047414287.tmp/WString.cpp.o
    /usr/share/arduino/hardware/tools/avr/bin/avr-gcc -Os -Wl,--gc-sections -mmcu=atmega328p -o /tmp/build4258280580047414287.tmp/Sweep.cpp.elf /tmp/build4258280580047414287.tmp/Sweep.cpp.o /tmp/build4258280580047414287.tmp/Servo/Servo.cpp.o /tmp/build4258280580047414287.tmp/core.a -L/tmp/build4258280580047414287.tmp -lm
    /usr/share/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 /tmp/build4258280580047414287.tmp/Sweep.cpp.elf /tmp/build4258280580047414287.tmp/Sweep.cpp.eep
    /usr/share/arduino/hardware/tools/avr/bin/avr-objcopy -O ihex -R .eeprom /tmp/build4258280580047414287.tmp/Sweep.cpp.elf /tmp/build4258280580047414287.tmp/Sweep.cpp.hex
    Binary sketch size: 2,554 bytes (of a 32,256 byte maximum)
    /usr/share/arduino/hardware/tools/avrdude -C/usr/share/arduino/hardware/tools/avrdude.conf -v -v -v -v -patmega328p -carduino -P/dev/ttyACM0 -b115200 -D -Uflash:w:/tmp/build4258280580047414287.tmp/Sweep.cpp.hex:i

    avrdude: Version 6.0.1, compiled on Oct 21 2013 at 15:55:32
             Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
             Copyright (c) 2007-2009 Joerg Wunsch

             System wide configuration file is "/usr/share/arduino/hardware/tools/avrdude.conf"
             User configuration file is "/home/username/.avrduderc"
             User configuration file does not exist or is not a regular file, skipping

             Using Port                    : /dev/ttyACM0
             Using Programmer              : arduino
             Overriding Baud Rate          : 115200
    ioctl("TIOCMSET"): Broken pipe
    ioctl("TIOCMGET"): Input/output error

  [1]: http://vishnuvarkala.blogspot.in/2012/07/arduino-ide-not-detecting-serial-port.html

body: Please use the last IDE version released here: arduino.cc/en/Main/Software The version 1.6.1 has many improvements about serial devices detection and sketches upload. It will solve your issues about older Arduino UNO version and Arduino Yun.


message:
Arduino Uno with CC3000 WiFi Shield cannot be initialized

I am working on an Arduino Uno and CC3000 WiFi shield. I interfaced it over my Arduino and added the SparkFun library `SFE_CC3000_Library`. Then I opened the TestBoard example, but it hangs on setup in the first command `wifi.init()`.

How can I solve this problem, and how can I enable debug mode?

Here's the code

    #include <SPI.h>
    #include <SFE_CC3000.h>
    #include <utility/netapp.h>

    #define DEBUG     1
    // Pins
    #define CC3000_INT      2   // Needs to be an interrupt pin (D2/D3)
    #define CC3000_EN       7   // Can be any digital pin
    #define CC3000_CS       10  // Preferred is pin 10 on Uno

    // Constants
    #define FW_VER_LEN      2   // Length of firmware version in bytes
    #define MAC_ADDR_LEN    6   // Length of MAC address in bytes

    // Global Variables
    SFE_CC3000 wifi = SFE_CC3000(CC3000_INT, CC3000_EN, CC3000_CS);

    void setup() {

      int i;
      unsigned char fw_ver[FW_VER_LEN];
      unsigned char mac_addr[MAC_ADDR_LEN];

      // Initialize Serial port
      Serial.begin(115200);
      Serial.println();
      Serial.println("----------------------------");
      Serial.println("SparkFun CC3000 - Board Test");
      Serial.println("----------------------------");

      // Initialize CC3000 (configure SPI communications)
      if ( wifi.init() ) {
        digitalWrite(13, HIGH);
        Serial.println("CC3000 initialization complete");
      } else {
        Serial.println("Something went wrong during CC3000 init!");
      }

      // Read and display CC3000 firmware version
      if ( wifi.getFirmwareVersion(fw_ver) ) {
        Serial.print("Firmware version: ");
        Serial.print(fw_ver[0], DEC);
        Serial.print(".");
        Serial.print(fw_ver[1], DEC);
        Serial.println();
      } else {
        Serial.println("Could not read firmware version from CC3000");
      }

      // Read and display CC3000 MAC address
      if ( wifi.getMacAddress(mac_addr) ) {
        Serial.print("MAC address: ");
        for ( i = 0; i < MAC_ADDR_LEN; i++ ) {
          if ( mac_addr[i] < 0x10 ) {
            Serial.print("0");
          }
          Serial.print(mac_addr[i], HEX);
          if ( i < MAC_ADDR_LEN - 1 ) {
            Serial.print(":");
          }
        }
        Serial.println();
      } else {
        Serial.println("Could not read MAC address from CC3000");
      }

      // Done!
      Serial.println("Finished board test");

    }

    void loop() {

      // Do nothing
      delay(1000);
      Serial.println("Loop_Problem");

        }

body: Solved it, the problem was because the SparkFun library was not working with my shield. I replaced it using the `Adafruit_CC3000_Library` and now it works fine.


message:
Pair of nRF24L01s ping/pong example sketch works, but using my own code fails after first successful transmit

I have a pair of nRF24L01s connected to a pair of Arduino Unos and I'm using the RF24 library from here: [RF24 library][1]. When I run the pingpair example sketch, the radios transmit and receive back and forth just fine. So I tried to program my own very simple example but I'm running into a problem where the first message transmits successfully (and is received successfully), however, subsequent messages fail to send. The call to radio.write() returns false.

I'm using the following code on the 'sender':

    RF24 radio(9,10);
    const uint64_t pipes[2] = { 0xF0F0F0F0E1LL, 0xF0F0F0F0D2LL };
    uint8_t payload[1];

    void setup() {
      Serial.begin(9600);
      radio.begin();
      radio.setRetries(15, 15);
      radio.setPayloadSize(1);
      radio.openWritingPipe(pipes[0]);
    }

    void loop() {
      payload[0] = 1;
      bool ok = radio.write(payload, 1);
      Serial.println("Status: " + (String) ok);
      delay(200);
    }

And the following on the 'receiver':

    RF24 radio(9,10);
    const uint64_t pipes[2] = { 0xF0F0F0F0E1LL, 0xF0F0F0F0D2LL };
    uint8_t payload[1];

    void setup() {
      Serial.begin(9600);
      radio.begin();
      radio.setRetries(15, 15);
      radio.setPayloadSize(1);
      radio.openReadingPipe(1, pipes[0]);
      radio.startListening();
      Serial.println("Listening: " );
    }

    void loop() {
      if (radio.available()) {
        bool done = false;
        while (!done) {
          done = radio.read(payload, 1);
          Serial.println("Got payload: " + (String) payload[0]);
        }
      }
    }

I'm guessing the problem has to be with my code because the example sketches work, but I can't figure out what the problem is. Again to summarize, when I reset the Arduino, the first call to `radio.write()` returns true and the message is transmitted. After that, subsequent calls to `radio.write()` return false.

Also note that I did try adding a 10uF capacitor across +3.3V and Ground but it did not help.

Thanks for any help.

  [1]: https://github.com/maniacbug/RF24

body: Comparing your rx against the example, i would suggest not having the while done statement. You could also throw in a few serial.write debug lines in both sketches, to log different parts of the code, to find where its getting stuck.


body:
I was just having this issue. You need to be able to read and write on both ends. You send up sending an ack package back to the sending arduino like in the test sketch.

You ripped that part out.

You need to read back through the example code and line by line understand what the data is doing and why it's doing it that way before you can start using rf24.

The short of it is that the sender will send data and then finish and wait for a response packet before sending the next one. The reciever works much the same way except it always will be listening for incoming data until the sender message ends. Then it in turn will send a reply packet saying that it recieved the first packet.

Make sure that the reciever isn't looping waiting for packets. It should only respond once it recieves something. The sender should have a timeout on it so that it knows that it's messages are failing. This is also incredibly important for debugging so you can see who failed and why.

This is basically tcp at work.

You can also use noack and that's called udp


body:
You should open a reading pipe on the transmitter end because when the reader receives your message it will reply with an acknowledge packet, which is expected by the writer in order to confirm the packet has been delivered. With your current setup, your writer is sending out a packet and expecting to receive the response on an address which is by default configured as a broadcast address.

On the sender side, you also need to start listening after sending the packet and stop listening before sending the new packet.

The transmission protocol works like this:

1. the sender sends a packet in the air and starts waiting for the ack
2. all listeners receive the packet, no matter their receive address
3. each listener check if the sender address matches with any configured reading pipe address
   1. if the address matches then the listener sends back an acknowledge packet to inform the transmission has been accomplished
   2. if the address does not match it discards the packet
5. if the sender receives at least one acknowledge packet then it marks the packet as being sent successfully
6. if the sender doesn't receive the ack packet within the configured time to live then sends the packet again until the retry count has not been reached
7. if the retry count has been reached then it marks the transmission as failed

So change your sender `setup()` and `loop()` functions above with:

    void setup() {
      Serial.begin(9600);
      radio.begin();
      radio.setRetries(15, 15);
      radio.setPayloadSize(1);
      radio.openWritingPipe(pipes[0]);
      radio.openReadingPipe(1, pipes[1]); // add this
    }

    void loop() {
      radio.stopListening(); // add this
      payload[0] = 1;
      bool ok = radio.write(payload, 1);
      radio.startListening(); // add this
      Serial.println("Status: " + (String) ok);
      delay(200);
    }

You might also want to set the writing address on the receiver if you plan to use more than 2 radios, otherwise, you will not be able to distinguish who has acknowledged different packets:

    radio.openWritingPipe(pipes[1]); // add this to receiver `setup()`


message:
Powering USB device from arduino uno?

I'm wanting to power a USB device from an Arduino Uno. Forgetting about the two data pins, it just requires power. Using a power meter, I can detect the 5v pin at about 4.95 volts, however I don't have access to any resistors at the moment so cannot test the amperage because it just shorts.

The USB device I want to power requires ~300mA (can't remember specifically). First of all, does the Arduino get 100mA or 500mA when getting power from the USB? Is this changeable depending on the setting on the USB Host (High 500mA, or Low 100mA)?

Secondly, how much would actually be usable? I assume the Arduino itself would require some of that current? Even more if a program where running on it at the same time? (I have no idea how computers utilize power) I would like to just hook up my usb device to ground and 5V with whatever resistors (and any other electrical components) in between to bring it down from 500mA to the required ~300mA.

body:
You'd have to test this but there's a chance you could supply the Arduino using a DC power supply on it's 5V pin. In this case DO NOT TURN YPUR SUPPLY HIGHER THAN 5V, as I don't believe there is any protection and will send the full voltage to the USB.

A safer option would be the Vin pin. Normally you'd want to put 7-12 Volts to this pin but you may want to start at 5V and work your way up just to be safe.

Someone please corrects if I am wrong, but if you never apply more than an external 5V your worst case scenario would be burning out the Arduino but not the USB device.


body:
The Arduino receives 500mA max from USB power.  That is per the USB specification, and the Arduino has a 500mA resettable fuse on the USB power to protect your computer's USB port from 'accidents'.

As to the question of whether it is configurable between 500mA/100mA, generally no it's not. I believe that part of the USB negotiation that occurs when the Arduino connects to your PC is that the Arduino describes itself to the computer, and it reports that it is a 500mA device. Bottom line is, you won't need to do anything special in this regard.

Now, how much of the power is needed for the Arduino, and how much is left over - well that depends on what else the Arduino is doing and what else it's powering (LEDs, etc.). If the Arduino is not doing much else, than 200mA should be plenty of headroom for it.

If you power the Arduino through the PWR Jack (or the Vin), then the voltage should be a minimum of 7V. That is because it is feeding into a 5v regulator, which has some voltage drop, so it needs about 7V to be able to consistently supply 5V output.  If you power the Arduino manually (through the 5V pin), you want to give it 5V. Anything less than 5V would be considered overclocking. (The ATMEGA328P needs 5V to operate at 16mHz, but can run at lower voltages when clocked at lower speeds.)

Also, keep in mind that the USB port on the Arduino is a USB 'client', not a USB host or USB OTG. Therefore, the port can not be used to supply outbound power. You can power your extra device from the Arduino's 5V and GND pins.


message:
which is the most efficient way to save power with battery using Arduino UNO?

I am working with a ArduinoUNO - 2100 mA battery, and a solar Charger shield. I use a temperature reader that sends info **every half hour with GPS-GSM shield** called LONET (http://www.seeedstudio.com/wiki/LoNet_-_GSM/GPRS/GPS_Breakout for more info).

I want to save all the energy i can, i am trying to put Arduino UNO and LONET on Sleep mode.

LONE has its own mode via “AT+CSCLK=1”.

But for Arduino UNO i haven seen a library called Narcoleptic (https://code.google.com/p/narcoleptic/ for more info) wich can solve the problem.

My question is:

Is there any other method that can help me to save Battery with Arduino uno? is it a good approach to use Narcoleptic or there is another method to do it?

Thanks for your time/help and sorry for my English.

Any feedback could be welcome.

body:
There's a great article on that topic: [https://www.openhomeautomation.net/arduino-battery/][1]

  [1]: https://www.openhomeautomation.net/arduino-battery/


body:
There is an even greater article on this topic: http://www.gammon.com.au/power

It shows how to reduce your power usage for the Uno from about 50mA to 350nA (0.000350mA) - at this point, you need to factor in the natural drain of batteries.

Also, I have had good success with a project that was activated by a pushbutton, by using a latch - the push button turned the power on; once the power is on, it latched. Then the Arduino can switch itself off, using one of it's pins. As far as I can tell from a simulator, there is no leakage (while it is off, to within the accuracy of the simulator, assuming a perfectly spherical transistor in a vacuum ;) ).

Just in case anyone is interested, my latch circuit can be seen at: https://i.stack.imgur.com/Uf9sX.png - the two resistors and the switch at the bottom represent the Arduino - +5V coming in the top, GND at the bottom, and one of the pin to switch it off is the switch - this pin should be INPUT to keep the power on; when you are ready to switch of, set it to output -> high. You should get switched off immediately. The switch at the top will switch it on. In the startup part of your sketch, set the pin to INPUT first.


message:
Connecting hardware to the Arduino

I'm using an Arduino Due with various sensors. At the moment, I'm using the majority of the pins along the width (the double width pins). I want to make the setup more permanent, however I can't seem to find any ribbon cables with 36-conductors. What do you use for long term connections on the Due, especially if you occasionally need to unplug all the connections? Would a 40-pin ribbon cable work as they're easy to come by.

Thanks

body: I have used 40 pin cables for this purpose, specifically, IDE cables (beware: on high speed, "80 conductor" cables, but still with 40 pin connectors, some pins are permanently connected, to indicate to to the controller that this is a high speed cable!). The connectors are cheap, the cables are free if you ask around (probably less so now). In my case, I connected two extra-large 7-segment displays, and it worked great. More pins than you rarely hurts. In my case, it was especially useful since I needed some pins at the top, and some pins at the bottom of the display; my ide cable had three connectors (motherboard & two drives); I used the top row on one ide connector to the top of of my displays, and the bottom row of pins on the other connector to the bottom of the displays.


body:
You can also make your own IDC ribbon cables pretty easily. A 36-pin cable might be pretty hard to find a connector for, but you could use a 20-pin and a 16-pin side by side.

Have a look at [Kobicon 164-9008-E](http://www.mouser.com/ProductDetail/Kobiconn/164-9008-E/?qs=sGAEpiMZZMs%2bGHln7q6pm2gjsa6Tcy/kwHR%2bX1kBnDU=) and [Kobicon 164-9001-E](http://www.mouser.com/ProductDetail/Kobiconn/164-9001-E/?qs=sGAEpiMZZMs%2bGHln7q6pm2gjsa6Tcy/khD4TEkl7%2bnc=).

You can get creative and mix and match different pin counts, depending on your project. Buy a few meters of 40-conductor .05" pitch ribbon cable, and you can peel off the 4 outermost conductors to make it 36-conductor, as well as separating the end of the cable into your connector groups.


body:
Take a look at these jumper wires. http://www.amazon.com/gp/aw/d/B00M5WLZDW/ref=mp_s_a_1_6?qid=1431346007&sr=8-6&pi=AC_SX110_SY165_QL70 they are really great for debugging as well as more permanent solutions.

If you are looking to build more than 5 go with some of the other posted answers


message:
Why is the constrain function used after the map function?

I am reading some sample code and they use this method of mapping data from IR sensors:

      sensor1 = analogRead(0);
      adj_1 = map(sensor1, s1_min, s1_max, 0, 255);
      adj_1 = constrain(adj_1, 0, 255);

What is the point of using `constrain` here if `adj_1` is already getting a value 0-255 from the `map` function?

body:
From [the official Arduino site][1]:

> [The map function] does not constrain values to within the range, because out-of-range values are sometimes intended and useful. The constrain() function may be used either before or after this function, if limits to the ranges are desired.

EDIT: Example.

You can try this by yourself with this code:

    int val = 20;
    val = map(val, 0, 10, 0, 100);

Although you set the upper bound of the value's range to 10, you passed an higher value than that and the function will linearly map it accordingly, resulting in an output of 200.

  [1]: http://arduino.cc/en/reference/map


body:
One caveat would be when mapping an input that ranges from 0 to 1023, since the Arduino is incapable of reading outside of this range there would be no need to constrain. You can check this by running through each iteration from 0 to 1023 and outputting the corresponding mapped value:

    for (int i = 0; i < 1024; i++){
        Serial.print(i);
        Serial.print(",");
        Serial.println(map(i, 0, 1023, 0, 255));

    }

Certainly, if your sensor reading offers a range smaller than 0 to 1023, then the constrain() function is definitely required, as per LoganBlade's example. Otherwise, it is not needed, but may still fall into the realm of best practice.

The only hiccup to this logic would be if you are mapping to decimal values (which doesn't make much sense since the function will return a long type anyway), in which case the Arduino's internal typecasting will round-down your lowest value mapping. Example:

    map(0, 0, 1023, 8.9, 61.9));
    >> 0 becomes 8

    map(1023, 0, 1023, 8.9, 61.9));
    >> 1023 becomes 61

Again, for the sake of best practice and the potential time wasted trying to find a mapping bug, using constrain() is better than skipping it.


message:
How to upload program to board using Arduino sketch ver 1.6?

I am having problems uploading my program. I have been using the verify button aka the "checkmark" to upload my programs. I assumed that this was the correct button but now I am having problems uploading. When I attempt to use the "upload" button I get the error "can not open device". What am I doing wrong? How can I fix this error code?

body:
The checkmark button is used to compile your program (which "verifies" your code), but does not upload it to the board. The "arrow" button is used to compile and upload your program.

If you cannot connect to the device, make sure the correct COM port is selected on the Tools->Ports menu, and make sure you have the correct board selected on Tools->Board (usually an Arduino UNO).

If you have not installed the drivers yet, you will not have a port present for your Arduino. If that is the case, here is a great tutorial that will help you get everything installed and set up correctly: https://learn.adafruit.com/lesson-0-getting-started


message:
Programming ATmega2560 processor with FTDI instead of ATmega32

Has anyone tried to program an ATmega2560 with an FTDI chip as is done in the [Arduino Nano][1] (this is for a custom design).

Will it work?

  [1]: http://arduino.cc/en/uploads/Main/ArduinoNano30Schematic.pdf

body:
The Arduino Mega already has a built-in USB-UART bridge, so there's no need for a separate chip.

The ATmega1280 on the other hand is just a bare AVR MCU and does require either a separate USB-UART bridge for serial programming (provided it is programmed with an appropriate bootloader) or an ISP programmer for ISP programming.


body:
In fact, the basic Arduino Mega (with the ATmega 1280) **utilizes an FT232RL**, so yes, it will work if you connect it correctly.

It is only the newer Mega2560 (along with the similar-generation Uno, etc) which utilizes an ATmega16u2 or similar as the USB bridge.

Generally speaking, the bootloader doesn't care - you should be able to use either target chip with either USB bridge (or others).


message:
Program attiny13 with Arduino uno 1.6

I am looking for the boards.txt, platform.txt and core files needed for the programming of the ATtiny13 with the Arduino Uno. Those I find on the internet probably only works with Arduino 1.0 and not with 1.6.

body: You can use the library for IDE 1.6 https://github.com/damellis/attiny/


message:
Connecting light and temperature sensors and LEDs to an Arduino

Fairly new to arduino, what is the best and simplest way to connect an LM35 temperature sensor, a GL5528 photoresistor and some LEDs as well as the required resistors to an arduino for recording values? Any tutorials with wiring diagrams for something similar would be helpful.

body:
The LM35 is a very common temperature sensor. It has 3 pins - Vs, Vout, and Gnd. Connect Vs to the Arduino's Vs pin. Connect the Gnd pin to one of the Arduino's GND pins. The Vout pin should be connected to an Analog input pin. If you google your board, you should find the pinout on Arduino's website. The LM35 pin diagram and information on how to calculate the temperature from voltage is found in the [LM35's Datasheet.][2] [Here is LadyAda's Temerature Sensor tutorial][3] (note: the tutorial specifies the TMP36, however the two sensors are comparable). [Here is an instructable for the LM35][4] (includes diagrams and source code).

The GL5528 is a photoresistor. That means its resistance changes proportional to how much light strikes its sensor surface. Because of this trait, we can build a [Voltage Divider][5]. This will allow us to read in values (again, analog values). [AdaFruit's tutorial is very comprehensive][6] and includes diagrams.

LEDs are generally considered output displays (we program to use LEDs as a visual display of state). A good starting place for Arduino LEDs is the [Blink Example.][7] we connect an LED and resistor in series with an Arduino output pin and GND or 5v. This allows us to 'write' to the Arduino pin HIGH or LOW, turning the LED on or off.

I found these results by googling 'Arduino LM35', 'Arduino GL5528', and 'Arduino LED' respectively.

  [1]: http://arduino.cc/en/Tutorial/DigitalPins
  [2]: http://www.ti.com/lit/ds/symlink/lm35.pdf
  [3]: https://learn.adafruit.com/tmp36-temperature-sensor
  [4]: http://www.instructables.com/id/ARDUINO-TEMPERATURE-SENSOR-LM35/
  [5]: http://en.wikipedia.org/wiki/Voltage_divider
  [6]: https://learn.adafruit.com/photocells
  [7]: http://arduino.cc/en/Tutorial/Blink?from=Tutorial.BlinkingLED


message:
Difficult between atmega328 & atmega2560 when coding & compiling in a pure c

I have an arduino uno with atmega328p controller.

I found the code to deal with some specific uart protocol, named mdb: https://github.com/Bouni/MateDealer/tree/master/arduino

But it's compiled just for atmega2560 controller: https://github.com/Bouni/MateDealer/blob/master/arduino/makefile#L42

If I replace it by `atmega328p` or `atmega328`, I get the error:

    asiniy@misha:~/projects/MateDealer/arduino$ make all

    -------- begin --------
    avr-gcc (GCC) 4.8.2
    Copyright (C) 2013 Free Software Foundation, Inc.
    This is free software; see the source for copying conditions.  There is NO
    warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

    Compiling: main.c
    avr-gcc -c -mmcu=atmega328 -I. -gdwarf-2   -Os -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes -Wa,-adhlns=main.lst  -std=gnu99 -DF_OSC=16000000 -MD -MP -MF .dep/main.o.d main.c -o main.o

    Compiling: usart.c
    avr-gcc -c -mmcu=atmega328 -I. -gdwarf-2   -Os -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes -Wa,-adhlns=usart.lst  -std=gnu99 -DF_OSC=16000000 -MD -MP -MF .dep/usart.o.d usart.c -o usart.o
    usart.c:25:40: error: ‘UBRR1H’ undeclared here (not in a function)
         { { { {}, 0, 0 }, { {}, 0, 0 } }, &UBRR1H, &UBRR1L, &UCSR1B, &UCSR1C },
                                            ^
    usart.c:25:49: error: ‘UBRR1L’ undeclared here (not in a function)
         { { { {}, 0, 0 }, { {}, 0, 0 } }, &UBRR1H, &UBRR1L, &UCSR1B, &UCSR1C },
                                                     ^
    usart.c:25:58: error: ‘UCSR1B’ undeclared here (not in a function)
         { { { {}, 0, 0 }, { {}, 0, 0 } }, &UBRR1H, &UBRR1L, &UCSR1B, &UCSR1C },
                                                              ^
    usart.c:25:67: error: ‘UCSR1C’ undeclared here (not in a function)
         { { { {}, 0, 0 }, { {}, 0, 0 } }, &UBRR1H, &UBRR1L, &UCSR1B, &UCSR1C },
                                                                       ^
    In file included from usart.c:14:0:
    usart.c: In function ‘USART0_RX_vect’:
    usart.c:185:5: warning: ‘USART0_RX_vect’ appears to be a misspelled signal handler [enabled by default]
     ISR(USART0_RX_vect){
         ^
    usart.c: In function ‘USART1_RX_vect’:
    usart.c:197:5: warning: ‘USART1_RX_vect’ appears to be a misspelled signal handler [enabled by default]
     ISR(USART1_RX_vect){
         ^
    usart.c:203:12: error: ‘UDR1’ undeclared (first use in this function)
         data = UDR1;
                ^
    usart.c:203:12: note: each undeclared identifier is reported only once for each function it appears in
    In file included from usart.c:14:0:
    usart.c: In function ‘USART0_UDRE_vect’:
    usart.c:233:5: warning: ‘USART0_UDRE_vect’ appears to be a misspelled signal handler [enabled by default]
     ISR(USART0_UDRE_vect){
         ^
    usart.c: In function ‘USART1_UDRE_vect’:
    usart.c:253:5: warning: ‘USART1_UDRE_vect’ appears to be a misspelled signal handler [enabled by default]
     ISR(USART1_UDRE_vect){
         ^
    usart.c:261:31: error: ‘TXB81’ undeclared (first use in this function)
                     UCSR1B |= (1<<TXB81);
                                   ^
    usart.c:266:9: error: ‘UDR1’ undeclared (first use in this function)
             UDR1 = data;
             ^
    usart.c:269:20: error: ‘UDRIE1’ undeclared (first use in this function)
         UCSR1B &= ~(1<<UDRIE1);
                        ^
    make: *** [usart.o] Error 1

I've tried to play with compilers (default is gnu99) and so on, but with no success. Why I have this trouble? How can I compile this code for upload it to arduino?

body: The '328 only has a single USART. You will need to remove all references to USARTs beyond the first as well as the numeric suffix from the USART register names in order to get it to compile.


body:
I'm the author of the MateDealer project and I never had the intention to port it to other boards than the Arduino Mega2560!

Ignacio Vazquez-Abrams is absolutely right, the Arduino Mega2560 is the only board with more than 1 serial port (Yes there is the Due and the Leonardo, but those would require major changes to the code).

The fastest way to get the code running is by using a Mega2560, but be warned, the code might be bugy as hell ;-)


message:
Can I have help interperting this code? char variable somehow storing big numbers

I have this GSM module I got for my arduino project and I am trying to access the call feature, but the function makes no sense.

      boolean Adafruit_FONA::callPhone(char *number) {
      char sendbuff[35] = "ATD";
      strncpy(sendbuff+3, number, min(30, strlen(number)));
      uint8_t x = strlen(sendbuff);
      sendbuff[x] = ';';
      sendbuff[x+1] = 0;
      //Serial.println(sendbuff);

      return sendCheckReply(sendbuff, "OK");
      }
This is the function however how is char being used to display a phone number in the parameter?

body: It's passed as a `char*`. This can be derived from either a string literal (e.g. `"212555121"`) or from a `String` via its `c_str()` method.


body:
Keeping it simple:

`char *number;` a variable pointing to a character (or string of them).
`char sendbuff[35];` 35 characters in a row, making a string.
The first 3 chars at locatiion sendbuff are initialised to "A", "T", & "D", then the string at "number" is copied to it (to a maximum of 30 characters, by taking the lesser of the length of "number" or 30. This is important to avoid over-running the space allocated.
This string of characters gets sent out; & a check is made for an "O" & a "K"

If you don't 'get' pointers, you need to look it up, as it's pretty central stuff.


message:
Emulating 1-wire device(s)

What I want to do is make a ATTiny IC become a slave on the 1-wire bus, with its own S/N and command list for its specific functions.

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

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

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

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

  [1]: http://playground.arduino.cc/Learning/OneWire

body:
As far as I know, the 1-wire library you linked in your question allows only to act as a master, not a slave.

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

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

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


message:
What happens if an interrupt is triggered while sending data via serial?

I would like to use an inertial sensor to measure acceleration and send the results to an Android app using a serial communication with a **bluetooth Mate Gold** module. The sensor provides a data ready interrupt which notifies **Arduino-Mega** that a new value is stored in a register of the module. The output data rate can be modified during the configuration of the sensor.
I want the information to be sent at a 10 Hz rate to the bluetooth module.

Is an interrupt at 400Hz capable of compromising the integrity of a 50 bytes long message sent at 10 Hz with a baudrate of 9600?
If yes, which approach would you recommend to correctly send the data?

**Edit**:
I'm using the following formula to compute the amount of time required to send N chars.

    bytes x bits_per_character / bits_per_second
    N x (8+2) / 9600 = N/960 secs

For N = 52:

    52/960 = 0.054 secs = 54 ms

So theoretically, I can send a 54 char-long message at 18Hz with a baudrate of 9600.

**Edit2**
I can use the hardware serial or the Software Serial interface.

body:
What you are looking for is a way to safely interleave transmitting characters while at same time responding to the interrupts.  You can wrap the sending of bytes with

    noInterrupts();
    swSerial.write("somethinglongyaddayadda"); // takes 50-60 ms
    interrupts();

That will protect the write() operation from being interrupted and ruined by you sensor interrupt handler.  But as you note, that will block the ability to process the the sensor every 2.5 ms.  During the noInterrupts() period you would miss readings.

To achieve the interleave of both operations, you should transmit the message one character at a time.  Implement a transmit queue to hold the outbound string.  When it has characters, send them 1 at a time, wrapping each interrupt protection:

    ...inside loop...
    if(txQueue is not empty) {
      // do not need noInterrupts() or cli() as these are inside write();
      swSerial.write(one character from Q); // takes ~1 ms
      txPointerHead += 1;
    }
    // at this point the interrupts are enabled
    // and the sensor will be processed if available
    // if the interrupt occurred in the middle of the above,
    // the level is still set and the interrupt handler will be invoked

The 1 ms is ideal and not accounting for overhead, but it is unlikely the 1 character write time could stretch out to 2.5 ms.  As long as the write time stays under 2.5 ms, you will never drop a sensor reading.

Note that this interleave means that the characters will have larger inter-character delay.  The serial ports will not care about that.  But if the processing of the sensor data takes too much time, you will not be able to keep up with your 10 messages per second goal.

Some options I see to improve:

1. Use a higher baud rate.  The baudrate of the serial port is not related to the bluetooth data rate, so you might as well use the 115.2k.  That will reduce the blocking time.  The baud rate doesn't even need to be the same on both ends.  The BT module isn't a simple modem; it is packetizing characters wrapping them in encryption and transmitting.  The receiver unbundles the packets and pushes out its serial port at the receivers baud rate.

2. Use hardware serial.  Using a hardware serial port greatly reduces the time because all write() does is put one character into a register.  The time for that is microsecond domain.  After the byte is put in the transmit register, the UART handles the clocking of the bits so the microcontroller is free to do other tasks.


body:
If you are on the ardruino platform, and are using the hardware serial port, you basically don't have to do anything.

The `Serial` library interface already uses a outgoing data-buffer (it's varies between versions, 1.5.5 has it set to 64 bytes. The arduino people keep changing it's size for no reason), where the call to `Serial.print()` or `Serial.write()` only places the bytes in question into the outgoing buffer, and the buffer is then emptied asynchronously in the background by the TX-ready (`UDRE`) interrupt (which is then disabled when the buffer is emptied).

Basically, all you have to do is ensure that you're not placing data into the transmit buffer from both an interrupt and the main `loop()`, because it's then possible for the message from the interrupt to be inserted into the middle of the message from the main loop thread.

This can be easily enough done by either guarding the call to `Serial.print()` with `cli()` `sei()` [interrupt guards][1] in the main `loop()` section (or the useless arduino analog: `noInterrupts()` and `interrupts()`, which are just named proxies for `cli()` `sei()`, which exists for no good reason), or simply not printing from an interrupt (which is a good idea anyways, string formatting can be slow).

  [1]: http://www.nongnu.org/avr-libc/user-manual/group__avr__interrupts.html


body:
You want to send a 50 byte (or 52 byte?) sequence every 100 ms (10 Hz).

For hardware serial, that will go into a buffer which is emptied via serial interrupts; it should be emptied well before the next 100 ms tic (as you have calculated).

You will get about 40 sensor interrupts during that 100 ms.  With hardware serial, that need not be a problem - **so long as you don't send bytes from within a sensor interrupt**.  If your sensor interrupt just accumulates results and the main loop (non-interrupt) uses those results to periodically send the 50 byte message, you should be good.

Suppose you were averaging each of the sensor readings.  In the sensor interrupt you might add 1 to the count and add the reading to a sum value.  In the main loop, test if it has it has been 100 msec since the last send, and if so turn off interrupts, divide the sum by the count and store that average in a new variable, zero the sum and count, turn on interrupts.  Then use the computed average to format and send the 50 byte package.

That's just an example.  The main thing is to make the sensor interrupt quick and simple; and to format and send the packet in the main loop (inhibiting interrupts temporarily while fetching and clearing the variables which get updated during the sensor interrupt).

Be sure to use "volatile" for the variables used by both the sensor interrupt and the main loop.

The serial should take care of itself if you use hardware serial, and might even be OK for software serial.  In the latter case, a sensor interrupt in the middle of sending the bits of a single character/byte would mess up the bit timing, but software serial should inhibit interrupts during that time - so your sensor interrupt might be delayed up to a millisecond.


message:
Serial Error Correction

I currently have a setup where I take serial output from Arduino 1 and push it through a transmitter to the receiver of Arduino 2 where it is fed back into the serial input and further processed. I want to ensure that there is as little error as possible and recover the data wherever possible.

I have come across the syndrome decoding technique which seems to be the ideal one for me, but I am confused as to how I would go about implementing it.

I know that the Arduino Serial transfers data byte by byte, each being 8 bits, but do not know how this data is sent over the serial connection (i.e. how the start & stop bits & parity is implemented).

I would assume that a solution to this could either involve modifying the data in the buffer or reading it from the buffer and then operating upon it. I could also use adjacent bytes of data for error correction, but this seems wasteful.

How should I proceed with this?

body:
In my case i used a buffer and a delimiter. Specificaly: The reading is placed on the byte array untill the delimiter is reached.

## For example

From the arduino IDE serial monitor im sending this: `CAT;`

Each letter will be placed inside the byte array and this will stop when the `;` sign is entered. This migh be usefull because you can send the bytes whenever you can and they will remain in the array.

    void loop(){
    if(Serial.available() > 0) {

     char rec = Serial.read();

     if(rec == '.'){
        Serial.print("Here: ");
        for(int i = 0; i < sizeof(attitude); i++){
           Serial.print(attitude[i]); //print
           attitude[i] = (char)0;
        }
        attitudePointer = 0;
        Serial.println();

     }else{
       if(attitudePointer <= sizeof(attitude)){
          attitude[attitudePointer] = rec;
          attitudePointer++;
        }
      }

     }
    }


body:
Welcome to the wide world of Communications.  You are asking about ["Error Detection and Correction"](https://en.wikipedia.org/wiki/Error_detection_and_correction).  This is different from "framing", which allows you to determine when a message starts and ends.

With "error detection", you know there was an error, but you can't necessarily recover from it.  With "correction", you know there was an error and you *can* determine what was originally sent.

This *always* requires extra bytes.  There are many schemes, but the [Fletcher checksum](https://en.wikipedia.org/wiki/Fletcher's_checksum) for Error Detection is easy to implement, fast, and only requires 2 extra bytes in the message (4 if hex digits).

The generic approach is to use a [finite-state machine](https://en.wikipedia.org/wiki/Finite-state_machine).  In complicated message protocols, there would be nested state machines: the inner-most would probably determine framing, the next one out might looks at addressing, etc.  Any or all of those layers could use Error Detection and/or Correction.

For your simple "protocol", a single state machine is probably sufficient.  The states might be IDLE, RX_PAYLOAD and RX_CS.  As characters are received, they are processed according to the current state and occasionally change the state variable.

    while (Serial.available()) {
      uint8_t c = Serial.read();
      switch (state) {
        case IDLE:
          if (c == MSG_START)
            state = RX_PAYLOAD;
          break;
        case RX_PAYLOAD:
          if (c == MSG_END) {
            state = RX_CS;
            cs = 0;
            csCount = 0;
          } else if (length < MAX_LENGTH-1) {
            msg[ length++ ] = c;
          }
          break;
        case RX_CS:
          //  Add in the next hex CS digit
          cs = cs * 16 + fromHex(c);
          if (++csCount == 2) {
            // both digits received, see if the CS matches
            if (cs == csOfMsg( msg, length )) {
              // Handle the message
              msg[ length ] = '\0';
              Serial.println( msg );
            } else {
              Serial.println( F("Bad message!") );
            }
            state = IDLE;
          }
          break;
      } // end switch
    } // end while

There are entire books written on protocols and their design.  This is just a made-up example to give you an idea of how it should be structured: a finite state machine, driven by received character "events".

Sometimes you can compute the checksum as the characters are received, like Fletcher.  Here, it waits until the entire message plus 2 CS bytes are received.


message:
I²C between ATTiny85 (8MHz) and Arduino Uno

I keep receiving the following error in myATTiny85-Slave code below:

> sketch_mar12a.ino: In function 'void setup()':
>
> sketch_mar12a:19: error: 'class USI_TWI_S' has no member named 'onRequest'

I have downloaded **[TinyWireS][1]** and *TinyWireS.h* clearly has a public function **onRequest**. I opened the .ZIP file (downloaded from https://github.com/rambo/TinyWire) and drag-dropped TinyWireS folder into the Arduino libraries folder. This is how I install ALL libraries.

**I am using Arduino 1.0.6**

What am I doing wrong?

ATTiny85-Slave Code:
--------------

    #include "TinyWireS.h"                  // wrapper class for I2C slave routines
    #define I2C_SLAVE_ADDR  0x26            // i2c slave address (38)

    byte t=10;

    void setup()
    {
       TinyWireS.begin(I2C_SLAVE_ADDR);      // init I2C Slave mode
       TinyWireS.onRequest(requestEvent);
    }

    void loop()
    {
    }

    void requestEvent()
    {
       TinyWireS.send(t);
    }

Arduino Uno-Master Code:
------------------------

     #include <Wire.h>
     #define I2C_SLAVE_ADDR  0x26            // i2c slave address (38)

     void setup()
     {
         Wire.begin();
         Serial.begin(9600);
     }

     void loop()
     {
          byte num;

         // read 1 byte, from address 0x26
         Wire.requestFrom(I2C_SLAVE_ADDR, 1);

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

         Serial.print("num = ");
         Serial.println(num,DEC);
     }

  [1]: https://github.com/rambo/TinyWire/tree/master/TinyWireS

body:
I was able to compile your code "ATTiny85-Slave Code" without problems.

You can try to extract the contents of the ZIP archive (i.e. the library) directly to the directory where your sketch is stored. `#include "TinyWireS.h"` should then pick up that version.

You should also switch on verbose output for the compilation to have a look at the directory in which the code is compiled. Here you would find (at least in my older Arduino IDE version) copies of the included files. (`/tmp/build...` on Linux systems.) You can then make sure the proper version of the files is used.

You can also search your drives for other copies of `TinyWireS.h`.


message:
Connecting PC speaker to Arduino

I've looted this speaker from my old PC and trying to understand how to connect it to Arduino to produce simple sound notification (and not fry anything in the process).

As far as I understand this is a piezo speaker, there is no markings on it. Here is how it looks:

![speaker front][1]
![speaker back][2]

How do I connect\control it?

Should I connect it to PWM pin? If so, what are the safe values to output on PWM pin?

Should I use resistor when connecting speaker? What resistor should I use?

 [1]: https://i.stack.imgur.com/WCLKq.jpg
  [2]: https://i.stack.imgur.com/BfWNK.jpg

body: No need for a resistor. Just connect black to ground, and red to a IO pin. Use the [tone](http://arduino.cc/en/reference/tone) function to specify a frequency.


message:
Stop servo when enter 0

I am trying to stop servo motor from rotating when I enter 0 in serial. The code is below. Can someone please help?

<!-- language: lang-cpp -->

    #include <Servo.h>

    Servo myservo;  // create servo object to control a servo
    // twelve servo objects can be created on most boards
    int state;
    int pos = 0;    // variable to store the servo position

    void setup()
    {
      myservo.attach(9);  // attaches the servo on pin 9 to the servo object
      Serial.begin (9600);
    }

    void loop()
    {
      if (Serial.available () > 0)
      {
        state = Serial.read ();
        if (state == '1')
        {
          for (pos = 0; pos <= 180; pos += 1)
          {
            myservo.write(pos);              // tell servo to go to position in variable 'pos'
            delay(15);
          }
          for (pos = 180; pos >= 0; pos -= 1)
          {
            myservo.write(pos);              // tell servo to go to position in variable 'pos'
            delay(15);      // waits 15ms for the servo to reach the position
          }
          if (Serial.available () > 0)
          {
            state = Serial.read ();
            if (state == '0')
            {
              myservo.write ('90');
              delay (300);
            }
          }
        }
      }
    }

body:
From the code you posted it looks like you have the right idea but you've nested the 'IF' statements causing the check for '0' to only happen if you send two bytes and it will only go to 90deg when you send '10'.  The loop section should look more like:

    if(Serial.available()){
        state = Serial.read();
        if(state == '1'){
               Make motor move;
        }else if(state == '0'){
               Make motor stop;
        }//end of elseif
    }//end of if


message:
What info should I look for when choosing a solid state relay for arduino?

I want to control a phone using an arduino board by connecting each pin of the arduino to a button on the phone using relays to simulate a button being pressed or release by switching a relay (on/off). I am using relays because from what I have seen ([Use Arduino to Switch Power On and Off! ][1]) relays are controlled swiches and I am using SSR because I want to use the less space possible.

I'm trying to buy a relay at [mouser.com][2] but I don't know what are the values I should look for, for those parameters (Control Voltage Range, Load Voltage Rating, Load Current Rating, Input Current).

  [1]: https://www.youtube.com/watch?v=tuOrH9sSykk
  [2]: http://www2.mouser.com/Electromechanical/Relays/Solid-State-Relays/Solid-State-Relays-PCB-Mount/_/N-ay0uc/

body:
If you're only controlling a button, the load current and load voltage are pretty much irrelevant since I'd be surprised if you even used 5% of it's rating in either category. I can't tell you how much you'll need here since I don't know the voltage that the relay will be operated on and the resistance of the path for the load.

What you do need to look at is the voltage and current of the input/control/logic signal. It should allow a 5V control voltage and the current draw for that logic signal should be no more than 40mA, although it's ideal to stick to a lower number (say, 30mA).

However, manually picking out a relay manually isn't ideal for a beginner since it requires a bit of extra components to properly run. A [relay module **(Amazon)**][1] allows you just hook up your wires to the jumpers and terminals of the relay module without any extra soldering (as far as I know they aren't breadboard compatible, thus requiring a custom PCB or having it "flop") or parts.

  [1]: http://www.amazon.com/Docooler®-Active-Channel-Module-Arduino/dp/B00G9TQH8U/ref=sr_1_4?ie=UTF8&qid=1426281552&sr=8-4&keywords=relay 1 channel


body:
I would tread carefully. A solid-state relay may or may not be suitable for the relatively low-level signals present across the phone buttons. Check the datasheet, buy just one, and try it out.

But do you need to control a physical phone? An Arduino can connect to a standard modem which has inbuilt commands to dial numbers and generally supervise a phone line.


body:
An SSR is not a good choice for your application.  The common use of an SSR is for switching on and off an **AC** load.  If the data sheet mentions SCR or Triac, then it is meant for only switching AC and will not function for controlling DC.  So keep this in mind when looking for components: if it says "24-220 VAC" on the data sheet that does not mean it will work for DC.

A second common use of SSR and microcontrollers is the opto-coupled input type.  That input method provides a safe scheme for a low voltage low current control signal to switch a large load.

For a button on a phone, you are switching a near zero current DC load.  You should be able to control that with a transistor, but that would require some reverse engineering of how the phone keypads where being scanned.  You would need to trace out what the voltage was, how much voltage drop could be accommodated.

A certain easy method is to use a small reed relay.  Parts are available that have a coil that only draws ~10 mA so can be driven directly from an output pin.  The relays are packaged in a DIP so easy to prototype on a breadboard.  Many list the coil resistance and voltage for specs, for example a 5V and 500 ohm resistance coil would draw 10 mA.  You will find many for 1 - 2 $US.

When working with a relay, you need to take care of the back EMF (aka flyback voltage) that occurs when you turn off.  That is handled with a single diode which you will see in every schematic for driving a relay.  For a beginner, an alternate/sure success route is to use a driver chip such as a ULN2003 that will drive inductive loads such as small relays.