We all have projects from yesteryear that we wish had been documented better. [EjaadTech] is fighting back by creating a project page about a tachometer he built 3 years ago while in college. He’s done a great write-up documenting all the steps from bread-boarding to testing to finished project. All of the code necessary for this tachometer is available too, just in case you’d like to make one yourself.
At the heart of the project is an AVR ATMega8 chip that performs the calculations and controls the LCD output screen that displays both the immediate RPM as well as the average. To hold everything together, [EjaadTech] etched his own custom PCB board that we must say looks pretty good. In addition to holding all the necessary components, there is also an ISP connector for programming and re-programming.
There are two attachment options for sensing the RPM. One is a beam-break style where the IR emitter is on one side of the object and the receiver is on the other. This type of sensor would work well with something like a fan, where the blades would break the IR beam as they passed by. Then other attachment has the IR emitter and receiver on one board mounted next to each other. The emitter continually sends out a signal and the receiver counts how often it sees a reflection. This works for rotating objects such as shafts where there would not be a regular break in the IR beam. For this reflective-based setup to work there would have to be a small piece of reflective tape on the shaft providing a once-per-revolution reflection point. Notice the use of female headers to block any stray IR beams from causing an inaccurate reading… simple and effective.
A bootloader is typically used to update application code on a microcontroller. It receives the new program from a host, writes it to flash, verifies the program is valid, and resets the microcontroller. Perhaps the most ubiquitous example is the Arduino bootloader which allows you to load code without an AVR programmer.
The bootloader resides in a special part of memory, which is protected. On the AVR, it isn’t possible to write to the bootloader memory from the application code. This is to prevent you from accidentally breaking the bootloader and bricking the device.
However, it can be useful to write to the bootloader memory. The best example would be when you need to update the bootloader itself. To accomplish this, [Julz] found a workaround that defeats the AVR bootloader protection.
The challenge was to find a way to execute the Store Program Memory (spm) instruction, which can only be executed by the bootloader. [Julz] managed to make use of the spm instruction in the existing bootloader by counting cycles and modifying registers at the right time.
Using this technique, which [Julz] calls BootJacker, the Fignition 8 bit computer could have its bootloader updated. However, this technique would likely allow you to modify most bootloaders on AVR devices.
A while back, we had a sci-fi contest on Hackaday.io. Inspired by the replicators in Stargate SG-1, [The Big One] and a few other folk decided a remote-controlled hexapod would be a great build. The contest is long over, but that doesn’t mean development stopped. Now Stubby, the replicator-inspired hexapod is complete and he looks awesome.
The first two versions suffered from underpowered servos and complex mechanics. Third time’s the charm, and version three is a lightweight robot with pretty simple mechanics able to translate and rotate along the XYZ axes. Stubby only weights about 600 grams, batteries included, so he’s surprisingly nimble as well.
The frame of the hexapod is designed to be cut with a scroll saw, much to the chagrin of anyone without a CNC machine. There are three 9g servos per leg, all controlled with a custom board featuring an ATMega1284p and an XBee interface to an old Playstation controller.
Video of Stubby below, and of course all the sources and files are available on the project site.
Continue reading “Stubby, The Adorable And Easy To Build Hexapod”
[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.