text:
How to tap my thermostat's serial line
This is a home heating system hack.
I want to add an arduino in-line between my thermostat and air handler; and possibly between the air handler and outdoor compressor. The long-term goal is to post long-term statistics to an RRD web page (run time, power consumption, temp, etc.) and control the blower (without the heat) automatically when we are burning our wood stove.
The product is a Nordyne IQDrive (notable in that the equipment comes with 5 separate brand logos to adhere to the equipment: Tappan, Frigidaire, Westinghouse, Nutone, and Broan).
At this stage, all I want to attempt to do is to tap the serial links and record the conversations. I would prefer not to shoot myself in the foot.
The "System Field Wiring Instructions" describe both links as "serial." The wiring diagrams label the connection points as:
air handler interface board --> [description] --> thermostat
      G --> GND --> C
      - --> DX- --> B-
      + --> DX+ --> A+
      R --> R   --> R

Googl'ing these might indicate that this is an RS485 (never heard of it).
How do I tap and record the communication?

It does indeed look like RS485. Maybe this is helpful: http://owlsan.blogspot.nl/2012/09/connecting-urm04-v20-ultrasonic-sensor.html

Although this chip doesn't look designed for packet sniffing, this Sparkfun product looks like it may be helpful...

You don't need anything special for sniffing - just don't wire a driver to the bus, or if it is internally wired in parallel with the receiver, tie its enable signal disabled.

@ChrisStratton I apologize... I'm too n00b'ish to understand (I even asked a friend). Can you please expand on your response a bit?

I does sound like RS-485.
You can get cheap RS-485 transceivers from the usual sources.  These take the 0..5v TX line and convert it to RS-485 voltages, or RS-485 voltages and convert to the 0..5v RX expected by your Arduino.  You would normally enable only one direction at a time - sending RS-485 from the Arduino TX or receiving RS-485 to the Arduino.
In your case, you just want to receive, so keep the transmit side (TX to RS-485) disabled, while enabling the receive side (RS-485 to RX).
RS-485 is just an electrical standard, and they could be sending any pattern of on and off signals they want, but often they will be sending asynchronous data with one start bit, 7-8 data bits, and one stop bit per character - which the Arduino's Serial port can handle.  So it's worth testing to see if that works.
The next thing you need to know is the clock rate, or "baud rate", which is how many bits per second (including start and stop bits) it is sending.  Often you can figure this out by trying some standard rates like 1200,2400,4800,9600,19200,38400,57600,115200 (there are others) and printing the results to your screen - when you are at the wrong rate you will get nothing, or some odd garbage.  When you get the right rate, it will look more reasonable.
If no speed works, you may need to reverse A and B.
You might temporarily hook up an LED and a resistor (say 2.2K or higher) between the RX from the RS-485 and your 5v power.  This will give you an idea of when there are transmissions from or to the thermostat.  If it only transmits once a minute, say, you might have to wait a while for each speed test.  Or changing the set temperature may trigger a send.
You may be able to test the lower speeds at least using Software Serial, and then echo the received data to the hardware serial port which goes to the Serial Terminal in the Arduino IDE.
From there, you may need to figure out the protocol - the structure of the data.  Protocols vary widely.  It may be text or it may be binary; if it's binary you may want to have the arduino convert each character (values 0..255) into hexadecimal (00..FF) for printing.
Most protocols for this kind of control send data in a burst, or packet.  You will likely be able to detect the start and end by the timing (ie: a long pause between the end and the start of the next).  Of course, some protocols might send several packets continuously, but still the first character (or binary value) after a long pause will often be the packet header.
Remember that there may be packets from the themostat, and packets to the thermostat, and you will see both without knowing which is which (so long as you are just passively tapping the line).
I hope this is enough of a pointer to get you started.  Decoding protocols is a more extended subject.

