Re: About the clang/llvm tool chain for AVR

As Ben Shi via Discussion of avr-libc development wrote: > I am current maintainer of the llvm-avr backend, and I would like to > ask for your feedback on my work. My final goal is making > clang-llvm-lld-compiler_rt chain fully functional, and let AVR > program developers get rid of the GNU tool

Re: released v2.1.0

As Joerg Wunsch wrote: > The intent is that this is going to be the last Savannah release, and > the project migrates to Github soon. The repository has been migrated now: https://github.com/avrdudes/avr-libc Issue trackers will follow soon. -- cheers,

released v2.1.0

Hello *, I just released the status quo of the SVN repository as version 2.1.0. Files have been uploaded to savannah, including documentation tarballs. Web documentation has not been updated yet. The intent is that this is going to be the last Savannah release, and the project migrates to Github

Re: Compilation with clang

As Marian Buschsieweke wrote: > So I guess for my application I know only have to teach clang the value of > __tmp_reg__ (and maybe also a few other constants) to get it compiling :-) Well, since Clang aims to be a GCC replacement, it would probably be good if the AVR port of it supported the

Re: Compilation with clang

As Marian Buschsieweke wrote: > parts of the avrlibc headers are not compatible with clang. (The use case is > not to compile avrlibc itself with clang, but rather an application using > a vanilla GCC compiled avrlibc.) However, the issues are not always trivial to > fix. I seem to remember

