body:
I'm noticing a crash when testing out some interrupt code for a project I'm working on.

I've returned to the example provided with the library [PciManager][1] and I'm still experiencing the same issue. There doesn't appear to be any patten to when the crash appears, and on occasion I've been playing for several minutes and not seen a crash. NOTE I had to add a file (Task.h) from the developers other project ([SoftTimer][2]) to get it to compile.

here is the code:

    #include <PciManager.h>
    #include <PciListenerImp.h>

    #define INPUT_PIN 3

    PciListenerImp listener(INPUT_PIN, onPinChange);

    int i = 0;

    void setup() {
      Serial.begin(9600);
      PciManager.registerListener(INPUT_PIN, &listener);
      Serial.println("Ready.");

    }

    void onPinChange(byte changeKind) {
      i++;
      Serial.print("pci : ");
      Serial.print(i);
      Serial.print(" : ");
      Serial.println(changeKind);
    }

    void loop() { }

I have a wire connected to pin 3 and 3.3v which I'm pulling out and then connecting again. Some times when disconnected it continually interrupts, I was expecting this. Sometimes it doesn't which I found strange, the crash appears to happen more in the latter case.

Here is a trace from the serial monitor

    Ready.
    pci : 1 : 0
    pci : 2 : 1
    pci : 3 : 0
    pci : 4 : 1
    pci : 5 : 0
    pci : 6 : 1
    pci : 7 : 0
    pci : 8 : 1
    pci : 9 : 0
    pci : 10 : 1
    pci : 11 : 0
    pci : 12 : 1
    pci : 13 : 0
    pci : 14 : 1
    pci : 15 : 0
    pci : 16 : 1
    pci : 17 : 0
    pci : 18 : 1
    pci : 19 : 0
    pci : 20 : 1
    pci :

I've run this on a [shrimp][3] and on a freeduino diecimila compatible board both resulting in the same effect.

Anyway down to question; is the issue the way I'm interrupting? i.e. not stopping the floating pin? or is it a problem with the library, or is it a fundamental problem with pin change interrupts.

  [1]: http://code.google.com/p/arduino-pcimanager/
  [2]: http://code.google.com/p/arduino-softtimer/
  [3]: http://shrimping.it/blog/shrimp-kit/

title: 'crash' when using pin change interrupts

Answers: 3

body:
Your `onPinChange()` function is called with interrupts disabled.

For you what it means is this function should:

- last **as short as possible** (because **NO** interrupts are handled during its execution, that includes timers that are used by several Arduino core libraries)
- not use `Serial` functions as these functions are slow and sometimes wait on interrupts (that could thus mean *wait forever*)

You can read further advice about these so-called *Interrupt Service Routines* (**ISR**) [here][1] and [there][2].

If you want to trace all calls to `onPinChange()` then you will have to use some kind of [circular buffer][3] as a global `volatile` variable, which will be written into by `onPinChange()` and read from by `loop()`.

Accessing that buffer from `loop()` should be protected against concurrent write by ISR.

Here is sample code I have just written (disclaimer, I have not checked that it compiles but I think it should work correctly) that uses such a circular buffer as described above, and ensures all shared variables accesses are protected against concurrent write by ISR:

    #include <PciManager.h>
    #include <PciListenerImp.h>

    // Structures and function to manage circular buffer of changes
    struct Change {
        int i;
        byte kind;
    };

    // We allow max SIZE changes in the buffer; if onPinChange() is called more often
    // than loop(), then at one time the buffer will be overwritten.
    const int SIZE = 100;
    volatile Change changes[SIZE];
    volatile int start = 0;
    volatile int end = 0;

    // Get the next change recorded by onPinChange()
    Change* nextChange() {
        static Change change;
        Change* result = 0;
        // Disable interrupts as we are accessing variables modified by onPinChange
        cli();
        if (start != end) {
            change = changes[start];
            start = (start + 1) % SIZE;
            result = &change;
        }
        // Re-enable interrupts before leaving the function
        sei();
        return result;
    }

    #define INPUT_PIN 3

    PciListenerImp listener(INPUT_PIN, onPinChange);

    // No change necessary in setup()
    void setup() {
        Serial.begin(9600);
        PciManager.registerListener(INPUT_PIN, &listener);
        Serial.println(Ready.);
    }

    void loop() {
        // Get the next change recorded by onPinChange (if any)
        Change* change = nextChange();
        if (change != 0) {
            // One change occurred since last time, trace it to Serial
            Serial.print("pci : ");
            Serial.print(change->i);
            Serial.print(" : ");
            Serial.println(change->kind);
        }
    }

    void onPinChange(byte changeKind) {
        // i does not have to be visible outside this function
        static int i = 0;
        i++;
        // Write information to the end of the circular buffer
        Change& change = changes[end];
        change.i = i;
        change.kind = changeKind;
        // Prepare for the next call (write to the next item of the buffer)
        end = (end + 1) % SIZE;
    }

  [1]: http://arduino.cc/en/Reference/AttachInterrupt
  [2]: http://gammon.com.au/interrupts
  [3]: http://en.wikipedia.org/wiki/Circular_buffer

body:
Note that disconnecting a wire on an input pin is also not going to give you the results you expect. A disconnected input pin's value will float, and you'll get a semi-random mixture of 1s and 0s. You should either connect an external pull-up/pull-down resistor, or activate the internal pull-up resistor when you configure the pin (by setting the pin to INPUT_PULLUP).

I prefer using INPUT_PULLUP, since that saves wiring an external resistor. Use INPUT_PULLUP, then wire the pin through a pushbutton switch to ground.

Then look for a high-to-low transition on the pin to signify a button press.

body:
I'm going to include this answer even though I think there's a very little chance that it is the problem because I just wasted ten hours on a project before finding it and it's an easy check so it won't take much time either way.

On AVR chips, if you have enabled interrupts and one occurs and you don't have an ISR for it, it will call the default ISR which resets the board. You can test if this is happening by redefining the default ISR by creating a function ISR(BADISR_vect){};  I would put a serial print in there and run it again and see if it's happening. If you don't want to do serial (for obvious reasons) just toggle an LED.

I also agree it's probably a bad idea to be doing this on a floating pin. I'd use the internal pull-up resister to keep it high then connect a wire between that pin and ground to simulate a button.


body:
Can't upload sketches to Arduino Nano clone with USB to serial chip ch340.

After installing drivers and plugging in, device has the name `cu/tty.wch ch341 USB=>RS232 fa130` (with spaces), but Arduino can't recognize the full name (only `tty.wch`).

Is it possible to rename device in Mac OS or change device identifier?

UPDATE: `ch340` new driver http://www.wch.cn/downloads.php?name=pro&proid=178

title: Rename device name (ch340 usb to serial) Mac OS

Answers: 6

body: I send email about this issue to WCH, and they change drivers to the latest version on their website, this is direct link http://www.wch.cn/downloads.php?name=pro&proid=178 (driver works and device has proper name in `dev/`)

body:
I used a terminal command:

    sudo ln -s /dev/tty.wch\ ch341\ USB\=\>RS232\ 1450 /dev/tty.USB0

where `/dev/tty.wch\ ch341\ USB\=\>RS232\ 1450` is the original name not recognized by Arduino; and `/dev/tty.USB0` is the new port name.

body:
For Yosemite you seem to need to run this command in the Terminal and then restart the computer to get it to work.

    sudo nvram boot-args="kext-dev-mode=1"

body:
I was having the same problem. installed the latest drivers, I'm using yosemite, installed the Arduino IDE, and tried the board in windows 7 and it worked in windows, so board and cable are working.

In mac OS 10.10 in system report now they show as USB 2.0 Serial in arduino IDE it appears the port now (only after I used the SUDO command that sjunnesson posted) /dev/cu.wchusbserialalpha1310

so, use the sudo command if you are in yosemite

body:
_I am Antonis from codebender and we recently released drivers for the Mac._

If you want to overcome this problem, without disabling your computer's security settings, maybe I can help you with this! Codebender just released their Mac drivers package, which includes a new driver that supports the CH340G chip, on Yosemite and all other versions of OS X for Mac.