I read the WikiPedia article on RS485 (http://en.wikipedia.org/wiki/RS-485). The more I learn about RS485, the more likely it seems this is the right track. RS485 is typically wired in a bus with as many as 32 nodes. It's noise tolerant and more than fast enough for a heating/cooling system. At slower data speeds, it can run as far as 4000 feet.
The next step appears to be trying to record some traffic. I found this question on the EE Stack Exchange about tapping RS485: https://electronics.stackexchange.com/questions/30511/hijack-observe-rs485-communication-data-by-wire-tapping
A USB widget appears to be affordable. Inserting the widget between the two ends (I'll try and test to see whether the ends both have termination resisters) should be some easy wiring.


text:
Arduino Yun's sample "Bridge" code not working
I'm new to the Arduino world (or the electronics world for that matter).
I have the Arduino Yun and the WifiStatus code works fine (so does the HttpClient).
But every time I try to run the bridge sample code, all I see is the pin 13 led light up, and the browser commands don't work.
PS: I have updated the open-wrt to ver. 1.3.
Any thoughts on why this would be happening?
Edit 1:
I have tried to reboot arduino using the hardware switches as well as from the web console. The blink sketch works fine, so does the WifiStatus code and the HttpClient code.
The other problem I face after every few uploads is that the IDE is stuck at "Uploading...". I have tried to give it more time (even an hour). But then I had to unplug it from the Mac and restarted. Then it worked but only for a few times.
But this problem is not specific to the Bridge code. The uploading issue has occurred with other sample code as well. But at least the code worked.
Edit 2:
This is the result from the command ls /dev/tty.*
/dev/tty.Bluetooth-Incoming-Port    /dev/tty.usbmodem1431
/dev/tty.Bluetooth-Modem

Welcome to Arduino SE! Can you please edit your questions with more details? Do you have anything connected? Can you add more information about what you've tried, etc? As far as we know, the official code should work. It's really hard to diagnose this without any other information. Does the "blink" sketch work? Does uploading fail? Thanks!

when the problem occurs can you open the terminal and post the result of ls /dev/tty.*

This is the result from the command
" /dev/tty.Bluetooth-Incoming-Port /dev/tty.usbmodem1431
/dev/tty.Bluetooth-Modem "

I ended up doing two things. First I got a replacement hardware. That made the bridge code start working.
And I also changed the port from /dev/tty.usbmodem1431 to /dev/cu.usbmodem1431. As shown in the picture below. That fixed the issue with IDE getting stuck at "Uploading...".
Not sure if this fix will last.

source: Stack Exchange

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

sort: votes


text:
Is it possible to program an Attiny85 with a USB-to-TTL converter?
I currently use my Arduino to program Attiny85. As I have one of these USB-to-TTL adapters I am wondering if it is possible to program Attiny85 with it, to free up my Arduino. I know it is possible to program Atmega's with such a thing.
If it is in fact possible to use the converter as a simple programmer for Attiny's, how should I connect the converter to the Attiny?

Without addressing complications and tricks for that particular interface, ATtiny's and ATmega's have basically the same sort of ISP programming scheme, just needing different details and data.  If you are talking about serial download to a bootloader, that is possible as well, though an ATtiny85 bootloader has to do something comparable to software serial as the chip lacks a hardware UART.

Yes, it is possible.
Note that the FTDI chip (assuming that is what you have) can be accessed as either Virtual Com Port VCP or D2XX. Where VCP is the traditional method of using them as Serial Ports with avrdude calling "-c arduino -P COM3 -b115200". However the later D2XX method allows for the pins to be Bit Bang'ed.
One can see in this tutorial it is possible to call avrdude with a programmer of "-c ftdi". Assuming that the D2XX drivers are installed.
Where I see in the current releases 1.0.5r2 and 1.5.7's avrdude's config files that a programmer of type "avrftdi" is supported, as opposed to the article "ftdi"
However, that is not to say the IDE natively supports its. You will have to either call avdude manually. Or add the "avrftdi" to "\arduino-1.5.7\hardware\arduino\avr\programmers.txt" so that the IDE will be aware of it.

That all said I see "Tiny AVR Programmer" that are very in-expensive.

Your are right, they are very cheap. I had no idea! I just ordered one at about USD 5 incl. shipping :-)

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


text:
Computer not detecting my Arduino MEGA 2560 R3
I've tried different USB cables, computers, ports and none of them can detect my possibly bricked Mega 2560 R3. Nothing shows up at all in the Device Manager, not even "Unknown Device".
When the board is plugged in via USB, the "L" LED is constantly lit as well as the "ON" LED next the reset button.
I came up on this article here and I gave it a try, which I believe is putting it in DFU mode. However I'm not having any luck with this. http://www.wayneandlayne.com/blog/2011/02/16/fixing-linux-firmware-issues-on-arduino-mega-2560/
Any one have any ideas on where to go from here? I'm very new with Arduino.

Have you tried a different computer and cord? When did it stop working (and what did you do differently)?

I recently purchased a clone Mega 2560, and could not get the USB port to work. Check the USB chip marking. If its a CH340G, it is not compatible with the Arduino drivers for PC USB ports. You need to find a file called ch341ser.zip, and install this on the PC, not the Arduino.

I have the same issue with an Arduino Mega ADK (same as Mega 2560 but with additional USB Host port) and only get gibberish as serial output

If your Mega has an ICSP header for the USB chip (circled below) then you can test that chip.

You can use another Arduino (eg. a Uno) to detect the signature on that chip, as per my sketch on Sketch to detect Atmega chip types.
All you need is 6 hookup wires to connect your testing board (the known good one with the sketch on it) to the ICSP header on the Mega. Note the pin orientation. I have circled the correct header pins, and pointed to pin 1. On the board pin 1, has a small white dot.
Below are the ICSP pin names, seen from above (component side).

Wire the Uno to the chip being tested as follows:
Arduino Uno      Target chip

D10 (SS)            /RESET
D11 (MOSI)          MOSI
D12 (MISO)          MISO
D13 (SCK)           SCK

Gnd                 GND
+5V                 VCC

Check your wiring! If you wire things around the wrong way you can turn a good chip into a bad one.

Important! Only attempt this process if you can see that you have an ATmega8U2 or ATmega16U2 chip on your board (see below). If you have something totally different this will not work. In that case you probably have a cheap clone board.

Using the Serial Monitor on your Uno, you should then see something like this:
Atmega chip detector.
Written by Nick Gammon.
Version 1.17
Compiled on Jul  7 2015 at 10:47:47 with Arduino IDE 106.
Attempting to enter ICSP programming mode ...
Entered programming mode OK.
Signature = 0x1E 0x93 0x89
Processor = ATmega8U2
Flash memory size = 8192 bytes.
LFuse = 0xEF
HFuse = 0xD9
EFuse = 0xF4
Lock byte = 0xFF
Clock calibration = 0xAB
Bootloader in use: No
EEPROM preserved through erase: No
Watchdog timer always on: No
Bootloader is 4096 bytes starting at 1000

Bootloader:

1000: 0x4B 0xC0 0x00 0x00 0x64 0xC0 0x00 0x00 0x62 0xC0 0x00 0x00 0x60 0xC0 0x00 0x00
1010: 0x5E 0xC0 0x00 0x00 0x5C 0xC0 0x00 0x00 0x5A 0xC0 0x00 0x00 0x58 0xC0 0x00 0x00
1020: 0x56 0xC0 0x00 0x00 0x54 0xC0 0x00 0x00 0x52 0xC0 0x00 0x00 0xCB 0xC4 0x00 0x00
1030: 0x4E 0xC0 0x00 0x00 0x4C 0xC0 0x00 0x00 0x4A 0xC0 0x00 0x00 0x48 0xC0 0x00 0x00
...

My board had a ATmega8U2 on it, yours might have a ATmega16U2. However the concept is the same. If you see something like that, the chip is (probably) good. At least it responds to programming commands.

If you see something like
Atmega chip detector.
Written by Nick Gammon.
Version 1.17
Compiled on Jul  7 2015 at 10:47:47 with Arduino IDE 106.
Attempting to enter ICSP programming mode ......................................................
Failed to enter programming mode. Double-check wiring!
Programming mode off.

Then either you made a wiring error, or the chip is bad.

I have had the same symptom with a Arduino Decimilia.
In that case had the USB to Serial chip failed. I used a USB to Serial device to verify the problem

It sounds like the USB to serial chip has failed. You could test this by using another arduino or a programmer like the AVRISP mkII to load a program that way and see if it's your whole board or just the serial chip.
If the board and main chip are still good, you could just get used to uploading with this new method, or you could try to reprogram the other chip used for serial. I know it I'd possible but ever time I've burned one this hadn't help so YMMV.

Check the Chips for any solder mistake, I found that my serial chip had two pins soldered together, probably cause i bought it for cheap :D


text:
Wrong data from DS18B20 temperature sensor after long power off
I have my Arduino Uno connected to the PC via USB when prototyping.  I am developing a thermometer with memory, using DS18B20 sensors.
When PC is shut down, there is no power on the USB and the Arduino is off. Sometimes, when my PC is turned off for several hours and then, when I turn it on, the Arduino is started, but it behaves "strange" - the program is showing buggy values on the display, looking like if there is some bug in the sketch. However, when I upload the sketch again, it works fine.
The buggy values are the averages for the run, computed simply by summing a float and dividing by int. What I see is e.g. instead of seeing something around 23.5 I see 85.1. The current values read from the sensor look OK (show 23.5 as expected), but I cannot tell for sure if perhaps some value read early might be wrong.
It is not easy to reproduce, I see it only sometimes, always when powering Arduino on after several hours without power.
My first idea is either the sketch got corrupted during the long power down, or variables are initialized wrong, and the sample sum / sample count is not zero.
However I though the sketches are uploaded into the Flash RAM, which should be non-volatile according to the docs. Is there something obvious I am missing, some explanation why is the sketch working differently after long power down?

Are you storing any values to EEPROM? The problem sounds odd. The brown out detector on the AVR is supposed to ensure a clean power off, meaning no unpredictable behaviour.

@user2973 No EEPROM. Moreover, I did not see the problem recently. I will watch the behaviour and will post if I learn anything new.

It sounds like the problematic variables should be properly cleared during the setup(). And or the sensor is not correctly working for an initial power up period.

@mpflaga Do you mean static variables are not reset when Arduino is reboot? Well, that would explain a lot ... I was probably programming PCs for too long.

@mpflaga "Global and static variables are guaranteed to be initialized to 0 by the C standard. avr-gcc does this by placing the appropriate code into section .init4"

They should be, cleared. I would print them and then clear them after a number of delays. To determine where the corruption is coming from.

It is not entirely out of the question that during boot, the PC could write garbage data to the Arduino - for example, as the Arduino uses what is really supposed to be a modem interface, the operating system might be trying to initialize it as such.

Can you clarify your question - "Sometimes, when my PC is turned off for several hours and then I turn it off" - do you mean turned off and then the pc is turned on, or turned on and then the pc is turned off?

Maxim DS18b20 data sheet, rev 042208, page 4, in a footnote to Table 1, says: *The power-on reset value of the temperature register is +85°C. Maybe a premature attempt to read?

There should be no difference between turning on your computer and plugging in a USB cable. The embedded devices typically plugged into a USB ports such as mice, keyboards, wireless adapters, hard drives, etc don't have their FLASH memory corrupted when the computer is turned on so it is unlikely that your Arduino would.
To confirm there isn't something dodgy going on with the USB power supplied to the board, use a multimeter to monitor the 5V pin of the Arduino. If the voltage isn't going too high or too low then everything should be fine. Even if it goes too low, the microcontroller will have brown-out-detect enabled to shut it down in this event.
You mentioned a display. Perhaps, and this is pure speculation, some how the display is being initialised wrongly due to the Arduino being reset by USB connection. If the display has a general reset command, or a reset pin, enable it at the start of your sketch to ensure the display is in its default state.

The display is fine, it is displaying values with good format, only the values are wrong (min/max temperatures out of possible range). Those min/max are stored in SRAM only, therefore they were freshly calculated since the Arduino was powered. Multimeter shows clean 5.00 V, but I cannot rule out some short spike, I am not sure the multimeter would show that (the response of the one I have is not immediate).

Would you be able to post the code? Just in case there is something obvious. :P

The code seems too long to post here. If I will see it again, I will try to create an isolated example, if possible.

What is the temperature sensor in use? Is it a thermistor, or some chip with i2c/2wire or a dallas 1 wire? Maybe it requires some initialisation step and not being reset properly?

@danny It is "dallas 1 wire" (DS18B20 - packed as https://www.sparkfun.com/products/11050). I am using http://www.milesburton.com/Dallas_Temperature_Control_Library to control it.

I researched this once when I was getting consistent, exactly 85 degC readings from my sensors. The Maxim DS18b20 data sheet (rev 042208, page 4, in a footnote to Table 1) says:

"The power-on reset value of the temperature register is +85°C.

Double check that the Arduino code is follows the sensor communication protocol correctly.

You are correct. I am using DS library in async mode  - setWaitForConversion(false) - therefore the library is not handling the wait for conversion for me and I have to wait on my own.

Thanks for the the feedback, Suma. That's useful to know.

The number you are seeing instead - 85.1, is suspiciously close to a Farenheit reading instead of Celcius - my guess is that there maybe a setup step for the Dallas DB18B20 that you are issuing too early for it, before it has initialised, and so it is ignoring it.
My guess would be steps being a unit setting, and a calibration setting.
can you attempt to wait a little time (perhaps 100 millis) before initialising the temperature control library.

Interesting theory, however DB18B20 is not providing F or C reading, it provides a raw value which needs to be recalculated in the program. However I agree it might be somthing with the setup wrong.


text:
Reliably duplicate custom IR remote control with ATTiny85
This is something I'm struggling with for a while and fail to find solid solution.
The Arduino IR library provides method for recording arbitrary IR code and re-sending it. This gave me different results every time I recorded the IR remote, so I wrote a little code, based on interrupts, that try to record the IR rise/fall as accurately as possible.
I am working with ATTiny85 running at 8Mhz on internal oscillator.
Here is the code:
#include <SoftwareSerial.h>

SoftwareSerial mySerial(4,3);

const int dataSize = 40;
int data[dataSize];
int dataLength[dataSize];

void setup() {
  pinMode(0, OUTPUT); // 0 is IR receiver pin
  mySerial.begin(9600);
  mySerial.println("Start");
  attachInterrupt(0,IR_ISR,CHANGE);
  mySerial.println("Registered");
  sei();
}
volatile unsigned long prev = micros();
volatile unsigned long curr = -1;
volatile unsigned short index = 0;
volatile bool rising = true;
void IR_ISR()
{
  if (!rising)
  {
    dataLength[index] = micros() - curr;
    rising = !rising;
    return;
  }

  curr = micros();

  data[index++] = (int)curr-prev;

  prev = curr;
  rising = !rising;
}

void loop() {

  delay(5000);
  for (int i=1; i<dataSize; i++)
  {
    mySerial.print(data[i]);
    mySerial.print("(");
    mySerial.print(dataLength[i]);
    mySerial.print(")");
    mySerial.print("; ");
  }
  mySerial.println();
  index = 0;
}

Problem is that the milliseconds alter on each record of the remote control, here is an example of the output of 3 attempts of clicking at the same button of the remote control (I pasted only the first 5 IR modulations to avoid too much text, total is about 39):

Start
  Registered
14104(9496); 1184(672); 1184(616); 1160(656); 1176(672); ...
14096(9480); 1184(664); 1208(568); 1136(616); 1184(664); ...
14096(9384); 1216(576); 1136(616); 1184(664); 1208(560); ...

The format is: [microseconds from previous falling edge](microseconds from rise to fall);
As you can see, the results vary. According to the arduino.cc website, the micros() function has a 8 microseconds resolution on 8Mhz AVR's, but the difference between reads is bigger than that.
This is not reliable enough for me to solidly duplicate a remote control, and I'm looking for a resolution that will provide accurate results, as the magnitude of every deviation increases when the voltages are low (for example, with a 3v 2032 coin battery half discharged).

While the AVR is 8MHz, there is latency to service the ISR. Hence your observed differences.

This is true that ISR has some delay and does not provide real time values, but if what you say is correct, I should have measured the same deviation on every attempt, and this is not happening.

The exact duration of the pulses don't matter much. In your example, you see that in all three recorded samples that's
about 14000 (about 9400); about 1200 (about 600); about 1200 (about 600) etc.

What matters is that nowhere you have pulses of about 900 : in other words if the receiver detects a 672 pulse it will know that it's definitely a 600, not a 1200.
So if you send exactly those values, the receiver will recognize it.

That's an interesting observation; do you have a thumb rule about the rounding?

I use 412-712 for detect a zero, and 1187-2187 for detecting a one. 412-712 for the ir-burst between them. It looks like the remote is using the NEC protocol. I actually used excel to convert the raw data into a number, and to test if the boundaries were sufficient. I actually had to increase the boundaries a few times to catch the IR signal reliably. The values above are what I ended up with.

I used NEC remote for the post, but my intention is to reliably adjust to any custom protocol. Hence I am not sure that NEC values will suite me. Also, my final goal is to make the entire processing dynamically on the AVR itself, making it a real adjustable remote control, thus excel is not an option here :) I'll try to play with the rounding using code, see if that helps (if it will do the trick, I'll accept your answer).

