Watterott’s new RPi-ShieldBridge

With the ili9341fb driver I wrote for notro’s fbtft driver suite you can easily connect and use a Watterott MI0283QT9A display with your Raspi. For now you had to wire the display yourself to the Pi and a nice plate connecting the display was missing. Now the wait is over: Watterott designed the RPi-ShieldBridge! This nice little plate features the display connector (but also contains a full fledged Arduino board with shield connector)!

Watterott was so kind and sent me a prototype v1.0 of the ShieldBridge (Thanks again, guys!). In this post I give you a short roundup of this nice hardware that will hit the stores in early/mid August…

Continue reading

Added SegTracker in FS-UAE’s Debugger

For most classic Amiga developers Michael Sinz’ Enforcer is a valuable tool for debugging. Especially the contained tools SegTracker and FindHit are very helpful when analyzing bugs in your compiled code: SegTracker patches AmigaDOS’ functions for loading and unloading binary files and then tracks where the (code/data/bss) segments of each binary are located in memory. If a crash occurs then you can locate which binary caused it. To get more detailed information then FindHit comes into play: If the segment associated with a crash location is identified then FindHit loads the debugging info stored in an executable and then can match these infos to your location and gives you the source code file and line that was used to generate the faulty code…

I do most of my Amiga development now in a cross-dev environment on my Mac and then the FS-UAE emulator is the runtime environment to test and debug code. While it is possible to use the same Enforcer setup inside FS-UAE I really like the built-in debugger of the emulator: It allows to freeze the whole Amiga and inspect the full state. Furthermore, memory watchpoints and breakpoints are available, too. The only thing that was missing: a SegTracker feature that tells me where my application/driver code is loaded and a FindHit feature to get detailed infos on the associated source.

Thanks to open source of both FS-UAE and Enforcer I was able to add both features without too many effort: In the following I present you an extended FS-UAE that adds SegTracker and FindHit right inside the built-in debugger!

Continue reading

Building AROS hosted for Raspbian

The Raspberry Pi platform really looks very suitable for running AROS. I wanted to play with this setup and build a Raspbian (armhf) release from source (so I can hack on if I like to). I chose the Linux hosted version of AROS as it is already available in the source tree and Raspi’s Linux kernel is a very good hardware abstraction layer for all Raspi peripherals. (The native Raspi AROS version exactly suffers from this: It has to implement all peripheral drivers that are already available in Linux – and that is a daunting task).

I had a look at the AROS Raspberry Pi Docs, but unfortunately the compilation details given there didn’t work for me. I have a xubuntu 12.04 VM running here on my Mac and it seems that this version does not support the multiarch compile given in the docs not very well… (I even had a quick check with the fresh release 13.04 but that one does not work either… so things don’t look good with this approach): The problem I encountered was that the multiarch setup does not allow to install libpng-dev for i386 and libx11-dev/libsdl-dev for armhf simulatenously. But both are required for a full compile of AROS…

I played around with the build process and found an own way to perform the build on my system. This post gives you the details…

Continue reading

Watterott MI0283QT-9 display with generic flexfb driver

Notro has added a generic frame buffer driver called flexfb in his fbtft driver framework. This driver resulted from the observation that most small TFT driver chips share a lot in common like data transfer scheme, pushing pixels, and setting the update window. The only major difference is found in the initialization sequence required to setup the connected TFT panel on your specific board. Therefore, the flexfb driver user needs only select some generic option (e.g. bus width, type of update window command) and a transcription of the init sequence found in the driver code during runtime. Then the driver can control the display.

The big advantage of this approach is that you only need to ship this one generic driver and you can support a large set of displays without actually coding them. Also adding a new device requires only extracting the init sequence from the display’s data sheet and you can test it on the command line without any driver code development!

I gave this nice approach a quick try with Watterott’s MI0283QT-9 display (that’s already fully supported in the ili9341fb driver of fbtft, but nevertheless the generic approach might be the future :)…

Continue reading

plipbox 0.4 released

Huh? Yet another plipbox release in such a short time, you might ask. While last time it was a software only update this time its a hardware update! I found such a nice new HW platform for the plipbox project that is really worth an immediate release…

While browsing ebay for some interesting hacking hardware last week, I stumbled across an Ethernet shield for the Arduino Nano that uses the ENC28J60 chip I need for the plipbox project in a very compact package… Combined with an off-the-shelve Arduino Nano v3 (clone from ebay that is) you get a very very nice packaging for the plipbox project. I call it the plipbox nano:

The release 0.4 now adds all you need to build your own plipbox nano:

  • A new firmware image for the nano (some parallel pins need to be changed due to collision with the Ethernet shield)
  • A schematic and board design for the plipbox nano base board. This board combines the parallel port connector and pin headers for the Ethernet shield. With the base board your can connect the plipbox nano directly to your Amiga and it really fits well without hiding the other connectors. See the plipbox gallery page for snapshots of an A1200 with attached plipbox nano. The board is a single layer PCB so you can build one yourself without much hassle. As an alternative you can simply use a small prototype board and solder the connector and pin headers there.

Grab your copy now on the plipbox project page and have fun building your own plipbox nano!

plipbox 0.3 released

It took quite a while but now a shiny new release of plibbox is available: The new version 0.3 is an AVR firmware and Amiga driver update and works on the same hardware as presented in 0.1 and 0.2.

The major change in this release was motivated by Nitz76, one of my commenters in the blog: plipbox firmware now implements a MAC bridge and no IP NAT gateway anymore (see this technical introduction for details on the differences). In short: While with the old firmware you created a point-to-point IP link from the Amiga to your plipbox and from there the traffic was NATed and routed to your local ethernet, the new approach directly presents an Ethernet card on the Amiga side and passes the Ethernet frames generated from the Amiga TCP/IP stack directly via PLIP to your local Ethernet.

This approach is much more compatible in your local network infrastructure as the NAT is avoided. The change required a larger rewrite of the SANA II driver and therefore I heavily modified the original MagPLIP implementation and renamed the new driver to plipbox.device (the new source code is now also hosted in the plipbox source repository). Please see the updated Amiga Setup guide for installing this driver on the popular TCP/IP stacks including AmiTCP, Genesis, MiamiDX, and Roadshow.

The new MAC bridge made a lot of the TCP/IP code of plipbox obsolete and allowed me to shrink the firmware size considerably. Furthermore, setting up the firmware is zero-conf now, i.e. you don’t have to adjust any parameters for default operation.

This release now hosts all the docs on GitHub right next to the source. It is more convenient there to keep the docs in sync with the implementation and writing markdown is really fun! Another goodie in this release is the plipbox Emulator written in Python that allows to emulate a plipbox setup in FS-UAE. Its esoteric but really helpful for development: see my previous log post for details…

Enjoy!

Emulating plipbox with FS-UAE

Recently, I had some time to spend and wanted to work on the plipbox project’s Amiga driver. Unfortunately, I only had my MacBook Pro with me and no Amiga or plipbox hardware.

What does a SW developer do if the real hardware is not at hand?

Yes, you write an emulator that represents the missing HW in SW on a machine you have access to…

Continue reading

Adding touch support for the MI0283QT* displays

In my last posts I showed how to integrate Watterott’s MI0283QT-2 and the newer -9 displays as a frame buffer device in Raspberry Pi’s Linux kernel. Now I will focus on adding support for the touch controller found on the display boards.

The touch controller is an ADS7846 chip that already has a device driver in the Linux kernel. User dronus has patched the vanilla driver to make it work with the MI0283QT displays and the Raspberry Pi.

Fine, we already have everything in place now to give it a try!

Hardware

First, we need to add two additional wires in our hardware setup to connect the touch controller (see old wiring in last post) with the RPi:

Signal     Raspi      Display   Comment
T_IRQ      GPIO25       13       Interrupt line from ADS7846
T_CS       SPI0_CE0_N   11       SPI chip select 0

Software

I assume you already have a patched Linux kernel with the tft driver patches applied. Here is quick list with the next steps:

  • (Manually) apply dronus small patch to your kernel tree. This adds the necessary modifications of the ADS driver.
  • Note: I had to replace the invert_x with the invert_y entry in the ADS configuration to match the display orientation we use in the frame buffer driver
  • Your SPI config for the display now should look like this (for the newer *-9 display): linux/file arch/arm/mach-bcm2708/bcm2708.c
static struct ads7846_platform_data ads7846_config = {
  .x_max      = 0x0fff,
  .y_max      = 0x0fff,
  .x_plate_ohms    = 180,
  .pressure_max    = 255,
  .debounce_max    = 10,
  .debounce_tol    = 3,
  .debounce_rep    = 1,
  .gpio_pendown    = 25,
  .keep_vref_on    = 1,
  .swap_xy     = true,
  .invert_y    = true
};

