___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
https://lists.nongnu.org/mailman/listinfo/avr-libc-dev
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
Hello,
recently I found that there ist not support for the (new) atmega328pb.
Do you plan to integrate this device?
If this will not happen timely, how can I do it myself (and send a patch)?
Thanks for your reply!
___
AVR-libc-dev mailing list
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
Yes but not much activity.
2017-02-07 10:33 GMT+01:00 Wilhelm :
>
> ___
> AVR-libc-dev mailing list
> AVR-libc-dev@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/avr-libc-dev
>
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
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
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
As janegil.r...@microchip.com 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