Re: [riot-devel] LoRa support

[Anon Anonymous]

Hello Jose,

Glad to hear that anything works! :)
Looking forward for further cooperation on that! Keep in touch.

Best regards,
Cr0s

2016-10-27 21:28 GMT+03:00 Jose Alamos :

> Hello cr0s,
>
> Thank you for the information. I just noticed Emmanuel asked about the
> same thing a couple of days ago. Great to hear that! :)
>
> We just did some test on the PR and it's working OK for us.
>
> We are really interested in the development of the netdev2 adoption for
> the SX1276 driver.  We will let you know how it goes.
>
> Cheers!
>
> ___
> 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] bitfeilds

[Neil Jones]

Ok so they are not outright banned but not recommended unless you can prove
there are not any code size penalties?
I'm now very interested in testing this on MIPS and will be querying our
compiler engineers if there is a difference. I wonder if the fact that
volatile acts as a compiler memory barrier that the compiled code is larger?

Neil

On 27 Oct 2016 14:11, "Hauke Petersen"  wrote:

> Sorry, saw Olegs mail only after I send mine...
>
> Cheers,
> Hauke
>
> On 27.10.2016 15:06, Martine Lenders wrote:
>
>> Hi,
>>
>> 2016-10-27 15:01 GMT+02:00 Oleg Hahm > oliver.h...@inria.fr>>:
>>
>> Hi Martine!
>>
>> On Thu, Oct 27, 2016 at 01:35:21PM +0200, Martine Lenders wrote:
>> > >> As example I was able to save several 100 bytes of ROM when
>> removing the
>> > >> named bitfield use from the samr21s peripheral drivers.
>> > >
>> > >
>> > I don't know about your specific code, but I was able to show,
>> that a
>> > bitfield actually *saves* ROM [1].
>>
>> In your example the variables were not volatile.
>>
>>
>> Right. That might be a factor ^^".
>>
>> Cheers,
>> Martine
>>
>>
>> ___
>> 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] LoRa support

[Jose Alamos]

Hello cr0s,

Thank you for the information. I just noticed Emmanuel asked about the same
thing a couple of days ago. Great to hear that! :)

We just did some test on the PR and it's working OK for us.

We are really interested in the development of the netdev2 adoption for the
SX1276 driver.  We will let you know how it goes.

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

Re: [riot-devel] openthread and riot - license issues?

[Kaspar Schleiser]

Hey,

On 10/27/2016 03:07 PM, MATTIA ANTONINI wrote:
> Any news on this topic?

Yes, FSF answered:

"
> Specifically, can we use Apache 2.0 licensed "packages" this way?

When someone who isn't the copyright holder of RIOT OS wants to further
distribute your work, they can only do so under the terms you have
specified. In this case the terms of LGPLv2.1.

If a third party wants to distribute a work which used your build system
(or any other system for that matter) to create a statically linked work
which includes RIOT OS and software licensed under the terms of the the
Apache 2.0 license, the terms of LGPLv2.1 (section 6.a) require that
third party to also provide the Apache 2.0 licensed work in an object
(not necessarily source) format which would allow the recipients to
relink against a modified version of RIOT OS.

Also see: http://www.gnu.org/licenses/gpl-faq.html#LGPLStaticVsDynamic
"

I tried to clarify whether source is sufficient:

"
> "not necessarily source" means that if source is available (as would be
> the case for AL2.0 code), that is sufficient, correct?

Section 6.a of LGPLv2.1 requires that if someone distributes an
executable linked with the library, that they actually accompany that
executable with the object or source code which would enable re-linking:

"""... Accompany the work with the complete corresponding
machine-readable source code for the Library... and, if the work is an
executable linked with the Library, with the complete machine-readable
"work that uses the Library", as object code and/or source code ..."""
"

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

Re: [riot-devel] bitfeilds

[Hauke Petersen]

Sorry, saw Olegs mail only after I send mine...

Cheers,
Hauke

On 27.10.2016 15:06, Martine Lenders wrote:

Hi,

2016-10-27 15:01 GMT+02:00 Oleg Hahm >:


Hi Martine!

