A go-playing friend of mine had a broken “Excalibur” chess clock that we here in Europe use extensively in go tournaments. The LCD was shattered and I don’t think they ship replacement parts:
Because the clock is not of much use without a display, I got to rip it apart to see what it contains. This particular clock is used quite a lot, so I thought I’d share the images. Note that you can click on pictures to view larger version of the image.
One of the nicest things when starting a new hobby is that there’s just so many things you don’t yet have, and can thus look forward to researching and then maybe buying if the price is right. In electronics, you can pretty much get started with a $10 soldering iron, $25 multimeter, maybe a $30 programmer if you want to use microcontrollers, and then just buy cheap components to tinker with. But sooner or later, you start thinking about how nice it would be if you had an oscilloscope.
For me it took about nine months. I saw an article on using AVR as an RFID tag and noticed I could build a simple RFID reader with a few components. However, to really learn something, it would be nice to actually see the 125 kHz RFID carrier wave instead of fumbling blindly with the schematics. Additionally, I could use the scope to verify DIY D/A circuits, maybe debug serial protocols and much more. So I started researching.
Getting a used analog or digital scope from eBay was of course one option. However, old scopes are big, clunky and I don’t really have much table space. And if the scope fell out of use, it would be wasting space in a closet. New Chinese-made digital scopes from Owon and Rigol looked good and were relatively small and light. However, they had 640×480 or 800×600 displays and I had 2560×1600 30″ monitor sitting on my workspace, and being more of a software person, I eventually decided against them and chose to get a PC scope instead.
Options in USB scopes
Going through the options for digital scopes, there seemed to be a few price brackets:
Since my brief journey to controlling LCD display directly with ATtiny2313 I purchased a display with Hitachi HD44780 compatible driver chip. The web is already pretty full of LCD tutorials and libraries, but most seemed to either skip details and rely on external libraries, or were just overly complex. So I decided it wouldn’t hurt to share the rather short (and functionally limited) versions I came up with.
In 8-bit mode, you will be needing 8 pins for sending or reading a whole byte of data at once, and 3 control lines: enable (EN), register select (RS), and read/write (RW). Basic procedure is to prepare all other lines, and then pulse the enable line high for a short while in which LCD reads your command (when RW is low) or writes data (when RW is high). For control messages, RS line is low, and for writing letters, RS line is high.
I started with ATtiny2313 and used the 8 pins in port B as LCD data lines, and PD4, PD5, and PD6 as RW, RS, and EN, respectively. With such a setup, working write command became:
My local electronics shop Partco (arguably the best in Finland) had a great offer on 6-digit LCD displays. For 1€ a piece, I immediately bought one:
Once I had my hands on it, the reason for such a low price became apparent: There was no controller chip, only 50 pins and the knowledge that pin 1 was “common cathode” and the rest were for the segments. So I decided to see if I could get it work directly without a controller. And succeeded, read on to learn how!
All right. Now that we got the basic USB code working in part 3, it’s time to wrap things up in this tutorial series. This fourth section will explain how to send data from your device to PC and also the other way around. I may later do a fifth part on how to make a USB HID device like a keyboard or mouse, so if you haven’t already, I’d recommend subscribing to the RSS feed to get updates.
Sending data from device to PC
If you look carefully at our command-line client code, you probably noticed that the control messages sent to toggle the led are of type USB_ENDPOINT_IN and we have a 256-byte buffer in place to receive any data the device sends. So far we have not received any data and the return value stored in nBytes has been zero. Let’s change that.