Just sample n times the same code, and record the averages of pulse lengths. If you reemit that, you'll be sure you sent the same code. The way that code is interpreted by the receiver (NEC, rc-6, whatever) is irrelevant.

Eventually I decided not to use ATtiny85 since, even if using PROGMEM, it's just not up to the job of being a 'universal remote control', memory wise. But this is indeed the correct answer to my question.

I often see where people have problems with decoding IR signals from time to time, but very few say how they are attempting to do that? The first thing you really need to know is what is the carrier frequency? if you are using a TSOP IR DEMODULATOR, They come in several flavors and if you have the wrong one your results may not be all that rock solid.  There are one or two ways to determine this. have a digital storage scope and a fast photo diode (photo transistors are slow) which does no demodulation, just gives you raw IR . Once you determine your carrier frequency,  then purchase a IR demodulator TSOP that is closest to your carrier frequency, then your results will be more stable no doubt.

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


text:
'OUTPUT' was not declared in this scope - ATtiny85 with Arduino Uno r3 as ISP
I'm trying to follow this this tutorial to program an ATtiny85 micro-controller using my Arduino Uno r3 as the ISP.
I am up to the final step on the tutorial, but get an error when attempting to compile my sketch:
'OUTPUT' was not declared in this scope

I have tried multiple "Blink" scripts, but none have seemed to work.
My full error log:
Blink.ino:10:21: error: Arduino.h: No such file or directory
Blink.ino: In function 'void setup()':
Blink:15: error: 'OUTPUT' was not declared in this scope
Blink:15: error: 'pinMode' was not declared in this scope
Blink.ino: In function 'void loop()':
Blink:20: error: 'HIGH' was not declared in this scope
Blink:20: error: 'digitalWrite' was not declared in this scope
Blink:21: error: 'delay' was not declared in this scope
Blink:22: error: 'LOW' was not declared in this scope

I have also tried including Arduino.h, no help, and changing "OUTPUT" to "0x01", as it is defined to said value in Arduino.h, but instead got this error:
error: 'pinMode' was not declared in this scope

Any ideas as to what is happening?

If you change the board back to Arduino UNO does it compile? Could you turn on verbose mode for compilation and post the text that appears when you compile.

It looks like the Arduino core libraries aren't being included...

Are you using the latest version of the Arduino IDE? Seems similar to (this problem](http://forum.arduino.cc/index.php?topic=82220.0), but in reverse.

The first issue, the 'missing' .h file, creates the others. Fix the INCLUDE path and the other errors will go away.

Check this thread
http://arduino.stackexchange.com/questions/3642/output-was-not-declared-in-this-scope-attiny85-with-arduino-uno-r3-as-isp

The tutorial you are using refers to the Arduino IDE version 1.0, are you sure you are using the same IDE version?

Create an Arduino.h in ...\Arduino\hardware\attiny45_85\cores\attiny45_85 containing
#include <WProgram.h>

From here
https://electronics.stackexchange.com/questions/87328/arduino-as-isp-for-attiny

Try moving the "Cores" folder from the avi directory to the attiny director. The path was wrong for me and I was getting the same error. Had the same issue with the bootloader file. Moved it out of the avi folder as well and all worked ok then.


text:
My counting function is not working with the text on my lcd
I want the bottom row of my LCD to display the counting function and include text:
lcd.setCursor(0, 1);
lcd.print("Launch in"millis()/1000);

But it comes out with an error, what part is wrong?

The last line in the code you provided won't compile.
The lcd.print() function expects a char, byte, int, long or string (taken from the LiquidCrystal docs) and you're trying to combine a string and an int which the compiler isn't going to understand.
The easiest way to print both would be to have two lcd.print statements:
lcd.print("launch in ");
lcd.print(millis()/1000);

Most of this is taken from quickly googling displaying time on an lcd screen.
Check out this forum post, it seems similar to what you want to do: click me!

Change the last line to:
lcd.print("Launch in " + (millis() / 1000));

The + concatenates the string Launch in with the number that results from millis() / 1000.

lcd.setCursor(0, 1);
lcd.print("Launch in ");
lcd.print(millis()/1000);

Can you add why the original code didn't work? Answers are best if they have some explanation, not just code.


text:
There is any way to simulate an arduino due?
As the title says there is any program that can simulate an arduino due? I like the design of Proteus 8 but he can't simulate it. Only the arduino Uno R3, Mega and another one that I forgot the name.


text:
On my lcd my characters collide, how can i remove one(because of the programming)
My code means that when i press a button it displays a word, but by default words are already there and i need to get rid of those default words.
#include <LiquidCrystal.h>

// initialize the library with the numbers of the interface pins
LiquidCrystal lcd(7,8,9,10,11,12);

int buttonApin = 4;

void setup() {
 pinMode(buttonApin, INPUT_PULLUP);
  // set up the LCD's number of columns and rows:
  lcd.begin(16, 2);
  // Print a message to the LCD.
  lcd.print("Mission Control ");
}

void loop()
{
  if (digitalRead(buttonApin) == LOW)
  {
    lcd.setCursor(0, 1);
    lcd.print("Test");
  }

  lcd.setCursor(0, 1);

lcd.print("launch in ");
lcd.print(millis()/1000);

The HD44780 controller has a 80 bytes (characters) memory, in order to support up to 2x40 character displays. Since you use a 2x16 display, there is an empty space in the memory you can use on your benefit. It's like having two desktops, you are able to show one or the other.
Refer to LCD Addressing for a visualization of the the memory locations and detailed explanation.

Anything you write in locations setCursor(16, 0) to setCursor(39, 0) and setCursor(16, 1) to setCursor(39, 1) will not be visible until you scroll to the left. Consequently you can have some text already written in the hidden area and then alternate the shown text just by scrolling left and right.
Here is an example
#include <LiquidCrystal.h>

// initialize the library with the numbers of the interface pins
LiquidCrystal lcd(7,8,9,10,11,12);

int buttonApin = 4;

void setup() {
   // set up the LCD's number of columns and rows:
  lcd.begin(16, 2);
}

void loop()
{
  if (digitalRead(buttonApin) == LOW)
  {
    // write text to the visible area
    lcd.setCursor(0, 0);
    lcd.print("showing 0,0-15,0");
    lcd.setCursor(0, 1);
    lcd.print("showing 1,0-15,1");

    // write text to the hidden area
    lcd.setCursor(16, 0);
    lcd.print("now  16,0-31,0");
    lcd.setCursor(16, 1);
    lcd.print("now  16,1-31,1");

    while (1) {  // scroll to the left and back to show different text without writing a single character
    delay(2000);
    for(uint8_t i=0;i<16;i++) lcd.scrollDisplayLeft();
    delay(2000);
    for(uint8_t i=0;i<16;i++) lcd.scrollDisplayRight();
    }

  }

}

The code changes the visible text just by scrolling

Either clear the display first, or print enough spaces after to overwrite the existing text.

Yes that would work, but i would like the original (defualt) text to reappear after the button has been pressed.

@Stratmoss if it works, then why not do that? You're going to have to re-print the text to the LCD as it doesn't have any memory...

@AnnonomusPenguin Are you sure about the memory?

It has a tiny bit of memory, but unless you can handle page switching (one of many optimization techniques mostly lost to history) it won't help.

@Stratmoss I'd estimate another write would take less than a 100 bytes (you have 32,000 bytes). If you want to make sure, when you click "verify," it tells you how big it is at the bottom.

@AnnonomusPenguin that worked, thanks, and the memory wasnt a problem.


text:
USB device not recognised - windows 8.1
I'm a beginner with Arduino and i have acquired the Arduino UNO R3 board. i have followed the instructions on arduino website in order to install the board, however it fails and still remains as an unrecognised device.
consequently, arduino IDE reports that COM1 is not found, and the 'ports' menu is grayed out.
steps i have tried:
1) install the Arduino 1.0.5 IDE
- the installation failes near the end when installing the arduino board
2) install the Arduino 1.5.7 BETA IDE
- the installation is successful but arduino device is still unrecognized.
3) i have tried manually installing the drivers by letting windows search in the arduino IDE installation folder/drivers/
- it reports that the best driver is already installed - "usb unrecognized device"
4) i have tried installing the drivers by manulally loading the .inf files from the IDE installation folders, and installing all the serial converter A/B/C/D in the list - all failed to install.
i have done all the above for both IDE 1.0.5 and 1.5.7b with windows installer And zipped files, under administrative rights in windows 8.1
How do i get this to work?

Is your board connected to COM1?

well thing is, i connect to this board via USB and i honestly dont know what 'port1' is. the windows device manager does not recognize and is unable to install the arduino driver, thus unable to create any ports for it

Ah, well then. Does it show up as an unknown device in device manager?

yep, it does indeed

You said you loaded the .inf files, the guide mentions to just load up Arduino UNO.inf. I'm guessing you tried that?

yes, the arduino.inf file according to the device manager, does not contain any relevant information. i have oppened the file and it does indeed contain what i need, but device manager says it doesnt

After a quick google, would this help? link

Is this an official board? If so, you might have to contact Arduino and ask for a replacement. Other than that: another computer, another USB cable, make sure the right COM port/board is selected...

