Splint now in WinAVR

Go To Last Post
39 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Now that Splint is part of WinAVR (20100110) I thought I'd give it a go. But for the life of me I cannot get it to see the LARCH_PATH:

D:\test>splint -D__AVR_ATmega16__ -IC:\WinAVR-20100110\avr\include -larchpath c:\WinAVR-20100110\share\splint\lib -lclimportdir c:\WinAVR-20100110\share\splint\imports -unrecogcomments test.c
Splint 3.1.2 --- 07 Jan 2010

Cannot find standard library: standard.lcd
     Check LARCH_PATH environment variable.
test.c: (in function main)
test.c:17:8: Test expression for while not boolean, type int: 1
  Test expression type is not boolean or int. (Use -predboolint to inhibit warning)
test.c:3:18: Variable exported but not used outside test: global_r18
  A declaration is exported, but not used outside this module. Declaration can use static qualifier. (Use -exportlocal to inhibit warning)

Finished checking --- 2 code warnings

That's just one of many tries I've made - this time using -larchpath and I know that standard.lcd is in the named directory but whether I use this or the LARCH_PATH environment var I cannot make the warning about standard.lcd disappear.

Anyway the above shows a few useful things such as the fact that you have to manually make the -D for the architecture selector that would usually be made by -mmcu= on the compiler command line.

It also shows that Splint does not like things like the Doxygen comment:

/*@{*/

in stdint.h but this is over-ridden by -unrecogcomments

It also shows that you use -I (no space) to give the path where the AVR system headers are. Sadly it almost defaults to the right thing but uses "C:\Winavr\..." rather than "C:\Winavr20100110\..." where the WinAVR will actually be installed.

If anyone else "plays" with Splint, now it's there for everyone to use, perhaps you can add to this thread to say what you learned about its use too?

Cliff

PS A tool like Lint or Splint is invaluable if you can make it work - so it's well worth exploring a bit.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yes, I spotted your heads-up in the canonical release thread by EW, and have planned to give it a go if I find the time.

Quote:

A tool like Lint or Splint is invaluable if you can make it work - so it's well worth exploring a bit.

Agree 100%.

Quote:
you have to manually make the -D for the architecture selector that would usually be made by -mmcu= on the compiler command line

It would be nice if the Mfile template makefile was augmented with a "splint" target, that could deduce the -D from the MCU= (if you understand what I mean by that...). I've been planning to take a peek at some other things in that template for quite a while so I might contribute that soon. If it actually makes it to "the official distribution" is of-course up to Jörg.

Quote:
It also shows that you use -I (no space) to give the path where the AVR system headers are.

The makefile, and the "splint" target, could handle this too, I suppose.

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The MFile template is also the same as the WinAVR Makefile Template. I never had the time to work out how to use splint, hence nothing in the Makefile Template. I would be interested in any feedback on what would make a good Makefile target to use splint generically with any AVR application.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

One of the tricky bits is going to be to make that transition from MCU=xxxxx to -D__AVR_yyyyy__

Where is the actual look up table that usually makes this translation? Somewhere in the GCC source? Presumably each time a new device is added to avr-gcc the table for -mmcu= support must be updated?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
One of the tricky bits is going to be to make that transition from MCU=xxxxx to -D__AVR_yyyyy__

Where is the actual look up table that usually makes this translation? Somewhere in the GCC source? Presumably each time a new device is added to avr-gcc the table for -mmcu= support must be updated?

That is correct, it is in the GCC source, and yes, every new device must update this table. However, if you look closely it is not that hard to convert between the two.

The -mmcu= flag has everything in lowercase. The __AVR_yyyy__ symbol has the proper device name.

For example
__AVR_ATmega128__
becomes
atmega128

The 'AT' is always uppercase. Lowercase 'mega', 'tiny', 'xmega'. Then numbers. Any alphabetical characters after the number are always uppercase.

One could put together a sed script to do the conversion in the Makefile. (IIRC, sed is shipped with WinAVR.) This would a typical way of handling this type of problem.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

One or a few GNU Make functions should also be able to do that, although I don't have the details right now..

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

JohanEkdahl wrote:
One or a few GNU Make functions should also be able to do that, although I don't have the details right now..

I know that you can substitute strings with a Make function. I'm not sure if Make has advanced pattern matching like sed does. But yeah there's a lot of ways to do this. One could write a one-line awk script to do it too. gawk is included in WinAVR.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The algorithm to go from the device name (-mmcu= flag) to the definition (-D flag) should be something like:

1. Uppercase all characters
2. Search for, and lower the case of strings in this order:
- XMEGA
- MEGA
- TINY
3. Add prefix: __AVR_
4. Add suffix: __

That should probably cover it.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Advanced sed capabilties not needed here.
"mcu" switches usually get MCU variable
-mmcu=$(MCU) for compilr
--mcu=$(MCU) for elf-size
so, we can handle the variable and create another variable

# can beused not only for splint
MCUDEF=$(subst at,__AVR_AT,$(MCU))__
...
splnt:
	... -D$(MCUDEF)

upd: no, it isn't so easy
atmega168 must be converted to __AVR_ATmega168__
attiny13 must be converted to __AVR_ATtiny13__
but
at90usb162 must be converted to __AVR_AT90USB162__

wbr, ReAl

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ReAlAl wrote:

upd: no, it isn't so easy
atmega168 must be converted to __AVR_ATmega168__
attiny13 must be converted to __AVR_ATtiny13__
but
at90usb162 must be converted to __AVR_AT90USB162__

So far the algorithm I described will correctly fit that variant in.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have collected a bit splint examples , this summer
Maybe someone can make a skeleton out of this :-)

http://www.koders.com/noncode/fi...

These are from bacnet M168 port

#!/bin/sh
# splint is a static code checker
[ -x /usr/bin/splint ] || exit 0

INCLUDES="-Iinclude -Iports/linux"
SETTINGS="-castfcnptr -fullinitblock -initallelements -weak +posixlib"

if [ ! -x .splintrc ]
then
  echo ${INCLUDES} ${SETTINGS} > .splintrc
fi

directory=${1-`pwd`}/src
for filename in $( find $directory -name '*.c' )
do
  echo splinting ${filename}
  /usr/bin/splint ${filename}
done
-sysdirs C:\WinAVR~1\avr\include;C:\WinAVR~1\lib\gcc\avr\4.2.2\include;C:\WinAVR~1\avr\include\avr;C:\WinAVR~1\avr\include\compat;C:\WinAVR~1\avr\include\util

-IC:\WinAVR~1\avr\include

-IC:\WinAVR~1\avr\include\avr

-IC:\WinAVR~1\avr\include\compat

-IC:\WinAVR~1\avr\include\util

-IC:\WinAVR~1\lib\gcc\avr\4.2.2\include

-I../../include

-I.

-castfcnptr

-fullinitblock

-weak

-D__AVR_ATmega168__

-D__GNUC__

https://www.avrfreaks.net/index.p...

Quote:

#faq 14
I develop code on an embedded system with a compiler that uses nonstandard key words and data types. I would like to run Splint on my code but these nonstandard keywords cause parse errors. What should I do?

You can often use -D to solve this problem.

If you just want to ignore a keyword, you can add -Dnonstandardkeyword= to make the preprocessor eliminate the keyword, where nonstandardkeyword is the name of the keyword. Similarly, you can use -Dspecialtype=int to make a custom type parse as an int.

Quote:
> Sfr is a command used my the compiler for registers in the Atmel chip that we are
> using.? How do I prevent these errors about Atmel registers from occurring?

My crystal ball is broken. What does the offending line of code actually look like?

The most likely fix is to use an object-style macro to define away the "sfr" token, and protect it with a compilation guard so it only takes effect when running Splint. For example:

#if defined S_SPLINT_S
#undef sfr
#define sfr
#endif

Or

As far as I know the Keil C51 Compiler, the SFR declarations looks
like:

sfr P0 = 0x80;

That is "#define sfr unsigned char" should do the trick.

HTH,

Ludolf

