[Joonas] became frustrated with cheap but crappy MIDI to USB converters, and the better commercial ones were beyond his budget. He used a Teensy LC to build one for himself and it did the job quite well. But he needed several converters, and using the Teensy LC was going to cost him a lot more than he was willing to spend. With some tinkering, he was able to build one using an Adafruit Pro Trinket which has onboard hardware UART (but no USB). This lack of USB support was a deal killer for him, so after hunting some more he settled on a clone of the Sparkfun Pro Micro. Based on the ATmega32U4, these clones were just right for his application, and the cheapest to boot. He reckons it cost him about $5 to build each of his cheap USB MIDI adapters which receive notes and pedal data from the keyboard’s MIDI OUT and transmit them to a computer
Besides the Pro Micro clone, the only other parts he used are a generic opto-coupler, a couple of resistors and a MIDI connector. After testing his simple circuit on a bread board, he managed to squeeze it all inside an old USB dongle housing, stuffing it in dead-bug style.
The heavy lifting is all done in the firmware, for which [Joonas] used LUFA — the Lightweight USB Framework for AVR’s. He wrote his own code to handle MIDI (UART) to USB MIDI messages conversion. The interesting part is his use of a 32.15 kbps baud rate even though the MIDI specification requires 31.25 kbps. He found that a slightly higher baud rate fixes a problem in the AVR USART implementation which tends to miss consecutive bytes due to the START edge not being detected. Besides this, his code is limited in functionality to only handle a few messages, mainly for playing a piano, and does not have full-fledged MIDI capabilities.
We’ve featured several of [Joonas]’s hacks here over the years, the most recent being the Beaglebone Pin-Toggling Torture Test and from earlier, How to Turn A PC On With a Knock And An ATTiny.
A few years ago, Microchip acquired Atmel for $3.56 Billion. There are plenty of manufacturers of 8-bit microcontrollers, but everyone makes 8051s, and the MSP430 isn’t as popular as it should be. Microchip’s acquisition of Atmel created what is probably the largest manufacturer of 8-bit micros, with a portfolio ranging from ATtinys smaller than a grain of rice to gigantic PICs.
This Friday, we’re hosting a Hack Chat with the Technical Marketing Engineer of 8-bitters at Microchip. If you love AVR, this is the guy to talk to. If you’re still rocking the vintage 1993 PICkit, this is the guy to talk to.
On the docket for this Hack Chat are some new PICs and some very interesting peripherals coming down the line. ADCC — A2D with computation — is on the table, along with configurable logic cells. This Hack Chat is also going to go over Microchip design tools like MP Lab Xpress.
Of course, these Hack Chats are a question and answer session for the community. We’re encouraging everyone to ask a few questions about what Microchip is doing. We’ve opened up a discussion guide for this Hack Chat. If you have a question, just add it to the list.
If you can’t make the Hack Chat, don’t worry. We’re going to have a transcript of the entire chat. That should be available here shortly after the chat concludes.
Here’s How To Take Part:
Our Hack Chats are live community events on the Hackaday.io Hack Chat group messaging. This hack chat will take place at noon Pacific time on Friday, June 9th. Here’s a fancy time and date converter if you need timezone help.
Log into Hackaday.io, visit that page, and look for the ‘Join this Project’ Button. Once you’re part of the project, the button will change to ‘Team Messaging’, which takes you directly to the Hack Chat.
You don’t have to wait until Friday; join whenever you want and you can see what the community is talking about
There is a high probability that the device on which you are reading this comes somehow loosely under the broad definition of a PC. The familiar x86 architecture with peripheral standards has trounced all its competitors over the years, to the extent that it is only in the mobile and tablet space of personal computing that it has not become dominant.
The modern PC with its multi-core processor and 64-bit instruction set is a world away from its 16-bit ancestor from the early 1980s. Those early PCs were computers in the manner of the day, in which there were relatively few peripherals, and the microprocessor bus was exposed almost directly rather than through the abstractions and gatekeepers we’d expect to see today. The 8088 processor with an 8-bit external bus though is the primordial PC processor, and within reason you will find software written for DOS on those earliest IBM machines will often still run on your multiprocessor behemoth over a DOS-like layer on your present-day operating system. This 35-year-plus chain of mostly unbroken compatibility is both a remarkable feat of engineering and a millstone round the necks of modern PC hardware and OS developers.
Those early PCs have captured the attention of [esot.eric], who has come up with the interesting project of interfacing an AVR microcontroller to the 8088 system bus of one of those early PCs. Thus all those PC peripherals could be made to run under the control of something a little more up-to-date. When you consider that the 8088 ran at a modest 300KIPS and that the AVR is capable of running at a by comparison blisteringly fast 22MIPS, the idea was that it should be able to emulate an 8088 at the same speed as an original, if not faster. His progress makes for a long and fascinating read, so far he has accessed the PC’s 640KB of RAM reliably, talked to an ISA-bus parallel port, and made a CGA card produce colours and characters. Interestingly the AVR has the potential for speed enhancements not possible with an 8088, for example it can use its own internal UART with many fewer instructions than it would use to access the PC UART, and its internal Flash memory can contain the PC BIOS and read it a huge amount faster than a real BIOS ROM could be on real PC hardware.
In case you were wondering what use an 8088 PC could be put to, take a look at this impressive demo. Don’t have one yourself? Build one.
Today, there are dozens of off-the-shelf solutions for a GPS tracking device. Most of them use GSM, some of them use satellites, and all of them are astonishingly inexpensive. If you want to track a car, dog, or your luggage, you’ve never had more options.
[Emilio] wanted to track his own car, and the original solution for this was a smartphone. This smartphone was also a good choice, as it’s a programmable GPS device connected to a cell network, but there had to be a simpler solution. It came in the form of an eight euro GPS module and a three euro GSM module (Google Translatrix right here). The rest of the hardware is an ATMega48V [Emilio] had sitting around and a 2500 mAh lithium cell. It’s a cellular tracker make out of eleven euro’s worth of hardware and some junk in a drawer.
There are only a few caveats to this hardware. First, the ATmega48V only has one UART. This is connected to the GPS module at 9600, 8N1. The connection to the GSM M-590 module is only 2400 bps, and slow enough for a bitbanged UART. This hardware is soldered to a piece of perfboard, thus ending the hardware part of this build.
The software is a little more complex, but not by very much. The GPS part of the firmware records the current latitude and longitude. If the GSM module receives a call, it replies with an SMS of the current GPS coordinates and a few GPS coordinates seen earlier. Of course, a pre-paid SIM is required for this build, but those are cheap enough.
Not even ten years ago, a simple, DIY GPS tracker would have cost a small fortune. Now that we have cheap GPS modules, GSM modules, and more magical electronics from the East, builds like this are easy and cheap. What a magical time to be alive.
I am a crappy software coder when it comes down to it. I didn’t pay attention when everything went object oriented and my roots were always assembly language and Real Time Operating Systems (RTOS) anyways.
So it only natural that I would reach for a true In-Circuit-Emulator (ICE) to finish of my little OBDII bus to speed pulse generator widget. ICE is a hardware device used to debug embedded systems. It communicates with the microcontroller on your board, allowing you to view what is going on by pausing execution and inspecting or changing values in the hardware registers. If you want to be great at embedded development you need to be great at using in-circuit emulation.
Not only do I get to watch my mistakes in near real time, I get to make a video about it.
Getting Data Out of a Vehicle
I’ve been working on a small board which will plug into my car and give direct access to speed reported on the Controller Area Network (CAN bus).
To back up a bit, my last video post was about my inane desire to make a small assembly that could plug into the OBDII port on my truck and create a series of pulses representing the speed of the vehicle for my GPS to function much more accurately. While there was a wire buried deep in the multiple bundles of wires connected to the vehicle’s Engine Control Module, I have decided for numerous reasons to create my own signal source.
At the heart of my project is the need to convert the OBDII port and the underlying CAN protocol to a simple variable representing the speed, and to then covert that value to a pulse stream where the frequency varied based on speed. The OBDII/CAN Protocol is handled by the STN1110 chip and converted to ASCII, and I am using an ATmega328 like found on a multitude of Arduino’ish boards for the ASCII to pulse conversion. I’m using hardware interrupts to control the signal output for rock-solid, jitter-free timing.
Walk through the process of using an In-Circuit Emulator in the video below, and join me after the break for a few more details on the process.
[Jan Ostman] has been pushing the limits of sound synthesis on the lowly AVR ATMega microcontrollers, and his latest two project is so cute that we just had to write it up. The miniTS shares the same basic sound-generation firmware with his previous TinyTS, which we’ve covered here before, but adds a lot more keys, an OLED, and MIDI, while taking away some of the knobs.
Both feature keyboards that are just copper pads placed over a ground plane, and the code does simple capacitive-sensing to figure out if they’re being touched or not. The point here is that you could pick up a PCB from [Jan] on the cheap, and experiment around with the code. Or you could just take the code and make a less refined version for yourself with a cheapo Arduino and some copper plates.
Either way, we like the combination of minimal materials and maximum tweakability, and think it’s cool that [Jan] shares the code, if not also the PCB designs. Anyone with PCB layout practice could get a clone worked up in an afternoon, although it’s going to be cheaper to get these made in bulk, and you’re probably better off just buying one from [Jan].
Linear voltage regulators are pretty easy to throw into a project if something in it needs a specific voltage that’s lower than the supply. If it needs a higher voltage, it’s almost just as easy to grab a boost converter of some sort to satisfy the power requirements. But if you’re on a mission to save some money for a large production run, or you just like the challenge of building something as simply as possible, there are ways of getting voltages greater than the supply voltage without using anything as non-minimalistic as a boost converter. [Josh] shows us exactly how this can be done using a circuit known as a charge pump to drive a blue LED.
One of the cool things about AVR microcontrollers is that they can run easily on a coin cell battery and source enough current to drive LEDs directly from the output pins. Obviously enough, if the LED voltage is greater than the voltage of the power supply, this won’t work. That is, unless you have a spare diode and capacitor around to build a charge pump.
The negative charge pump works by charging up a capacitor that is connected to an AVR pin, with the other side between the LED and a garden-variety diode to ground. That results in a roughly (VCC – 0.7) volt difference across the capacitor’s plates. When the AVR pin goes low, the other side of the capacitor goes negative by this same amount, and this makes the voltage across the LED high enough to light up. Not only is this simpler than a boost converter, but it doesn’t need any bulky inductors to work properly.
Will this work for any load? Am I going to start any fires by overdriving the LED? Luckily, [josh] answers all of these questions and more on the project page, and goes into some detail on the circuit theory as well. Granted, the charge pump doesn’t have the fine control over the power supply that you can get out of a buck or boost converter (or any switch-mode power supply). But it does have good bang-for-the-buck.