From richard at imagecraft.com Tue Jul 7 11:57:55 2009 From: richard at imagecraft.com (Richard Man) Date: Tue Jul 7 13:08:49 2009 Subject: [Icc-mot] Fwd: EEPROM Address Message-ID: <200907072008.n67K8mcx093686@mail.imagecraft.com> An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-mot/attachments/20090707/894b1f44/attachment.html From ekarpicz at freemail.lt Wed Jul 8 03:31:44 2009 From: ekarpicz at freemail.lt (Edward Karpicz) Date: Wed Jul 8 04:41:27 2009 Subject: [Icc-mot] Fwd: EEPROM Address References: <200907072008.n67K8mcx093686@mail.imagecraft.com> Message-ID: Hi Richard, 1. I am having a problem understanding how the compiler addresses paged memory, especially EEPROM. Currently ICC12 doesn't support paged data memory. All data memory accesses are limited to 16bits address space called "CPU Local Memory Map", please see MC9S12XDP512 datasheet, Figure 1-3. S12X CPU & BDM Global Address Mapping 2. EEPROM Start = 0x13_F000. (MC9S12XDP512) Here ^^ 0x13_F000 is a global address of start of EEPROM. Global addressing is not available without use of new S12X instructions beginning with G, like GLDAA, GSTAA etc. 3. Paged RAM and paged EEPROM can be accessed manipulating RPAGE and EPAGE registers. Nonpaged XDP512 RAM is in "CPU Local Memory Map" at 0x2000..0x3FFF. RAM page window - at 0x1000..0x1FFF. Nonpaged EEPROM - at 0xC00..0xFFF. EEPROM page window - at 0x800..0xBFF. 4. Paged FLASH is the most hard to access using ICC12, because PPAGE register can't be manipulated while executing code from flash page window 0x8000..0xBFFF. Small aplications with up to 32k of code don't have paged flash access problem, because nonpaged 32k code could run from nonpaged "CPU local" address ranges 0x4000..0x7FFF and 0xC000..0xFFFF; PPAGE could be manipulated when required. Edward ----- Original Message ----- From: Richard Man To: icc-mot@imagecraft.com Sent: Tuesday, July 07, 2009 21:57 Subject: [Icc-mot] Fwd: EEPROM Address Some of you have vastly more experience with the S12X than I do, does anyone know the answer to this inquiry from one of our customers? Thanks. Hello Richard, I am having a problem understanding how the compiler addresses paged memory, especially EEPROM. ICCV7 - Windows XP EEPROM Start = 0x13_F000. (MC9S12XDP512) Can you suggest a method or point me in the right direction regarding this problem? // richard < http://www.imagecraft.com/> blog: < http://imagecraft.wordpress.com> // mailing list: http://www.dragonsgate.net/mailman/listinfo // photo book: http://www.blurb.com/bookstore/detail/745963 [ 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-mot/attachments/20090708/2b09143f/attachment.html From richard at imagecraft.com Wed Jul 8 20:49:17 2009 From: richard at imagecraft.com (Richard Man) Date: Wed Jul 8 22:00:15 2009 Subject: [Icc-mot] CPUS12: logical to physical Message-ID: <200907090500.n6950EPR036174@mail.imagecraft.com> I am considering adding the similar functionality of P&E's log2phy into the ICC12 so the utility won't be necessary. For the HCS12 devices, currently I am using the logical addresses 64K devices: 0xF0000.0xFFFFF 128K devices: 0xE0000.0xFFFFF 256K devices: 0xC0000.0xFFFFF 512K devices: 0x80000.0xFFFFF If I understand this correctly, if I replace them with the physical addresses, e.g. 64K: 0x3F0000.0x3FFFFF 128K: 0x3E0000.0x3FFFFF 256K: 0x3C0000.0x3FFFFF 512K: 0x380000.0x3FFFFF For the S12X, currently we have (or will have, as I just updated the XDx512): 128K S12X: 0x3E0000.0x3FFFFF 256K S12X: 0x380000.0x39FFFF:0x3E0000.0x3FFFFF 512K S12X: 0x788000.0x7FFFFF **** Then we have to convert 0x4000.0x7FFF / 0xC000.0xFFFF to the right physical page, which should be relatively easy once the correct physical address range is used. The linker already supports S12 vs. S12X conversion so I think we are mostly there. Anything else I miss? Any advices on what actual addresses to use will be appreciated. Thanks. // richard blog: // mailing list: http://www.dragonsgate.net/mailman/listinfo // photo book: http://www.blurb.com/bookstore/detail/745963 [ For technical support on ImageCraft products, please include all previous replies in your msgs. ] From ekarpicz at freemail.lt Wed Jul 8 21:49:06 2009 From: ekarpicz at freemail.lt (Edward Karpicz) Date: Wed Jul 8 22:58:48 2009 Subject: [Icc-mot] CPUS12: logical to physical References: <200907090500.n6950EPR036174@mail.imagecraft.com> Message-ID: <0017C2AEE5C44916B865F9F77EC86730@REKS> Richard, >I am considering adding the similar functionality of P&E's log2phy into the >ICC12 so the utility won't be necessary. For the HCS12 devices, currently I >am using the logical addresses > > 64K devices: 0xF0000.0xFFFFF > 128K devices: 0xE0000.0xFFFFF > 256K devices: 0xC0000.0xFFFFF > 512K devices: 0x80000.0xFFFFF These ^^ "logical" addresses are physical. By physical Freescale and/or P&E mean internal hidden contiguous S12 flash address space. ICC12 linear addresses is what tools like P&E Prog12z understand. So please notice next few lines are not valid for S12: wrong:> If I understand this correctly, if I replace them with the physical wrong: > addresses, e.g. wrong:> 64K: 0x3F0000.0x3FFFFF wrong:> 128K: 0x3E0000.0x3FFFFF wrong:> 256K: 0x3C0000.0x3FFFFF wrong:> 512K: 0x380000.0x3FFFFF ICC12 linear addresses are fine for S12 and both Freescale factory programming and P&E software understands them. The only problem is they won't understand S1 records and all three CPU logical areas (CPU logical is FSL term, nonpaged in our understanding): 4000..7fff, 8000..bfff, c000..ffff have to be converted into corresponding linear/physical addresses. 4000..7fff to page 3E physical/linear addresses, 3E*4000 = F8000..FBFFF addresses. c000..ffff to page 3F - 3F*4000 = FC000..FFFFF. And nonpaged 8000..BFFF, depending on S12 device memory size, has to be converted to least available ppage number. on 32K devices, 8000..BFFF should be converted to 3E*4000 = F8000..FBFFF on 64K devices, 8000..BFFF should be converted to 3C*4000 = F0000..F3FFF on 128K devices, 8000..BFFF should be converted to 38*4000 = E0000..E3FFF on 256K devices , 8000..BFFF should be converted to 30*4000 = C0000..C3FFF > > For the S12X, currently we have (or will have, as I just updated the XDx512): > > 128K S12X: 0x3E0000.0x3FFFFF > 256K S12X: 0x380000.0x39FFFF:0x3E0000.0x3FFFFF > 512K S12X: 0x788000.0x7FFFFF No. First of all X devices should be converted the same way, despite of available memory, because nonpaged 8000..bfff defaults to page FE on all X devices. And 4000.7fff is fixed page FD, and c0000.ffff is fixed page FF. On S12 you have to convert different parts differently, because reset maps least available memory page to page window; which on S12X was made standartized, despite of available flash size, reset maps page FE to page window. Secondly, standard for S12X records are S records with global addresses. Global is linear address + 0x400000. Linear address is page number*0x4000. Add to product 0x400000 and you get global address. For example 512K parts have page number min E0 and max FF. That corresponds to Whole 512K X device flash memory is E0*4000 = 380000 to FF*4000+3FFF = 3FFFFF linear addresses. Nonpaged 4000..7fff could be FD*4000 = 3F4000..3F7FFF linear addresses Nonpaged 8000..bfff could be FE*4000 = 3F8000..3FBFFF linear addresses Nonpaged C000..ffff could be FF*4000 = 3FC000..3FFFFF linear addresses And both Freescale and P&E won't understand both nonpaged and linear addresses, until you convert them to global: Whole 512K X device flash memory: E0*4000+400000 = 780000 to FF*4000+3FFF+400000 = 7FFFFF global addresses. Nonpaged 4000..7fff could be FD*4000+400000 = 7F4000..7F7FFF global addresses Nonpaged 8000..bfff could be FE*4000+400000 = 7F8000..7FBFFF global addresses Nonpaged C000..ffff could be FF*4000+400000 = 7FC000..7FFFFF global addresses > > **** > Then we have to convert 0x4000.0x7FFF / 0xC000.0xFFFF to the right > physical page, which should be relatively easy once the correct physical > address range is used. The linker already supports S12 vs. S12X conversion > so I think we are mostly there. Nonbanked 4000..ffff is what makes sreccvt not working. This is primary, not secondary :-). Best Regards Edward > > Anything else I miss? Any advices on what actual addresses to use will be > appreciated. Thanks. > > > > > // richard blog: > > // mailing list: http://www.dragonsgate.net/mailman/listinfo > // photo book: http://www.blurb.com/bookstore/detail/745963 > [ 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 richard-lists at imagecraft.com Thu Jul 9 00:19:21 2009 From: richard-lists at imagecraft.com (Richard Man) Date: Thu Jul 9 01:30:21 2009 Subject: [Icc-mot] CPUS12: logical to physical In-Reply-To: <0017C2AEE5C44916B865F9F77EC86730@REKS> References: <200907090500.n6950EPR036174@mail.imagecraft.com> <0017C2AEE5C44916B865F9F77EC86730@REKS> Message-ID: <200907090830.n698UKX9042296@mail.imagecraft.com> At 09:49 PM 7/8/2009, Edward Karpicz wrote: >Richard, > > > >>I am considering adding the similar functionality of P&E's log2phy >>into the ICC12 so the utility won't be necessary. For the HCS12 >>devices, currently I am using the logical addresses >> >>64K devices: 0xF0000.0xFFFFF >>128K devices: 0xE0000.0xFFFFF >>256K devices: 0xC0000.0xFFFFF >>512K devices: 0x80000.0xFFFFF > >These ^^ "logical" addresses are physical. By physical Freescale >and/or P&E mean internal hidden contiguous S12 flash address space. >ICC12 linear addresses is what tools like P&E Prog12z understand. So >please notice next few lines are not valid for S12: > > >wrong:> If I understand this correctly, if I replace them with the physical >wrong: > addresses, e.g. >wrong:> 64K: 0x3F0000.0x3FFFFF >wrong:> 128K: 0x3E0000.0x3FFFFF >wrong:> 256K: 0x3C0000.0x3FFFFF >wrong:> 512K: 0x380000.0x3FFFFF > >ICC12 linear addresses are fine for S12 and both Freescale factory >programming and P&E software understands them. The only problem is >they won't understand S1 records and all three CPU logical areas >(CPU logical is FSL term, nonpaged in our understanding): >4000..7fff, 8000..bfff, c000..ffff have to be converted into >corresponding linear/physical addresses. 4000..7fff to page 3E >physical/linear addresses, 3E*4000 = F8000..FBFFF addresses. >c000..ffff to page 3F - 3F*4000 = FC000..FFFFF. And nonpaged >8000..BFFF, depending on S12 device memory size, has to be converted >to least available ppage number. > >on 32K devices, 8000..BFFF should be converted to 3E*4000 = F8000..FBFFF >on 64K devices, 8000..BFFF should be converted to 3C*4000 = F0000..F3FFF >on 128K devices, 8000..BFFF should be converted to 38*4000 = E0000..E3FFF >on 256K devices , 8000..BFFF should be converted to 30*4000 = C0000..C3FFF Thanks Ed, just to reiterate (I am just repeating what youe wrote, hopefully correctly) because the S12/S12X addressing is invented by aliens (they may be genius, but they are still aliens, and heck you can quote me on that): OK, so for the S12 chips, I will leave the memory ranges as they are currently, and then add some facility to map the 0x4000.0x7FFF -> F8000.FBFFF 0xC000.0xFFFF -> FC000.FFFFF and the 0x8000.0xBFFF to the map you wrote above. Got it. > > > > For the S12X, currently we have (or will have, as I just > updated the XDx512): > > > > 128K S12X: 0x3E0000.0x3FFFFF > > 256K S12X: 0x380000.0x39FFFF:0x3E0000.0x3FFFFF > > 512K S12X: 0x788000.0x7FFFFF > >No. First of all X devices should be converted the same way, despite >of available memory, because nonpaged 8000..bfff defaults to page FE >on all X devices. And 4000.7fff is fixed page FD, and c0000.ffff is >fixed page FF. On S12 you have to convert different parts >differently, because reset maps least available memory page to page >window; which on S12X was made standartized, despite of available >flash size, reset maps page FE to page window. >Secondly, standard for S12X records are S records with global >addresses. Global is linear address + 0x400000. Linear address is >page number*0x4000. Add to product 0x400000 and you get global >address. For example 512K parts have page number min E0 and max FF. >That corresponds to > >Whole 512K X device flash memory is E0*4000 = 380000 to FF*4000+3FFF >= 3FFFFF linear addresses. >Nonpaged 4000..7fff could be FD*4000 = 3F4000..3F7FFF linear addresses >Nonpaged 8000..bfff could be FE*4000 = 3F8000..3FBFFF linear addresses >Nonpaged C000..ffff could be FF*4000 = 3FC000..3FFFFF linear addresses OK, now I am getting a headache AGAIN. Every time I think I have an inkling of this S12/S12X memory addressing, I get confused again.... But my thinking is that to help to make the process easier (I hope), for the S12X, I would go ahead and use the global addresses for the "expanded memory" in the IDE and linker specifications, because frankly the compiler tools don't care. So if we use global addresses, it would be 128K: 0x7E0000.0x7FFFFF 256K: 0x7C0000.0x7FFFFF 512K: 0x780000.0x7FFFFF Is this correct? And then if we leave space for the XGate page, it would be 128K: 0x7E8000.0x7FFFFF 256K: 0x7C8000.0x7FFFFF 512K: 0x788000.0x7FFFFF Then the linker would only have to convert the nonpaged 0x4000.0xFFFF area, and the expanded address would already be in the correct format. Is that correct? And the conversion to the unpaged areas are the same for all S12X, as below. Is that correct? *headache* *headache* >And both Freescale and P&E won't understand both nonpaged and linear >addresses, until you convert them to global: > >Whole 512K X device flash memory: E0*4000+400000 = 780000 to >FF*4000+3FFF+400000 = 7FFFFF global addresses. >Nonpaged 4000..7fff could be FD*4000+400000 = 7F4000..7F7FFF global addresses >Nonpaged 8000..bfff could be FE*4000+400000 = 7F8000..7FBFFF global addresses >Nonpaged C000..ffff could be FF*4000+400000 = 7FC000..7FFFFF global addresses > > >> >>**** >>Then we have to convert 0x4000.0x7FFF / 0xC000.0xFFFF to the right >>physical page, which should be relatively easy once the correct >>physical address range is used. The linker already supports S12 vs. >>S12X conversion so I think we are mostly there. > >Nonbanked 4000..ffff is what makes sreccvt not working. This is >primary, not secondary :-). > >Best Regards > >Edward > > >> >>Anything else I miss? Any advices on what actual addresses to use >>will be appreciated. Thanks. // richard // photo book: http://www.blurb.com/bookstore/detail/745963 From ekarpicz at freemail.lt Thu Jul 9 01:36:40 2009 From: ekarpicz at freemail.lt (Edward Karpicz) Date: Thu Jul 9 02:46:23 2009 Subject: [Icc-mot] CPUS12: logical to physical References: <200907090500.n6950EPR036174@mail.imagecraft.com><0017C2AEE5C44916B865F9F77EC86730@REKS> <200907090830.n698UKX9042296@mail.imagecraft.com> Message-ID: > At 09:49 PM 7/8/2009, Edward Karpicz wrote: >>Richard, >> >> >> >>>I am considering adding the similar functionality of P&E's log2phy into >>>the ICC12 so the utility won't be necessary. For the HCS12 devices, >>>currently I am using the logical addresses >>> >>>64K devices: 0xF0000.0xFFFFF >>>128K devices: 0xE0000.0xFFFFF >>>256K devices: 0xC0000.0xFFFFF >>>512K devices: 0x80000.0xFFFFF >> >>These ^^ "logical" addresses are physical. By physical Freescale and/or >>P&E mean internal hidden contiguous S12 flash address space. ICC12 linear >>addresses is what tools like P&E Prog12z understand. So please notice next >>few lines are not valid for S12: >> >> >>wrong:> If I understand this correctly, if I replace them with the >>physical >>wrong: > addresses, e.g. >>wrong:> 64K: 0x3F0000.0x3FFFFF >>wrong:> 128K: 0x3E0000.0x3FFFFF >>wrong:> 256K: 0x3C0000.0x3FFFFF >>wrong:> 512K: 0x380000.0x3FFFFF >> >>ICC12 linear addresses are fine for S12 and both Freescale factory >>programming and P&E software understands them. The only problem is they >>won't understand S1 records and all three CPU logical areas (CPU logical >>is FSL term, nonpaged in our understanding): 4000..7fff, 8000..bfff, >>c000..ffff have to be converted into corresponding linear/physical >>addresses. 4000..7fff to page 3E physical/linear addresses, 3E*4000 = >>F8000..FBFFF addresses. c000..ffff to page 3F - 3F*4000 = FC000..FFFFF. >>And nonpaged 8000..BFFF, depending on S12 device memory size, has to be >>converted to least available ppage number. >> >>on 32K devices, 8000..BFFF should be converted to 3E*4000 = F8000..FBFFF >>on 64K devices, 8000..BFFF should be converted to 3C*4000 = F0000..F3FFF >>on 128K devices, 8000..BFFF should be converted to 38*4000 = E0000..E3FFF >>on 256K devices , 8000..BFFF should be converted to 30*4000 = >>C0000..C3FFF > > Thanks Ed, just to reiterate (I am just repeating what youe wrote, > hopefully correctly) because the S12/S12X addressing is invented by aliens > (they may be genius, but they are still aliens, and heck you can quote me > on that): Aliens residence is at P&E :-). Because their burners don't understand nonpaged 4000.ffff, and it must be P&E who invented all those restrictions and various linear vs physical vs logical differences. And Freescale are also aliens, I agree. > > OK, so for the S12 chips, I will leave the memory ranges as they are > currently, and then add some facility to map the > 0x4000.0x7FFF -> F8000.FBFFF > 0xC000.0xFFFF -> FC000.FFFFF > > and the 0x8000.0xBFFF to the map you wrote above. > > Got it. > Yes, you got it. Please don't forget that 8000.BFFF has to be converted differently for 32, 64, 128, 256 and 512K S12 devices, all it depends on the flash size and least available flash page number. >> > >> > For the S12X, currently we have (or will have, as I just updated the >> XDx512): >> > >> > 128K S12X: 0x3E0000.0x3FFFFF >> > 256K S12X: 0x380000.0x39FFFF:0x3E0000.0x3FFFFF >> > 512K S12X: 0x788000.0x7FFFFF >> >>No. First of all X devices should be converted the same way, despite of >>available memory, because nonpaged 8000..bfff defaults to page FE on all X >>devices. And 4000.7fff is fixed page FD, and c0000.ffff is fixed page FF. >>On S12 you have to convert different parts differently, because reset maps >>least available memory page to page window; which on S12X was made >>standartized, despite of available flash size, reset maps page FE to page >>window. >>Secondly, standard for S12X records are S records with global addresses. >>Global is linear address + 0x400000. Linear address is page number*0x4000. >>Add to product 0x400000 and you get global address. For example 512K parts >>have page number min E0 and max FF. That corresponds to >> >>Whole 512K X device flash memory is E0*4000 = 380000 to FF*4000+3FFF = >>3FFFFF linear addresses. >>Nonpaged 4000..7fff could be FD*4000 = 3F4000..3F7FFF linear addresses >>Nonpaged 8000..bfff could be FE*4000 = 3F8000..3FBFFF linear addresses >>Nonpaged C000..ffff could be FF*4000 = 3FC000..3FFFFF linear addresses > > OK, now I am getting a headache AGAIN. Every time I think I have an > inkling of this S12/S12X memory addressing, I get confused again.... > > But my thinking is that to help to make the process easier (I hope), for > the S12X, I would go ahead and use the global addresses for the "expanded > memory" in the IDE and linker specifications, because frankly the compiler > tools don't care. So if we use global addresses, it would be > > 128K: 0x7E0000.0x7FFFFF > 256K: 0x7C0000.0x7FFFFF > 512K: 0x780000.0x7FFFFF > > Is this correct? And then if we leave space for the XGate page, it would > be > Correct for 512K S12X device, but not at all correct for 256K device. 512K has contiguous flash pages E0 to FF. 256K device has flash pages E0 to E7 and then F8 to FF; two 128K flash blocks. Memory hole is introduced to not change XGATE mapping and still allow XGATE to run from flash (pages 0xE0 and 0xE1). So 256K S12X setting should be like this: 256K: 0x780000.0x79FFFF:0x7E0000.0x7FFFFF 384K: 0x780000.0x79FFFF:0x7C0000.0x7FFFFF 128K: 0x7E0000.0x7FFFFF only, XGATE can't run from flash 64K: 0x7F0000.0x7FFFFF only, XGATE can't run from flash > And then if we leave space for the XGate page, it would be > 512K: 0x788000.0x7FFFFF Correct for 512K part, but XGATE can't access lower 2k of flash, because that space in XGATE memory map is occupied by 2k registers block. So reserving max possible 30k of flash to XGATE only, and excluding that from whole 512K global flash memory range: 512K: 0x780000.0x780800 : 0x788000.0x7FFFFF > Then the linker would only have to convert the nonpaged 0x4000.0xFFFF > area, and the expanded address would already be in the correct format. Is > that correct? Yes. > And the conversion to the unpaged areas are the same for all S12X, as > below. Is that correct? Yes. Conversion of unpaged S12X areas is the same for all 64..1024K S12X devices. Richard, why I talked about notstandard linear S12X records, and not immediately about standard global S12X records is because I think that from the very beginning ICC12 linker used this formula to convert from Extended Memory setting to ppage and ofset: L = ppage * psize + ofset where L is Extended Memory address IDE setting, or linear address, ppage is PPAGE, and psize is ppage window size. I don't know details of ICC12 linker operations, but I guess that at some relocation stage, to get PPAGE of target function, linker uses this formula PPAGE = L / psize to get offset offset = (L % psize) + 0x8000, where 0x8000 is lower address of ppage window Now, with global addresses it is bit different. L = ppage * psize + ofset + 0x400000 PPAGE = (L - 0x400000) / psize And offset like before offset = (L % psize) + 0x8000 You may notice that for all S12X derivatives, old PPAGE formula PPAGE = L / psize will overflow. I mean PPAGE is always >=0x100. Since PPAGE is 8bits only, probably no problem keeping using old formula, but I'm not sure. I think I once got not working code, when I compiled my code with global 0x780000 instead of linear 0x380000 in Ext.Mem settings. I didn't investigate it further, not sure if it really wasn't working due PPAGE overflow... Please make sure that PPAGE overflow won't break anything. > *headache* *headache* sorry :-) Best Regards Edward > >>And both Freescale and P&E won't understand both nonpaged and linear >>addresses, until you convert them to global: >> >>Whole 512K X device flash memory: E0*4000+400000 = 780000 to >>FF*4000+3FFF+400000 = 7FFFFF global addresses. >>Nonpaged 4000..7fff could be FD*4000+400000 = 7F4000..7F7FFF global >>addresses >>Nonpaged 8000..bfff could be FE*4000+400000 = 7F8000..7FBFFF global >>addresses >>Nonpaged C000..ffff could be FF*4000+400000 = 7FC000..7FFFFF global >>addresses >> >> >>> >>>**** >>>Then we have to convert 0x4000.0x7FFF / 0xC000.0xFFFF to the right >>>physical page, which should be relatively easy once the correct physical >>>address range is used. The linker already supports S12 vs. S12X >>>conversion so I think we are mostly there. >> >>Nonbanked 4000..ffff is what makes sreccvt not working. This is primary, >>not secondary :-). >> >>Best Regards >> >>Edward >> >> >>> >>>Anything else I miss? Any advices on what actual addresses to use will be >>>appreciated. Thanks. > > // richard > > // photo book: http://www.blurb.com/bookstore/detail/745963 > _______________________________________________ > Icc-mot mailing list > Icc-mot@imagecraft.com > http://dragonsgate.net/mailman/listinfo/icc-mot > From StvRussell at aol.com Thu Jul 9 13:00:53 2009 From: StvRussell at aol.com (StvRussell@aol.com) Date: Thu Jul 9 14:10:52 2009 Subject: [Icc-mot] More Notes on S12(X) Addressing. Message-ID: S12X Global Addressing ----------------------------------- The colored addressing diagrams in the S12XEP100 "Datasheet" (all 1300+ pages of it) are the best aid I've seen for help in understanding S12X global addressing. As there are so many names for the various addressing schemes, your quick start documentation should define the names you are going to use and the names that others have used for each addressing method. A New Version of Global Addressing ---------------------------------------------------- The S12P, a new part featuring the S12 (NOT X) CPU and S12XEP100 type flash, D-flash and CAN has a new version of "global addressing" with the highest address of 3F_FFFF (not 7F_FFFF as for S12X parts). It uses the FPAGE register to do the global addressing. As far as I can tell its register map has little in common with other S12 CPU parts. Unfortunately, the S12P "Datasheet" (a slim 500+ pages) does not explain all this as clearly as the S12XEP100 "Datasheet". Steve Russell (formerly of Nohau) **************Dell Studio XPS Desktop: Save up to $400 - Limited Time Offer (http://pr.atwola.com/promoclk/100126575x1222466512x1201463496/aol?redir=htt p:%2F%2Faltfarm.mediaplex.com%2Fad%2Fck%2F12309%2D81939%2D1629%2D3) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-mot/attachments/20090709/1b4f6b52/attachment.html From richard-lists at imagecraft.com Thu Jul 9 13:21:45 2009 From: richard-lists at imagecraft.com (Richard Man) Date: Thu Jul 9 14:32:48 2009 Subject: [Icc-mot] More Notes on S12(X) Addressing. In-Reply-To: References: Message-ID: <200907092132.n69LWlZq062676@mail.imagecraft.com> An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-mot/attachments/20090709/1275843e/attachment.html From ekarpicz at freemail.lt Thu Jul 9 13:58:13 2009 From: ekarpicz at freemail.lt (Edward Karpicz) Date: Thu Jul 9 15:07:59 2009 Subject: [Icc-mot] More Notes on S12(X) Addressing. References: Message-ID: <588E3A058DD343C6B8CE95BC1384A226@REKS> Regarding S12P. Yeah, I forgot about this one. No idea why they made it not similar to other S12 and S12X, except that maybe they tried to add S12 to "MCU continuum"? Paged S08QE also has PPAGEs from 0 growing up. Two corrections, Steve to what you said. S12P global memory is from 0_0000 to 3_FFFF, not up to 3F_FFFF. Also S12P still uses PPAGE register for flash paging and I see no mention in datasheet about FPAGE. S12P CPU seems to not have global addressing instructions, so specified global memory map seems to only define standard S-records file addresses for P-flash, D-flash etc. S12P header file is all what's required to work with them using ICC12. Edward ----- Original Message ----- From: StvRussell@aol.com To: icc-mot@imagecraft.com Sent: Thursday, July 09, 2009 11:00 PM Subject: [Icc-mot] More Notes on S12(X) Addressing. S12X Global Addressing ----------------------------------- The colored addressing diagrams in the S12XEP100 "Datasheet" (all 1300+ pages of it) are the best aid I've seen for help in understanding S12X global addressing. As there are so many names for the various addressing schemes, your quick start documentation should define the names you are going to use and the names that others have used for each addressing method. A New Version of Global Addressing ---------------------------------------------------- The S12P, a new part featuring the S12 (NOT X) CPU and S12XEP100 type flash, D-flash and CAN has a new version of "global addressing" with the highest address of 3F_FFFF (not 7F_FFFF as for S12X parts). It uses the FPAGE register to do the global addressing. As far as I can tell its register map has little in common with other S12 CPU parts. Unfortunately, the S12P "Datasheet" (a slim 500+ pages) does not explain all this as clearly as the S12XEP100 "Datasheet". Steve Russell (formerly of Nohau) ------------------------------------------------------------------------------ Dell Studio XPS Desktop: Save up to $400 - Limited Time Offer ------------------------------------------------------------------------------ _______________________________________________ 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/20090709/813322e6/attachment.html From ekarpicz at freemail.lt Thu Jul 9 14:04:18 2009 From: ekarpicz at freemail.lt (Edward Karpicz) Date: Thu Jul 9 15:14:00 2009 Subject: [Icc-mot] More Notes on S12(X) Addressing. References: <200907092132.n69LWlZq062676@mail.imagecraft.com> Message-ID: <3FF996053DA54846A88CCB4772CF1E8F@REKS> Richard, I'm not educating (teaching) you, I'm just trying to answer your questions in as short form as my English allows me. And it always turns into long blablabla :-). Edward ----- Original Message ----- From: Richard Man To: icc-mot@imagecraft.com Sent: Thursday, July 09, 2009 11:21 PM Subject: Re: [Icc-mot] More Notes on S12(X) Addressing. Hi Steve, Thanks for the heads-up. Ed and I have been discussing off-list (more like Ed has been educating me on this subject). I think I am getting a handle on this. Fundamentally, we want to get away from having some customers to use SRecCVT and Log2Phy when they use some 3rd party tools, and I think it comes down to: - The S2 record addresses should be the one "native" to the particular device - The lower 64K S1 addresses should be mapped to S2 records with addresses natice to the particular device. That plus a few things should render SRecCVT/Log2Phy unnecessary. The changes to the compiler toolchain should actually be relatively small. We just need to understand this subject more thoroughly. The S12P addressing below no longer looks that scary, under this view. Full proposal later. Didn't I tell you around 2001 when we first added expanded memory support that the paging scheme is... "baroque?" At 01:00 PM 7/9/2009, StvRussell@aol.com wrote: S12X Global Addressing ----------------------------------- The colored addressing diagrams in the S12XEP100 "Datasheet" (all 1300+ pages of it) are the best aid I've seen for help in understanding S12X global addressing. As there are so many names for the various addressing schemes, your quick start documentation should define the names you are going to use and the names that others have used for each addressing method. A New Version of Global Addressing ---------------------------------------------------- The S12P, a new part featuring the S12 (NOT X) CPU and S12XEP100 type flash, D-flash and CAN has a new version of "global addressing" with the highest address of 3F_FFFF (not 7F_FFFF as for S12X parts). It uses the FPAGE register to do the global addressing. As far as I can tell its register map has little in common with other S12 CPU parts. Unfortunately, the S12P "Datasheet" (a slim 500+ pages) does not explain all this as clearly as the S12XEP100 "Datasheet". Steve Russell (formerly of Nohau) ---------------------------------------------------------------------------- Dell Studio XPS Desktop: Save up to $400 - Limited Time Offer _______________________________________________ Icc-mot mailing list Icc-mot@imagecraft.com http://dragonsgate.net/mailman/listinfo/icc-mot // richard < http://www.imagecraft.com> < http://www.dragonsgate.net/mailman/listinfo> // photo book: http://www.blurb.com/bookstore/detail/745963 ------------------------------------------------------------------------------ _______________________________________________ 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/20090710/eda6f3f2/attachment.html From barryc at rjlsystems.com Thu Jul 9 14:52:24 2009 From: barryc at rjlsystems.com (Barry Callahan) Date: Thu Jul 9 16:03:50 2009 Subject: [Icc-mot] More Notes on S12(X) Addressing. In-Reply-To: <3FF996053DA54846A88CCB4772CF1E8F@REKS> References: <200907092132.n69LWlZq062676@mail.imagecraft.com> <3FF996053DA54846A88CCB4772CF1E8F@REKS> Message-ID: <4A566698.70007@rjlsystems.com> Technically speaking, if he's doing the "learning" and you're doing the "explaining", that means you are, in fact, "educating" him. Yay, semantics! :-D Edward Karpicz wrote: > Richard, I'm not educating (teaching) you, I'm just trying to answer > your questions in as short form as my English allows me. And it always > turns into long blablabla :-). > > Edward From dean.bell at flightec.com Thu Jul 9 15:22:29 2009 From: dean.bell at flightec.com (Dean Bell) Date: Thu Jul 9 16:32:10 2009 Subject: [Icc-mot] ICC12 compiler version .map file Message-ID: Hi Richard I was looking at Albert van Veen (AVR) post about version ID in the .map file. If you are working on the ICC12 compiler it would be very handy to have a tattoo of the compiler version and the compile date/time at the top of the map file, along with the project name. Dean. From richard-lists at imagecraft.com Thu Jul 9 15:40:24 2009 From: richard-lists at imagecraft.com (Richard Man) Date: Thu Jul 9 16:51:27 2009 Subject: [Icc-mot] ICC12 compiler version .map file In-Reply-To: References: Message-ID: <200907092351.n69NpQOb066720@mail.imagecraft.com> Yes, this can and will probably be added. At 03:22 PM 7/9/2009, Dean Bell wrote: >Hi Richard > >I was looking at Albert van Veen (AVR) post about version ID in the .map >file. >If you are working on the ICC12 compiler it would be very handy to have a >tattoo of the compiler version and the compile date/time at the top of the >map file, along with the project name. > >Dean. // richard // photo book: http://www.blurb.com/bookstore/detail/745963 From richard-lists at imagecraft.com Thu Jul 9 15:40:56 2009 From: richard-lists at imagecraft.com (Richard Man) Date: Thu Jul 9 16:51:59 2009 Subject: [Icc-mot] More Notes on S12(X) Addressing. In-Reply-To: <4A566698.70007@rjlsystems.com> References: <200907092132.n69LWlZq062676@mail.imagecraft.com> <3FF996053DA54846A88CCB4772CF1E8F@REKS> <4A566698.70007@rjlsystems.com> Message-ID: <200907092351.n69NpvPO066756@mail.imagecraft.com> :-) Exactly! At 02:52 PM 7/9/2009, you wrote: >Technically speaking, if he's doing the "learning" and you're doing >the "explaining", that means you are, in fact, "educating" him. > >Yay, semantics! :-D > >Edward Karpicz wrote: >>Richard, I'm not educating (teaching) you, I'm just trying to >>answer your questions in as short form as my English allows me. And >>it always turns into long blablabla :-). >> >>Edward > >// richard > >// photo book: http://www.blurb.com/bookstore/detail/745963 From StvRussell at aol.com Thu Jul 9 15:43:55 2009 From: StvRussell at aol.com (StvRussell@aol.com) Date: Thu Jul 9 16:53:07 2009 Subject: [Icc-mot] The Aliens Don't Deserve All the Blame Message-ID: To defend the aliens who have evolved the HC12 addressing, they are continuing the evolution of a 1974 processor (the Motorola 6800) with 8 bit accumulators and a 16 bit address range to a single chip that runs at 80 times the speed with a megabyte of program memory and peripherals not imagined in 1974. In 35 years of evolution a few warts have appeared. Steve **************Dell Studio XPS Desktop: Save up to $400 - Limited Time Offer (http://pr.atwola.com/promoclk/100126575x1222466512x1201463496/aol?redir=htt p:%2F%2Faltfarm.mediaplex.com%2Fad%2Fck%2F12309%2D81939%2D1629%2D3) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-mot/attachments/20090709/c0b04b58/attachment.html From richard-lists at imagecraft.com Thu Jul 9 16:09:29 2009 From: richard-lists at imagecraft.com (Richard Man) Date: Thu Jul 9 17:20:33 2009 Subject: [Icc-mot] The Aliens Don't Deserve All the Blame In-Reply-To: References: Message-ID: <200907100020.n6A0KWdC068192@mail.imagecraft.com> An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-mot/attachments/20090709/b6f32874/attachment.html From ekarpicz at freemail.lt Thu Jul 9 23:34:06 2009 From: ekarpicz at freemail.lt (Edward Karpicz) Date: Fri Jul 10 00:43:48 2009 Subject: [Icc-mot] More Notes on S12(X) Addressing. References: <200907092132.n69LWlZq062676@mail.imagecraft.com><3FF996053DA54846A88CCB4772CF1E8F@REKS><4A566698.70007@rjlsystems.com> <200907092351.n69NpvPO066756@mail.imagecraft.com> Message-ID: <15B9DC9F3FDC4014A567AE4E55F9CABD@edvardo> OK :-) Edward > :-) Exactly! > > At 02:52 PM 7/9/2009, you wrote: >>Technically speaking, if he's doing the "learning" and you're doing >>the "explaining", that means you are, in fact, "educating" him. >> >>Yay, semantics! :-D >> >>Edward Karpicz wrote: >>>Richard, I'm not educating (teaching) you, I'm just trying to >>>answer your questions in as short form as my English allows me. And >>>it always turns into long blablabla :-). >>> >>>Edward >> >>// richard >> >>// photo book: http://www.blurb.com/bookstore/detail/745963 > > _______________________________________________ > Icc-mot mailing list > Icc-mot@imagecraft.com > http://dragonsgate.net/mailman/listinfo/icc-mot > From richard-lists at imagecraft.com Thu Jul 9 23:59:06 2009 From: richard-lists at imagecraft.com (Richard Man) Date: Fri Jul 10 01:10:17 2009 Subject: [Icc-mot] Proposed changes to ICC12 for expanded memory support Message-ID: <200907100810.n6A8ACjX079297@mail.imagecraft.com> An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-mot/attachments/20090709/7220af50/attachment.html From ekarpicz at freemail.lt Fri Jul 10 02:53:06 2009 From: ekarpicz at freemail.lt (Edward Karpicz) Date: Fri Jul 10 04:02:52 2009 Subject: [Icc-mot] The Aliens Don't Deserve All the Blame References: <200907100020.n6A0KWdC068192@mail.imagecraft.com> Message-ID: <4351B3B2C7F9495EA64BDCFBD3A1C9EC@edvardo> Can I add here more examples? Questions "why my flash programming routine hangs" have appeared zilions of times on 68hc12 list, also on "new and expected to be 1000x times better" Freescale forums. Did they explain that clearly in datasheets? Did they explain that not only flash erase/program, but also all other flash commands like signature check, backdoor unsecure, blank check all disconnect flash memory from the data bus? Questions about timer, and not only timer flags, have been asked zilions of times. But still CW promotes usage of bitfields, which just can't work properly with flags. No matter do you set timer flag bit or do you clear it, bitfields RW usage with flags will lead to clearing not what one may expect. Is it explained in datasheets? Are there valid code (both C and asm) examples? Is it said clearly why one shouldn't use bitfields to clear timer flags? Bootloaders are quite standard feature nearly in all real life applications. Look at available application notes first, then try to suggest to newbe AN, that could explain clearly why and how bootloaders code should be write protected, why bootloader shouldn't be paged, why bootloader should be a separate application and not compiled in the same process with the rest of application; where application vectors should be placed and how it all should be done, if not with all third party tools, then at least with CW. I could continue. I have no personal complains to Freescale, they are doing great chips and I'm happy with them. But aren't Freescale trying to suicide or kill their great products? Newbies and new customers often seem to be not welcome. Like with Srecords formatting. Ones like me have no problems converting Srecs to proper format. But try to explain what to remap to where to someone new, it must sound silly... Edward ----- Original Message ----- From: Richard Man To: icc-mot@imagecraft.com ; icc-mot@imagecraft.com Sent: Friday, July 10, 2009 02:09 Subject: Re: [Icc-mot] The Aliens Don't Deserve All the Blame // rant ON No offense to those fine engineers, but they a) introduced CPU banked vs. linear address when HC12 first appeared. They should have propose a single standard to use, and stick with it. As it was, 3rd party tools was all over the place. b) when HCS12 with internal flash appeared, they started to expose the internal flash addressing, blowing doors to the linear address. There is no excuse for not defining the terms well and ask 3rd party to use one. I am sure their rationale is that they want to give the 3rd party tool makers "choices" and freedom, which translates to chaos and confusion. c) When the S12X comes out... look global addressing!!! It's just like internal flash addresses!! Um, this is a case why ENGINEERS should not define external interface. Motorola was a great company, the S12/X are quite advanced for its time and for what they do, but there is a reason why they lost the microcontroller #1 spot... Sigh. // rant OFF At 03:43 PM 7/9/2009, StvRussell@aol.com wrote: To defend the aliens who have evolved the HC12 addressing, they are continuing the evolution of a 1974 processor (the Motorola 6800) with 8 bit accumulators and a 16 bit address range to a single chip that runs at 80 times the speed with a megabyte of program memory and peripherals not imagined in 1974. In 35 years of evolution a few warts have appeared. Steve // richard < http://www.imagecraft.com> < http://www.dragonsgate.net/mailman/listinfo> // photo book: http://www.blurb.com/bookstore/detail/745963 ------------------------------------------------------------------------------ _______________________________________________ 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/20090710/5325b956/attachment.html From genenorris at spotengineering.com Mon Jul 13 07:47:47 2009 From: genenorris at spotengineering.com (Gene Norris) Date: Mon Jul 13 08:57:38 2009 Subject: [Icc-mot] Interesting Optimizations In-Reply-To: <200804070828.m378S11L069215@mail.imagecraft.com> References: <47F64175.4020603@spotengineering.com> <000601c89672$d78b06f0$a300a8c0@REKS> <47F6635C.4060700@spotengineering.com> <02de01c8967c$c41b8c70$a300a8c0@REKS> <200804070828.m378S11L069215@mail.imagecraft.com> Message-ID: <4A5B4913.8020508@spotengineering.com> Richard, Do you remember this? Could you address this while you are back on the HC12? Richard Man wrote: > I will fix it... > > At 10:53 AM 4/4/2008, Edward Karpicz wrote: >> Gene, >> >>> Yes, I didn't want to muddy the waters though. >> >> >> Acctually I muddied waters, sorry. You are rigth, you found the bug. >> Richard, please fix it. Reconstructing minimal code: >> >> >> void main(void) >> { >> short i, j; >> >> i = (i << 8) + 1; >> j = (j << 8) | 2; >> } >> >> listing: >> >> .area text >> ; j -> 0,SP >> ; i -> 2,SP >> 0000 _main:: >> 0000 1B9C leas -4,S >> 0002 ; void main(void) >> 0002 ; { >> 0002 ; short i, j; >> 0002 ; >> 0002 ; i = (i << 8) + 1; >> 0002 A682 ldaa 2,S <<<#### - should be ldaa 2+1,S >> 0004 C601 ldab #1 >> 0006 B746 tfr D,Y >> 0008 6D82 sty 2,S >> 000A ; j = (j << 8) | 2; >> 000A A680 ldaa 0,S <<<#### - should be ldaa 0+1,S >> 000C C602 ldab #2 >> 000E B746 tfr D,Y >> 0010 6C80 std 0,S >> 0012 L1: >> 0012 .dbline 0 ; func end >> 0012 1B84 leas 4,S >> 0014 3D rts >> >> Edward >> _______________________________________________ >> Icc-mot mailing list >> Icc-mot@imagecraft.com >> http://dragonsgate.net/mailman/listinfo/icc-mot > > // 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 Mon Jul 13 12:20:59 2009 From: richard-lists at imagecraft.com (Richard Man) Date: Mon Jul 13 13:32:27 2009 Subject: [Icc-mot] Interesting Optimizations In-Reply-To: <4A5B4913.8020508@spotengineering.com> References: <47F64175.4020603@spotengineering.com> <000601c89672$d78b06f0$a300a8c0@REKS> <47F6635C.4060700@spotengineering.com> <02de01c8967c$c41b8c70$a300a8c0@REKS> <200804070828.m378S11L069215@mail.imagecraft.com> <4A5B4913.8020508@spotengineering.com> Message-ID: <200907132032.n6DKWQlw005726@mail.imagecraft.com> Yes, I just found this last night too and plan to fix it. Thanks. At 07:47 AM 7/13/2009, you wrote: >Richard, > >Do you remember this? Could you address this while you are back on the HC12? > >Richard Man wrote: >>I will fix it... >>At 10:53 AM 4/4/2008, Edward Karpicz wrote: >>>Gene, >>> >>>>Yes, I didn't want to muddy the waters though. >>> >>> >>>Acctually I muddied waters, sorry. You are rigth, you found the >>>bug. Richard, please fix it. Reconstructing minimal code: >>> >>> >>>void main(void) >>>{ >>>short i, j; >>> >>> i = (i << 8) + 1; >>> j = (j << 8) | 2; >>>} >>> >>>listing: >>> >>> .area text >>> ; j -> 0,SP >>> ; i -> 2,SP >>>0000 _main:: >>>0000 1B9C leas -4,S >>>0002 ; void main(void) >>>0002 ; { >>>0002 ; short i, j; >>>0002 ; >>>0002 ; i = (i << 8) + 1; >>>0002 A682 ldaa 2,S <<<#### - should be ldaa 2+1,S >>>0004 C601 ldab #1 >>>0006 B746 tfr D,Y >>>0008 6D82 sty 2,S >>>000A ; j = (j << 8) | 2; >>>000A A680 ldaa 0,S <<<#### - should be ldaa 0+1,S >>>000C C602 ldab #2 >>>000E B746 tfr D,Y >>>0010 6C80 std 0,S >>>0012 L1: >>>0012 .dbline 0 ; func end >>>0012 1B84 leas 4,S >>>0014 3D rts >>> >>>Edward // richard // photo book: http://www.blurb.com/bookstore/detail/745963 From richard at imagecraft.com Tue Jul 14 13:17:48 2009 From: richard at imagecraft.com (Richard Man) Date: Tue Jul 14 14:28:23 2009 Subject: [Icc-mot] OT: My Book Signing this Friday, July 17th Message-ID: <200907142128.n6ELSM4R046970@mail.imagecraft.com> Sorry for spamming, but I know some of you work in the Bay Area: **** I was in the Stanford's Continuing Education class Self Publishing Your Photo Book this past Spring, and now the fruits of our labor are ready to be unleashed into the world :-) The course was taught by Brigitte Carnochan and there are about 20 people in the class. For a few people, they had the book practically all planned at the start of the class. For others, it took a bit more work. For me personally, at the 3rd session when we were presenting our materials to our peers and when we should already have most of the images nailed down, I was looking at just a dozen images that I didn't know what to do with. One of co-instructors said to me, "Richard, I feel like you are holding out on me, these are (good) images but they are not cohesive to tell a story." It was definitely a "uh oh, what do I do now" moment. And so it goes. I learned a lot about pacing, editing, and presentation. My book combines my love for photography and calligraphy, and the theme of Asian Spiritual worship in its core. You can get a 15 page preview of my book Full Circle here: http://www.blurb.com/bookstore/detail/745963 A special edition of 10 copies is available for $100, each comes with an archival print and a hand written calligraphy of "Full Circle." I hope you can join us this Friday from 7-10PM at the Modern Book Gallery, 494 University Ave., Palo Alto, CA. http://www.modernbook.com. You may purchase the books at that time. // richard w: http://www.rfman.com blog: http://rfman.wordpress.com book: http://www.blurb.com/bookstore/detail/745963 From engineering at data-acquisition.com.au Tue Jul 14 23:35:10 2009 From: engineering at data-acquisition.com.au (Data Acquisition) Date: Wed Jul 15 00:45:05 2009 Subject: [Icc-mot] Diagramming Message-ID: <8A6D9A6D6D9F4B69B05E33629B5D1642@ENG5> Hi all designers, I have a question totally unrelated to this list. What diagramming tool do you use? I'm looking for a decent program to draw engineering diagrams. I'm not looking to pay too much as it's not something that I would use regularly but I need something better than M$ Word boxes and arrows. I've looked at visio but its probably a bit expensive for the number of times I would use it. I would require that the program handle object linking & embedding (OLE) for support with programs such as M$ Word. Would like to have such features as group/ungroup for creating complex objects. I personally would be happy with xfig if it supported OLE or even windows! What would you guys suggest? Regards, James Brown -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-mot/attachments/20090715/24932c60/attachment.html From j_baraclough at zetnet.co.uk Wed Jul 15 02:41:57 2009 From: j_baraclough at zetnet.co.uk (John Baraclough) Date: Wed Jul 15 03:51:46 2009 Subject: [Icc-mot] Diagramming In-Reply-To: <8A6D9A6D6D9F4B69B05E33629B5D1642@ENG5> References: <8A6D9A6D6D9F4B69B05E33629B5D1642@ENG5> Message-ID: <4A5DA465.5080902@zetnet.co.uk> Hi James, Have you looked at the Draw tool in Open Office? It's free (very big download!) or you can buy the CD. You can find it here: http://www.openoffice.org/ If you want a schematic drawing/PCB layout tool there are a raft of free ones, but I would recommend EasyPC. It's reasonably cheap and support is excellent. http://www.numberone.com/ All the best for now, John Data Acquisition wrote: > > Hi all designers, > > I have a question totally unrelated to this list. What diagramming > tool do you use? > > I?m looking for a decent program to draw engineering diagrams. I?m not > looking to pay too much as it?s not something that I would use > regularly but I need something better than M$ Word boxes and arrows. > I?ve looked at visio but its probably a bit expensive for the number > of times I would use it. > > I would require that the program handle object linking & embedding > (OLE) for support with programs such as M$ Word. Would like to have > such features as group/ungroup for creating complex objects. > > I personally would be happy with xfig if it supported OLE or even windows! > > What would you guys suggest? > > Regards, James Brown > > ------------------------------------------------------------------------ > > _______________________________________________ > Icc-mot mailing list > Icc-mot@imagecraft.com > http://dragonsgate.net/mailman/listinfo/icc-mot From barryc at rjlsystems.com Wed Jul 15 11:29:14 2009 From: barryc at rjlsystems.com (Barry Callahan) Date: Wed Jul 15 12:39:11 2009 Subject: [Icc-mot] Diagramming In-Reply-To: <4A5DA465.5080902@zetnet.co.uk> References: <8A6D9A6D6D9F4B69B05E33629B5D1642@ENG5> <4A5DA465.5080902@zetnet.co.uk> Message-ID: <4A5E1FFA.6060902@rjlsystems.com> While we're on the topic of Schematic editors and PCB layout tools: http://www.PCBExpress.com/ and http://www.ExpressPCB.com both have free windows software you can download and install. They give you the software in the hopes that you'll use it (and its proprietary file format) to create your designs and send the files to them for fabrication. Since James mentioned being comfortable with xfig, I would like to point out that xfig runs just fine and dandy under Cygwin on Windows. ( http://www.cygwin.com/ ) They even provide precompiled packages. They do not, however provide precompiled binaries for pcb ( http://pcb.gpleda.org/index.html ) or the gEDA suite ( http://www.gpleda.org/ ) which includes gSchem, their schematic editor. Barry John Baraclough wrote: > Hi James, > > Have you looked at the Draw tool in Open Office? It's free (very big > download!) or you can buy the CD. You can find it here: > > http://www.openoffice.org/ > > If you want a schematic drawing/PCB layout tool there are a raft of > free ones, but I would recommend EasyPC. It's reasonably cheap and > support is excellent. > > http://www.numberone.com/ > > All the best for now, > John > > > Data Acquisition wrote: >> >> Hi all designers, >> >> I have a question totally unrelated to this list. What diagramming >> tool do you use? >> >> I?m looking for a decent program to draw engineering diagrams. I?m >> not looking to pay too much as it?s not something that I would use >> regularly but I need something better than M$ Word boxes and arrows. >> I?ve looked at visio but its probably a bit expensive for the number >> of times I would use it. >> >> I would require that the program handle object linking & embedding >> (OLE) for support with programs such as M$ Word. Would like to have >> such features as group/ungroup for creating complex objects. >> >> I personally would be happy with xfig if it supported OLE or even >> windows! >> >> What would you guys suggest? >> >> Regards, James Brown >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Icc-mot mailing list >> Icc-mot@imagecraft.com >> http://dragonsgate.net/mailman/listinfo/icc-mot > > _______________________________________________ > Icc-mot mailing list > Icc-mot@imagecraft.com > http://dragonsgate.net/mailman/listinfo/icc-mot From richard-lists at imagecraft.com Wed Jul 15 17:49:51 2009 From: richard-lists at imagecraft.com (Richard Man) Date: Wed Jul 15 19:00:29 2009 Subject: [Icc-mot] Re: ICC12 bug In-Reply-To: <4A5B4913.8020508@spotengineering.com> References: <47F64175.4020603@spotengineering.com> <000601c89672$d78b06f0$a300a8c0@REKS> <47F6635C.4060700@spotengineering.com> <02de01c8967c$c41b8c70$a300a8c0@REKS> <200804070828.m378S11L069215@mail.imagecraft.com> <4A5B4913.8020508@spotengineering.com> Message-ID: <200907160200.n6G20R5W092917@mail.imagecraft.com> This has been fixed. It only affects code of the form local_var = (local_var << 8) op con where op is either + or |. http://www.dragonsgate.net/pub/BETAS/iccom12w.exe, put that in your bin directory. I will release this along with the enhanced expanded memory support soon... At 07:47 AM 7/13/2009, Gene Norris wrote: >Richard, > >Do you remember this? Could you address this while you are back on the HC12? > >Richard Man wrote: >>I will fix it... >>At 10:53 AM 4/4/2008, Edward Karpicz wrote: >>>Gene, >>> >>>>Yes, I didn't want to muddy the waters though. >>> >>> >>>Acctually I muddied waters, sorry. You are rigth, you found the >>>bug. Richard, please fix it. Reconstructing minimal code: >>> >>> >>>void main(void) >>>{ >>>short i, j; >>> >>> i = (i << 8) + 1; >>> j = (j << 8) | 2; >>>} // richard // photo book: http://www.blurb.com/bookstore/detail/745963 From ekarpicz at freemail.lt Thu Jul 16 00:37:54 2009 From: ekarpicz at freemail.lt (Edward Karpicz) Date: Thu Jul 16 01:47:47 2009 Subject: [Icc-mot] Re: ICC12 bug References: <47F64175.4020603@spotengineering.com><000601c89672$d78b06f0$a300a8c0@REKS><47F6635C.4060700@spotengineering.com><02de01c8967c$c41b8c70$a300a8c0@REKS><200804070828.m378S11L069215@mail.imagecraft.com><4A5B4913.8020508@spotengineering.com> <200907160200.n6G20R5W092917@mail.imagecraft.com> Message-ID: <938BD2429DF3433FBF97988473FB996C@edvardo> Hm, I see some more improvements in this compiler. 1). More long branches replaced with short branches, when in range. 2) Eliminated redundand ANDx instructions doing short & 0xFFFF , for example Old: ; if(errC & ~WARNINGS) // warnings defined as 0 ldd _errC anda #-1 andb #-1 tfr D,Y cpy #0 New: ; if(errC & ~WARNINGS) ldy _errC cpy #0 ***** ... And more. Wow! Edward ----- Original Message ----- From: "Richard Man" To: Sent: Thursday, July 16, 2009 03:49 Subject: [Icc-mot] Re: ICC12 bug > This has been fixed. It only affects code of the form > > local_var = (local_var << 8) op con > > where op is either + or |. > > http://www.dragonsgate.net/pub/BETAS/iccom12w.exe, put that in your bin > directory. I will release this along with the enhanced expanded memory > support soon... > > > > At 07:47 AM 7/13/2009, Gene Norris wrote: >>Richard, >> >>Do you remember this? Could you address this while you are back on the >>HC12? >> >>Richard Man wrote: >>>I will fix it... >>>At 10:53 AM 4/4/2008, Edward Karpicz wrote: >>>>Gene, >>>> >>>>>Yes, I didn't want to muddy the waters though. >>>> >>>> >>>>Acctually I muddied waters, sorry. You are rigth, you found the bug. >>>>Richard, please fix it. Reconstructing minimal code: >>>> >>>> >>>>void main(void) >>>>{ >>>>short i, j; >>>> >>>> i = (i << 8) + 1; >>>> j = (j << 8) | 2; >>>>} > > // richard > > // photo book: http://www.blurb.com/bookstore/detail/745963 > _______________________________________________ > Icc-mot mailing list > Icc-mot@imagecraft.com > http://dragonsgate.net/mailman/listinfo/icc-mot > From jim at fiocca.net Thu Jul 16 12:09:41 2009 From: jim at fiocca.net (Jim Fiocca) Date: Thu Jul 16 13:17:41 2009 Subject: [Icc-mot] Re: ICC12 bug In-Reply-To: <938BD2429DF3433FBF97988473FB996C@edvardo> References: <47F64175.4020603@spotengineering.com><000601c89672$d78b06f0$a300a8c0@REKS><47F6635C.4060700@spotengineering.com><02de01c8967c$c41b8c70$a300a8c0@REKS><200804070828.m378S11L069215@mail.imagecraft.com><4A5B4913.8020508@spotengineering.com> <200907160200.n6G20R5W092917@mail.imagecraft.com> <938BD2429DF3433FBF97988473FB996C@edvardo> Message-ID: <4A5F7AF5.2060500@fiocca.net> Does the assembler support the new S12X instructions yet, or will that be in a separate release of the assembler? Thanks, Jim Edward Karpicz wrote: > Hm, I see some more improvements in this compiler. > > 1). More long branches replaced with short branches, when in range. > > 2) Eliminated redundand ANDx instructions doing short & 0xFFFF , for > example > > Old: > ; if(errC & ~WARNINGS) // warnings defined as 0 > ldd _errC > anda #-1 > andb #-1 > tfr D,Y > cpy #0 > > New: > ; if(errC & ~WARNINGS) > ldy _errC > cpy #0 > ***** > > ... And more. > Wow! > > Edward > > > ----- Original Message ----- From: "Richard Man" > > To: > Sent: Thursday, July 16, 2009 03:49 > Subject: [Icc-mot] Re: ICC12 bug > > >> This has been fixed. It only affects code of the form >> >> local_var = (local_var << 8) op con >> >> where op is either + or |. >> >> http://www.dragonsgate.net/pub/BETAS/iccom12w.exe, put that in your >> bin directory. I will release this along with the enhanced expanded >> memory support soon... >> >> >> >> At 07:47 AM 7/13/2009, Gene Norris wrote: >>> Richard, >>> >>> Do you remember this? Could you address this while you are back on >>> the HC12? >>> >>> Richard Man wrote: >>>> I will fix it... >>>> At 10:53 AM 4/4/2008, Edward Karpicz wrote: >>>>> Gene, >>>>> >>>>>> Yes, I didn't want to muddy the waters though. >>>>> >>>>> >>>>> Acctually I muddied waters, sorry. You are rigth, you found the >>>>> bug. Richard, please fix it. Reconstructing minimal code: >>>>> >>>>> >>>>> void main(void) >>>>> { >>>>> short i, j; >>>>> >>>>> i = (i << 8) + 1; >>>>> j = (j << 8) | 2; >>>>> } >> >> // richard >> >> // photo book: http://www.blurb.com/bookstore/detail/745963 >> _______________________________________________ >> Icc-mot mailing list >> Icc-mot@imagecraft.com >> http://dragonsgate.net/mailman/listinfo/icc-mot >> > > _______________________________________________ > Icc-mot mailing list > Icc-mot@imagecraft.com > http://dragonsgate.net/mailman/listinfo/icc-mot From richard-lists at imagecraft.com Thu Jul 16 12:51:23 2009 From: richard-lists at imagecraft.com (Richard Man) Date: Thu Jul 16 14:02:04 2009 Subject: [Icc-mot] Re: ICC12 bug In-Reply-To: <4A5F7AF5.2060500@fiocca.net> References: <47F64175.4020603@spotengineering.com> <000601c89672$d78b06f0$a300a8c0@REKS> <47F6635C.4060700@spotengineering.com> <02de01c8967c$c41b8c70$a300a8c0@REKS> <200804070828.m378S11L069215@mail.imagecraft.com> <4A5B4913.8020508@spotengineering.com> <200907160200.n6G20R5W092917@mail.imagecraft.com> <938BD2429DF3433FBF97988473FB996C@edvardo> <4A5F7AF5.2060500@fiocca.net> Message-ID: <200907162102.n6GL23ui024312@mail.imagecraft.com> It's not in there yet, so it depends on how long it takes to add the expanded memory support. Will let the list know. At 12:09 PM 7/16/2009, Jim Fiocca wrote: >Does the assembler support the new S12X instructions yet, or will >that be in a separate release of the assembler? > >Thanks, >Jim > > >Edward Karpicz wrote: >>Hm, I see some more improvements in this compiler. >> >>1). More long branches replaced with short branches, when in range. >> >>2) Eliminated redundand ANDx instructions doing short & 0xFFFF , for example >> >>Old: >>; if(errC & ~WARNINGS) // warnings defined as 0 >> ldd _errC >> anda #-1 >> andb #-1 >> tfr D,Y >> cpy #0 >> >>New: >>; if(errC & ~WARNINGS) >> ldy _errC >> cpy #0 >>***** >> >>... And more. >>Wow! >> >>Edward >> >> >>----- Original Message ----- From: "Richard Man" >> >>To: >>Sent: Thursday, July 16, 2009 03:49 >>Subject: [Icc-mot] Re: ICC12 bug >> >> >>>This has been fixed. It only affects code of the form >>> >>> local_var = (local_var << 8) op con >>> >>>where op is either + or |. >>> >>>http://www.dragonsgate.net/pub/BETAS/iccom12w.exe, put that in >>>your bin directory. I will release this along with the enhanced >>>expanded memory support soon... >>> >>> >>> >>>At 07:47 AM 7/13/2009, Gene Norris wrote: >>>>Richard, >>>> >>>>Do you remember this? Could you address this while you are back >>>>on the HC12? >>>> >>>>Richard Man wrote: >>>>>I will fix it... >>>>>At 10:53 AM 4/4/2008, Edward Karpicz wrote: >>>>>>Gene, >>>>>> >>>>>>>Yes, I didn't want to muddy the waters though. >>>>>> >>>>>> >>>>>>Acctually I muddied waters, sorry. You are rigth, you found the >>>>>>bug. Richard, please fix it. Reconstructing minimal code: >>>>>> >>>>>> >>>>>>void main(void) >>>>>>{ >>>>>>short i, j; >>>>>> >>>>>> i = (i << 8) + 1; >>>>>> j = (j << 8) | 2; >>>>>>} // richard // photo book: http://www.blurb.com/bookstore/detail/745963 From mactwndon at yahoo.com Thu Jul 16 13:46:36 2009 From: mactwndon at yahoo.com (D) Date: Thu Jul 16 14:56:25 2009 Subject: [Icc-mot] Need Info on Schools and/or Institutions That Are Using ImageCraft ICC12 V6 Message-ID: <571110.94452.qm@web36804.mail.mud.yahoo.com> Hi everyone, I am writing a paper on my experience on moving from ImageCraft ICC12 V6 for HC12/HCS12 to ImageCraft ICCV7 for HC12/HCS12/HCS12X microcontrollers. I will like to find out if there are any schools/ institutons that are still using ImageCraft ICC12 V6 for HC12/HCS12 microcontrollers. I will like to include this list in my paper. Thanks, Donald From richard at imagecraft.com Tue Jul 21 16:27:44 2009 From: richard at imagecraft.com (Richard Man) Date: Tue Jul 21 17:38:44 2009 Subject: [Icc-mot] ICC12 7.07 BETA0 Message-ID: <200907220038.n6M0ch3H013717@mail.imagecraft.com> In the end, it's much easier to implement once we know what's needed :-) The IDE also picks up a number of enhancements done in the last 6 months: http://www.imagecraft.com/pub/iccv712_v707_beta0.exe You should no longer need to use log2phy or sreccvt EXCEPT to get the srecord line length. I will add that later. There should be no visible changes if you are using NoICE, Twinpeek etc. If you have any expanded memory projects, I'd appreciate if you see if it builds correctly using this beta. A few more things I want to add to this release: - doc changes for the expanded memory support - EITHER add __paged keyword, e.g. void __paged (*pfunc)(void); OR add an automatic trampoline for indirect paged function calls either way, this should allow indirect paged function calls without needing to use _icall() explicitly and allow function arguments **** CHANGE LOGS: IDE - Much faster startup time for the IDE - IDE now keeps a "Build Number" for each project. This is passed to the linker and emitted to the top of the .mp map file. - Overhauled the expanded memory settings. - Fixed RAM start address for S12XDP512 - Changed -D__ICC_VERSION=XXX where XXX is the version in integer form, e.g. 707. This allows easier conditional compilation. - Modified the "checking" options, now they are "Strict Checking" (equivalent to -A command line switch). "ANSI C Portability Conformance Checking" (equivalent to -A -A). This does draconian check on conditions that exceed ANSI C minimum limits (e.g. less than 512 variables) and is usually not needed. - Added Tools->EnvOptions->General->BackupPolicy. The choices are == Unlimied (in BACKUP\ directory) == One Only (in BACKUP\ directory) Compiler - The compiler was miscounting some instruction sizes and was generating short branches when long branches are needed and caused the assembler to assert with error. - Added #pragma warning warning message emits warning message, similar to #warning #pragma ignore_unused_var name1 name2 ... This must appear inside a function and specifies the named arguments are intentionally unused so no warning message should be generated for them. Linker - Overhauled the expanded memory support. The goal is to eliminate needing to use P&E Log2Phy or SrecCVT to convert our output. The following flags are not supported: -s1 Use S1 records only. Valid only if there is no extended memory CALL -s2_cpu Use CPU addresses for the S2 records -s2_s12 Use S12 expanded memory mapping for the S2 records -s2_s12x Use S12X expanded memory mapping for the S2 records The .DBG file uses CPU addresses, as before. See Help file for details (not yet done for BETA release). // richard blog: // mailing list: http://www.dragonsgate.net/mailman/listinfo // photo book: http://www.blurb.com/bookstore/detail/745963 [ For technical support on ImageCraft products, please include all previous replies in your msgs. ] From dean.bell at flightec.com Tue Jul 21 17:11:53 2009 From: dean.bell at flightec.com (Dean Bell) Date: Tue Jul 21 18:21:49 2009 Subject: [Icc-mot] ICC12 7.07 BETA0 In-Reply-To: <200907220038.n6M0ch3H013717@mail.imagecraft.com> Message-ID: Hi Richard I see that the 'build number' is not passed in at compile time, can this happen please? icc12w -c -IC:\iccv712\include -e -D__ICC_VERSION=707 -l -A ..\SRC\MisraMain.c -D__ICC_BUILD=xxx Dean. -----Original Message----- From: icc-mot-bounces@imagecraft.com [mailto:icc-mot-bounces@imagecraft.com]On Behalf Of Richard Man Sent: Wednesday, 22 July 2009 11:28 a.m. To: icc-mot@imagecraft.com Subject: [Icc-mot] ICC12 7.07 BETA0 In the end, it's much easier to implement once we know what's needed :-) The IDE also picks up a number of enhancements done in the last 6 months: http://www.imagecraft.com/pub/iccv712_v707_beta0.exe You should no longer need to use log2phy or sreccvt EXCEPT to get the srecord line length. I will add that later. There should be no visible changes if you are using NoICE, Twinpeek etc. If you have any expanded memory projects, I'd appreciate if you see if it builds correctly using this beta. A few more things I want to add to this release: - doc changes for the expanded memory support - EITHER add __paged keyword, e.g. void __paged (*pfunc)(void); OR add an automatic trampoline for indirect paged function calls either way, this should allow indirect paged function calls without needing to use _icall() explicitly and allow function arguments **** CHANGE LOGS: IDE - Much faster startup time for the IDE - IDE now keeps a "Build Number" for each project. This is passed to the linker and emitted to the top of the .mp map file. - Overhauled the expanded memory settings. - Fixed RAM start address for S12XDP512 - Changed -D__ICC_VERSION=XXX where XXX is the version in integer form, e.g. 707. This allows easier conditional compilation. - Modified the "checking" options, now they are "Strict Checking" (equivalent to -A command line switch). "ANSI C Portability Conformance Checking" (equivalent to -A -A). This does draconian check on conditions that exceed ANSI C minimum limits (e.g. less than 512 variables) and is usually not needed. - Added Tools->EnvOptions->General->BackupPolicy. The choices are == Unlimied (in BACKUP\ directory) == One Only (in BACKUP\ directory) Compiler - The compiler was miscounting some instruction sizes and was generating short branches when long branches are needed and caused the assembler to assert with error. - Added #pragma warning warning message emits warning message, similar to #warning #pragma ignore_unused_var name1 name2 ... This must appear inside a function and specifies the named arguments are intentionally unused so no warning message should be generated for them. Linker - Overhauled the expanded memory support. The goal is to eliminate needing to use P&E Log2Phy or SrecCVT to convert our output. The following flags are not supported: -s1 Use S1 records only. Valid only if there is no extended memory CALL -s2_cpu Use CPU addresses for the S2 records -s2_s12 Use S12 expanded memory mapping for the S2 records -s2_s12x Use S12X expanded memory mapping for the S2 records The .DBG file uses CPU addresses, as before. See Help file for details (not yet done for BETA release). // richard blog: // mailing list: http://www.dragonsgate.net/mailman/listinfo // photo book: http://www.blurb.com/bookstore/detail/745963 [ 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 richard-lists at imagecraft.com Tue Jul 21 17:16:17 2009 From: richard-lists at imagecraft.com (Richard Man) Date: Tue Jul 21 18:27:19 2009 Subject: [Icc-mot] ICC12 7.07 BETA0 In-Reply-To: References: <200907220038.n6M0ch3H013717@mail.imagecraft.com> Message-ID: <200907220127.n6M1RIO2014503@mail.imagecraft.com> Now why would anyone care?!! :-) How would you use it? At 05:11 PM 7/21/2009, you wrote: >Hi Richard > >I see that the 'build number' is not passed in at compile time, can this >happen please? > >icc12w -c -IC:\iccv712\include -e -D__ICC_VERSION=707 -l -A >..\SRC\MisraMain.c > >-D__ICC_BUILD=xxx > >Dean. // richard // photo book: http://www.blurb.com/bookstore/detail/745963 From dean.bell at flightec.com Tue Jul 21 18:26:46 2009 From: dean.bell at flightec.com (Dean Bell) Date: Tue Jul 21 19:36:42 2009 Subject: [Icc-mot] ICC12 7.07 BETA0 In-Reply-To: <200907220127.n6M1RIO2014503@mail.imagecraft.com> Message-ID: Ok, that is a easy way to send out the software ver/build out in two bytes over a CAN bus in a simple message (CANaerospace) so you don't have to remember to change the build number by hand, then compile. It is automated. Dean. -----Original Message----- From: icc-mot-bounces@imagecraft.com [mailto:icc-mot-bounces@imagecraft.com]On Behalf Of Richard Man Sent: Wednesday, 22 July 2009 12:16 p.m. To: icc-mot@imagecraft.com Subject: RE: [Icc-mot] ICC12 7.07 BETA0 Now why would anyone care?!! :-) How would you use it? At 05:11 PM 7/21/2009, you wrote: >Hi Richard > >I see that the 'build number' is not passed in at compile time, can this >happen please? > >icc12w -c -IC:\iccv712\include -e -D__ICC_VERSION=707 -l -A >..\SRC\MisraMain.c > >-D__ICC_BUILD=xxx > >Dean. // richard // photo book: http://www.blurb.com/bookstore/detail/745963 _______________________________________________ Icc-mot mailing list Icc-mot@imagecraft.com http://dragonsgate.net/mailman/listinfo/icc-mot From richard-lists at imagecraft.com Tue Jul 21 22:58:52 2009 From: richard-lists at imagecraft.com (Richard Man) Date: Wed Jul 22 00:09:54 2009 Subject: [Icc-mot] ICC12 7.07 BETA0 In-Reply-To: References: <200907220127.n6M1RIO2014503@mail.imagecraft.com> Message-ID: <200907220709.n6M79rMb019864@mail.imagecraft.com> I should know better than to argue with you :-) OK, I will add it. Currently, the build # does not saturated, so if you overflow a 32 bits integer, you are on your own :-) At 06:26 PM 7/21/2009, Dean Bell wrote: >Ok, that is a easy way to send out the software ver/build out in two bytes >over a CAN bus in a simple message >(CANaerospace) so you don't have to remember to change the build number by >hand, then compile. It is automated. > >Dean. > >-----Original Message----- >From: icc-mot-bounces@imagecraft.com >[mailto:icc-mot-bounces@imagecraft.com]On Behalf Of Richard Man >Sent: Wednesday, 22 July 2009 12:16 p.m. >To: icc-mot@imagecraft.com >Subject: RE: [Icc-mot] ICC12 7.07 BETA0 > > >Now why would anyone care?!! :-) How would you use it? > >At 05:11 PM 7/21/2009, you wrote: > >Hi Richard > > > >I see that the 'build number' is not passed in at compile time, can this > >happen please? > > > >icc12w -c -IC:\iccv712\include -e -D__ICC_VERSION=707 -l -A > >..\SRC\MisraMain.c > > > >-D__ICC_BUILD=xxx > > // richard // photo book: http://www.blurb.com/bookstore/detail/745963 From ekarpicz at freemail.lt Wed Jul 22 00:21:13 2009 From: ekarpicz at freemail.lt (Edward Karpicz) Date: Wed Jul 22 01:31:11 2009 Subject: [Icc-mot] ICC12 7.07 BETA0 References: <200907220038.n6M0ch3H013717@mail.imagecraft.com> Message-ID: <556B1CF2A848450798AFA479696DA021@edvardo> 1. To enable S1->S2 remapping, Expanded Memory Enable has to be checked. With expanded memory unchecked someone still may need sreccvt... And how someone could use S1->S2 conversion on C32? IDE doesn't allow to enable expanded memory for this device. Unless you switch to custom. But when you switch to custom, how could you tell ICC where it should remap nonpaged 0x8000? 2. Something is not right. Simple project with just void main(void) somewhere at 0x4000. CPU type radio is set to HCS12. All settings seem being valid. But s19 file has such records S20EF84000CF100016402DCE04028EF5 Logical/linear address 0xF84000. While expanded memory range is 0x0F0000.0xFFFFF... Nonpaged 0x4000..0x7FFF should translate on most S12s to page 0x3E. 0x3E*0x4000 + (0x4000%0x4000) = 0F8000..0x0FBFFF 3. Same application like in p2, but switching to custom and changing bottom of text to 0x8000. S20EF08000CF100016802DCE04028E7D But that's not weird. I switched to custom and ICC doesn't know is it 64k or 32k or xxk device, and doesn't know where to remap 0x8000. 4. Now since S12 S1->S2 conversion isn't OK, I'm switching CPU type to S1. And building my paged app, (probably) linker fills error window with zilion of !E main.o(16): -s1 flag specified. Expanded memory not supported. I wan't to convert my app myself, I don't want these messages. BTW despite of !E, ICC12 produced working application. 5. I had to type E! error message from p4 by hand. Because, when I wanted to copy it and clicked on error, Warning box popped up stating that "Error originates in associated .c or .s file". Wow. Very useful :-). I don't know how to copy error messages... 6. S12X application seems being converted well. Even nonpaged 4000-, 8000-, and c000-. Of course Expanded Memory should be on. Edward Richard Man wrote: > You should no longer need to use log2phy or sreccvt EXCEPT to get the > srecord line length. I will add that later. > > If you have any expanded memory projects, I'd appreciate if you see if it > builds correctly using this beta. > CHANGE LOGS: > Linker > - Overhauled the expanded memory support. The goal is to eliminate > needing to use P&E Log2Phy or SrecCVT to convert our output. The > following flags are not supported: > -s1 Use S1 records only. Valid only if there is no extended > memory > CALL > -s2_cpu Use CPU addresses for the S2 records > -s2_s12 Use S12 expanded memory mapping for the S2 records > -s2_s12x Use S12X expanded memory mapping for the S2 records > > // richard blog: > > // mailing list: http://www.dragonsgate.net/mailman/listinfo > // photo book: http://www.blurb.com/bookstore/detail/745963 > [ 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 ekarpicz at freemail.lt Wed Jul 22 00:29:10 2009 From: ekarpicz at freemail.lt (Edward Karpicz) Date: Wed Jul 22 01:39:05 2009 Subject: [Icc-mot] ICC12 7.07 BETA0 References: <200907220127.n6M1RIO2014503@mail.imagecraft.com> <200907220709.n6M79rMb019864@mail.imagecraft.com> Message-ID: Autoincrementing build number define would be nice. But won't it touch all project files and trigger recompilation all of them on next make? Some smart dependency check? Edward ----- Original Message ----- From: "Richard Man" To: Sent: Wednesday, July 22, 2009 08:58 Subject: RE: [Icc-mot] ICC12 7.07 BETA0 >I should know better than to argue with you :-) OK, I will add it. > > Currently, the build # does not saturated, so if you overflow a 32 bits > integer, you are on your own :-) > > At 06:26 PM 7/21/2009, Dean Bell wrote: >>Ok, that is a easy way to send out the software ver/build out in two bytes >>over a CAN bus in a simple message >>(CANaerospace) so you don't have to remember to change the build number by >>hand, then compile. It is automated. >> >>Dean. >> >>-----Original Message----- >>From: icc-mot-bounces@imagecraft.com >>[mailto:icc-mot-bounces@imagecraft.com]On Behalf Of Richard Man >>Sent: Wednesday, 22 July 2009 12:16 p.m. >>To: icc-mot@imagecraft.com >>Subject: RE: [Icc-mot] ICC12 7.07 BETA0 >> >> >>Now why would anyone care?!! :-) How would you use it? >> >>At 05:11 PM 7/21/2009, you wrote: >> >Hi Richard >> > >> >I see that the 'build number' is not passed in at compile time, can this >> >happen please? >> > >> >icc12w -c -IC:\iccv712\include -e -D__ICC_VERSION=707 -l -A >> >..\SRC\MisraMain.c >> > >> >-D__ICC_BUILD=xxx >> > > > // richard > > // photo book: http://www.blurb.com/bookstore/detail/745963 > _______________________________________________ > Icc-mot mailing list > Icc-mot@imagecraft.com > http://dragonsgate.net/mailman/listinfo/icc-mot > From richard-lists at imagecraft.com Wed Jul 22 00:43:39 2009 From: richard-lists at imagecraft.com (Richard Man) Date: Wed Jul 22 01:54:42 2009 Subject: [Icc-mot] ICC12 7.07 BETA0 In-Reply-To: <556B1CF2A848450798AFA479696DA021@edvardo> References: <200907220038.n6M0ch3H013717@mail.imagecraft.com> <556B1CF2A848450798AFA479696DA021@edvardo> Message-ID: <200907220854.n6M8sf1M022739@mail.imagecraft.com> So 1 out of 6 works?!!! Ship it!!! :-) Thanks for the comments... lets see.... At 12:21 AM 7/22/2009, Edward Karpicz wrote: >1. To enable S1->S2 remapping, Expanded Memory Enable has to be >checked. With expanded memory unchecked someone still may need sreccvt... >And how someone could use S1->S2 conversion on C32? IDE doesn't >allow to enable expanded memory for this device. Unless you switch >to custom. But when you switch to custom, how could you tell ICC >where it should remap nonpaged 0x8000? There are too many checkboxes and buttons!! :-) So should I add one more: when expanded memory is NOT enabled, then the old "S2 records only" checkbox shows up? >2. Something is not right. Simple project with just void main(void) >somewhere at 0x4000. CPU type radio is set to HCS12. All settings >seem being valid. But s19 file has such records > > S20EF84000CF100016402DCE04028EF5 > > > Logical/linear address 0xF84000. While expanded memory range is > 0x0F0000.0xFFFFF... Nonpaged 0x4000..0x7FFF should translate on > most S12s to page 0x3E. 0x3E*0x4000 + (0x4000%0x4000) = 0F8000..0x0FBFFF Just to clarify: are you saying I am off by having an extra zero, e.g. F84000 rather than F8400, or off by an extra zero AND also by 400(0)? >3. Same application like in p2, but switching to custom and changing >bottom of text to 0x8000. > > S20EF08000CF100016802DCE04028E7D > > >But that's not weird. I switched to custom and ICC doesn't know is >it 64k or 32k or xxk device, and doesn't know where to remap 0x8000. > Currently, it computes the size from the expanded memory range, e.g. -bextcode:0x?????.0xFFFFF Is it not right? >4. Now since S12 S1->S2 conversion isn't OK, I'm switching CPU type >to S1. And building my paged app, (probably) linker fills error >window with zilion of > >!E main.o(16): -s1 flag specified. Expanded memory not supported. > >I wan't to convert my app myself, I don't want these messages. BTW >despite of !E, ICC12 produced working application. > OK, will fix the zillion message problem. >5. I had to type E! error message from p4 by hand. Because, when I >wanted to copy it and clicked on error, Warning box popped up >stating that "Error originates in associated .c or .s file". Wow. >Very useful :-). I don't know how to copy error messages... > At one point, you should be able to select and then ^C, somewhere along the line this is broken :-( >6. S12X application seems being converted well. Even nonpaged 4000-, >8000-, and c000-. Of course Expanded Memory should be on. > Success! 1 out of 6 :-) >Edward > > > > >Richard Man wrote: > > >>You should no longer need to use log2phy or sreccvt EXCEPT to get >>the srecord line length. I will add that later. > > >>If you have any expanded memory projects, I'd appreciate if you see >>if it builds correctly using this beta. > > >>CHANGE LOGS: >> Linker >> - Overhauled the expanded memory support. The goal is to eliminate >> needing to use P&E Log2Phy or SrecCVT to convert our output. The >> following flags are not supported: >> -s1 Use S1 records only. Valid only if there is no >> extended memory >> CALL >> -s2_cpu Use CPU addresses for the S2 records >> -s2_s12 Use S12 expanded memory mapping for the S2 records >> -s2_s12x Use S12X expanded memory mapping for the S2 records > > >>// richard blog: >> >>// mailing list: http://www.dragonsgate.net/mailman/listinfo >>// photo book: http://www.blurb.com/bookstore/detail/745963 >>[ 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 > >_______________________________________________ >Icc-mot mailing list >Icc-mot@imagecraft.com >http://dragonsgate.net/mailman/listinfo/icc-mot // richard // photo book: http://www.blurb.com/bookstore/detail/745963 From richard-lists at imagecraft.com Wed Jul 22 00:45:08 2009 From: richard-lists at imagecraft.com (Richard Man) Date: Wed Jul 22 01:56:12 2009 Subject: [Icc-mot] ICC12 7.07 BETA0 In-Reply-To: References: <200907220127.n6M1RIO2014503@mail.imagecraft.com> <200907220709.n6M79rMb019864@mail.imagecraft.com> Message-ID: <200907220856.n6M8uAud022790@mail.imagecraft.com> No, it only causes a re-link. We always do a re-link everytime you do a Project->Build. It started out as a sort-of bug, but no one complains, and I like the fact that it always does something so I left it there... At 12:29 AM 7/22/2009, you wrote: >Autoincrementing build number define would be nice. But won't it >touch all project files and trigger recompilation all of them on >next make? Some smart dependency check? > >Edward > // richard // photo book: http://www.blurb.com/bookstore/detail/745963 From ekarpicz at freemail.lt Wed Jul 22 01:12:40 2009 From: ekarpicz at freemail.lt (Edward Karpicz) Date: Wed Jul 22 02:22:45 2009 Subject: [Icc-mot] ICC12 7.07 BETA0 References: <200907220127.n6M1RIO2014503@mail.imagecraft.com><200907220709.n6M79rMb019864@mail.imagecraft.com> <200907220856.n6M8uAud022790@mail.imagecraft.com> Message-ID: <67EDF6FE936C4A49912B34EE232ACC4D@edvardo> Hm, I don't see what started as a sort-of bug... OK, then all files will see build number define (-DBUILDNO or something), but linked application may have build number a little out of sync, depending on was define-using files recompiled or not. Right? If so, then fine, I like it. Edward ----- Original Message ----- From: "Richard Man" To: Sent: Wednesday, July 22, 2009 10:45 Subject: Re: [Icc-mot] ICC12 7.07 BETA0 > No, it only causes a re-link. We always do a re-link everytime you do a > Project->Build. It started out as a sort-of bug, but no one complains, and > I like the fact that it always does something so I left it there... > > > At 12:29 AM 7/22/2009, you wrote: >>Autoincrementing build number define would be nice. But won't it touch all >>project files and trigger recompilation all of them on next make? Some >>smart dependency check? >> >>Edward >> > > // richard > > // photo book: http://www.blurb.com/bookstore/detail/745963 > _______________________________________________ > Icc-mot mailing list > Icc-mot@imagecraft.com > http://dragonsgate.net/mailman/listinfo/icc-mot > From dean.bell at flightec.com Wed Jul 22 01:16:14 2009 From: dean.bell at flightec.com (Dean Bell) Date: Wed Jul 22 02:26:29 2009 Subject: [Icc-mot] ICC12 7.07 BETA0 In-Reply-To: Message-ID: Yes, I se what you mean Edward I just simulated __ICC_BUILD=13 from the Compile Options->Compile Macro define(s) and this dose rebuild all the .c files when using 'Make project' (F9). This is not an issue for me as I always use 'Rebuild All' (160+ .c files) as I have been caught out before by 'Make project'. Dean. -----Original Message----- From: icc-mot-bounces@imagecraft.com [mailto:icc-mot-bounces@imagecraft.com]On Behalf Of Edward Karpicz Sent: Wednesday, 22 July 2009 7:29 p.m. To: Discussion List for ICC08/11/12/16 users. You do NOT need tosubscribe toicc-announce if you are a member of this. Subject: Re: [Icc-mot] ICC12 7.07 BETA0 Autoincrementing build number define would be nice. But won't it touch all project files and trigger recompilation all of them on next make? Some smart dependency check? Edward ----- Original Message ----- From: "Richard Man" To: Sent: Wednesday, July 22, 2009 08:58 Subject: RE: [Icc-mot] ICC12 7.07 BETA0 >I should know better than to argue with you :-) OK, I will add it. > > Currently, the build # does not saturated, so if you overflow a 32 bits > integer, you are on your own :-) > > At 06:26 PM 7/21/2009, Dean Bell wrote: >>Ok, that is a easy way to send out the software ver/build out in two bytes >>over a CAN bus in a simple message >>(CANaerospace) so you don't have to remember to change the build number by >>hand, then compile. It is automated. >> >>Dean. >> >>-----Original Message----- >>From: icc-mot-bounces@imagecraft.com >>[mailto:icc-mot-bounces@imagecraft.com]On Behalf Of Richard Man >>Sent: Wednesday, 22 July 2009 12:16 p.m. >>To: icc-mot@imagecraft.com >>Subject: RE: [Icc-mot] ICC12 7.07 BETA0 >> >> >>Now why would anyone care?!! :-) How would you use it? >> >>At 05:11 PM 7/21/2009, you wrote: >> >Hi Richard >> > >> >I see that the 'build number' is not passed in at compile time, can this >> >happen please? >> > >> >icc12w -c -IC:\iccv712\include -e -D__ICC_VERSION=707 -l -A >> >..\SRC\MisraMain.c >> > >> >-D__ICC_BUILD=xxx >> > > > // richard > > // photo book: http://www.blurb.com/bookstore/detail/745963 > _______________________________________________ > Icc-mot mailing list > Icc-mot@imagecraft.com > http://dragonsgate.net/mailman/listinfo/icc-mot > _______________________________________________ Icc-mot mailing list Icc-mot@imagecraft.com http://dragonsgate.net/mailman/listinfo/icc-mot From richard-lists at imagecraft.com Wed Jul 22 01:18:53 2009 From: richard-lists at imagecraft.com (Richard Man) Date: Wed Jul 22 02:29:57 2009 Subject: [Icc-mot] ICC12 7.07 BETA0 In-Reply-To: References: Message-ID: <200907220929.n6M9TtB4023297@mail.imagecraft.com> No, it doesn't work that way :-) When you add something explicitly to the Macro Define box, then it will rebuild all, because that's the sensible thing to do. The IDE updating the build # is wholly done internally - it reads the number in the .prj file and increments it. So this does not cause a rebuild all. And AFAIK, there is no issue with Project->Make. At 01:16 AM 7/22/2009, Dean Bell wrote: >Yes, I se what you mean Edward > >I just simulated __ICC_BUILD=13 from the Compile Options->Compile Macro >define(s) >and this dose rebuild all the .c files when using 'Make project' (F9). >This is not an issue for me as I always use 'Rebuild All' (160+ .c files) as >I have been caught out before by 'Make project'. > >Dean. > >-----Original Message----- >From: icc-mot-bounces@imagecraft.com >[mailto:icc-mot-bounces@imagecraft.com]On Behalf Of Edward Karpicz >Sent: Wednesday, 22 July 2009 7:29 p.m. >To: Discussion List for ICC08/11/12/16 users. You do NOT need >tosubscribe toicc-announce if you are a member of this. >Subject: Re: [Icc-mot] ICC12 7.07 BETA0 > > >Autoincrementing build number define would be nice. But won't it touch all >project files and trigger recompilation all of them on next make? Some smart >dependency check? > >Edward // richard // photo book: http://www.blurb.com/bookstore/detail/745963 From ekarpicz at freemail.lt Wed Jul 22 01:47:07 2009 From: ekarpicz at freemail.lt (Edward Karpicz) Date: Wed Jul 22 02:57:02 2009 Subject: [Icc-mot] ICC12 7.07 BETA0 References: <200907220038.n6M0ch3H013717@mail.imagecraft.com><556B1CF2A848450798AFA479696DA021@edvardo> <200907220854.n6M8sf1M022739@mail.imagecraft.com> Message-ID: > So 1 out of 6 works?!!! Ship it!!! :-) > > Thanks for the comments... lets see.... > > At 12:21 AM 7/22/2009, Edward Karpicz wrote: >>1. To enable S1->S2 remapping, Expanded Memory Enable has to be checked. >>With expanded memory unchecked someone still may need sreccvt... >>And how someone could use S1->S2 conversion on C32? IDE doesn't allow to >>enable expanded memory for this device. Unless you switch to custom. But >>when you switch to custom, how could you tell ICC where it should remap >>nonpaged 0x8000? > > There are too many checkboxes and buttons!! :-) So should I add one more: > when expanded memory is NOT enabled, then the old "S2 records only" > checkbox shows up? I'm not sure. What I know is that if you want to solve all srecord conversion issues, then something should be done also to nonpaged applications. P&E burners won't burn nonpaged S12C32 applications, unless all nonpaged S1 records are converted to linear/physical. S12C32 and S12Dx32 IDE templates have hidden Enable expanded memory checkbox. And linker doesn't convert S1->S2 when this Enable checkbox is off. No one should use paged memory in C32, but as I understand many users want proper conversion to physical/linear records... >>2. Something is not right. Simple project with just void main(void) >>somewhere at 0x4000. CPU type radio is set to HCS12. All settings seem >>being valid. But s19 file has such records >> >> S20EF84000CF100016402DCE04028EF5 >> >> >> Logical/linear address 0xF84000. While expanded memory range is >> 0x0F0000.0xFFFFF... Nonpaged 0x4000..0x7FFF should translate on most S12s >> to page 0x3E. 0x3E*0x4000 + (0x4000%0x4000) = 0F8000..0x0FBFFF > > Just to clarify: are you saying I am off by having an extra zero, e.g. > F84000 rather than F8400, or off by an extra zero AND also by 400(0)? I see F84000 in S2 record, while it has to be 0F8000. >>3. Same application like in p2, but switching to custom and changing >>bottom of text to 0x8000. >> >> S20EF08000CF100016802DCE04028E7D >> >> >>But that's not weird. I switched to custom and ICC doesn't know is it 64k >>or 32k or xxk device, and doesn't know where to remap 0x8000. >> > > Currently, it computes the size from the expanded memory range, > e.g. -bextcode:0x?????.0xFFFFF > > Is it not right? No, it is not right. First of all, like we discussed before, S12 devices, depending on memory size, should have 0x8000 remapped to 32k device: 0x3E*0x4000 = 0F8000 64k device: 0x3C*0x4000 = 0F0000 128k - 38*0x4000 = 0E0000 etc When I select specific size S12 device, I can't verify 0x8000 remapping is performed well. Because 1) switching expanded memory off also turns S1->S2 conversion off. And 2) if I select specific size S12 device, then I can't adjust nonpaged Program Memory settings to start from or include 0x8000.. addresses. So the question is like with C32 devices, how to do nonpaged S12 application, which would include all available nonpaged addresses (including 0x8000..0xBFFF), but so that outputed S19 file would contain only physical/linear S records... >>4. Now since S12 S1->S2 conversion isn't OK, I'm switching CPU type to S1. >>And building my paged app, (probably) linker fills error window with >>zilion of >> >>!E main.o(16): -s1 flag specified. Expanded memory not supported. >> >>I wan't to convert my app myself, I don't want these messages. BTW despite >>of !E, ICC12 produced working application. >> > > OK, will fix the zillion message problem. I prefer no such message. What about old HC12 with paged memory? They are not S12X and not S12. Is there a way to disable this error message? >>5. I had to type E! error message from p4 by hand. Because, when I wanted >>to copy it and clicked on error, Warning box popped up stating that "Error >>originates in associated .c or .s file". Wow. Very useful :-). I don't >>know how to copy error messages... >> > > At one point, you should be able to select and then ^C, somewhere along > the line this is broken :-( > Message box pops up and clears error line selection :-). Frankly, I don't know how to ^C it. > > >>6. S12X application seems being converted well. Even nonpaged 4000-, >>8000-, and c000-. Of course Expanded Memory should be on. >> > > Success! 1 out of 6 :-) Yeah! Edward > > > > >>Edward >> >> >> >> >>Richard Man wrote: >> >> >>>You should no longer need to use log2phy or sreccvt EXCEPT to get the >>>srecord line length. I will add that later. >> >> >>>If you have any expanded memory projects, I'd appreciate if you see if it >>>builds correctly using this beta. >> >> >>>CHANGE LOGS: >>> Linker >>> - Overhauled the expanded memory support. The goal is to eliminate >>> needing to use P&E Log2Phy or SrecCVT to convert our output. The >>> following flags are not supported: >>> -s1 Use S1 records only. Valid only if there is no extended >>> memory >>> CALL >>> -s2_cpu Use CPU addresses for the S2 records >>> -s2_s12 Use S12 expanded memory mapping for the S2 records >>> -s2_s12x Use S12X expanded memory mapping for the S2 records >> >> >>>// richard blog: >>> >>>// mailing list: http://www.dragonsgate.net/mailman/listinfo >>>// photo book: http://www.blurb.com/bookstore/detail/745963 >>>[ 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 >> >>_______________________________________________ >>Icc-mot mailing list >>Icc-mot@imagecraft.com >>http://dragonsgate.net/mailman/listinfo/icc-mot > > // richard > > // photo book: http://www.blurb.com/bookstore/detail/745963 > _______________________________________________ > Icc-mot mailing list > Icc-mot@imagecraft.com > http://dragonsgate.net/mailman/listinfo/icc-mot > From ekarpicz at freemail.lt Wed Jul 22 01:55:31 2009 From: ekarpicz at freemail.lt (Edward Karpicz) Date: Wed Jul 22 03:05:25 2009 Subject: [Icc-mot] ICC12 7.07 BETA0 References: <200907220038.n6M0ch3H013717@mail.imagecraft.com><556B1CF2A848450798AFA479696DA021@edvardo> <200907220854.n6M8sf1M022739@mail.imagecraft.com> Message-ID: > So 1 out of 6 works?!!! Ship it!!! :-) > One more thing to think. I tried to play with that my almost empty, just void main(void){} project, but with dongle pulled out, so 8k evaluation... It seems paged memory is forced to be off. But then how could people, evaluating ICC12, convert to physical S records? They also may have problems working with FSL bootloaders and/or P&E burners... Edward From dean.bell at flightec.com Wed Jul 22 02:03:52 2009 From: dean.bell at flightec.com (Dean Bell) Date: Wed Jul 22 03:13:49 2009 Subject: [Icc-mot] ICC12 7.07 BETA0 In-Reply-To: <200907220929.n6M9TtB4023297@mail.imagecraft.com> Message-ID: Ok. The 'Project->Make' thing may have been a from working to many hours in the day/week or some thing. I just made it a SOP (standard operating procedure) to do a 'Rebuild All' every time. May be I should change this then. It may have been the uC/OS code it is called out in one .c file which then calls a number of .c file to build the OS, so if one of the OSxx.c files changes then the compiler dose not know of the change. Dean. -----Original Message----- From: icc-mot-bounces@imagecraft.com [mailto:icc-mot-bounces@imagecraft.com]On Behalf Of Richard Man Sent: Wednesday, 22 July 2009 8:19 p.m. To: icc-mot@imagecraft.com Subject: RE: [Icc-mot] ICC12 7.07 BETA0 No, it doesn't work that way :-) When you add something explicitly to the Macro Define box, then it will rebuild all, because that's the sensible thing to do. The IDE updating the build # is wholly done internally - it reads the number in the .prj file and increments it. So this does not cause a rebuild all. And AFAIK, there is no issue with Project->Make. At 01:16 AM 7/22/2009, Dean Bell wrote: >Yes, I se what you mean Edward > >I just simulated __ICC_BUILD=13 from the Compile Options->Compile Macro >define(s) >and this dose rebuild all the .c files when using 'Make project' (F9). >This is not an issue for me as I always use 'Rebuild All' (160+ .c files) as >I have been caught out before by 'Make project'. > >Dean. > >-----Original Message----- >From: icc-mot-bounces@imagecraft.com >[mailto:icc-mot-bounces@imagecraft.com]On Behalf Of Edward Karpicz >Sent: Wednesday, 22 July 2009 7:29 p.m. >To: Discussion List for ICC08/11/12/16 users. You do NOT need >tosubscribe toicc-announce if you are a member of this. >Subject: Re: [Icc-mot] ICC12 7.07 BETA0 > > >Autoincrementing build number define would be nice. But won't it touch all >project files and trigger recompilation all of them on next make? Some smart >dependency check? > >Edward // richard // photo book: http://www.blurb.com/bookstore/detail/745963 _______________________________________________ Icc-mot mailing list Icc-mot@imagecraft.com http://dragonsgate.net/mailman/listinfo/icc-mot From richard-lists at imagecraft.com Wed Jul 22 02:13:05 2009 From: richard-lists at imagecraft.com (Richard Man) Date: Wed Jul 22 03:24:14 2009 Subject: [Icc-mot] ICC12 7.07 BETA0 In-Reply-To: References: <200907220038.n6M0ch3H013717@mail.imagecraft.com> <556B1CF2A848450798AFA479696DA021@edvardo> <200907220854.n6M8sf1M022739@mail.imagecraft.com> Message-ID: <200907221024.n6MAODSa026587@mail.imagecraft.com> At 01:47 AM 7/22/2009, Edward Karpicz wrote: >>So 1 out of 6 works?!!! Ship it!!! :-) >> >>Thanks for the comments... lets see.... >> >>At 12:21 AM 7/22/2009, Edward Karpicz wrote: >>>1. To enable S1->S2 remapping, Expanded Memory Enable has to be >>>checked. With expanded memory unchecked someone still may need sreccvt... >>>And how someone could use S1->S2 conversion on C32? IDE doesn't >>>allow to enable expanded memory for this device. Unless you switch >>>to custom. But when you switch to custom, how could you tell ICC >>>where it should remap nonpaged 0x8000? >> >>There are too many checkboxes and buttons!! :-) So should I add one >>more: when expanded memory is NOT enabled, then the old "S2 records >>only" checkbox shows up? > > >I'm not sure. What I know is that if you want to solve all srecord >conversion issues, then something should be done also to nonpaged >applications. P&E burners won't burn nonpaged S12C32 applications, >unless all nonpaged S1 records are converted to linear/physical. >S12C32 and S12Dx32 IDE templates have hidden Enable expanded memory >checkbox. And linker doesn't convert S1->S2 when this Enable >checkbox is off. No one should use paged memory in C32, but as I >understand many users want proper conversion to physical/linear records... > I am almost willing to say, since there are only one or may be the D64 that require this, we can just let them use Log2Phy... I rather simplify for 90% of the users.... Sounds like the remaining problem is all related to the incorrect mapping of 0x8000 on S12 devices, I will look at your email carefully and release BETA1 soon... I will look at the -s1 record issues too. Thanks! // richard // photo book: http://www.blurb.com/bookstore/detail/745963 From barryc at rjlsystems.com Wed Jul 22 05:59:44 2009 From: barryc at rjlsystems.com (Barry Callahan) Date: Wed Jul 22 07:10:22 2009 Subject: [Icc-mot] ICC12 7.07 BETA0 In-Reply-To: <67EDF6FE936C4A49912B34EE232ACC4D@edvardo> References: <200907220127.n6M1RIO2014503@mail.imagecraft.com><200907220709.n6M79rMb019864@mail.imagecraft.com> <200907220856.n6M8uAud022790@mail.imagecraft.com> <67EDF6FE936C4A49912B34EE232ACC4D@edvardo> Message-ID: <4A670D40.4030508@rjlsystems.com> If an object file is newer than the source file, the compiler "has nothing to do" for that target and can safely skip it. If the linked S19 file is newer than all of the object files, you can safely skip the linking process, too. In fact, one might argue that this is the expected behavior. Since ICC *always* links regardless of whether or not it's needed, you could argue that it is a bug... but one that is not likely to ever cause any problems. Hence, it's only "sort-of" a bug. Edward Karpicz wrote: > Hm, I don't see what started as a sort-of bug... > > ----- Original Message ----- From: "Richard Man" > > To: > Sent: Wednesday, July 22, 2009 10:45 > Subject: Re: [Icc-mot] ICC12 7.07 BETA0 > > >> No, it only causes a re-link. We always do a re-link everytime you do >> a Project->Build. It started out as a sort-of bug, but no one >> complains, and I like the fact that it always does something so I >> left it there... From richard at imagecraft.com Wed Jul 22 16:06:55 2009 From: richard at imagecraft.com (Richard Man) Date: Wed Jul 22 17:18:00 2009 Subject: [Icc-mot] ICC12 7.07 BETA1 Message-ID: <200907230017.n6N0Hw77047459@mail.imagecraft.com> In the end, it's much easier to implement once we know what's needed :-) The IDE also picks up a number of enhancements done in the last 6 months: http://www.imagecraft.com/pub/iccv712_v707_beta1.exe BETA0 -> BETA1: add -D__BUILD, and fixed up the S2 record flags, again... You should no longer need to use log2phy or sreccvt EXCEPT to get the srecord line length. I will add that later. There should be no visible changes if you are using NoICE, Twinpeek etc. If you have any expanded memory projects, I'd appreciate if you see if it builds correctly using this beta. A few more things I want to add to this release: - doc changes for the expanded memory support - EITHER add __paged keyword, e.g. void __paged (*pfunc)(void); OR add an automatic trampoline for indirect paged function calls either way, this should allow indirect paged function calls without needing to use _icall() explicitly and allow function arguments **** CHANGE LOGS: IDE - Much faster startup time for the IDE - IDE now keeps a "Build Number" for each project. This is passed to the linker and emitted to the top of the .mp map file. - Added -D__BUILD for the Build Number. - Overhauled the expanded memory settings. - Fixed RAM start address for S12XDP512 - Changed -D__ICC_VERSION=XXX where XXX is the version in integer form, e.g. 707. This allows easier conditional compilation. - Modified the "checking" options, now they are "Strict Checking" (equivalent to -A command line switch). "ANSI C Portability Conformance Checking" (equivalent to -A -A). This does draconian check on conditions that exceed ANSI C minimum limits (e.g. less than 512 variables) and is usually not needed. - Added Tools->EnvOptions->General->BackupPolicy. The choices are == Unlimied (in BACKUP\ directory) == One Only (in BACKUP\ directory) Compiler - The compiler was miscounting some instruction sizes and was generating short branches when long branches are needed and caused the assembler to assert with error. - Added #pragma warning warning message emits warning message, similar to #warning #pragma ignore_unused_var name1 name2 ... This must appear inside a function and specifies the named arguments are intentionally unused so no warning message should be generated for them. Linker - Overhauled the expanded memory support. The goal is to eliminate needing to use P&E Log2Phy or SrecCVT to convert our output. The following flags are now supported: -s2_s1 Use a mix of S1 and S2 records (CPU12 only) -s2_cpu Use CPU addresses for the S2 records -s2_s12 Use S12 mapping to convert S1 to S2 records -s2_s12x Use S12X mapping to convert S1 to S2 records This means that for the CPUS12 and S12X, only S2 records will be generated, either as CPU/Banked addresses, or in the "native" linear / global address format. The .DBG file uses CPU addresses, as before. See Help file for details (not yet done for BETA release). // richard blog: // mailing list: http://www.dragonsgate.net/mailman/listinfo // photo book: http://www.blurb.com/bookstore/detail/745963 [ For technical support on ImageCraft products, please include all previous replies in your msgs. ] From ekarpicz at freemail.lt Thu Jul 23 05:51:59 2009 From: ekarpicz at freemail.lt (Edward Karpicz) Date: Thu Jul 23 07:01:58 2009 Subject: [Icc-mot] ICC12 7.07 BETA1 References: <200907230017.n6N0Hw77047459@mail.imagecraft.com> Message-ID: <5CC8D9FF8F1545E683F01CD85D1DF436@edvardo> Seems better. My 99% full D64 program now is Ok. But.. 1) With this code #pragma abs_address:0x4000 int i4 = 0x4444; #pragma abs_address:0x8000 int i8 = 0x8888; #pragma abs_address:0xC000 int ic = 0xcccc; #pragma end_abs_address and with Expanded Memory off, for all 32, 64, 128 S12 devices linker produces this: S206 0F8000 4444E2 S206 0F8000 88885A *** S206 0FC000 CCCC92 With Expanded Memory on, *** line becomes ok for all devices, but with Expanded Memory off, *** line is valid only for 32k S12. In other words, nonpaged apps can't use 8000.BFFF with this beda, but when I make Expanded Memory on, bingo, S1->S2 mapping starts working for all devices. It should be opposite! Nonpaged apps require device size dependend remapping of nonpaged 8000.BFFF, and paged apps don't use nonpaged 8000.BFFF. 1a) Custom setup. Aha, it seems you are using lower end of paged memory to calculate where to to remap nonpaged 8000.BFFF. But this remapping, like in p1, has reversed Expanded Memory Enable checkbox logics. 8000.BFFF should be remapped when Expanded Memory is off, or even always (because paged apps don't use nonpaged addresses 8000.bfff). 2) A little concern about requirements for bottom and top of areas. I managed to get this: !E (1156): S12 device must use linear address for expanded memory. It seems to happen when bottom of Expanded Memory setting is not 0x80000/0xC0000/0xE0000/0xF0000/0xF8000, right? I don't mind, while my application works. But could you enlighten what are requirements for top and bottom addresses of all standard areas, please? I've one 99%+ full D64 app. It has not just text or just extcode areas full, but it really fills D64 with almost no free bytes. I had to adjust top of paged area and bottom of fragmented text area to make it working. Also it enables checks for preventing possible paged/nonpaged memory overlap. My custom settings are these: Expanded memory - 0xF0000.0xFA6FF Text area setting is 0x6700.0x7FFF:0xC000.0xECFF and above nonpaged ECFF there are idata and bootloader My concern is about requirements for top and bottom addresses. Requirement for 32k/64k/128k.. aligned bottom of expanded S12 memory is probably OK, but are there more requirements? S12X seem to not have this requirement, am I right? Edward ----- Original Message ----- From: "Richard Man" To: Sent: Thursday, July 23, 2009 02:06 Subject: [Icc-mot] ICC12 7.07 BETA1 > In the end, it's much easier to implement once we know what's needed :-) > The IDE also picks up a number of enhancements done in the last 6 months: > http://www.imagecraft.com/pub/iccv712_v707_beta1.exe > > BETA0 -> BETA1: add -D__BUILD, and fixed up the S2 record flags, again... > > You should no longer need to use log2phy or sreccvt EXCEPT to get the > srecord line length. I will add that later. > > There should be no visible changes if you are using NoICE, Twinpeek etc. > > If you have any expanded memory projects, I'd appreciate if you see if it > builds correctly using this beta. > > A few more things I want to add to this release: > - doc changes for the expanded memory support > - EITHER add __paged keyword, e.g. > void __paged (*pfunc)(void); > OR add an automatic trampoline for indirect paged function calls > > either way, this should allow indirect paged function calls without > needing to use _icall() explicitly and allow function arguments > > > **** > > CHANGE LOGS: > IDE > - Much faster startup time for the IDE > - IDE now keeps a "Build Number" for each project. This is passed to > the linker and emitted to the top of the .mp map file. > - Added -D__BUILD for the Build Number. > - Overhauled the expanded memory settings. > - Fixed RAM start address for S12XDP512 > - Changed -D__ICC_VERSION=XXX where XXX is the version in integer > form, > e.g. 707. This allows easier conditional compilation. > - Modified the "checking" options, now they are > "Strict Checking" (equivalent to -A command line switch). > "ANSI C Portability Conformance Checking" (equivalent to -A -A). > This does draconian check on conditions that exceed ANSI C minimum > limits (e.g. less than 512 variables) and is usually not needed. > - Added Tools->EnvOptions->General->BackupPolicy. The choices are > == Unlimied (in BACKUP\ directory) > == One Only (in BACKUP\ directory) > > Compiler > - The compiler was miscounting some instruction sizes and was > generating short branches when long branches are needed and caused > the assembler to assert with error. > - Added > #pragma warning warning message > emits warning message, similar to #warning > > #pragma ignore_unused_var name1 name2 ... > This must appear inside a function and specifies the named arguments > are intentionally unused so no warning message should be generated > for them. > > Linker > - Overhauled the expanded memory support. The goal is to eliminate > needing to use P&E Log2Phy or SrecCVT to convert our output. The > following flags are now supported: > > > -s2_s1 Use a mix of S1 and S2 records (CPU12 only) > -s2_cpu Use CPU addresses for the S2 records > -s2_s12 Use S12 mapping to convert S1 to S2 records > -s2_s12x Use S12X mapping to convert S1 to S2 records > > This means that for the CPUS12 and S12X, only S2 records will be > generated, either as CPU/Banked addresses, or in the "native" > linear / global address format. > > The .DBG file uses CPU addresses, as before. > > See Help file for details (not yet done for BETA release). > > > // richard blog: > > // mailing list: http://www.dragonsgate.net/mailman/listinfo > // photo book: http://www.blurb.com/bookstore/detail/745963 > [ 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 richard-lists at imagecraft.com Mon Jul 27 20:18:09 2009 From: richard-lists at imagecraft.com (Richard Man) Date: Mon Jul 27 21:29:14 2009 Subject: [Icc-mot] ICC12 7.07 BETA1 In-Reply-To: <5CC8D9FF8F1545E683F01CD85D1DF436@edvardo> References: <200907230017.n6N0Hw77047459@mail.imagecraft.com> <5CC8D9FF8F1545E683F01CD85D1DF436@edvardo> Message-ID: <200907280429.n6S4TCpn022139@mail.imagecraft.com> OK, to solve these (hopefully) last set of problem, the -s2_s12 now looks like this: " -s2_s12: Use S12 mapping to convert S1 to S2 records. \n" " is device flash size in K bytes.", The linker will no longer looks at the address range to try to guess the memory size. Users using Custom Device is advised (via a pop up) that tells them they need to specify -s2xxx by themselves using the "Other Options" box. I will release the next / last beta soon. Unfortunately, I won't have time to tackle XGate memory or the icall this round. However, I have a good solution for XGate and I will push that through at some points. Thanks. At 05:51 AM 7/23/2009, Edward Karpicz wrote: >Seems better. My 99% full D64 program now is Ok. But.. > >1) With this code > >#pragma abs_address:0x4000 >int i4 = 0x4444; >#pragma abs_address:0x8000 >int i8 = 0x8888; >#pragma abs_address:0xC000 >int ic = 0xcccc; >#pragma end_abs_address > > >and with Expanded Memory off, for all 32, 64, 128 S12 devices >linker produces this: > >S206 0F8000 4444E2 >S206 0F8000 88885A *** >S206 0FC000 CCCC92 > >With Expanded Memory on, *** line becomes ok for all devices, but >with Expanded Memory off, *** line is valid only for 32k S12. >In other words, nonpaged apps can't use 8000.BFFF with this beda, >but when I make Expanded Memory on, bingo, S1->S2 mapping starts >working for all devices. It should be opposite! Nonpaged apps >require device size dependend remapping of nonpaged 8000.BFFF, and >paged apps don't use nonpaged 8000.BFFF. > > >1a) Custom setup. Aha, it seems you are using lower end of paged >memory to calculate where to to remap nonpaged 8000.BFFF. But this >remapping, like in p1, has reversed Expanded Memory Enable checkbox >logics. 8000.BFFF should be remapped when Expanded Memory is off, or >even always (because paged apps don't use nonpaged addresses 8000.bfff). > > > >2) A little concern about requirements for bottom and top of areas. >I managed to get this: >!E (1156): S12 device must use linear address for expanded memory. > >It seems to happen when bottom of Expanded Memory setting is not >0x80000/0xC0000/0xE0000/0xF0000/0xF8000, right? >I don't mind, while my application works. But could you enlighten >what are requirements for top and bottom addresses of all standard >areas, please? > > >I've one 99%+ full D64 app. It has not just text or just extcode >areas full, but it really fills D64 with almost no free bytes. I had >to adjust top of paged area and bottom of fragmented text area to >make it working. Also it enables checks for preventing possible >paged/nonpaged memory overlap. My custom settings are these: > >Expanded memory - 0xF0000.0xFA6FF >Text area setting is 0x6700.0x7FFF:0xC000.0xECFF >and above nonpaged ECFF there are idata and bootloader > >My concern is about requirements for top and bottom addresses. >Requirement for 32k/64k/128k.. aligned bottom of expanded S12 memory >is probably OK, but are there more requirements? S12X seem to not >have this requirement, am I right? > > > > >Edward > > // richard // photo book: http://www.blurb.com/bookstore/detail/745963 From richard at imagecraft.com Tue Jul 28 02:08:29 2009 From: richard at imagecraft.com (Richard Man) Date: Tue Jul 28 03:19:37 2009 Subject: [Icc-mot] last ICC12 7.07 beta Message-ID: <200907281019.n6SAJYEI033384@mail.imagecraft.com> http://www.imagecraft.com/pub/iccv712_v707_beta2.exe Will release this soon. Need to finish the doc changes. IDE - Much faster startup time for the IDE - IDE now keeps a "Build Number" for each project. This is passed to the linker and emitted to the top of the .mp map file. - Added -D__BUILD for the Build Number. - Changed -D__ICC_VERSION=XXX where XXX is the version in integer form, e.g. 707. This allows easier conditional compilation. - Added %v (version) and %b (build number) to the macro chars for the "Execute Before Build" and "Execute After Successful Build" command box. - Overhauled the expanded memory settings. - Fixed RAM start address for S12XDP512 - Modified the "checking" options, now they are "Strict Checking" (equivalent to -A command line switch). "ANSI C Portability Conformance Checking" (equivalent to -A -A). This does draconian check on conditions that exceed ANSI C minimum limits (e.g. less than 512 variables) and is usually not needed. - Added Tools->EnvOptions->General->BackupPolicy. The choices are == Unlimied (in BACKUP\ directory) == One Only (in BACKUP\ directory) - Under some rare conditions, the compiler sometimes generated bad code (assertion from the assembler) if a function uses floating point expressions in a function call. Compiler - The compiler was miscounting some instruction sizes and was generating short branches when long branches are needed and caused the assembler to assert with error. - Added #pragma warning warning message emits warning message, similar to #warning #pragma ignore_unused_var name1 name2 ... This must appear inside a function and specifies the named arguments are intentionally unused so no warning message should be generated for them. Linker - Overhauled the expanded memory support. The goal is to eliminate needing to use P&E Log2Phy or SrecCVT to convert our output. The following flags are now supported: -s2_s1 Use a mix of S1 and S2 records (CPU12 only) -s2_cpu Use CPU addresses for the S2 records -s2_s12: Use S12 mapping to convert S1 to S2 records. is in K bytes. -s2_s12x Use S12X mapping to convert S1 to S2 records This means that for the CPUS12 and S12X, only S2 records will be generated, either as CPU/Banked addresses, or in the "native" linear / global address format. The .DBG file uses CPU addresses, as before. See Help file for details (not yet done for BETA release). // richard blog: // mailing list: http://www.dragonsgate.net/mailman/listinfo // photo book: http://www.blurb.com/bookstore/detail/745963 [ For technical support on ImageCraft products, please include all previous replies in your msgs. ] From robmilne at web.net Tue Jul 28 20:18:52 2009 From: robmilne at web.net (Rob Milne) Date: Tue Jul 28 21:23:10 2009 Subject: [Icc-mot] last ICC12 7.07 beta In-Reply-To: <200907281019.n6SAJYEI033384@mail.imagecraft.com> References: <200907281019.n6SAJYEI033384@mail.imagecraft.com> Message-ID: <4A6FBF9C.4050709@web.net> Hi Richard, The -s2_s12: flag is working well for my project and it is great news to finally eject SRecCvt.exe, however my trusty old sreccvt command did have the advantage of building a file with a longer fixed line length (+ 0xFF padding). The new file loads fine via my CAN bootloader but the advantage of the old file format was quicker uploads (902 lines instead of 2270). Is setting output file line length a feature that you can add? Also I just discovered the -dinitrm:0xXX flag - thanks! I've had to rebuild crt.o for every release up until now. -rob Richard Man wrote: > http://www.imagecraft.com/pub/iccv712_v707_beta2.exe > > Will release this soon. Need to finish the doc changes. > > IDE > - Much faster startup time for the IDE > - IDE now keeps a "Build Number" for each project. This is passed to > the linker and emitted to the top of the .mp map file. > - Added -D__BUILD for the Build Number. > - Changed -D__ICC_VERSION=XXX where XXX is the version in integer > form, > e.g. 707. This allows easier conditional compilation. > - Added %v (version) and %b (build number) to the macro chars for > the "Execute Before Build" and "Execute After Successful Build" > command box. > - Overhauled the expanded memory settings. > - Fixed RAM start address for S12XDP512 > - Modified the "checking" options, now they are > "Strict Checking" (equivalent to -A command line switch). > "ANSI C Portability Conformance Checking" (equivalent to -A -A). > This does draconian check on conditions that exceed ANSI C minimum > limits (e.g. less than 512 variables) and is usually not needed. > - Added Tools->EnvOptions->General->BackupPolicy. The choices are > == Unlimied (in BACKUP\ directory) > == One Only (in BACKUP\ directory) > - Under some rare conditions, the compiler sometimes generated bad > code > (assertion from the assembler) if a function uses floating point > expressions in a function call. > > Compiler > - The compiler was miscounting some instruction sizes and was > generating short branches when long branches are needed and caused > the assembler to assert with error. > - Added > #pragma warning warning message > emits warning message, similar to #warning > > #pragma ignore_unused_var name1 name2 ... > This must appear inside a function and specifies the named > arguments > are intentionally unused so no warning message should be generated > for them. > > Linker > - Overhauled the expanded memory support. The goal is to eliminate > needing to use P&E Log2Phy or SrecCVT to convert our output. The > following flags are now supported: > > -s2_s1 Use a mix of S1 and S2 records (CPU12 only) > -s2_cpu Use CPU addresses for the S2 records > -s2_s12: Use S12 mapping to convert S1 to S2 records. > is in K bytes. > -s2_s12x Use S12X mapping to convert S1 to S2 records > > This means that for the CPUS12 and S12X, only S2 records will be > generated, either as CPU/Banked addresses, or in the "native" > linear / global address format. > > The .DBG file uses CPU addresses, as before. > > See Help file for details (not yet done for BETA release). > > > > // richard blog: > > // mailing list: http://www.dragonsgate.net/mailman/listinfo > // photo book: http://www.blurb.com/bookstore/detail/745963 > [ 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 richard-lists at imagecraft.com Tue Jul 28 22:55:02 2009 From: richard-lists at imagecraft.com (Richard Man) Date: Wed Jul 29 00:06:12 2009 Subject: [Icc-mot] last ICC12 7.07 beta In-Reply-To: <4A6FBF9C.4050709@web.net> References: <200907281019.n6SAJYEI033384@mail.imagecraft.com> <4A6FBF9C.4050709@web.net> Message-ID: <200907290706.n6T76BAw063025@mail.imagecraft.com> At 08:18 PM 7/28/2009, you wrote: >Hi Richard, > >The -s2_s12: flag is working well for my project and it is >great news to finally eject SRecCvt.exe, however my trusty old >sreccvt command did have the advantage of building a file with a >longer fixed line length (+ 0xFF padding). The new file loads fine >via my CAN bootloader but the advantage of the old file format was >quicker uploads (902 lines instead of 2270). Is setting output file >line length a feature that you can add? My initial goal was to add that support, but that requires a lot more work than I have time for currently. Sorry, next release. I think there are simple s-record reformatter out there? >Also I just discovered the -dinitrm:0xXX flag - thanks! I've had to >rebuild crt.o for every release up until now. Cool eh? >-rob > >Richard Man wrote: >>http://www.imagecraft.com/pub/iccv712_v707_beta2.exe >> >>Will release this soon. Need to finish the doc changes. >> >> IDE >> - Much faster startup time for the IDE >> - IDE now keeps a "Build Number" for each project. This is passed to >> the linker and emitted to the top of the .mp map file. >> - Added -D__BUILD for the Build Number. >> - Changed -D__ICC_VERSION=XXX where XXX is the version in integer form, >> e.g. 707. This allows easier conditional compilation. >> - Added %v (version) and %b (build number) to the macro chars for >> the "Execute Before Build" and "Execute After Successful Build" >> command box. >> - Overhauled the expanded memory settings. >> - Fixed RAM start address for S12XDP512 >> - Modified the "checking" options, now they are >> "Strict Checking" (equivalent to -A command line switch). >> "ANSI C Portability Conformance Checking" (equivalent to -A -A). >> This does draconian check on conditions that exceed ANSI C minimum >> limits (e.g. less than 512 variables) and is usually not needed. >> - Added Tools->EnvOptions->General->BackupPolicy. The choices are >> == Unlimied (in BACKUP\ directory) >> == One Only (in BACKUP\ directory) >> - Under some rare conditions, the compiler sometimes generated bad code >> (assertion from the assembler) if a function uses floating point >> expressions in a function call. >> >> Compiler >> - The compiler was miscounting some instruction sizes and was >> generating short branches when long branches are needed and caused >> the assembler to assert with error. >> - Added >> #pragma warning warning message >> emits warning message, similar to #warning >> >> #pragma ignore_unused_var name1 name2 ... >> This must appear inside a function and specifies the named arguments >> are intentionally unused so no warning message should be generated >> for them. >> >> Linker >> - Overhauled the expanded memory support. The goal is to eliminate >> needing to use P&E Log2Phy or SrecCVT to convert our output. The >> following flags are now supported: >> >> -s2_s1 Use a mix of S1 and S2 records (CPU12 only) >> -s2_cpu Use CPU addresses for the S2 records >> -s2_s12: Use S12 mapping to convert S1 to S2 records. >> is in K bytes. >> -s2_s12x Use S12X mapping to convert S1 to S2 records >> >> This means that for the CPUS12 and S12X, only S2 records will be >> generated, either as CPU/Banked addresses, or in the "native" >> linear / global address format. >> >> The .DBG file uses CPU addresses, as before. >> >> See Help file for details (not yet done for BETA release). >> >> >> >>// richard blog: >> >>// mailing list: http://www.dragonsgate.net/mailman/listinfo >>// photo book: http://www.blurb.com/bookstore/detail/745963 >>[ 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 >_______________________________________________ >Icc-mot mailing list >Icc-mot@imagecraft.com >http://dragonsgate.net/mailman/listinfo/icc-mot // richard // photo book: http://www.blurb.com/bookstore/detail/745963 From richard at imagecraft.com Thu Jul 30 00:26:43 2009 From: richard at imagecraft.com (Richard Man) Date: Thu Jul 30 01:37:57 2009 Subject: [Icc-mot] ICC12 V7.07 released Message-ID: <200907300837.n6U8bvxm008506@mail.imagecraft.com> CHANGE LOGS: V7.07 - July 30, 2009 IDE - Much faster startup time for the IDE - IDE now keeps a "Build Number" for each project. This is passed to the linker and emitted to the top of the .mp map file. - Added -D__BUILD for the Build Number. - Changed -D__ICC_VERSION=XXX where XXX is the version in integer form, e.g. 707. This allows easier conditional compilation. - Added %v (version) and %b (build number) to the macro chars for the "Execute Before Build" and "Execute After Successful Build" command box. - Overhauled the expanded memory settings. - Fixed RAM start address for S12XDP512 - Modified the "checking" options, now they are "Strict Checking" (equivalent to -A command line switch). "ANSI C Portability Conformance Checking" (equivalent to -A -A). This does draconian check on conditions that exceed ANSI C minimum limits (e.g. less than 512 variables) and is usually not needed. - Added Tools->EnvOptions->General->BackupPolicy. The choices are == Unlimied (in BACKUP\ directory) == One Only (in BACKUP\ directory) - Under some rare conditions, the compiler sometimes generated bad code (assertion from the assembler) if a function uses floating point expressions in a function call. Compiler - The compiler was miscounting some instruction sizes and was generating short branches when long branches are needed and caused the assembler to assert with error. - Added #pragma warning warning message emits warning message, similar to #warning #pragma ignore_unused_var name1 name2 ... This must appear inside a function and specifies the named arguments are intentionally unused so no warning message should be generated for them. Linker - Overhauled the expanded memory support. The goal is to eliminate needing to use P&E Log2Phy or SrecCVT to convert our output. The following flags are now supported: -s2_s1 Use a mix of S1 and S2 records (CPU12 only) -s2_cpu Use CPU addresses for the S2 records -s2_s12: Use S12 mapping to convert S1 to S2 records. is in K bytes. -s2_s12x Use S12X mapping to convert S1 to S2 records This means that for the CPUS12 and S12X, only S2 records will be generated, either as CPU/Banked addresses, or in the "native" linear / global address format. The .DBG file uses CPU addresses, as before. See Help file for details (not yet done for BETA release). // richard blog: // mailing list: http://www.dragonsgate.net/mailman/listinfo // photo book: http://www.blurb.com/bookstore/detail/745963 [ For technical support on ImageCraft products, please include all previous replies in your msgs. ]