Due to recent events (I became a dad a second time 🙂 I revisited my audio baby monitor project for Raspberry Pis called Pifon. The former setup of having one Pi observing one room is not enough anymore and therefore the new version adds multi-room support!
mon observing 2 fon clients now
Now you can add as many fon clients as you like. Well, at least up to 3 will be shown in the new UI on the LCD 🙂 All others are still handled but not shown.
While hacking the source I almost completely rewrote the XMPP based bots for mon and fon parts and added some nice features along the way: Configuration is a lot easier now and audio streaming was optimized.
Now a direct SSH pipe is created to connect the microphone device on the fon unit with the player on the mon unit. In favor of this new approach the old way of using a streaming server was dropped. (If you still need it then the new config freedom allows you to simple add the necessary commands again.)
Finally, the UI on the 16×2 LCD was greatly improved and can now show scrolling text if something interesting happens and furthermore draws nice bar graphs showing the incoming audio levels:
Pifon mon running in simulator. Showing some activity bars
The screenshot shows the new LCD simulator that allows you to run the mon client also on a system without real HW LCD connected (but you then need PyGame for display)…
Now head over to the new pifon Project Page and start building your own now!
I am a big fan of those small TFT displays in the size of the Raspi. They even come with a resistive touch panel and allow you to realize small applications with full UI control. With the fine fbtft drivers from notro you can access them as regular framebuffers and use all software that runs otherwise only on “big screens” via HDMI.
While setting up the TFT support in a Raspbian system was quite complex and includes compiling an own patched kernel, nowadays things got really simple. In this post I’ll give you a overview on the setup and how easy it has become…
(And it works for good ol’ Model A/B, A+/B+, and shiny new Model B2!)
When working with an Amiga running on a Minimig platform then data transfer isÂ not as convenient as one might think: You have an SD Card connected and copyingÂ files around with SD Card is not the biggest deal, but unfortunately your AmigaÂ is currently running from a system drive stored on this card :/ Each copy operationÂ therefore essentially requires a reboot of your Amiga and that’s not theÂ productive work flow I had in mind…
That’s the reason why I always prefer having network access on all my machinesÂ for truly covenient file handling (e.g. with FTP, wget…).
In my last post I showed you how to add a SilverSurfer high speed serial portÂ to your Minimig running on the Turbo Chameleon 64. Now we will use this serial port that is running up to 115200 Baud with easeÂ for something useful: networking! Old farts remember the times when homeÂ network access was done with PPP and a serial modem gateway. We’ll go that roadÂ but replace the modem and gateway with a small and cheap Linux machine, hereÂ the all hyped Rpi and a direct serial “null modem” link via an USB-to-serialÂ adapter.
TC64 with SilverSurfer attached to Raspi
Read on to find out all the glory details, starting with a pure “virtual”Â simulation running on a Mac on to the real thing…
[You can use this approach to bring other classic Amigas to the network, too.Â But for all machines with a parallel port available I’d suggest to use myÂ plipbox project: Its far easier to setup, a lot faster (4-5x ), and even cheaper :)]
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…
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…
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 :)…
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…
I really like my Raspberry Pi, but what I am missing is a tiny display matching the size of the board that can be used as primary display, the boot console or some graphics later on.
A very nice and cheap TFT display is theÂ MI0283QT-Adapter (note: I got the -2 version not the newer -9 version that has another display driver chip!) sold by Watterott. Its mainly focused to be an add on for the Arduinos, but it should work on every embedded system providing SPI access.
For the Linux running on the Raspberry Pi a framebuffer driver for the display would be the best solution, as it allows you to use it as a boot console and then you can run everything that runs on a framebuffer device (e.g. X11, SDL, mplayer, …).
First I thought about writing a fresh driver from scratch but some google-fu showed me that there already exists a nice solution: user notro has written fbtft, a driver framework that allows to simplify writing an own driver for those tiny TFTs.
For the R61505u display chip found on my display board, there was no driver available, but thanks to notro’s powerful framework and Watterott’s example code (Thanks to Markus for porting the code to the Raspi), I was able to derive a new driver for this chip in a few hours: See my cloned fbtft Git Hub repository for the source.
It works really nice: with 32 MHz SPI clock I can run 25 frames per second and even watch movies with smooth display:
Playing Big Bug Bunny with MPlayer's fbdev output
If you compile the driver directly in your kernel (i.e. no modules) then you can use the display directly as the boot console of your board:
Linux Boot Console running on display
If you want to build this setup yourself then read on…