Re: [avr-gcc-list] Pgmspace.h Use
Ron wrote:
As Brano suggested, a macro is about as close as you can get. Not
_quite_ what you want, but close:
#define array(i)pgm_read_byte(Array[i])
const prog_char Array[7] = {0x10,0x20,0x30,0x40,0x50,0x60,0x70};
y = array(4);
This is what I did:
unsigned char
ntohex(unsigned char n)
{
return( pgm_read_byte(PSTR(0123456789ABCDEF)+(n0xf)) );
}
--
David Kelly N4HHE, [EMAIL PROTECTED]
Whom computers would destroy, they must first drive mad.
___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] Macro to read /write long to eeprom
On Wed, Aug 10, 2005 at 11:00:20AM +0200, Branislav Katreniak wrote:
Another trick is not to clear the byte in eeprom before the write when
it is sufficient to only clear bits on order to store the value into
eeprom (you save half of the write). There is some datasheet on atmel
site about this.
Which datasheet, please? Which AVR?
What you describe is what we used to do on 68HC11E1. When it came time
to write to EE on Atmega64 I found the control structure was different
in that one does not have separate clear and set steps when writing.
This is the eeprom write routine I use. Later compared to the hand
assembly in avr-libc and found the code size and steps performed were
almost identical. Given that, I'd rather use my own in C under my own
source control.
Notice how it reads first and skips the write if data is identical.
This is the only routine I use for writing EEPROM. If I only write one
byte then this just requires a little extra call setup. Don't see any
point in having another routine with only 2 args rather than 3.
//
//write to EEPROM
//addr is the address within the EEPROM
//cp is where to read data in RAM
//n is the number of 8 bit octets to copy
//
//ee_writes( sram source, ee dest, count );
//
void
ee_writes(const void *cp, void *addr, uint16_t n)
{
uint8_t sreg;// store SREG
for( ; n ; n-- ) {
wdt_reset();
while( EECR (1EEWE) )// wait until ready
;
EEAR = (uint16_t)addr++;
EECR |= (1EERE);// start a read
// Don't write unless the contents have changed:
if( EEDR != *((uint8_t*)(cp)) ) {
EEDR = *((uint8_t*)(cp));// looks frightening
sreg = SREG;// save SREG to preserve global IRQ
cli();// an IRQ would ruin this timing
EECR |= (1EEMWE);// only stays set for 4 clocks
EECR |= (1EEWE);// hit EEWE before EEMWE clears
SREG = sreg;// restore prev global IRQ state
}
cp++;
}
}
--
David Kelly N4HHE, [EMAIL PROTECTED]
Whom computers would destroy, they must first drive mad.
___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] Problems with ATMEGA8 USART
On Aug 13, 2005, at 3:08 PM, juan antonio jimenez martinez wrote:
Hi, Im experimenting some details setting the ATMEGA8 usart, for
example, I have an interrupt driven routine for receiving data, may
problem is how can I clean the buffer in orther to let it ready for
the next reception, I mean, when I send two chars from my computer
to the ATMEGA, the interrupt routine do what I want , but when I
send 10 chars, the buffer that I use to read the incomming data,
reads the two chars that I have send before plus the new data and
as a result I got the 10 chars message incomplete due the two
chars that I have sent before
I hope some one know an answer, because I have tryed with the RXC
flag and it seems not work, or how can I select the sise in bytes
to read at one time, and again flush all the RX usart buffers
You need to learn the basics of a circular buffer. Set aside a buffer
which will not be used by anything other than the receive side of the
serial port. Use two indexes into this buffer, I like to call them
head and tail. Think of it as food goes in at the head, comes
out the tail end.
In RX IRQ always write the character in the buffer at head then
increment head. The IRQ routine never touches tail.
Outside of IRQ if head != tail then read the character at tail and
increment tail. Never change head outside of IRQ.
When either index is incremented beyond the size of your buffer,
reset that index to 0. A quick way to do this is to use a buffer size
which is a power of 2, then mask the index after incrementing.
#define BUFFER_SIZE (15)// 16
volatile uint8_t buffer[BUFFER_SIZE];
volatile uint8_t head;
uint8_t tail;
int my_getchar()
{
int c = -1;// preset with error condition
if( head != tail ) {
c = buffer[tail++];
tail = (BUFFER_SIZE-1);// 0x0f if BUFFER_SIZE is 16
}
return(c);
}
For advanced discussion one would probably wish to put the buffer and
its indexes into a struct so that its obvious to future generations
maintaining your code that the indexes and buffer belong together.
Doesn't make code size one iota bigger:
struct {
uint8_t tail;
volatile uint8_t head, buffer[BUFFER_SIZE];
} uart0;
Next, a purist might insist head and buffer should be volatile as
they are modified within IRQ. Volatile does not hurt anything in this
case but doesn't help unless my_getchar() is inlined and used within
a loop waiting for input. Avr-gcc is capable of inline functions so I
used volatile.
If tail were volatile then it would have to be read for the index and
increment, and read again to be masked. Not volatile, the compiler
can use the copy of tail already in its registers and write only
after it has no more use of it.
--
David Kelly N4HHE, [EMAIL PROTECTED]
Whom computers would destroy, they must first drive mad.
___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] Problems with ATMEGA8 USART
On Aug 14, 2005, at 4:21 AM, Bob Paddock wrote:
On Saturday 13 August 2005 08:35 pm, David Kelly wrote:
For advanced discussion one would probably wish to put the buffer and
its indexes into a struct so that its obvious to future generations
maintaining your code that the indexes and buffer belong together.
Doesn't make code size one iota bigger:
struct {
uint8_t tail;
volatile uint8_t head, buffer[BUFFER_SIZE];
} uart0;
On the Mega162 with two USARTs I tried it both ways. Duplicate the
code for
each USART, and using a common driver with structures. The duplicate
approach came out smaller in code space. Don't recall the exact
number but
it was more than a few bytes of difference.
Did that myself, partially, on an ATmega64. my_getchar() and family
require a pointer to struct of type UART to know which buffer to
manipulate.
The partial part was that I did not use common code to service the
Tx and Rx interrupts. All user code (that which runs outside of IRQ
time) was shared for both serial ports. For the very little space
savings a very large hit occurred by referencing USART registers via
double de-referenced pointers. Also the first thing an IRQ routine
would have to do is figure out whether UART 0 or 1 or both needs
attention. With separate routines one instantly and correctly knows
which is in need of attention and register addresses are hard coded
at link time.
The one clumsy part of code was in my_putchar() which had to reach
directly into the hardware for the specific port to restart the Tx
IRQ if the buffer had been empty, which causes my Tx IRQ routine to
shut itself off. Also there was a possible race condition.
--
David Kelly N4HHE, [EMAIL PROTECTED]
Whom computers would destroy, they must first drive mad.
___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] Cicrular Buffer routines
On Aug 16, 2005, at 6:07 PM, Bob Paddock wrote: You can test to make sure that you do have a power of two buffer size with the following: #define myQ_SIZE64 #define myQ_MASK ( myQ__SIZE - 1 ) #if ( myQ__SIZE myQ__MASK ) #error myQ_SIZE buffer size is not a power of 2 #endif Wouldn't it be easier to simply define the size like this: #define myQ_SIZE(16) If you shift a 1 then it must be a power of 2. -- David Kelly N4HHE, [EMAIL PROTECTED] Whom computers would destroy, they must first drive mad. ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] CALLBACK?????????
On Thu, Aug 25, 2005 at 07:45:22AM -0700, User Tomdean wrote: A callback is a function that will be called as a result of some pre-determined event or condition. The application code starts a function or routine that never returns. To get back to the application code, the callback function is called. For example, in networking, a callback function will be defined to be called by the network code in response to receiving a packet. See also the qsort() function in libc. Its arg list requires the address of a function to call for comparing two elements one is sorting. Qsort() doesn't have to know what it is sorting or how it is being ordered, the comparison function is expected to know. A callback routine by any other name. Yes, the docs say qsort() sorts in ascending order, but if the comparison function inverts its reply then the order is descending. -- David Kelly N4HHE, [EMAIL PROTECTED] Whom computers would destroy, they must first drive mad. ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] Re: [avr-libc-dev] Please have a look at avr-libc patch #3750
On Sep 5, 2005, at 9:19 AM, Joerg Wunsch wrote: 1. To change the order of arguments 'put' as: int (*put)(FILE *, char) -- int (*put)(char, FILE *) It would allow to leave the asm program 'put' without changes. But only these. ;-) For C programs, they'd yield a compile-time error due to the different function prototypes. Unix is putc(char, FILE*) so I think the put() function in avr-libc should be same. -- David Kelly N4HHE, [EMAIL PROTECTED] Whom computers would destroy, they must first drive mad. ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] Re: EEprom variable ordering
On Sep 7, 2005, at 2:34 AM, Wolfgang Wegner wrote: Thank you, Björn and Jörg, I really did not think about using a struct for all of the variables, but this is obviously the best solution. And if you name the struct something like ee then you have a visual naming reminder of how the contents must be accessed. I don't much care about the order of my eeprom variables, but everything in eeprom is named with an ee_ prefix. -- David Kelly N4HHE, [EMAIL PROTECTED] Whom computers would destroy, they must first drive mad. ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] How Hot does a 62256-15 SRAM Get?
On Sep 9, 2005, at 2:33 AM, [EMAIL PROTECTED] wrote: Be careful ! You use an 15ns SRAM (as I see so far in the part number). They will draw a bit more current than 70ns SRAM's. Can you post the Currents from the datasheet ? Back in the bad old days a -15 was a 150 ns part. To answer the power consumption and timing questions one must find the data sheet specific to the proposed component. As for heating, back in the bad old days we used to stack DIP 62256-12's on top of each other in parallel leaving the chip select pin hanging out of the upper chips to be z-wired to address decoders. Never observed any warming of these parts. -- David Kelly N4HHE, [EMAIL PROTECTED] Whom computers would destroy, they must first drive mad. ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] Initilizing complex const arrays : syntax ?
On Sep 18, 2005, at 3:02 PM, Vincent Trouilliez wrote: Do I need to use some variant of the printf function when displaying data declared with the __ATTR_PROGMEM__ attribute ? Yes. printf_P(). Better read the manual as I don't use printf() so I haven't used printf_P() and can't say how or whether you can mix memory spaces in one _P function call. Doesn't the compiler take care of this automatically ? Nope. Been talked about. GCC 3.x lacks the hooks to deal with multiple address spaces. Something that 4.x might. This is the one minor detail where at least some commercial AVR C compilers do better. There are at least 3 address spaces in the AVR: SRAM, FLASH, and EEPROM. Maybe SFR is 4th but think that is in SRAM space. -- David Kelly N4HHE, [EMAIL PROTECTED] Whom computers would destroy, they must first drive mad. ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] Initilizing complex const arrays : syntax ?
On Sep 18, 2005, at 5:33 PM, Vincent Trouilliez wrote:
On Sun, 2005-09-18 at 16:54 -0500, David Kelly wrote:
...I don't use printf() so I haven't used printf_P()
But how do you do then ?
If you wrote better functions, please share ! :-)
Printf takes huge space, so if you have a light weight alternative...
Printf()'s bulk comes from the generic format string parser. Hardcode
your format something like this:
#include stdlib.h// for utoi()
char buffer[10];// presumably this is something you can reuse
//
//Convert unsigned x to base 10 and output x.xx via putchar()
//
void
dot_two( uint8_t x )
{
// char buffer[4];// use global or auto
int8_t i, n;
char *cp;
cp = utoi( x, buffer, 10 );
n = strlen(cp);
// a for() loop is possibly much for just 3 characters
for( i = 3 ; i ; i-- ) {
if( n i )
putchar('0')
else
putchar(*cp++);
if( i == 3 )// test for our decimal point location
putchar('.');
}
}
void
another_dot_two( uint8_t x )
{
int8_t n;
// char buffer[7];// needs to be bigger here
strncpy_P( buffer, PGM_P(000), 3 );// preload leading zeros
utoi( x, buffer[3], 10 );// convert after the zeros
n = strlen(buffer[3]);// number of converted digits
// 012345index
// 0001 buffer[] if n == 1
// 00022 n == 2
// 000333n == 3
putchar( buffer[n] );// see above
putchar( '.' );
putchar( buffer[n+1] );
putchar( buffer[n+2] );
}
--
David Kelly N4HHE, [EMAIL PROTECTED]
Whom computers would destroy, they must first drive mad.
___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] Initilizing complex const arrays : syntax ?
On Sep 18, 2005, at 11:11 PM, Vincent Trouilliez wrote:
Okay, I got your dot_two() working (the another_dot_two() has one last
fatal error that I can't figure out yet).
Yeah well, still not bad for code written in bed on laptop in the
email editor.
I tested it in all fairness. That is, I modified the printf hack from
printf (%d.%03d, x / 1000, x % 1000), to
printf (%d.%02d, x / 100, x % 100)
So that the functionality is the same as dot_two().
Doing this, printf doesn't take 13ms anymore, but 10ms.
And your dot_two() takes... 6ms ! That's a whole 40% faster, not bad
indeed !!! :o)
Your putchar() (or whatever) writes to an LCD? So how long does it
take to latch a character into the LCD?
Another way I thought to write the code without utoa() was something
like this (no I haven't tried this one either):
char buffer[4];
uint8_t i;
strncpy_P( buffer, PGM_P(000), 3 );
i = 2;
while(x) {
buffer[i--] = x%10 + '0';
x = x/10;
}
putchar(buffer[0]);
putchar('.');
putchar(buffer[1]);
putchar(buffer[2]);
In the above I find myself wishing for the FORTH /mod operator. Avr-
gcc calls exactly the same routine for division or modulo and stores
the desired result. In assembly we could store both but I don't see
how to get at both from C. Is possible the compiler could optimize it
but plain -O didn't in recent tests.
--
David Kelly N4HHE, [EMAIL PROTECTED]
Whom computers would destroy, they must first drive mad.
___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] Initilizing complex const arrays : syntax ?
On Mon, Sep 19, 2005 at 05:46:52PM +0200, Vincent Trouilliez wrote: On Mon, 2005-09-19 at 07:33 -0500, David Kelly wrote: Your putchar() (or whatever) writes to an LCD? So how long does it take to latch a character into the LCD? Yep I print to standard text LCD module (4x20), it takes about 45us for the module to digest a character. 4 characters to send, that 0.2ms mximum. So they the LCD really can't be held responsible for the 6ms ;-) OK, 0.2ms max to write one, but how long to write two? Once the data is latched into the LCD it has to process and IIRC that is often 1 ms. I guess most of the time is used doing divisions to convert the byte in digits. But still, that would be 5,000++ cycles just to divide a single byte by 100 then 10, sound a bit dear... there must be space for further improvement ! :-) Another way I thought to write the code without utoa() in your first two functions you used utoi, which wasn't recognized by the gcc, so I had to look in the avr-libc PDF to search for an equivalent and picked up itoa instead. But maybe that wasn't the best(fastest) choice ? No, utoa() was correct. utoi() was a brain fart. Ah, it contains the same line that makes the compiler fail on your another_dot_two() : strncpy_P( buffer, PGM_P(000), 3 ); It says : ui.c:65: error: parse error before const make: *** [ui.o] Error 1 Heck, just pulled that function out of the Doxygen comments in pgmspace.h. This may occupy less space and is sure to run faster: buffer[0] = buffer[1] = buffer[2] = '0'; Just to be safe (because I don't remember all the surrounding code): buffer[3] = 0; // note lack of quotes around 0 -- David Kelly N4HHE, [EMAIL PROTECTED] Whom computers would destroy, they must first drive mad. ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] Initilizing complex const arrays : syntax ?
On Mon, Sep 19, 2005 at 10:19:41AM -0400, Dave Hansen wrote:
Try something like
#include stdlib.h
...
div_t qr;
while(x) {
qr = div(x,10);
buffer[i--] = qr.rem + '0';
x = qr.quot;
}
I'm not certain this is optimal. I haven't looked closely, but it
looks like it should be. It certainly has the opportunity to be.
Yeah! Thats what I was looking for. Exactly a FORTH /mod (pronounced
slash mod)!
div() costs nothing to implement because its almost certain the avr-libc
division primatives will be included at link time. div() is only a macro
wrapping that routine so we can get at both dividend and remainder using
a struct. The exact same primative is used for division and modulo, the
only difference is which result is picked up.
Might be nice to add a udiv() and uldiv() to existing div() and ldiv().
--
David Kelly N4HHE, [EMAIL PROTECTED]
Whom computers would destroy, they must first drive mad.
___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] OT Generic C question
On Sep 20, 2005, at 2:12 PM, Jeff Barlow wrote: Internet email is gradually degrading due to lame software and clueless users. Yes, that is exactly why I wrote. To alert the clueless. Apparently the clueless cherish their cluelessness, but that was nothing new. Yes, the messages are still threaded. Gmail has nothing on anything here. The point is that the messages are in the *wrong* thread. Its purely to the advantage of the poster to break a new topic out of an old thread and start fresh. Another advantage of proper threading is list archive search. Much more likely to find useful information when searching an archive which is properly threaded. Then again list archive searching is another lost art. On Sep 20, 2005, at 1:20 PM, Joerg Wunsch wrote: But in the end, people deploying that kind of laziness will simply cut theirselves off from people who might be willing to reply: If I kill an entire thread as I'm not interested in it, and deep in that thread appears a new question -- ce la vive. I won't be able to answer that new question as I won't see it at all. Some find it hard to believe others might tie their shoes differently. Same applies here as I expect many don't understand how what Joerg said above could be true. Many of us open this mailbox with threads collapsed under one entry. That old tired thread? Kill it. Next. Your query was deleted unseen because it was filed wrong. Because you sent it wrong. And I don't really care. However this needs to be mentioned now and then because sometimes The Clueless Get A Clue. I was split about 51/49 as to whether my posting this morning should continue in this thread or start a new. Decided that it was about this thread and therefore should stay in it. This way it was threaded directly to the message I was talking about if anyone cares to go read the message headers in the thread. And those who were already tired of this thread would not be bothered. -- David Kelly N4HHE, [EMAIL PROTECTED] Whom computers would destroy, they must first drive mad. ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] CVS or SVN ?!
On Sep 30, 2005, at 3:45 AM, Vincent Trouilliez wrote: I have been advised to use CVS when developing programs, but it seems awkward to set up the server side. % cvs -d ~/cvsroot init Then IMHO the simplest remote server access is via ssh. Set CVS_RSH=ssh in your environment and use :ext:yourhostname:/home/ cvsroot as the CVS root. This works very well for all users who have accounts on your host. More recent CVS may accept :ssh: in place of :ext: and not need the CVS_RSH environment variable set. The ssh link is completely transparent of you create passwordless key pairs. This means the security of your account on the repository machine is no better than the security of the host where your private key is kept. While asking around for help, I have been suggested to give up CVS and use SVN, subversion, instead, and that it was meant to supplant CVS. Subversion is new, CVS is tried and true. I do believe subversion is mature enough to use. Now CVS seems difficult enough, so I don't fancy spending time on it, only to have to change to something else soon after... What you are supposed to be doing is learning how to learn, not learning how to point and click operate Microsoft Word to be computer literate. Get experience developing your project under some sort of version control. Learn how to use that system to compare your current source to past sources. Learn how to resurrect past sources. Learn to make many small commits rather than traditional big roll off a copy for the filing cabinet. I would like your opinions on this... what do everyone use at work ? Does it make any difference what system I use, as long as I use one !? Say I find a job in this field, what would my boss be most likely to ask me to use, CVS or SVN ? Or do the bosses not care, and the engineer can use and setup whatever system he prefers or is familiar with ? At work they keep talking about making me move to Microsoft SourceSafe. I counter with, You want to buy another seat for me? as SS isn't cheap unless they have already spent a wad on .NET development tools. Which would be a major waste on me as that is essentially useless for AVR and MC9S12NE64 work. Also SourceSafe does not work from non-Microsoft environments such as FreeBSD and MacOS. CVS does. Subversion does work on MacOS, but only recently has it been supported within other major tools. -- David Kelly N4HHE, [EMAIL PROTECTED] Whom computers would destroy, they must first drive mad. ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] CVS or SVN ?!
On Sep 30, 2005, at 8:42 PM, Parthasaradhi Nayani wrote: Hello all, Most of the list members seem to have used CVS with success, but in our organisation two man months were spent in trying to make WINCVS work but to no avail. Even WINCVS needs a *nix sever I understand. How difficult or rather feasible is it going to be to install and use SVN in a place where there is small net work of about 60 WINDOWS machines? Any help/advice will be highly appreciated. Thank you. Windows-anything is 2nd rate. Especially when it originates on another platform and is ported to Windows. You don't say anything about how WINCVS failed for your group. Am guessing it had a lot to do with the fact the users didn't know what they were doing. The administrators didn't know what they were doing either. That CVS isn't taught in MCSE class. For some reason Windows people think an application which uses shared files on a file server with multiple copies of the same application is a network application. Multiple copies of CVS sharing a repository on a file server is a can of worms for file access permissions. Practically everyone has to have read/write for everything. IIRC there is a chapter about Windows- specific problems like this in the CVS book. -- David Kelly N4HHE, [EMAIL PROTECTED] Whom computers would destroy, they must first drive mad. ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] 32-bits time
On Thu, Oct 13, 2005 at 09:10:17AM +0200, Bjarne Laursen wrote:
A few additions to David Kelly's code:
inline uint32_t timer32_now(void)
{
int8_t sreg;
union {
struct {
uint16_t lo, hi;
} w;
uint32_t l;
uint8_t b[4]; // -- added: access as bytes
} temp;
Below is the way I usually do the above. Didn't have it under my mouse
last night:
typedef union {
uint32_t u32;
int32_t i32;
struct {
uint16_t lo, hi;
} u16;
struct {
uint8_t lo;
uint16_t mid;
uint8_t hi;
} hml;
struct {
uint8_t lo, b, c, hi;
} u8;
struct {
int8_t lo, b, c, hi;
} i8;
} union32_t;
Easy enough to hack into whatever shape desired. The idea is to use
named members of a union rather than type casting and shifting.
--
David Kelly N4HHE, [EMAIL PROTECTED]
Whom computers would destroy, they must first drive mad.
___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] How to (efficeiently !!!) test a bit within a multi-byte integer ?
On Nov 3, 2005, at 11:35 PM, Vincent Trouilliez wrote:
static void log_address_set( uint32_t address )
{
...
...
if (address 0x0004)
PORTB |= LOG_SDA;
else
PORTB = ~LOG_SDA;
...
}
On Nov 4, 2005, at 1:20 AM, Ian Caddy wrote:
I haven't tried this, but it might be better:
unsigned char temp;
temp = (address 16) 0xFF;
if(temp 0x04)
{
/* Your code */
}
In other messages has been replaced with .
Ian is close to how I would have handled it. I use a union32_t type
a fair bit in my code for no other purpose than to pluck values out
of the middle painlessly.
typedef union union32_t {
struct __attribute__ ((packed)) {
uint8_t a, b, c, d;
} u8;
struct __attribute__ ((packed)) {
uint8_t a;
uint16_t bc;
uint8_t d;
} mixed;
struct __attribute__ ((packed)) {
uint16_t ab, cd;
} u16;
uint32_t u32;
};
union32_t address;
if( address.u8.c 0x04 )
...
avr-gcc does the expected without __attribute__ ((packed)) but if
you get to playing in Linux or FreeBSD its needed to do the same as
what avr-gcc does.
Also note the above is sensitive to machine endianess. Macintosh,
Sun, and Irix are big-endian.
--
David Kelly N4HHE, [EMAIL PROTECTED]
Whom computers would destroy, they must first drive mad.
___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] How to (efficeiently !!!) test a bit within a multi-byte integer ?
On Nov 4, 2005, at 6:28 PM, Vincent Trouilliez wrote: Hmmm, it's interesting to see that 3.4.4 is that much better than 3.4.3 ! It means that avr-gcc is being actively improved, that's rather encouraging, at this pace, in 2 or 3 years, it will rival or better the most expensive commercial compilers :o) Long may live Unix/Linux and open source... The biggest difference I found between 3.4.3 and 3.4.4 was the handling of switch statements. Couldn't say that one was significantly better than the other. Apparently I had already coded my 32 bit bit manipulation routines with unions and didn't see the resulting advanced optimization. The little difference was 3.4.3 would often emit two returns at the end of a function where 3.4.4 only used one. -- David Kelly N4HHE, [EMAIL PROTECTED] Whom computers would destroy, they must first drive mad. ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] AVR assembly for fast bit bang
On Tue, Nov 08, 2005 at 03:45:54PM +, Mike S. wrote:
Hello to all,
Can anyone tell me the best (faster) way to implement bit shifting
(serial synch protocol -in a bit bang fashion-) with two general
purpose digital pins (one pin for data the other for clock)? Using C
is not fast enough! I need assembly!
Sounds like a homework assignment. Smart instructors monitor this list.
People keep saying C isn't fast enough. I don't belive it. First
attempt:
#include avr/io.h
#define CLOCK_B (10)
#define BIT_B (11)
void
myjunk(uint8_t byte) {
uint8_t i;
for( i = 0 ; i 8 ; i++ ) {
PORTA |= CLOCK_B; // rising edge of clock
if( byte (17) )
PORTA |= BIT_B; // set
else
PORTA = ~BIT_B;// clear
byte = 1;
PORTA = ~CLOCK_B; // falling edge of clock
}
}
Compiled with
avr-gcc -O -gdwarf-2 -Wall -ffreestanding -mmcu=atmega64 -c junk.c
Output of avr-objdump -S junk.o:
myjunk(uint8_t byte) {
uint8_t i;
for( i = 0 ; i 8 ; i++ ) {
0: 90 e0 ldi r25, 0x00 ; 0
PORTA |= CLOCK_B; // rising edge of clock
2: d8 9a sbi 0x1b, 0 ; 27
if( byte (17) )
4: 88 23 and r24, r24
6: 14 f4 brge.+4 ; 0xc myjunk+0xc
PORTA |= BIT_B; // set
8: d9 9a sbi 0x1b, 1 ; 27
a: 01 c0 rjmp.+2 ; 0xe myjunk+0xe
else
PORTA = ~BIT_B;// clear
c: d9 98 cbi 0x1b, 1 ; 27
byte = 1;
e: 88 0f add r24, r24
PORTA = ~CLOCK_B; // falling edge of clock
10: d8 98 cbi 0x1b, 0 ; 27
12: 9f 5f subir25, 0xFF ; 255
14: 98 30 cpi r25, 0x08 ; 8
16: a8 f3 brcs.-22; 0x2 myjunk+0x2
18: 08 95 ret
Its not going to get much better than that.
--
David Kelly N4HHE, [EMAIL PROTECTED]
Whom computers would destroy, they must first drive mad.
___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] AVR assembly for fast bit bang
On Wed, Nov 09, 2005 at 09:00:58AM -0500, Dave Hansen wrote:
From: David Kelly [EMAIL PROTECTED]
[...]
People keep saying C isn't fast enough. I don't belive it. First
attempt:
[...]
It might be tough to do better on AVR. My standard SPI routine uses a
do-while loop, which might save an instruction or two, but made
about a 30%
difference on the PIC compiler I used. Something like
void output_spi_byte(uint8_t byte)
{
uint8_t bit_ctr = 8;
do
{
output_low(SPI_DATA); // Set data bit low...
if (byte 0x80)
output_high(SPI_DATA); // ...or high, as required
output_high(SPI_CLK);
byte = 1; // Shift acts as clock dwell delay
output_low(SPI_CLK);
} while (--bit_ctr);
}
I don't have avr-gcc handy to see if it's any better than your
code. I was
more concerned with size than speed, as you may be able to tell.
If speed
is the ultimate object, unrolling the loop will help.
The above compiles to 14 bytes with slight changes
(output_low/output_high macros). But I would suggest putting
output_low(SPI_DATA) as an else to if (byte 0x80) as needless
transitions consume power, generate noise, and sometimes confuse the
connected device. Moving it into an else results in 16 byte code.
Forgot how big mine was. A little big bigger IIRC.
--
David Kelly N4HHE, [EMAIL PROTECTED]
Whom computers would destroy, they must first drive mad.
___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] C programming for AVR
On Nov 22, 2005, at 12:28 AM, techie_avr (sent by Nabble.com) wrote: Do anyone know whether AVR based C programming(AVR-GCC) supports ARRAYS? Pretty long stretch to call the language C if it did not. Would say you didn't do any homework on avr-gcc other than find this list before asking as there are many examples of avr-gcc code laying around on the 'net for you to study. For instance, avr-libc. -- David Kelly N4HHE, [EMAIL PROTECTED] Whom computers would destroy, they must first drive mad. ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] Porting code to/from codevision
On Nov 23, 2005, at 6:15 PM, Peter Harrison wrote: Specifically, I have a largeish lookup table (4k) and menu data (titles, function pointers etc) to deal with. I have considered using a macro for the data access so that I can write value = READ_FLASH_BYTE(addr); and define the macro as null in CVAVR or as required by AVRGCC. However, I am less sure about the declarations and can't get my head round a suitable dodge. Just to make things more awkward, I may well want this code to compile with the ARM and H8 GCC compilers. On the PC, I simply have a macro that defines 'flash' as null and the code compiles just fine. Is this overdoing the portability thing? No, thats what macros and include files are all about. In general avr-gcc uses macros to modify data access to FLASH, and to modify for declaring data stays in FLASH and should not be copied to RAM during startup. Essentially all you have to do is create NULL versions for Codevision or insert whatever special things Codevision likes. -- David Kelly N4HHE, [EMAIL PROTECTED] Whom computers would destroy, they must first drive mad. ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] how to write specific value to program memory?
On Nov 24, 2005, at 6:49 AM, 임지수 wrote: hi, I am using atmega128 mic. i want program memory to store data, not eeprom. At avrlibc, the file of pgmspace.h provide the function to read the program memory. But I can't find the function to write the program memory. how to write specific value to program memory? Its hard to write to FLASH program memory so its not done very often other than to write executable code and constant data. Also in general FLASH memory can not be reprogrammed as many times before breaking than EEPROM cells. EEPROM is much easier to write but harder to read than FLASH because the AVR EEPROM is not in either of the CPU memory spaces. The solution I use for read-often variables is to declare a structure containing all my EEPROM variables. Then create two allocations of that structure, one in RAM and one in EEPROM. Usually call them ee and wc, for EEprom and Working Copy, that its obvious ee.calibration and wc.calibration are paired. Initialization is easy because one only has to bulk copy ee into wc. Is also practical to bulk copy wc into ee, but I selectively write my updates as needed. -- David Kelly N4HHE, [EMAIL PROTECTED] Whom computers would destroy, they must first drive mad. ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] use of specifin RAM location
On Tue, Nov 29, 2005 at 08:35:05AM +1000, [EMAIL PROTECTED] wrote: I have the same problem, and the point is that part of my external memory is inside an FPGA, basically under control of the FPGA (It's high-speed ADC data), while another part is external SRAM which I use for my heap etc. I access the FPGA memory at the moment using pointers which I initialise to the right value. I don't yet have a method mapped out for the SRAM - it's on the next version of the board (the present version has no external SRAM). I will have a need to allocate some large-ish arrays in the external SRAM in the next hardware version. Memory-mapped peripherals need to be accessed at particular addresses also, however these don't usually need allocation (and hence can be accessed via pointers initialised to the correct address). The cleanest way to pull this off would be to lay a structure on the memory-mapped device and allocate it in a named section. See http://gcc.gnu.org/onlinedocs/gcc-3.4.3/gcc/Variable- Attributes.html#Variable-Attributes Then in the linking stage define the location of the FPGA something like this in Makefile: LDFLAGS= -Wl,-Map,[EMAIL PROTECTED] \ -Wl,--section-start=.eeprom=0x00810001 \ -Wl,--section-start=.fpga1=0x6000 \ -Wl,--section-start=.hsa2d=0x7000 \ -Wl,--section-start=.sram=0x2000 Just use the __attribute__ to tag variables as section .sram and the compiler will find places for them if you don't care about the order. -- David Kelly N4HHE, [EMAIL PROTECTED] Whom computers would destroy, they must first drive mad. ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] Adding date/version information to project??
On Nov 28, 2005, at 10:20 PM, [EMAIL PROTECTED] wrote: Hi all: I am looking for an automated way to update a static string in program space when my project is built. Is there an easy way to do this, either by adding an extra target to the makefile, or some other way? I'd prefer not to manually have to change the information, and I'd also prefer for it to NOT change when none of the other source files change. That is, the requirement is as follows: Incomplete, but this could get you started: Research the ability to run a script or executable from within Windows gmake. Copy stdout into a Make variable something like this: CFLAGS += -DThe_Date_Is=`date` Create a project file named something like makedate.c and tweak the Make rules so that makedate.c must be built for the situations you wish the date to be updated. makedate.c would look something like: const char My_Build_Date[] = The_Date_Is; gcc already has a bluzillion predefined environment variables. I wouldn't be surprised that one contains date and time stamp, lets check: % touch foo.h ; avr-cpp -dM foo.h Nope, didn't see a timestamp. -- David Kelly N4HHE, [EMAIL PROTECTED] Whom computers would destroy, they must first drive mad. ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] Program Space String optimization
On Dec 14, 2005, at 8:57 AM, Joerg Wunsch wrote:
volatile PGM_P txt= P_Txt;
Your volatile qualifier is at the wrong place. You're marking the
object txt points to as volatile, not the pointer itself. Change
that into
PGM_P volatile txt = P_Txt;
and it will work.
Believe that is correct. But the other thing that was tripping him is
in general all function calls are effectively volatile as well. Call
a function and expect it will be called simply because you said to,
the the optimizer probably won't descend into the function and decide
it can be skipped. If the function is inlined then all bets are off.
do{} while( (a=pgm_read_byte(txt)) ); // Wait for null char
While pgm_read_byte(txt) looks like a function call it is totally macro.
I don't believe this is a problem with the compiler at all, it did
exactly what it was told it could do.
--
David Kelly N4HHE, [EMAIL PROTECTED]
Whom computers would destroy, they must first drive mad.
___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] OS for AVR
On Mar 23, 2006, at 1:06 AM, rajeev joshi wrote: can somebody please tell me which OS is suitable for 8-bit AVR with 8k flash memory. Could be of more help if you would explain *why* you want an OS. Some are stronger in certain features than others. -- David Kelly N4HHE, [EMAIL PROTECTED] Whom computers would destroy, they must first drive mad. ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] PLEASE HELP ME
On Mar 27, 2006, at 11:01 AM, Jan Johansson wrote: I would suggest OpenTCP as it requires no OS. You can run it polled from your mainloop or similar way. I used Freescale OpenTCP on an MC9S12NE64. It was very disappointing. Could clearly see where several different people had glued one thing or another together. At least the NE64 version totally lacked a community which is what most people think of first when one says open source. The distributed version had several stupid coding errors. Sending a TCP packet was not terribly easy as the stack only informed one of what was needed, it didn't handle retries transparently. Had to do it over again, would pay $10k or $20k to buy a quality supported TCP/IP stack. Or use uIP. Or write my own. Think I spent more time figuring out the scrambled internals to OpenTCP than it would have taken to use Freescale's provided drivers and write my own stack. The OS requirement for uIP can't be anything much more than for you to provide software timers for it to keep track of time. -- David Kelly N4HHE, [EMAIL PROTECTED] Whom computers would destroy, they must first drive mad. ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] Program Listing With C Comments
On Apr 3, 2006, at 11:39 AM, Vincent Trouilliez wrote: I have tried various flags (-g, -gstabs, -gdwarf-2, for gcc, and -D and -DS for avr-objdump), but no combination would give a satisfactory result. OK, I spoke too soon. For example ui_message_show source is totally separate from its disassembly listing. Get lots of warnings like this: ui.c:762: warning: passing arg 1 of `eeprom_read_byte' makes pointer from integer without a cast ...which might contribut to avr-gcc getting confused and not properly tagging source with code. -- David Kelly N4HHE, [EMAIL PROTECTED] Whom computers would destroy, they must first drive mad. ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] Program Listing With C Comments
On Apr 5, 2006, at 10:53 AM, Vincent Trouilliez wrote: Okay, I just downloaded gcc 3.4.6 and compiled it... but it doesn't give me the error it gives you ?! How come...weird. I'm using the FreeBSD port that Joerg created. He includes several patches for new devices, binary constants, and I don't know what else. -- David Kelly N4HHE, [EMAIL PROTECTED] Whom computers would destroy, they must first drive mad. ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] Is this what we get for trying to help?
On Oct 14, 2006, at 8:29 AM, Niklas Lövgren wrote: Hmmm. It seems some people lack social skills! Submit a bug report. Maybe it'll make it into GCC 6.6.6. :-) -- David Kelly N4HHE, [EMAIL PROTECTED] Whom computers would destroy, they must first drive mad. ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] Bit-wise structure and unions
On Tue, Nov 21, 2006 at 01:31:13PM -0700, Eric Weddington wrote: You should really use the C language bitwise operators (|, , ~, ^, , ) and use bit masks to manipulate the bits that you want. The bit-wise operators have one advantage over using the bit-field structure. Using bit-wise operators you can operate on multiple, *non-contiguous* bits simultaneously within a variable. You can't do that with bit-field structures. I agree with Eric. I'll typically define STATUS_LED_m and STATUS_LED_p and write STATUS_LED_p |= STATUS_LED_m or variations thereof. The generated code won't be any smaller with a bitfield. Eric makes a good point that one can smack multiple bits with one punch this way, not only for smaller code but because often one desires all outputs to change at the same time, not several clock cycles apart. One other point is that I/O registers often return the value on the pin, not the value previously written. Doubt one wants a read-modify- write instruction to read an incorrect value as will happen if the pin is overloaded. In this case is best to have a copy of the port's intended value laying around in RAM, so one more define for STATUS_LED_r and write STATUS_LED_p = (STATUS_LED_r |= STATUS_LED_m); Think that will evaluate correctly without parenthesis, but they help when reading. Some MCU families (believe HC12 is one) have a separate register for reading the port's actual input/external value, and another for reading output latches containing the value last written. A bitfield works fine on the output latch register. -- David Kelly N4HHE, [EMAIL PROTECTED] Whom computers would destroy, they must first drive mad. ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] eeprom issue
On Fri, May 11, 2007 at 09:12:58AM +1200, Gavin Jackson wrote: Steve Since the .h file is pulled into each .c file, you would end up with two declarations for temp_ee, hence the two 0x0A values in your ee.hex file. If you remove the static keyword the compiler should complain that you have two global variables with the same name. The correct place to declare the variable would be in the .c file and not in the header. Yes, if it is supposed to be static then its supposed to be hidden from other modules so its not proper to put in a header which is reused unless each and every re-use is supposed to have its own private copy. I prefix most everything in headers with extern, then repeat the definition without extern in one and only one .c file, but in one that does include the header. If the two definitions do not match the compiler complains. Meanwhile all other modules have access to the variable. In The Bad Old Days many defined all variables in headers which were included many times in the project. Compiler/linkers typically eliminated the multiple definitions. Things worked, but were asking for trouble. I expect extern static is a contradictory statement which would cause gcc to bellyache. Haven't tried it, just guessing. -- David Kelly N4HHE, [EMAIL PROTECTED] Whom computers would destroy, they must first drive mad. ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] mac-avr
On Jul 8, 2007, at 4:51 AM, Steven Michalske wrote: i am in the process of making a Mac OS X universal binary installer of the tool chain basically a mac-avr version of win-avr which version of gcc should I build in and which patches should I apply? If you are going to make a MacOS version of WinAVR then by golly you should sync to sources and patches identical to what Eric uses. That or use the FreeBSD avr port as your baseline. Joerg and Eric stay in close sync, sometimes Joerg leads as the FreeBSD port is updated more often than WinAVR. There are at least two projects using the name MacAVR. Are you one of those or another? I have installed but only briefly experimented with the avr-gcc and supporting tools in Fink. Joerg's FreeBSD port has been very good under FreeBSD. -- David Kelly N4HHE, [EMAIL PROTECTED] Whom computers would destroy, they must first drive mad. ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] mac-avr
On Mon, Jul 09, 2007 at 03:34:37PM -0600, Eric Weddington wrote: If you are going to make a MacOS version of WinAVR then by golly you should sync to sources and patches identical to what Eric uses. That or use the FreeBSD avr port as your baseline. Joerg and Eric stay in close sync, sometimes Joerg leads as the FreeBSD port is updated more often than WinAVR. Although, right now I have more patches (bug fixes) in WinAVR. I now keep the patches I use in the WinAVR CVS. Yes, 6 of one, half-dozen of the other. My point was that it would be handiest to replicate all the bugs, features, and patches, of WinAVR. Bugs are unknown features. Once documented a bug becomes a feature. :-) There are at least two projects using the name MacAVR. Are you one of those or another? One goes by the name of OSXAVR and can be found on SourceForge (project name: osxavr). I highly suggest that you (Steven) join forces with that group instead of starting yet another project. That's a 3rd. Yet another in Fink, http://www.finkproject.org/. The Fink version of avr-gcc is 3.4.5 in the unstable branch. Nothing particularly wrong with 3.4.5, but it does suggest that the port isn't getting much attention. -- David Kelly N4HHE, [EMAIL PROTECTED] Whom computers would destroy, they must first drive mad. ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] avr-gcc won't compile (xgcc has bad cmdline option -march=i586)
On Tue, Sep 11, 2007 at 03:20:58PM -0700, Rory Galvin wrote: Hello avr-gcc list, Up until two days ago I was a bright-eyed enthusistic avr newbie. Unfortunately I have hit a brick wall and am desperately hoping that someone will be able to help. [...] I am running a spanking new install of vectorlinux 5.8 (std), which is Slackware 11 under the hood (This comes ready-rolled with gcc-3.4.6 and binutils 2.15.9), all on a toshiba tecra 8100 (P2). [...] I thought this would be ok. But when I try to make avr-gcc it fails when it hits xgcc (of _mulqi3.o): /home/root/shed/gcc-4.1.2/obj-avr/./gcc/xgcc Stop right there. You are trying to cross compile avr-gcc 4.1.2 with 3.4.6? Seems like that is begging for trouble. You know the easiest platform to run avr-gcc is Windows? Close second is FreeBSD. MacOS X and Linux run distant third. -- David Kelly N4HHE, [EMAIL PROTECTED] Whom computers would destroy, they must first drive mad. ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] avr-gcc won't compile (xgcc has bad cmdline option-march=i586)
On Sep 11, 2007, at 5:55 PM, Eric Weddington wrote: Stop right there. You are trying to cross compile avr-gcc 4.1.2 with 3.4.6? Seems like that is begging for trouble. Not really, actually. I do it all the time on MinGW. Just looked suspicious to me. Maybe Rory ought to build a native 4.1.2 for his Linux to see if it fails the same way? -- David Kelly N4HHE, [EMAIL PROTECTED] Whom computers would destroy, they must first drive mad. ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] avr-gcc won't compile (xgcc has bad cmdline option -march=i586)
On Sep 11, 2007, at 6:12 PM, Rory Galvin wrote: I didn't think I was making any reference to the old gcc. Doesn't avr-gcc build its own gcc? If not, what does the ./configure script message 'checking where to find the target gcc... just installed' mean? If I uninstalled gcc 3.4.6 just before building avr-gcc (4.1.2)...? I've a feeling that's not going to work. What I know of cross-compiling gcc dates back to reading the DDJ series of articles on the creation of 386BSD. That back in those days one often had to use whatever C compiler was available to build gcc, then attempted to use that gcc to build itself as the final test. Also so as to have a gcc compiled by gcc. -- David Kelly N4HHE, [EMAIL PROTECTED] Whom computers would destroy, they must first drive mad. ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] Problem with delay loop
On Sep 28, 2007, at 8:58 PM, Graham Davies wrote: David Kelly wrote: ... because it was volatile it *had* to be fetched and stored each time. Oh boy. That's a really interesting statement (to me anyway, but I have a volatile fetish). You're saying that having chosen to put the variable in memory, the compiler is obliged to fetch it prior to and store it after each increment. I can't disagree with that. But, does it explain the horrid code? Does the compiler *have* to put the variable in memory? I guess it doesn't really have to if it can assure that the variable has not been passed by address reference to another routine such as an interrupt. Thats pretty much the definition of volatile in the first place, that one is telling the compiler that it can be changed somewhere somehow outside of the compiler's control. It is declared as an automatic variable, right? That means that the compiler has complete freedom in deciding where to put it and a register is a perfectly good choice. The scope is local, so the variable can't be accessed outside the function. It could be passed to another function by address. It isn't static, so its value isn't preserved when execution leaves the function. Is there a body of opinion that the volatile modifier obliges the compiler to put a variable in memory? I'm just interested. If this is too off-topic, feel free to ignore me. Actually, feel free to ignore me at any time. I think there is room for other variations on volatile as much of what Graham says applies nicely in interrupt service routines. No need to treat most application volatile variables with kid gloves when interrupts are masked. Many variables mapped to a peripheral device needs volatile no matter what. Not for an ouput port, but an input port for sure, and hardware timers, etc. But not for my example software timer, at least not in the interrupt routine where it gets decremented: if( timer_serial_cmd ) timer_serial_cmd--; timer_serial_cmd above only needs to be volatile outside of the interrupt routine. It is a stretch to say that any code intended to cause a deliberate delay is horrible. The code provided in util/delay_basic.h is about as painless as anything can be, no matter that it is assembly in a C function wrapper. I wrote earlier, if an Output Compare is not being used elsewhere, they make excellent delay timers without tying up the CPU in a busy loop. My example tied the CPU up, but thats not the way I generally use them. Software timers implemented in my tick interrupt for longer events, OCR's for precise short periods, and more complex use of the OCR hardware for repetitive events such as PWM motor control. -- David Kelly N4HHE, [EMAIL PROTECTED] Whom computers would destroy, they must first drive mad. ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] Problem with delay loop
On Wed, Oct 03, 2007 at 12:23:46AM +0530, Royce Pereira wrote: Why then was the empty 'ret' function retained? I would think such a case would be the prime candidate for optimisation. The compiler should eliminate such a funtion, as well as all calls to that function. That would really make a difference in size/speed of the code. (Instead, the compiler destroys a perfectly good delay loop I've used for the last 2 years -yes, I'm still sore) So? Why did *you* change compilers if the old one did what you wanted? If it doesn't do what you want then its your choice whether to change your code to conform or to revert to the compiler that did what you want. So says one who still maintains a project using the same C compiler from 1994. *Always* archive the tools with your source code. Of course, there's no disputing that. But the delay loop is just an example, of how simple ,intuitive code can throw the compiler into a tizzy. I've used SDCC(for mcs51) where the compiler 'recognises' code patterns, and says Oh, I know what this is - it's a delay loop! - Let it pass.(for example). I've always maintained - good software is one that does what you *want* it to do, *not* what you tell it to do. ;) I'm always frightened when someone thinks they know better what I want than what I said. Even more frightened when someone claims *software* knows better. Avr-gcc *has* a delay loop that the compiler recognizes and leaves alone. You've been told about util/delay_basic.h yet you have written more email than the amount of code you would have to change to use it. -- David Kelly N4HHE, [EMAIL PROTECTED] Whom computers would destroy, they must first drive mad. ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] Warning message
On Tue, Oct 02, 2007 at 11:25:30PM -0700, Dave N6NZ wrote: #define CHK_1307 0x55 if(twi_read() != ~CHK_1307) ok= 0; // ^^ //The offending line. I believe what is going on is the C standard requires promotion to int, and that bites (bytes?) you :) The result of twi_read() and also the ~CHK_1307 get promoted to ints before comparison. So... 0x00xx from twi_read() is compared against -xFFAA, which is clearly always true. I think CHK_1307 is already an int but that it fits in uint8_t without loss of resolution so the compiler doesn't complain. When complimented it no longer fits so the compiler complains. I would recommend changing its definition: #define CHK_1307((uint8_t) 0x55) -- David Kelly N4HHE, [EMAIL PROTECTED] Whom computers would destroy, they must first drive mad. ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] stumped by my ATmega48 (again)
On Oct 4, 2007, at 11:25 PM, [EMAIL PROTECTED] wrote: Hi all, I thought I was getting the hang of this Atmel programming, but after dusting things off a bit, I'm stumped again. I have a demo program from Matthew MacClary at Oregon State that toggles all output pins every three seconds. Pin 15 is hooked up to an LED on my breadboard, and when I install his prebuilt .hex file, the LED lights right up and does its thing. But when I build the same source and then install my hex file, the LED never lights up. To try to isolate the problem, I reduced the main program to just this: DDRB = 0xff; DDRC = 0x7f; /* PORTC has only 7 pins */ DDRD = 0xff; PORTB = 0xff; PORTC = 0x7f; PORTD = 0xff; return 0; /* PATCH for testing! */ I believe this should set all output pins high. But again, when I build and install this, nothing; the LED doesn't light up. Then I tried setting all ports to 0x00, but that didn't work either. When you return the CPU goes thru a crash reset, or something like that, I haven't traced the code. Do something like this: ... PORTB = 0xff; PORTC = 0x7f; PORTD = 0xff; for( ;; ) ; return 0 Then again we've discussed the removal of empty loops to death. Make sure the compiler doesn't optimize out that empty loop. Possibly it recognizes it as infinite and leaves it alone. -- David Kelly N4HHE, [EMAIL PROTECTED] Whom computers would destroy, they must first drive mad. ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] OS X install
On Wed, Oct 17, 2007 at 09:06:39PM +0200, Francesco Sacchi wrote: Dave N6NZ ha scritto: OK, a FAQ, I know. I need to install the avr-gcc tool chain on a MacBook, OS X. Can someone please give me a pointer to the current best-known-method for getting the most up-to-date tool chain on a Mac? If you want also to take a look at my script: http://www.develer.com/oss/AvrToolchain Does not contain the latest versions because it is aligned with latest WinAVR version. You include the same patches and tweaks as WinAVR? Much the way Joerg's FreeBSD port and WinAVR stay in close sync? Several months ago I tried several MacOS X ports of avr-gcc but none supported ATmega 48 and/or 168 (forgot which, or both). I didn't have spare brain CPU cycles to push out other tasks and properly grok the gcc cross compiling process so... So I set up SVN properly over SSH between a remote FreeBSD machine, a local FreeBSD machine, local XP machine, and my Mac. Most composition was in BBEdit on Mac. File transfer/sync was via svn. Syntax error check compiles were via Terminal.app over ssh to one of the FreeBSD systems. ICE on XP with AVR Studio, WinAVR, and TortoiseSVN. -- David Kelly N4HHE, [EMAIL PROTECTED] Whom computers would destroy, they must first drive mad. ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] ATmega644 pin-change interrupts
On Thu, Nov 29, 2007 at 03:44:18PM +0100, Per-Tore Aasestrand wrote: Hi list, I am using an ATmega644 and is attempting to set up pin-change interrupts for ports PA4/PCINT4 PA5/PCINT5. I've used the following code. Apparently, no interrupts are coming. Any obvious faults? You need to enable to desired pins in PCMSKx. When in the interrupt handler, how should a decide what pin created the interrupt? I can't find a flag-bit that carries this information. I too have not found one. I snag a copy of the PINx and keep it in a static variable in my ISR() to compare for which pins changed. Something like this: current = PINA PCMSK0;// only the pins enabled xor = previous ^ current; // pins changed since last time ... previous = current; return; -- David Kelly N4HHE, [EMAIL PROTECTED] Whom computers would destroy, they must first drive mad. ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] Problem with timer0 overflow interrupt in c language..
On Fri, Dec 07, 2007 at 08:55:16AM +0200, Julius Luukko wrote: Or let the compiler handle reading from PIN and writing to PORT by using: PORTB ^= 0xff; The compiler won't read PINB using the above. In general on AVR when one reads PORTB one reads the output latchs, in other words the last value written. On other CPU's this same action may read the input buffers. AVR provids PIN ports for specifically reading the state of the external pins. Using -O1 the above exclusive-or-equals generates exactly the same code as the OP first wrote: PORTB = ~PORTB; 3ee: 85 b1 in r24, 0x05 ; 5 3f0: 80 95 com r24 3f2: 85 b9 out 0x05, r24 ; 5 PORTB ^= 0xff; 3f4: 85 b1 in r24, 0x05 ; 5 3f6: 80 95 com r24 3f8: 85 b9 out 0x05, r24 ; 5 -- David Kelly N4HHE, [EMAIL PROTECTED] Whom computers would destroy, they must first drive mad. ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] Problem with timer0 overflow interrupt in clanguage..
On Mon, Dec 10, 2007 at 12:51:31PM +0100, Schwichtenberg, Knut wrote: On Friday, December 07, 2007 5:24 PM, David Kelly wrote: The compiler won't read PINB using the above. In general on AVR when one reads PORTB one reads the output latchs, in other words the last value written. On other CPU's this same action may read the input buffers. AVR provids PIN ports for specifically reading the state of the external pins. Using -O1 the above exclusive-or-equals generates exactly the same code as the OP first wrote: PORTB = ~PORTB; 3ee: 85 b1 in r24, 0x05 ; 5 3f0: 80 95 com r24 3f2: 85 b9 out 0x05, r24 ; 5 PORTB ^= 0xff; 3f4: 85 b1 in r24, 0x05 ; 5 3f6: 80 95 com r24 3f8: 85 b9 out 0x05, r24 ; 5 This result is unambiguous. The question is: Is this a bug which means a bug report is necessary or is it a feature that needs to be described? It would be comfortable if GCC could distinguish between the IO-ports and other IO-variables were the in and out address are identical. I don't think there is anything wrong. Is perfectly legal to read PORTB. Would be completely wrong for the compiler to read PINB for either of the above situations when its told to use PORTB. If one wanted PINB then write PORTB = ~PINB. My original point was that one should use care and think about these things because on some MCU architectures (and maybe some variants of AVR) one reads input values from the same place one writes new outputs. That reading reads the state on the pin which may be forced externally to a different value than one wrote, so code as shown above would never toggle a pin that was shorted or pulled hard high, it would always try to drive it the other way. The OP was not seeing his LED flash. If an LED loaded the circuit too much the MCU would not have seen valid logic levels on PINB. -- David Kelly N4HHE, [EMAIL PROTECTED] Whom computers would destroy, they must first drive mad. ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] invalid ram address
On Thu, Dec 13, 2007 at 03:36:56PM +0700, andi wrote: Hi , I make a program for atmega32, and i compile it using WinAVR version 20070525. But when i want to simulate in AVRStudio, the variables that i declare are invalid location. I check the SRAM address and in outside the maximum address (example : 0xA64) Is it a bug ? Or maybe I have to configure something ? Yes its a bug in your software. The ATmega32 has 2k of RAM, 0x0800 bytes. Starts at 0x0060 and ends with $0x085f. 0x0a64 is way out of range. -- David Kelly N4HHE, [EMAIL PROTECTED] Whom computers would destroy, they must first drive mad. ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] Howto put constants on fixed address
On Wed, Dec 19, 2007 at 06:07:19PM +0100, [EMAIL PROTECTED] wrote: Well, perhaps I've written something wrong, because I think that you are talking about something else. Or I did not understand that, that is also possible :-). I need to put my constants on specific address into flash memory, not into sram. I want to have the resulting flash content like this: -03FFsome part of .text section (including vectors and so on) 0400-041Fmy .foo section 0420-end the rest of .text section I have done this in Introl-C11 where I had external memory mapped I/O registers. I had to manually massage the linker editor script file. For avr-gcc this will be in /usr/local/avr/lib/ldscripts/ (or similar in WinAVR). But you don't want to edit those but to copy one into your project and figure out how to override the default with your own. Due to the memory map I had I/O in the midst of my EPROM space. Once I got the Introl linker working the way I wanted it nicely split my object code around the I/O sections. One must question the need to map constants to a predetermined location in FLASH? -- David Kelly N4HHE, [EMAIL PROTECTED] Whom computers would destroy, they must first drive mad. ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] Howto put constants on fixed address
On Dec 19, 2007, at 5:03 PM, Martin Žižka wrote: Yes, that will place the .length segment between .vectors and .progmem. But you are unable to place it to some exact address. That will place it to address that is offset_of(.vectors)+length_of(.vectors). That can be different for some cpus. I think this URL describes the syntax to do what Martin is looking to do: http://www.gnu.org/software/binutils/manual/ld-2.9.1/html_node/ld_21.html#SEC21 More hints here, in that one can edit the . address: http://www.gnu.org/software/binutils/manual/ld-2.9.1/html_node/ld_10.html -- David Kelly N4HHE, [EMAIL PROTECTED] Whom computers would destroy, they must first drive mad. ___ 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
On Dec 28, 2007, at 11:00 AM, Jan Menzel wrote: Hi Alex! I'd suggest to take larrys approach and generate the start bit from within the ISR. For precise timings you might add the bit time to the current OCR value (insight the ISR). Using this schema you can have an arbitrary (but constant) phase difference between the interrupt and the time of changing the tx-pin. To start a transmission I'd just set the OCR to TIMER + x where x shall be set such that the ISR is called as fast as you like the transmission to start. That works so long as your interrupt doesn't have to wait on another before it runs. I recently had a problem where I used one interrupt to service an A/D converter and another for management of the A/D. The A/D responded much faster than I expected and these two interrupts overlapped. Most of the time that was fine but when a 3rd interrupt was running the A/D interrupts queued and were processed in priority order which was reverse of arrival times. Thankfully it was repeatable and occurred at least once every 10 seconds. If your timing accuracy doesn't mind pseudorandom latencies then manually driving output bits from interrupt is fine. If its picky then connect the OCR timer to its output bit and let the hardware do it. -- David Kelly N4HHE, [EMAIL PROTECTED] Whom computers would destroy, they must first drive mad. ___ 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
On Wed, Jan 02, 2008 at 10:59:05AM -0500, Mark Litwack wrote: One other way to approach this without having to deal with the fixed latency of the Tx ISR and any other interfering ISRs is to use the Compare Match Output bit on the timer as the Tx bit. It's close to what you're doing, but using the output bit allows the counter hardware to autonomously land the Tx bit in exactly the right position. The code is a little tricky, but the basic strategy is to repeatedly set up the OCR and COM registers so that the output pin gets set to 0 or 1 at the *next* bit time. In addition to setting the Tx pin, at each next bit time a Tx ISR is called to set up the OCR and COM registers again for the next bit. The OCR is loaded with OCR + BIT_TIME, and the COM is set up to clear or set the output bit (Tx) depending on the next Tx bit value. There is a mode where one only writes the BIT_TIME in the OCRx register once and the paired timer resets to 0 with the output bit change. So all you have to do in the ISR is to decide which output value is to be sent next. The transmitted timing will be as precise as your timer. -- David Kelly N4HHE, [EMAIL PROTECTED] Whom computers would destroy, they must first drive mad. ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] stumped: minor refactoring of simple program causes it to fail
On Thu, Jan 03, 2008 at 08:02:14AM -0700, [EMAIL PROTECTED] wrote: OK, once again I am an idiot. I stared right at this for hours and somehow didn't see it. My makefile had the -mmcu flag set to atmega168, but this chip is an ATmega48. This apparently can cause all sorts of weird behavior, like some code working fine while other, very similar code, locks up. After correcting the mmcu, things appear to work much better! I threw your code at avr-gcc last night and it looked reasonable to me but decided I was too sleepy to judge, and too sleepy to form a proper reply. I'm a big advocate of adding this rule to your Makefile: # # This is a fun conversion, creates an assembly dump # including C source lines interspersed as comments. # .elf.list: avr-objdump -DS $ $@ Then in your all: target do something like this: all:object.elf object.list It was the .list file I was looking at last night that looked reasonable. -- David Kelly N4HHE, [EMAIL PROTECTED] Whom computers would destroy, they must first drive mad. ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] Where/how to get latest stable version?
On Jan 5, 2008, at 12:44 AM, dlc wrote: I just pulled in and built avrdude, but my avr-gcc toolchain is years out of date. Can some kind soul tell me where to get a Max OS X distro, or lacking that, how I can pull in the requisite projects to build them? What I have works fine for me, but I'm looking at some new parts... There are/were older ports in fink and darwin-ports. You could start with one of those. I would recommend closely following Joerg's FreeBSD port as it and WinAVR march pretty much march in lockstep as the state-of-the-art avr-gcc. -- David Kelly N4HHE, [EMAIL PROTECTED] Whom computers would destroy, they must first drive mad. ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] Tip: handling volatile operands
On Thu, Jan 10, 2008 at 02:24:46PM -0500, [EMAIL PROTECTED] wrote:
I have come across a few instances where very inefficient c code is
created by volatile operands - often accidentally and thru no fault of
the compiler(s)
...
For example:
while (ioport != 0)
{
}
...
If ioport were a normal variable, there would be one read and one
test!
So, if you don't want the absolute latest value of a volatile, use a
temporary!
unsigned char a = ioport;
if ((a 1) || (a 2) || (a 0x0c))
{
}
Will produce much better code!
You changed horses in the middle of the stream. Replace if above with
while that you started with and your non-volatile may loop forever
based on one read.
The solution is to roll your conditions into one test:
while( ioport ( 1 | 2 | 0x0c ) )
{
}
--
David Kelly N4HHE, [EMAIL PROTECTED]
Whom computers would destroy, they must first drive mad.
___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] I need some help I am trying to use interrupts but...sigh!!
On Mon, Mar 17, 2008 at 09:28:47PM -0700, atifplus wrote: so as long as my move variable is 1 2 3 or 4 the interrupt should keep sending pulse accordingly but i am not getting anything on portB PORTB |= (0 PB3)|(0 PB4); Do you really believe you can OR a 0 into bit locations PB3 and PB4? This is what I think you intended: PORTB = ~( (1PB3) | (1PB4) ); -- David Kelly N4HHE, [EMAIL PROTECTED] Whom computers would destroy, they must first drive mad. ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] memcpy
On Mar 29, 2008, at 4:58 AM, Wynand Weyers wrote: How do I get memcpy not to compile inline? Write your own? Its not that hard. Or make a copy of the existing memcpy() in your project and remove the inline directive? Looking at avr-libc-1.6.1/libc/string/memcpy.S I don't understand your question. memcpy() isn't an inline function, its a called function like most everything else. -- David Kelly N4HHE, [EMAIL PROTECTED] Whom computers would destroy, they must first drive mad. ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] AVR-Gcc and overflow behavior
On Mon, Apr 14, 2008 at 05:33:13PM -0300, Jonathan Blanchard wrote: I was reading thought a recent discussion in the GCC dev list and also the following blog : www.airs.com/blog/archives/120 ; I'm now curious about how the avr port of gcc behave in front of overflows. Does it assume by default that overflow never occur? The nature of embedded programming says that if one is coding on the edge and expecting a particular behavior out of one's tools then one had better code tests to ensure the tool operates as expected. *THEN* document it in comments buried in the source. IMO signed variables are used way too much. I always use unsigned except in special cases where signed is needed. The norm (at least outside of the embedded world) is to use signed for everything but for the special cases where unsigned is uniquely appropriate. I use #include stdint.h for all my type definitions. This way there is no question as to the size or signedness of a char when its uint8_t. -- David Kelly N4HHE, [EMAIL PROTECTED] Whom computers would destroy, they must first drive mad. ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
[avr-gcc-list] Default location for .indent.pro in WinAVR?
One option is to set the environment variable INDENT_PROFILE to the location of one's default .indent.pro for GNU Indent, but I'd like to know where the program searches by default? It doesn't seem to be: C:\Documents and Settings\dkelly -- David Kelly N4HHE, [EMAIL PROTECTED] Whom computers would destroy, they must first drive mad. ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] OS X 4.2.2 -- simplest way today?
On Thu, May 08, 2008 at 10:23:34AM -0600, Dennis Clark wrote: Why don't you both just use AVRMacPack? I didn't even KNOW about MacPack! Ditto. The site talks about using it with XCode, I use Eclipse, that shouldn't affect anything will it? I'll have to read up on this site, anywhere I can find where someone has handled the details, especially if that includes being able to use the debugger would be a major time saver! The site (and the installer) also says, Does not depend on Xcode for building AVR code. Nice touch in including both 3.4.6 and 4.2.2. Default is 3.4.6, but avr-gcc-select is a script that will change the default. Would like to see the build tools included. Brief look I don't see any source code in the package or available at the site to download. -- David Kelly N4HHE, [EMAIL PROTECTED] Whom computers would destroy, they must first drive mad. ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] OS X 4.2.2 -- simplest way today?
On May 8, 2008, at 9:09 PM, Rick Mann wrote: On May 8, 2008, at 16:09:10, Dennis Clark wrote: I do wonder about the tool chain though - Is that not in the package? That is as much a hassle as the compiler to build. I've not looked, does this include the libs as well as the compiler? They tend to be related. I don't think it would've built my project without the rest of it. I'm sure it's all there. No kidding. Just read the original URL, repeated here: http://www.obdev.at/products/avrmacpack/download.html At the bottom of the page it says, Version 2007-11-26 This is the initial release. It contains the following software packages: • gcc 3.4.6 • gcc 4.2.2 • GNU binutils 2.18 • avr-libc 1.4.7 • avrdude 5.5 • libusb 0.1.12 • gdb 6.5 • avarice 2.7 • simulavr 0.1.2.2 • GNU make 3.81 There are 4 release versions shown. Most significant was the latest with avr-libc 1.6.1. Look around a bit on the site and see some familiar Mac utilities. And their other AVR thing, a software-only USB library for AVR. Guessing its bundled above as libusb 0.1.12. http://www.obdev.at/products/avrusb/index.html -- David Kelly N4HHE, [EMAIL PROTECTED] Whom computers would destroy, they must first drive mad. ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] __checksum
On Thu, May 29, 2008 at 09:48:08AM -0700, trile58 wrote: I have been successfully porting the old code from IAR to AVR GCC except for the followings: extern flash unsigned short __checksum; CRC_SUM = 0; /* Clear CRC-Check of Program Memory (Flash) */ /* Checksum of Program memory (IAR-Example) */ CRC_SUM = slow_crc16(CRC_SUM,(unsigned char flash *)0,(unsigned long)__checksum); CRC_SUM = slow_crc16(CRC_SUM,(unsigned char flash *)zero,sizeof(zero)); /* call with two 0 bytes for the correct calculation of crc */ I had flash changed to PROGMEM as instructed in the porting document. However, I got an error undefined reference to __checksum . From Porting from IAR to AVR GCC document, it does not list __checksum is one of the thing need to be ported. I wonder how this __checksum gets created and where it is located. Please advice. Am guessing you are trying to verify FLASH program content. What I find online of IAR's slow_crc16() is that the last argument is the number of bytes starting at the 2nd argument. Your code above is making an assumption that it is to CRC everything from and including address 0x to but not including a memory location containing __checksum. Avg-gcc isn't going to make or fill a variable named __checksum unless you do it yourself. -- David Kelly N4HHE, [EMAIL PROTECTED] Whom computers would destroy, they must first drive mad. ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] __checksum
On Thu, May 29, 2008 at 11:25:01AM -0600, Blake Leverett wrote: On Thursday 29 May 2008, trile58 wrote: I had flash changed to PROGMEM as instructed in the porting document. However, I got an error undefined reference to __checksum . It looks like the problem is the flash keyword. Avr-gcc handles flash differently from IAR - so more is needed than just a keyword change. The __checksum name is just a variable name, so I think that the flash keyword is where the compiler is losing track. Yes, but an undefined reference says that *nothing* is known about __checksum. Would seem IAR automatically buries a __checksum in the code image but avr-gcc does not. Be sure you are including avr/pgmspace.h, and you may want to place the PROGMEM keyword later in the line: extern unsigned short PROGMEM __checksum; But somewhere one has to allocate this variable and somehow put something in it. Also, in the slow_crc16() function, make sure that you call pgm_read_byte() or pgm_read_word() as necessary. You cannot simply say uint16_t a = __checksum; you have to use uint16_t a = pgm_read_word(__checksum); Or something like that. Not only that but if the intent is to CRC the FLASH contents then slow_crc16() needs to be coded accordingly. Is my understanding that slow_crc16() is a standard IAR library function. -- David Kelly N4HHE, [EMAIL PROTECTED] Whom computers would destroy, they must first drive mad. ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] how to unsubscribe?
On Wed, Jul 02, 2008 at 07:30:15AM -0700, Mohammad wrote: please tell me how to unsubscribe from maling list. Instructions are included in the email headers for email clients that recognize List-unsubscribe: header. Hint: mailto:[EMAIL PROTECTED] And of course the footer appeneded to each message has a link to the instructions: ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list -- David Kelly N4HHE, [EMAIL PROTECTED] Whom computers would destroy, they must first drive mad. ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] 24 bit Integer
On Mon, Jul 14, 2008 at 08:39:50AM -0600, Weddington, Eric wrote:
I was just wondering whether it's theoretically possible to use a
24bit Integer, and whether there is certain reason why 24bit aren't
supported.
A 24-bit integer is not supported by the C language. In theory,
support could be added to GCC, but then it would be considered an
extension to the C language. And it would also be difficult and/or
time-consuming to add to GCC.
But personally, I would like to see support added for 24-bit integer
types as the AVR port could really use 24-bit pointers for larger
devices (ATmega256x, avr6 architecture).
CodeWarrior for the 68HC12 uses 24 bit *far pointers. Perhaps gcc for
HC12 does too? One of the funky things about *far in HC12 is that the
bytes are not in the same order as one might expect if promoted to 32
bits.
If one absolutely had to have 24 bit integers one could construct a 3
byte struct, or probably better yet a union of several structs. Would
have to handle the math separately.
typedef union {
uint8_t a[3]; // array
struct {
uint16_tab;
uint8_t c;
} big_little;
struct {
uint8_t a;
uint16_tbc;
} little_big;
struct {
uint8_t a, b, c;
} byte;
} MY24BITS;
--
David Kelly N4HHE, [EMAIL PROTECTED]
Whom computers would destroy, they must first drive mad.
___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] Strange issues with 16-bit values
On Tue, Nov 11, 2008 at 12:30:10PM -0500, Brian Neltner wrote: I compiled with -Wall and minus a few unused variables there are no warnings. Although I'm not sure how it could cause the problem, I am curious why it would be doing 32 bit calculations in the polling. I do this: while(TCNT3(uint16_t)benc_period*224UL/255); where benc_period is a #define, so it should be cast as a 16-bit unsigned integer. Do I need to take manual action to tell it to do 16-bit comparison? You use 224UL in your expression and wonder why the comparison is promoted to 32 bits? The comparison is always the size of the biggest and your cast only sticks to the first item. If you want to force it down to a 16 bit comparison you need to force everything down to 16 bits: while(TCNT3(uint16_t)( benc_period*224UL/255) ); But I think it would be best written like this to enforce the desired evaluation order: while( TCNT3 (uint16_t)( (benc_period*224UL) /255) ) ; The above because I would be concerned the compiler might rearrange the order and precalculate 224UL/255. Always better safe than sorry. On empty while() loops I like to put the semicolon on a separate line so that the emptiness stands out. -- David Kelly N4HHE, [EMAIL PROTECTED] Whom computers would destroy, they must first drive mad. ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] RE: 16 bit Timer Issue
On Mon, Jan 05, 2009 at 11:50:53PM +0100, Stefan Wimmer wrote: prabu pr...@cet.be wrote: My intention is I have to generate 1 sec periodic delay. AT every one sec the portc PC6 will be toggled .. ...but not with this line: PORTC = ~(1PC6); But as Eric already mentionend: this is a mailinglist about AVR-GCC. You should ask at AVRfreaks or the AVR-chat ML at yahoogroups. On a note half way between here and there, the above is a good example of what one could do with a commented disassembly. Is not perfect but the avr tools can disassemble and comment an object file as a target in the Makefile. Often all that is needed is a glance at that file's contents to realize the code is not going to do what one expected. Also good for tuning one's C coding style for maximum avr-gcc performance. -- David Kelly N4HHE, dke...@hiwaay.net Whom computers would destroy, they must first drive mad. ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] About context saving in Vectors
On Wed, Jan 14, 2009 at 09:14:20AM -0700, dlc wrote: The solution is to NOT call functions from within your ISR. That is just evil. Get your data in the ISR, put it in a mailbox or buffer and have a regularly scheduled function handle the details from outside the ISR. I like to use ring buffers to store data from an ISR. When using the ring buffer the ISR modifies the write pointer, not the read pointer and the processing function outside the ISR modifies the read pointer and not the write pointer. This means that those pointers don't need push/popped in the ISR either. Pointers, or indexes? Don't quite understand the push/popped reference, but if a variable is accessed in both interrupt space and user space it needs to be protected so that its uses atomically. When reading a ring buffer from outside the interrupt one generally compares the head index to the tail index to know if there is data in the buffer. An atom in an AVR is 8 bits so if one uses 8 bit indexes then no special care is needed. But if 16 bit pointer that may span multiple 256 byte pages one must block the interrupt before reading the variable that the interrupt might modify. But this is something warranting further study of your specific code. If instructions are used that read the whole 16 bits without possibility of an interrupt between the bytes then no protection is necessary. -- David Kelly N4HHE, dke...@hiwaay.net Whom computers would destroy, they must first drive mad. ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] About context saving in Vectors
On Wed, Jan 14, 2009 at 10:02:48AM -0700, Stu Bell wrote:
Don't quite understand the push/popped reference, but if a variable
is accessed in both interrupt space and user space it needs to be
protected so that its uses atomically.
Which is why there is the util/atomic.h macros. Check out:
ATOMIC_BLOCK( ATOMIC_RESTORESTATE )
{
... Mangle pointers
}
Interesting. Don't recall those being there 3 or 4 years ago back in the
days of avr-gcc 3.3 and 3.4.
--
David Kelly N4HHE, dke...@hiwaay.net
Whom computers would destroy, they must first drive mad.
___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] About context saving in Vectors
On Wed, Jan 14, 2009 at 01:41:33PM -0700, dlc wrote: I guess that we agree. :) My biggest problem was getting variables established that gcc wouldn't try to save when the ISR started. I've tried REGISTER, but I couldn't guarantee that the register I'd fixed an index to was really not being used elsewhere, I had one instance where it clearly was corrupted elsewhere, even if it was in the list of registers that various docs say are available. I don't think gcc is trying to save any variables on entry to an ISR. What gcc does on entry to an ISR is save certain registers that it will use within that function to hold autos and temporary scratch values. It has to push those on the stack at entry and pull on exit because the interrupted routine expects them to be the way it last used them. So the ISR isn't initializing its variables, its making space for them. Can declare your variables as static within the ISR to keep them from being allocated in CPU registers or on the stack. But no matter what, some register space is needed for any non-trivial ISR. -- David Kelly N4HHE, dke...@hiwaay.net Whom computers would destroy, they must first drive mad. ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] About context saving in Vectors
On Jan 14, 2009, at 5:58 PM, Daniel O'Connor wrote:
On Thursday 15 January 2009 04:15:14 Dave Hylands wrote:
And here's some code that implements such a ring buffer. As David
Kelly points out, as long as the index type is uint8_t, then nothing
special is required (which for this particular implementation means
that buffers upto 128 entries would be supported)
http://websvn.hylands.org/filedetails.php?repname=Projectspath=%2Fcommon%2FCBUF.hrev=0sc=0
It's important that the queue be declared volatile (as myQ is in the
sample).
And I was just about to ask if someone could post some well tested
code! :)
You will notice Dave Hyland's code is C++.
This is how I did it recently for an AVR usart in plain C. Notice I
wrapped the indexes using a bitwise AND. That isn't always as
efficient as it might seem.
The indexes are named hd and tl, head and tail, as in food goes in
the head and comes out the tail.
None of these funtions loop, so the indexes do not need to be declared
volatile.
struct {
uint8_thd, tl;
uint8_t buf[(14)];// (14) is 16, must be power of
two for wrap
} incoming;
struct {
uint8_t hd, tl;
uint8_t buf[(16)];// (16) is 64, must be power of
two for wrap
} outgoing;
//
// Incoming character
//
ISR(USART0_RX_vect)
{
if ( UCSR0A ((1FE0)|(1DOR0)|(1UPE0)) ) {//
if error
UDR0; //
discard
} else {
incoming.buf[incoming.hd] = UDR0; //
reading clears IRQ
incoming.hd = (incoming.hd + 1)
(sizeof(incoming.buf)-1);
}
}
//
// Transmit complete, ready for another.
// USART0_TX_vect says all the buffers are empty, which we don't
care.
// USART0_UDRE_vect tells us when its ready to send another.
//
ISR(USART0_UDRE_vect)
{
if( outgoing.hd == outgoing.tl ) {
UCSR0B = ~(1UDRIE0); // disable this IRQ
} else {
UDR0 = outgoing.buf[outgoing.tl++];
outgoing.tl = ~(sizeof(outgoing.buf));
if( outgoing.hd == outgoing.tl )//
anticipate followup IRQ that just disables
UCSR0B = ~(1UDRIE0); // disable
this IRQ
}
}
//
// Return a character from incoming buffer, or -1 for empty
//
int
my_getchar(void)
{
int c;
if( incoming.hd == incoming.tl )
return(-1);
c = (unsigned)incoming.buf[incoming.tl];
incoming.tl = (incoming.tl + 1) 0x0f; // increment
and wrap
return(c);
}
//
// Put character in outgoing buffer. Enable UDRIE0 if not already.
//
// Calling routines may disable IRQ so as to prevent the data
// they are sending from changing before its sent, so we have to
// preserve the interrupt bit in SREG.
//
// UDRE0 should be set whenever there is space in the TX buffer
for more.
// Setting UDRIE0 should trigger USART0_UDRE_vect immediately.
//
// No protection provided against over filling the buffers.
//
void
my_putchar(uint8_t c)
{
uint8_t sreg;
sreg = SREG;// save IRQ status, costs almost nothing
cli(); // don't want illegal outgoing.hd during an
IRQ
// Put it in the queue/buffer
outgoing.buf[outgoing.hd++] = c;
outgoing.hd = ~(sizeof(outgoing.buf)); // make it
legal
// UDR0 is double-buffered so 2 characters can be handled
instantly
// leaving IRQ disabled which would force this data to split
across hops.
if( radio_hop 3 ) // (re)start now if this is
a clean hop
UCSR0B |= (1UDRIE0); // enable USART0_UDRE_vect
SREG = sreg;// restore prior IRQ enable/disable
}
//
// Rather than put the outgoing struct in externally visible space,
// provide a routine to compare head and tail.
// Then expand it with many other conditions. :-(
//
uint8_t
usart_tx_empty(void)
{
return((outgoing.hd == outgoing.tl) // buffer is
empty
((RF_CTS_I (1RF_CTS_B)) == 0)// radio is
not asking us to stop
);
}
--
David Kelly N4HHE, dke...@hiwaay.net
Whom computers would destroy, they must first drive mad.
___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] Re: Strings: escape sequence to insert arbitrary hex value ?
On Thu, Feb 05, 2009 at 07:13:18PM +0100, Vincent Trouilliez wrote: ISO C99, section 6.4.4.4, p3: the question-mark ?, [..] is representable according to the following table of escape sequences: question mark? \? Interesting. I wonder why the standard deeemd it necessary to provide an escape sequence for the question mark ? I do happen to have question marks in my strings, but didn't know about the escape sequence so didn't use it, yet the compiler didn't complain, and simply put the question mark ASCII code in the string, as I expected. I understand they phrased it to mean a possibility, not an obligation, but why provide it if they didn't think there were at least one use case where it would be mandatory ? Haven't gone back to the referenced text but perhaps the ? was intended as wildcard character indicating that any character can be escaped as itself when in doubt? -- David Kelly N4HHE, dke...@hiwaay.net Whom computers would destroy, they must first drive mad. ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] memcpy() : problem when passing destination pointer
On Wed, Feb 11, 2009 at 07:06:22PM +0100, Bernard Fouch? wrote: However it may not be perfect, if ever the system has other ISR routines that allow the MilliSeconds counter to progress but forbid getMs() to run between reading 'a' and 'b' for more than 255 ms! Well, not more than but interrupt getMs() for some multiple of 256 ms with a window of about 1 ms. -- David Kelly N4HHE, dke...@hiwaay.net Whom computers would destroy, they must first drive mad. ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] How to force GCC to not to remove nop statements ?
On Thu, Feb 19, 2009 at 11:14:40AM -0700, Weddington, Eric wrote: If you are using WinAVR 20081205 then you can use one of the new builtin functions: void __builtin_avr_delay_cycles(unsigned long __n); The prototype can be found in avr/builtins.h, but you shouldn't need the prototype to call it. Hey Joerg, you must be busy! FreeBSD's avr-gcc used to track WinAVR closer than this. :-) -- David Kelly N4HHE, dke...@hiwaay.net Whom computers would destroy, they must first drive mad. ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] How to force GCC to not to remove nop statements?
On Thu, Feb 19, 2009 at 12:46:50PM -0700, Weddington, Eric wrote: Hey Joerg, you must be busy! FreeBSD's avr-gcc used to track WinAVR closer than this. :-) He has been busy. He's been working on support for the new ATmega128RFA1 device, which has been added recently to the toolchain. Joerg will be including all of the WinAVR patches in his next update of the avr toolchain in FreeBSD Ports. Joerg and I are working closely on the next release. There's been a lot of activity recently on avr-libc and avrdude, with releases of both coming up very soon. Thought I ought to reply to make sure its clear that I'm not complaining and very much appreciate the work Eric and Joerg are doing and have done for avr-gcc. Related to another thread: as to why *not* to use an 8051: Doesn't have avr-gcc. -- David Kelly N4HHE, dke...@hiwaay.net Whom computers would destroy, they must first drive mad. ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] Preferred ICE (was: How to force GCC to not to remove nop statements?)
On Feb 19, 2009, at 9:44 PM, Graham Davies wrote: David Kelly wrote: I have a Microchip 1000 or 2000 ICE thingy that cost about $2000 and was used for one project. Given a choice I much prefer the ECROS ICE Cube, avr-gcc, and of course an AVR. Could I possibly quote that on the User Testimonials page, please? Yes you may. But rather than call it a Microchip 1000 or 2000 ICE thingy I checked the closet and its an MPLAB ICE-2000. And appears the current price is $1000 but requires external pods or personality modules. Its significantly more capable than AVR JTAG as its a full emulator that replaces the target MCU. Its just that the software (back then) resembled Windows 3.0 and DOS. And turned out some of its instruction execution times were not the same as a stand alone chip. Microchip has/had a ICD which is similar to Freescale BDM and AVD DebugWire but consumed some program space. But the ICD executed all code with proper timing as it was an enhanced monitor program. As I remember in the end I had to use a mix of the two Microchip development tools to get the job done. -- David Kelly N4HHE, dke...@hiwaay.net Whom computers would destroy, they must first drive mad. ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] How to force GCC to not to remove nop statements?
On Fri, Feb 20, 2009 at 08:00:00AM +0100, Joerg Wunsch wrote: David Kelly dke...@hiwaay.net wrote: Strangely the JTAGICE mkII didn't work on the above hardware where the ICE Cube did. I put a small 50 mA or maybe 100 mA linear regulator on the 3.3V supply and the mkII drew more power off the target than the regulator would provide. The JTAG ICE mkII cannot be powered from the target circuitry. It needs either a separate power supply, or can be powered directly from USB. Whatever, it didn't work on my circuit but worked on a purchased ATmega128 board. But the ICE Cube did work. I believe the company is currently using mkII's to support it. -- David Kelly N4HHE, dke...@hiwaay.net Whom computers would destroy, they must first drive mad. ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] Re: sprintf
On Fri, Feb 27, 2009 at 10:37:30PM +0100, Vincent Trouilliez wrote:
On Fri, 27 Feb 2009 22:10:16 +0100
David Brown david.br...@hesbynett.no wrote:
sprintf((A_String + i), %c, 0xff)
has exactly the same effect as:
A_String[i] = 0xff;
A_String[i + 1] = 0x00;
delay_about_1000_processor_cycles();
waste_about_2000_bytes_of_code_space();
ROTF ! :-
sprintf() only costs 2kB? Sure enough, this little program is 2132 bytes
after strip:
#include stdio.h
main()
{
char tmp[100];
sprintf( tmp, %d, 10 );
}
--
David Kelly N4HHE, dke...@hiwaay.net
Whom computers would destroy, they must first drive mad.
___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] Using delay functions with variable F_CPU clock?
On Wed, Mar 04, 2009 at 04:37:22PM -0500, David VanHorn wrote:
F_CPU is always evaluated upon each invocation, so if you ever
change it within one compilation unit, the next invocation of one of
these macros will reflect this.
That's compile-time, he's looking for execution-time changes in
processor speed.
He didn't explicitly say so, but I think he's using xdiv to scale the
CPU clock.
But doesn't say clock is infinitely variable. Most likely there are two
frequencies he's running but this is expandable:
if( frequency == LOW_KHZ ) {
#define SAVED_F_CPU F_CPU
#undef F_CPU
#define F_CPU LOW_KHZ
_delay_us(us);
#undef F_CPU
#define F_CPU SAVED_F_CPU
#undef SAVED_F_CPU
} else {
do_delay(us);
}
--
David Kelly N4HHE, dke...@hiwaay.net
Whom computers would destroy, they must first drive mad.
___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] Passing a string variable to lcd_puts
On Fri, Mar 27, 2009 at 04:06:21PM -0400, David VanHorn wrote: In C there are 3 char types. char signed char unsigned char so maybe char isn't signed? Ok, so that leaves me VERY confused.. As you should be. Plain old char *is* either signed or unsigned depending on your choice of compiler. And in effort to build code that runs as expected better compilers have a compile time switch to control code generation when the signedness is specifically indicated. See -funsigned-char, -fsigned-char, and -fno-unsigned-char in the avr-gcc man page. So in short plain old char is only being sloppy in not explicitly stating signed or unsigned. -- David Kelly N4HHE, dke...@hiwaay.net Whom computers would destroy, they must first drive mad. ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] Passing a string variable to lcd_puts
On Fri, Mar 27, 2009 at 04:21:15PM -0400, David VanHorn wrote: As you should be. Plain old char *is* either signed or unsigned depending on your choice of compiler. And in effort to build code that runs as expected better compilers have a compile time switch to control code generation when the signedness is specifically indicated. Ok, that's one of the reasons that I'm using the new types, but I still don't understand why I'm getting the signage warning when I use uint8_t or int8_t to feed chars to lcd_puts. Is int8_t not signed? Yes, int8_t is signed. Is defined in stdint.h as: typedef signed char int8_t; and uint8_t is: typedef unsigned char uint8_t; And why does lcd_puts want signed chars anyway? Isn't negative A nonsense? I think its nonsense, but the origins of convention date way back and might have something to do with the original practice of using signed int for everything. A value might move in and out of signed char out and in to signed int easier than for an unsigned char. Am not familiar with lcd_puts(). Have always written my own LCD code. Somethings are easier to write than to understand what someone else did. Meanwhile the point about -funsigned-char and family was a hint to look into what you are currently running and what was used when lcd_puts() was compiled. Sad, but current project is using Visual Studio 2008 Express where the C compiler has also thrown complaints for mixing signs. And for precision loss when stuffing 32 bits into 8. Generates exactly the same code without complaining if I write u8 = ( u32 0xff ); -- David Kelly N4HHE, dke...@hiwaay.net Whom computers would destroy, they must first drive mad. ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] main function registers push/pop
On Wed, Apr 15, 2009 at 12:22:25AM +0800, Kang Tin LAI wrote: My main function never return, I want to eliminate registers push/pop in main function. I read the list archives, found: OS_main - gcc 4.3.3 not implement OS_task - gcc 4.3.3 OK but interrupt not guarantee disable -mtiny-stack - not for what I wanted. Isn't this part of what -ffreestanding does? -- David Kelly N4HHE, dke...@hiwaay.net Whom computers would destroy, they must first drive mad. ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] Timer0 interrupt on Mega128
On Wed, Apr 22, 2009 at 11:35:53AM +0200, Jan Menzel wrote: Many thanks your suggestion. Unfortunately using a different device is not possible because the hardware has already been build. Finally I solved the problem by not dividing the clock anymore (initially a slow SPI device required a slow system clock but thats now operated by hand anyhow). Thanks again! If the SPI device is that slow then it might as well be handled in software. Perhaps that is what operated by hand means? -- David Kelly N4HHE, dke...@hiwaay.net Whom computers would destroy, they must first drive mad. ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] External EEPROM verses internal EEPROM data handling
On Mon, May 04, 2009 at 10:21:50PM +0930, Daniel O'Connor wrote:
On Mon, 4 May 2009, Bob Paddock wrote:
? ? ? ? ? ? ? ?uint16_t voltage[24]; ? // adc counts of 24 channels
in an array } ED; ? ? ? ? ? // total data = 58 bytes
Because of issues of structure packing it is better to define
structure items from the largest to the smallest, ie. uint16_t
should be first. This is more important on 32bit processors and up
than on the 8bit AVRs.
I suspect this is a homework assignment and the structure was provided.
You could just mark the struct as packed, eg..
typedef struct eventdata {
...
} __attribute__ ((packed)) ED;
Yup. Should also verify that sizeof(ED) == 58 in the code.
When allocating memory and calculating offsets into the EEPROM one
should use sizeof(ED) rather than a hard coded constant.
If I was defining the ED structure then I'd store 4 bytes of seconds
since some epoch rather than 6 bytes of year, month, day, hour, minute,
second. Much simpler, and routines to convert from seconds are readily
available in OS's and spreadsheets.
--
David Kelly N4HHE, dke...@hiwaay.net
Whom computers would destroy, they must first drive mad.
___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] External EEPROM verses internal EEPROM data handling
On Mon, May 04, 2009 at 11:06:06AM -0700, Steven Michalske wrote: so your external EEPROM will be accessed by functions you write. The compiler does not know how to interface to the external EEPROM. IIRC the compiler doesn't know internal AVR EEPROM either. AVR EEPROM is not mapped in CPU address space but it faked into the load map for debugging and device programming. [85 lines deleted under top-post] -- David Kelly N4HHE, dke...@hiwaay.net Whom computers would destroy, they must first drive mad. ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] External EEPROM verses internal EEPROM data handling
On Mon, May 04, 2009 at 11:46:40AM -0700, Steven Michalske wrote: On May 4, 2009, at 11:33 AM, David Kelly wrote: IIRC the compiler doesn't know internal AVR EEPROM either. AVR EEPROM is not mapped in CPU address space but it faked into the load map for debugging and device programming. Good catch Dave, avr libc has macros for accessing the AVR eeprom. Look at http://www.nongnu.org/avr-libc/user-manual/group__avr__eeprom.html for insperation on writing your own macros. You can add another section to your linker script for the external eeprom if you wanted to as well. Did that on a project some time ago. The advantage is to initialize the EEPROM at device programming time. You can get addresses off your structures initialized in the EEPROM but have to use them as offsets when using EEPROM routines rather than as pointers into RAM or FLASH. Other than the ability to initialize EEPROM with an AVR programming tool there isn't much difference in use of internal vs external EEPROM. The OP might consider writing to FLASH for his data logger assignment. Is harder to use as one must write bigger blocks at a time. Might be a wear limit depending on how many write/erase cycles are needed. -- David Kelly N4HHE, dke...@hiwaay.net Whom computers would destroy, they must first drive mad. ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] regression in size from 4.2.2 to 4.5.0
On Wed, May 06, 2009 at 12:44:42PM -0600, Sean D'Epagnier wrote: I was trying to reduce the size of my binary so it would fit on some 128kb parts. I normally used gcc 4.2.2 for this project, but decided to try gcc 4.5.0. To my surprise, the resulting binary was 3.5kb _larger_ with the newer gcc. I've been hanging around since something like 3.3.6 and rarely have I seen a newer avr-gcc produce smaller code. It happens sometimes. Is more important to generate correct code than to generate small code. I remember when avr-gcc issued two returns at the end of most (not all) routines. Pure waste. But the code ran correctly. This is a serious bug imho and should be fixed. If its documented then its a feature, not a bug. Want smaller code? Try one of the 3.x compilers. -- David Kelly N4HHE, dke...@hiwaay.net Whom computers would destroy, they must first drive mad. ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] Allocating variables to a fixed address
On Mon, May 11, 2009 at 02:55:17PM +0200, Robert von Knobloch wrote: Weddington, Eric wrote: Why do you need global variables to be at a specific address? Because my software consists of a: A fixed part - main plus User Interface - This is test equipment for small electronic products and Several loadable parts which can be loaded via rs232 as Intel hex and 'blown' into the flash as required - These are custom-built for each product. The entire code is one entity, loadables will be added and removed and I cannot have this affecting the main code. Sounds to me as if you are making the bootloader too big and should simply link an entire application for every possible target. What you are doing would make more sense if the loadable modules could run out of RAM. -- David Kelly N4HHE, dke...@hiwaay.net Whom computers would destroy, they must first drive mad. ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] Allocating variables to a fixed address
On Mon, May 11, 2009 at 03:56:34PM +0200, Robert von Knobloch wrote: David Kelly wrote: Sounds to me as if you are making the bootloader too big and should simply link an entire application for every possible target. What you are doing would make more sense if the loadable modules could run out of RAM. That would be no use, the loadables must be non-volatile. This is a tester that will be sent to a factory (somewhere). When a new product is to be tested, I can e-mail them the test routine which they then burn into flash (each of these is 0x900 bytes, there can be up to 0x0a of them). Yes, what I said before, link an entire application for every possible target. If a factory needs a new module added to their tester then link an application with all the modules they need if you are not able to make a single application that supports all known modules. Another way to pull this off would be to ship the avr-ln application, object files, and let the customer link their selected module set to flash the tester. You could wrap everything up and hide the process in a script or application. Strip the debugging stubs from the object files but leave the linking symbols. Otherwise for an example of how to statically allocate global variables look in the include files for how registers are defined. -- David Kelly N4HHE, dke...@hiwaay.net Whom computers would destroy, they must first drive mad. ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] Allocating variables to a fixed address
On Mon, May 11, 2009 at 08:21:37AM -0600, Weddington, Eric wrote: Sounds to me as if you are making the bootloader too big and should simply link an entire application for every possible target. What you are doing would make more sense if the loadable modules could run out of RAM. That would be no use, the loadables must be non-volatile. This is a tester that will be sent to a factory (somewhere). When a new product is to be tested, I can e-mail them the test routine which they then burn into flash (each of these is 0x900 bytes, there can be up to 0x0a of them). Why is this method superior to having a regular bootloader, and you have N applications, where each application is the individual test routine and the common portion? Why do you have create this custom interface which has its own set of problems? Alternatively, creating a custom Makefile to handle building 10 different applications is certainly easier in comparison. I agree, thats how I would handle it. Either build a custom linked application for each customer or provide the customer with the tools to build one of their own. What he is trying to do is in effect create a run time program linker. -- David Kelly N4HHE, dke...@hiwaay.net Whom computers would destroy, they must first drive mad. ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] Storing variables in external memory - suggestions
On Fri, May 22, 2009 at 05:35:43AM -0700, Parthasaradhi Nayani wrote: Hello all, I was wondering if any one can suggest a decent method of automatically assigning address space to variables in external EEPROM. For internal EEPROM the attribute EEMEM will allocate addresses in sequence. One can insert or delete a variable and the address space gets adjusted properly. Is there a method of doing something similar for external EEPROM. I have an external EEPROM where I would like to store and retrieve variables. Thanks in advance for your suggestions. All EEMEM does is this in eeprom.h: #define EEMEM __attribute__((section(.eeprom))) AVR Studio convention is that internal .eeprom starts at 0x0081. So what I'd do if I were you and wanted the compiler to assign static memory addresses in an external eeprom would be: #define EEEXT __attribute__((section(.eeexternal))) Then in my Makefile (or somewhere in AVR Studio) would add this to the linker definitions (am not certain 0x00a1 is available): LDFLAGS+=--section-start=.eeprom=00a1 If you put initialized definitions in EEEXT they will be lost. Your code has to write them in the external device because neither the compiler nor AVR Studio knows how. You can add a rule to the Makefile (if you are using make) to write a hex file containing your external EEPROM initial values: %_eeext.hex: %.elf avr-objcopy -j .eeexternal --change-section-lma .eeexternal=0 -O ihex $ $@ Then you need a target such as this which will invoke the above rule (think it needs a blank line after): object_eeext.hex: Finally, believe it goes without saying that you have to provide routines to access your external EEPROM device. -- David Kelly N4HHE, dke...@hiwaay.net Whom computers would destroy, they must first drive mad. ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] Storing variables in external memory - suggestions
On Fri, May 22, 2009 at 07:38:36AM -0700, Parthasaradhi Nayani wrote: Hello David Kelly, Thanks a lot for the suggestions. Yes, I understand that initializing the variables will not actually save the vales into the memory locations. I will try a sample code and revert. Thanks once again. And remember that the first variable you put in EEEXT will have the address of 0x00a1 in the symbol tables but an AVR pointer is 16 bits so it gets truncated to 0x. That is probably what you want in the first place when talking to you external EEPROM. Would be worth exploring putting a gcc attribute inside a typedef or similar so that your external eeprom routines might type check for EEEXT pointers in the address argument. Metrowerks on Freescale CPUs does something similar where an address could be near or far. -- David Kelly N4HHE, dke...@hiwaay.net Whom computers would destroy, they must first drive mad. ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] Memory problem
On Mon, Jun 22, 2009 at 10:17:50AM -0700, Parthasaradhi Nayani wrote: Hello all, I have interfaced flash memory to my mega64 and created a section for this memory. I have some variables and two structures which are located in this memory. Initially I defined the variables first and then the structure. After linking I checked the map and list files and found that the first defined variable occupied the first memory location and so on. Later I moved the structure to the top and compiled again but this time the variables remained in the same old order (the structure should have occupied the first byte onwards). Why is this happening? If I need to put some variables in some fixed address in this memory how can I do it? Thanks in advance for your help. The order variables are created only has accidental effect on their final resting place. In ancient times FORTRAN programmers often relied on variables being allocated in alphabetical order. Not all compilers/linkers behaved that way, which increased the difficulty of porting complex codes such as NASTRAN. Study the include files for register definitions for a means of controlling the absolute address of allocation. -- David Kelly N4HHE, dke...@hiwaay.net Whom computers would destroy, they must first drive mad. ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] Memory problem
On Tue, Jun 23, 2009 at 02:02:37AM -0700, Parthasaradhi Nayani wrote:
--- On Tue, 6/23/09, Joerg Wunsch j...@uriah.heep.sax.de wrote:
The only method to not have the linker reorder your variables is to
just use a single variable (per memory section).? So, put some kind of
an embracing struct around all your variables you'd like to have in
a particular order, and you'll be done.
Thank you very much for your suggestion. In case I declare all the
variables in a structure then accessing each variable will require
using the structure name.variable name! However I would like to assign
a memory to a variable also therefore can you suggest how I can do
this? Thanks once again for your support.
Joerg listed two methods. One is that you declare one section per
variable and set the address in each section declaration. The second is
the observation that a struct counts as one variable and that the
contents of a struct are not reordered.
It wouldn't be a bad idea at all to put all your external flash
variables in a struct named flash if for no other reason than to remind
you they are in flash and require special treatment to write. No matter
you code flash.variable to access, the generated code is just the same
as had variable not been in a struct. OTOH if you use a pointer to the
flash struct, flash-variable, then the code will grow unless the
compiler knows for certain that flash is constant.
Something like this might work for you:
typedef struct {
uint8_t variable;
uint16_t a, b, c, d;
uint32_t e;
} FLASH_STRUCT;
#define flash_p ((FLASH_STRUCT *)(0x8000))
Then use flash_p-variable to access.
The con of this method is that that all accounting of flash use has to
be done manually by the code author.
--
David Kelly N4HHE, dke...@hiwaay.net
Whom computers would destroy, they must first drive mad.
___
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
On Wed, Aug 19, 2009 at 02:23:10PM -0700, Steven Michalske wrote: This message got buried in a thread, because you used a reply to a previous message from the list. It's poor manners to hijack threads, and can cause some users not to reply. Same applies to top-post without trim. -- David Kelly N4HHE, dke...@hiwaay.net Whom computers would destroy, they must first drive mad. ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] Re: Larger than 64K memory sections
On Wed, Aug 26, 2009 at 03:10:05PM +0200, David Brown wrote: All in all, I can't see any advantage to the OP in using memory sections here, and I can see a great many complications if it can be made to work at all. I agree that with the avr-gcc toolset that a great many complications will occur if one tries to map 4MB into the existing 4MB memory space used by the linker. For lack of multiple address spaces the AVR tools magically assume an address space way out in never-never land is EEPROM. Perhaps the linker can be made 64-bit with minimal effort? I disagree with the claim that mapping external regions like this in to linker address space is a bad idea. We know nothing of the user's application or design for utilizing this space. Is very useful to create named globals and let the linker assign the address whether or not this global is in FLASH, RAM, EEPROM, or an external device. Otherwise one must manually manage allocation. -- David Kelly N4HHE, dke...@hiwaay.net Whom computers would destroy, they must first drive mad. ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] Re: Larger than 64K memory sections
On Wed, Aug 26, 2009 at 08:21:00PM -0700, Parthasaradhi Nayani wrote: David Kelly wrote: You are right that we know nothing about the application in question - details here would make it much easier to give recommendations. Hello all, I mentioned 4MB flash as it is the HW spec. This 4MB gets filled over a period of time. 4 million bytes or bits? Most FLASH devices are sized by the bit. Details of application - I have data packets each 32 bytes in size and we have accommodate 2000 of these (predefined). 32 * 2000 = 6400 bytes. This I plan to put in a part of the 4MB Flash. Rest of the memory will be used for storing records comprising of these data packets with data and time etc. The records will be deleted from time to time but the data packets will remain. It is possible to use a long int as an address pointer from the start of the available memory (after the data packets) and store records. I still curious to know how one can create a section larger than 64K. What you describe is probably best *not* mapped into avr-gcc name space or AVR address space. Is probably best to #define the starting offsets of each of your blocks of data. No matter what you do you won't be able to say *MyUInt16Ptr = 0x1234; you will have to write a routine and use it something like this: u16_value = 0x1234; result = Write4MBFlash( (uint32_t)MyUint16Ptr, sizeof(uint16_t), u16_value ); All the external SPI FLASH devices I have used are paged. One read/writes to a RAM buffer in the device then flush that buffer to a page in FLASH. IIRC the Atmel device I last used had 264 byte pages which served to complicate addressing if one insisted on using all 264 bytes. Believe the designer's intent was that one use 256 bytes as a sector and the other 8 bytes for tracking usage, even linking to previous sector and next sector for a form of filesystem. Atmel had a very useful appnote containing C routines for access to their DataFlash parts which helped a lot. I felt the need to heavily edit it for style and naming convention. Rearranged a bit, and deleted a lot that I didn't use. But it was a very good start. -- David Kelly N4HHE, dke...@hiwaay.net Whom computers would destroy, they must first drive mad. ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] Re: Larger than 64K memory sections
On Thu, Aug 27, 2009 at 09:55:05AM -0500, David Kelly wrote: On Wed, Aug 26, 2009 at 08:21:00PM -0700, Parthasaradhi Nayani wrote: Details of application - I have data packets each 32 bytes in size and we have accommodate 2000 of these (predefined). 32 * 2000 = 6400 bytes. Arrgh! Decaf! 64,000 bytes. Half of a megabit. -- David Kelly N4HHE, dke...@hiwaay.net Whom computers would destroy, they must first drive mad. ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] including default eeprom values in flash memory
On Wed, Oct 21, 2009 at 07:40:50AM -0700, Parthasaradhi Nayani wrote: From: Michael Clift mich...@clift.com.au ??? Hi, I am using winavr, and would like to include the default eeprom values (normally output to .eep) in flash memory. I want to do this so that my application can easily default the eeprom. Hello, EEPROM data in FLASH memory? then the easy way is to use the PGM space attribute to the variables you want in flash. Ditto. Declare the variables twice, once with a name that is obvious to you is EEPROM in the EEPROM space, and again with a name that is obvious to you is stored in FLASH. Then when/if you wish to restore EEPROM contents to their initial default values use the PGM modifier to read from FLASH and call the routine(s) used to write EEPROM. Duplicating the default data in your source code sounds wasteful but it will be easier to understand 6 months from now than an edit of the Makefile plus hacks to the memory segment definitions. I think it is possible that way to write the .eeprom segment to two places in memory, is just that you don't want to do it that way when there is an easier way that is also easier to understand. -- David Kelly N4HHE, dke...@hiwaay.net Whom computers would destroy, they must first drive mad. ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
