From rainer.dehnert at t-online.de Thu Aug 7 16:37:52 2008 From: rainer.dehnert at t-online.de (Rainer Dehnert) Date: Thu Aug 7 17:28:12 2008 Subject: [Icc-avr] atof-Difference string <> float Message-ID: <489B8750.9020907@t-online.de> Hi, I've differences converting string to float(double). I'm using ICCAVR V7.18 Pro with Win XP. The source: void main(void) { double lat; unsigned char string[] = "1234.123456"; //init_devices(); lat = atof(string); printf("string: %s\n\r", string); printf("float : %f\n\r", lat); } The displayed results are: string: 1234.123456 float : 1234.123168 Converting with Borland-Compiler the results are correct. Where's my mistake?! Many thanks. Rainer From obparham at jpl.nasa.gov Thu Aug 7 16:47:26 2008 From: obparham at jpl.nasa.gov (Bruce Parham) Date: Thu Aug 7 17:50:28 2008 Subject: [Icc-avr] atof-Difference string <> float In-Reply-To: <489B8750.9020907@t-online.de> References: <489B8750.9020907@t-online.de> Message-ID: <489B898E.2030705@jpl.nasa.gov> Rainer Dehnert wrote: > Hi, > > I've differences converting string to float(double). > I'm using ICCAVR V7.18 Pro with Win XP. > > The source: > void main(void) { > double lat; > unsigned char string[] = "1234.123456"; > > //init_devices(); > > lat = atof(string); > printf("string: %s\n\r", string); > printf("float : %f\n\r", lat); > } > > The displayed results are: > string: 1234.123456 > float : 1234.123168 > > Converting with Borland-Compiler the results are correct. > > Where's my mistake?! > > Many thanks. > Rainer To print a double don't you need to use %lf in the format? Bruce From richard-lists at imagecraft.com Thu Aug 7 21:15:35 2008 From: richard-lists at imagecraft.com (Richard Man) Date: Thu Aug 7 22:19:11 2008 Subject: [Icc-avr] atof-Difference string <> float In-Reply-To: <489B8750.9020907@t-online.de> References: <489B8750.9020907@t-online.de> Message-ID: <200808080519.m785JAPh082890@mail.imagecraft.com> As replied to you directly already: float has only about 7 decimal digits of precision, so 1234.123 is as precise as it can get. The rest is mostly noise. At 04:37 PM 8/7/2008, Rainer Dehnert wrote: >Hi, > >I've differences converting string to float(double). >I'm using ICCAVR V7.18 Pro with Win XP. > >The source: >void main(void) { >double lat; >unsigned char string[] = "1234.123456"; > >//init_devices(); > // richard (This email is for mailing lists. To reach me directly, please use richard at imagecraft.com) From j_baraclough at zetnet.co.uk Fri Aug 8 00:40:21 2008 From: j_baraclough at zetnet.co.uk (John Baraclough) Date: Fri Aug 8 01:44:28 2008 Subject: [Icc-avr] OT: Imagecraft in Elektor online magazine In-Reply-To: <200808080519.m785JAPh082890@mail.imagecraft.com> References: <489B8750.9020907@t-online.de> <200808080519.m785JAPh082890@mail.imagecraft.com> Message-ID: <489BF865.5000705@zetnet.co.uk> This article was just published today. I thought you may like to see it. http://www.elektor.com/news/icc-for-parallax-propeller.630545.lynkx John From steininger at sysdev4u.at Tue Aug 12 08:57:26 2008 From: steininger at sysdev4u.at (Thomas Steininger) Date: Tue Aug 12 10:00:24 2008 Subject: [Icc-avr] command line build Message-ID: <07C3E13CB0E63C43937E60D34FD6844605E359@exchange.sysdev4u.local> Hello, Is there any tool or batch file for command line build? How can I get a .mak file from a .prj file? Regards, steininger thomas sysdev4u edv-dienstleistung gmbh technoparkstr. 4 5310 mondsee austria -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20080812/a4226d54/attachment.html From johan at edab.nu Wed Aug 13 02:22:28 2008 From: johan at edab.nu (=?ISO-8859-1?Q?Johan_Wallstr=F6m?=) Date: Wed Aug 13 03:25:38 2008 Subject: [Icc-avr] File not found In-Reply-To: <489BF865.5000705@zetnet.co.uk> References: <489B8750.9020907@t-online.de> <200808080519.m785JAPh082890@mail.imagecraft.com> <489BF865.5000705@zetnet.co.uk> Message-ID: <48A2A7D4.1030105@edab.nu> Dear List! After installing iccavr on my new computer, the compiler fails to find the files in the project with the following message: !E: cannot load source file "E:\CAPI2S~1\trunk\Devices\DPN\SW\Source\ctrl.c"; file not found even though the file exists. I have also check the .src file that it looks okey and tried to remove all the files from the project and then add them again, but with the same result. Anyone know what can cause this? I'm running iccavr7.17 Regards Johan From benra at imt.liu.se Wed Aug 13 23:45:33 2008 From: benra at imt.liu.se (Bengt Ragnemalm) Date: Thu Aug 14 00:48:06 2008 Subject: SV: [Icc-avr] 32 KHZ Crystal problem, solved I think In-Reply-To: References: Message-ID: Sorry for lat answer but I couldn't resist. Loading capacitors to crystal is a never ending story on AVR freaks among others. But actually there is nothing like "trying with xxx values". Every crystal you buy has a predefined value of the loading capacitors and this is the one and only value you should use. There are exceptions though. First, sometimes the datasheet of for example the AVR may say that loading caps are not necessary. Ok, fine, I guess that must be correct so do not use any in this case. Sometimes the board (if not using a PCB) may introduce so much extra capacitance that you need to reduce the typical value. This should be no big source for problems if you just follow the datasheet of the crystal and the AVR. /Bengt > -----Ursprungligt meddelande----- > Fr?n: icc-avr-bounces@imagecraft.com [mailto:icc-avr- > bounces@imagecraft.com] F?r Patrick Fletcher-Jones > Skickat: den 31 juli 2008 11:05 > Till: Discussion list for ICCAVR and ICCtiny Users. You do NOT need > tosubscribe to icc-announce if you are a member of this. > Kopia: Paul Mooney; Tom Byrne; Martin Pearce > ?mne: [Icc-avr] 32 KHZ Crystal problem, solved I think > > Morning all, > > As some of you are aware I've had a nightmare with the 32KHz crystal > oscillator connected to timer 2 on a mega 1280 (running at either 3.3V or > 5V) > > There is / was a bug in the apps builder which set the prescaler bits > wrong > which I fixed by manually. Even after that my nice little 32 kHz crystal > was > running at 192KHz, not good when trying to run a timer. > > After tons of playing around, trawling the AVRfreaks news groups, trying > different crystals etc.. I have found that you really need to add a 22pF > cap > on each side of the crystal to ground. Once I did this it runs fine, take > the caps off it stops working. > > I've now changed my circuit diagrams to include these caps. > > I am going to try a 6pF crystal, because years ago I had a similar problem > with a Dallas RTCC that only worked with a 6pF crystal and crystals > (correct > me if I'm wrong) are normally 12.5pF > > Anyway its taken me ages to fix this problem and a lot of stress (unhappy > customer, well they are being ok really, its just very late) so I just > wanted to share this with you guys and hope it saves someone else a lot of > trouble. > > Patrick > > > _______________________________________________ > Icc-avr mailing list > Icc-avr@imagecraft.com > http://dragonsgate.net/mailman/listinfo/icc-avr From Morten at biocontrol.no Thu Aug 14 01:28:37 2008 From: Morten at biocontrol.no (Morten Dramstad) Date: Thu Aug 14 02:32:34 2008 Subject: [Icc-avr] Not possible to load old cof-file into AVR-studio Message-ID: <74A3202AB56F68479CC5939350662A023CEA3C@bioserv.biocontrol.no> Hi! Problem 1 I have an old boot loader application that I would like to debug using AVR Studio ver 4.13 Build 571. When I try to load the cof-file which was compiled using Imagecraft ICCAVR v.6 the AVR Studio gives the following errors: - Coordinator: None of the available object file readers can read the specified object file. Please check the format of the object file. - Error loading object file C:\Projects\DeLaval\Multireader\Atmega\Boot\Ver01\Rev00\MultireaderBoot.cof Problem 2 I tried to compile the file using the resent ICCAVR ver 7.14C, but the program cannot be compiled. The original file was compiled October 26 2006 and fit exactly into the memory of the boot sector, there is only 4 free bytes left at the end of the code. Code compression was used, and a lot of the code was written in assembler to be able to make the code small enough. When I compile the code using ICCAVR 7.14c, a get this errors: !E (116): Not enough space in 'text' area. Total of 32772 bytes needed. Question: I need to change the original code and to do so I need to use the same compiler as was used originally, ICCAVR ver 6.30c. Where do I find the installation files for that version? I still have my old laptop, and I thought ver 6.30c still was installed there, but unfortunately, I have uninstalled it to gain space on the hard disk. Best regards Morten Dramstad BioControl A/S Grimstad G?rd N-1890 Rakkestad Norway Phone +47 69 22 52 55 E-mail morten@biocontrol.no www.biocontrol.no From richard-lists at imagecraft.com Thu Aug 14 01:49:23 2008 From: richard-lists at imagecraft.com (Richard Man) Date: Thu Aug 14 02:52:47 2008 Subject: [Icc-avr] command line build In-Reply-To: <07C3E13CB0E63C43937E60D34FD6844605E359@exchange.sysdev4u.l ocal> References: <07C3E13CB0E63C43937E60D34FD6844605E359@exchange.sysdev4u.local> Message-ID: <200808140952.m7E9qkUv033485@mail.imagecraft.com> You use the IDE to build the project, then you can copy and save the .mak makfile for your own use. At 08:57 AM 8/12/2008, Thomas Steininger wrote: >Hello, > >Is there any tool or batch file for command line build? >How can I get a .mak file from a .prj file? > // richard (This email is for mailing lists. To reach me directly, please use richard at imagecraft.com) From paul.aa9gg at gmail.com Thu Aug 14 06:28:18 2008 From: paul.aa9gg at gmail.com (Paul Mateer) Date: Thu Aug 14 07:31:00 2008 Subject: [Icc-avr] 32 KHZ Crystal problem, solved I think In-Reply-To: References: Message-ID: <20f5efc40808140628s3113d1f2w7f87e205e76bc5d8@mail.gmail.com> Whenever we use a crystal we always include 22pF caps from the xtal leads to ground. Never had a problem. 73 de Paul, AA9GG On Thu, Aug 14, 2008 at 1:45 AM, Bengt Ragnemalm wrote: > Sorry for lat answer but I couldn't resist. > > Loading capacitors to crystal is a never ending story on AVR freaks among > others. But actually there is nothing like "trying with xxx values". Every > crystal you buy has a predefined value of the loading capacitors and this > is > the one and only value you should use. There are exceptions though. First, > sometimes the datasheet of for example the AVR may say that loading caps > are > not necessary. Ok, fine, I guess that must be correct so do not use any in > this case. Sometimes the board (if not using a PCB) may introduce so much > extra capacitance that you need to reduce the typical value. > > This should be no big source for problems if you just follow the datasheet > of the crystal and the AVR. > > /Bengt > > > -----Ursprungligt meddelande----- > > Fr?n: icc-avr-bounces@imagecraft.com [mailto:icc-avr- > > bounces@imagecraft.com] F?r Patrick Fletcher-Jones > > Skickat: den 31 juli 2008 11:05 > > Till: Discussion list for ICCAVR and ICCtiny Users. You do NOT need > > tosubscribe to icc-announce if you are a member of this. > > Kopia: Paul Mooney; Tom Byrne; Martin Pearce > > ?mne: [Icc-avr] 32 KHZ Crystal problem, solved I think > > > > Morning all, > > > > As some of you are aware I've had a nightmare with the 32KHz crystal > > oscillator connected to timer 2 on a mega 1280 (running at either 3.3V or > > 5V) > > > > There is / was a bug in the apps builder which set the prescaler bits > > wrong > > which I fixed by manually. Even after that my nice little 32 kHz crystal > > was > > running at 192KHz, not good when trying to run a timer. > > > > After tons of playing around, trawling the AVRfreaks news groups, trying > > different crystals etc.. I have found that you really need to add a 22pF > > cap > > on each side of the crystal to ground. Once I did this it runs fine, take > > the caps off it stops working. > > > > I've now changed my circuit diagrams to include these caps. > > > > I am going to try a 6pF crystal, because years ago I had a similar > problem > > with a Dallas RTCC that only worked with a 6pF crystal and crystals > > (correct > > me if I'm wrong) are normally 12.5pF > > > > Anyway its taken me ages to fix this problem and a lot of stress (unhappy > > customer, well they are being ok really, its just very late) so I just > > wanted to share this with you guys and hope it saves someone else a lot > of > > trouble. > > > > Patrick > > > > > > _______________________________________________ > > 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 > -- Paul Mateer, AA9GG Elan Engineering Corp. www.elanengr.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20080814/055f1357/attachment.html From fletcherjones at worldonline.co.uk Thu Aug 14 06:56:20 2008 From: fletcherjones at worldonline.co.uk (Patrick Fletcher-Jones) Date: Thu Aug 14 07:59:06 2008 Subject: [Icc-avr] 32 KHZ Crystal problem, solved I think In-Reply-To: <20f5efc40808140628s3113d1f2w7f87e205e76bc5d8@mail.gmail.com> Message-ID: Hi, Patrick Again the guy who had the crystal problems. I?ve used the 32 KHz crystal connected in async mode on many of the Atmel processors, mainly Mega 8, 103 & 128 (all PCBs). Never having a problem at all. It was only when we moved to using the mega 1280, upgrade in design from a 128 that these problems arose. We have produced many pcbs using the the mega 1280 and they have all had the same problem, with the 32 khz crystal not working so great. Basically some boards would not oscillate at all, other would be the wrong frequency and a few would work ok. On all the boards the crystals have been at max 2mm from the processor, protected with ground planes etc.. Since we have fitted 22pF caps to ground on the 32 KHz crystal we?ve not had a single problem. I?ve read all the Atmel data sheets and not one of them that I can find says you need to add caps to the 32 KHz crystal We have spent months on and off with this problem, so I?m just hoping our experiences may well save someone else from from pulling their hair out just as I ended up doing many times. VBR, Patrick On 14/08/2008 14:28, "Paul Mateer" wrote: > Whenever we use a crystal we always include 22pF caps from the xtal leads to > ground. Never had a problem. > > 73 de Paul, AA9GG > > > On Thu, Aug 14, 2008 at 1:45 AM, Bengt Ragnemalm wrote: >> Sorry for lat answer but I couldn't resist. >> >> Loading capacitors to crystal is a never ending story on AVR freaks among >> others. But actually there is nothing like "trying with xxx values". Every >> crystal you buy has a predefined value of the loading capacitors and this is >> the one and only value you should use. There are exceptions though. First, >> sometimes the datasheet of for example the AVR may say that loading caps are >> not necessary. Ok, fine, I guess that must be correct so do not use any in >> this case. Sometimes the board (if not using a PCB) may introduce so much >> extra capacitance that you need to reduce the typical value. >> >> This should be no big source for problems if you just follow the datasheet >> of the crystal and the AVR. >> >> /Bengt >> >>> > -----Ursprungligt meddelande----- >>> > Fr?n: icc-avr-bounces@imagecraft.com [mailto:icc-avr- >>> > bounces@imagecraft.com] F?r Patrick Fletcher-Jones >>> > Skickat: den 31 juli 2008 11:05 >>> > Till: Discussion list for ICCAVR and ICCtiny Users. You do NOT need >>> > tosubscribe to icc-announce if you are a member of this. >>> > Kopia: Paul Mooney; Tom Byrne; Martin Pearce >>> > ?mne: [Icc-avr] 32 KHZ Crystal problem, solved I think >>> > >>> > Morning all, >>> > >>> > As some of you are aware I've had a nightmare with the 32KHz crystal >>> > oscillator connected to timer 2 on a mega 1280 (running at either 3.3V or >>> > 5V) >>> > >>> > There is / was a bug in the apps builder which set the prescaler bits >>> > wrong >>> > which I fixed by manually. Even after that my nice little 32 kHz crystal >>> > was >>> > running at 192KHz, not good when trying to run a timer. >>> > >>> > After tons of playing around, trawling the AVRfreaks news groups, trying >>> > different crystals etc.. I have found that you really need to add a 22pF >>> > cap >>> > on each side of the crystal to ground. Once I did this it runs fine, take >>> > the caps off it stops working. >>> > >>> > I've now changed my circuit diagrams to include these caps. >>> > >>> > I am going to try a 6pF crystal, because years ago I had a similar problem >>> > with a Dallas RTCC that only worked with a 6pF crystal and crystals >>> > (correct >>> > me if I'm wrong) are normally 12.5pF >>> > >>> > Anyway its taken me ages to fix this problem and a lot of stress (unhappy >>> > customer, well they are being ok really, its just very late) so I just >>> > wanted to share this with you guys and hope it saves someone else a lot of >>> > trouble. >>> > >>> > Patrick >>> > >>> > >>> > _______________________________________________ >>> > 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20080814/7e52a030/attachment-0001.html From jassenbaum at htp-tel.de Thu Aug 14 12:30:20 2008 From: jassenbaum at htp-tel.de (Johannes Assenbaum) Date: Thu Aug 14 13:33:03 2008 Subject: [Icc-avr] 32 KHZ Crystal problem, solved I think References: <20f5efc40808140628s3113d1f2w7f87e205e76bc5d8@mail.gmail.com> Message-ID: It's just because Mega8/103/128 have on-chip caps for 32kHz xtal which Mega1280 etc. don't have. On Atmel website there is app note "AVR097: Migration between ATmega128 and ATmega1281/ATmega2561" addressing this. Best regards, Johannes > Hi, Patrick Again the guy who had the crystal problems. > I?ve used the 32 KHz crystal connected in async mode on many of the Atmel > processors, mainly Mega 8, 103 & 128 (all PCBs). Never having a problem at > all. > It was only when we moved to using the mega 1280, upgrade in design from a > 128 that these problems arose. > We have produced many pcbs using the the mega 1280 and they have all had the > same problem, with the 32 khz crystal not working so great. > Basically some boards would not oscillate at all, other would be the wrong > frequency and a few would work ok. > On all the boards the crystals have been at max 2mm from the processor, > protected with ground planes etc.. > Since we have fitted 22pF caps to ground on the 32 KHz crystal we?ve not had > a single problem. I?ve read all the Atmel data sheets and not one of them > that I can find says you need to add caps to the 32 KHz crystal > We have spent months on and off with this problem, so I?m just hoping our > experiences may well save someone else from from pulling their hair out just > as I ended up doing many times. > VBR, > Patrick > On 14/08/2008 14:28, "Paul Mateer" wrote: >> Whenever we use a crystal we always include 22pF caps from the xtal leads to >> ground. Never had a problem. >> >> 73 de Paul, AA9GG >> >> >> On Thu, Aug 14, 2008 at 1:45 AM, Bengt Ragnemalm wrote: >>> Sorry for lat answer but I couldn't resist. >>> >>> Loading capacitors to crystal is a never ending story on AVR freaks among >>> others. But actually there is nothing like "trying with xxx values". Every >>> crystal you buy has a predefined value of the loading capacitors and this is >>> the one and only value you should use. There are exceptions though. First, >>> sometimes the datasheet of for example the AVR may say that loading caps are >>> not necessary. Ok, fine, I guess that must be correct so do not use any in >>> this case. Sometimes the board (if not using a PCB) may introduce so much >>> extra capacitance that you need to reduce the typical value. >>> >>> This should be no big source for problems if you just follow the datasheet >>> of the crystal and the AVR. >>> >>> /Bengt >>> >>>> > -----Ursprungligt meddelande----- >>>> > Fr?n: icc-avr-bounces@imagecraft.com [mailto:icc-avr- >>>> > bounces@imagecraft.com] F?r Patrick Fletcher-Jones >>>> > Skickat: den 31 juli 2008 11:05 >>>> > Till: Discussion list for ICCAVR and ICCtiny Users. You do NOT need >>>> > tosubscribe to icc-announce if you are a member of this. >>>> > Kopia: Paul Mooney; Tom Byrne; Martin Pearce >>>> > ?mne: [Icc-avr] 32 KHZ Crystal problem, solved I think >>>> > >>>> > Morning all, >>>> > >>>> > As some of you are aware I've had a nightmare with the 32KHz crystal >>>> > oscillator connected to timer 2 on a mega 1280 (running at either 3.3V or >>>> > 5V) >>>> > >>>> > There is / was a bug in the apps builder which set the prescaler bits >>>> > wrong >>>> > which I fixed by manually. Even after that my nice little 32 kHz crystal >>>> > was >>>> > running at 192KHz, not good when trying to run a timer. >>>> > >>>> > After tons of playing around, trawling the AVRfreaks news groups, trying >>>> > different crystals etc.. I have found that you really need to add a 22pF >>>> > cap >>>> > on each side of the crystal to ground. Once I did this it runs fine, take >>>> > the caps off it stops working. >>>> > >>>> > I've now changed my circuit diagrams to include these caps. >>>> > >>>> > I am going to try a 6pF crystal, because years ago I had a similar problem >>>> > with a Dallas RTCC that only worked with a 6pF crystal and crystals >>>> > (correct >>>> > me if I'm wrong) are normally 12.5pF >>>> > >>>> > Anyway its taken me ages to fix this problem and a lot of stress (unhappy >>>> > customer, well they are being ok really, its just very late) so I just >>>> > wanted to share this with you guys and hope it saves someone else a lot of >>>> > trouble. >>>> > >>>> > Patrick >>>> > >>>> > >>>> > _______________________________________________ >>>> > 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 >> >> From fletcherjones at worldonline.co.uk Thu Aug 14 14:54:08 2008 From: fletcherjones at worldonline.co.uk (Patrick Fletcher-Jones) Date: Thu Aug 14 15:56:50 2008 Subject: [Icc-avr] 32 KHZ Crystal problem, solved I think In-Reply-To: Message-ID: Ahh Johannes if only I had know that about 18 months ago... Many thanks for pointing that out. VBR, Patrick On 14/08/2008 20:30, "Johannes Assenbaum" wrote: > It's just because Mega8/103/128 have on-chip caps for 32kHz xtal which > Mega1280 etc. don't have. > > On Atmel website there is app note "AVR097: Migration between ATmega128 and > ATmega1281/ATmega2561" addressing this. > > Best regards, > Johannes > > >> Hi, Patrick Again the guy who had the crystal problems. > >> I?ve used the 32 KHz crystal connected in async mode on many of the Atmel >> processors, mainly Mega 8, 103 & 128 (all PCBs). Never having a problem at >> all. > >> It was only when we moved to using the mega 1280, upgrade in design from a >> 128 that these problems arose. > >> We have produced many pcbs using the the mega 1280 and they have all had the >> same problem, with the 32 khz crystal not working so great. > >> Basically some boards would not oscillate at all, other would be the wrong >> frequency and a few would work ok. > >> On all the boards the crystals have been at max 2mm from the processor, >> protected with ground planes etc.. > >> Since we have fitted 22pF caps to ground on the 32 KHz crystal we?ve not had >> a single problem. I?ve read all the Atmel data sheets and not one of them >> that I can find says you need to add caps to the 32 KHz crystal > >> We have spent months on and off with this problem, so I?m just hoping our >> experiences may well save someone else from from pulling their hair out just >> as I ended up doing many times. > >> VBR, >> Patrick > > >> On 14/08/2008 14:28, "Paul Mateer" wrote: > >>> Whenever we use a crystal we always include 22pF caps from the xtal leads to >>> ground. Never had a problem. >>> >>> 73 de Paul, AA9GG >>> >>> >>> On Thu, Aug 14, 2008 at 1:45 AM, Bengt Ragnemalm wrote: >>>> Sorry for lat answer but I couldn't resist. >>>> >>>> Loading capacitors to crystal is a never ending story on AVR freaks among >>>> others. But actually there is nothing like "trying with xxx values". Every >>>> crystal you buy has a predefined value of the loading capacitors and this >>>> is >>>> the one and only value you should use. There are exceptions though. First, >>>> sometimes the datasheet of for example the AVR may say that loading caps >>>> are >>>> not necessary. Ok, fine, I guess that must be correct so do not use any in >>>> this case. Sometimes the board (if not using a PCB) may introduce so much >>>> extra capacitance that you need to reduce the typical value. >>>> >>>> This should be no big source for problems if you just follow the datasheet >>>> of the crystal and the AVR. >>>> >>>> /Bengt >>>> >>>>>> -----Ursprungligt meddelande----- >>>>>> Fr?n: icc-avr-bounces@imagecraft.com [mailto:icc-avr- >>>>>> bounces@imagecraft.com] F?r Patrick Fletcher-Jones >>>>>> Skickat: den 31 juli 2008 11:05 >>>>>> Till: Discussion list for ICCAVR and ICCtiny Users. You do NOT need >>>>>> tosubscribe to icc-announce if you are a member of this. >>>>>> Kopia: Paul Mooney; Tom Byrne; Martin Pearce >>>>>> ?mne: [Icc-avr] 32 KHZ Crystal problem, solved I think >>>>>> >>>>>> Morning all, >>>>>> >>>>>> As some of you are aware I've had a nightmare with the 32KHz crystal >>>>>> oscillator connected to timer 2 on a mega 1280 (running at either 3.3V or >>>>>> 5V) >>>>>> >>>>>> There is / was a bug in the apps builder which set the prescaler bits >>>>>> wrong >>>>>> which I fixed by manually. Even after that my nice little 32 kHz crystal >>>>>> was >>>>>> running at 192KHz, not good when trying to run a timer. >>>>>> >>>>>> After tons of playing around, trawling the AVRfreaks news groups, trying >>>>>> different crystals etc.. I have found that you really need to add a 22pF >>>>>> cap >>>>>> on each side of the crystal to ground. Once I did this it runs fine, take >>>>>> the caps off it stops working. >>>>>> >>>>>> I've now changed my circuit diagrams to include these caps. >>>>>> >>>>>> I am going to try a 6pF crystal, because years ago I had a similar >>>>>> problem >>>>>> with a Dallas RTCC that only worked with a 6pF crystal and crystals >>>>>> (correct >>>>>> me if I'm wrong) are normally 12.5pF >>>>>> >>>>>> Anyway its taken me ages to fix this problem and a lot of stress (unhappy >>>>>> customer, well they are being ok really, its just very late) so I just >>>>>> wanted to share this with you guys and hope it saves someone else a lot >>>>>> of >>>>>> trouble. >>>>>> >>>>>> Patrick >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> 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 >>> >>> > > > > > _______________________________________________ > Icc-avr mailing list > Icc-avr@imagecraft.com > http://dragonsgate.net/mailman/listinfo/icc-avr From benra at imt.liu.se Fri Aug 15 00:17:25 2008 From: benra at imt.liu.se (Bengt Ragnemalm) Date: Fri Aug 15 01:20:01 2008 Subject: SV: [Icc-avr] 32 KHZ Crystal problem, solved I think In-Reply-To: References: <20f5efc40808140628s3113d1f2w7f87e205e76bc5d8@mail.gmail.com> Message-ID: Exactly, that's why you need to read datasheets. Booth the AVRs and the crystals! The AVR datasheet is not the right place to look for what you need to do with external components except for the situation with built in caps. The reason that 22 nF works well is that it is very close to the most common values. I think 12-22 is very typical values. From my experience the frequency will not change if you choose wrong value, instead it could be longer start-up time or maybe more power. But actually there is no reason not to use the correct value as it always is in the crystals datasheet. It could even be so that if you have moved the crystal away from the CPU it would have worked better as it would have been a longer distance to form a capacitor between the wires and your ground plane. I have never had any problems with crystals as I have been aware of how crystals work (that they need capacitor loading) from the first place. Lucky enough someone told me in the early years. Best regards, Bengt > -----Ursprungligt meddelande----- > Fr?n: icc-avr-bounces@imagecraft.com [mailto:icc-avr- > bounces@imagecraft.com] F?r Johannes Assenbaum > Skickat: den 14 augusti 2008 21:30 > Till: icc-avr@imagecraft.com > ?mne: Re: [Icc-avr] 32 KHZ Crystal problem, solved I think > > It's just because Mega8/103/128 have on-chip caps for 32kHz xtal which > Mega1280 etc. don't have. > > On Atmel website there is app note "AVR097: Migration between ATmega128 > and > ATmega1281/ATmega2561" addressing this. > > Best regards, > Johannes > > > > Hi, Patrick Again the guy who had the crystal problems. > > > I?ve used the 32 KHz crystal connected in async mode on many of the > Atmel > > processors, mainly Mega 8, 103 & 128 (all PCBs). Never having a problem > at > > all. > > > It was only when we moved to using the mega 1280, upgrade in design from > a > > 128 that these problems arose. > > > We have produced many pcbs using the the mega 1280 and they have all had > the > > same problem, with the 32 khz crystal not working so great. > > > Basically some boards would not oscillate at all, other would be the > wrong > > frequency and a few would work ok. > > > On all the boards the crystals have been at max 2mm from the processor, > > protected with ground planes etc.. > > > Since we have fitted 22pF caps to ground on the 32 KHz crystal we?ve not > had > > a single problem. I?ve read all the Atmel data sheets and not one of > them > > that I can find says you need to add caps to the 32 KHz crystal > > > We have spent months on and off with this problem, so I?m just hoping > our > > experiences may well save someone else from from pulling their hair out > just > > as I ended up doing many times. > > > VBR, > > Patrick > > > > On 14/08/2008 14:28, "Paul Mateer" wrote: > > >> Whenever we use a crystal we always include 22pF caps from the xtal > leads to > >> ground. Never had a problem. > >> > >> 73 de Paul, AA9GG > >> > >> > >> On Thu, Aug 14, 2008 at 1:45 AM, Bengt Ragnemalm > wrote: > >>> Sorry for lat answer but I couldn't resist. > >>> > >>> Loading capacitors to crystal is a never ending story on AVR freaks > among > >>> others. But actually there is nothing like "trying with xxx values". > Every > >>> crystal you buy has a predefined value of the loading capacitors and > this is > >>> the one and only value you should use. There are exceptions though. > First, > >>> sometimes the datasheet of for example the AVR may say that loading > caps are > >>> not necessary. Ok, fine, I guess that must be correct so do not use > any in > >>> this case. Sometimes the board (if not using a PCB) may introduce so > much > >>> extra capacitance that you need to reduce the typical value. > >>> > >>> This should be no big source for problems if you just follow the > datasheet > >>> of the crystal and the AVR. > >>> > >>> /Bengt > >>> > >>>> > -----Ursprungligt meddelande----- > >>>> > Fr?n: icc-avr-bounces@imagecraft.com [mailto:icc-avr- > >>>> > bounces@imagecraft.com] F?r Patrick Fletcher-Jones > >>>> > Skickat: den 31 juli 2008 11:05 > >>>> > Till: Discussion list for ICCAVR and ICCtiny Users. You do NOT need > >>>> > tosubscribe to icc-announce if you are a member of this. > >>>> > Kopia: Paul Mooney; Tom Byrne; Martin Pearce > >>>> > ?mne: [Icc-avr] 32 KHZ Crystal problem, solved I think > >>>> > > >>>> > Morning all, > >>>> > > >>>> > As some of you are aware I've had a nightmare with the 32KHz > crystal > >>>> > oscillator connected to timer 2 on a mega 1280 (running at either > 3.3V or > >>>> > 5V) > >>>> > > >>>> > There is / was a bug in the apps builder which set the prescaler > bits > >>>> > wrong > >>>> > which I fixed by manually. Even after that my nice little 32 kHz > crystal > >>>> > was > >>>> > running at 192KHz, not good when trying to run a timer. > >>>> > > >>>> > After tons of playing around, trawling the AVRfreaks news groups, > trying > >>>> > different crystals etc.. I have found that you really need to add a > 22pF > >>>> > cap > >>>> > on each side of the crystal to ground. Once I did this it runs > fine, take > >>>> > the caps off it stops working. > >>>> > > >>>> > I've now changed my circuit diagrams to include these caps. > >>>> > > >>>> > I am going to try a 6pF crystal, because years ago I had a similar > problem > >>>> > with a Dallas RTCC that only worked with a 6pF crystal and crystals > >>>> > (correct > >>>> > me if I'm wrong) are normally 12.5pF > >>>> > > >>>> > Anyway its taken me ages to fix this problem and a lot of stress > (unhappy > >>>> > customer, well they are being ok really, its just very late) so I > just > >>>> > wanted to share this with you guys and hope it saves someone else a > lot of > >>>> > trouble. > >>>> > > >>>> > Patrick > >>>> > > >>>> > > >>>> > _______________________________________________ > >>>> > 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 > >> > >> > > > > > _______________________________________________ > Icc-avr mailing list > Icc-avr@imagecraft.com > http://dragonsgate.net/mailman/listinfo/icc-avr From benra at imt.liu.se Fri Aug 15 00:25:55 2008 From: benra at imt.liu.se (Bengt Ragnemalm) Date: Fri Aug 15 01:28:25 2008 Subject: [Icc-avr] Using to much RAM for local variables Message-ID: <664A08FA68194943BDD11F841E7D55F0@Shagrat> Hi. I felled in a new pit and have just found the ladder. I use an Mega88, it has 1 k RAM. I have declared two local arrays, both with 512 bytes. Obviously this will not work if they are used simultaneously. Unfortunately they are, something I totally missed. But the code compiles fine and I have been a little upset struggling with the problem that my hardware just turned off after 90 seconds by it self without ever entering the POWER OFF state. The problem was that as soon as one of the arrays was starting to write data to the later sections, it instead was writing in my registers. Among others, the register that was controlling the power. QUESTION: Is it natural that the compiler does not generate any error in this situation? The actual problem should not be to difficult to solve. /Bengt Bengt Ragnemalm, Forskningsingenj?r Tel 013-22 24 97 Leveransadress: Faktureringsadress: FAX: +46 13 10 19 02 Link?pings Universitet Link?pings Universitet bengt.ragnemalm@imt.liu.se Inst. f?r Medicinsk Teknik Faktura support http://www.imt.liu.se S-581 85 Link?ping SWEDEN 581 83 Link?ping Ref 1700 Bengt Ragnemalm M?rk med v?rt Best?llningsnr Vi kan g?ra mer ?n du kan dr?mma om men f?r det om?jliga beh?ver vi en liten leveranstid. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20080815/0b275b46/attachment-0001.html From byron at inhep.com Fri Aug 15 01:00:26 2008 From: byron at inhep.com (Byron Loader) Date: Fri Aug 15 02:03:34 2008 Subject: [Icc-avr] Warnings! In-Reply-To: <664A08FA68194943BDD11F841E7D55F0@Shagrat> Message-ID: Hi Richard - any chance of adding a warning prior to linking that the compiler cannot see the USB dongle? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20080815/d760b724/attachment.html From richard-lists at imagecraft.com Fri Aug 15 01:45:17 2008 From: richard-lists at imagecraft.com (Richard Man) Date: Fri Aug 15 02:48:47 2008 Subject: [Icc-avr] Using to much RAM for local variables In-Reply-To: <664A08FA68194943BDD11F841E7D55F0@Shagrat> References: <664A08FA68194943BDD11F841E7D55F0@Shagrat> Message-ID: <200808150948.m7F9mkkN058145@mail.imagecraft.com> There are billions problems to solve to write a compiler product. Most are easy, some are very difficult. Solving a SPECIFIC instance of a problem is easy, but solving a generic problem is never. To answer your questions directly, yes, it can be solved, especially by linker who does full call tree analysis and then layout all the SRAM requirements, and that'd be the right way to solve it. Unfortunately, that is not easy. It is the same as requesting Atmel to add a "stack check" hardware. All they need is a data break register. How hard can *that* be? At 12:25 AM 8/15/2008, Bengt Ragnemalm wrote: >Hi. > >I felled in a new pit and have just found the ladder. > >I use an Mega88, it has 1 k RAM. I have declared two local arrays, >both with 512 bytes. Obviously this will not work if they are used >simultaneously. Unfortunately they are, something I totally missed. >But the code compiles fine and I have been a little upset struggling >with the problem that my hardware just turned off after 90 seconds >by it self without ever entering the POWER OFF state. The problem >was that as soon as one of the arrays was starting to write data to >the later sections, it instead was writing in my registers. Among >others, the register that was controlling the power. > >QUESTION: Is it natural that the compiler does not generate any >error in this situation? > >The actual problem should not be to difficult to solve. > // richard (This email is for mailing lists. To reach me directly, please use richard at imagecraft.com) From j_baraclough at zetnet.co.uk Fri Aug 15 02:11:04 2008 From: j_baraclough at zetnet.co.uk (John Baraclough) Date: Fri Aug 15 03:13:46 2008 Subject: [Icc-avr] Using to much RAM for local variables In-Reply-To: <664A08FA68194943BDD11F841E7D55F0@Shagrat> References: <664A08FA68194943BDD11F841E7D55F0@Shagrat> Message-ID: <48A54828.3080300@zetnet.co.uk> That is why arrays should always be global! They don't take up any more space and the code to access them is the same, but the compiler will detect the problem immediately. John Bengt Ragnemalm wrote: > > Hi. > > > > I felled in a new pit and have just found the ladder. > > > > I use an Mega88, it has 1 k RAM. I have declared two local arrays, > both with 512 bytes. Obviously this will not work if they are used > simultaneously. Unfortunately they are, something I totally missed. > But the code compiles fine and I have been a little upset struggling > with the problem that my hardware just turned off after 90 seconds by > it self without ever entering the POWER OFF state. The problem was > that as soon as one of the arrays was starting to write data to the > later sections, it instead was writing in my registers. Among others, > the register that was controlling the power. > > > > QUESTION: Is it natural that the compiler does not generate any error > in this situation? > > > > The actual problem should not be to difficult to solve. > > > > /Bengt > > > > > From benra at imt.liu.se Fri Aug 15 03:14:10 2008 From: benra at imt.liu.se (Bengt Ragnemalm) Date: Fri Aug 15 04:16:40 2008 Subject: SV: [Icc-avr] Using to much RAM for local variables In-Reply-To: <200808150948.m7F9mkkN058145@mail.imagecraft.com> References: <664A08FA68194943BDD11F841E7D55F0@Shagrat> <200808150948.m7F9mkkN058145@mail.imagecraft.com> Message-ID: <05EF9FFB331A47DB916A8398F28BCF45@Shagrat> OK, so it is normal. Just needed to know. Johannes, what do you mean with "always global"? I have need for a temporary 512 bytes, what good is it to make this into something permanent? But if it is so tricky to track problems with to large temporary RAM variables (I do use Stack Check) maybe it is better to define one global array and switch the usage of it. /Bengt > -----Ursprungligt meddelande----- > Fr?n: icc-avr-bounces@imagecraft.com [mailto:icc-avr- > bounces@imagecraft.com] F?r Richard Man > Skickat: den 15 augusti 2008 10:45 > Till: benra@imt.liu.se; icc-avr@imagecraft.com > ?mne: Re: [Icc-avr] Using to much RAM for local variables > > There are billions problems to solve to write a compiler product. > Most are easy, some are very difficult. Solving a SPECIFIC instance > of a problem is easy, but solving a generic problem is never. To > answer your questions directly, yes, it can be solved, especially by > linker who does full call tree analysis and then layout all the SRAM > requirements, and that'd be the right way to solve it. Unfortunately, > that is not easy. > > It is the same as requesting Atmel to add a "stack check" > hardware. All they need is a data break register. How hard can *that* be? > > At 12:25 AM 8/15/2008, Bengt Ragnemalm wrote: > >Hi. > > > >I felled in a new pit and have just found the ladder. > > > >I use an Mega88, it has 1 k RAM. I have declared two local arrays, > >both with 512 bytes. Obviously this will not work if they are used > >simultaneously. Unfortunately they are, something I totally missed. > >But the code compiles fine and I have been a little upset struggling > >with the problem that my hardware just turned off after 90 seconds > >by it self without ever entering the POWER OFF state. The problem > >was that as soon as one of the arrays was starting to write data to > >the later sections, it instead was writing in my registers. Among > >others, the register that was controlling the power. > > > >QUESTION: Is it natural that the compiler does not generate any > >error in this situation? > > > >The actual problem should not be to difficult to solve. > > > > // 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 johan at edab.nu Fri Aug 15 03:55:50 2008 From: johan at edab.nu (=?ISO-8859-1?Q?Johan_Wallstr=F6m?=) Date: Fri Aug 15 04:58:32 2008 Subject: SV: [Icc-avr] Using to much RAM for local variables In-Reply-To: <05EF9FFB331A47DB916A8398F28BCF45@Shagrat> References: <664A08FA68194943BDD11F841E7D55F0@Shagrat> <200808150948.m7F9mkkN058145@mail.imagecraft.com> <05EF9FFB331A47DB916A8398F28BCF45@Shagrat> Message-ID: <48A560B6.2090700@edab.nu> Yes one global array is the best way to do it, and track the usage of it carefully Bengt Ragnemalm skrev: > OK, so it is normal. Just needed to know. > > Johannes, what do you mean with "always global"? I have need for a > temporary 512 bytes, what good is it to make this into something permanent? > But if it is so tricky to track problems with to large temporary RAM > variables (I do use Stack Check) maybe it is better to define one global > array and switch the usage of it. > > /Bengt > > >> -----Ursprungligt meddelande----- >> Fr?n: icc-avr-bounces@imagecraft.com [mailto:icc-avr- >> bounces@imagecraft.com] F?r Richard Man >> Skickat: den 15 augusti 2008 10:45 >> Till: benra@imt.liu.se; icc-avr@imagecraft.com >> ?mne: Re: [Icc-avr] Using to much RAM for local variables >> >> There are billions problems to solve to write a compiler product. >> Most are easy, some are very difficult. Solving a SPECIFIC instance >> of a problem is easy, but solving a generic problem is never. To >> answer your questions directly, yes, it can be solved, especially by >> linker who does full call tree analysis and then layout all the SRAM >> requirements, and that'd be the right way to solve it. Unfortunately, >> that is not easy. >> >> It is the same as requesting Atmel to add a "stack check" >> hardware. All they need is a data break register. How hard can *that* be? >> >> At 12:25 AM 8/15/2008, Bengt Ragnemalm wrote: >> >>> Hi. >>> >>> I felled in a new pit and have just found the ladder. >>> >>> I use an Mega88, it has 1 k RAM. I have declared two local arrays, >>> both with 512 bytes. Obviously this will not work if they are used >>> simultaneously. Unfortunately they are, something I totally missed. >>> But the code compiles fine and I have been a little upset struggling >>> with the problem that my hardware just turned off after 90 seconds >>> by it self without ever entering the POWER OFF state. The problem >>> was that as soon as one of the arrays was starting to write data to >>> the later sections, it instead was writing in my registers. Among >>> others, the register that was controlling the power. >>> >>> QUESTION: Is it natural that the compiler does not generate any >>> error in this situation? >>> >>> The actual problem should not be to difficult to solve. >>> >>> >> // 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 >> > > > _______________________________________________ > 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 - http://www.avg.com > Version: 8.0.138 / Virus Database: 270.6.3/1612 - Release Date: 2008-08-14 18:03 > > > > From benra at imt.liu.se Fri Aug 15 04:02:56 2008 From: benra at imt.liu.se (Bengt Ragnemalm) Date: Fri Aug 15 05:05:25 2008 Subject: [Icc-avr] Stack problems In-Reply-To: <05EF9FFB331A47DB916A8398F28BCF45@Shagrat> References: <664A08FA68194943BDD11F841E7D55F0@Shagrat><200808150948.m7F9mkkN058145@mail.imagecraft.com> <05EF9FFB331A47DB916A8398F28BCF45@Shagrat> Message-ID: <66680761C9744738A5BC9550E934E10E@Shagrat> I am beginning to get a hold on my problems now. Of course it was several problems as it usual are if you don't find the error quickly. First I have increased the hardware stack to 20 as it was overflowing. But know I have noticed that at entering a timer overflow interrupt, the interrupt routine is writing in my registers. Here is the first line, copied from Studio so you can see C and assembler: @0000080E: SampleRateTimerOverflowInt 329: void SampleRateTimerOverflowInt(void) +0000080E: D48F RCALL PC+0x0490 Relative call subroutine The RCALL goes here: +00000C9E: 920A ST -Y,R0 Store indirect and predecrement +00000C9F: 921A ST -Y,R1 Store indirect and predecrement +00000CA0: 922A ST -Y,R2 Store indirect and predecrement +00000CA1: 923A ST -Y,R3 Store indirect and predecrement +00000CA2: 924A ST -Y,R4 Store indirect and predecrement +00000CA3: 925A ST -Y,R5 Store indirect and predecrement +00000CA4: 926A ST -Y,R6 Store indirect and predecrement +00000CA5: 927A ST -Y,R7 Store indirect and predecrement +00000CA6: 928A ST -Y,R8 Store indirect and predecrement +00000CA7: 929A ST -Y,R9 Store indirect and predecrement +00000CA8: 930A ST -Y,R16 Store indirect and predecrement +00000CA9: 931A ST -Y,R17 Store indirect and predecrement +00000CAA: 932A ST -Y,R18 Store indirect and predecrement +00000CAB: 933A ST -Y,R19 Store indirect and predecrement +00000CAC: 938A ST -Y,R24 Store indirect and predecrement +00000CAD: 939A ST -Y,R25 Store indirect and predecrement +00000CAE: 93AA ST -Y,R26 Store indirect and predecrement +00000CAF: 93BA ST -Y,R27 Store indirect and predecrement +00000CB0: 93EA ST -Y,R30 Store indirect and predecrement +00000CB1: 93FA ST -Y,R31 Store indirect and predecrement +00000CB2: B60F IN R0,0x3F In from I/O location +00000CB3: 920A ST -Y,R0 Store indirect and predecrement +00000CB4: 9508 RET Subroutine return The subroutine is obviously saving all registers. The question is there? Y is 0xBE, counting down for each save. And yes, 0xBE are right into my registers. What should I look for to solve this? /Bengt From benra at imt.liu.se Fri Aug 15 04:25:57 2008 From: benra at imt.liu.se (Bengt Ragnemalm) Date: Fri Aug 15 05:28:28 2008 Subject: SV: [Icc-avr] Stack problems In-Reply-To: <66680761C9744738A5BC9550E934E10E@Shagrat> References: <664A08FA68194943BDD11F841E7D55F0@Shagrat><200808150948.m7F9mkkN058145@mail.imagecraft.com><05EF9FFB331A47DB916A8398F28BCF45@Shagrat> <66680761C9744738A5BC9550E934E10E@Shagrat> Message-ID: <0C3FA4B69B124EF8B17B390F7467971E@Shagrat> Sorry, this was of course the same reason that before, the big local array. After changing into one global this problem disappeared. But maybe someone could describe this a little so I understand what happened? The stack checking bytes was not overwritten. /Bengt > -----Ursprungligt meddelande----- > Fr?n: icc-avr-bounces@imagecraft.com [mailto:icc-avr- > bounces@imagecraft.com] F?r Bengt Ragnemalm > Skickat: den 15 augusti 2008 13:03 > Till: benra@imt.liu.se; 'Discussion list for ICCAVR and ICCtiny Users. You > do NOT needtosubscribeto icc-announce if you are a member of this.' > ?mne: [Icc-avr] Stack problems > > I am beginning to get a hold on my problems now. Of course it was several > problems as it usual are if you don't find the error quickly. First I have > increased the hardware stack to 20 as it was overflowing. But know I have > noticed that at entering a timer overflow interrupt, the interrupt routine > is writing in my registers. > > Here is the first line, copied from Studio so you can see C and assembler: > @0000080E: SampleRateTimerOverflowInt > 329: void SampleRateTimerOverflowInt(void) > +0000080E: D48F RCALL PC+0x0490 Relative call subroutine > > The RCALL goes here: > +00000C9E: 920A ST -Y,R0 Store indirect and > predecrement > +00000C9F: 921A ST -Y,R1 Store indirect and > predecrement > +00000CA0: 922A ST -Y,R2 Store indirect and > predecrement > +00000CA1: 923A ST -Y,R3 Store indirect and > predecrement > +00000CA2: 924A ST -Y,R4 Store indirect and > predecrement > +00000CA3: 925A ST -Y,R5 Store indirect and > predecrement > +00000CA4: 926A ST -Y,R6 Store indirect and > predecrement > +00000CA5: 927A ST -Y,R7 Store indirect and > predecrement > +00000CA6: 928A ST -Y,R8 Store indirect and > predecrement > +00000CA7: 929A ST -Y,R9 Store indirect and > predecrement > +00000CA8: 930A ST -Y,R16 Store indirect and > predecrement > +00000CA9: 931A ST -Y,R17 Store indirect and > predecrement > +00000CAA: 932A ST -Y,R18 Store indirect and > predecrement > +00000CAB: 933A ST -Y,R19 Store indirect and > predecrement > +00000CAC: 938A ST -Y,R24 Store indirect and > predecrement > +00000CAD: 939A ST -Y,R25 Store indirect and > predecrement > +00000CAE: 93AA ST -Y,R26 Store indirect and > predecrement > +00000CAF: 93BA ST -Y,R27 Store indirect and > predecrement > +00000CB0: 93EA ST -Y,R30 Store indirect and > predecrement > +00000CB1: 93FA ST -Y,R31 Store indirect and > predecrement > +00000CB2: B60F IN R0,0x3F In from I/O location > +00000CB3: 920A ST -Y,R0 Store indirect and > predecrement > +00000CB4: 9508 RET Subroutine return > > The subroutine is obviously saving all registers. The question is there? Y > is 0xBE, counting down for each save. And yes, 0xBE are right into my > registers. > > What should I look for to solve this? > > /Bengt > > > _______________________________________________ > Icc-avr mailing list > Icc-avr@imagecraft.com > http://dragonsgate.net/mailman/listinfo/icc-avr From johan at edab.nu Fri Aug 15 04:36:07 2008 From: johan at edab.nu (=?ISO-8859-1?Q?Johan_Wallstr=F6m?=) Date: Fri Aug 15 05:38:47 2008 Subject: SV: [Icc-avr] Stack problems In-Reply-To: <0C3FA4B69B124EF8B17B390F7467971E@Shagrat> References: <664A08FA68194943BDD11F841E7D55F0@Shagrat><200808150948.m7F9mkkN058145@mail.imagecraft.com><05EF9FFB331A47DB916A8398F28BCF45@Shagrat> <66680761C9744738A5BC9550E934E10E@Shagrat> <0C3FA4B69B124EF8B17B390F7467971E@Shagrat> Message-ID: <48A56A27.5030707@edab.nu> Didn't it just crash before you got a chance to call the stack check function? Bengt Ragnemalm skrev: > Sorry, this was of course the same reason that before, the big local array. > After changing into one global this problem disappeared. But maybe someone > could describe this a little so I understand what happened? The stack > checking bytes was not overwritten. > > /Bengt > > >> -----Ursprungligt meddelande----- >> Fr?n: icc-avr-bounces@imagecraft.com [mailto:icc-avr- >> bounces@imagecraft.com] F?r Bengt Ragnemalm >> Skickat: den 15 augusti 2008 13:03 >> Till: benra@imt.liu.se; 'Discussion list for ICCAVR and ICCtiny Users. You >> do NOT needtosubscribeto icc-announce if you are a member of this.' >> ?mne: [Icc-avr] Stack problems >> >> I am beginning to get a hold on my problems now. Of course it was several >> problems as it usual are if you don't find the error quickly. First I have >> increased the hardware stack to 20 as it was overflowing. But know I have >> noticed that at entering a timer overflow interrupt, the interrupt routine >> is writing in my registers. >> >> Here is the first line, copied from Studio so you can see C and assembler: >> @0000080E: SampleRateTimerOverflowInt >> 329: void SampleRateTimerOverflowInt(void) >> +0000080E: D48F RCALL PC+0x0490 Relative call subroutine >> >> The RCALL goes here: >> +00000C9E: 920A ST -Y,R0 Store indirect and >> predecrement >> +00000C9F: 921A ST -Y,R1 Store indirect and >> predecrement >> +00000CA0: 922A ST -Y,R2 Store indirect and >> predecrement >> +00000CA1: 923A ST -Y,R3 Store indirect and >> predecrement >> +00000CA2: 924A ST -Y,R4 Store indirect and >> predecrement >> +00000CA3: 925A ST -Y,R5 Store indirect and >> predecrement >> +00000CA4: 926A ST -Y,R6 Store indirect and >> predecrement >> +00000CA5: 927A ST -Y,R7 Store indirect and >> predecrement >> +00000CA6: 928A ST -Y,R8 Store indirect and >> predecrement >> +00000CA7: 929A ST -Y,R9 Store indirect and >> predecrement >> +00000CA8: 930A ST -Y,R16 Store indirect and >> predecrement >> +00000CA9: 931A ST -Y,R17 Store indirect and >> predecrement >> +00000CAA: 932A ST -Y,R18 Store indirect and >> predecrement >> +00000CAB: 933A ST -Y,R19 Store indirect and >> predecrement >> +00000CAC: 938A ST -Y,R24 Store indirect and >> predecrement >> +00000CAD: 939A ST -Y,R25 Store indirect and >> predecrement >> +00000CAE: 93AA ST -Y,R26 Store indirect and >> predecrement >> +00000CAF: 93BA ST -Y,R27 Store indirect and >> predecrement >> +00000CB0: 93EA ST -Y,R30 Store indirect and >> predecrement >> +00000CB1: 93FA ST -Y,R31 Store indirect and >> predecrement >> +00000CB2: B60F IN R0,0x3F In from I/O location >> +00000CB3: 920A ST -Y,R0 Store indirect and >> predecrement >> +00000CB4: 9508 RET Subroutine return >> >> The subroutine is obviously saving all registers. The question is there? Y >> is 0xBE, counting down for each save. And yes, 0xBE are right into my >> registers. >> >> What should I look for to solve this? >> >> /Bengt >> >> >> _______________________________________________ >> 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 - http://www.avg.com > Version: 8.0.138 / Virus Database: 270.6.3/1612 - Release Date: 2008-08-14 18:03 > > > > From bobgardner at aol.com Fri Aug 15 10:31:14 2008 From: bobgardner at aol.com (bobgardner@aol.com) Date: Fri Aug 15 11:34:13 2008 Subject: [Icc-avr] format strings in flash Message-ID: <8CACD13DA299CF2-1F60-1DBA@FWM-D21.sysops.aol.com> If I check 'all strings in flash', I assume all my cprintf format strings are stored in flash. Does the compiler reuse the strings by checking to see if this one is a dup of one already stored? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20080815/20f0aa69/attachment.html From bobgardner at aol.com Fri Aug 15 10:54:12 2008 From: bobgardner at aol.com (bobgardner@aol.com) Date: Fri Aug 15 11:57:01 2008 Subject: [Icc-avr] Saving floating point constants in flash Message-ID: <8CACD170F710AF2-12BC-1F42@MBLK-M13.sysops.aol.com> Consider 'assigning' an integer to an fp var like x=3; or using integer numbers in an fp expression like y=13x+7; I notice that the compiler loads the int and calls int2fp. I assume loading the float constants from flash must surely be faster than calling a subroutine, so adding a decimal point in that expression like this y=13.0*x+7.0; should load the fp numbers from flash. If I use a number like 13.0 several times, does the compiler keep track of all the fp constants and reuse them when possible? Trying to squeeze 10 lbs of stuff into a 5lb bag..... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20080815/cd5f951b/attachment.html From richard-lists at imagecraft.com Fri Aug 15 11:10:15 2008 From: richard-lists at imagecraft.com (Richard Man) Date: Fri Aug 15 12:13:44 2008 Subject: [Icc-avr] format strings in flash In-Reply-To: <8CACD13DA299CF2-1F60-1DBA@FWM-D21.sysops.aol.com> References: <8CACD13DA299CF2-1F60-1DBA@FWM-D21.sysops.aol.com> Message-ID: <200808151913.m7FJDhZx065688@mail.imagecraft.com> Only within the same source file. At 10:31 AM 8/15/2008, bobgardner@aol.com wrote: >If I check 'all strings in flash', I assume all my cprintf format >strings are stored in flash. Does the compiler reuse the strings by >checking to see if this one is a dup of one already stored? // richard (This email is for mailing lists. To reach me directly, please use richard at imagecraft.com) From j_baraclough at zetnet.co.uk Fri Aug 15 11:23:05 2008 From: j_baraclough at zetnet.co.uk (John Baraclough) Date: Fri Aug 15 12:26:33 2008 Subject: [Icc-avr] format strings in flash In-Reply-To: <8CACD13DA299CF2-1F60-1DBA@FWM-D21.sysops.aol.com> References: <8CACD13DA299CF2-1F60-1DBA@FWM-D21.sysops.aol.com> Message-ID: <48A5C989.7080709@zetnet.co.uk> Sorry Bob but the answer is 'Yes' & 'No'. All identical strings in the same source file will be reduced to a single instantiation. But, because the compiler only looks at one file at a time this does not happen across files and the linker isn't aware of the string contents so cannot optimise to this level. You are much better to define the string in a single header file and then access it by label; __flash unsigned char FloatString[] = "%4.1f"; csprintf(OutBuffer, FloatString, FloatValue); All the best for now, John bobgardner@aol.com wrote: > If I check 'all strings in flash', I assume all my cprintf format > strings are stored in flash. Does the compiler reuse the strings by > checking to see if this one is a dup of one already stored? > ------------------------------------------------------------------------ > It's time to go back to school! Get the latest trends and gadgets that > make the grade on AOL Shopping > . > ------------------------------------------------------------------------ > > _______________________________________________ > Icc-avr mailing list > Icc-avr@imagecraft.com > http://dragonsgate.net/mailman/listinfo/icc-avr > From j_baraclough at zetnet.co.uk Fri Aug 15 11:27:27 2008 From: j_baraclough at zetnet.co.uk (John Baraclough) Date: Fri Aug 15 12:30:57 2008 Subject: [Icc-avr] Saving floating point constants in flash In-Reply-To: <8CACD170F710AF2-12BC-1F42@MBLK-M13.sysops.aol.com> References: <8CACD170F710AF2-12BC-1F42@MBLK-M13.sysops.aol.com> Message-ID: <48A5CA8F.5010801@zetnet.co.uk> As the previous post, define the values as a Flash constants and then access them by label. __flash float Thirteen = 13.0; __flash float Seven = 7.0; y = ((float)Thirteen * x) + Seven; All the best for now, John bobgardner@aol.com wrote: > Consider 'assigning' an integer to an fp var like x=3; or using > integer numbers in an fp expression like y=13x+7; > I notice that the compiler loads the int and calls int2fp. I assume > loading the float constants from flash must surely be faster than > calling a subroutine, so adding a decimal point in that expression > like this y=13.0*x+7.0; should load the fp numbers from flash. If I > use a number like 13.0 several times, does the compiler keep track of > all the fp constants and reuse them when possible? Trying to squeeze > 10 lbs of stuff into a 5lb bag..... > ------------------------------------------------------------------------ > It's time to go back to school! Get the latest trends and gadgets that > make the grade on AOL Shopping > . > ------------------------------------------------------------------------ > > _______________________________________________ > Icc-avr mailing list > Icc-avr@imagecraft.com > http://dragonsgate.net/mailman/listinfo/icc-avr > From richard-lists at imagecraft.com Fri Aug 15 11:37:05 2008 From: richard-lists at imagecraft.com (Richard Man) Date: Fri Aug 15 12:40:34 2008 Subject: SV: [Icc-avr] Stack problems In-Reply-To: <0C3FA4B69B124EF8B17B390F7467971E@Shagrat> References: <664A08FA68194943BDD11F841E7D55F0@Shagrat> <200808150948.m7F9mkkN058145@mail.imagecraft.com> <05EF9FFB331A47DB916A8398F28BCF45@Shagrat> <66680761C9744738A5BC9550E934E10E@Shagrat> <0C3FA4B69B124EF8B17B390F7467971E@Shagrat> Message-ID: <200808151940.m7FJeXQY066103@mail.imagecraft.com> Bengt, the usual joke is that C gives you enough rope to hang yourself. To wit: foo() { char a[10]; bar(a); } in a different .c file bar(char *a) { int i; ... a[i] = ... } Where does a[i] write to? Well, it depends on "i" and "i" can be anything, a valid index from 0 to 9, or -1000, or 10000. When i is invalid, surely it chomps on some memory somewhere. It could be your IO registers, your stack, your data, your CPU register.... At 04:25 AM 8/15/2008, Bengt Ragnemalm wrote: >Sorry, this was of course the same reason that before, the big local array. >After changing into one global this problem disappeared. But maybe someone >could describe this a little so I understand what happened? The stack >checking bytes was not overwritten. // richard (This email is for mailing lists. To reach me directly, please use richard at imagecraft.com) From j_baraclough at zetnet.co.uk Sat Aug 16 12:32:07 2008 From: j_baraclough at zetnet.co.uk (John Baraclough) Date: Sat Aug 16 13:35:49 2008 Subject: [Icc-avr] ATmega8 hardware problem In-Reply-To: <200808151940.m7FJeXQY066103@mail.imagecraft.com> References: <664A08FA68194943BDD11F841E7D55F0@Shagrat> <200808150948.m7F9mkkN058145@mail.imagecraft.com> <05EF9FFB331A47DB916A8398F28BCF45@Shagrat> <66680761C9744738A5BC9550E934E10E@Shagrat> <0C3FA4B69B124EF8B17B390F7467971E@Shagrat> <200808151940.m7FJeXQY066103@mail.imagecraft.com> Message-ID: <48A72B37.9030702@zetnet.co.uk> Hi All, I've posted this question on AvrFreaks but nobody has replied so I thought I would try here. I'm using an ATmega8 in a small application with a 10-way DIP switch. Six of the switches are on PortC and the internal pull-ups are fine on this port. However, the remaining four switches are on Port D and I have a problem with getting the internal pull-ups to work on bits 5, 6 7 & 1. The data sheet implies that the pull-ups are present on these pins but I don't seem to be able to switch them on. The problem has been solved by adding external pull-ups to these pins, but I'm curious to know if anyone else has had a similar problem. All the best for now, John From robertrade at yahoo.com Sun Aug 17 16:16:57 2008 From: robertrade at yahoo.com (Robert Rademacher) Date: Sun Aug 17 17:19:41 2008 Subject: [Icc-avr] ATmega8 hardware problem (John Baraclough) Message-ID: <967881.33845.qm@web65710.mail.ac4.yahoo.com> Hi, "I'm using an ATmega8 in a small application with a 10-way DIP switch. Six of the switches are on PortC and the internal pull-ups are fine on this port. However, the remaining four switches are on Port D and I have a problem with getting the internal pull-ups to work on bits 5, 6 7 & 1. The data sheet implies that the pull-ups are present on these pins but I don't seem to be able to switch them on." PORTC = 0x7F; DDRC = 0x00; PORTD = 0xE1; DDRD = 0x00; may work with your 10 pos DIP switch. Robert -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20080817/1aea10d6/attachment.html From benra at imt.liu.se Sun Aug 17 23:58:00 2008 From: benra at imt.liu.se (Bengt Ragnemalm) Date: Mon Aug 18 01:00:24 2008 Subject: SV: [Icc-avr] ATmega8 hardware problem In-Reply-To: <48A72B37.9030702@zetnet.co.uk> References: <664A08FA68194943BDD11F841E7D55F0@Shagrat> <200808150948.m7F9mkkN058145@mail.imagecraft.com> <05EF9FFB331A47DB916A8398F28BCF45@Shagrat> <66680761C9744738A5BC9550E934E10E@Shagrat> <0C3FA4B69B124EF8B17B390F7467971E@Shagrat><200808151940.m7FJeXQY066103@mail.imagecraft.com> <48A72B37.9030702@zetnet.co.uk> Message-ID: <73598760780842B0B614BDBA3B05F690@Shagrat> I we assume that you have defined the registers correctly for turning the pull-ups (the corresponding bit in PORTD shall be set) on I would take a search in the entire datasheet for the word "pull-up". Check the the secondary function of the PORT D pins. Some functions may turn pull-ups off. Or it could be that the internal value are to high (up to 50k). Also check the status of the PUD bit in SFIOR at the time you use PORTD Or it could be that the AVR is damaged. /Bengt > -----Ursprungligt meddelande----- > Fr?n: icc-avr-bounces@imagecraft.com [mailto:icc-avr- > bounces@imagecraft.com] F?r John Baraclough > Skickat: den 16 augusti 2008 21:32 > Till: Discussion list for ICCAVR and ICCtiny Users. You do NOT need > tosubscribe to icc-announce if you are a member of this. > ?mne: [Icc-avr] ATmega8 hardware problem > > Hi All, > > I've posted this question on AvrFreaks but nobody has replied so I > thought I would try here. > > I'm using an ATmega8 in a small application with a 10-way DIP switch. > Six of the switches are on PortC and the internal pull-ups are fine on > this port. However, the remaining four switches are on Port D and I have > a problem with getting the internal pull-ups to work on bits 5, 6 7 & 1. > The data sheet implies that the pull-ups are present on these pins but I > don't seem to be able to switch them on. > > The problem has been solved by adding external pull-ups to these pins, > but I'm curious to know if anyone else has had a similar problem. > > All the best for now, > John > > _______________________________________________ > Icc-avr mailing list > Icc-avr@imagecraft.com > http://dragonsgate.net/mailman/listinfo/icc-avr From byron at inhep.com Mon Aug 18 00:03:10 2008 From: byron at inhep.com (Byron Loader) Date: Mon Aug 18 01:06:25 2008 Subject: [Icc-avr] ATmega8 hardware problem (John Baraclough) In-Reply-To: <967881.33845.qm@web65710.mail.ac4.yahoo.com> Message-ID: Have you ruled out Alternate Pin Functions on those Pins? -----Original Message----- From: icc-avr-bounces@imagecraft.com [mailto:icc-avr-bounces@imagecraft.com] On Behalf Of Robert Rademacher Sent: Monday, August 18, 2008 1:17 AM To: icc-avr@imagecraft.com Subject: [Icc-avr] ATmega8 hardware problem (John Baraclough) Hi, "I'm using an ATmega8 in a small application with a 10-way DIP switch. Six of the switches are on PortC and the internal pull-ups are fine on this port. However, the remaining four switches are on Port D and I have a problem with getting the internal pull-ups to work on bits 5, 6 7 & 1. The data sheet implies that the pull-ups are present on these pins but I don't seem to be able to switch them on." PORTC = 0x7F; DDRC = 0x00; PORTD = 0xE1; DDRD = 0x00; may work with your 10 pos DIP switch. Robert -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20080818/cd2188f4/attachment.html From benra at imt.liu.se Mon Aug 18 00:30:45 2008 From: benra at imt.liu.se (Bengt Ragnemalm) Date: Mon Aug 18 01:33:10 2008 Subject: SV: SV: [Icc-avr] Stack problems In-Reply-To: <0jszZ9gS1j6Ir7K4DQnQhv9LygS6i61ZxxKCJjf2Bco@akmail> References: <05EF9FFB331A47DB916A8398F28BCF45@Shagrat> <66680761C9744738A5BC9550E934E10E@Shagrat> <0C3FA4B69B124EF8B17B390F7467971E@Shagrat> <0jszZ9gS1j6Ir7K4DQnQhv9LygS6i61ZxxKCJjf2Bco@akmail> Message-ID: <1F71428AE33640F396E343CFEE741BD5@Shagrat> This was (maybe by mistake) posted only to me but I post the answer to the group. Yes, you are right. I have small checking function that I do call. Thank you for reminding me, I have avoided this elsewhere but have forgotten this here. /Bengt > -----Ursprungligt meddelande----- > Fr?n: Johannes Assenbaum [mailto:jassenbaum@htp-tel.de] > Skickat: den 15 augusti 2008 23:25 > Till: benra@imt.liu.se > ?mne: Re: SV: [Icc-avr] Stack problems > > Register saving looks like you are calling c function(s) from within an > interrupt handler. This may be suboptimal on small controller targets like > AVRs... > > Best regards, > Johannes > > > > Sorry, this was of course the same reason that before, the big local > array. > > After changing into one global this problem disappeared. But maybe > someone > > could describe this a little so I understand what happened? The stack > > checking bytes was not overwritten. > > > /Bengt > > >> -----Ursprungligt meddelande----- > >> Fr?n: icc-avr-bounces@imagecraft.com [mailto:icc-avr- > >> bounces@imagecraft.com] F?r Bengt Ragnemalm > >> Skickat: den 15 augusti 2008 13:03 > >> Till: benra@imt.liu.se; 'Discussion list for ICCAVR and ICCtiny Users. > You > >> do NOT needtosubscribeto icc-announce if you are a member of this.' > >> ?mne: [Icc-avr] Stack problems > >> > >> I am beginning to get a hold on my problems now. Of course it was > several > >> problems as it usual are if you don't find the error quickly. First I > have > >> increased the hardware stack to 20 as it was overflowing. But know I > have > >> noticed that at entering a timer overflow interrupt, the interrupt > routine > >> is writing in my registers. > >> > >> Here is the first line, copied from Studio so you can see C and > assembler: > >> @0000080E: SampleRateTimerOverflowInt > >> 329: void SampleRateTimerOverflowInt(void) > >> +0000080E: D48F RCALL PC+0x0490 Relative call > subroutine > >> > >> The RCALL goes here: > >> +00000C9E: 920A ST -Y,R0 Store indirect and > >> predecrement > >> +00000C9F: 921A ST -Y,R1 Store indirect and > >> predecrement > >> +00000CA0: 922A ST -Y,R2 Store indirect and > >> predecrement > >> +00000CA1: 923A ST -Y,R3 Store indirect and > >> predecrement > >> +00000CA2: 924A ST -Y,R4 Store indirect and > >> predecrement > >> +00000CA3: 925A ST -Y,R5 Store indirect and > >> predecrement > >> +00000CA4: 926A ST -Y,R6 Store indirect and > >> predecrement > >> +00000CA5: 927A ST -Y,R7 Store indirect and > >> predecrement > >> +00000CA6: 928A ST -Y,R8 Store indirect and > >> predecrement > >> +00000CA7: 929A ST -Y,R9 Store indirect and > >> predecrement > >> +00000CA8: 930A ST -Y,R16 Store indirect and > >> predecrement > >> +00000CA9: 931A ST -Y,R17 Store indirect and > >> predecrement > >> +00000CAA: 932A ST -Y,R18 Store indirect and > >> predecrement > >> +00000CAB: 933A ST -Y,R19 Store indirect and > >> predecrement > >> +00000CAC: 938A ST -Y,R24 Store indirect and > >> predecrement > >> +00000CAD: 939A ST -Y,R25 Store indirect and > >> predecrement > >> +00000CAE: 93AA ST -Y,R26 Store indirect and > >> predecrement > >> +00000CAF: 93BA ST -Y,R27 Store indirect and > >> predecrement > >> +00000CB0: 93EA ST -Y,R30 Store indirect and > >> predecrement > >> +00000CB1: 93FA ST -Y,R31 Store indirect and > >> predecrement > >> +00000CB2: B60F IN R0,0x3F In from I/O location > >> +00000CB3: 920A ST -Y,R0 Store indirect and > >> predecrement > >> +00000CB4: 9508 RET Subroutine return > >> > >> The subroutine is obviously saving all registers. The question is > there? Y > >> is 0xBE, counting down for each save. And yes, 0xBE are right into my > >> registers. > >> > >> What should I look for to solve this? > >> > >> /Bengt > >> > >> > >> _______________________________________________ > >> 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 From benra at imt.liu.se Mon Aug 18 00:48:02 2008 From: benra at imt.liu.se (Bengt Ragnemalm) Date: Mon Aug 18 01:50:31 2008 Subject: SV: SV: [Icc-avr] Stack problems In-Reply-To: <200808151940.m7FJeXQY066103@mail.imagecraft.com> References: <664A08FA68194943BDD11F841E7D55F0@Shagrat><200808150948.m7F9mkkN058145@mail.imagecraft.com><05EF9FFB331A47DB916A8398F28BCF45@Shagrat><66680761C9744738A5BC9550E934E10E@Shagrat><0C3FA4B69B124EF8B17B390F7467971E@Shagrat> <200808151940.m7FJeXQY066103@mail.imagecraft.com> Message-ID: <4C4242E0F9C240559AAF9C00FDCF9E4B@Shagrat> Yes, you are absolutely right. So the programmer must have good knowledge of about how long, how thick and the material strength of the rope? Damn, and I who thought I used a ladder. (C=rope, Pascal=ladder, Basic=elevator, brick wall=assembler???) A question: Does this mean that the compiler never have any control over if the RAM used for local variables by a single function are more than total RAM-global variables? This is what happened. I couldn't see how this can be such a big deal for the compiler. The code actually runs fine even after the "crash", it depends on what registers are overwritten (of course). It would have been easier to find if it did not. The reason for that the Stack Checking function didn't find anything was that the code at the time of using the 512 byte string in one step moved the RAM usage outside the RAM. And as the program didn't filled the entire string the Stack Checking bytes was never overwritten. It would of course resulted in bigger problems in the future as more of the string will be used. Maybe it could be that the compiler have problem of freeing the RAM space for the first array before the RAM space for the second array are used. A local array should be to prefer as it would use less RAM in the total application but a global may be necessary if that is the only way to see that the function defines to much RAM. The code is something like this: void Function(void) { unsigned char array1[512]; unsigned char array2[512]; unsigned char sendData; ... for(...) { array1[...]=...; // Reading values to array 1 array1[...]=...; ... } if (globalFlag) { for(...) { sendData = array1[...]; } else { SendArray(array1); // Last usage of array 1 array2[...]=; // Some usage of array 2 array2[...]=; ... SendArray(array2); // Last usage of array 2 } } /Bengt > -----Ursprungligt meddelande----- > Fr?n: icc-avr-bounces@imagecraft.com [mailto:icc-avr- > bounces@imagecraft.com] F?r Richard Man > Skickat: den 15 augusti 2008 20:37 > Till: icc-avr@imagecraft.com > ?mne: Re: SV: [Icc-avr] Stack problems > > Bengt, the usual joke is that C gives you enough rope to hang yourself. To > wit: > > foo() { char a[10]; > bar(a); > } > > in a different .c file > > bar(char *a) { > int i; > ... > a[i] = ... > } > > Where does a[i] write to? Well, it depends on "i" and "i" can be > anything, a valid index from 0 to 9, or -1000, or 10000. When i is > invalid, surely it chomps on some memory somewhere. It could be your > IO registers, your stack, your data, your CPU register.... > > At 04:25 AM 8/15/2008, Bengt Ragnemalm wrote: > >Sorry, this was of course the same reason that before, the big local > array. > >After changing into one global this problem disappeared. But maybe > someone > >could describe this a little so I understand what happened? The stack > >checking bytes was not overwritten. > > // 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 richard-lists at imagecraft.com Mon Aug 18 01:24:34 2008 From: richard-lists at imagecraft.com (Richard Man) Date: Mon Aug 18 02:27:28 2008 Subject: SV: SV: [Icc-avr] Stack problems In-Reply-To: <4C4242E0F9C240559AAF9C00FDCF9E4B@Shagrat> References: <664A08FA68194943BDD11F841E7D55F0@Shagrat> <200808150948.m7F9mkkN058145@mail.imagecraft.com> <05EF9FFB331A47DB916A8398F28BCF45@Shagrat> <66680761C9744738A5BC9550E934E10E@Shagrat> <0C3FA4B69B124EF8B17B390F7467971E@Shagrat> <200808151940.m7FJeXQY066103@mail.imagecraft.com> <4C4242E0F9C240559AAF9C00FDCF9E4B@Shagrat> Message-ID: <200808180927.m7I9RRxm017684@mail.imagecraft.com> The compiler does lifetime analysis for simple variables, but almost no compiler does analysis for aggregates. Why not? Consider this? void Function(void) { unsigned char array1[512]; unsigned char array2[512]; ... array1[512] = ...; this *may* write to the first element of array2, of what if the programmer writes if (cond) p = array1; else p = array2; point is the problem is A LOT more difficult than one may think. I'd welcome anyone who thinks writing a compiler is easy to produce a production quality compiler that people can rely on. You have to know the limitations of the microcontroller and the power+limitations of the language you use. There is no magic bullet. I am not so sure why you consider it is "easy" to write a heroic compiler, rather than understanding the limitations of the hardware and the language impose. You cannot pick and choose the subset of C that gives you the best code for *your* writing style, you must live with all the power that C gives you but you must also know its limitations. At 12:48 AM 8/18/2008, Bengt Ragnemalm wrote: >Yes, you are absolutely right. So the programmer must have good knowledge of >about how long, how thick and the material strength of the rope? Damn, and I >who thought I used a ladder. (C=rope, Pascal=ladder, Basic=elevator, brick >wall=assembler???) > >A question: Does this mean that the compiler never have any control over if >the RAM used for local variables by a single function are more than total >RAM-global variables? This is what happened. I couldn't see how this can be >such a big deal for the compiler. > >The code actually runs fine even after the "crash", it depends on what >registers are overwritten (of course). It would have been easier to find if >it did not. The reason for that the Stack Checking function didn't find >anything was that the code at the time of using the 512 byte string in one >step moved the RAM usage outside the RAM. And as the program didn't filled >the entire string the Stack Checking bytes was never overwritten. It would >of course resulted in bigger problems in the future as more of the string >will be used. > >Maybe it could be that the compiler have problem of freeing the RAM space >for the first array before the RAM space for the second array are used. A >local array should be to prefer as it would use less RAM in the total >application but a global may be necessary if that is the only way to see >that the function defines to much RAM. > >The code is something like this: > >void Function(void) >{ > unsigned char array1[512]; > unsigned char array2[512]; > unsigned char sendData; > ... > > for(...) > { > array1[...]=...; // Reading values to array 1 > array1[...]=...; > ... > } > if (globalFlag) > { > for(...) > { > sendData = array1[...]; > } > else > { > SendArray(array1); // Last usage of array 1 > array2[...]=; // Some usage of array 2 > array2[...]=; > ... > SendArray(array2); // Last usage of array 2 > } >} > >/Bengt > // richard (This email is for mailing lists. To reach me directly, please use richard at imagecraft.com) From j_baraclough at zetnet.co.uk Mon Aug 18 02:13:22 2008 From: j_baraclough at zetnet.co.uk (John Baraclough) Date: Mon Aug 18 03:16:11 2008 Subject: SV: [Icc-avr] ATmega8 hardware problem In-Reply-To: <73598760780842B0B614BDBA3B05F690@Shagrat> References: <664A08FA68194943BDD11F841E7D55F0@Shagrat> <200808150948.m7F9mkkN058145@mail.imagecraft.com> <05EF9FFB331A47DB916A8398F28BCF45@Shagrat> <66680761C9744738A5BC9550E934E10E@Shagrat> <0C3FA4B69B124EF8B17B390F7467971E@Shagrat><200808151940.m7FJeXQY066103@mail.imagecraft.com> <48A72B37.9030702@zetnet.co.uk> <73598760780842B0B614BDBA3B05F690@Shagrat> Message-ID: <48A93D32.90002@zetnet.co.uk> Yes, I already searched the data sheet to no avail. It has been suggested on AvrFreaks that the Analog Comparator being active (which is the default state) may be the cause. Unfortunately I now have external pull-ups added, so I can't see if disabling this will help. However I will come back to this once the current project is finished and let you know what I find. All the best for now, John Bengt Ragnemalm wrote: > I we assume that you have defined the registers correctly for turning the > pull-ups (the corresponding bit in PORTD shall be set) on I would take a > search in the entire datasheet for the word "pull-up". Check the the > secondary function of the PORT D pins. Some functions may turn pull-ups off. > Or it could be that the internal value are to high (up to 50k). > > Also check the status of the PUD bit in SFIOR at the time you use PORTD > > Or it could be that the AVR is damaged. > > /Bengt > From benra at imt.liu.se Mon Aug 18 02:59:17 2008 From: benra at imt.liu.se (Bengt Ragnemalm) Date: Mon Aug 18 04:01:41 2008 Subject: SV: SV: SV: [Icc-avr] Stack problems In-Reply-To: <200808180927.m7I9RRxm017684@mail.imagecraft.com> References: <664A08FA68194943BDD11F841E7D55F0@Shagrat><200808150948.m7F9mkkN058145@mail.imagecraft.com><05EF9FFB331A47DB916A8398F28BCF45@Shagrat><66680761C9744738A5BC9550E934E10E@Shagrat><0C3FA4B69B124EF8B17B390F7467971E@Shagrat><200808151940.m7FJeXQY066103@mail.imagecraft.com><4C4242E0F9C240559AAF9C00FDCF9E4B@Shagrat> <200808180927.m7I9RRxm017684@mail.imagecraft.com> Message-ID: Thank you Richard for a good explanation. Know I understands why this example IS a big deal for the compiler. I understand that it is extremely complicated to make a compiler that can do everything the customer wants it to do. Especially customers like me who am not so skilled in the limitations and the possibilities of the C language. I hope that you can live with getting stupid questions. I refuse to feel ashamed to asking them. The best with stupid questions is that others dare to tell their stupid questions, some that I can answer. And thank you for your absolutely superb support. Best regards, Bengt > -----Ursprungligt meddelande----- > Fr?n: icc-avr-bounces@imagecraft.com [mailto:icc-avr- > bounces@imagecraft.com] F?r Richard Man > Skickat: den 18 augusti 2008 10:25 > Till: icc-avr@imagecraft.com > ?mne: Re: SV: SV: [Icc-avr] Stack problems > > The compiler does lifetime analysis for simple variables, but almost > no compiler does analysis for aggregates. Why not? Consider this? > > void Function(void) > { > unsigned char array1[512]; > unsigned char array2[512]; > ... > > array1[512] = ...; > > this *may* write to the first element of array2, of what if the > programmer writes > > if (cond) > p = array1; > else > p = array2; > > point is the problem is A LOT more difficult than one may think. I'd > welcome anyone who thinks writing a compiler is easy to produce a > production quality compiler that people can rely on. You have to know > the limitations of the microcontroller and the power+limitations of > the language you use. There is no magic bullet. I am not so sure why > you consider it is "easy" to write a heroic compiler, rather than > understanding the limitations of the hardware and the language > impose. You cannot pick and choose the subset of C that gives you the > best code for *your* writing style, you must live with all the power > that C gives you but you must also know its limitations. > > At 12:48 AM 8/18/2008, Bengt Ragnemalm wrote: > >Yes, you are absolutely right. So the programmer must have good knowledge > of > >about how long, how thick and the material strength of the rope? Damn, > and I > >who thought I used a ladder. (C=rope, Pascal=ladder, Basic=elevator, > brick > >wall=assembler???) > > > >A question: Does this mean that the compiler never have any control over > if > >the RAM used for local variables by a single function are more than total > >RAM-global variables? This is what happened. I couldn't see how this can > be > >such a big deal for the compiler. > > > >The code actually runs fine even after the "crash", it depends on what > >registers are overwritten (of course). It would have been easier to find > if > >it did not. The reason for that the Stack Checking function didn't find > >anything was that the code at the time of using the 512 byte string in > one > >step moved the RAM usage outside the RAM. And as the program didn't > filled > >the entire string the Stack Checking bytes was never overwritten. It > would > >of course resulted in bigger problems in the future as more of the string > >will be used. > > > >Maybe it could be that the compiler have problem of freeing the RAM space > >for the first array before the RAM space for the second array are used. A > >local array should be to prefer as it would use less RAM in the total > >application but a global may be necessary if that is the only way to see > >that the function defines to much RAM. > > > >The code is something like this: > > > >void Function(void) > >{ > > unsigned char array1[512]; > > unsigned char array2[512]; > > unsigned char sendData; > > ... > > > > for(...) > > { > > array1[...]=...; // Reading values to array 1 > > array1[...]=...; > > ... > > } > > if (globalFlag) > > { > > for(...) > > { > > sendData = array1[...]; > > } > > else > > { > > SendArray(array1); // Last usage of array 1 > > array2[...]=; // Some usage of array 2 > > array2[...]=; > > ... > > SendArray(array2); // Last usage of array 2 > > } > >} > > > >/Bengt > > > > // 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 benra at imt.liu.se Mon Aug 18 03:03:35 2008 From: benra at imt.liu.se (Bengt Ragnemalm) Date: Mon Aug 18 04:06:00 2008 Subject: SV: SV: [Icc-avr] ATmega8 hardware problem In-Reply-To: <48A93D32.90002@zetnet.co.uk> References: <664A08FA68194943BDD11F841E7D55F0@Shagrat> <200808150948.m7F9mkkN058145@mail.imagecraft.com> <05EF9FFB331A47DB916A8398F28BCF45@Shagrat> <66680761C9744738A5BC9550E934E10E@Shagrat> <0C3FA4B69B124EF8B17B390F7467971E@Shagrat><200808151940.m7FJeXQY066103@mail.imagecraft.com> <48A72B37.9030702@zetnet.co.uk><73598760780842B0B614BDBA3B05F690@Shagrat> <48A93D32.90002@zetnet.co.uk> Message-ID: <708AB538191746EB9F5C96BDB6806248@Shagrat> The comparator should not be the problem. Enabling the pull-up may screw that comparator if you are measuring high impedance sources but I do not think it should disable the pull-ups. Let us know in the future what you may find. If you can disable the source of the signal you can just take a ohm-meter and measure the value of your pull-up in different situations like with and without AC and with or without internal pull-ups. /Bengt > -----Ursprungligt meddelande----- > Fr?n: icc-avr-bounces@imagecraft.com [mailto:icc-avr- > bounces@imagecraft.com] F?r John Baraclough > Skickat: den 18 augusti 2008 11:13 > Till: benra@imt.liu.se; Discussion list for ICCAVR and ICCtiny Users. You > do NOT need tosubscribe to icc-announce if you are a member of this. > ?mne: Re: SV: [Icc-avr] ATmega8 hardware problem > > Yes, I already searched the data sheet to no avail. It has been > suggested on AvrFreaks that the Analog Comparator being active (which is > the default state) may be the cause. Unfortunately I now have external > pull-ups added, so I can't see if disabling this will help. However I > will come back to this once the current project is finished and let you > know what I find. > > All the best for now, > John > > > Bengt Ragnemalm wrote: > > I we assume that you have defined the registers correctly for turning > the > > pull-ups (the corresponding bit in PORTD shall be set) on I would take a > > search in the entire datasheet for the word "pull-up". Check the the > > secondary function of the PORT D pins. Some functions may turn pull-ups > off. > > Or it could be that the internal value are to high (up to 50k). > > > > Also check the status of the PUD bit in SFIOR at the time you use PORTD > > > > Or it could be that the AVR is damaged. > > > > /Bengt > > > > _______________________________________________ > Icc-avr mailing list > Icc-avr@imagecraft.com > http://dragonsgate.net/mailman/listinfo/icc-avr From webbra.mlist at verizon.net Mon Aug 18 05:27:03 2008 From: webbra.mlist at verizon.net (Rich Webb) Date: Mon Aug 18 06:29:55 2008 Subject: [Icc-avr] Stack problems In-Reply-To: <200808180908.m7I98iHm017295@mail.imagecraft.com> References: <200808180908.m7I98iHm017295@mail.imagecraft.com> Message-ID: <48A96A97.40907@verizon.net> > A question: Does this mean that the compiler never have any control over if > the RAM used for local variables by a single function are more than total > RAM-global variables? This is what happened. I couldn't see how this can be > such a big deal for the compiler. I would imagine that to install that large of a safety net would require that the run-time image, and not the compiler, perform an explicit boundary check after each and every operation that accessed (or could access through indirection) any portion of the system RAM. Not absolutely sure that I'd want that much of a performance cost, although (especially for the JTAG-enabled AVRs) a compiler switch to turn on such a feature may be useful. Dangerous, though, to depend on something like that to catch problems after the fact. From Albert.vanVeen at pertronic.co.nz Mon Aug 18 13:18:54 2008 From: Albert.vanVeen at pertronic.co.nz (Albert vanVeen) Date: Mon Aug 18 14:22:19 2008 Subject: [Icc-avr] Stack problems In-Reply-To: <48A96A97.40907@verizon.net> References: <200808180908.m7I98iHm017295@mail.imagecraft.com> <48A96A97.40907@verizon.net> Message-ID: <5F8515C5ED67B6439B4F93D7B5E08A36063E20@sbs.pertronic.local> Many/most pascal compilers give you this sort of runtime checks. It may be an overhead you can't always afford, but a great help for prototyping (or some might say laziness). Albert. -----Original Message----- From: icc-avr-bounces@imagecraft.com [mailto:icc-avr-bounces@imagecraft.com] On Behalf Of Rich Webb Sent: Tuesday, August 19, 2008 12:27 AM To: icc-avr@imagecraft.com Subject: Re: [Icc-avr] Stack problems > A question: Does this mean that the compiler never have any control > over if the RAM used for local variables by a single function are more > than total RAM-global variables? This is what happened. I couldn't see > how this can be such a big deal for the compiler. I would imagine that to install that large of a safety net would require that the run-time image, and not the compiler, perform an explicit boundary check after each and every operation that accessed (or could access through indirection) any portion of the system RAM. Not absolutely sure that I'd want that much of a performance cost, although (especially for the JTAG-enabled AVRs) a compiler switch to turn on such a feature may be useful. Dangerous, though, to depend on something like that to catch problems after the fact. _______________________________________________ Icc-avr mailing list Icc-avr@imagecraft.com http://dragonsgate.net/mailman/listinfo/icc-avr Scanned by Bizo Email Filter From richard-lists at imagecraft.com Mon Aug 18 15:25:40 2008 From: richard-lists at imagecraft.com (Richard Man) Date: Mon Aug 18 16:29:20 2008 Subject: [Icc-avr] Stack problems In-Reply-To: <5F8515C5ED67B6439B4F93D7B5E08A36063E20@sbs.pertronic.local > References: <200808180908.m7I98iHm017295@mail.imagecraft.com> <48A96A97.40907@verizon.net> <5F8515C5ED67B6439B4F93D7B5E08A36063E20@sbs.pertronic.local> Message-ID: <200808182329.m7INTJBu034220@mail.imagecraft.com> It's also a lot more difficult to do for C due to pointer aliasing. At 01:18 PM 8/18/2008, Albert vanVeen wrote: >Many/most pascal compilers give you this sort of runtime checks. It may >be an overhead you can't always afford, but a great help for prototyping >(or some might say laziness). > >Albert. > // richard (This email is for mailing lists. To reach me directly, please use richard at imagecraft.com) From benra at imt.liu.se Thu Aug 21 05:55:35 2008 From: benra at imt.liu.se (Bengt Ragnemalm) Date: Thu Aug 21 06:57:57 2008 Subject: SV: SV: SV: [Icc-avr] Stack problems In-Reply-To: <200808180927.m7I9RRxm017684@mail.imagecraft.com> References: <664A08FA68194943BDD11F841E7D55F0@Shagrat><200808150948.m7F9mkkN058145@mail.imagecraft.com><05EF9FFB331A47DB916A8398F28BCF45@Shagrat><66680761C9744738A5BC9550E934E10E@Shagrat><0C3FA4B69B124EF8B17B390F7467971E@Shagrat><200808151940.m7FJeXQY066103@mail.imagecraft.com><4C4242E0F9C240559AAF9C00FDCF9E4B@Shagrat> <200808180927.m7I9RRxm017684@mail.imagecraft.com> Message-ID: <35ECDAA83E1C40C489CC77B94DEA242B@Shagrat> One more question about this. If I declare a local array that is larger than the RAM, I do not get an error. Is that because the compiler can not be sure that this array will actually be placed in RAM as it can point to anything? /Bengt > -----Ursprungligt meddelande----- > Fr?n: icc-avr-bounces@imagecraft.com [mailto:icc-avr- > bounces@imagecraft.com] F?r Richard Man > Skickat: den 18 augusti 2008 10:25 > Till: icc-avr@imagecraft.com > ?mne: Re: SV: SV: [Icc-avr] Stack problems > > The compiler does lifetime analysis for simple variables, but almost > no compiler does analysis for aggregates. Why not? Consider this? > > void Function(void) > { > unsigned char array1[512]; > unsigned char array2[512]; > ... > > array1[512] = ...; > > this *may* write to the first element of array2, of what if the > programmer writes > > if (cond) > p = array1; > else > p = array2; > > point is the problem is A LOT more difficult than one may think. I'd > welcome anyone who thinks writing a compiler is easy to produce a > production quality compiler that people can rely on. You have to know > the limitations of the microcontroller and the power+limitations of > the language you use. There is no magic bullet. I am not so sure why > you consider it is "easy" to write a heroic compiler, rather than > understanding the limitations of the hardware and the language > impose. You cannot pick and choose the subset of C that gives you the > best code for *your* writing style, you must live with all the power > that C gives you but you must also know its limitations. > > At 12:48 AM 8/18/2008, Bengt Ragnemalm wrote: > >Yes, you are absolutely right. So the programmer must have good knowledge > of > >about how long, how thick and the material strength of the rope? Damn, > and I > >who thought I used a ladder. (C=rope, Pascal=ladder, Basic=elevator, > brick > >wall=assembler???) > > > >A question: Does this mean that the compiler never have any control over > if > >the RAM used for local variables by a single function are more than total > >RAM-global variables? This is what happened. I couldn't see how this can > be > >such a big deal for the compiler. > > > >The code actually runs fine even after the "crash", it depends on what > >registers are overwritten (of course). It would have been easier to find > if > >it did not. The reason for that the Stack Checking function didn't find > >anything was that the code at the time of using the 512 byte string in > one > >step moved the RAM usage outside the RAM. And as the program didn't > filled > >the entire string the Stack Checking bytes was never overwritten. It > would > >of course resulted in bigger problems in the future as more of the string > >will be used. > > > >Maybe it could be that the compiler have problem of freeing the RAM space > >for the first array before the RAM space for the second array are used. A > >local array should be to prefer as it would use less RAM in the total > >application but a global may be necessary if that is the only way to see > >that the function defines to much RAM. > > > >The code is something like this: > > > >void Function(void) > >{ > > unsigned char array1[512]; > > unsigned char array2[512]; > > unsigned char sendData; > > ... > > > > for(...) > > { > > array1[...]=...; // Reading values to array 1 > > array1[...]=...; > > ... > > } > > if (globalFlag) > > { > > for(...) > > { > > sendData = array1[...]; > > } > > else > > { > > SendArray(array1); // Last usage of array 1 > > array2[...]=; // Some usage of array 2 > > array2[...]=; > > ... > > SendArray(array2); // Last usage of array 2 > > } > >} > > > >/Bengt > > > > // 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 andrew_166 at msn.com Thu Aug 21 06:25:55 2008 From: andrew_166 at msn.com (Andrew) Date: Thu Aug 21 07:28:45 2008 Subject: SV: SV: [Icc-avr] Stack problems References: <664A08FA68194943BDD11F841E7D55F0@Shagrat><200808150948.m7F9mkkN058145@mail.imagecraft.com><05EF9FFB331A47DB916A8398F28BCF45@Shagrat><66680761C9744738A5BC9550E934E10E@Shagrat><0C3FA4B69B124EF8B17B390F7467971E@Shagrat><200808151940.m7FJeXQY066103@mail.imagecraft.com><4C4242E0F9C240559AAF9C00FDCF9E4B@Shagrat><200808180927.m7I9RRxm017684@mail.imagecraft.com> <35ECDAA83E1C40C489CC77B94DEA242B@Shagrat> Message-ID: Hi, Surely at some stage a static variable will end up being placed in SDRAM, if the function that uses the variable is called, one would hope the complier tells the user the variable is too big. Although i did try this and the compiler did show me an error: -- void test (void) { static unsigned char Test[8192]; return; } Note; i am using a Atmega 640 (8K) of RAM So as far as i can see it works fine. Andy ----- Original Message ----- From: "Bengt Ragnemalm" To: "'Discussion list for ICCAVR and ICCtiny Users. You do NOT needtosubscribeto icc-announce if you are a member of this.'" Sent: Thursday, August 21, 2008 1:55 PM Subject: SV: SV: SV: [Icc-avr] Stack problems > One more question about this. > > If I declare a local array that is larger than the RAM, I do not get an > error. Is that because the compiler can not be sure that this array will > actually be placed in RAM as it can point to anything? > > /Bengt > >> -----Ursprungligt meddelande----- >> Fr?n: icc-avr-bounces@imagecraft.com [mailto:icc-avr- >> bounces@imagecraft.com] F?r Richard Man >> Skickat: den 18 augusti 2008 10:25 >> Till: icc-avr@imagecraft.com >> ?mne: Re: SV: SV: [Icc-avr] Stack problems >> >> The compiler does lifetime analysis for simple variables, but almost >> no compiler does analysis for aggregates. Why not? Consider this? >> >> void Function(void) >> { >> unsigned char array1[512]; >> unsigned char array2[512]; >> ... >> >> array1[512] = ...; >> >> this *may* write to the first element of array2, of what if the >> programmer writes >> >> if (cond) >> p = array1; >> else >> p = array2; >> >> point is the problem is A LOT more difficult than one may think. I'd >> welcome anyone who thinks writing a compiler is easy to produce a >> production quality compiler that people can rely on. You have to know >> the limitations of the microcontroller and the power+limitations of >> the language you use. There is no magic bullet. I am not so sure why >> you consider it is "easy" to write a heroic compiler, rather than >> understanding the limitations of the hardware and the language >> impose. You cannot pick and choose the subset of C that gives you the >> best code for *your* writing style, you must live with all the power >> that C gives you but you must also know its limitations. >> >> At 12:48 AM 8/18/2008, Bengt Ragnemalm wrote: >> >Yes, you are absolutely right. So the programmer must have good knowledge >> of >> >about how long, how thick and the material strength of the rope? Damn, >> and I >> >who thought I used a ladder. (C=rope, Pascal=ladder, Basic=elevator, >> brick >> >wall=assembler???) >> > >> >A question: Does this mean that the compiler never have any control over >> if >> >the RAM used for local variables by a single function are more than total >> >RAM-global variables? This is what happened. I couldn't see how this can >> be >> >such a big deal for the compiler. >> > >> >The code actually runs fine even after the "crash", it depends on what >> >registers are overwritten (of course). It would have been easier to find >> if >> >it did not. The reason for that the Stack Checking function didn't find >> >anything was that the code at the time of using the 512 byte string in >> one >> >step moved the RAM usage outside the RAM. And as the program didn't >> filled >> >the entire string the Stack Checking bytes was never overwritten. It >> would >> >of course resulted in bigger problems in the future as more of the string >> >will be used. >> > >> >Maybe it could be that the compiler have problem of freeing the RAM space >> >for the first array before the RAM space for the second array are used. A >> >local array should be to prefer as it would use less RAM in the total >> >application but a global may be necessary if that is the only way to see >> >that the function defines to much RAM. >> > >> >The code is something like this: >> > >> >void Function(void) >> >{ >> > unsigned char array1[512]; >> > unsigned char array2[512]; >> > unsigned char sendData; >> > ... >> > >> > for(...) >> > { >> > array1[...]=...; // Reading values to array 1 >> > array1[...]=...; >> > ... >> > } >> > if (globalFlag) >> > { >> > for(...) >> > { >> > sendData = array1[...]; >> > } >> > else >> > { >> > SendArray(array1); // Last usage of array 1 >> > array2[...]=; // Some usage of array 2 >> > array2[...]=; >> > ... >> > SendArray(array2); // Last usage of array 2 >> > } >> >} >> > >> >/Bengt >> > >> >> // 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 > > > _______________________________________________ > 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/20080821/545d433b/attachment.html From j_baraclough at zetnet.co.uk Thu Aug 21 07:44:44 2008 From: j_baraclough at zetnet.co.uk (John Baraclough) Date: Thu Aug 21 08:48:05 2008 Subject: SV: SV: SV: [Icc-avr] Stack problems In-Reply-To: <35ECDAA83E1C40C489CC77B94DEA242B@Shagrat> References: <664A08FA68194943BDD11F841E7D55F0@Shagrat><200808150948.m7F9mkkN058145@mail.imagecraft.com><05EF9FFB331A47DB916A8398F28BCF45@Shagrat><66680761C9744738A5BC9550E934E10E@Shagrat><0C3FA4B69B124EF8B17B390F7467971E@Shagrat><200808151940.m7FJeXQY066103@mail.imagecraft.com><4C4242E0F9C240559AAF9C00FDCF9E4B@Shagrat> <200808180927.m7I9RRxm017684@mail.imagecraft.com> <35ECDAA83E1C40C489CC77B94DEA242B@Shagrat> Message-ID: <48AD7F5C.9000805@zetnet.co.uk> Hi Bengt, I think you need to post a code snippet as your message is a liitle unclear. The first sentence says that you have declared an array, but the second implies that you have declared a pointer to an array. You need to tell us which you have done as declaring a pointer cannot possibly allow the compiler to know how large an array you will be accessing. All the best for now, John Bengt Ragnemalm wrote: > One more question about this. > > If I declare a local array that is larger than the RAM, I do not get an > error. Is that because the compiler can not be sure that this array will > actually be placed in RAM as it can point to anything? > > /Bengt > > From richard-lists at imagecraft.com Thu Aug 21 12:41:55 2008 From: richard-lists at imagecraft.com (Richard Man) Date: Thu Aug 21 13:44:51 2008 Subject: SV: SV: SV: [Icc-avr] Stack problems In-Reply-To: <35ECDAA83E1C40C489CC77B94DEA242B@Shagrat> References: <664A08FA68194943BDD11F841E7D55F0@Shagrat> <200808150948.m7F9mkkN058145@mail.imagecraft.com> <05EF9FFB331A47DB916A8398F28BCF45@Shagrat> <66680761C9744738A5BC9550E934E10E@Shagrat> <0C3FA4B69B124EF8B17B390F7467971E@Shagrat> <200808151940.m7FJeXQY066103@mail.imagecraft.com> <4C4242E0F9C240559AAF9C00FDCF9E4B@Shagrat> <200808180927.m7I9RRxm017684@mail.imagecraft.com> <35ECDAA83E1C40C489CC77B94DEA242B@Shagrat> Message-ID: <200808212044.m7LKioEw004305@mail.imagecraft.com> Currently, the compiler does not do any check on the local variables, because any checking would be at best a guess (unless it does full call tree analysis and layout all the SRAM usage). While it can clearly complain in the obvious cases, it will do a lousy job overall and then people will complain about false security. If you look at the View->"Map File Summary" it gives you an estimate on how big the software stack can be. Generally speaking, you shouldn't be pushing the limit of the SRAM, so it should be farily easy for you to see what your margins are. If you are really pushing the limit, you would need to check and test carefully anyway. At 05:55 AM 8/21/2008, Bengt Ragnemalm wrote: >One more question about this. > >If I declare a local array that is larger than the RAM, I do not get an >error. Is that because the compiler can not be sure that this array will >actually be placed in RAM as it can point to anything? > // richard (This email is for mailing lists. To reach me directly, please use richard at imagecraft.com) From benra at imt.liu.se Fri Aug 22 01:45:05 2008 From: benra at imt.liu.se (Bengt Ragnemalm) Date: Fri Aug 22 02:47:21 2008 Subject: SV: SV: SV: SV: [Icc-avr] Stack problems In-Reply-To: <200808212044.m7LKioEw004305@mail.imagecraft.com> References: <664A08FA68194943BDD11F841E7D55F0@Shagrat><200808150948.m7F9mkkN058145@mail.imagecraft.com><05EF9FFB331A47DB916A8398F28BCF45@Shagrat><66680761C9744738A5BC9550E934E10E@Shagrat><0C3FA4B69B124EF8B17B390F7467971E@Shagrat><200808151940.m7FJeXQY066103@mail.imagecraft.com><4C4242E0F9C240559AAF9C00FDCF9E4B@Shagrat><200808180927.m7I9RRxm017684@mail.imagecraft.com><35ECDAA83E1C40C489CC77B94DEA242B@Shagrat> <200808212044.m7LKioEw004305@mail.imagecraft.com> Message-ID: <7E54A6C77EA54AC284353D5D59159EFD@Shagrat> I understand the problem that only generating obvious errors could give you a false safety but all errors that can be generated is good errors in my point of view. I still feel a little lost in what to do to check that I do not use too many local variables. The example below will be the same regardless if the array is used in a function or in main. /Bengt ============= The code could be for example be this: (Full program) #include #include void Function(void) { unsigned char array[3000]; // RAM is 2k unsigned short index; array[index]=0; index = 3000; array[index]=0; // Writing in cyberspace } void main(void) { Function(); } ============= The map file: Map File Summary V3.2.3 for IccV7 AVR run at 2008-08-22 10:36:44 on project "\\Annatar\benra\Projekt\Slask\SLASK" Memory summary: flash size is 8192 bytes (8KB) flash used for - int vectors = 52 (0x34) bytes from 0x0000 to 0x0033 = 26 (0x1A) instruction words from 0x0000 to 0x0019 - code = 290 (0x122) bytes from 0x0034 to 0x0155 = 145 (0x91) instruction words) from 0x001A to 0x00AA +- user code : -52 (0x-,) bytes from 0x0034 to 0x000/ = -26 (0x/&) instruction words) from 0x001A to 0x000/ +- : 342 (0x156) bytes from 0x0000 to 0x0155 = 171 (0xAB) instruction words) from 0x0000 to 0x00AA flash usage is 342 bytes or 4.2%, leaving 7850 bytes (7KB) free sram size is 1024 bytes (1KB) sram used for - s/w stack = 994 (0x3E2) bytes from 0x0100 to 0x04E1 - h/w stack = 30 (0x1E) bytes from 0x04E2 to 0x04FF eeprom size is 512 bytes no eeprom area found Areas: (items sorted by name) FLASH area "text" used for code FLASH area "text" = 290 (0x122) bytes from 0x0034 to 0x0155 = 145 (0x91) instruction words from 0x001A to 0x00AA _Function = 110 (0x006E) words __start = 33 (0x0021) words _exit = 1 (0x0001) word _main = 1 (0x0001) word FLASH area "vector" used for interrupt vectors FLASH area "vector" = 2 (0x02) bytes from 0x0000 to 0x0001 = 1 (0x01) instruction words from 0x0000 to 0x0000 > -----Ursprungligt meddelande----- > Fr?n: icc-avr-bounces@imagecraft.com [mailto:icc-avr- > bounces@imagecraft.com] F?r Richard Man > Skickat: den 21 augusti 2008 21:42 > Till: icc-avr@imagecraft.com > ?mne: Re: SV: SV: SV: [Icc-avr] Stack problems > > Currently, the compiler does not do any check on the local variables, > because any checking would be at best a guess (unless it does full > call tree analysis and layout all the SRAM usage). While it can > clearly complain in the obvious cases, it will do a lousy job overall > and then people will complain about false security. > > If you look at the View->"Map File Summary" it gives you an estimate > on how big the software stack can be. Generally speaking, you > shouldn't be pushing the limit of the SRAM, so it should be farily > easy for you to see what your margins are. If you are really pushing > the limit, you would need to check and test carefully anyway. > > At 05:55 AM 8/21/2008, Bengt Ragnemalm wrote: > >One more question about this. > > > >If I declare a local array that is larger than the RAM, I do not get an > >error. Is that because the compiler can not be sure that this array will > >actually be placed in RAM as it can point to anything? > > > > // 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 johan at edab.nu Fri Aug 22 02:04:21 2008 From: johan at edab.nu (=?ISO-8859-1?Q?Johan_Wallstr=F6m?=) Date: Fri Aug 22 03:07:09 2008 Subject: SV: SV: SV: SV: [Icc-avr] Stack problems In-Reply-To: <7E54A6C77EA54AC284353D5D59159EFD@Shagrat> References: <664A08FA68194943BDD11F841E7D55F0@Shagrat><200808150948.m7F9mkkN058145@mail.imagecraft.com><05EF9FFB331A47DB916A8398F28BCF45@Shagrat><66680761C9744738A5BC9550E934E10E@Shagrat><0C3FA4B69B124EF8B17B390F7467971E@Shagrat><200808151940.m7FJeXQY066103@mail.imagecraft.com><4C4242E0F9C240559AAF9C00FDCF9E4B@Shagrat><200808180927.m7I9RRxm017684@mail.imagecraft.com><35ECDAA83E1C40C489CC77B94DEA242B@Shagrat> <200808212044.m7LKioEw004305@mail.imagecraft.com> <7E54A6C77EA54AC284353D5D59159EFD@Shagrat> Message-ID: <48AE8115.2000402@edab.nu> You're just gonna have to keep track of the RAM you use. Putting large arrays in global helps. If you got a simple call tree that causes no function to be called more than once at the same time (this is the way a small C software should be made) the stack needed for those functions will never exceed the sum of the usage of each function. Bengt Ragnemalm skrev: > I understand the problem that only generating obvious errors could give you > a false safety but all errors that can be generated is good errors in my > point of view. > > I still feel a little lost in what to do to check that I do not use too many > local variables. > > The example below will be the same regardless if the array is used in a > function or in main. > > /Bengt > > ============= > The code could be for example be this: (Full program) > > #include > #include > > void Function(void) > { > unsigned char array[3000]; // RAM is 2k > unsigned short index; > array[index]=0; > index = 3000; > array[index]=0; // Writing in cyberspace > } > > void main(void) > { > Function(); > } > ============= > > The map file: > > Map File Summary V3.2.3 for IccV7 AVR > run at 2008-08-22 10:36:44 > on project "\\Annatar\benra\Projekt\Slask\SLASK" > > Memory summary: > > flash size is 8192 bytes (8KB) > flash used for > - int vectors = 52 (0x34) bytes from 0x0000 to 0x0033 = 26 (0x1A) > instruction words from 0x0000 to 0x0019 > - code = 290 (0x122) bytes from 0x0034 to 0x0155 = 145 (0x91) > instruction words) from 0x001A to 0x00AA > +- user code : -52 (0x-,) bytes from 0x0034 to 0x000/ = -26 (0x/&) > instruction words) from 0x001A to 0x000/ > +- : 342 (0x156) bytes from 0x0000 to 0x0155 = 171 (0xAB) > instruction words) from 0x0000 to 0x00AA > flash usage is 342 bytes or 4.2%, leaving 7850 bytes (7KB) free > > sram size is 1024 bytes (1KB) > sram used for > - s/w stack = 994 (0x3E2) bytes from 0x0100 to 0x04E1 > - h/w stack = 30 (0x1E) bytes from 0x04E2 to 0x04FF > > eeprom size is 512 bytes > no eeprom area found > > > Areas: > (items sorted by name) > > FLASH area "text" used for code > FLASH area "text" = 290 (0x122) bytes from 0x0034 to 0x0155 = 145 (0x91) > instruction words from 0x001A to 0x00AA > _Function = 110 (0x006E) words > __start = 33 (0x0021) words > _exit = 1 (0x0001) word > _main = 1 (0x0001) word > > FLASH area "vector" used for interrupt vectors > FLASH area "vector" = 2 (0x02) bytes from 0x0000 to 0x0001 = 1 (0x01) > instruction words from 0x0000 to 0x0000 > > > > > > >> -----Ursprungligt meddelande----- >> Fr?n: icc-avr-bounces@imagecraft.com [mailto:icc-avr- >> bounces@imagecraft.com] F?r Richard Man >> Skickat: den 21 augusti 2008 21:42 >> Till: icc-avr@imagecraft.com >> ?mne: Re: SV: SV: SV: [Icc-avr] Stack problems >> >> Currently, the compiler does not do any check on the local variables, >> because any checking would be at best a guess (unless it does full >> call tree analysis and layout all the SRAM usage). While it can >> clearly complain in the obvious cases, it will do a lousy job overall >> and then people will complain about false security. >> >> If you look at the View->"Map File Summary" it gives you an estimate >> on how big the software stack can be. Generally speaking, you >> shouldn't be pushing the limit of the SRAM, so it should be farily >> easy for you to see what your margins are. If you are really pushing >> the limit, you would need to check and test carefully anyway. >> >> At 05:55 AM 8/21/2008, Bengt Ragnemalm wrote: >> >>> One more question about this. >>> >>> If I declare a local array that is larger than the RAM, I do not get an >>> error. Is that because the compiler can not be sure that this array will >>> actually be placed in RAM as it can point to anything? >>> >>> >> // 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 >> > > > _______________________________________________ > 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 - http://www.avg.com > Version: 8.0.138 / Virus Database: 270.6.6/1626 - Release Date: 2008-08-21 18:54 > > > > From richard-lists at imagecraft.com Fri Aug 22 02:17:44 2008 From: richard-lists at imagecraft.com (Richard Man) Date: Fri Aug 22 03:20:44 2008 Subject: SV: SV: SV: SV: [Icc-avr] Stack problems In-Reply-To: <7E54A6C77EA54AC284353D5D59159EFD@Shagrat> References: <664A08FA68194943BDD11F841E7D55F0@Shagrat> <200808150948.m7F9mkkN058145@mail.imagecraft.com> <05EF9FFB331A47DB916A8398F28BCF45@Shagrat> <66680761C9744738A5BC9550E934E10E@Shagrat> <0C3FA4B69B124EF8B17B390F7467971E@Shagrat> <200808151940.m7FJeXQY066103@mail.imagecraft.com> <4C4242E0F9C240559AAF9C00FDCF9E4B@Shagrat> <200808180927.m7I9RRxm017684@mail.imagecraft.com> <35ECDAA83E1C40C489CC77B94DEA242B@Shagrat> <200808212044.m7LKioEw004305@mail.imagecraft.com> <7E54A6C77EA54AC284353D5D59159EFD@Shagrat> Message-ID: <200808221020.m7MAKhNb017672@mail.imagecraft.com> Bengt, the map file summary says you have 994 bytes SW stack. A reasonable thing to do is to give yourself a reasonable margin, e.g. it should not be rocket science to keep your local variable usage down to about 500 bytes. If you are creeping up to 900 bytes mark, and honestly, how many nested functions are you writing? It should be fairly easy for YOU, the programmer, to make an estimate. Anyway, if you are creeping toward the full size, then obviously you will need to do more careful study. I don't see why the compiler has to do heroic when you can do a simple job of better estimating. You know not to blow the current requirement of an IO pin, so why not know the limitations of the memory constraints? At 01:45 AM 8/22/2008, Bengt Ragnemalm wrote: >I understand the problem that only generating obvious errors could give you >a false safety but all errors that can be generated is good errors in my >point of view. > >I still feel a little lost in what to do to check that I do not use too many >local variables. > >The example below will be the same regardless if the array is used in a >function or in main. // richard (This email is for mailing lists. To reach me directly, please use richard at imagecraft.com) From benra at imt.liu.se Fri Aug 22 04:15:44 2008 From: benra at imt.liu.se (Bengt Ragnemalm) Date: Fri Aug 22 05:17:57 2008 Subject: SV: SV: SV: SV: SV: [Icc-avr] Stack problems In-Reply-To: <200808221020.m7MAKhNb017672@mail.imagecraft.com> References: <664A08FA68194943BDD11F841E7D55F0@Shagrat><200808150948.m7F9mkkN058145@mail.imagecraft.com><05EF9FFB331A47DB916A8398F28BCF45@Shagrat><66680761C9744738A5BC9550E934E10E@Shagrat><0C3FA4B69B124EF8B17B390F7467971E@Shagrat><200808151940.m7FJeXQY066103@mail.imagecraft.com><4C4242E0F9C240559AAF9C00FDCF9E4B@Shagrat><200808180927.m7I9RRxm017684@mail.imagecraft.com><35ECDAA83E1C40C489CC77B94DEA242B@Shagrat><200808212044.m7LKioEw004305@mail.imagecraft.com><7E54A6C77EA54AC284353D5D59159EFD@Shagrat> <200808221020.m7MAKhNb017672@mail.imagecraft.com> Message-ID: <8FCE561DFE8743DBA7C4A5B670174030@Shagrat> Richard, I am not saying the compiler should be heroic, I am just trying to learn how this works. /Bengt > -----Ursprungligt meddelande----- > Fr?n: icc-avr-bounces@imagecraft.com [mailto:icc-avr- > bounces@imagecraft.com] F?r Richard Man > Skickat: den 22 augusti 2008 11:18 > Till: icc-avr@imagecraft.com > ?mne: Re: SV: SV: SV: SV: [Icc-avr] Stack problems > > Bengt, the map file summary says you have 994 bytes SW stack. A > reasonable thing to do is to give yourself a reasonable margin, e.g. > it should not be rocket science to keep your local variable usage > down to about 500 bytes. If you are creeping up to 900 bytes mark, > and honestly, how many nested functions are you writing? It should be > fairly easy for YOU, the programmer, to make an estimate. Anyway, if > you are creeping toward the full size, then obviously you will need > to do more careful study. > > I don't see why the compiler has to do heroic when you can do a > simple job of better estimating. You know not to blow the current > requirement of an IO pin, so why not know the limitations of the > memory constraints? > > > At 01:45 AM 8/22/2008, Bengt Ragnemalm wrote: > >I understand the problem that only generating obvious errors could give > you > >a false safety but all errors that can be generated is good errors in my > >point of view. > > > >I still feel a little lost in what to do to check that I do not use too > many > >local variables. > > > >The example below will be the same regardless if the array is used in a > >function or in main. > > // 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 patchell at cox.net Fri Aug 22 06:36:21 2008 From: patchell at cox.net (Jim Patchell) Date: Fri Aug 22 07:39:09 2008 Subject: SV: SV: SV: SV: [Icc-avr] Stack problems In-Reply-To: <7E54A6C77EA54AC284353D5D59159EFD@Shagrat> References: <664A08FA68194943BDD11F841E7D55F0@Shagrat><200808150948.m7F9mkkN058145@mail.imagecraft.com><05EF9FFB331A47DB916A8398F28BCF45@Shagrat><66680761C9744738A5BC9550E934E10E@Shagrat><0C3FA4B69B124EF8B17B390F7467971E@Shagrat><200808151940.m7FJeXQY066103@mail.imagecraft.com><4C4242E0F9C240559AAF9C00FDCF9E4B@Shagrat><200808180927.m7I9RRxm017684@mail.imagecraft.com><35ECDAA83E1C40C489CC77B94DEA242B@Shagrat> <200808212044.m7LKioEw004305@mail.imagecraft.com> <7E54A6C77EA54AC284353D5D59159EFD@Shagrat> Message-ID: <48AEC0D5.5020008@cox.net> It comes with practice... Where I work, first thing I tell C newbies: Never put arrays on the stack (auto variables/local variables)...it is just bad practice, especially in an embedded controller. Stack problems are very difficult to track down. -Jim Bengt Ragnemalm wrote: > I understand the problem that only generating obvious errors could give you > a false safety but all errors that can be generated is good errors in my > point of view. > > I still feel a little lost in what to do to check that I do not use too many > local variables. > > The example below will be the same regardless if the array is used in a > function or in main. > > /Bengt > > ============= > The code could be for example be this: (Full program) > > #include > #include > > void Function(void) > { > unsigned char array[3000]; // RAM is 2k > unsigned short index; > array[index]=0; > index = 3000; > array[index]=0; // Writing in cyberspace > } > > void main(void) > { > Function(); > } > ============= > > The map file: > > Map File Summary V3.2.3 for IccV7 AVR > run at 2008-08-22 10:36:44 > on project "\\Annatar\benra\Projekt\Slask\SLASK" > > Memory summary: > > flash size is 8192 bytes (8KB) > flash used for > - int vectors = 52 (0x34) bytes from 0x0000 to 0x0033 = 26 (0x1A) > instruction words from 0x0000 to 0x0019 > - code = 290 (0x122) bytes from 0x0034 to 0x0155 = 145 (0x91) > instruction words) from 0x001A to 0x00AA > +- user code : -52 (0x-,) bytes from 0x0034 to 0x000/ = -26 (0x/&) > instruction words) from 0x001A to 0x000/ > +- : 342 (0x156) bytes from 0x0000 to 0x0155 = 171 (0xAB) > instruction words) from 0x0000 to 0x00AA > flash usage is 342 bytes or 4.2%, leaving 7850 bytes (7KB) free > > sram size is 1024 bytes (1KB) > sram used for > - s/w stack = 994 (0x3E2) bytes from 0x0100 to 0x04E1 > - h/w stack = 30 (0x1E) bytes from 0x04E2 to 0x04FF > > eeprom size is 512 bytes > no eeprom area found > > > Areas: > (items sorted by name) > > FLASH area "text" used for code > FLASH area "text" = 290 (0x122) bytes from 0x0034 to 0x0155 = 145 (0x91) > instruction words from 0x001A to 0x00AA > _Function = 110 (0x006E) words > __start = 33 (0x0021) words > _exit = 1 (0x0001) word > _main = 1 (0x0001) word > > FLASH area "vector" used for interrupt vectors > FLASH area "vector" = 2 (0x02) bytes from 0x0000 to 0x0001 = 1 (0x01) > instruction words from 0x0000 to 0x0000 > > > > > >> -----Ursprungligt meddelande----- >> Fr?n: icc-avr-bounces@imagecraft.com [mailto:icc-avr- >> bounces@imagecraft.com] F?r Richard Man >> Skickat: den 21 augusti 2008 21:42 >> Till: icc-avr@imagecraft.com >> ?mne: Re: SV: SV: SV: [Icc-avr] Stack problems >> >> Currently, the compiler does not do any check on the local variables, >> because any checking would be at best a guess (unless it does full >> call tree analysis and layout all the SRAM usage). While it can >> clearly complain in the obvious cases, it will do a lousy job overall >> and then people will complain about false security. >> >> If you look at the View->"Map File Summary" it gives you an estimate >> on how big the software stack can be. Generally speaking, you >> shouldn't be pushing the limit of the SRAM, so it should be farily >> easy for you to see what your margins are. If you are really pushing >> the limit, you would need to check and test carefully anyway. >> >> At 05:55 AM 8/21/2008, Bengt Ragnemalm wrote: >>> One more question about this. >>> >>> If I declare a local array that is larger than the RAM, I do not get an >>> error. Is that because the compiler can not be sure that this array will >>> actually be placed in RAM as it can point to anything? >>> >> // richard (This email is for mailing