Re: [riot-devel] Switch to BSD?

2014-12-09 Thread Kaspar Schleiser
Hey, On 12/09/2014 12:43 AM, Carsten Bormann wrote: allow a potential license change to be put off As long as relicensing hasn’t happened, RIOT stays in suspended animation for those of us who care about actual pickup in products. Waiting some more (a license change has been discussed for

Re: [riot-devel] Switch to BSD?

2014-12-15 Thread Kaspar Schleiser
Hey, On 12/15/2014 11:10 AM, Ludwig Ortmann wrote: I'd rather add a static linking exception to our current license (or switch to GPL with linking exception which amounts to the same as far as I remember) What kind of static linking exception do you have in mind? Kaspar

Re: [riot-devel] Switch to BSD?

2014-12-15 Thread Kaspar Schleiser
Hey, On 12/15/2014 01:19 PM, Ludwig Ortmann wrote: On Mon, Dec 15, 2014 at 01:08:24PM +0100, Kaspar Schleiser wrote: On 12/15/2014 11:10 AM, Ludwig Ortmann wrote: I'd rather add a static linking exception to our current license (or switch to GPL with linking exception which amounts

Re: [riot-devel] Switch to BSD?

2014-12-15 Thread Kaspar Schleiser
Hey, On 12/03/2014 10:59 PM, Emmanuel Baccelli wrote: But in the first place, we would like to debate this topic. In particular: is anyone violently opposing the idea of migrating to a less restrictive license, such as BSD? If so, why? On the other hand, if you explicitly support the license

Re: [riot-devel] Switch to BSD?

2014-12-16 Thread Kaspar Schleiser
Hi, On 12/16/2014 12:44 PM, Oleg Hahm wrote: If RIOT is BSD'ed, for *me* personally time spent on it is not fun time I like to in my unpaid spare time anymore, it becomes work that is also fun. Work others can (and will) sell under their terms. I totally don't get this point. How do more

Re: [riot-devel] Switch to BSD?

2014-12-17 Thread Kaspar Schleiser
Hey, On 12/16/2014 06:09 PM, Ludwig Ortmann wrote: (L)GPL tries to put some restrictions on that. Mostly, the source code cannot realistically be sold as long it's (L)GPL. This is not correct (depending on your definition of code and selling of course). I know that you know what my definition

Re: [riot-devel] Switch to BSD?

2014-12-18 Thread Kaspar Schleiser
On 12/16/2014 06:39 PM, Oleg Hahm wrote: arguably written less code in my free time). On the other hand, free software also means that this software might be used for any purpose - even to harm or kill people. LGPL (or any other discussed license) does not prevent this. Are you feeling

Re: [riot-devel] Switch to BSD?

2014-12-18 Thread Kaspar Schleiser
Hey, On 12/18/2014 02:09 PM, Ludwig Ortmann wrote: Please explain without analogies and use concrete examples instead. We release RIOT under BSD. Company X takes the BSD'ed code and sells some infrastructure around that, but basically, they sell commercially supported RIOT under a non-free

Re: [riot-devel] Switch to BSD?

2014-12-18 Thread Kaspar Schleiser
Hey, On 12/18/2014 02:10 PM, Ludwig Ortmann wrote: (L)GPL tries to put some restrictions on that. Mostly, the source code cannot realistically be sold as long it's (L)GPL. This is not correct (depending on your definition of code and selling of course). I know that you know what my

Re: [riot-devel] New IPC API status

2015-01-26 Thread Kaspar Schleiser
Hi Adam, On 01/24/2015 09:49 AM, Adam Hunt wrote: filesystem/VFS, and maybe ELF loading). Back in November Kaspar concluded that the approach he had been working on wasn't the correct way forward and closed the PR.[1] I was wondering, is any further API work was being done outside the view of

Re: [riot-devel] LGPL compliance testing

2015-01-26 Thread Kaspar Schleiser
Hi, On 01/26/2015 05:36 PM, Joakim Gebart wrote: Is RIOT_VERSION the only thing that is automatically generated for each build? Seems like... I mean, if even a build date is included somewhere the result will not be identical. I tried this on ARM (for the hello-world example) and the

[riot-devel] LGPL compliance testing

2015-01-26 Thread Kaspar Schleiser
Hey guys, here's an initial draft on how to check for LGPL compliance: https://github.com/RIOT-OS/RIOT/wiki/LGPL-compliancy-guide This is for showing that some proprietary code has been compiled and linked with a specific version of RIOT. I wrote the wiki entry out of my head, so maybe I

Re: [riot-devel] LGPL compliance testing

