Re: Nimble on U-blox Nina B112 (Nrf52832)

2021-06-01 Thread Erik Englund 
Change the Nimble stacksize from 16384 to 2048, the nimble application
starts as it should.
Haven't had time to look into it anymore, it should've been 16k for a
reason.

We´ll have to trim stacksizes to leave some ram for the actual application
though.

I guess the board should start advertising some data, which it doesn't.
I´m not familiar with Mynewt/Nimble at all, our BLE products use the zephyr
rtos/stack together with MCUboot.


This is tested on nrf52832-dk.

apps/wireless/bluetooth/nimble/Makefile
STACKSIZE = 2048

NuttShell (NSH) NuttX-10.1.0-RC1
nsh> nimble &
nimble [5:255]
hci init
port init
gap init
gatt init
ans init
ias init
lls init
tps init
hci_sock task init
ble_host task init
nsh> hci sock task
host task
free
 total   used   freelargest  nused  nfree
Umem:31120  26144   4976   4944 83  2
nsh> ps
  PID PRI POLICY   TYPENPX STATEEVENT SIGMASK   STACK   USED
 FILLED COMMAND
0   0 FIFO Kthread N-- Ready   002048 000536
 26.1%  Idle Task
1 224 RR   Kthread --- Waiting  Signal 002032 000600
 29.5%  hpwork
2 100 RR   Kthread --- Waiting  Signal 002032 000600
 29.5%  lpwork
3 100 RR   Task--- Running 002032 001308
 64.3%  init
4 100 RR   Kthread --- Waiting  MQ empty   001000 000408
 40.8%  BT HCI Tx
5 255 RR   Task--- Waiting  Signal 002032 000856
 42.1%  nimble
6   1 RR   pthread --- Waiting  MQ empty   002048 000440
 21.4%  pt-0x12bed 0
7   1 RR   pthread --- Waiting  Semaphore  002048 000736
 35.9%  pt-0x12c05 0
nsh>


 arm-none-eabi-size nuttx
   textdata bss dec hex filename
 3135742340   29472  345386   5452a nuttx

Med vänlig hälsning
Erik Englund

Innoware Development AB
Hyttvägen 13

73338 SALA
Org.nr. 556790-2977
www.innoware.se


Den lör 29 maj 2021 kl 01:03 skrev Nathan Hartman :

> On Fri, May 28, 2021 at 5:24 PM Alan Carvalho de Assis 
> wrote:
>
> > Hi Nathan,
> >
> > On 5/28/21, Nathan Hartman  wrote:
> > > On Fri, May 28, 2021 at 4:43 PM Alan Carvalho de Assis
> > >  wrote:
> > >>
> > >> Hi Erik,
> > >>
> > >> Thank you very much for your help.
> > >>
> > >> I noticed the final binary is too big (more than 300KB), is it also
> > >> happening to you?
> > >>
> > >> BR,
> > >>
> > >> Alan
> > >
> > >
> > > Do some sections in the linker script need (NOLOAD)?
> > >
> > > See PR-3198 [1], where the binary was also huge, until davids5 taught
> > > me about that:
> > >
> > > [1] https://github.com/apache/incubator-nuttx/pull/3198
> > >
> >
> > Good question!
> >
> > When using external libraries with NuttX I need to use "--gc-sections"
> > to reduce the final size:
> >
> >
> >
> https://acassis.wordpress.com/2020/10/06/linking-external-libraries-on-nuttx/
> >
> > BR,
> >
> > Alan
>
>
>
> Ah, yes, I use that too, together with -ffunction-sections and
> -fdata-sections, because the linker gc works at the granularity of a
> section.
>
> Did it work in this case?
>
> Nathan
>

Re: Nimble on U-blox Nina B112 (Nrf52832)

2021-06-01 Thread Alan Carvalho de Assis 
Hi Erik,

Thank you very much!

Nice finding. Maybe Matias used 16KB because it was failing when stack
was small, and maybe it is failing now but silently because you said
it is not adverting data.

We need to get NuttX BLE with better support on NuttX. Currently we
have NimBLE integrated, but Xiaomi team integrated the Zephyr stack on
NuttX.

I hope your company can use NuttX with BLE soon too! ;-)

BR,

Alan

