Re: [riot-devel] Networking Module does not appear in process list

[malo]

Hello Bernhard,

AFAIK autoinit module is enabled by default, just check if you have defined
-DMODULE_AT86RF2XX, -DMODULE_AUTO_INIT_GNRC_NETIF and
-DMODULE_AUTO_INIT_GNRC_NETIF while compiling.

Im not using default toolchain based on Makefiles so Im not that familiar
with it...

wbr
malo

On 3 March 2016 at 01:14, Bernhard Nägele 
wrote:

> Hello malo,
> the output of ps show at me the same as you have posted it here with the
> exception that there is no at86rfxx. The at86rf2xx driver is compiled - I
> see it there.
> And I have no hint - no error message or something like that why it isn't
> loaded.
> It seem for me, that at86rf2xx_init is not executed - that
> auto_init_at86rf2xx was
> not inivolved in the init-phase. I will check this tomorrow with the
> emulator...
> If so - which action/module invokes the execution of auto_init_at86rf2xx?
> As far
> I have seen this are gnrc-netif modules?
> Thanks a lot,
> Bernhard
>
> ___
> 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] Networking Module does not appear in process list

[Oleg Hahm]

Hi Bernhard!

I think looking at boards/iotlab-m3/Makefile.dep and examples/default/Makefile
may help to understand which modules are necessary. On the one hand you need
either to add a default transceiver to your board configuration, e.g. by
adding something like
 ifneq (,$(filter gnrc_netif_default,$(USEMODULE)))
   USEMODULE += at86rf231
   USEMODULE += gnrc_nomac
 endif
to the board's Makefile.dep, or explicitly add the module (e.g. at86rf231) to
your application Makefile. On the other hand, you need to make sure that you
have the auto_init_gnrc_netif module in your Makefile to automatically
initialize and start the transceiver.

Cheers,
Oleg

On Wed, Mar 02, 2016 at 10:57:50PM +0100, Bernhard Nägele wrote:
> Hello everybody,
> today I tried to get the at86rf2xx working with my board. I have the
> following statement in the board's Makefile:
> 
> ifneq (,$(filter gnrc_netif_default,$(USEMODULE)))
> USEMODULE += at86rf233
> USEMODULE += gnrc_nomac
> endif
> 
> I tried all the networking examples but no example shows the at86rf2xx
> networking module when I list the threads.
> I see all networking threads but not the driver.
> 
> I tried to include (USEMODULE) the Module  in the project makefile and then
> i tried to invoke the auto_init mechanism on serveral places -> no success.
> 
> Can you please tell me what I have to do to load the radio module driver? I
> think it would be a good idea to write down how it should go in a tutorial.
> It's not very nice for newbies to grep through the source code to find out
> how it should work and what might go wrong (it a little bit like beeing
> Sherlock Holmes but without having fun).
> 
> Question 2 - ifconfig:
> ifconfig help
> usage: ifconfig []
> 
> From where do I get the if_id ?
> I think you will get it if you invoke ifconfig without parameters (when you
> have a network module thread running). Is this true?
> 
> Thanks a lot!
> Regards,
> Bernhard
> 
> 
> 
> ___
> devel mailing list
> devel@riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel

-- 
DPRINTK("FAILURE, CAPUT\n");
linux-2.6.6/drivers/net/tokenring/ibmtr.c


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

[riot-devel] auto_init_at86rf2xx - discovering valid devices

[Bernhard Nägele]

Hello everybody,
I have seen in the auto_init_at86rf2xx.c file a loop which tries to find 
valid devices.


The loop-counter is used for discovering spi-busses and also for the 
device descriptor ("i" in the code).
I think this is not a good idea because what happens if you have only 
ONE device sitting
on the SECOND spi-bus? The device will not be found. I think you need 
two counters - one for numbering the spi-bus and one for the device 
descriptor. Do you agree?