2015-02-10 Thread Kaspar Schleiser
Hi, On 02/10/15 15:52, Matthias Waehlisch wrote: (1) Compiling with RIOT_VERSION: Including the RIOT_VERSION works as a trust anchor to identify the source code base. Assuming a single (valid) and trustworthy version, you wouldn't need this ingredient. Right? Correct. (2) MD5 hash:

Re: [riot-devel] About function pointers

2015-02-19 Thread Kaspar Schleiser
Hey, On 02/18/15 22:50, Oleg Hahm wrote: but we don't know which weird compilers on some esoteric hardware platform might be used for RIOT somewhere sometime, so I rather rely on optimized C code than on optimized compilers. this keeps popping up as an excuse not to do some elegant, readable,

Re: [riot-devel] LGPL compliance testing

2015-02-16 Thread Kaspar Schleiser
Hi Matthias, On 02/16/15 01:39, Matthias Waehlisch wrote: all IoT scenarios. You gave one example -- I wouldn't claim general applicability. Agreed. Several concerns have already been raised that developing for the IoT world is not the same as developing for the non-IoT world. Separating

Re: [riot-devel] LGPL compliance testing

2015-02-20 Thread Kaspar Schleiser
Hey Matthias, On 02/19/15 23:47, Matthias Waehlisch wrote: As you pointed out in your email, there are scenarios where the approach will not help due to technical reasons (and using a weird compiler might have technical reasons as well). You may consider these as irrelevant. But there is one

Re: [riot-devel] LGPL compliance testing

2015-02-20 Thread Kaspar Schleiser
Hi, On 02/20/15 13:07, Emmanuel Baccelli wrote: Saying otherwise makes clear that the persons are not aware of the troubles embedded linux companies go through when developing proprietary devices using (L)GPLed linux + libraries. What do you mean by proprietary device? Routers,

Re: [riot-devel] LGPL compliance testing - This is just to state an opinion of a different kind :-)

2015-02-20 Thread Kaspar Schleiser
Hi, On 02/20/15 13:50, Thomas C. Schmidt wrote: sorry to interrupt here: You are discussing the question whether Linux is available for more hardware than RIOT ??? No. We're discussing if developing proprietary products using RIOT is comparable to developing proprietary products using embedded

Re: [riot-devel] LGPL compliance testing

2015-02-20 Thread Kaspar Schleiser
Hi, On 02/20/15 12:41, Oleg Hahm wrote: Using a weird compiler that cannot output the required object files because it is closed source and proprietary is purely political. That compiler could be changed trivially *if it would be open source* or the vendor was inclined to do so. This doesn't

Re: [riot-devel] About function pointers

2015-02-20 Thread Kaspar Schleiser
Hi, On 02/20/15 08:01, Oleg Hahm wrote: A bit polemic: can't we use Java then and rely on a highly optimized (micro) JVM? ;) Maybe the question here is if we should concentrate on gcc and clang and keep weird, esoteric, proprietary compilers that someone might use someday in an

Re: [riot-devel] LGPL compliance testing

2015-02-13 Thread Kaspar Schleiser
Hi Matthias, On 02/13/15 11:49, Matthias Waehlisch wrote: the core technical argument that you gave is: Your approach simplifies compliance check. Simplification is nice but does not introduce additional new functions in principle. From this perspective I don't see how this approach allows us

Re: [riot-devel] Event driven drivers

2015-02-09 Thread Kaspar Schleiser
Hi Joakim, On 02/09/15 14:20, Joakim Gebart wrote: Has anyone measured the cost of the thread context switching on the different platforms? I'm mainly interested in Cortex-M4 (Kinetis). This would be a good indication of how slow an I/O device has to be before it is worth it to manually yield a

Re: [riot-devel] Project S2: RIOT as an RPython Module

2015-03-19 Thread Kaspar Schleiser
Hi AAshish, Thanks for your interest! On 03/12/15 19:36, Regmi, Aashish wrote: I was wondering if you could provide more information about the project so that I can get a clear understanding about the project and about how to get started with project. Well, some of us think that it would be

Re: [riot-devel] More convenient access to the IoT-LAB from a RIOT application

2015-03-20 Thread Kaspar Schleiser
Hi, On 03/18/15 19:23, Oleg Hahm wrote: in an application's Makefile allows to create IoT-LAB experiments, flash, reset and access the nodes right from the command line with Make in one go, Let me know what you think about this idea and what could be improved. Pretty awesome! How can I

Re: [riot-devel] kinetis common - differences between families

2015-03-14 Thread Kaspar Schleiser
Hi, On 03/13/15 19:59, Hauke Petersen wrote: Of course this leads to some duplication of code, but in the end it leaves the overall folder structure very clean and it is always clear, where the code you are currently building is coming from. No. Code duplication is evil. It leads to