static struct spi_board_info bcm2708_spi_devices[] = {
        {
                // ads7846 touchscreen on chipsel=0 device
                .modalias    = "ads7846",
                .bus_num    = 0,
                .chip_select    = 0,
                .max_speed_hz           = 500000,
                .irq      = GPIO_IRQ_START+25,
                .platform_data    = &ads7846_config,
                .mode = SPI_MODE_0
        }, {
                // display on chipsel=1 device
                .modalias = "ili9341fb",
                .max_speed_hz = 16000000,
                .bus_num = 0,
                .chip_select = 1,
                .mode = SPI_MODE_0,
                .platform_data = &(struct fbtft_platform_data) {
                        .gpios = (const struct fbtft_gpio []) {
                                { "reset", 23 },
                                { "led", 24 },
                                {},
                        },
                        .fps = 10
                }
        }
};
  • I use GPIO 25 for the touch IRQ (mainly because wiring was easier this way 🙂 and had to change the relevant entries. dronus used GPIO 17 instead.
  • I reduced the SPI rate of the display to 16 MHz and the frame rate to 10 fps. This proved to be more stable with activated touch controller.
  • The older -2 display works similarly. You only have to exchange the second block with the one of the r61505u driver. See old post for details
  • Open the configuration of the kernel and select the ADS driver:
> make menuconfig
Select "Device Drivers -> Input Device Support -> [*] Touchscreens -> [*] ADS7846..."
  • Make sure to include the ADS driver directly into the kernel and NOT in a module
  • Ok, thats it! (Re-)compile kernel and install it on your RPi…

Test

After a reboot your system shows a new input device in /dev/input/*. If no other USB mouse or keyboard is connected then the devices found there are all created by the touch controller.

You can use the evtest utility to check the touch operation (Install with ‘apt-get install evtest’ first!):

> evtest /dev/input/event0

When you tap on the display you will see the incoming events. Note the x and y coordinates mapping if you tap on different corners of the display.

Now with the basic operation tested you can start X11 on your display (see last post) and use your fingers or a stylus to navigate the mouse cursor!

Open Topic

While touch operation with this driver is rock solid and works very precisely I have found one little nuisance: I can’t move the X11 cursor into the border regions of the display 🙁 Approx 5 mm at the border of the visibile display area my touch movements are not recognized anymore and I can’t move the pointer there… I am not sure if this is a limitation of the display, of the ADS driver or the parameter set for the driver… If you find a workaround for this then please post a comment!

[Update: 21.4.2013] Pre-compiled Kernel

A pre-compiled Raspbian Wheezy Kernel 3.6.11+ with both ili9341 display and ads7846 touch driver (i.e. supporting all devices on the MI0283QT-9 board) is available for download here:

pifon: an audio baby monitor for two Raspberry Pis

Becoming a dad does not only completely change your life but also changes the scope of your hobby projects (If time still permits :)) My first self-made project made especially for my newborn baby boy Felix is called pifon and is an audio baby monitor realized with two Raspberry Pi devices.

the pifon project: two Raspberry Pis converted into an audio baby monitor

Hardware

The hardware setup is fairly simple: one Pi, the pifon server, has a USB web cam attached. I use its internal microphone to record the voice of my little boy. The other Pi is the pifon monitor and has a set of analog speakers attached for the output. Additionaly, the mon device has an Adafruit RGB LCD Plate attached and I use the LCD on this little plate as output device and its 5 keys as user input. I did not mount the plate directly on the Pi but used a ribbon cable to detach it: This allows me to package the plate in its own housing (As it is easier to find a case for the plate alone):

pifon/mon: the listening Pi with the control panel attached

Continue reading

Watterott MI0283QT-9A Display for the Rasbperry Pi

In my last post I attached the Watterott Display to my Raspi. The model MI0283QT-2 I have here is not available anymore and was replaced with the newer MI0283QT-9A display modul. Unfortunately, this new display uses a different graphics chip and thus the driver I wrote won’t work for these panels… 🙁

With my new display driver skills, I thought about adding this new module, too 🙂 A few days ago I received this new model and on the weekend I finally found a little time to investigate the new driver code… The new chip is an ILI9341 and uses a 9 bit SPI protocol to receive its commands… Phew, sounds a bit strange but notro’s fbtft driver framework again comes to the rescue: he has already supported the Adafruit22 which also uses 9 bit transfers and he also added an 9-bit SPI patch for the Raspi Linux kernel… With this starting point I was able to support the new display in a few hours:

Watterott's new MI0283QT-9A display running the boot console

Since the display supports the Linux framebuffer interface its also possible to run X11 with Xorg’s framebuffer driver on it:

The display also runs the X11 desktop

Again I was able to drive the display with a 32 MHz SPI clock (even 48 MHz works) and got a stable and smooth 25 fps for the 320×240 pixels in 16 Bit RGB.

If you want to setup this display on your own Raspi then read on…

Continue reading