On 6/1/21, Erik Englund  wrote:
> Change the Nimble stacksize from 16384 to 2048, the nimble application
> starts as it should.
> Haven't had time to look into it anymore, it should've been 16k for a
> reason.
>
> We´ll have to trim stacksizes to leave some ram for the actual application
> though.
>
> I guess the board should start advertising some data, which it doesn't.
> I´m not familiar with Mynewt/Nimble at all, our BLE products use the zephyr
> rtos/stack together with MCUboot.
>
>
> This is tested on nrf52832-dk.
>
> apps/wireless/bluetooth/nimble/Makefile
> STACKSIZE = 2048
>
> NuttShell (NSH) NuttX-10.1.0-RC1
> nsh> nimble &
> nimble [5:255]
> hci init
> port init
> gap init
> gatt init
> ans init
> ias init
> lls init
> tps init
> hci_sock task init
> ble_host task init
> nsh> hci sock task
> host task
> free
>  total   used   freelargest  nused  nfree
> Umem:31120  26144   4976   4944 83  2
> nsh> ps
>   PID PRI POLICY   TYPENPX STATEEVENT SIGMASK   STACK   USED
>  FILLED COMMAND
> 0   0 FIFO Kthread N-- Ready   002048 000536
>  26.1%  Idle Task
> 1 224 RR   Kthread --- Waiting  Signal 002032 000600
>  29.5%  hpwork
> 2 100 RR   Kthread --- Waiting  Signal 002032 000600
>  29.5%  lpwork
> 3 100 RR   Task--- Running 002032 001308
>  64.3%  init
> 4 100 RR   Kthread --- Waiting  MQ empty   001000 000408
>  40.8%  BT HCI Tx
> 5 255 RR   Task--- Waiting  Signal 002032 000856
>  42.1%  nimble
> 6   1 RR   pthread --- Waiting  MQ empty   002048 000440
>  21.4%  pt-0x12bed 0
> 7   1 RR   pthread --- Waiting  Semaphore  002048 000736
>  35.9%  pt-0x12c05 0
> nsh>
>
>
>  arm-none-eabi-size nuttx
>textdata bss dec hex filename
>  3135742340   29472  345386   5452a nuttx
>
> Med vänlig hälsning
> Erik Englund
>
> Innoware Development AB
> Hyttvägen 13
>
> 73338 SALA
> Org.nr. 556790-2977
> www.innoware.se
>
>
> Den lör 29 maj 2021 kl 01:03 skrev Nathan Hartman >:
>
>> On Fri, May 28, 2021 at 5:24 PM Alan Carvalho de Assis
>> 
>> wrote:
>>
>> > Hi Nathan,
>> >
>> > On 5/28/21, Nathan Hartman  wrote:
>> > > On Fri, May 28, 2021 at 4:43 PM Alan Carvalho de Assis
>> > >  wrote:
>> > >>
>> > >> Hi Erik,
>> > >>
>> > >> Thank you very much for your help.
>> > >>
>> > >> I noticed the final binary is too big (more than 300KB), is it also
>> > >> happening to you?
>> > >>
>> > >> BR,
>> > >>
>> > >> Alan
>> > >
>> > >
>> > > Do some sections in the linker script need (NOLOAD)?
>> > >
>> > > See PR-3198 [1], where the binary was also huge, until davids5 taught
>> > > me about that:
>> > >
>> > > [1] https://github.com/apache/incubator-nuttx/pull/3198
>> > >
>> >
>> > Good question!
>> >
>> > When using external libraries with NuttX I need to use "--gc-sections"
>> > to reduce the final size:
>> >
>> >
>> >
>> https://acassis.wordpress.com/2020/10/06/linking-external-libraries-on-nuttx/
>> >
>> > BR,
>> >
>> > Alan
>>
>>
>>
>> Ah, yes, I use that too, together with -ffunction-sections and
>> -fdata-sections, because the linker gc works at the granularity of a
>> section.
>>
>> Did it work in this case?
>>
>> Nathan
>>
>

Re: Nimble on U-blox Nina B112 (Nrf52832)

2021-06-01 Thread Alan Carvalho de Assis 
After reducing the stack from 16KB to 2KB I got same result as yours Erik:

NuttShell (NSH) NuttX-10.1.0-RC1
nsh> nimble &
nimble [5:255]
hci init
port init
gap init
gatt init
ans init
ias init
lls init
tps init
hci_sock task init
ble_host task init
nsh> hci sock task
host task

