The easiest way to connect a GSM module to a Raspberry Pi would be to buy a breakout module, install some software, and connect to a mobile network with a Pi. Need GPS, too? That’s a whole other module, with different software. The guys behind RasPiCommPlus are working on a better solution – a breakout board for breakout boards that takes care of plugging a ton of modules into a Pi and sorts out the kernel drivers to make interfacing with these modules easy.
Right now, the team has a GPS and GSM module, digital in and out modules, an analog input module, and RS-232 and -485 modules. They’re working on some cool additions to the lineup, including a breakout for Sharp memory displays, a 9-axis IMU, a stepper motor driver, and a 1-wire breakout module.
Some of the RasPiCommPlus team showed up to the Hackaday Munich party and were kind enough to sit down for a demo video. You can check that out below.
We’ve been lurking over at Big Mess ‘o Wires as [Steve] geared up for his 68000 computer build. One of his previous posts mentioned a working breadboard version but we figured it would be a ways off. Surprise, he’s got it working and what you see above took just 6 days of “occasional work” to get running.
The chip in use is actually a 68008 but we remember reading that he does plan to migrate to a 68000 because this one lacks the memory pins to address more than 1 MB of RAM. The trick here was just to get the thing running and he made some common choices to get there. For instance, he grounded the /DTACK in much the same way [Brian Benchoff] explained in his own 68k build.
We’re not sure if his address decoding was a time saver or not. If you study [Steve's] original planning post you’ll learn that he’s going to use programmable logic to handle the address decoding. But above he wired up 74-series logic chips to perform these functions. On the one hand you know your Hardware Description Language isn’t the problem, but did you terminate one of those wires where you ought not?
Additional tripping points include a bouncing reset pin. Looking at that we’d tell [Steve] there’s a problem with his chip, except that this was his first thought as well. He went the extra mile by building and testing a replica of the reset system. This makes our brain spin… shouldn’t the reset be among the most reliable parts of a processor?
Unless you’ve been to Japan or are fairly deep into the retro game collecting, you’ve probably never heard of the WonderSwan. It’s a handheld console, released after the Game Boy Color was beginning to show its age, and a bit before the introduction of the Game Boy Advance. It sold rather well in the only country it was released in, the game library is somewhat impressive, and there are quite a few homebrew games. Actually running these homebrew games is a challenge, though: each WonderSwan has a memory controller that maps the game ROM into the CPU’s memory. Without knowing how this controller chip works, the only way to run a homebrew cartridge is to turn on the machine with a real cart, go to the system menu, and swap the carts out. It turns out there’s a better solution, that includes programming CPLDs and looking at the output of a logic analyzer.
The first step towards [Godzil]‘s efforts to create a Flash cart for the WonderSwan is to figure out the pinout of the cartridge connector – something that isn’t well documented for a system without a homebrew hardware scene. This was done in the usual way; with a lot of ribbon cable and patience This only provided an incomplete picture of how the WonderSwan interfaced with its carts, but after digging up an official development board, [Godzil] was able to make sense of all the signals.
After building a breakout board for the cartridge port, [Godzil] connected a DE0 Nano FPGA board and looked at all the signals. With just a little bit of VHDL, the memory controller could be reverse engineered and reimplemented. [Godzil] has his proof of concept working – video below – and the next part of his project will be to turn this into a proper Flash cart.
The PC Engine was pretty popular in Japan, but only the coolest kids in America had the US edition, the TurboGrafx16. These two systems weren’t exactly the same; the TurboGrafx-16′s data bus was flipped so the games were made to be incompatible, and the US games have a region lockout. [Kaz] looked at the existing hacks for running Japanese games on US systems, and every single one of them required modding a console. Thinking he could do better, he came up with the PC-Henshin, an adapter and CPLD that allows Japanese game to run on US consoles.
To take care of the mixed up lines on the PC card connector between the US and Japanese variants, a few adapter cards are available. That’s great, but they only solve one part of the compatibility problem. The region lockout routine found on nearly every American title mean PC Engine consoles can’t run TurboGrafx-16 games. [Kaz] used a small, cheap CPLD to read the data bus, patch everything as it is read out, and turns a Japanese console into something that can play American games.
[PK] is working on a very simple video card, meant to output 640×480 VGA with a cheap CPLD. The interface will be 5 Volt SPI, meaning there’s a ton of potential here for anyone wanting put a reasonable (and cheap) display in a microcontroller project. The project has come a long way, and his latest update showcases something that has only been done once before: color NTSC with programmable logic
The brains of the outfit is a $5, 100-pin CPLD from Xilinx. Apart from that, the rest of the components are a crystal, PLL, and an almost hilarious number of resistors for the R2R ladder. The one especially unique component is the 25.056815 MHz crystal – multiply by that by two, and it’s fast enough to drive a VGA monitor. Divide the crystal by seven, it’s the 3.579545 MHz you need for an NTSC colorburst frequency. That’s VGA and NTSC in a single programmable logic project, something the one FPGA project we could find that did color NTSC couldn’t manage.
The next step in the project is designing a PCB and figuring out the code for the framebuffer. [PK] put up a demo showing off both VGA and NTSC; you can check that out below.
The project featured in this post is an entry in The Hackaday Prize. Build something awesome and win a trip to space or hundreds of other prizes.
The development board being used for this online course is an Altera EMP3032 CPLD conveniently included in the Introduction to FPGA and CPLD kit used in this course. It’s not a powerful device by any measure; it only has 32 macrocells and about 600 usable gates. You won’t be designing CPUs with this thing, but you will be able to grasp the concept of designing logic with code.
Future lessons include building binary counters, PWM-controlled LEDs, and a handheld LED POV device. In any event, it’s a great way to learn about how programmable logic actually works, and a fairly cheap way to get into the world of FPGAs and CPLDs. Introductory video below.
There is a wide assortment of cheap development (dev) boards for Complex Programmable Logic Devices (CPLD), the smaller cousin of the Field Programmable Logic Array (FPLA)
Using an inexpensive board and the development software that’s free to download from the major programmable companies such as Xilinx and Altera, the only additional thing needed is a programmer module. Cheap ones are available on Ebay but I am hoping that someone takes the time to teach an ARM/Arduino to step in as a programmer.
I have a small collection of dev boards including some Ebay specials and also designs I did a few years ago to choose from. For today I am grabbing a newer board that has not been fully checked out yet; an Altera Max V device. I have stuffed the CPLD, the clock oscillator, some LED’s and part of the onboard power supply along with the JTAG header needed to program the CPLD and that’s about it.