Peering Inside The GPU Black Box

March 30, 2016 by Elliot Williams 27 Comments

Researchers at Binghamton University have built their own graphics processor unit (GPU) that can be flashed into an FGPA. While “graphics” is in the name, this GPU design aims to provide a general-purpose computing peripheral, a GPGPU testbed. Of course, that doesn’t mean that you can’t play Quake (slowly) on it.

The Binghamton crew’s design is not only open, but easily modifiable. It’s a GPGPU where you not only know what’s going on inside the silicon, but also have open-source drivers and interfaces. As Prof. [Timothy Miller] says,

It was bad for the open-source community that GPU manufacturers had all decided to keep their chip specifications secret. That prevented open source developers from writing software that could utilize that hardware. With contributions from the ‘open hardware’ community, we can incorporate more creative ideas and produce an increasingly better tool.

That’s where you come in. [Jeff Bush], a member of the team, has a great blog with a detailed walk-through of a known GPU design. All of the Verilog and C++ code is up on [Jeff]’s GitHub, including documentation.

If you’re interested in the deep magic that goes on inside GPUs, here’s a great way to peek inside the black box.

Kestrel Computer Project

March 25, 2016 by Brandon Dunson 29 Comments

Many successful large-scale projects don’t start out large: they start with a small working core and grow out from there. Building a completely open-source personal computer is not a weekend project. This is as much a retelling of events as it is background information leading up to a request for help. You’ll discover that quite a lot of hard work has already been put forth towards the creation of a completely open personal computer.

When I noticed the Kestrel Computer Project had been submitted via the Hackaday tips line I quickly tracked down and contacted [Samuel] and asked a swarm of questions with the excitement of a giddy schoolgirl. Throughout our email conversation I discovered that [Samuel] had largely kept the project under the radar because he enjoyed working on it in his down time as a hobby. Now that the project is approaching the need for hardware design, I posed a question to [Samuel]: “Do you want me to write a short article summarizing years of your work on Kestrel Project?” But before he could reply to that question I followed it up with another: “Better yet [Samuel], how about we tell a more thorough history of the Kestrel Project and ask the Hackaday community for some help bringing the project home!?”
Continue reading “Kestrel Computer Project” →

EKG Business Card Warms Our Hearts

March 13, 2016 by Elliot Williams 32 Comments

Giving out a paper business card is so 1960s. Giving out a PCB business card, well that gets you up to the early 2010s. If you really want to stand out these days, give them a fully-functional EKG in a business card. (Note: works best if you’re leading an open-source electrocardiography project.)

Looking through the schematics (PDF), there’s not much to the card. At the center of everything is an ADuC7061, which is an ARM microprocessor equipped with 24-bit ADCs that also has an internal DAC-driven voltage reference connected to one of the user’s thumbs. This, plus a little buffering circuitry, seems to be enough to translate the tiny voltage potential difference across your two hands into a beautiful signal on the included OLED display. Very nice!

Everything (including the big version of their EKG) is open source and made on an open toolchain. If you’re interested in health and medical sensing, you should head over to the project’s GitHub and check it out. The standalone open EKG is based on a much more complicated circuit, and stands to be more accurate. But the business card version is just soooo cute!

Thanks [Ag Primatic] for the tip!

Microchip Publishes USB Mass Storage Loader

March 11, 2016 by Mike Szczys 36 Comments

Microchip just published their USB-MSD Programmer firmware. This open source project allows a board to enumerate as a USB Mass Storage device. Programming is as simple as copying a .hex file to the “drive”.

This code is what’s running on the $10 Xpress board that they released last month which includes a PIC18F25K50 to serve as a PICkit On Board (PKOB) programmer for the actual target micro; a PIC16F18855. In its stock version, the XPRESS-Loader firmware programs any PIC16F188xx chips that have a row size of 32 words. But it should be possible to tweak this package to program any chips that use the 8-bit LVP-ICSP protocol.

Now, this may seem like small potatoes at first look: it requires two microcontrollers on your board and is capable of programming just a small subset of the vast PIC inventory. But in our minds it’s the USB-MSD that is killer since it doesn’t require any software or drivers on the computer side of things. That’s a big invitation for all kinds of hacks. But there should be even more on the way from the Xpress team before too long.

It turns out the microcontroller [Voja Antonic] chose to use on the Hackaday | Belgrade badge is the 25k50. Since hearing about the Xpress board we’ve been talking to some of the PIC engineers and they are exploring a loader that will program onto the same chip. This means device upgrades without special hardware or drivers – perfect for badge hacking at a conference. This can be done with a precompiled hex, one created on MPLAB X, MPLAB Xpress, or others. We’ll keep you updated if we hear more on that part of the project.