i am going to disable driver sign check as per doowy advice, and i will try it on a different pc too. how do i know if the board is official?

nothing worked, i guess my board is just faulty. thanks for the help guys

I have solved my issue. its funny, since i have got a new genuine kit, but the usb cable was faulty. i changed to some other usb cable i had laying around, and it worked perfectly...

Maybe you typed something in wrong somewhere; your Shift key appears to be having problems.

@TheGuywithTheHat if you are referring to the inconsistency in capitalization, dont mind it. i never care about correct capitalization. and no, i am pretty sure it was the cable. i never make case-sensitive mistakes where it matters.

The issue was resolved by changing my USB cable. the cable in the kit was new and seemed to supply power to the arduino board, but windows was unable to identify the board using that cable. maybe the data wires were damaged.
 in any case, i changed the cable and everything worked smoothly.

To solve this problem.
1. connect your Arduino board to the PC / Laptop.
2. open control panel. and go to view devices and printers
3. Here You can see a unknown device... i.e. your arduino board. double click on it.

4 Click on hardware..................................................

5. Now Choose Update Driver... Choose the location where the Arduino IDE is installed... And go to Next
6. Now your computer will recognise your arduino board

Right click on devices list from Manager
update driver and choose the folder with name "driver" in your arduino IDE app that you use
Ok
and the card ll be recognized
good luck


text:
What transparent casings are commonly used for smaller devices with a display
Not exactly Arduino-specific, but if you want to get a daily usable device (instead of a floating wire connection on your table) you eventually want to put your (Arduino-based) device into a nice casing. What are the different types of cases that people use?
I found soap cases as well as kitchen boxes (used one large cheese box from Mepal Rosti).

I found display cases for signed baseballs/golfballs/softballs useful for projects where I wanted all the pretty internals to be visible.  Just buy two - one to scratch up while planning, and then a clean one for the final result.

So far we have used:
ABS cases (pic camdenboss.com):

Small pelicases (convenient to open, pic pelican-case.com):

3D printed cases with a clear perspex window (pic instructables.com):

I've seen other people use laser cut perspex (pic spikenzielabs.com):

If you have affordable access to a laser cutter, then you could laser cut a box to exactly match your project.
Laser cutters typically come with software that reads SVG or DXF files.
Find out what file types are used, then search the web for something like "laser cut box design tool SVG", and you'll find a bunch of ways to make the box outline.
For example, this laser cut box web site generates a pdf file, which you can 'print'. You fill in a few parameters, and it does the rest, generating all the profiles for interlocking edges. Even though the edges are interlocking, you might want to add some glue to make it more robust.
An advantage of laser cutting is you can choose the materials. Maybe you'd like wood, with a transparent red acrylic lid.
A further advantage, if your laser can read things like SVG or DXF, is you could use a CAD or drawing program to modify the box. So, for example, you could 'etch' labels onto a control panel, or cut extra holes to mount LEDs. Or just decorate the outside of the box.

Yes, having a laser cutter would be handy. Unfortunately, that's no option for where I'm living. Nonetheless, thanks for the link, though the resulting pdf files waste a lot of material because of inefficient placing.

@Thomas S. I apologise for the poor choice of boxmaker. I thought I'd one which created DXF or SVG but I seen to have lost it. I'll ask a friend for the one they like, and update my answer if it is better. Do you not live in a country with MakerSpaces? Some of them offer to cut designs quite cheaply. I am not against ready made cases, it's just they often need to be cut anyway for cables, or to make components, like sockets, LEDs, etc. usable. I also like the idea of engraving labels onto it.


text:
Arduino Servo won't move when using classes
I'm trying to make a class work with Arduino, however it doesn't seem to trigger properly. The code is compiling perfectly, and it's supposed to control the leg of an hexapod. Also, the example sweep works on this servo, so no problem here. However, the servo is not actually moving. I'm thinking it has something to do with the order of declaring the variables:
#include <Servo.h>

// Abstract each leg, so only those functions can be accessed
class Leg {
  // Actions that can be triggered from outside
  public:
    Leg(int hipPin, int kneePin);
    void up();

  // These should be only available for the leg
  private:
    Servo hip;
    Servo knee;
  };

Leg::Leg(int hipPin, int kneePin) {
  hip.attach(hipPin);
  knee.attach(kneePin);
  }

// Testing the leg: move it up
void Leg::up() {
  for(int pos = 0; pos < 180; pos += 1) {
    hip.write(pos);
    delay(15);
    }
  }

// Initialize the leg
Leg topLeft(9, 10);

void setup() {
  }

// Test the function up()
void loop() {
  topLeft.up();
  }

I'm testing only the pin 9 (leaving the 10 empty). It seems in pain, meaning, you can see the servo trembling but not moving really at 0 degrees.

Note: similar question to this one, but since the solution didn't work for me, I'm assuming it's not the same problem. Any help debugging it is also welcome (:

Does the same setup work with the same pin when you test just the hip servo code outside of class? Does the problem only occur when the code is inside the Leg class?

Your problem may be similar to this question: http://arduino.stackexchange.com/questions/830/timer2-does-not-work-as-it-should

It looks this problem may be due to bad order of initializers calls for global variables.
In C++, the order of global variable initialization is unpredictable across different compilation units (i.e. C++ source files, not header files). Initialization order is only respected inside one compilation unit.
In your program, there are several global variables that, if initialized in the wrong order, will fail your program:

Leg topLeft; this is your class instance
servo_t servos[MAX_SERVOS];, int8_t Channel[_Nbr_16timers ]; and uint8_t ServoCount = 0; all defined in Servo.cpp

Calling Servo.attach() requires that the 3 variables above have already been initialized, which you cannot be sure of.
How can you fix that?
By not performing the attach() in Leg constructor but delegating it to some kind of init() method that you can call from setup():
class Leg {
    // Actions that can be triggered from outside
    public:
    void init(int hipPin, int kneePin);
    void up();

    // These should be only available for the leg
    private:
    Servo hip;
    Servo knee;
};

Leg::init(int hipPin, int kneePin) {
    hip.attach(hipPin);
    knee.attach(kneePin);
}

// Testing the leg: move it up
void Leg::up() {
    for(int pos = 0; pos < 180; pos += 1) {
        hip.write(pos);
        delay(15);
    }
}

// Declare the leg
Leg topLeft;

void setup() {
    // Initialize the leg
    topLeft.init(9, 10);
}

// Test the function up()
void loop() {
    topLeft.up();
}

Just for clarification, the initialization order of global variables is not defined only between different translation units. In the same translation unit, it is the order of their definitions.

+1 this is gold, the explanation just solved about 100% of the unresolved problems I've ever had with arduino and C++. Thank you, I'll test it when I get home.

@Omer thanks for the clarification which I had forgotten to include. I have just edited my answer.


text:
question about progmem
I have a problem understanding the following code:
PROGMEM  prog_uint16_t x={1232,3232,43343};
rawlen = pgm_read_word_near(x);
memcpy_P(uSendBuff, pfSendBuff+1, rawlen * sizeof(uint16_t));

Why do we need this? -
rawlen * sizeof(uint16_t));

Why not this? -
memcpy_P(uSendBuff, pfSendBuff+1, sizeof(rawlen));

Probably because x is an array of integers (although in the code you posted you miss the '[]'), thus memcpy_p should run over rawlen integers, each integer occupies sizeof(uint16_t) bytes, hence rawlen * sizeof(uint16_t) bytes in program memory space.


text:
Adapt program to suit Arduino UNO
I am trying to use a program that has been written for  STM32 microprocessor for interfacing with a Time to Digital Converter TDC GP22 via SPI interface. I would like to use the same program and adapt it to suit Arduino Uno for interfacing with TDC GP22. This would really help save a lot of time.
Can someone please suggest me the most effective way to do this ?

Read the code. Write high-level pseudocode. Translate the pseudocode.

@user18197 - Do you know how to use programming languages other than the Arduino's? Specifically, do you know languages that are good at text processing using regular expressions? For example, Perl, Python, Rubu, Go, awk, etc?

You'll be wasting your time tring to convert the code on a procedure by procedure basis.  Arduino has different libraries, different clocks, different pins, etc.
I suggest you flowchart the code, and then work out which of the Arduino libraries (SPI, LCD, etc.) you can use to achieve the flow.  You'll be able to drop some of the initialisation code probably as Arduino is easier to run "out the box".
There's no quick-and-easy solution here - it's a re-write... as you'll find is often the case migrating code from one MCU to another.


text:
Attiny13 + Arduino
I started my first try in programming an ATTINY13 with my Arduino 2560.
Everything seemed fine, however when I wanted to run the blink example, my LED did not blink, it keeps lighting.
I am using 5V as input voltage.
I did not change the blink example except for the correct pin number.
All the wiring seems correct, when I change the pin number the LED stays dark, so my program is arriving propperly on the ATTINY.
If I start playing with the delays (delaymicroseconds) I get the LED to become darker.
The documentation of the ATTINY13 (www.atmel.com/images/doc2535.pdf) mentions a maximum clock frequency of 20MHz. When I choose the ATTINY13 from the Arduino IDE board menu it is listed with a 9.6MHz clock.
Could this be a reason?
How can I adjust or take care of that?
----------- Edit:
I was starting with the default blink example (delay(1000)).
I played with both, the normal delay and the delayMicroseconds.
The following codes dimmed the LED:
void setup() {
  pinMode(3, OUTPUT);
}

void loop() {
  digitalWrite(3, HIGH);
  delayMicroseconds(10);
  digitalWrite(3, LOW);
  delayMicroseconds(1000);
}

Which makes me believe the LED is blinking very fast.
A similar sketch with normal delay does not make the LED dim:
void setup() {
  pinMode(3, OUTPUT);
}

void loop() {
  digitalWrite(3, HIGH);
  delay(1);
  digitalWrite(3, LOW);
  delay(100);
}

And as mentioned with the default blink sketch the LED nothing happens as well.
I also made the delay a ever increasing variable to see if something is happening, no luck.
And I have 2 ATTINYs to test, same result for both...
--- Edit2:
Another try:
int led = 3;

void setup() {
  pinMode(led, OUTPUT);
  digitalWrite(led, HIGH);
  delayMicroseconds(100);
  digitalWrite(led, LOW);
}