nsh> ifconfig
bnep0   Link encap:UNSPEC at UP

Matias, do you have some idea why we are not seeing the BLE adverting?

BR,

Alan

On 6/1/21, Erik Englund  wrote:
> Change the Nimble stacksize from 16384 to 2048, the nimble application
> starts as it should.
> Haven't had time to look into it anymore, it should've been 16k for a
> reason.
>
> We´ll have to trim stacksizes to leave some ram for the actual application
> though.
>
> I guess the board should start advertising some data, which it doesn't.
> I´m not familiar with Mynewt/Nimble at all, our BLE products use the zephyr
> rtos/stack together with MCUboot.
>
>
> This is tested on nrf52832-dk.
>
> apps/wireless/bluetooth/nimble/Makefile
> STACKSIZE = 2048
>
> NuttShell (NSH) NuttX-10.1.0-RC1
> nsh> nimble &
> nimble [5:255]
> hci init
> port init
> gap init
> gatt init
> ans init
> ias init
> lls init
> tps init
> hci_sock task init
> ble_host task init
> nsh> hci sock task
> host task
> free
>  total   used   freelargest  nused  nfree
> Umem:31120  26144   4976   4944 83  2
> nsh> ps
>   PID PRI POLICY   TYPENPX STATEEVENT SIGMASK   STACK   USED
>  FILLED COMMAND
> 0   0 FIFO Kthread N-- Ready   002048 000536
>  26.1%  Idle Task
> 1 224 RR   Kthread --- Waiting  Signal 002032 000600
>  29.5%  hpwork
> 2 100 RR   Kthread --- Waiting  Signal 002032 000600
>  29.5%  lpwork
> 3 100 RR   Task--- Running 002032 001308
>  64.3%  init
> 4 100 RR   Kthread --- Waiting  MQ empty   001000 000408
>  40.8%  BT HCI Tx
> 5 255 RR   Task--- Waiting  Signal 002032 000856
>  42.1%  nimble
> 6   1 RR   pthread --- Waiting  MQ empty   002048 000440
>  21.4%  pt-0x12bed 0
> 7   1 RR   pthread --- Waiting  Semaphore  002048 000736
>  35.9%  pt-0x12c05 0
> nsh>
>
>
>  arm-none-eabi-size nuttx
>textdata bss dec hex filename
>  3135742340   29472  345386   5452a nuttx
>
> Med vänlig hälsning
> Erik Englund
>
> Innoware Development AB
> Hyttvägen 13
>
> 73338 SALA
> Org.nr. 556790-2977
> www.innoware.se
>
>
> Den lör 29 maj 2021 kl 01:03 skrev Nathan Hartman >:
>
>> On Fri, May 28, 2021 at 5:24 PM Alan Carvalho de Assis
>> 
>> wrote:
>>
>> > Hi Nathan,
>> >
>> > On 5/28/21, Nathan Hartman  wrote:
>> > > On Fri, May 28, 2021 at 4:43 PM Alan Carvalho de Assis
>> > >  wrote:
>> > >>
>> > >> Hi Erik,
>> > >>
>> > >> Thank you very much for your help.
>> > >>
>> > >> I noticed the final binary is too big (more than 300KB), is it also
>> > >> happening to you?
>> > >>
>> > >> BR,
>> > >>
>> > >> Alan
>> > >
>> > >
>> > > Do some sections in the linker script need (NOLOAD)?
>> > >
>> > > See PR-3198 [1], where the binary was also huge, until davids5 taught
>> > > me about that:
>> > >
>> > > [1] https://github.com/apache/incubator-nuttx/pull/3198
>> > >
>> >
>> > Good question!
>> >
>> > When using external libraries with NuttX I need to use "--gc-sections"
>> > to reduce the final size:
>> >
>> >
>> >
>> https://acassis.wordpress.com/2020/10/06/linking-external-libraries-on-nuttx/
>> >
>> > BR,
>> >
>> > Alan
>>
>>
>>
>> Ah, yes, I use that too, together with -ffunction-sections and
>> -fdata-sections, because the linker gc works at the granularity of a
>> section.
>>
>> Did it work in this case?
>>
>> Nathan
>>
>

Re: Nimble on U-blox Nina B112 (Nrf52832)

2021-06-01 Thread Matias N. 
Sorry, no idea. You should probably enable debugging and see what is happening.

