Re: [riot-devel] MIPS platform (PIC32)

[Adam Hunt]

Though, if you ask me, RIOT's code is far cleaner and more approachable
than that of some other projects.

On Tue Jan 13 2015 at 3:15:56 PM Martine Lenders 
wrote:

> Hi,
>
> 2015-01-14 0:10 GMT+01:00 Adam Hunt :
>
>> […]
>>
> Aside from those you should take a look at the Porting Guide
>>  on the wiki if you
>> haven't already. You might also find the API documentation
>>  useful. Beyond that, someone correct me if I'm
>> wrong, the canonical documentation can be found in the code itself
>> .
>>
>
> At least in most cases the API documentation is auto-generated (daily
> iirc) from the canonical documentation these days. For everything else the
> law of code is still a vicious and cruel ruler ;-).
>
> Cheers,
> Martine
> ___
> 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] MIPS platform (PIC32)

[Martine Lenders]

Hi,

2015-01-14 0:10 GMT+01:00 Adam Hunt :

> […]
>
Aside from those you should take a look at the Porting Guide
>  on the wiki if you
> haven't already. You might also find the API documentation
>  useful. Beyond that, someone correct me if I'm
> wrong, the canonical documentation can be found in the code itself
> .
>

At least in most cases the API documentation is auto-generated (daily iirc)
from the canonical documentation these days. For everything else the law of
code is still a vicious and cruel ruler ;-).

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

Re: [riot-devel] MIPS platform (PIC32)

[Adam Hunt]

There are a few papers out there that provide a decent 10,000 foot view (or
3,048 meters, if you prefer).

   - RIOT OS: Towards an OS for the Internet of Things
   
   - RIOT: One OS to Rule Them All in the IoT
   
   - A real-time kernel for wireless sensor networks employed in rescue
   scenarios
   
(paywalled
   unfortunately)
   - Simply RIOT: Teaching and Experimental Research in the Internet of
   Things 

Aside from those you should take a look at the Porting Guide
 on the wiki if you
haven't already. You might also find the API documentation
 useful. Beyond that, someone correct me if I'm
wrong, the canonical documentation can be found in the code itself
.

--adam

On Tue Jan 13 2015 at 1:24:26 PM  wrote:

> Hi Adam,
>
> Does RIOT use any memory protected (do not think so since MSP430 and
> PIC do not have any) is it using any hardware specific things ?. I am
> new to RIOT that is why I ask. Is there a good ducument about the
> inner workings of RIOY OS so I can see if there are possible issues
> with MIPS.
>
> Paul.
>
> Adam Hunt  schreef:
>
> > Is there anything special about the MIPS march that would make porting
> RIOT
> > an issue? Seeing as RIOT runs on 32-bit ARMs, 16-bit MSP430s, x86, and
> now
> > even 8-bit Atmels I don't imagine there is much standing in the way of
> > another incredibly well documented architecture. Though, I've been wrong
> > before.
> >
> > On Tue Jan 13 2015 at 5:16:44 AM  wrote:
> >
> >> Hi Oleg,
> >>
> >> I do know the MIPS code very good, I am looking for a good e-book or
> >> normal book about the ARM core. The MIPS code is more powerfull per
> >> MHz and also has a better architecture. Its only a pitty that the chip
> >> technology used is less power optimized than most ARM vendors use that
> >> is why the sleep and powerdown are higher.
> >>
> >> I think this will change since microchip is busy with XLP for PIC32.
> >>
> >> regards, Paul.
> >>
> >> Oleg  schreef:
> >>
> >> > Hi Paul!
> >> >
> >> >
> >> >> Does anyone know if people are porting RIOT-OS to the MIPS platform
> >> >> and what is the status ?.
> >> >
> >> > As far as I know noone ever tried porting RIOT to MIPS and I know
> >> > too little about this platform to give any estimate about the
> >> > feasibility/difficulty of this task.
> >> >
> >> > Cheers,
> >> > Oleg
> >> > ___
> >> > 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
> >>
>
>
>
> ___
> 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] thread is not working

[Ryan Kurte]

Hi Shishir,

