Support for AtMega328pb

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Support for AtMega328pb

Wilhelm Meier
Hello,

recently I found that there ist not support for the (new) atmega328pb.
Do you plan to integrate this device?

Thanks for your reply!

_______________________________________________
AVR-libc-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Support for AtMega328pb

Joerg Wunsch
As Wilhelm Meier wrote:

> recently I found that there ist not support for the (new) atmega328pb.
> Do you plan to integrate this device?

Well, recently, the contributions for new devices mainly came from
Atmel, errm, Microchip.

But of course, if you want to submit a patch yourself, feel free to
do so.  The biggest work is to create the ioxxx.h header file.  It's
supposed to match the datasheet, and ought to be generated straight
from the Atmel Studio XML files.  However, it should also be possible
to roll it manually, e.g. by deriving it from the ATmega328P file.

The remainder is a bit of mentioning it in some other files, like
EEPROM and bootloader support.  If you grep through the existing
sources, looking for e.g. __ATmega168P__, you should be able to see
where this might be needed.
--
cheers, Joerg               .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/
Never trust an operating system you don't have sources for. ;-)

_______________________________________________
AVR-libc-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Support for AtMega328pb

Wilhelm Meier
Am 07.02.2017 um 14:21 schrieb Joerg Wunsch:

> As Wilhelm Meier wrote:
>
>> recently I found that there ist not support for the (new) atmega328pb.
>> Do you plan to integrate this device?
>
> Well, recently, the contributions for new devices mainly came from
> Atmel, errm, Microchip.
>
> But of course, if you want to submit a patch yourself, feel free to
> do so.  The biggest work is to create the ioxxx.h header file.

ok, obviously done by Fa. Watterott.

> The remainder is a bit of mentioning it in some other files, like
> EEPROM and bootloader support.  If you grep through the existing
> sources, looking for e.g. __ATmega168P__, you should be able to see
> where this might be needed.

Ok, I need to find the steps to generate the crtmega328pb.o ...


_______________________________________________
AVR-libc-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Support for AtMega328pb

Joerg Wunsch
As Wilhelm Meier wrote:

> > But of course, if you want to submit a patch yourself, feel free to
> > do so.  The biggest work is to create the ioxxx.h header file.

> ok, obviously done by Fa. Watterott.

Are you sure?  Or are they just redistributing stuff that Atmel
already ships as part of their Atmel Studio?

In the latter case, we cannot simply move that code into the tree,
because Atmel has the copyright for it.  They at least have to agree,
but sure, it would be easiest if they integrated it theirselves as
they used to do in the past.

> Ok, I need to find the steps to generate the crtmega328pb.o ...

Ah, I forgot: the device also needs to be added to
devtools/gen-avr-lib-tree.sh.

--
cheers, Joerg               .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/
Never trust an operating system you don't have sources for. ;-)

_______________________________________________
AVR-libc-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Support for AtMega328pb

Wilhelm Meier
Am 07.02.2017 um 14:36 schrieb Joerg Wunsch:
> As Wilhelm Meier wrote:
>
>>> But of course, if you want to submit a patch yourself, feel free to
>>> do so.  The biggest work is to create the ioxxx.h header file.
>
>> ok, obviously done by Fa. Watterott.
>
> Are you sure?  Or are they just redistributing stuff that Atmel
> already ships as part of their Atmel Studio?

well, they seem to redistribute the files from Atmel.

>
> In the latter case, we cannot simply move that code into the tree,
> because Atmel has the copyright for it.  They at least have to agree,
> but sure, it would be easiest if they integrated it theirselves as
> they used to do in the past.

is there a chance to trigger that?

>
>> Ok, I need to find the steps to generate the crtmega328pb.o ...
>
> Ah, I forgot: the device also needs to be added to
> devtools/gen-avr-lib-tree.sh.

Ok, so integrating the header-files, adapting the atmega328p
startup-code and running the above script shall do the trick?





_______________________________________________
AVR-libc-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Support for AtMega328pb

Joerg Wunsch
As Wilhelm Meier wrote:

> > In the latter case, we cannot simply move that code into the tree,
> > because Atmel has the copyright for it.  They at least have to agree,
> > but sure, it would be easiest if they integrated it theirselves as
> > they used to do in the past.
>
> is there a chance to trigger that?

I was in the hope one of the Atmel guys listening here would respond.

> > Ah, I forgot: the device also needs to be added to
> > devtools/gen-avr-lib-tree.sh.
>
> Ok, so integrating the header-files, adapting the atmega328p
> startup-code and running the above script shall do the trick?

No need to modify the startup code, it's pretty generic.

But, as I mentioned, a couple of other header files needs to be
modified, too, to get full support from avr-libc.
--
cheers, Joerg               .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/
Never trust an operating system you don't have sources for. ;-)

_______________________________________________
AVR-libc-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Support for AtMega328pb

JanEgil.Ruud
As Joerg Wunsch wrote:

> > > In the latter case, we cannot simply move that code into the tree,
> > > because Atmel has the copyright for it.  They at least have to
> > > agree, but sure, it would be easiest if they integrated it
> > > theirselves as they used to do in the past.
> >
> > is there a chance to trigger that?
>
> I was in the hope one of the Atmel guys listening here would respond.

We have spent quite some effort into detaching part support from other toolchains and libraries. In doing this we can more easily release support for new parts and fix bugs in the existing part support. Part support is now distributed in CMSIS-compatible packs that are available on http://packs.download.atmel.com/ . I would rather recommend you to download and unzip these packs, and then point the toolchain to the location of the linker scripts in the pack.

-Jan Egil Ruud
   --Microchip Tools employee

_______________________________________________
AVR-libc-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Support for AtMega328pb

Pitchumani Sivanupandi-2
On Wednesday 08 February 2017 01:59 AM, [hidden email] wrote:
> As Joerg Wunsch wrote:
>
>>>> In the latter case, we cannot simply move that code into the tree,
>>>> because Atmel has the copyright for it.  They at least have to
>>>> agree, but sure, it would be easiest if they integrated it
>>>> theirselves as they used to do in the past.
>>> is there a chance to trigger that?
>> I was in the hope one of the Atmel guys listening here would respond.
> We have spent quite some effort into detaching part support from other toolchains and libraries. In doing this we can more easily release support for new parts and fix bugs in the existing part support. Part support is now distributed in CMSIS-compatible packs that are available on http://packs.download.atmel.com/ . I would rather recommend you to download and unzip these packs, and then point the toolchain to the location of the linker scripts in the pack.
Yes, these device packs contains the required files (header, startup
file and device library) to support new devices.
Refer
http://distribute.atmel.no/tools/opensource/Atmel-AVR-GNU-Toolchain/3.5.4/ 
for using toolchain with these Atmel Device Family Packs.

Regards,
Pitchumani


_______________________________________________
AVR-libc-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Support for AtMega328pb

Joerg Wunsch
In reply to this post by JanEgil.Ruud
As [hidden email] wrote:

> We have spent quite some effort into detaching part support from
> other toolchains and libraries. In doing this we can more easily
> release support for new parts and fix bugs in the existing part
> support. Part support is now distributed in CMSIS-compatible packs
> that are available on http://packs.download.atmel.com/ .

Well, that doesn't help people expecting the respective support
already being part of the native toolchain though.

Can Microchip at least grant us permission to back-integrate their
header files here?  I assume they still have the usual 3-clause
BSD-like copyright statement, so it wouldn't be a legal issue to have
them here.

--
cheers, Joerg               .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/
Never trust an operating system you don't have sources for. ;-)

_______________________________________________
AVR-libc-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Support for AtMega328pb

Pitchumani Sivanupandi-2
On Wednesday 08 February 2017 01:16 PM, Joerg Wunsch wrote:

