Jan 192013
Just a picture of the Raspberry Pi running

Just a picture of the Raspberry Pi running

I recently received a Raspberry Pi from a friend and I wanted to see if I could tie it to one of my Arduino boards without using a USB cable. The tutorials I found were helpful and relatively simple but were missing some details that I thought would be helpful. So I’ve decided to make a (hopefully) more simple tutorial to get people up and running with serial on the Raspberry Pi’s GPIO pins.

Required hardware:

The first thing is to get your Raspberry Pi up and running. I used this wiki page to get an operating system (Raspian Wheezy for me) installed in my SD card. I had to use the “flashnul” software because the Win32DiskImager software used in the “easy way” wouldn’t recognize my SD card.

Once that is done you can plug a keyboard and a monitor into your Raspberry Pi (you don’t need a mouse for what we’re doing). I used the yellow composite cable port to connect my Pi to an old portable DVD player. Plug the power cable (micro USB) into the Raspberry Pi. When it starts for the first time you will see a configuration settings screen. I followed the steps in this tutorial to get mine setup.  Additionally, I enabled the SSH server because I didn’t want to have so many things plugged in when using my Pi. When you’ve finished with the configuration and you’ve rebooted your Pi it will present you with a login screen.  If you had plugged in an ethernet cable to your Pi you should have seen an IP address during boot. I use this IP address to SSH into my Pi from my desktop computer. The login name is “pi” and the password is the one you setup during configuration. Log in to your Pi (I logged in via SSH).

Note: don’t run the “startx” command after you log in. You can do everything you need for this tutorial from the command line.

Now you can begin installing the junk you need to get going with serial over GPIO.

The first thing I did was update the Pi. press “y” when prompted: sudo apt-get update && sudo apt-get upgrade

The next thing is to get Vim installed: sudo apt-get install vim

Now for the actual serial over GPIO configuration…

