[riot-devel] Count link layer retransmissions for at86rf231

[Oleg Hahm]

Dear IoT developers,

sorry for cross-posting, but since all of these communities are working (at
least partly) with this chip, I want to increase my chances:
The at86rf231 supports automatic link layer retransmissions by setting
MAX_FRAME_RETRIES in XAH_CTRL_0 accordingly. While this is a nice feature, I
wonder if it is possible to figure out how many retransmissions were actually
made (on the sender side).

Cheers,
Oleg
-- 
printk(KERN_WARNING "Warning: defective CD-ROM (volume sequence
number). Enabling \"cruft\" mount option.\n");
linux-2.2.16/fs/isofs/inode.c


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

Re: [riot-devel] NSTF - Naming the stack

[Francesco Ermini]

Hi,
If it can help brainstorming, "non-specific"  is a synonym for generic e.g
 ns_ as "non-specific network stack".

2015-05-18 19:44 GMT+02:00 Kaspar Schleiser :

> Hey,
>
> On 05/18/15 16:17, Oleg Hahm wrote:
> >> +1 for "generic", but do we need the abbrevation?
> >
> > Aren't you usually the one arguing for short variable names and the like?
> Yes, but "gnrc"... ;)
>
> gns (generic network stack), gn, gnet, gen, g, ... ?
>
> Kaspar
> ___
> devel mailing list
> devel@riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel
>



-- 
Francesco Ermini
Via Abebe Bikila, 8 50012 (FI)
cell. 3338710609
tell. 055642820
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] NSTF - Naming the stack

[Kaspar Schleiser]

Hey,

On 05/18/15 16:17, Oleg Hahm wrote:
>> +1 for "generic", but do we need the abbrevation?
> 
> Aren't you usually the one arguing for short variable names and the like?
Yes, but "gnrc"... ;)

gns (generic network stack), gn, gnet, gen, g, ... ?

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

Re: [riot-devel] NSTF - Naming the stack

[Hauke Petersen]

Hi,

I also can live very well with gnrc aka generic.

Cheers,
Hauke

P.S. +1 for 'Google never really called' :-)


On 18.05.2015 17:56, Martine Lenders wrote:

Hi,
given that I was asked today what the "R" means in RIOT (and Thomas W. 
giving the most excellent to my "revelutionary" or "restricted": 
"RIOT") I really like gnrc. Let's find some alternative meanings for 
that! :D "Generic newly retained code"? "Great networking! RIOT 
certified"? "Google never really called [us]"?


Cheers,
Martine

2015-05-18 16:17 GMT+02:00 Oleg Hahm >:


Hey Kaspar!

> +1 for "generic", but do we need the abbrevation?

Aren't you usually the one arguing for short variable names and
the like?

Cheers,
Oleg
--
WHO HAS ANY ARP JOKES?

___
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] NSTF - Naming the stack

[Martine Lenders]

Hi,
given that I was asked today what the "R" means in RIOT (and Thomas W.
giving the most excellent to my "revelutionary" or "restricted": "RIOT") I
really like gnrc. Let's find some alternative meanings for that! :D
"Generic newly retained code"? "Great networking! RIOT certified"? "Google
never really called [us]"?

Cheers,
Martine

2015-05-18 16:17 GMT+02:00 Oleg Hahm :

> Hey Kaspar!
>
> > +1 for "generic", but do we need the abbrevation?
>
> Aren't you usually the one arguing for short variable names and the like?
>
> Cheers,
> Oleg
> --
> WHO HAS ANY ARP JOKES?
>
> ___
> 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] NSTF - Naming the stack

[Oleg Hahm]

Hey Kaspar!

> +1 for "generic", but do we need the abbrevation?

Aren't you usually the one arguing for short variable names and the like?

Cheers,
Oleg
-- 
WHO HAS ANY ARP JOKES?


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

Re: [riot-devel] NSTF - Naming the stack

[Kaspar Schleiser]

+1 for "generic", but do we need the abbrevation?

