MCU/Board with WiFi, BT and USB Host

[Petro Karashchenko]

Hello,

I'm looking for an MCU or better a development board that has WiFi, BT and
USB host capabilities. Can anybody give me advice for that? I need to
connect a CDC ACM device to that USB, so maybe there are some alternatives
that can be used (there is a device that exposes its functionality via USB
to serial), so I need to communicate with that from my device.
If that MCU is supported by NuttX then it would be super fantastic!

Best regards,
Petro

Re: MCU/Board with WiFi, BT and USB Host

[Alan C. Assis]

Hi Petro,

You can use ESP32-S2 or ESP32-S3.

Currently the USB Host support is not integrated on mainline yet, but
we (Espressif) have customers that are developing products with
ESP32-S3 with NuttX and USB.

So USB Host support will arrive on NuttX upstream very soon.

BR,

Alan

On 4/20/23, Petro Karashchenko  wrote:
> Hello,
>
> I'm looking for an MCU or better a development board that has WiFi, BT and
> USB host capabilities. Can anybody give me advice for that? I need to
> connect a CDC ACM device to that USB, so maybe there are some alternatives
> that can be used (there is a device that exposes its functionality via USB
> to serial), so I need to communicate with that from my device.
> If that MCU is supported by NuttX then it would be super fantastic!
>
> Best regards,
> Petro
>

Re: MCU/Board with WiFi, BT and USB Host

[Gregory Nutt]

I'm looking for an MCU or better a development board that has WiFi, BT and
USB host capabilities. Can anybody give me advice for that? I need to
connect a CDC ACM device to that USB, so maybe there are some alternatives
that can be used (there is a device that exposes its functionality via USB
to serial), so I need to communicate with that from my device.
If that MCU is supported by NuttX then it would be super fantastic!
My only recommendation is that if you depend on good USB host 
performance, you should avoid MCUs that have their own, non-standard, 
so-called "mini" USB hosts.  The ones that I have used do not work well 
with CDC ACM host.  Make sure the MCU supports a quality, standard OHCI 
or EHCI host interface.

Re: MCU/Board with WiFi, BT and USB Host

[Alan C. Assis]

Hi Mr. Zou,

PinePhone is a nice idea, but I'm afraid that WiFi is not supported yet too.

Mr. Lup, could you please confirm/deny my suspect?

BR,

Alan

On 4/20/23, fft  wrote:
> I think PinePhone is a great choice
>
>
>
> -- Original --
> From:  "Petro Karashchenko" Date:  Thu, Apr 20, 2023 09:25 PM
> To:  "dev"
> Subject:  MCU/Board with WiFi, BT and USB Host
>
>  
>
> Hello,
>
> I'm looking for an MCU or better a development board that has WiFi, BT and
> USB host capabilities. Can anybody give me advice for that? I need to
> connect a CDC ACM device to that USB, so maybe there are some alternatives
> that can be used (there is a device that exposes its functionality via USB
> to serial), so I need to communicate with that from my device.
> If that MCU is supported by NuttX then it would be super fantastic!
>
> Best regards,
> Petro

Re: MCU/Board with WiFi, BT and USB Host

[Tomek CEDRO]

On Thu, Apr 20, 2023, 15:52 Alan C. Assis <> wrote:

> Hi Petro,
>
> You can use ESP32-S2 or ESP32-S3.
>
> Currently the USB Host support is not integrated on mainline yet, but
> we (Espressif) have customers that are developing products with
> ESP32-S3 with NuttX and USB.
>
> So USB Host support will arrive on NuttX upstream very soon.


Hey there Alan, I saw your initial support for ESP32-C6 that is RISC-V
based, thank you, does that chip have full USB (device? host? otg?) support
and full documentation of the USB block? :-)

This sounds even better than ESP32-C3 :-)

--
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info

Re: MCU/Board with WiFi, BT and USB Host

[Alan C. Assis]

Hi Tomek,

