Looking for a new clock but hate the fact that all the numbers are always in the correct order? Look no further than [Andy]’s topsy turvy clock which correctly tells time despite the fact that the numbers on the face of the clock are in random positions.
At first glance, the clock looks fairly normal despite the mixed-up numerals. Upon closer inspection, the clock is much more than it appears to be. A battery backed real-time clock keeps track of time, and a microcontroller turns the hands of the clock to where they need to be. The clock uses optical sensors to make sure the hands are in the correct starting position when it is first powered on.
Check out the video below for a better illustration of what the clock looks like when in operation. The hour hand is always pointing at the correct hour, and the minute hand starts every five minutes at the number it would have started at on a normal clock, i.e. at 1:15 the hour hand will point at “one” and the minute hand will point at “three”.
We love this very interesting and unique take. It was inspired by a few other clocks, including a version of the infamous Vetinari “random tick” clock which will drive you crazy in a different way.
If you listen to [Bil Herd] and the rest of the Commodore crew, you’ll quickly realize the folks behind Commodore were about 20 years ahead of their time, with their own chip foundries and vertical integration that would make the modern-day Apple jealous. One of the cool chips that came out of the MOS foundry was the 6500/1 – used in the keyboard controller of the Amiga and the 1520 printer/plotter. Basically a microcontroller with a 6502 core, the 6500/1 has seen a lot of talk when it comes to dumping the contents of the ROM, and thus all the code on the Amiga’s keyboard controller and the font for the 1520 plotter – there were ideas on how to get the contents of the ROM, but no one tried building a circuit.
[Jim Brain] looked over the discussions and recently gave it a try. He was completely successful, dumping the ROM of a 6500/1, and allowing for the preservation and analysis of the 1520 plotter, analysis of other devices controlled by a 6500/1, and the possibility of the creation of a drop-in replacement for the unobtanium 6500/1.
The datasheet for the 6500/1 has a few lines describing the test mode, where applying +10 VDC to the /RES line forces the machine to make memory fetches from the external pins. The only problem was, no body knew how to make this work. Ideas were thrown around, but it wasn’t until [Jim Brain] pulled an ATMega32 off the top of his parts bin did anyone create a working circuit.
The code for the AVR puts the 6500/1 into it’s test mode, loads a single memory location from ROM, stores the data in PORTA, where the AVR reads it and prints it out over a serial connection to a computer. Repeat for every location in the 6500/1 ROM, and you have a firmware dump. This is probably the first time this code has been seen in 20 years.
Now the race is on to create a drop-in replacement of what is basically a 6502-based microcontroller. That probably won’t be used for much outside of the classic and retro scene, but at least it would be a fun device to play around with.
As [Shahriar] points out in the introductory matter to his latest video at The Signal Path, Arduinos are a great way for a beginner to dig into all kinds of electronic excitement, but they do so at the cost of isolating that beginner from the nitty gritty of microcontrollers. Here, [Shahriar] gives a very thorough walkthrough of a 60-neopixel ring starting with the guts and glory of a single RGB LED. He then shows how that ring can easily be programmed using a PIC and some C.
[Shahriar]’s eval board is a simple setup that he’s used for other projects. It’s based on the PIC18F4550 which he’s programming with an ICD-U64. The PIC is powered through USB, but he’s using a separate switching supply to power the ring itself since he would need ~60mA per RGB to make them burn white at full brightness.
He’s written a simple header file that pulls in the 18F4550 library, sets the fuses, and defines some constants specific to the ring size. As he explains in the video, the PIC can create a 48MHz internal clock from a 20Mhz crystal and he sets up this delay in the header as well. The main code deals with waveform generation, and [Shahriar] does a great job explaining how this is handled with a single pin. Before he lights up the ring, he puts his scope on the assigned GPIO pin to show that although the datasheet is wrong about the un-delayed width of the low period for a zero bit, it still works to program the LEDs.
[Shahriar] has the code available on his site. He is also holding a giveaway open to US residents: simply comment on his blog post or on the video at YouTube and you could win either a TPI Scope Plus 440 with probes and a manual or a Tektronix TDS2232 with GPIB. He’ll even pay the shipping.
Continue reading “PIC Up a NeoPixel Ring and C What You Can Do Using This Tutorial”
[Texane] had been thinking about how to monitor the state of his garage door from a remote place. The door itself isn’t around any power outlets, and is a few floors away from where his server would be located in his apartment. This presented a few design challenges – namely, the sensor itself should have a wireless connection to the server, and being low power would be a great idea. This led to the development of a minimalist framework for wireless communication that allows a sensor to run for weeks without a battery swap.
The wireless protocol itself is based on a simple key value pair; each individual sensor, coupled with a NRF905 radio, has passes an address, a key, and a value. There are allowances for checksums and acknowledgement, but as the PDF says, this is a very minimal protocol.
With the software out of the way, [Texane] turned to the hardware. The microcontroller is a simple Arduino clone, paired with a radio and a coin cell on a small board. The micro spends most of its time in a low power state, with the sensor, in this case a reed switch, tied to an interrupt pin.
There was a problem with the power consumption of the radio, though: when the short 17-byte message was transmitting, there was a significant voltage drop. This was okay with a fully charged battery, but with a partially drained coin cell, the possibility of brownouts was high. A big cap in parallel was enough to offset this voltage drop.
It’s still a little expensive for an all-in-one home automation and monitoring system, but developing a functional wireless protocol and the hardware to go with it is no small feat. It’s actually a great piece of kit that [Texane] is sure to find a few uses for.
Very few people know assembly. [Luto] seeks to make learning assembly just a little bit easier with his “fully functional web-based assembler development environment, including a real assembler, emulator and debugger.”
These days, you can be a microcontroller expert without knowing a thing about assembly. While you don’t NEED to know assembly, it actually can help you understand quite a bit about embedded programming and how your C code actually works. Writing a small part of your code in assembly can reduce code size and speed things up quite a bit. It also can result in some very cool projects, such as using Java to program microcontrollers.
With high quality example code, it is very easy to get started learning assembly. The emulator consists of a microcontroller with 32 registers, hooked up to three LEDs, two buttons, and a potentiometer. This is way better than painfully learning assembly on real hardware. Be sure to check out the online demo! Being able to step through each line of code and clearly see the result help make assembly easier to use and understand. It would be great to see this kind of tool widely adopted in engineering programs.
Have you used assembly in any of your projects? Let us know how it went and why you choose to use assembly
[Bogdan] knows that it’s hard to model the cooling needs of any given project. It’s important to know how much heat a system can dissipate given the housing material, airflow opportunity, and the proximity of neighboring components. Inspired by an aluminium-walled enclosure that allows for mounted transistors, he devised and built a heatsink tester.
He’s using an ATXMEGA32A4U, a temperature sensor, and a IRF540 MOSFET. A specific power is dissipated across the transistor, and the temperature sensor measures the heatsink as close as possible to the transistor. Through the serial connection, he gets back the supply voltage, current, calculated power, DAC set, temperature, and calculated thermal resistance in the terminal.
[Bogdan]’s tester assumes that it is reading the ambient temperature, so the circuit needs to warm up first. He found that an hour is generally long enough to reach this point. He also found that the system exhibits high thermal inertia, so it regulates the DAC output based on the dissipated power.
Ideally, technology is supposed to enhance our lives. [Shane and Eileen], two seniors at Cornell have found a great way to enhance the lives of visually impaired individuals with their acoustic wayfinding device. In brainstorming for their final project, [Shane and Eileen] were inspired by this Hackaday post about robots as viable replacements for guide dogs. They sought to provide wearable, hands-free guidance and detection of (primarily) indoor obstacles—namely chairs, benches, and other inanimate objects below eye level.
The wayfinder comprises two systems working in tandem: a head-mounted navigation unit and a tactile sensor worn on the user’s finger. Both systems use Maxbotix LV-MaxSonar-EZ0 ultrasonic rangefinder modules to detect obstacles and vibrating mini-disc motors to provide haptic feedback at speeds proportionate to the user’s distance from an obstacle.
The head unit uses two rangefinders and two vibrating motors. Together, the rangefinders have a field of view of about 120 degrees and are capable of detecting obstacles up to 6.45 meters away. The tactile sensor comprises one rangefinder and motor and is used in a manner similar to a Hoover cane. The user sweeps their hand to detect objects that would likely be out of the range of the head unit. Both parts are ergonomic and size-adjustable.
At power up, [Shane and Eileen]’s software performs a calibration of the tactile sensor to determine the distance threshold in conjunction with the user’s height. They’ve used an ATMega 1284 to drive the system, and handled real-time task scheduling between the two subsystems with the TinyRealTime kernel. A full demonstration video is embedded after the break.
Continue reading “Acoustic Wayfinder for the Visually Impaired”