Floats. They're great! You can store really large or really small numbers in them with ease (provided they're supported by your compiler). Most processors even have built in instructions for playing with them. However, they are an imprecise number, which means that whatever value you try to put in may not be the value you get out.
Take for example the counter system I installed in a factory - the processor we used could only support 16-bit integers, or 32-bit floats. I thought, "Great! 32-bit floats go all the way up to ~4bn, we'll never have bigger counts than that". And we wont. The problem is, just because they can count to 4bn, doesn't mean that they can count ever number in between.
I knew about this problem, but I thought it only applied to small fractions after the decimal point. Unfortunately (as I discovered today with 100+ counters), there are also whole numbers it cannot display.
The first one of these (on a 32-bit float) is 16,777,217. So whenever you try to increment the counter after 16,777,216, the processor adds 1 to the number, then stores it back in the float as the closest representable number (16,777,216). Do you see the problem?
There's a very good reason for this, which I really don't want to have to explain because I hate working with the binary representations of floats. If you have to know, try the Wikipedia article on IEEE 754-2008.
So, long story short: do not use floats for counters!
Friday, 23 October 2009
Saturday, 15 August 2009
An Arduino and RS485
I love being a student! It gives you tonnes of perks, such as free industrial samples from semiconductor companies. I just got my order of MAX485 ICs through the post this morning, so I've spent the day playing around with Arduino and RS485 comms. I'm now going to share my experiences with you
The aim of this demo is to simulate some serial data on an Arduino and send it via RS485 to a computer.
RS485? Say what?
485 is a standard very similar to RS232 (the serial port used on an Arduino and your PC). RS485 improves upon 232 by removing the limitation of distance (up to 4000ft) and allows more than two devices to communicate using a single line, though it does this at the cost of using more wires between the devices
What you'll need for this demo:
Ok, so how's it done?
For this you're going to need a Maxim MAX485 (or equivalent) IC. This IC will take RS232 signals and perform the voltage level conversions required to turn them into 485 signals.
The MAX485 has 8 pins:
Code:
The code for this project is reallllly simple. We're just wanting to simulate some data coming from the Arduino, and pick it up using the FTDI. I uploaded this simple sketch to my Arduino:
Upload that to your Arduino and you should see the LED flashing roughly every 1 second. This means that it's sending serial data every 1 second. Now plug in your FTDI board to the PC and open up serial monitor in the Arduino IDE. If you have everything wired correctly, you'll see a number appearing in the window each time the Arduino sends something. Cool eh?
[UPDATE]
Handling two way communications:
The MAX485 and equivalents are only half duplex, meaning that they only support sending data in one direction at a time. This is fine, but it means you're going to need to account for that in your code.
It is possible to get full duplex versions of the MAX485 (I can't remember the part number right now). These bypass the need for any of the stuff below, but you will need four wires running between each device. Not a problem if you're running short distances, but it gets expensive if you have ~4000ft of cable. Anyway, it's pretty easy to get past the limitations of half duplex...
Remember the RE and DE pins? They specify whether the chip is in receive (RX) or transmit (TX) mode. If we control these from a pin on the Arduino we can leave the chip in RX mode, wait till something is received, and then change to TX mode to reply. Luckily the DE pin has a NOT gate on it, so you can drive both pins from one pin on your Arduino.
Note: From this point on you will need two Arduinos, as the FTDI board can't control the MAX485 in the way we want.
If you take a wire from your Arduino's digital pin 2, and wire it to DE, and then take another jumper wire and wire DE to RE, that will handle the TX/RX mode of the chip. Do this for both chips.
One of your Arduinos will need to be the master of the "network". This is typical in 485 applications, where there are several slave devices taking cues from a master. The master will query a slave, then change to RX mode. The slave will receive the command, and change to TX mode to send its response. After the response both devices change back to their normal mode.
At this point in your project you should probably specify exactly what a "command" is. They usually go along the lines of:
It's up to you to specify what the start byte and end byte are. You also have to specify how long and what the commands are (1 byte will provide 255 commands), and how long the parameters are (whether they're a fixed length or not).
Below, I'll use 0xFF (255) as the start and end bytes, and 0x01 as the command (send status). The slave device will be number 0x05. Params are optional and may be any length (zero or more whole bytes).
The resulting communications between the two devices would look something like this:
This is just an example of very basic comms between two device, but you can do a lot with it. I'm using something similar for my Arduino Backplane Experiment, only with I2C instead of serial.
I haven't gotten around to writing the code for two-way communications yet. Hopefully I've explained it well enough so you can have a stab at it. If anyone's feeling really stuck, give me a shout in the comments or on Twitter (@paddypluggedin) and I'll try and throw some code together
The aim of this demo is to simulate some serial data on an Arduino and send it via RS485 to a computer.
RS485? Say what?
485 is a standard very similar to RS232 (the serial port used on an Arduino and your PC). RS485 improves upon 232 by removing the limitation of distance (up to 4000ft) and allows more than two devices to communicate using a single line, though it does this at the cost of using more wires between the devices
What you'll need for this demo:
- 2x MAX485 ICs (or equivalent)
- 1x Arduino
- 1x breadboard (2 preferably)
- Jumper wires
- 2x 150R resistors
- FTDI cable or breakout board
Ok, so how's it done?
For this you're going to need a Maxim MAX485 (or equivalent) IC. This IC will take RS232 signals and perform the voltage level conversions required to turn them into 485 signals.
The MAX485 has 8 pins:- RO - Receiver out
- RE - Receiver enable (enabled when this pin is LOW)
- DE - Driver enable (enabled when this pin is HIGH)
- DI - Driver in (the transmitter pin)
- GND - Ground (0V)
- A - Connect to pin A of the other 485 IC
- B - Connect to pin B of the other 485 IC
- Vcc - Power, in my case +5V
- Wire up the power and ground. Try to use a battery for the transmitter. You can take power from the FTDI board for the receiver. This proves that there's only two wires (the comm) wires going between the devices.
- Wire pin A to the other pin A
- Wire pin B to the other pin B
- On each IC, a 150R resistor goes between pin A and B
- On the receiver side, wire pin RE to 0V
- On the transmitter side, wire pin DE to 5V
- On the transmitter, wire digital pin 0 (TX) from the Arduino to DI
- On the receiver, wire pin RO on the 485 to the RX pin of the FTDI board
Code:
The code for this project is reallllly simple. We're just wanting to simulate some data coming from the Arduino, and pick it up using the FTDI. I uploaded this simple sketch to my Arduino:
#define LED_PIN 13;
int i;
boolean b;
void setup() {
Serial.begin(57600);
i = 0;
b = false;
pinMode(LED_PIN, OUTPUT);
Serial.println("Init() complete");
}
void loop() {
i ++;
Serial.println(i);
b = !b;
digitalWrite(LED_PIN, b);
delay(1000);
}
int i;
boolean b;
void setup() {
Serial.begin(57600);
i = 0;
b = false;
pinMode(LED_PIN, OUTPUT);
Serial.println("Init() complete");
}
void loop() {
i ++;
Serial.println(i);
b = !b;
digitalWrite(LED_PIN, b);
delay(1000);
}
Upload that to your Arduino and you should see the LED flashing roughly every 1 second. This means that it's sending serial data every 1 second. Now plug in your FTDI board to the PC and open up serial monitor in the Arduino IDE. If you have everything wired correctly, you'll see a number appearing in the window each time the Arduino sends something. Cool eh?
[UPDATE]
Handling two way communications:
The MAX485 and equivalents are only half duplex, meaning that they only support sending data in one direction at a time. This is fine, but it means you're going to need to account for that in your code.
It is possible to get full duplex versions of the MAX485 (I can't remember the part number right now). These bypass the need for any of the stuff below, but you will need four wires running between each device. Not a problem if you're running short distances, but it gets expensive if you have ~4000ft of cable. Anyway, it's pretty easy to get past the limitations of half duplex...
Remember the RE and DE pins? They specify whether the chip is in receive (RX) or transmit (TX) mode. If we control these from a pin on the Arduino we can leave the chip in RX mode, wait till something is received, and then change to TX mode to reply. Luckily the DE pin has a NOT gate on it, so you can drive both pins from one pin on your Arduino.
Note: From this point on you will need two Arduinos, as the FTDI board can't control the MAX485 in the way we want.
If you take a wire from your Arduino's digital pin 2, and wire it to DE, and then take another jumper wire and wire DE to RE, that will handle the TX/RX mode of the chip. Do this for both chips.
One of your Arduinos will need to be the master of the "network". This is typical in 485 applications, where there are several slave devices taking cues from a master. The master will query a slave, then change to RX mode. The slave will receive the command, and change to TX mode to send its response. After the response both devices change back to their normal mode.
At this point in your project you should probably specify exactly what a "command" is. They usually go along the lines of:
[START BYTE][COMMAND][PARAMS][END BYTE]
or even:[START BYTE][DEVICE NUMBER][COMMAND][PARAMS][END BYTE]
It's up to you to specify what the start byte and end byte are. You also have to specify how long and what the commands are (1 byte will provide 255 commands), and how long the parameters are (whether they're a fixed length or not).
Below, I'll use 0xFF (255) as the start and end bytes, and 0x01 as the command (send status). The slave device will be number 0x05. Params are optional and may be any length (zero or more whole bytes).
The resulting communications between the two devices would look something like this:
| Step | Master | Slave |
| 1 | Prepare command 0xFF 0x05 0x01 0xFF | Waiting |
| 2 | Send command | Waiting |
| 3 | Change to RX mode Set pin 2 to LOW | Receive serial data 0xFF 0x05 0x01 0xFF |
| 4 | Waiting | Parse serial data Start byte ok, ID byte OK, command = send status, end byte ok |
| 5 | Waiting | Change to TX mode Set pin 2 to HIGH |
| 6 | Waiting | Send response (0x05 = ID, 0x01 = status ok) 0xFF 0x05 0x01 0xFF |
| 7 | Receive serial data | Change back to RX mode Set pin 2 to LOW |
| 9 | Change back to TX mode Set pin 2 to HIGH | Waiting |
| 10 | Parse data.... | Waiting |
This is just an example of very basic comms between two device, but you can do a lot with it. I'm using something similar for my Arduino Backplane Experiment, only with I2C instead of serial.
I haven't gotten around to writing the code for two-way communications yet. Hopefully I've explained it well enough so you can have a stab at it. If anyone's feeling really stuck, give me a shout in the comments or on Twitter (@paddypluggedin) and I'll try and throw some code together
Saturday, 8 August 2009
Arduino Backplane Experiment
Just as an experiment I thought I'd try this...
My motivation:
Pictured above is an Allen Bradley SLC-500 PLC. We use these a lot in work to automate industrial processes. They're very expensive, and all they are is a simple motherboard connecting daughter boards. The first slot is the CPU and does all the processing, and the rest of the cards are "dumb" cards which add different kinds of inputs or outputs, counters, comms, etc. Have I mentioned that they're very expensive?
My hope is to copy this modular, "slot in" design, so someone could just slide in a new pre-programmed module in their rack. This concept could be used to add:
The whole idea is not dissimilar to the Arduino "shield" idea, but I'm using I2C to connect them instead of all the pins. The trouble with the stackable shield idea is that pretty soon you'll get two cards that want to use the same pin, and then they can't be used together. Using I2C you have a theoretical limit of 255 devices
Above you can see my half-finished product. I've used a bunch of Arduino Pros, which have a 6 pin header on one side supplying power and serial comms. This plugs into an 8-pin female header on the motherboard. The remaining two pins are the I2C pins (analog 4 and 5), which I had to bring down using some wire and a couple of pins.
Each of these cards will eventually be configured to perform a particular task
Motherboard
The motherboard itself is a bit of strip board, connecting each of the pins to the corresponding pin of every daughter board (with the exception of the serial pins, 'cos serial can't work that way).
There's a set of male headers beside every card, this basically brings out the serial pins so I can connect my FTDI board to each card for debugging (not all are wired yet).
There should also be a 3-pin header beside each board for addressing (see the next section)
Oh I almost forgot, hiding away between the two leftmost boards is an I2C RTC module. I do plan to use this later...
Addressing
In order for I2C to work, each slave device needs a unique address. I don't want to have to reprogram the individual daughter cards after they've been configured, so I've brought down digital pins 11-13 to the motherboard. These pins will be either wired to +5v or 0v, depending on which slot they're in. These 3 inputs are then used to calculate the I2C address, giving 8 possible addresses.
Demo
In the picture you can see three of the Pros connected to a Duemilanove as the main CPU. As a very simple test program I have the CPU turning on the LED on each of the expansion boards in turn, then waiting, and turning them off again, to create a kind of chaser effect.
Eventually there'll be 5 Pros connected to the backplane (I don't have enough female header strips to complete the board today). I honestly don't know what I'm going to do with it afterwards, but I think this demonstrates a good proof of concept and I hope someone can think of a good use for this arrangement :).
[UPDATED] Source code:
The code's still not quite finished yet, but it now supports all the basic pin commands, except with an extra parameter to specify the card you want to address:
CPU code - here
Expansion board code - here
More photos
As always, comments, suggestions and fan mail are greatly appreciated
My motivation:
Pictured above is an Allen Bradley SLC-500 PLC. We use these a lot in work to automate industrial processes. They're very expensive, and all they are is a simple motherboard connecting daughter boards. The first slot is the CPU and does all the processing, and the rest of the cards are "dumb" cards which add different kinds of inputs or outputs, counters, comms, etc. Have I mentioned that they're very expensive?
My hope is to copy this modular, "slot in" design, so someone could just slide in a new pre-programmed module in their rack. This concept could be used to add:
- Additional digital or analog IO
- A real time clock
- EEPROM card
- Pre-built sensor cards
- Dedicated counter modules
- GPS modules
- Ethernet, or XBee or other RF comms
- Flash storage cards
- Motor, servo and stepper drivers
- RS485 comms card
The whole idea is not dissimilar to the Arduino "shield" idea, but I'm using I2C to connect them instead of all the pins. The trouble with the stackable shield idea is that pretty soon you'll get two cards that want to use the same pin, and then they can't be used together. Using I2C you have a theoretical limit of 255 devices
Above you can see my half-finished product. I've used a bunch of Arduino Pros, which have a 6 pin header on one side supplying power and serial comms. This plugs into an 8-pin female header on the motherboard. The remaining two pins are the I2C pins (analog 4 and 5), which I had to bring down using some wire and a couple of pins.
Each of these cards will eventually be configured to perform a particular task
Motherboard
The motherboard itself is a bit of strip board, connecting each of the pins to the corresponding pin of every daughter board (with the exception of the serial pins, 'cos serial can't work that way).
There's a set of male headers beside every card, this basically brings out the serial pins so I can connect my FTDI board to each card for debugging (not all are wired yet).
There should also be a 3-pin header beside each board for addressing (see the next section)
Oh I almost forgot, hiding away between the two leftmost boards is an I2C RTC module. I do plan to use this later...
Addressing
In order for I2C to work, each slave device needs a unique address. I don't want to have to reprogram the individual daughter cards after they've been configured, so I've brought down digital pins 11-13 to the motherboard. These pins will be either wired to +5v or 0v, depending on which slot they're in. These 3 inputs are then used to calculate the I2C address, giving 8 possible addresses.
Demo
In the picture you can see three of the Pros connected to a Duemilanove as the main CPU. As a very simple test program I have the CPU turning on the LED on each of the expansion boards in turn, then waiting, and turning them off again, to create a kind of chaser effect.
Eventually there'll be 5 Pros connected to the backplane (I don't have enough female header strips to complete the board today). I honestly don't know what I'm going to do with it afterwards, but I think this demonstrates a good proof of concept and I hope someone can think of a good use for this arrangement :).
[UPDATED] Source code:
The code's still not quite finished yet, but it now supports all the basic pin commands, except with an extra parameter to specify the card you want to address:
- digitalRead()
- digitalWrite()
- analogRead()
- pinMode()
CPU code - here
Expansion board code - here
More photos
As always, comments, suggestions and fan mail are greatly appreciated
Saturday, 1 August 2009
iPhones are great things
Just spent £1.79 on an app to blog from my phone. Lets see how it goes...
-- Post From My iPhone
-- Post From My iPhone
Thursday, 2 July 2009
My version of the BakerTweet
In case you haven't heard about the awesomeness, the BakerTweet (www.bakertweet.com) is an Arduino based twitter client. It's a little box that sits on the wall of a bakery, and whenever something tasty comes out of the oven, the baker can select the product and let the world know via Twitter that there's a fresh batch of croissants ready.
I thought this was a great idea! And I've been wanting an excuse to hook my Arduino up to twitter for ages.
What you'll need:
All the elements of this project are already widely available. People have been using the official Arduino Ethernet shield to sent Twitter updates for ages. My problem was that I bought the much cheaper, ENC28J60 based Ethernet shield by nuelectrnoics. It wasn't until tuxgraphics.org brought out their new TCP/IP stack, and Andy modded it for the Arduino that I was able to send Twitter updates from it.
The LCD shield also proved a bit of a hassle. Mine is also from nuelectronics and wouldn't sit properly on top of the Ethernet shield. The RJ45 socket from the lower shield is a lot higher than the pin headers, and there were some through-hole pins from the buttons poking through making it impossible for the two boards to mate.
I soon solved that though by desoldering most of the buttons, shortening the leads, and re-soldering them in a surface mount fashion. They work just fine, and the two boards will now mate (not perfectly, but enough to make a solid connection).
Code:
The code for my Arduino sketch is located here. Basically, you just plug the board into an Internet router (over a wired LAN), power the Arduino somehow, and then use the buttons to scroll through the possible tweets. Once you've found the one you like, click the send button and it'll post the tweet to your Twitter account.
What's Next?
I'd love to make this thing wireless, using a WiFi card. I bet they aren't cheap though....
I thought this was a great idea! And I've been wanting an excuse to hook my Arduino up to twitter for ages.
What you'll need:
- Arduino board (I'm using the Duemilanove)
- Ethernet shield
- LCD shield
- 3 push buttons (if your LCD shield doesn't come with them)
All the elements of this project are already widely available. People have been using the official Arduino Ethernet shield to sent Twitter updates for ages. My problem was that I bought the much cheaper, ENC28J60 based Ethernet shield by nuelectrnoics. It wasn't until tuxgraphics.org brought out their new TCP/IP stack, and Andy modded it for the Arduino that I was able to send Twitter updates from it.
The LCD shield also proved a bit of a hassle. Mine is also from nuelectronics and wouldn't sit properly on top of the Ethernet shield. The RJ45 socket from the lower shield is a lot higher than the pin headers, and there were some through-hole pins from the buttons poking through making it impossible for the two boards to mate.
I soon solved that though by desoldering most of the buttons, shortening the leads, and re-soldering them in a surface mount fashion. They work just fine, and the two boards will now mate (not perfectly, but enough to make a solid connection).
Code:
The code for my Arduino sketch is located here. Basically, you just plug the board into an Internet router (over a wired LAN), power the Arduino somehow, and then use the buttons to scroll through the possible tweets. Once you've found the one you like, click the send button and it'll post the tweet to your Twitter account.
What's Next?
I'd love to make this thing wireless, using a WiFi card. I bet they aren't cheap though....
Wednesday, 1 July 2009
Cheap Joystick and Accelerometer for Arduino from Wii Nunchuck
For ages now I've been wanting to play with an accelerometer but didn't really fancy paying £20-25 for the privilege. I'd also seen a lot of posts about people using the joystick from a Wii Nunchuck to control robots, servos, cameras, etc, which I didn't have a lot of interest in. Then I remembered that the Nunchuck controller actually has an accelerometer built in. Long story short, I'm now short one Nunchuck and plus one accelerometer.
The economics of this one really work out, since a Nunchuck is usually only about £15, and communicates over I2C which saves on IO. So far, the lowest price accelerometer I've found was over £20 and communicated using 3x analogue signals.
Obviously I'm not the first to make this realisation. A quick Google search took me to http://www.windmeadow.com/node/42, which gives a great tutorial on how to wire it up and gives a sample sketch to get you up and running.
I wanted a way to visualize the data coming out, just so I could see how it looks when I make a few gestures or use the buttons and joystick. I'm not the greatest fan of Processing (mainly because I haven't used it an awful lot) but I am a big fan of Java. I created a program which shows me the current levels of each of the 5 axes (x, y, z, joystick x, joystick y), and the 2 buttons. It also graphs the xyz-axes over time. Cool eh?
As with most of my programs it needs a lot of attached Jar files, so here's my Eclipse workspace folder in zip format.
Note: you'll need to tweak the Windymedow sample sketch a little to work for my Java program - specifically you'll need to change the value separator in the "print()" function to a comma, not a tab.
The economics of this one really work out, since a Nunchuck is usually only about £15, and communicates over I2C which saves on IO. So far, the lowest price accelerometer I've found was over £20 and communicated using 3x analogue signals.
Obviously I'm not the first to make this realisation. A quick Google search took me to http://www.windmeadow.com/node/42, which gives a great tutorial on how to wire it up and gives a sample sketch to get you up and running.
I wanted a way to visualize the data coming out, just so I could see how it looks when I make a few gestures or use the buttons and joystick. I'm not the greatest fan of Processing (mainly because I haven't used it an awful lot) but I am a big fan of Java. I created a program which shows me the current levels of each of the 5 axes (x, y, z, joystick x, joystick y), and the 2 buttons. It also graphs the xyz-axes over time. Cool eh?
As with most of my programs it needs a lot of attached Jar files, so here's my Eclipse workspace folder in zip format.
Note: you'll need to tweak the Windymedow sample sketch a little to work for my Java program - specifically you'll need to change the value separator in the "print()" function to a comma, not a tab.
Sunday, 28 June 2009
Arduino + Laser Pointer + Servos = Homemade Laser Cannon
After discovering how ridiculously easy it was to control a servo motor from the Arduino, I wondered what 2 servos and a laser pointer could do...
Long story short, I now have a computer controlled laser cannon muhahha!
The whole thing is controlled via serial commands, which let me:
I started by sending the commands by hand from the Arduino IDE, but then I wrote a Java app that let me control all the options using a GUI, which made things a lot easier. It can also record the position of the laser at given times, and play these back, allowing the laser to follow a path:
Finally, I added some physical aiming controls (two variable resistors to control X and Y). This makes it a lot easier to point it at objects, and I can use it along side the Java interface.
If you want to build your own, the Arduino PDE file is here. There's not much actual "building" required - if you have two servos, Blu Tac them together and sticky tape a laser pointer on the side. I'm using a heavy shot glass as a frim base for mine ;)
The laser pointer and servos drew too much power for my Arduino to handle on its own, so I have them hooked up to an external 4.5V supply. The servos have a separate +V and signal wire so they were easy enough to wire up, but I had to use a transistor to switch the laser pointer.
I'm not quite finished the Java app yet, but if you're interested leave a comment and I'll post what I have so far.
Long story short, I now have a computer controlled laser cannon muhahha!
The whole thing is controlled via serial commands, which let me:
- Control pitch (Y) and yaw (X)
- Turn the laser on and off
- Make the laser flash or not
- Follow a pre-programmed "sweep" pattern
- Control whether or not the laser turned off while moving and on again
I started by sending the commands by hand from the Arduino IDE, but then I wrote a Java app that let me control all the options using a GUI, which made things a lot easier. It can also record the position of the laser at given times, and play these back, allowing the laser to follow a path:Finally, I added some physical aiming controls (two variable resistors to control X and Y). This makes it a lot easier to point it at objects, and I can use it along side the Java interface.
If you want to build your own, the Arduino PDE file is here. There's not much actual "building" required - if you have two servos, Blu Tac them together and sticky tape a laser pointer on the side. I'm using a heavy shot glass as a frim base for mine ;)
The laser pointer and servos drew too much power for my Arduino to handle on its own, so I have them hooked up to an external 4.5V supply. The servos have a separate +V and signal wire so they were easy enough to wire up, but I had to use a transistor to switch the laser pointer.
I'm not quite finished the Java app yet, but if you're interested leave a comment and I'll post what I have so far.
Subscribe to:
Posts (Atom)
