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

2015-03-23 Thread Oleg Hahm
Hi!

At least for IoTivity it should be fairly simple to port it to RIOT according
to the response I got on their mailing list:
http://lists.iotivity.org/pipermail/iotivity-dev/2015-March/000600.html

The only problem I see is the incompatible license of their implementation.

(Btw. the Contiki port seems to be more or less vaporware according to
http://lists.iotivity.org/pipermail/iotivity-dev/2015-March/000606.html).

Cheers,
Oleg
-- 
if (user_specified)
/* Didn't work, but the user is convinced this is the
 * place. */
linux-2.4.0-test2/drivers/parport/parport_pc.c


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


Re: [riot-devel] Removing thirdparty repositories

2015-03-23 Thread Oleg Hahm
Hi!

Okay, I removed it from the organization on Github. To be on the safe side I
just moved it to my personal repos.

Cheers,
Oleg
-- 
printk(KERN_DEBUG %s: Flex. T...\n, DRV_NAME);
linux-2.6.6/drivers/net/wan/dscc4.c


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


Re: [riot-devel] NSTF radio driver

2015-03-23 Thread Hauke Petersen

Hi Joakim,

as of today, I PRed a new version of the Xbee S1 radio driver[1], which 
is build 100% on the new netdev interface. I think it makes a good 
reference implementation for radio drivers, even if it is through it's 
UART interface a little different from others drivers we are supporting...


So to my opinion, the netdev interface can be considere as stable (I 
expect only very minor changes). So if you want to go ahead implementing 
your new driver, now is a good time as any!


Cheers,
Hauke

[1] https://github.com/RIOT-OS/RIOT/pull/2695


On 20.02.2015 07:25, Joakim Gebart wrote:

Dear RIOT developers,
  - Which radio driver is the most up to date with regards to the
network stack restructuring work being done in #2278?
  - How stable is the radio device API currently? Are there any more
API changes coming?
  - Would it be wise to wait until the restructuring todo list is
mostly checked off until starting work on implementing a new radio
device driver?
  - Which driver would be best to use as an example of a fully
compliant radio driver?

I am looking at implementing a driver for a new radio chip, but I do
not want to have to redo the work again in a couple of weeks because
of the network refactoring...

https://github.com/RIOT-OS/RIOT/issues/2278

Best regards,
Joakim Gebart
Managing Director
Eistec AB

Aurorum 1C
977 75 LuleƄ
Tel: +46(0)730-65 13 83
joakim.geb...@eistec.se
www.eistec.se
___
devel mailing list
devel@riot-os.org
http://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] N2 Project

2015-03-23 Thread David Reinert
The way I envision it is as a starting point for RIOT, a base. Once the project 
is integrated, then we can make changes to it as we see fit. Is that an 
accurate picture or is it more a case of utilizing the project and handling 
changes to that project that affect RIOT as they occur on Wakaama independently 
through patches? Perhaps some combination of those?




 On Mar 23, 2015, at 4:33 PM, Hauke Petersen hauke.peter...@fu-berlin.de 
 wrote:
 
 Hi David,
 
 when using Wakaama (which is certainly an option), the way would be to 
 include it in RIOT as a package and include some Makefiles that are able to 
 download/checkout the library and build it into RIOT. When choosing this 
 path, one important thing is to think of a concept for continuous 
 integration, so that the Makefiles and patches can be adjusted to changes of 
 the Wakaama implementation in an easy way.
 
 Cheers,
 Hauke
 
 
 On 23.03.2015 19:45, David Reinert wrote:
 I am almost certainly planning on using the Wakaama project(formerly 
 liblwM2M) for this project. A possibly silly question but, would a final 
 port of this implementation look similar to the various ports under 
 RIOT/pkg/ or is it more involved than that? I am just trying to get a 
 picture of what the final project would look like so I can better form a 
 clear timeline. Thanks!
 
 -David
 
 
 ___
 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] N2 Project

2015-03-23 Thread Hauke Petersen

Hi David,

when using Wakaama (which is certainly an option), the way would be to 
include it in RIOT as a package and include some Makefiles that are able 
to download/checkout the library and build it into RIOT. When choosing 
this path, one important thing is to think of a concept for continuous 
integration, so that the Makefiles and patches can be adjusted to 
changes of the Wakaama implementation in an easy way.


Cheers,
Hauke


On 23.03.2015 19:45, David Reinert wrote:
I am almost certainly planning on using the Wakaama project(formerly 
liblwM2M) for this project. A possibly silly question but, would a 
final port of this implementation look similar to the various ports 
under RIOT/pkg/ or is it more involved than that? I am just trying to 
get a picture of what the final project would look like so I can 
better form a clear timeline. Thanks!


-David


___
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] CSMA MAC-layer, Open Issues

2015-03-23 Thread Hauke Petersen

