Logic Simulator Atanua Goes Free, Possibly Open Source

The history of software is littered with developers that built a great product, gave people a reasonable option to license the software, and ended up making a pittance. There’s a reason you don’t see shareware these days – nobody pays. It looks like [Gates] had a point with his Open Letter to Hobbyists.

Such is the case with Atanua. [Jari] built a nice little graphical logic simulator that has tens of thousands of downloads, and is being used in dozens of universities. [Jari] has sold only about 60 licenses for Atanua, netting him only a few thousand Euro. You can’t develop software with a pittance, so now [Jari] is giving Atanua away. This neat little logic simulator has reached the end of its life, the license is free, and [Jari] is out of the business.

This isn’t an ideal situation, but [Jari] is strongly considering open-sourcing Atanua. The code is a little bit of a mess at the moment, and cleaning it up will require a bit of work. [Jari] is leaving the option to buy a license for Atanua open, and anyone who wants to see this bit of software open sourced could buy a license or hundred.

While this isn’t great news for [Jari], if you’re looking for a neat tool to learn digital logic, you now have a very nice free option. Atanua simulates individual logic gates, 74-series chips, and even an 8051 microcontroller in real-time (up to about 1 kHz), with enough buttons, LEDs, and displays to do some very cool stuff. It’s more than enough to learn digital logic on, and good enough for a test bed for some odd and bizarre projects you might have floating around your head.

USB On The Teensy 3 From The Ground Up

When implementing USB on a microcontroller, most people are going to reach for V-USB if they’re using an AVR, one of Microchip’s USB libraries if a PIC is involved, or any number of the USB libraries for various ARM processors. [Kevin] had a different idea. As a challenge to himself, he wrote a USB device driver for the Teensy 3.1 microcontroller board, getting as close to the bare metal as he could get.

Writing a USB device driver first required a literature review. There are a few peculiarities in the Freescale K20 family of microcontrollers – the one found in the Teensy 3.1 – that dictate the need for a specific memory layout, using several clocks, and handling all the USB descriptors. [Kevin] started with the clocks, every last one of which must be enabled. The clock is generated by the Multipurpose Clock Generator from a 16MHz crystal, PLL’ed to the frequencies the USB module needs, and sent out over the System Integration Module.

Following the flowcharts and sequences found in the Freescale reference guide told [Kevin] exactly what needed to be done with the startup sequence, and offered a few suggestions on what needed to be done to set up all the interrupts. [Kevin] spent an incredible amount of time documenting, programming, and smashing his head against the keyboard for this tutorial, but he does give everyone a great opportunity to learn from his struggles.

While [Kevin] has a mostly complete USB device driver, his work is far from done. That’s alright, because this project wasn’t meant to be a full-featured driver; it’s still missing real error handling, strings in the configuration, and a real VID/PID. That’s alright, it’s still a great exercise in building something from scratch, especially something that very few people have built successfully.

Oh, blatant Hackaday Store plug for the Teensy 3.1.

Making Embedded GUI’s Without Code

When the 4D Systems display first arrived in the mail, I assumed it would be like any other touch display – get the library and start coding/debugging and maybe get stuff painted on the screen before dinner. So I installed the IDE and driver, got everything talking and then…it happened. There, on my computer screen, were the words that simply could not exist –  “doesn’t require any coding at all”.

I took a step back, blinked and adjusted my glasses. The words were still there. I tapped the side of the monitor to make sure the words hadn’t somehow jumbled themselves together into such an impossible statement. But the words remained…   doesn’t.require.any.coding.at.all.

Continue reading “Making Embedded GUI’s Without Code”

MicroDMA and LEDs

[Jordan] has been playing around with WS2812b RGB LED strips with TI’s Tiva and Stellaris Launchpads. He’s been using the SPI lines to drive data to the LED strip, but this method means the processor is spending a lot of time grabbing data from a memory location and shuffling it out the SPI output register. It’s a great opportunity to learn about the μDMA available on these chips, and to write a library that uses DMA to control larger numbers of LEDs than a SPI peripheral could handle with a naive bit of code.

DMA is a powerful tool – instead of wasting processor cycles on moving bits back and forth between memory and a peripheral, the DMA controller does the same thing all by its lonesome, freeing up the CPU to do real work. TI’s Tiva C series and Stellaris LaunchPads have a μDMA controller with 32 channels, each of which has four unique hardware peripherals it can interact with or used for DMA transfer.

[Jordan] wrote a simple library that can be used to control a chain of WS2812b LEDs using the SPI peripheral. It’s much faster than transferring bits to the SPI peripheral with the CPU, and updating the frames for the LED strip are easier; new frames of a LED animation can be called from the main loop, or the DMA can just start again, without wasting precious CPU cycles updating some LEDs.

Better SPI Bus Design

Quick, how do you wire up an SPI bus between a microcontroller and a peripheral? SCK goes to SCK, MISO goes to MISO, and MOSI goes to MOSI, right? Yeah. You’ll need to throw in a chip select pin, but that’s pretty much it. Just wires, and it’ll most likely work. Now add a second device. The naïve solution found in thousands of Arduino tutorials do the same thing; just wires, and it’ll probably work. It’s not that simple, and Mr. Teensy himself, [Paul Stoffregen] is here to show you why.

