Shallow Thoughts : : hardware

Akkana's Musings on Open Source Computing, Science, and Nature.

Wed, 29 Jan 2014

PyCon Tutorial: Build your own PiDoorbell - Learn Home Automation with Python

[Raspberry Pi from wikipedia] The first batch of hardware has been ordered for Rupa's and my tutorial at PyCon in Montreal this April!

We're presenting Build your own PiDoorbell - Learn Home Automation with Python on the afternoon of Wednesday, April 9.

It'll be a hands-on workshop, where we'll experiment with the Raspberry Pi's GPIO pins and learn how to control simple things like an LED. Then we'll hook up sonar rangefinders to the RPis, and build a little device that can be used to monitor visitors at your front door, birds at your feeder, co-workers standing in front of your monitor while you're away, or just about anything else you can think of.

Participants will bring their own Raspberry Pi computers and power supplies -- attendees of last year's PyCon got them there, but a new Model A can be gotten for $30, and a model B for $40.

We'll provide everything else. We worried that requiring participants to bring a long list of esoteric hardware was just asking for trouble, so we worked a deal with PyCon and they're sponsoring hardware for attendees. Thank you, PyCon! CodeChix is fronting the money for the kits and helping with our travel expenses, thanks to donations from some generous sponsors. We'll be passing out hardware kits and SD cards at the beginning of the workshop, which attendees can take home afterward.

We're also looking for volunteer T/As. The key to a good hardware workshop is having lots of helpers who can make sure everybody's keeping up and nobody's getting lost. We have a few top-notch T/As signed up already, but we can always use more. We can't provide hardware for T/As, but most of it's quite inexpensive if you want to buy your own kit to practice on. And we'll teach you everything you need to know about how get your PiDoorbell up and running -- no need to be an expert at hardware or even at Python, as long as you're interested in learning and in helping other people learn.

This should be a really fun workshop! PyCon tutorial sign-ups just opened recently, so sign up for the tutorial (we do need advance registration so we know how many hardware kits to buy). And if you're going to be at PyCon and are interested in being a T/A, drop me or Rupa a line and we'll get you on the list and get you all the information you need.

See you at PyCon!

Tags: , , , , ,
[ 19:32 Jan 29, 2014    More hardware | permalink to this entry | comments ]

Wed, 18 Sep 2013

Connecting an Arduino Pro Mini with an FTDI Friend

I found myself wanting to upload a sketch to an Arduino Pro Mini recently, using an FTDI Friend, and found that how to do it was surprisingly undocumented.

[Arduino Pro Mini] [Arduino Pro Mini]

First, the important thing is that the six FTDI pins do match up with the six pins at the edge of the Pro Mini, though obviously you have to figure out which way to rotate the two boards so you won't be 180 degrees off. I wasn't clear on that since the labels on the pins don't seem to match (see below).

Second, if you haven't soldered headers to your Pro Mini, you can stick a female-female header into the FTDI Friend's female header. then insert the other side of the header into the holes in the Pro Mini at an angle -- hold them with some tension so that the header pins are making contact with the copper-plated rims of the Pro Mini holes.

Okay, so the big question is which way to match the pins. It's complicated by the Pro Mini's having both outer holes unlabeled.

Usually when trying to match pins I start by looking for Ground, and make sure the two Grounds match. That doesn't work here -- the FTDI has the Gnd on one of the outer pins, while the Pro Mini has Gnd on the second pin in. The pin parked Gnd on the Pro Mini goes to CTS on the FTDI, while the pin parked Gnd on the FTDI corresponds to a pin on the Pro Mini that's unmarked. If you turned one of them 180 degrees, then you'd have Gnd (Pro Mini) - Rx (FTDI), and Gnd (FTDI) - unmarked (Pro Mini). No help there.

So ignore Ground and use VCC as your guide. It's on the third pin in -- so only in one orientation will VCC on both boards match. That's the orientation you want, and it works.

On some Pro Minis and some FTDI boards, you'll also have a label for "GREEN" or "GRN" on one side, and "BLACK" or "BLK" on the other. Match those if you have them, but you may not find that on all boards, particularly if you ever hook up to clone or third-party boards. So stick to VCC as a guide and you should be okay.

