From richard at imagecraft.com Wed Apr 4 01:51:18 2007 From: richard at imagecraft.com (Richard) Date: Wed Apr 4 01:59:57 2007 Subject: [Icc-avr] 7.13 BETA0 Message-ID: <6.1.0.6.2.20070404015026.075f7998@192.168.100.42> http://www.imagecraft.com/pub/iccv7avr_v713_beta0.exe V7.13 [ Vista compatible licensing engine ] IDE/Compiler - [PRO version only] Added "8 bit optimization." Most if not all expressions that can be done legally per Standard C rules should be done with 8 bit operations instead of the promoted int type. Should improve most programs by one to two percent and more if 8 bit variables are used extensively. This is enabled if you turn on Project->Options->Compiler->"Global Optimizations" Compiler - Fixed a bug where the compiler was generating code that save/restore R20..R23 inside an ISR even if the "Do not use R20..R23" switch is on. Header Files - USB AVR header files update // 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 bobgardner at aol.com Wed Apr 4 09:31:27 2007 From: bobgardner at aol.com (bobgardner@aol.com) Date: Wed Apr 4 09:40:21 2007 Subject: [Icc-avr] cscanf in what h file? Message-ID: <8C944EDD403794D-1E44-100F@mblk-d43.sysops.aol.com> Just upgraded to v7 pro, trying to squeeze too much code into a 16k rom... was using gets and scanf, tried using cscanf but that isnt in stdio.h (should it be??), so I dummied up an extern that looked like scanf, and now the linker says cscanf isnt in the lib. Anyone know where it is? Where is should be ? How to get it there? I'm at 99% and looking at the lst file and doing stuff like mkng strngs shrtr ________________________________________________________________________ AOL now offers free email to everyone. Find out more about what's free from AOL at AOL.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20070404/e3f46848/attachment.html From pladow at gmail.com Wed Apr 4 10:44:32 2007 From: pladow at gmail.com (Peter LaDow) Date: Wed Apr 4 10:53:08 2007 Subject: [Icc-avr] Preserved registers? Message-ID: <9e264e780704041044r3d9f7568ka3d2334cb39c055d@mail.gmail.com> I'm running into an issue with preserved registers being overwritten. For example, I have something like: extern void (*foo)(void); void bar(void) { int i; for(i=0; i < 16; i++) { foo(); } } The problem is that i keeps getting destroyed after a call to foo(). I've tracked this down and it is because foo() is using the same registers that i is using. Now foo() is not located in the same executable (i.e. not linked with bar()), and I think some sort of optimization is being done. Since bar() is unaware of foo()'s register usage, and foo() is unaware of bar()'s register usage, they can pick the same registers. (The application calls functions in the bootloader to program the flash, but the bootloader and application are compiled separately.) I do NOT have global optimizations enabled (which I think is -Wf-O8). I think my only way to handle this is to make sure that all preserved registers are saved and restored whenever leaving (or entering) code outside of the current executable. Is this my only solution, or is there an ICC way to handle this? Thanks, Pete -- "To love for the sake of being loved is human; to love for the sake of loving is Angelic." -- Alphonse de Lamartine -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20070404/409a2628/attachment.html From j_baraclough at zetnet.co.uk Wed Apr 4 11:28:07 2007 From: j_baraclough at zetnet.co.uk (John Baraclough) Date: Wed Apr 4 11:36:39 2007 Subject: [Icc-avr] cscanf in what h file? In-Reply-To: <8C944EDD403794D-1E44-100F@mblk-d43.sysops.aol.com> References: <8C944EDD403794D-1E44-100F@mblk-d43.sysops.aol.com> Message-ID: Hi Bob, No I've had a look and it doesn't seem to be in 'stdio.h'. However you will find the C source in: \iccv7avr\libsrc.avr\libsrc.zip. The file is password protected and you can find the password under the Help->Show Library Source Code Password drop-down menu. You will also need to extract the source for '_scanf.c' and include both files in your project. HTH. All the best for now, John At 17:31 04/04/2007, you wrote: >Just upgraded to v7 pro, trying to squeeze too much code into a 16k >rom... was using gets and scanf, tried using cscanf but that isnt in >stdio.h (should it be??), so I dummied up an extern that looked like >scanf, and now the linker says cscanf isnt in the lib. Anyone know >where it is? Where is should be ? How to get it there? >I'm at 99% and looking at the lst file and doing stuff like mkng strngs shrtr > >---------- >AOL now offers free email to everyone. Find out more about what's >free from AOL at AOL.com. >_______________________________________________ >Icc-avr mailing list >Icc-avr@imagecraft.com >http://dragonsgate.net/mailman/listinfo/icc-avr -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20070404/415e26e0/attachment.html From richard-lists at imagecraft.com Wed Apr 4 13:03:27 2007 From: richard-lists at imagecraft.com (Richard) Date: Wed Apr 4 13:12:06 2007 Subject: [Icc-avr] Preserved registers? In-Reply-To: <9e264e780704041044r3d9f7568ka3d2334cb39c055d@mail.gmail.co m> References: <9e264e780704041044r3d9f7568ka3d2334cb39c055d@mail.gmail.com> Message-ID: <6.1.0.6.2.20070404130115.07675bb0@192.168.100.42> Is "foo" compiled by ICC? If so, then it should not be a problem, since foo()'s code will save/restore the "Preserved Registers" (see Help on Calling Convention and Assembler Interface). If foo() is written in assembler, it will still need to obey the convention. At 10:44 AM 4/4/2007, Peter LaDow wrote: >I'm running into an issue with preserved registers being overwritten. > >For example, I have something like: > >extern void (*foo)(void); > >void bar(void) >{ > int i; > > for(i=0; i < 16; i++) > { > foo(); > } >} > >The problem is that i keeps getting destroyed after a call to foo(). I've >tracked this down and it is because foo() is using the same registers that >i is using. Now foo() is not located in the same executable ( i.e. not >linked with bar()), and I think some sort of optimization is being >done. Since bar() is unaware of foo()'s register usage, and foo() is >unaware of bar()'s register usage, they can pick the same registers. > >(The application calls functions in the bootloader to program the flash, >but the bootloader and application are compiled separately.) > >I do NOT have global optimizations enabled (which I think is -Wf-O8). > >I think my only way to handle this is to make sure that all preserved >registers are saved and restored whenever leaving (or entering) code >outside of the current executable. Is this my only solution, or is there >an ICC way to handle this? > >Thanks, >Pete // richard (This email is for mailing lists. To reach me directly, please use richard at imagecraft.com) From bobgardner at aol.com Wed Apr 4 13:34:01 2007 From: bobgardner at aol.com (bobgardner@aol.com) Date: Wed Apr 4 13:42:52 2007 Subject: [Icc-avr] Preserved registers? In-Reply-To: <6.1.0.6.2.20070404130115.07675bb0@192.168.100.42> References: <9e264e780704041044r3d9f7568ka3d2334cb39c055d@mail.gmail.com> <6.1.0.6.2.20070404130115.07675bb0@192.168.100.42> Message-ID: <8C9450FB699E0F4-CCC-1D52@webmail-mf05.sysops.aol.com> Only exception... maybe one of these programs is using r20,21,22,23 by accident when it shouldnt be?? -----Original Message----- From: richard-lists@imagecraft.com Sent: Wed, 4 Apr 2007 4:03 PM Subject: Re: [Icc-avr] Preserved registers? Is "foo" compiled by ICC? If so, then it should not be a problem, since foo()'s code will save/restore the "Preserved Registers" (see Help on Calling Convention and Assembler Interface). If foo() is written in assembler, it will still need to obey the convention. At 10:44 AM 4/4/2007, Peter LaDow wrote: >I'm running into an issue with preserved registers being overwritten. > >For example, I have something like: > >extern void (*foo)(void); > >void bar(void) >{ > int i; > > for(i=0; i < 16; i++) > { > foo(); > } >} > >The problem is that i keeps getting destroyed after a call to foo(). I've >tracked this down and it is because foo() is using the same registers that >i is using. Now foo() is not located in the same executable ( i.e. not >linked with bar()), and I think some sort of optimization is being >done. Since bar() is unaware of foo()'s register usage, and foo() is >unaware of bar()'s register usage, they can pick the same registers. > >(The application calls functions in the bootloader to program the flash, >but the bootloader and application are compiled separately.) > >I do NOT have global optimizations enabled (which I think is -Wf-O8). > >I think my only way to handle this is to make sure that all preserved >registers are saved and restored whenever leaving (or entering) code >outside of the current executable. Is this my only solution, or is there >an ICC way to handle this? > >Thanks, >Pete // 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 ________________________________________________________________________ AOL now offers free email to everyone. Find out more about what's free from AOL at AOL.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20070404/97842353/attachment.html From pladow at gmail.com Wed Apr 4 18:17:35 2007 From: pladow at gmail.com (Peter LaDow) Date: Wed Apr 4 18:26:10 2007 Subject: [Icc-avr] Preserved registers? In-Reply-To: <6.1.0.6.2.20070404130115.07675bb0@192.168.100.42> References: <9e264e780704041044r3d9f7568ka3d2334cb39c055d@mail.gmail.com> <6.1.0.6.2.20070404130115.07675bb0@192.168.100.42> Message-ID: <9e264e780704041817m67730ca0o498f2371a3a79596@mail.gmail.com> Ok, I figured out the problem. Turns out it was a stack overflow in the HW stack. The variable in question was the first variable on the SW stack (there were no local variables before this point), and the HW stack overflowed by exactly 2 bytes, thus clobbering that 1 variable. And I thought a HW stack depth of 64 would be sufficient. Turns out I needed 66. >From the documentation: "The generated code uses two stacks: a hardware stack that is used by the subroutine calls and interrupt handlers, and a software stack for allocating stack frames for parameters, temporaries and local variables. Although it may seem cumbersome, using two stacks instead of one allows the most transparent use of the data RAM." It's not clear to me how two stacks allows for "the most transparent use of the data RAM." Is this because of the use of RAMPY as a frame pointer? But couldn't the function prologue save RAMPY to the stack, copy SP to RAMPY, then decrement RAMPY to establish the stack frame? And then just pop SP into RAMPY to clear the stack frame? This is still pretty transparent use. Just curious about why 2 stacks are used. Thanks, Pete -- -- "To love for the sake of being loved is human; to love for the sake of loving is Angelic." -- Alphonse de Lamartine -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20070404/d3596ef1/attachment.html From richard-lists at imagecraft.com Wed Apr 4 21:45:16 2007 From: richard-lists at imagecraft.com (Richard) Date: Wed Apr 4 21:53:56 2007 Subject: [Icc-avr] Preserved registers? In-Reply-To: <9e264e780704041817m67730ca0o498f2371a3a79596@mail.gmail.co m> References: <9e264e780704041044r3d9f7568ka3d2334cb39c055d@mail.gmail.com> <6.1.0.6.2.20070404130115.07675bb0@192.168.100.42> <9e264e780704041817m67730ca0o498f2371a3a79596@mail.gmail.com> Message-ID: <6.1.0.6.2.20070404214157.076a8168@192.168.100.42> First, it's "Y" or R28/R29 being used as the frame pointer, not RAMPY. Second, the primary reason for having 2 stacks is code efficiency. The CALL stack is architecture in the ISA (Instruction set architecture) but it's an IO register, e.g. you can't access anything off the stack frame without the expensive copying to and fro from the IO SP. This is very expensive. I believe GCC maintains a single stack by sync'ing up the software and hardware stack at function points (not 100% sure), but I have not heard that being more or even as efficient as using two stacks. At 06:17 PM 4/4/2007, Peter LaDow wrote: >Ok, I figured out the problem. Turns out it was a stack overflow in the >HW stack. The variable in question was the first variable on the SW stack >(there were no local variables before this point), and the HW stack >overflowed by exactly 2 bytes, thus clobbering that 1 variable. And I >thought a HW stack depth of 64 would be sufficient. Turns out I needed 66. > > From the documentation: > >"The generated code uses two stacks: a hardware stack that is used by the >subroutine calls and interrupt handlers, and a software stack for >allocating stack frames for parameters, temporaries and local variables. >Although it may seem cumbersome, using two stacks instead of one allows >the most transparent use of the data RAM." > >It's not clear to me how two stacks allows for "the most transparent use >of the data RAM." Is this because of the use of RAMPY as a frame >pointer? But couldn't the function prologue save RAMPY to the stack, copy >SP to RAMPY, then decrement RAMPY to establish the stack frame? And then >just pop SP into RAMPY to clear the stack frame? This is still pretty >transparent use. > >Just curious about why 2 stacks are used. > >Thanks, >Pete // richard (This email is for mailing lists. To reach me directly, please use richard at imagecraft.com) From bobgardner at aol.com Thu Apr 5 08:10:56 2007 From: bobgardner at aol.com (bobgardner@aol.com) Date: Thu Apr 5 08:19:37 2007 Subject: [Icc-avr] How does unix echo chars? Message-ID: <8C945ABBF029236-1D1C-3D69@MBLK-R02.sysops.aol.com> I just converted from v6 where I had to write my own gets(). I made it call my getche(), which echos chars... just c=getchar() and putchar(c); I was tight on rom, so the boss sprung for the pro upgrade, so I commented my gets() out and used the one in the library, which evidently calls getchar(), and when I went to enter a number, lo and behold, no echo. I guess the fix is to comment my gets() back in, but my question is..... if you call the gets() in the library, how do you see what you're typing? Forgive me is this is abundantly obvious to unix experts... I have lots of vms and cpm and msdos experience, but my unix is pretty thin.... ________________________________________________________________________ AOL now offers free email to everyone. Find out more about what's free from AOL at AOL.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20070405/807b8df2/attachment.html From pladow at gmail.com Thu Apr 5 09:03:23 2007 From: pladow at gmail.com (Peter LaDow) Date: Thu Apr 5 09:12:43 2007 Subject: [Icc-avr] Preserved registers? In-Reply-To: <6.1.0.6.2.20070404214157.076a8168@192.168.100.42> References: <9e264e780704041044r3d9f7568ka3d2334cb39c055d@mail.gmail.com> <6.1.0.6.2.20070404130115.07675bb0@192.168.100.42> <9e264e780704041817m67730ca0o498f2371a3a79596@mail.gmail.com> <6.1.0.6.2.20070404214157.076a8168@192.168.100.42> Message-ID: <9e264e780704050903i20b01002i9b0dda7c863ab536@mail.gmail.com> On 4/4/07, Richard wrote: > > First, it's "Y" or R28/R29 being used as the frame pointer, not RAMPY. Fair enough, I was saying RAMPY, but was thinking Y. That is, using an index register as a frame pointer. Second, the primary reason for having 2 stacks is code efficiency. The CALL Ok, so it is about efficiency. I was confused about the statement that it is "the most transparent use of data RAM." stack is architecture in the ISA (Instruction set architecture) but it's an > IO register, e.g. you can't access anything off the stack frame without > the > expensive copying to and fro from the IO SP. This is very expensive. I Looking at the ISA documentation, IN/OUT instructions take 1 clock cycle. And LDS/STS take 2 clock cycles (assuming internal memory). Is there some other bottleneck? I think I know what it is--see below. believe GCC maintains a single stack by sync'ing up the software and > hardware stack at function points (not 100% sure), but I have not heard > that being more or even as efficient as using two stacks. > That is what AVR GCC does. I looked at the generated code and it does sync them up. But unfortunately, it has to disable interrupts when it does this. That I can see is an advantage to having a separate hw and sw stack (or as a disadvantage to having a stack pointer that cannot be written atomically). Thanks for the clarification. You gave me the nudge to look at what AVR GCC does and it shows why 2 stacks are better than 1! Thanks, Pete -- "To love for the sake of being loved is human; to love for the sake of loving is Angelic." -- Alphonse de Lamartine -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20070405/dea04018/attachment-0001.html From BobGardner at aol.com Thu Apr 5 16:40:42 2007 From: BobGardner at aol.com (BobGardner@aol.com) Date: Thu Apr 5 16:49:34 2007 Subject: [Icc-avr] Is this speed optimization worth it? Message-ID: I recently upgraded to v7 from v6 and I see in the lst file that a call followed by a ret gets converted to a jmp, saving 5 cycles and 1 word. I see a few places where there is an rcall followed by a ret. I think this could get converted to an rjmp, with same savings of 5 cycles, but no space. So in the big scheme of things, the only place 5 cycles would matter is in something real tight that gets called a lot, but I thought I'd toss it out there. I guess every little bit helps. ************************************** See what's free at http://www.aol.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20070405/9df752be/attachment.html From richard-lists at imagecraft.com Fri Apr 6 02:37:27 2007 From: richard-lists at imagecraft.com (Richard) Date: Fri Apr 6 02:46:12 2007 Subject: [Icc-avr] Is this speed optimization worth it? In-Reply-To: References: Message-ID: <6.1.0.6.2.20070406023640.07c19008@192.168.100.42> In all cases like these, best to find the smallest function that demonstrates the optimizations and email it to me. No test case - hard to do anything. At 04:40 PM 4/5/2007, BobGardner@aol.com wrote: >I recently upgraded to v7 from v6 and I see in the lst file that a call >followed by a ret gets converted to a jmp, saving 5 cycles and 1 word. I >see a few places where there is an rcall followed by a ret. I think this >could get converted to an rjmp, with same savings of 5 cycles, but no >space. So in the big scheme of things, the only place 5 cycles would >matter is in something real tight that gets called a lot, but I thought >I'd toss it out there. I guess every little bit helps. // richard (This email is for mailing lists. To reach me directly, please use richard at imagecraft.com) From richard-lists at imagecraft.com Fri Apr 6 02:40:11 2007 From: richard-lists at imagecraft.com (Richard) Date: Fri Apr 6 02:48:53 2007 Subject: [Icc-avr] How does unix echo chars? In-Reply-To: <8C945ABBF029236-1D1C-3D69@MBLK-R02.sysops.aol.com> References: <8C945ABBF029236-1D1C-3D69@MBLK-R02.sysops.aol.com> Message-ID: <6.1.0.6.2.20070406023734.07913b98@192.168.100.42> Unix's getchar does not echo since it may be getting input from a file (everything is either a file or a process and even processes are files in later version [ /etc/proc] ). The terminal program is the one that does echo'ing (getchar then putchar). At 08:10 AM 4/5/2007, you wrote: >I just converted from v6 where I had to write my own gets(). I made it >call my getche(), which echos chars... just c=getchar() and putchar(c); I >was tight on rom, so the boss sprung for the pro upgrade, so I commented >my gets() out and used the one in the library, which evidently calls >getchar(), and when I went to enter a number, lo and behold, no echo. I >guess the fix is to comment my gets() back in, but my question is..... if >you call the gets() in the library, how do you see what you're typing? >Forgive me is this is abundantly obvious to unix experts... I have lots of >vms and cpm and msdos experience, but my unix is pretty thin.... // richard (This email is for mailing lists. To reach me directly, please use richard at imagecraft.com) From richard-lists at imagecraft.com Fri Apr 6 02:42:14 2007 From: richard-lists at imagecraft.com (Richard) Date: Fri Apr 6 02:50:59 2007 Subject: [Icc-avr] Preserved registers? In-Reply-To: <9e264e780704050903i20b01002i9b0dda7c863ab536@mail.gmail.co m> References: <9e264e780704041044r3d9f7568ka3d2334cb39c055d@mail.gmail.com> <6.1.0.6.2.20070404130115.07675bb0@192.168.100.42> <9e264e780704041817m67730ca0o498f2371a3a79596@mail.gmail.com> <6.1.0.6.2.20070404214157.076a8168@192.168.100.42> <9e264e780704050903i20b01002i9b0dda7c863ab536@mail.gmail.com> Message-ID: <6.1.0.6.2.20070406024025.079058b0@192.168.100.42> At 09:03 AM 4/5/2007, Peter LaDow wrote: >On 4/4/07, Richard ><richard-lists@imagecraft.com> wrote: >First, it's "Y" or R28/R29 being used as the frame pointer, not RAMPY. > > > Fair enough, I was saying RAMPY, but was thinking Y. That is, using an > index register as a frame pointer. > >Second, the primary reason for having 2 stacks is code efficiency. The CALL > > >Ok, so it is about efficiency. I was confused about the statement that it >is "the most transparent use of data RAM." Well, transparent from a compiler point of view :-) Set the SP up once and never have to worry about it re: sync'ing etc. >stack is architecture in the ISA (Instruction set architecture) but it's an >IO register, e.g. you can't access anything off the stack frame without the >expensive copying to and fro from the IO SP. This is very expensive. I > > >Looking at the ISA documentation, IN/OUT instructions take 1 clock >cycle. And LDS/STS take 2 clock cycles (assuming internal memory). Is >there some other bottleneck? I think I know what it is--see below. > >believe GCC maintains a single stack by sync'ing up the software and >hardware stack at function points (not 100% sure), but I have not heard >that being more or even as efficient as using two stacks. > > >That is what AVR GCC does. I looked at the generated code and it does >sync them up. But unfortunately, it has to disable interrupts when it >does this. That I can see is an advantage to having a separate hw and sw >stack (or as a disadvantage to having a stack pointer that cannot be >written atomically). > >Thanks for the clarification. You gave me the nudge to look at what AVR >GCC does and it shows why 2 stacks are better than 1! I believe GCC is the only AVR compiler that uses a single stack. That either say GCC knows something we don't and we are all wrong, or GCC people are making different tradeoff... >Thanks, >Pete >-- >"To love for the sake of being loved is human; to love for the sake of >loving is Angelic." -- Alphonse de Lamartine >_______________________________________________ >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 sl at ecpower.dk Mon Apr 9 23:34:11 2007 From: sl at ecpower.dk (Steven Lose) Date: Mon Apr 9 23:43:24 2007 Subject: SV: [Icc-avr] 7.13 BETA0 Message-ID: <072D96786BFC014AAEBA9EB07A8070EA1A5381@seattle.ecpower.dk> HI Richard. Just installed 7.13 Beta 0 I'm using M128 and CC Gave me 2% but also some warnings that were not there before: 1th. !W C:\Steven\Kode\Styring\WATCH\WATCH.C(99):[warning] result of unsigned comparison is constant !W C:\Steven\Kode\Styring\WATCH\WATCH.C(99):[warning] expression with no effect elided When click on it, puts the cursor at the branch below void Watch(void) { static unsigned char ucLastMinute = 0; GetWatch(); if(Ur.ucMinute != ucLastMinute) { ucLastMinute = Ur.ucMinute; switch(Ur.ucMinute) { /* some cases */ } } <<--- cursor is here } 2th. !W C:\Steven\Kode\Styring\OILCHANGE\OILCHANGE.C(459):[warning] result of unsigned comparison is constant !W C:\Steven\Kode\Styring\OILCHANGE\OILCHANGE.C(459):[warning] expression with no effect elided static void UserOilChange(void) { if(!UserOilChangeBusy()) { switch(GetSystemStatus()) /* */ { /* some cases */ } } <<-- cursor is here } Any ideas? 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: 4. april 2007 10:51 Til: icc-avr@imagecraft.com Emne: [Icc-avr] 7.13 BETA0 http://www.imagecraft.com/pub/iccv7avr_v713_beta0.exe V7.13 [ Vista compatible licensing engine ] IDE/Compiler - [PRO version only] Added "8 bit optimization." Most if not all expressions that can be done legally per Standard C rules should be done with 8 bit operations instead of the promoted int type. Should improve most programs by one to two percent and more if 8 bit variables are used extensively. This is enabled if you turn on Project->Options->Compiler->"Global Optimizations" Compiler - Fixed a bug where the compiler was generating code that save/restore R20..R23 inside an ISR even if the "Do not use R20..R23" switch is on. Header Files - USB AVR header files update // 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 richard-lists at imagecraft.com Mon Apr 9 23:52:12 2007 From: richard-lists at imagecraft.com (Richard) Date: Tue Apr 10 00:01:05 2007 Subject: SV: [Icc-avr] 7.13 BETA0 In-Reply-To: <072D96786BFC014AAEBA9EB07A8070EA1A5381@seattle.ecpower.dk> References: <072D96786BFC014AAEBA9EB07A8070EA1A5381@seattle.ecpower.dk> Message-ID: <6.1.0.6.2.20070409235107.0847ed70@192.168.100.42> Someone else got something similar. My guess is that it may have to do with the default case in the switch. I have forwarded the other customer's to the optimizer team. It should be fixed shortly. Thank you for testing it. 2% is right on the mark... At 11:34 PM 4/9/2007, Steven Lose wrote: >HI Richard. > >Just installed 7.13 Beta 0 >I'm using M128 and CC >Gave me 2% but also some warnings that were not there before: > >1th. > >!W C:\Steven\Kode\Styring\WATCH\WATCH.C(99):[warning] result of unsigned >comparison is constant >!W C:\Steven\Kode\Styring\WATCH\WATCH.C(99):[warning] expression with no >effect elided > >When click on it, puts the cursor at the branch below > >void Watch(void) >{ > static unsigned char ucLastMinute = 0; > > GetWatch(); > > if(Ur.ucMinute != ucLastMinute) > { > ucLastMinute = Ur.ucMinute; > > switch(Ur.ucMinute) > { > /* some cases */ > } > } <<--- cursor is here >} > >2th. > >!W C:\Steven\Kode\Styring\OILCHANGE\OILCHANGE.C(459):[warning] result of >unsigned comparison is constant >!W C:\Steven\Kode\Styring\OILCHANGE\OILCHANGE.C(459):[warning] expression >with no effect elided > >static void UserOilChange(void) >{ > if(!UserOilChangeBusy()) > { > switch(GetSystemStatus()) /* */ > { > /* some cases */ > } > } <<-- cursor is here >} > >Any ideas? > >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: 4. april 2007 10:51 >Til: icc-avr@imagecraft.com >Emne: [Icc-avr] 7.13 BETA0 > >http://www.imagecraft.com/pub/iccv7avr_v713_beta0.exe > >V7.13 > [ Vista compatible licensing engine ] > IDE/Compiler > - [PRO version only] Added "8 bit optimization." Most if not all > expressions that can be done legally per Standard C rules should be > done with 8 bit operations instead of the promoted int type. Should > improve most programs by one to two percent and more if 8 bit > variables are used extensively. This is enabled if you turn on > Project->Options->Compiler->"Global Optimizations" > Compiler > - Fixed a bug where the compiler was generating code that > save/restore R20..R23 inside an ISR even if the "Do not use R20..R23" > switch is on. > Header Files > - USB AVR header files update > > >// 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 > > >_______________________________________________ >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 sl at ecpower.dk Tue Apr 10 00:16:52 2007 From: sl at ecpower.dk (Steven Lose) Date: Tue Apr 10 00:25:36 2007 Subject: SV: SV: [Icc-avr] 7.13 BETA0 Message-ID: <072D96786BFC014AAEBA9EB07A8070EA1A538F@seattle.ecpower.dk> Thanks Richard. 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: 10. april 2007 08:52 Til: Discussion list for ICCAVR and ICCtiny Users. You do NOT need tosubscribe to icc-announce if you are a member of this.; Discussion list for ICCAVR and ICCtiny Users. You do NOT needtosubscribeto icc-announce if you are a member of this. Emne: Re: SV: [Icc-avr] 7.13 BETA0 Someone else got something similar. My guess is that it may have to do with the default case in the switch. I have forwarded the other customer's to the optimizer team. It should be fixed shortly. Thank you for testing it. 2% is right on the mark... At 11:34 PM 4/9/2007, Steven Lose wrote: >HI Richard. > >Just installed 7.13 Beta 0 >I'm using M128 and CC >Gave me 2% but also some warnings that were not there before: > >1th. > >!W C:\Steven\Kode\Styring\WATCH\WATCH.C(99):[warning] result of unsigned >comparison is constant >!W C:\Steven\Kode\Styring\WATCH\WATCH.C(99):[warning] expression with no >effect elided > >When click on it, puts the cursor at the branch below > >void Watch(void) >{ > static unsigned char ucLastMinute = 0; > > GetWatch(); > > if(Ur.ucMinute != ucLastMinute) > { > ucLastMinute = Ur.ucMinute; > > switch(Ur.ucMinute) > { > /* some cases */ > } > } <<--- cursor is here >} > >2th. > >!W C:\Steven\Kode\Styring\OILCHANGE\OILCHANGE.C(459):[warning] result of >unsigned comparison is constant >!W C:\Steven\Kode\Styring\OILCHANGE\OILCHANGE.C(459):[warning] expression >with no effect elided > >static void UserOilChange(void) >{ > if(!UserOilChangeBusy()) > { > switch(GetSystemStatus()) /* */ > { > /* some cases */ > } > } <<-- cursor is here >} > >Any ideas? > >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: 4. april 2007 10:51 >Til: icc-avr@imagecraft.com >Emne: [Icc-avr] 7.13 BETA0 > >http://www.imagecraft.com/pub/iccv7avr_v713_beta0.exe > >V7.13 > [ Vista compatible licensing engine ] > IDE/Compiler > - [PRO version only] Added "8 bit optimization." Most if not all > expressions that can be done legally per Standard C rules should be > done with 8 bit operations instead of the promoted int type. Should > improve most programs by one to two percent and more if 8 bit > variables are used extensively. This is enabled if you turn on > Project->Options->Compiler->"Global Optimizations" > Compiler > - Fixed a bug where the compiler was generating code that > save/restore R20..R23 inside an ISR even if the "Do not use R20..R23" > switch is on. > Header Files > - USB AVR header files update > > >// 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 > > >_______________________________________________ >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 Svenn at symetrics.no Tue Apr 10 04:12:44 2007 From: Svenn at symetrics.no (=?iso-8859-1?Q?Svenn_Dahlstr=F8m?=) Date: Tue Apr 10 04:21:39 2007 Subject: SV: [Icc-avr] 7.13 BETA0 Message-ID: <23CAB4A1878E854994AB398BC4CF5B0E034FE9@SERVER.symetrics.local> Hi Richard Here is another one for the GO. struct reg{ unsigned sw1_pushed : 1, sw2_pushed : 1, sw1_sent : 1, sw2_sent : 1, CoinInputHigh : 1, service_key_state : 1, service_key_pstate : 1, CoinOk : 1, reset_possible : 1, comm_err_disable : 1, transmitting : 1, packet_received : 1, tick : 1, USB_packet_received : 1; }flag; (0195) flag.sw1_pushed=0; 619 9180 0163 LDS R24,flag 61B 9190 0164 LDS R25,flag+1 //waist of time(2cp) and flash(4byte)... 61D 7F8E ANDI R24,0xFE 61E 9390 0164 STS flag+1,R25 //waist of time(2cp) and flash(4byte)... 620 9380 0163 STS flag,R24 When more than 8 bit of bitfield types are defined in a struct like above. Every time you set/clr or check one of the bits, all bits (2 bytes) are loaded and stored... Svenn :) > > V7.13 > [ Vista compatible licensing engine ] > IDE/Compiler > - [PRO version only] Added "8 bit optimization." Most if not all > expressions that can be done legally per Standard C rules should be > done with 8 bit operations instead of the promoted int type. Should > improve most programs by one to two percent and more if 8 bit > variables are used extensively. This is enabled if you turn on > Project->Options->Compiler->"Global Optimizations" > Compiler > - Fixed a bug where the compiler was generating code that > save/restore R20..R23 inside an ISR even if the "Do not use > R20..R23" > switch is on. > Header Files > - USB AVR header files update > > > // 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 richard-lists at imagecraft.com Tue Apr 10 22:06:46 2007 From: richard-lists at imagecraft.com (Richard) Date: Tue Apr 10 22:15:43 2007 Subject: SV: [Icc-avr] 7.13 BETA0 In-Reply-To: <072D96786BFC014AAEBA9EB07A8070EA1A5381@seattle.ecpower.dk> References: <072D96786BFC014AAEBA9EB07A8070EA1A5381@seattle.ecpower.dk> Message-ID: <6.1.0.6.2.20070410220558.07973f98@192.168.100.42> Steve, try this: http://www.dragonsgate.net/pub/BETAS/iccomavr.exe Put it in the bin directory. It should fix the problem. Thanks for reporting. At 11:34 PM 4/9/2007, Steven Lose wrote: >HI Richard. > >Just installed 7.13 Beta 0 >I'm using M128 and CC >Gave me 2% but also some warnings that were not there before: > >1th. > >!W C:\Steven\Kode\Styring\WATCH\WATCH.C(99):[warning] result of unsigned >comparison is constant >!W C:\Steven\Kode\Styring\WATCH\WATCH.C(99):[warning] expression with no >effect elided > >When click on it, puts the cursor at the branch below > >void Watch(void) >{ > static unsigned char ucLastMinute = 0; > > GetWatch(); > > if(Ur.ucMinute != ucLastMinute) > { > ucLastMinute = Ur.ucMinute; > > switch(Ur.ucMinute) > { > /* some cases */ > } > } <<--- cursor is here >} > >2th. > >!W C:\Steven\Kode\Styring\OILCHANGE\OILCHANGE.C(459):[warning] result of >unsigned comparison is constant >!W C:\Steven\Kode\Styring\OILCHANGE\OILCHANGE.C(459):[warning] expression >with no effect elided > >static void UserOilChange(void) >{ > if(!UserOilChangeBusy()) > { > switch(GetSystemStatus()) /* */ > { > /* some cases */ > } > } <<-- cursor is here >} > >Any ideas? > >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: 4. april 2007 10:51 >Til: icc-avr@imagecraft.com >Emne: [Icc-avr] 7.13 BETA0 > >http://www.imagecraft.com/pub/iccv7avr_v713_beta0.exe > >V7.13 > [ Vista compatible licensing engine ] > IDE/Compiler > - [PRO version only] Added "8 bit optimization." Most if not all > expressions that can be done legally per Standard C rules should be > done with 8 bit operations instead of the promoted int type. Should > improve most programs by one to two percent and more if 8 bit > variables are used extensively. This is enabled if you turn on > Project->Options->Compiler->"Global Optimizations" > Compiler > - Fixed a bug where the compiler was generating code that > save/restore R20..R23 inside an ISR even if the "Do not use R20..R23" > switch is on. > Header Files > - USB AVR header files update > > >// 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 > > >_______________________________________________ >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 sl at ecpower.dk Tue Apr 10 22:31:06 2007 From: sl at ecpower.dk (Steven Lose) Date: Tue Apr 10 22:39:52 2007 Subject: SV: SV: [Icc-avr] 7.13 BETA0 Message-ID: <072D96786BFC014AAEBA9EB07A8070EA1A542E@seattle.ecpower.dk> Hi Richard. Fixed it, no warnings but haven't tried it on target yet. I of course lost my 2% again, but I'll try GO later. 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: 11. april 2007 07:07 Til: icc-avr@imagecraft.com Emne: Re: SV: [Icc-avr] 7.13 BETA0 Steve, try this: http://www.dragonsgate.net/pub/BETAS/iccomavr.exe Put it in the bin directory. It should fix the problem. Thanks for reporting. At 11:34 PM 4/9/2007, Steven Lose wrote: >HI Richard. > >Just installed 7.13 Beta 0 >I'm using M128 and CC >Gave me 2% but also some warnings that were not there before: > >1th. > >!W C:\Steven\Kode\Styring\WATCH\WATCH.C(99):[warning] result of unsigned >comparison is constant >!W C:\Steven\Kode\Styring\WATCH\WATCH.C(99):[warning] expression with no >effect elided > >When click on it, puts the cursor at the branch below > >void Watch(void) >{ > static unsigned char ucLastMinute = 0; > > GetWatch(); > > if(Ur.ucMinute != ucLastMinute) > { > ucLastMinute = Ur.ucMinute; > > switch(Ur.ucMinute) > { > /* some cases */ > } > } <<--- cursor is here >} > >2th. > >!W C:\Steven\Kode\Styring\OILCHANGE\OILCHANGE.C(459):[warning] result of >unsigned comparison is constant >!W C:\Steven\Kode\Styring\OILCHANGE\OILCHANGE.C(459):[warning] expression >with no effect elided > >static void UserOilChange(void) >{ > if(!UserOilChangeBusy()) > { > switch(GetSystemStatus()) /* */ > { > /* some cases */ > } > } <<-- cursor is here >} > >Any ideas? > >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: 4. april 2007 10:51 >Til: icc-avr@imagecraft.com >Emne: [Icc-avr] 7.13 BETA0 > >http://www.imagecraft.com/pub/iccv7avr_v713_beta0.exe > >V7.13 > [ Vista compatible licensing engine ] > IDE/Compiler > - [PRO version only] Added "8 bit optimization." Most if not all > expressions that can be done legally per Standard C rules should be > done with 8 bit operations instead of the promoted int type. Should > improve most programs by one to two percent and more if 8 bit > variables are used extensively. This is enabled if you turn on > Project->Options->Compiler->"Global Optimizations" > Compiler > - Fixed a bug where the compiler was generating code that > save/restore R20..R23 inside an ISR even if the "Do not use R20..R23" > switch is on. > Header Files > - USB AVR header files update > > >// 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 > > >_______________________________________________ >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 benra at imt.liu.se Wed Apr 11 02:24:01 2007 From: benra at imt.liu.se (Bengt Ragnemalm) Date: Wed Apr 11 02:32:10 2007 Subject: [Icc-avr] USART character size Message-ID: <00b801c77c1b$247495d0$b160ec82@Shagrat> Hi. I am managing some old uart code and find that the data sent was incorrect because of that the character size was not set (UBRRC) But while checking the code I found this note in the uart init file: // Set to 8 bit frame length. (This is done automaticly for compatibility but is showed her for clarity // SetBitMask(UART_UCSRC,(BIT(URSEL)|BIT(UCSZ1)); // Bit 7 is used to direct the write operation to UCSRC Does anyone know if the note about setting frame length to 8 bit automatically is correct for some AVR?s? It certainly is not for mega32. Also the commented line is incorrect as it will set the frame length to 7 bits and not 8 as intended. This code have been working for a long time just because that the actual data sent was (until now) never using bit 8. Best regards, 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/20070411/524b6100/attachment.html From benra at imt.liu.se Wed Apr 11 02:40:32 2007 From: benra at imt.liu.se (Bengt Ragnemalm) Date: Wed Apr 11 02:48:36 2007 Subject: SV: [Icc-avr] USART character size In-Reply-To: <00b801c77c1b$247495d0$b160ec82@Shagrat> References: <00b801c77c1b$247495d0$b160ec82@Shagrat> Message-ID: <00cf01c77c1d$72e2caf0$b160ec82@Shagrat> Am I totally wrong here? It seems that AVR Studio does not display the actual value of UCSSRC and UBRRH, they are always showing the same. Do I have to read the value back into a variable to be able to check what I actually have there? /Bengt _____ Fr?n: icc-avr-bounces@imagecraft.com [mailto:icc-avr-bounces@imagecraft.com] F?r Bengt Ragnemalm Skickat: den 11 april 2007 11:24 Till: ICC-AVR discussion list ?mne: [Icc-avr] USART character size Hi. I am managing some old uart code and find that the data sent was incorrect because of that the character size was not set (UBRRC) But while checking the code I found this note in the uart init file: // Set to 8 bit frame length. (This is done automaticly for compatibility but is showed her for clarity // SetBitMask(UART_UCSRC,(BIT(URSEL)|BIT(UCSZ1)); // Bit 7 is used to direct the write operation to UCSRC Does anyone know if the note about setting frame length to 8 bit automatically is correct for some AVR?s? It certainly is not for mega32. Also the commented line is incorrect as it will set the frame length to 7 bits and not 8 as intended. This code have been working for a long time just because that the actual data sent was (until now) never using bit 8. Best regards, 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/20070411/7f0baf6a/attachment-0001.html From Derek.Robertson at logitech.uk.com Wed Apr 11 03:43:50 2007 From: Derek.Robertson at logitech.uk.com (Robertson, Derek) Date: Wed Apr 11 03:53:29 2007 Subject: [Icc-avr] USART character size Message-ID: Bengt, There's a URSEL bit in UBRRH (page 162 of my data book) It needs to be set to zero for reading and writing to UBRRH as it shares the same address as UCSRC. Hope this helps. Derek ________________________________ From: Bengt Ragnemalm [mailto:benra@imt.liu.se] Sent: 11 April 2007 10:41 To: 'Discussion list for ICCAVR and ICCtiny Users. You do NOT needtosubscribeto icc-announce if you are a member of this.' Subject: SV: [Icc-avr] USART character size Am I totally wrong here? It seems that AVR Studio does not display the actual value of UCSSRC and UBRRH, they are always showing the same. Do I have to read the value back into a variable to be able to check what I actually have there? /Bengt ________________________________ Fr?n: icc-avr-bounces@imagecraft.com [mailto:icc-avr-bounces@imagecraft.com] F?r Bengt Ragnemalm Skickat: den 11 april 2007 11:24 Till: ICC-AVR discussion list ?mne: [Icc-avr] USART character size Hi. I am managing some old uart code and find that the data sent was incorrect because of that the character size was not set (UBRRC) But while checking the code I found this note in the uart init file: // Set to 8 bit frame length. (This is done automaticly for compatibility but is showed her for clarity // SetBitMask(UART_UCSRC,(BIT(URSEL)|BIT(UCSZ1)); // Bit 7 is used to direct the write operation to UCSRC Does anyone know if the note about setting frame length to 8 bit automatically is correct for some AVR's? It certainly is not for mega32. Also the commented line is incorrect as it will set the frame length to 7 bits and not 8 as intended This code have been working for a long time just because that the actual data sent was (until now) never using bit 8. Best regards, 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/20070411/f1497df8/attachment.html From sl at ecpower.dk Wed Apr 11 04:53:59 2007 From: sl at ecpower.dk (Steven Lose) Date: Wed Apr 11 05:03:21 2007 Subject: SV: SV: [Icc-avr] 7.13 BETA0 Message-ID: <072D96786BFC014AAEBA9EB07A8070EA1A549B@seattle.ecpower.dk> Hi Richard. Activating GO in 7.13 seems to have no effect! Is it activated? I have a PRO license on USB dongle. 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 Steven Lose Sendt: 11. april 2007 07:31 Til: Discussion list for ICCAVR and ICCtiny Users. You do NOT needtosubscribeto icc-announce if you are a member of this. Emne: SV: SV: [Icc-avr] 7.13 BETA0 Hi Richard. Fixed it, no warnings but haven't tried it on target yet. I of course lost my 2% again, but I'll try GO later. 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: 11. april 2007 07:07 Til: icc-avr@imagecraft.com Emne: Re: SV: [Icc-avr] 7.13 BETA0 Steve, try this: http://www.dragonsgate.net/pub/BETAS/iccomavr.exe Put it in the bin directory. It should fix the problem. Thanks for reporting. At 11:34 PM 4/9/2007, Steven Lose wrote: >HI Richard. > >Just installed 7.13 Beta 0 >I'm using M128 and CC >Gave me 2% but also some warnings that were not there before: > >1th. > >!W C:\Steven\Kode\Styring\WATCH\WATCH.C(99):[warning] result of unsigned >comparison is constant >!W C:\Steven\Kode\Styring\WATCH\WATCH.C(99):[warning] expression with no >effect elided > >When click on it, puts the cursor at the branch below > >void Watch(void) >{ > static unsigned char ucLastMinute = 0; > > GetWatch(); > > if(Ur.ucMinute != ucLastMinute) > { > ucLastMinute = Ur.ucMinute; > > switch(Ur.ucMinute) > { > /* some cases */ > } > } <<--- cursor is here >} > >2th. > >!W C:\Steven\Kode\Styring\OILCHANGE\OILCHANGE.C(459):[warning] result of >unsigned comparison is constant >!W C:\Steven\Kode\Styring\OILCHANGE\OILCHANGE.C(459):[warning] expression >with no effect elided > >static void UserOilChange(void) >{ > if(!UserOilChangeBusy()) > { > switch(GetSystemStatus()) /* */ > { > /* some cases */ > } > } <<-- cursor is here >} > >Any ideas? > >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: 4. april 2007 10:51 >Til: icc-avr@imagecraft.com >Emne: [Icc-avr] 7.13 BETA0 > >http://www.imagecraft.com/pub/iccv7avr_v713_beta0.exe > >V7.13 > [ Vista compatible licensing engine ] > IDE/Compiler > - [PRO version only] Added "8 bit optimization." Most if not all > expressions that can be done legally per Standard C rules should be > done with 8 bit operations instead of the promoted int type. Should > improve most programs by one to two percent and more if 8 bit > variables are used extensively. This is enabled if you turn on > Project->Options->Compiler->"Global Optimizations" > Compiler > - Fixed a bug where the compiler was generating code that > save/restore R20..R23 inside an ISR even if the "Do not use R20..R23" > switch is on. > Header Files > - USB AVR header files update > > >// 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 > > >_______________________________________________ >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 sl at ecpower.dk Wed Apr 11 05:07:20 2007 From: sl at ecpower.dk (Steven Lose) Date: Wed Apr 11 05:18:22 2007 Subject: [Icc-avr] Switch thing Message-ID: <072D96786BFC014AAEBA9EB07A8070EA1A549E@seattle.ecpower.dk> Hi. Is the following ok, or just bad coding? If bad coding, how is it done the "right way"? Switch(status) { Case 1: do lot of stuff If(Option enabled) { Case 2: Do optional thing } break } 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/20070411/510af20d/attachment-0001.html From Derek.Robertson at logitech.uk.com Wed Apr 11 04:07:32 2007 From: Derek.Robertson at logitech.uk.com (Robertson, Derek) Date: Wed Apr 11 05:24:57 2007 Subject: [Icc-avr] USART character size Message-ID: Ah... never actually answered the question... I guess this shared address is probably screwing up studio, so doing something like.. UBRRH &= ~BIT(7); // clear bit for reading UBRRH VarUbrr = UBRRH; UBRRH |= BIT(7); // set bit for reading UCSRC VarUcsrc = UBRRH; The watching the two variable would work round this, The data book also suggests this unsigned char USART_ReadUCSRC( void ) { unsigned char ucsrc, ubrrh; ubrrh = UBRRH; // this read reads the UBRRH value ucsrc = UCSRC; // this read reads the UCSRC value return ucsrc; } As reading the I/O location in consecutive clock cycles returns the UCSRC value, if you do the later studio may not like this if you step through it so put a breakpoint on the return and run at full speed. I can remember single stepping through eeprom write code on a AT908535 in assembler just after leaving university. Only to find that my *bug* was the fact that I was single stepping through something that was timing critical. Derek Bengt, There's a URSEL bit in UBRRH (page 162 of my data book) It needs to be set to zero for reading and writing to UBRRH as it shares the same address as UCSRC. Hope this helps. Derek ________________________________ From: Bengt Ragnemalm [mailto:benra@imt.liu.se] Sent: 11 April 2007 10:41 To: 'Discussion list for ICCAVR and ICCtiny Users. You do NOT needtosubscribeto icc-announce if you are a member of this.' Subject: SV: [Icc-avr] USART character size Am I totally wrong here? It seems that AVR Studio does not display the actual value of UCSSRC and UBRRH, they are always showing the same. Do I have to read the value back into a variable to be able to check what I actually have there? /Bengt ________________________________ Fr?n: icc-avr-bounces@imagecraft.com [mailto:icc-avr-bounces@imagecraft.com] F?r Bengt Ragnemalm Skickat: den 11 april 2007 11:24 Till: ICC-AVR discussion list ?mne: [Icc-avr] USART character size Hi. I am managing some old uart code and find that the data sent was incorrect because of that the character size was not set (UBRRC) But while checking the code I found this note in the uart init file: // Set to 8 bit frame length. (This is done automaticly for compatibility but is showed her for clarity // SetBitMask(UART_UCSRC,(BIT(URSEL)|BIT(UCSZ1)); // Bit 7 is used to direct the write operation to UCSRC Does anyone know if the note about setting frame length to 8 bit automatically is correct for some AVR's? It certainly is not for mega32. Also the commented line is incorrect as it will set the frame length to 7 bits and not 8 as intended This code have been working for a long time just because that the actual data sent was (until now) never using bit 8. Best regards, 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 From sbeaver at columbus.rr.com Wed Apr 11 05:33:08 2007 From: sbeaver at columbus.rr.com (Stephen Beaver) Date: Wed Apr 11 05:41:54 2007 Subject: [Icc-avr] Switch thing In-Reply-To: <072D96786BFC014AAEBA9EB07A8070EA1A549E@seattle.ecpower.dk> Message-ID: It might work, but it is very nasty. Reversing the logic makes it slightly less horrible: switch(status) { case 1: do_stuff(); if(Option NOT enabled) break; case 2: optional_thing(); break; } On 4/11/07 8:07 AM, "Steven Lose" wrote: > Hi. > > Is the following ok, or just bad coding? > If bad coding, how is it done the ?right way?? > > > Switch(status) > { > ?Case 1: ??????? do lot of stuff > ????????????? ??????? If(Option enabled) > ????????????????????? { > ?Case 2:???????? Do optional thing > } > break > } > > 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 mailto:bsl@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/20070411/96de0427/attachment.html From benra at imt.liu.se Wed Apr 11 05:43:42 2007 From: benra at imt.liu.se (Bengt Ragnemalm) Date: Wed Apr 11 05:51:46 2007 Subject: SV: [Icc-avr] Switch thing In-Reply-To: <072D96786BFC014AAEBA9EB07A8070EA1A549E@seattle.ecpower.dk> References: <072D96786BFC014AAEBA9EB07A8070EA1A549E@seattle.ecpower.dk> Message-ID: <012201c77c37$0987aac0$b160ec82@Shagrat> I say horrible coding if at all possible. Do you mean that you have two cases that you may enter, case 1 and case 2 there case 1 may also want to execute the code in case 2? I suggest you put the code for the cases in functions: Switch(status) { Case 1: Case1func(); if(Option enabled) Case2func() break; Case 2: Case2func(); break; } /Bengt _____ Fr?n: icc-avr-bounces@imagecraft.com [mailto:icc-avr-bounces@imagecraft.com] F?r Steven Lose Skickat: den 11 april 2007 14:07 Till: Discussion list for ICCAVR and ICCtiny Users. You do NOT needtosubscribeto icc-announce if you are a member of this. ?mne: [Icc-avr] Switch thing Hi. Is the following ok, or just bad coding? If bad coding, how is it done the ?right way?? Switch(status) { Case 1: do lot of stuff If(Option enabled) { Case 2: Do optional thing } break } 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/20070411/a3bc53df/attachment-0001.html From david_brown at hotpop.com Wed Apr 11 06:30:06 2007 From: david_brown at hotpop.com (David Brown) Date: Wed Apr 11 06:18:23 2007 Subject: [Icc-avr] Switch thing In-Reply-To: <072D96786BFC014AAEBA9EB07A8070EA1A549E@seattle.ecpower.dk> References: <072D96786BFC014AAEBA9EB07A8070EA1A549E@seattle.ecpower.dk> Message-ID: <461CE2DE.5050302@hotpop.com> Steven Lose wrote: > Hi. > > > > Is the following ok, or just bad coding? > It's bad coding. I don't know what the "right way" would be, since it is far from clear what you want to do. The sensible way to write switch statements is to consider each case as a separate block, and *always* include a "break". Thus you have: switch (status) { case 1 : { do stuff for case 1 break; }; case 2 : { do stuff for case 2 break; }; } It's not necessary to have the extra brackets for each case, but I prefer them as it keeps my indentation consistent (tab out after each "{", tab in before each "}"), and you can easily use local variables within each case block. The only exception is if you have several cases doing exactly the same thing: switch (key) { case 'A' : case 'a' : { ... break; }; } Just because C gives you more flexibility, does not mean that it is a good thing to use! mvh., David > If bad coding, how is it done the ?right way?? > > > > > > *Switch*(status) > > { > > *Case 1*: do lot of stuff > > *If*(Option enabled) > > { > > *Case 2:* Do optional thing > > } > > break > > } > > > > 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 From sl at ecpower.dk Wed Apr 11 06:42:16 2007 From: sl at ecpower.dk (Steven Lose) Date: Wed Apr 11 06:51:02 2007 Subject: SV: [Icc-avr] Switch thing Message-ID: <072D96786BFC014AAEBA9EB07A8070EA1A54B7@seattle.ecpower.dk> Hi. Looks better. But as Bengt says, I could use functions, would be much cleaner, but means that I have to pass tons of local vars and I really don't want that. Hmm.... I think it is clear enough for the reader to se what it is doing by using your example. I'll do that until someone gets a much brighter Idea. Hopefully It won't course me to many bruises. ;o) Thanks. Med venlig hilsen / Best regards / mit freundlichen Gr??en EC POWER A/S Steven Lose Software Ingeni?r Tlf.: +45 87434100 Direkte tlf. +45 58286608 Email: sl@ecpower.dk www.ecpower.dk ________________________________ Fra: icc-avr-bounces@imagecraft.com [mailto:icc-avr-bounces@imagecraft.com] P? vegne af Stephen Beaver Sendt: 11. april 2007 14:33 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] Switch thing It might work, but it is very nasty. Reversing the logic makes it slightly less horrible: switch(status) { case 1: do_stuff(); if(Option NOT enabled) break; case 2: optional_thing(); break; } On 4/11/07 8:07 AM, "Steven Lose" wrote: Hi. Is the following ok, or just bad coding? If bad coding, how is it done the "right way"? Switch(status) { Case 1: do lot of stuff If(Option enabled) { Case 2: Do optional thing } break } 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/20070411/cf9b49ac/attachment.html From sbeaver at columbus.rr.com Wed Apr 11 07:03:01 2007 From: sbeaver at columbus.rr.com (Stephen Beaver) Date: Wed Apr 11 07:11:48 2007 Subject: SV: [Icc-avr] Switch thing In-Reply-To: <072D96786BFC014AAEBA9EB07A8070EA1A54B7@seattle.ecpower.dk> Message-ID: You might also put in a comment such as shown below. That way, when someone runs Lint on it next year and it shows an error, they will know it is not really an error. - You did this deliberately. Steve switch(status) > { > case 1: do_stuff(); > > if(Option NOT enabled) > break; > > // * Intentional fall-through! > > case 2: optional_thing(); > break; > } On 4/11/07 9:42 AM, "Steven Lose" wrote: > Hi. > > Looks better. > But as Bengt says, I could use functions, would be much cleaner, but means > that I have to pass tons of local vars and I really don?t want that. > > Hmm?. I think it is clear enough for the reader to se what it is doing by > using your example. > > I?ll do that until someone gets a much brighter Idea. > Hopefully It won?t course me to many bruises. ;o) > > 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 mailto:bsl@ecpower.dk> > > > www.ecpower.dk > > > Fra: icc-avr-bounces@imagecraft.com [mailto:icc-avr-bounces@imagecraft.com] P? > vegne af Stephen Beaver > Sendt: 11. april 2007 14:33 > 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] Switch thing > > It might work, but it is very nasty. Reversing the logic makes it slightly > less horrible: > > > switch(status) > { > case 1: do_stuff(); > > if(Option NOT enabled) > break; > > case 2: optional_thing(); > break; > } > > > > > On 4/11/07 8:07 AM, "Steven Lose" wrote: > Hi. > > Is the following ok, or just bad coding? > If bad coding, how is it done the ?right way?? > > > Switch(status) > { > Case 1: do lot of stuff > If(Option enabled) > { > Case 2: Do optional thing > } > break > } > > 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 mailto:bsl@ecpower.dk> > > > www.ecpower.dk > > > > _______________________________________________ > Icc-avr mailing list > Icc-avr@imagecraft.com > http://dragonsgate.net/mailman/listinfo/icc-avr > > > > _______________________________________________ > Icc-avr mailing list > Icc-avr@imagecraft.com > http://dragonsgate.net/mailman/listinfo/icc-avr -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20070411/40dfe216/attachment-0001.html From sl at ecpower.dk Wed Apr 11 07:29:20 2007 From: sl at ecpower.dk (Steven Lose) Date: Wed Apr 11 07:38:06 2007 Subject: SV: [Icc-avr] Switch thing Message-ID: <072D96786BFC014AAEBA9EB07A8070EA1A54BC@seattle.ecpower.dk> Hi David. The meaning is that if you have case 2: only case 2 stuff is executed. If you have case 1: there is 2 possibilities, if Option is not set, only case 1 code is executed. But if option is set, both case 1 and case 2 stuff is executed. 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 David Brown Sendt: 11. april 2007 15:30 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] Switch thing Steven Lose wrote: > Hi. > > > > Is the following ok, or just bad coding? > It's bad coding. I don't know what the "right way" would be, since it is far from clear what you want to do. The sensible way to write switch statements is to consider each case as a separate block, and *always* include a "break". Thus you have: switch (status) { case 1 : { do stuff for case 1 break; }; case 2 : { do stuff for case 2 break; }; } It's not necessary to have the extra brackets for each case, but I prefer them as it keeps my indentation consistent (tab out after each "{", tab in before each "}"), and you can easily use local variables within each case block. The only exception is if you have several cases doing exactly the same thing: switch (key) { case 'A' : case 'a' : { ... break; }; } Just because C gives you more flexibility, does not mean that it is a good thing to use! mvh., David > If bad coding, how is it done the "right way"? > > > > > > *Switch*(status) > > { > > *Case 1*: do lot of stuff > > *If*(Option enabled) > > { > > *Case 2:* Do optional thing > > } > > break > > } > > > > 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 _______________________________________________ Icc-avr mailing list Icc-avr@imagecraft.com http://dragonsgate.net/mailman/listinfo/icc-avr From sl at ecpower.dk Wed Apr 11 07:52:11 2007 From: sl at ecpower.dk (Steven Lose) Date: Wed Apr 11 08:00:58 2007 Subject: SV: SV: [Icc-avr] Switch thing Message-ID: <072D96786BFC014AAEBA9EB07A8070EA1A54BF@seattle.ecpower.dk> Good Idea, thanks. Med venlig hilsen / Best regards / mit freundlichen Gr??en EC POWER A/S Steven Lose Software Ingeni?r Tlf.: +45 87434100 Direkte tlf. +45 58286608 Email: sl@ecpower.dk www.ecpower.dk ________________________________ Fra: icc-avr-bounces@imagecraft.com [mailto:icc-avr-bounces@imagecraft.com] P? vegne af Stephen Beaver Sendt: 11. april 2007 16:03 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: [Icc-avr] Switch thing You might also put in a comment such as shown below. That way, when someone runs Lint on it next year and it shows an error, they will know it is not really an error. - You did this deliberately. Steve switch(status) { case 1: do_stuff(); if(Option NOT enabled) break; // * Intentional fall-through! case 2: optional_thing(); break; } On 4/11/07 9:42 AM, "Steven Lose" wrote: Hi. Looks better. But as Bengt says, I could use functions, would be much cleaner, but means that I have to pass tons of local vars and I really don't want that. Hmm.... I think it is clear enough for the reader to se what it is doing by using your example. I'll do that until someone gets a much brighter Idea. Hopefully It won't course me to many bruises. ;o) Thanks. Med venlig hilsen / Best regards / mit freundlichen Gr??en EC POWER A/S Steven Lose Software Ingeni?r Tlf.: +45 87434100 Direkte tlf. +45 58286608 Email: sl@ecpower.dk www.ecpower.dk ________________________________ Fra: icc-avr-bounces@imagecraft.com [mailto:icc-avr-bounces@imagecraft.com] P? vegne af Stephen Beaver Sendt: 11. april 2007 14:33 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] Switch thing It might work, but it is very nasty. Reversing the logic makes it slightly less horrible: switch(status) { case 1: do_stuff(); if(Option NOT enabled) break; case 2: optional_thing(); break; } On 4/11/07 8:07 AM, "Steven Lose" wrote: Hi. Is the following ok, or just bad coding? If bad coding, how is it done the "right way"? Switch(status) { Case 1: do lot of stuff If(Option enabled) { Case 2: Do optional thing } break } 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 ________________________________ _______________________________________________ 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/20070411/284777cf/attachment.html From jh.bodin at telia.com Thu Apr 12 03:37:10 2007 From: jh.bodin at telia.com (Johan H. Bodin) Date: Thu Apr 12 03:45:48 2007 Subject: [Icc-avr] Jump table inside a C function? Message-ID: <461E0BD6.6080506@telia.com> Hi, I am writing an interrupt handler which has a state machine with a lot of states. Is there any alternative to the switch() statement? A big switch() can eat a lot of CPU cycles as it seems to use 16-bit comparisons even if the switch variable is a char :-(. I made a desperate attempt to make a jump table using IJMP with inline assembly but I wasn't able to make it work... Maybe mentioning PIC on this list is taboo but the PIC has a very efficient way of implementing jump tables. In C: ---------------------------------------- ... skip (charvar); // charvar = 0..N goto label0; goto label1; ... goto labelN; label0; goto exit; label1; goto exit; ... labelN; goto exit; exit: ... ---------------------------------------- On my wishlist is a similar jump table mechanism in ICCAVR when Project/Options/Compiler/Accept Extensions is checked... In my opinion, increasing code portability from 90% to 100% is not worth a 50% (or so) speed penalty ;-) Best Regards Johan Bodin Johan Bodin Elektronik AB Sweden From benra at imt.liu.se Thu Apr 12 04:31:08 2007 From: benra at imt.liu.se (Bengt Ragnemalm) Date: Thu Apr 12 04:39:11 2007 Subject: SV: [Icc-avr] Jump table inside a C function? In-Reply-To: <461E0BD6.6080506@telia.com> References: <461E0BD6.6080506@telia.com> Message-ID: <003601c77cf6$110e0900$b160ec82@Shagrat> Maybe this is one of the performance boosts you will get with the new 8 bit optimization with the PRO version? - Richard? Personally I can't understand why C requires 16 bit testing in a switch. But now it does and ICCAVR is special with having this 100% compability part from the static const -> FLASH. /Bengt > -----Ursprungligt meddelande----- > Fr?n: icc-avr-bounces@imagecraft.com [mailto:icc-avr- > bounces@imagecraft.com] F?r Johan H. Bodin > Skickat: den 12 april 2007 12:37 > Till: Icc-avr@imagecraft.com > ?mne: [Icc-avr] Jump table inside a C function? > > Hi, > > I am writing an interrupt handler which has a state machine > with a lot of states. > > Is there any alternative to the switch() statement? A big > switch() can eat a lot of CPU cycles as it seems to use > 16-bit comparisons even if the switch variable is a char :-(. > > I made a desperate attempt to make a jump table using IJMP > with inline assembly but I wasn't able to make it work... > > Maybe mentioning PIC on this list is taboo but the PIC has > a very efficient way of implementing jump tables. In C: > > ---------------------------------------- > ... > skip (charvar); // charvar = 0..N > goto label0; > goto label1; > ... > goto labelN; > > label0; > > goto exit; > > label1; > > goto exit; > > ... > > labelN; > > goto exit; > > exit: > ... > ---------------------------------------- > > On my wishlist is a similar jump table mechanism in ICCAVR when > Project/Options/Compiler/Accept Extensions is checked... > > In my opinion, increasing code portability from 90% to 100% is > not worth a 50% (or so) speed penalty ;-) > > > Best Regards > Johan Bodin > Johan Bodin Elektronik AB > > Sweden > > _______________________________________________ > Icc-avr mailing list > Icc-avr@imagecraft.com > http://dragonsgate.net/mailman/listinfo/icc-avr From muihlein at 3psinc.com Thu Apr 12 05:58:31 2007 From: muihlein at 3psinc.com (Mike Uihlein) Date: Thu Apr 12 06:12:57 2007 Subject: [Icc-avr] Jump table inside a C function? In-Reply-To: <461E0BD6.6080506@telia.com> Message-ID: <0D6EEAE152460C4688DA1CB4F55C26693D6AE1@3ps-server1.3ps.local> You might try using an... if() else if() else if() else() kind of statement. I believe I have seen that use 8 bit comparisons instead of 16 bit in the past. Just a thought. Mike Uihlein 3PS, Inc. 512-260-9570 x11 muihlein@3psinc.com -----Original Message----- From: icc-avr-bounces@imagecraft.com [mailto:icc-avr-bounces@imagecraft.com] On Behalf Of Johan H. Bodin Sent: Thursday, April 12, 2007 5:37 AM To: Icc-avr@imagecraft.com Subject: [Icc-avr] Jump table inside a C function? Hi, I am writing an interrupt handler which has a state machine with a lot of states. Is there any alternative to the switch() statement? A big switch() can eat a lot of CPU cycles as it seems to use 16-bit comparisons even if the switch variable is a char :-(. I made a desperate attempt to make a jump table using IJMP with inline assembly but I wasn't able to make it work... Maybe mentioning PIC on this list is taboo but the PIC has a very efficient way of implementing jump tables. In C: ---------------------------------------- ... skip (charvar); // charvar = 0..N goto label0; goto label1; ... goto labelN; label0; goto exit; label1; goto exit; ... labelN; goto exit; exit: ... ---------------------------------------- On my wishlist is a similar jump table mechanism in ICCAVR when Project/Options/Compiler/Accept Extensions is checked... In my opinion, increasing code portability from 90% to 100% is not worth a 50% (or so) speed penalty ;-) Best Regards Johan Bodin Johan Bodin Elektronik AB Sweden _______________________________________________ Icc-avr mailing list Icc-avr@imagecraft.com http://dragonsgate.net/mailman/listinfo/icc-avr From albert.vanveen at pertronic.co.nz Thu Apr 12 21:12:09 2007 From: albert.vanveen at pertronic.co.nz (Albert van Veen) Date: Thu Apr 12 21:21:03 2007 Subject: [Icc-avr] Jump table inside a C function? In-Reply-To: <461E0BD6.6080506@telia.com> Message-ID: Talking aother processors shouldn't be taboo; I agree that PIC's method in this kind of tables is really neat! Albert -----Original Message----- From: Johan H. Bodin [mailto:jh.bodin@telia.com] Sent: Thursday, 12 April 2007 10:37 p.m. To: Icc-avr@imagecraft.com Subject: [Icc-avr] Jump table inside a C function? Hi, I am writing an interrupt handler which has a state machine with a lot of states. Is there any alternative to the switch() statement? A big switch() can eat a lot of CPU cycles as it seems to use 16-bit comparisons even if the switch variable is a char :-(. I made a desperate attempt to make a jump table using IJMP with inline assembly but I wasn't able to make it work... Maybe mentioning PIC on this list is taboo but the PIC has a very efficient way of implementing jump tables. In C: ---------------------------------------- ... skip (charvar); // charvar = 0..N goto label0; goto label1; ... goto labelN; label0; goto exit; label1; goto exit; ... labelN; goto exit; exit: ... ---------------------------------------- On my wishlist is a similar jump table mechanism in ICCAVR when Project/Options/Compiler/Accept Extensions is checked... In my opinion, increasing code portability from 90% to 100% is not worth a 50% (or so) speed penalty ;-) Best Regards Johan Bodin Johan Bodin Elektronik AB Sweden _______________________________________________ Icc-avr mailing list Icc-avr@imagecraft.com http://dragonsgate.net/mailman/listinfo/icc-avr From benra at imt.liu.se Thu Apr 12 23:26:29 2007 From: benra at imt.liu.se (Bengt Ragnemalm) Date: Thu Apr 12 23:34:30 2007 Subject: SV: [Icc-avr] Jump table inside a C function? In-Reply-To: References: <461E0BD6.6080506@telia.com> Message-ID: <002601c77d94$abcdc6d0$b160ec82@Shagrat> I could not find "skip" in my book so the only special about this code is the skip statement, all the rest with goto and labels is standard C. The code will also not differ in any way from a switch with just the difference that the testing of the skip will be done using char instead of int. But have this PIC C-compilator included this special skip statement just for this purpose??? In my opinion it would have been much better to invent for example something like switch_char(char) and using the same syntax as normal. I guess this is just a special usage of skip. /Bengt > -----Ursprungligt meddelande----- > Fr?n: icc-avr-bounces@imagecraft.com [mailto:icc-avr- > bounces@imagecraft.com] F?r Albert van Veen > Skickat: den 13 april 2007 06:12 > Till: Discussion list for ICCAVR and ICCtiny Users. You do NOT > needtosubscribeto icc-announce if you are a member of this. > ?mne: RE: [Icc-avr] Jump table inside a C function? > > Talking aother processors shouldn't be taboo; I agree that PIC's method in > this kind of tables is really neat! > > Albert > > -----Original Message----- > From: Johan H. Bodin [mailto:jh.bodin@telia.com] > Sent: Thursday, 12 April 2007 10:37 p.m. > To: Icc-avr@imagecraft.com > Subject: [Icc-avr] Jump table inside a C function? > > > Hi, > > I am writing an interrupt handler which has a state machine > with a lot of states. > > Is there any alternative to the switch() statement? A big > switch() can eat a lot of CPU cycles as it seems to use > 16-bit comparisons even if the switch variable is a char :-(. > > I made a desperate attempt to make a jump table using IJMP > with inline assembly but I wasn't able to make it work... > > Maybe mentioning PIC on this list is taboo but the PIC has > a very efficient way of implementing jump tables. In C: > > ---------------------------------------- > ... > skip (charvar); // charvar = 0..N > goto label0; > goto label1; > ... > goto labelN; > > label0; > > goto exit; > > label1; > > goto exit; > > ... > > labelN; > > goto exit; > > exit: > ... > ---------------------------------------- > > On my wishlist is a similar jump table mechanism in ICCAVR when > Project/Options/Compiler/Accept Extensions is checked... > > In my opinion, increasing code portability from 90% to 100% is > not worth a 50% (or so) speed penalty ;-) > > > Best Regards > Johan Bodin > Johan Bodin Elektronik AB > > 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 david_brown at hotpop.com Fri Apr 13 00:49:35 2007 From: david_brown at hotpop.com (David Brown) Date: Fri Apr 13 00:37:36 2007 Subject: SV: [Icc-avr] Switch thing In-Reply-To: <072D96786BFC014AAEBA9EB07A8070EA1A54B7@seattle.ecpower.dk> References: <072D96786BFC014AAEBA9EB07A8070EA1A54B7@seattle.ecpower.dk> Message-ID: <461F360F.8030500@hotpop.com> Steven Lose wrote: > Hi. > > > > Looks better. > > But as Bengt says, I could use functions, would be much cleaner, but > means that I have to pass tons of local vars and I really don?t want that. > > If you don't want to use functions because of the number of parameters, and you don't want to duplicate code, another possibility is to use some local flags: bool doSomething = false; bool doSomethingElse = false; switch (...) { ... set "doSomething" or "doSomethingElse" as appropriate ... } if (doSomething) { ... } if (doSomethingElse) { ... } That separates the decision making from the actions, and may give you a better structure. If you have several such flags, then using a single "doFlags" byte combined with bitmasks will be particularly efficient on the AVR. mvh., David > > Hmm?. I think it is clear enough for the reader to se what it is doing > by using your example. > > > > I?ll do that until someone gets a much brighter Idea. > > Hopefully It won?t course me to many bruises. ;o) > > > > Thanks. > > Med venlig hilsen / Best regards / mit freundlichen Gr??en > > *EC POWER A/S* > > *Steven Lose* > > Software Ingeni?r > > Tlf.: +45 87434100 > > Direkte tlf. +45 58286608 > > Email: sl@ecpower.dk > > www.ecpower.dk > > ------------------------------------------------------------------------ > > *Fra:* icc-avr-bounces@imagecraft.com > [mailto:icc-avr-bounces@imagecraft.com] *P? vegne af *Stephen Beaver > *Sendt:* 11. april 2007 14:33 > *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] Switch thing > > > > It might work, but it is very nasty. Reversing the logic makes it > slightly less horrible: > > > switch(status) > { > case 1: do_stuff(); > > if(Option NOT enabled) > break; > > case 2: optional_thing(); > break; > } > > > > > On 4/11/07 8:07 AM, "Steven Lose" wrote: > > Hi. > > Is the following ok, or just bad coding? > If bad coding, how is it done the ?right way?? > > > *Switch*(status) > { > *Case 1*: do lot of stuff > *If*(Option enabled) > { > *Case 2:* Do optional thing > } > break > } > > 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 > From sl at ecpower.dk Fri Apr 13 00:45:13 2007 From: sl at ecpower.dk (Steven Lose) Date: Fri Apr 13 00:54:01 2007 Subject: SV: SV: [Icc-avr] Switch thing Message-ID: <072D96786BFC014AAEBA9EB07A8070EA1A5580@seattle.ecpower.dk> Hi David. Good Idea. Actually A method I use already in other switches, Didn't thing of it here, probably got blinded by the easiness of a fall though. 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 David Brown Sendt: 13. april 2007 09:50 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: [Icc-avr] Switch thing Steven Lose wrote: > Hi. > > > > Looks better. > > But as Bengt says, I could use functions, would be much cleaner, but > means that I have to pass tons of local vars and I really don't want that. > > If you don't want to use functions because of the number of parameters, and you don't want to duplicate code, another possibility is to use some local flags: bool doSomething = false; bool doSomethingElse = false; switch (...) { ... set "doSomething" or "doSomethingElse" as appropriate ... } if (doSomething) { ... } if (doSomethingElse) { ... } That separates the decision making from the actions, and may give you a better structure. If you have several such flags, then using a single "doFlags" byte combined with bitmasks will be particularly efficient on the AVR. mvh., David > > Hmm.... I think it is clear enough for the reader to se what it is doing > by using your example. > > > > I'll do that until someone gets a much brighter Idea. > > Hopefully It won't course me to many bruises. ;o) > > > > Thanks. > > Med venlig hilsen / Best regards / mit freundlichen Gr??en > > *EC POWER A/S* > > *Steven Lose* > > Software Ingeni?r > > Tlf.: +45 87434100 > > Direkte tlf. +45 58286608 > > Email: sl@ecpower.dk > > www.ecpower.dk > > ------------------------------------------------------------------------ > > *Fra:* icc-avr-bounces@imagecraft.com > [mailto:icc-avr-bounces@imagecraft.com] *P? vegne af *Stephen Beaver > *Sendt:* 11. april 2007 14:33 > *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] Switch thing > > > > It might work, but it is very nasty. Reversing the logic makes it > slightly less horrible: > > > switch(status) > { > case 1: do_stuff(); > > if(Option NOT enabled) > break; > > case 2: optional_thing(); > break; > } > > > > > On 4/11/07 8:07 AM, "Steven Lose" wrote: > > Hi. > > Is the following ok, or just bad coding? > If bad coding, how is it done the "right way"? > > > *Switch*(status) > { > *Case 1*: do lot of stuff > *If*(Option enabled) > { > *Case 2:* Do optional thing > } > break > } > > 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 From jh.bodin at telia.com Fri Apr 13 03:55:04 2007 From: jh.bodin at telia.com (Johan H. Bodin) Date: Fri Apr 13 04:03:42 2007 Subject: SV: [Icc-avr] Jump table inside a C function? In-Reply-To: <002601c77d94$abcdc6d0$b160ec82@Shagrat> References: <461E0BD6.6080506@telia.com> <002601c77d94$abcdc6d0$b160ec82@Shagrat> Message-ID: <461F6188.7010907@telia.com> Yes, the C compiler I use has a special skip statement. In its simplest form, it uses the fact that a value can be added to the program counter (works within any 256 code word boundary). Asm: ; here register W is loaded with jump offset, 0..N ... addwf PCL,f ; add 0..N to PC ("skip") so that the goto label0 ; next instruction executed will be goto label1 ; one of the gotos ... goto labelN The AVR cannot do this but is possible to use the IJMP instruction to do something similar. When/if such a "non-standard" mechanism is included in the C compiler, it will be possible to write very efficient code without using assembly language... The idea is to avoid multiple comparisons when the "switch variable" is known to be a contigous range of numbers. AVR: ; The table jumptable: rjmp label0 rjmp label1 ... rjmp labelN ; The jumping code: ... load Z with address of jumptable add "switch variable" to Z, (using carry for MSByte!) IJMP ; jump to selected line in the jump table ; The jump destinations: label0: ... label1: ... labelN: Bengt Ragnemalm skrev: > I could not find "skip" in my book so the only special about this code is > the skip statement, all the rest with goto and labels is standard C. The > code will also not differ in any way from a switch with just the difference > that the testing of the skip will be done using char instead of int. > > But have this PIC C-compilator included this special skip statement just for > this purpose??? In my opinion it would have been much better to invent for > example something like switch_char(char) and using the same syntax as > normal. I guess this is just a special usage of skip. > > /Bengt From t.jaspers at cpseurope.com Fri Apr 13 06:34:14 2007 From: t.jaspers at cpseurope.com (Jaspers, Ton) Date: Fri Apr 13 06:43:01 2007 Subject: [Icc-avr] Jump table inside a C function? Message-ID: <7B0EB27CF1CC93439B5CFB7526E5D74C3BFEAF@mickey.PBNV.local> Is this fast enough? Typedef unsigned char uchar; Typedef unsigned short int ushort; Void function_one(ushort cntr) { ... } Void function_two(ushort cntr) { ... } Void function_three(ushort cntr) { ... } Void function_four(ushort cntr) { ... } Void interrupt_service(uchar state) { static const void(*func[])(ushort) = { function_one, function_two, function_three, function_four } static ushort counter = 0 ; If ( state < 4 ) func[state](counter++) ; /* call function */ } Cheers, Ton Jaspers > -----Original Message----- > From: icc-avr-bounces@imagecraft.com > [mailto:icc-avr-bounces@imagecraft.com] On Behalf Of Johan H. Bodin > Sent: donderdag 12 april 2007 12:37 > To: Icc-avr@imagecraft.com > Subject: [Icc-avr] Jump table inside a C function? > > Hi, > > I am writing an interrupt handler which has a state machine > with a lot of states. > > Is there any alternative to the switch() statement? A big > switch() can eat a lot of CPU cycles as it seems to use > 16-bit comparisons even if the switch variable is a char :-(. > > I made a desperate attempt to make a jump table using IJMP > with inline assembly but I wasn't able to make it work... > > Maybe mentioning PIC on this list is taboo but the PIC has a > very efficient way of implementing jump tables. In C: > > ---------------------------------------- > ... > skip (charvar); // charvar = 0..N > goto label0; > goto label1; > ... > goto labelN; > > label0; > > goto exit; > > label1; > > goto exit; > > ... > > labelN; > > goto exit; > > exit: > ... > ---------------------------------------- > > On my wishlist is a similar jump table mechanism in ICCAVR > when Project/Options/Compiler/Accept Extensions is checked... > > In my opinion, increasing code portability from 90% to 100% > is not worth a 50% (or so) speed penalty ;-) > > > Best Regards > Johan Bodin > Johan Bodin Elektronik AB > > Sweden > > _______________________________________________ > Icc-avr mailing list > Icc-avr@imagecraft.com > http://dragonsgate.net/mailman/listinfo/icc-avr > From richard-lists at imagecraft.com Fri Apr 13 12:48:05 2007 From: richard-lists at imagecraft.com (Richard) Date: Fri Apr 13 12:57:07 2007 Subject: SV: [Icc-avr] Jump table inside a C function? In-Reply-To: <461F6188.7010907@telia.com> References: <461E0BD6.6080506@telia.com> <002601c77d94$abcdc6d0$b160ec82@Shagrat> <461F6188.7010907@telia.com> Message-ID: <6.1.0.6.2.20070413124457.078fba70@192.168.100.42> The ICC compilers DO use jump table, but only case 12 or so more, due to the overhead of fetching from the program memory. Actually, Jodan's post made me realize that we can generate shorter code sequence for the jump table. Currently, the jump table stores only the program addresses and not "rjmp address" Changing it will reduce the tradeoff point. Unfortunately, this will screw up the code compressor so the changes must be done with care. The 8 bit optimization will generate byte comparison for 8 bit switch variable if the case values fit. At 03:55 AM 4/13/2007, Johan H. Bodin wrote: >Yes, the C compiler I use has a special skip statement. >In its simplest form, it uses the fact that a value can >be added to the program counter (works within any 256 >code word boundary). Asm: > > ; here register W is loaded with jump offset, 0..N > ... > addwf PCL,f ; add 0..N to PC ("skip") so that the > goto label0 ; next instruction executed will be > goto label1 ; one of the gotos > ... > goto labelN > >The AVR cannot do this but is possible to use the IJMP >instruction to do something similar. When/if such a >"non-standard" mechanism is included in the C compiler, >it will be possible to write very efficient code without >using assembly language... > >The idea is to avoid multiple comparisons when the >"switch variable" is known to be a contigous range >of numbers. > >AVR: > >; The table > >jumptable: > rjmp label0 > rjmp label1 > ... > rjmp labelN > >; The jumping code: > > ... > load Z with address of jumptable > add "switch variable" to Z, (using carry for MSByte!) > IJMP ; jump to selected line in the jump table > >; The jump destinations: > >label0: > ... >label1: > ... >labelN: > > > >Bengt Ragnemalm skrev: >>I could not find "skip" in my book so the only special about this code is >>the skip statement, all the rest with goto and labels is standard C. The >>code will also not differ in any way from a switch with just the difference >>that the testing of the skip will be done using char instead of int. >>But have this PIC C-compilator included this special skip statement just for >>this purpose??? In my opinion it would have been much better to invent for >>example something like switch_char(char) and using the same syntax as >>normal. I guess this is just a special usage of skip. >>/Bengt > >_______________________________________________ >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 edwards.john.c at gmail.com Fri Apr 13 17:58:27 2007 From: edwards.john.c at gmail.com (John Edwards) Date: Fri Apr 13 20:50:01 2007 Subject: SV: [Icc-avr] Jump table inside a C function? In-Reply-To: <6.1.0.6.2.20070413124457.078fba70@192.168.100.42> References: <461E0BD6.6080506@telia.com> <002601c77d94$abcdc6d0$b160ec82@Shagrat> <461F6188.7010907@telia.com> <6.1.0.6.2.20070413124457.078fba70@192.168.100.42> Message-ID: <494d49270704131758i61fe6d7cv2d840c4fd669cdb9@mail.gmail.com> Ok, so we started off with "switch statements are inefficient - what else could I use" and have ended up with Richard giving us a current and future solution that keeps SWITCH. So if SWITCH is ok, you should know about Protothreads which manipulate code threading using the switch statement and avoids layers of enumerated states. http://www.sics.se/~adam/pt/ Very cool, very elegant, very useful. On 4/13/07, Richard wrote: > > The ICC compilers DO use jump table, but only case 12 or so more, due to > the overhead of fetching from the program memory. > > Actually, Jodan's post made me realize that we can generate shorter code > sequence for the jump table. Currently, the jump table stores only the > program addresses and not "rjmp address" Changing it will reduce the > tradeoff point. Unfortunately, this will screw up the code compressor so > the changes must be done with care. > > The 8 bit optimization will generate byte comparison for 8 bit switch > variable if the case values fit. > > At 03:55 AM 4/13/2007, Johan H. Bodin wrote: > >Yes, the C compiler I use has a special skip statement. > >In its simplest form, it uses the fact that a value can > >be added to the program counter (works within any 256 > >code word boundary). Asm: > > > > ; here register W is loaded with jump offset, 0..N > > ... > > addwf PCL,f ; add 0..N to PC ("skip") so that the > > goto label0 ; next instruction executed will be > > goto label1 ; one of the gotos > > ... > > goto labelN > > > >The AVR cannot do this but is possible to use the IJMP > >instruction to do something similar. When/if such a > >"non-standard" mechanism is included in the C compiler, > >it will be possible to write very efficient code without > >using assembly language... > > > >The idea is to avoid multiple comparisons when the > >"switch variable" is known to be a contigous range > >of numbers. > > > >AVR: > > > >; The table > > > >jumptable: > > rjmp label0 > > rjmp label1 > > ... > > rjmp labelN > > > >; The jumping code: > > > > ... > > load Z with address of jumptable > > add "switch variable" to Z, (using carry for MSByte!) > > IJMP ; jump to selected line in the jump table > > > >; The jump destinations: > > > >label0: > > ... > >label1: > > ... > >labelN: > > > > > > > >Bengt Ragnemalm skrev: > >>I could not find "skip" in my book so the only special about this code > is > >>the skip statement, all the rest with goto and labels is standard C. The > >>code will also not differ in any way from a switch with just the > difference > >>that the testing of the skip will be done using char instead of int. > >>But have this PIC C-compilator included this special skip statement just > for > >>this purpose??? In my opinion it would have been much better to invent > for > >>example something like switch_char(char) and using the same syntax as > >>normal. I guess this is just a special usage of skip. > >>/Bengt > > > >_______________________________________________ > >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 > -- John C. Edwards -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20070413/1c1a357e/attachment.html From rnd-iccavr2 at rnd.se Mon Apr 16 03:33:10 2007 From: rnd-iccavr2 at rnd.se (Magnus Johansson) Date: Mon Apr 16 03:43:17 2007 Subject: [Icc-avr] csscanf() Message-ID: <462350E6.80700@rnd.se> Hi! (7.11) What is the current status of csscanf()? It's mentioned in the help-file but is not in stdio.h... From j_baraclough at zetnet.co.uk Mon Apr 16 07:38:02 2007 From: j_baraclough at zetnet.co.uk (John Baraclough) Date: Mon Apr 16 07:46:38 2007 Subject: [Icc-avr] csscanf() In-Reply-To: <462350E6.80700@rnd.se> References: <462350E6.80700@rnd.se> Message-ID: Hi Magnus, Bob asked the same question just a couple of weeks ago. It isn't in the library, however you will find the C source in: \iccv7avr\libsrc.avr\libsrc.zip. The file is password protected and you can find the password under the Help->Show Library Source Code Password drop-down menu. You will also need to extract the source for '_scanf.c' and include both files in your project. HTH. All the best for now, John At 11:33 16/04/2007, you wrote: >Hi! > >(7.11) What is the current status of csscanf()? It's mentioned in >the help-file but is not in stdio.h... > >_______________________________________________ >Icc-avr mailing list >Icc-avr@imagecraft.com >http://dragonsgate.net/mailman/listinfo/icc-avr > From bobgardner at aol.com Mon Apr 16 07:41:25 2007 From: bobgardner at aol.com (bobgardner@aol.com) Date: Mon Apr 16 07:50:27 2007 Subject: [Icc-avr] csscanf() In-Reply-To: <462350E6.80700@rnd.se> References: <462350E6.80700@rnd.se> Message-ID: <8C94E4C71F995FA-3BC-A31@WEBMAIL-RA08.sysops.aol.com> I think just copy the csscanf.c from the libsrc dir to your dir, add it to proj -----Original Message----- From: rnd-iccavr2@rnd.se Sent: Mon, 16 Apr 2007 6:33 AM Subject: [Icc-avr] csscanf() Hi! (7.11) What is the current status of csscanf()? It's mentioned in the help-file but is not in stdio.h... _______________________________________________ Icc-avr mailing list Icc-avr@imagecraft.com http://dragonsgate.net/mailman/listinfo/icc-avr ________________________________________________________________________ AOL now offers free email to everyone. Find out more about what's free from AOL at AOL.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20070416/22406bdf/attachment.html From jgeiger at intuitivecontrols.com Mon Apr 16 09:58:49 2007 From: jgeiger at intuitivecontrols.com (Jason Geiger) Date: Mon Apr 16 10:07:39 2007 Subject: [Icc-avr] Spontanious RAM problems Message-ID: Greetings, I am having a problem with an ATMEGA128 which I am a little unsure how to debug and I was hoping to get some basic ideas as to where to start. Any and all suggestions are welcome and appreciated! I have a few timing/counting variables that are spontaneously changing from their value of 0 to something that is non-zero. I have a TimeKeeper (ISR) routine counting those variables back down to zero. In Main() I act on them, usually when their value is equal to 1 - then I set them to zero until I need to get to them. I believe this is pretty standard fare for keeping track of timing. What could be causing these variables to spontaneously change from zero? Perhaps I am abusing ICC somehow. Some notes and considerations. - I do boundary checking with any arrays - especially noting that some of these are RX and TX data packets. - I use a LOT of structures. Some people seem to think this is great for organization. Others argue that it's awful for code efficiency. - My Software and Hardware stack seem to be much bigger than I need, based on some quick calculations and verified by that handy stack checker that I got from one of you on here. (Sylvain?) - Related; I do not have nested interrupts. - 5 volt circuit - Brown out fuse is enabled and set at 4 volts. Could this be hardware? Power supply issues? How do I know these are happening spontaneously? Most of the timer variables that I am noticing this problem are set exclusively by from incoming data packets and they are being set when I have the circuit detached from anything else. They are also variables that are more recently. I could be happening to others, but I have not noticed that yet. Void Main() { If (Time2.DoSomething == 1) { DoSomething(); // like set and LED pin high PORTB = 0x01; //Uh oh, this LED is on now, nothing else can cause that! Time2.DoSomething = 0; } } Void TimeKeeperISR() { if (Time2.DoSomething > 1) Time2.DoSomething--; } Thoughts? Ideas? Thank you ahead of time, Jason Geiger -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20070416/739859e6/attachment-0001.html From rnd-iccavr2 at rnd.se Mon Apr 16 10:16:13 2007 From: rnd-iccavr2 at rnd.se (Magnus Johansson) Date: Mon Apr 16 10:25:39 2007 Subject: [Icc-avr] csscanf() In-Reply-To: References: <462350E6.80700@rnd.se> Message-ID: <4623AF5D.7040003@rnd.se> > Bob asked the same question just a couple of weeks ago. It isn't in the > library, however you will find the C source in: That I didn't find, Bob asked the same thing back in 2004, that Google did find. So I thought I'd ask again. > You will also need to extract the source for '_scanf.c' and include both > files in your project. I tried including csscanf.c as Richards follow-up to the 2004-message said, but I got a const error for the _scanf()-call in csscanf... Trying to use sscanf() was even weirder, that got me the putchar() error...? From richard-lists at imagecraft.com Mon Apr 16 12:20:41 2007 From: richard-lists at imagecraft.com (Richard) Date: Mon Apr 16 12:30:18 2007 Subject: [Icc-avr] Spontanious RAM problems In-Reply-To: References: Message-ID: <6.1.0.6.2.20070416121422.078a6e08@192.168.100.42> At 09:58 AM 4/16/2007, Jason Geiger wrote: >Greetings, > >I am having a problem with an ATMEGA128 which I am a little unsure how to >debug and I was hoping to get some basic ideas as to where to start. Any >and all suggestions are welcome and appreciated! > >I have a few timing/counting variables that are spontaneously changing >from their value of 0 to something that is non-zero. I have a TimeKeeper >(ISR) routine counting those variables back down to zero. In Main() I act >on them, usually when their value is equal to 1 - then I set them to zero >until I need to get to them. I believe this is pretty standard fare for >keeping track of timing. > >What could be causing these variables to spontaneously change from >zero? Perhaps I am abusing ICC somehow. Almost certainly some sort of memory overwrite or boundary race conditions. >Some notes and considerations. > > - I do boundary checking with any arrays ? especially noting that some > of these are RX and TX data packets. > > - I use a LOT of structures. Some people seem to think this is great > for organization. Others argue that it?s awful for code efficiency. Structures should not cause code efficiency problem, EXCEPT if you actually pass it back and forth in function call (i.e. not pass the pointer to a structure, but the struct itself) >- My Software and Hardware stack seem to be much bigger than I need, based >on some quick calculations and verified by that handy stack checker that I >got from one of you on here. (Sylvain?) Probably Johannes' tools. The HW stack rarely has to be bigger than ~40 bytes. Have you used the Stack Checking functions? > - Related; I do not have nested interrupts. > >- 5 volt circuit ? Brown out fuse is enabled and set at 4 volts. Could >this be hardware? Power supply issues? I have heard from customers power supply and watchdog timers causing problems that take forever to figure out. >How do I know these are happening spontaneously? Most of the timer >variables that I am noticing this problem are set exclusively by from >incoming data packets and they are being set when I have the circuit >detached from anything else. They are also variables that are more >recently. I could be happening to others, but I have not noticed that yet. IMPORTANT!!!! Is "DoSomething" larger than 8 bits, if so, then you need to be careful how it is modified and accessed by the main program and the ISRs. The compiler does not disable interrupt when accessing multi-byte variables or any memory that requires more than one instruction to access, so if the main program is modifying a variable only partially and then get interrupted, the results can be chaos! >Void Main() > >{ > > If (Time2.DoSomething == 1) > >{ > > DoSomething(); // like set and LED pin high > PORTB = 0x01; //Uh oh, this LED is on now, nothing else > can cause that! > > Time2.DoSomething = 0; > >} > >} > >Void TimeKeeperISR() > >{ > >if (Time2.DoSomething > 1) Time2.DoSomething--; > >} > > >Thoughts? Ideas? Thank you ahead of time, > >Jason Geiger > >_______________________________________________ >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 Mon Apr 16 15:06:26 2007 From: j_baraclough at zetnet.co.uk (John Baraclough) Date: Mon Apr 16 15:15:08 2007 Subject: [Icc-avr] csscanf() In-Reply-To: <4623AF5D.7040003@rnd.se> References: <462350E6.80700@rnd.se> <4623AF5D.7040003@rnd.se> Message-ID: Hi Magnus, At 18:16 16/04/2007, you wrote: >>Bob asked the same question just a couple of weeks ago. It isn't in >>the library, however you will find the C source in: > >That I didn't find, Bob asked the same thing back in 2004, that Google >did find. So I thought I'd ask again. It was only on April 4th, so probably hasn't made it to the archives yet. >>You will also need to extract the source for '_scanf.c' and include >>both files in your project. > >I tried including csscanf.c as Richards follow-up to the 2004-message >said, but I got a const error for the _scanf()-call in csscanf... >Trying to use sscanf() was even weirder, that got me the putchar() error...? Since this is the second time this month that this question has been raised, I think it's time to get both 'cscanf()' and 'csscanf()' built into the library and 'stdio.h'. >_______________________________________________ >Icc-avr mailing list >Icc-avr@imagecraft.com >http://dragonsgate.net/mailman/listinfo/icc-avr > From richard at imagecraft.com Mon Apr 16 19:07:57 2007 From: richard at imagecraft.com (Richard) Date: Mon Apr 16 19:17:32 2007 Subject: [Icc-avr] 7.13 Beta 1 Message-ID: <6.1.0.6.2.20070416190653.078ce520@192.168.100.42> http://www.imagecraft.com/pub/iccv7avr_v713_beta1.exe Still TBD: add cscanf and csscanf V7.13 - Vista compatible licensing engine - Make the toolchain compatible with large projects (e.g. over 700+ source files etc.) IDE/Compiler - [PRO version only] Added "8 bit optimization." Most if not all expressions that can be done legally per Standard C rules should be done with 8 bit operations instead of the promoted int type. Should improve most programs by one to two percent and more if 8 bit variables are used extensively. This is enabled if you turn on Project->Options->Compiler->"Global Optimizations" Compiler - Fixed a bug where the compiler was generating code that save/restore R20..R23 inside an ISR even if the "Do not use R20..R23" switch is on. Header Files - USB AVR header files update // 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 johan at edab.nu Tue Apr 17 00:09:55 2007 From: johan at edab.nu (=?iso-8859-1?Q?Johan_Wallstr=F6m?=) Date: Tue Apr 17 00:18:15 2007 Subject: [Icc-avr] Spontanious RAM problems / Timers References: Message-ID: <003601c780bf$66f79940$64026e0a@EDAB1> Spontanious RAM problemsI don't have an answer to your question, but I thought I'd show you my way of doing timers. It's based on only having one value that is actually being incremented, and the "timer" variables just keep track on where they were reset. (this code is not protected for interrupted 16 bit access, but that should be easy to add if needed) -------------- timer.h -------------- typedef struct TimerT { int startTime; } Timer; void Delay(int time); char CheckTimer(Timer *timer, int time)M void ResetTimer(Timer *timer); long GetTimer(Timer *timer); void DecreaseTimer(Timer *timer, int value); extern int msecTimer; -------------- timer.c -------------- int msecTimer; void ResetTimer(Timer *timer) { timer->startTime = msecTimer; } long GetTimer(Timer *timer) { return msecTimer - timer->startTime; } void DecreaseTimer(Timer *timer, int value) { timer->startTime += value; } char CheckTimer(Timer *timer, int time) { if(GetTimer(timer) > time) { ResetTimer(timer); return true; } return false; } char CheckTimerOverflow(Timer *timer) { if(msecTimer - timer->startTime > 61000) { timer->startTime = msecTimer - 61000; return true; } return false; } void Delay(int time) { Timer timeout; ResetTimer(&timeout); while(GetTimer(&timeout) 1000) { ResetTimer(&timer1); foo1(); } // call foo2 every second if(CheckTimer(&timer2, 1000)) { foo2(); } // call foo3 on every program run during one second after an event if(someCondition) ResetTimer(&timer3); CheckTimerOverflow(&timer3); if(GetTimer(&timer3) < 1000) { foo3(); } // sometimes you'll need to know how much time actually passed temp = GetTimer(&timer4); if(temp > 1000) { DecreaseTimer(&timer4, temp); derivative = (inputSingal - lastInputSignal) / temp; } } } ----- Original Message ----- From: Jason Geiger To: Discussion list for ICCAVR and ICCtiny Users. You do NOT needtosubscribeto icc-announce if you are a member of this. Sent: Monday, April 16, 2007 6:58 PM Subject: [Icc-avr] Spontanious RAM problems Greetings, I am having a problem with an ATMEGA128 which I am a little unsure how to debug and I was hoping to get some basic ideas as to where to start. Any and all suggestions are welcome and appreciated! I have a few timing/counting variables that are spontaneously changing from their value of 0 to something that is non-zero. I have a TimeKeeper (ISR) routine counting those variables back down to zero. In Main() I act on them, usually when their value is equal to 1 - then I set them to zero until I need to get to them. I believe this is pretty standard fare for keeping track of timing. What could be causing these variables to spontaneously change from zero? Perhaps I am abusing ICC somehow. Some notes and considerations. - I do boundary checking with any arrays - especially noting that some of these are RX and TX data packets. - I use a LOT of structures. Some people seem to think this is great for organization. Others argue that it's awful for code efficiency. - My Software and Hardware stack seem to be much bigger than I need, based on some quick calculations and verified by that handy stack checker that I got from one of you on here. (Sylvain?) - Related; I do not have nested interrupts. - 5 volt circuit - Brown out fuse is enabled and set at 4 volts. Could this be hardware? Power supply issues? How do I know these are happening spontaneously? Most of the timer variables that I am noticing this problem are set exclusively by from incoming data packets and they are being set when I have the circuit detached from anything else. They are also variables that are more recently. I could be happening to others, but I have not noticed that yet. Void Main() { If (Time2.DoSomething == 1) { DoSomething(); // like set and LED pin high PORTB = 0x01; //Uh oh, this LED is on now, nothing else can cause that! Time2.DoSomething = 0; } } Void TimeKeeperISR() { if (Time2.DoSomething > 1) Time2.DoSomething--; } Thoughts? Ideas? Thank you ahead of time, Jason Geiger ------------------------------------------------------------------------------ _______________________________________________ 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/20070417/9ab0a998/attachment-0001.html From benra at imt.liu.se Thu Apr 19 01:42:14 2007 From: benra at imt.liu.se (Bengt Ragnemalm) Date: Thu Apr 19 01:50:11 2007 Subject: [Icc-avr] Bitfields versus byte variables Message-ID: <00c301c7825e$a11bd140$b160ec82@Shagrat> Hi. I have a lot of settings that I must save to configure the system. I not played so much with bitfields but I understand that ICCAVR can be very effective using bitfields and that a test of a bit may be better than testing a byte value. Is this correct? Anything else about this subject? A very typical setting that I have a lot of is to specify the port and port pin of an output signal. For example a chip select. Best regards, 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/20070419/d49cdddd/attachment.html From j_baraclough at zetnet.co.uk Thu Apr 19 03:24:46 2007 From: j_baraclough at zetnet.co.uk (John Baraclough) Date: Thu Apr 19 03:33:30 2007 Subject: [Icc-avr] Bitfields versus byte variables In-Reply-To: <00c301c7825e$a11bd140$b160ec82@Shagrat> References: <00c301c7825e$a11bd140$b160ec82@Shagrat> Message-ID: My preference is to use macros to define flags. Then you can control exactly what happens. Here's some examples: // Interrupt flags #define TEST_MSG_FLAG gucInterruptFlags&BIT(0) #define SET_MSG_FLAG gucInterruptFlags|=BIT(0) #define CLEAR_MSG_FLAG gucInterruptFlags&=~BIT(0) #define TEST_NOT_MSG_FLAG ~(gucInterruptFlags)&BIT(0) #define TEST_HEATER_RUNNING_FLAG gucInterruptFlags&BIT(1) #define SET_HEATER_RUNNING_FLAG gucInterruptFlags|=BIT(1) #define CLEAR_HEATER_RUNNING_FLAG gucInterruptFlags&=~BIT(1) #define TEST_HEATER_ON_FLAG gucInterruptFlags&BIT(2) #define SET_HEATER_ON_FLAG gucInterruptFlags|=BIT(2) #define CLEAR_HEATER_ON_FLAG gucInterruptFlags&=~BIT(2) // Flow control flags. #define TEST_SCREEN_FLAG gucFlags&BIT(0) #define SET_SCREEN_FLAG gucFlags|=BIT(0) #define CLEAR_SCREEN_FLAG gucFlags&=~BIT(0) #define TEST_RUN_FLAG gucFlags&BIT(1) #define SET_RUN_FLAG gucFlags|=BIT(1) #define CLEAR_RUN_FLAG gucFlags&=~BIT(1) #define TEST_SEND_FLAG gucFlags&BIT(2) #define SET_SEND_FLAG gucFlags|=BIT(2) #define CLEAR_SEND_FLAG gucFlags&=~BIT(2) #define TEST_CHANGE_FLAG gucFlags&BIT(3) #define SET_CHANGE_FLAG gucFlags|=BIT(3) #define CLEAR_CHANGE_FLAG gucFlags&=~BIT(3) #define TEST_UPDATE_FLAG gucFlags&BIT(4) #define SET_UPDATE_FLAG gucFlags|=BIT(4) #define CLEAR_UPDATE_FLAG gucFlags&=~BIT(4) #define TEST_RUN_SCREEN_FLAG gucFlags&BIT(5) #define SET_RUN_SCREEN_FLAG gucFlags|=BIT(5) #define CLEAR_RUN_SCREEN_FLAG gucFlags&=~BIT(5) The appropriate global variables are define elsewhere. All the best for now, John At 09:42 19/04/2007, you wrote: >Hi. > >I have a lot of settings that I must save to >configure the system. I not played so much with >bitfields but I understand that ICCAVR can be >very effective using bitfields and that a test >of a bit may be better than testing a byte >value. Is this correct? Anything else about this subject? > >A very typical setting that I have a lot of is >to specify the port and port pin of an output >signal. For example a chip select. > >Best regards, >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 -----------