Re: [riot-devel] Galileo-Board

2015-03-14 Thread Kaspar Schleiser
Hi Martine, On 03/14/15 13:05, Martine Lenders wrote: board. I can't remember: Do we support the board or was the development aborted do to the complications René encountered. If the latter one is AFAIR Galileo connects some of it's peripherals using PCI(E), so without (non-trivial) support

Re: [riot-devel] API proficiency levels

2015-03-25 Thread Kaspar Schleiser
Hey, On 03/25/2015 11:12 AM, Hauke Petersen wrote: in general I like the idea, one problem I see is however, that is not always clear, to which level an API belongs (e.g. the GPIO API is definitely used also by high-level application programmers, while still belonging to the low-level

Re: [riot-devel] Switch to BSD?

2015-03-02 Thread Kaspar Schleiser
Hey, On 02/25/2015 11:39 AM, Emmanuel Baccelli wrote: GPL with linking exception seems relevant in this discussion -- especially since eCOS, which is also a well-known embedded OS, uses this license. If we are thinking about amending an existing license, we could also try to ease the

Re: [riot-devel] LGPL compliance testing

2015-02-26 Thread Kaspar Schleiser
Hi, On 02/25/2015 09:46 PM, Murat CAKMAK wrote: So, What is the latest decision? No decision, yet. Stay tuned. ;) Should I withdraw my “pull request” for PsoC 5LP port? Definately not. I guess whatever the license discussion will lead to, it will be possible to use that port even for

Re: [riot-devel] Feedback from emworld and future plans (partnerships AND licensing)

2015-02-26 Thread Kaspar Schleiser
Hi, On 02/26/2015 12:35 PM, Jan Wagner wrote: Is the big picture clearer fo you? yes kind of. but can you please tell my what this fincancial engagement is used for? - who is defined as maintainer? RIOT is legally fully independent and will stay so. We're setting up a Verein in order

Re: [riot-devel] ENABLE_DEBUG per module?

2015-04-21 Thread Kaspar Schleiser
Hey, On 04/21/15 10:14, Oleg Hahm wrote: some time ago Martine proposed to move the `ENABLE_DEBUG` macro from file to module context [1]. Since this would effect the whole RIOT printf debugging, I would like to call on the mailing list if someone thinks that this would be a bad idea. I like

[riot-devel] Board maintainers

2015-04-26 Thread Kaspar Schleiser
Hey guys, I've added a Maintainer field to our supported platforms list [1]. Feel free to add yourself to the board ports you feel responsible for. Kaspar [1] https://github.com/RIOT-OS/RIOT/wiki/RIOT-Platforms ___ devel mailing list

Re: [riot-devel] Network API task force

2015-05-08 Thread Kaspar Schleiser
Hi, On 05/08/15 10:58, Martine Lenders wrote: just to state the opposite opinion, too: while I see the need for an API suitable for embedded use only and other stacks than the default one too, I'm of the opinion, that the POSIX sockets (needed for library and application ports) should also be

Re: [riot-devel] help

2015-05-07 Thread Kaspar Schleiser
Hi, On 05/08/15 00:23, Sonda Bousnina wrote: I'm wondering if it is possible to flash or update the code in the target board in real time while it is working without switching it off. Not sure I understand the question. You mean, add/replace code while the device is running? Are you referring

Re: [riot-devel] LPM idle_thread

2015-05-10 Thread Kaspar Schleiser
Hi, On 05/10/15 09:34, Oleg Hahm wrote: DEVELHELP should not be used to change the semantics of things. Can you elaborate? The system should behave the same whether develhelp is used or not. I would claim that this is impossible. Even a simple puts() already affects the timings, calls

Re: [riot-devel] LPM idle_thread

2015-05-10 Thread Kaspar Schleiser
Hi, On 05/10/15 10:38, Oleg Hahm wrote: I would claim that this is impossible. Even a simple puts() already affects the timings, calls peripheral drivers, and may cause interrupts. the same was bad wording. I meant semantically, like Martine initially stated. I guess you mean Ludwig. Yes,

Re: [riot-devel] LPM idle_thread

2015-05-10 Thread Kaspar Schleiser
Hi, On 05/09/15 20:24, Oleg Hahm wrote: DEVELHELP should not be used to change the semantics of things. Can you elaborate? The system should behave the same whether develhelp is used or not. If you do something like #ifdef DEVELHELP if(input_not_correct) { print(error message);

Re: [riot-devel] Network API task force

2015-05-08 Thread Kaspar Schleiser
Hi, On 05/08/15 14:51, Oleg Hahm wrote: But why couldn't udp_send(vargs) not be wrapper/macro for X_send(PROTO_UDP, vargs)? It definately could. and this udp_send shouldn't have a pktsnip as parameter. Well, you will have to specify a pointer to data. I guess the most stack agnostic way

