Projects

So today I got the I2C port on the expansion header working. (Its I2C2). Fairly straight forward process, but I'll write about it anyway. I should start by saying that I have been using Angstrom and Open Embedded for my development. So the two changes I made to get this working are huge hacks.

First thing you have to do is modify u-boot to have the correct pin mux configuration. This will depend on your application! For me, I have external pull up resistors so I disabled them in the pin mux, you may want to use the internal resistors. Anyway I'm getting ahead of myself. Modifying u-boot in OE is tricky because you cant change this configuration in the recipe, you have to modify the source its compiling. So what I did was:

bitbake u-boot

This gets OE to pull down the source code and build it. Now that its sitting in your temp directory you can go in make the changes. Look in $OE_HOME/$tmp/work/beagleboard-angstrom-linux-gnueabi/{gitubootdir}/git/board/board/omap3/beagle as it contains the header file we want. Open up beagle.h in your favorite editor and look for these lines:

MUX_VAL(CP(I2C2_SCL), (IEN | PTU | EN | M4)) /*GPIO_168*/\
MUX_VAL(CP(I2C2_SDA), (IEN | PTU | EN | M4)) /*GPIO_183*/\

and change them to this:

MUX_VAL(CP(I2C2_SCL), (IEN | PTU | DIS | M0)) /*I2C2_SCL*/\
MUX_VAL(CP(I2C2_SDA), (IEN | PTU | DIS | M0)) /*I2C2_SDA3*/\

So what did we do? Well the big change is M4 -> M0. MX is used to denote which function the physical pin will have. All these functions are described in detail in 7-4 of the OMAP35x Documentation. Notice I also changed the EN to DIS. This flag determines whether or not the pull up/down configuration flag is used. I didn't want pullups so I disabled them, your choice may be different here. The other two flags are fun, IEN enables input on the pin and PTU is for pullup. PTD would get you a pull down. These flags are in the comments at the top of the document so refer to them if you think I'm wrong, I might be.

So now rebuild u-boot and deploy it to get the image.

bitbake -f -c compile u-boot
bitbake -f -c deploy u-boot

And now you have a sparkling new, custom uboot image in tmp/work/deploy/glibc/images/beagleboard (gotta love these long paths).

But hold on cowboy, we are only halfway ready to boot.

Next we modify the kernel. Developers disabled I2C2 because it throws bunches of errors if not hooked up to hardware (or it used to? There are posts on the dev mailing lists about it). Its a fairly simple fix, first we do what we did before and pull down some source code:

bitbake virtual/kernel

Now head over to $OE_HOME/$tmp/work/beagleboard-angstrom-linux-gnueabi/linux-omap-2.6.29-{gitversioninfo}/git/arch/arm/mach-omap2 and edit board-omap3beagle.c. We are looking for the initialization of the other two I2C controllers, so look for these lines:

omap_register_i2c_bus(1, 2600, beagle_i2c_boardinfo, ARRAY_SIZE(beagle_i2c_boardinfo));
/* Bus 3 is attached to the DVI port where devices like the pico DLP projector don't work reliably with 400kHz */
omap_register_i2c_bus(3, 100, NULL, 0);

Once we add the extra line it looks like this:

omap_register_i2c_bus(1, 2600, beagle_i2c_boardinfo, ARRAY_SIZE(beagle_i2c_boardinfo));
/*Enable I2C2 on the expansion header*/
omap_register_i2c_bus(2, 100, NULL, 0);
/* Bus 3 is attached to the DVI port where devices like the pico DLP projector don't work reliably with 400kHz */
omap_register_i2c_bus(3, 100, NULL, 0);

So now we have it running at 100kHz and the kernel will register it during boot up (there was much rejoicing). Now to build, same as before.

bitbake -f -c compile virtual/kernel
bitbake -f -c deploy virtual/kernal

It gets a little weird here, for some reason the uImage that ends up in the deploy folder does not work for me, I have to pull it out of tmp/work/beagleboard-angstrom-linux-gnueabi/linux-omap-2.6.29-{gitversioninfo}/image/boot your mileage may vary.

Finally we need get it all up and running! Look at this page for a great step by step to get your u-boot and uImage working for you. I recommend the section called "Booting u-boot with MMC/SD Card". It also talks about formatting and such for your MMC/SD card so its a pretty good reference link.

If all works out well you should be able see /dev/i2c-2 and if you have i2c-tools installed you can probe the bus for slaves. I am currently using 5k pullup resistors, as 10k did not work at all (got lots of timeouts when probing). REMEMBER: You absolutely must have level shifting, the expansion port runs at 1.8 volts and you will likely need at least 3.3 for any peripherals. I'm using the PCA9517 from TI to go from 1.8V to 5V, it works great.

A warning: All the modifications we made are in source code pulled down by OE via git. This means that when the git version of the code gets updated, OE will no longer be building the code with our changes. I have yet to figure out how to make the changes permanent, but when I do I'll post about. I'll likely end up building a patch and find a way to apply it to any new source code. We'll see.

Hope this was helpful. I gathered this knowledge from all over and did a little tweaking myself, so credit goes to the OE and beagle board communities.

Happy Hacking!

So I had this rover I built and I wanted a better way to control it. Up until now I had been using a program written in C#(Mono) on my computer and a usb->serial adapter with a hacked together level converter. Quite a mess. Some research showed that it was easy to interface with Playstation controllers because its basically SPI. If you want to pretend to be a PS controller there are some strange things you have to deal with, but if you want to talk to one its much simpler.

Most of the work had already been done (here and here), but I needed an implementation for the ATMega88 (the micro I happened to have laying around in a DIP package). Considering that the code is pretty much portable to the 168 I had no reason not to give it a try while waiting on my Digikey order to come in.

Everything went well, the interface is simple. Only real speed bumps were missing the pullup on MISO and trying 500KHz (works great at 125KHz). Easily fixed problems. After having it working on my bench I crammed all the electronics into the PS controller (had to removed the rumble motors). Slapped a battery pack and a transmitter socket on the back and it works great. (I use the LINX TXM/RXM-916-ES chips and have them on surfboards, the sockets allow me to have multiple projects share radio gear to save $$)

Currently the rover uses tank controls (one joystick for each tread) and a trigger for the headlights. I hope to write some code for "arcade mode" control so that I can use one joystick for moving the rover and the other for moving my wireless camera on a gimbal (already assembled, but not integrated yet). I even have enough buttons for other fun things like perhaps a coil gun. Every tank needs a weapon :)

Photos via Picasa

Source Code: psx-int.c

Blurry video of it in action. One of these days I'll buy a linux friendly camera that works better.

And finally the schematic, go build one.