Re: [riot-devel] replace printf, puts issue

[Oleg Hahm]

Hi!

> I more incline to use macros, but implement logging API too. Logging
> functions can be use as default macro value in big MCUs (or MPUs).

+1

Cheers,
Oleg
-- 
panic("Detected a card I can't drive - whoops\n");
linux-2.2.16/drivers/net/daynaport.c


pgpqP1up6VV75.pgp
Description: PGP signature
___
devel mailing list
devel@riot-os.org
http://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] replace printf, puts issue

[Ludwig Ortmann]

Hi,

Here's the PR:
https://github.com/RIOT-OS/RIOT/pull/2503

Please discuss!

Cheers, Ludwig

On Fri, Feb 27, 2015 at 07:08:43AM +0100, Ludwig Ortmann wrote:
> Hi,
> 
> Yes, we came to the same conclusion while driving to embedded world.
> I've got the implementation and API  specification ready as well and will 
> open a PR later.
> 
> Cheers, Ludwig
> 
> Am 27. Februar 2015 02:14:51 MEZ, schrieb Jozef Maslik 
> :
> >Hi,
> >
> >Yes compiler do not optimize (remove out) empty function defined as is
> >suggested.
> >But if RIOT does not want use macros, we can define empty function as
> >static inline function in header and then will be removed by
> >optimization.
> >
> >log_api.h
> >
> >#if MODULE_LOG
> >void log_info(...);
> >#else
> >static inline void log_info(...) {}
> >#endif
> >
> >
> >BTW. Hauke idea use modules is nice.
> >
> >Regards,
> >Jozef
> >
> >
> >
> >
> >
> >> On 23 Feb 2015, at 13:00, Martine Lenders 
> >wrote:
> >> 
> >> Hi,
> >> 
> >> Am 23.02.2015 10:04 schrieb "Ludwig Ortmann"
> >:
> >> > are you suggesting macros are better than APIs + functions?
> >> > If so, please explain why and what better means ;)
> >> 
> >> I was not sure if the compiler optimizes out empty functions, so I
> >assumed
> >> 
> >> #define INFO(msg) (void)0;
> >> 
> >> to be the better solution concerning code size.
> >> 
> >> Regards, 
> >> Martine
> >> ___
> >> 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

Re: [riot-devel] replace printf, puts issue

[Ludwig Ortmann]

Hi,

Yes, we came to the same conclusion while driving to embedded world.
I've got the implementation and API  specification ready as well and will open 
a PR later.

Cheers, Ludwig

Am 27. Februar 2015 02:14:51 MEZ, schrieb Jozef Maslik :
>Hi,
>
>Yes compiler do not optimize (remove out) empty function defined as is
>suggested.
>But if RIOT does not want use macros, we can define empty function as
>static inline function in header and then will be removed by
>optimization.
>
>log_api.h
>
>#if MODULE_LOG
>void log_info(...);
>#else
>static inline void log_info(...) {}
>#endif
>
>
>BTW. Hauke idea use modules is nice.
>
>Regards,
>Jozef
>
>
>
>
>
>> On 23 Feb 2015, at 13:00, Martine Lenders 
>wrote:
>> 
>> Hi,
>> 
>> Am 23.02.2015 10:04 schrieb "Ludwig Ortmann"
>:
>> > are you suggesting macros are better than APIs + functions?
>> > If so, please explain why and what better means ;)
>> 
>> I was not sure if the compiler optimizes out empty functions, so I
>assumed
>> 
>> #define INFO(msg) (void)0;
>> 
>> to be the better solution concerning code size.
>> 
>> Regards, 
>> Martine
>> ___
>> 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

Re: [riot-devel] replace printf, puts issue

[Jozef Maslik]

Hi,

Yes compiler do not optimize (remove out) empty function defined as is 
suggested.
But if RIOT does not want use macros, we can define empty function as static 
inline function in header and then will be removed by optimization.

log_api.h

#if MODULE_LOG
void log_info(...);
#else
static inline void log_info(...) {}
#endif


BTW. Hauke idea use modules is nice.

Regards,
Jozef





> On 23 Feb 2015, at 13:00, Martine Lenders  wrote:
> 
> Hi,
> 
> Am 23.02.2015 10:04 schrieb "Ludwig Ortmann" :
> > are you suggesting macros are better than APIs + functions?
> > If so, please explain why and what better means ;)
> 
> I was not sure if the compiler optimizes out empty functions, so I assumed
> 
> #define INFO(msg) (void)0;
> 
> to be the better solution concerning code size.
> 
> Regards, 
> Martine
> ___
> 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

Re: [riot-devel] replace printf, puts issue

[Martine Lenders]

Hi,

Am 23.02.2015 10:04 schrieb "Ludwig Ortmann" :
> are you suggesting macros are better than APIs + functions?
> If so, please explain why and what better means ;)

I was not sure if the compiler optimizes out empty functions, so I assumed

#define INFO(msg) (void)0;

to be the better solution concerning code size.

Regards,
Martine
___
devel mailing list
devel@riot-os.org
http://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] replace printf, puts issue

[Attilio Dona]

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/deve

Re: [riot-devel] replace printf, puts issue

[Jozef Maslik]

Hi,

I really focused to this problem, because I do not have target to duplicate 
code base only because here missing this “small” things ;)

From my side:
- logging API is good idea, it can by nice to have possibilities implement 
logging to any output (stdout, file, net, etc.)
- macros can have some limitation and can be problem in some cases, but it 
depend how we use it ;) - I do not have problem with it, it is usual way in 
many other projects. After short look to source code, there is many places 
which use DEBUG macro (but more places with printf/puts, too).
- if we use macros, there can be easy and fast way how to change logging 
function. Yes, this way can be dirty but switching between simple printf and 
“log.error” will be without impact to the resources (code size, mem usage and 
execution time - call the printf directly opposite call the printf inside 
logging subsystem).
- if we use logging subsystem directly, then we will pay for bigger 
possibilities/flexibility, it has its price (cpu load, mem usage)

I more incline to use macros, but implement logging API too. Logging functions 
can be use as default macro value in big MCUs (or MPUs).

Jozef

> On 23 Feb 2015, at 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  > 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  > >
> > 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"  > > 
> > > >:
> > >
> > > >
> > > > 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

Re: [riot-devel] replace printf, puts issue

[Hauke Petersen]

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 
mailto: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
mailto: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"
mailto: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
> >
> >

Re: [riot-devel] replace printf, puts issue

[Attilio Dona]

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  >
> > 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 list
devel@riot-os.org
http://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] replace printf, puts issue

[Ludwig Ortmann]

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 
> 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"  > >:
> >
> > >
> > > 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

Re: [riot-devel] replace printf, puts issue

[Attilio Dona]

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 
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"  >:
>
> >
> > 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

Re: [riot-devel] replace printf, puts issue

[Martine Lenders]

+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" :
>
> 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

Re: [riot-devel] replace printf, puts issue

[Ludwig Ortmann]

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 :
>
>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

[riot-devel] replace printf, puts issue

[Jozef Maslik]

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