Best,
Matias

On Tue, Jun 1, 2021, at 11:54, Alan Carvalho de Assis wrote:
> After reducing the stack from 16KB to 2KB I got same result as yours Erik:
> 
> NuttShell (NSH) NuttX-10.1.0-RC1
> nsh> nimble &
> nimble [5:255]
> hci init
> port init
> gap init
> gatt init
> ans init
> ias init
> lls init
> tps init
> hci_sock task init
> ble_host task init
> nsh> hci sock task
> host task
> 
> nsh> ifconfig
> bnep0   Link encap:UNSPEC at UP
> 
> Matias, do you have some idea why we are not seeing the BLE adverting?
> 
> BR,
> 
> Alan
> 
> On 6/1/21, Erik Englund  > wrote:
> > Change the Nimble stacksize from 16384 to 2048, the nimble application
> > starts as it should.
> > Haven't had time to look into it anymore, it should've been 16k for a
> > reason.
> >
> > We´ll have to trim stacksizes to leave some ram for the actual application
> > though.
> >
> > I guess the board should start advertising some data, which it doesn't.
> > I´m not familiar with Mynewt/Nimble at all, our BLE products use the zephyr
> > rtos/stack together with MCUboot.
> >
> >
> > This is tested on nrf52832-dk.
> >
> > apps/wireless/bluetooth/nimble/Makefile
> > STACKSIZE = 2048
> >
> > NuttShell (NSH) NuttX-10.1.0-RC1
> > nsh> nimble &
> > nimble [5:255]
> > hci init
> > port init
> > gap init
> > gatt init
> > ans init
> > ias init
> > lls init
> > tps init
> > hci_sock task init
> > ble_host task init
> > nsh> hci sock task
> > host task
> > free
> >  total   used   freelargest  nused  nfree
> > Umem:31120  26144   4976   4944 83  2
> > nsh> ps
> >   PID PRI POLICY   TYPENPX STATEEVENT SIGMASK   STACK   USED
> >  FILLED COMMAND
> > 0   0 FIFO Kthread N-- Ready   002048 000536
> >  26.1%  Idle Task
> > 1 224 RR   Kthread --- Waiting  Signal 002032 000600
> >  29.5%  hpwork
> > 2 100 RR   Kthread --- Waiting  Signal 002032 000600
> >  29.5%  lpwork
> > 3 100 RR   Task--- Running 002032 001308
> >  64.3%  init
> > 4 100 RR   Kthread --- Waiting  MQ empty   001000 000408
> >  40.8%  BT HCI Tx
> > 5 255 RR   Task--- Waiting  Signal 002032 000856
> >  42.1%  nimble
> > 6   1 RR   pthread --- Waiting  MQ empty   002048 000440
> >  21.4%  pt-0x12bed 0
> > 7   1 RR   pthread --- Waiting  Semaphore  002048 000736
> >  35.9%  pt-0x12c05 0
> > nsh>
> >
> >
> >  arm-none-eabi-size nuttx
> >textdata bss dec hex filename
> >  3135742340   29472  345386   5452a nuttx
> >
> > Med vänlig hälsning
> > Erik Englund
> >
> > Innoware Development AB
> > Hyttvägen 13
> >
> > 73338 SALA
> > Org.nr. 556790-2977
> > www.innoware.se
> >
> >
> > Den lör 29 maj 2021 kl 01:03 skrev Nathan Hartman  > 
> >>:
> >
> >> On Fri, May 28, 2021 at 5:24 PM Alan Carvalho de Assis
> >> mailto:acassis%40gmail.com>>
> >> wrote:
> >>
> >> > Hi Nathan,
> >> >
> >> > On 5/28/21, Nathan Hartman  >> > > wrote:
> >> > > On Fri, May 28, 2021 at 4:43 PM Alan Carvalho de Assis
> >> > > mailto:acassis%40gmail.com>> wrote:
> >> > >>
> >> > >> Hi Erik,
> >> > >>
> >> > >> Thank you very much for your help.
> >> > >>
> >> > >> I noticed the final binary is too big (more than 300KB), is it also
> >> > >> happening to you?
> >> > >>
> >> > >> BR,
> >> > >>
> >> > >> Alan
> >> > >
> >> > >
> >> > > Do some sections in the linker script need (NOLOAD)?
> >> > >
> >> > > See PR-3198 [1], where the binary was also huge, until davids5 taught
> >> > > me about that:
> >> > >
> >> > > [1] https://github.com/apache/incubator-nuttx/pull/3198
> >> > >
> >> >
> >> > Good question!
> >> >
> >> > When using external libraries with NuttX I need to use "--gc-sections"
> >> > to reduce the final size:
> >> >
> >> >
> >> >
> >> https://acassis.wordpress.com/2020/10/06/linking-external-libraries-on-nuttx/
> >> >
> >> > BR,
> >> >
> >> > Alan
> >>
> >>
> >>
> >> Ah, yes, I use that too, together with -ffunction-sections and
> >> -fdata-sections, because the linker gc works at the granularity of a
> >> section.
> >>
> >> Did it work in this case?
> >>
> >> Nathan
> >>
> >
>

