body:
I'm using a 12v fan and 12v LED modules in my project, so I need about 400mA by their combined specs. I have a 12.6v dc regulated power source that can give ~700mA I wish to use, and since it has a rather small form factor I would also like to power my Arduino Diecimila with it. I'm using PWM from pins 10 and 6 to go through N-channel MOSFETs in order to control both the LEDs and the fan. Anyway, in the Arduino Diecimila board page it says the recommended voltages are between 7-12v, and beyond that it can handle 6-20v, but it might cause the voltage regulator to heat too much, which might damage the board. So, my question is that: will 12.6v really damage my board, or is it within some margin of error? The actual voltage I got when I checked my power supply was 12.55V. Can I maybe just dial it down a bit somehow?

Thanks in advance,

UriSh.

title: Will 12.6v really damage my arduino?

Answers: 1

body:
As you have already noticed, it may cause the 5V regulator to get hotter than would be normally considered reasonable.  However, how hot depends entirely on how much current your board is drawing (not including the 12V devices)- the more current you draw the hotter it will get.

Even at 12V it can get uncomfortably hot.

For running off voltages greater than about 9V I usually recommend using an external 5V switching regulator.  These can be easily and cheaply obtained under the name "UBEC" (Universal Battery Elimination Circuit) and are used extensively in the model aircraft arena.  They don't get hot, can handle large currents, and don't waste power like the on-board linear regulator does.

So you'd connect that to your 12.6V supply, then the 5V output of the UBEC (make sure you get a 5V one) would go straight to the 5V pin of the Arduino, and you wouldn't connect the barrel jack or Vin to anything.

You can also pick up cheap switching regulators on eBay - some are adjustable, so you'd want to make sure you adjust it to 5V first before connecting the Arduino, or if you can adjust it to around 7V then you could power the Arduino through the barrel jack (or Vin) with it and avoid too much heat from the on-board linear regulator.


body:
I have recently started working on esp8266 wifi module and arduino uno.
I am a little confused.

I have created a small Web page with esp8266 AT commands.
Now I want use it for receiving data such as changes on the Arduino inputs.

I have seen many similar implementations using jQuery for that purpose,
but I don't know where to place that jQuery file.

Furthermore, is it possible to use NODEMCU firmware and still toggle arduino pins and transmit data to esp8266?

I want to use Arduino for:

  * reading voltage levels
  * publish the values read to the Web page
  * toggle a relay when a button on the Web page is pressed.

Please kindly help me out or point me in the right direction to search

title: NODEMCU vs AT for esp8266

Answers: 1

body:
This is quite a huge topic to cover in one answer, but I will do my best.

The NodeMCU can be used in three distinctly different ways.  First is the *AT* mode, where you have installed the *AT* firmware.  In this mode the NodeMCU is purely a slave device to the Arduino.  Once you have got the Arduino to configure the NodeMCU in the right way to receive data on a socket it will send that data back to the Arduino verbatim through the serial port with special tags added (indicating what the data is, and which socket it arrived on, etc).  It is then up to you to receive that data, interpret it in whatever way you desire (as a HTTP GET request most likely) and craft the correct response (if any) and send it to the NodeMCU to send back (again using the *AT* commands).

What you send through the socket is entirely up to you.  By the sounds of things you will be making a simple GET request from a web browser to perform an operation, and maybe respond with some data to display in the web page.  That can be easy, or it can be hard - it's as hard as you want to make it.  The simplest way is to rely on an external web server to serve the main content and structure of the page, then use jQuery or Prototype to make an AJAX call to your NodeMCU and receive back any data there may be.  In this case everything will be on your external web server except the single (or few) URL(s) that perform operations and return data.  That includes the jQuery (which is just Javascript, it's loaded from your web server into the browser and executed), any code for buttons, images, HTML, everything (on the web server, that is).

The other two ways the NodeMCU can operate are both very different to that.  They differ mainly in the language that is used with them.  You can use the NodeMCU with its own LUA language to get it to do almost anything you want.  That includes receiving the HTTP GET request and serving the data for it, all without the help of the Arduino.  In fact, doing that, there is little need for the Arduino any more - the NodeMCU has an analog input and multiple digital IO lines - it also has SPI available for interfacing with external ADC chips if you want more than one analog input.  So you can have everything internal to the NodeMCU without needing the Arduino at all.  If you do want to keep the Arduino then you can interface to it through the serial port (as you would in *AT* mode) but using your own custom protocol in whatever way you see fit.