//for (unsigned i = 0; i < AT86RF2XX_NUM; i++) {
unsigned i = 1;/* Number of SPI bus */
unsigned k = 0;/* Number device descriptor */
DEBUG("Initializing AT86RF2xx radio at SPI_%i\n", i);
const at86rf2xx_params_t *p = &at86rf2xx_params[k];
int res = at86rf2xx_init(&at86rf2xx_devs[k],
 p->spi,
 p->spi_speed,
 p->cs_pin,
 p->int_pin,
 p->sleep_pin,
 p->reset_pin);

if (res < 0) {
printf("ERROR");
DEBUG("Error initializing AT86RF2xx radio device!\n");
}
else {
gnrc_nomac_init(_nomac_stacks[k],
AT86RF2XX_MAC_STACKSIZE, AT86RF2XX_MAC_PRIO,
"at86rfxx", (gnrc_netdev_t 
*)&at86rf2xx_devs[k]);

}
//}

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

Re: [riot-devel] auto_init_at86rf2xx - discovering valid devices

[Martine Lenders]

Hi Bernhard,
I thik the printf is just wrong. It should be

DEBUG("Initializing AT86RF2xx radio at SPI_%i\n", p->spi);

The SPI bus itself is stored in the parameter descriptor in
at86rf2xx_params.h which is either provided by the board (if it is shipped
with the device) or the application (if it is jacked into some pins of the
device Arduino-like). But the auto-initialization of network devices needs
a bigger overhaul anyways in the near future.

Kind Regards,
Martine


2016-03-03 12:33 GMT+01:00 Bernhard Nägele :

> Hello everybody,
> I have seen in the auto_init_at86rf2xx.c file a loop which tries to find
> valid devices.
>
> The loop-counter is used for discovering spi-busses and also for the
> device descriptor ("i" in the code).
> I think this is not a good idea because what happens if you have only ONE
> device sitting
> on the SECOND spi-bus? The device will not be found. I think you need two
> counters - one for numbering the spi-bus and one for the device descriptor.
> Do you agree?
>
> //for (unsigned i = 0; i < AT86RF2XX_NUM; i++) {
> unsigned i = 1;/* Number of SPI bus */
> unsigned k = 0;/* Number device descriptor */
> DEBUG("Initializing AT86RF2xx radio at SPI_%i\n", i);
> const at86rf2xx_params_t *p = &at86rf2xx_params[k];
> int res = at86rf2xx_init(&at86rf2xx_devs[k],
>  p->spi,
>  p->spi_speed,
>  p->cs_pin,
>  p->int_pin,
>  p->sleep_pin,
>  p->reset_pin);
>
> if (res < 0) {
> printf("ERROR");
> DEBUG("Error initializing AT86RF2xx radio device!\n");
> }
> else {
> gnrc_nomac_init(_nomac_stacks[k],
> AT86RF2XX_MAC_STACKSIZE, AT86RF2XX_MAC_PRIO,
> "at86rfxx", (gnrc_netdev_t
> *)&at86rf2xx_devs[k]);
> }
> //}
>
> Regards,
> Bernhard
> ___
> 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] auto_init_at86rf2xx - discovering valid devices

[Martine Lenders]

Just opened a PR to fix the wrong output:
https://github.com/RIOT-OS/RIOT/pull/4951

2016-03-03 12:41 GMT+01:00 Martine Lenders :

