No sympathy expected......

No advice required, just need to tell people who might understand, if not 
sympathise, about my last 2 hours.....

Got stuck with an HCS12 program that's grown into a bit of a monster. Added 
serial IO and things went off the rails.

Program structure like this:

void main()
{
general setup stuff
enable various interrupts

while (1)
    {
    background processing    ;
    }
}

ISR1 {}
ISR2{}
......

getchar()  {}  very basic

putchar()  {} very basic too


Anyway, I couldn't get the getchar and putchar to work reliably, despite the 
fact that they're nothing more than the standard status wait followed by a 
read. The SIO worked OK if I embedded the functions into an ISR, but within 
the main while loop... nothing. Tried all sorts of things, read the chip 
datasheet again and again in case there's something strange about HCS12 
serial, ended up with weird theories that maybe the waits in the SIO 
functions were causing a lockup, which is just dumb.

Anyway, finally took a closer look at the code, particularly the main while 
loop, it started like this....

while (1)                ;

:-/

On 08/12/2010 10:00, Noodnik wrote:
> No advice required, just need to tell people who might understand, if not
> sympathise, about my last 2 hours.....
>
> Got stuck with an HCS12 program that's grown into a bit of a monster. Added
> serial IO and things went off the rails.
>
> Program structure like this:
>
> void main()
> {
> general setup stuff
> enable various interrupts
>
> while (1)
>      {
>      background processing    ;
>      }
> }
>
> ISR1 {}
> ISR2{}
> ......
>
> getchar()  {}  very basic
>
> putchar()  {} very basic too
>
>
> Anyway, I couldn't get the getchar and putchar to work reliably, despite the
> fact that they're nothing more than the standard status wait followed by a
> read. The SIO worked OK if I embedded the functions into an ISR, but within
> the main while loop... nothing. Tried all sorts of things, read the chip
> datasheet again and again in case there's something strange about HCS12
> serial, ended up with weird theories that maybe the waits in the SIO
> functions were causing a lockup, which is just dumb.
>
> Anyway, finally took a closer look at the code, particularly the main while
> loop, it started like this....
>
> while (1)                ;
>
> :-/
>
>

Maybe it's time to change your code format system to:

while (1) {
	.... ;
}

It's more compact, and makes a couple of mistakes (like your one here) 
harder to make.

Other than that, yes, I can sympathise with you.  Most of us have had 
occasion to spend more than just a couple of hours chasing a typo like that.

mvh.,

David

In comp.arch.embedded,
Noodnik <Noodnik@NotHere.com> wrote:
> No advice required, just need to tell people who might understand, if not 
> sympathise, about my last 2 hours.....

<searching the fault in all the wrong places>

> Anyway, finally took a closer look at the code, particularly the main while 
> loop, it started like this....
>
> while (1)                ;
>
>:-/

Sympathy? You're lucky you found it in 2 hours! :-)

You are certainly not the first to make a silly mistake like this.
And 2 hours is by far not the longest anyone has ever 'debugged' a
silly typo like this.

HTH, HAND,

-- 
Stef    (remove caps, dashes and .invalid from e-mail address to reply by mail)

There is no grief which time does not lessen and soften.

On Dec 8, 3:00=A0am, "Noodnik" <Nood...@NotHere.com> wrote:
> No advice required, just need to tell people who might understand, if not
> sympathise, about my last 2 hours.....
>
> Got stuck with an HCS12 program that's grown into a bit of a monster. Add=
ed
> serial IO and things went off the rails.
>
> Program structure like this:
>
> void main()
> {
> general setup stuff
> enable various interrupts
>
> while (1)
> =A0 =A0 {
> =A0 =A0 background processing =A0 =A0;
> =A0 =A0 }
>
> }
>
> ISR1 {}
> ISR2{}
> ......
>
> getchar() =A0{} =A0very basic
>
> putchar() =A0{} very basic too
>
> Anyway, I couldn't get the getchar and putchar to work reliably, despite =
the
> fact that they're nothing more than the standard status wait followed by =
a
> read. The SIO worked OK if I embedded the functions into an ISR, but with=
in
> the main while loop... nothing. Tried all sorts of things, read the chip
> datasheet again and again in case there's something strange about HCS12
> serial, ended up with weird theories that maybe the waits in the SIO
> functions were causing a lockup, which is just dumb.
>
> Anyway, finally took a closer look at the code, particularly the main whi=
le
> loop, it started like this....
>
> while (1) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0;


