Re: [riot-devel] TI CC1310 and CC2650

2015-11-17 Thread b...@vpt-systems.co.za 

Hi Oleg

More a bastardized implementation.  We are running RPL and implemented 
our own channel hopping on the CC1120 with 6LowPAN.
We started off many moons ago when Things Squared V1 was available open 
source and before they went commercial.  After many implementations we 
found that the our current  platform on Contiki and associated 
"libraries" is to difficult and time consuming to maintain in the long 
run.  So we have to think in a different modeso we are in an 
investigation phase to plot long term goals.


B

On 2015-11-17 05:06 PM, Oleg Hahm wrote:

Hi Ben,

a clarification question:

Am Mon, Nov 16, 2015 at 11:23:12AM +0200 schrieb b...@vpt-systems.co.za:

We are running Contiki on our MSP430 with CC1120 and CC1190 (PA) for our
OpenWSN mesh network implementation.  Debugging is a major issue on Contiki
so I will be loading RIOT and see what is required in terms of porting

You're using OpenWSN on top of Contiki?

Cheers,
Oleg


___
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] RIOT Release 2015.09

2015-11-13 Thread b...@vpt-systems.co.za 

H All

Are there a release for TI CC13xxx chip?

Kind regards
Ben Duvenage

On 2015-10-05 10:16 PM, Oleg Hahm wrote:

Dear RIOT developers and users,

it has been a long and rocky road, but thanks to the marvellous community, we
managed to finalize the fifth official release of the RIOT operating system:
 ---
 * RIOT 2015.09*
 ---

The highlights of this release are three major parts:
* gnrc network stack
* xtimer
* cleanup of CPU and board specific code

The new generic ("gnrc") network stack is a highly modular and configurable
IPv6/6LoWPAN network stack. It implements a large number of IETF RFCs, such as
RFC 2473, RFC 4861, RFC 4944, RFC 6550, or RFC 6775. Furthermore, it provides
a unified API between the different layers and a generic network device
interface. The provided 6LoWPAN border router (6LBR) can be run on any
hardware, providing an IPv6 capable network interface or a UART for using SLIP
(RFC 1055).

A new timer subsystem is introduced by xtimer, replacing hwtimer and vtimer
modules. xtimer offers very precise timer operations as well as support for
long-term timers running over days and weeks. Along with well-known timer
operations in RIOT, it also provides a function for accurate periodic timers.
In order to ease porting of your existing RIOT code, a vtimer compatibility
layer can be used on top.

Refactoring and cleaning up the peripheral drivers as well as other CPU and
board specific code, helped to reduce the number of Makefile duplication lines
by about 50% and provide a much cleaner and easier to use interface for
porting new platforms to RIOT.

Of course this release also comes along with a variety of newly supported
boards, CPUs, and device drivers. RIOT 2015.09 has been ported to the Eistec
Mulle, Phytec phyWAVE, Zolertia ReMote, Atmel SAML21, various ST Nucleo
boards, Freescale Freedom, TI Stellaris Launchpad, the LimiFrog, and Silab's
Wonder Gecko. It supports a LC display, new light, motion, and temperature
sensors, and more accelerometers and magnetometers.

Just to give you a rough estimation about the tremendous amount of work that
has been put into this release, here are some impressive numbers:
About 580 pull requests with about 2,500 commits have been merged since the
last release and 120 additional issues have been solved. 62 people contributed
code in 277 days. 2578 files have been touched with ~320,000 insertions and
~134,000 deletions.

As a major change to our development procedures, the RIOT community will offer
long-term bug fixes for this release in a API-stable branch.

You can download the RIOT release from Github, either by cloning the
repository or using the tarball:
https://github.com/RIOT-OS/RIOT/archive/2015.09.tar.gz

Happy RIOT,
Oleg


___
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] Open WSN

2015-09-22 Thread b...@vpt-systems.co.za 

Hi Thomas

Thank you

I have with keen interest followed the development of RIOT is and see 
progress is great.


Currently I have a product running on Contiki where I use the mesh 
network side to route my data through if I can not see a break out. 
Coupled with "Drowsy"  I can get a decent battery life out of my nodes.  
All is fine but debugging and documentation is the biggest problem with 
Contiki.


I'm in an investigation phase where I evaluate all the OS's out there 
(embedded of course) to address my developing needs.

I need to run on a few platforms
PIC32MX
MSP430/2
CC13xx
with preference to the CC13xx.

I would maybe like "donate" some time to RIOT and the mesh networking 
side but can only do so after 16 /10 /2015
Where can I start or I can I just download from GITHUB and start? 
Obviously there must be a co-ordinated effort as I have seen things get 
done by RIOT'ers

Once I have something to add, to whom can I submit for approval?

Kind regards
Ben Duvenage

On 2015-09-21 09:12 PM, Thomas Eichinger wrote:

Hi Ben,

