Are there any good LINT programs for development in a microcontroller environment? I do not know much about LINT but I have read that when properly used it enforces good coding practice. I am willing to try it out but all the ones I have found are for unix/linux.
regards,
Bradley
snipped-for-privacy@canoemail.com (Bradley) wrote in news: snipped-for-privacy@posting.google.com:
Look for lclint, I think there's a win32 port.
-- - Mark -> --
PC-Lint by Gimpel is the gold standard, and it runs very happily under Windows. The only negative might be the cost, about $160, but everybody I know who uses it thinks it's well worth it.
Bradley wrote: : Are there any good LINT programs for development in a microcontroller : environment? I do not know much about LINT but I have read that when : properly used it enforces good coding practice. I am willing to try it : out but all the ones I have found are for unix/linux. :
In what language? Lint doesn't do much good in assembly... although I suppose someone somewhere could write a 'lint' for one specific assembly language, there's not much out there yet.
if you're writing in C, there are a number of syntax checkers which vary from free to very expensive. Search google for more :)
Regards, Buddy
-- Remove '.spaminator' and '.invalid' from email address when replying.
Two options spring to mind.
Splint (previously LCLint)
PC-Lint
Andy
PC-Lint from gimpel
Rob
-- Robert Kaiser email: rkaiser AT sysgo DOT com SYSGO AG http://www.elinos.com Klein-Winternheim / Germany http://www.sysgo.com
Lclint is now splint, I believe. That's what shows up at lclint.cs.virginia.edu, anyway. It may take a bit of work to get splint to work on code written for compilers targetting microcontrollers, but it's probably worth the effort.
There's also PC-lint/FlexeLint from Gimpel, which is very adaptable, and includes adaptations for many compilers like Keil's C51. I highly recommend it, though it's not free. PC-lint is about $250, Flexelint somewhat more. PC-lint might run under wine or dosemu, but I've never tried it.
Regards,
-=Dave
-- Change is inevitable, progress is not.
It will pay for itself within minutes of opening the box, and will become a way of life for you. There have been many discussions of this excellent product on this group...
pete
-- pete@fenelon.com "there's no room for enigmas in built-up areas."
There's a benefit to Gimpel's PC-Lint that isn't mentioned nearly often enough, and that's how useful it can be to someone who, like the OP, is learning C or C++. If you don't happen to be working closely with an expert who can coach you on good coding practices, PC-Lint can help you learn to write clean code before bad habits become entrenched.
There's a step-by-step guide for getting splint integrated into the Imagecraft AVR compiler at
-- Rich Webb Norfolk, VA
Lint checks your source files against standards. It has nothing to do with the end execution environment. Most versions have varius means of customizing so as to ignore certain poor coding practices, and make it easier to use on non-standard source code. Lints will also often warn about legal, but dangerous, practices.
Pclint and Flexelint (from Gimpel) run on the MsDos/Windows or Unix/Linux systems. Splint, now known as lclint, is free, has source available, and runs on many systems.
Your best good coding practice is to adhere to the ISO standard. Where you have to make non-portable deviations, isolate them in separate files and functions.
--
Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
Available for consulting/temporary embedded and systems.
USE worldnet address!
Actually one of the great strengths of PC-Lint -- I don't know about Splint -- is the ability to customize its checks for various compilers, even when they _don't_ comply with the standard.
Compilers for embedded chips typically reflect the target processor design, either through language extensions (e.g., memory models for the x86 real mode operation), restrictions to a subset of the language, or non-standard meanings of keywords. The size of atomic types like char also varies with the target: 16-bit chips that don't support byte addressing will have 16-bit chars. I once did a lot of C programming for the TI 34010, which was a bit addressable graphics processor, and for which sizeof(char) was 8, not 1. PC-Lint provides numerous ways to tailor its operation to a particular architectures (including specifying sizeof(char)).
Andy writes: "(these are switches that stop warnings which I'm not too bothered about - I'll probably regret some of these later!)" - yes, probably. He uses a rather extensive suppresion.
Among others, because Splint can't deal with literal assignments to char. Since the literal is "int", Splint complains about "Assignment of int to unsigned char" although it's small enough.
After all, I'm not sure what the LCC substitution %f is: all project files or only one? For a correct analysis, you have to pass _all_ source files to *lint.
Oliver
-- Oliver Betz, Muenchen
By definition, sizeof(char) is 1. CHAR_BIT could be 64, however.
-- Al Balmer Balmer Consulting removebalmerconsultingthis@att.net
You are correct regarding what the standard says, but my point was that PC-Lint lets you do static checking even for compilers which _don't_ comply with the standard, as was the case for the TI compiler.
Interesting processor. I dug for some info, since I wasn't familiar with it (though I remembered the associated graphic mode.) I suppose all C bets are off, since it was developed before the standard. Apparently they decided that sizeof would return the number of addressable units in an object, and the 34010 was bit addressable. Someone has done a gcc code generator for it, but I don't know how it reports sizeof(char).
-- Al Balmer Balmer Consulting removebalmerconsultingthis@att.net
The 340x0 compiler that was sold by TI, and written by LPI (Language Processors Inc??), was actually a very nice one, putting aside certain oddities due to the target chips. For a brief time before the PCI bus came out, the highest performance graphic boards for PCs used the TIGA standard, which defined a powerful and elegant interface between the PC processor and a 34010/20 on the graphics board. Some of TI's OMAP architecture is reminiscent of the TIGA approach,
340x0 processors were popular in embedded (non-PC) applications because of they were well documented (unlike most graphics chipsets), had good tool support and could be purchased in moderate quantities.
And a guide for the CCS C compiler (for Microchip PICs):
Has anyone done CCS C compiler (for Microchip PICs) for PC_LINT?
I use PC-lint with CCS. I always use
#pragma case #pragma type short=16, int=16, long=32
and my setup relies on that. I use -si2 -sf4.
I created a co-ccs.lnt file to contain some of the common options. These are mostly things like +ppw(asm,endasm) and +ppw(device,use). I also have +rw(_bit) -dbit=_bit -dint1=_bit.
Other than that, the only special options required seem to be
-elib(677) (use of sizeof in preprocessor #if statement) and
-elib(683) (library function #defined to another symbol) to overcome some deficiencies in the header files. (Assuming -wlib(1))
But you have to make some adjustments in the source code. For example,
#pragma byte TMR0 = 0x01
becomes
#if defined(_lint) unsigned char volatile TMR0; #else #pragma byte TMR0 = 0x01 #endif
You might need a -esym(552,...) (written but not read) and
-esym(729,...) (not initialized before use) on some of these, as well as -esym(714,...) on your ISRs.
I also have a header that defines some of the intrinsics as library functions, e.g.
#if defined(_lint) //lint ++flb void output_low(int); void output_high(int); // etc. //lint --flb #endif
Other than that, it should work about the same as anything else. HTH,
-=Dave
-- Change is inevitable, progress is not.
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.