[CNLohr] is no stranger to running Minecraft on some weird hardware. Earlier, he built this Linux powered microscope slide… thing to toggle LEDs with redstone levers in Minecraft. Figuring if Minecraft could run on an AVR, he decided to try the same thing on a router, a TP-LINK TL-WR841N to be specific. Like the microscope slide running Linux, this proved to be an easy task. [CNLohr] had another router he could run Minecraft on, and this one could also punch wood. There really was only one thing for him to do.
Like the microscope slide and the wireless router, [CNLohr]’s CNC router is now running a Minecraft server. The phrase, “because it’s there” comes to mind. When connected to the CNC server, the player controls a snow golem (a snowman with a jack ‘o lantern head) with a carrot. Wherever the snow golem goes, the tool head follows, allowing him to carve objects in the world, and on a sheet of MDF secured in the CNC machine.
It’s certainly an odd build, but [CNLohr] was able to carve out a pixeley, blocky Hackaday logo with the snow golem controlled CNC machine. Code here, video below.
Continue reading “Running Minecraft On Two Routers”
[Thomas] tipped us about his latest project: a stand-alone AVR programmer module named ISPnub. As you can see in the picture above, it is a simple circuit board composed of a main microcontroller (ATmega1284p), one button and two LEDs. Programming a target is a simple as connecting the ISPnub and pressing the button. The flashing operation success status is then shown using the green/red LED.
ISPnub gets its power from the target circuit so no external power supply is needed. It works over a wide voltage range: 1.8V to 5.5V. The module also features a programming counter which can be used to limit the number of programming cycles. A multi-platform Java tool is in charge of embedding the target flash contents with the ISPnub main firmware. The complete project is open source so you may want to check out the official GitHub repository for the firmware and the project’s page for the schematics.
[Necromant] wrote a library to flash his microcontroller over an RF link using an NRF24L01 wireless communication module. The NRF24L01 is a cheap RF module that can be easily integrated into many microcontroller projects. Though there are Arduino libraries for driving the NRF24L01, [Necromat] decided to make a port of one with no Arduino dependencies.
The resulting bootloader fits into 4K of
RAM flash with packet loss and recovery along with user-configurable hardware or software SPI. Programming speeds are not the highest, but [ NecromatNecromant] believes this to be a property of the VUSB rather than the transfer rate from the NRF24L01 or the target microcontroller.
To program the target AVR chip, [
NecromatNecromant] used another NRF24L01 module connected to his uISP dongle over USB. Using a custom tool to interface with the uISP, the target board can be programmed in a similar fashion as avrdude. Check out the code for the ISP dongle and the AVR bootloader on his GitHub page.
[Josh] had a little project where he needed to keep a variable in RAM while a microcontroller was disconnected from a power source. Yes, the EEPROM on board would be able to store a variable without power, but that means writing to the EEPROM a lot, killing the lifetime of the chip. He found an ATTiny can keep the RAM alive for a variable amount of time – somewhere between 150ms and 10 minutes. Wanting to understand this variability, he decided to solve the mystery of the zombie RAM.
The first experiment involved writing a little bit of code for an ATTiny4313 that looked for a value in RAM on power up and light up a LED if it saw the right value. The test circuit consisted of a simple switch connected to the power pin. Initial tests were astonishing; the ATTiny could hold a value in RAM for up to 10 minutes without power.
With the experiment a success, [Josh] updated his project to use this new EEPROM-saving technique. Only this time, it didn’t work. The value hidden away in RAM would die in a matter of milliseconds, not minutes. After tearing his hair out looking for something different, [Josh] rigged up an Arduino based test circuit with humidity and temperature sensors to see if that had any effect. It didn’t, and the zombie RAM was still not-undead.
The key insight into how the RAM in an ATtiny could stay alive for so long came when [Josh] noticed his test circuit had a LED, but the actual project didn’t. Apparently this LED was functioning as a very tiny solar cell, generating a tiny bit of current that kept the RAM alive. A dark room with a flashlight confirmed this hypothesis, and once [Josh] gets his uCurrent from Kickstarter he’ll know exactly how much current this LED is supplying.
[Tim’s] new version of Micronucleus, Micronucleus 2.0, improves upon V-USB by removing the need for interrupts. The original Micronucleus was a very small implementation of V-USB that took up only 2KB. Removing the need for interrupts is a big leap forward for V-USB.
For those of you that do not know, “V-USB is a software-only implementation of a low-speed USB device for Atmel’s AVR® microcontrollers, making it possible to build USB hardware with almost any AVR® microcontroller, not requiring any additional chip.” One tricky aspect of using V-USB is that the bootloader requires interrupts, which can lead to messy problems within the user program. By removing the need for interrupts, Micronucleus 2.0 reduces the complexity of the bootloader by removing the need to patch the interrupt vector for the user program.
With the added benefit of speeding up the V-USB data transmission, Micronucleus 2.0 is very exciting for those minimal embedded platforms based on V-USB. Go ahead and try out Micronucleus 2.0! Leave a comment and let us know what you think.
[Aditya] had a project that called for spoken output. He admits that he could have built a PC-based solution, but he found that adding speech by using a microcontroller was not only a cheap and portable alternative, it was also a fun and easy build.
His design uses an ATMega128. Many microcontrollers would work, but his major requirements were PWM generation and plenty of memory to store the file(s). The output is cleaned up in a simple low pass filter before going to the 8Ω speaker.
[Aditya] lays his tracks in WAV format and then compresses it to 8-bit/8kHz. He found a C++ function that converts the track data into a huge arrays and then digitizes it. He uses two timers, one to generate the waveform and second one to time the square wave. [Aditya] has a zip of samples available on his site that will speak the digits 0-9.
[Karl] was in need of a hardware random number generator, but is needs had a few caveats: it needed to be cheap, and sufficiently random. Random number generation can get quite crazy with Geiger tubes, lava lamps, and radioactive decay, but a much smaller solution was found in an 8 pin AVR microcontroller.
The solution uses AVRentropy, a library that uses the watchdog timer’s jitter in AVR microcontrollers to provide cryptographically secure random numbers. Setting up the circuit was easy – an ATtiny45 microcontroller was connected to a cheap chinese USB to serial converter. Three wires, and the circuit is complete. The code was simple as well; it’s just a call to initialize the entropy and write the bits to the serial port.
There are a few drawbacks to this build. Because the entropy library must wait until enough entropy is gathered, it can only produce about two 32-bit numbers per second. That’s all [Karl] needed for his application, though, and with an enclosure made from a wine cork and marble, he has the prettiest and smallest random number generator around.