From kris at abbey.co.nz Sun Jan 4 13:56:11 2009 From: kris at abbey.co.nz (Kris Heidenstrom) Date: Sun Jan 4 15:02:02 2009 Subject: [Icc-430] new assembler testing request In-Reply-To: <200812310254.mBV2sOlh078391@mail.imagecraft.com> References: <200812310232.mBV2W0l6078144@mail.imagecraft.com> <495ACB88.5040805@interstellar.com> <200812310254.mBV2sOlh078391@mail.imagecraft.com> Message-ID: <4961307B.8010201@abbey.co.nz> Richard Man wrote: > http://www.dragonsgate.net/pub/BETAS/ias430.exe I've done a "rebuild all" and .lst file comparison for four projects: Prj Name Device Flash img size .lst result 1 of 4 "batt" F1611 0x6232 bytes Identical 2 of 4 "rosie" F1232 0x16B8 bytes Identical 3 of 4 "fgen" F1611 0x031A bytes Identical 4 of 4 "io" F1611 0x5990 bytes One error. The "io" project has a Flash image 0x5990 bytes long (__lit_start = 0x4000 and __text_end = 0x9990) and there is one difference between the .lst files for the shipping assembler (from V7.06A) and the new beta assembler, which looks like a fairly straightforward bug in the new beta assembler. I don't want to post or send the whole project. The code section that has the problem is an inline assembler block using asm(). The source code, and the corresponding .lst file lines using the new beta assembler, are: asm ( " mov.b \x40%alsp,r15 \n" 6C84 446F mov.B @R4,R15 " rra.b r15 \n" 6C86 114F rra.B R15 " jeq als_got \n" 6C88 2402 jeq 6C8E " rra.b _flash_flag \n" 6C8A 1150 A48A rra.B flash_flag "als_got: \n" " rlc.b %aleds \n" 6C8E 6505 rlc R5 <--ERROR! " jnc als_loop \n" 6C90 2BF7 jnc 6C80 ); The "rlc.b %aleds" instruction seems to be assembled as a word-wide rotate by the new beta assembler, with an opcode of 0x6505. The V7.06 shipping assembler generated an opcode of 0x6545 which appears in the .lst file as "rlc.B R5" which is right. (I'm using V7.06A of the compiler.) (The reason I use "mov.b \x40%alsp,r15" instead of "mov.b @alsp,r15" is that an "@" symbol in the asm string causes the compiler to emit a warning "string literal contains non-portable characters".) Regards Kris -- Kris Heidenstrom Embedded systems designer / programmer kris@abbey.co.nz Abbey Systems Ltd - Telemetry Specialists Wellington NEW ZEALAND Voice +64-4-385-6611 Fax +64-4-385-6848 From llchisho at paradise.net.nz Sun Jan 4 22:36:04 2009 From: llchisho at paradise.net.nz (llchisho@paradise.net.nz) Date: Sun Jan 4 23:41:47 2009 Subject: [Icc-430] new assembler testing request In-Reply-To: <4961307B.8010201@abbey.co.nz> References: <200812310232.mBV2W0l6078144@mail.imagecraft.com> <495ACB88.5040805@interstellar.com> <200812310254.mBV2sOlh078391@mail.imagecraft.com> <4961307B.8010201@abbey.co.nz> Message-ID: <1231137364.4961aa5474320@www.paradise.net.nz> Quoting Kris Heidenstrom : > there is one difference between the .lst files for > the shipping assembler (from V7.06A) and the new beta > assembler, which looks like a fairly straightforward > bug in the new beta assembler. I don't want to post > The "rlc.b %aleds" instruction seems to be assembled > as a word-wide rotate by the new beta assembler, with > an opcode of 0x6505. The V7.06 shipping assembler > generated an opcode of 0x6545 which appears in the > .lst file as "rlc.B R5" which is right. I also observed the same failure to generate a byte rotate with hand-written assembler source in an external module, where a byte-wide register rotate became a word rotate, irrespective of the case of the B or the register chosen. Concentrating on the rotate (not actually emitted by the compiler as RLA Rx but as an ADD Rx,Rx) has exposed a bug in ilst430 (V7.06 and V7.08). Here is the list file fragment : (0909) ipbus.rx_timeout = get_tick() + IPB_RX_CHAR_TIMEOUT + ipb_ms_per_tick; 4856 401B D896 mov ipb_ltickcnt,R11 485A 503B 0005 add #5,R11 485E 4B80 D888 mov R11,20E8 4862 5090 D888 D882 rla 20E8 The final instruction should be "add ipb_ms_per_tick, 20e8" but instead is decoded as a rotate. This also demonstrates the compiler's annoying habit of performing the last operation of an equation with a memory->memory instruction after storing an intermediate result in the destination variable. Interestingly, making the rx_timeout field volatile produces the expected result (a bit earlier in the flash :-) : 4854 501B D896 add ipb_ms_per_tick,R11 4858 4B80 D88E mov R11,20E8 Len Chisholm. From olli.pohjolainen at medikro.com Thu Jan 8 00:28:32 2009 From: olli.pohjolainen at medikro.com (Olli Pohjolainen) Date: Thu Jan 8 01:34:25 2009 Subject: [Icc-430] new assembler testing request In-Reply-To: <495BBFF3.2010803@interstellar.com> References: <200812310232.mBV2W0l6078144@mail.imagecraft.com> <495ACB88.5040805@interstellar.com> <200812310254.mBV2sOlh078391@mail.imagecraft.com> <495BBFF3.2010803@interstellar.com> Message-ID: <001901c9716b$1a409810$4ec1c830$@pohjolainen@medikro.com> Richard Man wrote: >Please also contact me if you have done this experiment and give me size of your project. Thanks. Seems to work. No errors. F449. Flash img. size 0x5780 The tested application is using a lot of mathematical libraries and some i/o. Olli __________________________________________________________________ MEDIKRO OY Postal Address:?????? P.O.Box 54, FIN-70101 Kuopio, Finland Homepage: ??????????? www.medikro.com Olli Pohjolainen ???? R&D Director __________________________________________________________________ From richard at imagecraft.com Sun Jan 11 23:29:23 2009 From: richard at imagecraft.com (Richard Man) Date: Mon Jan 12 00:33:51 2009 Subject: [Icc-430] ICC430 V7.09 Released Message-ID: <200901120833.n0C8Xouq015937@mail.imagecraft.com> Happy New Year! Just a quick release to get the -NC license version out. More features will be added soon... V7.09 - Jan 11th, 2009 Enabled the -NC Non-Commercial Use license. IDE - Added entries for F54xx Compiler - Better code for checking for inequality against zero - Fixed problem with inline asm with local variables that did not get allocated to registers Asm - Code cleanup to prepare for 430X (no 430X support yet). // 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-lists at imagecraft.com Wed Jan 14 19:44:54 2009 From: richard-lists at imagecraft.com (Richard Man) Date: Wed Jan 14 20:49:42 2009 Subject: [Icc-430] new assembler testing request In-Reply-To: <1231137364.4961aa5474320@www.paradise.net.nz> References: <200812310232.mBV2W0l6078144@mail.imagecraft.com> <495ACB88.5040805@interstellar.com> <200812310254.mBV2sOlh078391@mail.imagecraft.com> <4961307B.8010201@abbey.co.nz> <1231137364.4961aa5474320@www.paradise.net.nz> Message-ID: <200901150449.n0F4nfb5078185@mail.imagecraft.com> Just added the optimization to swap move Rtmp,_glob1 op _glob2,_glob1 to op _glob2, Rtmp mov Rtmp,_glob1 Will go out in the next minor release. At 10:36 PM 1/4/2009, llchisho@paradise.net.nz wrote: >...Here is the list file fragment : >(0909) ipbus.rx_timeout = get_tick() + IPB_RX_CHAR_TIMEOUT + >ipb_ms_per_tick; > 4856 401B D896 mov ipb_ltickcnt,R11 > 485A 503B 0005 add #5,R11 > 485E 4B80 D888 mov R11,20E8 > 4862 5090 D888 D882 rla 20E8 > >The final instruction should be "add ipb_ms_per_tick, 20e8" but instead is >decoded as a rotate. >This also demonstrates the compiler's annoying habit of performing the last >operation of an equation with a memory->memory instruction after storing an >intermediate result in the destination variable. >Interestingly, making the rx_timeout field volatile produces the >expected result >(a bit earlier in the flash :-) : > 4854 501B D896 add ipb_ms_per_tick,R11 > 4858 4B80 D88E mov R11,20E8 // richard // photo & calligraphy blog: http://rfman.wordpress.com From llchisho at paradise.net.nz Sun Jan 25 16:41:58 2009 From: llchisho at paradise.net.nz (llchisho@paradise.net.nz) Date: Sun Jan 25 17:48:10 2009 Subject: [Icc-430] ilst430 and the __start label Message-ID: <1232930518.497d06d615abe@www.paradise.net.nz> I have a project where the code is partitioned into several program areas, and I would prefer the __start label to be in an area other than the text area. However, when I do this I get a failure in ilst430, with the following message: c:/iccv7430/bin/ilst430 -i o/fwupdate.hex map file does not contain '__start' symbol make: *** [o/fwupdate.lst] Error 1 __start IS in the map file but is in the demotext area rather than text. The DBG file has the START keyword with the correct value as per the map file. Is there any reason why __start needs to be in the text area ? If not, perhaps ilst430 can be fixed to allow this. Len Chisholm. 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:24 2009 Subject: [Icc-430] 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-430] 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 richard at imagecraft.com Fri Jan 30 17:29:21 2009 From: richard at imagecraft.com (Richard Man) Date: Fri Jan 30 18:34:16 2009 Subject: [Icc-430] eMOS for MSP430 in Development Message-ID: <200901310234.n0V2YFEA083531@mail.imagecraft.com> We are now porting eMOS (current AVR doc: http://www.imagecraft.com/pub/emos_avr.pdf) to the TI MSP430. The TI MSP430 excels at minimizing power consumption, and with eMOS' system hooks to shut down the system when it is quiescent,eMOS is a good fit for the MSP430 family. We expect porting and testing will take about a month so production release should be around the beginning of March. // 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. ]