Kickstarter and its ilk seem like the Wild West when it comes to claims of being “The world’s most (Insert feature here) device!” It does add something special when you can truly say you have the world record for a device though, and [MellBell Electronics] are currently running a Kickstarter claiming the worlds smallest Arduino compatible board called Pico.

We don’t want to knock them too much, they seem like a legit Kickstarter campaign who have at time of writing doubled their goal, but after watching their promo video, checking out their Kickstarter, and around a couple of minutes research, their claim of being the world’s smallest Arduino-compatible board seems to have been debunked. The Pico measures in at an impressive 0.6 in. x 0.6 in. with a total area of 0.36 sq.in. which is nothing to be sniffed at, but the Nanite 85 which we wrote up back in 2014 measures up at around 0.4 in. x  0.7in. with a total area of around 0.28 sq.in.. In this post-fact, fake news world we live in, does it really matter? Are we splitting hairs? Or are the Pico team a little fast and loose with facts and the truth?

There may be smaller Arduino compatible boards out there, and this is just a case study between these two. We think when it comes to making bold claims like “worlds smallest” or something similar perhaps performing a simple Google search just to be sure may be an idea.

In the mid-1970s, if you had your own computer, you probably built it. If you had a lot of money and considerable building skill, you could make an Altair 8800 for about $395 — better than the $650 to have it built. However, cheaper alternatives were not far behind.

In 1976, Popular Electronics published plans for a computer called the COSMAC Elf which you could build for under $100, and much less if you had a good junk box. The design was simple enough that you could build it on a piece of perf board or using wire wrap. We featured the online archive of the entire Popular Electronics collection, but hit up page 33 of this PDF if you want to jump right to the article that started it all. The COSMAC Elf is a great little machine built around a 40-pin RCA 1802 processor, and for many was the first computer they owned. I lost my original 1802 computer in a storm and my recent rebuild in another completely different kind of storm. But there is a way to reclaim those glory days without starting from scratch.  I’m going to repurpose another retro-computing recreation; the KIM-1.

I’ll admit it, Rewiring a real KIM-1 to take an 1802 CPU would be difficult and unnecessary and that’s not what this article is about. However, I did have a KIM UNO — [Oscar’s] respin of the classic computer using an Arduino mini pro. Looking at the keyboard, it occurred to me that the Arduino could just as easily simulate an 1802 as it could a 6502. Heck, that’s only two digits different, right?

The result is pretty pleasing. A “real” Elf had 8 toggle switches, but there were several variations that did have keypads, so it isn’t that far off. Most Elf computers had 256 bytes of memory (without an upgrade) but the 1802 UNO (as I’m calling it) has 1K. There’s also a host of other features, including a ROM and a monitor for loading and debugging programs that doesn’t require any space in the emulated 1802.

Repurpose

The KIM UNO has 24 switches. There are 16 for the hex digits, of course. The top two rows mimic functions from the original KIM-1. A real Elf had a way to input a byte (usually 8 toggle switches), a load switch, a run switch, a memory protect switch, and a push button wired to a CPU pin. That means the hardware has more than enough switches.

On the display side, a normal Elf had a single-byte hex display although some clones had more. There was also the Q LED that a program could light or extinguish. The KIM UNO hardware has many 7-segment displays so it is possible to put those digits to use like an Elf clone. There isn’t an LED, however, except for the Arduino’s built in LED which is not normally visible in operation. However, the digital displays have decimal points and they are connected to the Arduino. So if you don’t mind using those, you have plenty of LEDs, too.

The hardware is open source and easy to duplicate. [Oscar] sometimes has kits as well and they are very inexpensive (about $20).

The KIM UNO software is open source, so I started there. I first stripped all the code out of the main file other than the parts that drove the display and the keyboard, then built up everything need to suppot 1802 emulation. You can find all the code in my 1802UNO GitHub repository.

Inside the 1802

The 1802 instruction set is very regular and quite simple. Most instructions use the top 4 bits as an op code and the bottom 4 bits to select one of sixteen 16-bit registers. So 0x12 increments register 2 and 0x15 increments register 5. There are only a handful of op codes that don’t follow this pattern. There’s also an 8-bit accumulator called “D” (not to be confused with register D).

One unique feature in the 1802 architecture is the program counter. There isn’t one. Well, more precisely, there are up to 16. Any of the registers can be the program counter and a subroutine call can be as simple as switching the program counter. Unfortunately, that isn’t very reentrant (or good for recursion). If you want a proper subroutine call, you had to code it yourself. RCA provided the “standard call and return technique” that had the unfortunate downside of destroying the accumulator.

