[chbot] Choc fish challenge, adding USART1 interrupts to WinAVR-20100110
markaren1 at xtra.co.nz
Mon Apr 20 20:34:48 BST 2020
At last nights meeting I touched on this subject ...
Many years ago, the ATmega328P became an incredibly popular processor
because of the efforts of the Arduino project.
The Arduino Nano uses this processor, and is a delightful, lightweight,
low cost module with USB and readily available bootloaders - so has been
designed into several projects here.
So, plenty of legacy code generated here for projects requiring low-end
I am continuously irritated by the speed at which tool-chains evolve,
and the associated eventual incompatibility between projects generated
by either different IDEs, or language implementations.
My (Luddite) fix for the problem is to select a toolchain, download all
associated binaries, and stick with it until a compelling reason for
.. and because of this boneheaded approach I can still produce
bit-accurate copies of projects I worked on in the 1980s.
So, some years ago, rightly, or wrongly I chose to use WinAVR-20100110
for the ATmega328 series, and as I said, now have quite a legacy
collection of source code associated with it. Editor is usually
something like notepad++, and an associated Makefile.
For my low power project, the main limitation of the 328x has been the
lack of a second UART. Then one day William mentioned the ATmega328PB
which appears to be a die-shrink of it's predecessor, with more
peripherals (including a 2nd UART), and lower cost.
So, sure, why not, let's have a go...
So to use the 2nd USART on the -PB variant, the minimum effort may be
take the toolchain
update the config file associated with the processor (called iom328p.h)
by adding new register definitions, adding some extra vectors, and
telling the compiler how much space to reserve for vector-space.
See tiny attached zip of a sample project, and read USART1.h - it has
all of the notes so far, and it is very straightforward.
Using polled I/O it was very easy to get USART1 up and running.
Head-banging started when I attempted to use associated interrupts...
Attached code fragment is not intended as a working example of anything,
just a sample which demonstrates the interrupt definition problem.
'make' will build the project, and 'dis.bat' will disassemble the
created ELF file into hw.txt - which starts with the vector table.
Clearly, my assumption and implementation of "telling the compiler how
much space to reserve for vector-space" is just plain wrong.
Ignoring the immediate need to generate valid vectors, I was rather
expecting that fiddling with _VECTORS_SIZE was going to (in some way)
affect the generated and initialised vector space. And it is quite
normal to populate such a table with a handler for unhandled events (in
this case <__bad_interrupt>).
Even commenting out out _VECTORS_SIZE has no effect, so my best guess at
the moment is that the compiler has vector table sizes baked in per
processor, which seems daft, and limiting since iom328p.h appears to
contain everything needed.
To verify that iom328p.h is being used by the compiler, introducing
errors into iom328p.h causes problems as expected.
So if anyone has some spare time(!) and a few ounces on inclination, I
will be most interested to see alternate approaches to the problem as
'brownie-points--' for anyone suggesting a different toolchain or
processor !! :)
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 3160 bytes
Desc: not available
More information about the Chchrobotics