Re: Nimble on U-blox Nina B112 (Nrf52832)

2021-06-01 Thread Alan Carvalho de Assis 
Thank you Matias,

I'll do it!

BR,

Alan

On 6/1/21, Matias N.  wrote:
> Sorry, no idea. You should probably enable debugging and see what is
> happening.
>
> Best,
> Matias
>
> On Tue, Jun 1, 2021, at 11:54, Alan Carvalho de Assis wrote:
>> After reducing the stack from 16KB to 2KB I got same result as yours
>> Erik:
>>
>> NuttShell (NSH) NuttX-10.1.0-RC1
>> nsh> nimble &
>> nimble [5:255]
>> hci init
>> port init
>> gap init
>> gatt init
>> ans init
>> ias init
>> lls init
>> tps init
>> hci_sock task init
>> ble_host task init
>> nsh> hci sock task
>> host task
>>
>> nsh> ifconfig
>> bnep0   Link encap:UNSPEC at UP
>>
>> Matias, do you have some idea why we are not seeing the BLE adverting?
>>
>> BR,
>>
>> Alan
>>
>> On 6/1/21, Erik Englund > > wrote:
>> > Change the Nimble stacksize from 16384 to 2048, the nimble application
>> > starts as it should.
>> > Haven't had time to look into it anymore, it should've been 16k for a
>> > reason.
>> >
>> > We´ll have to trim stacksizes to leave some ram for the actual
>> > application
>> > though.
>> >
>> > I guess the board should start advertising some data, which it doesn't.
>> > I´m not familiar with Mynewt/Nimble at all, our BLE products use the
>> > zephyr
>> > rtos/stack together with MCUboot.
>> >
>> >
>> > This is tested on nrf52832-dk.
>> >
>> > apps/wireless/bluetooth/nimble/Makefile
>> > STACKSIZE = 2048
>> >
>> > NuttShell (NSH) NuttX-10.1.0-RC1
>> > nsh> nimble &
>> > nimble [5:255]
>> > hci init
>> > port init
>> > gap init
>> > gatt init
>> > ans init
>> > ias init
>> > lls init
>> > tps init
>> > hci_sock task init
>> > ble_host task init
>> > nsh> hci sock task
>> > host task
>> > free
>> >  total   used   freelargest  nused
>> > nfree
>> > Umem:31120  26144   4976   4944 83
>> > 2
>> > nsh> ps
>> >   PID PRI POLICY   TYPENPX STATEEVENT SIGMASK   STACK
>> > USED
>> >  FILLED COMMAND
>> > 0   0 FIFO Kthread N-- Ready   002048
>> > 000536
>> >  26.1%  Idle Task
>> > 1 224 RR   Kthread --- Waiting  Signal 002032
>> > 000600
>> >  29.5%  hpwork
>> > 2 100 RR   Kthread --- Waiting  Signal 002032
>> > 000600
>> >  29.5%  lpwork
>> > 3 100 RR   Task--- Running 002032
>> > 001308
>> >  64.3%  init
>> > 4 100 RR   Kthread --- Waiting  MQ empty   001000
>> > 000408
>> >  40.8%  BT HCI Tx
>> > 5 255 RR   Task--- Waiting  Signal 002032
>> > 000856
>> >  42.1%  nimble
>> > 6   1 RR   pthread --- Waiting  MQ empty   002048
>> > 000440
>> >  21.4%  pt-0x12bed 0
>> > 7   1 RR   pthread --- Waiting  Semaphore  002048
>> > 000736
>> >  35.9%  pt-0x12c05 0
>> > nsh>
>> >
>> >
>> >  arm-none-eabi-size nuttx
>> >textdata bss dec hex filename
>> >  3135742340   29472  345386   5452a nuttx
>> >
>> > Med vänlig hälsning
>> > Erik Englund
>> >
>> > Innoware Development AB
>> > Hyttvägen 13
>> >
>> > 73338 SALA
>> > Org.nr. 556790-2977
>> > www.innoware.se
>> >
>> >
>> > Den lör 29 maj 2021 kl 01:03 skrev Nathan Hartman
>> > mailto:hartman.nathan%40gmail.com>
>> >>:
>> >
>> >> On Fri, May 28, 2021 at 5:24 PM Alan Carvalho de Assis
>> >> mailto:acassis%40gmail.com>>
>> >> wrote:
>> >>
>> >> > Hi Nathan,
>> >> >
>> >> > On 5/28/21, Nathan Hartman > >> > > wrote:
>> >> > > On Fri, May 28, 2021 at 4:43 PM Alan Carvalho de Assis
>> >> > > mailto:acassis%40gmail.com>> wrote:
>> >> > >>
>> >> > >> Hi Erik,
>> >> > >>
>> >> > >> Thank you very much for your help.
>> >> > >>
>> >> > >> I noticed the final binary is too big (more than 300KB), is it
>> >> > >> also
>> >> > >> happening to you?
>> >> > >>
>> >> > >> BR,
>> >> > >>
>> >> > >> Alan
>> >> > >
>> >> > >
>> >> > > Do some sections in the linker script need (NOLOAD)?
>> >> > >
>> >> > > See PR-3198 [1], where the binary was also huge, until davids5
>> >> > > taught
>> >> > > me about that:
>> >> > >
>> >> > > [1] https://github.com/apache/incubator-nuttx/pull/3198
>> >> > >
>> >> >
>> >> > Good question!
>> >> >
>> >> > When using external libraries with NuttX I need to use
>> >> > "--gc-sections"
>> >> > to reduce the final size:
>> >> >
>> >> >
>> >> >
>> >> https://acassis.wordpress.com/2020/10/06/linking-external-libraries-on-nuttx/
>> >> >
>> >> > BR,
>> >> >
>> >> > Alan
>> >>
>> >>
>> >>
>> >> Ah, yes, I use that too, together with -ffunction-sections and
>> >> -fdata-sections, because the linker gc works at the granularity of a
>> >> section.
>> >>
>> >> Did it work in this case?
>> >>
>> >> Nathan
>> >>
>> >
>>
>

