RE: USB Host and Bluetooth "dongle".

[Tim]

> Am 24.03.2021 um 18:34 schrieb Tim:
> 
> > I can also build in Bluetooth support and the demo app, but as far as
> > I can tell there are no actual Bluetooth host drivers in NuttX to
> > properly support a detected Bluetooth device. My custom board actually
> > has a SiLabs Bluetooth module on it (connected to the SAM via UART and
> > proven to work) but I quite like the idea of just using plug-in
> > Bluetooth devices instead :)
> 
> Bluetooth is quite complex. You will have to deal with several layers:
> 
> 1. Hardware driver (like Ethernet Hardware driver) 2. Low Level Protocol
> Stack (HCI, like network TCP/IP layer) 3. High Level Protocol Stack
("Profiles",
> like network mail, web, ntp, nfs application protocols)
> 
> USB dongles usually implement the hardware driver and the low-level
> protocol stack (HCI). The computer has to run the high level protocol
stack.

[>]  Understood, of course. The documentation in NuttX regarding Bluetooth
is superficial and I am probably guilty of assumption and naivety! Because
there is Host device support, and there are Bluetooth tools and drivers, and
because Linux itself has a Bluetooth stack I leapt to the conclusion that
Nuttx probably had a stack, just not the "link" between it and the detected
USB device (i.e. a relevant USB driver, which are available in the Linux
source trees).

> 
> Other modules, especially the serial ones, implement the whole stack:
> hardware driver, low-level stack, and one or more profiles (SPP,
audio,...). If
> you only need SPP, you really should use these modules.
> This allows you to write only 100 lines of code instead of 1.

[>] My custom board has a SiLabs SoC on-board. I have developed LE
applications using custom GATT on these before very successfully and it has
a UART link to my SAM processor running NuttX. I will probably stick with
that.

The reasons for considering using a USB Bluetooth device:
a) reduces unit costs, when not everyone wants to use Bluetooth
b) existence of (proven working on my custom board, using USB C) host
support so it's over the first hurdle compared to the Bare Metal approach I
had been taking
c) Trying to steer through the Bluetooth SIG nightmare of registrations and
fees...but that's another story!


> 
> fchk

Re: USB Host and Bluetooth "dongle".

[Alan Carvalho de Assis]

Hi Tim,

It depends on what you refers to Bluetooth: is it Bluetooth Classic or BLE ?

If you want BT BLE maybe it is better to use a MCU with BLE.

BR,

Alan

On 3/25/21, Tim  wrote:
>> Am 24.03.2021 um 18:34 schrieb Tim:
>>
>> > I can also build in Bluetooth support and the demo app, but as far as
>> > I can tell there are no actual Bluetooth host drivers in NuttX to
>> > properly support a detected Bluetooth device. My custom board actually
>> > has a SiLabs Bluetooth module on it (connected to the SAM via UART and
>> > proven to work) but I quite like the idea of just using plug-in
>> > Bluetooth devices instead :)
>>
>> Bluetooth is quite complex. You will have to deal with several layers:
>>
>> 1. Hardware driver (like Ethernet Hardware driver) 2. Low Level Protocol
>> Stack (HCI, like network TCP/IP layer) 3. High Level Protocol Stack
> ("Profiles",
>> like network mail, web, ntp, nfs application protocols)
>>
>> USB dongles usually implement the hardware driver and the low-level
>> protocol stack (HCI). The computer has to run the high level protocol
> stack.
>
> [>]  Understood, of course. The documentation in NuttX regarding Bluetooth
> is superficial and I am probably guilty of assumption and naivety! Because
> there is Host device support, and there are Bluetooth tools and drivers,
> and
> because Linux itself has a Bluetooth stack I leapt to the conclusion that
> Nuttx probably had a stack, just not the "link" between it and the detected
> USB device (i.e. a relevant USB driver, which are available in the Linux
> source trees).
>
>>
>> Other modules, especially the serial ones, implement the whole stack:
>> hardware driver, low-level stack, and one or more profiles (SPP,
> audio,...). If
>> you only need SPP, you really should use these modules.
>> This allows you to write only 100 lines of code instead of 1.
>
> [>] My custom board has a SiLabs SoC on-board. I have developed LE
> applications using custom GATT on these before very successfully and it has
> a UART link to my SAM processor running NuttX. I will probably stick with
> that.
>
> The reasons for considering using a USB Bluetooth device:
> a) reduces unit costs, when not everyone wants to use Bluetooth
> b) existence of (proven working on my custom board, using USB C) host
> support so it's over the first hurdle compared to the Bare Metal approach I
> had been taking
> c) Trying to steer through the Bluetooth SIG nightmare of registrations and
> fees...but that's another story!
>
>
>>
>> fchk
>
>
>

RE: USB Host and Bluetooth "dongle".

[Tim]

> Hi Tim,
> 
> It depends on what you refers to Bluetooth: is it Bluetooth Classic or BLE ?
> 
> If you want BT BLE maybe it is better to use a MCU with BLE.
> 

Thanks Alan
Bluetooth LE, which is why I put a SiLabs module on the board and have it 
working, but thought "hey, I might be able to offload the cost of the module to 
the customer, and they can use a USB dongle if they actually want to use 
Bluetooth (not all users will)".