On 4/20/23, Tomek CEDRO  wrote:
>
> Hey there Alan, I saw your initial support for ESP32-C6 that is RISC-V
> based, thank you, does that chip have full USB (device? host? otg?) support
> and full documentation of the USB block? :-)
>
> This sounds even better than ESP32-C3 :-)
>

No, ESP32-C6 has only the USB_JTAG_SERIAL just like ESP32-C3.

In fact ESP32-C6 is similar to ESP32-C3, but with WiFi-6 support,
ideal for low power applications.

BR,

Alan

Re: MCU/Board with WiFi, BT and USB Host

[Tim Hardisty]

What sort processing power? Memory? Peripherals?

SAMA5D27 (not that I’m biased lol) perhaps? ATSAMA5D27-WLSOM1 eval board has 
what you need but might be over the top? USB host/device works and you can do 
OTG/DRP on a custom board and it should be more than capable of doing CDC-ACM I 
would have thought?

From: Petro Karashchenko 
Reply to: "dev@nuttx.apache.org" 
Date: Thursday, 20 April 2023 at 14:25
To: "dev@nuttx.apache.org" 
Subject: MCU/Board with WiFi, BT and USB Host

Hello, I'm looking for an MCU or better a development board that has WiFi, BT 
and USB host capabilities. Can anybody give me advice for that? I need to 
connect a CDC ACM device to that USB, so maybe there are some alternatives that 
can be used (there is a device that exposes its functionality via USB to 
serial), so I need to communicate with that from my device. If that MCU is 
supported by NuttX then it would be super fantastic! Best regards, Petro

Re: MCU/Board with WiFi, BT and USB Host

[Alan C. Assis]

Hi Tim,

Really nice board!

Do you know if Microchip is planing to port ATWILC3000-MR110UA
WiFi/BLE chip to NuttX?

Should be nice to have a companion to BCM43 at drivers/wireless/ieee80211/

BR,

Alan

On 4/20/23, Tim Hardisty  wrote:
> What sort processing power? Memory? Peripherals?
>
> SAMA5D27 (not that I’m biased lol) perhaps? ATSAMA5D27-WLSOM1 eval board has
> what you need but might be over the top? USB host/device works and you can
> do OTG/DRP on a custom board and it should be more than capable of doing
> CDC-ACM I would have thought?
>
> From: Petro Karashchenko 
> Reply to: "dev@nuttx.apache.org" 
> Date: Thursday, 20 April 2023 at 14:25
> To: "dev@nuttx.apache.org" 
> Subject: MCU/Board with WiFi, BT and USB Host
>
> Hello, I'm looking for an MCU or better a development board that has WiFi,
> BT and USB host capabilities. Can anybody give me advice for that? I need to
> connect a CDC ACM device to that USB, so maybe there are some alternatives
> that can be used (there is a device that exposes its functionality via USB
> to serial), so I need to communicate with that from my device. If that MCU
> is supported by NuttX then it would be super fantastic! Best regards, Petro
>

Re: MCU/Board with WiFi, BT and USB Host

[Tim Hardisty]

I don’t know if Microchip do NuttX (or other RTOS) porting work? I would assume 
not so would need support from the NuttX community.

My longer term plan is to work on USB support for Bluetooth dongles rather than 
dedicated module support as that – should – avoid the need for Bluetooth SIG 
accreditation and fees. Don’t quote me on that!

From: "Alan C. Assis" 
Reply to: "dev@nuttx.apache.org" 
Date: Thursday, 20 April 2023 at 20:08
To: "dev@nuttx.apache.org" 
Subject: Re: MCU/Board with WiFi, BT and USB Host

Hi Tim,

Really nice board!

Do you know if Microchip is planing to port ATWILC3000-MR110UA
WiFi/BLE chip to NuttX?

Should be nice to have a companion to BCM43 at drivers/wireless/ieee80211/

BR,

Alan

On 4/20/23, Tim Hardisty mailto:t...@hardisty.co.uk>> 
wrote:
What sort processing power? Memory? Peripherals?

