Super Simple 50+ kHz Logic Analysis with ATtiny2313 and FTDI Friend

AVR & FTDI logic analyzer

While banging my head against the wall with debugging my PS/2 keyboard thingy, I really wished I had a dedicated logic analyzer (preferably with PS/2 decoder, but even raw binary data would’ve been fine). So I decided to try out a long hatched idea – combine an ATtiny2313 and FTDI for some unlimited-length logic capturing with a PC. You’ll only need:

  1. ATtiny2313
  2. 20 MHz crystal and caps (slower will also work, frequency just defines what baud rates you’ll achieve)
  3. FTDI USB/serial converter, like the FTDI friend from Adafruit
  4. Optionally, some power-stabilizing capacitors, reset pullup and ISP programming header for flashing the firmware

ATtiny2313 is ideal for this, as it has all eight port B pins on one side in numerical order – attaching up to 8 logic lines is really straightforward. With 20 MHz crystal, baud rates close to 1 Mbps can be achieved in fast serial mode. I used Adafruit’s FTDI Friend for really simple (and way faster than most cheap serial adapter dongles) serial to USB conversion – just connect ATtiny RXD pin to TX, and TXD to RX, and you can even get power from the Friend so you’re all set! For crystal and that other stuff, see my ATtiny2313 breadboard header post for schematic, the picture above should fill you in with the rest.

Firmware code

This device has some of the smallest firmware codebases ever (firmware is 128 bytes). All we need to do is to set up UART with desired speed, and have the AVR chip to fire up an interrupt whenever data has been sent, and then use that to send current state of port B (using PINB):

#include <avr/io.h>
#include <avr/interrupt.h>

void USARTInit(unsigned int ubrr_value, uint8_t x2, uint8_t stopbits) { 
  // Set baud rate
  UBRRL = ubrr_value & 255; 
  UBRRH = ubrr_value >> 8;

  // Frame Format: asynchronous, 8 data bits, no parity, 1/2 stop bits
  UCSRC = _BV(UCSZ1) | _BV(UCSZ0);
  if(stopbits == 2) UCSRC |= _BV(USBS);

  if(x2) UCSRA = _BV(U2X); // 2x

  // USART Data Register Empty Interrupt Enable
  UCSRB = _BV(UDRIE);

  // Enable The receiver and transmitter
  UCSRB |= _BV(RXEN) | _BV(TXEN);
}

int main() {
  // 230.4 kbps, 8 data bits, no parity, 2 stop bits
  USARTInit(10, 1, 2); // replace 10 with 4 to get 0.5 Mbps

  sei(); // enable interrupts

  while(1) {}
	
  return 1;
}

ISR(USART_UDRE_vect) {
  UDR = PINB;
}

Continue reading Super Simple 50+ kHz Logic Analysis with ATtiny2313 and FTDI Friend

Arduino PS/2 Keyboard Tester

Arduino PS/2 tester

Once I got my minimal AVR PS/2 keyboard device built, it quickly became apparent that such a device should be able to respond to rudimentary PS/2 commands if I would like to avoid irritating errors in BIOS and O/S side.

After spending a couple of educating evenings with my PicoScope (the only device I had at hand that could capture several seconds of PS/2 traffic at 100 kHz or more to make sure I detect each individual level change) and trying to understand bit-level PS/2 signals (I’ll maybe do a short post on that effort later), I decided it would be too complicated for debugging my own wanna-be PS/2 compliant device. So I decided to implement a simple PS/2 tester sketch with Arduino.

Basic Arduino Setup

There is already a great Arduino/Teensy library called PS2keyboard that had done most of the thinking work for me – the core of the library is an interrupt routine that is called automatically when the Arduino detects falling edge (logic level going from HIGH to LOW) on the clock pin. In Arduino Uno, pin 3 is attached to INT1, and setting up the interrupt is very simple:

#define CLOCK_PIN_INT 1 // Pin 3 attached to INT1 in Uno
// ...
attachInterrupt(CLOCK_PIN_INT, ps2int_read, FALLING);

Continue reading Arduino PS/2 Keyboard Tester

PiSerial Arduino Communication Library

RGB LED demo

As a continuation to my Raspberry Pi and Arduino communication post, I thought I’d do the same but opposite way. This time, I thought it would be nice to make a proper Arduino library to make the process more streamlined.

To make communication more robust, I decided to implement a more formal communication over serial to enable applications that have some idea if a command sent to Arduino was successfully carried out or not, and also introduce basic error recovery if invalid commands or wrong number of parameters are received.

If you haven’t worked with Arduino libraries before, I suggest you to familiarize yourself with this basic tutorial or the other one at Arduino Playground. If you’re not familiar with AnalogWrite(), a quick peek to Arduino PWM Tutorial may also be in order.

Serial communication protocol

I wanted to make a simple formal protocol to send commands and hex, byte or word-sized parameters related to that command over serial line to the Arduino. For the protocol, I had these requirements:

  1. Text-based, so communication can be emulated with Arduino IDE’s “Serial Monitor” tool
  2. Size-efficient to speed up communications with slow baud rates
  3. Support for at least a few dozen commands and free number of parameters
  4. Success and error messages from Arduino
  5. Capability to return to known state after invalid commands, invalid number of arguments, communication errors or breakdowns

