AVR AT90S8515 getting started code.
Getting Started Version 5.0
Dontronics Pages Duplicated:
Dontronics goes to great lengths to provide new and interesting material
for visitors. It has been found in recent months that other Webmasters
are duplicating material that has already been presented here. This may
be with, or without the permission of the original Author. If you see a
copy of the following files or pages, you will know Dontronics was responsible
for the initial release, and the others are simply copies. It would
be nice if these people did their own ground work, and put in the time
to get new material, and not benefit from the time and effort that Dontronics
has already invested to make this a better site.
AVR AT90S8515 getting
started code. by David VanHorn Original Copy 4-Sep-98
PIC Source Book/Disk
by Scott Edwards Electronics. Free public release. Original Copy 3-Apr-98
A Free Programmer
for the: 90S2313, 90S2323, 90S2343, 90S4414,
90S4434, 90S8515, 90S8535, and 90S2333.
Finally, it's done. Version
4.0.
The biggest changes are:
The elimination of the old linear buffers. They've been replaced with variable length circular buffers. I made them variable length, in preparation for a dynamic allocation scheme, but I'm not sure at this point if it's worth implementing. That's part of what I'm exploring for version 5.0
The implementation of a language interpreter, reading commands with optional parameters from EEPROM. This also means that the program in EEPROM is alterable, so this is a starting point for a robot or other device that could learn . The language only has four commands implemented, but I didn't want to make it too complicated at first. It is trivially easy to add your own commands, and they can be simple procedures, or they could alter the behaviour of other parts of the system. It's entirely up to the user. Currently implemented commands: Delay (ms), Servo position (servo) (position), Loop, and Skip (commands to skip) I didn't implement variables, but adding a few fixed variables would be trivial. I'm looking for a more flexible scheme that would allow me to allocate variable memory dynamically, but again, that's something for 5.0
There are many cleanups and improvements in the other routines as well. The hardware assignments are easier to deal with, and I've pulled in all the rom and ram allocations to the routines that use them, rather than having them in tables.asm and equates.asm
It's still fast, and it uses just over half the rom (as configured) and less than half the ram (again, as configured) In a real application, you probably allocate only a small subset of the buffers I have in this demo, but I wanted to make it visually busy , so I am using all eight servos (one is controlled by the interpreted program, one is controlled by the random generator, and the rest simply ramp), a VFD display (scrolling the top and bottom lines in opposite directions within the same buffer), and LCD display with different text, but scrolling similarly, and a Quick brown fox output on the serial port, plus morse code output with randomized messages.
Given all that, the CPU is
still nearly idle :)
As it sits, this application could be used to control a small robot, or radio-controlled device. It initializes the chip, and provides code for reading the switches and lighting the LEDs. It handles the on-chip watchdog timer, and it is trivially easy to add an external watchdog. It includes a 19 bit PseudoNoise generator, useful for encryption, or making coin toss decisions. It provides buffered, interrupt-driven serial communications on the uart, just point at the transmit string and call the routine.
It provides eight R/C servo output channels, each programmable from 1-2mS which corresponds to full travel in each direction. Also, the frame rate is programmable from 0-255mS, with 20 being typical. Servo outputs can also be disabled under program control.
It provides a stepper motor output for a unipolar stepper motor (6 wire type). This output can be selected as full or half-step, forward, reverse or stop, and 0-255mS per step.
(You will have to provide a proper electrical interface to these devices, I was only concerned with the software aspect. The AVR will not drive any stepper motor directly, and I would reccomend at least a buffer or 1k resistor in the servo outputs to protect the chip)
All of this activity is interrupt driven, leaving a large amount of CPU time available for other tasks. Each interrupt vector is handled. In the case of unused vectors, they contain code to turn off that interrupt. If you decide to use an int that is currently unused, just replace my turnoff code with your int handler. I like having the turnoff code in place, in case an int mask gets munged or I goof in the main code.
In this application you have working example code for properly initializing
the chip, setting the stack, using the watchdog timer, Timer 0, and timer
1, the baud rate generator and uart, and all the I/O ports as input or
output. You also have working examples of the features availalable in the
assembler, using equates, defines, and inline math to set variables dependent
on other variables. If you've never written in assembler before, you can
learn a lot from this code. If you haven't worked with the 8515 before,
then this code will get you past some of the parts that are a little difficult
to pick up from the manual. If you're doing projects regularly with the
8515, then this may give you a worthwhile template to begin a project with,
having most of the system up and running.
Here's a little addititon, I put some diagnostic bits in all the ISRs, such that whenever an ISR is executing, a port pin is high. Each ISR is identified by the number of pulses before the pin stays high. T0, because it executes frequently, just goes high. Others have from 1 to 11 pulses in front of the ISR so that I can identify exactly which ISR fired. (In some cases, the pulses take longer than the ISR itself!)
The vertical cursors show 1mS, which is a T0 interval. The top trace is an RC servo pulse, in between zero and full scale. The bottom trace shows how much time is eaten up in all the ISRs. As you can see, it isn't much. I'd guess that more than 90% of the processor cycles are available for tasks in the idle loop.
Although the T0 ISR is kind of long, very little of it actually gets executed in any given pass, so it ends up much shorter than you'd think. The wide looking one is the serial UDRIE which has a lot of pings in front of it.
| Home | Products | Prices | Site Map | Order | Contact | What's New | Books | Free Files | Links | FAQ |
_
Copyright © 1996-2005 Dontronics
 |
 |