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) ;

:-/

Reply to
Noodnik
Loading thread data ...

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

Reply to
David Brown

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.
Reply to
Stef

ed

the

a

in

le

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.
Reply to
robertwessel2

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

formatting link

Reply to
Vladimir Vassilevsky

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

Vladimir Vassilevsky DSP and Mixed Signal Design Consultant

formatting link

Reply to
Vladimir Vassilevsky

On 08.12.2010 10:00, Noodnik wrote: [...]

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.

Reply to
Hans-Bernhard Bröker
[...]

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.

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:
Reply to
Oliver Betz

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     /\/\/\/\/
 Click to see the full signature
Reply to
Chris H

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).

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.

Reply to
David Brown

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.