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

[Mark Atherton]

Earlier this morning, I downloaded AVR-GCC V5.4 from Atmel (which seems 
to be their latest offering) and quite stunned that it also doesn't 
appear to support 328PB either. This does not bode well.

It appears that the compiler (and it's predecessor) do have the 328P 
baked in, or at least i can't find the associated .LD file. And, yes, I 
am very well aware of the compile / link / locate process.

I am a 1980s programmer, and work well enough; thank you for enquiring :)

Interesting in the disparity between Arduino and Atmel GCC versions, 
need to investigate further.

Yup, the PB is core 5.

Have never seen a .TEXT section used to store vectors before - the whole 
points of sections, segments and a locating linker is to keep such 
spaces apart until then need to be combined and relocated under user 
control.

I do have a morally-reprehensible solution to my USART1 dilemma, and 
since this is not a saleable project and not worried too much about it, 
but this upgrade what supposed to be easy-and-useful.

Well done for finding the linker scripts, I was stupidly looking for .LD 
files !

Thanks for you help and comments, will investigate the linker scripts 
when I get a moment

-Mark




On 21/04/2020 11:07 AM, Volker Kuhlmann wrote:
> 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
>