Re: [Discuss] Migrate the build system to CMake

2021-06-01 Thread Matias N. 
Hi,
just wanted to add that until this is ready, the gap between master and the 
branch
widens with every merged PR and this increases the backporting effort. 
I'm willing to do most of the remaining work but as I mentioned I cannot 
possibly test everything so
help is needed. 
I'd really like your feedback on this before I continue and ensure the effort 
will not go to waste.

Best,
Matias

On Sat, May 29, 2021, at 14:06, Matias N. wrote:
> Hi,
> for anyone not following the relevant PR, please have a look at the current 
> state here:
> 
> https://github.com/apache/incubator-nuttx/pull/3704
> 
> This is now at a point where it can be tested by others. It would be very 
> good to get some
> help testing what I got so far (sim and stm32f4discovery, both on Linux and 
> mac), by running
> examples and test. There are some brief instructions at the end of the PR 
> description for building.
> 
> Other than that, I can continue porting other arch's and boards with the help 
> of CI but it would be
> best if others with more boards could help testing (and ideally with some 
> PRs, as the hard part
> is mostly done) those as well.
> 
> Also, note that this is a PR against a branch so we could eventually merge it 
> before adding support
> for other arch/boards. And finally, I will provide documentation to the new 
> build system in a separate
> PR at some point, which I hope will ease the transition and help reviewing.
> 
> Best,
> Matias
> 
> On Sat, Apr 10, 2021, at 18:43, Xiang Xiao wrote:
>> A new issue is opened recently to address this topic:
>> https://github.com/apache/incubator-nuttx/issues/3455
>> This proposal has the depth of the impact in our daily working, so it's
>> very important to get the feedback from the community before the real
>> action is taken.
>> If you have any concern or suggestion, please reply to this email.
>> 
>> Thanks
>> Xiang
>> 
>

