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
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
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
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
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
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
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
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
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
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
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
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
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:
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,
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
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
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,
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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,
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);
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
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
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)).
+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
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
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
___
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
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
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
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
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
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.
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
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
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
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
-
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
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
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
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
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
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
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
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
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
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
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,
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
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
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
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
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
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
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,
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
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
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.
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
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.
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
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
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
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
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
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
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
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
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
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
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
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
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
>
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
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
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
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
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
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
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
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
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
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
___
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 - 100 of 245 matches
Mail list logo
