[Martin Hubáček] wrote in with his WS2812 LED library for the STM32F3 series processors. [Martin]’s library takes the same approach as [Paul Stoffregen]’s OctoWS2811 for the Teensy, and [Erich Styger]’s for the Freescale FRDM-K64F board. That is, it uses three DMA channels to get the signal out as fast as possible.
[Mike] wanted to drive several SPI peripheral from a PIC32. He shows how much latency his conventional interrupt handlers were taking away from his main task. He needed something more efficient. So he created the SPI channels using DMA. He also made a video (see below) with a very clear explanation about why he did it and shows oscilloscope traces about how it all works.
Although the project is specific to the PIC32, the discussion about DMA applies to any computer with direct memory access. The only thing missing is the code. However, there are plenty of examples on the web you can look at, including a Microchip webinar.
The venerable ESP8266 has rocked the Internet of Things world. Originally little more than a curious $3 WiFi-to-serial bridge, bit by bit, the true power of the ESP has become known, fully programmable, with a treasure trove of peripherals it seemed that the list of things the ESP couldn’t do was short. On that list, at least until today was Ethernet.
No, despite the misleading title, the ESP does not have a MAC and/or PHY, but what it does have is an incredible 80 MHz DMA-able shift register which can be used to communicate 10BASE-T Ethernet using a new project, espthernet. Join me after the break for video proof, and a deep dive into how this is possible.
The ESP8266 is well known as an incredibly small and cheap WiFi module. But the silicon behind that functionality is very powerful, far beyond its intended purpose. I’ve been hacking different uses for the board and my most recent adventure involves generating color video from the chip. This generated video may be wired to your TV, or you can broadcast it over the air!
I’ve been tinkering with NTSC, the North American video standard that has fairly recently been superseded by digital standards like ATSC. Originally I explored pumping out NTSC with AVRs, which lead to an entire let’s learn, let’s code series. But for a while, this was on the back-burner, until I decided to see how fast I could run the ESP8266’s I2S bus (a glorified shift register) and the answer was 80 MHz. This is much faster than I expected. Faster than the 1.41 MHz used for audio (its intended purpose), 2.35 MHz used for controlling WS2812B LEDs or 4 MHz used to hopefully operate a reprap. It occasionally glitches at 80 MHz, however, it still works surprisingly well!
The coolest part of using the chip’s I2S bus is the versatile DMA engine connected to it. Data blocks can be chained together to seamlessly shift the data out, and interrupts can be generated upon a block’s completion to fill it in with new data. This allows the creation of a software defined bitstream in an interrupt.
Why NTSC? If I lived in Europe, it would have been PAL. The question you’re probably thinking is: “Why a dead standard?” And there’s really three reasons.
I usually see retro-gaming projects using tiny screens with a fair number of pixels (64×64) but what I really like is the look of making every pixel count. With this in mind I built 1-Pixel Pac-Man, the classic coin-op experience but with characters that consist of just one pixel. Playing a throw-back like this wouldn’t be the same without some vintage controls so I picked up an Atari joystick, patched it into a microcontroller, and started coding. Check it out:
This piece of hardware made the project build really easy: the Smartmatrix. [Louis Beaudioin] developed the Smartmatrix and it’s been in the Hackaday Store for a while now. The display module itself is a commodity item that is used in LED billboards. There are shrouded headers on the back of the panels, to the left and right sides, which allow them to be daisy chained. The Smartmatrix PCB plugs into one of these shields, provides a soldering footprint for the Teensy 3.1 which drives the display, and gives you the wiring to connect screw terminals from the PCB to the power terminals on the module. Why the need for beefy power jumpers? At full white the thing can draw about 3.5A — don’t worry there’s a power supply included in the bundle.
Also integral to making this look good is the diffuser panel which is frosted acrylic. The Smartmatrix is designed to be housed in a shadowbox frame; it even includes a frame backer board with a cut-out for the Teensy 3.1 so it can be programmed without opening the thing up. I like looking at the guts so I’m leaving my free floating until I come up with an interesting way to mount everything as one unit.
Programming Pac-Man from the Ground Up
If you haven’t looked into it before, the ghost AI and gameplay details for Pac-Man are absolutely brilliant. [Toru Iwatani] did a masterful job with the original, and you should take a look at all of the analysis that has been done over the years. The best collection I could find was the Pac-Man Dossier and I based most of my code on the rules described there.
Basically the ghosts have two modes, chase and scatter. The modes set the enemy targets differently; to points at the four corners of the board in scatter, and to points relative to the player in chase. The relative part is key; only the red enemy actually chases you. Another one of them looks at the red enemy’s distance and angle, and targets the reflection of that vector. Really easy, really clever, and results in enemy behavior that’s believable. It isn’t just the enemy movement, little touches like a speed penalty (1/60 of a second) for each dot the player gobbles up means the enemies can catch up if you continuously eat, but you can escape by taking the path already-eaten.
Library, DMA, and Extra Hardware
The hardware and software running the Smartmatrix made the display portions of the project really simple. First off, the Teensy 3.1 is fast, running at 96MHz in this case. Second, it has Direct Memory Access (DMA) which [Louis] used in the Smartmatrix library. This means that driving the display takes almost no CPU time at all, leaving the rest for your own use. This example of a game is under-utilizing this power… it’s totally capable of full-motion video and calculating amazing visualizations on the fly.
The PCB hosting the Teensy 3.1 breaks out several pins to one side. I’m not sure what I’ll add in the future so I actually used the extra surface-mount IO pins on the bottom of the Teensy to connect the Atari joystick (which is simply a set of switches). The are enough pads for two joysticks so I used pin sockets to interface the Teensy to the PCB so that I can get to it again later.
The kit also includes an IR receiver and remote, and also a microSD card to loading animations (there’s an SD socket on the PCB). The bundle in the Hackaday Store is a kit you solder yourself, but [Louis’] company, Pixelmatix, has a Kickstarter running for fully-assembled versions that come with a black remote and sound-visualization hardware.
The game is fully working, but there are a few key things that I really want to add. The Teensy 3.1 has a single DAC pin available. I’m fairly certain the original coin-op game had mono audio. It should be possible to reproduce the sound quite accurately with this board. That would really make the project pop.
There are also a bunch of touch-ups that need to happen. I’d like to add an animation when the player is eaten by an enemy, and a countdown before the level restarts. The score, shown in binary on the right column, should be scrolled out in decimal when the game ends, and what’s a coin-op recreation without a high-score screen?
Like just about everyone we know, [Luis] decided a gigantic RGB LED matrix would be a cool thing to build. Gigantic LED matrices are very hard to build, though: not only do you have to deal with large power requirements and the inevitable problems of overheating, you also need to drive a boat load of LEDs. This is not easy.
[Luis] found a solution to the problem of driving these LEDs with a new, fancy ARM Cortex M4 microcontroller. All Cortex M4 ARMs have DMA, making automatic memory transfers to peripherals and LED strips a breeze.
The microcontroler [Luis] is using only supports 1024 transfers per transfer set, equating to a maximum of 14 LEDs per transfer. This problem can be fixed by using the ping-pong mode in the DMA controller by switching between data structures for every DMA request. Basically, he’s extending the number of LEDs is just switching between two regions of memory and setting up the DMA transfer.
The result is much better than [Luis]’ original circuit that was just a bunch of SPI lines. It also looks really good, judging by the video below. It’s not quite a gigantic LED matrix yet, but if you want to see what that would look like, check out the huge 6 by 4 foot matrix hanging in the Hackaday overlord office.
[Lewin] wrote in to tell us about a high speed library for Arduino Due that he helped develop which allows interfacing OLED displays that use the SSD1306 display controller, using DMA routines for faster display refresh time.
Typically, displays such as the Monochrome 1.3″ 128×64 OLED graphic display , are interfaced with an Arduino board via the SPI or I2C bus. The Adafruit_SSD1306 library written by [Limor Fried] makes it simple to use these displays with a variety of Arduinos, using either software or hardware SPI. With standard settings using hardware SPI, calls to display() take about 2ms on the Due.
[Lewin] wanted to make it faster, and the SAM3X8E on the Due seemed like it could deliver. He first did a search to find out if this was already done, but came up blank. He did find [Marek Buriak]’s library for ILI9341-based TFT screens. [Marek] used code from [William Greiman], who developed SD card libraries for the Arduino. [William] had taken advantage of the SAM3X8E’s DMA capabilities to enable faster SD card transfers, and [Marek] then adapted this code to allow faster writes to ILI9341-based screens. All [Lewin] had to do was to find the code that sent a buffer out over SPI using DMA in Marek’s code, and adapt that to the Adafruit library for the SSD1306.
There is a caveat though: using this library will likely cause trouble if you are also using SPI to interface to other hardware, since the regular SPI.h library will no longer work in tandem with [Lewin]’s library. He offers some tips on how to overcome these issues, and would welcome any feedback or testing to help improve the code. The speed improvement is substantial. Up to 4 times quicker using standard SPI clock, or 8 times if you increase SPI clock speed. The code is available on his Github repo.