Use vim to comment (#) this line out of /etc/inittab (it was the last line in my inittab file):

T0:23:respawn:/sbin/getty -L ttyAMA0 115200 vt100

so that line becomes:

#T0:23:respawn:/sbin/getty -L ttyAMA0 115200 vt100

I think I rebooted at this point although I’m not sure it matters: sudo reboot

Then use vim to remove this section from /boot/cmdline.txt

console=ttyAMA0,115200 kgdboc=ttyAMA0,115200

Be careful to remove only that.

Reboot your raspberry pi: sudo reboot

Then install minicom: sudo apt-get install minicom

Now your Raspberry Pi is ready software-wise.

Load this sketch onto your Arduino:

byte num = 0;

void setup()

void loop()
  if (Serial.available())
    num = Serial.read();
    Serial.print("character recieved: ");
    Serial.println(num, DEC);

After that’s been loaded onto the Arduino, turn them both off and wire them up according to this diagram:

Raspberry Pi to Arduino serial wiring diagram

created with draw.io

Also this might help:

GPIO Header - Raspberry Pi

Additionally, there are some pictures of my wiring setup at the bottom of the page.

Double check your wiring. I’ve heard that you can break the crap out of your Raspberry Pi if you do it wrong.

I’m not sure the order matters, but turn on your Raspberry Pi and then turn on your Arduino. Login to your Pi and enter the following command to connect to the Arduino:

minicom -b 9600 -o -D /dev/ttyAMA0

Now whatever you type is sent to the Arduino and the Arduino responds with the decimal format of the character that it received (see asciitable.com)

minicom screenshot

Also, to get out of minicom do: ctrl-a q

Success! Your Raspberry Pi is now communicating with your Arduino over the GPIO pins.

This might be useful for testing, but in order to do something more useful you might want to communicate with the Arduino using Python.

Exit out of  minicom: ctrl-a q

Run this command to install the necessary python serial library: sudo apt-get install python-serial

Then you can write a python program like this to send data to the Arduino over the serial line:

import serial
ser = serial.Serial('/dev/ttyAMA0', 9600, timeout=1)

        while 1:
                response = ser.readline()
                print response
except KeyboardInterrupt:

Run the program with: python <program file name>

And your output should look something like this:

Python serial program output

press ctrl-c to exit the program.

Well that’s all for now. Have fun and let me know in the comments if you have any questions.

Some pictures of the process:

the full setup

the full setup

Raspberry Pi wiring

Raspberry Pi wiring

Arduino wiring

Arduino wiring

Breadboard wiring

Breadboard wiring with Logic Level Converter

 Posted by at 1:58 PM
Jul 052012

I took another printer off of my stack yesterday. This one happened to be a Lexmark X125. My original intent was to turn it into a PCB printer, but after trying a few test prints I found that there wasn’t anymore ink left in it and I wasn’t about to buy ink for a printer that I got for free; there are plenty more where that one came from. Thus, I began to destructionate.

The last printer I disassembled had a pretty nice little LCD in it, so I figured that I would at least have a look at the LCD in this one to see if it was even worth my time. Digging in I found that there were 14 pins leading into the LCD:

A quick google search of the part number on the back of the LCD (“P1620B”) lead me to this thread. Reading through I saw that someone noted that the 14 pin version (more commonly 16 pins I think) was probably just missing pins 15 and 16 which were for a backlight. Thinking about it some more, it kind of reminded me of one of the LCDs that Sparkfun carries. If it was only missing a backlight then it would be extremely easy to interface to since the Arduino environment comes with example code for this kind of LCD.  So I desoldered the LCD from the ribbon cable…

And I soldered some header pins on the LCD (sorry, no “exciting” pictures for this part). And I wired it up to an Arduino Pro Mini on a breadboard according to the wiring example for the LCD page on the Arduino site. And I pulled up the “Hello World” example code for the LCD. And… it wouldn’t compile. … well back to the pile Arduino 0022. I pulled up the example code on Arduino 0022, compiled successfully, and spank:

That was a lot easier than last time.

Got any working LCDs you’ve salvaged from old printers/electronics? Drop a link in the comments.

 Posted by at 8:47 PM
May 192012

I’ve recently acquired a few printers for salvaging the stepper motors out of them. In taking one apart (specifically a Brother MFC-5860CN), I found that the LCD had a 6 pin ribbon cable connected to it. I figured it wouldn’t be too hard to figure out the communication protocol and talk to it so I gave it a shot. Well it wasn’t too hard, but it did take some time and effort.

Brother LCD Hacking

I picked up an Open Workbench Logic Sniffer from SeeedStudio. This is a pretty useful tool for the price.  I had only seen someone work with a logic analyzer before so I had to do some learning before I could start to use it. If you end up getting one, I found this page to be a pretty good documentation hub. I also watched some youtube videos about how to use it which were only somewhat helpful.

After acquiring a passing knowledge of how to use the logic analyzer, I needed a way to get to the logic signals from the tiny connector. So… this happened:

LCD connections to connector

This wasn’t as hard as it could have been, but was still pretty hard especially since some of the wires fell off several times and I had to re-solder them in between the other wires without accidentally desoldering the other wires. And then, I attached some wire clippies to the wires above and to a breadboard where my logic analyzer was plugged in:

Logic analyzer connected to the Brother printer LCD

Great, so everything was plugged in and ready to figure out. But what exactly was I trying to figure out:

Brother printer LCD character display

In case you can’t read upside down and backwards, it says “Please Wait”. I needed to figure out how it was sending those words over the 6 wires that the LCD was connected with. So then I connected my logic analyzer to my computer and started capturing data. The logic analyzer only captures logic for a short window of time, and the message seen above only appears on the screen for about 2 seconds so I had to be quick and precise. I would plug the printer in, then wait a second or so, and then hit capture on the logic analyzer software. This was not easy. After struggling for about an hour I finally got something that looked like the data I was looking for, but I wasn’t sure.

capture data

The logic analyzer software has options to analyze I2C, SPI, and a bunch of other types of logic. I was pretty sure that it was either I2C or SPI, but I didn’t know which one, and I didn’t know enough about either one to figure it out. I was finally to the point in my electronics hobbiest career where I had to learn I2C and SPI. I had a feeling that it was using I2C so I started with that.

A quick Google search of “I2C” lead me to this tutorial, and after a bit of reading I felt I had a pretty good understanding of the bus. Since I felt like the data was I2C, I decided to wait on learning the SPI bus. However looking back at and analyzing the logic capture file that I had saved, I realized that the software wasn’t analyzing the data as anything readable and there was a mysterious line that would go logic low when the data was sent. It was time to stop being lazy and learn SPI (which, in the end, wasn’t really that difficult).

Another quick Google search of “spi tutorial” lead me to a couple of tutorials (first one, second one). Turns out that mysterious line that would go logic low when data was sent was the slave select line. Plugging what I learned into the logic analyzer software and tweaking the settings a bit led me to a really geeky point in my life. I saw the following on the screen and was more excited than I’d like to admit:

spi analyzer showing please wait

“Please Wait” it said. I had learned the language of the LCD. It was using SPI! Now it was time to rig up my arduino to talk to the LCD. So then I did this:

Arduino to LCD connector

Don’t worry, this isn’t the same connector from before that I soldered wires to for use with the logic analyzer (you were worried weren’t you). Luckily I had a similar Brother printer that used the same LCD and connector. I desoldered the connector from that printer very carefully since it’s mostly made of plastic and plastic tends to melt when you poke it with a soldering iron. Then I soldered on some wires and plugged it in to a breadboard with a 16MHz/5v Arduino pro mini on it. And then, I wrote some code using the SPI library to recreate what I was seeing on the logic lines. And then, I wired everything up and uploaded the code… And then it didn’t work.

My best guess was that, even though I was dividing the clock frequency by 128, 125kHz (16MHz / 128) was just too fast for the little LCD. hrm. Measuring the wavelength of the clock signal in the logic analyzer software showed me that the printer was sending data at 33kHz-ish. I had a 4.096MHz crystal lying around which, with the same setup, would get me to 32kHz. Close enough. I busted out my DIP Atmega328P, wired it up with the crystal, wired it to my Pocket Programmer, plugged it in, tried to program it, remembered that for some reason the pocket programmer only works with the old version of the arduino software, opened arduino version 22, sucessfully programmed the Atmega, and… no luck. Now I was really confused.

My best guess now was that I missed something when looking at the logic. Maybe there was something required at start up for the LCD to work. But I wasn’t about to try and get the timing perfect by plugging in the printer manually and manually clicking capture. That was ridiculous last time, and it took way too long to find the window of logic where the communication was happening. If I tried that method again, frustration and anger would happen, and something might be destroyed. I previously had an idea that I could use my controllable power outlet and some Java code to automate the process of plugging the printer in and pressing the capture button on the logic analyzer software.

I figured I could use some keyboard simulation to press the enter key with focus on the capture button, and that didn’t turn out to be very hard at all. I found that Java’s Robot class made it really easy to simulate the enter key being pressed. Now I needed to figure out how to connect to a device on a COM port, and read from it. This device would be an arduino connected to my controllable power outlet. However, doing this in Java turned out to be not so easy. In fact, apparently this is no longer supported in Java. That sucks. Now what to do.

I’d heard of people connecting to their arduinos using Python, but before I could try that I had to relearn Python. The version of Python for windows comes with a very in depth help tutorial, which I read for a couple of hours. Once I was familiar enough to do some basic tasks I started diving into python libraries. I quickly found PySerial (download) which would make it relatively easy to connect to a COM port and do read/write operations. Then after looking through a couple of other libraries I found one that would do keyboard simulation (tutorial).

I combined some proof of concept python scripts and created a script that would allow you to specify waiting times (in milliseconds) for the turning on of the power outlet and the pressing of the enter button. By changing these times (mostly just the power outlet time) I was able to capture data from right after the printer was turned on. There ended up being nothing really useful there, however I kept playing and found a set of wait times that would capture the beginning of the data transmission (which I had seen before when I found it manually). Looking more closely at this logic, I found a sequence of numbers (13, 72 ,9) being sent before each transmission. When I uploaded the program with this sequence of numbers at the beginning of the transmission and did some rewiring it said “Hi”.

logic learner

the controllable power outlet setup

I had done it! I successfully reverse engineered the LCD. I turned it on and off a couple of times, dragged my wife over to show her my accomplishment, and then realized that there was something wrong. Occasionally when I turned it on, the letters would smear down so that there were ugly lines showing on the screen instead of the text that was supposed to be showing. It was great that I had figured out how to make something show on the screen, but I wasn’t finished. This project was not complete (are you tired of reading yet?).

Brother LCD lines in screen

"Hello World?" being smeared down the screen

My first guess this time was that there was noise in the lines and I needed some filtering caps. After looking at the PCB from the printer, I found that there were some capacitors on there that I had missed when recreating the circuit. So then, I measured the values with a multimeter and found some lying around that had the same value. But inserting these capacitors into my circuit did not fix the problem.

In my original measurements to figure out the ground and power lines of the LCD, I had found that there were 2 lines that read as 5v which were pin 1 and pin 3. I had previously noticed that with only pin 1 connected to 5v the LCD would not work at all, so I had connected pins 1 and 3 together so that they were both at 5v. This was my current setup. I tried the only other option of connecting only pin 3 to 5v, and voila!, the LCD was turning on and printing the text (now “Hello World?”) every time. However, the screen was much more dim than it was when it had occasionally worked with the previous setup.

I was starting to get the idea that pin 1 was the contrast pin, and, after testing my theory by plugging pin 1 into my 5v line on my breadboard after the text was already showing, I found that to the best of my knowledge that pin 1 was indeed a contrast pin. So now my idea was that I needed to pull pin 1 high after the text was already being displayed. I wired pin 1 to pin 12 on my ATMega chip (arduino pin 6) and rewrote my program to turn on  pin 6 after the text was being displayed. At this point I’m feeling like I should be really close to just stomping on the whole thing if it doesn’t work. It didn’t work (however it was surprisingly not that frustrating).

I had one last idea to try before I was ready to quit and write this project off as beyond my current knowledge. There were periods of hundreds of milliseconds that I had not seen in the logic. It was time to stop taking shortcuts and just figure the whole thing out, so I, once again, got out my controllable power outlet setup, and started precisely writing down everything that I saw in the logic. What I found (from my notes):

vcc goes high
<1ms passes
contrast goes high
133ms pass
ss, sck, and mosi go high
7ms pass

3 (decial) is sent (start of sequence 3, 40, 20)
7ms pass
40 (decimal) is sent
7ms pass
20 (decimal) is sent
40ms pass

10 (decimal) is sent
140ms pass

26 (decimal) is sent (before it was 13)
7ms pass
72 (decimal) is sent
7ms pass
9 (decimal) is sent
26ms pass

then the following in decimal all while ss is low:
192, 0, 255 (32x)
(ends about 1350ish)

about 1800ms pass

at 1000, 3232-ish (power wait, capture wait)
3 (decimal) is sent
1.2ms pass
40 (decimal) is sent
1.2ms pass
20 (decimal) is sent
48ms pass

10 (decimal) is sent
200ms pass

26 (decimal) is sent (before it was 13)
1ms pass
72 (decimal) is sent
1ms pass
9 (decimal) is sent
7ms pass

then the following in decimal all while ss is low:
192, 0, “Please Wait” converted to hex space filled (space is 32 decimal)

Turned out that I was still missing some things. The numbers 3, 40, 20, and 10 were being sent right after startup, and what I thought was a 13 before turned out to be 26 (a logic analyzer software fluke I’m guessing?). So I programmed my ATMega 328 to precisely reflect my findings and I held my breath… uh… It worked? It really worked! I turned it on and off a couple of times to test it, and I couldn’t seem to find anything wrong. Wow. That was a long process.

LCD showing Hello World?

I began the process of cleaning up my code and found that most of the timing didn’t really matter. It didn’t even matter that I was using a slower crystal. Using a regular 16MHz arduino worked fine. It was the 3, 40, 20, 10 sequence that did the trick. If only I had looked at all of the logic first. Still the path I took made for a good learning experience.

I just finished writing up an arduino library to do some fancy stuff with it. Check out my video below. Thanks for reading, and I hope you got something out of it.

UPDATE: Here’s a pinout to for the ribbon connector. Also I’ve added my arduino library and demo code to Github. For immediate use, you can download the BroLCD library and demo code as a zip file here.

ribbon connector pinout


 Posted by at 5:53 PM
Jul 202011

Slurp (this is me drooling). I want one. This thing is awesome.
RC Controller of Awesomeness

16+ channels alone would do it for me, but this thing goes so much further than that by including the following and more: 2 way communication with the receiver, AMOLED Touch-Screen, Linux based UI, and the ability to add a Video receiver unit for real time preview and/or recording.

On top of all the Controller functions, the receiver unit will have internal accelerometers and a gyro as well as a modular design for easy modification.

Let’s just hope they get the funding they need to start making them.

Check out the project page for more information.

 Posted by at 11:15 AM