From jim at fiocca.net Sat Aug 4 19:59:03 2007 From: jim at fiocca.net (Jim Fiocca) Date: Sat Aug 4 20:10:29 2007 Subject: [Icc-mot] Mixed C/ASM pointers In-Reply-To: <018001c7c2ba$eebfa0b0$0400a8c0@edvardo> References: <6.1.0.6.2.20070326182059.0b750e28@192.168.100.42> <468D2E77.7050100@fiocca.net> <468D2FAD.2010409@rjlsystems.com><468D3296.2000202@fiocca.net> <4692AEF3.4040505@fiocca.net> <018001c7c2ba$eebfa0b0$0400a8c0@edvardo> Message-ID: <46B53CF7.4080906@fiocca.net> I'm having trouble referencing assembly language pointers in C. In the assembly file I have: _vmdc: .asciz "hello world" .globl _vmdc In the C file I have: extern const char *vmdc; void speak(const char *msg); And then I reference it like this: speak(vmdc); And what happens is, the compiler passes 0x6865 (ASCII for 'he') instead of the address of the array. I can work around it with: speak(&vmdc); but I use lots of assembly pointers and don't want to have to remember to use this bad practice all over my code. Thanks, Jim From lance at rapidware.com Sat Aug 4 20:18:35 2007 From: lance at rapidware.com (Lance B. Smith) Date: Sat Aug 4 20:30:01 2007 Subject: [Icc-mot] Mixed C/ASM pointers In-Reply-To: <46B53CF7.4080906@fiocca.net> Message-ID: <200708050330.l753U0n4020280@dragonsgate2.imagecraft.com> Jim -- Without reading up on all of this assembly interface, you might try: ;Assembly (as before) _vmdc: .asciz "hello world" .globl _vmdc /* C: */ extern const char *vmdc; void speak(const char *msg[]); /* ... */ speak(&vmdc); It seems like your way should work, but it appears the compiler may need to go back one level of indirection. Regards -- Lance -----Original Message----- From: icc-mot-bounces@imagecraft.com [mailto:icc-mot-bounces@imagecraft.com] On Behalf Of Jim Fiocca Sent: Saturday, August 04, 2007 10:59 PM To: Discussion List for ICC08/11/12/16 users. You do NOT need to subscribe toicc-announce if you are a member of this. Subject: [Icc-mot] Mixed C/ASM pointers I'm having trouble referencing assembly language pointers in C. In the assembly file I have: _vmdc: .asciz "hello world" .globl _vmdc In the C file I have: extern const char *vmdc; void speak(const char *msg); And then I reference it like this: speak(vmdc); And what happens is, the compiler passes 0x6865 (ASCII for 'he') instead of the address of the array. I can work around it with: speak(&vmdc); but I use lots of assembly pointers and don't want to have to remember to use this bad practice all over my code. Thanks, Jim _______________________________________________ Icc-mot mailing list Icc-mot@imagecraft.com http://dragonsgate.net/mailman/listinfo/icc-mot From ekarpicz at freemail.lt Sat Aug 4 23:13:25 2007 From: ekarpicz at freemail.lt (Edward Karpicz) Date: Sat Aug 4 23:24:49 2007 Subject: [Icc-mot] Mixed C/ASM pointers References: <6.1.0.6.2.20070326182059.0b750e28@192.168.100.42> <468D2E77.7050100@fiocca.net> <468D2FAD.2010409@rjlsystems.com><468D3296.2000202@fiocca.net> <4692AEF3.4040505@fiocca.net><018001c7c2ba$eebfa0b0$0400a8c0@edvardo> <46B53CF7.4080906@fiocca.net> Message-ID: <001601c7d727$bc0f8aa0$a300a8c0@REKS> Jim Fiocca wrote: > I'm having trouble referencing assembly language pointers in C. > > In the assembly file I have: > _vmdc: .asciz "hello world" > .globl _vmdc > > In the C file I have: > extern const char *vmdc; ^^ this is extern "pointer to const char" variable. But you really have not pointer but chars at _vmdc. Define it as follows: extern const char vmdc[]; speak(vmdc) should work then. Regards Edward > void speak(const char *msg); > > And then I reference it like this: > speak(vmdc); > > And what happens is, the compiler passes 0x6865 (ASCII for 'he') instead > of the address of the array. > > I can work around it with: > speak(&vmdc); > but I use lots of assembly pointers and don't want to have to remember to > use this bad practice all over my code. > > Thanks, > Jim > > > _______________________________________________ > Icc-mot mailing list > Icc-mot@imagecraft.com > http://dragonsgate.net/mailman/listinfo/icc-mot > From richard-lists at imagecraft.com Sat Aug 4 23:14:42 2007 From: richard-lists at imagecraft.com (Richard) Date: Sat Aug 4 23:26:34 2007 Subject: [Icc-mot] Mixed C/ASM pointers In-Reply-To: <46B53CF7.4080906@fiocca.net> References: <6.1.0.6.2.20070326182059.0b750e28@192.168.100.42> <468D2E77.7050100@fiocca.net> <468D2FAD.2010409@rjlsystems.com> <468D3296.2000202@fiocca.net> <4692AEF3.4040505@fiocca.net> <018001c7c2ba$eebfa0b0$0400a8c0@edvardo> <46B53CF7.4080906@fiocca.net> Message-ID: <200708050626.l756QWib021216@dragonsgate2.imagecraft.com> User error, try extern const char vmdc[]; in your C file. Pointers and arrays are NOT the same.... (if I get a dollar for every time the compiler gets blamed :-) ) At 07:59 PM 8/4/2007, Jim Fiocca wrote: >I'm having trouble referencing assembly language pointers in C. > > In the assembly file I have: >_vmdc: .asciz "hello world" > .globl _vmdc > > In the C file I have: >extern const char *vmdc; >void speak(const char *msg); > > And then I reference it like this: > speak(vmdc); > >And what happens is, the compiler passes 0x6865 (ASCII for 'he') >instead of the address of the array. > >I can work around it with: > speak(&vmdc); >but I use lots of assembly pointers and don't want to have to >remember to use this bad practice all over my code. > >Thanks, > Jim > // richard (This email is for mailing lists. To reach me directly, please use richard at imagecraft.com) From jim at fiocca.net Sun Aug 5 11:09:29 2007 From: jim at fiocca.net (Jim Fiocca) Date: Sun Aug 5 11:20:54 2007 Subject: [Icc-mot] Mixed C/ASM pointers In-Reply-To: <200708050626.l756QWib021216@dragonsgate2.imagecraft.com> References: <6.1.0.6.2.20070326182059.0b750e28@192.168.100.42> <468D2E77.7050100@fiocca.net> <468D2FAD.2010409@rjlsystems.com> <468D3296.2000202@fiocca.net> <4692AEF3.4040505@fiocca.net> <018001c7c2ba$eebfa0b0$0400a8c0@edvardo> <46B53CF7.4080906@fiocca.net> <200708050626.l756QWib021216@dragonsgate2.imagecraft.com> Message-ID: <46B61259.3010900@fiocca.net> Didn't intend to blame the compiler, just looking for a solution to my problem. And this one works - thanks! Jim Richard wrote: > User error, try > > extern const char vmdc[]; > > in your C file. Pointers and arrays are NOT the same.... (if I get a > dollar for every time the compiler gets blamed :-) ) > > At 07:59 PM 8/4/2007, Jim Fiocca wrote: >> I'm having trouble referencing assembly language pointers in C. >> >> In the assembly file I have: >> _vmdc: .asciz "hello world" >> .globl _vmdc >> >> In the C file I have: >> extern const char *vmdc; >> void speak(const char *msg); >> >> And then I reference it like this: >> speak(vmdc); >> >> And what happens is, the compiler passes 0x6865 (ASCII for 'he') >> instead of the address of the array. >> >> I can work around it with: >> speak(&vmdc); >> but I use lots of assembly pointers and don't want to have to >> remember to use this bad practice all over my code. >> >> Thanks, >> Jim >> > > // richard (This email is for mailing lists. To reach me directly, > please use richard at imagecraft.com) > _______________________________________________ > Icc-mot mailing list > Icc-mot@imagecraft.com > http://dragonsgate.net/mailman/listinfo/icc-mot From richard-lists at imagecraft.com Sun Aug 5 13:54:05 2007 From: richard-lists at imagecraft.com (Richard) Date: Sun Aug 5 14:05:58 2007 Subject: [Icc-mot] Mixed C/ASM pointers In-Reply-To: <46B61259.3010900@fiocca.net> References: <6.1.0.6.2.20070326182059.0b750e28@192.168.100.42> <468D2E77.7050100@fiocca.net> <468D2FAD.2010409@rjlsystems.com> <468D3296.2000202@fiocca.net> <4692AEF3.4040505@fiocca.net> <018001c7c2ba$eebfa0b0$0400a8c0@edvardo> <46B53CF7.4080906@fiocca.net> <200708050626.l756QWib021216@dragonsgate2.imagecraft.com> <46B61259.3010900@fiocca.net> Message-ID: <200708052105.l75L5v09028438@dragonsgate2.imagecraft.com> Sorry, getting a tad too sensitive, probably from spending almost a week dealing with a customer who insists that the compiler was wrong... At 11:09 AM 8/5/2007, Jim Fiocca wrote: >Didn't intend to blame the compiler, just looking for a solution to >my problem. And this one works - thanks! > >Jim // richard (This email is for mailing lists. To reach me directly, please use richard at imagecraft.com) From barryc at rjlsystems.com Sun Aug 5 15:26:56 2007 From: barryc at rjlsystems.com (Barry Callahan) Date: Sun Aug 5 15:38:48 2007 Subject: [Icc-mot] Mixed C/ASM pointers In-Reply-To: <200708052105.l75L5v09028438@dragonsgate2.imagecraft.com> References: <6.1.0.6.2.20070326182059.0b750e28@192.168.100.42> <468D2E77.7050100@fiocca.net> <468D2FAD.2010409@rjlsystems.com> <468D3296.2000202@fiocca.net> <4692AEF3.4040505@fiocca.net> <018001c7c2ba$eebfa0b0$0400a8c0@edvardo> <46B53CF7.4080906@fiocca.net> <200708050626.l756QWib021216@dragonsgate2.imagecraft.com> <46B61259.3010900@fiocca.net> <200708052105.l75L5v09028438@dragonsgate2.imagecraft.com> Message-ID: <46B64EB0.1010807@rjlsystems.com> You have my deepest sympathy. Sometimes customers suck. Richard wrote: > Sorry, getting a tad too sensitive, probably from spending almost a > week dealing with a customer who insists that the compiler was wrong... > > At 11:09 AM 8/5/2007, Jim Fiocca wrote: > >> Didn't intend to blame the compiler, just looking for a solution to >> my problem. And this one works - thanks! >> >> Jim > > > // richard (This email is for mailing lists. To reach me directly, > please use richard at imagecraft.com) > _______________________________________________ > Icc-mot mailing list > Icc-mot@imagecraft.com > http://dragonsgate.net/mailman/listinfo/icc-mot From richard at imagecraft.com Tue Aug 14 03:05:24 2007 From: richard at imagecraft.com (Richard) Date: Tue Aug 14 03:17:37 2007 Subject: [Icc-mot] Product News Message-ID: <200708141017.l7EAHXTL058581@dragonsgate2.imagecraft.com> With all the developments going on, sometimes it is hard to keep track of things. There is also some rumors that we are emphasizing certain compilers less etc. so hopefully this email will also address some of those concerns. Obviously, we are in the business to make money, I have always believe that by providing excellent support, a decent development toolset, plus the low cost factor, that we would be able to make a decent living. I see no reason to change from that philosophy. ImageCraft is relatively speaking a small company, but then again, so is the embedded tools market. A million unit a year gadget may only need one copy of the compiler for development! This is a challenging market. There are gazillions devices out there, each with a potential market of only a few thousand compiler licenses in total at best. With multiple fishes in the pond, the feeding can get thin indeed. Then you have brilliant silicon manufacturers who think that it is in their best interest to have their own software tools, not caring that it is an effective way to drive away their third party tool vendors. So we have to adjust. We have to look at the potential markets and react, we have to change our development team setup, we have to look ahead and come up with effective strategies and tactics. Given this light, the last thing we want to do is to abandon our existing markets. While we believe the growth markets would likely be the AVR and ARM, there is no reason not to continue to develop for the HCS12 and MSP430 platforms. Especially with the new generations of the S12X and MSP430X devices coming in, the market potential is bigger than ever. But we need to be smarter. May be we should look into educational kits with detail examples and an easy to use board bundles. Perhaps we need to add more companion products such as a RTOS. May be we need to be more aggressive in making sure users pay for the annual maintenance.... Of course, coming from a techie background, most importantly, we have to continue to improve on our technologies. The MIO global optimizer is working well and we have come up with a plan to improve the performance further. We need to implement features like __far and __flash to support certain chip features better (paged function under S12 and flash items under AVR), and we need to deliver the 64 bits FP support. And we need to widen the net farther. We are very excited about the new Parallax Propeller chips. 8 32 bits core on a single chip. While it is not a microcontroller per se, the chip has a lot of potential. A Propeller C, which is under development, is potentially huge. Beyond that, the Atmel AVR32 is a natural target for us, and we have new resources with Eclipse expertise so we would be able to leverage the Studio32 platform from day one. Oh, BTW, relating to that, we will be releasing an AVR Studio plugin for ICCAVR soon and users than can use one single IDE for the AVR platform. All these take human, monetary and time resources. It is a challenging road we have chosen, but I am confident that we are set up to succeed. I thank you all for the support you have given us over the years. I hope this is useful information and I welcome any comments and suggestions you may have, either on the list or to me privately. Thank you. // richard From richard at imagecraft.com Fri Aug 17 00:21:44 2007 From: richard at imagecraft.com (Richard) Date: Fri Aug 17 00:34:05 2007 Subject: [Icc-mot] CPU12 V7.03A released Message-ID: <200708170734.l7H7Y3Zj008551@dragonsgate2.imagecraft.com> V7.03A - August 17th, 2007 IDE/Compiler - Added "MIO Global Optimizations" to the Project->Options->Compiler tab. As MIO has not been fully tuned for the CPU12 target, please consider this as beta testing of this feature. As such, this is enabled for all versions. When released, MIO will only be enabled for the PRO version. Please notify us of any issues you may encounter while beta testing MIO. Compiler - Occsionally the compiler optimizer incorrectly removed an instruction - compiler was incorrectly using int to floating point conversion in the cases where it should be using unsigned to floating point conversion. // 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 ekarpicz at freemail.lt Mon Aug 20 10:22:40 2007 From: ekarpicz at freemail.lt (Edward Karpicz) Date: Mon Aug 20 10:50:11 2007 Subject: [Icc-mot] CPU12 V7.03A released References: <200708170734.l7H7Y3Zj008551@dragonsgate2.imagecraft.com> Message-ID: <006101c7e350$c90c8c00$a300a8c0@REKS> Richard, 1) is this V7.03A supposed to show some power of MIO? I see no difference between MIO = on and MIO=off. 2) compared V7.03 to V7.03A output I found compiler got worse. 7.03A generates emits extra TFR D,X or TFR D,Y which don't make sense. For example ; ISRflags|=CANRXISRflg; ldd _ISRflags ora #1 orb #0 tfr D,Y <=== this transfer doesn't make any sense std _ISRflags .dbline 91 ; #endif ; regptr.regflgs = canregflagsmap + (unsigned int)num; ldy #_canregflagsmap ... It it a fix for > - Occsionally the compiler optimizer incorrectly removed an > instruction 3) > - compiler was incorrectly using int to floating point conversion in > the cases where it should be using unsigned to floating point > conversion. Maybe I missing something but it looks like behaviour didn't change. Same code in both 7.03 and 7.03A: ; signed int i; ; unsigned int u; ; float f; ; ; f=i; ldd 2,S jsr int2fp puld std 6,S puld std 6,S ; f=u; ldd 0,S jsr int2fp puld std 6,S puld std 6,S Regards Edward ----- Original Message ----- From: "Richard" To: ; Sent: Friday, August 17, 2007 10:21 Subject: [Icc-mot] CPU12 V7.03A released > V7.03A - August 17th, 2007 > IDE/Compiler > - Added "MIO Global Optimizations" to the Project->Options->Compiler > tab. As MIO has not been fully tuned for the CPU12 target, please > consider this as beta testing of this feature. As such, this is > enabled for all versions. When released, MIO will only be enabled > for the PRO version. Please notify us of any issues you may > encounter while beta testing MIO. > Compiler > - Occsionally the compiler optimizer incorrectly removed an > instruction > - compiler was incorrectly using int to floating point conversion in > the cases where it should be using unsigned to floating point > conversion. > > > // 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. ] > _______________________________________________ > Icc-mot mailing list > Icc-mot@imagecraft.com > http://dragonsgate.net/mailman/listinfo/icc-mot > From dean.bell at flightec.com Mon Aug 20 12:59:46 2007 From: dean.bell at flightec.com (Dean Bell) Date: Mon Aug 20 13:12:19 2007 Subject: [Icc-mot] CPU12 V7.03A released Message-ID: <006101c7e364$a8959ac0$1101a8c0@Technicaldesgnxp1b12e69c9632> Hi Richard There was no change in the code size between MIO on and off, do you have any test source code to show MIO in action please? Dean. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-mot/attachments/20070821/502d9636/attachment.html From richard-lists at imagecraft.com Tue Aug 21 03:44:35 2007 From: richard-lists at imagecraft.com (Richard) Date: Tue Aug 21 03:56:13 2007 Subject: [Icc-mot] CPU12 V7.03A released In-Reply-To: <006101c7e364$a8959ac0$1101a8c0@Technicaldesgnxp1b12e69c963 2> References: <006101c7e364$a8959ac0$1101a8c0@Technicaldesgnxp1b12e69c9632> Message-ID: <200708211056.l7LAuBA6063957@dragonsgate2.imagecraft.com> An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-mot/attachments/20070821/8e98695f/attachment.html From oskar at atk-it.com Thu Aug 23 08:31:09 2007 From: oskar at atk-it.com (Oskar Atkinson) Date: Thu Aug 23 08:43:11 2007 Subject: [Icc-mot] GNU to ICC Message-ID: <62B9B4B3C4921F48A08F1F160197507009414E@atk-master.atk-it.com> Hi, I am absulutly new to programming on Frescale uC's ( HC9S12C64 ), professionally I am developing for the win32 platform. I am attemting to port code which is written for GNU to ICC. Of course I am getting all kinds of compiler errors How would this be correct in ICC ? #define LOOKUP_ATTR __attribute__ ((section (".lookup"))) #define VECT_ATTR __attribute__ ((section (".vectors"))) extern const int cltfactor_table[1024] LOOKUP_ATTR; INTERRUPT void UnimplementedISR(void) POST_INTERRUPT; INTERRUPT void ISR_Ign_TimerIn(void) POST_INTERRUPT_TEXT3; TIA Oskar -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-mot/attachments/20070823/faff1e02/attachment.html From ekarpicz at freemail.lt Sat Aug 25 10:05:13 2007 From: ekarpicz at freemail.lt (Edward Karpicz) Date: Sat Aug 25 10:17:19 2007 Subject: [Icc-mot] GNU to ICC References: <62B9B4B3C4921F48A08F1F160197507009414E@atk-master.atk-it.com> Message-ID: <001601c7e73a$1a201ca0$a300a8c0@REKS> Oskar Atkinson wrote: Hi, I am absulutly new to programming on Frescale uC's ( HC9S12C64 ), professionally I am developing for the win32 platform. I am attemting to port code which is written for GNU to ICC. Of course I am getting all kinds of compiler errors Porting is easy when you know what you are doing. I'm not familiar with GCC, I may only guess what all those attributes are about. How would this be correct in ICC ? #define LOOKUP_ATTR __attribute__ ((section (".lookup"))) #define VECT_ATTR __attribute__ ((section (".vectors"))) extern const int cltfactor_table[1024] LOOKUP_ATTR; ^^ this looks like putting some table of constants into nondefault memory area. Well, with extern declaration (in the header probably) you shouldn't do anything, just remove LOOKUP_ATTR. extern const int cltfactor_table[1024]; Definition is bit different. First of all create you custom memory section by putting -b linker option into Project->Options->Other Options edit box. For example -blookup:0x1000.0x4FFF ^^ this defines area lookup from 0x1000 to 0x4FFF Then in C source you write #pragma text:lookup const int cltfactor_table[1024]={1,2,3,4,5,6}; // add here more initialized const variables #pragma text:text INTERRUPT void UnimplementedISR(void) POST_INTERRUPT; INTERRUPT void ISR_Ign_TimerIn(void) POST_INTERRUPT_TEXT3; ISR's must be easier than in GCC. 1) Remove INTERRUPT and POST_xxx, 2) add #pragma interrupt_handler to the file where ISR's are defined: #pragma interrupt_handler UnimplementedISR void UnimplementedISR(void) { ... } #pragma interrupt_handler ISR_Ign_TimerIn void ISR_Ign_TimerIn(void) { } Regards Edward TIA Oskar ------------------------------------------------------------------------------ _______________________________________________ Icc-mot mailing list Icc-mot@imagecraft.com http://dragonsgate.net/mailman/listinfo/icc-mot -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-mot/attachments/20070825/c10f5d35/attachment.html From oskar at atk-it.com Mon Aug 27 10:30:36 2007 From: oskar at atk-it.com (Oskar Atkinson) Date: Mon Aug 27 10:42:05 2007 Subject: [Icc-mot] GNU to ICC References: <62B9B4B3C4921F48A08F1F160197507009414E@atk-master.atk-it.com> <001601c7e73a$1a201ca0$a300a8c0@REKS> Message-ID: <62B9B4B3C4921F48A08F1F160197507009415B@atk-master.atk-it.com> Edward, thanks a lot. It really helped to get me started. Oskar ________________________________ From: icc-mot-bounces@imagecraft.com [mailto:icc-mot-bounces@imagecraft.com] On Behalf Of Edward Karpicz Sent: Samstag, 25. August 2007 10:05 To: Discussion List for ICC08/11/12/16 users. You do NOT need tosubscribetoicc-announce if you are a member of this. Subject: Re: [Icc-mot] GNU to ICC Oskar Atkinson wrote: Hi, I am absulutly new to programming on Frescale uC's ( HC9S12C64 ), professionally I am developing for the win32 platform. I am attemting to port code which is written for GNU to ICC. Of course I am getting all kinds of compiler errors Porting is easy when you know what you are doing. I'm not familiar with GCC, I may only guess what all those attributes are about. How would this be correct in ICC ? #define LOOKUP_ATTR __attribute__ ((section (".lookup"))) #define VECT_ATTR __attribute__ ((section (".vectors"))) extern const int cltfactor_table[1024] LOOKUP_ATTR; ^^ this looks like putting some table of constants into nondefault memory area. Well, with extern declaration (in the header probably) you shouldn't do anything, just remove LOOKUP_ATTR. extern const int cltfactor_table[1024]; Definition is bit different. First of all create you custom memory section by putting -b linker option into Project->Options->Other Options edit box. For example -blookup:0x1000.0x4FFF ^^ this defines area lookup from 0x1000 to 0x4FFF Then in C source you write #pragma text:lookup const int cltfactor_table[1024]={1,2,3,4,5,6}; // add here more initialized const variables #pragma text:text INTERRUPT void UnimplementedISR(void) POST_INTERRUPT; INTERRUPT void ISR_Ign_TimerIn(void) POST_INTERRUPT_TEXT3; ISR's must be easier than in GCC. 1) Remove INTERRUPT and POST_xxx, 2) add #pragma interrupt_handler to the file where ISR's are defined: #pragma interrupt_handler UnimplementedISR void UnimplementedISR(void) { ... } #pragma interrupt_handler ISR_Ign_TimerIn void ISR_Ign_TimerIn(void) { } Regards Edward TIA Oskar ________________________________ _______________________________________________ Icc-mot mailing list Icc-mot@imagecraft.com http://dragonsgate.net/mailman/listinfo/icc-mot -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-mot/attachments/20070827/df3aba68/attachment.html From v.dijk.bas at gmail.com Thu Aug 30 01:07:57 2007 From: v.dijk.bas at gmail.com (Bas van Dijk) Date: Thu Aug 30 01:19:55 2007 Subject: [Icc-mot] Upgrade from ICC12 v6 to v7 Message-ID: (resending this message because the previous did not come through) Hello, I'm trying to upgrade from ICC12 6.16A to ICC12 7.03A (demo). I have a project that runs fine when compiled with v6.16A but when I compile it with 7.03A, load it on the device and run it the device stops functioning (no sign of life: no LCD, no serial communication, no flickering leds). Do I have to change some code or is it just some project setting that needs to be changed? I attached the projectfiles from both versions. As you can see I'm using a HC9S12Dx512 device. I also postprocess the .s19 file with: C:\Program Files\icc\bin\SRecCvt -m 80000 FFFFF 32 -lp -o Any pointers are highly appreciated. regards, Bas van Dijk http://members.home.nl/basvandijk/ethylenedetector_v6.prj http://members.home.nl/basvandijk/ethylenedetector_v7.prj From ekarpicz at freemail.lt Thu Aug 30 10:19:27 2007 From: ekarpicz at freemail.lt (Edward Karpicz) Date: Thu Aug 30 10:31:47 2007 Subject: [Icc-mot] Upgrade from ICC12 v6 to v7 References: Message-ID: <000801c7eb29$f11c03c0$0200a8c0@leon> Bas, 1) I see that both, V7 and V6, projects use same library and include paths: Edit1=C:\Progra~1\icc\include;.\; Edit2=C:\Progra~1\icc\lib This is wrong. V7 and V6 libs are incompatible. When building with V7, compiler should use V7 headers and linker should link with V7 libs (just bank lib and include paths in project options). I wonder how it didn't complain about missing symbols. Did you try to rebuild all (Shift+F9)? 2) do you have some pieces of inline asm? If you have then check them for compatibility with V7. Someone already has failed to use something like this: asm(" PSHX"); asm(" LDD %var"); // problem here because since V7 // frame pointer is now SP and one should take it into account // when manipulating SP asm(" PULX"); Edward ----- Original Message ----- From: "Bas van Dijk" To: Sent: Thursday, August 30, 2007 11:07 AM Subject: [Icc-mot] Upgrade from ICC12 v6 to v7 > (resending this message because the previous did not come through) > > Hello, > > I'm trying to upgrade from ICC12 6.16A to ICC12 7.03A (demo). I have a > project that runs fine when compiled with v6.16A but when I compile it > with 7.03A, load it on the device and run it the device stops > functioning (no sign of life: no LCD, no serial communication, no > flickering leds). Do I have to change some code or is it just some > project setting that needs to be changed? > > I attached the projectfiles from both versions. As you can see I'm > using a HC9S12Dx512 device. I also postprocess the .s19 file with: > > C:\Program Files\icc\bin\SRecCvt -m 80000 FFFFF 32 -lp -o > > > Any pointers are highly appreciated. > > regards, > > Bas van Dijk > > http://members.home.nl/basvandijk/ethylenedetector_v6.prj > http://members.home.nl/basvandijk/ethylenedetector_v7.prj > > _______________________________________________ > Icc-mot mailing list > Icc-mot@imagecraft.com > http://dragonsgate.net/mailman/listinfo/icc-mot > From v.dijk.bas at gmail.com Fri Aug 31 05:55:37 2007 From: v.dijk.bas at gmail.com (Bas van Dijk) Date: Fri Aug 31 06:07:47 2007 Subject: [Icc-mot] Upgrade from ICC12 v6 to v7 In-Reply-To: <000801c7eb29$f11c03c0$0200a8c0@leon> References: <000801c7eb29$f11c03c0$0200a8c0@leon> Message-ID: On 8/30/07, Edward Karpicz wrote: > 1) I see that both, V7 and V6, projects use same library and include paths: > > Edit1=C:\Progra~1\icc\include;.\; > Edit2=C:\Progra~1\icc\lib I have no V6 installed (I uninstalled it before installing V7). So these path are from V7. > 2) do you have some pieces of inline asm? The only asm I use is NOP :-) Thanks, Bas From ekarpicz at freemail.lt Fri Aug 31 08:09:29 2007 From: ekarpicz at freemail.lt (Edward Karpicz) Date: Fri Aug 31 18:03:36 2007 Subject: [Icc-mot] Upgrade from ICC12 v6 to v7 References: <000801c7eb29$f11c03c0$0200a8c0@leon> Message-ID: <000b01c7ebe0$edf497e0$0200a8c0@leon> Bas van Dijk wrote: > On 8/30/07, Edward Karpicz wrote: >> 1) I see that both, V7 and V6, projects use same library and include >> paths: >> >> Edit1=C:\Progra~1\icc\include;.\; >> Edit2=C:\Progra~1\icc\lib > > I have no V6 installed (I uninstalled it before installing V7). So > these path are from V7. > OK, then no ideas. I upgraded many projects to V7 but don't remember any real issues. Did you try to use original V7 output file, not one generated by Sreccvt? Calling sreccvt with -m 80000 fffff 32 -lp, it won't be able to convert 0x8000-0xBFFF addresses properly. Regards Edward > >> 2) do you have some pieces of inline asm? > > The only asm I use is NOP :-) > > > Thanks, > > Bas > > _______________________________________________ > Icc-mot mailing list > Icc-mot@imagecraft.com > http://dragonsgate.net/mailman/listinfo/icc-mot