If not, so be it.

Re: Sleep Resolution

[Grr]

Why not use msec & usec delays?

Because the need is nsec delays

My question is:

Why not add a portable, general purpose nsec delay function to Nuttx?

El mié, 24 mar 2021 a las 22:34, Xiang Xiao ()
escribió:

> Another way to avoid the calibration is to reuse the hardware timer in the
> busy loop:
>
> https://github.com/apache/incubator-nuttx/blob/master/drivers/timers/arch_alarm.c#L60-L74
>
> https://github.com/apache/incubator-nuttx/blob/master/drivers/timers/arch_timer.c#L122-L144
>
> On Thu, Mar 25, 2021 at 11:42 AM Gregory Nutt  wrote:
>
> >
> > > Why not call up_udelay or up_mdelay? The arch/soc should provide a best
> > > implementation for you.
> >
> > I was wondering that too.
> >
> > Also, as a side note, it is very important to calibrate the delay loop
> > using in those functions.  If the delay loop is properly calibrated,
> > these can be very accurate (but I suspect most people no longer
> > calibrate the delay loop).
> >
> > There is an app at apps/examples/calib_udelay that can be used to do
> that.
> >
> >
>

Re: USB Host and Bluetooth "dongle".

[Alan Carvalho de Assis]

Hi Tim,

On 3/25/21, Tim  wrote:
>> Hi Tim,
>>
>> It depends on what you refers to Bluetooth: is it Bluetooth Classic or BLE
>> ?
>>
>> If you want BT BLE maybe it is better to use a MCU with BLE.
>>
>
> Thanks Alan
> Bluetooth LE, which is why I put a SiLabs module on the board and have it
> working, but thought "hey, I might be able to offload the cost of the module
> to the customer, and they can use a USB dongle if they actually want to use
> Bluetooth (not all users will)".
>

And you can further offload the price of USB Dongle Bluetooth using a
MCU with BLE.

Currently you have three MCUs with BLE support on NuttX: ESP32 (driver
is coming soon), Bouffalo BL-602 and Nordic nRF52832.

I work at Espressif, so I want to suggest you to consider ESP32! ;-)

BR,

Alan

RE: USB Host and Bluetooth "dongle".

[Tim]

> >> Hi Tim,
> >>
> >> It depends on what you refers to Bluetooth: is it Bluetooth Classic
> >> or BLE ?
> >>
> >> If you want BT BLE maybe it is better to use a MCU with BLE.
> >>
> >
> > Thanks Alan
> > Bluetooth LE, which is why I put a SiLabs module on the board and have
> > it working, but thought "hey, I might be able to offload the cost of
> > the module to the customer, and they can use a USB dongle if they
> > actually want to use Bluetooth (not all users will)".
> >
> 
> And you can further offload the price of USB Dongle Bluetooth using a MCU
> with BLE.
> 
> Currently you have three MCUs with BLE support on NuttX: ESP32 (driver is
> coming soon), Bouffalo BL-602 and Nordic nRF52832.
> 
> I work at Espressif, so I want to suggest you to consider ESP32! ;-)

Main processor is SAMA5D27C as there are many many peripherals on this custom 
board (LCD/CAN/GPS/Accelerometers/multiple RGB LED drivers) and a 
SiLabs/Bouffalo/Nordic SoC will not "cut the mustard" as the main processor; 
Bluetooth LE is just one of many things not the "main deal". This is why I put 
the SiLabs SoC on the board as I have used it before with great success and 
it's not that expensive of course. In this case it's a "network co-processor".