I seem to recall having the same issue when starting the EFM32 port.
The issue in my case was that without the startup files, the .bss section
was not getting cleared.
When the threads came to launch, the value in one of the kernel functions
was not correct. Which is pretty easy to check with a debugger.

The fix was to clear the .bss section in the _init routine, my
implementation (using symbols from the linker) is:

//Clear bss
for (uint32_t i = (uint32_t)&__bss_start__; i < (uint32_t)&__bss_end__;
i++) {
addr = (int*)i;
*addr = (int)NULL;
}

I am not sure this is the /correct/ way to do it, but the .bss definitely
needs to be initialised to zeros.

Hope that helps,

Ryan

On 14 January 2015 at 07:56, Hauke Petersen 
wrote:

> Hi,
>
> On 13.01.2015 19:04, shishir tiwari wrote:
>
>> Hi petersen,
>>
>>   Thanks for your information.
>>
>> we are trying to put your method but still is it not working. we are
>> studying and doing some experiments.
>>
>> one more question : In hwtimer_init()--> hwtimer_arch_init() this need
>> to be implemented in harsware is compulsory?? for scheduling to work?
>>
> nope, the timer is generally not needed for scheduling.
>
> Cheers,
> Hauke
>
>
>
>
>>
>> thanks
>> shishir tiwari
>>
>> On Mon, Jan 12, 2015 at 10:01 PM, Hauke Petersen
>>  wrote:
>>
>>> Hi Shishir,
>>>
>>> when RIOT initially starts up, the CPU is normally running in interrupt
>>> mode
>>> (using the interrupt mode stack). After creating the stacks for the main
>>> and
>>> the idle threads, the CPU must be put into thread-mode. This means the
>>> main
>>> threads initial context needs to put into the CPUs registers and the
>>> stack
>>> pointer must put to the main-threads stack. After this is done the CPU
>>> can
>>> just do 'normal' task switching for switching between threads.
>>>
>>> So to put it short: in cpu_switch_context_exit() you simply must load the
>>> main threads context into the CPUs register and point the stack pointer
>>> to
>>> the main threads stack.
>>>
>>> Let me know if you need further information!
>>>
>>> Cheers,
>>> Hauke
>>>
>>>
>>>
>>> On 12.01.2015 15:35, shishir tiwari wrote:
>>>
 Hey Everyone,

 I have been porting RIOT OS to new processor(ARC) and i had compilied
 hello world program successfully.
 When i debug the helloworld.elf in kernel_init function the
 thread_create() function has execute successfully.But the thread
 "idle_thread" "and main_trampoline" function is not been called. why?

 What is thing need to be done on this cpu_switch_context_exit()
 function. please explain me.


 Thanks
 Shishir Tiwari
 ___
 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
>>>
>> ___
>> 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
>
___
devel mailing list
devel@riot-os.org
http://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] MIPS platform (PIC32)

[gnupic]

Hi Adam,

Does RIOT use any memory protected (do not think so since MSP430 and  
PIC do not have any) is it using any hardware specific things ?. I am  
new to RIOT that is why I ask. Is there a good ducument about the  
inner workings of RIOY OS so I can see if there are possible issues  
with MIPS.


Paul.

Adam Hunt  schreef:


Is there anything special about the MIPS march that would make porting RIOT
an issue? Seeing as RIOT runs on 32-bit ARMs, 16-bit MSP430s, x86, and now
even 8-bit Atmels I don't imagine there is much standing in the way of
another incredibly well documented architecture. Though, I've been wrong
before.

On Tue Jan 13 2015 at 5:16:44 AM  wrote:


Hi Oleg,

I do know the MIPS code very good, I am looking for a good e-book or
normal book about the ARM core. The MIPS code is more powerfull per
MHz and also has a better architecture. Its only a pitty that the chip
technology used is less power optimized than most ARM vendors use that
is why the sleep and powerdown are higher.

I think this will change since microchip is busy with XLP for PIC32.

regards, Paul.

Oleg  schreef:

> Hi Paul!
>
>
>> Does anyone know if people are porting RIOT-OS to the MIPS platform
>> and what is the status ?.
>
> As far as I know noone ever tried porting RIOT to MIPS and I know
> too little about this platform to give any estimate about the
> feasibility/difficulty of this task.
>
> Cheers,
> Oleg
> ___
> 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





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