Not to be too preachy, but turning up the warning level on your
compiler* or, even better, using a proper lint, should have resulting
in warning about unreachable code and indenting oddness (OK, only lint
for the latter).  And yes, lint on embedded systems can take some
getting used to.

But still, been there, done that...  One of my personal =93favorites=94 is
when someone swapped the condition and increment portions of a for() =96
I looked at that for() statement a hundred times before I noticed that
it was swapped.

*acknowledging that many compilers for controllers are POS's, where
you need to be happy if they actually happen generate running code...
Which may or may not include the one you=92re using - I have no idea.

Noodnik wrote:

> No advice required, just need to tell people who might understand, if not 
> sympathise, about my last 2 hours..... 
> Anyway, finally took a closer look at the code, particularly the main while 
> loop, it started like this....
> 
> while (1)                ;

Congratulations. Along with volatiles and opening files in the text 
mode, this is the one of those mistakes that everybody has to come 
through. Some 20 years ago I did the same mistake with if() operator. 
Never fall into this trap since then.


Vladimir Vassilevsky
DSP and Mixed Signal Design Consultant
http://www.abvolt.com

Noodnik wrote:


> while (1) ;
>     {
>     background processing    ;
>     }

What compiler is this?
Any sensible compiler would issue "no entry to code" warning.


Vladimir Vassilevsky
DSP and Mixed Signal Design Consultant
http://www.abvolt.com

On 08.12.2010 10:00, Noodnik wrote:
[...]
> Anyway, finally took a closer look at the code, particularly the main while
> loop, it started like this....
>
> while (1)                ;
>
> :-/

Well on the positive side I think we all agree that this taught you an 
important lesson, in the only way that's known to _really_ work: the 
painful one.  This particular nugget has hit just about every one of us 
in the face --- the trick lies in avoiding the repetition of this lesson.

So, class, let's all get up and join in the obligatory recital of the 
school motto, shall we?

	Lint early!
	Lint often!
	Lint is your friend!

Lint (with a decent choice of settings) would have slapped you with not 
just one, but two unmistakable warnings about that code:

* while() with no braces around the controlled statement
* unreachable code

And please allow me to suggest that if this took two hours to find, you 
may need to improve your debugging tactics.

Hans-Bernhard Br�ker wrote:

[...]

>	Lint early!
>	Lint often!
>	Lint is your friend!
>
>Lint (with a decent choice of settings) would have slapped you with not 
>just one, but two unmistakable warnings about that code:

exactly.

The old "Programming languages are like cars" joke describes lint as
"optional" seatbelt, but isn't using the seatbelt mandatory these
days?

And PC-Lint evolved to more than a seatbelt, rather an airbag. Don't
know about Splint.

>* while() with no braces around the controlled statement
>* unreachable code
>
>And please allow me to suggest that if this took two hours to find, you 
>may need to improve your debugging tactics.

especially because HCS12 debugging is usually done with a decent BDM
debugger. Simply stopping the program after a while will show a bra *
instruction.

Oliver
-- 
Oliver Betz, Munich
despammed.com is broken, use Reply-To:

In message <us21g6lm64e8hs3n8lnk4t46kls56a6aec@z1.oliverbetz.de>, Oliver
Betz <obetz@despammed.com> writes
>Hans-Bernhard Br&#4294967295;ker wrote:
>>      Lint early!
>>      Lint often!
>>      Lint is your friend!
>>
>>Lint (with a decent choice of settings) would have slapped you with not
>>just one, but two unmistakable warnings about that code:
>
>exactly.
>
>The old "Programming languages are like cars" joke describes lint as
>"optional" seatbelt, but isn't using the seatbelt mandatory these
>days?
>
>And PC-Lint evolved to more than a seatbelt, rather an airbag. Don't
>know about Splint.

Somewhere else I was extolling the virtues of static analysis but was
told it was only because my company sells several static analysers.  The
person went on to say static analysis was not that important.