The SIG licensing costs mean - and they have not clarified this to me as yet - 
that there is a possibility that a board with USB and a Bluetooth stack but no 
radio module included *may* not need the $8k declaration fee which is 
completely out of step with the target volumes of this design. I was/am hoping 
that using a plug-in radio module via USB, of the customer's choice (i.e. not 
supplied as part of the product) works around the need to declare the product. 
But this is probably cloud-cuckoo land lol. With hindsight, Wi-Fi may have been 
a much better choice :(

mqtt library on NuttX?

[Matias N.]

Hi,
I was wondering if anyone is already using some MQTT library on NuttX. I see 
many options some of which look like potential candidates for easy porting, but 
if anyone already went through this process I would appreciate some feedback.

Thanks,
Matias

Re: mqtt library on NuttX?

[Alan Carvalho de Assis]

Hi Matias,

Yes, some people here are using mqtt-c on NuttX and it is working fine.

It needs some clean-up to be submitted to apps/

BR,

Alan

On 3/25/21, Matias N.  wrote:
> Hi,
> I was wondering if anyone is already using some MQTT library on NuttX. I see
> many options some of which look like potential candidates for easy porting,
> but if anyone already went through this process I would appreciate some
> feedback.
>
> Thanks,
> Matias

Re: mqtt library on NuttX?

[Alan Carvalho de Assis]

BTW we need to have this PR integrated first:

https://github.com/apache/incubator-nuttx-apps/pull/566

On 3/25/21, Alan Carvalho de Assis  wrote:
> Hi Matias,
>
> Yes, some people here are using mqtt-c on NuttX and it is working fine.
>
> It needs some clean-up to be submitted to apps/
>
> BR,
>
> Alan
>
> On 3/25/21, Matias N.  wrote:
>> Hi,
>> I was wondering if anyone is already using some MQTT library on NuttX. I
>> see
>> many options some of which look like potential candidates for easy
>> porting,
>> but if anyone already went through this process I would appreciate some
>> feedback.
>>
>> Thanks,
>> Matias
>

Re: mqtt library on NuttX?

[Matias N.]

Great, maybe some draft PR could be submitted?

Regarding SSL, is it required to build? Maybe it can be initially integrated 
without
SSL support?

Best,
Matias

On Thu, Mar 25, 2021, at 14:13, Alan Carvalho de Assis wrote:
> Hi Matias,
> 
> Yes, some people here are using mqtt-c on NuttX and it is working fine.
> 
> It needs some clean-up to be submitted to apps/
> 
> BR,
> 
> Alan
> 
> On 3/25/21, Matias N. mailto:matias%40imap.cc>> wrote:
> > Hi,
> > I was wondering if anyone is already using some MQTT library on NuttX. I see
> > many options some of which look like potential candidates for easy porting,
> > but if anyone already went through this process I would appreciate some
> > feedback.
> >
> > Thanks,
> > Matias
> 

Re: mqtt library on NuttX?

[Abdelatif Guettouche]

Someone was asking the other day on Linkedin, so I pushed this:
https://github.com/Ouss4/MQTTC_NuttX

> Regarding SSL, is it required to build? Maybe it can be initially integrated 
> without
SSL support?

You can use it with no SSL support.  But MQTT-C supports multiple
crypto libraries, mbedTLS being one of them, I guess it was
contributed by Yamamoto.  I used mbedTLS + MQTT-C before as well.

On Thu, Mar 25, 2021 at 6:23 PM Matias N.  wrote:
>
> Great, maybe some draft PR could be submitted?
>
> Regarding SSL, is it required to build? Maybe it can be initially integrated 
> without
> SSL support?
>
> Best,
> Matias
>
> On Thu, Mar 25, 2021, at 14:13, Alan Carvalho de Assis wrote:
> > Hi Matias,
> >
> > Yes, some people here are using mqtt-c on NuttX and it is working fine.
> >
> > It needs some clean-up to be submitted to apps/
> >
> > BR,
> >
> > Alan
> >
> > On 3/25/21, Matias N. mailto:matias%40imap.cc>> wrote:
> > > Hi,
> > > I was wondering if anyone is already using some MQTT library on NuttX. I 
> > > see
> > > many options some of which look like potential candidates for easy 
> > > porting,
> > > but if anyone already went through this process I would appreciate some
> > > feedback.
> > >
> > > Thanks,
> > > Matias
> >

Re: Sleep Resolution

[Xiang Xiao]

On Thu, Mar 25, 2021 at 5:25 AM Grr  wrote:

> Why not use msec & usec delays?
>
> Because the need is nsec delays
>
>
Ok, I understand.


> My question is:
>
> Why not add a portable, general purpose nsec delay function to Nuttx?
>
>
1nsec means 1GHz, it is very hard to achieve the required accuracy even
with the high end CPU. But since the standard defines nano_sleep, up_ndelay
looks not so unreasonable.


> El mié, 24 mar 2021 a las 22:34, Xiang Xiao ()
> escribió:
>
> > Another way to avoid the calibration is to reuse the hardware timer in
> the
> > busy loop:
> >
> >
> https://github.com/apache/incubator-nuttx/blob/master/drivers/timers/arch_alarm.c#L60-L74
> >
> >
> https://github.com/apache/incubator-nuttx/blob/master/drivers/timers/arch_timer.c#L122-L144
> >
> > On Thu, Mar 25, 2021 at 11:42 AM Gregory Nutt 
> wrote:
> >
> > >
> > > > Why not call up_udelay or up_mdelay? The arch/soc should provide a
> best
> > > > implementation for you.
> > >
> > > I was wondering that too.
> > >
> > > Also, as a side note, it is very important to calibrate the delay loop
> > > using in those functions.  If the delay loop is properly calibrated,
> > > these can be very accurate (but I suspect most people no longer
> > > calibrate the delay loop).
> > >
> > > There is an app at apps/examples/calib_udelay that can be used to do
> > that.
> > >
> > >
> >
>

Re: mqtt library on NuttX?

[Matias N.]

On Thu, Mar 25, 2021, at 15:02, Abdelatif Guettouche wrote:
> Someone was asking the other day on Linkedin, so I pushed this:
> https://github.com/Ouss4/MQTTC_NuttX

Great, thanks! I see the wrapper app is quite simple. Could we submit it
to nuttx apps repo?

> 
> > Regarding SSL, is it required to build? Maybe it can be initially 
> > integrated without
> SSL support?
> 
> You can use it with no SSL support.  But MQTT-C supports multiple
> crypto libraries, mbedTLS being one of them, I guess it was
> contributed by Yamamoto.  I used mbedTLS + MQTT-C before as well.

Sure, if the mbedTLS PR gets finished it would be a good combination.

Best,
Matias

> 
> On Thu, Mar 25, 2021 at 6:23 PM Matias N.  > wrote:
> >
> > Great, maybe some draft PR could be submitted?
> >
> > Regarding SSL, is it required to build? Maybe it can be initially 
> > integrated without
> > SSL support?
> >
> > Best,
> > Matias
> >
> > On Thu, Mar 25, 2021, at 14:13, Alan Carvalho de Assis wrote:
> > > Hi Matias,
> > >
> > > Yes, some people here are using mqtt-c on NuttX and it is working fine.
> > >
> > > It needs some clean-up to be submitted to apps/
> > >
> > > BR,
> > >
> > > Alan
> > >
> > > On 3/25/21, Matias N. mailto:matias%40imap.cc> 
> > > > wrote:
> > > > Hi,
> > > > I was wondering if anyone is already using some MQTT library on NuttX. 
> > > > I see
> > > > many options some of which look like potential candidates for easy 
> > > > porting,
> > > > but if anyone already went through this process I would appreciate some
> > > > feedback.
> > > >
> > > > Thanks,
> > > > Matias
> > >
> 

Re: mqtt library on NuttX?

[Alan Carvalho de Assis]

Hi Matias,

On 3/25/21, Matias N.  wrote:
>
>
> On Thu, Mar 25, 2021, at 15:02, Abdelatif Guettouche wrote:
>> Someone was asking the other day on Linkedin, so I pushed this:
>> https://github.com/Ouss4/MQTTC_NuttX
>
> Great, thanks! I see the wrapper app is quite simple. Could we submit it
> to nuttx apps repo?
>

Yes, please!

>>
>> > Regarding SSL, is it required to build? Maybe it can be initially
>> > integrated without
>> SSL support?
>>
>> You can use it with no SSL support.  But MQTT-C supports multiple
>> crypto libraries, mbedTLS being one of them, I guess it was
>> contributed by Yamamoto.  I used mbedTLS + MQTT-C before as well.
>
> Sure, if the mbedTLS PR gets finished it would be a good combination.
>

Yes, I don't see Brennan around during this and last week, I hope he is fine!

BR,

Alan

Re: Sleep Resolution

[Grr]

> 1nsec means 1GHz, it is very hard to achieve the required accuracy even
> with the high end CPU. But since the standard defines nano_sleep, up_ndelay
> looks not so unreasonable.
>

I don't mean 1 ns

I mean delays in the order of _dozens_ of ns

100 MHz (a very reasonable frequency nowadays) means 10 ns per cycle, so a
standard function that eases the task of delaying a few cycles for things
like hold times is a _very_ needed tool


> > El mié, 24 mar 2021 a las 22:34, Xiang Xiao ( >)
> > escribió:
> >
> > > Another way to avoid the calibration is to reuse the hardware timer in
> > the
> > > busy loop:
> > >
> > >
> >
> https://github.com/apache/incubator-nuttx/blob/master/drivers/timers/arch_alarm.c#L60-L74
> > >
> > >
> >
> https://github.com/apache/incubator-nuttx/blob/master/drivers/timers/arch_timer.c#L122-L144
> > >
> > > On Thu, Mar 25, 2021 at 11:42 AM Gregory Nutt 
> > wrote:
> > >
> > > >
> > > > > Why not call up_udelay or up_mdelay? The arch/soc should provide a
> > best
> > > > > implementation for you.
> > > >
> > > > I was wondering that too.
> > > >
> > > > Also, as a side note, it is very important to calibrate the delay
> loop
> > > > using in those functions.  If the delay loop is properly calibrated,
> > > > these can be very accurate (but I suspect most people no longer
> > > > calibrate the delay loop).
> > > >
> > > > There is an app at apps/examples/calib_udelay that can be used to do
> > > that.
> > > >
> > > >
> > >
> >
>

Re: Sleep Resolution

[Nathan Hartman]

On Thu, Mar 25, 2021 at 2:22 PM Grr  wrote:

> > 1nsec means 1GHz, it is very hard to achieve the required accuracy even
> > with the high end CPU. But since the standard defines nano_sleep,
> up_ndelay
> > looks not so unreasonable.
> >
>
> I don't mean 1 ns
>
> I mean delays in the order of _dozens_ of ns
>
> 100 MHz (a very reasonable frequency nowadays) means 10 ns per cycle, so a
> standard function that eases the task of delaying a few cycles for things
> like hold times is a _very_ needed tool



What about the ASM function Fotis shared earlier in this thread?

If you're not on an ARM CPU it would just need translation of the ASM
instructions for that CPU.

I recommend to make macros that given a delay time in ns will take into
account the delay loop calibration Greg mentioned, and run the ASM delay
loop. That way, there is only one calibration to make for ns, us, and ms.

Cheers,
Nathan

Re: Sleep Resolution

[Arie de Muijnck]

A trick I often used was writing to the volatile (!) CS pin control 
register twice (or more).

The extra writes change nothing, but provide the tiny delay.
The compilers never optimized the extra writes away.
An obj file dumper and scope are handy to check the actual generated 
code and delay.


Arie

On 2021-03-24 18:08, Grr wrote:

Thank you very much for your response

What I'm trying to do is to generate hold and disable times for SPI CS,
which should be about 50 ns

I started by an empty for loop but it seems optimization gets rid of it (I
haven't researched the issue properly). Then I thought a proper function
would be better but got stuck in that expression "sleep resolution"

For that scale (10 SYSCLK cycles), a loop is probably OK but I wanted to
make sure there's not a more appropriate system tool

El mié, 24 mar 2021 a las 10:46, Sara da Cunha Monteiro de Souza (<
saramonteirosouz...@gmail.com>) escribió:


Hi Grr,

I have never needed to use this function neither this range (ns).
But I used the usleep function which resolution is defined as
CONFIG_USEC_PER_TICK.
But maybe, in your case, for such range, you should consider using a
hardware timer or a Timer Hook.
Take a look at this wiki:
https://cwiki.apache.org/confluence/display/NUTTX/Short+Time+Delays

Sara

Em qua., 24 de mar. de 2021 às 13:37, Grr  escreveu:


Hello to all.

Looking for the right way to create a _very_ short delay (10-100 ns), I
found clock_nanosleep, whose description says:

"The suspension time caused by this function may be longer than requested
because the argument value is rounded up to an integer multiple of the
sleep resolution"

What is the sleep resolution and where/how is defined?

TIA
Grr

Re: mqtt library on NuttX?

[Matias N.]

On Thu, Mar 25, 2021, at 15:21, Alan Carvalho de Assis wrote:
> Hi Matias,
> 
> On 3/25/21, Matias N. mailto:matias%40imap.cc>> wrote:
> >
> >
> > On Thu, Mar 25, 2021, at 15:02, Abdelatif Guettouche wrote:
> >> Someone was asking the other day on Linkedin, so I pushed this:
> >> https://github.com/Ouss4/MQTTC_NuttX
> >
> > Great, thanks! I see the wrapper app is quite simple. Could we submit it
> > to nuttx apps repo?
> >
> 
> Yes, please!

The copyright header is from Espressif so I guess it would be best if someone 
at Espressif can submit it
(not sure if it would require a SGA).

> >>
> >> > Regarding SSL, is it required to build? Maybe it can be initially
> >> > integrated without
> >> SSL support?
> >>
> >> You can use it with no SSL support.  But MQTT-C supports multiple
> >> crypto libraries, mbedTLS being one of them, I guess it was
> >> contributed by Yamamoto.  I used mbedTLS + MQTT-C before as well.
> >
> > Sure, if the mbedTLS PR gets finished it would be a good combination.
> >
> 
> Yes, I don't see Brennan around during this and last week, I hope he is fine!
> 
> BR,
> 
> Alan
> 

Re: mqtt library on NuttX?

[Alan Carvalho de Assis]

On 3/25/21, Matias N.  wrote:
>
>
> On Thu, Mar 25, 2021, at 15:21, Alan Carvalho de Assis wrote:
>> Hi Matias,
>>
>> On 3/25/21, Matias N. mailto:matias%40imap.cc>> wrote:
>> >
>> >
>> > On Thu, Mar 25, 2021, at 15:02, Abdelatif Guettouche wrote:
>> >> Someone was asking the other day on Linkedin, so I pushed this:
>> >> https://github.com/Ouss4/MQTTC_NuttX
>> >
>> > Great, thanks! I see the wrapper app is quite simple. Could we submit
>> > it
>> > to nuttx apps repo?
>> >
>>
>> Yes, please!
>
> The copyright header is from Espressif so I guess it would be best if
> someone at Espressif can submit it
> (not sure if it would require a SGA).
>

It is not a code from IDF, it was Abdelatif whom added it :-)

But you are right, maybe it is better if we submit it because there is
an Espressif copyright on it.

BR,

Alan

Re: mqtt library on NuttX?

[Abdelatif Guettouche]

Espressif has already signed an SGA, licensing shouldn't be an issue.
That said, I can submit it later if you guys want.
One question: where do we put the library?
A new "mqtt" folder?

On Thu, Mar 25, 2021 at 10:59 PM Alan Carvalho de Assis
 wrote:
>
> On 3/25/21, Matias N.  wrote:
> >
> >
> > On Thu, Mar 25, 2021, at 15:21, Alan Carvalho de Assis wrote:
> >> Hi Matias,
> >>
> >> On 3/25/21, Matias N. mailto:matias%40imap.cc>> wrote:
> >> >
> >> >
> >> > On Thu, Mar 25, 2021, at 15:02, Abdelatif Guettouche wrote:
> >> >> Someone was asking the other day on Linkedin, so I pushed this:
> >> >> https://github.com/Ouss4/MQTTC_NuttX
> >> >
> >> > Great, thanks! I see the wrapper app is quite simple. Could we submit
> >> > it
> >> > to nuttx apps repo?
> >> >
> >>
> >> Yes, please!
> >
> > The copyright header is from Espressif so I guess it would be best if
> > someone at Espressif can submit it
> > (not sure if it would require a SGA).
> >
>
> It is not a code from IDF, it was Abdelatif whom added it :-)
>
> But you are right, maybe it is better if we submit it because there is
> an Espressif copyright on it.
>
> BR,
>
> Alan