'''''''''''''''''''''

I think you need to conditionally define sfr (and sbit and eventually
other stuff).

You can do it in splint.rc or in a specific .h file.

----

First solution (splint.rc):

Add the following definitions in splint.rc file:

-Dsfr=volatile unsigned char
-Dsbit=volatile bool

----

Second solution (.h file):

Create a file (for example: splint.h) that contains:

#ifdef S_SPLINT_S
#define sfr volatile unsigned char
#define sbit volatile bool
#endif

Then, include this file

'''''''''''''''''''''''''''''''''''''

> That is "#define sfr unsigned char" should do the trick.

In the (few) projects checked by Splint we cheat by mocking the
microcontroller specific stuff:

#ifdef S_SPLINT_S
#include "splint.h"
#else
#include
#endif

This is from a module for an AVR compiled by avr-gcc which uses memory
placement modifiers and special functions.

The file "splint.h" contains all the #define's and such to make the
source "splintable", for example:

/* We don't want to annotate each #define */
/*@-macroconstdecl@*/
/*@-macrofcndecl@*/
/*@-macroparams@*/

/* Constants starting with E are reserved */
/*@-isoreserved@*/

/* Stuff of pgmspace.h */
/*@notfunction@*/
#define PROGMEM /* empty */
/*@notfunction@*/
#define fputs_P fputs
/*@notfunction@*/
#define pgm_read_byte(address) (*(address))

/* EEPROM bits and registers */
#define E2END 0
#define EECR (*(unsigned char *)0)
#define EEMPE 0
#define EEPE 0
#define EERE 0
#define EEAR (*(unsigned short *)0)
#define EEDR (*(unsigned char *)0)

/*@=isoreserved@*/
/*@=macroparams@*/
/*@=macrofcndecl@*/
/*@=macroconstdecl@*/

http://www.cs.virginia.edu/piper...

http://www.cs.virginia.edu/piper...

http://www.cs.virginia.edu/piper...

http://www2.imm.dtu.dk/courses/0...

German (blush ...)
http://www.linux-magazin.de/heft...
http://www.linux-magazin.de/Heft...

http://www.embeddedrelated.com/u...

Some Examples

ISR(/*@unused@*/USART_RX_vect )
{
	
....

	/*@ -whileempty @*/while( (UCSRA & USART_UDRE_MASK ) == 0); 

[/code]

Attachment(s): 

Last Edited: Tue. Jan 12, 2010 - 08:42 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

EW wrote:
So far the algorithm I described will correctly fit that variant in.
Sure, but it can't be realised using make built-in functions.
You are right about gawk also.

wbr, ReAl

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I did the conversion last night with:

splint -D`$(CC) -mmcu=$(MCU) -dM -E - < /dev/null | grep "__AVR_AT" | cut -d' ' -f2` ...

Which isn't the prettiest of things (and would be best if the MCU conversion was done once rather than for each file) but it does work. It replies on calling avr-gcc with the correct MMCU parameter on a null input file, using the -dM switch to print out all predefined macros before filtering the result for the __AVR_AT*__ entry.

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well, I'll be darned! I could have sworn that GNU Make had functions for changing case. It has not. So I'll revoke my vote for an all-Make-solution. Dean rules.

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

No Dean doesn't rule. He's using grep, cut, and other things in the ellipsis that he's not posting. Let's see a single tool that does it all. I challenge him to do it in AWK. More points if it can be done in sed alone. ;)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

No Dean doesn't rule.

Of-course he does - until someone topples him with a better running solution.

Quote:

Let's see a single tool that does it all.

Why? That sequence of pipes seems perfectly GNUish to me. And if the list of avr-gcc/avrlibc predefined macros holds the correct names for splint to use, then using that makes some sense, n'est-ce pas?

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Fair one -- I was only showing a simple (?) way to change the MCU value into the equivalent preprocessor token for splint, not showing how to get splint to actually work. My way uses the real defines for avr-libc via the preprocessor, so it will work no matter what the translation is, so long as it starts with __AVR_AT.

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

In case anybody gets crazy in WXP with splint's anachronic liking of the 8.3-shortened pathnames:

  • in command prompt (assuming cmd is used, but I for example use Total Commander), goto the required directory
  • run "command.com" (the old 16-bit shell); the default prompt is the pathname in 8.3 format
  • on the top bar of that window right-click, select edit->mark
  • highlight the pathname by mouse dragging
  • suppress your urge to press Ctrl-C, rather, press ENTER (or, for the mouse-challenged, again right-click on the top bar and select Copy from menu)
  • paste wherever needed

JW

PS. Cliff, this appears to be your problem you described in first post of this thread: you attempt to use long directory names.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

OK so my findings:

  • 8.3 path/file names are a must (bleeeeeh) - see post above
  • LARCH_PATH in environment variables (set and verified by SET) did not work
  • tried to copy/paste Bingo's .splintrc above and change the paths
  • .splintrc in the working directory got read, but -larchpath got ignored, and most other switches result in various funny error messages; paths defined by -I got malformed (even if they were of 8.3 form)
  • after some time I scrapped .splintrc altogether and threw everything on a single command line:

    splint.exe -larch_path C:\WINAVR~3\SHARE\SPLINT\LIB -lclimportdir C:\WINAVR~3\SHARE\SPLINT\IMPORTS -sysdirs C:\PROGRA~1\ATMEL\AVRTOO~1\WINAVR\avr\include;C:\PROGRA~1\ATMEL\AVRTOO~1\WINAVR\lib\gcc\avr\4.2.2\include;C:\PROGRA~1\ATMEL\AVRTOO~1\WINAVR\avr\include\avr;C:\PROGRA~1\ATMEL\AVRTOO~1\WINAVR\avr\include\compat;C:\PROGRA~1\ATMEL\AVRTOO~1\WINAVR\avr\include\util -D__AVR_ATmega128__ -D__GNUC__ -IC:\PROGRA~1\ATMEL\AVRTOO~1\WINAVR\avr\include -IC:\PROGRA~1\ATMEL\AVRTOO~1\WINAVR\avr\include\avr -IC:\PROGRA~1\ATMEL\AVRTOO~1\WINAVR\avr\include\compat -IC:\PROGRA~1\ATMEL\AVRTOO~1\WINAVR\avr\include\util  sml.c
    

    (just as illustration, no reason to copy/paste, these are MY paths etc.)

  • this finally run, but got stuck at the very first "avr-gcc-specific-extension" thing - the following declaration:

    register unsigned char _r2 asm("r2");

    and what splint spit out is:

    xxx.h:20:24: Parse Error: Non-function declaration: _r2 :
        register unsigned char. (For help on parse errors, see splint -help parseerrors.)
    *** Cannot continue.

What now?... :-(

JW

Last Edited: Wed. Jan 13, 2010 - 10:35 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Jan,

Nice idea but sadly not the solution:

D:\test>dir c:\Win* /x
 Volume in drive C is ACER
 Volume Serial Number is C6B0-75D7

 Directory of c:\

04/05/2009  13:21              WINAVR~1     WinAVR-20090313
12/01/2010  11:46              WINAVR~2     WinAVR-20100110
[snip]

D:\test>splint -D__AVR_ATmega16__ -IC:\WINAVR~2\avr\include -larchpath c:\WINAVR~2\share\splint\lib -lclimportdir c:\WINAVR~2\share\splint\imports -unrecogcomments test.c
Splint 3.1.2 --- 07 Jan 2010

Cannot find standard library: standard.lcd
     Check LARCH_PATH environment variable.

also

D:\test>set LARCH_PATH=C:\WINAVR~2\share\splint\lib

D:\test>splint -D__AVR_ATmega16__ -IC:\WINAVR~2\avr\include -lclimportdir c:\WINAVR~2\share\splint\imports -unrecogcomments test.c
Splint 3.1.2 --- 07 Jan 2010

Cannot find standard library: standard.lcd
     Check LARCH_PATH environment variable.

(I prefer /X on DIR rather than starting a whole new command prompt just to get the 8.3 name)

EDIT: Just a minute I see in your edit "-larch_path" whereas I used (because the manual told me) "-larchpath"

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
Nice idea but sadly not the solution:

Ummm.

Try perhaps all capitals. Try larchpath as the first switch. Use some magic salt and a few carefully selected incantations.

Do you run it under cmd.exe or command.com or anything else? Is it WXP at all?

Do I repeat often enough that the OS stuff (and mainly their documentation) s**ks?

JW

PS.

Cliff wrote:

(I prefer /X on DIR rather than starting a whole new command prompt just to get the 8.3 name)

Yes that's nice unless you have the system directories dug under a whole tree of directories, much of them with long names. Then the game of cd and dir/x and copy/past gets a little boring after a while... ;-)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

BTW my very first example also had an "asm("r18")" in it and I got that same error you mentioned :-(

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
EDIT: Just a minute I see in your edit "-larch_path" whereas I used (because the manual told me) "-larchpath"

Should not matter.

http://www.splint.org/manual/htm... wrote:
To make flag names more readable, the space, dash (-), and underscore (_) characters may be used inside a flag name. Hence, globals-implies-modifies-nothing, glob_imps_­mods­nothing and globsimpmodsnothing are equivalent.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

EW wrote:
No Dean doesn't rule. He's using grep, cut, and other things in the ellipsis that he's not posting.
But the conversion from MCU to maco name is compete. The ellipsis part is about other things.
Quote:
Let's see a single tool that does it all.
What all? Wasn't this about converting MCU to macro name?
Quote:
I challenge him to do it in AWK.

The MCU to macro name conversion would be nearly the same with awk:

splint -D`$(CC) -mmcu=$(MCU) -dM -E - 

or sed:

Quote:
More points if it can be done in sed alone. ;)

splint -D`$(CC) -mmcu=$(MCU) -dM -E - 

The sed script can be simplified, but I couldn't be bothered.

Stealing Proteus doesn't make you an engineer.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

More findings (after having "conditioned" out the offending asm("rxx") lines, using #ifndef S_SPLINT_S:

  • complains on uint8_t (unsigned char) being initialised/assigned/compared to integers (e.g. in uint8_t i = 0; etc.) WHAT'A... I AM NOT GOING TO TYPECAST ALL MY LITERALS!
  • fails on for(uint8_t i=0 etc.) - I know it's not pure C, but AFAIK this is GNU extension (and I have gnu extensions on) (btw. I don't write such, this was an inherited piece of code)
  • in the warnings, line numbers don't match reality at all (I'd guess it prints the preprocessed file's line numbers or something similar)
This is my second attempt to give splint a chance (first was a year ago).

By now, I've spent enough time with this to conclude that it's still too crappy to be used for real work with avr-gcc at this stage.

Maybe I'll try next year again.

JW

[edit]
I take this back. My fault: in mistake, splinted an older - and significantly different - version of the same file. What a shame.

Still don't know how to cope with the "literals-treated-as-int-and-cannot-be-assigned-to-uint8_t" problem.
[/edit]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I wonder if this is a Vista CMD.EXE/COMMAND.COM problem I have? But try as I might I cannot resolve the LARCH_PATH problem even running the 8.3 limited COMMAND.COM and specifying all paths in terms of 8.3

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Cliff,

actually, do you know WHICH splint are you running, by just typing "splint", without any path and extension?

I have copied splint.exe into my working directory.

JW

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0
D:\test>which splint.exe
C:\WinAVR-20100110\bin\splint.exe

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I now came onto a "don't know what is uint_farptr_t". This is typedef'd in , but

Tried to play with -skip-iso-headers, but it then cannot find . OK, added its path as a -I , which in turn threw an error because the WinAVR supplied contains a multi-line #if, and splint apparently does not like that...

Definitively, I rest my case for now.

JW

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

wek wrote:
More findings (after having "conditioned" out the offending asm("rxx") lines, using #ifndef S_SPLINT_S:
  • complains on uint8_t (unsigned char) being initialised/assigned/compared to integers (e.g. in uint8_t i = 0; etc.) WHAT'A... I AM NOT GOING TO TYPECAST ALL MY LITERALS!
  • fails on for(uint8_t i=0 etc.) - I know it's not pure C, but AFAIK this is GNU extension (and I have gnu extensions on) (btw. I don't write such, this was an inherited piece of code)
  • in the warnings, line numbers don't match reality at all (I'd guess it prints the preprocessed file's line numbers or something similar)
This is my second attempt to give splint a chance (first was a year ago).

By now, I've spent enough time with this to conclude that it's still too crappy to be used for real work with avr-gcc at this stage.

Maybe I'll try next year again.

JW

[edit]
I take this back. My fault: in mistake, splinted an older - and significantly different - version of the same file. What a shame.

Still don't know how to cope with the "literals-treated-as-int-and-cannot-be-assigned-to-uint8_t" problem.
[/edit]


Mmmm. Yellow text on a white background! Nice!

Four legs good, two legs bad, three legs stable.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

John_A_Brown wrote:
Mmmm. Yellow text on a white background! Nice!
Sorry. That is the "taken back" part. If this forum would allow html tags, I would use some sort of strikethrough.

JW

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

abcminiuser wrote:
Fair one -- I was only showing a simple (?) way to change the MCU value into the equivalent preprocessor token for splint, not showing how to get splint to actually work. My way uses the real defines for avr-libc via the preprocessor, so it will work no matter what the translation is, so long as it starts with __AVR_AT.

And there's the rub: Strangely, there are some device names that don't start with AT, but do start with __AVR_.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0
awk -vmcu=$(MCU) 'BEGIN { mcu=toupper(mcu); sub(/XMEGA/, "xmega", mcu); sub(/MEGA/, "mega", mcu); sub(/TINY/, "tiny", mcu); print "__AVR_" mcu "__" }'

echo "$(MCU)" | sed 'y/abcdefghijklmnopqrstuvwxyz/ABCDEFGHIJKLMNOPQRSTUVWXYZ/; s/XMEGA/xmega/; s/MEGA/mega/; s/TINY/tiny/; s/^/__AVR_/; s/$/__/'

Stealing Proteus doesn't make you an engineer.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

wek wrote:
More findings (after having "conditioned" out the offending asm("rxx") lines, using #ifndef S_SPLINT_S:
  • complains on uint8_t (unsigned char) being initialised/assigned/compared to integers (e.g. in uint8_t i = 0; etc.) WHAT'A... I AM NOT GOING TO TYPECAST ALL MY LITERALS!

You don't have to :-)
Someone allready started here
http://www.koders.com/noncode/fi...

But you are right ... that is Booooring.

But if we all make an effort , we could make a "Freaks include / .splintrc" set that works reasonably well

/Bingo

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ArnoldB wrote:

awk -vmcu=$(MCU) 'BEGIN { mcu=toupper(mcu); sub(/XMEGA/, "xmega", mcu); sub(/MEGA/, "mega", mcu); sub(/TINY/, "tiny", mcu); print "__AVR_" mcu "__" }'

echo "$(MCU)" | sed 'y/abcdefghijklmnopqrstuvwxyz/ABCDEFGHIJKLMNOPQRSTUVWXYZ/; s/XMEGA/xmega/; s/MEGA/mega/; s/TINY/tiny/; s/^/__AVR_/; s/$/__/'

w00t! :D

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Just as followup

It seems like the CVS version is being worked on they mention VA_ARGS etc ...
http://www.cs.virginia.edu/piper...

/Bingo

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello freaks,
hello Wek, Claswon,

I know that this is an old thread...

But I found something interesting (a kind of solution) regarding the LARCH_PATH issue.

On a Windows XP machine I already used Splint successfully.

But on an old Windows '98 machine I had problems with the following call:

splint -larchpath E:/WinAVR/share/splint/lib -lclimportdir E:/WinAVR/share/splint/imports -sysdirs C:/avrgcc/avr/include/ -sysdirs C:/avrgcc/avr/include/avr -IC:/avrgcc/avr/include -IC:/avrgcc/avr/include/avr -D__AVR_ATmega1284P__ -DF_CPU=16000000UL -ansistrictlib -weak megatest.c > megatest.spl

I also got the warning

Quote:
Cannot find strict standard library: standardstrict.lcd
Check LARCH_PATH environment variable.

But then I substituted the path with "cygwin" like this:

splint -larchpath /cygdrive/e/WinAVR/share/splint/lib -lclimportdir E:/WinAVR/share/splint/imports -sysdirs C:/avrgcc/avr/include/ -sysdirs C:/avrgcc/avr/include/avr -IC:/avrgcc/avr/include -IC:/avrgcc/avr/include/avr -D__AVR_ATmega1284P__ -DF_CPU=16000000UL -ansistrictlib -weak megatest.c > megatest.spl

With this the above warning was gone.

The same is true for the tmpdir option:
With -tmpdir E:/tmp I got trouble.
With -tmpdir /cygdrive/e/tmp it works fine.

Crazy, isn't it?!

The path behind -lclimportdir does not need this. Maybe another API call is used...

Best regards...

---
If you wonder about the different paths: the splint program is used from the WinAVR folder (20100110); the actual compiler is the AVR-GCC, based on GNU 4.7.2.

In the beginning was the Word, and the Word was with God, and the Word was God.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Nice find.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

With reference to my last post I have to add:
A path like

/cygdrive/e/WinAVR/share/splint/lib

can be shortened to

/e/WinAVR/share/splint/lib

.

Also, to avoid this error message about LARCH_PATH, it seems to be important from where the splint program is called and where the project files (the C files to be splinted) are stored. On a windows machine, it seems to be necessary, that you call the splint program from the same partition, where the C file is located (same device character). If you are using the make tool (instead of a batch file) you have to take special attention for this behavior...
So, if you have everything (make-tool, splint.exe and needed libraries/imports, source and header files), on the same partition, this will be the most trouble-free setup relating to splint 3.1.2.

In the beginning was the Word, and the Word was with God, and the Word was God.