erikc,
In this project, yes they are together. But that's not always the case. If I can't find a better solution, then I will just set the routeene to work with a 2x4 pair and provide it an "encoder number" which would resolve to A0/A1 for encoder 1, A2/A3 for encoder 2, etc. That's easy. But given I use a rotary in almost everything now, I'm trying to move toward a function which would not have any prespecified index.
Now that I think of it, I suppose I could set it up with arguments PORT, pin A, pin B.
Something like this: char encoder_service(char *avr_port, unsigned char bit_mask_A, unsigned char bit_mask_B)
Which would then be called as (example):
x = encoder_service(&PORTA, 0x01, 0x02);
Think that would work?
73/jeff/ac0c
www.ac0c.com
From: erikc
Sent: Friday, August 06, 2010 7:45 AM
To: AVR-Chat@yahoogroups.com
Subject: Re: [AVR-Chat] passing an AVR port's bit pointer to to a function
Will the port bits both be on the same port or can they be on
different ports? If so, it seems to me that the best way to go would
be to pass the port bits as a bit mask (i.e. pin7 = 0x80 rather than
pin7 = 7) and do it that way.
erikc
Jeff Blaine wrote:
> I have an encoder service function that reads a couple of bits from an AVR and increments a counter if a turn was decoded.
>
> To make the function generic, I would like to pass the port bits as arguments to the function.
>
> Unfortunately, I cannot quite figure out how to pass the port bits to the function. Appreciate advice as to what I'm overlooking...
>
> function prototype looks like this:
>
> char encoder_service(char *avr_port_bit_A, char *avr_port_bit_B) {
>
> }
>
> In the main program, I would have something like this to call the function
>
> x = char pointer to PORTA0
> y = char pointer to PORTA1
>
> encoder_service( x , y );
>
> Using standard C.
>
> 73/jeff/ac0c
> www.ac0c.com
[Non-text portions of this message have been removed]Message
Re: [AVR-Chat] passing an AVR port's bit pointer to to a function
2010-08-06 by Jeff Blaine
Attachments
- No local attachments were found for this message.