Re: mqtt library on NuttX?

[Alan Carvalho de Assis]

I think it is better to put it at apps/netutils/mqttc

On 3/25/21, Abdelatif Guettouche  wrote:
> Espressif has already signed an SGA, licensing shouldn't be an issue.
> That said, I can submit it later if you guys want.
> One question: where do we put the library?
> A new "mqtt" folder?
>
> On Thu, Mar 25, 2021 at 10:59 PM Alan Carvalho de Assis
>  wrote:
>>
>> On 3/25/21, Matias N.  wrote:
>> >
>> >
>> > On Thu, Mar 25, 2021, at 15:21, Alan Carvalho de Assis wrote:
>> >> Hi Matias,
>> >>
>> >> On 3/25/21, Matias N. mailto:matias%40imap.cc>>
>> >> wrote:
>> >> >
>> >> >
>> >> > On Thu, Mar 25, 2021, at 15:02, Abdelatif Guettouche wrote:
>> >> >> Someone was asking the other day on Linkedin, so I pushed this:
>> >> >> https://github.com/Ouss4/MQTTC_NuttX
>> >> >
>> >> > Great, thanks! I see the wrapper app is quite simple. Could we
>> >> > submit
>> >> > it
>> >> > to nuttx apps repo?
>> >> >
>> >>
>> >> Yes, please!
>> >
>> > The copyright header is from Espressif so I guess it would be best if
>> > someone at Espressif can submit it
>> > (not sure if it would require a SGA).
>> >
>>
>> It is not a code from IDF, it was Abdelatif whom added it :-)
>>
>> But you are right, maybe it is better if we submit it because there is
>> an Espressif copyright on it.
>>
>> BR,
>>
>> Alan
>