On 05/18/15 15:55, Emmanuel Baccelli wrote:
> Hi everyone,
> 
> concerning the name of the new network stack, and assuming it is not
> going to be the only network stack that RIOT hosts, here's a suggestion.
> 
> The way I see it, the goal of this network stack was/is to be generic [1]:
> - one-size-fits-most
> - flexible/configurable/extendable 
> 
> In contrast, other stacks that RIOT supports (or is about to support)
> have more specific goals, e.g.
> - OpenWSN stack (focus on 802.15.4e and 6TiSCH)
> - Kaspar's IP stack focusing on fitting the memory constraints of Class
> 0 devices
> - CCN-lite stack focusing on NDN and CCN
> 
> So how about we simply name the new network stack "the generic stack"
> and, where needed in the code, we could abbreviate the word "generic" by
> eliding the vowels from the word, which then becomes the acronym/prefix
> "gnrc". 
> 
> Somehow, we can convene that "gnrc" could/can be pronounced almost like
> the original word "generic".
> 
> Cheers,
> 
> Emmanuel 
> 
> 
> [1] Word definition from Webster dictionary:
> Generic: Very comprehensive; pertaining or appropriate to large classes
> or their characteristics; -- opposed to specific. 
> http://www.dict.org/bin/Dict?Form=Dict2&Database=*&Query=generic
> 
> On Wed, May 13, 2015 at 7:28 AM, Oleg Hahm  > wrote:
> 
> Hi Ludwig!
> 
> > Isn't ccn-lite using the lower layer(s) (MAC, LLC, driver - correct me 
> if
> > I'm wrong) of the old stack and should be upgraded to use the lower 
> layer(s)
> > of the new stack? (What about OpenWSN?) Or are those layers not 
> considered
> > part of the stack?
> 
> Yes, you're right, ccn-lite can run directly on top of Link Layer (and
> actually more or less any other layer) and should be upgraded.
> 
> OpenWSN provides a full network stack from Link to Application Layer.
> 
> > >I think we cannot compare to Linux,
> > >BSD, and
> > >the like here. They can afford to make different modules somehow
> > >interoperable
> > >at cost of memory, we cannot.
> >
> > As far as I remember, the modularization of the new stack had exactly 
> this
> > as a goal.
> 
> Yes, that's correct. However, there will - as Kaspar pointed out -
> still exist
> other stack implementations. Actually, this might be another reason
> for a
> name: if one implements a new module for this stack, one should
> indicate that
> it is compatible to stack XYZ.
> 
> Cheers,
> Oleg
> 
> --
> panic("This never returns");
> linux-2.6.6/kernel/power/swsusp.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

Re: [riot-devel] NSTF - Naming the stack

[Emmanuel Baccelli]

Hi everyone,

concerning the name of the new network stack, and assuming it is not going
to be the only network stack that RIOT hosts, here's a suggestion.

The way I see it, the goal of this network stack was/is to be generic [1]:
- one-size-fits-most
- flexible/configurable/extendable

In contrast, other stacks that RIOT supports (or is about to support) have
more specific goals, e.g.
- OpenWSN stack (focus on 802.15.4e and 6TiSCH)
- Kaspar's IP stack focusing on fitting the memory constraints of Class 0
devices
- CCN-lite stack focusing on NDN and CCN

So how about we simply name the new network stack "the generic stack" and,
where needed in the code, we could abbreviate the word "generic" by eliding
the vowels from the word, which then becomes the acronym/prefix "gnrc".

Somehow, we can convene that "gnrc" could/can be pronounced almost like the
original word "generic".

Cheers,

Emmanuel


[1] Word definition from Webster dictionary:
Generic: Very comprehensive; pertaining or appropriate to large classes or
their characteristics; -- opposed to specific.
http://www.dict.org/bin/Dict?Form=Dict2&Database=*&Query=generic

On Wed, May 13, 2015 at 7:28 AM, Oleg Hahm  wrote:

> Hi Ludwig!
>
> > Isn't ccn-lite using the lower layer(s) (MAC, LLC, driver - correct me if
> > I'm wrong) of the old stack and should be upgraded to use the lower
> layer(s)
> > of the new stack? (What about OpenWSN?) Or are those layers not
> considered
> > part of the stack?
>
> Yes, you're right, ccn-lite can run directly on top of Link Layer (and
> actually more or less any other layer) and should be upgraded.
>
> OpenWSN provides a full network stack from Link to Application Layer.
>
> > >I think we cannot compare to Linux,
> > >BSD, and
> > >the like here. They can afford to make different modules somehow
> > >interoperable
> > >at cost of memory, we cannot.
> >
> > As far as I remember, the modularization of the new stack had exactly
> this
> > as a goal.
>
> Yes, that's correct. However, there will - as Kaspar pointed out - still
> exist
> other stack implementations. Actually, this might be another reason for a
> name: if one implements a new module for this stack, one should indicate
> that
> it is compatible to stack XYZ.
>
> Cheers,
> Oleg
>
> --
> panic("This never returns");
> linux-2.6.6/kernel/power/swsusp.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

