PrintfP incorrectly applies power control. about tinyos-main HOT 6 CLOSED

From klueska on March 03, 2011 00:03:49
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?

from tinyos-main.

From [email protected] on March 03, 2011 01:07:33
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.

from tinyos-main.

From klueska on March 03, 2011 01:26:12
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.

from tinyos-main.

From [email protected] on March 03, 2011 01:29:41
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.

from tinyos-main.

From klueska on March 04, 2011 00:49:17
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.

from tinyos-main.

From [email protected] on March 14, 2011 15:34:28
Fixed.

from tinyos-main.