> Hi Bernhard,
> I thik the printf is just wrong. It should be
>
> DEBUG("Initializing AT86RF2xx radio at SPI_%i\n", p->spi);
>
> The SPI bus itself is stored in the parameter descriptor in
> at86rf2xx_params.h which is either provided by the board (if it is shipped
> with the device) or the application (if it is jacked into some pins of the
> device Arduino-like). But the auto-initialization of network devices needs
> a bigger overhaul anyways in the near future.
>
> Kind Regards,
> Martine
>
>
> 2016-03-03 12:33 GMT+01:00 Bernhard Nägele :
>
>> Hello everybody,
>> I have seen in the auto_init_at86rf2xx.c file a loop which tries to find
>> valid devices.
>>
>> The loop-counter is used for discovering spi-busses and also for the
>> device descriptor ("i" in the code).
>> I think this is not a good idea because what happens if you have only ONE
>> device sitting
>> on the SECOND spi-bus? The device will not be found. I think you need two
>> counters - one for numbering the spi-bus and one for the device descriptor.
>> Do you agree?
>>
>> //for (unsigned i = 0; i < AT86RF2XX_NUM; i++) {
>> unsigned i = 1;/* Number of SPI bus */
>> unsigned k = 0;/* Number device descriptor */
>> DEBUG("Initializing AT86RF2xx radio at SPI_%i\n", i);
>> const at86rf2xx_params_t *p = &at86rf2xx_params[k];
>> int res = at86rf2xx_init(&at86rf2xx_devs[k],
>>  p->spi,
>>  p->spi_speed,
>>  p->cs_pin,
>>  p->int_pin,
>>  p->sleep_pin,
>>  p->reset_pin);
>>
>> if (res < 0) {
>> printf("ERROR");
>> DEBUG("Error initializing AT86RF2xx radio device!\n");
>> }
>> else {
>> gnrc_nomac_init(_nomac_stacks[k],
>> AT86RF2XX_MAC_STACKSIZE, AT86RF2XX_MAC_PRIO,
>> "at86rfxx", (gnrc_netdev_t
>> *)&at86rf2xx_devs[k]);
>> }
>> //}
>>
>> Regards,
>> Bernhard
>> ___
>> 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] Port to STM32F7

[Antoine Faure]

Hi everyone,

I am interested in using RTOS with an STM32F746NG Discovery (a board 
with an ARM Cortex M7), but it doesn't seem to be supported yet. Does 
anyone know if someone started working on this ?


Here is a link to the board I'm talking about :
http://www.st.com/web/en/catalog/tools/FM116/SC959/SS1532/LN1848/PF261641?sc=stm32f7-discovery

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

Re: [riot-devel] Port to STM32F7

[Emmanuel Baccelli]

Hi Antoine,

As far as I know, no one has started porting to this board, or to any other
Cortex M7-based board yet.

However, it would be great to have support for this Discovery board (and
initial M7 support).

Are you interested/willing to start porting?

The community usually turns out to be supportive of that type of efforts in
various ways via exchanges on GitHub or discussions on this list or private
exchanges spun out from such discussions.

Cheers

Emmanuel
On Mar 3, 2016 17:52, "Antoine Faure"  wrote:

> Hi everyone,
>
> I am interested in using RTOS with an STM32F746NG Discovery (a board with
> an ARM Cortex M7), but it doesn't seem to be supported yet. Does anyone
> know if someone started working on this ?
>
> Here is a link to the board I'm talking about :
>
> http://www.st.com/web/en/catalog/tools/FM116/SC959/SS1532/LN1848/PF261641?sc=stm32f7-discovery
>
> Thanks,
> Antoine.
> ___
> 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] Documentation: Syntax of the ifconfig command with example

[Bernhard Nägele]

Hello everybody,
today I tried to find out how I can set an IPv6 address for the network 
interface.
In all examples and readme's you can read how to show the settings for 
the network
interface, but I can't find any example how an IP address is set for a 
given interface.
I tried several styles of setting an address and the only thing I got 
was "syntax error".

I took a look to ifconfig in Linux but the syntax here seems different.
Please give me just one example like "ifconfig 7 set addr_long .." 
that works.


Thank you very much!
Best regards,
Bernhard
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] Documentation: Syntax of the ifconfig command with example

[Cenk Gündogan]

Hello Bernhard,

`ifconfig help` will give you a list of sub-commands
and a description of the syntax.

To add an IPv6 address you can write
`ifconfig 6 add abcd::1`
Replace 6 with the desired interface id.

