It's Alive! (again!)

Well, it’s been a while since I’ve had time to work on the Weebox — and part of that’s due to the lack of a working LCD screen (covered amply in A frustrating evening). Yesterday morning this all changed with the arrival of the new, working, negative voltage generator.

I’ve bought an LCD negative voltage generator evaluation board from Maxim IC. Rather than try and solder on all the tiny and hard-to-find components needed, I plumped for the cheating method of getting Maxim to do it for me. All I had to do was solder on the +5V, GND, Shutdown and Output wires — which even with my hamfisted soldering skills wasn’t too hard:

A frustrating evening

This morning I was yet again rudely awakened by the DHL man. This time he brought me a DC-DC converter, to jump my 5V down to -12V ready for use in the screen.

My idea of electronics is somewhat out of kilter with the Universe’s, it would seem. So I’m researching on more alternatives to get my -9.1V that I need. The only circuits that I’ve seen use Maxim ICs, which RS don’t seem to sell, so I’m a bit stuck. I’ve found this but the issue is the 0V. When I measured my NMA0512S’s output at its three terminals (marked, -12V, 0V and 12V) relative to ground, I got 0V, 20V and 40V. I put a bit of a load on the system, and I couldn’t fathom out any kind of relationship between the voltages and the load…and when I got it nearly right (about -10V) plugging the LCD screen in immediately took the voltage back up to 2-3V. Aargh! Unfortunately, after some further mucking about I managed to blow the stupid thing, burning my fingers in the process (yes, they get really hot if you short them out…doops).

I’m sure this is obvious stuff, so I’ve resolved to go and buy an electronics book or two tomorrow and try and work out where I’m going wrong.

A new screen

It’s been rather a while since I’ve been able to spend any time on the Weebox, what with the Xania.org attack and with work and life intervening (damn them!) However, in the evenings I’ve been researching a new LCD display to replace the frankly quite rubbish 2x24 character display I’m currently using.

Before I go much further I have an admision to make…I’ve actually broken the 2x24 display. It was always a little sensitive to being pushed and pulled about, but after a recent attempt to ‘fix’ it I think I accidentally heat- damaged the underside. Only by bending the whole PCB by about 10 degrees could I get it to work — some solder joint has come undone somewhere. As the screen was never intended to be the final solution this just puhed forwards the point at which I replaced it.

I was looking for a largish screen to display song name, menus, volumes, status messages and the like. I wanted a rectangular screen and ideally a graphical screen instead of a pure character-based screen, so I could do all my favourite games-programmer whizzy effects. Importantly I also wanted something with as few pads to solder as possible (as my soldering skills are limited) and with as few differences from the existing board I had so I could use a lot of the existing LCD support.

The Ep93xx LIRC driver

As promised, I’m posting a patch here for LIRC to support an IR detector plugged into the EP93xx processor’s IO ports.

To apply the patch you’ll need to be able to build from LIRC’s CVS repository. Grab the latest lirc down and then get this gzipped patch. From there, apply the patch and build lirc. Detailed instructions:

weebox:/home/matthew/build/lirc# zcat ../ep93xx.patch.gz | patch -p1
patching file configure.in
patching file drivers/Makefile.am
patching file drivers/lirc_dev/lirc_dev.c
patching file drivers/lirc_ep93xx/Makefile.am
patching file drivers/lirc_ep93xx/lirc_ep93xx.c
patching file setup.data
weebox:/home/matthew/build/lirc# ./autogen.sh
processing /home/matthew/build/build/lirc
Running libtoolize...
...lots more output, takes a very long time...
daemons/Makefile.am: installing `./compile'
daemons/Makefile.am: installing `./depcomp'
Running autoconf ...
Creating setup-driver.sh ...
weebox:/home/matthew/build/lirc# ./setup.sh
[Choose Driver configuration / Other / EP93xx IO driver]
[Configure the software as you see fit]
[Save configuration & run configure]
setup.sh written by Karsten Scheibler, 1999-JUN-28
If you have problems or questions please consult the mailing list
Configuration: .setup.config, executable shell script: configure.sh
...lots more output, takes a fair while....
config.status: executing depfiles commands
You will have to use the lirc_ep93xx kernel module.
Now enter 'make' and 'make install' to compile and install the package.
weebox:/home/matthew/build/lirc# make
make  all-recursive
make[1]: Entering directory `/home/matthew/build/lirc'
Making all in drivers
make[2]: Entering directory `/home/matthew/build/lirc/drivers'
Making all in lirc_dev
make[3]: Entering directory `/home/matthew/build/lirc/drivers/lirc_dev'
...lots more stuff...
make[2]: Nothing to be done for `all-am'.
make[2]: Leaving directory `/home/matthew/build/lirc'
make[1]: Leaving directory `/home/matthew/build/lirc'
weebox:/home/matthew/build/lirc# make install
... lots of installation stuff...
weebox:/home/matthew/build/lirc# modprobe lirc_ep93xx
weebox:/home/matthew/build/lirc# mode2
[point remote at detector and press buttons]
pulse 459815
space 3943
pulse 606
space 900
pulse 597
space 1898
pulse 604
...and so on...

The infra-red receiver should be plugged onto IO pin 0 (though this is configurable at module load time). Please let me know how you get on if you try this, I’ll aim to deal with any features needed or bugs found.