SAMA5D27 (not that I’m biased lol) perhaps? ATSAMA5D27-WLSOM1 eval board has
what you need but might be over the top? USB host/device works and you can
do OTG/DRP on a custom board and it should be more than capable of doing
CDC-ACM I would have thought?

From: Petro Karashchenko 
mailto:petro.karashche...@gmail.com>>
Reply to: "dev@nuttx.apache.org" 
mailto:dev@nuttx.apache.org>>
Date: Thursday, 20 April 2023 at 14:25
To: "dev@nuttx.apache.org" 
mailto:dev@nuttx.apache.org>>
Subject: MCU/Board with WiFi, BT and USB Host

Hello, I'm looking for an MCU or better a development board that has WiFi,
BT and USB host capabilities. Can anybody give me advice for that? I need to
connect a CDC ACM device to that USB, so maybe there are some alternatives
that can be used (there is a device that exposes its functionality via USB
to serial), so I need to communicate with that from my device. If that MCU
is supported by NuttX then it would be super fantastic! Best regards, Petro

Re: MCU/Board with WiFi, BT and USB Host

[Tomek CEDRO]

On Thu, Apr 20, 2023 at 9:15 PM Tim Hardisty wrote:
> My longer term plan is to work on USB support for Bluetooth dongles rather 
> than dedicated module support as that – should – avoid the need for Bluetooth 
> SIG accreditation and fees. Don’t quote me on that!

Bluetooth SIG membership is free, no?

Unless you need to certify your own custom hardware.. which is quite
expensive to design, manufacture, and certify.. this is why I found
ESP32* MINI/WROOM modules really convenient as they already have WiFi
and Bluetooth certification + devkits that you can quickly prototype
with even on a breadboard.. other SoC also have this kind of
pre-certified modules :-)

-- 
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info

Re: MCU/Board with WiFi, BT and USB Host

[Tim Hardisty]

To the best of my understanding, using a module does NOT mean you can avoid 
certification for a custom board that uses it. I am a member of the SIG and 
specifically asked this…but they do not give a 100% clear answer ☹️

> On 20 Apr 2023, at 20:38, Tomek CEDRO  wrote:
> 
> On Thu, Apr 20, 2023 at 9:15 PM Tim Hardisty wrote:
>> My longer term plan is to work on USB support for Bluetooth dongles rather 
>> than dedicated module support as that – should – avoid the need for 
>> Bluetooth SIG accreditation and fees. Don’t quote me on that!
> 
> Bluetooth SIG membership is free, no?
> 
> Unless you need to certify your own custom hardware.. which is quite
> expensive to design, manufacture, and certify.. this is why I found
> ESP32* MINI/WROOM modules really convenient as they already have WiFi
> and Bluetooth certification + devkits that you can quickly prototype
> with even on a breadboard.. other SoC also have this kind of
> pre-certified modules :-)
> 
> -- 
> CeDeROM, SQ7MHZ, http://www.tomek.cedro.info

Re: MCU/Board with WiFi, BT and USB Host

[Tomek CEDRO]

On Thu, Apr 20, 2023 at 9:42 PM Tim Hardisty wrote:
> To the best of my understanding, using a module does NOT mean you can avoid 
> certification for a custom board that uses it. I am a member of the SIG and 
> specifically asked this…but they do not give a 100% clear answer ☹️

whaaat o_O

-- 
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info

Re: MCU/Board with WiFi, BT and USB Host

[Alan C. Assis]

Tim,

Normally the certification if for the module and for the product, but
this is the FCC, CE, Anatel, etc.

Since the module is already certified, your board doesn't need to pass
for a new complete WiFi / Bluetooth certification, just some simple
electric compatibility, EMI, etc, tests.

Maybe what they are asking you is to have a Bluetooth ID for your company.

That said, I think Bluetooth SIG is not Nintendo! They will not
process you and send you to jail :-)

