Re: [riot-devel] replace printf, puts issue
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 list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Repository for Docker builds
Hi Joakim, +1 from my side! Cheers, Hauke On 23.02.2015 09:35, Oleg Hahm wrote: Hi Joakim! I'm completely fine with that. Thanks for the effort! Cheers, Oleg Am Mon, Feb 23, 2015 at 09:18:42AM +0100 schrieb Joakim Gebart: I'd like to hear if anyone is strongly opposed to this, otherwise I will go ahead and create a new repository tomorrow. Best regards, Joakim Gebart www.eistec.se On Sun, Feb 22, 2015 at 2:51 PM, Ludwig Ortmann ludwig.ortm...@fu-berlin.de wrote: Hi, fine with me, thank you for the initiative =) Cheers, Ludwig On Sun, Feb 22, 2015 at 11:54:16AM +0100, Joakim Gebart wrote: Dear relentless RIOTers, I would like to introduce an official repository for keeping Dockerfiles used for building Docker images. The images can be used to build RIOT in conjunction with the work being proposed in [1]. The images will contain supported versions of tool chains to make getting started with RIOT more convenient. I volunteer as maintainer for the Dockerfile repository and the pre-built images which will be published at the Docker hub [2]. The reason for making a separate repository instead of using /dist/X is that we can more easily keep track of tool chain updates, and we can use the Docker hub automatic build feature to automatically update the images. Using the core RIOT code repo for Dockerfiles will cause an unnecessary amount of rebuilds when watching it with the automatic build feature of the Docker hub. [1]: https://github.com/RIOT-OS/RIOT/pull/2392 [2]: https://registry.hub.docker.com/repos/riot/ Best regards, Joakim ___ 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
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 http://log.info(const char* fmt, ...);
...
#ifdef ENABLE_INFO
#define LOG_INFO(...) log.info http://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 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
authmille...@gmail.com 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
ludwig.ortm...@fu-berlin.de 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 http://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 mailto: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 mailto:devel@riot-os.org
http://lists.riot-os.org/mailman/listinfo/devel
___
devel mailing list
devel@riot-os.org mailto:devel@riot-os.org
http://lists.riot-os.org/mailman/listinfo/devel
___
devel mailing list
devel@riot-os.org mailto:devel@riot-os.org
[riot-devel] This week's developer meeting
Dear rocking IoTlers, due to the embedded world this week, several maintainers won't be available for this week's PlaceCam meeting. Hence, I have two questions: 1.) Is there anything urgent to discuss or can we skip the meeting? 2.) If we don't want to skip the meeting, is there anyone available for hosting the session? Cheers, Oleg -- Perl’s 1st theorem: for each Perl script there is a more readable equivalent assembly program. pgpwwW_mxUBlQ.pgp Description: PGP signature ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Repository for Docker builds
Hi Joakim! I'm completely fine with that. Thanks for the effort! Cheers, Oleg Am Mon, Feb 23, 2015 at 09:18:42AM +0100 schrieb Joakim Gebart: I'd like to hear if anyone is strongly opposed to this, otherwise I will go ahead and create a new repository tomorrow. Best regards, Joakim Gebart www.eistec.se On Sun, Feb 22, 2015 at 2:51 PM, Ludwig Ortmann ludwig.ortm...@fu-berlin.de wrote: Hi, fine with me, thank you for the initiative =) Cheers, Ludwig On Sun, Feb 22, 2015 at 11:54:16AM +0100, Joakim Gebart wrote: Dear relentless RIOTers, I would like to introduce an official repository for keeping Dockerfiles used for building Docker images. The images can be used to build RIOT in conjunction with the work being proposed in [1]. The images will contain supported versions of tool chains to make getting started with RIOT more convenient. I volunteer as maintainer for the Dockerfile repository and the pre-built images which will be published at the Docker hub [2]. The reason for making a separate repository instead of using /dist/X is that we can more easily keep track of tool chain updates, and we can use the Docker hub automatic build feature to automatically update the images. Using the core RIOT code repo for Dockerfiles will cause an unnecessary amount of rebuilds when watching it with the automatic build feature of the Docker hub. [1]: https://github.com/RIOT-OS/RIOT/pull/2392 [2]: https://registry.hub.docker.com/repos/riot/ Best regards, Joakim ___ 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 -- I'd make a joke about UDP, but I don't know if anyone's actually listening... pgpyErbM5b43Q.pgp Description: PGP signature ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Repository for Docker builds
Hi Joakim! What is a suitable name for the new repo? I have been using riotbuild for my Docker development at https://github.com/gebart/riotbuild I don't have any particular ideas for the name, so, for me riotbuild (or riotdocker) would be fine. Also, I need to have an organisation owner (Oleg, Kaspar, Emmanuel or Matthias Wählisch) create the repo since maintainers do not have the proper access to do it. Sure, I can do so. Let's wait if no one objects against the proposed name. Cheers, Oleg -- The problem with git jokes is everyone has their own version. pgpNrN0Dn8mQD.pgp Description: PGP signature ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
