PIC "C" macro definitions for PORTB and *pointers on PIC18.
Carbon_Rod, Fri Apr 21 2006, 12:10AMThe situation:
Declared an array of const function pointers that scheduled to run round robin style for consistent timing. A helper process may be assigned to a given port address and asserts a test-and-set mutex to perform the bus transaction.
The problem: The C macro definitions for PORTB on PIC18.
Normally I would just write it in asm and do an extern call to get around this problem using the indirect de-referencing reregister trick. However, the code must be portable without violating the other procs register states when interrupted. The compiler documentation/code support, google, microchip, and Usenet searches have not been very helpful. (I am rather amazed it took this long to run into this issue)
Any ideas on how a simple macro to a non-constant (far unsigned char*) pointer translation can be done on the fly in C?
Cheers, =D
Re: PIC "C" macro definitions for PORTB and *pointers on PIC18.
Steve Conner, Fri Apr 21 2006, 10:14AM
I'm not sure I even understand what the problem is. I think you are saying that you are writing a multitasking OS for a PIC, and you want several processes to be able to access the same I/O port, but it won't work?
I have the same problem doing firmware for our instruments at work, where I sometimes find that I want the main code to toggle a few bits in a given port, and an interrupt service routine to toggle a few other bits in the same port. The read-modify-write behaviour of the PIC's ports doesn't seem to work quite right under these conditions. I'm no computer scientist, so rather than mess around with locks and mutexes, I just try and avoid this situation of multiple processes accessing the same hardware resource altogether, and if I have to do it, I keep a spare copy of the port output states in another register, and use that for the read-modify-write, instead of reading the port itself.
*edit* I just re-read your post, and it looks like I totally misunderstood what the question was. Can't you write your helper process as a function that takes an argument of type (whatever type holds a pointer to a PIC18xxx memory location), and then when you want to assign your process to PORTB, take the constant "PORTB" as defined in the header file, load it into a variable of the appropriate type, and call the function with this variable as its argument?
Another possibility would be to do it in assembler, but save the states of any registers you use and restore them afterwards.
Steve Conner, Fri Apr 21 2006, 10:14AM
I'm not sure I even understand what the problem is. I think you are saying that you are writing a multitasking OS for a PIC, and you want several processes to be able to access the same I/O port, but it won't work?
I have the same problem doing firmware for our instruments at work, where I sometimes find that I want the main code to toggle a few bits in a given port, and an interrupt service routine to toggle a few other bits in the same port. The read-modify-write behaviour of the PIC's ports doesn't seem to work quite right under these conditions. I'm no computer scientist, so rather than mess around with locks and mutexes, I just try and avoid this situation of multiple processes accessing the same hardware resource altogether, and if I have to do it, I keep a spare copy of the port output states in another register, and use that for the read-modify-write, instead of reading the port itself.
*edit* I just re-read your post, and it looks like I totally misunderstood what the question was. Can't you write your helper process as a function that takes an argument of type (whatever type holds a pointer to a PIC18xxx memory location), and then when you want to assign your process to PORTB, take the constant "PORTB" as defined in the header file, load it into a variable of the appropriate type, and call the function with this variable as its argument?
Another possibility would be to do it in assembler, but save the states of any registers you use and restore them afterwards.
Re: PIC "C" macro definitions for PORTB and *pointers on PIC18.
Carbon_Rod, Sat Apr 22 2006, 12:55AM
// OK so I think I solved the issue:
// Can you spot the syntax error(s) that refuses to compile foo() ?
// Yet bar() compiles just fine.
unsigned char* io_port_Alias_Ptr; //port alias
//\\//\\//\\//\\//\\//\\//\\//\\//\\//\\// \\//\\//\\//\\//\\//\\//\\//\\//\\//\\//\\//\\// \\
//This Compiles in Hi-tech C
//This chokes with a syntax error in Microchip C.
//\\//\\//\\//\\//\\//\\//\\//\\//\\//\\//\\// \\//\\//\\//\\//\\//\\//\\//\\//\\//\\//\\// \\
void foo(void)
{
io_Port_Alias_Ptr = &PORTB;
*io_Port_Alias_Ptr = 0xF0;
}
//\\//\\//\\//\\//\\//\\//\\//\\//\\// \\//\\//\\//\\//\\//\\//\\//\\//\\//\\//\\//\\// \\//\\
//This Compiles in Hi-tech C
//This Compiles in Microchip C.
//Microchip C syntax error bug magically disappears –POOF!
//\\//\\//\\//\\//\\//\\//\\//\\//\\//\\/ /\\//\\//\\//\\//\\//\\//\\//\\//\\//\\//\\//\\// \\
void bar(void)
{
io_Port_Alias_Ptr = &PORTB;
*io_Port_Alias_Ptr = 0x0F;
}
Carbon_Rod, Sat Apr 22 2006, 12:55AM
// OK so I think I solved the issue:
// Can you spot the syntax error(s) that refuses to compile foo() ?
// Yet bar() compiles just fine.
unsigned char* io_port_Alias_Ptr; //port alias
//\\//\\//\\//\\//\\//\\//\\//\\//\\//\\// \\//\\//\\//\\//\\//\\//\\//\\//\\//\\//\\//\\// \\
//This Compiles in Hi-tech C
//This chokes with a syntax error in Microchip C.
//\\//\\//\\//\\//\\//\\//\\//\\//\\//\\//\\// \\//\\//\\//\\//\\//\\//\\//\\//\\//\\//\\// \\
void foo(void)
{
io_Port_Alias_Ptr = &PORTB;
*io_Port_Alias_Ptr = 0xF0;
}
//\\//\\//\\//\\//\\//\\//\\//\\//\\// \\//\\//\\//\\//\\//\\//\\//\\//\\//\\//\\//\\// \\//\\
//This Compiles in Hi-tech C
//This Compiles in Microchip C.
//Microchip C syntax error bug magically disappears –POOF!
//\\//\\//\\//\\//\\//\\//\\//\\//\\//\\/ /\\//\\//\\//\\//\\//\\//\\//\\//\\//\\//\\//\\// \\
void bar(void)
{
io_Port_Alias_Ptr = &PORTB;
*io_Port_Alias_Ptr = 0x0F;
}
Re: PIC "C" macro definitions for PORTB and *pointers on PIC18.
..., Sat Apr 22 2006, 01:31AM
could it have been related to the fact that one one refers to 0xf0 and one to 0x0f?
I asume that the extra return isn't related to it...
..., Sat Apr 22 2006, 01:31AM
could it have been related to the fact that one one refers to 0xf0 and one to 0x0f?
I asume that the extra return isn't related to it...
Re: PIC "C" macro definitions for PORTB and *pointers on PIC18.
Carbon_Rod, Sat Apr 22 2006, 03:16AM
1.) Variable name case: (duoh! borken)
2.) "Second is using a backslash" <- Weird Microchip multi-line issue
3.) Variable declaration:
volatile near unsigned char *portb_ptr;
Personally I took way too long to spot 2 when porting the code as the other compiler never complained
Cheers, =D
Carbon_Rod, Sat Apr 22 2006, 03:16AM
1.) Variable name case: (duoh! borken)
2.) "Second is using a backslash" <- Weird Microchip multi-line issue
3.) Variable declaration:
volatile near unsigned char *portb_ptr;
Personally I took way too long to spot 2 when porting the code as the other compiler never complained
Cheers, =D
Print this page