With so few instructions, the emulator turns out to be a few switch statements and some pretty simple code. Although it is made to run with the KIM UNO hardware, like the KIM UNO, you should be able to use it with just about any Arduino via the serial port. It isn’t quite as fun as having the real hardware, but it is simpler.

Unreal

The emulator is reasonably accurate except it doesn’t simulate interrupts (since there is no source of them). However, it doesn’t faithfully reproduce the 1802’s load mode which used DMA. Instead, load mode is just completely custom code that enters data into memory. It does not simulate the cycle and register manipulations that go on in a real 1802 using DMA in load mode.

In addition to loading a program with the ersatz load mode, you can also move RAM back and forth to EEPROM or a PC via the serial port.

Serial and Push Buttons

The serial port is just the usual Arduino serial port set for 9600 baud. By default, the serial input will mimic the hardware keys. However, you can use the pipe character (‘|’) to shift the serial port into terminal mode. Then the 1802 code can read data from the serial port. You lose the front panel functions and there’s no way to go back until you cycle the power unless you make the 1802 code release the port.

A few of the push buttons have special functions if you hold them down for more than one second. For example, the AD button writes the EEPROM data into RAM. This is useful for storing a self-contained demo, for example.

You can find a summary of the keyboard and serial commands on the GitHub site. The serial port can do things you can’t do from the front panel, like set a trace mode, dump the CPU registers, and more.

Building

The hardware doesn’t require any changes to the stock KIM UNO kit. There’s a lot to solder and once you solder the displays on, it would be hard to get the Arduino back off the board.

You could probably build the software using the Arduino IDE, but I used Platform IO. That lets me use the editor of my choice, but you ought to be able to get the code to work in the IDE, as well. There is enough memory to make the RAM slightly bigger, but I didn’t do it. Since one way to save and load the RAM is to EEPROM, I didn’t want the RAM to be larger than the EEPROM. In addition, the RAM “maps” like a real Elf (that is, RAM at location 0x0 also appears at 0x4000, 0x8000, etc). This would be more difficult if you added a little bit more than 1K of RAM.

There are a few other options at the top of 1802config.h. You can select how often the screen and keyboard refresh. Higher values are slower to refresh but faster to execute code. You can change the I/O ports associated with the keyboard, displays, and serial port. You can also change the serial escape character.

Examples

There are some examples provided that blink the LEDs and manipulate the serial port. If you look around, there’s a lot of 1802 code on the web. However, be aware that most 1802s don’t have a hardware UART. They emulate serial ports using the Q output and one of the EF inputs. That’s fine for a real device even though it takes lots of code, but for this virtual device, it isn’t practical. You’ll need to rip out any code that does serial I/O and replace it with single I/O instructions.

If you have a binary file (or a format you can convert to binary) I have a converter written in C included on GitHub. You can compile it on nearly any platform and use it to convert. It always assumes address. If that’s not right, you can always open the output in a text editor and adjust.

In addition, there are three ROMs included that you can try. By default, there is a simple high-low game. There are also two monitors, one for use with the built-in keyboard and another for use with a serial port. To select a ROM, edit 1802rom.h and change the comments so the ROM you want is not commented and the others are.

Practical?

Emulators are fun, but as the song goes, there’s nothing like the real thing. If that’s not authentic enough for you, it is possible to build a very authentic looking Elf, even today. The reason real 1802s are still around is they had several desirable characteristics, namely low power consumption and resistance to radiation.

The Arduino simulation has neither of those features. However, it is a fun retrocomputing toy, inexpensive, and a great learning tool. The CPU is simple enough to program directly in machine code and the portability is better than most other old school computers.

If you want to learn more about the 1802 there are several sites dedicated to it and a very helpful Yahoo group. One site has a very prolific software author, but most of the code won’t fit in the 1802 UNO’s 1K RAM. Maybe a version with more memory is in the future.

[MrRedBeard] wanted to play a particular song from an Arduino program and got tired of trying to hand transcribe the notes. A little research turned up that there was a project to convert Music XML (MXL) files to the Arduino. However, [MrRedBeard] wasn’t a fan of the language it used, so he created his own means of doing the same thing. He learned a lot along the way and was willing to share it in a tutorial that will help you if you want to do the same thing. You can see a video of his results, below.