Re: [riot-devel] Network API task force

2015-05-08 Thread Kaspar Schleiser
Hi, On 05/08/15 14:34, Oleg Hahm wrote: Sure, from the caller perspective you don't care what's happening inside the stack, but what's so wrong in having the same API at all layers, i.e. inside and on top of the stack? (Assuming that it can be implemented without (or very, very, very little

Re: [riot-devel] Network API task force

2015-05-08 Thread Kaspar Schleiser
Hi, On 05/08/15 14:38, Oleg Hahm wrote: I don't see the problem. In implementation A (the nameless stack) udp_send() calls netapi_send(UDP_THREAD_PID, pointers_to(ip_header+udp_header+payload)) and in implementation B (nanonet) udp_send() calls netapi_send(active_pid, pointer_to(payload)).

Re: [riot-devel] NSTF - Naming the stack

2015-05-18 Thread Kaspar Schleiser
+1 for generic, but do we need the abbrevation? On 05/18/15 15:55, Emmanuel Baccelli wrote: Hi everyone, concerning the name of the new network stack, and assuming it is not going to be the only network stack that RIOT hosts, here's a suggestion. The way I see it, the goal of this network

Re: [riot-devel] Support for Stellaris Launchpad LM4F120 board.

2015-05-18 Thread Kaspar Schleiser
Hi, On 05/18/15 04:23, rakendra thapa wrote: I have ported RIOT-OS to Stellaris Launchpad Evaluation board. Nice! I've got some of these lying around, will review soon. Meanwhile, I had a separate query from the fellow developers. I was also working on porting RIOT-OS to a 8-bit PIC18F uC for

Re: [riot-devel] NSTF - Naming the stack

2015-05-18 Thread Kaspar Schleiser
Hey, On 05/18/15 16:17, Oleg Hahm wrote: +1 for generic, but do we need the abbrevation? Aren't you usually the one arguing for short variable names and the like? Yes, but gnrc... ;) gns (generic network stack), gn, gnet, gen, g, ... ? Kaspar ___

Re: [riot-devel] NSTF - Naming the stack

2015-05-12 Thread Kaspar Schleiser
Hey, On 05/12/2015 09:54 AM, Oleg Hahm wrote: I just stumbled across ng_netconf - we should rename this to avoid confusion with RFC 6241 [1]. If the stack would have a name, we could simply call it NAME_conf... If nameless sticks, we could just replace all ng_ with nl_ ... Until we port

Re: [riot-devel] enums vs. macros

2015-05-13 Thread Kaspar Schleiser
Hey, On 05/13/15 08:12, Oleg Hahm wrote: Because flags have a width in memory that is in most cases smaller than sizeof(enum) (most bit fields I know of are 16 bits max, on most of our newer platforms, sizeof(enum) is however 32 bits). This results in every assignment needed to be cast to

Re: [riot-devel] NSTF meeting - detail questions

2015-04-16 Thread Kaspar Schleiser
yup. On 04/16/15 14:33, Hauke Petersen wrote: fine with me. Cheers, Hauke On 16.04.2015 14:22, Emmanuel Baccelli wrote: Hi everyone, seems the 30th is the best date? Should we plan for that then? Best Emmanuel On Thu, Apr 16, 2015 at 1:15 PM, Emmanuel Baccelli emmanuel.bacce...@inria.fr

[riot-devel] Task force ping

2015-04-09 Thread Kaspar Schleiser
Hey guys, trying a new idea: task force pings. Every task force: please give a short status update. I'll start as only member of the timer task force: - requirements collection seems complete - some thought has gone into actual implementation - stalled for lack-of-time reasons Kaspar

[riot-devel] new network stack mini howto

2015-04-11 Thread Kaspar Schleiser
Hey guys, is there any kind of example on how to set up the new network stack as far as currently possible? So many PR's, components, etc. and all I want is ping my node... Kaspar ___ devel mailing list devel@riot-os.org

Re: [riot-devel] OTA update

2015-06-09 Thread Kaspar Schleiser
Hi, On 06/09/15 12:06, Baptiste Clenet wrote: IMO, OTA is mandatory for IOT's OS and we should consider it seriously as soon as the network stack will be done/stable.(People can work on in parallel of the network stack) +1 I will probably need to implement this for a customer, so count me in.

[riot-devel] pktbuf question

2015-06-16 Thread Kaspar Schleiser
Hey, (this goes probably to Martine) The docs of ng_pktbuf_add say: If @p data is already in the packet buffer (e.g. a payload of an already allocated packet) it will not be duplicated. Does this check for pointer equality, or would it correctly de-duplicate the snip if I add e.g., just the

