VS Electronics and Embedded Development

While wordpress is nice as a blog, it feels like a crude content management system for electronics projects that might have many images (pictures, schematics) and extra files (code, schematics). Also, I never liked the size wordpress scaled uploaded images to, or where it stored the images (although there might be a third party plugin or modification to better customize this process), so I’ve always been reluctant to upload images and then manually scale them to my preferred size with “convert.”

Recently I’ve launched a development wiki powered by DokuWiki. It’s not really a wiki, since I’m the only one that can edit it, but I think it will work as a good backend for my project site. You can find the development wiki here: http://dev.frozeneskimo.com/.

I’ve already moved most of the projects from my blog to my wiki, and even added a new one (the Parallel SRAM one). This blog isn’t going anywhere, I think it’s great for news/project updates and the like, but the actual project content will be stored on the wiki.

A typical parallel SRAM chip has always been on my list of things-to-interface-with so I decided to take up this mini-project a little while ago. It’s pretty straightforward. I’ve put the explanation, schematic, and source code for interfacing an ATMega32 to a 32 kilobyte SRAM chip, you can find it here: http://dev.frozeneskimo.com/embedded_projects:parallel_sram.

And here’s a picture (can’t forget it):
.

This is the release of the second network tool, deja-packet, that I promised in my previous post. Here is the project description I submitted to Freshmeat:
“deja-packet transmits raw packets through a specified interface. In pcap file mode, deja-packet transmits user-selected packets from a libpcap capture file (such as one created by Ethereal/Wireshark, or tcpdump). In raw file mode, deja-packet transmits the raw contents of a file as one whole packet, and will exit immediately after the attempted transmission is complete (allowing deja-packet to be easily used in a script).”

‘deja’ like ‘deja-vu’, like, you’ve seen it before? Like you’ve seen the packet before? Get it? Yeah I know it’s hilarious.

See it here: http://www.frozeneskimo.com/electronics/network-tools/.

Recently I wrote a small network tool that I wanted release freely online. But, I didn’t know where to put it, since this is technically an electronics/embedded-development blog (not really for desktop programs). But, I don’t really have any other active development blogs. Oh well, I thought, and I decided to add a network tools section to this blog so I can post any other network tool programs I release in the future (I have one more coming for sure).

The first program released on the Network Tools page is pcap2c, which converts a pcap capture file to a C source file, or more specifically, reformat packets that are stored in a pcap capture file to more easily accessible raw unsigned char arrays. In some of the low-level network work I’ve been dealing with I’d had to retransmit certain packets I captured in Ethereal/Wireshark, and well, I didn’t really have a clean way to do it but extracting it of the pcap capture file, and rearranging it as a C array with perl. I would then compile the raw packet into a small PF_PACKET sockets program that could retransmit it down a particular interface. pcap2c greatly simplifies the process of extracting the packets, and will work with libpcap formatted capture files (Ethereal/Wireshark, tcpdump, etc.).

The next “network tool” that I will have available will read in all the packets from a pcap capture file in memory and allow you to retransmit any of them down an interface on demand. It’s basically a simple debugging tool that retransmits packets you may later want to observe as they traverse the network (watching them get routed, bridged, etc.). Future versions may allow you to edit the packet on the fly and automatically recalculate the IP and TCP checksums, but that’s down the long road, and there are already many projects in that niche.

Link to Network Tools section and pcap2c: Network Tools.

Any suggestions or comments are welcome at: vsergeev at gmail.

Besides a small bug fix, vAVRdisasm now can format data constants in binary and decimal, in addition to the default hexadecimal base. The base representation can be selected with the - -data-base-… options.

See the vAVRdisasm page for more information and links to download the new version.

This post may hold a striking resemblence to a previous post, but don’t worry, it’s no deja-vu. I figured I’d also write a PIC disassembler, based on my previous AVR disassembler. The AVR disassembler’s flexible codebase makes it easy to implement other architectures with instruction opcodes of 16-bits or less. This disassembler features everything the previous one did, but also with a few new handy features.

vPICdisasm is a finished and working Mid-Range PIC 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:
vPICdisasm is an PIC Mid-Range MCU family program disassembler. It supports all 35 PIC instructions, plus the two deprecated ones (”option” and “tris”) as defined by the PICmicro Mid-Range MCU Family Instruction Set, document DS31029A.

This single-pass disassembler can handle Intel HEX8, and Motorola S-Record formatted files containing valid PIC program binaries.

vPICdisasm features a handful of formatting options, including:

• Printing the instruction addresses alongside disassembly, enabled by default
• Ghetto Address Labels (see “Ghetto Address Labels” section)
• Literal operands represented in either hexadecimal, binary, or decimal bases, and as ASCII in an assembly comment
• Data word directive for data not recognized as an instruction during during disassembly

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

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

Too good to be true? I ordered them anyway:

http://www.neonixie.com/store/product_info.php?cPath=24&products_id=631sdesc=Breadboard%2C+830+test+points+Model+%23+

I needed the INV-TH-202 inverter for a graphics LCD I bought recently from ebay.

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…