From H.Fuerstenberger at glp.de Thu Dec 3 01:40:39 2009 From: H.Fuerstenberger at glp.de (=?iso-8859-1?Q?F=FCrstenberger=2C_Holger?=) Date: Thu Dec 3 02:53:26 2009 Subject: [Icc-avr] Re: Assembly Program calls C-Function (Johannes Assenbaum) In-Reply-To: <200911132002.nADK04JT087836@mail.imagecraft.com> References: <200911132002.nADK04JT087836@mail.imagecraft.com> Message-ID: <0870D146C1394543BA6773B969A091AFDDEB0E256D@glp-xchg-itt.intern.glp.de> Hi, just for your information. I get it working and it works really fine. In my solutions these are the steps: 1 call from Assembly 2. save all register 3. set SW-Stack in Y-Register (asm only use the HW-Stack) 4. call C-Function (optional parameter in r16..19) 5. optional return in 16..17 6. restore all register 7. continue in assembler Important is to set the Y-Register with a valid Software-Stackpointer. Best Regards Holger ------------------------------ Message: 2 Date: Fri, 13 Nov 2009 19:40:38 +0100 From: Johannes Assenbaum Subject: Re: [Icc-avr] Assembly Program calls C-Function To: icc-avr@imagecraft.com Message-ID: Content-Type: text/plain; charset=iso-8859-1 Hi Holger, calling C from asm is just the rear-view of icc-avr help/runtime architecture/assembly interface... That is in special: - C code is allowed to change any of preserved and volatile registers, which together are all registers. So, which registers you need to save and restore is depending on your asm application. In cases of doubt, always save all. - C arguments are (still and hopefully forever) 16bit aligned, with first 32 bit passed in r16..19 overflowing to software stack. - C return value is r16..19 if not void. And don't overlook to set scope of your C function global ;-) Best regards, Johannes > Hello developers, > i have a real special requirement in my software project. I want to add a existing > bootloader to an application. The application is written in assembly and I have > programmed a bootloader in C-Code with a special protocol. To reduce the work in > the application, the application recognizes the header of the protocol and calls > my Handler-function in C (bootloader-section), which is already written. > Which registers do I have to save and setup? > 1. Hardware Stack => Don'T Change anything > stores only the PC Counter > 2. Software Stack => Setup FramePointer (y-register) under the Hardware Stack with > enough space for hardware stack > 3. Save Registers R0-R31 (depends on the application) > I would appreciate any suggestions to this project. I quite familiar with the > ICC-Compiler, but I'm not sure if all relating things to the compiler was paid > attention. > Best regards, > Holger F?rstenberger > _______________________________________________ > 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 End of Icc-avr Digest, Vol 64, Issue 4 ************************************** From mcih at dataone.in Thu Dec 3 19:38:28 2009 From: mcih at dataone.in (MCIH POP) Date: Thu Dec 3 20:51:37 2009 Subject: [Icc-avr] Solution for Opening New AVR STudio 4.18 Projects for COF made from ICCAVR Message-ID: If you open the Project Wizard it has an [Open] button and if you use that to open a .cof file then it looks like it's working OK. I got it from AVR FREEKS forum. Seralathan From Albert.vanVeen at pertronic.co.nz Sun Dec 6 14:51:02 2009 From: Albert.vanVeen at pertronic.co.nz (Albert vanVeen) Date: Sun Dec 6 16:03:52 2009 Subject: [Icc-avr] Ports and pins In-Reply-To: References: Message-ID: <5F8515C5ED67B6439B4F93D7B5E08A3606400D@sbs.pertronic.local> I have used this in the past: setting/clearing port pins/bits. Suddenly I can't get it to work. In header file: #define SETBIT(port,pin) port |= 1< <5F8515C5ED67B6439B4F93D7B5E08A3606400D@sbs.pertronic.local> Message-ID: Albert, Here are the ones that I use: // // Bit Macros // // use of these with the OUTxxx parameters will cause errors // since readback gets the OUT register and if they are set // these will be sent back to be set (ok), but clr and tgl // do not produce the correct operation #define SETBIT(addr,bit) ((addr)|=(1< References: <5F8515C5ED67B6439B4F93D7B5E08A3606400D@sbs.pertronic.local> Message-ID: <5F8515C5ED67B6439B4F93D7B5E08A3606400E@sbs.pertronic.local> nice, but doesn't solve my compile problems. ________________________________ From: icc-avr-bounces@imagecraft.com [mailto:icc-avr-bounces@imagecraft.com] On Behalf Of Jim Hatley Sent: Monday, December 07, 2009 12:17 PM To: Discussion list for ICCAVR and ICCtiny Users. You do NOT needtosubscribeto icc-announce if you are a member of this. Subject: Re: [Icc-avr] Ports and pins Albert, Here are the ones that I use: // // Bit Macros // // use of these with the OUTxxx parameters will cause errors // since readback gets the OUT register and if they are set // these will be sent back to be set (ok), but clr and tgl // do not produce the correct operation #define SETBIT(addr,bit) ((addr)|=(1< To: Discussion list for ICCAVR and ICCtiny Users. You do NOT needtosubscribeto icc-announce if you are a member of this. Sent: Sunday, December 06, 2009 2:51 PM Subject: [Icc-avr] Ports and pins I have used this in the past: setting/clearing port pins/bits. Suddenly I can't get it to work. In header file: #define SETBIT(port,pin) port |= 1<<5F8515C5ED67B6439B4F93D7B5E08A3606400D@sbs.pertronic.local> <5F8515C5ED67B6439B4F93D7B5E08A3606400E@sbs.pertronic.local> Message-ID: <48839B0378C14F8B865AB03576DA1EAD@red7> I'm sure you have checked all these things and I may be wrong but ... from the error message it sounds like it didn't get the header file with the defines read, so that it thinks it is a function in the old style ... so I'd check if the defines for CLRBIT (etc) actually precede the code where they are used. You might try putting a define just preceding the function that uses it as a test ... Jim ----- Original Message ----- From: Albert vanVeen To: Discussion list for ICCAVR and ICCtiny Users. You do NOT needtosubscribeto icc-announce if you are a member of this. Sent: Sunday, December 06, 2009 4:21 PM Subject: RE: [Icc-avr] Ports and pins nice, but doesn't solve my compile problems. ------------------------------------------------------------------------------ From: icc-avr-bounces@imagecraft.com [mailto:icc-avr-bounces@imagecraft.com] On Behalf Of Jim Hatley Sent: Monday, December 07, 2009 12:17 PM To: Discussion list for ICCAVR and ICCtiny Users. You do NOT needtosubscribeto icc-announce if you are a member of this. Subject: Re: [Icc-avr] Ports and pins Albert, Here are the ones that I use: // // Bit Macros // // use of these with the OUTxxx parameters will cause errors // since readback gets the OUT register and if they are set // these will be sent back to be set (ok), but clr and tgl // do not produce the correct operation #define SETBIT(addr,bit) ((addr)|=(1< References: <5F8515C5ED67B6439B4F93D7B5E08A3606400D@sbs.pertronic.local><5F8515C5ED67B6439B4F93D7B5E08A3606400E@sbs.pertronic.local> <48839B0378C14F8B865AB03576DA1EAD@red7> Message-ID: <5F8515C5ED67B6439B4F93D7B5E08A3606400F@sbs.pertronic.local> I thought it would be something really dumm, but not that dumm! But yes, it was really that stupid: I missed a closing */ somewhere before the include, and just didn't spot it. A few hours of my time, plus ome time of yours, sorry, but thanks!!! Albert. ________________________________ From: icc-avr-bounces@imagecraft.com [mailto:icc-avr-bounces@imagecraft.com] On Behalf Of Jim Hatley Sent: Monday, December 07, 2009 02:29 PM To: Discussion list for ICCAVR and ICCtiny Users. You do NOT needtosubscribeto icc-announce if you are a member of this. Subject: Re: [Icc-avr] Ports and pins I'm sure you have checked all these things and I may be wrong but ... from the error message it sounds like it didn't get the header file with the defines read, so that it thinks it is a function in the old style ... so I'd check if the defines for CLRBIT (etc) actually precede the code where they are used. You might try putting a define just preceding the function that uses it as a test ... Jim ----- Original Message ----- From: Albert vanVeen To: Discussion list for ICCAVR and ICCtiny Users. You do NOT needtosubscribeto icc-announce if you are a member of this. Sent: Sunday, December 06, 2009 4:21 PM Subject: RE: [Icc-avr] Ports and pins nice, but doesn't solve my compile problems. ________________________________ From: icc-avr-bounces@imagecraft.com [mailto:icc-avr-bounces@imagecraft.com] On Behalf Of Jim Hatley Sent: Monday, December 07, 2009 12:17 PM To: Discussion list for ICCAVR and ICCtiny Users. You do NOT needtosubscribeto icc-announce if you are a member of this. Subject: Re: [Icc-avr] Ports and pins Albert, Here are the ones that I use: // // Bit Macros // // use of these with the OUTxxx parameters will cause errors // since readback gets the OUT register and if they are set // these will be sent back to be set (ok), but clr and tgl // do not produce the correct operation #define SETBIT(addr,bit) ((addr)|=(1< To: Discussion list for ICCAVR and ICCtiny Users. You do NOT needtosubscribeto icc-announce if you are a member of this. Sent: Sunday, December 06, 2009 2:51 PM Subject: [Icc-avr] Ports and pins I have used this in the past: setting/clearing port pins/bits. Suddenly I can't get it to work. In header file: #define SETBIT(port,pin) port |= 1< References: <200912070243.nB72hcoh045394@mail.imagecraft.com> Message-ID: <4B1C5EFA.304@verizon.net> > I have used this in the past: setting/clearing port pins/bits. > Suddenly I can't get it to work. > > In header file: > #define SETBIT(port,pin) port |= 1< #define CLRBIT(port,pin) port &= ~(1< Hi Has anybody seen a driver for CEC data in a HDMI connector? Regards Tom Steenberg -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20091207/f5dd0b8c/attachment.html From paul.aa9gg at gmail.com Mon Dec 7 06:25:36 2009 From: paul.aa9gg at gmail.com (Paul Mateer) Date: Mon Dec 7 16:36:16 2009 Subject: [Icc-avr] Ports and pins In-Reply-To: <5F8515C5ED67B6439B4F93D7B5E08A3606400F@sbs.pertronic.local> References: <5F8515C5ED67B6439B4F93D7B5E08A3606400D@sbs.pertronic.local> <5F8515C5ED67B6439B4F93D7B5E08A3606400E@sbs.pertronic.local> <48839B0378C14F8B865AB03576DA1EAD@red7> <5F8515C5ED67B6439B4F93D7B5E08A3606400F@sbs.pertronic.local> Message-ID: <20f5efc40912070625s17e43d6es82ac0b6a8d060853@mail.gmail.com> Don't you just hate that ! :^( On Sun, Dec 6, 2009 at 7:42 PM, Albert vanVeen wrote: > I thought it would be something really dumm, but not that dumm! > But yes, it was really that stupid: I missed a closing */ somewhere before > the include, and just didn't spot it. > A few hours of my time, plus ome time of yours, sorry, but thanks!!! > > Albert. > ________________________________ > From: icc-avr-bounces@imagecraft.com [mailto:icc-avr-bounces@imagecraft.com] > On Behalf Of Jim Hatley > Sent: Monday, December 07, 2009 02:29 PM > To: Discussion list for ICCAVR and ICCtiny Users. You do NOT > needtosubscribeto icc-announce if you are a member of this. > Subject: Re: [Icc-avr] Ports and pins > > I'm sure you have checked all these things and I may be wrong?but ... > > from the error message it sounds like it didn't get the header file with the > defines?read, so that it thinks it is a function in the old style ... so I'd > check if the defines for CLRBIT (etc) actually precede the code where they > are used. > > You might try putting a define just preceding the function that uses it as a > test ... > > Jim > > ----- Original Message ----- > From: Albert vanVeen > To: Discussion list for ICCAVR and ICCtiny Users. You do NOT > needtosubscribeto icc-announce if you are a member of this. > Sent: Sunday, December 06, 2009 4:21 PM > Subject: RE: [Icc-avr] Ports and pins > nice, but doesn't solve my compile problems. > > ________________________________ > From: icc-avr-bounces@imagecraft.com [mailto:icc-avr-bounces@imagecraft.com] > On Behalf Of Jim Hatley > Sent: Monday, December 07, 2009 12:17 PM > To: Discussion list for ICCAVR and ICCtiny Users. You do NOT > needtosubscribeto icc-announce if you are a member of this. > Subject: Re: [Icc-avr] Ports and pins > > Albert, > > Here are the ones that I use: > // > // Bit Macros > // > // use of these with the OUTxxx parameters will cause errors > // since readback gets the OUT register and if they are set > // these will be sent back to be set (ok), but clr and tgl > // do not produce the correct operation > #define SETBIT(addr,bit) ((addr)|=(1< #define CLRBIT(addr,bit) ((addr)&=(~(1< #define CHKBIT(addr,bit) ((addr)&(1< #define TGLBIT(addr,bit) ((addr)^=(1< // for use with OUTDIR, OUTSET, OUTCLR, OUTTGL > // where only the bit must be set to cause desired action > #define OUTSETBIT(addr,bit) (addr=(1< // > (the OUTSETBIT solved?problems which?showed up when programming the XMEGA > parts which have the OUTDIR, etc. registers) > > Jim > > ----- Original Message ----- > From: Albert vanVeen > To: Discussion list for ICCAVR and ICCtiny Users. You do NOT > needtosubscribeto icc-announce if you are a member of this. > Sent: Sunday, December 06, 2009 2:51 PM > Subject: [Icc-avr] Ports and pins > I have used this in the past: setting/clearing port pins/bits. > Suddenly I can't get it to work. > > In header file: > #define SETBIT(port,pin) port |= 1< #define CLRBIT(port,pin) port &= ~(1< > #define SCLK 2 // PTC TPIC shift clock > #define RCLK 1 // PTC TPIC reg strobe > > > Whenever I use anything like > CLRBIT(PORTC,RCLK); > > ICC reports an error: extraneous old-style parameter list > > What's going wrong here? > (note: it IS Monday morning) > > Albert. > > _______________________________________________ > Icc-avr mailing list > Icc-avr@imagecraft.com > http://dragonsgate.net/mailman/listinfo/icc-avr > > ________________________________ > > _______________________________________________ > Icc-avr mailing list > Icc-avr@imagecraft.com > http://dragonsgate.net/mailman/listinfo/icc-avr > > _______________________________________________ > Icc-avr mailing list > Icc-avr@imagecraft.com > http://dragonsgate.net/mailman/listinfo/icc-avr > -- Paul Mateer, AA9GG Elan Engineering Corp. www.elanengr.com NAQCC 3123, SKCC 4628, FPQRP 2003, CW 29 From ira at extrasensory.com Mon Dec 7 17:51:40 2009 From: ira at extrasensory.com (Ira) Date: Mon Dec 7 19:04:37 2009 Subject: [Icc-avr] Where did my 4 bytes go? In-Reply-To: <20f5efc40912070625s17e43d6es82ac0b6a8d060853@mail.gmail.co m> References: <5F8515C5ED67B6439B4F93D7B5E08A3606400D@sbs.pertronic.local> <5F8515C5ED67B6439B4F93D7B5E08A3606400E@sbs.pertronic.local> <48839B0378C14F8B865AB03576DA1EAD@red7> <5F8515C5ED67B6439B4F93D7B5E08A3606400F@sbs.pertronic.local> <20f5efc40912070625s17e43d6es82ac0b6a8d060853@mail.gmail.com> Message-ID: <0M9qme-1NOOoE2ghc-00BTjo@mrelay.perfora.net> once upon a time this program compiled and fit in a Mega48. Today I tried to re-compile it and failed. Why can't it fit 4092 bytes of code into 4096 bytes of flash? Ira fihx_coff -S2 @WINDOWSWITCHOFF48.lk !E (215): area 'text' not large enough want size 30 lo 4082 hi 4096 size 15 C:\iccv7avr\bin\imakew.exe: Error code 1 Done: there are error(s). Exit code: 1. Mon Dec 07 17:34:10 2009 Memory summary: flash size is 4096 bytes (4KB) flash used for - int vectors = 52 (0x34) bytes from 0x0000 to 0x0033 = 26 (0x1A) instruction words from 0x0000 to 0x0019 - constants = 28 (0x1C) bytes from 0x0034 to 0x004F - code = 4012 (0xFAC) bytes from 0x0050 to 0x0FFB = 2006 (0x7D6) instruction words) from 0x0028 to 0x07FD +- user code : 3292 (0xCDC) bytes from 0x0050 to 0x0D2B = 1646 (0x66E) instruction words) from 0x0028 to 0x0695 +- : 720 (0x2D0) bytes from 0x0D2C to 0x0FFB = 360 (0x168) instruction words) from 0x0696 to 0x07FD flash usage is 4092 bytes or 101.2%, leaving -48 bytes free From byron at inhep.com Tue Dec 8 00:36:43 2009 From: byron at inhep.com (Byron Loader) Date: Tue Dec 8 01:50:42 2009 Subject: [Icc-avr] CEC (Consumer Electronics Control) In-Reply-To: <008801ca7787$4cba2b80$e62e8280$@dk> References: <008801ca7787$4cba2b80$e62e8280$@dk> Message-ID: <004801ca77e1$9223d810$b66b8830$@com> Probably not what you're looking for but Renesas M16C/65 processors have a hardware module that does exactly what you want If the volumes are good they go for around Euro 3-00 http://eu.renesas.com/fmwk.jsp?cnt=m16c65_root.jsp&fp=/products/mpumcu/m16c_ family/m16c60_series/m16c65_group/ Best Regards, From: icc-avr-bounces@imagecraft.com [mailto:icc-avr-bounces@imagecraft.com] On Behalf Of Tom Steenberg Sent: Monday, December 07, 2009 11:51 PM To: icc-avr@imagecraft.com Subject: [Icc-avr] CEC (Consumer Electronics Control) Hi Has anybody seen a driver for CEC data in a HDMI connector? Regards Tom Steenberg -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20091208/d63bd9e9/attachment.html From richard-lists at imagecraft.com Tue Dec 8 03:13:31 2009 From: richard-lists at imagecraft.com (Richard Man) Date: Tue Dec 8 04:28:11 2009 Subject: [Icc-avr] Where did my 4 bytes go? In-Reply-To: <0M9qme-1NOOoE2ghc-00BTjo@mrelay.perfora.net> References: <5F8515C5ED67B6439B4F93D7B5E08A3606400D@sbs.pertronic.local> <5F8515C5ED67B6439B4F93D7B5E08A3606400E@sbs.pertronic.local> <48839B0378C14F8B865AB03576DA1EAD@red7> <5F8515C5ED67B6439B4F93D7B5E08A3606400F@sbs.pertronic.local> <20f5efc40912070625s17e43d6es82ac0b6a8d060853@mail.gmail.com> <0M9qme-1NOOoE2ghc-00BTjo@mrelay.perfora.net> Message-ID: <200912081228.nB8CSBRl066553@mail.imagecraft.com> Did you change compiler? If so, there can be a number of factors, e.g. different libraries, compiler some stuff differently etc. If you need a copy of the older compiler, contact me off-list and I will load it up to the web server. At 05:51 PM 12/7/2009, Ira wrote: >once upon a time this program compiled and fit in a Mega48. Today I >tried to re-compile it and failed. > >Why can't it fit 4092 bytes of code into 4096 bytes of flash? > >Ira > > >fihx_coff -S2 @WINDOWSWITCHOFF48.lk >!E (215): area 'text' not large enough >want size 30 >lo 4082 hi 4096 size 15 >C:\iccv7avr\bin\imakew.exe: Error code 1 >Done: there are error(s). Exit code: 1. Mon Dec 07 17:34:10 2009 > // richard // http://rfman.wordpress.com // http://www.imagecraft.com/pub/Portfolio09/ From ira at extrasensory.com Tue Dec 8 09:56:27 2009 From: ira at extrasensory.com (Ira) Date: Tue Dec 8 11:09:25 2009 Subject: [Icc-avr] Where did my 4 bytes go? In-Reply-To: <200912081228.nB8CSBRl066553@mail.imagecraft.com> References: <5F8515C5ED67B6439B4F93D7B5E08A3606400D@sbs.pertronic.local> <5F8515C5ED67B6439B4F93D7B5E08A3606400E@sbs.pertronic.local> <48839B0378C14F8B865AB03576DA1EAD@red7> <5F8515C5ED67B6439B4F93D7B5E08A3606400F@sbs.pertronic.local> <20f5efc40912070625s17e43d6es82ac0b6a8d060853@mail.gmail.com> <0M9qme-1NOOoE2ghc-00BTjo@mrelay.perfora.net> <200912081228.nB8CSBRl066553@mail.imagecraft.com> Message-ID: <0Lp4oe-1NlcHt1vFM-00f02d@mrelay.perfora.net> At 03:13 AM 12/8/2009, you wrote: >Did you change compiler? If so, there can be a number of factors, >e.g. different libraries, compiler some stuff differently etc. > >If you need a copy of the older compiler, contact me off-list and I >will load it up to the web server. > > >At 05:51 PM 12/7/2009, Ira wrote: >>once upon a time this program compiled and fit in a Mega48. Today I >>tried to re-compile it and failed. >> >>Why can't it fit 4092 bytes of code into 4096 bytes of flash? Well, just upgraded to a newer version of the same compiler. But it still begs the question, why does it claim that 4092 is bigger than 4096? Ira From ira at extrasensory.com Tue Dec 8 09:57:53 2009 From: ira at extrasensory.com (Ira) Date: Tue Dec 8 11:10:50 2009 Subject: [Icc-avr] Where did my 4 bytes go? Message-ID: <0MBVXy-1NPFqb1sxC-00AuvE@mrelay.perfora.net> At 03:13 AM 12/8/2009, you wrote: >Did you change compiler? If so, there can be a number of factors, >e.g. different libraries, compiler some stuff differently etc. > >If you need a copy of the older compiler, contact me off-list and I >will load it up to the web server. > > >At 05:51 PM 12/7/2009, Ira wrote: >>once upon a time this program compiled and fit in a Mega48. Today I >>tried to re-compile it and failed. >> >>Why can't it fit 4092 bytes of code into 4096 bytes of flash? Well, just upgraded to a newer version of the same compiler. But it still begs the question, why does it claim that 4092 is bigger than 4096? And the forgotten question, how many more bytes of code do I have to save before it will fit again? Ira From hr_iccavr at srel.de Tue Dec 8 11:11:05 2009 From: hr_iccavr at srel.de (Hartmut Reinke) Date: Tue Dec 8 12:24:00 2009 Subject: [Icc-avr] Where did my 4 bytes go? In-Reply-To: <0MBVXy-1NPFqb1sxC-00AuvE@mrelay.perfora.net> References: <0MBVXy-1NPFqb1sxC-00AuvE@mrelay.perfora.net> Message-ID: <4B1EA4C9.9080208@srel.de> Ira schrieb: > At 03:13 AM 12/8/2009, you wrote: >> Did you change compiler? If so, there can be a number of factors, e.g. >> different libraries, compiler some stuff differently etc. >> >> If you need a copy of the older compiler, contact me off-list and I >> will load it up to the web server. >> >> >> At 05:51 PM 12/7/2009, Ira wrote: >>> once upon a time this program compiled and fit in a Mega48. Today I >>> tried to re-compile it and failed. >>> >>> Why can't it fit 4092 bytes of code into 4096 bytes of flash? Hello Ira, Your Linker reported: >> flash usage is 4092 bytes or 101.2%, leaving -48 bytes free I had the same Problem some time ago. I was confused by the Linker output. As far as i can remember, the Linker showed the size of all parts, it could make fit into the available space. In your case this was 4092 Bytes. There seems to be another demand for 48 bytes, which did NOT fit in, although the linker did not tell, which module it had to leave outside. 48 Bytes is 1,17% of the whole flash, so the whole usage would sum up to 101,2% (rounded to 1/10%) as indicated. I think, you have to save at least 44 bytes to make it fit into 4096 Bytes. regards Hartmut From jassenbaum at htp-tel.de Tue Dec 8 11:18:37 2009 From: jassenbaum at htp-tel.de (Johannes Assenbaum) Date: Tue Dec 8 12:31:28 2009 Subject: [Icc-avr] Where did my 4 bytes go? References: <0MBVXy-1NPFqb1sxC-00AuvE@mrelay.perfora.net> Message-ID: 1: Looks like a bug in Map file summary. Would you please send me you project, or at least .lk .lst and .mp files off-list? 2: You can calculate the bytes to save it from the numbers in error message: "!E (215): area 'text' not large enough want size 30 lo 4082 hi 4096 size 15" = - ((hi-1) - lo) in this case: 30-((4096-1)-4082 = 16 bytes or 8 instruction words to save. Btw: linker calculates size one to large. Best regards, Johannes > At 03:13 AM 12/8/2009, you wrote: >>Did you change compiler? If so, there can be a number of factors, >>e.g. different libraries, compiler some stuff differently etc. >> >>If you need a copy of the older compiler, contact me off-list and I >>will load it up to the web server. >> >> >>At 05:51 PM 12/7/2009, Ira wrote: >>>once upon a time this program compiled and fit in a Mega48. Today I >>>tried to re-compile it and failed. >>> >>>Why can't it fit 4092 bytes of code into 4096 bytes of flash? > Well, just upgraded to a newer version of the same compiler. But it > still begs the question, why does it claim that 4092 is bigger than 4096? > And the forgotten question, how many more bytes of code do I have to > save before it will fit again? > Ira > _______________________________________________ > Icc-avr mailing list > Icc-avr@imagecraft.com > http://dragonsgate.net/mailman/listinfo/icc-avr From ira at extrasensory.com Tue Dec 8 12:09:00 2009 From: ira at extrasensory.com (Ira) Date: Tue Dec 8 13:21:58 2009 Subject: [Icc-avr] Where did my 4 bytes go? In-Reply-To: <4B1EA4C9.9080208@srel.de> References: <0MBVXy-1NPFqb1sxC-00AuvE@mrelay.perfora.net> <4B1EA4C9.9080208@srel.de> Message-ID: <0MbwJa-1NY7aG3hFG-00JkNP@mrelay.perfora.net> At 11:11 AM 12/8/2009, you wrote: >Hello Ira, > >Your Linker reported: > >> flash usage is 4092 bytes or 101.2%, leaving -48 bytes free > >I had the same Problem some time ago. I was confused by the Linker output. >As far as i can remember, the Linker showed the size of all parts, it could >make fit into the available space. >In your case this was 4092 Bytes. >There seems to be another demand for 48 bytes, which did NOT fit in, >although the linker did not tell, which module it had to leave outside. >48 Bytes is 1,17% of the whole flash, so the whole usage would >sum up to 101,2% (rounded to 1/10%) as indicated. > >I think, you have to save at least 44 bytes to make it fit into 4096 Bytes. Well, something must be very wrong as I just started commenting out lines in my init code like "ADSRA=0x00" and it only took 2 lines being commented out to make it fit again. I think that's more like 8 bytes than 44 bytes. Ira From jassenbaum at htp-tel.de Tue Dec 8 14:50:37 2009 From: jassenbaum at htp-tel.de (Johannes Assenbaum) Date: Tue Dec 8 16:03:28 2009 Subject: [Icc-avr] Where did my 4 bytes go? References: <0MBVXy-1NPFqb1sxC-00AuvE@mrelay.perfora.net> <4B1EA4C9.9080208@srel.de> <0MbwJa-1NY7aG3hFG-00JkNP@mrelay.perfora.net> Message-ID: I see that there is something wrong with map file summary and I already started to fix it. Anyway please don't worry about code. Map file summary only reads but never writes linker output files. Best regards, Johannes > At 11:11 AM 12/8/2009, you wrote: >>Hello Ira, >> >>Your Linker reported: >> >> flash usage is 4092 bytes or 101.2%, leaving -48 bytes free >> >>I had the same Problem some time ago. I was confused by the Linker output. >>As far as i can remember, the Linker showed the size of all parts, it could >>make fit into the available space. >>In your case this was 4092 Bytes. >>There seems to be another demand for 48 bytes, which did NOT fit in, >>although the linker did not tell, which module it had to leave outside. >>48 Bytes is 1,17% of the whole flash, so the whole usage would >>sum up to 101,2% (rounded to 1/10%) as indicated. >> >>I think, you have to save at least 44 bytes to make it fit into 4096 Bytes. > Well, something must be very wrong as I just started commenting out > lines in my init code like "ADSRA=0x00" and it only took 2 lines > being commented out to make it fit again. I think that's more like 8 > bytes than 44 bytes. > Ira > _______________________________________________ > Icc-avr mailing list > Icc-avr@imagecraft.com > http://dragonsgate.net/mailman/listinfo/icc-avr From ira at extrasensory.com Tue Dec 8 15:15:42 2009 From: ira at extrasensory.com (Ira) Date: Tue Dec 8 16:28:40 2009 Subject: [Icc-avr] Where did my 4 bytes go? In-Reply-To: References: <0MBVXy-1NPFqb1sxC-00AuvE@mrelay.perfora.net> <4B1EA4C9.9080208@srel.de> <0MbwJa-1NY7aG3hFG-00JkNP@mrelay.perfora.net> Message-ID: <0LiRym-1NntfM0jFs-00cng5@mrelay.perfora.net> At 02:50 PM 12/8/2009, you wrote: >I see that there is something wrong with map file summary and I >already started to fix it. > >Anyway please don't worry about code. Map file summary only reads >but never writes linker output files. Sorry, I wasn't worried about the code, only trying to figure out how many bytes I needed to find to make it fit again. I put one function call from the init code in-line and commented out a duplicate line of code in the same place and it's happy again. Ira From bobgardner at aol.com Tue Dec 8 17:45:05 2009 From: bobgardner at aol.com (bobgardner@aol.com) Date: Tue Dec 8 18:58:28 2009 Subject: [Icc-avr] Where did my 4 bytes go? In-Reply-To: <0MbwJa-1NY7aG3hFG-00JkNP@mrelay.perfora.net> References: <0MBVXy-1NPFqb1sxC-00AuvE@mrelay.perfora.net><4B1EA4C9.9080208@srel.de> <0MbwJa-1NY7aG3hFG-00JkNP@mrelay.perfora.net> Message-ID: <8CC46885DDEFB1D-2B34-924F@webmail-d044.sysops.aol.com> There is a 'checklist' of stuff to do to shrink those last couple of bytes into the flash. Do you have strings? If so, you need to check 'strings in flash'. This saves ram more than flash. Do you do printf? You have a choice of 3 sizes of printf. I click on the 'view listing file and if it looks like there are a lot of places where two instructions are used to load and store whazt could be a one byte variable, then go back and declare that variable as an unsigned char instead of an int. The easiest way to stuff 110lbs of code into a flash that hold 100 lbs is get the procompiler and turn on the global optimizer. Saved my arse a couple of times already. If all else fails, attach the source code to a message and declare that 'this code can not be shrunk anymore' and stand back. -----Original Message----- From: Ira Sent: Tue, Dec 8, 2009 3:09 pm Subject: Re: [Icc-avr] Where did my 4 bytes go? At 11:11 AM 12/8/2009, you wrote: >Hello Ira, > >Your Linker reported: > >> flash usage is 4092 bytes or 101.2%, leaving -48 bytes free > >I had the same Problem some time ago. I was confused by the Linker output. >As far as i can remember, the Linker showed the size of all parts, it could >make fit into the available space. >In your case this was 4092 Bytes. >There seems to be another demand for 48 bytes, which did NOT fit in, >although the linker did not tell, which module it had to leave outside. >48 Bytes is 1,17% of the whole flash, so the whole usage would >sum up to 101,2% (rounded to 1/10%) as indicated. > >I think, you have to save at least 44 bytes to make it fit into 4096 Bytes. Well, something must be very wrong as I just started commenting out lines in my init code like "ADSRA=0x00" and it only took 2 lines being commented out to make it fit again. I think that's more like 8 bytes than 44 bytes. Ira _______________________________________________ Icc-avr mailing list Icc-avr@imagecraft.com http://dragonsgate.net/mailman/listinfo/icc-avr -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20091208/59dd0834/attachment.html From ira at extrasensory.com Tue Dec 8 20:06:10 2009 From: ira at extrasensory.com (Ira) Date: Tue Dec 8 21:19:22 2009 Subject: [Icc-avr] Where did my 4 bytes go? In-Reply-To: <8CC46885DDEFB1D-2B34-924F@webmail-d044.sysops.aol.com> References: <0MBVXy-1NPFqb1sxC-00AuvE@mrelay.perfora.net> <4B1EA4C9.9080208@srel.de> <0MbwJa-1NY7aG3hFG-00JkNP@mrelay.perfora.net> <8CC46885DDEFB1D-2B34-924F@webmail-d044.sysops.aol.com> Message-ID: <0MY8xk-1NeGvO0vIm-00VJbS@mrelay.perfora.net> An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20091208/fb1202cb/attachment-0001.html From bobgardner at aol.com Tue Dec 8 20:36:41 2009 From: bobgardner at aol.com (bobgardner@aol.com) Date: Tue Dec 8 21:49:47 2009 Subject: [Icc-avr] Where did my 4 bytes go? In-Reply-To: <0MY8xk-1NeGvO0vIm-00VJbS@mrelay.perfora.net> References: <0MBVXy-1NPFqb1sxC-00AuvE@mrelay.perfora.net><4B1EA4C9.9080208@srel.de><0MbwJa-1NY7aG3hFG-00JkNP@mrelay.perfora.net><8CC46885DDEFB1D-2B34-924F@webmail-d044.sysops.aol.com> <0MY8xk-1NeGvO0vIm-00VJbS@mrelay.perfora.net> Message-ID: <8CC46A05668778A-4F80-CA7E@webmail-m068.sysops.aol.com> I dont think anyone would expect the additional expense of the pro compiler to pay for itself by saving money on one job. Hopefully, a professional programmer using professional tools over a period of years will not only save enough to pay for his compiler, but for his car, house, and kids college. Unless the democrats stay in office. -----Original Message----- From: Ira Sent: Tue, Dec 8, 2009 11:06 pm Subject: Re: [Icc-avr] Where did my 4 bytes go? At 05:45 PM 12/8/2009, you wrote: There is a 'checklist' of stuff to do to shrink those last couple of bytes into the flash. Do you have strings? If so, you need to check 'strings in flash'. This saves ram more than flash. Do you do printf? You have a choice of 3 sizes of printf. I click on the 'view listing file and if it looks like there are a lot of places where two instructions are used to load and store whazt could be a one byte variable, then go back and declare that variable as an unsigned char instead of an int. The easiest way to stuff 110lbs of code into a flash that hold 100 lbs is get the procompiler and turn on the global optimizer. Saved my arse a couple of times already. If all else fails, attach the source code to a message and declare that 'this code can not be shrunk anymore' and stand back. The Pro Compiler is just way to much money for this budget, maybe if some of this stuff starts selling. I was able to fix it by in-lining one function that was only called one time. I'm sure converting one of the single line ones to a #define would find a bit more. The code works perfectly, no reason to touch it except I was sent a new production sample that didn't work and tried compiling the project out of habit. Turns out instead of getting a 7Segment LED of a different color like they thought they were doing, they got the same color but common anode instead of common cathode. So, the fix turned out to be a bit of SMT rework and nothing to do with the code. it doesn't take much to cause a problem, I've had to find extra bytes here and there during development to be able to keep adding features. I'm sure someone smarter than me could find a free 100 bytes or maybe a lot more, but it fits, we're building the second 500 and to the best of my knowledge none have ever been returned as defective. Not bad for something that lives under the hood of a car and attaches to ignition coils. I'm always still surprised no one's ever fried one by zapping it with the secondary or connecting it to the primary of a CDI. Ira The Pro Compiler is just way to much money for this budget, maybe if some of this stuff starts selling. I was able to fix it by in-lining one function that was only called one time. I'm sure converting one of the single line ones to a #define would find a bit more. The code works perfectly, no reason to touch it except I was sent a new production sample that didn't work and tried compiling the project out of habit. Turns out instead of getting a 7Segment LED of a different color like they thought they were doing, they got the same color but common anode instead of common cathode. So, the fix turned out to be a bit of SMT rework and nothing to do with the code. it doesn't take much to cause a problem, I've had to find extra bytes here and there during development to be able to keep adding features. I'm sure someone smarter than me could find a free 100 bytes or maybe a lot more, but it fits, we're building the second 500 and to the best of my knowledge none have ever been returned as defective. Not bad for something that lives under the hood of a car and attaches to ignition coils. I'm always still surprised no one's ever fried one by zapping it with the secondary or connecting it to the primary of a CDI. Ira _______________________________________________ cc-avr mailing list cc-avr@imagecraft.com ttp://dragonsgate.net/mailman/listinfo/icc-avr -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20091208/efd121af/attachment.html From ira at extrasensory.com Tue Dec 8 21:37:17 2009 From: ira at extrasensory.com (Ira) Date: Tue Dec 8 22:50:22 2009 Subject: [Icc-avr] Where did my 4 bytes go? In-Reply-To: <8CC46A05668778A-4F80-CA7E@webmail-m068.sysops.aol.com> References: <0MBVXy-1NPFqb1sxC-00AuvE@mrelay.perfora.net> <4B1EA4C9.9080208@srel.de> <0MbwJa-1NY7aG3hFG-00JkNP@mrelay.perfora.net> <8CC46885DDEFB1D-2B34-924F@webmail-d044.sysops.aol.com> <0MY8xk-1NeGvO0vIm-00VJbS@mrelay.perfora.net> <8CC46A05668778A-4F80-CA7E@webmail-m068.sysops.aol.com> Message-ID: <0Lp4kW-1Nm3g62MU8-00eyc9@mrelay.perfora.net> An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20091208/b41c1980/attachment.html From tim at sabretechnology.co.uk Wed Dec 9 04:10:50 2009 From: tim at sabretechnology.co.uk (Tim Mitchell) Date: Wed Dec 9 05:23:47 2009 Subject: [Icc-avr] Trying to load from a flash table in assembler Message-ID: <04671BB8D269034BBC4BB6BA894867261CBFA7@sserver.SabreTechnology.local> Hi, I am trying to write an assembler module which loads a value from a table in flash. As far as I can see it should be like this... ldi zl,<(pwm_time*2) ldi zh,>(pwm_time*2) lpm r16,z pwm_time: .db 16,16,16,16,16,16,16,16,16,16,16,16,16,16,16,16 but the assembler complains about the "pwm_time*2" - Absolute expression expected. Can't see where I'm going wrong... it's probably something really obvious. -- Tim Mitchell From jassenbaum at htp-tel.de Wed Dec 9 10:40:54 2009 From: jassenbaum at htp-tel.de (Johannes Assenbaum) Date: Wed Dec 9 11:53:47 2009 Subject: [Icc-avr] Trying to load from a flash table in assembler References: <04671BB8D269034BBC4BB6BA894867261CBFA7@sserver.SabreTechnology.local> Message-ID: Besides that assembler cannot calculate "pwm_time*2" in this context, you don't need address correction. Addresses of data are always byte addresses, even in flash. Best regards, Johannes > Hi, I am trying to write an assembler module which loads a value from a > table in flash. > As far as I can see it should be like this... > ldi zl,<(pwm_time*2) > ldi zh,>(pwm_time*2) > lpm r16,z > pwm_time: > .db 16,16,16,16,16,16,16,16,16,16,16,16,16,16,16,16 > but the assembler complains about the "pwm_time*2" - Absolute expression > expected. > Can't see where I'm going wrong... it's probably something really > obvious. > -- > Tim Mitchell > _______________________________________________ > Icc-avr mailing list > Icc-avr@imagecraft.com > http://dragonsgate.net/mailman/listinfo/icc-avr From Albert.vanVeen at pertronic.co.nz Wed Dec 9 11:20:00 2009 From: Albert.vanVeen at pertronic.co.nz (Albert vanVeen) Date: Wed Dec 9 12:32:53 2009 Subject: [Icc-avr] Where did my 4 bytes go? In-Reply-To: <0MY8xk-1NeGvO0vIm-00VJbS@mrelay.perfora.net> References: <0MBVXy-1NPFqb1sxC-00AuvE@mrelay.perfora.net><4B1EA4C9.9080208@srel.de><0MbwJa-1NY7aG3hFG-00JkNP@mrelay.perfora.net><8CC46885DDEFB1D-2B34-924F@webmail-d044.sysops.aol.com> <0MY8xk-1NeGvO0vIm-00VJbS@mrelay.perfora.net> Message-ID: <5F8515C5ED67B6439B4F93D7B5E08A36064012@sbs.pertronic.local> I remember building that without software (or micro) some 35 years ago into old VW's; worked briliantly. The ultimate optimisation: 0 bytes! Albert ________________________________ From: icc-avr-bounces@imagecraft.com [mailto:icc-avr-bounces@imagecraft.com] On Behalf Of Ira Sent: Wednesday, December 09, 2009 05:06 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] Where did my 4 bytes go? At 05:45 PM 12/8/2009, you wrote: There is a 'checklist' of stuff to do to shrink those last couple of bytes into the flash. Do you have strings? If so, you need to check 'strings in flash'. This saves ram more than flash. Do you do printf? You have a choice of 3 sizes of printf. I click on the 'view listing file and if it looks like there are a lot of places where two instructions are used to load and store whazt could be a one byte variable, then go back and declare that variable as an unsigned char instead of an int. The easiest way to stuff 110lbs of code into a flash that hold 100 lbs is get the procompiler and turn on the global optimizer. Saved my arse a couple of times already. If all else fails, attach the source code to a message and declare that 'this code can not be shrunk anymore' and stand back. The Pro Compiler is just way to much money for this budget, maybe if some of this stuff starts selling. I was able to fix it by in-lining one function that was only called one time. I'm sure converting one of the single line ones to a #define would find a bit more. The code works perfectly, no reason to touch it except I was sent a new production sample that didn't work and tried compiling the project out of habit. Turns out instead of getting a 7Segment LED of a different color like they thought they were doing, they got the same color but common anode instead of common cathode. So, the fix turned out to be a bit of SMT rework and nothing to do with the code. it doesn't take much to cause a problem, I've had to find extra bytes here and there during development to be able to keep adding features. I'm sure someone smarter than me could find a free 100 bytes or maybe a lot more, but it fits, we're building the second 500 and to the best of my knowledge none have ever been returned as defective. Not bad for something that lives under the hood of a car and attaches to ignition coils. I'm always still surprised no one's ever fried one by zapping it with the secondary or connecting it to the primary of a CDI. Ira -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20091210/c5ee4a69/attachment.html From tony at encoreelectronics.com Wed Dec 9 12:21:02 2009 From: tony at encoreelectronics.com (Tony Karavidas) Date: Wed Dec 9 13:34:21 2009 Subject: [Icc-avr] Where did my 4 bytes go? In-Reply-To: <8CC46885DDEFB1D-2B34-924F@webmail-d044.sysops.aol.com> References: <0MBVXy-1NPFqb1sxC-00AuvE@mrelay.perfora.net><4B1EA4C9.9080208@srel.de> <0MbwJa-1NY7aG3hFG-00JkNP@mrelay.perfora.net> <8CC46885DDEFB1D-2B34-924F@webmail-d044.sysops.aol.com> Message-ID: This is the reason I don't size my processors so close to the limit. Maybe your code has grown beyond your expectations, but you don't seem to have the sales volume to put up with such headaches. What are you going to do in 6 months when you have to tweak the code again? If it were me, the next bigger processor would go in there. It looks like you're selling stuff for a few hundred dollars and could absorb the slightly more expensive processor. It would make life easier. Tony Sent from my iphone On Dec 8, 2009, at 5:45 PM, bobgardner@aol.com wrote: > There is a 'checklist' of stuff to do to shrink those last couple of > bytes into the flash. Do you have strings? If so, you need to check > 'strings in flash'. This saves ram more than flash. Do you do > printf? You have a choice of 3 sizes of printf. I click on the 'view > listing file and if it looks like there are a lot of places where > two instructions are used to load and store whazt could be a one > byte variable, then go back and declare that variable as an unsigned > char instead of an int. The easiest way to stuff 110lbs of code into > a flash that hold 100 lbs is get the procompiler and turn on the > global optimizer. Saved my arse a couple of times already. If all > else fails, attach the source code to a message and declare that > 'this code can not be shrunk anymore' and stand back. > > > -----Original Message----- > From: Ira > Sent: Tue, Dec 8, 2009 3:09 pm > Subject: Re: [Icc-avr] Where did my 4 bytes go? > > At 11:11 AM 12/8/2009, you wrote: > >Hello Ira, > > > >Your Linker reported: > > >> flash usage is 4092 bytes or 101.2%, leaving -48 bytes free > > > >I had the same Problem some time ago. I was confused by the Linker > output. > >As far as i can remember, the Linker showed the size of all parts, > it could > >make fit into the available space. > >In your case this was 4092 Bytes. > >There seems to be another demand for 48 bytes, which did NOT fit in, > >although the linker did not tell, which module it had to leave > outside. > >48 Bytes is 1,17% of the whole flash, so the whole usage would > >sum up to 101,2% (rounded to 1/10%) as indicated. > > > >I think, you have to save at least 44 bytes to make it fit into > 4096 Bytes. > > Well, something must be very wrong as I just started commenting out > lines in my init code like "ADSRA=0x00" and it only took 2 lines > being commented out to make it fit again. I think that's more like 8 > bytes than 44 bytes. > > Ira > _______________________________________________ > Icc-avr mailing list > Icc-avr@imagecraft.com > http://dragonsgate.net/mailman/listinfo/icc-avr > _______________________________________________ > Icc-avr mailing list > Icc-avr@imagecraft.com > http://dragonsgate.net/mailman/listinfo/icc-avr -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20091209/47d49d13/attachment.html From ira at extrasensory.com Wed Dec 9 17:57:53 2009 From: ira at extrasensory.com (Ira) Date: Wed Dec 9 19:12:56 2009 Subject: [Icc-avr] Where did my 4 bytes go? In-Reply-To: References: <0MBVXy-1NPFqb1sxC-00AuvE@mrelay.perfora.net> <4B1EA4C9.9080208@srel.de> <0MbwJa-1NY7aG3hFG-00JkNP@mrelay.perfora.net> <8CC46885DDEFB1D-2B34-924F@webmail-d044.sysops.aol.com> Message-ID: <0Lg2Cp-1NqXQO1V9P-00pC9f@mrelay.perfora.net> At 12:21 PM 12/9/2009, you wrote: >This is the reason I don't size my processors so close to the >limit. Maybe your code has grown beyond your expectations, but you >don't seem to have the sales volume to put up with such >headaches. What are you going to do in 6 months when you have to >tweak the code again? If it were me, the next bigger processor would >go in there. It looks like you're selling stuff for a few hundred >dollars and could absorb the slightly more expensive processor. It >would make life easier. But it fit when I programmed it, and given the hardware there's no more features we can think of or implement so it seems silly to go to an Mega416 or what ever one up from a Mega48 is, just because the compiler changed and took 6 more bytes. Ira From tony at encoreelectronics.com Wed Dec 9 20:27:22 2009 From: tony at encoreelectronics.com (Tony Karavidas) Date: Wed Dec 9 21:40:13 2009 Subject: [Icc-avr] Where did my 4 bytes go? In-Reply-To: <0Lg2Cp-1NqXQO1V9P-00pC9f@mrelay.perfora.net> References: <0MBVXy-1NPFqb1sxC-00AuvE@mrelay.perfora.net><4B1EA4C9.9080208@srel.de><0MbwJa-1NY7aG3hFG-00JkNP@mrelay.perfora.net><8CC46885DDEFB1D-2B34-924F@webmail-d044.sysops.aol.com> <0Lg2Cp-1NqXQO1V9P-00pC9f@mrelay.perfora.net> Message-ID: Silly? Let's see, a 'typical' mega48 is $1.84 (q=100) A Mega88 has twice the FLASH and twice the RAM, and is $2.32. You've sold 500 units and are building your 2nd batch of 500 as you mentioned. So to save $240, you are struggling with getting the code to fit each time you touch the code. If you were building millions of units, I would say you're absolutely doing the right thing. I don't know how much you make, but around here, that's 2 to 3 hours of labor. To me, that is not smart engineering or smart business practices. The days of being super clever to get 99% utilization of a processor are long gone. Processors are cheap, engineering is not. Good luck, Tony -----Original Message----- From: icc-avr-bounces@imagecraft.com [mailto:icc-avr-bounces@imagecraft.com] On Behalf Of Ira Sent: Wednesday, December 09, 2009 5:58 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] Where did my 4 bytes go? At 12:21 PM 12/9/2009, you wrote: >This is the reason I don't size my processors so close to the limit. >Maybe your code has grown beyond your expectations, but you don't seem >to have the sales volume to put up with such headaches. What are you >going to do in 6 months when you have to tweak the code again? If it >were me, the next bigger processor would go in there. It looks like >you're selling stuff for a few hundred dollars and could absorb the >slightly more expensive processor. It would make life easier. But it fit when I programmed it, and given the hardware there's no more features we can think of or implement so it seems silly to go to an Mega416 or what ever one up from a Mega48 is, just because the compiler changed and took 6 more bytes. Ira _______________________________________________ Icc-avr mailing list Icc-avr@imagecraft.com http://dragonsgate.net/mailman/listinfo/icc-avr From ira at extrasensory.com Wed Dec 9 21:46:31 2009 From: ira at extrasensory.com (Ira) Date: Wed Dec 9 22:59:39 2009 Subject: [Icc-avr] Where did my 4 bytes go? In-Reply-To: References: <0MBVXy-1NPFqb1sxC-00AuvE@mrelay.perfora.net> <4B1EA4C9.9080208@srel.de> <0MbwJa-1NY7aG3hFG-00JkNP@mrelay.perfora.net> <8CC46885DDEFB1D-2B34-924F@webmail-d044.sysops.aol.com> <0Lg2Cp-1NqXQO1V9P-00pC9f@mrelay.perfora.net> Message-ID: <0MhScU-1NfF4m1Lvu-00N26W@mrelay.perfora.net> At 08:27 PM 12/9/2009, you wrote: >I don't know how much you make, but around here, that's 2 to 3 hours of labor. >To me, that is not smart engineering or smart business practices. The days >of being super clever to get 99% utilization of a processor are long gone. >Processors are cheap, engineering is not. Sometimes I make a lot, and sometimes I make nothing, and the struggle for optimization is a silly but obsessive behavior of mine. Thankfully my income doesn't depend on my programming ability and I have the freedom to waste time with senseless quests like this. Were I a decent businessman I'd probably not have time for this as there are people I can pay that are way better programmers than me and someday the tiny little world I work in will pass my abilities and I'll retire or do something else, but it amuses me. Ira From tim at sabretechnology.co.uk Thu Dec 10 00:50:58 2009 From: tim at sabretechnology.co.uk (Tim Mitchell) Date: Thu Dec 10 02:06:51 2009 Subject: [Icc-avr] Trying to load from a flash table in assembler Message-ID: <04671BB8D269034BBC4BB6BA89486726128980@sserver.SabreTechnology.local> Hi Johannes, So it's not the same as the AVRStudio assembler then? (Which confusingly has SRAM addresses as byte addresses and Flash addresses as word addresses) This is code previously used on the AVRStudio assembler and code such as "pwm_time*2" works there. -- Tim Mitchell -----Original Message----- From: icc-avr-bounces@imagecraft.com on behalf of Johannes Assenbaum Sent: Wed 09/12/2009 18:40 To: icc-avr@imagecraft.com Subject: Re: [Icc-avr] Trying to load from a flash table in assembler Besides that assembler cannot calculate "pwm_time*2" in this context, you don't need address correction. Addresses of data are always byte addresses, even in flash. Best regards, Johannes > Hi, I am trying to write an assembler module which loads a value from a > table in flash. > As far as I can see it should be like this... > ldi zl,<(pwm_time*2) > ldi zh,>(pwm_time*2) > lpm r16,z > pwm_time: > .db 16,16,16,16,16,16,16,16,16,16,16,16,16,16,16,16 > but the assembler complains about the "pwm_time*2" - Absolute expression > expected. > Can't see where I'm going wrong... it's probably something really > obvious. > -- > Tim Mitchell > _______________________________________________ > Icc-avr mailing list > Icc-avr@imagecraft.com > http://dragonsgate.net/mailman/listinfo/icc-avr _______________________________________________ Icc-avr mailing list Icc-avr@imagecraft.com http://dragonsgate.net/mailman/listinfo/icc-avr -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/ms-tnef Size: 3245 bytes Desc: not available Url : http://dragonsgate.net/pipermail/icc-avr/attachments/20091210/100d1f70/attachment.bin From bgarner at fhrd.net Thu Dec 10 05:35:42 2009 From: bgarner at fhrd.net (Bobby Garner) Date: Thu Dec 10 06:50:51 2009 Subject: [Icc-avr] Where did my 4 bytes go? In-Reply-To: References: <0MBVXy-1NPFqb1sxC-00AuvE@mrelay.perfora.net><4B1EA4C9.9080208@srel.de><0MbwJa-1NY7aG3hFG-00JkNP@mrelay.perfora.net><8CC46885DDEFB1D-2B34-924F@webmail-d044.sysops.aol.com> <0Lg2Cp-1NqXQO1V9P-00pC9f@mrelay.perfora.net> Message-ID: <4B20F92E.5070200@fhrd.net> I realize this may be off topic, but it's relevant. Submit this problem to a robot (computer) and you would get Tony's answer. However, there remains among us, those who believe that understanding a problem can prove to be more valuable than getting a job out the door efficiently. We used to call that education. Now education is a university issued placard on the wall. Computers (robots) are being used throughout the design, production, and marketing process. New products are now more a function of program menu options than a new human generated idea. The final objective of technological advancement is the development of the Technological Singularity, i.e. Super Intelligence, Posthumanism. Google it. Productivity soars as real men and women are idled on the sidelines. Bobby Garner Tony Karavidas wrote: > Silly? Let's see, a 'typical' mega48 is $1.84 (q=100) > A Mega88 has twice the FLASH and twice the RAM, and is $2.32. > You've sold 500 units and are building your 2nd batch of 500 as you > mentioned. > So to save $240, you are struggling with getting the code to fit each time > you touch the code. > If you were building millions of units, I would say you're absolutely doing > the right thing. > > I don't know how much you make, but around here, that's 2 to 3 hours of > labor. > To me, that is not smart engineering or smart business practices. The days > of being super clever to get 99% utilization of a processor are long gone. > Processors are cheap, engineering is not. > > > Good luck, > Tony > > > > > -----Original Message----- > From: icc-avr-bounces@imagecraft.com [mailto:icc-avr-bounces@imagecraft.com] > On Behalf Of Ira > Sent: Wednesday, December 09, 2009 5:58 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] Where did my 4 bytes go? > > At 12:21 PM 12/9/2009, you wrote: > >> This is the reason I don't size my processors so close to the limit. >> Maybe your code has grown beyond your expectations, but you don't seem >> to have the sales volume to put up with such headaches. What are you >> going to do in 6 months when you have to tweak the code again? If it >> were me, the next bigger processor would go in there. It looks like >> you're selling stuff for a few hundred dollars and could absorb the >> slightly more expensive processor. It would make life easier. >> > > But it fit when I programmed it, and given the hardware there's no more > features we can think of or implement so it seems silly to go to an Mega416 > or what ever one up from a Mega48 is, just because the compiler changed and > took 6 more bytes. > > Ira > > _______________________________________________ > Icc-avr mailing list > Icc-avr@imagecraft.com > http://dragonsgate.net/mailman/listinfo/icc-avr > > _______________________________________________ > Icc-avr mailing list > Icc-avr@imagecraft.com > http://dragonsgate.net/mailman/listinfo/icc-avr > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20091210/3fd7eb67/attachment.html From tim at sabretechnology.co.uk Thu Dec 10 07:04:44 2009 From: tim at sabretechnology.co.uk (Tim Mitchell) Date: Thu Dec 10 08:17:53 2009 Subject: [Icc-avr] Where did my 4 bytes go? Message-ID: <04671BB8D269034BBC4BB6BA894867261CBFC3@sserver.SabreTechnology.local> ----Original Message---- From: icc-avr-bounces@imagecraft.com [mailto:icc-avr-bounces@imagecraft.com] On Behalf Of Bobby Garner Sent: 10 December 2009 13:36 To: tony@encoreelectronics.com; 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] Where did my 4 bytes go? > I realize this may be off topic, but it's relevant. > Submit this problem to a robot (computer) and you would > get Tony's answer. However, there remains among us, those > who believe that understanding a problem can prove to be > more valuable than getting a job out the door > efficiently. We used to call that education. Now > education is a university issued placard on the wall. > Computers (robots) are being used throughout the design, > production, and marketing process. New products are now > more a function of program menu options than a new human > generated idea. The final objective of technological > advancement is the development of the Technological > Singularity, i.e. Super Intelligence, Posthumanism. > Google it. > > Productivity soars as real men and women are idled on the > sidelines. > I don't agree with you, Tony's answer is all about commercial pressures when you are running a design business. And that's an education in itself, though probably not the sort you were thinking of. If, as with my business, getting paid at the end of the week depends on getting the job out the door, then though I would prefer to spend days getting to the bottom of the problem, finishing the job efficiently and getting on to the next thing is often more important. If you have the luxury of being paid regularly and being able to spend time investigating such problems, or this is a hobby for you, then it's great to be able to fully understand the problem. -- Tim Mitchell From tim at sabretechnology.co.uk Thu Dec 10 07:58:53 2009 From: tim at sabretechnology.co.uk (Tim Mitchell) Date: Thu Dec 10 09:11:51 2009 Subject: [Icc-avr] Another assembler thing Message-ID: <04671BB8D269034BBC4BB6BA894867261CBFC7@sserver.SabreTechnology.local> Is there any way to use the .if assembler directive with a symbol defined in the main c program? I have some compile-time options which are defined in the c program, but I would like to be able to access the value of these options in an assembly module too... but it doesn't seem to work. The .if directive only seems to work with locally defined 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 jassenbaum at htp-tel.de Thu Dec 10 11:04:38 2009 From: jassenbaum at htp-tel.de (Johannes Assenbaum) Date: Thu Dec 10 12:17:34 2009 Subject: [Icc-avr] Another assembler thing References: <04671BB8D269034BBC4BB6BA894867261CBFC7@sserver.SabreTechnology.local> Message-ID: AFAIK no way. Or does Richard still know a cheat never documented? Best regards, Johannes > Is there any way to use the .if assembler directive with a symbol > defined in the main c program? > I have some compile-time options which are defined in the c program, but > I would like to be able to access the value of these options in an > assembly module too... but it doesn't seem to work. The .if directive > only seems to work with locally defined 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 > _______________________________________________ > Icc-avr mailing list > Icc-avr@imagecraft.com > http://dragonsgate.net/mailman/listinfo/icc-avr From ira at extrasensory.com Thu Dec 10 11:24:19 2009 From: ira at extrasensory.com (Ira) Date: Thu Dec 10 12:37:23 2009 Subject: [Icc-avr] Another assembler thing In-Reply-To: <04671BB8D269034BBC4BB6BA894867261CBFC7@sserver.SabreTechno logy.local> References: <04671BB8D269034BBC4BB6BA894867261CBFC7@sserver.SabreTechnology.local> Message-ID: <0MMTtG-1NR4l63LOI-008gkx@mrelay.perfora.net> At 07:58 AM 12/10/2009, you wrote: >Is there any way to use the .if assembler directive with a symbol >defined in the main c program? > >I have some compile-time options which are defined in the c program, but >I would like to be able to access the value of these options in an >assembly module too... but it doesn't seem to work. The .if directive >only seems to work with locally defined symbols. Wouldn't those belong in a header file? Ira From tim at sabretechnology.co.uk Thu Dec 10 11:56:56 2009 From: tim at sabretechnology.co.uk (Tim Mitchell) Date: Thu Dec 10 13:11:01 2009 Subject: [Icc-avr] Another assembler thing Message-ID: <04671BB8D269034BBC4BB6BA89486726128981@sserver.SabreTechnology.local> -----Original Message----- From: icc-avr-bounces@imagecraft.com on behalf of Ira Sent: Thu 10/12/2009 19:24 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] Another assembler thing At 07:58 AM 12/10/2009, you wrote: >Is there any way to use the .if assembler directive with a symbol >defined in the main c program? > >I have some compile-time options which are defined in the c program, but >I would like to be able to access the value of these options in an >assembly module too... but it doesn't seem to work. The .if directive >only seems to work with locally defined symbols. >Wouldn't those belong in a header file? Well, they are in a c header file, but I can't see a way of including a c header into an assembler module. Tim -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/ms-tnef Size: 2902 bytes Desc: not available Url : http://dragonsgate.net/pipermail/icc-avr/attachments/20091210/14f80695/attachment.bin From dsmith at medeco.com Thu Dec 10 12:12:25 2009 From: dsmith at medeco.com (David Smith) Date: Thu Dec 10 13:25:17 2009 Subject: [Icc-avr] Another assembler thing References: <04671BB8D269034BBC4BB6BA894867261CBFC7@sserver.SabreTechnology.local> <0MMTtG-1NR4l63LOI-008gkx@mrelay.perfora.net> Message-ID: I accomplished the same thing with a different toolset on a different micro several years ago, but I don't think the method I used will work here. The trick that allowed me to do it was that the compiler and the assembler used the same #if conditional compile statement. I created 1 file that had both the assembly and the C definitions, with the conditional compile choosing which flavor got compiled/assembled. I just checked ICCAVR docs, and it looks like it uses different constructs (#if for C; .if for assembly), so I don't see a good way around it. My intuition would be that you will have to have 2 include files -- 1 for assembly and 1 for C. It creates a bit of a potential maintenance headache; you have to remember to change a value in both files instead of just one when making changes. Regards, David Smith Senior Electrical Design Engineer Medeco Security Locks, Inc. Phone: 540-380-1710 dsmith@medeco.com -----Original Message----- From: icc-avr-bounces@imagecraft.com [mailto:icc-avr-bounces@imagecraft.com] On Behalf Of Ira Sent: Thursday, December 10, 2009 2:24 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] Another assembler thing At 07:58 AM 12/10/2009, you wrote: >Is there any way to use the .if assembler directive with a symbol >defined in the main c program? > >I have some compile-time options which are defined in the c program, but >I would like to be able to access the value of these options in an >assembly module too... but it doesn't seem to work. The .if directive >only seems to work with locally defined symbols. Wouldn't those belong in a header file? Ira _______________________________________________ Icc-avr mailing list Icc-avr@imagecraft.com http://dragonsgate.net/mailman/listinfo/icc-avr From richard-lists at imagecraft.com Thu Dec 10 12:47:52 2009 From: richard-lists at imagecraft.com (Richard Man) Date: Thu Dec 10 14:01:42 2009 Subject: [Icc-avr] Another assembler thing In-Reply-To: References: <04671BB8D269034BBC4BB6BA894867261CBFC7@sserver.SabreTechnology.local> <0MMTtG-1NR4l63LOI-008gkx@mrelay.perfora.net> Message-ID: <200912102201.nBAM1eHm095045@mail.imagecraft.com> V8's C Preprocessor will have a feature that allows the use of the C preprocessor with asm code. You can use #include "asm.h" #define foo bar and all the C preprocessor features. Of course the macros will have to be compatible with underlying asm syntax etc. May be it will be useful for tasks like these. At 12:12 PM 12/10/2009, David Smith wrote: >I accomplished the same thing with a different toolset on a different >micro several years ago, but I don't think the method I used will work >here. > >The trick that allowed me to do it was that the compiler and the >assembler used the same #if conditional compile statement. I created 1 >file that had both the assembly and the C definitions, with the >conditional compile choosing which flavor got compiled/assembled. I >just checked ICCAVR docs, and it looks like it uses different constructs >(#if for C; .if for assembly), so I don't see a good way around it. > >My intuition would be that you will have to have 2 include files -- 1 >for assembly and 1 for C. It creates a bit of a potential maintenance >headache; you have to remember to change a value in both files instead >of just one when making changes. > >Regards, > // richard // http://rfman.wordpress.com // http://www.imagecraft.com/pub/Portfolio09/ From dsmith at medeco.com Thu Dec 10 12:57:55 2009 From: dsmith at medeco.com (David Smith) Date: Thu Dec 10 14:10:48 2009 Subject: [Icc-avr] Another assembler thing References: <04671BB8D269034BBC4BB6BA894867261CBFC7@sserver.SabreTechnology.local><0MMTtG-1NR4l63LOI-008gkx@mrelay.perfora.net> <200912102201.nBAM1eHm095045@mail.imagecraft.com> Message-ID: That would certainly do it -- that will be a nice feature enhancement! David Smith Senior Electrical Design Engineer Medeco Security Locks, Inc. Phone: 540-380-1710 dsmith@medeco.com -----Original Message----- From: icc-avr-bounces@imagecraft.com [mailto:icc-avr-bounces@imagecraft.com] On Behalf Of Richard Man Sent: Thursday, December 10, 2009 3:48 PM To: icc-avr@imagecraft.com Subject: RE: [Icc-avr] Another assembler thing V8's C Preprocessor will have a feature that allows the use of the C preprocessor with asm code. You can use #include "asm.h" #define foo bar and all the C preprocessor features. Of course the macros will have to be compatible with underlying asm syntax etc. May be it will be useful for tasks like these. At 12:12 PM 12/10/2009, David Smith wrote: >I accomplished the same thing with a different toolset on a different >micro several years ago, but I don't think the method I used will work >here. > >The trick that allowed me to do it was that the compiler and the >assembler used the same #if conditional compile statement. I created 1 >file that had both the assembly and the C definitions, with the >conditional compile choosing which flavor got compiled/assembled. I >just checked ICCAVR docs, and it looks like it uses different constructs >(#if for C; .if for assembly), so I don't see a good way around it. > >My intuition would be that you will have to have 2 include files -- 1 >for assembly and 1 for C. It creates a bit of a potential maintenance >headache; you have to remember to change a value in both files instead >of just one when making changes. > >Regards, > // richard // http://rfman.wordpress.com // http://www.imagecraft.com/pub/Portfolio09/ _______________________________________________ Icc-avr mailing list Icc-avr@imagecraft.com http://dragonsgate.net/mailman/listinfo/icc-avr From johan at edab.nu Wed Dec 16 01:41:42 2009 From: johan at edab.nu (=?ISO-8859-1?Q?Johan_Wallstr=F6m?=) Date: Wed Dec 16 02:54:47 2009 Subject: [Icc-avr] ATMega128 addressing and text_end In-Reply-To: References: <04671BB8D269034BBC4BB6BA894867261CBFC7@sserver.SabreTechnology.local><0MMTtG-1NR4l63LOI-008gkx@mrelay.perfora.net> <200912102201.nBAM1eHm095045@mail.imagecraft.com> Message-ID: <4B28AB56.3000203@edab.nu> Hmm, I just ordered the pro version of the compiler, to support 128kb code flash in atmega128. Now I'm looking on how to adjust my software for this upgrade. I'm currently using _text_end to get the total length of the firmware, so the bootloader can calculate the length of the fw. I assume that code will no longer work, seeing how a data pointer will still only be 16-bit.. Will I be able to retrieve the length of the application somehow..? extern unsigned const char _text_end; const char * const FwLength = &_text_end; best regards Johan From bobgardner at aol.com Wed Dec 16 04:54:44 2009 From: bobgardner at aol.com (bobgardner@aol.com) Date: Wed Dec 16 06:08:16 2009 Subject: [Icc-avr] ATMega128 addressing and text_end In-Reply-To: <4B28AB56.3000203@edab.nu> References: <04671BB8D269034BBC4BB6BA894867261CBFC7@sserver.SabreTechnology.local><0MMTtG-1NR4l63LOI-008gkx@mrelay.perfora.net> <200912102201.nBAM1eHm095045@mail.imagecraft.com> <4B28AB56.3000203@edab.nu> Message-ID: <8CC4C66132EFE6F-39B0-13E4@webmail-m085.sysops.aol.com> mega128 uses words as instructions. 128k bytes is 64k words, so it all fits. You start using 3 byte pointers in the mega256 flavor. -----Original Message----- From: Johan Wallstr?m Sent: Wed, Dec 16, 2009 4:41 am Subject: [Icc-avr] ATMega128 addressing and text_end Hmm, I just ordered the pro version of the compiler, to support 128kb code flash in atmega128. Now I'm looking on how to adjust my software for this upgrade. I'm currently using _text_end to get the total length of the firmware, so the bootloader can calculate the length of the fw. I assume that code will no longer work, seeing how a data pointer will still only be 16-bit.. Will I be able to retrieve the length of the application somehow..? extern unsigned const char _text_end; const char * const FwLength = &_text_end; best regards Johan _______________________________________________ Icc-avr mailing list Icc-avr@imagecraft.com http://dragonsgate.net/mailman/listinfo/icc-avr -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20091216/cadfbfe6/attachment.html From johan at edab.nu Wed Dec 16 05:00:14 2009 From: johan at edab.nu (=?ISO-8859-1?Q?Johan_Wallstr=F6m?=) Date: Wed Dec 16 06:13:18 2009 Subject: [Icc-avr] ATMega128 addressing and text_end In-Reply-To: <8CC4C66132EFE6F-39B0-13E4@webmail-m085.sysops.aol.com> References: <04671BB8D269034BBC4BB6BA894867261CBFC7@sserver.SabreTechnology.local><0MMTtG-1NR4l63LOI-008gkx@mrelay.perfora.net> <200912102201.nBAM1eHm095045@mail.imagecraft.com> <4B28AB56.3000203@edab.nu> <8CC4C66132EFE6F-39B0-13E4@webmail-m085.sysops.aol.com> Message-ID: <4B28D9DE.2000400@edab.nu> Well, the text_end symbol is still accessed as an external byte-addressed variabel, as you can se in the example code. Is it possible to declare the text_end symbol as a function pointer instead, to get the word based address? bobgardner@aol.com skrev: > mega128 uses words as instructions. 128k bytes is 64k words, so it all > fits. You start using 3 byte pointers in the mega256 flavor. > > > -----Original Message----- > From: Johan Wallstr?m > Sent: Wed, Dec 16, 2009 4:41 am > Subject: [Icc-avr] ATMega128 addressing and text_end > > Hmm, I just ordered the pro version of the compiler, to support 128kb > code flash in atmega128. > > Now I'm looking on how to adjust my software for this upgrade. > > I'm currently using _text_end to get the total length of the firmware, > so the bootloader can calculate the length of the fw. > > I assume that code will no longer work, seeing how a data pointer will > still only be 16-bit.. > Will I be able to retrieve the length of the application somehow..? > > extern unsigned const char _text_end; > const char * const FwLength = &_text_end; > > best regards > Johan > _______________________________________________ > Icc-avr mailing list > Icc-avr@imagecraft.com > http://dragonsgate.net/mailman/listinfo/icc-avr > ------------------------------------------------------------------------ > > > No virus found in this incoming message. > Checked by AVG - www.avg.com > Version: 8.5.427 / Virus Database: 270.14.110/2568 - Release Date: 12/16/09 08:02:00 > > From johan at edab.nu Wed Dec 16 05:59:20 2009 From: johan at edab.nu (=?ISO-8859-1?Q?Johan_Wallstr=F6m?=) Date: Wed Dec 16 07:12:24 2009 Subject: [Icc-avr] ATMega128 addressing and text_end In-Reply-To: <4B28D9DE.2000400@edab.nu> References: <04671BB8D269034BBC4BB6BA894867261CBFC7@sserver.SabreTechnology.local><0MMTtG-1NR4l63LOI-008gkx@mrelay.perfora.net> <200912102201.nBAM1eHm095045@mail.imagecraft.com> <4B28AB56.3000203@edab.nu> <8CC4C66132EFE6F-39B0-13E4@webmail-m085.sysops.aol.com> <4B28D9DE.2000400@edab.nu> Message-ID: <4B28E7B8.8040200@edab.nu> For reference, I was able to solve it in asm, getting the word address by doing this: _FwLength:: .word `__text_end Would be nice if it was possible in C code too.. Trying with a function pointer resulted in getting the address to a function pointer lookup table.. Johan Wallstr?m skrev: > > Well, the text_end symbol is still accessed as an external > byte-addressed variabel, as you can se in the example code. > Is it possible to declare the text_end symbol as a function pointer > instead, to get the word based address? > > > > bobgardner@aol.com skrev: >> mega128 uses words as instructions. 128k bytes is 64k words, so it >> all fits. You start using 3 byte pointers in the mega256 flavor. >> >> >> -----Original Message----- >> From: Johan Wallstr?m >> Sent: Wed, Dec 16, 2009 4:41 am >> Subject: [Icc-avr] ATMega128 addressing and text_end >> >> Hmm, I just ordered the pro version of the compiler, to support 128kb >> code flash in atmega128. >> Now I'm looking on how to adjust my software for this upgrade. >> I'm currently using _text_end to get the total length of the >> firmware, so the bootloader can calculate the length of the fw. >> I assume that code will no longer work, seeing how a data pointer >> will still only be 16-bit.. Will I be able to retrieve the length of >> the application somehow..? >> extern unsigned const char _text_end; const char * const FwLength = >> &_text_end; >> best regards Johan _______________________________________________ >> Icc-avr mailing list Icc-avr@imagecraft.com >> >> http://dragonsgate.net/mailman/listinfo/icc-avr >> ------------------------------------------------------------------------ >> >> >> No virus found in this incoming message. >> Checked by AVG - www.avg.com Version: 8.5.427 / Virus Database: >> 270.14.110/2568 - Release Date: 12/16/09 08:02:00 >> >> > _______________________________________________ > Icc-avr mailing list > Icc-avr@imagecraft.com > http://dragonsgate.net/mailman/listinfo/icc-avr > ------------------------------------------------------------------------ > > > No virus found in this incoming message. > Checked by AVG - www.avg.com > Version: 8.5.427 / Virus Database: 270.14.110/2568 - Release Date: 12/16/09 08:02:00 > > From dsmith at medeco.com Wed Dec 16 06:13:14 2009 From: dsmith at medeco.com (David Smith) Date: Wed Dec 16 07:26:13 2009 Subject: [Icc-avr] ATMega128 addressing and text_end References: <04671BB8D269034BBC4BB6BA894867261CBFC7@sserver.SabreTechnology.local><0MMTtG-1NR4l63LOI-008gkx@mrelay.perfora.net> <200912102201.nBAM1eHm095045@mail.imagecraft.com> <4B28AB56.3000203@edab.nu> <8CC4C66132EFE6F-39B0-13E4@webmail-m085.sysops.aol.com><4B28D9DE.2000400@edab.nu> <4B28E7B8.8040200@edab.nu> Message-ID: One thing to consider if you were interested in using the function pointer approach -- with creative casting and dereferencing, you can get the address of the routine that is in the function pointer lookup table. I used the following to get the actual address of the function "vCreatekey" instead of the address of the entry in the function pointer table: funcAddress = (void*)(*(void* const* const)vCreatekey); This may or may not be useful to you for what you are trying to do .... David Smith Senior Electrical Design Engineer Medeco Security Locks, Inc. Phone: 540-380-1710 dsmith@medeco.com -----Original Message----- From: icc-avr-bounces@imagecraft.com [mailto:icc-avr-bounces@imagecraft.com] On Behalf Of Johan Wallstr?m Sent: Wednesday, December 16, 2009 8:59 AM 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] ATMega128 addressing and text_end For reference, I was able to solve it in asm, getting the word address by doing this: _FwLength:: .word `__text_end Would be nice if it was possible in C code too.. Trying with a function pointer resulted in getting the address to a function pointer lookup table.. Johan Wallstr?m skrev: > > Well, the text_end symbol is still accessed as an external > byte-addressed variabel, as you can se in the example code. > Is it possible to declare the text_end symbol as a function pointer > instead, to get the word based address? > > > > bobgardner@aol.com skrev: >> mega128 uses words as instructions. 128k bytes is 64k words, so it >> all fits. You start using 3 byte pointers in the mega256 flavor. >> >> >> -----Original Message----- >> From: Johan Wallstr?m >> Sent: Wed, Dec 16, 2009 4:41 am >> Subject: [Icc-avr] ATMega128 addressing and text_end >> >> Hmm, I just ordered the pro version of the compiler, to support 128kb >> code flash in atmega128. >> Now I'm looking on how to adjust my software for this upgrade. >> I'm currently using _text_end to get the total length of the >> firmware, so the bootloader can calculate the length of the fw. >> I assume that code will no longer work, seeing how a data pointer >> will still only be 16-bit.. Will I be able to retrieve the length of >> the application somehow..? >> extern unsigned const char _text_end; const char * const FwLength = >> &_text_end; >> best regards Johan _______________________________________________ >> Icc-avr mailing list Icc-avr@imagecraft.com >> >> http://dragonsgate.net/mailman/listinfo/icc-avr >> ------------------------------------------------------------------------ >> >> >> No virus found in this incoming message. >> Checked by AVG - www.avg.com Version: 8.5.427 / Virus Database: >> 270.14.110/2568 - Release Date: 12/16/09 08:02:00 >> >> > _______________________________________________ > Icc-avr mailing list > Icc-avr@imagecraft.com > http://dragonsgate.net/mailman/listinfo/icc-avr > ------------------------------------------------------------------------ > > > No virus found in this incoming message. > Checked by AVG - www.avg.com > Version: 8.5.427 / Virus Database: 270.14.110/2568 - Release Date: 12/16/09 08:02:00 > > _______________________________________________ Icc-avr mailing list Icc-avr@imagecraft.com http://dragonsgate.net/mailman/listinfo/icc-avr From johan at edab.nu Wed Dec 16 06:34:42 2009 From: johan at edab.nu (=?ISO-8859-1?Q?Johan_Wallstr=F6m?=) Date: Wed Dec 16 07:47:46 2009 Subject: [Icc-avr] ATMega128 addressing and text_end In-Reply-To: References: <04671BB8D269034BBC4BB6BA894867261CBFC7@sserver.SabreTechnology.local><0MMTtG-1NR4l63LOI-008gkx@mrelay.perfora.net> <200912102201.nBAM1eHm095045@mail.imagecraft.com> <4B28AB56.3000203@edab.nu> <8CC4C66132EFE6F-39B0-13E4@webmail-m085.sysops.aol.com><4B28D9DE.2000400@edab.nu> <4B28E7B8.8040200@edab.nu> Message-ID: <4B28F002.2050100@edab.nu> Hey, Thanks for the suggestion, unfortunately it is not possible to do it in a constant expression =) David Smith skrev: > One thing to consider if you were interested in using the function pointer approach -- with creative casting and dereferencing, you can get the address of the routine that is in the function pointer lookup table. > > I used the following to get the actual address of the function "vCreatekey" instead of the address of the entry in the function pointer table: > > funcAddress = (void*)(*(void* const* const)vCreatekey); > > This may or may not be useful to you for what you are trying to do .... > > > David Smith > Senior Electrical Design Engineer > Medeco Security Locks, Inc. > > Phone: 540-380-1710 > dsmith@medeco.com > -----Original Message----- > From: icc-avr-bounces@imagecraft.com [mailto:icc-avr-bounces@imagecraft.com] On Behalf Of Johan Wallstr?m > Sent: Wednesday, December 16, 2009 8:59 AM > 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] ATMega128 addressing and text_end > > > For reference, I was able to solve it in asm, getting the word address > by doing this: > > _FwLength:: > .word `__text_end > > Would be nice if it was possible in C code too.. Trying with a function > pointer resulted in getting the address to a function pointer lookup table.. > > > Johan Wallstr?m skrev: > >> Well, the text_end symbol is still accessed as an external >> byte-addressed variabel, as you can se in the example code. >> Is it possible to declare the text_end symbol as a function pointer >> instead, to get the word based address? >> >> >> >> bobgardner@aol.com skrev: >> >>> mega128 uses words as instructions. 128k bytes is 64k words, so it >>> all fits. You start using 3 byte pointers in the mega256 flavor. >>> >>> >>> -----Original Message----- >>> From: Johan Wallstr?m >>> Sent: Wed, Dec 16, 2009 4:41 am >>> Subject: [Icc-avr] ATMega128 addressing and text_end >>> >>> Hmm, I just ordered the pro version of the compiler, to support 128kb >>> code flash in atmega128. >>> Now I'm looking on how to adjust my software for this upgrade. >>> I'm currently using _text_end to get the total length of the >>> firmware, so the bootloader can calculate the length of the fw. >>> I assume that code will no longer work, seeing how a data pointer >>> will still only be 16-bit.. Will I be able to retrieve the length of >>> the application somehow..? >>> extern unsigned const char _text_end; const char * const FwLength = >>> &_text_end; >>> best regards Johan _______________________________________________ >>> Icc-avr mailing list Icc-avr@imagecraft.com >>> >>> http://dragonsgate.net/mailman/listinfo/icc-avr >>> ------------------------------------------------------------------------ >>> >>> >>> No virus found in this incoming message. >>> Checked by AVG - www.avg.com Version: 8.5.427 / Virus Database: >>> 270.14.110/2568 - Release Date: 12/16/09 08:02:00 >>> >>> >>> >> _______________________________________________ >> Icc-avr mailing list >> Icc-avr@imagecraft.com >> http://dragonsgate.net/mailman/listinfo/icc-avr >> ------------------------------------------------------------------------ >> >> >> No virus found in this incoming message. >> Checked by AVG - www.avg.com >> Version: 8.5.427 / Virus Database: 270.14.110/2568 - Release Date: 12/16/09 08:02:00 >> >> >> > _______________________________________________ > Icc-avr mailing list > Icc-avr@imagecraft.com > http://dragonsgate.net/mailman/listinfo/icc-avr > > > ------------------------------------------------------------------------ > > > No virus found in this incoming message. > Checked by AVG - www.avg.com > Version: 8.5.427 / Virus Database: 270.14.110/2568 - Release Date: 12/16/09 08:02:00 > > From jassenbaum at htp-tel.de Wed Dec 16 14:31:29 2009 From: jassenbaum at htp-tel.de (Johannes Assenbaum) Date: Wed Dec 16 15:44:31 2009 Subject: [Icc-avr] New version of Map File Summary available Message-ID: <33bD5b0p9zSDpedLBvAXnsQ5AD0Xjxct5fBrqFy9LoG@akmail> Hi all, there are news at flash info. Please update, as you prefer, by http://avr.jassenbaum.de/iccv7avr/files/iccv7avr_mfs_update.exe http://avr.jassenbaum.de/iccv7avr/files/iccv7avr_mfs_update.zip http://avr.jassenbaum.de/iccv7avr/files/iccv7avr_latest_mfs.7z Best regards, Johannes From richard-lists at imagecraft.com Wed Dec 16 18:55:12 2009 From: richard-lists at imagecraft.com (Richard Man) Date: Wed Dec 16 20:09:30 2009 Subject: [Icc-avr] ATMega128 addressing and text_end In-Reply-To: <4B28E7B8.8040200@edab.nu> References: <04671BB8D269034BBC4BB6BA894867261CBFC7@sserver.SabreTechnology.local> <0MMTtG-1NR4l63LOI-008gkx@mrelay.perfora.net> <200912102201.nBAM1eHm095045@mail.imagecraft.com> <4B28AB56.3000203@edab.nu> <8CC4C66132EFE6F-39B0-13E4@webmail-m085.sysops.aol.com> <4B28D9DE.2000400@edab.nu> <4B28E7B8.8040200@edab.nu> Message-ID: <200912170409.nBH49Si6073995@mail.imagecraft.com> I think currently this is the only solution. Sorry. Will consider a better solution for future release. At 05:59 AM 12/16/2009, Johan Wallstr?m wrote: >For reference, I was able to solve it in asm, >getting the word address by doing this: > >_FwLength:: > .word `__text_end > >Would be nice if it was possible in C code too.. >Trying with a function pointer resulted in >getting the address to a function pointer lookup table.. > // richard // http://rfman.wordpress.com // http://www.imagecraft.com/pub/Portfolio09/