Of course, MXL files are probably not better than sheet music if you had to create them by hand. Luckily, there’s a large collection of them available online and the song of interest was there. Note that the link in [MrRedBeard’s] post erroneously has the site as a .com instead of a .org, so you’ll want to use the link here instead of there.

A C# application reads the MXL file and converts it for use on the Arduino. There’s also sample code for the Arduino to get you started.

The project that inspired him is on GitHub and uses Ruby if that suits you better. We’ve talked about MXL before, by the way. If you want to integrate multi channel music on the Arduino, you might start here.

When you think of image processing, you probably don’t think of the Arduino. [Jan Gromes] did, though. Using a camera and an Arduino Mega, [Jan] was able to decode input from an Arduino-connected camera into raw image data. We aren’t sure about [Jan’s] use case, but we can think of lots of reasons you might want to know what is hiding inside a compressed JPEG from the camera.

The Mega is key, because–as you might expect–you need plenty of memory to deal with photos. There is also an SD card for auxiliary storage. The camera code is straightforward and saves the image to the SD card. The interesting part is the decoding.

The use case mentioned in the post is sending image data across a potentially lossy communication channel. Because JPEG is compressed in a lossy way, losing some part of a JPEG will likely render it useless. But sending raw image data means that lost or wrong data will just cause visual artifacts (think snow on an old TV screen) and your brain is pretty good at interpreting lossy images like that.

Just to test that theory, we took one of [Joe Kim’s] illustrations, saved it as a JPEG and corrupted just a few bytes in a single spot in it. You can see the before (left) and after (right) picture below. You can make it out, but the effect of just a few bytes in one spot is far-reaching, as you can see.

The code uses a library that returns 16-bit RGB images. The library was meant for displaying images on a screen, but then again it doesn’t really know what you are doing with the results. It isn’t hard to imagine using the data to detect a specific color, find edges in the image, detect motion, and other simple tasks.

Sending the uncompressed image data might be good for error resilience, but it isn’t good for impatient people. At 115,200 baud, [Jan] says it takes about a minute to move a raw picture from the Arduino to a PC.

We’ve seen the Arduino handle a single pixel at a time. Even in color. The Arduino might not be your first choice for an image processing platform, but clearly, you can do some things with it.

If you’ve done 3D printing, you’ve probably at least heard of Tinkercad. This popular CAD package runs in your browser and was rescued from oblivion by Autodesk a few years ago. [Chuck] recently did a video about a new Tinkercad feature: building and simulating virtual Arduino circuits. You can watch it below.

There are a variety of components you can add to your design. You’ll find an integrated code editor and a debugger. You can even get to the serial monitor, all in your browser with no actual Arduino hardware. You can also build simple circuits that don’t use an Arduino, although the component selection is somewhat limited.

This could be great for teaching Arduino in classrooms or when you want to do some development in a hotel room. The layout is very visual, so if you are accustomed to reading schematics, you may not appreciate the style. In addition, the selection of components is somewhat limited (including only supporting the Arduino UNO, as far as we could tell). So for educational purposes, it is great. For breadboarding your next great Arduino-powered robot, maybe not so much.

If you remember Circuits123 (or circuits.io), this is the same underlying technology. They’ve just integrated it with Tinkercad. However, there doesn’t seem to be any real integration between the two other than they are on the same web page now. Perhaps in the future, they’ll let you drop components on the circuit that also show up in the 3D design (or, at least, with sockets or holders for those components).

However, having a simulated Arduino with a debugger could come in handy even if you don’t care about the circuit simulations. If you really want to do circuit simulation, it is hard to go wrong with LTSpice. If you really want it to be in your browser, there’s always Falstad.

If you are working with OBD2 hardware or software, it’s easy enough to access test data, simply plug into a motor vehicle with an OBD2 socket. If, however, you wish to test OBD2 software under all possible fault conditions likely to be experienced by an engine, you are faced with a problem in that it becomes difficult to simulate all faults on a running engine without breaking it. This led [Fixkick] to create an OBD2 simulator using a secondhand Ford ECU supplied with fake sensor data from an Arduino to persuade it that a real engine was connected.

The write-up is quite a dense block of text to wade through, but if you are new to the world of ECU hacking it offers up some interesting nuggets of information. In it there is described how the crankshaft and camshaft sensors were simulated, as well as the mass airflow sensor, throttle position, and speedometer sensors. Some ECU inputs require a zero-crossing signal, something achieved with the use of small isolating transformers. The result is a boxed up unit containing ECU and Arduino, with potentiometers on its front panel to vary the respective sensor inputs.