Hi Jonas,

On 20.03.2015 18:02, Jonas Remmert wrote:


1. Both, the upper layer and the current implementations of the 
ng_netdev radio drivers use task messages to signalize an event 
(Packet to be sent or Packet to receive waiting). Both message 
mechanisms send their messages to the mac_pid and therefore use the 
same message queue. If the mac-layer and the transceiver is busy with 
sending a message out or waiting for an ACK it might wait for a signal 
from the driver (RX-ready, ACK-received...). In the same time there 
might also be messages from the upper layers that can not be handled 
until the previous packet is sent out.


- I handled this problem in using the drivers call-back function in 
combination with different task lock mechanisms for upper layer 
(msg_receive) and for driver events 2x(mutex_lock), which causes in 
TASK_BLOCKED state. That method worked very well, even if I fired the 
mac-layer continously with upper layer messages.
Though this probably works fine, this is not quite how the concept was 
meant. The problem is of course there: when the MAC layer is getting 
spammed by upper layer messages, the reaction time for device driver 
messages might be not as fast... Though the messages should not be los 
(as they are queued...). The concept is based on the assumption, that 
the time needed for handling incoming messages in the MAC layer is very 
short. Also so far we basically assumed, that the MAC layer has a higher 
priority then the upper layers. This way, the MAC layer will always 
finish processing all it's queued messages before the upper layers get 
scheduled again.


2. The drivers send function builds the IEEE 802.15.4 MAC header on 
its own. The alternative would be to let the MAC layer do this job. 
This would avoid code duplication and make it easier to implement new 
radio drivers. Is there any reason to do this in the driver 
implementation?
I don't really understand the code duplication issue here... The MAC 
layer should actually not know anything about the radio frame format or 
the like, as the idea behing the MAC layer in the current form is to 
make them interchangable and usable with different network devices (not 
only 802.15.4 devices)... So to answer your question: yes!


3. Introduction of PHY dependant constants: The constants (e.g. 
SYMBOL_LENGTH used in backoff intervall, MAX_BE, MIN_BE, 
TURNAROUND_TIME, MAC_ACK_WAIT_DURATION, MAX_RETRIES..). As these 
constants are different for each type of PHY (2,5 Ghz, subGhz and also 
Modulation specific) we could put them in a struct that would be 
linked to the device descriptor.
Actually, these constants should not be constants :-) The way I would 
implement them is by naming these defines something like 
xx_DEFAULT_MAX_BE, xx_DEFAULT_TURNAROUND_TIME, etc. The you include 
fields in your device descriptor for these values and initialize them 
with these values. This way you can change them during runtime and 
define different values if you run more then 1 device concurrently...


4. Generally, a successfull TX of a packet is not signalized to upper 
layers. But how do we handle a packet that could not be sent to the 
channel (e.g. channel busy)? Should upper layer be informed about the 
failure?
So far the packets are just silently dropped. The plain netapi_send() 
does not support feedback to upper layers on the success of the send 
process - this we did to avoid deadlock scenarios and synchronization 
issues...


Cheers,
Hauke




A WIP state of the ng_kw2xrf-driver that I used for testing can be 
found in my repo [2].


a nice Weekend,
Jonas


[1] - https://github.com/RIOT-OS/RIOT/pull/2467
[2] - https://github.com/jremmert-phytec-iot/RIOT/tree/wip%40kw2xrf_ng


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


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


[riot-devel] N2 Project

2015-03-23 Thread David Reinert
I am almost certainly planning on using the Wakaama project(formerly liblwM2M) 
for this project. A possibly silly question but, would a final port of this 
implementation look similar to the various ports under RIOT/pkg/ or is it more 
involved than that? I am just trying to get a picture of what the final project 
would look like so I can better form a clear timeline. Thanks!

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


Re: [riot-devel] BLE project N2

2015-03-23 Thread Hauke Petersen

Hi Kausthub,

with a clean hardware abstraction the BLE implementation should be 
mostly independent of hardware. For the small hardware dependent part we 
propose the NRF51822 SoC (as it is broadly available and cheap), that is 
correct. But as a basic driver for the SoC's radio is already available, 
we sure think that the implementation is doable in the given timeframe.


There is no general answer regarding the deliverables: they depend on 
your proposed architecture and timetable. In the beginning of the 
project we will plan with you, which milestones are realistic and plan 
the deliverables on top of these.


Cheers,
Hauke


On 21.03.2015 03:27, Kausthub Naarayan wrote:

hi all ,

the BLE stack needs to be developed first on nrf52822 ? and is it 
possible to develop all these within 2 months ? And how do we go about 
giving deliverables for this project proposal ?

Sorry if this is a trivial question  , i am new to gsoc procedure
thanks in advance

--
Regards
Kausthub Naarayan B
9535264688


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


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