void loop() {
}

Now I moved switching the LED on and off into the setup function. Strangely enough, by changing the delay between 1000 and 100 micro seconds, the LED gets lighter and darker...
---- Edit 3:
Here is my circuit:

And this is the ATTINY specific code I added to the Arduino IDE:
attiny13.name=ATtiny13 (internal 9.6 MHz clock)
attiny13.bootloader.low_fuses=0x7a
attiny13.bootloader.high_fuses=0xff
attiny13.upload.maximum_size=1024
attiny13.build.mcu=attiny13
attiny13.build.f_cpu=9600000L
attiny13.build.core=arduino:arduino
attiny13.build.variant=tiny8

Sounds like the LED is flashing very quickly. Try delaying for a longer time.

Delay microseconds? That's a very short amount of time... try using delay() in general because that is milliseconds

Possibly the fuse is not set correctly to match the desired oscillator.

If it is getting lighter and darker in set up then the ATTiny is resetting. What clock source are you using?

Post your circuit. How have you connected the reset pin?

Try adding a capacitor near the attiny's VCC. You are using a resistor with that led, right? What core are you using, as the Arduino IDE doesn't support the attiny13 by default?

To echo what @mpflaga says, a microsecond is a millionth of a second. So 100 microseconds is 1/10,000 of a second. You should be using delay(200). "delay" is in milliseconds (thousandths of a second) and 200 milliseconds is 2/10 of a second, a flash rate you could actually see.

I switched to a different ATTINY 13 driver and core definition in the Arduino IDE and this made it work.
Unfortunately by playing around I lost track of the old driver.
I am now using smeezkekitty's core13 which I found here: http://elabz.com/arduino-shrunk-how-to-use-attiny13-with-arduino-ide/

The documentation of the ATTINY13 (www.atmel.com/images/doc2535.pdf) mentions a maximum clock frequency of 20MHz. When I choose the ATTINY13 from the Arduino IDE board menu it is listed with a 9.6MHz clock.
Could this be a reason? How can I adjust or take care of that?

I don't think it is the reason, as it is totally fine to underclock your chip. In fact, most Arduino boards are underclocked. In fact, the Arduino Uno's chip can do 20MHz, but it is only ran at 16MHz.
As mentioned in the comments, your oscillator might be off. However, it should still blink. If you're saying changing the pin makes it go dark, then some code is running.
My guess is your delay is way to short. You said you were using delayMicroseconds(). Emphasis on microseconds, not milliseconds. (1 second = 1,000 milliseconds; 1 millisecond = 1,000 microseconds) If you meant to be using milliseconds, it is very possible that you are changing the power to the LED at 1,000 times a second, instead of 1. This would make the LED dimmer than directly to power, but it would still appear lit.
Try this code:
void setup() {
  pinmode(LEDPIN, OUTPUT);
}

void loop() {
  digitalWrite(LEDPIN, HIGH);
  delay(1000);
  digitalWrite(LEDPIN, LOW);
  delay(1000);
}

Of course, replace the LEDPIN with the right value.

I added some code an clarification: I used both, delay and delayMicorseconds.

@pat the first one you delay it for 1.0e-6 seconds, and then 1/1000th of a second. On the second example, you blink it for 1/1000th of a second, and then for 1/10th of a second. Those are way too short.

I know, it is to quick to see a blink. But with the first example I see the LED becaome darker (the result of the very fast blink), but not with the second example.

@pat that is because the LED is only on for 1/1000th of a second. That's not much time! I'd try at least 50 for that delay, although the LED brightness and a few other factors will determine if you can see the LED lighting up.

See my new edit, I moved switching the LED into the setup function and the behaviour became even weirder... (thanks for your help btw.)

@pat I'm not sure why it gets lighter/darker since you always have it either HIGH or LOW and that isn't in a loop. However, that code 1.) never repeats and 2.) if it did repeat, you'd need a delay after turning it off. Try my code first to see if the issue is with the code or with your hardware...

Pin 1 is active low reset. Try connecting it to 5V to run the program.


text:
little pump isn't working
I'm trying to use a little pump with my arduino nano:
void setup ()
{
  pinMode(waterPump, OUTPUT);
}
...
  while (val < valueWater)
  {
    Serial.println ("in while"); // testing purpose
    digitalWrite(waterPump, HIGH);
    delay(1000); // 1 second
    digitalWrite(waterPump, LOW);
    val = analogRead(sondeEau);
  }

When I try this one, pump isn't working. When I unplug the waterPump pin, I see "LED3" that run, and when I plut it, LED3 is not running, why?
I tried to plug pump directly on 5V on arduino, pump works well...
This is the pump I bought: http://www.dx.com/p/hsyy01-water-pump-motor-w-hose-white-silver-236808
Thanks in advance to help me!

You can't plug a motor directly into the arduino, you need an appropriate driver circuit, or for simplicity, a "motor shield".  Further, you should not try to a run the motor off of USB power or through the Arduino's voltage regulator.

You plugged this directly into your Arduino? You might as well have dropped your Arduino in the water you are pumping...
The Arduino can only supply 40mA per pin. However, you pump requires 800 mA!!! Often, when overloading a pin, the Arduino chip is fried. Even worse, a typical USB port can only supply 500 mA, so you could have fried your computer if using USB.
You'll need a motor driver. Like mentioned in the comments, the Arduino motor shield is a great place to start. If you don't to spend all that money, you have a few options:

A relay is an easy way that works with almost all voltages and any reasonable amount of current.
If you want something a little more professional, a transistor, like a MOSFET would be the way to go. They're fairly cheap, but you have to know which to pick (that's hard to do in practice).
You can also get a half H-bridge which I think would work well for your situation.

When I unplug the waterPump pin, I see "LED3" that run, and when I plut it, LED3 is not running, why?

The motor is likely taking up all the current.
tl;dr: get an external power source and get a proper motor driver.

Pretty much any logic level power mosfet will do, driven through a 120 ohm resistor. Plus a flyback diode across the motor. I think that's the cheapest and lowest component count solution.

I would not qualify a relay to "wok with any reasonable amount of current". Using a relay typically implies using a transistor (not a high-current) AND a diode to protect against emf currents.

@jfpoilpret I meant that a relay shield/break out board might be better than a transistor (as far as ease of use for some users).

I used a relay I had and an other power source for the motor. Thanks for your infos, very appreciate!

As Chris says, you should never plug a high current device like a motor directly into a pin on your Arduino. That motor is rated at 800 mA, which is more than you can draw from the entire 5V supply on the Arduino!
The digital pins are rated for 40 mA max, if I remember correctly. You tried to draw 20 times that much. There is a decent chance that you burned out the driver for that digital pin. I would try hooking an LED through a 220 ohm resistor and to ground and see if it still lights up when you send it a HIGH logic signal.
For a simple DC motor you should be able to use a high current transistor and an external power supply to drive it.
Edit:  If I were doing this I would use a logic-level MOSFET to drive the pump directly, plus a flyback diode. To use a relay, you will still need a transistor to power the relay coil, AND a flyback diode. Your circuit might look like this:

(Note that I made no attempt to pick the RIGHT kind of diode and transistor. Ignore the part numbers shown in the schematic. I just used the defaults.)

All is ok, all pin works. I finally used a relay and 5V 2A input source, it works well.

Did you put a flyback diode on the relay? (VERY important!) And are you driving the relay with a transistor? A relay's coil will almost certainly draw more than the 40 mA max from an Arduino digital output pin.


text:
Arduino Pro Mini (5V) Raw Pin and VCC Pin
I am new to the microcontroller world and circuits, so bare with me. I recently bought some 5V arduino pro mini microcontrollers. I have been playing with them and they work fine, I have been powering it from an usb connection.
Now I want to power the board using a 9V battery, I connected the + to the RAW pin and the Ground to the Ground pin on the Arduino.
My question is if I can still use the VCC pins? I understand the board has a voltage regulator that from my understanding it brings down the 9V to 5V. I thought this 5 volts were available through the VCC pin but I connected an LED to it and nothing happens.

I have tried this method with an arduino Uno and it works so I dont know why it doesnt work with the Pro Mini.

Is the LED plugged in the right way? If the board is okay, it should work AFAIK.

Yes. I tried this setup with the Arduino Uno and it works

I bet it is a hardware issue if you are 100% sure it is plugged in the right way. Can you blink pin 13?... you might just have to get a replacement. I'm not sure though...

Yes i think its a defective board

Hmm... double check everything again. If it is defective, we can't really help you; you will have to contact the seller. I have no more advice, but good luck :)

You could always test it with a voltimeter to make sure it's the pin, not the power source or led where the issue lies.

Note you should have a current limiting resistor. The regulator can supply up to 150mA. With out a limit can pop your LED. Assuming it is running 5V.

Is your Mini really 5V. If it was 3V some LED's may not work, with or without limiting resistor.

As others have pointed out, without a current limiting resistor you may have fried the LED. Thus you might need another LED to test with. On a typical LED with a 1.2 forward voltage drop, a 220 ohm resistor will limit current to about 17 mA (i = v/r.)
forward voltage = supply voltage - LED voltage drop
forward voltage  = (5.0 - 1.2) = 3.8
current = 3.8V/220ohms = 17 mA.
Check the specs on your LEDs. 1.2 V forward voltage drop is common on little LEDs. Max current of 20 mA is common as well, but it doesn't pay to go all the way to the max. That's the "do not exceed or you may destroy it" level.

One way to figure out the answer to a question like this is to go have a look at the schematic. It's not perhaps not as clear as it could be there, but the VCC output of the regulator is connected to the common VCC bus across the board that's connected to the microcontroller and the JP1 and JP7 headers.
A cheap multimeter can be handy for checking voltages, and would also be able to use it to check the continuity (while the board is unplugged from everything!) between the VCC pin and the output of the regulator.


text:
In Linux, how to identify multiple Arduinos connected over USB?
If I have multiple Arduinos connected over USB to a Linux computer, and they show up as

/tty/ACM0
/tty/ACM1
/tty/ACM2