After some consideration, I chose to select non-overlapping sets of symbols from the ASCII character set for commands, parameters, control characters and success/error messages:

  • Small letters (a-z) for commands (26 should be enough for everyone, right?)
  • Numbers 0-9 and capital letters A-F to send parameters as hex-encoded values
  • Newline to mark end of command and parameters (either ‘\r’ + ‘\n’ or just ‘\n’)
  • Capital letters O, K, and R for success (OK) and error (RR) indications

With non-overlapping characters used for different things, detecting errors in sent commands becomes easier, as any “non-expected” character marks an error situation and as status messages OK and RR do not appear in commands, implementing two-way communication (commands to both directions) is easy later on.
Continue reading PiSerial Arduino Communication Library

Raspberry Pi as Arduino HDMI Shield

Arduino to Pi serial link

Merry Christmas to everyone! Today’s hack is something that I’ve been planning to try out for a while: Using the Raspberry Pi as a (relatively inexpensive) “HDMI shield” for the Arduino microcontroller. While the Pi can easily do most things that the Arduino can and usually much more, one might have an otherwise complete project (for example, something related to home theater automation) that would benefit from HDMI output.

Arduino display shields are not the least expensive, so why not use a RaspPi instead? There have been hacks for using RaspPi as network shield, too, and this project is very much like it (actually, you could change the Pi-side code just a bit and have some network-related commands available for your Arduino in no time).

The basic hardware premise for this hack is very straightforward – wire the Pi and Arduino together using the serial interface available on both. Because Pi is 3.3V and Arduino 5V, a level converter is needed – I used one from Adafruit this time, as it’s dead simple to use and doesn’t pose the dangers of overloading Pi like my simple resistor option does (you might, however, check that link out as it contains the pinouts for RaspPi serial pins in the GPIO header).

On software side, the Pi acts as a “server”, taking simple display commands via serial link. You could even start the Pi server script and connect to the serial port with Putty, and the session could look a bit like the following:


# initialize viewport - not actually implemented yet
init 500 500
# draw a 10x10 rectangle at (5,15)
draw 5 15 10 10
# exit the server
exit

The python server uses pyserial for serial communications, currently at 9600 bps, but the Pi and Arduino should be able to do 115 200 as well. For graphics, pygame framework is used. Current version of code initializes a 500×500 pixel graphics viewport, but one could use the parameters given by “init” command from Arduino side to define that, too. The code should be rather straightforward to understand: there are only two supported commands, “draw” with four parameters, and “quit” to exit the otherwise infinite loop waiting for draw commands (I named the file ar2pi.py):

#!/usr/bin/env python

import serial
import string
import pygame

ser = serial.Serial("/dev/ttyAMA0",9600)
ser.open()

pygame.init()
window = pygame.display.set_mode((500, 500))
colour = pygame.Color("blue")
pygame.mouse.set_visible(False)

quit = False

while not quit:
	line = ser.readline()
	words = line.split()

	if words[0] == "rect":
		pygame.draw.rect(window, colour, (int(words[1]), 
                                 int(words[2]), int(words[3]), int(words[4])))
	elif words[0] == "exit":
		quit = True
		
	pygame.display.flip()

ser.close()

Continue reading Raspberry Pi as Arduino HDMI Shield

Arduino and Raspberry Pi Serial Communication

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:

1:2345:respawn:/sbin/getty 115200 tty1
# Line below commented out
# 2:23:respawn:/sbin/getty -L ttyAMA0 115200 vt100
3:23:respawn:/sbin/getty 115200 tty3
4:23:respawn:/sbin/getty 115200 tty4
5:23:respawn:/sbin/getty 115200 tty5
6:23:respawn:/sbin/getty 115200 tty6

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.
Continue reading Arduino and Raspberry Pi Serial Communication

Raspberry Pi Serial Console With MAX3232CPE

In addition to the audio, video, network and USB connectors, the Raspberry Pi also has 26 GPIO pins. These pins also include an UART serial console, which can be used to log in to the Pi, and many other things. However, normal UART device communicate with -12V (logical “1”) and +12V (logical “0”), which may just fry something in the 3.3V Pi. Even “TTL level” serial at 5V runs the same risk.

So in this short tutorial, I’ll show you how to use a MAX3232CPE transceiver to safely convert the normal UART voltage levels to 3.3V accepted by Raspberry Pi, and connect to the Pi using Putty. This is what you’ll need:

  • Raspberry Pi unit
  • Serial port in your PC or USB to serial -adapter
  • MAX3232CPE or similar RS-232 to 3.3V logic level transceiver
  • 5 x 0.1 uF capacitors (I used plastic ones)
  • Jumper wires and breadboard
  • Some type of female-female adapter

The last item is needed to connect male-male jumper wires to RaspPi GPIO pins. I had a short 2×6 pin extension cable available and used that, but an IDE cable and other types ribbon cable work fine as well. Just make sure it doesn’t internally short any of the connections – use a multimeter if in doubt!

The connections on Pi side are rather straightforward. We’ll use the 3.3V pin for power – the draw should not exceed 50 mA, but this should not be an issue, since MAX3232CPE draws less than 1 mA and the capacitors are rather small. GND is also needed, and the two UART pins, TXD and RXD.
Continue reading Raspberry Pi Serial Console With MAX3232CPE