From t.jaspers at cpseurope.com Tue Jun 2 01:09:58 2009 From: t.jaspers at cpseurope.com (Jaspers, Ton) Date: Tue Jun 2 02:19:04 2009 Subject: [Icc-avr] modem In-Reply-To: Message-ID: <7B0EB27CF1CC93439B5CFB7526E5D74C85757A@mickey.PBNV.local> Single chip is posible but not at 56k. 1200 BPS FSK or less can easily be made using AVR's PWM timer or DA converter. I used it to transfer a five digit counter value once an hour. Cheers, Ton > -----Original Message----- > From: icc-avr-bounces@imagecraft.com > [mailto:icc-avr-bounces@imagecraft.com] On Behalf Of A. R. Khorasani > Sent: donderdag 28 mei 2009 22:23 > To: icc-avr@imagecraft.com > Subject: Re: [Icc-avr] modem > > Dear Johannes > > Thanks for your post. > I wish it was single chip solution. > > Regards > A.R.Khorasani > http://www.instrumentalanalysis.com > > On Tue, May 26, 2009 at 11:39 PM, Johannes Assenbaum > wrote: > > Silicon Labs Si2457 56k chipset is available as "G grade" > spec'd for -40 to +85 oC. > > > > (https://www.silabs.com/Support > > Documents/TechnicalDocs/si2457-34-15.pdf) > > > > Best regards, > > Johannes > > > > > >> Hello, > > > >> Thanks all > >> unfortunately these solutions do not meet industrial standard > >> temperature range (-20 to +80 oC) > > > >> Regards > >> A.R.Khorasani > >> http://www.instrumentalanalysis.com > > > >> On 5/20/09, Byron Loader wrote: > >>> Hey, > >>> > >>> Try https://www.silabs.com/Pages/default.aspx > >>> > >>> They have a range of modem ics and daa's for your line interface. > >>> > >>> As a starting point, I would look at what your market is. A > >>> significant percentage of countries require type > approvals in order > >>> for you to connect electronic equipment to a phone line and > >>> requirements vary from country to country. > >>> > >>> Good Luck :) > >>> > >>> > >>> Byron Loader > >>> Senior Electronic Engineer > >>> Inhep Electronics Holdings (pty) ltd > >>> Email: byron@inhep.com > >>> Tel: +27 31 7051373 > >>> Fax: +27 31 7054445 > >>> > >>> -----Original Message----- > >>> From: icc-avr-bounces@imagecraft.com > >>> [mailto:icc-avr-bounces@imagecraft.com] > >>> On Behalf Of A. R. Khorasani > >>> Sent: Tuesday, May 19, 2009 5:15 PM > >>> To: icc-avr@imagecraft.com > >>> Subject: [Icc-avr] modem > >>> > >>> Hello, > >>> > >>> I will be appreciated with your suggestion and comment > regarding a > >>> "single chip solution" for data transmission over the analogue > >>> telephone line at 56K. > >>> > >>> Best Regards > >>> A. R. Khorasani > >>> www.instrumentalanalysis.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 > >>> > >> _______________________________________________ > >> Icc-avr mailing list > >> Icc-avr@imagecraft.com > >> http://dragonsgate.net/mailman/listinfo/icc-avr > > > > _______________________________________________ > > Icc-avr mailing list > > Icc-avr@imagecraft.com > > http://dragonsgate.net/mailman/listinfo/icc-avr > > > _______________________________________________ > Icc-avr mailing list > Icc-avr@imagecraft.com > http://dragonsgate.net/mailman/listinfo/icc-avr > From a.r.khorasani at gmail.com Tue Jun 2 10:01:06 2009 From: a.r.khorasani at gmail.com (A. R. Khorasani) Date: Tue Jun 2 11:10:00 2009 Subject: [Icc-avr] modem In-Reply-To: <7B0EB27CF1CC93439B5CFB7526E5D74C85757A@mickey.PBNV.local> References: <7B0EB27CF1CC93439B5CFB7526E5D74C85757A@mickey.PBNV.local> Message-ID: if you mean 1200 bps with only avr, please provide me with transmitter & receiver telephone line side, circuit schematic. Regards, Abolfazl On Tue, Jun 2, 2009 at 11:39 AM, Jaspers, Ton wrote: > Single chip is posible but not at 56k. > 1200 BPS FSK or less can easily be made using AVR's PWM timer or DA > converter. > I used it to transfer a five digit counter value once an hour. > > Cheers, > Ton > > >> -----Original Message----- >> From: icc-avr-bounces@imagecraft.com >> [mailto:icc-avr-bounces@imagecraft.com] On Behalf Of A. R. Khorasani >> Sent: donderdag 28 mei 2009 22:23 >> To: icc-avr@imagecraft.com >> Subject: Re: [Icc-avr] modem >> >> Dear Johannes >> >> Thanks for your post. >> I wish it was single chip solution. >> >> Regards >> A.R.Khorasani >> http://www.instrumentalanalysis.com >> >> On Tue, May 26, 2009 at 11:39 PM, Johannes Assenbaum >> wrote: >> > Silicon Labs Si2457 56k chipset is available as "G grade" >> spec'd for -40 to +85 oC. >> > >> > (https://www.silabs.com/Support >> > Documents/TechnicalDocs/si2457-34-15.pdf) >> > >> > Best regards, >> > Johannes >> > >> > >> >> Hello, >> > >> >> Thanks all >> >> unfortunately these solutions do not meet industrial standard >> >> temperature range (-20 to +80 oC) >> > >> >> Regards >> >> A.R.Khorasani >> >> http://www.instrumentalanalysis.com >> > >> >> On 5/20/09, Byron Loader wrote: >> >>> Hey, >> >>> >> >>> Try https://www.silabs.com/Pages/default.aspx >> >>> >> >>> They have a range of modem ics and daa's for your line interface. >> >>> >> >>> As a starting point, I would look at what your market is. A >> >>> significant percentage of countries require type >> approvals in order >> >>> for you to connect electronic equipment to a phone line and >> >>> requirements vary from country to country. >> >>> >> >>> Good Luck :) >> >>> >> >>> >> >>> Byron Loader >> >>> Senior Electronic Engineer >> >>> Inhep Electronics Holdings (pty) ltd >> >>> Email: byron@inhep.com >> >>> Tel: +27 31 7051373 >> >>> Fax: +27 31 7054445 >> >>> >> >>> -----Original Message----- >> >>> From: icc-avr-bounces@imagecraft.com >> >>> [mailto:icc-avr-bounces@imagecraft.com] >> >>> On Behalf Of A. R. Khorasani >> >>> Sent: Tuesday, May 19, 2009 5:15 PM >> >>> To: icc-avr@imagecraft.com >> >>> Subject: [Icc-avr] modem >> >>> >> >>> Hello, >> >>> >> >>> I will be appreciated with your suggestion and comment >> regarding a >> >>> "single chip solution" for data transmission over the analogue >> >>> telephone line at 56K. >> >>> >> >>> Best Regards >> >>> A. R. Khorasani >> >>> www.instrumentalanalysis.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 >> >>> >> >> _______________________________________________ >> >> Icc-avr mailing list >> >> Icc-avr@imagecraft.com >> >> http://dragonsgate.net/mailman/listinfo/icc-avr >> > >> > _______________________________________________ >> > Icc-avr mailing list >> > Icc-avr@imagecraft.com >> > http://dragonsgate.net/mailman/listinfo/icc-avr >> > >> _______________________________________________ >> Icc-avr mailing list >> Icc-avr@imagecraft.com >> http://dragonsgate.net/mailman/listinfo/icc-avr >> > _______________________________________________ > Icc-avr mailing list > Icc-avr@imagecraft.com > http://dragonsgate.net/mailman/listinfo/icc-avr > From j_baraclough at zetnet.co.uk Tue Jun 2 10:32:30 2009 From: j_baraclough at zetnet.co.uk (John Baraclough) Date: Tue Jun 2 11:41:37 2009 Subject: [Icc-avr] modem In-Reply-To: References: <7B0EB27CF1CC93439B5CFB7526E5D74C85757A@mickey.PBNV.local> Message-ID: <4A25622E.40402@zetnet.co.uk> This is going very off-topic for this mailing list. Besides which, designing your own product is what your company gets paid for, isn't it? A. R. Khorasani wrote: > if you mean 1200 bps with only avr, please provide me with transmitter > & receiver telephone line side, circuit schematic. > > Regards, > Abolfazl > > From tony at encoreelectronics.com Tue Jun 2 16:08:22 2009 From: tony at encoreelectronics.com (Tony Karavidas) Date: Tue Jun 2 17:17:35 2009 Subject: [Icc-avr] modem In-Reply-To: <4A25622E.40402@zetnet.co.uk> References: <7B0EB27CF1CC93439B5CFB7526E5D74C85757A@mickey.PBNV.local> <4A25622E.40402@zetnet.co.uk> Message-ID: Really! Tony Sent from my iphone On Jun 2, 2009, at 10:32 AM, John Baraclough wrote: > This is going very off-topic for this mailing list. Besides which, > designing your own product is what your company gets paid for, isn't > it? > > > A. R. Khorasani wrote: >> if you mean 1200 bps with only avr, please provide me with >> transmitter >> & receiver telephone line side, circuit schematic. >> >> Regards, >> Abolfazl >> >> > > _______________________________________________ > Icc-avr mailing list > Icc-avr@imagecraft.com > http://dragonsgate.net/mailman/listinfo/icc-avr From tim at sabretechnology.co.uk Fri Jun 5 01:31:38 2009 From: tim at sabretechnology.co.uk (Tim Mitchell) Date: Fri Jun 5 03:40:42 2009 Subject: [Icc-avr] Using a c integer variable in assembler function Message-ID: <04671BB8D269034BBC4BB6BA89486726164F7E@sserver.SabreTechnology.local> I'm trying to write an assembler function which reads a global integer variable from the c code (i.e. it's not passed as a parameter). I can't work out how to specify the high and low bytes of the integer. If it was a char I would just use: mov R16,_GlobalCharVariable Can I just use: movw R30,_GlobalIntVariable to get it into zh:zl? -- Tim Mitchell From tim at sabretechnology.co.uk Fri Jun 5 01:39:46 2009 From: tim at sabretechnology.co.uk (Tim Mitchell) Date: Fri Jun 5 03:40:47 2009 Subject: [Icc-avr] FW: Using a c integer variable in assembler function Message-ID: <04671BB8D269034BBC4BB6BA89486726164F81@sserver.SabreTechnology.local> Doh, not thinking For a char it would of course be: lds R16,_GlobalCharVariable Is it: lds R30,<_GlobalIntVariable lds R31,>_GlobalIntVariable The help says you can only use the "+" operator with external symbols. -- Tim Mitchell tim@sabretechnology.co.uk http://www.sabretechnology.co.uk Sabre Technology (Hull) Ltd, 3a Newlands Science Park, Hull HU6 7TQ Registered in England and Wales no.3131504 t:01482 801003 f:01482 801078 From tim at sabretechnology.co.uk Fri Jun 5 03:53:19 2009 From: tim at sabretechnology.co.uk (Tim Mitchell) Date: Fri Jun 5 05:02:22 2009 Subject: [Icc-avr] Interrupt routine in assembler Message-ID: <04671BB8D269034BBC4BB6BA89486726164F87@sserver.SabreTechnology.local> OK, the answer to my previous question was of course lds R30,_GlobalIntVariable lds R31,_GlobalIntVariable+1 Next problem... I am trying to provide an interrupt routine in assembler (for speed). I have followed the instructions in the help regarding setting up the vector myself, but it crashes horribly, and when I check the listfile, my assembler interrupt routine is not in it (though another assembler routine is). Has it been optimised away because it isn't called from anywhere? (I do not have any compression or optimisation enabled). It is definitely being compiled because I can cause errors to appear in the build by putting an invalid opcode in. -- Tim Mitchell From richard-lists at imagecraft.com Fri Jun 5 13:06:43 2009 From: richard-lists at imagecraft.com (Richard Man) Date: Fri Jun 5 14:15:54 2009 Subject: [Icc-avr] Interrupt routine in assembler In-Reply-To: <04671BB8D269034BBC4BB6BA89486726164F87@sserver.SabreTechno logy.local> References: <04671BB8D269034BBC4BB6BA89486726164F87@sserver.SabreTechnology.local> Message-ID: <200906052115.n55LFskO018668@mail.imagecraft.com> At 03:53 AM 6/5/2009, Tim Mitchell wrote: >Next problem... I am trying to provide an interrupt routine in assembler >(for speed). > >I have followed the instructions in the help regarding setting up the >vector myself, but it crashes horribly, and when I check the listfile, >my assembler interrupt routine is not in it (though another assembler >routine is). Tim, It shouldn't be optimized away. Can you zip up your project and email it to me off-list? Thanks. Also, what version of the IDE are you using? Help->About tells. // richard From jassenbaum at htp-tel.de Fri Jun 5 13:11:18 2009 From: jassenbaum at htp-tel.de (Johannes Assenbaum) Date: Fri Jun 5 14:20:19 2009 Subject: [Icc-avr] Interrupt routine in assembler References: <04671BB8D269034BBC4BB6BA89486726164F87@sserver.SabreTechnology.local> Message-ID: AFAIK no asm code is optimised away, even if not used. This only may happen to unused C code. How did you set up the vector? Are you sure, it's correct for your target device? As help is not quite up to date regarding rjmp/jmp, the most safe way to define the vector is by either asm set_vector macro or C #pragma interrupt_vector. The difference is, that for asm macro the underscore at the beginning of isr name may be omitted and that isr name not necessarily must be defined global, if isr is in same file as set_vector macro. On the other hand, with vector defined in asm, it does not appear in C code, and if not global (single colon after isr name), it's not listed in map file. So, for best C readability, I prefer the #pragma, e.g. in C file: #pragma interrupt_handler tim1_capt_isr: iv_TIMER1_CAPT // isr see asm file xyz.s and in asm file: _tim1_capt_isr:: st -Y,r16 ; save r16 in r16,SREG st -Y,r16 ; save SREG and have r16 free for isr ... ld r16,Y+ ; restore SREG out SREG,r16 ld r16,Y+ ; restore r16 reti BTW: If isr uses CBI/SBI and SBIC/SBIS only, you don't even need to save SREG nor any register. Best regards, Johannes > OK, the answer to my previous question was of course > lds R30,_GlobalIntVariable > lds R31,_GlobalIntVariable+1 > Next problem... I am trying to provide an interrupt routine in assembler > (for speed). > I have followed the instructions in the help regarding setting up the > vector myself, but it crashes horribly, and when I check the listfile, > my assembler interrupt routine is not in it (though another assembler > routine is). > Has it been optimised away because it isn't called from anywhere? (I do > not have any compression or optimisation enabled). It is definitely > being compiled because I can cause errors to appear in the build by > putting an invalid opcode in. > -- > Tim Mitchell > _______________________________________________ > Icc-avr mailing list > Icc-avr@imagecraft.com > http://dragonsgate.net/mailman/listinfo/icc-avr From karl at lautman.com Sat Jun 6 14:46:52 2009 From: karl at lautman.com (Karl Lautman) Date: Sat Jun 6 15:55:52 2009 Subject: [Icc-avr] Trouble installing ICC-AVR Studio plug-in Message-ID: <200906062255.n56MtnVl036059@mail.imagecraft.com> I have ICC 7.16A (Std) and AVR Studio 4.16, both of which run fine. When I try to install the ICC-AVR Studio plug-in I get a warning that my security key "does not appear to be valid" for my version of the "program" (presumably ICC). I mentioned this to Richard and he's investigating, but I thought I'd check here to see if anyone else has encountered this problem, and how they fixed it. Karl From j_baraclough at zetnet.co.uk Sat Jun 6 15:37:31 2009 From: j_baraclough at zetnet.co.uk (John Baraclough) Date: Sat Jun 6 16:46:33 2009 Subject: [Icc-avr] Trouble installing ICC-AVR Studio plug-in In-Reply-To: <200906062255.n56MtnVl036059@mail.imagecraft.com> References: <200906062255.n56MtnVl036059@mail.imagecraft.com> Message-ID: <4A2AEFAB.6050302@zetnet.co.uk> Hi Karl, I've got ICCAVR version 7.18 with an ADV dongle and it works fine with Studio 4.16. What kind of licence do you have? All the best for now, John Karl Lautman wrote: > I have ICC 7.16A (Std) and AVR Studio 4.16, both of which run fine. When I > try to install the ICC-AVR Studio plug-in I get a warning that my security > key "does not appear to be valid" for my version of the "program" > (presumably ICC). I mentioned this to Richard and he's investigating, but I > thought I'd check here to see if anyone else has encountered this problem, > and how they fixed it. > > Karl > > _______________________________________________ > Icc-avr mailing list > Icc-avr@imagecraft.com > http://dragonsgate.net/mailman/listinfo/icc-avr > > > From karl at lautman.com Sat Jun 6 15:53:50 2009 From: karl at lautman.com (Karl Lautman) Date: Sat Jun 6 17:03:01 2009 Subject: [Icc-avr] Trouble installing ICC-AVR Studio plug-in In-Reply-To: <4A2AEFAB.6050302@zetnet.co.uk> Message-ID: <200906070002.n5702wgO036704@mail.imagecraft.com> Hi, John. I have a standard, no-dongle version. Karl ----------------------------------------------------- Karl Lautman 1052 Clark Ave. Mountain View, CA 94040 T: 650-941-2395 F: 650-941-9012 karl@lautman.com www.karllautman.com > -----Original Message----- > From: icc-avr-bounces@imagecraft.com [mailto:icc-avr- > bounces@imagecraft.com] On Behalf Of John Baraclough > Sent: Saturday, June 06, 2009 3:38 PM > To: Discussion list for ICCAVR and ICCtiny Users. You do NOT need > tosubscribe to icc-announce if you are a member of this. > Subject: Re: [Icc-avr] Trouble installing ICC-AVR Studio plug-in > > Hi Karl, > > I've got ICCAVR version 7.18 with an ADV dongle and it works fine with > Studio 4.16. What kind of licence do you have? > > All the best for now, > John > > > Karl Lautman wrote: > > I have ICC 7.16A (Std) and AVR Studio 4.16, both of which run fine. > When I > > try to install the ICC-AVR Studio plug-in I get a warning that my > security > > key "does not appear to be valid" for my version of the "program" > > (presumably ICC). I mentioned this to Richard and he's investigating, > but I > > thought I'd check here to see if anyone else has encountered this > problem, > > and how they fixed it. > > > > Karl > > > > _______________________________________________ > > 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 Albert.vanVeen at pertronic.co.nz Sun Jun 7 13:09:57 2009 From: Albert.vanVeen at pertronic.co.nz (Albert vanVeen) Date: Sun Jun 7 14:18:59 2009 Subject: [Icc-avr] Interrupt routine in assembler In-Reply-To: <04671BB8D269034BBC4BB6BA89486726164F87@sserver.SabreTechnology.local> References: <04671BB8D269034BBC4BB6BA89486726164F87@sserver.SabreTechnology.local> Message-ID: <5F8515C5ED67B6439B4F93D7B5E08A36063F66@sbs.pertronic.local> Why don't you just include the interrupt routine in a c module, and put your assembly code in there? No worries about external or global potential confusion. That's what I've 'always' done without any problem, ... Although nowadays the compiler is so good, it's hardly ever necessary to improve on speed. Albert. -----Original Message----- From: icc-avr-bounces@imagecraft.com [mailto:icc-avr-bounces@imagecraft.com] On Behalf Of Tim Mitchell Sent: Friday, June 05, 2009 10:53 PM To: Discussion list for ICCAVR and ICCtiny Users. You do NOT needtosubscribeto icc-announce if you are a member of this. Subject: [Icc-avr] Interrupt routine in assembler OK, the answer to my previous question was of course lds R30,_GlobalIntVariable lds R31,_GlobalIntVariable+1 Next problem... I am trying to provide an interrupt routine in assembler (for speed). I have followed the instructions in the help regarding setting up the vector myself, but it crashes horribly, and when I check the listfile, my assembler interrupt routine is not in it (though another assembler routine is). Has it been optimised away because it isn't called from anywhere? (I do not have any compression or optimisation enabled). It is definitely being compiled because I can cause errors to appear in the build by putting an invalid opcode in. -- Tim Mitchell _______________________________________________ Icc-avr mailing list Icc-avr@imagecraft.com http://dragonsgate.net/mailman/listinfo/icc-avr -- This message has been scanned for viruses and dangerous content by Bizo EmailFilter, and is believed to be clean. From tim at sabretechnology.co.uk Mon Jun 8 01:20:00 2009 From: tim at sabretechnology.co.uk (Tim Mitchell) Date: Mon Jun 8 02:29:08 2009 Subject: [Icc-avr] Interrupt routine in assembler Message-ID: <04671BB8D269034BBC4BB6BA89486726164FA4@sserver.SabreTechnology.local> ----Original Message---- From: icc-avr-bounces@imagecraft.com [mailto:icc-avr-bounces@imagecraft.com] On Behalf Of Albert vanVeen Sent: 07 June 2009 21:10 To: Discussion list for ICCAVR and ICCtiny Users. You do NOT needtosubscribeto icc-announce if you are a member of this. Subject: RE: [Icc-avr] Interrupt routine in assembler > Why don't you just include the interrupt routine in a c > module, and put your assembly code in there? > No worries about external or global potential confusion. > That's what I've 'always' done without any problem, ... > Although nowadays the compiler is so good, it's hardly > ever necessary to improve on speed. It's a short interrupt routine, but the compiler is using a lot of different registers (for reasons I can't quite work out) so there's lots of pushes and pops. Using asm allows me to get rid of these too. To Johannes, there may well be errors with the vector or even in my asm, but the confusion for me is that the list file apparently did not contain my asm routine. However it turns out that the routine is there, but the label I gave it is not in the list file, and that's how I was searching for it. Thanks for the useful info about the vector macros. -- Tim Mitchell From sl at ecpower.dk Fri Jun 12 03:39:44 2009 From: sl at ecpower.dk (Steven Lose) Date: Fri Jun 12 04:48:53 2009 Subject: [Icc-avr] Funtion pointer question Message-ID: <072D96786BFC014AAEBA9EB07A8070EA61281F@seattle.ecpower.dk> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 2650 bytes Desc: image001.jpg Url : http://dragonsgate.net/pipermail/icc-avr/attachments/20090612/4299c0b2/attachment.jpe From pragnesh68 at yahoo.com Fri Jun 12 05:28:16 2009 From: pragnesh68 at yahoo.com (pragnesh patel) Date: Fri Jun 12 06:37:23 2009 Subject: [Icc-avr] Funtion pointer question Message-ID: <7658.743.qm@web52003.mail.re2.yahoo.com> You may be exceeding in time when calling function by pointer. As when you call by pointer, compiler has no idea which function is called, so it try to save and restore all registers. But when you call fix function, it save only those registers used within the new called function. Try increasing your timer tick. Pragnesh --- On Fri, 6/12/09, Steven Lose wrote: From: Steven Lose Subject: [Icc-avr] Funtion pointer question To: "Discussion list for ICCAVR and ICCtiny Users. You do NOT need tosubscribeto icc-announce if you are a member of this." Date: Friday, June 12, 2009, 4:09 PM Hi. ? I have a function pointer issue that I need help to understand. ICCAVR 7.21A PRO ATMEGA2561 ? I have a scheduler that calls functions by pointers stored in an array. ? typedef void(*FP)(void); typedef struct { ????????????????FP Fp; ????????????????unsigned char TaskCheck; ????????????????unsigned char TaskTimeCheck; ????????????????unsigned long TaskCheckTime; ????????????????unsigned char TaskMasterEnable; ?????????????? }cTask_T; __flash cTask_T Fpoint[NrOfTask] = {?..}; ?<- at adr 0x47CF ? The tasks is then called in a scheduler function like this: ? _Schedule: ? uci????????????????? --> R10 ??? 0FD93 920A????? ST?????????? -Y,R0 ??? 0FD94 921A????? ST?????????? -Y,R1 ??? 0FD95 922A????? ST?????????? -Y,R2 ??? 0FD96 923A????? ST?????????? -Y,R3 ??? 0FD97 924A????? ST?????????? -Y,R4 ??? 0FD98 925A????? ST?????????? -Y,R5 ??? 0FD99 926A????? ST?????????? -Y,R6 ??? 0FD9A 927A????? ST?????????? -Y,R7 ??? 0FD9B 928A????? ST?????????? -Y,R8 ??? 0FD9C 929A????? ST?????????? -Y,R9 ??? 0FD9D 930A????? ST?????????? -Y,R16 ??? 0FD9E 931A????? ST?????????? -Y,R17 ??? 0FD9F 932A????? ST?????????? -Y,R18 ??? 0FDA0 933A????? ST?????????? -Y,R19 ??? 0FDA1 938A????? ST?????????? -Y,R24 ??? 0FDA2 939A????? ST?????????? -Y,R25 ??? 0FDA3 93AA????? ST?????????? -Y,R26 ??? 0FDA4 93BA????? ST?????????? -Y,R27 ??? 0FDA5 93EA????? ST?????????? -Y,R30 ??? 0FDA6 93FA????? ST?????????? -Y,R31 ??? 0FDA7 B60F????? IN?????????? R0,0x3F ??? 0FDA8 920A????? ST?????????? -Y,R0 ??? 0FDA9 940F 3456 CALL???????? push_xgsetF00C ??? 0FDAB 9724????? SBIW???????? R28,4 ?. ?. ? ? (0202)?? Fpoint[uci].Fp(); ??? 0FE3D E089????? LDI????????? R24,0x9 ??<- size of cTask_T ??? 0FE3E 9D8A????? MUL????????? R24,R10 ??<- uci ??? 0FE3F EC8F????? LDI????????? R24,0xCF ?<- low Adr of Fpoint ??? 0FE40 E497????? LDI????????? R25,0x47? <- Hi Adr of Fpoint ??? 0FE41 01F0????? MOVW???????? R30,R0 ???<- R0 = 0x3F, don?t know what it is ??? 0FE42 0FE8????? ADD????????? R30,R24 ??? 0FE43 1FF9????? ADC????????? R31,R25 ??? 0FE44 9007????? ELPM???????? R0,Z+ ??? 0FE45 9016????? ELPM???????? R1,Z ??? 0FE46 01F0????? MOVW???????? R30,R0 ??? 0FE47 940F 348E CALL???????? exicall I have experienced some crashes, and have stripped my code down to the point where the only interrupt is the scheduler, and only on? call is carried out from the scheduler. (KeyPad) ? If I substitute the call by pointer with a call to function, then the problem disappears. Like: //Fpoint[uci].Fp(); ????<- removed ?(0203)?? GetKeyPad();? <- direct call. 0FE3D 940E 7D2C CALL? _GetKeyPad I can se that exicall is used which uses 3bytes, but I can not se where the third is stored, only 2 bytes is stored in the array? ? ? 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 ? ? -----Inline Attachment Follows----- _______________________________________________ Icc-avr mailing list Icc-avr@imagecraft.com http://dragonsgate.net/mailman/listinfo/icc-avr -------------- next part -------------- Skipped content of type multipart/related From sl at ecpower.dk Fri Jun 12 05:41:59 2009 From: sl at ecpower.dk (Steven Lose) Date: Fri Jun 12 06:51:10 2009 Subject: SV: [Icc-avr] Funtion pointer question In-Reply-To: <7658.743.qm@web52003.mail.re2.yahoo.com> References: <7658.743.qm@web52003.mail.re2.yahoo.com> Message-ID: <072D96786BFC014AAEBA9EB07A8070EA61284E@seattle.ecpower.dk> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 2650 bytes Desc: image001.jpg Url : http://dragonsgate.net/pipermail/icc-avr/attachments/20090612/647fb850/attachment-0002.jpe -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 2650 bytes Desc: image002.jpg Url : http://dragonsgate.net/pipermail/icc-avr/attachments/20090612/647fb850/attachment-0003.jpe From t.jaspers at cpseurope.com Fri Jun 12 06:12:20 2009 From: t.jaspers at cpseurope.com (Jaspers, Ton) Date: Fri Jun 12 07:21:27 2009 Subject: [Icc-avr] Funtion pointer question In-Reply-To: <072D96786BFC014AAEBA9EB07A8070EA61284E@seattle.ecpower.dk> Message-ID: <7B0EB27CF1CC93439B5CFB7526E5D74C857B78@mickey.PBNV.local> Do it in C and the problem does not exist. I have made a several real time OS-es without a single line of assembly. Code from a good C programmer is as efficient as assembly. You only need to be aware of how a compiler works. Even a big OS like Linux has no assembly code. The ojnly time I look assembly code is when there is a need to modify the C-startup code. (Tweak vector tables and such). Why do things simple if there is a hard way? Cheers, Ton > -----Original Message----- > From: icc-avr-bounces@imagecraft.com > [mailto:icc-avr-bounces@imagecraft.com] On Behalf Of Steven Lose > Sent: vrijdag 12 juni 2009 14:42 > To: Discussion list for ICCAVR and ICCtiny Users. You do NOT > need tosubscribeto icc-announce if you are a member of this. > Subject: SV: [Icc-avr] Funtion pointer question > > So, you are saying that if function A, is calling function B, > then function A is doing the push to stack before calling > function B. instead of B doing it itself? > > > > > > 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 pragnesh patel > Sendt: 12. juni 2009 14:28 > Til: Discussion list for ICCAVR and ICCtiny Users. You do NOT > need tosubscribe to icc-announce if you are a member of this. > Emne: Re: [Icc-avr] Funtion pointer question > > > > You may be exceeding in time when calling function by > pointer. As when you call by pointer, compiler has no idea > which function is called, so it try to save and restore all > registers. But when you call fix function, it save only those > registers used within the new called function. > > Try increasing your timer tick. > > Pragnesh > > --- On Fri, 6/12/09, Steven Lose wrote: > > > From: Steven Lose > Subject: [Icc-avr] Funtion pointer question > To: "Discussion list for ICCAVR and ICCtiny Users. You do NOT > need tosubscribeto icc-announce if you are a member of this." > > Date: Friday, June 12, 2009, 4:09 PM > > Hi. > > > > I have a function pointer issue that I need help to understand. > > ICCAVR 7.21A PRO > > ATMEGA2561 > > > > I have a scheduler that calls functions by pointers stored in > an array. > > > > typedef void(*FP)(void); > > typedef struct { > > FP Fp; > > unsigned char TaskCheck; > > unsigned char TaskTimeCheck; > > unsigned long TaskCheckTime; > > unsigned char TaskMasterEnable; > > }cTask_T; > > __flash cTask_T Fpoint[NrOfTask] = {.....}; <- at adr 0x47CF > > > > The tasks is then called in a scheduler function like this: > > > > _Schedule: > uci --> R10 > 0FD93 920A ST -Y,R0 > 0FD94 921A ST -Y,R1 > 0FD95 922A ST -Y,R2 > 0FD96 923A ST -Y,R3 > 0FD97 924A ST -Y,R4 > 0FD98 925A ST -Y,R5 > 0FD99 926A ST -Y,R6 > 0FD9A 927A ST -Y,R7 > 0FD9B 928A ST -Y,R8 > 0FD9C 929A ST -Y,R9 > 0FD9D 930A ST -Y,R16 > 0FD9E 931A ST -Y,R17 > 0FD9F 932A ST -Y,R18 > 0FDA0 933A ST -Y,R19 > 0FDA1 938A ST -Y,R24 > 0FDA2 939A ST -Y,R25 > 0FDA3 93AA ST -Y,R26 > 0FDA4 93BA ST -Y,R27 > 0FDA5 93EA ST -Y,R30 > 0FDA6 93FA ST -Y,R31 > 0FDA7 B60F IN R0,0x3F > 0FDA8 920A ST -Y,R0 > 0FDA9 940F 3456 CALL push_xgsetF00C > 0FDAB 9724 SBIW R28,4 > > .... > > .... > > > > > > (0202) Fpoint[uci].Fp(); > 0FE3D E089 LDI R24,0x9 <- size of cTask_T > 0FE3E 9D8A MUL R24,R10 <- uci > 0FE3F EC8F LDI R24,0xCF <- low Adr of Fpoint > 0FE40 E497 LDI R25,0x47 <- Hi Adr of Fpoint > 0FE41 01F0 MOVW R30,R0 <- R0 = 0x3F, > don't know what it is > 0FE42 0FE8 ADD R30,R24 > 0FE43 1FF9 ADC R31,R25 > 0FE44 9007 ELPM R0,Z+ > 0FE45 9016 ELPM R1,Z > 0FE46 01F0 MOVW R30,R0 > 0FE47 940F 348E CALL exicall > > I have experienced some crashes, and have stripped my code > down to the point where the only interrupt is the scheduler, > and only on? call is carried out from the scheduler. (KeyPad) > > > > If I substitute the call by pointer with a call to function, > then the problem disappears. > > Like: > > //Fpoint[uci].Fp(); <- removed > > (0203) GetKeyPad(); <- direct call. > 0FE3D 940E 7D2C CALL _GetKeyPad > > I can se that exicall is used which uses 3bytes, but I can > not se where the third is stored, only 2 bytes is stored in the array? > > > > > > 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 > > > > > > > -----Inline Attachment Follows----- > > _______________________________________________ > Icc-avr mailing list > Icc-avr@imagecraft.com > http://dragonsgate.net/mailman/listinfo/icc-avr > > > > > From sl at ecpower.dk Fri Jun 12 06:59:22 2009 From: sl at ecpower.dk (Steven Lose) Date: Fri Jun 12 08:08:30 2009 Subject: SV: [Icc-avr] Funtion pointer question In-Reply-To: <7B0EB27CF1CC93439B5CFB7526E5D74C857B78@mickey.PBNV.local> References: <072D96786BFC014AAEBA9EB07A8070EA61284E@seattle.ecpower.dk> <7B0EB27CF1CC93439B5CFB7526E5D74C857B78@mickey.PBNV.local> Message-ID: <072D96786BFC014AAEBA9EB07A8070EA612859@seattle.ecpower.dk> Ton, There is only C. The asm is a snip from the list file. 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 Jaspers, Ton Sendt: 12. juni 2009 15:12 Til: Discussion list for ICCAVR and ICCtiny Users. You do NOT need to subscribeto icc-announce if you are a member of this. Emne: RE: [Icc-avr] Funtion pointer question Do it in C and the problem does not exist. I have made a several real time OS-es without a single line of assembly. Code from a good C programmer is as efficient as assembly. You only need to be aware of how a compiler works. Even a big OS like Linux has no assembly code. The ojnly time I look assembly code is when there is a need to modify the C-startup code. (Tweak vector tables and such). Why do things simple if there is a hard way? Cheers, Ton > -----Original Message----- > From: icc-avr-bounces@imagecraft.com > [mailto:icc-avr-bounces@imagecraft.com] On Behalf Of Steven Lose > Sent: vrijdag 12 juni 2009 14:42 > To: Discussion list for ICCAVR and ICCtiny Users. You do NOT > need tosubscribeto icc-announce if you are a member of this. > Subject: SV: [Icc-avr] Funtion pointer question > > So, you are saying that if function A, is calling function B, > then function A is doing the push to stack before calling > function B. instead of B doing it itself? > > > > > > 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 pragnesh patel > Sendt: 12. juni 2009 14:28 > Til: Discussion list for ICCAVR and ICCtiny Users. You do NOT > need tosubscribe to icc-announce if you are a member of this. > Emne: Re: [Icc-avr] Funtion pointer question > > > > You may be exceeding in time when calling function by > pointer. As when you call by pointer, compiler has no idea > which function is called, so it try to save and restore all > registers. But when you call fix function, it save only those > registers used within the new called function. > > Try increasing your timer tick. > > Pragnesh > > --- On Fri, 6/12/09, Steven Lose wrote: > > > From: Steven Lose > Subject: [Icc-avr] Funtion pointer question > To: "Discussion list for ICCAVR and ICCtiny Users. You do NOT > need tosubscribeto icc-announce if you are a member of this." > > Date: Friday, June 12, 2009, 4:09 PM > > Hi. > > > > I have a function pointer issue that I need help to understand. > > ICCAVR 7.21A PRO > > ATMEGA2561 > > > > I have a scheduler that calls functions by pointers stored in > an array. > > > > typedef void(*FP)(void); > > typedef struct { > > FP Fp; > > unsigned char TaskCheck; > > unsigned char TaskTimeCheck; > > unsigned long TaskCheckTime; > > unsigned char TaskMasterEnable; > > }cTask_T; > > __flash cTask_T Fpoint[NrOfTask] = {.....}; <- at adr 0x47CF > > > > The tasks is then called in a scheduler function like this: > > > > _Schedule: > uci --> R10 > 0FD93 920A ST -Y,R0 > 0FD94 921A ST -Y,R1 > 0FD95 922A ST -Y,R2 > 0FD96 923A ST -Y,R3 > 0FD97 924A ST -Y,R4 > 0FD98 925A ST -Y,R5 > 0FD99 926A ST -Y,R6 > 0FD9A 927A ST -Y,R7 > 0FD9B 928A ST -Y,R8 > 0FD9C 929A ST -Y,R9 > 0FD9D 930A ST -Y,R16 > 0FD9E 931A ST -Y,R17 > 0FD9F 932A ST -Y,R18 > 0FDA0 933A ST -Y,R19 > 0FDA1 938A ST -Y,R24 > 0FDA2 939A ST -Y,R25 > 0FDA3 93AA ST -Y,R26 > 0FDA4 93BA ST -Y,R27 > 0FDA5 93EA ST -Y,R30 > 0FDA6 93FA ST -Y,R31 > 0FDA7 B60F IN R0,0x3F > 0FDA8 920A ST -Y,R0 > 0FDA9 940F 3456 CALL push_xgsetF00C > 0FDAB 9724 SBIW R28,4 > > .... > > .... > > > > > > (0202) Fpoint[uci].Fp(); > 0FE3D E089 LDI R24,0x9 <- size of cTask_T > 0FE3E 9D8A MUL R24,R10 <- uci > 0FE3F EC8F LDI R24,0xCF <- low Adr of Fpoint > 0FE40 E497 LDI R25,0x47 <- Hi Adr of Fpoint > 0FE41 01F0 MOVW R30,R0 <- R0 = 0x3F, > don't know what it is > 0FE42 0FE8 ADD R30,R24 > 0FE43 1FF9 ADC R31,R25 > 0FE44 9007 ELPM R0,Z+ > 0FE45 9016 ELPM R1,Z > 0FE46 01F0 MOVW R30,R0 > 0FE47 940F 348E CALL exicall > > I have experienced some crashes, and have stripped my code > down to the point where the only interrupt is the scheduler, > and only on? call is carried out from the scheduler. (KeyPad) > > > > If I substitute the call by pointer with a call to function, > then the problem disappears. > > Like: > > //Fpoint[uci].Fp(); <- removed > > (0203) GetKeyPad(); <- direct call. > 0FE3D 940E 7D2C CALL _GetKeyPad > > I can se that exicall is used which uses 3bytes, but I can > not se where the third is stored, only 2 bytes is stored in the array? > > > > > > 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 > > > > > > > -----Inline Attachment Follows----- > > _______________________________________________ > 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 danar at astrixnet.com Fri Jun 12 07:55:28 2009 From: danar at astrixnet.com (Dana Raymond) Date: Fri Jun 12 09:04:19 2009 Subject: [Icc-avr] Funtion pointer question In-Reply-To: <200906121338.n5CDc49l043985@mail.imagecraft.com> References: <200906121338.n5CDc49l043985@mail.imagecraft.com> Message-ID: Firstly, the registers are stored on the software stack within the called function, not at the calling point, so there should be no additional overhead by using function pointers, other than the indirection itself. Secondly, The ATM 256X series uses a function pointer table located below main(). The 16bit address you speak of is the address of the location of a full address of the function, allowing the function to reside anywhere within the full program memory space. Thirdly, if you happen to be using uC/OS-II as your scheduler you should be aware that a new ATM256 port is soon to be available that allows the entire program memory space to contain tasks. The new port fixes problems with first starting a task if located in the upper 128KB of program memory only. I Hope This Helps. DFR Astrix Networks Inc. -----Original Message----- From: icc-avr-bounces@imagecraft.com [mailto:icc-avr-bounces@imagecraft.com] On Behalf Of icc-avr-request@imagecraft.com Sent: June 12, 2009 9:38 AM To: icc-avr@imagecraft.com Subject: Icc-avr Digest, Vol 59, Issue 7 Send Icc-avr mailing list submissions to icc-avr@imagecraft.com To subscribe or unsubscribe via the World Wide Web, visit http://dragonsgate.net/mailman/listinfo/icc-avr or, via email, send a message with subject or body 'help' to icc-avr-request@imagecraft.com You can reach the person managing the list at icc-avr-owner@imagecraft.com When replying, please edit your Subject line so it is more specific than "Re: Contents of Icc-avr digest..." Today's Topics: 1. Funtion pointer question (Steven Lose) 2. Re: Funtion pointer question (pragnesh patel) ---------------------------------------------------------------------- Message: 1 Date: Fri, 12 Jun 2009 12:39:44 +0200 From: "Steven Lose" Subject: [Icc-avr] Funtion pointer question To: "Discussion list for ICCAVR and ICCtiny Users. You do NOT need tosubscribeto icc-announce if you are a member of this." Message-ID: <072D96786BFC014AAEBA9EB07A8070EA61281F@seattle.ecpower.dk> Content-Type: text/plain; charset="iso-8859-1" Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 2650 bytes Desc: image001.jpg Url : http://dragonsgate.net/pipermail/icc-avr/attachments/20090612/4299c0b2/attac hment-0001.jpe ------------------------------ Message: 2 Date: Fri, 12 Jun 2009 05:28:16 -0700 (PDT) From: pragnesh patel Subject: Re: [Icc-avr] Funtion pointer question To: "Discussion list for ICCAVR and ICCtiny Users. You do NOT need to subscribe to icc-announce if you are a member of this." Message-ID: <7658.743.qm@web52003.mail.re2.yahoo.com> Content-Type: text/plain; charset="utf-8" You may be exceeding in time when calling function by pointer. As when you call by pointer, compiler has no idea which function is called, so it try to save and restore all registers. But when you call fix function, it save only those registers used within the new called function. Try increasing your timer tick. Pragnesh --- On Fri, 6/12/09, Steven Lose wrote: From: Steven Lose Subject: [Icc-avr] Funtion pointer question To: "Discussion list for ICCAVR and ICCtiny Users. You do NOT need tosubscribeto icc-announce if you are a member of this." Date: Friday, June 12, 2009, 4:09 PM Hi. B I have a function pointer issue that I need help to understand. ICCAVR 7.21A PRO ATMEGA2561 B I have a scheduler that calls functions by pointers stored in an array. B typedef void(*FP)(void); typedef struct { B B B B B B B B B B B B B B B B FP Fp; B B B B B B B B B B B B B B B B unsigned char TaskCheck; B B B B B B B B B B B B B B B B unsigned char TaskTimeCheck; B B B B B B B B B B B B B B B B unsigned long TaskCheckTime; B B B B B B B B B B B B B B B B unsigned char TaskMasterEnable; B B B B B B B B B B B B B B }cTask_T; __flash cTask_T Fpoint[NrOfTask] = {b From benjamin_rockwell at yahoo.com Fri Jun 12 08:10:43 2009 From: benjamin_rockwell at yahoo.com (Benjamin Rockwell) Date: Fri Jun 12 09:19:49 2009 Subject: [Icc-avr] iccavrplugin and windows 7 Message-ID: <465661.89059.qm@web56404.mail.re3.yahoo.com> I recently installed the Windows 7 RC on a?system along with ICCAVR7 and AVRStudio. I?tried to install the ICC AVR Studio plugin. The installation failed with a message indicating it was unable to register the dll: AvrPluginavriccplugin.dll Has anyone else tried this? Ben -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20090612/1424e176/attachment.html From sl at ecpower.dk Fri Jun 12 09:02:33 2009 From: sl at ecpower.dk (Steven Lose) Date: Fri Jun 12 10:11:41 2009 Subject: SV: [Icc-avr] Funtion pointer question In-Reply-To: References: <200906121338.n5CDc49l043985@mail.imagecraft.com> Message-ID: <072D96786BFC014AAEBA9EB07A8070EA61285A@seattle.ecpower.dk> 1. yes, anything else would be a surprise. 2. Also what I thought, but I got confused when I say the exicall. 3. Thanks, but I'm not using uC/OS-II I have no clue what the problem is, I have used this scheduler for a number of years, but got into trouble when changing from M128 to M256x The problem is very similar to the problem that Richard fixed in 7.20 regarding ldd offset expansion error. 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 Dana Raymond Sendt: 12. juni 2009 16:55 Til: icc-avr@imagecraft.com Emne: [Icc-avr] Funtion pointer question Firstly, the registers are stored on the software stack within the called function, not at the calling point, so there should be no additional overhead by using function pointers, other than the indirection itself. Secondly, The ATM 256X series uses a function pointer table located below main(). The 16bit address you speak of is the address of the location of a full address of the function, allowing the function to reside anywhere within the full program memory space. Thirdly, if you happen to be using uC/OS-II as your scheduler you should be aware that a new ATM256 port is soon to be available that allows the entire program memory space to contain tasks. The new port fixes problems with first starting a task if located in the upper 128KB of program memory only. I Hope This Helps. DFR Astrix Networks Inc. -----Original Message----- From: icc-avr-bounces@imagecraft.com [mailto:icc-avr-bounces@imagecraft.com] On Behalf Of icc-avr-request@imagecraft.com Sent: June 12, 2009 9:38 AM To: icc-avr@imagecraft.com Subject: Icc-avr Digest, Vol 59, Issue 7 Send Icc-avr mailing list submissions to icc-avr@imagecraft.com To subscribe or unsubscribe via the World Wide Web, visit http://dragonsgate.net/mailman/listinfo/icc-avr or, via email, send a message with subject or body 'help' to icc-avr-request@imagecraft.com You can reach the person managing the list at icc-avr-owner@imagecraft.com When replying, please edit your Subject line so it is more specific than "Re: Contents of Icc-avr digest..." Today's Topics: 1. Funtion pointer question (Steven Lose) 2. Re: Funtion pointer question (pragnesh patel) ---------------------------------------------------------------------- Message: 1 Date: Fri, 12 Jun 2009 12:39:44 +0200 From: "Steven Lose" Subject: [Icc-avr] Funtion pointer question To: "Discussion list for ICCAVR and ICCtiny Users. You do NOT need tosubscribeto icc-announce if you are a member of this." Message-ID: <072D96786BFC014AAEBA9EB07A8070EA61281F@seattle.ecpower.dk> Content-Type: text/plain; charset="iso-8859-1" Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 2650 bytes Desc: image001.jpg Url : http://dragonsgate.net/pipermail/icc-avr/attachments/20090612/4299c0b2/attac hment-0001.jpe ------------------------------ Message: 2 Date: Fri, 12 Jun 2009 05:28:16 -0700 (PDT) From: pragnesh patel Subject: Re: [Icc-avr] Funtion pointer question To: "Discussion list for ICCAVR and ICCtiny Users. You do NOT need to subscribe to icc-announce if you are a member of this." Message-ID: <7658.743.qm@web52003.mail.re2.yahoo.com> Content-Type: text/plain; charset="utf-8" You may be exceeding in time when calling function by pointer. As when you call by pointer, compiler has no idea which function is called, so it try to save and restore all registers. But when you call fix function, it save only those registers used within the new called function. Try increasing your timer tick. Pragnesh --- On Fri, 6/12/09, Steven Lose wrote: From: Steven Lose Subject: [Icc-avr] Funtion pointer question To: "Discussion list for ICCAVR and ICCtiny Users. You do NOT need tosubscribeto icc-announce if you are a member of this." Date: Friday, June 12, 2009, 4:09 PM Hi. B I have a function pointer issue that I need help to understand. ICCAVR 7.21A PRO ATMEGA2561 B I have a scheduler that calls functions by pointers stored in an array. B typedef void(*FP)(void); typedef struct { B B B B B B B B B B B B B B B B FP Fp; B B B B B B B B B B B B B B B B unsigned char TaskCheck; B B B B B B B B B B B B B B B B unsigned char TaskTimeCheck; B B B B B B B B B B B B B B B B unsigned long TaskCheckTime; B B B B B B B B B B B B B B B B unsigned char TaskMasterEnable; B B B B B B B B B B B B B B }cTask_T; __flash cTask_T Fpoint[NrOfTask] = {b _______________________________________________ Icc-avr mailing list Icc-avr@imagecraft.com http://dragonsgate.net/mailman/listinfo/icc-avr From danar at astrixnet.com Fri Jun 12 09:28:57 2009 From: danar at astrixnet.com (Dana Raymond) Date: Fri Jun 12 10:38:04 2009 Subject: [Icc-avr] Funtion pointer question In-Reply-To: <072D96786BFC014AAEBA9EB07A8070EA61285A@seattle.ecpower.dk> References: <200906121338.n5CDc49l043985@mail.imagecraft.com> <072D96786BFC014AAEBA9EB07A8070EA61285A@seattle.ecpower.dk> Message-ID: " I have no clue what the problem is, I have used this scheduler for a number of years, but got into trouble when changing from M128 to M256x" Given that comment I would look at your scheduler's task context save and restoration code. Make sure that the EIND register is part of the context. Check out this register in the datsheet, you'll see what I mean. Mopving the task down to below the half-way mark can also solve the problem but a proper fix for the M256X involves the EIND register. HTH DFR -----Original Message----- From: Steven Lose [mailto:sl@ecpower.dk] Sent: June 12, 2009 12:03 PM To: danar@astrixnet.com; Discussion list for ICCAVR and ICCtiny Users. You do NOT need tosubscribeto icc-announce if you are a member of this. Subject: SV: [Icc-avr] Funtion pointer question 1. yes, anything else would be a surprise. 2. Also what I thought, but I got confused when I say the exicall. 3. Thanks, but I'm not using uC/OS-II I have no clue what the problem is, I have used this scheduler for a number of years, but got into trouble when changing from M128 to M256x The problem is very similar to the problem that Richard fixed in 7.20 regarding ldd offset expansion error. 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 Dana Raymond Sendt: 12. juni 2009 16:55 Til: icc-avr@imagecraft.com Emne: [Icc-avr] Funtion pointer question Firstly, the registers are stored on the software stack within the called function, not at the calling point, so there should be no additional overhead by using function pointers, other than the indirection itself. Secondly, The ATM 256X series uses a function pointer table located below main(). The 16bit address you speak of is the address of the location of a full address of the function, allowing the function to reside anywhere within the full program memory space. Thirdly, if you happen to be using uC/OS-II as your scheduler you should be aware that a new ATM256 port is soon to be available that allows the entire program memory space to contain tasks. The new port fixes problems with first starting a task if located in the upper 128KB of program memory only. I Hope This Helps. DFR Astrix Networks Inc. -----Original Message----- From: icc-avr-bounces@imagecraft.com [mailto:icc-avr-bounces@imagecraft.com] On Behalf Of icc-avr-request@imagecraft.com Sent: June 12, 2009 9:38 AM To: icc-avr@imagecraft.com Subject: Icc-avr Digest, Vol 59, Issue 7 Send Icc-avr mailing list submissions to icc-avr@imagecraft.com To subscribe or unsubscribe via the World Wide Web, visit http://dragonsgate.net/mailman/listinfo/icc-avr or, via email, send a message with subject or body 'help' to icc-avr-request@imagecraft.com You can reach the person managing the list at icc-avr-owner@imagecraft.com When replying, please edit your Subject line so it is more specific than "Re: Contents of Icc-avr digest..." Today's Topics: 1. Funtion pointer question (Steven Lose) 2. Re: Funtion pointer question (pragnesh patel) ---------------------------------------------------------------------- Message: 1 Date: Fri, 12 Jun 2009 12:39:44 +0200 From: "Steven Lose" Subject: [Icc-avr] Funtion pointer question To: "Discussion list for ICCAVR and ICCtiny Users. You do NOT need tosubscribeto icc-announce if you are a member of this." Message-ID: <072D96786BFC014AAEBA9EB07A8070EA61281F@seattle.ecpower.dk> Content-Type: text/plain; charset="iso-8859-1" Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 2650 bytes Desc: image001.jpg Url : http://dragonsgate.net/pipermail/icc-avr/attachments/20090612/4299c0b2/attac hment-0001.jpe ------------------------------ Message: 2 Date: Fri, 12 Jun 2009 05:28:16 -0700 (PDT) From: pragnesh patel Subject: Re: [Icc-avr] Funtion pointer question To: "Discussion list for ICCAVR and ICCtiny Users. You do NOT need to subscribe to icc-announce if you are a member of this." Message-ID: <7658.743.qm@web52003.mail.re2.yahoo.com> Content-Type: text/plain; charset="utf-8" You may be exceeding in time when calling function by pointer. As when you call by pointer, compiler has no idea which function is called, so it try to save and restore all registers. But when you call fix function, it save only those registers used within the new called function. Try increasing your timer tick. Pragnesh --- On Fri, 6/12/09, Steven Lose wrote: From: Steven Lose Subject: [Icc-avr] Funtion pointer question To: "Discussion list for ICCAVR and ICCtiny Users. You do NOT need tosubscribeto icc-announce if you are a member of this." Date: Friday, June 12, 2009, 4:09 PM Hi. B I have a function pointer issue that I need help to understand. ICCAVR 7.21A PRO ATMEGA2561 B I have a scheduler that calls functions by pointers stored in an array. B typedef void(*FP)(void); typedef struct { B B B B B B B B B B B B B B B B FP Fp; B B B B B B B B B B B B B B B B unsigned char TaskCheck; B B B B B B B B B B B B B B B B unsigned char TaskTimeCheck; B B B B B B B B B B B B B B B B unsigned long TaskCheckTime; B B B B B B B B B B B B B B B B unsigned char TaskMasterEnable; B B B B B B B B B B B B B B }cTask_T; __flash cTask_T Fpoint[NrOfTask] = {b _______________________________________________ Icc-avr mailing list Icc-avr@imagecraft.com http://dragonsgate.net/mailman/listinfo/icc-avr From richard-lists at imagecraft.com Fri Jun 12 11:31:51 2009 From: richard-lists at imagecraft.com (Richard Man) Date: Fri Jun 12 12:41:14 2009 Subject: [Icc-avr] Funtion pointer question In-Reply-To: References: <200906121338.n5CDc49l043985@mail.imagecraft.com> <072D96786BFC014AAEBA9EB07A8070EA61285A@seattle.ecpower.dk> Message-ID: <200906121941.n5CJfDYZ051094@mail.imagecraft.com> Steve, I suspect Dana is right here, your schedule needs to save EIND also for M256 At 09:28 AM 6/12/2009, Dana Raymond wrote: >" I have no clue what the problem is, I have used this scheduler for a >number of years, but got into trouble when changing from M128 to M256x" > >Given that comment I would look at your scheduler's task context save and >restoration code. Make sure that the EIND register is part of the context. > >Check out this register in the datsheet, you'll see what I mean. Mopving the >task down to below the half-way mark can also solve the problem but a proper >fix for the M256X involves the EIND register. > // richard From jassenbaum at htp-tel.de Fri Jun 12 11:52:53 2009 From: jassenbaum at htp-tel.de (Johannes Assenbaum) Date: Fri Jun 12 13:02:00 2009 Subject: SV: [Icc-avr] Funtion pointer question References: <200906121338.n5CDc49l043985@mail.imagecraft.com> <072D96786BFC014AAEBA9EB07A8070EA61285A@seattle.ecpower.dk> Message-ID: 1. No, it's not a surprise, but a must: As compiler does not, and in case of function pointers just cannot follow the code of functions called from within an isr, it *must* save all registers that may be used becase of calling conventions (i.e. all volatile registers) *before* calling any function. 2. exicall loads three-byte call address from efunc_lit table addressed by two bytes. Nothing to get confused of ;-) Best regards, Johannes > 1. yes, anything else would be a surprise. > 2. Also what I thought, but I got confused when I say the exicall. > 3. Thanks, but I'm not using uC/OS-II > I have no clue what the problem is, I have used this scheduler for a number of > years, but got into trouble when changing from M128 to M256x > The problem is very similar to the problem that Richard fixed in 7.20 regarding ldd > offset expansion error. > 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 Dana Raymond > Sendt: 12. juni 2009 16:55 > Til: icc-avr@imagecraft.com > Emne: [Icc-avr] Funtion pointer question > Firstly, the registers are stored on the software stack within the called > function, not at the calling point, so there should be no additional > overhead by using function pointers, other than the indirection itself. > Secondly, The ATM 256X series uses a function pointer table located below > main(). The 16bit address you speak of is the address of the location of a > full address of the function, allowing the function to reside anywhere > within the full program memory space. > Thirdly, if you happen to be using uC/OS-II as your scheduler you should be > aware that a new ATM256 port is soon to be available that allows the entire > program memory space to contain tasks. The new port fixes problems with > first starting a task if located in the upper 128KB of program memory only. > I Hope This Helps. > DFR > Astrix Networks Inc. > -----Original Message----- > From: icc-avr-bounces@imagecraft.com [mailto:icc-avr-bounces@imagecraft.com] > On Behalf Of icc-avr-request@imagecraft.com > Sent: June 12, 2009 9:38 AM > To: icc-avr@imagecraft.com > Subject: Icc-avr Digest, Vol 59, Issue 7 > Send Icc-avr mailing list submissions to > icc-avr@imagecraft.com > To subscribe or unsubscribe via the World Wide Web, visit > http://dragonsgate.net/mailman/listinfo/icc-avr > or, via email, send a message with subject or body 'help' to > icc-avr-request@imagecraft.com > You can reach the person managing the list at > icc-avr-owner@imagecraft.com > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Icc-avr digest..." > Today's Topics: > 1. Funtion pointer question (Steven Lose) > 2. Re: Funtion pointer question (pragnesh patel) > ---------------------------------------------------------------------- > Message: 1 > Date: Fri, 12 Jun 2009 12:39:44 +0200 > From: "Steven Lose" > Subject: [Icc-avr] Funtion pointer question > To: "Discussion list for ICCAVR and ICCtiny Users. You do NOT need > tosubscribeto icc-announce if you are a member of this." > > Message-ID: > <072D96786BFC014AAEBA9EB07A8070EA61281F@seattle.ecpower.dk> > Content-Type: text/plain; charset="iso-8859-1" > Skipped content of type multipart/alternative-------------- next part > -------------- > A non-text attachment was scrubbed... > Name: not available > Type: image/jpeg > Size: 2650 bytes > Desc: image001.jpg > Url : > http://dragonsgate.net/pipermail/icc-avr/attachments/20090612/4299c0b2/attac > hment-0001.jpe > ------------------------------ > Message: 2 > Date: Fri, 12 Jun 2009 05:28:16 -0700 (PDT) > From: pragnesh patel > Subject: Re: [Icc-avr] Funtion pointer question > To: "Discussion list for ICCAVR and ICCtiny Users. You do NOT need to > subscribe to icc-announce if you are a member of this." > > Message-ID: <7658.743.qm@web52003.mail.re2.yahoo.com> > Content-Type: text/plain; charset="utf-8" > You may be exceeding in time when calling function by pointer. As when you > call by pointer, compiler has no idea which function is called, so it try to > save and restore all registers. But when you call fix function, it save only > those registers used within the new called function. > Try increasing your timer tick. > Pragnesh > --- On Fri, 6/12/09, Steven Lose wrote: > From: Steven Lose > Subject: [Icc-avr] Funtion pointer question > To: "Discussion list for ICCAVR and ICCtiny Users. You do NOT need > tosubscribeto icc-announce if you are a member of this." > > Date: Friday, June 12, 2009, 4:09 PM > Hi. > B > I have a function pointer issue that I need help to > understand. > ICCAVR 7.21A PRO > ATMEGA2561 > B > I have a scheduler that calls functions by pointers stored > in an array. > B > typedef void(*FP)(void); > typedef struct { > B B B B B B B B B B B B B B B B FP > Fp; > B B B B B B B B B B B B B B B B unsigned char > TaskCheck; > B B B B B B B B B B B B B B B B unsigned char > TaskTimeCheck; > B B B B B B B B B B B B B B B B unsigned long > TaskCheckTime; > B B B B B B B B B B B B B B B B unsigned char > TaskMasterEnable; > B B B B B B B B B B B B B B > }cTask_T; > __flash cTask_T Fpoint[NrOfTask] = {b > _______________________________________________ > 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 Fri Jun 12 13:35:16 2009 From: sl at ecpower.dk (Steven Lose) Date: Fri Jun 12 14:44:26 2009 Subject: SV: [Icc-avr] Funtion pointer question In-Reply-To: References: <200906121338.n5CDc49l043985@mail.imagecraft.com> <072D96786BFC014AAEBA9EB07A8070EA61285A@seattle.ecpower.dk> Message-ID: <072D96786BFC014AAEBA9EB07A8070EA612860@seattle.ecpower.dk> Thanks again Dana. I have made a test, and it have now run for an Hour, where it would crash within a few seconds before. I have spent a week on the problem, and would properly not have found it within the next week without help. It's nice with this list and thanks to all the people out there willing to help. ;o) Med venlig hilsen / Best regards / mit freundlichen Gr??en EC POWER A/S Steven Lose Software Ingeni?r Tlf.: +45 87434100 Direkte tlf. +45 58286608 Email: sl@ecpower.dk www.ecpower.dk -----Oprindelig meddelelse----- Fra: Dana Raymond [mailto:danar@astrixnet.com] Sendt: 12. juni 2009 18:29 Til: Steven Lose; 'Discussion list for ICCAVR and ICCtiny Users. You do NOT need tosubscribeto icc-announce if you are a member of this.' Emne: RE: [Icc-avr] Funtion pointer question " I have no clue what the problem is, I have used this scheduler for a number of years, but got into trouble when changing from M128 to M256x" Given that comment I would look at your scheduler's task context save and restoration code. Make sure that the EIND register is part of the context. Check out this register in the datsheet, you'll see what I mean. Mopving the task down to below the half-way mark can also solve the problem but a proper fix for the M256X involves the EIND register. HTH DFR -----Original Message----- From: Steven Lose [mailto:sl@ecpower.dk] Sent: June 12, 2009 12:03 PM To: danar@astrixnet.com; Discussion list for ICCAVR and ICCtiny Users. You do NOT need tosubscribeto icc-announce if you are a member of this. Subject: SV: [Icc-avr] Funtion pointer question 1. yes, anything else would be a surprise. 2. Also what I thought, but I got confused when I say the exicall. 3. Thanks, but I'm not using uC/OS-II I have no clue what the problem is, I have used this scheduler for a number of years, but got into trouble when changing from M128 to M256x The problem is very similar to the problem that Richard fixed in 7.20 regarding ldd offset expansion error. 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 Dana Raymond Sendt: 12. juni 2009 16:55 Til: icc-avr@imagecraft.com Emne: [Icc-avr] Funtion pointer question Firstly, the registers are stored on the software stack within the called function, not at the calling point, so there should be no additional overhead by using function pointers, other than the indirection itself. Secondly, The ATM 256X series uses a function pointer table located below main(). The 16bit address you speak of is the address of the location of a full address of the function, allowing the function to reside anywhere within the full program memory space. Thirdly, if you happen to be using uC/OS-II as your scheduler you should be aware that a new ATM256 port is soon to be available that allows the entire program memory space to contain tasks. The new port fixes problems with first starting a task if located in the upper 128KB of program memory only. I Hope This Helps. DFR Astrix Networks Inc. -----Original Message----- From: icc-avr-bounces@imagecraft.com [mailto:icc-avr-bounces@imagecraft.com] On Behalf Of icc-avr-request@imagecraft.com Sent: June 12, 2009 9:38 AM To: icc-avr@imagecraft.com Subject: Icc-avr Digest, Vol 59, Issue 7 Send Icc-avr mailing list submissions to icc-avr@imagecraft.com To subscribe or unsubscribe via the World Wide Web, visit http://dragonsgate.net/mailman/listinfo/icc-avr or, via email, send a message with subject or body 'help' to icc-avr-request@imagecraft.com You can reach the person managing the list at icc-avr-owner@imagecraft.com When replying, please edit your Subject line so it is more specific than "Re: Contents of Icc-avr digest..." Today's Topics: 1. Funtion pointer question (Steven Lose) 2. Re: Funtion pointer question (pragnesh patel) ---------------------------------------------------------------------- Message: 1 Date: Fri, 12 Jun 2009 12:39:44 +0200 From: "Steven Lose" Subject: [Icc-avr] Funtion pointer question To: "Discussion list for ICCAVR and ICCtiny Users. You do NOT need tosubscribeto icc-announce if you are a member of this." Message-ID: <072D96786BFC014AAEBA9EB07A8070EA61281F@seattle.ecpower.dk> Content-Type: text/plain; charset="iso-8859-1" Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 2650 bytes Desc: image001.jpg Url : http://dragonsgate.net/pipermail/icc-avr/attachments/20090612/4299c0b2/attac hment-0001.jpe ------------------------------ Message: 2 Date: Fri, 12 Jun 2009 05:28:16 -0700 (PDT) From: pragnesh patel Subject: Re: [Icc-avr] Funtion pointer question To: "Discussion list for ICCAVR and ICCtiny Users. You do NOT need to subscribe to icc-announce if you are a member of this." Message-ID: <7658.743.qm@web52003.mail.re2.yahoo.com> Content-Type: text/plain; charset="utf-8" You may be exceeding in time when calling function by pointer. As when you call by pointer, compiler has no idea which function is called, so it try to save and restore all registers. But when you call fix function, it save only those registers used within the new called function. Try increasing your timer tick. Pragnesh --- On Fri, 6/12/09, Steven Lose wrote: From: Steven Lose Subject: [Icc-avr] Funtion pointer question To: "Discussion list for ICCAVR and ICCtiny Users. You do NOT need tosubscribeto icc-announce if you are a member of this." Date: Friday, June 12, 2009, 4:09 PM Hi. B I have a function pointer issue that I need help to understand. ICCAVR 7.21A PRO ATMEGA2561 B I have a scheduler that calls functions by pointers stored in an array. B typedef void(*FP)(void); typedef struct { B B B B B B B B B B B B B B B B FP Fp; B B B B B B B B B B B B B B B B unsigned char TaskCheck; B B B B B B B B B B B B B B B B unsigned char TaskTimeCheck; B B B B B B B B B B B B B B B B unsigned long TaskCheckTime; B B B B B B B B B B B B B B B B unsigned char TaskMasterEnable; B B B B B B B B B B B B B B }cTask_T; __flash cTask_T Fpoint[NrOfTask] = {b _______________________________________________ Icc-avr mailing list Icc-avr@imagecraft.com http://dragonsgate.net/mailman/listinfo/icc-avr From danar at astrixnet.com Fri Jun 12 13:51:33 2009 From: danar at astrixnet.com (Dana Raymond) Date: Fri Jun 12 15:00:39 2009 Subject: [Icc-avr] Funtion pointer question In-Reply-To: <072D96786BFC014AAEBA9EB07A8070EA612860@seattle.ecpower.dk> References: <200906121338.n5CDc49l043985@mail.imagecraft.com> <072D96786BFC014AAEBA9EB07A8070EA61285A@seattle.ecpower.dk> <072D96786BFC014AAEBA9EB07A8070EA612860@seattle.ecpower.dk> Message-ID: We just came out of a 3-week detour because wour executive didn't hanle EIND properly. I'm glad the lists's efforts to assist you with this issue ended up on a positive note. DFR -----Original Message----- From: Steven Lose [mailto:sl@ecpower.dk] Sent: June 12, 2009 4:35 PM To: danar@astrixnet.com; Discussion list for ICCAVR and ICCtiny Users. You do NOT need tosubscribeto icc-announce if you are a member of this. Subject: SV: [Icc-avr] Funtion pointer question Thanks again Dana. I have made a test, and it have now run for an Hour, where it would crash within a few seconds before. I have spent a week on the problem, and would properly not have found it within the next week without help. It's nice with this list and thanks to all the people out there willing to help. ;o) Med venlig hilsen / Best regards / mit freundlichen Gr??en EC POWER A/S Steven Lose Software Ingeni?r Tlf.: +45 87434100 Direkte tlf. +45 58286608 Email: sl@ecpower.dk www.ecpower.dk -----Oprindelig meddelelse----- Fra: Dana Raymond [mailto:danar@astrixnet.com] Sendt: 12. juni 2009 18:29 Til: Steven Lose; 'Discussion list for ICCAVR and ICCtiny Users. You do NOT need tosubscribeto icc-announce if you are a member of this.' Emne: RE: [Icc-avr] Funtion pointer question " I have no clue what the problem is, I have used this scheduler for a number of years, but got into trouble when changing from M128 to M256x" Given that comment I would look at your scheduler's task context save and restoration code. Make sure that the EIND register is part of the context. Check out this register in the datsheet, you'll see what I mean. Mopving the task down to below the half-way mark can also solve the problem but a proper fix for the M256X involves the EIND register. HTH DFR -----Original Message----- From: Steven Lose [mailto:sl@ecpower.dk] Sent: June 12, 2009 12:03 PM To: danar@astrixnet.com; Discussion list for ICCAVR and ICCtiny Users. You do NOT need tosubscribeto icc-announce if you are a member of this. Subject: SV: [Icc-avr] Funtion pointer question 1. yes, anything else would be a surprise. 2. Also what I thought, but I got confused when I say the exicall. 3. Thanks, but I'm not using uC/OS-II I have no clue what the problem is, I have used this scheduler for a number of years, but got into trouble when changing from M128 to M256x The problem is very similar to the problem that Richard fixed in 7.20 regarding ldd offset expansion error. 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 Dana Raymond Sendt: 12. juni 2009 16:55 Til: icc-avr@imagecraft.com Emne: [Icc-avr] Funtion pointer question Firstly, the registers are stored on the software stack within the called function, not at the calling point, so there should be no additional overhead by using function pointers, other than the indirection itself. Secondly, The ATM 256X series uses a function pointer table located below main(). The 16bit address you speak of is the address of the location of a full address of the function, allowing the function to reside anywhere within the full program memory space. Thirdly, if you happen to be using uC/OS-II as your scheduler you should be aware that a new ATM256 port is soon to be available that allows the entire program memory space to contain tasks. The new port fixes problems with first starting a task if located in the upper 128KB of program memory only. I Hope This Helps. DFR Astrix Networks Inc. -----Original Message----- From: icc-avr-bounces@imagecraft.com [mailto:icc-avr-bounces@imagecraft.com] On Behalf Of icc-avr-request@imagecraft.com Sent: June 12, 2009 9:38 AM To: icc-avr@imagecraft.com Subject: Icc-avr Digest, Vol 59, Issue 7 Send Icc-avr mailing list submissions to icc-avr@imagecraft.com To subscribe or unsubscribe via the World Wide Web, visit http://dragonsgate.net/mailman/listinfo/icc-avr or, via email, send a message with subject or body 'help' to icc-avr-request@imagecraft.com You can reach the person managing the list at icc-avr-owner@imagecraft.com When replying, please edit your Subject line so it is more specific than "Re: Contents of Icc-avr digest..." Today's Topics: 1. Funtion pointer question (Steven Lose) 2. Re: Funtion pointer question (pragnesh patel) ---------------------------------------------------------------------- Message: 1 Date: Fri, 12 Jun 2009 12:39:44 +0200 From: "Steven Lose" Subject: [Icc-avr] Funtion pointer question To: "Discussion list for ICCAVR and ICCtiny Users. You do NOT need tosubscribeto icc-announce if you are a member of this." Message-ID: <072D96786BFC014AAEBA9EB07A8070EA61281F@seattle.ecpower.dk> Content-Type: text/plain; charset="iso-8859-1" Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 2650 bytes Desc: image001.jpg Url : http://dragonsgate.net/pipermail/icc-avr/attachments/20090612/4299c0b2/attac hment-0001.jpe ------------------------------ Message: 2 Date: Fri, 12 Jun 2009 05:28:16 -0700 (PDT) From: pragnesh patel Subject: Re: [Icc-avr] Funtion pointer question To: "Discussion list for ICCAVR and ICCtiny Users. You do NOT need to subscribe to icc-announce if you are a member of this." Message-ID: <7658.743.qm@web52003.mail.re2.yahoo.com> Content-Type: text/plain; charset="utf-8" You may be exceeding in time when calling function by pointer. As when you call by pointer, compiler has no idea which function is called, so it try to save and restore all registers. But when you call fix function, it save only those registers used within the new called function. Try increasing your timer tick. Pragnesh --- On Fri, 6/12/09, Steven Lose wrote: From: Steven Lose Subject: [Icc-avr] Funtion pointer question To: "Discussion list for ICCAVR and ICCtiny Users. You do NOT need tosubscribeto icc-announce if you are a member of this." Date: Friday, June 12, 2009, 4:09 PM Hi. B I have a function pointer issue that I need help to understand. ICCAVR 7.21A PRO ATMEGA2561 B I have a scheduler that calls functions by pointers stored in an array. B typedef void(*FP)(void); typedef struct { B B B B B B B B B B B B B B B B FP Fp; B B B B B B B B B B B B B B B B unsigned char TaskCheck; B B B B B B B B B B B B B B B B unsigned char TaskTimeCheck; B B B B B B B B B B B B B B B B unsigned long TaskCheckTime; B B B B B B B B B B B B B B B B unsigned char TaskMasterEnable; B B B B B B B B B B B B B B }cTask_T; __flash cTask_T Fpoint[NrOfTask] = {b _______________________________________________ Icc-avr mailing list Icc-avr@imagecraft.com http://dragonsgate.net/mailman/listinfo/icc-avr From richard-lists at imagecraft.com Fri Jun 12 14:01:35 2009 From: richard-lists at imagecraft.com (Richard Man) Date: Fri Jun 12 15:10:57 2009 Subject: [Icc-avr] Funtion pointer question In-Reply-To: References: <200906121338.n5CDc49l043985@mail.imagecraft.com> <072D96786BFC014AAEBA9EB07A8070EA61285A@seattle.ecpower.dk> <072D96786BFC014AAEBA9EB07A8070EA612860@seattle.ecpower.dk> Message-ID: <200906122210.n5CMAuLo053678@mail.imagecraft.com> In your case, it's because the RTOS did not read the 3 byte function address. Glad they fixed it. At 01:51 PM 6/12/2009, Dana Raymond wrote: >We just came out of a 3-week detour because wour executive didn't hanle EIND >properly. > >I'm glad the lists's efforts to assist you with this issue ended up on a >positive note. > >DFR > // richard From richard at imagecraft.com Fri Jun 12 14:03:23 2009 From: richard at imagecraft.com (Richard Man) Date: Fri Jun 12 15:12:44 2009 Subject: [Icc-avr] 7;.22 BETA2 Message-ID: <200906122212.n5CMChMO053756@mail.imagecraft.com> A number of bug fixes and enhancements: http://www.imagecraft.com/pub/iccv7avr_v722_beta2.exe *** 7.22 IDE - Changed -D__ICC_VERSION=XXX where XXX is the version in integer form, e.g. 722. This allows easier conditional compilation. - XM128 bootloader was not emitting -xcall due to a typo. - Modified the "checking" options, now they are "Strict Checking" (equivalent to -A command line switch). "ANSI C Portability Conformance Checking" (equivalent to -A -A). This does draconian check on conditions that exceed ANSI C minimum limits (e.g. less than 512 variables) and is usually not needed. Compiler - Now always performs constant folding even if the constants *may* overflow (e.g. clock rate calculation) - Fixed XMEGA option not turning on enhanced core code generation error. - Added #pragma warning warning message emits warning message, similar to #warning #pragma ignore_unused_var name1 name2 ... This must appear inside a function and specifies the named arguments are intentionally unused so no warning message should be generated for them. - C Interrupt handlers for M256 or above now saves and restores EIND. Header Files - many updates for XMega etc. Library - Some floating point low level routines use R20-R23, making the library incompatible with the "Do Not Use R20..R23" option. This has been fixed. - Enabled fast scaled math versions of sinf and cosf // richard blog: 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 dean.bell at flightec.com Mon Jun 15 14:01:18 2009 From: dean.bell at flightec.com (Dean Bell) Date: Mon Jun 15 15:10:30 2009 Subject: [Icc-avr] V-USB port Message-ID: Hi Has any one ported V-USB (http://www.obdev.at/products/vusb/index.html) to ICCAVR? Dean. From sl at ecpower.dk Wed Jun 17 22:44:12 2009 From: sl at ecpower.dk (Steven Lose) Date: Wed Jun 17 23:53:29 2009 Subject: SV: [Icc-avr] 7;.22 BETA2 In-Reply-To: <200906122212.n5CMChMO053756@mail.imagecraft.com> Message-ID: <072D96786BFC014AAEBA9EB07A8070EA612A20@seattle.ecpower.dk> Hi Richard. Thanks for the quick response to the EIND problem. Release notes states that it is only in interrupt that EIND is stored/restored. What if compiler uses EICALL/EIJMP outside an interrupt? 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 Man Sendt: 12. juni 2009 23:03 Til: icc-avr@imagecraft.com Emne: [Icc-avr] 7;.22 BETA2 A number of bug fixes and enhancements: http://www.imagecraft.com/pub/iccv7avr_v722_beta2.exe *** 7.22 IDE - Changed -D__ICC_VERSION=XXX where XXX is the version in integer form, e.g. 722. This allows easier conditional compilation. - XM128 bootloader was not emitting -xcall due to a typo. - Modified the "checking" options, now they are "Strict Checking" (equivalent to -A command line switch). "ANSI C Portability Conformance Checking" (equivalent to -A -A). This does draconian check on conditions that exceed ANSI C minimum limits (e.g. less than 512 variables) and is usually not needed. Compiler - Now always performs constant folding even if the constants *may* overflow (e.g. clock rate calculation) - Fixed XMEGA option not turning on enhanced core code generation error. - Added #pragma warning warning message emits warning message, similar to #warning #pragma ignore_unused_var name1 name2 ... This must appear inside a function and specifies the named arguments are intentionally unused so no warning message should be generated for them. - C Interrupt handlers for M256 or above now saves and restores EIND. Header Files - many updates for XMega etc. Library - Some floating point low level routines use R20-R23, making the library incompatible with the "Do Not Use R20..R23" option. This has been fixed. - Enabled fast scaled math versions of sinf and cosf // richard blog: 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 Wed Jun 17 22:59:57 2009 From: richard-lists at imagecraft.com (Richard Man) Date: Thu Jun 18 00:09:37 2009 Subject: SV: [Icc-avr] 7;.22 BETA2 In-Reply-To: <072D96786BFC014AAEBA9EB07A8070EA612A20@seattle.ecpower.dk> References: <200906122212.n5CMChMO053756@mail.imagecraft.com> <072D96786BFC014AAEBA9EB07A8070EA612A20@seattle.ecpower.dk> Message-ID: <200906180709.n5I79Zjr081241@mail.imagecraft.com> I think it's OK because the compiler always load EIND when it generates EICALL/EIJMP. In fact, currently the compiler does not generate eicall directly and uses a library routine that uses eijmp to accomplish the equivalence of eicall. So this fix should be good for all cases. Let me know if you think there are scenarios where this fails. At 10:44 PM 6/17/2009, Steven Lose wrote: >Hi Richard. > >Thanks for the quick response to the EIND problem. > >Release notes states that it is only in >interrupt that EIND is stored/restored. What if >compiler uses EICALL/EIJMP outside an interrupt? > >Med venlig hilsen / Best regards / mit freundlichen Gr??en // richard From sl at ecpower.dk Thu Jun 18 01:14:04 2009 From: sl at ecpower.dk (Steven Lose) Date: Thu Jun 18 02:23:19 2009 Subject: SV: SV: [Icc-avr] 7;.22 BETA2 In-Reply-To: <200906180709.n5I79Zjr081241@mail.imagecraft.com> Message-ID: <072D96786BFC014AAEBA9EB07A8070EA612A60@seattle.ecpower.dk> I guess its ok then, but maybe the compiler should just do the store/restore everywhere the EICALL/EIJMP is used, and if EICALL/EIJMP is not generated now, maybe they will in 6 month when we have forgotten this EIND problem. But I think you know best what to, so you decide. ;o) Anyway, my test until now runs fine and has not produced any crashes. 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 Man Sendt: 18. juni 2009 08:00 Til: icc-avr@imagecraft.com Emne: Re: SV: [Icc-avr] 7;.22 BETA2 I think it's OK because the compiler always load EIND when it generates EICALL/EIJMP. In fact, currently the compiler does not generate eicall directly and uses a library routine that uses eijmp to accomplish the equivalence of eicall. So this fix should be good for all cases. Let me know if you think there are scenarios where this fails. At 10:44 PM 6/17/2009, Steven Lose wrote: >Hi Richard. > >Thanks for the quick response to the EIND problem. > >Release notes states that it is only in >interrupt that EIND is stored/restored. What if >compiler uses EICALL/EIJMP outside an interrupt? > >Med venlig hilsen / Best regards / mit freundlichen Gr??en // richard _______________________________________________ Icc-avr mailing list Icc-avr@imagecraft.com http://dragonsgate.net/mailman/listinfo/icc-avr From richard-lists at imagecraft.com Thu Jun 18 01:42:37 2009 From: richard-lists at imagecraft.com (Richard Man) Date: Thu Jun 18 02:52:17 2009 Subject: SV: SV: [Icc-avr] 7;.22 BETA2 In-Reply-To: <072D96786BFC014AAEBA9EB07A8070EA612A60@seattle.ecpower.dk> References: <200906180709.n5I79Zjr081241@mail.imagecraft.com> <072D96786BFC014AAEBA9EB07A8070EA612A60@seattle.ecpower.dk> Message-ID: <200906180952.n5I9qFRP084571@mail.imagecraft.com> No, the compiler must obey some rules, which in this case are: - If it needs to use EIND, then it loads it. - If it may change other uses of EIND, and that can only happen in an ISR, then it should save/restore it. Simple. The bug was that I forgot about case #2 :-) At 01:14 AM 6/18/2009, Steven Lose wrote: >I guess its ok then, but maybe the compiler should just do the >store/restore everywhere the EICALL/EIJMP is used, and if >EICALL/EIJMP is not generated now, maybe they will in 6 month when >we have forgotten this EIND problem. > >But I think you know best what to, so you decide. ;o) > >Anyway, my test until now runs fine and has not produced any crashes. // richard From benra at imt.liu.se Wed Jun 24 00:12:03 2009 From: benra at imt.liu.se (Bengt Ragnemalm) Date: Wed Jun 24 01:21:46 2009 Subject: [Icc-avr] AVR Studio plug-in Message-ID: Hi. I have tested the plug in some time but never really started to use it. A friend asked why and I think it was two reasons. The way Studio sorts and add files. If I remember right Studio does not sort them alphabetical and it was impossible to add more than on file at a time. Do I remember correct? I have not the latest Studio version installed so I can not test at the moment. Has anything of this to do with the plug-in or is it just the way Studio behaves? Bengt Bengt Ragnemalm, Forskningsingenj?r Tel 013-22 24 97 Leveransadress: FAX: +46 13 10 19 02 Link?pings Universitet bengt.ragnemalm@imt.liu.se Inst. f?r Medicinsk Teknik 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/20090624/2ecaf5b2/attachment.html From tim at sabretechnology.co.uk Wed Jun 24 04:44:13 2009 From: tim at sabretechnology.co.uk (Tim Mitchell) Date: Wed Jun 24 05:53:41 2009 Subject: [Icc-avr] Strange compilation result Message-ID: <04671BB8D269034BBC4BB6BA8948672616509E@sserver.SabreTechnology.local> Hi Folks, can anyone help me understand what is going wrong here. I have an array of dimmer levels (char) and I am wanting to multiply each by a master dimmer (char). xc is declared as an unsigned int. TXPointer is a char pointer to the array of dimmer levels. If I do... xc=(*TXPointer)*MasterDimmer; TXPointer++; all is ok. but if I do xc=(*TXPointer++)*MasterDimmer; it doesn't work the same. (works if MasterDimmer=0 else appears as if MasterDimmer=255) To my mind this should be the same thing. The asm code generated is: (0518) xc=*TXPointer*MasterDimmer; 678E 9020 0154 LDS R2,MasterDimmer 6790 91E0 1685 LDS R30,TXPointer 6792 91F0 1686 LDS R31,TXPointer+1 6794 8030 LDD R3,Z+0 6795 9C32 MUL R3,R2 6796 0180 MOVW R16,R0 (0519) TXPointer++; 6797 01CF MOVW R24,R30 6798 9601 ADIW R24,1 6799 9390 1686 STS TXPointer+1,R25 679B 9380 1685 STS TXPointer,R24 and (0517) xc=(*TXPointer++)*MasterDimmer; 6790 9110 0154 LDS R17,MasterDimmer 6792 91E0 1685 LDS R30,TXPointer 6794 91F0 1686 LDS R31,TXPointer+1 6796 9101 LD R16,Z+ 6797 93F0 1686 STS TXPointer+1,R31 6799 93E0 1685 STS TXPointer,R30 679B 0301 MULSU R16,R17 679C 0150 MOVW R10,R0 iccavr v7.18b -- Tim Mitchell From owena99 at gmail.com Wed Jun 24 04:44:12 2009 From: owena99 at gmail.com (OWENA) Date: Wed Jun 24 05:53:43 2009 Subject: [Icc-avr] AVR Studio plug-in In-Reply-To: References: Message-ID: <0A46EAE54A9D4E53A5AA627BEA354615@BLACK> _____ Hi. I have tested the plug in some time but never really started to use it. A friend asked why and I think it was two reasons. The way Studio sorts and add files. If I remember right Studio does not sort them alphabetical and it was impossible to add more than on file at a time. Do I remember correct? I have not the latest Studio version installed so I can not test at the moment. Has anything of this to do with the plug-in or is it just the way Studio behaves? Bengt Hi Bengt, I tried the plug in a short while ago but found that I could not use splint for code checking with the plug in so went back to using the Imagecraft IDE, do not know about multiple files as I only had one C file in the project. Using the IDE is not a big hassle as I am using two monitors. Regards Owen. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20090624/e6aad05a/attachment-0001.html From jassenbaum at htp-tel.de Wed Jun 24 12:05:15 2009 From: jassenbaum at htp-tel.de (Johannes Assenbaum) Date: Wed Jun 24 13:14:39 2009 Subject: [Icc-avr] Strange compilation result References: <04671BB8D269034BBC4BB6BA8948672616509E@sserver.SabreTechnology.local> Message-ID: Hi Tim, as I have similar in a new project, I played around with your code a bit and don't understand the results, too. Compiler always generates MULSU (mult signed with unsigned) for *pointer++, if ++ is in the same instruction as the mult operator, it even ignores explicite casting like this: xc=MasterDimmer*(unsigned char)(*TXPointer++); The only code using ++ compiled correctly is with an extra (local) char variable: x=*TXPointer++; xc=x*MasterDimmer; A case for Richard, I think... Best regards, Johannes > Hi Folks, can anyone help me understand what is going wrong here. > I have an array of dimmer levels (char) and I am wanting to multiply > each by a master dimmer (char). > xc is declared as an unsigned int. TXPointer is a char pointer to the > array of dimmer levels. > If I do... > xc=(*TXPointer)*MasterDimmer; > TXPointer++; > all is ok. > but if I do > xc=(*TXPointer++)*MasterDimmer; > it doesn't work the same. (works if MasterDimmer=0 else appears as if > MasterDimmer=255) > To my mind this should be the same thing. > The asm code generated is: > (0518) xc=*TXPointer*MasterDimmer; > 678E 9020 0154 LDS R2,MasterDimmer > 6790 91E0 1685 LDS R30,TXPointer > 6792 91F0 1686 LDS R31,TXPointer+1 > 6794 8030 LDD R3,Z+0 > 6795 9C32 MUL R3,R2 > 6796 0180 MOVW R16,R0 > (0519) TXPointer++; > 6797 01CF MOVW R24,R30 > 6798 9601 ADIW R24,1 > 6799 9390 1686 STS TXPointer+1,R25 > 679B 9380 1685 STS TXPointer,R24 > and > (0517) xc=(*TXPointer++)*MasterDimmer; > 6790 9110 0154 LDS R17,MasterDimmer > 6792 91E0 1685 LDS R30,TXPointer > 6794 91F0 1686 LDS R31,TXPointer+1 > 6796 9101 LD R16,Z+ > 6797 93F0 1686 STS TXPointer+1,R31 > 6799 93E0 1685 STS TXPointer,R30 > 679B 0301 MULSU R16,R17 > 679C 0150 MOVW R10,R0 > iccavr v7.18b > -- > Tim Mitchell > _______________________________________________ > Icc-avr mailing list > Icc-avr@imagecraft.com > http://dragonsgate.net/mailman/listinfo/icc-avr From j_baraclough at zetnet.co.uk Wed Jun 24 12:15:59 2009 From: j_baraclough at zetnet.co.uk (John Baraclough) Date: Wed Jun 24 13:25:26 2009 Subject: [Icc-avr] Strange compilation result In-Reply-To: References: <04671BB8D269034BBC4BB6BA8948672616509E@sserver.SabreTechnology.local> Message-ID: <4A427B6F.2040702@zetnet.co.uk> Hi Tim & Johannes, What happens if you put in the correct casting? xc= MasterDimmer * (unsigned int)(*TxPointer++); That of course assumes that MasterDimmer is already 'unsigned int'. All the best for now, John Johannes Assenbaum wrote: > Hi Tim, > > as I have similar in a new project, I played around with your code a bit and don't understand the results, too. Compiler always generates MULSU (mult signed with unsigned) for *pointer++, if ++ is in the same instruction as the mult operator, it even ignores explicite casting like this: > > xc=MasterDimmer*(unsigned char)(*TXPointer++); > > The only code using ++ compiled correctly is with an extra (local) char variable: > > x=*TXPointer++; > xc=x*MasterDimmer; > > A case for Richard, I think... > > Best regards, > Johannes > > From richard-lists at imagecraft.com Wed Jun 24 12:45:24 2009 From: richard-lists at imagecraft.com (Richard Man) Date: Wed Jun 24 13:55:25 2009 Subject: [Icc-avr] Strange compilation result In-Reply-To: <04671BB8D269034BBC4BB6BA8948672616509E@sserver.SabreTechno logy.local> References: <04671BB8D269034BBC4BB6BA8948672616509E@sserver.SabreTechnology.local> Message-ID: <200906242055.n5OKtOtY052055@mail.imagecraft.com> Hmm... sounds like a bug. I am about to release 7.22, so I will try to fix it before release. At 04:44 AM 6/24/2009, Tim Mitchell wrote: >Hi Folks, can anyone help me understand what is going wrong here. > >I have an array of dimmer levels (char) and I am wanting to multiply >each by a master dimmer (char). > >xc is declared as an unsigned int. TXPointer is a char pointer to the >array of dimmer levels. > >If I do... > xc=(*TXPointer)*MasterDimmer; > TXPointer++; > >all is ok. > >but if I do > xc=(*TXPointer++)*MasterDimmer; > >it doesn't work the same. (works if MasterDimmer=0 else appears as if >MasterDimmer=255) > >To my mind this should be the same thing. > >The asm code generated is: > >(0518) xc=*TXPointer*MasterDimmer; > 678E 9020 0154 LDS R2,MasterDimmer > 6790 91E0 1685 LDS R30,TXPointer > 6792 91F0 1686 LDS R31,TXPointer+1 > 6794 8030 LDD R3,Z+0 > 6795 9C32 MUL R3,R2 > 6796 0180 MOVW R16,R0 >(0519) TXPointer++; > 6797 01CF MOVW R24,R30 > 6798 9601 ADIW R24,1 > 6799 9390 1686 STS TXPointer+1,R25 > 679B 9380 1685 STS TXPointer,R24 > >and > >(0517) xc=(*TXPointer++)*MasterDimmer; > 6790 9110 0154 LDS R17,MasterDimmer > 6792 91E0 1685 LDS R30,TXPointer > 6794 91F0 1686 LDS R31,TXPointer+1 > 6796 9101 LD R16,Z+ > 6797 93F0 1686 STS TXPointer+1,R31 > 6799 93E0 1685 STS TXPointer,R30 > 679B 0301 MULSU R16,R17 > 679C 0150 MOVW R10,R0 > > >iccavr v7.18b > >-- >Tim Mitchell > > >_______________________________________________ >Icc-avr mailing list >Icc-avr@imagecraft.com >http://dragonsgate.net/mailman/listinfo/icc-avr // richard From richard at imagecraft.com Wed Jun 24 13:41:30 2009 From: richard at imagecraft.com (Richard Man) Date: Wed Jun 24 14:51:30 2009 Subject: [Icc-avr] 7.22 BETA3 Message-ID: <200906242151.n5OLpT3L053006@mail.imagecraft.com> Last beta before final release. For NEXT release (7.23), I am working on "unused function elimination" (PRO version only). http://www.imagecraft.com/pub/iccv7avr_v722_beta3.exe Readme: V7.22 IDE - Changed -D__ICC_VERSION=XXX where XXX is the version in integer form, e.g. 722. This allows easier conditional compilation. - XM128 bootloader was not emitting -xcall due to a typo. - Modified the "checking" options, now they are "Strict Checking" (equivalent to -A command line switch). "ANSI C Portability Conformance Checking" (equivalent to -A -A). This does draconian check on conditions that exceed ANSI C minimum limits (e.g. less than 512 variables) and is usually not needed. Compiler - Now always performs constant folding even if the constants *may* overflow (e.g. clock rate calculation) - Fixed XMEGA option not turning on enhanced core code generation error. - Added #pragma warning warning message emits warning message, similar to #warning #pragma ignore_unused_var name1 name2 ... This must appear inside a function and specifies the named arguments are intentionally unused so no warning message should be generated for them. - C Interrupt handlers for M256 or above now saves and restores EIND. - Fixed a latent typo bug where incorrect registers might be used with "mulsu" and "muls" instructions (they take limited register set). - Fixed a rare error where mulsu/muls may incorrectly be used in expressions as follows: unsigned int x; unsigned char *pi; unsigned char n; x = (*pi++) * n; // should use MUL and not MULSU/MULS Header Files - many updates for XMega etc. Library - Some floating point low level routines use R20-R23, making the library incompatible with the "Do Not Use R20..R23" option. This has been fixed. - Enabled fast scaled math versions of sinf and cosf // richard blog: 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 tim at sabretechnology.co.uk Thu Jun 25 01:05:11 2009 From: tim at sabretechnology.co.uk (Tim Mitchell) Date: Thu Jun 25 02:14:28 2009 Subject: [Icc-avr] Strange compilation result Message-ID: <04671BB8D269034BBC4BB6BA894867261650A2@sserver.SabreTechnology.local> ----Original Message---- From: icc-avr-bounces@imagecraft.com [mailto:icc-avr-bounces@imagecraft.com] On Behalf Of Richard Man Sent: 24 June 2009 20:45 To: icc-avr@imagecraft.com Subject: Re: [Icc-avr] Strange compilation result > Hmm... sounds like a bug. I am about to release 7.22, so > I will try to fix it before release. > Thanks Richard (and Johannes). I was starting to question my understanding of how C works... -- Tim Mitchell tim@sabretechnology.co.uk http://www.sabretechnology.co.uk Sabre Technology (Hull) Ltd, 3a Newlands Science Park, Hull HU6 7TQ Registered in England and Wales no.3131504 t:01482 801003 f:01482 801078 From richard-lists at imagecraft.com Thu Jun 25 01:16:47 2009 From: richard-lists at imagecraft.com (Richard Man) Date: Thu Jun 25 02:26:49 2009 Subject: [Icc-avr] Strange compilation result In-Reply-To: <04671BB8D269034BBC4BB6BA894867261650A2@sserver.SabreTechno logy.local> References: <04671BB8D269034BBC4BB6BA894867261650A2@sserver.SabreTechnology.local> Message-ID: <200906250926.n5P9QmMh062910@mail.imagecraft.com> You;re welcome. Of course it only shows up if the signness makes a difference, e.g. if both operands are unsigned, and both have the high bit on, then the 16 bit result is incorrect when using MULSU. At 01:05 AM 6/25/2009, Tim Mitchell wrote: >Thanks Richard (and Johannes). I was starting to question my >understanding of how C works... > >-- >Tim Mitchell >tim@sabretechnology.co.uk http://www.sabretechnology.co.uk >Sabre Technology (Hull) Ltd, 3a Newlands Science Park, Hull >HU6 7TQ Registered in England and Wales no.3131504 >t:01482 801003 f:01482 801078 > >_______________________________________________ >Icc-avr mailing list >Icc-avr@imagecraft.com >http://dragonsgate.net/mailman/listinfo/icc-avr // richard From richard at imagecraft.com Fri Jun 26 01:16:36 2009 From: richard at imagecraft.com (Richard Man) Date: Fri Jun 26 02:26:40 2009 Subject: [Icc-avr] ICCAVR 7.22 released Message-ID: <200906260926.n5Q9QeUK088352@mail.imagecraft.com> Change Log: V7.22 - June 25th 2009 IDE - Changed -D__ICC_VERSION=XXX where XXX is the version in integer form, e.g. 722. This allows easier conditional compilation. - XM128 bootloader was not emitting -xcall due to a typo. - Modified the "checking" options, now they are "Strict Checking" (equivalent to -A command line switch). "ANSI C Portability Conformance Checking" (equivalent to -A -A). This does draconian check on conditions that exceed ANSI C minimum limits (e.g. less than 512 variables) and is usually not needed. Compiler - Now always performs constant folding even if the constants *may* overflow (e.g. clock rate calculation) - Fixed XMEGA option not turning on enhanced core code generation error. - Added #pragma warning warning message emits warning message, similar to #warning #pragma ignore_unused_var name1 name2 ... This must appear inside a function and specifies the named arguments are intentionally unused so no warning message should be generated for them. - C Interrupt handlers for M256 or above now saves and restores EIND. - Fixed a latent typo bug where incorrect registers might be used with "mulsu" and "muls" instructions (they take limited register set). - Fixed a rare error where mulsu/muls may incorrectly be used in expressions as follows: unsigned int x; unsigned char *pi; unsigned char n; x = (*pi++) * n; // should use MUL and not MULSU/MULS Header Files - many updates for XMega etc. Library - Some floating point low level routines use R20-R23, making the library incompatible with the "Do Not Use R20..R23" option. This has been fixed. - Enabled fast scaled math versions of sinf and cosf // richard blog: 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 tim at sabretechnology.co.uk Fri Jun 26 01:36:31 2009 From: tim at sabretechnology.co.uk (Tim Mitchell) Date: Fri Jun 26 02:46:00 2009 Subject: [Icc-avr] ICCAVR 7.22 released Message-ID: <04671BB8D269034BBC4BB6BA894867261650C4@sserver.SabreTechnology.local> ----Original Message---- From: icc-avr-bounces@imagecraft.com [mailto:icc-avr-bounces@imagecraft.com] On Behalf Of Richard Man Sent: 26 June 2009 09:17 To: icc-avr@imagecraft.com; icc-announce@imagecraft.com Subject: [Icc-avr] ICCAVR 7.22 released Hi Richard, where can we download this, your website still says v7.21? -- Tim Mitchell tim@sabretechnology.co.uk http://www.sabretechnology.co.uk Sabre Technology (Hull) Ltd, 3a Newlands Science Park, Hull HU6 7TQ Registered in England and Wales no.3131504 t:01482 801003 f:01482 801078 From richard-lists at imagecraft.com Fri Jun 26 02:20:36 2009 From: richard-lists at imagecraft.com (Richard Man) Date: Fri Jun 26 03:30:42 2009 Subject: [Icc-avr] ICCAVR 7.22 released In-Reply-To: <04671BB8D269034BBC4BB6BA894867261650C4@sserver.SabreTechno logy.local> References: <04671BB8D269034BBC4BB6BA894867261650C4@sserver.SabreTechnology.local> Message-ID: <200906261030.n5QAUe7G090069@mail.imagecraft.com> I forgot to update the database entry :-) It's there... At 01:36 AM 6/26/2009, you wrote: >----Original Message---- >From: icc-avr-bounces@imagecraft.com >[mailto:icc-avr-bounces@imagecraft.com] On Behalf Of >Richard Man Sent: 26 June 2009 09:17 To: >icc-avr@imagecraft.com; icc-announce@imagecraft.com >Subject: [Icc-avr] ICCAVR 7.22 released > > >Hi Richard, where can we download this, your website still says v7.21? > // richard From j_baraclough at zetnet.co.uk Fri Jun 26 06:46:45 2009 From: j_baraclough at zetnet.co.uk (John Baraclough) Date: Fri Jun 26 07:56:12 2009 Subject: [Icc-avr] ICCAVR 7.22 released In-Reply-To: <200906261030.n5QAUe7G090069@mail.imagecraft.com> References: <04671BB8D269034BBC4BB6BA894867261650C4@sserver.SabreTechnology.local> <200906261030.n5QAUe7G090069@mail.imagecraft.com> Message-ID: <4A44D145.2050604@zetnet.co.uk> Hi Richard, AVG detects a spyware trojan in the created file 'irsetup.exe'. Please could you check before I install it. All the best for now, John Richard Man wrote: > I forgot to update the database entry :-) It's there... > > > At 01:36 AM 6/26/2009, you wrote: >> ----Original Message---- >> From: icc-avr-bounces@imagecraft.com >> [mailto:icc-avr-bounces@imagecraft.com] On Behalf Of >> Richard Man Sent: 26 June 2009 09:17 To: >> icc-avr@imagecraft.com; icc-announce@imagecraft.com >> Subject: [Icc-avr] ICCAVR 7.22 released >> >> >> Hi Richard, where can we download this, your website still says v7.21? >> > > // richard > > _______________________________________________ > Icc-avr mailing list > Icc-avr@imagecraft.com > http://dragonsgate.net/mailman/listinfo/icc-avr > > From bobgardner at aol.com Fri Jun 26 08:27:44 2009 From: bobgardner at aol.com (bobgardner@aol.com) Date: Fri Jun 26 09:37:33 2009 Subject: [Icc-avr] dragon-studio416build638-mega324p-iccv7avrv7.22 combo flaky? Message-ID: <8CBC489C961FDEE-6BC-125E@webmail-mf14.sysops.aol.com> Hello iccv7avr users. Has anyone burned a mega324p using a dragon?? Keep getting 'cant identify target'. I suppose there is some subtle differences between 324p, 324pv etc. Chip says 324P-20AU on it, include file is iom324pv.h. Stumped right now. Evidently I cant program a 324 with a regular old jtab and tell it its programming a mega32? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20090626/bfcdfbc0/attachment.html From richard-lists at imagecraft.com Fri Jun 26 12:14:18 2009 From: richard-lists at imagecraft.com (Richard Man) Date: Fri Jun 26 13:24:26 2009 Subject: [Icc-avr] ICCAVR 7.22 released In-Reply-To: <4A44D145.2050604@zetnet.co.uk> References: <04671BB8D269034BBC4BB6BA894867261650C4@sserver.SabreTechnology.local> <200906261030.n5QAUe7G090069@mail.imagecraft.com> <4A44D145.2050604@zetnet.co.uk> Message-ID: <200906262024.n5QKOO8E098868@mail.imagecraft.com> False positive. It's safe. Virus/spyware checkers are overly aggressive with program packers etc. A pain some times.... At 06:46 AM 6/26/2009, John Baraclough wrote: >Hi Richard, > >AVG detects a spyware trojan in the created file 'irsetup.exe'. >Please could you check before I install it. > >All the best for now, >John > // richard From j_baraclough at zetnet.co.uk Fri Jun 26 12:56:42 2009 From: j_baraclough at zetnet.co.uk (John Baraclough) Date: Fri Jun 26 14:06:11 2009 Subject: [Icc-avr] ICCAVR 7.22 released In-Reply-To: <200906262024.n5QKOO8E098868@mail.imagecraft.com> References: <04671BB8D269034BBC4BB6BA894867261650C4@sserver.SabreTechnology.local> <200906261030.n5QAUe7G090069@mail.imagecraft.com> <4A44D145.2050604@zetnet.co.uk> <200906262024.n5QKOO8E098868@mail.imagecraft.com> Message-ID: <4A4527FA.3040500@zetnet.co.uk> Thanks Richard. Now I just need to figure out how to stop AVG interfering with 'Setup' all the time. All the best for now, John Richard Man wrote: > False positive. It's safe. Virus/spyware checkers are overly > aggressive with program packers etc. A pain some times.... > > At 06:46 AM 6/26/2009, John Baraclough wrote: >> Hi Richard, >> >> AVG detects a spyware trojan in the created file 'irsetup.exe'. >> Please could you check before I install it. >> >> All the best for now, >> John >> > > // richard > > _______________________________________________ > Icc-avr mailing list > Icc-avr@imagecraft.com > http://dragonsgate.net/mailman/listinfo/icc-avr > >