How can I identify which Arduino is which without connecting to them via serial connection? Is there a serial number or a unique id on the Arduino?
Thank you for your time.
Situation: Uno R3, Mega, Leonardo with /ttyACM[1,2,3]
lsusb output with devices in the order mentioned above:

...
Bus 001 Device 011: ID 2341:0043
Bus 001 Device 013: ID 2341:8036
...
Bus 001 Device 014: ID 2341:0042

lsusb -d vendor:device -vvv shows for each one
Uno

Bus 001 Device 014: ID 2341:0042
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               1.10
  bDeviceClass            2 Communications
  bDeviceSubClass         0
  bDeviceProtocol         0
  bMaxPacketSize0         8
  idVendor           0x2341
  idProduct          0x0042
  bcdDevice            0.01
  iManufacturer           1 Arduino (www.arduino.cc)
  iProduct                2
  iSerial               220 55330313735351910141
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           62
    bNumInterfaces          2
    bConfigurationValue     1
    iConfiguration          0
    bmAttributes         0xc0
      Self Powered
    MaxPower              100mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           1
      bInterfaceClass         2 Communications
      bInterfaceSubClass      2 Abstract (modem)
      bInterfaceProtocol      1 AT-commands (v.25ter)
      iInterface              0
      CDC Header:
        bcdCDC               10.01
      CDC ACM:
        bmCapabilities       0x06
          sends break
          line coding and serial state
      CDC Union:
        bMasterInterface        0
        bSlaveInterface         1
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x82  EP 2 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0008  1x 8 bytes
        bInterval             255
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        1
      bAlternateSetting       0
      bNumEndpoints           2
      bInterfaceClass        10 CDC Data
      bInterfaceSubClass      0 Unused
      bInterfaceProtocol      0
      iInterface              0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x04  EP 4 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               1
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x83  EP 3 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               1
Device Status:     0x0000
  (Bus Powered)

Leonardo:
Bus 001 Device 013: ID 2341:8036
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass         0
  bDeviceProtocol         0
  bMaxPacketSize0        64
  idVendor           0x2341
  idProduct          0x8036
  bcdDevice            1.00
  iManufacturer           1 Arduino LLC
  iProduct                2 Arduino Leonardo
  iSerial                 0
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength          100
    bNumInterfaces          3
    bConfigurationValue     1
    iConfiguration          0
    bmAttributes         0x80
      (Bus Powered)
    MaxPower              500mA
    Interface Association:
      bLength                 8
      bDescriptorType        11
      bFirstInterface         0
      bInterfaceCount         2
      bFunctionClass          2 Communications
      bFunctionSubClass       2 Abstract (modem)
      bFunctionProtocol       1 AT-commands (v.25ter)
      iFunction               0
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           1
      bInterfaceClass         2 Communications
      bInterfaceSubClass      2 Abstract (modem)
      bInterfaceProtocol      0 None
      iInterface              0
      CDC Header:
        bcdCDC               1.10
      CDC Call Management:
        bmCapabilities       0x01
          call management
        bDataInterface          1
      CDC ACM:
        bmCapabilities       0x06
          sends break
          line coding and serial state
      CDC Union:
        bMasterInterface        0
        bSlaveInterface         1
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x83  EP 3 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               0
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        2
      bAlternateSetting       0
      bNumEndpoints           1
      bInterfaceClass         3 Human Interface Device
      bInterfaceSubClass      0 No Subclass
      bInterfaceProtocol      0 None
      iInterface              0
        HID Device Descriptor:
          bLength                 9
          bDescriptorType        33
          bcdHID               1.01
          bCountryCode            0 Not supported
          bNumDescriptors         1
          bDescriptorType        34 Report
          wDescriptorLength     101
          Report Descriptor: (length is 101)
            Item(Global): Usage Page, data= [ 0x01 ] 1
                            Generic Desktop Controls
            Item(Local ): Usage, data= [ 0x02 ] 2
                            Mouse
            Item(Main  ): Collection, data= [ 0x01 ] 1
                            Application
            Item(Local ): Usage, data= [ 0x01 ] 1
                            Pointer
            Item(Main  ): Collection, data= [ 0x00 ] 0
                            Physical
            Item(Global): Report ID, data= [ 0x01 ] 1
            Item(Global): Usage Page, data= [ 0x09 ] 9
                            Buttons
            Item(Local ): Usage Minimum, data= [ 0x01 ] 1
                            Button 1 (Primary)
            Item(Local ): Usage Maximum, data= [ 0x03 ] 3
                            Button 3 (Tertiary)
            Item(Global): Logical Minimum, data= [ 0x00 ] 0
            Item(Global): Logical Maximum, data= [ 0x01 ] 1
            Item(Global): Report Count, data= [ 0x03 ] 3
            Item(Global): Report Size, data= [ 0x01 ] 1
            Item(Main  ): Input, data= [ 0x02 ] 2
                            Data Variable Absolute No_Wrap Linear
                            Preferred_State No_Null_Position Non_Volatile Bitfield
            Item(Global): Report Count, data= [ 0x01 ] 1
            Item(Global): Report Size, data= [ 0x05 ] 5
            Item(Main  ): Input, data= [ 0x03 ] 3
                            Constant Variable Absolute No_Wrap Linear
                            Preferred_State No_Null_Position Non_Volatile Bitfield
            Item(Global): Usage Page, data= [ 0x01 ] 1
                            Generic Desktop Controls
            Item(Local ): Usage, data= [ 0x30 ] 48
                            Direction-X
            Item(Local ): Usage, data= [ 0x31 ] 49
                            Direction-Y
            Item(Local ): Usage, data= [ 0x38 ] 56
                            Wheel
            Item(Global): Logical Minimum, data= [ 0x81 ] 129
            Item(Global): Logical Maximum, data= [ 0x7f ] 127
            Item(Global): Report Size, data= [ 0x08 ] 8
            Item(Global): Report Count, data= [ 0x03 ] 3
            Item(Main  ): Input, data= [ 0x06 ] 6
                            Data Variable Relative No_Wrap Linear
                            Preferred_State No_Null_Position Non_Volatile Bitfield
            Item(Main  ): End Collection, data=none
            Item(Main  ): End Collection, data=none

            ......

      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x84  EP 4 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               1
Device Status:     0x0000
  (Bus Powered)

And Mega256:
Bus 001 Device 014: ID 2341:0042
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               1.10
  bDeviceClass            2 Communications
  bDeviceSubClass         0
  bDeviceProtocol         0
  bMaxPacketSize0         8
  idVendor           0x2341
  idProduct          0x0042
  bcdDevice            0.01
  iManufacturer           1 Arduino (www.arduino.cc)
  iProduct                2
  iSerial               220 55330313735351910141
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           62
    bNumInterfaces          2
    bConfigurationValue     1
    iConfiguration          0
    bmAttributes         0xc0
      Self Powered
    MaxPower              100mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           1
      bInterfaceClass         2 Communications
      bInterfaceSubClass      2 Abstract (modem)
      bInterfaceProtocol      1 AT-commands (v.25ter)
      iInterface              0
      CDC Header:
        bcdCDC               10.01
      CDC ACM:
        bmCapabilities       0x06
          sends break
          line coding and serial state
      CDC Union:
        bMasterInterface        0
        bSlaveInterface         1
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x82  EP 2 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0008  1x 8 bytes
        bInterval             255
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        1
      bAlternateSetting       0
      bNumEndpoints           2
      bInterfaceClass        10 CDC Data
      bInterfaceSubClass      0 Unused
      bInterfaceProtocol      0
      iInterface              0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x04  EP 4 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               1
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x83  EP 3 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               1
Device Status:     0x0000
  (Bus Powered)

lsusb -vvv says?

Can you unplug one and see which one disappears?

Not really, i want to do this for a remote solar-powered sensor array that will be very far away for someone to do that when it reboots.

Ignacio Vasquez-Abrams - how can I map the information from lsusb -vvv to /dev/ttyACM ? IS there something in the lsusb output i can parse? Thank you for the idea!

Do you have another Arduino you can compare output with?

Added two more arduino types - all 3 connected at once.

What also puzzles me is that the leonardo has iSerial = 0, while the others have a serial number.

Does this article from my personal website help? http://wirespeed.xs4all.nl/mediawiki/index.php/Udev_rules_file_for_Arduino_boards  I am curious if other Leonardo's have the same 0 serial number, it seems odd to me.

What happens if you use sudo lsusb -s............?

Assuming your distro is using udev:
udevadm info --query=all --name=/dev/ttyACM0

You might need root privileges to run this(sudo / su). It will output a list of information like this:
P: /devices/pci0000:00/0000:00:1d.2/usb4/4-2/4-2:1.0/tty/ttyACM0
N: ttyACM0
S: serial/by-id/usb-Dean_Camera_LUFA_USB-RS232_Adapter_74133353537351403012-if00
S: serial/by-path/pci-0000:00:1d.2-usb-0:2:1.0
E: DEVLINKS=/dev/serial/by-id/usb-Dean_Camera_LUFA_USB-RS232_Adapter_74133353537351403012-if00 /dev/serial/by-path/pci-0000:00:1d.2-usb-0:2:1.0
E: DEVNAME=/dev/ttyACM0
E: DEVPATH=/devices/pci0000:00/0000:00:1d.2/usb4/4-2/4-2:1.0/tty/ttyACM0
E: ID_BUS=usb
E: ID_MM_CANDIDATE=1
E: ID_MODEL=LUFA_USB-RS232_Adapter
E: ID_MODEL_ENC=LUFA\x20USB-RS232\x20Adapter
E: ID_MODEL_FROM_DATABASE=Uno R3 (CDC ACM)
E: ID_MODEL_ID=0043
E: ID_PATH=pci-0000:00:1d.2-usb-0:2:1.0
E: ID_PATH_TAG=pci-0000_00_1d_2-usb-0_2_1_0
E: ID_REVISION=0001
E: ID_SERIAL=Dean_Camera_LUFA_USB-RS232_Adapter_74133353537351403012
E: ID_SERIAL_SHORT=74133353537351403012
E: ID_TYPE=generic
E: ID_USB_DRIVER=cdc_acm
E: ID_USB_INTERFACES=:020201:0a0000:
E: ID_USB_INTERFACE_NUM=00
E: ID_VENDOR=Dean_Camera
E: ID_VENDOR_ENC=Dean\x20Camera
E: ID_VENDOR_FROM_DATABASE=Arduino SA
E: ID_VENDOR_ID=2341
E: MAJOR=166
E: MINOR=0
E: SUBSYSTEM=tty
E: UDEV_LOG=3
E: USEC_INITIALIZED=751387324986

