From richard at imagecraft.com Wed Apr 2 23:56:41 2008 From: richard at imagecraft.com (Richard Man) Date: Wed Apr 2 23:59:08 2008 Subject: [Icc-mot] eBox-AVR, a complete AVR kit Message-ID: <200804030759.m337x66v034939@mail.imagecraft.com> Know anyone starting with embedded design? Know any school that needs a complete embedded kit for their courses? Want to help support ImageCraft? Introducing eBox-AVR, a complete kit with an AVR ATMega16, keypad, LED, LCD and 10 example projects, even comes with a battery. To purchase and look at the amazingly cute yellow top tub it comes in, go to our website www.imagecraft.com, then click on Hardware, then "ImageCraft eBox" button. Thank you. // richard From genenorris at spotengineering.com Fri Apr 4 06:55:49 2008 From: genenorris at spotengineering.com (Gene Norris) Date: Fri Apr 4 07:55:59 2008 Subject: [Icc-mot] Interesting Optimizations Message-ID: <47F64175.4020603@spotengineering.com> Richard, Am I getting the correct results here? ; unsigned crc_calculation(unsigned irrelevant, unsigned useless) 1662 ; { 1662 .dbline 1231 1662 ; unsigned i, j, k; 1662 ; 1662 ; i = j = 0x0011; 1662 1800820011 movw #17,2,S 1667 1800840011 movw #17,4,S 166C .dbline 1232 166C ; i = i << 8; 166C EC84 ldd 4,S // D = 0x0011 166E B710 tfr B,A // D = 0x1111 1670 C7 clrb // D = 0x1100 1671 B746 tfr D,Y // Worked! 1673 6D84 sty 4,S // Back in original location 1675 .dbline 1233 1675 ; i = (i << 8) + 1; 1675 A684 ldaa 4,S // D = 0x1100 (from above) 1677 C601 ldab #1 // D = 0x1101 (?!) 1679 B746 tfr D,Y // Fast? (but wrong) 167B 6D84 sty 4,S // Back to original spot 167D .dbline 1234 167D ; j = (j << 8) | 2; 167D A682 ldaa 2,S // D = 0x0001, ldaa 3,s? 167F C602 ldab #2 // D = 0x0002, oops 1681 B746 tfr D,Y // Faster, but curiously, 1683 6C82 std 2,S // drastically incorrect 1685 .dbline -2 From ekarpicz at freemail.lt Fri Apr 4 08:42:07 2008 From: ekarpicz at freemail.lt (Edward Karpicz) Date: Fri Apr 4 09:42:23 2008 Subject: [Icc-mot] Interesting Optimizations References: <47F64175.4020603@spotengineering.com> Message-ID: <000601c89672$d78b06f0$a300a8c0@REKS> Hi Gene > ; unsigned crc_calculation(unsigned irrelevant, unsigned useless) > 1662 ; { > 1662 .dbline 1231 > 1662 ; unsigned i, j, k; > 1662 ; > > 1662 ; i = j = 0x0011; > 1662 1800820011 movw #17,2,S > 1667 1800840011 movw #17,4,S > 166C .dbline 1232 > > 166C ; i = i << 8; > 166C EC84 ldd 4,S // D = 0x0011 All right, except it's not very optimal. If compiler wasn't using MOVW initializing i and j, but load-store instructions, then it could save on loading i into register. > 166E B710 tfr B,A // D = 0x1111 > 1670 C7 clrb // D = 0x1100 > 1671 B746 tfr D,Y // Worked! > 1673 6D84 sty 4,S // Back in original location > 1675 .dbline 1233 All right, except that it isn't necessary to move D to Y first, then store Y to i. But generated code is correct. > > 1675 ; i = (i << 8) + 1; > 1675 A684 ldaa 4,S // D = 0x1100 (from above) > 1677 C601 ldab #1 // D = 0x1101 (?!) > 1679 B746 tfr D,Y // Fast? (but wrong) > 167B 6D84 sty 4,S // Back to original spot > 167D .dbline 1234 Why wrong? It's OK. As seen from i = i << 8 case, i is stack local var at 4,S. Since A is upper half of D register, we can optimize regD<<8 by loading A with highbyte(i), right? Since shift left zeroes least bits, we can replace +1 with load B with #1. Try adding something bigger than 255 and compiler will generate different code. > > 167D ; j = (j << 8) | 2; > 167D A682 ldaa 2,S // D = 0x0001, ldaa 3,s? It's loading hibyte of D, that's why 2,s. It optimizes <<8 by loading right bits to right 8bit register. > 167F C602 ldab #2 // D = 0x0002, oops > 1681 B746 tfr D,Y // Faster, but curiously, > 1683 6C82 std 2,S // drastically incorrect > 1685 .dbline -2 > Why incorrect? Regards Edward From genenorris at spotengineering.com Fri Apr 4 09:20:28 2008 From: genenorris at spotengineering.com (Gene Norris) Date: Fri Apr 4 10:20:43 2008 Subject: [Icc-mot] Interesting Optimizations In-Reply-To: <000601c89672$d78b06f0$a300a8c0@REKS> References: <47F64175.4020603@spotengineering.com> <000601c89672$d78b06f0$a300a8c0@REKS> Message-ID: <47F6635C.4060700@spotengineering.com> Hello Edward, Edward Karpicz wrote: > Hi Gene > >> ; unsigned crc_calculation(unsigned irrelevant, unsigned useless) >> 1662 ; { >> 1662 .dbline 1231 >> 1662 ; unsigned i, j, k; >> 1662 ; >> >> 1662 ; i = j = 0x0011; >> 1662 1800820011 movw #17,2,S >> 1667 1800840011 movw #17,4,S >> 166C .dbline 1232 >> >> 166C ; i = i << 8; >> 166C EC84 ldd 4,S // D = 0x0011 > > All right, except it's not very optimal. If compiler wasn't using MOVW > initializing i and j, but load-store instructions, then it could save on > loading i into register. > >> 166E B710 tfr B,A // D = 0x1111 >> 1670 C7 clrb // D = 0x1100 >> 1671 B746 tfr D,Y // Worked! >> 1673 6D84 sty 4,S // Back in original location >> 1675 .dbline 1233 > > All right, except that it isn't necessary to move D to Y first, then > store Y to i. But generated code is correct. Yes, I didn't want to muddy the waters though. > > >> >> 1675 ; i = (i << 8) + 1; >> 1675 A684 ldaa 4,S // D = 0x1100 (from above) >> 1677 C601 ldab #1 // D = 0x1101 (?!) >> 1679 B746 tfr D,Y // Fast? (but wrong) >> 167B 6D84 sty 4,S // Back to original spot >> 167D .dbline 1234 > > Why wrong? It's OK. As seen from i = i << 8 case, i is stack local var > at 4,S. Since A is upper half of D register, we can optimize regD<<8 by > loading A with highbyte(i), right? Since shift left zeroes least bits, > we can replace +1 with load B with #1. Try adding something bigger than > 255 and compiler will generate different code. It is loading the highbyte of D with the high byte of j, it should be loading the highbyte of D with the low byte of j [That is (j << 8)]. HC12s are big-endian, I'm not sure where you are confused. i = 0x1100 i = (i << 8) + 1; Result is 0x1101, result should be 0x0001 > > >> >> 167D ; j = (j << 8) | 2; >> 167D A682 ldaa 2,S // D = 0x0001, ldaa 3,s? > > It's loading hibyte of D, that's why 2,s. It optimizes <<8 by loading > right bits to right 8bit register. It is loading the highbyte of D with the high byte of j, it should be loading the highbyte of D with the low byte of j [That is (j << 8)]. It optimizes incorrectly. No 8 bit shift occurs in either example. Only the lowbyte is correct. > >> 167F C602 ldab #2 // D = 0x0002, oops >> 1681 B746 tfr D,Y // Faster, but curiously, >> 1683 6C82 std 2,S // drastically incorrect >> 1685 .dbline -2 >> > > Why incorrect? j = 0x0011 j = (j << 8) | 2; Result is 0x0002, result should be 0x1102 > > Regards > Edward > > _______________________________________________ > Icc-mot mailing list > Icc-mot@imagecraft.com > http://dragonsgate.net/mailman/listinfo/icc-mot > > > From ekarpicz at freemail.lt Fri Apr 4 09:53:15 2008 From: ekarpicz at freemail.lt (Edward Karpicz) Date: Fri Apr 4 10:53:31 2008 Subject: [Icc-mot] Interesting Optimizations References: <47F64175.4020603@spotengineering.com><000601c89672$d78b06f0$a300a8c0@REKS> <47F6635C.4060700@spotengineering.com> Message-ID: <02de01c8967c$c41b8c70$a300a8c0@REKS> 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 From richard-lists at imagecraft.com Mon Apr 7 00:25:24 2008 From: richard-lists at imagecraft.com (Richard Man) Date: Mon Apr 7 01:28:03 2008 Subject: [Icc-mot] Interesting Optimizations In-Reply-To: <02de01c8967c$c41b8c70$a300a8c0@REKS> References: <47F64175.4020603@spotengineering.com> <000601c89672$d78b06f0$a300a8c0@REKS> <47F6635C.4060700@spotengineering.com> <02de01c8967c$c41b8c70$a300a8c0@REKS> Message-ID: <200804070828.m378S11L069215@mail.imagecraft.com> 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) From willard.a.hall at gm.com Mon Apr 7 07:54:25 2008 From: willard.a.hall at gm.com (willard.a.hall@gm.com) Date: Mon Apr 7 08:54:48 2008 Subject: [Icc-mot] ICC12 Advanced V7.03 bug Message-ID: The code shown needs to do a logical shift right to give me id = 0x0581 The compiler uses an arithmatic shift which wraps the sign bit to give me id = 0xFD81 CANRIDR0 = 0xB0 CANRIDR1 = 0x20 06B9 ; id = ((((I16)(CANRIDR0 << 8)) | ((I16)(CANRIDR1))) >> 5); 06B9 F60161 ldab 0x161 06BC 87 clra 06BD B746 tfr D,Y 06BF C7 clrb 06C0 B60160 ldaa 0x160 06C3 6D80 sty 0,S 06C5 AA80 ora 0,S 06C7 EA81 orb 1,S 06C9 B746 tfr D,Y 06CB CE0005 ldx #5 06CE B764 tfr Y,D 06D0 160000 jsr asr16 06D3 B746 tfr D,Y 06D5 6D83 sty 3,S 06D7 .dbline 269 From genenorris at spotengineering.com Mon Apr 7 09:08:05 2008 From: genenorris at spotengineering.com (Gene Norris) Date: Mon Apr 7 10:08:31 2008 Subject: [Icc-mot] ICC12 Advanced V7.03 bug In-Reply-To: References: Message-ID: <47FA46E5.9090307@spotengineering.com> Willard, The below is not much information, please show your function and the listing (.lis) segment pertinent to this problem. In general, arithmetic shifts are done on signed values and logical on unsigned, so you probably have a sign type problem. Data that is not typed is assumed to be signed... Gene willard.a.hall@gm.com wrote: > > The code shown needs to do a logical shift right to give me id = 0x0581 > The compiler uses an arithmatic shift which wraps the sign bit to give me > id = 0xFD81 > > CANRIDR0 = 0xB0 CANRIDR1 = 0x20 > > > 06B9 ; id = ((((I16)(CANRIDR0 << 8)) | ((I16)(CANRIDR1))) >>> 5); > 06B9 F60161 ldab 0x161 > 06BC 87 clra > 06BD B746 tfr D,Y > 06BF C7 clrb > 06C0 B60160 ldaa 0x160 > 06C3 6D80 sty 0,S > 06C5 AA80 ora 0,S > 06C7 EA81 orb 1,S > 06C9 B746 tfr D,Y > 06CB CE0005 ldx #5 > 06CE B764 tfr Y,D > 06D0 160000 jsr asr16 > 06D3 B746 tfr D,Y > 06D5 6D83 sty 3,S > 06D7 .dbline 269 > > _______________________________________________ > Icc-mot mailing list > Icc-mot@imagecraft.com > http://dragonsgate.net/mailman/listinfo/icc-mot > > > From ekarpicz at freemail.lt Mon Apr 7 10:03:30 2008 From: ekarpicz at freemail.lt (Edward Karpicz) Date: Mon Apr 7 11:03:47 2008 Subject: [Icc-mot] ICC12 Advanced V7.03 bug References: Message-ID: <003301c898d1$5063e550$a300a8c0@REKS> > > > The code shown needs to do a logical shift right to give me id = 0x0581 > The compiler uses an arithmatic shift which wraps the sign bit to give me > id = 0xFD81 > > CANRIDR0 = 0xB0 CANRIDR1 = 0x20 > > > 06B9 ; id = ((((I16)(CANRIDR0 << 8)) | ((I16)(CANRIDR1))) >>> 5); What's I16? Is it signed? Replace I16 with U16 and I guess you'll get desired result. Edward > 06B9 F60161 ldab 0x161 > 06BC 87 clra > 06BD B746 tfr D,Y > 06BF C7 clrb > 06C0 B60160 ldaa 0x160 > 06C3 6D80 sty 0,S > 06C5 AA80 ora 0,S > 06C7 EA81 orb 1,S > 06C9 B746 tfr D,Y > 06CB CE0005 ldx #5 > 06CE B764 tfr Y,D > 06D0 160000 jsr asr16 > 06D3 B746 tfr D,Y > 06D5 6D83 sty 3,S > 06D7 .dbline 269 > > _______________________________________________ > Icc-mot mailing list > Icc-mot@imagecraft.com > http://dragonsgate.net/mailman/listinfo/icc-mot > From willard.a.hall at gm.com Mon Apr 7 10:15:10 2008 From: willard.a.hall at gm.com (willard.a.hall@gm.com) Date: Mon Apr 7 11:15:30 2008 Subject: [Icc-mot] ICC12 Advanced V7.03 bug In-Reply-To: <003301c898d1$5063e550$a300a8c0@REKS> Message-ID: Thanks for the suggestion Edward, I tried changing to an unsigned 16, but the compiler still does a "jsr asr16" Bill "Edward Karpicz" To Sent by: "Discussion List for ICC08/11/12/16 icc-mot-bounces@i users. You do NOT need tosubscribe magecraft.com toicc-announce if you are a member of this." cc 04/07/2008 01:03 PM Subject Re: [Icc-mot] ICC12 Advanced V7.03 bug Please respond to "Discussion List for ICC08/11/12/16 users. You do NOT need to subscribe to icc-announce if you are a member of this." > > > The code shown needs to do a logical shift right to give me id = 0x0581 > The compiler uses an arithmatic shift which wraps the sign bit to give me > id = 0xFD81 > > CANRIDR0 = 0xB0 CANRIDR1 = 0x20 > > > 06B9 ; id = ((((I16)(CANRIDR0 << 8)) | ((I16)(CANRIDR1))) >>> 5); What's I16? Is it signed? Replace I16 with U16 and I guess you'll get desired result. Edward > 06B9 F60161 ldab 0x161 > 06BC 87 clra > 06BD B746 tfr D,Y > 06BF C7 clrb > 06C0 B60160 ldaa 0x160 > 06C3 6D80 sty 0,S > 06C5 AA80 ora 0,S > 06C7 EA81 orb 1,S > 06C9 B746 tfr D,Y > 06CB CE0005 ldx #5 > 06CE B764 tfr Y,D > 06D0 160000 jsr asr16 > 06D3 B746 tfr D,Y > 06D5 6D83 sty 3,S > 06D7 .dbline 269 > > _______________________________________________ > 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 willard.a.hall at gm.com Mon Apr 7 10:23:06 2008 From: willard.a.hall at gm.com (willard.a.hall@gm.com) Date: Mon Apr 7 11:23:27 2008 Subject: [Icc-mot] ICC12 Advanced V7.03 bug In-Reply-To: <47FA46E5.9090307@spotengineering.com> Message-ID: Thanks for the response Gene, the snippet I included is from the .lis file. The code in question is the >> 5 at 06B9 id is an integer 16 and (I16) is a cast to integer16 that is probably not needed but my habit. The call to asr16 at 06D0 should be a rotate if I understand the compiler command >>5 to be a shift right 5 times Bill Gene Norris To Sent by: "Discussion List for ICC08/11/12/16 icc-mot-bounces@i users. You do NOT need to subscribe magecraft.com to icc-announce if you are a member of this." 04/07/2008 12:08 cc PM Subject Re: [Icc-mot] ICC12 Advanced V7.03 Please respond to bug "Discussion List for ICC08/11/12/16 users. You do NOT need to subscribe to icc-announce if you are a member of this." Willard, The below is not much information, please show your function and the listing (.lis) segment pertinent to this problem. In general, arithmetic shifts are done on signed values and logical on unsigned, so you probably have a sign type problem. Data that is not typed is assumed to be signed... Gene willard.a.hall@gm.com wrote: > > The code shown needs to do a logical shift right to give me id = 0x0581 > The compiler uses an arithmatic shift which wraps the sign bit to give me > id = 0xFD81 > > CANRIDR0 = 0xB0 CANRIDR1 = 0x20 > > > 06B9 ; id = ((((I16)(CANRIDR0 << 8)) | ((I16)(CANRIDR1))) >>> 5); > 06B9 F60161 ldab 0x161 > 06BC 87 clra > 06BD B746 tfr D,Y > 06BF C7 clrb > 06C0 B60160 ldaa 0x160 > 06C3 6D80 sty 0,S > 06C5 AA80 ora 0,S > 06C7 EA81 orb 1,S > 06C9 B746 tfr D,Y > 06CB CE0005 ldx #5 > 06CE B764 tfr Y,D > 06D0 160000 jsr asr16 > 06D3 B746 tfr D,Y > 06D5 6D83 sty 3,S > 06D7 .dbline 269 > > _______________________________________________ > 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 ekarpicz at freemail.lt Mon Apr 7 10:35:06 2008 From: ekarpicz at freemail.lt (Edward Karpicz) Date: Mon Apr 7 11:35:24 2008 Subject: [Icc-mot] ICC12 Advanced V7.03 bug References: Message-ID: <003e01c898d5$b96a0c10$a300a8c0@REKS> > Thanks for the suggestion Edward, I tried changing to an unsigned 16, but > the compiler still does a "jsr asr16" > Bill > Then you should check your defines. I tried this, and one case calls asr16, another one lsr16. Please attach your code along with all used defines. #define I16 signed #define U16 unsigned short getid(void) { short id; id = ((((I16)(CAN0RXIDR0 << 8)) | ((I16)(CAN0RXIDR1)))>> 5); id = ((((U16)(CAN0RXIDR0 << 8)) | ((U16)(CAN0RXIDR1)))>> 5); } Edward > > > > "Edward Karpicz" > l.lt> To > Sent by: "Discussion List for ICC08/11/12/16 > icc-mot-bounces@i users. You do NOT need tosubscribe > magecraft.com toicc-announce if you are a member > of this." > cc > 04/07/2008 01:03 > PM Subject > Re: [Icc-mot] ICC12 Advanced V7.03 > bug > Please respond to > "Discussion List > for > ICC08/11/12/16 > users. You do NOT > need to > subscribe to > icc-announce if > you are a member > of this." > ft.com> > > > > > > > > >> >> >> The code shown needs to do a logical shift right to give me id = 0x0581 >> The compiler uses an arithmatic shift which wraps the sign bit to give me >> id = 0xFD81 >> >> CANRIDR0 = 0xB0 CANRIDR1 = 0x20 >> >> >> 06B9 ; id = ((((I16)(CANRIDR0 << 8)) | > ((I16)(CANRIDR1))) >>>> 5); > > > > What's I16? Is it signed? Replace I16 with U16 and I guess you'll get > desired result. > > Edward > > > > >> 06B9 F60161 ldab 0x161 >> 06BC 87 clra >> 06BD B746 tfr D,Y >> 06BF C7 clrb >> 06C0 B60160 ldaa 0x160 >> 06C3 6D80 sty 0,S >> 06C5 AA80 ora 0,S >> 06C7 EA81 orb 1,S >> 06C9 B746 tfr D,Y >> 06CB CE0005 ldx #5 >> 06CE B764 tfr Y,D >> 06D0 160000 jsr asr16 >> 06D3 B746 tfr D,Y >> 06D5 6D83 sty 3,S >> 06D7 .dbline 269 >> >> _______________________________________________ >> 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 > > > _______________________________________________ > Icc-mot mailing list > Icc-mot@imagecraft.com > http://dragonsgate.net/mailman/listinfo/icc-mot > From willard.a.hall at gm.com Mon Apr 7 11:50:22 2008 From: willard.a.hall at gm.com (willard.a.hall@gm.com) Date: Mon Apr 7 12:50:53 2008 Subject: [Icc-mot] ICC12 Advanced V7.03 bug In-Reply-To: <003e01c898d5$b96a0c10$a300a8c0@REKS> Message-ID: Foolish me! I changed the variable id to unsigned, but left the cast signed Thanks for the help Bill "Edward Karpicz" To Sent by: "Discussion List for ICC08/11/12/16 icc-mot-bounces@i users. You do NOT need tosubscribe magecraft.com toicc-announce if you are a member of this." cc 04/07/2008 01:35 PM Subject Re: [Icc-mot] ICC12 Advanced V7.03 bug Please respond to "Discussion List for ICC08/11/12/16 users. You do NOT need to subscribe to icc-announce if you are a member of this." > Thanks for the suggestion Edward, I tried changing to an unsigned 16, but > the compiler still does a "jsr asr16" > Bill > Then you should check your defines. I tried this, and one case calls asr16, another one lsr16. Please attach your code along with all used defines. #define I16 signed #define U16 unsigned short getid(void) { short id; id = ((((I16)(CAN0RXIDR0 << 8)) | ((I16)(CAN0RXIDR1)))>> 5); id = ((((U16)(CAN0RXIDR0 << 8)) | ((U16)(CAN0RXIDR1)))>> 5); } Edward > > > > "Edward Karpicz" > l.lt> To > Sent by: "Discussion List for ICC08/11/12/16 > icc-mot-bounces@i users. You do NOT need tosubscribe > magecraft.com toicc-announce if you are a member > of this." > cc > 04/07/2008 01:03 > PM Subject > Re: [Icc-mot] ICC12 Advanced V7.03 > bug > Please respond to > "Discussion List > for > ICC08/11/12/16 > users. You do NOT > need to > subscribe to > icc-announce if > you are a member > of this." > ft.com> > > > > > > > > >> >> >> The code shown needs to do a logical shift right to give me id = 0x0581 >> The compiler uses an arithmatic shift which wraps the sign bit to give me >> id = 0xFD81 >> >> CANRIDR0 = 0xB0 CANRIDR1 = 0x20 >> >> >> 06B9 ; id = ((((I16)(CANRIDR0 << 8)) | > ((I16)(CANRIDR1))) >>>> 5); > > > > What's I16? Is it signed? Replace I16 with U16 and I guess you'll get > desired result. > > Edward > > > > >> 06B9 F60161 ldab 0x161 >> 06BC 87 clra >> 06BD B746 tfr D,Y >> 06BF C7 clrb >> 06C0 B60160 ldaa 0x160 >> 06C3 6D80 sty 0,S >> 06C5 AA80 ora 0,S >> 06C7 EA81 orb 1,S >> 06C9 B746 tfr D,Y >> 06CB CE0005 ldx #5 >> 06CE B764 tfr Y,D >> 06D0 160000 jsr asr16 >> 06D3 B746 tfr D,Y >> 06D5 6D83 sty 3,S >> 06D7 .dbline 269 >> >> _______________________________________________ >> 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 > > > _______________________________________________ > 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 warm38 at juno.com Tue Apr 8 07:00:08 2008 From: warm38 at juno.com (Wade A Smith) Date: Tue Apr 8 08:02:30 2008 Subject: [Icc-mot] upgrading Message-ID: <20080408.100011.4248.1.warm38@juno.com> We have just about run out of linear access space on the D64, so it looks like we'll be needing to upgrade icc12v7 to the version that handles paging (advanced). We're having a meeting Friday to discuss getting one copy (of the 4 we have) of the upgrade to try it out before we mess up what we have. The production guys are using two copies and they don't want to disturb their procedures. How much of a difference will we see in the upgrade? What differences will there be when we go to compile? I am assuming that we will want to have the interrupt handlers in the 4000-7FFF range (page 3E) to keep the interrupts visible all the time. Or is this a non-issue? wade From ekarpicz at freemail.lt Tue Apr 8 12:02:02 2008 From: ekarpicz at freemail.lt (Edward Karpicz) Date: Tue Apr 8 13:02:21 2008 Subject: [Icc-mot] upgrading References: <20080408.100011.4248.1.warm38@juno.com> Message-ID: <045501c899ab$09bf04b0$a300a8c0@REKS> Wade A Smith wrote: > We have just about run out of linear access space on the D64, so it looks > like we'll be needing to upgrade icc12v7 to the version that handles > paging (advanced). STD should support up to 64k of paged memory: http://www.imagecraft.com/pub/ICCV7_CPU12flyer.pdf BTW did you look at C64/C96/C128 chips? According to the docs these should have more than 48k of linear flash, though I didn't try these myself. > > We're having a meeting Friday to discuss getting one copy (of the 4 we > have) of the upgrade to try it out before we mess up what we have. The > production guys are using two copies and they don't want to disturb their > procedures. Hm, interesting what production guys are doing with compiler and/or IDE. Terminal? Editor? > > How much of a difference will we see in the upgrade? What differences > will there be when we go to compile? > I am assuming that we will want to have the interrupt handlers in the > 4000-7FFF range (page 3E) to keep the interrupts visible all the time. > Or is this a non-issue? Interrupt handlers should be in the 4000-7fff and c000-FEFF. Non-issue since these are automatically put there even if make paged functions default option is on. Edward From warm38 at juno.com Wed Apr 9 12:24:28 2008 From: warm38 at juno.com (Wade A Smith) Date: Wed Apr 9 13:25:52 2008 Subject: [Icc-mot] upgrading Message-ID: <20080409.152432.6080.0.warm38@juno.com> > Wade A Smith wrote: > > > STD should support up to 64k of paged memory: > http://www.imagecraft.com/pub/ICCV7_CPU12flyer.pdf > > BTW did you look at C64/C96/C128 chips? According to the docs these > should > have more than 48k of linear flash, though I didn't try these > myself. Time to test it out.... 2 questions, 1) how do I specify that I want function main() to start at page 3C:8000? Most everything else can go ... wherever. 2) can I use C000-EFFF if F000-FFFF is used by the monitor and we don't wish to disturb that memory (because it loads the rest of flash for us)? We looked at the C chips, but they have NO EEPROM, which is an absolute must. We even have a Delete4bytes+Program2bytes functions that write 1+ bytes to EEPROM. > > We're having a meeting Friday to discuss getting one copy (of the > 4 we > > have) of the upgrade to try it out before we mess up what we have. > The > > production guys are using two copies and they don't want to > disturb their > > procedures. > > Hm, interesting what production guys are doing with compiler and/or > IDE. > Terminal? Editor? Parmameters are set for each unit after calibration, so they go through their procedures for the IDE: modify the parameters; hit the compile button; SrecCvrt; and load it onto the chip. My current version (6 months newer than the production version) of the program uses EEPROM for the parameters. The user interface is currently a serial terminal with no floating point to ASCII (toooo much space used up there), and now I'm working on a LCD menu/button interface. Eventually, production may^H^H^Hwill switch over to one of the user interfaces and the "compile-the-parameters-in" procedure will be changed, freeing up a copy of the compiler (when the EEs get over their fear of multi-file project software to start using the current version of the program instead of their tried-and-tested singular file original, in-house test version I gave them long ago). > > How much of a difference will we see in the upgrade? What > differences > > will there be when we go to compile? > > I am assuming that we will want to have the interrupt handlers in > the > > 4000-7FFF range (page 3E) to keep the interrupts visible all the > time. > > Or is this a non-issue? > > Interrupt handlers should be in the 4000-7fff and c000-FEFF. > Non-issue since > these are automatically put there even if make paged functions > default > option is on. > > Edward Thand, Edward, for the info. From ekarpicz at freemail.lt Wed Apr 9 23:28:33 2008 From: ekarpicz at freemail.lt (Edward Karpicz) Date: Thu Apr 10 00:28:54 2008 Subject: [Icc-mot] upgrading References: <20080409.152432.6080.0.warm38@juno.com> Message-ID: <003001c89ad4$1e356860$0400a8c0@edvardo> Wade A Smith wrote: >> >> STD should support up to 64k of paged memory: >> http://www.imagecraft.com/pub/ICCV7_CPU12flyer.pdf >> >> BTW did you look at C64/C96/C128 chips? According to the docs these >> should >> have more than 48k of linear flash, though I didn't try these >> myself. > > Time to test it out.... > > 2 questions, > 1) how do I specify that I want function main() to start at page 3C:8000? > Most everything else can go ... wherever. By default the same crt.s startup file is used for all configurations, paged and not paged. That's why crt.s always JSRs _main, and compiler always pushes main() into nonpaged memory. You lose some nonpaged memory, but you win the ease of use. You maay easily workaround main occuping nonpaged memory. Just rename your main() into main2() or something like that and call main2() from main(). I assume you checked Expanded memory Enable checkbox and Make Paged Functions Default? If for some reason you don't want Make Paged Default option, then you should use #pragma paged_function main2 to make main2 paged. Do you really need sepcific paged function (main) sitting at absolute paged address (3c:8000)? This would be not easy and is definitely troublesome. > 2) can I use C000-EFFF if F000-FFFF is used by the monitor and we don't > wish to disturb that memory (because it loads the rest of flash for us)? Of course you can use any part of any ppage as you wish. It's absolutely no problem having bootloader or monitor at f000-ffff and use for application c000-Efff or paged 3F:8000-3F:AFFF. Defalut ICC derivative templates are set so if all nonpaged flash 4000-FFFF and alll paged flash was available. As soon as you enable paged memory, there's a page window hole so that nonpaged "text" area setting becomes 0x4000.0x7FFF:0xC000.0xFFFF. If you want to lower upper bound, then you should use custom template and set program memory to 0x4000.0x7FFF:0xC000.0xeFFF. Paged memory setting. D64 template sets paged memory to 0xF0000.0xFFFFF. These figures are linear addresses. The least D64 PPAGE is 0x3C. Multiplying that by size of page window you get 0xF0000. 0x3F*0x4000 + 0x3FFF = 0xFFFFF. Now using pages 0x3E and 0x3F exclusively for nonpaged code, you can limit expanded memory setting to use only pages 3C and 3D: 0xF0000.0xF7FFF. > > We looked at the C chips, but they have NO EEPROM, which is an absolute > must. We even have a Delete4bytes+Program2bytes functions that write 1+ > bytes to EEPROM. > OK. > >> > We're having a meeting Friday to discuss getting one copy (of the >> 4 we >> > have) of the upgrade to try it out before we mess up what we have. >> The >> > production guys are using two copies and they don't want to >> disturb their >> > procedures. >> >> Hm, interesting what production guys are doing with compiler and/or >> IDE. >> Terminal? Editor? > > Parmameters are set for each unit after calibration, so they go through > their procedures for the IDE: modify the parameters; hit the compile > button; SrecCvrt; and load it onto the chip. > My current version (6 months newer than the production version) of the > program uses EEPROM for the parameters. The user interface is currently > a serial terminal with no floating point to ASCII (toooo much space used > up there), and now I'm working on a LCD menu/button interface. > Eventually, production may^H^H^Hwill switch over to one of the user > interfaces and the "compile-the-parameters-in" procedure will be changed, > freeing up a copy of the compiler (when the EEs get over their fear of > multi-file project software to start using the current version of the > program instead of their tried-and-tested singular file original, > in-house test version I gave them long ago). > I see it now, thanks. Edward >> > How much of a difference will we see in the upgrade? What >> differences >> > will there be when we go to compile? >> > I am assuming that we will want to have the interrupt handlers in >> the >> > 4000-7FFF range (page 3E) to keep the interrupts visible all the >> time. >> > Or is this a non-issue? >> >> Interrupt handlers should be in the 4000-7fff and c000-FEFF. >> Non-issue since >> these are automatically put there even if make paged functions >> default >> option is on. >> >> Edward > > Thand, Edward, for the info. > > _______________________________________________ > Icc-mot mailing list > Icc-mot@imagecraft.com > http://dragonsgate.net/mailman/listinfo/icc-mot >