From sidprice at softtools.com Sat Jan 3 10:08:26 2009 From: sidprice at softtools.com (Sid Price) Date: Sat Jan 3 11:14:17 2009 Subject: [Icc-avr] Problem reading program memory In-Reply-To: <0E755D4F91B6D344B39791054F52A2A905C7645F@gbexchange.bankspower.local> References: <49C038D6F09744A5AA4BC1148D685A1B@SID004> <0E755D4F91B6D344B39791054F52A2A905C7645F@gbexchange.bankspower.local> Message-ID: Seems I have a VERY dumb mistake here; I checked my project settings and the micro selected was an atmega163, the SRAM on that device is in a different place than the atmega164p, just about as dumb a mistake as one can make I guess. However this brings me to a second problem and that is that v6 of the compiler does not have a selection for the atmega164p so I am trying to use the custom setting, I think I have things set correctly but when I try to build I get a message that "'' is not a valid integer" but no other indication of what is wrong. Does anyone have any suggestions for what may be wrong or maybe the settings that work for a 164p? Many thanks, Sid. Sid Price Software Design _____ From: icc-avr-bounces@imagecraft.com [mailto:icc-avr-bounces@imagecraft.com] On Behalf Of David Raymond Sent: Monday, December 29, 2008 9:22 AM To: sidprice@softtools.com; Discussion list for ICCAVR and ICCtiny Users. You do NOT needtosubscribeto icc-announce if you are a member of this. Subject: RE: [Icc-avr] Problem reading program memory Your code is identical to mine, which works on a Mega128, except I make sure interrupts are disabled. Most people do not use interrupts in a bootloader so this may not be your problem. Dave Raymond Software Engineer Gale Banks Engineering Ph (626) 969-9600 x3301 Fx (626) 334-2376 Visit us on the Web: www.bankspower.com E-mail: draymond@bankspower.com _____ From: icc-avr-bounces@imagecraft.com [mailto:icc-avr-bounces@imagecraft.com] On Behalf Of Sid Price Sent: Saturday, December 27, 2008 2:57 PM To: icc-avr@imagecraft.com Subject: [Icc-avr] Problem reading program memory I am working on a bootloader for the atmega164p, based upon the MicroSyl code. I have the first page (128 bytes) of code loading and programming correctly into the flash however the verification of the code by recalculating the checksum is failing unless I single step the code and then the checksum is correct. This suggests some kind of timing issue but I am not sure where. I have changed the processor just in case there was a real hardware issue and the results were the same. The code that reads the program memory is this: read_program_memory:: movw r30, r16 SBRC R18, 0 STS SPMCR, R18 ELPM r16, Z+ ELPM r17, Z RET The processor is set up using an external 8MHz crystal, CKDIV is unprogrammed. Any comments much appreciated, Sid. ****verified by GBE SPAM FILTER**** -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20090103/9b90492a/attachment.html From andrew_166 at msn.com Sun Jan 4 20:04:57 2009 From: andrew_166 at msn.com (Andrew) Date: Sun Jan 4 21:10:23 2009 Subject: [Icc-avr] String Question In-Reply-To: <664A08FA68194943BDD11F841E7D55F0@Shagrat><200808150948.m7F9mkkN058145@mail.imagecraft.com><05EF9FFB331A47DB916A8398F28BCF45@Shagrat><66680761C9744738A5BC9550E934E10E@Shagrat><0C3FA4B69B124EF8B17B390F7467971E@Shagrat><200808151940.m7FJeXQY066103@mail.imagecraft.com><4C4242E0F9C240559AAF9C00FDCF9E4B@Shagrat><200808180927.m7I9RRxm017684@mail.imagecraft.com><35ECDAA83E1C40C489CC77B94DEA242B@Shagrat> <200808212044.m7LKioEw004305@mail.imagecraft.com><7E54A6C77EA54AC284353D5D59159EFD@Shagrat> <48AEC0D5.5020008@cox.net> References: <664A08FA68194943BDD11F841E7D55F0@Shagrat><200808150948.m7F9mkkN058145@mail.imagecraft.com><05EF9FFB331A47DB916A8398F28BCF45@Shagrat><66680761C9744738A5BC9550E934E10E@Shagrat><0C3FA4B69B124EF8B17B390F7467971E@Shagrat><200808151940.m7FJeXQY066103@mail.imagecraft.com><4C4242E0F9C240559AAF9C00FDCF9E4B@Shagrat><200808180927.m7I9RRxm017684@mail.imagecraft.com><35ECDAA83E1C40C489CC77B94DEA242B@Shagrat> <200808212044.m7LKioEw004305@mail.imagecraft.com><7E54A6C77EA54AC284353D5D59159EFD@Shagrat> <48AEC0D5.5020008@cox.net> Message-ID: Hi, I am writing an application that requires allot of strings to be stored as I have an attached device that requires allot of AT commands to be sent to it via the UART, at specific times. My question is if I have the following function: - ********************** Code **************** void UART232_Char(char data) { while (!(UCSR0A & (1 << UDRE0))); // Wait for empty transmit buffer UDR0 = data; // Start transmition } ******************** End Code ************ and i make the following call :- UART232_Char("Hello World"): is the string "Hello World" compiled in flash only or does it use up valuable RAM? If it is stored in flash only then it is ok, if not will doing the following make it stay in RAM:- #define STR "Hello World" Or does this just do the same thing (as i suspect)? I am guessing that it will do the same thing, and the only way to make the string stay in flash is to define it as follows:- __flash str(11) as char = {"Hello World"}; or tick the 'Strings in flash only' in the project options. But then my UART232_Char(char data) function will not work as it is expecting a pointer to a char not a flash pointer, so in this case would i need two send functions one for my flash stored strings and another to print out my ram stored strings? The reason i ask is that am trying to save some RAM as i need to add some large variables. Thanks Andy -------------------------------------------------- From: "Jim Patchell" Sent: Friday, August 22, 2008 1:36 PM To: ; "Discussion list for ICCAVR and ICCtiny Users. You do NOT need tosubscribe to icc-announce if you are a member of this." Subject: Re: SV: SV: SV: SV: [Icc-avr] Stack problems > It comes with practice... > > Where I work, first thing I tell C newbies: > > Never put arrays on the stack (auto variables/local variables)...it is > just bad practice, especially in an embedded controller. > > Stack problems are very difficult to track down. > > -Jim > > Bengt Ragnemalm wrote: >> I understand the problem that only generating obvious errors could give >> you >> a false safety but all errors that can be generated is good errors in my >> point of view. >> >> I still feel a little lost in what to do to check that I do not use too >> many >> local variables. The example below will be the same regardless if the >> array is used in a >> function or in main. >> >> /Bengt >> >> ============= >> The code could be for example be this: (Full program) >> >> #include >> #include >> >> void Function(void) >> { >> unsigned char array[3000]; // RAM is 2k >> unsigned short index; >> array[index]=0; >> index = 3000; >> array[index]=0; // Writing in cyberspace >> } >> >> void main(void) >> { >> Function(); >> } >> ============= >> >> The map file: >> >> Map File Summary V3.2.3 for IccV7 AVR >> run at 2008-08-22 10:36:44 >> on project "\\Annatar\benra\Projekt\Slask\SLASK" >> >> Memory summary: >> >> flash size is 8192 bytes (8KB) >> flash used for >> - int vectors = 52 (0x34) bytes from 0x0000 to 0x0033 = 26 (0x1A) >> instruction words from 0x0000 to 0x0019 >> - code = 290 (0x122) bytes from 0x0034 to 0x0155 = 145 (0x91) >> instruction words) from 0x001A to 0x00AA >> +- user code : -52 (0x-,) bytes from 0x0034 to 0x000/ = -26 (0x/&) >> instruction words) from 0x001A to 0x000/ >> +- : 342 (0x156) bytes from 0x0000 to 0x0155 = 171 (0xAB) >> instruction words) from 0x0000 to 0x00AA >> flash usage is 342 bytes or 4.2%, leaving 7850 bytes (7KB) free >> >> sram size is 1024 bytes (1KB) >> sram used for >> - s/w stack = 994 (0x3E2) bytes from 0x0100 to 0x04E1 >> - h/w stack = 30 (0x1E) bytes from 0x04E2 to 0x04FF >> >> eeprom size is 512 bytes >> no eeprom area found >> >> >> Areas: >> (items sorted by name) >> >> FLASH area "text" used for code >> FLASH area "text" = 290 (0x122) bytes from 0x0034 to 0x0155 = 145 (0x91) >> instruction words from 0x001A to 0x00AA >> _Function = 110 (0x006E) words >> __start = 33 (0x0021) words >> _exit = 1 (0x0001) word >> _main = 1 (0x0001) word >> >> FLASH area "vector" used for interrupt vectors >> FLASH area "vector" = 2 (0x02) bytes from 0x0000 to 0x0001 = 1 (0x01) >> instruction words from 0x0000 to 0x0000 >> >> >> >> >> >>> -----Ursprungligt meddelande----- >>> Fr?n: icc-avr-bounces@imagecraft.com [mailto:icc-avr- >>> bounces@imagecraft.com] F?r Richard Man >>> Skickat: den 21 augusti 2008 21:42 >>> Till: icc-avr@imagecraft.com >>> ?mne: Re: SV: SV: SV: [Icc-avr] Stack problems >>> >>> Currently, the compiler does not do any check on the local variables, >>> because any checking would be at best a guess (unless it does full >>> call tree analysis and layout all the SRAM usage). While it can >>> clearly complain in the obvious cases, it will do a lousy job overall >>> and then people will complain about false security. >>> >>> If you look at the View->"Map File Summary" it gives you an estimate >>> on how big the software stack can be. Generally speaking, you >>> shouldn't be pushing the limit of the SRAM, so it should be farily >>> easy for you to see what your margins are. If you are really pushing >>> the limit, you would need to check and test carefully anyway. >>> >>> At 05:55 AM 8/21/2008, Bengt Ragnemalm wrote: >>>> One more question about this. >>>> >>>> If I declare a local array that is larger than the RAM, I do not get an >>>> error. Is that because the compiler can not be sure that this array >>>> will >>>> actually be placed in RAM as it can point to anything? >>>> >>> // richard (This email is for mailing lists. To reach me directly, >>> please use richard at imagecraft.com) >>> >>> _______________________________________________ >>> Icc-avr mailing list >>> Icc-avr@imagecraft.com >>> http://dragonsgate.net/mailman/listinfo/icc-avr >> >> >> _______________________________________________ >> Icc-avr mailing list >> Icc-avr@imagecraft.com >> http://dragonsgate.net/mailman/listinfo/icc-avr >> >> > > -- > ---------------------------------------------- > Visit http://www.noniandjim.com > SDIY: http://www.noniandjim.com/Jim/index.html > ---------------------------------------------- > > _______________________________________________ > Icc-avr mailing list > Icc-avr@imagecraft.com > http://dragonsgate.net/mailman/listinfo/icc-avr > From k.reimann at trillian.de Mon Jan 5 02:38:56 2009 From: k.reimann at trillian.de (Karlheinz Reimann) Date: Mon Jan 5 03:44:53 2009 Subject: [Icc-avr] Problem reading program memory In-Reply-To: References: <49C038D6F09744A5AA4BC1148D685A1B@SID004> <0E755D4F91B6D344B39791054F52A2A905C7645F@gbexchange.bankspower.local> Message-ID: <4961E340.3010900@trillian.de> Sid Price schrieb: > Seems I have a VERY dumb mistake here; I checked my project settings and the > micro selected was an atmega163, the SRAM on that device is in a different > place than the atmega164p, just about as dumb a mistake as one can make I > guess. > > However this brings me to a second problem and that is that v6 of the > compiler does not have a selection for the atmega164p so I am trying to use > the custom setting, I think I have things set correctly but when I try to > build I get a message that "'' is not a valid integer" but no other > indication of what is wrong. > > Does anyone have any suggestions for what may be wrong or maybe the settings > that work for a 164p? > select a atmega163, switch to custom and then change the text addres AND the data address to 0x100 From k.reimann at trillian.de Mon Jan 5 02:51:58 2009 From: k.reimann at trillian.de (Karlheinz Reimann) Date: Mon Jan 5 03:57:56 2009 Subject: [Icc-avr] String Question In-Reply-To: References: <664A08FA68194943BDD11F841E7D55F0@Shagrat><200808150948.m7F9mkkN058145@mail.imagecraft.com><05EF9FFB331A47DB916A8398F28BCF45@Shagrat><66680761C9744738A5BC9550E934E10E@Shagrat><0C3FA4B69B124EF8B17B390F7467971E@Shagrat><200808151940.m7FJeXQY066103@mail.imagecraft.com><4C4242E0F9C240559AAF9C00FDCF9E4B@Shagrat><200808180927.m7I9RRxm017684@mail.imagecraft.com><35ECDAA83E1C40C489CC77B94DEA242B@Shagrat> <200808212044.m7LKioEw004305@mail.imagecraft.com><7E54A6C77EA54AC284353D5D59159EFD@Shagrat> <48AEC0D5.5020008@cox.net> Message-ID: <4961E64E.7050308@trillian.de> Andrew schrieb: > Hi, > > I am writing an application that requires allot of strings to be stored > as I have an attached device that requires allot of AT commands to be > sent to it via the UART, at specific times. > > > My question is if I have the following function: - > > ********************** Code **************** > > void UART232_Char(char data) > { > while (!(UCSR0A & (1 << UDRE0))); // Wait for empty transmit buffer > UDR0 = data; // Start transmition > } > > ******************** End Code ************ > > > and i make the following call :- > > UART232_Char("Hello World"): your function sends only one character, not a zero terminated string! > > is the string "Hello World" compiled in flash only or does it use up > valuable RAM? > > If it is stored in flash only then it is ok, if not will doing the > following make it stay in RAM:- > > #define STR "Hello World" > > Or does this just do the same thing (as i suspect)? yes, it's the same. The preprocessor only substitutes the string STR > > I am guessing that it will do the same thing, and the only way to make > the string stay in flash is to define it as follows:- > > __flash str(11) as char = {"Hello World"}; may be i'm wrong, but that needs to be: __flash str[] = "Hello World"; > > or tick the 'Strings in flash only' in the project options. > > But then my UART232_Char(char data) function will not work as it is > expecting a pointer to a char not a flash pointer, so in this case would > i need two send functions one for my flash stored strings and another to > print out my ram stored strings? yes! If you have enough space in program memory, you may use the library functions (printf, cprintf, puts, etc). There are funtions for ram variables and for const (flash) variables. Good luck Karl Reimann From sidprice at softtools.com Mon Jan 5 08:21:20 2009 From: sidprice at softtools.com (Sid Price) Date: Mon Jan 5 09:27:15 2009 Subject: [Icc-avr] Problem reading program memory In-Reply-To: <4961E340.3010900@trillian.de> References: <49C038D6F09744A5AA4BC1148D685A1B@SID004> <0E755D4F91B6D344B39791054F52A2A905C7645F@gbexchange.bankspower.local> <4961E340.3010900@trillian.de> Message-ID: <955C8EBDBA5B4373A430458C665D943E@SID004> Thank you, Sid. Sid Price Software Design -----Original Message----- From: icc-avr-bounces@imagecraft.com [mailto:icc-avr-bounces@imagecraft.com] On Behalf Of Karlheinz Reimann Sent: Monday, January 05, 2009 3:39 AM To: Discussion list for ICCAVR and ICCtiny Users. You do NOT need tosubscribe to icc-announce if you are a member of this. Subject: Re: [Icc-avr] Problem reading program memory Sid Price schrieb: > Seems I have a VERY dumb mistake here; I checked my project settings and the > micro selected was an atmega163, the SRAM on that device is in a different > place than the atmega164p, just about as dumb a mistake as one can make I > guess. > > However this brings me to a second problem and that is that v6 of the > compiler does not have a selection for the atmega164p so I am trying to use > the custom setting, I think I have things set correctly but when I try to > build I get a message that "'' is not a valid integer" but no other > indication of what is wrong. > > Does anyone have any suggestions for what may be wrong or maybe the settings > that work for a 164p? > select a atmega163, switch to custom and then change the text addres AND the data address to 0x100 _______________________________________________ Icc-avr mailing list Icc-avr@imagecraft.com http://dragonsgate.net/mailman/listinfo/icc-avr From andrew_166 at msn.com Mon Jan 5 11:45:58 2009 From: andrew_166 at msn.com (Andrew) Date: Mon Jan 5 12:51:48 2009 Subject: [Icc-avr] String Question In-Reply-To: <664A08FA68194943BDD11F841E7D55F0@Shagrat><200808150948.m7F9mkkN058145@mail.imagecraft.com><05EF9FFB331A47DB916A8398F28BCF45@Shagrat><66680761C9744738A5BC9550E934E10E@Shagrat><0C3FA4B69B124EF8B17B390F7467971E@Shagrat><200808151940.m7FJeXQY066103@mail.imagecraft.com><4C4242E0F9C240559AAF9C00FDCF9E4B@Shagrat><200808180927.m7I9RRxm017684@mail.imagecraft.com><35ECDAA83E1C40C489CC77B94DEA242B@Shagrat> <200808212044.m7LKioEw004305@mail.imagecraft.com><7E54A6C77EA54AC284353D5D59159EFD@Shagrat> <48AEC0D5.5020008@cox.net> <4961E64E.7050308@trillian.de> References: <664A08FA68194943BDD11F841E7D55F0@Shagrat><200808150948.m7F9mkkN058145@mail.imagecraft.com><05EF9FFB331A47DB916A8398F28BCF45@Shagrat><66680761C9744738A5BC9550E934E10E@Shagrat><0C3FA4B69B124EF8B17B390F7467971E@Shagrat><200808151940.m7FJeXQY066103@mail.imagecraft.com><4C4242E0F9C240559AAF9C00FDCF9E4B@Shagrat><200808180927.m7I9RRxm017684@mail.imagecraft.com><35ECDAA83E1C40C489CC77B94DEA242B@Shagrat> <200808212044.m7LKioEw004305@mail.imagecraft.com><7E54A6C77EA54AC284353D5D59159EFD@Shagrat> <48AEC0D5.5020008@cox.net> <4961E64E.7050308@trillian.de> Message-ID: Hi, Sorry i had posted the wrong function for my string sender, anyway i have written another for sending constant strings: - ****************** CODE ********************* void UART232_CString(unsigned const char* string) { while(*string) // Send String { while(!(UCSR0A & (1 << UDRE0))); // Wait until Tx fifo empty, if necessary UDR0 = *string++; // Fill FIFO } } ****************** CODE ********************* So if i create my const string as follows : - unsigned const char HELLO[] = {"Hello World"}; ** Note sure how i would do this as a define as currently all my strings are in the following format : - #define HELLO "Hello World" and then call my function: - UART232_CString(HELLO); will this onlt store the string in flash? or do i need to define the string as :- __flash unsigned char HELLO[]={"Hello World"}; and change my UART232_CString() function? I don't think i can rick the "Strings in flash only option" in the project settings as i am using alot of string function (copy, move, compare etc) and i am not sure if this will effect them. I don't really need to use the printf etc functions as i have prefer to use my own as they sould be faster and take less flash space up. Many Thanks, Andy -------------------------------------------------- From: "Karlheinz Reimann" Sent: Monday, January 05, 2009 10:51 AM To: "Discussion list for ICCAVR and ICCtiny Users. You do NOT need tosubscribe to icc-announce if you are a member of this." Subject: Re: [Icc-avr] String Question > Andrew schrieb: >> Hi, >> >> I am writing an application that requires allot of strings to be stored >> as I have an attached device that requires allot of AT commands to be >> sent to it via the UART, at specific times. >> >> >> My question is if I have the following function: - >> >> ********************** Code **************** >> >> void UART232_Char(char data) >> { >> while (!(UCSR0A & (1 << UDRE0))); // Wait for empty transmit >> buffer >> UDR0 = data; // Start transmition >> } >> >> ******************** End Code ************ >> >> >> and i make the following call :- >> >> UART232_Char("Hello World"): > > your function sends only one character, not a zero terminated string! > >> >> is the string "Hello World" compiled in flash only or does it use up >> valuable RAM? >> >> If it is stored in flash only then it is ok, if not will doing the >> following make it stay in RAM:- >> >> #define STR "Hello World" >> >> Or does this just do the same thing (as i suspect)? > > yes, it's the same. The preprocessor only substitutes the string STR > >> >> I am guessing that it will do the same thing, and the only way to make >> the string stay in flash is to define it as follows:- >> >> __flash str(11) as char = {"Hello World"}; > > may be i'm wrong, but that needs to be: > __flash str[] = "Hello World"; > >> >> or tick the 'Strings in flash only' in the project options. >> >> But then my UART232_Char(char data) function will not work as it is >> expecting a pointer to a char not a flash pointer, so in this case would >> i need two send functions one for my flash stored strings and another to >> print out my ram stored strings? > > yes! If you have enough space in program memory, you may use the library > functions (printf, cprintf, puts, etc). There are funtions for ram > variables and for const (flash) variables. > > Good luck > Karl Reimann > > _______________________________________________ > Icc-avr mailing list > Icc-avr@imagecraft.com > http://dragonsgate.net/mailman/listinfo/icc-avr > From Albert.vanVeen at pertronic.co.nz Mon Jan 5 16:26:45 2009 From: Albert.vanVeen at pertronic.co.nz (Albert vanVeen) Date: Mon Jan 5 17:32:31 2009 Subject: [Icc-avr] String Question In-Reply-To: References: <664A08FA68194943BDD11F841E7D55F0@Shagrat><200808150948.m7F9mkkN058145@mail.imagecraft.com><05EF9FFB331A47DB916A8398F28BCF45@Shagrat><66680761C9744738A5BC9550E934E10E@Shagrat><0C3FA4B69B124EF8B17B390F7467971E@Shagrat><200808151940.m7FJeXQY066103@mail.imagecraft.com><4C4242E0F9C240559AAF9C00FDCF9E4B@Shagrat><200808180927.m7I9RRxm017684@mail.imagecraft.com><35ECDAA83E1C40C489CC77B94DEA242B@Shagrat> <200808212044.m7LKioEw004305@mail.imagecraft.com><7E54A6C77EA54AC284353D5D59159EFD@Shagrat> <48AEC0D5.5020008@cox.net><4961E64E.7050308@trillian.de> Message-ID: <5F8515C5ED67B6439B4F93D7B5E08A36063EB5@sbs.pertronic.local> I don't want to come across all negative, but may I make a general suggestion regarding this type of questions: Why don't you try out 2 or 3 of your possibilities, and then look in the map (or listing) what the result is? You can then safely draw your conclusions without relying on other people's opinions. Greetings, Albert. -----Original Message----- From: icc-avr-bounces@imagecraft.com [mailto:icc-avr-bounces@imagecraft.com] On Behalf Of Andrew Sent: Tuesday, January 06, 2009 08:46 AM To: Discussion list for ICCAVR and ICCtiny Users. You do NOT needtosubscribeto icc-announce if you are a member of this. Subject: Re: [Icc-avr] String Question Importance: High Hi, Sorry i had posted the wrong function for my string sender, anyway i have written another for sending constant strings: - ****************** CODE ********************* void UART232_CString(unsigned const char* string) { while(*string) // Send String { while(!(UCSR0A & (1 << UDRE0))); // Wait until Tx fifo empty, if necessary UDR0 = *string++; // Fill FIFO } } ****************** CODE ********************* So if i create my const string as follows : - unsigned const char HELLO[] = {"Hello World"}; ** Note sure how i would do this as a define as currently all my strings are in the following format : - #define HELLO "Hello World" and then call my function: - UART232_CString(HELLO); will this onlt store the string in flash? or do i need to define the string as :- __flash unsigned char HELLO[]={"Hello World"}; and change my UART232_CString() function? I don't think i can rick the "Strings in flash only option" in the project settings as i am using alot of string function (copy, move, compare etc) and i am not sure if this will effect them. I don't really need to use the printf etc functions as i have prefer to use my own as they sould be faster and take less flash space up. Many Thanks, Andy -------------------------------------------------- From: "Karlheinz Reimann" Sent: Monday, January 05, 2009 10:51 AM To: "Discussion list for ICCAVR and ICCtiny Users. You do NOT need tosubscribe to icc-announce if you are a member of this." Subject: Re: [Icc-avr] String Question > Andrew schrieb: >> Hi, >> >> I am writing an application that requires allot of strings to be >> stored as I have an attached device that requires allot of AT >> commands to be sent to it via the UART, at specific times. >> >> >> My question is if I have the following function: - >> >> ********************** Code **************** >> >> void UART232_Char(char data) >> { >> while (!(UCSR0A & (1 << UDRE0))); // Wait for empty transmit >> buffer >> UDR0 = data; // Start transmition >> } >> >> ******************** End Code ************ >> >> >> and i make the following call :- >> >> UART232_Char("Hello World"): > > your function sends only one character, not a zero terminated string! > >> >> is the string "Hello World" compiled in flash only or does it use up >> valuable RAM? >> >> If it is stored in flash only then it is ok, if not will doing the >> following make it stay in RAM:- >> >> #define STR "Hello World" >> >> Or does this just do the same thing (as i suspect)? > > yes, it's the same. The preprocessor only substitutes the string STR > >> >> I am guessing that it will do the same thing, and the only way to >> make the string stay in flash is to define it as follows:- >> >> __flash str(11) as char = {"Hello World"}; > > may be i'm wrong, but that needs to be: > __flash str[] = "Hello World"; > >> >> or tick the 'Strings in flash only' in the project options. >> >> But then my UART232_Char(char data) function will not work as it is >> expecting a pointer to a char not a flash pointer, so in this case >> would i need two send functions one for my flash stored strings and >> another to print out my ram stored strings? > > yes! If you have enough space in program memory, you may use the > library functions (printf, cprintf, puts, etc). There are funtions for > ram variables and for const (flash) variables. > > Good luck > Karl Reimann > > _______________________________________________ > 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 -- This message has been scanned for viruses and dangerous content by Bizo EmailFilter, and is believed to be clean. From richard at imagecraft.com Sat Jan 10 23:19:42 2009 From: richard at imagecraft.com (Richard Man) Date: Sun Jan 11 00:24:18 2009 Subject: [Icc-avr] ICCAVR V7.20 Released Message-ID: <200901110824.n0B8O6pb000438@mail.imagecraft.com> Happy New Year! V7.20 Jan 10th, 2009 [ Enabled -NC Non-Commercial Use license] IDE - For XMega128, add the -xcall flag so 22-bit relocation will be used for CALL instructions since the bootloader flash is beyond the 128K byte boundary. Compiler - Fixed a very obscure bug with ldd offset expansion. - For XMega, 16 bits writes are now done low byte first to conform to the IO register access requirement - Faster code to load a constant into longs. // richard blog: On-line orders, support, and listservers available on web site. [ For technical support on ImageCraft products, please include all previous replies in your msgs. ] From sl at ecpower.dk Mon Jan 12 06:12:13 2009 From: sl at ecpower.dk (Steven Lose) Date: Mon Jan 12 07:18:10 2009 Subject: [Icc-avr] test Message-ID: <072D96786BFC014AAEBA9EB07A8070EA568CC9@seattle.ecpower.dk> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 2650 bytes Desc: image001.jpg Url : http://dragonsgate.net/pipermail/icc-avr/attachments/20090112/7086bbd9/attachment.jpe From sl at ecpower.dk Fri Jan 16 02:00:29 2009 From: sl at ecpower.dk (Steven Lose) Date: Fri Jan 16 03:06:30 2009 Subject: [Icc-avr] PC-Lint and __flash Message-ID: <072D96786BFC014AAEBA9EB07A8070EA568F53@seattle.ecpower.dk> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 2650 bytes Desc: image001.jpg Url : http://dragonsgate.net/pipermail/icc-avr/attachments/20090116/2991663f/attachment.jpe From richard at imagecraft.com Fri Jan 23 15:11:38 2009 From: richard at imagecraft.com (Richard Man) Date: Fri Jan 23 16:16:55 2009 Subject: [Icc-avr] SD card interface for the AVR Message-ID: <200901240016.n0O0GrUY050371@mail.imagecraft.com> I am going to work on a SD card interface and FileSystem (FAT16) next, both as an add-on to eMOS and also as a standalone module. Does anyone know wnay good and easy to use hardware module for the STK-600 or a combination AVR+SD kit? Does anyone have a spare kit? :-) Thanks. // richard blog: On-line orders, support, and listservers available on web site. [ For technical support on ImageCraft products, please include all previous replies in your msgs. ] From Albert.vanVeen at pertronic.co.nz Sun Jan 25 13:49:20 2009 From: Albert.vanVeen at pertronic.co.nz (Albert vanVeen) Date: Sun Jan 25 14:55:33 2009 Subject: [Icc-avr] Dean Bell Message-ID: <5F8515C5ED67B6439B4F93D7B5E08A36063EC8@sbs.pertronic.local> A known contributor to ICC's forum (and software), but he appears to have changed email address. If you read this, can you please let us know your new address. Albert. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20090126/2e81e9a7/attachment.html From t.jaspers at cpseurope.com Mon Jan 26 00:42:20 2009 From: t.jaspers at cpseurope.com (Jaspers, Ton) Date: Mon Jan 26 01:48:32 2009 Subject: [Icc-avr] SD card interface for the AVR In-Reply-To: <200901240016.n0O0GrUY050371@mail.imagecraft.com> Message-ID: <7B0EB27CF1CC93439B5CFB7526E5D74C7C6A30@mickey.PBNV.local> > From: Richard Man > Subject: [Icc-avr] SD card interface for the AVR > > I am going to work on a SD card interface and FileSystem > (FAT16) next, both as an add-on to eMOS and also as a > standalone module. Does anyone know wnay good and easy to use > hardware module for the STK-600 or a combination AVR+SD kit? > Does anyone have a spare kit? :-) > > Thanks. If you type "open source FAT" in google there are thousands of hits. This one seems to be floating on top: http://sourceforge.net/projects/efsl But if you are looking for a lean and mean solution this may fit the bill: http://elm-chan.org/fsw/ff/00index_e.html This is a real small simplified FAT interface but this relies on NXP drivers (copyright) for the high speed SD/MMC interface. It does not support all FAT features but because it is so small it is ideal for small memory footprint projects. In my case (LPC2386 / ATmega8515), I got it to work thanks to Martin Thomas from Kaiserslautern University (Germany): http://www.siwawi.arubi.uni-kl.de/avr_projects/arm_projects/ Hope this helps, Cheers, Ton From j_baraclough at zetnet.co.uk Mon Jan 26 15:28:55 2009 From: j_baraclough at zetnet.co.uk (John Baraclough) Date: Mon Jan 26 16:35:10 2009 Subject: [Icc-avr] Happy New Year In-Reply-To: <200901240016.n0O0GrUY050371@mail.imagecraft.com> References: <200901240016.n0O0GrUY050371@mail.imagecraft.com> Message-ID: <497E4737.6040800@zetnet.co.uk> I would just like to wish all readers a Happy (Chinese) New Year and welcome to the year of the Ox. According to the astrologers, it's a year where success is possible - but only through hard work. All the best for now, John From lvcep at arnet.com.ar Mon Jan 26 17:06:44 2009 From: lvcep at arnet.com.ar (Claudio E Palumbo) Date: Mon Jan 26 18:12:54 2009 Subject: [Icc-avr] Ethernet Interface References: <200901240016.n0O0GrUY050371@mail.imagecraft.com> <497E4737.6040800@zetnet.co.uk> Message-ID: <002401c9801b$858f1970$0400000a@labelius> Hi , Has any experience in how to interface an m128 with the microchip Ethernet controler ECNJ60? Thanks in advance for any comments and/or suggestions Saluda atte. CEP Claudio E Palumbo lvcep@hotmail.com lvcep@hotmail.com ----- Original Message ----- From: "John Baraclough" To: "Discussion list for ICCAVR and ICCtiny Users. You do NOT need tosubscribe to icc-announce if you are a member of this." Sent: Monday, January 26, 2009 9:28 PM Subject: [Icc-avr] Happy New Year I would just like to wish all readers a Happy (Chinese) New Year and welcome to the year of the Ox. According to the astrologers, it's a year where success is possible - but only through hard work. All the best for now, John _______________________________________________ Icc-avr mailing list Icc-avr@imagecraft.com http://dragonsgate.net/mailman/listinfo/icc-avr -------------------------------------------------------------------------------- Se certific? que el correo entrante no contiene virus. Comprobada por AVG - http://www.avg.es Versi?n: 8.0.176 / Base de datos de virus: 270.10.13/1914 - Fecha de la versi?n: 24/01/2009 20:40 From Albert.vanVeen at pertronic.co.nz Tue Jan 27 13:48:29 2009 From: Albert.vanVeen at pertronic.co.nz (Albert vanVeen) Date: Tue Jan 27 14:54:43 2009 Subject: [Icc-avr] Happy New Year In-Reply-To: <497E4737.6040800@zetnet.co.uk> References: <200901240016.n0O0GrUY050371@mail.imagecraft.com> <497E4737.6040800@zetnet.co.uk> Message-ID: <5F8515C5ED67B6439B4F93D7B5E08A36063ECD@sbs.pertronic.local> Doesn't sound very different from other years then! We started a chinese venture last year, so hopefully the ox will help us this year. Gong Xi Fa Cai! Albert. -----Original Message----- From: icc-avr-bounces@imagecraft.com [mailto:icc-avr-bounces@imagecraft.com] On Behalf Of John Baraclough Sent: Tuesday, January 27, 2009 12:29 PM To: Discussion list for ICCAVR and ICCtiny Users. You do NOT need tosubscribe to icc-announce if you are a member of this. Subject: [Icc-avr] Happy New Year I would just like to wish all readers a Happy (Chinese) New Year and welcome to the year of the Ox. According to the astrologers, it's a year where success is possible - but only through hard work. All the best for now, John _______________________________________________ Icc-avr mailing list Icc-avr@imagecraft.com http://dragonsgate.net/mailman/listinfo/icc-avr -- This message has been scanned for viruses and dangerous content by Bizo EmailFilter, and is believed to be clean. From richard-lists at imagecraft.com Tue Jan 27 14:07:09 2009 From: richard-lists at imagecraft.com (Richard Man) Date: Tue Jan 27 15:12:37 2009 Subject: [Icc-avr] Happy New Year In-Reply-To: <497E4737.6040800@zetnet.co.uk> References: <200901240016.n0O0GrUY050371@mail.imagecraft.com> <497E4737.6040800@zetnet.co.uk> Message-ID: <200901272312.n0RNCapU020282@mail.imagecraft.com> I must have missed the memo where it says "Success is possible, without hard work." :-) Full speed ahead! At 03:28 PM 1/26/2009, John Baraclough wrote: >I would just like to wish all readers a Happy (Chinese) New Year and >welcome to the year of the Ox. According to the astrologers, it's a >year where success is possible - but only through hard work. > >All the best for now, >John // richard // photo & calligraphy blog: http://rfman.wordpress.com From richard at imagecraft.com Thu Jan 29 19:26:42 2009 From: richard at imagecraft.com (Richard Man) Date: Thu Jan 29 20:32:23 2009 Subject: [Icc-avr] File System API Message-ID: <200901300432.n0U4WL4O065733@mail.imagecraft.com> We are now looking into our first plug-in module for eMOS, which is a file system and SD driver. We will probably also include a standalone version that does not require eMOS. The eMOS version will of course fully support multitasking. In terms of API, the obvious choice for the FS is in fact the stdio.h C API,... (Read the complete article below. I welcome any comments and suggestions. Thanks) http://imagecraft.wordpress.com/2009/01/29/filesys-and-sd-modules-plus-emos-update/ // richard blog: On-line orders, support, and listservers available on web site. [ For technical support on ImageCraft products, please include all previous replies in your msgs. ] From richard at imagecraft.com Fri Jan 30 02:10:16 2009 From: richard at imagecraft.com (Richard Man) Date: Fri Jan 30 03:15:07 2009 Subject: [Icc-avr] OT: Fine Arts Prints Message-ID: <200901301115.n0UBF5Po071328@mail.imagecraft.com> I am sorry for this OT commercial message, but please read http://rfman.wordpress.com for my outside hobby and print sales. I will not burden the mailing lists with further messages. // richard From jh.bodin at telia.com Sat Jan 31 01:23:57 2009 From: jh.bodin at telia.com (Johan H. Bodin) Date: Sat Jan 31 02:30:15 2009 Subject: [Icc-avr] SD card interface for the AVR In-Reply-To: <200901240016.n0O0GrUY050371@mail.imagecraft.com> References: <200901240016.n0O0GrUY050371@mail.imagecraft.com> Message-ID: <498418AD.5040600@telia.com> Hi, a solution already exists for low volume and hobby projects. FTDI's Vinculum chip is an USB controller with a simple microcontroller interface. Just plug a cheap off-the-shelf USB memory stick in and your file system is ready to go. http://www.ftdichip.com/ FTDI also offers a ready built "drive": http://apple.clickandbuild.com/cnb/shop/ftdichip?op=catalogue-products-null&prodCategoryID=54&title=VDRIVE2 Cheers Johan Bodin ---- Richard Man wrote: > I am going to work on a SD card interface and FileSystem (FAT16) next, > both as an add-on to eMOS and also as a standalone module. Does anyone > know wnay good and easy to use hardware module for the STK-600 or a > combination AVR+SD kit? Does anyone have a spare kit? :-) > > Thanks. From richard-lists at imagecraft.com Sat Jan 31 01:29:16 2009 From: richard-lists at imagecraft.com (Richard Man) Date: Sat Jan 31 02:34:13 2009 Subject: [Icc-avr] SD card interface for the AVR In-Reply-To: <498418AD.5040600@telia.com> References: <200901240016.n0O0GrUY050371@mail.imagecraft.com> <498418AD.5040600@telia.com> Message-ID: <200901311034.n0VAYCfZ088865@mail.imagecraft.com> May be I didn't make this clear: I am writing a package to be sold by ImageCraft :-)I am not looking for a hardware solution per se. Judging from some offline responses, there does appear to be a market for simple to use solution. Besides, it will just make our eMOS offering more compelling. Users may of course choose our solutions, or whatever best fit their needs. At 01:23 AM 1/31/2009, Johan H. Bodin wrote: >Hi, > >a solution already exists for low volume and hobby projects. FTDI's >Vinculum chip is an USB controller with a simple microcontroller >interface. Just plug a cheap off-the-shelf USB memory stick in and your >file system is ready to go. > >http://www.ftdichip.com/ // richard // photo & calligraphy blog: http://rfman.wordpress.com From andrew_166 at msn.com Sat Jan 31 03:48:52 2009 From: andrew_166 at msn.com (Andrew) Date: Sat Jan 31 04:54:57 2009 Subject: [Icc-avr] SD card interface for the AVR In-Reply-To: <200901240016.n0O0GrUY050371@mail.imagecraft.com> <498418AD.5040600@telia.com> References: <200901240016.n0O0GrUY050371@mail.imagecraft.com> <498418AD.5040600@telia.com> Message-ID: HI John, This is fine for low volume projects (10/20) but i think an SD/MMC and FAT filing system interface for the AVR, written by Imagecraft. Is a brilliant idea. The FTDi units are not all that cheap, and the support from FTDi is rubbish IMO. Andy -------------------------------------------------- From: "Johan H. Bodin" Sent: Saturday, January 31, 2009 9:23 AM To: "Discussion list for ICCAVR and ICCtiny Users. You do NOT need tosubscribe to icc-announce if you are a member of this." Subject: Re: [Icc-avr] SD card interface for the AVR > Hi, > > a solution already exists for low volume and hobby projects. FTDI's > Vinculum chip is an USB controller with a simple microcontroller > interface. Just plug a cheap off-the-shelf USB memory stick in and your > file system is ready to go. > > http://www.ftdichip.com/ > > FTDI also offers a ready built "drive": > > http://apple.clickandbuild.com/cnb/shop/ftdichip?op=catalogue-products-null&prodCategoryID=54&title=VDRIVE2 > > > Cheers > Johan Bodin > > ---- > > Richard Man wrote: >> I am going to work on a SD card interface and FileSystem (FAT16) next, >> both as an add-on to eMOS and also as a standalone module. Does anyone >> know wnay good and easy to use hardware module for the STK-600 or a >> combination AVR+SD kit? Does anyone have a spare kit? :-) >> >> Thanks. > > _______________________________________________ > Icc-avr mailing list > Icc-avr@imagecraft.com > http://dragonsgate.net/mailman/listinfo/icc-avr > From sidprice at softtools.com Sat Jan 31 17:23:27 2009 From: sidprice at softtools.com (Sid Price) Date: Sat Jan 31 18:29:59 2009 Subject: [Icc-avr] Atmel AVR315 Message-ID: <405D251F61E64F8DAD4FA65889278034@SID004> Has anyone ported the code for the above application note to ICC-AVR? Thanks, Sid. Sid Price Software Design -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20090131/2a0db21f/attachment.html