stevenj / avr-libc3 Goto Github PK

I've identified a few issues with the latest commit ff52582 which prevent it from building:

1. There's a command line in Makefile.in that's indented with 4 spaces instead of a tab which causes an error when make tries to parse the file.

2. The header file avr/io.h now has a block surrounded by #if !defined(AVR_LIBC_LEGACY_IO) ... #endif. The problem is that this conditional block skips including avr/common.h (and others) when AVR_LIBC_LEGACY_IO is defined. This causes the compiler to eventually generate an error since AVR_STACK_POINTER_REG in libc/stdlib/stdlib_private.h is no longer defined.

3. Many of the header files in avr/legacyio refer to common headers which were previously just in the avr directory. For example, iom48.h includes avr/iomx8.h. Since iomx8.h has been moved to legacyio directory this and other include directives fail.

I am trying to build an avr-libc that supports new devices like the mega 4809. While the auto-generated IO headers are in place, there are (at least) some additional hurdles to overcome:

• The device-specific directories below avr/lib are not generated by gen-avr-lib-tree because the list of devices is hard-coded.
• Same thing for configure.ac, where each of the generated Makefile.am has to be added.
• The iosym files for the new devices are missing, causing the CRT build to fail.

I think I have solved the first two problems by having gen-avr-lib-tree parse the spec-files used by the installed avr-gcc. The parse generates the same data structure that was used before. To tie the generated files into autotools gen-avr-lib-tree also generates an M4 file with an AC_CONFIG_FILES macro containing all generated files. That file can be included by configure.ac.

The missing iosym files could be added as stubs for now, they should probably be generated from the atdf files if I understand the process correctly.

I have created a branch in my fork that contains the changes.

Is this useful or are there issues that I have overlooked?

I struggle to run the config. Am I missing anything?

13:22 $ ./configure --prefix=$PREFIX --build=`./config.guess` --host=avr
-bash: ./config.guess: No such file or directory
-bash: ./configure: No such file or directory

Hi.

I see you also generate headers from ATDF files. I've created a repo with bug fixes in ATDF files.
https://github.com/luqasz/avr-registers
I see lots of people parse them over and over again. I propose to join forces and provide a source with fixed definitions.

What do you say ?

Hi 👋
I'd like to add support for both ATMEGA320/4809 but I've not done anything like this before. Can you point me to to some PR, patch or commit where I can see how to add new MCUs to the library?
With kind regards, Alex

When using sleep_mode() function from sleep.h, avr-gcc emits the following errors: error: 'MCUCR' undeclared (first use in this function) and error: 'SE' undeclared (first use in this function); did you mean 'SP'?.

The problem is that sleep.h treats the ATtiny3217 as an XMEGA part #elif defined(__AVR_XMEGA__), but the sleep register name and sleep bit names for the ATtiny3217 don't match other XMEGA devices.

... with make install.

It seems something like a SUBDIRS = io legacyio is missing in include/avr/Makefile.am. However, so far there is no autogenerated include/avr/io/Makefile.am to match the autogenerated io headers. I really don't know autoconf at all though, and my quick try with just SUBDIRS = legacyio did not lead to even just the legacy headers to be properly installed.

And here we were all worried that Microchip was going to let AVR languish, and was just doing a capture -> woodshed sorta thing to take out a PIC competitor...

Microchip's AVR team has apparently been slaving away on some mindblowing new parts.

ATtiny162x datasheet is out, silicon in november I've been seeing. The ADC is not only 12-bit, but absolutely on another level (plus a normal assortment of tweaks to what peripherals they have and how many, but no seizemic changes to architecture from the 1-series, other than no TCD, but yes external HF crystal).

AVRxxDAyy (where xx is flash size, 32/64/128, and yy is number of pins, 28. 32, 48, or 64) is shipping and baller, though the errata on the initial silicon is a a bit of a kick below the belt (and their errata sheet is incomplete),
AVRxxDByy is shipping in 128K version, but availability is still really spotty., haven't been able to score anything other than the 28-pin version; the others seem to mostly be available only in tray quantities, and very limited supply, and distributors don't have any at all) - basically identical to the DA, except that it supports external HF crystal, has 2/3 on-chip opamps (yes, you read that right) with software controlled mux on input and even a feedback resistor network), and (unless you disable via fuses), PORTC is in a separate power domain (in effect, a builtin level shifter, ie, you can have the chip running at 3.3v, and PORTC running at 5. Or the other way around - REALLY neat feature), powered by that pin in the middle of PORTC (28/32-pin parts lose PD0 and get the VDDIO2 pin in place of it). Their errata sheets imply that there are already two versions of silicon shipping, and the first version has a 3mV offset bug in the ADC, second doesn't - my theory is that they had too many chips built by the time they realized that to dump them, and they really needed to get them into the hands of developers for friendly customers anyway, but they don't want everyone and their mom to start playing with them until they can give us silicon that works better. I mean, a chip with special analog-specific features like them opamps and a 12 bit ADC but a 3mV offset... it's kind of a bad look, you know?
Finally, the AVRxxDDyy product brief is out now, too - 16/32/64k flash, 14/20/28/32 pins, external xtal, MVIO, on 3/4 pins..

Oh, and there's an AVRxxEAyy coming too - 28/32/48 pins, 16/32/64k flash. mostly seems least interesting of these parts, except for the fact that they have two TCAs and 4 TCBs on all of them (no TCD or MVIO, though). So if this library is still being maintained, there's some serious work to do ;-)

If I had to guess, I'd reckon that they're trying to replace the whole AVR product line for new product development, and exile the classic AVRs into the wilderness of "not for new designs".

Very exciting times for the AVR architecture, for sure. Real stroke of luck that the first excitement for the AVR instruction set in ~4 years started dropping it did - I don't know what I'd be doing with myself if I didn't have 20 new parts to add Arduino support for with 3 months left to go in the year...