Strange data from input function

[thomasj50]

Hi, I use an input function call to read a digital pin and assign the result to a 16 bit int. When the pin is high sometimes I get a value different from 1; see the following small code snippet:

int16 val;

val = input(PIN_A4);

printf("val = %lu\n\r", val);

Recent results are 257 (0x0101) and 20481 (0x5001) - it seems that the top 8 bits are not masked out somehow, and since they vary perhaps they represent other input bits on the same port (they are connected to custom hardware and vary with the state of the system). If I mask the result with 0xff the function results the data as expected. I use a PIC18LF158 with compiler version 4.014. Perhaps someone out there can try this and study the list file - I don't know enough of PIC assembler to do this myself I'm afraid :-)

Best Regards,
Thomas Johansson

[dyeatman]

According to the manual (current manual page 155) the input() function is a digital function and returns the pin state as True or False. It is not an A/D function. Therefore any value greater than zero is actually just an indication of TRUE.

By definition a DIGITAL input can only be high or low (1 or 0). An ANALOG input value can can vary between zero and the maximum resolution of the A/D converter (255, 1024 etc.).

regards

[jecottrell]

I'm just curious, why are you storing a bit value in an int16?

If that is truly what you're after, why not:

[thomasj50]

dyeatman - Yes, I know that a value different from 0 is regarded as a TRUE value, but my point is that the compiler help (and the manual) states that the return value should be either zero or one, and nothing else. In this case I use the value to test whether a certain signal is active and it does not matter if the true value is 1 or 257 - but it differs from what the function is supposed to return.

As you note yourself - a digital input can only be high or low (1 or 0), so I find it reasonable that the function should return only a one or a zero value.

Regarding the question why I store a bit value in a 16 bit integer - the variable is part of a structure composed mostly of 16 bit ints, mainly because the serial protocol used to read and write values to the struct is independent of what the value represents - it reads/writes 16 bits to a variable depending on its position in the struct, and to avoid a special case I treat booleans as 16 bit integers. To find the right place I use a union with an array of int16 (could have used pointer arithmetic, but I teach Java at the university and it's a personal thing :-). Why I dont use an array in the first place is beacuse the actual type of the values are not the same, specfically some are signed, some not, and there are actually a pair of 32 bit values in there too.

To sum up, I just wanted a digital function to return a 0/1 value as stated in the manual, and wondered if this is a compiler bug. (Actually I was just annoyed with the value 20481 showing up in a text box in the pc control program when it should have been a one :-)

Best Regards,
thomas Johansson

[SimpleAsPossible]

I looked at a listing file. The compiler defines two consecutive bytes for val. Then, for the call to input() it clears the low byte, tests the input pin and if it is low skips an opcode that increments the low byte. So you always get a 1 or a 0 in the low byte. Since it doesn't appear to clear the high byte, try adding:

[PCM programmer]

[thomasj50]

Thanks for the help on this, I wanted to be sure my brain wasn't on the fritz. This is actually the second 'compiler malfunction' I found this week, and I started to have some doubts ... :-)

The PIC I use is a 18LF258, I made a typo there.

Best Regards,
Thomas Johansson