|
|
View previous topic :: View next topic |
Author |
Message |
bdavis
Joined: 31 May 2004 Posts: 86 Location: Colorado Springs, CO
|
Init Code and fast_io() |
Posted: Wed Aug 25, 2004 11:27 pm |
|
|
I haven't seen an example of how to initialize the ports if using "#pragma use fast_io()" or other ports with set_tris_x() in regard to ordering with port initialization of the pragma's such.
Do you use #pragma use rs232 () & #use i2c(), then fast_io(), then setup_ports( NO_ANALOGS ), then set output ports to a value, then set_tris_x() ?
I want to use the standard I2C and UART support too, and am concerned about trashing the output states for the pins for RX, TX, SDA, SCL.
I would like to use fast_io() on all ports. |
|
|
PCM programmer
Joined: 06 Sep 2003 Posts: 21708
|
|
|
bdavis
Joined: 31 May 2004 Posts: 86 Location: Colorado Springs, CO
|
|
Posted: Fri Aug 27, 2004 12:29 am |
|
|
Thanks for the reply PCM I was beginning to think there was no hope
The example was careful to not use fast_io() on port C (where I2C/RX/TX are used ).
I did see that they did use:
fast_io()
then set_tris_x(),
then setup_ports( NO_ANALOGS )
then then set output ports to a value
I think I will omit the fast_io() on port c until I have enough time for proper testing and looking at various listing files. I may later just control the I2C and UART directly, and then I should know exactly what is going on, but I would give up portability and any errata corrected by the compiler.
By the way - unrelated, but found that xor'ing a bit takes 10 instructions, while doing a if/else to flip it only takes 5 instructions. I just need to get comfortable with knowing what the compiler is doing well, and what it does poorly...
I hope CCS gives you freebies for all the help you give people on this forum.
Thanks again! |
|
|
Ttelmah Guest
|
|
Posted: Fri Aug 27, 2004 2:28 am |
|
|
bdavis wrote: | Thanks for the reply PCM I was beginning to think there was no hope
The example was careful to not use fast_io() on port C (where I2C/RX/TX are used ).
I did see that they did use:
fast_io()
then set_tris_x(),
then setup_ports( NO_ANALOGS )
then then set output ports to a value
I think I will omit the fast_io() on port c until I have enough time for proper testing and looking at various listing files. I may later just control the I2C and UART directly, and then I should know exactly what is going on, but I would give up portability and any errata corrected by the compiler.
By the way - unrelated, but found that xor'ing a bit takes 10 instructions, while doing a if/else to flip it only takes 5 instructions. I just need to get comfortable with knowing what the compiler is doing well, and what it does poorly...
I hope CCS gives you freebies for all the help you give people on this forum.
Thanks again! |
I use fast_io, with the peripherals quite regularly, and normally. The 'key', is to ensure that you set the IO direction to the expected state before calling the routines. With hardware SPI, or I2C, the state must be the one that is defined in the data sheet to enable this peripheral to work (depends on the chip). The same is true for the serial port.
For instance, with a 18F252, using the serial, and SPI ports, I initialise with:
SET_TRIS_C(0b10010000); /* RX/TX=set as I/P controlled by UART
SDO & SCK must be set =0. SDI set to 1
remainder all O/P.*/
One way to go, is to use standard IO, run a test program, and step it to the start of any IO reoutine, then check what TRIS is set to. Once you have this data, simply ensure that you set TRIS the same before arriving at this point. A bit 'caveat', is that chips do differ. MicroChip, specify different setup conditions for the serial port I/O lines (for example), on some chips, so it is well worth being careful over this.
Best Wishes |
|
|
bdavis
Joined: 31 May 2004 Posts: 86 Location: Colorado Springs, CO
|
|
Posted: Fri Aug 27, 2004 8:40 am |
|
|
Thanks Ttelmah
That helps, and eliminates many worries about not knowing for sure what the compiler wants for the TRIS. I didn't know about the different setups for TRIS for the UART on different chips, so thanks for that too! |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|