Re: [riot-devel] OTA update

2015-06-18 Thread Kaspar Schleiser
Hi, On 06/17/15 23:34, Baptiste Clenet wrote: * 4. This software may only be redistributed and used in connection with an *Atmel microcontroller product. * too bad. Kaspar ___ devel mailing list devel@riot-os.org

Re: [riot-devel] pktbuf question

2015-06-17 Thread Kaspar Schleiser
Hi, On 06/16/15 23:00, Kaspar Schleiser wrote: If @p data is already in the packet buffer (e.g. a payload of an already allocated packet) it will not be duplicated. Does this check for pointer equality, or would it correctly de-duplicate the snip if I add e.g., just the end of a packet

Re: [riot-devel] Open Processes Task Force

2015-05-28 Thread Kaspar Schleiser
Hey, On 05/28/15 15:59, Emmanuel Baccelli wrote: - introducing a show-stopper textual label for comments on PRs (if absent, would require less or no ACK before being merged, after some agreed-upon probation time). The idea would be to increase agility -

[riot-devel] IEEE802.15.4 discovery

2015-05-19 Thread Kaspar Schleiser
Hey, is anybody working on or are there plans for support for discovering 802.15.4 PANs? Kaspar ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] RIOT examples

2015-08-19 Thread Kaspar Schleiser
Hey, On 08/14/15 14:54, Oleg Hahm wrote: But maybe we can even live with one examples directory holding all examples, as that makes finding them very easy. I think I would also prefer a flat hierarchy and keep it simple. Does anyone have an opinion on this? Kaspar

Re: [riot-devel] Introducing: Light-weight connection API

2015-08-19 Thread Kaspar Schleiser
Hey RIOTers, On 08/17/15 19:33, Martine Lenders wrote: Both of us want to sit down on Wednesday to hammer down the last details. The API is primarily designed to wrap around any stack with minimal-sized code, and not to enable the full functionality that sockets do. We didn't really succeed

Re: [riot-devel] RIOT examples

2015-08-20 Thread Kaspar Schleiser
Hey, On 08/19/15 16:02, Andreas Paul Pauli wrote: Having the same structure as the source tree is also some kind of basic documentation of dependencies. Interesting. The first example I wrote shows how to use xtimer_usleep_until() to create periodic wakeups. I called it timer_periodic_wakeup

Re: [riot-devel] Pull request procedure

2015-08-21 Thread Kaspar Schleiser
Hey, On 08/21/15 11:01, Emmanuel Baccelli wrote: One argument for decently documented/explained code is Do I sound like I want to write complex, undocumented code? I just don't agree with a rule requiring a PR to have perfect documentation before even opening it. Documented code (might be

Re: [riot-devel] Pull request procedure

2015-08-21 Thread Kaspar Schleiser
Hey, On 08/21/15 11:35, Oleg Hahm wrote: Am I mistaken or do you react somehow allergic to the word rule here? You might have nailed it. Kaspar ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] Pull request procedure

2015-08-21 Thread Kaspar Schleiser
Hey, On 08/21/15 10:37, Oleg Hahm wrote: Now it's up to me to ask: are you trying to piss me off? For the record, Oleg and I are very good friends and usually spend awesome time together and we like discussing, so if the tone between us seems to get rude, we know each other well enough to

Re: [riot-devel] Pull request procedure

2015-08-21 Thread Kaspar Schleiser
Hey, On 08/21/15 10:37, Oleg Hahm wrote: If the code is complex and poorly documented, it sucks. Full stop! I agree 100%. But as there are no simple metrics for well documented or even easy to understand code, and we can't even agree on goto vs do() while (0), I find it difficult to have a

Re: [riot-devel] HotSpot JVM on RIOT-OS?

2015-08-11 Thread Kaspar Schleiser
Hey, On 08/11/15 11:13, Zac Harvey wrote: Has anyone here ever heard of someone trying to run a JVM (HotSpot/OpenJDK) on a RIOT-OS embedded device? RIOT targets devices that don't have enough RAM to run Linux. The official Java embedded VMs are way too fat for those devices, as they're just

Re: [riot-devel] HotSpot JVM on RIOT-OS?

2015-08-12 Thread Kaspar Schleiser
Hey, On 08/12/2015 01:36 PM, Zac Harvey wrote: still planning on using RIOT-OS if it all possible. When you're evaluating embedded JVMs, take a look at the VM used by leJOS. It seems like it could rather easily be cut out of the OS, and it is apparently very capable even on the lego NXTs

[riot-devel] RIOT examples

