The BeagleBone is a board that doesn’t get a lot of attention in a world of $5 Raspberry Pis, $8 single board computers based on router chipsets, and a dizzying array of Kickstarter projects promising Android and Linux on tiny credit card-sized single board computers. That doesn’t mean the BeagleBone still isn’t evolving, as evidenced by the recent announcement of the BeagleBone Blue.
The BeagleBone Blue is the latest board in the BeagleBone family, introduced last week at CES. The Blue is the result of a collaboration between UCSD Engineering and TI, and with that comes a BeagleBone built for one specific purpose: robotics and autonomous vehicles. With a suite of sensors very useful for robotics and a supported software stack ideal for robots and drones, the BeagleBone Blue is the perfect board for all kinds of robots.
On board the BeagleBone Blue is a 2 cell LiPo charger with cell balancing and a 6-16 V charger input. The board also comes with eight 6V servo outputs, four DC motor outputs and inputs for four quadrature encoders. Sensors include a nine axis IMU and barometer. Unlike all previous BeagleBones, the BeagleBone Blue also comes with wireless networking: 802.11bgn, Bluetooth 4.0 and BLE. USB 2.0 client and host ports are also included.
Like all of the recent BeagleBoards, including the recently released BeagleBone Green, the Blue uses the same AM3358 1 GHz ARM Cortex 8 CPU, features 512 MB of DDR3 RAM, 4GB of on board Flash, and features the main selling point of the BeagleBoard, two 32-bit programmable real-time units (PRUs) running at 200 MHz. The PRUs are what give the BeagleBone the ability to blink pins and control peripherals faster than any other single board Linux computer, and are extremely useful in robotics, the Blue’s target use.
Right now, the BeagleBone Blue isn’t available, although we do know you’ll be able to buy one this summer. Information on pricing and availability – as well as a few demos – will come in February.
The Zedboard uses Xilinx’s Zynq, which is a combination ARM CPU and FPGA. [Jeff Johnson] recently posted an excellent two-part tutorial covering using a Zedboard with multiple Ethernet ports. The lwIP (light-weight Internet Protocol) stack takes care of the software end.
Vivado is Xilinx’s software for configuring the Zynq (among other chips), and the tutorial shows you how to use it. The Ethernet PHY is an FPGA Mezzanine Card (FMC) with four ports that is commercially available. The project uses VHDL, but there is no VHDL coding involved, just the use of canned components.
The real issue when using an FPGA and a CPU is the interface between the processor and the FPGA circuitry. In this case, the ARM standard AXI bus does this task, and the Ethernet component properly interfaces to that bus. The IP application in the second part of the post is an echo server.
We’ve seen the Zynq used in flying machines and also in a music synthesizer. Although this project doesn’t use any Verilog or VHDL that you create, it is still a great example of configuring using Vivado and using common components in a design.
Since you’re going to have to be flying your “drones” indoors anyway in the USA, at least in the US Capitol region, you might as well celebrate the one freedom you still have — the freedom to re-flash the firmware!
The Eachine H8 is a typical-looking mini-quadcopter of the kind that sell for under $20. Inside, the whole show is powered by an ARM Cortex-M3 processor, with the programming pins easily visible. Who could resist? [garagedrone] takes you through a step-by-step guide to re-flashing the device with a custom firmware to enable acrobatics, or simply to tweak the throttle-to-engine-speed mapping for the quad. We had no idea folks were doing this.
Spoiler alert: re-flashing the firmware is trivial. Hook up an ARM SWD programmer (like the ST-Link V2) and you’re done. Wow. All you need is firmware.
The firmware comes from [silverxxx], and he’s written all about it on the forum at RCGroups.com. He’s even got the code up on GitHub if you’re interested in taking a peek. It looks like it’d be fun to start playing around with the control algorithms. Next step, Skynet!
Reading the forum post, it looks like you’ll have to be a little careful to get the right model quad, so look before you leap. But for the price, you can also afford to mess up once. Heck, at that price you could throw away the motors and you’d have a tricked-out ARM dev kit.
And if you insist on hacking everything, you can probably re-purpose a wireless mouse controller to control the thing. Write your own code for the controller and you’ve got an end-to-end open firmware quadcopter for a pittance.
We’ve always found the Cypress PSoC an interesting beast. It’s a CPU with functional blocks that you can configure to build various I/O devices, including incorporating FPGA logic using Verilog. [MiguelVP] has an excellent multi-part project that produces VGA output from a PSoC. So far it just generates a fixed pattern, but a frame buffer is in the works, and there is plenty of detail about how to configure the PSoC for the task.
Although the PSoC has some analog capability, [MiguelVP] uses a cheap R2R DAC and VGA connector to interface to the VGA monitor. You can get the same PSoC board the project uses for about $10. The software, unfortunately, is Windows-only, so be prepared to fire up a virtual machine if you run Linux or Mac. Our own [Bil Herd] did a video introduction to PSoC that you can watch after the break.
Continue reading “PSoC VGA on a $10 Development Board”
The life of a modern DJ is hard. [Gergely] loves his apps, but the MIDI controller that works with the app feels wrong when he’s scratching, and the best physical interfaces for scratching only work with their dedicated machines. [Gergely]’s blog documents his adventures in building an interface to drive his iPad apps from a physical turntable. But be warned, there’s a lot here and your best bet is to start at the beginning of the blog (scroll down) and work your way up. Or just let us guide you through it.
In one of his earliest posts he lays out his ideal solution: a black box that interprets time-code vinyl records and emulates the MIDI output of the sub-par MIDI controller. Sounds easy, right? [Gergely] gets the MIDI side working fairly early on, because it’s comparatively simple to sniff USB traffic and emulate it. So now he’s got control over the MIDI-driven app, and the hard part of interfacing with the real world began.
After experimenting a lot with timecode vinyl, [Gergely] gives up on that and looks for an easier alternative. He also considers using an optical mouse, but that turns out to be a dead-end as well. Finally, [Gergely] settled on using a Tascam TT-M1, which is basically an optical encoder that sits on top of the record, and that makes the microcontroller’s job a lot easier. You can see the result in the video below the break.
And then in a surprise ending worthy of M. Night (“I see dead people”) Shyamalan he pulls timecode vinyl out of the grave, builds up a small hardware translator, and gets his original plan working. But we have the feeling that he’s not done yet: he also made a 3D printed optical-mouse holder.
Continue reading “Scratching Vinyl Straddles Physical and Digital Realms”
[Dave] wanted to learn more about the ARM architecture, so he started with an image of the ARMV1 die. If you’ve had some experience looking at CPU die, you can make some pretty good guesses at what parts of the chip have certain functions. [Dave], however, went further. He reverse engineered the entire ALU–about 2,200 transistors worth.
Continue reading “Reverse Engineering the ARM ALU”
Do hardware hackers need a new programming language? Your first answer might be no, but hold off a bit until you hear about a new language called Rust before you decide for sure.
We all know real hackers use assembly language to program CPUs directly, right? Well, most of us don’t do as much assembly language as we used to do. Languages like C can generate tight, predictable code and are easier to manage.
Although some people use more abstract languages in some embedded systems, it is no secret that for real-time systems, device driver development, and other similar tasks, you want a language that doesn’t obscure underlying details or generate code that’s difficult to reason about (like, for example, garbage collection). It is possible to use special techniques (like the Real-Time Java Specification) to help languages, but in the general case a lean language is still what most programmers reach for when you have to program bare metal.
Even C++, which is very popular, obscures some details if you use things like virtual functions (a controversial subject) although it is workable. It is attractive to get the benefit of modern programming tools even if it does conceal some of the underlying code more than straight C.
That’s where Rust comes in. I could describe what Rust attempts to achieve, but it is probably easier to just quote the first part of the Rust documentation:
Rust is a systems programming language focused on three goals: safety, speed, and concurrency. It maintains these goals without having a garbage collector, making it a useful language for a number of use cases other languages aren’t good at: embedding in other languages, programs with specific space and time requirements, and writing low-level code, like device drivers and operating systems. It improves on current languages targeting this space by having a number of compile-time safety checks that produce no runtime overhead, while eliminating all data races. Rust also aims to achieve ‘zero-cost abstractions’ even though some of these abstractions feel like those of a high-level language. Even then, Rust still allows precise control like a low-level language would.
Continue reading “Programming with Rust”