This is for an Uno with modified firmware on the atmega16u2(usb to serial). The lines of interest are probably ID_MODEL_ID and ID_MODEL_FROM_DATABASE.

Thank you. I am using OpenWrt in this case with hotplug2 by default but I will try to switch to udev and test this.

On Ubuntu 16.04 (and maybe previous versions or other distribs too), you can do:
> ls /dev/serial/by-id

which displays (on my box where an Arduino UNO is connected):
usb-Arduino__www.arduino.cc__0043_A4139363931351318241-if00

You can easily spot the Device ID 0043 (UNO) here.
This file is actually a link to /dev/ttyACM0 in my box.

Use ls -la /dev/serial/by-id to see the link

You can add an alias for each. Then you know which is which. Here is a nice tutorial on how to set this up.
Here is a snippet that I wrote based on the tutorial. In the below example, I am using a FTDI RS232RL USB to Serial adapter, which I believe is what the Arduino uses too.

In order to assign an alias to a USB-Serial device, we need to find some info on the device
Plug in the usb. This assumes you have already install the drivers for this use be device and the device is visible when typing:

lsusb

We are going to need the following
a.    The vendor id
b.    The product id
c.    The device serial number
To do this, it takes a little bit of hunting. All your devices log entries in '/var/log/messages'.

Therefore we can read this file and find the correct USB:
grep "ftdi" /var/log/messages

You can also use "usb"

This is find all messages tagged with ftdi:
Next to ftdi_sio, there is a number like 1-1.2. This is the USB device

grep "usb 1-1.2" /var/log/messages
Or you can use:
dmesg | grep "usb 1-1.3"

This gives us all the info we need:

Now with the list of serial numbers in hand let’s create a UDEV ruleset that’ll make a nice symbolic link for each of these devices. UDEV rules are usually scattered into many files in /etc/udev/rules.d. Create a new file called 99-usb-serial.rules and put the following lines in there:

In this example my alias is called 'lcdbox'
SUBSYSTEM=="tty", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6001", ATTRS{serial}=="A601ERJJ", SYMLINK+="lcdbox"

SYMLINK is the name of your alias. In this case my alias is lcdbox.
Save the file and type
sudo udevadm control --reload-rules
Type
ls –l /dev/lcdbox

lrwxrwxrwx 1 root root 7 Jan  1  1970 /dev/lcdbox -> ttyUSB0

This shows that my lcdbox alias is mapped to ttyUSB0

This is quite easy! You have to customize the ftdi chips firmware and add an udev rule:
First, get ftdi_eeprom via apt-get or from the sources. Identify your device via lsusb and get the id:

lsusb

Bus 001 Device 005: ID 0403:6001 Future Technology Devices International, Ltd FT232 Serial (UART) IC
....

Prepare a config and make sure, that vendor_id and product_id match. Customize the strings in the Strings section to get a unique id for your device.

vendor_id=0x0403    # Vendor ID
product_id=0x6001   # Product ID

max_power=50        # Max. power consumption: value * 2 mA. Use 0 if self_powered = true.

###########
# Strings #
###########
manufacturer="FTDI"     # Manufacturer
product="Arduino Nano"      # Product
serial="arduino1"       # Serial

###########
# Options #
###########
self_powered=false  # Turn this off for bus powered
remote_wakeup=false # Turn this on for remote wakeup feature
use_serial=true     # Use the serial number string

# Normally out don't have to change one of these flags
# BM_type_chip=true         # Newer chips are all BM type
in_is_isochronous=false     # In Endpoint is Isochronous
out_is_isochronous=false    # Out Endpoint is Isochronous
suspend_pull_downs=false    # Enable suspend pull downs for lower power
change_usb_version=false    # Change USB Version
usb_version=0x0200      # Only used when change_usb_version is enabled

########
# Misc #
########

filename="eeprom.old"   # Filename, leave empty to skip file writing
cbus0=RXLED#
cbus1=TXLED#

Dump the current ftdi-firmware:
ftdi_eeprom --read-eprom
This command creates ${pwd}/eeprom.old, which contains the current firmware on the ftdi. Backup this file before continuing, because during flash-eeprom the file gets rewritten. After the backup, flash the ftdi:
ftdi_eeprom --flash-eeprom myconfig.conf

Now, create an udev rule, like so
SUBSYSTEMS=="usb", ATTRS{idProduct}=="6001", ATTRS{idVendor}=="0403", SYMLINK+="$attr{serial}", OWNER="bananapi", GROUP="pi", MODE="0777"

in /etc/udev/rules.d/90-arduino-usb.rules and restart udev.
service udev restart

Unplug and re-plug your device and try
ls -lah /dev/arduino1

Where arduino1 is the string defined under serial in the above .conf.
See also: Risks of ftdi_eeprom? - TX always high after flashing

I would have used a script to make an alias under /dev/ and also set group and rights on it with udev like the other answers.
But if I didn't have udev I would pipe lsusb into grep or awk, like lsusb|grep -e "idProduct".
Anyway, with udev rules or with lsusb and grep to identify USB devices, use idVendor, idProduct and iSerial in Device descriptor part of lsusb to make the proper idenification.  The idVendor tells you the manufaturer, idProduct should indentify the product from the manufacturer but sometimes they use the same product id for more than one product.  Lastly, if needed, the iSerial should be a unique id for each example of that product.

You can always make some kind of id print via serial in void setup(). After the certain board is connected it will send this id to your USB interface (which you are listening with some kind of daemon app on your linux box). Once you receive id you can map it to it's path
 'Arduino1' : '/dev/ttyACM0',
 'Arduino2' : '/dev/ttyACM1',
 'Arduino3' : '/dev/ttyACM2'...etc
Be aware that when device is disconnected for some reason it can change it's physical path so you might have to remap all of them. For this case it might be good to write separate function ex: get_id() which you can call any time (not only on startup).

I'd be mighty tempted to identify some other way, like having the sketch itself respond to a special identify command, just to avoid USB's odd ways of identifying devices.

Overview

One way as ansi_lumen mentioned in his answer is to flash ftdi
chip EEPROM to have unique serial number which then could be
identified by UDEV rules.
But turns out it won't work on cheap chinese Arduinos which instead
of FTDI has CH340G chip which doesn't have EEPROM to store
unique ID (CH340B should work).
This answer suggests to write UDEV rule with special script
which asks Arduino to send its unique ID via serial. Problem with
that is that you need to modify Arduino sketch and in general it's
quite complex.

Identifying by port
So the easiest way I found was to use UDEV rules and identify Arduinos by the usb port (devpath)
so connecting Arduino to the same port (even in nested usb hubs) will create persistent name.
TLDR setup:
Modified version of this

Find Arduino idVendor and idProduct:

lsusb
You will get something like this:
...
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 124: ID 1a86:7523 QinHeng Electronics HL-340 USB-Serial adapter
Bus 003 Device 123: ID 214b:7000
Bus 003 Device 122: ID 1a86:7523 QinHeng Electronics HL-340 USB-Serial adapter
Bus 003 Device 121: ID 1a86:7523 QinHeng Electronics HL-340 USB-Serial adapter
Bus 003 Device 120: ID 1a40:0101 Terminus Technology Inc. Hub
...

By connecting/disconnecting Arduino find which one it is (I have 3 connected). We are looking for its ID. In my case "...ID 1a86:7523 QinHeng...". So idVendor=1a86, idProduct=7523

Create new UDEV rules file:

sudo nano /etc/udev/rules.d/99-usb-serial.rules

Modify idVendor and idProduct values by what you found in previous step on copy paste it in the rules file we have created:

SUBSYSTEM=="tty", ATTRS{idVendor}=="1a86", ATTRS{idProduct}=="7523", SYMLINK+="ttyUSB-arduino%s{/devpath}"

Reload UDEV rules

sudo udevadm control --reload

Replug Arduinos and now it will have unique name. To test it type:

ls /dev/ttyUSB*

Which will output:
/dev/ttyUSB1  /dev/ttyUSB3  /dev/ttyUSB-arduino2.1  /dev/ttyUSB-arduino2.4
 /dev/ttyUSB2  /dev/ttyUSB4  /dev/ttyUSB-arduino2.2  /dev/ttyUSB-arduino3
As you can see we still get /dev/ttyUSBx as before which are always changing depending which one was connected first. But now we also have /dev/ttyUSB-arduino{port} which are always the same for same port and only for Arduinos. To analyze what "..arduino2.4" means: 2 refers to the second port of laptop and 4 to the fourth port on usb hub.
To better see it type:
lsusb -t

Output:
...
/:  Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 480M
    |__ Port 1: Dev 5, If 0, Class=Human Interface Device, Driver=usbhid, 12M
    |__ Port 1: Dev 5, If 1, Class=Human Interface Device, Driver=usbhid, 12M
    |__ Port 2: Dev 84, If 0, Class=Hub, Driver=hub/4p, 480M
        |__ Port 1: Dev 85, If 0, Class=Vendor Specific Class, Driver=ch341, 12M
        |__ Port 2: Dev 86, If 0, Class=Vendor Specific Class, Driver=ch341, 12M
        |__ Port 3: Dev 87, If 0, Class=Hub, Driver=hub/4p, 480M
        |__ Port 4: Dev 88, If 0, Class=Vendor Specific Class, Driver=ch341, 12M
    |__ Port 3: Dev 89, If 0, Class=Vendor Specific Class, Driver=ch341, 12M
/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/2p, 480M
    |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/6p, 480M
...

By connecting/disconnecting you can see which devices are on which ports


text:
Question different ways of connecting L298N motor driver board to arduino and motors and powering them
I read few posts and tutorials on this topic but none of them kind of answered my questions.  I bought this L298N motor board and i have two motors that are rated 3V

