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

[Volker Kuhlmann]

There's nothing wrong with keeping some tools with the projects, even if
they're from the 80s. (How well that software and the programmers still
work on a modern system is a different question I guess.)

# There is nothing wrong with upgrading the CPU to a slightly more
# capable version, especially if downwards compatible. I use 328P a lot
# too. There are serious downsides with ARM stuff in very small settings
# (more silicon, more xxOPS, more power) - run off a battery for how
# long?
brownie-points++;

# As you have now changed CPU, perhaps it is a good enough reason to
# upgrade the tool chain, especially as it's 10 years old and missing a
# few capabilities you suddenly find essential?
brownie-points--;

I can't speak for any microsoft software, but did you say before your
tool chain uses gcc?

The memory allocation is not handled by the compiler, but by the linker,
using a linker script. IIRC other compilers did that too. The compiler
only generates the segment names where any particular code/data must be
placed, the linker decides where to place it (and there may be a
mechanism where the compiler requests/tells the linker, like giving an
address for a particular object). These days, the linker also makes
significant optimisations to the code (LTO, gold linker), respectively
code chunks, throwing those out that aren't actually used. This is a
good reason to use the newest gcc you can for AVR.

Arduino IDE 1.8.12 comes wth gcc 7.3.0, and it already knows the 328PB.
These are all the 328 files:

hardware/arduino/avr/bootloaders/atmega/ATmegaBOOT_168_atmega328.hex
hardware/arduino/avr/bootloaders/atmega/ATmegaBOOT_168_atmega328_pro_8MHz.hex
hardware/arduino/avr/bootloaders/bt/ATmegaBOOT_168_atmega328_bt.hex
hardware/arduino/avr/bootloaders/optiboot/optiboot_atmega328-Mini.hex
hardware/arduino/avr/bootloaders/optiboot/optiboot_atmega328.hex
hardware/arduino/avr/bootloaders/optiboot/optiboot_atmega328.lst
hardware/tools/avr/avr/include/avr/iom328.h
hardware/tools/avr/avr/include/avr/iom328p.h
hardware/tools/avr/avr/include/avr/iom328pb.h
hardware/tools/avr/avr/lib/avr5/crtatmega328.o
hardware/tools/avr/avr/lib/avr5/crtatmega328p.o
hardware/tools/avr/avr/lib/avr5/crtatmega328pb.o
hardware/tools/avr/avr/lib/avr5/libatmega328.a
hardware/tools/avr/avr/lib/avr5/libatmega328p.a
hardware/tools/avr/avr/lib/avr5/libatmega328pb.a
hardware/tools/avr/lib/gcc/avr/7.3.0/device-specs/specs-atmega328
hardware/tools/avr/lib/gcc/avr/7.3.0/device-specs/specs-atmega328p
hardware/tools/avr/lib/gcc/avr/7.3.0/device-specs/specs-atmega328pb

The specs file indicates core avr5.
Linker scripts:

hardware/tools/avr/avr/lib/ldscripts/avr5.x
hardware/tools/avr/avr/lib/ldscripts/avr5.xbn
hardware/tools/avr/avr/lib/ldscripts/avr5.xn
hardware/tools/avr/avr/lib/ldscripts/avr5.xr
hardware/tools/avr/avr/lib/ldscripts/avr5.xu
hardware/tools/avr/lib/gcc/avr/7.3.0/device-specs/specs-avr5

Note the .vectors section, but there's no definition for it.
It may be a subsection of the .text section and because .vectors is
first might force it to address 0x0000 (or whereever the flash starts).

Before you get too excited, these are the differences:

--- hardware/tools/avr/lib/gcc/avr/7.3.0/device-specs/specs-atmega328p	2019-03-08 23:27:11.000000000 +1300
+++ hardware/tools/avr/lib/gcc/avr/7.3.0/device-specs/specs-atmega328pb	2019-03-08 23:27:11.000000000 +1300
-# Auto-generated specs for AVR device atmega328p (core avr5, 16-bit SP)
+# Auto-generated specs for AVR device atmega328pb (core avr5, 16-bit SP)
-	crtatmega328p.o%s
+	crtatmega328pb.o%s
-	%{!nodevicelib:-latmega328p}
+	%{!nodevicelib:-latmega328pb}
-	-D__AVR_ATmega328P__ -D__AVR_DEVICE_NAME__=atmega328p
+	-D__AVR_ATmega328PB__ -D__AVR_DEVICE_NAME__=atmega328pb

Going through the header files, USART0 uses interrupt vectors 18-20,
USART1 uses 28-31(! - 1 more). They go up to 44.
Definitions are like:

 #define USART1_RX_vect            _VECTOR(28)
 #  define BADISR_vect __vector_default

 #define _VECTOR(N) __vector_ ## N

There is no definition for __vector_ anything, but the object libraries
all contain __vector_xxx, like __vector_18. (Btw __vector_default is at
the end. Does that hint at anything?)

That makes me think the compiler and linker have some implicit
assumptions about what the interrupt vector objects are and where they
go. Check the source of the AVR libc library? You may have to recompile
that, the assumptions may originate there.

Or maybe not. The location is already defined, the size might follow by
itself (or is it __vector_default?). But you will have to declare
(#define?) __vector_28 etc, *and* use them, or the linker will throw
them out. I.e., you have to define an ISR for it.

If you're not using gcc, sorry for the noise... and I can't help. I
decided a long time ago that for anything at home, it either uses gcc or
the manufacturer can sell the chips to someone else.

# Stuck on doctoring 10 year old tool chains into the present.
while (brownie-points == 0);

HTH,

Volker

-- 
Volker Kuhlmann
http://volker.top.geek.nz/	Please do not CC list postings to me.