This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. (gnu.txt)
You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
Previously I had done some small projects with the PIC 16F84 micro from www.microchip.com. There were pages and pages of PIC micros in Digkey's catalog, but only two basic parts that are flash-reprogrammable (the others are one-time-programmable). Digikey had a whole page of Atmel AVR parts, and they were ALL flash programmable. They were about half the cost of the comparable PIC parts, and they went from 8 pin packages on up to 60 plus.
When I decided to experiment with the Atmel AVR chips I selected the affordable Dontronics DT-006 board to start with. I had tried a couple of Don's boards before when I was experimenting with the PIC micro. Don ships these boards and kits worldwide via small airmail packages. Mine arrived in a week. (I have no afiliation with Dontronics other than being a satisfied customer.)
There is a free demo version of a Basic Compiler from MCS Electronics (www.mcselec.com) called BASCOM for the AVR on Don's site that works with the board, and this is an excellent starting point. All that is required to get started is a pc, some downloaded free documentation and software, a parallel cable, a wall transformer and connector to supply power to the board, and the assembled DT-006 board, which includes the AT90S2313 processor. This complete computer on a chip is a good starting point with 15 I/O pins and 2K bytes of flash programmable program space. It has many other features, too numerous to cover here.
I connected a $7US 2x16 LCD (Liquid Crystal Display) (see www.flat-panel.com, www.eio.com, www.allelectronics.com, www.bgmicro.com, www.digikey.com and others) to the board using 6 I/O pins, configured the BASCOM for the pins I used, and the display worked immediately. I connected a Dallas Semiconductor DS18S20 (www.dalsemi.com) 3 pin direct to digital temperature sensor, and the BASCOM support for 1-wire was used to communicate with the chip. That also worked within a few minutes. BASCOM-AVR was great for testing the system and building confidence in the hardware. It is simple to use and downloads the chip directly with its own loader. The free version is limited to 2K of code, which fits the AT90S2313 perfectly, and a full version without limits is around $70US.
Compiled Basic has a tendency to fill up the chip a bit faster than Assembler or carefully crafted C. I needed to get more code to fit in the AT90S2313 and I somewhat prefer C for this type of application, so I researched tools on the net and next tried Imagecraft ICCAVR (www.imagecraft.com). This worked well, though the built-in loader was not DT-006 compatible (at that time) and I continued to use the BASCOM loader. The BASCOM loader would not (at the time) handle the hex output from ICCAVR, so I wrote a translator. (The BASCOM loader on the demo version at that time would not correctly interpret out-of-order or gapped hex input). (There is excellent support for both BASCOM and ICCAVR on the net, and it is my understanding that the paid version of BASCOM does not have this loader problem, and that a future version of ICCAVR will have direct DT-006 loading support).
When the ICCAVR demo timed out (in 30 days) I was faced with paying $200 for a compiler locked to one CPU. My current use is for hobby projects, so I decided to evaluate a free compiler -- avr-gcc.
Firing up avr-gcc on windows 98 turned out to be fairly simple - the only hard part was figuring out which installation procedure to follow and setting up the makefile. The actual effort was essentially copying a directory tree and running one install script. The makefile was somewhat complex, but complete examples are available that can be used with minimal editing. See the GCC section below for details.
AVR-GCC is impressive - it produced 15% smaller code (optimized) than the demo (unoptimized) ICCAVR. It produced hex that was compatible with the BASCOM loader, so my translator was not needed. Still, I wanted to have a programmer that would run from the makefile.
A search of the net didn't find a programmer that would handle the DT-006 and meet my requirements. So I added a few lines of code to the hex reformatter that I already had, and voila, a programmer. Now I can compile and reload the AT90S2313 chip in five to ten seconds with two keystrokes. (I use a batch file, m.bat, to run make, so 'm [return]' does the job).
I noted the variety of different connection schemes used to program the AVR's ISP from the parallel port, so I decided to make this programmer's input/output extremely configurable.
| Option | Action |
| -h | Help = Display Options List |
| -s | Read chip signature |
| -r | Read flash program memory to stdout |
| -m | Read eeprom data memory to stdout |
| -c | Clear chip memory (both eeprom and flash) |
| -p hexfile | program flash memory after clearing chip |
| -P hexfile | program flash memory without first clearing chip |
| -e hexfile | program eeprom memory |
Standard Output (stdout) may be redirected to a file using the usual redirection commands:
| Option | Port Address |
| -0 | use parallel port LP0 0x3BC |
| -1 | use parallel port LP1 0x378 (default) |
| -2 | use parallel port LP2 0x278 |
Each of the four bits requires a bit position address, and an invert sense. The configuration is expressed as an 8 character string:
| Character | Range | Description |
| 1 | 0..B | Reset bit address |
| 2 | 0..1 | Reset invert |
| 3 | 0..B | Clock bit address |
| 4 | 0..1 | Clock invert |
| 5 | 0..B | Master Out Slave In bit address |
| 6 | 0..1 | Master Out Slave In invert |
| 7 | 3..7 | Master In Slave Out bit address |
| 8 | 0..1 | Master In Slave Out invert |
The PC parallel port is the master, the chip is the slave.
| Bit | Port | Port | LPT | PC Printer |
| Addr | Addr | Bit | Pin | Signal Name |
| 0 | base+0 | 0 | 2 | Data Output LSB (0=low, 1=high) |
| 1 | base+0 | 1 | 3 | |
| 2 | base+0 | 2 | 4 | |
| 3 | base+0 | 3 | 5 | |
| 4 | base+0 | 4 | 6 | |
| 5 | base+0 | 5 | 7 | |
| 6 | base+0 | 6 | 8 | |
| 7 | base+0 | 7 | 9 | Data Output MSB |
| 8 | base+2 | 0 | 1 | Strobe Output (0=high) |
| 9 | base+2 | 1 | 14 | Auto fd xt Output (0=high) |
| A | base+2 | 2 | 16 | Init Output (1=high) |
| B | base+2 | 3 | 17 | Select Output (0=high) |
| 3 | base+1 | 3 | 15 | Error Input (high=1) |
| 4 | base+1 | 4 | 13 | Select Input (high=1) |
| 5 | base+1 | 5 | 12 | Paper Error In (high=1) |
| 6 | base+1 | 6 | 10 | ACK Input (high=1) |
| 7 | base+1 | 7 | 11 | Busy Input (high=0) |
The Inversion controls allow each bit to be inverted, or not as required by the hardware configuration. The states reported above are nominal uninverted.
| Value | Effect |
| 0 | do not invert, logic as shown above |
| 1 | invert, logic reverse of table above |
PC Parallel port information obtained from various sources including the Linux Documentation Project Parallel IO Port Programming Mini-HOWTO (www.linuxdoc.org).
| pre | --definit AA | set bits addressed 0-7 per AA (0 is LSB) |
| pre | --definit AAB | in addition to AA, set bits 8-B per B (8 is LSB) |
| post | --definit AABCC | in addition to AAB, set bits 0-7 per CC |
| post | --definit AABCCD | in addition to AABCC, set bits 8-B per D |
ABCD above denote hex characters [0..9,A..F]. The default values for the above are to put all lines to the high state, equivalent to "--definit FF4FF4".
wppisp --kanda %1 %2 %3 %4 %5 %6 %7 %8 %9
| -W | loop testing RESET |
| -X | loop testing CLOCK |
| -Y | loop testing MOSI |
| -Z | loop testing MISO |
Intel Hex format starts each line with a colon ":". It contains address, type, data, and checksum in ascii hex (0-9,A-F). This program verifies the checksum, aborting if an error is detected. Since the entire file is read in before any programming is done, a bad file will not result in a partial program - it will quit before beginning the cycle.
Motorola hex format starts with 'S' on the first character of each line. Each line contains type, address, data, and checksum. Motorola hex S-Records are not currently supported.
Generic Hex format is an address followed by data bytes. The first character on the line must be a valid hex character, or the line will be ignored. Nonhex characters on the line will cause termination of the program cycle. The data bytes can be space separated or not. If they are not space separated they must be two characters per byte. If they are space separated they can be one or two characters per byte.
| Option | Details |
| -d | Toggles debug printing On or Off |
| -C | Recalibrates internal millisecond delay against system clock |
| -D | Displays 10 second count using internal millisecond clock for verification |
| -S | adds a 1 millisecond delay for each output bit (very slow) |
This program does direct port I/O to the parallel port. This behavior is not permitted in operating systems that improve robustness by limiting direct access to I/O. This includes Unix, Linux, Windows NT and 2000. In these systems it is necessary to write special priveliged programs to interact with the device hardware. These are generally referred to as device drivers. There are some device drivers for Windows NT (and possibly 2000) that will essentially open up the hardware access to a program, and allow the program to directly access the hardware, in this case the parallel port. This should work for this program, but has not been tested.
The more proper way to do I/O to the parallel port in these systems is to use a device driver that translates the requests and performs them on behalf of the program. This requires changes to the program. Perhaps in a future upgrade.
Systems like DOS and Windows 9x do not protect the hardware. This is one reason they crash as often as they do -- it is possible for any program do dangerous things, and not do them right. It makes it easy to write programs like this one, but makes the system less reliable.
Alan Biocca earned Bachelor of Science in Electrical Engineering and Master of Science in Computer Science degrees from the University of California at Berkeley. He has worked in microprocessor and computer controls and data acquisition software and hardware for more than 20 years at Lawrence Berkeley National Laboratory (www.lbl.gov).
Past projects include development of the mirror positioning control system for the segmented primary mirror in the Keck Ten Meter Telescope (www2.keck.hawaii.edu:3636) and the Data Acquisition and Control System for the Gammasphere Detector Project (www-gam.lbl.gov). He is currently leading the Accelerator Controls group at the Advanced Light Source (www.als.lbl.gov), a third generation Synchrotron Light Source providing soft and hard x-rays for experiments in materials science including such things as improving magnetic storage and integrated circuit manufacturing.
His hobbies include Amateur Radio where he holds the Extra Class License callsign WB6ZQZ.
He can generally be reached via email: Alan.Biocca@usa.net.