From sl at ecpower.dk Mon Oct 1 01:41:55 2007 From: sl at ecpower.dk (Steven Lose) Date: Mon Oct 1 01:54:01 2007 Subject: SV: [Icc-avr] help? Stepper motr appl.. References: <072D96786BFC014AAEBA9EB07A8070EA2CE21F@seattle.ecpower.dk><46FBB89F.50903@cox.net><072D96786BFC014AAEBA9EB07A8070EA2CE29D@seattle.ecpower.dk><001601c801bf$6273d9c0$0200a8c0@BigFoot> <000901c803f4$857b1a00$b160ec82@Shagrat> Message-ID: <072D96786BFC014AAEBA9EB07A8070EA2CE335@seattle.ecpower.dk> Hi. I also have experience in both SW and HW drivers for stepper motors. Could you describe what you need to know? 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 Bengt Ragnemalm Sendt: 1. oktober 2007 08:30 Til: 'Discussion list for ICCAVR and ICCtiny Users. You do NOT needtosubscribeto icc-announce if you are a member of this.' Emne: SV: [Icc-avr] help? Stepper motr appl.. Well, I have played with a stepper motor driver once. Did it much to learn how stepper motor works. I made my own stepper motor driver entirely out of some MOSFET transistors and an AVR. What do you want to know? Regards Bengt > -----Ursprungligt meddelande----- > Fr?n: icc-avr-bounces@imagecraft.com [mailto:icc-avr- > bounces@imagecraft.com] F?r AMS Solutions - GJ Laubscher > Skickat: den 28 september 2007 13:04 > Till: Discussion list for ICCAVR and ICCtiny Users. You do NOT > needtosubscribeto icc-announce if you are a member of this. > ?mne: [Icc-avr] help? Stepper motr appl.. > > Hi All, > Any experience around re stepper motor control, plse contact me? > > Have a great day! > > Regards, > Gerhard Laubscher > AMS Solutions 'Electronic System Design made easy' > Cape Town , Table View PO Box 132, Table View, 7439 > South Africa South Africa > > TeleFax : +27-21-557 0160 Mobile : 082 366 1950 > email : amsol@amssolutions.co.za website: http://www.amssolutions.co.za > > _______________________________________________ > Icc-avr mailing list > Icc-avr@imagecraft.com > http://dragonsgate.net/mailman/listinfo/icc-avr _______________________________________________ Icc-avr mailing list Icc-avr@imagecraft.com http://dragonsgate.net/mailman/listinfo/icc-avr From j_baraclough at zetnet.co.uk Mon Oct 1 02:46:43 2007 From: j_baraclough at zetnet.co.uk (John Baraclough) Date: Mon Oct 1 02:58:50 2007 Subject: [Icc-avr] read and write i2c eeprom using twi? In-Reply-To: References: Message-ID: That code was written for the Futurlec ATmega32 controller board with DS1307 RTC. However the RTC functions remain untested as the project was abandoned by the customer. All the best for now, John At 23:26 30/09/2007, you wrote: >Thanks John B! Routines seem to work fine. What kind of clock chip >are those other routines for? DS11307? > > > > > >---------- >See what's new at >AOL.com and >Make AOL >Your Homepage. >_______________________________________________ >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/20071001/3939d0d0/attachment.html From MDipperstein at CalAmp.com Mon Oct 1 09:58:42 2007 From: MDipperstein at CalAmp.com (Michael Dipperstein) Date: Mon Oct 1 10:10:46 2007 Subject: [Icc-avr] Optimization of write and read to register STS, LDS In-Reply-To: <20070930094045.7B7B26B13@annatar.imt.liu.se> Message-ID: Bengt, I haven't looked at the AVRfreaks application, but if you can put your data in a structure and access it by pointer, the compiler will uses LDD and STD. The compiler will usually load the address of the pointer into a register pair and then movw that value into the Z register, so you need to do at least 3 load/store operations to break even. I don't know why the compiler doesn't just load the Z register directly. Here are some samples I generated using 7.13A without optimizations: typedef struct { char field1; int field2; char field3; } my_struct_t; my_struct_t myStruct; void func1(void) { myStruct.field2 = myStruct.field1 + myStruct.field3; } void func2(void) { my_struct_t *myPtr; myPtr = &myStruct; myPtr->field2 = myPtr->field1 + myPtr->field3; } I got following for func1: lds R2,_myStruct+3 clr R3 lds R4,_myStruct clr R5 add R4,R2 adc R5,R3 sts _myStruct+1+1,R5 sts _myStruct+1,R4 ret And the following for func2: ldi R16,<_myStruct ldi R17,>_myStruct movw R30,R16 ldd R2,z+3 clr R3 ldd R4,z+0 clr R5 add R4,R2 adc R5,R3 std z+2,R5 std z+1,R4 ret -Mike -----Original Message----- From: icc-avr-bounces@imagecraft.com [mailto:icc-avr-bounces@imagecraft.com] On Behalf Of Bengt Ragnemalm Sent: Sunday, September 30, 2007 2:41 AM To: Discussion list for ICCAVR and ICCtiny Users. You do NOT need tosubscribe to icc-announce if you are a member of this. Subject: [Icc-avr] Optimization of write and read to register STS, LDS I am testing a size optimized osccal routine (RetroDan, AVRfreaks). It is a hint there about the possibility to optimize many STS and LDS instructions with LDD and STD (load and store with displacement). It occured to me that why could a C-compiler not catch that possibility? Or maybe it would be possible to "fool" the compiler to use it anyway. Regards, Bengt _______________________________________________ Icc-avr mailing list Icc-avr@imagecraft.com http://dragonsgate.net/mailman/listinfo/icc-avr From benra at imt.liu.se Mon Oct 1 11:35:07 2007 From: benra at imt.liu.se (Bengt Ragnemalm) Date: Mon Oct 1 11:47:19 2007 Subject: [Icc-avr] Optimization of write and read to register STS, LDS In-Reply-To: <20070930094045.7B7B26B13@annatar.imt.liu.se> Message-ID: <20071001183508.894BD6B0A@annatar.imt.liu.se> Richard, as this is a post for optimization I think this is most for you. I post the code here so I can describe how this optimization works. What I ask is if this type of optimization is or can be done by the compiler. When there is always the question of how much effect it will have. ----- Assembler snippet: RETRO_CAL: STS CLKPR,V128 ;DROP CLOCK TO 1Mhz STS CLKPR,THREE ; STS TIMSK1,ZERO ;SETUP TIMER1 STS TCCR1B,ONE ;TC1 = 1MHz = 1uS STS TIMSK2,ZERO ;SETUP TIMER2 STS ASSR,EIGHT ;CLOCK FROM 32KHz OSCILLATOR LDI TMP1,200 ;OCR2A = 200 STS OCR2A,TMP1 ;200 / 32768Hz ~= 6103uS STS TCCR2A,ONE ;TC2 = 32768Hz ~= 30.5176uS LDS TMP,OSCCAL ;READ OSCCAL ---- Same snippet in C: void OSCCAL_retrocal(void) { unsigned char temp; unsigned char val_1 = 0x01; unsigned char low,high; // set the CPU Frequency to 1MHz (8Mhz / 8 = 1Mhz) CLKPR = (1< I am testing a size optimized osccal routine (RetroDan, AVRfreaks). It is a > hint there about the possibility to optimize many STS and LDS instructions > with LDD and STD (load and store with displacement). > > It occured to me that why could a C-compiler not catch that possibility? Or > maybe it would be possible to "fool" the compiler to use it anyway. > > Regards, > Bengt > > _______________________________________________ > Icc-avr mailing list > Icc-avr@imagecraft.com > http://dragonsgate.net/mailman/listinfo/icc-avr > From richard-lists at imagecraft.com Mon Oct 1 12:19:01 2007 From: richard-lists at imagecraft.com (Richard) Date: Mon Oct 1 12:31:00 2007 Subject: [Icc-avr] Optimization of write and read to register STS, LDS In-Reply-To: <20071001183508.894BD6B0A@annatar.imt.liu.se> References: <20070930094045.7B7B26B13@annatar.imt.liu.se> <20071001183508.894BD6B0A@annatar.imt.liu.se> Message-ID: <200710011930.l91JUwjX022527@dragonsgate2.imagecraft.com> val_1 being the same as "1" will/should be caught by MIO (PRO). This optimization looks doable, probably will only add it to the PRO version though... Thanks for the suggestion... At 11:35 AM 10/1/2007, Bengt Ragnemalm wrote: >Richard, as this is a post for optimization I think this is most for you. > >I post the code here so I can describe how this optimization works. What I >ask is if this type of optimization is or can be done by the compiler. When >there is always the question of how much effect it will have. > >----- >Assembler snippet: >RETRO_CAL: STS CLKPR,V128 ;DROP CLOCK TO 1Mhz > STS CLKPR,THREE ; > STS TIMSK1,ZERO ;SETUP TIMER1 > STS TCCR1B,ONE ;TC1 = 1MHz = 1uS > STS TIMSK2,ZERO ;SETUP TIMER2 > STS ASSR,EIGHT ;CLOCK FROM 32KHz OSCILLATOR > LDI TMP1,200 ;OCR2A = 200 > STS OCR2A,TMP1 ;200 / 32768Hz ~= 6103uS > STS TCCR2A,ONE ;TC2 = 32768Hz ~= 30.5176uS > LDS TMP,OSCCAL ;READ OSCCAL >---- >Same snippet in C: >void OSCCAL_retrocal(void) >{ > unsigned char temp; > unsigned char val_1 = 0x01; > unsigned char low,high; > // set the CPU Frequency to 1MHz (8Mhz / 8 = 1Mhz) > CLKPR = (1< CLKPR = (1< // setup timer1 TC1= 1MHz = 1usec > TIMSK1 = 0; > TCCR1B = val_1; > // setup timer2 > TIMSK2 = 0; > // set 32,768kHz osc as source for timer2 > ASSR = (1< // 200 / 32768Hz ~= 6103uS > OCR2A = 200; > // TC2 = 32768Hz ~= 30.5176uS > TCCR2A = val_1; > temp = OSCCAL; >---- >You can see that there are several registers acesses that is done with STS >or LDS instructions. As there are so many of them someone suggested that >they were replaced with STD and LDD instructions. To use displacement I >understand that the Z register (?) must be used. Also the loading of the Z >register will cost some bytes extra. Maybe the Z register is already in use >and in that case this possibility can only occur in very special moment >making it not worth the effort. > >But I like to stretch C and the compiler to its limits to see how far you >can go before you have to switch to inline assembler. > >Also note the lokal variable val_1 that is used to set the value 1 several >times. > >Regards >Bengt > > >------------------- > > I am testing a size optimized osccal routine (RetroDan, AVRfreaks). It is >a > > hint there about the possibility to optimize many STS and LDS >instructions > > with LDD and STD (load and store with displacement). > > > > It occured to me that why could a C-compiler not catch that possibility? >Or > > maybe it would be possible to "fool" the compiler to use it anyway. > > > > Regards, > > Bengt // richard (This email is for mailing lists. To reach me directly, please use richard at imagecraft.com) From MDipperstein at CalAmp.com Mon Oct 1 17:14:30 2007 From: MDipperstein at CalAmp.com (Michael Dipperstein) Date: Mon Oct 1 17:26:36 2007 Subject: [Icc-avr] Optimization of write and read to register STS, LDS In-Reply-To: <20071001183508.894BD6B0A@annatar.imt.liu.se> Message-ID: Bengt, You can get the compiler to use the Z register if you use a local register pointer + offset instead of the register name directly. You just need to make sure the offset is never larger than 63. Here's what I came up with using ATmega48 and version 7.13A with no optimization: void OsccalRetrocal(void) { unsigned char temp; unsigned char val_1 = 0x01; volatile unsigned char *reg; // set the CPU Frequency to 1MHz (8Mhz / 8 = 1Mhz) reg = &CLKPR; *reg = (1< R16 ; val_1 -> R16 ; reg -> R18,R19 .even _OsccalRetrocal:: .dbline -1 .dbline 242 ; } ; ; void OsccalRetrocal(void) ; { .dbline 244 ; unsigned char temp; ; unsigned char val_1 = 0x01; ldi R16,1 .dbline 248 ; volatile unsigned char *reg; ; ; // set the CPU Frequency to 1MHz (8Mhz / 8 = 1Mhz) ; reg = &CLKPR; ldi R18,97 ldi R19,0 .dbline 249 ; *reg = (1< I am testing a size optimized osccal routine (RetroDan, AVRfreaks). It is a > hint there about the possibility to optimize many STS and LDS instructions > with LDD and STD (load and store with displacement). > > It occured to me that why could a C-compiler not catch that possibility? Or > maybe it would be possible to "fool" the compiler to use it anyway. > > Regards, > Bengt > > _______________________________________________ > 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 asyms at technosoft.co.uk Tue Oct 2 09:35:56 2007 From: asyms at technosoft.co.uk (Andy Syms) Date: Tue Oct 2 10:11:40 2007 Subject: [Icc-avr] Maxim MAX6917 alarm problem In-Reply-To: Message-ID: Hi We're having trouble with the alarm on a MAX6917 I2C uP Supervisor/RTC device. I2C comms to the device is working fine and we can read/write all RTC registers. The ALM output of the MAX6917 is connected directly to the INT4 (PE4) input of a Mega2560 with internal pullup enabled. We just can't get this beast to generate an interrupt, either at a specific time, or even once per second. We've tried this on three different boards and my h/w guy (who's just shoved off on holiday) assures me that the design is good and that the boards are not faulty. Any gotchas I'm missing ? Or other suggestions ? TIA. Andy. -- >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >> >> Andy Syms Technosoft Systems Ltd >> >> email : asyms@technosoft.co.uk >> website : www.technosoft.co.uk >> >> tel : +44 (0) 1483 799554 >> fax : +44 (0) 1483 799664 >> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> From sl at ecpower.dk Tue Oct 2 11:39:32 2007 From: sl at ecpower.dk (Steven Lose) Date: Tue Oct 2 11:51:42 2007 Subject: SV: [Icc-avr] Maxim MAX6917 alarm problem References: Message-ID: <072D96786BFC014AAEBA9EB07A8070EA2CE466@seattle.ecpower.dk> Hi Andy. Doesn't use this RTC my self but had a look in the datasheet. The ALM output is open drain and active low. If your HW does not have a pull-up resistor, make sure that you have enabled the pull-up in the uP. The ALM output stays low until you clear it by SW, so make sure that your int4 clears the alarm, or the input is edge triggered, if cleared somewhere else. If you have an oscilloscope, it should be easy to verify that a correct signal is there, or even with a standard meter hence the signal stays low. (Just don't clear it by SW, so you can se the transition on the meter) 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 Andy Syms Sendt: 2. oktober 2007 18:36 Til: Discussion list for ICCAVR and ICCtiny Users. You do NOT needtosubscribeto icc-announce if you are a member of this. Emne: [Icc-avr] Maxim MAX6917 alarm problem Hi We're having trouble with the alarm on a MAX6917 I2C uP Supervisor/RTC device. I2C comms to the device is working fine and we can read/write all RTC registers. The ALM output of the MAX6917 is connected directly to the INT4 (PE4) input of a Mega2560 with internal pullup enabled. We just can't get this beast to generate an interrupt, either at a specific time, or even once per second. We've tried this on three different boards and my h/w guy (who's just shoved off on holiday) assures me that the design is good and that the boards are not faulty. Any gotchas I'm missing ? Or other suggestions ? TIA. Andy. -- >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >> >> Andy Syms Technosoft Systems Ltd >> >> email : asyms@technosoft.co.uk >> website : www.technosoft.co.uk >> >> tel : +44 (0) 1483 799554 >> fax : +44 (0) 1483 799664 >> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> _______________________________________________ Icc-avr mailing list Icc-avr@imagecraft.com http://dragonsgate.net/mailman/listinfo/icc-avr From j_baraclough at zetnet.co.uk Tue Oct 2 12:02:05 2007 From: j_baraclough at zetnet.co.uk (John Baraclough) Date: Tue Oct 2 12:14:14 2007 Subject: [Icc-avr] Maxim MAX6917 alarm problem In-Reply-To: References: Message-ID: Hi Andy, First hang an LED on the 1Hz output to make sure the oscillator is running correctly. Then put an external 10k pull-up on PE4, just in case the internal pull-ups aren't working for some reason. All the best for now, John At 17:35 02/10/2007, you wrote: >Hi > >We're having trouble with the alarm on a MAX6917 I2C uP Supervisor/RTC >device. > >I2C comms to the device is working fine and we can read/write all RTC >registers. The ALM output of the MAX6917 is connected directly to the INT4 >(PE4) input of a Mega2560 with internal pullup enabled. > >We just can't get this beast to generate an interrupt, either at a specific >time, or even once per second. > >We've tried this on three different boards and my h/w guy (who's just shoved >off on holiday) assures me that the design is good and that the boards are >not faulty. > >Any gotchas I'm missing ? Or other suggestions ? > >TIA. > >Andy. > >-- > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >> > >> Andy Syms Technosoft Systems Ltd > >> > >> email : asyms@technosoft.co.uk > >> website : www.technosoft.co.uk > >> > >> tel : +44 (0) 1483 799554 > >> fax : +44 (0) 1483 799664 > >> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > > >_______________________________________________ >Icc-avr mailing list >Icc-avr@imagecraft.com >http://dragonsgate.net/mailman/listinfo/icc-avr From paul.aa9gg at gmail.com Tue Oct 2 16:59:44 2007 From: paul.aa9gg at gmail.com (Paul Mateer) Date: Tue Oct 2 17:11:52 2007 Subject: [Icc-avr] Maxim MAX6917 alarm problem In-Reply-To: References: Message-ID: <20f5efc40710021659w6133369buaefad9a4c6eb93cf@mail.gmail.com> Hi ... I haven't used that chip, but on most you have to make sure you enable the interrupt on the RTC and make sure you have the correct alarm rate plugged into the registers. Does the RTC actually keep time (is it actually running)? I had one chip where I had to short the external back-up battery pin to ground momentaraliy before things would run. You must also clear the alarm interrupt on the RTC before another will occur too. that's my 2 cents.... On 10/2/07, John Baraclough wrote: > > Hi Andy, > > First hang an LED on the 1Hz output to make sure the oscillator is > running correctly. Then put an external 10k pull-up on PE4, just in > case the internal pull-ups aren't working for some reason. > > All the best for now, > John > > At 17:35 02/10/2007, you wrote: > >Hi > > > >We're having trouble with the alarm on a MAX6917 I2C uP Supervisor/RTC > >device. > > > >I2C comms to the device is working fine and we can read/write all RTC > >registers. The ALM output of the MAX6917 is connected directly to the > INT4 > >(PE4) input of a Mega2560 with internal pullup enabled. > > > >We just can't get this beast to generate an interrupt, either at a > specific > >time, or even once per second. > > > >We've tried this on three different boards and my h/w guy (who's just > shoved > >off on holiday) assures me that the design is good and that the boards > are > >not faulty. > > > >Any gotchas I'm missing ? Or other suggestions ? > > > >TIA. > > > >Andy. > > > >-- > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > > >> > > >> Andy Syms Technosoft Systems Ltd > > >> > > >> email : asyms@technosoft.co.uk > > >> website : www.technosoft.co.uk > > >> > > >> tel : +44 (0) 1483 799554 > > >> fax : +44 (0) 1483 799664 > > >> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > > > > > >_______________________________________________ > >Icc-avr mailing list > >Icc-avr@imagecraft.com > >http://dragonsgate.net/mailman/listinfo/icc-avr > > _______________________________________________ > Icc-avr mailing list > Icc-avr@imagecraft.com > http://dragonsgate.net/mailman/listinfo/icc-avr > -- Paul Mateer, AA9GG Elan Engineering Corp. www.elanengr.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20071002/d18dd023/attachment.html From benra at imt.liu.se Wed Oct 3 04:14:13 2007 From: benra at imt.liu.se (Bengt Ragnemalm) Date: Wed Oct 3 04:26:24 2007 Subject: [Icc-avr] Want higher UART speeds in Application Builder Message-ID: <005b01c805ae$87a38c70$b160ec82@Shagrat> Maximum speed is now 115200. I want higher speeds, up to 1 MHz as that is commonly used in some peripherals. I use 460800 with the hardware I use at the moment. Of course you can write in the speed but when we come to my own memory meaning I have to check each time. /Bengt ________________________________________________________________ Bengt Ragnemalm Tel +46 13 22 24 97 Research engineer FAX: +46 13 10 19 02 Link?pings Universitet mailto:bengt.ragnemalm@imt.liu.se Inst. f?r Medicinsk Teknik Internet: http://www.imt.liu.se S-581 85 Link?ping SWEDEN -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20071003/c4446cb2/attachment.html From BobGardner at aol.com Wed Oct 3 05:41:03 2007 From: BobGardner at aol.com (BobGardner@aol.com) Date: Wed Oct 3 05:53:13 2007 Subject: [Icc-avr] app builder feature list Message-ID: Morning compiler folks. Is there an open 'app builder bug list/ wish list'? Maybe you could have a system where folks would fill out a form checking off which new features/processors they wanted added in the next AB release and how much/how little they were prepared to pay. Example: next release could have support for AVR x,y,or z, and the survey shows that the demand is 10X greater for AVR z support, and folks are willing to pay $20 ea to expedite the upgrade, and hopefully there are several hundred of them, which might be a break even position. I think folks using the app builder would pay a small amt per release to get new functionality. Anyone else agree with me, or am I just an old obsolete capitalist? I'd like to see the wish list. ************************************** See what's new at http://www.aol.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20071003/d75037a6/attachment.html From paul.aa9gg at gmail.com Wed Oct 3 06:09:39 2007 From: paul.aa9gg at gmail.com (Paul Mateer) Date: Wed Oct 3 06:21:54 2007 Subject: [Icc-avr] app builder feature list In-Reply-To: References: Message-ID: <20f5efc40710030609u473a2203w2205568f00f56fd0@mail.gmail.com> I'm still waiting for AtMega3290 / 6490 support!! On 10/3/07, BobGardner@aol.com wrote: > > Morning compiler folks. Is there an open 'app builder bug list/ wish > list'? Maybe you could have a system where folks would fill out a form > checking off which new features/processors they wanted added in the next AB > release and how much/how little they were prepared to pay. Example: next > release could have support for AVR x,y,or z, and the survey shows that the > demand is 10X greater for AVR z support, and folks are willing to pay $20 ea > to expedite the upgrade, and hopefully there are several hundred of them, > which might be a break even position. I think folks using the app builder > would pay a small amt per release to get new functionality. Anyone else > agree with me, or am I just an old obsolete capitalist? I'd like to see the > wish list. > > > > ------------------------------ > See what's new at AOL.com and Make > AOL Your Homepage > . > > _______________________________________________ > 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/20071003/15d6c054/attachment-0001.html From amsol at amssolutions.co.za Wed Oct 3 06:40:25 2007 From: amsol at amssolutions.co.za (AMS Solutions - GJ Laubscher) Date: Wed Oct 3 06:50:40 2007 Subject: [Icc-avr] app builder feature list References: Message-ID: <003d01c805c2$f6dafc40$0200a8c0@BigFoot> Hi Group, Anyone here have an old copy of 'Turbo C++ Compiler +Asm' V5.0 - V5.2 ? (Not later eg 5.5) I am busy with a project where i require to compile files with this specific 16bit compiler. If someone here can help me, plse contact me. Thx, have a great day! Regards, Gerhard Laubscher AMS Solutions 'Electronic System Design made easy' Cape Town , Table View PO Box 132, Table View, 7439 South Africa South Africa TeleFax : +27-21-557 0160 Mobile : 082 366 1950 email : amsol@amssolutions.co.za website: http://www.amssolutions.co.za -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20071003/ce77dfcf/attachment.html From BobGardner at aol.com Wed Oct 3 06:59:54 2007 From: BobGardner at aol.com (BobGardner@aol.com) Date: Wed Oct 3 07:12:12 2007 Subject: [Icc-avr] app builder feature list Message-ID: In a message dated 10/3/2007 9:39:36 A.M. Eastern Daylight Time, amsol@amssolutions.co.za writes: Anyone here have an old copy of 'Turbo C++ Compiler +Asm' V5.0 - V5.2 ? (Not later eg 5.5) ================================= Saw this recently: _http://www.gridconnect.com/development-kits.html_ (http://www.gridconnect.com/development-kits.html) ************************************** See what's new at http://www.aol.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20071003/48f0be57/attachment.html From jassenbaum at htp-tel.de Wed Oct 3 10:54:48 2007 From: jassenbaum at htp-tel.de (Johannes Assenbaum) Date: Wed Oct 3 11:07:55 2007 Subject: [Icc-avr] app builder feature list References: Message-ID: You are right: app builder is not really up-to-date. Too bad that noone tells how to make and include additional .cpu files. I'd really like to support not only io header files but app builder, too. I don't think, it would be much, but I don't know yet. Best regards, Johannes > Morning compiler folks. Is there an open 'app builder bug list/ wish list'? > Maybe you could have a system where folks would fill out a form checking off > which new features/processors they wanted added in the next AB release and how > much/how little they were prepared to pay. Example: next release could > have support for AVR x,y,or z, and the survey shows that the demand is 10X > greater for AVR z support, and folks are willing to pay $20 ea to expedite the > upgrade, and hopefully there are several hundred of them, which might be a break > even position. I think folks using the app builder would pay a small amt per > release to get new functionality. Anyone else agree with me, or am I just an > old obsolete capitalist? I'd like to see the wish list. > ************************************** See what's new at http://www.aol.com From paul.aa9gg at gmail.com Wed Oct 3 11:11:56 2007 From: paul.aa9gg at gmail.com (Paul Mateer) Date: Wed Oct 3 11:24:10 2007 Subject: [Icc-avr] app builder feature list In-Reply-To: References: Message-ID: <20f5efc40710031111g4cec5b57jc88375bc0d4986f9@mail.gmail.com> I tried making a .cpu file for the Mega3290 but could not get it to work. Richard told me awhile ago that the guy who did the app builder is "missing in action" On 10/3/07, Johannes Assenbaum wrote: > > You are right: app builder is not really up-to-date. > > Too bad that noone tells how to make and include additional .cpu files. > > I'd really like to support not only io header files but app builder, too. > I don't think, it would be much, but I don't know yet. > > Best regards, > Johannes > > > > Morning compiler folks. Is there an open 'app builder bug list/ wish > list'? > > Maybe you could have a system where folks would fill out a form checking > off > > which new features/processors they wanted added in the next AB release > and how > > much/how little they were prepared to pay. Example: next release could > > have support for AVR x,y,or z, and the survey shows that the demand is > 10X > > greater for AVR z support, and folks are willing to pay $20 ea to > expedite the > > upgrade, and hopefully there are several hundred of them, which might be > a break > > even position. I think folks using the app builder would pay a small amt > per > > release to get new functionality. Anyone else agree with me, or am I > just an > > old obsolete capitalist? I'd like to see the wish list. > > > > > ************************************** See what's new at > http://www.aol.com > > > > _______________________________________________ > 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/20071003/a250675e/attachment.html From jassenbaum at htp-tel.de Wed Oct 3 11:48:41 2007 From: jassenbaum at htp-tel.de (Johannes Assenbaum) Date: Wed Oct 3 12:01:34 2007 Subject: [Icc-avr] app builder feature list References: <20f5efc40710031111g4cec5b57jc88375bc0d4986f9@mail.gmail.com> Message-ID: Afaik app builder is maintained further, only there is no how-to re .cpu files existing yet. Would be really helpful. Best regards, Johannes > I tried making a .cpu file for the Mega3290 but could not get it to work. > Richard told me awhile ago that the guy who did the app builder is "missing > in action" > On 10/3/07, Johannes Assenbaum wrote: >> >> You are right: app builder is not really up-to-date. >> >> Too bad that noone tells how to make and include additional .cpu files. >> >> I'd really like to support not only io header files but app builder, too. >> I don't think, it would be much, but I don't know yet. >> >> Best regards, >> Johannes >> >> >> > Morning compiler folks. Is there an open 'app builder bug list/ wish >> list'? >> > Maybe you could have a system where folks would fill out a form checking >> off >> > which new features/processors they wanted added in the next AB release >> and how >> > much/how little they were prepared to pay. Example: next release could >> > have support for AVR x,y,or z, and the survey shows that the demand is >> 10X >> > greater for AVR z support, and folks are willing to pay $20 ea to >> expedite the >> > upgrade, and hopefully there are several hundred of them, which might be >> a break >> > even position. I think folks using the app builder would pay a small amt >> per >> > release to get new functionality. Anyone else agree with me, or am I >> just an >> > old obsolete capitalist? I'd like to see the wish list. >> >> >> >> > ************************************** See what's new at >> http://www.aol.com >> >> >> >> _______________________________________________ >> Icc-avr mailing list >> Icc-avr@imagecraft.com >> http://dragonsgate.net/mailman/listinfo/icc-avr >> > -- > Paul Mateer, AA9GG > Elan Engineering Corp. > www.elanengr.com From michael.bate at integra-ls.com Wed Oct 3 12:53:30 2007 From: michael.bate at integra-ls.com (Bate, Michael) Date: Wed Oct 3 13:05:39 2007 Subject: [Icc-avr] CRC Check of Program Memory In-Reply-To: References: Message-ID: Rodney (and the ICC list), Thank you! Actually my problem should be fairly simple, since I already have a routine (in C) to calculate CRCs. I really have two questions: 1. How do I loop through the program memory? 2. How do I store the correct CRC at the end of the Flash memory? Regarding question 1, I tried coding: for (iprog = __func_lit_start; iprog <= __text_end; iprog++) { Add contents of location "iprog" to CRC } Where __func_lit_start and _text_end are defined as external, but they do not link (the map says they are "Global Symbols" but the linker doesn't know about them). Regarding the second question: if I can get the first part working, I can run with the debugger to get the correct CRC, but then what do I do with it? How do I get it into Flash memory? Am I doing something stupid? Michael Bate ________________________________ From: Rodney Pearson [mailto:rodney@junipersys.com] Sent: Friday, September 28, 2007 12:09 PM To: Discussion list for ICCAVR and ICCtiny Users. You do NOT need tosubscribeto icc-announce if you are a member of this.; Bate, Michael Subject: RE: [Icc-avr] CRC Check of Program Memory Hello Michael - I have worked on this. I developed a bootloader for the M2560 that has a bootstrap that does what you are trying to do. The app note you refer to has all the pieces, but it is not the clearest code in the world if your plan on implementing it differently than Atmel has...I ended up just stripping out the relevant CRC checking code (rot_word,rot_loop), creating my own ASM routines and then called those from the C code. This made it much more flexible for me since my CRC is pre-calculated and stored in the last WORD of Flash... Cheers! Rodney Pearson Software Engineer Juniper Systems, Inc. www.junipersys.com ________________________________ From: icc-avr-bounces@imagecraft.com [mailto:icc-avr-bounces@imagecraft.com] On Behalf Of Bate, Michael Sent: Friday, September 28, 2007 9:06 AM To: icc-avr@imagecraft.com Subject: [Icc-avr] CRC Check of Program Memory This may have come up before; unfortunately I don't see how to search the archives of this list. I am looking for a way to validate the program memory of an AVR Atmega168. Atmel provides an application note (AVR236) which includes some assembly language code, but I do not see how to combine this code with my C program written for the ImageCraft C compiler. There are problems assembling this even with the assembler in AVR Studio. Has anyone solved this problem already? Thanks in advance. ---- Michael Bate Principal Software Engineer Integra Radionics 22 Terry Avenue Burlington, MA 01803 Phone: 781-565-1313 Fax: 781-238-0606 E-mail: www.radionics.com Integra Radionics, Trusted Accuracy ****************************** Confidentiality Notice: This e-mail transmission may contain material that is confidential and/or proprietary. If the reader of this message is not the intended recipient, dissemination, disclosure, distribution or reliance on the contents is strictly prohibited. If you have received this e-mail transmission in error, please reply to the sender and delete the message and its contents from your system. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20071003/c6e0f028/attachment.html From richard-lists at imagecraft.com Wed Oct 3 13:31:28 2007 From: richard-lists at imagecraft.com (Richard) Date: Wed Oct 3 13:43:18 2007 Subject: [Icc-avr] app builder feature list In-Reply-To: References: Message-ID: <200710032043.l93KhHqm053535@dragonsgate2.imagecraft.com> An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20071003/1051f0e9/attachment.html From rodney at junipersys.com Thu Oct 4 09:02:19 2007 From: rodney at junipersys.com (Rodney Pearson) Date: Thu Oct 4 09:17:01 2007 Subject: [Icc-avr] CRC Check of Program Memory In-Reply-To: References: Message-ID: Michael - 1. How do I loop through the program memory? Looping through memory is easy, reading it is the tricky part. Unless I missed something, I've found that ICCAVR does not handle very well reading Flash above the 64KB boundary (ie - using ELPM v. LPM). The compiler doesn't know how to (1) implement ELPM to read flash directly and (2) use RAMPZ...at least from what I've found in the Help and experience. Richard may have to set me straight on this one...=) Since I am developing for the M2560, I had to implement the looping through reading program memory in ASM to reach beyond the 64KB boundary. I didn't bother messing with the compiler area names since I needed to perform a CRC on the entire application space starting at 0x0000 (includes the startup code and variables) and going clear up to the bootloader space (last 1/2/4/8 KB of Flash). I have been unsuccessful at getting ICCAVR to generate proper ASM code from C code to read a flash address directly [ie - something like *(unsigned char*) ()], so I've written my routines in ASM to read flash. ICCAVR does not have a "FLASH" identifier like IAR to let you tell the compiler that you wish to access a flash address instead of normal SRAM. There is also the issue of having to manually manipulate RAMPZ on devices with >64KB flash... 2. How do I store the correct CRC at the end of the Flash memory? You can either use a small app to edit the HEX file to add the CRC bytes to the proper location or you can hand-edit the HEX file (just google "Intel HEX" to learn what to do). I have implemented a bootloader, so I built an application that adds the CRC into the HEX flash image when it is creating the update file to feed to the bootloader. Another option is to create the CRC routine that both generates and checks the CRC. Then you only have figure out a way to tell your code to generate a CRC if one isn't there. This way you do not have to modify the HEX flash image at all. This does require the use of the SPM instruction in your code to burn Flash on-chip. A standard CRC-16 routine will both generate and validate a CRC with the same code. My bootloader implements ASM CRC code (that I can send to you) that will both generate and validate a CRC. I currently only use it to validate the CRC. It all depends on how you plan to (1) generate the CRC and (2) use it on the device. Currently I do the following: 1. A bootloader is implemented that performs the CRC check on the application space only (no CRC on the bootloader). 2. An external PC application takes the HEX file generated by ICCAVR and converts it to a format the bootloader understands. 3. Additionally, this app also calculates the CRC on the application flash space and appends the CRC to the last 2 bytes of the application memory space. This is added to the update file built for the bootloader. 4. I burn the bootloader to the device and then use the bootloader to update/burn the flash application memory. 5. Now I can use the bootloader to perform the CRC check on the entire flash application space anytime I want to. I hope this helps more than confuses...or at least avoid stating the obvious. =) I have submitted my CRC code (including looping through reading Flash) to Richard as a code sample, but I can send it to you as well if you think it can help. Cheers! Rodney Pearson Software Engineer Juniper Systems, Inc. www.junipersys.com ________________________________ From: Bate, Michael [mailto:michael.bate@integra-ls.com] Sent: Wednesday, October 03, 2007 1:54 PM To: Rodney Pearson; icc-avr@imagecraft.com Subject: RE: [Icc-avr] CRC Check of Program Memory Rodney (and the ICC list), Thank you! Actually my problem should be fairly simple, since I already have a routine (in C) to calculate CRCs. I really have two questions: 1. How do I loop through the program memory? 2. How do I store the correct CRC at the end of the Flash memory? Regarding question 1, I tried coding: for (iprog = __func_lit_start; iprog <= __text_end; iprog++) { Add contents of location "iprog" to CRC } Where __func_lit_start and _text_end are defined as external, but they do not link (the map says they are "Global Symbols" but the linker doesn't know about them). Regarding the second question: if I can get the first part working, I can run with the debugger to get the correct CRC, but then what do I do with it? How do I get it into Flash memory? Am I doing something stupid? Michael Bate ________________________________ From: Rodney Pearson [mailto:rodney@junipersys.com] Sent: Friday, September 28, 2007 12:09 PM To: Discussion list for ICCAVR and ICCtiny Users. You do NOT need tosubscribeto icc-announce if you are a member of this.; Bate, Michael Subject: RE: [Icc-avr] CRC Check of Program Memory Hello Michael - I have worked on this. I developed a bootloader for the M2560 that has a bootstrap that does what you are trying to do. The app note you refer to has all the pieces, but it is not the clearest code in the world if your plan on implementing it differently than Atmel has...I ended up just stripping out the relevant CRC checking code (rot_word,rot_loop), creating my own ASM routines and then called those from the C code. This made it much more flexible for me since my CRC is pre-calculated and stored in the last WORD of Flash... Cheers! Rodney Pearson Software Engineer Juniper Systems, Inc. www.junipersys.com ________________________________ From: icc-avr-bounces@imagecraft.com [mailto:icc-avr-bounces@imagecraft.com] On Behalf Of Bate, Michael Sent: Friday, September 28, 2007 9:06 AM To: icc-avr@imagecraft.com Subject: [Icc-avr] CRC Check of Program Memory This may have come up before; unfortunately I don't see how to search the archives of this list. I am looking for a way to validate the program memory of an AVR Atmega168. Atmel provides an application note (AVR236) which includes some assembly language code, but I do not see how to combine this code with my C program written for the ImageCraft C compiler. There are problems assembling this even with the assembler in AVR Studio. Has anyone solved this problem already? Thanks in advance. ---- Michael Bate Principal Software Engineer Integra Radionics 22 Terry Avenue Burlington, MA 01803 Phone: 781-565-1313 Fax: 781-238-0606 E-mail: www.radionics.com Integra Radionics, Trusted Accuracy ****************************** Confidentiality Notice: This e-mail transmission may contain material that is confidential and/or proprietary. If the reader of this message is not the intended recipient, dissemination, disclosure, distribution or reliance on the contents is strictly prohibited. If you have received this e-mail transmission in error, please reply to the sender and delete the message and its contents from your system. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20071004/e37ef429/attachment-0001.html From sl at ecpower.dk Thu Oct 4 22:44:15 2007 From: sl at ecpower.dk (Steven Lose) Date: Thu Oct 4 23:04:37 2007 Subject: SV: [Icc-avr] CRC Check of Program Memory References: Message-ID: <072D96786BFC014AAEBA9EB07A8070EA2CE5BF@seattle.ecpower.dk> Hi "ICCAVR does not have a "FLASH" identifier like IAR to let you tell the compiler that you wish to access a flash address instead of normal SRAM" That is the const indentifier. Med venlig hilsen / Best regards / mit freundlichen Gr??en EC POWER A/S Steven Lose Software Ingeni?r Tlf.: +45 87434100 Direkte tlf. +45 58286608 Email: sl@ecpower.dk www.ecpower.dk ________________________________ Fra: icc-avr-bounces@imagecraft.com [mailto:icc-avr-bounces@imagecraft.com] P? vegne af Rodney Pearson Sendt: 4. oktober 2007 18:02 Til: Bate, Michael; icc-avr@imagecraft.com Emne: RE: [Icc-avr] CRC Check of Program Memory Michael - 1. How do I loop through the program memory? Looping through memory is easy, reading it is the tricky part. Unless I missed something, I've found that ICCAVR does not handle very well reading Flash above the 64KB boundary (ie - using ELPM v. LPM). The compiler doesn't know how to (1) implement ELPM to read flash directly and (2) use RAMPZ...at least from what I've found in the Help and experience. Richard may have to set me straight on this one...=) Since I am developing for the M2560, I had to implement the looping through reading program memory in ASM to reach beyond the 64KB boundary. I didn't bother messing with the compiler area names since I needed to perform a CRC on the entire application space starting at 0x0000 (includes the startup code and variables) and going clear up to the bootloader space (last 1/2/4/8 KB of Flash). I have been unsuccessful at getting ICCAVR to generate proper ASM code from C code to read a flash address directly [ie - something like *(unsigned char*) ()], so I've written my routines in ASM to read flash. ICCAVR does not have a "FLASH" identifier like IAR to let you tell the compiler that you wish to access a flash address instead of normal SRAM. There is also the issue of having to manually manipulate RAMPZ on devices with >64KB flash... 2. How do I store the correct CRC at the end of the Flash memory? You can either use a small app to edit the HEX file to add the CRC bytes to the proper location or you can hand-edit the HEX file (just google "Intel HEX" to learn what to do). I have implemented a bootloader, so I built an application that adds the CRC into the HEX flash image when it is creating the update file to feed to the bootloader. Another option is to create the CRC routine that both generates and checks the CRC. Then you only have figure out a way to tell your code to generate a CRC if one isn't there. This way you do not have to modify the HEX flash image at all. This does require the use of the SPM instruction in your code to burn Flash on-chip. A standard CRC-16 routine will both generate and validate a CRC with the same code. My bootloader implements ASM CRC code (that I can send to you) that will both generate and validate a CRC. I currently only use it to validate the CRC. It all depends on how you plan to (1) generate the CRC and (2) use it on the device. Currently I do the following: 1. A bootloader is implemented that performs the CRC check on the application space only (no CRC on the bootloader). 2. An external PC application takes the HEX file generated by ICCAVR and converts it to a format the bootloader understands. 3. Additionally, this app also calculates the CRC on the application flash space and appends the CRC to the last 2 bytes of the application memory space. This is added to the update file built for the bootloader. 4. I burn the bootloader to the device and then use the bootloader to update/burn the flash application memory. 5. Now I can use the bootloader to perform the CRC check on the entire flash application space anytime I want to. I hope this helps more than confuses...or at least avoid stating the obvious. =) I have submitted my CRC code (including looping through reading Flash) to Richard as a code sample, but I can send it to you as well if you think it can help. Cheers! Rodney Pearson Software Engineer Juniper Systems, Inc. www.junipersys.com ________________________________ From: Bate, Michael [mailto:michael.bate@integra-ls.com] Sent: Wednesday, October 03, 2007 1:54 PM To: Rodney Pearson; icc-avr@imagecraft.com Subject: RE: [Icc-avr] CRC Check of Program Memory Rodney (and the ICC list), Thank you! Actually my problem should be fairly simple, since I already have a routine (in C) to calculate CRCs. I really have two questions: 1. How do I loop through the program memory? 2. How do I store the correct CRC at the end of the Flash memory? Regarding question 1, I tried coding: for (iprog = __func_lit_start; iprog <= __text_end; iprog++) { Add contents of location "iprog" to CRC } Where __func_lit_start and _text_end are defined as external, but they do not link (the map says they are "Global Symbols" but the linker doesn't know about them). Regarding the second question: if I can get the first part working, I can run with the debugger to get the correct CRC, but then what do I do with it? How do I get it into Flash memory? Am I doing something stupid? Michael Bate ________________________________ From: Rodney Pearson [mailto:rodney@junipersys.com] Sent: Friday, September 28, 2007 12:09 PM To: Discussion list for ICCAVR and ICCtiny Users. You do NOT need tosubscribeto icc-announce if you are a member of this.; Bate, Michael Subject: RE: [Icc-avr] CRC Check of Program Memory Hello Michael - I have worked on this. I developed a bootloader for the M2560 that has a bootstrap that does what you are trying to do. The app note you refer to has all the pieces, but it is not the clearest code in the world if your plan on implementing it differently than Atmel has...I ended up just stripping out the relevant CRC checking code (rot_word,rot_loop), creating my own ASM routines and then called those from the C code. This made it much more flexible for me since my CRC is pre-calculated and stored in the last WORD of Flash... Cheers! Rodney Pearson Software Engineer Juniper Systems, Inc. www.junipersys.com ________________________________ From: icc-avr-bounces@imagecraft.com [mailto:icc-avr-bounces@imagecraft.com] On Behalf Of Bate, Michael Sent: Friday, September 28, 2007 9:06 AM To: icc-avr@imagecraft.com Subject: [Icc-avr] CRC Check of Program Memory This may have come up before; unfortunately I don't see how to search the archives of this list. I am looking for a way to validate the program memory of an AVR Atmega168. Atmel provides an application note (AVR236) which includes some assembly language code, but I do not see how to combine this code with my C program written for the ImageCraft C compiler. There are problems assembling this even with the assembler in AVR Studio. Has anyone solved this problem already? Thanks in advance. ---- Michael Bate Principal Software Engineer Integra Radionics 22 Terry Avenue Burlington, MA 01803 Phone: 781-565-1313 Fax: 781-238-0606 E-mail: www.radionics.com Integra Radionics, Trusted Accuracy ****************************** Confidentiality Notice: This e-mail transmission may contain material that is confidential and/or proprietary. If the reader of this message is not the intended recipient, dissemination, disclosure, distribution or reliance on the contents is strictly prohibited. If you have received this e-mail transmission in error, please reply to the sender and delete the message and its contents from your system. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20071005/2dfb3ac5/attachment-0001.html From jassenbaum at htp-tel.de Fri Oct 5 12:09:36 2007 From: jassenbaum at htp-tel.de (Johannes Assenbaum) Date: Fri Oct 5 12:22:41 2007 Subject: [Icc-avr] New Map File Summary Message-ID: Hi all, you may like to beta-test latest Map File Summary. In file mpdAVR.switches you'll find new options including sorted output, that are not supported by ide yet and maybe never will. Download updater as an exe http://avr.jassenbaum.de/iccv7avr/files/ICCV7AVR_mpdAVR.dll_update.exe or zipped http://avr.jassenbaum.de/iccv7avr/files/ICCV7AVR_mpdAVR.dll_update.zip Best regards, Johannes From rodney at junipersys.com Fri Oct 5 08:38:13 2007 From: rodney at junipersys.com (Rodney Pearson) Date: Fri Oct 5 12:23:17 2007 Subject: [Icc-avr] CRC Check of Program Memory In-Reply-To: <072D96786BFC014AAEBA9EB07A8070EA2CE5BF@seattle.ecpower.dk> References: <072D96786BFC014AAEBA9EB07A8070EA2CE5BF@seattle.ecpower.dk> Message-ID: Hi Steven - Thanks for the heads up - Michael also pointed out the same thing to me. I'm not sure how I missed it when I was developing, but I did.. Cheers! Rodney Pearson Software Engineer Juniper Systems, Inc. www.junipersys.com ________________________________ From: icc-avr-bounces@imagecraft.com [mailto:icc-avr-bounces@imagecraft.com] On Behalf Of Steven Lose Sent: Thursday, October 04, 2007 11:44 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] CRC Check of Program Memory Hi "ICCAVR does not have a "FLASH" identifier like IAR to let you tell the compiler that you wish to access a flash address instead of normal SRAM" That is the const indentifier. Med venlig hilsen / Best regards / mit freundlichen Gr??en EC POWER A/S Steven Lose Software Ingeni?r Tlf.: +45 87434100 Direkte tlf. +45 58286608 Email: sl@ecpower.dk www.ecpower.dk ________________________________ Fra: icc-avr-bounces@imagecraft.com [mailto:icc-avr-bounces@imagecraft.com] P? vegne af Rodney Pearson Sendt: 4. oktober 2007 18:02 Til: Bate, Michael; icc-avr@imagecraft.com Emne: RE: [Icc-avr] CRC Check of Program Memory Michael - 1. How do I loop through the program memory? Looping through memory is easy, reading it is the tricky part. Unless I missed something, I've found that ICCAVR does not handle very well reading Flash above the 64KB boundary (ie - using ELPM v. LPM). The compiler doesn't know how to (1) implement ELPM to read flash directly and (2) use RAMPZ...at least from what I've found in the Help and experience. Richard may have to set me straight on this one...=) Since I am developing for the M2560, I had to implement the looping through reading program memory in ASM to reach beyond the 64KB boundary. I didn't bother messing with the compiler area names since I needed to perform a CRC on the entire application space starting at 0x0000 (includes the startup code and variables) and going clear up to the bootloader space (last 1/2/4/8 KB of Flash). I have been unsuccessful at getting ICCAVR to generate proper ASM code from C code to read a flash address directly [ie - something like *(unsigned char*) ()], so I've written my routines in ASM to read flash. ICCAVR does not have a "FLASH" identifier like IAR to let you tell the compiler that you wish to access a flash address instead of normal SRAM. There is also the issue of having to manually manipulate RAMPZ on devices with >64KB flash... 2. How do I store the correct CRC at the end of the Flash memory? You can either use a small app to edit the HEX file to add the CRC bytes to the proper location or you can hand-edit the HEX file (just google "Intel HEX" to learn what to do). I have implemented a bootloader, so I built an application that adds the CRC into the HEX flash image when it is creating the update file to feed to the bootloader. Another option is to create the CRC routine that both generates and checks the CRC. Then you only have figure out a way to tell your code to generate a CRC if one isn't there. This way you do not have to modify the HEX flash image at all. This does require the use of the SPM instruction in your code to burn Flash on-chip. A standard CRC-16 routine will both generate and validate a CRC with the same code. My bootloader implements ASM CRC code (that I can send to you) that will both generate and validate a CRC. I currently only use it to validate the CRC. It all depends on how you plan to (1) generate the CRC and (2) use it on the device. Currently I do the following: 1. A bootloader is implemented that performs the CRC check on the application space only (no CRC on the bootloader). 2. An external PC application takes the HEX file generated by ICCAVR and converts it to a format the bootloader understands. 3. Additionally, this app also calculates the CRC on the application flash space and appends the CRC to the last 2 bytes of the application memory space. This is added to the update file built for the bootloader. 4. I burn the bootloader to the device and then use the bootloader to update/burn the flash application memory. 5. Now I can use the bootloader to perform the CRC check on the entire flash application space anytime I want to. I hope this helps more than confuses...or at least avoid stating the obvious. =) I have submitted my CRC code (including looping through reading Flash) to Richard as a code sample, but I can send it to you as well if you think it can help. Cheers! Rodney Pearson Software Engineer Juniper Systems, Inc. www.junipersys.com ________________________________ From: Bate, Michael [mailto:michael.bate@integra-ls.com] Sent: Wednesday, October 03, 2007 1:54 PM To: Rodney Pearson; icc-avr@imagecraft.com Subject: RE: [Icc-avr] CRC Check of Program Memory Rodney (and the ICC list), Thank you! Actually my problem should be fairly simple, since I already have a routine (in C) to calculate CRCs. I really have two questions: 1. How do I loop through the program memory? 2. How do I store the correct CRC at the end of the Flash memory? Regarding question 1, I tried coding: for (iprog = __func_lit_start; iprog <= __text_end; iprog++) { Add contents of location "iprog" to CRC } Where __func_lit_start and _text_end are defined as external, but they do not link (the map says they are "Global Symbols" but the linker doesn't know about them). Regarding the second question: if I can get the first part working, I can run with the debugger to get the correct CRC, but then what do I do with it? How do I get it into Flash memory? Am I doing something stupid? Michael Bate ________________________________ From: Rodney Pearson [mailto:rodney@junipersys.com] Sent: Friday, September 28, 2007 12:09 PM To: Discussion list for ICCAVR and ICCtiny Users. You do NOT need tosubscribeto icc-announce if you are a member of this.; Bate, Michael Subject: RE: [Icc-avr] CRC Check of Program Memory Hello Michael - I have worked on this. I developed a bootloader for the M2560 that has a bootstrap that does what you are trying to do. The app note you refer to has all the pieces, but it is not the clearest code in the world if your plan on implementing it differently than Atmel has...I ended up just stripping out the relevant CRC checking code (rot_word,rot_loop), creating my own ASM routines and then called those from the C code. This made it much more flexible for me since my CRC is pre-calculated and stored in the last WORD of Flash... Cheers! Rodney Pearson Software Engineer Juniper Systems, Inc. www.junipersys.com ________________________________ From: icc-avr-bounces@imagecraft.com [mailto:icc-avr-bounces@imagecraft.com] On Behalf Of Bate, Michael Sent: Friday, September 28, 2007 9:06 AM To: icc-avr@imagecraft.com Subject: [Icc-avr] CRC Check of Program Memory This may have come up before; unfortunately I don't see how to search the archives of this list. I am looking for a way to validate the program memory of an AVR Atmega168. Atmel provides an application note (AVR236) which includes some assembly language code, but I do not see how to combine this code with my C program written for the ImageCraft C compiler. There are problems assembling this even with the assembler in AVR Studio. Has anyone solved this problem already? Thanks in advance. ---- Michael Bate Principal Software Engineer Integra Radionics 22 Terry Avenue Burlington, MA 01803 Phone: 781-565-1313 Fax: 781-238-0606 E-mail: www.radionics.com Integra Radionics, Trusted Accuracy ****************************** Confidentiality Notice: This e-mail transmission may contain material that is confidential and/or proprietary. If the reader of this message is not the intended recipient, dissemination, disclosure, distribution or reliance on the contents is strictly prohibited. If you have received this e-mail transmission in error, please reply to the sender and delete the message and its contents from your system. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20071005/e94581c2/attachment-0001.html From benra at imt.liu.se Mon Oct 8 00:36:36 2007 From: benra at imt.liu.se (Bengt Ragnemalm) Date: Mon Oct 8 00:48:37 2007 Subject: SV: [Icc-avr] New Map File Summary In-Reply-To: References: Message-ID: <004601c8097d$f551cd40$b160ec82@Shagrat> Hi. The ZIP didn't work but the exe did. Looks great but there is a NE 0 last at this line: SRAM area "data" with global and static variables initialised NE 0 Also EQ 0: SRAM area "bss" with global and static variables initialised EQ 0 Great with the informatic text. Good job! Best regards, Bengt > -----Ursprungligt meddelande----- > Fr?n: icc-avr-bounces@imagecraft.com [mailto:icc-avr- > bounces@imagecraft.com] F?r Johannes Assenbaum > Skickat: den 5 oktober 2007 21:10 > Till: icc-avr@imagecraft.com > ?mne: [Icc-avr] New Map File Summary > > Hi all, > > you may like to beta-test latest Map File Summary. > > In file mpdAVR.switches you'll find new options including sorted output, > that are not supported by ide yet and maybe never will. > > Download updater as an exe > http://avr.jassenbaum.de/iccv7avr/files/ICCV7AVR_mpdAVR.dll_update.exe > or zipped > http://avr.jassenbaum.de/iccv7avr/files/ICCV7AVR_mpdAVR.dll_update.zip > > Best regards, > Johannes > > _______________________________________________ > Icc-avr mailing list > Icc-avr@imagecraft.com > http://dragonsgate.net/mailman/listinfo/icc-avr From schaefer at mabel.info Mon Oct 8 01:10:46 2007 From: schaefer at mabel.info (=?ISO-8859-15?Q?Thomas_Sch=E4fer?=) Date: Mon Oct 8 01:22:41 2007 Subject: [Icc-avr] AvrStudio plugin and filenames Message-ID: <4709E606.1080408@mabel.info> Hello, I've some problems with the AvrStudio Plugin. It seems to require the past millenium 8.3 file name convention. Is that right? best regards, Thomas From richard-lists at imagecraft.com Mon Oct 8 01:27:39 2007 From: richard-lists at imagecraft.com (Richard) Date: Mon Oct 8 01:40:05 2007 Subject: [Icc-avr] AvrStudio plugin and filenames In-Reply-To: <4709E606.1080408@mabel.info> References: <4709E606.1080408@mabel.info> Message-ID: <200710080840.l988e3e9017290@dragonsgate2.imagecraft.com> It's a bug that we just found. I will release a patch soon. At 01:10 AM 10/8/2007, Thomas Sch?fer wrote: >Hello, > >I've some problems with the AvrStudio Plugin. It seems to require the past >millenium 8.3 file name convention. Is that right? > >best regards, >Thomas // richard (This email is for mailing lists. To reach me directly, please use richard at imagecraft.com) From schaefer at mabel.info Mon Oct 8 01:51:48 2007 From: schaefer at mabel.info (=?ISO-8859-1?Q?Thomas_Sch=E4fer?=) Date: Mon Oct 8 02:03:35 2007 Subject: [Icc-avr] AvrStudio plugin and filenames In-Reply-To: <200710080840.l988e3e9017290@dragonsgate2.imagecraft.com> References: <4709E606.1080408@mabel.info> <200710080840.l988e3e9017290@dragonsgate2.imagecraft.com> Message-ID: <4709EFA4.9060804@mabel.info> Thanks! Richard schrieb: > It's a bug that we just found. I will release a patch soon. > > At 01:10 AM 10/8/2007, Thomas Sch?fer wrote: >> Hello, >> >> I've some problems with the AvrStudio Plugin. It seems to require the >> past >> millenium 8.3 file name convention. Is that right? >> >> best regards, >> Thomas > > // 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 sl at ecpower.dk Mon Oct 8 01:52:32 2007 From: sl at ecpower.dk (Steven Lose) Date: Mon Oct 8 02:04:50 2007 Subject: SV: [Icc-avr] New Map File Summary References: Message-ID: <072D96786BFC014AAEBA9EB07A8070EA2CE6C3@seattle.ecpower.dk> Hi Johannes. It works very nice. I haven't tried the zip, only the exe. 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 Johannes Assenbaum Sendt: 5. oktober 2007 21:10 Til: icc-avr@imagecraft.com Emne: [Icc-avr] New Map File Summary Hi all, you may like to beta-test latest Map File Summary. In file mpdAVR.switches you'll find new options including sorted output, that are not supported by ide yet and maybe never will. Download updater as an exe http://avr.jassenbaum.de/iccv7avr/files/ICCV7AVR_mpdAVR.dll_update.exe or zipped http://avr.jassenbaum.de/iccv7avr/files/ICCV7AVR_mpdAVR.dll_update.zip Best regards, Johannes _______________________________________________ Icc-avr mailing list Icc-avr@imagecraft.com http://dragonsgate.net/mailman/listinfo/icc-avr From richard at imagecraft.com Mon Oct 8 02:06:49 2007 From: richard at imagecraft.com (Richard) Date: Mon Oct 8 02:19:15 2007 Subject: [Icc-avr] AVR Studio plugin V1.01 for ICCAVR Message-ID: <200710080919.l989JDqd017618@dragonsgate2.imagecraft.com> V1.01 version of the compiler plugin for AVR Studio has been released. It fixes a bug with filenames longer than 8 characters. You can download it from the AVR Compiler "Code Samples" page, or direct URL: http://www.imagecraft.com/pub/code_samples/AVR/AvrIccPluginSetup.msi // richard On-line orders, support, and listservers available on web site. [ For technical support on ImageCraft products, please include all previous replies in your msgs. ] From schaefer at mabel.info Mon Oct 8 06:48:36 2007 From: schaefer at mabel.info (=?ISO-8859-1?Q?Thomas_Sch=E4fer?=) Date: Mon Oct 8 07:00:27 2007 Subject: [Icc-avr] AVR Studio plugin V1.01 for ICCAVR In-Reply-To: <200710080919.l989JDqd017618@dragonsgate2.imagecraft.com> References: <200710080919.l989JDqd017618@dragonsgate2.imagecraft.com> Message-ID: <470A3534.7080702@mabel.info> Hi Richard, After reinstalling the plugin 'About ICC AVR Plugin' still tells me 'Version: V 1.00' Is something wrong with the URL? regards, Thomas Richard schrieb: > V1.01 version of the compiler plugin for AVR Studio has been released. > It fixes a bug with filenames longer than 8 characters. You can download > it from the AVR Compiler "Code Samples" page, or direct URL: > http://www.imagecraft.com/pub/code_samples/AVR/AvrIccPluginSetup.msi > > > // richard > On-line orders, support, > and listservers available on web site. > [ For technical support on ImageCraft products, please include all > previous replies in your msgs. ] > _______________________________________________ > Icc-avr mailing list > Icc-avr@imagecraft.com > http://dragonsgate.net/mailman/listinfo/icc-avr From jassenbaum at htp-tel.de Mon Oct 8 11:08:58 2007 From: jassenbaum at htp-tel.de (Johannes Assenbaum) Date: Mon Oct 8 11:21:56 2007 Subject: SV: [Icc-avr] New Map File Summary References: <004601c8097d$f551cd40$b160ec82@Shagrat> Message-ID: Yes, the zip does not work. Sorry. I will fix it. The "NE 0" and "EQ 0" are templates that you can edit for your own. Just search your iccv7avr installation for "mpdAVR.areainfo" and see. Btw: There is another template file "mpdAVR.switches" noteworthy, too... Best regards, Johannes > Hi. > The ZIP didn't work but the exe did. > Looks great but there is a NE 0 last at this line: > SRAM area "data" with global and static variables initialised NE 0 > Also EQ 0: > SRAM area "bss" with global and static variables initialised EQ 0 > Great with the informatic text. Good job! > Best regards, > Bengt >> -----Ursprungligt meddelande----- >> Fr?n: icc-avr-bounces@imagecraft.com [mailto:icc-avr- >> bounces@imagecraft.com] F?r Johannes Assenbaum >> Skickat: den 5 oktober 2007 21:10 >> Till: icc-avr@imagecraft.com >> ?mne: [Icc-avr] New Map File Summary >> >> Hi all, >> >> you may like to beta-test latest Map File Summary. >> >> In file mpdAVR.switches you'll find new options including sorted output, >> that are not supported by ide yet and maybe never will. >> >> Download updater as an exe >> http://avr.jassenbaum.de/iccv7avr/files/ICCV7AVR_mpdAVR.dll_update.exe >> or zipped >> http://avr.jassenbaum.de/iccv7avr/files/ICCV7AVR_mpdAVR.dll_update.zip >> >> Best regards, >> Johannes >> >> _______________________________________________ >> 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 Free Edition. > Version: 7.5.488 / Virus Database: 269.14.4/1057 - Release Date: 08.10.07 09:04 From richard-lists at imagecraft.com Mon Oct 8 12:09:49 2007 From: richard-lists at imagecraft.com (Richard) Date: Mon Oct 8 12:22:15 2007 Subject: [Icc-avr] AVR Studio plugin V1.01 for ICCAVR In-Reply-To: <470A3534.7080702@mabel.info> References: <200710080919.l989JDqd017618@dragonsgate2.imagecraft.com> <470A3534.7080702@mabel.info> Message-ID: <200710081922.l98JMEfe025954@dragonsgate2.imagecraft.com> Yes it's correct. I forgot to update the version. When things are stablized, the plugin will become part of the official demo distribution and this won't happen. At 06:48 AM 10/8/2007, Thomas Sch?fer wrote: >Hi Richard, > >After reinstalling the plugin 'About ICC AVR >Plugin' still tells me 'Version: V >1.00' >Is something wrong with the URL? > >regards, >Thomas > >Richard schrieb: > > V1.01 version of the compiler plugin for AVR Studio has been released. > > It fixes a bug with filenames longer than 8 characters. You can download > > it from the AVR Compiler "Code Samples" page, or direct URL: > > http://www.imagecraft.com/pub/code_samples/AVR/AvrIccPluginSetup.msi // richard (This email is for mailing lists. To reach me directly, please use richard at imagecraft.com) From richard-lists at imagecraft.com Mon Oct 8 12:12:26 2007 From: richard-lists at imagecraft.com (Richard) Date: Mon Oct 8 12:24:52 2007 Subject: [Icc-avr] app builder feature list In-Reply-To: References: Message-ID: <200710081924.l98JOpvI026009@dragonsgate2.imagecraft.com> The AppB is being updated right now. We should have a new release in 1-2 weeks that cover the missing M32x and Tiny2x. The problem is not that we don't want to disclose the nature of the .cpu files, but that because there are hard coded stuff in the DLL to support each device. Of course, ideally Atmel should release some sort XML files to describe the devices, but since they don't, it's a eye-ball to read the datasheet process :-( At 10:54 AM 10/3/2007, Johannes Assenbaum wrote: >You are right: app builder is not really up-to-date. > >Too bad that noone tells how to make and include additional .cpu files. > >I'd really like to support not only io header files but app builder, >too. I don't think, it would be much, but I don't know yet. // richard (This email is for mailing lists. To reach me directly, please use richard at imagecraft.com) From schaefer at mabel.info Mon Oct 8 13:18:48 2007 From: schaefer at mabel.info (=?ISO-8859-1?Q?Thomas_Sch=E4fer?=) Date: Mon Oct 8 13:31:06 2007 Subject: [Icc-avr] app builder feature list In-Reply-To: <200710081924.l98JOpvI026009@dragonsgate2.imagecraft.com> References: <200710081924.l98JOpvI026009@dragonsgate2.imagecraft.com> Message-ID: <470A90A8.3030003@mabel.info> Of course, ideally Atmel should release some sort XML files > to describe the devices, but since they don't, it's a eye-ball to read > the datasheet process :-( How about the 'Partdescriptionfiles', delivered with AVR Studio. I haven't looked deeper inside yet, but it looks to me like what the name promises. regards, Thomas From MDipperstein at CalAmp.com Mon Oct 8 13:23:35 2007 From: MDipperstein at CalAmp.com (Michael Dipperstein) Date: Mon Oct 8 13:35:49 2007 Subject: [Icc-avr] app builder feature list In-Reply-To: <200710081924.l98JOpvI026009@dragonsgate2.imagecraft.com> Message-ID: Richard, I don't know what kind of information you need, but AVR Studio includes XML descriptions in its Partdescriptionfiles subdirectory. Maybe they'll help speed things up for you. -Mike -----Original Message----- From: icc-avr-bounces@imagecraft.com [mailto:icc-avr-bounces@imagecraft.com] On Behalf Of Richard Sent: Monday, October 08, 2007 12:12 PM To: Johannes Assenbaum; Discussion list for ICCAVR and ICCtiny Users. You do NOT need tosubscribe to icc-announce if you are a member of this.; icc-avr@imagecraft.com Subject: Re: [Icc-avr] app builder feature list The AppB is being updated right now. We should have a new release in 1-2 weeks that cover the missing M32x and Tiny2x. The problem is not that we don't want to disclose the nature of the .cpu files, but that because there are hard coded stuff in the DLL to support each device. Of course, ideally Atmel should release some sort XML files to describe the devices, but since they don't, it's a eye-ball to read the datasheet process :-( At 10:54 AM 10/3/2007, Johannes Assenbaum wrote: >You are right: app builder is not really up-to-date. > >Too bad that noone tells how to make and include additional .cpu files. > >I'd really like to support not only io header files but app builder, >too. I don't think, it would be much, but I don't know yet. // 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 schaefer at mabel.info Tue Oct 9 00:02:16 2007 From: schaefer at mabel.info (=?ISO-8859-1?Q?Thomas_Sch=E4fer?=) Date: Tue Oct 9 00:14:09 2007 Subject: [Icc-avr] AVR Studio plugin V1.01 for ICCAVR In-Reply-To: <200710081922.l98JMEfe025954@dragonsgate2.imagecraft.com> References: <200710080919.l989JDqd017618@dragonsgate2.imagecraft.com> <470A3534.7080702@mabel.info> <200710081922.l98JMEfe025954@dragonsgate2.imagecraft.com> Message-ID: <470B2778.4030601@mabel.info> OK. Plug-In Manager says Version 1,0,0,1, but the problem with the long file names is still there. While the build process the compiler generates from a LongFileName.c an LongFi~1.o file, and afterwards the process fails because 'LongFileName.o' couldn't opened. regards, Thomas Richard schrieb: > Yes it's correct. I forgot to update the version. > > When things are stablized, the plugin will become part of the official > demo distribution and this won't happen. > > At 06:48 AM 10/8/2007, Thomas Sch?fer wrote: >> Hi Richard, >> >> After reinstalling the plugin 'About ICC AVR Plugin' still tells me >> 'Version: V >> 1.00' >> Is something wrong with the URL? >> >> regards, >> Thomas >> >> Richard schrieb: >> > V1.01 version of the compiler plugin for AVR Studio has been released. >> > It fixes a bug with filenames longer than 8 characters. You can >> download >> > it from the AVR Compiler "Code Samples" page, or direct URL: >> > http://www.imagecraft.com/pub/code_samples/AVR/AvrIccPluginSetup.msi > > // richard (This email is for mailing lists. To reach me directly, > please use richard at imagecraft.com) > > _______________________________________________ > Icc-avr mailing list > Icc-avr@imagecraft.com > http://dragonsgate.net/mailman/listinfo/icc-avr From richard-lists at imagecraft.com Tue Oct 9 00:44:35 2007 From: richard-lists at imagecraft.com (Richard) Date: Tue Oct 9 00:57:12 2007 Subject: [Icc-avr] AVR Studio plugin V1.01 for ICCAVR In-Reply-To: <470B2778.4030601@mabel.info> References: <200710080919.l989JDqd017618@dragonsgate2.imagecraft.com> <470A3534.7080702@mabel.info> <200710081922.l98JMEfe025954@dragonsgate2.imagecraft.com> <470B2778.4030601@mabel.info> Message-ID: <200710090757.l997vBZF034218@dragonsgate2.imagecraft.com> That's not the right .msi then. I will check. The new one should not generate short name except for file/path with spaces, and I have verified that, so may be I didn't upload right... At 12:02 AM 10/9/2007, Thomas Sch?fer wrote: >OK. Plug-In Manager says Version 1,0,0,1, but the problem with the long file >names is still there. >While the build process the compiler generates from a LongFileName.c an >LongFi~1.o file, and afterwards the process fails because 'LongFileName.o' >couldn't opened. > >regards, >Thomas > >Richard schrieb: > > Yes it's correct. I forgot to update the version. > > > > When things are stablized, the plugin will become part of the official > > demo distribution and this won't happen. > > > > At 06:48 AM 10/8/2007, Thomas Sch?fer wrote: > >> Hi Richard, > >> > >> After reinstalling the plugin 'About ICC AVR Plugin' still tells me > >> 'Version: V > >> 1.00' > >> Is something wrong with the URL? > >> > >> regards, > >> Thomas > >> > >> Richard schrieb: > >> > V1.01 version of the compiler plugin for AVR Studio has been released. > >> > It fixes a bug with filenames longer than 8 characters. You can > >> download > >> > it from the AVR Compiler "Code Samples" page, or direct URL: > >> > http://www.imagecraft.com/pub/code_samples/AVR/AvrIccPluginSetup.msi > > > > // 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 // richard (This email is for mailing lists. To reach me directly, please use richard at imagecraft.com) From tim at sabretechnology.co.uk Tue Oct 9 01:04:03 2007 From: tim at sabretechnology.co.uk (Tim Mitchell) Date: Tue Oct 9 01:16:11 2007 Subject: [Icc-avr] app builder feature list Message-ID: <04671BB8D269034BBC4BB6BA894867260A81C7@sserver.SabreTechnology.local> Michael Dipperstein wrote: > Richard, > > I don't know what kind of information you need, but AVR Studio > includes XML descriptions in its Partdescriptionfiles subdirectory. > Maybe they'll help speed things up for you. > This is kind of OT, but does anyone know of an appbuilder type application which can be used for assembler? I know you can fire up ICCAVR then convert the C back to asm quite easily, just wondered if there was anything. I also think that it would be nicer if appbuilder produced its output using the bit names rather than just a hex value, e.g. TCCR0=(1< References: <200710080919.l989JDqd017618@dragonsgate2.imagecraft.com> <470A3534.7080702@mabel.info> <200710081922.l98JMEfe025954@dragonsgate2.imagecraft.com> <470B2778.4030601@mabel.info> Message-ID: <200710090830.l998Ut9W034957@dragonsgate2.imagecraft.com> Thomas, can you download and try again? Make sure you uninstall the old one etc. Our team just d/l'ed the .msi from the web and it behaves correctly. Thanks At 12:02 AM 10/9/2007, Thomas Sch?fer wrote: >OK. Plug-In Manager says Version 1,0,0,1, but the problem with the long file >names is still there. >While the build process the compiler generates from a LongFileName.c an >LongFi~1.o file, and afterwards the process fails because 'LongFileName.o' >couldn't opened. > // richard (This email is for mailing lists. To reach me directly, please use richard at imagecraft.com) From schaefer at mabel.info Tue Oct 9 03:27:21 2007 From: schaefer at mabel.info (=?ISO-8859-1?Q?Thomas_Sch=E4fer?=) Date: Tue Oct 9 03:39:15 2007 Subject: [Icc-avr] AVR Studio plugin V1.01 for ICCAVR In-Reply-To: <200710090830.l998Ut9W034957@dragonsgate2.imagecraft.com> References: <200710080919.l989JDqd017618@dragonsgate2.imagecraft.com> <470A3534.7080702@mabel.info> <200710081922.l98JMEfe025954@dragonsgate2.imagecraft.com> <470B2778.4030601@mabel.info> <200710090830.l998Ut9W034957@dragonsgate2.imagecraft.com> Message-ID: <470B5789.7040800@mabel.info> Allright, now I'm in line. Everything works fine. Great! best regards, Thomas Richard schrieb: > Thomas, can you download and try again? Make sure you uninstall the old > one etc. Our team just d/l'ed the .msi from the web and it behaves > correctly. > > Thanks > > At 12:02 AM 10/9/2007, Thomas Sch?fer wrote: >> OK. Plug-In Manager says Version 1,0,0,1, but the problem with the >> long file >> names is still there. >> While the build process the compiler generates from a LongFileName.c an >> LongFi~1.o file, and afterwards the process fails because >> 'LongFileName.o' >> couldn't opened. >> > > // 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 amsol at amssolutions.co.za Tue Oct 9 05:24:14 2007 From: amsol at amssolutions.co.za (AMS Solutions - GJ Laubscher) Date: Tue Oct 9 05:34:31 2007 Subject: [Icc-avr] help : AlphNum Display : LED References: Message-ID: <001401c80a6f$51316b60$0200a8c0@BigFoot> Hi Group, I wish to source/find out on how to design an Alpha-Num LED display unit to display 24? chars. I have access to a std dot-type red led display (5x7dots 50mm) I have, however, never done this type of multiplex design Is there anyone here who can give me some guidelines? or perhaps have a very similar application to share with me? I appreciate your feedback. Regards, Gerhard Laubscher South Africa TeleFax : +27-21-557 0160 Mobile : 082 366 1950 email : amsol@amssolutions.co.za website: http://www.amssolutions.co.za -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20071009/8b63f42a/attachment-0001.html From j_baraclough at zetnet.co.uk Tue Oct 9 06:07:35 2007 From: j_baraclough at zetnet.co.uk (John Baraclough) Date: Tue Oct 9 06:19:52 2007 Subject: [Icc-avr] help : AlphNum Display : LED In-Reply-To: <001401c80a6f$51316b60$0200a8c0@BigFoot> References: <001401c80a6f$51316b60$0200a8c0@BigFoot> Message-ID: Hi Gerhard, A bit OT, but the simplest and fastest to market solution is the MAX7219, used in non-decode mode. It's not going to be the cheapest solution but is very easy to interface. Contact me off-list if for some other links. All the best for now, John At 13:24 09/10/2007, you wrote: >Hi Group, >I wish to source/find out on how to design an Alpha-Num LED display >unit to display 24? chars. I have access to a std dot-type red led >display (5x7dots 50mm) >I have, however, never done this type of multiplex design > >Is there anyone here who can give me some guidelines? or perhaps have a very >similar application to share with me? > >I appreciate your feedback. > >Regards, >Gerhard Laubscher >South Africa > >TeleFax : +27-21-557 0160 Mobile : 082 366 1950 >email : >amsol@amssolutions.co.za website: >http://www.amssolutions.co.za >_______________________________________________ >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/20071009/beeda1ff/attachment.html From paul.aa9gg at gmail.com Tue Oct 9 06:38:21 2007 From: paul.aa9gg at gmail.com (Paul Mateer) Date: Tue Oct 9 06:50:38 2007 Subject: [Icc-avr] app builder feature list In-Reply-To: <04671BB8D269034BBC4BB6BA894867260A81C7@sserver.SabreTechnology.local> References: <04671BB8D269034BBC4BB6BA894867260A81C7@sserver.SabreTechnology.local> Message-ID: <20f5efc40710090638m67e6e353oc975ca1095506a3@mail.gmail.com> This is a good idea!!! Makes it easier to debug too. "I also think that it would be nicer if appbuilder produced its output using the bit names rather than just a hex value, e.g. TCCR0=(1< wrote: > > Michael Dipperstein wrote: > > Richard, > > > > I don't know what kind of information you need, but AVR Studio > > includes XML descriptions in its Partdescriptionfiles subdirectory. > > Maybe they'll help speed things up for you. > > > > This is kind of OT, but does anyone know of an appbuilder type > application which can be used for assembler? > I know you can fire up ICCAVR then convert the C back to asm quite > easily, just wondered if there was anything. > > I also think that it would be nicer if appbuilder produced its output > using the bit names rather than just a hex value, e.g. > TCCR0=(1< to modify the program without having to run appbuilder again. Just my > 0.02 pounds sterling worth. > > -- > Tim Mitchell > tim@sabretechnology.co.uk http://www.sabretechnology.co.uk > Sabre Technology (Hull) Ltd, 3a Newlands Science Park, Hull HU6 7TQ > Registered in England and Wales no.3131504 > t:01482 801003 f:01482 801078 > > _______________________________________________ > Icc-avr mailing list > Icc-avr@imagecraft.com > http://dragonsgate.net/mailman/listinfo/icc-avr > -- Paul Mateer, AA9GG Elan Engineering Corp. www.elanengr.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20071009/9b634fd8/attachment.html From bobgardner at aol.com Tue Oct 9 06:32:16 2007 From: bobgardner at aol.com (bobgardner@aol.com) Date: Tue Oct 9 07:00:31 2007 Subject: [Icc-avr] app builder feature list In-Reply-To: <04671BB8D269034BBC4BB6BA894867260A81C7@sserver.SabreTechnology.local> References: <04671BB8D269034BBC4BB6BA894867260A81C7@sserver.SabreTechnology.local> Message-ID: <8C9D88FF1837D17-E3C-4707@mblk-d35.sysops.aol.com> I also think that it would be nicer if appbuilder produced its output using the bit names rather than just a hex value, e.g. TCCR0=(1< References: <001401c80a6f$51316b60$0200a8c0@BigFoot> Message-ID: <20f5efc40710090712q4902e699i28413fa2285dbafd@mail.gmail.com> We use HP's HDSP-2502 in a lot of our designs. They are only 8 char. but are "stackable" and easy to interface. On 10/9/07, John Baraclough < j_baraclough@zetnet.co.uk> wrote: > > Hi Gerhard, > > A bit OT, but the simplest and fastest to market solution is the MAX7219, > used in non-decode mode. It's not going to be the cheapest solution but is > very easy to interface. > > Contact me off-list if for some other links. > > All the best for now, > John > > > At 13:24 09/10/2007, you wrote: > > Hi Group, > I wish to source/find out on how to design an Alpha-Num LED display > unit to display 24? chars. I have access to a std dot-type red led > display (5x7dots 50mm) > I have, however, never done this type of multiplex design > > Is there anyone here who can give me some guidelines? or perhaps have a > very > similar application to share with me? > > I appreciate your feedback. > > Regards, > Gerhard Laubscher > South Africa > > TeleFax : +27-21-557 0160 Mobile : 082 366 1950 > email : amsol@amssolutions.co.za website: http://www.amssolutions.co.za > _______________________________________________ > Icc-avr mailing list > Icc-avr@imagecraft.com > http://dragonsgate.net/mailman/listinfo/icc-avr > > > _______________________________________________ > Icc-avr mailing list > Icc-avr@imagecraft.com > http://dragonsgate.net/mailman/listinfo/icc-avr > > -- Paul Mateer, AA9GG Elan Engineering Corp. www.elanengr.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20071009/db9873fd/attachment.html From paul.aa9gg at gmail.com Tue Oct 9 13:24:48 2007 From: paul.aa9gg at gmail.com (Paul Mateer) Date: Tue Oct 9 13:37:05 2007 Subject: [Icc-avr] dumb pointer question Message-ID: <20f5efc40710091324l65316ef6s132ced1b552af635@mail.gmail.com> Hello All..... Please tell me what I'm doing wrong here: void Process_Cmd(void) { unsigned char *P_PORT; int w_port, w_pin; w_port = WHICH_PORT & 0xF0; w_pin = WHICH_PORT & 0x0F; if(w_port == 0x10) P_PORT = &PORTA; // PORT A if(w_port == 0x20) P_PORT = &PORTB; // PORT B if(w_port == 0x30) P_PORT = &PORTC; // PORT C if(w_port == 0x40) P_PORT = &PORTD; // PORT D if(w_pin != 8) { if(PORT_CMD == OFF) P_PORT &= ~w_pin; if(PORT_CMD == ON) P_PORT |= w_pin; }else { if(PORT_CMD == OFF) P_PORT = 0; if(PORT_CMD == ON) P_PORT = 0xFF; } } //------------------------------------------------------------------------------------------------ I always seem to stumble when it comes to pointers -- Paul Mateer, AA9GG Elan Engineering Corp. www.elanengr.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20071009/e844f6ac/attachment.html From richard at imagecraft.com Tue Oct 9 13:34:13 2007 From: richard at imagecraft.com (Richard) Date: Tue Oct 9 13:46:50 2007 Subject: [Icc-avr] Sample code for flash CRC Message-ID: <200710092046.l99KknkM043864@dragonsgate2.imagecraft.com> Courtesy of Rodney Pearson of Juniper Systems, a flash CRC routine has been added to the AVR Code Samples page. From the description: This is an ASM code sample that performs CRC generation and validation on Flash memory in Atmel AVR devices. This code is currently written for theM2560, but can be easily tweaked for any AVR device that supports ELPM/SPM. This code is based off of information found on Atmel's website in the AVR Application Note AVR236: CRC Check of Program Memory. Thank you to Rodney for giving back to the community. // richard On-line orders, support, and listservers available on web site. [ For technical support on ImageCraft products, please include all previous replies in your msgs. ] From john at idea-tech.com Tue Oct 9 13:42:17 2007 From: john at idea-tech.com (John Woods) Date: Tue Oct 9 13:54:34 2007 Subject: [Icc-avr] dumb pointer question In-Reply-To: <20f5efc40710091324l65316ef6s132ced1b552af635@mail.gmail.com> References: <20f5efc40710091324l65316ef6s132ced1b552af635@mail.gmail.com> Message-ID: <470BE7A9.10300@idea-tech.com> Hi Paul, You want to use the '*' in front oft he P_PORT when doing accesses so that bit operators work on the port and not the pointer itself. For example: *P_PORT &= ~w_pin; Paul Mateer wrote: > Hello All..... > Please tell me what I'm doing wrong here: > > void Process_Cmd(void) > { > unsigned char *P_PORT; > int w_port, w_pin; > > w_port = WHICH_PORT & 0xF0; > w_pin = WHICH_PORT & 0x0F; > > if(w_port == 0x10) P_PORT = &PORTA; // PORT A > if(w_port == 0x20) P_PORT = &PORTB; // PORT B > if(w_port == 0x30) P_PORT = &PORTC; // PORT C > if(w_port == 0x40) P_PORT = &PORTD; // PORT D > > if(w_pin != 8) > { > if(PORT_CMD == OFF) P_PORT &= ~w_pin; > if(PORT_CMD == ON) P_PORT |= w_pin; > }else > { > if(PORT_CMD == OFF) P_PORT = 0; > if(PORT_CMD == ON) P_PORT = 0xFF; > } > } > > //------------------------------------------------------------------------------------------------ > > I always seem to stumble when it comes to pointers > -- > Paul Mateer, AA9GG > Elan Engineering Corp. > www.elanengr.com > ------------------------------------------------------------------------ > > _______________________________________________ > Icc-avr mailing list > Icc-avr@imagecraft.com > http://dragonsgate.net/mailman/listinfo/icc-avr > -- John Woods Phone: (780) 431 1843 Idea Technologies Inc. Fax: 1 866 293 5883 6746 75 St. Email: john@idea-tech.com Edmonton, Alberta, Web: www.idea-tech.com Canada, T6E 6T9 From richard-lists at imagecraft.com Tue Oct 9 13:44:10 2007 From: richard-lists at imagecraft.com (Richard) Date: Tue Oct 9 13:56:48 2007 Subject: [Icc-avr] app builder feature list In-Reply-To: <8C9D88FF1837D17-E3C-4707@mblk-d35.sysops.aol.com> References: <04671BB8D269034BBC4BB6BA894867260A81C7@sserver.SabreTechnology.local> <8C9D88FF1837D17-E3C-4707@mblk-d35.sysops.aol.com> Message-ID: <200710092056.l99Kulgs044050@dragonsgate2.imagecraft.com> An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20071009/0013c2a1/attachment.html From richard-lists at imagecraft.com Tue Oct 9 13:51:06 2007 From: richard-lists at imagecraft.com (Richard) Date: Tue Oct 9 14:03:51 2007 Subject: [Icc-avr] dumb pointer question In-Reply-To: <20f5efc40710091324l65316ef6s132ced1b552af635@mail.gmail.co m> References: <20f5efc40710091324l65316ef6s132ced1b552af635@mail.gmail.com> Message-ID: <200710092103.l99L3ntS044141@dragonsgate2.imagecraft.com> An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20071009/5253a2da/attachment.html From paul.aa9gg at gmail.com Tue Oct 9 14:04:14 2007 From: paul.aa9gg at gmail.com (Paul Mateer) Date: Tue Oct 9 14:16:32 2007 Subject: [Icc-avr] dumb pointer question In-Reply-To: <470BE7A9.10300@idea-tech.com> References: <20f5efc40710091324l65316ef6s132ced1b552af635@mail.gmail.com> <470BE7A9.10300@idea-tech.com> Message-ID: <20f5efc40710091404s93cc44t1c3997425430706a@mail.gmail.com> thanks...that was it! On 10/9/07, John Woods wrote: > > Hi Paul, > > You want to use the '*' in front oft he P_PORT when doing accesses so > that bit operators work on the port and not the pointer itself. For > example: > > *P_PORT &= ~w_pin; > > Paul Mateer wrote: > > Hello All..... > > Please tell me what I'm doing wrong here: > > > > void Process_Cmd(void) > > { > > unsigned char *P_PORT; > > int w_port, w_pin; > > > > w_port = WHICH_PORT & 0xF0; > > w_pin = WHICH_PORT & 0x0F; > > > > if(w_port == 0x10) P_PORT = &PORTA; // PORT A > > if(w_port == 0x20) P_PORT = &PORTB; // PORT B > > if(w_port == 0x30) P_PORT = &PORTC; // PORT C > > if(w_port == 0x40) P_PORT = &PORTD; // PORT D > > > > if(w_pin != 8) > > { > > if(PORT_CMD == OFF) P_PORT &= ~w_pin; > > if(PORT_CMD == ON) P_PORT |= w_pin; > > }else > > { > > if(PORT_CMD == OFF) P_PORT = 0; > > if(PORT_CMD == ON) P_PORT = 0xFF; > > } > > } > > > > > //------------------------------------------------------------------------------------------------ > > > > I always seem to stumble when it comes to pointers > > -- > > Paul Mateer, AA9GG > > Elan Engineering Corp. > > www.elanengr.com > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > Icc-avr mailing list > > Icc-avr@imagecraft.com > > http://dragonsgate.net/mailman/listinfo/icc-avr > > > > -- > John Woods Phone: (780) 431 1843 > Idea Technologies Inc. Fax: 1 866 293 5883 > 6746 75 St. Email: john@idea-tech.com > Edmonton, Alberta, Web: www.idea-tech.com > Canada, T6E 6T9 > > _______________________________________________ > 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/20071009/855cb3f8/attachment.html From DRaymond at Bankspower.com Tue Oct 9 14:07:52 2007 From: DRaymond at Bankspower.com (David Raymond) Date: Tue Oct 9 14:20:07 2007 Subject: [Icc-avr] app builder feature list In-Reply-To: <200710092056.l99Kulgs044050@dragonsgate2.imagecraft.com> References: <04671BB8D269034BBC4BB6BA894867260A81C7@sserver.SabreTechnology.local><8C9D88FF1837D17-E3C-4707@mblk-d35.sysops.aol.com> <200710092056.l99Kulgs044050@dragonsgate2.imagecraft.com> Message-ID: <0E755D4F91B6D344B39791054F52A2A901220963@gbexchange.bankspower.local> Bit names should include named pins (from the application builder itself) when applied to PORT or PIN registers. Dave Raymond Software Engineer Gale Banks Engineering Ph (626) 969-9600 x3301 Fx (626) 334-2376 Visit us on the Web: www.bankspower.com E-mail: draymond@bankspower.com ________________________________ From: icc-avr-bounces@imagecraft.com [mailto:icc-avr-bounces@imagecraft.com] On Behalf Of Richard Sent: Tuesday, October 09, 2007 1:44 PM To: Discussion list for ICCAVR and ICCtiny Users. You do NOT need tosubscribe to icc-announce if you are a member of this. Subject: Re: [Icc-avr] app builder feature list I will have the dev team look into this. Sounds like a good idea. At 06:32 AM 10/9/2007, you wrote: I also think that it would be nicer if appbuilder produced its output using the bit names rather than just a hex value, e.g. TCCR0=(1< <004601c8097d$f551cd40$b160ec82@Shagrat> Message-ID: Problem with zip actually was not on my, but on my provider's side. Should be solved now. Best regards, Johannes > Yes, the zip does not work. Sorry. I will fix it. > The "NE 0" and "EQ 0" are templates that you can edit for your own. Just search > your iccv7avr installation for "mpdAVR.areainfo" and see. > Btw: There is another template file "mpdAVR.switches" noteworthy, too... > Best regards, > Johannes >> Hi. >> The ZIP didn't work but the exe did. >> Looks great but there is a NE 0 last at this line: >> SRAM area "data" with global and static variables initialised NE 0 >> Also EQ 0: >> SRAM area "bss" with global and static variables initialised EQ 0 >> Great with the informatic text. Good job! >> Best regards, >> Bengt >>> -----Ursprungligt meddelande----- >>> Fr?n: icc-avr-bounces@imagecraft.com [mailto:icc-avr- >>> bounces@imagecraft.com] F?r Johannes Assenbaum >>> Skickat: den 5 oktober 2007 21:10 >>> Till: icc-avr@imagecraft.com >>> ?mne: [Icc-avr] New Map File Summary >>> >>> Hi all, >>> >>> you may like to beta-test latest Map File Summary. >>> >>> In file mpdAVR.switches you'll find new options including sorted output, >>> that are not supported by ide yet and maybe never will. >>> >>> Download updater as an exe >>> http://avr.jassenbaum.de/iccv7avr/files/ICCV7AVR_mpdAVR.dll_update.exe >>> or zipped >>> http://avr.jassenbaum.de/iccv7avr/files/ICCV7AVR_mpdAVR.dll_update.zip >>> >>> Best regards, >>> Johannes >>> >>> _______________________________________________ >>> 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 Free Edition. >> Version: 7.5.488 / Virus Database: 269.14.4/1057 - Release Date: 08.10.07 09:04 > -- > No virus found in this incoming message. > Checked by AVG Free Edition. > Version: 7.5.488 / Virus Database: 269.14.4/1057 - Release Date: 08.10.07 09:04 From rohde at aragon-interactive.de Tue Oct 16 04:28:22 2007 From: rohde at aragon-interactive.de (Roman Rohde) Date: Tue Oct 16 04:47:33 2007 Subject: [Icc-avr] CRC Check of Program Memory In-Reply-To: References: Message-ID: > 1. How do I loop through the program memory? // Project -> Options... -> Target -> Other Options: // -bbootsect:0x07000.0x08000 for BOOTSIZE 2048words @ 0x3800 * // -bbootsect:0x07800.0x08000 for BOOTSIZE 1024words @ 0x3C00 // -bbootsect:0x07C00.0x08000 for BOOTSIZE 512words @ 0x3E00 // -bbootsect:0x07E00.0x08000 for BOOTSIZE 256words @ 0x3F00 #pragma text:bootsect(abs) void boot(void) { const unsigned int * root; register unsigned int sum; register unsigned int tmp; asm(".include \"aiom32.s\""); asm("wdr"); asm("cli"); // init PORTs PORTD = 0x9F; DDRD = 0xFB; PORTB = DDRB = PORTC = DDRC = PORTA = DDRA = 0xFF; SFIOR = 0x00; // SFIOR &= ~(1<RAMEND"); asm("out SPH,r16"); asm("ldi r16, 2. How do I store the correct CRC at the end of the Flash memory? // Project -> Options... -> Target -> Other Options: // -bchecksum:0x04FFE.0x05000 for 2 Byte checksum #pragma text:checksum(abs) asm(".word 0x753A"); #pragma text:text From benra at imt.liu.se Mon Oct 22 01:17:25 2007 From: benra at imt.liu.se (Bengt Ragnemalm) Date: Mon Oct 22 01:29:54 2007 Subject: [Icc-avr] Freeing static variables Message-ID: <002f01c81483$fa562500$b160ec82@Shagrat> Is there any intelligent way to release the memory used by a static variable? I have a calibration routine that is run the first loops of the program. If the calibration was done in a separate function , I could just use temporary variables but as this is run in the entire normal program loop I can not see any other way than to use statics for my temporary variables in the calibration routine. But after the calibrating is done, it would have been nice to free the space used by the static variables. Maybe there is some better way to do this so any suggestions are welcome. Regards, Bengt ________________________________________________________________ Bengt Ragnemalm Tel +46 13 22 24 97 Research engineer FAX: +46 13 10 19 02 Link?pings Universitet mailto:bengt.ragnemalm@imt.liu.se Inst. f?r Medicinsk Teknik Internet: http://www.imt.liu.se S-581 85 Link?ping SWEDEN -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20071022/6d363f1a/attachment.html From david_brown at hotpop.com Mon Oct 22 02:26:51 2007 From: david_brown at hotpop.com (David Brown) Date: Mon Oct 22 02:08:48 2007 Subject: [Icc-avr] Freeing static variables In-Reply-To: <002f01c81483$fa562500$b160ec82@Shagrat> References: <002f01c81483$fa562500$b160ec82@Shagrat> Message-ID: <471C6CDB.4090909@hotpop.com> By their very definition, "static" variables are allocated a fixed address in memory by the linker, and cannot be "freed". You have to figure out why you might want to re-use the space they take - if you are using heap-allocated dynamic memory (a terrible idea on most embedded systems!), for example, then you could use malloc and free for the calibration data. If you need it for other specific purposes after calibration, you could do something like define a union containing a calibration data structure and a run-time data structure, as long as you are careful to track which one is valid. mvh., David Bengt Ragnemalm wrote: > Is there any intelligent way to release the memory used by a static > variable? > > > > I have a calibration routine that is run the first loops of the program. > If the calibration was done in a separate function , I could just use > temporary variables but as this is run in the entire normal program loop > I can not see any other way than to use statics for my temporary > variables in the calibration routine. > > > > But after the calibrating is done, it would have been nice to free the > space used by the static variables. > > > > Maybe there is some better way to do this so any suggestions are welcome. > > > > Regards, > > Bengt > From benra at imt.liu.se Mon Oct 22 02:38:53 2007 From: benra at imt.liu.se (Bengt Ragnemalm) Date: Mon Oct 22 02:51:16 2007 Subject: SV: [Icc-avr] Freeing static variables In-Reply-To: <471C6CDB.4090909@hotpop.com> References: <002f01c81483$fa562500$b160ec82@Shagrat> <471C6CDB.4090909@hotpop.com> Message-ID: <004301c8148f$5c27f320$b160ec82@Shagrat> The purpose is just to use less RAM. My problem is that I must run this during the normal execution of the full program and not just prior starting. I can see several solutions to this but none that I can call well written code. Would malloc even work in ICCAVR? I have no idea how it works but I am aware of the function. /Bengt > -----Ursprungligt meddelande----- > Fr?n: icc-avr-bounces@imagecraft.com [mailto:icc-avr- > bounces@imagecraft.com] F?r David Brown > Skickat: den 22 oktober 2007 11:27 > Till: Discussion list for ICCAVR and ICCtiny Users. You do NOT need > tosubscribe to icc-announce if you are a member of this. > ?mne: Re: [Icc-avr] Freeing static variables > > > By their very definition, "static" variables are allocated a fixed > address in memory by the linker, and cannot be "freed". You have to > figure out why you might want to re-use the space they take - if you are > using heap-allocated dynamic memory (a terrible idea on most embedded > systems!), for example, then you could use malloc and free for the > calibration data. If you need it for other specific purposes after > calibration, you could do something like define a union containing a > calibration data structure and a run-time data structure, as long as you > are careful to track which one is valid. > > mvh., > > David > > > Bengt Ragnemalm wrote: > > Is there any intelligent way to release the memory used by a static > > variable? > > > > > > > > I have a calibration routine that is run the first loops of the program. > > If the calibration was done in a separate function , I could just use > > temporary variables but as this is run in the entire normal program loop > > I can not see any other way than to use statics for my temporary > > variables in the calibration routine. > > > > > > > > But after the calibrating is done, it would have been nice to free the > > space used by the static variables. > > > > > > > > Maybe there is some better way to do this so any suggestions are > welcome. > > > > > > > > Regards, > > > > Bengt > > > > > _______________________________________________ > Icc-avr mailing list > Icc-avr@imagecraft.com > http://dragonsgate.net/mailman/listinfo/icc-avr From richard-lists at imagecraft.com Mon Oct 22 03:15:28 2007 From: richard-lists at imagecraft.com (Richard) Date: Mon Oct 22 03:27:55 2007 Subject: SV: [Icc-avr] Freeing static variables In-Reply-To: <004301c8148f$5c27f320$b160ec82@Shagrat> References: <002f01c81483$fa562500$b160ec82@Shagrat> <471C6CDB.4090909@hotpop.com> <004301c8148f$5c27f320$b160ec82@Shagrat> Message-ID: <200710221027.l9MARrXI090039@dragonsgate2.imagecraft.com> If you really must. Don't blame me if your program gets non-readable: In a .s file, .area bss _name1:: _name2:: ... .blkb 2 now in C, extern unsigned name1, name2; Both will have the same address. Yes, malloc does work At 02:38 AM 10/22/2007, Bengt Ragnemalm wrote: >The purpose is just to use less RAM. My problem is that I must run this >during the normal execution of the full program and not just prior starting. > >I can see several solutions to this but none that I can call well written >code. > >Would malloc even work in ICCAVR? I have no idea how it works but I am aware >of the function. > >/Bengt > > > -----Ursprungligt meddelande----- > > Fr?n: icc-avr-bounces@imagecraft.com [mailto:icc-avr- > > bounces@imagecraft.com] F?r David Brown > > Skickat: den 22 oktober 2007 11:27 > > Till: Discussion list for ICCAVR and ICCtiny Users. You do NOT need > > tosubscribe to icc-announce if you are a member of this. > > ?mne: Re: [Icc-avr] Freeing static variables > > > > > > By their very definition, "static" variables are allocated a fixed > > address in memory by the linker, and cannot be "freed". You have to > > figure out why you might want to re-use the space they take - if you are > > using heap-allocated dynamic memory (a terrible idea on most embedded > > systems!), for example, then you could use malloc and free for the > > calibration data. If you need it for other specific purposes after > > calibration, you could do something like define a union containing a > > calibration data structure and a run-time data structure, as long as you > > are careful to track which one is valid. > > > > mvh., > > > > David > > > > > > Bengt Ragnemalm wrote: > > > Is there any intelligent way to release the memory used by a static > > > variable? > > > > > > > > > > > > I have a calibration routine that is run the first loops of the program. > > > If the calibration was done in a separate function , I could just use > > > temporary variables but as this is run in the entire normal program loop > > > I can not see any other way than to use statics for my temporary > > > variables in the calibration routine. > > > > > > > > > > > > But after the calibrating is done, it would have been nice to free the > > > space used by the static variables. > > > > > > > > > > > > Maybe there is some better way to do this so any suggestions are > > welcome. > > > > > > > > > > > > Regards, > > > > > > Bengt // richard (This email is for mailing lists. To reach me directly, please use richard at imagecraft.com) From david_brown at hotpop.com Mon Oct 22 13:17:44 2007 From: david_brown at hotpop.com (David Brown) Date: Mon Oct 22 13:32:42 2007 Subject: SV: [Icc-avr] Freeing static variables In-Reply-To: <200710221027.l9MARrXI090039@dragonsgate2.imagecraft.com> References: <002f01c81483$fa562500$b160ec82@Shagrat> <471C6CDB.4090909@hotpop.com> <004301c8148f$5c27f320$b160ec82@Shagrat> <200710221027.l9MARrXI090039@dragonsgate2.imagecraft.com> Message-ID: <471D0568.4000401@hotpop.com> Richard wrote: > If you really must. Don't blame me if your program gets non-readable: > > In a .s file, > .area bss > _name1:: > _name2:: > ... > .blkb 2 > > > now in C, > extern unsigned name1, name2; > It would be safer and more readable (or at least less unreadable!) to use a union - sharing memory is one of the reasons it exists. If it makes your code hard to read because your variables are now part of a union of structures, you can use #define to give short names. Thus instead of an int called "calibrationCount", you have a union: union { struct { int calibrationCount_; // ... } calData; struct { ... } runData; } shared; with access as shared.calData.calibrationCount_, or with #define calibrationCount shared.calData.calibrationCount and access as before. #define names can also be used to give a single variable two completely different names, so that your code can look normal, but share the data space. They can also be used with typecasts to share data with different types: int calibrationCount; #define runByteA (*((unsigned char*) &calibrationCount)) #define runByteB (*(((unsigned char*) &calibrationCount) + 1)) Of course, you code gets a bit messy, and it's hard to debug or to inspect the generated assembly. And yes, malloc will work (or should - I've never used it with iccavr). But it's seldom advisable to use dynamic memory on a small micro in an embedded system - only use it if it is the least bad solution to your problem. mvh., David > Both will have the same address. > > Yes, malloc does work > > At 02:38 AM 10/22/2007, Bengt Ragnemalm wrote: >> The purpose is just to use less RAM. My problem is that I must run this >> during the normal execution of the full program and not just prior >> starting. >> >> I can see several solutions to this but none that I can call well written >> code. >> >> Would malloc even work in ICCAVR? I have no idea how it works but I am >> aware >> of the function. >> >> /Bengt >> >> > -----Ursprungligt meddelande----- >> > Fr?n: icc-avr-bounces@imagecraft.com [mailto:icc-avr- >> > bounces@imagecraft.com] F?r David Brown >> > Skickat: den 22 oktober 2007 11:27 >> > Till: Discussion list for ICCAVR and ICCtiny Users. You do NOT need >> > tosubscribe to icc-announce if you are a member of this. >> > ?mne: Re: [Icc-avr] Freeing static variables >> > >> > >> > By their very definition, "static" variables are allocated a fixed >> > address in memory by the linker, and cannot be "freed". You have to >> > figure out why you might want to re-use the space they take - if you >> are >> > using heap-allocated dynamic memory (a terrible idea on most embedded >> > systems!), for example, then you could use malloc and free for the >> > calibration data. If you need it for other specific purposes after >> > calibration, you could do something like define a union containing a >> > calibration data structure and a run-time data structure, as long as >> you >> > are careful to track which one is valid. >> > >> > mvh., >> > >> > David >> > >> > >> > Bengt Ragnemalm wrote: >> > > Is there any intelligent way to release the memory used by a static >> > > variable? >> > > >> > > >> > > >> > > I have a calibration routine that is run the first loops of the >> program. >> > > If the calibration was done in a separate function , I could just use >> > > temporary variables but as this is run in the entire normal >> program loop >> > > I can not see any other way than to use statics for my temporary >> > > variables in the calibration routine. >> > > >> > > >> > > >> > > But after the calibrating is done, it would have been nice to free >> the >> > > space used by the static variables. >> > > >> > > >> > > >> > > Maybe there is some better way to do this so any suggestions are >> > welcome. >> > > >> > > >> > > >> > > Regards, >> > > >> > > Bengt > > // richard (This email is for mailing lists. To reach me directly, > please use richard at imagecraft.com) > > _______________________________________________ From MDipperstein at CalAmp.com Mon Oct 22 13:21:59 2007 From: MDipperstein at CalAmp.com (Michael Dipperstein) Date: Mon Oct 22 13:34:34 2007 Subject: [Icc-avr] Freeing static variables In-Reply-To: <002f01c81483$fa562500$b160ec82@Shagrat> Message-ID: Can you reuse the space instead of releasing it? If you have the need for two static variables that can share the same memory location, you can just use it for two purposes. You can use #defines if you'd like it to look like you're using two different variables. #define calibrationVar staticVar #define otherVar staticVar static int staticVar; -----Original Message----- From: icc-avr-bounces@imagecraft.com [mailto:icc-avr-bounces@imagecraft.com] On Behalf Of Bengt Ragnemalm Sent: Monday, October 22, 2007 1:17 AM To: ICC-AVR discussion list Subject: [Icc-avr] Freeing static variables Is there any intelligent way to release the memory used by a static variable? I have a calibration routine that is run the first loops of the program. If the calibration was done in a separate function , I could just use temporary variables but as this is run in the entire normal program loop I can not see any other way than to use statics for my temporary variables in the calibration routine. But after the calibrating is done, it would have been nice to free the space used by the static variables. Maybe there is some better way to do this so any suggestions are welcome. Regards, Bengt ________________________________________________________________ Bengt Ragnemalm Tel +46 13 22 24 97 Research engineer FAX: +46 13 10 19 02 Link?pings Universitet mailto:bengt.ragnemalm@imt.liu.se Inst. f?r Medicinsk Teknik Internet: http://www.imt.liu.se S-581 85 Link?ping SWEDEN -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20071022/beb86227/attachment.html From benra at imt.liu.se Wed Oct 24 01:30:25 2007 From: benra at imt.liu.se (Bengt Ragnemalm) Date: Wed Oct 24 01:42:53 2007 Subject: [Icc-avr] Module globals static? Message-ID: <002101c81618$20928ac0$b160ec82@Shagrat> Is a variable that is global in a module also automatically static? I think it is but if so, shouldn?t the strictly most correct way to define the globals also be as static? Thanks for all suggestions about the freeing static variables. /Bengt ________________________________________________________________ Bengt Ragnemalm Tel +46 13 22 24 97 Research engineer FAX: +46 13 10 19 02 Link?pings Universitet mailto:bengt.ragnemalm@imt.liu.se Inst. f?r Medicinsk Teknik Internet: http://www.imt.liu.se S-581 85 Link?ping SWEDEN -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20071024/92a54532/attachment.html From david_brown at hotpop.com Wed Oct 24 02:45:23 2007 From: david_brown at hotpop.com (David Brown) Date: Wed Oct 24 02:27:00 2007 Subject: [Icc-avr] Module globals static? In-Reply-To: <002101c81618$20928ac0$b160ec82@Shagrat> References: <002101c81618$20928ac