PDA

View Full Version : Problems reading io pins as a group


emusteve
02-11-2004, 12:31 PM
I'm trying to read a group of 4 io pins to get a numerical value as the status of an outboard device. I'm trying it out using the edubot controller so I'm looking at io pins 1-4 which translates to PortA bits 0-3. I was trying to do the following:

sensor_value = (PORTA & 0x0f);

iIt compiles ok, but the result is always 0. I double-checked that I have set the pins to INPUT, and have set the number of analog channels to NO_ANALOG. sensor_value is an unsigned char.

I also tried reading the pins individually as rc_dit_in01 through rc_dig_in04 and got the proper values, so I know the hardware is ok. Anyone know what gives here? Any help would be appreciated.


On another note, I often have problems getting the edubot to take to a program upload. Sometimes it takes 2 or 3 tries before it will run. And it won't hold through a power-down. Do I just have a bad machine? this is true for a fresh load of the Default Code as well as my own, and the same behavior with both versions of the IFI Loader.

deltacoder1020
02-11-2004, 12:57 PM
worse case scenario, you could always just do this:

portAvalue = (rc_dig_in01 << 3) & (rc_dig_in02 << 2) & (rc_dig_in03 << 1) & rc_dig_in04;

Mark McLeod
02-11-2004, 01:35 PM
I'm trying to read a group of 4 io pins to get a numerical value as the status of an outboard device. I'm trying it out using the edubot controller so I'm looking at io pins 1-4 which translates to PortA bits 0-3. I was trying to do the following:

sensor_value = (PORTA & 0x0f);

iIt compiles ok, but the result is always 0. I double-checked that I have set the pins to INPUT, and have set the number of analog channels to NO_ANALOG. sensor_value is an unsigned char.

I also tried reading the pins individually as rc_dit_in01 through rc_dig_in04 and got the proper values, so I know the hardware is ok. Anyone know what gives here? Any help would be appreciated.
We're doing the same thing with a BCD switch.

I tested this on the EDU controller and it worked.
With unconnected pins you get 0x0F
With dig I/O 1 signal-to-gnd you get 0x0E
With dig I/O 1&2 connected you get 0x0C



in user_routines.c, User_Initialization()

Set_Number_of_Analog_Channels(NO_ANALOG); /* See ifi_aliases.h */

IO1 = IO2 = INPUT;
IO3 = IO4 = IO5 = INPUT;
IO6 = IO8 = IO10 = INPUT;

// IO3 = IO4 = OUTPUT;
// IO5 = IO7 = IO9 = OUTPUT;

IO7 = IO9 = OUTPUT;
IO11 = IO13 = IO15 = OUTPUT;

// rc_dig_out03 = rc_dig_out04 = 0;
// rc_dig_out05 = 0;


in user_routines.c, Process_Data_From_Master_uP()

PrintString((char *) "PORTA = ");
PrintByte(PORTA & 0x0f);

The Lucas
02-11-2004, 01:38 PM
worse case scenario, you could always just do this:

portAvalue = (rc_dig_in01 << 3) & (rc_dig_in02 << 2) & (rc_dig_in03 << 1) & rc_dig_in04;


Shouldn't it be

portAvalue = (rc_dig_in01 << 3) + (rc_dig_in02 << 2) + (rc_dig_in03 << 1) + rc_dig_in04;



actually it should be

portAvalue = (rc_dig_in04 << 3) + (rc_dig_in03 << 2) + (rc_dig_in02 << 1) + rc_dig_in01;

since rc_dig_in01 is in bit0 (least significant) of PORTA

deltacoder1020
02-11-2004, 04:00 PM
whichever - it depends on what direction you hooked the device up in :)

emusteve
02-11-2004, 04:40 PM
The point was to make the routine as fast as possible by not taking the time and space to read each line individually. I've already got that to work, but it makes for messy code.

Mark's post has the greatest similarity to mine in code structure. I wonder why PrintByte worked for him, but using PORTA to transfer a value to another variable doesn't seem to?

Steve

Astronouth7303
02-11-2004, 05:33 PM
All around, False means closed (On) True means open (off).

You can add, or just OR it (| I think), Which makes more sense to me. You're merging bits, not adding values.

deltacoder1020
02-11-2004, 08:21 PM
the way it works out, either will work. you're right though, bitwise OR is probably faster.