Wiring Was Arduino Before Arduino

March 4, 2016 by Elliot Williams 149 Comments

Hernando Barragán is the grandfather of Arduino of whom you’ve never heard. And after years now of being basically silent on the issue of attribution, he’s decided to get some of his grudges off his chest and clear the air around Wiring and Arduino. It’s a long read, and at times a little bitter, but if you’ve been following the development of the Arduino vs Arduino debacle, it’s an important piece in the puzzle.

Wiring, in case you don’t know, is where digitalWrite() and company come from. Maybe even more importantly, Wiring basically incubated the idea of building a microcontroller-based hardware controller platform that was simple enough to program that it could be used by artists. Indeed, it was intended to be the physical counterpart to Processing, a visual programming language for art. We’ve always wondered about the relationship between Wiring and Arduino, and it’s good to hear the Wiring side of the story. (We actually interviewed Barragán earlier this year, and he asked that we hold off until he published his side of things on the web.)

The short version is that Arduino was basically a fork of the Wiring software, re-branded and running on a physical platform that borrowed a lot from the Wiring boards. Whether or not this is legal or even moral is not an issue — Wiring was developed fully open-source, both software and hardware, so it was Massimo Banzi’s to copy as much as anyone else’s. But given that Arduino started off as essentially a re-branded Wiring (with code ported to a trivially different microcontroller), you’d be forgiven for thinking that somewhat more acknowledgement than “derives from Wiring” was appropriate.

The story of Arduino, from Barragán’s perspective, is actually a classic tragedy: student comes up with a really big idea, and one of his professors takes credit for it and runs with it.

Continue reading “Wiring Was Arduino Before Arduino” →

Stallman’s One Mistake

January 13, 2016 by Brian Benchoff 147 Comments

We all owe [Richard Stallman] a large debt for his contributions to computing. With a career that began in MIT’s AI lab, [Stallman] was there for the creation of some of the most cutting edge technology of the time. He was there for some of the earliest Lisp machines, the birth of the Internet, and was a necessary contributor for Emacs, GCC, and was foundational in the creation of GPL, the license that made a toy OS from a Finnish CS student the most popular operating system on the planet. It’s not an exaggeration to say that without [Stallman], open source software wouldn’t exist.

Linux, Apache, PHP, Blender, Wikipedia and MySQL simply wouldn’t exist without open and permissive licenses, and we are all richer for [Stallman]’s insight that software should be free. Hardware, on the other hand, isn’t. Perhaps it was just a function of the time [Stallman] fomented his views, but until very recently open hardware has been a kludge of different licenses for different aspects of the design. Even in the most open devices, firmware uses GPLv3, hardware documentation uses the CERN license, and Creative Commons is sprinkled about various assets.

If [Stallman] made one mistake, it was his inability to anticipate everything would happen in hardware eventually. The first battle on this front was the Tivoization of hardware a decade ago, leading to the creation of GPLv3. Still, this license does not cover hardware, leading to an interesting thought experiment: what would it take to build a completely open source computer? Is it even possible?

Continue reading “Stallman’s One Mistake” →

32C3: A Free And Open Source Verilog-to-Bitstream Flow For ICE40 FPGAs

December 29, 2015 by Elliot Williams 10 Comments

[Clifford] presented a fully open-source toolchain for programming FPGAs. If you don’t think that this is an impressive piece of work, you don’t really understand FPGAs.

The toolchain, or “flow” as the FPGA kids like to call it, consists of three parts: Project IceStorm, a low-level tool that can build the bitstreams that flip individual bits inside the FPGA, Arachne-pnr, a place-and-route tool that turns a symbolic netlist into the physical stuff that IceStorm needs, and Yosys which synthesizes Verilog code into the netlists needed by Arachne. [Clifford] developed both IceStorm and Yosys, so he knows what he’s talking about.

What’s most impressive is that FPGAs aren’t the only target for this flow. Because it’s all open source and modifiable, it has also been used for designing custom ASICs, good to know when you’re in need of your own custom silicon. [Clifford]’s main focus in Yosys is on formal verification — making sure that the FPGA will behave as intended in the Verilog code. A fully open-source toolchain makes working on this task possible.

If you’ve been following along with [Al Williams]’s FPGA posts, either this introduction or his more recent intermediate series that are also based on the relatively cheap Lattice iCEStick development kit, this video is a must-watch. It’s a fantastic introduction to the cutting-edge in free FPGA tools.