Storing User Data On Your FPGA

October 16, 2012 by Brian Benchoff 14 Comments

We’ve seen FPGAs used to recreate everything from classic arcade games to ancient computers, but with each of these builds a common problem arises. Once you’ve got the hardware emulated on an FPGA, you’ve also got to get the ROMs into the project as well. In a very interesting hack, [Mike] figured out that the serial Flash chip that stores the FPGA settings has a lot of space free, so why not store user data there?

[Mike] got the idea from seeing a recreation of the classic BombJack arcade game we featured last month. In that build, [Alex] needed to store 112Kb of game data stored in 16 ROM chips. Unfortunately, [Alex]’s FPGA only had space for 40Kb of data. After realizing his FPGA had a 512Kb SRAM chip, [Alex] decided to put all the sprites, sounds, and levels of BombJack in the SRAM.

Impressed with [Alex]’s build, [Mike] set to work generalizing the hack to work with other projects. [Mike] notes that only a few FPGA boards are capable of storing user data next to the configuration bitstream; the hack is impossible on the Digilent Basys2 board, but it works wonderfully on a Papilio One 250K.

As a very cool build that makes FPGA-related builds even easier, we’ve got to tip our hat to [Mike] for writing up a great tutorial.

Weird Processing Unit Only Has 4 Instructions

October 16, 2012 by Brian Benchoff 34 Comments

[Tomáš], a.k.a. [Frooxius] is playing around with computational theory and processor architectures – a strange hobby in itself, we know – and has created the strangest CPU we’ve ever seen described.

The Weird Processing Unit, or WPU, isn’t designed like the Intel or ARM CPU in your laptop or phone. No, the WPU is a thought experiment in computer design that’s something between being weird for the sake of being weird and throwing stuff at the wall and seeing what sticks.

The WPU only has four instructions, or attoinstructions, to change the state of one of the 64 pins on the computer – set to logical 1, set to logical 0, invert current state, and halt. These instructions are coded with two bits, and the operand (i.e. the wire connected to the computer) is encoded in another six bits.

These 64 wires are divided up into several busses – eight bit address and control busses make up the lowest 16 bits, a 32-bit data bus has a function akin to a register, and a 16-bit ‘Quick aJump bus’ provides the program counter and attocode memory. The highest bit on the WPU is a ‘jump bit’, implemented for unconditional jumps in code.

We’re not even sure the WPU can even be considered a computer. We realize, though, that’s probably not the point; [Tomáš] simply created the WPU to do something out of the ordinary. It’s not meant to be a real, or even useful, CPU; it’s simply a thought experiment to see what is possible by twiddling bits around.

Tip ‘o the hat to [Adam] for sending this one in.

Controlling A Robot With Your Mind

October 15, 2012 by Brian Benchoff 16 Comments

For [Ern]’s MEng group project, his group had to develop a robotics platform capable of achieving some end goal. Because innovation is a large part of the grade, [Ern] convinced his team members to work with a brain controlled interface and build a mind controlled robotics platform.

For wont of having an easy build, [Ern] and his team chose a Lynxmotion Tri-Track robot capable of moving around the classroom while receiving commands from a computer. The mind-control portion of the build comes from a NeuroSky MindWave Mobile, a cheap and fairly open EEG system that reads alpha, beta, and delta waves generated by a user’s brain and sends that data over to a computer for processing.

After a bit of testing that included an Arduino to move the robot forward if the MindWave’s ‘attention’ value was over 60%, [Ern] and his team looked for a way to implement multi-directional control.

In order to get the robot moving left, right, and backwards in addition to moving forwards, the team looked at the included ‘blink detection’ abilities of the MindWave to cycle through a few commands. This technique turned out to be far too sensitive – the blink detection of the MindWave is simply too good. To get around that problem, the team used the signal strength of the received EEG signals. The theory being when a user blinks their eyes, the EEG contacts will move slightly, degrading the signal received by the hardware.

The team finally got a reasonable mind-controlled robot up and working, as demonstrated in the video after the break. Check out how each blink allows [Ern] and his colleagues to cycle through driving modes. Pretty neat for controlling something with your mind.

Continue reading “Controlling A Robot With Your Mind” →

μJ, A Java Virtual Machine For Microcontrollers

October 15, 2012 by Brian Benchoff 78 Comments

[Dimitri] sent in a project he’s been working on that implements a Java Virtual Machine purely in C, and is easily portable between microcontrollers such as the AVRs and PICs we normally see, ARM devices, and even the lowly 386.

Before going into the ‘how’, [Dimitri] first covers why he wanted to run Java bytecode on a microcontroller. Basically, he found existing solutions like the Arduino environment too complex for people just wanting to program a chip. Arduino and PICAXE require C-like syntax and pointers; not the easiest thing when everyone and their mother can program in Java.