We’ve brought you quite a few OBD2 projects over the years, for example, there was this LED tachometer, and a way into GM’s OnStar.

Thanks [darkspr1te] for the tip.

An ISP dongle is a very common piece of equipment on a maker’s bench. However, its potential as a hackable device is generally overlooked. The USBASP has an ATmeg8L at its heart and [Robson] decided that this humble USB device could be used as an interface between his PC and a SNES Joypad.

A SNES controller required three pins to communicate with a host: clock, data and latch. In his hack, [Robson]  connects the controller to the ISP interface using a small DIY adaptor and programs the AVR using the V-USB library. V-USB is a software USB library for small microcontrollers and comes in pretty handy in this instance.

[Robson] does a pretty good job of documenting the entire process of creating the interface which includes the USB HID code as well as the SNES joypad serial protocol. His hack works on both Windows and Linux alike and the code is available on GitHub for download.

Simple implementation like this project are a great starting point for anyone looking to dip their toes in the DIY USB device pool. Veterans may find a complete DIY joystick more up their alley and will be inspired by some plastic techniques as well.

If you were sad that Codebender had bit the dust, cheer up. A site called codeanywhere has acquired the online Arduino development environment and brought it back to life. In addition to the main Codebender site, the edu and blocks sites are also back on the air.

Not only is this great news, but it also makes sense. The codeanywhere site is a development IDE in the cloud for many different programming languages. The downside? Well, all the people who said they’d be glad to pay to keep Codebender alive will get a chance to put their money where their mouth is.

Here’s an excerpt from Codebender’s blog:

First of all, codebender will mostly remain the same. It will continue to operate as a standalone service, so you don’t have to change the way you are currently using codebender. However, it will transition to a monthly subscription service. This means that you will be able to use it for free for 1 month (as a trial, beginning on June 1st, or for the first month after registration), and it will then cost $10/month to keep using it. This is the price to pay for keeping codebender alive and sustainable, and it’s a small one, really.

Secondly, Codeanywhere intends to keep adding more and more features, the same way we have been adding features, libraries, and board support in the past few years. So you can expect codebender to keep improving with time, much as it did until now.

We have to wonder how many people will pay $120 / year to do something they can do for free. Mbed has support from ARM and offers a free IDE. Maybe a better deal with Codebender would have been with Atmel or Arduino. Not that we are opposed to charging for services, but we imagine a lot of people will just use free tools unless they have a strong use case for using a cloud-based service.

We covered Codebender’s short-lived demise back in October of last year.

[Ryan Bates] apparently really likes building claw machines. We noticed his latest build with a new PCB, but then we scrolled down and found other incarnations of the machine going back to 2015.

The laser-cut claw is interesting looking and the brains are an Arduino. You can see the action in the video below and there are plenty of older videos on the project page.

Without the PCB, the machine was a mess of wires. With the PCB, a single ribbon cable connects the Arduino to the board, and the board has a layout of screw terminals. This results in a much cleaner layout than before.

You might think you wouldn’t see many homemade claw machines. However, that’s not true. We’ve seen plenty, some of them even using commercial claws. Naturally, some of them also connect to the Internet.

USB chargers are everywhere and it is the responsibility of every hacker to use this commonly available device to its peak potential. [Septillion] and [Hugatry] have come up with a hack to manipulate a USB charger into becoming a variable voltage source. Their project QC2Control works with chargers that employ Quick Charge 2.0 technology which includes wall warts as well as power banks.

Qualcomm’s Quick Charge is designed to deliver up to 24 watts over a micro USB connector so as to reduce the charging time of compatible devices. It requires both the charger as well as the end device to have compatible power management chips so that they may negotiate voltage limiting cycles.

In their project, [Septillion] and [Hugatry] use a 3.3 V Arduino Pro Mini to talk to the charger in question through a small circuit consisting of a few resistors and diodes. The QC2.0 device outputs voltages of 5 V, 9 V and 12 V when it sees predefined voltage levels transmitted over the D+ and D- lines, set by Arduino and voltage dividers. The code provides function calls to simplify the control of the power supply. The video below shows the hack in action.

Quick Charge has been around for a while and you can dig into the details of the inner workings as well as the design of a compatible power supply from reference designs for the TPS61088 (PDF). The patent (PDF) for the Quick Charge technology has a lot more detail for the curious.

Similar techniques have been used in the past and will prove useful for someone looking for a configurable power supply on the move. This is one for the MacGyver fans.