Re: [RFC] Mesh uses multi advertising instances.

[Aditya Xavier]

Hi Łukasz,

Any pointers, as to what needs to be implemented from the blemesh_shell app ?


Thanks,
Aditya Xavier.

> On 02-Apr-2018, at 11:34 PM, Łukasz Rymanowski 
>  wrote:
> 
> Second thought
> 
> Aditya,
> Since I did not test it a lot, would it be possible to give us feedback how
> it works for you?
> 
> Best
> Lukasz
> 
> 
> 
> 
> On Mon, Apr 2, 2018, 20:01 Łukasz Rymanowski 
> wrote:
> 
>> Hi Aditya.
>> 
>> On Mon, Apr 2, 2018, 19:14 Aditya Xavier  wrote:
>> 
>>> Hi Łukasz,
>>> 
>>> Is there anything special required to get this working along with BLE ?
>> 
>> 
>>> For e.g. would the btshell app code for ADV_EXT work along with mesh with
>>> the provided patches ?
>>> 
>> 
>> In addition to configuration mentioned in PR commit message, the btshell
>> app would have to enable ble mesh and ble mesh shell (check blemesh_shell
>> app for that)
>> 
>>> 
>>> Mesh and BLE seems to compile however, am currently unable to get Mesh
>>> working.
>>> 
>>> Also, any reason why this was not accepted yet ?
>>> 
>> 
>> People are busy with other stuff I guess. I think it will be merged
>> eventually.
>> 
>>> 
>>> 
>>> 
>>> Thanks,
>>> Aditya Xavier.
>>> 
>> 
>> Best
>> Lukasz
>> 
>> 
>>> 
 On 20-Mar-2018, at 12:57 AM, Sterling Hughes <
>>> sterling.hughes.pub...@gmail.com> wrote:
 
 +1 - this is great, thanks Lukasz!
 
 On 19 Mar 2018, at 6:36, Łukasz Rymanowski wrote:
 
> Hi All,
> 
> I saw people asking around about possibility to advertise with non-mesh
> data while mesh is running on Mynewt.  Well this is possible to do but
>>> of
> course it brings a lot of risk for mesh operations and especially for
> friendship scenario. However I went ahead and added support for this in
> Mynewt and I'm interested in how it works for you.
> 
> So here is a PR which makes use of multi instances from BT5 Advertising
> extensions and basically allows you to create additional instances
>>> which
> contains non-mesh data.
> 
> https://github.com/apache/mynewt-nimble/pull/8
> 
> Instructions on how to enable it you can find in the commit message.
> 
> Comments are welcome
> 
> Best
> Łukasz
>>> 
>>> 

Re: os data.core memory section

[markus]

Hey Will,

thanks for the background - much appreciated.

I did indeed need the additional memory to store a time series
generated at high frequencies, so offloading wasn't an option. I solved
it by storing some of the time series in CCM memory, which is probably
the better solution anyway.

Given the constraints around CCM and DTCM, it might actually be better
if the OS doesn't use it. I guess I got confused, misled by the "core"
in the section name, which in retrospect probably applies to the MCU and
not the OS.

Thanks for all the input,
Markus

On Mon, 2 Apr 2018 10:54:32 -0700
will sanfilippo  wrote:

> Markus:
> 
> I presume you are referring to these definitions:
> 
> #define sec_data_core   __attribute__((section(".data.core")))
> #define sec_bss_core__attribute__((section(".bss.core")))
> #define sec_bss_nz_core __attribute__((section(".bss.core.nz")))
> 
> As far as I know there is no real magic here but I am sure there is
> some degree of inconsistency.
> 
> The reason sec_bss_nz_core was added was to get around a HW problem
> with early nordic chips (you can see the reference in nrf52.ld) so I
> do not doubt that this is no longer used. Personally, I think the
> idea of having a “non-zeroed .bss” is pretty cool. I guess one could
> simply call that the heap but sometimes you just like allocating a
> global variable and not allocating it from the heap. I realize that
> the only real reason to do this is save time in the startup code
> zeroing out memory (but still; that is cool!) :-) Not quite sure why
> “core” was added to that defintion. Maybe because there was some
> conflict with naming it bss.nz?
> 
> I should probably look at the STM startup code to be sure of this but
> I presume they use sec_data_core for both code and data they want to
> locate in CCM. This is basically a .data section in that the startup
> code needs to copy this from flash (whether it be code or initialized
> data).
> 
> I guess sec_bss_core is used to store variables in CCM that just need
> to get zeroed by the startup code.
> 
> btw, I am no STM CPU/memory architecture expert but I was reading up
> on it and they do not suggest putting both code and data into CCM. Of
> course, if you need the RAM you need the RAM… Is that why you want to
> move a stack there? I guess if all your code is executing from flash
> then putting data into CCM is fine (maybe faster is SRAM is slower?).
> 
> Seems to me it would be nice to differentiate “core text” from “core
> data”. No real reason I guess but seems a bit more intuitive. Might
> be nice to come up with a set of “standard” section definitions (if
> they do not already exist somewhere) that we can apply across all
> BSPs/MCUs.
> 
> 
> > On Mar 31, 2018, at 4:02 PM, markus  wrote:
> > 
> > I looked into moving the stack into the CCM memory of the stm32
> > mcu's - and although almost every linker script defines ".data.core"
> > sections and there are some defines in bsp.h's for section
> > attributes they don't seem to be used.
> > 
> > Is there some hidden magic going on or is the CCM reserved for
> > application code?
> > 
> > Have fun,
> > Markus  
> 