The third way is to program the NodeMCU as if it were itself an Arduino.  There is an ESP8266 core for the Arduino IDE (and for [UECIDE Beta](http://uecide.org/beta) as well) which allows you to program the NodeMCU in the same language and with a similar API, as the Arduino.  This even more removes the need for the Arduino.  You can get the Arduino core from Github here: https://github.com/esp8266/Arduino

Incidentally, the Xtensa core in the ESP8266 is considerably more powerful than your typical Arduino, being 32-bit, having its own DSP, and with much more RAM and Flash memory.  It kind of makes the Arduino redundant.


body:
Following configuration:

- Arduino UNO R3
- Real Time Clock DS1307RTC
- LCD1602 Shield with buttons
- Photo resistor
- DHT11 (Temp & Humidity Sensor)

I need the function delay(1000) to display the seconds properly from the RTC to the LCD.
But, that way I always have to keep the buttons pressed for up to 1 second until they react.

How can I workaround or solve this problem?

Idea 1: Multitasking would come in handy here :-) pseudocode:

    task 1: listen for LCD buttons
    task 2: display seconds with a delay of 1000ms

But there isn’t a way Arduino could multitask, isn’t it?

Idea 2: As far as I saw in the header files for the RTC, the smallest readable unit is seconds. Otherwise I could have used something like a millisecond reader in a while condition to listen for the buttons; pseudocode:

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

    while (RTC-millisecond < 1000ms) {
     // listen for buttons
        // so a second passes, which gives the RTC time to display the seconds values
    }

-

**EDIT**

updated code, thanks to @NickGammon and Gerben:

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

    #include <LiquidCrystal.h>
    #include <Wire.h>
    #include <Time.h>
    #include <DS1307RTC.h>
    #include <DHT.h>

    // initialize the library with the numbers of the interface pins
    //                RS  E  D4 D5 D6 D7 (maybe wrong order)
    LiquidCrystal lcd(8, 9, 4, 5, 6, 7);

    // pins on which the sensor is connected
    #define DHTPIN A1
    #define PHOTOPIN A2

    // initialize DHT sensor
    #define DHTTYPE DHT11
    DHT dht(DHTPIN, DHTTYPE);

    // define some values used by the panel and buttons
    int lcd_key     = 0;
    int adc_key_in  = 0;
    //#define btnRIGHT  0
    //#define btnUP     1
    //#define btnDOWN   2
    //#define btnLEFT   3
    //#define btnSELECT 4
    //#define btnNONE   5

    // FSM
    unsigned long previousMillis1 = 0;
    unsigned long previousMillis2 = 0;
    const long interval = 3000;

    // prototypes
    void print2digits(int number);
    int read_LCD_buttons();

    void setup() {
      // open a serial connection to display values on PC
      Serial.begin(9600);

      // set up the number of columns and rows on the LCD
      lcd.begin(16, 2);

      // start DHT sensor
      dht.begin();
    }

    void loop() {
      // set variable from struct tmElements_t
      tmElements_t tm;

    /********* Reading from sensors *********/
      /*** DHT sensor ***/
      // Reading temp or RH takes about 250 milliseconds!
      // Sensor readings may also be up to 2 seconds 'old' (its a very slow sensor)
      float humid = dht.readHumidity();
      float tempC = dht.readTemperature();
      // Check if any reads failed and exit early (to try again).
      if (isnan(humid) || isnan(tempC)) {
        lcd.clear();
        lcd.setCursor(0, 0);
        lcd.print("DHT reading failed!");
        Serial.println("DHT reading failed!");
        return;
      }
      // Compute heat index in Celsius (isFahreheit = false)
      float hiC = dht.computeHeatIndex(tempC, humid, false);

      /*** Photo resistor ***/
      int lightReading = analogRead(PHOTOPIN);

    /********* Print to PC over serial connection *********/
      // ...

    /********* Print values to LCD *********/
      /* --- first line on LCD --- */
      /*** RTC ***/
      // set the cursor to LCD column 4, line 0 to center the clock
      lcd.setCursor(4, 0);

      // starts RTC reading and checks if it's working
      if (RTC.read(tm)) {
        static byte oldSecond = 60; // 60, because there is no 60'th second in a clock
        // display only if time changes
        if (tm.Second != oldSecond) {
          oldSecond = tm.Second;
          print2digits(tm.Hour);
          lcd.print(':');
          print2digits(tm.Minute);
          lcd.print(':');
          print2digits(tm.Second);
        }
      }
      else {
        lcd.clear();
        lcd.setCursor(0, 0);
        if (RTC.chipPresent()) {
          lcd.print("Please run SetTime function");
        } else {
          lcd.print("DS1307 read error!");
        }
        delay(9000);
      }

      /* --- second line on LCD according to button --- */
      lcd_key = ((lcd_key + read_LCD_buttons()) %3);  // call button function, modulo 3 to cycle through
        /** // Test buttons:
        lcd.setCursor(1, 1);
        lcd.print("lcd var:");
        lcd.print(lcd_key); */

      unsigned long currentMillis = millis(); // FSM used for displaying DHT and photo values without flikering

      switch (lcd_key) {
        case 0:
          /*** Weekday and Date ***/
          // display only if day changed
          static byte oldDay = 99;
          if (tm.Day != oldDay) {
            oldDay = tm.Day;
            lcd.setCursor(0, 1);
            lcd.print("                "); // 16 spaces to clear second line before printing
            lcd.setCursor(0, 1);
            //lcd.print(dayShortStr((weekday() + 1) % 7 )); // (day+1)%7 calculation for Swiss layout
            lcd.print(tm.Wday); // TEST
            lcd.print(weekday()); // TEST
            lcd.print(", ");
            print2digits(tm.Day);
            lcd.print('.');
            print2digits(tm.Month);
            lcd.print('.');
            lcd.print(tmYearToCalendar(tm.Year));
          }
          break;

        case 1:
          /*** DHT Sensor ***/
          if (currentMillis - previousMillis1 >= interval) {
            previousMillis1 = currentMillis;
            lcd.setCursor(0, 1);
            lcd.print("                "); // 16 spaces to clear second line before printing
            lcd.setCursor(1, 1);
            lcd.print(hiC);
            lcd.print("*C ");
            lcd.setCursor(10, 1);
            lcd.print(humid);
            lcd.setCursor(12, 1);
            lcd.print("%RH ");
          }
          break;

        case 2:
          /*** Photo resistor ***/
          if (currentMillis - previousMillis2 >= interval) {
            previousMillis2 = currentMillis;
            lcd.setCursor(0, 1);
            lcd.print("                "); // 16 spaces to clear second line before printing
            lcd.setCursor(0, 1);
            lcd.print("Light ");
            lcd.setCursor(6, 1);
            lcd.print(lightReading);
          }
          break;
      }
    }

    // used to print 2 digits in the time values
    void print2digits(int number) {
      if (number >= 0 && number < 10) {
        lcd.print('0');
      }
      lcd.print(number);
    }

    // read the buttons
    int read_LCD_buttons() {
      adc_key_in = analogRead(0);
      //if (adc_key_in > 1000) return btnNONE; // 1st option since it will be the most likely result (speed reasons)
      //if (adc_key_in < 50)   return btnRIGHT;
      //if (adc_key_in < 195)  return btnUP; // replaced by below one
      if (adc_key_in < 195)  return 1; // my button up !
      //if (adc_key_in < 380)  return btnDOWN;
      //if (adc_key_in < 555)  return btnLEFT;
      //if (adc_key_in < 790)  return btnSELECT;
      //return btnNONE;  // when all others fail, return this...
      return 0;
    }

title: Delay workaround needed for RTC and LCD-shield buttons

Answers: 2

body:
You need to learn a different way of programming.

Two things you need to understand:

1. Non-blocking code.  Read and understand the BlinkWithoutDelay example sketch (in the Arduino IDE's File -> Examples menu)
2. Finite State Machines.  Stop thinking purely linear, and start thinking about the different states your program can be in at any one time.

Once you have those cracked you'll be an Elite Arduino Programmer (EAP™).

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

      // clean up screen before printing a new reply
      lcd.clear();

      /* --- first line on LCD --- */
      /*** RTC ***/
      // set the cursor to LCD column 4, line 0 to center the clock
      lcd.setCursor(4, 0);

Straight away, that will cause flicker, right? For a few milliseconds the screen will go blank, and then get gradually redrawn. Why not omit the clear? You could put it in if you are changing display types (eg. from date to temperature) but you don't need to clear the screen every time. So:

* Don't call `delay()`

* Don't clear the screen unless changing to displaying a different type of thing

* Only update the display at all if the new number (or time, or temperature, etc.) is **different** from what you just displayed.

* Just do the `setCursor()` to position the cursor and **overwrite** the information there previously.

* Preferably follow by a space or two in case a large number is replaced by a smaller one.

---

Side-benefit: Since you have removed the delay, your project will now be much more responsive to key presses. Win win!

---

## References

* [State machines](http://www.gammon.com.au/statemachine)

* [How to do multiple things at once ... like cook bacon and eggs](http://www.gammon.com.au/blink)

---

>  I am not quite sure how to do it

     if (RTC.read(tm))
      {
      static byte oldSecond = 99;
      // display if time changes
      if (tm.Second != oldSecond)
        {
        oldSecond = tm.Second;
        print2digits(tm.Hour);
        lcd.print(':');
        print2digits(tm.Minute);
        lcd.print(':');
        print2digits(tm.Second);
        }
      }

Similarly further down where you display the date / sensor.


body:
I have two arduinos (uno) and I would like to send the results of a key press on a 5X4 matrix pad to the other arduino. The matrix keypad works great. I can identify which key was pressed with a switch function.

    switch (keypad())
    //switch used to specify which button
         {
          case 0:
            Serial.print("Key A Pressed");
            Serial.print(keypad());
            messageToSend = 0;
          break;
            case 1:
            Serial.print("Key B Pressed");
            Serial.print(keypad());
            messageToSend = 1;
          break;
            case 2:
            Serial.print("Key C Pressed");
            Serial.print(keypad());
            messageToSend = 2;
          break;
           }

My RF units are both nrf24l01. I have tried working with the sample code and I think the issue is I don't understand how the unit works well enough.

 1. What is the nature of the data sent between units? I want to send
    integers, possibly even text. Is that possible? Do I need to convert
    to binary or something?

 2. My understanding of "ping" and "pong" is that ping sends a message
    then pong sends that same message back to ping... is this correct?

 3. Are RF units very different? Is this one particularly difficult?

 4. If I just want to send with one receive with the other shouldn't
    this simplify the code?

 5. What are pipes? How many can I open?

 6. If I have 3 or more of these what changes will I need to make to the
    code?

Thanks!

title: Need help understanding how RF communication works with 2 arduinos

Answers: 2

body:
Many questions so broad answers, but hopefully informative for your research

 1. >What is the nature of the data sent between units? I want to send integers, possibly even text. Is that possible? Do I need to convert to binary or something?

It depends broadly on what you use. If you use an ethernet peripheral then the communications will be entire ethernet packets with whatever protocol stack you have above it in payload. For simple RF communication modules it may be as simple as a serial stream delivered 8 bits at a time. The simplest rf (buzzer-style) would simply interrupt (or drive a pin high) when the transmitter is sending a signal.

In Your case the transmitter uses an addressed protocol with a payload packet of between 1 and 25 Bytes of data. This means that you will need code to read and store the necessary payload, maintain configuration data and keep track of addresses of the other systems to message. You also need to poll (or handle interrupts from) the rf module to make sure there aren't messages from the transmit node.

How you convert the data is up to you, a string can be represented by a sequence of bytes and can be send and read as a string on the receivers end. Your rf module will deliver you data in 1-25 byte chunks, what you send in that chunk and how to encode it is entirely up to you.

On the low level,the way this module is configured, the MCU sends data into the rf ic using a serial protocol, the module incorporates a buffer to allow the MCU (slow - 8 bit) to send the data and not have to keep up with the 1Mbps throughput of the rf. On a physical level the signals of the chip look thus:

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

2. >My understanding of "ping" and "pong" is that ping sends a message then pong sends that same message back to ping... is this correct?

Ping Pong is a game and not a well defined technical term. For precision you can define ping-pong as an ``echo`` where the transmitter effectively acknowledges the message by re-transmitting it back to you.

3. >Are RF units very different? Is this one particularly difficult?

RF units can be very different depending on what high level protocol they offer. This unit is somewhere half way between full blown wifi and simple and modulated RF communications. It gives you addressing and error correction as well as a robust communication scheme

This particular unit is made to be relatively "modern", it uses [GFSK](https://en.wikipedia.org/wiki/Gaussian_frequency-shift_keying) - a frequency modulation scheme -to transmit and receive data to uniquely addressable nodes on a number of channels. At 2.4 GHz it is high throughput, [legal](https://en.wikipedia.org/wiki/ISM_band).  It is not the simplest toy.

In terms of simplicity, this module has a lot of examples and documentation, given that it has an arduino library it has a high likelihood of working and succeeding, but you will need to use more advanced microcontroller features to fully utilize the device (e.g. interrupts, DMA).

For other RF options there are lots of things to consider. Going up to wifi requires you to maintain a much more complex stack, meaning more processing power and code, if you want to offer TCP/IP services (say webserver) it is even more code but can be done on an 8 bit arduino. Going down to simpler protocol may win you less power and simpler code but a headache to expand.

 4. >If I just want to send with one receive with the other shouldn't this simplify the code?

You will still need to implement both a receiving and a transmitting application so the work is still all there, it will simplify the higher level logic into separate application which is easier.

5. >What are pipes? How many can I open?

I see nothing about pipes from a cursory glance at the docs, perhaps you can illuminate more on what you are confused about?

In general pipes are a "hole" where an application (in the broadest sense) can stream data and it will be consumed by whoever is on the other end, a black hole of a serial data stream. You can implement a pipe as a high level software construct that will buffer and consume data from peripherals and wait to send it out the RF transmitter, it may also be implemented on a hardware level with discrete buffers and additional logic around the rf transmitter etc. As a conceptual element you can probably use a "pipe" concept for communication between the different devices in your code (e.g. move byte to pipe 1 for device 1, move byte to pipe 2 for device 2, let the "driver" handle order), this is a design paradigm that makes software development easier.

6. >If I have 3 or more of these what changes will I need to make to the code?

The rf module is fully capable of addressing up to 65,536 unique hosts, so the device is fully ready to talk to 3 of your hosts, however the software logic needs to track the addresses and other comms data about each host as well as process the data for them (if its different) in enough time.

If you are expecting this in advance, good design decisions early on (e.g. small API or library) will make this much easier on yourself to add features in the future.

***Final Thought***

If you need a simple echo, this may be a bit overkill for your system, however it is relatively powerful and may make it easier for you to program since you can work with "real-world" data units and send multiple byte packets easily.

I would **highly recommend** you read and understand the [datasheet](https://www.sparkfun.com/datasheets/IC/nRF2401A.pdf) for the RF chip, be thankful that the nice library takes care of the messy details for you, but understanding how it works will certainly help you understand how to use it best.

An 8 bit Atmega may not be powerful enough to process and transmit 3 separate streams together (if they are identical its less difficult) if you require a constant high rate transmission or if you do a significant amount of processing on the arduino before sending you will feel the limitations of the chip and a 32 bit board may be worth looking at.

  [1]: https://i.stack.imgur.com/2yKFf.png

body:
> My RF units are both nrf24l01. I have tried working with the sample
> code and I think the issue is I don't understand how the unit works
> well enough.

[Start here, this is the absolutely best resource][1] I could find. I use MIRF libary and there are [send and receive examples][2].  They are really, really simple. Get them working first.

> What is the nature of the data sent between units? I want to send
> integers, possibly even text. Is that possible? Do I need to convert
> to binary or something?

*Technically*, you send between 1 and 32 *bytes* of information. However, the libraries (see examples above) will take care of the technicality and allow you to send nums, chars or strings.

> My understanding of "ping" and "pong" is that ping sends a message
> then pong sends that same message back to ping... is this correct?

Not necessarily. Since [tag:NRF24L01+] does all the signal checking for you, and you know that your TX device is the only one sending, you can just reply with "data received".

Anyways, why are even concerned with this? Pinging and ponging have nothing to do with your task at hand.

> Are RF units very different? Is this one particularly difficult?

Yes, they are different in frequencies, protocols, power etc. No, this one isn't. It's an amazing, cheap and robust piece of Norwegian ingenuity.

> If I just want to send with one receive with the other shouldn't this
> simplify the code?

Simplify compared to what exactly? It will simplify the code compared to a two-way communication, obviously.

> What are pipes? How many can I open?
As someone said before me, read the bloody manual, or a tutorial, or the data sheet, or something. The answer is 6.

Any unit can send on ONE pipe and receive on SIX pipes. Imagine having 6 phones on your table. You can simultaneously listen to all 6 phones but you can only TALK INTO ONE. You can choose which one to talk into to, at any point. Unless you have a lot of devices talking to each other (more than TWO), don't bother, forget the pipes.

> If I have 3 or more of these what changes will I need to make to the
> code?

Get two Arduinos talking to each other first. No one has succeeded at making anything work by getting ahead of themselves.

Now here is [a video of two Arduinos talking][3]. There's only one button but you can easily change it to a 20-button setup.

The code for sending:

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

    #include <SPI.h>
    #include <Mirf.h>
    #include <MirfHardwareSpiDriver.h>
    #include <MirfSpiDriver.h>
    #include <nRF24L01.h>

    const int buttonPin = 2;
    const int ledPin =  3;

    // sends a string via the nRF24L01
    void transmit(const char *string)
    {
      byte c;

      for( int i=0 ; string[i]!=0x00 ; i++ )
      {
        c = string[i];
        Mirf.send(&c);
        while( Mirf.isSending() ) ;
      }
    }

    void setup() {
      //RADIO
      Serial.begin(9600);
      Mirf.spi = &MirfHardwareSpi;
      Mirf.init();
      Mirf.payload = 1;
      Mirf.channel = 90;
      Mirf.config();
      Mirf.configRegister(RF_SETUP,0x06);
      Mirf.setTADDR((byte *)"serv1");

      //BUTTON AND LED
      pinMode(buttonPin, INPUT_PULLUP);
      pinMode(ledPin, OUTPUT);

      Serial.println("Sending ... ");
    }

    void loop() {
      int buttonState = digitalRead(buttonPin);
       if (buttonState == LOW) { //pressed
        digitalWrite(ledPin, HIGH);
        transmit("X");
      }
      else {
        digitalWrite(ledPin, LOW);
      }
    }

The code for receiving:

    #include <SPI.h>
    #include <Mirf.h>
    #include <MirfHardwareSpiDriver.h>
    #include <MirfSpiDriver.h>
    #include <nRF24L01.h>

    unsigned long lasttime;
    unsigned long delaytime;
    unsigned long time;
    const int ledPin = 3;

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

      //RADIO
      Mirf.spi = &MirfHardwareSpi;
      Mirf.init();
      Mirf.setRADDR((byte *)"serv1");
      Mirf.payload = 1;
      Mirf.channel = 90;
      Mirf.config();
      Mirf.configRegister(RF_SETUP,0x06);

      //LED
      pinMode(ledPin, OUTPUT);
      digitalWrite(ledPin, HIGH);
      Serial.println("Listening ... ");
    }

    void loop() {
      byte c;

      if( Mirf.dataReady() ) {
        Mirf.getData(&c);
        Serial.write(c);

        if (c == 'X') {
          digitalWrite(ledPin, HIGH);
        }
      } else {
          digitalWrite(ledPin, LOW);
      }
    }

  [1]: https://arduino-info.wikispaces.com/Nrf24L01-2.4GHz-HowTo
  [2]: https://arduino-info.wikispaces.com/nRF24L01-Mirf-Examples
  [3]: https://www.youtube.com/watch?v=plDPBVjcckw


body:
I have been using a library to control a LED Strip with buttons. My current code does not execute properly. It skips the if statement and just runs the code in a loop with no regard to the button and I'm uncertain why. I'm using an Arduino Uno with an LPD8806.

    #include "LPD8806.h"
    #include "SPI.h" // Comment out this line if using Trinket or Gemma
    #ifdef __AVR_ATtiny85__
    #include <avr/power.h>
    #endif

    int nLEDs = 160;

    // Chose 2 pins for output; can be any valid output pins:
    int dataPin  = 2;
    int clockPin = 3;

    // First parameter is the number of LEDs in the strand.  The LED strips
    // are 32 LEDs per meter but you can extend or cut the strip.  Next two
    // parameters are SPI data and clock pins:
    LPD8806 strip = LPD8806(nLEDs, dataPin, clockPin);

    int inPin = 4;
    boolean lastState = LOW;//storage for last button state

    void setup(){
       pinMode(inPin, INPUT);//this time we will set the pin as INPUT
       Serial.begin(9600);//initialize Serial connection
       #if defined(__AVR_ATtiny85__) && (F_CPU == 16000000L)
       clock_prescale_set(clock_div_1); // Enable 16 MHz on Trinket
       #endif

       strip.begin();
       // Update the strip, to start they are all 'off'
       strip.show();

     }

    void loop(){

       if (digitalRead(inPin) == HIGH && lastState == LOW){//if button has just
       been pressed
       // Start up the LED strip
            theaterChase(strip.Color(127, 127, 127), 50); // White
            delay(100);
        } else if(digitalRead(inPin) == LOW && lastState == HIGH){
            digitalWrite(dataPin, LOW);
            digitalWrite(clockPin, LOW);
        }
        lastState = digitalRead(inPin);
        }

        //Theatre-style crawling lights.
        void theaterChase(uint32_t c, uint8_t wait) {
             for (int j=0; j<10; j++) {  //do 10 cycles of chasing
                  for (int q=0; q < 3; q++) {
                       for (int i=0; i < strip.numPixels(); i=i+3) {
                          strip.setPixelColor(i+q, c);    //turn every third pixel on
          }
          strip.show();

          delay(wait);

          for (int i=0; i < strip.numPixels(); i=i+3) {
          strip.setPixelColor(i+q, 0);        //turn every third pixel off
          }
        }
      }
      }

title: Toggle Button For LED Strip not executing properly

Answers: 1

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

If you have just connected a switch to the Arduino pin, like the image below, it will just return "random" undefined results:

[![Floating input on switch][1]][1]

There are various ways of avoiding this, including using a pull-down resistor to ensure that, if the switch is open, it will read LOW. For example:

[![Pull-down resistor][2]][2]

There are other possible techniques as discussed on [this page](http://gammon.com.au/switches).

One is to change:

       pinMode(inPin, INPUT);//this time we will set the pin as INPUT

to:

       pinMode(inPin, INPUT_PULLUP);//this time we will set the pin as INPUT

Then wire the switch to **ground**, not +5 V. That way the pull-up resistor pulls the switch HIGH, and when you close the switch it is LOW.

  [1]: https://i.stack.imgur.com/dbixU.png
  [2]: https://i.stack.imgur.com/eYepo.png


body:
My code is designed to play a tone when ever pin 3 is high on my Arduino. When I am examine the pins voltage with a multimeter it is always reading below 1 volt. When I examined the voltage off of a osiliscope it is reading the voltage pretty steady at 0.2 to 0.3.

**My multimeter reads at 0.26**

[![][1]][1]:

**My code is:**

    void setup() {
      // put your setup code here, to run once:
    Serial.begin(9600);
    }
    void loop() {
      // put your main code here, to run repeatedly:
    int input = digitalRead(3);
    Serial.println(input);
    if(input == 1){
      tone(A5,4000);
      }
    }

**My board looks like:**
[![enter image description here][2]][2]
**The bottom of the board looks like:**
[![enter image description here][3]][3]

  [1]: https://i.stack.imgur.com/VDZrq.jpg
  [2]: https://i.stack.imgur.com/WxcKw.jpg
  [3]: https://i.stack.imgur.com/VmlpH.jpg

title: Arduino LED lighting up when signal is reading low on multimeter

Answers: 1

body:
You left pin 3 floating. The multimeter will lower the voltage, resulting the the led lighting. Try enabling the pull-up resistor in pin 3 by adding `pinMode(3, INPUT_PULLUP)`.

PS you might want to add a resistor in series with that led, or it will burn out and/or damage pin 3 on the arduino.


body:
I want to read the SMS using Arduino and GSM module, I want to perform conditional programming based on the received SMS.

What I found really interesting is SMS format is different if I send message from different phones.

Output of my code is

Case 1:(From a smartphone)

Mobile Number is: +91954xxxxxxx
Message Text: 5+22" Hello Arduino

Case 2:(From a normal phone)

Mobile Number is: +91984yyyyyyy
Message Text: Hello Arduino

----

Does it really depend on the sender's mobile phone? If yes, how to move further to make my code independent on the sender mobile.

----
My code is

    //===final code

    char RcvdMsg[200] = "";
    int RcvdCheck = 0;
    int RcvdConf = 0;
    int index = 0;
    int RcvdEnd = 0;
    char MsgMob[15];
    char MsgTxt[50];
    int MsgLength = 0;

    void Config() // This function is configuring our SIM900 module i.e. sending the initial AT commands
    {
       delay(1000);
       Serial.print("ATE0\r");
       Response();
       Serial.print("AT\r");
       Response();
       Serial.print("AT+CMGF=1\r");
       Response();
       Serial.print("AT+CNMI=1,2,0,0,0\r");
       Response();
    }

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

    void loop()
    {
       RecSMS();
    }

    void Response() // Get the Response of each AT Command
    {
       int count = 0;
       Serial.println();
       while(1)
       {
          if(Serial.available())
          {
             char data =Serial.read();
             if(data == 'K'){Serial.println("OK");break;}
             if(data == 'R'){Serial.println("GSM Not Working");break;}
          }
          count++;
          delay(10);
          if(count == 1000){Serial.println("GSM not Found");break;}

       }
    }

    void RecSMS() // Receiving the SMS and extracting the Sender Mobile number & Message Text
    {
       if(Serial.available())
       {
          char data = Serial.read();
          if(data == '+'){RcvdCheck = 1;}
          if((data == 'C') && (RcvdCheck == 1)){RcvdCheck = 2;}
          if((data == 'M') && (RcvdCheck == 2)){RcvdCheck = 3;}
          if((data == 'T') && (RcvdCheck == 3)){RcvdCheck = 4;}
          if(RcvdCheck == 4){RcvdConf = 1; RcvdCheck = 0;}

          if(RcvdConf == 1)
          {
             if(data == '\n'){RcvdEnd++;}
             if(RcvdEnd == 3){RcvdEnd = 0;}
             RcvdMsg[index] = data;

             index++;
             if(RcvdEnd == 2){RcvdConf = 0;MsgLength = index-2;index = 0;}
             if(RcvdConf == 0)
             {
                Serial.print("Mobile Number is: ");
                for(int x = 4;x < 17;x++)
                {
                   MsgMob[x-4] = RcvdMsg[x];
                   Serial.print(MsgMob[x-4]);
                }
                Serial.println();
                Serial.print("Message Text: ");
                for(int x = 46; x < MsgLength; x++)
                {
                   MsgTxt[x-46] = RcvdMsg[x];
                   Serial.print(MsgTxt[x-46]);
                }

                Serial.println();

                //****Resetting all the variables*****//

                //RcvdMsg[200]={0};
                RcvdCheck = 0;
                RcvdConf = 0;
                index = 0;
                RcvdEnd = 0;
                MsgMob[15];
                MsgTxt[50];
                MsgLength = 0;

                Serial.flush();

             }
          }
       }
    }

title: Does SMS format depend on the sender's mobile?

Answers: 1

body:
If you're not trying to capture the mobile number or whatever SMS text was sent, but only react to specific SMS messages, then don't try to parse the whole message, but design the protocol between any arbitrary phone and your Arduino to be detectable independent of everything else, e.g.:

    #L 5 on        ; set an LED state

    #M 3 137       ; set a motor speed


body:
I have an Arduino Uno. The story is I installed Arduino IDE and Drivers before even buying an Arduino Board. I used it a little and when I bought and connected an arduino board, I was unable to make it detect. I smacked a little usimg google and was able to somehow Fix this. but again another day, It worked a little and started creatimg problems. now its not detecting. Please suggest me a way To make it work...
Should I format my windows 7 and Reinstall all the drivers as per rules?

title: Arduino Uno not Detecting on Laptop

Answers: 1

body:
under the IDE make sure you have set the correct board and comm port. go to tools>>board then choose your board then tools>>Comm to choose the correct comm port.

is the IDE saying anything about having problems connecting to the board?

and no re-installing all drivers should not be necessary.


body:
I have an Arduino Mega2560 and a Raspberry Pi hooked up through I2C. The Pi is acting as the master, while the Arduino is the slave. While sending data over I2C, the int message gets messed up and will either send the address or the data. Then I can't even receive any useful data from the Arduino.

So if I turn the receiving function off it sends the data just fine, but when I ask the Pi to start receiving data again it slows down the entire bus and data starts conflicting between the Pi and Arduino. Also it only happens with the Arduino. Every other device works flawlessly.

Here's what my code looks like on the Pi side. I'm using SMBus to send and receive bytes. I didn't bother to put up code for it because I don't have the source code for SMBus. I just trust that they work because my other I2C devices work without a hitch.

    while True:
        #if alternating == true then get the imu if not then get the motor speed
        if alternating == True:
            try: #need the try because an error will stop the program completely
                ypr = IMU.getYPR()
                yaw = int(ypr['yaw'] * 180 / math.pi)
                savedYaw = yaw
            except:
                yaw = savedYaw
                #print "exception"
                pass
                #write yaw to arduino
                i2c.writeByte(yaw)
                alternating = False
            else:
                #start reading data from arduino
                #readArduino()
                alternating = True
                pass

Then on the Arduino side these are my `onReceive` and `onRequest` functions:

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

    void readPI(int byteC) {
        if(Wire.available()) {
            reference = Wire.read();
        }
        pid1.getReference(reference);
        pid2.getReference(reference);
    }

    void sendPI() {
        int values[] = {(int)out, (int)outReversed  };
        Wire.write(values[count]);
        count++;
        if(count > 1) {
            count = 0;
        }
    }

Is there something about the Arduino that I don't know? Maybe it's a timing issue? Is there a way to set up registers? I can either receive or send, but I can't do both, and Googling the problem only leads to an example of someone sending 1 - 9 over the Pi. I can't find examples of anyone actually doing something complicated with an Arduino and a Rasp Pi over I2C. Any and all help would be amazing!

title: Arduino messing up as slave over I2C

Answers: 1

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

I find your onRequest function obscure:

    void sendPI(){
         int values[] = {(int)out, (int)outReversed  };

         Wire.write(values[count]);
         count++;
         if(count > 1){
         count = 0;

         }
     }

Why only send one byte? I think you have a number of problems:

* The size of `int` on the Arduino Uno is 2 bytes, on a Pi it is 4 bytes. So there is a mismatch there for a start.

* `Wire.write` (written like that) sends one byte, so that is only going to be half of your `int`. So that is even less.

* It isn't obvious what the Pi end is doing, but to make the `int` sizes match, I would be sending the lot in one hit like this:

        void sendPI(){
             long values[] = {(int)out, (int)outReversed  };
             Wire.write((byte *) &values, sizeof values);
         }

    Now you just read 8 bytes on the Pi (two ints).


body:
Looking at my Arduino Uno board, it appears the digital PWM pins are #11, #10, #9, #6, #5 and #3.

When playing around with the Theremin, it seems that the `Tone()` message works on all pins regardless of whether they are marked PWM or not?

Can anyone explain what is happening or how this is possible?

title: Tone() working on all digital pins?

Answers: 1

body:
The Tone library doesn't use the PWM mode timer functions on the atmega, instead it uses an interrupt routine to toggle the pins. You can find the source code for Tone libary here for reference:

https://github.com/johnmccombs/arduino-libraries/blob/master/Tone/


body:
I had an old duemilanove lying around (Which was not working because i accidentially busted the atmega) and I recently bought some atmegas pre-flashed with the UNO bootloader. So I tried to put one of those in it, and it seems to work fine except that I have to select the UNO board in the arduino IDE.

My question is: Is there anything problematic to be aware of when using the UNO bootloader in an duemilanove?

title: Will the Uno bootloader work in the Duemilanove?

Answers: 1

body:
So I researched it a bit, and there does not seem to be any problems with running the UNO bootloader on a Duemilanove board.

The biggest difference between the two seems to be the USB interface:

**USB interface**

Duemilanove uses FTDI, UNO uses another microcontroller (ATmega8u2).

Since the USB to serial is transparent for me as an end user for the most parts, it doesn't really matter to me.

**Leaner bootloader**

The UNO bootloader is smaller than the duemilanove.


body:
I need to pass a class member function to server.on, unfortunately i get an error.

> error: no matching function for call to 'ESP8266WebServer::on

I have done some searching but could not understand anything I found. No simple explanation.

This works:

    void handleRoot(){}
    server.on("/", handleRoot);

This doesn't:

    void myClass::handleRoot(){}
    void myClass::setup(){
        server.on("/", handleRoot);
    }

The second argument to server.on is

    typedef std::function<void(void)> THandlerFunction;

Unfortunately I have no idea what it means.

title: Passing class member function as argument

Answers: 3

body:
It's quite common question related to C++ programming.

The extensive explanation can be found [here][1].

The short answer is: it's very different from taking the address of a regular function.

Workarounds (that might or might not work for you, depending on what else you need that function to do) are:

 - make it static
 - declare it as friend function, rather than member function

Either way, the point is that it should not be something associated to an instance of the class, but rather to the class as a whole.

  [1]: http://www.parashift.com/c++-faq/pointers-to-members.html

body:
I've ben hitting this same problem.
Some further research on c++ syntax helped me find this clean solution, based on the

std::bind syntax:

    server.on("/", std::bind(&myClass::handleRoot, this));

body:
This will get the job done - using anonymous function syntax:

    server->on("/", [&]() {
       handleRoot();
    });


body:
I am completely new to this technology, but I'm hoping to build a fairly simple program through the Arduino IDE that takes the serial numbers of RFID cards read through my ID-20LA Innovations RFID reader and send those serial numbers to an API endpoint all through the IDE (as in without using a physical Arduino).

Is this possible? Are there any tutorials out there that walk through a stripped down version of this? I don't know where to start code wise, and all tutorials I've found use physical Arduinos to accomplish this.

title: Reading RFID tags with Arduino IDE, not using Arduino

Answers: 1

body:
**Short answer:**
NO

**Long Answer:**

Option 1:
 Use a USB RFID reader and create a basic processing/python/<place your preferred language here> app to read from the USB RFID reader and post it where ever you want it to

Option 2:
Use the arduino to read from the ID-20LA and send the data via UART to your computer and then create a windows app using processing/python/<place your preferred language here> to send it to your API endpoint

Option 3:
Use the arduino YUN to read from the ID-20LA and then create a basic python program to run on the YUN itself. Such that it will read data from the atmel microcontroller (on the YUN) and post it to your API endpoint. This is a much cleaner yet slightly more expensive way of doing this.


body:
I can't believe I am stumped by this, but this is my issue and I can't see any other solution for this anywhere.

I have an official Arduino Leonardo loaded up with the following code:

    void setup() {
      Keyboard.begin();
    }

    void loop() {
      char keyToPress = random('A', 'Z'); // choose a random letter between 'A' and 'Z'
      delay(1900);
      Keyboard.press(keyToPress);
      delay(100);
      Keyboard.release(keyToPress); // overall loop time is ~2s, with a 100mS keypress length
    }

On OSX and Linux, I get a predictable output - random capital letters typed by a keyboard, two seconds apart: FWTDXJP etc.

However, on Windows 7(x64), I get... nothing. I have the Leonardo appear correctly as a CDC COM port, drivers were installed from the latest 1.6.5 installer on their website. I have tried uninstalling the Leonardo in device manager while checking the "remove software" box so as to be sure that the driver I install is the one being used.

Has anyone seen this before? A search of the Arduino forum reveals some people having the same issue, a bit of a discussion and then usually "I don't know what I did but the problem has gone now".

This is the output from [USB Device Tree Viewer][1], which seems to correctly show the USB HID descriptor:

        =========================== USB Port2 ===========================

    Connection Status        : 0x01 (Device is connected)
    Port Chain               : 1-2

          ======================== USB Device ========================

            +++++++++++++++++ Device Information ++++++++++++++++++
    Friendly Name            : Arduino Leonardo (COM3)
    Device Description       : Arduino Leonardo
    Device Path              : \\?\usb#vid_2341&pid_8036#5&18f54cb7&0&2#{a5dcbf10-6530-11d2-901f-00c04fb951ed}
    Device ID                : USB\VID_2341&PID_8036\5&18F54CB7&0&2
    Driver KeyName           : {4d36e978-e325-11ce-bfc1-08002be10318}\0001 (GUID_DEVCLASS_PORTS)
    Driver                   : C:\Windows\system32\DRIVERS\usbser.sys (Version: 6.1.7601.18247  Date: 2013-08-29)
    Driver Inf               : C:\Windows\inf\oem6.inf
    Legacy BusType           : PNPBus
    Class                    : Ports
    Service                  : usbser
    Enumerator               : USB
    Location Info            : Port_#0002.Hub_#0001
    Location IDs             : PCIROOT(0)#PCI(0600)#USBROOT(0)#USB(2)
    Container ID             : {2d5fa232-297c-11e5-9565-080027ccdb00}
    Manufacturer Info        : Arduino LLC (www.arduino.cc)
    Capabilities             : 0x84 (Removable, SurpriseRemovalOK)
    Address                  : 2
    Problem Code             : 0
    Power State              : D0 (supported: D0, D3, wake from D0)
    COM-Port                 : COM3 (\Device\USBPDO-3)

            ---------------- Connection Information ---------------
    Connection Index         : 0x02 (2)
    Connection Status        : 0x01 (DeviceConnected)
    Current Config Value     : 0x01
    Device Address           : 0x02 (2)
    Is Hub                   : 0x00 (no)
    Number Of Open Pipes     : 0x04 (4)
    Device Bus Speed         : 0x01 (Full-Speed)
    Pipe0ScheduleOffset      : 0x04 (4)
    Pipe1ScheduleOffset      : 0x00 (0)
    Pipe2ScheduleOffset      : 0x00 (0)
    Pipe3ScheduleOffset      : 0x00 (0)

            ------------------ Device Descriptor ------------------
    bLength                  : 0x12 (18 bytes)
    bDescriptorType          : 0x01 (Device Descriptor)
    bcdUSB                   : 0x200 (USB Version 2.00)
    bDeviceClass             : 0x02 (Communications and CDC Control)
    bDeviceSubClass          : 0x00
    bDeviceProtocol          : 0x00
    bMaxPacketSize0          : 0x40 (64 bytes)
    idVendor                 : 0x2341
    idProduct                : 0x8036
    bcdDevice                : 0x100
    iManufacturer            : 0x01 (String Descriptor 1)
     Language 0x0409         : "Arduino LLC"
    iProduct                 : 0x02 (String Descriptor 2)
     Language 0x0409         : "Arduino Leonardo"
    iSerialNumber            : 0x00 (No String Descriptor)
    bNumConfigurations       : 0x01

            ------------------ String Descriptors -----------------
                 ------ String Descriptor 0 ------
    bLength                  : 0x04 (4 bytes)
    bDescriptorType          : 0x03 (String Descriptor)
    Language ID[0]           : 0x0409 (English - United States)
                 ------ String Descriptor 1 ------
    bLength                  : 0x18 (24 bytes)
    bDescriptorType          : 0x03 (String Descriptor)
    Language 0x0409          : "Arduino LLC"
                 ------ String Descriptor 2 ------
    bLength                  : 0x22 (34 bytes)
    bDescriptorType          : 0x03 (String Descriptor)
    Language 0x0409          : "Arduino Leonardo"

            -------------- Configuration Descriptor ---------------
    bLength                  : 0x09 (9 bytes)
    bDescriptorType          : 0x02 (Configuration Descriptor)
    wTotalLength             : 0x0064 (100 bytes)
    bNumInterfaces           : 0x03
    bConfigurationValue      : 0x01
    iConfiguration           : 0x00 (No String Descriptor)
    bmAttributes             : 0x80
     D7: Reserved, set 1     : 0x01
     D6: Self Powered        : 0x00 (no)
     D5: Remote Wakeup       : 0x00 (no)
     D4..0: Reserved, set 0  : 0x00
    MaxPower                 : 0xFA (500 mA)

            ------------------- IAD Descriptor --------------------
    bLength                  : 0x08 (8 bytes)
    bDescriptorType          : 0x0B
    bFirstInterface          : 0x00
    bInterfaceCount          : 0x02
    bFunctionClass           : 0x02 (Communications and CDC Control)
    bFunctionSubClass        : 0x02
    bFunctionProtocol        : 0x01
    iFunction                : 0x00 (No String Descriptor)

            ---------------- Interface Descriptor -----------------
    bLength                  : 0x09 (9 bytes)
    bDescriptorType          : 0x04 (Interface Descriptor)
    bInterfaceNumber         : 0x00
    bAlternateSetting        : 0x00
    bNumEndpoints            : 0x01 (1 Endpoint)
    bInterfaceClass          : 0x02 (Communications and CDC Control)
    bInterfaceSubClass       : 0x02
    bInterfaceProtocol       : 0x00
    iInterface               : 0x00 (No String Descriptor)

            -------------- CDC Interface Descriptor ---------------
    bFunctionLength          : 0x05 (5 bytes)
    bDescriptorType          : 0x24 (Interface)
    bDescriptorSubType       : 0x00 (Header Functional Descriptor)
    bcdCDC                   : 0x110 (CDC Version 1.10)

            -------------- CDC Interface Descriptor ---------------
    bFunctionLength          : 0x05 (5 bytes)
    bDescriptorType          : 0x24 (Interface)
    bDescriptorSubType       : 0x01 (Call Management Functional Descriptor)
    bmCapabilities           : 0x01
    bDataInterface           : 0x01

            -------------- CDC Interface Descriptor ---------------
    bFunctionLength          : 0x04 (4 bytes)
    bDescriptorType          : 0x24 (Interface)
    bDescriptorSubType       : 0x02 (Abstract Control Management Functional Descriptor)
    bmCapabilities           : 0x06

            -------------- CDC Interface Descriptor ---------------
    bFunctionLength          : 0x05 (5 bytes)
    bDescriptorType          : 0x24 (Interface)
    bDescriptorSubType       : 0x06 (Union Functional Descriptor)
    bControlInterface        : 0x00
    bSubordinateInterface[0] : 0x01

            ----------------- Endpoint Descriptor -----------------
    bLength                  : 0x07 (7 bytes)
    bDescriptorType          : 0x05 (Endpoint Descriptor)
    bEndpointAddress         : 0x81 (Direction=IN  EndpointID=1)
    bmAttributes             : 0x03 (TransferType=Interrupt)
    wMaxPacketSize           : 0x0010 (16 bytes) (16 bytes)
    bInterval                : 0x40 (64 ms)

            ---------------- Interface Descriptor -----------------
    bLength                  : 0x09 (9 bytes)
    bDescriptorType          : 0x04 (Interface Descriptor)
    bInterfaceNumber         : 0x01
    bAlternateSetting        : 0x00
    bNumEndpoints            : 0x02 (2 Endpoints)
    bInterfaceClass          : 0x0A (CDC-Data)
    bInterfaceSubClass       : 0x00
    bInterfaceProtocol       : 0x00
    iInterface               : 0x00 (No String Descriptor)

            ----------------- Endpoint Descriptor -----------------
    bLength                  : 0x07 (7 bytes)
    bDescriptorType          : 0x05 (Endpoint Descriptor)
    bEndpointAddress         : 0x02 (Direction=OUT  EndpointID=2)
    bmAttributes             : 0x02 (TransferType=Bulk)
    wMaxPacketSize           : 0x0040 (64 bytes) (64 bytes)
    bInterval                : 0x00 (ignored)

            ----------------- Endpoint Descriptor -----------------
    bLength                  : 0x07 (7 bytes)
    bDescriptorType          : 0x05 (Endpoint Descriptor)
    bEndpointAddress         : 0x83 (Direction=IN  EndpointID=3)
    bmAttributes             : 0x02 (TransferType=Bulk)
    wMaxPacketSize           : 0x0040 (64 bytes) (64 bytes)
    bInterval                : 0x00 (ignored)

            ---------------- Interface Descriptor -----------------
    bLength                  : 0x09 (9 bytes)
    bDescriptorType          : 0x04 (Interface Descriptor)
    bInterfaceNumber         : 0x02
    bAlternateSetting        : 0x00
    bNumEndpoints            : 0x01 (1 Endpoint)
    bInterfaceClass          : 0x03 (HID - Human Interface Device)
    bInterfaceSubClass       : 0x00 (None)
    bInterfaceProtocol       : 0x00 (None)
    iInterface               : 0x00 (No String Descriptor)

            ------------------- HID Descriptor --------------------
    bLength                  : 0x09 (9 bytes)
    bDescriptorType          : 0x21 (HID Descriptor)
    bcdHID                   : 0x0101 (HID Version 1.01)
    bCountryCode             : 0x00 (00 = not localized)
    bNumDescriptors          : 0x01
    Descriptor 1:
    bDescriptorType          : 0x22 (Class=Report)
    wDescriptorLength        : 0x0065 (101 bytes)
      05 01             Usage Page (Generic Desktop Controls)
      09 02             Usage (Mouse)
      A1 01             Collection (Application)
      09 01               Usage (Pointer)
      A1 00               Collection (Physical)
      85 01                 Report ID (0x01)
      05 09                 Usage Page (Buttons)
      19 01                 Usage Minimum (1)
      29 03                 Usage Maximum (3)
      15 00                 Logical Minimum (0)
      25 01                 Logical Maximum (1)
      95 03                 Report Count (3)
      75 01                 Report Size (1)
      81 02                 Input (Var)
      95 01                 Report Count (1)
      75 05                 Report Size (5)
      81 03                 Input (Const, Var)
      05 01                 Usage Page (Generic Desktop Controls)
      09 30                 Usage (Direction-X)
      09 31                 Usage (Direction-Y)
      09 38                 Usage (Wheel)
      15 81                 Logical Minimum (-127)
      25 7F                 Logical Maximum (127)
      75 08                 Report Size (8)
      95 03                 Report Count (3)
      81 06                 Input (Var, Rel)
      C0                  End Collection
      C0                End Collection
      05 01             Usage Page (Generic Desktop Controls)
      09 06             Usage (Keyboard)
      A1 01             Collection (Application)
      85 02               Report ID (0x02)
      05 07               Usage Page (Keyboard)
      19 E0               Usage Minimum (-32)
      29 E7               Usage Maximum (-25)
      15 00               Logical Minimum (0)
      25 01               Logical Maximum (1)
      75 01               Report Size (1)
      95 08               Report Count (8)
      81 02               Input (Var)
      95 01               Report Count (1)
      75 08               Report Size (8)
      81 03               Input (Const, Var)
      95 06               Report Count (6)
      75 08               Report Size (8)
      15 00               Logical Minimum (0)
      25 65               Logical Maximum (101)
      05 07               Usage Page (Keyboard)
      19 00               Usage Minimum (0)
      29 65               Usage Maximum (101)
      81 00               Input ()
      C0                End Collection

            ----------------- Endpoint Descriptor -----------------
    bLength                  : 0x07 (7 bytes)
    bDescriptorType          : 0x05 (Endpoint Descriptor)
    bEndpointAddress         : 0x84 (Direction=IN  EndpointID=4)
    bmAttributes             : 0x03 (TransferType=Interrupt)
    wMaxPacketSize           : 0x0040 (64 bytes) (64 bytes)
    bInterval                : 0x01 (1 ms)

And this is a screenshot from Device Manager, showing just one HID device (my keyboard / trackpad on my laptop):

[![Device Manager screenshot][2]][2]

Any ideas? I have obviously tried the example USB keyboard code from the Arduino IDE too - my code was just to get a minimum system to simplify testing. All help gratefully received.

  [1]:http://www.uwe-sieber.de/usbtreeview_e.html
  [2]: https://i.stack.imgur.com/HPEeG.png

title: Can't get Arduino Leonardo working as a USB keyboard in Windows 7

Answers: 1

body:
Let me try to help. This isn't a definitive "answer" but I need to post screenshots etc., so I am making it an answer.

I tried your code with my Arduino Micro. I believe it is the same as the Leonardo except for a byte difference in the bootloader identification (for the USB device).

First the <s>good</s> bad news. It worked under Windows 7. And let me tell you something: It is incredibly annoying to try to use the Windows 7 device manager when something is typing a key every two seconds! I recompiled it to type a key every minute to save my sanity.

I don't usually use Windows 7 (I use Ubuntu normally) so the device driver was not installed. It offered to install it, I told it to skip going to Windows Update, and it installed it thus:

[![USB installation][1]][1]

Note that I did **not** use the device drivers (if any) supplied with the Arduino installation. I never got asked that question.

---

Locating the device in the Device Manager I see I got Windows drivers:

[![Driver names][2]][2]

---

It showed up under Human Interface Devices as a USB Input Device:

[![USB input device][3]][3]

---

These were the hardware IDs:

[![Hardware IDs][4]][4]

---

It also showed up as a Composite Device:

[![USB composite device][5]][5]

---

This was the report from the program you linked:

        =========================== USB Port1 ===========================

    Connection Status        : 0x01 (Device is connected)
    Port Chain               : 1-1-3-1

          ======================== USB Device ========================

            +++++++++++++++++ Device Information ++++++++++++++++++
    Device Description       : USB Composite Device
    Device Path              : \\?\usb#vid_2341&pid_8037#7&171b751b&0&1#{a5dcbf10-6530-11d2-901f-00c04fb951ed}
    Device ID                : USB\VID_2341&PID_8037\7&171B751B&0&1
    Driver KeyName           : {36fc9e60-c465-11cf-8056-444553540000}\0026 (GUID_DEVCLASS_USB)
    Driver                   : C:\Windows\system32\DRIVERS\usbccgp.sys (Version: 6.1.7601.18328  Date: 2013-11-27)
    Driver Inf               : C:\Windows\inf\usb.inf
    Legacy BusType           : PNPBus
    Class                    : USB
    Service                  : usbccgp
    Enumerator               : USB
    Location Info            : Port_#0001.Hub_#0005
    Location IDs             : PCIROOT(0)#PCI(1D00)#USBROOT(0)#USB(1)#USB(3)#USB(1)
    Container ID             : {821d8eeb-43cd-11e5-b4e1-10c37b50593b}
    Manufacturer Info        : (Standard USB Host Controller)
    Capabilities             : 0x84 (Removable, SurpriseRemovalOK)
    Address                  : 1
    Problem Code             : 0
    Power State              : D0 (supported: D0, D2, D3, wake from D0, wake from D2)
     Child Device 1          : Arduino Micro
      Device ID              : USB\VID_2341&PID_8037&MI_00\8&6467A9E&0&0000
      Class                  : Ports
      COM-Port               : COM8 (\Device\USBSER000)
     Child Device 2          : USB Input Device
      Device ID              : USB\VID_2341&PID_8037&MI_02\8&6467A9E&0&0002
      Class                  : HIDClass
       Child Device 1        : HID-compliant mouse
        Device ID            : HID\VID_2341&PID_8037&MI_02&COL01\9&F900E83&0&0000
        Class                : Mouse
       Child Device 2        : HID Keyboard Device
        Device ID            : HID\VID_2341&PID_8037&MI_02&COL02\9&F900E83&0&0001
        Class                : Keyboard

            ---------------- Connection Information ---------------
    Connection Index         : 0x01 (1)
    Connection Status        : 0x01 (DeviceConnected)
    Current Config Value     : 0x01
    Device Address           : 0x08 (8)
    Is Hub                   : 0x00 (no)
    Number Of Open Pipes     : 0x04 (4)
    Device Bus Speed         : 0x01 (Full-Speed)
    Pipe0ScheduleOffset      : 0x01 (1)
    Pipe1ScheduleOffset      : 0x00 (0)
    Pipe2ScheduleOffset      : 0x00 (0)
    Pipe3ScheduleOffset      : 0x00 (0)

            ------------------ Device Descriptor ------------------
    bLength                  : 0x12 (18 bytes)
    bDescriptorType          : 0x01 (Device Descriptor)
    bcdUSB                   : 0x200 (USB Version 2.00)
    bDeviceClass             : 0x00 (defined by the interface descriptors)
    bDeviceSubClass          : 0x00
    bDeviceProtocol          : 0x00
    bMaxPacketSize0          : 0x40 (64 bytes)
    idVendor                 : 0x2341
    idProduct                : 0x8037
    bcdDevice                : 0x100
    iManufacturer            : 0x01 (String Descriptor 1)
     Language 0x0409         : "Arduino LLC"
    iProduct                 : 0x02 (String Descriptor 2)
     Language 0x0409         : "Arduino Micro"
    iSerialNumber            : 0x00 (No String Descriptor)
    bNumConfigurations       : 0x01

            ------------------ String Descriptors -----------------
                 ------ String Descriptor 0 ------
    bLength                  : 0x04 (4 bytes)
    bDescriptorType          : 0x03 (String Descriptor)
    Language ID[0]           : 0x0409 (English - United States)
                 ------ String Descriptor 1 ------
    bLength                  : 0x18 (24 bytes)
    bDescriptorType          : 0x03 (String Descriptor)
    Language 0x0409          : "Arduino LLC"
                 ------ String Descriptor 2 ------
    bLength                  : 0x1C (28 bytes)
    bDescriptorType          : 0x03 (String Descriptor)
    Language 0x0409          : "Arduino Micro"

            -------------- Configuration Descriptor ---------------
    bLength                  : 0x09 (9 bytes)
    bDescriptorType          : 0x02 (Configuration Descriptor)
    wTotalLength             : 0x0064 (100 bytes)
    bNumInterfaces           : 0x03
    bConfigurationValue      : 0x01
    iConfiguration           : 0x00 (No String Descriptor)
    bmAttributes             : 0x80
     D7: Reserved, set 1     : 0x01
     D6: Self Powered        : 0x00 (no)
     D5: Remote Wakeup       : 0x00 (no)
     D4..0: Reserved, set 0  : 0x00
    MaxPower                 : 0xFA (500 mA)

            ------------------- IAD Descriptor --------------------
    bLength                  : 0x08 (8 bytes)
    bDescriptorType          : 0x0B
    bFirstInterface          : 0x00
    bInterfaceCount          : 0x02
    bFunctionClass           : 0x02 (Communications and CDC Control)
    bFunctionSubClass        : 0x02
    bFunctionProtocol        : 0x01
    iFunction                : 0x00 (No String Descriptor)

            ---------------- Interface Descriptor -----------------
    bLength                  : 0x09 (9 bytes)
    bDescriptorType          : 0x04 (Interface Descriptor)
    bInterfaceNumber         : 0x00
    bAlternateSetting        : 0x00
    bNumEndpoints            : 0x01 (1 Endpoint)
    bInterfaceClass          : 0x02 (Communications and CDC Control)
    bInterfaceSubClass       : 0x02
    bInterfaceProtocol       : 0x00
    iInterface               : 0x00 (No String Descriptor)

            -------------- CDC Interface Descriptor ---------------
    bFunctionLength          : 0x05 (5 bytes)
    bDescriptorType          : 0x24 (Interface)
    bDescriptorSubType       : 0x00 (Header Functional Descriptor)
    bcdCDC                   : 0x110 (CDC Version 1.10)

            -------------- CDC Interface Descriptor ---------------
    bFunctionLength          : 0x05 (5 bytes)
    bDescriptorType          : 0x24 (Interface)
    bDescriptorSubType       : 0x01 (Call Management Functional Descriptor)
    bmCapabilities           : 0x01
    bDataInterface           : 0x01

            -------------- CDC Interface Descriptor ---------------
    bFunctionLength          : 0x04 (4 bytes)
    bDescriptorType          : 0x24 (Interface)
    bDescriptorSubType       : 0x02 (Abstract Control Management Functional Descriptor)
    bmCapabilities           : 0x06

            -------------- CDC Interface Descriptor ---------------
    bFunctionLength          : 0x05 (5 bytes)
    bDescriptorType          : 0x24 (Interface)
    bDescriptorSubType       : 0x06 (Union Functional Descriptor)
    bControlInterface        : 0x00
    bSubordinateInterface[0] : 0x01

            ----------------- Endpoint Descriptor -----------------
    bLength                  : 0x07 (7 bytes)
    bDescriptorType          : 0x05 (Endpoint Descriptor)
    bEndpointAddress         : 0x81 (Direction=IN  EndpointID=1)
    bmAttributes             : 0x03 (TransferType=Interrupt)
    wMaxPacketSize           : 0x0010 (16 bytes) (16 bytes)
    bInterval                : 0x40 (64 ms)

            ---------------- Interface Descriptor -----------------
    bLength                  : 0x09 (9 bytes)
    bDescriptorType          : 0x04 (Interface Descriptor)
    bInterfaceNumber         : 0x01
    bAlternateSetting        : 0x00
    bNumEndpoints            : 0x02 (2 Endpoints)
    bInterfaceClass          : 0x0A (CDC-Data)
    bInterfaceSubClass       : 0x00
    bInterfaceProtocol       : 0x00
    iInterface               : 0x00 (No String Descriptor)

            ----------------- Endpoint Descriptor -----------------
    bLength                  : 0x07 (7 bytes)
    bDescriptorType          : 0x05 (Endpoint Descriptor)
    bEndpointAddress         : 0x02 (Direction=OUT  EndpointID=2)
    bmAttributes             : 0x02 (TransferType=Bulk)
    wMaxPacketSize           : 0x0040 (64 bytes) (64 bytes)
    bInterval                : 0x00 (ignored)

            ----------------- Endpoint Descriptor -----------------
    bLength                  : 0x07 (7 bytes)
    bDescriptorType          : 0x05 (Endpoint Descriptor)
    bEndpointAddress         : 0x83 (Direction=IN  EndpointID=3)
    bmAttributes             : 0x02 (TransferType=Bulk)
    wMaxPacketSize           : 0x0040 (64 bytes) (64 bytes)
    bInterval                : 0x00 (ignored)

            ---------------- Interface Descriptor -----------------
    bLength                  : 0x09 (9 bytes)
    bDescriptorType          : 0x04 (Interface Descriptor)
    bInterfaceNumber         : 0x02
    bAlternateSetting        : 0x00
    bNumEndpoints            : 0x01 (1 Endpoint)
    bInterfaceClass          : 0x03 (HID - Human Interface Device)
    bInterfaceSubClass       : 0x00 (None)
    bInterfaceProtocol       : 0x00 (None)
    iInterface               : 0x00 (No String Descriptor)

            ------------------- HID Descriptor --------------------
    bLength                  : 0x09 (9 bytes)
    bDescriptorType          : 0x21 (HID Descriptor)
    bcdHID                   : 0x0101 (HID Version 1.01)
    bCountryCode             : 0x00 (00 = not localized)
    bNumDescriptors          : 0x01
    Descriptor 1:
    bDescriptorType          : 0x22 (Class=Report)
    wDescriptorLength        : 0x0065 (101 bytes)
      05 01             Usage Page (Generic Desktop Controls)
      09 02             Usage (Mouse)
      A1 01             Collection (Application)
      09 01               Usage (Pointer)
      A1 00               Collection (Physical)
      85 01                 Report ID (0x01)
      05 09                 Usage Page (Buttons)
      19 01                 Usage Minimum (1)
      29 03                 Usage Maximum (3)
      15 00                 Logical Minimum (0)
      25 01                 Logical Maximum (1)
      95 03                 Report Count (3)
      75 01                 Report Size (1)
      81 02                 Input (Var)
      95 01                 Report Count (1)
      75 05                 Report Size (5)
      81 03                 Input (Const, Var)
      05 01                 Usage Page (Generic Desktop Controls)
      09 30                 Usage (Direction-X)
      09 31                 Usage (Direction-Y)
      09 38                 Usage (Wheel)
      15 81                 Logical Minimum (-127)
      25 7F                 Logical Maximum (127)
      75 08                 Report Size (8)
      95 03                 Report Count (3)
      81 06                 Input (Var, Rel)
      C0                  End Collection
      C0                End Collection
      05 01             Usage Page (Generic Desktop Controls)
      09 06             Usage (Keyboard)
      A1 01             Collection (Application)
      85 02               Report ID (0x02)
      05 07               Usage Page (Keyboard)
      19 E0               Usage Minimum (-32)
      29 E7               Usage Maximum (-25)
      15 00               Logical Minimum (0)
      25 01               Logical Maximum (1)
      75 01               Report Size (1)
      95 08               Report Count (8)
      81 02               Input (Var)
      95 01               Report Count (1)
      75 08               Report Size (8)
      81 03               Input (Const, Var)
      95 06               Report Count (6)
      75 08               Report Size (8)
      15 00               Logical Minimum (0)
      25 65               Logical Maximum (101)
      05 07               Usage Page (Keyboard)
      19 00               Usage Minimum (0)
      29 65               Usage Maximum (101)
      81 00               Input ()
      C0                End Collection

            ----------------- Endpoint Descriptor -----------------
    bLength                  : 0x07 (7 bytes)
    bDescriptorType          : 0x05 (Endpoint Descriptor)
    bEndpointAddress         : 0x84 (Direction=IN  EndpointID=4)
    bmAttributes             : 0x03 (TransferType=Interrupt)
    wMaxPacketSize           : 0x0040 (64 bytes) (64 bytes)
    bInterval                : 0x01 (1 ms)

---

Hopefully you can compare this to your situation and see what is different.

---

*(Edited to add)*

I tried today on my son's Windows 7 PC, which I don't think had Arduino ever installed on it. Also I used my Leonardo instead of the Micro, just to be sure. First Windows tried to install the device drivers:

[![Leonard device driver install][6]][6]

---

Then it only succeeded with the composite device and the keyboard:

[![Leonard device driver install - keyboard][7]][7]

---

However the keyboard worked (eg. in Notepad).

[![Input device description][8]][8]

---

It shows up in the Device Manager:

[![Peripheral ID][9]][9]

  [1]: https://i.stack.imgur.com/UaMY1.png
  [2]: https://i.stack.imgur.com/GdZZS.png
  [3]: https://i.stack.imgur.com/fDf0Q.png
  [4]: https://i.stack.imgur.com/RTyBp.png
  [5]: https://i.stack.imgur.com/0j2jH.png
  [6]: https://i.stack.imgur.com/yQnhu.png
  [7]: https://i.stack.imgur.com/4gC41.png
  [8]: https://i.stack.imgur.com/wc8xs.png
  [9]: https://i.stack.imgur.com/A9kfk.png


body:
Can I make a USB 2x16 display using an Arduino?
I want to control a 2x16 character lcd display using USB, not com port/serial.

I need it to appear as a HID device when connected to the computer.

Please advise me.

Thanks

title: How do I use an Arduino as a USB output device for a 2x16 display?

Answers: 1

body:
HID's generally are input devices to your computer, if you do want your computer to send data to the device you will need an application to do it.

So your best bet is to have a windows app to communicate with your arduino using a virtual com port ( as it does already) and send data as you require


body:
I am trying to find cheap options for displays about 3 x 6 inches to display time, weather, simple clip-art type images, and other marquee messages.  What are my best options to work with arduino if my goal is cost-cutting?

* 2" x 4" or greater in size
* 40 dpi minimum
* readable from 15 feet in normal indoor conditions
* everything else is unimportant to me at this point: RGB, pitch, power draw, etc.

title: Solutions for displays?

Answers: 3

body:
www.aliexpress.com would be your first go for cheap stuff.

You can always chat with the guys and bargain a bit on the price. Do remember that the free shipping option means that it will take nearly a month to arrive

body:
One possible option would be these 8x8 pixel displays.

[![8x8 pixel LED][1]][1]

I got that from eBay for $8.50 (for the 4 modules).

They come pre-assembled, this is the back:

[![8x8 pixel LED back][2]][2]

Notice the data direction. You can connect them together like this:

[![8x8 pixel LED - 3 modules][3]][3]

That one (3 lots of 4 modules) is 25.4 cm long (10 inches) and 3.2 cm high (about 1.25 inches).

That's 96 pixels (8 x 4 x 3) in 10 inches, which is a lot less than 40 DPI, but really, if you want to read them from 15 feet away, that is probably OK.

Note: These were single-colour only.

---

If you want 40 DPI x 6 inches that means you must want 240 pixels horizontally and 120 pixels vertically. That would be `240 / 8` modules horizontally (30 modules) and `120 / 8` vertically (15 modules). That's a total of 450 modules. Since they come in lots of four that would be 116 in total (rounded up). 116 x $8.50 = $US 986.

I don't know if that is what you have in mind by "cost cutting" but that is one option.

You would need to assemble them yourself, connect them together, supply power, and have a suitable driver. I have some [code](http://www.gammon.com.au/forum/?id=11516) that drives those boards, although I certainly have not tested it with 450 of them at once.

As you can see those boards come with mounting holes on the back, and are designed to be physically adjacent to each other. Mounting 450 of them could be quite tedious. The LED modules on the front pull off to give access to the mounting holes, but it would be a long job.

---

You can get larger modules, as mentioned in another reply, I expect they would be more expensive, but you would of course get more pixels.

Example: [64x32 RGB LED Matrix - 4mm pitch](http://www.adafruit.com/products/2278). That one is 64x32 pixels for around $US 80.

You would probably need 4 of those horizontally (256 pixels) and 4 vertically (128 pixels). Thus, a total of 16 which would cost you around $US 1280. However for that at least you get RGB. Note that the Adafruit page mentions you cannot drive that many pixels with a Uno.

  [1]: https://i.stack.imgur.com/hw5UO.jpg
  [2]: https://i.stack.imgur.com/NFmlK.jpg
  [3]: https://i.stack.imgur.com/aIW09.jpg

body:
How about just a computer monitor? That would be reasonably large, have high resolution, and could display whatever you want it to. That would only be a few hundred dollars (if that). You could drive it from a cheap PC, or from an Arduino using something like the [MicroVGA](http://www.microvga.com/) board. That has 800x600 pixels resolution.

That would be cheaper, and less fiddly, than putting together a lot of LED display modules.

Also see <http://playground.arduino.cc/Main/MicroVGA>


body:
The company where I work wants to do a proof of concept for our new product, a force-sensing platform.

The platform contains four three-axial load cells, so we have 12 channels, which are to be digitized at 2kHz and 16bits. This gives us 2.000 dataframes per second, with 24 bytes of payload each.

Our proposed architecture is as following:

 - The analog signals from the cells is acquired by a dedicated data-acquisition board;
 - The digital stream is sent to the ATmega on Yún over SPI;
 - The data is then relayed to the Atheros over Serial;
 - Finally, the data is transmitted over UDP (or TCP).

I wonder if it is a sensible way of doing it, with the following questions:

 - How would one normally use the Ethernet functionality? Can I call a function on the sketch, or do I need to put some program or script in the Linux, calling it from the sketch?
 - What would be the maximum transmission speed (in bytes per second) from the ATmega side to the Linux side?
 - What would be the maximum throughput of the Ethernet?

I have calculated 24 bytes * 2000 = 480 bytes per second, or a baud rate of 480 * 8 = 3840bps. Is that right?

I would appreciate any help, it could be just a link to the proper information resources.

title: Streaming sensor data over UDP using an Arduino Yún - how to do it and how fast could it be?

Answers: 1

body:
The Yun is really two different computers (one AVR and on Linux) connected by a serial link. Basically the AVR is connected to a serial console on the Linux machine, so you can "type" commands into Linux by sending strings out the serial port from the AVR.

The serial link normally comes up at 250,000 buad, so that should not be a bottleneck for your application.

Typically, the AVR will "type" a command to run a Python program on the Linux side (called the Bridge) that will then communicate with AVR code using a high level protocol. Unfortunately, this "bridge" connections tends to be slow and flaky.

But you could do what you want very easily by just pumping netcat commands into the Linux machine from the AVR machine every time you wanted to send a UDP packet out. The overhead would only be a few serial bytes per packet (you'd send "nc -u <host> <port> <data>\r" where everything but data is likely the same for every packet).

Here is an example of a program that runs on thew AVR and periodically reads some data from temperature sensors connected via 1-Wire, and then runs a "curl" command on the linux console to record  the readings to a server...

https://github.com/bigjosh/SimpleTempLoggerYun/blob/master/Arduino/SimpleTempLoggerYun/SimpleTempLoggerYun.ino

In your case, your replace the 1-Wire reading code with SPI reading code, and replace the "curl" that sends HTTP data command with an "[nc][1]" command that would send a UDP packet (using the "-u" parameter).

With this technique, I think you could get something working very very quickly and likely easily meet your data rate requirements.

Note that while this is a great technique for getting a proof-of-concept working quickly, I would not use a setup like this in production. Instead consider something like a BeagleBone Black where you could read the SPI data and send the UDP pack in a single C program that ran as a normal Linux process.

  [1]: http://linux.die.net/man/1/nc


body:
I've got a [MAX7456 chip][1] and I am using [this][2] library with it.
But the issue is that the character table is not the one the library needs to function like it should. The "Hello world" example is nowhere near to what it should display, because the character table is wrong.

All the instructions that talk about character set updating require a USB FTDI cable (I don't have one), I am able to  program the board with [USBASP][3] programmer but that's it. I also have a few Nanos, if that helps.

How could I update the character table to what the library needs (without a FTDI cable) or how to make the sketch included to update the character set work properly?

[1]: https://www.sparkfun.com/datasheets/BreakoutBoards/MAX7456.pdf
[2]: https://www.dropbox.com/s/3cp4am1f271odcm/max7456.tar?dl=1
[3]: http://www.fischl.de/usbasp/

title: How to update the character table of MAX7456

Answers: 1

body:
To solve this problem one would need to get the builtin character updating sketch work (Max456WriteTable.cpp in examples folder). After the sketch has been compiled one would have to connect either FTDI cable or a USBASP programmer to the board and upload the sketch to it.

The character set (array) itself used in the code can be updated with the appropriate program available at [this site][1].

UPDATE: In the end I solved it [this way][2].

Many thanks to Charlie Hanson & Nick Gammon.

  [1]: http://theboredengineers.com/2012/12/a-max7456-library-for-arduino/
  [2]: https://arduino.stackexchange.com/questions/14739/character-updating-sketch-not-working


body:
Does anyone know (1) how much transient current can be output from a pin and (2) how much (and how long) reverse current an output pin can take?  For instance, consider the following circuit (driven by a series of 10 ms pulses at 5V):

      o----------------
           |          |
           = 10µF    1k LOAD
           |          |
      o----------------

which would be a classical filtered (smoothed) PWM circuit.  When the pin goes to +5V, the capacitor would act like a short and allow very high current (assuming about 20 ohm impedance, maybe 250 mA) for a millisecond or so.  Similarly, when the voltage drops to 0V, the charged capacitor will discharge, leading to a reverse current until it bleeds through the load.  Will either of these damage the diodes in the pin or even the IC?  Thanks.  (Worse comes to worse, does this mean that a resistor and diode are needed to protect the pin?)

**More info**

1)  It's 10µF.  10 pF would be useless in a power supply, it would only store 0.05 µC of electricity at most, which would only be able to smooth the output for a few microseconds.

2)  The load is resistance, 1 k ohms.

3)  A diode would be handy if you wanted to prevent reverse current, since you could put a much larger diode outside than the protective diodes in the Arduino.  They are classically used with motors (inductive load) as a clamp diode.

4)  My general question is about high transient current or reverse currents.  A capacitor is just an example of a situation that could cause this.  Another example would be a pin that is putting out only occasional (for example) 1ms long 100 mA pulses, separated by many seconds.  Such a circuit is really not delivering much power, but for very short periods it exceeds that recommended 40 mA.  Would this burn out the pin or not?

5)  A capacitor in parallel with the load is pretty much the classic filtered DC power supply.  Open any wall wart you have and you'll see a transformer, a rectifier and several large (electrolytic) capacitors (along with a couple small ones) and a voltage regulator.  Closer to this example, say you want to deliver current at 2 volts DC.  You can do this by alternating 2 ms pulses (at 5V) with 3 ms at 0V.  Then have a capacitor in series to smooth it to closer to DC, making it more like analog output.  That is, in fact, exactly how adjustable power supplies often work.

title: Transient and reverse current

Answers: 2

body:
I have had fairly lengthy discussions with [Mike Cook](http://www.thebox.myzen.co.uk/Tutorial/LEDs.html) from the Arduino forum about this sort of thing. I asked, for example, if it was OK to drive LEDs by PWM providing the duty cycle was short enough that "on average" the pins put out a current in specified range.

His answer always is: **no**!

The datasheet does not say you can exceed the *absolute maximum ratings* for a certain amount of time (like 1 µs). You are not supposed to exceed them at all.

It doesn't take a particularly large series resistor to limit current to the recommended 20 mA (250 Ω at 5 V).

Now you can probably "get away with" not using it, but you are basically moving into unsupported territory. If the chip fails after a year, don't blame the manufacturer.

---

>  It's 10 microFarad = 10mmF. 10 picoFarad would be useless in a power supply

According to [Wikipedia](https://en.wikipedia.org/wiki/Farad):

>  A "micro-microfarad" (μμF, and confusingly often mmf or MMF), an obsolete unit sometimes found in older texts, is the equivalent of a picofarad.

Your use of mmF as a replacement for µF is confusing. I suggest either copying and pasting "my" µ from this post, or using a simple "u" instead.

> ... useless in a power supply

Surely you are not seriously suggesting that you are going to make a power supply, powered by an Arduino output pin?

I am presuming not, so perhaps if you describe your application?

body:
It sounds like you are trying to make a digital to analog converter driving some type of load.  Look at this link: http://emesystems.com/BS2PWM.htm
It will give you a start. Please note they use an opamp as a buffer.

This 'buffer' has a very high input impedance and a low output impedance.  It can drive from a few mills to over an amp depending on the opamp chosen.  Additional circuitry can get you into thousands of amps if desired.  The schematic is a 2 pole filter originally designed for the Stamp microcontroller.

The filter soothes it out but adds a delay on the final output value (settling time).  The greater the filter capactance the lower the ripple and the slower the response.  You can add another pole to filter if you want.

As a bit of information from an old semiconductor guy absolute ratings are just that.  If you exceed them even for a few nanoseconds you can be sure you damaged the device, you just do not know when it will fail.

I have seen a lot of microcontrollers damaged because of capacitors connected to the pins, power excluded, doesn't matter if the pin is input or output.  When the power supply collapses it will inject current into the microprocessor substrate possibly damaging it.

Good Luck


body:
Hoping someone can help me out in my conundrum here...

I currently am testing the SoftwareSerial library out to understand how I may use it in my project.

I have a wire running from pin 6 to pin 9, so that the TX talks straight to the RX.

I have written the following:

    #include <SoftwareSerial.h>

    SoftwareSerial mySerial(6,9); //RX = 6 TX = 9

    void setup() {

      Serial.begin(1200);
      mySerial.begin(1200);
    }

    void loop() {

      mySerial.write('F');
      delay(100); // attempting to allow time between write and read commands

      while (mySerial.available()>0) {
      Serial.println(mySerial.read());
      }
    }

The whole point is just to see 'F' return in the Serial Monitor.

The output, unfortunately, is absolutely nothing! If I omit the `while(mySerial.available>0)` I just get -1 's down the lines of the Serial Monitor.

Thank you in advance!

title: SoftwareSerial Write to return Read in Serial Monitor?

Answers: 1

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

SoftwareSerial cannot talk to itself. Since it is implemented in software and not hardware it can either send or receive at one time, but not both.

Look at the code for `write` in SoftwareSerial:

    size_t SoftwareSerial::write(uint8_t b)
    {

    ...

      cli();  // turn off interrupts for a clean txmit

    ...

      // Write each of the 8 bits
      for (uint8_t i = 8; i > 0; --i)
      {
        if (b & 1) // choose bit
          *reg |= reg_mask; // send 1
        else
          *reg &= inv_mask; // send 0

        tunedDelay(delay);
        b >>= 1;
      }

    ...

      SREG = oldSREG; // turn interrupts back on

    ...

    }

Since it turns interrupts off, and interrupts are needed for it to detect incoming data, therefore it cannot detect incoming data while it is sending.


body:
Why do people use a variable to specify a pin number when the pin is unlikely to change throughout the execution of the code?

Many times I see an `int` being used for a pin definition,

    int led = 13;

when the use of a `const int`

    const int led = 13;

or [`enum`][1], or [`#define`][2]

    #define LED 13

makes much more sense.

It is even in tutorials on the Arduino site, for example, the first tutorial that most people run, [Blink][3].

I [read somewhere][4] that `const int` is preferred over `#define`. Why isn't this encouraged right from the beginning, rather than allowing people to develop bad habits, from the outset? I noticed it a while back, but recently it has started to irritate me, hence the question.

Memory/processing/computing wise is a `const int`, `enum`, or for that matter `#define`, better than a plain `int`, i.e. occupies less memory, stored in [different memory][5] (Flash, EEPROM, SRAM), faster execution, quicker to compile?

----

This may appear to be a duplicate of [Is it better to use #define or const int for constants?][6], but I am addressing the question of why people use variables, and how does the performance improve when they don't, rather than which type of constant is better.

  [1]: http://playground.arduino.cc/Code/Enum
  [2]: https://www.arduino.cc/en/Reference/Define
  [3]: https://www.arduino.cc/en/tutorial/blink
  [4]: https://stackoverflow.com/questions/16889213/how-to-use-define-to-assign-pins-in-arduino#comment-24383545
  [5]: https://www.arduino.cc/en/Tutorial/Memory
  [6]: https://arduino.stackexchange.com/questions/506/is-it-better-to-use-define-or-const-int-for-constants

title: Why use an int variable for a pin when const int, enum or #define makes much more sense

Answers: 4

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

    const int led = 13;

That is the correct method. Or even:

    const byte led = 13;

How many pins do you have?

Some of the tutorials did not quite go through as much quality control as they might have.

Performance will be better using `const byte`, compare to `int` however the compiler may be smart enough to realize what you are doing.

What you can do is gently encourage people to use more efficient techniques by using them in your own code.

---

### Responses to comments

1. A commenter has suggested that `byte` is not standard C. This is correct, however this is an Arduino StackExchange site, and I believe using standard types supplied by the Arduino IDE is acceptable.

    In Arduino.h there is this line:

        typedef uint8_t byte;

    Note that this is not exactly the same as `unsigned char`. See [uint8_t vs unsigned char](https://stackoverflow.com/questions/1725855/uint8-t-vs-unsigned-char) and [When is uint8_t ≠ unsigned char?](https://stackoverflow.com/questions/16138237/when-is-uint8-t-≠-unsigned-char).

2. Another commenter has suggested that using byte will not necessarily improve performance, because numbers smaller than `int` will be promoted to `int` (see Integer Promotion Rules if you want more on this).

    However in the context of a **const** identifier, the compiler will generate efficient code in any case. For example, disassembling "blink" gives this in the original form:

    <!-- language-all: lang-none -->

        00000086 <loop>:
          86: 8d e0        ldi r24, 0x0D ; 13
          88: 61 e0        ldi r22, 0x01 ; 1
          8a: 1b d1        rcall .+566     ; 0x2c2 <digitalWrite>

    In fact it generates the same code whether the `13`:

    * Is a literal
    * Is a `#define`
    * Is a `const int`
    * Is a `const byte`

---

The compiler know when it can fit a number into one register and when it can't. However it is *good practice* to use coding that indicates your *intent*. Making it `const` makes it clear that the number won't change, and making it `byte` (or `uint8_t`) makes it clear that you are expecting a small number.

---

### Confusing error messages

Another major reason to avoid `#define` is the error messages you get if you make a mistake. Consider this "blink" sketch which has an error:

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

    #define LED = 13;

    void setup() {
      pinMode(LED, OUTPUT);      // <---- line with error
    }

    void loop() {
      digitalWrite(LED, HIGH);   // <---- line with error
      delay(1000);
      digitalWrite(LED, LOW);    // <---- line with error
      delay(1000);
    }

On the surface it looks OK, but it generates these error messages:

<!-- language-all: lang-none -->

    Blink.ino: In function ‘void setup()’:
    Blink:4: error: expected primary-expression before ‘=’ token
    Blink:4: error: expected primary-expression before ‘,’ token
    Blink:4: error: expected `;' before ‘)’ token
    Blink.ino: In function ‘void loop()’:
    Blink:8: error: expected primary-expression before ‘=’ token
    Blink:8: error: expected primary-expression before ‘,’ token
    Blink:8: error: expected `;' before ‘)’ token
    Blink:10: error: expected primary-expression before ‘=’ token
    Blink:10: error: expected primary-expression before ‘,’ token
    Blink:10: error: expected `;' before ‘)’ token

You look at the first highlighted line (line 4) and *don't even see* a "=" symbol. Plus, the line looks fine. Now it's fairly obvious what the problem is here (`= 13` is being substituted for `LED`), but when the line is 400 lines further down in the code, it isn't obvious the problem is with the way LED is defined.

I've seen people fall for this many times (including myself).

body:
As Ignacio has rightly states, it's basically because they don't know better.  And they don't know better because the people who taught them (or the resources they used when learning) didn't know better.

Much of the Arduino code and tutorials are written by people who have never had any training in programming and are very much "self taught" from resources by people who themselves are very much self taught with no proper training in programming.

Many of the snippets of tutorial code I see around the place (and especially those that are only available within YouTube videos --- urgh) would be a fail mark if I were marking them in an exam.

Yes, a `const` is preferred over a non-const, and even over a `#define`, because:

* A `const` (like a `#define`, unlike a non-const) does not allocate any RAM
* A `const` (like a non-const, but unlike a `#define`) gives the value an explicit *type*

The second point there is of particular interest.  Unless specifically told otherwise with embedded type-casting (`(long)3`) or a type suffix (`3L`) or the presence of a decimal point (`3.0`), a `#define` of a number will always be an integer and all mathematics performed on that value will be as if it were an integer.  Most of the time that's not a problem, but you can run into interesting scenarios when you try to `#define` a value that is larger than an integer can store, such as `#define COUNT 70000` and then perform a mathematical operation with other `int` values on it.  By using a `const` you get to tell the compiler "This value is to be treated as this variable type" - so you would instead use: `const long count = 70000;` and all would work as expected.

It also has the knock-on effect that it checks the type when passing the value around the place.  Try passing a `const long` to a function that expects an `int` and it would complain about narrowing the variable range (or even completely fail to compile depending on the scenario).  Do that with a `#define` and it would just silently carry on giving you the wrong results and leave you scratching your head for hours.

body: My answer is... they do it because it works. I'm having a hard time not asking a question in my answer such as "why does it have to be 'wrong'?"

body: As a 2-week newbie to Arduino I'd pick up on the general idea of Arduino being occupied by non-programmers. Most sketches I have examined, including those on the Arduino site, show a total lack of order,  with sketches that do not work & barely a coherent comment in sight. Flow charts are non-existent, and the "Libraries" are an un-moderated jumble.


body:
Hi my lcd doesnt display that i was expected. Can anyone help me???

RS-->22
RW-->GROUND
E-->23
D4-->24
D5-->25
D6-->26
D7-->27

        #include <LiquidCrystal.h>

    LiquidCrystal lcd(22, 23, 24, 25, 26, 27);
    void setup() {

    lcd.begin(16,2);

    lcd.setCursor(0,1);
    lcd.print("Hello!");
    delay(1000);
    }
    void loop() {
    lcd.setCursor(0,1);
    lcd.print(millis()/1000);
    }

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

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

title: Arduino LCD Simple Problem

Answers: 1

body: I Had a similar problem with a different display, It looks like you are printing the value without clearing the display so all the numbers print on top of each other creating those squares. try adding lcd.clear() in the loop to clear the display before it prints another value.