I remember reading this great article about holographic storage in 1991. Yes, that’s 1991, I was a nerd even back then (article on Der Spiegel or via Google Translate). Holographic storage was going to take over everything and replace hard-drives in five years. I guess that didn’t happen, but companies such as InPhase sure kept trying. Now according to ZDNet, InPhase finally bit the dust.
Bye bye holographic storage, too bad we never met, but you sure sounded like a cool idea.
Apparently Steve Jobs told the Wall Street Journal to ditch flash because it is a buggy old technology with security holes. That’s an interesting attitude, considering that the real reason for why Apple refuses to support Flash on the iPhone and iPad is that it would undermine the Apple store and they would have to relinquish their total control over what apps run on the devices. That and the fact that AT&T would have to deal with large-scale video streaming on their network (here’s interesting article regarding this on the Economist).
Do no evil, Mr Gates Jobs and let us decide what software to install on the devices.
I ran across this totally awesome rant/statement of facts (thanks Slashdot) about real-world development, hype, and just getting things done. I personally have always been a huge proponent of just doing what works and feels right in the particular situation, borrowing bits and pieces from all kinds of methodologies. I’ve never been a fan of folks who want to follow a process (whichever it is) on a text-book level.
While the author talks about projects in the gaming world, I think these translate 1-1 to my reality. I think I would like to have a drink with the author of this post. Read it here.
Taking my home automation tinkering to the next level, I am launching catrpillr.com as an open-source solution to home automation. The site contains circuits, software, firmware, and documentation. Be advised that you currently still need at least intermediate knowledge of electronics to put these pieces together. The current solution allows you to fairly easily link together devices through low-cost radio-frequency receivers and transmitters, a few sample circuits such as a generic binary sensor and a relay-based remote switch are included.
A lot of the Arduino and hardware-related posts as of late will start going over onto the new site, freeing this site back up for things relating to (enterprise) software development.
Since my RF receivers require a full hardware-based UART to function reliably, I decided to opt for adding a simple attiny2313 as a controller connected to an Arduino. Ready to build a simple protocol, I decided to do a little more research into I2C — the inter-integrated-circuit protocol which puts multiple digital micro-controllers on a low-speed bus. As it turns out, the attiny controllers actually implement the full protocol, even if Atmel calls it TWI (two-wire-interface). The protocol defines a master device as well as up to 127 slave devices (7-bit addressing).
The hardware is very easy to hook up and it simply requires two wires (TWI is not just a clever name) – one called SDA, to transmit the data, and one called SCL, to transmit a clock signal. On an Arduino Duemilanove SDA is analog pin 4 and SCL is analog pin 5. On the attiny2313 controller, SDA is pin B5 (pin 17, also MOSI), and SCL is on pin B7 (pin 19) — also refer to Alex’s cheat sheet for the pins. Just connect SDA to SDA and SCL to SCL.
Arduinos have the Wirelibrary built straight into them, and after some hunting I found a small library for atttiny adapted from the original Atmel code by a Donald Blake (can be found on avrfreaks.net or my subversion repository). The Arduino is quickly configured as a master and set up to send and receive characters typed into the serial console to and from the slave controller:
// Arduino Codevoid
setup() {
Serial.begin(57600);
// initialize as i2c master
Wire.begin();
Serial.println("OK>");
}
// loop forever..void loop()
{
// data available from computer?if (Serial.available()) {
// read the incoming byte from the serial port
sByte = Serial.read();
// begin transmission to device 1
Wire.beginTransmission(1);
// send
Wire.send(sByte);
// done
Wire.endTransmission();
// request data from device 1
Wire.requestFrom(1,1);
// echo out whatever we get backwhile(Wire.available()) {
Serial.print(Wire.receive());
Serial.print("-");
}
}
delay(100);
}
On the slave, simply link the Donald Blake’s library into the code and this then does all the magic:
// attiny2313 codeint main(void)
{
// initialize as slave with id 1
usiTwiSlaveInit(1);
// enable interrupts (must be there, i2c needs them!)
sei();
// handle commandswhile (1)
{
// check if data is in the i2c receive bufferif(usiTwiDataInReceiveBuffer())
{
// get it
uint8_t b = usiTwiReceiveByte();
// echo it back
usiTwiTransmitByte(b);
}
// Do something else while waiting for the TWI transceiver to complete.
asm volatile ("NOP" ::);
}
return 0;
}
In the implementation of the “reverse” channel of my home automation system, the RF receiver will transmit radio data back to the master controller which in return sends it to the computer. Since the atmega168/328’s processors used in the standard Arduino only have one hardware-based serial port (UART), I tried for the software-based serial that ships with the Arduino IDEs. Transmitting data out works like a charm (as seen previously), but receiving it is quite a challenge, mostly due to timing problems. The software serial port doesn’t work unless all the sketch does is gather data — there’s no time for processing or it will start losing data.
My next attempt was to use an interrupt-based version of the software serial port. I briefly thought about writing one, but then I found this great libary, the New SoftSerial. It is as simple to use as the original library, but unfortunately once I connect the RF receiver, the processor is too busy handling interrupts and nothing really works. The noise picked up by the RF module must simply overwhelm it. That’s too bad, this works beautifully on my attiny2313-based receiver when using the hardware UART.
A software-based solution is clearly not the answer, some hardware is required. I can think of a few options
Abandon the Arduino altogether and use an AVR controller with multiple UARTs — not ideal, I like the idea of basing the master on Arduino for the hackability factor
Use a logic gate and an external clock generator to sample/filter the signal exactly at the right timing required for 1200 bps (the maximum reliable speed I could get to work for the RF modules) – this could still lead to timing issues
Create an attiny2313-based “daughter-board” which handles all the nitty gritty of the RF communication using the hardware-UART and then communicates to the Arduino via a few of the regular digital ports (I’m thinking asynchronously via about 4 pins)
Clearly this requires a little more thinking, but I’m leaning towards the third option — it encapsulates all the protocol logic on the attiny’s and the Arduino library that would need to be written to communicate with it would be very light-weight. And let’s not forget the attiny’s are only about two bucks.
You keep forgetting your keys but would never let your precious iPhone out of sight? Then nothing should seem more obvious than the need to open your garage door with your iPhone. An Arduino and a few microcontrollers, relays, rf link transmitters and receivers and some firmware later, it’s now reality. Check out the prototype (and excuse the slightly shaky video, it was bitter cold outside):
As I’m in the process of building a full home-automation suite so I can finally open my garage door with my iPhone (stay tuned, more on that soon), I wanted to quickly post this since it actually wasn’t really easily found online and I spent a few minutes (ok, more like an hour) fiddling with this before I got it to work.
The code below takes data (you should pass in numeric 8-bit values, i.e. between 0×0 and 0xFF) and then read them out on the Arduino as usual. As a general note, working in dynamically typed language like Ruby is a major pain in the a** when you’re trying to fiddle with every bit and work with an 8-bit microcontroller on the other side of the wire. On a positive note, Ruby has bit manipulation capabilities and it’s just so easy to build webapps with it…
The gist of the code below: Put the data into an array, pack it as unsigned characters, and then pump it into the serial port. The code below requires the ruby-serial gem.
class SerialGateway
def initialize()
puts "Starting serial gateway"
begin
# 9600, 8N1 on USB0
@sp = SerialPort.new"/dev/ttyUSB0", 9600, 8, 1, SerialPort::NONE
# release port on shutdown
at_exit { do_at_exit() }
rescue => e
# sophisticated error handling
puts "Cannot initialize usb device"
end
# only one serial access per time
@send_mutex = Mutex.new
end
#
# Send a command to the master device.
#
def sendCommand(command, targetAddress, data=[])
if(data.length >4)
raise "Sorry, maximum command data length is 4."
end
# first one ASCII R (remote, 0x52)
cmd = [ 0x52, command, targetAddress, data.size()]
# add data array
data.each { |d| cmd << d}
# pack it into unsigned chars
cmd = cmd.pack("C*")
@send_mutex.synchronize do
cmd.each_byte { |c| @sp.putc c }
end
end
end
Oh, and flipping back and forth between Ruby and C is a little weird :-)
The Wall Street Journal has another article on open source hardware and Arduinos up today.
The palm-sized Arduino serves as an electronic brain running everything from high schoolers’ robots to high-end art installations. But perhaps the oddest thing about the device is the business model behind it.
I remember reading this great article about holographic storage in 1991. Yes, that’s 1991, I was a nerd even back then (article on Der Spiegel or via Google Translate). Holographic storage was going to take over everything and replace hard-drives in five years. I guess that didn’t happen, but companies such as InPhase sure kept trying. Now according to ZDNet, InPhase finally bit the dust.
Jochen Toppe
-->