As for how [Dimitri] managed to pack a JVM into a microcontroller, that’s another story entirely. Everything in the JVM, from double, long, and float data types to exceptions, neat thread-related functions such as ‘synchronize’ and even methods such as String.charAt() and String.length() are completely optional. If your microcontroller is too small, just disable the functions you don’t need.

As for how well – and how fast – μJ is able to run, [Dimitri] threw up a demo of an ATMega644 and PIC24 running his JVM and a small Java app. You can check those videos out after the break, or just download the source for μJ on [Dimitri]’s site.

Continue reading “μJ, A Java Virtual Machine For Microcontrollers” →

Raspis With Double The RAM In The Wild

October 15, 2012 by Brian Benchoff 33 Comments

There is buzz all over the reddits and Element 14 discussion boards about an updated version of the Raspberry Pi that bumps the amount of RAM from 256 MB to 512 MB.

This new update comes after the announcement of an upgraded version of the yet-to-be-released Raspi Model A (from 128 MB of RAM to 256 MB), and a few slight modifications to the Model B that include fixing a few hardware bugs (nothing serious) and adding mounting holes.

After perusing the Element 14 and Raspberry Pi discussion boards, a few things become apparent. Firstly, it appears this new upgrade to double the amount of RAM was initiated by manufacturers. It seems 512 MB RAM chips are cheap enough now to include in the Raspi without impacting the cost of components. Secondly, 512 MB seems to be the upper limit for the Raspberry Pi, at least for this iteration of hardware. Not enough address lines, they say, but you’re welcome to try and hack your own RAM to a Raspi CPU.

So far, attentive Raspi enthusiasts have found Raspberry Pis with double the amount of RAM on the UK Farnell site and the Australian Element 14 site. Nothing so far on the US Element 14 site, although we’ll gladly update this post when a Hackaday reader finds the relevant link.

EDIT: Here’s the link for the US version of Newark. No, there aren’t any in stock. Also, Hackaday beat the official Farnell/Element 14/Newark press release and the Raspberry Pi blog to the punch. Woo, go us.

Our First Election Hack That Doesn’t Involve E-ballots

October 15, 2012 by Brian Benchoff 47 Comments

Because some of Hackaday’s readers aren’t from America, let us fill you in on the US election process from the point of view as a voter. Over the next few weeks, political campaigns will dump millions of dollars into advertising, get-out-the-vote and canvassing efforts across the country. The airwaves will broadcast still more ads and political analyses until November 6th, when voters will go to the polls and pull the lever for whoever earned their vote back in July.

Despite how effectively public opinion can be swayed, there are still a lot of problems with the election process in the United States. A first-past-the-post, winner take all system guarantees there will only ever be two realistic choices for voters, but a group of philosophy students (and teachers) may have a solution to this problem.

The idea is fairly simple, really: take dissatisfied members of one party and match them up with dissatisfied members of another party. Normally, these voters would be inclined to vote the party line and not their conscience, for fear of throwing their vote away. After matching these voters up, they make a gentleman’s agreement with each other (either with a handshake or by mailing in their ballots together) to not vote the party line. The balance of power between (D)s and (R)s remains, but third-party candidates get a much-needed shot in the arm.

It’s an interesting idea with far more potential to effect some change than the numerous e-voting hacks that will pop up after the election. Sure, it may not be as effective as other voting systems such as the Condorcet method, but save for elected officials abdicating powers granted to them, this might be the best shot we’ve got.

Have A Baby? Build Another One!

October 14, 2012 by Brian Benchoff 26 Comments

Ever since his daughter was born, [Markus] has been keeping logs full of observations of human behavior. Despite how it sounds, this sort of occurrence isn’t terribly odd; the field of developmental psychology is filled with research of this sort. It’s what [Markus] is doing with this data that makes his project unique. He’s attempting to use stochastic learning to model the behavior of his daughter and put her mind in a robot. Basically, [Markus] is building a robotic version of his newborn daughter.

The basics of stochastic learning (PDF with more info) is that a control system is modeled on an existing system – in this case, a baby – by telling a robot if it is doing a good or bad job. Think of it as classical conditioning for automatons that can only respond to a 1 or 0.

[Markus] built a robotic platform based on an Arduino Mega and a few ultrasonic distance sensors. By looking at its surrounding environment, the robot makes judgments as to what it should do next. In the video after the break, [Markus] shows off his robot finding its way around an obstacle course – really just a pair of couch cushions.

It’s a long way from crawling around on all fours, paying attention to shiny things, and making a complete mess of everything, but we’re loving [Markus]’ analytical approach to creating a rudimentary artificial intelligence.

Continue reading “Have A Baby? Build Another One!” →