Peripheral Module Disable (PMD)

what is peripheral module disable peripheral module disable is a feature available in the pic16f18877 family that enables the firmware to disable certain peripherals that are not needed or won't be needed at startup or a reset recovery, all peripherals are enabled or "on" or out of reset by default the power consumption at this point would be at its peak, and disabling the modules not being used would reduce power consumption the method provides the option to power down or power up the modules that have this feature individually this is done by disabling the peripheral's corresponding bit the enabling or disabling of a peripheral is not instantaneous and would require at least i full clock cycle for the peripheral to be disabled or enabled the deployed code would need to consider the device's operating characteristics for when the peripheral is powered down or then powered back up the delay between the change in the peripheral's state and its being operational would need to be factored in, especially if the module is needed for a critical or time sensitive application when reset, the mcu returns all devices to the default state of "on" which powers up all peripherals implementing pmd pmd operationally puts the selected peripherals into a reset low state as per a device that is in reset low, the mclr line has been pulled low preventing the device from executing any instructions when the line returns high, the operation will resume powering down and powering up when a device peripheral or module is disabled and then enabled, there are effects on the system for legacy reasons, all modules are on by default following any reset exercise care when implementing pmd as the peripheral and its associated registers may be impacted and this could result in reduced or nulled capacity of adjacent modules or modules that operate in tandem disabling a module when the module is disabled, disabling has the following effect • all clock and control inputs to the module are suspended; there are no logic transitions and the module will not function • the module is held in reset • any sfrs become “unimplemented” \ writing is disabled \ reading returns 00h • module outputs are disabled; i/o goes to the next module according to pin priority enabling a module when the register bit is cleared, the module is reenabled and will be in its reset state; sfr data will reflect the por reset values depending on the module, it may take up to one full instruction cycle for the module to become active there should be no interaction with the module (e g , writing to registers) for at least one instruction after it has been re enabled clock cycle delay when the peripheral is enabled, a full clock cycle may be required for some modules to be active again this implies that the enabling of a peripheral incurrs an operational delay will not be available immediately after enabling checks may be required or a reinitialization of the peripheral to ensure that it retains previous settings considerations the following items are to be considered when powering up or powering down a peripheral powering down a module requires that the control bit is cleared or set to 0 powering up a module requires that the control bit is set to 1 code sample the basic code sample below assumes a function exists to test for the need for the uart when needed its on and when not is disabled or in a reset low state the logic is inverted here, so when needed its set to 0, and when not its 1 c \#define not 1 \#define is 0 bit need; void needforcoms (); needforcoms(){ bit test; //\<user code here>, fictitious function that determines the need // for coms return test; } void main() { while(1){ need = needforcoms(); if(need == not){ pmd4 uart1md = 1; } else pmd4 uart1md = 0; delay us(1); } }