Re: [riot-devel] Just another good reason not to implement printf() yourself
Hello Oleg,
that would be even better indeed.
something like #define LOG_PRINTF(...) LOG(LOG_PRINTF, __VA_ARGS__) and to
forbid to use printf?
wbr
malo
On 1 March 2016 at 20:31, Oleg Hahm wrote:
> Hey malo!
>
> On Tue, Mar 01, 2016 at 08:25:23PM +0100, malo wrote:
> > what about to have at least "official" wrapper around printf?
> >
> > Im using tinyprintf already with riot and to have PRINTF macro defined
> > would make things much easier.
> > There are DEBUGs and LOGs together with printf-s sprinkled in the code.
> > While DEBUG and LOG can be defined to custom functions, printf no.
> Thinking
> > at printf.h with PRINTF macro + formatter macros defined - bad idea?
>
> I would rather do the other way around and get rid of all the printfs in
> RIOT
> and replace them by DEBUG and LOG_*.
>
> Cheers,
> Oleg
> --
> printk("WE HAVE A BUG HERE!!! stk=0x%p\n", stk);
> linux-2.6.6/drivers/block/cciss_scsi.c
>
> ___
> devel mailing list
> devel@riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel
>
>
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel
[riot-devel] Travis Backlog
Dear Developers, This is a friendly reminder that we should take more care of our travis backlog. Everytime a pull request gets rebased/squashed/new commits travis will enqueue a new task. This enqueing takes up space in the travis backlog and hinders us from getting quick feedback about important pull requests, which are basically ready to merge. I know that everyone loves to see her/his pull request checked by travis as soon as possible as means of a smoke test, but this "first check" can almost always be done by compiling locally! So please follow these two steps: 1) If your pull request has commits with a message that includes "SQUASH" or "FIXME" then travis will fail anyways. So why let it enqueue at the first place? Please use "[ci skip]" somewhere in your commit message if this is the case. Travis will ignore a pull request if the last commit message has "[ci skip]" somewhere in it. 2) (Maintainers only) If you notice several jobs in Travis for the same pull request, then please take the initiative and stop old jobs for obsolete commits. I also know that it's sometimes inevitable, especially when the pull request was already squashed and is basically ready to merge, but another small remark forces us to commit/amend a change. (This often happens at hack'n'acks) If a maintainer is involved in this, then again, a pointer to 2), cancel jobs for obsolete commits. Take a glance at our current travis backlog [1]. The queue is still full from yesterday's hack'n'ack session, and that was about 8-9 hours ago. Develop cautiously! Cenk [1] https://travis-ci.org/RIOT-OS/RIOT/pull_requests ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Sample applications
Hi there, I think it would be great to have a RIOT tutorial space somewhere. Two comments: - Cenk also had some input on that at https://github.com/cgundogan/RIOT-Tutorial - maybe some stuff from Alex (e.g. his upcoming Bluetooth+802.15.4 border router) could belong into applications or even examples? Cheers Emmanuel On Tue, Mar 1, 2016 at 10:35 PM, Ludwig Knüpfer < ludwig.knuep...@fu-berlin.de> wrote: > Hi, > > Based on a quick scan this looks very good indeed and think we should > incorporate it into the RIOT project space. Not sure where exactly though. > > Cheers, > Ludwig > > Am 1. März 2016 11:48:19 MEZ, schrieb Alexandre Abadie < > alexandre.aba...@inria.fr>: > >Dear Rioters, > > > >I started to use riot-os a few weeks ago now and I'd like to tell you > >that your project is totally awesome and quite well documented. > > > >I first began to write some sample applications with in mind the idea > >of providing some easy to use/understand starter tutorials showing the > >possibilities offered by riot-os (UART, GPIO, NET, etc). I tried to > >have the examples as much documented as possible (but we all know that > >this can always be improved). > >The code is already available on GitHub [1]. By the way I noticed that > >you already have a repo targeting the same idea [2]. > > > >What do you think of merging both or maybe create another repository > >called "riot-tutorials" where "aabadie/riot-apps" could be moved ? Are > >you interested in such a contribution ? > > > >Cheers, > > > >Alex > > > >[1] https://github.com/aabadie/riot-apps > >[2] https://github.com/RIOT-OS/applications > >___ > >devel mailing list > >devel@riot-os.org > >https://lists.riot-os.org/mailman/listinfo/devel > > ___ > devel mailing list > devel@riot-os.org > https://lists.riot-os.org/mailman/listinfo/devel > ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Sample applications
Hi, Based on a quick scan this looks very good indeed and think we should incorporate it into the RIOT project space. Not sure where exactly though. Cheers, Ludwig Am 1. März 2016 11:48:19 MEZ, schrieb Alexandre Abadie : >Dear Rioters, > >I started to use riot-os a few weeks ago now and I'd like to tell you >that your project is totally awesome and quite well documented. > >I first began to write some sample applications with in mind the idea >of providing some easy to use/understand starter tutorials showing the >possibilities offered by riot-os (UART, GPIO, NET, etc). I tried to >have the examples as much documented as possible (but we all know that >this can always be improved). >The code is already available on GitHub [1]. By the way I noticed that >you already have a repo targeting the same idea [2]. > >What do you think of merging both or maybe create another repository >called "riot-tutorials" where "aabadie/riot-apps" could be moved ? Are >you interested in such a contribution ? > >Cheers, > >Alex > >[1] https://github.com/aabadie/riot-apps >[2] https://github.com/RIOT-OS/applications >___ >devel mailing list >devel@riot-os.org >https://lists.riot-os.org/mailman/listinfo/devel ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
[riot-devel] Opinion on ARM mbed
I'm currently working on a my Thesis where we are evaluating/comparing four lightweight IoT OS, and we will implement the two most promising ones on a use case provided by a company that develop IoT products. We are looking at mBed, RIOT, Contiki and Zephyr and right now it looks like mBed and RIOT are best suited for the use case implementation. I can get back to you guys with my results when I'm done if you are interested. Cheers Daniel ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Just another good reason not to implement printf() yourself
Hey malo!
On Tue, Mar 01, 2016 at 08:25:23PM +0100, malo wrote:
> what about to have at least "official" wrapper around printf?
>
> Im using tinyprintf already with riot and to have PRINTF macro defined
> would make things much easier.
> There are DEBUGs and LOGs together with printf-s sprinkled in the code.
> While DEBUG and LOG can be defined to custom functions, printf no. Thinking
> at printf.h with PRINTF macro + formatter macros defined - bad idea?
I would rather do the other way around and get rid of all the printfs in RIOT
and replace them by DEBUG and LOG_*.
Cheers,
Oleg
--
printk("WE HAVE A BUG HERE!!! stk=0x%p\n", stk);
linux-2.6.6/drivers/block/cciss_scsi.c
signature.asc
Description: PGP signature
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Just another good reason not to implement printf() yourself
Hello Oleg,
what about to have at least "official" wrapper around printf?
Im using tinyprintf already with riot and to have PRINTF macro defined
would make things much easier.
There are DEBUGs and LOGs together with printf-s sprinkled in the code.
While DEBUG and LOG can be defined to custom functions, printf no. Thinking
at printf.h with PRINTF macro + formatter macros defined - bad idea?
wbr
malo
On 1 March 2016 at 15:23, Oleg Hahm wrote:
> Dear re-examining IOTlers,
>
> I know a lot of us have been unhappy with (some aspects of) Newlib for a
> long
> time, including the somewhat bloated implementation of printf(). However,
> there are IMO various good reasons not to implement printf() ourselves.
>
> https://guidovranken.wordpress.com/2016/02/27/openssl-cve-2016-0799-heap-corruption-via-bio_printf/
> gives just another good example, what could go wrong.
>
> Cheers,
> Oleg
> --
> panic("If this is a 64-bit machine, please try a 64-bit kernel.\n");
> linux-2.6.6/arch/parisc/kernel/inventory.c
>
> ___
> devel mailing list
> devel@riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel
>
>
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Opinion on ARM mbed
Hi Baptiste!
On Tue, Mar 01, 2016 at 07:14:50PM +0100, Baptiste Clenet wrote:
> This is just to know your opinion about this OS:
> https://www.mbed.com/en/
> Why RIOT is better than mbed (apart from being a multi thread OS)? It
> seems to support lot of boards and has a rich network stack.
Disclaimer: I don't know any details about mbed, but from what I know the main
differences are:
* RIOT is open source, mbed uses some blobs (e.g. for the network stack)
* RIOT believes in the power of open source and therefore uses a copyleft
license (LGPL), where mbed OS uses Apache license which encourages hardware
vendors to provide closed source drivers (see openness of Android for a bad
example)
* RIOT is a community powered OS, out there for almost three years now with a
lot of experience in IoT and (constrained) wireless networks, mbed is
driven by one commercial entity (ARM) which got released only have a year
ago as beta version from some hardware folks
* RIOT supports basically all kind of architectures for the IoT (AVR 8bit, TI
MSP430 16bit, ARM7 and ARM Cortex-M, x86...) and is vendor independent -
well, for mbed this should be quite obvious... (do they even support ARM7)
Do you know anything about the memory footprint of mbed OS?
What about standard compliance of mbed OS? I cannot remember that I have met
an mbed team on any of the five ETSI plugtests I participated with/for RIOT.
Cheers,
Oleg
--
printk("WE HAVE A BUG HERE!!! stk=0x%p\n", stk);
linux-2.6.6/drivers/block/cciss_scsi.c
signature.asc
Description: PGP signature
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Interim Hack'n'ACK
Hi! Sorry, this is getting embarrassing: http://placecam.de/call.php?c=lmakKMrDG8a35aIBNqLBvOnApExkKFntj9xXawGNgTc Cheers, Oleg On Tue, Mar 01, 2016 at 07:54:04PM +0100, Ludwig Knüpfer wrote: > Hi, > > On Tue, Mar 01, 2016 at 07:49:42PM +0100, Oleg Hahm wrote: > > Hi! > > > > On Tue, Mar 01, 2016 at 07:23:26PM +0100, Ludwig Ortmann wrote: > > > apparently there was a copy/paste error, the correct URL is: > > > http://placecam.de/call.php?c=VBYEpXi43MZ2MOrV~pegsMm6Z7woUbw.VRY0Qxal2pE- > > > > Actually, I had to switch to a different machine and different user, correct > > URL is now > > http://placecam.de/call.php?c=lmakKMrDG8a35aIBNqLBvOnApExkKFntj9xX- > > Sorry, it's not working. The debug output says: > "qml: The user whom this link belongs to could not be found." > > Cheers, > Ludwig > ___ > devel mailing list > devel@riot-os.org > https://lists.riot-os.org/mailman/listinfo/devel -- The bad thing about HTML DOM jokes is that everyone has their own interpretations, so you have to tell them 9000 different ways. signature.asc Description: PGP signature ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Interim Hack'n'ACK
Hi, On Tue, Mar 01, 2016 at 07:49:42PM +0100, Oleg Hahm wrote: > Hi! > > On Tue, Mar 01, 2016 at 07:23:26PM +0100, Ludwig Ortmann wrote: > > apparently there was a copy/paste error, the correct URL is: > > http://placecam.de/call.php?c=VBYEpXi43MZ2MOrV~pegsMm6Z7woUbw.VRY0Qxal2pE- > > Actually, I had to switch to a different machine and different user, correct > URL is now > http://placecam.de/call.php?c=lmakKMrDG8a35aIBNqLBvOnApExkKFntj9xX- Sorry, it's not working. The debug output says: "qml: The user whom this link belongs to could not be found." Cheers, Ludwig ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Interim Hack'n'ACK
Hi! On Tue, Mar 01, 2016 at 07:23:26PM +0100, Ludwig Ortmann wrote: > apparently there was a copy/paste error, the correct URL is: > http://placecam.de/call.php?c=VBYEpXi43MZ2MOrV~pegsMm6Z7woUbw.VRY0Qxal2pE- Actually, I had to switch to a different machine and different user, correct URL is now http://placecam.de/call.php?c=lmakKMrDG8a35aIBNqLBvOnApExkKFntj9xX- Cheers, Oleg -- if(ct<0) ct=2;/* Shit happens.. */ linux-2.6.6/drivers/net/wan/z85230.c signature.asc Description: PGP signature ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Interim Hack'n'ACK
Hi, apparently there was a copy/paste error, the correct URL is: http://placecam.de/call.php?c=VBYEpXi43MZ2MOrV~pegsMm6Z7woUbw.VRY0Qxal2pE- See https://github.com/RIOT-OS/RIOT/wiki/Instructions-for-remote-participation for instructions on how to participate. Currently the session is not live due to some technical problem on the hosting side, though. Keep your fingers crossed ;) Cheers, Ludwig On Tue, Mar 01, 2016 at 05:56:54PM +0100, Oleg Hahm wrote: > Dear reviewing IOTlers, > > in Berlin we're having an interim Hack'n'ACK session tonight. If someone wants > to join us remotely, you can do so at > http://placecam.de/call.php?c=3DVBYEpXi43MZ2MOrV~pegsMm6Z7woUbw.VRY0Qxal2pE- > > Cheers, > Oleg > -- > /* We are root, all done! */ > RIOT/sys/net/rpl/rpl.c > ___ > devel mailing list > devel@riot-os.org > https://lists.riot-os.org/mailman/listinfo/devel ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
[riot-devel] Opinion on ARM mbed
Hi all, This is just to know your opinion about this OS: https://www.mbed.com/en/ Why RIOT is better than mbed (apart from being a multi thread OS)? It seems to support lot of boards and has a rich network stack. Cheers, -- Baptiste ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Interim Hack'n'ACK
Since the clock selection is an Hack 'n ACK candidate. I noticed that some STM discovery boards use the Stlink's MCO output as clock source. The code currently expects an external xtal to be connected. There should be a define to switch the clock input to bypass mode. Don't know if I can join tonight, but it could save allot of time not going trough the documentation :) I will try to join remote though maybe later tonight. Cheers and Enjoy, Nick v. IJzendoorn On 1 Mar 2016 17:58, "Oleg Hahm" wrote: > Dear reviewing IOTlers, > > in Berlin we're having an interim Hack'n'ACK session tonight. If someone > wants > to join us remotely, you can do so at > > http://placecam.de/call.php?c=3DVBYEpXi43MZ2MOrV~pegsMm6Z7woUbw.VRY0Qxal2pE- > > Cheers, > Oleg > -- > /* We are root, all done! */ > RIOT/sys/net/rpl/rpl.c > ___ > devel mailing list > devel@riot-os.org > https://lists.riot-os.org/mailman/listinfo/devel > ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
[riot-devel] Interim Hack'n'ACK
Dear reviewing IOTlers, in Berlin we're having an interim Hack'n'ACK session tonight. If someone wants to join us remotely, you can do so at http://placecam.de/call.php?c=3DVBYEpXi43MZ2MOrV~pegsMm6Z7woUbw.VRY0Qxal2pE- Cheers, Oleg -- /* We are root, all done! */ RIOT/sys/net/rpl/rpl.c ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
[riot-devel] Just another good reason not to implement printf() yourself
Dear re-examining IOTlers,
I know a lot of us have been unhappy with (some aspects of) Newlib for a long
time, including the somewhat bloated implementation of printf(). However,
there are IMO various good reasons not to implement printf() ourselves.
https://guidovranken.wordpress.com/2016/02/27/openssl-cve-2016-0799-heap-corruption-via-bio_printf/
gives just another good example, what could go wrong.
Cheers,
Oleg
--
panic("If this is a 64-bit machine, please try a 64-bit kernel.\n");
linux-2.6.6/arch/parisc/kernel/inventory.c
signature.asc
Description: PGP signature
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel
[riot-devel] Sample applications
Dear Rioters, I started to use riot-os a few weeks ago now and I'd like to tell you that your project is totally awesome and quite well documented. I first began to write some sample applications with in mind the idea of providing some easy to use/understand starter tutorials showing the possibilities offered by riot-os (UART, GPIO, NET, etc). I tried to have the examples as much documented as possible (but we all know that this can always be improved). The code is already available on GitHub [1]. By the way I noticed that you already have a repo targeting the same idea [2]. What do you think of merging both or maybe create another repository called "riot-tutorials" where "aabadie/riot-apps" could be moved ? Are you interested in such a contribution ? Cheers, Alex [1] https://github.com/aabadie/riot-apps [2] https://github.com/RIOT-OS/applications ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
