VS Electronics and Embedded Development

I’ve finished writing and finalizing my first disassembler, for the AVR architecture. I discovered that avrdisasm, avrdasm, disavr, and even dasmavr names were all taken, so I went eventually went with vavrdisasm.

vAVRdisasm is a finished and working AVR disassembler. It should work on most *nix systems, as well as a Cygwin environment.

Here is an excerpt from the README that gives a brief summary of its functionality:
vAVRdisasm is an AVR program disassembler. It supports all 136 AVR instructions as defined by the Atmel AVR Instruction Set, revision 0856E-AVR-11/05.

This single-pass disassembler can handle Atmel Generic, Intel HEX, and Motorola S-Record formatted files containing valid AVR program binaries.

vAVRdisasm features a handful of formatting options, including:

• Printing the instruction addresses alongside disassembly, enabled by default
• Printing of the destination comments of relative branch/jump/call instructions, enabled by default
• Ghetto Address Labels (see “Ghetto Address Labels” section)
• .DW data word directive for data not recognized as an instruction during disassembly.

The heart of vAVRdisasm is its “Ghetto Address Labels” feature. With this feature, vAVRdisasm can produce directly assemble-able disassembly that can be easily modified without having to manually format the disassembly (i.e. adjusting relative branch/jump/call distances). This means you can disassemble a program, add, remove, and modify any instructions, and directly re-assemble it.

See the vAVRdisasm page for a complete description of vAVRdisasm, its usage, and the links to download the disassembler.

I’ve just released the first version of this tiny library that’s not really a library. It’s a set of utility functions to help parse Atmel Generic, Intel HEX, and Motorola S-Record formatted files. This can be very convenient in disassembler, assembler, binary file converting, and similar projects. Best of all, it’s public domain, meaning it’s 100% free. The interface for this “library” is fully documented, and you’ll find that the implementing it into C/C++ projects is very easy (just compiling in two files per format).
To download “libGIS”, view its documentation, or learn more about it go to http://www.frozeneskimo.com/electronics/libgis-free-atmel-generic-intel-hex-and-motorola-s-record-parser-library/.

I have several other projects to work on this Winter break. Not in any specific order, they include building that Xilinx FPGA/CPLD download cable to flash my miniLA (I recently finished assembling the miniLA), wrapping up my AVR disassembler and writing the PIC one, writing an ATMega32 driver for the ADS7841P SPI ADC, building this to flash AVRs from my Mac Mini, and revising my ESNB project board. I probably won’t get through it all, though…

The other night I came across a 7-segment LED display and decided to interface it to a parallel port. I added a button as well. The 7-segment LED lines (each leg of the display plus the dot LEDs) are connected to the parallel port data pins (D0-D7). I have the button hooked up to nInitialize (bidirectional) and nAck (input only). I’ve never done a parallel port interface project before, so I figured this would be a good start.

I wrote some quick prototype software in Perl, of all languages. It requires Device::ParallelPort for parallel port access, which for some reason didn’t work well with writing data bytes, so I had to resort to doing everything bit by bit in software. For the switch, I bring nInitialize down, and poll nAck for changes. When nAck goes low, the switch has been pressed.

__(’Read the rest of this entry »’)

