151 |
kaklik |
1 |
AVRcam Release 1.4
|
|
|
2 |
1/16/2005
|
|
|
3 |
|
|
|
4 |
Whats New in v1.4:
|
|
|
5 |
-Greatly improved the issue where the AVRcam would potentially
|
|
|
6 |
lock up in particular situations (especially after lots of frame
|
|
|
7 |
dumps). This was due to a combination of bugs, which have all been fixed:
|
|
|
8 |
-turned off interrupts in certain critical sections that were missed
|
|
|
9 |
previously
|
|
|
10 |
-only allow PCLK to be piped into timer1 when needed (i.e., when dumping
|
|
|
11 |
a line or tracking a frame).
|
|
|
12 |
-allowed the main executive to check both the fast event bitmask as well
|
|
|
13 |
as the normal event queue on each pass of the main executive
|
|
|
14 |
|
|
|
15 |
I'll be curious to hear if this has completely fixed the issue (I haven't
|
|
|
16 |
seen it happen after ~500 frame dumps, but the real test is when
|
|
|
17 |
others try it :-). Also note: an input voltage below 6 volts will
|
|
|
18 |
cause the system to work sometimes and lock up others. The input voltage
|
|
|
19 |
regulator really wants to see a 6V minimum. I had drained
|
|
|
20 |
8 AA NiMH batteries down to where they were only providing ~4.8 V at the
|
|
|
21 |
input. The system worked for a little while, and then started locking
|
|
|
22 |
up. I immediately changed batteries and everything was fine.
|
|
|
23 |
|
|
|
24 |
-Improved how the colorMap gets written to EEPROM. Now, before
|
|
|
25 |
each byte in the colorMap is written to EEPROM, a check of the
|
|
|
26 |
current value in EEPROM is made to see if the old value matches
|
|
|
27 |
the new value. If so, the write is skipped. Also, after a value
|
|
|
28 |
is written, it is read back to ensure that it is correct, and
|
|
|
29 |
will re-write up to three times if needed.
|
|
|
30 |
|
|
|
31 |
-Moved the UART rx ISR to the UartInterface.c file, instead of having
|
|
|
32 |
it in its own UartInterfaceAsm.S file. The ISR is in C now.
|
|
|
33 |
|
|
|
34 |
-Added a revision history to each source file so that people can
|
|
|
35 |
see the changes on a per-version basis.
|
|
|
36 |
|
|
|
37 |
|
|
|
38 |
---Misc Info about AVRcam---
|
|
|
39 |
|
|
|
40 |
* The AVRcam source files were built using the WinAVR distribution
|
|
|
41 |
(version 3.3.1 of GCC). I haven't tested other versions of GCC,
|
|
|
42 |
but they should compile without too much difficulty. The makefile
|
|
|
43 |
used to build the source is included.
|
|
|
44 |
|
|
|
45 |
* Currently, the AVRcam only works at a baud rate of 115.2 kbps. I
|
|
|
46 |
am in the process of working on autobaud routines that will set the
|
|
|
47 |
baud rate automatically at start up. I'm pretty sure the system
|
|
|
48 |
should be able to track 8 objects all the way down to a baud rate
|
|
|
49 |
of 38.4 kbps. Check back to www.jrobot.net for more info about the
|
|
|
50 |
AVRcam.
|
|
|
51 |
|
|
|
52 |
* Different portions of the code are #ifdef'ed in or out to show
|
|
|
53 |
the various debugging that can be turned on in the system. The
|
|
|
54 |
debugging mechanisms are typically for dumping additional information
|
|
|
55 |
out to a serial terminal for viewing, and are not intended to work
|
|
|
56 |
with the AVRcamVIEW PC application. The code, as released, doesn't
|
|
|
57 |
have any debugging features turned on.
|
|
|
58 |
|
|
|
59 |
* For more info about the AVRcam, check out http://www.jrobot.net
|
|
|
60 |
|
|
|
61 |
John Orlando
|
|
|
62 |
January 16, 2005
|