Re: os data.core memory section

[Fabio Utzig]

On Mon, Apr 2, 2018, at 4:42 PM, markus wrote:
> On Mon, 02 Apr 2018 14:16:54 -0300
> Fabio Utzig  wrote:
> 
> > Both
> > 
> > hw/mcu/stm/stm32f7xx/stm32f767.ld
> > hw/mcu/stm/stm32f4xx/stm32f407.ld
> > 
> > already define the stack on CCM (called DTCM on the F7xx). Am I
> > missing something here?
> 
> It might be me who's missing something (most likely scenario). The
> linker scripts do indeed define the DTCM and CCM memory regions and
> gives them names, ".stack" and ".data.core" depending on the linker
> script. What I'm missing is that those sections aren't used anywhere in
> the code.
> 
> The stacks for (main/idle) tasks are defined by OS_TASK_STACK_DEFINE in
> os_task.h, which sets the alignment but not the section. Looking at the
> generated memory map from an stm32f7 app all the sections are there but
> I cannot identify anything actually placed in there.
> 
> But then the linker has always been a bit of a dark art to me so I
> might just not be looking at the right things, or properly interpret
> what I'm seeing.

Ah, I see what you mean now, seems correct. Beyond main/idle it lso applies to 
any task for which the stack was allocated with malloc.

Re: os data.core memory section

[markus]

On Mon, 02 Apr 2018 14:16:54 -0300
Fabio Utzig  wrote:

> Both
> 
> hw/mcu/stm/stm32f7xx/stm32f767.ld
> hw/mcu/stm/stm32f4xx/stm32f407.ld
> 
> already define the stack on CCM (called DTCM on the F7xx). Am I
> missing something here?

It might be me who's missing something (most likely scenario). The
linker scripts do indeed define the DTCM and CCM memory regions and
gives them names, ".stack" and ".data.core" depending on the linker
script. What I'm missing is that those sections aren't used anywhere in
the code.

The stacks for (main/idle) tasks are defined by OS_TASK_STACK_DEFINE in
os_task.h, which sets the alignment but not the section. Looking at the
generated memory map from an stm32f7 app all the sections are there but
I cannot identify anything actually placed in there.

But then the linker has always been a bit of a dark art to me so I
might just not be looking at the right things, or properly interpret
what I'm seeing.



> 
> On Mon, Apr 2, 2018, at 2:15 PM, Christopher Collins wrote:
> > Hi Markus,
> > 
> > On Sat, Mar 31, 2018 at 04:02:05PM -0700, markus wrote:  
> > > I looked into moving the stack into the CCM memory of the stm32
> > > mcu's - and although almost every linker script defines
> > > ".data.core" sections and there are some defines in bsp.h's for
> > > section attributes they don't seem to be used.
> > > 
> > > Is there some hidden magic going on or is the CCM reserved for
> > > application code?  
> > 
> > No hidden magic; CCM is mostly unused and is up for grabs.  I think
> > there was some attempt to use this memory intelligently a while
> > back, but as the number of supported BSPs increased, it became
> > impractical.
> > 
> > When you say "the stack", do you mean the interrupt handler stack?
> > That sounds like a reasonable use of CCM (though you and others
> > probably have a better sense of this than I do).  If this is
> > something that users will want to do, it might be good to create a
> > syscfg setting to control whether the stack gets put in CCM or
> > normal RAM.
> > 
> > Chris  

