[Piotr] was working on a recent Arduino project when he ran into a problem. He was having trouble getting his Arduino Pro Mini to communicate with an ESP8266 module. He needed a way to snoop on the back and forth serial communications. Since he didn’t have a specialized tool for this task, [Piotr] ended up building his own.
The setup is pretty simple. You start with a standard serial cable containing the TX, RX, DTR, and GND wires. This cable connects the Arduino to the ESP8266 WiFi module. The TX and RX lines are then tapped into. Each wire is routed to the RX pin of two different serial to USB adapters. This way, the data being sent from the Arduino shows up on one COM port and the data being transmitted from the module shows up on the other.
The next piece of the puzzle was coming up with a way to see the data more clearly. [Piotr] could have opened two serial terminals simultaneously, but this wasn’t ideal because it would be difficult to compare the timing of the data. Instead, [Piotr] spent less than an hour writing his own simple serial terminal. This one connects to two COM ports at the same time and prints the data on the same screen. The data from each COM port is displayed in a separate color to make it easy to differentiate. The schematic and source code to this project can be found on [Piotr’s] website.
[Trapper] is an 80’s kid, and back in the day the Nintendo Entertainment System was his jam. One fateful night, he turned over his favorite gray box, removed a small plastic guard, and revealed the mythical expansion port. What was it for? What would Nintendo do with it?
The expansion port on the NES wasn’t really used for anything, at least in the US market. Even in the homebrew scene, there’s only one stalled project that allows the NES to connect to external devices. To fulfill [Trap]’s childhood dream, he would have to build something for the NES expansion port. Twitter seemed like a good application.
The first step towards creating an NES Expansion Port Twitter thing was to probe the depths of this connector. The entire data bus for the CPU is there, along with some cartridge pass-through pins and a single address line. The design of the system uses a microcontroller and a small bit of shared SRAM with the NES. This SRAM shares messages between the microcontroller and NES, telling the uC to Tweet something, or telling the NES to put something on the screen.
Only a single address pin – A15 – is available on the expansion port, but [Trapper] needed to read and write to a certain section of memory starting at $6000. This meant Addresses A13 and A14 needed to be accessed as well. Fortunately, these pins are available on the cartridge slot, and there are a number of cartridge pass-through pins on the expansion connector. Making a bridge between a few pins of an unused cartridge solved this problem.
From there, it’s just a series of message passing between a microcontroller and the NES. With the help of [Trap]’s brother [Jered] and a Twitter relay app running on a server, this NES can actually Tweet. You can see a video of that below.
Continue reading “Tweeting From The NES Expansion Port”
The most common way of programming AVR microcontrollers is the In System Programming port. That little six-pin header with MOSIs and MISOs coming out of it will program every AVR you’ll ever come across. The ISP does have a downside – fuses. Set your fuses wrong, and without a High Voltage Serial Programmer, your chip is bricked. [Dilshan] designed his own HVSP that’s less expensive than the Atmel STK500 and has a nice GUI app.
Instead of following in the footsteps of the USBtinyISP, [Dilshan] is using a PIC18F as the main microcontroller in the programmer. This chip was chosen because of its built-in USB functionality. Because the High Voltage part of a HVSP operates at 12V, actually providing that voltage needed to be taken into consideration. For this, [Dilshan] is using standard 78xx regulators with an 18V input.
The app to control this programmer does everything you would expect, including all the usual AVRdude commands. A great build, and just what we need to reset the fuses on a few dozen chips we have sitting around.
Generating video signals with a microcontroller or old CPU is hard if you haven’t noticed. If you’re driving even a simple NTSC or PAL display at one bit per pixel, you’re looking at a minimum of around 64kB of RAM being used as a frame buffer. Most microcontrollers don’t have this much RAM on the chip, and the AVR video builds we’ve seen either have terrible color or relatively low resolution.
Here’s something interesting that solves the memory problem and also generates analog video signals. Yes, such a chip exists, and apparently this has been in the works for a very long time. It’s the VLSI VS23s010C-L, and it has 131,072 bytes of SRAM and a video display controller that supports NTSC and PAL output.
There are two chips in the family, one being an LQFP48 package, the other a tiny SMD 8-pin package. From what I can tell from the datasheets, the 8-pin version is only an SPI-based SRAM chip. The larger LQFP package is where the action is, with parallel and SPI interfaces to the memory, an input for the colorburst crystal, and composite video and sync out.
After looking at the datasheet (PDF), it looks like generating video with this chip is simply a matter of connecting an RCA jack, throwing a few commands to the chip over SPI, and pushing bits into the SRAM. That’s it. You’re not getting hardware acceleration, you’re going to have to draw everything pixel by pixel, but this looks like the easiest way to generate relatively high-resolution video with a single part.
Thanks [antibyte] for the tip on this one.
Provided you have an NTSC-compatible TV you can build yourself a really inexpensive spectrum analyzer. From there you just need one trivial piece of hardware to complete this build. [Bruce Land] has come up with a spectrum analyzer that shouldn’t cost any more than $5, if that’s what’s been keeping you from adding this tool to your workbench!
The spectrum analyzer is based on a PIC32 microcontroller which was previously proven in his Oscilloscope project. [Bruce] has managed to squeeze quite a bit out of this robust chip; the spectrum analyzer has 450 kHz bandwidth and runs a 256 Hz TV display and can output over 30 updates per second. The microcontroller runs the Fast Fourier Transform (FFT) to do calculations, with great results.
[Bruce] notes that the project was based on TV framework from another project, and that the FFT was added on top of that. Be sure to check out the source code on the project site if you’ve been on the hunt for an inexpensive spectrum analyzer, and if you need something with more processing power but only slightly more money, check out the FFT that runs on the Raspberry Pi’s GPU.
[Maurice] recently built a clock that draws the time (Google Doc) on a white board. We’ve seen plenty of clock hacks in the past, and even a very similar one. It’s always fun to see the different creative solutions people can come up with to solve the same problem.
This device runs on a PIC16F1454 microcontroller. The code for the project is available on GitHub. The micro is also connected to a 433MHz receiver. This allows a PC to keep track of the time, instead of having to include a real-time clock in the circuit. The USB connector is only used for power. All of the mounting pieces were designed in OpenSCAD and printed on a 3D printer. Two servos control the drawing arms. A third servo can raise and lower the marker to the whiteboard. This also has the added benefit of being able to place the marker tip inside of an eraser head. That way the same two servos can also erase the writing.
The communication protocol for this systems is interesting. The transmitter shows up on [Maurice’s] PC as a modem. All he needs to do to update the time is “echo 12:00 > /dev/whiteboard”. In this case, the command is run by a cron job every 5 minutes. This makes it easy to tweak the rate at which the time updates on the whiteboard. All communication is done one-way. The drawing circuit will verify the checksum each time it receives a message. If the check fails, the circuit simply waits for another message. The computer transmits the message multiple times, just in case there is a problem during transmission.
Sometimes it is a blessing to have some spare time on your hands, specially if you are a hacker with lots of ideas and skill to bring them to life. [Matt] was lucky enough to have all of that and recently completed an ambitious project 8 months in the making – a Non-Arduino powered by the giant of computing history – Intel’s 8086 processor. Luckily, [Matt] provides a link to describe what Non-Arduino actually means; it’s a board that is shield-compatible, but not Arduino IDE compatible.
He was driven by a desire to build a single board computer in the old style, specifically, one with a traditional local bus. In the early days, a System Development Kit for Intel’s emerging range of microprocessors would have involved a fair bit of discrete hardware, and software tools which were not all too easy to use.
Back in his den, [Matt] was grappling with his own set of challenges. The 8086 is a microprocessor, not a microcontroller like the AVR, so the software side of things are quite different. He quickly found himself locking horns with complex concepts such as assembly bootstrapping routines, linker scripts, code relocation, memory maps, vectors and so on. The hardware side of things was also difficult. But his goal was learning so he did not take any short cuts along the way.
[Matt] documented his project in detail, listing out the various microprocessors that run on his 8OD board, describing the software that makes it all run, linking to the schematics and source code. There’s also an interesting section on running Soviet era (USSR) microprocessor clones on the 8OD. He is still contemplating if it is worthwhile building this board in quantities, considering it uses some not so easy to source parts. If you are interested in contributing to the project, you could get lucky. [Matt] has a few spares of the prototypes which he is willing to loan out to anyone who can can convince him that they could add some value to the project.
Continue reading “Non-Arduino powered by a piece of Computing history”