LIRC and a driver

Last night I built a LIRC driver for the Weebox’s infra red detector. Full credit to the LIRC guys, this was very easy, barring one unfortunate problem (isn’t there always!)

The LIRC source comes with a serial port driver, which uses an infra-red detector plugged into the serial port directly, and uses interrupts from the DCD line to note when infra-red pulses come in. I used this as reference; with one main modification: The EP9302 can detect both rising and falling edges on its IO pins. The serial port can’t and so the serial driver sits in the interrupt routine waiting for a falling edge after it has been interrupted with a rising edge. As this can be a fair few milliseconds, this is a waste of valuable kernel time for my embedded box.

During my investigations I came across a very nasty bug which initially I thought was a compiler bug. No really, it was one of those ones where inserting a printf() fixed the problem, or indeed moving the code about very slightly or changing the optimisation settings fixed it too. In the end — pretty much as ever — it turned out to be an actual programming bug: a zero-sized array was being written to (through a fairly obfuscated set of steps). I’ve mailed the LIRC guys and hopefully they can put it right in the main line.

Adventures with a Prototype Board

After a fair few days without being able to work on the Weebox, I finally got some spare time last night. Earlier in the week, the nice man from DHL had turned up and delivered my package from RS Electronics containing some resistors, a prototype board and a Vishay infra red detector. Now it was time to get on and build a circuit to plug directly onto my precious TS 7250 board.

I’m not exactly the world’s best electronics expert. Luckily the circuit I needed to get working was simple enough: The detector needed a 5V input, and the output from it needed chopping down from 5V to 3.3V for the weebox. A simple resistive divider on the output was all I needed — that and a way of getting 5V to the chip. The TS7250’s IO ports only supplied 3.3V, so I used a long wire directly over to the input 5V. An old ribbon cable was sacrificed to give me access to the IO input port and ground, and the circuit was built and installed.

An LCD driver for the Weebox

Yesterday I mostly spent learning about Linux kernel module development. I decided to bite the bullet and modify lcdmod to support the TS7200-series LCD panel. It turned out to be fairly simple in the end.

I firstly created a new configuration define ‘TS7200_CONFIG’ which switched between the default parallel port behaviour of lcdmod and the memory-mapped hardware approach the Weebox needs. Then I refactored the LCD sample code from Embedded ARM to have a rational API, replacing the ARM-specific code with kernel equivalents (mostly ndelay() calls). With appropriate #ifdefs in the lcd.c to call the TS7200 support routines, and a patched Makefile, it built fine. A bit of debugging ensued (and a fair number of reboots!) until I had everything working — the stupidest bug being me getting the parameters to writel() the wrong way around at first, so instead of writing 0x38 to address 0x8084004c, I was writing 0x8084004c to address 0x38 — boom!

In modifying the driver I discovered a crash bug in the implementation which probably doesn’t manifest itself on the PC (well, I guess not as seemingly nobody’s noticed it before!) Upon reprogramming the user-defined graphics, the virtual cursor was left at ‘-1, -1’ (to invalidate the current cursor position). This is all sensible and good…except the next character write reads and updates a virtual display array at array[-1][-1] — CRASH. The UDG reprogram code really should have moved the hardware cursor position — then in the character write code the driver spots the actual and virtual cursors are out of synch and resets the hardware cursor position. I’ve submitted a patch to the author, though with no activity on the driver since August 2004 there’s a chance the author may have moved on.

Wireless booting and flash RAM fun

After my uncharacteristically non-verbose entry yesterday (Display!), I’m going to post a little more content today. Yesterday I got the LCD display working with my little Python program prototyped on the PC earlier in the week, which got me rather overexcited. The first thing I noticed was that the sound was stuttering playing OGG files … maybe the Python idea was a bit pie-in-the sky. Luckily changing an internal polling interval to be a quarter of a second instead of a tenth fixed that; though I’m now rather doubting that Python is the best idea.

One of the other arguments against Python is the fact it’s not easy for it to talk directly to hardware. In order to program the LCD display I need to poke directly into physical RAM. Currently I’m doing this in a server process that I’ve knocked up in C by modifying Embedded ARM’s sample code. The server listens on port 4000 and with fairly minimal logic sends any incoming data on that port to the LCD device. This has worked well enough to get the Python process running; and has the nice side effect of meaning I can write a simple LCD emulator Windows program (again, in Python) and develop on the PC first. The music player library I’m using — MPD — supports generic control over TCP/IP; so I can pretty much prototype the whole thing on Windows with the sound coming out of the Weebox using this method.

Although this is working OK for now, in the future I’ll want to be able to put various other status messages on the LCD display (e.g. during boot) . A quick skirt around the internet finds lcdmod, a kernel module to control a HD44780-compatible device connected to a PC’s parallel port. This creates a /dev/lcd device which is then easily accessible from shell scripts etc via simple ‘echo “Message” > /dev/lcd’ commands. Of course, my LCD display isn’t attached to the parallel port, nor indeed does the Weebox have a parallel port! One idea I’m toying with is modifying the code to work using the memory- mapped hardware registers, it shouldn’t be too difficult to get working, and could be a good way to reintroduce myself to kernel-space, being my first kernel modifications since about 1996!