News:

Let's find out together what makes a PIC Tick!

Main Menu

New 8-bit MCUs PPS and SPI - Important !

Started by trastikata, May 30, 2026, 05:19 PM

Previous topic - Next topic

trastikata

Hello all,

While working with the PIC18F57Q83, I ran into a behavior that surprised me and may be worth sharing.

Based on my testing, it appears that on these newer 8-bit MCUs, assigning a pin to a peripheral through PPS can leave the peripheral in control of the pin even after the peripheral itself is disabled.

What does this mean in practice?

- On older devices, pins could be configured as inputs or outputs and assigned to a peripheral (for example, SPIx) through PPS. While the peripheral was enabled, it controlled the assigned pins. Once the peripheral was disabled via its Enable bit, control of the pins was returned to the generic I/O latches.

- On the PIC18F57Q83, my testing shows that disabling the SPIx module alone does not automatically return control of the assigned pins to the generic I/O logic. The corresponding PPS assignments must also be cleared before the pins can be driven normally through software.

I discovered this while switching from hardware SPI to a bit-banged SPI implementation. Although the SPI module was disabled and the pins were configured as outputs, the pin states would not respond as expected until the PPS assignments were removed.

On older 16-bit devices I have used, simply disabling the SPI module was sufficient to regain control of the pins, even when PPS was involved. I have not yet tested whether newer 16-bit devices exhibit the same behavior.

JackB

Hello trastikata

Also I'm puzzle about this event or conflic

I'm not an expert of any kind, but from the datasheet
© 2020-2021 Microchip Technology Inc.    Preliminary Datasheet

page 359,361

and find maybe this can help in anyway

page 359 : 21.5   PPS Lock
page 361 : 21.5.1 PPS One-Way Lock




Fanie

#2
16F17146, I made a controller for my hybrid water garden.
A lot is different for using this chip vs the usual 16F684's I used.
I couldn't get the A/D to work, then disabled all the A/D setups except enabling the peripheral, and then it worked but not properly, not getting the expected readings.
Code I used hundreds of times already, like reading from a 18B20 also gives weird values.

The controller works off solar, I intend to measure the sun power from a loaded solar cell before switching the pump on, it also get a battery so that an hour before daylight and an hour after daylight it will switch a light sequencer on (got the sequence from a client that sell these, I do his hardware for it) which is said to improve the plant health and increase growth rate.
Since it is winter here, I would like to measure the water temperature and if it gets below 15oC I can switch an element on powered by a solar panel so the temperature increases at least into the 20oC's.  I would prefer to use a solar geyser, much more efficient, but limited space and more expensive.

To get any of this done I will have to sit and find the quirks of this pic.
To at least get the pump working for the time being I time 3 hours and 20 minutes, a wait for the sun to be up properly, then run the pump an hour, two hours off, one hour on again.

John Lawton

With the extra complication of many modern PICs, I can't help wondering whether it's worth using them for small projects. Why not stick with what you know, i.e. the 16F684 ?

John
-----------------------------------------------------------------------------------------
Amicus 8 and 16A/16B dev boards
Especially created for Positron development
https://www.easy-driver.co.uk/Amicus

Fanie

The price of the older pics ($1,56) are a problem at around double vs ($0,80).
I have however ordered a different 16 pin pic but got these new 20 pin pics instead from Taiwan after mine was apparently delivered in Malesia.
What to do... ?