[chbot] Choc fish challenge, adding USART1 interrupts to WinAVR-20100110

Mark Atherton 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 
processing.

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 
change occurs.

.. 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 
(https://sourceforge.net/projects/winavr/files/latest/download), and 
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 
described.

'brownie-points--' for anyone suggesting a different toolchain or 
processor !! :)

Regards,

Mark



-------------- next part --------------
A non-text attachment was scrubbed...
Name: c-test.zip
Type: application/octet-stream
Size: 3160 bytes
Desc: not available
URL: <http://lists.ourshack.com/pipermail/chchrobotics/attachments/20200421/f61748a1/attachment-0001.obj>


More information about the Chchrobotics mailing list