From sergiosider at gmail.com Sun May 6 09:53:50 2007 From: sergiosider at gmail.com (Sergio Paulo Sider) Date: Sun May 6 10:03:11 2007 Subject: [Icc-430] ICC430 generating an invalid assembler instruction Message-ID: Hi Richard & All, I got the following error when trying to compile a C program: !E killme.s(xxx): invalid dst operand mode the offender line is: mov R11,@R1 that is on the asm code the compiler created itself. I removed all unnecessary code from the program just to clarify. The single killme.c source is: void update_ptr(char **s) { while (*((*s)++)); //too many parenthesis?! ;-) } int proc_string(char* fullstring) { char c; while (c=*fullstring++) { switch (c) { case 0x81: //simple delay //bla bla bla update_ptr(&fullstring); //bla bla bla break; default: putchar(c); break; } } return 0; } void main(void) { proc_string("test""\x00""test2""\x00""test3"); } I know I am not a genius C coder, but it seems the compiler should not generate an invalid assembler instruction even if my C program looks ugly... (obs: using ICC430 V7.05A, feb,14,2007), standard - dongle version Regards, Sergio. From sergiosider at gmail.com Wed May 9 09:33:47 2007 From: sergiosider at gmail.com (Sergio Paulo Sider) Date: Wed May 9 09:43:40 2007 Subject: [Icc-430] ICC430 generating an invalid assembler instruction Message-ID: Hi Richard & All, I got the following error when trying to compile a C program: !E killme.s(xxx): invalid dst operand mode the offender line is: mov R11,@R1 that is on the asm code the compiler created itself. I removed all unnecessary code from the program just to clarify. The single killme.c source is: void update_ptr(char **s) { while (*((*s)++)); //too many parenthesis?! ;-) } int proc_string(char* fullstring) { char c; while (c=*fullstring++) { switch (c) { case 0x81: //simple delay //bla bla bla update_ptr(&fullstring); //bla bla bla break; default: putchar(c); break; } } return 0; } void main(void) { proc_string("test""\x00""test2""\x00""test3"); } I know I am not a genius C coder, but it seems the compiler should not generate an invalid assembler instruction even if my C program looks ugly... (obs: using ICC430 V7.05A, feb,14,2007), standard - dongle version Regards, Sergio. From richard-lists at imagecraft.com Wed May 9 12:23:08 2007 From: richard-lists at imagecraft.com (Richard) Date: Wed May 9 12:33:01 2007 Subject: [Icc-430] ICC430 generating an invalid assembler instruction In-Reply-To: References: Message-ID: <6.1.0.6.2.20070509122217.0498b698@192.168.100.42> Hi Sergio, thanks for the report. I will fix the compiler. At 09:33 AM 5/9/2007, Sergio Paulo Sider wrote: >Hi Richard & All, > >I got the following error when trying to compile a C program: > >!E killme.s(xxx): invalid dst operand mode > >the offender line is: > > mov R11,@R1 > >that is on the asm code the compiler created itself. > >I removed all unnecessary code from the program just to clarify. The >single killme.c source is: > >void update_ptr(char **s) >{ >while (*((*s)++)); //too many parenthesis?! ;-) >} > >int proc_string(char* fullstring) >{ > char c; > while (c=*fullstring++) { > > switch (c) { > > case 0x81: //simple delay > //bla bla bla > update_ptr(&fullstring); > //bla bla bla > break; > > default: > putchar(c); > break; > } > > } > return 0; >} > >void main(void) >{ >proc_string("test""\x00""test2""\x00""test3"); >} > > > >I know I am not a genius C coder, but it seems the compiler should not >generate an invalid assembler instruction even if my C program looks >ugly... > >(obs: using ICC430 V7.05A, feb,14,2007), standard - dongle version > >Regards, >Sergio. > // richard (This email is for mailing lists. To reach me directly, please use richard at imagecraft.com) From richard-lists at imagecraft.com Wed May 9 12:24:29 2007 From: richard-lists at imagecraft.com (Richard) Date: Wed May 9 12:34:21 2007 Subject: [Icc-430] ICC430 generating an invalid assembler instruction In-Reply-To: References: Message-ID: <6.1.0.6.2.20070509122339.07b60a88@192.168.100.42> OH, if you are looking for a a workaround, something like this ought to work: while (**s) { .... *s++; } Thanks. At 09:33 AM 5/9/2007, you wrote: >Hi Richard & All, > >I got the following error when trying to compile a C program: > >!E killme.s(xxx): invalid dst operand mode > >the offender line is: > > mov R11,@R1 > >that is on the asm code the compiler created itself. > >I removed all unnecessary code from the program just to clarify. The >single killme.c source is: > >void update_ptr(char **s) >{ >while (*((*s)++)); //too many parenthesis?! ;-) >} > >int proc_string(char* fullstring) >{ > char c; > while (c=*fullstring++) { > > switch (c) { > > case 0x81: //simple delay > //bla bla bla > update_ptr(&fullstring); > //bla bla bla > break; > > default: > putchar(c); > break; > } > > } > return 0; >} > >void main(void) >{ >proc_string("test""\x00""test2""\x00""test3"); >} > > > >I know I am not a genius C coder, but it seems the compiler should not >generate an invalid assembler instruction even if my C program looks >ugly... > >(obs: using ICC430 V7.05A, feb,14,2007), standard - dongle version > >Regards, >Sergio. > >_______________________________________________ >Icc-430 mailing list >Icc-430@imagecraft.com >http://dragonsgate.net/mailman/listinfo/icc-430 // richard (This email is for mailing lists. To reach me directly, please use richard at imagecraft.com) From richard at imagecraft.com Fri May 11 00:47:22 2007 From: richard at imagecraft.com (Richard) Date: Fri May 11 02:44:07 2007 Subject: [Icc-430] Some mail messages lost due to hard drive failure Message-ID: <200705110757.l4B7uwi1095789@dragonsgate2.imagecraft.com> One of our systems suffered a hard drive failure (two less than a year old Seagate drives died within a span of 2 weeks in 2 different systems, draw your own conclusions?) Fortunately, our back up system minimizes the data loss, less minimal for the email messages because unfortunately the email clients run all the time and the backup utility cannot access the data file. So if you have emailed us in the last few weeks and are still awaiting a response from us, please email again. Sorry for the inconvenience. // 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 jdurand at interstellar.com Fri May 11 08:38:52 2007 From: jdurand at interstellar.com (Jerry Durand) Date: Fri May 11 08:48:41 2007 Subject: [Icc-430] Some mail messages lost due to hard drive failure In-Reply-To: <200705110757.l4B7uwi1095789@dragonsgate2.imagecraft.com> References: <200705110757.l4B7uwi1095789@dragonsgate2.imagecraft.com> Message-ID: <7185A072-5CB2-4D87-9638-A8688D5CA2B0@interstellar.com> On May 11, 2007, at 12:47 AM, Richard wrote: > One of our systems suffered a hard drive failure (two less than a > year old Seagate drives died within a span of 2 weeks in 2 > different systems, draw your own conclusions?) I drew conclusions years ago about drives, our systems are now RAID. Had a few drives replaced on warranty, no big deal since the other keeps working. > Fortunately, our back up system minimizes the data loss, less > minimal for the email messages because unfortunately the email > clients run all the time and the backup utility cannot access the > data file. Backups are a GOOD thing. From richard at imagecraft.com Tue May 15 23:29:09 2007 From: richard at imagecraft.com (Richard) Date: Tue May 15 23:39:09 2007 Subject: [Icc-430] 64 bits FP chip.... Message-ID: <200705160639.l4G6d7mj067739@dragonsgate2.imagecraft.com> I am considering producing something like this: 64 bits FP support will be provided by the new iFPLightning chip. The product is integrated fully into our compilers (initially AVR but later on supporting other ICC compilers as well). The approximate performance goals are 1 uSec for 32 bit FP MUL 1.5 uSec for DIV and ~2X for 64 bits. This is at least 15x-20X faster than the equivalent AVR code and of course free up code space on the AVR chip. The data transfer overheard is ~10 uSec to transfer two operands and a result. Complex expressions will use the intermediate results directly without data transfer. The API uses a stack architecture so interrupt can remain enabled except during the data transfer. The iFPLightning chip comes in a 16 or 18 pin DIP module, ~0.7" x 0.6" in size. The following pricing is very tentative, but is our best guess: 1-50 $30 100 $27 500 $25 1000 $22 It is highly likely that the chip will provide full high level math support such as sin/cos/etc. We are also open to other API such as DSP etc. What do you think? // richard From jdurand at interstellar.com Wed May 16 07:38:24 2007 From: jdurand at interstellar.com (Jerry Durand) Date: Wed May 16 07:48:08 2007 Subject: [Icc-430] 64 bits FP chip.... In-Reply-To: <200705160639.l4G6d7mj067739@dragonsgate2.imagecraft.com> References: <200705160639.l4G6d7mj067739@dragonsgate2.imagecraft.com> Message-ID: <20070516143824.9B0EB3BC0E1@smtp.interstellar.com> At 11:29 PM 5/15/2007, Richard wrote: >The data transfer overheard is ~10 uSec to transfer two operands and >a result. Complex expressions will use the intermediate results >directly without data transfer. The API uses a stack architecture so >interrupt can remain enabled except during the data transfer. So, how do you actually get the data into and out of this thing? Parallel bus (8, 16, 32, 64 bit? endian?), serial (SPI, I2C)? Can it do any other tricks? The TMS320C6722RFP250 floating point DSP at Digi-Key is $17.70 in single quantity and does a lot more than math. -- Jerry Durand, Durand Interstellar, Inc. www.interstellar.com tel: +1 408 356-3886, USA toll free: 1 866 356-3886 Skype: jerrydurand From jdurand at interstellar.com Tue May 22 15:38:29 2007 From: jdurand at interstellar.com (Jerry Durand) Date: Tue May 22 15:48:18 2007 Subject: [Icc-430] Note on MSP-FET430UIF errata Message-ID: <20070522223829.75C3A3CD957@smtp.interstellar.com> On a current project I started having problems debugging the board. Thinking there could be a problem with the processor, I tried programming it with the Softbaugh Flash Bootloader which uses the BSL. That worked perfectly. Then I tried a second MSP-FET430UIF and THAT worked fine. Hmmm.... It turns out that if you have version 1.4 of the FET and your board is self-powered, then there can be problems with random resets (in that mode they have a pulldown on the reset line). I opened up both FETs, the working one is version 1.3, the one not working is 1.4. I followed their instructions to remove R62 from the version 1.4 FET and now all is well. I also noticed that R62 was a lower value than their schematic indicated, this just made it worse. -- Jerry Durand, Durand Interstellar, Inc. www.interstellar.com tel: +1 408 356-3886, USA toll free: 1 866 356-3886 Skype: jerrydurand