Re: [riot-devel] MIPS platform (PIC32)

[Adam Hunt]

Is there anything special about the MIPS march that would make porting RIOT
an issue? Seeing as RIOT runs on 32-bit ARMs, 16-bit MSP430s, x86, and now
even 8-bit Atmels I don't imagine there is much standing in the way of
another incredibly well documented architecture. Though, I've been wrong
before.

On Tue Jan 13 2015 at 5:16:44 AM  wrote:

> Hi Oleg,
>
> I do know the MIPS code very good, I am looking for a good e-book or
> normal book about the ARM core. The MIPS code is more powerfull per
> MHz and also has a better architecture. Its only a pitty that the chip
> technology used is less power optimized than most ARM vendors use that
> is why the sleep and powerdown are higher.
>
> I think this will change since microchip is busy with XLP for PIC32.
>
> regards, Paul.
>
> Oleg  schreef:
>
> > Hi Paul!
> >
> >
> >> Does anyone know if people are porting RIOT-OS to the MIPS platform
> >> and what is the status ?.
> >
> > As far as I know noone ever tried porting RIOT to MIPS and I know
> > too little about this platform to give any estimate about the
> > feasibility/difficulty of this task.
> >
> > Cheers,
> > Oleg
> > ___
> > 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
>
___
devel mailing list
devel@riot-os.org
http://lists.riot-os.org/mailman/listinfo/devel

[riot-devel] Virtual Meeting tomorrow

[Oleg Hahm]

Dear radical IoTlers,

please recall that the next bi-weekly meeting will happen tomorrow at 10:30 am
CET. Everybody is welcome to join via PlaceCam (free for everybody, please
read [1]). The PlaceCam link will follow tomorrow.

I've set up a pad with a tentative agenda here:
http://riot.pad.spline.de/6

Talk to you tomorrow,
Oleg

[1] https://github.com/RIOT-OS/RIOT/wiki/Instructions-for-remote-participation
-- 
/* Fuck, we are miserable poor guys... */
linux-2.6.6/net/xfrm/xfrm_algo.c


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

Re: [riot-devel] thread is not working

[Hauke Petersen]

Hi,

On 13.01.2015 19:04, shishir tiwari wrote:

Hi petersen,

  Thanks for your information.

we are trying to put your method but still is it not working. we are
studying and doing some experiments.

one more question : In hwtimer_init()--> hwtimer_arch_init() this need
to be implemented in harsware is compulsory?? for scheduling to work?

nope, the timer is generally not needed for scheduling.

Cheers,
Hauke





thanks
shishir tiwari

On Mon, Jan 12, 2015 at 10:01 PM, Hauke Petersen
 wrote:

Hi Shishir,

when RIOT initially starts up, the CPU is normally running in interrupt mode
(using the interrupt mode stack). After creating the stacks for the main and
the idle threads, the CPU must be put into thread-mode. This means the main
threads initial context needs to put into the CPUs registers and the stack
pointer must put to the main-threads stack. After this is done the CPU can
just do 'normal' task switching for switching between threads.

So to put it short: in cpu_switch_context_exit() you simply must load the
main threads context into the CPUs register and point the stack pointer to
the main threads stack.

Let me know if you need further information!

Cheers,
Hauke



On 12.01.2015 15:35, shishir tiwari wrote:

Hey Everyone,

I have been porting RIOT OS to new processor(ARC) and i had compilied
hello world program successfully.
When i debug the helloworld.elf in kernel_init function the
thread_create() function has execute successfully.But the thread
"idle_thread" "and main_trampoline" function is not been called. why?

What is thing need to be done on this cpu_switch_context_exit()
function. please explain me.


Thanks
Shishir Tiwari
___
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

___
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] thread is not working

[shishir tiwari]

Hi petersen,

 Thanks for your information.

we are trying to put your method but still is it not working. we are
studying and doing some experiments.

one more question : In hwtimer_init()--> hwtimer_arch_init() this need
to be implemented in harsware is compulsory?? for scheduling to work?


thanks
shishir tiwari

On Mon, Jan 12, 2015 at 10:01 PM, Hauke Petersen
 wrote:
> Hi Shishir,
>
> when RIOT initially starts up, the CPU is normally running in interrupt mode
> (using the interrupt mode stack). After creating the stacks for the main and
> the idle threads, the CPU must be put into thread-mode. This means the main
> threads initial context needs to put into the CPUs registers and the stack
> pointer must put to the main-threads stack. After this is done the CPU can
> just do 'normal' task switching for switching between threads.
>
> So to put it short: in cpu_switch_context_exit() you simply must load the
> main threads context into the CPUs register and point the stack pointer to
> the main threads stack.
>
> Let me know if you need further information!
>
> Cheers,
> Hauke
>
>
>
> On 12.01.2015 15:35, shishir tiwari wrote:
>>
>> Hey Everyone,
>>
>> I have been porting RIOT OS to new processor(ARC) and i had compilied
>> hello world program successfully.
>> When i debug the helloworld.elf in kernel_init function the
>> thread_create() function has execute successfully.But the thread
>> "idle_thread" "and main_trampoline" function is not been called. why?
>>
>> What is thing need to be done on this cpu_switch_context_exit()
>> function. please explain me.
>>
>>
>> Thanks
>> Shishir Tiwari
>> ___
>> 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
___
devel mailing list
devel@riot-os.org
http://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] MIPS platform (PIC32)

[gnupic]

Hi Oleg,

I do know the MIPS code very good, I am looking for a good e-book or  
normal book about the ARM core. The MIPS code is more powerfull per  
MHz and also has a better architecture. Its only a pitty that the chip  
technology used is less power optimized than most ARM vendors use that  
is why the sleep and powerdown are higher.


I think this will change since microchip is busy with XLP for PIC32.

regards, Paul.

Oleg  schreef:


Hi Paul!



Does anyone know if people are porting RIOT-OS to the MIPS platform 
and what is the status ?.


As far as I know noone ever tried porting RIOT to MIPS and I know  
too little about this platform to give any estimate about the  
feasibility/difficulty of this task.


Cheers,
Oleg
___
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] RFDuino Board -> add to Wiki please (and more)

[Hauke Petersen]

Hi Jan,

On 13.01.2015 11:13, Jan Wagner wrote:

Hi christian,
  
i will create the gfx soon. I also wanted to do some testing about the PIN

nunberig.
  
https://github.com/RIOT-OS/RIOT/blob/master/boards/yunjia-nrf51822/include/periph_conf.h


#define GPIO_0_PIN 7
#define GPIO_1_PIN 8
#define GPIO_2_PIN 9
etc.

I dont get why its starting at 7. i dont own a yunia board.
The rationale for the pin numbering is quite simple: do with it for your 
board whatever you feel like... :-)


We designed the peripheral drivers in a way, that we do a 1-to-1 mapping 
between peripherals and pins, meaning that each pin is mapped to exactly 
one peripheral, so the pin is mapped to one of e.g. SPI or GPIO or UART. 
For the yunjia board I just decided to use pins 7 to 14 for GPIO for no 
hard reason. And as the NRF SoC only has one port, it is enough for this 
platform to just define pins...


So for your board you just change the pin layout to whatever you see fit.

Regarding the LED defines: At least the defines for RED and GREEN must 
be present, but it is completely ok to leave them blank. The rationale 
for the hard-coded LED control defines in RIOT is simply that they are 
often used for timing measurements and for this we try to keep the 
overhead as low as possible. But if a board does not include LEDs and 
you don't plan on using them for profiling/debugging, it is completely 
fine to leave those defines empty.


Let me know if there is anything unclear!

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

Re: [riot-devel] ESP8266 WIFI transceiver

[David Lyon]

On 2015-01-13 21:23, Christian Mehlis wrote:


The software on the chip is just garbage, but it's replaceable.


Definitely.

I like the LuaNodeMCU firmware the most. It's very powerful although
you access all functionality through LUA.


But if you see this board as a external device it can be a cheap wifi
board to connect a RIOT board to the internet. (the RIOT network stack
is not used in this case).


Well it probably could be easily interfaced.

Regards

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

Re: [riot-devel] RFDuino Board -> add to Wiki please (and more)

[Hauke Petersen]

Hi Frank,

