[Stephen] designed a standalone Ambilight clone built around an FPGA and recently added many new features to make his design even better. His original design was based around a Spartan 3-E FPGA, but his new design uses the Papilio One board with a Spartan-6 LX9 FPGA. This gives him dedicated DSP hardware and more RAM, allowing him to add more processing-intensive features.
[Steven]’s new board can drive up to 4096 LEDs total, and each LED is colored from one of 256 segmented screen areas. The output of the LEDs is smoothed over a configurable time period which makes the result a bit more pleasant. [Steven] also added color correction matrices and gamma correction tables to make up for differences in LED coloration and so the output can be fine-tuned to the color of the wall behind the TV.
Finally, [Steven] added multiple configurations which can be stored in Flash memory. The FPGA can detect letterboxes and pillarboxes in the video stream and change to a corresponding configuration automatically, so settings rarely need to be manually adjusted. He also added an extensive serial interface to configure all of the parameters and configurations in Flash. Be sure to check out the video after the break to see his setup in action.
Continue reading “FPGA Ambilight Clone Packs a Ton of Features”
Somewhere down the road, you’ll find that your almighty autonomous robot chassis is going to need some sensor feedback. Otherwise, that next small step down the road may end with a blind leap off the coffee table. The first low-cost sensors we might throw at this problem would be sonars or IR rangefinders, but there’s a problem: those sensors only really provide distance data back from the pinpoint view directly ahead of them.
Rest assured, [Jonathan] wrote in to let us know that he’s got you covered. Combining a line laser, camera, and an FPGA, he’s able to detect obstacles that fall within the field of view of the camera and laser.
If you thought writing algorithms in software is tricky, wait till to you try hardware! (We know: division sucks!) [Jonathan] knows no fear though; he’s performing gradient computation on the FPGA directly to detect the laser in the camera image at a wicked 30 frames-per-second. Why roll up your sleeves and take the hardware route, you might ask? If we took a CPU-based approach at the tiny embedded-robot scale, Jonathan estimates a mere 10 frames-per-second. With an FPGA, we’re able to process images about as fast as they’re received.
Jonathan is using the Logi Board, a Kickstarter success we’ve visited in the past, and all of his code is up on the Githubs. If you crack it open, you’ll also find that many of his modules are Wishbone compliant, so developing your own projects with just some of these parts has been made much easier than trying to rip out useful features from a sea of hairy logic.
With computer-vision hardware keeping such a low profile in the hobbyist community, we’re excited to hear more about [Jonathan’s] FPGA-based robotics endeavors.
Continue reading “Robot Vision: Detecting Obstacles with FPGAs and line lasers”
The Parallax Propeller is an interesting chip that doesn’t get a lot of love, but since the entire chip was released as open source, that might be about to change: people are putting this chip inside FPGA and modifying the binaries to give the chip functions that never existed in the original.
Last August, Parallax released the source for the P8X32A, giving anyone with an FPGA board the ability to try out the Prop for their own designs. Since then, a few people have put some time in, cleaning up the files, unscrambling ROM images, fixing bugs, and all the general maintenance that an open source microcontroller core requires.
[Sylwester] has grabbed some of the experimental changes found on the Parallax forum and included them as a branch of the Propeller source. There is support for a second 32-bit port, giving the new chip 64 I/O pins, multiply instructions, video generators, hard-coded SD card libraries, and a variant called a microProp that has four cores instead of eight.
You can grab all the updated sources right here and load them up on a DE0 Nano FPGA board. If you’re exceptionally lucky and have the Altera DE2-115 dev board, you’ll also be able to run the upcoming Propeller 2.
Open Sourcing something doesn’t actually acquire meaning until someone actually uses what has been unleashed in the wild. We’re happy to see a working example of Propeller 1 on an FPGA dev board. That link takes you to a short description and some remapping of the pins to work with a BeMicro CV board. But you’ll want to watch the video below, or rather listen to it, for a bit more explanation of what [Sylwester] did to get this working.
You’ll remember that Parallax released the Propeller 1 as Verilog code a few weeks back. This project first loads the code onto the FPGA, then proves it works by running SIDcog, the Commodore 64 sound emulation program written in Spin for p8x32a processors.
We do find this to be an interesting first step. But we’re still waiting to see what type of hacks are made possible because of the newly available Verilog code. If you have a proof of concept working on other hardware, certainly tell us about it below. If you’ve been hacking on it and have something you want to show off, what are you waiting for?
Continue reading “FPGA with Open Source Propeller 1 Running Spin”
It’s no secret that people love the 6502 processor. This historic processor powered some of our favorite devices, including the Apple II, the Commodore 64, and the NES. If you want to play with the 6502, but don’t want to bother with obtaining legacy chips, the CHOCHI board is for you.
While many people have built modern homebrew 6502 computers, the CHOCHI will be much easier for those looking to play with the architecture. It’s based on a Xilinx XC3S50 FPGA which comes preconfigured as a 6502 processor.
After powering on the board, you can load a variety of provided binaries onto it. This collection includes a BASIC interpreter and a Forth interpreter. Of course, you’re free to write your own applications in 6502 assembly, or compile C code for the device using the cc65 compiler.
If you get bored with the 6502 core, you can always grab Xilinx’s ISE WebPACK for free and use the board as a generic FPGA development tool. It comes with 128K of SRAM and 31 I/O pins. Not bad for a $30 board.
Graphics accelerators move operations to hardware, where they can be executed much faster. This is what allows your Raspberry Pi to display high definition video decently. [Andy]’s latest build is a 2D sprite engine, featuring hardware accelerated graphics on an FPGA.
In the simplest mode, the sprite engine just passes commands through to the LCD. This allows for basic control. The fun part sprite mode, which allows for sprites to be loaded onto the FPGA. At that point, you can show, hide, and move the sprite. By overlapping many sprites, you something like the demo shown above.
The FPGA is from Xilinx, and uses their Block RAM IP to store the state of the sprites. The actual sprite data is contained on a 128 Mb external flash chip, since they require significant space.
The game logic runs on a STM32 Cortex M4 microcontroller which communicates with the FPGA and orders the sprites around. The FPGA then deals with generating frames and sending them to the LCD screen, freeing up the microcontroller.
If you’re wondering about the LCD itself, it’s 3.2″, 640 x 360, and taken from a Ericsson U5 Vivaz cellphone. [Andy] has a detailed writeup on reverse engineering it. After the break, he gives us a video overview of the whole system.
Continue reading “Sprite Graphics Accelerator on an FPGA”
During one of [Michael]’s many forum lurking sessions, he came across a discussion about frequency counting on a CPLD. He wondered if he could do the same on an FPGA, and how hard it would be to count high clock rates. As it turns out, it’s pretty hard with a naive solution. Being a bit more clever turns the task into a cakewalk, with a low-end FPGA being able to count clocks over 500 MHz.
The simplest solution for counting a clock would be to count a clock for a second with a huge, 30-bit counter. This is a terrible idea: long counters have a lot of propagation delays. Also, any sampling would have to run at least twice as fast as the input signal – not a great idea if you’re counting really fast clocks.
The solution is to have the input signal drive a very small counter – only five bits – and sample the counter using a slower clock on board the FPGA. [Michael] used a 5-bit Gray code, getting rid of the problem of the ‘11111’ to ‘00000’ rollover of a normal binary counter.
Because [Michael] is using a 5 bit clock with 31 edges sampled at 32 MHz, he can theoretically sample a 992 MHz clock. There isn’t a chance in hell of the Spartan 6 on his Papilio Pro board ever being able to measure that, but he is able to measure a 500 MHz clock, something that would be impossible without his clever bit of code.