Re: [RFC] Mesh uses multi advertising instances.

[Łukasz Rymanowski]

Hi Aditya.

On Mon, Apr 2, 2018, 19:14 Aditya Xavier  wrote:

> Hi Łukasz,
>
> Is there anything special required to get this working along with BLE ?


> For e.g. would the btshell app code for ADV_EXT work along with mesh with
> the provided patches ?
>

In addition to configuration mentioned in PR commit message, the btshell
app would have to enable ble mesh and ble mesh shell (check blemesh_shell
app for that)

>
> Mesh and BLE seems to compile however, am currently unable to get Mesh
> working.
>
> Also, any reason why this was not accepted yet ?
>

People are busy with other stuff I guess. I think it will be merged
eventually.

>
>
>
> Thanks,
> Aditya Xavier.
>

Best
Lukasz


>
> > On 20-Mar-2018, at 12:57 AM, Sterling Hughes <
> sterling.hughes.pub...@gmail.com> wrote:
> >
> > +1 - this is great, thanks Lukasz!
> >
> > On 19 Mar 2018, at 6:36, Łukasz Rymanowski wrote:
> >
> >> Hi All,
> >>
> >> I saw people asking around about possibility to advertise with non-mesh
> >> data while mesh is running on Mynewt.  Well this is possible to do but
> of
> >> course it brings a lot of risk for mesh operations and especially for
> >> friendship scenario. However I went ahead and added support for this in
> >> Mynewt and I'm interested in how it works for you.
> >>
> >> So here is a PR which makes use of multi instances from BT5 Advertising
> >> extensions and basically allows you to create additional instances which
> >> contains non-mesh data.
> >>
> >> https://github.com/apache/mynewt-nimble/pull/8
> >>
> >> Instructions on how to enable it you can find in the commit message.
> >>
> >> Comments are welcome
> >>
> >> Best
> >> Łukasz
>
>

Re: os data.core memory section

[will sanfilippo]

Markus:

I presume you are referring to these definitions:

#define sec_data_core   __attribute__((section(".data.core")))
#define sec_bss_core__attribute__((section(".bss.core")))
#define sec_bss_nz_core __attribute__((section(".bss.core.nz")))

As far as I know there is no real magic here but I am sure there is some degree 
of inconsistency.

The reason sec_bss_nz_core was added was to get around a HW problem with early 
nordic chips (you can see the reference in nrf52.ld) so I do not doubt that 
this is no longer used. Personally, I think the idea of having a “non-zeroed 
.bss” is pretty cool. I guess one could simply call that the heap but sometimes 
you just like allocating a global variable and not allocating it from the heap. 
I realize that the only real reason to do this is save time in the startup code 
zeroing out memory (but still; that is cool!) :-) Not quite sure why “core” was 
added to that defintion. Maybe because there was some conflict with naming it 
bss.nz?

I should probably look at the STM startup code to be sure of this but I presume 
they use sec_data_core for both code and data they want to locate in CCM. This 
is basically a .data section in that the startup code needs to copy this from 
flash (whether it be code or initialized data).

I guess sec_bss_core is used to store variables in CCM that just need to get 
zeroed by the startup code.

btw, I am no STM CPU/memory architecture expert but I was reading up on it and 
they do not suggest putting both code and data into CCM. Of course, if you need 
the RAM you need the RAM… Is that why you want to move a stack there? I guess 
if all your code is executing from flash then putting data into CCM is fine 
(maybe faster is SRAM is slower?).

Seems to me it would be nice to differentiate “core text” from “core data”. No 
real reason I guess but seems a bit more intuitive. Might be nice to come up 
with a set of “standard” section definitions (if they do not already exist 
somewhere) that we can apply across all BSPs/MCUs.


> On Mar 31, 2018, at 4:02 PM, markus  wrote:
> 
> I looked into moving the stack into the CCM memory of the stm32
> mcu's - and although almost every linker script defines ".data.core"
> sections and there are some defines in bsp.h's for section
> attributes they don't seem to be used.
> 
> Is there some hidden magic going on or is the CCM reserved for
> application code?
> 
> Have fun,
> Markus

Re: os data.core memory section

[Fabio Utzig]

Both

hw/mcu/stm/stm32f7xx/stm32f767.ld
hw/mcu/stm/stm32f4xx/stm32f407.ld

already define the stack on CCM (called DTCM on the F7xx). Am I missing 
something here?

