PrintfP incorrectly applies power control.

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Install an application with PrintfP that does not explicitly start the 
serial port.
2. Measure idle current of the platform.
3.

What is the expected output? What do you see instead?

Since the application has not started the serial port, it should be able to go 
into an ultra-low power state. But PrintfP starts the serial port, precluding 
low power operation.

Serial port power control (along with the radio) should be left to the 
application. PrintfP should not handle the booted event to start the serial 
stack.

Please use labels and text to provide additional information.

Original issue reported on code.google.com by philip.l...@gmail.com on 2 Mar 2011 at 11:28

[GoogleCodeExporter]

The printf library was designed to be used only for debugging.  The reason it 
automatically starts the serial port is, specifically, so that applications 
don't have to.  To use printf, all you have to do is #include the printf 
library in any nesc file and make sure to include CFLAGS +=$(TOSDIR)/lib/printf 
and you are ready to go.  Can you give me an example of an application that 
requires the use of printf, but is not tethered to a machine, and thus, 
actually requires low poer operation?

Original comment by klueska on 3 Mar 2011 at 12:03

[GoogleCodeExporter]

The problem isn't when an application does it; it's when a library or subsystem 
leaves in printf. As it is now, you're faced with two options: either leave the 
possibility of debugging in and preclude low-power operation, or disable 
debugging without modifying the source of the library. 

It's always been the policy that power control of always-on hardware (radio, 
serial port) is under control of the top-level application. Printf breaks this. 
Note that SerialActiveMessageC does *not* turn on the serial port.

To simplify autostarting the serial port, Thomas wrote a component, 
SerialStartC, which handles booted to start the serial port. So that way an app 
merely needs to include the component, rather than write code.

Original comment by philip.l...@gmail.com on 3 Mar 2011 at 1:07

[GoogleCodeExporter]

I'm not 100% opposed to making this change.  I'm just worried because it may 
break people's existing code.  The current printf semantics have been in place 
for a couple of years now.  Another option would be to include the following 
definitions in one of the main system headers:

#define printf(...) 
#define printfflush(...)

This way, if you didn't include CFLAGS +=$(TOSDIR)/lib/printf in you makefile, 
the printf calls would just reduce to nothing.

I don't really have a preference either way though.  Whatever you decide is 
fine with me.  I'll just need to update the tutorial appropriately and send out 
a message on tinyos-help warning people of the semantical change in the case of 
forcing them to now start the serial stack manually. 

Original comment by klueska on 3 Mar 2011 at 1:26

[GoogleCodeExporter]

I agree, it kinda sucks that the fix breaks existing code; I wish I'd caught it 
earlier. You could also do something like put a #warning in printf that prints 
out at compilation that you need to explicitly start the stack. We could keep 
that in the tree for a while, then remove it. A message to -help and -devel 
would also be great.

Original comment by philip.l...@gmail.com on 3 Mar 2011 at 1:29

[GoogleCodeExporter]

Changes pushed.  A warning is generated if you haven't changed your 
applications semantics to the new way of doing things.  There is also a way to 
suppress this warning once you have fixed things up.  Details are in the 
warning message itself.

Original comment by klueska on 4 Mar 2011 at 12:49

[GoogleCodeExporter]

Fixed.

Original comment by philip.l...@gmail.com on 14 Mar 2011 at 3:34

• Changed state: Fixed