From ira at extrasensory.com Thu Aug 2 09:00:25 2007 From: ira at extrasensory.com (Ira) Date: Thu Aug 2 09:11:59 2007 Subject: [Icc-avr] Is this a bug? Message-ID: <0MKp8S-1IGd6M2CCO-0005qi@mrelay.perfora.net> I wrote some code that looks somewhat like this and it didn't work because, well, let's see the code first. So my problem turned out to be that temp.c[3] became not empty and adding "temp.c[3] = 0;" and "foo.c[3] = 0;" I realize that using a union like that is very target and maybe even compiler specific but it works and it's a very easy way to implement what I want to do. What I don't understand is why when I declare "u temp", temp ends up containing random stuff. I thought that I read somewhere that variables are supposed to be initialized to 0. It always works right after I program the processor, it never works if I power the processor on and off and it occasionally works when I reset the processor. And even when it works, one it stops working, it will never start working again. It's astonishing how many subtle bugs can fit in a 200 line C program. union u { unsigned long l; char c[4]; } u foo; main(){ unsigned long i; i = 65000; while (1) { i = dosomestuff(); if (i > foo.l) dosomeotherstuff(); } } void intfunction(){ u temp; CLI(); temp.c[0] = a; temp.c[1] = b; temp.c[2] = c; if (temp.l < 55000){ SEI(); return; } foo.c[0] = temp.c[0]; foo.c[1] = temp.c[1]; foo.c[2] = temp.c[2]; SEI(); } From bobgardner at aol.com Thu Aug 2 09:12:13 2007 From: bobgardner at aol.com (bobgardner@aol.com) Date: Thu Aug 2 09:23:35 2007 Subject: [Icc-avr] Is this a bug? In-Reply-To: <0MKp8S-1IGd6M2CCO-0005qi@mrelay.perfora.net> References: <0MKp8S-1IGd6M2CCO-0005qi@mrelay.perfora.net> Message-ID: <8C9A33705BA0EA8-DA0-C75E@webmail-md06.sysops.aol.com> union u {? ? unsigned long l;? ? char c[4];? }? u foo;? In this example, u is the 'tag'. (says so in my ansi book that Richards buddy PJ wrote). I though you had to declare a variable using the word union and the tag and the union name... union u foo; or make 'union u' a typedef for u_t or something? I got confused by that lonely u out there in open by himself. Maybe the compiler did too! ________________________________________________________________________ AOL now offers free email to everyone. Find out more about what's free from AOL at AOL.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20070802/dd7c3269/attachment.html From MDipperstein at CalAmp.com Thu Aug 2 09:12:49 2007 From: MDipperstein at CalAmp.com (Michael Dipperstein) Date: Thu Aug 2 09:24:07 2007 Subject: [Icc-avr] Is this a bug? In-Reply-To: <0MKp8S-1IGd6M2CCO-0005qi@mrelay.perfora.net> Message-ID: Ira, I'm not sure what it is that you're trying to do, but only static variables are initialized to 0. temp is not a static variable. If you want it to be initialized to 0, you can declare it as static, declare it outside of the function, or explicitly initialize it. -Mike -----Original Message----- From: icc-avr-bounces@imagecraft.com [mailto:icc-avr-bounces@imagecraft.com] On Behalf Of Ira Sent: Thursday, August 02, 2007 9:00 AM To: icc-avr@imagecraft.com Subject: [Icc-avr] Is this a bug? I wrote some code that looks somewhat like this and it didn't work because, well, let's see the code first. So my problem turned out to be that temp.c[3] became not empty and adding "temp.c[3] = 0;" and "foo.c[3] = 0;" I realize that using a union like that is very target and maybe even compiler specific but it works and it's a very easy way to implement what I want to do. What I don't understand is why when I declare "u temp", temp ends up containing random stuff. I thought that I read somewhere that variables are supposed to be initialized to 0. It always works right after I program the processor, it never works if I power the processor on and off and it occasionally works when I reset the processor. And even when it works, one it stops working, it will never start working again. It's astonishing how many subtle bugs can fit in a 200 line C program. union u { unsigned long l; char c[4]; } u foo; main(){ unsigned long i; i = 65000; while (1) { i = dosomestuff(); if (i > foo.l) dosomeotherstuff(); } } void intfunction(){ u temp; CLI(); temp.c[0] = a; temp.c[1] = b; temp.c[2] = c; if (temp.l < 55000){ SEI(); return; } foo.c[0] = temp.c[0]; foo.c[1] = temp.c[1]; foo.c[2] = temp.c[2]; SEI(); } _______________________________________________ Icc-avr mailing list Icc-avr@imagecraft.com http://dragonsgate.net/mailman/listinfo/icc-avr From asyms at technosoft.co.uk Thu Aug 2 09:49:10 2007 From: asyms at technosoft.co.uk (Andy Syms) Date: Thu Aug 2 10:00:46 2007 Subject: [Icc-avr] Is this a bug? In-Reply-To: <0MKp8S-1IGd6M2CCO-0005qi@mrelay.perfora.net> Message-ID: > What I don't understand is why when I declare "u > temp", temp ends up containing random stuff. I thought that I read > somewhere that variables are supposed to be initialized to 0. Not when it's a local variable that's allocated on the stack. Andy From j_baraclough at zetnet.co.uk Thu Aug 2 10:22:55 2007 From: j_baraclough at zetnet.co.uk (John Baraclough) Date: Thu Aug 2 10:34:23 2007 Subject: [Icc-avr] Is this a bug? In-Reply-To: <0MKp8S-1IGd6M2CCO-0005qi@mrelay.perfora.net> References: <0MKp8S-1IGd6M2CCO-0005qi@mrelay.perfora.net> Message-ID: Hi Ira, The answer is NO and YES in that order. No, it's not a compiler bug. Yes, union storage is very compiler specific and very dangerous to use in the way you have done it. Be aware that there is no specification in C for how a variable is stored inside a union. The 'C' specification only guarantees that you will get back what you have written, when using the same types for both actions. It's possible (but very unlikely) that the storage format may change between different revisions of the same compiler and that can lead to disaster. Also your definition of the union is incorrect. In the way you have defined it the first 'u' is an identifier and not a type, so cannot be used as a type definition later. I'm not surprised it didn't work. You should have done it one of the following ways: union u { unsigned long l; char c[4]; } ; union u temp, foo; or typedef union { unsigned long l; char c[4]; } u; u temp, foo; but not both at the same time. Finally, since 'temp.c' is an 'array of char', you could use 'cstrcpy()' or 'strcpy()' to fill it and 'strcpy()' to copy it to 'foo.c'. That would ensure the integrity of the trailing 'NULL' in both cases. cstrcpy(temp.c, "abc"); // Assuming 'String in Flash only' is checked. or strcpy(temp.c, "abc"); // Assuming strings in RAM. then strcpy(foo.c, temp.c); HTH. All the best for now, John At 17:00 02/08/2007, you wrote: >I wrote some code that looks somewhat like this and it didn't work >because, well, let's see the code first. > >So my problem turned out to be that temp.c[3] became not empty and >adding "temp.c[3] = 0;" and "foo.c[3] = 0;" > >I realize that using a union like that is very target and maybe even >compiler specific but it works and it's a very easy way to implement >what I want to do. What I don't understand is why when I declare "u >temp", temp ends up containing random stuff. I thought that I read >somewhere that variables are supposed to be initialized to 0. It >always works right after I program the processor, it never works if >I power the processor on and off and it occasionally works when I >reset the processor. And even when it works, one it stops working, >it will never start working again. > >It's astonishing how many subtle bugs can fit in a 200 line C program. > >union u { > unsigned long l; > char c[4]; >} >u foo; > >main(){ > unsigned long i; > i = 65000; > while (1) { > > i = dosomestuff(); > if (i > foo.l) > dosomeotherstuff(); > } >} > >void intfunction(){ > u temp; > CLI(); > temp.c[0] = a; > temp.c[1] = b; > temp.c[2] = c; > if (temp.l < 55000){ > SEI(); > return; > } > foo.c[0] = temp.c[0]; > foo.c[1] = temp.c[1]; > foo.c[2] = temp.c[2]; > SEI(); >} > >_______________________________________________ >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/20070802/aef35c8b/attachment.html From ira at extrasensory.com Thu Aug 2 10:28:53 2007 From: ira at extrasensory.com (Ira) Date: Thu Aug 2 10:45:06 2007 Subject: [Icc-avr] Is this a bug? In-Reply-To: <8C9A33705BA0EA8-DA0-C75E@webmail-md06.sysops.aol.com> References: <0MKp8S-1IGd6M2CCO-0005qi@mrelay.perfora.net> <8C9A33705BA0EA8-DA0-C75E@webmail-md06.sysops.aol.com> Message-ID: <0MKpCa-1IGeYU2IMs-0006Vm@mrelay.perfora.net> At 09:12 AM 8/2/2007, you wrote: >I got confused by that lonely u out there in open by himself. Maybe >the compiler did too! Sorry, the code is upstairs and I don't remember the syntax correctly yet. The problem is not a syntax error. I think the next person got it when he said the declaration will not initialize the variable, a fact I was not aware of. The perils of learning a new language! Ira From ira at extrasensory.com Thu Aug 2 10:29:52 2007 From: ira at extrasensory.com (Ira) Date: Thu Aug 2 10:45:08 2007 Subject: [Icc-avr] Is this a bug? In-Reply-To: References: <0MKp8S-1IGd6M2CCO-0005qi@mrelay.perfora.net> Message-ID: <0MKpCa-1IGeYW2WsT-0006Vm@mrelay.perfora.net> At 09:12 AM 8/2/2007, you wrote: >I'm not sure what it is that you're trying to do, but only static >variables are initialized to 0. temp is not a static variable. If you >want it to be initialized to 0, you can declare it as static, declare it >outside of the function, or explicitly initialize it. OK, thanks for that. Another previously unknown rule to commit to memory. Ira From ira at extrasensory.com Thu Aug 2 12:11:12 2007 From: ira at extrasensory.com (Ira) Date: Thu Aug 2 12:22:48 2007 Subject: [Icc-avr] Is this a bug? In-Reply-To: References: <0MKp8S-1IGd6M2CCO-0005qi@mrelay.perfora.net> Message-ID: <0MKpCa-1IGg513kW6-0006XT@mrelay.perfora.net> At 10:22 AM 8/2/2007, you wrote: >Finally, since 'temp.c' is an 'array of char', you could use >'cstrcpy()' or 'strcpy()' to fill it and 'strcpy()' to copy it to >'foo.c'. That would ensure the integrity of the trailing 'NULL' in both cases. But for char[4] it's way faster to just copy the 4 elements individually as the overhead for the function call is more than the 4 lines of foo[n] = temp[n]. If it existed in more than one place in the code, maybe, but still for that short an array it's not clear it ever makes sense, does it? And to everyone else, thanks for the comments. It's all appreciated and hopefully I'll remember it and not make the same mistake again. If anyone wonders, my previous languages are Clipper and PIC assembly, neither of which can have problems like this. Ira From j_baraclough at zetnet.co.uk Thu Aug 2 13:08:04 2007 From: j_baraclough at zetnet.co.uk (John Baraclough) Date: Thu Aug 2 13:20:35 2007 Subject: [Icc-avr] Is this a bug? In-Reply-To: <0MKpCa-1IGg513kW6-0006XT@mrelay.perfora.net> References: <0MKp8S-1IGd6M2CCO-0005qi@mrelay.perfora.net> <0MKpCa-1IGg513kW6-0006XT@mrelay.perfora.net> Message-ID: Wow, that takes me back a bit. I remember using dBase under CPM in the early 80's. Data bases running on micros then were just a little different from today. As for PIC assembler, you couldn't choose a simpler instruction set with only 35 instructions. I only tinkered with the PIC16 series and always found the 256 byte segmentation irritating. Of course things move on don't they, and now I find the 64Kbyte Flash segmentation of the mega2560 equally irritating. ;-) Luckily, I don't have to work with any of this irritating stuff in anger any more, just do it for fun. All the best for now, John At 20:11 02/08/2007, you wrote: . . . >And to everyone else, thanks for the comments. It's all appreciated >and hopefully I'll remember it and not make the same mistake >again. If anyone wonders, my previous languages are Clipper and PIC >assembly, neither of which can have problems like this. From david_brown at hotpop.com Fri Aug 3 00:05:55 2007 From: david_brown at hotpop.com (David Brown) Date: Thu Aug 2 23:50:45 2007 Subject: [Icc-avr] Is this a bug? In-Reply-To: References: <0MKp8S-1IGd6M2CCO-0005qi@mrelay.perfora.net> Message-ID: <46B2D3D3.7080609@hotpop.com> John Baraclough wrote: > Hi Ira, > > The answer is NO and YES in that order. > > No, it's not a compiler bug. > > Yes, union storage is very compiler specific and very dangerous to use > in the way you have done it. Be aware that there is no specification in > C for how a variable is stored inside a union. The 'C' specification > only guarantees that you will get back what you have written, when using > the same types for both actions. It's possible (but *very unlikely*) > that the storage format may change between different revisions of the > same compiler and that can lead to disaster. > > Also your definition of the union is incorrect. In the way you have > defined it the first 'u' is an identifier and not a type, so cannot be > used as a type definition later. I'm not surprised it didn't work. You > should have done it one of the following ways: > > union u { > unsigned long l; > char c[4]; > } ; > > union u temp, foo; > > or > > typedef union { > unsigned long l; > char c[4]; > } u; > > u temp, foo; > > but not both at the same time. > > Finally, since 'temp.c' is an 'array of char', you could use 'cstrcpy()' > or 'strcpy()' to fill it and 'strcpy()' to copy it to 'foo.c'. That > would ensure the integrity of the trailing 'NULL' in both cases. > > > cstrcpy(temp.c, "abc"); // Assuming 'String in Flash only' is checked. > > or > > strcpy(temp.c, "abc"); // Assuming strings in RAM. > > then > > strcpy(foo.c, temp.c); > > HTH. > > All the best for now, > John > You are absolutely right about the declaration of the union being a tag name and not a type name - a good rule is *always* to use typedef when defining unions and structs. However, the idea of using string functions is poor for two reasons - one is that it is much less efficient than a straight copy, and the other is that the use of an unqualified "char" in the union is wrong. From david_brown at hotpop.com Fri Aug 3 00:15:29 2007 From: david_brown at hotpop.com (David Brown) Date: Fri Aug 3 00:00:16 2007 Subject: [Icc-avr] Is this a bug? In-Reply-To: <0MKp8S-1IGd6M2CCO-0005qi@mrelay.perfora.net> References: <0MKp8S-1IGd6M2CCO-0005qi@mrelay.perfora.net> Message-ID: <46B2D611.1080401@hotpop.com> Ira wrote: > I wrote some code that looks somewhat like this and it didn't work > because, well, let's see the code first. > > So my problem turned out to be that temp.c[3] became not empty and > adding "temp.c[3] = 0;" and "foo.c[3] = 0;" > > I realize that using a union like that is very target and maybe even > compiler specific but it works and it's a very easy way to implement > what I want to do. What I don't understand is why when I declare "u > temp", temp ends up containing random stuff. I thought that I read > somewhere that variables are supposed to be initialized to 0. It always > works right after I program the processor, it never works if I power the > processor on and off and it occasionally works when I reset the > processor. And even when it works, one it stops working, it will never > start working again. > > It's astonishing how many subtle bugs can fit in a 200 line C program. > > union u { > unsigned long l; > char c[4]; > } > u foo; > > main(){ > unsigned long i; > i = 65000; > while (1) { > > i = dosomestuff(); > if (i > foo.l) > dosomeotherstuff(); > } > } > > void intfunction(){ > u temp; > CLI(); > temp.c[0] = a; > temp.c[1] = b; > temp.c[2] = c; > if (temp.l < 55000){ > SEI(); > return; > } > foo.c[0] = temp.c[0]; > foo.c[1] = temp.c[1]; > foo.c[2] = temp.c[2]; > SEI(); > } You have several things wrong here, some of which have been pointed out by others (missing the "typedef" on the union, and the fact that local variables are not automatically initialised unless they are "static"). It is also totally and completely wrong to use "char" for numerical data. A "char" holds a character, often as part of a string. If you want an 8-bit number, the fundamental C types are "unsigned char" and "signed char" - or of preference, a typedef'ed version such as "uint8_t". In C, "char" is sometimes a signed type, sometimes unsigned - it depends on the target, the compiler, and possibly compiler flags. Specifying the signedness (or using a named typedef) lets you specify what you mean, both to your compiler and to yourself. Finally, if intfunction() modifies foo from something outside of main (such as from an interrupt function - although why the extra CLI() and SEI() ?), then "foo" should be declared "volatile". Depending on how and where "dosomestuff" is defined, an optimising compiler could see that "foo" was never modified from within main, so there would be no need to keep reading it within the loop. icc-avr will not do so heavy optimisation (at the moment), but it would certainly be perfectly legal for the compiler to do so - get in the habit of using "volatile" whenever something can happen "behind the compiler's back". mvh., David From bobgardner at aol.com Mon Aug 6 09:56:29 2007 From: bobgardner at aol.com (bobgardner@aol.com) Date: Mon Aug 6 10:07:56 2007 Subject: [Icc-avr] what calls strtol and strtoul? Message-ID: <8C9A661DE42A801-D18-2E27@FWM-D42.sysops.aol.com> I'm 99% with both compressions on on a mega16. Map file shows I'm using tolower (but I never call it) and strtol and strtoul and these are real big, and it seems like they should share a lot of code and how to I figure out who's calling them? Do they get pulled in when something else is called? Is there a call tree of the runtime lib dependencies somewhere? That would be fun to look at. One more: Looks like the compressors are fixing up the rtl routines too. Right? ________________________________________________________________________ AOL now offers free email to everyone. Find out more about what's free from AOL at AOL.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20070806/fe0bfd9a/attachment.html From richard-lists at imagecraft.com Mon Aug 6 13:28:18 2007 From: richard-lists at imagecraft.com (Richard) Date: Mon Aug 6 13:40:15 2007 Subject: [Icc-avr] what calls strtol and strtoul? In-Reply-To: <8C9A661DE42A801-D18-2E27@FWM-D42.sysops.aol.com> References: <8C9A661DE42A801-D18-2E27@FWM-D42.sysops.aol.com> Message-ID: <200708062040.l76KeCiw040547@dragonsgate2.imagecraft.com> At 09:56 AM 8/6/2007, you wrote: >I'm 99% with both compressions on on a mega16. Map file shows I'm >using tolower (but I never call it) and strtol and strtoul and these >are real big, and it seems like they should share a lot of code and >how to I figure out who's calling them? Do they get pulled in when >something else is called? Is there a call tree of the runtime lib >dependencies somewhere? That would be fun to look at. One more: >Looks like the compressors are fixing up the rtl routines too. Right? Mainly printf? Yes, we can generate a call tree, especially using the code compressor technology. So much we can do..... And yes the code compressor fixes up ALL code. // richard (This email is for mailing lists. To reach me directly, please use richard at imagecraft.com) From BobGardner at aol.com Mon Aug 6 16:35:44 2007 From: BobGardner at aol.com (BobGardner@aol.com) Date: Mon Aug 6 16:47:15 2007 Subject: [Icc-avr] what calls strtol and strtoul? Message-ID: In a message dated 8/6/2007 4:29:49 P.M. Eastern Daylight Time, richard-lists@imagecraft.com writes: At 09:56 AM 8/6/2007, you wrote: >I'm 99% with both compressions on on a mega16. Map file shows I'm >using tolower (but I never call it) and strtol and strtoul and these >are real big, and it seems like they should share a lot of code and >how to I figure out who's calling them? Do they get pulled in when >something else is called? Is there a call tree of the runtime lib >dependencies somewhere? That would be fun to look at. One more: >Looks like the compressors are fixing up the rtl routines too. Right? Mainly printf? Yes, we can generate a call tree, especially using the code compressor technology. So much we can do..... And yes the code compressor fixes up ALL code. ================================== Actually I'm at 98% now. I dont have floating point printf checked, have the middle box checked..but I am doing some fp calcs, just have all the %f cprintfs commented out..(have some degree calcs so its pulling in sin etc). any other code squeeze tricks? If I can just squeeze out 256 words (another 2%) I can shoehorn in the bootloader.... ************************************** Get a sneak peek of the all-new AOL at http://discover.aol.com/memed/aolcom30tour -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20070806/b147be68/attachment.html From richard-lists at imagecraft.com Mon Aug 6 16:54:25 2007 From: richard-lists at imagecraft.com (Richard) Date: Mon Aug 6 17:06:21 2007 Subject: [Icc-avr] what calls strtol and strtoul? In-Reply-To: References: Message-ID: <200708070006.l7706Kvj043248@dragonsgate2.imagecraft.com> An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20070806/275bee41/attachment.html From MDipperstein at CalAmp.com Mon Aug 6 17:21:40 2007 From: MDipperstein at CalAmp.com (Michael Dipperstein) Date: Mon Aug 6 17:33:05 2007 Subject: [Icc-avr] what calls strtol and strtoul? In-Reply-To: Message-ID: There are a ton of things you can do. If (x == case1) { docase1; } If (x == case2) { docase2; } .... generates smaller code than switch(x) { case case1: docase1; break; case case2: docase2; break; ... } as long as docase1 doesn't change x. If you're accessing a static array within a function keep a pointer to the structure in a register and access the data through the pointer, e.g. register int *myArrayPtr; myArrayPtr = &myArray[0]; if (*(myArray + 3) == 42) { (myArray + 5) = 24; } When comparing one byte variables to constants operations matter. I don't remember all of the rules, but if (x > 42) takes one more instruction than if (x >= 43). if (x <= 42) takes one more instruction than if (x < 43). foo = 0; if (bar) { foo = 1; } is smaller than if (bar) { foo = 1; } else { foo = 0; } I can't think of any other simple optimizations right now. I found that the compiler has influenced my code style to the point where I do the things that make it generate smaller code without thinking about why I do them. There are also some not so common (in my code anyway) cases that are made bigger by the optimizer. I'd have to go through my notes to see what they are. -Mike -----Original Message----- From: icc-avr-bounces@imagecraft.com [mailto:icc-avr-bounces@imagecraft.com] On Behalf Of BobGardner@aol.com Sent: Monday, August 06, 2007 4:36 PM To: icc-avr@imagecraft.com Subject: Re: [Icc-avr] what calls strtol and strtoul? In a message dated 8/6/2007 4:29:49 P.M. Eastern Daylight Time, richard-lists@imagecraft.com writes: At 09:56 AM 8/6/2007, you wrote: >I'm 99% with both compressions on on a mega16. Map file shows I'm >using tolower (but I never call it) and strtol and strtoul and these >are real big, and it seems like they should share a lot of code and >how to I figure out who's calling them? Do they get pulled in when >something else is called? Is there a call tree of the runtime lib >dependencies somewhere? That would be fun to look at. One more: >Looks like the compressors are fixing up the rtl routines too. Right? Mainly printf? Yes, we can generate a call tree, especially using the code compressor technology. So much we can do..... And yes the code compressor fixes up ALL code. ================================== Actually I'm at 98% now. I dont have floating point printf checked, have the middle box checked..but I am doing some fp calcs, just have all the %f cprintfs commented out..(have some degree calcs so its pulling in sin etc). any other code squeeze tricks? If I can just squeeze out 256 words (another 2%) I can shoehorn in the bootloader.... ________________________________ Get a sneak peek of the all-new AOL.com . -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20070806/dacd2f5a/attachment-0001.html From bjonaspero at hotmail.com Tue Aug 7 00:00:56 2007 From: bjonaspero at hotmail.com (Björn Lindgren) Date: Tue Aug 7 00:12:25 2007 Subject: [Icc-avr] what calls strtol and strtoul? In-Reply-To: Message-ID: Have you not concidered replaceing the M16 with a M32? It's very compatible (cannot say if all periferals are 100% compatible - there are some names of registers that have to be changed - but hardware is still the same). Life gets easier if you double your memory (wish that would be applicable to humans too) Well, I guess you have a milllion units out at customers already.. Björn >From: BobGardner@aol.com >Reply-To: "Discussion list for ICCAVR and ICCtiny Users. You do NOT need >tosubscribeto icc-announce if you are a member of this." > >To: icc-avr@imagecraft.com >Subject: Re: [Icc-avr] what calls strtol and strtoul? >Date: Mon, 6 Aug 2007 19:35:44 EDT > > >In a message dated 8/6/2007 4:29:49 P.M. Eastern Daylight Time, >richard-lists@imagecraft.com writes: > >At 09:56 AM 8/6/2007, you wrote: > >I'm 99% with both compressions on on a mega16. Map file shows I'm > >using tolower (but I never call it) and strtol and strtoul and these > >are real big, and it seems like they should share a lot of code and > >how to I figure out who's calling them? Do they get pulled in when > >something else is called? Is there a call tree of the runtime lib > >dependencies somewhere? That would be fun to look at. One more: > >Looks like the compressors are fixing up the rtl routines too. Right? > >Mainly printf? Yes, we can generate a call tree, especially using the >code compressor technology. So much we can do..... > >And yes the code compressor fixes up ALL code. > > > > >================================== >Actually I'm at 98% now. >I dont have floating point printf checked, have the middle box checked..but >I am doing some fp calcs, just have all the %f cprintfs commented >out..(have >some degree calcs so its pulling in sin etc). any other code squeeze >tricks? >If I can just squeeze out 256 words (another 2%) I can shoehorn in the >bootloader.... > > > >************************************** Get a sneak peek of the all-new AOL >at >http://discover.aol.com/memed/aolcom30tour >_______________________________________________ >Icc-avr mailing list >Icc-avr@imagecraft.com >http://dragonsgate.net/mailman/listinfo/icc-avr _________________________________________________________________ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ From BobGardner at aol.com Tue Aug 7 04:49:53 2007 From: BobGardner at aol.com (BobGardner@aol.com) Date: Tue Aug 7 05:01:22 2007 Subject: [Icc-avr] what calls strtol and strtoul? Message-ID: In a message dated 8/7/2007 3:02:15 A.M. Eastern Daylight Time, bjonaspero@hotmail.com writes: Have you not concidered replaceing the M16 with a M32? It's very compatible (cannot say if all periferals are 100% compatible - there are some names of registers that have to be changed - but hardware is still the same). Life gets easier if you double your memory (wish that would be applicable to humans too) Well, I guess you have a milllion units out at customers already.. Bj?rn ================================================== The prototypes were mega32, and when I //ed out all the debug stuff, it looked like it would fit in a mega16. Getting the latest compiler with the compressors got it all in, but then there was a couple bug fixes that ate up the last couple of percent. I have 500 of these things... I's like to get the 256 word bootloader in it so I can send out sw updates. ************************************** Get a sneak peek of the all-new AOL at http://discover.aol.com/memed/aolcom30tour -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20070807/3e1db93c/attachment.html From MDipperstein at CalAmp.com Tue Aug 7 11:28:31 2007 From: MDipperstein at CalAmp.com (Michael Dipperstein) Date: Tue Aug 7 11:39:57 2007 Subject: [Icc-avr] what calls strtol and strtoul? In-Reply-To: Message-ID: Bob, Here are some more ideas that might help: If you have EEPROM to spare, you might want to move some of your larger constant data items to EEPROM. Look at converting rarely called functions to inline code. Look at common code blocks and make them a function. Code compressor can do some of this for you, but you should be able to do a better job by making functions that handle slightly different blocks of code. Look for small loops that you can unroll. If you're doing shifts, try to shift by constant values e.g. for (x = 0; x < 8; x++) { ... mask = 1 << x; ... } can be converted to: for (x = 0, mask = 1; x < 8; x++, mask <<= 1) { ... } Expanding on yesterday's array pointer idea you can convert: for (x = 0; x < 8; x++) { ... myArray[x] = y; ... } to: myArrayPtr = myArray; for (x = 0; x < 8; x++, myArrayPtr++) { ... *myArrayPtr = y; ... } The savings will happen if myArray is accessed multiple times. If myArray happens to be an array of struct, you'll see more savings. If you have multiple static arrays with the same dimensions that are accessed with the same offset in the same function, make them a struct and use the pointer trick. x1[n] = 1; x2[n] = 2; x3[n] = 3; can be replaced with: xStructPtr = &xStructArray[n]; xStructPtr->x1 = 1; xStructPtr->x2 = 2; xStructPtr->x3 = 3; Do all math in the simplest possible form. Use unsigned char instead of int where possible. Use int instead of float where possible. I know there are still more things I'm not thinking of. Once you start doing them, you'll find that you can get the compiler to generate smaller code without the optimizer than it does with the optimizer. -Mike -----Original Message----- From: icc-avr-bounces@imagecraft.com [mailto:icc-avr-bounces@imagecraft.com] On Behalf Of BobGardner@aol.com Sent: Tuesday, August 07, 2007 4:50 AM To: icc-avr@imagecraft.com Subject: Re: [Icc-avr] what calls strtol and strtoul? In a message dated 8/7/2007 3:02:15 A.M. Eastern Daylight Time, bjonaspero@hotmail.com writes: Have you not concidered replaceing the M16 with a M32? It's very compatible (cannot say if all periferals are 100% compatible - there are some names of registers that have to be changed - but hardware is still the same). Life gets easier if you double your memory (wish that would be applicable to humans too) Well, I guess you have a milllion units out at customers already.. Bj?rn ================================================== The prototypes were mega32, and when I //ed out all the debug stuff, it looked like it would fit in a mega16. Getting the latest compiler with the compressors got it all in, but then there was a couple bug fixes that ate up the last couple of percent. I have 500 of these things... I's like to get the 256 word bootloader in it so I can send out sw updates. ________________________________ Get a sneak peek of the all-new AOL.com . -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20070807/1c074fae/attachment-0001.html From j_baraclough at zetnet.co.uk Tue Aug 7 15:20:57 2007 From: j_baraclough at zetnet.co.uk (John Baraclough) Date: Tue Aug 7 15:32:35 2007 Subject: [Icc-avr] what calls strtol and strtoul? In-Reply-To: References: Message-ID: Others have offered several tricks to help you and here are a couple more. Check if you really need to use fp calculations. Would a 'pseudo float' be good enough? You can do this by multiplying everything by a factor of 100 or 1000, using int or long int maths and finally dividing the result by the same factor to restore the decimal point to the correct place. Analyse your sin() calculations and see if you could use a look-up table. It may end up being considerably smaller than the fp library. If all else fails go back to the M32 on your prototype! All the best for now, John At 00:35 07/08/2007, you wrote: . >================================== >Actually I'm at 98% now. >I dont have floating point printf checked, have the middle box >checked..but I am doing some fp calcs, just have all the %f cprintfs >commented out..(have some degree calcs so its pulling in sin etc). >any other code squeeze tricks? If I can just squeeze out 256 words >(another 2%) I can shoehorn in the bootloader.... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20070807/330c8f6f/attachment.html From david_brown at hotpop.com Wed Aug 8 00:41:14 2007 From: david_brown at hotpop.com (David Brown) Date: Wed Aug 8 00:25:38 2007 Subject: [Icc-avr] what calls strtol and strtoul? In-Reply-To: References: Message-ID: <46B9739A.1000601@hotpop.com> Michael Dipperstein wrote: > Bob, > > Here are some more ideas that might help: > > If you have EEPROM to spare, you might want to move some of your larger > constant data items to EEPROM. That's a risky idea, at least if your program updates data in the eeprom. It's normally better to go the other way - make sure you have a flash-based copy of a stable eeprom image so that you can "reset to factory defaults" if necessary. It may be possible to squash up constant data a bit, however - perhaps tables can be compacted in some way, and it may even be worth the effort using some sort of compression for strings if there are lots of them. > > Look at converting rarely called functions to inline code. > Any function that is only ever called once should be made smaller and faster by inlining. Unfortunately, if the compiler does not do it automatically and does not support "inline" functions, then it's a real maintainance nightmare converting the functions to macros. I'm also not sure how smart icc-avr is these days as its register allocation for local variables - it may be that it tries to keep the same variables in the same registers throughout the function (this makes the debugger's life *much* easier), which would greatly reduce the benefits as you end up with more locals on the stack. Inlining small functions can also lead to smaller code in some cases, even if they are used regularly, as they avoid the function call overhead and can give the compiler more opportunity for optimisations. This can be particularly useful if the functions are often called with constant data (a function like "setBaudRate(uint16_t baud)" which calculates the uart divisor from the clock speed is an ideal candidate). > > Look at common code blocks and make them a function. Code compressor > can do some of this for you, but you should be able to do a better job > by making functions that handle slightly different blocks of code. > > Look for small loops that you can unroll. > Loop unrolling may or may not help - if you end up with constant values or addresses in the unrolled version, then it can be particularly helpful. > If you?re doing shifts, try to shift by constant values e.g. > > for (x = 0; x < 8; x++) > { > ? > mask = 1 << x; > ? > } > > can be converted to: > > for (x = 0, mask = 1; x < 8; x++, mask <<= 1) > { > ? > } > In general, it is very bad style to put two expressions in any of the clauses in a "for" statement. Hands up all those who *really* understand how the comma operator works in C? Readability is always important - the "for" statement should be "for (x = 0; x < 8; x++)" as before, with "mask = 1" before it and "mask <<= 1" inside the loop. Sometimes "while" loops can be smaller or faster than "for" loops with icc-avr, and it is also often faster to change such a loop to: x = 8; mask = 0x01; while (x--) { ... mask <<= 1; } > Expanding on yesterday?s array pointer idea you can convert: > > for (x = 0; x < 8; x++) > { > ? > myArray[x] = y; > ? > } > > to: > > myArrayPtr = myArray; Just because C allows such abominations as the equivalency of arrays and pointers, does not mean that it should be used! If what you want to say is that myArrayPtr should be initialised to point to the first element of myArray, then write that: myArrayPtr = &myArray[0]; It generates the same code - but makes it clearer what you mean. > > for (x = 0; x < 8; x++, myArrayPtr++) > { > ? > *myArrayPtr = y; > ? > } > Again, drop the "myArrayPtr++" from the "for" clause. It may or may not be faster using "*myArrayPtr++ = y", or doing the increment as a separate statement - it depends on whether icc-avr has kept the pointer in a pointer register. Again, try it and read the generated assembly. > The savings will happen if myArray is accessed multiple times. If > myArray happens to be an array of struct, you?ll see more savings. > Very true. > > If you have multiple static arrays with the same dimensions that are > accessed with the same offset in the same function, make them a struct > and use the pointer trick. > > x1[n] = 1; > x2[n] = 2; > x3[n] = 3; > > can be replaced with: > > xStructPtr = &xStructArray[n]; > xStructPtr->x1 = 1; > xStructPtr->x2 = 2; > xStructPtr->x3 = 3; > That can often be useful (and can improve the quality of the source code). Sometimes it can be useful to pad these structures to a power of two in size, so that the calculation of the address of xStructArray[n] is just a shift and an add. It makes a big difference on older AVRs with no multiplier, but can help even on mega's. (It also makes it easier to view the array with a memory window in your debugger.) > Do all math in the simplest possible form. Use unsigned char instead of > int where possible. Use int instead of float where possible. > Sound advice - using "uint8_t" instead of "int" is a good idea throughout your code (not just for maths). > I know there are still more things I?m not thinking of. Once you start > doing them, you?ll find that you can get the compiler to generate > smaller code without the optimizer than it does with the optimizer. > There are also the obvious things - drop printf and friends, and never use dynamic memory routines in an embedded system (unless you *really* need them - and even then, write your own ones). mvh., David > -Mike > > > > -----Original Message----- > *From:* icc-avr-bounces@imagecraft.com > [mailto:icc-avr-bounces@imagecraft.com] *On Behalf Of *BobGardner@aol.com > *Sent:* Tuesday, August 07, 2007 4:50 AM > *To:* icc-avr@imagecraft.com > *Subject:* Re: [Icc-avr] what calls strtol and strtoul? > > > > In a message dated 8/7/2007 3:02:15 A.M. Eastern Daylight Time, > bjonaspero@hotmail.com writes: > > Have you not concidered replaceing the M16 with a M32? It's very > compatible > (cannot say if all > periferals are 100% compatible - there are some names of registers > that have > to be changed - but > hardware is still the same). > > Life gets easier if you double your memory (wish that would be > applicable to > humans too) > > Well, I guess you have a milllion units out at customers already.. > > Bj?rn > > ================================================== > > The prototypes were mega32, and when I //ed out all the debug stuff, it > looked like it would fit in a mega16. Getting the latest compiler with > the compressors got it all in, but then there was a couple bug fixes > that ate up the last couple of percent. I have 500 of these things... > I's like to get the 256 word bootloader in it so I can send out sw updates. > > From david_brown at hotpop.com Wed Aug 8 00:46:07 2007 From: david_brown at hotpop.com (David Brown) Date: Wed Aug 8 00:30:31 2007 Subject: [Icc-avr] what calls strtol and strtoul? In-Reply-To: References: Message-ID: <46B974BF.6050209@hotpop.com> John Baraclough wrote: > Others have offered several tricks to help you and here are a couple more. > > Check if you really need to use fp calculations. Would a 'pseudo float' > be good enough? You can do this by multiplying everything by a factor of > 100 or 1000, using int or long int maths and finally dividing the result > by the same factor to restore the decimal point to the correct place. > This would be significantly smaller and faster if you used 256 or 65536 as your scale factor, as the multiplication and division becomes movement of bytes. 1024 is also a useful scale - it's not quite as efficient, but makes it easy to think of as 0.1% precision. > Analyse your sin() calculations and see if you could use a look-up > table. It may end up being considerably smaller than the fp library. > A half-decent lookup based fixed-point sin() will be much smaller and faster than a general floating point sin(). Depending on the accuracy you need, a simple table with linear interpolation is often good enough - cubic interpolation takes a bit more thought (especially to avoid overflow in your intermediary calculations) but will give extremely smooth results even with a small table. Another alternative is to use a cordic algorithm. > If all else fails go back to the M32 on your prototype! > > All the best for now, > John > From tobias.pflug at atm-computer.de Wed Aug 8 03:53:12 2007 From: tobias.pflug at atm-computer.de (Tobias Pflug) Date: Wed Aug 8 04:03:58 2007 Subject: [Icc-avr] iccavr7 code size Message-ID: <1186570392.20264.0.camel@p57.atm-computer.de> hi, My company is currently using iccavr6 for several projects. I just downloaded the 45day trial version of iccavr7 to give it a try. When I tried to compile a current project it fails reporting that the text area is not large enough. This surprised me a great deal because when compiling the same code with iccavr6 there is still 30% free (even more when using compression) How is this possible ? The code in question is for a atmega128. Are there any known bugs where the compiler bloats code size or how could this be explained ? I also thought that maybe the evaluation version is limited through code size, but the website clearly states it isn't. Any help is appreciated. Regards, Tobias From richard-lists at imagecraft.com Wed Aug 8 04:28:10 2007 From: richard-lists at imagecraft.com (Richard) Date: Wed Aug 8 04:40:09 2007 Subject: [Icc-avr] iccavr7 code size In-Reply-To: <1186570392.20264.0.camel@p57.atm-computer.de> References: <1186570392.20264.0.camel@p57.atm-computer.de> Message-ID: <200708081140.l78Be8mB065290@dragonsgate2.imagecraft.com> The demo is limited to 64K (the latest yet to be released version says that on the title bar to make it clear) so if you are using V6 PRO, then you have access to the full 128K of the M128. My guess is that that is the cause. At 03:53 AM 8/8/2007, Tobias Pflug wrote: >hi, > >My company is currently using iccavr6 for several projects. I just >downloaded the 45day trial version of iccavr7 to give it a try. When >I tried to compile a current project it fails reporting that the >text area is not large enough. > >This surprised me a great deal because when compiling the same code >with iccavr6 there is still 30% free (even more when using compression) > >How is this possible ? The code in question is for a atmega128. Are >there any known bugs where the compiler bloats code size or how could >this be explained ? I also thought that maybe the evaluation version >is limited through code size, but the website clearly states it isn't. > >Any help is appreciated. > >Regards, >Tobias > // richard (This email is for mailing lists. To reach me directly, please use richard at imagecraft.com) From w.renn at tesionmail.de Wed Aug 8 04:35:56 2007 From: w.renn at tesionmail.de (Werner Renn) Date: Wed Aug 8 04:47:16 2007 Subject: [Icc-avr] iccavr7 code size References: <1186570392.20264.0.camel@p57.atm-computer.de> Message-ID: <001801c7d9b0$4acabaa0$6401a8c0@D48DNK0J> Hallo Tobias, das Problem mit der Fehlermeldung "text area is not large enough" hatte ich auch beim Test der Demo ICCV7. Massnahme siehe unten (Mail von Richard. Wenn die Demozeit von 45 Tage abgelaufen ist, reduziert sich die Codegr?sse auf 4KB. Diese 4KB werden dann als 100% maximaler Code angenommen, d.h. nach Ablauf der Demozeit reduuiert sich dadurch der noch freie Codespeicher drastisch. Gr?sse Werner Von: "Richard" An: "Werner Renn" Betreff: Re: Problems with ICC V7 Datum: Dienstag, 29. Mai 2007 22:50 At 12:45 PM 5/29/2007, you wrote: >Ladies and Gentlemen, > >I downloaded the demo version of ICCV7 from your homepage and installed >the programm without any problems on my computer . > >To get familar with your C- compiler I tried to use your examples >like led.prj, hello.prj,8516intr.prj and clock.prj. >I did not change anything at the c-files of the example projects. >When I tried to "make a project" (menu Project F9) I got always the >following error message: > >! E (7):invalid adress range: 0x14000.0x2000 > >This happened with all mentioned examples. We accidentally broke it. Just go to Project->Options->Target and remove the content of "Other Options" in the lower right side, where it says -bmytext:... and they should compile. >I am not sure,if the reason is the unzipped file libsrc.zip in >the directory libsrc.avr. I tried to unzip this file with the >programm "Winzip" by >using the password "!not registered!", but I always >got the message "wrong Checksum" and the extraction procedure failed. >I appreciate your support in this matter. The password is not "!not registered!" :-) the library source is only available if you have purchased a license. >Best regards > >Werner Renn >Germany // 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. ] -----Urspr?ngliche Nachricht----- Von: "Tobias Pflug" An: Gesendet: Mittwoch, 8. August 2007 12:53 Betreff: [Icc-avr] iccavr7 code size > hi, > > My company is currently using iccavr6 for several projects. I just > downloaded the 45day trial version of iccavr7 to give it a try. When > I tried to compile a current project it fails reporting that the > text area is not large enough. > > This surprised me a great deal because when compiling the same code > with iccavr6 there is still 30% free (even more when using compression) > > How is this possible ? The code in question is for a atmega128. Are > there any known bugs where the compiler bloats code size or how could > this be explained ? I also thought that maybe the evaluation version > is limited through code size, but the website clearly states it isn't. > > Any help is appreciated. > > Regards, > Tobias > > > _______________________________________________ > Icc-avr mailing list > Icc-avr@imagecraft.com > http://dragonsgate.net/mailman/listinfo/icc-avr > From tobias.pflug at atm-computer.de Wed Aug 8 05:01:22 2007 From: tobias.pflug at atm-computer.de (Tobias Pflug) Date: Wed Aug 8 05:12:08 2007 Subject: [Icc-avr] iccavr7 code size In-Reply-To: <200708081140.l78Be8mB065290@dragonsgate2.imagecraft.com> References: <1186570392.20264.0.camel@p57.atm-computer.de> <200708081140.l78Be8mB065290@dragonsgate2.imagecraft.com> Message-ID: <1186574482.20264.5.camel@p57.atm-computer.de> On Wed, 2007-08-08 at 04:28 -0700, Richard wrote: > The demo is limited to 64K (the latest yet to be released version > says that on the title bar to make it clear) so if you are using V6 > PRO, then you have access to the full 128K of the M128. My guess is > that that is the cause. > "45-day fully functional Demo, code-size limited for non-commercial use thereafter." To me that reads as : For 45 days there will be no limitations whatsoever - after the trial period the code size will be limited. I sort of guessed that this would be the problem, because it is highly unlikely that the newer version creates massively bigger code. Still it would have helped if things were made a bit clearer and you could actually /tell/ that the .text size is limited to 64kb instead of the 128KB which are also displayed in the device configuration dialog. regards, Tobi From j_baraclough at zetnet.co.uk Wed Aug 8 07:28:37 2007 From: j_baraclough at zetnet.co.uk (John Baraclough) Date: Wed Aug 8 07:40:16 2007 Subject: [Icc-avr] iccavr7 code size In-Reply-To: <1186574482.20264.5.camel@p57.atm-computer.de> References: <1186570392.20264.0.camel@p57.atm-computer.de> <200708081140.l78Be8mB065290@dragonsgate2.imagecraft.com> <1186574482.20264.5.camel@p57.atm-computer.de> Message-ID: Hi Tobias, When moving a project from version 6 to version 7 you must ensure the version 6 library paths and include paths are deleted. Go to 'Project->Options->Paths' and make sure all references to version 6 are removed as the compiler will automatically add the version 7 paths. All the best for now, John At 13:01 08/08/2007, you wrote: >On Wed, 2007-08-08 at 04:28 -0700, Richard wrote: > > The demo is limited to 64K (the latest yet to be released version > > says that on the title bar to make it clear) so if you are using V6 > > PRO, then you have access to the full 128K of the M128. My guess is > > that that is the cause. > > > >"45-day fully functional Demo, code-size limited for non-commercial use >thereafter." > >To me that reads as : For 45 days there will be no limitations >whatsoever - after the trial period the code size will be limited. > >I sort of guessed that this would be the problem, because it is highly >unlikely that the newer version creates massively bigger code. Still >it would have helped if things were made a bit clearer and you could >actually /tell/ that the .text size is limited to 64kb instead of the >128KB which are also displayed in the device configuration dialog. > >regards, >Tobi > >_______________________________________________ >Icc-avr mailing list >Icc-avr@imagecraft.com >http://dragonsgate.net/mailman/listinfo/icc-avr From richard-lists at imagecraft.com Wed Aug 8 10:28:44 2007 From: richard-lists at imagecraft.com (Richard) Date: Wed Aug 8 10:40:44 2007 Subject: [Icc-avr] iccavr7 code size In-Reply-To: <1186574482.20264.5.camel@p57.atm-computer.de> References: <1186570392.20264.0.camel@p57.atm-computer.de> <200708081140.l78Be8mB065290@dragonsgate2.imagecraft.com> <1186574482.20264.5.camel@p57.atm-computer.de> Message-ID: <200708081740.l78HegMw069362@dragonsgate2.imagecraft.com> Yes, as I said, the next version will have the clearer. It will have the words [64K bytes code size limited] on the title bar. You can see that if you are using 7.14 BETA1 already... At 05:01 AM 8/8/2007, Tobias Pflug wrote: >"45-day fully functional Demo, code-size limited for non-commercial use >thereafter." > >To me that reads as : For 45 days there will be no limitations >whatsoever - after the trial period the code size will be limited. > >I sort of guessed that this would be the problem, because it is highly >unlikely that the newer version creates massively bigger code. Still >it would have helped if things were made a bit clearer and you could >actually /tell/ that the .text size is limited to 64kb instead of the >128KB which are also displayed in the device configuration dialog. > >regards, >Tobi > >_______________________________________________ >Icc-avr mailing list >Icc-avr@imagecraft.com >http://dragonsgate.net/mailman/listinfo/icc-avr // richard (This email is for mailing lists. To reach me directly, please use richard at imagecraft.com) From richard at imagecraft.com Wed Aug 8 12:03:56 2007 From: richard at imagecraft.com (Richard) Date: Wed Aug 8 12:15:55 2007 Subject: [Icc-avr] Reminder: maintenance contract renewal Message-ID: <200708081915.l78JFsHw070411@dragonsgate2.imagecraft.com> As you know, our maintenance contract fee is ridiculously low ($50) and so far it is an honor system. I may add some auto-reminder feature in soon (as non-intrusive as possible of course), but if you don't remember the last time you pay for an annual maintenance, you can purchase it now, today, this moment :-) using our web server. We have lots new stuff coming, including 64 bits double, full integration with AVR Studio, and even more powerful MIO. All these take resources, human and monetary. Your maintenance contract will help to make that happen. Thanks. // 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 sbissonnette at microsyl.com Wed Aug 8 14:05:38 2007 From: sbissonnette at microsyl.com (Sylvain Bissonnette) Date: Wed Aug 8 13:18:50 2007 Subject: [Icc-avr] AVR ISP mkII & ICCAVR References: <200708081915.l78JFsHw070411@dragonsgate2.imagecraft.com> Message-ID: <000c01c7d9ff$ded705b0$0301a8c0@Sylvain> Hi, Did someone know how to setup ICC to program target with the ISP mkII Thanks Sylvain Bissonnette From abuk at texa.com.pl Wed Aug 8 13:54:57 2007 From: abuk at texa.com.pl (Jakub Targalski) Date: Wed Aug 8 14:05:03 2007 Subject: [Icc-avr] AVR ISP mkII & ICCAVR In-Reply-To: <000c01c7d9ff$ded705b0$0301a8c0@Sylvain> References: <200708081915.l78JFsHw070411@dragonsgate2.imagecraft.com> <000c01c7d9ff$ded705b0$0301a8c0@Sylvain> Message-ID: <46BA2DA1.1070601@texa.com.pl> Sylvain Bissonnette pisze: > > Did someone know how to setup ICC to program target with the ISP mkII > > If you have AVRStudio installed only thing you have to do is chose STK500/AVRISP in ICCAVR programing menu. -- regards, Jakub Targalski --------------------------------------------------------------- TEXA s.c. Jakub i Kazimierz Targalski http://www.texa.com.pl TEL: (024) 2543386 GSM: 0607 838567 jakub.targalski@texa.com.pl From sbissonnette at microsyl.com Wed Aug 8 15:24:51 2007 From: sbissonnette at microsyl.com (Sylvain Bissonnette) Date: Wed Aug 8 14:38:03 2007 Subject: [Icc-avr] AVR ISP mkII & ICCAVR References: <200708081915.l78JFsHw070411@dragonsgate2.imagecraft.com> <000c01c7d9ff$ded705b0$0301a8c0@Sylvain> <46BA2DA1.1070601@texa.com.pl> Message-ID: <000801c7da0a$f0555200$0301a8c0@Sylvain> Thanks for your reply Jakub, But the COM selection in ICC will be override? I have 2 ISP one serial and the other usb and many time I have 2 ICC open and I work on 2 target at the same time. Sylvain ----- Original Message ----- From: "Jakub Targalski" To: "Discussion list for ICCAVR and ICCtiny Users. You do NOT need tosubscribe to icc-announce if you are a member of this." Sent: Wednesday, August 08, 2007 3:54 PM Subject: Re: [Icc-avr] AVR ISP mkII & ICCAVR > Sylvain Bissonnette pisze: >> >> Did someone know how to setup ICC to program target with the ISP mkII >> >> > If you have AVRStudio installed only thing you have to do is chose > STK500/AVRISP in ICCAVR programing menu. > > -- > regards, > Jakub Targalski > --------------------------------------------------------------- > TEXA s.c. Jakub i Kazimierz Targalski http://www.texa.com.pl > TEL: (024) 2543386 > GSM: 0607 838567 jakub.targalski@texa.com.pl > > _______________________________________________ > Icc-avr mailing list > Icc-avr@imagecraft.com > http://dragonsgate.net/mailman/listinfo/icc-avr > From rodney at junipersys.com Wed Aug 8 15:18:35 2007 From: rodney at junipersys.com (Rodney Pearson) Date: Wed Aug 8 15:30:20 2007 Subject: [Icc-avr] AVR ISP mkII & ICCAVR In-Reply-To: <000801c7da0a$f0555200$0301a8c0@Sylvain> References: <200708081915.l78JFsHw070411@dragonsgate2.imagecraft.com><000c01c7d9ff$ded705b0$0301a8c0@Sylvain> <46BA2DA1.1070601@texa.com.pl> <000801c7da0a$f0555200$0301a8c0@Sylvain> Message-ID: Yes and no. Yes it will override the ICC COM selection, but not until you close one of the instances of the ICCAVR ISP dialog with OK. The ISP COM selection for the AVRISP is stored in the Windows registry. Every time you open the ICCAVR ISP dialog, it get the COM setting from the registry, as near as I have been able to tell. I am uncertain how this will effect ICCAVR with two instances open. You'll just have to try it out =) I only have the AVRISPmkII, so I am unable to test it out. I'm guessing that each time you open/close the ICCAVR ISP dialog in either IDE, it will read/write the registry and effect the COM settings... 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 Sylvain Bissonnette Sent: Wednesday, August 08, 2007 4:25 PM To: Discussion list for ICCAVR and ICCtiny Users. You do NOT needtosubscribetoicc-announce if you are a member of this. Subject: Re: [Icc-avr] AVR ISP mkII & ICCAVR Thanks for your reply Jakub, But the COM selection in ICC will be override? I have 2 ISP one serial and the other usb and many time I have 2 ICC open and I work on 2 target at the same time. Sylvain ----- Original Message ----- From: "Jakub Targalski" To: "Discussion list for ICCAVR and ICCtiny Users. You do NOT need tosubscribe to icc-announce if you are a member of this." Sent: Wednesday, August 08, 2007 3:54 PM Subject: Re: [Icc-avr] AVR ISP mkII & ICCAVR > Sylvain Bissonnette pisze: >> >> Did someone know how to setup ICC to program target with the ISP mkII >> >> > If you have AVRStudio installed only thing you have to do is chose > STK500/AVRISP in ICCAVR programing menu. > > -- > regards, > Jakub Targalski > --------------------------------------------------------------- > TEXA s.c. Jakub i Kazimierz Targalski http://www.texa.com.pl > TEL: (024) 2543386 > GSM: 0607 838567 jakub.targalski@texa.com.pl > > _______________________________________________ > Icc-avr mailing list > Icc-avr@imagecraft.com > http://dragonsgate.net/mailman/listinfo/icc-avr > _______________________________________________ Icc-avr mailing list Icc-avr@imagecraft.com http://dragonsgate.net/mailman/listinfo/icc-avr From tobias.pflug at atm-computer.de Wed Aug 8 23:13:51 2007 From: tobias.pflug at atm-computer.de (Tobias Pflug) Date: Wed Aug 8 23:24:35 2007 Subject: [Icc-avr] jtagice mkII Message-ID: <1186640031.20264.14.camel@p57.atm-computer.de> Hello, Excuse me if I am missing something obvious by asking this but I have only recently started with AVR at work. Initially I wanted to use GCC but I had problems porting the excisting iccavr based to GCC so I installed vmware and started using image craft. What surprised me, in a bad way, is that there is no support for the avr jtag ice mkII in the imagecraft IDE. Instead everyone seems to be using avr studio for that. Are there any plans at all to support that device at all? I find it rather inconvenient to depend on a second IDE for debugging/and programming flash at all (for some reason I can't get avrdude to work ..) I am actually not even using the imagecraft IDE because I prefer to use vim and execute the compilers manually. Lastly I was wondering if there have ever been any thoughts about releasing the image craft compilers under linux? thank you. have a nice day, Tobi From stephan.daub at sap.com Wed Aug 8 23:39:26 2007 From: stephan.daub at sap.com (Daub, Stephan) Date: Wed Aug 8 23:51:00 2007 Subject: AW: [Icc-avr] jtagice mkII In-Reply-To: <1186640031.20264.14.camel@p57.atm-computer.de> Message-ID: Hi Tobi and Richard, >What surprised me, in a bad way, is that there is no support for >the avr jtag ice mkII in the imagecraft IDE. Instead everyone seems I definitely would like to support this idea ! >imagecraft IDE because I prefer to use vim and execute the compilers old school - he ?:) I like the ICC IDE but I would like to support the idea of LINUX support (a basic compiler framework - [for me] IDE not needed) ! @Richard, if any help is needed to port the ICC compilers to linux, I would be glad to help with this. have a nice day, Stephan From Derek.Robertson at logitech.uk.com Thu Aug 9 01:13:16 2007 From: Derek.Robertson at logitech.uk.com (Robertson, Derek) Date: Thu Aug 9 01:24:10 2007 Subject: [Icc-avr] AVR ISP mkII & ICCAVR Message-ID: Just put -cUSB in the additional Stk500 Arguments in the ISP set up dialog.. And all should be well :o) Derek -----Original Message----- From: Sylvain Bissonnette [mailto:sbissonnette@microsyl.com] Sent: 08 August 2007 22:06 To: Discussion list for ICCAVR and ICCtiny Users. You do NOT needtosubscribetoicc-announce if you are a member of this. Subject: [Icc-avr] AVR ISP mkII & ICCAVR Hi, Did someone know how to setup ICC to program target with the ISP mkII Thanks Sylvain Bissonnette _______________________________________________ Icc-avr mailing list Icc-avr@imagecraft.com http://dragonsgate.net/mailman/listinfo/icc-avr -------------------------------------------------------- Logitech Ltd is a limited company registered in Scotland. Registration Number: SC42330 Registered Address: Erskine Ferry Road, Old Kilpatrick, Glasgow, G60 5EU, Scotland, UK -------------------------------------------------------- This message (and any associated files) is intended only for the use of the individual or entity to which it is addressed and may contain information that is confidential, subject to copyright or constitutes a trade secret. If you are not the intended recipient you are hereby notified that any dissemination, copying or distribution of this message, or files associated with this message, is prohibited. If you have received this message in error, please notify us immediately by replying to the message and deleting it from your computer. Messages sent to and from us may be monitored. Any views or opinions presented are solely those of the author and do not necessarily represent those of the company. From Svenn at symetrics.no Thu Aug 9 02:27:43 2007 From: Svenn at symetrics.no (=?iso-8859-1?Q?Svenn_Dahlstr=F8m?=) Date: Thu Aug 9 02:39:13 2007 Subject: SV: [Icc-avr] AVR ISP mkII & ICCAVR Message-ID: <23CAB4A1878E854994AB398BC4CF5B0E077370@SERVER.symetrics.local> And you can also add the serial number of the AVR ISP mkII -cUSB:00001A52 I have not tried this, but I will believe you can direct your programming to any usb connected AVR ISP mkII... You can find the serial number at the buttum of the AVR ISP mkII. Svenn Dahlstr?m Symetrics Elektronikk AS > -----Opprinnelig melding----- > Fra: icc-avr-bounces@imagecraft.com [mailto:icc-avr- > bounces@imagecraft.com] P? vegne av Robertson, Derek > Sendt: 9. august 2007 10:31 > Til: Discussion list for ICCAVR and ICCtiny Users. You do NOT > needtosubscribeto icc-announce if you are a member of this. > Emne: RE: [Icc-avr] AVR ISP mkII & ICCAVR > > Just put -cUSB in the additional Stk500 Arguments in the ISP set up > dialog.. And all should be well :o) > > Derek > > > > -----Original Message----- > From: Sylvain Bissonnette [mailto:sbissonnette@microsyl.com] > Sent: 08 August 2007 22:06 > To: Discussion list for ICCAVR and ICCtiny Users. You do NOT > needtosubscribetoicc-announce if you are a member of this. > Subject: [Icc-avr] AVR ISP mkII & ICCAVR > > Hi, > > Did someone know how to setup ICC to program target with the ISP > mkII > > Thanks > Sylvain Bissonnette > > _______________________________________________ > Icc-avr mailing list > Icc-avr@imagecraft.com > http://dragonsgate.net/mailman/listinfo/icc-avr > > -------------------------------------------------------- > > Logitech Ltd is a limited company registered in Scotland. Registration > Number: SC42330 > Registered Address: Erskine Ferry Road, Old Kilpatrick, Glasgow, G60 5EU, > Scotland, UK > -------------------------------------------------------- > > > This message (and any associated files) is intended only for the use of > the individual or entity > to which it is addressed and may contain information that is confidential, > subject to copyright > or constitutes a trade secret. If you are not the intended recipient you > are hereby notified that > any dissemination, copying or distribution of this message, or files > associated with this message, > is prohibited. If you have received this message in error, please notify > us immediately by replying > to the message and deleting it from your computer. > Messages sent to and from us may be monitored. > > Any views or opinions presented are solely those of the author and do not > necessarily represent > those of the company. > > _______________________________________________ > Icc-avr mailing list > Icc-avr@imagecraft.com > http://dragonsgate.net/mailman/listinfo/icc-avr > > From tobias.pflug at atm-computer.de Thu Aug 9 04:54:51 2007 From: tobias.pflug at atm-computer.de (Tobias Pflug) Date: Thu Aug 9 05:05:37 2007 Subject: [Icc-avr] A little Note to vim users Message-ID: <1186660491.20264.17.camel@p57.atm-computer.de> Hello everyone.. Should you, like me, prefer to use the iccavr compiler with vim then two tiny changes will make your life easier: set efm=!%t\ %f(%l):%m set makeprg=imakew\ -f\ YourMakefile.mak The first sets the error format properly so that the cwindow lists errors and warnings and you can navigate them. The latter redefines the command executed when carrying out :make happy vim'ing ... ;] regards, Tobi From sbissonnette at microsyl.com Thu Aug 9 16:49:20 2007 From: sbissonnette at microsyl.com (Sylvain Bissonnette) Date: Thu Aug 9 16:02:32 2007 Subject: [Icc-avr] AVR ISP mkII & ICCAVR References: <23CAB4A1878E854994AB398BC4CF5B0E077370@SERVER.symetrics.local> Message-ID: <000601c7dadf$e7aaef90$0301a8c0@Sylvain> Hi, That's fine, but if you chose in ICC the option USB the witch -cUSB:00001A52 will work you will have something like this -cUSB -cUSB00001A52 I can be wrong I don't know Sylvain Bissonnette ----- Original Message ----- From: "Svenn Dahlstr?m" To: "Discussion list for ICCAVR and ICCtiny Users. You do NOT needtosubscribeto icc-announce if you are a member of this." Sent: Thursday, August 09, 2007 4:27 AM Subject: SV: [Icc-avr] AVR ISP mkII & ICCAVR And you can also add the serial number of the AVR ISP mkII -cUSB:00001A52 I have not tried this, but I will believe you can direct your programming to any usb connected AVR ISP mkII... You can find the serial number at the buttum of the AVR ISP mkII. Svenn Dahlstr?m Symetrics Elektronikk AS > -----Opprinnelig melding----- > Fra: icc-avr-bounces@imagecraft.com [mailto:icc-avr- > bounces@imagecraft.com] P? vegne av Robertson, Derek > Sendt: 9. august 2007 10:31 > Til: Discussion list for ICCAVR and ICCtiny Users. You do NOT > needtosubscribeto icc-announce if you are a member of this. > Emne: RE: [Icc-avr] AVR ISP mkII & ICCAVR > > Just put -cUSB in the additional Stk500 Arguments in the ISP set up > dialog.. And all should be well :o) > > Derek > > > > -----Original Message----- > From: Sylvain Bissonnette [mailto:sbissonnette@microsyl.com] > Sent: 08 August 2007 22:06 > To: Discussion list for ICCAVR and ICCtiny Users. You do NOT > needtosubscribetoicc-announce if you are a member of this. > Subject: [Icc-avr] AVR ISP mkII & ICCAVR > > Hi, > > Did someone know how to setup ICC to program target with the ISP > mkII > > Thanks > Sylvain Bissonnette > > _______________________________________________ > Icc-avr mailing list > Icc-avr@imagecraft.com > http://dragonsgate.net/mailman/listinfo/icc-avr > > -------------------------------------------------------- > > Logitech Ltd is a limited company registered in Scotland. Registration > Number: SC42330 > Registered Address: Erskine Ferry Road, Old Kilpatrick, Glasgow, G60 5EU, > Scotland, UK > -------------------------------------------------------- > > > This message (and any associated files) is intended only for the use of > the individual or entity > to which it is addressed and may contain information that is confidential, > subject to copyright > or constitutes a trade secret. If you are not the intended recipient you > are hereby notified that > any dissemination, copying or distribution of this message, or files > associated with this message, > is prohibited. If you have received this message in error, please notify > us immediately by replying > to the message and deleting it from your computer. > Messages sent to and from us may be monitored. > > Any views or opinions presented are solely those of the author and do not > necessarily represent > those of the company. > > _______________________________________________ > Icc-avr mailing list > Icc-avr@imagecraft.com > http://dragonsgate.net/mailman/listinfo/icc-avr > > _______________________________________________ Icc-avr mailing list Icc-avr@imagecraft.com http://dragonsgate.net/mailman/listinfo/icc-avr From rodney at junipersys.com Thu Aug 9 16:24:28 2007 From: rodney at junipersys.com (Rodney Pearson) Date: Thu Aug 9 16:36:02 2007 Subject: [Icc-avr] AVR ISP mkII & ICCAVR In-Reply-To: <000601c7dadf$e7aaef90$0301a8c0@Sylvain> References: <23CAB4A1878E854994AB398BC4CF5B0E077370@SERVER.symetrics.local> <000601c7dadf$e7aaef90$0301a8c0@Sylvain> Message-ID: >>Hi, >> >> That's fine, but if you chose in ICC the option USB the >>witch -cUSB:00001A52 will work you will have >>something like this -cUSB -cUSB00001A52 I can be wrong I don't know >> >>Sylvain Bissonnette Yes, you are correct. But from my testing, the stk500.exe will simply override the first -cUSB with the second -cUSB:xxxxxxxx and attempt to connect to that specific AVRISPmkII device. You can check this by using an invalid number and watching the status window in ICCAVR. It will report that stk500.exe is trying to find and connect to a device with the bogus ID number. It is similar to how in the "Other Options" of the Compiler Options dialog you can add something like -bfunc_lit:0x00000.0x40000 and end up with an invocation like iccavr ... -bfunc_lit:0x3e0e4.0x40000 ... -bfunc_lit:0x00000.0x40000.. yet the iccavr EXE uses the overridden setting (-bfunc_lit:0x00000.0x40000). My recommendation is to just play around with it and watch the command line the ISP dialog produces and compare that to the resultant stk500.exe actions. Cheers! Rodney Pearson Software Engineer Juniper Systems, Inc. www.junipersys.com From sbissonnette at microsyl.com Thu Aug 9 18:00:30 2007 From: sbissonnette at microsyl.com (Sylvain Bissonnette) Date: Thu Aug 9 17:13:43 2007 Subject: [Icc-avr] AVR ISP mkII & ICCAVR References: <23CAB4A1878E854994AB398BC4CF5B0E077370@SERVER.symetrics.local> <000601c7dadf$e7aaef90$0301a8c0@Sylvain> Message-ID: <000601c7dae9$d8b3ddd0$0301a8c0@Sylvain> Thanks Rodney, Now it's clear in my mind! Sylvain ----- Original Message ----- From: "Rodney Pearson" To: "Discussion list for ICCAVR and ICCtiny Users. You do NOT needtosubscribeto icc-announce if you are a member of this." Sent: Thursday, August 09, 2007 6:24 PM Subject: RE: [Icc-avr] AVR ISP mkII & ICCAVR >>>Hi, >>> >>> That's fine, but if you chose in ICC the option USB the >>>witch -cUSB:00001A52 will work you will have >>>something like this -cUSB -cUSB00001A52 I can be wrong I don't know >>> >>>Sylvain Bissonnette > > Yes, you are correct. But from my testing, the stk500.exe will simply > override the first -cUSB with the second -cUSB:xxxxxxxx and attempt to > connect to that specific AVRISPmkII device. You can check this by using > an invalid number and watching the status window in ICCAVR. It will > report that stk500.exe is trying to find and connect to a device with > the bogus ID number. > > It is similar to how in the "Other Options" of the Compiler Options > dialog you can add something like > > -bfunc_lit:0x00000.0x40000 > > and end up with an invocation like > > iccavr ... -bfunc_lit:0x3e0e4.0x40000 ... > -bfunc_lit:0x00000.0x40000.. > > yet the iccavr EXE uses the overridden setting > (-bfunc_lit:0x00000.0x40000). > > My recommendation is to just play around with it and watch the command > line the ISP dialog produces and compare that to the resultant > stk500.exe actions. > > Cheers! > > Rodney Pearson > Software Engineer > Juniper Systems, Inc. > www.junipersys.com > > > > _______________________________________________ > Icc-avr mailing list > Icc-avr@imagecraft.com > http://dragonsgate.net/mailman/listinfo/icc-avr > From ira at extrasensory.com Sun Aug 12 14:57:42 2007 From: ira at extrasensory.com (Ira) Date: Sun Aug 12 15:09:36 2007 Subject: [Icc-avr] A few more beginner questions Message-ID: <0MKpCa-1IKLRh0H0v-0006TL@mrelay.perfora.net> Hi I'm using an ATMega48. Why does my code work different when I use these 2 lines of code: PORTB &= 253; PORTB |= 2; Then when I use: ClrBit(PORTB, 2); SetBit(PORTB, 2); Well, that led to the discovery that these two lines of code generate very different output even though it seems they should generate the same output PORTB &= 253; PORTB &= ~2; Ira From sl at ecpower.dk Sun Aug 12 22:03:32 2007 From: sl at ecpower.dk (Steven Lose) Date: Sun Aug 12 22:15:07 2007 Subject: SV: [Icc-avr] A few more beginner questions References: <0MKpCa-1IKLRh0H0v-0006TL@mrelay.perfora.net> Message-ID: <072D96786BFC014AAEBA9EB07A8070EA285269@seattle.ecpower.dk> Hi Ira. It's easer to see what you mean if we could see your output 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 Ira Sendt: 12. august 2007 23:58 Til: icc-avr@imagecraft.com Emne: [Icc-avr] A few more beginner questions Hi I'm using an ATMega48. Why does my code work different when I use these 2 lines of code: PORTB &= 253; PORTB |= 2; Then when I use: ClrBit(PORTB, 2); SetBit(PORTB, 2); Well, that led to the discovery that these two lines of code generate very different output even though it seems they should generate the same output PORTB &= 253; PORTB &= ~2; Ira _______________________________________________ Icc-avr mailing list Icc-avr@imagecraft.com http://dragonsgate.net/mailman/listinfo/icc-avr From ira at extrasensory.com Sun Aug 12 22:29:25 2007 From: ira at extrasensory.com (Ira) Date: Sun Aug 12 22:41:18 2007 Subject: SV: [Icc-avr] A few more beginner questions In-Reply-To: <072D96786BFC014AAEBA9EB07A8070EA285269@seattle.ecpower.dk> References: <0MKpCa-1IKLRh0H0v-0006TL@mrelay.perfora.net> <072D96786BFC014AAEBA9EB07A8070EA285269@seattle.ecpower.dk> Message-ID: <0MKpCa-1IKSUp3YOw-0006Y4@mrelay.perfora.net> At 10:03 PM 8/12/2007, you wrote: >It's easer to see what you mean if we could see your output > > > PORTB &= 253; > PORTB &= ~2; The ~=2 generates the code for Clear Bit Immediate. The &= 253 code looks like copy PORTB to R24, AND R$ with 253 and then copy R24 to PORTB Ira From Douglas.Pearless at pearless.co.nz Sun Aug 12 22:42:16 2007 From: Douglas.Pearless at pearless.co.nz (Douglas Pearless) Date: Sun Aug 12 22:53:49 2007 Subject: [Icc-avr] A few more beginner questions In-Reply-To: <0MKpCa-1IKLRh0H0v-0006TL@mrelay.perfora.net> References: <0MKpCa-1IKLRh0H0v-0006TL@mrelay.perfora.net> Message-ID: <46BFEF38.3080507@pearless.co.nz> Hi, I am struggling to get my ATmega16 to generate a square ware. I am using the internal 1MHz oscillator (NO Crystal) and I am trying to use PWM to get a 1Hz wave out on the pin. I am using ICCAVR 7.11, AVR Studio 4.12 build 498 and a JTAGICE II. The Application Builder gives the following output (I have tried all sorts of combinations!!) and I would normally toggle the output bit manually via the overflow interrupt, but reading the data sheet it seems that the PWM should be able to be put to PD5/4 (OC1A / OC1B)??? I seem to be missing something, help! Cheers Douglas code: //ICC-AVR application builder : 13/08/2007 5:33:15 p.m. // Target : M16 // Crystal: 1.0000Mhz #include #include void port_init(void) { PORTA = 0x00; DDRA = 0x00; PORTB = 0x00; DDRB = 0x00; PORTC = 0x00; //m103 output only DDRC = 0x00; PORTD = 0x00; DDRD = 0xFF; } //TIMER1 initialize - prescale:1024 // WGM: 0) Normal, TOP=0xFFFF // desired value: 1Hz // actual value: 1.001Hz (0.1%) void timer1_init(void) { TCCR1B = 0x00; //stop TCNT1H = 0xFC; //setup TCNT1L = 0x30; OCR1AH = 0x03; OCR1AL = 0xD0; OCR1BH = 0x03; OCR1BL = 0xD0; ICR1H = 0x03; ICR1L = 0xD0; TCCR1A = 0x40; TCCR1B = 0x05; //start Timer } //call this routine to initialize all peripherals void init_devices(void) { //stop errant interrupts until set up CLI(); //disable all interrupts port_init(); timer1_init(); MCUCR = 0x00; GICR = 0x00; TIMSK = 0x00; //timer interrupt sources SEI(); //re-enable interrupts //all peripherals are now initialized } // void main(void) { init_devices(); //insert your functional code here... loop: goto loop; } -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.476 / Virus Database: 269.11.15/949 - Release Date: 12/08/2007 11:03 a.m. From benra at imt.liu.se Sun Aug 12 23:02:11 2007 From: benra at imt.liu.se (Bengt Ragnemalm) Date: Sun Aug 12 23:12:31 2007 Subject: SV: [Icc-avr] Reminder: maintenance contract renewal In-Reply-To: <200708081915.l78JFsHw070411@dragonsgate2.imagecraft.com> References: <200708081915.l78JFsHw070411@dragonsgate2.imagecraft.com> Message-ID: <005b01c7dd6f$7d8bf0e0$b160ec82@Shagrat> Well, I do not think $50 is ridiculously low (hm, this make me think of Harry Potter), but I think it is just fair. A problem is that you have to pay this of your own every year (is that the correct period?). It would have been better if your distributor used an automatic method for this. Of course, that would mean the distributor would take some of the $... By the way, how come that it is cheaper to buy from you directly than from a distributor? I find that odd as it may kill your distributors. OK, I got a fancy manual and a CD that still is in it's plastic but as I do not need it I thought I could bye whatever I want even from a distributor. $50 is 25% of the cost of the standard ICCAVR. As a comparision, I pay about 5% in maintenance fee for my CAD software (commercial standard version). But 5% maintenance fee for ICCAVR would really be ridiculously low. I know I have paid the maintenance fee at least once but as I have been using ICCAVR for years and also have three dongles I fell rather guilty. On the other hand, it would be interesting to see your statistics for downloaded upgrades compared to paid maintenance fees. (Minus the licenses you sold last year). Best regards Bengt > -----Ursprungligt meddelande----- > Fr?n: icc-avr-bounces@imagecraft.com [mailto:icc-avr- > bounces@imagecraft.com] F?r Richard > Skickat: den 8 augusti 2007 21:04 > Till: icc-avr@imagecraft.com > ?mne: [Icc-avr] Reminder: maintenance contract renewal > > As you know, our maintenance contract fee is ridiculously low ($50) > and so far it is an honor system. I may add some auto-reminder > feature in soon (as non-intrusive as possible of course), but if you > don't remember the last time you pay for an annual maintenance, you > can purchase it now, today, this moment :-) using our web server. > > We have lots new stuff coming, including 64 bits double, full > integration with AVR Studio, and even more powerful MIO. All these > take resources, human and monetary. Your maintenance contract will > help to make that happen. > > Thanks. > > // 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 richard-lists at imagecraft.com Mon Aug 13 00:18:56 2007 From: richard-lists at imagecraft.com (Richard) Date: Mon Aug 13 00:31:02 2007 Subject: SV: [Icc-avr] Reminder: maintenance contract renewal In-Reply-To: <005b01c7dd6f$7d8bf0e0$b160ec82@Shagrat> References: <200708081915.l78JFsHw070411@dragonsgate2.imagecraft.com> <005b01c7dd6f$7d8bf0e0$b160ec82@Shagrat> Message-ID: <200708130731.l7D7V2eY037473@dragonsgate2.imagecraft.com> Sure Bengt, for you only, the price of the compiler is now $1000. $50 is now only 5%. Do you feel better for the deal now? Yes, we should make the maintenance more automatic and easier to pay. More customers would probably pay if we remind them that way and if it is very easy to pay. We are looking into that. As for distributor prices, some distributors have to include VAT (Value Added Tax) or prices for advertising etc. I can assure you that very few of us are getting rich off this :-( At 11:02 PM 8/12/2007, Bengt Ragnemalm wrote: >Well, I do not think $50 is ridiculously low (hm, this make me think of >Harry Potter), but I think it is just fair. A problem is that you have to >pay this of your own every year (is that the correct period?). It would have >been better if your distributor used an automatic method for this. Of >course, that would mean the distributor would take some of the $... > >By the way, how come that it is cheaper to buy from you directly than from a >distributor? I find that odd as it may kill your distributors. OK, I got a >fancy manual and a CD that still is in it's plastic but as I do not need it >I thought I could bye whatever I want even from a distributor. > >$50 is 25% of the cost of the standard ICCAVR. As a comparision, I pay about >5% in maintenance fee for my CAD software (commercial standard version). But >5% maintenance fee for ICCAVR would really be ridiculously low. > >I know I have paid the maintenance fee at least once but as I have been >using ICCAVR for years and also have three dongles I fell rather guilty. On >the other hand, it would be interesting to see your statistics for >downloaded upgrades compared to paid maintenance fees. (Minus the licenses >you sold last year). // richard (This email is for mailing lists. To reach me directly, please use richard at imagecraft.com) From david_brown at hotpop.com Mon Aug 13 00:59:43 2007 From: david_brown at hotpop.com (David Brown) Date: Mon Aug 13 00:43:57 2007 Subject: SV: [Icc-avr] A few more beginner questions In-Reply-To: <0MKpCa-1IKSUp3YOw-0006Y4@mrelay.perfora.net> References: <0MKpCa-1IKLRh0H0v-0006TL@mrelay.perfora.net> <072D96786BFC014AAEBA9EB07A8070EA285269@seattle.ecpower.dk> <0MKpCa-1IKSUp3YOw-0006Y4@mrelay.perfora.net> Message-ID: <46C00F6F.2050003@hotpop.com> Ira wrote: > At 10:03 PM 8/12/2007, you wrote: >> It's easer to see what you mean if we could see your output >> >> >> PORTB &= 253; >> PORTB &= ~2; > > The ~=2 generates the code for Clear Bit Immediate. > > The &= 253 code looks like copy PORTB to R24, AND R$ with 253 and then > copy R24 to PORTB > > Ira It's a matter of optimising for common patterns. The C language specifies that the two sides of "&" (or "&=") are promoted to 16-bit integers, and has no concept of CBI or SBI instructions. The icc-avr compiler has optimisations that spot certain common patterns, and generate better code than the naive 16-bit logic operations. In particular, it spots the "&= ~2" pattern but not the "&= 253" pattern (although in the latter case, it at least spots that it can do the logic as 8-bit, not 16-bit). The most common way of writing the bit clear is: PORTB &= ~0x02; Alternatives are things like PORTB &= ~(1 << 2); or (much better), using named macros that expand to one of these constructs. It is far better to write ~0x02 than 253 (note the use of two hex digits, not just a plain "2"), since it is much clearer. But even then, the "magic numbers" should be hidden within macro names defined in a header. From benra at imt.liu.se Mon Aug 13 00:56:53 2007 From: benra at imt.liu.se (Bengt Ragnemalm) Date: Mon Aug 13 01:07:10 2007 Subject: SV: SV: [Icc-avr] Reminder: maintenance contract renewal In-Reply-To: <200708130731.l7D7V2eY037473@dragonsgate2.imagecraft.com> References: <200708081915.l78JFsHw070411@dragonsgate2.imagecraft.com><005b01c7dd6f$7d8bf0e0$b160ec82@Shagrat> <200708130731.l7D7V2eY037473@dragonsgate2.imagecraft.com> Message-ID: <012001c7dd7f$838030f0$b160ec82@Shagrat> Ha-ha, well I hope you noticed that I said that I think $50 was fair. Also I said nothing about if a percentage comparison was very good to use in this case. (Of course it is not, you must count in some starting cost). A problem with this type of payment is of course that is a "free will" payment and it is easy to think "why should I pay if nobody else is paying". But most users here are very strict in the opinion that we shall not steal from small companies like you, we are very dependent of your success! I have seen requests for cracks once and I do not think anyone of us was very happy on him so to say. Also, you have been very kind and not included a lot of problematic security features that just creates problem for the users. For example on users loosing reg numbers. As there are sometimes student that use the software here on our department I use dongle protected version, that works perfectly. I for sure will pay the maintenance contract, for all three of our licenses. But you haven't stated the time for the contract in the shop even if one year should be a good guess. And I can promise you that I will not remember to pay next year so keep up sending reminders. Best regards, Bengt Keep up the good work > -----Ursprungligt meddelande----- > Fr?n: icc-avr-bounces@imagecraft.com [mailto:icc-avr- > bounces@imagecraft.com] F?r Richard > Skickat: den 13 augusti 2007 09:19 > 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: SV: [Icc-avr] Reminder: maintenance contract renewal > > Sure Bengt, for you only, the price of the compiler is now $1000. $50 > is now only 5%. Do you feel better for the deal now? > > Yes, we should make the maintenance more automatic and easier to pay. > More customers would probably pay if we remind them that way and if > it is very easy to pay. We are looking into that. > > As for distributor prices, some distributors have to include VAT > (Value Added Tax) or prices for advertising etc. > > I can assure you that very few of us are getting rich off this :-( > > At 11:02 PM 8/12/2007, Bengt Ragnemalm wrote: > >Well, I do not think $50 is ridiculously low (hm, this make me think of > >Harry Potter), but I think it is just fair. A problem is that you have to > >pay this of your own every year (is that the correct period?). It would > have > >been better if your distributor used an automatic method for this. Of > >course, that would mean the distributor would take some of the $... > > > >By the way, how come that it is cheaper to buy from you directly than > from a > >distributor? I find that odd as it may kill your distributors. OK, I got > a > >fancy manual and a CD that still is in it's plastic but as I do not need > it > >I thought I could bye whatever I want even from a distributor. > > > >$50 is 25% of the cost of the standard ICCAVR. As a comparision, I pay > about > >5% in maintenance fee for my CAD software (commercial standard version). > But > >5% maintenance fee for ICCAVR would really be ridiculously low. > > > >I know I have paid the maintenance fee at least once but as I have been > >using ICCAVR for years and also have three dongles I fell rather guilty. > On > >the other hand, it would be interesting to see your statistics for > >downloaded upgrades compared to paid maintenance fees. (Minus the > licenses > >you sold last year). > > // richard (This email is for mailing lists. To reach me directly, > please use richard at imagecraft.com) > > _______________________________________________ > Icc-avr mailing list > Icc-avr@imagecraft.com > http://dragonsgate.net/mailman/listinfo/icc-avr From j_baraclough at zetnet.co.uk Mon Aug 13 03:23:38 2007 From: j_baraclough at zetnet.co.uk (John Baraclough) Date: Mon Aug 13 03:35:18 2007 Subject: [Icc-avr] A few more beginner questions In-Reply-To: <0MKpCa-1IKLRh0H0v-0006TL@mrelay.perfora.net> References: <0MKpCa-1IKLRh0H0v-0006TL@mrelay.perfora.net> Message-ID: Ira, When asking a question, it would be helpful if you include some more context. For example, what are the macros that you use for 'ClrBit()' and 'SetBit()'. The generated code will depend very much on how they are written. As David has said, it always much better to use either hex numbers or the 'BIT()' macro when using any logic operation. Then the compiler has a better chance of understanding what you really want it to do. All the best for now, John At 22:57 12/08/2007, you wrote: >Hi > >I'm using an ATMega48. > >Why does my code work different when I use these 2 lines of code: > > PORTB &= 253; > PORTB |= 2; > >Then when I use: > > ClrBit(PORTB, 2); > SetBit(PORTB, 2); > >Well, that led to the discovery that these two lines of code >generate very different output even though it seems they should >generate the same output > > PORTB &= 253; > PORTB &= ~2; > >Ira > >_______________________________________________ >Icc-avr mailing list >Icc-avr@imagecraft.com >http://dragonsgate.net/mailman/listinfo/icc-avr > From jassenbaum at htp-tel.de Mon Aug 13 09:50:54 2007 From: jassenbaum at htp-tel.de (Johannes Assenbaum) Date: Mon Aug 13 10:00:36 2007 Subject: [Icc-avr] A few more beginner questions References: <0MKpCa-1IKLRh0H0v-0006TL@mrelay.perfora.net> <46BFEF38.3080507@pearless.co.nz> Message-ID: You must select a PWM "Waveform mode" (WGM). Best regards, Johannes > Hi, > I am struggling to get my ATmega16 to generate a square ware. I am > using the internal 1MHz oscillator (NO Crystal) and I am trying to use > PWM to get a 1Hz wave out on the pin. I am using ICCAVR 7.11, AVR > Studio 4.12 build 498 and a JTAGICE II. > The Application Builder gives the following output (I have tried all > sorts of combinations!!) and I would normally toggle the output bit > manually via the overflow interrupt, but reading the data sheet it seems > that the PWM should be able to be put to PD5/4 (OC1A / OC1B)??? > I seem to be missing something, help! > Cheers Douglas > code: > //ICC-AVR application builder : 13/08/2007 5:33:15 p.m. > // Target : M16 > // Crystal: 1.0000Mhz > #include > #include > void port_init(void) > { > PORTA = 0x00; > DDRA = 0x00; > PORTB = 0x00; > DDRB = 0x00; > PORTC = 0x00; //m103 output only > DDRC = 0x00; > PORTD = 0x00; > DDRD = 0xFF; > } > //TIMER1 initialize - prescale:1024 > // WGM: 0) Normal, TOP=0xFFFF > // desired value: 1Hz > // actual value: 1.001Hz (0.1%) > void timer1_init(void) > { > TCCR1B = 0x00; //stop > TCNT1H = 0xFC; //setup > TCNT1L = 0x30; > OCR1AH = 0x03; > OCR1AL = 0xD0; > OCR1BH = 0x03; > OCR1BL = 0xD0; > ICR1H = 0x03; > ICR1L = 0xD0; > TCCR1A = 0x40; > TCCR1B = 0x05; //start Timer > } > //call this routine to initialize all peripherals > void init_devices(void) > { > //stop errant interrupts until set up > CLI(); //disable all interrupts > port_init(); > timer1_init(); > MCUCR = 0x00; > GICR = 0x00; > TIMSK = 0x00; //timer interrupt sources > SEI(); //re-enable interrupts > //all peripherals are now initialized > } > // > void main(void) > { > init_devices(); > //insert your functional code here... > loop: goto loop; > } > -- > No virus found in this outgoing message. > Checked by AVG Free Edition. > Version: 7.5.476 / Virus Database: 269.11.15/949 - Release Date: 12/08/2007 11:03 > a.m. > _______________________________________________ > 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.476 / Virus Database: 269.11.17/951 - Release Date: 13.08.07 10:15 From j_baraclough at zetnet.co.uk Mon Aug 13 14:43:32 2007 From: j_baraclough at zetnet.co.uk (John Baraclough) Date: Mon Aug 13 14:55:17 2007 Subject: [Icc-avr] A few more beginner questions In-Reply-To: <46BFEF38.3080507@pearless.co.nz> References: <0MKpCa-1IKLRh0H0v-0006TL@mrelay.perfora.net> <46BFEF38.3080507@pearless.co.nz> Message-ID: From a message posted 2007-07-13: From: John Baraclough You can get a precise 100Hz output using Mode 8 (Frequency and Phase Correct PWM), but you will be limited to a resolution of 1/10000. OCR1A still provides you with the PWM that you require. The the prescalar is set to divide the 16MHz clock by 8 giving a timer clock of 2mHz. In Mode 8, the counter will count up to the TOP value contained in ICR1A and then count down to zero again. If this register is set to 10,000, then the frequency will be exactly 100Hz. The output pin will toggle as the count passes through the value contained in OCR1A. Bit COM1A0 controls the polarity of this toggling. Here's the setup code: void timer1_init(void) { TCCR1B = 0x00; // Stop Timer1 TCNT1H = 0x00; TCNT1L = 0x00; OCR1AH = 0x00; OCR1AL = 0x00; ICR1H = 0x27; // TOP == 10,000 ICR1L = 0x10; TCCR1A = BIT(COM1A1) | BIT(COM1A0) | ; // Note COM1A0 controls polarity of output pin. TCCR1B = BIT(WGM13) | BIT(CS11); // Start Timer1 } You can also get 100Hz PWM signals from OC1B and OC1C pins, with the same frequency and resolution. Unfortunately the Timer1 prescalar cannot be set to 4 or 2 which would improve the resolution considerably, but I would expect that 0.01% should be enough for most applications. HTH. All the best for now, John At 17:41 13/07/2007, you wrote: >I assume you want to use OC1A pin pb5. Make sure it is set to >output. App builder shows me mode 3 10 bit pwm with prescaler of 64 >gives 122Hz. Close enough? > >//TIMER1 initialize - prescale:64 >// WGM: 3) PWM 10bit phz correct, TOP=0x3FF >// desired value: 100Hz >// actual value: 122.190Hz (18.2%) >void timer1_init(void) >{ > TCCR1B = 0x00; //stop > TCNT1H = 0xFC; //setup > TCNT1L = 0x01; > OCR1AH = 0x03; > OCR1AL = 0xFF; > OCR1BH = 0x03; > OCR1BL = 0xFF; > OCR1CH = 0x03; > OCR1CL = 0xFF; > ICR1H = 0x03; > ICR1L = 0xFF; > TCCR1A = 0xC3; > TCCR1B = 0x03; //start Timer >} > >-----Original Message----- >From: Neil Emiro >Bcc: bobgardner@aol.com >Sent: Fri, 13 Jul 2007 12:01 pm >Subject: [Icc-avr] M128 PWM Basics > >I tried searching for this, but have not found a suitable example in >ICCAVR. I have never had to use the PWM function on an AVR >before. Now I do. My basic setup is this. I need to generate a >constant 100Hz signal with a 0-100 duty cycle. I have a M128 >running at 16.0MHz. I have tried the Application Builder in Mode 3 >of Timer 1, and get nothing out. If I use some of the phase correct >modes, I can get a signal, but altering what I thought would be duty >cycle, just changes the period. I have been slamming on this hard >enough, that I think I can't see the forrest for the trees. Do any >of you have a small coding example that would show the basics of how >to use PWM in this type of configuration? I really don't understand >why I get no output in Mode 3, but can in other modes. I guess I am >just not understanding the M128's datasheet. I have looked at cod! >ing examples under GCC, but I think I am getting lost in the >semantics of the differences between it and ICCAVR. Right now, I'm >in serious mental block mode. I have asked Richard about this, and >he suggested that I post up here. Thanks for any help! > >Neil V. Emiro At 06:42 13/08/2007, you wrote: >Hi, > >I am struggling to get my ATmega16 to generate a square ware. I am >using the internal 1MHz oscillator (NO Crystal) and I am trying to >use PWM to get a 1Hz wave out on the pin. I am using ICCAVR 7.11, >AVR Studio 4.12 build 498 and a JTAGICE II. > >The Application Builder gives the following output (I have tried all >sorts of combinations!!) and I would normally toggle the output bit >manually via the overflow interrupt, but reading the data sheet it >seems that the PWM should be able to be put to PD5/4 (OC1A / OC1B)??? > >I seem to be missing something, help! >Cheers Douglas > >code: > >//ICC-AVR application builder : 13/08/2007 5:33:15 p.m. >// Target : M16 >// Crystal: 1.0000Mhz > >#include >#include > >void port_init(void) >{ >PORTA = 0x00; >DDRA = 0x00; >PORTB = 0x00; >DDRB = 0x00; >PORTC = 0x00; //m103 output only >DDRC = 0x00; >PORTD = 0x00; >DDRD = 0xFF; >} > >//TIMER1 initialize - prescale:1024 >// WGM: 0) Normal, TOP=0xFFFF >// desired value: 1Hz >// actual value: 1.001Hz (0.1%) >void timer1_init(void) >{ >TCCR1B = 0x00; //stop >TCNT1H = 0xFC; //setup >TCNT1L = 0x30; >OCR1AH = 0x03; >OCR1AL = 0xD0; >OCR1BH = 0x03; >OCR1BL = 0xD0; >ICR1H = 0x03; >ICR1L = 0xD0; >TCCR1A = 0x40; >TCCR1B = 0x05; //start Timer >} > >//call this routine to initialize all peripherals >void init_devices(void) >{ >//stop errant interrupts until set up >CLI(); //disable all interrupts >port_init(); >timer1_init(); > >MCUCR = 0x00; >GICR = 0x00; >TIMSK = 0x00; //timer interrupt sources >SEI(); //re-enable interrupts >//all peripherals are now initialized >} > > >// >void main(void) >{ >init_devices(); >//insert your functional code here... >loop: goto loop; >} > > >-- >No virus found in this outgoing message. >Checked by AVG Free Edition. Version: 7.5.476 / Virus Database: >269.11.15/949 - Release Date: 12/08/2007 11:03 a.m. > >_______________________________________________ >Icc-avr mailing list >Icc-avr@imagecraft.com >http://dragonsgate.net/mailman/listinfo/icc-avr > From richard at imagecraft.com Tue Aug 14 03:05:24 2007 From: richard at imagecraft.com (Richard) Date: Tue Aug 14 03:17:36 2007 Subject: [Icc-avr] Product News Message-ID: <200708141017.l7EAHXTL058581@dragonsgate2.imagecraft.com> With all the developments going on, sometimes it is hard to keep track of things. There is also some rumors that we are emphasizing certain compilers less etc. so hopefully this email will also address some of those concerns. Obviously, we are in the business to make money, I have always believe that by providing excellent support, a decent development toolset, plus the low cost factor, that we would be able to make a decent living. I see no reason to change from that philosophy. ImageCraft is relatively speaking a small company, but then again, so is the embedded tools market. A million unit a year gadget may only need one copy of the compiler for development! This is a challenging market. There are gazillions devices out there, each with a potential market of only a few thousand compiler licenses in total at best. With multiple fishes in the pond, the feeding can get thin indeed. Then you have brilliant silicon manufacturers who think that it is in their best interest to have their own software tools, not caring that it is an effective way to drive away their third party tool vendors. So we have to adjust. We have to look at the potential markets and react, we have to change our development team setup, we have to look ahead and come up with effective strategies and tactics. Given this light, the last thing we want to do is to abandon our existing markets. While we believe the growth markets would likely be the AVR and ARM, there is no reason not to continue to develop for the HCS12 and MSP430 platforms. Especially with the new generations of the S12X and MSP430X devices coming in, the market potential is bigger than ever. But we need to be smarter. May be we should look into educational kits with detail examples and an easy to use board bundles. Perhaps we need to add more companion products such as a RTOS. May be we need to be more aggressive in making sure users pay for the annual maintenance.... Of course, coming from a techie background, most importantly, we have to continue to improve on our technologies. The MIO global optimizer is working well and we have come up with a plan to improve the performance further. We need to implement features like __far and __flash to support certain chip features better (paged function under S12 and flash items under AVR), and we need to deliver the 64 bits FP support. And we need to widen the net farther. We are very excited about the new Parallax Propeller chips. 8 32 bits core on a single chip. While it is not a microcontroller per se, the chip has a lot of potential. A Propeller C, which is under development, is potentially huge. Beyond that, the Atmel AVR32 is a natural target for us, and we have new resources with Eclipse expertise so we would be able to leverage the Studio32 platform from day one. Oh, BTW, relating to that, we will be releasing an AVR Studio plugin for ICCAVR soon and users than can use one single IDE for the AVR platform. All these take human, monetary and time resources. It is a challenging road we have chosen, but I am confident that we are set up to succeed. I thank you all for the support you have given us over the years. I hope this is useful information and I welcome any comments and suggestions you may have, either on the list or to me privately. Thank you. // richard From tobias.pflug at atm-computer.de Tue Aug 14 03:22:16 2007 From: tobias.pflug at atm-computer.de (Tobias Pflug) Date: Tue Aug 14 03:33:54 2007 Subject: [Icc-avr] Product News In-Reply-To: <200708141017.l7EAHXTL058581@dragonsgate2.imagecraft.com> References: <200708141017.l7EAHXTL058581@dragonsgate2.imagecraft.com> Message-ID: <1187086936.6134.8.camel@p57.atm-computer.de> On Tue, 2007-08-14 at 03:05 -0700, Richard wrote: > With all the developments going on, sometimes it is hard to keep > track of things. There is also some rumors that we are emphasizing > certain compilers less etc. so hopefully this email will also address > some of those concerns. [...rest cut...] I am not sure if this is the appropriate time and place but anyway: While I am a linux programmer and user and I only shortly dive into the AVR subject to support some other group at work I have to say the level of support and direct contact to imagecraft through this mailing list is very convenient and gives me as an end-user/customer a good feeling about using this product. My main concerns/wishes about imagecraft are that (a) there is no linux version and (b) the parallel use of AVR-Studio and the Imagecraft IDE is inappropriate and inconvenient. As I read in your mail, point (b) is being addressed already. Another point I would like to mention is that it would be nice to make the use of the compiler more transparent for usage without the IDE, making it possible for people who want to use the IDE and those who want to use something else more seamless. Just my 2 cents. Thank you. best regards, Tobias From richard-lists at imagecraft.com Tue Aug 14 12:51:00 2007 From: richard-lists at imagecraft.com (Richard) Date: Tue Aug 14 13:03:10 2007 Subject: [Icc-avr] Product News In-Reply-To: <1187086936.6134.8.camel@p57.atm-computer.de> References: <200708141017.l7EAHXTL058581@dragonsgate2.imagecraft.com> <1187086936.6134.8.camel@p57.atm-computer.de> Message-ID: <200708142003.l7EK39GQ065520@dragonsgate2.imagecraft.com> I meant to address the Linux issue earlier... First of all, what else do we need to do to make the compiler more transparent to use without the IDE? I know currently a number of people already use their own process with their choice of editor, etc. and either use the makefile created by the ICC IDE or write their own. As for Linux, it is trivial to have the command line compiler work under Linux. We in fact have Linux versions back in the late 90s. The issues are the GUI (the editor, project manager etc. are not that useful for Linux users, but the AppBuilder is nice), licensing engines and support. And of course the market size. In the end, it may be the easiest to recommend people to use WINE on Linux and Parallel on OSX, I am not sure... p.s. the Studio plugin should be ready for beta testing very soon.... At 03:22 AM 8/14/2007, Tobias Pflug wrote: >...My main concerns/wishes about imagecraft are that > >(a) there is no linux version >and >(b) the parallel use of AVR-Studio and the Imagecraft IDE is > inappropriate and inconvenient. > >As I read in your mail, point (b) is being addressed already. Another >point I would like to mention is that it would be nice to make the >use of the compiler more transparent for usage without the IDE, making >it possible for people who want to use the IDE and those who want to use >something else more seamless. // richard (This email is for mailing lists. To reach me directly, please use richard at imagecraft.com) From jassenbaum at htp-tel.de Tue Aug 14 14:04:23 2007 From: jassenbaum at htp-tel.de (Johannes Assenbaum) Date: Tue Aug 14 14:13:57 2007 Subject: [Icc-avr] io header files for new mega..p parts References: <6.1.0.6.2.20070227141947.079e8468@192.168.100.42> Message-ID: <0styCy0xQ9WAJcsxT3jWDLJCU38OcmABOIDDtpHG2lr@akmail> Hi all, if you need io header files for mega325(0)p, mega48p..328p or mega329(0)p right now, get updater here: http://avr.jassenbaum.de/iccv7avr/index.html Best regards Johannes From david_brown at hotpop.com Tue Aug 14 14:18:46 2007 From: david_brown at hotpop.com (David Brown) Date: Tue Aug 14 14:31:36 2007 Subject: [Icc-avr] Product News In-Reply-To: <200708142003.l7EK39GQ065520@dragonsgate2.imagecraft.com> References: <200708141017.l7EAHXTL058581@dragonsgate2.imagecraft.com> <1187086936.6134.8.camel@p57.atm-computer.de> <200708142003.l7EK39GQ065520@dragonsgate2.imagecraft.com> Message-ID: <46C21C36.4000202@hotpop.com> I'm one of these people who use the command-line version of the compiler - I only ever looked at the IDE briefly when I first started with icc-avr, and quickly realised that I would be much more productive with my usual editor and makefiles (but then, I work with a lot of different targets and a lot of different tools - learning "make", a couple of different editors, and assorted command line utilities is essential for that). I fully agree that there is little point in trying to make an IDE that works under Linux - it is simply not worth the time and effort it would take. Although the use of Linux is heavily increasing, even among those allergic to command prompts, the majority of people who are likely to run a compiler under Linux already use editors and makefiles. If you want to look at IDEs for Linux, think cross-platform - there are all sorts of development tools that let you make Windows and Linux applications from the same code base so that you don't duplicate your efforts. You could also look at basing your IDE on ready-made software. In particular, consider making a plugin for Eclipse to handle icc-avr specific makefiles and compiler options, along with an AppBuilder plugin. I know that Eclipse is pretty resource-heavy, but that's less of a problem with modern PC's, and this is the route that steadily more development tool companies are taking (big and small, open source and closed source). I don't know how other license-locked software works on Linux, but I can think of a couple of ideas for a fairly unobtrusive software lock (I can describe it in private email if you are interested), and USB access under Linux is easy enough for dongles. The big issue to consider when looking at embedded development under Linux is debugging - that is going to be complicated for different targets and different debugger hardware. mvh., David Richard wrote: > I meant to address the Linux issue earlier... First of all, what else do > we need to do to make the compiler more transparent to use without the > IDE? I know currently a number of people already use their own process > with their choice of editor, etc. and either use the makefile created by > the ICC IDE or write their own. > > As for Linux, it is trivial to have the command line compiler work under > Linux. We in fact have Linux versions back in the late 90s. The issues > are the GUI (the editor, project manager etc. are not that useful for > Linux users, but the AppBuilder is nice), licensing engines and support. > And of course the market size. In the end, it may be the easiest to > recommend people to use WINE on Linux and Parallel on OSX, I am not sure... > > p.s. the Studio plugin should be ready for beta testing very soon.... > > At 03:22 AM 8/14/2007, Tobias Pflug wrote: >> ...My main concerns/wishes about imagecraft are that >> >> (a) there is no linux version >> and >> (b) the parallel use of AVR-Studio and the Imagecraft IDE is >> inappropriate and inconvenient. >> >> As I read in your mail, point (b) is being addressed already. Another >> point I would like to mention is that it would be nice to make the >> use of the compiler more transparent for usage without the IDE, making >> it possible for people who want to use the IDE and those who want to use >> something else more seamless. > > // richard (This email is for mailing lists. To reach me directly, > please use richard at imagecraft.com) > _______________________________________________ > Icc-avr mailing list > Icc-avr@imagecraft.com > http://dragonsgate.net/mailman/listinfo/icc-avr From richard-lists at imagecraft.com Tue Aug 14 15:13:35 2007 From: richard-lists at imagecraft.com (Richard) Date: Tue Aug 14 15:25:45 2007 Subject: [Icc-avr] Product News In-Reply-To: <46C21C36.4000202@hotpop.com> References: <200708141017.l7EAHXTL058581@dragonsgate2.imagecraft.com> <1187086936.6134.8.camel@p57.atm-computer.de> <200708142003.l7EK39GQ065520@dragonsgate2.imagecraft.com> <46C21C36.4000202@hotpop.com> Message-ID: <200708142225.l7EMPiDs067806@dragonsgate2.imagecraft.com> At 02:18 PM 8/14/2007, David Brown wrote: >... > >If you want to look at IDEs for Linux, think cross-platform - there >are all sorts of development tools that let you make Windows and >Linux applications from the same code base so that you don't >duplicate your efforts. You could also look at basing your IDE on >ready-made software. In particular, consider making a plugin for >Eclipse to handle icc-avr specific makefiles and compiler options, >along with an AppBuilder plugin. I know that Eclipse is pretty >resource-heavy, but that's less of a problem with modern PC's, and >this is the route that steadily more development tool companies are >taking (big and small, open source and closed source). Eventually Eclipse plugin is the future, there is no doubt about that. When we do the AVR32 compiler (probably toward the end of the year), that's what we will go since Studio32 is Eclipse. Fortunately, we got a couple people with Open Source experience so the process should be smooth. I don't know if we will move to Eclipse based for the rest of the compilers any time soon, but it will probably be a matter of time. Currently Eclipse is still resource heavy, but as machines get faster and bigger still, it will not matter much. So certainly, when the time comes, we will go where Eclipse goes. Windows, Mac, Linux .... The kicker is of course that the compilers themselves are and will continue to be relatively lean. It's funny how the old resource intensive optimizations dwarfed in comparison to the modern IDEs!!! >I don't know how other license-locked software works on Linux, but I >can think of a couple of ideas for a fairly unobtrusive software >lock (I can describe it in private email if you are interested), and >USB access under Linux is easy enough for dongles. Yes, please send some info to me privately. Thanks! >The big issue to consider when looking at embedded development under >Linux is debugging - that is going to be complicated for different >targets and different debugger hardware. > >mvh., > >David > > > >Richard wrote: >>I meant to address the Linux issue earlier... First of all, what >>else do we need to do to make the compiler more transparent to use >>without the IDE? I know currently a number of people already use >>their own process with their choice of editor, etc. and either use >>the makefile created by the ICC IDE or write their own. >>As for Linux, it is trivial to have the command line compiler work >>under Linux. We in fact have Linux versions back in the late 90s. >>The issues are the GUI (the editor, project manager etc. are not >>that useful for Linux users, but the AppBuilder is nice), licensing >>engines and support. And of course the market size. In the end, it >>may be the easiest to recommend people to use WINE on Linux and >>Parallel on OSX, I am not sure... >>p.s. the Studio plugin should be ready for beta testing very soon.... >>At 03:22 AM 8/14/2007, Tobias Pflug wrote: >>>...My main concerns/wishes about imagecraft are that >>> >>>(a) there is no linux version >>>and >>>(b) the parallel use of AVR-Studio and the Imagecraft IDE is >>> inappropriate and inconvenient. >>> >>>As I read in your mail, point (b) is being addressed already. Another >>>point I would like to mention is that it would be nice to make the >>>use of the compiler more transparent for usage without the IDE, making >>>it possible for people who want to use the IDE and those who want to use >>>something else more seamless. // richard (This email is for mailing lists. To reach me directly, please use richard at imagecraft.com) From sbissonnette at microsyl.com Tue Aug 14 19:09:51 2007 From: sbissonnette at microsyl.com (Sylvain Bissonnette) Date: Tue Aug 14 18:23:34 2007 Subject: [Icc-avr] From ASM to C References: <200708141017.l7EAHXTL058581@dragonsgate2.imagecraft.com> <1187086936.6134.8.camel@p57.atm-computer.de> <200708142003.l7EK39GQ065520@dragonsgate2.imagecraft.com> <46C21C36.4000202@hotpop.com> <200708142225.l7EMPiDs067806@dragonsgate2.imagecraft.com> Message-ID: <000c01c7dee1$5d775ce0$0301a8c0@Sylvain> Hi, Long time ago Richard had give me this code (Thanks for!) but I want to port if in C and I don't have any knowleage of ASM. Any help will be usefull for me. Thanks Sylvain Bissonnette .if MEGATYPE64 | MEGATYPE128 SPMCR = 0x68 .else SPMCR = 0x57 .endif ;----------------------------------------- ; void write_page (unsigned int adr, unsigned char function); ; bits 8:15 adr addresses the page...(must setup RAMPZ beforehand!!!) _write_page:: XCALL __WAIT_SPMEN__ movw r30, r16 ;move address to z pointer (R31 = ZH, R30 = ZL) STS SPMCR, R18 ;argument 2 decides function SPM ;perform pagewrite RET ;----------------------------------------- ; void fill_temp_buffer (unsigned int data, unsigned int adr); ; bits 7:1 in adr addresses the word in the page... (2=first word, 4=second word etc..) _fill_temp_buffer:: XCALL __WAIT_SPMEN__ movw r30, r18 ;move adress to z pointer (R31=ZH R30=ZL) movw r0, r16 ;move data to reg 0 and 1 LDI R19, 0x01 STS SPMCR, R19 SPM ;Store program memory RET ;----------------------------------------- ;unsigned int read_program_memory (unsigned int adr ,unsigned char cmd); _read_program_memory:: movw r30, r16 ;move adress to z pointer SBRC R18, 0 ;read lockbits? (second argument = 0x09) STS SPMCR, R18 ;if so, place second argument in SPMEN register .if MEGATYPE128 ELPM r16, Z+ ;read LSB ELPM r17, Z ;read MSB .else LPM r16, Z+ LPM r17, Z .endif RET ;----------------------------------------- ;void write_lock_bits (unsigned char val); _write_lock_bits:: MOV R0, R16 LDI R17, 0x09 STS SPMCR, R17 SPM ;write lockbits RET ;----------------------------------------- _enableRWW:: XCALL __WAIT_SPMEN__ LDI R27,0x11 STS SPMCR,R27 SPM RET ;----------------------------------------- __WAIT_SPMEN__: LDS R27,SPMCR ; load SPMCR to R27 SBRC R27,0 ; check SPMEN flag RJMP __WAIT_SPMEN__ ; wait for SPMEN flag cleared RET ;----------------------------------------- From benra at imt.liu.se Tue Aug 14 23:18:29 2007 From: benra at imt.liu.se (Bengt Ragnemalm) Date: Tue Aug 14 23:28:41 2007 Subject: SV: [Icc-avr] Product News In-Reply-To: <200708141017.l7EAHXTL058581@dragonsgate2.imagecraft.com> References: <200708141017.l7EAHXTL058581@dragonsgate2.imagecraft.com> Message-ID: <001201c7df04$194983e0$b160ec82@Shagrat> ....ImageCraft is relatively speaking a small company, but then again, so > is the embedded tools market. A million unit a year gadget may only > need one copy of the compiler for development... Isn't it strange that the compiler company not take any license cost of the produced products? A producer of an extremely expensive compiler may not need to but why not do the other way around? A (almost) free compiler and a licence fee per sold unit. The licence fee could be higher for low volume and decreasing the for larger volumes. /Bengt From mark at extron.com.au Tue Aug 14 23:48:25 2007 From: mark at extron.com.au (Mark Barber) Date: Wed Aug 15 00:00:04 2007 Subject: [Icc-avr] Product News In-Reply-To: <001201c7df04$194983e0$b160ec82@Shagrat> References: <200708141017.l7EAHXTL058581@dragonsgate2.imagecraft.com> <001201c7df04$194983e0$b160ec82@Shagrat> Message-ID: <005201c7df08$47e60da0$6701a8c0@mark> Interesting point, Microsoft tried this many years back for one of their compilers, late 70's, and it never lasted. How would you manage it and enforce it. I make a couple of products that once up and running are sealed in epoxy resin for security. No one would ever know how many I have used or made. A good idea for the compiler company but not practical in its enforcement or application. Mark -----Original Message----- From: icc-avr-bounces@imagecraft.com [mailto:icc-avr-bounces@imagecraft.com] On Behalf Of Bengt Ragnemalm Sent: Wednesday, 15 August 2007 4:18 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] Product News ....ImageCraft is relatively speaking a small company, but then again, so > is the embedded tools market. A million unit a year gadget may only > need one copy of the compiler for development... Isn't it strange that the compiler company not take any license cost of the produced products? A producer of an extremely expensive compiler may not need to but why not do the other way around? A (almost) free compiler and a licence fee per sold unit. The licence fee could be higher for low volume and decreasing the for larger volumes. /Bengt _______________________________________________ Icc-avr mailing list Icc-avr@imagecraft.com http://dragonsgate.net/mailman/listinfo/icc-avr From david_brown at hotpop.com Wed Aug 15 02:22:04 2007 From: david_brown at hotpop.com (David Brown) Date: Wed Aug 15 02:06:19 2007 Subject: SV: [Icc-avr] Product News In-Reply-To: <001201c7df04$194983e0$b160ec82@Shagrat> References: <200708141017.l7EAHXTL058581@dragonsgate2.imagecraft.com> <001201c7df04$194983e0$b160ec82@Shagrat> Message-ID: <46C2C5BC.4040905@hotpop.com> Bengt Ragnemalm wrote: > ....ImageCraft is relatively speaking a small company, but then again, so >> is the embedded tools market. A million unit a year gadget may only >> need one copy of the compiler for development... > > Isn't it strange that the compiler company not take any license cost of the > produced products? A producer of an extremely expensive compiler may not > need to but why not do the other way around? A (almost) free compiler and a > licence fee per sold unit. The licence fee could be higher for low volume > and decreasing the for larger volumes. > > /Bengt Royalty models are very difficult to administer, and on a small scale the bureaucracy outweighs any profits. How does the compiler supplier and the production company keep track of the units and the licenses? It's not an insurmountable problem, but it takes a lot to get there. There is also the question of how attractive the model would be - it's a lot easier to budget for a one-off tools purchase than for continuous royalty costs. Royalties can be treated as a "component", but are still different enough to be a little awkward. What makes much more sense is to use the sort of model ImageCraft already has with the standard and professional editions of the tools. If you are working with small systems, then the standard version is fine. If you have a large enough volume that it makes sense to aim for minimum code size (and therefore smaller and cheaper flash), go for the professional version. Thus ImageCraft does, in fact, get paid a bit more for higher volume usage. mvh., David From edi.imhof.ml at ihe.ch Wed Aug 15 07:42:20 2007 From: edi.imhof.ml at ihe.ch (Edi Im Hof) Date: Wed Aug 15 07:54:16 2007 Subject: SV: [Icc-avr] Product News In-Reply-To: <46C2C5BC.4040905@hotpop.com> References: <200708141017.l7EAHXTL058581@dragonsgate2.imagecraft.com> <001201c7df04$194983e0$b160ec82@Shagrat> <46C2C5BC.4040905@hotpop.com> Message-ID: <46C310CC.5080305@ihe.ch> David Brown schrieb: > Bengt Ragnemalm wrote: >> ....ImageCraft is relatively speaking a small company, but then again, so >>> is the embedded tools market. A million unit a year gadget may only >>> need one copy of the compiler for development... >> >> Isn't it strange that the compiler company not take any license cost >> of the >> produced products? A producer of an extremely expensive compiler may not >> need to but why not do the other way around? A (almost) free compiler >> and a >> licence fee per sold unit. The licence fee could be higher for low volume >> and decreasing the for larger volumes. >> >> /Bengt I would stop using this compiler with a royalty licensing model. Too much bureaucracy and too complicated. Edi From rodney at junipersys.com Wed Aug 15 09:44:54 2007 From: rodney at junipersys.com (Rodney Pearson) Date: Wed Aug 15 09:56:51 2007 Subject: [Icc-avr] From ASM to C In-Reply-To: <000c01c7dee1$5d775ce0$0301a8c0@Sylvain> References: <200708141017.l7EAHXTL058581@dragonsgate2.imagecraft.com><1187086936.6134.8.camel@p57.atm-computer.de><200708142003.l7EK39GQ065520@dragonsgate2.imagecraft.com><46C21C36.4000202@hotpop.com><200708142225.l7EMPiDs067806@dragonsgate2.imagecraft.com> <000c01c7dee1$5d775ce0$0301a8c0@Sylvain> Message-ID: Sylvain - It is best to keep this code in ASM due to timing requirements when using the SPM instructions. Also, unless some else knows differently, the C compiler has no knowledge of how to implement SPM/LPM/ELP as they are used below in ASM. That is why they are in ASM =) Any particular reason you want to move these into C? Beside being unfamiliar with ASM? 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 Sylvain Bissonnette Sent: Tuesday, August 14, 2007 8:10 PM To: Discussion list for ICCAVR and ICCtiny Users. You do NOT needtosubscribetoicc-announce if you are a member of this. Subject: [Icc-avr] From ASM to C Hi, Long time ago Richard had give me this code (Thanks for!) but I want to port if in C and I don't have any knowleage of ASM. Any help will be usefull for me. Thanks Sylvain Bissonnette .if MEGATYPE64 | MEGATYPE128 SPMCR = 0x68 .else SPMCR = 0x57 .endif ;----------------------------------------- ; void write_page (unsigned int adr, unsigned char function); ; bits 8:15 adr addresses the page...(must setup RAMPZ beforehand!!!) _write_page:: XCALL __WAIT_SPMEN__ movw r30, r16 ;move address to z pointer (R31 = ZH, R30 = ZL) STS SPMCR, R18 ;argument 2 decides function SPM ;perform pagewrite RET ;----------------------------------------- ; void fill_temp_buffer (unsigned int data, unsigned int adr); ; bits 7:1 in adr addresses the word in the page... (2=first word, 4=second word etc..) _fill_temp_buffer:: XCALL __WAIT_SPMEN__ movw r30, r18 ;move adress to z pointer (R31=ZH R30=ZL) movw r0, r16 ;move data to reg 0 and 1 LDI R19, 0x01 STS SPMCR, R19 SPM ;Store program memory RET ;----------------------------------------- ;unsigned int read_program_memory (unsigned int adr ,unsigned char cmd); _read_program_memory:: movw r30, r16 ;move adress to z pointer SBRC R18, 0 ;read lockbits? (second argument = 0x09) STS SPMCR, R18 ;if so, place second argument in SPMEN register .if MEGATYPE128 ELPM r16, Z+ ;read LSB ELPM r17, Z ;read MSB .else LPM r16, Z+ LPM r17, Z .endif RET ;----------------------------------------- ;void write_lock_bits (unsigned char val); _write_lock_bits:: MOV R0, R16 LDI R17, 0x09 STS SPMCR, R17 SPM ;write lockbits RET ;----------------------------------------- _enableRWW:: XCALL __WAIT_SPMEN__ LDI R27,0x11 STS SPMCR,R27 SPM RET ;----------------------------------------- __WAIT_SPMEN__: LDS R27,SPMCR ; load SPMCR to R27 SBRC R27,0 ; check SPMEN flag RJMP __WAIT_SPMEN__ ; wait for SPMEN flag cleared RET ;----------------------------------------- _______________________________________________ Icc-avr mailing list Icc-avr@imagecraft.com http://dragonsgate.net/mailman/listinfo/icc-avr From richard-lists at imagecraft.com Wed Aug 15 12:59:5