good to hear that somebody is following up on the work on the Nordic 
SoCs! To give you a quick overview on the current state of the RIOT support:


- the basic support for the NRFs peripherals is quite good (timers, 
UART, GPIO, rtt, rng), for SPI there is a open PR [1], for PWM [2], I2C 
[3], and ADC [4] support I started some basic work.
- for radio support there is an open PR [5] supporting the radios basic 
functionality and support for the upcoming netdev as well as the 
deprecated transceiver interface (however, the PR is in dire need of 
some rebasing...)
- towards an actual BLE stack there was to my knowledge no code proposed 
to RIOT so far -> anyone taking on this task is very welcome!


Cheers,
Hauke

[1] https://github.com/RIOT-OS/RIOT/pull/2014
[2] https://github.com/haukepetersen/RIOT/tree/add_nrf_pwm
[3] https://github.com/haukepetersen/RIOT/tree/add_nrf_i2c
[4] https://github.com/haukepetersen/RIOT/tree/add_nrf_adc
[5] https://github.com/RIOT-OS/RIOT/pull/2010



On 13.01.2015 08:18, Frank Holtz wrote:

Hello Jan,

https://github.com/RIOT-OS/RIOT/pull/1417/files <<- in general I 
wanted to start the BLE work based on this pull - i sadly got 
closed/merged with silently dropping the "BLE poc" support that a 
least reads like it could work :) Do u know if this code is actualy 
"sending something out" ?



There is another PR to bring radio functionality. I have this not tested.

Aggain Frank thanks for this valuable information. in general I 
just wanted to test ANT, there is a nice tech talk about in ages ago 
but no one uses it(?)...



ANT+ is used for wearables and fitness equipment. There are only a few 
mobile phones supporting ANT+. I think ANT+ is not ready for IoT.


Regards,

Frank
___
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] RFDuino Board -> add to Wiki please (and more)

[Thomas Eichinger]

Hi Jan,

> On 13 Jan 2015, at 11:13, Jan Wagner  wrote:
> 
> https://github.com/RIOT-OS/RIOT/blob/master/boards/yunjia-nrf51822/include/periph_conf.h
> 
> #define GPIO_0_PIN 7
> #define GPIO_1_PIN 8
> #define GPIO_2_PIN 9
> etc.
> 
> I dont get why its starting at 7. i dont own a yunia board.
> 
> (http://forum.rfduino.com/index.php?topic=377.0 - Pin assignment nRF51822 ->
> RFD22301)

I’m not the expert for these nrf MCUs/boards but these mappings work on MCU pin
numbering. So `GPIO_0_PIN` which is MCU’s pin 7 could be mapped to the boards’s
pin with the label “P1.1000” (I’m making these up).
So you’ll need the boards data sheet to get the MCU’s pin connected to which 
board
pin.

Best, Thomas

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

Re: [riot-devel] ESP8266 WIFI transceiver

[Christian Mehlis]

Am 12.01.2015 um 19:38 schrieb Cenk Gündogan:

Hi *,

Does anyone has any experience with this cheap WiFi transceiver (ESP8266)?

May be of interest to some of you, too.

http://www.ebay.de/itm/ESP8266-Serial-WIFI-Wireless-TransceiveR-Module-SPI-Send-Receive-LWIP-Arduino-/171530595640?pt=Wissenschaftliche_Ger%C3%A4te&hash=item27f0052d38


we orderer 20 or something :)

I can bring some of them to the next hack n ack!

It's indeed a very cheap chip with wifi which is actually working with 
wpa2:)


The software on the chip is just garbage, but it's replaceable.
This device needs some more time than I have in my spare time:)

All the interesting components (wifi) are supported with a binary blob, 
so unless someone is willing to reverse engineer it, the potential RIOT 
benefit is a new board with a new cpu architecture.


But if you see this board as a external device it can be a cheap wifi 
board to connect a RIOT board to the internet. (the RIOT network stack 
is not used in this case).


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

Re: [riot-devel] Flashing the Samr21 xpro

[Martin]

Hi,

my flashing speed is roughly equal to Thomas' for the Samr21-xpro:

```
wrote 65536 bytes from file RIOT/tests/pnet/bin/samr21-xpro/pnet.hex in 
32.083557s (1.995 KiB/s)

verified 49688 bytes in 4.114729s (11.793 KiB/s)
```

My openocd version:
`Open On-Chip Debugger 0.9.0-dev-00186-g30203b3 (2014-11-12-11:49)`

Best regards,
Martin
On 12.01.2015 21:07, Baptiste Clenet wrote:

Flashing is slow for us too, how do you get the speed?

2015-01-12 11:13 GMT+01:00 Lucas Jenß >:


Hi Thomas,

verification was much faster as 0.4KiB/s, I think around 10 or so
for me.
I checked out OpenOCD on the 9th. I’m also running Linux inside VMware
though, so maybe it’s just caused by the virtualization. I’ll see
how fast
it is on the host.

Cheers,
Lucas

A couple of days ago.

On 12 Jan 2015, at 11:00, Thomas Eichinger
mailto:thomas.eichin...@fu-berlin.de>> wrote:

> Hi Lucas,
>
> I was playing with the openocd configuration a bit, mainly
> `adapter_speed`, back when support for this was added without
> any significant outcome.
> Problem is, the EDBG chip, on the bottom of the board, handling
> communication with the MCU is specified to run on 1MHz and the
> openocd docs mention, for CMSIS-DAP, it is not advised to let
> signal frequency exceed half of the operating frequency.
> (I’d guess Nyquist-Shannon applies)
>
> That said, 0.481KiB/s still seems slow for this. I’m at least
> reaching 1.787KiB/s for flashing and 11.190KiB/s for verification.
> When did you check out the OpenOCD code?
>
> Best, Thomas
>
>> On 10 Jan 2015, at 14:25, Lucas Jenß mailto:li...@x3ro.de>> wrote:
>>
>> Hey everyone,
>>
>> I’ve been playing around with the Samr21 xpro and flashing
>> the device is _really_ slow, i.e. 0.481 KiB/s. Is this expected
>> or is there a way to improve it? I’m using the current OpenOCD
>> Git HEAD because the 0.8.0 release does not seem to contain the
>> configs for the board yet. I tried to flash the hello-world
>> example.
>>
>> Cheers,
>> Lucas
>> ___
>> 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
>

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




--
/Clenet Baptiste
FR: +33 6 29 73 05 39/
/Élève-Ingénieur ESEO Angers, dernière année, spécialisation: 
Architecte système temps réél embarqué//

/
/Bidiplôme Master Robotics à l'Université de Plymouth en 2013-2014

/


___
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] RFDuino Board -> add to Wiki please (and more)

[Jan Wagner]

Hi christian,
 
i will create the gfx soon. I also wanted to do some testing about the PIN
nunberig.
 
https://github.com/RIOT-OS/RIOT/blob/master/boards/yunjia-nrf51822/include/periph_conf.h

#define GPIO_0_PIN 7
#define GPIO_1_PIN 8
#define GPIO_2_PIN 9
etc.

I dont get why its starting at 7. i dont own a yunia board.

(http://forum.rfduino.com/index.php?topic=377.0 - Pin assignment nRF51822 ->
RFD22301)

Pin Mapping

GPIO 0 = P0.00
GPIO 1 = P0.01
GPIO 2 = P0.02
GPIO 3 = P0.03
GPIO 4 = P0.04
GPIO 5 = P0.05
GPIO 6 = P0.06
Reset = SWDIO
Factory = SWDCLK

ps. i am new to the OS - i first need some experience about code and building
ideas. In my
personal idea - a board that does not have a LED "on board" should not be
'forced' to
include one function def. but thats only my opinion.

regards jan


