Le 01/03/2012 11:25, Richard Zetterberg a écrit :
I have a ATmega328-PU chip which I have programmed with a bare minimum
program which sets PB0 to output and then runs a function which sets the
pin to HIGH. The problem is that the voltage output of the pin is at
10-20% of what it should be,
Hi List.
When using -fshort-enums, the definition of the enumeration relative to
the place where the enumeration is referenced gives different memory
allocation sizes for the enum. When linking different objects, one may
have a program using different width for the same variable.
Here is an
I would look at the source but unless I am mistaken Atmel still has not
released the patches for 4.5.1, does anyone know the status on these
patches, especially for the xmega support?
Yes, the patches for xmega support are pretty much the same as the latest
release of WinAVR (20100110), but
Le 04/03/2011 05:23, Weddington, Eric a écrit :
(In addition, WinAVR is about to be
deprecated
in favor of a toolset integrated into AVR Studio. It is on it's last
official
release, at least officially.)
Officially, it's up to me what to do with WinAVR. Admittedly there hasn't been
a lot
Le 07/06/2010 23:15, Weddington, Eric a écrit :
It's still tricky to have WinAVR quality on Linux
What do you mean by that? I've been working on linux for
quite some time
now and I'm wondering what the gcc in WinAVR could do better than my
avr-gcc installed from the repositories?
Le 07/06/2010 18:13, Graham Davies a écrit :
Me Again: Actually, it's so easy now that I have a hard time imagining
it being easier. The only tricky thing is that you can't install
WinAVR to a path that has a space character in it, such as Program
Files, but even that doesn't bite me as I
Hi Lars.
I don't understand what 'tmpbuf' is declared 'static'. And what do you
mean by 'broken'? In your example, main() calls functions by providing
pointers to uninitialized data located in the stack. Having functions
being inlined completely changes the stack usage. Maybe your program
Hi All.
I still have at hand that nice perl script from John Regher and revised
by Xuejun Yang (stack.pl) that I hacked a bit to have it working
correctly for GCC 4.3.0. It takes a .elf file as input and explores all
the possible execution paths to return the maximum stack usage, taking
into
Robert von Knobloch wrote:
Curiously I could not use e.g.
asm (test_pgm_read_byte:jmp pgm_read_byte);
undefined reference to 'pgm_read_byte' although it is defined and in
scope.
Where pgm_read_byte is a library function from avr-libc.
I think this is because pgm_read_byte() is a
David VanHorn wrote:
How would I construct a lookup table of logarithms in program memory?
I'll need the logarithm of N entries between 0 and 1, ex: If N = 10,
then I need log(0), log(0.1), log(0.2) etc.
I don't know what precision I'll need yet, but I'll need to be
adjusting N, so manually
Hi Dave.
In both of these cases, volatile is insufficient because it does not
imply atomic. In the first case, you need an atomic
read-modify-write, and in the second you need an atomic read of a wide
value. In both cases you can achieve that by enclosing the the
variable access in a
Hi.
Did you try with:
-finline-limit=10
-fno-if-conversion
-mcall-prologues
I ran into similar problems with code size and these options made the
code fit in a bootloader area (however my bootloader is much bigger
thant 512 bytes)
I've also seen that EEPROM related function calls were
You must also consider if your target MCU is supported by a particular
version of GCC. If you have a target supported only in the last
versions, your choice between GCC versions will narrow.
Bernard
David Carr wrote:
By reliability, I mean least probability of undetected errors in
machine
I had a quick look... a guess: since the interrupt handler is polling
the counter that triggers the interrupt, the mcu may spend its whole
time in the interrupt handler. Could you time the interrupt handler? Are
you sure that the delay loop is really 'stuck'? I'd rather bet that it
crawls
Since the 16 bits code should be running a little bit slower than the 8
bits version, maybe the target fires up its watchdog? Also how do you
test that PORTA is correctly set on the 8 bits version ? (I don't see
any DDRA setting to use bit zero of PORTA as an output)
Bernard
Brian Neltner
Hi Eshwaran.
Here is what I did to have avr-gcc and friends on Fedora 9:
- Get WinAvr (20080610) :
http://sourceforge.net/project/showfiles.php?group_id=68108
- Get GNU Binutils (2.18): http://sources.redhat.com/binutils/
- Get GCC (4.3.0) : http://gcc.gnu.org/
- Get avr-libc:
Hi Michael.
I think that you hit this bug: http://savannah.nongnu.org/bugs/?23969
Compile with -Os until the problem is fixed (or with any optimization
level different from 0 or 1)
Regards,
Bernard
Michael wrote:
Hi, I am finding that I have to disable interrupts when reading the
eeprom
Hi Andy.
avr-gcc -c -mmcu=at90can128 -finline-limit=10 -mcall-prologues -g -Os
-fsigned-char -funsigned-bitfields -fpack-struct -fshort-enums
-Wstrict-prototypes -std=gnu99:
section size addr
.text 68232 0
.bss 3557 8388864
.stab 157716 0
How a 'void' function can return something? Normally the compiler
refuses such code..
Douglas Hammond wrote:
*[..snip..]*
void test(uint8_t axis_index) {
return (_axis[axis_index].state);
}
[..snip..]
void test(uint8_t axis_index) {
axis_control_s* axis = (axis_control_s*)
Weddington, Eric wrote:
I'm currently working on a new WinAVR, with the offending patch removed, and I
hope that this will finally clear up the problems. After I release WinAVR, and
no one is screaming that it is causing bad code to be generated then I will
post the patches on the WinAVR CVS.
Weddington, Eric wrote:
FSF stock 4.3.0 is broken for the AVR port. You have to have a slew of
patches to get code generation right. See the patches (gcc, binutils,
others) that come with the WinAVR 20080411 package.
Hi Eric.
Is there any chance that GCC 4.3.1, about to be released around
Malloc() and friends are not reentrant, they use globals to handle the
freelist. To share that list, you would need a locking mechanism and
such a mechanism is usually OS specific and could not be provided by
avr-libc (IMHO). So in some cases it will be difficult to provide more
than
Javier Almansa Sobrino wrote:
The problem is I can't understand the malfuncion of malloc... :-S
Usually malloc() get nuts when you free() a wrong pointer, or you
overwrite some bytes just around an allocated area: depending of the
implementation of malloc, bytes around the malloc'ed area
Scott Morken wrote:
Hi
I have an application that jumps to the bootloader using this function
(it's a slightly modified avr109 bootloader made by atmel):
void (*funcptr)( void ) = (void *)0x3800; // Set up function pointer
to the bootloader start.
I call it when a command is sent over the
If you focus on erasing the chip to regain control of it, then you can
use nearly anything that provides logical zeros and ones as a clock.
For instance I recovered chips sometimes by using UART traffic because
I had no other hardware at hand: I took a RS232-UART converter, sent a
big file
Hi All.
Do you know if this patch will make it in the 4.2.2 release expected
around September 18th ?
Thanks!
Bernard
Anatoly Sokolov wrote:
Anatoly Sokolov wrote:
Hi.
This patch optimizes logic left shift of unsigned char by 4, 5, and 6,
excluding double 'andi' instructions in some
Vincent Trouilliez wrote:
I replaced the '' operator with the more appropriate '' one works
much better... 5 instructions instead of 115 (3 + 6*18 + 4) for the
previous code.
Unfortunately, '' and '' are very different. '' is the correct bit
operator to use, '' will check the result
Vincent Trouilliez wrote:
Now your problem with 'address 0x0004' is a real one: avr-gcc is
not yet very good with 32 bits operators
Well, this way we have nice things to be looking forward to, for
upcoming releases of gcc :-)
(BTW what version of avr-gcc do you use?).
Vincent Trouilliez wrote:
I tried:
eeprom_read_block( ui_param_status, 0, PARAM_NB);
but it's doing something funky !
Once I program this into the AVR, and let avrdude reset it, and it runs
for the first time, it will write 0xFF to all concerned EEPROM
locations ! But, if I then modify the
Timothy Smith wrote:
i want the following code to light the led connected to porta pin0, it
should work?
I don't think so. Try:
main()
{
DDRA|= 1PA0;
PORTA|=1PA0;
}
Bernard
___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
Haase Bjoern (PT-BEU/EMT) * wrote:
1.) IMO the fastest way will be to insert jump stubs to the function
entry point in the lower 128k as part of the prologues
Will this work when one wants to write a bootloader ?
Bernard
___
AVR-GCC-list
Haase Bjoern (PT-BEU/EMT) * wrote:
At which address does the bootloader code end up?
Always at the end of the flash... from 4 to 32 pages of 256 bytes
reserved from the end.
Now one may need more than 8K bytes of program size for a complex
bootloader and so extend its size downward from
Haase Bjoern (PT-BEU/EMT) * wrote:
After reading your message I conclude that you will probably not be having any
problem unless that you are planing to use pointers to functions in your
bootloader code. The jump stubs will be used *only* in case that you are using
a function pointer because
Peter Zuur wrote:
Hello everyone,
I’m not sure whether I’m addressing this to the proper list, but does
anyone know about a small footprint open-source PPP stack optimized
for the AVR series?
Hi.
Have a look at NutOs. I saw a PPP layer in the OS, but I did not used it
yet. Everything
Vincent Trouilliez wrote:
It's just that I find the use of pointers a bit inconsistent, the syntax
and operators change depending on whether you work on discrete data
types, or complex ones like structures or arrays, so I sometimes find
myself scratching my head when I have to use pointers on
User Tomdean wrote:
I have been using an stk500/atmega16 on FreeBSD 5.4, with avr-gcc
(GCC) 3.4.3, avrdude: Version 4.4.0, as happy as can be. Suddenly, I
cannot program the atmega16. I can communicate with it on the spare
UART port and the same FreeBSD serial port.
However, I can program
Björn Haase wrote:
Russell Shaw wrote on Montag, 5. September 2005 02:39 :
I'd rather adapt to a newer and better api than continue with old junk.
I agree. One should be prepared to face a flaming war on this list, but I
think that a substantial improvement is worth to endure this.
Joerg Wunsch wrote:
As the malloc()-less API change is long overdue, I'd rather move that
in by the same time. We're going to have a new library minor version
number, so we are eligible for an API change anyway.
Great!
How about the following API:
#define __STDIO_FBUF_SIZE
Haase Bjoern (PT-BEU/EMT) * wrote:
Which compiler version have you been working with for your tests?
Yours,
Bjoern
I'm using gcc-3.4.4 with avr-libc-1.2.5 . I tried gcc-4.0.1 but the
result with the 'big file' was bigger
than with gcc-3.4.4.
Anyway, with any compiler you'll get the
On 14:26:38 28/08/2005 E. Weddington [EMAIL PROTECTED] wrote:
Haase Bjoern (PT-BEU/EMT) * wrote:
Citing from the gcc documentation:
Compiling multiple files at once to a single output file in
_unit-at-a-time_ mode allows the compiler to use information gained
from all of the files when
Timothy Smith wrote:
titan# avr-gcc led.c
In file included from led.c:2:
/usr/local/lib/gcc/avr/3.4.4/../../../../avr/include/avr/io.h:252:6:
warning: #warning device type not defined
The warning says it all: you must tell avr-gcc what device you use
(-mmc=) since ports,etc differ from
Hi.
I'd like to write my own init stuf mainly because I don't have anything
in .data and I
badly need the few bytes of flash I can spare if I dont bring in the
application the code
to init .data.
I tried :
avr-gcc ... -nostartfiles
with no luck: all the .init4 stuff is still there but I've
Maybe Juan is designing his own tiny os and then needs to write a
scheduler that gives control in turn to each process? Or wants to
provide some warranty on the time taken by a system to react to an event
with a reaction too big to be run only as an interrupt? In such case it
may be necessary
Unless I've missed something, one can still face problems unless
pointers are wider than 16 bits: if a program uses PSTR() to store
strings in flash, fprintf_P and such will have to be forced to use
pgm_read_byte_far() for all targets wider then 64K. Otherwise, when one
compile the program it
44 matches
Mail list logo