great to hear from you and about your interest in RIOT. First of all
I am really sorry for the delayed reply.

In our current approach we pull in the network stack part of OpenWSN
and apply patches with an adaption layer to map OpenWSN's hardware
abstraction to RIOT's driver model. Unfortunately the current version
used in RIOT master is quite outdated but we plan to change this and
address problems we found during the last plug test soon.
Right now we are kept busy getting a new RIOT release ready but it
improvements to OpenWSN support have a very high priority for the time
after the release is out.
(This should happen in the next couple of days)

There are also plans to improve interaction between RIOT applications
and the OpenWSN network stack. If you could imply what your specific
requirements are we can take these into account of future planning.

I hope this gives you an overview, for any further questions don't
hesitate to ask.

Best, Thomas


On 17 Sep 2015, at 8:35 CEST(+0200), b...@vpt-systems.co.za wrote:


Hi All

Not sure if this is the correct channel to start , but will never 
know unless I try.


Currently I'm running Contiki OS for my applications with all the 
problems (biggest is debugging the OS)
My applications are relying heavily on Open WSN that Contiki provide 
for the mesh network.


What are the status of OpenWSN on RIOT?

My solutions needs
1) Low power consumption
2) Wireless Mesh

Any input will be appreciated.

Kind regards
Ben Duvenage
VPT-SYSTEMS
Development Engineer

On 2015-09-14 03:25 PM, Evan Dietz wrote:


Hi Oleg,

I would be happy to give the new feature a try. When you create the 
issue, could you point to some similar implementations as 
references? This will help me implement the "riot" way.


I imagine getting the periph_uart* unit tests working on native 
would be a good start?


Thanks for the help.

Evan

On Sep 14, 2015 3:20 AM, "Oleg Hahm" <oliver.h...@inria.fr 
<mailto:oliver.h...@inria.fr>> wrote:


Hi Evan!

> This is a first time post to the forum so please excuse any newbie
> language/etiquette.

Welcome to the RIOT community and no worries about any RIOT
specific language
or etiquette.

> I'd like to test some uart-related code using native before
flashing to a
> specific board.  However it doesn't look like native cpu
supports uart.
>
> Am I missing something or is this the correct assessment?

Nope, you are correct. We just recently switched to periph/uart
support for
all boards, but since the native getchar/putchar implementation
are mapped to
the host's implementation of these functions there was no urgent
need for a
periph/uart implementation on native.

> Is there any work being done on adding uart emulation to
native?  Is this
> an issue already being tracked (i tried to check but didn't see
anything)

I guess you're right here, too: there is indeed no issue for this.
I'll open
one. Do you have interest in working on this by any chance?

Cheers,
Oleg
--
printk(KERN_CRIT "Whee.. Swapped out page in kernel page table\n");
linux-2.6.6/mm/vmalloc.c

___
devel mailing list
devel@riot-os.org <mailto: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

___
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

[riot-devel] Open WSN

2015-09-17 Thread b...@vpt-systems.co.za 

Hi All

Not sure if this is the correct channel to start , but will never know 
unless I try.


Currently I'm running Contiki OS for my applications with all the 
problems (biggest is debugging the OS)
My applications are relying heavily on Open WSN that Contiki provide for 
the mesh network.


What are the status of OpenWSN on RIOT?

My solutions needs
1) Low power consumption
2) Wireless Mesh

Any input will be appreciated.

Kind regards
Ben Duvenage
VPT-SYSTEMS
Development Engineer

On 2015-09-14 03:25 PM, Evan Dietz wrote:


Hi Oleg,

I would be happy to give the new feature a try. When you create the 
issue, could you point to some similar implementations as references? 
This will help me implement the "riot" way.


I imagine getting the periph_uart* unit tests working on native would 
be a good start?


Thanks for the help.

Evan

On Sep 14, 2015 3:20 AM, "Oleg Hahm" > wrote:


Hi Evan!

> This is a first time post to the forum so please excuse any newbie
> language/etiquette.

Welcome to the RIOT community and no worries about any RIOT
specific language
or etiquette.

> I'd like to test some uart-related code using native before
flashing to a
> specific board.  However it doesn't look like native cpu
supports uart.
>
> Am I missing something or is this the correct assessment?

Nope, you are correct. We just recently switched to periph/uart
support for
all boards, but since the native getchar/putchar implementation
are mapped to
the host's implementation of these functions there was no urgent
need for a
periph/uart implementation on native.

> Is there any work being done on adding uart emulation to
native?  Is this
> an issue already being tracked (i tried to check but didn't see
anything)

I guess you're right here, too: there is indeed no issue for this.
I'll open
one. Do you have interest in working on this by any chance?

Cheers,
Oleg
--
printk(KERN_CRIT "Whee.. Swapped out page in kernel page table\n");
linux-2.6.6/mm/vmalloc.c

___
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