[chbot] Choc fish challenge, adding USART1 interrupts to WinAVR-20100110
Mark Atherton
markaren1 at xtra.co.nz
Tue Apr 21 02:24:38 BST 2020
Hi Daniel,
Thanks for your thoughts.
The issue is a bit more complex than just horsepower per $$, it is about
time invested in a specific project which already uses this part, and
some peripheral specification issues about multiple boot-loader modes,
because of other attached external processor based devices.
At the start, this CPU looked like a good bet, so I have invested about
20 hours designing, fabricating and documenting the system, and had
everything except the 2nd serial port working just fine.
Basically the horse fell at the last jump, which is always a real
bugger, but given that this is a lockdown project, and the current state
of the supply-chain I am interested in a pragmatic solution.
At some point, the point of redoing 20 hrs work vs the real benefit of
that effort has to be looked at, and a balance struck.
Regards, Mark
On 21/04/2020 12:40 PM, Daniel Powell wrote:
> Mark, I'm reasonably new to micros I'm more than likely completely well off base....
>
> But I don't believe good enough is where it's at anymore. For a few dollars more you get magnitudes more ability.
>
> Because I've the coding ability close to the ability of my cat walking across my keyboard I simply wanted a single prototyping micro that can suit pretty much everything I need. I tried the Arduino series of micros and my sloppy cat quickly ran out of memory / connectivity / processor grunt. After being stung by ESP8266 wemos clones and inadequate 3.3v voltage regulators I tried the ESP32 is a processor group. I've pretty much standardised on everything from my race car datalogger to my home automation system in ESP32. You simply can't beat it for dollar spent (3 UARTS, SPI, I2C, 12S, CANBus, ADC, DAC, wifi, BLE, etc) and sheer grunt (240mhz dual core) and memory 448kb or ROM, 529KB SRAM, 4mb of flash. It's even got an RTC. Sleep mode draws between 3-20mA.
>
> My cat has chosen to hack in the Arduino IDE (hey I can't code!!!), Visual Studio for project work, ESPHome OTA [YAML] for "Home Assistant". Although everything from the Expressive IDF, microPython to block languages are available. My kids use UIFlow.
>
> Because I'm even lazier than my cat walking across my keyboard I've pretty much standardised on the M5StickC which gives me a battery, battery management, 6 axis, grove connector, mic, IR transmitter, LED, 3 buttons, LCD, USB C in a pretty little case.
>
> I bought 11 for about $150 and use them from everything to getting my kids coding to home automation.
>
> Regards,
> Daniel.
>
>
>
> -----Original Message-----
> From: Chchrobotics <chchrobotics-bounces at lists.ourshack.com> On Behalf Of Mark Atherton
> Sent: Tuesday, 21 April 2020 11:50 AM
> To: chchrobotics at lists.ourshack.com
> Subject: Re: [chbot] Choc fish challenge, adding USART1 interrupts to WinAVR-20100110
>
> 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_8
>> MHz.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
>>
>
> _______________________________________________
> Chchrobotics mailing list Chchrobotics at lists.ourshack.com
> https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.ourshack.com%2Fmailman%2Flistinfo%2Fchchrobotics&data=02%7C01%7C%7C1d8858215f984859f52208d7e5859a7a%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637230234313772828&sdata=zJFK46WWed6q9LF7%2FOGEWebRELssOfV43EhwiNkxJiU%3D&reserved=0
> Mail Archives: https://nam10.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.ourshack.com%2Fpipermail%2Fchchrobotics%2F&data=02%7C01%7C%7C1d8858215f984859f52208d7e5859a7a%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637230234313772828&sdata=L3rf28qSiR%2FuJDs%2Fc3Z%2BVmg6Ypa%2BdY6GuVpVL2ng68I%3D&reserved=0
> Meetings usually 3rd Monday each month. See https://nam10.safelinks.protection.outlook.com/?url=http%3A%2F%2Fkiwibots.org%2F&data=02%7C01%7C%7C1d8858215f984859f52208d7e5859a7a%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637230234313772828&sdata=OXEGIhnGO1eBAnMdCbmvwsmac6Rij3PDnyv2d4%2Fz2Sk%3D&reserved=0 for venue, directions and dates.
> When replying, please edit your Subject line to reflect new subjects.
> _______________________________________________
> Chchrobotics mailing list Chchrobotics at lists.ourshack.com
> https://lists.ourshack.com/mailman/listinfo/chchrobotics
> Mail Archives: http://lists.ourshack.com/pipermail/chchrobotics/
> Meetings usually 3rd Monday each month. See http://kiwibots.org for venue, directions and dates.
> When replying, please edit your Subject line to reflect new subjects.
More information about the Chchrobotics
mailing list