|
Hi Can anyone imagine a way that a modulus operator (%) in the main loop could slow down an ISR? I'm stumped. There's a lot of "div"s in the library function, and two "rtsd"s . I'm using the 6.0.2 CW for 56800E (568357). I turned on Processor Expert to create the project, then turned PE off. Any suggestions or speculation would be appreciated, even if derived from experience with CW 5.1. I had some durable FlexCAN code that broke when I added a modulus operator to my main loop. I just wanted to blink some LEDs so I could see fast TX and RX occur without a scope. The symptom seems to be partial or intermittent blocking of the FlexCAN mailbox interrupt - or possibly slowing down the servicing of that interrupt. If it was only slowing down the main loop, I should never see this symptom. It acts as if it is preventing the FlexCAN ISR from being serviced promptly. I can see a few packets (around 8, instead of 96) go out after a one-second delay that should have fully restored the pool, but despite waiting long enough to TX 7,000 packets, I only find that 8 or so have been clocked out. It seems as if, once this "bad thing" happens, CAN TX is permanently slowed down by a very large factor - maybe around 1,000 times too slow - but not stopped entirely. I normally set up to send almost as fast as the packets can go over the wire. Then I blink an LED every 100 messages (every 300 CAN packets) - in some tests, I also blink other LEDs every 1,000 or 10,000 messages. The symptom is running low on TX packet buffers - as if the ISR is being prevented from running as soon as it should, or as fast as it should. (If the TX ISR ran normally, all the packet buffers would be restored to the pool before I took another 30 buffers out.) Strangely, adding a one-second delay every time I detect "low buffer pool" does not return the chip to full-speed sending, as it should once the pool is full again. Further, the lengths of time it takes to exhaust the pool will be consistent for each test case, but range from 20 seconds to several minutes to overnight. I normally send 30 packets, wait 4 milliseconds, then send another 30. The 4 mSec plus the main loop itself is long enough for the packets to go out - if I count the number of times my ToTxList goes empty, it is equal to the number of batches of packets, so the pool normally gets empty every 4 milliseconds. The test also fails if I run with 10 mSec delays, or 50 mSec - it just takes longer to fail. With the 4 mSec delay and no "%"s, it runs over a weekend. I read the error counters every few packets, and they never exceed "1". I trigger an interrupt and trap on any FCSTATUS error bit. None seen. CODE SAMPLES: Worst case code, with unsigned long, breaks in 20 seconds: if (!(NumMsgsSent % 100)) { LED1_Toggle(); if (!(NumMsgsSent % ONE_K)) { LED2_Toggle(); if (!(NumMsgsSent % TEN_K)) LED3_Toggle(); } } Bad-enough case, even with an unsigned short, it breaks overnight: It also breaks if I use if ( 0 == (NumMsgsSent % 100) ), instead of if (!(NumMsgsSent % 100)) . // not OK with an ushort, either, but it runs for much longer before dying if (!(NumMsgsSent % 100)) LED1_Toggle(); This runs fine overnight, without any "%" modulus: if (NumMsgsSent >= 256) { NumMsgsSent = 0; LED2_Toggle(); } Note that instances of (var % 256) get turned by the compiler into (var & 256), so those don't do any messy math. I've used that for months without problems. LIBRARY CODE, from "mixed source" screen: Here's the asm library function that is JSRed to for if (!(NumMsgsSent % 100)) . I notice that different code is used for % 1,000 or %10,000, but the problem occurs even when I only do % 100 : if (!(NumMsgsSent % 100)) jsr 01238 ARTREMU16Z.asm support/runtime56800E/math_support tst.w y1 ; Check on high bit, should be zero . . . P:00001238: 8F07 tst.w Y1 ; Required carry bit is cleard too! blt High_bit_present ; If bit 15 on, result is either 1 or 0 P:00001239: A51B blt @DummyFn1+0x1d (0x1255) ; 0x000938 P:0000123A: E700 nop lsr16 y0,b ; Copy dividend to b0 no sign extension P:0000123B: 7CD7 lsr16 Y0,B ;;;;;;;;;;;;;;;; 4-bit division ;;;;;;;;;;;;;;;; div y1,b ; form quotient in b0 P:0000123C: 78FF div Y1,B div y1,b P:0000123D: 78FF div Y1,B div y1,b P:0000123E: 78FF div Y1,B div y1,b P:0000123F: 78FF div Y1,B ;;;;;;;;;;;;;;;; 4-bit division ;;;;;;;;;;;;;;;; div y1,b ; form quotient in b0 P:00001240: 78FF div Y1,B div y1,b P:00001241: 78FF div Y1,B div y1,b P:00001242: 78FF div Y1,B div y1,b P:00001243: 78FF div Y1,B ;;;;;;;;;;;;;;;; 4-bit division ;;;;;;;;;;;;;;;; div y1,b ; form quotient in b0 P:00001244: 78FF div Y1,B div y1,b P:00001245: 78FF div Y1,B div y1,b P:00001246: 78FF div Y1,B div y1,b P:00001247: 78FF div Y1,B ;;;;;;;;;;;;;;;; 4-bit division ;;;;;;;;;;;;;;;; div y1,b ; form quotient in b0 P:00001248: 78FF div Y1,B div y1,b P:00001249: 78FF div Y1,B div y1,b P:0000124A: 78FF div Y1,B div y1,b P:0000124B: 78FF div Y1,B ;;;;;;;;;;;;;;;; check sign of quotient and adjust accordingly tst b ; Result sign in N bit of SR P:0000124C: 70BB tst B bge Positive_rem ; if remainder is positive, ok P:0000124D: A403 bge @DummyFn1+0x19 (0x1251) ; 0x00092a P:0000124E: E700 nop Fix_required_remainder: add y1,b ; restored remainder, b is negative P:0000124F: 78F0 add Y1,B P:00001250: E700 nop ; y1-b Positive_rem: rtsd ; delay return after nxt 3 instr P:00001251: E70C rtsd move.w b1,y0 ; move result value into return register P:00001252: 8511 move.w B1,Y0 nop ; filler P:00001253: E700 nop nop ; filler P:00001254: E700 nop ;;;;;;;;;;;;;;; Quotient result is either be 1 (REM = y0-y1) or 0 (REM = y0) High_bit_present: move.w y0,b ; set REM to dividend, y0, for quotient = 0 P:00001255: 8105 move.w Y0,B sub y1,y0 ; REM valid if y0 >= y1 (quotient = 1) P:00001256: 7AF1 sub Y1,Y0 tcc y0,b ; if quotient = 1, REM = y0-y1 P:00001257: 709F tcc Y0,B rtsd ; delay return after nxt 3 instr P:00001258: E70C rtsd move.w b1,y0 ; move REM value into return register P:00001259: 8511 move.w B1,Y0 nop ; filler P:0000125A: E700 nop nop ; filler P:0000125B: E700 nop FWIW, here's what I use for LEDs, borrowed from P.E.: #define LED6_Toggle() (changeRegBits(*GPIO_D_DR,128)) #define LED1_Off() (clrRegBits(*GPIO_C_DR,1)) The inner loop of my delay function reads the timers as often as it can, but does 32-bit arithmetic: while ( NowTick < DoneTick ) TMRD3D2_TICKS_LONG ( NowTick ); where the macro is: #define TMRD3D2_TICKS_LONG( LongVar ) { \ LongVar = (*TMR_D2_CNTR); \ LongVar <<= 16; \ LongVar += (*TMR_D3_HOLD); } Is it conceivable that reading a timer too frequently is somehow stalling an ISR? The HOLD register? Long arithmetic?? Rick Corey Senior Software Engineer DPC Instrument Systems Division |
|
|
modulus (%) affects interrupts?
Started by ●April 5, 2004
Reply by ●April 7, 20042004-04-07
|
I've seen something even worse in an earlier version of Code
Warrior. I was also attempting to do "simple" math in an ISR. The math in my ISR was written as a standard C expression, but the compiler implemented this as a call to a run-time library function. So far, so good ... but the run-time library function was NOT INTERRUPT SAFE! It corrupted registers which manifested itself as random failures in background code. This was a VERY insidious problem and took quite a while to find. William C. Yochum Microwave Data Systems Inc. Principal Eng./Software 175 Science Parkway Phone: (585) 242-8319 Rochester, NY 14620 FAX: (585) 241-5590 USA -----Original Message----- From: Corey, Rick [mailto:] Sent: Monday, April 05, 2004 5:51 PM To: ' Subject: [Bulk E-Mail] [motoroladsp] modulus (%) affects interrupts? Hi Can anyone imagine a way that a modulus operator (%) in the main loop could slow down an ISR? I'm stumped. There's a lot of "div"s in the library function, and two "rtsd"s . I'm using the 6.0.2 CW for 56800E (568357). I turned on Processor Expert to create the project, then turned PE off. Any suggestions or speculation would be appreciated, even if derived from experience with CW 5.1. I had some durable FlexCAN code that broke when I added a modulus operator to my main loop. I just wanted to blink some LEDs so I could see fast TX and RX occur without a scope. The symptom seems to be partial or intermittent blocking of the FlexCAN mailbox interrupt - or possibly slowing down the servicing of that interrupt. If it was only slowing down the main loop, I should never see this symptom. It acts as if it is preventing the FlexCAN ISR from being serviced promptly. I can see a few packets (around 8, instead of 96) go out after a one-second delay that should have fully restored the pool, but despite waiting long enough to TX 7,000 packets, I only find that 8 or so have been clocked out. It seems as if, once this "bad thing" happens, CAN TX is permanently slowed down by a very large factor - maybe around 1,000 times too slow - but not stopped entirely. I normally set up to send almost as fast as the packets can go over the wire. Then I blink an LED every 100 messages (every 300 CAN packets) - in some tests, I also blink other LEDs every 1,000 or 10,000 messages. The symptom is running low on TX packet buffers - as if the ISR is being prevented from running as soon as it should, or as fast as it should. (If the TX ISR ran normally, all the packet buffers would be restored to the pool before I took another 30 buffers out.) Strangely, adding a one-second delay every time I detect "low buffer pool" does not return the chip to full-speed sending, as it should once the pool is full again. Further, the lengths of time it takes to exhaust the pool will be consistent for each test case, but range from 20 seconds to several minutes to overnight. I normally send 30 packets, wait 4 milliseconds, then send another 30. The 4 mSec plus the main loop itself is long enough for the packets to go out - if I count the number of times my ToTxList goes empty, it is equal to the number of batches of packets, so the pool normally gets empty every 4 milliseconds. The test also fails if I run with 10 mSec delays, or 50 mSec - it just takes longer to fail. With the 4 mSec delay and no "%"s, it runs over a weekend. I read the error counters every few packets, and they never exceed "1". I trigger an interrupt and trap on any FCSTATUS error bit. None seen. CODE SAMPLES: Worst case code, with unsigned long, breaks in 20 seconds: if (!(NumMsgsSent % 100)) { LED1_Toggle(); if (!(NumMsgsSent % ONE_K)) { LED2_Toggle(); if (!(NumMsgsSent % TEN_K)) LED3_Toggle(); } } Bad-enough case, even with an unsigned short, it breaks overnight: It also breaks if I use if ( 0 == (NumMsgsSent % 100) ), instead of if (!(NumMsgsSent % 100)) . // not OK with an ushort, either, but it runs for much longer before dying if (!(NumMsgsSent % 100)) LED1_Toggle(); This runs fine overnight, without any "%" modulus: if (NumMsgsSent >= 256) { NumMsgsSent = 0; LED2_Toggle(); } Note that instances of (var % 256) get turned by the compiler into (var & 256), so those don't do any messy math. I've used that for months without problems. LIBRARY CODE, from "mixed source" screen: Here's the asm library function that is JSRed to for if (!(NumMsgsSent % 100)) . I notice that different code is used for % 1,000 or %10,000, but the problem occurs even when I only do % 100 : if (!(NumMsgsSent % 100)) jsr 01238 ARTREMU16Z.asm support/runtime56800E/math_support tst.w y1 ; Check on high bit, should be zero . . . P:00001238: 8F07 tst.w Y1 ; Required carry bit is cleard too! blt High_bit_present ; If bit 15 on, result is either 1 or 0 P:00001239: A51B blt @DummyFn1+0x1d (0x1255) ; 0x000938 P:0000123A: E700 nop lsr16 y0,b ; Copy dividend to b0 no sign extension P:0000123B: 7CD7 lsr16 Y0,B ;;;;;;;;;;;;;;;; 4-bit division ;;;;;;;;;;;;;;;; div y1,b ; form quotient in b0 P:0000123C: 78FF div Y1,B div y1,b P:0000123D: 78FF div Y1,B div y1,b P:0000123E: 78FF div Y1,B div y1,b P:0000123F: 78FF div Y1,B ;;;;;;;;;;;;;;;; 4-bit division ;;;;;;;;;;;;;;;; div y1,b ; form quotient in b0 P:00001240: 78FF div Y1,B div y1,b P:00001241: 78FF div Y1,B div y1,b P:00001242: 78FF div Y1,B div y1,b P:00001243: 78FF div Y1,B ;;;;;;;;;;;;;;;; 4-bit division ;;;;;;;;;;;;;;;; div y1,b ; form quotient in b0 P:00001244: 78FF div Y1,B div y1,b P:00001245: 78FF div Y1,B div y1,b P:00001246: 78FF div Y1,B div y1,b P:00001247: 78FF div Y1,B ;;;;;;;;;;;;;;;; 4-bit division ;;;;;;;;;;;;;;;; div y1,b ; form quotient in b0 P:00001248: 78FF div Y1,B div y1,b P:00001249: 78FF div Y1,B div y1,b P:0000124A: 78FF div Y1,B div y1,b P:0000124B: 78FF div Y1,B ;;;;;;;;;;;;;;;; check sign of quotient and adjust accordingly tst b ; Result sign in N bit of SR P:0000124C: 70BB tst B bge Positive_rem ; if remainder is positive, ok P:0000124D: A403 bge @DummyFn1+0x19 (0x1251) ; 0x00092a P:0000124E: E700 nop Fix_required_remainder: add y1,b ; restored remainder, b is negative P:0000124F: 78F0 add Y1,B P:00001250: E700 nop ; y1-b Positive_rem: rtsd ; delay return after nxt 3 instr P:00001251: E70C rtsd move.w b1,y0 ; move result value into return register P:00001252: 8511 move.w B1,Y0 nop ; filler P:00001253: E700 nop nop ; filler P:00001254: E700 nop ;;;;;;;;;;;;;;; Quotient result is either be 1 (REM = y0-y1) or 0 (REM = y0) High_bit_present: move.w y0,b ; set REM to dividend, y0, for quotient = 0 P:00001255: 8105 move.w Y0,B sub y1,y0 ; REM valid if y0 >= y1 (quotient = 1) P:00001256: 7AF1 sub Y1,Y0 tcc y0,b ; if quotient = 1, REM = y0-y1 P:00001257: 709F tcc Y0,B rtsd ; delay return after nxt 3 instr P:00001258: E70C rtsd move.w b1,y0 ; move REM value into return register P:00001259: 8511 move.w B1,Y0 nop ; filler P:0000125A: E700 nop nop ; filler P:0000125B: E700 nop FWIW, here's what I use for LEDs, borrowed from P.E.: #define LED6_Toggle() (changeRegBits(*GPIO_D_DR,128)) #define LED1_Off() (clrRegBits(*GPIO_C_DR,1)) The inner loop of my delay function reads the timers as often as it can, but does 32-bit arithmetic: while ( NowTick < DoneTick ) TMRD3D2_TICKS_LONG ( NowTick ); where the macro is: #define TMRD3D2_TICKS_LONG( LongVar ) { \ LongVar = (*TMR_D2_CNTR); \ LongVar <<= 16; \ LongVar += (*TMR_D3_HOLD); } Is it conceivable that reading a timer too frequently is somehow stalling an ISR? The HOLD register? Long arithmetic?? Rick Corey Senior Software Engineer DPC Instrument Systems Division _____________________________________ Note: If you do a simple "reply" with your email client, only the author of this message will receive your answer. You need to do a "reply all" if you want your answer to be distributed to the entire group. _____________________________________ About this discussion group: To Join: To Post: To Leave: Archives: http://www.yahoogroups.com/group/motoroladsp <http://www.yahoogroups.com/group/motoroladsp> More Groups: http://www.dsprelated.com/groups.php3 <http://www.dsprelated.com/groups.php3 _____ > . |
Reply by ●April 7, 20042004-04-07
|
Hi
William
Ouch! I thought I read somewhere that simple "multiply" is
a run-time library function. I wish I could recall where I read
that. I see nothing in the "MSL C" doc. I see 13 "multiply"
instructions listed in family RefMan (which makes sense, for a DSP).
IMACUU provides a 32-bit result. Maybe I'm wrong about "*" being a
run-time lib function. Hope so!
The CW
online manual has this to say about "certain computations":
"Intrinsic functions let you pass in data to perform specific
optimized computations. For example, some calculations may be inefficient if
coded in C because the compiler has to follow ANSI C rules to represent data,
and this may cause the program to jump to runtime math routines for certain
computations. In such cases, it probably is better to code these calculations
using assembly language instructions and intrinsic functions.
"
The
intrinsic multiply functions I found were all for fractional math, not
integer.
I
didn't even have the modulus operator in my ISR - it was in the main
loop. I understand that if it isn't thread-safe, some other math in
the ISR could break it ... I would have expected less-repeatable
results.
The
"fanciest" math inside my ISR is:
increment a variable (I think they are
all ushorts, but I'll search for longs)
mask a ushort variable using "var &
mask"
mask-and-shift register contents, then assign to another
variable (for byte-swapping)
mask a register value, then use it in a
comparison
On a
quick look-through, I don't even see any "multiply"s remaining, but I
suppose pointer arithmetic might use one implicitly. I'll look
several more times. I had better look through the ASM produced to
look for calls to lib functions.
I share
your paranoia. Thanks!
Rick
Corey
|
|
|
Reply by ●April 7, 20042004-04-07
|
I tried throwing ISR protection around my "modulus code" but that
didn't help much. It still died, but maybe took a little longer than it used to. I used the P.E. macros : #define __EI0() { asm(bfclr #0x0300,SR); } /* Enable interrupts of level 0,1,2,3 */ #define __EI3() { asm(bfset #0x0300,SR); } /* Enable interrupts of level 3 only (NMI) */ I _think_ that this rules out the theory that the only problem with modulus is that it isn't interrupt-safe ... but what is left? Rick Corey -----Original Message----- From: Yochum, William [mailto:] Sent: Wednesday, April 07, 2004 11:00 AM To: ' Cc: Corey, Rick Subject: [motoroladsp] RE: modulus (%) affects interrupts? I've seen something even worse in an earlier version of Code Warrior. I was also attempting to do "simple" math in an ISR. The math in my ISR was written as a standard C expression, but the compiler implemented this as a call to a run-time library function. So far, so good ... but the run-time library function was NOT INTERRUPT SAFE! It corrupted registers which manifested itself as random failures in background code. This was a VERY insidious problem and took quite a while to find. William C. Yochum Microwave Data Systems Inc. Principal Eng./Software 175 Science Parkway Phone: (585) 242-8319 Rochester, NY 14620 FAX: (585) 241-5590 USA -----Original Message----- From: Corey, Rick [mailto:] Sent: Monday, April 05, 2004 5:51 PM To: ' Subject: [Bulk E-Mail] [motoroladsp] modulus (%) affects interrupts? Hi Can anyone imagine a way that a modulus operator (%) in the main loop could slow down an ISR? I'm stumped. There's a lot of "div"s in the library function, and two "rtsd"s . I'm using the 6.0.2 CW for 56800E (568357). I turned on Processor Expert to create the project, then turned PE off. Any suggestions or speculation would be appreciated, even if derived from experience with CW 5.1. I had some durable FlexCAN code that broke when I added a modulus operator to my main loop. I just wanted to blink some LEDs so I could see fast TX and RX occur without a scope. The symptom seems to be partial or intermittent blocking of the FlexCAN mailbox interrupt - or possibly slowing down the servicing of that interrupt. If it was only slowing down the main loop, I should never see this symptom. It acts as if it is preventing the FlexCAN ISR from being serviced promptly. I can see a few packets (around 8, instead of 96) go out after a one-second delay that should have fully restored the pool, but despite waiting long enough to TX 7,000 packets, I only find that 8 or so have been clocked out. It seems as if, once this "bad thing" happens, CAN TX is permanently slowed down by a very large factor - maybe around 1,000 times too slow - but not stopped entirely. I normally set up to send almost as fast as the packets can go over the wire. Then I blink an LED every 100 messages (every 300 CAN packets) - in some tests, I also blink other LEDs every 1,000 or 10,000 messages. The symptom is running low on TX packet buffers - as if the ISR is being prevented from running as soon as it should, or as fast as it should. (If the TX ISR ran normally, all the packet buffers would be restored to the pool before I took another 30 buffers out.) Strangely, adding a one-second delay every time I detect "low buffer pool" does not return the chip to full-speed sending, as it should once the pool is full again. Further, the lengths of time it takes to exhaust the pool will be consistent for each test case, but range from 20 seconds to several minutes to overnight. I normally send 30 packets, wait 4 milliseconds, then send another 30. The 4 mSec plus the main loop itself is long enough for the packets to go out - if I count the number of times my ToTxList goes empty, it is equal to the number of batches of packets, so the pool normally gets empty every 4 milliseconds. The test also fails if I run with 10 mSec delays, or 50 mSec - it just takes longer to fail. With the 4 mSec delay and no "%"s, it runs over a weekend. I read the error counters every few packets, and they never exceed "1". I trigger an interrupt and trap on any FCSTATUS error bit. None seen. CODE SAMPLES: Worst case code, with unsigned long, breaks in 20 seconds: if (!(NumMsgsSent % 100)) { LED1_Toggle(); if (!(NumMsgsSent % ONE_K)) { LED2_Toggle(); if (!(NumMsgsSent % TEN_K)) LED3_Toggle(); } } Bad-enough case, even with an unsigned short, it breaks overnight: It also breaks if I use if ( 0 == (NumMsgsSent % 100) ), instead of if (!(NumMsgsSent % 100)) . // not OK with an ushort, either, but it runs for much longer before dying if (!(NumMsgsSent % 100)) LED1_Toggle(); This runs fine overnight, without any "%" modulus: if (NumMsgsSent >= 256) { NumMsgsSent = 0; LED2_Toggle(); } Note that instances of (var % 256) get turned by the compiler into (var & 256), so those don't do any messy math. I've used that for months without problems. LIBRARY CODE, from "mixed source" screen: Here's the asm library function that is JSRed to for if (!(NumMsgsSent % 100)) . I notice that different code is used for % 1,000 or %10,000, but the problem occurs even when I only do % 100 : if (!(NumMsgsSent % 100)) jsr 01238 ARTREMU16Z.asm support/runtime56800E/math_support tst.w y1 ; Check on high bit, should be zero . . . P:00001238: 8F07 tst.w Y1 ; Required carry bit is cleard too! blt High_bit_present ; If bit 15 on, result is either 1 or 0 P:00001239: A51B blt @DummyFn1+0x1d (0x1255) ; 0x000938 P:0000123A: E700 nop lsr16 y0,b ; Copy dividend to b0 no sign extension P:0000123B: 7CD7 lsr16 Y0,B ;;;;;;;;;;;;;;;; 4-bit division ;;;;;;;;;;;;;;;; div y1,b ; form quotient in b0 P:0000123C: 78FF div Y1,B div y1,b P:0000123D: 78FF div Y1,B div y1,b P:0000123E: 78FF div Y1,B div y1,b P:0000123F: 78FF div Y1,B ;;;;;;;;;;;;;;;; 4-bit division ;;;;;;;;;;;;;;;; div y1,b ; form quotient in b0 P:00001240: 78FF div Y1,B div y1,b P:00001241: 78FF div Y1,B div y1,b P:00001242: 78FF div Y1,B div y1,b P:00001243: 78FF div Y1,B ;;;;;;;;;;;;;;;; 4-bit division ;;;;;;;;;;;;;;;; div y1,b ; form quotient in b0 P:00001244: 78FF div Y1,B div y1,b P:00001245: 78FF div Y1,B div y1,b P:00001246: 78FF div Y1,B div y1,b P:00001247: 78FF div Y1,B ;;;;;;;;;;;;;;;; 4-bit division ;;;;;;;;;;;;;;;; div y1,b ; form quotient in b0 P:00001248: 78FF div Y1,B div y1,b P:00001249: 78FF div Y1,B div y1,b P:0000124A: 78FF div Y1,B div y1,b P:0000124B: 78FF div Y1,B ;;;;;;;;;;;;;;;; check sign of quotient and adjust accordingly tst b ; Result sign in N bit of SR P:0000124C: 70BB tst B bge Positive_rem ; if remainder is positive, ok P:0000124D: A403 bge @DummyFn1+0x19 (0x1251) ; 0x00092a P:0000124E: E700 nop Fix_required_remainder: add y1,b ; restored remainder, b is negative P:0000124F: 78F0 add Y1,B P:00001250: E700 nop ; y1-b Positive_rem: rtsd ; delay return after nxt 3 instr P:00001251: E70C rtsd move.w b1,y0 ; move result value into return register P:00001252: 8511 move.w B1,Y0 nop ; filler P:00001253: E700 nop nop ; filler P:00001254: E700 nop ;;;;;;;;;;;;;;; Quotient result is either be 1 (REM = y0-y1) or 0 (REM = y0) High_bit_present: move.w y0,b ; set REM to dividend, y0, for quotient = 0 P:00001255: 8105 move.w Y0,B sub y1,y0 ; REM valid if y0 >= y1 (quotient = 1) P:00001256: 7AF1 sub Y1,Y0 tcc y0,b ; if quotient = 1, REM = y0-y1 P:00001257: 709F tcc Y0,B rtsd ; delay return after nxt 3 instr P:00001258: E70C rtsd move.w b1,y0 ; move REM value into return register P:00001259: 8511 move.w B1,Y0 nop ; filler P:0000125A: E700 nop nop ; filler P:0000125B: E700 nop FWIW, here's what I use for LEDs, borrowed from P.E.: #define LED6_Toggle() (changeRegBits(*GPIO_D_DR,128)) #define LED1_Off() (clrRegBits(*GPIO_C_DR,1)) The inner loop of my delay function reads the timers as often as it can, but does 32-bit arithmetic: while ( NowTick < DoneTick ) TMRD3D2_TICKS_LONG ( NowTick ); where the macro is: #define TMRD3D2_TICKS_LONG( LongVar ) { \ LongVar = (*TMR_D2_CNTR); \ LongVar <<= 16; \ LongVar += (*TMR_D3_HOLD); } Is it conceivable that reading a timer too frequently is somehow stalling an ISR? The HOLD register? Long arithmetic?? Rick Corey Senior Software Engineer DPC Instrument Systems Division _____________________________________ Note: If you do a simple "reply" with your email client, only the author of this message will receive your answer. You need to do a "reply all" if you want your answer to be distributed to the entire group. _____________________________________ About this discussion group: To Join: To Post: To Leave: Archives: http://www.yahoogroups.com/group/motoroladsp <http://www.yahoogroups.com/group/motoroladsp> More Groups: http://www.dsprelated.com/groups.php3 <http://www.dsprelated.com/groups.php3 _____ > . _____________________________________ Note: If you do a simple "reply" with your email client, only the author of this message will receive your answer. You need to do a "reply all" if you want your answer to be distributed to the entire group. _____________________________________ About this discussion group: To Join: To Post: To Leave: Archives: http://www.yahoogroups.com/group/motoroladsp More Groups: http://www.dsprelated.com/groups.php3 Yahoo! Groups Links |
Reply by ●April 7, 20042004-04-07
|
FWIW, I just noticed that my #defined constants for "ONE_K" and
"TEN_K" were #defined as longs ... so the problem I saw may have been with modulus-for-longs. I've run for 5-8 minutes at a time just now with ushorts ... will try overnight. Rick Corey -----Original Message----- From: Corey, Rick Sent: Wednesday, April 07, 2004 3:20 PM To: 'Yochum, William'; ' Cc: Corey, Rick Subject: RE: [motoroladsp] RE: modulus (%) affects interrupts? I tried throwing ISR protection around my "modulus code" but that didn't help much. It still died, but maybe took a little longer than it used to. I used the P.E. macros : #define __EI0() { asm(bfclr #0x0300,SR); } /* Enable interrupts of level 0,1,2,3 */ #define __EI3() { asm(bfset #0x0300,SR); } /* Enable interrupts of level 3 only (NMI) */ I _think_ that this rules out the theory that the only problem with modulus is that it isn't interrupt-safe ... but what is left? Rick Corey -----Original Message----- From: Yochum, William [mailto:] Sent: Wednesday, April 07, 2004 11:00 AM To: ' Cc: Corey, Rick Subject: [motoroladsp] RE: modulus (%) affects interrupts? I've seen something even worse in an earlier version of Code Warrior. I was also attempting to do "simple" math in an ISR. The math in my ISR was written as a standard C expression, but the compiler implemented this as a call to a run-time library function. So far, so good ... but the run-time library function was NOT INTERRUPT SAFE! It corrupted registers which manifested itself as random failures in background code. This was a VERY insidious problem and took quite a while to find. William C. Yochum Microwave Data Systems Inc. Principal Eng./Software 175 Science Parkway Phone: (585) 242-8319 Rochester, NY 14620 FAX: (585) 241-5590 USA -----Original Message----- From: Corey, Rick [mailto:] Sent: Monday, April 05, 2004 5:51 PM To: ' Subject: [Bulk E-Mail] [motoroladsp] modulus (%) affects interrupts? Hi Can anyone imagine a way that a modulus operator (%) in the main loop could slow down an ISR? I'm stumped. There's a lot of "div"s in the library function, and two "rtsd"s . I'm using the 6.0.2 CW for 56800E (568357). I turned on Processor Expert to create the project, then turned PE off. Any suggestions or speculation would be appreciated, even if derived from experience with CW 5.1. I had some durable FlexCAN code that broke when I added a modulus operator to my main loop. I just wanted to blink some LEDs so I could see fast TX and RX occur without a scope. The symptom seems to be partial or intermittent blocking of the FlexCAN mailbox interrupt - or possibly slowing down the servicing of that interrupt. If it was only slowing down the main loop, I should never see this symptom. It acts as if it is preventing the FlexCAN ISR from being serviced promptly. I can see a few packets (around 8, instead of 96) go out after a one-second delay that should have fully restored the pool, but despite waiting long enough to TX 7,000 packets, I only find that 8 or so have been clocked out. It seems as if, once this "bad thing" happens, CAN TX is permanently slowed down by a very large factor - maybe around 1,000 times too slow - but not stopped entirely. I normally set up to send almost as fast as the packets can go over the wire. Then I blink an LED every 100 messages (every 300 CAN packets) - in some tests, I also blink other LEDs every 1,000 or 10,000 messages. The symptom is running low on TX packet buffers - as if the ISR is being prevented from running as soon as it should, or as fast as it should. (If the TX ISR ran normally, all the packet buffers would be restored to the pool before I took another 30 buffers out.) Strangely, adding a one-second delay every time I detect "low buffer pool" does not return the chip to full-speed sending, as it should once the pool is full again. Further, the lengths of time it takes to exhaust the pool will be consistent for each test case, but range from 20 seconds to several minutes to overnight. I normally send 30 packets, wait 4 milliseconds, then send another 30. The 4 mSec plus the main loop itself is long enough for the packets to go out - if I count the number of times my ToTxList goes empty, it is equal to the number of batches of packets, so the pool normally gets empty every 4 milliseconds. The test also fails if I run with 10 mSec delays, or 50 mSec - it just takes longer to fail. With the 4 mSec delay and no "%"s, it runs over a weekend. I read the error counters every few packets, and they never exceed "1". I trigger an interrupt and trap on any FCSTATUS error bit. None seen. CODE SAMPLES: Worst case code, with unsigned long, breaks in 20 seconds: if (!(NumMsgsSent % 100)) { LED1_Toggle(); if (!(NumMsgsSent % ONE_K)) { LED2_Toggle(); if (!(NumMsgsSent % TEN_K)) LED3_Toggle(); } } Bad-enough case, even with an unsigned short, it breaks overnight: It also breaks if I use if ( 0 == (NumMsgsSent % 100) ), instead of if (!(NumMsgsSent % 100)) . // not OK with an ushort, either, but it runs for much longer before dying if (!(NumMsgsSent % 100)) LED1_Toggle(); This runs fine overnight, without any "%" modulus: if (NumMsgsSent >= 256) { NumMsgsSent = 0; LED2_Toggle(); } Note that instances of (var % 256) get turned by the compiler into (var & 256), so those don't do any messy math. I've used that for months without problems. LIBRARY CODE, from "mixed source" screen: Here's the asm library function that is JSRed to for if (!(NumMsgsSent % 100)) . I notice that different code is used for % 1,000 or %10,000, but the problem occurs even when I only do % 100 : if (!(NumMsgsSent % 100)) jsr 01238 ARTREMU16Z.asm support/runtime56800E/math_support tst.w y1 ; Check on high bit, should be zero . . . P:00001238: 8F07 tst.w Y1 ; Required carry bit is cleard too! blt High_bit_present ; If bit 15 on, result is either 1 or 0 P:00001239: A51B blt @DummyFn1+0x1d (0x1255) ; 0x000938 P:0000123A: E700 nop lsr16 y0,b ; Copy dividend to b0 no sign extension P:0000123B: 7CD7 lsr16 Y0,B ;;;;;;;;;;;;;;;; 4-bit division ;;;;;;;;;;;;;;;; div y1,b ; form quotient in b0 P:0000123C: 78FF div Y1,B div y1,b P:0000123D: 78FF div Y1,B div y1,b P:0000123E: 78FF div Y1,B div y1,b P:0000123F: 78FF div Y1,B ;;;;;;;;;;;;;;;; 4-bit division ;;;;;;;;;;;;;;;; div y1,b ; form quotient in b0 P:00001240: 78FF div Y1,B div y1,b P:00001241: 78FF div Y1,B div y1,b P:00001242: 78FF div Y1,B div y1,b P:00001243: 78FF div Y1,B ;;;;;;;;;;;;;;;; 4-bit division ;;;;;;;;;;;;;;;; div y1,b ; form quotient in b0 P:00001244: 78FF div Y1,B div y1,b P:00001245: 78FF div Y1,B div y1,b P:00001246: 78FF div Y1,B div y1,b P:00001247: 78FF div Y1,B ;;;;;;;;;;;;;;;; 4-bit division ;;;;;;;;;;;;;;;; div y1,b ; form quotient in b0 P:00001248: 78FF div Y1,B div y1,b P:00001249: 78FF div Y1,B div y1,b P:0000124A: 78FF div Y1,B div y1,b P:0000124B: 78FF div Y1,B ;;;;;;;;;;;;;;;; check sign of quotient and adjust accordingly tst b ; Result sign in N bit of SR P:0000124C: 70BB tst B bge Positive_rem ; if remainder is positive, ok P:0000124D: A403 bge @DummyFn1+0x19 (0x1251) ; 0x00092a P:0000124E: E700 nop Fix_required_remainder: add y1,b ; restored remainder, b is negative P:0000124F: 78F0 add Y1,B P:00001250: E700 nop ; y1-b Positive_rem: rtsd ; delay return after nxt 3 instr P:00001251: E70C rtsd move.w b1,y0 ; move result value into return register P:00001252: 8511 move.w B1,Y0 nop ; filler P:00001253: E700 nop nop ; filler P:00001254: E700 nop ;;;;;;;;;;;;;;; Quotient result is either be 1 (REM = y0-y1) or 0 (REM = y0) High_bit_present: move.w y0,b ; set REM to dividend, y0, for quotient = 0 P:00001255: 8105 move.w Y0,B sub y1,y0 ; REM valid if y0 >= y1 (quotient = 1) P:00001256: 7AF1 sub Y1,Y0 tcc y0,b ; if quotient = 1, REM = y0-y1 P:00001257: 709F tcc Y0,B rtsd ; delay return after nxt 3 instr P:00001258: E70C rtsd move.w b1,y0 ; move REM value into return register P:00001259: 8511 move.w B1,Y0 nop ; filler P:0000125A: E700 nop nop ; filler P:0000125B: E700 nop FWIW, here's what I use for LEDs, borrowed from P.E.: #define LED6_Toggle() (changeRegBits(*GPIO_D_DR,128)) #define LED1_Off() (clrRegBits(*GPIO_C_DR,1)) The inner loop of my delay function reads the timers as often as it can, but does 32-bit arithmetic: while ( NowTick < DoneTick ) TMRD3D2_TICKS_LONG ( NowTick ); where the macro is: #define TMRD3D2_TICKS_LONG( LongVar ) { \ LongVar = (*TMR_D2_CNTR); \ LongVar <<= 16; \ LongVar += (*TMR_D3_HOLD); } Is it conceivable that reading a timer too frequently is somehow stalling an ISR? The HOLD register? Long arithmetic?? Rick Corey Senior Software Engineer DPC Instrument Systems Division _____________________________________ Note: If you do a simple "reply" with your email client, only the author of this message will receive your answer. You need to do a "reply all" if you want your answer to be distributed to the entire group. _____________________________________ About this discussion group: To Join: To Post: To Leave: Archives: http://www.yahoogroups.com/group/motoroladsp <http://www.yahoogroups.com/group/motoroladsp> More Groups: http://www.dsprelated.com/groups.php3 <http://www.dsprelated.com/groups.php3 _____ > . _____________________________________ Note: If you do a simple "reply" with your email client, only the author of this message will receive your answer. You need to do a "reply all" if you want your answer to be distributed to the entire group. _____________________________________ About this discussion group: To Join: To Post: To Leave: Archives: http://www.yahoogroups.com/group/motoroladsp More Groups: http://www.dsprelated.com/groups.php3 Yahoo! Groups Links |
Reply by ●April 7, 20042004-04-07
|
HI Rick and William, 32-bit multiply instructions take two 16-bit values and generated a 32-bit result. This is not useful by itself for doing 32x32-bit multiplication. This is why a runtime library is called for. 16-bit math is not done in a library. For 5683xx/5685x we have more instruction support and inline much of these user select "optimize for speed". 5680x and 5682x families have a more limited instruction and registers set here. All FP math is done in a library. (no FPU on the processor) Regarding being ISR safe. This is addressed as long as the routine calling these functions have one of the following: 1. "#pragma interrupt" For use only at top level ISR. Recommended when there are not too many subroutine calls 2. "#pragma interrupt saveall" For use only at top level ISR recommended when there will be many subroutine calls 3. "#pragma interrupt called" for use in case #1. Must be placed on C functions called by interrupt routine (unless saveall option was used) One problem you point out is that the compiler does not emit an error if pragma in case 3 is left off. We don not have a solution to offer this shortcoming. If its not guarded by these #pragma's it will clobber volatile registers used by the library. This ABI approach is a solid performance tradeoffs. We have many volatile registers because, it would really slow things down if more were treated as non-volatile. > Hi William > > Ouch! I thought I read somewhere that simple "multiply" is a run-time > library function. I wish I could recall where I read that. I see nothing > in the "MSL C" doc. I see 13 "multiply" instructions listed in family > RefMan (which makes sense, for a DSP). IMACUU provides a 32-bit result. > Maybe I'm wrong about "*" being a run-time lib function. Hope so! > > The CW online manual has this to say about "certain computations": > "Intrinsic functions let you pass in data to perform specific optimized > computations. For example, some calculations may be inefficient if coded in > C because the compiler has to follow ANSI C rules to represent data, and > this may cause the program to jump to runtime math routines for certain > computations. In such cases, it probably is better to code these > calculations using assembly language instructions and intrinsic functions. " > > The intrinsic multiply functions I found were all for fractional math, not > integer. > > I didn't even have the modulus operator in my ISR - it was in the main loop. > I understand that if it isn't thread-safe, some other math in the ISR could > break it ... I would have expected less-repeatable results. > > The "fanciest" math inside my ISR is: > increment a variable (I think they are all ushorts, but I'll search for > longs) > mask a ushort variable using "var & mask" > mask-and-shift register contents, then assign to another variable (for > byte-swapping) > mask a register value, then use it in a comparison > > On a quick look-through, I don't even see any "multiply"s remaining, but I > suppose pointer arithmetic might use one implicitly. I'll look several more > times. I had better look through the ASM produced to look for calls to lib > functions. > > I share your paranoia. Thanks! > > Rick Corey > -----Original Message----- > From: Yochum, William [mailto:] > Sent: Wednesday, April 07, 2004 11:00 AM > To: ' > Cc: Corey, Rick > Subject: RE: modulus (%) affects interrupts? > I've seen something even worse in an earlier version of Code Warrior. > > I was also attempting to do "simple" math in an ISR. > > The math in my ISR was written as a standard C expression, but the compiler > implemented this as a call to a run-time library function. So far, so good > ... but the run-time library function was NOT INTERRUPT SAFE! It corrupted > registers which manifested itself as random failures in background code. > This was a VERY insidious problem and took quite a while to find. > > William C. Yochum Microwave Data Systems Inc. > Principal Eng./Software 175 Science Parkway > Phone: (585) 242-8319 Rochester, NY 14620 > FAX: (585) 241-5590 USA > -- Free Download - New Version Released CodeWarrior Development Studio for HC(S)12 Microcontrollers v3.1 Offers "emulator-like" debugging support for HCS12 derivatives http://www.metrowerks.com/MW/Develop/Embedded/HC12/Default.htm Ron Liechty - - http://www.metrowerks.com |
Reply by ●April 7, 20042004-04-07
|
Rick Corey wrote: > Can anyone imagine a way that a modulus operator (%) in the main loop could > slow down an ISR? I'm stumped. An ISR will not call any function in the main loop or be affected by it in anyway. The ISR should run to completion before going back to the main loop. The engineers that looked at this are guessing that the time to complete the ISR you wrote might depend on some data structure that could be corrupted by something done in the mainloop. The mod library itself would not do this. It is likely something in your code. Perhaps the modulus operation is just a red herring? Ron -- Free Download - New Version Released CodeWarrior Development Studio for HC(S)12 Microcontrollers v3.1 Offers "emulator-like" debugging support for HCS12 derivatives http://www.metrowerks.com/MW/Develop/Embedded/HC12/Default.htm Ron Liechty - - http://www.metrowerks.com |
Reply by ●April 8, 20042004-04-08
|
Hi Ron The modulus problem is not a red herring. I have weeks of testing where: 'without the % it works fine for days" and 20-30 cycles of "add the % and break it - remove the % and it works fine for as long as I run the test". The most recent test is "make both arguments ushorts and run overnight" vs. "if either is a long it will crash very quickly". This is conclusive. The two variables used in the % statement are not used anywhere else in the program and are local to the routine that uses them. It is not a red herring. Rick Corey -----Original Message----- From: MW Ron [mailto:] Sent: Wednesday, April 07, 2004 5:10 PM To: Cc: Corey, Rick Subject: Re: [motoroladsp] modulus (%) affects interrupts? Importance: Low Rick Corey wrote: > Can anyone imagine a way that a modulus operator (%) in the main loop could > slow down an ISR? I'm stumped. An ISR will not call any function in the main loop or be affected by it in anyway. The ISR should run to completion before going back to the main loop. The engineers that looked at this are guessing that the time to complete the ISR you wrote might depend on some data structure that could be corrupted by something done in the mainloop. The mod library itself would not do this. It is likely something in your code. Perhaps the modulus operation is just a red herring? Ron -- Free Download - New Version Released CodeWarrior Development Studio for HC(S)12 Microcontrollers v3.1 Offers "emulator-like" debugging support for HCS12 derivatives http://www.metrowerks.com/MW/Develop/Embedded/HC12/Default.htm Ron Liechty - - http://www.metrowerks.com |
|
|
Reply by ●April 8, 20042004-04-08
|
Hi Ron First, I'll just mention that even blocking interrupts entirely around that modulus code did not seem to solve the problem either! I used: "#define __EI3() { asm(bfset #0x0300,SR); }" and "#define __EI0() { asm(bfclr #0x0300,SR); } I added such long delays elsewhere in the main loop that blocking IRQs during the % code wouldn't cause problems. It still died when I used a long constant, and worked when I used a short. Tentatively I would think that this means that "ISR-safety" is not the only issue. Sorry, but I have several points of substantial disagreement with your post: (1) First, you said: "Regarding being ISR safe. This is addressed as long as the routine calling these functions have one of the following: ..." Ron, that means that these are absolutely *NOT* ISR-safe in ANY sense, since they need to have complete ISR protection wrapped around them. You said: "as long as the routine calling these functions have ..." Please tell me how one would add ISR protection like "#pragma interrupt called" to "main", which is where this happened to bite me. Then I could test the theory that "% long" is merely not ISR-safe, as opposed to having other problems as well. I'm also puzzled about how "#pragma interrupt called" can protect the inside of a function, if it does not block IRQs when the function is not called from inside an ISR. It seems to me that the "protected" function (or main, in my case) would save its context, then start running, then reach the math code, then be interrupted by an ISR, and break things. When you put "#pragma interrupt called" around a function that is NOT called from inside an iSR, does it block IRQs as well as SAVEALL? This is puzzling. Even if that is sufficient, are you saying that ANY non-ISR routine that uses any floating point math, or any math function, or any 32-bit multiply needs to have "#pragma interrupt called" around it, even if it is NOT called from inside any ISR? That's a brutal efficiency hit! Would the same rule apply to any function that uses the modulus operator with a long (32-bit) variable? I understand that floating point math will be slow (that's understandable) but not having to save and restore the whole context just to do a 32-bit multiply or modulus! The most scary thing is that these are not explicit library functions like "sin" or "log" ... these are just the ANSII C operators "*" and "%". Modulus isn't ISR-safe with longs in your compiler - or maybe it just occasionally works wrong with longs altogether, I don't know. When I change the "unsigned short" to a "unsigned long" it breaks my code. One excellent consultant we work with pointed to FPE_state as a possible culprit, and I'll test that eventually - he suggests that it should be part of your SAVEALL and RESTOREALL macros for ISRs to work correctly with math. (2) Next, you said: >> 16-bit math is not done in a library. << I think this is incorrect. Here's the ASM you generate: - - - - if (!(NumMsgsSent % 100)) // 0xFF)) P:00000EBA: B57C move.w X:(SP-4),Y0 P:00000EBB: 87470064 move.w #100,Y1 P:00000EBD: E254126D jsr 0x00126d P:00000EBF: 8F05 tst.w Y0 P:00000EC0: A211 bne main+0xd0 (0xed2) ; 0x000772 - - - - The jsr jumps to the following, which the debugger says comes from "C:\program files\Metrowerks\CW6\M56800E Support\math support\Rtrem16\ARTREMU16Z.asm". This looks like a library to me. "Modulus" is math, and both the operands are ushorts (16 bits). It seems to be "16 bit math done in a library" ... but at least it doesn't seem to destroy my code. tst.w y1 ; Check on high bit, should be zero P:0000126D: 8F07 tst.w Y1 ; Required carry bit is cleard too! blt High_bit_present ; If bit 15 on, result is either 1 or 0 P:0000126E: A51B blt @DummyFn1+0x1d (0x128a) ; 0x000953 P:0000126F: E700 nop lsr16 y0,b ; Copy dividend to b0 no sign extension P:00001270: 7CD7 lsr16 Y0,B ;;;;;;;;;;;;;;;; 4-bit division ;;;;;;;;;;;;;;;; div y1,b ; form quotient in b0 P:00001271: 78FF div Y1,B <big snip> ;;;;;;;;;;;;;;; Quotient result is either be 1 (REM = y0-y1) or 0 (REM = y0) High_bit_present: move.w y0,b ; set REM to dividend, y0, for quotient = 0 P:0000128A: 8105 move.w Y0,B sub y1,y0 ; REM valid if y0 >= y1 (quotient = 1) P:0000128B: 7AF1 sub Y1,Y0 tcc y0,b ; if quotient = 1, REM = y0-y1 P:0000128C: 709F tcc Y0,B rtsd ; delay return after nxt 3 instr P:0000128D: E70C rtsd move.w b1,y0 ; move REM value into return register P:0000128E: 8511 move.w B1,Y0 nop ; filler P:0000128F: E700 nop nop ; filler P:00001290: E700 nop - - - - - - (3) Finally, you said: "If its not guarded by these #pragma's it will clobber volatile registers used by the library. This ABI approach is a solid performance tradeoffs. We have many volatile registers because, it would really slow things down if more were treated as non-volatile." I never heard that, before, as a reason to ship non-re-entrant math libraries for a microcontroller. The tendency to use those with interrupts usually makes re-entrancy an absolute requirement for usability. How could making your libraries re-entrant slow things down as much as forcing the user to wrap "SAVEALL" and "RESTOREALL" around every single routine that uses any math? Rick Corey -----Original Message----- From: MW Ron [mailto:] Sent: Wednesday, April 07, 2004 5:06 PM To: Subject: Re: [motoroladsp] RE: modulus (%) affects interrupts? Importance: Low HI Rick and William, 32-bit multiply instructions take two 16-bit values and generated a 32-bit result. This is not useful by itself for doing 32x32-bit multiplication. This is why a runtime library is called for. 16-bit math is not done in a library. For 5683xx/5685x we have more instruction support and inline much of these user select "optimize for speed". 5680x and 5682x families have a more limited instruction and registers set here. All FP math is done in a library. (no FPU on the processor) Regarding being ISR safe. This is addressed as long as the routine calling these functions have one of the following: 1. "#pragma interrupt" For use only at top level ISR. Recommended when there are not too many subroutine calls 2. "#pragma interrupt saveall" For use only at top level ISR recommended when there will be many subroutine calls 3. "#pragma interrupt called" for use in case #1. Must be placed on C functions called by interrupt routine (unless saveall option was used) One problem you point out is that the compiler does not emit an error if pragma in case 3 is left off. We don not have a solution to offer this shortcoming. If its not guarded by these #pragma's it will clobber volatile registers used by the library. This ABI approach is a solid performance tradeoffs. We have many volatile registers because, it would really slow things down if more were treated as non-volatile. > Hi William > > Ouch! I thought I read somewhere that simple "multiply" is a run-time > library function. I wish I could recall where I read that. I see nothing > in the "MSL C" doc. I see 13 "multiply" instructions listed in family > RefMan (which makes sense, for a DSP). IMACUU provides a 32-bit result. > Maybe I'm wrong about "*" being a run-time lib function. Hope so! > > The CW online manual has this to say about "certain computations": > "Intrinsic functions let you pass in data to perform specific optimized > computations. For example, some calculations may be inefficient if coded in > C because the compiler has to follow ANSI C rules to represent data, and > this may cause the program to jump to runtime math routines for certain > computations. In such cases, it probably is better to code these > calculations using assembly language instructions and intrinsic functions. " > > The intrinsic multiply functions I found were all for fractional math, not > integer. > > I didn't even have the modulus operator in my ISR - it was in the main loop. > I understand that if it isn't thread-safe, some other math in the ISR could > break it ... I would have expected less-repeatable results. > > The "fanciest" math inside my ISR is: > increment a variable (I think they are all ushorts, but I'll search for > longs) > mask a ushort variable using "var & mask" > mask-and-shift register contents, then assign to another variable (for > byte-swapping) > mask a register value, then use it in a comparison > > On a quick look-through, I don't even see any "multiply"s remaining, but I > suppose pointer arithmetic might use one implicitly. I'll look several more > times. I had better look through the ASM produced to look for calls to lib > functions. > > I share your paranoia. Thanks! > > Rick Corey > -----Original Message----- > From: Yochum, William [mailto:] > Sent: Wednesday, April 07, 2004 11:00 AM > To: ' > Cc: Corey, Rick > Subject: RE: modulus (%) affects interrupts? > I've seen something even worse in an earlier version of Code Warrior. > > I was also attempting to do "simple" math in an ISR. > > The math in my ISR was written as a standard C expression, but the compiler > implemented this as a call to a run-time library function. So far, so good > ... but the run-time library function was NOT INTERRUPT SAFE! It corrupted > registers which manifested itself as random failures in background code. > This was a VERY insidious problem and took quite a while to find. > > William C. Yochum Microwave Data Systems Inc. > Principal Eng./Software 175 Science Parkway > Phone: (585) 242-8319 Rochester, NY 14620 > FAX: (585) 241-5590 USA > -- Free Download - New Version Released CodeWarrior Development Studio for HC(S)12 Microcontrollers v3.1 Offers "emulator-like" debugging support for HCS12 derivatives http://www.metrowerks.com/MW/Develop/Embedded/HC12/Default.htm Ron Liechty - - http://www.metrowerks.com _____________________________________ Note: If you do a simple "reply" with your email client, only the author of this message will receive your answer. You need to do a "reply all" if you want your answer to be distributed to the entire group. _____________________________________ About this discussion group: To Join: To Post: To Leave: Archives: http://www.yahoogroups.com/group/motoroladsp More Groups: http://www.dsprelated.com/groups.php3 Yahoo! Groups Links |
|
|
Reply by ●April 8, 20042004-04-08
|
Corey, Rick wrote: > Hi Ron > > The modulus problem is not a red herring. I have weeks of testing where: > 'without the % it works fine for days" and 20-30 cycles of "add the % and > break it - remove the % and it works fine for as long as I run the test". > The most recent test is "make both arguments ushorts and run overnight" vs. > "if either is a long it will crash very quickly". This is conclusive. The > two variables used in the % statement are not used anywhere else in the > program and are local to the routine that uses them. It is not a red > herring. Please open a Service Request on this and let me know when you do. We need a reproducible case. Ron > > > -----Original Message----- > From: MW Ron [mailto:] > Sent: Wednesday, April 07, 2004 5:10 PM > To: > Cc: Corey, Rick > Subject: Re: [motoroladsp] modulus (%) affects interrupts? > Importance: Low > Rick Corey wrote: > >> Can anyone imagine a way that a modulus operator (%) in the main loop > could >> slow down an ISR? I'm stumped. > > An ISR will not call any function in the main loop or be affected by it in > anyway. The ISR should run to completion before going back to the main loop. > > The engineers that looked at this are guessing that the time to complete the > ISR you wrote might depend on some data structure that could be corrupted by > something done in the mainloop. The mod library itself would not do this. > It is likely something in your code. Perhaps the modulus operation is just > a red herring? > > Ron > > -- > Free Download - New Version Released > CodeWarrior Development Studio for HC(S)12 Microcontrollers v3.1 > Offers "emulator-like" debugging support for HCS12 derivatives > http://www.metrowerks.com/MW/Develop/Embedded/HC12/Default.htm > Ron Liechty - - http://www.metrowerks.com > > > _____________________________________ > Note: If you do a simple "reply" with your email client, only the author of > this message will receive your answer. You need to do a "reply all" if you > want your answer to be distributed to the entire group. > > _____________________________________ > About this discussion group: > > To Join: > > To Post: > > To Leave: > > Archives: http://www.yahoogroups.com/group/motoroladsp > > More Groups: http://www.dsprelated.com/groups.php3 > > Yahoo! Groups Links -- Free Download - New Version Released CodeWarrior Development Studio for HC(S)12 Microcontrollers v3.1 Offers "emulator-like" debugging support for HCS12 derivatives http://www.metrowerks.com/MW/Develop/Embedded/HC12/Default.htm Ron Liechty - - http://www.metrowerks.com |
