[avr-libc-dev] [bug #35398] assert doesn't work unless stdlib.h is also included

URL: Summary: assert doesn't work unless stdlib.h is also included Project: AVR C Runtime Library Submitted by: bkerin Submitted on: Sun 29 Jan 2012 09:30:36 PM GMT Category: Librar

[avr-libc-dev] [patch #8649] small documentation fixes in

URL: Summary: small documentation fixes in Project: AVR C Runtime Library Submitted by: bkerin Submitted on: Sun 12 Apr 2015 03:57:34 PM GMT Category: None Priority

[avr-libc-dev] [patch #8650] another small doc fix in atomic.h

URL: Summary: another small doc fix in atomic.h Project: AVR C Runtime Library Submitted by: bkerin Submitted on: Sun 12 Apr 2015 04:06:42 PM GMT Category: None Prio

[avr-libc-dev] [bug #49688] wdt_enable() should get an entry on avr/wdt.h documentation page

URL: Summary: wdt_enable() should get an entry on avr/wdt.h documentation page Project: AVR C Runtime Library Submitted by: bkerin Submitted on: Wed 23 Nov 2016 11:30:06 PM GMT Cate

[avr-libc-dev] [bug #50800] example in avr/boot.h uses function from header not directly included

URL: Summary: example in avr/boot.h uses function from header not directly included Project: AVR C Runtime Library Submitted by: bkerin Submitted on: Thu 13 Apr 2017 11:59:07 PM UTC

support for atmega4809 family?

I notice there are official arduinos (arduino nano every and variants) which use the 4809 now so there's presumably some support for this chip somewhere. Is it going to show up in my beloved avr-libc? If there's work to be done I'd be interested in helping with this though I haven't done any avr-l

what are the correct high/low maximums for _delay_ms()/_delay_us()

I guess the high-res maximums are 262.14 ms / F_CPU in MH for _delay_ms() and 768 us / F_CPU in MHz for _dalay_us() regardless of the availability of __builtin_avr_delay_cycles(), but the way the _delay_ms() and _delay_us() descriptions are written this is not entirely clear. Am I correct? If so,

Re: what are the correct high/low maximums for _delay_ms()/_delay_us()

On Thu, Jan 23, 2020 at 1:25 PM Joerg Wunsch wrote: > > As Britton Kerin wrote: > > > I guess the high-res maximums are 262.14 ms / F_CPU in MH for > > _delay_ms() and 768 us / F_CPU in MHz for _dalay_us() regardless of > > the availability of __builtin_avr_delay_cy

can't reproduce documented overflow behavior of _delay_ms()

On a 16 MHz Arduino Mega 256, this code: __builtin_avr_delay_cycles (100.0); // Compiles, so we apparently have it debug_led_on (); _delay_ms (29.0); debug_led_off (); assert (0); leaves the debug led on for about 269 s. Same for larger arguments to _delay_ms (e.g. 35.0). Th

support for atmega328PB?

I notice this one doesn't show up all in include/avr :( It seems like it's just 328P with an extra serial port, i2c, SPI, some more PWM channels and QTouch. If I recall correctly some of the recent microchip offerings (mega-0 or something) weren't supported yet by gcc, but it seems like this one

Re: support for atmega328PB?

On Thu, Sep 10, 2020 at 12:42 PM Joerg Wunsch wrote: > > As Britton Kerin wrote: > > > I notice this one doesn't show up all in include/avr :( > > I'm not sure, perhaps there's already a bug/patch for it? > > I started catching up with my AVR stuff. Fi

notable exception to FAQ item https://www.nongnu.org/avr-libc/user-manual/FAQ.html#faq_intbits

This FAQ item says: The solution is simple: writing a logical 1 to it requires only a single OUT instruction, and it is clear that only this single interrupt request bit will be cleared. There is no need to perform a read-modify-write cycle (like, an SBI instruction), since all bits in these

stdbool.h exists but isn't documented

at least it doesn't show up on https://www.nongnu.org/avr-libc/user-manual/modules.html Britton

using __func__ once increases _end (variable area size) by 446 bytes?

I have a program where changing this: POSSIBLY_UNUSED char const *foo = "x"; printf ("%s, %i\n", foo, __LINE__); to this: POSSIBLY_UNUSED char const *foo = "x"; printf ("%s, %i\n", __func__, __LINE__); increases _end from 67b to 839 and causes the produced program to never

Re: using __func__ once increases _end (variable area size) by 446 bytes?

On Fri, Dec 18, 2020 at 11:27 PM Joerg Wunsch wrote: > > As Britton Kerin wrote: > > > The function name is only 17 characters. How can using __func__ cause > > such a dramatic increase in the variable area size? > > Well, the avr-libc list ist probably not necessari

Re: using __func__ once increases _end (variable area size) by 446 bytes?

On Sat, Dec 19, 2020 at 10:40 AM Britton Kerin wrote: > > On Fri, Dec 18, 2020 at 11:27 PM Joerg Wunsch wrote: > > > > As Britton Kerin wrote: > > > > > The function name is only 17 characters. How can using __func__ cause > > > such a dramatic increa

PROGMEM doesn't work right from bootloader?

Am I right? This probably shouldn't come as a surprise but I have for years my own stuff for debugging on terminal that uses AVR libc printf_P etc. so it was :( Afterall __attribute__((__progmem__)) is compile-time and the only thing that tells the bootloader base flash address goes to the linker