From richard at imagecraft.com Fri Dec 5 00:19:33 2008 From: richard at imagecraft.com (Richard Man) Date: Fri Dec 5 01:22:29 2008 Subject: [Icc-avr] eMOS for AVR Released Message-ID: <200812050922.mB59MRJq027013@mail.imagecraft.com> doc: http://www.imagecraft.com/pub/emos_avr.pdf zip: http://www.imagecraft.com/pub/emos_avr.zip The zip file is the demo version. You are limited to up to 5 tasks. Currently you will need to unzip the content in a temporary directory and then copy the files: copy *.h c:\iccv7avr\include copy lib*.a c:\iccv7avr\lib When we release the next AVR update, the files will be incorporated directly. **** We really feel that eMOS is a very useful tool. The core features of preemptive multitasking and message passing are nice, but we also carefully added additional features such as stack checking, virtual watchdog, and system call error checking, which can save you significantly amount of debugging time. Please check out the documentation or the demo and see for yourselve. **** Our next port is probably either the MSP430 (the system idle task hook is ideal for low power systems) or ARM. Let me know if you have interest in either port. 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 steve.williams at westnet.com.au Fri Dec 5 16:36:43 2008 From: steve.williams at westnet.com.au (Insilicon Embedded Solutions Pty Ltd) Date: Fri Dec 5 17:41:48 2008 Subject: [Icc-avr] eMOS for AVR Released Message-ID: <380-22008126603643517@westnet.com.au> ---- Original Message ---- From: richard@imagecraft.com To: icc-announce@imagecraft.com, icc-avr@imagecraft.com, icc-mot@imagecraft.com, icc-430@imagecraft.com, icc-arm@imagecraft.com Subject: [Icc-avr] eMOS for AVR Released Date: Fri, 05 Dec 2008 00:19:33 -0800 >doc: http://www.imagecraft.com/pub/emos_avr.pdf >zip: http://www.imagecraft.com/pub/emos_avr.zip > >The zip file is the demo version. You are limited to up to 5 tasks. >Currently you will need to unzip the content in a temporary directory > >and then copy the files: > >copy *.h c:\iccv7avr\include >copy lib*.a c:\iccv7avr\lib > >When we release the next AVR update, the files will be incorporated >directly. > >**** >We really feel that eMOS is a very useful tool. The core features of >preemptive multitasking and message passing are nice, but we also >carefully added additional features such as stack checking, virtual >watchdog, and system call error checking, which can save you >significantly amount of debugging time. Please check out the >documentation or the demo and see for yourselve. > >**** >Our next port is probably either the MSP430 (the system idle task >hook is ideal for low power systems) or ARM. Let me know if you have >interest in either port. > >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. ] > >_______________________________________________ >Icc-avr mailing list >Icc-avr@imagecraft.com >http://dragonsgate.net/mailman/listinfo/icc-avr Hi Richard, I would prefer ARM as the next port please. Cheers Steve Williams Insilicon Embedded Solutions Pty Ltd From sl at ecpower.dk Tue Dec 9 11:54:51 2008 From: sl at ecpower.dk (Steven Lose) Date: Tue Dec 9 13:00:03 2008 Subject: [Icc-avr] size of array in flash! Message-ID: <072D96786BFC014AAEBA9EB07A8070EA542B91@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: image002.jpg Url : http://dragonsgate.net/pipermail/icc-avr/attachments/20081209/fda5e8cf/attachment.jpe From bobgardner at aol.com Tue Dec 9 17:35:34 2008 From: bobgardner at aol.com (bobgardner@aol.com) Date: Tue Dec 9 18:41:28 2008 Subject: [Icc-avr] size of array in flash! In-Reply-To: <072D96786BFC014AAEBA9EB07A8070EA542B91@seattle.ecpower.dk> References: <072D96786BFC014AAEBA9EB07A8070EA542B91@seattle.ecpower.dk> Message-ID: <8CB287EBAF18F30-1354-1828@FWM-D19.sysops.aol.com> Declare const char jnk1=1; and const char jnk2=2 before and after the key array and then look at the size in the map file. If you get the latest compiler it has a real good map file util by Johannes A. -----Original Message----- From: Steven Lose Sent: Tue, 9 Dec 2008 2:54 pm Subject: [Icc-avr] size of array in flash! Hi. ? I have a array like this: ? #define NROFBUTTONS 4 const unsigned char KeyPattern[NROFBUTTONS] = {0x40,0x02,0x01,0x20}; ? The map says: ? FLASH area "lit" = 18213 (0x4725) bytes from 0x02FD to 0x4A21 _KeyPattern? =?? 20 (0x0014) bytes ? How can those 4 bytes take up 20 bytes of flash? Is it the map file showing wrong size or ??? ? I?m using 7.14B ? 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 ? ? _______________________________________________ cc-avr mailing list cc-avr@imagecraft.com ttp://dragonsgate.net/mailman/listinfo/icc-avr -------------- next part -------------- Skipped content of type multipart/related From sl at ecpower.dk Wed Dec 10 01:33:01 2008 From: sl at ecpower.dk (Steven Lose) Date: Wed Dec 10 02:38:14 2008 Subject: SV: [Icc-avr] size of array in flash! In-Reply-To: <8CB287EBAF18F30-1354-1828@FWM-D19.sysops.aol.com> References: <072D96786BFC014AAEBA9EB07A8070EA542B91@seattle.ecpower.dk> <8CB287EBAF18F30-1354-1828@FWM-D19.sysops.aol.com> Message-ID: <072D96786BFC014AAEBA9EB07A8070EA542BBE@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/20081210/e0a554ca/attachment-0002.jpe -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 2650 bytes Desc: image002.jpg Url : http://dragonsgate.net/pipermail/icc-avr/attachments/20081210/e0a554ca/attachment-0003.jpe From richard at imagecraft.com Mon Dec 15 04:50:29 2008 From: richard at imagecraft.com (Richard Man) Date: Mon Dec 15 05:53:36 2008 Subject: [Icc-avr] ImageCraft news, next-gen IDE etc. Message-ID: <200812151353.mBFDrYCB021399@mail.imagecraft.com> Lots of little updates, checkout our blog at http://imagecraft.wordpress.com // 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 Dec 15 07:13:38 2008 From: sl at ecpower.dk (Steven Lose) Date: Mon Dec 15 08:19:00 2008 Subject: [Icc-avr] 7.14B vs 7.19 with ATMEGA2561 Message-ID: <072D96786BFC014AAEBA9EB07A8070EA568536@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: image002.jpg Url : http://dragonsgate.net/pipermail/icc-avr/attachments/20081215/d31d30c7/attachment.jpe From sidprice at softtools.com Sat Dec 27 14:56:42 2008 From: sidprice at softtools.com (Sid Price) Date: Sat Dec 27 16:02:21 2008 Subject: [Icc-avr] Problem reading program memory Message-ID: <49C038D6F09744A5AA4BC1148D685A1B@SID004> 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20081227/2f55bacb/attachment.html From richard at imagecraft.com Mon Dec 29 02:04:50 2008 From: richard at imagecraft.com (Richard Man) Date: Mon Dec 29 03:08:33 2008 Subject: [Icc-avr] V7.20 Beta Message-ID: <200812291108.mBTB8UcZ051453@mail.imagecraft.com> http://www.imagecraft.com/pub/iccv7avr_v720_beta0.exe 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 DRaymond at Bankspower.com Mon Dec 29 08:22:27 2008 From: DRaymond at Bankspower.com (David Raymond) Date: Mon Dec 29 09:29:30 2008 Subject: [Icc-avr] Problem reading program memory In-Reply-To: <49C038D6F09744A5AA4BC1148D685A1B@SID004> References: <49C038D6F09744A5AA4BC1148D685A1B@SID004> Message-ID: <0E755D4F91B6D344B39791054F52A2A905C7645F@gbexchange.bankspower.local> 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/20081229/25dc4b29/attachment.html