I also intend to have OTA in my project. I'm going to help/implement it
if that's neccessary, but it's still a milestone that's further down my
roadmap.
Am 08.05.2015 um 09:04 schrieb Baptiste Clenet:
I would add that we all want this feature to be added to RIOT and we
are pleased for any
Hi Kaspar,
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 as slim as possible. This means: A
Hi Kaspar,
2015-05-08 11:09 GMT+02:00 Kaspar Schleiser kas...@schleiser.de:
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
Hi,
2015-05-08 11:25 GMT+02:00 Kaspar Schleiser kas...@schleiser.de:
Hi,
On 05/08/15 11:14, Martine Lenders wrote:
Actually, yes. But I'm still trying to get my head around why netapi (or
it's wrapper functions [1], slightly renamed) could not be that API.
Because it requires the use of
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 Kaspar,
2015-05-08 11:32 GMT+02:00 Kaspar Schleiser kas...@schleiser.de:
Hey,
On 05/08/15 11:29, Martine Lenders wrote:
On 05/08/15 11:14, Martine Lenders wrote:
Actually, yes. But I'm still trying to get my head around why netapi
(or
it's wrapper functions [1], slightly renamed)
Hi Ludwig, Nhat,
Thanks a lot for your answers! It is much clearer now. We will estimate how
difficult it would be to adopt RIOT to our use case.
It is very attractive that RIOT is modular, supports C++ and aims to POSIX
compatibility.
I just wanted to thank you all again.
Regards,
Alex
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 Kaspar!
Actually, how a network stack internally communicates should be kept to
that stack. I was talking exactly for the upper layers, e.g., applications.
How do I bind to a UDP or TCP port? How do I write to a TCP connection?
Well, no, than you're talking exactly about the second type
Hi!
That doesn't answer the question.
A udp_send could in one implementation fill a pktbuf and use netapi,
in another implementation just call the underlying send functions and
return only when the payload has been copied into the send buffer, not
malloc'ing extra memory. That should be
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)).
12 matches
Mail list logo