[patch #9553] Fix some issues in libc/

Update of patch #9553 (project avr-libc): Status:None => Done Assigned to:None => joerg_wunsch Open/Closed:Open => Closed

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

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 necessarily the right place to ask questions about the compiler itself. Anyway, please provide a

Re: [patch] fix use of uninitialized variable in

As Yuriy M. Kaminskiy wrote: > ... due to missing return after fallback to _delay_ms() when > __builtin_avr_delay_cycles is not used. Well, normally, I'd like to have things like this going into a bug tracker. However, as this bug fix was pretty obvious, I just applied the patch to the tree.

Re: stdbool.h exists but isn't documented

As Britton Kerin wrote: > at least it doesn't show up on > https://www.nongnu.org/avr-libc/user-manual/modules.html Well, it's part of the compiler suite, not avr-libc. There are some more files in this group: j@uriah 63% ls /usr/local/lib/gcc/avr/9.1.0/include

Re: Attempting to modify efuse with avrdude and Atmega32m1 seems to be unsupported by standard means?

As Hannes Wallnöfer wrote: > I send a similar mail to the avr-c...@nongnu.org but we where not able to > resolve the issue. I thought I should give it a try here as well since the > problem still occurs and it may be a bug somewhere. Apologies if this is not > the right place, maybe someone could

Re: support for atmega328PB?

As Britton Kerin wrote: > I've never looked at device packs, but if there's something you think > I could usefully help with on this effort let me know. Well, you could always give that a try, and see what they are doing inside. -- cheers, Joerg .-.-. --... ...-- -.. . DL8DTL

Re: support for atmega328PB?

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. First was AVaRICE (because it did not even compile anymore with recent compilers, for a bug that had been fixed

[bug #58711] correcting errors in documentation inquiry

Follow-up Comment #1, bug #58711 (project avr-libc): It is completely fine to issue tickets for such errors. ___ Reply to this item at: ___ Message

Re: can't reproduce documented overflow behavior of _delay_ms()

As Georg-Johann Lay wrote: > hmmm. So there is more work to do for double support? We definitely do not > want double here but float instead... I disagree. This is all just happening in temporary variables inside of "static inline" functions, and thus completely optimized away by the

Re: can't reproduce documented overflow behavior of _delay_ms()

As Britton Kerin wrote: > If the avr-gcc toolchain has __builtin_avr_delay_cycles() support, > maximal possible delay is > 4294967.295 ms/ F_CPU in MHz. For values greater than the maximal > possible delay, > overflows results in no delay i.e., 0ms. > > It looks like the result is now the

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

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_cycles(), but > the way the _delay_ms() and _delay_us() descriptions are written this > is not

[bug #50270] Article "Problems with reordering code" misleading

Follow-up Comment #9, bug #50270 (project avr-libc): Just propose (best on the list where it can be discussed better) a new wording of that entry. If a new formulation is agreed on, it is then quite simple to update the article. So far, I see a discussion, but barely already a complete

[bug #57299] util/setbaud.h incompatible with new AVR iom*.h headers

Follow-up Comment #1, bug #57299 (project avr-libc): Well, it's really a poor idea from the to use such a common name like BAUD for a subregister. I wonder how much code needs to be reworked now ... Sure, we could work around that by calling it BAUDRATE, and make BAUD an alias for it on

[bug #57071] Fix math.h and function names that block 64-bit double

Follow-up Comment #5, bug #57071 (project avr-libc): Thanks for the explanation. I think I'll apply the patch then as is by now, and we might add some words about the usage later on, when the configuration is settled. ___ Reply to this

[bug #57071] Fix math.h and function names that block 64-bit double

Follow-up Comment #3, bug #57071 (project avr-libc): Thanks, something "auto-configuring" like the second patch is much appreciated. Curious, what's the compiler switch to select 32- vs. 64-bit double? I'd like to add a bit of documentation about the entire topic as well.

Re: [avr-libc-dev] broken code generation

As avr-libc-devel wrote: > >Seems like a strange compiler build. > In my opinion, the problem at the link stage: the object file after > compilation looks OK Yes, but the linker is driven by the compiler. > 2.$ avr-gcc blink.o -v -o blink.elf Your linker call is missing the -mmcu option.

Re: [avr-libc-dev] broken code generation

As avr-libc-devel wrote: > Can anyone comment on what is going on? Seems like a strange compiler build. > Command line to compile the project: > $ avr-gcc -iquote . -Os -pipe -mmcu=attiny2313 -mint8 -g -c -o blink.o > blink.c While I would not recommend using -mint8 (it has been deprecated for

Re: [avr-libc-dev] Is there any active maintainer?

As Taavo Raykoff wrote: > What is the route to becoming an allowed committer — if I or someone > has time to help out with this? Given the low activity of all existing committers (including me), I'd say: enough dedication ... Regarding your malloc stuff: there is a testsuite in the source

Re: [avr-libc-dev] Is there any active maintainer?

As Taavo Raykoff wrote: > Is there any active maintainer on avr-libc? Depends on your definition of "active". I am the maintainer of it, but unfortunately, even though my activity is very low (being busy in many respects, family, job, German amateur radio league, other opensource stuff as

Re: [avr-libc-dev] [Docs] on compiler / linker flags

As flo.ke...@gmx.at wrote: > IMHO there *should* be a mention in the first paragraph, that this > flag is OFC needed for the linker also. At least it should be the > first flag for "selected linker options" So, you're obviously referring to the -mmcu= option. Please file a formal bug report

Re: [avr-libc-dev] [patch #9659] Update eeprom_is_ready for avrxmega3 devices

As pitchumani.sivanupa...@microchip.com wrote: > Hi All, > > Any comments for this patch? > > If OK, I'll commit this by early next week. Yes, please do! -- cheers, Joerg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/ Never trust an operating system you don't

Re: [avr-libc-dev] Printf %S printing from PROGMEM not functional, compiler error

As Joerg Wunsch wrote: > > But I get the following compiler error: > > error: format '%S' expects argument of type 'wchar_t*', but argument 2 > > has type 'const char*' [-Werror=format=] > > printf("%S:%u\n", name, i); > > Then do as suggested, and

Re: [avr-libc-dev] Printf %S printing from PROGMEM not functional, compiler error

As avr-libc-...@nicohood.de wrote: > But I get the following compiler error: > error: format '%S' expects argument of type 'wchar_t*', but argument 2 > has type 'const char*' [-Werror=format=] > printf("%S:%u\n", name, i); Then do as suggested, and turn off compiler warnings (and -Werror) for

Re: [avr-libc-dev] PSTR() in static initialisers

As Georg-Johann Lay wrote: > If that static is not function-static, then __flash can be used: Thanks for that, Johann. I tried to come up with a __flash-based implementation myself, but didn't get it to work. Maybe your "recipe" would be worth an entry into the avr-libc FAQ? -- cheers, Joerg

Re: [avr-libc-dev] PSTR() in static initialisers

As Paul "LeoNerd" Evans wrote: > Hrm; that's upsettingly annoying. Is there perhaps a way this can be > convinced into working? I could not find a way. You want to initialize a flash pointer, and for that to work, you need an (array) object already in flash. A string literal defaults to end up

Re: [avr-libc-dev] PSTR() in static initialisers

As Paul "LeoNerd" Evans wrote: > Does anyone have a suggestion on how I can have a string pointer to a > flash-stored string in a static initialiser? This only works by allocating each of the string into a variable (well, constant actually) in flash by itself, and then mention their names in the

[avr-libc-dev] [patch #9543] Add avrxmega3 devices.

Follow-up Comment #12, patch #9543 (project avr-libc): Mixing the licenses is doable, it's just a little cumbersome since we need to LICENSE documents then at the toplevel. If #b is not too much work, it would be my personally preferred solution, as it makes us completely independent from

[avr-libc-dev] [bug #52181] assert should make Serial.flush() before calling abort()

Update of bug #52181 (project avr-libc): Status:None => Wont Fix Open/Closed:Open => Closed ___ Follow-up Comment #2: I agree with

Re: [avr-libc-dev] Linker size check by adding export symbols

As Sebastian Brückner wrote: > See patch below. Is this the right way to do it? I think so, yes. -- cheers, Joerg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/ Never trust an operating system you don't have sources for. ;-)

[avr-libc-dev] [patch #9187] [AVR_TINY]: Support 16-bit xtoa functons and more string functions.

Update of patch #9187 (project avr-libc): Status:None => Done Assigned to:None => joerg_wunsch Open/Closed:Open => Closed

[avr-libc-dev] [patch #8966] Update RFR devices header files

Follow-up Comment #1, patch #8966 (project avr-libc): As already discussed in the mailing list, applying this patch would essentially remove a lot of existing functionality from the header files (it removes about 2 lines in total), just for the sake of "we've always been doing it that way",

[avr-libc-dev] [patch #8826] Add UCSR0C bit definitions for ATmega1284(p) USART in SPI mode

Update of patch #8826 (project avr-libc): Assigned to:None => joerg_wunsch ___ Follow-up Comment #1: Thinking a little about it, I'm not that convinced yet about this. All the modern

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

Update of patch #8650 (project avr-libc): Status:None => Done Assigned to:None => joerg_wunsch Open/Closed:Open => Closed

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

Follow-up Comment #1, patch #8650 (project avr-libc): Added in r2541, thanks! ___ Reply to this item at: ___ Message sent via/by Savannah

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

Update of patch #8649 (project avr-libc): Status:None => Done Assigned to:None => joerg_wunsch Open/Closed:Open => Closed

[avr-libc-dev] [patch #8536] Fix a typo within

Update of patch #8536 (project avr-libc): Status:None => Done Assigned to:None => joerg_wunsch Open/Closed:Open => Closed

[avr-libc-dev] [patch #8729] [avr/interrupt.h] Add ISR_NOICF, ISR_FLATTEN. Fix namespace of identifiers.

Update of patch #8729 (project avr-libc): Status:None => Done Assigned to:None => joerg_wunsch Open/Closed:Open => Closed

[avr-libc-dev] [bug #51022] avr/wdt.h should support all of the modes of operation of the WDT

Update of bug #51022 (project avr-libc): Status: Need Info => None ___ Follow-up Comment #3: OK, now it makes sense. ___ Reply to

[avr-libc-dev] [bug #51022] avr/wdt.h should support all of the modes of operation of the WDT

Update of bug #51022 (project avr-libc): Status:None => Need Info ___ Follow-up Comment #1: Please submit more details. ___

Re: [avr-libc-dev] Pulling avr-libc headers into simavr

As M P wrote: > I'm considering pulling the header parts of avr-libc straight into > simavr source code > Anyone has an issue with that? I think there is no licencing problem? I don't think it is. Just remember clause two: mention the avr-libc licensing conditions somewhere in your

[avr-libc-dev] [bug #50811] using -Wl, -u, vfprintf -lprintf_min causes program to grow a lot

Follow-up Comment #8, bug #50811 (project avr-libc): > I guess maybe it happens inevitably due to compiler > machinations. Exactly, it's a compiler thing we cannot influence. ___ Reply to this item at:

Re: [avr-libc-dev] Missed optimizations

As Raul Sanchez wrote: > Just wanted to report the following observations in generated code. > Target: __AVR_ATtiny85__Version: AVR gcc 4.6.4Optimization level: -Os Besides your code missing linefeeds so it's barely readable: sorry, GCC code optimization is nothing we could do anything about.

[avr-libc-dev] [bug #50811] using -Wl, -u, vfprintf -lprintf_min causes program to grow a lot

Follow-up Comment #6, bug #50811 (project avr-libc): Well, the fact that the -u vfprintf needs to be forced is an unfortunate side effect of libprintf_min.a *only* containing a different definition of vfprintf(), but not e.g. for printf() or other members of the family. Thus, if you only add

[avr-libc-dev] [bug #50270] Article "Problems with reordering code" misleading

Follow-up Comment #6, bug #50270 (project avr-libc): Yes, he can discuss it there, but he cannot append anything to the bug report itself. ___ Reply to this item at:

Re: [avr-libc-dev] Support for AtMega328pb

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

[avr-libc-dev] [bug #50270] Article "Problems with reordering code" misleading

Follow-up Comment #3, bug #50270 (project avr-libc): The bug report is fine for a clear bug. However, for something to be discussed first, it's a poor medium: if the author of that text (who is on the developers mailinglist) wants to reply something, he stands no chance to add it to the bug

[avr-libc-dev] [bug #50270] Article "Problems with reordering code" misleading

Follow-up Comment #1, bug #50270 (project avr-libc): Your criticism seems to confuse volatile memory access with volatile asm statements. Given the matter is known to be tricky, it would have been better to subscribe to the avr-libc mailing list, and discuss the wording there with the other

Re: [avr-libc-dev] Support for AtMega328pb

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

Re: [avr-libc-dev] Support for AtMega328pb

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

Re: [avr-libc-dev] Support for AtMega328pb

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

Re: [avr-libc-dev] Support for AtMega328pb

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

Re: [avr-libc-dev] Erroneous definition of _MemoryBarrier() in cpufunc.h

As Ralf Ramsauer wrote: > If someone could confirm this I'll send a short patch. https://savannah.nongnu.org/bugs/index.php?37778 Already fixed in the SVN tree. -- cheers, Joerg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/ Never trust an operating system you

Re: [avr-libc-dev] Testsuite (Was: How attached are people ...)

As George Spelvin wrote: > > Ah OK. Then I missed it, somehow. > > Here's my patch. Thanks, committed. > (ObLegalese: Yes, *of course* I grant permission for > this, and anything else I post to avr-libc-dev, to be distributed under > the terms of the 3-clause BSD license in the LICENSE

Re: [avr-libc-dev] Testsuite (Was: How attached are people ...)

As George Spelvin wrote: > I just updated and it's still there. Commit 2532 got the one in > avr-libc/tests/simulate/stdlib/dtostre.h, but the one I tripped over in > dtostrf.h is still there. Ah OK. Then I missed it, somehow. -- cheers, Joerg .-.-. --... ...-- -.. . DL8DTL

Re: [avr-libc-dev] I just noticed OPTIMIZE_SPEED

As George Spelvin wrote: > Er... AFAICT, that option has nothing to do with -O compiler > flags, but is set as part of library compilation. I know. I've never really been happy with that, but it's been in use for so long, so it won't be changed. -- cheers, Joerg .-.-. --...

Re: [avr-libc-dev] Testsuite (Was: How attached are people ...)

As Georg-Johann Lay wrote: > >Simulate: scanf/sscanf_flt-f1.c /scanf_flt atmega128 ... > >scanf/sscanf_flt-f1.c: In function 'main': > >scanf/sscanf_flt-f1.c:162:1: internal compiler error: in push_reload, at > >reload.c:1380 > > } > > ^ > >no stack trace because unwind library not available >

Re: [avr-libc-dev] How attached are people to the implementation of rand()/random()?

As George Spelvin wrote: > Simulate: regression/bug-22828.c atmega128 ... /tmp/cciW6XcS.o: In function > `main': > ~/avr/avr-libc/avr-libc/tests/simulate/regression/bug-22828.c:50: undefined > reference to `eeprom_write_block' > ~/avr/avr-libc/avr-libc/tests/simulate/regression/bug-22828.c:52:

Re: [avr-libc-dev] Testsuite (Was: How attached are people ...)

As Georg-Johann Lay wrote: > Presumably, it goes like follows: avr-libc detects from the version of > avr-gcc that it does not add -latmega128 and hence skips building > libatmega128.a, hence no such .a in the avr-libc build tree. Yep. However, Pitchumani added (in r2520) code to runtest.sh

Re: [avr-libc-dev] How attached are people to the implementation of rand()/random()?

As George Spelvin wrote: > As I'm looking through the rest of the code, I notice a few silly things. > > For example, couldn't rand_r save a jump by declaring it > > int rand_r(unsigned long *ctx) __attribute__((alias("do_rand"))); I don't think that would work, as do_rand() is declared

Re: [avr-libc-dev] Interested in 64-bit printf support?

As George Spelvin wrote: > I could just pass this over to the TICC project, but is there any interest > in me making the necessary overhauls to vfprintf to incorporate this? Basically, yes, having 64-bit integer printing support in vfprintf() would certainly be cool. My only concern from

[avr-libc-dev] [bug #49447] Example code for uart_putchar() has error in recursive call

Update of bug #49447 (project avr-libc): Status:None => Fixed Assigned to:None => joerg_wunsch Open/Closed:Open => Closed Fixed Release:

Re: [avr-libc-dev] cxa_aexit issue

As NicoHood wrote: > We've got some workarounds, but I hope someone can help use find the > real issue and possibly also solve it. You may have a look at it more > detailed here: > https://bugs.archlinux.org/task/50848 After looking at it, it's not quite sure what we are supposed to do here. If

[avr-libc-dev] [bug #49020] dtostre() flags documentation error

Update of bug #49020 (project avr-libc): Status:None => Fixed Assigned to:None => joerg_wunsch Open/Closed:Open => Closed Fixed Release:

Re: [avr-libc-dev] Generating and Publishing AVR-Libc Documentation

Citing that CVS document: > cvs [-z3] [-n] -d $use...@cvs.savannah.nongnu.org:/web/avr-libc \ > import avr-libc/user-manual AVR-LIBC $release > > The meta variable $userid is (obviously) your User ID on savannah, > while $release is the symbolic release tag. While this tag is mostly >

Re: [avr-libc-dev] [bug #43261] symbols in documentation are getting their leading and trailing "__" stripped by doxygen

As Jonathan W. Taylor wrote: > Furthermore, if it OK for me to > change it, I don't know if I should regenerate all of the documentation or > just the broken files. Re-importing everything is the better way for sure. -- cheers, Joerg .-.-. --... ...-- -.. . DL8DTL

Re: [avr-libc-dev] Generating and Publishing AVR-Libc Documentation

Hi Jonathan, many thanks for your work on the documentation! As Jonathan Taylor wrote: > What is the process for (re)generating and publishing documentation to > http://www.nongnu.org/avr-libc ? It's unfortunately a little complicated, as it still requires the use of CVS, and quite a bit of

Re: [avr-libc-dev] [bug #48480] missing definitions in iox128a1u.h, iox64a1u.h

As anonymous wrote: > ...anyone? A month to have a simple "definitions missing from headers" report > even acknowledged is silly. What would an acknowledgment get you, actually? I tend to work down that kind of bugs right before a release. -- cheers, Joerg .-.-. --... ...--

Re: [avr-libc-dev] C11 Atomics and GCC libatomic

As Georg-Johann Lay wrote: > As libatomic will need close cooperation with the compiler, I'd > recommend to add it to GCC. That would be my recommendation, too. If it's a compile feature, it would better be there. Perhaps it's then even possible to find a more efficient implementation (no

[avr-libc-dev] [bug #47937] Incorrect "0" suffix in names of SPI registers and bits for ATmega324PA and ATmega164PA

Update of bug #47937 (project avr-libc): Status:None => Confirmed ___ Reply to this item at: ___

[avr-libc-dev] [bug #47937] Incorrect "0" suffix in names of SPI registers and bits for ATmega324PA and ATmega164PA

Follow-up Comment #4, bug #47937 (project avr-libc): OK, great if your patch maintains both names. I'll apply it shortly then. Quite possible Atmel tried to maintain some "forward consistency" (they did it in other situations that way in the past, e.g. USART bit names), but the datasheet and

[avr-libc-dev] [bug #47937] Incorrect "0" suffix in names of SPI registers and bits for ATmega324PA and ATmega164PA

Follow-up Comment #1, bug #47937 (project avr-libc): Actuall, the datasheet is inconsistent on this: in the register summary at the end, the bits do have the 0 suffix, while the description omits them. Likewise, the Atmel Studio XML files (where our header files have been derived from) also

[avr-libc-dev] [bug #47734] WDTO_4S and WDTO_8S are incorrect

Follow-up Comment #4, bug #47734 (project avr-libc): I added a remark in the comment of these constants, telling that their values does not match the control register's bit pattern. ___ Reply to this item at:

[avr-libc-dev] [bug #47734] WDTO_4S and WDTO_8S are incorrect

Update of bug #47734 (project avr-libc): Status: Need Info => Invalid Open/Closed:Open => Closed ___ Follow-up Comment #3: The WDTO_xxx

[avr-libc-dev] [bug #47734] WDTO_4S and WDTO_8S are incorrect

Update of bug #47734 (project avr-libc): Status:None => Need Info ___ Follow-up Comment #1: What do you mean by "atmel-8271 and atmel-2586"? In general, your remark is incorrect.

[avr-libc-dev] [bug #47655] OC0_{DDR, PORT, PIN, BIT} is missing from avr/iom16a.h (at least)

Update of bug #47655 (project avr-libc): Status:None => Wont Fix ___ Follow-up Comment #1: We have never been supplying specific abstraction macros for various IO features in our

Re: [avr-libc-dev] Update RFR devices header files

As Pitchumani Sivanupandi wrote: > RFR devices (mega64/644/128/1284/256/2564rfr2) headers are included in > the revision 2308. > http://svn.savannah.nongnu.org/viewvc?view=rev=avr-libc=2308 > > It seems they are in struct-based format like xmega headers. Nope, it's quite different. If at all,

Re: [avr-libc-dev] [avr-libc-commit] [2520] Patch #8961: Update test script for new simulavr and library layout

As Pitchumani wrote: > Revision: 2520 > http://svn.sv.gnu.org/viewvc/?view=rev=avr-libc=2520 > Author: pitchumani > Date: 2016-04-04 08:38:44 + (Mon, 04 Apr 2016) > Log Message: > --- > Patch #8961: Update test script for new simulavr and library layout Thanks! --

Re: [avr-libc-dev] Export fuse memory size as a symbol

As Senthil Kumar Selvaraj wrote: > For starters, the below patch defines __FUSE_REGION_LENGTH__ as a weak > symbol. > > diff --git avr-libc/crt1/gcrt1.S avr-libc/crt1/gcrt1.S > index 561d4f8..b2f482b 100644 > --- avr-libc/crt1/gcrt1.S > +++ avr-libc/crt1/gcrt1.S > @@ -390,3 +390,8 @@

[avr-libc-dev] [bug #47113] XMegaE series won't write eeprom

Update of bug #47113 (project avr-libc): Status:None => Invalid Open/Closed:Open => Closed ___ Follow-up Comment #4: OK, I'm glad it

Re: [avr-libc-dev] Need news update for avr-libc 2.0.0 release

As Pitchumani Sivanupandi wrote: > It seems the News in project page is not updated for the new release > (2.0.0). Thanks for the reminder. I added an entry for it. -- cheers, Joerg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/ Never trust an operating system you

Re: [avr-libc-dev] 2.0.0 and XMega32E5 eeprom troubles...

As Scott Price wrote: > After hacking around some, I found the patch below makes it work for me. > Granted, it is not a good solution, as it probably breaks things for all > other XMegas. ;) I am only using the E5 currently. Does that mean it's an XmegaE issue? Please submit a bug report:

Re: [avr-libc-dev] Release 2.0.0 is out

As Joerg Wunsch wrote: > Webpage documentation updates will happen tomorrow. Done. -- cheers, Joerg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/ Never trust an operating system you don't have sources for. ;-) ___

[avr-libc-dev] Release 2.0.0 is out

The long-requested, long-awaited next avr-libc release is out. There were some last-minute changes, triggered by a new version of Doxygen bein unable to pick up documentation from .S assembly code files, so I moved all the documentation out into the respective header file(s). Compiles under

[avr-libc-dev] [patch #8902] Xmega's PROTECTED_WRITE is incorrect for IO registers whose address is more than one byte

Follow-up Comment #3, patch #8902 (project avr-libc): OK, I checked it (on something else), and think I understand it. Please go ahead, and commit it. Btw., this Web interface mangles patches. Better post them as attachments. ___ Reply

Re: [avr-libc-dev] [patch #8902] Xmega's PROTECTED_WRITE is incorrect for IO registers whose address is more than one byte

Hi Pitchumani, > Is this ok for trunk? If you are sure about it: yes. I tried to understand it, but without reviewing the respective datasheets and generated code, I could not decide whether it is correct or not. Ideally, this should be accompanied by a testcase in the testsuite, to

Re: [avr-libc-dev] [avr-libc-commit] [2498] Fix make distcheck errors.

As Pitchumani wrote: > Revision: 2498 > http://svn.sv.gnu.org/viewvc/?view=rev=avr-libc=2498 > Author: pitchumani > Date: 2016-01-28 11:17:55 + (Thu, 28 Jan 2016) > Log Message: > --- > Fix make distcheck errors. Thanks for spotting it, I didn't have the time to

Re: [avr-libc-dev] Need new avr-libc release

As Sivanupandi, Pitchumani wrote: > I'll push few more devices support. Please hold the release for a > day. Will do, I might do some other release preparations in the meantime (bumping version numbers, have a look at the documentation etc.) If make distcheck passes again, this is good. --

Re: [avr-libc-dev] Need new avr-libc release

As Sivanupandi, Pitchumani wrote: > Can you make a new release? I can give it a try, to see whether "make distcheck" works out of the box. What's the opinion of others, are there any show-stoppers in the current state of the tree? -- cheers, Joerg .-.-. --... ...-- -.. .

Re: [avr-libc-dev] Need new avr-libc release

As Joerg Wunsch wrote: > I can give it a try, to see whether "make distcheck" works out > of the box. Pah: gmake[3]: Entering directory `/home/joerg/src/avr-libc/avr/lib' (cd avr2 && gmake top_distdir=../../../avr-libc-1.8.1svn distdir=../../../avr-li

Re: [avr-libc-dev] Need new avr-libc release

As Joerg Wunsch wrote: > As Joerg Wunsch wrote: > > > I can give it a try, to see whether "make distcheck" works out > > of the box. > > Pah: > gmake[4]: Entering directory `/home/joerg/src/avr-libc/avr/lib/avr2' > (cd at90s1200 && gmake top_

Re: [avr-libc-dev] missing pgm_read_ptr

As Maurin Donneaud wrote: I have linux avr-libc 1:1.8.0-4.1 installed I'm wondering why pgmspace.h do not have the pgm_read_byte macro ? $ fgrep pgm_read_byte ~/src/avr-libc/include/avr/pgmspace.h pgm_read_byte_near() or pgm_read_word_near() instead of pgm_read_byte_far() or

Re: [avr-libc-dev] [patch #8587] Move device specific functions to libdev.a

As Pitchumani wrote: Follow-up Comment #7: Device library build is based on compiler detected or configure option. Curious, would it be time to build a new release, do you feel comfortable with the status quo? -- cheers, Joerg .-.-. --... ...-- -.. . DL8DTL

[avr-libc-dev] [bug #45304] Will it be possible please to add support and document all possible interrupts for ATmega16/32HVB ATmega8/16HVA

Update of bug #45304 (project avr-libc): Severity: 3 - Normal = 2 - Minor Status:None = In Progress Assigned to:None = joerg_wunsch

Re: [avr-libc-dev] [bug #45067] inconsistency errors in crc.hdocumentation

As Jan Waclawek wrote: In my experience, the only thing which really helps in disambiguating CRC calculation is a couple of simple but nontrivial input examples together with the respective outputs. I could probably live with that. -- cheers, Joerg .-.-. --... ...-- -.. .

[avr-libc-dev] [bug #45067] inconsistency errors in crc.h documentation

Follow-up Comment #1, bug #45067 (project avr-libc): Unfortunately, the bit order of the CRC polynomial appears to be one of the things where there is never consensus about. :( Just because you cite pycrc as one source, you'll as well be able to find numerous other sources quoting the

  1   2   3   4   5   6   7   8   9   >