Just thought I'd point out that I agree that the statement is poorly
written:
return (UxTHR = ch);
The only reason it's like that is that this code is straight out of the
Keil examples!
MX
UART stuck waiting for THRE
Started by ●May 10, 2008
Reply by ●May 10, 20082008-05-10
Reply by ●May 10, 20082008-05-10
At 02:06 AM 5/11/2008 +0000, mattwoolsey wrote:
>Just thought I'd point out that I agree that the statement is poorly
>written:
>
> return (UxTHR = ch);
>
>The only reason it's like that is that this code is straight out of the
>Keil examples!
Lord save us from vendors examples ;)
Robert
Another sign of the end of civilization, our technical magazines are
getting chatty
From an EETimes product descriptions 2006/08/09
".... systems that can sample gobs of inputs simultaneously"
Now just what is the technical definition for gobs again?
http://www.aeolusdevelopment.com/
>Just thought I'd point out that I agree that the statement is poorly
>written:
>
> return (UxTHR = ch);
>
>The only reason it's like that is that this code is straight out of the
>Keil examples!
Lord save us from vendors examples ;)
Robert
Another sign of the end of civilization, our technical magazines are
getting chatty
From an EETimes product descriptions 2006/08/09
".... systems that can sample gobs of inputs simultaneously"
Now just what is the technical definition for gobs again?
http://www.aeolusdevelopment.com/
Reply by ●May 10, 20082008-05-10
--- In l..., Robert Adsett
wrote:
>
I've run into plenty of Heisenbugs. :)
I added turning on an LED just before the loop and turning it off
after the loop. The LED does indeed stay on. When I change the one
parameter from int to char, it blinks.
//-------------
int sendchar (int ch) // <--- the THRE bit never goes high again if
this is int parameter!!!
//int sendchar (char ch)
{ /* Write character to Serial Port */
int i;
IOCLR = 0x00008000;
for(i=0;i<1000;i++); // <--- just enough delay to see the LED
blink
while (!(UxLSR & 0x20))
{
}
IOSET = 0x00008000;
return (UxTHR = ch);
}
//-------------
MX
> At 01:57 AM 5/11/2008 +0000, mattwoolsey wrote:
> >--- In l..., Robert Adsett
> >wrote:
> >
> > > Somehow I think the problem is somewhere else entirely. Are you
> >running
> > > any interrupts? Why are you sure it's stuck in that loop?
> >
> >No interrupts are running. I know it's stuck in the loop, because
I
> >can comment out that line and then all the characters get sent.
>
> That's a hint, but it doesn't prove it's stuck there. Have you
heard the
> term Heisenbug?
>
> > > In that loop there are only a few possibilities
> > > - You are addressing the wrong location (not likely
since
> >it's
> > > reloaded)
> > > - The location is really returning a value without the
> >6'th bit set
> > >
> > > For the second to be true the character must not have been sent.
> >For it
> > > not to have been sent there must be some reason separate from
this
> >piece of
> > > code.
> > >
> > > Both are easily checkable walking through the loop if you are
> >running a
> > > JTAG debugger.
> >
> >Sorry, no JTAG on this one. This is a really small board design
that
> >doesn't even have room for the JTAG header. I already had a big
> >application up and running. Then decided to try the latest Keil
> >tools with the new compiler and things quit working. Even the
serial
> >port wouldn't work. So I went back to the bare minimum and ran
into
> >this strange issue.
>
> Well I don't see how it can be in your loop, so time to prove if it
really
> is. Steal an output pin. Set it high just before you enter the
loop and
> low when you exit. If it sticks high you will start to convince me.
>
> Robert
>
> "A million lines of code costs $20m to $40m ..... a million times
> the cost of the flash chips it lives in. .... Yet accounting screams
> over each added penny in recurring costs, while chanting the
> dual mantras 'software is free,' and 'hey, it's only a software
> change.'" Jack Ganssle in "A Million Lines of Code"
>
> Robert Adsett - http://www.aeolusdevelopment.com/
>
wrote:
>
I've run into plenty of Heisenbugs. :)
I added turning on an LED just before the loop and turning it off
after the loop. The LED does indeed stay on. When I change the one
parameter from int to char, it blinks.
//-------------
int sendchar (int ch) // <--- the THRE bit never goes high again if
this is int parameter!!!
//int sendchar (char ch)
{ /* Write character to Serial Port */
int i;
IOCLR = 0x00008000;
for(i=0;i<1000;i++); // <--- just enough delay to see the LED
blink
while (!(UxLSR & 0x20))
{
}
IOSET = 0x00008000;
return (UxTHR = ch);
}
//-------------
MX
> At 01:57 AM 5/11/2008 +0000, mattwoolsey wrote:
> >--- In l..., Robert Adsett
> >wrote:
> >
> > > Somehow I think the problem is somewhere else entirely. Are you
> >running
> > > any interrupts? Why are you sure it's stuck in that loop?
> >
> >No interrupts are running. I know it's stuck in the loop, because
I
> >can comment out that line and then all the characters get sent.
>
> That's a hint, but it doesn't prove it's stuck there. Have you
heard the
> term Heisenbug?
>
> > > In that loop there are only a few possibilities
> > > - You are addressing the wrong location (not likely
since
> >it's
> > > reloaded)
> > > - The location is really returning a value without the
> >6'th bit set
> > >
> > > For the second to be true the character must not have been sent.
> >For it
> > > not to have been sent there must be some reason separate from
this
> >piece of
> > > code.
> > >
> > > Both are easily checkable walking through the loop if you are
> >running a
> > > JTAG debugger.
> >
> >Sorry, no JTAG on this one. This is a really small board design
that
> >doesn't even have room for the JTAG header. I already had a big
> >application up and running. Then decided to try the latest Keil
> >tools with the new compiler and things quit working. Even the
serial
> >port wouldn't work. So I went back to the bare minimum and ran
into
> >this strange issue.
>
> Well I don't see how it can be in your loop, so time to prove if it
really
> is. Steal an output pin. Set it high just before you enter the
loop and
> low when you exit. If it sticks high you will start to convince me.
>
> Robert
>
> "A million lines of code costs $20m to $40m ..... a million times
> the cost of the flash chips it lives in. .... Yet accounting screams
> over each added penny in recurring costs, while chanting the
> dual mantras 'software is free,' and 'hey, it's only a software
> change.'" Jack Ganssle in "A Million Lines of Code"
>
> Robert Adsett - http://www.aeolusdevelopment.com/
>
Reply by ●May 10, 20082008-05-10
Is this 'custom' made hardware?
I'm beginning to suspect hardware.. I base this on the fact that MX just sent me his project files.
Not having a 21xx I ran it on the emulator.
It just works fine... as expected.
The int/char thing doesn't make any difference logically.
The ONLY thing I can see change is TIMING. Granted, the int version only marginally takes more time
(0xff mask).
I have NO idea (I'm a software guy) how, what, why, where or when... but it seems this, and ONLY
this, extra (few bytes) in execution time makes all the differennce.
I bet that anyone with a LPC21xx (06) eval board who would also run this code would have it just
work as it is supposed to work.
(I only bet a quarter... I have been wrong before!)
~ Paul Claessen
----- Original Message -----
From: "mattwoolsey"
To:
Sent: Saturday, May 10, 2008 10:18 PM
Subject: [lpc2000] Re: UART stuck waiting for THRE
--- In l..., Robert Adsett
wrote:
>
I've run into plenty of Heisenbugs. :)
I added turning on an LED just before the loop and turning it off
after the loop. The LED does indeed stay on. When I change the one
parameter from int to char, it blinks.
//-------------
int sendchar (int ch) // <--- the THRE bit never goes high again if
this is int parameter!!!
//int sendchar (char ch)
{ /* Write character to Serial Port */
int i;
IOCLR = 0x00008000;
for(i=0;i<1000;i++); // <--- just enough delay to see the LED
blink
while (!(UxLSR & 0x20))
{
}
IOSET = 0x00008000;
return (UxTHR = ch);
}
//-------------
MX
> At 01:57 AM 5/11/2008 +0000, mattwoolsey wrote:
> >--- In l..., Robert Adsett
> >wrote:
> >
> > > Somehow I think the problem is somewhere else entirely. Are you
> >running
> > > any interrupts? Why are you sure it's stuck in that loop?
> >
> >No interrupts are running. I know it's stuck in the loop, because
I
> >can comment out that line and then all the characters get sent.
>
> That's a hint, but it doesn't prove it's stuck there. Have you
heard the
> term Heisenbug?
>
> > > In that loop there are only a few possibilities
> > > - You are addressing the wrong location (not likely
since
> >it's
> > > reloaded)
> > > - The location is really returning a value without the
> >6'th bit set
> > >
> > > For the second to be true the character must not have been sent.
> >For it
> > > not to have been sent there must be some reason separate from
this
> >piece of
> > > code.
> > >
> > > Both are easily checkable walking through the loop if you are
> >running a
> > > JTAG debugger.
> >
> >Sorry, no JTAG on this one. This is a really small board design
that
> >doesn't even have room for the JTAG header. I already had a big
> >application up and running. Then decided to try the latest Keil
> >tools with the new compiler and things quit working. Even the
serial
> >port wouldn't work. So I went back to the bare minimum and ran
into
> >this strange issue.
>
> Well I don't see how it can be in your loop, so time to prove if it
really
> is. Steal an output pin. Set it high just before you enter the
loop and
> low when you exit. If it sticks high you will start to convince me.
>
> Robert
>
> "A million lines of code costs $20m to $40m ..... a million times
> the cost of the flash chips it lives in. .... Yet accounting screams
> over each added penny in recurring costs, while chanting the
> dual mantras 'software is free,' and 'hey, it's only a software
> change.'" Jack Ganssle in "A Million Lines of Code"
>
> Robert Adsett - http://www.aeolusdevelopment.com/
>
I'm beginning to suspect hardware.. I base this on the fact that MX just sent me his project files.
Not having a 21xx I ran it on the emulator.
It just works fine... as expected.
The int/char thing doesn't make any difference logically.
The ONLY thing I can see change is TIMING. Granted, the int version only marginally takes more time
(0xff mask).
I have NO idea (I'm a software guy) how, what, why, where or when... but it seems this, and ONLY
this, extra (few bytes) in execution time makes all the differennce.
I bet that anyone with a LPC21xx (06) eval board who would also run this code would have it just
work as it is supposed to work.
(I only bet a quarter... I have been wrong before!)
~ Paul Claessen
----- Original Message -----
From: "mattwoolsey"
To:
Sent: Saturday, May 10, 2008 10:18 PM
Subject: [lpc2000] Re: UART stuck waiting for THRE
--- In l..., Robert Adsett
wrote:
>
I've run into plenty of Heisenbugs. :)
I added turning on an LED just before the loop and turning it off
after the loop. The LED does indeed stay on. When I change the one
parameter from int to char, it blinks.
//-------------
int sendchar (int ch) // <--- the THRE bit never goes high again if
this is int parameter!!!
//int sendchar (char ch)
{ /* Write character to Serial Port */
int i;
IOCLR = 0x00008000;
for(i=0;i<1000;i++); // <--- just enough delay to see the LED
blink
while (!(UxLSR & 0x20))
{
}
IOSET = 0x00008000;
return (UxTHR = ch);
}
//-------------
MX
> At 01:57 AM 5/11/2008 +0000, mattwoolsey wrote:
> >--- In l..., Robert Adsett
> >wrote:
> >
> > > Somehow I think the problem is somewhere else entirely. Are you
> >running
> > > any interrupts? Why are you sure it's stuck in that loop?
> >
> >No interrupts are running. I know it's stuck in the loop, because
I
> >can comment out that line and then all the characters get sent.
>
> That's a hint, but it doesn't prove it's stuck there. Have you
heard the
> term Heisenbug?
>
> > > In that loop there are only a few possibilities
> > > - You are addressing the wrong location (not likely
since
> >it's
> > > reloaded)
> > > - The location is really returning a value without the
> >6'th bit set
> > >
> > > For the second to be true the character must not have been sent.
> >For it
> > > not to have been sent there must be some reason separate from
this
> >piece of
> > > code.
> > >
> > > Both are easily checkable walking through the loop if you are
> >running a
> > > JTAG debugger.
> >
> >Sorry, no JTAG on this one. This is a really small board design
that
> >doesn't even have room for the JTAG header. I already had a big
> >application up and running. Then decided to try the latest Keil
> >tools with the new compiler and things quit working. Even the
serial
> >port wouldn't work. So I went back to the bare minimum and ran
into
> >this strange issue.
>
> Well I don't see how it can be in your loop, so time to prove if it
really
> is. Steal an output pin. Set it high just before you enter the
loop and
> low when you exit. If it sticks high you will start to convince me.
>
> Robert
>
> "A million lines of code costs $20m to $40m ..... a million times
> the cost of the flash chips it lives in. .... Yet accounting screams
> over each added penny in recurring costs, while chanting the
> dual mantras 'software is free,' and 'hey, it's only a software
> change.'" Jack Ganssle in "A Million Lines of Code"
>
> Robert Adsett - http://www.aeolusdevelopment.com/
>
Reply by ●May 10, 20082008-05-10
Yes, custom hardware. By the way, I added code to turn an LED on
before the loop and off afterward. That should have changed the
timing significantly, but still had the same results.
MX
--- In l..., "Paul Claessen" wrote:
>
> Is this 'custom' made hardware?
> I'm beginning to suspect hardware.. I base this on the fact that MX
just sent me his project files.
> Not having a 21xx I ran it on the emulator.
> It just works fine... as expected.
>
> The int/char thing doesn't make any difference logically.
> The ONLY thing I can see change is TIMING. Granted, the int
version only marginally takes more time
> (0xff mask).
> I have NO idea (I'm a software guy) how, what, why, where or
when... but it seems this, and ONLY
> this, extra (few bytes) in execution time makes all the differennce.
>
> I bet that anyone with a LPC21xx (06) eval board who would also run
this code would have it just
> work as it is supposed to work.
>
> (I only bet a quarter... I have been wrong before!)
>
> ~ Paul Claessen
> ----- Original Message -----
> From: "mattwoolsey"
> To:
> Sent: Saturday, May 10, 2008 10:18 PM
> Subject: [lpc2000] Re: UART stuck waiting for THRE
> --- In l..., Robert Adsett
> wrote:
> >
> I've run into plenty of Heisenbugs. :)
>
> I added turning on an LED just before the loop and turning it off
> after the loop. The LED does indeed stay on. When I change the one
> parameter from int to char, it blinks.
>
> //-------------
>
> int sendchar (int ch) // <--- the THRE bit never goes high again if
> this is int parameter!!!
> //int sendchar (char ch)
> { /* Write character to Serial Port */
> int i;
>
> IOCLR = 0x00008000;
> for(i=0;i<1000;i++); // <--- just enough delay to see the LED
> blink
>
> while (!(UxLSR & 0x20))
> {
> }
>
> IOSET = 0x00008000;
>
> return (UxTHR = ch);
> }
>
> //-------------
>
> MX
> > At 01:57 AM 5/11/2008 +0000, mattwoolsey wrote:
> > >--- In l..., Robert Adsett
> > >wrote:
> > >
> > > > Somehow I think the problem is somewhere else entirely. Are
you
> > >running
> > > > any interrupts? Why are you sure it's stuck in that loop?
> > >
> > >No interrupts are running. I know it's stuck in the loop,
because
> I
> > >can comment out that line and then all the characters get sent.
> >
> > That's a hint, but it doesn't prove it's stuck there. Have you
> heard the
> > term Heisenbug?
> >
> > > > In that loop there are only a few possibilities
> > > > - You are addressing the wrong location (not likely
> since
> > >it's
> > > > reloaded)
> > > > - The location is really returning a value without
the
> > >6'th bit set
> > > >
> > > > For the second to be true the character must not have been
sent.
> > >For it
> > > > not to have been sent there must be some reason separate from
> this
> > >piece of
> > > > code.
> > > >
> > > > Both are easily checkable walking through the loop if you are
> > >running a
> > > > JTAG debugger.
> > >
> > >Sorry, no JTAG on this one. This is a really small board design
> that
> > >doesn't even have room for the JTAG header. I already had a big
> > >application up and running. Then decided to try the latest Keil
> > >tools with the new compiler and things quit working. Even the
> serial
> > >port wouldn't work. So I went back to the bare minimum and ran
> into
> > >this strange issue.
> >
> > Well I don't see how it can be in your loop, so time to prove if
it
> really
> > is. Steal an output pin. Set it high just before you enter the
> loop and
> > low when you exit. If it sticks high you will start to convince
me.
> >
> > Robert
> >
> > "A million lines of code costs $20m to $40m ..... a million times
> > the cost of the flash chips it lives in. .... Yet accounting
screams
> > over each added penny in recurring costs, while chanting the
> > dual mantras 'software is free,' and 'hey, it's only a software
> > change.'" Jack Ganssle in "A Million Lines of Code"
> >
> > Robert Adsett - http://www.aeolusdevelopment.com/
>
before the loop and off afterward. That should have changed the
timing significantly, but still had the same results.
MX
--- In l..., "Paul Claessen" wrote:
>
> Is this 'custom' made hardware?
> I'm beginning to suspect hardware.. I base this on the fact that MX
just sent me his project files.
> Not having a 21xx I ran it on the emulator.
> It just works fine... as expected.
>
> The int/char thing doesn't make any difference logically.
> The ONLY thing I can see change is TIMING. Granted, the int
version only marginally takes more time
> (0xff mask).
> I have NO idea (I'm a software guy) how, what, why, where or
when... but it seems this, and ONLY
> this, extra (few bytes) in execution time makes all the differennce.
>
> I bet that anyone with a LPC21xx (06) eval board who would also run
this code would have it just
> work as it is supposed to work.
>
> (I only bet a quarter... I have been wrong before!)
>
> ~ Paul Claessen
> ----- Original Message -----
> From: "mattwoolsey"
> To:
> Sent: Saturday, May 10, 2008 10:18 PM
> Subject: [lpc2000] Re: UART stuck waiting for THRE
> --- In l..., Robert Adsett
> wrote:
> >
> I've run into plenty of Heisenbugs. :)
>
> I added turning on an LED just before the loop and turning it off
> after the loop. The LED does indeed stay on. When I change the one
> parameter from int to char, it blinks.
>
> //-------------
>
> int sendchar (int ch) // <--- the THRE bit never goes high again if
> this is int parameter!!!
> //int sendchar (char ch)
> { /* Write character to Serial Port */
> int i;
>
> IOCLR = 0x00008000;
> for(i=0;i<1000;i++); // <--- just enough delay to see the LED
> blink
>
> while (!(UxLSR & 0x20))
> {
> }
>
> IOSET = 0x00008000;
>
> return (UxTHR = ch);
> }
>
> //-------------
>
> MX
> > At 01:57 AM 5/11/2008 +0000, mattwoolsey wrote:
> > >--- In l..., Robert Adsett
> > >wrote:
> > >
> > > > Somehow I think the problem is somewhere else entirely. Are
you
> > >running
> > > > any interrupts? Why are you sure it's stuck in that loop?
> > >
> > >No interrupts are running. I know it's stuck in the loop,
because
> I
> > >can comment out that line and then all the characters get sent.
> >
> > That's a hint, but it doesn't prove it's stuck there. Have you
> heard the
> > term Heisenbug?
> >
> > > > In that loop there are only a few possibilities
> > > > - You are addressing the wrong location (not likely
> since
> > >it's
> > > > reloaded)
> > > > - The location is really returning a value without
the
> > >6'th bit set
> > > >
> > > > For the second to be true the character must not have been
sent.
> > >For it
> > > > not to have been sent there must be some reason separate from
> this
> > >piece of
> > > > code.
> > > >
> > > > Both are easily checkable walking through the loop if you are
> > >running a
> > > > JTAG debugger.
> > >
> > >Sorry, no JTAG on this one. This is a really small board design
> that
> > >doesn't even have room for the JTAG header. I already had a big
> > >application up and running. Then decided to try the latest Keil
> > >tools with the new compiler and things quit working. Even the
> serial
> > >port wouldn't work. So I went back to the bare minimum and ran
> into
> > >this strange issue.
> >
> > Well I don't see how it can be in your loop, so time to prove if
it
> really
> > is. Steal an output pin. Set it high just before you enter the
> loop and
> > low when you exit. If it sticks high you will start to convince
me.
> >
> > Robert
> >
> > "A million lines of code costs $20m to $40m ..... a million times
> > the cost of the flash chips it lives in. .... Yet accounting
screams
> > over each added penny in recurring costs, while chanting the
> > dual mantras 'software is free,' and 'hey, it's only a software
> > change.'" Jack Ganssle in "A Million Lines of Code"
> >
> > Robert Adsett - http://www.aeolusdevelopment.com/
>
Reply by ●May 10, 20082008-05-10
At 02:18 AM 5/11/2008 +0000, mattwoolsey wrote:
>--- In l..., Robert Adsett
>wrote:
> >
>I've run into plenty of Heisenbugs. :)
>
>I added turning on an LED just before the loop and turning it off
>after the loop. The LED does indeed stay on. When I change the one
>parameter from int to char, it blinks.
>
>//-------------
>
>int sendchar (int ch) // <--- the THRE bit never goes high again if
>this is int parameter!!!
>//int sendchar (char ch)
>{ /* Write character to Serial Port */
> int i;
>
> IOCLR = 0x00008000;
> for(i=0;i<1000;i++); // <--- just enough delay to see the LED
That delay bothers me. I'd want to see it without the delay. You will
need an oscilloscope or logic analyzer of course.
Robert
http://www.aeolusdevelopment.com/
From the Divided by a Common Language File (Edited to protect the guilty)
ME - "I'd like to get Price and delivery for connector Part # XXXXX"
Dist./Rep - "$X.XX Lead time 37 days"
ME - "Anything we can do about lead time? 37 days seems a bit high."
Dist./Rep - "that is the lead time given because our stock is live.... we
currently have stock."
>--- In l..., Robert Adsett
>wrote:
> >
>I've run into plenty of Heisenbugs. :)
>
>I added turning on an LED just before the loop and turning it off
>after the loop. The LED does indeed stay on. When I change the one
>parameter from int to char, it blinks.
>
>//-------------
>
>int sendchar (int ch) // <--- the THRE bit never goes high again if
>this is int parameter!!!
>//int sendchar (char ch)
>{ /* Write character to Serial Port */
> int i;
>
> IOCLR = 0x00008000;
> for(i=0;i<1000;i++); // <--- just enough delay to see the LED
That delay bothers me. I'd want to see it without the delay. You will
need an oscilloscope or logic analyzer of course.
Robert
http://www.aeolusdevelopment.com/
From the Divided by a Common Language File (Edited to protect the guilty)
ME - "I'd like to get Price and delivery for connector Part # XXXXX"
Dist./Rep - "$X.XX Lead time 37 days"
ME - "Anything we can do about lead time? 37 days seems a bit high."
Dist./Rep - "that is the lead time given because our stock is live.... we
currently have stock."
Reply by ●May 10, 20082008-05-10
At 10:29 PM 5/10/2008 -0400, Paul Claessen wrote:
>Is this 'custom' made hardware?
>I'm beginning to suspect hardware.. I base this on the fact that MX just
>sent me his project files.
>Not having a 21xx I ran it on the emulator.
>It just works fine... as expected.
>
>The int/char thing doesn't make any difference logically.
>The ONLY thing I can see change is TIMING. Granted, the int version only
>marginally takes more time
>(0xff mask).
>I have NO idea (I'm a software guy) how, what, why, where or when... but
>it seems this, and ONLY
>this, extra (few bytes) in execution time makes all the differennce.
It does use a slightly different register set as well. I don't see how
that is likely to make a difference either.
>I bet that anyone with a LPC21xx (06) eval board who would also run this
>code would have it just
>work as it is supposed to work.
Testing on an eval board with JTAG makes a lot of sense. I can't quite
envision what sort of HW failure would cause this either. Maybe a power
supply right on the edge?
>(I only bet a quarter... I have been wrong before!)
Reminds me of an add (by an ICE vendor IIRC) showing a printer spewing out
paper airplanes with the tagline "Quick! Is it hardware or software?"
I'm obviously easily amused.
Robert
Another sign of the end of civilization, our technical magazines are
getting chatty
From an EETimes product descriptions 2006/08/09
".... systems that can sample gobs of inputs simultaneously"
Now just what is the technical definition for gobs again?
http://www.aeolusdevelopment.com/
>Is this 'custom' made hardware?
>I'm beginning to suspect hardware.. I base this on the fact that MX just
>sent me his project files.
>Not having a 21xx I ran it on the emulator.
>It just works fine... as expected.
>
>The int/char thing doesn't make any difference logically.
>The ONLY thing I can see change is TIMING. Granted, the int version only
>marginally takes more time
>(0xff mask).
>I have NO idea (I'm a software guy) how, what, why, where or when... but
>it seems this, and ONLY
>this, extra (few bytes) in execution time makes all the differennce.
It does use a slightly different register set as well. I don't see how
that is likely to make a difference either.
>I bet that anyone with a LPC21xx (06) eval board who would also run this
>code would have it just
>work as it is supposed to work.
Testing on an eval board with JTAG makes a lot of sense. I can't quite
envision what sort of HW failure would cause this either. Maybe a power
supply right on the edge?
>(I only bet a quarter... I have been wrong before!)
Reminds me of an add (by an ICE vendor IIRC) showing a printer spewing out
paper airplanes with the tagline "Quick! Is it hardware or software?"
I'm obviously easily amused.
Robert
Another sign of the end of civilization, our technical magazines are
getting chatty
From an EETimes product descriptions 2006/08/09
".... systems that can sample gobs of inputs simultaneously"
Now just what is the technical definition for gobs again?
http://www.aeolusdevelopment.com/
Reply by ●May 10, 20082008-05-10
Power supply measures 3.27v and 1.797v.
--- In l..., Robert Adsett
wrote:
>
> At 10:29 PM 5/10/2008 -0400, Paul Claessen wrote:
> >Is this 'custom' made hardware?
> >I'm beginning to suspect hardware.. I base this on the fact that
MX just
> >sent me his project files.
> >Not having a 21xx I ran it on the emulator.
> >It just works fine... as expected.
> >
> >The int/char thing doesn't make any difference logically.
> >The ONLY thing I can see change is TIMING. Granted, the int
version only
> >marginally takes more time
> >(0xff mask).
> >I have NO idea (I'm a software guy) how, what, why, where or
when... but
> >it seems this, and ONLY
> >this, extra (few bytes) in execution time makes all the
differennce.
>
> It does use a slightly different register set as well. I don't see
how
> that is likely to make a difference either.
> >I bet that anyone with a LPC21xx (06) eval board who would also
run this
> >code would have it just
> >work as it is supposed to work.
>
> Testing on an eval board with JTAG makes a lot of sense. I can't
quite
> envision what sort of HW failure would cause this either. Maybe a
power
> supply right on the edge?
>
> >(I only bet a quarter... I have been wrong before!)
>
> Reminds me of an add (by an ICE vendor IIRC) showing a printer
spewing out
> paper airplanes with the tagline "Quick! Is it hardware or
software?"
>
> I'm obviously easily amused.
>
> Robert
>
> Another sign of the end of civilization, our technical magazines
are
> getting chatty
> From an EETimes product descriptions 2006/08/09
> ".... systems that can sample gobs of inputs simultaneously"
> Now just what is the technical definition for gobs again?
> http://www.aeolusdevelopment.com/
>
--- In l..., Robert Adsett
wrote:
>
> At 10:29 PM 5/10/2008 -0400, Paul Claessen wrote:
> >Is this 'custom' made hardware?
> >I'm beginning to suspect hardware.. I base this on the fact that
MX just
> >sent me his project files.
> >Not having a 21xx I ran it on the emulator.
> >It just works fine... as expected.
> >
> >The int/char thing doesn't make any difference logically.
> >The ONLY thing I can see change is TIMING. Granted, the int
version only
> >marginally takes more time
> >(0xff mask).
> >I have NO idea (I'm a software guy) how, what, why, where or
when... but
> >it seems this, and ONLY
> >this, extra (few bytes) in execution time makes all the
differennce.
>
> It does use a slightly different register set as well. I don't see
how
> that is likely to make a difference either.
> >I bet that anyone with a LPC21xx (06) eval board who would also
run this
> >code would have it just
> >work as it is supposed to work.
>
> Testing on an eval board with JTAG makes a lot of sense. I can't
quite
> envision what sort of HW failure would cause this either. Maybe a
power
> supply right on the edge?
>
> >(I only bet a quarter... I have been wrong before!)
>
> Reminds me of an add (by an ICE vendor IIRC) showing a printer
spewing out
> paper airplanes with the tagline "Quick! Is it hardware or
software?"
>
> I'm obviously easily amused.
>
> Robert
>
> Another sign of the end of civilization, our technical magazines
are
> getting chatty
> From an EETimes product descriptions 2006/08/09
> ".... systems that can sample gobs of inputs simultaneously"
> Now just what is the technical definition for gobs again?
> http://www.aeolusdevelopment.com/
>
Reply by ●May 11, 20082008-05-11
At 02:58 AM 5/11/2008 +0000, mattwoolsey wrote:
>Power supply measures 3.27v and 1.797v.
In this case if it's a problem it's likely a dynamic issue. The only way
you might see it would be with an oscilloscope. Getting it to trigger
would likely be an issue though. A related possibility would be inadequate
decoupling/failed decoupling caps. Or a problem with the power supply layout.
Robert
http://www.aeolusdevelopment.com/
From the Divided by a Common Language File (Edited to protect the guilty)
ME - "I'd like to get Price and delivery for connector Part # XXXXX"
Dist./Rep - "$X.XX Lead time 37 days"
ME - "Anything we can do about lead time? 37 days seems a bit high."
Dist./Rep - "that is the lead time given because our stock is live.... we
currently have stock."
>Power supply measures 3.27v and 1.797v.
In this case if it's a problem it's likely a dynamic issue. The only way
you might see it would be with an oscilloscope. Getting it to trigger
would likely be an issue though. A related possibility would be inadequate
decoupling/failed decoupling caps. Or a problem with the power supply layout.
Robert
http://www.aeolusdevelopment.com/
From the Divided by a Common Language File (Edited to protect the guilty)
ME - "I'd like to get Price and delivery for connector Part # XXXXX"
Dist./Rep - "$X.XX Lead time 37 days"
ME - "Anything we can do about lead time? 37 days seems a bit high."
Dist./Rep - "that is the lead time given because our stock is live.... we
currently have stock."
Reply by ●May 11, 20082008-05-11
Things look good on my scope here, but I only have a 20MHz. I'll
take it in to work on Monday and check it out on a faster scope.
MX
--- In l..., Robert Adsett
wrote:
>
> At 02:58 AM 5/11/2008 +0000, mattwoolsey wrote:
> >Power supply measures 3.27v and 1.797v.
>
> In this case if it's a problem it's likely a dynamic issue. The
only way
> you might see it would be with an oscilloscope. Getting it to
trigger
> would likely be an issue though. A related possibility would be
inadequate
> decoupling/failed decoupling caps. Or a problem with the power
supply layout.
>
> Robert
>
> http://www.aeolusdevelopment.com/
>
> From the Divided by a Common Language File (Edited to protect the
guilty)
> ME - "I'd like to get Price and delivery for connector Part # XXXXX"
> Dist./Rep - "$X.XX Lead time 37 days"
> ME - "Anything we can do about lead time? 37 days seems a bit
high."
> Dist./Rep - "that is the lead time given because our stock is
live.... we
> currently have stock."
>
take it in to work on Monday and check it out on a faster scope.
MX
--- In l..., Robert Adsett
wrote:
>
> At 02:58 AM 5/11/2008 +0000, mattwoolsey wrote:
> >Power supply measures 3.27v and 1.797v.
>
> In this case if it's a problem it's likely a dynamic issue. The
only way
> you might see it would be with an oscilloscope. Getting it to
trigger
> would likely be an issue though. A related possibility would be
inadequate
> decoupling/failed decoupling caps. Or a problem with the power
supply layout.
>
> Robert
>
> http://www.aeolusdevelopment.com/
>
> From the Divided by a Common Language File (Edited to protect the
guilty)
> ME - "I'd like to get Price and delivery for connector Part # XXXXX"
> Dist./Rep - "$X.XX Lead time 37 days"
> ME - "Anything we can do about lead time? 37 days seems a bit
high."
> Dist./Rep - "that is the lead time given because our stock is
live.... we
> currently have stock."
>