How to ensure HEAP will not overlap static DMA buffer?

[Nathan Hartman]

tl;dr: How do I statically allocate DMA buffers and prevent the heap
from overlapping them?

Details: On STM32H7, BDMA can only reach SRAM4 (64 KB starting at
0x3800:). The armv7m DCache line size means the buffers must be
allocated on a cache line boundary. So a DMA buffer must meet 2
requirements: (1) be in SRAM4, and (2) be aligned and padded to 32
byte increments.

Ok, I can do this easily with:

static volatile uint8_t my_bdma_buf[128] __attribute__ ((section
(".sram4"))) __attribute__ ((aligned (32)));

or equivalent.

But then the heap will overlap this memory and my buffer will be
clobbered because arch/arm/src/stm32h7/stm32_allocateheap.c
arm_addregion() does this:

addregion (SRAM4_START, SRAM4_END - SRAM4_START, "SRAM4");

Looking into it, I see that in arch/arm/src/stm32h7/stm32_spi.c,
g_spi6_txbuf[] and g_spi6_rxbuf[] are declared like this:

static uint8_t g_spi6_txbuf[SPI6_DMABUFSIZE_ADJUSTED]
SPI6_DMABUFSIZE_ALGN locate_data(".sram4");
static uint8_t g_spi6_rxbuf[SPI6_DMABUFSIZE_ADJUSTED]
SPI6_DMABUFSIZE_ALGN locate_data(".sram4");