Now i am trying to understand how to connect it to arduino and power the motors.
For example i have a 12V (8x 1.5v AA batteries) I can connect to VCC and GND then enable ENA with a jumper and connect PWN port from arduino to INA. This way i can control the voltage that is coming out from OUTA and OUTB  I can bring down the 12V to 3V.
Now the question is can i use the +5 (regulated voltage) on the driver board and connect it to arduino Vin and GND to ground to power the arduino? Is that viable solution.  I actually tried it and it works.  I am worried that it is not enough voltage to properly power the arduino.  It's suggested to connect 7v - 12v to Vin.  I am also going to connect a red lab ble shield on top of arduino that is powered by 5v
Another question is if i use 12 volts battery and step it down to 3v with PWN is that going to heat up the L298N chip?

Another option is connecting 9V battery to arduino and then using Vin and GND to power the motor shield and the motors.  The problem there if motor draws more then 1Amp that wouldn't be good for the arduino.  Also if i would switch to 9v+ motors then it wouldn't work.
The third option is to have two separate power sources. 9V for arduino and 5v+ for powering the motors.  Does it make sense to use two power sources?
This project seems like a good way to learn about arduino and electronics
Update
NEOMART Brand New Original High Quality Chips L298N
http://www.amazon.com/gp/product/B00E58EA90/ref=oh_aui_detailpage_o04_s00?ie=UTF8&psc=1
Product Details
1. driver chip: L298N Dual H-Bridge Motor Driver IC

drive section terminal supply area Vs: +5V ~ +35V; such as the need to take power within the board, the supply area Vs: +7V ~ +35V
drive section peak current Io: 2A
logical part of the terminal supply area Vss: +5V ~ +7V(can take power within the board +5V)
logical part of the operating current range: 0 ~ 36mA
Control signal input voltage range:
Low:-0.3V ≤ Vin ≤ 1.5V
High: 2.3V ≤ Vin ≤ Vss
enable signal input voltage range:
Low: -0.3 ≤ Vin ≤ 1.5V (control signal is invalid)
High: 2.3V ≤ Vin ≤ Vss (control signal active)
Maximum power consumption: 20W (when the temperature T = 75℃)
Storage temperature: -25℃ ~ +130℃
Driver Board Size: 48mm*43mm*33mm (with fixed copper pillar and the heat sink height)
Other Extensions: control of direction indicators, the logic part of the plate to take power interface.

Update 2:
I wanted to clarify regarding using 12 volt battery and having 2 motors that I think max voltage is 3 volts.  If i use PWN and step down the voltage to 3 volts will L298N produce a lot more heat to step the voltage down?
Probably in this case would be the best just to get two separate power supplies 9 volts for arduino and 4.5 volts for the motor drive to supply 3 volts for each motor.  Unless i get better motors that support 6v - 9v then i can use the 12 volts battery for both arduino and motors.
As far as the motor drivers, I thought they are used to prevent the noise and power spikes from motors?  I guess you still have to consider it either way.
Thanks in advance!

Can you post a link to the datasheet of that board?

I couldn't find the data sheet for it.  Everyone on amazon complained about it. I updated the answer with the link to the amazon page and some schematics but its pretty small picture.

Found these 2 links: http://www.dx.com/p/l298n-dual-h-bridge-dc-motor-driver-for-robot-smart-car-green-154444#.U-Ppevl_tK0 gives useful info of the board itself, while https://www.sparkfun.com/datasheets/Components/General/L298N.pdf is the datasheet of the IC L298N

@Yan - there is an error in your question, "12V (6xAA batteries)" must be incorrect. 6 x 1.5V AA batteries, ordinary 'dry' cells, would be 9V, and 6 x 1.2V rechargeable ( e.g. NiMh) would be 7.1V. So do you have more than 6 batteries, or is the voltage lower than 12V?

Here is a link to a robotoid page which describes a way to use it.
Here is a link to funnyrobotics which explains how to use it.
I am confident that you could use a search engine to find more examples.
One trick is to use image search. Then look for pictures which look like your photo, and which have extra writing on them. Most people who add labels and writing to the photo are writing to help beginners understand how to use something.
Edit:
That L298N board claims to have a 5V regulator for powering the Arduino, in which case you could use a single power supply, and let the motor board feed the Arduino.
There are two schools of thought on powering the Arduino and motors:

Use two separate power supplies, one for the motor and one for the Arduino.
Use one supply for both the motor, and Arduino.

Using one supply is simple overall. One concern is electric motors can create a lot of electrical noise. If this is not adequately filtered, it might get injected into the Arduino and maybe cause the microcontroller to reset, or become temporarily unstable. The single supply advocates say the power supply to the Arduino should be properly filtered using capacitors and a proper voltage regulator usually, and the problem is solved.
I agree in principle. However, I have seen situations where the transient failure was so brief it looked 'mysterious'. It took time and effort to track it down. Sometimes it was because the motor power supply was underpowered. When the motor 'stalled', for example when changing direction, taking maximum current, the power supply voltage might dip enough to cause the Arduino supply to dip, and reset the chip.
Summary, if you are going to use a single power source for both motor and Arduino, ensure it has plenty of electrical noise filtering, and is a bit over-engineered to cope with the motor stalling. Specifically, it should be able to supply the motors stall current without dipping too low for the Arduino. The 'professional' approach is to have the Arduino monitor the main power supply, and detect that voltage dip. However, that is more complexity, and I suggest you avoid that.
Edit: If you are concerned you might have weird, hard to trace problems, using a single supply, try to design the system so that the Arduino can be 'unplugged' and given its own supply. That should be easy to do with that L298N board as the connections are screw terminals.
Using two separate power supplies should reduce the chances of electrical noise from the motors getting into the Arduino. In some circumstances is it useful to be able to change the motor power supply, or switch it off, without powering the Arduino off.
When the motor voltage is a lot higher than the 5V needed by the arduino, simple techniques to step down the voltage (linear regulators, like the part on that L298N board) convert the excess power to heat, which is quite inefficient. Much above, about, 18V it can generate enough heat to reach quite a high temperature (i.e. 100C) unless it has a good heatsink.
In that case, a simple, cheap solution is to use a second small power supply for the Arduino. An Arduino is likely using under 100mA, so a PP3 would be okay for, maybe, a few hours. A longer term approach is to step the motor voltage down efficiently.
If you use two power supplies, connect the two 'ground' (i.e. or most negative battery connections) together so that they have a common 'ground' reference. That way the Arduino signals will control the motor driver reliably.
Edit:
PWM does not step down voltage. It gives the illusion of less power because the full voltage is only applied for a fraction of each millisecond. When it is on, it is providing (very close to) the full 'motor' voltage. If the 'motor voltage' connected to that L298N board is 12V, then the motor will see 12V.
However, even if the motor is rated at only 3volts, it is unlikely to break only because 12V is applied across it. A 3V motor is as likely to break because it gets too hot, or spun too fast (e.g. the bearings get damaged).
It will likely get too hot under load, or spin too fast if the PWM signal is on for more than, WAG 50% of the time (but there is no warranty with WAG = Wild-A$$-Guess).
If, and only if, your software doesn't run PWM more than 50%, then those motors may be okay. That is a risk I might be prepared to take if the motors are cheap, and replacements easy to get.
Skimming the datasheet, the L298N needs an absolute minimum motor supply of 2.3V+2.5V = 4.8V.
Also, the output switches which control the motor appear to 'drop' a minimum of 1.8volts.
So I think it would be okay with 6V or 7.2V (maybe upto 9V) motor voltage.
IIRC the arduino will work okay with 7.2V upwards, i.e. 6 x NiMh batteries. A higher voltage is just converted to heat by the on-board voltage regulator. I might be tempted to experiment with the L298N boards 5V output, unless you have seen complaints about it.
I am assuming the motors are brushed DC motors (and not steppers or something exotic)
The motor driver will handle switching the current that the motor needs. However, each time the current is switched on or off, the motor will draw current, or generate current (remember it is a motor and also a generator). That could cause the power rail to dip, or even feed current into power or ground. There are diodes on the board to prevent those spikes doing anything awful to the chip, but there is still current flowing through wires.
Further, every rev of the motor, the brushes will break one connection, and make a different connection with the commutator, typically 6 times. (The commutator is the mechanical system that directs the current to flow the correct way round in the motors spinning electromagnet). That creates electrical noise. In some cases so much that you can hear it on an old fashioned radio receiver or analogue TV.
So noise may be a problem. People typically put a 10nF-100nF, relatively high voltage (say 50V), capacitor directly across the motors power connections, at the motor end.
If things get bad, I did a quick search and this blog looked okay, it illustrates ways to use capacitors and inductors to reduce motor noise.
I wouldn't worry too much. Put 10nF-100nF across the motor wires, and see what happens.

Thanks for the reply.  I updated my question and it's 8 AA batteries not 6.  I seen these tutorials and i am able to get the motors running but i am new to electronics and wanted to know the logistics behind connecting motors to the driver and arduino plus stepping down voltage and effect on the driver chip.  Also i don't think any of these tutorials talked about powering the arduino itself.  I am not sure it is assumed that is powered from USB or need a separate power source

Thank you very much!!! This is exactly the information i was looking for which was not included in the other tutorials.  This greatly helps me to continue on with the project.  If don't mind i updated the question with few more questions that i want to ask you.  Either way i am accepting the answer :) Have a great day!

This is a severely underappreciated answer.


text:
How can I use the SerialIP library on my Arduino through a Mac?
I am looking into using the SerialIP library to connect my Arduino to the internet through it's USB connection to my computer.
However, I cannot figure out how to establish the SLIP connection to the Arduino from my Mac.
The library's documentation says:

Perhaps the most difficult part of using this library is figuring out
  how to establish the SLIP connection to the Arduino.

It suggests the use of:
sudo slattach -L -s 115200 -p slip /dev/ttyUSB0

On linux systems. However, on my Mac running OS X 10.10, there is no such command.
I ran into this thread on the Apple forums regarding the missing slattach command, which sounds like it was removed in OS X 10.6.
How can I use the SerialIP Arduino library on my Mac?

You might see if there is a homebrew or macports version of that?