I hope that helps!

Best,
Cenk

On 03.03.2016 18:34, Bernhard Nägele wrote:

Hello everybody,
today I tried to find out how I can set an IPv6 address for the 
network interface.
In all examples and readme's you can read how to show the settings for 
the network
interface, but I can't find any example how an IP address is set for a 
given interface.
I tried several styles of setting an address and the only thing I got 
was "syntax error".

I took a look to ifconfig in Linux but the syntax here seems different.
Please give me just one example like "ifconfig 7 set addr_long .." 
that works.


Thank you very much!
Best regards,
Bernhard
___
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] Documentation: Syntax of the ifconfig command with example

[Bernhard Nägele]

Hello Cenk,
I have found the "ifconfig help" but nevertheless I was doing something 
wrong.
Why not giving just a simple example? I have worked with ifconfig a long 
time

under Linux but not with IPv6.
"ifconfig ..add" worked well - as expected.
Best,
Bernhard
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] Minimal MCU-Core Frequency for using 6LoWPAN Protocol

[Bernhard Nägele]

Hello developers,
what is the best way to find out that a given core-frequency isn't 
sufficient for carrying 6LoWPAN protocol? I guess if the cpu-frequency 
is too low it just won't work no hint from the OS side - is this true?

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

[riot-devel] exhausted Travis

[Cenk Gündogan]

Dear hard-working Developers,

I just wanted to share with you the chart in [1]
with the caption "Active Linux Builds for Open Source Projects (GCE)"

All our current jobs are build on that infrastructure and looking at the 
chart:
travis is pretty flat-lining. It seems that there are more jobs 
available than builders

and there is nothing that we can do about that.

I once tried to move our jobs to the container based infrastructure,
but this requires to remove all "sudo" operations that we currently
have in our travis script.
Unfortunately, certain compilers are not in the default Ubuntu 12.04
repository (or are outdated), therefore we would need to
download/build all compilers by hand. That's the point where I failed.

Do you think it makes sense to invest some time into bringing our jobs
to the container based infrastructure, or should we just wait until we
hit the next great invention (Kaspar (; ) ?

And btw. to clarify things: 1 job is not a pull request in the queue.
We currently have 11 jobs per pull request (: And we still need
to share all those builders with other open source projects.

Best,
Cenk

[1] https://www.traviscistatus.com/
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] exhausted Travis

[Carsten Bormann]

Have you looked at CircleCI?
This seems to be the rage for IETF repos at this point.
(ISTR I couldn't get it to work for my repos, but I probably just didn't
try hard enough.)

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

Re: [riot-devel] exhausted Travis

[Kaspar Schleiser]

Hey,

On 03/03/2016 07:03 PM, Cenk Gündogan wrote:
> should we just wait until we
> hit the next great invention (Kaspar (; ) ?

it's nearly ready...

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

Re: [riot-devel] Port to STM32F7

[DipSwitch]

Awesome!

I'm almost done with most off the non-it stuff (I hope). I have the board
myself as well. So I would like to help in the near feature :)

Kind Regards,
Nick
On 3 Mar 2016 18:32, "Emmanuel Baccelli" 
wrote:

> Hi Antoine,
>
> As far as I know, no one has started porting to this board, or to any
> other Cortex M7-based board yet.
>
> However, it would be great to have support for this Discovery board (and
> initial M7 support).
>
> Are you interested/willing to start porting?
>
> The community usually turns out to be supportive of that type of efforts
> in various ways via exchanges on GitHub or discussions on this list or
> private exchanges spun out from such discussions.
>
> Cheers
>
> Emmanuel
> On Mar 3, 2016 17:52, "Antoine Faure" 
> wrote:
>
>> Hi everyone,
>>
>> I am interested in using RTOS with an STM32F746NG Discovery (a board with
>> an ARM Cortex M7), but it doesn't seem to be supported yet. Does anyone
>> know if someone started working on this ?
>>
>> Here is a link to the board I'm talking about :
>>
>> http://www.st.com/web/en/catalog/tools/FM116/SC959/SS1532/LN1848/PF261641?sc=stm32f7-discovery
>>
>> Thanks,
>> Antoine.
>> ___
>> 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] exhausted Travis