Re: [Discuss] Migrate the build system to CMake

2021-06-01 Thread Alan Carvalho de Assis 
I think we can divide the effort to port all the boards to the new CMake.

I can start take care of ESP32, ESP32-C3 and ESP32-S2.

Let see if we get more people involved in this effort.

BR,

Alan

On 6/1/21, Matias N.  wrote:
> Hi,
> just wanted to add that until this is ready, the gap between master and the
> branch
> widens with every merged PR and this increases the backporting effort.
> I'm willing to do most of the remaining work but as I mentioned I cannot
> possibly test everything so
> help is needed.
> I'd really like your feedback on this before I continue and ensure the
> effort will not go to waste.
>
> Best,
> Matias
>
> On Sat, May 29, 2021, at 14:06, Matias N. wrote:
>> Hi,
>> for anyone not following the relevant PR, please have a look at the
>> current state here:
>>
>> https://github.com/apache/incubator-nuttx/pull/3704
>>
>> This is now at a point where it can be tested by others. It would be very
>> good to get some
>> help testing what I got so far (sim and stm32f4discovery, both on Linux
>> and mac), by running
>> examples and test. There are some brief instructions at the end of the PR
>> description for building.
>>
>> Other than that, I can continue porting other arch's and boards with the
>> help of CI but it would be
>> best if others with more boards could help testing (and ideally with some
>> PRs, as the hard part
>> is mostly done) those as well.
>>
>> Also, note that this is a PR against a branch so we could eventually merge
>> it before adding support
>> for other arch/boards. And finally, I will provide documentation to the
>> new build system in a separate
>> PR at some point, which I hope will ease the transition and help
>> reviewing.
>>
>> Best,
>> Matias
>>
>> On Sat, Apr 10, 2021, at 18:43, Xiang Xiao wrote:
>>> A new issue is opened recently to address this topic:
>>> https://github.com/apache/incubator-nuttx/issues/3455
>>> This proposal has the depth of the impact in our daily working, so it's
>>> very important to get the feedback from the community before the real
>>> action is taken.
>>> If you have any concern or suggestion, please reply to this email.
>>>
>>> Thanks
>>> Xiang
>>>
>>
>

Re: [Discuss] Migrate the build system to CMake

2021-06-01 Thread Matias N. 

On Tue, Jun 1, 2021, at 12:24, Alan Carvalho de Assis wrote:
> I think we can divide the effort to port all the boards to the new CMake.

That would be ideal.

> I can start take care of ESP32, ESP32-C3 and ESP32-S2.
> 
> Let see if we get more people involved in this effort.

Thanks, Alan.

> 
> BR,
> 
> Alan
> 
> On 6/1/21, Matias N. mailto:matias%40imap.cc>> wrote:
> > Hi,
> > just wanted to add that until this is ready, the gap between master and the
> > branch
> > widens with every merged PR and this increases the backporting effort.
> > I'm willing to do most of the remaining work but as I mentioned I cannot
> > possibly test everything so
> > help is needed.
> > I'd really like your feedback on this before I continue and ensure the
> > effort will not go to waste.
> >
> > Best,
> > Matias
> >
> > On Sat, May 29, 2021, at 14:06, Matias N. wrote:
> >> Hi,
> >> for anyone not following the relevant PR, please have a look at the
> >> current state here:
> >>
> >> https://github.com/apache/incubator-nuttx/pull/3704
> >>
> >> This is now at a point where it can be tested by others. It would be very
> >> good to get some
> >> help testing what I got so far (sim and stm32f4discovery, both on Linux
> >> and mac), by running
> >> examples and test. There are some brief instructions at the end of the PR
> >> description for building.
> >>
> >> Other than that, I can continue porting other arch's and boards with the
> >> help of CI but it would be
> >> best if others with more boards could help testing (and ideally with some
> >> PRs, as the hard part
> >> is mostly done) those as well.
> >>
> >> Also, note that this is a PR against a branch so we could eventually merge
> >> it before adding support
> >> for other arch/boards. And finally, I will provide documentation to the
> >> new build system in a separate
> >> PR at some point, which I hope will ease the transition and help
> >> reviewing.
> >>
> >> Best,
> >> Matias
> >>
> >> On Sat, Apr 10, 2021, at 18:43, Xiang Xiao wrote:
> >>> A new issue is opened recently to address this topic:
> >>> https://github.com/apache/incubator-nuttx/issues/3455
> >>> This proposal has the depth of the impact in our daily working, so it's
> >>> very important to get the feedback from the community before the real
> >>> action is taken.
> >>> If you have any concern or suggestion, please reply to this email.
> >>>
> >>> Thanks
> >>> Xiang
> >>>
> >>
> >
>