The reason being that work had stopped on Splint (the only Open Source
static analyser apparently) several years ago.

Had static analysis been any use apparently IBM et all would have paid
to have Splint finished....



-- 
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

On 09/12/2010 12:36, Chris H wrote:
> In message<us21g6lm64e8hs3n8lnk4t46kls56a6aec@z1.oliverbetz.de>, Oliver
> Betz<obetz@despammed.com>  writes
>> Hans-Bernhard Br&#4294967295;ker wrote:
>>>       Lint early!
>>>       Lint often!
>>>       Lint is your friend!
>>>
>>> Lint (with a decent choice of settings) would have slapped you with not
>>> just one, but two unmistakable warnings about that code:
>>
>> exactly.
>>
>> The old "Programming languages are like cars" joke describes lint as
>> "optional" seatbelt, but isn't using the seatbelt mandatory these
>> days?
>>
>> And PC-Lint evolved to more than a seatbelt, rather an airbag. Don't
>> know about Splint.
>
> Somewhere else I was extolling the virtues of static analysis but was
> told it was only because my company sells several static analysers.  The
> person went on to say static analysis was not that important.
>
> The reason being that work had stopped on Splint (the only Open Source
> static analyser apparently) several years ago.
>

Splint was, I think, academic research software.  Development has 
stagnated, partly because they have got pretty much as far as they could 
get without major changes to the software, and probably because the 
people involved have moved on.

There are lot of open source static analysers around - unfortunately, 
there are not yet any usable FOSS general C or C++ static analysers. 
Splint never supported C++, probably never will.  But there /are/ static 
analysis tools for a number of other languages, such as Java and Python 
(it's particularly useful for Python, since the language's dynamic 
nature means many errors are not seen until run time).

There are also plenty of specialised tools.  For example, there is 
"sparse" for finding particular kinds of pointer issues in the Linux 
kernel, and tools for checking for common security bugs (like potential 
buffer overflows).

Additionally, there are many run-time tools, particularly for things 
like memory allocation checking.

The current trend is to use compilers as the base for general static 
analysers, but the available tools don't yet cover the range of checks 
of, for example, pc-lint.  gcc by itself will do an impressive amount of 
static error checking, including spotting the bug here, as long as you 
enable the warnings.

Beyond that, there are tools like Dehydra (a plugin for gcc, developed 
by Mozilla and therefore sponsored by Google) and Clang static analysis 
(a target for llvm, heavily backed by Apple).

> Had static analysis been any use apparently IBM et all would have paid
> to have Splint finished....
>

I wouldn't say that static analysis has no use.  But I /would/ say that 
a tool like pc-lint is not the sort of "magic bullet" against bugs that 
some people seem to think.  It helps catch typos and small mistakes, and 
a number of subtle ones - but so does gcc.  I think the gap between 
gcc's warnings and pc-lint's here is fairly small.  If you write clear, 
well-planned (and preferably well-documented) code, then you are already 
making use of the best static analyser available - a good programmer.

Where pc-lint can really shine is when you make use of its special 
structured comments to add information that the C compiler does not 
have.  You can tell pc-lint that the variable "x" must have a range from 
0 to 4 - then it will check it for you.  But you are no longer 
programming in C - you are programming in C with pc-lint extensions. 
You have to question how this affects the readability and 
maintainability of your code - done well, it's probably a good thing, 
but is it worth the effort?  If it /is/ worth the effort, would it not 
be better to switch to a language like Ada that supports these concepts 
natively in the language?  And what about the levels of false-positives? 
  Tuning a tool like pc-lint to give warnings on real issues but not on 
false positives is far from easy, especially if you are using existing 
code that was not written from scratch to work well with tighter static 
analysis.

If you have a solid test procedure, including unit tests and functional 
tests, how much more does advanced static analysis give you?  It 
certainly can't replace the dynamic testing.

As I say, I am far from being against the use of tools like pc-lint, and 
I think some base level of static analysis is an essential tool.  And 
sometimes there are specific types of work that greatly benefit from 
such tools.  But beyond that, you only get benefit from it according to 
the effort you put into it.