2015-08-14 Thread Kaspar Schleiser
Hey fellow RIOTers, listening to incoming feedback about RIOT, it seems that while we get a lot of praise for our well-documented API, it seems that people are missing more high-level concept documentation and more to-the-point examples on how to do things in RIOT. Looking at our example code,

Re: [riot-devel] Thread

2015-07-21 Thread Kaspar Schleiser
Hey, On 07/21/15 12:18, Simon Vincent wrote: Are there any plans to support the new Thread standard within RIOT. Or is anyone working on a RIOT/Thread implementation? Currently the Thread specification is closed source however they did recently release some white papers which provide some

Re: [riot-devel] Guide to add Ethernet 1 Xpro support to RIOT

2015-10-30 Thread Kaspar Schleiser
Hey, On 10/30/15 14:11, Ilias Seitanidis wrote: > Does anyone have used the encx24j600? Yes, I wote the driver and used it a lot (on the nice PoElli shield). It should be a good example on how to write a netdev2 based driver. Kaspar ___ devel mailing

Re: [riot-devel] Include in Makefile

2015-10-14 Thread Kaspar Schleiser
Hey, On 10/14/2015 09:05 AM, Baptiste Clenet wrote: Anyone? @OlegHahm , @daniel-k ? One way that comes to mind is manually filling the SRC variable in app/Makefile, e.g., SRC += ./*.c thingA/*.c Kaspar ___ devel mailing list devel@riot-os.org

Re: [riot-devel] hw timers

2015-07-09 Thread Kaspar Schleiser
Hey, On 07/09/15 18:52, Simon Vincent wrote: - RIOT only supports 32 bit timers? You should implement the periph/timer interface. Using defines in periph_conf.h, you can set a max value, e.g., 0x for 16 bit timers. Don't bother with hwtimer, that will be phased out soon, and also there's a

Re: [riot-devel] hw timers

2015-07-10 Thread Kaspar Schleiser
Hey, On 07/10/15 10:32, Simon Vincent wrote: Currently the issue I get with multiple timers is that calls to hwtimer_arch_now do not specify a timer. So you call hwtimer_arch_now and get a value. If you then use this to set a delay there are problems as when you request this delay it could

Re: [riot-devel] Using C++ in device drivers

2015-07-09 Thread Kaspar Schleiser
Hey, On 07/09/15 21:08, Joakim Gebart wrote: What are your opinions on writing device drivers or system modules in C++? Well, there are probably many things that could be written with more concise code or with less duplication in C++. But I still think that the base system should be plain C, to

Re: [riot-devel] module documentation

2015-11-17 Thread Kaspar Schleiser
Hey Martine, On 11/17/15 09:18, Martine Lenders wrote: > The module documentation for RIOT can be found here [1]. duh. ;) When I saw Ralph's question, I was looking forward to you using the opportunity to put some light in how gnrc_ipv6, gnrc_ipv6_router, ipv6_router_default, sixlowpan,

Re: [riot-devel] Save data in ROM

2015-08-27 Thread Kaspar Schleiser
Hey, On 08/27/2015 11:39 AM, Baptiste Clenet wrote: By the way, flashrom.h should provide a flashrom_read() function or I don't see the utility. Flash is usually directly accessible, no need for read(), unless the flash chip is somehow externally connected. Kaspar

Re: [riot-devel] RIOT preview for TI cc3200

2015-09-02 Thread Kaspar Schleiser
Hey Attilio, Thanks a lot for your effort on getting this board supported! On 09/01/15 21:32, Attilio Dona wrote: > I need just some confirmation, the most important is > that driverlib from TI is license compatible with RIOT > (cpu/cc32000/driverlib and cpu/cc3200/inc files used as HAL for the

Re: [riot-devel] msp430 thoughts

2015-09-07 Thread Kaspar Schleiser
Hey Eric, On 09/07/15 02:46, Eric Decker wrote: > I'd liked to possibly help you folks to avoid the same crap I ran into. That would be awesome! > who are the main msp430 developers? Hard to say. IIRC I wrote the initial port, Oleg kept it alive, then a lot of people kicked in to fix things.

Re: [riot-devel] Flash based storage system for RIOT

2015-12-07 Thread Kaspar Schleiser
Hey Lucas, On 12/07/15 15:50, Lucas Jenß wrote: > In my opinion, a solution that provides a higher-level abstraction compared > to "files" should be developed for RIOT. While I definately see the need for a higher-level abstraction, make sure you don't skip the less abstracted intermediate

Re: [riot-devel] Ubuntu to Riot Communication

2015-12-08 Thread Kaspar Schleiser
Hey, On 12/08/15 17:29, Sugang Li wrote: > 1. I am using SAM R21 board for the border_router examples, and I can > shell into the RIOT from both USB debug port and UART port (PIN: PA04 > and PA05). I just opened a pull request [1] that allows multiplexing network and shell over just one UART.

Re: [riot-devel] From hwtimer to xtimer: What Changes for RIOT Features?

2015-12-09 Thread Kaspar Schleiser
Hey, On 12/09/15 12:57, ROUSSEL Kévin wrote: > 1] Is RIOT OS kernel still *tickless*? > Does it mean that there will be an interrupt every microsecond when > 'xtimer' is used, or will we still have only an interrupt when a > time-related event actually happens (which means RIOT still qualifies

Re: [riot-devel] RIOT Wireshark Sniffer - unidentified frame format

2016-01-04 Thread Kaspar Schleiser
Hey, On 01/04/2016 01:46 AM, Mateusz Kubaszek wrote: > A few days ago I ran a sniffer application using CC1101 transceiver. The cc110x doesn't support 802.15.4 natively, so I wrote the driver to "pretend" to be 802.15.4 to the upper layers, so we can re-use 6lowpan and the rest of the network

Re: [riot-devel] Task Forces

2015-11-19 Thread Kaspar Schleiser
Hey, On 11/19/15 16:50, Emmanuel Baccelli wrote: > - would Kaspar agree he was the shepherd of the timers task force? yes. Kaspar ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] Task Forces

2015-11-19 Thread Kaspar Schleiser
Hey, On 11/19/15 14:48, Oleg Hahm wrote: > As an effort to "formalize" this idea of task forces a little bit more, I just > created a small page in the Wiki: > > What do you think? +1 I've updated the xtimer page. Kaspar ___ devel mailing list

Re: [riot-devel] Working on port to SODAQ Autonomo (SAMD21)

2016-06-15 Thread Kaspar Schleiser
Hey, On 06/15/2016 09:32 AM, Peter Kietzmann wrote: > AFAIK Kaspar has a > saml21-xpro board. Unfortunately not anymore. I think Hauke has one, or at there should be one at FU Berlin. Kaspar ___ devel mailing list devel@riot-os.org

Re: [riot-devel] Working on port to SODAQ Autonomo (SAMD21)

2016-06-15 Thread Kaspar Schleiser
Hey, On 06/14/2016 08:59 PM, Kees Bakker wrote: > Notice the TXPO and RXPO. These indicate which "pads" the pin can use on > a certain SERCOM. > So, what we can learn from this is that we need to expand uart_conf_t. > We need PAD configuration > too. yep, that makes sense. +1! Kaspar

Re: [riot-devel] Notification: Biweekly virtual meeting @ Wed Jun 15, 2016 2pm - 3pm (RIOT Events)

2016-06-15 Thread Kaspar Schleiser
Hey, On 06/15/2016 02:35 PM, Martine Lenders wrote: > Should we rathe change to skype & co? please! :) IMHO voice only is fine, so should we go with mumble? Kaspar ___ devel mailing list devel@riot-os.org

Re: [riot-devel] remote forking and scheduling

2016-06-01 Thread Kaspar Schleiser
Hey, On 06/01/2016 01:02 PM, Arash Shafiei wrote: > Has anyone worked on or thought about remote forking in the context of > Internet of Things? Well, without MMU and with the little memory we're targeting, even local forking is hard to impossible to do efficiently. > Would such thing be useful

Re: [riot-devel] LoRaWAN implementation under RIOT

2016-06-20 Thread Kaspar Schleiser
Hey anonymous, On 06/20/2016 03:20 PM, Anon Anonymous wrote: > After a couple of months I've finished a Semtech's SX1276 LoRa > transceiver driver (physical level, RX and TX) under RIOT (pull request > coming soon!) and the next step is a LoRaWAN MAC level implementation. Awesome! looking

Re: [riot-devel] Contiki as a RIOT thread

2016-01-19 Thread Kaspar Schleiser
Hey, On 01/19/2016 11:58 AM, Joakim Nohlgård wrote: I would like to hear any ideas and opinions on this list on how to effectively implement this. I really like the possiblity and always bragged that this way it is possble, but running RIOT as thread within Contiki is not (in any way that

Re: [riot-devel] Connecting RasPi with RIOT node via 6lowpan using ULAs

2016-02-10 Thread Kaspar Schleiser
Hey, On 02/10/2016 09:04 PM, Sebastian Meiling wrote: > - RasPi `sudo ip addr add fd59:7f5:2065:7622::2/64 dev lowpan0` Try setting an address based on the interface's EUI-64. Kaspar ___ devel mailing list devel@riot-os.org

Re: [riot-devel] Ethos_BR

2016-02-05 Thread Kaspar Schleiser
Hey Ilias, it is best to ask these questions on devel@riot-os.org... On 02/03/2016 12:28 PM, Ilias Seitanidis wrote: > I am currently working on RIOT with Atmel R21 boards. I want to > ask you which branch should I use for my BR and if its possible > some tips for the configuration.I tried the

Re: [riot-devel] Odd problems with xtimer

2016-02-10 Thread Kaspar Schleiser
Hey Michael, On 02/10/2016 07:57 AM, Michael Andersen wrote: > it seems that one of the nodes in the list points to itself, hence the > endless loop. > > My first question is: when is this possible? It seems at first glance > that all code paths that lead here call remove_timer to prevent this >

Re: [riot-devel] Overriding SPI speeds + gadgets drivers

2016-01-29 Thread Kaspar Schleiser
Hey, On 01/29/2016 01:56 PM, Marc wrote: I would like to drive the SPI at speeds currently not in the enum types. What would be the best approach (ie. what would be accepted in a pull request) : - adding extra speeds to the global enum Sounds the most sensible. Also, I'm wondering if

Re: [riot-devel] Running Java on RIOT-OS

2016-01-31 Thread Kaspar Schleiser
Hey, On 01/30/2016 01:36 PM, Zac Harvey wrote: > You mention several major problems with running Java + RIOT-OS (or > really any RTOS) together, namely garbage collection and VTABLE-related > performance issues. If I *did* go down the road of either GCJ or LLVM, > would they somehow

Re: [riot-devel] Is the "netif" module used anymore?

2016-01-25 Thread Kaspar Schleiser
Hey Aaron, On 01/25/2016 09:49 AM, Aaron Sowry wrote: > I notice that there's references to it scattered throughout the code > (the default example, for example), but nothing that seems to have any > real effect. Unless I'm missing something. "netif" is a pseudo-module. All network device

Re: [riot-devel] Odd problems with xtimer

2016-02-19 Thread Kaspar Schleiser
Hey Michael, On 02/10/2016 11:08 PM, Michael Andersen wrote: > One question, in the network stacks, are there ever two threads possibly > using the same timer object? I ask because the timer_remove and the > insert are in two different critical sections, and if there are > concurrent calls with

Re: [riot-devel] Just another good reason not to implement printf() yourself

2016-03-10 Thread Kaspar Schleiser
Hey, On 03/10/2016 11:58 PM, malo wrote: > as for the most un needed option of the year 2016:) - my target is riot > running 6lowpan host with 6lowpan ndp support plus coap server on 8kB of > ram. so do not have that much memory to waste for printf. Am I the only one? Not at all. Did you try

Re: [riot-devel] Call for conn Task Force

2016-03-19 Thread Kaspar Schleiser
Hey, On 03/16/2016 01:39 PM, Martine Lenders wrote: > our current conn API is not very beta at best. This is why I think we > need to re-discuss it. > > Anyone willing to join? I'd like to join. Kaspar ___ devel mailing list devel@riot-os.org

Re: [riot-devel] xtimer problem

2016-04-07 Thread Kaspar Schleiser
Hey Theodore, On 04/07/2016 06:08 PM, Theodore Kotsonis wrote: > The problem isn't in printfs. They show up but I get this error. Can you show the whole code? Your snippets are correct, the error must be somewhere else. Kaspar ___ devel mailing list

Re: [riot-devel] CC110x and CC112x addressing

2016-04-08 Thread Kaspar Schleiser
Hey Mateusz, On 04/08/2016 06:58 PM, Mateusz Kubaszek wrote: > How to set correct transceiver address, so that the 1B addresses > generated from netif headers will match the destination node 1B address? Are you trying to use sixlowpan? Then the least significant byte of a node's IPv6 address has

Re: [riot-devel] Bridge border router and 6LowPan interfaces

2016-03-07 Thread Kaspar Schleiser
Hey, On 03/07/2016 08:43 AM, Baptiste Clenet wrote: > @Cenk (or anyone), could you give me some help on that please? Just so I understand correctly: you basically want to sniff traffic that passes between the two samr21 on linux via the tun interface? There's currently no support for that. Do

[riot-devel] new CI

2016-03-04 Thread Kaspar Schleiser
Hey fellow RIOTers, I'm testing a new CI server. You'll see results from "RIOT CI" popping up. This system is in testing phase, so for now, don't put too much value in those results. We'll announce if that CI is deemed stable. Have fun, Kaspar ___

Re: [riot-devel] Helping out with the CI situation

2016-03-06 Thread Kaspar Schleiser
Hey, On 03/06/2016 05:28 AM, Adam Hunt wrote: > With all the chatter about the CI situation lately I got to wondering if > there might be some way I could help out. It sound like Kaspar has > things under control with the new CI system but what about builders; are > there enough CPU cycles

  1   2   3   >