Slowly, very slowly, the time when we don’t subject embedded beginners to AVRs and PICs is coming. At a glacial pace, FPGA development platforms are becoming ever more capable and less expensive. [Eric Brombaugh] has been playing around with both ARMs and FPGAs for a while now and decided to combine these two loves into a single board that’s capable of a lot.
This board is fittingly called an STM32F303 + ice5 development board, and does exactly what it says on the tin. There’s an STM32F303 on board providing a 32-bit CPU running at 72 MHz, 48 kB of SRAM, a quarter meg of Flash, and enough peripherals to keep anyone happy. The FPGA side of this board is a Lattice iCE5 with about 3k Look Up Tables (LUTs), and one time programmable non-volatile config memory.
The connections between the ARM and FPGA include a dedicated SPI port, and enough GPIOs to implement full-duplex I2S and a USART. Like all good projects, [Eric] has shared all the files, schematics, and BOMs required to make this board your very own reality, and has provided a few links to the development toolchains. While the FPGA is from Lattice’s ice40 family, it’s not supported by the Open Source Project Icestorm toolchain. Still, it’s a very capable board for ARM and FPGA development.
There is no CPU that is better understood than the 6502 and its cousins the 6510, 6507, 6509, and whatever we’re calling the CPU in the NES. With this vast amount of documentation, just about anything can be done. Want a discrete and un-discreet 6502? Sure thing. It’s the NMOS version, though. Want an emulated version. Sure. With libraries porting the 6502 to every platform ever, there’s only one place left to go: putting a 6502 in a Commodore 64. Make it dual-core, too, so we can run CP/M.
This build is based on one of [telmomoya]’s earlier builds – a soft-core 6510 running on an ARM Cortex M3. The inspiration for this build came from a 6502 emulator running on an Arduino, which got [telmomoya] wondering what would happen if he attached some external RAM, CIA or a SID. Doing this on an Arduino is hard, but there are a few 5 Volt tolerant ARM chips out there, and with a few banks of SRAM, [tel] quickly had an emulated 6502 running EhBasic.
Running an emulated 6502 on an ARM chip is nothing new. What makes this build spectacular is the adaptation to the C64 motherboard. Since [telmomoya] was already breaking out the data and address lines to go to the SRAMs, it didn’t take much extra work to simply build an adapter for the DIP40 CPU socket on a C64. A few 74-series logic chips made the interface easy, and after a bit of soldering, [telmomoya] had a Commodore 64 powered by an ARM chip.
If you’re emulating one chip, you can emulate two, and with the Commodore 64, this leads to a few interesting possibilities. The C64 had a CP/M cartridge — a cartridge that contained a Z80 CPU, sharing the data and address bus with the 6510. This cartridge allowed the ‘toy computer’ C64 to run the ‘business’ CP/M operating system (and the Z80 made the Commodore 128 much cooler). Since [telmomoya] was already emulating a CPU, emulating a second CPU wasn’t really that hard.
It’s a phenomenal build, and great if you’ve ever wanted to speed up VisiCalc.
Boston Dynamics, the lauded robotics company famed for its ‘Big Dog’ robot and other machines which push mechanical dexterity to impressive limits have produced a smaller version of their ‘Spot’ robot dubbed ‘SpotMini’.
A lightweight at 55-65 lbs, this quiet, all-electric robot lasts 90 minutes on a full charge and boasts partial autonomy — notably in navigation thanks to proprioception sensors in the limbs. SpotMini’s most striking features are its sleek new profile and manipulator arm, showing off this huge upgrade by loading a glass into a dishwasher and taking out some recycling.
Robots are prone to failure, however, so it’s good to know that our future overlords are just as susceptible to slipping on banana peels as we humans are.
In the show Full Metal Alchemist, there’s a city called Rush Valley whose main and only business are the high performance prostheses called Automail. Engineers roam the street in Rush Valley; the best have their own shop like that of the high-end clothiers in Saville Row. Of course; it’s all fantasy set in a slightly ridiculous Japanese cartoon, but while walking through this year’s Maker Faire I began to wonder if is a future that may come to be.
The problem with prosthetics is the sheer variety of injuries, body types, and solutions needed. If an injury is an inch higher or an inch lower it can have a big effect on how a prosthetic will interact with the limb. If the skin is damaged or the nerves no longer function a different type of prosthesis will be needed. Some prostheses are to replace a lost limb, others are to assist an ailing body in order to return it to normal function. More than a few are simply temporary aides to help the body along in its healing efforts. Unfortunately, this means that it’s often the case that larger companies only sell the prostheses people are most likely to need; the rarer cases are often left without a solution.
However, we see hackers stepping up and not just working on the problems, but solving them. One of our semifinalists last year, openbionics, inspired one of the projects we’ll be talking about later. There are robotic legs. We met a guy at MRRF who has been 3D printing hands for his son from the E-nable project.
Along these lines, we saw two really cool projects at Maker Faire this year: The first is the Motor-Assistive Glove, or MAG. MAG is designed to help people with Peripheral Neropathy regain some use of their hands while they go through the lengthy road to recovery. Perhipheral Neuropathy is a disease, usually resulting from diabetes, toxin exposure, or infection, where the nerves are damaged in such a way that typically the hands and feet are no longer mobile or feel sensation in a useful way. Once the disease is in full swing, a previously able person will find themselves unable to do simple things like hold a can of soda or grasp a doorknob firmly enough to open it.
We had a chance to interview one of the members of the MAG team, [Victor Ardulov], which you can see in the following video. [Victor] and his group started a research project at the University of Santa Cruz to develop the Motor-Assistive Glove. The concept behind it is simple. People with Peripheral Neuropathy typically have some movement in their hands, but no strength. The MAG has some pressure sensors at the tips of the fingers. When the user puts pressure on the pad; the glove closes that finger. When the pressure is off; the glove opens. The concept is simple, but the path to something usable is a long one.
There’s a tremendous amount of value in using pre-built, known-good development environments. It saves you hours of potential headaches when things aren’t working. Is the bug in the hardware or the software? If you bought a dev kit, you can be pretty sure it’s your software. But sometimes using a dev kit also feels like there’s a black box in the system. [Kevin] wanted to peer inside the black box, so he ordered a tray of cheap STM32F103 chips on eBay, and did the rest himself.
“The rest” isn’t all that much, but figuring that out is half the battle. [Kevin] soldered the TQFP chip onto a breakout board, added some decoupling capacitors, and connected four pins up to a dirt-cheap ST-Link programmer clone. The rest of the article describes the toolchain he used to compile for and program the chip. The end result is, natch, a blinking LED.
If you’re a bit experienced with microcontrollers and want to dive head-first into an ARM chip, [Kevin]’s writeup is just the ticket. In a single (long) blog post, he walks you through all the steps. If this is your first rodeo, you might be tempted to cheese out and buy a pre-built board on eBay (search “STM32F103” and you’ll find many options to choose from) and we don’t think that’s a bad idea either. Still, there’s just something to be said for the confidence that you’ll have once you’ve built the whole system from scratch.
A lot of old science fiction movies show people wearing the same–or nearly the same–clothes. We’re left guessing if this is because there is a single centralized plant mass-producing skin-tight jumpsuits, or if everyone is under orders to dress the same. Now that we live in the past’s future, it looks like science fiction was a poor predictor of fashion. People want variety.
Which calls to mind development boards. How many different ones do we need? Need doesn’t matter, because we have plenty of them. There may be strong leaders: in the 8-bit world, you think of the Arduino, and on the Linux side, maybe the Raspberry Pi. But there are options.
If you’ve read through the comments on Hackaday, you’ve doubtless felt the fires of one of our classic flame-wars. Any project done with a 32-bit chip could have been done on something smaller and cheaper, if only the developer weren’t so lazy. And any project that’s squeezes the last cycles of performance out of an 8-bit processor could have been done faster and more appropriately with a 32-bit chip.
Of course, the reality for any given project is between these two comic-book extremes. There’s a range of capabilities in both camps. (And of course, there are 16-bit chips…) The 32-bit chips tend to have richer peripherals and run at higher speeds — anything you can do with an 8-bitter can be done with its fancier cousin. Conversely, comparatively few microcontroller applications outgrow even the cheapest 8-bitters out there. So, which to choose, and when?
Eight Bits are Great Bits
The case that [Mike] makes for an 8-bit microcontroller is that it’s masterable because it’s a limited playground. It’s a lot easier to get through the whole toolchain because it’s a lot shorter. In terms of debugging, there’s (often) a lot less that can go wrong, letting you learn the easy debugging lessons first before moving on to the truly devilish. You can understand the hardware peripherals because they’re limited.
And then there’s the datasheets. The datasheet for a chip like the Atmel ATMega168 is not something you’d want to print out, at around 660 pages long. But it’s complete. [Mike] contrasts with the STM32F405 which has a datasheet that’s only 200 pages long, but that’s just going over the functions in principle. To actually get down to the registers, you need to look at the programming manual, which is 1,731 pages long. (And that doesn’t even cover the various support libraries that you might want to use, which add even more to the documentation burden.) The point is, simpler is simpler. And if you’re getting started, simpler is better.