This will help you to install these drivers securely, and
all you have to do is to [download and install them](https://codebender.cc/static/walkthrough/page/3).

You can find more [information about the drivers in the codebender blog](http://blog.codebender.cc/2015/06/12/new-stuff-updated-mac-drivers/).

body:
once you have installed the driver, you should be able to use it with any IDE or program

but I doubt anyone would prefer the Arduino IDE to codebender


body:
A while ago, I found a library for the MAX72XX that had functions for writing text to the display, but unfortunately cannot find such library now.

Which would be the best library to use for a text and number display? I'm using LedControl but it is very awkward to use.

title: MAX72XX with 8 digit 7 segment display library

Answers: 1

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

I have a library for driving the MAX7219 chip connected to a 7-segment display. It is at: <https://github.com/nickgammon/MAX7219>

Example of use:

    #include <SPI.h>
    #include <bitBangedSPI.h>
    #include <MAX7219.h>

    const byte chips = 1;

    // 1 chip, bit banged SPI on pins 6, 7, 8
    MAX7219 display (chips, 6, 7, 8);  // Chips / LOAD / DIN / CLK

    void setup ()
      {
      display.begin ();
      display.sendString ("HELLO");
      }  // end of setup

    void loop () { }

In operation displaying a number:

[![MAX7219 display][1]][1]

More details at: [Interfacing LED displays with the MAX7219 driver](http://www.gammon.com.au/forum/?id=11516)

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


body:
I am having problems controlling a 3.5" Floppy Disk Drive with an Arduino Uno.

I have the floppy disk drive powered with a computer power supply that is switched on, and the Arduino powered by my computer's USB.  I have cut apart the ribbon of a 34-pin IDC connector to be able to route the pins to my Arduino.  I am able to turn the floppy disk motor on and move the read/write head back and forth, but I am never able to read any pulses from the Track-0 or Index pins.

I have pins 7, 15, 17, 19, and 25 from the floppy all grounded to my Arduino, and I have pins 8, 16, 18, 20, and 26 from the floppy connected to my arduino as output pins so I can control the drive.

I am expecting the Index to pulse when the disk motor makes a rotation, and for Track 0 to change when I am at the outside of the disk, but they are both always LOW.  Am I missing something?

**Here is the spec I found for the back of the floppy disk unit**

        2 /REDWC Input Density Select
        4 n/c N/A Reserved
        6 n/c N/A Reserved
        8 /INDEX Output Index
        10 /MOTEA Input Motor Enable A
        12 /DRVSB Input Drive Sel B
        14 /DRVSA Input Drive Sel A
        16 /MOTEB Input Motor Enable B
        18 /DIR Input Direction
        20 /STEP Input Step
        22 /WDATE Input Write Data
        24 /WGATE Input Floppy Write Enable
        26 /TRK00 Output Track 0
        28 /WPT Output Write Protect
        30 /RDATA Output Read Data
        32 /SIDE1  Input  Head Select
        34 /DSKCHG Output Disk Change/Ready

**Here a schematic of what I have hooked up**
***(The breadboard in this circuit diagram represents the IDC connector that is plugged into the 3.5" floppy drive.)***

![Floppy & Arduino Connections][1]

**Here is a photo of the IDC Connector and I labelled which wires are connected to the Arduino.**

![Labelled IDC Connector][2]

**Here's the code I am running.**

    //constants
    static const int IN = LOW;
    static const int OUT = HIGH;
    static const int pulseDelayTime = 6;

    //pins
    int indexPin = 2; //8 on the drive INDEX
    int track0Pin = 3; //26 on the drive. TRACK 0
    int dirPin = 6; //18 on the drive. DIRECTION
    int stepPin = 7; //20 on the drive. STEP
    int motorEnableBPin = 9; //16 on the drive. MOTOR ENABLE B

    unsigned long motorSpinTime = 1000UL; //in ms

    void setup() {

      //initial delay
      delay(3000);

      //setup serial monitor
      Serial.begin(9600);

      //setup pins.
      pinMode(dirPin, OUTPUT);
      pinMode(stepPin, OUTPUT);
      pinMode(motorEnableBPin, OUTPUT);
      pinMode(indexPin, INPUT);
      pinMode(track0Pin, INPUT);

      //turn the motor off initially
      digitalWrite(motorEnableBPin, HIGH);

      //print state here.
      printState("Setup done.");

      //spin the disk some.
      printState("Begin to spin motor");
      spinMotorForThisManyMs(motorSpinTime);
      spinMotorForThisManyMs(motorSpinTime);
      printState("Done spinning motor");

      //step read/write head all the way in.
      stepAllTheWayIn();

      //spin the disk some more.
      printState("Begin to spin motor");
      spinMotorForThisManyMs(motorSpinTime);
      spinMotorForThisManyMs(motorSpinTime);
      printState("Done spinning motor");

      //step read/write head all the way out.
      stepAllTheWayOut();

      //spin the disk even more.
      printState("Begin to spin motor");
      spinMotorForThisManyMs(motorSpinTime);
      spinMotorForThisManyMs(motorSpinTime);
      printState("Done spinning motor");

      //never completes.
      waitForIndex();
    }

    void loop() {
    }

    //spins the disk motor for a number of ms and prints the state
    void spinMotorForThisManyMs(unsigned long msToSpin) {

      //start spinning
      digitalWrite(motorEnableBPin,LOW);

      //delay.. keep printing the state
      unsigned long maxTimeMs = millis() + msToSpin;
      while(millis() < maxTimeMs ) {
        printState("Spinning");
      }

      //stop spinning
      digitalWrite(motorEnableBPin,HIGH);
    }

    //step the read/write head all the way to the center
    void stepAllTheWayIn() {
      for(int i=0;i<100;i++) {
        printState("Stepping In");
        stepInALittle();
      }
    }

    //step the read/write head all the way to the outside
    void stepAllTheWayOut() {
      for(int i=0;i<100;i++) {
        printState("Stepping Out");
        stepOutALittle();
      }
    }

    //print the state of the index and track
    void printState(const char* charPrint) {
      Serial.print(" Index:");
      Serial.print(digitalRead(indexPin));
      Serial.print(" Track:");
      Serial.print(digitalRead(track0Pin));
      Serial.print(" ");
      Serial.println(charPrint);
    }

    //move the head towards the outside a little
    void stepOutALittle() {
      digitalWrite(dirPin,HIGH);
      stepPulse();
    }

    //move the head towards the center a little
    void stepInALittle() {
      digitalWrite(dirPin,LOW);
      stepPulse();
    }

    //pulse the step pin
    void stepPulse() {
      digitalWrite(stepPin,LOW);
      delay(pulseDelayTime);
      digitalWrite(stepPin,HIGH);
    }

    //waits for the index to trigger. this never gets completed.
    void waitForIndex() {

      printState("beginning to wait for index pin to pulse");

      //start spinning
      digitalWrite(motorEnableBPin,LOW);

      //wait for pulse
      while(digitalRead(indexPin));
      //wait for end of pulse 0
      while(!digitalRead(indexPin));

      printState("end of waiting for index pin to pulse");

      //stop spinning
      digitalWrite(motorEnableBPin,HIGH);
    }

**Here is the output I am getting.**

  Index:0 Track:0 Setup done.
  Index:0 Track:0 Begin to spin motor
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Done spinning motor
  Index:0 Track:0 Stepping In
  Index:0 Track:0 Stepping In
  Index:0 Track:0 Stepping In
  Index:0 Track:0 Stepping In
  Index:0 Track:0 Stepping In
  Index:0 Track:0 Stepping In
  Index:0 Track:0 Stepping In
  Index:0 Track:0 Stepping In
  Index:0 Track:0 Stepping In
  Index:0 Track:0 Stepping In
  Index:0 Track:0 Stepping In
  Index:0 Track:0 Stepping In
  Index:0 Track:0 Stepping In
  Index:0 Track:0 Stepping In
  Index:0 Track:0 Stepping In
  Index:0 Track:0 Stepping In
  Index:0 Track:0 Stepping In
  Index:0 Track:0 Stepping In
  Index:0 Track:0 Stepping In
  Index:0 Track:0 Stepping In
  Index:0 Track:0 Stepping In
  Index:0 Track:0 Stepping In
  Index:0 Track:0 Stepping In
  Index:0 Track:0 Stepping In
  Index:0 Track:0 Stepping In
  Index:0 Track:0 Stepping In
  Index:0 Track:0 Stepping In
  Index:0 Track:0 Stepping In
  Index:0 Track:0 Stepping In
  Index:0 Track:0 Stepping In
  Index:0 Track:0 Stepping In
  Index:0 Track:0 Stepping In
  Index:0 Track:0 Stepping In
  Index:0 Track:0 Stepping In
  Index:0 Track:0 Stepping In
  Index:0 Track:0 Stepping In
  Index:0 Track:0 Stepping In
  Index:0 Track:0 Stepping In
  Index:0 Track:0 Stepping In
  Index:0 Track:0 Stepping In
  Index:0 Track:0 Stepping In
  Index:0 Track:0 Stepping In
  Index:0 Track:0 Stepping In
  Index:0 Track:0 Stepping In
  Index:0 Track:0 Stepping In
  Index:0 Track:0 Stepping In
  Index:0 Track:0 Stepping In
  Index:0 Track:0 Stepping In
  Index:0 Track:0 Stepping In
  Index:0 Track:0 Stepping In
  Index:0 Track:0 Stepping In
  Index:0 Track:0 Stepping In
  Index:0 Track:0 Stepping In
  Index:0 Track:0 Stepping In
  Index:0 Track:0 Stepping In
  Index:0 Track:0 Stepping In
  Index:0 Track:0 Stepping In
  Index:0 Track:0 Stepping In
  Index:0 Track:0 Stepping In
  Index:0 Track:0 Stepping In
  Index:0 Track:0 Stepping In
  Index:0 Track:0 Stepping In
  Index:0 Track:0 Stepping In
  Index:0 Track:0 Stepping In
  Index:0 Track:0 Stepping In
  Index:0 Track:0 Stepping In
  Index:0 Track:0 Stepping In
  Index:0 Track:0 Stepping In
  Index:0 Track:0 Stepping In
  Index:0 Track:0 Stepping In
  Index:0 Track:0 Stepping In
  Index:0 Track:0 Stepping In
  Index:0 Track:0 Stepping In
  Index:0 Track:0 Stepping In
  Index:0 Track:0 Stepping In
  Index:0 Track:0 Stepping In
  Index:0 Track:0 Stepping In
  Index:0 Track:0 Stepping In
  Index:0 Track:0 Stepping In
  Index:0 Track:0 Stepping In
  Index:0 Track:0 Stepping In
  Index:0 Track:0 Stepping In
  Index:0 Track:0 Stepping In
  Index:0 Track:0 Stepping In
  Index:0 Track:0 Stepping In
  Index:0 Track:0 Stepping In
  Index:0 Track:0 Stepping In
  Index:0 Track:0 Stepping In
  Index:0 Track:0 Stepping In
  Index:0 Track:0 Stepping In
  Index:0 Track:0 Stepping In
  Index:0 Track:0 Stepping In
  Index:0 Track:0 Stepping In
  Index:0 Track:0 Stepping In
  Index:0 Track:0 Stepping In
  Index:0 Track:0 Stepping In
  Index:0 Track:0 Stepping In
  Index:0 Track:0 Stepping In
  Index:0 Track:0 Stepping In
  Index:0 Track:0 Stepping In
  Index:0 Track:0 Begin to spin motor
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Done spinning motor
  Index:0 Track:0 Stepping Out
  Index:0 Track:0 Stepping Out
  Index:0 Track:0 Stepping Out
  Index:0 Track:0 Stepping Out
  Index:0 Track:0 Stepping Out
  Index:0 Track:0 Stepping Out
  Index:0 Track:0 Stepping Out
  Index:0 Track:0 Stepping Out
  Index:0 Track:0 Stepping Out
  Index:0 Track:0 Stepping Out
  Index:0 Track:0 Stepping Out
  Index:0 Track:0 Stepping Out
  Index:0 Track:0 Stepping Out
  Index:0 Track:0 Stepping Out
  Index:0 Track:0 Stepping Out
  Index:0 Track:0 Stepping Out
  Index:0 Track:0 Stepping Out
  Index:0 Track:0 Stepping Out
  Index:0 Track:0 Stepping Out
  Index:0 Track:0 Stepping Out
  Index:0 Track:0 Stepping Out
  Index:0 Track:0 Stepping Out
  Index:0 Track:0 Stepping Out
  Index:0 Track:0 Stepping Out
  Index:0 Track:0 Stepping Out
  Index:0 Track:0 Stepping Out
  Index:0 Track:0 Stepping Out
  Index:0 Track:0 Stepping Out
  Index:0 Track:0 Stepping Out
  Index:0 Track:0 Stepping Out
  Index:0 Track:0 Stepping Out
  Index:0 Track:0 Stepping Out
  Index:0 Track:0 Stepping Out
  Index:0 Track:0 Stepping Out
  Index:0 Track:0 Stepping Out
  Index:0 Track:0 Stepping Out
  Index:0 Track:0 Stepping Out
  Index:0 Track:0 Stepping Out
  Index:0 Track:0 Stepping Out
  Index:0 Track:0 Stepping Out
  Index:0 Track:0 Stepping Out
  Index:0 Track:0 Stepping Out
  Index:0 Track:0 Stepping Out
  Index:0 Track:0 Stepping Out
  Index:0 Track:0 Stepping Out
  Index:0 Track:0 Stepping Out
  Index:0 Track:0 Stepping Out
  Index:0 Track:0 Stepping Out
  Index:0 Track:0 Stepping Out
  Index:0 Track:0 Stepping Out
  Index:0 Track:0 Stepping Out
  Index:0 Track:0 Stepping Out
  Index:0 Track:0 Stepping Out
  Index:0 Track:0 Stepping Out
  Index:0 Track:0 Stepping Out
  Index:0 Track:0 Stepping Out
  Index:0 Track:0 Stepping Out
  Index:0 Track:0 Stepping Out
  Index:0 Track:0 Stepping Out
  Index:0 Track:0 Stepping Out
  Index:0 Track:0 Stepping Out
  Index:0 Track:0 Stepping Out
  Index:0 Track:0 Stepping Out
  Index:0 Track:0 Stepping Out
  Index:0 Track:0 Stepping Out
  Index:0 Track:0 Stepping Out
  Index:0 Track:0 Stepping Out
  Index:0 Track:0 Stepping Out
  Index:0 Track:0 Stepping Out
  Index:0 Track:0 Stepping Out
  Index:0 Track:0 Stepping Out
  Index:0 Track:0 Stepping Out
  Index:0 Track:0 Stepping Out
  Index:0 Track:0 Stepping Out
  Index:0 Track:0 Stepping Out
  Index:0 Track:0 Stepping Out
  Index:0 Track:0 Stepping Out
  Index:0 Track:0 Stepping Out
  Index:0 Track:0 Stepping Out
  Index:0 Track:0 Stepping Out
  Index:0 Track:0 Stepping Out
  Index:0 Track:0 Stepping Out
  Index:0 Track:0 Stepping Out
  Index:0 Track:0 Stepping Out
  Index:0 Track:0 Stepping Out
  Index:0 Track:0 Stepping Out
  Index:0 Track:0 Stepping Out
  Index:0 Track:0 Stepping Out
  Index:0 Track:0 Stepping Out
  Index:0 Track:0 Stepping Out
  Index:0 Track:0 Stepping Out
  Index:0 Track:0 Stepping Out
  Index:0 Track:0 Stepping Out
  Index:0 Track:0 Stepping Out
  Index:0 Track:0 Stepping Out
  Index:0 Track:0 Stepping Out
  Index:0 Track:0 Stepping Out
  Index:0 Track:0 Stepping Out
  Index:0 Track:0 Stepping Out
  Index:0 Track:0 Stepping Out
  Index:0 Track:0 Begin to spin motor
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Spinning
  Index:0 Track:0 Done spinning motor
  Index:0 Track:0 beginning to wait for index pin to pulse

  [1]: https://i.stack.imgur.com/pEHOT.png
  [2]: https://i.stack.imgur.com/DdFX0.jpg

**UPDATE:**
I am now receiving my expected results due to geometrikal's answer.   While researching this problem I found a few code examples of Arduino to Floppy Drive. I noticed that they were setting their input pins to HIGH, but I never realized why they were doing this.  After fixing my problem, I found this in some Arduino documentation (which made me realize the code examples I had were using an older version of the Arduino IDE):

"Prior to Arduino 1.0.1, it was possible to configure the internal pull-ups      in the following manner:"

    pinMode(pin, INPUT);           // set pin to input
    digitalWrite(pin, HIGH);       // turn on pullup resistors`

In Arduino 1.0.1+ you can do it this way.

    pinMode(pin, INPUT_PULLUP);

title: Controlling Floppy Disk Drive with Arduino

Answers: 2

body:
You should replace `int` with `unsigned long` in all locations where you deal with time in milliseconds.

The point is that `millis()` returns an `unsigned long`, thus using `int` to store `millis()` value, you have a loss of information due to automatic cast performed by the compiler.

The changes you have to perform are:

    unsigned long motorSpinTime = 1000UL; //in ms

and:

    //spins the disk motor for a number of ms and prints the state
    void spinMotorForThisManyMs(unsigned long msToSpin) {

      //start spinning
      digitalWrite(motorEnableBPin,LOW);

      //delay.. keep printing the state
      unsigned long maxTimeMs = millis() + msToSpin;
      while(millis() < maxTimeMs ) {
        printState("Spinning");
      }

      //stop spinning
      digitalWrite(motorEnableBPin,HIGH);
    }

Note that I have also performed some optimization in the waiting loop by calculating the maximum time once and then compare `millis()` directly to that value. This is not mandatory but I just find it a bit more clean.

body:
According to this (dead link):

http://bitsavers.trailing-edge.com/pdf/nec/FD1035_Product_Description_Jul84.pdf

> *This is an archived copy of the [FD1035 3.5" Floppy disk drive: Product Description July 1984 - PDF][1]:*
>
> *https://archive.org/details/bitsavers_necFD1035Pl84_876629*

The outputs are open-collector, so a pull-up resistor is required. You can instead enable the Arduino internal pull-ups on those pins by

    pinMode(indexPin, INPUT_PULLUP);
    pinMode(track0Pin, INPUT_PULLUP);

  [1]: https://ia801902.us.archive.org/3/items/bitsavers_necFD1035Pl84_876629/FD1035_Product_Description_Jul84.pdf


body:
I'm new to XBee and a colleague setup a sender/receiver pair. I'm using an usb breakout and reading the values using this [java XBee API][1] in Processing/Java.

The issue I'm having is two of the pins(analog 3 and 4) seem to have a strange alternating pattern and this makes it harder to read the values. Here's what I mean:

a recording of the plot I'm drawing of the values:
![analog plot][2]

and here are some values. I noticed there were duplicate entries, so I removed those:

    654,28
    65,28
    65,366
    52,366
    52,263
    607,263
    607,23
    45,23
    45,554
    164,554
    164,138
    393,138
    393,14
    33,14
    33,677
    432,677
    432,64
    77,64
    24,237
    24,345
    659,345
    659,29
    61,29
    74,378
    74,226
    455,226
    455,16
    42,16
    42,592
    225,592
    225,107
    348,107
    348,13
    27,13
    27,700
    515,700
    515,56
    60,56
    60,392
    372,392
    372,70
    98,70
    98,141
    12,141
    12,456
    663,456
    663,30
    64,30
    74,349
    74,224
    554,224
    554,20
    41,20
    41,600
    256,600
    256,96
    127,96
    127,87
    13,87
    13,502
    659,502
    659,37
    75,37
    75,251
    20,251
    20,364
    631,364
    631,25
    55,25
    55,436
    128,436
    128,165
    447,165
    447,16
    38,16
    38,618
    224,618
    224,107
    251,14
    25,14
    25,700
    535,700
    535,54
    67,54
    69,323
    69,235
    568,235
    568,21
    49,21
    49,503
    182,503
    330,128
    330,12
    13,12
    13,498
    665,498
    665,35
    76,35
    76,247
    47,247
    47,277
    313,277
    313,12
    22,12
    22,691
    513,691
    513,56
    157,56
    157,53
    18,53
    18,640
    169,640
    103,48
    103,105
    12,105
    12,389
    209,389
    209,30
    65,30
    65,353
    19,353
    19,282
    200,282
    200,18
    21,18
    21,681
    152,681
    152,54
    123,54
    123,47
    14,47
    14,526
    654,526
    654,37
    74,37
    74,260
    17,260
    17,387
    655,387
    655,29
    61,29
    61,375
    74,375
    74,249
    512,249
    512,18
    32,18
    32,678
    255,678
    255,92
    270,92
    270,11
    25,11
    25,319
    557,319
    557,53
    61,53
    61,165
    115,165
    115,133
    195,133
    195,18
    20,18
    20,317
    594,317
    594,48
    126,48
    126,41
    14,41
    14,281
    653,281
    653,40
    80,40
    80,96
    35,96
    35,189
    623,189
    623,25
    55,25
    55,191
    139,191
    139,123
    468,123
    468,16
    31,16
    31,306
    622,306
    622,45
    82,45
    82,90
    24,90
    24,345
    207,345
    207,32
    66,32
    66,347
    22,347
    22,247
    201,247
    201,18
    41,18
    41,616
    82,616
    82,82
    93,82
    93,147
    12,147
    12,472
    206,472
    206,33
    73,33
    73,287
    18,287
    18,274
    204,274
    204,19
    49,19
    49,526
    64,526
    64,103
    182,103
    182,14
    27,14
    27,701
    457,701
    457,61
    225,61
    225,19
    19,19
    19,654
    592,654
    592,48
    105,48
    105,125

Looking at the pattern I noticed the higher values occur every 3rd value but also the values seem to oscillate like on a sine wave. If I read only the 3rd value of each sensor that seems remove the 'gaps', but the sine wave pattern is still visible. When I physically get the two pots connected to analog pins 3 and 4 (index 2 and 3 in my plot) I can notice the maximum value either increases or decreases, but the sine pattern is still there.

I've also started going though the XBee manual and found this:

> Analog samples are returned as 10-bit values. The analog reading is
> scaled such that 0x0000 represents 0V, and 0x3FF = 1.2V. (The analog
> inputs on the module cannot read more than 1.2V.) Analog samples are
> returned in order starting with AIN0 and finishing with AIN3, and the
> supply voltage. Only enabled analog input channels return data as
> shown in the figure below. To convert the A/D reading to mV, do the
> following: AD(mV) = (A/D reading * 1200mV) / 1023

Unfortunately I'm not very experienced with electronics, but it looks like a linear mapping to me and I haven't found anything else pointing to this oscillation.

My naive approach would be to work out the period or this sine wave and see how much the amplitude changes when I physically turn the pots versus the 'default' position.

I've also started looking at signal processing and thought that potentially I could use a 'wavelet' to detect a pattern and then see difference between the expected one and the current signal, but that sounds a bit overkill.

Is my naive approach decent ? What's the simplest way to read values from a signal like this ?

  [1]: https://code.google.com/p/xbee-api/wiki/Processing
  [2]: https://i.stack.imgur.com/1VR74.gif

title: How to process this XBee analog pins signal?

Answers: 2

body:
Sounds like your pots are not connected correctly and you pick up noise. The waveform you are seeing could be from the mains, or another source. Stray magnetic fields from transformers etc. can couple and be picked up by your circuit and you will notice them if your input is of high impedance. The atmosphere is also full of electromagnetic radiation from human sources and from space, that you can also pick up. The longer wires that are connected to your high impedance input, the more noise you will pick up.

Your pots should be wired 1.2V-AIN-GND, with the 1.2V source being low impedance, coming from a power supply/regulator and not eg. a voltage divider. If your potentiometer is high impedance (say 100 kOhm), and it is connected with wires from eg. a breadboard, you might want to add a decoupling capacitor between AIN and GND. 0.1 uF would be a typical value. It will short out AC waveforms(noise) to ground.

body:
Sounds familiar .

First i will test whether i am reading something or just picking up random noise due to poor connection or error in coding (data conversion arithmetic etc).

Connect 1 pin to ground and another to 1.2V.

You should read 1024 and 0 on e 2 pins . If not check circuit and code.

Anyway

    Vadc = (ADC/1024) * Vref

Did you connect Vref ?


body:
I am working with a [Sainsmart Uno with SVG header pins][1].  This header is really convenient for hooking a servo to directly, so I have two servos connected to it on D9 and D10 and a 9v battery supplying power via the power jack.

Everything seems to work fine at first, but eventually (sometimes quickly), the board becomes unresponsive.  If, instead, I wire my servos to use the 5v pin on the Arduino (not from this SVG header), I don't run into this trouble.

Does anyone know if I am running into a limitation of this header Voltage pin?  Has anyone had any success using this mechanism to drive servos?  Certainly, I don't NEED to do it this way, but it sure is convenient.

  [1]: https://arduino.stackexchange.com/questions/304/what-are-the-svg-pins-for-on-the-sainsmart-uno-clone

title: Can I use the SVG headers on the SainSmart Uno to drive servos?

Answers: 0


body:
I found this wonderful breakout board based on [FT232][1]. I wonder if I can use this board for connecting my arduino to a USB dongle for 3g/GPRS connection ?

From what I understand this board can be connected to the serial data pins of the arduino board. And if I connect the USB dongle to the FT232 board, I should be able to run AT commands from the arduino board.

  [1]: https://www.sparkfun.com/products/9716#comment-53e7333cce395f8b068b4567

title: Connecting a Arduino to FT232

Answers: 1

body:
Unfortunately, no, as the FT232 would have to act as a USB host device. A [USB host shield][1] might work if someone has written driver code to support 3G modems.

  [1]: http://www.circuitsathome.com/products-page/arduino-shields/usb-host-shield-2-0-for-arduino


body:
I'm not sure if I'm being really really stupid, but why doesn't this work?

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

    void loop() {
      for (int x; x < 8; x++) {
        for (int y; y < 8; y++) {
          Serial.print(x);
          Serial.println(y);
          delay(100);
        }
      }
    }

When this does:

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

    void loop() {
      for (int x; x < 8; x++) {
        Serial.println(x);
        delay(100);
      }
    }

The first produces no output over Serial, whereas the second one prints out the numbers 0 to 7 as expected. I'm using a Teensy 3.1.

title: Nested For Loop

Answers: 1

body:
You are not initializing x and y.

When a local variable isn't initialized, it will "inherit" the value contained in the register assigned to the variable by the compiler. The fact that your single loop example worked is pure luck - the assigned register happened to contain 0 at that point in execution.

Change your nested loop like this:

    for (int x = 0; x < 8; x++) {
      for (int y = 0; y < 8; y++) {
        Serial.print(x);
        Serial.println(y);
        delay(100);
      }
    }

And it will work.

Note: Global variables, on the other hand, are guaranteed by the c++ standard to be initialized to zero. The compiler will make sure to write zeros to those memory addresses before the main program code executes.


body:
I am a newbie to the arduino world. And am trying to work out a configuration that does not involve USB.

I wonder if this configuration will work.

Are there any 3g modems that work on Rs232 interface. That should get rid of the USB compatibility that costs 3 times a arduino.

title: Using Arduino RS232 to a modem (only RS232)

Answers: 0


body:
I'm using FastLED with a custom board built around the ATMega32u4. When I set it to use Software SPI, everything works fine, but when I use hardware SPI it just hangs whenever it tries to write out the data (FastLED.show()).

I originally mocked this up on an Arduino Pro Micro and it worked fine there. That makes me think that it's a hardware issue but, as I mentioned, SPI output *does* work, but only when bit-banged. Which really doesn't make much sense.

I tested this by also just using the built in SPI classes and I get the same thing. No luck with hardware SPI.

Anyone else ever see something like this?

The schematic of my circuit is below.

![enter image description here][1]

  [1]: https://i.stack.imgur.com/4R7AW.png

title: Arduino: Hardware SPI hangs, bit-bang does not

Answers: 1

body:
According to [ATmega32u4 datasheet][1], section 17.2.1 (SPI / SS Pin Functionality / Master Mode:

> **If SS is configured as an input, it must be held high to ensure Master SPI operation.**

In your circuit, SS pin (#8 on package), also labeled as "**(SS/PCINT0) PB0**", is left unconnected.

Is it possible that PB0 is also configured as input somewhere in your program or libraries? In this case, it should be connected to Vcc.

  [1]: http://www.atmel.ch/Images/Atmel-7766-8-bit-AVR-ATmega16U4-32U4_ Datasheet.pdf


body:
Do Arduinos meet military standards?

If not, where does it fall short? Is it something internal to the chip which might be corrected via external circuit? How could I evaluate the potential of a device I'm building?

title: Do Arduinos meet military standards?

Answers: 5

body: It is not mil spec. Making something comply with milspec is a big, complex subject. (A subject I know very little about.)

body: Defiantly not. If you wanted to use it for very early prototyping then I think it would be fine. However, it really depends on the use because lets admit it Adriuno boards don't have huge amounts of processing power and are somewhat limited to capabilities.

body:
It depends on the application. For something like a rechargeable torch, Arduino might exceed the specifications. For a weapons system, NEVER (and **this is one of the *specific* prohibitions in the [license agreement][1]** - see section 1.5 *note: link currently broken*). You also have to consider that there's literally thousands of armies in the world and they all have different standards. What might be acceptable to one might not be acceptable to another. Hamas uses rockets I wouldn't consider safe for anything, and they use them effectively - the [Qassam rocket][2] would never meet US military standards but it works great for Hamas.

US military standards are so complicated, nobody can answer this question for you. You're gonna need an army of lawyers to do that... here's [a link][3] to some documents to get started though...

Please note there are multiple standards which may apply to a given device. For example, you will see common off the shelf desktop computers (running Windows) used for some things in a military installation, but they could never be used to control a vehicle. Bottom line - you're gonna need a lawyer to navigate this. (You are better off selling your devices directly to soldiers, if you can live with that if it fails.)

http://www.dsp.dla.mil/ - Terrible site - get used to that if you want to deal with govs.

OH BTW... if you want to use Arduino to prototype something, and you plan to remove "Arduino" later, running straight from the ATMega - that's the whole point of Arduino! It is a prototyping system, not intended to be used wholly in products. Arduino is very little more than a break-out board for the ATMega processor, a robust (kinda) power supply, and a runtime environment in C++.

  [1]: http://store.arduino.cc/index.php?main_page=conditions
  [2]: https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&uact=8&ved=0CB8QFjAA&url=http://en.wikipedia.org/wiki/Qassam_rocket&ei=6QvpU8HTAY7toASWroKwBg&usg=AFQjCNEo1p4fmf7z50ubVtBvXmItqD4nWQ&sig2=qJRL1_apQAqHK7O6Qn30cw&bvm=bv.72676100,d.cGU
  [3]: http://www.dsp.dla.mil/APP_UIL/displayPage.aspx?action=content&contentid=66

body: Your question is broad. My first reaction is to say No.  But in order to be very accurate (or fair), your should find the application standard. Military has an extensive library of standards ranging from manufacturing and testing.  Therefore, take a look at the standard regulating your application. Only after this assessment, the question of whether Arduino will suffice a military application will be accurately answered.

body:
> Do Arduinos meet military standards?

it meets some military standards but fails the others.


body:
I'm using a 5V [Arduino Pro Micro][1] ([schematic][2]).

For my project, I'm using the VCC pin to output power to an external device.  I need VCC to output 3.3V to the external device.  Can I open jumper SJ1 to reduce the voltage of the VCC pin without affecting the operation of the other parts of the unit?

![Circuit schematic][3]

  [1]: https://www.sparkfun.com/products/12640
  [2]: http://dlnmh9ip6v2uc.cloudfront.net/datasheets/Dev/Arduino/Boards/Pro_Micro_v13.pdf
  [3]: https://i.stack.imgur.com/ZzMmK.png

title: Can I change VCC pin to 3.3V on a 5V Arduino Pro Micro?

Answers: 4

body: No. If you change the voltage to 3,3 Volt you also have to change the crystal to 8MHz and reprogram the ATmega32u4 to meet the new frequency.

body:
I'm pretty sure that, despite the schematic provided, you will find that the 5V Pro Micro actually has a 5V regulator onboard. So even if you open the jumper, it will still be powering the Atmega32u4 at 5V (technically 5V minus diode voltage drop and regulator dropout voltage).

You could change the regulator for a 3.3V one using a hot air station and solder paste *and* open the jumper, but as other posters have commented, you would still be running the Atmega beyond spec at 16MHz and 3.3V.

body: You can, actually albeit 32u4 at 16MHz at 3.3V is outside of the safe operating area, it worked for me perfectly. Also for others :) google for it.

body:
I had the same issue on my cheap 5V @ 16Mhz Pro Micro from ebay. I have the 16Mhz crystal and a voltage regulator marked S2PC.
The J1 was not bridged and I was only getting 3.3V on the digital pins... wait a sec that should be 5V!!
I Went ahead and bridged the J1 jumper and now I am getting 5V on my digital pins! Not sure what is going on behind the scenes with the J1 jumper open with this hardware but I'm thinking it may have been overclocking the chip while running at the lower voltage.
Going to let it run over night and see if something doesn't blow but it looks like they may have just forgot to bridge that J1 whilst mass producing both the 3.3V and 5V versions of this board.


body:
I have arduino UNO hooked up with wtv020-sd-16p and it works fine, playing audio files - speaker is connected right to the WTV020's pin #4 and #5. However, volume is rather low. So I have ordered LM386 amplifier module. I have wired it's IN pin with WTV020's pin #2 AUDIO-L. But no sound comes out of speaker. I can hear only some scratches from the speaker while arduino is running.

LM386 is pretty easy, only VCC, IN and GND pins, so there is nothing much to screw up. I am wondering, what could be the problem ?

Thanks for any help or hints in advance.

EDIT: Only to note, when WTV020 is playing sound, speaker goes completely mute. When it doesn't play sound, little scratchy sounds can be heard from speaker. Maybe it could help with analysis ?

title: LM386 module not working

Answers: 1

body:
>when WTV020 is playing sound, speaker goes completely mute. When it doesn't play sound, little scratchy sounds can be heard from speaker. Maybe it could help with analysis

Indeed - what you are describing sounds like the DC component of the Arduino's output is outside the workable range of the amplifier, effectively cutting it off.  When there is no output, the voltage is within range and little bits of noise are able to be amplified.

You should be able to fix the cutoff problem with a series capacitor to block the DC component of the input, allowing only the AC signal through - a common technique for coupling between stages in Audio and RF systems.

The value of the capacitor will depend on the impedance of the circuit it is driving.  A bare input to many chips could use a quite small value, while a circuit with feedback or a voltage-divider volume control might require a larger or carefully chosen one.


body:
thanks for taking the time to read this, I really appreciate it.
I am very new to Arduino and the Micro controller world so please forgive my ignorance.

So I have an old 7 segment display that displays outside temperature, what i want to do is read the temp into the Arduino and light up an LED if the temperature gets high, and a different color if the temp gets low.

I know i can use a thermometer and plug it into the Arduino and go from there, but that would be cheating. So my question is, can i read each pin of the 7 segment display and translate that into a number into the Arduino?

- Task: **Read** a dual  10 pin 7 segment by **jumping** wires into the Arduino.

- Setup: I am using the code and setup found here: "http://blog.rastating.com/using-a-7-segment-led-display-w-arduino-uno/" to display a number (21) for testing purposes. I want to jump the pins into another Arduino and read "21"

please see pictures.

Any help would be very very appreciated!!

Thanks again for reading.

![This is the main goal.][1]

![Another picture of the main goal.![\]\[2\]][2]

  [1]: https://i.stack.imgur.com/Da26i.jpg
  [2]: https://i.stack.imgur.com/gNJto.jpg

This last picture shows "21" using the code and set up on the above link.
I want to jump another Arduino into the breadboard and read "21" or any other temperature (depends on outside thermometer) into the serial monitor. Now the challenging part is the code, Im not really good at coding but i understand if this had 1 pin for each LED i would just read each one and translate it into the serial monitor. However this only has 10 pins therefore represents a challenge.

Any input is greatly appreciated, I dont even know how to start.

title: Reading a 10 pin 7 segment (2 digits) sing Arduino 1. Please Help!

Answers: 4

body:
Your display is multiplexed, so you will need to monitor not only the segment lines but also the digit lines.

First figure out if your display is "common anode" or "common cathode" as the logic in one case will be inverted from that of the other.

For your test case, you can write the driving and reading arduinos to the display in the same way, but configure all the connected pins on the reading one as inputs.

The tricky part is going to be detecting when the segment select has changed, but you could do it by storing the current value of each select pin, and then reading the new value.  If you see that the old value was inactive and the new value active, then wait a tiny amount of time and read all of the segment lines.  You want to wait long enough to make sure that the data lines have been driven to match, but no so long that you get the data for the next digit instead.  If you have access to a scope, you can find the best value, but you could also experiment by making the delay short until you get wrong data, making it long until you get wrong data, and then picking an intermediate value.

You may find it easiest to read all 7 or 8 segment lines into a single byte value, and then compare it to each element in the lookup table you used in the driver code until you find a match.

If you don't know the exact wiring of the segments on the unknown target board, consider printing the bytes to the serial monitor as you cause the displayed values to change (cup of ice water, cup of hot water...) and taking notes of the segment values vs. the digits you see display.  It will be a puzzle, but one you should be able to figure out.

body:
First of all, make sure that the voltage is below 5V (but above 2.5V so it can register as HIGH on a digital pin). If not, it will either fry your Arduino or won't work.

As for the code, you can do one of the two following things:

 - Use a library like **[PinChangeInt](http://playground.arduino.cc/Main/PinChangeInt)** to help you detect when and what changed.
 - Store the data and check every so often.

Chris Stratton had a good idea with the byte and compare it. To do this, you would do something like this:

    byte data = 0;
    if(digitalRead(10) == HIGH) {
      data |= B00000001;
    }
    if(digitalRead(11) == HIGH) {
      data |= B00000010;
    }
    if(digitalRead(12) == HIGH) {
      data |= B00000100;
    }
    //...

Basically, this is *bit-wise math* that sets one bit of your byte to a 1. If it is a 0, then you leave it alone (all bits default to 0 because of how I declared `data`).

If pins 10 and 12 were HIGH, the byte would look like this in binary:

    00000101

body:
so I realized that the 2 pins that are driving this toggle at 4kHz, when one is on the other is off, but there is a 6usec time when both pins are on. So what im trying to do now is adding "if right bit is == 1, if A=1 b=0 c=1 d=1... and so on" then number = 6 then scan for it. Im not sure how to use that library.

    void loop() {
    // read the input pin:
    //int buttonState = digitalRead(pushButton);
    int State_A = digitalRead(A);
    int State_B = digitalRead(B);
    int State_C = digitalRead(c);
    int State_D = digitalRead(D);
    int State_E = digitalRead(E);
    int State_F = digitalRead(F);
    int State_G = digitalRead(G);
    int State_DP = digitalRead(DP);
    int State_RIGHT = digitalRead(RIGHT);
    int State_LEFT = digitalRead(LEFT);

    if (State_LEFT==1)
    {
     if(State_A==0 & State_B==1 & State_C==0 & State_D==0 & State_E==0 & State_F==0 & State_G==0)
    {
    number=6;
    Serial.println(number);
    // Serial.print(State_LEFT);
    }

i plan to add that for every digit. is there any easier way to do that?

body:
What you are trying to do is tricky and awkward, and probably not worth the trouble.

It's also above your current skill level, both in hardware and software.

As the other poster has said, the display is likely multiplexed. If so, it sends a value to 1 digit, then to the next, and alternates them quickly. Only one digit at a time is actually lit.

It's also possible that the digits are latched. The processor sends a value to one digit at a time and that digit's circuitry remembers the value until it changes again. However that's  less likely because it's more complex and expensive to do

To decode a multiplexed display you'll need to figure out how the multiplexing is done. There are lots of different ways it could be done.

You say it's common anode. It might have the anodes of a digit wired together, and have them both connected to the controller. The anode that's currently being displayed would be connected to +5, and the cathodes of like segments from each digit would be wired together in parallel. To drive a digit, the control circuitry would connect the anode of that digit to the positive supply, and connect the segments to be displayed to ground. All other connections would be left floating. Then it would disconnect the anode of the first digit and connect the anode of the other digit to the positive supply.

The display may also have a logic level that determines which segment is being driven. For a 2 digit display all you'd need is one line, and a HIGH would drive 1 digit and a LOW would drive the other digit.

A logic analyzer would help you sort this out, but you need to know how to use it.

You might also try researching the thermometer you're using and see if you can find a schematic for it, in the documentation, the manufacturer website, or in a patent

Once you figure out how to read the segment values from each digit, you will need a truth table that maps segment values to numbers, and will need to do a lookup. That is intermediate level C programming.


body:
I have a project with leds and sensors, this is my first project in Arduino and I want to know if it need resistors and how and where?

I use 16-Bit I/O Expander [MCP23017][1] for leds and multiplexer [CD4051][2] for sensors [LM35][3]

![My design][4]

  [1]: http://ww1.microchip.com/downloads/en/DeviceDoc/21952b.pdf
  [2]: http://pdf.datasheetcatalog.net/datasheets/120/109150_DS.pdf
  [3]: http://www.ti.com/lit/ds/symlink/lm35.pdf
  [4]: https://i.stack.imgur.com/jUCjl.jpg

title: Sensors and leds. This need resistors? and how?

Answers: 1

body:
You will definitely need resistors for each LED connected to MCP23017 circuits.

This is necessary because without resistor the following is likely to happen:

- burn each LED that is lit on as it would be fed too much current
- burn the MCP23017 because it is rated for 125mA maximum (20mA per output pin)

The resistor to use normally depends on the color of each LED as those LEDs have different electrical charasteristics.

Typically one LED (3 or 5mm) needs no more than 20mA to be lit (lower current such as 10mA is generally provides enough light).

One other important LED characteristic is its **forward voltage**, which depends on the color.

[This link][1] will help you calculate the "ideal" resistor for each LED.

For the sensors part, I see no reason to use any resistor to connect them to 4051 circuits.

One last important point is related to the use of **I2C** bus by the MCP23017 circuits. [I2C bus][2] is "open drain" and thus requires pullup resistors for both **SCL** and **SDA** lines.

  [1]: http://led.linear1.org/1led.wiz
  [2]: http://en.wikipedia.org/wiki/I²C


body:
I'm currently studying embedded systems on eDx.
https://courses.edx.org/courses/UTAustinX/UT.6.01x/1T2014/info (must login to see)
http://users.ece.utexas.edu/~valvano/edX/index.html (don't need to login)
and I found out that TM4C123 is quite similar to Arduino.
but I haven't worked TM4C123 yet.(I ordered it and I'm waiting for it)
 I don't know much about it.
and it's not that popular as Arduino I guess.
so If anyone has used Tm4C123, please give me some information compared to Arduino.

title: Is TM4C123 similar to Arduino?

Answers: 2

body:
The Tiva C LaunchPad is comparable to the Arduino Due in power and capabilities, but is incompatible with the stock Arduino ecosystem. It uses "BoosterPacks" rather than Shields, and Code Composer Studio (or other [some non-gratis] tools) instead of the Arduino IDE and libraries.

The Energia IDE is a port of the Arduino IDE and significantly simplifies configuration and programming Tiva C launchpads.

Beware of odd quirks with the Tiva C Launchpad board, such as the 0-ohm shunts that must be removed if you want all pins to be completely independent.

body:
I have completed the edX course, and the TM4C123 is significantly different to the Arduino from a programming perspective. Each family of microcontrollers have (on the surface) a fair amount in common - GPIO pins, an ADC or two, timers etc. However the way these work internally are very different - different registers, different process for using them, different gotchas to look out for, etc. If you're looking at tackling a new MCU family, be prepared to effectively learn a new "language".

Incidentally, the Launchpads from Texas Instruments have a processing-based language similar to the Arduino - called Energia - which should work on your TM4C123.

Enjoy the course, I did.


body:
I want to use xbee's to communicate between two different arduinos.  I'm using [this tutorial](http://youtu.be/mPx3TjzvE9U) as a guide to setup my xbee's. I've already used XCTU to setup one xbee as a router and another as a coordinator (both in ZIGBEE AT mode).  I used XCTU's terminal feature to verify that info was being sent and received properly.

Basically, I have both arduinos connected to the same PC via USB cables, but the communication is taking place through the Xbee's.  I also made sure to disconnect the TX & RX wires when uploading the sketches to avoid an AVRDUDE error.

I wanted to test the communication by sending a "hello world" message once every five seconds, from the router to the coordinator.  To do this, I wrote the following code:

    //Code for Arduino attached to Xbee in Router AT mode
    void setup(){
     Serial.begin(9600);
    }

    void loop(){
      Serial.println("Hello World!");
      delay(5000);
    }

and

    //Code for Arduino attached to Xbee in Coordinator AT mode
    void setup(){
      Serial.begin(9600);
    }

    void loop(){
      if (Serial.available()>0){
        Serial.write(Serial.read());
      }
    }

I checked the serial monitor for the arduino connected to the router, and it does exactly what I expected to see:  a new Hello World message once every 5 seconds.  However, the serial monitor on the arduino connected to the coordinator does not produce the desired effect:  ***the "hello world" message instantly displays the message over a hundred times per second and repeats without end, each time on a separate, new line***.  Sometimes, when I turn the serial monitor on, the message instantly appears with a few repetitions before displaying some strange characters and stopping altogether.

I'm not sure if the problem is with the serial monitor or with the xbee.  Any help with this problem would be greatly appreciated.

title: Serial.write displaying repeating output from Xbee communication

Answers: 1

body:
Code is correct and it does what it is asked to. The receiver code reads the RX pin of arduino which is connected to the Xbee. The same pin is used by the FT232 interface IC to send data to your computer through USB.

The "hello world" you send is received by the Xbee and is send to microcontroller and FT232 at same time as that pin is shared between them. Thus the "hello world" will be seen in serial monitor, first time from Xbee and second time, from `Serial.write(Serial.read())` of the program.

Also check whether the settings are correct from [this tutorial][1], as Xbee will not be configured as P2P.

![enter image description here][2]

  [1]: http://www.ladyada.net/make/xbee/arduino.html
  [2]: https://i.stack.imgur.com/4AxOG.png


body:
I have seen several references where the solution to interfacing a 5V Arduino with a 3.3V nRF24L01+ was to power the nRF24L01+ externally.

How do I do this?  The ground of the nRF24L01+ is connected to the Arduino; can I simply attach 3.3V power between the power and ground pins of the nRF24L01+?

title: Externally Powering a 3.3V device (nRL24L01+) with a 5V Arduino Pro Mini?

Answers: 3

body:
Yes, You can.
In any communication system, each module should have the same reference point of operation, or else the line is said to float. Here it is GND of arduino mini and GND of nRF24L01+.

body:
you can download the references from this link: https://s3-ap-northeast-1.amazonaws.com/sain-amzn/20/20-019-102/NRF24L01.rar
Hope the information may be helpful. Cheers!

body:
To connect the nRF24L01+ to a 5V Pro Mini you will need external 3.3V power supply to power the nRF24L01+.  The ground for the Pro Mini and the ground for the nRF24L01+ should be tied together to ensure a common ground reference.

The inputs to the nRF24L01+ are 5V tolerant so you will not need a level shifter to convert the 5V Digital IO on the Pro Mini to 3.3V. Be aware the not all 3.3V devices have 5V tolerant inputs like nRF24L01+.

You might want to look into using a [3.3V Pro Mini](https://www.sparkfun.com/products/11114) with that you should be able to use the regulated 3.3V power on the Pro Mini to power the nRF24L01+. Be aware that the 3.3V Pro Mini only runs at 8MHz instead of 16MHz.


body:
I am having problems with values i get from Pololu MinIMU-9 boards's magnetometer. I am using Arduino-micro and the arduino library from Pololu. The sensor on the board is 3 axis accelero- and magnetometer LSM303.
The problem is - the highest value always seems to be in vertical axis, not horisontal, as i would expect.

For example, here is the data i got when i put sensor flat on the table and made 360 clockwise turn in horizontal plane:
(values are X Y Z)

    -6 102 -516
    -11 103 -515
    -11 103 -515
    -21 102 -514
    -31 109 -515
    -40 114 -512
    -57 116 -509
    -57 116 -509
    -77 111 -507
    -93 109 -506
    -104 106 -507
    -104 106 -507
    -114 99 -508
    -126 88 -504
    -131 74 -507
    -142 52 -507
    -142 52 -507
    -151 31 -506
    -150 4 -509
    -147 -27 -513
    -147 -27 -513
    -133 -60 -513
    -119 -80 -519
    -112 -87 -517
    -102 -97 -521
    -102 -97 -521
    -89 -101 -522
    -77 -101 -524
    -50 -104 -527
    -50 -104 -527
    -43 -105 -529
    -14 -98 -532
    2 -92 -535
    23 -92 -535
    23 -92 -535
    36 -81 -534
    66 -54 -534
    76 -32 -531
    76 -32 -531
    76 -21 -532
    78 -7 -531
    85 10 -528
    91 39 -524
    91 39 -524
    94 50 -524
    91 63 -524
    76 75 -525
    76 75 -525
    63 82 -526
    47 93 -525
    44 98 -522
    44 98 -522
    38 104 -521
    26 110 -521
    26 112 -518
    21 116 -519
    21 116 -519
    18 116 -518
    12 120 -517
    11 120 -515
    11 120 -515
    8 120 -517
    5 122 -515
    -5 123 -514

Turning the sensor "upside down" and then rotating it in horisontal plane again gives similar results, only Z axis has positive 500+ value.

Shouldn't the magnetometer always point in the direction of the magnetic field - in X or Y direction?
I have tried this in different rooms and buildings and got the same results.
Rotating the sensor on other axes yields the same results - vertical axis has the largest (and constant) value.

For reference, here is the code i used to get the values.

    #include <Wire.h>
    #include <LSM303.h>
    LSM303 compass;

    void setup()
    {
      Serial.begin(115200);
      Wire.begin();
      compass.init();
      compass.enableDefault();
    }

    void loop(){
      compass.readMag();
      Serial.print(compass.m.x);
      Serial.print(" ");
      Serial.print(compass.m.y);
      Serial.print(" ");
      Serial.print(compass.m.z);
      Serial.print("\n");
      delay(100);
    }

title: Strange values from LSM303 Magnetometer

Answers: 1

body:
The earth's magnetic field is not parallel with the ground. In some locations it can be pointing more down than across.

NOAA has a [magnetic field calculator][1] where you can enter you latitude and longitude. For example, I am located at approx  19deg S 147degE and the field is

    North Comp    East Comp    Vertical Comp    Total magnitude
    32,434.4 nT   4,280.6 nT   -36,035.1 nT     48,670.7 nT

So the downwards strength is more than the other two combined for my location. I'm guessing the calculator will also show a very strong down component for your location.

Some other things to be aware of are that the LSM303DLHC magnetometer can have quite large offsets, up to the equivalent of 2 earth magnetic fields, and therefore requires calibration. Also hard and soft iron distortions can affect the readings.

Edit: Please see my answer [here][2] for methods to calibrate the sensor.

  [1]: http://www.ngdc.noaa.gov/geomag-web/#igrfwmm
  [2]: https://electronics.stackexchange.com/questions/22144/magnetometer-∞-shaped-calibration/22271#22271


body:
I have implemented a PWM controlled LED backlight for the LCD in my Arduino Uno design. One LCD backlight pin is connected to +5V, the second to the ground via 220 Ohm resistor and MOSFET controlled from a PWM capable D9 pin.

Everything seems to work fine, I do not see any oscillation, but after some reading about PWM I am not sure if I perhaps should connect a 100 uF capacitor to smooth the voltage?

Is the MOSFET even necessary? It seems backlight is drawing about 5 mA - can I perhaps drive it directly from the D9 pin, using the resistor? (It seems another user in https://arduino.stackexchange.com/questions/1805/do-i-need-to-use-a-resistor-if-i-am-using-a-potentiometer-to-control-an-leds-br?rq=1 is controlling brightness without any of those.)

title: Arduino LED backlight - should PWM be used with transistor or capacitor?

Answers: 1

body:
**You don't need the MOSFET, you don't need the capacitor, you _do_ need the resistor.**

The pins on your Arduino can deliver up to 20mA comfortably, so in this case there is no need for the MOSFET. However, if you were to replace your backlight with a high power LED, your current setup will work just fine.

Without a capacitor, your PWM is a nice square wave. The cap will, depending on its capacity and the resistor in your circuit, turn that into a more rounded waveform, or very ripply DC. Whichever is the case, it will not benefit the (dimming of) your LED. With some bad luck it will even introduce flickering instead of preventing it!

The reason why you should still use the resistor is to prevent the LED from drawing too much current. Without it, it's simply a game between the LED and the Arduino pin to see who will burn first. Whoever wins, you'll end up with a destroyed backlight or fried Arduino. Adding a component costing a few cents can prevent that.


body:
I am new to Arduino (and computer programming in general), so I apologize if this question  looks silly.

Once I set up a basic arduino-LED connection, I have problems sending INTEGERS to arduino through the serial port. I can easily send characters such as 'm', 'o' and so on.. However if I send a number it looks like it simply does not get it.

Here is the Arduino code, ideally it should get a value from the usb port through python or the serial monitor and then adjust the brightness of the LED according to the value. (value must be in range [0,255]).

NOTE: I am using ARDUINO UNO and PYTHON 3

//--------------------------

    int LED = 10;
    int number;

    void setup(){

    pinMode(LED,OUTPUT);
    Serial.begin(9600);
    }

    void loop(){

    number = Serial.read();
    Serial.print(number);
    Serial.print('\n');
    if(number == -1){
    number = 0;
    }

    else if(number > 255){

    number = 255;

    }

    else if(number < 0){

    number = 0;
    }

    analogWrite(LED,number);
    delay(1000);
    }

However, when I input a value into the Serial port or through Python, for instance 0, it gives me 48 as answer (which, interestingly, is the ASCII code for 0!) and lights up the LED which is not what should happen since at 0 the LED should be off!!
I am missing something but I cannot find what... Could you please tell me what is wrong?

Here is the code I use in Python:

    import serial
    import time
    try:
        arduino = serial.Serial(port,speed)
        time.sleep(2)
        print("Connection to " + port + " established succesfully!\n")
    except Exception as e:
        print(e)

    #Note: for characters such as 'a' I set data = b'a' to convert the data in bytes
    #However the same thing does not work with numbers...
    data = 0
    data = arduino.write(valueToWrite)
    time.sleep(2)
    arduino.close()

what am I doing wrong or misunderstanding? Thank you.

title: How to send numbers to Arduino UNO via Python 3 and the module serial

Answers: 2

body:
`Serial.read()` reads only **ONE** character from the serial port and returns its ASCII value, which explains the `48` you got.

To read a complete number, you have 2 options:

1. Use `Serial.parseInt()` that reads as many characters as needed and performs the conversion before returning the read number as an `int`. Please further check the [reference][1] here.
2. You read eachn character in a loop (with `Serial.read()`) until the last one, put each read charcater into a buffer (`char` array) then convert the resulting string to a number with the standard C function `atoi`.

Of course, the first option is the easiest one but it will return `0` if nothing is read after a 1s timeout (configurable with `Serial.setTimeout()`).

  [1]: http://arduino.cc/en/Serial/ParseInt

body:
Parsing on the Arduino can be slow and time-consuming (which is bad if you use clock prescaling or have time-critical tasks), so let's do it in Python.

The problem is that you're sending the numbers as ASCII whereas you need to be sending them as raw binary. This is where <a href="https://docs.python.org/3/library/struct.html">`struct`</a> comes in.

    3>> import struct
    3>> print(struct.pack('>B', 0))
    b'\x00'
    3>> print(struct.pack('>B', 255))
    b'\xff'
    3>> print(struct.pack('>2B', 255, 0))
    b'\xff\x00'
    3>> print(struct.pack('>H', 9000))
    b'#('

So what you really want is:

    data = arduino.write(struct.pack('>B', valueToWrite))

or something to that effect.


body:
When I use JSSC and call `serialPort.readLine(event.getEventValue())` from `public void serialEvent(SerialPortEvent event)` I've got fragments, not all string. What I must do to get all string from begin to `"\r\n"`? What I must do to get all string from my start marker (like `"[start]"`) to my stop marker (like `"[stop]"`)? What to modify in this code:

    private static class PortReader implements SerialPortEventListener {
        public void serialEvent(SerialPortEvent event) {
            if(event.isRXCHAR() && event.getEventValue() > 0){
                try {
                    String data = serialPort.readString(event.getEventValue());
                    serialPort.writeByte((byte) 1);
                }
                catch (SerialPortException ex) {
                    System.out.println(ex);
                }
            }
        }
    }

title: How to use readLine from JSSC

Answers: 1

body:
The event gets fired when a single character is received, not the whole string. You have to build the string up until you get to `\r\n` and then process it. This is my code for a similar project. It uses a protocol where `>` signifies the start of a message and `\r` signifies the end. `processMessage` is a function to process the entire message and update GUI elements etc. It is invoked using `runLater` because the serialEvent function will be on a different thread to the GUI thread.

    StringBuilder message = new StringBuilder();
    Boolean receivingMessage = false;
    public void serialEvent(SerialPortEvent event) {
        if(event.isRXCHAR() && event.getEventValue() > 0){
            try {
                byte buffer[] = serialPort.readBytes();
                for (byte b: buffer) {
                    if (b == '>') {
                        receivingMessage = true;
                        message.setLength(0);
                    }
                    else if (receivingMessage == true) {
                        if (b == '\r') {
                            receivingMessage = false;
                            String toProcess = message.toString();
                            Platform.runLater(new Runnable() {
                                @Override public void run() {
                                    processMessage(toProcess);
                               }
                            });
                        }
                        else {
                            message.append((char)b);
                        }
                    }
                }
            }
            catch (SerialPortException ex) {
                System.out.println(ex);
                System.out.println("serialEvent");
            }
        }
    }

A simpler version for you might be the following. `processMessage` is called whenever a `\r` or `\n` is received and there are some bytes in the message.

    StringBuilder message = new StringBuilder();
    public void serialEvent(SerialPortEvent event) {
        if(event.isRXCHAR() && event.getEventValue() > 0){
            try {
                byte buffer[] = serialPort.readBytes();
                for (byte b: buffer) {
                        if ( (b == '\r' || b == '\n') && message.length() > 0) {
                            String toProcess = message.toString();
                            Platform.runLater(new Runnable() {
                                @Override public void run() {
                                    processMessage(toProcess);
                               }
                            });
                            message.setLength(0);
                        }
                        else {
                            message.append((char)b);
                        }
                }
            }
            catch (SerialPortException ex) {
                System.out.println(ex);
                System.out.println("serialEvent");
            }
        }
    }

**Edit:**

Two things fixed:  1. Using `StringBuilder` instead of `String` to save making a lot objects every time the message is incremented. 2. Make a copy of the message string before passing to `runLater` otherwise when it does run it will use the up to date version of the string, which could have new characters, and thus cause problems.

**Edt 2:**
On Windows I found it needed `if(event.isRXCHAR() && event.getEventValue() > 0)` as the event would sometimes be fired with 0 bytes causing a null point exception in `for (byte b: buffer)`


body:
I bought an Arduino-on-breadboard kit. I have several PCs with serial ports, and now I'm being told I need a USB-to-serial converter. I thought I was ready to start uploading sketches, so how can I do this?

I'm able to understand serial communications and am capable of wiring a [MAX232][1] chip into a [breaduino][2] if necessary, but I'm not sure it will work, so to save some time I'm asking, mostly because I was unable to figure it out with Google searches alone.

PS: I also have a stk500, but then I would be out of the easiness of using Arduino sketches and the programming language. I need the fastest route to prototyping/testing my sketches.

  [1]: https://en.wikipedia.org/wiki/MAX232
  [2]: https://hackaday.io/project/43857/gallery#93070cbab9a55ed645fc2aa7dc3c54c3

title: Arduino serial port programming

Answers: 2

body:
If your PCs have real RS-232 serial ports (rare these days), you can use those directly.  Otherwise, you will need a USB<->RS-232 serial adaptor cable.

**Correction:**  I thought my Arduino did have an RS-232 port, but I was thinking of another board.  If your board only has a TTL-level serial port (ie. direct from the ATMega328), then you need either an RS-232 level translator, or a USB<->TTL serial cable.  A suitable cable is available from Adafruit (and no doubt, others).

body:
![enter image description here][1]An RS232 port wired via a level converter (as you mentioned max232) and a 1uF capacitor between RTS and "Arduino reset pin" [Getting started with Arduino][2].

The capacitor is to trigger a reset on the Arduino so the bootloader kicks in and awaits a "Arduino sketch" via the serial port.

Your setup is AKA "Arduino Bare bone".

  [1]: https://i.stack.imgur.com/6a9HT.jpg
  [2]: http://tronixstuff.com/2010/06/14/getting-started-with-arduino-chapter-ten/


body:
I'm having an issue programming the Arduino Uno with Sparkfun's MAX3232 breakout board attached.  Sometimes the Arduino IDE won't see the Uno plugged in.  I'm thinking of  connecting a switch to the GND or the 3V - 5.5V pin so I don't have to disconnect the breakout board when programming.  Are there any better solutions?

Sparkfun link: https://www.sparkfun.com/products/11189

title: Issues programming Arduino Uno with Sparkfun's MAX3232 breakout board

Answers: 1

body:
Switching the power off to the MAX3232 appears to be okay.
There are no components connected to the Rx and Tx lines on the breakout board to complicate it.

Unfortunately the break out does not give access to pin 1, EN which is "Enable Control", or pin 18 SHDN "Shutdown Control". AFAICT they could have been used to turn off the receiver and transmitters of the MAX3232. That would have been ideal. Maybe contact Sparkfun and suggest the improvement to put them on pads for folks to use, and offer to beta test it :-)

The datasheet for the MAX3232 says that it is able to withstand a continuous short on the Tx line, so it sounds pretty tolerant to minor abuse. Also, the diagrams dont show any pull-ups on the MOS/TTL Tx line. So I would expect it t be okay if you shut the power off, but continued to wiggle the Tx Rx pins.

An alternative would be to disconnect the Tx pin from the Arduino, so that the MAX3232 wouldn't interfere with the host PC's USB comms. It sounds like the thing on the RS232 connection will ignore data it receive while the Arduino is being programmed. If that is not true, then it would need to be disconnected too.

At the moment, switching off power looks like a reasonable approach.
Disconnecting Tx and Rx also looks reasonable, and slightly better than powering the MAX3232 off.

Do you know how you want to do that?

NB: The MAX232 datasheet shows that part should not be driven by a high when the chip is unpowered. However the MAX3232 datasheet does not carry that warning. My preference would be to use the MAX3232 signals 'EN' and 'SHDN'. However those are not available on the breakout. I'd recommend having the part powered, and disconnecting Tx and Rx from the Arduino.


body:
I'm driving a large stepper motor via a GeckoBoard G213V and arduino UNO and I have that mostly working fine. However, I'd like to 'release' the stepper so it can swing freely.

There's two reasons I want to do this:

1) (Most important) I want the rotated object to naturally swing back to the 0 position thanks to gravity.
2) The motor gets hot - I'd rather not juice it when it should just be sat at 0.

Anybody know how I can do this? I'm using the AccelStepper library so a solution compatible with that would be ideal.

title: Release power to stepper motor

Answers: 1

body:
From the documentation:

>  **TERMINAL 7 Disable**
This terminal will force the winding currents to zero when tied to the step and direction controller +5V.

>The DISABLE input on the G213V is optically isolated and requires logic “1” to DISABLE and logic “0” to ENABLE the drive. Once it is disabled, the motor windings are unergenized[sic] and ***the motor freewheels.*** *(emphasis mine)*

So, feed the disable input a high.


body:
I need to create a millisecond capable visual clock - I will use the clock for visual frame synchronization of multiple cameras. I found [this project][1] but it seems to use a LED display that only has resolution of one 1/100th of a second. Not sure if the digits can be shifted to show milliseconds.

I guess I need to use LED instead of LCD display because of the ms refresh rate? Can someone help with my project please? I am a SW programmer and have zero experience in HW programming. So I am new to Arduino too - I have not done any project at all yet. I do own neither Arduino nor LED display.

Thanks!

  [1]: http://embedded-lab.com/blog/?p=8559

title: Visual clock with millisecond display refresh rate

Answers: 3

body:
Assuming you camera's shutter is fast enough to capture a display updating every millisecond:
Get individual digit seven segment (LED) displays. The ones with multiple digits together are usually multiplexed and that might not work for your application(the multiplexing frequency would have to be higher than 1000 Hz or only one/some digits would be visible at a time). Using single digit displays, hook up each digit to a shift register such as the 74HC595. Then you only need two Arduino pins to control each digit (Data and clock, latch clock can be shared by all the shift registers). Use protection resistors for each individual segment diode and mind the current limit of the shift register when lighting all segments.

At 16 MHz you have 16000 instructions per ms so that shouldn't be an issue.

I don't know too much about LCD displays, but with LED's and a latching shift register transitions should be update pretty much instantaneous(from a millisecond perspective).

body:
You need to define the parameters of the problem more clearly.

First, and most importantly, what is the shutterspeed you'll be using? If it's longer than 1 ms, then you can't use a 7-segment display to show the MS count, since the camera shutter would be open for multiple values.

Even if your shutterspeed is a single MS, your shutter won't be synchronized with your timer, so sometimes the shutter will be open when the display switches. That can even happen with the seconds digit of your time display.

If you're using a video camera, assume the frame rate is 60 fps, which gives a likely shutterspeed somewhere around 16.6 ms. That's way too long to display ms time values using 7-segment displays.

The ring of LED idea is good, but I would tweak it.

Here's what I would do: Build an LED clock to display whole number seconds. Don't multiplex, use latches and drive each 7-segment display constantly. (There are off-the-shelf CMOS chips that are latching 7-segment drivers.) If you only care about the 1s digit of the second value, only use 1 7-segment display. That will make things easier to wire.

Use 3 rings or columns of 10 LEDs for the MS display: tenths, hundredths, and thousandths. I would lean towards using columns since it would be visually easier to read.

The display will show your seconds as numbers, and 3 columns of 10 LEDs, showing the sub-second time range in 10ths, 100ths, and 1000ths. If the shutter opening spans multiple MS, as it will very likely do, all the LEDs that represent the sub-second time will be lit in the image, so you will get a nice clean visual image of the time SPAN that the shutter was open (All the LEDs from the start to the end of the shutter opening will be lit.)

You could drive the 3 columns of LEDs using 3 4017 divide-by-10 counters. These chips have both a 1-of-10- output, which will drive an LED, and a count/10 output, which would feed the next stage.

Write Arduino code that generates a short positive pulse every MS. Feed that into the clock input of the 4017 driving the thousandths digit. Feed the out/10 output of that chip to the clock input of the hundredths 4017, and the output of the hundredths 4017 into the clock input of the tenths 4017.

You can drive the whole ms display with 2 Arduino lines: The ms clock, and a reset line tied to all your 4017 counters' reset lines. To start timing, first pulse the reset line to zero them all out, then start your ms clock.

My CMOS cookbook doesn't say how much current the 4017 will put out to it's 1-of-10 outputs, but I bet it's enough to drive a display LED directly. You could wire all 10 LEDs in each column as common cathode, with a single current limiting resistor between each column's common cathode and ground.

You could probably set up a timer pin on the Arduino to generate a millisecond pulsed output, but that's not something I've learned how to do yet.

Occasionally you'll get a whole second 7-segment display with 2 different values captured in a frame, but that will be rare, and you will be able to figure out what happened from the frames immediately before and after it. (Previous frame shows a 5. Current frame shows a 5 and a 6 superimposed, so it's a mess. Conclusion, this frame shows the end of second 5 and the beginning of second 6.)

body:
I think Duncan C's 'user interface' is excellent. It is clean, simple and elegant.

Using individual LEDs is much better than digits. IMHO it is much more flexible, and avoids the ambiguity of digits.  +1 for the concept.

However, I would make it 'softer', and use a lot fewer components.

By going 'softer' you could have more flexibility, which would give you the ability to expand the useful resolution of the 'clock'.

Duncan C made a very important point that digits are useless if a digit changes during the photograph. However, that is still a potential problem with the three lines of LEDs. When the exposure time is longer than the duration of the 'lower digit' line of LEDs, information is lost.

Certainly Duncan C's design could be speeded up or slowed down to adjust for that, but it has a built in resolution limit because it counts in 10's. Imposing the digital idea of '10' on an analogue system (which is similar to a child's abacus) loses some of three inherent flexibility in the fundamental superiority (in this case) of an analogue display. I suggest making it 'soft' so that the system can be 'tweaked' in software after the electronics are completed.

Instead of fixed function decade counters, use shift registers . Then there is complete flexibility to change the 'user interface' in software.

To reduce the number of components use shift registers *designed to drive LEDs*.

For example, Texas instruments make many LED-drivers. The lowest cost ones, in Dual-In-Line packages (which can be used in a breadboard, and so would be easier to prototype) that I found on RS were TLC5916/TLC5917. Each device drives 8 LEDs, so Duncan C's design would use 4. This is *more expensive* than decade counters. However, I think the cost (about 5GBP) may be worth it.

One benefit is they are 'constant current' drivers, and so eliminate the current-limiting resistors on each LED. Each device uses one resistor to program the current for all 8 LEDs. That won't save much money, but it will save a lot of wiring.

These shift registers are fed a pattern of data bits, one at a time, using a second 'clock' signal to tell the shift-register when the data bit is valid. Toggling the clock loads the data bit. So you could cascade them, end-to-end, exactly like cascaded counters. To reduce the CPU load, the input to the chain of shift registers could be loaded autonomously, 8 bits at a time by using the SPI peripheral in the Arduino.

Alternatively, you could use 4 pins to load data simultaneously, with one pin driving a shared clock. Those shift registers can operate much faster than even Arduino assembler (upto 30MHz/bit). So this needn't take much time.

The outputs of the shift registers do not change until a further signal is sent. Then they all change output simultaneously. So your cameras won't be confused by seeing the data being loaded.

So there is more software complexity than cascaded counters. However, there is no constraints on what data they show. For example, you might decide that you would like 20 LEDs worth of resolution, so that cameras have a wider exposure time and the frames can still be synchronised or 'positioned' relative to one another in time.

Anther advantage of this 'soft' behaviour is, you could add lots more LEDs and get pretty much any resolution you might need, using exactly the same hardware technology.

This approach shares an advantage of Duncan C's design. Time is indicated by discrete points of light, and not shape. So it should be relatively straightforward to use image processing to process images. That might be very important if the cameras are video cameras.

Edit:
To clarify a few points.

It is purely software which determines the behaviour of the LEDs in a shift-register based approach. Hence it is practical and straightforward, to simulate decade counters. So the 'user interface' can not be worse.

The complexity of a chain of shift-registers is the same as decade counters, if you want to use them that way. However for a few pins more, the shift registers could be loaded independently, which might have some benefits.

Using constant current LED drivers reduces the number of resistors to wire by a factor of 8. TI and others sell devices with 16 and 24 LED drivers, so the number of packages might be reduced.

The decade counter has a built in restriction. Not suprising, it gives no more than 10% resolution. However if you need 5%, it can't do it.

The shift-register-based electronics could emulate a 'clock face', so if 5% is needed, use 20 LEDs for that part. If 1% is required, add some more shift registers and LEDs

***Summary***:
Duncan C's concept of using an 'analogue abacus' display is, IMHO, a more robust user interface than LED Arabic digits.

However, IMHO a hard-wired implementation using decade counters is an unnecessary restriction, limiting resolution. Shift registers make the display 'soft'. Wiring up shift registers is the same complexity as decade counters. Using LED drivers, saves a lot of wiring.


body:
The pinhole camera is a [420TVL, 3.7mm Passive Infrared Detector Color Covert Security Camera][1]. Can I use this camera with an arduino creation?

Things I don't know to answer the question:

1. Does the power need something special arduino can't offer?
2. Is the arduino powerful enough to push the video feed/photos to a computer or any other method to video/photos.

Here are some specs from the site:
>- Sensor 1/3" Sony Super HAD II CCD
- Picture Elements NTSC 768x494
- PAL 752x582
- Horizontal Resolution 420 TVL
- Minimum Illumination 0.001 Lux
- S/N Ratio more than 50dB
- Scanning System 2:1 interlace
- Synchronous System Internal, Negative sync
- Auto Electronic Shutter NTSC 1/60s ~ 1/100,000s
- PAL 1/50s ~ 1/100,000s
- Gamma Characteristics 0.45
- Video Output 1 Vpp, 75 ohms
- Auto Gain Control Auto
- Power / Current DC 12V (±10%) / 150mA
- Lens 3.7mm Taper Pinhole Lens

Is it possible? They're on sale but I don't want to throw money away and find out that they don't work with any arduino. Also, I don't have any setup for this to be plugged into. Therefore, I'm not tied down to previous creations the cameras need to fit in.

  [1]: http://www.monoprice.com/Product?c_id=110&cp_id=11018&cs_id=1101801&p_id=9285&seq=1&format=2

title: Can I use this pinhole camera with arduino?

Answers: 1

body:
No, you cannot use this with an Arduino without additional hardware in between, and even with it, not as more than a still camera (or maybe low quality video for one of the ARM- rather than ATmega-based boards).

The first problem is that this camera has a high speed analog output called composite video.  It is basically what would be fed into a modulator to produce an old-style analog TV signal.  Capturing this digitally requires an Analog to Digital converter (ADC) capable of several million measurements per second, while that on the classic ATmega-based Arduino tops out at around ten thousand.

But let's say you had an additional Analog-to-digital converter to put in between this and your arduino.  The next problem is that the data rate out of the camera will be too high, and the Arduino won't have enough RAM memory to buffer it.

In theory, you could get a "frame grabber" consisting of an ADC and its own buffer memory, which would take a still snapshot of the video and allow the arduino to read it out more slowly.  But you can buy cameras which already do that with their onboard electronics, and allowing something like an Arduino to read the still image data out over a moderate speed serial interface.

Even the ARM-based arduino boards would be taxed to keep up with the output of a video ADC and do much of anything useful with the results - typical digital cameras do not record raw images to SD card, but do JPEG compression within a frame.  When cheap digital cameras operate in video mode, they compress each frame of the video before storing it (just as with stills - they do not compress between frames in the manner of real video recorders), and are able to get that processing done in time because the actual computing hardware is optimized for it in a way that none of the Arduinos are.

If you want to experiment with a camera on a development platform, there is one with a high speed digital interface sold as an add-on for the Raspberry Pi board.  Or you can use a more inexpensive USB webcam with that.


body:
The uno has digital pins marked 0-13.

0 is marked as rx and 1 is marked as tx.
Can these two pins be used as regular digital pins if i am short of digital pins?

title: Can tx and rx pins on the uno be used like regular digital pins?

Answers: 3

body:
Yes you can perfectly use these 2 pins as long as your program does not use `Serial`.

EDIT: Serial data over USB goes through copper traces connected to the rx and tx pins, connecting them to the USB to serial converter chip.

body: Also you will probably want to ensure these wires are not connected when programming the Arduino. Otherwise you may have problems.

body: You can, but it will disable the serial port.