PIC18F252, CCS-IDE 3.249

ulg · Joined: 09 May 2019 Posts: 24

In order to have at all a debug means at the extension of a Uralt system at hand, I wanted to spend in a Fifo cached debug values alternating to the temperature with the serial interface.

In a first step, I once issued two nibbles of my ms timer and already with it there is a problem:

- I output the two lower nibbles of the 16bit return value,
The two nibbles go out on the RS232 line as well.
- but I give out the middle two Nibble
(time = ((uint16_t) msTime ()) >> 4;), but goes out on the
RS232 cable only the lower nibble
- and finally I give out the top two nibbles (>> 8),
does not send out anything anymore, I permanently have the output "@ 00".

The same thing is then repeated with a local static variable (tick), with the same result - if I send the upper byte of the 16bit variable (>> 8), I see on the RS232 line only "@ 00" - I override the calculated Values with the values that I have
I expect the first run, I get as output also "@ 12", so the problem must be with shift / and / or! Does anyone see my mistake?

gaugeguy · Joined: 05 Apr 2011 Posts: 303

static signed int tick = 0x1234;

This is going to be a signed 8 bit value, so only the 0x34 gets loaded into the variable.

Change to
static signed int16 tick = 0x1234;

ulg · Joined: 09 May 2019 Posts: 24

Here's what the compiler generates at shift 8, shift 4 and without shift.
shift 8:

PCM programmer · Joined: 06 Sep 2003 Posts: 21708

Ttelmah · Joined: 11 Mar 2010 Posts: 19520

Key is this:

ulg · Joined: 09 May 2019 Posts: 24

Thanks for the quick responses.

I had still checked that in the stdint.h I created (since one of them was not supplied by the compiler) I accidentally defined the int16_t with char and then defined tick as "signed int" to exclude any errors. That this could only be 8bit, I did not get the idea!

Can someone tell me where I can find a useful stdint.h for CCS 3.249 / PIC18F252?
Where can I find the Reference Manual for 3.249?

ulg · Joined: 09 May 2019 Posts: 24

Using the 2019 CCS Reference Manual, I modified my stdint.h as below.
Does it fit with vs. 3.249?

Ttelmah · Joined: 11 Mar 2010 Posts: 19520

Yes.

The key point is to _never_ assume sizes.

For example 'int', on CCS, is an int8. On most C's it is int16, but on things
like some of the Microsoft languages it is an int32.
It is always better/safer to explicitly use named sizes. So int16, int32 etc.
stdint, is just a way to give some shorter standard names for some of these
(so it is shorter to type uint32_t, than 'unsigned int32').
The lines shown from the 2019 manual can be used if you want in 3.249.
However use these or not, you just need to be using a type that is 16bit
to store a variable that you want to perform 16bit operations on.

Now 'C' historically in K&R, it was said that the default size for an integer
should always be the type that best fitted the processor hardware involved.
So Historically C on a PDP-8, use a 12bit integer. CCS kept to this, since
if you want to write fast code using the processor, the 'best' size is the
one that it handles as a single instruction. So they made 'int' an int8. Later
C's though generally decided to have 'int' always mean an int16, and
ANSI-C's use this as a standard. In fact you can change CCS to use this
by selecting it's 'ANSI' mode. However on 3.249, this is pretty limited.
Much better to just always be explicit on the size you are using. This
allows the best efficiency, and gives you control of the types used.