They just want to make sure that all BT devices are compatible.

BR,

Alan

On 4/20/23, Tim Hardisty  wrote:
> To the best of my understanding, using a module does NOT mean you can avoid
> certification for a custom board that uses it. I am a member of the SIG and
> specifically asked this…but they do not give a 100% clear answer ☹️
>
>> On 20 Apr 2023, at 20:38, Tomek CEDRO  wrote:
>>
>> On Thu, Apr 20, 2023 at 9:15 PM Tim Hardisty wrote:
>>> My longer term plan is to work on USB support for Bluetooth dongles
>>> rather than dedicated module support as that – should – avoid the need
>>> for Bluetooth SIG accreditation and fees. Don’t quote me on that!
>>
>> Bluetooth SIG membership is free, no?
>>
>> Unless you need to certify your own custom hardware.. which is quite
>> expensive to design, manufacture, and certify.. this is why I found
>> ESP32* MINI/WROOM modules really convenient as they already have WiFi
>> and Bluetooth certification + devkits that you can quickly prototype
>> with even on a breadboard.. other SoC also have this kind of
>> pre-certified modules :-)
>>
>> --
>> CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
>

Re: MCU/Board with WiFi, BT and USB Host

[Simon Filgis]

Yes, answer is not no. I heard about 10k for "registering" a product with
certified module. So no measurements, only paperwork.

I would be glad to hear that's wrong! It feels wrong definitely...

--
Ingenieurbüro-Filgis
USt-IdNr.: DE305343278
--
sent by mobile phone

Tomek CEDRO  schrieb am Do., 20. Apr. 2023, 21:51:

> On Thu, Apr 20, 2023 at 9:42 PM Tim Hardisty wrote:
> > To the best of my understanding, using a module does NOT mean you can
> avoid certification for a custom board that uses it. I am a member of the
> SIG and specifically asked this…but they do not give a 100% clear answer ☹️
>
> whaaat o_O
>
> --
> CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
>

Re: MCU/Board with WiFi, BT and USB Host

[Fotis Panagiotopoulos]

Specifically for CE and E-mark (that I am mostly experienced with), module
certifications have no value.

The complete and finished product must be certified from scratch. As a
whole. It must be able to demonstrate that it is functional (to some
degree).
So in the end, you will have to go through lab testing for EMC, RED, LVD
etc...

But modules *may* help you in this process, or may just provide you some
peace of mind (that the product will not fail an expensive lab test).

Another "trick" is to sell the product without the module (if possible) and
offer the module separately as an add-on.
This way, for example, a device may be sold without its 4G modem, avoiding
the RED certification and lowering the costs.

---

I don't know about any extra bluetooth-specific certifications though,
never done that.

On Thu, Apr 20, 2023 at 11:08 PM Simon Filgis <
si...@ingenieurbuero-filgis.de> wrote:

> Yes, answer is not no. I heard about 10k for "registering" a product with
> certified module. So no measurements, only paperwork.
>
> I would be glad to hear that's wrong! It feels wrong definitely...
>
> --
> Ingenieurbüro-Filgis
> USt-IdNr.: DE305343278
> --
> sent by mobile phone
>
> Tomek CEDRO  schrieb am Do., 20. Apr. 2023, 21:51:
>
> > On Thu, Apr 20, 2023 at 9:42 PM Tim Hardisty wrote:
> > > To the best of my understanding, using a module does NOT mean you can
> > avoid certification for a custom board that uses it. I am a member of the
> > SIG and specifically asked this…but they do not give a 100% clear answer
> ☹️
> >
> > whaaat o_O
> >
> > --
> > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
> >
>

Re: MCU/Board with WiFi, BT and USB Host

[Lee, Lup Yuen]

That's correct, NuttX on PinePhone doesn't support WiFi and BT yet.

We're still working on USB Host for PinePhone:
https://lupyuen.github.io/articles/usb3

Lup

On Thu, Apr 20, 2023 at 11:07 PM Alan C. Assis  wrote:

> Hi Mr. Zou,
>
> PinePhone is a nice idea, but I'm afraid that WiFi is not supported yet
> too.
>
> Mr. Lup, could you please confirm/deny my suspect?
>
> BR,
>
> Alan
>
> On 4/20/23, fft  wrote:
> > I think PinePhone is a great choice
> >
> >
> >
> > -- Original --
> > From:  "Petro Karashchenko" > Date:  Thu, Apr 20, 2023 09:25 PM
> > To:  "dev" >
> > Subject:  MCU/Board with WiFi, BT and USB Host
> >
> >  
> >
> > Hello,
> >
> > I'm looking for an MCU or better a development board that has WiFi, BT
> and
> > USB host capabilities. Can anybody give me advice for that? I need to
> > connect a CDC ACM device to that USB, so maybe there are some
> alternatives
> > that can be used (there is a device that exposes its functionality via
> USB
> > to serial), so I need to communicate with that from my device.
> > If that MCU is supported by NuttX then it would be super fantastic!
> >
> > Best regards,
> > Petro
>

Re: sched_lock() should be completely removed

[jun hu]

Thank you for your reply and providing additional information.
Based on your suggestion, I believe a reasonable solution about
sched_lock should be step by step.

1 Add sched_lock()'s ability to the enter_critical_section()
2 Correct the incorrect usage of sched_lock, since many places
sched_lock and enter_critical_section are used simultaneously
3 Remove the sched_lock call from userspace

Finally, change the sched_lock's name.

BR!

Gregory Nutt  于2023年4月19日周三 21:42写道：
>
>  > I think sched_lock() should be completely removed
>  > most case we can replace sched_lock() with enter_critical_section(),
>  > at the sametime we add sched_lock()'s ability to the
> enter_critical_section()
>  > we can replace sched_lock() with mutex ,sem or spinlock。
>  > directly removal
>
> I would not remove sched_lock().  I think is it very important in a real
> time system.  Most RTOSs support something like this internally.
>
> enter_critical_section() is not a replacement for sched_lock() because
> it disables interrupts and, hence, harms real time performance.
> Interrupts must be disabled as little as possible because it destroys
> deterministic OS behavior.  sched_lock(), on the other hand, has little
> or now real time performance implications if used properly.
>
> sched_lock() postpones a task from losing the CPU until sched_unlock()
> is called.  Misuses would include locking the scheduler for too long or,
> in the SMP case, misunderstanding the functionality of sched_lock() and
> assuming that it is always equivalent to a critical section.  Locking
> the scheduler for too long is probably not as damaging to performance
> has holding the critical section too long!
>
> Both are very light weight in the single CPU modes.  But in SMP,
> enter_critical_section() is huge performance pig and should be avoided
> when at all possible.  sched_lock() is much more real time friendly in SMP.
>
> Your primary complaint and the thing that no one argues with is that
> nxsched "sched_lock() is very easy to misuse and difficult to
> understand."  However, that is not a sane justification to remove an
> important OS function.  You don't have a valid, technical justification
> for doing that.
>
> However, we should address your concern (but NOT by removing
> sched_lock()).  How can be make sched_lock() more intuititive and less
> prone to miunderstanding by naive users?
>
> I think that all we can do is change the naming or perhaps modify semantics.
>
> First of all, sched_lock() is a non-standard, internal OS and should
> never be exposed to applications.  It is for the use by informed
> developers within the OS only.  The naive user should not even be aware
> that it exists.  So at a minimum, (1) it should be renamed
> nxsched_lock(), (2) the user syscall interface should be removed from
> syscall/ and include/sys, and (3) the prototype should be removed from
> include/sched.h and moved to include/nuttx/sched.h
>
> The naming could be further improved.  The name
> nxsched_disable_preemption() and nxsched_enable_preemption(), while a
> bit long, do make the functionality of the internal interfaces much
> clearer and those are the names that I would recommend.
>
>
>