From j_baraclough at zetnet.co.uk Sun Jul 1 15:10:40 2007 From: j_baraclough at zetnet.co.uk (John Baraclough) Date: Sun Jul 1 15:21:20 2007 Subject: [Icc-avr] Absolute Ram Memory allocation? Ooops In-Reply-To: References: <072D96786BFC014AAEBA9EB07A8070EA22F733@seattle.ecpower.dk> Message-ID: Hi Jeff, I've been doing a little more investigation and there is some strange behaviour with the linker. I have a small test program for a mega2561, with the following lines of code: long MoreWasteSpace[200]; const unsigned char *Months[12] = { "Jan", "Feb", "Mar", "Apr", "May", "Jun", "Jul", "Aug", "Sep", "Oct", "Nov", "Dec" } ; int WasteSpace[100]; char Date[20]; #pragma data:mydata unsigned char BootFlags; unsigned char BootBuffer[24]; #pragma data:data I have added the following linker directive: -bmydata:0x0300.0x031f -bdata:0x200.0x21f:0x0400.0x21ff This is an excerpt from the map file which shows the utilisation of RAM. Area Addr Size Decimal Bytes (Attributes) -------------------------------- ---- ---- ------- ----- ------------ data 0200 0018 = 24. bytes (rel,con,ram) Addr Global Symbol ----- -------------------------------- 0200 _Months 0200 __data_start 0218 __data_end Area Addr Size Decimal Bytes (Attributes) -------------------------------- ---- ---- ------- ----- ------------ bss 0218 0417 = 1047. bytes (rel,con,ram) Addr Global Symbol ----- -------------------------------- 0218 __bss_start 0400 _Date 0414 _WasteSpace 04DC _MoreWasteSpace 0815 __bss_end Area Start End Decimal Bytes (Attributes) -------------------------------- ---- ---- ------- ----- ------------ vector 0000 0004 = 4. bytes (abs,ovr,rom) Area Addr Size Decimal Bytes (Attributes) -------------------------------- ---- ---- ------- ----- ------------ mydata 0300 0019 = 25. bytes (rel,con,ram) Addr Global Symbol ----- -------------------------------- 0300 _BootFlags 0301 _BootBuffer 0319 __mydata_end I would have expected the linker to use as much of the space below 0x0300 as possible before utilising the space above 0x0400. However it only appears to put the array of constant string pointers in there and then immediately jump to 0x400 to continue. I'm afraid the linker does not appear to be quite as efficient as it could be at utilising split areas of RAM. All the best for now, John At 22:40 29/06/2007, you wrote: >Content-class: urn:content-classes:message >Content-Type: multipart/alternative; > boundary="----_=_NextPart_001_01C7BA96.1C96999D" > >John, > >Thanks again, this list is a real knowledge base and blessing. > >Thanks >Jeff > >Jeff Milender >Sr. Electronic Design Engineer >Cargo Systems >Goodrich Interiors >2604 Highway 20 North >Jamestown, ND 58401 >Tel: 701-253-7569 >jeff.milender@goodrich.com >www.goodrich.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20070701/795d9bcd/attachment.html From jassenbaum at htp-tel.de Sun Jul 1 15:14:50 2007 From: jassenbaum at htp-tel.de (Johannes Assenbaum) Date: Sun Jul 1 15:23:27 2007 Subject: [Icc-avr] io header files for at90pwm216/316 References: <6.1.0.6.2.20070227141947.079e8468@192.168.100.42> Message-ID: <4fHPNTw3YVwBBsrwodYYavrI5JogKqsEoNkKPqL7HC9@akmail> If you need those now, get updater here: http://avr.jassenbaum.de/iccv7avr/index.html Else there is no change. Best regards Johannes From Jeff.Milender at goodrich.com Mon Jul 2 06:47:38 2007 From: Jeff.Milender at goodrich.com (Milender, Jeff) Date: Mon Jul 2 06:58:30 2007 Subject: [Icc-avr] Absolute Ram Memory allocation? Ooops In-Reply-To: References: <072D96786BFC014AAEBA9EB07A8070EA22F733@seattle.ecpower.dk> Message-ID: John, I noticed the same thing, but at this point I have enough other fires to fight that I am not concerned with this one. Thanks again for the assistance. Jeff Jeff Milender Sr. Electronic Design Engineer Cargo Systems Goodrich Interiors 2604 Highway 20 North Jamestown, ND 58401 Tel: 701-253-7569 jeff.milender@goodrich.com www.goodrich.com ________________________________ From: icc-avr-bounces@imagecraft.com [mailto:icc-avr-bounces@imagecraft.com] On Behalf Of John Baraclough Sent: Sunday, July 01, 2007 5:11 PM To: Discussion list for ICCAVR and ICCtiny Users. You do NOT need tosubscribe to icc-announce if you are a member of this. Subject: RE: [Icc-avr] Absolute Ram Memory allocation? Ooops Hi Jeff, I've been doing a little more investigation and there is some strange behaviour with the linker. I have a small test program for a mega2561, with the following lines of code: long MoreWasteSpace[200]; const unsigned char *Months[12] = { "Jan", "Feb", "Mar", "Apr", "May", "Jun", "Jul", "Aug", "Sep", "Oct", "Nov", "Dec" } ; int WasteSpace[100]; char Date[20]; #pragma data:mydata unsigned char BootFlags; unsigned char BootBuffer[24]; #pragma data:data I have added the following linker directive: -bmydata:0x0300.0x031f -bdata:0x200.0x21f:0x0400.0x21ff This is an excerpt from the map file which shows the utilisation of RAM. Area Addr Size Decimal Bytes (Attributes) -------------------------------- ---- ---- ------- ----- ------------ data 0200 0018 = 24. bytes (rel,con,ram) Addr Global Symbol ----- -------------------------------- 0200 _Months 0200 __data_start 0218 __data_end Area Addr Size Decimal Bytes (Attributes) -------------------------------- ---- ---- ------- ----- ------------ bss 0218 0417 = 1047. bytes (rel,con,ram) Addr Global Symbol ----- -------------------------------- 0218 __bss_start 0400 _Date 0414 _WasteSpace 04DC _MoreWasteSpace 0815 __bss_end Area Start End Decimal Bytes (Attributes) -------------------------------- ---- ---- ------- ----- ------------ vector 0000 0004 = 4. bytes (abs,ovr,rom) Area Addr Size Decimal Bytes (Attributes) -------------------------------- ---- ---- ------- ----- ------------ mydata 0300 0019 = 25. bytes (rel,con,ram) Addr Global Symbol ----- -------------------------------- 0300 _BootFlags 0301 _BootBuffer 0319 __mydata_end I would have expected the linker to use as much of the space below 0x0300 as possible before utilising the space above 0x0400. However it only appears to put the array of constant string pointers in there and then immediately jump to 0x400 to continue. I'm afraid the linker does not appear to be quite as efficient as it could be at utilising split areas of RAM. All the best for now, John At 22:40 29/06/2007, you wrote: Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7BA96.1C96999D" John, Thanks again, this list is a real knowledge base and blessing. Thanks Jeff Jeff Milender Sr. Electronic Design Engineer Cargo Systems Goodrich Interiors 2604 Highway 20 North Jamestown, ND 58401 Tel: 701-253-7569 jeff.milender@goodrich.com www.goodrich.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20070702/d564a955/attachment-0001.html From john111smith at gmail.com Mon Jul 2 09:53:26 2007 From: john111smith at gmail.com (John Smith) Date: Mon Jul 2 10:04:03 2007 Subject: [Icc-avr] 16 bits DAC Message-ID: Hi all According to ATMEGA64 datasheet we can use it for developing "6 PWM Channels with Programmable Resolution from 1 to 16 Bits". What is quality of possible developed 16 bits DAC for DC level generation with single pole RC low pass filter? What is code for its initialize and implementation? I have lot of experience with Atmega8/16/32 ones. Are there any new issue regarding its PCB pinout design/programming ? I will be appreciated with your comments in these regards. Best Regards JS -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20070702/3413aceb/attachment.html From paul.aa9gg at gmail.com Mon Jul 2 10:12:15 2007 From: paul.aa9gg at gmail.com (Paul Mateer) Date: Mon Jul 2 10:22:52 2007 Subject: [Icc-avr] 16 bits DAC In-Reply-To: References: Message-ID: <20f5efc40707021012m1fad857cs6b026e5d7bae27f5@mail.gmail.com> We do this with the Mega32, using the OCR, to generate a 4-20mA signal. Using 10-bits we get about 0.01mA per step. Pretty simple actually. On 7/2/07, John Smith wrote: > > Hi all > > According to ATMEGA64 datasheet we can use it for developing "6 PWM > Channels with Programmable Resolution from 1 to 16 Bits". > > What is quality of possible developed 16 bits DAC for DC level generation > with single pole RC low pass filter? > What is code for its initialize and implementation? > > I have lot of experience with Atmega8/16/32 ones. Are there any new issue > regarding its PCB pinout design/programming ? > > I will be appreciated with your comments in these regards. > > > Best Regards > JS > > _______________________________________________ > Icc-avr mailing list > Icc-avr@imagecraft.com > http://dragonsgate.net/mailman/listinfo/icc-avr > > -- Paul Mateer, AA9GG Elan Engineering Corp. www.elanengr.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20070702/42d873aa/attachment.html From BobGardner at aol.com Mon Jul 2 13:10:47 2007 From: BobGardner at aol.com (BobGardner@aol.com) Date: Mon Jul 2 13:21:32 2007 Subject: [Icc-avr] 16 bits DAC Message-ID: In a message dated 7/2/2007 12:54:45 P.M. Eastern Daylight Time, john111smith@gmail.com writes: What is quality of possible developed 16 bits DAC for DC level generation with single pole RC low pass filter? ================================================ The counter can count 20 million clocks a sec. You get a 16 bit count 305 times a sec, so if you have an RC at .1Hz, you'll be 20db down at 1hz, 40db down at 10hz, 60db down at 100hz. Not quite the 90db you need to have 16 bit resolution ************************************** See what's free at http://www.aol.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20070702/d360085b/attachment.html From ira at extrasensory.com Mon Jul 2 16:09:02 2007 From: ira at extrasensory.com (Ira) Date: Mon Jul 2 16:24:01 2007 Subject: [Icc-avr] Why does it do this? In-Reply-To: <34998.199.22.57.2.1173197259.squirrel@www.microsyl.com> References: <000701c75f70$da89ac60$0301a8c0@Sylvain> <45ED5A12.7060605@indas.de> <34998.199.22.57.2.1173197259.squirrel@www.microsyl.com> Message-ID: <0MKp8S-1I5V592ILS-0002r9@mrelay.perfora.net> In a piece of code looking something like this: unsigned int foo( unsigned int *x){ const unsigned int y[1024] = {1,2,3,4,5,6,7}; return y[*x]; } At the beginning of the listing there 32 occurrences of ADIW R28,0x3F and at the end of the listing there are 32 occupancies of SBIW R28,0x3F Not a complaint, but is there a reason for this? I can't think of one and it just seems very odd. Ira From MDipperstein at CalAmp.com Mon Jul 2 16:38:26 2007 From: MDipperstein at CalAmp.com (Michael Dipperstein) Date: Mon Jul 2 16:49:03 2007 Subject: [Icc-avr] Why does it do this? In-Reply-To: <0MKp8S-1I5V592ILS-0002r9@mrelay.perfora.net> Message-ID: The code is incrementing your stack pointer 2048 bytes to make room for your array of 1024 integers. There are more efficient ways to change the stack pointer by such large amounts, but I'm guessing most people don't put such large blocks of data on the stacks of their AVRs. -Mike > -----Original Message----- > From: icc-avr-bounces@imagecraft.com [mailto:icc-avr- > bounces@imagecraft.com] On Behalf Of Ira > Sent: Monday, July 02, 2007 4:09 PM > To: icc-avr@imagecraft.com > Subject: [Icc-avr] Why does it do this? > > In a piece of code looking something like this: > > unsigned int foo( unsigned int *x){ > const unsigned int y[1024] = {1,2,3,4,5,6,7}; > return y[*x]; > } > > At the beginning of the listing there 32 occurrences of ADIW > R28,0x3F > and at the end of the listing there are 32 occupancies of SBIW > R28,0x3F > > Not a complaint, but is there a reason for this? I can't think of one > and it just seems very odd. > > Ira > > _______________________________________________ > Icc-avr mailing list > Icc-avr@imagecraft.com > http://dragonsgate.net/mailman/listinfo/icc-avr From ira at extrasensory.com Mon Jul 2 18:52:26 2007 From: ira at extrasensory.com (Ira) Date: Mon Jul 2 19:03:28 2007 Subject: [Icc-avr] Why does it do this? In-Reply-To: References: <0MKp8S-1I5V592ILS-0002r9@mrelay.perfora.net> Message-ID: <0MKpCa-1I5XZS3HCb-0001bA@mrelay.perfora.net> At 04:38 PM 7/2/2007, you wrote: >The code is incrementing your stack pointer 2048 bytes to make room for >your array of 1024 integers. > >There are more efficient ways to change the stack pointer by such large >amounts, but I'm guessing most people don't put such large blocks of >data on the stacks of their AVRs. That would indicate that I'm not doing what I want in anything remotely resembling the most efficient way possible. I want to create a look-up table in flash that I can retrieve a value from. I know how to do it in assembly on the PIC, but have no clue how to do it in C on the AVR. So, 2 questions: What is a reasonable way to create a large data table, in this case, 1024 unsigned ints? And second, is there built in support in ICC to write to flash from running code? In case I want to update that table from my running code. Ira From BobGardner at aol.com Mon Jul 2 20:25:46 2007 From: BobGardner at aol.com (BobGardner@aol.com) Date: Mon Jul 2 20:36:28 2007 Subject: [Icc-avr] Why does it do this? Message-ID: In a message dated 7/2/2007 7:14:29 P.M. Eastern Daylight Time, ira@extrasensory.com writes: unsigned int foo( unsigned int *x){ const unsigned int y[1024] = {1,2,3,4,5,6,7}; return y[*x]; } =============================================== const unsigned int y[1024] = {1,2,3,4,5,6,7}; //put the array outside of the function unsigned int dat,ndx; dat=y[ndx]; //dont need a pointer, dont need a function ************************************** See what's free at http://www.aol.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20070702/9d2eafc9/attachment.html From ira at extrasensory.com Mon Jul 2 23:51:38 2007 From: ira at extrasensory.com (Ira) Date: Tue Jul 3 00:04:05 2007 Subject: [Icc-avr] Why does it do this? In-Reply-To: References: Message-ID: <0MKpCa-1I5cGN1aQZ-0001ZP@mrelay.perfora.net> At 08:25 PM 7/2/2007, you wrote: >=============================================== >const unsigned int y[1024] = {1,2,3,4,5,6,7}; //put the array >outside of the function >unsigned int dat,ndx; >dat=y[ndx]; //dont need a pointer, dont need a function Thanks ever so much. I wasn't worried about the overhead of the function call but I was surprised it initialized the array every time through the function. Much happier since I moved it outside. Ira From t.jaspers at cpseurope.com Tue Jul 3 00:36:14 2007 From: t.jaspers at cpseurope.com (Jaspers, Ton) Date: Tue Jul 3 00:46:52 2007 Subject: [Icc-avr] Why does it do this? In-Reply-To: Message-ID: <7B0EB27CF1CC93439B5CFB7526E5D74C45D813@mickey.PBNV.local> Or use a "static" modifier. ________________________________ From: icc-avr-bounces@imagecraft.com [mailto:icc-avr-bounces@imagecraft.com] On Behalf Of BobGardner@aol.com Sent: dinsdag 3 juli 2007 5:26 To: icc-avr@imagecraft.com Subject: Re: [Icc-avr] Why does it do this? In a message dated 7/2/2007 7:14:29 P.M. Eastern Daylight Time, ira@extrasensory.com writes: unsigned int foo( unsigned int *x){ const unsigned int y[1024] = {1,2,3,4,5,6,7}; return y[*x]; } =============================================== const unsigned int y[1024] = {1,2,3,4,5,6,7}; //put the array outside of the function unsigned int dat,ndx; dat=y[ndx]; //dont need a pointer, dont need a function ________________________________ See what's free at AOL.com . -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20070703/f9da415f/attachment.html From sl at ecpower.dk Tue Jul 3 02:13:40 2007 From: sl at ecpower.dk (Steven Lose) Date: Tue Jul 3 02:24:20 2007 Subject: SV: [Icc-avr] Why does it do this? References: <7B0EB27CF1CC93439B5CFB7526E5D74C45D813@mickey.PBNV.local> Message-ID: <072D96786BFC014AAEBA9EB07A8070EA22F917@seattle.ecpower.dk> Depends, if you only have internal ram, use static or put it outside function as global. If you have external memory, use static if you want it in internal memory or put it outside function if you want it in (slower) external memory. Med venlig hilsen / Best regards / mit freundlichen Gr??en EC POWER A/S Steven Lose Software Ingeni?r Tlf.: +45 87434100 Direkte tlf. +45 58286608 Email: sl@ecpower.dk www.ecpower.dk ________________________________ Fra: icc-avr-bounces@imagecraft.com [mailto:icc-avr-bounces@imagecraft.com] P? vegne af Jaspers, Ton Sendt: 3. juli 2007 09:36 Til: Discussion list for ICCAVR and ICCtiny Users. You do NOT need to subscribeto icc-announce if you are a member of this. Emne: RE: [Icc-avr] Why does it do this? Or use a "static" modifier. ________________________________ From: icc-avr-bounces@imagecraft.com [mailto:icc-avr-bounces@imagecraft.com] On Behalf Of BobGardner@aol.com Sent: dinsdag 3 juli 2007 5:26 To: icc-avr@imagecraft.com Subject: Re: [Icc-avr] Why does it do this? In a message dated 7/2/2007 7:14:29 P.M. Eastern Daylight Time, ira@extrasensory.com writes: unsigned int foo( unsigned int *x){ const unsigned int y[1024] = {1,2,3,4,5,6,7}; return y[*x]; } =============================================== const unsigned int y[1024] = {1,2,3,4,5,6,7}; //put the array outside of the function unsigned int dat,ndx; dat=y[ndx]; //dont need a pointer, dont need a function ________________________________ See what's free at AOL.com . -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20070703/9029e152/attachment-0001.html From j_baraclough at zetnet.co.uk Tue Jul 3 08:45:47 2007 From: j_baraclough at zetnet.co.uk (John Baraclough) Date: Tue Jul 3 08:56:32 2007 Subject: SV: [Icc-avr] Why does it do this? In-Reply-To: <072D96786BFC014AAEBA9EB07A8070EA22F917@seattle.ecpower.dk> References: <7B0EB27CF1CC93439B5CFB7526E5D74C45D813@mickey.PBNV.local> <072D96786BFC014AAEBA9EB07A8070EA22F917@seattle.ecpower.dk> Message-ID: There's no point in using 'static' for 'const' values. ICCAVR uses 'const' in a slightly unconventional way, in that it forces that data to be in Flash memory. Any data declared using the 'const' keyword should always be global, so that it is accessible to all code modules in the project. All the best for now, John At 10:13 03/07/2007, you wrote: >Content-class: urn:content-classes:message >Content-Type: multipart/alternative; > boundary="----_=_NextPart_001_01C7BD52.72CF5302" > >Depends, if you only have internal ram, use >static or put it outside function as global. >If you have external memory, use static if you >want it in internal memory or put it outside >function if you want it in (slower) external memory. > > >Med venlig hilsen / Best regards / mit freundlichen Gr??en > >EC POWER A/S > >Steven Lose > >Software Ingeni?r > >Tlf.: +45 87434100 > >Direkte tlf. +45 58286608 > >Email: sl@ecpower.dk > >www.ecpower.dk > >---------- >Fra: icc-avr-bounces@imagecraft.com >[mailto:icc-avr-bounces@imagecraft.com] P? vegne af Jaspers, Ton >Sendt: 3. juli 2007 09:36 >Til: Discussion list for ICCAVR and ICCtiny >Users. You do NOT need to subscribeto icc-announce if you are a member of this. >Emne: RE: [Icc-avr] Why does it do this? > >Or use a "static" modifier. > > > >---------- >From: icc-avr-bounces@imagecraft.com >[mailto:icc-avr-bounces@imagecraft.com] On Behalf Of BobGardner@aol.com >Sent: dinsdag 3 juli 2007 5:26 >To: icc-avr@imagecraft.com >Subject: Re: [Icc-avr] Why does it do this? >In a message dated 7/2/2007 7:14:29 P.M. Eastern >Daylight Time, ira@extrasensory.com writes: >unsigned int foo( unsigned int *x){ > const unsigned int y[1024] = {1,2,3,4,5,6,7}; > return y[*x]; >} > >=============================================== >const unsigned int y[1024] = {1,2,3,4,5,6,7}; >//put the array outside of the function >unsigned int dat,ndx; >dat=y[ndx]; //dont need a pointer, dont need a function > > > > >---------- >See what's free at AOL.com. > >_______________________________________________ >Icc-avr mailing list >Icc-avr@imagecraft.com >http://dragonsgate.net/mailman/listinfo/icc-avr -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20070703/757a12c6/attachment.html From richard-lists at imagecraft.com Tue Jul 3 19:43:22 2007 From: richard-lists at imagecraft.com (Richard) Date: Tue Jul 3 19:53:59 2007 Subject: [Icc-avr] Absolute Ram Memory allocation? Ooops In-Reply-To: References: <072D96786BFC014AAEBA9EB07A8070EA22F733@seattle.ecpower.dk> Message-ID: <200707040253.l642rua1065171@dragonsgate2.imagecraft.com> An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20070703/5b613703/attachment.html From richard-lists at imagecraft.com Tue Jul 3 19:45:18 2007 From: richard-lists at imagecraft.com (Richard) Date: Tue Jul 3 19:55:52 2007 Subject: [Icc-avr] Why does it do this? In-Reply-To: <0MKpCa-1I5cGN1aQZ-0001ZP@mrelay.perfora.net> References: <0MKpCa-1I5cGN1aQZ-0001ZP@mrelay.perfora.net> Message-ID: <200707040255.l642tpBD065217@dragonsgate2.imagecraft.com> That is the semantic of declaring an object inside a function. "Const" just means not-modifiable but the lifetime of the object is still just within the function, i.e. it needs to be on the stack. At 11:51 PM 7/2/2007, you wrote: >At 08:25 PM 7/2/2007, you wrote: >>=============================================== >>const unsigned int y[1024] = {1,2,3,4,5,6,7}; //put the array >>outside of the function >>unsigned int dat,ndx; >>dat=y[ndx]; //dont need a pointer, dont need a function > > >Thanks ever so much. I wasn't worried about the overhead of the >function call but I was surprised it initialized the array every >time through the function. Much happier since I moved it outside. > >Ira // richard (This email is for mailing lists. To reach me directly, please use richard at imagecraft.com) From ira at extrasensory.com Wed Jul 4 00:17:11 2007 From: ira at extrasensory.com (Ira) Date: Wed Jul 4 00:28:22 2007 Subject: [Icc-avr] Why does it do this? In-Reply-To: <200707040255.l642tpBD065217@dragonsgate2.imagecraft.com> References: <0MKpCa-1I5cGN1aQZ-0001ZP@mrelay.perfora.net> <200707040255.l642tpBD065217@dragonsgate2.imagecraft.com> Message-ID: <0MKp8S-1I5z7N1H5R-0002we@mrelay.perfora.net> At 07:45 PM 7/3/2007, you wrote: >That is the semantic of declaring an object inside a function. >"Const" just means not-modifiable but the lifetime of the object is >still just within the function, i.e. it needs to be on the stack. It still seems like on odd choice as it resides in flash and the code would be faster if you just treated it the same as if it was declared outside, wouldn't it? Ira From richard-lists at imagecraft.com Wed Jul 4 00:49:46 2007 From: richard-lists at imagecraft.com (Richard) Date: Wed Jul 4 01:00:22 2007 Subject: [Icc-avr] Why does it do this? In-Reply-To: <0MKp8S-1I5z7N1H5R-0002we@mrelay.perfora.net> References: <0MKpCa-1I5cGN1aQZ-0001ZP@mrelay.perfora.net> <200707040255.l642tpBD065217@dragonsgate2.imagecraft.com> <0MKp8S-1I5z7N1H5R-0002we@mrelay.perfora.net> Message-ID: <200707040800.l6480Ljd068237@dragonsgate2.imagecraft.com> Sure there are many ways to interpret things but I rather not do too many "do what they mean, not what they write" decisions. At 12:17 AM 7/4/2007, Ira wrote: >At 07:45 PM 7/3/2007, you wrote: >>That is the semantic of declaring an object inside a function. >>"Const" just means not-modifiable but the lifetime of the object is >>still just within the function, i.e. it needs to be on the stack. > >It still seems like on odd choice as it resides in flash and the >code would be faster if you just treated it the same as if it was >declared outside, wouldn't it? > // richard (This email is for mailing lists. To reach me directly, please use richard at imagecraft.com) From j_baraclough at zetnet.co.uk Wed Jul 4 06:19:29 2007 From: j_baraclough at zetnet.co.uk (John Baraclough) Date: Wed Jul 4 06:30:15 2007 Subject: [Icc-avr] Absolute Ram Memory allocation? Ooops In-Reply-To: <200707040253.l642rua1065171@dragonsgate2.imagecraft.com> References: <072D96786BFC014AAEBA9EB07A8070EA22F733@seattle.ecpower.dk> <200707040253.l642rua1065171@dragonsgate2.imagecraft.com> Message-ID: Hi Richard, In the map file below the 'bss' area starts immediately after the 'data' area at 0x0218. However the space between 0x0218->0x02ff remains unused and the first use of 'bss' is at address 0x0400. I assume this is because the area 'mydata' is sitting in between, but it does leave some unused RAM. It won't affect Jeff as he appears to have plenty of RAM to play with. Also it is a simple test and doesn't have much stuff in the data area. The most important lesson to be learnt here is that personalised data areas should always be placed at the start of the RAM area so that the 'data' & 'bss' areas can be contiguous allowing the linker to manage them correctly. All the best for now, John At 03:43 04/07/2007, you wrote: >Eh? What's the problem? Initialized globals go to the "data" area >and non-initialized globals (which default to zero-initialized) go >to the "bss" area. The linker do not change the ordering of the >variables within each area (although it may do that according to >Standard C rules but this will cause some problems with some code >and also generally not a high priority optimization). Can you >explain further what I am missing? > >At 03:10 PM 7/1/2007, John Baraclough wrote: >>Hi Jeff, >> >>I've been doing a little more investigation and there is some >>strange behaviour with the linker. >> >>I have a small test program for a mega2561, with the following lines of code: >> >>long MoreWasteSpace[200]; >> >>const unsigned char *Months[12] = >>{ >> "Jan", >> "Feb", >> "Mar", >> "Apr", >> "May", >> "Jun", >> "Jul", >> "Aug", >> "Sep", >> "Oct", >> "Nov", >> "Dec" >>} ; >> >>int WasteSpace[100]; >>char Date[20]; >> >>#pragma data:mydata >> unsigned char BootFlags; >> unsigned char BootBuffer[24]; >>#pragma data:data >> >> >>I have added the following linker directive: >> >>-bmydata:0x0300.0x031f -bdata:0x200.0x21f:0x0400.0x21ff >> >> >>This is an excerpt from the map file which shows the utilisation of RAM. >> >>Area Addr Size Decimal Bytes (Attributes) >>-------------------------------- ---- ---- ------- ----- ------------ >> data 0200 0018 = 24. bytes (rel,con,ram) >> >> Addr Global Symbol >> ----- -------------------------------- >> 0200 _Months >> 0200 __data_start >> 0218 __data_end >> >>Area Addr Size Decimal Bytes (Attributes) >>-------------------------------- ---- ---- ------- ----- ------------ >> bss 0218 0417 = 1047. bytes (rel,con,ram) >> >> Addr Global Symbol >> ----- -------------------------------- >> 0218 __bss_start >> 0400 _Date >> 0414 _WasteSpace >> 04DC _MoreWasteSpace >> 0815 __bss_end >> >>Area Start End Decimal Bytes (Attributes) >>-------------------------------- ---- ---- ------- ----- ------------ >> vector 0000 0004 = 4. bytes (abs,ovr,rom) >> >>Area Addr Size Decimal Bytes (Attributes) >>-------------------------------- ---- ---- ------- ----- ------------ >> mydata 0300 0019 = 25. bytes (rel,con,ram) >> >> Addr Global Symbol >> ----- -------------------------------- >> 0300 _BootFlags >> 0301 _BootBuffer >> 0319 __mydata_end >> >> >>I would have expected the linker to use as much of the space below >>0x0300 as possible before utilising the space above 0x0400. However >>it only appears to put the array of constant string pointers in >>there and then immediately jump to 0x400 to continue. I'm afraid >>the linker does not appear to be quite as efficient as it could be >>at utilising split areas of RAM. >> >>All the best for now, >>John >> >> >>At 22:40 29/06/2007, you wrote: >>>Content-class: urn:content-classes:message >>>Content-Type: multipart/alternative; >>> boundary="----_=_NextPart_001_01C7BA96.1C96999D" >>> >>>John, >>> >>>Thanks again, this list is a real knowledge base and blessing. >>> >>>Thanks >>>Jeff >>> >>>Jeff Milender >>>Sr. Electronic Design Engineer >>>Cargo Systems >>>Goodrich Interiors >>>2604 Highway 20 North >>>Jamestown, ND 58401 >>>Tel: 701-253-7569 >>>jeff.milender@goodrich.com >>>www.goodrich.com >>_______________________________________________ >>Icc-avr mailing list >>Icc-avr@imagecraft.com >>http://dragonsgate.net/mailman/listinfo/icc-avr > >// richard (This email is for mailing lists. To reach me directly, >please use richard at imagecraft.com) >_______________________________________________ >Icc-avr mailing list >Icc-avr@imagecraft.com >http://dragonsgate.net/mailman/listinfo/icc-avr -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20070704/742e4868/attachment-0001.html From richard-lists at imagecraft.com Wed Jul 4 10:45:38 2007 From: richard-lists at imagecraft.com (Richard) Date: Wed Jul 4 10:56:16 2007 Subject: [Icc-avr] Absolute Ram Memory allocation? Ooops In-Reply-To: References: <072D96786BFC014AAEBA9EB07A8070EA22F733@seattle.ecpower.dk> <200707040253.l642rua1065171@dragonsgate2.imagecraft.com> Message-ID: <200707041756.l64HuFDW074291@dragonsgate2.imagecraft.com> At 06:19 AM 7/4/2007, John Baraclough wrote: >Hi Richard, > >In the map file below the 'bss' area starts immediately after the >'data' area at 0x0218. However the space between 0x0218->0x02ff >remains unused and the first use of 'bss' is at address 0x0400. I >assume this is because the area 'mydata' is sitting in between, but >it does leave some unused RAM. Right, as I said, the linker won't split or rearrange bss items within a single file (think of them as a single unit), and nothing fits in between that space. Is it suboptimal use of space? Sure. However, at least the behavior is explainable, deterministic, and won't happen or can be worked around in most cases that one cares about so it's a low priority to change, and the only thing I would consider changing is breaking up items within a single file. I have actually done that for the M8C compiler, but that brings its share of trouble to the users. >It won't affect Jeff as he appears to have plenty of RAM to play >with. Also it is a simple test and doesn't have much stuff in the >data area. The most important lesson to be learnt here is that >personalised data areas should always be placed at the start of the >RAM area so that the 'data' & 'bss' areas can be contiguous allowing >the linker to manage them correctly. Yup. Thanks for reverse engineering and documenting the process. // richard (This email is for mailing lists. To reach me directly, please use richard at imagecraft.com) From jsp at infonegocio.com Thu Jul 5 00:40:48 2007 From: jsp at infonegocio.com (Jose Sanchez del Pozo) Date: Thu Jul 5 00:51:43 2007 Subject: [Icc-avr] Why does it do this? In-Reply-To: <200707040255.l642tpBD065217@dragonsgate2.imagecraft.com> References: <0MKpCa-1I5cGN1aQZ-0001ZP@mrelay.perfora.net> <200707040255.l642tpBD065217@dragonsgate2.imagecraft.com> Message-ID: <16689050.20070705094048@infonegocio.com> Richard, that means that "const" means two different things in ICCAVR. Either it makes an object reside in flash OR it means an object is not-modifiable (but it can reside in the stack, not flash), depending where "const" is used. IMHO, that is a bit weird. Moreover when the manual says: "There are no standard rules for how to handle this. The ImageCraft AVR compiler uses the const qualifier to signify that an item is in the program memory..." That is clearly not consistent with the second use of "const", is it? Regards, Jose Sanchez del Pozo jsp@infonegocio.com Con fecha mi?rcoles, 04 de julio de 2007, 4:45:18, escribi?: > That is the semantic of declaring an object inside a function. > "Const" just means not-modifiable but the lifetime of the object is > still just within the function, i.e. it needs to be on the stack. > At 11:51 PM 7/2/2007, you wrote: >>At 08:25 PM 7/2/2007, you wrote: >>>=============================================== >>>const unsigned int y[1024] = {1,2,3,4,5,6,7}; //put the array >>>outside of the function >>>unsigned int dat,ndx; >>>dat=y[ndx]; //dont need a pointer, dont need a function >> >> >>Thanks ever so much. I wasn't worried about the overhead of the >>function call but I was surprised it initialized the array every >>time through the function. Much happier since I moved it outside. >> >>Ira > // richard (This email is for mailing lists. To reach me directly, > please use richard at imagecraft.com) > _______________________________________________ > Icc-avr mailing list > Icc-avr@imagecraft.com > http://dragonsgate.net/mailman/listinfo/icc-avr -- Saludos, Jose mailto:jsp@infonegocio.com From richard-lists at imagecraft.com Thu Jul 5 01:28:23 2007 From: richard-lists at imagecraft.com (Richard) Date: Thu Jul 5 01:39:03 2007 Subject: [Icc-avr] Why does it do this? In-Reply-To: <16689050.20070705094048@infonegocio.com> References: <0MKpCa-1I5cGN1aQZ-0001ZP@mrelay.perfora.net> <200707040255.l642tpBD065217@dragonsgate2.imagecraft.com> <16689050.20070705094048@infonegocio.com> Message-ID: <200707050839.l658d2t4081634@dragonsgate2.imagecraft.com> No, const means the object is non-modifiable, and putting it in flash satisfies that. The meaning has not changed. The implicit "auto" storage for local variables, regardless of the const qualifier takes precedent - the object must obey function scope lifetime. OTOH, yes, I should amend the documentation to clarify that. Thanks for pointing it out. As for why not just put const local in program memory, consider const being used as a parameter type void foo(const int i); it's a bit in netherland - it can clearly not be in the program memory. So it goes. The proper thing to do is to introduce a __flash qualifier, which we will do so at some points, with a compatibility switch of course so old program will not break. Then const will go back to mean that it is not modifiable (of course __flash would imply const, sigh). While C was designed to run on the PDP-11 with separate Instruction and Data space, those ol' timers wrote the compilers themselves so they know the semantic of everything and they never had this sort of trouble :-) At 12:40 AM 7/5/2007, Jose Sanchez del Pozo wrote: >Richard, >that means that "const" means two different things in ICCAVR. Either >it makes an object reside in flash OR it means an object is >not-modifiable (but it can reside in the stack, not flash), depending >where "const" is used. > >IMHO, that is a bit weird. Moreover when the manual says: > >"There are no standard rules for how to handle this. The ImageCraft >AVR compiler uses the const qualifier to signify that an item is in >the program memory..." > >That is clearly not consistent with the second use of "const", is it? > >Regards, > >Jose Sanchez del Pozo >jsp@infonegocio.com > // richard (This email is for mailing lists. To reach me directly, please use richard at imagecraft.com) From schaefer at mabel.info Thu Jul 5 03:02:59 2007 From: schaefer at mabel.info (=?ISO-8859-1?Q?Thomas_Sch=E4fer?=) Date: Thu Jul 5 03:13:40 2007 Subject: [Icc-avr] Running M168 code on M168P w/o recompile? In-Reply-To: <200707050839.l658d2t4081634@dragonsgate2.imagecraft.com> References: <0MKpCa-1I5cGN1aQZ-0001ZP@mrelay.perfora.net> <200707040255.l642tpBD065217@dragonsgate2.imagecraft.com> <16689050.20070705094048@infonegocio.com> <200707050839.l658d2t4081634@dragonsgate2.imagecraft.com> Message-ID: <468CC1D3.3060803@mabel.info> Hi all, is it possible to run code, compiled for an Mega168, on an Mega168P without recompiling? In my opinion it should work because there is only a iom168v.h. Another little thing, I realized: If I choose in the Project options the 169P and let the App Builder make a basic file, the iom169v.h will be included instead of the iom169vp.h. Is this a bug? regards, Thomas From sl at ecpower.dk Thu Jul 5 03:59:16 2007 From: sl at ecpower.dk (Steven Lose) Date: Thu Jul 5 04:10:03 2007 Subject: [Icc-avr] check for adequately nr. of bits Message-ID: <072D96786BFC014AAEBA9EB07A8070EA22F9BC@seattle.ecpower.dk> Hi. I want to make the linker check that a variable is defined big enough, but don't know how. Basically I need something that tells me how many bits there is in a variable so I can check it up against a defined value. #define NROFFLAGS 17 Unsigned int uiFlags; #if NROFFLAGS > NROFBITS(uiFlags) ERROR "VALUE TO SMALL" #endif Is it possible to do so? (if it had been in code I would just use (sizeof(uiFlags)*8) ) And if yes, what is the right way to do it? Med venlig hilsen / Best regards / mit freundlichen Gr??en EC POWER A/S Steven Lose Software Ingeni?r Tlf.: +45 87434100 Direkte tlf. +45 58286608 Email: sl@ecpower.dk www.ecpower.dk -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20070705/bc0148fb/attachment.html From t.jaspers at cpseurope.com Thu Jul 5 05:45:20 2007 From: t.jaspers at cpseurope.com (Jaspers, Ton) Date: Thu Jul 5 05:56:02 2007 Subject: [Icc-avr] check for adequately nr. of bits In-Reply-To: <072D96786BFC014AAEBA9EB07A8070EA22F9BC@seattle.ecpower.dk> Message-ID: <7B0EB27CF1CC93439B5CFB7526E5D74C45D932@mickey.PBNV.local> I don't think it is a linker issue. It is a coding issue. You could try to use teh pre-processor with something like this: #include #define NROFFLAGS 17 #if (1<<(NROFFLAGS-1)) > UINT_MAX ERROR "VALUE TO SMALL" #endif Mind you, I have not tried it. Cheers, Ton ________________________________ From: icc-avr-bounces@imagecraft.com [mailto:icc-avr-bounces@imagecraft.com] On Behalf Of Steven Lose Sent: donderdag 5 juli 2007 12:59 To: Discussion list for ICCAVR and ICCtiny Users. You do NOT need tosubscribeto icc-announce if you are a member of this. Subject: [Icc-avr] check for adequately nr. of bits Hi. I want to make the linker check that a variable is defined big enough, but don't know how. Basically I need something that tells me how many bits there is in a variable so I can check it up against a defined value. #define NROFFLAGS 17 Unsigned int uiFlags; #if NROFFLAGS > NROFBITS(uiFlags) ERROR "VALUE TO SMALL" #endif Is it possible to do so? (if it had been in code I would just use (sizeof(uiFlags)*8) ) And if yes, what is the right way to do it? Med venlig hilsen / Best regards / mit freundlichen Gr??en EC POWER A/S Steven Lose Software Ingeni?r Tlf.: +45 87434100 Direkte tlf. +45 58286608 Email: sl@ecpower.dk www.ecpower.dk -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20070705/72057638/attachment-0001.html From albert.vanveen at pertronic.co.nz Thu Jul 5 13:13:21 2007 From: albert.vanveen at pertronic.co.nz (Albert van Veen) Date: Thu Jul 5 13:24:31 2007 Subject: [Icc-avr] check for adequately nr. of bits In-Reply-To: <7B0EB27CF1CC93439B5CFB7526E5D74C45D932@mickey.PBNV.local> Message-ID: couldn't you simply say #if NROFFLAGS<17 Unsigned int uiFlags; #else Unsigned long uiFlags; #endif Albert -----Original Message----- From: Jaspers, Ton [mailto:t.jaspers@cpseurope.com] Sent: Friday, 6 July 2007 12:45 a.m. To: Discussion list for ICCAVR and ICCtiny Users. You do NOT need to subscribeto icc-announce if you are a member of this. Subject: RE: [Icc-avr] check for adequately nr. of bits I don't think it is a linker issue. It is a coding issue. You could try to use teh pre-processor with something like this: #include #define NROFFLAGS 17 #if (1<<(NROFFLAGS-1)) > UINT_MAX ERROR ?VALUE TO SMALL? #endif Mind you, I have not tried it. Cheers, Ton ---------------------------------------------------------------------------- From: icc-avr-bounces@imagecraft.com [mailto:icc-avr-bounces@imagecraft.com] On Behalf Of Steven Lose Sent: donderdag 5 juli 2007 12:59 To: Discussion list for ICCAVR and ICCtiny Users. You do NOT need tosubscribeto icc-announce if you are a member of this. Subject: [Icc-avr] check for adequately nr. of bits Hi. I want to make the linker check that a variable is defined big enough, but don?t know how. Basically I need something that tells me how many bits there is in a variable so I can check it up against a defined value. #define NROFFLAGS 17 Unsigned int uiFlags; #if NROFFLAGS > NROFBITS(uiFlags) ERROR ?VALUE TO SMALL? #endif Is it possible to do so? (if it had been in code I would just use (sizeof(uiFlags)*8) ) And if yes, what is the right way to do it? Med venlig hilsen / Best regards / mit freundlichen Gr??en EC POWER A/S Steven Lose Software Ingeni?r Tlf.: +45 87434100 Direkte tlf. +45 58286608 Email: sl@ecpower.dk www.ecpower.dk -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20070706/25b52aa4/attachment.html From j_baraclough at zetnet.co.uk Thu Jul 5 13:59:53 2007 From: j_baraclough at zetnet.co.uk (John Baraclough) Date: Thu Jul 5 14:10:39 2007 Subject: [Icc-avr] check for adequately nr. of bits In-Reply-To: References: <7B0EB27CF1CC93439B5CFB7526E5D74C45D932@mickey.PBNV.local> Message-ID: You could indeed, but it would be very unwise. Single bit flags should always be stored in 8-bit variables, otherwise there is a very large overhead in setting, clearing or testing any flag. This is the way I define flag macros for fastest execution: #include #define SCR_BIT 0 #define RUN_BIT 1 #define SEN_BIT 2 #define CHA_BIT 3 #define UPD_BIT 4 // Flow control flags. #define TEST_SCREEN_FLAG gucFlags&BIT(SCR) #define SET_SCREEN_FLAG gucFlags|=BIT(SCR) #define CLEAR_SCREEN_FLAG gucFlags&=~BIT(SCR) #define TEST_RUN_FLAG gucFlags&BIT(RUN) #define SET_RUN_FLAG gucFlags|=BIT(RUN) #define CLEAR_RUN_FLAG gucFlags&=~BIT(RUN) #define TEST_SEND_FLAG gucFlags&BIT(SEN) #define SET_SEND_FLAG gucFlags|=BIT(SEN) #define CLEAR_SEND_FLAG gucFlags&=~BIT(SEN) #define TEST_CHANGE_FLAG gucFlags&BIT(CHA) #define SET_CHANGE_FLAG gucFlags|=BIT(CHA) #define CLEAR_CHANGE_FLAG gucFlags&=~BIT(CHA) #define TEST_UPDATE_FLAG gucFlags&BIT(UPD) #define SET_UPDATE_FLAG gucFlags|=BIT(UPD) #define CLEAR_UPDATE_FLAG gucFlags&=~BIT(UPD) Whichever way you choose, stay with 8-bit variable as the holders for flags. HTH All the best for now, John At 21:13 05/07/2007, you wrote: >couldn't you simply say > >#if NROFFLAGS<17 > >Unsigned int uiFlags; > >#else > >Unsigned long uiFlags; >#endif > >Albert > > >-----Original Message----- >From: Jaspers, Ton [mailto:t.jaspers@cpseurope.com] >Sent: Friday, 6 July 2007 12:45 a.m. >To: Discussion list for ICCAVR and ICCtiny >Users. You do NOT need to subscribeto icc-announce if you are a member of this. >Subject: RE: [Icc-avr] check for adequately nr. of bits > >I don't think it is a linker issue. It is a >coding issue. You could try to use teh pre-processor with something like this: > > #include > > #define NROFFLAGS 17 > > #if (1<<(NROFFLAGS-1)) > UINT_MAX > ERROR ?VALUE TO SMALL? > #endif > >Mind you, I have not tried it. > >Cheers, >Ton > > >---------- >From: icc-avr-bounces@imagecraft.com >[mailto:icc-avr-bounces@imagecraft.com] On Behalf Of Steven Lose >Sent: donderdag 5 juli 2007 12:59 >To: Discussion list for ICCAVR and ICCtiny >Users. You do NOT need tosubscribeto icc-announce if you are a member of this. >Subject: [Icc-avr] check for adequately nr. of bits > >Hi. > > > >I want to make the linker check that a variable >is defined big enough, but don?t know how. > > > >Basically I need something that tells me how >many bits there is in a variable so I can check it up against a defined value. > > > >#define NROFFLAGS 17 > > > >Unsigned int uiFlags; > > > >#if NROFFLAGS > NROFBITS(uiFlags) > > ERROR ?VALUE TO SMALL? > >#endif > > > >Is it possible to do so? (if it had been in code >I would just use (sizeof(uiFlags)*8) ) > >And if yes, what is the right way to do it? > > > >Med venlig hilsen / Best regards / mit freundlichen Gr??en > >EC POWER A/S > >Steven Lose > >Software Ingeni?r > >Tlf.: +45 87434100 > >Direkte tlf. +45 58286608 > >Email: sl@ecpower.dk > >www.ecpower.dk > > > >_______________________________________________ >Icc-avr mailing list >Icc-avr@imagecraft.com >http://dragonsgate.net/mailman/listinfo/icc-avr -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20070705/abc9832f/attachment-0001.html From sl at ecpower.dk Thu Jul 5 14:08:28 2007 From: sl at ecpower.dk (Steven Lose) Date: Thu Jul 5 14:19:12 2007 Subject: SV: [Icc-avr] check for adequately nr. of bits References: <7B0EB27CF1CC93439B5CFB7526E5D74C45D932@mickey.PBNV.local> Message-ID: <072D96786BFC014AAEBA9EB07A8070EA22F9E9@seattle.ecpower.dk> Hi Ton. It does not check the actual value defined; only one define against another define. Cheers Med venlig hilsen / Best regards / mit freundlichen Gr??en EC POWER A/S Steven Lose Software Ingeni?r Tlf.: +45 87434100 Direkte tlf. +45 58286608 Email: sl@ecpower.dk www.ecpower.dk ________________________________ Fra: icc-avr-bounces@imagecraft.com [mailto:icc-avr-bounces@imagecraft.com] P? vegne af Jaspers, Ton Sendt: 5. juli 2007 14:45 Til: Discussion list for ICCAVR and ICCtiny Users. You do NOT need to subscribeto icc-announce if you are a member of this. Emne: RE: [Icc-avr] check for adequately nr. of bits I don't think it is a linker issue. It is a coding issue. You could try to use teh pre-processor with something like this: #include #define NROFFLAGS 17 #if (1<<(NROFFLAGS-1)) > UINT_MAX ERROR "VALUE TO SMALL" #endif Mind you, I have not tried it. Cheers, Ton ________________________________ From: icc-avr-bounces@imagecraft.com [mailto:icc-avr-bounces@imagecraft.com] On Behalf Of Steven Lose Sent: donderdag 5 juli 2007 12:59 To: Discussion list for ICCAVR and ICCtiny Users. You do NOT need tosubscribeto icc-announce if you are a member of this. Subject: [Icc-avr] check for adequately nr. of bits Hi. I want to make the linker check that a variable is defined big enough, but don't know how. Basically I need something that tells me how many bits there is in a variable so I can check it up against a defined value. #define NROFFLAGS 17 Unsigned int uiFlags; #if NROFFLAGS > NROFBITS(uiFlags) ERROR "VALUE TO SMALL" #endif Is it possible to do so? (if it had been in code I would just use (sizeof(uiFlags)*8) ) And if yes, what is the right way to do it? Med venlig hilsen / Best regards / mit freundlichen Gr??en EC POWER A/S Steven Lose Software Ingeni?r Tlf.: +45 87434100 Direkte tlf. +45 58286608 Email: sl@ecpower.dk www.ecpower.dk -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20070705/cd59464c/attachment.html From sl at ecpower.dk Thu Jul 5 14:10:01 2007 From: sl at ecpower.dk (Steven Lose) Date: Thu Jul 5 14:20:44 2007 Subject: SV: [Icc-avr] check for adequately nr. of bits References: Message-ID: <072D96786BFC014AAEBA9EB07A8070EA22F9EA@seattle.ecpower.dk> Yes, but then someone will try and make 33 flags. ;o) Med venlig hilsen / Best regards / mit freundlichen Gr??en EC POWER A/S Steven Lose Software Ingeni?r Tlf.: +45 87434100 Direkte tlf. +45 58286608 Email: sl@ecpower.dk www.ecpower.dk ________________________________ Fra: icc-avr-bounces@imagecraft.com [mailto:icc-avr-bounces@imagecraft.com] P? vegne af Albert van Veen Sendt: 5. juli 2007 22:13 Til: Discussion list for ICCAVR and ICCtiny Users. You do NOT needtosubscribeto icc-announce if you are a member of this. Emne: RE: [Icc-avr] check for adequately nr. of bits couldn't you simply say #if NROFFLAGS<17 Unsigned int uiFlags; #else Unsignedlong uiFlags; #endif Albert -----Original Message----- From: Jaspers, Ton [mailto:t.jaspers@cpseurope.com] Sent: Friday, 6 July 2007 12:45 a.m. To: Discussion list for ICCAVR and ICCtiny Users. You do NOT need to subscribeto icc-announce if you are a member of this. Subject: RE: [Icc-avr] check for adequately nr. of bits I don't think it is a linker issue. It is a coding issue. You could try to use teh pre-processor with something like this: #include #define NROFFLAGS 17 #if (1<<(NROFFLAGS-1)) > UINT_MAX ERROR "VALUE TO SMALL" #endif Mind you, I have not tried it. Cheers, Ton ________________________________ From: icc-avr-bounces@imagecraft.com [mailto:icc-avr-bounces@imagecraft.com] On Behalf Of Steven Lose Sent: donderdag 5 juli 2007 12:59 To: Discussion list for ICCAVR and ICCtiny Users. You do NOT need tosubscribeto icc-announce if you are a member of this. Subject: [Icc-avr] check for adequately nr. of bits Hi. I want to make the linker check that a variable is defined big enough, but don't know how. Basically I need something that tells me how many bits there is in a variable so I can check it up against a defined value. #define NROFFLAGS 17 Unsigned int uiFlags; #if NROFFLAGS > NROFBITS(uiFlags) ERROR "VALUE TO SMALL" #endif Is it possible to do so? (if it had been in code I would just use (sizeof(uiFlags)*8) ) And if yes, what is the right way to do it? Med venlig hilsen / Best regards / mit freundlichen Gr??en EC POWER A/S Steven Lose Software Ingeni?r Tlf.: +45 87434100 Direkte tlf. +45 58286608 Email: sl@ecpower.dk www.ecpower.dk -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20070705/4519533c/attachment-0001.html From sl at ecpower.dk Thu Jul 5 14:30:48 2007 From: sl at ecpower.dk (Steven Lose) Date: Thu Jul 5 14:41:30 2007 Subject: SV: [Icc-avr] check for adequately nr. of bits References: <7B0EB27CF1CC93439B5CFB7526E5D74C45D932@mickey.PBNV.local> Message-ID: <072D96786BFC014AAEBA9EB07A8070EA22F9EB@seattle.ecpower.dk> Hi John. Alright, it's not that I use more than 8 flags at the moment, but I thought that at some point in time someone may in the other module raise the defined nr. that in this module is the reason for the nr. of flags needed. And then I have a memory leak. So the easiest way is only to accept inputs < 8 for the flag function. And then hope that it will become very clear that more space is needed when the SW change does not work. But... An error message would be so nice. Thanks. Med venlig hilsen / Best regards / mit freundlichen Gr??en EC POWER A/S Steven Lose Software Ingeni?r Tlf.: +45 87434100 Direkte tlf. +45 58286608 Email: sl@ecpower.dk www.ecpower.dk ________________________________ Fra: icc-avr-bounces@imagecraft.com [mailto:icc-avr-bounces@imagecraft.com] P? vegne af John Baraclough Sendt: 5. juli 2007 23:00 Til: Discussion list for ICCAVR and ICCtiny Users. You do NOT need tosubscribe to icc-announce if you are a member of this. Emne: RE: [Icc-avr] check for adequately nr. of bits You could indeed, but it would be very unwise. Single bit flags should always be stored in 8-bit variables, otherwise there is a very large overhead in setting, clearing or testing any flag. This is the way I define flag macros for fastest execution: #include #define SCR_BIT 0 #define RUN_BIT 1 #define SEN_BIT 2 #define CHA_BIT 3 #define UPD_BIT 4 // Flow control flags. #define TEST_SCREEN_FLAG gucFlags&BIT(SCR) #define SET_SCREEN_FLAG gucFlags|=BIT(SCR) #define CLEAR_SCREEN_FLAG gucFlags&=~BIT(SCR) #define TEST_RUN_FLAG gucFlags&BIT(RUN) #define SET_RUN_FLAG gucFlags|=BIT(RUN) #define CLEAR_RUN_FLAG gucFlags&=~BIT(RUN) #define TEST_SEND_FLAG gucFlags&BIT(SEN) #define SET_SEND_FLAG gucFlags|=BIT(SEN) #define CLEAR_SEND_FLAG gucFlags&=~BIT(SEN) #define TEST_CHANGE_FLAG gucFlags&BIT(CHA) #define SET_CHANGE_FLAG gucFlags|=BIT(CHA) #define CLEAR_CHANGE_FLAG gucFlags&=~BIT(CHA) #define TEST_UPDATE_FLAG gucFlags&BIT(UPD) #define SET_UPDATE_FLAG gucFlags|=BIT(UPD) #define CLEAR_UPDATE_FLAG gucFlags&=~BIT(UPD) Whichever way you choose, stay with 8-bit variable as the holders for flags. HTH All the best for now, John At 21:13 05/07/2007, you wrote: couldn't you simply say #if NROFFLAGS<17 Unsigned int uiFlags; #else Unsigned long uiFlags; #endif Albert -----Original Message----- From: Jaspers, Ton [ mailto:t.jaspers@cpseurope.com ] Sent: Friday, 6 July 2007 12:45 a.m. To: Discussion list for ICCAVR and ICCtiny Users. You do NOT need to subscribeto icc-announce if you are a member of this. Subject: RE: [Icc-avr] check for adequately nr. of bits I don't think it is a linker issue. It is a coding issue. You could try to use teh pre-processor with something like this: #include #define NROFFLAGS 17 #if (1<<(NROFFLAGS-1)) > UINT_MAX ERROR "VALUE TO SMALL" #endif Mind you, I have not tried it. Cheers, Ton ________________________________ From: icc-avr-bounces@imagecraft.com [ mailto:icc-avr-bounces@imagecraft.com ] On Behalf Of Steven Lose Sent: donderdag 5 juli 2007 12:59 To: Discussion list for ICCAVR and ICCtiny Users. You do NOT need tosubscribeto icc-announce if you are a member of this. Subject: [Icc-avr] check for adequately nr. of bits Hi. I want to make the linker check that a variable is defined big enough, but don't know how. Basically I need something that tells me how many bits there is in a variable so I can check it up against a defined value. #define NROFFLAGS 17 Unsigned int uiFlags; #if NROFFLAGS > NROFBITS(uiFlags) ERROR "VALUE TO SMALL" #endif Is it possible to do so? (if it had been in code I would just use (sizeof(uiFlags)*8) ) And if yes, what is the right way to do it? Med venlig hilsen / Best regards / mit freundlichen Gr??en EC POWER A/S Steven Lose Software Ingeni?r Tlf.: +45 87434100 Direkte tlf. +45 58286608 Email: sl@ecpower.dk www.ecpower.dk _______________________________________________ Icc-avr mailing list Icc-avr@imagecraft.com http://dragonsgate.net/mailman/listinfo/icc-avr -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20070705/234bbba4/attachment-0001.html From albert.vanveen at pertronic.co.nz Thu Jul 5 16:13:43 2007 From: albert.vanveen at pertronic.co.nz (Albert van Veen) Date: Thu Jul 5 16:25:01 2007 Subject: [Icc-avr] check for adequately nr. of bits In-Reply-To: Message-ID: I totally agree and would always do it like that; I was just responding directly to the question asked. BTW: shouldn't you be going to bed on your side of the world? Albert. -----Original Message----- From: John Baraclough [mailto:j_baraclough@zetnet.co.uk] Sent: Friday, 6 July 2007 9:00 a.m. To: Discussion list for ICCAVR and ICCtiny Users. You do NOT need tosubscribe to icc-announce if you are a member of this. Subject: RE: [Icc-avr] check for adequately nr. of bits You could indeed, but it would be very unwise. Single bit flags should always be stored in 8-bit variables, otherwise there is a very large overhead in setting, clearing or testing any flag. This is the way I define flag macros for fastest execution: #include #define SCR_BIT 0 #define RUN_BIT 1 #define SEN_BIT 2 #define CHA_BIT 3 #define UPD_BIT 4 // Flow control flags. #define TEST_SCREEN_FLAG gucFlags&BIT(SCR) #define SET_SCREEN_FLAG gucFlags|=BIT(SCR) #define CLEAR_SCREEN_FLAG gucFlags&=~BIT(SCR) #define TEST_RUN_FLAG gucFlags&BIT(RUN) #define SET_RUN_FLAG gucFlags|=BIT(RUN) #define CLEAR_RUN_FLAG gucFlags&=~BIT(RUN) #define TEST_SEND_FLAG gucFlags&BIT(SEN) #define SET_SEND_FLAG gucFlags|=BIT(SEN) #define CLEAR_SEND_FLAG gucFlags&=~BIT(SEN) #define TEST_CHANGE_FLAG gucFlags&BIT(CHA) #define SET_CHANGE_FLAG gucFlags|=BIT(CHA) #define CLEAR_CHANGE_FLAG gucFlags&=~BIT(CHA) #define TEST_UPDATE_FLAG gucFlags&BIT(UPD) #define SET_UPDATE_FLAG gucFlags|=BIT(UPD) #define CLEAR_UPDATE_FLAG gucFlags&=~BIT(UPD) Whichever way you choose, stay with 8-bit variable as the holders for flags. HTH All the best for now, John At 21:13 05/07/2007, you wrote: couldn't you simply say #if NROFFLAGS<17 Unsigned int uiFlags; #else Unsigned long uiFlags; #endif Albert -----Original Message----- From: Jaspers, Ton [ mailto:t.jaspers@cpseurope.com] Sent: Friday, 6 July 2007 12:45 a.m. To: Discussion list for ICCAVR and ICCtiny Users. You do NOT need to subscribeto icc-announce if you are a member of this. Subject: RE: [Icc-avr] check for adequately nr. of bits I don't think it is a linker issue. It is a coding issue. You could try to use teh pre-processor with something like this: #include #define NROFFLAGS 17 #if (1<<(NROFFLAGS-1)) > UINT_MAX ERROR ?VALUE TO SMALL? #endif Mind you, I have not tried it. Cheers, Ton ------------------------------------------------------------------------ From: icc-avr-bounces@imagecraft.com [ mailto:icc-avr-bounces@imagecraft.com] On Behalf Of Steven Lose Sent: donderdag 5 juli 2007 12:59 To: Discussion list for ICCAVR and ICCtiny Users. You do NOT need tosubscribeto icc-announce if you are a member of this. Subject: [Icc-avr] check for adequately nr. of bits Hi. I want to make the linker check that a variable is defined big enough, but don?t know how. Basically I need something that tells me how many bits there is in a variable so I can check it up against a defined value. #define NROFFLAGS 17 Unsigned int uiFlags; #if NROFFLAGS > NROFBITS(uiFlags) ERROR ?VALUE TO SMALL? #endif Is it possible to do so? (if it had been in code I would just use (sizeof(uiFlags)*8) ) And if yes, what is the right way to do it? Med venlig hilsen / Best regards / mit freundlichen Gr??en EC POWER A/S Steven Lose Software Ingeni?r Tlf.: +45 87434100 Direkte tlf. +45 58286608 Email: sl@ecpower.dk www.ecpower.dk _______________________________________________ Icc-avr mailing list Icc-avr@imagecraft.com http://dragonsgate.net/mailman/listinfo/icc-avr -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20070706/d9840df3/attachment.html From mcreations at fibertel.com.ar Thu Jul 5 17:56:54 2007 From: mcreations at fibertel.com.ar (Ing. Abner Chamson) Date: Thu Jul 5 18:08:03 2007 Subject: [Icc-avr] check for adequately nr. of bits In-Reply-To: <072D96786BFC014AAEBA9EB07A8070EA22F9EB@seattle.ecpower.dk> References: <7B0EB27CF1CC93439B5CFB7526E5D74C45D932@mickey.PBNV.local> <072D96786BFC014AAEBA9EB07A8070EA22F9EB@seattle.ecpower.dk> Message-ID: <086e01c7bf68$8c66cd80$a5346880$@com.ar> Hi, I?m sort of a newbie in C. Not a newbie perhaps in time, but yes in the fact that I program occasionnaly This discussion coincided for me with the start of a project where I know I?ll have lots of flags, and wanted something to manage them. Everytime I started a project I thougth ?well, 8 flags will be enough? and declared unsigned char ucflags #define FLAG1 BIT(0) then, each time i wanted to set, reset or test this flag I worked on the bit(0) of ucflags but when I had more than 8 flags, then I have to create another char named ucflags2 and each time I have to work on a specific flag I have to remember if it corresponds to ucflags or ucflags2 viewing this list, I realized I had to define 3 or 4 Macros for each flag: SET, CLEAR, TOGGLE and TEST As for the container for those flags, I thought using an array of unsigned char whose length would be the ceiling of NR_OF_FLAGS / 8 Then each flag is represented with two parameters, the group to which it corresponds and the position in this byte This is a sample code I did to test this: ******************************** unsigned char ucflags[2]; #define FLAG1 0,0 #define FLAG2 0,1 #define FLAG3 0,2 #define FLAG4 0,3 #define FLAG5 0,4 #define FLAG6 0,5 #define FLAG7 0,6 #define FLAG8 0,7 #define FLAG9 1,0 #define FLAG10 1,1 #define FLAG11 1,2 #define FLAG12 1,3 #define FLAG13 1,4 #define FLAG14 1,5 #define FLAG15 1,6 #define _SET(x,y) (ucflags[x] |= 1< www.ecpower.dk _____ Fra: icc-avr-bounces@imagecraft.com [mailto:icc-avr-bounces@imagecraft.com] P? vegne af John Baraclough Sendt: 5. juli 2007 23:00 Til: Discussion list for ICCAVR and ICCtiny Users. You do NOT need tosubscribe to icc-announce if you are a member of this. Emne: RE: [Icc-avr] check for adequately nr. of bits You could indeed, but it would be very unwise. Single bit flags should always be stored in 8-bit variables, otherwise there is a very large overhead in setting, clearing or testing any flag. This is the way I define flag macros for fastest execution: #include #define SCR_BIT 0 #define RUN_BIT 1 #define SEN_BIT 2 #define CHA_BIT 3 #define UPD_BIT 4 // Flow control flags. #define TEST_SCREEN_FLAG gucFlags&BIT(SCR) #define SET_SCREEN_FLAG gucFlags|=BIT(SCR) #define CLEAR_SCREEN_FLAG gucFlags&=~BIT(SCR) #define TEST_RUN_FLAG gucFlags&BIT(RUN) #define SET_RUN_FLAG gucFlags|=BIT(RUN) #define CLEAR_RUN_FLAG gucFlags&=~BIT(RUN) #define TEST_SEND_FLAG gucFlags&BIT(SEN) #define SET_SEND_FLAG gucFlags|=BIT(SEN) #define CLEAR_SEND_FLAG gucFlags&=~BIT(SEN) #define TEST_CHANGE_FLAG gucFlags&BIT(CHA) #define SET_CHANGE_FLAG gucFlags|=BIT(CHA) #define CLEAR_CHANGE_FLAG gucFlags&=~BIT(CHA) #define TEST_UPDATE_FLAG gucFlags&BIT(UPD) #define SET_UPDATE_FLAG gucFlags|=BIT(UPD) #define CLEAR_UPDATE_FLAG gucFlags&=~BIT(UPD) Whichever way you choose, stay with 8-bit variable as the holders for flags. HTH All the best for now, John At 21:13 05/07/2007, you wrote: couldn't you simply say #if NROFFLAGS<17 Unsigned int uiFlags; #else Unsigned long uiFlags; #endif Albert -----Original Message----- From: Jaspers, Ton [ mailto:t.jaspers@cpseurope.com ] Sent: Friday, 6 July 2007 12:45 a.m. To: Discussion list for ICCAVR and ICCtiny Users. You do NOT need to subscribeto icc-announce if you are a member of this. Subject: RE: [Icc-avr] check for adequately nr. of bits I don't think it is a linker issue. It is a coding issue. You could try to use teh pre-processor with something like this: #include #define NROFFLAGS 17 #if (1<<(NROFFLAGS-1)) > UINT_MAX ERROR ?VALUE TO SMALL? #endif Mind you, I have not tried it. Cheers, Ton _____ From: icc-avr-bounces@imagecraft.com [ mailto:icc-avr-bounces@imagecraft.com] On Behalf Of Steven Lose Sent: donderdag 5 juli 2007 12:59 To: Discussion list for ICCAVR and ICCtiny Users. You do NOT need tosubscribeto icc-announce if you are a member of this. Subject: [Icc-avr] check for adequately nr. of bits Hi. I want to make the linker check that a variable is defined big enough, but don?t know how. Basically I need something that tells me how many bits there is in a variable so I can check it up against a defined value. #define NROFFLAGS 17 Unsigned int uiFlags; #if NROFFLAGS > NROFBITS(uiFlags) ERROR ?VALUE TO SMALL? #endif Is it possible to do so? (if it had been in code I would just use (sizeof(uiFlags)*8) ) And if yes, what is the right way to do it? Med venlig hilsen / Best regards / mit freundlichen Gr??en EC POWER A/S Steven Lose Software Ingeni?r Tlf.: +45 87434100 Direkte tlf. +45 58286608 Email: sl@ecpower.dk www.ecpower.dk _______________________________________________ Icc-avr mailing list Icc-avr@imagecraft.com http://dragonsgate.net/mailman/listinfo/icc-avr -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20070705/d8569293/attachment-0001.html From albert.vanveen at pertronic.co.nz Thu Jul 5 20:40:45 2007 From: albert.vanveen at pertronic.co.nz (Albert van Veen) Date: Thu Jul 5 22:52:18 2007 Subject: [Icc-avr] check for adequately nr. of bits In-Reply-To: <086e01c7bf68$8c66cd80$a5346880$@com.ar> Message-ID: Well, the way I have really always done it, and has been compatible over all compilers I've used: typedef struct { unsigned b0: 1; unsigned b1: 1; unsigned b2: 1; unsigned b3: 1; unsigned b4: 1; unsigned b5: 1; unsigned b6: 1; unsigned b7: 1; } Tbits; Tbits flags1,flags2,latch_flags,defect_flags,extra_flags; // as many as needed, named or numbered #define kiwi flags1.0 #define piezo_fast flags1.1 #define new_tick flags1.2 #define walk_wait flags1.3 #define in_24hr_test flags1.4 #define wait_for_ext flags1.5 #define keyclick flags1.6 #define pressed flags1.7 // any button #define interlock1 flags2.0 // switches/ext.interl. #define interlock2 flags2.1 // mains / e2 #define combi flags2.2 #define tmp_flag flags2.3 // local only #define in_ALA flags2.3 // (in zone a/d) #define recheck flags2.4 // status of switches (MUX1) #define flash flags2.5 // global fire led (Aus) #define real_alarm flags2.6 // [ to cancel #define test_active flags2.7 // test alarm ] #define pcb_defect_latch latch_flags.0 /* these latch */ #define leds_defect_latch latch_flags.1 #define door_defect_latch latch_flags.2 #define extern_def_latch latch_flags.3 #define spr_latch latch_flags.4 // NZ #define auxm_latch latch_flags.4 // Aus #define earth_defect_latch latch_flags.5 #define battery_latch latch_flags.6 #define charger_latch latch_flags.7 etc. etc. Easy to set, clear, check: if (in_ALA) recheck= true; AND VERY READABLE TOO !! Greetings, Albert. -----Original Message----- From: Ing. Abner Chamson [mailto:mcreations@fibertel.com.ar] Sent: Friday, 6 July 2007 12:57 p.m. To: 'Discussion list for ICCAVR and ICCtiny Users. You do NOT need to subscribe to icc-announce if you are a member of this.' Subject: RE: [Icc-avr] check for adequately nr. of bits Hi, I?m sort of a newbie in C. Not a newbie perhaps in time, but yes in the fact that I program occasionnaly This discussion coincided for me with the start of a project where I know I?ll have lots of flags, and wanted something to manage them. Everytime I started a project I thougth ?well, 8 flags will be enough? and declared unsigned char ucflags #define FLAG1 BIT(0) then, each time i wanted to set, reset or test this flag I worked on the bit(0) of ucflags but when I had more than 8 flags, then I have to create another char named ucflags2 and each time I have to work on a specific flag I have to remember if it corresponds to ucflags or ucflags2 viewing this list, I realized I had to define 3 or 4 Macros for each flag: SET, CLEAR, TOGGLE and TEST As for the container for those flags, I thought using an array of unsigned char whose length would be the ceiling of NR_OF_FLAGS / 8 Then each flag is represented with two parameters, the group to which it corresponds and the position in this byte This is a sample code I did to test this: ******************************** unsigned char ucflags[2]; #define FLAG1 0,0 #define FLAG2 0,1 #define FLAG3 0,2 #define FLAG4 0,3 #define FLAG5 0,4 #define FLAG6 0,5 #define FLAG7 0,6 #define FLAG8 0,7 #define FLAG9 1,0 #define FLAG10 1,1 #define FLAG11 1,2 #define FLAG12 1,3 #define FLAG13 1,4 #define FLAG14 1,5 #define FLAG15 1,6 #define _SET(x,y) (ucflags[x] |= 1< #define SCR_BIT 0 #define RUN_BIT 1 #define SEN_BIT 2 #define CHA_BIT 3 #define UPD_BIT 4 // Flow control flags. #define TEST_SCREEN_FLAG gucFlags&BIT(SCR) #define SET_SCREEN_FLAG gucFlags|=BIT(SCR) #define CLEAR_SCREEN_FLAG gucFlags&=~BIT(SCR) #define TEST_RUN_FLAG gucFlags&BIT(RUN) #define SET_RUN_FLAG gucFlags|=BIT(RUN) #define CLEAR_RUN_FLAG gucFlags&=~BIT(RUN) #define TEST_SEND_FLAG gucFlags&BIT(SEN) #define SET_SEND_FLAG gucFlags|=BIT(SEN) #define CLEAR_SEND_FLAG gucFlags&=~BIT(SEN) #define TEST_CHANGE_FLAG gucFlags&BIT(CHA) #define SET_CHANGE_FLAG gucFlags|=BIT(CHA) #define CLEAR_CHANGE_FLAG gucFlags&=~BIT(CHA) #define TEST_UPDATE_FLAG gucFlags&BIT(UPD) #define SET_UPDATE_FLAG gucFlags|=BIT(UPD) #define CLEAR_UPDATE_FLAG gucFlags&=~BIT(UPD) Whichever way you choose, stay with 8-bit variable as the holders for flags. HTH All the best for now, John At 21:13 05/07/2007, you wrote: couldn't you simply say #if NROFFLAGS<17 Unsigned int uiFlags; #else Unsigned long uiFlags; #endif Albert -----Original Message----- From: Jaspers, Ton [ mailto:t.jaspers@cpseurope.com] Sent: Friday, 6 July 2007 12:45 a.m. To: Discussion list for ICCAVR and ICCtiny Users. You do NOT need to subscribeto icc-announce if you are a member of this. Subject: RE: [Icc-avr] check for adequately nr. of bits I don't think it is a linker issue. It is a coding issue. You could try to use teh pre-processor with something like this: #include #define NROFFLAGS 17 #if (1<<(NROFFLAGS-1)) > UINT_MAX ERROR ?VALUE TO SMALL? #endif Mind you, I have not tried it. Cheers, Ton ---------------------------------------------------------------------------- -- From: icc-avr-bounces@imagecraft.com [ mailto:icc-avr-bounces@imagecraft.com] On Behalf Of Steven Lose Sent: donderdag 5 juli 2007 12:59 To: Discussion list for ICCAVR and ICCtiny Users. You do NOT need tosubscribeto icc-announce if you are a member of this. Subject: [Icc-avr] check for adequately nr. of bits Hi. I want to make the linker check that a variable is defined big enough, but don?t know how. Basically I need something that tells me how many bits there is in a variable so I can check it up against a defined value. #define NROFFLAGS 17 Unsigned int uiFlags; #if NROFFLAGS > NROFBITS(uiFlags) ERROR ?VALUE TO SMALL? #endif Is it possible to do so? (if it had been in code I would just use (sizeof(uiFlags)*8) ) And if yes, what is the right way to do it? Med venlig hilsen / Best regards / mit freundlichen Gr??en EC POWER A/S Steven Lose Software Ingeni?r Tlf.: +45 87434100 Direkte tlf. +45 58286608 Email: sl@ecpower.dk www.ecpower.dk _______________________________________________ Icc-avr mailing list Icc-avr@imagecraft.com http://dragonsgate.net/mailman/listinfo/icc-avr -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20070706/e0b319b9/attachment-0001.html From t.jaspers at cpseurope.com Fri Jul 6 00:40:23 2007 From: t.jaspers at cpseurope.com (Jaspers, Ton) Date: Fri Jul 6 00:51:08 2007 Subject: [Icc-avr] check for adequately nr. of bits In-Reply-To: <072D96786BFC014AAEBA9EB07A8070EA22F9E9@seattle.ecpower.dk> Message-ID: <7B0EB27CF1CC93439B5CFB7526E5D74C45D956@mickey.PBNV.local> Steven, What I would do is avoid the problem all together and leave it to the compiler: typedef struct { unsigned aflag:1; unsigned anotherflag:1; unsigned brflag:1; unsigned cflag:1; unsigned dflag:1; unsigned eflag:1; unsigned fflag:1; unsigned gflag:1; unsigned hflag:1; unsigned iflag:1; unsigned jflag:1; unsigned kflag:1; unsigned lflag:1; unsigned mflag:1; unsigned nflag:1; unsigned oflag:1; unsigned pflag:1; } flag_t ; #define SETFLAG(x) (flag.(x)=1) #define CLRFLAG(x) (flag.(x)=0) #define TSTFLAG(x) (flag.(x)) flag_t flag ; ..... SETFLAG(aflag) ; .... if ( TSTFLAG(aflag) ) ..... The compiler should optimise this in to the best solution, bytes or words or what ever. Cheers, Ton ________________________________ From: icc-avr-bounces@imagecraft.com [mailto:icc-avr-bounces@imagecraft.com] On Behalf Of Steven Lose Sent: donderdag 5 juli 2007 23:08 To: Discussion list for ICCAVR and ICCtiny Users. You do NOT need tosubscribeto icc-announce if you are a member of this. Subject: SV: [Icc-avr] check for adequately nr. of bits Hi Ton. It does not check the actual value defined; only one define against another define. Cheers Med venlig hilsen / Best regards / mit freundlichen Gr??en EC POWER A/S Steven Lose Software Ingeni?r Tlf.: +45 87434100 Direkte tlf. +45 58286608 Email: sl@ecpower.dk www.ecpower.dk ________________________________ Fra: icc-avr-bounces@imagecraft.com [mailto:icc-avr-bounces@imagecraft.com] P? vegne af Jaspers, Ton Sendt: 5. juli 2007 14:45 Til: Discussion list for ICCAVR and ICCtiny Users. You do NOT need to subscribeto icc-announce if you are a member of this. Emne: RE: [Icc-avr] check for adequately nr. of bits I don't think it is a linker issue. It is a coding issue. You could try to use teh pre-processor with something like this: #include #define NROFFLAGS 17 #if (1<<(NROFFLAGS-1)) > UINT_MAX ERROR "VALUE TO SMALL" #endif Mind you, I have not tried it. Cheers, Ton ________________________________ From: icc-avr-bounces@imagecraft.com [mailto:icc-avr-bounces@imagecraft.com] On Behalf Of Steven Lose Sent: donderdag 5 juli 2007 12:59 To: Discussion list for ICCAVR and ICCtiny Users. You do NOT need tosubscribeto icc-announce if you are a member of this. Subject: [Icc-avr] check for adequately nr. of bits Hi. I want to make the linker check that a variable is defined big enough, but don't know how. Basically I need something that tells me how many bits there is in a variable so I can check it up against a defined value. #define NROFFLAGS 17 Unsigned int uiFlags; #if NROFFLAGS > NROFBITS(uiFlags) ERROR "VALUE TO SMALL" #endif Is it possible to do so? (if it had been in code I would just use (sizeof(uiFlags)*8) ) And if yes, what is the right way to do it? Med venlig hilsen / Best regards / mit freundlichen Gr??en EC POWER A/S Steven Lose Software Ingeni?r Tlf.: +45 87434100 Direkte tlf. +45 58286608 Email: sl@ecpower.dk www.ecpower.dk -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20070706/48295f5a/attachment-0001.html From sl at ecpower.dk Fri Jul 6 00:10:35 2007 From: sl at ecpower.dk (Steven Lose) Date: Fri Jul 6 01:43:14 2007 Subject: SV: [Icc-avr] check for adequately nr. of bits References: Message-ID: <072D96786BFC014AAEBA9EB07A8070EA22F9F3@seattle.ecpower.dk> Thanks every one for all the inputs. In this particular case, I'll make sure that it is not possible to make a memory leak. No clever warning but can't have it all. Med venlig hilsen / Best regards / mit freundlichen Gr??en EC POWER A/S Steven Lose Software Ingeni?r Tlf.: +45 87434100 Direkte tlf. +45 58286608 Email: sl@ecpower.dk www.ecpower.dk ________________________________ Fra: icc-avr-bounces@imagecraft.com [mailto:icc-avr-bounces@imagecraft.com] P? vegne af Albert van Veen Sendt: 6. juli 2007 05:41 Til: Discussion list for ICCAVR and ICCtiny Users. You do NOT needtosubscribeto icc-announce if you are a member of this. Emne: RE: [Icc-avr] check for adequately nr. of bits Well, the way I have really always done it, and has been compatible over all compilers I've used: typedef struct { unsigned b0: 1; unsigned b1: 1; unsigned b2: 1; unsigned b3: 1; unsigned b4: 1; unsigned b5: 1; unsigned b6: 1; unsigned b7: 1; } Tbits; Tbits flags1,flags2,latch_flags,defect_flags,extra_flags; // as many as needed, named or numbered #define kiwi flags1.0 #define piezo_fast flags1.1 #define new_tick flags1.2 #define walk_wait flags1.3 #define in_24hr_test flags1.4 #define wait_for_ext flags1.5 #define keyclick flags1.6 #define pressed flags1.7 // any button #define interlock1 flags2.0 // switches/ext.interl. #define interlock2 flags2.1 // mains / e2 #define combi flags2.2 #define tmp_flag flags2.3 // local only #define in_ALA flags2.3 // (in zone a/d) #define recheck flags2.4 // status of switches (MUX1) #define flash flags2.5 // global fire led (Aus) #define real_alarm flags2.6 // [ to cancel #define test_active flags2.7 // test alarm ] #define pcb_defect_latch latch_flags.0 /* these latch */ #define leds_defect_latch latch_flags.1 #define door_defect_latch latch_flags.2 #define extern_def_latch latch_flags.3 #define spr_latch latch_flags.4 // NZ #define auxm_latch latch_flags.4 // Aus #define earth_defect_latch latch_flags.5 #define battery_latch latch_flags.6 #define charger_latch latch_flags.7 etc. etc. Easy to set, clear, check: if (in_ALA) recheck= true; AND VERY READABLE TOO !! Greetings, Albert. -----Original Message----- From: Ing. Abner Chamson [mailto:mcreations@fibertel.com.ar] Sent: Friday, 6 July 2007 12:57 p.m. To: 'Discussion list for ICCAVR and ICCtiny Users. You do NOT need to subscribe to icc-announce if you are a member of this.' Subject: RE: [Icc-avr] check for adequately nr. of bits Hi, I'm sort of a newbie in C. Not a newbie perhaps in time, but yes in the fact that I program occasionnaly... This discussion coincided for me with the start of a project where I know I'll have lots of flags, and wanted something to manage them. Everytime I started a project I thougth "well, 8 flags will be enough" and declared unsigned char ucflags #define FLAG1 BIT(0) ... then, each time i wanted to set, reset or test this flag I worked on the bit(0) of ucflags but when I had more than 8 flags, then I have to create another char named ucflags2 and each time I have to work on a specific flag I have to remember if it corresponds to ucflags or ucflags2... viewing this list, I realized I had to define 3 or 4 Macros for each flag: SET, CLEAR, TOGGLE and TEST As for the container for those flags, I thought using an array of unsigned char whose length would be the ceiling of NR_OF_FLAGS / 8 Then each flag is represented with two parameters, the group to which it corresponds and the position in this byte This is a sample code I did to test this: ******************************** unsigned char ucflags[2]; #define FLAG1 0,0 #define FLAG2 0,1 #define FLAG3 0,2 #define FLAG4 0,3 #define FLAG5 0,4 #define FLAG6 0,5 #define FLAG7 0,6 #define FLAG8 0,7 #define FLAG9 1,0 #define FLAG10 1,1 #define FLAG11 1,2 #define FLAG12 1,3 #define FLAG13 1,4 #define FLAG14 1,5 #define FLAG15 1,6 #define _SET(x,y) (ucflags[x] |= 1< www.ecpower.dk ________________________________ Fra: icc-avr-bounces@imagecraft.com [mailto:icc-avr-bounces@imagecraft.com] P? vegne af John Baraclough Sendt: 5. juli 2007 23:00 Til: Discussion list for ICCAVR and ICCtiny Users. You do NOT need tosubscribe to icc-announce if you are a member of this. Emne: RE: [Icc-avr] check for adequately nr. of bits You could indeed, but it would be very unwise. Single bit flags should always be stored in 8-bit variables, otherwise there is a very large overhead in setting, clearing or testing any flag. This is the way I define flag macros for fastest execution: #include #define SCR_BIT 0 #define RUN_BIT 1 #define SEN_BIT 2 #define CHA_BIT 3 #define UPD_BIT 4 // Flow control flags. #define TEST_SCREEN_FLAG gucFlags&BIT(SCR) #define SET_SCREEN_FLAG gucFlags|=BIT(SCR) #define CLEAR_SCREEN_FLAG gucFlags&=~BIT(SCR) #define TEST_RUN_FLAG gucFlags&BIT(RUN) #define SET_RUN_FLAG gucFlags|=BIT(RUN) #define CLEAR_RUN_FLAG gucFlags&=~BIT(RUN) #define TEST_SEND_FLAG gucFlags&BIT(SEN) #define SET_SEND_FLAG gucFlags|=BIT(SEN) #define CLEAR_SEND_FLAG gucFlags&=~BIT(SEN) #define TEST_CHANGE_FLAG gucFlags&BIT(CHA) #define SET_CHANGE_FLAG gucFlags|=BIT(CHA) #define CLEAR_CHANGE_FLAG gucFlags&=~BIT(CHA) #define TEST_UPDATE_FLAG gucFlags&BIT(UPD) #define SET_UPDATE_FLAG gucFlags|=BIT(UPD) #define CLEAR_UPDATE_FLAG gucFlags&=~BIT(UPD) Whichever way you choose, stay with 8-bit variable as the holders for flags. HTH All the best for now, John At 21:13 05/07/2007, you wrote: couldn't you simply say #if NROFFLAGS<17 Unsigned int uiFlags; #else Unsigned long uiFlags; #endif Albert -----Original Message----- From: Jaspers, Ton [ mailto:t.jaspers@cpseurope.com ] Sent: Friday, 6 July 2007 12:45 a.m. To: Discussion list for ICCAVR and ICCtiny Users. You do NOT need to subscribeto icc-announce if you are a member of this. Subject: RE: [Icc-avr] check for adequately nr. of bits I don't think it is a linker issue. It is a coding issue. You could try to use teh pre-processor with something like this: #include #define NROFFLAGS 17 #if (1<<(NROFFLAGS-1)) > UINT_MAX ERROR "VALUE TO SMALL" #endif Mind you, I have not tried it. Cheers, Ton ________________________________ From: icc-avr-bounces@imagecraft.com [ mailto:icc-avr-bounces@imagecraft.com ] On Behalf Of Steven Lose Sent: donderdag 5 juli 2007 12:59 To: Discussion list for ICCAVR and ICCtiny Users. You do NOT need tosubscribeto icc-announce if you are a member of this. Subject: [Icc-avr] check for adequately nr. of bits Hi. I want to make the linker check that a variable is defined big enough, but don't know how. Basically I need something that tells me how many bits there is in a variable so I can check it up against a defined value. #define NROFFLAGS 17 Unsigned int uiFlags; #if NROFFLAGS > NROFBITS(uiFlags) ERROR "VALUE TO SMALL" #endif Is it possible to do so? (if it had been in code I would just use (sizeof(uiFlags)*8) ) And if yes, what is the right way to do it? Med venlig hilsen / Best regards / mit freundlichen Gr??en EC POWER A/S Steven Lose Software Ingeni?r Tlf.: +45 87434100 Direkte tlf. +45 58286608 Email: sl@ecpower.dk www.ecpower.dk _______________________________________________ Icc-avr mailing list Icc-avr@imagecraft.com http://dragonsgate.net/mailman/listinfo/icc-avr -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20070706/90e91b59/attachment-0001.html From sl at ecpower.dk Fri Jul 6 02:19:23 2007 From: sl at ecpower.dk (Steven Lose) Date: Fri Jul 6 02:30:06 2007 Subject: SV: [Icc-avr] check for adequately nr. of bits References: <7B0EB27CF1CC93439B5CFB7526E5D74C45D956@mickey.PBNV.local> Message-ID: <072D96786BFC014AAEBA9EB07A8070EA22FA10@seattle.ecpower.dk> Thanks Ton Med venlig hilsen / Best regards / mit freundlichen Gr??en EC POWER A/S Steven Lose Software Ingeni?r Tlf.: +45 87434100 Direkte tlf. +45 58286608 Email: sl@ecpower.dk www.ecpower.dk ________________________________ Fra: icc-avr-bounces@imagecraft.com [mailto:icc-avr-bounces@imagecraft.com] P? vegne af Jaspers, Ton Sendt: 6. juli 2007 09:40 Til: Discussion list for ICCAVR and ICCtiny Users. You do NOT need to subscribeto icc-announce if you are a member of this. Emne: RE: [Icc-avr] check for adequately nr. of bits Steven, What I would do is avoid the problem all together and leave it to the compiler: typedef struct { unsigned aflag:1; unsigned anotherflag:1; unsigned brflag:1; unsigned cflag:1; unsigned dflag:1; unsigned eflag:1; unsigned fflag:1; unsigned gflag:1; unsigned hflag:1; unsigned iflag:1; unsigned jflag:1; unsigned kflag:1; unsigned lflag:1; unsigned mflag:1; unsigned nflag:1; unsigned oflag:1; unsigned pflag:1; } flag_t ; #define SETFLAG(x) (flag.(x)=1) #define CLRFLAG(x) (flag.(x)=0) #define TSTFLAG(x) (flag.(x)) flag_t flag ; ..... SETFLAG(aflag) ; .... if ( TSTFLAG(aflag) ) ..... The compiler should optimise this in to the best solution, bytes or words or what ever. Cheers, Ton ________________________________ From: icc-avr-bounces@imagecraft.com [mailto:icc-avr-bounces@imagecraft.com] On Behalf Of Steven Lose Sent: donderdag 5 juli 2007 23:08 To: Discussion list for ICCAVR and ICCtiny Users. You do NOT need tosubscribeto icc-announce if you are a member of this. Subject: SV: [Icc-avr] check for adequately nr. of bits Hi Ton. It does not check the actual value defined; only one define against another define. Cheers Med venlig hilsen / Best regards / mit freundlichen Gr??en EC POWER A/S Steven Lose Software Ingeni?r Tlf.: +45 87434100 Direkte tlf. +45 58286608 Email: sl@ecpower.dk www.ecpower.dk ________________________________ Fra: icc-avr-bounces@imagecraft.com [mailto:icc-avr-bounces@imagecraft.com] P? vegne af Jaspers, Ton Sendt: 5. juli 2007 14:45 Til: Discussion list for ICCAVR and ICCtiny Users. You do NOT need to subscribeto icc-announce if you are a member of this. Emne: RE: [Icc-avr] check for adequately nr. of bits I don't think it is a linker issue. It is a coding issue. You could try to use teh pre-processor with something like this: #include #define NROFFLAGS 17 #if (1<<(NROFFLAGS-1)) > UINT_MAX ERROR "VALUE TO SMALL" #endif Mind you, I have not tried it. Cheers, Ton ________________________________ From: icc-avr-bounces@imagecraft.com [mailto:icc-avr-bounces@imagecraft.com] On Behalf Of Steven Lose Sent: donderdag 5 juli 2007 12:59 To: Discussion list for ICCAVR and ICCtiny Users. You do NOT need tosubscribeto icc-announce if you are a member of this. Subject: [Icc-avr] check for adequately nr. of bits Hi. I want to make the linker check that a variable is defined big enough, but don't know how. Basically I need something that tells me how many bits there is in a variable so I can check it up against a defined value. #define NROFFLAGS 17 Unsigned int uiFlags; #if NROFFLAGS > NROFBITS(uiFlags) ERROR "VALUE TO SMALL" #endif Is it possible to do so? (if it had been in code I would just use (sizeof(uiFlags)*8) ) And if yes, what is the right way to do it? Med venlig hilsen / Best regards / mit freundlichen Gr??en EC POWER A/S Steven Lose Software Ingeni?r Tlf.: +45 87434100 Direkte tlf. +45 58286608 Email: sl@ecpower.dk www.ecpower.dk -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20070706/1a34c6ef/attachment-0001.html From david_brown at hotpop.com Fri Jul 6 07:47:08 2007 From: david_brown at hotpop.com (David Brown) Date: Fri Jul 6 07:32:36 2007 Subject: [Icc-avr] Why does it do this? In-Reply-To: <200707040255.l642tpBD065217@dragonsgate2.imagecraft.com> References: <0MKpCa-1I5cGN1aQZ-0001ZP@mrelay.perfora.net> <200707040255.l642tpBD065217@dragonsgate2.imagecraft.com> Message-ID: <468E55EC.1060809@hotpop.com> Richard wrote: > That is the semantic of declaring an object inside a function. "Const" > just means not-modifiable but the lifetime of the object is still just > within the function, i.e. it needs to be on the stack. > There is, as far as I understand it, no requirement for a C compiler to actually implement limited lifetimes for local data, and there is certainly no requirement that the data be placed on the stack. The original code was: unsigned int foo( unsigned int *x){ const unsigned int y[1024] = {1,2,3,4,5,6,7}; return y[*x]; } There is absolutely nothing forcing a C compiler to put the array "y" on the stack. A smart compiler will treat the array exactly as though it was "static const", and therefore put it at a global fixed address, since that saves time and space. mvh., David From bobgardner at aol.com Fri Jul 6 08:42:48 2007 From: bobgardner at aol.com (bobgardner@aol.com) Date: Fri Jul 6 08:53:38 2007 Subject: [Icc-avr] Why does it do this? In-Reply-To: <468E55EC.1060809@hotpop.com> References: <0MKpCa-1I5cGN1aQZ-0001ZP@mrelay.perfora.net> <200707040255.l642tpBD065217@dragonsgate2.imagecraft.com> <468E55EC.1060809@hotpop.com> Message-ID: <8C98DFB70581A31-3A8-C8A@WEBMAIL-RA05.sysops.aol.com> There is absolutely nothing forcing a C compiler to put the array "y" on the stack. A smart compiler will treat the array exactly as though it was "static const", and therefore put it at a global fixed address, since that saves time and space.? ================================================= I've seen compiler ads that claim to adhere to an ANSI standard, but until this message I had never heard of a standard for 'smart compilers'. I assume this means that they make subtle changes in where to put variables as they attempt to outguess the carbon based masters. Do they leave a summary of changes they make at the end? Can you you disable the 'smart' feature with a #pragma dumb so it works just like an ANSI compiler and puts the stuff where I tell it? ________________________________________________________________________ AOL now offers free email to everyone. Find out more about what's free from AOL at AOL.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20070706/a505b40e/attachment.html From johan at edab.nu Fri Jul 6 09:05:10 2007 From: johan at edab.nu (johan@edab.nu) Date: Fri Jul 6 09:17:23 2007 Subject: [Icc-avr] Why does it do this? Message-ID: <200707061605.l66G5AMr005541@gigamail.giganet.se> There is nothing in the ANSI standard that says that a local variable needs to be on the stack, right? So you are in fact not telling the compiler anything about where to put the data.. Thus, a "smart compiler" wouldn't be making any changes to anything, since they can decide on their own where to put the local variables. On 2007-07-06 bobgardner@aol.com wrote: >There is absolutely nothing forcing a C compiler to put the array "y" on the stack. A smart compiler will treat the array exactly as though it was "static const", and therefore put it at a global fixed address, since that saves time and space.? >================================================= >I've seen compiler ads that claim to adhere to an ANSI standard, but until this message I had never heard of a standard for 'smart compilers'. I assume this means that they make subtle changes in where to put variables as they attempt to outguess the carbon based masters. Do they leave a summary of changes they make at the end? Can you you disable the 'smart' feature with a #pragma dumb so it works just like an ANSI compiler and puts the stuff where I tell it? > > >________________________________________________________________________ >AOL now offers free email to everyone. Find out more about what's free from AOL at AOL.com. > >_______________________________________________ >Icc-avr mailing list >Icc-avr@imagecraft.com >http://dragonsgate.net/mailman/listinfo/icc-avr > > From mcreations at fibertel.com.ar Fri Jul 6 09:29:07 2007 From: mcreations at fibertel.com.ar (Ing. Abner Chamson) Date: Fri Jul 6 09:40:14 2007 Subject: [Icc-avr] check for adequately nr. of bits In-Reply-To: <7B0EB27CF1CC93439B5CFB7526E5D74C45D956@mickey.PBNV.local> References: <072D96786BFC014AAEBA9EB07A8070EA22F9E9@seattle.ecpower.dk> <7B0EB27CF1CC93439B5CFB7526E5D74C45D956@mickey.PBNV.local> Message-ID: <093201c7bfea$c6e1ae80$54a50b80$@com.ar> Hi Ton, thanks! That?s what I was looking for but couldn?t find in Kernigan-Ritchie or anywhere else: The ability to manage flags in a straight forward way in standard C. When you declare a variable inside a structure with :1 at the end it tells it?s a 1 bit variable? And your line #define SETFLAG(x) (flag.(x)=1) I had to remove the() around x as it kept telling me about an error of a ( found, as the macro replaces (x) with (FLAG1) instead of FLAG1 Finally, the code compiled ok: typedef struct { unsigned FLAG1:1; unsigned FLAG2:1; unsigned FLAG3:1; unsigned FLAG4:1; unsigned FLAG5:1; unsigned FLAG6:1; unsigned FLAG7:1; unsigned FLAG8:1; unsigned FLAG9:1; unsigned FLAG10:1; unsigned FLAG11:1; unsigned FLAG12:1; unsigned FLAG13:1; unsigned FLAG14:1; unsigned FLAG15:1; }flag_t; #define SET(x) (flag.x=1) #define CLEAR(x) (flag.x=0) #define TOGGLE(x) (flag.x=~flag.x) #define TEST(x) (flag.x) flag_t flag; signed char scfoo; void main(void) { SET(FLAG1); SET(FLAG9); SET(FLAG11); CLEAR(FLAG1); CLEAR(FLAG9); CLEAR(FLAG11); /* */ TOGGLE(FLAG1); TOGGLE(FLAG9); TOGGLE(FLAG11); TOGGLE(FLAG3); if(TEST(FLAG1)) scfoo++; else scfoo--; TOGGLE(FLAG1); } But I found that what before it compiled using 2% of code space, now it told device is 4%full :S Another drawback is that when simulating the application with studio I couldn?t see the members of a structure and cannot place a watch on the flags. abner From: icc-avr-bounces@imagecraft.com [mailto:icc-avr-bounces@imagecraft.com] On Behalf Of Jaspers, Ton Sent: Viernes, 06 de Julio de 2007 04:40 a.m. To: Discussion list for ICCAVR and ICCtiny Users. You do NOT need to subscribe to icc-announce if you are a member of this. Subject: RE: [Icc-avr] check for adequately nr. of bits Steven, What I would do is avoid the problem all together and leave it to the compiler: typedef struct { unsigned aflag:1; unsigned anotherflag:1; unsigned brflag:1; unsigned cflag:1; unsigned dflag:1; unsigned eflag:1; unsigned fflag:1; unsigned gflag:1; unsigned hflag:1; unsigned iflag:1; unsigned jflag:1; unsigned kflag:1; unsigned lflag:1; unsigned mflag:1; unsigned nflag:1; unsigned oflag:1; unsigned pflag:1; } flag_t ; #define SETFLAG(x) (flag.(x)=1) #define CLRFLAG(x) (flag.(x)=0) #define TSTFLAG(x) (flag.(x)) flag_t flag ; ..... SETFLAG(aflag) ; .... if ( TSTFLAG(aflag) ) ..... The compiler should optimise this in to the best solution, bytes or words or what ever. Cheers, Ton _____ From: icc-avr-bounces@imagecraft.com [mailto:icc-avr-bounces@imagecraft.com] On Behalf Of Steven Lose Sent: donderdag 5 juli 2007 23:08 To: Discussion list for ICCAVR and ICCtiny Users. You do NOT need tosubscribeto icc-announce if you are a member of this. Subject: SV: [Icc-avr] check for adequately nr. of bits Hi Ton. It does not check the actual value defined; only one define against another define. Cheers Med venlig hilsen / Best regards / mit freundlichen Gr??en EC POWER A/S Steven Lose Software Ingeni?r Tlf.: +45 87434100 Direkte tlf. +45 58286608 Email: sl@ecpower.dk www.ecpower.dk _____ Fra: icc-avr-bounces@imagecraft.com [mailto:icc-avr-bounces@imagecraft.com] P? vegne af Jaspers, Ton Sendt: 5. juli 2007 14:45 Til: Discussion list for ICCAVR and ICCtiny Users. You do NOT need to subscribeto icc-announce if you are a member of this. Emne: RE: [Icc-avr] check for adequately nr. of bits I don't think it is a linker issue. It is a coding issue. You could try to use teh pre-processor with something like this: #include #define NROFFLAGS 17 #if (1<<(NROFFLAGS-1)) > UINT_MAX ERROR ?VALUE TO SMALL? #endif Mind you, I have not tried it. Cheers, Ton _____ From: icc-avr-bounces@imagecraft.com [mailto:icc-avr-bounces@imagecraft.com] On Behalf Of Steven Lose Sent: donderdag 5 juli 2007 12:59 To: Discussion list for ICCAVR and ICCtiny Users. You do NOT need tosubscribeto icc-announce if you are a member of this. Subject: [Icc-avr] check for adequately nr. of bits Hi. I want to make the linker check that a variable is defined big enough, but don?t know how. Basically I need something that tells me how many bits there is in a variable so I can check it up against a defined value. #define NROFFLAGS 17 Unsigned int uiFlags; #if NROFFLAGS > NROFBITS(uiFlags) ERROR ?VALUE TO SMALL? #endif Is it possible to do so? (if it had been in code I would just use (sizeof(uiFlags)*8) ) And if yes, what is the right way to do it? Med venlig hilsen / Best regards / mit freundlichen Gr??en EC POWER A/S Steven Lose Software Ingeni?r Tlf.: +45 87434100 Direkte tlf. +45 58286608 Email: sl@ecpower.dk www.ecpower.dk -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20070706/23ea9c32/attachment-0001.html From richard-lists at imagecraft.com Fri Jul 6 12:10:33 2007 From: richard-lists at imagecraft.com (Richard) Date: Fri Jul 6 12:21:20 2007 Subject: [Icc-avr] Why does it do this? In-Reply-To: <468E55EC.1060809@hotpop.com> References: <0MKpCa-1I5cGN1aQZ-0001ZP@mrelay.perfora.net> <200707040255.l642tpBD065217@dragonsgate2.imagecraft.com> <468E55EC.1060809@hotpop.com> Message-ID: <200707061921.l66JLJfX006716@dragonsgate2.imagecraft.com> I don't have any solid evidence to go against it per se, except from my experience, every time we do something like, OK, so the qualifier is a const, if it is auto storage class and not a function argument, then lets rewrite the storage as-if it is "static." Anytime we put in a hack like this usually brings out something else later on. The unintended consequences, so to speak. But in the end, I can't really argue with what you said, so I will probably go ahead and put the support in. At 07:47 AM 7/6/2007, David Brown wrote: >There is, as far as I understand it, no requirement for a C compiler >to actually implement limited lifetimes for local data, and there is >certainly no requirement that the data be placed on the stack. The >original code was: > > unsigned int foo( unsigned int *x){ > const unsigned int y[1024] = {1,2,3,4,5,6,7}; > return y[*x]; > } > >There is absolutely nothing forcing a C compiler to put the array >"y" on the stack. A smart compiler will treat the array exactly as >though it was "static const", and therefore put it at a global fixed >address, since that saves time and space. // richard (This email is for mailing lists. To reach me directly, please use richard at imagecraft.com) From david_brown at hotpop.com Fri Jul 6 15:14:23 2007 From: david_brown at hotpop.com (David Brown) Date: Fri Jul 6 14:59:48 2007 Subject: [Icc-avr] Why does it do this? In-Reply-To: <8C98DFB70581A31-3A8-C8A@WEBMAIL-RA05.sysops.aol.com> References: <0MKpCa-1I5cGN1aQZ-0001ZP@mrelay.perfora.net> <200707040255.l642tpBD065217@dragonsgate2.imagecraft.com> <468E55EC.1060809@hotpop.com> <8C98DFB70581A31-3A8-C8A@WEBMAIL-RA05.sysops.aol.com> Message-ID: <468EBEBF.5080408@hotpop.com> (Please do not strip attributions or use non-standard quoting styles on a public mailing lists - it is useful to know who wrote what.) bobgardner@aol.com wrote: David Brown wrote: >> There is absolutely nothing forcing a C compiler to put the array "y" on >> the stack. A smart compiler will treat the array exactly as though it >> was "static const", and therefore put it at a global fixed address, >> since that saves time and space. >> ================================================= > I've seen compiler ads that claim to adhere to an ANSI standard, but > until this message I had never heard of a standard for 'smart > compilers'. I assume this means that they make subtle changes in where > to put variables as they attempt to outguess the carbon based masters. > Do they leave a summary of changes they make at the end? Can you you > disable the 'smart' feature with a #pragma dumb so it works just like an > ANSI compiler and puts the stuff where I tell it? > ------------------------------------------------------------------------ A "smart" compiler is a C compiler that is good at its job - producing object code that produces the effect of the given source code, using the standard language definitions of ANSI C (or something close to the standard - for example, icc-avr does not adhere to ANSI standards for "const", and many other compilers have small non-standard issues). When you write C code, you are giving a specification of the effect you want to occur on the processor. It is up to the compiler to generate code that has this effect - the implementation details are up to the compiler. When you ask for a local variable, you are very specifically *not* specifying that the variable should be allocated on the stack - C has no way to describe such a requirement. All you can ask for is that the variable works just as though it were on the virtual stack of the virtual machine that the C standard describes. The compiler can put it in a register, at a specific memory location, or optimise it out of the code altogether. It could convert the integer to a string of digits and store that, if it wanted to. Imagecraft's compilers have traditionally generated code that is close to a direct translation of the source code, although that has changed in recent times with their newer optimisers. Their compilers compete in the marketplace on the basis of ease of use, reliability, excellent support, and solid code generation - but they do not use the range of optimisation tricks that some other compilers can handle. I am confident that if Richard thought that local non-static const arrays were a common construct that his customers would use, then he would add a new trick to his optimisers to recognize this case and treat them as static - and I am equally confident that Richard will in fact see that this is a very unusual construct, and use his development time on something more useful in practice. mvh., David From david_brown at hotpop.com Fri Jul 6 15:19:55 2007 From: david_brown at hotpop.com (David Brown) Date: Fri Jul 6 15:05:18 2007 Subject: [Icc-avr] Why does it do this? In-Reply-To: <200707061921.l66JLJfX006716@dragonsgate2.imagecraft.com> References: <0MKpCa-1I5cGN1aQZ-0001ZP@mrelay.perfora.net> <200707040255.l642tpBD065217@dragonsgate2.imagecraft.com> <468E55EC.1060809@hotpop.com> <200707061921.l66JLJfX006716@dragonsgate2.imagecraft.com> Message-ID: <468EC00B.2090600@hotpop.com> Richard wrote: > I don't have any solid evidence to go against it per se, except from my > experience, every time we do something like, > > OK, so the qualifier is a const, if it is auto storage class and not a > function argument, then lets rewrite the storage as-if it is "static." > > Anytime we put in a hack like this usually brings out something else > later on. The unintended consequences, so to speak. But in the end, I > can't really argue with what you said, so I will probably go ahead and > put the support in. > As I said in my last post, it is unlikely to be a common case in practice, and therefore probably not worth worrying about. And there are other possible solutions, such as generating a warning on local non-static const arrays suggesting that they be declared static (which should generate good code on *any* compiler). In fact, the older icc-avr 6 that I have rejects the non-static local const with an error (even though it is correct C). For non-array local consts, on the other hand, it may be worth optimising the code generation - but then it would be to use "ldi" instructions rather than to treat them as statics. mvh., David > At 07:47 AM 7/6/2007, David Brown wrote: >> There is, as far as I understand it, no requirement for a C compiler >> to actually implement limited lifetimes for local data, and there is >> certainly no requirement that the data be placed on the stack. The >> original code was: >> >> unsigned int foo( unsigned int *x){ >> const unsigned int y[1024] = {1,2,3,4,5,6,7}; >> return y[*x]; >> } >> >> There is absolutely nothing forcing a C compiler to put the array "y" >> on the stack. A smart compiler will treat the array exactly as though >> it was "static const", and therefore put it at a global fixed address, >> since that saves time and space. > > // richard (This email is for mailing lists. To reach me directly, > please use richard at imagecraft.com) > _______________________________________________ > Icc-avr mailing list > Icc-avr@imagecraft.com > http://dragonsgate.net/mailman/listinfo/icc-avr From jassenbaum at htp-tel.de Fri Jul 6 16:05:04 2007 From: jassenbaum at htp-tel.de (Johannes Assenbaum) Date: Fri Jul 6 16:13:46 2007 Subject: [Icc-avr] Why does it do this? References: <200707061605.l66G5AMr005541@gigamail.giganet.se> Message-ID: I actually do not understand this sub-discussion. Ok, there is nothing forcing a C compiler to put local variables on the stack, only which location would be more approiate *in* *AVR* *programming* *model* to release the variables space *completely* when leaving local scope? Any standard area (e.g. bss)? This would be implicitely static, not good with larger locals. Or the heap? No chance without a good garbage collection. Or a "heap beyond the heap"? Would be no difference to stack, except that addresses would be counted from the low end of free ram rather than from the high end as with stack... I mean, AVRs have a harvard architecture with basically limited ram space, and C standards are not really for this kind of machines. At least they never can enlargen the ram of any AVR we have to do our jobs on. And from my own point of view, I just learned to hate compilers, that are told to do "smart" handling of variables. They always hid to much to me. But this is my opinion, no offense meant. Johannes > There is nothing in the ANSI standard that says that a local variable needs to be > on the stack, right? So you are in fact not telling the compiler anything about > where to put the data.. Thus, a "smart compiler" wouldn't be making any changes to > anything, since they can decide on their own where to put the local variables. > On 2007-07-06 bobgardner@aol.com wrote: >>There is absolutely nothing forcing a C compiler to put the array "y" on the stack. >>A smart compiler will treat the array exactly as though it was "static const", and >>therefore put it at a global fixed address, since that saves time and space.? >>================================================= >>I've seen compiler ads that claim to adhere to an ANSI standard, but until this >>message I had never heard of a standard for 'smart compilers'. I assume this means >>that they make subtle changes in where to put variables as they attempt to outguess >>the carbon based masters. Do they leave a summary of changes they make at the end? >>Can you you disable the 'smart' feature with a #pragma dumb so it works just like >>an ANSI compiler and puts the stuff where I tell it? >> >> >>________________________________________________________________________ >>AOL now offers free email to everyone. Find out more about what's free from AOL at >>AOL.com. >> >>_______________________________________________ >>Icc-avr mailing list >>Icc-avr@imagecraft.com >>http://dragonsgate.net/mailman/listinfo/icc-avr >> >> > _______________________________________________ > Icc-avr mailing list > Icc-avr@imagecraft.com > http://dragonsgate.net/mailman/listinfo/icc-avr > -- > No virus found in this incoming message. > Checked by AVG Free Edition. > Version: 7.5.476 / Virus Database: 269.10.1/888 - Release Date: 06.07.07 06:36 Best regards, Johannes From david_brown at hotpop.com Sat Jul 7 05:57:25 2007 From: david_brown at hotpop.com (David Brown) Date: Sat Jul 7 05:42:46 2007 Subject: [Icc-avr] Why does it do this? In-Reply-To: References: <200707061605.l66G5AMr005541@gigamail.giganet.se> Message-ID: <468F8DB5.8080507@hotpop.com> Johannes Assenbaum wrote: > I actually do not understand this sub-discussion. > > Ok, there is nothing forcing a C compiler to put local variables on > the stack, only which location would be more approiate *in* *AVR* > *programming* *model* to release the variables space *completely* > when leaving local scope? Any standard area (e.g. bss)? This would be Where do you get the idea that variable space must be *completely* released when leaving the scope? That's only the case if the variable space was only allocated when entering the scope. For processors which have no decent hardware support for a software stack (such as the 8051), local variables are statically allocated in data ram (except for re-entrant functions, which cause extra complications). This is perfectly acceptable for a standards-compliant C compiler. Of course it can lead to wasted ram - compilers for the 8051 (and others like it) often have very sophisticated algorithms to multiplex these static locals among functions. On the AVR, the most appropriate place to put local variables is in registers - the stack is only useful for overflow of locals, or for large locals. Most compilers probably also use it if you take the address of a local variable, although that isn't actually necessary on the AVR. But in this particular case, we are talking about local *const* data. This is data that does not change over its lifetime. The data's initialiser is also constant (Imagecraft does not support using a non-constant initialiser in this situation). So the data is the same every time the function is called, and cannot (legally!) be changed by the program. Why then should the compiler (and the AVR at run-time) go through the effort of allocating extra stack space, copying the initialisation data from flash to ram, using the data, then de-allocating the stack space, every time the function is called? It is *much* more efficient just to use the flash-based initialisation data directly. Note that this does not use any memory that is not already needed - in fact it saves significantly on stack space. > implicitely static, not good with larger locals. Or the heap? No > chance without a good garbage collection. Or a "heap beyond the > heap"? Would be no difference to stack, except that addresses would > be counted from the low end of free ram rather than from the high end > as with stack... > > I mean, AVRs have a harvard architecture with basically limited ram > space, and C standards are not really for this kind of machines. At > least they never can enlargen the ram of any AVR we have to do our > jobs on. > It's not the lack of ram that make the AVR's C-unfriendly... > And from my own point of view, I just learned to hate compilers, that > are told to do "smart" handling of variables. They always hid to much > to me. > In my experience, dislike of compiler "tricks" and optimisations can almost always be traced to one of two things - problems when debugging (such as trying to "watch" variables which don't exist in the object code), and incorrect source code. Many people make unwarranted assumptions about C and their compilers, and get in trouble when other compilers don't play by these same imaginary "rules". The most common example is forgetting to use "volatile" as required, but it's not alone. I don't mean to be rude to Imagecraft or anyone else, but I've seen this several times with people moving up from icc-avr to more optimising compilers (or even from older icc-avr to newer versions with better optimisation). People find their delay loops worked fine with the simpler compiler, but are entirely removed by smarter compiler