On Thu, Oct 27, 2016 at 01:35:21PM +0200, Martine Lenders wrote:
> >> As example I was able to save several 100 bytes of ROM when
removing the
> >> named bitfield use from the samr21s peripheral drivers.
> >
> >
> I don't know about your specific code, but I was able to show,
that a
> bitfield actually *saves* ROM [1].

In your example the variables were not volatile.


Right. That might be a factor ^^".

Cheers,
Martine


___
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] bitfeilds

[Hauke Petersen]

Hi,

Marinte's example does not use `volatile` fields, this makes it in my 
experience even worse...


Anyhow, it still shows, that on Cortex based platforms, the manual 
approach is superior in terms of ROM usage (which fits with my 
experiences). So especially for register maps (which are completely tied 
not only to a platform but to a specific CPU) I see a negative effect 
from using named bitfields.


 @Neil: yes, I am suggesting (also backed by Martine's example) that 
compiler generated code for accessing the bitfeilds is less size 
efficient on Cortex-Mx based platforms. But please feel free to prove me 
wrong!


Cheers,
Hauke


On 27.10.2016 13:35, Martine Lenders wrote:

Hi,
because this discussion came up in one of my (higher level) PRs, too.

2016-10-27 12:33 GMT+02:00 Neil Jones >:


are you suggesting the compiler generated code for accessing the
bitfeilds is less size efficient than doing it manually? I would
be suprised if that was the case ?


On 27 Oct 2016 08:05, "Hauke Petersen"
mailto:hauke.peter...@fu-berlin.de>>
wrote:

Hi Neil, hi Kees,

though named bitfields are kind of nice when it comes to code
readability, they behave very poorly when it comes to code
size. This is especially true for register maps, as these are
typically volatile. For this reason, we don't use them in RIOT
and I strongly advice not to use those.

As example I was able to save several 100 bytes of ROM when
removing the named bitfield use from the samr21s peripheral
drivers.


I don't know about your specific code, but I was able to show, that a 
bitfield actually *saves* ROM [1].


Cheers,
Martine

[1] https://github.com/RIOT-OS/RIOT/pull/5866#issuecomment-249801576


___
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] openthread and riot - license issues?

[MATTIA ANTONINI]

Hi All,
Any news on this topic?

Cheers,
Mattia

2016-10-24 12:15 GMT+02:00 Kaspar Schleiser :

> Hi,
>
> On 10/24/2016 10:59 AM, Martine Lenders wrote:
> > "WHICH LICENSES MAY NOT BE INCLUDED WITHIN APACHE PRODUCTS?"
> >
> > from [0]. But RIOT is not an "APACHE PRODUCT"... , :-)
>
> > Well we do it the other way around, we include (in this instant I mean
> > linking) a non-LGPL product within a LGPL product. The code itself isn't
> > even included, but downloaded from source. AFAIK this is fine*.
>
> I think what Alexander wants to point out is that above statement can be
> misread as "Apache 2.0 and LGPLv2.1 are incompatible from Apache's
> perspective.
>
> Here [1] is an interesting thread which should clarify the issue.
> In essence, the Apache foundation has a *policy* that *Apache foundation
> projects* may not use mandatory LGPL'ed components, in order for
> downstream users to not have to deal with LGPL's requirements.
>
> That does not mean that the Apache License 2.0 ("AL 2.0") is
> incompatible with LGPLv2.1.
>
> I've contacted the FSF (again) to clarify our specific "AL 2.0 package"
> problem, and I'm waiting for them to answer. But currently I read the
> licenses as follows:
>
> 1. LGPLv2.1 does not consider a released binary as derivative work if
> the LGPL'ed code is only linked to non-LGPL'ed code, and the distributor
> of that combined work distributes the means necessary to replace and/or
> debug the LGPL'ed part. As packages are available as source, this
> constraint is satisfied, thus from the LGPLv2.1 perspective using AL 2.0
> packages is fine.
>
> 2. AL 2.0 has a linking exception: "For the purposes of this License,
> Derivative Works shall not include works that remain separable from, or
> merely link (or bind by name) to the interfaces of, the Work and
> Derivative Works thereof." Thus using an AL 2.0 as package is fine.
>
> Kaspar
>
> [1] https://issues.apache.org/jira/browse/LEGAL-192
> ___
> 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] bitfeilds

