Wed Nov 4 10:22:03 EST 2009: Windows XP Sucks •
My CD drive disappeared. Well, the driver disappeared. Windows could see the drive, but wouldn't install a driver for it. I frantically searched the dell support pages for ... a cd driver. But nothing was to be found.
I could tell from booting to linux that the drive works fine. So what then?
The solution was to delete LowerFilters from my registry (HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class\{4D36E965-E325-11CE-BFC1-08002BE10318}).
This arcane bullshit is why I hate windows. On the one hand, I'm glad MS documented this. On the other hand, I can't help but wonder if automatic updates has an entropy system in place to get me to give up and upgrade to Windows 7. Unlikely, but technically possible. MS has a direct financial interest in that... but definitely not in helping me get XP working.
-Paul
Thu Aug 6 11:59:39 EDT 2009: My Win0 Device •
I wasn't happy with the two choices of network interface types given in the VirtualBox documentation. It struck me, I could make the guest OS appear on the lan just like any other computer by using proxy arp and tun device.
This works rather like a hybrid of their NAT and their Bridge modes from the documenation, but more awesome. This script is ubuntu/debian-esque, but could be refactored for other linux OSes fairly easily.
bash$ cat /etc/init.d/win0
#!/bin/bash
vbox="win0"
ethr="eth0"
ip="10.1.1.200"
case "$1" in
start)
( set -x
tunctl -t $vbox -u jettero
ifconfig $vbox up
route add -host $ip dev $vbox
echo 1 > /proc/sys/net/ipv4/conf/$vbox/proxy_arp
arp -Ds $ip $ethr pub
)
;;
stop)
(echo 0 > /proc/sys/net/ipv4/conf/$vbox/proxy_arp) 2>/dev/null
ifconfig $vbox down &>/dev/null
tunctl -d $vbox &>/dev/null
arp -i $ethr -d $ip &>/dev/null
;;
restart) $0 stop; $0 start ;;
esac
Here's the ifconfig and ipconfig results.
bash$ ifconfig win0
win0 Link encap:Ethernet HWaddr xx:xx:xx:xx:xx:xx
inet6 addr: xxxx::xxx:xxx:xxxx:xxxx/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:3687268 overruns:0 carrier:0
collisions:0 txqueuelen:500
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
C:\Documents and Settings\jettero> ipconfig
Ethernet adapter win0:
Connection-specific DNS Suffix . :
IP Address. . . . . . . . . . . . : 10.1.1.200
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . : 10.1.1.1
This could not be simpler to set up in Virtualbox either. From here, you simply set it to bridged on your new win0 device. Done.
-Paul
Fri Jun 12 06:28:28 EDT 2009: XBee Shell •
I finally got around to doing some things with my XBee chips. Nothing special at all. I didn't really like the way minicom interfaced the things. First of all, it keeps telling the "modem" to init and reset after the session. The XBee does take AT commands, but ... not like that.
Despite my telling minicom to echo local characters, it still wasn't echoing the AT commands in command mode ... that made me kinda mad. So I wrote my own console program. And when I say I wrote my own, I mean I used POE (so I only wrote 10% of it) and I started from the cookbook (so I only wrote 5% of it).
#!/usr/bin/perl # My XBee shell. Copyright 2009 Paul Miller - LGPL # # This is very much ripped off from the cookbook though, that license (if any) # may apply. http://poe.perl.org/?POE_Cookbook/Serial_Ports # # POE makes this so easy. Yes, you could do it with blocking read/writes and # select() and rts/cts checks and things. Would you really want to? # use warnings; use strict; use POE qw(Wheel::ReadWrite Filter::Stream); use Symbol qw(gensym); use Device::SerialPort; use Term::ReadKey; my $dev = uc( shift || "usb0" ); $dev = "/dev/tty$dev"; die "no such dev: $dev" unless -c $dev; my $lck = $dev; $lck =~ s/\/dev\//\/var\/lock\/LCK../; # POE is very fun. You don't write the program flow at all in POE, you simply # name the things you want to happen and ... they do! POE::Session->create( package_states => [ main => [qw(_start got_port got_console got_error byebye)] ]); POE::Kernel->run(); exit 0; # notice, run() doesn't return until the program is done. sub _start { my ( $kernel, $heap ) = @_[ KERNEL, HEAP ]; # The XBee won't work quite right in line mode, not if you want to be # able to interact with the +++ command mode. Also, I have mine set to # 115200, you'd have to change the baud rate to use this if yours is # set to default. # ATBD 7 ReadMode 'ultra-raw'; # ultra-raw gets really serious about grabbing the actual bytes # from the serial port. my $handle = gensym(); my $port = tie( *$handle, "Device::SerialPort", $dev, 0, $lck ); unless( $port ) { my $err = $!; ReadMode 'restore'; $err = "lockfile exists: $lck" if $err =~ m/File exists/; die "can't open port: $err"; } $port->datatype('raw'); $port->baudrate(115200); # the baud rate, default is 9600 $port->databits(8); $port->stopbits(1); $port->parity("none"); $port->handshake("rts"); $port->write_settings; # We have two "wheels," streams that handle input and output. This # type of wheel is specifically for reading and writing at the same # time, in an event based manner. $heap->{port} = $port; $heap->{port_wheel} = POE::Wheel::ReadWrite->new( Handle => $handle, Filter => $heap->{output_stream} = POE::Filter::Stream->new, InputEvent => "got_port", ErrorEvent => "got_error", ); $heap->{port_wheel}->put("[enter: $ENV{USER}\@$ENV{HOSTNAME}:$dev]\r"); $heap->{cons_wheel} = POE::Wheel::ReadWrite->new( InputHandle => \*STDIN, OutputHandle => \*STDOUT, Filter => $heap->{input_stream} = POE::Filter::Stream->new, InputEvent => "got_console", ErrorEvent => "got_error", ); $heap->{cons_wheel}->put("Press ^D to stop.\r\n"); } sub got_port { my ( $heap, $data ) = @_[ HEAP, ARG0 ]; # We've received something from the XBee, so we reformulate it for the # terminal a little and pass it to the console. $data =~ s/\x0d/\x0d\x0a/g; $data =~ s/([^\x0d\x0a[:print:]])/"0x" . unpack("H*", $1)/eg; $heap->{cons_wheel}->put($data); } sub got_console { my ( $heap, $data ) = @_[ HEAP, ARG0 ]; # we've received something from the console if( $data =~ s/(\x03|\x04|\x1c)//g ) { # 3 ^C, 4 ^D, 28 ^| # if we receive a ^C, ^D or ^|, break out of the program ReadMode 'restore'; $heap->{port_wheel}->put("[exit: $ENV{USER}\@$ENV{HOSTNAME}:$dev]\r"); $heap->{cons_wheel}->put("Bye!\r\n"); $poe_kernel->delay("byebye", 1); } # echo the input locally $heap->{port_wheel}->put($data) if $data; # reformulate new input for the # XBee a little and pass it to the serial device. $data =~ s/\x0d/\x0d\x0a/g; $data =~ s/([^\x0d\x0a[:print:]])/"0x" . unpack("H*", $1)/eg; $heap->{cons_wheel}->put($data) if $data; } sub byebye { my $heap = $_[HEAP]; # once the wheels are gone, POE will notice there's nothing left to do # and the program will exit delete $heap->{cons_wheel}; delete $heap->{port_wheel}; } sub got_error { my $heap = $_[HEAP]; $heap->{cons_wheel}->put("$_[ARG0] error $_[ARG1]: $_[ARG2]"); $heap->{cons_wheel}->put("bye!"); delete $heap->{cons_wheel}; delete $heap->{port_wheel}; }
-Paul
Wed Jun 3 06:48:36 EDT 2009: XBee •
I'm trying to break into the world of embedded programming. I'm starting small. I bought some zigbee modules and USB boards. I figured out a few things on the radios, which feel oddly similar to talking to an old fashion modem — modem in the traditional sense, not a terminal adapter.
bash$ mrsh uptime Welcome to minicom 2.3-rc1 Compiled on Dec 10 2007, 10:31:35. Port /dev/ttyUSB0 OK ATDB 0 ATDB 17 ATVD 10CD OK ATCN test
I haven't figured out the API mode yet, but the transparent passthrough mode has been fun. When I'm not in command mode, typing in one minicom shows up in the other and vice versa. When I issue ATDB in command mode, it reports the signal strength. When I first plugged it in, ATDB returned: 0... but after I had the other module send some data, it reported: 17. 17? The manual says, "Absolute values are reported. For example: 0x58 = -88 dBm (decimal)." So the signal strength when the modules are 0.5 inches apart is really: -23 dBm? I think?
I have successfully transferred files using Zmodem! Man that takes me back.
In the picture on the right, note that the lights are on the USB boards. Zigbee's main purpose is to be very power efficient, so the modules certainly wouldn't have lights on them!
-Paul




