There’s a lot of reasons you might want to emulate the keyboard on your Commodore 64. The ravages of time and dust may have put the original keyboard out of order, or perhaps you need to type in a long program and don’t fancy pecking away with the less-than-stellar feedback of the standard keys. [podstawek] has come up with the solution: a Commodore 64 keyboard emulator that works over serial.
It’s a simple concept, but one that works well. A Python script accepts incoming keypresses or pre-typed text, then converts them into a 6-bit binary code, which is sent to an Arduino over the serial connection. The Arduino uses the 6-bit code as addresses for an MT8808 crosspoint switch.
The MT8808 is essentially an 8×8 matrix of controllable switches, which acts as the perfect tool to interface with the C64’s 8×8 keyboard matrix. Hardware wise, this behaves as if someone were actually pressing the keys on the real keyboard. It’s just replacing the original key switches with an electronic version controlled by the Arduino.
[podstawek] already has the setup working on Mac, and it should work on Linux and Windows too. There’s a little more to do yet – modifying the script to allow complex macros and to enable keys to be held – so check out the Github if you want to poke around in the source. Overall it’s a tidy, useful hack to replace the stock keyboard.
Like so many other home appliances, it’s likely that even your air conditioner has a serial interface buried inside it. If you’re wondering why, it’s because virtually every microcontroller on the planet has a UART built in, and it’s highly useful for debugging during the development process, so it makes sense to use it. Thus, it was only a matter of time before we saw a hacked airconditioner controlled by a Raspberry Pi.
[Hadley] was growing frustrated with the IR remote for his Mitsubishi air conditioner; it can issue commands, but it’s a one way interface – there’s no feedback on current status or whether commands are received, other then the occasional beep or two. Deciding there had to be a better way, [Hadley] grabbed a Saleae Logic Analyser and started probing around, determining that the unit spoke 5 V TTL at 2400 bps with even parity. The next step was to start talking back.
A tachometer used to be an accessory added to the dash of only the sportiest of cars, but now they’re pretty much standard equipment on everything from sleek coupes to the family truckster. If your daily driver was born without a tach, fear not – a simple Arduino tachometer is well within your reach.
The tach-less vehicle in question is [deepsyx]’s Opel Astra, which from the video below seems to have the pep and manual transmission that would make a tach especially useful. Eschewing the traditional analog meter display or even a digital readout, [deepsyx] opted to indicate shift points with four LEDs mounted to a scrap of old credit card. The first LED lights at 4000 RPM, with subsequent LEDs coming on at each 500 RPM increase beyond that. At 5800 RPM, all the LEDs blink as a redline warning. [Deepsyx] even provides a serial output of the smoothed RPM value, so logging of RPM data is a possible future enhancement.
The project is sensing engine speed using the coil trigger signal – a signal sent from the Engine Control Unit (ECU) which tells one of the ignition coilpacks to fire. The high voltage signal from the coilpack passes on to the spark plug, which ignites the air-fuel mixture in that cylinder. This is a good way to determine engine RPM without mechanical modifications to the car. Just make sure you modify the code for the correct number of cylinders in your vehicle.
Simple, cheap, effective – even if it is more of a shift point indicator than true tachometer, it gets the job done. But if you’re looking for a more traditional display and have a more recent vintage car, this sweeping LED tachometer might suit you more.
[ttsiodras] tells an epic tale of getting a custom Debian kernel installed on an Asus MemoPAD (ME103K) tablet. Skipping to the end of the saga, he discovers what looks like serial data coming out on the headphone jack when the system boots, but the signal was so distorted that he couldn’t simply interpret it. The solution turns out to be attaching a level-converter chip.
A level converter is a non-inverting amplifier, usually with a Schmitt trigger for immunity against noise. In this case, it acts like a “binarizer” — outputting a high voltage when the input rises above a threshold, and a low when it drops below. It’s the right part when you need to clean up a messy digital signal, and in this case works just fine because the capacitive distortion effects slow down both the leading and trailing edges of the signal, keeping the serial data’s timing intact.
That was the spoiler. If you want to read up on putting a custom Linux on an Android device, check out [ttsiodras]’s first post where he backs the machine up, and the second where he gets his custom kernel up and running. If you’re ever faced with an Android tablet that hasn’t been owned yet, or if you just have a DIY streak, this should help you get started.
Using the audio jack for serial is actually not uncommon, and discovering a serial terminal that listens at boot time is our favorite way to wedge a Linux OS into odd devices. So when you see a funny, distorted signal coming out at 115,200 baud, take a moment to clean its edges up and see what you’ve got.
Despite concerted efforts to kill them, serial ports are alive and well, especially in embedded system. True, most of them end in a USB port, these days, but there’s still a lot of gear with a DE-9 (it isn’t a DB-9, despite the common use of the word) or a TTL-serial port lurking around. [James Fowkes] got tired of managing a bunch of USB to serial adapters, so he decided to build his own FT4232 breakout board that would provide four serial ports from a USB connection.
The small board has transmit and receive LEDs for each port along with EMI and ESD protection on the USB port. The ports are all TTL serial, serving the modern hacker, and the 3.3V pins are 5V tolerant.
We love little tricks like this. Suppose that you want to generate an IR remote’s signal. It’s easy, because most of the codes are known. But it can be slightly harder because most IR remotes and receivers modulate the on pulses with a square wave at roughly 38 kHz for background lighting immunity.
With a competent PWM generator on a microcontroller, you can create this carrier modulation easily enough yourself. Set the PWM frequency to 38 kHz and the duty cycle somewhere in the 33%-50% range, and you’re set. But what if you don’t have a competent PWM generator? Such was the case that prompted [AnalysIR Blog] to fake it, with USART.
Here’s the trick. You set up the serial port to communicate at ten times the desired carrier frequency, and then transmit “special” data. (The number ten comes from eight bits of data plus a start and a stop bit.) If you want a 50% duty cycle, you simply send 0b11110000, as fast as the microcontroller will allow, for a mark and nothing for a space.
There’s some extra detail with inverting the signal if, as most do, your USART idles high. But that’s really it. It’s a cute trick for when you’re desperate enough to need it. And if you’d like to brush up some more on your asynchronous serial skills, check out our guide on troubleshooting USART, and the great comments that ensued.
It’s the easiest thing in the world — simple, straightforward serial data. It’s the fallback communication protocol for nearly every embedded system out there, and so it’s one that you really want to work when the chips are down. And yet! When you need it most, you may discover that even asynchronous serial can cost you a few hours of debugging time and add a few gray hairs to your scalp.
In this article, I’m going to cover most (all?) of the things that can go wrong with asynchronous serial protocols, and how to diagnose and debug this most useful of data transfer methods. The goal is to make you aware enough of what can go wrong that when it does, you’ll troubleshoot it systematically in a few minutes instead of wasting a few hours.