assembly

105 Articles

SPI: Let Go And Use The Force

January 2, 2016 by 23 Comments

Take a leap the next time you use SPI and don’t poll for the busy flag. “What, are you crazy? That’s the whole point of the busy flag! It’s a quick check to make sure you don’t kill a byte waiting to be shifted out!” Sure, we thought the same thing, but the other side of the coin is that it takes time to check the busy flag, and that’s time he could be transmitting data. [bigjosh2] calculates that his technique saves 20% of those wasted cycles in this particular case. And he’s “using the force” only because he’s a Jedi master able to rely on the cycle count of a chunk of assembly code.

He’s working with an AVR processor, and pumping out bits to drive the vintage LED display pictured above. The ancient chips don’t have buffered SPI so he has to blank the display while shifting new data in to prevent it from glitching. Because the display blank during the SPI transmission, the slower it goes, the dimmer the lights.

He attacks the problem with synchronous code. It takes 2 cycles for the hardware SPI to send each bit, so he twiddles his thumbs (that’s exactly what he wrote in his code comments) for 16 cycles before reloading the SPI register with his next value. This leaves it up to faith in the silicon that the shifting will always take the same number of cycles, but the nice thing about hardware is that it’s deterministic. He ends up killing a few cycles in order to save time by not polling the busy flag.

Still need a crash course in what SPI actually does? [Bil Herd] has you covered with this SPI communication demo.

Nick Sayer: Making 10ⁿ Isn’t The Same As Building One

December 24, 2015 by 27 Comments

Building one of something is tremendously easy. If you’re making one of something, you can cover the insides with hot glue, keep everything held together with duct tape, and mess around with it enough that it mostly works most of the time. Building more than one of something is another matter entirely. This is the thought behind DFM, or Design For Manufacturing. [Nick Sayer] is an experienced seller on Tindie and he’s put together enough kits to learn the ins and outs, rights and wrongs of building not one, but an inventory of things. Check out this last talk of the 2015 Hackaday SuperConference, then join us below for a bit more on the subject.

Continue reading “Nick Sayer: Making 10ⁿ Isn’t The Same As Building One” →

ATtiny Does 170×240 VGA With 8 Colors

December 17, 2015 by 96 Comments

The Arduino is a popular microcontroller platform for getting stuff done quickly: it’s widely available, there’s a wealth of online resources, and it’s a ready-to-use prototyping platform. On the opposite end of the spectrum, if you want to enjoy programming every bit of the microcontroller’s flash ROM, you can start with an arbitrarily tight resource constraint and see how far you can push it. [lucas][Radical Brad]’s demo that can output VGA and stereo audio on an eight-pin DIP microcontroller is a little bit more amazing than just blinking an LED.

[lucas][RB] is using an ATtiny85, the larger of the ATtiny series of microcontrollers. After connecting the required clock signal to the microcontroller to get the 25.175 Mhz signal required by VGA, he was left with only four pins to handle the four-colors and stereo audio. This is accomplished essentially by sending audio out at a time when the VGA monitor wouldn’t be expecting a signal (and [lucas][Rad Brad] does a great job explaining this process on his project page). He programmed the video core in assembly which helps to optimize the program, and only used passive components aside from the clock and the microcontroller.

Be sure to check out the video after the break to see how a processor with only 512 bytes of RAM can output an image that would require over 40 KB. It’s a true testament to how far you can push these processors if you’re determined. We’ve also seen these chips do over-the-air NTSC, bluetooth, and even Ethernet.

Continue reading “ATtiny Does 170×240 VGA With 8 Colors” →

Industrial Automation In Action: Steam Controller Assembly

December 12, 2015 by 63 Comments

Right up front, we’ll cop to the inevitable “not a hack” comments on this one. This video of the Steam Controller assembly plant is just two minutes of pure robotics porn, plain and simple.

From injection molding of the case parts through assembly, testing and final palletizing of packaged controllers for the trip to distributors, Valve’s video is amazingly detailed and very well made. We’d wager that the crane shots and the shots following product down conveyors were done with a drone. A grin was had with the Aperture Labs logo on the SCARA arms in the assembly and testing work cell, and that inexplicable puff of “steam” from the ceiling behind the pallet in the final shot was a nice touch too. We also enjoyed the all-too-brief time-lapse segment at around 00:16 that shows the empty space in Buffalo Grove, Illinois being fitted out.

This may seem like a frivolous video, but think about it: if you’re a hardware hacker, isn’t this where you want to see your idea end up? Think of it as inspiration to get your widget into production. You’ll want to get there in stages, of course, so make sure you check out [Zach Fredin]’s 2015 Hackaday Superconference talk on pilot-scale production.

Continue reading “Industrial Automation In Action: Steam Controller Assembly” →

A Modern 386 Development Board

November 17, 2015 by 49 Comments

Some readers out there probably have nostalgic feelings for their first 386 based PC, the beeps and hisses of the modem, and the classic sound of a floppy drive’s stepper motor. Perhaps that turbo button that we could never quite figure out.

If you want the power of a 386 processor today, you’re in luck: [Pierre Surply] has developed a modern development board for the 80386SX CPU. This board is based on a 386 processor that comes in a LQFP package for “easy” soldering, and an Altera Cyclone IV FPGA.

To allow the CPU to run, the FPGA emulates the chipset you would usually find on a PC motherboard. The FPGA acts as both a bus controller and a memory controller for the CPU. On the board, there’s an SRAM chip and internal memory on the FPGA, which can be accessed through the 386’s bus access protocol.

The FPGA also provides debugging features. A supervisor application running on the FPGA gives debugging functionality via a FTDI USB to UART chip. This lets you control operation of the CPU from a PC for debugging purposes. The FPGA’s memory can be programmed through a JTAG interface.

The project is very well documented, and is a great read if you’re wondering how your old 386 actually worked. It can even be hand soldered, so the adventurous can grab the design files and give it a go. The francophones reading can also watch the talk in the video below.

Continue reading “A Modern 386 Development Board” →

Hacking A Universal Assembler

August 6, 2015 by 30 Comments

I have always laughed at people who keep multitools–those modern Swiss army knives–in their toolbox. To me, the whole premise of a multitool is that they keep me from going to the toolbox. If I’ve got time to go to the garage, I’m going to get the right tool for the job.

Not that I don’t like a good multitool. They are expedient and great to get a job done. That’s kind of the way I feel about axasm — a universal assembler I’ve been hacking together. To call it a cross assembler hack doesn’t do it justice. It is a huge and ugly hack, but it does get the job done. If I needed something serious, I’d go to the tool box and get a real assembler, but sometimes you just want to use what’s in your pocket.

Continue reading “Hacking A Universal Assembler” →

Doom on Raspberry Pi

Writing Doom For The Raspberry Pi

July 6, 2015 by 35 Comments

We’ve all seen Doom played on the Raspberry Pi before… but this isn’t a port of the game. No, this was a school project at the Imperial College of London — writing the game in bare assembly. They wrote it from scratch.

bare metal doom thumbnail
Complete with a custom home made controller connected directly to the GPIO pins!

Yep. There’s not even an operating system on the Pi. It’s 9800 lines of bare metal ARM assembly. If that doesn’t hurt your brain we dunno what does!

They are using the official textures from the game, and it’s not quite a perfect replica — but it’s pretty darn close.

Part of the project was to build an emulator to make it easier to test the game, but it didn’t work out the greatest — so most of the actual game development was performed on the actual hardware. Yikes!

Stick around after the break to see Doom in all its former glory. Top notch work guys!

Continue reading “Writing Doom For The Raspberry Pi” →