So what are those outer two holes on the Pro Mini? An image search for Arduino Pro Mini Pinout gives some pages showing GRN as TX and BLK as +9V (I assume that would be Vin, but actually those pages seem to be referring to the Arduino Mini, not the Pro Mini). But another shows GRN as RESET and BLK as Gnd. The official Pro Mini schematic shows the outer pins on JP1 as DTR and GND. So that seems most likely.

Tags: ,
[ 15:28 Sep 18, 2013    More hardware | permalink to this entry | comments ]

Sun, 11 Aug 2013

GPIO tutorial for the BeagleBone Black

Want to get started controlling hardware from your BeagleBone Black? I've found a lot of the documentation and tutorials a little sketchy, so here's what I hope is a quick start guide.

I used the Adafruit Python GPIO library for my initial hacking. It's easy to set up: once you have your network set up, run these commands:

opkg update && opkg install python-pip python-setuptools python-smbus
pip install Adafruit_BBIO

Pinout diagrams

First, where can you plug things in? The BBB has two huge header blocks, P8 and P9, but trying to find pinout diagrams for them is a problem. Don't blindly trust any diagram you find on the net; compare it against several others, and you may find there are big differences. I've found a lot of mislabeled BBB diagrams out there.

The best I've found so far are the two tables at elinux.org/BeagleBone. No pictures, but the tables are fairly readable and seem to be correct.

The official BeagleBone Black hardware manual is the reference you're actually supposed to use. It's a 121-page PDF full of incomprehensible and unexplained abbreviations. Good luck! The pin tables for P8 and P9 are on pp. 80 and 82. P8 and P8 are identified on p. 78.

Blinking an LED: basic GPIO output

For basic GPIO output, you have a wide choice of pins. Use the tables to identify power and ground, then pick a GPIO pin that doesn't seem to have too many other uses.

The Adafruit library can identify pins either by their location on the P8 and P9 headers, e.g. "P9_11", or by GPIO number, e.g. "GPIO0_26". Except -- with the latter designation, what's that extra zero between GPIO and _26? Is it always 0? Adafruit doesn't explain it. So for now I'm sticking to the PN_NN format.

I plugged my LED and resistor into ground (there are lots of ground terminals -- I used pin 0 on the P9 header) and pin 11 on P9. It's one line to enable it, and then you can turn it on and off:

import Adafruit_BBIO.GPIO as GPIO

GPIO.setup("P9_11", GPIO.OUT)
GPIO.output("P9_11", GPIO.HIGH)
GPIO.output("P9_11", GPIO.LOW)
GPIO.output("P9_11", GPIO.HIGH)
Or make it blink:
import time
while True:
    GPIO.output("P9_11", GPIO.HIGH)
    time.sleep(.5)
    GPIO.output("P9_11", GPIO.LOW)
    time.sleep(.5)

Fading an LED: PWM output

PWM is harder. Mostly because it's not easy to find out which pins can be used for GPIO. All the promotional literature on the BBB says it has 8 GPIO outputs -- but which ones are those?

If you spend half an hour searching for "pwm" in that long PDF manual and collecting a list of pins with "pwm" in their description, you'll find 13 of them on P9 and 12 on P8. So that's no help.

After comparing a bunch of references and cross-checking pin numbers against the descriptions in the hardware manual, I think this is the list: P9_14 P9_16 P9_21 P9_22 P9_28 P9_31 P8_13 P8_19

I haven't actually verified all of them yet, though.

Once you've found a pin that works for PWM, the rest is easy. Start it and set an initial frequency with PWM.start(pin, freq), and then you can change the duty cycle with set_duty_cycle(pin, cycle) where cycle is a number between 0 and 100. The duty cycle is the reverse of what you might expect: if you have an LED plugged in, a duty cycle of 0 will be brightest, 100 will be dimmest.

You can also change the frequency with PWM.set_frequency(pin, freq). I'm guessing freq is in Hertz, but they don't actually say.

When you're done, you should call PWM.stop() and PWM.cleanup().

Here's how to fade an LED from dim to bright ten times:

import Adafruit_BBIO.PWM as PWM

PWM.start("P9_14", 50)

for j in range(10):
    for i in range(100, 0, -1):
        PWM.set_duty_cycle("P9_14", i)
        time.sleep(.02)

PWM.stop("P9_14")
PWM.cleanup()

Tags: , ,
[ 12:36 Aug 11, 2013    More hardware | permalink to this entry | comments ]

Tue, 16 Jul 2013

Talking to a BeagleBone Black from Linux

Just a couple of tips for communicating with your BeagleBone Black once you have it flashed with the latest Angstrom:

Configure the USB network

The Beaglebone Black running Angstrom has a wonderful feature: when it's connected to your desktop via the mini USB cable, you can not only mount it like a disk, but you can also set up networking to it.

If the desktop is running Linux, you should have all the drivers you need. But you might need a couple of udev rules to make the network device show up. I ran the mkudevrule.sh from the official Getting Started page, which creates four rules and then runs sudo udevadm control --reload-rules to enable them without needing to reboot your Linux machine.

Now you're ready to boot the BeagleBone Black running Angstrom. Ideally you'll want it connected connected to your desktop machine by the mini USB cable, but also plugged in to a separate power supply. Your Linux machine should see it as a new network device, probably eth1: run ifconfig -a to see it.

The Beagle is already configured as 192.168.7.2. So you can talk to it by configuring your desktop machine to be .1 on the same network:

ifconfig eth1 192.168.7.1

So now you can ssh from your desktop machine to the BBB, or point your browser at the BBB's built in web pages.

Make your Linux machine a router for the Beaglebone

If you want the Beaglebone Black to have access to the net, there are two more things you need to do.

First, on the BBB itself, run these two lines:

/sbin/route add default gw 192.168.7.1
echo "nameserver 8.8.8.8" >> /etc/resolv.conf
You'll probably want to add these lines to the end of /usr/bin/g-ether-load.sh on the BBB, so they'll be run automatically every time you boot.

Then, back on your Linux host, do this:

sudo iptables -A POSTROUTING -t nat -j MASQUERADE
echo 1 | sudo tee /proc/sys/net/ipv4/ip_forward > /dev/null

Now you should be able to ping, ssh or otherwise use the BBB to get anywhere on the net.

Once your network is running, you might want to run /usr/bin/ntpdate -b -s -u pool.ntp.org to set the time, since the BBB doesn't have a real-time clock (RTC).

Serial monitor

[Beaglebone Black with serial cable]

If you're serious about playing with hardware, you'll probably want a serial cable, for those times when something goes wrong and your board isn't talking properly over USB.

I use the Adafruit console cable -- it's meant for Raspberry Pi but it works fine with the BeagleBone, since they both use the same 3.3v logic levels. It plugs in to the pins right next to the "P9" header, on the power-supply-plug side of the board. The header has six pins: plug the black wire (ground) into pin 1, the one closest to the power plug and ethernet jack. Plug the green wire (RXD) into pin 4, and the white wire (TXD) into 5, the next-to-last pin.

Do not plug in the red power wire -- leave it hanging. It's 5 volts and might damage the BBB if you plug it in to the wrong place.

In case my photo isn't clear enough (click for a larger image), Here's a diagram made by a helpful person on #beagle: BeagleBone Black serial connections.

Once the cable is connected, now what? Easy:

screen /dev/ttyUSB0 115200
That requires read-write privileges on the serial device /dev/ttyUSB0; if you get a Permission Denied type error, it probably means you need to add yourself to group dialout. (Changing groups requires logging out and logging back in, so if you're impatient, just run screen as root.)

I used the serial monitor while flashing my new Angstrom image (which is how I found out about how it spends most of that hour updating Gnome desktop stuff). On the Raspberry Pi, I was dependent on the serial cable for all sorts of things while I worked on hardware projects; on the BeagleBone, I suspect I may use the USB networking feature a lot more. Still, the serial cable will be handy to have when things go wrong, or if I use a different Linux distro (like Debian) that doesn't enable the USB networking feature.

Tags: , ,
[ 18:41 Jul 16, 2013    More hardware | permalink to this entry | comments ]

Sat, 13 Jul 2013

Flashing a new BeagleBone Black from Linux

I finally got a shiny new BeagleBone Black! This little board looks like it should be just the ticket for robotics, a small, cheap, low-power Linux device that can also talk to hardware like an Arduino, with plenty of GPIO pins, analog, PWM, serial, I2C and all.

I plugged in the BeagleBone Black via the mini USB cable, and it powered up and booted. It comes with a Linux distro, Angstrom, already installed on its built-in flash memory. I had already known that it would show up as a USB storage device -- you can mount it like a disk, and read the documentation (already there on the filesystem) that way. Quite a nice feature.

What I didn't know until I read the Getting Started guide was that it had an even slicker feature: it also shows up as a USB network device. All I had to do was run a script, mkudevrule.sh, to set up some udev rules, and then ifconfig -a on my desktop showed a new device named eth1.

The Beagle is already configured as 192.168.7.2, so I configured eth1 to be on the same network:

ifconfig eth1 192.168.7.1
and I was able to point my browser directly at a mini http server running on the device, which gives links to all the built-in documentation. Very slick and well thought out!

But of course, what I really wanted was to log in to the machine itself. So I tried ssh 192.168.7.2 and ... nothing. It turns out that the Angstrom that ships on current BBBs has a bug, and ssh often doesn't work. The cure is to download a new Angstrom image and re-flash the machine.

It was getting late in the evening, so I postponed that until the following day. And a good thing I did: the flashing process turned out to be very time consuming and poorly documented, at least for Linux users. So here's how to do it.

Step 1: Use a separate power supply

Most of the Beaglebone guides recommend just powering the BBB through its provided mini USB cable. Don't believe it. At least, my first attempt at flashing failed, while repeating exactly the same steps with the addition of an external power supply worked just fine, and I've heard from other people who have had similar problems trying to power the BBB through cable USB cable.

Fortunately, when I ordered the BBB I ordered a 2A power supply with it. It's hard to believe that it ever really draws 2 amps, but that's what Adafruit recommended, so that's what I ordered.

One caution: the BBB will start booting as soon as you apply any power, whether from an external supply or the USB cable. So it might be best to leave the USB cable disconnected during the flashing process.

Get the eMMC-flasher image and copy it to the SD card

Download the image for the BeagleBone Black eMMC flasher from Beagleboard Latest Images. They don't tell you the size of the image, but it's 369M.

The uncompress it. It's a .xz file, which I wasn't previously familiar with, but I already had an uncompressor for it, unxz:

unxz BBB-eMMC-flasher-2013.06.20.img.xz
After uncompressing, it was 583M.

You'll need a microSD card to copy the image to. The Beagleboard folks don't say how much space you need, but I found a few pages talking about needing a 4G card. I'm not clear why you'd need that for an image barely over half a gig, but 4G is what I happened to have handy, so that's what I used.

Put the card in whatever adapter you need, plug it in to your Linux box, and unmount it if got mounted automatically. Then copy the image to the card -- just the base card device, not the first partition. Replace X with the appropriate drive name (b in my case):

dd bs=1M if=BBB-eMMC-flasher-2013.06.20.img of=/dev/sdX
The copy will take quite a while.

Boot off the card

With the BBB powered off, insert the microSD card. Find the "user boot" button. It's a tiny button right on top of the microSD card reader. While holding it down, plug in your power supply to power the BBB on. Keep holding the button down until you see all four of the bright blue LEDs come on, then release the button.

Then wait. A long time. A really long time. The LEDs should flash erratically during this period. Most estimates I found on the web estimated 30-45 minutes to flash a new version of Angstrom, but for me it took an hour and six minutes.

You'll know when it's done when the LEDs stop blinking erratically. Either they'll all turn on steady (success) or they'll all go off (failure).

Over an hour? Why so long?

I wondered that, of course, so in my second attempt at flashing, once I had the serial cable plugged in, I ran ps periodically to see what it was doing.

And for nearly half that time -- over 25 minutes -- what it was doing was configuring Gnome.

Seriously. This Angstrom distribution for a tiny board half the size of your hand runs a Gnome desktop -- and when it flashes its OS, it doesn't just copy files, it runs Gnome configuration scripts for every damn program on the system.

Okay. I'm a little less impressed with the Beagle's Angstrom setup now. Though I still think this USB-ethernet thing is totally slick.

Tags: , ,
[ 13:30 Jul 13, 2013    More hardware | permalink to this entry | comments ]

Sun, 23 Jun 2013

Arduino and Servos

[Servo wired up to Arduino, without separate battery] My quest to make physical things move with Arduinos continues as we ramp up to Wednesday's GetSET workshop.

A few nights ago I finally broke out some old airplane servos and hooked them up to the Arduino. Don't know why I'd never gotten around to that, but I hadn't.

I had to decode the wire colors, aided by this excellent Connector Types page from Servo City. The GWS Naro servo I chose, with a JR plug, has a red wire (power), a brown wire (ground) and an orange wire (signal). Easy enough.

The Arduino software has a built-in Servo library, with instructions on wiring things up and a sample "Sweep" program to run the servo through its paces. Easy. I hooked it up and in just a few minutes I had the servo arm sweeping. Servos are so easy!

Or so I thought. The next day, I tried turning it into a real application, and that's where my problems started. I added a couple of photoresistors to my basic servo circuit and wrote a quick sketch to hook up the servo and print the output from the photoresistors to the serial port, as a first step before making it actually move the servos in response to the light coming in.

And ... nothing. Not only did I not get any output on my serial console, but I couldn't even open the serial console -- /dev/ttyACM0 didn't exist on my computer, or if it did, I got an error trying to open it. I couldn't even download new versions of the sketch, since those, too, are downloaded over the ACM0 serial device.

It turns out that servos, like larger motors, need a separate power source. Sometimes you can get away with powering them from the Arduino's 5v supply, but sometimes it will lead to flaky results.

This is contrary to every tutorial I found on the web. The official Arduino.cc Servo library documentation says "The power wire is typically red, and should be connected to the 5V pin on the Arduino board." and adds "Note that servos draw considerable power, so if you need to drive more than one or two, you'll probably need to power them from a separate supply (i.e. not the +5V pin on your Arduino). Be sure to connect the grounds of the Arduino and external power supply together."

And the Adafruit motor shield documentation says, "Servos are powered off of the same regulated 5V that the Arduino uses. This is OK for the small hobby servos suggested. If you want something beefier, cut the trace going to + on the servo connectors and wire up your own 5-6V supply!"

Basically, everywhere you turn people will tell you that for one or two servos, there's no point in fussing with a separate power supply. But when I went to the #arduino IRC channel, the experts there assured me that all the web tutorials were wrong, and that power was almost certainly my problem -- even with a single tiny GWS Naro servo.

And sure enough, when I added a 7.4v li-po battery as the power source for the servo, all my problems went away. Serial communication worked fine, and the servo was less jumpy. It's probably less risky to the Arduino, too.

The weirdest part of all this? When I tried to power it all off the Arduino's power supply (from USB), the servo was working fine, moving to wherever I told it. It was just serial communications to the PC that was failing.

I still have yet to find a good, simple way to power servos if you can't power them off the Arduino's 5v supply. Apparently their maximum voltage is 6V, and it's risky giving them any more than that. Right now I have a 7.4V li-po pack going through a speed controller; I'm not using the speed controller for anything except voltage regulation. Pretty silly.

I tried using a 4 AA pack, but that didn't seem to have enough oomph to power the servos. Maybe the answer is to add a 5v voltage regulator to the circuit, but that makes it a little difficult for robotics classes.

So, anyway, don't believe what you read on the net. That little 5v port is not a reliable power source even for one small hobby servo. Spread the word! And have fun playing with servos, whatever you end up using as a power source.

Tags: ,
[ 20:43 Jun 23, 2013    More hardware | permalink to this entry | comments ]

Thu, 30 May 2013

GetSET Robotics workshop -- now, with cheap motor shields

Last summer I led a one day robotics workshop for high school girls as part of the Society of Women Engineers' GetSET summer camp. I'm giving it again this year, on June 26. We're still lining up volunteers to help teach the workshop, and I'd love help from bay area women -- you don't have to be a robotics or programming expert, just willing to learn and play.

The workshop is based around the Arduino open-source microcontroller: we hook up Arduinos, then wire up LEDs, buzzers and other parts on breadboards and make them do things.

It's a programming workshop as well as a hardware one: most of the girls had a workshop the previous summer on Ruby programming, but that's their only exposure to programming. So it's a challenge to see how much we can cover in one day -- and a testament to the girls that they do so well.

Last year we spent the morning covering wiring Arduinos to the basics like breadboards, LEDs, pushbuttons and potentiometers. Then in the afternoon, teams worked on projects -- some of them wired together lots of colored LEDs, some worked with making sounds with buzzers, and one team built a robotic truck. I was hoping to be able to show them more motorized projects, and I'd brought several toy cars and trucks scavenged from thrift shops (radio controlled toys that had lost their radio controller).

But the wiring needed for the H-bridge to control the motor is complex, and the team that chose the truck project had their hands full getting the truck running by the end of the day -- forget about adding any bells and whistles. I wanted to make that easier. [Homemade, super cheap Arduino motor shield]

So for this year, with a little more time to prepare, I'm wiring up some Arduino motor shields.

Shields are devices that stack on top of an Arduino. You can do all the difficult wiring beforehand, and just plug in the shield when you're ready to use it. The down side is that shields can be expensive -- motor shields typically cost around $25. That's okay if you're buying one, but if you're trying to outfit a classroom, that can add up pretty quickly.

But I found a way of building motor shields cheaply. The H-bridge chip I'm using, the SN754410, is $1.75 at Jameco if you buy 5 or more. Jameco also carries a proto-shield PC board ($4.25 in quantity) and stacking headers ($1.59). So that's only $7.59 per shield, plus shipping, not counting a few sundries like battery connectors that I'd already bought for last year's class.

Then I had to wire up the shields. I was all fired up about having a good excuse to use wire-wrap instead of soldering. But then I realized that tiny 30-gauge wire-wrap wire probably wasn't adequate for the current going to the motors. So I soldered wires for the motors, the power lines from the battery connector to the H-bridge chip, and from the battery connector to the Arduino's Vin. Then I wire-wrapped everything else. [Car sporting super cheap Arduino motor shield]

The end result looks nice and clean from the top (please avert your eyes from my messy soldering underneath). There's no scary rats-nest of wires, like with the breadboards I used last year, and there's plenty of empty space on the board to velcro a battery or attach sensors like an ultrasonic rangefinder. I think this will work well and will encourage the girls to get some little cars zipping around the computer room.

I'm looking forward to setting up some simple projects I can combine with the cars -- light sensors, sonar or IR rangefinders, other ideas? I'd love suggestions from anybody, and I'd especially love to line up some volunteers (women only for the day of the workshop, please). Workshop day -- June 26 -- mostly means walking around checking on how the girls are doing, cheering them on, helping them debug problems by checking their wiring and looking over their programs (very simple code -- remember, they've never seen C code before).