> Christian Mehlis  hat am 13. Januar 2015 um 10:40
> geschrieben:
>
>
> Am 12.01.2015 um 18:58 schrieb Jan Wagner:
> > hi devs!
> >
> > I recently discovered riot OS. I hope to support the project in my freetime.
> > low
> > power rf sensors will be everywhere
> > around us in the next years. Now the time is perfect to make sure these tiny
> > boards and sensors are running the right
> > open OS - or can be re-flashed to use one.
> >
> > 1 .RFDuino:
> > https://github.com/rfswarm/Board-RFduino/wiki/Board:-RFduino
> > (cpu/nrf51822/startup.c: LED_RED_TOGGLE undeclared -> comment out -> should
> > become ifdef/ifndef)
> > (PIN numbering a little bit strange did not investigate further -> check
> > UART)
> >
> > The wiki text is in general the same as airfy and yunjia. UART, HARDWARE
> > changed.
>
> Great, I'm going to add this to the wiki when you open up a PR with the
> board support.
>
> Please add a picture with the pin mapping of
> 1. cpu pin to
> 2. board pin to
> 3. RIOT name mapping
>
> Don't worry, just copy the e.g. yunjia, change the names and adjust the
> pin mappings to your board.
>
> You can make a diff between yuinija and airfy-beacon to find all places
> where there is board specific code (mostly defines).
>
> Drop a mail when you are ready, I'll review/merge and add the page to
> the wiki.
>
> Best
> Christian
>
> ___
> 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] RFDuino Board -> add to Wiki please (and more)

[Christian Mehlis]

Am 12.01.2015 um 18:58 schrieb Jan Wagner:

hi devs!

I recently discovered riot OS. I hope to support the project in my freetime. low
power rf sensors will be everywhere
around us in the next years. Now the time is perfect to make sure these tiny
boards and sensors are running the right
open OS - or can be re-flashed to use one.

1 .RFDuino:
https://github.com/rfswarm/Board-RFduino/wiki/Board:-RFduino
(cpu/nrf51822/startup.c: LED_RED_TOGGLE undeclared -> comment out -> should
become ifdef/ifndef)
(PIN numbering a little bit strange did not investigate further -> check UART)

The wiki text is in general the same as airfy and yunjia. UART, HARDWARE
  changed.


Great, I'm going to add this to the wiki when you open up a PR with the 
board support.


Please add a picture with the pin mapping of
1. cpu pin to
2. board pin to
3. RIOT name mapping

Don't worry, just copy the e.g. yunjia, change the names and adjust the 
pin mappings to your board.


You can make a diff between yuinija and airfy-beacon to find all places 
where there is board specific code (mostly defines).


Drop a mail when you are ready, I'll review/merge and add the page to 
the wiki.


Best
Christian

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

Re: [riot-devel] RFDuino Board -> add to Wiki please (and more)

[Christian Mehlis]

Am 12.01.2015 um 19:55 schrieb Frank Holtz:

Hello Jan,

i work currently with nRF51 MCU. I have try'd to port RFDuino to plain
nRF51 chips and found this working and more complete project.


 1 .RFDuino:
 https://github.com/rfswarm/Board-RFduino/wiki/Board:-RFduino
 (cpu/nrf51822/startup.c: LED_RED_TOGGLE undeclared -> comment out ->
should become ifdef/ifndef)
 (PIN numbering a little bit strange did not investigate further ->
check UART)


What if LED_RED_TOGGLE is defined empty?


The convention in RIOT with this LED is set to:
1. This define maps to a free and usable LED on the board
	2. In case there is no free and usable LED on the board, define it to a 
GPIO port (you can attach a LED there)
	3. This LED is usable from users code, so for portability of RIOT, 
every platform *must* have this "LED" defined



 3. BLE Stack:
 I am realy pissed about nordic and the "open" rfduino BLE support.
Binary blob myass.
 It might take some weeks but i got all the test hardware ready to
implement basic BLE support.


I'm not interested using BLE at the moment, but i found this:
http://code.google.com/p/btstack/ I think it's an good idea to check if
btstack can be ported to nRF51. This is widely more open than using
these Blobs from Nordic. btstack has ant support.


There are at least two open PRs for the nrf51822:
https://github.com/RIOT-OS/RIOT/pull/2014
https://github.com/RIOT-OS/RIOT/pull/2010

So feel free to test and comment to make this architecture a biger 
success in RIOT:)!


To address the networking support of RIOT via BLE:
1. the new network stack(-architecture) is a generic IPv6/6low stack
2. the primary focus is currently 6low over 15.4
3. it is designed to work with different mac layers
	4. in case you need something else than 6low and IPv6 eg. Zigbee or 
full Bluetooth you need the vendor stack (which can't do 6low, afaik)


Hope this helps you:)

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