From richard at imagecraft.com Sat Feb 3 13:08:18 2007 From: richard at imagecraft.com (Richard) Date: Sat Feb 3 13:15:49 2007 Subject: [Icc-430] Fate of the ICC forums Message-ID: <6.1.0.6.2.20070203130645.07c523c8@192.168.100.42> I will probably delete the icc-forums. They are causing more trouble than they are worth. With all the spammers hitting it, we just don't have the resource to deal with it. The forum's sole purpose is for the users to upload sample code. One way to do this is to utilize the new database backend on our new website. The webmistress can set up a page such that she does not need to modify it as new sample files are uploaded with the description and link being pulled out from the database. The users can send me the sample codes directly and I can upload them. Comments? Suggestions? // richard From jdurand at interstellar.com Sat Feb 3 13:56:21 2007 From: jdurand at interstellar.com (Jerry Durand) Date: Sat Feb 3 14:04:08 2007 Subject: [Icc-430] Fate of the ICC forums In-Reply-To: <6.1.0.6.2.20070203130645.07c523c8@192.168.100.42> References: <6.1.0.6.2.20070203130645.07c523c8@192.168.100.42> Message-ID: <20070203215620.EA46018F748@smtp.interstellar.com> At 01:08 PM 2/3/2007, Richard wrote: >The forum's sole purpose is for the users to upload sample code. One >way to do this is to utilize the new database backend on our new >website. The webmistress can set up a page such that she does not >need to modify it as new sample files are uploaded with the >description and link being pulled out from the database. The users >can send me the sample codes directly and I can upload them. > >Comments? Suggestions? Considering the low volume of sample code submitted, I don't see a problem with you handling the code that's posted. I sometimes post files on our server that people need to share (actually, I'm hosting a couple of friend's entire domains on our little Mac mini). The only thing I'd suggest is way to have descriptions of the files that can be read without downloading an archive to find the ReadMe file. -- Jerry Durand, Durand Interstellar, Inc. www.interstellar.com tel: +1 408 356-3886, USA toll free: 1 866 356-3886 Skype: jerrydurand From richard-lists at imagecraft.com Sun Feb 4 19:06:04 2007 From: richard-lists at imagecraft.com (Richard) Date: Sun Feb 4 19:13:38 2007 Subject: [Icc-430] Re: Interrupt handler wrapper preserves R8,9 - repost In-Reply-To: <004d01c740bc$d98acc90$1917a8c0@KH> References: <00da01c73f2c$de4c4600$1917a8c0@KH> <6.1.0.6.2.20070124005342.053cb250@192.168.100.42> <004d01c740bc$d98acc90$1917a8c0@KH> Message-ID: <6.1.0.6.2.20070204190257.07905d88@192.168.100.42> Hi Kris and Kirk, I found the root of the problem, and of course it is.... the documentation is wrong!!! R8/R9 are not preserved registers. They are "work" or volatile registers. The change came when the compiler started to use R12/R13 also to pass arguments, and I also moved R8/R9 into the other pool. I think the change was documented in the readme file, but I forgot to fix the documentation. I will do that. Sorry about that. At 12:10 PM 1/25/2007, Kris Heidenstrom wrote: >The wrapper doesn't need to preserve the preserved registers, >because the called function will preserve any of them that it uses. >In fact the wrapper doesn't preserve R4~7 for this reason, but >it _does_ preserve R8,9, which are "preserved registers" just like >R4~7. > >In my case the called function doesn't use R8,9 at all, but if it did, >it would preserve them (according to the help), because they are >"preserved registers", so the wrapper doesn't need to preserve >them, it just needs to preserve the "volatile registers", R10~15, >as also stated in the help: "If you write a handler in assembly and >if it calls normal C functions, then the assembly handler must >save and restore the volatile registers, since normal C functions >do not preserve them". > >My guess is that when the compiler sees that the interrupt handler >is calling a function, it flags a list of registers as "needing to be >preserved by the wrapper", and this list wrongly includes R8,9 >as well as (rightly) R10~15. > >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 > >_______________________________________________ >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 Sun Feb 4 23:56:20 2007 From: richard at imagecraft.com (Richard) Date: Mon Feb 5 00:03:54 2007 Subject: [Icc-430] 7.05 BETA1 Message-ID: <6.1.0.6.2.20070204235534.07d37870@192.168.100.42> Probably will go live later on this week http://www.imagecraft.com/pub/iccv7430_v705_beta1.exe Readme: V7.05 - Feb 5th 2007 IDE/Compiler - Added device listing for the 430X FG46xx devices. No > 64K addressing supported yet (TBD later in ADV/PRO versions). Compiler - Further improvement to 32 bit == != code (thanks to Kirk Bailey) - Interface to the 32 bit internal functions for longs and floating point now use R12/R13 in addition to R14/R15 for argument passing, resulting in smaller and faster code. To function names are slightly changed with the addition of a "x" suffix so any attempt to link with older libraries would correctly fail. Library - faster structure copying and str*/mem* functions TI DLL for flash programming and debugging - upgraded to the latest 2.8.1 of the MSP430.DLL and HIL.DLL Documentation - R8/R9 should be listed under volatile registers and not preserved registers // 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 Mon Feb 5 09:09:57 2007 From: jdurand at interstellar.com (Jerry Durand) Date: Mon Feb 5 09:40:00 2007 Subject: [Icc-430] 7.05 BETA1 In-Reply-To: <6.1.0.6.2.20070204235534.07d37870@192.168.100.42> References: <6.1.0.6.2.20070204235534.07d37870@192.168.100.42> Message-ID: <20070205170957.609CE197937@smtp.interstellar.com> At 11:56 PM 2/4/2007, Richard wrote: >Probably will go live later on this week >http://www.imagecraft.com/pub/iccv7430_v705_beta1.exe Testing it now, and I just downloaded the new NoICE that fixes that local variable bug I reported. See, it's not ALWAYS me. :) -- 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 Mon Feb 5 09:44:14 2007 From: jdurand at interstellar.com (Jerry Durand) Date: Mon Feb 5 09:51:55 2007 Subject: [Icc-430] 7.05 BETA1 In-Reply-To: <20070205170957.609CE197937@smtp.interstellar.com> References: <6.1.0.6.2.20070204235534.07d37870@192.168.100.42> <20070205170957.609CE197937@smtp.interstellar.com> Message-ID: <20070205174415.0BA4B197B32@smtp.interstellar.com> At 09:09 AM 2/5/2007, Jerry Durand wrote: >Testing it now, and I just downloaded the new NoICE that fixes that >local variable bug I reported. > >See, it's not ALWAYS me. :) Ok, I just crashed beta1 (just by running it). Maybe it IS me. -- 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 Mon Feb 5 09:58:17 2007 From: jdurand at interstellar.com (Jerry Durand) Date: Mon Feb 5 10:06:09 2007 Subject: [Icc-430] NoICE update Message-ID: <20070205175817.B2173197D25@smtp.interstellar.com> The new NoICE update (8.7.1.2001) is working fine, but be sure you copy the MSP430.dll file from the ICC bin directory over to the NoICE one and let it update the firmware in the MSP0439UIF pod, or else things work "funny". Is there a mailing list to announce NoICE updates? I couldn't find one on their web page. -- Jerry Durand, Durand Interstellar, Inc. www.interstellar.com tel: +1 408 356-3886, USA toll free: 1 866 356-3886 Skype: jerrydurand From richard at imagecraft.com Mon Feb 5 16:47:15 2007 From: richard at imagecraft.com (Richard) Date: Mon Feb 5 16:54:53 2007 Subject: [Icc-430] ImageCraft vacation Feb 15 to Feb 26 Message-ID: <6.1.0.6.2.20070205164248.079092f8@192.168.100.42> ImageCraft office will be closed between Feb 15 to the 26th. Download purchases, licensing and email will be handled sporadically. Don't cause too much trouble and buy now and often :-) // richard From kris at abbey.co.nz Tue Feb 6 12:38:43 2007 From: kris at abbey.co.nz (Kris Heidenstrom) Date: Tue Feb 6 12:45:48 2007 Subject: [Icc-430] Re: Interrupt handler wrapper preserves R8,9 - repost References: <00da01c73f2c$de4c4600$1917a8c0@KH> <6.1.0.6.2.20070124005342.053cb250@192.168.100.42> <004d01c740bc$d98acc90$1917a8c0@KH> <6.1.0.6.2.20070204190257.07905d88@192.168.100.42> Message-ID: <021501c74a2e$cb51b870$1917a8c0@KH> Richard wrote: > Hi Kris and Kirk, I found the root of the problem, > and of course it is.... > > the documentation is wrong!!! R8/R9 are not > preserved registers. They are "work" or volatile > registers. The change came when the compiler > started to use R12/R13 also to pass arguments, > and I also moved R8/R9 into the other pool. [...] Thanks Richard for the clear explanation. -- 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 bailey at peak.org Tue Feb 6 15:34:40 2007 From: bailey at peak.org (bailey@peak.org) Date: Tue Feb 6 15:42:11 2007 Subject: [Icc-430] Re: Interrupt handler wrapper preserves R8,9 - repost In-Reply-To: <021501c74a2e$cb51b870$1917a8c0@KH> References: <00da01c73f2c$de4c4600$1917a8c0@KH> <6.1.0.6.2.20070124005342.053cb250@192.168.100.42> <004d01c740bc$d98acc90$1917a8c0@KH> <6.1.0.6.2.20070204190257.07905d88@192.168.100.42> <021501c74a2e$cb51b870$1917a8c0@KH> Message-ID: <1069.69.59.200.77.1170804880.squirrel@webmail.peak.org> That's right, blame the person responsible for the documentation! It's more fun at a bigger outfit though... Thanks Richard! Kirk > Richard wrote: > >> Hi Kris and Kirk, I found the root of the problem, >> and of course it is.... >> >> the documentation is wrong!!! R8/R9 are not >> preserved registers. They are "work" or volatile >> registers. The change came when the compiler >> started to use R12/R13 also to pass arguments, >> and I also moved R8/R9 into the other pool. > [...] > > Thanks Richard for the clear explanation. > -- > 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 > > > _______________________________________________ > Icc-430 mailing list > Icc-430@imagecraft.com > http://dragonsgate.net/mailman/listinfo/icc-430 > From richard at imagecraft.com Wed Feb 7 22:54:42 2007 From: richard at imagecraft.com (Richard) Date: Wed Feb 7 23:02:24 2007 Subject: [Icc-430] ICCv7 for MSP430 7.05 Released Message-ID: <6.1.0.6.2.20070207225339.07e69398@192.168.100.42> Readme excerpt: V7.05 - Feb 8th 2007 IDE/Compiler - Added device listing for the 430X FG46xx devices. No > 64K addressing supported yet (TBD later in ADV/PRO versions). Compiler - Further improvement to 32 bit == != code (thanks to Kirk Bailey) - Interface to the 32 bit internal functions for longs and floating point now use R12/R13 in addition to R14/R15 for argument passing, resulting in smaller and faster code. To function names are slightly changed with the addition of a "x" suffix so any attempt to link with older libraries would correctly fail. Library - faster structure copying and str*/mem* functions TI DLL for flash programming and debugging - upgraded to the latest 2.8.1 of the MSP430.DLL and HIL.DLL Documentation - Fixed documentation to list R8/9 as volatile registers and not preserved registers // 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 Thu Feb 8 09:45:13 2007 From: jdurand at interstellar.com (Jerry Durand) Date: Thu Feb 8 09:53:58 2007 Subject: [Icc-430] ICCv7 for MSP430 7.05 Released In-Reply-To: <6.1.0.6.2.20070207225339.07e69398@192.168.100.42> References: <6.1.0.6.2.20070207225339.07e69398@192.168.100.42> Message-ID: <20070208174513.A72941A7A9E@smtp.interstellar.com> At 10:54 PM 2/7/2007, Richard wrote: > TI DLL for flash programming and debugging > - upgraded to the latest 2.8.1 of the MSP430.DLL and HIL.DLL I notice the HIL.dll in my NoICE directory is dated 11/16/6 while yours is 11/15/6. Are these the same or which is the right one? -- Jerry Durand, Durand Interstellar, Inc. www.interstellar.com tel: +1 408 356-3886, USA toll free: 1 866 356-3886 Skype: jerrydurand From richard-lists at imagecraft.com Thu Feb 8 11:53:44 2007 From: richard-lists at imagecraft.com (Richard) Date: Thu Feb 8 12:01:32 2007 Subject: [Icc-430] ICCv7 for MSP430 7.05 Released In-Reply-To: <20070208174513.A72941A7A9E@smtp.interstellar.com> References: <6.1.0.6.2.20070207225339.07e69398@192.168.100.42> <20070208174513.A72941A7A9E@smtp.interstellar.com> Message-ID: <6.1.0.6.2.20070208115252.07e96d60@192.168.100.42> If you right click on a DLL and bring up its properties page, it will list the version #. Don't do that with our .exe though since we pretty much put random whatever tools use for our .exe in that field. At 09:45 AM 2/8/2007, Jerry Durand wrote: >At 10:54 PM 2/7/2007, Richard wrote: >> TI DLL for flash programming and debugging >> - upgraded to the latest 2.8.1 of the MSP430.DLL and HIL.DLL > >I notice the HIL.dll in my NoICE directory is dated 11/16/6 while yours is >11/15/6. Are these the same or which is the right one? // richard (This email is for mailing lists. To reach me directly, please use richard at imagecraft.com) From kris at abbey.co.nz Thu Feb 8 12:32:23 2007 From: kris at abbey.co.nz (Kris Heidenstrom) Date: Thu Feb 8 13:01:38 2007 Subject: [Icc-430] ICCv7 for MSP430 7.05 Released References: <6.1.0.6.2.20070207225339.07e69398@192.168.100.42> Message-ID: <027a01c74bc0$3d92bfa0$1917a8c0@KH> Richard wrote: > V7.05 - Feb 8th 2007 There seems to be something wrong with the Imagecraft web site. The "Imagecraft software" link with the 30 second default points to www.imagecraft.com/software but this location doesn't seem to exist, it just bounces me back to www.imagecraft.com. (I'm using Firefox 2.) In the meantime could you provide a link to download version 7.05 directly please. 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 jdurand at interstellar.com Thu Feb 8 13:26:27 2007 From: jdurand at interstellar.com (Jerry Durand) Date: Thu Feb 8 13:35:47 2007 Subject: [Icc-430] ICCv7 for MSP430 7.05 Released In-Reply-To: <6.1.0.6.2.20070208115252.07e96d60@192.168.100.42> References: <6.1.0.6.2.20070207225339.07e69398@192.168.100.42> <20070208174513.A72941A7A9E@smtp.interstellar.com> <6.1.0.6.2.20070208115252.07e96d60@192.168.100.42> Message-ID: <20070208212627.5FDC41A8DCF@smtp.interstellar.com> At 11:53 AM 2/8/2007, Richard wrote: >If you right click on a DLL and bring up its properties page, it >will list the version #. Don't do that with our .exe though since we >pretty much put random whatever tools use for our .exe in that field. Ah, completely different HIL files, one's from TI, the other is from NoICE. So, I guess they're not interchangeable. -- Jerry Durand, Durand Interstellar, Inc. www.interstellar.com tel: +1 408 356-3886, USA toll free: 1 866 356-3886 Skype: jerrydurand From richard-lists at imagecraft.com Thu Feb 8 13:51:14 2007 From: richard-lists at imagecraft.com (Richard) Date: Thu Feb 8 13:58:58 2007 Subject: [Icc-430] ICCv7 for MSP430 7.05 Released In-Reply-To: <027a01c74bc0$3d92bfa0$1917a8c0@KH> References: <6.1.0.6.2.20070207225339.07e69398@192.168.100.42> <027a01c74bc0$3d92bfa0$1917a8c0@KH> Message-ID: <6.1.0.6.2.20070208134837.07ef1a58@192.168.100.42> Kris, you must have the old DNS entry. Weird since the website changeover was almost a month ago. Somewhere your system is still caching it. Try using the new IP directly: http://198.207.204.28 and http://198.207.204.28/pub/iccv7430_demo.exe At 12:32 PM 2/8/2007, Kris Heidenstrom wrote: >Richard wrote: > >>V7.05 - Feb 8th 2007 > >There seems to be something wrong with the >Imagecraft web site. The "Imagecraft software" >link with the 30 second default points to >www.imagecraft.com/software but this location >doesn't seem to exist, it just bounces me back to >www.imagecraft.com. (I'm using Firefox 2.) > >In the meantime could you provide a link to >download version 7.05 directly please. > >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 > >_______________________________________________ >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 kris at abbey.co.nz Thu Feb 8 15:41:28 2007 From: kris at abbey.co.nz (Kris Heidenstrom) Date: Thu Feb 8 15:48:46 2007 Subject: [Icc-430] memcpy() from 16-bit hardware registers References: <6.1.0.6.2.20070207225339.07e69398@192.168.100.42> <027a01c74bc0$3d92bfa0$1917a8c0@KH> <6.1.0.6.2.20070208134837.07ef1a58@192.168.100.42> Message-ID: <028b01c74bda$a7971a80$1917a8c0@KH> Richard wrote: > Kris, you must have the old DNS entry. > Weird since the website changeover was > almost a month ago. > Somewhere your system is still caching it. > > Try using the new IP directly: http://198.207.204.28 > and http://198.207.204.28/pub/iccv7430_demo.exe Thanks, that works. I've been having an issue with memcpy() and I noticed that you've improved it slightly with this release, but the change doesn't solve my problem so I'm posting my comments here for feedback. I will first describe the problem, then describe my fix with code which Imagecraft is welcome to use if you think it's worthwhile. The icc430 v7.05 memcpy() always copies one byte at a time. This isn't very efficient but it simplifies the code in _memcpy since it needn't worry about alignment issues (the same loop will copy all four combinations of source and destination areas being even-aligned or odd-aligned). Apart from the efficiency, the only problem with this method occurs when you're trying to memcpy() from 16-bit hardware registers. This is an unusual thing to do, which is probably why no one has mentioned it before. If you access a 16-bit hardware register using two 8-bit accesses, the high-order byte doesn't read correctly (it always read as 0xFF for me). This is fair enough since TI's docs state that 16-bit hardware registers must be read and written using 16-bit-wide instructions, and normally would be, unless you're using memcpy() to read them. In our applications we have generalised diagnostic support that can read "memory" at any address range in the device. The data is memcpy()ed into a RAM buffer then sent upstream over a serial or SPI link. We may want to read hardware registers in this way, but using byte-at-a-time memcpy() doesn't work correctly. Byte-at-a-time memcpy() presumably wouldn't work for _writing_ to the hardware registers either, so if code uses memcpy() to copy an array of words to registers for bulk initialisation, it would probably write the wrong values to the registers too. For our application I have written a memcpy() equivalent function, aligned_memcpy(), which uses 16-bit-wide reads at even source addresses. It is always faster than icc430's memcpy() (except perhaps if the count is very small) and is fastest copying even-to-even. If all parameters (source, dest and nbytes) are even, it uses only 16-bit reads and writes, so it will also correctly initialise an array of 16-bit hardware registers from an array of words. Like normal memcpy() it doesn't handle overlapping memory areas. Here is the pseudo-code: void *memcpy(void *dest, const void *source, unsigned int nbytes) { word val16; word initial_dest = dest; if (nbytes) { if ((word)source & 1) { /* If source is odd */ *(byte *)dest++ = *(byte *)source++; --nbytes; } /* Now source must be even */ if ((word)dest & 1) { /* If dest is odd */ while (nbytes >= 2) { val16 = *(word *)source++; *(byte *)dest++ = val16 & 0xFF; *(byte *)dest++ = val16 >> 8; nbytes -= 2; } } else { /* If dest is even */ while (nbytes >= 2) { *(word *)dest++ = *(word *)source++; nbytes -= 2; } } /* Copy the final byte if present */ if (nbytes) *(byte *)dest = *(byte *)source; } return initial_dest; }/*memcpy*/ I haven't compiled the above code; probably some of the typecasting is not allowed. The intention is just to show what the code is supposed to do. Here is the assembly language version. This is written for ICC430 version 7.05 which passes parameters in R14, R15 and R12. The parameter passing convention is different for earlier versions of ICC. _aligned_memcpy: ; ; void *aligned_memcpy(void *dest, const void *source, unsigned int nbytes); ; ; dest --> R14 ; source --> R15 ; nbytes --> R12 ; R4~11 are not modified ; R13 is modified ; push r14 ; Keep dest to restore before return tst r12 ; Any nbytes? jeq amc_done ; If not bit #1,r15 ; Is source even or odd? jeq amc_src_even ; If even, skip this special case mov.b @r15+,0(r14) ; Copy one byte and bump source pointer inc r14 ; Bump dest pointer dec r12 ; Decrement byte count amc_src_even: bit #1,r14 ; Source is even now. Is dest is even or odd? jeq amc_e2e_test ; If dest is also even jmp amc_e2o_test ; Go to middle of loop amc_e2o_loop: mov.w @r15+,r13 ; Get 16-bit value from source mov.b r13,0(r14) ; Copy lobyte inc r14 ; Bump destination pointer by one swpb r13 ; Get hibyte to lobyte in R13 mov.b r13,0(r14) ; Copy hibyte inc r14 ; Bump destination pointer by one again amc_e2o_test: decd r12 ; Double-decrement nbytes jc amc_e2o_loop ; Loop if more (carry = ~borrow) jmp amc_last_byte ; Handle the final byte if present amc_e2e_loop: mov.w @r15+,0(r14) ; Copy the word directly and bump source pointer incd r14 ; Bump dest pointer amc_e2e_test: decd r12 ; Double-decrement nbytes jc amc_e2e_loop ; Loop if more (carry = ~borrow) amc_last_byte: incd r12 ; Double-increment nbytes to get actual count of bytes remaining to be copied jeq amc_done ; If zero, there's no final byte mov.b @r15,0(r14) ; Copy the final byte amc_done: pop r14 ; Reinstate original dest parameter as the return value ret This code is 43 words long, compared with 11 words for the simple memcpy(), so might not be appropriate to use as a standard memcpy(). 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 richard at imagecraft.com Tue Feb 13 03:05:50 2007 From: richard at imagecraft.com (Richard) Date: Tue Feb 13 03:13:45 2007 Subject: [Icc-430] Web sample code forums deprecated, long live the mailing lists... Message-ID: <6.1.0.6.2.20070213030343.07effa08@192.168.100.42> As mentioned previously, the web forum used for code samples are now disabled. The icc-XYZ mailing lists will be the proper channel for user communications. Samples codes are now on the respective web pages on the www.imagecraft.com site. If you have sample codes to share, please send them to me. 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 richard at imagecraft.com Wed Feb 14 16:03:59 2007 From: richard at imagecraft.com (Richard) Date: Wed Feb 14 16:11:57 2007 Subject: [Icc-430] ICCV7 for MSP430 V7.05A Released Message-ID: <6.1.0.6.2.20070214160320.077634a0@192.168.100.42> CHANGE LOGS: V7.05A - Feb 14th 2007 IDE/Compiler - Added F22xx and F23xx as 430X devices // 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. ]