Zedboard Multiport Ethernet

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.

Open-Source Firmware for a Mini Quadrotor

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.

PSoC VGA on a $10 Development Board

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”

Scratching Vinyl Straddles Physical and Digital Realms

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”

Reverse Engineering the ARM ALU

[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”

Programming with Rust

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.

About Rust

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”

Polyphonic FM Synthesizer uses ARM

There seems to be a direct correlation between musicians and people who can program. Even programmers who don’t play an instrument often have a profound appreciation of music and so we see quite a few musical projects pop up. [Ihsan Kehribar’s] latest project is a good example. He married an STM32F031 ARM development board, an audio codec, and a simple op amp filter to make a playable MIDI instrument. Of course, it is hard to appreciate a music project from a picture, but if you want to listen to the results, there’s always Soundcloud.

He’d started the project using an 8-bit micro, but ran into some limitations. He switched to an STM32F031, which is a low-end ARM Cortex M0 chip. [Ihsan] mentions that he could have used the DSP instructions built into larger ARM chips, but he wanted to keep the project done on minimal hardware. The audio CODEC chip is from Cirrus Logic (a WM8524), and it produces two output channels at 192 kHz. As an unexpected benefit, the CODEC uses a charge pump to generate a negative voltage (much like a MAX232 does) and [Ihsan] was able to tap that voltage to provide the op-amps in the audio filter with a negative supply rail.

Continue reading “Polyphonic FM Synthesizer uses ARM”