On Mon, Apr 2, 2018, at 2:15 PM, Christopher Collins wrote:
> Hi Markus,
> 
> On Sat, Mar 31, 2018 at 04:02:05PM -0700, markus wrote:
> > I looked into moving the stack into the CCM memory of the stm32
> > mcu's - and although almost every linker script defines ".data.core"
> > sections and there are some defines in bsp.h's for section
> > attributes they don't seem to be used.
> > 
> > Is there some hidden magic going on or is the CCM reserved for
> > application code?
> 
> No hidden magic; CCM is mostly unused and is up for grabs.  I think
> there was some attempt to use this memory intelligently a while back,
> but as the number of supported BSPs increased, it became impractical.
> 
> When you say "the stack", do you mean the interrupt handler stack?  That
> sounds like a reasonable use of CCM (though you and others probably have
> a better sense of this than I do).  If this is something that users will
> want to do, it might be good to create a syscfg setting to control
> whether the stack gets put in CCM or normal RAM.
> 
> Chris

Re: [RFC] Mesh uses multi advertising instances.

[Aditya Xavier]

Hi Łukasz,

Is there anything special required to get this working along with BLE ?

For e.g. would the btshell app code for ADV_EXT work along with mesh with the 
provided patches ?

Mesh and BLE seems to compile however, am currently unable to get Mesh working.

Also, any reason why this was not accepted yet ?

Thanks,
Aditya Xavier.


> On 20-Mar-2018, at 12:57 AM, Sterling Hughes 
>  wrote:
> 
> +1 - this is great, thanks Lukasz!
> 
> On 19 Mar 2018, at 6:36, Łukasz Rymanowski wrote:
> 
>> Hi All,
>> 
>> I saw people asking around about possibility to advertise with non-mesh
>> data while mesh is running on Mynewt.  Well this is possible to do but of
>> course it brings a lot of risk for mesh operations and especially for
>> friendship scenario. However I went ahead and added support for this in
>> Mynewt and I'm interested in how it works for you.
>> 
>> So here is a PR which makes use of multi instances from BT5 Advertising
>> extensions and basically allows you to create additional instances which
>> contains non-mesh data.
>> 
>> https://github.com/apache/mynewt-nimble/pull/8
>> 
>> Instructions on how to enable it you can find in the commit message.
>> 
>> Comments are welcome
>> 
>> Best
>> Łukasz

Re: os data.core memory section

[Christopher Collins]

Hi Markus,

On Sat, Mar 31, 2018 at 04:02:05PM -0700, markus wrote:
> I looked into moving the stack into the CCM memory of the stm32
> mcu's - and although almost every linker script defines ".data.core"
> sections and there are some defines in bsp.h's for section
> attributes they don't seem to be used.
> 
> Is there some hidden magic going on or is the CCM reserved for
> application code?

No hidden magic; CCM is mostly unused and is up for grabs.  I think
there was some attempt to use this memory intelligently a while back,
but as the number of supported BSPs increased, it became impractical.

When you say "the stack", do you mean the interrupt handler stack?  That
sounds like a reasonable use of CCM (though you and others probably have
a better sense of this than I do).  If this is something that users will
want to do, it might be good to create a syscfg setting to control
whether the stack gets put in CCM or normal RAM.

Chris

Re: [GitHub] sdalu opened a new issue #985: Building Lora with SPI > 0

[will sanfilippo]

I think this is just some legacy code. At least, I cannot see any restrictions 
in the code that would necessitate spi 0 being used. I do seem to recall there 
being a reason for this but as far as I can tell it is no longer needed.
 
> On Apr 2, 2018, at 2:15 AM, GitBox  wrote:
> 
> sdalu opened a new issue #985: Building Lora with SPI  > 0
> URL: https://github.com/apache/mynewt-core/issues/985
> 
> 
>   It's not possible to build Lora with SPI1, due to the following code in 
> `sx1276-board.h`. Is there a specific reason for this restriction?
> 
>   ~~~c
>   #if RADIO_SPI_IDX == 0
>   #define RADIO_NSS   MYNEWT_VAL(SX1276_SPI_CS_PIN)
>   #else
>   #error Invalid SX1276_SPI_IDX value
>   #endif
>   ~~~
> 
> 
> This is an automated message from the Apache Git Service.
> To respond to the message, please log on GitHub and use the
> URL above to go to the specific comment.
> 
> For queries about this service, please contact Infrastructure at:
> us...@infra.apache.org
> 
> 
> With regards,
> Apache Git Services