[Martine Lenders]

Am 03.03.2016 21:02 schrieb "Kaspar Schleiser" :
>
> Hey,
>
> On 03/03/2016 07:03 PM, Cenk Gündogan wrote:
> > should we just wait until we
> > hit the next great invention (Kaspar (; ) ?
>
> it's nearly ready...
>
> Kaspar

The KasparCI will be ready soon ;)
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] Port to STM32F7

[Hauke Petersen]

Hi,

this is not quite true, I have started to work on this some time ago 
[1], but don't quite remember were I left of. But maybe this branch 
might give you a head start? Feel free to copy what you need!


Cheers,
Hauke

[1] https://github.com/haukepetersen/RIOT/tree/add_board_stm32f7discovery

On 03.03.2016 18:31, Emmanuel Baccelli wrote:


Hi Antoine,

As far as I know, no one has started porting to this board, or to any 
other Cortex M7-based board yet.


However, it would be great to have support for this Discovery board 
(and initial M7 support).


Are you interested/willing to start porting?

The community usually turns out to be supportive of that type of 
efforts in various ways via exchanges on GitHub or discussions on this 
list or private exchanges spun out from such discussions.


Cheers

Emmanuel

On Mar 3, 2016 17:52, "Antoine Faure" > wrote:


Hi everyone,

I am interested in using RTOS with an STM32F746NG Discovery (a
board with an ARM Cortex M7), but it doesn't seem to be supported
yet. Does anyone know if someone started working on this ?

Here is a link to the board I'm talking about :

http://www.st.com/web/en/catalog/tools/FM116/SC959/SS1532/LN1848/PF261641?sc=stm32f7-discovery

Thanks,
Antoine.
___
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] Port to STM32F7

[Emmanuel Baccelli]

Oops, did not remember that one. Thanks Hauke!
Emmanuel
On Mar 4, 2016 08:49, "Hauke Petersen"  wrote:

> Hi,
>
> this is not quite true, I have started to work on this some time ago [1],
> but don't quite remember were I left of. But maybe this branch might give
> you a head start? Feel free to copy what you need!
>
> Cheers,
> Hauke
>
> [1] https://github.com/haukepetersen/RIOT/tree/add_board_stm32f7discovery
>
> On 03.03.2016 18:31, Emmanuel Baccelli wrote:
>
> Hi Antoine,
>
> As far as I know, no one has started porting to this board, or to any
> other Cortex M7-based board yet.
>
> However, it would be great to have support for this Discovery board (and
> initial M7 support).
>
> Are you interested/willing to start porting?
>
> The community usually turns out to be supportive of that type of efforts
> in various ways via exchanges on GitHub or discussions on this list or
> private exchanges spun out from such discussions.
>
> Cheers
>
> Emmanuel
> On Mar 3, 2016 17:52, "Antoine Faure" 
> wrote:
>
>> Hi everyone,
>>
>> I am interested in using RTOS with an STM32F746NG Discovery (a board with
>> an ARM Cortex M7), but it doesn't seem to be supported yet. Does anyone
>> know if someone started working on this ?
>>
>> Here is a link to the board I'm talking about :
>>
>> http://www.st.com/web/en/catalog/tools/FM116/SC959/SS1532/LN1848/PF261641?sc=stm32f7-discovery
>>
>> Thanks,
>> Antoine.
>> ___
>> devel mailing list
>> devel@riot-os.org
>> https://lists.riot-os.org/mailman/listinfo/devel
>>
>
>
> ___
> devel mailing 
> listdevel@riot-os.orghttps://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