When using multiple SPI devices, a pullup resistor on the chip select lines are a really great idea. Without a pullup, devices will work great when used alone, but will inexplicably fail when used together. It’s not magic; both devices are listening to the bus when only one should be. Putting a pullup on the CS lines keeps everything at the right logic level until a device is actually needed.

How about the MISO line? Most peripherals will disconnect their pins when the chip select signal is active, but there are exceptions. Good luck finding them. There is an easy way to check, though: just connect two resistors so the MISO line floats to a non-logic level when the CS pin is high, and check with a voltmeter. If MISO is driven high or low, you should put a small tri-state buffer in there.

That just covers hardware, and there are a few things you can do in software to reduce the number of conflicts when using more than one SPI device. One of these methods is transactions, or defining the clock rate, setting MSB or LSB first, and the polarity of the clock. Newer versions of the Arduino SPI library support transactions and the setup is very easy. In fact, transaction support in the Arduino library is something [Paul] worked on himself, and gets around the problem of having SPI-related code happening in both the main loop of a program and whenever an interrupt hits. Awesome work, and a boon to the Arduino makers around the world.

[Sprite_TM]’s Keyboard Plays Snake

Hackaday Prize judge, hacker extraordinaire, and generally awesome dude [Sprite_TM] spends a lot of time at his computer, and that means a lot of time typing on his keyboard. He recently picked up a board with the latest fad in the world of keyboards, a board with individually addressable LEDs. He took this board to work and a colleague jokingly said, ‘You’ve had this keyboard for 24 hours now, and it has a bunch of LEDs and some arrow keys. I’m disappointed you haven’t got Snake running on it yet.” Thus began the quest to put the one game found on all Nokia phones on a keyboard.

The keyboard in question is a Coolermaster Quickfire Rapid-I, a board that’s marketed as having an ARM Cortex CPU. Pulling apart the board, [Sprite] found a bunch of MX Browns, some LEDs, and a 72MHz ARM Cortex-M3 with 127k of Flash and 32k of RAM. That’s an incredible amount of processing power for a keyboard, and after finding the SWD port, [Sprite] attempted to dump the Flash. The security bit was set. There was another way, however.

Coolermaster is actively working on the firmware, killing bugs, adding lighting modes, and putting all these updates on their website. The firmware updater is distributed as an executable with US and EU versions; the EU version has another key. Figuring the only difference between these versions would be the firmware itself, [Sprite] got his hands on both versions, did a binary diff, and found only one 16k block of data at the end of the file was different. There’s the firmware. It was XOR encrypted, but that’s obvious if you know what to look for.

flashdata The firmware wasn’t complete, though; there were jumps to places outside the code [Sprite] had and a large block looked corrupted. There’s another thing you can do with an executable file: run it. With USBPcap running in the background while executing the firmware updater, [Sprite] could read exactly what was happening when the keyboard was updating. With a small executable that gets around the weirdness of the updater, [Sprite] had a backup copy of the keyboard’s firmware. Even if he bricked the keyboard, he could always bring it back to a stock state. It was time to program Snake.

The first part of writing new firmware was finding a place that had some Flash and RAM to store the new code. This wasn’t hard; there was 64k of Flash free and 28K of unused RAM. The calls to the Snake routine were modified from the variables the original firmware had. If, for example, the original keyboard had a call to change the PWM, [Sprite] could change that to the Snake routine.

Snake is fun, but with a huge, powerful ARM in a device that people will just plug into their keyboard, there’s a lot more you can do with a hacked keyboard. Keyloggers and a BadUSB are extremely possible, especially with firmware that can be updated from a computer. To counter that, [Sprite] added the requirement for a physical condition in order to enter Flash mode. Now, the firmware will only update for about 10 seconds after pressing the fn+f key combination.

There’s more to playing Snake on a keyboard; Sprite has also written a new lighting mode, a fluid simulation thingy that will surely annoy anyone who can’t touch type. You can see the videos of that below.

Continue reading “[Sprite_TM]’s Keyboard Plays Snake”

Multi-target IDE for 8-Bit CPUs

A long time ago, [Martin] played with old 8-bit computers. Recently, he’s been honing his assembly skills again, and the idea of an IDE for a boatload of old systems came to him. After a year of work, he announced a multitarget IDE for 8-bit computers that works in your browser.

The project is called ASM80, and includes a code editor, a workspace to put all your code, compilers for the 8080/8085, Z80, 6502, 6800 and 6809 CPUs, emulators for all these CPUs, and emulators for a few Czech computers, the ZX Spectrum, and a few of [Grant Searle]’s single board computers.

What makes this project interesting is the syntax for all the different CPUs is pretty much the same. It’s a real, modular code editor that supports macros and everything you would expect for a code editor for ancient computers.

You can check out an assembler description here. [Martin] also has an offline, desktop-based version of ASM80 called IDE80, with a video demo of that below.

Continue reading “Multi-target IDE for 8-Bit CPUs”