So they will suffer that same problem. (I'm pretty sure that's a bug,
unless I missed something.)

I discovered this the hard way, i.e., on my board, NSH suddenly
wouldn't start. In reality, it does start but it turns out that when
it tries to print the greeting message, it fails on the very first
character ('\n') and exits. Why? I single-stepped all the way into the
guts of the serial logic, and found that in fs/vfs/fs_write.c,
file_write(), it fetches the inode and tests if it's valid (!inode ||
!inode->u.i_ops || !inode->u.i_ops->write) or returns -EBADF. That's
where it fails, because it seems that the inode is allocated at
0x3800:0070, right on top of my BDMA buffers!

I don't know which question to ask, but I think it's one of these:

(1) Is there a standard(-ish) way to allocate a buffer that is both
aligned to a specified boundary AND in a specified region of memory?

(2) Is there a standard way to make a hole in the heap so that nothing
else in NuttX will overwrite the DMA buffer?

(Yes, I see that I can fiddle with CONFIG_MM_REGIONS, but then only
the 512 KB of AXI SRAM will be in the heap, and none of the other
regions, SRAM1,2,3, etc., and I don't think I want that.)

Thanks,
Nathan

Re: How to ensure HEAP will not overlap static DMA buffer?

[Gregory Nutt]

Just don't add it to the primary heap:  Add the region below and the 
region above the DMA buffers with two calls to mm_addregion().


addregion (DMABUF_END, SRAM4_END - DMABUF_END, "SRAM4-A");

addregion (SRAM4_START, DMABUF_START- SRAM4_START, "SRAM4-B");

You can also create a different heap for the DMA region (or probably 
better, and granule allocator for the DMA region.  See mm/mm_gram.)  Or 
just use the DMA region directly if you don't need allocations from it.  
For big things like frame buffers, I usually put them at the beginning 
or end of the memory region to minimize the number of regions.


addregion (SRAM4_START, SRAM4_END - SRAM4_START - 128, "SRAM4");

You can see how that was done for most boards that need framebuffers 
like SAMA5Dx (the boards use Kconfig settings to determine the size of 
the memory regions).


This DMA buffer is rather tiny.

I suppose memalign() won't work because you can't guarantee that the 
memory lies in SRAM4.


On 3/25/2021 5:27 PM, Nathan Hartman wrote:

tl;dr: How do I statically allocate DMA buffers and prevent the heap
from overlapping them?

Details: On STM32H7, BDMA can only reach SRAM4 (64 KB starting at
0x3800:). The armv7m DCache line size means the buffers must be
allocated on a cache line boundary. So a DMA buffer must meet 2
requirements: (1) be in SRAM4, and (2) be aligned and padded to 32
byte increments.

Ok, I can do this easily with:

static volatile uint8_t my_bdma_buf[128] __attribute__ ((section
(".sram4"))) __attribute__ ((aligned (32)));

or equivalent.

But then the heap will overlap this memory and my buffer will be
clobbered because arch/arm/src/stm32h7/stm32_allocateheap.c
arm_addregion() does this:

addregion (SRAM4_START, SRAM4_END - SRAM4_START, "SRAM4");

Looking into it, I see that in arch/arm/src/stm32h7/stm32_spi.c,
g_spi6_txbuf[] and g_spi6_rxbuf[] are declared like this:

static uint8_t g_spi6_txbuf[SPI6_DMABUFSIZE_ADJUSTED]
SPI6_DMABUFSIZE_ALGN locate_data(".sram4");
static uint8_t g_spi6_rxbuf[SPI6_DMABUFSIZE_ADJUSTED]
SPI6_DMABUFSIZE_ALGN locate_data(".sram4");

So they will suffer that same problem. (I'm pretty sure that's a bug,
unless I missed something.)

I discovered this the hard way, i.e., on my board, NSH suddenly
wouldn't start. In reality, it does start but it turns out that when
it tries to print the greeting message, it fails on the very first
character ('\n') and exits. Why? I single-stepped all the way into the
guts of the serial logic, and found that in fs/vfs/fs_write.c,
file_write(), it fetches the inode and tests if it's valid (!inode ||
!inode->u.i_ops || !inode->u.i_ops->write) or returns -EBADF. That's
where it fails, because it seems that the inode is allocated at
0x3800:0070, right on top of my BDMA buffers!