Re: [Discuss] Migrate the build system to CMake

2021-06-01 Thread Nathan Hartman 
I am interested and I'll try to help with boards I can test. It will take a
few days to get around to it because this has been a busy month, but I'm
catching up.

Cheers
Nathan

On Tue, Jun 1, 2021 at 11:25 AM Alan Carvalho de Assis 
wrote:

> I think we can divide the effort to port all the boards to the new CMake.
>
> I can start take care of ESP32, ESP32-C3 and ESP32-S2.
>
> Let see if we get more people involved in this effort.
>
> BR,
>
> Alan
>
> On 6/1/21, Matias N.  wrote:
> > Hi,
> > just wanted to add that until this is ready, the gap between master and
> the
> > branch
> > widens with every merged PR and this increases the backporting effort.
> > I'm willing to do most of the remaining work but as I mentioned I cannot
> > possibly test everything so
> > help is needed.
> > I'd really like your feedback on this before I continue and ensure the
> > effort will not go to waste.
> >
> > Best,
> > Matias
> >
> > On Sat, May 29, 2021, at 14:06, Matias N. wrote:
> >> Hi,
> >> for anyone not following the relevant PR, please have a look at the
> >> current state here:
> >>
> >> https://github.com/apache/incubator-nuttx/pull/3704
> >>
> >> This is now at a point where it can be tested by others. It would be
> very
> >> good to get some
> >> help testing what I got so far (sim and stm32f4discovery, both on Linux
> >> and mac), by running
> >> examples and test. There are some brief instructions at the end of the
> PR
> >> description for building.
> >>
> >> Other than that, I can continue porting other arch's and boards with the
> >> help of CI but it would be
> >> best if others with more boards could help testing (and ideally with
> some
> >> PRs, as the hard part
> >> is mostly done) those as well.
> >>
> >> Also, note that this is a PR against a branch so we could eventually
> merge
> >> it before adding support
> >> for other arch/boards. And finally, I will provide documentation to the
> >> new build system in a separate
> >> PR at some point, which I hope will ease the transition and help
> >> reviewing.
> >>
> >> Best,
> >> Matias
> >>
> >> On Sat, Apr 10, 2021, at 18:43, Xiang Xiao wrote:
> >>> A new issue is opened recently to address this topic:
> >>> https://github.com/apache/incubator-nuttx/issues/3455
> >>> This proposal has the depth of the impact in our daily working, so it's
> >>> very important to get the feedback from the community before the real
> >>> action is taken.
> >>> If you have any concern or suggestion, please reply to this email.
> >>>
> >>> Thanks
> >>> Xiang
> >>>
> >>
> >
>

Re: Nimble on U-blox Nina B112 (Nrf52832)

2021-06-01 Thread Miguel Wisintainer 
First experiments on NRF52840

nsh> nimble &
nimble [5:255]
hci init
port init
gap init
gatt init
ans init
ias init
lls init
tps init
hci_sock task init
ble_host task init
nsh> hci sock task
host task

nsh> free
nsh: free: Could not open /proc/meminfo (is procfs mounted?): 2
nsh> mount -t procfs /proc
nsh> free
 total   used   freelargest
Umem:96736  26128  70608  70576
nsh> ps
  PID PRI POLICY   TYPENPX STATEEVENT SIGMASK   STACK COMMAND
0   0 FIFO Kthread N-- Ready   002048 Idle Task
1 224 RR   Kthread --- Waiting  Signal 002032 hpwork
2 100 RR   Kthread --- Waiting  Signal 002032 lpwork
3 100 RR   Task--- Running 002032 init
4 100 RR   Kthread --- Waiting  MQ empty   001000 BT HCI Tx
5 255 RR   Task--- Waiting  Signal 002032 nimble
6   1 RR   pthread --- Waiting  MQ empty   002048 pt-0x128b9 0
7   1 RR   pthread --- Waiting  Semaphore  002048 pt-0x128d1 0
nsh>