In the world of computers, the central processing unit (CPU) is–well–central. Your first computer course probably explained it like the brain of the computer. However, sometimes you can overload that brain and CPU designers are always trying to improve both speed and throughput using a variety of techniques. One of those methods is DMA or direct memory access.
As the name implies, DMA is the ability for an I/O device to transfer data directly to or from memory. In some cases, it might actually transfer data to another device, but not all DMA systems support that. Sounds simple, but the devil is in the details. There’s a lot of information in this introduction to DMA by [Andrei Chichak]. It covers different types of DMA and the tradeoffs involved in each one.
Continue reading “Understanding DMA”
A while back, [Jorj] caught wind of a Hackaday post from December. It was a handheld Apple IIe, emulated on an ATMega1284p. An impressive feat, no doubt, but it’s all wrong. This ATapple only has 12k of RAM and only runs at 70% of the correct speed. The ATapple is impressive, but [Jorj] knew he could do better. He set out to create the ultimate portable Apple IIe. By all accounts, he succeeded.
This project and its inspiration have a few things in common. They’re both assembled on perfboard, using tiny tact switches for the keyboard. The display is a standard TFT display easily sourced from eBay, Amazon, or Aliexpress. There’s a speaker for terribad Apple II audio on both, and gigantic 5 1/4″ floppies have been shrunk down to the size of an SD card. That’s where the similarities end.
[Jorj] knew he needed horsepower for this build, so he turned to the most powerful microcontroller development board he had on his workbench: the Teensy 3.6. This is a 180 MHz ARM Cortex M4 running a full-speed Apple IIe emulator. Writing a simple 6502 emulator is straightforward, but Apple IIe emulation also requires an MMU. the complete emulator is available in [Jorj]’s repo, and passes all the tests for 6502 functionality.
The project runs all Apple II software with ease, but we’re really struck by how simple the entire circuit is. Aside from the Teensy, there really isn’t much to this build. It’s an off-the-shelf display, a dead simple keyboard matrix, and a little bit of miscellaneous circuitry. It’s simple enough to be built on a piece of perfboard, and we hope simple enough for someone to clone the circuit and share the PCBs.
We aren’t sure this technically qualifies as music synthesis, but what else do you call a computer playing music? In this case, the computer is a Teensy, and the music comes from a common classroom instrument: a plastic recorder. The mistaken “flute” label comes from the original project. The contraption uses solenoids to operate 3D printed “fingers” and an air pump — this is much easier with a recorder since (unlike a flute) it just needs reasonable air pressure to generate sound.
A Teensy 3.2 programmed using the Teensyduino IDE drives the solenoids. The board reads MIDI command sent over USB from a PC and translates them into the commands for this excellent driver board. It connects TIP31C transistors, along with flyback diodes, to the solenoids via a terminal strip.
On the PC, a program called Ableton sends the MIDI messages to the Teensy. MIDI message have three parts: one sets the message type and channel, another sets the velocity, and one sets the pitch. The code here only looks at the pitch.
This is one of those projects that would be a lot harder without a 3D printer. There are other ways to actuate the finger holes, but being able to make an exact-fitting bracket is very useful. Alas, we couldn’t find a video demo. If you know of one, please drop the link in the comments below.
We have seen bagpipe robots (in fact, we’ve seen several). We’ve also seen hammering shotguns into flutes, which is certainly more melodious than plowshares.
Building a software defined radio (SDR) involves many trades offs. But one of the most fundamental is should you use an FPGA or a CPU to do the processing. Of course, if you are piping data to a PC, the answer is probably a CPU. But if you are doing the whole system, it is a vexing choice. The FPGA can handle lots of data all at one time but is somewhat more difficult to develop and modify. CPUs using software are flexible–especially for coding user interfaces, networking connections, and the like) but don’t always have enough horsepower to cope with signal processing tasks (and, yes, it depends on the CPU).
[Eric Brombaugh] sidestepped that trade off. He used a board with both an ARM processor and an ICE FPGA at the heart of his SDR design. He uses three custom boards: one is the CPU/FPGA board, another is a 10-bit converter that can sample at 40 MSPS (sufficient to decode to 20 MHz), and an I2S DAC to produce audio. Each board has its own page linked from the main project.
Continue reading “Ice, Ice, Radio Uses FPGA”
We’ve seen a lot of retro builds around the Z80. Not many are as neatly done or as well-documented as [dekeNukem’s] FAP80 project. Before you rush to the comments to make the obvious joke, we’ll tell you that everyone has already made up their own variation of the same joke. We’ll also tell you the name is a cross between an old design from [Steve Ciarcia] called the ZAP80 and a reference to the FPGA used in this device.
[dekeNukem] says his goal was to create a Z80 computer without all the baggage of using period-correct support chips. You can argue about the relative merits of that approach versus a more purist build, but the FAP80 has a 5 slot backplane, VGA output, a PS/2 keyboard port and more. You can see one of many videos showing the machine below.
Continue reading “The Impressive Z80 Computer With The Unfortunate Name”
You can now program the Open-V on the web, and see the results in real time. The code is compiled in the web IDE and then flashed to a microcontroller which is connected to a live YouTube live stream. It’s pretty neat to flash firmware on a microcontroller thousands of miles away and see the development board blink in response.
We’ve covered the Open-V before, and the crowd funding campaign they have going. The Open-V is an open hardware implementation of the RISC-V standard. And is designed to offer Cortex M0-class capabilities.
This feels like a create way to play around with some real hardware and get a taste of what a future where we can expect Arduino-like boards, open source down to the transistor level.
For a closer look at why open silicon matters, check out [Brian Benchoff’s] hands-on review of the HiFive, an Arduino form-factor board built around an open hardware RISC-V microcontroller.
Rotary encoders are great devices. Monitoring just a few pins you can easily and quickly read in rotation and direction of a user input (as well as many other applications). But as with anything, there are caveats. I recently had the chance to dive into some of the benefits and drawbacks of rotary encoders and how to work with them.
I often work with students on different levels of electronic projects. One student project needed a rotary encoder. These come in mechanical and optical variants. In a way, they are very simple devices. In another way, they have some complex nuances. The target board was an ST Nucleo. This particular board has a small ARM processor and can use mbed environment for development and programming. The board itself can take Arduino daughter boards and have additional pins for ST morpho boards (whatever those are).
The mbed system is the ARM’s answer to Arduino. A web-based IDE lets you write C++ code with tons of support libraries. The board looks like a USB drive, so you download the program to this ersatz drive, and the board is programmed. I posted an intro to mbed awhile back with a similar board, so if you want a refresher on that, you might like to read that first.
Reading the Encoder
The encoder we had was on a little PCB that you get when you buy one of those Chinese Arduino 37 sensor kits. (By the way, if you are looking for documentation on those kinds of boards, look here.; in particular, this was a KY-040 module.) The board has power and ground pins, along with three pins. One of the pins is a switch closure to ground when you depress the shaft of the encoder. The other two encode the direction and speed of the shaft rotation. There are three pull-up resistors, one for each output.
I expected to explain how the device worked, and then assist in writing some code with a good example of having to debounce, use pin change interrupts, and obviously throw in some other arcane lore. Turns out that was wholly unnecessary. Well… sort of.
Continue reading “Encoders Spin Us Right Round”