[avr-gcc-list] RE: Make question (how to)
Sorry, I misspoke: none of the variables are substituted... I know how to set variables on the command line (make MCU=atmega128... target). but how to pass a list like the C source to do custom builds with one makefile? TIA -Original Message- From: Larry Barello [mailto:[EMAIL PROTECTED] ... But this doesn't work. The SRC and ASRC are not substituted for the default ones defined earlier in the makefile (MCU and other symbols are). How do I do this? What is the magic incantation to substitute a list? ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
RE: [avr-gcc-list] Compiler error
Ok, I submitted this as a bug (#21811) and within an hour it was closed as a duplicate of #8788 which will be corrected in the 4.1.0 mainline. #8788 sounds similar, but I am still somewhat unsatisfied since a union of a three byte array and a word should be allowed in C. Maybe I just didn't understand. -Original Message- From: Haase Bjoern (PT-BEU/EMT) * [mailto:[EMAIL PROTECTED] Sent: Monday, May 23, 2005 7:31 AM To: Larry Barello; Joerg Wunsch; avr-gcc-list@nongnu.org Subject: AW: [avr-gcc-list] Compiler error I was able to reproduce your problem. I assume that the underlying problem is, that gcc does assign the mode BLKmode to your 3-Byte objects. It crashes since it does not know how to place an object of mode BLKmode into registers: Blockmode is meant to be used for memory blocks but also assigned to structs/unions of sizes that do not exactly fit into int, long int or long long int variables. Your asm code is forcing a BLKmode object into registers by using the r constraint and there's the problem: GCC does not know how to place blocks of memory into registers. E.g. have a look how your object would be returned or passed as a function parameter: GCC would probably never pass or return your union in registers but allways in memory. It's also not a problem of the avr port alone. The x86 port crashes as well with your source code. Short term (but shurly not most efficient) workaround would be to allocate 4 bytes for your union. In this case gcc will allocate a variable of mode SImode and for this type of object, gcc knows how to place SImode objects into registers. Other workaround would be to leave your object in memory. HTH, Björn -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Larry Barello Gesendet: Montag, 23. Mai 2005 16:04 An: Joerg Wunsch; avr-gcc-list@nongnu.org Betreff: RE: [avr-gcc-list] Compiler error Nope, my problem seems much worse and is in the asm constraints handling. Attached is all details. -Original Message- From: Joerg Wunsch ... What's the actual error message? (And which compiler version?) Maybe it's related to https://savannah.nongnu.org/bugs/?func=detailitemitem_id=13106 http://lists.gnu.org/archive/html/avr-libc-dev/2005-05/msg00020.html ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
FW: [avr-gcc-list] Problems with ATMEGA8 USART
This is the original message. Dave's header file only version is
essentially the same as my procedural code. The header file version would,
naturally, be all inline code and likely tighter for small systems with
minimal calls to the fifo routines (or fifo routines buried inside single
point of access higher level routines like getc() putc()...)
I thought I was responding to a message to the avr-chat list. Obviously
this kind of message isn't appropriate for the Gcc compiler list. I
apologize in advance :)
-Original Message-
From: Larry Barello [mailto:[EMAIL PROTECTED]
Sent: Tuesday, August 16, 2005 11:53 AM
To: 'Dave Hylands'
Subject: RE: [avr-gcc-list] Problems with ATMEGA8 USART
So, who has the tiniest fifo routine in C? I don't mean lack of text, but
size of compiled code. The best I have done is using powers of two with
masks on the indexes (32 byte buffer being a convenient size).
-
#define BUFSIZE 32
#define BUFMSK 0x1F
#define Nextfifo(A) ((unsigned char)(((A) + 1) BUFMSK))
#define isEmpty(A) ((A)-in == (A)-out)
#define isFull(A) (Nextfifo((A)-in) == (A)-out)
typedef struct
{
volatile unsigned char in;
volatile unsigned char out;
volatile unsigned char buf[BUFSIZE];
}
Fifo, *pFifo;
int PutFifo(pFifo p, char c)
{
unsigned char t = Nextfifo(p-in);
if (t == p-out)
return -1;
else
{
p-buf[p-in] = c;
p-in = t;
return 0;
}
}
int PullFifo(pFifo p)
{
if (isEmpty(p))
return -1;
else
{
int c = p-buf[p-out];
p-out = Nextfifo(p-out);
return c;
}
}
void DelLastFifo(pFifo p)
{
if (!isEmpty(p))
{
p-in = (p-in - 1) BUFMSK;
}
}
void FlushFifo(pFifo p)
{
p-in = p-out = 0;
}
-Original Message-
From: Dave Hylands
Be warned that the head/tail usage can be something of a religious
war with people. There are those who champion the opposite roles
of head/tail, and remember it with when you join a queue, should you
join at the head or the tail ? - so if you inherit code, it is
always worth double checking which rule the author is following.
I get around this problem with cicular buffers by having get and put
ptrs or indicies. It makes it much more obvious what they do.
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
[avr-gcc-list] Union as parameter
I tried using this typedef, below, as a parameter to a function. When I do,
it gets stuck onto the stack frame. The resulting code is a riot since
there is all sorts of set up and teardown, the value gets stuck onto the
stack, the routine called, the variable pulled off the stack into registers
where it is acted upon.
Taking out the bitfield reverts to more normal GCC behavior: the union is
passed in a dword register set. An aside from some shuffling of registers is
pretty decent code.
Gcc 3.4.3 (latest WinAvr).
Is this a known issue?
Typedef union
{
Uint32_t dword;
Uint16_t word[2];
Uint8_t byte[4];
Struct
{
Uint16_t offset:7;
Uint16_t page:10;
Uint16_t bank:2;
} bits;
}
Addr_u;
Larry Barello
www.barello.net
___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
RE: [avr-gcc-list] Union as parameter
Passing by reference would work and produce decent code (GCC is amazing with dereferenced data), but passing the bitfield in registers should result in even tighter code. Since this is lowest level EEPROM driver code I would like it to be pretty tight. I removed the struct and the resulting code was pretty good, if somewhat more obscure (doing my own mask shift operations). I'll take Dean's suggestion and declare the bit-field as uint32_t and see what happens; that would be the cleanest way to do this. In any case, GCC putting the union on the stack just because the bitfield was not an exact unit long seems like broken behavior. The first bit over 16 should have allocated the additional word to make it a dword variable. Well, at least it produced correct, if somewhat sloppy, code. Cheers! -Original Message- From: Dean Hall [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 24, 2005 6:29 AM To: avr-gcc-list@nongnu.org; [EMAIL PROTECTED] Subject: Re: [avr-gcc-list] Union as parameter Larry, Sounds like you're passing the union by value. If you are, can you instead pass it by reference (which would occupy 2 bytes on the stack)? If you're worried about modifying the data in the function, you can shield it with a const declaration. More details here: http://www.embedded.com/shared/printableArticle.jhtml?articleID=9900322 I compiled to assembly a dummy program that used your union. I didn't see anything out of the ordinary (but I'm not an expert in gcc prologue code, so take that statement with a modicum of sodium chloride). One thing you might consider is to make the types in the bits struct all uint32_t. This way you explicitly tell the compiler to pack them all into a 4 byte container. I did this in my dummy program and didn't see a difference, but I didn't see a much of a riot in the first place. Maybe my dummy program didn't exercise a certain case of bit manipulation that your program does. !!Dean On Aug 24, 2005, at 07:15, [EMAIL PROTECTED] wrote: -- Message: 8 Date: Wed, 24 Aug 2005 00:19:08 -0700 From: Larry Barello [EMAIL PROTECTED] Subject: [avr-gcc-list] Union as parameter To: AVR GCC List avr-gcc-list@nongnu.org Message-ID: [EMAIL PROTECTED] Content-Type: text/plain;charset=us-ascii I tried using this typedef, below, as a parameter to a function. When I do, it gets stuck onto the stack frame. The resulting code is a riot since there is all sorts of set up and teardown, the value gets stuck onto the stack, the routine called, the variable pulled off the stack into registers where it is acted upon. ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
RE: [avr-gcc-list] Union as parameter
Well, dang. Making it a uint32_t bitfield didn't work. Adding a dummy 13 bit field to force alignment to a dword worked and the union was passed in registers. That made a 280 byte difference is a tiny SPI EEPROM driver... ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
RE: [avr-gcc-list] Union as parameter
Sorry for the blizzard of email... Using bitfields was almost as optimal as manual shift mask: Resulting .text for my application: Using frames: 14282 (odd size bitfield forces parameter onto stack..) Using Shift/mask: 14002 Using bitfield: 14008 I'll use bitfields as it is easier to layout new eeprom sizes and the code is easier to follow. THANKS! ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
[avr-gcc-list] C Preprocessor question
Can I define a macro that defines some stuff? I cannot get the following to
work
#define mymacro(foo, somenumber) \
#define foo (*(pFifo)foo##bar) \
Static uint8_t foo##bar[somenumber + sizeof(Fifo)]
The goal (maybe there is a better way...) is to have a variable length
buffer with some defined structure in the front. A pointer to the struct is
passed around various routines.
I could use a union:
#define mymacro(foo, somenumber) \
Union {uint8_t buf[somenumber + sizeof(Fifo)]; Fifo fifo;} foo
And the user would have to use foo.fifo as the reference, but I would
prefer to just type in foo when calling routines.
Larry Barello
www.barello.net
___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
[avr-gcc-list] stdio - how extensible?
I am wrapping up a serial io sample for my rtos (www.barello.net/AvrX) and as a final test I spun up two tasks, one attached to USART0 and one to USART1 (mega128). Well, duh, it didn't work since the second call to fdevopen() (task 2) failed miserably. I knew that, I am just sometimes thick in the morning ;^) So, the question is: what would it take to extend the current stdio facility to allow N descriptors (rather than just stdout, stdin and stderr). Obviously, for my sample I need four channels. But, I bet others are hanging extra serial ports off the chip (mega8's or SPI USARTs) and could use channels beyond four. Or is this already implemented and I just need to RTFM? A second question: is stdio written to be re-entrant? I.e. No static data (other than the file descriptor)? The first question is sort of moot if stdio is not re-entrant (for me at least). Larry Barello www.barello.net ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
[avr-gcc-list] FW: Atmel New AVR Studio 4.12
FYI I have been using the beta and this is *much* better than previous releases. The docking system is super: all docked windows can auto-shrink to the side (top/bottom) with tabs - click on a tab and the window you want slides open: source, registers, i/o, etc. Really, really slick. -Original Message- From: Eric Feign [mailto:[EMAIL PROTECTED] AVR Studio 4.12 http://www.atmel.com/dyn/general/tech_doc.asp?doc_id=10385 Release Notes http://www.atmel.com/dyn/general/tech_doc.asp?doc_id=10003 45.2MB Download Please remove AVR Studio 4.11 first, then install 4.12. When installing, please make sure to check the Install/Upgrade USB Driver. This release adds new device support and numerous overall enhancements; new breakpoint system, integrated AVR GCC development and improved docking system! See release notes for more details. ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
[avr-gcc-list] Latest release
I just upgraded from last Feb to this Jan release of WinAvr. I have not been following the chatter and in fact I have been offline for the last two or three months (w/regard to avr gcc list). So I appologise in advance for asking some dumb questions. What happened to INTERRUPT? Why was that and SIGNAL depreciated? Is it safe to continue to use the interrupt attribute? --- Larry Barello www.barello.net ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
RE: [avr-gcc-list] Horrible code
3.4.5 winavr produces nice tidy code. Even the compares with 0 reduce to
tight sbic/jmp pairs.
---
Larry Barello
www.barello.net
| -Original Message-
| From: [EMAIL PROTECTED] [mailto:avr-gcc-
| [EMAIL PROTECTED] On Behalf Of James L. Evans
| Sent: Tuesday, May 16, 2006 3:47 PM
| To: avr-gcc-list@nongnu.org
| Subject: [avr-gcc-list] Horrible code
|
| Could someone with a 4.1 version of the AVR-GCC compiler please compile
| the following code (-Os) and see if it generates better code than the
| horrible code (25 instructions) generated for Case 2 by version 3.4.3?
|
| Thanks,
|
| Jim Evans
|
|
| #include inttypes.h
| #include avr/io.h
|
| void test7(void) {
| while (PINA 0x40) PORTA = 0; // Case 1
|
| while ((PINA 0x40) == 0) PORTA = 0; // Case 2
|
| while (!(PINA 0x40)) PORTA = 0; // Case 3
|
| uint8_t b;
| while ((b = (PINA 0x40)) == 0) PORTA = 0; // Case 4
| }
|
|
| ___
| AVR-GCC-list mailing list
| AVR-GCC-list@nongnu.org
| http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
RE: [avr-gcc-list] PRG_RDB where is it?
Try pgm_read_byte() defined in #include avr/pgmspace.h --- Larry Barello www.barello.net | -Original Message- | From: [EMAIL PROTECTED] [mailto:avr-gcc- | [EMAIL PROTECTED] On Behalf Of Paulo da Silva | Sent: Tuesday, July 11, 2006 8:53 PM | To: avr-gcc-list@nongnu.org | Subject: [avr-gcc-list] PRG_RDB where is it? | | Hi all | | I am trying to compile a code and avr-gcc return that PRG_RDB is | undefined. | I searched it and found nothing. | Please where can I find it? | I am using avr-gcc version 3.4.6. | | regards | | Paulo | | | ___ | AVR-GCC-list mailing list | AVR-GCC-list@nongnu.org | http://lists.nongnu.org/mailman/listinfo/avr-gcc-list ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
[avr-gcc-list] stdio newline character
I never noticed this before, but it appears that the stdio facility in the latest WinAvr appends a newline character whenever I send a return. I am working on a project where I am not using printf() etc. but just simple puts_P() and puts(). Unfortunately the insertion of the 0x0A is a problem. I looked through the libc faq which mentions the automatic appending of the 0x0A, but never mentions how to disable that. I must have missed some paragraph or something... I would appreciate someone pointing me to the magic incantation to disable cooking the output. I even tried writing my own puts_P() using putchar(), and THAT appended the bloody 0x0A... --- Larry Barello www.barello.net ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
RE: [avr-gcc-list] OT: anyone successfully use the CLKPR feature in themega88?
Ok, if you insist. It just is so off topic...
Anyway, I have a little app, and when I want to snooze, rather than shutting
down using the watchdog to wake up, I thought I would use that handy
looking CLKPR register to slow the main clock waaay down. Then, when
interrupted (via the Timer0 main heartbeat, but now 1/128 slower...) I would
bump the clock back up to do my processing, etc.
The overt symptoms are that the clock doesn't bump up reliably. I suspect
that it doesn't bump down reliably either, but at 11mhz 50hz timer tick I
wouldn't notice the code taking several tries. @ 100khz and .5 hz I notice
when it misses as a complete control cycle occurs at a glacial pace...
I tried many variations and finally settled on the code, below, which still
isn't reliable. I toggle between 0x00 and 0x06 divisors.
void SetClock(uint8_t divisor)
{
cli();
asm(nop);
asm(nop);
asm(nop);
asm(nop);
asm(nop);
asm(nop);
asm(nop);
asm(nop);
CLKPR = 0x80;
CLKPR = divisor;// Divide system
clock by 128.
asm(nop);
asm(nop);
asm(nop);
asm(nop);
asm(nop);
asm(nop);
asm(nop);
asm(nop);
}
The code, above, of course, resolves into two back-to-back STS instructions,
which, with interrupts off should do the trick.
| -Original Message-
| From: Eric Weddington [mailto:[EMAIL PROTECTED]
| Sent: Tuesday, October 03, 2006 8:12 AM
| To: 'larry barello'; 'AVR GCC List'
| Subject: RE: [avr-gcc-list] OT: anyone successfully use the CLKPR feature
| in themega88?
|
|
|
| -Original Message-
| From:
| [EMAIL PROTECTED]
| [mailto:[EMAIL PROTECTED]
| org] On Behalf Of larry barello
| Sent: Tuesday, October 03, 2006 8:35 AM
| To: AVR GCC List
| Subject: [avr-gcc-list] OT: anyone successfully use the CLKPR
| feature in themega88?
|
| I am having difficulty with reliable transition between clock
| speeds. I
| have been using various AVR chips for years so I doubt I am
| doing something
| stupid, but, one never knows.
|
| Hi Larry,
|
| Long time, no see. ;-)
|
| What do you mean by difficulty with reliable transition between clock
| speeds? What are you seeing?
|
| Please, reply direct rather than on the list.
|
| And deprive others from the answer? ;-) I'll reply to both direct *and*
| the
| list if that helps...
|
| Eric Weddington
___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
RE: [avr-gcc-list] OT: anyone successfully use the CLKPR feature in themega88?
While generating a minimal test case I discovered that the feature works exactly as advertised, no funky NOP's needed. So, my problem was (naturally) my own clumsiness. I don't know why (yet) but I am guessing that by resetting the CLKPR in my interrupt handler I ran a-foul of a classic failure: my state variable tracking the CPU speed was not declared volatile and would get out of phase every so often (one hint was the regularity that the speed change failed, about once every four control cycles...) The speed change works reliably after I pulled the reset out of the handler and put everything into the main loop. Cheers! | -Original Message- | From: Joerg Wunsch [mailto:[EMAIL PROTECTED] | Sent: Tuesday, October 03, 2006 9:42 PM | To: avr-gcc-list@nongnu.org | Cc: [EMAIL PROTECTED] | Subject: Re: [avr-gcc-list] OT: anyone successfully use the CLKPR feature | in themega88? | | larry barello [EMAIL PROTECTED] wrote: | | The overt symptoms are that the clock doesn't bump up reliably. I | suspect that it doesn't bump down reliably either, but at 11mhz | 50hz timer tick I wouldn't notice the code taking several tries. | | You could always program the CKOUT fuse (provided your stuff connected | to PORT B0 would tolerate that), and monitor the clock frequency | change. | | -- | cheers, Jorg .-.-. --... ...-- -.. . DL8DTL | | http://www.sax.de/~joerg/NIC: JW11-RIPE | Never trust an operating system you don't have sources for. ;-) ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
[avr-gcc-list] C coding question
when mixing bit-wise and logical operations, is it safe to assume that (!0 == 1) is true? Specifically I was looking for an efficient way to encode (bSomeBool ^ (SomeBitMask SomeVariable)) to get a true/false output. Of course, expressed, as above, doesn't work too well when bit-wise exclusive or-ing the bool with the bitmask. So I said: (bSomeBool?1:0) ^ ((SomeBitMask SomeVariable)?1:0)) which worked fine, but isn't particularly efficient in assembly. Not that I really care, but since I had to look at it to realize my mistake, I became interested in a better way to express the thought. For example, is the following guaranteed to work? (bSomeBool ^ ((SomeBitMask SomeVariable)?1:0)) Where bSomeBool is either 0 or !0? Cheers! ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
RE: [avr-gcc-list] AVR byte swap optimization
Although a bit wordy, the following produces good code under a lot of
different circumstances. It allows the compiler to shove things around
optimize.
static inline uint16_t ByteSwap(uint16_t data)
{
union byteswap
{
uint16_t word;
struct
{
uint8_t low;
uint8_t high;
};
} foo;
foo.word = data;
uint8_t t = foo.high;
foo.high = foo.low;
foo.low = t;
return foo.word;
}
| -Original Message-
| From: [EMAIL PROTECTED] [mailto:avr-gcc-
| [EMAIL PROTECTED] On Behalf Of Shaun Jackman
| Sent: Friday, November 17, 2006 3:31 PM
| To: avr-gcc-list@nongnu.org; gcc@gcc.gnu.org
| Subject: [avr-gcc-list] AVR byte swap optimization
|
| The following macro expands to some rather frightful code on the AVR:
|
| #define BSWAP_16(x) \
| x) 8) 0xff) | (((x) 0xff) 8))
|
| uint16_t bswap_16(uint16_t x)
| {
|0: 9c 01 movwr18, r24
|2: 89 2f mov r24, r25
|4: 99 27 eor r25, r25
|6: 32 2f mov r19, r18
|8: 22 27 eor r18, r18
| return BSWAP_16(x);
| }
|a: 82 2b or r24, r18
|c: 93 2b or r25, r19
|e: 08 95 ret
|
| Ideally, this macro would expand to three mov instructions and a ret.
| Is there anything I can do to help GCC along here? I'm using GCC 4.1.0
| with -O2.
|
| I won't bother to show bswap_32 here, which produces a real disaster!
| Think 47 instructions, for what should be 6.
|
| Cheers,
| Shaun
|
| $ avr-gcc --version |head -1
| avr-gcc (GCC) 4.1.0
|
|
| ___
| AVR-GCC-list mailing list
| AVR-GCC-list@nongnu.org
| http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
RE: [avr-gcc-list] AT90CAN128 bootloader
I took Jason Kyle's boot-loader and reworked it to fit in 512 words. A version that should be relatively easy to modify for your needs can be found in the files section of Yahoogroups avrrobotcontrol You will need to sign up for Yahoogroups to see it download. it is a stand-alone program using GCC. You load it into the target chip and then use the old fashion STK500 protocol to communicate. With a 16mhz crystal you won't be able to use STK500.exe as that is fixed for 115.2kbaud and you can't get that baud rate with a 16mhz crystal; use AvrDude, which works fine. The specific loader is for a mega16, but many of the classic chips can be specified (look at the source) and new ones easily added. For the mega128 the code is fixed for USART1, but again, easy to change. Cheers! http://tech.groups.yahoo.com/group/AVRRobotControl/files/ARC%20Bootloader/AR C%20Bootloader%2012mhz.zip _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Trampas Sent: Saturday, November 25, 2006 6:59 AM To: avr-gcc-list@nongnu.org Subject: [avr-gcc-list] AT90CAN128 bootloader I know this has been asked somewhere before, but is there a bootloader that is easy to implement for the AT90CAN128? I would like to have the ability to upgrade firmware on my device through serial port, I found this link and it looked ideal except I am using UART0 and 16Mhz which is not support. http://hubbard.engr.scu.edu/embedded/avr/bootloader/index.html Maybe someone has a how to on including the bootloader in my sources? Thanks Trampas ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
RE: [avr-gcc-list] AT90CAN128 bootloader
Thanks! IIRC you can cut out the EEPROM support and the boot loader fits into 256 words. While paring down the size I cut out the C startup (there is no main()) runtime support and moved statics/globals into automatics assuming they would go onto the stack. However that clever compiler kept everything in registers and the resulting code generation was spectacular. One thing not mentioned in the README is if your application scans for 0x30, 0x20 (no echo) and then jumps to the bootloader + one instruction, you can have entry into the loader automatic. I do that with all my projects (that have user interfaces) with a tiny state machine that eats the two characters (printing them if it fails). That way I don't have to reset or otherwise fool around: Just run AvrDude and tada! new code in 10 seconds or less. 0 is an unusual sequence so I never trip across it otherwise. Cheers! Nice work! Compiled with avr-gcc 3.4.6 it uses just 418 instructions out of 512 and it works with avrdude! Yahoo groups is a bit of a pain that others may not have the patience for! (Why do they need to know my sex, birthday and my mother's maiden name?). I've posted a ZIP file here too... http://www.lightner.net/avr/bootstap/ARCbootloader.zip Best regards, Bruce -- Bruce D. Lightner Lightner Engineering La Jolla, California Voice: +1-858-551-4011 FAX: +1-858-551-0777 Email: [EMAIL PROTECTED] URL: http://www.lightner.net/lightner/bruce/ ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
RE: [avr-gcc-list] AT90CAN128 bootloader
I wrote a little state machine that eats the '0' and ' ', printing out the '0' if not followed by a space. Then it jumps to the bootloader. The bootloader also waits 3 seconds prior to running the application which is how I recover if I mess up and the escape sequence doesn't work. Finally, you can specify an input pin to force the bootloader to take control. Just look at the source. The linker magic is all in the makefile. Cheers! _ From: Trampas [mailto:[EMAIL PROTECTED] Sent: Saturday, November 25, 2006 10:11 AM To: 'Larry Barello'; 'Bruce D. Lightner' Cc: 'AVR GCC List' Subject: RE: [avr-gcc-list] AT90CAN128 bootloader Larry, I have some stupid questions. Does the AVRDUDE and/or AVR Studio send out 0 to start programming? Is there some specification somewhere? What happens if user does hit 0 by accident? I would very much like to do two things, one is have the automatic bootloader like you do, and the second is to integrate the bootloader into my code, thus I assume there are some special linker stuff I need to do? Thanks again for the help. Thanks Trampas _ From: Larry Barello [mailto:[EMAIL PROTECTED] Sent: Saturday, November 25, 2006 12:59 PM To: 'Bruce D. Lightner' Cc: 'Trampas'; 'AVR GCC List' Subject: RE: [avr-gcc-list] AT90CAN128 bootloader Thanks! IIRC you can cut out the EEPROM support and the boot loader fits into 256 words. While paring down the size I cut out the C startup (there is no main()) runtime support and moved statics/globals into automatics assuming they would go onto the stack. However that clever compiler kept everything in registers and the resulting code generation was spectacular. One thing not mentioned in the README is if your application scans for 0x30, 0x20 (no echo) and then jumps to the bootloader + one instruction, you can have entry into the loader automatic. I do that with all my projects (that have user interfaces) with a tiny state machine that eats the two characters (printing them if it fails). That way I don't have to reset or otherwise fool around: Just run AvrDude and tada! new code in 10 seconds or less. 0 is an unusual sequence so I never trip across it otherwise. Cheers! Nice work! Compiled with avr-gcc 3.4.6 it uses just 418 instructions out of 512 and it works with avrdude! Yahoo groups is a bit of a pain that others may not have the patience for! (Why do they need to know my sex, birthday and my mother's maiden name?). I've posted a ZIP file here too... http://www.lightner.net/avr/bootstap/ARCbootloader.zip Best regards, Bruce -- Bruce D. Lightner Lightner Engineering La Jolla, California Voice: +1-858-551-4011 FAX: +1-858-551-0777 Email: [EMAIL PROTECTED] URL: http://www.lightner.net/lightner/bruce/ ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
RE: [avr-gcc-list] volatile...
gcc-armxxx places volatile data outside the cache... so it must be a compiler dependent feature. Always best to examine the resulting assembly to make sure your assumptions are correct :) | -Original Message- | From: [EMAIL PROTECTED] [mailto:avr-gcc- | [EMAIL PROTECTED] On Behalf Of Graham Davies |... | On the subject of volatile isn't enough and straying further from AVR, | remember that if your machine has a data cache you need to figure out how | to | not have the cache between you and a hardware register. This varies by | CPU | and there is nothing in the language to help you with this. | ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
RE: [avr-gcc-list] Options on avr-gcc
Declaring N as volatile is a good solution. The alternative is to disenable optimization on GCC (-o0) but I don't think you will like the results. Another solution is to put asm(nop); In your loop body. That will force the compiler to implement the loop. There might be some fancier compiler option just for loop optimization, but I don't know about them. -Original Message- From: Javier Almansa Sobrino Hi everybody. Let's see if you can help me I've been compiling a proyect based on a AT90USB1287 and I've something like this: uint16_t n; for (n = 0; n 1000; n++); /* Delay loop */ --- rest of code -- originally, this piece of code generates a delay loop, but I've changed the AVR-GCC options on my Makefile and now, if I want the delay loop works correctly, I must declare n as volatile. Any one knows what option I must to pass to AVR-GCC when compile to avoid this. I don't remember and I've lost the original Makefile. Thanks in advance. ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
[avr-gcc-list] Embedding CRC into hex file
Does anyone have the AVR equivalent routine for one of the CRC16 generated with srecord they would share? I would like to modify my boot loader to check the application code before running so corrupted downloads don't wedge my application. I know there are plenty of examples on the web (I have done this before for the H8), I just thought if someone has GCC code ready to cut paste that is known to work with srec, that would shave a bit of time off my project. Thanks. ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
[avr-gcc-list] Debugging bootloaders on m128
In the past it was difficult to debug stuff in the upper 64k of FLASH using Atmel Studio. I thought with the latest studio that was fixed. Does that require the latest WinAvr as well? I have the previous version, being scared off of upgrading due to various problems reported in this list. Anyway, I am once again, developing a new bootloader and finding debugging disassembly to be a challenge. ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
[avr-gcc-list] srec_cat help request
I am updating my boot-loader to perform a CRC check across the application - it will stay in the BL if the CRC is bad. I am trying to use srec_cat to generate the CRC value. I am having no success getting the CRC value to match what the bootloader calculates. Since srec_cat operation is opaque to me, I am asking for some help. How do I get srec_cat to calculate a CRC value from 0 to (lets say) 0x1F7FD and plop that value down in 0x1F7FE? I.e. deposit the CRC into the last two bytes prior to my bootloader (2k byte, m128). This is the command line I am using w/o luck (well, *something* is getting deposited.) srec_cat $(TARGET).hex -Intel -fill 0xFF 0 0x1F7FE -Little_Endian_CRC16 0x1F7FE -Cyclic_Redundancy_Check_16_XMODEM -Output $(TARGET).hex -Intel Does the above process the CRC over the entire address range? Or just the extents of the input file? Srec_cat isn't clear on that. Has anyone used these tools to do this? The only example I have uses the application to check itself - it knows it's extents because the linker provides that. Unfortunately the boot-loader doesn't have access to that information. Alternatively if I could get srec_cat to put both the maximum extent and the CRC near the end of FLASH, I could adjust my boot-loader to read those values in generating the CRC. Thanks in advance. ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
RE: [avr-gcc-list] srec_cat help request
Thanks. My sample code included snippets like Uwe's. Because the
bootloader doesn't know where the end of the code is, I needed to do this
a bit differently. I finally got what I wanted by doing the following:
srec_cat $(TARGET).hex -Intel -little_endian_max 0 -multiple -output max.hex
-intel
srec_cat $(TARGET).hex -intel -little_endian_crc16 0x1F7FE
-Cyclic_Redundancy_Check_16_XMODEM -output crc.hex -intel
srec_cat crc.hex -intel max.hex -intel -crop 0 4 -offset 0x1F7FA -Output
combined.hex -Intel
It is way too much work just to stuff the high water mark at the end of
FLASH w/o modifying the high water mark, but that seems to be a fundamental
limitation of srec_cat. The locations are fixed, but need to be
parameterized so I can specify where the loader lives (various chips) and
have the makefile do the math (BOOT_START-2 or -6). Any hints how to do
that? Also the first srec_cat spits out four warnings because I am laying
the max over the beginning of the input file. How do I just put the
length out as its own record w/o any of the original file???
I ended up running through all permutations of CRC, initial value for both
srec_cat and the crc16.h header file and found that only XMODEM worked.
Uwe's example, implies one of the other combinations works as well but I was
unable to figure it out. Perhaps srec_cat is broken, or perhaps the AVR
algorithms are broken. I dunno. I have something that works, now, so I am
moving on.
The AVR end looks like this:
bool CheckCrc(void)
{
uint32_t crc_end = pgm_read_dword_far(BOOT_START-6);
if (crc_end == -1)
return false;
uint16_t crc = 0;
uint32_t adx;
for(adx = 0; adx crc_end; adx++) // include all empty space?
// crc = _crc16_update (crc, pgm_read_byte_far(adx));
crc = _crc_xmodem_update (crc, pgm_read_byte_far(adx));
return (crc == pgm_read_word_far(BOOT_START-2));
}
_
From: Schwichtenberg, Knut [mailto:[EMAIL PROTECTED]
Sent: Thursday, April 05, 2007 12:32 AM
To: larry barello; avr-gcc-list@nongnu.org
Subject: RE: [avr-gcc-list] srec_cat help request
Larry,
I have not tried, but at 31.03.06 Uwe Fechner came around here with the same
problem. He solved the problem and on his last email he showed his makefile
which puts the CRC behind the last used byte of code.
# Create final output files (.hex, .eep) from ELF output file.
%.hex: %.elf
@echo
@echo $(MSG_FLASH) $@
$(OBJCOPY) -O $(FORMAT) -R .eeprom $ $@
mv $@ $(TARGET).org.hex
srec_cat $(TARGET).org.hex -Little_Endian_CRC16 -max $(TARGET).org.hex
-Output $(TARGET).hex
I'm pretty sure he also showed the algorithm of the used AVR-CRC, but could
not find it on his web.
Maybe that helps.
Cheers
Knut
_
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On
Behalf Of larry barello
Sent: Thursday, April 05, 2007 12:12 AM
To: avr-gcc-list@nongnu.org
Subject: [avr-gcc-list] srec_cat help request
I am updating my boot-loader to perform a CRC check across the application -
it will stay in the BL if the CRC is bad.
I am trying to use srec_cat to generate the CRC value. I am having no
success getting the CRC value to match what the bootloader calculates.
Since srec_cat operation is opaque to me, I am asking for some help.
How do I get srec_cat to calculate a CRC value from 0 to (lets say) 0x1F7FD
and plop that value down in 0x1F7FE? I.e. deposit the CRC into the last two
bytes prior to my bootloader (2k byte, m128).
This is the command line I am using w/o luck (well, *something* is getting
deposited.)
srec_cat $(TARGET).hex -Intel -fill 0xFF 0 0x1F7FE -Little_Endian_CRC16
0x1F7FE -Cyclic_Redundancy_Check_16_XMODEM -Output $(TARGET).hex -Intel
Does the above process the CRC over the entire address range? Or just the
extents of the input file? Srec_cat isn't clear on that.
Has anyone used these tools to do this? The only example I have uses the
application to check itself - it knows it's extents because the linker
provides that. Unfortunately the boot-loader doesn't have access to that
information.
Alternatively if I could get srec_cat to put both the maximum extent and the
CRC near the end of FLASH, I could adjust my boot-loader to read those
values in generating the CRC.
Thanks in advance.
___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
[avr-gcc-list] New GCC warning - how to silence?
This is a new warning with the latest WinAvr. What does it mean and how do I silence it? It is highly annoying that the buffers are even concerned whether a byte value is signed or not when dealing with characters. TetherTask.c:191: warning: pointer targets in passing argument 1 of 'sscanf_P' differ in signedness ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
RE: [avr-gcc-list] New GCC warning - how to silence?
Ok, this is the most interesting answer and begs another question: Are you just saying use either signed or unsigned (I typically use uint8_t except when the signedness counts) or is char a distinct type that has defined behavior across portable systems? I don't like the -funsigned-char because that is magic. I rather just explicitly say what I want. Anyway, I solved the warnings by casting (or changing the type) of buffers and pointers from uint8_t to char as int8_t seemed to cause grief as well. Cheers! -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Joerg Wunsch Sent: Thursday, April 05, 2007 3:02 PM To: avr-gcc-list@nongnu.org Subject: Re: [avr-gcc-list] New GCC warning - how to silence? Eric Weddington [EMAIL PROTECTED] wrote: GCC 4 seems to be a lot more concerned about the differences between char and unsigned char. Are you using the -funsigned-char flag in your compiler command? Regardless of which is the default, just never mix up char with either unsigned char (or uint8_t) or signed char (int8_t) at all. A portable application needs to handle all three types as distinct, as the default signedness of the type char is not determined by the standard. -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
[avr-gcc-list] Odd difference between last two WinAvrs
I have the following: #define BOOTSTART 0x1F800 #define BL_SERIAL 2 #define BL_SMB 4 So I can say ((void (*)(void))((BOOT_START+BL_SERIAL)/2))(); When I want to jump into my bootloader at the serial download entry point. In last years WinAvr that code breaks. It generates: call -1023 In this years compiler it works. It generates ldi r30,lo8(-1023) ldi r31,hi8(-1023) icall Is there a bug I am missing? A compiler problem? Am I being clueless on how I specify a hard address to call? ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
[avr-gcc-list] WinAvr and Vista
Ok, I give up. What environment variables do I need to specify so WinAvr can operate successfully under Vista? I just took the default installation under c:\WinAVR I added c:\WinAVR\libexec\gcc\avr\4.1.1 to the path and now the compiler at least runs. But it can't find the include files.. ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
RE: [avr-gcc-list] WinAvr and Vista
Thanks for the tip on google... Doh! http://www.madwizard.org/extern/winavr-vista/ It works, but really crawls. I may yet switch back to XP... -Original Message- From: Eric Weddington [mailto:[EMAIL PROTECTED] You're a bit late to the game. There are at least two major threads about WinAVR on Vista on the AVR Freaks website, as well as numerous hits on Google about GCC on Vista. Right now, there is not a slam-dunk solution. I'm currently working on the issue... I would suggest that, for now, you use a more stable OS release. ;-) Eric Weddington ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
RE: [avr-gcc-list] Fine Tuning code timings
I just adjusted the initial bit time by a few counts to offset the delay. Subsequent bits were sampled/output through the same code path so I just continued to add the bit time to the OCxx register for the next interrupt. In my code I used TIMER3 as CPU/8. I had to adjust my initial delays by 10 counts (~80 cycles) to eliminate the ~75 clocks of ISR entry code (determined by inspection of generated assembly). All subsequent adjustments to the OC3X register were just the bit time for the next compare. I for Rx I used IC3 to capture the start time and adjusted that -10 cycled so the first OC3X interrupt would sample at the right time. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Alex Shepherd Sent: Saturday, December 22, 2007 11:17 PM To: avr-gcc-list@nongnu.org Subject: [avr-gcc-list] Fine Tuning code timings Hi Guys, I'm trying to fine tune some C code timing issues for a software UART written in AVRGCC. Essentially when I go to transmit a byte, I capture the value of Timer1, set the output compare value to the current timer value + the bit period, activate the Tx pin and then wait for the interrupt handler to output the rest of the bits in the byte. The problem I'm having is that the latency between the timer interrupt firing and the code in the interrupt handler that drives the pin state is causing some error. I need some way to calculate the amount of time to reduce the initial timer period by so that the pin state driving logic in the interrupt handler executes at the right time. What I would like to try and find out (and why I'm asking on this list): Is there any way to figure out using compiler tricks/magic how far into a function or interrupt handler a line of code is so that I can use this offset value to tune the initial start-bit timer value. The subsequent bit timings are ok as they are generated using the same code path? I have experimented using LABELS in the code and trying to do pointer arithmetic but they don't seem to be accessible outside the function or I was just doing it wrong. Merry Christmas Alex Shepherd ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
RE: [avr-gcc-list] cbr and negative numbers
AvrX has been around since the late 90's www.barello.net/Avrx www.yahoogroups.com/group/avrx I originally wrote it for the at90S2313 with 128 bytes of stack. Later I modified it for larger chips (16 bit stack). It is almost entirely in assembly. There is no active development or maintenance at this time (I have moved on...) It runs as is on all AVR chips with minor changes to IO port names. It does need some work to function on the newer larger chips with three byte call as it doesn't know about the extra byte. . Cheers! -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Gre7g Luterman Sent: Friday, September 12, 2008 8:19 AM To: avr-gcc-list@nongnu.org Subject: Re: [avr-gcc-list] cbr and negative numbers - Original Message From: Ruud Vlaming [EMAIL PROTECTED] To: avr-gcc-list@nongnu.org Sent: Friday, September 12, 2008 8:23:23 AM Subject: Re: [avr-gcc-list] cbr and negative numbers So have a look at my OS for the AVR, sources included (GPLv3) http://www.femtoos.org/ ;-) There's an OS for the AVR? Whoa. I had no idea. Guess I know what website I'll be perusing this morning. Is it stable yet? Gre7g ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
[avr-gcc-list] xmega support
I am trying to bring a project developed on a mega128 up on an xmega128A1. Aside from the very different I/O structure (which is actually pretty nice) the non-volatile memory stuff is totally different. Is there some libc support for reading/writing the EEPROM? How about self-programming support (aka boot-loader)? Or do I have to roll my own? Hmm, a search through the 1205 release for __AVR_ATxmega128a1__ shows only the following files having knowledge of the chip: Power.h Sleep.h Wdt.h And Io.h of course. I suppose the real question is: what level of support does Libc have for these new chips? Cheers! ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
RE: [avr-gcc-list] xmega support
Thanks for the response. I dug a bit further into the manual and I see that EEPROM can be mapped to SRAM space eliminating the need for library EEPROM support in GCC. Ironically, since writing AvrX I have not really used it for anything. I have no plans to upgrade AvrX for the bigger chips. A lot of other people use it and I suppose someone will eventually add things like RampZ, etc. to the task state and a third word to the call return stack. Cheers! -Original Message- From: Weddington, Eric [mailto:ewedding...@cso.atmel.com] Sent: Tuesday, January 06, 2009 5:40 PM To: larry barello; AVR GCC List Subject: RE: [avr-gcc-list] xmega support -Original Message- From: avr-gcc-list-bounces+eweddington=cso.atmel@nongnu.org [mailto:avr-gcc-list-bounces+eweddington=cso.atmel@nongnu. org] On Behalf Of larry barello Sent: Tuesday, January 06, 2009 5:33 PM To: AVR GCC List Subject: [avr-gcc-list] xmega support I am trying to bring a project developed on a mega128 up on an xmega128A1. Aside from the very different I/O structure (which is actually pretty nice) the non-volatile memory stuff is totally different. Is there some libc support for reading/writing the EEPROM? How about self-programming support (aka boot-loader)? Or do I have to roll my own? Hmm, a search through the 1205 release for __AVR_ATxmega128a1__ shows only the following files having knowledge of the chip: Power.h Sleep.h Wdt.h And Io.h of course. I suppose the real question is: what level of support does Libc have for these new chips? Unfortunately that is it at the moment. Yes, we would certainly like to add more support for the xmega series in avr-libc. User feedback is particularly welcomed, whether it is patches, or suggestions for APIs. Tell us what you would like to see! Are you thinking about porting AVRX to the xmega? Eric ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
RE: [avr-gcc-list] xmega support
Read the data sheet. http://www.atmel.com/dyn/resources/prod_documents/doc8077.pdf -Original Message- From: avr-gcc-list-bounces+larry=barello@nongnu.org [mailto:avr-gcc-list-bounces+larry=barello@nongnu.org] On Behalf Of Colin D Bennett Sent: Wednesday, January 14, 2009 9:48 AM To: avr-gcc-list@nongnu.org Subject: Re: [avr-gcc-list] xmega support On Tue, 6 Jan 2009 22:37:15 -0800 larry barello la...@barello.net wrote: Thanks for the response. I dug a bit further into the manual and I see that EEPROM can be mapped to SRAM space eliminating the need for library EEPROM support in GCC. Does this EEPROM-SRAM mapping support writing, though? Regards, Colin ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
[avr-gcc-list] Funny business with latest WinAvr 20081205 + xmega128A1 and stdio
I have hit this roadblock in porting over my application from my mega128
test bed to the xmega. As far as I can tell the compiler completely wedges
a very simple routine (and it worked earlier, so it *must* be something I am
doing.)
Anyway, the code is below. The compiler fails to re-load R24 with the
proper stack value after poking the CCP register..
The generated code is the same -Os and -O1, I have not tried anything else.
void PrintBanner(FILE *fp)
{
fprintf_P(fp, PSTR(%s\r\n), VersionString);
}
75 .global PrintBanner
77 PrintBanner:
78 .LFB93:
79 .LM9:
80 .LVL6:
81 /* prologue: function */
82 /* frame size = 0 */
83 .LM10:
84 003a 00D0rcall .
85 003c 00D0rcall .
86 003e EDB7 in r30,__SP_L__
87 0040 FEB7in r31,__SP_H__
88 0042 3196 adiw r30,1
89 0044 ADB7 in r26,__SP_L__
90 0046 BEB7in r27,__SP_H__
91 0048 1196 adiw r26,1
92 004a 8D93st X+,r24
93 004c 9C93 st X,r25
94 004e 1297sbiw r26,1+1
95 0050 80E0 ldi r24,lo8(__c.5488)
96 0052 90E0 ldi r25,hi8(__c.5488)
97 .LVL7:
98 0054 8283 std Z+2,r24
99 0056 9383 std Z+3,r25
100 0058 80E0 ldi r24,lo8(VersionString)
101 005a 90E0 ldi r25,hi8(VersionString)
102 005c 8483std Z+4,r24
103 005e 9583 std Z+5,r25
104 0060 0E94 call fprintf_P
105 0064 8DB7 in r24,__SP_L__
106 0066 9EB7 in r25,__SP_H__
107 0068 0696 adiw r24,6
108 006a 082E mov __tmp_reg__,r24
109 006c 88ED ldi r24,0xD8
110 006e 84BF out __CCP__,r24
111 0070 9EBF out __SP_H__,r25
112 0072 8DBF out __SP_L__,r24
113 0074 802D mov r24,__tmp_reg__
114/* epilogue start */
115.LM11:
116 0076 0895 ret
___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
RE: [avr-gcc-list] Funny business with latest WinAvr 20081205 + xmega128A1 and stdio
It looks like all fprintf/sprintf/etc. for the xmega is broken in this
release. No matter how I craft it the same code pattern is repeated with
the mangling of the stack on clean-up.
Sigh.
From: avr-gcc-list-bounces+larry=barello@nongnu.org
[mailto:avr-gcc-list-bounces+larry=barello@nongnu.org] On Behalf Of
larry barello
Sent: Saturday, January 17, 2009 12:38 PM
To: avr-gcc-list@nongnu.org
Subject: [avr-gcc-list] Funny business with latest WinAvr 20081205 +
xmega128A1 and stdio
I have hit this roadblock in porting over my application from my mega128
test bed to the xmega. As far as I can tell the compiler completely wedges
a very simple routine (and it worked earlier, so it *must* be something I am
doing
)
Anyway, the code is below. The compiler fails to re-load R24 with the
proper stack value after poking the CCP register..
The generated code is the same Os and O1, I have not tried anything else.
void PrintBanner(FILE *fp)
{
fprintf_P(fp, PSTR(%s\r\n), VersionString);
}
75 .global PrintBanner
77 PrintBanner:
78 .LFB93:
79 .LM9:
80 .LVL6:
81 /* prologue: function */
82 /* frame size = 0 */
83 .LM10:
84 003a 00D0 rcall .
85 003c 00D0 rcall .
86 003e EDB7 in r30,__SP_L__
87 0040 FEB7 in r31,__SP_H__
88 0042 3196 adiw r30,1
89 0044 ADB7 in r26,__SP_L__
90 0046 BEB7 in r27,__SP_H__
91 0048 1196 adiw r26,1
92 004a 8D93 st X+,r24
93 004c 9C93 st X,r25
94 004e 1297 sbiw r26,1+1
95 0050 80E0 ldi r24,lo8(__c.5488)
96 0052 90E0 ldi r25,hi8(__c.5488)
97 .LVL7:
98 0054 8283 std Z+2,r24
99 0056 9383 std Z+3,r25
100 0058 80E0 ldi r24,lo8(VersionString)
101 005a 90E0 ldi r25,hi8(VersionString)
102 005c 8483 std Z+4,r24
103 005e 9583 std Z+5,r25
104 0060 0E94 call fprintf_P
105 0064 8DB7 in r24,__SP_L__
106 0066 9EB7 in r25,__SP_H__
107 0068 0696 adiw r24,6
108 006a 082E mov __tmp_reg__,r24
109 006c 88ED ldi r24,0xD8
110 006e 84BF out __CCP__,r24
111 0070 9EBF out __SP_H__,r25
112 0072 8DBF out __SP_L__,r24
113 0074 802D mov r24,__tmp_reg__
114 /* epilogue start */
115 .LM11:
116 0076 0895 ret
Internal Virus Database is out of date.
Checked by AVG - http://www.avg.com
Version: 8.0.176 / Virus Database: 270.10.7/1892 - Release Date: 1/13/2009
8:04 PM
___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
RE: [avr-gcc-list] Funny business with latest WinAvr20081205+ xmega128A1 and stdio
This bug was worth the two hours of anxiety I suffered waiting for Anatoly to reply with, unbelievably, a hand-patch of the compiler executable! Cheers! -Original Message- From: Weddington, Eric [mailto:ewedding...@cso.atmel.com] Sent: Monday, January 19, 2009 3:48 AM To: Anatoly Sokolov; larry barello; avr-gcc-list@nongnu.org Subject: RE: [avr-gcc-list] Funny business with latest WinAvr20081205+ xmega128A1 and stdio Ah, thanks Anatoly! I thought it was that bug. Larry, I'm planning on a WinAVR release sometime in early February, and it will include Anatoly's fix for this bug. Eric Weddington -Original Message- From: Anatoly Sokolov [mailto:ae...@post.ru] Sent: Monday, January 19, 2009 9:03 AM To: Weddington, Eric; larry barello; avr-gcc-list@nongnu.org Subject: Re: [avr-gcc-list] Funny business with latest WinAvr20081205+ xmega128A1 and stdio Is there a WinAVR bug report filed for this? Yes. This is the sourceforge.ne bug #2490164 XMega (128A1): subroutine calling may corrupt stack pointer http://sourceforge.net/tracker/index.php?func=detailaid=24901 64group_id=68108atid=520074 Anatoly. ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
RE: [avr-gcc-list] Typdef chick 'n egg situation.. way out ?
Use a struct tag, rather than the typdef tag for your storage type, as:
typedef struct _TMenu
{
...
struct _TMenuItem items[];
}
TMenu;
typedef struct _TMenuItem
{
...
struct _TMenu *ptr;
...
}
MenuItem;
-Original Message-
Subject: [avr-gcc-list] Typdef chick 'n egg situation.. way out ?
Hi list,
Problem: I have two typdef's statement, each type contains a pointer to
the other type ! Hmmm
typedef TMenuItem struct {
chartext[20];
TMenu *ptr;
void (*fptr)();
};
typedef TMenu struct {
uint8_t nb;
chartitle[20];
TMenuItem items[];
};
I am basically rewriting (following a computer crash..) a program I did
3+ years ago.. all from memory. Back then ISTR some kind soul on here,
sorted me out with something he called forward declaration... but I
can't seem to manage to find this particular post in the list archive
sadly.
I think it was a line just saying TMenu will be defined further down,
don't worry Mister GCC and just accept my TMenuItem struct below, you
will find TMenu soon enough. Something to that effect ! ;-)
TIA...
Regards,
--
Vince
___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
RE: [avr-gcc-list] A couple GCC warnings I would like to understand / get rid of...
the compiler is complaining because you have an extra or a missing const
in your structure definitions. There is a mismatch between your flash
declaration and the type of pointer within your struct. Probably adding a
const keyword to the pointer within your struct and removing the const in
your declaration will fix the problems.
-Original Message-
From: avr-gcc-list-bounces+larry=barello@nongnu.org
[mailto:avr-gcc-list-bounces+larry=barello@nongnu.org] On Behalf Of
Vincent Trouilliez
Sent: Thursday, January 22, 2009 8:20 AM
To: avr-gcc-list@nongnu.org
Subject: [avr-gcc-list] A couple GCC warnings I would like to understand /
get rid of...
Hi,
I am having a couple GCC warning I would like to understand and
hopefully clear with a graceful modification of my code, if anyone can
help...
Basically it's to do with the structures I put in Flash, and the
pointers to these structures (which are themselves located in said
structures).
When I initialize the structure with constant data, GCC coughs about
the field where I store the pointer.
Then later in the code, when trying to retrieve/read that pointer and
use it, I also get a warning.
It has to be said that GCC actually understands what I want to do,
because it stored and retrieved the correct pointer value, and my
program works as expected. It's just that these warning are annoying
and of course, maybe I did do a mistake in the syntax, and that would be
the opportunity to learn a little something new today..
#1 warning: when storing pointer in Flash
--
Pointer is stored in structure menu_main, and points to menu_sub
(structure of the same type).
//target structure
const struct TMenu menu_sub PROGMEM = {
};
//struct holding the pointer
const struct TMenu menu_main PROGMEM = {
...
{ , menu_sub,...}, ---WARNING
}
};
The warning is:
warning: initialization from incompatible pointer type
I don't understand why it's incompatible. I the structure is define as
this:
struct TMenu;
struct TMenuItem {
chartext[20];
struct Tmenu*ptr;
void (*fptr)();
};
the pointer ptr is declared as a pointer to a structure of type TMenu,
and of course I initialize it with the address of such a structure
(menu_sub), so... where is the incompatibility ? :-/
#2 warning: when retrieving/reading pointer from Flash
--
//--
// declare pointers of same type as found in struture,
// in order to read them from flash
void (*FncPtr)();
const struct TMenu *SubPtr;
FncPtr = pgm_read_word( (p-items[cursor].fptr) );
SubPtr = pgm_read_word( (p-items[cursor].ptr) );
//-
I get a identical warning for each of these lines/reads :
warning: assignment makes pointer from integer without a cast
Here for a change, I think I can, agree with GCC, since pgm_read_word
returns an integer, but what's the syntax to turns that back into the
pointer it once was ?!
Something like that ?
FncPtr = ( void (*FncPtr)() )pgm_read_word( (p-items[cursor].fptr) );
and similarly:
SubPtr = (*SubPtr)pgm_read_word( (p-items[cursor].ptr) );
Tried, doesn't work...
A cyber beer offered to anyone with the answer :-)
Regards,
--
Vince, still at the very bottom of the learning curve, brrr...
___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
[avr-gcc-list] xmega128A1 + WinAvr 20081205
Is anyone successfully using WinAvr and Xmega (and fp/printf) in a significant project? I already corrected the vararg problem and have my project running, but there is a rare stack corruption problem with the xmega that I don't see on the mega series (mega128 and mega1280). Interrupts and i/o change protection are the big differences between the two series so that seems like a possible source of errors. I have five serial sources and a 1khz system timer and a multitasking kernel that relies on nesting interrupts (run to completion model) and a GUI. So it is pretty busy and, as I said, works sweet on the m128. The problem is subtle. There is no evidence of stack overrun. Just one task eventually ends up somewhere it shouldn't be and dies. Evidence pointing to it being my problem is that it is always the same task and indirectly the same routine because if I cut the routine out, the problem either disappears or becomes so rare I never wait long enough. The routine is a character glyph bitblit. The evidence that it isn't my code is that I have two other bitblit routines (windows bmp, and a specialized fill routine) that have the same code in their core (about a dozen lines) and they don't fail. Failure occurs in minutes to hours after starting a test screen. Anyway, I am running out of ideas and starting to consider moving to the mega1280. I don't want a big discussion, but would be interested in knowing if others have success, or have seen problems. That will help me decide if I am going to pursue this more (i.e. my code issues, or possible compiler issues) or drop it (chip issues). TIA ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
RE: [avr-gcc-list] WinAvr 20081205 and Xmega AVR
Uh, I cut that out of the v10 xmega patch file, changed SPH/L but didn't change the A/B. So yeah, your way looks like it would work :) -Original Message- From: Weddington, Eric [mailto:ewedding...@cso.atmel.com] Sent: Thursday, February 05, 2009 9:04 PM To: larry barello; avr-gcc-list@nongnu.org; Anatoly Sokolov Subject: RE: [avr-gcc-list] WinAvr 20081205 and Xmega AVR -Original Message- From: avr-gcc-list-bounces+eweddington=cso.atmel@nongnu.org [mailto:avr-gcc-list-bounces+eweddington=cso.atmel@nongnu. org] On Behalf Of larry barello Sent: Wednesday, February 04, 2009 11:52 AM To: avr-gcc-list@nongnu.org Subject: [avr-gcc-list] WinAvr 20081205 and Xmega AVR So what should really happen is: return ( AS2 (out,__SP_L__,%B1) CR_TAB + AS2 (out,__SP_H__,%A1)); Shouldn't %A1 be in __SP_L__, and %B1 be in __SP_H__, like so?: + return (AS2 (out,__SP_L__,%A1) CR_TAB + AS2 (out,__SP_H__,%B1)); ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
[avr-gcc-list] RE: inline control
I explicitly inline code with the following attribute #define _INLINE_ static inline __attribute__((always_inline)) For my medium size project (lots of menus/graphics/various sensors and serial port devices) 1) -no-inline-small-function- 69034 2) --param inline-call-cost=2 - 68964 3) -fno-inline - 68816 4) -finline-limit=10- 68810 5) #2 #4 - 68754 6) -finline-limit=3 - 68754 (same results for 1,2 and 3) Since I am generally not too concerned about overall speed I prefer small size and explicit _INLINE_ where I deem appropriate... Usually the speed I am worried about is how long it takes to download another version while debugging :) Anyway, thanks for the pointers and I am glad I spent 20 minutes trying them out! Cheers! -Original Message- From: avr-gcc-list-bounces+larry=barello@nongnu.org [mailto:avr-gcc-list-bounces+larry=barello@nongnu.org] On Behalf Of Ruud Vlaming Sent: Monday, February 16, 2009 6:40 AM To: avr-gcc-list@nongnu.org Subject: Re: [avr-gcc-list] Code optimistaion in AVR Tiny13 On Monday 16 February 2009 15:11, Robert von Knobloch wrote: On inspection I find that the compiler has 'in-lined' at least 3 function calls that I had written as a function to achieve compactness. Is there any way I can stop this, or is this a bug? There has been some discussions about this before. After trying many different optimization settings i concluded that --param inline-call-cost=2 is -overall- the best setting for small projects. However, if you need to minimize just one app, further reduction might be possible. For example with things like: -fno-inline-small-functions -fno-split-wide-types -fno-tree-scev-cprop Also, you can prohibit the compiler to inline on a function by function basis. Just to be sure you have no dead code around, include: -ffunction-sections -Wl,--gc-sections -Wl,--relax Ruud. ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
[avr-gcc-list] GCC code gen on xmega
What follows is a pretty typical sequence for a vararg function on the XMEGA. In particular, why does the code generator do the funky double call rather than just subtract the right number from the SP? I am guessing this is a left-over code from the early XMEGA stack handling. Also typical, the compiler loads a second pointer to the stack just to poke out the address of the sprintf buffer - even though the information was already in Z. I see that kind of sequence a lot in my code. I always figured the compiler was making the least expensive choice when deciding to recomputed vs. store a pointer, but now I am not so sure. Finally, I suppose if it was simple it would have been done already: if there are multiple calls to printf and friends, the entire sequence of setting up and tearing down the stack occurs over and over again - and that is on top of any setup and teardown performed for the function (say, a buffer on the stack). In general, this kind of code inefficiency doesn't bother me much because I usually factor the routines to minimize the code, and the processor is so blazingly fast I don't care about the cycles. I just noticed this while looking for code sequences that might cause stack corruption. PS. this is the alpha CC1 Eric gave me that corrects the XMEGA SP handling... 122 0098 00D0 rcall . 123 009a 00D0 rcall . 124 009c EDB7 in r30,__SP_L__ 125 009e FEB7 in r31,__SP_H__ 126 00a0 3196 adiw r30,1 127 00a2 ADB7 in r26,__SP_L__ 128 00a4 BEB7 in r27,__SP_H__ 129 00a6 1196 adiw r26,1 130 00a8 ED92 st X+,r14 131 00aa FC92 st X,r15 132 00ac 1297 sbiw r26,1+1 133 00ae 80E0 ldi r24,lo8(__c.6529) 134 00b0 90E0 ldi r25,hi8(__c.6529) 135 00b2 8283 std Z+2,r24 136 00b4 9383 std Z+3,r25 137 00b6 8091 lds r24,Params+6 138 00ba 9091 lds r25,(Params+6)+1 139 00be 8483 std Z+4,r24 140 00c0 9583 std Z+5,r25 141 00c2 0E94 call sprintf_P 142.LM10: 143 00c6 8DB7 in r24,__SP_L__ 144 00c8 9EB7 in r25,__SP_H__ 145 00ca 0696 adiw r24,6 146 00cc 8DBF out __SP_L__,r24 147 00ce 9EBF out __SP_H__,r25 ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
[avr-gcc-list] cLib... Reentrant?
Is the cLib, in general, written as reentrant code? Specifically floating point (yes), printf and friends?, small string functions (strcat_P(), etc)? intrinsic like div() and ldiv()? I realize there are issues with the stdio stuff since the file descriptors are static and it is up to the i/o routines to be written properly. If I have multiple pre-emptive tasks using, say, stdin, do I need to do anything beyond making sure the char_in and char_out routines are properly written/protected (buffers, etc). ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
RE: [avr-gcc-list] Re: Passing a string variable to lcd_puts
The way I deal with this is to think of char as a distinct type different than unsigned or signed char. The compiler certainly thinks that way. So, either keep all your type's the same, or, cast. But don't mix and match char with the others - the compiler is complaining because it will mess your code up! To reiterate: don't assume signed or unsigned for char you will be bitten. I was, just yesterday, bitten where comparing a char to 0xB0 failed, but comparing a uint8_t succeeded (and made for smaller code.) Another way to deal with the typeness of stuff is to make the type explicit. Either cast the constant: #define cHeader ((uint8_t)0xB0) or make a local variable that the compiler will throw away when it is done: static const uint8_t cHeader = 0xB0; In my case, yesterday, I cheesed out and just made the input type uint8_t and moved on. If I was not in a hurry I would have made the constants type explicit. I'll probably pay for that decision sometime in the future when the code breaks and I spend an hour or four figuring it out, again. Oh, yeah: Job security! YMMV From: avr-gcc-list-bounces+larry=barello@nongnu.org [mailto:avr-gcc-list-bounces+larry=barello@nongnu.org] On Behalf Of David VanHorn Sent: Monday, March 30, 2009 10:15 AM To: avr-gcc-list@nongnu.org Subject: Re: [avr-gcc-list] Re: Passing a string variable to lcd_puts I am still very puzzled over why the compiler balks wether I use signed or unsigned chars to feed lcd_puts. When I used unsigned char it balked. When I used char, it didn't. Now when I use int8_t or uint8_t, it balks. No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.0.238 / Virus Database: 270.11.21/2014 - Release Date: 03/30/09 08:40:00 ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
RE: [avr-gcc-list] WINAVR with GCC 4.3.3
I have spent a fair amount of time trying out various compiler options and
this is what I settled on for large projects. A lot of suggested options
made no significant difference in my projects however, your mileage may
vary, so give em a try and see what happens:
CFLAGS += -funsigned-bitfields -fpack-struct -fshort-enums
CFLAGS += -fno-inline
#CFLAGS += -fno-inline-small-functions
#CFLAGS += -finline-limit=3
#CFLAGS += --param inline-call-cost=2
#CFLAGS += -fno-if-conversion
#CFLAGS += -fno-split-wide-types
CFLAGS += -mcall-prologues
CFLAGS += -Wall -Wstrict-prototypes
For a small project (e.g. tiny26) I think explicit inlining works best. For
larger projects (as above) the biggest win was call-prologues. The
inline-limit=2 worked as well or better than explicit inlining, but since
I inline for specific reasons, I just keep it explicit.
you might find this #define useful
#define _INLINE_ static inline __attribute__((always-inline))
as in
_INLINE_ void SomeFunction(void) {}
-Original Message-
From: avr-gcc-list-bounces+larry=barello@nongnu.org
[mailto:avr-gcc-list-bounces+larry=barello@nongnu.org] On Behalf Of
Royce Pereira
Sent: Monday, June 22, 2009 6:37 AM
To: avr-gcc-list@nongnu.org
Subject: Re: [avr-gcc-list] WINAVR with GCC 4.3.3
Hi,
I have a project built around a Tiny26.
It was compiled with WinAVR-20070525.
I'd stuck to this version for a long time, until recently when I upgraded to
20090313.
Soon after, I had to recompile my project due some change in specs.
Imagine my shock when AVRstudio complained that the hex file was too big for
the device !
Upon further checking I found the code size at 2234 bytes - correctly too
big for the tiny26.
I quickly compiled with the older WinAVR, and the code size was back to
original- 1760 bytes ...whew - tears of relief !!
The new WinAVR bloated the code by about 500 bytes . Wow.
Various posts on this list have indicated that each new release bloats the
code ??
If that is true, then, by 2012, I'll have to redesign my current Tiny2313 /
Tiny26 projects around a Mega128 :-)) !!!
(lol)
Regards,
--Royce.
___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 8.5.339 / Virus Database: 270.12.78/2185 - Release Date: 06/22/09
06:54:00
___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
RE: [avr-gcc-list] Format of HEX file when program memory addresses exceed 64K
It has been a while since I wrote my boot-loader, but if I recall, there are two ways: you can set an extended address register which adds to the hex record address, or you can set a segment which is an address shifted over 4 bits or something like that. It is in the intel spec. Just look at the record definitions. In your specific case, you will end up with a short record between the low and high hex stuff with the new base address (or segment). Records following will start at 0. -Original Message- From: avr-gcc-list-bounces+larry=barello@nongnu.org [mailto:avr-gcc-list-bounces+larry=barello@nongnu.org] On Behalf Of Graham Davies Sent: Thursday, May 06, 2010 11:35 AM To: avr-gcc-list@nongnu.org Subject: [avr-gcc-list] Format of HEX file when program memory addresses exceed 64K I've spent over an hour looking for this information on the Web and in the WinAVR documentation but I can't find it so I'm asking for some pointers. I'm using WinAVR-20081205 with AVRStudio 4.15, letting the GCC plug-in do all the heavy lifting (I'm not writing my own Makefiles or link scripts or anthing like that). The target is an ATmega1280, which is significant to my question because it has more than 64Kbytes of program memory. The output format is Intel HEX and I totally grok what I'm getting now as my program size is less than 64Kbytes. I even know where this is coming from. The generated Makefile uses 'avr-objcopy -O ihex' to get this. What I need to know is what the HEX file is going to look like when my program inevitably grows is size above 64Kbytes. What mechanism will 'objcopy' use to get above sixteen address bits? I need to know this exactly because I need to write a Flash loader to read such a file. I just need to know where to look for this information or what to Google for. Thanks, Graham. ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list No virus found in this incoming message. Checked by AVG - www.avg.com Version: 9.0.819 / Virus Database: 271.1.1/2847 - Release Date: 05/05/10 23:26:00 ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
RE: [avr-gcc-list] Optimization Problem?
Strange rcalls are a fast way to allocate four bytes on the stack for a local... -Original Message- From: avr-gcc-list-bounces+larry=barello@nongnu.org [mailto:avr-gcc-list-bounces+larry=barello@nongnu.org] On Behalf Of Thomas D. Dean Sent: Wednesday, December 29, 2010 11:56 AM To: avr-gcc-list@nongnu.org Subject: Re: [avr-gcc-list] Optimization Problem? On Wed, 2010-12-29 at 11:48 -0800, Thomas D. Dean wrote: Sorry, again. I am really doing good with this post. avr-gcc --version avr-gcc (GCC) 4.3.4 Copyright (C) 2008 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. uname -a Linux asus 2.6.32-26-generic-pae #48-Ubuntu SMP Wed Nov 24 10:31:20 UTC 2010 i686 GNU/Linux tomdean ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
