| View previous topic :: View next topic |
| Author |
Message |
Backfire
Joined: 12 Oct 2020
Posts: 46
|
| Using a PIC to control another PICs MCLR |
 Posted: Fri Sep 15, 2023 7:22 am |
 |
|
Hello all,
I had a quick question and would value peoples input. I am developing a board that has 4 PIC’s, one device acting as a ‘controller’ (let’s call it the CPU) and three devices that are being controlled (let’s call them ‘Drivers’). The three drivers will each have their MCLR pin connected to a separate GPIO of the CPU, (as well each MCLR net being tied to VCC through a 10K resistor).
My question was how best to code the CPU for toggling the MCLR line of a driver PIC. I only really want to be actively driving the signal when undertaking a reset, otherwise leaving the CPU GPIO floating (un-driven, as the net is electrically pulled to +5V by the external resistor) seems like the best idea.
Would the best implementation be as below, or should I be using the “set_open_drain_b(value)” functions?
| Code: |
void ResetDriverA(void)
{
output_drive(PIN_B0);
output_low(PIN_B0);
delay_ms(1);
output_float(PIN_B0);
}
|
I just want to ensure I’m using the function calls, thanks in advance for peoples input. |
|
 |
Ttelmah
Joined: 11 Mar 2010
Posts: 19552
|
|
| Posted: Sat Sep 16, 2023 2:53 am |
|
|
Assuming the pin is set as standard IO, then the compiler will automatically
enable the tris when a pin is driven, so no need for the 'output_drive'.
What is needed is:
At boot
output_float(PIN_B0);
By default the line will always be floated till it is driven, but this
'makes sure'.
Then in the drive routine:
| Code: |
void ResetDriverA(void)
{
output_low(PIN_B0);
delay_ms(1);
output_float(PIN_B0);
}
|
You only need the explicit 'output_drive', if the pin is setup as fixed_io
or fast_io. |
|
|
Backfire
Joined: 12 Oct 2020
Posts: 46
|
|
| Posted: Sat Sep 16, 2023 3:06 am |
|
|
Amazing!
Many thanks for the advice Ttelmah. |
|
|
temtronic
Joined: 01 Jul 2010
Posts: 9246
Location: Greensville,Ontario
|
|
| Posted: Sat Sep 16, 2023 5:59 am |
|
|
as a comment...
stay with using 'standard_IO' and NOT 'fast_IO'.
This way compiler does all the 'details' automatically for you.Iif you use 'fast_io' and you change the hardware pinning and not recode to reassign them, oopsy... 'stuff doesn't work' that used to !!!
In 2 decades of 'playing with PICs', I've only needed fast_io for 2 projects that needed very 'tight' timing to communicate with client's special hardware |
|
|
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