I don't know which question to ask, but I think it's one of these:

(1) Is there a standard(-ish) way to allocate a buffer that is both
aligned to a specified boundary AND in a specified region of memory?

(2) Is there a standard way to make a hole in the heap so that nothing
else in NuttX will overwrite the DMA buffer?

(Yes, I see that I can fiddle with CONFIG_MM_REGIONS, but then only
the 512 KB of AXI SRAM will be in the heap, and none of the other
regions, SRAM1,2,3, etc., and I don't think I want that.)

Thanks,
Nathan

Re: How to ensure HEAP will not overlap static DMA buffer?

[Nathan Hartman]

On Thu, Mar 25, 2021 at 7:54 PM Gregory Nutt  wrote:
>
> Just don't add it to the primary heap:  Add the region below and the
> region above the DMA buffers with two calls to mm_addregion().
>
> addregion (DMABUF_END, SRAM4_END - DMABUF_END, "SRAM4-A");
>
> addregion (SRAM4_START, DMABUF_START- SRAM4_START, "SRAM4-B");

Where should I call mm_addregion() from?

Right now, arm_addregion() in
arch/arm/src/stm32h7/stm32_allocateheap.c is unconditionally setting
up heap regions. I think that customizing it for my particular
situation is an ugly hack.

Or, I can leave the OS alone, and in my board config, set
CONFIG_MM_REGIONS = 1 so arm_addregion() does nothing; then from
somewhere (board_late_initialize()?) call mm_addregion() to customize
other regions. This also feels like an ugly hack to me.

Option 3, I add a new Kconfig to exclude SRAM4 from the heap, as is
already being done for DTCM RAM with CONFIG_STM32H7_DTCMEXCLUDE. This
seems more sensible than above, because right now, any STM32H7 build
that uses SPI6 with BDMA will have its DMA buffers (g_spi6_txbuf and
g_spi6_rxbuf) clobbering heap-allocated objects. If I add a new
Kconfig to exclude SRAM4 from the heap, I could also add compile-time
logic in arch/arm/src/stm32h7/stm32_spi.c to trigger an #error
directive if CONFIG_STM32H7_SPI6 and CONFIG_STM32H7_SPI6_DMA_BUFFER
are defined while SRAM4 is included in the heap. That could save some
poor soul a big debugging session; but it will not help if someone
(like me) creates their own DMA buffers.

Option 4, I like the Granule Allocator option; If I understand
correctly, to use the granule allocator, I need to exclude SRAM4 from
the heap (like option 3) + create a g_dmaheap in .sram4, and init the
granule allocator from board init code. Is that correct?

Other notes:

I think SPI1 thru SPI5 are unaffected because (I think) their static
allocations end up in .bss and automatically excluded from all heaps;
but because g_spi6_txbuf and g_spi6_rxbuf have locate_data(".sram4"),
they end up in the heap.

We might have other __attribute__ ((section (".insert_name_here")))
buffers in other files that suffer the same problem.

I looked at SAMA5Dx as you suggested... I see in the README of
boards/arm/sama5/sama5d3x-ek/README.txt the following ominous warning:

  Care must be used applied these RAM locations; the graphics
  configurations use SDRAM in an incompatible way to set aside
  LCD framebuffers.

It seems that's the exact issue I've run into.

Thanks,
Nathan

Request Peripheral Configuration for Nucleo-H743ZI2 Board

[Ganesh Kardile]

Hi,

We are planning to port Nuttx on 'Nucleo-H743ZI2' development board. We need 
support for the below peripherals configuration.

  *   USB OTG FS Host (Mass storage)
  *   Ethernet
  *   SD Card interface via both SPI and SDIO

The config file with the above peripherals support would speed our development 
activity.

Best Regards,
Ganesh Kardile
L&T TECHNOLOGY SERVICES LIMITED
Building No 1, 8th Floor, Mindspace SEZ,
Airoli East, Thane - Belapur Road, Navi Mumbai - 400708


Tel: +91 22 6105 8044 | Mobile: +91 9819226306
www.LTTS.com |
[cid:image005.jpg@01D209BF.B0FF4A90]


L&T Technology Services Ltd

www.LTTS.com

L&T Technology Services Limited (LTTS) is committed to safeguard your data 
privacy. For more information to view our commitment towards data privacy under 
GDPR, please visit the privacy policy on our website www.Ltts.com. This Email 
may contain confidential or privileged information for the intended recipient 
(s). If you are not the intended recipient, please do not use or disseminate 
the information, notify the sender and delete it from your system.

Re: How to ensure HEAP will not overlap static DMA buffer?

[Gregory Nutt]

Just don't add it to the primary heap:  Add the region below and the
region above the DMA buffers with two calls to mm_addregion().

addregion (DMABUF_END, SRAM4_END - DMABUF_END, "SRAM4-A");

addregion (SRAM4_START, DMABUF_START- SRAM4_START, "SRAM4-B");

Where should I call mm_addregion() from?

up_addregion().  It is normally in the same file as up_allocateheap()

Right now, arm_addregion() in
arch/arm/src/stm32h7/stm32_allocateheap.c is unconditionally setting
up heap regions. I think that customizing it for my particular
situation is an ugly hack.


It is customized in all MCUs that have complex RAM maps.  Using with a 
Kconfig setting that defines the start and end of RAM regions.  So only 
the configured part of the RAM region is added to the heap.


I don't think the is ugly in the C code.  It is just a change in the 
naming so that the start and size start with CONFIG_



Or, I can leave the OS alone, and in my board config, set
CONFIG_MM_REGIONS = 1 so arm_addregion() does nothing; then from
somewhere (board_late_initialize()?) call mm_addregion() to customize
other regions. This also feels like an ugly hack to me.

Seems a little uglier only because other boards would have to do the same.

Option 3, I add a new Kconfig to exclude SRAM4 from the heap, as is
already being done for DTCM RAM with CONFIG_STM32H7_DTCMEXCLUDE.

Yep.  I should have read futher before responding.

Option 4, I like the Granule Allocator option; If I understand
correctly, to use the granule allocator, I need to exclude SRAM4 from
the heap (like option 3) + create a g_dmaheap in .sram4, and init the
granule allocator from board init code. Is that correct?
Yes, there should be some good examples for STM32.  The granule 
allocator is nice because you can configure it so that each DMA region 
is automatically aligned to the cache line size and automatically forced 
to be multiples of the cache line size in size.

I think SPI1 thru SPI5 are unaffected because (I think) their static
allocations end up in .bss and automatically excluded from all heaps;
but because g_spi6_txbuf and g_spi6_rxbuf have locate_data(".sram4"),
they end up in the heap.

We might have other __attribute__ ((section (".insert_name_here")))
buffers in other files that suffer the same problem.

Using the granule allocate would solve that too.

Re: Request Peripheral Configuration for Nucleo-H743ZI2 Board

[Brennan Ashton]

This mostly exists under the H743ZI configuration. I made probably the
wrong choice and combined the both rev1 and rev2 in that config and there
is a board config to select which rev since they have subtle but important
pinout difference.  The rev2 is like the other H7xx nuclei board while the
rev1 is more like the F4xx boards.  I don't know if I tested sdio, but
ethernet and usb device work. USB host might need a little more work.

Maybe I'll take another stab at cleaning up that board and breaking it out
like I should have done in the first place.


On Thu, Mar 25, 2021, 10:01 PM Ganesh Kardile 
wrote:

> Hi,
>
>
>
> We are planning to port Nuttx on ‘*Nucleo-H743ZI2*’ development board. We
> need support for the below peripherals configuration.
>
>- USB OTG FS Host (Mass storage)
>- Ethernet
>- SD Card interface via both SPI and SDIO
>
>
>
> The config file with the above peripherals support would speed our
> development activity.
>
>
>
> Best Regards,
>
> *Ganesh Kardile*
>
> *L&T TECHNOLOGY SERVICES LIMITED*
>
> Building No 1, 8th Floor, Mindspace SEZ,
>
> Airoli East, Thane – Belapur Road, Navi Mumbai - 400708
>
> 
>
>
>
> Tel: +91 22 6105 8044 | Mobile: +91 9819226306
>
> www.LTTS.com |
>
> [image: cid:image005.jpg@01D209BF.B0FF4A90]
> 
>
>
>
> *L&T Technology Services Ltd*
>
> www.LTTS.com
>
> L&T Technology Services Limited (LTTS) is committed to safeguard your data
> privacy. For more information to view our commitment towards data privacy
> under GDPR, please visit the privacy policy on our website www.Ltts.com.
> This Email may contain confidential or privileged information for the
> intended recipient (s). If you are not the intended recipient, please do
> not use or disseminate the information, notify the sender and delete it
> from your system.
>