sts_222@hotmail.com (Scott) wrote in message news:<2a55e2bc.0404120426.612818f9@posting.google.com>...
> sts_222@hotmail.com (Scott) wrote in message news:<2a55e2bc.0404090600.36d709b@posting.google.com>...
> > Let me first say that I am new to the embedded development community.
> > I have been tasked with determining the problem with the code below.
> > Let me explain what is happening and why I find it strange. The
> > problem is in the inner for loop. The first 16 times through the loop
> > all lines execute as expected. After that, when I step through with
> > the debugger, line 12 is executed and the debugger skips 13 and 14,
> > and goes to line 15. The debugger will not step into the function on
> > line 15, gScreenIO.Special(), it just pops out and goes to line 12
> > again to repeat the pattern.
> >
> > I am using Diab Data 4.0b, SingleStep 7.03 on a Windows NT
> > environment. I have never seen this kind of thing before. I find it
> > quite odd. I have tried changing the data types of shiftcnt, shift and
> > count to the largest types possible; same behavior. We can't get any
> > help from Windriver (I think they bought Diab compiler) because we
> > haven't given them enough money.
> >
> > Any help would be *greatly* appreciated.
> > TIA.
> >
> > 1void SetSysWin( void ) // Highlight all fault buttons //
> > {
> > 2 register _faults *fltptr = Disfaults;
> > 3 ulword tmpfaultvalue;
> > 4 ulword shiftcnt;
> > 5 ulword shift;
> > 6 uword count;
> >
> > 7 for( count = 0; count < MaxFaults; count++ )
> > {
> > 8 tmpfaultvalue = fltptr[count].faultvalue;
> > 9 if(tmpfaultvalue)// don't need to check all the bits if there is
> > no fault
> > {
> > 10 for(shiftcnt = 0; shiftcnt < 32; shiftcnt++) // 16 bits to
> > shift through
> > {
> > 11 shift = 1;
> >
> > 12 if( ( shift <<= shiftcnt ) & tmpfaultvalue )
> > 13 if( ! ( fltptr->faultsalreadydisplayed & shift ) )
> > {
> > 14 fltptr->faultsalreadydisplayed |= shift;
> > 15 gScreenIO.Special(butPress, Faults[count][shiftcnt]);
> > }
> > }
> > 16 gScreenIO << flush; // STS
> > }
> > } // end of for count loop
> >
> > 17 return;
> > }
>
> Thanks for the input gentlemen.
>
> I don't know why the programmer didn't use unsigned long instead of
> typedefing ulword. I thought the same thing when I saw that. Adds to
> the confusion. Along with the silly "16 bits to shift through"
> comment. 16 or 32?
>
> I'll try and let you know what happens.
>
> Scott
I don't know why the debugger was skipping lines 13 and 14 and going
to 15 and not executing, but know why my display was not being updated
correctly. tmpfaultvalue was being set to a mask of 65535 (0xFFFF). As
a result, the first 16 faults on the display were being updated. The
problem is that there are 19 faults on the display.
Scott
Reply by Scott●April 12, 20042004-04-12
sts_222@hotmail.com (Scott) wrote in message news:<2a55e2bc.0404090600.36d709b@posting.google.com>...
> Let me first say that I am new to the embedded development community.
> I have been tasked with determining the problem with the code below.
> Let me explain what is happening and why I find it strange. The
> problem is in the inner for loop. The first 16 times through the loop
> all lines execute as expected. After that, when I step through with
> the debugger, line 12 is executed and the debugger skips 13 and 14,
> and goes to line 15. The debugger will not step into the function on
> line 15, gScreenIO.Special(), it just pops out and goes to line 12
> again to repeat the pattern.
>
> I am using Diab Data 4.0b, SingleStep 7.03 on a Windows NT
> environment. I have never seen this kind of thing before. I find it
> quite odd. I have tried changing the data types of shiftcnt, shift and
> count to the largest types possible; same behavior. We can't get any
> help from Windriver (I think they bought Diab compiler) because we
> haven't given them enough money.
>
> Any help would be *greatly* appreciated.
> TIA.
>
> 1void SetSysWin( void ) // Highlight all fault buttons //
> {
> 2 register _faults *fltptr = Disfaults;
> 3 ulword tmpfaultvalue;
> 4 ulword shiftcnt;
> 5 ulword shift;
> 6 uword count;
>
> 7 for( count = 0; count < MaxFaults; count++ )
> {
> 8 tmpfaultvalue = fltptr[count].faultvalue;
> 9 if(tmpfaultvalue)// don't need to check all the bits if there is
> no fault
> {
> 10 for(shiftcnt = 0; shiftcnt < 32; shiftcnt++) // 16 bits to
> shift through
> {
> 11 shift = 1;
>
> 12 if( ( shift <<= shiftcnt ) & tmpfaultvalue )
> 13 if( ! ( fltptr->faultsalreadydisplayed & shift ) )
> {
> 14 fltptr->faultsalreadydisplayed |= shift;
> 15 gScreenIO.Special(butPress, Faults[count][shiftcnt]);
> }
> }
> 16 gScreenIO << flush; // STS
> }
> } // end of for count loop
>
> 17 return;
> }
Thanks for the input gentlemen.
I don't know why the programmer didn't use unsigned long instead of
typedefing ulword. I thought the same thing when I saw that. Adds to
the confusion. Along with the silly "16 bits to shift through"
comment. 16 or 32?
I'll try and let you know what happens.
Scott
Reply by CBFalconer●April 9, 20042004-04-09
"Gene S. Berkowitz" wrote:
>
> In article <4076E618.D7B44993@yahoo.com>, cbfalconer@yahoo.com says...
> > "Gene S. Berkowitz" wrote:
> > > cbfalconer@yahoo.com says...
> > >> Scott wrote:
> > >>>
> > >>> Let me first say that I am new to the embedded development community.
> > >>> I have been tasked with determining the problem with the code below.
> > >>> Let me explain what is happening and why I find it strange. The
> > >>> problem is in the inner for loop. The first 16 times through the loop
> > >>> all lines execute as expected. After that, when I step through with
> > >>> the debugger, line 12 is executed and the debugger skips 13 and 14,
> > >>> and goes to line 15. The debugger will not step into the function on
> > >>> line 15, gScreenIO.Special(), it just pops out and goes to line 12
> > >>> again to repeat the pattern.
> > >>>
> > >> ... snip ...
> > >>>
> > >>> 7 for( count = 0; count < MaxFaults; count++ )
> > >>> {
> > >>> 8 tmpfaultvalue = fltptr[count].faultvalue;
> > >>> 9 if(tmpfaultvalue)// don't need to check all the bits if there is
> > >>> no fault
> > >>> {
> > >>> 10 for(shiftcnt = 0; shiftcnt < 32; shiftcnt++) // 16 bits to
> > >>> shift through
> > >>> {
> > >>> 11 shift = 1;
> > >>>
> > >>> 12 if( ( shift <<= shiftcnt ) & tmpfaultvalue )
> > >>
> > >> Don't use // comments in newsgroups, they don't wrap well.
> > >>
> > >> Apart from the silly type names (what is wrong with unsigned long
> > >> etc?) just monitor the value of shift. It should be 1, 2, 8, ....
> > >> which I doubt is what you want. At shiftcnt == 16 it is shifting
> > >> off the left, and becoming zero, which has a tendency to inhibit
> > >> any action controlled by your line 12.
> > >
> > > If the odd typing can be believed, "shift" is an unsigned long,
> > > which defaults to 32 bits with the Diab compiler, so I don't think
> > > it's falling off the end. A more appropriate name would be
> > > "Bitmask", because that's what it is.
> >
> > Yes it is falling off, at count = 16, with a 32 bit unsigned
> > long. At that point you are shifting 65536 left 16 places, with
> > result 0.
>
> No; in the OP's code, shift is INITIALIZED to 1 EVERY time through the
> loop.
> The 1st pass, shift (1) is shifted left shiftcnt (0) bits == 1.
> The 2nd pass, shift (1) is shifted left shiftcnt (1) bits == 2.
> The 3rd pass, shift (1) is shifted left shiftcnt (2) bits == 4.
> etc.
> ..which is why I recommended moving the initialization outside the loop,
> and shift by 1 each time within the loop.
You are right - I missed that reinitialization. The code is even
more obscured than it appears at first. So I have been talking my
usual nonsense. Bah. But the suggestion fitted the described
failure point, which blinded me even further. :-(
--
Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!
Reply by Ben Bradley●April 9, 20042004-04-09
In comp.arch.embedded, Gene S. Berkowitz <first.last@comcast.net>
wrote:
>You should probably move this assigment OUTSIDE the for(shiftcnt) loop,
>then simply shift it left by one bit each time at the end of the loop:
>
>shift = 1;
>for(shiftcnt = 0; shiftcnt < 32; shiftcnt++)
>{
> ..tests go here
> shift <<= 1;
>}
>You should probably move this assigment OUTSIDE the for(shiftcnt) loop,
>then simply shift it left by one bit each time at the end of the loop:
I might argue that the mask (the variable named 'shift') is a
second loop index, and stick the initialization and 'incrementing'
into the for statement:
for(shiftcnt = 0, shift = 1; shiftcnt < 32; shiftcnt++, shift <<= 1)
{
12 if( shift & tmpfaultvalue )
...
}
The code is effectively no different from yours, but it makes it more
obvious that both shiftcnt and shift are loop variables, set in the
for statement, and read but not changed inside the loop.
-----
http://mindspring.com/~benbradley
Reply by Gene S. Berkowitz●April 9, 20042004-04-09
In article <4076E618.D7B44993@yahoo.com>, cbfalconer@yahoo.com says...
> "Gene S. Berkowitz" wrote:
> > cbfalconer@yahoo.com says...
> >> Scott wrote:
> >>>
> >>> Let me first say that I am new to the embedded development community.
> >>> I have been tasked with determining the problem with the code below.
> >>> Let me explain what is happening and why I find it strange. The
> >>> problem is in the inner for loop. The first 16 times through the loop
> >>> all lines execute as expected. After that, when I step through with
> >>> the debugger, line 12 is executed and the debugger skips 13 and 14,
> >>> and goes to line 15. The debugger will not step into the function on
> >>> line 15, gScreenIO.Special(), it just pops out and goes to line 12
> >>> again to repeat the pattern.
> >>>
> >> ... snip ...
> >>>
> >>> 7 for( count = 0; count < MaxFaults; count++ )
> >>> {
> >>> 8 tmpfaultvalue = fltptr[count].faultvalue;
> >>> 9 if(tmpfaultvalue)// don't need to check all the bits if there is
> >>> no fault
> >>> {
> >>> 10 for(shiftcnt = 0; shiftcnt < 32; shiftcnt++) // 16 bits to
> >>> shift through
> >>> {
> >>> 11 shift = 1;
> >>>
> >>> 12 if( ( shift <<= shiftcnt ) & tmpfaultvalue )
> >>
> >> Don't use // comments in newsgroups, they don't wrap well.
> >>
> >> Apart from the silly type names (what is wrong with unsigned long
> >> etc?) just monitor the value of shift. It should be 1, 2, 8, ....
> >> which I doubt is what you want. At shiftcnt == 16 it is shifting
> >> off the left, and becoming zero, which has a tendency to inhibit
> >> any action controlled by your line 12.
> >
> > If the odd typing can be believed, "shift" is an unsigned long,
> > which defaults to 32 bits with the Diab compiler, so I don't think
> > it's falling off the end. A more appropriate name would be
> > "Bitmask", because that's what it is.
>
> Yes it is falling off, at count = 16, with a 32 bit unsigned
> long. At that point you are shifting 65536 left 16 places, with
> result 0.
No; in the OP's code, shift is INITIALIZED to 1 EVERY time through the
loop.
The 1st pass, shift (1) is shifted left shiftcnt (0) bits == 1.
The 2nd pass, shift (1) is shifted left shiftcnt (1) bits == 2.
The 3rd pass, shift (1) is shifted left shiftcnt (2) bits == 4.
etc.
..which is why I recommended moving the initialization outside the loop,
and shift by 1 each time within the loop.
--Gene
Reply by Richard●April 9, 20042004-04-09
CBFalconer <cbfalconer@yahoo.com> wrote in news:4076E618.D7B44993
@yahoo.com:
> "Gene S. Berkowitz" wrote:
>> cbfalconer@yahoo.com says...
>>> Scott wrote:
>>>>
>>>> Let me first say that I am new to the embedded development
community.
>>>> I have been tasked with determining the problem with the code below.
>>>> Let me explain what is happening and why I find it strange. The
>>>> problem is in the inner for loop. The first 16 times through the
loop
>>>> all lines execute as expected. After that, when I step through with
>>>> the debugger, line 12 is executed and the debugger skips 13 and 14,
>>>> and goes to line 15. The debugger will not step into the function on
>>>> line 15, gScreenIO.Special(), it just pops out and goes to line 12
>>>> again to repeat the pattern.
>>>>
>>> ... snip ...
>>>>
>>>> 7 for( count = 0; count < MaxFaults; count++ )
>>>> {
>>>> 8 tmpfaultvalue = fltptr[count].faultvalue;
>>>> 9 if(tmpfaultvalue)// don't need to check all the bits if there
is
>>>> no fault
>>>> {
>>>> 10 for(shiftcnt = 0; shiftcnt < 32; shiftcnt++) // 16 bits to
>>>> shift through
>>>> {
>>>> 11 shift = 1;
>>>>
>>>> 12 if( ( shift <<= shiftcnt ) & tmpfaultvalue )
>>>
>>> Don't use // comments in newsgroups, they don't wrap well.
>>>
>>> Apart from the silly type names (what is wrong with unsigned long
>>> etc?) just monitor the value of shift. It should be 1, 2, 8, ....
>>> which I doubt is what you want. At shiftcnt == 16 it is shifting
>>> off the left, and becoming zero, which has a tendency to inhibit any
>>> action controlled by your line 12.
>>
>> If the odd typing can be believed, "shift" is an unsigned long, which
>> defaults to 32 bits with the Diab compiler, so I don't think it's
>> falling off the end. A more appropriate name would be "Bitmask",
>> because that's what it is.
>
> Yes it is falling off, at count = 16, with a 32 bit unsigned
> long. At that point you are shifting 65536 left 16 places, with
> result 0.
>
> After 8 in the above sequence comes 128. I.e. it is not really
> the bitmask you want if you are trying to scan bits in
> tmpfaultvalue.
shift is reset to 1 each pass through the loop, so the sequence is the
expected 1,2,4,8,16,32,....
Certainly not the way I would code it, but, I don't see a problem with
that offhand, assuming that ulword is indeed an unsigned 32 bit integer.
--
Richard
Reply by CBFalconer●April 9, 20042004-04-09
"Gene S. Berkowitz" wrote:
> cbfalconer@yahoo.com says...
>> Scott wrote:
>>>
>>> Let me first say that I am new to the embedded development community.
>>> I have been tasked with determining the problem with the code below.
>>> Let me explain what is happening and why I find it strange. The
>>> problem is in the inner for loop. The first 16 times through the loop
>>> all lines execute as expected. After that, when I step through with
>>> the debugger, line 12 is executed and the debugger skips 13 and 14,
>>> and goes to line 15. The debugger will not step into the function on
>>> line 15, gScreenIO.Special(), it just pops out and goes to line 12
>>> again to repeat the pattern.
>>>
>> ... snip ...
>>>
>>> 7 for( count = 0; count < MaxFaults; count++ )
>>> {
>>> 8 tmpfaultvalue = fltptr[count].faultvalue;
>>> 9 if(tmpfaultvalue)// don't need to check all the bits if there is
>>> no fault
>>> {
>>> 10 for(shiftcnt = 0; shiftcnt < 32; shiftcnt++) // 16 bits to
>>> shift through
>>> {
>>> 11 shift = 1;
>>>
>>> 12 if( ( shift <<= shiftcnt ) & tmpfaultvalue )
>>
>> Don't use // comments in newsgroups, they don't wrap well.
>>
>> Apart from the silly type names (what is wrong with unsigned long
>> etc?) just monitor the value of shift. It should be 1, 2, 8, ....
>> which I doubt is what you want. At shiftcnt == 16 it is shifting
>> off the left, and becoming zero, which has a tendency to inhibit
>> any action controlled by your line 12.
>
> If the odd typing can be believed, "shift" is an unsigned long,
> which defaults to 32 bits with the Diab compiler, so I don't think
> it's falling off the end. A more appropriate name would be
> "Bitmask", because that's what it is.
Yes it is falling off, at count = 16, with a 32 bit unsigned
long. At that point you are shifting 65536 left 16 places, with
result 0.
After 8 in the above sequence comes 128. I.e. it is not really
the bitmask you want if you are trying to scan bits in
tmpfaultvalue. If you need a mask that moves left, use the code I
suggested and you snipped. If you just need to test the bits in
sequence, then:
for (tfv = tmpfaultvalue, i = 0; i < MAGICSIZE; i++, tfv >>= 1)
{
if (1 & tfv) {
/* action */
}
}
--
Churchill and Bush can both be considered wartime leaders, just
as Secretariat and Mr Ed were both horses. - James Rhodes.
Reply by Gene S. Berkowitz●April 9, 20042004-04-09
In article <4076BAB8.ED557162@yahoo.com>, cbfalconer@yahoo.com says...
> Scott wrote:
> >
> > Let me first say that I am new to the embedded development community.
> > I have been tasked with determining the problem with the code below.
> > Let me explain what is happening and why I find it strange. The
> > problem is in the inner for loop. The first 16 times through the loop
> > all lines execute as expected. After that, when I step through with
> > the debugger, line 12 is executed and the debugger skips 13 and 14,
> > and goes to line 15. The debugger will not step into the function on
> > line 15, gScreenIO.Special(), it just pops out and goes to line 12
> > again to repeat the pattern.
> >
> ... snip ...
> >
> > 7 for( count = 0; count < MaxFaults; count++ )
> > {
> > 8 tmpfaultvalue = fltptr[count].faultvalue;
> > 9 if(tmpfaultvalue)// don't need to check all the bits if there is
> > no fault
> > {
> > 10 for(shiftcnt = 0; shiftcnt < 32; shiftcnt++) // 16 bits to
> > shift through
> > {
> > 11 shift = 1;
> >
> > 12 if( ( shift <<= shiftcnt ) & tmpfaultvalue )
>
> Don't use // comments in newsgroups, they don't wrap well.
>
> Apart from the silly type names (what is wrong with unsigned long
> etc?) just monitor the value of shift. It should be 1, 2, 8, ....
> which I doubt is what you want. At shiftcnt == 16 it is shifting
> off the left, and becoming zero, which has a tendency to inhibit
> any action controlled by your line 12.
If the odd typing can be believed, "shift" is an unsigned long, which
defaults to 32 bits with the Diab compiler, so I don't think it's
falling off the end. A more appropriate name would be "Bitmask",
because that's what it is.
--Gene
Reply by CBFalconer●April 9, 20042004-04-09
Scott wrote:
>
> Let me first say that I am new to the embedded development community.
> I have been tasked with determining the problem with the code below.
> Let me explain what is happening and why I find it strange. The
> problem is in the inner for loop. The first 16 times through the loop
> all lines execute as expected. After that, when I step through with
> the debugger, line 12 is executed and the debugger skips 13 and 14,
> and goes to line 15. The debugger will not step into the function on
> line 15, gScreenIO.Special(), it just pops out and goes to line 12
> again to repeat the pattern.
>
... snip ...
>
> 7 for( count = 0; count < MaxFaults; count++ )
> {
> 8 tmpfaultvalue = fltptr[count].faultvalue;
> 9 if(tmpfaultvalue)// don't need to check all the bits if there is
> no fault
> {
> 10 for(shiftcnt = 0; shiftcnt < 32; shiftcnt++) // 16 bits to
> shift through
> {
> 11 shift = 1;
>
> 12 if( ( shift <<= shiftcnt ) & tmpfaultvalue )
Don't use // comments in newsgroups, they don't wrap well.
Apart from the silly type names (what is wrong with unsigned long
etc?) just monitor the value of shift. It should be 1, 2, 8, ....
which I doubt is what you want. At shiftcnt == 16 it is shifting
off the left, and becoming zero, which has a tendency to inhibit
any action controlled by your line 12. Maybe the initialization
of shift should go, and the expression should be: "if (shift = (1
<< shiftcnt)) & tmpfaultvalue)"
--
Churchill and Bush can both be considered wartime leaders, just
as Secretariat and Mr Ed were both horses. - James Rhodes.
Reply by Gene S. Berkowitz●April 9, 20042004-04-09
In article <2a55e2bc.0404090600.36d709b@posting.google.com>, sts_222
@hotmail.com says...
> Let me first say that I am new to the embedded development community.
> I have been tasked with determining the problem with the code below.
> Let me explain what is happening and why I find it strange. The
> problem is in the inner for loop. The first 16 times through the loop
> all lines execute as expected. After that, when I step through with
> the debugger, line 12 is executed and the debugger skips 13 and 14,
> and goes to line 15. The debugger will not step into the function on
> line 15, gScreenIO.Special(), it just pops out and goes to line 12
> again to repeat the pattern.
>
> I am using Diab Data 4.0b, SingleStep 7.03 on a Windows NT
> environment. I have never seen this kind of thing before. I find it
> quite odd. I have tried changing the data types of shiftcnt, shift and
> count to the largest types possible; same behavior. We can't get any
> help from Windriver (I think they bought Diab compiler) because we
> haven't given them enough money.
>
> Any help would be *greatly* appreciated.
> TIA.
>
> 1void SetSysWin( void ) // Highlight all fault buttons //
> {
> 2 register _faults *fltptr = Disfaults;
^^^ This is usually best left to the compiler to decide; there is rarely
an advantage to using the register declaration...
> 3 ulword tmpfaultvalue;
> 4 ulword shiftcnt;
> 5 ulword shift;
> 6 uword count;
>
> 7 for( count = 0; count < MaxFaults; count++ )
> {
> 8 tmpfaultvalue = fltptr[count].faultvalue;
> 9 if(tmpfaultvalue)// don't need to check all the bits if there is
> no fault
> {
> 10 for(shiftcnt = 0; shiftcnt < 32; shiftcnt++) // 16 bits to
> shift through
Make up your mind; is it 16 or 32 bits?
> {
> 11 shift = 1;
You should probably move this assigment OUTSIDE the for(shiftcnt) loop,
then simply shift it left by one bit each time at the end of the loop:
shift = 1;
for(shiftcnt = 0; shiftcnt < 32; shiftcnt++)
{
..tests go here
shift <<= 1;
}
Compile this file with optimization OFF (no -XO switch).
SingleStep is incredibly bad at showing the actual location within
optimized for(..) loops, unless you drop into disassembly mode.