[Martine Lenders]

Hi,

2016-10-27 15:01 GMT+02:00 Oleg Hahm :

> Hi Martine!
>
> On Thu, Oct 27, 2016 at 01:35:21PM +0200, Martine Lenders wrote:
> > >> As example I was able to save several 100 bytes of ROM when removing
> the
> > >> named bitfield use from the samr21s peripheral drivers.
> > >
> > >
> > I don't know about your specific code, but I was able to show, that a
> > bitfield actually *saves* ROM [1].
>
> In your example the variables were not volatile.
>

Right. That might be a factor ^^".

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

Re: [riot-devel] bitfeilds

[Oleg Hahm]

Hi Martine!

On Thu, Oct 27, 2016 at 01:35:21PM +0200, Martine Lenders wrote:
> >> As example I was able to save several 100 bytes of ROM when removing the
> >> named bitfield use from the samr21s peripheral drivers.
> >
> >
> I don't know about your specific code, but I was able to show, that a
> bitfield actually *saves* ROM [1].

In your example the variables were not volatile.

Cheers,
Oleg
-- 
printk("Illegal format on cdrom.  Pester manufacturer.\n"); 
linux-2.2.16/fs/isofs/inode.c


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

Re: [riot-devel] bitfeilds

[Martine Lenders]

(okay it's not the case for MSP430 e.g.)

2016-10-27 13:35 GMT+02:00 Martine Lenders :

> Hi,
> because this discussion came up in one of my (higher level) PRs, too.
>
> 2016-10-27 12:33 GMT+02:00 Neil Jones :
>
>> are you suggesting the compiler generated code for accessing the
>> bitfeilds is less size efficient than doing it manually? I would be
>> suprised if that was the case ?
>>
>> On 27 Oct 2016 08:05, "Hauke Petersen" 
>> wrote:
>>
>>> Hi Neil, hi Kees,
>>>
>>> though named bitfields are kind of nice when it comes to code
>>> readability, they behave very poorly when it comes to code size. This is
>>> especially true for register maps, as these are typically volatile. For
>>> this reason, we don't use them in RIOT and I strongly advice not to use
>>> those.
>>>
>>> As example I was able to save several 100 bytes of ROM when removing the
>>> named bitfield use from the samr21s peripheral drivers.
>>
>>
> I don't know about your specific code, but I was able to show, that a
> bitfield actually *saves* ROM [1].
>
> Cheers,
> Martine
>
> [1] https://github.com/RIOT-OS/RIOT/pull/5866#issuecomment-249801576
>
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] bitfeilds

[Martine Lenders]

Hi,
because this discussion came up in one of my (higher level) PRs, too.

2016-10-27 12:33 GMT+02:00 Neil Jones :

> are you suggesting the compiler generated code for accessing the bitfeilds
> is less size efficient than doing it manually? I would be suprised if that
> was the case ?
>
> On 27 Oct 2016 08:05, "Hauke Petersen" 
> wrote:
>
>> Hi Neil, hi Kees,
>>
>> though named bitfields are kind of nice when it comes to code
>> readability, they behave very poorly when it comes to code size. This is
>> especially true for register maps, as these are typically volatile. For
>> this reason, we don't use them in RIOT and I strongly advice not to use
>> those.
>>
>> As example I was able to save several 100 bytes of ROM when removing the
>> named bitfield use from the samr21s peripheral drivers.
>
>
I don't know about your specific code, but I was able to show, that a
bitfield actually *saves* ROM [1].

Cheers,
Martine

[1] https://github.com/RIOT-OS/RIOT/pull/5866#issuecomment-249801576
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] bitfeilds

[Neil Jones]

are you suggesting the compiler generated code for accessing the bitfeilds
is less size efficient than doing it manually? I would be suprised if that
was the case ?

On 27 Oct 2016 08:05, "Hauke Petersen"  wrote:

> Hi Neil, hi Kees,
>
> though named bitfields are kind of nice when it comes to code readability,
> they behave very poorly when it comes to code size. This is especially true
> for register maps, as these are typically volatile. For this reason, we
> don't use them in RIOT and I strongly advice not to use those.
>
> As example I was able to save several 100 bytes of ROM when removing the
> named bitfield use from the samr21s peripheral drivers.
>
> Cheers,
> Hauke
>
>
>
> On 26.10.2016 21:24, Kees Bakker wrote:
>
>> On 26-10-16 16:52, Neil Jones wrote:
>>
>>> Hi,
>>>
>>> What is RIOT's position on using named bitfields for register
>>> definitions ? I know they are frown upon as there are no endian
>>> guarantees in the C standard, personally I don't use them, but the PIC32
>>> device files supplied by Microchip do include bitfield structures for
>>> most registers so could make life easier ? (thankfully there are #define
>>> for most register fields too, if the answer is not to use them).
>>>
>>
>> I can't speak for RIOT, but personally I don't have a problem with them
>> when they are used for register definitions.
>>
>> And I know that SAMD21 uses them too in Atmel's CMSIS include files.
>>
>> In many cases it makes the code much nicer. That doesn't mean the
>> SAMD21 already uses them a lot. For example, we currently have code
>> like
>>
>> dev(bus)->CTRLA.reg |= SERCOM_SPI_CTRLA_SWRST;
>> while ((dev(bus)->CTRLA.reg & SERCOM_SPI_CTRLA_SWRST) ||
>>(dev(bus)->SYNCBUSY.reg & SERCOM_SPI_SYNCBUSY_SWRST));
>> ...
>> while (!(dev(bus)->INTFLAG.reg & SERCOM_SPI_INTFLAG_DRE)) {}
>> ...
>> dev(bus)->CTRLA.reg &= ~(SERCOM_SPI_CTRLA_ENABLE);
>>
>>
>> which could use bitfields and be written like this
>>
>> dev(bus)->CTRLA.bit.SWRST = 1;
>> while ((dev(bus)->CTRLA.bit.SWRST) ||
>>(dev(bus)->SYNCBUSY.bit.SWRST)) {}
>> ...
>> while (!(dev(bus)->INTFLAG.bit.DRE)) {}
>> ...
>> dev(bus)->CTRLA.bit.ENABLE = 0;
>>
>>
> ___
> 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] bitfeilds

[Hauke Petersen]

Hi Neil, hi Kees,

though named bitfields are kind of nice when it comes to code 
readability, they behave very poorly when it comes to code size. This is 
especially true for register maps, as these are typically volatile. For 
this reason, we don't use them in RIOT and I strongly advice not to use 
those.


As example I was able to save several 100 bytes of ROM when removing the 
named bitfield use from the samr21s peripheral drivers.


Cheers,
Hauke



On 26.10.2016 21:24, Kees Bakker wrote:

On 26-10-16 16:52, Neil Jones wrote:

Hi,

What is RIOT's position on using named bitfields for register
definitions ? I know they are frown upon as there are no endian
guarantees in the C standard, personally I don't use them, but the PIC32
device files supplied by Microchip do include bitfield structures for
most registers so could make life easier ? (thankfully there are #define
for most register fields too, if the answer is not to use them).


I can't speak for RIOT, but personally I don't have a problem with them
when they are used for register definitions.

And I know that SAMD21 uses them too in Atmel's CMSIS include files.

In many cases it makes the code much nicer. That doesn't mean the
SAMD21 already uses them a lot. For example, we currently have code
like

dev(bus)->CTRLA.reg |= SERCOM_SPI_CTRLA_SWRST;
while ((dev(bus)->CTRLA.reg & SERCOM_SPI_CTRLA_SWRST) ||
   (dev(bus)->SYNCBUSY.reg & SERCOM_SPI_SYNCBUSY_SWRST));
...
while (!(dev(bus)->INTFLAG.reg & SERCOM_SPI_INTFLAG_DRE)) {}
...
dev(bus)->CTRLA.reg &= ~(SERCOM_SPI_CTRLA_ENABLE);


which could use bitfields and be written like this

dev(bus)->CTRLA.bit.SWRST = 1;
while ((dev(bus)->CTRLA.bit.SWRST) ||
   (dev(bus)->SYNCBUSY.bit.SWRST)) {}
...
while (!(dev(bus)->INTFLAG.bit.DRE)) {}
...
dev(bus)->CTRLA.bit.ENABLE = 0;



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