Re: [riot-devel] Support for Stellaris Launchpad LM4F120 board.

[rakendra thapa]

Thank you for feedbacks.
Okay, so that is quite a minimal set of Newlib functionality being used.
Even my application wont be requiring more than these but only memset.

Kaspar,
 - Can you please share the branch with me you working on regarding the
library.

- Also, for testing purposes, you might will have to configure some tools
to get it working with Stellaris Launchpad. Its pretty straightforward.
Also, we need to build OpenOCD with ICDI support to flash and debug
launchpad. You might take a look into the link.
http://processors.wiki.ti.com/index.php/Stellaris_Launchpad_with_OpenOCD_and_Linux

- We have pending discussion regarding using StellarisWare lib or not.
Once, we are done, I will commit StellarisWare on a separate PR.

Thanks and Regards,
Rakendra

On Mon, May 18, 2015 at 1:45 PM, Oleg Hahm  wrote:

> Hi Rakendra!
>
> Welcome aboard!
>
> > I have ported RIOT-OS to Stellaris Launchpad Evaluation board. This is
> just
> > a basic port with only ADC, TIMER and UART modules currently supported. I
> > have done basic sanity test on the board and it seems running fine.
>
> Can you maybe split up the PR in commits so that the import of TI files is
> separated in one commit? Otherwise it's literally impossible to review your
> code (at least on Github).
>
> Cheers,
> Oleg
> --
> fs_dprintk (FS_DEBUG_INIT, "Ha! Initialized OK!\n");
> linux-2.6.6/drivers/atm/firestream.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

Re: [riot-devel] Support for Stellaris Launchpad LM4F120 board.

[Oleg Hahm]

Hi Rakendra!

Welcome aboard!

> I have ported RIOT-OS to Stellaris Launchpad Evaluation board. This is just
> a basic port with only ADC, TIMER and UART modules currently supported. I
> have done basic sanity test on the board and it seems running fine.

Can you maybe split up the PR in commits so that the import of TI files is
separated in one commit? Otherwise it's literally impossible to review your
code (at least on Github).

Cheers,
Oleg
-- 
fs_dprintk (FS_DEBUG_INIT, "Ha! Initialized OK!\n");
linux-2.6.6/drivers/atm/firestream.c


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

Re: [riot-devel] Support for Stellaris Launchpad LM4F120 board.

[Oleg Hahm]

Hi!

> > Also, can someone help me with list of functions RIOT is actually using
> > from Newlib. ?
> The RIOT core itself mainly uses printf for debugging. If you disable
> that (or provide your own minimal version of printf), it should compile
> without any C library.
> 
> Apart from that, some modules use the string functions (strcmp, strtok),
> memcpy, memmove, memset, malloc, printf/sprintf, ...
> 
> Really depends on the used modules and application.

You could add -nostdlib to the LINKFLAGS and compile, e.g. hello-world to see
what is missing withoug Newlib. For some boards (most of the ARM Cortex-M
boards) you'll have to comment out this line:

 export LINKFLAGS += -specs=nano.specs -lc -lnosys

in boards/${BOARD}/Makefile.include.

Core and cpu itself reveals requirements for:
 * __libc_init_array
 * printf
 * strncpy
 * puts
 * memcpy

Cheers,
Oleg
-- 
If no space is available nothing happens.
RIOT/sys/net/include/pktbuf.h


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

Re: [riot-devel] Support for Stellaris Launchpad LM4F120 board.

[Kaspar Schleiser]

Hi,

On 05/18/15 04:23, rakendra thapa wrote:
> I have ported RIOT-OS to Stellaris Launchpad Evaluation board.
Nice! I've got some of these lying around, will review soon.

> Meanwhile, I had a separate query from the fellow developers.
> I was also working on porting RIOT-OS to a 8-bit PIC18F uC for one of my
> application. Newlib library is too fat for it and I have decided to
> discard it. 
I've got a branch for integrating musl somewhere, but that is just a
little smaller than newlib.

> Also, can someone help me with list of functions RIOT is actually using
> from Newlib. ?
The RIOT core itself mainly uses printf for debugging. If you disable
that (or provide your own minimal version of printf), it should compile
without any C library.

Apart from that, some modules use the string functions (strcmp, strtok),
memcpy, memmove, memset, malloc, printf/sprintf, ...

Really depends on the used modules and application.

Kaspar


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