8051 and power management

In the code you can see, how I usually use the IDLE mode. The main() function waits, until an interrupt occurs. Each interrupt routine has its own bit flag, that is set by the ISR. In main() this flag is cleared and the required actions are performed.

void main()
{
	Init_System();

	for( ; ; )
	{
		// wait for an event
		while( !b_PeriodicTimer &&
			  !b_NewCommand )
		{
			PCON |= 0x01;
		}

		ServiceWatchdog();

		if( b_NewCommand )
		{
			b_NewCommand = FALSE;
			ProcessCommand();
		}

		if( b_PeriodicTimer )
		{
			b_PeriodicTimer = FALSE;
			PerformPeriodicTasks();
		}

		UpdateSystemStatus();
	}
}

In the code you can see, how I usually use the IDLE mode. The main() function waits, until an interrupt occurs. Each interrupt routine has its own bit flag, that is set by the ISR. In main() this flag is cleared and the required actions are performed.

void main()
{
	Init_System();

	for( ; ; )
	{
		// wait for an event
		while( !b_PeriodicTimer &&
			  !b_NewCommand )
		{
			PCON |= 0x01;
		}

		ServiceWatchdog();

		if( b_NewCommand )
		{
			b_NewCommand = FALSE;
			ProcessCommand();
		}

		if( b_PeriodicTimer )
		{
			b_PeriodicTimer = FALSE;
			PerformPeriodicTasks();
		}

		UpdateSystemStatus();
	}
}

Thanks for your code sample.

I am puzzled by how your code would work for complex program.

For example, ProcessCommand(); would branch out of main, and within ProcessCommand();, there are more functions for getting user input and processing interrupts.

In short do I have to implement something similar for each subprogram ?

Thanks

I am puzzled by how your code would work for complex program. ...


Of cause it depends on the stucture of your program, if this kind of solution is appropriate. But I found this approach very useful for many solutions.
Most of the embedded modules, for that I wrote the firmware, work almost autonomous. The processing of a command usually requires no further interaction.

E.g. a module that controls the temperature of a chemical reactor has a command, that allows to change the temperature set-point.
The new set-point is part of the command message. If the set-point is in the valid range, the command is acknowledged and the set-point is changed, otherwise an error code is sent as answer.
An interrupt from an ADC triggers the temperature control each time a new temperature reading is available. Eventually the current temperature and the deviation to the set-point are reported to somewhere, too.

I hope this simple example helps you to understand, how this approach can be used.

Regards,
Tim