As Wouter van Gulik wrote:
Ok, good that is is known but I don't really get the concept of private
bugs.
Maybe because it's somehow a potential security issue?
That has probably been the intention for why the Web interface offers
that item at all, and somehow the submitter of bug #19079
Update of bug #11714 (project avr-libc):
Privacy: Private = Public
___
Reply to this item at:
http://savannah.nongnu.org/bugs/?11714
___
Update of bug #12557 (project avr-libc):
Privacy: Private = Public
___
Reply to this item at:
http://savannah.nongnu.org/bugs/?12557
___
As Joerg Wunsch wrote:
That has probably been the intention for why the Web interface offers
that item at all, and somehow the submitter of bug #19079 (most likely
inadvertently) selected that feature.
I disabled the privacy field in the Web form, because I think it
doesn't make any sense
As edward baafi wrote:
Ok.. The author is Joerg Wunsch and the document is here:
It's actually example code, rather than meant to be a really universal
LCD driver. But yes, I tried to make it flexible enough so someone
else (or even myself :) could reuse it for a real-world project as
well
Update of bug #21228 (project avr-libc):
Status:None = Fixed
Open/Closed:Open = Closed
___
Reply to this item at:
As Eric Weddington wrote:
Currently, some devices are opitimized for speed in
devtools/gen-avr-lib-tree.sh. I'd like to change the current setup
to optimize for space for all devices. See attached patch.
The question is whether distinguishing CFLAGS_SPACE and CFLAGS_SPEED
still makes any
As Eric Weddington wrote:
Admittedly, no, I haven't done those comparisons. Both CFLAGS_SPACE
and CFLAGS_SPEED use -Os, but CFLAGS_SPACE also adds
-mcall-prologues, so that is the only difference between the
two. Using -mcall-prologues is useful and will reduce code size as
the application
[EMAIL PROTECTED] (Erik Christiansen) wrote:
How does a GNU assembler-only project specify fuse settings, lock
bit settings, etc., in this potential scheme?
If I've correctly understood Joerg, then the magic addresses are
specified by linker script memory regions. I'd expect to just do the
As Patrick Mahoney wrote:
It might not be an actual reset because all bits in the MCUSR register
are cleared. So it could be a jmp to address 0, but it doesn't make more
sense... Again, the sims run perfectly...
Smells like either a problem with the stack initialization, or you've
enabled an
Update of bug #20843 (project avr-libc):
Priority: 5 - Normal = 7 - High
Assigned to:None = joerg_wunsch
___
Follow-up Comment #1:
I suspect this is
As Harald Kipp wrote:
No idea what __init() is intended to do, but it won't help: No
initialized stack pointer, no return.
__init() is the name of the routine jumped to from the reset vector.
crtXXX.o provides a default implementation which is marked weak, so
you could overlay it by your own.
As Bob Paddock wrote:
That would be worth a bug report, I'd say.
MCUCR in the Mega162:
SRE SRW10 SE SM1 ISC11 ISC10 ISC01 ISC00
MCUCR in the Mega325:
JTD - - PUD - - IVSEL IVCE
Ah, I see... OK, that's multiple generations of AVRs between both, so
the contents of MCUCR gradually shifted.
As Chris Spencer wrote:
I'm not sure if this is a bug, but when I try to build an rpm from the
tarball/spec file like:
rpmbuild -tb --target avr --clean avr-libc-1.4.6.tar.bz2
I get the error:
make[4]: *** [refman.dvi] Error 1
I've seen a similar error on a recent FreeBSD but it's not my
As Bob Paddock wrote:
(About MISRA and bit-fields.)
A *signed* integer requires two bits, one for the value, the other
for the sign of the value. Don't see that as an issue,
as it would not make sense to have a signed register bit for I/O.
Sure, that way, it makes sense. I'm pretty sure we
As Bob Paddock wrote:
Atmel sometimes transfers bits from one register
to another (for example, SE is moved from MCUSR to SMCR).
What is even worse is when they use the same register name
for completely different functions, which I've ran into
when moving code from one device to an other.
As Chris Spencer wrote:
Running latex -version gives me:
pdfeTeX 3.141592-1.21a-2.2 (Web2C 7.5.4)
kpathsea version 3.5.4
That's exactly what I get here, but I think it's also what I used to
get with the older LaTeX version.
Why does avr-libc even need latex? Is it just for documentation?
As Dmitry K. wrote:
TCCR0B = _BV(CS00) | _BV(CS02);
would be rewritten as
TCCR0B_.byte = _BV(CS00) | _BV(CS02);
A small note: the above expressions are *different*.
No, they aren't. The .byte union member simply access the entire
8-bit IO register the same way as the current
As Eric Weddington wrote:
There are new devices that need support:
AT90PWM216
AT90PWM316
ATmega48P
ATmega88P
ATmega168P
ATmega328P
AT90PWM2B
AT90PWM3B
And possibly ATA6289, though I would have that as a lower priority.
Note that this issue came up because IAR recently announced support
As Bob Paddock wrote:
union tccr0b {
uint8_t byte;
struct {
uint8_t cs0: 3;
uint8_t wgm02: 1;
uint8_t : 2;
uint8_t foc0b: 1;
uint8_t foc0a: 1;
} bits;
};
MISRA-2004 rule 6.4: Bit fields shall only be
As Eric Weddington wrote:
I am new to this list, so I am sorry if this post is OT.
Btw., it would be more appropriate for the avr-gcc-list (on the same
mailman host). avr-libc-dev, as the name suggests, is rather the
forum for developers of avr-libc.
I am building my code at the command
As Joerg Wunsch wrote:
avr-gcc -mmcu=atmega8 jsp.c -o jsp.hex
That's odd considering your command line above cannot compile a C
file directly to a hex file. GCC compiles to object code (.o), then
linked to an ELF file (.elf), then converted to a hex file (.hex)
via avr-objcopy.
I
As [EMAIL PROTECTED] wrote:
The XML file for AT90USB1287 seems to be in error.
The external RAM starting address is set to $2200, but the part manual
lists it at $2100.
I think you're right. As the INTRAM starts at 0x100, it would sound
logical for EXTRAM to start at 0x2100.
I just asked
Michalkiewicz, Joerg Wunsch
+ Copyright (c) 2007 Eric B. Weddington
All rights reserved.
Redistribution and use in source and binary forms, with or without
@@ -39,16 +40,22 @@
command-line switch. This is done by diverting to the appropriate
file ttlt;avr/io/ttem/emtt.hgt;/tt
As Bob Paddock wrote:
However I have missed any Atmel documentation that says a 'out' to
SREG applies that same protection? Does that mean all 'out'
instructions delay pending interrupts, or just 'out' instructions to
SREG? What document did I miss reading?
AFAIR it applies to every method
avr-libc-1.4.6 has been released. For a list of changes, see
the NEWS file:
http://www.nongnu.org/avr-libc/NEWS.txt
Source code and documentation downloads can be found in the
avr-libc download area:
http://download.savannah.gnu.org/releases/avr-libc/
A binary release can be obtained here:
Update of bug #19009 (project avr-libc):
Status:None = Fixed
Assigned to:None = joerg_wunsch
Open/Closed:Open = Closed
As Eric Weddington wrote:
Now that this is fixed, is there anything else that needs to be
fixed before 1.4.6?
I'd like to at least have a glance at the suggested delay.h
improvement, as this appears to become a frequently requested item
lately.
I won't be able to work on my computer by
Update of bug #19862 (project avr-libc):
Status:None = Invalid
Assigned to:None = joerg_wunsch
Open/Closed:Open = Closed
Update of bug #19841 (project avr-libc):
Status:None = Fixed
Open/Closed:Open = Closed
___
Reply to this item at:
Update of bug #19445 (project avr-libc):
Status:None = Fixed
Assigned to:None = joerg_wunsch
Open/Closed:Open = Closed
Update of bug #19841 (project avr-libc):
Status:None = Fixed
Open/Closed:Open = Closed
___
Reply to this item at:
Update of bug #19427 (project avr-libc):
Status:None = Fixed
Percent Complete: 30% = 100%
Open/Closed:Open = Closed
Update of bug #19050 (project avr-libc):
Assigned to:None = joerg_wunsch
___
Reply to this item at:
http://savannah.nongnu.org/bugs/?19050
___
Update of bug #19050 (project avr-libc):
Status:None = Fixed
Open/Closed:Open = Closed
___
Reply to this item at:
As Steve Franks wrote:
FYI, We are having serious issues (reboots, etc) on the project that
generated this bug report, and cannot appear to find any
pointer/bounds issues that would cause that type of behavior.
However, just to remind you, the subject of this bug report is
*solely* to fix the
Update of bug #19771 (project avr-libc):
Status:None = Duplicate
Assigned to:None = joerg_wunsch
Open/Closed:Open = Closed
Follow-up Comment #1, bug #19666 (project avr-libc):
Agree about ADTS3.
ADHSM was supposed to be discontinued some years ago, and
we thus removed it from all avr-libc header files. Seems
like a cutpaste-o to me that it still reappears in some
datasheets. I opened an ATticket to see whether it
Update of bug #19650 (project avr-libc):
Status:None = Fixed
Assigned to:None = joerg_wunsch
Open/Closed:Open = Closed
As Eric Weddington wrote:
I commmitted a small change to the Using malloc() documentation
page. I changed the title to Memory Areas and Using malloc() and
reorderd some of the sentences in the Introduction of that page.
The reason for the rather terse titles is that we've previously been
As Eric Weddington wrote:
Note the last sentence. The iocanxx.h has the correct naming with
the USART* prefix. The vector names that start with SIG* should
not be used anymore.
In general, I agree with your statement, though in this case, I'd
probably have made an exception. The iocanxxx.h
As Eric Weddington wrote:
Log message:
* include/avr/io2343.h: Add missing bit definitions
for MCUSR.
I'm fairly surprised someone really still cares for those pretty old
AVRs...
--
cheers, Jorg .-.-. --... ...-- -.. . DL8DTL
http://www.sax.de/~joerg/
Update of bug #19445 (project avr-libc):
Category:None = Documentation
Item Group: Unknown = Documentation
___
Follow-up Comment #1:
As Dave Hylands
As Dave Hylands wrote:
So it's the contents of __malloc_heap_end not the address of
__malloc_heap_end that points to __heap_end.
Right. As I wrote in the followup to the bug report, I agree the
picture is a bit misleading here, though the remainder of the
documentation explains that. I'm
As Steve Franks wrote:
Probably if the pictures had
*__malloc_heap_end == __heap_end
instead of
__malloc_heap_end == __heap_end
that would do the trick. At least in my mind.
It has a point, but it's not very exact either: it suggests
__malloc_heap_end were a pointer which
URL:
http://savannah.nongnu.org/bugs/?19427
Summary: doxygen-generated asmdemo ends prematurely
Project: AVR C Runtime Library
Submitted by: joerg_wunsch
Submitted on: Tuesday 03/27/2007 at 21:11
Category: Documentation
As Eric Weddington wrote:
I'm going through the .dox files in the doc/api directory. Why do
these files have a 2-clause BSD license instead of the 3-clause
license used for the source code?
Good question, perhaps because Ted once created them that way?
It shouldn't matter too much, as these
As Eric Weddington wrote:
Any objections, or problems in changing them to the 3-clause
license, to be consistent?
No objections from me. I don't have an idea though how many people
might have contributed who aren't already covered by their agreement
regarding the 3-clause source code license
Follow-up Comment #2, bug #19281 (project avr-libc):
Not a bug - does conform to C99 standard.
isblank() is not the same as isspace().
___
Reply to this item at:
http://savannah.nongnu.org/bugs/?19281
Follow-up Comment #4, bug #19281 (project avr-libc):
Fix in docs or in source?
We don't have locales, so we should restrict the implementation
to just space and TAB. Note the emphasis on separate words.
This is also justified by the C99 Rationale:
7.4.1.3 The isblank function
A new
As Ned Konz wrote:
According to the docs, the two macros __OPTIMIZE__ and
__OPTIMIZE_SIZE__ are already defined in avr-gcc programs, so one
could do something like this (using the existing macros):
#ifdef __OPTIMIZE__
#ifdef __OPTIMIZE_SIZE__
extern void __optimized_for_size(void);
As David Brown wrote:
Size is the main priority when you are low on flash space -
otherwise, it is irrelevant. If your chosen AVR has 16k flash, then
it does not matter if the program code takes 2k or 15.9k of that
flash. In particular, for smaller devices, program space will be at
a
As Dmitry K. wrote:
Is it by browser wrong?
I do not see a choice to commit a new bug.
Supposedly, when you move the focus over the Bugs headlin,
a drop-down menu appears that has a Submit menu entry.
This even works with JavaScript disabled, and I just tried it with w3m
(text-mode browser),
As David Breeze wrote:
It is up to you to keep track of the current channel, which you can
of course read back from the ADMUX register.
e.g.:
uint16_t adcs[8];
ISR(ADC_vect)
{
static uint8_t oldchan;
uint8_t curchan = ADMUX 7;
adcs[oldchan] = ADCW;
oldchan = curchan;
if
As bad address wrote:
we are building a avr application. We are trying to
build our application with some home grown makefiles
which were not generated by avr studio.
Hmm, you'd better derive them from a known-to-be-good one, and only
fine-tune once you understood what happens inside.
Can
As Dmitry K. wrote:
Avr-libc-CVS:
Flash, bts Stack, bts Time, clks
Function avr2 avr4 avr2 avr4 avr2 avr4
--
sprintf(s,%x,12345) 1690 1500 5757 1078 1010
As Dmitry Xmelkov wrote:
Modified files:
include/avr: pgmspace.h
Log message:
Add new function: strchr_P()
Seems like another candidate for the 1.4 branch to me.
Dmitry, could you handle these simple merges yourself, or
do you want me to assist you?
--
cheers, Jorg
As Thomas Richter wrote:
Can I write in the Application Flash Section during a running
application?
You can, but the code executing the SPM instruction must be located in
the bootloader area (as described by the fuses). Also, any code in
the non-read-while-write memory area (i.e. in the lower
As Thomas Richter wrote:
I will divide the application flash section into 3 parts where I
have 3 different applications. The boot loading process shall decide
which part shall be used.
OK, as long as it's the bootloader that wants to write the application
section, the macros from avr/boot.h
As Dmitry K. wrote:
It is not necessary to consider this mistake blocking,
it does not destroy a stack of the program. After the
termination of testing I shall update function.
OK, it's no problem either. Do you think it would be time now to roll
a 1.5.1 release, so a wider audience could
URL:
http://savannah.nongnu.org/bugs/?19050
Summary: gcrt1.S should call main rather than jumping to it
Project: AVR C Runtime Library
Submitted by: joerg_wunsch
Submitted on: Tuesday 02/13/2007 at 13:29
Category:
Update of bug #19050 (project avr-libc):
Priority: 5 - Normal = 9 - Immediate
___
Reply to this item at:
http://savannah.nongnu.org/bugs/?19050
___
As Eric Weddington wrote:
Should it be the 1.6 branch because of the new floating point
library? I'm thinking that that would be a very nice feature to
release next.
I thought of releasing a snapshot from the development branch (1.5)
for the first time, so people could test the new FP
As Eric Weddington wrote:
I'm sorry, could you clarify this? Are you suggesting that we will
have to *add* a command-line option to get the smaller code?
Yes, in the same sense as -mint8 produces smaller code when applied.
Except, -mno-mainframe causes way less portability issues.
Marek's
As Anatoly Sokolov wrote:
These changes should be reverted:
- if (main_p)
-{
- fprintf (file, (\t
- AS1 (ldi,r28) ,lo8(%s - HOST_WIDE_INT_PRINT_DEC )
CR_TAB
- AS1 (ldi,r29) ,hi8(%s - HOST_WIDE_INT_PRINT_DEC )
CR_TAB
-
As Dean wrote:
I was under the impression that the main overhead could be
eliminated via the use of the naked and/or noreturn attributes. It
seems to work in my own simple tests; is this not the case?
See Marek's discussion about __C_task (or OS_task). In short, it's a
noreturn function that
As Dmitry K. wrote:
What is the necessity of occurrence __AVR_HAVE_MUL__
in common/macros.inc? Is it not the same as
__AVR_ENHANCED__?
Anatoly recently introduced two new AVR categories into GCC: avr25 and
avr35. They should be though of as avr2.5 and avr3.5: while they
share almost
As Dmitry K. wrote:
Besides there is an opportunity a little to reduce a code.
I guess you are going to summarize the white space checks as
if (c == ' ' || (c = BEL c = CR)) ...
are you?
I wonder whether we should care about a *real* ctypes implementation
some day, i.e. about something that
As Anatoly Sokolov wrote:
I consider that the __AVR_ENHANCED__ macro should be obsolete. I
asked Denis the sanction to remove __AVR_ENHANCED__ from the GCC 4.3
or later version, but he was against. Hence the __AVR_ENHANCED__
will be present in the compiler still some time.
That's probably a
As Raymond Moore wrote:
Probably related to this P/nonP thing. I have recently acquired
some atmega324 chips and when attempting to compile for them, GCC
and binutils differ as to whether it is atmega324 or atmega324p...
You are not supposed to be able to get your hands on non-P ATmega324
Follow-up Comment #2, patch #5647 (project avr-libc):
I wrote a small script to create the header file #defines out
of the XML files. I see two differences between the non-P and
the P version:
1) All USART names have been changed to USART0. However, this
does not match the datasheet of the
Update of bug #18686 (project avr-libc):
Status:None = Fixed
Assigned to:None = joerg_wunsch
Open/Closed:Open = Closed
As Tero Sinervo wrote:
What happened was I never bothered to check if it really works,
fooled by the absence of 'p' in the individual header files, coupled
with this line in iomxx4.h:
/*
* Only ATmega164/324 have a second USART.
*/
OK, I fixed that.
Historical note on this is, the
Update of bug #18818 (project avr-libc):
Open/Closed:Open = Closed
___
Follow-up Comment #3:
Confusing comment has been fixed in that header file.
Update of bug #18806 (project avr-libc):
Status:None = Wont Fix
Open/Closed:Open = Closed
___
Follow-up Comment #2:
Flagged as won't
Update of bug #18806 (project avr-libc):
Assigned to:None = joerg_wunsch
___
Follow-up Comment #1:
The interrupt vector names are derived directly from the Atmel
part XML files. If you think
As Yann GOUY wrote:
so, is there a trick to compile C for the attiny84, such as giving
the -mmcu=avr2 option to avr-gcc and defining a _ATTINY84_ before
every inclusion of avr/io.h?
The trick is that you have to patch your binutils and GCC first,
*before* compiling avr-libc.
See this
As Dmitry Xmelkov wrote:
Modified files:
. : bootstrap
Log message:
Version 2.60 for autoconf is added
This one is probably a candidate for being merged into the 1.4 branch.
Perhaps the doc change to include/stdlib.h might also be merged, what
do you think?
Do
As Robert Schiele wrote:
When specifying -mint8 on the compiler command line the typedef of
(u)int64_t leads to an error thus I suggest the following patch:
Thanks. Patch committed with some minimal changes (mostly pertaining
to the doxygen part).
--
cheers, Jorg .-.-. --...
As Dean wrote:
Joerg: If eventually accepted I will of course ask the original
author for permission, and add him to the copyright. I hope I don't
get too annoying here bouncing my ideas off you all; I tend to get
over-enthusiastic about the simplest of things.
No, it's completely fine to
As Ron wrote:
I have used these two for some time now.
static inline STATE_REG SaveState(void)
{
STATE_REG flags = SREG; // get processor state
cli();// turn off interrupts
return flags; // return machine state
}
This is something like the
Update of bug #18688 (project avr-libc):
Item Group:None = Documentation
___
Reply to this item at:
http://savannah.nongnu.org/bugs/?18688
___
Update of bug #18686 (project avr-libc):
Item Group:None = Documentation
___
Reply to this item at:
http://savannah.nongnu.org/bugs/?18686
___
Update of bug #18115 (project avr-libc):
Item Group:None = Documentation
Summary: online documentation typo/bug = online
documentation typo/bug avr/boot.h
___
Reply to this
Update of bug #17815 (project avr-libc):
Item Group:None = Build system
___
Reply to this item at:
http://savannah.nongnu.org/bugs/?17815
___
Update of bug #17216 (project avr-libc):
Item Group:None = Header files
___
Reply to this item at:
http://savannah.nongnu.org/bugs/?17216
___
Update of bug #14855 (project avr-libc):
Item Group:None = libm code
___
Reply to this item at:
http://savannah.nongnu.org/bugs/?14855
___
Update of bug #11820 (project avr-libc):
Item Group:None = libm code
___
Reply to this item at:
http://savannah.nongnu.org/bugs/?11820
___
Update of bug #11511 (project avr-libc):
Item Group:None = libm code
___
Reply to this item at:
http://savannah.nongnu.org/bugs/?11511
___
Update of bug #3485 (project avr-libc):
Item Group:None = libm code
___
Reply to this item at:
http://savannah.nongnu.org/bugs/?3485
___
Update of bug #1929 (project avr-libc):
Item Group:None = libm code
___
Reply to this item at:
http://savannah.nongnu.org/bugs/?1929
___
I added item groups to the bug tracker, so they could be classified.
I also added a query form named Item groups. Unfortunately, the
standard query cannot be changed, so if you simply select Bugs -
Browse, you'll always end up using the (system-wide) Basic query.
Open the (+) Display Criteria on
Update of bug #18662 (project avr-libc):
Status: Confirmed = In Progress
___
Follow-up Comment #1:
This is an issue with the original BSD implementation our
implementation has been taken from.
Update of bug #18688 (project avr-libc):
Status:None = Fixed
Assigned to:None = joerg_wunsch
Open/Closed:Open = Closed
Update of bug #18115 (project avr-libc):
Status:None = Fixed
Assigned to:None = joerg_wunsch
Open/Closed:Open = Closed
Hi Dean,
thanks for your suggestion, and for getting here to the mailing list
with these. I hope others might also state their opinions about it,
as I think this issue occasionally came up as a request in some
discussions.
My macro allows for both atomic (interrupts disabled) and non-atomic
Update of bug #18673 (project avr-libc):
Status:None = Duplicate
Assigned to:None = joerg_wunsch
Open/Closed:Open = Closed
Update of bug #18169 (project avr-libc):
Status:None = Duplicate
Assigned to:None = joerg_wunsch
Open/Closed:Open = Closed
As Julian Bleecker wrote:
I am attempting to port some krufty IAR code to GCC for the
AT90USB1287.
Pester Atmel about it. They've got GCC code as well.
Looking further, I think the vectors in iousbxx6_7.h are all off by
one, ...
The avr-libc and the Atmel numbering are in general off by
As Eric Weddington wrote:
Pester Atmel about it. They've got GCC code as well.
Hey, Joerg: Do you remember which email address it is to pester that
group in Atmel?
I think there's nothing else but [EMAIL PROTECTED] from a customer's
point of view. They'll probably pass that on to France
601 - 700 of 868 matches
Mail list logo