Yesterday I received the miniLA kit (mini logic analyzer, see more at http://minila.sourceforge.net) from g1powermac.
Some info from a previous post:
“”g1powermac” from the ##microcontrollers IRC channel on Freenode has organized a group PCB and components buy of the “miniLA” mini logic analyzer, freely available at http://minila.sourceforge.net/ . This will be an invaluable tool for FPGAs and CPLDs, which I’m looking to getting into. The device itself has some very impressive features: 32 channels, 100MHz, 128Kb memory for *each* channel, compatible with 3.3v and 5V, and it is of course free. The price will probably end up being under $70 as well. There is also a simple parallel port to USB converter designed for the miniLA, and it looks relatively easy to build.”

Currently there are none available to order, but check periodically because a second run with an improved board is coming along soon.

Here is a picture of it unassembled:

Most versions of this story are vaguely correct:
http://www.signonsandiego.com/news/education/20060620-9999-1m20whizkid.html or http://securitypronews.com/news/securitynews/spn-45-20060620YoungProgrammerDevelopsSecuritySolutions.html

But don’t you hate when you get crap like this?: http://www.theinquirer.net/?article=32543

“Already, a manufacturer has created a working prototype based on Sergeev’s design and he is trolling around the tech fairs flogging his ideas.” Yeah, I love those juicy insults.
There was one (rather big) mistake in the original article: there is no hardware manufacturer “producing my device”. In fact, I designed the pcb schematic and board entirely in CadSoft EAGLE Lite. The pcb got printed/etched by Advanced Circuits ($83 with 1 day turn around for 3 prototype boards), and I assembled the boards myself with parts either sampled from the companies (Microchip, Philips, etc.) or from Mouser and Digikey. As for specifics: the board is based on a Philips LPC2148 ARM microcontroller, and two Microchip ENC28J60 ethernet controllers. RJ-45 jacks are actually Magjacks with integrated magnetics. Other goodies include a serial port, JTAG header, and of course basic voltage regulation.

You know what I loved the most, though? This: “where it probably beat off opposition from another kid’s ant farm and the display ‘My dad’s a scientist’.” As for my dad, well, he’s actually a high-level database programmer (FoxPro), so his expertise does not apply and could not have applied to the science fair project what-so-ever. Writing firmware for a microcontroller (an ARM one by Philips, in my case) is usually low-level C or assembly (mostly C in my case), and includes driving interfaces like UART or SPI (which I do in my project), not query and select statements to a db. Not to mention the whole other side of the project: digital electronics and pcb board design. So yes, I did well in science fair… why? because I honestly built, wrote, and conceived my project by myself, and the judges obviously judged the way they did after they got to know me well enough to realize that this was true. What explains my experience in these subjects? Take it or leave it, but it’s all self-taught. Also, GSDSEF (Greater San Diego Science and Engineering Fair) is hardly your ant-farm project fair. The senior divison projects, particularly, go through some pretty extensive screening sessions to keep the bullshit projects out. A good handful of the projects progress into bigger fairs, patents, or even to the market.

__(’Read the rest of this entry »’)

I wrote a simple driver a few nights ago for the single DC motor driver FAN8082 by Fairchild. This is a very straight-forward 8 pinned IC. The motor is controlled by two inputs, and can be set to spin forward, reverse, or brake. Today I setup a breadboard on the car and wired the microcontroller circuitry to the 4 AA batteries housed underneath the car. After some experimentation with the motor driver, I gave the DC motor its own dedicated 9V supply

Yes it spins very fast (relatively speaking to the stock setup), but I think it will work out fine. The DC motor driver is actually very neat because you can control the speed of the motor by changing the voltage on the Vctl pin (I left it unconnected).

Here is a short video of the motor spinning forwards and backwards, toggled by a simple button connected to the microcontroller: video

Well, my two days worth of figuring out AVR timers and PWM produced a very small and clean servo driver. Today my two 5g servos arrived and I hooked up one of them to the chip. I setup a test program and it worked out of the box. If you care to see it, just watch this:

http://www.frozeneskimo.com/electronics/wp-content/uploads/Videos/avrservo.avi

Like I said in the previous post, the RF receiver will pick up junk data when the transmitter isn’t transmitting anything. This means that you need some sort of encoding or decoding method of the data to differentiate from junk in the air and actual data. This can be easily done through Manchester Encoding, which was used in Ethernet until 100Base-TX came along.

Manchester Encoding actually halves the data rate. The encoding is extremely simple, though. If you have a 1 in your data, it will be followed by a 0, if you have a 0 in your data, it will be followed by a 1. So the ASCII letter ‘A’, or 0100 0001 in binary, would be encoded as 01 10 01 01 01 01 01 10.

This allows for easy error checking- if a bit in the received data is not followed by its inverse, you know that the data is invalid. In other words, there are an equal number of ones and zeroes in the Manchester encoded data. Of course, there is that small chance that one byte of the random junk floating around is actually properly encoded, but these bytes can be avoided with a basic protocol on top of the encoding (possibly with a checksum).

__(’Read the rest of this entry »’)

Those RF units I was talking about in the previous post arrived today. Since the transmitter and receiver are actually separate devices, I ordered two sets at different frequencies for the robot and computer to communicate. One set is 433MHz, the other set is 418MHz.

These things are very small, and after playing with them, they seem to be on par for $12 per transmitter and receiver pair–even though they have a maximum speed of 2400 bps. I hooked up the transmitter to an AVR microcontroller (ATTiny2313) that was sending A’s straight out of the UART port. I hooked up the receiver to max232 serial module which was connected to my computer through a serial->USB converter. When the transmitter isn’t transmitting, the receiver picks up junk data that is floating around. With the AVR sending A’s though, I could see a fresh, clean stream of A’s coming in with the transmitter and receiver about 10 inches apart. It simply worked out of the box. More distance between the transmitter and receiver required some sort of an antenna, so I just plucked a 5 or something inch wire with the transmitter, and the receiver picked up the A’s from all the way across my room (it probably could have picked up from even further).

Here are some pictures of the devices:

__(’Read the rest of this entry »’)

Well, I’ve decided that I wanted to build a basic robot based on a toy car I recently dissected. I took out all of the cheap RF stuff in there, and left the back DC motor and gear box that gives it two-wheel drive. I also modified the front wheels so that they had complete left and right freedom of motion (the radio controlled toy car had this interesting steering mechanism that had only let the wheels point straight or to the right).

What do I have left? A simplified car frame with two-wheel drive, 4 AA battery compartment housing, an on-off switch, and front wheels that can’t steer. The only thing to do mechanically is to add steering to the two front wheels, which I’ll probably do using Ackermann Steering, kind of like what cars use. I originally thought of using a gear rack, and doing a simple rack and pinion model with a stepper motor, but later I found out that the easiest (and cleanest) way is to use a servo motor. Since the two front wheels have a connecting bar that keeps the wheels parallel, I only need to focus on moving this bar left or right. A stiff wire connected from the horn of a servo motor to this bar (or a wheel) would do exactly this. Besides, servos remember their position, so all I’ll have to do is send it the angle I want the wheels to be at. I ordered two cheap 5g servo motors from ebay.

__(’Read the rest of this entry »’)