After getting my Raspberry Pi and successfully trying out serial console and communication with Arduino, I wanted to see if I could use the Pi as a “display shield” for Arduino and other simpler microcontroller projects. However, this plan had a minor problem: My workstation’s monitor wouldn’t display the HDMI image from Pi, and neither had it had a composite input. Working with the Pi in my living room which has a projector with both HDMI and composite was an option, but spreading all my gear there didn’t seem like such a good plan. But then I got a crazy idea:
The Pi has a composite output, which seems like a standard RCA connector. Presumably it’s sending out a rather straightforward analog signal. Would it be possible to digitize this signal and emulate a composite video display on the PC?
The short answer is: Yes. The medium length answer is, that it either requires an expensive oscilloscope with very large capture buffer (millions of samples), or then something that can stream the data fast enough so there’s enough samples per scanline to go by. Turns out my Picoscope 2204 can do the latter just enough – it isn’t enough for color, but here’s what I was able to achieve (hint: you may want to set video quality to 480p):
What my program does is essentially capture a run of 500 000 samples at 150ns intervals, analyze the data stream to see whether we have a working frame (and because the signal is interlaced, whether we got odd or even pixels), plot it on screen and get a new set of data. It essentially creates a “virtual composite input” for the PC. There’s some jitter and horizontal resolution lost due to capture rate and decoding algorithm limitations, and the picture is monochrome, but if you consider that realtime serial decoding is considered a nice feature in oscilloscopes, this does take things to a whole another level.
Read on to learn how this is achieved, and you’ll learn a thing or two about video signals! I’ve also included full source code (consider it alpha grade) for any readers with similar equipment in their hands.
Today’s the last day of my summer holiday, and I had some free time on my hands. So I decided to see if I could get my Arduino Uno and Raspberry Pi to talk to each other. It turned out the task was even easier than my previous Pi to RS-232 project – all that was needed between the two devices was some jumper wire and two 1 kOhm resistors to form a voltage divider between Arduino TX pin and Pi RX pin – Arduino understands Pi’s 3.3V signal levels just fine so Pi TX to Arduino RX needed no voltage shifting at all.
IMPORTANT UPDATE! It turns out that the RX pin on the Arduino is held at 5V even when that pin is not initialized. I suspect it is due to the fact that the Arduino is programmed via these same pins every time you flash it from Arduino IDE, and there are external (weak) pullups to keep the lines to 5V at other times. So the method described below may be risky – I suggest either add a resistor in series to the RX pin, or use a proper level converter (see this post for details how to accomplish that). And if you do try the method below, never connect the Pi to Arduino RX pin before you have already flashed the program to Arduino, otherwise you may end up with a damaged Pi!!!
Setting Raspberry Pi up for serial communications
In order to use the Pi’s serial port for anything else than as a console, you first need to disable getty (the program that displays login seen) by commenting the serial line out of Pi’s /etc/inittab:
If you don’t want the Pi sending stuff over the serial line when it boots, you can also remove the statements console=ttyAMA0,115200 and kgdboc=ttyAMA0,115200 from /boot/cmdline.txt. You’ll need to reboot the Pi in order for the changes to take effect.
I’ve wanted a more unique look to the blog for quite some while now, but hadn’t found any creative talent to help me with the process. Luckily I heard about Freelancer.com, and used their service to find a designer to help me with the process.
AFter some consultation, plus 10 hours of my work time to convert the design from Photoshop file to HTML and CSS, and then another 10 hours learning to transform that into a WordPress theme, I now believe I’m more or less ready to roll out the new look.
There may be some hiccups for a few hours at most while I’m testing the theme, and the look may revert back to Suffusion while I iron out any remaining issues. Sorry for that.
On electronics front, expect some new material rather soon – the blog design work has taken my time for the last two weeks, but I should have two very interesting projects to announce quite shortly!
Just a short post today to inform interested readers that my interview was recently featured in Electrical Engineering Community EEWeb‘s. So if you’re interested, you can read the full interview. I talk a bit about how I got into electronics, my favorite software and hardware tools, a bit about this site as well as few other things.
It’s time to wrap up my DipTrace tutorial series with a brief look at how to do Design Rule Check (DRC) with the PCB layout tool, and generate gerber files for board manufacture. Take a look at the previous part on how the board was done.
I chose Olimex PCB prototype service because it’s very inexpensive by itself: 30€ for a two-side 160x100mm euroboard plus 5.50€ for shipping. They also can panel your designs and I counted that 16 ATtiny2313 headers would fit into a single board while still leaving room to cut them apart. Read on what was needed to make sure my PCB design was ready for manufacturing!
Design Rule Check (DRC)
The first thing before ordering was to investigate Olimex requirements for the boards. I knew I had no overlapping drill holes and had taken care to use only drill sizes supported by them (35 and 39 mils), so the most important ones for me were:
At least 8 mils spacing between tracks/pads
At least 8 mils for pads (i.e. 16 mils larger pad than drill hole)
