From BobGardner at aol.com Sat Dec 1 09:53:23 2007 From: BobGardner at aol.com (BobGardner@aol.com) Date: Sat Dec 1 10:07:00 2007 Subject: [Icc-avr] Whats in the mystery 40 bytes in ram? Message-ID: If I declare 'char junk;' as the first global var, it shows up in the map as 41 bytes. If I look in that area of ram, I guess it looks like some sort of ascii numbers with the residue of the last floating point printf the program printed out. I think if someone is unfortunate enough to trash this area due to a programming mistake, it causes weird stuff to happen. Maybe we could give it a label like 'printfbuffer' so folks could stay away from it? I really like Johannes' detailed map summary. Other items: can I make __flash a hilite in the editor? What do you folks think about the utility of a pragma to turn on and off expression eval using single or double floats? Would be useful in certain critical sections that needed hi precision, like NMEA lat/long calcs, could be turned off elsewhere. If you think this is a good idea, we should talk it up so it will get added...... **************************************Check out AOL's list of 2007's hottest products. (http://money.aol.com/special/hot-products-2007?NCID=aoltop00030000000001) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20071201/c4496b73/attachment.html From richard-lists at imagecraft.com Sat Dec 1 11:16:26 2007 From: richard-lists at imagecraft.com (Richard) Date: Sat Dec 1 11:30:35 2007 Subject: [Icc-avr] Whats in the mystery 40 bytes in ram? In-Reply-To: References: Message-ID: <200712011930.lB1JUYsR044858@dragonsgate2.imagecraft.com> An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20071201/d3737ea1/attachment.html From andrew_166 at msn.com Sat Dec 1 12:24:33 2007 From: andrew_166 at msn.com (Andrew) Date: Sat Dec 1 12:36:02 2007 Subject: [Icc-avr] AT90USB162 References: <200712011930.lB1JUYsR044858@dragonsgate2.imagecraft.com> Message-ID: Hi, Is there any working code compatible with the imagecraft compiler for the new USB devices from Atmel specifically the AT90USB162? If so where can i find them? All i need to do is make the USB turn up as a virtual serial port in windows and then be able to program the USB like the UARTS under ICCAVR. Many Thanks, NOTE is imagecraft going to make this part of the application builder process anytime soon? Andrew ----- Original Message ----- From: Richard To: 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 Sent: Saturday, December 01, 2007 7:16 PM Subject: Re: [Icc-avr] Whats in the mystery 40 bytes in ram? At 09:53 AM 12/1/2007, BobGardner@aol.com wrote: If I declare 'char junk;' as the first global var, it shows up in the map as 41 bytes. If I look in that area of ram, I guess it looks like some sort of ascii numbers with the residue of the last floating point printf the program printed out. I think if someone is unfortunate enough to trash this area due to a programming mistake, it causes weird stuff to happen. Maybe we could give it a label like 'printfbuffer' so folks could stay away from it? I really like Johannes' detailed map summary. Other items: can I make __flash a hilite in the editor? What do you folks think about the utility of a pragma to turn on and off expression eval using single or double floats? Would be useful in certain critical sections that needed hi precision, like NMEA lat/long calcs, could be turned off elsewhere. If you think this is a good idea, we should talk it up so it will get added...... Those 40 bytes (were) from the library, basically error msgs. They have been moved to flash only since 7,14 or may ve even 7,.13 // richard (This email is for mailing lists. To reach me directly, please use richard at imagecraft.com) ------------------------------------------------------------------------------ _______________________________________________ Icc-avr mailing list Icc-avr@imagecraft.com http://dragonsgate.net/mailman/listinfo/icc-avr -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20071201/22e594c9/attachment.html From jwbacon at comcast.net Sat Dec 1 13:42:34 2007 From: jwbacon at comcast.net (Jim Bacon) Date: Sat Dec 1 13:56:03 2007 Subject: [Icc-avr] AT90USB162 In-Reply-To: References: <200712011930.lB1JUYsR044858@dragonsgate2.imagecraft.com> Message-ID: <200712012156.lB1Lu0oN046273@dragonsgate2.imagecraft.com> Wouldn't this be easier? http://www.ftdichip.com/ At 01:24 PM 12/1/2007, you wrote: >Hi, >Is there any working code compatible with the imagecraft compiler >for the new USB devices from Atmel specifically the AT90USB162? >If so where can i find them? > >All i need to do is make the USB turn up as a virtual serial port in >windows and then be able to program the USB like the UARTS under ICCAVR. >Many Thanks, > >NOTE is imagecraft going to make this part of the application >builder process anytime soon? > > * Glory is fleeting, but obscurity is forever. * ***************************************************************** Jim Bacon jwbacon@comcast.net 303-666-9455 (H) http://adams22.homeip.net jbacon@mellesgriot.com (W) 720-494-4938 ext 329 (W) ... 720-494-9432 (FAX) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20071201/86e2682f/attachment.html From BobGardner at aol.com Sat Dec 1 14:22:56 2007 From: BobGardner at aol.com (BobGardner@aol.com) Date: Sat Dec 1 14:36:43 2007 Subject: [Icc-avr] Whats in the mystery 40 bytes in ram? Message-ID: But I'm running 7.15 pro... supposedly the latest and greatest? In a message dated 12/1/2007 2:21:59 P.M. Eastern Standard Time, richard-lists@imagecraft.com writes: At 09:53 AM 12/1/2007, BobGardner@aol.com wrote: If I declare 'char junk;' as the first global var, it shows up in the map as 41 bytes. If I look in that area of ram, I guess it looks like some sort of ascii numbers with the residue of the last floating point printf the program printed out. I think if someone is unfortunate enough to trash this area due to a programming mistake, it causes weird stuff to happen. Maybe we could give it a label like 'printfbuffer' so folks could stay away from it? I really like Johannes' detailed map summary. Other items: can I make __flash a hilite in the editor? What do you folks think about the utility of a pragma to turn on and off expression eval using single or double floats? Would be useful in certain critical sections that needed hi precision, like NMEA lat/long calcs, could be turned off elsewhere. If you think this is a good idea, we should talk it up so it will get added...... Those 40 bytes (were) from the library, basically error msgs. They have been moved to flash only since 7,14 or may ve even 7,.13 // 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 **************************************Check out AOL's list of 2007's hottest products. (http://money.aol.com/special/hot-products-2007?NCID=aoltop00030000000001) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20071201/2bd1fd19/attachment.html From richard-lists at imagecraft.com Sat Dec 1 18:49:36 2007 From: richard-lists at imagecraft.com (Richard) Date: Sat Dec 1 19:23:23 2007 Subject: [Icc-avr] Whats in the mystery 40 bytes in ram? In-Reply-To: References: Message-ID: <200712020323.lB23NMpa048637@dragonsgate2.imagecraft.com> An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20071201/611ae058/attachment.html From andrew_166 at msn.com Sun Dec 2 09:16:10 2007 From: andrew_166 at msn.com (Andrew Hill) Date: Sun Dec 2 09:30:01 2007 Subject: [Icc-avr] AT90USB162 In-Reply-To: <200712012156.lB1Lu0oN046273@dragonsgate2.imagecraft.com> References: <200712011930.lB1JUYsR044858@dragonsgate2.imagecraft.com> <200712012156.lB1Lu0oN046273@dragonsgate2.imagecraft.com> Message-ID: HI, No the FTDI chip is to expensive. and the board must be small so i have to use the USB AVR Andy Date: Sat, 1 Dec 2007 14:42:34 -0700To: icc-avr@imagecraft.comFrom: jwbacon@comcast.netSubject: Re: [Icc-avr] AT90USB162Wouldn't this be easier? http://www.ftdichip.com/At 01:24 PM 12/1/2007, you wrote: Hi,Is there any working code compatible with the imagecraft compiler for the new USB devices from Atmel specifically the AT90USB162?If so where can i find them?All i need to do is make the USB turn up as a virtual serial port in windows and then be able to program the USB like the UARTS under ICCAVR.Many Thanks,NOTE is imagecraft going to make this part of the application builder process anytime soon? * Glory is fleeting, but obscurity is forever. ******************************************************************Jim Baconjwbacon@comcast.net303-666-9455 (H)http://adams22.homeip.netjbacon@mellesgriot.com (W)720-494-4938 ext 329 (W) ... 720-494-9432 (FAX) _________________________________________________________________ Who's friends with who and co-starred in what? http://www.searchgamesbox.com/celebrityseparation.shtml -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20071202/4ca84efa/attachment-0001.html From Albert.vanVeen at pertronic.co.nz Sun Dec 2 11:10:51 2007 From: Albert.vanVeen at pertronic.co.nz (Albert vanVeen) Date: Sun Dec 2 11:24:27 2007 Subject: [Icc-avr] Variables declared in main() and the stack In-Reply-To: References: <474F2653.6070603@hotpop.com> Message-ID: I'm sorry to people who started thinking about Fibernacci's solution. It was just a retoric question to show how some problems 'naturally' call for a recursive function. And yes, it is probably true that the typical use of these functions is in programming courses. Something you might come across in real life could be faculties. And of course there are other methods. Albert. -----Original Message----- From: icc-avr-bounces@imagecraft.com [mailto:icc-avr-bounces@imagecraft.com] On Behalf Of John Baraclough Sent: Saturday, December 01, 2007 01:29 AM To: Discussion list for ICCAVR and ICCtiny Users. You do NOT need tosubscribe to icc-announce if you are a member of this. Subject: RE: [Icc-avr] Variables declared in main() and the stack At 21:26 29/11/2007, you wrote: >How do you solve Fibernacci without recursion? I really have to ask why, on a typical AVR (or indeed any other 8-bit) based embedded system you would want to do that? Surely a limited set of pre calculated values in a look-up table is the best method. John _______________________________________________ Icc-avr mailing list Icc-avr@imagecraft.com http://dragonsgate.net/mailman/listinfo/icc-avr Scanned by Bizo Email Filter From mark at extron.com.au Sun Dec 2 14:21:13 2007 From: mark at extron.com.au (Mark Barber) Date: Sun Dec 2 14:34:54 2007 Subject: [Icc-avr] AT90USB162 In-Reply-To: References: <200712011930.lB1JUYsR044858@dragonsgate2.imagecraft.com> Message-ID: <029701c83531$a82f4940$6701a8c0@mark> Andrew, There is some good demo code from Atmel on the UART implementation using the 162. It is not ICC but the conversion for their demo code only takes a few hours. It is no a bad processor nad with the USB code working the device is only 40% full. Regards Mark ********************************** Mark Barber Extron Technologies Pty. Ltd. www.extron.com.au Ph: 613-9761-8166 Fx: 613-9761-8177 ********************************** _____ From: icc-avr-bounces@imagecraft.com [mailto:icc-avr-bounces@imagecraft.com] On Behalf Of Andrew Sent: Sunday, 2 December 2007 7:25 AM To: Discussion list for ICCAVR and ICCtiny Users. You do NOT needtosubscribeto icc-announce if you are a member of this. Subject: [Icc-avr] AT90USB162 Hi, Is there any working code compatible with the imagecraft compiler for the new USB devices from Atmel specifically the AT90USB162? If so where can i find them? All i need to do is make the USB turn up as a virtual serial port in windows and then be able to program the USB like the UARTS under ICCAVR. Many Thanks, NOTE is imagecraft going to make this part of the application builder process anytime soon? Andrew ----- Original Message ----- From: Richard To: 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 Sent: Saturday, December 01, 2007 7:16 PM Subject: Re: [Icc-avr] Whats in the mystery 40 bytes in ram? At 09:53 AM 12/1/2007, BobGardner@aol.com wrote: If I declare 'char junk;' as the first global var, it shows up in the map as 41 bytes. If I look in that area of ram, I guess it looks like some sort of ascii numbers with the residue of the last floating point printf the program printed out. I think if someone is unfortunate enough to trash this area due to a programming mistake, it causes weird stuff to happen. Maybe we could give it a label like 'printfbuffer' so folks could stay away from it? I really like Johannes' detailed map summary. Other items: can I make __flash a hilite in the editor? What do you folks think about the utility of a pragma to turn on and off expression eval using single or double floats? Would be useful in certain critical sections that needed hi precision, like NMEA lat/long calcs, could be turned off elsewhere. If you think this is a good idea, we should talk it up so it will get added...... Those 40 bytes (were) from the library, basically error msgs. They have been moved to flash only since 7,14 or may ve even 7,.13 // richard (This email is for mailing lists. To reach me directly, please use richard at imagecraft.com) _____ _______________________________________________ Icc-avr mailing list Icc-avr@imagecraft.com http://dragonsgate.net/mailman/listinfo/icc-avr -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20071203/59d4f7a9/attachment.html From andrew_166 at msn.com Sun Dec 2 15:42:40 2007 From: andrew_166 at msn.com (Andrew) Date: Sun Dec 2 15:56:15 2007 Subject: [Icc-avr] AT90USB162 References: <200712011930.lB1JUYsR044858@dragonsgate2.imagecraft.com> <029701c83531$a82f4940$6701a8c0@mark> Message-ID: Hi, Thansk for you help it may take me a few more 1hrs to convert it as i am completly new to AVR's and the ICCAVR compiler. Maybe even days/weeks so if any kind soul has some code working can the please point me in the correct general direction Andy ----- Original Message ----- From: Mark Barber To: 'Discussion list for ICCAVR and ICCtiny Users. You do NOT needtosubscribeto icc-announce if you are a member of this.' Sent: Sunday, December 02, 2007 10:21 PM Subject: RE: [Icc-avr] AT90USB162 Andrew, There is some good demo code from Atmel on the UART implementation using the 162. It is not ICC but the conversion for their demo code only takes a few hours. It is no a bad processor nad with the USB code working the device is only 40% full. Regards Mark ********************************** Mark Barber Extron Technologies Pty. Ltd. www.extron.com.au Ph: 613-9761-8166 Fx: 613-9761-8177 ********************************** ------------------------------------------------------------------------------ From: icc-avr-bounces@imagecraft.com [mailto:icc-avr-bounces@imagecraft.com] On Behalf Of Andrew Sent: Sunday, 2 December 2007 7:25 AM To: Discussion list for ICCAVR and ICCtiny Users. You do NOT needtosubscribeto icc-announce if you are a member of this. Subject: [Icc-avr] AT90USB162 Hi, Is there any working code compatible with the imagecraft compiler for the new USB devices from Atmel specifically the AT90USB162? If so where can i find them? All i need to do is make the USB turn up as a virtual serial port in windows and then be able to program the USB like the UARTS under ICCAVR. Many Thanks, NOTE is imagecraft going to make this part of the application builder process anytime soon? Andrew ----- Original Message ----- From: Richard To: 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 Sent: Saturday, December 01, 2007 7:16 PM Subject: Re: [Icc-avr] Whats in the mystery 40 bytes in ram? At 09:53 AM 12/1/2007, BobGardner@aol.com wrote: If I declare 'char junk;' as the first global var, it shows up in the map as 41 bytes. If I look in that area of ram, I guess it looks like some sort of ascii numbers with the residue of the last floating point printf the program printed out. I think if someone is unfortunate enough to trash this area due to a programming mistake, it causes weird stuff to happen. Maybe we could give it a label like 'printfbuffer' so folks could stay away from it? I really like Johannes' detailed map summary. Other items: can I make __flash a hilite in the editor? What do you folks think about the utility of a pragma to turn on and off expression eval using single or double floats? Would be useful in certain critical sections that needed hi precision, like NMEA lat/long calcs, could be turned off elsewhere. If you think this is a good idea, we should talk it up so it will get added...... Those 40 bytes (were) from the library, basically error msgs. They have been moved to flash only since 7,14 or may ve even 7,.13 // 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20071202/ff54fc11/attachment-0001.html From mark at extron.com.au Sun Dec 2 16:18:43 2007 From: mark at extron.com.au (Mark Barber) Date: Sun Dec 2 16:32:27 2007 Subject: [Icc-avr] AT90USB162 In-Reply-To: References: <200712011930.lB1JUYsR044858@dragonsgate2.imagecraft.com> <029701c83531$a82f4940$6701a8c0@mark> Message-ID: <02ba01c83542$10a06580$6701a8c0@mark> Andy, Understand, I will take my working code and pull my project specific code out and email you the basic working USB ICC skeleton. Will try to do it tonight. Regards Mark ********************************** Mark Barber Extron Technologies Pty. Ltd. www.extron.com.au Ph: 613-9761-8166 Fx: 613-9761-8177 ********************************** _____ From: Andrew [mailto:andrew_166@msn.com] Sent: Monday, 3 December 2007 10:43 AM To: mark@extron.com.au; Discussion list for ICCAVR and ICCtiny Users. You do NOT need tosubscribeto icc-announce if you are a member of this. Subject: Re: [Icc-avr] AT90USB162 Hi, Thansk for you help it may take me a few more 1hrs to convert it as i am completly new to AVR's and the ICCAVR compiler. Maybe even days/weeks so if any kind soul has some code working can the please point me in the correct general direction Andy ----- Original Message ----- From: Mark Barber To: 'Discussion list for ICCAVR and ICCtiny Users. You do NOT needtosubscribeto icc-announce if you are a member of this.' Sent: Sunday, December 02, 2007 10:21 PM Subject: RE: [Icc-avr] AT90USB162 Andrew, There is some good demo code from Atmel on the UART implementation using the 162. It is not ICC but the conversion for their demo code only takes a few hours. It is no a bad processor nad with the USB code working the device is only 40% full. Regards Mark ********************************** Mark Barber Extron Technologies Pty. Ltd. www.extron.com.au Ph: 613-9761-8166 Fx: 613-9761-8177 ********************************** _____ From: icc-avr-bounces@imagecraft.com [mailto:icc-avr-bounces@imagecraft.com] On Behalf Of Andrew Sent: Sunday, 2 December 2007 7:25 AM To: Discussion list for ICCAVR and ICCtiny Users. You do NOT needtosubscribeto icc-announce if you are a member of this. Subject: [Icc-avr] AT90USB162 Hi, Is there any working code compatible with the imagecraft compiler for the new USB devices from Atmel specifically the AT90USB162? If so where can i find them? All i need to do is make the USB turn up as a virtual serial port in windows and then be able to program the USB like the UARTS under ICCAVR. Many Thanks, NOTE is imagecraft going to make this part of the application builder process anytime soon? Andrew ----- Original Message ----- From: Richard To: 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 Sent: Saturday, December 01, 2007 7:16 PM Subject: Re: [Icc-avr] Whats in the mystery 40 bytes in ram? At 09:53 AM 12/1/2007, BobGardner@aol.com wrote: If I declare 'char junk;' as the first global var, it shows up in the map as 41 bytes. If I look in that area of ram, I guess it looks like some sort of ascii numbers with the residue of the last floating point printf the program printed out. I think if someone is unfortunate enough to trash this area due to a programming mistake, it causes weird stuff to happen. Maybe we could give it a label like 'printfbuffer' so folks could stay away from it? I really like Johannes' detailed map summary. Other items: can I make __flash a hilite in the editor? What do you folks think about the utility of a pragma to turn on and off expression eval using single or double floats? Would be useful in certain critical sections that needed hi precision, like NMEA lat/long calcs, could be turned off elsewhere. If you think this is a good idea, we should talk it up so it will get added...... Those 40 bytes (were) from the library, basically error msgs. They have been moved to flash only since 7,14 or may ve even 7,.13 // 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20071203/4bfebca2/attachment.html From sl at ecpower.dk Sun Dec 2 22:44:35 2007 From: sl at ecpower.dk (Steven Lose) Date: Sun Dec 2 22:58:11 2007 Subject: SV: [Icc-avr] Whats in the mystery 40 bytes in ram? References: <200712020323.lB23NMpa048637@dragonsgate2.imagecraft.com> Message-ID: <072D96786BFC014AAEBA9EB07A8070EA3086A6@seattle.ecpower.dk> Hi. I haven't started on the use of flash keyword yet, but highlight of keywords is a necessity, and sounds more like something that Richard forgot by mistake. It might be me not paying attention, but why did we need the double underscore in front of the flash keyword? No other C keyword use underscore! 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 Richard Sendt: 2. december 2007 03:50 Til: 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 Emne: Re: [Icc-avr] Whats in the mystery 40 bytes in ram? Bob, send me your project files zipped offlist. Thx At 02:22 PM 12/1/2007, BobGardner@aol.com wrote: But I'm running 7.15 pro... supposedly the latest and greatest? In a message dated 12/1/2007 2:21:59 P.M. Eastern Standard Time, richard-lists@imagecraft.com writes: At 09:53 AM 12/1/2007, BobGardner@aol.com wrote: If I declare 'char junk;' as the first global var, it shows up in the map as 41 bytes. If I look in that area of ram, I guess it looks like some sort of ascii numbers with the residue of the last floating point printf the program printed out. I think if someone is unfortunate enough to trash this area due to a programming mistake, it causes weird stuff to happen. Maybe we could give it a label like 'printfbuffer' so folks could stay away from it? I really like Johannes' detailed map summary. Other items: can I make __flash a hilite in the editor? What do you folks think about the utility of a pragma to turn on and off expression eval using single or double floats? Would be useful in certain critical sections that needed hi precision, like NMEA lat/long calcs, could be turned off elsewhere. If you think this is a good idea, we should talk it up so it will get added...... Those 40 bytes (were) from the library, basically error msgs. They have been moved to flash only since 7,14 or may ve even 7,.13 // 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 ________________________________ Check out AOL Money & Finance's list of the hottest products and top money wasters of 2007. _______________________________________________ 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) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20071203/7d27f531/attachment-0001.html From david_brown at hotpop.com Mon Dec 3 00:31:06 2007 From: david_brown at hotpop.com (David Brown) Date: Mon Dec 3 00:11:20 2007 Subject: [Icc-avr] Variables declared in main() and the stack In-Reply-To: References: <474F2653.6070603@hotpop.com> Message-ID: <4753BECA.7010701@hotpop.com> Albert vanVeen wrote: > I'm sorry to people who started thinking about Fibernacci's solution. It > was just a retoric question to show how some problems 'naturally' call > for a recursive function. And yes, it is probably true that the typical > use of these functions is in programming courses. Something you might > come across in real life could be faculties. And of course there are > other methods. > > Albert. > Generation of Fibernacci numbers using recursion is used as an academic example of why *not* to use recursion sometimes, even if it seems obvious and your chosen language has strong recursion support (such as functional programming languages). Think about how inefficient calculating F(n) = F(n - 1) + F(n - 2) would be. The typical example of a recursive function is for calculating factorials - but again, any decent programming language will automatically convert it into a loop, and with C you should convert it to a loop by hand. On the other hand, there are situations where recursive functions can often be the most elegant way to express the problem in question. Graph and tree structures often lend themselves to very elegant recursive algorithms. Walking general tree structures frequently requires a stack structure anyway, and you have the choice between using a simple and elegant (and therefore probably bug-free) recursive solution, or a more complex dedicated stack solution (which will probably use less memory). The balance of priorities here will of course be different for a small microcontroller, and a large computer, and depending on the programming language (for some languages, you should aim to convert your loops to recursions). The point is that any realistic recursive algorithm can be converted to a loop (or even an algorithm without any loops), and on a small microcontroller, you should normally do that. mvh., David > > -----Original Message----- > From: icc-avr-bounces@imagecraft.com > [mailto:icc-avr-bounces@imagecraft.com] On Behalf Of John Baraclough > Sent: Saturday, December 01, 2007 01:29 AM > To: Discussion list for ICCAVR and ICCtiny Users. You do NOT need > tosubscribe to icc-announce if you are a member of this. > Subject: RE: [Icc-avr] Variables declared in main() and the stack > > At 21:26 29/11/2007, you wrote: >> How do you solve Fibernacci without recursion? > > I really have to ask why, on a typical AVR (or indeed any other > 8-bit) based embedded system you would want to do that? Surely a limited > set of pre calculated values in a look-up table is the best method. > > John > From david_brown at hotpop.com Mon Dec 3 00:40:45 2007 From: david_brown at hotpop.com (David Brown) Date: Mon Dec 3 00:20:53 2007 Subject: SV: [Icc-avr] Whats in the mystery 40 bytes in ram? In-Reply-To: <072D96786BFC014AAEBA9EB07A8070EA3086A6@seattle.ecpower.dk> References: <200712020323.lB23NMpa048637@dragonsgate2.imagecraft.com> <072D96786BFC014AAEBA9EB07A8070EA3086A6@seattle.ecpower.dk> Message-ID: <4753C10D.6080109@hotpop.com> Steven Lose wrote: > Hi. > > > > I haven?t started on the use of flash keyword yet, but highlight of > keywords is a necessity, and sounds more like something that Richard > forgot by mistake. > > It might be me not paying attention, but why did we need the double > underscore in front of the *flash* keyword? > > No other C keyword use underscore! > That's because "flash" is not a C keyword, but an icc-avr specific pseudo-keyword, and the C standards make it perfectly clear that a compiler implementer cannot introduce a new "keyword" that is also a valid user-level identifier in standard C. The standards also make it clear that identifiers beginning with a double underscore are reserved for the implementer (either the compiler, or the libraries) - thus Richard did exactly the correct thing by making the word "__flash". That way, if your code had a function or variable "flash" from before, it will continue to work correctly and there is no collision of namespaces. You can, if you want, add a "#define flash __flash" line to your common include files to make your code look neater. mvh., David From sl at ecpower.dk Mon Dec 3 00:57:29 2007 From: sl at ecpower.dk (Steven Lose) Date: Mon Dec 3 01:11:07 2007 Subject: SV: SV: [Icc-avr] Whats in the mystery 40 bytes in ram? References: <200712020323.lB23NMpa048637@dragonsgate2.imagecraft.com><072D96786BFC014AAEBA9EB07A8070EA3086A6@seattle.ecpower.dk> <4753C10D.6080109@hotpop.com> Message-ID: <072D96786BFC014AAEBA9EB07A8070EA3086DB@seattle.ecpower.dk> Thanks David. I will not use the define, I stay with the __flash, and wait for the highlight. ;o) Med venlig hilsen / Best regards / mit freundlichen Gr??en EC POWER A/S Steven Lose Software Ingeni?r Tlf.: +45 87434100 Direkte tlf. +45 58286608 Email: sl@ecpower.dk www.ecpower.dk -----Oprindelig meddelelse----- Fra: icc-avr-bounces@imagecraft.com [mailto:icc-avr-bounces@imagecraft.com] P? vegne af David Brown Sendt: 3. december 2007 09:41 Til: Discussion list for ICCAVR and ICCtiny Users. You do NOT need tosubscribe to icc-announce if you are a member of this. Emne: Re: SV: [Icc-avr] Whats in the mystery 40 bytes in ram? Steven Lose wrote: > Hi. > > > > I haven't started on the use of flash keyword yet, but highlight of > keywords is a necessity, and sounds more like something that Richard > forgot by mistake. > > It might be me not paying attention, but why did we need the double > underscore in front of the *flash* keyword? > > No other C keyword use underscore! > That's because "flash" is not a C keyword, but an icc-avr specific pseudo-keyword, and the C standards make it perfectly clear that a compiler implementer cannot introduce a new "keyword" that is also a valid user-level identifier in standard C. The standards also make it clear that identifiers beginning with a double underscore are reserved for the implementer (either the compiler, or the libraries) - thus Richard did exactly the correct thing by making the word "__flash". That way, if your code had a function or variable "flash" from before, it will continue to work correctly and there is no collision of namespaces. You can, if you want, add a "#define flash __flash" line to your common include files to make your code look neater. mvh., David _______________________________________________ Icc-avr mailing list Icc-avr@imagecraft.com http://dragonsgate.net/mailman/listinfo/icc-avr From richard at imagecraft.com Mon Dec 3 02:27:52 2007 From: richard at imagecraft.com (Richard) Date: Mon Dec 3 02:42:04 2007 Subject: [Icc-avr] ICCV7 for AVR V.715 released Message-ID: <200712031042.lB3Ag30Q062801@dragonsgate2.imagecraft.com> From the readme: V7.15 - Dec 3rd, 2007 - Added __flash keyword. Use it to refer to objects or pointers in the flash space. IDE - [AppBudiler ] Added Tiny24, Tiny25, M324, M325, M324P, M325P M3250, M3250P, M329, M3290, M3290P - Added Project->Options->Compiler->"Treat const as __flash" for backward compatibility. If the checkbox is selected -Wf-const_is_flash -DCONST="" are added to the compiler flag. Compiler - Added support for __flash - If the command line flag -const_is_flash is used, then "const" is treated as the same as __flash Header Files - Added _const.h, with defines CONST and FLASH. // 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 oldboot at bigpond.com Mon Dec 3 03:55:03 2007 From: oldboot at bigpond.com (Owen) Date: Mon Dec 3 04:08:33 2007 Subject: [Icc-avr] ver 7.15 Broken Code Message-ID: ICCAVR version 7.15 seems to have broken my code that compiled quite happily with the earlier version, seems to be linked with the new header files supplied with version 7.15. Also lint reports a lot of errors in these headers, may be it just needs setting up properly to ignore them, I am getting a lot of error messages but mainly the one below. operands of = have illegal types `pointer to char' and `pointer to char' ??? Any suggestions would be helpful. Thanking You, Owen. Owen Allison. From richard at imagecraft.com Mon Dec 3 04:09:34 2007 From: richard at imagecraft.com (Richard) Date: Mon Dec 3 04:23:47 2007 Subject: [Icc-avr] Re: ICCV7 for AVR V.715 released In-Reply-To: <7.1.0.9.0.20071203022721.04b592d8@imagecraft.com> References: <7.1.0.9.0.20071203022721.04b592d8@imagecraft.com> Message-ID: <200712031223.lB3CNjek064571@dragonsgate2.imagecraft.com> 7.15 "recllaed" until further notice. sorry. At 02:27 AM 12/3/2007, Richard wrote: > From the readme: > >V7.15 - Dec 3rd, 2007 > - Added __flash keyword. Use it to refer to objects or pointers in the > flash space. > > IDE > - [AppBudiler ] Added Tiny24, Tiny25, M324, M325, M324P, M325P > M3250, M3250P, M329, M3290, M3290P > - Added Project->Options->Compiler->"Treat const as __flash" for > backward compatibility. If the checkbox is selected > > -Wf-const_is_flash -DCONST="" > are added to the compiler flag. > Compiler > - Added support for __flash > - If the command line flag -const_is_flash is used, then "const" is > treated as the same as __flash > > Header Files > - Added _const.h, with defines CONST and FLASH. > >// 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. ] // 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 oldboot at bigpond.com Mon Dec 3 04:57:44 2007 From: oldboot at bigpond.com (Owen) Date: Mon Dec 3 05:11:17 2007 Subject: [Icc-avr] Re: ICCV7 for AVR V.715 released In-Reply-To: <200712031223.lB3CNjek064571@dragonsgate2.imagecraft.com> References: <7.1.0.9.0.20071203022721.04b592d8@imagecraft.com> <200712031223.lB3CNjek064571@dragonsgate2.imagecraft.com> Message-ID: Richard, Thank you for the prompt confirmation about ver 7.15, I was wondering if I had done something wrong. Also I suspect it would have been beyond my resources sorting out all those errors. I have reinstalled ver 7.14 and everything seems to be working ok again. Thanking You, Owen. Owen Allison From: icc-avr-bounces@imagecraft.com [mailto:icc-avr-bounces@imagecraft.com] On Behalf Of Richard Sent: Monday, December 03, 2007 11:10 PM To: icc-avr@imagecraft.com; icc-announce@imagecraft.com Subject: [Icc-avr] Re: ICCV7 for AVR V.715 released 7.15 "recllaed" until further notice. sorry. At 02:27 AM 12/3/2007, Richard wrote: > From the readme: > >V7.15 - Dec 3rd, 2007 > - Added __flash keyword. Use it to refer to objects or pointers in the > flash space. > > IDE > - [AppBudiler ] Added Tiny24, Tiny25, M324, M325, M324P, M325P > M3250, M3250P, M329, M3290, M3290P > - Added Project->Options->Compiler->"Treat const as __flash" for > backward compatibility. If the checkbox is selected > > -Wf-const_is_flash -DCONST="" > are added to the compiler flag. > Compiler > - Added support for __flash > - If the command line flag -const_is_flash is used, then "const" is > treated as the same as __flash > > Header Files > - Added _const.h, with defines CONST and FLASH. > >// 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. ] // 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 Albert.vanVeen at pertronic.co.nz Mon Dec 3 11:19:50 2007 From: Albert.vanVeen at pertronic.co.nz (Albert vanVeen) Date: Mon Dec 3 11:33:28 2007 Subject: [Icc-avr] Variables declared in main() and the stack In-Reply-To: <4753BECA.7010701@hotpop.com> References: <474F2653.6070603@hotpop.com> <4753BECA.7010701@hotpop.com> Message-ID: "Faculties"? Did I write that? factorials, thank you. I never considered what you said "any decent programming language will automatically convert it into a loop". I might be getting philosophical, but shouldn't it be up to the programmer, not the machine, how to implement a function? I have the choice: recursion, loop, something else; the compiler should then not go and change my choice! As I often say to my obstinate computer: Who is the boss here? Albert. -----Original Message----- From: icc-avr-bounces@imagecraft.com [mailto:icc-avr-bounces@imagecraft.com] On Behalf Of David Brown Sent: Monday, December 03, 2007 09:31 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] Variables declared in main() and the stack Albert vanVeen wrote: > I'm sorry to people who started thinking about Fibernacci's solution. > It was just a retoric question to show how some problems 'naturally' > call for a recursive function. And yes, it is probably true that the > typical use of these functions is in programming courses. Something > you might come across in real life could be faculties. And of course > there are other methods. > > Albert. > Generation of Fibernacci numbers using recursion is used as an academic example of why *not* to use recursion sometimes, even if it seems obvious and your chosen language has strong recursion support (such as functional programming languages). Think about how inefficient calculating F(n) = F(n - 1) + F(n - 2) would be. The typical example of a recursive function is for calculating factorials - but again, any decent programming language will automatically convert it into a loop, and with C you should convert it to a loop by hand. On the other hand, there are situations where recursive functions can often be the most elegant way to express the problem in question. Graph and tree structures often lend themselves to very elegant recursive algorithms. Walking general tree structures frequently requires a stack structure anyway, and you have the choice between using a simple and elegant (and therefore probably bug-free) recursive solution, or a more complex dedicated stack solution (which will probably use less memory). The balance of priorities here will of course be different for a small microcontroller, and a large computer, and depending on the programming language (for some languages, you should aim to convert your loops to recursions). The point is that any realistic recursive algorithm can be converted to a loop (or even an algorithm without any loops), and on a small microcontroller, you should normally do that. mvh., David > > -----Original Message----- > From: icc-avr-bounces@imagecraft.com > [mailto:icc-avr-bounces@imagecraft.com] On Behalf Of John Baraclough > Sent: Saturday, December 01, 2007 01:29 AM > To: Discussion list for ICCAVR and ICCtiny Users. You do NOT need > tosubscribe to icc-announce if you are a member of this. > Subject: RE: [Icc-avr] Variables declared in main() and the stack > > At 21:26 29/11/2007, you wrote: >> How do you solve Fibernacci without recursion? > > I really have to ask why, on a typical AVR (or indeed any other > 8-bit) based embedded system you would want to do that? Surely a > limited set of pre calculated values in a look-up table is the best method. > > John > _______________________________________________ Icc-avr mailing list Icc-avr@imagecraft.com http://dragonsgate.net/mailman/listinfo/icc-avr Scanned by Bizo Email Filter From jassenbaum at htp-tel.de Mon Dec 3 11:53:39 2007 From: jassenbaum at htp-tel.de (Johannes Assenbaum) Date: Mon Dec 3 12:07:55 2007 Subject: [Icc-avr] Variables declared in main() and the stack References: <4753BECA.7010701@hotpop.com> Message-ID: And yes, recursive functions are used even on 8-bit targets some now and then. E.g. I use such quite normally while developing, and once even shipped. With call deepth and so memory usage limited, there for me is nothing against recursion. Best regards, Johannes > Albert vanVeen wrote: >> I'm sorry to people who started thinking about Fibernacci's solution. It >> was just a retoric question to show how some problems 'naturally' call >> for a recursive function. And yes, it is probably true that the typical >> use of these functions is in programming courses. Something you might >> come across in real life could be faculties. And of course there are >> other methods. >> >> Albert. >> > Generation of Fibernacci numbers using recursion is used as an academic > example of why *not* to use recursion sometimes, even if it seems > obvious and your chosen language has strong recursion support (such as > functional programming languages). Think about how inefficient > calculating F(n) = F(n - 1) + F(n - 2) would be. > The typical example of a recursive function is for calculating > factorials - but again, any decent programming language will > automatically convert it into a loop, and with C you should convert it > to a loop by hand. > On the other hand, there are situations where recursive functions can > often be the most elegant way to express the problem in question. Graph > and tree structures often lend themselves to very elegant recursive > algorithms. Walking general tree structures frequently requires a stack > structure anyway, and you have the choice between using a simple and > elegant (and therefore probably bug-free) recursive solution, or a more > complex dedicated stack solution (which will probably use less memory). > The balance of priorities here will of course be different for a small > microcontroller, and a large computer, and depending on the programming > language (for some languages, you should aim to convert your loops to > recursions). > The point is that any realistic recursive algorithm can be converted to > a loop (or even an algorithm without any loops), and on a small > microcontroller, you should normally do that. > mvh., > David >> >> -----Original Message----- >> From: icc-avr-bounces@imagecraft.com >> [mailto:icc-avr-bounces@imagecraft.com] On Behalf Of John Baraclough >> Sent: Saturday, December 01, 2007 01:29 AM >> To: Discussion list for ICCAVR and ICCtiny Users. You do NOT need >> tosubscribe to icc-announce if you are a member of this. >> Subject: RE: [Icc-avr] Variables declared in main() and the stack >> >> At 21:26 29/11/2007, you wrote: >>> How do you solve Fibernacci without recursion? >> >> I really have to ask why, on a typical AVR (or indeed any other >> 8-bit) based embedded system you would want to do that? Surely a limited >> set of pre calculated values in a look-up table is the best method. >> >> John >> > _______________________________________________ > 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.503 / Virus Database: 269.16.13/1167 - Release Date: 03.12.07 12:20 From david_brown at hotpop.com Mon Dec 3 13:02:29 2007 From: david_brown at hotpop.com (David Brown) Date: Mon Dec 3 13:16:06 2007 Subject: [Icc-avr] Variables declared in main() and the stack In-Reply-To: References: <474F2653.6070603@hotpop.com> <4753BECA.7010701@hotpop.com> Message-ID: <47546EE5.2030008@hotpop.com> Albert vanVeen wrote: > "Faculties"? Did I write that? factorials, thank you. > I never considered what you said "any decent programming language will > automatically convert it into a loop". I might be getting philosophical, > but shouldn't it be up to the programmer, not the machine, how to > implement a function? I have the choice: recursion, loop, something > else; the compiler should then not go and change my choice! As I often > say to my obstinate computer: Who is the boss here? > No, you do *not* get to tell the compiler exactly how you want it to implement your source code. If you want that, stick to assembly. When you write C code, you want the compiler to generate code that gives the same result as if it had directly implemented the code you wrote, but it is allowed to take shortcuts. If you write: int factorial(int n) { if (n <= 1) return 1; return n * factorial(n - 1); } then the compiler can reorganise that as a loop if it wants - and a good enough optimiser will do exactly that (except in the case when the function is called with a compile-time constant - ideally, the compiler will compute the answer at compile time rather than run time). I don't know off-hand which C compilers actually handle such optimisations, but they are certainly free to do so. When I wrote about converting recursion into loops, however, I was not thinking about C, since recursion is not a common construct in C. In functional programming languages such as Haskell or OCaml, recursion is much more common. In Caml, you would probably write your factorial function as: let rec factorial = function | 0 -> 1 | n -> n * factorial(n - 1);; In Haskell: factorial 0 = 1 factorial n = n * factorial (n - 1) When compiling these functions to bytecode (or possibly assembly code, for OCaml), the compiler will generate loops for these functions rather than recursive function calls. Even though C is a lower-level language, you are not working at the assembly level, and you are not giving strict instructions. The compiler doesn't have to give a direct translation of your code, even if you have optimisations disabled (as that's just a hint that compiler should not try to hard to optimise the code - it's not an order). The point is, you are the *boss* - you are not a micro-manager. mvh., David > Albert. > > > -----Original Message----- > From: icc-avr-bounces@imagecraft.com > [mailto:icc-avr-bounces@imagecraft.com] On Behalf Of David Brown > Sent: Monday, December 03, 2007 09:31 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] Variables declared in main() and the stack > > Albert vanVeen wrote: >> I'm sorry to people who started thinking about Fibernacci's solution. >> It was just a retoric question to show how some problems 'naturally' >> call for a recursive function. And yes, it is probably true that the >> typical use of these functions is in programming courses. Something >> you might come across in real life could be faculties. And of course >> there are other methods. >> >> Albert. >> > > Generation of Fibernacci numbers using recursion is used as an academic > example of why *not* to use recursion sometimes, even if it seems > obvious and your chosen language has strong recursion support (such as > functional programming languages). Think about how inefficient > calculating F(n) = F(n - 1) + F(n - 2) would be. > > The typical example of a recursive function is for calculating > factorials - but again, any decent programming language will > automatically convert it into a loop, and with C you should convert it > to a loop by hand. > > On the other hand, there are situations where recursive functions can > often be the most elegant way to express the problem in question. Graph > and tree structures often lend themselves to very elegant recursive > algorithms. Walking general tree structures frequently requires a stack > structure anyway, and you have the choice between using a simple and > elegant (and therefore probably bug-free) recursive solution, or a more > complex dedicated stack solution (which will probably use less memory). > The balance of priorities here will of course be different for a small > microcontroller, and a large computer, and depending on the programming > language (for some languages, you should aim to convert your loops to > recursions). > > The point is that any realistic recursive algorithm can be converted to > a loop (or even an algorithm without any loops), and on a small > microcontroller, you should normally do that. > > mvh., > > David > > >> -----Original Message----- >> From: icc-avr-bounces@imagecraft.com >> [mailto:icc-avr-bounces@imagecraft.com] On Behalf Of John Baraclough >> Sent: Saturday, December 01, 2007 01:29 AM >> To: Discussion list for ICCAVR and ICCtiny Users. You do NOT need >> tosubscribe to icc-announce if you are a member of this. >> Subject: RE: [Icc-avr] Variables declared in main() and the stack >> >> At 21:26 29/11/2007, you wrote: >>> How do you solve Fibernacci without recursion? >> I really have to ask why, on a typical AVR (or indeed any other >> 8-bit) based embedded system you would want to do that? Surely a >> limited set of pre calculated values in a look-up table is the best > method. >> John >> From Albert.vanVeen at pertronic.co.nz Mon Dec 3 14:11:50 2007 From: Albert.vanVeen at pertronic.co.nz (Albert vanVeen) Date: Mon Dec 3 14:25:35 2007 Subject: [Icc-avr] Variables declared in main() and the stack In-Reply-To: <47546EE5.2030008@hotpop.com> References: <474F2653.6070603@hotpop.com> <4753BECA.7010701@hotpop.com> <47546EE5.2030008@hotpop.com> Message-ID: Hmmmm... not convinced. As I said: I (the boss) have already decided on the algorithm to be used; it's not up to the compiler to choose a different algorithm. *Optimisation* is not easy in such circumstances: what does the compiler optimise: time or space? Space is "easy" (sorry Richard), time not so, can be pretty complex for a mere compiler, whereas **I** know what I'm doing (no comments please). -----Original Message----- From: icc-avr-bounces@imagecraft.com [mailto:icc-avr-bounces@imagecraft.com] On Behalf Of David Brown Sent: Tuesday, December 04, 2007 10:02 AM To: Discussion list for ICCAVR and ICCtiny Users. You do NOT need tosubscribe to icc-announce if you are a member of this. Subject: Re: [Icc-avr] Variables declared in main() and the stack Albert vanVeen wrote: > "Faculties"? Did I write that? factorials, thank you. > I never considered what you said "any decent programming language will > automatically convert it into a loop". I might be getting > philosophical, but shouldn't it be up to the programmer, not the > machine, how to implement a function? I have the choice: recursion, > loop, something else; the compiler should then not go and change my > choice! As I often say to my obstinate computer: Who is the boss here? > No, you do *not* get to tell the compiler exactly how you want it to implement your source code. If you want that, stick to assembly. When you write C code, you want the compiler to generate code that gives the same result as if it had directly implemented the code you wrote, but it is allowed to take shortcuts. If you write: int factorial(int n) { if (n <= 1) return 1; return n * factorial(n - 1); } then the compiler can reorganise that as a loop if it wants - and a good enough optimiser will do exactly that (except in the case when the function is called with a compile-time constant - ideally, the compiler will compute the answer at compile time rather than run time). I don't know off-hand which C compilers actually handle such optimisations, but they are certainly free to do so. When I wrote about converting recursion into loops, however, I was not thinking about C, since recursion is not a common construct in C. In functional programming languages such as Haskell or OCaml, recursion is much more common. In Caml, you would probably write your factorial function as: let rec factorial = function | 0 -> 1 | n -> n * factorial(n - 1);; In Haskell: factorial 0 = 1 factorial n = n * factorial (n - 1) When compiling these functions to bytecode (or possibly assembly code, for OCaml), the compiler will generate loops for these functions rather than recursive function calls. Even though C is a lower-level language, you are not working at the assembly level, and you are not giving strict instructions. The compiler doesn't have to give a direct translation of your code, even if you have optimisations disabled (as that's just a hint that compiler should not try to hard to optimise the code - it's not an order). The point is, you are the *boss* - you are not a micro-manager. mvh., David > Albert. > > > -----Original Message----- > From: icc-avr-bounces@imagecraft.com > [mailto:icc-avr-bounces@imagecraft.com] On Behalf Of David Brown > Sent: Monday, December 03, 2007 09:31 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] Variables declared in main() and the stack > > Albert vanVeen wrote: >> I'm sorry to people who started thinking about Fibernacci's solution. >> It was just a retoric question to show how some problems 'naturally' >> call for a recursive function. And yes, it is probably true that the >> typical use of these functions is in programming courses. Something >> you might come across in real life could be faculties. And of course >> there are other methods. >> >> Albert. >> > > Generation of Fibernacci numbers using recursion is used as an > academic example of why *not* to use recursion sometimes, even if it > seems obvious and your chosen language has strong recursion support > (such as functional programming languages). Think about how > inefficient calculating F(n) = F(n - 1) + F(n - 2) would be. > > The typical example of a recursive function is for calculating > factorials - but again, any decent programming language will > automatically convert it into a loop, and with C you should convert it > to a loop by hand. > > On the other hand, there are situations where recursive functions can > often be the most elegant way to express the problem in question. > Graph and tree structures often lend themselves to very elegant > recursive algorithms. Walking general tree structures frequently > requires a stack structure anyway, and you have the choice between > using a simple and elegant (and therefore probably bug-free) recursive > solution, or a more complex dedicated stack solution (which will probably use less memory). > The balance of priorities here will of course be different for a > small microcontroller, and a large computer, and depending on the > programming language (for some languages, you should aim to convert > your loops to recursions). > > The point is that any realistic recursive algorithm can be converted > to a loop (or even an algorithm without any loops), and on a small > microcontroller, you should normally do that. > > mvh., > > David > > >> -----Original Message----- >> From: icc-avr-bounces@imagecraft.com >> [mailto:icc-avr-bounces@imagecraft.com] On Behalf Of John Baraclough >> Sent: Saturday, December 01, 2007 01:29 AM >> To: Discussion list for ICCAVR and ICCtiny Users. You do NOT need >> tosubscribe to icc-announce if you are a member of this. >> Subject: RE: [Icc-avr] Variables declared in main() and the stack >> >> At 21:26 29/11/2007, you wrote: >>> How do you solve Fibernacci without recursion? >> I really have to ask why, on a typical AVR (or indeed any other >> 8-bit) based embedded system you would want to do that? Surely a >> limited set of pre calculated values in a look-up table is the best > method. >> John >> _______________________________________________ Icc-avr mailing list Icc-avr@imagecraft.com http://dragonsgate.net/mailman/listinfo/icc-avr Scanned by Bizo Email Filter From bobgardner at aol.com Mon Dec 3 14:22:47 2007 From: bobgardner at aol.com (bobgardner@aol.com) Date: Mon Dec 3 14:38:40 2007 Subject: [Icc-avr] Variables declared in main() and the stack In-Reply-To: <47546EE5.2030008@hotpop.com> References: <474F2653.6070603@hotpop.com> <4753BECA.7010701@hotpop.com> <47546EE5.2030008@hotpop.com> Message-ID: <8CA04122B2EA298-778-1273@WEBMAIL-DG15> Old Fibonacci is turning over in his grave. He's not Fibber McGee! > > Albert vanVeen wrote:? >> I'm sorry to people who started thinking about Fibernacci's solution. ? ________________________________________________________________________ More new features than ever. Check out the new AOL Mail ! - http://o.aolcdn.com/cdn.webmail.aol.com/mailtour/aol/en-us/text.htm?ncid=aolcmp00050000000003 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20071203/a409b413/attachment.html From richard-lists at imagecraft.com Mon Dec 3 15:43:12 2007 From: richard-lists at imagecraft.com (Richard) Date: Mon Dec 3 15:57:28 2007 Subject: [Icc-avr] Variables declared in main() and the stack In-Reply-To: References: <474F2653.6070603@hotpop.com> <4753BECA.7010701@hotpop.com> <47546EE5.2030008@hotpop.com> Message-ID: <200712032357.lB3NvQeI071612@dragonsgate2.imagecraft.com> This is probably straying a bit far from the list's purpose, but let me close the thread by saying that David is correct: a C compiler may compile a program very different from what the programmers write, as long as all the side effects are observed and the results are correct. A simple example is that a "useless" loop with no side effect can be eliminated by the compilers. At 02:11 PM 12/3/2007, Albert vanVeen wrote: >Hmmmm... not convinced. As I said: I (the boss) have already decided on >the algorithm to be used; it's not up to the compiler to choose a >different algorithm. *Optimisation* is not easy in such circumstances: >what does the compiler optimise: time or space? Space is "easy" (sorry >Richard), time not so, can be pretty complex for a mere compiler, >whereas **I** know what I'm doing (no comments please). > // richard (This email is for mailing lists. To reach me directly, please use richard at imagecraft.com) From andrew_166 at msn.com Tue Dec 4 05:28:53 2007 From: andrew_166 at msn.com (Andrew) Date: Tue Dec 4 05:42:33 2007 Subject: [Icc-avr] ICCARV Bootloader References: <200712011930.lB1JUYsR044858@dragonsgate2.imagecraft.com> Message-ID: Hi, I have an AVR 128 and i need to try and make a bootloader for it, but i have no idea where to start can some sombody direct me to some datasheets or sample code please. For the ICCAVR compiler Andy ----- Original Message ----- From: Andrew To: Discussion list for ICCAVR and ICCtiny Users. You do NOT needtosubscribeto icc-announce if you are a member of this. Sent: Saturday, December 01, 2007 8:24 PM Subject: [Icc-avr] AT90USB162 Hi, Is there any working code compatible with the imagecraft compiler for the new USB devices from Atmel specifically the AT90USB162? If so where can i find them? All i need to do is make the USB turn up as a virtual serial port in windows and then be able to program the USB like the UARTS under ICCAVR. Many Thanks, NOTE is imagecraft going to make this part of the application builder process anytime soon? Andrew ----- Original Message ----- From: Richard To: 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 Sent: Saturday, December 01, 2007 7:16 PM Subject: Re: [Icc-avr] Whats in the mystery 40 bytes in ram? At 09:53 AM 12/1/2007, BobGardner@aol.com wrote: If I declare 'char junk;' as the first global var, it shows up in the map as 41 bytes. If I look in that area of ram, I guess it looks like some sort of ascii numbers with the residue of the last floating point printf the program printed out. I think if someone is unfortunate enough to trash this area due to a programming mistake, it causes weird stuff to happen. Maybe we could give it a label like 'printfbuffer' so folks could stay away from it? I really like Johannes' detailed map summary. Other items: can I make __flash a hilite in the editor? What do you folks think about the utility of a pragma to turn on and off expression eval using single or double floats? Would be useful in certain critical sections that needed hi precision, like NMEA lat/long calcs, could be turned off elsewhere. If you think this is a good idea, we should talk it up so it will get added...... Those 40 bytes (were) from the library, basically error msgs. They have been moved to flash only since 7,14 or may ve even 7,.13 // 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20071204/3d200b0c/attachment-0001.html From rodney at junipersys.com Tue Dec 4 06:43:53 2007 From: rodney at junipersys.com (Rodney Pearson) Date: Tue Dec 4 06:57:43 2007 Subject: [Icc-avr] ICCARV Bootloader In-Reply-To: References: <200712011930.lB1JUYsR044858@dragonsgate2.imagecraft.com> Message-ID: Hi Andrew - Here is a list of AVR App Notes to get you started: - AVR109: Self Programming - AVR230: DES Bootloader - AVR231: AES Bootloader All are available on Atmel's website. Also, the data sheet for the 640/1280/2560 has a thorough section on self-programming that will help out ("Boot Loader Support"). In the ICCAVR install directory you can find example SPM code for the flash programming (\ICCAVR\examples.avr\appnote109\assembly.c). I ported the Atmel AES bootloader to ICCAVR (from IAR). It is written for the M2560, but should easily work for the M1280 with a few minor changes. I submitted it to Richard a few weeks back, so it should (hopefully) appear shortly if Richard decides to post it in the example code section on the ImageCraft site. If you need it sooner than that, let me know and I can get you a copy of the code. 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 Andrew Sent: Tuesday, December 04, 2007 6:29 AM To: Discussion list for ICCAVR and ICCtiny Users. You do NOT needtosubscribeto icc-announce if you are a member of this. Subject: [Icc-avr] ICCARV Bootloader Hi, I have an AVR 128 and i need to try and make a bootloader for it, but i have no idea where to start can some sombody direct me to some datasheets or sample code please. For the ICCAVR compiler Andy ----- Original Message ----- From: Andrew To: Discussion list for ICCAVR and ICCtiny Users. You do NOT needtosubscribeto icc-announce if you are a member of this. Sent: Saturday, December 01, 2007 8:24 PM Subject: [Icc-avr] AT90USB162 Hi, Is there any working code compatible with the imagecraft compiler for the new USB devices from Atmel specifically the AT90USB162? If so where can i find them? All i need to do is make the USB turn up as a virtual serial port in windows and then be able to program the USB like the UARTS under ICCAVR. Many Thanks, NOTE is imagecraft going to make this part of the application builder process anytime soon? Andrew ----- Original Message ----- From: Richard To: 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 Sent: Saturday, December 01, 2007 7:16 PM Subject: Re: [Icc-avr] Whats in the mystery 40 bytes in ram? At 09:53 AM 12/1/2007, BobGardner@aol.com wrote: If I declare 'char junk;' as the first global var, it shows up in the map as 41 bytes. If I look in that area of ram, I guess it looks like some sort of ascii numbers with the residue of the last floating point printf the program printed out. I think if someone is unfortunate enough to trash this area due to a programming mistake, it causes weird stuff to happen. Maybe we could give it a label like 'printfbuffer' so folks could stay away from it? I really like Johannes' detailed map summary. Other items: can I make __flash a hilite in the editor? What do you folks think about the utility of a pragma to turn on and off expression eval using single or double floats? Would be useful in certain critical sections that needed hi precision, like NMEA lat/long calcs, could be turned off elsewhere. If you think this is a good idea, we should talk it up so it will get added...... Those 40 bytes (were) from the library, basically error msgs. They have been moved to flash only since 7,14 or may ve even 7,.13 // 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20071204/976c603e/attachment.html From rodney at junipersys.com Tue Dec 4 06:49:07 2007 From: rodney at junipersys.com (Rodney Pearson) Date: Tue Dec 4 07:02:50 2007 Subject: [Icc-avr] ICCARV Bootloader In-Reply-To: References: <200712011930.lB1JUYsR044858@dragonsgate2.imagecraft.com> Message-ID: I also neglected to mention Sylvain's megaloader bootloader that he created. It's available from him at www.microsyl.com. 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 Andrew Sent: Tuesday, December 04, 2007 6:29 AM To: Discussion list for ICCAVR and ICCtiny Users. You do NOT needtosubscribeto icc-announce if you are a member of this. Subject: [Icc-avr] ICCARV Bootloader Hi, I have an AVR 128 and i need to try and make a bootloader for it, but i have no idea where to start can some sombody direct me to some datasheets or sample code please. For the ICCAVR compiler Andy ----- Original Message ----- From: Andrew To: Discussion list for ICCAVR and ICCtiny Users. You do NOT needtosubscribeto icc-announce if you are a member of this. Sent: Saturday, December 01, 2007 8:24 PM Subject: [Icc-avr] AT90USB162 Hi, Is there any working code compatible with the imagecraft compiler for the new USB devices from Atmel specifically the AT90USB162? If so where can i find them? All i need to do is make the USB turn up as a virtual serial port in windows and then be able to program the USB like the UARTS under ICCAVR. Many Thanks, NOTE is imagecraft going to make this part of the application builder process anytime soon? Andrew ----- Original Message ----- From: Richard To: 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 Sent: Saturday, December 01, 2007 7:16 PM Subject: Re: [Icc-avr] Whats in the mystery 40 bytes in ram? At 09:53 AM 12/1/2007, BobGardner@aol.com wrote: If I declare 'char junk;' as the first global var, it shows up in the map as 41 bytes. If I look in that area of ram, I guess it looks like some sort of ascii numbers with the residue of the last floating point printf the program printed out. I think if someone is unfortunate enough to trash this area due to a programming mistake, it causes weird stuff to happen. Maybe we could give it a label like 'printfbuffer' so folks could stay away from it? I really like Johannes' detailed map summary. Other items: can I make __flash a hilite in the editor? What do you folks think about the utility of a pragma to turn on and off expression eval using single or double floats? Would be useful in certain critical sections that needed hi precision, like NMEA lat/long calcs, could be turned off elsewhere. If you think this is a good idea, we should talk it up so it will get added...... Those 40 bytes (were) from the library, basically error msgs. They have been moved to flash only since 7,14 or may ve even 7,.13 // 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20071204/ca741b40/attachment-0001.html From johan at edab.nu Tue Dec 4 07:05:51 2007 From: johan at edab.nu (=?iso-8859-1?Q?Johan_Wallstr=F6m?=) Date: Tue Dec 4 07:16:06 2007 Subject: [Icc-avr] ICCARV Bootloader References: <200712011930.lB1JUYsR044858@dragonsgate2.imagecraft.com> Message-ID: <005901c83687$2917a740$64026e0a@EDAB1> I have a bl for atmega128, if you want to have a look I can send it to you. From: Andrew To: Discussion list for ICCAVR and ICCtiny Users. You do NOT needtosubscribeto icc-announce if you are a member of this. Sent: Tuesday, December 04, 2007 2:28 PM Subject: [Icc-avr] ICCARV Bootloader Hi, I have an AVR 128 and i need to try and make a bootloader for it, but i have no idea where to start can some sombody direct me to some datasheets or sample code please. For the ICCAVR compiler Andy ----- Original Message ----- From: Andrew To: Discussion list for ICCAVR and ICCtiny Users. You do NOT needtosubscribeto icc-announce if you are a member of this. Sent: Saturday, December 01, 2007 8:24 PM Subject: [Icc-avr] AT90USB162 Hi, Is there any working code compatible with the imagecraft compiler for the new USB devices from Atmel specifically the AT90USB162? If so where can i find them? All i need to do is make the USB turn up as a virtual serial port in windows and then be able to program the USB like the UARTS under ICCAVR. Many Thanks, NOTE is imagecraft going to make this part of the application builder process anytime soon? Andrew ----- Original Message ----- From: Richard To: 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 Sent: Saturday, December 01, 2007 7:16 PM Subject: Re: [Icc-avr] Whats in the mystery 40 bytes in ram? At 09:53 AM 12/1/2007, BobGardner@aol.com wrote: If I declare 'char junk;' as the first global var, it shows up in the map as 41 bytes. If I look in that area of ram, I guess it looks like some sort of ascii numbers with the residue of the last floating point printf the program printed out. I think if someone is unfortunate enough to trash this area due to a programming mistake, it causes weird stuff to happen. Maybe we could give it a label like 'printfbuffer' so folks could stay away from it? I really like Johannes' detailed map summary. Other items: can I make __flash a hilite in the editor? What do you folks think about the utility of a pragma to turn on and off expression eval using single or double floats? Would be useful in certain critical sections that needed hi precision, like NMEA lat/long calcs, could be turned off elsewhere. If you think this is a good idea, we should talk it up so it will get added...... Those 40 bytes (were) from the library, basically error msgs. They have been moved to flash only since 7,14 or may ve even 7,.13 // richard (This email is for mailing lists. To reach me directly, please use richard at imagecraft.com) -------------------------------------------------------------------------- _______________________________________________ Icc-avr mailing list Icc-avr@imagecraft.com http://dragonsgate.net/mailman/listinfo/icc-avr ---------------------------------------------------------------------------- _______________________________________________ Icc-avr mailing list Icc-avr@imagecraft.com http://dragonsgate.net/mailman/listinfo/icc-avr ------------------------------------------------------------------------------ _______________________________________________ Icc-avr mailing list Icc-avr@imagecraft.com http://dragonsgate.net/mailman/listinfo/icc-avr -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20071204/79f0efca/attachment.html From j_baraclough at zetnet.co.uk Tue Dec 4 07:38:32 2007 From: j_baraclough at zetnet.co.uk (John Baraclough) Date: Tue Dec 4 07:52:09 2007 Subject: [Icc-avr] ICCARV Bootloader In-Reply-To: References: <200712011930.lB1JUYsR044858@dragonsgate2.imagecraft.com> Message-ID: Sylvain has one including the PC front end at http://www.microsyl.com/. Just click on the MegaLoad link. All the best for now, John At 13:28 04/12/2007, you wrote: >Hi, > >I have an AVR 128 and i need to try and make a bootloader for it, >but i have no idea where to start can some sombody direct me to some >datasheets or sample code please. For the ICCAVR compiler > >Andy -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20071204/a03fb0c3/attachment.html From andrew_166 at msn.com Tue Dec 4 11:00:11 2007 From: andrew_166 at msn.com (Andrew) Date: Tue Dec 4 11:14:11 2007 Subject: [Icc-avr] ICCARV Bootloader References: <200712011930.lB1JUYsR044858@dragonsgate2.imagecraft.com> Message-ID: Hi all, I will give the MegaLoad ago, if i have any problems i will let you now. NOTE; Thanks to everybody for all there help and advice, it is much appreciated. Since i have been on the mailing list i have had allot of very helpful advice. Regarding the bootloader ; I know if I can select its size in the fuses and this much then take up x amount of EPROM ( I am guessing, I am have not had chance to read any of the app notes yet) Best Regards, Andrew - From: John Baraclough To: Discussion list for ICCAVR and ICCtiny Users. You do NOT need tosubscribe to icc-announce if you are a member of this. Sent: Tuesday, December 04, 2007 3:38 PM Subject: Re: [Icc-avr] ICCARV Bootloader Sylvain has one including the PC front end at http://www.microsyl.com/. Just click on the MegaLoad link. All the best for now, John At 13:28 04/12/2007, you wrote: Hi, I have an AVR 128 and i need to try and make a bootloader for it, but i have no idea where to start can some sombody direct me to some datasheets or sample code please. For the ICCAVR compiler Andy ------------------------------------------------------------------------------ _______________________________________________ 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/20071204/1b8a915d/attachment-0001.html From andrew_166 at msn.com Tue Dec 4 11:14:56 2007 From: andrew_166 at msn.com (Andrew) Date: Tue Dec 4 11:29:52 2007 Subject: [Icc-avr] ICCARV Bootloader References: <200712011930.lB1JUYsR044858@dragonsgate2.imagecraft.com> Message-ID: Hi all, I will give the MegaLoad ago, if i have any problems i will let you now. NOTE; Thanks to everybody for all there help and advice, it is much appreciated. Since i have been on the mailing list i have had allot of very helpful advice. Regarding the bootloader ; I know if I can select its size in the fuses and this much then take up x amount of EPROM ( I am guessing, I am have not had chance to read any of the app notes yet). SO my question is that when I address the EPROM i.e to save variables can I still go from address 0 to the end? Or does the complier not adjust for this, thus starting at address 0 would write over the bootloader. Best Regards, Andrew ----- Original Message ----- From: John Baraclough To: Discussion list for ICCAVR and ICCtiny Users. You do NOT need tosubscribe to icc-announce if you are a member of this. Sent: Tuesday, December 04, 2007 3:38 PM Subject: Re: [Icc-avr] ICCARV Bootloader Sylvain has one including the PC front end at http://www.microsyl.com/. Just click on the MegaLoad link. All the best for now, John At 13:28 04/12/2007, you wrote: Hi, I have an AVR 128 and i need to try and make a bootloader for it, but i have no idea where to start can some sombody direct me to some datasheets or sample code please. For the ICCAVR compiler Andy ------------------------------------------------------------------------------ _______________________________________________ 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/20071204/071e42e5/attachment.html From andrew_166 at msn.com Tue Dec 4 11:39:41 2007 From: andrew_166 at msn.com (Andrew) Date: Tue Dec 4 11:53:34 2007 Subject: [Icc-avr] ICCARV Bootloader References: <200712011930.lB1JUYsR044858@dragonsgate2.imagecraft.com> Message-ID: Hi all, I will give the MegaLoad ago, if i have any problems i will let you now. NOTE; Thanks to everybody for all there help and advice, it is much appreciated. Since i have been on the mailing list i have had allot of very helpful advice. Regarding the boot loader; I know I can select its size in the fuses and this must then take up x amount of EPROM space (I am guessing, as I have not had chance to read any of the app notes yet) that the compiler sorts out the EPROM allocation, so that in code I can still save program variables into the EPROM starting at address 0, or do I have to compensate for the bootloader and thus make sure I don't over write it? SORRY THE LAST E-MAIL DID NOT MAKE ANSY SENSE Best Regards, Andrew ----- Original Message ----- From: Andrew To: Discussion list for ICCAVR and ICCtiny Users. You do NOT needtosubscribeto icc-announce if you are a member of this. Sent: Tuesday, December 04, 2007 7:00 PM Subject: Re: [Icc-avr] ICCARV Bootloader Hi all, I will give the MegaLoad ago, if i have any problems i will let you now. NOTE; Thanks to everybody for all there help and advice, it is much appreciated. Since i have been on the mailing list i have had allot of very helpful advice. Regarding the bootloader ; I know if I can select its size in the fuses and this much then take up x amount of EPROM ( I am guessing, I am have not had chance to read any of the app notes yet) Best Regards, Andrew - From: John Baraclough To: Discussion list for ICCAVR and ICCtiny Users. You do NOT need tosubscribe to icc-announce if you are a member of this. Sent: Tuesday, December 04, 2007 3:38 PM Subject: Re: [Icc-avr] ICCARV Bootloader Sylvain has one including the PC front end at http://www.microsyl.com/. Just click on the MegaLoad link. All the best for now, John At 13:28 04/12/2007, you wrote: Hi, I have an AVR 128 and i need to try and make a bootloader for it, but i have no idea where to start can some sombody direct me to some datasheets or sample code please. For the ICCAVR compiler Andy ---------------------------------------------------------------------------- _______________________________________________ Icc-avr mailing list Icc-avr@imagecraft.com http://dragonsgate.net/mailman/listinfo/icc-avr ------------------------------------------------------------------------------ _______________________________________________ Icc-avr mailing list Icc-avr@imagecraft.com http://dragonsgate.net/mailman/listinfo/icc-avr -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20071204/6ece38b1/attachment.html From rodney at junipersys.com Tue Dec 4 12:38:10 2007 From: rodney at junipersys.com (Rodney Pearson) Date: Tue Dec 4 12:51:52 2007 Subject: [Icc-avr] ICCARV Bootloader In-Reply-To: References: <200712011930.lB1JUYsR044858@dragonsgate2.imagecraft.com> Message-ID: Andrew - The bootloader will actually reside in the upper Flash address space (set in compiler options). You will also need to set this size in the fuse bits... You can also redirect the reset vector to point to your bootloader instead of address 0x0000 in Flash so that the bootloader can run on power-on/reset. There is no impact on EEPROM when you use a bootloader - you are able to read/write to it as normal to address you desire. 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 Andrew Sent: Tuesday, December 04, 2007 12:15 PM To: Discussion list for ICCAVR and ICCtiny Users. You do NOT needtosubscribeto icc-announce if you are a member of this. Subject: Re: [Icc-avr] ICCARV Bootloader Hi all, I will give the MegaLoad ago, if i have any problems i will let you now. NOTE; Thanks to everybody for all there help and advice, it is much appreciated. Since i have been on the mailing list i have had allot of very helpful advice. Regarding the bootloader ; I know if I can select its size in the fuses and this much then take up x amount of EPROM ( I am guessing, I am have not had chance to read any of the app notes yet). SO my question is that when I address the EPROM i.e to save variables can I still go from address 0 to the end? Or does the complier not adjust for this, thus starting at address 0 would write over the bootloader. Best Regards, Andrew ----- Original Message ----- From: John Baraclough To: Discussion list for ICCAVR and ICCtiny Users. You do NOT need tosubscribe to icc-announce if you are a member of this. Sent: Tuesday, December 04, 2007 3:38 PM Subject: Re: [Icc-avr] ICCARV Bootloader Sylvain has one including the PC front end at http://www.microsyl.com/. Just click on the MegaLoad link. All the best for now, John At 13:28 04/12/2007, you wrote: Hi, I have an AVR 128 and i need to try and make a bootloader for it, but i have no idea where to start can some sombody direct me to some datasheets or sample code please. For the ICCAVR compiler Andy ________________________________ _______________________________________________ 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/20071204/fb7707de/attachment.html From pr at income.cz Wed Dec 5 00:48:03 2007 From: pr at income.cz (=?iso-8859-2?Q?Pavel_Rev=E1k?=) Date: Wed Dec 5 01:02:33 2007 Subject: [Icc-avr] rampz / elpm problem Message-ID: we buy icc7, and we have problems in migrating from icc6 (before we using in our project ATMEGA128, now 256) on AT MEA2561 and icc7, when I use const data in program memmory and accessing it, compiler never set RAMPZ register before reading data from program memmory using ELPM instruction and read data from bad address, because register RAMPZ has a bad value. I using compiler v7.14b and for compilation I have these switches: "-Mavr_extended -Wf-str_in_flash -Wf-use_elpm" thanks for help. Palo Revak. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20071205/97d91588/attachment.html From sl at ecpower.dk Wed Dec 5 01:05:26 2007 From: sl at ecpower.dk (Steven Lose) Date: Wed Dec 5 01:24:16 2007 Subject: SV: [Icc-avr] rampz / elpm problem References: Message-ID: <072D96786BFC014AAEBA9EB07A8070EA308854@seattle.ecpower.dk> Hi Palo. Which version of ICC 7 are you using? If you are using the latest, be aware of the new __flash keyword. 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 Pavel Rev?k Sendt: 5. december 2007 09:48 Til: icc-avr@imagecraft.com Emne: [Icc-avr] rampz / elpm problem we buy icc7, and we have problems in migrating from icc6 (before we using in our project ATMEGA128, now 256) on AT MEA2561 and icc7, when I use const data in program memmory and accessing it, compiler never set RAMPZ register before reading data from program memmory using ELPM instruction and read data from bad address, because register RAMPZ has a bad value. I using compiler v7.14b and for compilation I have these switches: "-Mavr_extended -Wf-str_in_flash -Wf-use_elpm" thanks for help. Palo Revak. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20071205/c016e28d/attachment-0001.html From pr at income.cz Wed Dec 5 02:23:22 2007 From: pr at income.cz (=?iso-8859-1?Q?Pavel_Rev=E1k?=) Date: Wed Dec 5 02:37:44 2007 Subject: [Icc-avr] rampz / elpm problem In-Reply-To: <072D96786BFC014AAEBA9EB07A8070EA308854@seattle.ecpower.dk> References: <072D96786BFC014AAEBA9EB07A8070EA308854@seattle.ecpower.dk> Message-ID: on imagecraft.com pages is at this time only 7.14c for download and __flash support is in 7.15 and about __flash, we have in project more than 30000 lines, it is hard way to rewrite all :( ________________________________ From: icc-avr-bounces@imagecraft.com [mailto:icc-avr-bounces@imagecraft.com] On Behalf Of Steven Lose Sent: Wednesday, December 05, 2007 10:05 AM 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] rampz / elpm problem Hi Palo. Which version of ICC 7 are you using? If you are using the latest, be aware of the new __flash keyword. 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 Pavel Rev?k Sendt: 5. december 2007 09:48 Til: icc-avr@imagecraft.com Emne: [Icc-avr] rampz / elpm problem we buy icc7, and we have problems in migrating from icc6 (before we using in our project ATMEGA128, now 256) on AT MEA2561 and icc7, when I use const data in program memmory and accessing it, compiler never set RAMPZ register before reading data from program memmory using ELPM instruction and read data from bad address, because register RAMPZ has a bad value. I using compiler v7.14b and for compilation I have these switches: "-Mavr_extended -Wf-str_in_flash -Wf-use_elpm" thanks for help. Palo Revak. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20071205/f150a1d3/attachment.html From j_baraclough at zetnet.co.uk Wed Dec 5 08:27:29 2007 From: j_baraclough at zetnet.co.uk (John Baraclough) Date: Wed Dec 5 08:41:07 2007 Subject: [Icc-avr] rampz / elpm problem In-Reply-To: References: Message-ID: Hi Palo, You must manage the RAMPZ register yourself. This is from the help file: ELPM and RAMPZ To access Flash memory beyond 64K bytes (such as on an M103, M128x, or M256x), the ELPM instruction must be used in conjunction with setting the RAMPZ bit to 1, 2, or 3. The "Use ELPM" option in Compiler Options: Target is enabled for all these devices. Unfortunately, to support automatic switching of RAMPZ would require (a) the flash memory pointer size to be greater than 16 bits and (b) greater usage of data and code space. Therefore, you must manage RAMPZ explicitly. HTH John At 08:48 05/12/2007, you wrote: >Content-class: urn:content-classes:message >Content-Type: multipart/alternative; > boundary="----_=_NextPart_001_01C8371B.8C5D1523" > >we buy icc7, and we have problems in migrating from icc6 (before we >using in our project ATMEGA128, now 256) >on AT MEA2561 and icc7, when I use const data in program memmory and >accessing it, compiler never set RAMPZ register before reading data >from program memmory using ELPM instruction and read data from bad >address, because register RAMPZ has a bad value. >I using compiler v7.14b and for compilation I have these switches: >"-Mavr_extended -Wf-str_in_flash -Wf-use_elpm" >thanks for help. >Palo Revak. >_______________________________________________ >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/20071205/65f8b5f3/attachment.html From richard at imagecraft.com Wed Dec 5 17:56:49 2007 From: richard at imagecraft.com (Richard) Date: Wed Dec 5 18:11:11 2007 Subject: [Icc-avr] Compiler price increase expected Jan 01, 2008. Order now... Message-ID: <200712060211.lB62B88a003641@dragonsgate2.imagecraft.com> We expect to increase the list prices of the compilers in 2008. Order now to take advantage of the current lower prices. // 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 benra at imt.liu.se Thu Dec 6 00:49:21 2007 From: benra at imt.liu.se (Bengt Ragnemalm) Date: Thu Dec 6 01:02:59 2007 Subject: [Icc-avr] Single step in Studio Message-ID: <002301c837e4$e5a13e40$b160ec82@Shagrat> I have problems with that if I single step, I many times have to press single step more than once to make Studio advance to the next line. I searched for this problem at AVRfreaks but did only found one very old unanswered post. Have this something to do with ICCAVR? Can I get rid of it? I think this have come and gone with different versions of Stuidio. Now I use the latest, 4.13 SP1. Best regards Bengt ________________________________________________________________ Bengt Ragnemalm Tel +46 13 22 24 97 Research engineer FAX: +46 13 10 19 02 Link?pings Universitet mailto:bengt.ragnemalm@imt.liu.se Inst. f?r Medicinsk Teknik Internet: http://www.imt.liu.se S-581 85 Link?ping SWEDEN -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20071206/53533134/attachment.html From richard-lists at imagecraft.com Thu Dec 6 01:17:07 2007 From: richard-lists at imagecraft.com (Richard) Date: Thu Dec 6 01:31:33 2007 Subject: [Icc-avr] Single step in Studio In-Reply-To: <002301c837e4$e5a13e40$b160ec82@Shagrat> References: <002301c837e4$e5a13e40$b160ec82@Shagrat> Message-ID: <200712060931.lB69VS1F007174@dragonsgate2.imagecraft.com> An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20071206/2f1e187a/attachment.html From benra at imt.liu.se Thu Dec 6 02:26:36 2007 From: benra at imt.liu.se (Bengt Ragnemalm) Date: Thu Dec 6 02:40:20 2007 Subject: SV: [Icc-avr] Single step in Studio In-Reply-To: <200712060931.lB69VS1F007174@dragonsgate2.imagecraft.com> References: <002301c837e4$e5a13e40$b160ec82@Shagrat> <200712060931.lB69VS1F007174@dragonsgate2.imagecraft.com> Message-ID: <004f01c837f2$7bf164d0$b160ec82@Shagrat> I understand what you mean. A for loop have in that case three ?instructions?. But that doesn?t change anything. While debugging we want the step button to execute exactly one line of C code. /Bengt _____ Fr?n: icc-avr-bounces@imagecraft.com [mailto:icc-avr-bounces@imagecraft.com] F?r Richard Skickat: den 6 december 2007 10:17 Till: benra@imt.liu.se; Discussion list for ICCAVR and ICCtiny Users. You do NOT need tosubscribe to icc-announce if you are a member of this.; 'Discussion list for ICCAVR and ICCtiny Users. You do NOT needtosubscribeto icc-announce if you are a member of this.' ?mne: Re: [Icc-avr] Single step in Studio Some C statements may in fact have multiple "steps." In particular, the top of for loop, or function entry { At 12:49 AM 12/6/2007, Bengt Ragnemalm wrote: I have problems with that if I single step, I many times have to press single step more than once to make Studio advance to the next line. I searched for this problem at AVRfreaks but did only found one very old unanswered post. Have this something to do with ICCAVR? Can I get rid of it? I think this have come and gone with different versions of Stuidio. Now I use the latest, 4.13 SP1. // richard (This email is for mailing lists. To reach me directly, please use richard at imagecraft.com) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20071206/9d9c95a4/attachment.html From richard-lists at imagecraft.com Thu Dec 6 03:58:06 2007 From: richard-lists at imagecraft.com (Richard) Date: Thu Dec 6 04:12:28 2007 Subject: [Icc-avr] Re: [Icc-announce] ICCV7 for AVR V.715 released In-Reply-To: <200712031042.lB3Ag30Q062801@dragonsgate2.imagecraft.com> References: <200712031042.lB3Ag30Q062801@dragonsgate2.imagecraft.com> Message-ID: <200712061212.lB6CCQHv009216@dragonsgate2.imagecraft.com> 7.15 was recalled due to some errors crept into the type checking code. The actual code for __flash support is working well, but we want to add more type checking code to detect error cases between __flash and non flash assignment, parameter etc. Unfortunately, existing working code were broken. Sorry about that. Please, if you have some big projects, please try 7.15 RC1: http://www.imagecraft.com/pub/iccv7avr_v715_rc1.exe Just enable the "const as __flash" checkbox and your existing projects should work as before. Much appreciated. You can install 7.15 in a separate directory. Your current license will be used. Thanks. At 02:27 AM 12/3/2007, Richard wrote: > From the readme: > >V7.15 - Dec 3rd, 2007 > - Added __flash keyword. Use it to refer to objects or pointers in the > flash space. > > IDE > - [AppBudiler ] Added Tiny24, Tiny25, M324, M325, M324P, M325P > M3250, M3250P, M329, M3290, M3290P > - Added Project->Options->Compiler->"Treat const as __flash" for > backward compatibility. If the checkbox is selected > > -Wf-const_is_flash -DCONST="" > are added to the compiler flag. > Compiler > - Added support for __flash > - If the command line flag -const_is_flash is used, then "const" is > treated as the same as __flash > > Header Files > - Added _const.h, with defines CONST and FLASH. > > >// 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-announce mailing list >Icc-announce@imagecraft.com >http://dragonsgate.net/mailman/listinfo/icc-announce // richard (This email is for mailing lists. To reach me directly, please use richard at imagecraft.com) From Albert.vanVeen at pertronic.co.nz Thu Dec 6 10:57:33 2007 From: Albert.vanVeen at pertronic.co.nz (Albert vanVeen) Date: Thu Dec 6 11:11:24 2007 Subject: [Icc-avr] Single step in Studio In-Reply-To: <004f01c837f2$7bf164d0$b160ec82@Shagrat> References: <002301c837e4$e5a13e40$b160ec82@Shagrat><200712060931.lB69VS1F007174@dragonsgate2.imagecraft.com> <004f01c837f2$7bf164d0$b160ec82@Shagrat> Message-ID: I wouldn't see it that way: if (cond) then a= b; will obviously be 2 'single' steps, maybe 3 if the condition is complex. Perfectly logical. Albert. ________________________________ From: icc-avr-bounces@imagecraft.com [mailto:icc-avr-bounces@imagecraft.com] On Behalf Of Bengt Ragnemalm Sent: Thursday, December 06, 2007 11:27 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] Single step in Studio I understand what you mean. A for loop have in that case three "instructions". But that doesn't change anything. While debugging we want the step button to execute exactly one line of C code. /Bengt ________________________________ Fr?n: icc-avr-bounces@imagecraft.com [mailto:icc-avr-bounces@imagecraft.com] F?r Richard Skickat: den 6 december 2007 10:17 Till: benra@imt.liu.se; Discussion list for ICCAVR and ICCtiny Users. You do NOT need tosubscribe to icc-announce if you are a member of this.; 'Discussion list for ICCAVR and ICCtiny Users. You do NOT needtosubscribeto icc-announce if you are a member of this.' ?mne: Re: [Icc-avr] Single step in Studio Some C statements may in fact have multiple "steps." In particular, the top of for loop, or function entry { At 12:49 AM 12/6/2007, Bengt Ragnemalm wrote: I have problems with that if I single step, I many times have to press single step more than once to make Studio advance to the next line. I searched for this problem at AVRfreaks but did only found one very old unanswered post. Have this something to do with ICCAVR? Can I get rid of it? I think this have come and gone with different versions of Stuidio. Now I use the latest, 4.13 SP1. // richard (This email is for mailing lists. To reach me directly, please use richard at imagecraft.com) Scanned by Bizo EmailFilter -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20071207/7d9256e4/attachment-0001.html From rohde at aragon-interactive.de Fri Dec 7 03:05:06 2007 From: rohde at aragon-interactive.de (Roman Rohde) Date: Fri Dec 7 03:18:48 2007 Subject: [Icc-avr] program areas Message-ID: how could i use the _lit_start and _lit_end addresses in my code for boundary checking? From johan at edab.nu Fri Dec 7 03:36:34 2007 From: johan at edab.nu (=?iso-8859-15?Q?Johan_Wallstr=F6m?=) Date: Fri Dec 7 03:46:59 2007 Subject: [Icc-avr] Bootloader size calculation References: Message-ID: <004f01c838c5$6c17f000$64026e0a@EDAB1> Hi! I just wanted mention that there is still a problem with the mem usage calculation in some situations. Here's the console output: C:\iccv7avr\bin\imakew -f BL88.mak iccavr -o BL88 -g -e:0x2000 -Wl-W -ucrtboot8k.o -bvector:0x1e00.0x2000 -bfunc_lit:0x1e34.0x2000 -dram_end:0x4ff -bdata:0x100.0x4ff -dhwstk_size:32 -beeprom:0.512 -fihx_coff -beeprom:0.512, -btext:5130.7680, -bbootloader:7712.8192 -S2 @BL88.lk -lcavrgr Device 9336856% full. Done. Fri Dec 07 12:34:53 2007 Cheers Johan Wallstr?m From jh.bodin at telia.com Fri Dec 7 04:01:41 2007 From: jh.bodin at telia.com (Johan H. Bodin) Date: Fri Dec 7 04:15:19 2007 Subject: [Icc-avr] Bootloader size calculation In-Reply-To: <004f01c838c5$6c17f000$64026e0a@EDAB1> References: <004f01c838c5$6c17f000$64026e0a@EDAB1> Message-ID: <47593625.9030306@telia.com> Johan Wallstr?m wrote: > Device 9336856% full. > Done. Fri Dec 07 12:34:53 2007 That number is probably the code memory usage before the code compressor kicks in :-) MVH Johan Bodin From johan at edab.nu Fri Dec 7 04:16:39 2007 From: johan at edab.nu (=?iso-8859-15?Q?Johan_Wallstr=F6m?=) Date: Fri Dec 7 04:26:56 2007 Subject: [Icc-avr] Bootloader size calculation References: <004f01c838c5$6c17f000$64026e0a@EDAB1> <47593625.9030306@telia.com> Message-ID: <000d01c838cb$050b6ad0$64026e0a@EDAB1> Hehe, of course! Good job by the compressor fitting that in! ----- Original Message ----- From: "Johan H. Bodin" To: "Discussion list for ICCAVR and ICCtiny Users. You do NOT need tosubscribe to icc-announce if you are a member of this." Sent: Friday, December 07, 2007 1:01 PM Subject: Re: [Icc-avr] Bootloader size calculation > Johan Wallstr?m wrote: >> Device 9336856% full. >> Done. Fri Dec 07 12:34:53 2007 > > That number is probably the code memory usage before the code compressor > kicks in :-) > > > MVH > Johan Bodin > > _______________________________________________ > Icc-avr mailing list > Icc-avr@imagecraft.com > http://dragonsgate.net/mailman/listinfo/icc-avr > > From rodney at junipersys.com Fri Dec 7 06:33:50 2007 From: rodney at junipersys.com (Rodney Pearson) Date: Fri Dec 7 06:47:59 2007 Subject: [Icc-avr] program areas In-Reply-To: References: Message-ID: Hi Roman - Could you please be more specific on what you are trying to accomplish. The LIT section refers to Flash-only CONST data (integer & floating-point). Why would you desire to use it in boundary checking? Normally that is reserved for RAM data, not CONST data in flash... Cheers! Rodney Pearson Software Engineer Juniper Systems, Inc. www.junipersys.com -----Original Message----- From: icc-avr-bounces@imagecraft.com [mailto:icc-avr-bounces@imagecraft.com] On Behalf Of Roman Rohde Sent: Friday, December 07, 2007 4:05 AM To: icc-avr@imagecraft.com Subject: [Icc-avr] program areas how could i use the _lit_start and _lit_end addresses in my code for boundary checking? _______________________________________________ Icc-avr mailing list Icc-avr@imagecraft.com http://dragonsgate.net/mailman/listinfo/icc-avr From j_baraclough at zetnet.co.uk Fri Dec 7 07:49:42 2007 From: j_baraclough at zetnet.co.uk (John Baraclough) Date: Fri Dec 7 08:03:32 2007 Subject: [Icc-avr] program areas In-Reply-To: References: Message-ID: Simple answer is that you can't. Those symbols are created by the linker and their values aren't known at compile time, so your code cannot use them. HTH. John At 11:05 07/12/2007, you wrote: >how could i use the > >_lit_start > >and > >_lit_end > >addresses in my code for boundary checking? > >_______________________________________________ >Icc-avr mailing list >Icc-avr@imagecraft.com >http://dragonsgate.net/mailman/listinfo/icc-avr From richard-lists at imagecraft.com Fri Dec 7 12:47:32 2007 From: richard-lists at imagecraft.com (Richard) Date: Fri Dec 7 13:02:04 2007 Subject: [Icc-avr] program areas In-Reply-To: References: Message-ID: <200712072102.lB7L1wlJ028058@dragonsgate2.imagecraft.com> Not quite, __end is created by the linker, but __..start is in the startup file. In any case, you can do extern unsigned _lit_start, _lit_end; // data type does not matter if (0x???? < &_lit_start) // ... i.e. use & address of to get their addresses, as per usual. At 07:49 AM 12/7/2007, John Baraclough wrote: >Simple answer is that you can't. Those symbols are created by the >linker and their values aren't known at compile time, so your code >cannot use them. > >HTH. > >John > > >At 11:05 07/12/2007, you wrote: >>how could i use the >> >>_lit_start >> >>and >> >>_lit_end >> >>addresses in my code for boundary checking? // richard (This email is for mailing lists. To reach me directly, please use richard at imagecraft.com) From r.rohde at indas.de Sat Dec 8 05:32:57 2007 From: r.rohde at indas.de (Roman Rohde) Date: Sat Dec 8 05:46:48 2007 Subject: [Icc-avr] program areas In-Reply-To: <200712072102.lB7L1wlJ028058@dragonsgate2.imagecraft.com> References: <200712072102.lB7L1wlJ028058@dragonsgate2.imagecraft.com> Message-ID: <475A9D09.3050004@indas.de> great! I will try it. Roman > Not quite, __end is created by the linker, but __..start is in the > startup file. In any case, you can do > > extern unsigned _lit_start, _lit_end; // data type does not matter > > > if (0x???? < &_lit_start) // > ... > > i.e. use & address of to get their addresses, as per usual. > > At 07:49 AM 12/7/2007, John Baraclough wrote: >> Simple answer is that you can't. Those symbols are created by the >> linker and their values aren't known at compile time, so your code >> cannot use them. >> >> HTH. >> >> John >> >> >> At 11:05 07/12/2007, you wrote: >>> how could i use the >>> >>> _lit_start >>> >>> and >>> >>> _lit_end >>> >>> addresses in my code for boundary checking? > > // 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 r.rohde at indas.de Sat Dec 8 07:51:14 2007 From: r.rohde at indas.de (Roman Rohde) Date: Sat Dec 8 08:05:13 2007 Subject: [Icc-avr] program areas In-Reply-To: <200712072102.lB7L1wlJ028058@dragonsgate2.imagecraft.com> References: <200712072102.lB7L1wlJ028058@dragonsgate2.imagecraft.com> Message-ID: <475ABD72.3010808@indas.de> a simple example: // lit.c const unsigned char msg[] = "abc."; extern unsigned _lit_start, _lit_end; void main(void) { const unsigned char *ptr; if (ptr < (const unsigned char *)_lit_start) { ptr = msg; } if (ptr >= (const unsigned char *)_lit_end) { ptr = msg; } // ... } from my .mp file: Addr Global Symbol ----- -------------------------------- 0054 __lit_start 0054 _msg 0059 __lit_end from .s file _main:: .dbline -1 .dbline 4 ; const unsigned char msg[] = "abc."; ; extern unsigned _lit_start, _lit_end; ; ; void main(void) { .dbline 6 ; const unsigned char *ptr; ; if (ptr < (const unsigned char *)_lit_start) { lds R2,__lit_start ;;; should be ldi R2, 0x54 <================= lds R3,__lit_start+1 ;;; should be ldi R3, 0x00 <================= cp R16,R2 cpc R17,R3 brsh L2 > Not quite, __end is created by the linker, but __..start is in the > startup file. In any case, you can do > > extern unsigned _lit_start, _lit_end; // data type does not matter > > > if (0x???? < &_lit_start) // > ... > > i.e. use & address of to get their addresses, as per usual. > > At 07:49 AM 12/7/2007, John Baraclough wrote: >> Simple answer is that you can't. Those symbols are created by the >> linker and their values aren't known at compile time, so your code >> cannot use them. >> >> HTH. >> >> John >> >> >> At 11:05 07/12/2007, you wrote: >>> how could i use the >>> >>> _lit_start >>> >>> and >>> >>> _lit_end >>> >>> addresses in my code for boundary checking? > > // 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 Sat Dec 8 12:13:52 2007 From: richard-lists at imagecraft.com (Richard) Date: Sat Dec 8 12:28:22 2007 Subject: [Icc-avr] program areas In-Reply-To: <475ABD72.3010808@indas.de> References: <200712072102.lB7L1wlJ028058@dragonsgate2.imagecraft.com> <475ABD72.3010808@indas.de> Message-ID: <200712082028.lB8KSKqQ039755@dragonsgate2.imagecraft.com> Read my msg carefully please. I said use & the address of operator. At 07:51 AM 12/8/2007, Roman Rohde wrote: >a simple example: > >// lit.c >const unsigned char msg[] = "abc."; >extern unsigned _lit_start, _lit_end; > >void main(void) { > const unsigned char *ptr; > if (ptr < (const unsigned char *)_lit_start) { > ptr = msg; > } > if (ptr >= (const unsigned char *)_lit_end) { > ptr = msg; > } > // ... >} > // richard (This email is for mailing lists. To reach me directly, please use richard at imagecraft.com) From Albert.vanVeen at pertronic.co.nz Sun Dec 9 12:16:48 2007 From: Albert.vanVeen at pertronic.co.nz (Albert vanVeen) Date: Sun Dec 9 12:30:40 2007 Subject: [Icc-avr] Bootloader size calculation In-Reply-To: <004f01c838c5$6c17f000$64026e0a@EDAB1> References: <004f01c838c5$6c17f000$64026e0a@EDAB1> Message-ID: 9 million procent full; how many chips do you need for that? The obvious problem with a missing decimal point is: where was it before losing it: 0.933, 9.33 or 93.3? I suppose that is your real question. My question is: where is "nu"? Albert. -----Original Message----- From: icc-avr-bounces@imagecraft.com [mailto:icc-avr-bounces@imagecraft.com] On Behalf Of Johan Wallstr?m Sent: Saturday, December 08, 2007 12:37 AM To: Discussion list for ICCAVR and ICCtiny Users. You do NOT needtosubscribeto icc-announce if you are a member of this. Subject: [Icc-avr] Bootloader size calculation Hi! I just wanted mention that there is still a problem with the mem usage calculation in some situations. Here's the console output: C:\iccv7avr\bin\imakew -f BL88.mak iccavr -o BL88 -g -e:0x2000 -Wl-W -ucrtboot8k.o -bvector:0x1e00.0x2000 -bfunc_lit:0x1e34.0x2000 -dram_end:0x4ff -bdata:0x100.0x4ff -dhwstk_size:32 -beeprom:0.512 -fihx_coff -beeprom:0.512, -btext:5130.7680, -bbootloader:7712.8192 -S2 @BL88.lk -lcavrgr Device 9336856% full. Done. Fri Dec 07 12:34:53 2007 Cheers Johan Wallstr?m _______________________________________________ Icc-avr mailing list Icc-avr@imagecraft.com http://dragonsgate.net/mailman/listinfo/icc-avr Scanned by Bizo Email Filter From johan at edab.nu Sun Dec 9 15:12:00 2007 From: johan at edab.nu (johan@edab.nu) Date: Sun Dec 9 15:27:56 2007 Subject: [Icc-avr] Bootloader size calculation Message-ID: <200712092312.lB9NC0LY005039@gigamail.giganet.se> I only got a few bytes spare in it =) By the way, it's a bit of a complicated setup in my BL, since I had too much stuff that was supposed to fit in there, so parts of the bootloader resides outside of the bootloader area (it works over a proprietary software emulated bus system which takes some space). We reside in Sweden, although .nu is assigned to the island state of Niue. "The domain is particularly popular in Sweden, Denmark, Norway, the Netherlands and Belgium, as nu is the word for "now" in Swedish, Danish and Dutch. Partially owing to restrictive domain rules for the ccTLD assigned to Sweden, .se, .nu was used for creative marketing of websites" Cheers Johan Wallstr?m On 2007-12-09 Albert vanVeen wrote: 9 million procent full; how many chips do you need for that? >The obvious problem with a missing decimal point is: where was it before losing it: 0.933, 9.33 or 93.3? >I suppose that is your real question. > >My question is: where is "nu"? >Albert. > > >-----Original Message----- >From: icc-avr-bounces@imagecraft.com [mailto:icc-avr-bounces@imagecraft.com] On Behalf Of Johan Wallstr?m >Sent: Saturday, December 08, 2007 12:37 AM >To: Discussion list for ICCAVR and ICCtiny Users. You do NOT needtosubscribeto icc-announce if you are a member of this. >Subject: [Icc-avr] Bootloader size calculation > >Hi! > >I just wanted mention that there is still a problem with the mem usage calculation in some situations. Here's the console output: > > >C:\iccv7avr\bin\imakew -f BL88.mak >iccavr -o >BL88 -g -e:0x2000 -Wl-W -ucrtboot8k.o -bvector:0x1e00.0x2000 -bfunc_lit:0x1e34.0x2000 > -dram_end:0x4ff -bdata:0x100.0x4ff -dhwstk_size:32 -beeprom:0.512 -fihx_coff > -beeprom:0.512, -btext:5130.7680, -bbootloader:7712.8192 -S2 >@BL88.lk -lcavrgr >Device 9336856% full. >Done. Fri Dec 07 12:34:53 2007 > > >Cheers >Johan Wallstr?m > > > >_______________________________________________ >Icc-avr mailing list >Icc-avr@imagecraft.com >http://dragonsgate.net/mailman/listinfo/icc-avr > >Scanned by Bizo Email Filter > > From rohde at aragon-interactive.de Mon Dec 10 02:43:21 2007 From: rohde at aragon-interactive.de (Roman Rohde) Date: Mon Dec 10 02:57:07 2007 Subject: [Icc-avr] program areas In-Reply-To: <200712082028.lB8KSKqQ039755@dragonsgate2.imagecraft.com> References: <200712072102.lB7L1wlJ028058@dragonsgate2.imagecraft.com> <475ABD72.3010808@indas.de> <200712082028.lB8KSKqQ039755@dragonsgate2.imagecraft.com> Message-ID: could I create a special lit area that have the exact boundarys of my const data? // Project -> Options... -> Target -> Other Options: // -bmsg:0x00100.0x01000 #pragma lit:msg(abs) const char msg1[] = "message1"; const char msg2[] = "message2"; // ... #pragma lit:lit > Read my msg carefully please. I said use & the address of operator. Sorry, I've overlooked it. From j_baraclough at zetnet.co.uk Mon Dec 10 04:07:06 2007 From: j_baraclough at zetnet.co.uk (John Baraclough) Date: Mon Dec 10 04:20:58 2007 Subject: [Icc-avr] program areas In-Reply-To: References: <200712072102.lB7L1wlJ028058@dragonsgate2.imagecraft.com> <475ABD72.3010808@indas.de> <200712082028.lB8KSKqQ039755@dragonsgate2.imagecraft.com> Message-ID: Hi Roman, I'm not sure what you are trying to do here, but you must be careful that the area 'msg' doesn't overlap with any areas that the compiler wishes to use. There is a warning in the help file about this. Also see a thread from October 2005 entitled 'Checksum' which covers this subject exactly. It's in the archives. HTH All the best for now, John At 10:43 10/12/2007, you wrote: >could I create a special lit area that have the exact boundarys of my >const data? > >// Project -> Options... -> Target -> Other Options: >// -bmsg:0x00100.0x01000 >#pragma lit:msg(abs) > const char msg1[] = "message1"; > const char msg2[] = "message2"; > // ... >#pragma lit:lit > > > >>Read my msg carefully please. I said use & the address of operator. >Sorry, I've overlooked it. > >_______________________________________________ >Icc-avr mailing list >Icc-avr@imagecraft.com >http://dragonsgate.net/mailman/listinfo/icc-avr From benra at imt.liu.se Mon Dec 10 04:09:51 2007 From: benra at imt.liu.se (Bengt Ragnemalm) Date: Mon Dec 10 04:23:23 2007 Subject: SV: [Icc-avr] Single step in Studio In-Reply-To: References: <002301c837e4$e5a13e40$b160ec82@Shagrat><200712060931.lB69VS1F007174@dragonsgate2.imagecraft.com><004f01c837f2$7bf164d0$b160ec82@Shagrat> Message-ID: <003501c83b25$91bb0240$b160ec82@Shagrat> It do make some sense that a C line that includes several instructions or evaluations (or what ever the right name may be) as it would be able to follow the value of the variables as each part of the line is executed. But in the same time it is not possible to know what part of the code is executed after each step so I still not understand why Studio is made like this. If I want to follow the underlying code in a C-line, I switch the window to assembler. Is it only me that think this is unnormal? In a technical view I agree that the behaviour is perfectly logical but I do not think it is user friendly. You can just as easily say that it is totally illogical that a function that should do single step does not execute one ?step? in my C-code. (If I am free to define a step as one line ) I must admit though that the right name for F11 is ?Step into?, not single step. This is not necessarily the same. This is from Studio User guide: ?Single step over the current instruction or source statement?. OK, so what is a source statement? Is for example ?for (x=0;x<1;x++)? one statement? This is also from Studio User Guide: ?The Trace Into command in the Debug menu executes one instruction? Hm, now it is suddenly one instruction. /Bengt _____ Fr?n: icc-avr-bounces@imagecraft.com [mailto:icc-avr-bounces@imagecraft.com] F?r Albert vanVeen Skickat: den 6 december 2007 19:58 Till: benra@imt.liu.se; Discussion list for ICCAVR and ICCtiny Users. You do NOT needtosubscribeto icc-announce if you are a member of this. ?mne: RE: [Icc-avr] Single step in Studio I wouldn't see it that way: if (cond) then a= b; will obviously be 2 'single' steps, maybe 3 if the condition is complex. Perfectly logical. Albert. _____ From: icc-avr-bounces@imagecraft.com [mailto:icc-avr-bounces@imagecraft.com] On Behalf Of Bengt Ragnemalm Sent: Thursday, December 06, 2007 11:27 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] Single step in Studio I understand what you mean. A for loop have in that case three ?instructions?. But that doesn?t change anything. While debugging we want the step button to execute exactly one line of C code. /Bengt _____ Fr?n: icc-avr-bounces@imagecraft.com [mailto:icc-avr-bounces@imagecraft.com] F?r Richard Skickat: den 6 december 2007 10:17 Till: benra@imt.liu.se; Discussion list for ICCAVR and ICCtiny Users. You do NOT need tosubscribe to icc-announce if you are a member of this.; 'Discussion list for ICCAVR and ICCtiny Users. You do NOT needtosubscribeto icc-announce if you are a member of this.' ?mne: Re: [Icc-avr] Single step in Studio Some C statements may in fact have multiple "steps." In particular, the top of for loop, or function entry { At 12:49 AM 12/6/2007, Bengt Ragnemalm wrote: I have problems with t