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
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
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
;
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
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
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
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
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
) 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
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.
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
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
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
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
, 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
?
|
| 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
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
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
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
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
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-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
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
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
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.
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
, 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
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'
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
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:
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
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
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
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
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
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
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
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
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
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
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]
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
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
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
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
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,
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
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
#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
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
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
51 matches
Mail list logo
