From richard-lists at imagecraft.com Tue May 1 00:49:33 2007 From: richard-lists at imagecraft.com (Richard) Date: Tue May 1 00:58:56 2007 Subject: [Icc-avr] Specific 7.13-Beta2Compile Error In-Reply-To: References: Message-ID: <6.1.0.6.2.20070501004853.080bde50@192.168.100.42> The 2nd one is definitely a bug with the "8 bit optimization." Will fix. At 05:12 AM 4/27/2007, Glenn Greig wrote: >For the second problem, I suspect the calculation is being 'optimized' to >8 bits... >168 * 128 = 0x5400, so if the high byte is discarded it becomes 0. > >This is similar to an issue I reported earlier for 7.12 (only this one is >is the pre-processor). > >-----Original Message----- >From: icc-avr-bounces@imagecraft.com >[mailto:icc-avr-bounces@imagecraft.com]On Behalf Of Jared Broad >Sent: April 26, 2007 8:26 PM >To: icc-avr@imagecraft.com >Cc: Dave Marshall; Shane Buckham >Subject: [Icc-avr] Specific 7.13-Beta2Compile Error > > > >Hello Richard, > >I just downloaded the most recent 7.13 from the website and new errors >appeared I thought you may want to know about. > >!W C:\ethernut-4.2.1\nutapp-13g\Metro\DPSLog.c: [warning] in function >'DPL_RxResponse', argument 'success' has no use. >The boolean success is used in the function, >This is one of many warnings of this nature which previously were not >there, > > >And, >!E C:\ethernut-4.2.1\nutapp-13g\Metro\ilr\IOLib.c(40): `0' is an illegal >array size > >// the LCD library >#define LCDWidth 168 >#define LCDHeight 128 >#define LCDVisWidth 160 >u08 LCDImage[(LCDWidth * LCDHeight)/8]; > >When I replace the brackets with the number 2688 it works. Is the >pre-processor working correctly? >This also generates an error: u08 LCDImage[(168 * 128)/8]; > >Regards > >Jared // richard (This email is for mailing lists. To reach me directly, please use richard at imagecraft.com) From sbissonnette at microsyl.com Tue May 1 21:24:54 2007 From: sbissonnette at microsyl.com (Sylvain Bissonnette) Date: Tue May 1 20:34:35 2007 Subject: [Icc-avr] Pointer Problem References: Message-ID: <001d01c78c71$d5f58920$0301a8c0@Sylvain> Hi, I have a problem with pointer in my code, Here is the code and the question is after // LED typedef struct { ushort Red; ushort Green; ushort Blue; }LedStruct; LedStruct *Led; // DMX ushort DMXBuffer[MAX_DMX]; void main() { Led = &DMXBuffer[0]; } I have declaire a array "DMXBuffer" of x byte, now I want to address this array by using the LedStruct to have something like Led[0].Red; // will give DMXBuffer[0] Led[0].Green; // will give DMXBuffer[1] Led[0].Blue; // will give DMXBuffer[2] Led[1].Red; // will give DMXBuffer[3] Led[1].Green; // will give DMXBuffer[4] Led[1].Blue; //will give DMXBuffer[5] Thanks for your help Sylvain Bissonnette -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20070501/9fda8e2a/attachment.html From jmail at shotwiz.net Tue May 1 20:45:14 2007 From: jmail at shotwiz.net (Keith Hamberg) Date: Tue May 1 20:54:27 2007 Subject: [Icc-avr] Pointer Problem In-Reply-To: <001d01c78c71$d5f58920$0301a8c0@Sylvain> Message-ID: <001d01c78c6c$4b904090$2d01a8c0@PC17> Not sure I understand exactly what the question is, but this compiles and the generated asm seems correct typedef unsigned short ushort ; #define MAX_DMX 30 typedef struct { ushort Red; ushort Green; ushort Blue; }LedStruct; LedStruct *Led; // DMX ushort DMXBuffer[MAX_DMX]; void main() { Led = (LedStruct *) DMXBuffer; Led[0].Red = 1; // will give DMXBuffer[0] Led[0].Green= 2; // will give DMXBuffer[1] Led[0].Blue=3; // will give DMXBuffer[2] Led[1].Red=4; // will give DMXBuffer[3] Led[1].Green=5; // will give DMXBuffer[4] Led[1].Blue=6; //will give DMXBuffer[5] } //I have declaire a array "DMXBuffer" of x byte, now I want to address this array by //using the LedStruct to have something like -----Original Message----- From: icc-avr-bounces@imagecraft.com [mailto:icc-avr-bounces@imagecraft.com] On Behalf Of Sylvain Bissonnette Sent: Tuesday, May 01, 2007 11:25 PM To: Discussion list for ICCAVR and ICCtiny Users. You do NOT needtosubscribetoicc-announce if you are a member of this. Subject: [Icc-avr] Pointer Problem Hi, I have a problem with pointer in my code, Here is the code and the question is after // LED typedef struct { ushort Red; ushort Green; ushort Blue; }LedStruct; LedStruct *Led; // DMX ushort DMXBuffer[MAX_DMX]; void main() { Led = &DMXBuffer[0]; } I have declaire a array "DMXBuffer" of x byte, now I want to address this array by using the LedStruct to have something like Led[0].Red; // will give DMXBuffer[0] Led[0].Green; // will give DMXBuffer[1] Led[0].Blue; // will give DMXBuffer[2] Led[1].Red; // will give DMXBuffer[3] Led[1].Green; // will give DMXBuffer[4] Led[1].Blue; //will give DMXBuffer[5] Thanks for your help Sylvain Bissonnette -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20070501/63f80ca1/attachment.html From sl at ecpower.dk Tue May 1 22:34:24 2007 From: sl at ecpower.dk (Steven Lose) Date: Tue May 1 22:43:44 2007 Subject: SV: [Icc-avr] Pointer Problem Message-ID: <072D96786BFC014AAEBA9EB07A8070EA1EB19E@seattle.ecpower.dk> Hi. Could also use union. Union { Ledstruct Led[NROFLED]; Ushort DmxBuffer[sizeof(Ledstruct)* NROFLED]; //or just sizeof(Led) }ULed; Uled.Led[0].Red = 1; // will give DMXBuffer[0] Uled.Led[0].Green= 2; // will give DMXBuffer[1] Uled.Led[0].Blue=3; // will give DMXBuffer[2] Uled.Led[1].Red=4; // will give DMXBuffer[3] Uled.Led[1].Green=5; // will give DMXBuffer[4] Uled.Led[1].Blue=6; //will give DMXBuffer[5] Med venlig hilsen / Best regards / mit freundlichen Gr??en EC POWER A/S Steven Lose Software Ingeni?r Tlf.: +45 87434100 Direkte tlf. +45 58286608 Email: sl@ecpower.dk www.ecpower.dk ________________________________ Fra: icc-avr-bounces@imagecraft.com [mailto:icc-avr-bounces@imagecraft.com] P? vegne af Keith Hamberg Sendt: 2. maj 2007 05:45 Til: 'Discussion list for ICCAVR and ICCtiny Users. You do NOT needtosubscribeto icc-announce if you are a member of this.' Emne: RE: [Icc-avr] Pointer Problem Not sure I understand exactly what the question is, but this compiles and the generated asm seems correct typedef unsigned short ushort ; #define MAX_DMX 30 typedef struct { ushort Red; ushort Green; ushort Blue; }LedStruct; LedStruct *Led; // DMX ushort DMXBuffer[MAX_DMX]; void main() { Led = (LedStruct *) DMXBuffer; Led[0].Red = 1; // will give DMXBuffer[0] Led[0].Green= 2; // will give DMXBuffer[1] Led[0].Blue=3; // will give DMXBuffer[2] Led[1].Red=4; // will give DMXBuffer[3] Led[1].Green=5; // will give DMXBuffer[4] Led[1].Blue=6; //will give DMXBuffer[5] } //I have declaire a array "DMXBuffer" of x byte, now I want to address this array by //using the LedStruct to have something like -----Original Message----- From: icc-avr-bounces@imagecraft.com [mailto:icc-avr-bounces@imagecraft.com] On Behalf Of Sylvain Bissonnette Sent: Tuesday, May 01, 2007 11:25 PM To: Discussion list for ICCAVR and ICCtiny Users. You do NOT needtosubscribetoicc-announce if you are a member of this. Subject: [Icc-avr] Pointer Problem Hi, I have a problem with pointer in my code, Here is the code and the question is after // LED typedef struct { ushort Red; ushort Green; ushort Blue; }LedStruct; LedStruct *Led; // DMX ushort DMXBuffer[MAX_DMX]; void main() { Led = &DMXBuffer[0]; } I have declaire a array "DMXBuffer" of x byte, now I want to address this array by using the LedStruct to have something like Led[0].Red; // will give DMXBuffer[0] Led[0].Green; // will give DMXBuffer[1] Led[0].Blue; // will give DMXBuffer[2] Led[1].Red; // will give DMXBuffer[3] Led[1].Green; // will give DMXBuffer[4] Led[1].Blue; //will give DMXBuffer[5] Thanks for your help Sylvain Bissonnette -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20070502/44ad5456/attachment-0001.html From t.jaspers at cpseurope.com Wed May 2 00:41:29 2007 From: t.jaspers at cpseurope.com (Jaspers, Ton) Date: Wed May 2 00:50:50 2007 Subject: [Icc-avr] Pointer Problem Message-ID: <7B0EB27CF1CC93439B5CFB7526E5D74C41F5BA@mickey.PBNV.local> From: Sylvain Bissonnette > > Hi, > > I have a problem with pointer in my code, Here is the code and the question is after > > void main() > { > Led = &DMXBuffer[0]; > } You need to cast the correct type to avoid compiler errors: void main() { Led = (LedStruct *)&DMXBuffer[0]; ^^^^^^^^^^^^^ } Or as I would do it (should compile to the same code): void main() { Led = (LedStruct *)DMXBuffer ; } Cheers,T From sbissonnette at microsyl.com Wed May 2 11:17:54 2007 From: sbissonnette at microsyl.com (Sylvain Bissonnette) Date: Wed May 2 10:27:36 2007 Subject: [Icc-avr] Pointer Problem References: <7B0EB27CF1CC93439B5CFB7526E5D74C41F5BA@mickey.PBNV.local> Message-ID: <003801c78ce6$342cb3a0$0301a8c0@Sylvain> Hi, First thanks for your help, I'm not too fare from the solution, It's look like my buffer transmitter don't work. typedef struct { ushort Red; ushort Green; ushort Blue; }LedStruct; LedStruct *Led; // DMX ushort DMXBuffer[MAX_DMX]; void main() { Led = (LedStruct*)&DMXBuffer[0]; } #pragma interrupt_handler DMXSendByte:15 void DMXSendByte(void) { static ushort *Pointer; if (Pointer > &DMXBuffer[0]) Pointer = &DMXBuffer[0]; else UDR = *Pointer++; } Thanks for your usfull help Sylvain Bissonnette From albert.vanveen at pertronic.co.nz Wed May 2 13:27:38 2007 From: albert.vanveen at pertronic.co.nz (Albert van Veen) Date: Wed May 2 13:36:58 2007 Subject: [Icc-avr] Pointer Problem In-Reply-To: <003801c78ce6$342cb3a0$0301a8c0@Sylvain> Message-ID: Surely you mean: if (Pointer > &DMXBuffer[MAX_DMX]) Albert. -----Original Message----- From: Sylvain Bissonnette [mailto:sbissonnette@microsyl.com] Sent: Thursday, 3 May 2007 6:18 a.m. To: Discussion list for ICCAVR and ICCtiny Users. You do NOT needtosubscribetoicc-announce if you are a member of this. Subject: Re: [Icc-avr] Pointer Problem Hi, First thanks for your help, I'm not too fare from the solution, It's look like my buffer transmitter don't work. typedef struct { ushort Red; ushort Green; ushort Blue; }LedStruct; LedStruct *Led; // DMX ushort DMXBuffer[MAX_DMX]; void main() { Led = (LedStruct*)&DMXBuffer[0]; } #pragma interrupt_handler DMXSendByte:15 void DMXSendByte(void) { static ushort *Pointer; if (Pointer > &DMXBuffer[0]) Pointer = &DMXBuffer[0]; else UDR = *Pointer++; } Thanks for your usfull help Sylvain Bissonnette _______________________________________________ Icc-avr mailing list Icc-avr@imagecraft.com http://dragonsgate.net/mailman/listinfo/icc-avr From MDipperstein at CalAmp.com Wed May 2 14:38:47 2007 From: MDipperstein at CalAmp.com (Michael Dipperstein) Date: Wed May 2 14:47:58 2007 Subject: [Icc-avr] Pointer Problem In-Reply-To: Message-ID: Probably if (Pointer > &DMXBuffer[MAX_DMX - 1]) -----Original Message----- From: icc-avr-bounces@imagecraft.com [mailto:icc-avr-bounces@imagecraft.com] On Behalf Of Albert van Veen Sent: Wednesday, May 02, 2007 1:28 PM To: Discussion list for ICCAVR and ICCtiny Users. You do NOT needtosubscribeto icc-announce if you are a member of this. Subject: RE: [Icc-avr] Pointer Problem Surely you mean: if (Pointer > &DMXBuffer[MAX_DMX]) Albert. -----Original Message----- From: Sylvain Bissonnette [mailto:sbissonnette@microsyl.com] Sent: Thursday, 3 May 2007 6:18 a.m. To: Discussion list for ICCAVR and ICCtiny Users. You do NOT needtosubscribetoicc-announce if you are a member of this. Subject: Re: [Icc-avr] Pointer Problem Hi, First thanks for your help, I'm not too fare from the solution, It's look like my buffer transmitter don't work. typedef struct { ushort Red; ushort Green; ushort Blue; }LedStruct; LedStruct *Led; // DMX ushort DMXBuffer[MAX_DMX]; void main() { Led = (LedStruct*)&DMXBuffer[0]; } #pragma interrupt_handler DMXSendByte:15 void DMXSendByte(void) { static ushort *Pointer; if (Pointer > &DMXBuffer[0]) Pointer = &DMXBuffer[0]; else UDR = *Pointer++; } Thanks for your usfull help Sylvain Bissonnette _______________________________________________ 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 sbissonnette at microsyl.com Wed May 2 20:13:37 2007 From: sbissonnette at microsyl.com (Sylvain Bissonnette) Date: Wed May 2 19:23:19 2007 Subject: [Icc-avr] Pointer Problem References: Message-ID: <000801c78d31$0aff83e0$0301a8c0@Sylvain> Hi, Yes that was my problem, after so many hours in from of my code I see nothing,... Thanks for your light! Sylvain ----- Original Message ----- From: "Michael Dipperstein" To: "Discussion list for ICCAVR and ICCtiny Users. You do NOT need tosubscribe to icc-announce if you are a member of this." Sent: Wednesday, May 02, 2007 4:38 PM Subject: RE: [Icc-avr] Pointer Problem > Probably > > if (Pointer > &DMXBuffer[MAX_DMX - 1]) > > -----Original Message----- > From: icc-avr-bounces@imagecraft.com > [mailto:icc-avr-bounces@imagecraft.com] On Behalf Of Albert van Veen > Sent: Wednesday, May 02, 2007 1:28 PM > To: Discussion list for ICCAVR and ICCtiny Users. You do NOT > needtosubscribeto icc-announce if you are a member of this. > Subject: RE: [Icc-avr] Pointer Problem > > Surely you mean: > > if (Pointer > &DMXBuffer[MAX_DMX]) > > Albert. > > > > -----Original Message----- > From: Sylvain Bissonnette [mailto:sbissonnette@microsyl.com] > Sent: Thursday, 3 May 2007 6:18 a.m. > To: Discussion list for ICCAVR and ICCtiny Users. You do NOT > needtosubscribetoicc-announce if you are a member of this. > Subject: Re: [Icc-avr] Pointer Problem > > > Hi, > > First thanks for your help, I'm not too fare from the solution, > It's > look like my buffer transmitter don't work. > > typedef struct > { > ushort Red; > ushort Green; > ushort Blue; > }LedStruct; > > LedStruct *Led; > > // DMX > ushort DMXBuffer[MAX_DMX]; > > void main() > { > Led = (LedStruct*)&DMXBuffer[0]; > } > > #pragma interrupt_handler DMXSendByte:15 > void DMXSendByte(void) > { > static ushort *Pointer; > > if (Pointer > &DMXBuffer[0]) Pointer = &DMXBuffer[0]; > else UDR = *Pointer++; > } > > Thanks for your usfull help > Sylvain Bissonnette > > _______________________________________________ > 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 paul.aa9gg at gmail.com Thu May 3 06:44:52 2007 From: paul.aa9gg at gmail.com (Paul Mateer) Date: Thu May 3 06:54:04 2007 Subject: [Icc-avr] Pointer Problem In-Reply-To: <000801c78d31$0aff83e0$0301a8c0@Sylvain> References: <000801c78d31$0aff83e0$0301a8c0@Sylvain> Message-ID: <20f5efc40705030644g6a09bc8et16328cec986b23a0@mail.gmail.com> Don't you just hate that! ;) On 5/2/07, Sylvain Bissonnette wrote: > > Hi, > > Yes that was my problem, after so many hours in from of my code I see > nothing,... > > Thanks for your light! > Sylvain > > ----- Original Message ----- > From: "Michael Dipperstein" > To: "Discussion list for ICCAVR and ICCtiny Users. You do NOT need > tosubscribe to icc-announce if you are a member of this." > > Sent: Wednesday, May 02, 2007 4:38 PM > Subject: RE: [Icc-avr] Pointer Problem > > > > Probably > > > > if (Pointer > &DMXBuffer[MAX_DMX - 1]) > > > > -----Original Message----- > > From: icc-avr-bounces@imagecraft.com > > [mailto:icc-avr-bounces@imagecraft.com] On Behalf Of Albert van Veen > > Sent: Wednesday, May 02, 2007 1:28 PM > > To: Discussion list for ICCAVR and ICCtiny Users. You do NOT > > needtosubscribeto icc-announce if you are a member of this. > > Subject: RE: [Icc-avr] Pointer Problem > > > > Surely you mean: > > > > if (Pointer > &DMXBuffer[MAX_DMX]) > > > > Albert. > > > > > > > > -----Original Message----- > > From: Sylvain Bissonnette [mailto:sbissonnette@microsyl.com] > > Sent: Thursday, 3 May 2007 6:18 a.m. > > To: Discussion list for ICCAVR and ICCtiny Users. You do NOT > > needtosubscribetoicc-announce if you are a member of this. > > Subject: Re: [Icc-avr] Pointer Problem > > > > > > Hi, > > > > First thanks for your help, I'm not too fare from the solution, > > It's > > look like my buffer transmitter don't work. > > > > typedef struct > > { > > ushort Red; > > ushort Green; > > ushort Blue; > > }LedStruct; > > > > LedStruct *Led; > > > > // DMX > > ushort DMXBuffer[MAX_DMX]; > > > > void main() > > { > > Led = (LedStruct*)&DMXBuffer[0]; > > } > > > > #pragma interrupt_handler DMXSendByte:15 > > void DMXSendByte(void) > > { > > static ushort *Pointer; > > > > if (Pointer > &DMXBuffer[0]) Pointer = &DMXBuffer[0]; > > else UDR = *Pointer++; > > } > > > > Thanks for your usfull help > > Sylvain Bissonnette > > > > _______________________________________________ > > 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 > > > > _______________________________________________ > 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/20070503/439ed508/attachment.html From benra at imt.liu.se Fri May 4 05:44:23 2007 From: benra at imt.liu.se (Bengt Ragnemalm) Date: Fri May 4 05:54:02 2007 Subject: [Icc-avr] Compiler bug? Message-ID: <00c101c78e49$f1712770$b160ec82@Shagrat> Hi. I know that I am usually wrong about this but this looks like a compiler bug to me. Please have look. ppgAcDiff and acGain are signed short. This simple line didn?t do anything so I checked the assembler. Actually this is very similar to my previous problem but this time the variable is used at the line right after. Just to provoke, I inserted a simple ++ in between and yes, now the result is saved. What is going on here? ppgAcDiff = ppgAcDiff/acGain; 411: ppgAcDiff = ppgAcDiff/acGain; +0000020D: 019C MOVW R18,R24 Copy register pair +0000020E: 0187 MOVW R16,R14 Copy register pair +0000020F: 940E0A68 CALL 0x00000A68 Call subroutine 414: subtractTotalDiffFiltered = S_ShortFilter(ppgAcDiff, &filtMem[channel], filterdjup, &firFiltMem[channel]); 411: ppgAcDiff = ppgAcDiff/acGain; +0000020D: 019C MOVW R18,R24 Copy register pair +0000020E: 0187 MOVW R16,R14 Copy register pair +0000020F: 940E0A6D CALL 0x00000A6D Call subroutine +00000211: 0178 MOVW R14,R16 Copy register pair 412: ppgAcDiff++; +00000212: 01C7 MOVW R24,R14 Copy register pair +00000213: 9601 ADIW R24,0x01 Add immediate to word +00000214: 017C MOVW R14,R24 Copy register pair 414: subtractTotalDiffFiltered = S_ShortFilter(ppgAcDiff, &filtMem[channel], filterdjup, &firFiltMem[channel]); /Bengt ________________________________________________________________ Bengt Ragnemalm Tel +46 13 22 24 97 Research engineer FAX: +46 13 10 19 02 Link?pings Universitet mailto:bengt.ragnemalm@imt.liu.se Inst. f?r Medicinsk Teknik Internet: http://www.imt.liu.se S-581 85 Link?ping SWEDEN -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20070504/b5953e59/attachment.html From richard-lists at imagecraft.com Fri May 4 08:17:57 2007 From: richard-lists at imagecraft.com (Richard) Date: Fri May 4 08:27:37 2007 Subject: [Icc-avr] Compiler bug? In-Reply-To: <00c101c78e49$f1712770$b160ec82@Shagrat> References: <00c101c78e49$f1712770$b160ec82@Shagrat> Message-ID: <6.1.0.6.2.20070504081242.057494e8@192.168.100.42> At 05:44 AM 5/4/2007, Bengt Ragnemalm wrote: >Hi. > >I know that I am usually wrong about this but this looks like a compiler >bug to me. Please have look. > >ppgAcDiff and acGain are signed short. > >This simple line didn't do anything so I checked the assembler. Actually >this is very similar to my previous problem but this time the variable is >used at the line right after. Just to provoke, I inserted a simple ++ in >between and yes, now the result is saved. What is going on here? Bengt, are we suppose to be mind readers? :-) What do you think is the problem? It will help if you describe what the problem is. Not what might have caused the problem, but what do you see that is odd? Possibly you may mean that you don't see a write back to ppgAcDiff? Which is... registers R24/R25 or R14/R15 (which you could tell us from the .lst file or a few other places so we don't have to guess). If that's the case, possibly because there is no further use to the variable except the argument to the next function call, and that may be OK since the "Call subroutine" (which you can tell us what it's name is, from the .lst file) returns it in the right registers readying for the S_ShortFilter call. At least that's my guess, but I am really shooting in the dark as I would need more info (as described above) to say for sure. > >ppgAcDiff = ppgAcDiff/acGain; > > >411: ppgAcDiff = ppgAcDiff/acGain; >+0000020D: 019C MOVW R18,R24 Copy register pair >+0000020E: 0187 MOVW R16,R14 Copy register pair >+0000020F: 940E0A68 CALL 0x00000A68 Call subroutine >414: subtractTotalDiffFiltered = S_ShortFilter(ppgAcDiff, >&filtMem[channel], filterdjup, &firFiltMem[channel]); > > > >411: ppgAcDiff = ppgAcDiff/acGain; >+0000020D: 019C MOVW R18,R24 Copy register pair >+0000020E: 0187 MOVW R16,R14 Copy register pair >+0000020F: 940E0A6D CALL 0x00000A6D Call subroutine >+00000211: 0178 MOVW R14,R16 Copy register pair >412: ppgAcDiff++; >+00000212: 01C7 MOVW R24,R14 Copy register pair >+00000213: 9601 ADIW R24,0x01 Add immediate to word >+00000214: 017C MOVW R14,R24 Copy register pair >414: subtractTotalDiffFiltered = S_ShortFilter(ppgAcDiff, >&filtMem[channel], filterdjup, &firFiltMem[channel]); > >/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 Fri May 4 09:26:36 2007 From: j_baraclough at zetnet.co.uk (John Baraclough) Date: Fri May 4 09:36:20 2007 Subject: [Icc-avr] Compiler bug? In-Reply-To: <00c101c78e49$f1712770$b160ec82@Shagrat> References: <00c101c78e49$f1712770$b160ec82@Shagrat> Message-ID: Hi Bengt, I assume the function at 0x00000A68 in your first listing is 'div16s', in which case the result is returned in R16/R17. That being so, then the first parameter being passed to the function S_ShortFilter(ppgAcDiff, &filtMem[channel], filterdjup, &firFiltMem[channel]); is already in the correct register pair and doesn't need to be moved. Sorry, but I don't think he problem is with the compiler. All the best for now, John At 13:44 04/05/2007, you wrote: >Hi. > >I know that I am usually wrong about this but >this looks like a compiler bug to me. Please have look. > >ppgAcDiff and acGain are signed short. > >This simple line didn?t do anything so I checked >the assembler. Actually this is very similar to >my previous problem but this time the variable >is used at the line right after. Just to >provoke, I inserted a simple ++ in between and >yes, now the result is saved. What is going on here? > >ppgAcDiff = ppgAcDiff/acGain; > > >411: ppgAcDiff = ppgAcDiff/acGain; >+0000020D: 019C MOVW R18,R24 Copy register pair >+0000020E: 0187 MOVW R16,R14 Copy register pair >+0000020F: 940E0A68 CALL 0x00000A68 Call subroutine >414: subtractTotalDiffFiltered = >S_ShortFilter(ppgAcDiff, &filtMem[channel], filterdjup, &firFiltMem[channel]); > > > >411: ppgAcDiff = ppgAcDiff/acGain; >+0000020D: 019C MOVW R18,R24 Copy register pair >+0000020E: 0187 MOVW R16,R14 Copy register pair >+0000020F: 940E0A6D CALL 0x00000A6D Call subroutine >+00000211: 0178 MOVW R14,R16 Copy register pair >412: ppgAcDiff++; >+00000212: 01C7 MOVW R24,R14 Copy register pair >+00000213: 9601 ADIW R24,0x01 Add immediate to word >+00000214: 017C MOVW R14,R24 Copy register pair >414: subtractTotalDiffFiltered = >S_ShortFilter(ppgAcDiff, &filtMem[channel], filterdjup, &firFiltMem[channel]); > >/Bengt >________________________________________________________________ > >Bengt Ragnemalm Tel +46 13 22 24 97 > >Research engineer FAX: +46 13 10 19 02 > >Link?pings >Universitet >mailto:bengt.ragnemalm@imt.liu.se > >Inst. f?r Medicinsk Teknik >Internet: http://www.imt.liu.se > >S-581 85 Link?ping SWEDEN > > > >_______________________________________________ >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/20070504/6d56e7e1/attachment-0001.html From hzhang at quickset.com Fri May 4 12:52:04 2007 From: hzhang at quickset.com (Haojiong Zhang) Date: Fri May 4 13:01:09 2007 Subject: [Icc-avr] pwm using ATmega48 In-Reply-To: Message-ID: Hi, I tried the following code to genearte pwm on PD5(OC0B) and PD6(OC0A), but it doesn't work. The pins never change status when compare matching happens. Anything wrong? DDRD |= (1< References: Message-ID: <20f5efc40705041350k49393999k86c1e48ffdc30060@mail.gmail.com> Here is my setup for a Mega32 (using Timer1).....hope this helps void timer1_init(void) { TCCR1A = 0x00; //stop OCR1A = 127; //set compare OCR1B = 127; //set compare TCCR1A = 0x83; //start timer 0xA3 TCCR1B = 0x6A; //start timer wgm = fast pwm, 10-bit TIMSK = 0x80; // timer interrupt sources } #pragma interrupt_handler timer1_compa_isr:8 void timer1_compa_isr(void) { //compare occured TCNT1=OCR1A OCR1A = PWMA_420_Duty; // update of OCR1A load value } On 5/4/07, Haojiong Zhang wrote: > > Hi, > > I tried the following code to genearte pwm on PD5(OC0B) and PD6(OC0A), but > it doesn't work. The pins never change status when compare matching happens. > Anything wrong? > > DDRD |= (1< OCR0A = 0xAF; > TCCR0A = ( 1 << COM0A1) | (0 << COM0A0) | (1 << COM0B1) | (0 << COM0B0) | > (0 << WGM01) | (1 << WGM00); > TCCR0B = (1 << WGM02) | (0 << CS12) | (0 << CS11) | (1 << CS10); > OCR0A = 0xFF; > TIMSK0 = (0< > > > best regards, > > Haojiong Zhang > > _______________________________________________ > 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/20070504/5fc8999d/attachment.html From j_baraclough at zetnet.co.uk Fri May 4 17:21:45 2007 From: j_baraclough at zetnet.co.uk (John Baraclough) Date: Fri May 4 17:31:16 2007 Subject: [Icc-avr] pwm using ATmega48 In-Reply-To: References: Message-ID: The code does not work because there are several fundamental mistakes in it. The timer is set up for phase correct PWM with WGM2:0 == 5. This mode uses OCR0A as TOP and thus will produce no output from the OCR0A pin. The reset value of 0x00 is left in OCR0B and thus there will be no output from the OCR0B pin either. The bit names in TCCR0B are incorrect, but luckily they are in the same positions as CS00, CS01 & CS02, so that should be OK. Try reading section 13.7.4 of the data sheet again. Then look at table 13-8 in section 13.9.1. All will become clear. John At 20:52 04/05/2007, you wrote: >Hi, > >I tried the following code to genearte pwm on PD5(OC0B) and >PD6(OC0A), but it doesn't work. The pins never change status when >compare matching happens. Anything wrong? > > DDRD |= (1<OCR0A = 0xAF; >TCCR0A = ( 1 << COM0A1) | (0 << COM0A0) | (1 << COM0B1) | (0 << >COM0B0) | (0 << WGM01) | (1 << WGM00); >TCCR0B = (1 << WGM02) | (0 << CS12) | (0 << CS11) | (1 << CS10); >OCR0A = 0xFF; >TIMSK0 = (0< > > >best regards, > >Haojiong Zhang >_______________________________________________ >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/20070505/501b80dd/attachment.html From benra at imt.liu.se Sun May 6 23:45:16 2007 From: benra at imt.liu.se (Bengt Ragnemalm) Date: Sun May 6 23:54:35 2007 Subject: SV: [Icc-avr] Compiler bug? In-Reply-To: References: <00c101c78e49$f1712770$b160ec82@Shagrat> Message-ID: <002101c79073$45b929b0$b160ec82@Shagrat> Please Richartd, try to be patient with me. I am just trying to get some help and am truly sorry if you are feeling ?spammed?. I will try to be more precise in the future. My problem is that I do not get any result from the simple division ?ppgAcDiff = ppgAcDiff/acGain;? As I said, I always am very careful about accusing the compiler as it is not normally the cause and especially not for simple things like this. But in this case I am running it in Studio and after just adding the : ppgAcDiff++; (and also a ppgACDiff--;) The result is not the same, not even the result from the function there the result from the division is used. As John said, the move should be unnecessary but in my testing, the result from the function did change. I will try to use a test function that do something simple and see the result. I get back. Maybe the problem is in the function. And Richard again, I am used to ask all kind of questions here, one more stupid than the other, and I am used to get great support from you or anyone else here so I am not so used that you being so angry with me. Could it possible be that you have little black devil on your shoulder that triggers on the ?compiler bug? condition? It that is so, please use a frying pan or something and smash it down, I do not want to upset anyone (maybe I did so right now which I didn?t intended either) Sincerely Bengt Ragnemalm _____ Fr?n: icc-avr-bounces@imagecraft.com [mailto:icc-avr-bounces@imagecraft.com] F?r John Baraclough Skickat: den 4 maj 2007 18:27 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: [Icc-avr] Compiler bug? Hi Bengt, I assume the function at 0x00000A68 in your first listing is 'div16s', in which case the result is returned in R16/R17. That being so, then the first parameter being passed to the function S_ShortFilter(ppgAcDiff, &filtMem[channel], filterdjup, &firFiltMem[channel]); is already in the correct register pair and doesn't need to be moved. Sorry, but I don't think he problem is with the compiler. All the best for now, John At 13:44 04/05/2007, you wrote: Hi. I know that I am usually wrong about this but this looks like a compiler bug to me. Please have look. ppgAcDiff and acGain are signed short. This simple line didn?t do anything so I checked the assembler. Actually this is very similar to my previous problem but this time the variable is used at the line right after. Just to provoke, I inserted a simple ++ in between and yes, now the result is saved. What is going on here? ppgAcDiff = ppgAcDiff/acGain; 411: ppgAcDiff = ppgAcDiff/acGain; +0000020D: 019C MOVW R18,R24 Copy register pair +0000020E: 0187 MOVW R16,R14 Copy register pair +0000020F: 940E0A68 CALL 0x00000A68 Call subroutine 414: subtractTotalDiffFiltered = S_ShortFilter(ppgAcDiff, &filtMem[channel], filterdjup, &firFiltMem[channel]); 411: ppgAcDiff = ppgAcDiff/acGain; +0000020D: 019C MOVW R18,R24 Copy register pair +0000020E: 0187 MOVW R16,R14 Copy register pair +0000020F: 940E0A6D CALL 0x00000A6D Call subroutine +00000211: 0178 MOVW R14,R16 Copy register pair 412: ppgAcDiff++; +00000212: 01C7 MOVW R24,R14 Copy register pair +00000213: 9601 ADIW R24,0x01 Add immediate to word +00000214: 017C MOVW R14,R24 Copy register pair 414: subtractTotalDiffFiltered = S_ShortFilter(ppgAcDiff, &filtMem[channel], filterdjup, &firFiltMem[channel]); /Bengt ________________________________________________________________ Bengt Ragnemalm Tel +46 13 22 24 97 Research engineer FAX: +46 13 10 19 02 Link?pings Universitet mailto:bengt.ragnemalm@imt.liu.se Inst. f?r Medicinsk Teknik Internet: http://www.imt.liu.se S-581 85 Link?ping SWEDEN _______________________________________________ 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/20070507/8eeca777/attachment.html From richard-lists at imagecraft.com Mon May 7 00:43:22 2007 From: richard-lists at imagecraft.com (Richard) Date: Mon May 7 00:53:13 2007 Subject: SV: [Icc-avr] Compiler bug? In-Reply-To: <002101c79073$45b929b0$b160ec82@Shagrat> References: <00c101c78e49$f1712770$b160ec82@Shagrat> <002101c79073$45b929b0$b160ec82@Shagrat> Message-ID: <6.1.0.6.2.20070507003519.05760150@192.168.100.42> Sorry if I sound accusatory. I really just meant to ask for more clarification. Here's what I recommend you to do, either create the smallest compilable program, or even just document what you have, with things like // ppgAcDiff is XYZ at this point ppgAcDiff = ppgAcDiff/acGain; ppgAcDiff++; // ppgAcDiff is ABC here subtractTotalDiffFiltered = S_ShortFilter(ppgAcDiff, &filtMem[channel], filterdjup, &firFiltMem[channel]); // When S_ShortFilter is entered, the first argument has QWE instead of ABC Especially if you trim it down to a compilable function, with this type of description, I can easily say something like, yes, it sounds like a bug, or no, it's just the way the C semantic is, or I can compile it, and say, the code looks OK or not. In other words, just describe what you see. It makes it easier to determine what questions I need to ask. For example, in this email, you said: >The result is not the same, not even the result from the function there >the result from the division is used. > >As John said, the move should be unnecessary but in my testing, the result >from the function did change. I will try to use a test function that do >something simple and see the result. I get back. Maybe the problem is in >the function. "The result is not the same" Which result? If you just point to the code and say, and result should be XYZ but AVR Studio shows ABC, it would be more useful. Hope this clarifies. At 11:45 PM 5/6/2007, Bengt Ragnemalm wrote: >Please Richartd, try to be patient with me. I am just trying to get some >help and am truly sorry if you are feeling ?spammed?. I will try to be >more precise in the future. > >My problem is that I do not get any result from the simple division >?ppgAcDiff = ppgAcDiff/acGain;? > >As I said, I always am very careful about accusing the compiler as it is >not normally the cause and especially not for simple things like this. But >in this case I am running it in Studio and after just adding the >: ppgAcDiff++; (and also a ppgACDiff--;) The result is not the same, >not even the result from the function there the result from the division >is used. > >As John said, the move should be unnecessary but in my testing, the result >from the function did change. I will try to use a test function that do >something simple and see the result. I get back. Maybe the problem is in >the function. > >And Richard again, I am used to ask all kind of questions here, one more >stupid than the other, and I am used to get great support from you or >anyone else here so I am not so used that you being so angry with me. >Could it possible be that you have little black devil on your shoulder >that triggers on the ?compiler bug? condition? It that is so, please use a >frying pan or something and smash it down, I do not want to upset anyone >(maybe I did so right now which I didn?t intended either) > >Sincerely >Bengt Ragnemalm > > >---------- >Fr?n: icc-avr-bounces@imagecraft.com >[mailto:icc-avr-bounces@imagecraft.com] F?r John Baraclough >Skickat: den 4 maj 2007 18:27 >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: [Icc-avr] Compiler bug? > >Hi Bengt, > >I assume the function at 0x00000A68 in your first listing is 'div16s', in >which case the result is returned in R16/R17. That being so, then the >first parameter being passed to the function > >S_ShortFilter(ppgAcDiff, &filtMem[channel], filterdjup, &firFiltMem[channel]); > >is already in the correct register pair and doesn't need to be moved. >Sorry, but I don't think he problem is with the compiler. > >All the best for now, >John > > >At 13:44 04/05/2007, you wrote: > >Hi. > >I know that I am usually wrong about this but this looks like a compiler >bug to me. Please have look. > >ppgAcDiff and acGain are signed short. > >This simple line didn?t do anything so I checked the assembler. Actually >this is very similar to my previous problem but this time the variable is >used at the line right after. Just to provoke, I inserted a simple ++ in >between and yes, now the result is saved. What is going on here? > >ppgAcDiff = ppgAcDiff/acGain; > > >411: ppgAcDiff = ppgAcDiff/acGain; >+0000020D: 019C MOVW R18,R24 Copy register pair >+0000020E: 0187 MOVW R16,R14 Copy register pair >+0000020F: 940E0A68 CALL 0x00000A68 Call subroutine >414: subtractTotalDiffFiltered = S_ShortFilter(ppgAcDiff, >&filtMem[channel], filterdjup, &firFiltMem[channel]); > > > >411: ppgAcDiff = ppgAcDiff/acGain; >+0000020D: 019C MOVW R18,R24 Copy register pair >+0000020E: 0187 MOVW R16,R14 Copy register pair >+0000020F: 940E0A6D CALL 0x00000A6D Call subroutine >+00000211: 0178 MOVW R14,R16 Copy register pair >412: ppgAcDiff++; >+00000212: 01C7 MOVW R24,R14 Copy register pair >+00000213: 9601 ADIW R24,0x01 Add immediate to word >+00000214: 017C MOVW R14,R24 Copy register pair >414: subtractTotalDiffFiltered = S_ShortFilter(ppgAcDiff, >&filtMem[channel], filterdjup, &firFiltMem[channel]); > >/Bengt >________________________________________________________________ > >Bengt Ragnemalm Tel +46 13 22 24 97 > >Research engineer FAX: +46 13 10 19 02 > >Link?pings >Universitet >mailto:bengt.ragnemalm@imt.liu.se > >Inst. f?r Medicinsk Teknik >Internet: http://www.imt.liu.se > >S-581 85 Link?ping SWEDEN > > > >_______________________________________________ >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 // richard (This email is for mailing lists. To reach me directly, please use richard at imagecraft.com) From david_brown at hotpop.com Mon May 7 01:27:12 2007 From: david_brown at hotpop.com (David Brown) Date: Mon May 7 01:14:49 2007 Subject: SV: [Icc-avr] Compiler bug? In-Reply-To: <002101c79073$45b929b0$b160ec82@Shagrat> References: <00c101c78e49$f1712770$b160ec82@Shagrat> <002101c79073$45b929b0$b160ec82@Shagrat> Message-ID: <463EE2E0.80307@hotpop.com> Hi Bengt, Far and away the best way to get help for this sort of thing is to provide a *complete* code snippet - a function that can be compiled and will demonstrate the problem, and is as small as reasonably possible. Include both the code snippet and the generated listing file in your post, along with a description of the symptoms - as Richard said, describe what is happening, and how that differs from what you expect to see. Guessing the reason for your problem comes later - you don't start off claiming to have found a compiler bug (Richard is pretty thick-skinned, but it is still rather impolite unless you are very sure of your ground). In many cases, issues like this turn out to be misunderstandings on the programmer's part (and they often find it themselves when isolating a test case). But whether it is a compiler bug or a user error, a test case is what is needed for people to help you. mvh., David Bengt Ragnemalm wrote: > Please Richartd, try to be patient with me. I am just trying to get some > help and am truly sorry if you are feeling ?spammed?. I will try to be > more precise in the future. > > > > My problem is that I do not get any result from the simple division > ?ppgAcDiff = ppgAcDiff/acGain;? > > > > As I said, I always am very careful about accusing the compiler as it is > not normally the cause and especially not for simple things like this. > But in this case I am running it in Studio and after just adding the > : ppgAcDiff++; (and also a ppgACDiff--;) The result is not the > same, not even the result from the function there the result from the > division is used. > > > > As John said, the move should be unnecessary but in my testing, the > result from the function did change. I will try to use a test function > that do something simple and see the result. I get back. Maybe the > problem is in the function. > > > > And Richard again, I am used to ask all kind of questions here, one more > stupid than the other, and I am used to get great support from you or > anyone else here so I am not so used that you being so angry with me. > Could it possible be that you have little black devil on your shoulder > that triggers on the ?compiler bug? condition? It that is so, please use > a frying pan or something and smash it down, I do not want to upset > anyone (maybe I did so right now which I didn?t intended either) > > > > Sincerely > > Bengt Ragnemalm > > > > ------------------------------------------------------------------------ > > *Fr?n:* icc-avr-bounces@imagecraft.com > [mailto:icc-avr-bounces@imagecraft.com] *F?r *John Baraclough > *Skickat:* den 4 maj 2007 18:27 > *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: [Icc-avr] Compiler bug? > > > > Hi Bengt, > > I assume the function at 0x00000A68 in your first listing is 'div16s', > in which case the result is returned in R16/R17. That being so, then the > first parameter being passed to the function > > S_ShortFilter(ppgAcDiff, &filtMem[channel], filterdjup, > &firFiltMem[channel]); > > is already in the correct register pair and doesn't need to be moved. > Sorry, but I don't think he problem is with the compiler. > > All the best for now, > John > > > At 13:44 04/05/2007, you wrote: > > Hi. > > I know that I am usually wrong about this but this looks like a compiler > bug to me. Please have look. > > ppgAcDiff and acGain are signed short. > > This simple line didn?t do anything so I checked the assembler. Actually > this is very similar to my previous problem but this time the variable > is used at the line right after. Just to provoke, I inserted a simple ++ > in between and yes, now the result is saved. What is going on here? > > ppgAcDiff = ppgAcDiff/acGain; > > > 411: ppgAcDiff = ppgAcDiff/acGain; > +0000020D: 019C MOVW R18,R24 Copy register pair > +0000020E: 0187 MOVW R16,R14 Copy register pair > +0000020F: 940E0A68 CALL 0x00000A68 Call subroutine > 414: subtractTotalDiffFiltered = S_ShortFilter(ppgAcDiff, > &filtMem[channel], filterdjup, &firFiltMem[channel]); > > > > 411: ppgAcDiff = ppgAcDiff/acGain; > +0000020D: 019C MOVW R18,R24 Copy register pair > +0000020E: 0187 MOVW R16,R14 Copy register pair > +0000020F: 940E0A6D CALL 0x00000A6D Call subroutine > +00000211: 0178 MOVW R14,R16 Copy register pair > 412: ppgAcDiff++; > +00000212: 01C7 MOVW R24,R14 Copy register pair > +00000213: 9601 ADIW R24,0x01 Add immediate to word > +00000214: 017C MOVW R14,R24 Copy register pair > 414: subtractTotalDiffFiltered = S_ShortFilter(ppgAcDiff, > &filtMem[channel], filterdjup, &firFiltMem[channel]); > > /Bengt > ________________________________________________________________ > > Bengt Ragnemalm Tel +46 13 22 24 97 > > Research engineer FAX: +46 13 10 19 02 > > Link?pings Universitet > mailto:bengt.ragnemalm@imt.liu.se > > Inst. f?r Medicinsk Teknik Internet: http://www.imt.liu.se > > > S-581 85 Link?ping SWEDEN > > > > _______________________________________________ > 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 jh.bodin at telia.com Mon May 7 02:42:38 2007 From: jh.bodin at telia.com (Johan H. Bodin) Date: Mon May 7 02:52:02 2007 Subject: SV: [Icc-avr] Compiler bug? In-Reply-To: <463EE2E0.80307@hotpop.com> References: <00c101c78e49$f1712770$b160ec82@Shagrat> <002101c79073$45b929b0$b160ec82@Shagrat> <463EE2E0.80307@hotpop.com> Message-ID: <463EF48E.1000008@telia.com> Hej Bengt, if you have some kind of output channel, such as a serial port, you can make a "debug printout" of the variables to actually *see* what happens. Regards Johan Bodin Example: --- // ppgAcDiff and acGain come loaded with something here /**** You may want to fake other values here to see what happens: ppgAcDiff = -17; // -17/36 = 0 ;-) acGain= 36; ***/ printf ("\r\nBefore scaling: Diff=%d, Gain=%d", ppgAcDiff, acGain); ppgAcDiff = ppgAcDiff/acGain; printf ("\r\nAfter scaling: Diff=%d", ppgAcDiff); --- >> My problem is that I do not get any result from the simple division >> ?ppgAcDiff = ppgAcDiff/acGain;? From BobGardner at aol.com Mon May 7 18:29:45 2007 From: BobGardner at aol.com (BobGardner@aol.com) Date: Mon May 7 18:39:33 2007 Subject: [Icc-avr] FP error message Message-ID: Just saw 'sizeof(buf) >= fp buf size' error message. Never seen that one before. How does one manipulate the size of these buffers? Want me to send the example code? ************************************** See what's free at http://www.aol.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20070507/413405bb/attachment.html From richard at imagecraft.com Fri May 11 00:47:22 2007 From: richard at imagecraft.com (Richard) Date: Fri May 11 02:44:50 2007 Subject: [Icc-avr] Some mail messages lost due to hard drive failure Message-ID: <200705110757.l4B7uwi1095789@dragonsgate2.imagecraft.com> One of our systems suffered a hard drive failure (two less than a year old Seagate drives died within a span of 2 weeks in 2 different systems, draw your own conclusions?) Fortunately, our back up system minimizes the data loss, less minimal for the email messages because unfortunately the email clients run all the time and the backup utility cannot access the data file. So if you have emailed us in the last few weeks and are still awaiting a response from us, please email again. Sorry for the inconvenience. // richard On-line orders, support, and listservers available on web site. [ For technical support on ImageCraft products, please include all previous replies in your msgs. ] From scottk at skelleyco.com Tue May 15 21:52:33 2007 From: scottk at skelleyco.com (Scott) Date: Tue May 15 22:02:48 2007 Subject: [Icc-avr] ImageCraft ICCAVR - Startup ? Options In-Reply-To: References: Message-ID: <021d01c79776$049fdff0$0300a8c0@FIFI2> The environment is an ATmega64 with a 32 KHz watch crystal running a real time clock on AVR timer0. The problem is with an occasional watch dog reset that happens every few days or longer is resetting the AVR processor and wiping out the current real time clock values. The long term fix it to find what is causing the watchdog resets, but saving the real time clock through a watchdog reset is still a desirable program enhancement. What I would like to do is use the MCUSR register reset flags to detect the watchdog (WDRF) flag only and treat this as a warm start (i.e. a warm start as in the SRAM real time clock variables still have valid data in them). In order to do this, I need to read the MCUSR register and copy the real time clock variables before these real time clock variables are initialized, before main() is run. I think using a custom startup file is the correct place to access the MCUSR and the real time clock variables. The problem is I cannot see a straight forward way of creating a protected memory storage area just for the copies of the real time clock variables and the MCUSR flag. Of course, if it is not a warm start then the normal real time clock initialization would still apply. The idea is roughly: STARTUP- read MCUSR save MCUSR to a protected temporary location clear MCUSR (as per data sheet instructions) if MCUSR == WDRF read the real time clock values save the real time clock values in a protected temporary location memory will be initialized before main() is run, except for the protected memory- main()- read the MCUSR flag from the protected temporary location if MCUSR == WDRF read the real time clock values from the protected temporary location restore the real time clock values (i.e. overwrite the ICC initialized values) I'm open to any other suggestions on how to do this. Scott -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20070515/05b06f83/attachment.html From richard-lists at imagecraft.com Tue May 15 22:10:59 2007 From: richard-lists at imagecraft.com (Richard) Date: Tue May 15 22:20:57 2007 Subject: [Icc-avr] ImageCraft ICCAVR - Startup ? Options In-Reply-To: <021d01c79776$049fdff0$0300a8c0@FIFI2> References: <021d01c79776$049fdff0$0300a8c0@FIFI2> Message-ID: <200705160520.l4G5KtLK067075@dragonsgate2.imagecraft.com> Put it in the "noinit": #pragma data:noinit unsigned RTC_value; #pragma data:data in main(), check MCUSR, if it did not come from a watchdog, then just clears the variable. At 09:52 PM 5/15/2007, Scott wrote: >The environment is an ATmega64 with a 32 KHz watch crystal running a >real time clock on AVR timer0."urn:schemas-microsoft-com:office:office" /> > > > >The problem is with an occasional watch dog reset that happens every >few days or longer is resetting the AVR processor and wiping out the >current real time clock values. The long term fix it to find what is >causing the watchdog resets, but saving the real time clock through >a watchdog reset is still a desirable program enhancement. > > > >What I would like to do is use the MCUSR register reset flags to >detect the watchdog (WDRF) flag only and treat this as a warm start >(i.e. a warm start as in the SRAM real time clock variables still >have valid data in them). > > > > In order to do this, I need to read the MCUSR register and copy > the real time clock variables before these real time clock > variables are initialized, before main() is run. I think using a > custom startup file is the correct place to access the MCUSR and > the real time clock variables. The problem is I cannot see a > straight forward way of creating a protected memory storage area > just for the copies of the real time clock variables and the MCUSR flag. > > > >Of course, if it is not a warm start then the normal real time clock >initialization would still apply. > > > >The idea is roughly: > >STARTUP- > > read MCUSR > > save MCUSR to a protected temporary location > > clear MCUSR (as per data sheet instructions) > > if MCUSR == WDRF > > read the real time clock values > > save the real time clock values in a protected temporary location > > > >memory will be initialized before main() is run, except for the >protected memory- > > > >main()- > > read the MCUSR flag from the protected temporary location > > if MCUSR == WDRF > > read the real time clock values from the protected temporary location > > restore the real time clock values (i.e. overwrite the ICC > initialized values) > > > > > >I'm open to any other suggestions on how to do this. > > > > > >Scott >_______________________________________________ >Icc-avr mailing list >Icc-avr@imagecraft.com >http://dragonsgate.net/mailman/listinfo/icc-avr // richard (This email is for mailing lists. To reach me directly, please use richard at imagecraft.com) From richard at imagecraft.com Tue May 15 23:29:09 2007 From: richard at imagecraft.com (Richard) Date: Tue May 15 23:39:09 2007 Subject: [Icc-avr] 64 bits FP chip.... Message-ID: <200705160639.l4G6d7mj067739@dragonsgate2.imagecraft.com> I am considering producing something like this: 64 bits FP support will be provided by the new iFPLightning chip. The product is integrated fully into our compilers (initially AVR but later on supporting other ICC compilers as well). The approximate performance goals are 1 uSec for 32 bit FP MUL 1.5 uSec for DIV and ~2X for 64 bits. This is at least 15x-20X faster than the equivalent AVR code and of course free up code space on the AVR chip. The data transfer overheard is ~10 uSec to transfer two operands and a result. Complex expressions will use the intermediate results directly without data transfer. The API uses a stack architecture so interrupt can remain enabled except during the data transfer. The iFPLightning chip comes in a 16 or 18 pin DIP module, ~0.7" x 0.6" in size. The following pricing is very tentative, but is our best guess: 1-50 $30 100 $27 500 $25 1000 $22 It is highly likely that the chip will provide full high level math support such as sin/cos/etc. We are also open to other API such as DSP etc. What do you think? // richard From t.jaspers at cpseurope.com Wed May 16 00:26:39 2007 From: t.jaspers at cpseurope.com (Jaspers, Ton) Date: Wed May 16 00:36:08 2007 Subject: [Icc-avr] 64 bits FP chip.... Message-ID: <7B0EB27CF1CC93439B5CFB7526E5D74C41FA55@mickey.PBNV.local> At those price levels we will never use them. Are you sure you have the decimal point at the correct position? For example we use PXA320 (around $5), TMS320 ($2 to $3) An AVR peripheral chip in the $25 range isn't going to cut it. The average AVR is below $1, except the most advanced types. Ton Jaspers > -----Original Message----- > From: icc-avr-bounces@imagecraft.com > [mailto:icc-avr-bounces@imagecraft.com] On Behalf Of Richard > Sent: woensdag 16 mei 2007 8:29 > To: icc-announce@imagecraft.com; icc-avr@imagecraft.com; > icc-mot@imagecraft.com; icc-430@imagecraft.com; icc-arm@imagecraft.com > Subject: [Icc-avr] 64 bits FP chip.... > > I am considering producing something like this: > > 64 bits FP support will be provided by the new iFPLightning > chip. The product is integrated fully into our compilers > (initially AVR but later on supporting other ICC compilers as > well). The approximate performance goals are > > 1 uSec for 32 bit FP MUL > 1.5 uSec for DIV > and ~2X for 64 bits. > > This is at least 15x-20X faster than the equivalent AVR code > and of course free up code space on the AVR chip. > > The data transfer overheard is ~10 uSec to transfer two > operands and a result. Complex expressions will use the > intermediate results directly without data transfer. The API > uses a stack architecture so interrupt can remain enabled > except during the data transfer. > > The iFPLightning chip comes in a 16 or 18 pin DIP module, > ~0.7" x 0.6" in size. > > The following pricing is very tentative, but is our best guess: > > 1-50 $30 > 100 $27 > 500 $25 > 1000 $22 > > It is highly likely that the chip will provide full high > level math support such as sin/cos/etc. We are also open to > other API such as DSP etc. > > What do you think? > > // richard > > > _______________________________________________ > Icc-avr mailing list > Icc-avr@imagecraft.com > http://dragonsgate.net/mailman/listinfo/icc-avr > From richard-lists at imagecraft.com Wed May 16 00:50:29 2007 From: richard-lists at imagecraft.com (Richard) Date: Wed May 16 01:00:28 2007 Subject: [Icc-avr] 64 bits FP chip.... In-Reply-To: <7B0EB27CF1CC93439B5CFB7526E5D74C41FA55@mickey.PBNV.local> References: <7B0EB27CF1CC93439B5CFB7526E5D74C41FA55@mickey.PBNV.local> Message-ID: <200705160800.l4G80QTC069468@dragonsgate2.imagecraft.com> I know the price does look high, but it's a complete DIP module, not just a bare chip. The competition would be something like www.micromegacorp.com but they only do 32-bit FP and slower, for $20. At 12:26 AM 5/16/2007, Jaspers, Ton wrote: >At those price levels we will never use them. Are you sure you have >the decimal point at the correct position? > >For example we use PXA320 (around $5), TMS320 ($2 to $3) >An AVR peripheral chip in the $25 range isn't going to cut it. >The average AVR is below $1, except the most advanced types. > >Ton Jaspers // richard (This email is for mailing lists. To reach me directly, please use richard at imagecraft.com) From david_brown at hotpop.com Wed May 16 01:42:09 2007 From: david_brown at hotpop.com (David Brown) Date: Wed May 16 01:29:17 2007 Subject: [Icc-avr] 64 bits FP chip.... In-Reply-To: <200705160639.l4G6d7mj067739@dragonsgate2.imagecraft.com> References: <200705160639.l4G6d7mj067739@dragonsgate2.imagecraft.com> Message-ID: <464AC3E1.4070807@hotpop.com> Richard, this chip is a factor of 10 out in terms of value for money - and that's assuming you can run it at full speed without the AVR overhead. Factor in transfers from the AVR, and you are another factor of 10 out. I can't imagine any situation where it would be worth spending $30 to get that sort of minimal FP performance. If I have a project for which the AVR does not have the performance, I switch architectures - an ARM or a ColdFire will give you vastly better value for money. Even the smallest of these devices will do software floating point faster than this iFPLightning chip, and it will do everything else much faster too. About the only situation where this device might appeal is for hobbyists who like the DIP package and can't solder a QFP device - that's not a big customer base. If you have too much time on your hands, consider making a ICC compiler for the new ColdFire V1 cores. You'd enjoy writing it (the ColdFire cpu is very nice), and it would fit your customer type well - the ColdFire V1's are basically going to be common 8-bit Freescale devices with the old 6808 cores swapped out with a 32-bit ColdFire core. This means small and robust microcontrollers with easy-to-use peripherals, but with a much more powerful processor core. mvh., David Richard wrote: > I am considering producing something like this: > > 64 bits FP support will be provided by the new iFPLightning chip. The > product is integrated fully into our compilers (initially AVR but later > on supporting other ICC compilers as well). The approximate performance > goals are > > 1 uSec for 32 bit FP MUL > 1.5 uSec for DIV > and ~2X for 64 bits. > > This is at least 15x-20X faster than the equivalent AVR code and of > course free up code space on the AVR chip. > > The data transfer overheard is ~10 uSec to transfer two operands and a > result. Complex expressions will use the intermediate results directly > without data transfer. The API uses a stack architecture so interrupt > can remain enabled except during the data transfer. > > The iFPLightning chip comes in a 16 or 18 pin DIP module, ~0.7" x 0.6" > in size. > > The following pricing is very tentative, but is our best guess: > > 1-50 $30 > 100 $27 > 500 $25 > 1000 $22 > > It is highly likely that the chip will provide full high level math > support such as sin/cos/etc. We are also open to other API such as DSP etc. > > What do you think? > > // richard > > _______________________________________________ > Icc-avr mailing list > Icc-avr@imagecraft.com > http://dragonsgate.net/mailman/listinfo/icc-avr From richard-lists at imagecraft.com Wed May 16 01:57:45 2007 From: richard-lists at imagecraft.com (Richard) Date: Wed May 16 02:07:43 2007 Subject: [Icc-avr] 64 bits FP chip.... In-Reply-To: <464AC3E1.4070807@hotpop.com> References: <200705160639.l4G6d7mj067739@dragonsgate2.imagecraft.com> <464AC3E1.4070807@hotpop.com> Message-ID: <200705160907.l4G97g8K070217@dragonsgate2.imagecraft.com> At 01:42 AM 5/16/2007, David Brown wrote: >Richard, this chip is a factor of 10 out in terms of value for money >- and that's assuming you can run it at full speed without the AVR >overhead. Factor in transfers from the AVR, and you are another >factor of 10 out. I can't imagine any situation where it would be >worth spending $30 to get that sort of minimal FP performance. If I >have a project for which the AVR does not have the performance, I >switch architectures - an ARM or a ColdFire will give you vastly >better value for money. Even the smallest of these devices will do >software floating point faster than this iFPLightning chip, and it >will do everything else much faster too. About the only situation >where this device might appeal is for hobbyists who like the DIP >package and can't solder a QFP device - that's not a big customer base. It's based on a 70MHz ARM7TDMI. The target audience is for people who want to stay with their AVR, M8C, etc. but still want FP support. Yes, it's a relatively small market and yes, the price looks high. It's something that I will work on. >If you have too much time on your hands, consider making a ICC >compiler for the new ColdFire V1 cores. You'd enjoy writing it (the >ColdFire cpu is very nice), and it would fit your customer type well >- the ColdFire V1's are basically going to be common 8-bit Freescale >devices with the old 6808 cores swapped out with a 32-bit ColdFire >core. This means small and robust microcontrollers with easy-to-use >peripherals, but with a much more powerful processor core. Heh, no worry about too much free time :-) We are committed to doing a Parallax Propeller C. Also will be working on AVR Studio plug in integration for the AVR, and it's highly likely that we will do a PIC24 compiler and also a AVR32 UC3 compiler. ColdFire is very interesting, but it depends on the market conditions... Thanks. // richard (This email is for mailing lists. To reach me directly, please use richard at imagecraft.com) From david_brown at hotpop.com Wed May 16 03:37:31 2007 From: david_brown at hotpop.com (David Brown) Date: Wed May 16 03:24:36 2007 Subject: [Icc-avr] 64 bits FP chip.... In-Reply-To: <200705160907.l4G97g8K070217@dragonsgate2.imagecraft.com> References: <200705160639.l4G6d7mj067739@dragonsgate2.imagecraft.com> <464AC3E1.4070807@hotpop.com> <200705160907.l4G97g8K070217@dragonsgate2.imagecraft.com> Message-ID: <464ADEEB.5070906@hotpop.com> Richard wrote: > At 01:42 AM 5/16/2007, David Brown wrote: >> Richard, this chip is a factor of 10 out in terms of value for money - >> and that's assuming you can run it at full speed without the AVR >> overhead. Factor in transfers from the AVR, and you are another >> factor of 10 out. I can't imagine any situation where it would be >> worth spending $30 to get that sort of minimal FP performance. If I >> have a project for which the AVR does not have the performance, I >> switch architectures - an ARM or a ColdFire will give you vastly >> better value for money. Even the smallest of these devices will do >> software floating point faster than this iFPLightning chip, and it >> will do everything else much faster too. About the only situation >> where this device might appeal is for hobbyists who like the DIP >> package and can't solder a QFP device - that's not a big customer base. > > It's based on a 70MHz ARM7TDMI. The target audience is for people who > want to stay with their AVR, M8C, etc. but still want FP support. Yes, > it's a relatively small market and yes, the price looks high. It's > something that I will work on. > >> If you have too much time on your hands, consider making a ICC >> compiler for the new ColdFire V1 cores. You'd enjoy writing it (the >> ColdFire cpu is very nice), and it would fit your customer type well - >> the ColdFire V1's are basically going to be common 8-bit Freescale >> devices with the old 6808 cores swapped out with a 32-bit ColdFire >> core. This means small and robust microcontrollers with easy-to-use >> peripherals, but with a much more powerful processor core. > > Heh, no worry about too much free time :-) We are committed to doing a > Parallax Propeller C. Also will be working on AVR Studio plug in > integration for the AVR, and it's highly likely that we will do a PIC24 > compiler and also a AVR32 UC3 compiler. > > ColdFire is very interesting, but it depends on the market conditions... > Here are a few links about the ColdFire V1 core: http://www.freescale.com/webapp/sps/site/overview.jsp?code=DR68KV1CF&fsrch=1 http://www.freescale.com/files/microcontrollers/doc/train_ref_material/CFV1WC.pdf?fsrch=1 http://www.freescale.com/files/microcontrollers/doc/white_paper/V1CFWP.pdf?fsrch=1 mvh., David From richard-lists at imagecraft.com Wed May 16 03:39:11 2007 From: richard-lists at imagecraft.com (Richard) Date: Wed May 16 03:49:09 2007 Subject: [Icc-avr] 64 bits FP chip.... In-Reply-To: <464ADEEB.5070906@hotpop.com> References: <200705160639.l4G6d7mj067739@dragonsgate2.imagecraft.com> <464AC3E1.4070807@hotpop.com> <200705160907.l4G97g8K070217@dragonsgate2.imagecraft.com> <464ADEEB.5070906@hotpop.com> Message-ID: <200705161049.l4GAn8CQ072008@dragonsgate2.imagecraft.com> Thanks. Clearly this idea of a FP chip will not fly unless I get the cost down to may be $10 or lower. So back to the shelf it goes... ColdFire is nice. I like the 68K architecture. It's my first code generator. We shall see... At 03:37 AM 5/16/2007, David Brown wrote: >Here are a few links about the ColdFire V1 core: > >http://www.freescale.com/webapp/sps/site/overview.jsp?code=DR68KV1CF&fsrch=1 >http://www.freescale.com/files/microcontrollers/doc/train_ref_material/CFV1WC.pdf?fsrch=1 >http://www.freescale.com/files/microcontrollers/doc/white_paper/V1CFWP.pdf?fsrch=1 > // richard (This email is for mailing lists. To reach me directly, please use richard at imagecraft.com) From scottk at skelleyco.com Wed May 16 12:58:08 2007 From: scottk at skelleyco.com (Scott) Date: Wed May 16 13:07:51 2007 Subject: [Icc-avr] ImageCraft ICCAVR - Startup ? Options In-Reply-To: <200705160520.l4G5KtLK067075@dragonsgate2.imagecraft.com> References: <021d01c79776$049fdff0$0300a8c0@FIFI2> <200705160520.l4G5KtLK067075@dragonsgate2.imagecraft.com> Message-ID: <032c01c797f4$86d9bee0$0300a8c0@FIFI2> I don't fully understand this. Part of the problem is that I have a very narrow understanding of C. I need to make this work, and have limited time. Can I pay you a consulting fee and we talk by phone? Scott Kelley > -----Original Message----- > From: icc-avr-bounces@imagecraft.com > [mailto:icc-avr-bounces@imagecraft.com] On Behalf Of Richard > Sent: Tuesday, May 15, 2007 10:11 PM > To: icc-avr@imagecraft.com > Subject: Re: [Icc-avr] ImageCraft ICCAVR - Startup ? Options > > Put it in the "noinit": > > #pragma data:noinit > unsigned RTC_value; > #pragma data:data > > in main(), check MCUSR, if it did not come from a watchdog, then just > clears the variable. > > At 09:52 PM 5/15/2007, Scott wrote: > > >The environment is an ATmega64 with a 32 KHz watch crystal running a > >real time clock on AVR timer0. >"urn:schemas-microsoft-com:office:office" /> > > > > > > > >The problem is with an occasional watch dog reset that happens every > >few days or longer is resetting the AVR processor and wiping out the > >current real time clock values. The long term fix it to find what is > >causing the watchdog resets, but saving the real time clock through > >a watchdog reset is still a desirable program enhancement. > > > > > > > >What I would like to do is use the MCUSR register reset flags to > >detect the watchdog (WDRF) flag only and treat this as a warm start > >(i.e. a warm start as in the SRAM real time clock variables still > >have valid data in them). > > > > > > > > In order to do this, I need to read the MCUSR register and copy > > the real time clock variables before these real time clock > > variables are initialized, before main() is run. I think using a > > custom startup file is the correct place to access the MCUSR and > > the real time clock variables. The problem is I cannot see a > > straight forward way of creating a protected memory storage area > > just for the copies of the real time clock variables and > the MCUSR flag. > > > > > > > >Of course, if it is not a warm start then the normal real time clock > >initialization would still apply. > > > > > > > >The idea is roughly: > > > >STARTUP- > > > > read MCUSR > > > > save MCUSR to a protected temporary location > > > > clear MCUSR (as per data sheet instructions) > > > > if MCUSR == WDRF > > > > read the real time clock values > > > > save the real time clock values in a protected > temporary location > > > > > > > >memory will be initialized before main() is run, except for the > >protected memory- > > > > > > > >main()- > > > > read the MCUSR flag from the protected temporary location > > > > if MCUSR == WDRF > > > > read the real time clock values from the protected > temporary location > > > > restore the real time clock values (i.e. overwrite the ICC > > initialized values) > > > > > > > > > > > >I'm open to any other suggestions on how to do this. > > > > > > > > > > > >Scott > >_______________________________________________ > >Icc-avr mailing list > >Icc-avr@imagecraft.com > >http://dragonsgate.net/mailman/listinfo/icc-avr > > // richard (This email is for mailing lists. To reach me directly, > please use richard at imagecraft.com) > > _______________________________________________ > Icc-avr mailing list > Icc-avr@imagecraft.com > http://dragonsgate.net/mailman/listinfo/icc-avr From scottk at skelleyco.com Wed May 16 13:06:50 2007 From: scottk at skelleyco.com (Scott) Date: Wed May 16 13:16:32 2007 Subject: [Icc-avr] ImageCraft ICCAVR - Startup ? Options In-Reply-To: <200705160520.l4G5KtLK067075@dragonsgate2.imagecraft.com> References: <021d01c79776$049fdff0$0300a8c0@FIFI2> <200705160520.l4G5KtLK067075@dragonsgate2.imagecraft.com> Message-ID: <032d01c797f5$bd94b650$0300a8c0@FIFI2> OH - I think I get it: #pragma data:noinit no-init variable declarations go here #pragma data:data normal variable declarations go here If that's right, do I handle external variables the same way? > -----Original Message----- > From: icc-avr-bounces@imagecraft.com > [mailto:icc-avr-bounces@imagecraft.com] On Behalf Of Richard > Sent: Tuesday, May 15, 2007 10:11 PM > To: icc-avr@imagecraft.com > Subject: Re: [Icc-avr] ImageCraft ICCAVR - Startup ? Options > > Put it in the "noinit": > > #pragma data:noinit > unsigned RTC_value; > #pragma data:data > > in main(), check MCUSR, if it did not come from a watchdog, then just > clears the variable. > > At 09:52 PM 5/15/2007, Scott wrote: > > >The environment is an ATmega64 with a 32 KHz watch crystal running a > >real time clock on AVR timer0. >"urn:schemas-microsoft-com:office:office" /> > > > > > > > >The problem is with an occasional watch dog reset that happens every > >few days or longer is resetting the AVR processor and wiping out the > >current real time clock values. The long term fix it to find what is > >causing the watchdog resets, but saving the real time clock through > >a watchdog reset is still a desirable program enhancement. > > > > > > > >What I would like to do is use the MCUSR register reset flags to > >detect the watchdog (WDRF) flag only and treat this as a warm start > >(i.e. a warm start as in the SRAM real time clock variables still > >have valid data in them). > > > > > > > > In order to do this, I need to read the MCUSR register and copy > > the real time clock variables before these real time clock > > variables are initialized, before main() is run. I think using a > > custom startup file is the correct place to access the MCUSR and > > the real time clock variables. The problem is I cannot see a > > straight forward way of creating a protected memory storage area > > just for the copies of the real time clock variables and > the MCUSR flag. > > > > > > > >Of course, if it is not a warm start then the normal real time clock > >initialization would still apply. > > > > > > > >The idea is roughly: > > > >STARTUP- > > > > read MCUSR > > > > save MCUSR to a protected temporary location > > > > clear MCUSR (as per data sheet instructions) > > > > if MCUSR == WDRF > > > > read the real time clock values > > > > save the real time clock values in a protected > temporary location > > > > > > > >memory will be initialized before main() is run, except for the > >protected memory- > > > > > > > >main()- > > > > read the MCUSR flag from the protected temporary location > > > > if MCUSR == WDRF > > > > read the real time clock values from the protected > temporary location > > > > restore the real time clock values (i.e. overwrite the ICC > > initialized values) > > > > > > > > > > > >I'm open to any other suggestions on how to do this. > > > > > > > > > > > >Scott > >_______________________________________________ > >Icc-avr mailing list > >Icc-avr@imagecraft.com > >http://dragonsgate.net/mailman/listinfo/icc-avr > > // richard (This email is for mailing lists. To reach me directly, > please use richard at imagecraft.com) > > _______________________________________________ > Icc-avr mailing list > Icc-avr@imagecraft.com > http://dragonsgate.net/mailman/listinfo/icc-avr From albert.vanveen at pertronic.co.nz Wed May 16 13:11:06 2007 From: albert.vanveen at pertronic.co.nz (Albert van Veen) Date: Wed May 16 13:20:46 2007 Subject: [Icc-avr] ImageCraft ICCAVR - Startup ? Options In-Reply-To: <200705160520.l4G5KtLK067075@dragonsgate2.imagecraft.com> Message-ID: Maybe you have reasons for not being able to do this, but: I keep values I don't want to use in an uninit ram area. After a startup/reset it shouldn't be hard to check if these data make sense without having to check for any flags en temp storage (checksum, signature). If it's corrupted: special init. Albert. -----Original Message----- From: Richard [mailto:richard-lists@imagecraft.com] Sent: Wednesday, 16 May 2007 5:11 p.m. To: icc-avr@imagecraft.com Subject: Re: [Icc-avr] ImageCraft ICCAVR - Startup ? Options Put it in the "noinit": #pragma data:noinit unsigned RTC_value; #pragma data:data in main(), check MCUSR, if it did not come from a watchdog, then just clears the variable. At 09:52 PM 5/15/2007, Scott wrote: >The environment is an ATmega64 with a 32 KHz watch crystal running a >real time clock on AVR timer0."urn:schemas-microsoft-com:office:office" /> > > > >The problem is with an occasional watch dog reset that happens every >few days or longer is resetting the AVR processor and wiping out the >current real time clock values. The long term fix it to find what is >causing the watchdog resets, but saving the real time clock through >a watchdog reset is still a desirable program enhancement. > > > >What I would like to do is use the MCUSR register reset flags to >detect the watchdog (WDRF) flag only and treat this as a warm start >(i.e. a warm start as in the SRAM real time clock variables still >have valid data in them). > > > > In order to do this, I need to read the MCUSR register and copy > the real time clock variables before these real time clock > variables are initialized, before main() is run. I think using a > custom startup file is the correct place to access the MCUSR and > the real time clock variables. The problem is I cannot see a > straight forward way of creating a protected memory storage area > just for the copies of the real time clock variables and the MCUSR flag. > > > >Of course, if it is not a warm start then the normal real time clock >initialization would still apply. > > > >The idea is roughly: > >STARTUP- > > read MCUSR > > save MCUSR to a protected temporary location > > clear MCUSR (as per data sheet instructions) > > if MCUSR == WDRF > > read the real time clock values > > save the real time clock values in a protected temporary location > > > >memory will be initialized before main() is run, except for the >protected memory- > > > >main()- > > read the MCUSR flag from the protected temporary location > > if MCUSR == WDRF > > read the real time clock values from the protected temporary location > > restore the real time clock values (i.e. overwrite the ICC > initialized values) > > > > > >I'm open to any other suggestions on how to do this. > > > > > >Scott >_______________________________________________ >Icc-avr mailing list >Icc-avr@imagecraft.com >http://dragonsgate.net/mailman/listinfo/icc-avr // richard (This email is for mailing lists. To reach me directly, please use richard at imagecraft.com) _______________________________________________ Icc-avr mailing list Icc-avr@imagecraft.com http://dragonsgate.net/mailman/listinfo/icc-avr From j_baraclough at zetnet.co.uk Wed May 16 15:09:49 2007 From: j_baraclough at zetnet.co.uk (John Baraclough) Date: Wed May 16 15:19:21 2007 Subject: [Icc-avr] ImageCraft ICCAVR - Startup ? Options In-Reply-To: <032c01c797f4$86d9bee0$0300a8c0@FIFI2> References: <021d01c79776$049fdff0$0300a8c0@FIFI2> <200705160520.l4G5KtLK067075@dragonsgate2.imagecraft.com> <032c01c797f4$86d9bee0$0300a8c0@FIFI2> Message-ID: Not before you pay me mine from September 2006 I hope. At 20:58 16/05/2007, you wrote: > >..... Can I pay you a >consulting fee and we talk by phone? > >Scott Kelley From albert.vanveen at pertronic.co.nz Wed May 16 16:21:10 2007 From: albert.vanveen at pertronic.co.nz (Albert van Veen) Date: Wed May 16 16:30:51 2007 Subject: [Icc-avr] ImageCraft ICCAVR - Startup ? Options In-Reply-To: Message-ID: Well, I massed that up, didn't I? I wanted to write: "values I don't want to loose" of course! {If I don't want to use them, I don't declare them!} -----Original Message----- From: Albert van Veen [mailto:albert.vanveen@pertronic.co.nz] Sent: Thursday, 17 May 2007 8:11 a.m. To: Discussion list for ICCAVR and ICCtiny Users. You do NOT needtosubscribeto icc-announce if you are a member of this. Subject: RE: [Icc-avr] ImageCraft ICCAVR - Startup ? Options Maybe you have reasons for not being able to do this, but: I keep values I don't want to use in an uninit ram area. After a startup/reset it shouldn't be hard to check if these data make sense without having to check for any flags en temp storage (checksum, signature). If it's corrupted: special init. Albert. -----Original Message----- From: Richard [mailto:richard-lists@imagecraft.com] Sent: Wednesday, 16 May 2007 5:11 p.m. To: icc-avr@imagecraft.com Subject: Re: [Icc-avr] ImageCraft ICCAVR - Startup ? Options Put it in the "noinit": #pragma data:noinit unsigned RTC_value; #pragma data:data in main(), check MCUSR, if it did not come from a watchdog, then just clears the variable. At 09:52 PM 5/15/2007, Scott wrote: >The environment is an ATmega64 with a 32 KHz watch crystal running a >real time clock on AVR timer0."urn:schemas-microsoft-com:office:office" /> > > > >The problem is with an occasional watch dog reset that happens every >few days or longer is resetting the AVR processor and wiping out the >current real time clock values. The long term fix it to find what is >causing the watchdog resets, but saving the real time clock through >a watchdog reset is still a desirable program enhancement. > > > >What I would like to do is use the MCUSR register reset flags to >detect the watchdog (WDRF) flag only and treat this as a warm start >(i.e. a warm start as in the SRAM real time clock variables still >have valid data in them). > > > > In order to do this, I need to read the MCUSR register and copy > the real time clock variables before these real time clock > variables are initialized, before main() is run. I think using a > custom startup file is the correct place to access the MCUSR and > the real time clock variables. The problem is I cannot see a > straight forward way of creating a protected memory storage area > just for the copies of the real time clock variables and the MCUSR flag. > > > >Of course, if it is not a warm start then the normal real time clock >initialization would still apply. > > > >The idea is roughly: > >STARTUP- > > read MCUSR > > save MCUSR to a protected temporary location > > clear MCUSR (as per data sheet instructions) > > if MCUSR == WDRF > > read the real time clock values > > save the real time clock values in a protected temporary location > > > >memory will be initialized before main() is run, except for the >protected memory- > > > >main()- > > read the MCUSR flag from the protected temporary location > > if MCUSR == WDRF > > read the real time clock values from the protected temporary location > > restore the real time clock values (i.e. overwrite the ICC > initialized values) > > > > > >I'm open to any other suggestions on how to do this. > > > > > >Scott >_______________________________________________ >Icc-avr mailing list >Icc-avr@imagecraft.com >http://dragonsgate.net/mailman/listinfo/icc-avr // richard (This email is for mailing lists. To reach me directly, please use richard at imagecraft.com) _______________________________________________ Icc-avr mailing list Icc-avr@imagecraft.com http://dragonsgate.net/mailman/listinfo/icc-avr _______________________________________________ Icc-avr mailing list Icc-avr@imagecraft.com http://dragonsgate.net/mailman/listinfo/icc-avr From scottk at skelleyco.com Wed May 16 18:16:35 2007 From: scottk at skelleyco.com (Scott) Date: Wed May 16 18:25:58 2007 Subject: [Icc-avr] ImageCraft ICCAVR - Startup ? Options In-Reply-To: References: <021d01c79776$049fdff0$0300a8c0@FIFI2><200705160520.l4G5KtLK067075@dragonsgate2.imagecraft.com><032c01c797f4$86d9bee0$0300a8c0@FIFI2> Message-ID: <037f01c79821$033b7740$0300a8c0@FIFI2> CRAP... Sorry John. I had made a note to pay you, which I put in a convenient location at the time - in the development notes within the main code file . . . I then got "better organized" and started putting notes somewhere else, and never copied the notes over from the code file. Also explains why I overlooked some things that I was sure were on the to-do list! Send me a note off-line as to where to send payment (I think we agreed on Paypal, right?), and how much interest has accrued . . . Scott > -----Original Message----- > From: icc-avr-bounces@imagecraft.com > [mailto:icc-avr-bounces@imagecraft.com] On Behalf Of John Baraclough > Sent: Wednesday, May 16, 2007 3:10 PM > To: Discussion list for ICCAVR and ICCtiny Users. You do NOT > need tosubscribe to icc-announce if you are a member of this. > Subject: RE: [Icc-avr] ImageCraft ICCAVR - Startup ? Options > > Not before you pay me mine from September 2006 I hope. > > At 20:58 16/05/2007, you wrote: > > > >..... Can I pay you a > >consulting fee and we talk by phone? > > > >Scott Kelley > > > _______________________________________________ > Icc-avr mailing list > Icc-avr@imagecraft.com > http://dragonsgate.net/mailman/listinfo/icc-avr From richard at imagecraft.com Thu May 17 01:35:11 2007 From: richard at imagecraft.com (Richard) Date: Thu May 17 01:45:11 2007 Subject: [Icc-avr] V7.13A BETA0 Message-ID: <200705170845.l4H8jAYC088518@dragonsgate2.imagecraft.com> Most of the work were done right before the hard drive crash so I have to recreate some of the stuff. I am pretty sure the code is as current, but please do check it out to make sure I didn't lose any of the earlier fixes as well. V7.13A C Preprocessor - Reverted to the V6 behavior of expanding __FILE__ to just the file name without the path components Compiler - [PRO only] 8 bit optimization was causing some array declarations to emit erraneous "zero sized array" error. Library - Eliminated use of RAM literal strings in the library. http://www.imagecraft.com/pub/iccv7avr_v713a_beta0.exe // richard On-line orders, support, and listservers available on web site. [ For technical support on ImageCraft products, please include all previous replies in your msgs. ] From j_baraclough at zetnet.co.uk Thu May 17 03:13:14 2007 From: j_baraclough at zetnet.co.uk (John Baraclough) Date: Thu May 17 03:22:45 2007 Subject: [Icc-avr] V7.13A BETA0 In-Reply-To: <200705170845.l4H8jAYC088518@dragonsgate2.imagecraft.com> References: <200705170845.l4H8jAYC088518@dragonsgate2.imagecraft.com> Message-ID: Hi Richard, Since you already have the technology, is there a plan to introduce a '__PATH__' macro to supplement '__FILE__'? Some people may find it useful. All the best for now, John At 09:35 17/05/2007, you wrote: >Most of the work were done right before the hard drive crash so I >have to recreate some of the stuff. I am pretty sure the code is as >current, but please do check it out to make sure I didn't lose any >of the earlier fixes as well. > >V7.13A > C Preprocessor > - Reverted to the V6 behavior of expanding __FILE__ to just the file > name without the path components > Compiler > - [PRO only] 8 bit optimization was causing some array declarations > to emit erraneous "zero sized array" error. > Library > - Eliminated use of RAM literal strings in the library. > >http://www.imagecraft.com/pub/iccv7avr_v713a_beta0.exe > > >// richard > On-line orders, >support, and listservers available on web site. >[ For technical support on ImageCraft products, please include all >previous replies in your msgs. ] >_______________________________________________ >Icc-avr mailing list >Icc-avr@imagecraft.com >http://dragonsgate.net/mailman/listinfo/icc-avr > From paul.aa9gg at gmail.com Thu May 17 09:33:08 2007 From: paul.aa9gg at gmail.com (Paul Mateer) Date: Thu May 17 09:42:40 2007 Subject: [Icc-avr] USI SPI Write? Message-ID: <20f5efc40705170933tf09fd9cu49464735e3ad66bc@mail.gmail.com> Hello Group..... Does anyone have a GOOD example (in C) on how to do a write on the USI SPI? I'm using a Tiny44 in SLAVE mode and I can get it to read the data coming in, but I can't seem to get it to write correctly. I'm trying to have it send a response after it receives a command. Here is what I have: void SpiWriteByte(unsigned char byte) { USISR = (1 << USIOIF); USIDR = byte; } //--------------------------------------------------------------------- unsigned char Read_USI_SPI_Byte(void) { USISR = (1 << USIOIF); while(1) { if(USISR & (1 << USIOIF)) return USIDR; if(!(PINA & ENABLE)) break; } return USIDR; } //------------------------------------------------------------------ main() { USICR = 0x18; // init usi for 3-wire mode, external clock while(1) { if(PINA & ENABLE) // enable pin - PortA.0 { SpiWriteByte(0x01); // 1st "ACK" after enable channel = Read_USI_SPI_Byte(); // read pwm channel SpiWriteByte(0x02); // "ACK" after command a = Read_USI_SPI_Byte(); // read hi-byte SpiWriteByte(0x04); // "ACK" after command } } } //------------------------------------------------------------------ I would expect the values 1, 2, 4 to be sent, but never do. I get data but it is not correct. Any clues as to what may be wrong???? -- Paul Mateer, AA9GG Elan Engineering Corp. www.elanengr.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20070517/b9894ddf/attachment.html From jassenbaum at htp-tel.de Thu May 17 12:42:00 2007 From: jassenbaum at htp-tel.de (Johannes Assenbaum) Date: Thu May 17 12:49:39 2007 Subject: [Icc-avr] USI SPI Write? References: <20f5efc40705170933tf09fd9cu49464735e3ad66bc@mail.gmail.com> Message-ID: Hi Paul, there is an app note with C code available on atmel AVR page: "AVR319: Using the USI module for SPI communication". Some more ideas: - your master is too fast for USI SPI slave - your master sends extra clocks after ENABLE goes inactive - your master uses different SPI mode or phase than slave - DDR is not setup correctly Hope it helps. Johannes > Hello Group..... > Does anyone have a GOOD example (in C) on how to do a write on the USI SPI? > I'm using a Tiny44 in SLAVE mode and I can get it to read the data coming > in, but I can't seem to get it to write correctly. I'm trying to have it > send a response after it receives a command. Here is what I have: > void SpiWriteByte(unsigned char byte) > { > USISR = (1 << USIOIF); > USIDR = byte; > } > //--------------------------------------------------------------------- > unsigned char Read_USI_SPI_Byte(void) > { > USISR = (1 << USIOIF); > while(1) > { > if(USISR & (1 << USIOIF)) return USIDR; > if(!(PINA & ENABLE)) break; > } > return USIDR; > } > //------------------------------------------------------------------ > main() > { > USICR = 0x18; // init usi for 3-wire mode, external clock > while(1) > { > if(PINA & ENABLE) // enable pin - PortA.0 > { > SpiWriteByte(0x01); // 1st "ACK" after enable > channel = Read_USI_SPI_Byte(); // read pwm channel > SpiWriteByte(0x02); // "ACK" after command > a = Read_USI_SPI_Byte(); // read hi-byte > SpiWriteByte(0x04); // "ACK" after command > } > } > } > //------------------------------------------------------------------ > I would expect the values 1, 2, 4 to be sent, but never do. I get data but > it is not correct. > Any clues as to what may be wrong???? > -- > Paul Mateer, AA9GG > Elan Engineering Corp. > www.elanengr.com From jh.bodin at telia.com Fri May 18 12:47:51 2007 From: jh.bodin at telia.com (Johan H. Bodin) Date: Fri May 18 12:57:25 2007 Subject: [Icc-avr] Packing of variables in union Message-ID: <464E02E7.3030603@telia.com> Hi, can I trust ICCAVR to *always* put all members of a union at the same starting address? Example: given the following declaration: union { short w16; char b8; long l32; char abFourBytes[4]; char abSevenBytes[7]; } u; is this true: b8 == (w16 & 0xFF) == (l32 & 0xFF) == abFourBytes[0] == abSevenBytes[0] ? I have in some dull memory that alignment in struct and union is allowed to be "impementation dependent" but I can see no reason use other than 8-bit alignment (== no "padding") in the AVR (?). I don't have my trusty old K&R at hand right now so I can't check the rules... Regards Johan Bodin, SM6LKM From j_baraclough at zetnet.co.uk Fri May 18 15:00:40 2007 From: j_baraclough at zetnet.co.uk (John Baraclough) Date: Fri May 18 15:10:23 2007 Subject: [Icc-avr] Packing of variables in union In-Reply-To: <464E02E7.3030603@telia.com> References: <464E02E7.3030603@telia.com> Message-ID: Hi Johan, Sorry, but that is very bad programming practice. K&R states: "It is the responsibility of the programmer to keep track of what type is currently stored in a union; the results are machine dependent if something is stored as one type and extracted as another." Thus writing: u.w16 = 123; c = u.b8; may not return the expected value of 123 into 'c'. Furthermore, it is unsafe to assume that what works in one release will also work in the next. I'm sure that Richard will try his utmost to retain reverse compatibility, but K&R does not require it. HTH. All the best for now, John At 20:47 18/05/2007, you wrote: >Hi, > >can I trust ICCAVR to *always* put all members of a union at >the same starting address? > >Example: > given the following declaration: > >union >{ > short w16; > char b8; > long l32; > char abFourBytes[4]; > char abSevenBytes[7]; >} u; > >is this true: > > b8 == (w16 & 0xFF) == (l32 & 0xFF) == abFourBytes[0] == abSevenBytes[0] ? > >I have in some dull memory that alignment in struct and union is allowed >to be "impementation dependent" but I can see no reason use other than >8-bit alignment (== no "padding") in the AVR (?). > >I don't have my trusty old K&R at hand right now so I can't check the rules... > > >Regards >Johan Bodin, SM6LKM > >_______________________________________________ >Icc-avr mailing list >Icc-avr@imagecraft.com >http://dragonsgate.net/mailman/listinfo/icc-avr > From richard-lists at imagecraft.com Fri May 18 16:03:03 2007 From: richard-lists at imagecraft.com (Richard) Date: Fri May 18 16:13:06 2007 Subject: [Icc-avr] Packing of variables in union In-Reply-To: References: <464E02E7.3030603@telia.com> Message-ID: <200705182313.l4IND6IE017033@dragonsgate2.imagecraft.com> What John says, actually, the things that will break the code would be either a) the endianness change, or b) the alignment changes. Neither is likely but I wouldn't want to promise it will work forever and ever. Who knows, the next group of AVRs may be super-turbo-internet-enabled-AVRs that would benefit from word aligment... At 03:00 PM 5/18/2007, John Baraclough wrote: >Hi Johan, > >Sorry, but that is very bad programming practice. > >K&R states: "It is the responsibility of the programmer to keep >track of what type is currently stored in a union; the results are >machine dependent if something is stored as one type and extracted as another." > >Thus writing: > >u.w16 = 123; >c = u.b8; > >may not return the expected value of 123 into 'c'. Furthermore, it >is unsafe to assume that what works in one release will also work in >the next. I'm sure that Richard will try his utmost to retain >reverse compatibility, but K&R does not require it. > >HTH. > >All the best for now, >John > > >At 20:47 18/05/2007, you wrote: >>Hi, >> >>can I trust ICCAVR to *always* put all members of a union at >>the same starting address? >> >>Example: >> given the following declaration: >> >>union >>{ >> short w16; >> char b8; >> long l32; >> char abFourBytes[4]; >> char abSevenBytes[7]; >>} u; >> >>is this true: >> >> b8 == (w16 & 0xFF) == (l32 & 0xFF) == abFourBytes[0] == abSevenBytes[0] ? >> >>I have in some dull memory that alignment in struct and union is allowed >>to be "impementation dependent" but I can see no reason use other than >>8-bit alignment (== no "padding") in the AVR (?). >> >>I don't have my trusty old K&R at hand right now so I can't check >>the rules... >> >> >>Regards >>Johan Bodin, SM6LKM >> >>_______________________________________________ >>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 // richard (This email is for mailing lists. To reach me directly, please use richard at imagecraft.com) From jh.bodin at telia.com Mon May 21 00:38:23 2007 From: jh.bodin at telia.com (Johan H. Bodin) Date: Mon May 21 00:47:58 2007 Subject: [Icc-avr] Packing of variables in union In-Reply-To: <200705182313.l4IND6IE017033@dragonsgate2.imagecraft.com> References: <464E02E7.3030603@telia.com> <200705182313.l4IND6IE017033@dragonsgate2.imagecraft.com> Message-ID: <46514C6F.1000501@telia.com> Hi John, Richard, yes, I know it bad programming practice but I was a litlle bit curious and I wanted to take a shortcut reusing some old code... ;-) By the way, if I will ever need to port this code to a future big endian 40-bit GigaAVR3000++ Super Turbo I will run into a few problems anyway since 30% of the code is written in assembly language ;-) Regards Johan Richard wrote: > What John says, actually, the things that will break the code would be > either a) the endianness change, or b) the alignment changes. John Baraclough wrote: >> Sorry, but that is very bad programming practice. From sl at ecpower.dk Mon May 21 09:47:44 2007 From: sl at ecpower.dk (Steven Lose) Date: Mon May 21 09:57:26 2007 Subject: [Icc-avr] some 7.13a problem Message-ID: <072D96786BFC014AAEBA9EB07A8070EA1EB7A8@seattle.ecpower.dk> Hi Richard. Got the following problem with 7.13a which were not there with 7.13 + iccomavr fix from the 26/4-07 iccavr -o STYRING -O -g -e:0x20000 -ucrtatmegaram.o -bfunc_lit:0x8c.0x20000 -dram_end:0x10ff -bdata:0x1100.0x7fff -dFRAM:1 -dhwstk_size:120 -beeprom:0.4096 -fihx_coff -S2 @STYRING.lk -lcatmega !ERROR file 'POWERMESSURE.o': undefined symbol 'uint2fp' !ERROR file 'POWERMESSURE.o': undefined symbol 'ulong2fp' C:\iccv7avr\bin\imakew.exe: Error code 1 Done: there are error(s). Exit code: 1. Mon May 21 18:04:36 2007 Med venlig hilsen / Best regards / mit freundlichen Gr??en EC POWER A/S Steven Lose Software Ingeni?r Tlf.: +45 87434100 Direkte tlf. +45 58286608 Email: sl@ecpower.dk www.ecpower.dk -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20070521/a044ebbe/attachment.html From j_baraclough at zetnet.co.uk Mon May 21 13:25:48 2007 From: j_baraclough at zetnet.co.uk (John Baraclough) Date: Mon May 21 13:35:43 2007 Subject: [Icc-avr] some 7.13a problem In-Reply-To: <072D96786BFC014AAEBA9EB07A8070EA1EB7A8@seattle.ecpower.dk> References: <072D96786BFC014AAEBA9EB07A8070EA1EB7A8@seattle.ecpower.dk> Message-ID: Hi Steven, Are you sure that you haven't moved some variable declarations to a another file? That error usually stems from variables being declared in a different file and not being declared as 'extern' in the code file, so the linker doesn't know what to do. All the best for now, John At 17:47 21/05/2007, you wrote: >Content-Type: multipart/alternative; > boundary="----_=_NextPart_001_01C79BC7.C1B33DAC" >Content-class: urn:content-classes:message > >Hi Richard. > >Got the following problem with 7.13a which were >not there with 7.13 + iccomavr fix from the 26/4-07 > > iccavr -o STYRING -O -g -e:0x20000 > -ucrtatmegaram.o -bfunc_lit:0x8c.0x20000 > -dram_end:0x10ff -bdata:0x1100.0x7fff -dFRAM:1 > -dhwstk_size:120 -beeprom:0.4096 -fihx_coff -S2 @STYRING.lk -lcatmega >!ERROR file 'POWERMESSURE.o': undefined symbol 'uint2fp' >!ERROR file 'POWERMESSURE.o': undefined symbol 'ulong2fp' >C:\iccv7avr\bin\imakew.exe: Error code 1 >Done: there are error(s). Exit code: 1. Mon May 21 18:04:36 2007 > > >Med venlig hilsen / Best regards / mit freundlichen Gr??en > >EC POWER A/S > >Steven Lose > >Software Ingeni?r > >Tlf.: +45 87434100 > >Direkte tlf. +45 58286608 > >Email: sl@ecpower.dk > >www.ecpower.dk > >_______________________________________________ >Icc-avr mailing list >Icc-avr@imagecraft.com >http://dragonsgate.net/mailman/listinfo/icc-avr -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20070521/99913cd0/attachment.html From richard-lists at imagecraft.com Mon May 21 13:53:26 2007 From: richard-lists at imagecraft.com (Richard) Date: Mon May 21 14:03:38 2007 Subject: [Icc-avr] some 7.13a problem In-Reply-To: References: <072D96786BFC014AAEBA9EB07A8070EA1EB7A8@seattle.ecpower.dk> Message-ID: <200705212103.l4LL3bSv056246@dragonsgate2.imagecraft.com> I think it's a genuine problem.... an artifact or something got lost. I will need to track it down... At 01:25 PM 5/21/2007, you wrote: >Hi Steven, > >Are you sure that you haven't moved some variable declarations to a >another file? That error usually stems from variables being declared >in a different file and not being declared as 'extern' in the code >file, so the linker doesn't know what to do. > >All the best for now, >John > // richard (This email is for mailing lists. To reach me directly, please use richard at imagecraft.com) From sl at ecpower.dk Mon May 21 15:33:43 2007 From: sl at ecpower.dk (Steven Lose) Date: Mon May 21 15:43:24 2007 Subject: SV: [Icc-avr] some 7.13a problem Message-ID: <072D96786BFC014AAEBA9EB07A8070EA1EB7A9@seattle.ecpower.dk> Hi John. No, I tried to go back to the older version, and then it was gone again. (or the older version can not detect the error you say) But I only have one external variable in the whole project, so I don't think it is it. Med venlig hilsen / Best regards / mit freundlichen Gr??en EC POWER A/S Steven Lose Software Ingeni?r Tlf.: +45 87434100 Direkte tlf. +45 58286608 Email: sl@ecpower.dk www.ecpower.dk ________________________________ Fra: icc-avr-bounces@imagecraft.com [mailto:icc-avr-bounces@imagecraft.com] P? vegne af John Baraclough Sendt: 21. maj 2007 22:26 Til: Discussion list for ICCAVR and ICCtiny Users. You do NOT need tosubscribe to icc-announce if you are a member of this. Emne: Re: [Icc-avr] some 7.13a problem Hi Steven, Are you sure that you haven't moved some variable declarations to a another file? That error usually stems from variables being declared in a different file and not being declared as 'extern' in the code file, so the linker doesn't know what to do. All the best for now, John At 17:47 21/05/2007, you wrote: Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C79BC7.C1B33DAC" Content-class: urn:content-classes:message Hi Richard. Got the following problem with 7.13a which were not there with 7.13 + iccomavr fix from the 26/4-07 iccavr -o STYRING -O -g -e:0x20000 -ucrtatmegaram.o -bfunc_lit:0x8c.0x20000 -dram_end:0x10ff -bdata:0x1100.0x7fff -dFRAM:1 -dhwstk_size:120 -beeprom:0.4096 -fihx_coff -S2 @STYRING.lk -lcatmega !ERROR file 'POWERMESSURE.o': undefined symbol 'uint2fp' !ERROR file 'POWERMESSURE.o': undefined symbol 'ulong2fp' C:\iccv7avr\bin\imakew.exe: Error code 1 Done: there are error(s). Exit code: 1. Mon May 21 18:04:36 2007 Med venlig hilsen / Best regards / mit freundlichen Gr??en EC POWER A/S Steven Lose Software Ingeni?r Tlf.: +45 87434100 Direkte tlf. +45 58286608 Email: sl@ecpower.dk www.ecpower.dk _______________________________________________ Icc-avr mailing list Icc-avr@imagecraft.com http://dragonsgate.net/mailman/listinfo/icc-avr -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20070522/337c34c6/attachment.html From sl at ecpower.dk Mon May 21 15:33:54 2007 From: sl at ecpower.dk (Steven Lose) Date: Mon May 21 15:43:33 2007 Subject: SV: [Icc-avr] some 7.13a problem Message-ID: <072D96786BFC014AAEBA9EB07A8070EA1EB7AA@seattle.ecpower.dk> OK Med venlig hilsen / Best regards / mit freundlichen Gr??en EC POWER A/S Steven Lose Software Ingeni?r Tlf.: +45 87434100 Direkte tlf. +45 58286608 Email: sl@ecpower.dk www.ecpower.dk -----Oprindelig meddelelse----- Fra: icc-avr-bounces@imagecraft.com [mailto:icc-avr-bounces@imagecraft.com] P? vegne af Richard Sendt: 21. maj 2007 22:53 Til: Discussion list for ICCAVR and ICCtiny Users. You do NOT need tosubscribe to icc-announce if you are a member of this. Emne: Re: [Icc-avr] some 7.13a problem I think it's a genuine problem.... an artifact or something got lost. I will need to track it down... At 01:25 PM 5/21/2007, you wrote: >Hi Steven, > >Are you sure that you haven't moved some variable declarations to a >another file? That error usually stems from variables being declared >in a different file and not being declared as 'extern' in the code >file, so the linker doesn't know what to do. > >All the best for now, >John > // 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 at imagecraft.com Mon May 21 16:57:16 2007 From: richard at imagecraft.com (Richard F. Man) Date: Mon May 21 17:07:30 2007 Subject: [Icc-avr] Fwd: DMS ICCAVR PLUGIN FOR ECLIPSE Message-ID: <200705212357.l4LNvrCf072789@postman.bayarea.net> For the Eclipse fans! Since I don't use Eclipse, can someone try it out and let me know how well it works? Thanks. >Good moorning, > >I am using of iccavr7 to more than the 3 years, and is very good the >compiler from IMAGECRAFT. >I created one plugin for ICCAVR7 to use with Eclipse SDK >site: >http://sourceforge.net/projects/dms-iccavr/ > > >Greetings >Dimitri Marques Silva > From richard-lists at imagecraft.com Tue May 22 01:30:10 2007 From: richard-lists at imagecraft.com (Richard) Date: Tue May 22 01:40:26 2007 Subject: V7.13A BETA1 Re: [Icc-avr] some 7.13a problem In-Reply-To: <072D96786BFC014AAEBA9EB07A8070EA1EB7A8@seattle.ecpower.dk> References: <072D96786BFC014AAEBA9EB07A8070EA1EB7A8@seattle.ecpower.dk> Message-ID: <200705220840.l4M8eO0Z063579@dragonsgate2.imagecraft.com> Fixed in beta1, the only change since beta0 is the re-addition of the missing functions http://www.imagecraft.com/poub/iccv7avr_v713a_beta1.exe At 09:47 AM 5/21/2007, you wrote: >Hi Richard. > >Got the following problem with 7.13a which were not there with 7.13 >+ iccomavr fix from the 26/4-07 > > iccavr -o STYRING -O -g -e:0x20000 -ucrtatmegaram.o > -bfunc_lit:0x8c.0x20000 -dram_end:0x10ff -bdata:0x1100.0x7fff > -dFRAM:1 -dhwstk_size:120 -beeprom:0.4096 -fihx_coff -S2 > @STYRING.lk -lcatmega >!ERROR file 'POWERMESSURE.o': undefined symbol 'uint2fp' >!ERROR file 'POWERMESSURE.o': undefined symbol 'ulong2fp' >C:\iccv7avr\bin\imakew.exe: Error code 1 >Done: there are error(s). Exit code: 1. Mon May 21 18:04:36 2007 > // richard (This email is for mailing lists. To reach me directly, please use richard at imagecraft.com) From richard-lists at imagecraft.com Tue May 22 03:28:20 2007 From: richard-lists at imagecraft.com (Richard) Date: Tue May 22 03:38:34 2007 Subject: V7.13A BETA1 Re: [Icc-avr] some 7.13a problem In-Reply-To: <200705220840.l4M8eO0Z063579@dragonsgate2.imagecraft.com> References: <072D96786BFC014AAEBA9EB07A8070EA1EB7A8@seattle.ecpower.dk> <200705220840.l4M8eO0Z063579@dragonsgate2.imagecraft.com> Message-ID: <200705221038.l4MAcWxB065275@dragonsgate2.imagecraft.com> Correct URL http://www.imagecraft.com/pub/iccv7avr_v713a_beta1.exe At 01:30 AM 5/22/2007, you wrote: >Fixed in beta1, the only change since beta0 is the re-addition of >the missing functions >http://www.imagecraft.com/poub/iccv7avr_v713a_beta1.exe > >At 09:47 AM 5/21/2007, you wrote: > >>Hi Richard. >> >>Got the following problem with 7.13a which were not there with 7.13 >>+ iccomavr fix from the 26/4-07 >> >> iccavr -o STYRING -O -g -e:0x20000 -ucrtatmegaram.o >> -bfunc_lit:0x8c.0x20000 -dram_end:0x10ff -bdata:0x1100.0x7fff >> -dFRAM:1 -dhwstk_size:120 -beeprom:0.4096 -fihx_coff -S2 >> @STYRING.lk -lcatmega >>!ERROR file 'POWERMESSURE.o': undefined symbol 'uint2fp' >>!ERROR file 'POWERMESSURE.o': undefined symbol 'ulong2fp' >>C:\iccv7avr\bin\imakew.exe: Error code 1 >>Done: there are error(s). Exit code: 1. Mon May 21 18:04:36 2007 > >// 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 // richard (This email is for mailing lists. To reach me directly, please use richard at imagecraft.com) From j_baraclough at zetnet.co.uk Tue May 22 12:05:27 2007 From: j_baraclough at zetnet.co.uk (John Baraclough) Date: Tue May 22 12:15:13 2007 Subject: SV: [Icc-avr] some 7.13a problem In-Reply-To: <072D96786BFC014AAEBA9EB07A8070EA1EB7A9@seattle.ecpower.dk> References: <072D96786BFC014AAEBA9EB07A8070EA1EB7A9@seattle.ecpower.dk> Message-ID: Hi Steven, It looks as though Richard has found it already. All the best for now, John At 23:33 21/05/2007, you wrote: >Content-Type: multipart/alternative; > boundary="----_=_NextPart_001_01C79BF8.174EC46C" >Content-class: urn:content-classes:message > >Hi John. > >No, I tried to go back to the older version, and then it was gone again. >(or the older version can not detect the error you say) >But I only have one external variable in the >whole project, so I don?t think it is it. > > >Med venlig hilsen / Best regards / mit freundlichen Gr??en > >EC POWER A/S > >Steven Lose > >Software Ingeni?r > >Tlf.: +45 87434100 > >Direkte tlf. +45 58286608 > >Email: sl@ecpower.dk > >www.ecpower.dk -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20070522/1125e611/attachment.html From sl at ecpower.dk Tue May 22 22:40:09 2007 From: sl at ecpower.dk (Steven Lose) Date: Tue May 22 22:49:54 2007 Subject: SV: V7.13A BETA1 Re: [Icc-avr] some 7.13a problem Message-ID: <072D96786BFC014AAEBA9EB07A8070EA1EB800@seattle.ecpower.dk> Hi Richard. That did it. ;o) So the last issue is the "argument not used" thing we talked about. Any success with the code I send? Med venlig hilsen / Best regards / mit freundlichen Gr??en EC POWER A/S Steven Lose Software Ingeni?r Tlf.: +45 87434100 Direkte tlf. +45 58286608 Email: sl@ecpower.dk www.ecpower.dk -----Oprindelig meddelelse----- Fra: icc-avr-bounces@imagecraft.com [mailto:icc-avr-bounces@imagecraft.com] P? vegne af Richard Sendt: 22. maj 2007 12:28 Til: Discussion list for ICCAVR and ICCtiny Users. You do NOT need tosubscribe to icc-announce if you are a member of this. Emne: Re: V7.13A BETA1 Re: [Icc-avr] some 7.13a problem Correct URL http://www.imagecraft.com/pub/iccv7avr_v713a_beta1.exe At 01:30 AM 5/22/2007, you wrote: >Fixed in beta1, the only change since beta0 is the re-addition of >the missing functions >http://www.imagecraft.com/poub/iccv7avr_v713a_beta1.exe > >At 09:47 AM 5/21/2007, you wrote: > >>Hi Richard. >> >>Got the following problem with 7.13a which were not there with 7.13 >>+ iccomavr fix from the 26/4-07 >> >> iccavr -o STYRING -O -g -e:0x20000 -ucrtatmegaram.o >> -bfunc_lit:0x8c.0x20000 -dram_end:0x10ff -bdata:0x1100.0x7fff >> -dFRAM:1 -dhwstk_size:120 -beeprom:0.4096 -fihx_coff -S2 >> @STYRING.lk -lcatmega >>!ERROR file 'POWERMESSURE.o': undefined symbol 'uint2fp' >>!ERROR file 'POWERMESSURE.o': undefined symbol 'ulong2fp' >>C:\iccv7avr\bin\imakew.exe: Error code 1 >>Done: there are error(s). Exit code: 1. Mon May 21 18:04:36 2007 > >// 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 // 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 Wed May 23 00:04:40 2007 From: richard-lists at imagecraft.com (Richard) Date: Wed May 23 00:14:57 2007 Subject: SV: V7.13A BETA1 Re: [Icc-avr] some 7.13a problem In-Reply-To: <072D96786BFC014AAEBA9EB07A8070EA1EB800@seattle.ecpower.dk> References: <072D96786BFC014AAEBA9EB07A8070EA1EB800@seattle.ecpower.dk> Message-ID: <200705230714.l4N7EuQt076373@dragonsgate2.imagecraft.com> Well, with the global optimizer ON, your arguments do have no use! The compiler is getting too smart, the solution is to probably add some sort of pragma. Otherwise, the optimizer will just delete any non-use anyway/// At 10:40 PM 5/22/2007, you wrote: >Hi Richard. > >That did it. ;o) > >So the last issue is the "argument not used" thing we talked about. >Any success with the code I send? > // richard (This email is for mailing lists. To reach me directly, please use richard at imagecraft.com) From sl at ecpower.dk Wed May 23 00:48:01 2007 From: sl at ecpower.dk (Steven Lose) Date: Wed May 23 00:57:41 2007 Subject: SV: SV: V7.13A BETA1 Re: [Icc-avr] some 7.13a problem Message-ID: <072D96786BFC014AAEBA9EB07A8070EA1EB81E@seattle.ecpower.dk> Yes, a pragma would be fine. Thanks. Med venlig hilsen / Best regards / mit freundlichen Gr??en EC POWER A/S Steven Lose Software Ingeni?r Tlf.: +45 87434100 Direkte tlf. +45 58286608 Email: sl@ecpower.dk www.ecpower.dk -----Oprindelig meddelelse----- Fra: icc-avr-bounces@imagecraft.com [mailto:icc-avr-bounces@imagecraft.com] P? vegne af Richard Sendt: 23. maj 2007 09:05 Til: Discussion list for ICCAVR and ICCtiny Users. You do NOT need tosubscribe to icc-announce if you are a member of this. Emne: Re: SV: V7.13A BETA1 Re: [Icc-avr] some 7.13a problem Well, with the global optimizer ON, your arguments do have no use! The compiler is getting too smart, the solution is to probably add some sort of pragma. Otherwise, the optimizer will just delete any non-use anyway/// At 10:40 PM 5/22/2007, you wrote: >Hi Richard. > >That did it. ;o) > >So the last issue is the "argument not used" thing we talked about. >Any success with the code I send? > // 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 Fri May 25 02:27:35 2007 From: benra at imt.liu.se (Bengt Ragnemalm) Date: Fri May 25 02:36:38 2007 Subject: [Icc-avr] iccomavr.exe error Message-ID: <000b01c79eae$edc1d5f0$b160ec82@Shagrat> I get this error: (7.13) iccavr: can't execute `C:\Program\iccv7avr\bin\iccomavr.exe' C:\Program\iccv7avr\bin\imakew.exe: Error code 100 Done: there are error(s). Exit code: 100. Fri May 25 11:21:40 2007 Haven?t figured out what I changed to get this error yet though. /Bengt ________________________________________________________________ Bengt Ragnemalm Tel +46 13 22 24 97 Research engineer FAX: +46 13 10 19 02 Link?pings Universitet mailto:bengt.ragnemalm@imt.liu.se Inst. f?r Medicinsk Teknik Internet: http://www.imt.liu.se S-581 85 Link?ping SWEDEN -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20070525/3f4e3499/attachment.html From benra at imt.liu.se Fri May 25 02:53:06 2007 From: benra at imt.liu.se (Bengt Ragnemalm) Date: Fri May 25 03:02:10 2007 Subject: [Icc-avr] RE: iccomavr.exe error Message-ID: <001301c79eb2$7e41d780$b160ec82@Shagrat> This is what I by misstake tried to do that made iccomavr.exe to crash: TOV2 &= BIT(TOV2); TOV2 is a bit in register TIFR2. The correct line would be: TIFR2 &= BIT(TOV2); /Bengt _____ Fr?n: Bengt Ragnemalm [mailto:benra@imt.liu.se] Skickat: den 25 maj 2007 11:28 Till: ICC-AVR discussion list ?mne: iccomavr.exe error I get this error: (7.13) iccavr: can't execute `C:\Program\iccv7avr\bin\iccomavr.exe' C:\Program\iccv7avr\bin\imakew.exe: Error code 100 Done: there are error(s). Exit code: 100. Fri May 25 11:21:40 2007 Haven?t figured out what I changed to get this error yet though. /Bengt ________________________________________________________________ Bengt Ragnemalm Tel +46 13 22 24 97 Research engineer FAX: +46 13 10 19 02 Link?pings Universitet mailto:bengt.ragnemalm@imt.liu.se Inst. f?r Medicinsk Teknik Internet: http://www.imt.liu.se S-581 85 Link?ping SWEDEN -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20070525/dfa2c3d1/attachment.html From richard-lists at imagecraft.com Fri May 25 02:52:14 2007 From: richard-lists at imagecraft.com (Richard) Date: Fri May 25 03:02:45 2007 Subject: [Icc-avr] iccomavr.exe error In-Reply-To: <000b01c79eae$edc1d5f0$b160ec82@Shagrat> References: <000b01c79eae$edc1d5f0$b160ec82@Shagrat> Message-ID: <200705251002.l4PA2hYO008918@dragonsgate2.imagecraft.com> Compiler crashed :-( which it should never do. Send me the generated file.i in the output directory and your .mak file and I will take a look.... At 02:27 AM 5/25/2007, you wrote: >I get this error: (7.13) > >iccavr: can't execute `C:\Program\iccv7avr\bin\iccomavr.exe' >C:\Program\iccv7avr\bin\imakew.exe: Error code 100 >Done: there are error(s). Exit code: 100. Fri May 25 11:21:40 2007 > >Haven't figured out what I changed to get this error yet though. > >/Bengt // richard (This email is for mailing lists. To reach me directly, please use richard at imagecraft.com) From asyms at technosoft.co.uk Fri May 25 06:38:43 2007 From: asyms at technosoft.co.uk (Andy Syms) Date: Fri May 25 06:51:36 2007 Subject: [Icc-avr] Differences between V6 and V7 In-Reply-To: <200705251002.l4PA2hYO008918@dragonsgate2.imagecraft.com> Message-ID: I've just started using V7 in anger and am noticing some minor but irritating differences in the IDE from V6. My two biggest bugbears are that it doesn't re-open the project that was open when it was shutdown and it doesn't remember the size of the message pane. I've looked for configuration options for these things but can't seem to find any. Have I missed something or do I just have to get used to these backward steps ? Regards Andy From asyms at technosoft.co.uk Fri May 25 07:31:16 2007 From: asyms at technosoft.co.uk (Andy Syms) Date: Fri May 25 07:44:11 2007 Subject: [Icc-avr] Differences between V6 and V7 In-Reply-To: Message-ID: > I've just started using V7 in anger and am noticing some minor but > irritating differences in the IDE from V6. Forget this. It now seems to work OK. Strange that it didn't the first half dozen or so times I shut it down and restarted it. Andy From albert.vanveen at pertronic.co.nz Mon May 21 13:01:33 2007 From: albert.vanveen at pertronic.co.nz (Albert van Veen) Date: Fri May 25 14:41:24 2007 Subject: [Icc-avr] Packing of variables in union In-Reply-To: <46514C6F.1000501@telia.com> Message-ID: Hmmm, I've been pondering about this for a day (not fultime!), and must say: if it really is bad programming, why does it exist? union that is. Not that I want to be too philosophical about programming, but stil... Albert. -----Original Message----- From: Johan H. Bodin [mailto:jh.bodin@telia.com] Sent: Monday, 21 May 2007 7:38 p.m. To: Discussion list for ICCAVR and ICCtiny Users. You do NOT need tosubscribe to icc-announce if you are a member of this. Subject: Re: [Icc-avr] Packing of variables in union Hi John, Richard, yes, I know it bad programming practice but I was a litlle bit curious and I wanted to take a shortcut reusing some old code... ;-) By the way, if I will ever need to port this code to a future big endian 40-bit GigaAVR3000++ Super Turbo I will run into a few problems anyway since 30% of the code is written in assembly language ;-) Regards Johan Richard wrote: > What John says, actually, the things that will break the code would be > either a) the endianness change, or b) the alignment changes. John Baraclough wrote: >> Sorry, but that is very bad programming practice. _______________________________________________ Icc-avr mailing list Icc-avr@imagecraft.com http://dragonsgate.net/mailman/listinfo/icc-avr From jh.bodin at telia.com Fri May 25 15:29:08 2007 From: jh.bodin at telia.com (Johan H. Bodin) Date: Fri May 25 15:38:54 2007 Subject: [Icc-avr] Packing of variables in union In-Reply-To: References: Message-ID: <46576334.2030000@telia.com> Hi Albert, > Hmmm, I've been pondering about this for a day (not fultime!), and must say: > if it really is bad programming, why does it exist? union that is. Hmmmm... The idea is probably to save some memory by physically overlapping variables that are never used at the same time. In order to claim the code as portable, the "reader" must know which union member (type/variable) the "writer" has written and access the variable in the correct "machine dependent" way... Regards Johan Bodin From BobGardner at aol.com Sat May 26 09:38:04 2007 From: BobGardner at aol.com (BobGardner@aol.com) Date: Sat May 26 09:47:54 2007 Subject: [Icc-avr] compiler size report request Message-ID: I like the '97% full' report... I'd also like to see '3K left' so I know if I can still add the bootloader. Good idea? ************************************** See what's free at http://www.aol.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20070526/843ccee9/attachment.html From j_baraclough at zetnet.co.uk Sat May 26 10:33:48 2007 From: j_baraclough at zetnet.co.uk (John Baraclough) Date: Sat May 26 10:43:35 2007 Subject: [Icc-avr] Packing of variables in union In-Reply-To: <46576334.2030000@telia.com> References: <46576334.2030000@telia.com> Message-ID: Perhaps I didn't explain myself properly. What is bad programming practice is writing one type of variable into a union and then reading back a different type. A union is very useful, but can be dangerous. Although it may produce the desired result in any compiler at any point in time, reading back a different type from that written, must not be considered to be portable. All the best for now, John At 23:29 25/05/2007, you wrote: >Hi Albert, > >>Hmmm, I've been pondering about this for a day (not fultime!), and must say: >>if it really is bad programming, why does it exist? union that is. > > >Hmmmm... The idea is probably to save some memory by physically overlapping >variables that are never used at the same time. In order to claim the code >as portable, the "reader" must know which union member (type/variable) the >"writer" has written and access the variable in the correct "machine >dependent" way... > >Regards >Johan Bodin > > > >_______________________________________________ >Icc-avr mailing list >Icc-avr@imagecraft.com >http://dragonsgate.net/mailman/listinfo/icc-avr > From benra at imt.liu.se Sun May 27 23:25:11 2007 From: benra at imt.liu.se (Bengt Ragnemalm) Date: Sun