Bug in Imagecraft AVR?

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
Hi all (and Richard, if you're here :-) )

I see some strange behaviour of the ICC AVR compiler.
In the following code:

char i,r;

for (i=0;i<5;i++)
{
  r = get_data_field(par,i,field,PROP_FIELD_SIZE); /* extract one field */
  if (r < 0) break; /* break out of loop when no more fields left */
  if (r > 0)
  {
     do something....
  }
}

I expect the for loop to break when r is negative. However, it does not and
the loop is executed 5 times, no matter the returned result of
get_data_field().

Is the compiler wrong or my understanding of the effects of the
break-statement.

Meindert



Re: Bug in Imagecraft AVR?

Quoted text here. Click to load it

Seems the type 'char' is unsigned, isn't it?

  Vadim

Re: Bug in Imagecraft AVR?
Quoted text here. Click to load it

No. char is signed.

Meindert



Re: Bug in Imagecraft AVR?
On Fri, 14 Nov 2003 16:42:50 +0100, "Meindert Sprang"

Quoted text here. Click to load it

What happens for r==0?

Quoted text here. Click to load it

No. Plain char, signed char, and unsigned char are three distinct
types.  It is implementation-defined as to whether plain char is
signed or not.  Most 8-bit compilers I'm familiar with make it
unsigned by default.

If you want a small int, use signed char.  Typedef it if the name bugs
you.  I use S8 or SI8

Never use plain char for anything.  It's useless, even dangerous.
Particularly unsuitable for character data.

Regards,

                               -=Dave
--
Change is inevitable, progress is not.

Re: Bug in Imagecraft AVR?
Quoted text here. Click to load it

And so I have noticed :-(....

When I write in C builder, char is always signed. In my older versions of
'51 compiler, it was signed. Even in my Z80 compiler. Sigh.....   Thanks for
the hint though.

Meindert



Re: Bug in Imagecraft AVR?

Quoted text here. Click to load it

Although the folks in comp.lang.c don't approve of this, I find it has
saved me many a time in my embedded work with C compilers. Once I include
this file I never use C's char, int, short, etc., only these base types.

#ifndef fixed_types_h_included
#define fixed_types_h_included

/* fixed_types.h
**
** Programmer is responsible for determining if compiler
** and architecture support these types and bit widths.
**
**     U = Unsigned integer type
**     S = Signed   integer type
**     F = Floating point   type
**
**     8,16,32,64 indicates the bit width of the type
*/
typedef unsigned char  U8;
typedef   signed char  S8;
typedef unsigned short U16;
typedef   signed short S16;
typedef unsigned long  U32;
typedef   signed long  S32;
typedef float          F32;
typedef double         F64;

#endif /* fixed_types_h_included */


HTH.

--
- Mark ->
--

Re: Bug in Imagecraft AVR?
wrote in comp.arch.embedded:

Quoted text here. Click to load it

The latest C standard was approved four years ago last month.  It now
includes a standard header, <stdint.h>, that defines a standard syntax
for naming exact width integer types:

int8_t, uint8_t, int16_t, uint16_t, and so on.

They're not the prettiest I have ever seen, but they are standard, and
it's pretty easy to make your own stdint.h header to use them.

We've made them for TI DSP's (no *8_t types!), Motorola HS12, Visual
C++, among others.  In fact, it so happens that the stdint.h header
that comes with ARM's ADS works just fine with Visual C++, right down
to supporting signed and unsigned __int64 as int64_t and uint64_t.

Try using the standard ones for your next project, it will ease
porting.

--
Jack Klein
Home: http://JK-Technology.Com
We've slightly trimmed the long signature. Click to see the full one.
Re: Bug in Imagecraft AVR?

Quoted text here. Click to load it

Wrong - "char" should *never* be considered signed or unsigned.  If you want
to write code that is readable, reliable, and works, then you should always
specify "signed char" or "unsigned char".  I've used ImageCraft's avr
compiler for years, and I have no idea what the signedness of a plain "char"
is on that compiler.




Re: Bug in Imagecraft AVR?
Quoted text here. Click to load it
want
always
"char"
Quoted text here. Click to load it

Unsigned, as I found out the hard way and read in the helpfile afterwards.

Meindert



Re: Bug in Imagecraft AVR?

Quoted text here. Click to load it

And it could be signed in the next version of the same compiler.
Don't rely on char being either signed or unsigned.



Re: Bug in Imagecraft AVR?
Quoted text here. Click to load it

I've always mistrusted the 'break' function---seems too much like
BASIC to me!  i would code the function more like:

#define MAXFIELD  5
for (i=0;i<MAXFIELD;i++)
{
  r = get_data_field(par,i,field,PROP_FIELD_SIZE); // extract one field  
  if (r < 0) i = MAXFIELD; // break out of loop when no more fields left
  if (r > 0)
  {
     do something....
  }
}



About the only only place I use 'break'  is after the case elments in  a
switch statement.

It would be interesting to see what assembly language is being generated
by your compiler for this code.   Perhaps there is an obvious error
in the generated object code.

Mark Borgerson

Re: Bug in Imagecraft AVR?
Quoted text here. Click to load it

Another thought:  Is it possible that get_data_field is returning zero?


Mark Borgerson

Re: Bug in Imagecraft AVR?
Quoted text here. Click to load it

Yes, sometimes. But I found the culprit (with apologies to Vladimir): a char
type in unsigned in ICC AVR. So I have to explicitly declare 'signed char
get_data_field()'
So now it works OK.

Meindert



Re: Bug in Imagecraft AVR?
Quoted text here. Click to load it

It's time for some old-fashioned debugging.  You are assuming that char
is signed, which may be true for your compiler, but needn't be for C in
general (it is good practice to type the variable signed char, which
will force it to be signed on any conforming compiler).  What is the
return type for get_data_field()?  If it is int and the return value is
outside the range of r, you could get a false indication.

I suggest looking at the generated code.  You may be able to have the
compiler generate assembly output or you can look at disassembled code.
In either case, verify the code for the first test on r.

It may be that the value returned in r isn't what you think it is.  You
can use a simulator, ICE, or other means to inspect the returned data.
For debugging realtime applications on the fly I have inserted code to
generate pulse patterns on a spare pin at certain critical points in the
code.

Thad

Re: Bug in Imagecraft AVR?
Quoted text here. Click to load it

I'd use a loop that allows me to do checks, eg a while loop.

You're aware that imagecraft have their own list servers to answer questions
related to the ICCAVR ? Available at the imagecraft website.

Rene
--
Ing.Buero R.Tschaggelar - http://www.ibrtses.com
& commercial newsgroups - http://www.talkto.net


Re: Bug in Imagecraft AVR?
Quoted text here. Click to load it

Well, it does not make much difference which loop you use. Even the for loop
does a check. Instead of usgin the obvious

   for (i=0;i<5;i++)

I could have used

   for(i=0;x;i++)

where x is set to 1 before starting the loop and at some point in the loop
set to 0.

Quoted text here. Click to load it
questions

Didn't know that. I'll take a look there. Thanks.

Meindert



Re: Bug in Imagecraft AVR?



Quoted text here. Click to load it

...
Yes, I am still here :-) and yes, the problem is that "char" is unsigned.
--
// richard
http://www.imagecraft.com



Re: Bug in Imagecraft AVR?

Quoted text here. Click to load it

No, the problem is the programmer _assumed_ it was signed.

--
Grant Edwards                   grante             Yow!  Where's th' DAFFY
                                  at               DUCK EXHIBIT??
We've slightly trimmed the long signature. Click to see the full one.
Re: Bug in Imagecraft AVR?
Quoted text here. Click to load it
unsigned.

Yes. But it was an assumption based on experience. All compilers I have
previously used treated char as signed unless an option was set. But you
learn something everyday :-)

Meindert



Re: Bug in Imagecraft AVR?
Quoted text here. Click to load it

Here's my usage, which I recommend:

 signed char for 8-bit (or more) signed values
 unsigned char for 8-bit (or more) unsigned values
 char for actual characters.

This is portable to any conforming C compiler.

Thad

Site Timeline