And if anybody (male or female) wants to get together before the workshop and play with Arduinos, help me solder the rest of the shields, and brainstorm fun projects for the girls, please drop me a line!

The rough outline, handouts and wiring diagrams so far are at my Robots and Sensors Workshop page.

Tags: , ,
[ 18:40 May 30, 2013    More hardware | permalink to this entry | comments ]

Sat, 25 May 2013

Telling your Raspberry Pi that your terminal is bigger than 24 lines

When I'm working with an embedded Linux box -- a plug computer, or most recently with a Raspberry Pi -- I usually use GNU screen as my terminal program. screen /dev/ttyUSB0 115200 connects to the appropriate USB serial port at the appropriate speed, and then you can log in just as if you were using telnet or ssh.

With one exception: the window size. Typically everything is fine until you use an editor, like vim. Once you fire up an editor, it assumes your terminal window is only 24 lines high, regardless of its actual size. And even after you exit the editor, somehow your window will have been changed so that it scrolls at the 24th line, leaving the bottom of the window empty.

Tracking down why it happens took some hunting. Tthere are lots of different places the screen size can be set. Libraries like curses can ask the terminal its size (but apparently most programs don't). There's a size built into most terminfo entries (specified by the TERM environment variable) -- but it's not clear that gets used very much any more. There are environment variables LINES and COLUMNS, and a lot of programs read those; but they're often unset, and even if they are set, you can't trust them. And setting any of these didn't help -- I could change TERM and LINES and COLUMNS all I wanted, but as soon as I ran vim the terminal would revert to that scrolling-at-24-lines behavior.

In the end it turned out the important setting was the tty setting. You can get a summary of what the tty driver thinks its size is:

% stty size
32 80

But to set it, you use rows and columns rather than size. I discovered I could type stty rows 32 (or whatever my current terminal size was), and then I could run vim and it would stay at 32 rather than reverting to 24. So that was the important setting vim was following.

The basic problem was that screen, over a serial line, doesn't have a protocol for passing the terminal's size information, the way a remote login program like ssh, rsh or telnet does. So how could I get my terminal size set appropriately on login?

Auto-detecting terminal size

There's one program that will do it for you, which I remembered from the olden days of Unix, back before programs like telnet had this nice size-setting built in. It's called resize, and on Debian, it turned out to be part of the xterm package.

That's actually okay on my current Raspberry Pi, since I have X libraries installed in case I ever want to hook up a monitor. But in general, a little embedded Linux box shouldn't need X, so I wasn't very satisfied with this solution. I wanted something with no X dependencies. Could I do the same thing in Python?

How it works

Well, as I mentioned, there are ways of getting the size of the actual terminal window, by printing an escape sequence and parsing the result.

But finding the escape sequence was trickier than I expected. It isn't written about very much. I ended up running script and capturing the output that resize sent, which seemed a little crazy: '\e[7\e[r\e[999;999H\e[6n' (where \e means the escape character). Holy cow! What are all those 999s?

Apparently what's going on is that there isn't any sequence to ask xterm (or other terminal programs) "What's your size?" But there is a sequence to ask, "Where is the cursor on the screen right now?"

So what you do is send a sequence telling it to go to row 999 and column 999; and then another sequence asking "Where are you really?" Then read the answer: it's the window size.

(Note: if we ever get monitors big enough for 1000x1000 terminals, this will fail. I'm not too worried.)

Reading the answer

Okay, great, we've asked the terminal where it is, and it responds. How do we read the answer? That was actually the trickiest part.

First, you have to write to /dev/tty, not just stdout.

Second, you need the output to be available for your program to read, not just echo in the terminal for the user to see. Setting the tty to noncanonical mode does that.

Third, you can't just do a normal blocking read of stdin -- it'll never return. Instead, put stdin into non-blocking mode and use select() to see when there's something available to read.

And of course, you have to make sure you reset the terminal back to normal canonical line-buffered mode when you're done, whether or not your read succeeds.

Once you do all that, you can read the output, which will look something like "\e[32;80R". The two numbers, of course, are the lines and columns values you want; ignore the rest.

stty in python

Oh, yes, and one other thing: once you've read the terminal size, how do you set the stty size appropriately? You can't just run system('stty rows %d' % (rows) seems like it should work, but it doesn't, probably because it's using stdout instead of /dev/tty. But I did find one way to do it, the enigmatic:

fcntl.ioctl(fd, termios.TIOCSWINSZ,
            struct.pack("HHHH", rows, cols, 0, 0))

Here it all is in one script, which you can install on your Raspberry Pi (or other embedded Linux box) and run from .bash_profile:
termsize: set stty size to the size of the current terminal window.

Tags: , , , ,
[ 18:47 May 25, 2013    More hardware | permalink to this entry | comments ]

Syndicated on:
LinuxChix Live
Ubuntu Women
Women in Free Software
Graphics Planet
DevChix
Ubuntu California
Planet Openbox
Devchix
Planet LCA2009

Friends' Blogs:
Morris "Mojo" Jones
Jane Houston Jones
Dan Heller
Long Live the Village Green
Ups & Downs
DailyBBG

Other Blogs of Interest:
DevChix
Scott Adams
Dave Barry
BoingBoing

Powered by PyBlosxom.