Rickertsen2
02-11-2004, 09:00 PM
The problem is that you are using bitwise and(&), you should be using logical AND(&&).
the difference is this:

"&" (bitwise and) ANDs each corresponding bit individually.
11110000 & 11111111 = 11110000
10101010 & 10101010 = 10101010

"&&" (logical and) ANDs the entire word at a time. (it will only be true if the two arguements are the same.)
11110000 && 11111111 = 00000000
10101010 && 10101010 = 11111111

deltacoder1020
02-11-2004, 09:14 PM
The problem is that you are using bitwise and(&), you should be using logical AND(&&).
the difference is this:

"&" (bitwise and) ANDs each corresponding bit individually.
11110000 & 11111111 = 11110000
10101010 & 10101010 = 10101010

"&&" (logical and) ANDs the entire word at a time. (it will only be true if the two arguements are the same.)
11110000 && 11111111 = 00000000
10101010 && 10101010 = 11111111

I don't believe that's what he's trying to do - he's using the & to mask off the four bits he's trying to read, which is correct.

Rickertsen2
02-11-2004, 09:37 PM
Shouldn't it be

portAvalue = (rc_dig_in01 << 3) + (rc_dig_in02 << 2) + (rc_dig_in03 << 1) + rc_dig_in04;



actually it should be

portAvalue = (rc_dig_in04 << 3) + (rc_dig_in03 << 2) + (rc_dig_in02 << 1) + rc_dig_in01;

since rc_dig_in01 is in bit0 (least significant) of PORTA

Technically bit0 would be the MSB, because of the endianness.



Btw jsut wxactly what are you trying to do? mask off bits or compare values?

Mark McLeod
02-12-2004, 09:09 AM
Mark's post has the greatest similarity to mine in code structure. I wonder why PrintByte worked for him, but using PORTA to transfer a value to another variable doesn't seem to?

SteveI originally ran:

unsigned char port_a;

port_a = PORTA & 0x0f; /* mask off unused bits */
PrintByte(port_a);


to more closely emulate what you were doing. I simplified it to the minimum number of lines before posting.
This works as well, so it isn't an assignment problem.

steven114
02-12-2004, 10:35 AM
"&&" (logical and) ANDs the entire word at a time. (it will only be true if the two arguements are the same.)
11110000 && 11111111 = 00000000
10101010 && 10101010 = 11111111

I believe that is wrong - && returns 1 if both arguments are true (non-zero). This is because the logical and works on two boolean values, and returns a third. Anything except 0 is treated as true in C.

deltacoder1020
02-12-2004, 11:22 AM
steven is correct - anything with a set bit qualifies as the "true" state, the only false state being 0.

you cannot really show how the boolean && works using bits - it's a logical operator, versus the bitwise operator &.

Random Dude
02-12-2004, 11:30 PM
Ahh.. I found the problem..

Mark, if you notice, tested his code on the EDU controller, where PORTA0-3, is bits 1-4

However on the fullsize RC, bits1-4 are PORTB2-5. Infact PORTA isn't even used on the outputs at all.

The full size RC uses parts of Ports B,H,& J
The EDU controller uses parts of Ports A,F,H.

And they actually use different halves of Port H, so I really would suggest against using the port names directly.

Hope this helps....

Mark McLeod
02-13-2004, 08:35 AM
Mark, if you notice, tested his code on the EDU controller, where PORTA0-3, is bits 1-4emusteve is doing his testing using the EDU controller, so that isn't it.
That is a good caution to others who might be reading this thread though.

He may have discovered his problem by now though.

emusteve
02-13-2004, 12:42 PM
Yes, YES! I got it to work last night.

Thanks for all the comments and help! As it turns out, the original statement was working, the problem was apparentlywith the way I was trying to view the result through a printf statement. Still not sure what I was doing wrong there, as when I substituted a pwm variable I would get a real number. In frustration, I ended up echoing the result to a set of output pins, and there it was!

For those who are curious, I am using the "& 0x0f" as a mask to keep only the lower 4 bits. What I'm doing is implementing an outboard i/o expansion scheme so we can read numerical values from outboard hardware. PORTA will translate to PORTH on the FRC. For those who are interested, e-mail me directly and I'll be happy to share schematics and code (once I get the code finished). If there is enough interest, I'll post it as a white paper.

Thanks Again,
Steve Martin
smartin@emich.edu