Re: [riot-devel] Removing thirdparty repositories

2015-03-21 Thread Joakim Gebart
I haven't looked too closely, but I think at least the ideas put
forward in https://github.com/RIOT-OS/thirdparty_cpu/pull/3 are
useful. The PRs are old so they probably won't work on the current
master but the LPM stuff is interesting.
On the thirdparty_boards repo I didn't find anything interesting.

Best regards,
Joakim Gebart
www.eistec.se


On Sun, Mar 22, 2015 at 12:12 AM, Oleg Hahm  wrote:
> Dear rousing IoTlers,
>
> since we don't need the thirdparty repositories for CPUs and boards any more
> for quite some time, I think we should finally remove them. Any objections?
> Can anyone with some experience with the Cortex ports take a look at the PRs
> in these repos that are still open and see if they contain anything useful
> that might be applied to the current implementation in RIOT master?
>
> Cheers,
> Oleg
> --
> arrival order packet joke is critical to good a make
>
> ___
> 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

2015-03-21 Thread Joakim Gebart
On Sun, Mar 22, 2015 at 12:18 AM, Oleg Hahm  wrote:
> Hi!
>
>> > 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.
>
> This somehow disappeared from my radar. I think you need to give me admin
> access to the repository in order to move it to the RIOT organization (and
> rename it to riotdocker).

What do you mean?
If you create a new empty riotdocker repo in the RIOT organization we
can push the Dockerfile commits to it.

>
> Cheers,
> Oleg
> --
> /* The HME is the biggest piece of shit I have ever seen. */
> linux-2.6.6/drivers/scsi/esp.h
>
> ___
> 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

2015-03-21 Thread Oleg Hahm
Hi!

> > 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.

This somehow disappeared from my radar. I think you need to give me admin
access to the repository in order to move it to the RIOT organization (and
rename it to riotdocker).

Cheers,
Oleg
-- 
/* The HME is the biggest piece of shit I have ever seen. */
linux-2.6.6/drivers/scsi/esp.h


pgpGhnyaerHzV.pgp
Description: PGP signature
___
devel mailing list
devel@riot-os.org
http://lists.riot-os.org/mailman/listinfo/devel


[riot-devel] Removing thirdparty repositories

2015-03-21 Thread Oleg Hahm
Dear rousing IoTlers,

since we don't need the thirdparty repositories for CPUs and boards any more
for quite some time, I think we should finally remove them. Any objections?
Can anyone with some experience with the Cortex ports take a look at the PRs
in these repos that are still open and see if they contain anything useful
that might be applied to the current implementation in RIOT master?

Cheers,
Oleg
-- 
arrival order packet joke is critical to good a make


pgpLnn6gnTzVS.pgp
Description: PGP signature
___
devel mailing list
devel@riot-os.org
http://lists.riot-os.org/mailman/listinfo/devel


Re: [riot-devel] C Bitfields and network_uint16_t

2015-03-21 Thread Martine Lenders
Hi Simon,
you can use network_uint16_t as integer by accessing it's u16 member, but
since bitfields are usually accessed using bit-arithmetics anyways I'm
wondering if it makes so much sense to use network_uint16_t, since they are
primarily used to warn about byteorder issues.

Cheers,
Martine

2015-03-21 21:01 GMT+01:00 Simon :

> Hi Everyone,
>
> I am trying to define the Header Datastructure for the new TCP
> implementation. I'd like to use C Bitfields in structs for the Control
> Bits and would like to use the Type of network_uint16_t (That seems to
> be common for most other Header Structures). My compiler tells me that
> thats not possible because network_uint16_t is not an integer type.
>
> In Byteorder.h it shows that its actually a union. Has anyone an Idea to
> solve this issue? I would really like to use only network types in my
> structure.
>
> Thanks in advance.
>
> Yours sincerly
> Simon Brummer
>
>
> ___
> 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


[riot-devel] C Bitfields and network_uint16_t

2015-03-21 Thread Simon
Hi Everyone, 

I am trying to define the Header Datastructure for the new TCP
implementation. I'd like to use C Bitfields in structs for the Control
Bits and would like to use the Type of network_uint16_t (That seems to
be common for most other Header Structures). My compiler tells me that
thats not possible because network_uint16_t is not an integer type.

