Hi Hauke,
I have not consider the RIOT design guideline of reducing macro usage.
In this regard your solution is also for me much better.
The only (IMHO minor) advantage for using "complex" macro is little saving
in cpu cycles and stack memory usage.
ciao
Attilio
On Mon, Feb 23, 2015 at 11:35 AM, Hauke Petersen <
hauke.peter...@fu-berlin.de> wrote:
> Hi Attilio,
>
> personally I think Macros might not be the best idea - one of the design
> principles of RIOT so far is to limit the use of Macros to the minimum. You
> can actually get the same results for the code below by using a plain API
> based approach:
>
> log_api.h:
> void log_info(...);
>
> implementations 1:
> void log_info(...) {
> printf(...);
> }
>
> implementation 2:
> void log_info() { /* this function will be optimized away... */
> /* do nothing here */
> }
>
> Now when setting up your project, just tell the make file which of the
> implementations to use:
> USEMODULE+=log_implementation1
> or
> USEMODULE+=log_implementation2
>
> This soultion does not only scale better, but it is IMHO the cleaner
> approach.
>
> Cheers,
> Hauke
>
>
>
>
> On 23.02.2015 11:25, Attilio Dona wrote:
>
> Hi Ludwig,
>
> In my simple tinking the macro approach does not exclude the API, just a
> pseudo code example:
>
>
> API log_api.h:
>
> ...
>
> void log.info(const char* fmt, ...);
>
> ...
>
> #ifdef ENABLE_INFO
> #define LOG_INFO(...) log.info(__VA_ARGS__)
> #else
> #define LOG_INFO(...)
> #endif
>
>
>
> In RIOT framework and application code use exclusively the macro
> LOG_INFO, LOG_DEBUG, ecc. ecc. so you have one more degree of freedom for
> easy including/stripping the tracing code from the binary.
>
> Another advantage with the macro usage is obviously the possibility to
> change to another logging implementation in one place instead of modifying
> all source lines where log is instrumented.
>
> Attilio
>
>
>
>
> On Mon, Feb 23, 2015 at 10:04 AM, Ludwig Ortmann <
> ludwig.ortm...@fu-berlin.de> wrote:
>
>> Hi Attilio, Martine,
>>
>> are you suggesting macros are better than APIs + functions?
>> If so, please explain why and what better means ;)
>>
>> Cheers, Ludwig
>>
>> On Mon, Feb 23, 2015 at 09:26:34AM +0100, Attilio Dona wrote:
>> > Also for me the MACRO approach has to be considered in a design review,
>> > eventually in addition to a tracing API layer.
>> >
>> > Just to add my bit of experience with RIOT about porting msp430 family
>> on
>> > new TI/redhat gcc 4.9:
>> >
>> > the default nanolib bundled with the toolchain implies a big printf
>> memory
>> > usage, not suitable for a lot of msp430 chips.
>> >
>> > At the moment my solution is to use tinyprintf:
>> >
>> > https://github.com/cjlano/tinyprintf
>> >
>> > It works as expected, with some minor modification to suit my port.
>> >
>> > Greetings
>> > Attilio
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> > On Mon, Feb 23, 2015 at 8:24 AM, Martine Lenders <
>> authmille...@gmail.com>
>> > wrote:
>> >
>> > > +1 thought about this for a long time, too. Though my approach would
>> be
>> > > with macros and more global (similar to how DEBUG is now).
>> > >
>> > > Am 23.02.2015 07:16 schrieb "Ludwig Ortmann" <
>> ludwig.ortm...@fu-berlin.de
>> > > >:
>> > >
>> > > >
>> > > > Hi Jozef,
>> > > >
>> > > > AFAIK there has been no work on a solution so far.
>> > > > However, I thought about this the other day in the context of the
>> > > function pointer discussion and would like to propose a "logging" API
>> > > (maybe there is an issue for that as well somewhere) for `core`, which
>> > > offers things like `log.info(...)` and `log.error(...)`.
>> > > > Different logging modules can implement this API then, ranging from
>> > > `printf` over file based logging to network messages.
>> > > > And then there should also be a `(void) ...` implementation which
>> suits
>> > > production and ultra low memory needs.
>> > > >
>> > > > Opinions?
>> > > >
>> > > > Cheers, Ludwig
>> > > >
>> > > > Am 23. Februar 2015 03:16:33 MEZ, schrieb Jozef Maslik <
>> > > ma...@binarylemon.com>:
>> > > > >
>> > > > >Hi,
>> > > > >
>> > > > >Could you please give me information about actual state of "replace
>> > > > >printf and puts" issues?
>> https://github.com/RIOT-OS/RIOT/issues/994,
>> > > > >https://github.com/RIOT-OS/RIOT/issues/641
>> > > > >
>> > > > >I’m working with MKL02Z32 which has 4kB RAM. Printf or puts which
>> are
>> > > > >almost everywhere make a big problem. I removed them from my fork,
>> but
>> > > > >it is not good or nice solution.
>> > > > >
>> > > > >If I miss something important around “printing issue” please
>> correct
>> > > > >me.
>> > > > >How others deal with this issue? (printf or puts usage like here,
>> is
>> > > > >not nessesary in real applications).
>> > > > >
>> > > > >Regards,
>> > > > >Jozef
>> > > > >
>> > > > >_______________________________________________
>> > > > >devel mailing list
>> > > > >devel@riot-os.org
>> > > > >http://lists.riot-os.org/mailman/listinfo/devel
>> > > >
>> > > > _______________________________________________
>> > > > devel mailing list
>> > > > devel@riot-os.org
>> > > > http://lists.riot-os.org/mailman/listinfo/devel
>> > >
>> > >
>> > > _______________________________________________
>> > > devel mailing list
>> > > devel@riot-os.org
>> > > http://lists.riot-os.org/mailman/listinfo/devel
>> > >
>> > >
>>
>> > _______________________________________________
>> > devel mailing list
>> > devel@riot-os.org
>> > http://lists.riot-os.org/mailman/listinfo/devel
>>
>> _______________________________________________
>> devel mailing list
>> devel@riot-os.org
>> http://lists.riot-os.org/mailman/listinfo/devel
>>
>
>
>
> _______________________________________________
> devel mailing
> listdevel@riot-os.orghttp://lists.riot-os.org/mailman/listinfo/devel
>
>
>
> _______________________________________________
> devel mailing list
> devel@riot-os.org
> http://lists.riot-os.org/mailman/listinfo/devel
>
>
_______________________________________________
devel mailing list
devel@riot-os.org
http://lists.riot-os.org/mailman/listinfo/devel