> As [hidden email] wrote:
>
>> We have spent quite some effort into detaching part support from
>> other toolchains and libraries. In doing this we can more easily
>> release support for new parts and fix bugs in the existing part
>> support. Part support is now distributed in CMSIS-compatible packs
>> that are available on http://packs.download.atmel.com/ .
> Well, that doesn't help people expecting the respective support
> already being part of the native toolchain though.
>
> Can Microchip at least grant us permission to back-integrate their
> header files here?  I assume they still have the usual 3-clause
> BSD-like copyright statement, so it wouldn't be a legal issue to have
> them here.
I think there is no change in licensing terms after Microchip
acquisition.
It would be easier if we could blindly copy the Atmel generated
headers and overwrite avr-libc headers. But there are compatibility
issues to replace avr-libc headers. We may need to figure out a way
to resolve this before start committing the generated headers.
It is also worth nothing that avr-gcc moving away from hard-coding
device specific details.

Regards,
Pitchumani

_______________________________________________
AVR-libc-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Support for AtMega328pb

Joerg Wunsch
As Pitchumani Sivanupandi wrote:

> >Can Microchip at least grant us permission to back-integrate their
> >header files here?  I assume they still have the usual 3-clause
> >BSD-like copyright statement, so it wouldn't be a legal issue to have
> >them here.

> I think there is no change in licensing terms after Microchip
> acquisition.

OK, that means we are allowed to import them.  Good.

> It would be easier if we could blindly copy the Atmel generated
> headers and overwrite avr-libc headers.

Well, in general, no.

What's there should stay there.  If there are bugs, they can be fixed,
but it's always been our policy even in that case to retain full
backwards compatibility (e.g. by keeping both, the old and the new
name).  Thus, you can sometimes find things in the header files like:

#define    UCSZ         2
#define    UCSZ2        2       /* new name in datasheet (2467E-AVR-05/02) */

It's not only important to have both names, but also to comment on
*why* it is that way, so people questioning it get to know what's the
way to go for them.

By generally dumping auto-generated files over them, we'd risk this
tradition.  Besides, avr-libc used to continue to support devices long
after Atmel has given up on them.

I think you are mainly referring to the large discrepancy in the
ATmega*RF[AR]* header files.  We (avr-libc together with the Atmel
developer team) tried to introduce an extended IO register addressing
scheme with the introduction of these devices: register-safe bit
access.  With the traditional register definitions, you are always at
a risk to do something like this:

TCCR0A = _BV(WGM01) | _BV(WGM02);

/* wrong: WGM02 belongs to TCCR0B */

No compiler would tell you about that mistake, it just yields
completely wrong results.

With register-safe access, you will get an error trying to do this:

TCCR0A_struct.wgm02 = 1;

because "wgm02" is only present in TCCR0B_struct.

The idea here was to eventually make this standard for all future
AVRs.  However, by that time, all future AVRs turned out to become
Xmega devices (for quite some time), which got a completely different
naming scheme.  However, even the Xmega scheme is *not* register-safe:

TCC1->CTRLB = TC_CLKSEL_DIV64_gc;

/* wrong: clock selection is performed in CTRLA */

Only starting with the SAMD ARM series, something similar finally got
state of the art:

SYSCTRL->XOSC32K.bit.STARTUP = 6; /* ≈ 1 s */
SYSCTRL->XOSC32K.bit.XTALEN = 1;  /* this is a crystal */

(Alas, writing the bitfield names all uppercase has other bad
implications, since there happen to be subregisters that have the same
name as global IO modules.  Writing them lowercase, as we did in 2009
with the ATmegaRFA, would have avoided that.)

So in general: backwards compatibility of the code of our userbase is
a value which is not to be broken.

Of course, for new devices that have no precedent cases, this is never
an issue, so you are free to import the auto-generated files for them.

> It is also worth nothing that avr-gcc moving away from hard-coding
> device specific details.

I cannot imagine how this would be possible for a library as avr-libc
though.  At least the startup code is always device-dependant and
needs to be pre-compiled.  In addition, history shows that for each
new device, a number of header files usually needs to be patched as
well (avr/eeprom.h, avr/power.h, avr/sleep.h come to mind).
--
cheers, Joerg               .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/
Never trust an operating system you don't have sources for. ;-)

_______________________________________________
AVR-libc-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Loading...