From benra at imt.liu.se Wed Oct 1 01:39:51 2008 From: benra at imt.liu.se (Bengt Ragnemalm) Date: Wed Oct 1 02:43:33 2008 Subject: [Icc-avr] Equation help Message-ID: Hi. Please help me with the following code: The purpose is to shift the 16 bit dcSampledCoarse two steps down, convert to 8 bit char and finally mask away the highest bit. The two last lines are just break down of the first test line. To test, I have run the code with Studio on actual hardware and the simulator. /Bengt // Target : M32 #include #include #include void main(void) { static unsigned short dcSampledCoarse=14565; static unsigned char test; test = ((unsigned char)(dcSampledCoarse>>2)) & 0b01111111; // =57. Should be 7273 test = ((unsigned char)(dcSampledCoarse>>2)); test = test & 0b01111111; } Assembler of the first line: 15: test = ((unsigned char)(dcSampledCoarse>>2)) & 0b01111111; // =60. Should be 7273 +0000004E: 91800060 LDS R24,0x0060 Load direct from data space +00000050: 91900061 LDS R25,0x0061 Load direct from data space +00000052: 9596 LSR R25 Logical shift right +00000053: 9587 ROR R24 Rotate right through carry +00000054: 9596 LSR R25 Logical shift right +00000055: 9587 ROR R24 Rotate right through carry +00000056: 778F ANDI R24,0x7F Logical AND with immediate +00000057: 93800062 STS 0x0062,R24 Store direct to data space Bengt Ragnemalm, Forskningsingenj?r Tel 013-22 24 97 Leveransadress: Faktureringsadress: FAX: +46 13 10 19 02 Link?pings Universitet Link?pings Universitet bengt.ragnemalm@imt.liu.se Inst. f?r Medicinsk Teknik Faktura support http://www.imt.liu.se S-581 85 Link?ping SWEDEN 581 83 Link?ping Ref 1700 Bengt Ragnemalm M?rk med v?rt Best?llningsnr Vi kan g?ra mer ?n du kan dr?mma om men f?r det om?jliga beh?ver vi en liten leveranstid. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20081001/3e265e37/attachment.html From johan at edab.nu Wed Oct 1 01:51:33 2008 From: johan at edab.nu (=?ISO-8859-1?Q?Johan_Wallstr=F6m?=) Date: Wed Oct 1 02:55:20 2008 Subject: [Icc-avr] Equation help In-Reply-To: References: Message-ID: <48E33A15.2020604@edab.nu> *static* *unsigned* *short* dcSampledCoarse=14565; *static* *unsigned* *char* test; test = dcSampledCoarse>>2; // Does the whole shebang. Should be 3641 Bengt Ragnemalm skrev: > > Hi. > > > > Please help me with the following code: > > > > The purpose is to shift the 16 bit dcSampledCoarse two steps down, > convert to 8 bit char and finally mask away the highest bit. > > The two last lines are just break down of the first test line. > > > > To test, I have run the code with Studio on actual hardware and the > simulator. > > > > /Bengt > > > > > > // Target : M32 > > #include > #include > #include > > > *void* main(*void*) > { > *static* *unsigned* *short* dcSampledCoarse=14565; > *static* *unsigned* *char* test; > > test = ((*unsigned* *char*)(dcSampledCoarse>>2)) & 0b01111111; // > =57. Should be 7273 > test = ((*unsigned* *char*)(dcSampledCoarse>>2)); > test = test & 0b01111111; > } > > Assembler of the first line: > > 15: test = ((unsigned char)(dcSampledCoarse>>2)) & > 0b01111111; // =60. Should be 7273 > > +0000004E: 91800060 LDS R24,0x0060 Load direct from > data space > > +00000050: 91900061 LDS R25,0x0061 Load direct from > data space > > +00000052: 9596 LSR R25 Logical shift right > > +00000053: 9587 ROR R24 Rotate right through > carry > > +00000054: 9596 LSR R25 Logical shift right > > +00000055: 9587 ROR R24 Rotate right through > carry > > +00000056: 778F ANDI R24,0x7F Logical AND with > immediate > > +00000057: 93800062 STS 0x0062,R24 Store direct to data > space > > > > > > *Bengt Ragnemalm**,* Forskningsingenj?r** > > > > Tel *013-22 24 97* > > Leveransadress: > > > > > > > > Faktureringsadress: > > > > > > > > FAX: +46 13 10 19 02 > > Link?pings Universitet > > > > > > > > Link?pings Universitet > > > > > > > > *bengt.ragnemalm@imt.liu.se *** > > Inst. f?r Medicinsk Teknik > > > > > > > > Faktura support > > > > > > > > http://www.imt.liu.se > > S-581 85 Link?ping SWEDEN > > > > > > > > 581 83 Link?ping > > > > > > > > > > > > > > > > > > Ref 1700 Bengt Ragnemalm > M?rk med v?rt Best?llningsnr > > > > > > > > /Vi kan g?ra mer ?n du kan dr?mma om men f?r det om?jliga beh?ver vi > en liten leveranstid./ > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Icc-avr mailing list > Icc-avr@imagecraft.com > http://dragonsgate.net/mailman/listinfo/icc-avr > > ------------------------------------------------------------------------ > > > No virus found in this incoming message. > Checked by AVG - http://www.avg.com > Version: 8.0.173 / Virus Database: 270.7.5/1701 - Release Date: 2008-09-30 19:08 > > From richard-lists at imagecraft.com Wed Oct 1 01:51:19 2008 From: richard-lists at imagecraft.com (Richard Man) Date: Wed Oct 1 02:56:16 2008 Subject: [Icc-avr] Equation help In-Reply-To: References: Message-ID: <200810010956.m919uEPb084922@mail.imagecraft.com> An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20081001/b1b6f7f1/attachment-0001.html From benra at imt.liu.se Wed Oct 1 02:01:09 2008 From: benra at imt.liu.se (Bengt Ragnemalm) Date: Wed Oct 1 03:04:49 2008 Subject: SV: [Icc-avr] Equation help In-Reply-To: References: Message-ID: Sorry, sorry, I was staring blindly at the ?Should be 7273? but that was an old note. This calculation is perfectly OK. I check the original code with original problem and get back if there is a problem. /Bengt _____ Fr?n: icc-avr-bounces@imagecraft.com [mailto:icc-avr-bounces@imagecraft.com] F?r Bengt Ragnemalm Skickat: den 1 oktober 2008 10:40 Till: 'Discussion list for ICCAVR and ICCtiny Users. You do NOT needtosubscribeto icc-announce if you are a member of this.' ?mne: [Icc-avr] Equation help Hi. Please help me with the following code: The purpose is to shift the 16 bit dcSampledCoarse two steps down, convert to 8 bit char and finally mask away the highest bit. The two last lines are just break down of the first test line. To test, I have run the code with Studio on actual hardware and the simulator. /Bengt // Target : M32 #include #include #include void main(void) { static unsigned short dcSampledCoarse=14565; static unsigned char test; test = ((unsigned char)(dcSampledCoarse>>2)) & 0b01111111; // =57. Should be 7273 test = ((unsigned char)(dcSampledCoarse>>2)); test = test & 0b01111111; } Assembler of the first line: 15: test = ((unsigned char)(dcSampledCoarse>>2)) & 0b01111111; // =60. Should be 7273 +0000004E: 91800060 LDS R24,0x0060 Load direct from data space +00000050: 91900061 LDS R25,0x0061 Load direct from data space +00000052: 9596 LSR R25 Logical shift right +00000053: 9587 ROR R24 Rotate right through carry +00000054: 9596 LSR R25 Logical shift right +00000055: 9587 ROR R24 Rotate right through carry +00000056: 778F ANDI R24,0x7F Logical AND with immediate +00000057: 93800062 STS 0x0062,R24 Store direct to data space Bengt Ragnemalm, Forskningsingenj?r Tel 013-22 24 97 Leveransadress: Faktureringsadress: FAX: +46 13 10 19 02 Link?pings Universitet Link?pings Universitet bengt.ragnemalm@imt.liu.se Inst. f?r Medicinsk Teknik Faktura support http://www.imt.liu.se S-581 85 Link?ping SWEDEN 581 83 Link?ping Ref 1700 Bengt Ragnemalm M?rk med v?rt Best?llningsnr Vi kan g?ra mer ?n du kan dr?mma om men f?r det om?jliga beh?ver vi en liten leveranstid. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20081001/a9b76407/attachment.html From bobgardner at aol.com Wed Oct 1 08:30:26 2008 From: bobgardner at aol.com (bobgardner@aol.com) Date: Wed Oct 1 09:34:26 2008 Subject: [Icc-avr] cant init a flot in eeprom?!? Message-ID: <8CAF1F1C301B962-CA0-191@mblk-d38.sysops.aol.com> Can the compiler understand an initialized float in the eeprom section? float thing=1.234; //<---- map file shows 0000s makes me think it aint flyin -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20081001/05fc47e8/attachment-0001.html From j_baraclough at zetnet.co.uk Wed Oct 1 08:53:36 2008 From: j_baraclough at zetnet.co.uk (John Baraclough) Date: Wed Oct 1 09:57:35 2008 Subject: [Icc-avr] cant init a flot in eeprom?!? In-Reply-To: <8CAF1F1C301B962-CA0-191@mblk-d38.sysops.aol.com> References: <8CAF1F1C301B962-CA0-191@mblk-d38.sysops.aol.com> Message-ID: <48E39D00.30508@zetnet.co.uk> Hi Bob, What's actually in the .eep file? It's standard Intel Hex so is easy to decode. All the best for now, John bobgardner@aol.com wrote: > Can the compiler understand an initialized float in the eeprom section? > > float thing=1.234; //<---- map file shows 0000s makes me think it aint > flyin > ------------------------------------------------------------------------ > Find phone numbers fast with the New AOL Yellow Pages > ! > ------------------------------------------------------------------------ > > _______________________________________________ > Icc-avr mailing list > Icc-avr@imagecraft.com > http://dragonsgate.net/mailman/listinfo/icc-avr > From bibi at microsyl.com Wed Oct 1 09:08:58 2008 From: bibi at microsyl.com (bibi@microsyl.com) Date: Wed Oct 1 10:12:39 2008 Subject: [Icc-avr] Math sin function In-Reply-To: <8CAF1F1C301B962-CA0-191@mblk-d38.sysops.aol.com> References: <8CAF1F1C301B962-CA0-191@mblk-d38.sysops.aol.com> Message-ID: <24198.204.19.71.2.1222877338.squirrel@www.microsyl.com> Hi, Could you told me if sin(0.1) will be execute faster than sin(0.08123) Thanks Sylvain Bissonnette From bobgardner at aol.com Wed Oct 1 09:25:32 2008 From: bobgardner at aol.com (bobgardner@aol.com) Date: Wed Oct 1 10:29:28 2008 Subject: [Icc-avr] cant init a flot in eeprom?!? In-Reply-To: <48E39D00.30508@zetnet.co.uk> References: <8CAF1F1C301B962-CA0-191@mblk-d38.sysops.aol.com> <48E39D00.30508@zetnet.co.uk> Message-ID: <8CAF1F9759D355F-CA0-608@mblk-d38.sysops.aol.com> I found the problem There was a loose nut behind the keyboard. I was calculating the size of the ee block to write with &dummybyteatend - &firstbyteatbeginning and using that size for the eewritebytes... BUT.... the size was words. When I gave it the block size in bytes, it worked. (The floats were at the end... last half of the eeblock wasnt getting written) -----Original Message----- From: John Baraclough Sent: Wed, 1 Oct 2008 11:53 am Subject: Re: [Icc-avr] cant init a flot in eeprom?!? Hi Bob,? ? What's actually in the .eep file? It's standard Intel Hex so is easy to decode.? ? All the best for now,? John? ? bobgardner@aol.com wrote:? > Can the compiler understand an initialized float in the eeprom section?? >? > float thing=1.234; //<---- map file shows 0000s makes me think it aint > flyin? > ------------------------------------------------------------------------? > Find phone numbers fast with the New AOL Yellow Pages > !? > ------------------------------------------------------------------------? >? > _______________________________________________? > 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/20081001/3806b7b5/attachment.html From bobgardner at aol.com Wed Oct 1 09:27:20 2008 From: bobgardner at aol.com (bobgardner@aol.com) Date: Wed Oct 1 10:31:20 2008 Subject: [Icc-avr] Math sin function In-Reply-To: <24198.204.19.71.2.1222877338.squirrel@www.microsyl.com> References: <8CAF1F1C301B962-CA0-191@mblk-d38.sysops.aol.com> <24198.204.19.71.2.1222877338.squirrel@www.microsyl.com> Message-ID: <8CAF1F9B66F3F6F-CA0-62E@mblk-d38.sysops.aol.com> The sin function evaluates a polynomial with a half dozen terms, so there are a?halfdozen fp mults and adds. ? -----Original Message----- From: bibi@microsyl.com Sent: Wed, 1 Oct 2008 12:08 pm Subject: [Icc-avr] Math sin function Hi, Could you told me if sin(0.1) will be execute faster than sin(0.08123) Thanks Sylvain Bissonnette _______________________________________________ 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/20081001/712e09d8/attachment.html From j_baraclough at zetnet.co.uk Wed Oct 1 09:39:01 2008 From: j_baraclough at zetnet.co.uk (John Baraclough) Date: Wed Oct 1 10:43:02 2008 Subject: [Icc-avr] Math sin function In-Reply-To: <8CAF1F9B66F3F6F-CA0-62E@mblk-d38.sysops.aol.com> References: <8CAF1F1C301B962-CA0-191@mblk-d38.sysops.aol.com> <24198.204.19.71.2.1222877338.squirrel@www.microsyl.com> <8CAF1F9B66F3F6F-CA0-62E@mblk-d38.sysops.aol.com> Message-ID: <48E3A7A5.3040005@zetnet.co.uk> Although sin() is a requisite part of the C language, it should not be used in an embedded environment unless you have plenty of processing time to waste. Look at the resolution you need and pre-calculate a look-up table with Excel or something similar. You only need the first quadrant and then use reflection and inversion. All the best for now, John bobgardner@aol.com wrote: > > The sin function evaluates a polynomial with a half dozen terms, so > there are a halfdozen fp mults and adds. > > -----Original Message----- > From: bibi@microsyl.com > Sent: Wed, 1 Oct 2008 12:08 pm > Subject: [Icc-avr] Math sin function > > Hi, > > Could you told me if sin(0.1) will be execute faster than sin(0.08123) > > Thanks > Sylvain Bissonnette > > _______________________________________________ > Icc-avr mailing list > Icc-avr@imagecraft.com > http://dragonsgate.net/mailman/listinfo/icc-avr > ------------------------------------------------------------------------ > Find phone numbers fast with the New AOL Yellow Pages > ! > ------------------------------------------------------------------------ > > _______________________________________________ > Icc-avr mailing list > Icc-avr@imagecraft.com > http://dragonsgate.net/mailman/listinfo/icc-avr > From jassenbaum at htp-tel.de Wed Oct 1 17:02:03 2008 From: jassenbaum at htp-tel.de (Johannes Assenbaum) Date: Wed Oct 1 18:05:42 2008 Subject: [Icc-avr] cant init a flot in eeprom?!? References: <8CAF1F1C301B962-CA0-191@mblk-d38.sysops.aol.com> Message-ID: <0kgqaAP5FHlZGwdLGQ78S203cTNOO7lUW0TYoQsOIQt@akmail> Hi Bob, AFAIK in the eeprom section any typedef is allowed, as long as data is initialized. Best regards, Johannes > Can the compiler understand an initialized float in the eeprom section? > float thing=1.234; //<---- map file shows 0000s makes me think it aint flyin From bibi at microsyl.com Wed Oct 1 21:36:56 2008 From: bibi at microsyl.com (Sylvain Bissonnette) Date: Wed Oct 1 21:43:01 2008 Subject: [Icc-avr] Math sin function Message-ID: <001101c92448$804e2520$0301a8c0@Sylvain> Hi, Thanks for your info, I had done a lookup table via excel and it's good for what I need, Sylvain Bissonnette -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20081001/064b2a5e/attachment.html From bjonaspero at hotmail.com Thu Oct 2 00:46:43 2008 From: bjonaspero at hotmail.com (=?Windows-1252?Q?Bj=F6rn_Lindgren?=) Date: Thu Oct 2 01:50:22 2008 Subject: [Icc-avr] Digital to analogue converter (PWM3B) In-Reply-To: <001101c92448$804e2520$0301a8c0@Sylvain> References: <001101c92448$804e2520$0301a8c0@Sylvain> Message-ID: Dear List I just discovered a strange thing concerning the DAC in the AT90PWM3B device. Atmel have for some strange reason changed the write-order of the DACL/DACH registers. The normal AVR-write style is high first, then low (and read the other way around) BUT using 10-bits to the DAC, low byte should be written first and then high!! This means that the defined base-register ?DAC? (in ioPWM3Bv.h) cannot be used. DAC = value; // 0..1023 !!DOES NOT WORK PROPERLY!! Use instead: DACL = value; // Write low first DACH = value >> 8; // Then high Johannes, it might be a good idea to remove the line: #define DAC (*(volatile unsigned int *)0xAB) /* m/m */ in the header-file, in order to avid problems for others. Regards, Bj?rn Lindgren _________________________________________________________________ Explore the seven wonders of the world http://search.msn.com/results.aspx?q=7+wonders+world&mkt=en-US&form=QBRE -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20081002/069dd395/attachment.html From benra at imt.liu.se Thu Oct 2 23:04:24 2008 From: benra at imt.liu.se (Bengt Ragnemalm) Date: Fri Oct 3 00:07:58 2008 Subject: SV: [Icc-avr] Digital to analogue converter (PWM3B) In-Reply-To: References: <001101c92448$804e2520$0301a8c0@Sylvain> Message-ID: <4482617DA45F4D0FAAE8D4112C3EF2FB@Shagrat> Are you sure about this? Have you checked with Atmel first so it is not a fault in the datasheet? /Bengt _____ Fr?n: icc-avr-bounces@imagecraft.com [mailto:icc-avr-bounces@imagecraft.com] F?r Bj?rn Lindgren Skickat: den 2 oktober 2008 09:47 Till: Discussion list for ICCAVR and ICCtiny Users. You do NOT need tosubscribe to icc-announce if you are a member of this. ?mne: [Icc-avr] Digital to analogue converter (PWM3B) Dear List I just discovered a strange thing concerning the DAC in the AT90PWM3B device. Atmel have for some strange reason changed the write-order of the DACL/DACH registers. The normal AVR-write style is high first, then low (and read the other way around) BUT using 10-bits to the DAC, low byte should be written first and then high!! This means that the defined base-register ?DAC? (in ioPWM3Bv.h) cannot be used. DAC = value; // 0..1023 !!DOES NOT WORK PROPERLY!! Use instead: DACL = value; // Write low first DACH = value >> 8; // Then high Johannes, it might be a good idea to remove the line: #define DAC (*(volatile unsigned int *)0xAB) /* m/m */ in the header-file, in order to avid problems for others. Regards, Bj?rn Lindgren _____ Explore the seven wonders of the world Learn more! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20081003/7d50f0f1/attachment.html From richard at imagecraft.com Fri Oct 3 19:47:07 2008 From: richard at imagecraft.com (Richard Man) Date: Fri Oct 3 20:52:19 2008 Subject: [Icc-avr] eMOS beta testers wanted Message-ID: <200810040352.m943qH2d045327@mail.imagecraft.com> We should be able to beta test eMOS (embedded message passing RTOS) sometimes next week. I need to add the timer, RTC and comm stuff, but the core is working pretty well. The preliminary un-cleanuped doc is here http://www.dragonsgate.net/pub/BETAS/emos_avr_doc.zip Let me know what you think, and if you are interested in beta testing, please send me info about your target (e.g. which AVR) and whether you can have sample projects that you can convert to use eMOS for testing purpose. Thanks. // 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 kenhicks at shaw.ca Tue Oct 7 05:32:17 2008 From: kenhicks at shaw.ca (Ken Hicks) Date: Tue Oct 7 06:36:07 2008 Subject: [Icc-avr] area 'text' not large enough Message-ID: Hi Guys I need some help figuring out an error I'm getting when compiling my project. I have been using the ICCAVR compiler for several years. I just recently changed to version 7. My current project has been getting bigger and bigger. So I decided to change to a MEGA 64 chip. I changed the Project/Options/Device configuration to ATMEGA 64 and recompiled the project. I expected to only have 50% memory full. When compiling the project I get an error saying "area 'text' not large enough" My project compiles with ATMEGA 32 at 98% full. I went back and recompiled some of my old projects that used version 6 of the compiler and they all had the same problem. If I compile them with version 6 they only have about 80% memory full. I have been trouble shooting this problem for a week now and can't seem to find a solution. Am I doing something wrong ??? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20081007/d44d4393/attachment.html From j_baraclough at zetnet.co.uk Tue Oct 7 05:49:18 2008 From: j_baraclough at zetnet.co.uk (John Baraclough) Date: Tue Oct 7 06:53:27 2008 Subject: [Icc-avr] area 'text' not large enough In-Reply-To: References: Message-ID: <48EB5ACE.5020702@zetnet.co.uk> Hi Ken, It's most likely to be the wrong header file. I expect you've forgotten to change the: #include to: #include Better still, if you use: #include then the compiler does the work for you. You also need to be sure to remove the reference to the version 6 libraries in the Project -> Options -> Paths pop-up menu. The version 7 compiler automatically adds it to the end of the list. All the best for now, John Ken Hicks wrote: > Hi Guys > > I need some help figuring out an error I'm getting when compiling my > project. > > I have been using the ICCAVR compiler for several years. I just > recently changed to > version 7. > > My current project has been getting bigger and bigger. So I decided to > change to a MEGA 64 chip. > > I changed the Project/Options/Device configuration to ATMEGA 64 > and recompiled the project. > I expected to only have 50% memory full. > > When compiling the project I get an error saying "area 'text' not > large enough" > > My project compiles with ATMEGA 32 at 98% full. > > I went back and recompiled some of my old projects that used version 6 > of the compiler > and they all had the same problem. If I compile them with version 6 > they only have about > 80% memory full. > > I have been trouble shooting this problem for a week now and can't > seem to find a solution. > > Am I doing something wrong ??? > ------------------------------------------------------------------------ > > _______________________________________________ > Icc-avr mailing list > Icc-avr@imagecraft.com > http://dragonsgate.net/mailman/listinfo/icc-avr > From t.jaspers at cpseurope.com Tue Oct 7 06:36:35 2008 From: t.jaspers at cpseurope.com (Jaspers, Ton) Date: Tue Oct 7 07:40:24 2008 Subject: [Icc-avr] Atmel VS Microchip In-Reply-To: <24198.204.19.71.2.1222877338.squirrel@www.microsyl.com> Message-ID: <7B0EB27CF1CC93439B5CFB7526E5D74C72691D@mickey.PBNV.local> Hi, I wander if you all heard the news about the hostile bid by Microchip on Atmel? As I understand it Microchip is mainly interested in the AVR division of Atmel (kill the PIC killer?). I sure hope I don't have to go back to programming PIC's again. Its old technology IMHO. Cheers, Ton Jaspers From cirn at uniquedesigns.co.za Tue Oct 7 09:47:01 2008 From: cirn at uniquedesigns.co.za (cirn@uniquedesigns.co.za) Date: Tue Oct 7 10:43:09 2008 Subject: [Icc-avr] Atmel VS Microchip In-Reply-To: <7B0EB27CF1CC93439B5CFB7526E5D74C72691D@mickey.PBNV.local> References: <24198.204.19.71.2.1222877338.squirrel@www.microsyl.com> <7B0EB27CF1CC93439B5CFB7526E5D74C72691D@mickey.PBNV.local> Message-ID: I switched to Atmel for the bigger devices. I lost to much time with PICs. There are also to many. Rod -----Original Message----- From: icc-avr-bounces@imagecraft.com [mailto:icc-avr-bounces@imagecraft.com] On Behalf Of Jaspers, Ton Sent: 07 October 2008 03:37 PM To: Discussion list for ICCAVR and ICCtiny Users. You do NOT need to subscribeto icc-announce if you are a member of this. Subject: [Icc-avr] Atmel VS Microchip Hi, I wander if you all heard the news about the hostile bid by Microchip on Atmel? As I understand it Microchip is mainly interested in the AVR division of Atmel (kill the PIC killer?). I sure hope I don't have to go back to programming PIC's again. Its old technology IMHO. Cheers, Ton Jaspers _______________________________________________ Icc-avr mailing list Icc-avr@imagecraft.com http://dragonsgate.net/mailman/listinfo/icc-avr From ira at extrasensory.com Tue Oct 7 09:55:33 2008 From: ira at extrasensory.com (Ira) Date: Tue Oct 7 10:59:28 2008 Subject: [Icc-avr] Atmel VS Microchip In-Reply-To: References: <24198.204.19.71.2.1222877338.squirrel@www.microsyl.com> <7B0EB27CF1CC93439B5CFB7526E5D74C72691D@mickey.PBNV.local> Message-ID: <0MKp8S-1KnFqT16Am-0001jR@mrelay.perfora.net> At 09:47 AM 10/7/2008, you wrote: >As I understand it Microchip is mainly interested in the AVR division of >Atmel (kill the PIC killer?). I don't think they want to kill Atmel, I think they want the product line. Then again, I've been wrong before. Ira From jassenbaum at htp-tel.de Tue Oct 7 12:06:06 2008 From: jassenbaum at htp-tel.de (Johannes Assenbaum) Date: Tue Oct 7 13:09:56 2008 Subject: [Icc-avr] area 'text' not large enough References: Message-ID: Hi Ken, as you come from version 6, you need to swap system paths from v6 to v7 installation. Go project options / paths page and just delete iccavr link from include and lib paths. Only v6 won't compile without them no more. Best regards, Johannes > Hi Guys > I need some help figuring out an error I'm getting when compiling my project. > I have been using the ICCAVR compiler for several years. I just recently changed to > version 7. > My current project has been getting bigger and bigger. So I decided to change to a > MEGA 64 chip. > I changed the Project/Options/Device configuration to ATMEGA 64 and recompiled the > project. > I expected to only have 50% memory full. > When compiling the project I get an error saying "area 'text' not large enough" > My project compiles with ATMEGA 32 at 98% full. > I went back and recompiled some of my old projects that used version 6 of the > compiler > and they all had the same problem. If I compile them with version 6 they only have > about > 80% memory full. > I have been trouble shooting this problem for a week now and can't seem to find a > solution. > Am I doing something wrong ??? From Albert.vanVeen at pertronic.co.nz Tue Oct 7 12:11:23 2008 From: Albert.vanVeen at pertronic.co.nz (Albert vanVeen) Date: Tue Oct 7 13:15:14 2008 Subject: [Icc-avr] Atmel VS Microchip In-Reply-To: <7B0EB27CF1CC93439B5CFB7526E5D74C72691D@mickey.PBNV.local> References: <24198.204.19.71.2.1222877338.squirrel@www.microsyl.com> <7B0EB27CF1CC93439B5CFB7526E5D74C72691D@mickey.PBNV.local> Message-ID: <5F8515C5ED67B6439B4F93D7B5E08A36063E5F@sbs.pertronic.local> Great things, these PICs; you'd be surprised all the different control projects we use them for, and HiTech has become quite a good compiler too. The architecture is a bit odd I agree. We use Atmegas when PICs are too small. I don't think there will be any technical consequences for us if they 'merge' a companies. Albert. -----Original Message----- From: icc-avr-bounces@imagecraft.com [mailto:icc-avr-bounces@imagecraft.com] On Behalf Of Jaspers, Ton Sent: Wednesday, October 08, 2008 02:37 AM To: Discussion list for ICCAVR and ICCtiny Users. You do NOT need to subscribeto icc-announce if you are a member of this. Subject: [Icc-avr] Atmel VS Microchip Hi, I wander if you all heard the news about the hostile bid by Microchip on Atmel? As I understand it Microchip is mainly interested in the AVR division of Atmel (kill the PIC killer?). I sure hope I don't have to go back to programming PIC's again. Its old technology IMHO. Cheers, Ton Jaspers _______________________________________________ Icc-avr mailing list Icc-avr@imagecraft.com http://dragonsgate.net/mailman/listinfo/icc-avr Scanned by Bizo Email Filter From jassenbaum at htp-tel.de Tue Oct 7 14:09:31 2008 From: jassenbaum at htp-tel.de (Johannes Assenbaum) Date: Tue Oct 7 15:13:23 2008 Subject: [Icc-avr] Atmel VS Microchip References: <24198.204.19.71.2.1222877338.squirrel@www.microsyl.com> <7B0EB27CF1CC93439B5CFB7526E5D74C72691D@mickey.PBNV.local> <5F8515C5ED67B6439B4F93D7B5E08A36063E5F@sbs.pertronic.local> Message-ID: Microchip already bought several chip manufacturers, so why not Atmel, if they are weak enough? I don't beleive, that PIC killer will get killed then, only assimilated. Some parts may not be continued, AVRs as well as PICs, but all higher production parts will survive. For a meantime, Microchip even could continue to produce all parts existing - Atmel's foundry base is big enough. I'm actually more worried about the parts, that shall go to ONsemi. Especially for the flash parts, Onsemi does not seem to be right company for me. Best regards, Johannes > Great things, these PICs; you'd be surprised all the different control > projects we use them for, and HiTech has become quite a good compiler > too. The architecture is a bit odd I agree. > We use Atmegas when PICs are too small. > I don't think there will be any technical consequences for us if they > 'merge' a companies. > Albert. > -----Original Message----- > From: icc-avr-bounces@imagecraft.com > [mailto:icc-avr-bounces@imagecraft.com] On Behalf Of Jaspers, Ton > Sent: Wednesday, October 08, 2008 02:37 AM > To: Discussion list for ICCAVR and ICCtiny Users. You do NOT need to > subscribeto icc-announce if you are a member of this. > Subject: [Icc-avr] Atmel VS Microchip > Hi, > I wander if you all heard the news about the hostile bid by Microchip on > Atmel? > As I understand it Microchip is mainly interested in the AVR division of > Atmel (kill the PIC killer?). > I sure hope I don't have to go back to programming PIC's again. Its old > technology IMHO. > Cheers, > Ton Jaspers > _______________________________________________ > Icc-avr mailing list > Icc-avr@imagecraft.com > http://dragonsgate.net/mailman/listinfo/icc-avr > Scanned by Bizo Email Filter > _______________________________________________ > Icc-avr mailing list > Icc-avr@imagecraft.com > http://dragonsgate.net/mailman/listinfo/icc-avr From richard-lists at imagecraft.com Tue Oct 7 15:49:34 2008 From: richard-lists at imagecraft.com (Richard Man) Date: Tue Oct 7 16:54:21 2008 Subject: [Icc-avr] Atmel VS Microchip In-Reply-To: References: <24198.204.19.71.2.1222877338.squirrel@www.microsyl.com> <7B0EB27CF1CC93439B5CFB7526E5D74C72691D@mickey.PBNV.local> <5F8515C5ED67B6439B4F93D7B5E08A36063E5F@sbs.pertronic.local> Message-ID: <200810072354.m97NsJLn027907@mail.imagecraft.com> I have zero insider info, I wish I do, so all is speculation on my part. If we take the offer at face value, but think through what a reasonable thing for Microchip to do, it would be to preserve the AVR line as is. Then they will own the 8 bits market with some 8051 vendors picking over the rest. There is absolutely no reason to kill AVR per se, since an AVR sale is still a sale. They also immediately gain a sizable entry to the 32 bits market in the forms of ARM7 and ARM9. What they mean do to their just released PIC32 based on MIPS would be unclear, neither would be AVR32 :-(. Interesting time indeed.... At 02:09 PM 10/7/2008, Johannes Assenbaum wrote: >Microchip already bought several chip manufacturers, so why not >Atmel, if they are weak enough? > >I don't beleive, that PIC killer will get killed then, only >assimilated. Some parts may not be continued, AVRs as well as PICs, >but all higher production parts will survive. For a meantime, >Microchip even could continue to produce all parts existing - >Atmel's foundry base is big enough. > >I'm actually more worried about the parts, that shall go to ONsemi. >Especially for the flash parts, Onsemi does not seem to be right >company for me. // richard (This email is for mailing lists. To reach me directly, please use richard at imagecraft.com) From kenhicks at shaw.ca Tue Oct 7 19:52:56 2008 From: kenhicks at shaw.ca (Ken Hicks) Date: Tue Oct 7 20:56:44 2008 Subject: [Icc-avr] area 'text' not large enough Message-ID: Thanks John Baraclough and Johannes Assenbaum for your prompt replies I double checked my project path settings for ICCACVR V7 and they seem to be fine. John's suggestion about the include file was right on the money. I changed to the #include and it worked great. I got the program to compile using the ATmega 64, but it still said 99% full. Changing to the ATMEGA 32 compiles and say's 98% full. Figure that out ? I tried to compile some of my old projects that used V6 of the compiler, using V7. They all failed and gave the "area 'text' not large enough" errors. I re-activated the V6 complier and the programs compiled just fine. I still think I'm doing something wrong. Any more ideas would be appreciated. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20081007/bd0ada39/attachment.html From t.jaspers at cpseurope.com Wed Oct 8 01:22:19 2008 From: t.jaspers at cpseurope.com (Jaspers, Ton) Date: Wed Oct 8 02:26:11 2008 Subject: [Icc-avr] Atmel VS Microchip In-Reply-To: <200810072354.m97NsJLn027907@mail.imagecraft.com> Message-ID: <7B0EB27CF1CC93439B5CFB7526E5D74C726977@mickey.PBNV.local> I already have one customer postponing a 3000 units follow-up order due to the Microchip bid. He wants to wait and see how things develop.... Bummer! Cheers, Ton > -----Original Message----- > From: icc-avr-bounces@imagecraft.com > [mailto:icc-avr-bounces@imagecraft.com] On Behalf Of Richard Man > Sent: woensdag 8 oktober 2008 0:50 > To: icc-avr@imagecraft.com > Subject: RE: [Icc-avr] Atmel VS Microchip > > I have zero insider info, I wish I do, so all is speculation > on my part. > > If we take the offer at face value, but think through what a > reasonable thing for Microchip to do, it would be to preserve > the AVR line as is. Then they will own the 8 bits market with > some 8051 vendors picking over the rest. There is absolutely > no reason to kill AVR per se, since an AVR sale is still a > sale. They also immediately gain a sizable entry to the 32 > bits market in the forms of ARM7 and ARM9. What they mean do > to their just released PIC32 based on MIPS would be unclear, > neither would be AVR32 :-(. > > Interesting time indeed.... > > At 02:09 PM 10/7/2008, Johannes Assenbaum wrote: > >Microchip already bought several chip manufacturers, so why > not Atmel, > >if they are weak enough? > > > >I don't beleive, that PIC killer will get killed then, only > >assimilated. Some parts may not be continued, AVRs as well > as PICs, but > >all higher production parts will survive. For a meantime, Microchip > >even could continue to produce all parts existing - Atmel's foundry > >base is big enough. > > > >I'm actually more worried about the parts, that shall go to ONsemi. > >Especially for the flash parts, Onsemi does not seem to be right > >company for me. > > // richard (This email is for mailing lists. To reach me > directly, please use richard at imagecraft.com) > > _______________________________________________ > Icc-avr mailing list > Icc-avr@imagecraft.com > http://dragonsgate.net/mailman/listinfo/icc-avr > From bobgardner at aol.com Wed Oct 8 03:22:25 2008 From: bobgardner at aol.com (bobgardner@aol.com) Date: Wed Oct 8 04:27:19 2008 Subject: [Icc-avr] area 'text' not large enough In-Reply-To: References: Message-ID: <8CAF746E415F503-344-A58@WEBMAIL-MB05.sysops.aol.com> Do you have a standard, advanced or pro license? Might be 32k limited? -----Original Message----- From: Ken Hicks To: ICC AVR News Group Sent: Tue, 7 Oct 2008 10:52 pm Subject: [Icc-avr] area 'text' not large enough Thanks John Baraclough and? Johannes Assenbaum for your prompt replies ? I double checked my project path settings for ICCACVR V7 and they seem to be fine. ? John's suggestion about the include file was right on the money. I changed to the #include and it worked great. ? I got the program to compile using the ATmega 64, but it still said 99% full. Changing to the ATMEGA 32 compiles and say's 98% full. Figure that out ?? ? I tried to compile some of my old projects that used V6 of the compiler, using V7. They all failed and gave the "area 'text' not large enough" errors. ? I re-activated the V6 complier and the programs compiled just fine. ? I still think I'm doing something wrong.? Any more ideas would be appreciated. ? I still think I'm doing something wrong.? Any more ideas would be appreciated. ? _______________________________________________ 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/20081008/03f2aaa6/attachment-0001.html From byron at inhep.com Wed Oct 8 05:13:37 2008 From: byron at inhep.com (Byron Loader) Date: Wed Oct 8 06:18:22 2008 Subject: [Icc-avr] area 'text' not large enough In-Reply-To: <8CAF746E415F503-344-A58@WEBMAIL-MB05.sysops.aol.com> Message-ID: <5624A98BBCB8438EABBEF2800F4962BE@inhep> How big is your original code .. 3.99K Could be you're running on the 4K demo licence? My pc often loses the dongle and I get the same problems. Caught me out a couple of times Byron Loader 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 bobgardner@aol.com Sent: Wednesday, October 08, 2008 12:22 PM To: icc-avr@imagecraft.com Subject: Re: [Icc-avr] area 'text' not large enough Do you have a standard, advanced or pro license? Might be 32k limited? -----Original Message----- From: Ken Hicks To: ICC AVR News Group Sent: Tue, 7 Oct 2008 10:52 pm Subject: [Icc-avr] area 'text' not large enough Thanks John Baraclough and Johannes Assenbaum for your prompt replies I double checked my project path settings for ICCACVR V7 and they seem to be fine. John's suggestion about the include file was right on the money. I changed to the #include and it worked great. I got the program to compile using the ATmega 64, but it still said 99% full. Changing to the ATMEGA 32 compiles and say's 98% full. Figure that out ? I tried to compile some of my old projects that used V6 of the compiler, using V7. They all failed and gave the "area 'text' not large enough" errors. I re-activated the V6 complier and the programs compiled just fine. I still think I'm doing something wrong. Any more ideas would be appreciated. _______________________________________________ Icc-avr mailing list Icc-avr@imagecraft.com http://dragonsgate.net/mailman/listinfo/icc-avr _____ McCain or Obama? Stay updated on coverage of the Presidential race while you browse - Download Now! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20081008/dbcccd8c/attachment.html From rob at usbmicro.com Wed Oct 8 08:47:17 2008 From: rob at usbmicro.com (rob@usbmicro.com) Date: Wed Oct 8 09:51:06 2008 Subject: [Icc-avr] Atmel VS Microchip In-Reply-To: <7B0EB27CF1CC93439B5CFB7526E5D74C726977@mickey.PBNV.local> References: <200810072354.m97NsJLn027907@mail.imagecraft.com> <7B0EB27CF1CC93439B5CFB7526E5D74C726977@mickey.PBNV.local> Message-ID: <877020416.20081008104717@usbmicro.com> Perhaps that was Michochump's plan all along. Make a bid for Atmel to shake confidence in introducing new Atmel designs. Not a very classy move, but probably pushed some people away from Atmel (or perhaps even both.) > I already have one customer postponing a 3000 units follow-up > order due to the Microchip bid. He wants to wait and see how > things develop.... > Bummer! > Cheers, > Ton > >> -----Original Message----- >> From: icc-avr-bounces@imagecraft.com >> [mailto:icc-avr-bounces@imagecraft.com] On Behalf Of Richard Man >> Sent: woensdag 8 oktober 2008 0:50 >> To: icc-avr@imagecraft.com >> Subject: RE: [Icc-avr] Atmel VS Microchip >> >> I have zero insider info, I wish I do, so all is speculation >> on my part. >> >> If we take the offer at face value, but think through what a >> reasonable thing for Microchip to do, it would be to preserve >> the AVR line as is. Then they will own the 8 bits market with >> some 8051 vendors picking over the rest. There is absolutely >> no reason to kill AVR per se, since an AVR sale is still a >> sale. They also immediately gain a sizable entry to the 32 >> bits market in the forms of ARM7 and ARM9. What they mean do >> to their just released PIC32 based on MIPS would be unclear, >> neither would be AVR32 :-(. >> >> Interesting time indeed.... >> >> At 02:09 PM 10/7/2008, Johannes Assenbaum wrote: >> >Microchip already bought several chip manufacturers, so why >> not Atmel, >> >if they are weak enough? >> > >> >I don't beleive, that PIC killer will get killed then, only >> >assimilated. Some parts may not be continued, AVRs as well >> as PICs, but >> >all higher production parts will survive. For a meantime, Microchip >> >even could continue to produce all parts existing - Atmel's foundry >> >base is big enough. >> > >> >I'm actually more worried about the parts, that shall go to ONsemi. >> >Especially for the flash parts, Onsemi does not seem to be right >> >company for me. >> >> // richard (This email is for mailing lists. To reach me >> directly, please use richard at imagecraft.com) >> >> _______________________________________________ >> Icc-avr mailing list >> Icc-avr@imagecraft.com >> http://dragonsgate.net/mailman/listinfo/icc-avr >> > _______________________________________________ > Icc-avr mailing list > Icc-avr@imagecraft.com > http://dragonsgate.net/mailman/listinfo/icc-avr From Albert.vanVeen at pertronic.co.nz Wed Oct 8 12:59:41 2008 From: Albert.vanVeen at pertronic.co.nz (Albert vanVeen) Date: Wed Oct 8 14:03:36 2008 Subject: [Icc-avr] Atmel VS Microchip In-Reply-To: <7B0EB27CF1CC93439B5CFB7526E5D74C726977@mickey.PBNV.local> References: <200810072354.m97NsJLn027907@mail.imagecraft.com> <7B0EB27CF1CC93439B5CFB7526E5D74C726977@mickey.PBNV.local> Message-ID: <5F8515C5ED67B6439B4F93D7B5E08A36063E63@sbs.pertronic.local> I find that a strange attitude from a customer. Follow up and maintenance is your problem, not theirs! Some years ago a range of TMC chips that we were using became obsolete; so we ensured a healthy stock for existing maintenance, and changed to Atmel for new designs. No problem for any customers. They don't even need to know what processor or software is inside, none of our manuals would tell you. Albert. -----Original Message----- From: icc-avr-bounces@imagecraft.com [mailto:icc-avr-bounces@imagecraft.com] On Behalf Of Jaspers, Ton Sent: Wednesday, October 08, 2008 09:22 PM To: Discussion list for ICCAVR and ICCtiny Users. You do NOT need to subscribeto icc-announce if you are a member of this. Subject: RE: [Icc-avr] Atmel VS Microchip I already have one customer postponing a 3000 units follow-up order due to the Microchip bid. He wants to wait and see how things develop.... Bummer! Cheers, Ton > -----Original Message----- > From: icc-avr-bounces@imagecraft.com > [mailto:icc-avr-bounces@imagecraft.com] On Behalf Of Richard Man > Sent: woensdag 8 oktober 2008 0:50 > To: icc-avr@imagecraft.com > Subject: RE: [Icc-avr] Atmel VS Microchip > > I have zero insider info, I wish I do, so all is speculation on my > part. > > If we take the offer at face value, but think through what a > reasonable thing for Microchip to do, it would be to preserve the AVR > line as is. Then they will own the 8 bits market with some 8051 > vendors picking over the rest. There is absolutely no reason to kill > AVR per se, since an AVR sale is still a sale. They also immediately > gain a sizable entry to the 32 bits market in the forms of ARM7 and > ARM9. What they mean do to their just released PIC32 based on MIPS > would be unclear, neither would be AVR32 :-(. > > Interesting time indeed.... > > At 02:09 PM 10/7/2008, Johannes Assenbaum wrote: > >Microchip already bought several chip manufacturers, so why > not Atmel, > >if they are weak enough? > > > >I don't beleive, that PIC killer will get killed then, only > >assimilated. Some parts may not be continued, AVRs as well > as PICs, but > >all higher production parts will survive. For a meantime, Microchip > >even could continue to produce all parts existing - Atmel's foundry > >base is big enough. > > > >I'm actually more worried about the parts, that shall go to ONsemi. > >Especially for the flash parts, Onsemi does not seem to be right > >company for me. > > // richard (This email is for mailing lists. To reach me directly, > please use richard at imagecraft.com) > > _______________________________________________ > Icc-avr mailing list > Icc-avr@imagecraft.com > http://dragonsgate.net/mailman/listinfo/icc-avr > _______________________________________________ Icc-avr mailing list Icc-avr@imagecraft.com http://dragonsgate.net/mailman/listinfo/icc-avr Scanned by Bizo Email Filter From j_baraclough at zetnet.co.uk Wed Oct 8 14:45:42 2008 From: j_baraclough at zetnet.co.uk (John Baraclough) Date: Wed Oct 8 15:50:07 2008 Subject: [Icc-avr] Atmel VS Microchip In-Reply-To: <877020416.20081008104717@usbmicro.com> References: <200810072354.m97NsJLn027907@mail.imagecraft.com> <7B0EB27CF1CC93439B5CFB7526E5D74C726977@mickey.PBNV.local> <877020416.20081008104717@usbmicro.com> Message-ID: <48ED2A06.7050601@zetnet.co.uk> Well. I think Atmel have made a pretty good job of that themselves without any help from outsiders. They appear to have a very limited concept of reverse compatibility in new products. With register changes, different bit allocations and now changing the write order for 16-bit registers they don't seem to talk amongst themselves. Then of course there's the AVR32! What's that all about when they have a perfectly good range of ARM7 & ARM9 processors. It all reminds me of when I worked for Motorola before it became Freescale and we had HC08, HC11, HC16, Coldfire and Power PC. As an applications engineer I would find that customers had had visits from five different groups trying to push their particular processor into the customer's application. It was quite laughable. Anyway my take on the question is that Microchip has a good range of small processors in the PIC12, PIC16 & PIC18 series. Having a very limited register set and instruction set, they are ideal for assembly programming, but very poor for high level programming having code space and RAM which are both banked. On the other hand the Atmel small processers are difficult to code in assembler as the instruction set is so vast, but the larger processors are ideal for high level programming. If the takeover happens (which begins to look doubtful in the current financial climate) I see the ideal solution as all PICs larger than PIC18 and all AVRs smaller than mega32 get dumped (unfortunately mega 8 is one of my favourites for small applications), along with AVR32 & PIC32 and Microchip gets a ready made range of ARM processors which continue to be made in Atmel fabs. Anyone who currently uses the Atmel Tiny range should be able to switch to PIC12 or PIC16 in just a few weeks. Unfortunately the reverse exercise for anyone who currently uses the larger Microchip processors might not be so smooth, but ICCAVR will of course help to negotiate that path. There is of course a very large duplication in the other chip ranges of both manufactures, ADCs, DACs and power sensing for example, so these ranges will no doubt be rationalised. Just my 2 pennyworth (or 2 cents at the current exchange rate ;-) ). All the best for now, John rob@usbmicro.com wrote: > Perhaps that was Michochump's plan all along. Make a bid for Atmel to > shake confidence in introducing new Atmel designs. Not a very classy > move, but probably pushed some people away from Atmel (or perhaps even > both.) > From j_baraclough at zetnet.co.uk Wed Oct 8 15:26:55 2008 From: j_baraclough at zetnet.co.uk (John Baraclough) Date: Wed Oct 8 16:31:19 2008 Subject: [Icc-avr] Atmel VS Microchip In-Reply-To: <48ED2A06.7050601@zetnet.co.uk> References: <200810072354.m97NsJLn027907@mail.imagecraft.com> <7B0EB27CF1CC93439B5CFB7526E5D74C726977@mickey.PBNV.local> <877020416.20081008104717@usbmicro.com> <48ED2A06.7050601@zetnet.co.uk> Message-ID: <48ED33AF.7040808@zetnet.co.uk> Sorry but this post seems to have lost its first few words which should have read: Atmel seem to have managed this themselves .... John Baraclough wrote: > without any help from outsiders. They appear to have a very limited > concept of reverse compatibility in new products. With register > changes, different bit allocations and now changing the write order > for 16-bit registers they don't seem to talk amongst themselves. Then > of course there's the AVR32! What's that all about when they have a > perfectly good range of ARM7 & ARM9 processors. > > It all reminds me of when I worked for Motorola before it became > Freescale and we had HC08, HC11, HC16, Coldfire and Power PC. As an > applications engineer I would find that customers had had visits from > five different groups trying to push their particular processor into > the customer's application. It was quite laughable. > > Anyway my take on the question is that Microchip has a good range of > small processors in the PIC12, PIC16 & PIC18 series. Having a very > limited register set and instruction set, they are ideal for assembly > programming, but very poor for high level programming having code > space and RAM which are both banked. On the other hand the Atmel small > processers are difficult to code in assembler as the instruction set > is so vast, but the larger processors are ideal for high level > programming. > > If the takeover happens (which begins to look doubtful in the current > financial climate) I see the ideal solution as all PICs larger than > PIC18 and all AVRs smaller than mega32 get dumped (unfortunately mega > 8 is one of my favourites for small applications), along with AVR32 & > PIC32 and Microchip gets a ready made range of ARM processors which > continue to be made in Atmel fabs. Anyone who currently uses the Atmel > Tiny range should be able to switch to PIC12 or PIC16 in just a few > weeks. Unfortunately the reverse exercise for anyone who currently > uses the larger Microchip processors might not be so smooth, but > ICCAVR will of course help to negotiate that path. > > There is of course a very large duplication in the other chip ranges > of both manufactures, ADCs, DACs and power sensing for example, so > these ranges will no doubt be rationalised. > > Just my 2 pennyworth (or 2 cents at the current exchange rate ;-) ). > > All the best for now, > John > > > rob@usbmicro.com wrote: >> Perhaps that was Michochump's plan all along. Make a bid for Atmel to >> shake confidence in introducing new Atmel designs. Not a very classy >> move, but probably pushed some people away from Atmel (or perhaps even >> both.) >> > > _______________________________________________ > Icc-avr mailing list > Icc-avr@imagecraft.com > http://dragonsgate.net/mailman/listinfo/icc-avr > > . > From kenhicks at shaw.ca Wed Oct 8 17:47:24 2008 From: kenhicks at shaw.ca (Ken Hicks) Date: Wed Oct 8 18:51:13 2008 Subject: [Icc-avr] area 'test' not large enough problem solved Message-ID: <8E576BEDEE84490FBF25BB7030AE0FEA@kenneth55d18f9> Thanks guys for your help. Byron Loader hit the nail on the head. Some how my usb dongle didn't get installed properly. So the code got limited to 4K. I re-installed the usb driver and it now works just great. Took me a week to figure this out. Must be something about getting older. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20081008/792ca9f2/attachment.html From richard-lists at imagecraft.com Wed Oct 8 17:54:31 2008 From: richard-lists at imagecraft.com (Richard Man) Date: Wed Oct 8 18:59:29 2008 Subject: [Icc-avr] area 'test' not large enough problem solved In-Reply-To: <8E576BEDEE84490FBF25BB7030AE0FEA@kenneth55d18f9> References: <8E576BEDEE84490FBF25BB7030AE0FEA@kenneth55d18f9> Message-ID: <200810090159.m991xRDf056229@mail.imagecraft.com> An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20081008/a2624c05/attachment.html From byron at inhep.com Wed Oct 8 22:49:34 2008 From: byron at inhep.com (Byron Loader) Date: Wed Oct 8 23:54:07 2008 Subject: [Icc-avr] area 'test' not large enough problem solved In-Reply-To: <200810090159.m991xRDf056229@mail.imagecraft.com> Message-ID: Not if the Dongle is 'lost' by windows after the program had already started. Build 7.17 Byron Loader 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 Richard Man Sent: Thursday, October 09, 2008 2:55 AM To: icc-avr@imagecraft.com Subject: Re: [Icc-avr] area 'test' not large enough problem solved What version of the IDE are you using? The title bar should say "4K Limited?" At 05:47 PM 10/8/2008, Ken Hicks wrote: Thanks guys for your help. Byron Loader hit the nail on the head. Some how my usb dongle didn't get installed properly. So the code got limited to 4K. I re-installed the usb driver and it now works just great. Took me a week to figure this out. Must be something about getting older. // richard (This email is for mailing lists. To reach me directly, please use richard at imagecraft.com) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20081009/73a9d113/attachment-0001.html From kenhicks at shaw.ca Fri Oct 10 05:42:01 2008 From: kenhicks at shaw.ca (Ken Hicks) Date: Fri Oct 10 06:45:54 2008 Subject: [Icc-avr] area 'test' not large enough problem solved References: <8E576BEDEE84490FBF25BB7030AE0FEA@kenneth55d18f9> <200810090159.m991xRDf056229@mail.imagecraft.com> Message-ID: <1888472F537D41A6A0185F4C8375D901@kenneth55d18f9> Hi Richard My titlebar said 4K limited when I started. I installed the hardware dongle drivers about six months ago. Since then I've upgaded several times and now using V7.19. I can't say for sure what happed. But re-installing the hardware dongle drivers fixed the compiler and the title bar now say's 64K limited and everything works just fine now. ----- Original Message ----- From: Richard Man To: icc-avr@imagecraft.com Sent: Wednesday, October 08, 2008 5:54 PM Subject: Re: [Icc-avr] area 'test' not large enough problem solved What version of the IDE are you using? The title bar should say "4K Limited?" At 05:47 PM 10/8/2008, Ken Hicks wrote: Thanks guys for your help. Byron Loader hit the nail on the head. Some how my usb dongle didn't get installed properly. So the code got limited to 4K. I re-installed the usb driver and it now works just great. Took me a week to figure this out. Must be something about getting older. // richard (This email is for mailing lists. To reach me directly, please use richard at imagecraft.com) ------------------------------------------------------------------------------ _______________________________________________ Icc-avr mailing list Icc-avr@imagecraft.com http://dragonsgate.net/mailman/listinfo/icc-avr -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20081010/a07fdbde/attachment.html From Albert.vanVeen at pertronic.co.nz Tue Oct 21 13:16:06 2008 From: Albert.vanVeen at pertronic.co.nz (Albert vanVeen) Date: Tue Oct 21 14:20:23 2008 Subject: [Icc-avr] interrupt handlers Message-ID: <5F8515C5ED67B6439B4F93D7B5E08A36063E74@sbs.pertronic.local> I have a time critical application driven by 2 interrupts (timer and external). The interrupt handlers seem to blindly save/restore ALL registers, yet only a few are used. Looking in the listings, the timer0_ovf uses R2, R20, R24, R25, but on entry & exit it does all registers R0..R31. Is there a way to avoid this superfluous overhead? Albert. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20081022/a85006e1/attachment.html From benra at imt.liu.se Tue Oct 21 22:51:44 2008 From: benra at imt.liu.se (Bengt Ragnemalm) Date: Tue Oct 21 23:55:48 2008 Subject: SV: [Icc-avr] interrupt handlers In-Reply-To: <5F8515C5ED67B6439B4F93D7B5E08A36063E74@sbs.pertronic.local> References: <5F8515C5ED67B6439B4F93D7B5E08A36063E74@sbs.pertronic.local> Message-ID: <6C3F2C11D7454294A4425AD7B9D9F415@Shagrat> Maybe you are calling some external function from within the interrupt handler? In that case the compiler has too much problem to find out the registers you are using so all are saved. /Bengt _____ Fr?n: icc-avr-bounces@imagecraft.com [mailto:icc-avr-bounces@imagecraft.com] F?r Albert vanVeen Skickat: den 21 oktober 2008 22:16 Till: Discussion list for ICCAVR and ICCtiny Users. You do NOT needtosubscribeto icc-announce if you are a member of this. ?mne: [Icc-avr] interrupt handlers I have a time critical application driven by 2 interrupts (timer and external). The interrupt handlers seem to blindly save/restore ALL registers, yet only a few are used. Looking in the listings, the timer0_ovf uses R2, R20, R24, R25, but on entry & exit it does all registers R0..R31. Is there a way to avoid this superfluous overhead? Albert. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20081022/0e3b5ee0/attachment.html From johan at edab.nu Wed Oct 22 00:38:42 2008 From: johan at edab.nu (=?ISO-8859-1?Q?Johan_Wallstr=F6m?=) Date: Wed Oct 22 01:42:56 2008 Subject: [Icc-avr] Moving text area In-Reply-To: <6C3F2C11D7454294A4425AD7B9D9F415@Shagrat> References: <5F8515C5ED67B6439B4F93D7B5E08A36063E74@sbs.pertronic.local> <6C3F2C11D7454294A4425AD7B9D9F415@Shagrat> Message-ID: <48FED882.6040800@edab.nu> Hi there Is there any way to offset the text area a bit (to create an empty area for a serial id between the vector table and code area)? Without selecting a custom target, so I can still use the iccioavr.h file. regards Johan Wallstr?m From benra at imt.liu.se Wed Oct 22 00:57:43 2008 From: benra at imt.liu.se (Bengt Ragnemalm) Date: Wed Oct 22 02:01:43 2008 Subject: SV: [Icc-avr] Moving text area In-Reply-To: <48FED882.6040800@edab.nu> References: <5F8515C5ED67B6439B4F93D7B5E08A36063E74@sbs.pertronic.local><6C3F2C11D7454294A4425AD7B9D9F415@Shagrat> <48FED882.6040800@edab.nu> Message-ID: You can easily make your own start-up file. Search for it in the help files. > -----Ursprungligt meddelande----- > Fr?n: icc-avr-bounces@imagecraft.com [mailto:icc-avr- > bounces@imagecraft.com] F?r Johan Wallstr?m > Skickat: den 22 oktober 2008 09:39 > Till: Discussion list for ICCAVR and ICCtiny Users. You do NOT need > tosubscribe to icc-announce if you are a member of this. > ?mne: [Icc-avr] Moving text area > > Hi there > > Is there any way to offset the text area a bit (to create an empty area > for a serial id between the vector table and code area)? > Without selecting a custom target, so I can still use the iccioavr.h file. > > regards > Johan Wallstr?m > _______________________________________________ > Icc-avr mailing list > Icc-avr@imagecraft.com > http://dragonsgate.net/mailman/listinfo/icc-avr From j_baraclough at zetnet.co.uk Wed Oct 22 01:52:52 2008 From: j_baraclough at zetnet.co.uk (John Baraclough) Date: Wed Oct 22 02:57:02 2008 Subject: [Icc-avr] interrupt handlers In-Reply-To: <5F8515C5ED67B6439B4F93D7B5E08A36063E74@sbs.pertronic.local> References: <5F8515C5ED67B6439B4F93D7B5E08A36063E74@sbs.pertronic.local> Message-ID: <48FEE9E4.7060905@zetnet.co.uk> It's not ideal, but the quickest solution is to copy the listing of the interrupt handler into an assembler file and delete the unnecessary pushes and pops, then include that file in place of the C file. Richard may have a more elegant solution. All the best for now, John Albert vanVeen wrote: > I have a time critical application driven by 2 interrupts (timer and > external). The interrupt handlers seem to blindly save/restore ALL > registers, yet only a few are used. Looking in the listings, the > timer0_ovf uses R2, R20, R24, R25, but on entry & exit it does all > registers R0..R31. > Is there a way to avoid this superfluous overhead? > > Albert. > > > ------------------------------------------------------------------------ > > _______________________________________________ > Icc-avr mailing list > Icc-avr@imagecraft.com > http://dragonsgate.net/mailman/listinfo/icc-avr > From richard-lists at imagecraft.com Wed Oct 22 12:30:49 2008 From: richard-lists at imagecraft.com (Richard Man) Date: Wed Oct 22 13:36:36 2008 Subject: [Icc-avr] Moving text area In-Reply-To: <48FED882.6040800@edab.nu> References: <5F8515C5ED67B6439B4F93D7B5E08A36063E74@sbs.pertronic.local> <6C3F2C11D7454294A4425AD7B9D9F415@Shagrat> <48FED882.6040800@edab.nu> Message-ID: <200810222036.m9MKaYY7094090@mail.imagecraft.com> Not ideal, but you can change it to Custom, then add the device name to the Macro Define box in the "compiler" tab. At 12:38 AM 10/22/2008, Johan Wallstr?m wrote: >Hi there > >Is there any way to offset the text area a bit >(to create an empty area for a serial id between >the vector table and code area)? >Without selecting a custom target, so I can still use the iccioavr.h file. > // richard (This email is for mailing lists. To reach me directly, please use richard at imagecraft.com) From Albert.vanVeen at pertronic.co.nz Wed Oct 22 13:18:29 2008 From: Albert.vanVeen at pertronic.co.nz (Albert vanVeen) Date: Wed Oct 22 14:22:37 2008 Subject: [Icc-avr] interrupt handlers In-Reply-To: <6C3F2C11D7454294A4425AD7B9D9F415@Shagrat> References: <5F8515C5ED67B6439B4F93D7B5E08A36063E74@sbs.pertronic.local> <6C3F2C11D7454294A4425AD7B9D9F415@Shagrat> Message-ID: <5F8515C5ED67B6439B4F93D7B5E08A36063E75@sbs.pertronic.local> Yes Bengt, your answer is correct. I was actually calling a function without realising it. Copying somebody else's code, I thought it was a macro. I put the function code inline, and now it only saves the really necessary registers. Sorry Richard for implicitly insulting you! Albert. ________________________________ From: icc-avr-bounces@imagecraft.com [mailto:icc-avr-bounces@imagecraft.com] On Behalf Of Bengt Ragnemalm Sent: Wednesday, October 22, 2008 06:52 PM To: 'Discussion list for ICCAVR and ICCtiny Users. You do NOT needtosubscribeto icc-announce if you are a member of this.' Subject: SV: [Icc-avr] interrupt handlers Maybe you are calling some external function from within the interrupt handler? In that case the compiler has too much problem to find out the registers you are using so all are saved. /Bengt ________________________________ Fr?n: icc-avr-bounces@imagecraft.com [mailto:icc-avr-bounces@imagecraft.com] F?r Albert vanVeen Skickat: den 21 oktober 2008 22:16 Till: Discussion list for ICCAVR and ICCtiny Users. You do NOT needtosubscribeto icc-announce if you are a member of this. ?mne: [Icc-avr] interrupt handlers I have a time critical application driven by 2 interrupts (timer and external). The interrupt handlers seem to blindly save/restore ALL registers, yet only a few are used. Looking in the listings, the timer0_ovf uses R2, R20, R24, R25, but on entry & exit it does all registers R0..R31. Is there a way to avoid this superfluous overhead? Albert. Scanned by Bizo EmailFilter -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20081023/f7f8f8d5/attachment.html From bobgardner at aol.com Wed Oct 22 17:53:48 2008 From: bobgardner at aol.com (bobgardner@aol.com) Date: Wed Oct 22 18:58:17 2008 Subject: [Icc-avr] interrupt handlers In-Reply-To: <5F8515C5ED67B6439B4F93D7B5E08A36063E75@sbs.pertronic.local> References: <5F8515C5ED67B6439B4F93D7B5E08A36063E74@sbs.pertronic.local><6C3F2C11D7454294A4425AD7B9D9F415@Shagrat> <5F8515C5ED67B6439B4F93D7B5E08A36063E75@sbs.pertronic.local> Message-ID: <8CB02C0F170D8AA-12B8-FE5@webmail-da01.sysops.aol.com> I was actually calling a function without realising it. Copying somebody else's code, I thought it was a macro. I put the function code inline, and now it only saves the really necessary registers. =============================================== Its tough at the top aint it? Thats why Hendrix and Clapton were driven to drugs. Some hotshot always gunnin' for em. Wonder if they give ol Bjarne a hard time when someone's c++ program acts flaky? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20081022/49fe4954/attachment.html From johan at edab.nu Fri Oct 24 07:12:07 2008 From: johan at edab.nu (=?ISO-8859-1?Q?Johan_Wallstr=F6m?=) Date: Fri Oct 24 08:16:20 2008 Subject: [Icc-avr] text_end In-Reply-To: <200810222036.m9MKaYY7094090@mail.imagecraft.com> References: <5F8515C5ED67B6439B4F93D7B5E08A36063E74@sbs.pertronic.local> <6C3F2C11D7454294A4425AD7B9D9F415@Shagrat> <48FED882.6040800@edab.nu> <200810222036.m9MKaYY7094090@mail.imagecraft.com> Message-ID: <4901D7B7.6050305@edab.nu> Hi gang Is it possible to access the _text_end label from C, like it is from asm? best regards Johan W Richard Man skrev: > Not ideal, but you can change it to Custom, then add the device name > to the Macro Define box in the "compiler" tab. > > At 12:38 AM 10/22/2008, Johan Wallstr?m wrote: >> Hi there >> >> Is there any way to offset the text area a bit (to create an empty >> area for a serial id between the vector table and code area)? >> Without selecting a custom target, so I can still use the iccioavr.h >> file. >> > > // richard (This email is for mailing lists. To reach me directly, > please use richard at imagecraft.com) > > _______________________________________________ > Icc-avr mailing list > Icc-avr@imagecraft.com > http://dragonsgate.net/mailman/listinfo/icc-avr > ------------------------------------------------------------------------ > > > No virus found in this incoming message. > Checked by AVG - http://www.avg.com > Version: 8.0.175 / Virus Database: 270.8.2/1738 - Release Date: 2008-10-21 14:10 > > From j_baraclough at zetnet.co.uk Fri Oct 24 09:24:48 2008 From: j_baraclough at zetnet.co.uk (John Baraclough) Date: Fri Oct 24 10:29:01 2008 Subject: [Icc-avr] text_end In-Reply-To: <4901D7B7.6050305@edab.nu> References: <5F8515C5ED67B6439B4F93D7B5E08A36063E74@sbs.pertronic.local> <6C3F2C11D7454294A4425AD7B9D9F415@Shagrat> <48FED882.6040800@edab.nu> <200810222036.m9MKaYY7094090@mail.imagecraft.com> <4901D7B7.6050305@edab.nu> Message-ID: <4901F6D0.20606@zetnet.co.uk> I haven't tried, but since the value of '_text_end' isn't known until the linker has finished its work, I think it's very unlikely. All the best for now, John Johan Wallstr?m wrote: > > Hi gang > > Is it possible to access the _text_end label from C, like it is from asm? > > best regards > Johan W > From hr_iccavr at srel.de Fri Oct 24 09:43:46 2008 From: hr_iccavr at srel.de (Hartmut Reinke) Date: Fri Oct 24 10:47:53 2008 Subject: [Icc-avr] text_end In-Reply-To: <4901D7B7.6050305@edab.nu> References: <5F8515C5ED67B6439B4F93D7B5E08A36063E74@sbs.pertronic.local> <6C3F2C11D7454294A4425AD7B9D9F415@Shagrat> <48FED882.6040800@edab.nu> <200810222036.m9MKaYY7094090@mail.imagecraft.com> <4901D7B7.6050305@edab.nu> Message-ID: <4901FB42.1080001@srel.de> Hi Johan, should work like this: //---------------------------------------------------- extern unsigned char _data_start, _data_end; extern unsigned char _bss_start, _bss_end; extern unsigned const char _text_start, _text_end; const unsigned char *p_ts, *p_te; unsigned char *p_ds, p_de; p_te = &_text_end; p_ts = &_text_start; p_ds = _data_start; p_de = _data_end; //---------------------------------------------------- regards Hartmut Johan Wallstr?m schrieb: > > Hi gang > > Is it possible to access the _text_end label from C, like it is from asm? > > best regards > Johan W > > Richard Man skrev: >> Not ideal, but you can change it to Custom, then add the device name >> to the Macro Define box in the "compiler" tab. >> >> At 12:38 AM 10/22/2008, Johan Wallstr?m wrote: >>> Hi there >>> >>> Is there any way to offset the text area a bit (to create an empty >>> area for a serial id between the vector table and code area)? >>> Without selecting a custom target, so I can still use the iccioavr.h >>> file. >>> >> >> // richard (This email is for mailing lists. To reach me directly, >> please use richard at imagecraft.com) >> >> _______________________________________________ >> Icc-avr mailing list >> Icc-avr@imagecraft.com >> http://dragonsgate.net/mailman/listinfo/icc-avr >> ------------------------------------------------------------------------ >> >> >> No virus found in this incoming message. >> Checked by AVG - http://www.avg.com Version: 8.0.175 / Virus Database: >> 270.8.2/1738 - Release Date: 2008-10-21 14:10 >> >> > > _______________________________________________ > Icc-avr mailing list > Icc-avr@imagecraft.com > http://dragonsgate.net/mailman/listinfo/icc-avr > From johan at edab.nu Sun Oct 26 23:45:06 2008 From: johan at edab.nu (=?ISO-8859-1?Q?Johan_Wallstr=F6m?=) Date: Mon Oct 27 00:49:25 2008 Subject: [Icc-avr] text_end In-Reply-To: <4901FB42.1080001@srel.de> References: <5F8515C5ED67B6439B4F93D7B5E08A36063E74@sbs.pertronic.local> <6C3F2C11D7454294A4425AD7B9D9F415@Shagrat> <48FED882.6040800@edab.nu> <200810222036.m9MKaYY7094090@mail.imagecraft.com> <4901D7B7.6050305@edab.nu> <4901FB42.1080001@srel.de> Message-ID: <49057182.9080601@edab.nu> Thank you for the response. I would like to put it (at a specific position) in flash, so this is what I do: extern unsigned const char _text_end; #pragma lit:MfgData const char *FwLength = &_text_end; The program is compiled without errors, but FwLength is totally omitted by the linker, putting the next label there instead. Hartmut Reinke skrev: > Hi Johan, > > should work like this: > > //---------------------------------------------------- > extern unsigned char _data_start, _data_end; > extern unsigned char _bss_start, _bss_end; > extern unsigned const char _text_start, _text_end; > > > const unsigned char *p_ts, *p_te; > unsigned char *p_ds, p_de; > > p_te = &_text_end; > p_ts = &_text_start; > > p_ds = _data_start; > p_de = _data_end; > //---------------------------------------------------- > > > regards > Hartmut > > > Johan Wallstr?m schrieb: > >> Hi gang >> >> Is it possible to access the _text_end label from C, like it is from asm? >> >> best regards >> Johan W >> >> Richard Man skrev: >> >>> Not ideal, but you can change it to Custom, then add the device name >>> to the Macro Define box in the "compiler" tab. >>> >>> At 12:38 AM 10/22/2008, Johan Wallstr?m wrote: >>> >>>> Hi there >>>> >>>> Is there any way to offset the text area a bit (to create an empty >>>> area for a serial id between the vector table and code area)? >>>> Without selecting a custom target, so I can still use the iccioavr.h >>>> file. >>>> >>>> >>> // richard (This email is for mailing lists. To reach me directly, >>> please use richard at imagecraft.com) >>> >>> _______________________________________________ >>> Icc-avr mailing list >>> Icc-avr@imagecraft.com >>> http://dragonsgate.net/mailman/listinfo/icc-avr >>> ------------------------------------------------------------------------ >>> >>> >>> No virus found in this incoming message. >>> Checked by AVG - http://www.avg.com Version: 8.0.175 / Virus Database: >>> 270.8.2/1738 - Release Date: 2008-10-21 14:10 >>> >>> >>> >> _______________________________________________ >> Icc-avr mailing list >> Icc-avr@imagecraft.com >> http://dragonsgate.net/mailman/listinfo/icc-avr >> >> >> ------------------------------------------------------------------------ >> >> >> No virus found in this incoming message. >> Checked by AVG - http://www.avg.com >> Version: 8.0.175 / Virus Database: 270.8.2/1742 - Release Date: 2008-10-23 15:29 >> >> From j_baraclough at zetnet.co.uk Mon Oct 27 00:22:04 2008 From: j_baraclough at zetnet.co.uk (John Baraclough) Date: Mon Oct 27 01:26:20 2008 Subject: [Icc-avr] text_end In-Reply-To: <49057182.9080601@edab.nu> References: <5F8515C5ED67B6439B4F93D7B5E08A36063E74@sbs.pertronic.local> <6C3F2C11D7454294A4425AD7B9D9F415@Shagrat> <48FED882.6040800@edab.nu> <200810222036.m9MKaYY7094090@mail.imagecraft.com> <4901D7B7.6050305@edab.nu> <4901FB42.1080001@srel.de> <49057182.9080601@edab.nu> Message-ID: <49057A2C.5060300@zetnet.co.uk> Hi Johan, Have a look at this thread in the archives: http://dragonsgate.net/pipermail/icc-avr/2005-September/005982.html I think it has what you need to know. All the best for now, John Johan Wallstr?m wrote: > > Thank you for the response. > I would like to put it (at a specific position) in flash, so this is > what I do: > > extern unsigned const char _text_end; > #pragma lit:MfgData > const char *FwLength = &_text_end; > > The program is compiled without errors, but FwLength is totally > omitted by the linker, putting the next label there instead. From johan at edab.nu Mon Oct 27 00:52:31 2008 From: johan at edab.nu (=?ISO-8859-1?Q?Johan_Wallstr=F6m?=) Date: Mon Oct 27 01:56:49 2008 Subject: [Icc-avr] text_end In-Reply-To: <49057A2C.5060300@zetnet.co.uk> References: <5F8515C5ED67B6439B4F93D7B5E08A36063E74@sbs.pertronic.local> <6C3F2C11D7454294A4425AD7B9D9F415@Shagrat> <48FED882.6040800@edab.nu> <200810222036.m9MKaYY7094090@mail.imagecraft.com> <4901D7B7.6050305@edab.nu> <4901FB42.1080001@srel.de> <49057182.9080601@edab.nu> <49057A2C.5060300@zetnet.co.uk> Message-ID: <4905814F.3040106@edab.nu> I just needed another const in there for the pointer #pragma lit:MfgData const char * const FwLength = &_text_end; John Baraclough skrev: > Hi Johan, > > Have a look at this thread in the archives: > > http://dragonsgate.net/pipermail/icc-avr/2005-September/005982.html > > I think it has what you need to know. > > All the best for now, > John > > > Johan Wallstr?m wrote: >> >> Thank you for the response. >> I would like to put it (at a specific position) in flash, so this is >> what I do: >> >> extern unsigned const char _text_end; >> #pragma lit:MfgData >> const char *FwLength = &_text_end; >> >> The program is compiled without errors, but FwLength is totally >> omitted by the linker, putting the next label there instead. > ------------------------------------------------------------------------ > > > No virus found in this incoming message. > Checked by AVG - http://www.avg.com > Version: 8.0.175 / Virus Database: 270.8.3/1748 - Release Date: 2008-10-26 19:53 > > From sl at ecpower.dk Mon Oct 27 06:55:06 2008 From: sl at ecpower.dk (Steven Lose) Date: Mon Oct 27 07:59:21 2008 Subject: [Icc-avr] problems when porting code from M128 to M2561 Message-ID: <072D96786BFC014AAEBA9EB07A8070EA514932@seattle.ecpower.dk> Hi. I just finished porting code from ATMEGA128 to ATMEGA2561. Now I got 11 lines of compiler errors saying eg. " Code Adr. 0:0xd5 already contains a value" Im using 7.14B. Is it something with switching between code banks that is not handled by compiler? Med venlig hilsen / Best regards / mit freundlichen Gr??en EC POWER A/S Steven Lose Software Ingeni?r Tlf.: +45 87434100 Direkte tlf. +45 58286608 Email: sl@ecpower.dk www.ecpower.dk -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20081027/3b79d23e/attachment.html From tim at sabretechnology.co.uk Mon Oct 27 07:10:10 2008 From: tim at sabretechnology.co.uk (Tim Mitchell) Date: Mon Oct 27 08:14:28 2008 Subject: [Icc-avr] problems when porting code from M128 to M2561 Message-ID: <04671BB8D269034BBC4BB6BA8948672610B76A@sserver.SabreTechnology.local> > > I just finished porting code from ATMEGA128 to ATMEGA2561. > > > > Now I got 11 lines of compiler errors saying eg. " Code > Adr. 0:0xd5 already contains a value" > This is usually caused by having the wrong target processor selected in the project options. Or at least it always is when I get it (frequently!) -- Tim Mitchell From j_baraclough at zetnet.co.uk Mon Oct 27 08:30:47 2008 From: j_baraclough at zetnet.co.uk (John Baraclough) Date: Mon Oct 27 09:35:07 2008 Subject: [Icc-avr] problems when porting code from M128 to M2561 In-Reply-To: <04671BB8D269034BBC4BB6BA8948672610B76A@sserver.SabreTechnology.local> References: <04671BB8D269034BBC4BB6BA8948672610B76A@sserver.SabreTechnology.local> Message-ID: <4905ECB7.7030207@zetnet.co.uk> Hi Steven, It's probably either that or you have the wrong header file in one of your source files as the interrupt vector table in the M2561 is much larger than that in the M128 . If you use: #include then the compiler does the work for you. All the best for now, John Tim Mitchell wrote: >> I just finished porting code from ATMEGA128 to ATMEGA2561. >> >> >> >> Now I got 11 lines of compiler errors saying eg. " Code >> Adr. 0:0xd5 already contains a value" >> >> > > This is usually caused by having the wrong target processor selected in > the project options. Or at least it always is when I get it > (frequently!) > > From sl at ecpower.dk Mon Oct 27 11:25:10 2008 From: sl at ecpower.dk (Steven Lose) Date: Mon Oct 27 12:29:27 2008 Subject: SV: [Icc-avr] problems when porting code from M128 to M2561 In-Reply-To: <04671BB8D269034BBC4BB6BA8948672610B76A@sserver.SabreTechnology.local> References: <04671BB8D269034BBC4BB6BA8948672610B76A@sserver.SabreTechnology.local> Message-ID: <072D96786BFC014AAEBA9EB07A8070EA514934@seattle.ecpower.dk> Hi Tim. No, the target is selected correct. But thanks. Med venlig hilsen / Best regards / mit freundlichen Gr??en EC POWER A/S Steven Lose Software Ingeni?r Tlf.: +45 87434100 Direkte tlf. +45 58286608 Email: sl@ecpower.dk www.ecpower.dk -----Oprindelig meddelelse----- Fra: icc-avr-bounces@imagecraft.com [mailto:icc-avr-bounces@imagecraft.com] P? vegne af Tim Mitchell Sendt: 27. oktober 2008 16:10 Til: Discussion list for ICCAVR and ICCtiny Users. You do NOT needtosubscribeto icc-announce if you are a member of this. Emne: RE: [Icc-avr] problems when porting code from M128 to M2561 > > I just finished porting code from ATMEGA128 to ATMEGA2561. > > > > Now I got 11 lines of compiler errors saying eg. " Code > Adr. 0:0xd5 already contains a value" > This is usually caused by having the wrong target processor selected in the project options. Or at least it always is when I get it (frequently!) -- Tim Mitchell _______________________________________________ Icc-avr mailing list Icc-avr@imagecraft.com http://dragonsgate.net/mailman/listinfo/icc-avr From richard-lists at imagecraft.com Mon Oct 27 12:31:39 2008 From: richard-lists at imagecraft.com (Richard Man) Date: Mon Oct 27 12:37:31 2008 Subject: SV: [Icc-avr] problems when porting code from M128 to M2561 In-Reply-To: <072D96786BFC014AAEBA9EB07A8070EA514934@seattle.ecpower.dk> References: <04671BB8D269034BBC4BB6BA8948672610B76A@sserver.SabreTechnology.local> <072D96786BFC014AAEBA9EB07A8070EA514934@seattle.ecpower.dk> Message-ID: <200810272037.m9RKbUaE093575@mail.imagecraft.com> Make sure you are not using vectors that only exist in the M128 but not thye M256 At 11:25 AM 10/27/2008, Steven Lose wrote: >Hi Tim. > >No, the target is selected correct. >But thanks. > // richard (This email is for mailing lists. To reach me directly, please use richard at imagecraft.com) From sl at ecpower.dk Mon Oct 27 11:42:56 2008 From: sl at ecpower.dk (Steven Lose) Date: Mon Oct 27 12:47:10 2008 Subject: SV: [Icc-avr] problems when porting code from M128 to M2561 In-Reply-To: <4905ECB7.7030207@zetnet.co.uk> References: <04671BB8D269034BBC4BB6BA8948672610B76A@sserver.SabreTechnology.local> <4905ECB7.7030207@zetnet.co.uk> Message-ID: <072D96786BFC014AAEBA9EB07A8070EA514935@seattle.ecpower.dk> Hi John. If it a wrong header, I haven't been able to find it. Been through all headers and c files manually and with the find function. I'm still using 7.14B so unfortunately I'm not able to use iccioavr.h Here's a dump of the whole story: iccavr -o STYRING256 -g -e:0x40000 -xcall -ucrtnewram.o -bfunc_lit:0xcc.0x40000 -dram_end:0x21ff -bdata:0x2200.0x7fff -dFRAM:1 -dhwstk_size:120 -beeprom:0.4096 -fihx_coff -S2 @STYRING256.lk -lcatm256 !E ATMEGA128HW.o(153): Code address 0:0xcc already contains a value !E ATMEGA128HW.o(153): Code address 0:0xcd already contains a value !E ATMEGA128HW.o(153): Code address 0:0xce already contains a value !E ATMEGA128HW.o(153): Code address 0:0xcf already contains a value !E ATMEGA128HW.o(155): Code address 0:0xd0 already contains a value !E ATMEGA128HW.o(155): Code address 0:0xd1 already contains a value !E ATMEGA128HW.o(155): Code address 0:0xd2 already contains a value !E ATMEGA128HW.o(155): Code address 0:0xd3 already contains a value !E ATMEGA128HW.o(157): Code address 0:0xd4 already contains a value !E ATMEGA128HW.o(157): Code address 0:0xd5 already contains a value C:\iccv7avr\bin\imakew.exe: Error code 1 Done: there are error(s). Exit code: 1. Mon Oct 27 20:40:00 2008 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 John Baraclough Sendt: 27. oktober 2008 17:31 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] problems when porting code from M128 to M2561 Hi Steven, It's probably either that or you have the wrong header file in one of your source files as the interrupt vector table in the M2561 is much larger than that in the M128 . If you use: #include then the compiler does the work for you. All the best for now, John Tim Mitchell wrote: >> I just finished porting code from ATMEGA128 to ATMEGA2561. >> >> >> >> Now I got 11 lines of compiler errors saying eg. " Code >> Adr. 0:0xd5 already contains a value" >> >> > > This is usually caused by having the wrong target processor selected in > the project options. Or at least it always is when I get it > (frequently!) > > _______________________________________________ Icc-avr mailing list Icc-avr@imagecraft.com http://dragonsgate.net/mailman/listinfo/icc-avr From sl at ecpower.dk Mon Oct 27 11:53:43 2008 From: sl at ecpower.dk (Steven Lose) Date: Mon Oct 27 12:57:57 2008 Subject: SV: SV: [Icc-avr] problems when porting code from M128 to M2561 In-Reply-To: <200810272037.m9RKbUaE093575@mail.imagecraft.com> References: <04671BB8D269034BBC4BB6BA8948672610B76A@sserver.SabreTechnology.local><072D96786BFC014AAEBA9EB07A8070EA514934@seattle.ecpower.dk> <200810272037.m9RKbUaE093575@mail.imagecraft.com> Message-ID: <072D96786BFC014AAEBA9EB07A8070EA514936@seattle.ecpower.dk> Aha, that was it! I have a dummy int for all unused vectors, and have added the extra vectors that were in the header file. But the vectors for Uart 2 and 3 was the problem. Thanks a lot, saved me some days of hair pulling. ;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: icc-avr-bounces@imagecraft.com [mailto:icc-avr-bounces@imagecraft.com] P? vegne af Richard Man Sendt: 27. oktober 2008 21:32 Til: icc-avr@imagecraft.com Emne: Re: SV: [Icc-avr] problems when porting code from M128 to M2561 Make sure you are not using vectors that only exist in the M128 but not thye M256 At 11:25 AM 10/27/2008, Steven Lose wrote: >Hi Tim. > >No, the target is selected correct. >But thanks. > // richard (This email is for mailing lists. To reach me directly, please use richard at imagecraft.com) _______________________________________________ Icc-avr mailing list Icc-avr@imagecraft.com http://dragonsgate.net/mailman/listinfo/icc-avr From j_baraclough at zetnet.co.uk Mon Oct 27 11:57:39 2008 From: j_baraclough at zetnet.co.uk (John Baraclough) Date: Mon Oct 27 13:01:56 2008 Subject: SV: [Icc-avr] problems when porting code from M128 to M2561 In-Reply-To: <072D96786BFC014AAEBA9EB07A8070EA514935@seattle.ecpower.dk> References: <04671BB8D269034BBC4BB6BA8948672610B76A@sserver.SabreTechnology.local> <4905ECB7.7030207@zetnet.co.uk> <072D96786BFC014AAEBA9EB07A8070EA514935@seattle.ecpower.dk> Message-ID: <49061D33.8030405@zetnet.co.uk> Hi Steven, "iccioavr.h" can be used with any release of V7, it just wasn't packaged with the download until 7.16. Just go here: http://avr.jassenbaum.de/iccv7avr/index.html and download the zip file of the latest header files, then you will have it. It looks as though your problem is with just one file called 'ATMEGA128HW.c', which coulkd be significant. If you want to send it to me off-list I'll have a look. All the best for now, John Steven Lose wrote: > Hi John. > > If it a wrong header, I haven't been able to find it. > Been through all headers and c files manually and with the find function. > I'm still using 7.14B so unfortunately I'm not able to use iccioavr.h > > Here's a dump of the whole story: > > iccavr -o STYRING256 -g -e:0x40000 -xcall -ucrtnewram.o -bfunc_lit:0xcc.0x40000 -dram_end:0x21ff -bdata:0x2200.0x7fff -dFRAM:1 -dhwstk_size:120 -beeprom:0.4096 -fihx_coff -S2 @STYRING256.lk -lcatm256 > !E ATMEGA128HW.o(153): Code address 0:0xcc already contains a value > !E ATMEGA128HW.o(153): Code address 0:0xcd already contains a value > !E ATMEGA128HW.o(153): Code address 0:0xce already contains a value > !E ATMEGA128HW.o(153): Code address 0:0xcf already contains a value > !E ATMEGA128HW.o(155): Code address 0:0xd0 already contains a value > !E ATMEGA128HW.o(155): Code address 0:0xd1 already contains a value > !E ATMEGA128HW.o(155): Code address 0:0xd2 already contains a value > !E ATMEGA128HW.o(155): Code address 0:0xd3 already contains a value > !E ATMEGA128HW.o(157): Code address 0:0xd4 already contains a value > !E ATMEGA128HW.o(157): Code address 0:0xd5 already contains a value > C:\iccv7avr\bin\imakew.exe: Error code 1 > Done: there are error(s). Exit code: 1. Mon Oct 27 20:40:00 2008 > > Med venlig hilsen / Best regards / mit freundlichen Gr??en > > EC POWER A/S > > Steven Lose > > Software Ingeni?r > > Tlf.: +45 87434100 > > Direkte tlf. +45 58286608 > > Email: sl@ecpower.dk > > www.ecpower.dk > From sl at ecpower.dk Mon Oct 27 12:07:07 2008 From: sl at ecpower.dk (Steven Lose) Date: Mon Oct 27 13:11:21 2008 Subject: SV: SV: [Icc-avr] problems when porting code from M128 to M2561 In-Reply-To: <49061D33.8030405@zetnet.co.uk> References: <04671BB8D269034BBC4BB6BA8948672610B76A@sserver.SabreTechnology.local> <4905ECB7.7030207@zetnet.co.uk><072D96786BFC014AAEBA9EB07A8070EA514935@seattle.ecpower.dk> <49061D33.8030405@zetnet.co.uk> Message-ID: <072D96786BFC014AAEBA9EB07A8070EA514937@seattle.ecpower.dk> Thanks John. And thanks for the offer of having a look at it. It was in ATMEGA128.C file (haven't changed the name yet) It was a list of all unused vectors that was causing the trouble. I had added all the extra vectors from the 2561 header file, and the vectors for the Uart 2 and 3 was the trouble. 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 John Baraclough Sendt: 27. oktober 2008 20:58 Til: Discussion list for ICCAVR and ICCtiny Users. You do NOT need tosubscribe to icc-announce if you are a member of this. Emne: Re: SV: [Icc-avr] problems when porting code from M128 to M2561 Hi Steven, "iccioavr.h" can be used with any release of V7, it just wasn't packaged with the download until 7.16. Just go here: http://avr.jassenbaum.de/iccv7avr/index.html and download the zip file of the latest header files, then you will have it. It looks as though your problem is with just one file called 'ATMEGA128HW.c', which coulkd be significant. If you want to send it to me off-list I'll have a look. All the best for now, John Steven Lose wrote: > Hi John. > > If it a wrong header, I haven't been able to find it. > Been through all headers and c files manually and with the find function. > I'm still using 7.14B so unfortunately I'm not able to use iccioavr.h > > Here's a dump of the whole story: > > iccavr -o STYRING256 -g -e:0x40000 -xcall -ucrtnewram.o -bfunc_lit:0xcc.0x40000 -dram_end:0x21ff -bdata:0x2200.0x7fff -dFRAM:1 -dhwstk_size:120 -beeprom:0.4096 -fihx_coff -S2 @STYRING256.lk -lcatm256 > !E ATMEGA128HW.o(153): Code address 0:0xcc already contains a value > !E ATMEGA128HW.o(153): Code address 0:0xcd already contains a value > !E ATMEGA128HW.o(153): Code address 0:0xce already contains a value > !E ATMEGA128HW.o(153): Code address 0:0xcf already contains a value > !E ATMEGA128HW.o(155): Code address 0:0xd0 already contains a value > !E ATMEGA128HW.o(155): Code address 0:0xd1 already contains a value > !E ATMEGA128HW.o(155): Code address 0:0xd2 already contains a value > !E ATMEGA128HW.o(155): Code address 0:0xd3 already contains a value > !E ATMEGA128HW.o(157): Code address 0:0xd4 already contains a value > !E ATMEGA128HW.o(157): Code address 0:0xd5 already contains a value > C:\iccv7avr\bin\imakew.exe: Error code 1 > Done: there are error(s). Exit code: 1. Mon Oct 27 20:40:00 2008 > > Med venlig hilsen / Best regards / mit freundlichen Gr??en > > EC POWER A/S > > Steven Lose > > Software Ingeni?r > > Tlf.: +45 87434100 > > Direkte tlf. +45 58286608 > > Email: sl@ecpower.dk > > www.ecpower.dk > _______________________________________________ Icc-avr mailing list Icc-avr@imagecraft.com http://dragonsgate.net/mailman/listinfo/icc-avr From r.rohde at indas.de Tue Oct 28 13:22:33 2008 From: r.rohde at indas.de (Roman Rohde) Date: Tue Oct 28 14:26:50 2008 Subject: SV: SV: [Icc-avr] problems when porting code from M128 to M2561 In-Reply-To: <072D96786BFC014AAEBA9EB07A8070EA514936@seattle.ecpower.dk> References: <04671BB8D269034BBC4BB6BA8948672610B76A@sserver.SabreTechnology.local><072D96786BFC014AAEBA9EB07A8070EA514934@seattle.ecpower.dk> <200810272037.m9RKbUaE093575@mail.imagecraft.com> <072D96786BFC014AAEBA9EB07A8070EA514936@seattle.ecpower.dk> Message-ID: <49078299.8050109@indas.de> Steven Lose schrieb: > Aha, that was it! > I have a dummy int for all unused vectors, and have added the extra vectors that were in the header file. > But the vectors for Uart 2 and 3 was the problem. > > There is a simple way to write a exact count of RETI intructions in ALL vectors: get the startup code source for the ATMega128: --------------------------------------------------------- ; crtatmegaram.s ; make sure to assemble w/ -n flag, e.g. ; iasavr -n crt... .include "area.s" .text __start:: ; entry point wdr ; aviod spurious watch dog resets cli ; disable ints securely .include "extram.s" USE_ELPM = 1 .include "init.s" ; call user main routine call _main _exit:: rjmp _exit ; interrupt vectors. The first entry is the reset vector ; .area vector(abs) .org 0 jmp __start ; 0 - RESET reti ; 1 - reti reti ; 2 - reti ... reti ; 34 - reti --------------------------------------------------------- ALL really used int vectors are automatically overwritten by a JMP instruction! Roman > Thanks a lot, saved me some days of hair pulling. ;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: icc-avr-bounces@imagecraft.com [mailto:icc-avr-bounces@imagecraft.com] P? vegne af Richard Man > Sendt: 27. oktober 2008 21:32 > Til: icc-avr@imagecraft.com > Emne: Re: SV: [Icc-avr] problems when porting code from M128 to M2561 > > Make sure you are not using vectors that only exist in the M128 but > not thye M256 > > At 11:25 AM 10/27/2008, Steven Lose wrote: > >> Hi Tim. >> >> No, the target is selected correct. >> But thanks. >> >> > > // richard (This email is for mailing lists. To reach me directly, > please use richard at imagecraft.com) > > _______________________________________________ > Icc-avr mailing list > Icc-avr@imagecraft.com > http://dragonsgate.net/mailman/listinfo/icc-avr > > > _______________________________________________ > Icc-avr mailing list > Icc-avr@imagecraft.com > http://dragonsgate.net/mailman/listinfo/icc-avr > > From sl at ecpower.dk Wed Oct 29 08:31:52 2008 From: sl at ecpower.dk (Steven Lose) Date: Wed Oct 29 09:36:10 2008 Subject: SV: SV: SV: [Icc-avr] problems when porting code from M128 to M2561 In-Reply-To: <49078299.8050109@indas.de> References: <04671BB8D269034BBC4BB6BA8948672610B76A@sserver.SabreTechnology.local><072D96786BFC014AAEBA9EB07A8070EA514934@seattle.ecpower.dk> <200810272037.m9RKbUaE093575@mail.imagecraft.com><072D96786BFC014AAEBA9EB07A8070EA514936@seattle.ecpower.dk> <49078299.8050109@indas.de> Message-ID: <072D96786BFC014AAEBA9EB07A8070EA514A8D@seattle.ecpower.dk> Yes, that's a simple way of doing it. But I try to stick to the C files if possible, so my colleagues do not need to know some special stuff to maintain it. Thanks. Med venlig hilsen / Best regards / mit freundlichen Gr??en EC POWER A/S Steven Lose Software Ingeni?r Tlf.: +45 87434100 Direkte tlf. +45 58286608 Email: sl@ecpower.dk www.ecpower.dk -----Oprindelig meddelelse----- Fra: icc-avr-bounces@imagecraft.com [mailto:icc-avr-bounces@imagecraft.com] P? vegne af Roman Rohde Sendt: 28. oktober 2008 22:23 Til: Discussion list for ICCAVR and ICCtiny Users. You do NOT need tosubscribe to icc-announce if you are a member of this. Emne: Re: SV: SV: [Icc-avr] problems when porting code from M128 to M2561 Steven Lose schrieb: > Aha, that was it! > I have a dummy int for all unused vectors, and have added the extra vectors that were in the header file. > But the vectors for Uart 2 and 3 was the problem. > > There is a simple way to write a exact count of RETI intructions in ALL vectors: get the startup code source for the ATMega128: --------------------------------------------------------- ; crtatmegaram.s ; make sure to assemble w/ -n flag, e.g. ; iasavr -n crt... .include "area.s" .text __start:: ; entry point wdr ; aviod spurious watch dog resets cli ; disable ints securely .include "extram.s" USE_ELPM = 1 .include "init.s" ; call user main routine call _main _exit:: rjmp _exit ; interrupt vectors. The first entry is the reset vector ; .area vector(abs) .org 0 jmp __start ; 0 - RESET reti ; 1 - reti reti ; 2 - reti ... reti ; 34 - reti --------------------------------------------------------- ALL really used int vectors are automatically overwritten by a JMP instruction! Roman > Thanks a lot, saved me some days of hair pulling. ;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: icc-avr-bounces@imagecraft.com [mailto:icc-avr-bounces@imagecraft.com] P? vegne af Richard Man > Sendt: 27. oktober 2008 21:32 > Til: icc-avr@imagecraft.com > Emne: Re: SV: [Icc-avr] problems when porting code from M128 to M2561 > > Make sure you are not using vectors that only exist in the M128 but > not thye M256 > > At 11:25 AM 10/27/2008, Steven Lose wrote: > >> Hi Tim. >> >> No, the target is selected correct. >> But thanks. >> >> > > // richard (This email is for mailing lists. To reach me directly, > please use richard at imagecraft.com) > > _______________________________________________ > Icc-avr mailing list > Icc-avr@imagecraft.com > http://dragonsgate.net/mailman/listinfo/icc-avr > > > _______________________________________________ > Icc-avr mailing list > Icc-avr@imagecraft.com > http://dragonsgate.net/mailman/listinfo/icc-avr > > _______________________________________________ Icc-avr mailing list Icc-avr@imagecraft.com http://dragonsgate.net/mailman/listinfo/icc-avr From sl at ecpower.dk Wed Oct 29 22:15:38 2008 From: sl at ecpower.dk (Steven Lose) Date: Wed Oct 29 23:19:57 2008 Subject: [Icc-avr] upgrade from ATMEGA128 to ATMEGA2561 and stack size Message-ID: <072D96786BFC014AAEBA9EB07A8070EA514A97@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: image002.jpg Url : http://dragonsgate.net/pipermail/icc-avr/attachments/20081030/a015aac8/attachment.jpe From richard-lists at imagecraft.com Thu Oct 30 02:40:10 2008 From: richard-lists at imagecraft.com (Richard Man) Date: Thu Oct 30 02:46:01 2008 Subject: [Icc-avr] upgrade from ATMEGA128 to ATMEGA2561 and stack size In-Reply-To: <072D96786BFC014AAEBA9EB07A8070EA514A97@seattle.ecpower.dk> References: <072D96786BFC014AAEBA9EB07A8070EA514A97@seattle.ecpower.dk> Message-ID: <200810301046.m9UAk06l055798@mail.imagecraft.com> An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20081030/753d84c5/attachment.html From j_baraclough at zetnet.co.uk Thu Oct 30 01:56:26 2008 From: j_baraclough at zetnet.co.uk (John Baraclough) Date: Thu Oct 30 03:00:45 2008 Subject: [Icc-avr] upgrade from ATMEGA128 to ATMEGA2561 and stack size In-Reply-To: <072D96786BFC014AAEBA9EB07A8070EA514A97@seattle.ecpower.dk> References: <072D96786BFC014AAEBA9EB07A8070EA514A97@seattle.ecpower.dk> Message-ID: <490984CA.2060409@zetnet.co.uk> Hi steven, The stack summary tool was written by Johannes. It can be integrated into the IDE and can be downloaded from here: http://avr.jassenbaum.de/iccv7avr/stacksum.html All the best for now, John Steven Lose wrote: > Does the HW stack grow when moving code from an ATMEGA128 to ATMEGA2561? > > It seems that I have to make the stack much bigger. > > Someone had a stack calc tool, but can?t remember who! > From snewbold at unlnotes.unl.edu Thu Oct 30 05:14:38 2008 From: snewbold at unlnotes.unl.edu (Stefan Newbold) Date: Thu Oct 30 06:19:38 2008 Subject: [Icc-avr] ATtiny12 In-Reply-To: <7B0EB27CF1CC93439B5CFB7526E5D74C72691D@mickey.PBNV.local> References: <24198.204.19.71.2.1222877338.squirrel@www.microsyl.com> <7B0EB27CF1CC93439B5CFB7526E5D74C72691D@mickey.PBNV.local> Message-ID: I need to make a few changes to some code I wrote for a ATtiny12 micro 7+ years ago. Unfortunately, ICCAVR no longer has this micro listed as a target. I tried compiling using the ATtiny13 as a target for the project with no luck. In looking at the generated assembly code, it looks like the ATtiny13's instruction set is different than the 12's. Anyone have any work-around ideas? Richard: Would it be possible to get an older version of the compiler that has a ATtiny12 as a target option? Thanks. Stefan Newbold Software Engineer University of Nebraska - Lincoln snewbold@unl.edu Phone: (402) 472 4852 FAX: (402) 472 9291 "I'd let her shoot me" -- Bullwinkle -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20081030/288c0b21/attachment.html From paul.aa9gg at gmail.com Thu Oct 30 05:28:46 2008 From: paul.aa9gg at gmail.com (Paul Mateer) Date: Thu Oct 30 06:33:04 2008 Subject: [Icc-avr] ATtiny12 In-Reply-To: References: <24198.204.19.71.2.1222877338.squirrel@www.microsyl.com> <7B0EB27CF1CC93439B5CFB7526E5D74C72691D@mickey.PBNV.local> Message-ID: <20f5efc40810300628n7b83b0b7i3f4b11f67719e5d6@mail.gmail.com> I think you can select "custom" and set the parameters. On Thu, Oct 30, 2008 at 8:14 AM, Stefan Newbold wrote: > > I need to make a few changes to some code I wrote for a ATtiny12 micro 7+ > years ago. Unfortunately, ICCAVR no longer has this micro listed as a > target. I tried compiling using the ATtiny13 as a target for the project > with no luck. In looking at the generated assembly code, it looks like the > ATtiny13's instruction set is different than the 12's. > > Anyone have any work-around ideas? > > Richard: Would it be possible to get an older version of the compiler that > has a ATtiny12 as a target option? > > Thanks. > > Stefan Newbold > Software Engineer > University of Nebraska - Lincoln > snewbold@unl.edu > Phone: (402) 472 4852 > FAX: (402) 472 9291 > > "I'd let her shoot me" -- Bullwinkle > > _______________________________________________ > Icc-avr mailing list > Icc-avr@imagecraft.com > http://dragonsgate.net/mailman/listinfo/icc-avr > > -- Paul Mateer, AA9GG Elan Engineering Corp. www.elanengr.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20081030/f0d9b97a/attachment.html From sl at ecpower.dk Thu Oct 30 08:25:40 2008 From: sl at ecpower.dk (Steven Lose) Date: Thu Oct 30 09:30:16 2008 Subject: SV: [Icc-avr] upgrade from ATMEGA128 to ATMEGA2561 and stack size In-Reply-To: <490984CA.2060409@zetnet.co.uk> References: <072D96786BFC014AAEBA9EB07A8070EA514A97@seattle.ecpower.dk> <490984CA.2060409@zetnet.co.uk> Message-ID: <072D96786BFC014AAEBA9EB07A8070EA514B37@seattle.ecpower.dk> Arh, it was johannes. I was into his site under the ja-tools but did not find it. Thanks. And thanks to Johannes for the nice tool. 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 John Baraclough Sendt: 30. oktober 2008 10:56 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] upgrade from ATMEGA128 to ATMEGA2561 and stack size Hi steven, The stack summary tool was written by Johannes. It can be integrated into the IDE and can be downloaded from here: http://avr.jassenbaum.de/iccv7avr/stacksum.html All the best for now, John Steven Lose wrote: > Does the HW stack grow when moving code from an ATMEGA128 to ATMEGA2561? > > It seems that I have to make the stack much bigger. > > Someone had a stack calc tool, but can't remember who! > _______________________________________________ Icc-avr mailing list Icc-avr@imagecraft.com http://dragonsgate.net/mailman/listinfo/icc-avr From sl at ecpower.dk Thu Oct 30 08:28:46 2008 From: sl at ecpower.dk (Steven Lose) Date: Thu Oct 30 09:33:04 2008 Subject: SV: [Icc-avr] upgrade from ATMEGA128 to ATMEGA2561 and stack size In-Reply-To: <200810301046.m9UAk06l055798@mail.imagecraft.com> References: <072D96786BFC014AAEBA9EB07A8070EA514A97@seattle.ecpower.dk> <200810301046.m9UAk06l055798@mail.imagecraft.com> Message-ID: <072D96786BFC014AAEBA9EB07A8070EA514B38@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/20081030/0f82108e/attachment.jpe From sl at ecpower.dk Thu Oct 30 12:07:29 2008 From: sl at ecpower.dk (Steven Lose) Date: Thu Oct 30 13:12:43 2008 Subject: SV: [Icc-avr] upgrade from ATMEGA128 to ATMEGA2561 and stack size In-Reply-To: <490984CA.2060409@zetnet.co.uk> References: <072D96786BFC014AAEBA9EB07A8070EA514A97@seattle.ecpower.dk> <490984CA.2060409@zetnet.co.uk> Message-ID: <072D96786BFC014AAEBA9EB07A8070EA514B3C@seattle.ecpower.dk> Hi John. I may need a little hint on the setup. ;o) A: I have copied the stacksumAVR.exe into ICC standard install root B: I have set up a tool with path to the stacksumAVR.exe, with %p as parameter as shown on jassenbaum's home page. And capture output is checked. But it doesn't seem to know where the project file is. When used prom a command prompt, it works just fine. What is the missing part? 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 John Baraclough Sendt: 30. oktober 2008 10:56 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] upgrade from ATMEGA128 to ATMEGA2561 and stack size Hi steven, The stack summary tool was written by Johannes. It can be integrated into the IDE and can be downloaded from here: http://avr.jassenbaum.de/iccv7avr/stacksum.html All the best for now, John Steven Lose wrote: > Does the HW stack grow when moving code from an ATMEGA128 to ATMEGA2561? > > It seems that I have to make the stack much bigger. > > Someone had a stack calc tool, but can't remember who! > _______________________________________________ Icc-avr mailing list Icc-avr@imagecraft.com http://dragonsgate.net/mailman/listinfo/icc-avr From oldhat_owen at yahoo.com.au Thu Oct 30 14:11:28 2008 From: oldhat_owen at yahoo.com.au (Owen) Date: Thu Oct 30 15:28:09 2008 Subject: [Icc-avr] ATtiny12 In-Reply-To: References: <24198.204.19.71.2.1222877338.squirrel@www.microsyl.com><7B0EB27CF1CC93439B5CFB7526E5D74C72691D@mickey.PBNV.local> Message-ID: Hi Stefan, I think that you will find that you will need to use the ICCTINY compiler for the ATtiny12 and AVRstudio 3.53 for debugging (AVRstudio 3.53 is the last version of studio that was compatible with the coff file produced by the ICCTINY compiler). I suspect that the memory configuration of the early tiny's is different to the later versions (I think that there is no sram in the early tiny's). The ICCTINY compiler supports tiny 10, 11, 12, 15, 28, and AT90s1200. The other option would be to program in assembly. Owen. I need to make a few changes to some code I wrote for a ATtiny12 micro 7+ years ago. ?Unfortunately, ICCAVR no longer has this micro listed as a target. ?I tried compiling using the ATtiny13 as a target for the project with no luck. ?In looking at the generated assembly code, it looks like the ATtiny13's instruction set is different than the 12's. ? Anyone have any work-around ideas? Richard: ?Would it be possible to get an older version of the compiler that has a ATtiny12 as a target option? Thanks. Stefan Newbold Software Engineer University of Nebraska - Lincoln snewbold@unl.edu Phone: (402) 472 4852 FAX: (402) 472 9291 "I'd let her shoot me" ? -- Bullwinkle