PICC lite program functions
- Clyde Crashkop
- Posts: 99
- Joined: Fri Feb 06, 2004 1:01 am
- Location: Florida
- Contact:
Re: PICC lite program functions
Maybe "OR" your byte with a mask byte to see if the target bit is set.
- HighFrequency
- Posts: 122
- Joined: Sun Apr 17, 2005 1:01 am
- Location: Victoria BC
- Contact:
Re: PICC lite program functions
I usually "AND" my bytes. For instance:
10011010 I need bit 4. So I AND with:
00010000 Now everything other than bit 4 is -------- guaranteed to be zero. And the result:
00010000
Then just do an if (result). If anything is in result, it returns true which means your bit was set.
10011010 I need bit 4. So I AND with:
00010000 Now everything other than bit 4 is -------- guaranteed to be zero. And the result:
00010000
Then just do an if (result). If anything is in result, it returns true which means your bit was set.
There is only one correct answer, mine.
Re: PICC lite program functions
IN 'C' an easy way is to define your bits with real names, like
#define button1 0x02 (for bit #2)
then.....
if(portb && (1 << button1)) >>>> the '1' get
shifted 2 places
left
{
whatever you want to happen if is ON
}
else
{
whatever you want to happen if button 1 is OFF
}
As far as free stuff, mikroelectronics offers their 'C' and Basic compilers for the pic for limited code size. They have built in functions for many things so you don't have to re-invent the wheel.
#define button1 0x02 (for bit #2)
then.....
if(portb && (1 << button1)) >>>> the '1' get
shifted 2 places
left
{
whatever you want to happen if is ON
}
else
{
whatever you want to happen if button 1 is OFF
}
As far as free stuff, mikroelectronics offers their 'C' and Basic compilers for the pic for limited code size. They have built in functions for many things so you don't have to re-invent the wheel.
Re: PICC lite program functions
ahem, I'd use a bitwise AND (&) and not a boolean (&&).
You can make the code even more readable by doing this:But I prefer and if your C compiler preprocessor supports it you can generalize this
<small>[ March 21, 2006, 08:54 PM: Message edited by: philba ]</small>
You can make the code even more readable by doing this:
Code: Select all
#define Button1 (1<<2)
// or
#define Button1 0b00000100
if((PORTB & Button1) != 0)....
Code: Select all
#define Button1 (PORTB & 0b00000100)
if(Button1 != 0) ...
Code: Select all
#define Bit(i) (1<<i)
if(Value & Bit(2))...
<small>[ March 21, 2006, 08:54 PM: Message edited by: philba ]</small>
- HighFrequency
- Posts: 122
- Joined: Sun Apr 17, 2005 1:01 am
- Location: Victoria BC
- Contact:
Re: PICC lite program functions
You could multiplex the pins. When you're not sending parallel data, RB3 could be an input. Then when you need to send data, switch it to an output.
-- edit: Actually that's not a good idea at all. Don't do that
<small>[ March 22, 2006, 07:13 AM: Message edited by: HighFrequency ]</small>
-- edit: Actually that's not a good idea at all. Don't do that
<small>[ March 22, 2006, 07:13 AM: Message edited by: HighFrequency ]</small>
There is only one correct answer, mine.
Re: PICC lite program functions
First a quick bit wise operations lesson:
shift: <<, >>and: & or: | parallel output pins from different ports are kind of tricky. you could write 8 if statements testing each bit in your output value and set the corresponding port bit. be careful that the device doesn't expect all the bits at the same time, though. To save pins, you could use the 74HC595 shift reg - serial input, parallel output. use SPI (hw or sw implementation) to drive it. mikro C has support for both, I believe. You only need 3 pins.
Multiplexing input and output on a single pin is fine as long as what ever device expects it as an output doesn't do something wierd when you use the pin for input. You can use resistors to gain some degree of isolation.
What device are you hooking up to?
<small>[ March 22, 2006, 03:00 PM: Message edited by: philba ]</small>
shift: <<, >>
Code: Select all
a = 0b11001100; // a contains 0b11001100
b = a << 1; // b now contains 0b10011000
b = a >> 1; // b now contains 0b01100110
b = a << 3; // b now contains 0b01100000
Code: Select all
a = 0b11001100;
b = a & 0b10101010; // b now contains 0b10001000
b = a | 0b10101010; // b now contains 0b11101110
Multiplexing input and output on a single pin is fine as long as what ever device expects it as an output doesn't do something wierd when you use the pin for input. You can use resistors to gain some degree of isolation.
What device are you hooking up to?
<small>[ March 22, 2006, 03:00 PM: Message edited by: philba ]</small>
Re: PICC lite program functions
no, this won't work. there are ways to do what you want but they are more complex. I'd probably just code it as straignt line code:
the construct PORTn.i is specific to certain compilers so you should replace it with what ever your compiler uses to access specific bits.
[edit]
Here's a more compact way to do this but it's not as readable.It probably generates the same instruction sequences, though.
I would avoid bit shifting since the PIC only has single bit shift instructions[/edit]
<small>[ March 23, 2006, 09:32 AM: Message edited by: philba ]</small>
Code: Select all
//bit 0
if(value & 0x1)
PORTB.0 = 1;
else
PORTB.0 = 0;
// bit 1
if(value & 0x2)
PORTB.5 = 1;
else
PORTB.5 = 0;
...
[edit]
Here's a more compact way to do this but it's not as readable.
Code: Select all
PORTB.0 = value & 0x1 ? 1:0; // bit 0
PORTB.5 = value & 0x2 ? 1:0; // bit 1
PORTA.7 = value & 0x4 ? 1:0; // bit 2
...
I would avoid bit shifting since the PIC only has single bit shift instructions[/edit]
<small>[ March 23, 2006, 09:32 AM: Message edited by: philba ]</small>
Re: PICC lite program functions
If you are going to have a circuit where the individual bits of a PIC port may change direction, EG: two bits become inputs whilst the rest of the port is an output and then those two bits become outputs, you may run into the PIC's RMW problem.
It would be advisable in that instance to have a 'dummy' variable where you copy the port to it and perform the operation on the dummy/shadow/copy byte and then copy it back to the port.
EG:
uchar portB_copy;
portB_copy = (PORTB & 0xbit(s) of interest);
TRISB = 0b???????;
.......
do stuff with portB_copy here
.......
TRISB = 0b??????;
PORTB |= portB_copy; // or PORTB = PORTB | portB_copy;
Colin
It would be advisable in that instance to have a 'dummy' variable where you copy the port to it and perform the operation on the dummy/shadow/copy byte and then copy it back to the port.
EG:
uchar portB_copy;
portB_copy = (PORTB & 0xbit(s) of interest);
TRISB = 0b???????;
.......
do stuff with portB_copy here
.......
TRISB = 0b??????;
PORTB |= portB_copy; // or PORTB = PORTB | portB_copy;
Colin
On a clear disk you can seek forever.
Shameless self promotion...
Dear Friends:
I know this post is off-topic, but I wanted to attract some attention to a forum topic I started called "Virtual Digital Circuits." It includes a poll question, and already has generated a few spirited responses.
Come join the fun!
Regards
I know this post is off-topic, but I wanted to attract some attention to a forum topic I started called "Virtual Digital Circuits." It includes a poll question, and already has generated a few spirited responses.
Come join the fun!
Regards
Who is online
Users browsing this forum: No registered users and 61 guests