Follow-up Comment #2, bug #50501 (project avr-libc):
I wouldn't recommend to do this unless explicitly allowed by datasheet or an
Atmel insider approves it. Depending on the particular implementation of
EEPROM, write distrubs may decrease read reliability. This is not something
which can be
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 know it sounds/looks bad in the documentation, but it really helps.
Jan Waclawek
Forgive my ignorance, but would this address the seemingly related error:
libc.a(isspace.o)*:In function `isspace'
(.text.avr-libc+0x2)*:relocation truncated to fit: R_AVR_13_PCREL against
symbol `__ctype_isfalse' defined in .text.avr-libc section in
... :-)
-
Sorry for side tracking, but could the issue of the xxx_PF() functions not
clearing RAMPZ, discussed recently on the avrfreaks' avr-gcc subforum, be
addressed at the same time?
Thanks,
Jan Waclawek
___
AVR-libc-dev mailing list
AVR-libc
Follow-up Comment #1, bug #38021 (project avr-libc):
It is a very bad idea overall. It would increase code size of existing
programs, with little to no benefit except of a negligibly small group of
applications.
1. FLASH is inherently non-volatile; SPM out of bootloader context is uncommon
and
=PNphpBB2file=viewtopicp=1023806#1023806
Jan Waclawek
PS. I know I should submit this as an enhancement request to the tracker,
but I lost access to the e-mail account bound to my savannah account (and
of course thanks to the complex password required policy, never
remembered the password
Floating point equivalence is not guaranteed so is this comparison valid ?
C99 in 5.2.4.2.2#5 says:
The accuracy ofthe floating-point operations (+, -, *, /) and of the
library functions in math.hand complex.h that return floating-point
results is implementation-defined [...] The implementation
PS. Are you sure you linked against avr-libc's math library?
It linked against the libc math libraries .
How exactly?
Also adding to the points mentioned above, is it required to use the logrithms
for getting this done as we explicitly say the second argument of pow should
be an
URL:
http://savannah.nongnu.org/bugs/?36124
Summary: Improve documentation on .bss clear when used in
assembler
Project: AVR C Runtime Library
Submitted by: wek
Submitted on: Sat 07 Apr 2012 02:02:23 PM GMT
Category:
That's because .initX sections *are* located after .progmem etc.
You want to have a look at the default linker scripts, and probably want to
place your experimental stuff into .vectors (which would probably be sort of
obvious if you had a look at the original vectors table source in gcrt1.S).
I am really not sure. There is no read use of such a type, it's just because
some guys are to lazy to type some letters. Moreover in the case of pointers,
you have the difference between pointers, const pointers, pointers to const and
const pointers to const etc. and all for arbitrary number of
Just want to remark that these issues had been discussed already in the thread
stemming from
http://lists.nongnu.org/archive/html/avr-libc-dev/2011-09/msg00025.html and on
several occassions on avrfreaks.
JW
- Original Message ---
On 10/01/2012 08:13, Joerg Wunsch wrote:
As
in source form,
with appropriate changes ithe documentation.
Jan Waclawek
___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
https://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Strictly, that description is only guaranteed to apply to the SEI
instruction, not to other ways that modify the I flag.
Indeed.
I stand corrected; sorry for confusion.
Jan
___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
What exactly do you mean by safe in this context, and how could that be
discovered or shown?
The user who wants to declare a variable to be positioned in FLASH (code
memory), and obeys the deprecation warning, is now presumably recommended to
write the PROGMEM keyword after the type, e.g.
Follow-up Comment #4, bug #33698 (project avr-libc):
It appears to me that most of those 135 places (those which rcall to external
label, perhaps indentified by the _U() macro) are potential errors, e.g.
http://www.avrfreaks.net/index.php?name=PNphpBB2file=viewtopict=108109 and
many more.
But
IMO such macros are bad style, there is no reason for them.
I already said what is the reasons for them, here:
https://savannah.nongnu.org/bugs/?33716 and here
http://www.avrfreaks.net/index.php?name=PNphpBB2file=viewtopicp=871000#871000
. And I repeat, it is a feature for the users, and a
.
I here repeat what I've already said in
http://www.avrfreaks.net/index.php?name=PNphpBB2file=viewtopicp=871000#871000
Jan Waclawek
___
Reply to this item at:
http://savannah.nongnu.org/bugs/?33716
Follow-up Comment #9, patch #6352 (project avr-libc):
You seem to have misunderstood my comment.
Carlos's library is fully adequate for its purpose and has been used for that
purpose by several users months or even years before it has been accepted in
1.7.0; the problem is that it is incorrectly
Follow-up Comment #1, bug #32945 (project avr-libc):
This appears to be a consequence of the problem reported in
https://savannah.nongnu.org/patch/?6352 (thus duplicate).
___
Reply to this item at:
), and you told that you are
going to issue a new edition of WinAVR soon. Cumulatively, these gave me the
impulse to make this post.
Jan Waclawek
___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
https://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Follow-up Comment #7, patch #6352 (project avr-libc):
The _PF functions in the respective binary libraries are broken, and they ever
were, since the've been added to avr-libc in 1.7.0.
They don't use the ELPM instruction rather, incorrectly, the LPM instruction.
The reason is, that these
URL:
http://savannah.nongnu.org/bugs/?30669
Summary: improve comment in stdiodemo
Project: AVR C Runtime Library
Submitted by: wek
Submitted on: Fri 06 Aug 2010 07:01:08 AM GMT
Category: Documentation
Follow-up Comment #6, patch #6352 (project avr-libc):
The xxx_PF() functions modify the RAMPZ register, but on XMegas with EBI,
RAMPZ influences also LD/LDD/ST/STD, making code after using xxx_PF() to
access unintended data memory pages.
In the attached file, in macros.inc, macro
Follow-up Comment #6, bug #26365 (project avr-libc):
In attachment, pgmspace.h and an example linker script (avr6).
Changes in pgmspace.h against
http://svn.savannah.nongnu.org/viewvc/trunk/avr-libc/include/avr/pgmspace.h?revision=2168root=avr-libcview=markup
:
- documentation related to
Regarding the linker script section names, that should certainly be
mentioned in the description (so it eventually goes into the avr-libc
documentation), independent of whether Eric provides a patch in the
next version of the WinAVR successor. Can you please submit a
paragraph for that, Jan?
#$%^... sorry. Mea culpa.
Joerg, would you please fix it? Thanks.
Jan
On Thu, 10 Jun 2010 22:25:12 +0200
Wouter van Gulik wvgu...@xs4all.nl wrote:
Joerg Wunsch schreef:
+
+\code
+#define cli() __asm volatile( cli ::: memory )
+#define sei() __asm volatile( sei ::: memory )
+
(unfortunately had no
time to move on really on this)
http://www.avrfreaks.net/index.php?name=PNphpBB2file=viewtopict=90149
You might also want to notify the audience on the avr-gcc forum on
avrfreaks.net on the major changes you've just made - there appears to be a
higher attendance there than here.
Jan
It's a little unfair that you repost a message to the list which
you've sent me personally only before, and which I've already replied
to.
Although I did not mean my post to be private, and reply often as private due
to the nonstandard setting of this forum, you are right.
I apologize.
JW
I would also like very much to finally add the FAR macros that Carlos put
together a long time ago, or something very similar. I don't remember if
there was ever any issues with them that need to get resolved, or if there is
basic agreement that these should be added the way they are etc.
/2010 14:55, Jan Waclawek wrote:
I would also like very much to finally add the FAR macros that
Carlos put together a long time ago, or something very similar. I
don't remember if there was ever any issues with them that need to
get resolved, or if there is basic agreement that these should
3) Resolving the compiler/linker issues, specifically code generated
when the gs() macro kicks in. Jan, I'm still not convinced its purely a
linker error, more likely a problem with gs() but I didn't get to dig
much further.
I believe the most competent to judge is the author of that patch,
Follow-up Comment #5, patch #6352 (project avr-libc):
Adding one more function, memcmp_PF().
Jan Waclawek
(file #20682)
___
Additional Item Attachment:
File name: memcmp_PF.zip Size:4 KB
to be used with appropriate caution (and documented
accordingly).
Jan Waclawek
- Original Message ---
Subject: Re: [avr-libc-dev] New pgm_read_ptr() macro?
From: David Brown da...@westcontrol.com
How about a more general solution based on typeof and sizeof
=92866start=20postdays=0postorder=aschighlight=.
Jan Waclawek
___
Reply to this item at:
http://savannah.nongnu.org/bugs/?28058
___
Message sent via/by Savannah
http://savannah.nongnu.org
Follow-up Comment #5, bug #26365 (project avr-libc):
No patches which could be added with no effort from the side of project
maintainers, yet (and zero likelihood of them ever); but for those who are
interested, some of my solutions of the items below are now posted here
Still, what would hurt to list both?
Jan Waclawek
- Original Message ---
Good policy. Thanks.
Hi,
I have noticed that iom16.h, iom323.h, iom32.h, and iom8.h all define
USART_RXC_vect and USART_TXC_vect
while the headers for other micro-controllers define
USART_RX_vect
Well, there are (unfortunately) more stumbling blocks along that road.
That starts with older devices naming their registers just UDR, UCSRA
etc. while newer AVRs always number them (UDR0, UCSR0A) even if there
is only one USART available.
Again, why couldn't both be listed for the older
)(__LPM((uint16_t)(addr)));
}
[Please note that in my initial submission, the markup feature eat up the
double-underscores around __attribute__ and __always_inline__ to single
underscores...]
Jan Waclawek
___
Reply to this item at:
http
Follow-up Comment #4, bug #28108 (project avr-libc):
This bug has been discussed extensively in the avrfreaks.net thread to which
the link is given in the original bugreport.
It has been confirmed that while the given code DOES result in erratic
binary, reducing the given code results in
Please follow the avrfreaks link given by OP for further discussion and a link
to a similar bug already reported and apparently solved.
JW
___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
May be we looking forward also to a decent changelog, this time?
Jan Waclawek
___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Could someone perhaps give a real example we could chew upon?
What should an API or whatever look like?
Isn't the issue with multiple different AVRs related more to
the library routines themselves rather than to an API?
Well, actually a few of us have provided examples.
I fail to
On Fri, 18 Sep 2009 13:45:47 -0700
Ruddick Lawrence rudd...@stanford.edu wrote:
The confusion I was talking about with LibAVR was not with the existing
Procyon library, but with avr-libc. Of course that only becomes a problem if
they are indeed separate projects, which brings me to my second
cleanly, allocating zero bytes for test.
IMHO, this is a compiler bug.
Jan Waclawek
___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Follow-up Comment #2, bug #26365 (project avr-libc):
I beg to differ.
The request is a list, of which only the first item is duplicate of patch
#6352.
Shall I submit it as a series of feature requests, rather?
JW
___
Reply to this
Follow-up Comment #4, bug #26365 (project avr-libc):
What is then the appropriate form of posting feature requests, which are not
likely to be implemented immediately, but still might be an inspiration for
anybody who has time to pick up older ideas in the future?
My naive idea was, that
if the initialiser is 32kB, but compiles cleanly
(albeit incorrectly) if the initialiser is 64kB.
Thanks,
Jan Waclawek
___
Reply to this item at:
http://savannah.nongnu.org/bugs/?26365
URL:
http://savannah.nongnu.org/bugs/?23703
Summary: eeprom_write_ functions optimisation
Project: AVR C Runtime Library
Submitted by: wek
Submitted on: Wednesday 06/25/2008 at 10:24
Category: Feature Request
49 matches
Mail list logo