In Byteorder.h it shows that its actually a union. Has anyone an Idea to
solve this issue? I would really like to use only network types in my
structure. 

Thanks in advance. 

Yours sincerly 
Simon Brummer 


___
devel mailing list
devel@riot-os.org
http://lists.riot-os.org/mailman/listinfo/devel


Re: [riot-devel] Biweekly virtual meeting

2015-03-21 Thread Oleg Hahm
Dear radioing IoTlers,

the next regular bi-weekly PlaceCam meeting would usually be scheduled next
Wednesday at 10am CET. However, since we have some potential participants in
other timezones (including me), I would like to ask if we could reschedule the
meeting to 2pm CET again? This would be 8am CDT (e.g. Dallas) and 6:30pm IST
(India) if I'm not mistaken.

Cheers,
Oleg
-- 
panic("Lucy in the sky");
linux-2.2.16/arch/sparc64/kernel/starfire.c


pgp8_39b8RM2E.pgp
Description: PGP signature
___
devel mailing list
devel@riot-os.org
http://lists.riot-os.org/mailman/listinfo/devel


Re: [riot-devel] Iotivity, AllJoyn, Thread, Ipso Alliance

2015-03-21 Thread Carsten Bormann
Oleg Hahm wrote:
>  I (and I guess I'm speaking for most of us) want a
> (R)IOT device being able to be connected _directly_ to anything. Be it another
> RIOT powered device, a Contiki device, my home gateway, my smartphone, or any
> server in the Internet. 

That's why it's called "Thing-to-thing research group"!

> Protocols for the IoT should not rely on the fact that
> there is something more powerful that translates their messages to the rest of
> the world.

There is nothing wrong with factoring in something more powerful for
setup, human interface etc.  But for doing their job, where
thing-to-thing communication is the appropriate mode for that job, we
should be able to do it.  It's the Internet way...

I'm also looking forward to the IoTivity and AllSeen talks today.
Too bad we couldn't find someone from Thread to talk.

Grüße, Carsten
___
devel mailing list
devel@riot-os.org
http://lists.riot-os.org/mailman/listinfo/devel


Re: [riot-devel] Iotivity, AllJoyn, Thread, Ipso Alliance

2015-03-21 Thread Oleg Hahm
Hi!

I just realized that I'll probably learn something about  IoTivity and AllJoyn
today at the T2TRG meeting:
https://github.com/t2trg/2015-ietf92/blob/master/agenda.md

I guess there won't be now audio stream, but at least the slides should be
online later this day.

> Concerning IoTBase, I would add that they're thinking about a stack for
> constrained devices [1] so it might be easier to implement on RIOT. 

Looks indeed interesting at a first glance. We should have an eye on this and
see if someone's willing to give it a try with RIOT.

> As you said, Riot nodes will be connected to something more powerful but
> this kind of protocol avoids to create new proprietary protocols.

Just for clarification: I (and I guess I'm speaking for most of us) want a
(R)IOT device being able to be connected _directly_ to anything. Be it another
RIOT powered device, a Contiki device, my home gateway, my smartphone, or any
server in the Internet. Protocols for the IoT should not rely on the fact that
there is something more powerful that translates their messages to the rest of
the world.

> I found this link on stackoverflow where they compare AllJoyn and
> IoTivity.[2]

Thanks for the pointer.

Cheers,
Oleg
-- 
printk("Entering UltraSMPenguin Mode...\n");
linux-2.2.16/arch/sparc64/kernel/smp.c


pgptpor10Mxlt.pgp
Description: PGP signature
___
devel mailing list
devel@riot-os.org
http://lists.riot-os.org/mailman/listinfo/devel


[riot-devel] Nucleo L1 Wiki article renamed

2015-03-21 Thread Ludwig Ortmann
Hi,

in case anyone wonders what happened to the Wiki entry;
https://github.com/RIOT-OS/RIOT/wiki/Board%3A-ST-nucleo-l1

I renamed it to
https://github.com/RIOT-OS/RIOT/wiki/Board:-Nucleo-L1
in order to match the naming scheme of the other Nucleo boards.

Cheers,
Ludwig
___
devel mailing list
devel@riot-os.org
http://lists.riot-os.org/mailman/listinfo/devel