1. devel@lists.zephyrproject.org
  2. Messages
   Date   
Re: AODV Based Routing Over BLE Mesh

Nashif, Anas
 

Osama,

 

Sure, can you share more details about your project and share the feature in form of a pull request on Github?

 

Thank you,

 

Anas

 

From: devel@... [mailto:devel@...] On Behalf Of Haytham Osama
Sent: Wednesday, July 18, 2018 10:01 AM
To: devel@...
Cc: Khaled Elsayed <khaled@...>; rehamtarekahmed@...; Ahmed Hussein <ahmedhussein.9494@...>; Rana Fawzi <rana.fawzi22@...>
Subject: [Zephyr-devel] AODV Based Routing Over BLE Mesh

 

Dear All,

 

We are a group of students at Cairo University who has developed an AODV based routing protocol using Zephyr over a BLE mesh network as our graduation project. Will you be interested in adding such feature to the current Zephyr stack?

 

Best Regards.  
AODV Based Routing Over BLE Mesh

Haytham Osama <haythamossama.95@...>
 

Dear All,

We are a group of students at Cairo University who has developed an AODV based routing protocol using Zephyr over a BLE mesh network as our graduation project. Will you be interested in adding such feature to the current Zephyr stack?

Best Regards.  
Re: Bluetooth: Mesh: Saving Server's State on SoC flash

vikrant8051 <vikrant8051@...>
 

Hi Johan,

But I need reference example or files from mesh stack which show how
to save & retrieve variable after reboot using setting layer ?

Thank You !!

On Wed, Jul 18, 2018 at 3:30 PM, Johan Hedberg <johan.hedberg@...> wrote:
Hi Vikrant,

On Wed, Jul 18, 2018, vikrant8051 wrote:
> Bluetooth Mesh stack is already utilizing setting layer (#FCB)
> to store mesh related data on SoC flash. Need examples so that
> its implementation along with Bluetooth Mesh sample code
> would not impact Mesh's persistent data ?

You should be able to use the same settings storage for your own data as
well. The Bluetooth stack (Mesh included) uses the prefix "bt/" for all
key names stored in settings, so as long as you use something else for
your own data there shouldn't be any risk of conflicts.

Johan
Re: Bluetooth: Mesh: Saving Server's State on SoC flash

Johan Hedberg
 

Hi Vikrant,

On Wed, Jul 18, 2018, vikrant8051 wrote:
Bluetooth Mesh stack is already utilizing setting layer (#FCB)
to store mesh related data on SoC flash. Need examples so that
its implementation along with Bluetooth Mesh sample code
would not impact Mesh's persistent data ?
You should be able to use the same settings storage for your own data as
well. The Bluetooth stack (Mesh included) uses the prefix "bt/" for all
key names stored in settings, so as long as you use something else for
your own data there shouldn't be any risk of conflicts.

Johan
Bluetooth: Mesh: Saving Server's State on SoC flash

vikrant8051 <vikrant8051@...>
 

Hi,

Bluetooth Mesh stack is already utilizing setting layer (#FCB)
to store mesh related data on SoC flash. Need examples so that
its implementation along with Bluetooth Mesh sample code
would not impact Mesh's persistent data ?

Thank You !!
Re: ZEPHYR_BASE environment variableIs setup #gettingstartedguide

miem@...
 

I added the ZEPHYR_BASE in environmental variable and it works now. Thanks.
Re: ZEPHYR_BASE environment variableIs setup #gettingstartedguide

Carles Cufi
 

Hi there,

 

I did tell you yesterday how to do that.

 

  1. Download Rapid Environment Editor.
  2. Add the environment variables you want with it
  3. Save

 

Now ZEPHYR_BASE will be set automatically every time you open a command window.

 

Carles

 

From: devel@... <devel@...> On Behalf Of miem@...
Sent: 13 July 2018 09:41
To: devel@...
Subject: Re: [Zephyr-devel] ZEPHYR_BASE environment variableIs setup #gettingstartedguide

 

Yes,
I am running on windows. and I set the ZEPHYR_TOOLCHAIN_VARIANT and GCCARMEMB_TOOLCHAIN_PATH in zephyrrc.cmd but I have to run zephyrrc.cmd and zephyr-env.cmd every time I am running a new command window session. 
Is it any way to save them as environmental variables and don't run zephyrrc.cmd and zephyr-env.cmd everytime?

Re: ZEPHYR_BASE environment variableIs setup #gettingstartedguide

miem@...
 

Yes,
I am running on windows. and I set the ZEPHYR_TOOLCHAIN_VARIANT and GCCARMEMB_TOOLCHAIN_PATH in zephyrrc.cmd but I have to run zephyrrc.cmd and zephyr-env.cmd every time I am running a new command window session. 
Is it any way to save them as environmental variables and don't run zephyrrc.cmd and zephyr-env.cmd everytime?
Re: ZEPHYR_BASE environment variableIs setup #gettingstartedguide

Maureen Helm
 

In Windows you can run zephyr-env.cmd to set ZEPHYR_BASE. It also has a hook to invoke your own zephyrrc.cmd which is handy for setting ZEPHYR_TOOLCHAIN_VARIANT and GCCARMEMB_TOOLCHAIN_PATH.

 

From: devel@... [mailto:devel@...] On Behalf Of Cufi, Carles
Sent: Thursday, July 12, 2018 10:28 AM
To: miem@...; devel@...
Subject: Re: [Zephyr-devel] ZEPHYR_BASE environment variableIs setup #gettingstartedguide

 

I assume you are on Windows from what you say.

 

If you have a single copy of the repo on your disk you can add ZEPHYR_BASE as a permanent environment variable. I recommend https://www.rapidee.com/en/about to do that.

 

Windows doesn’t have the equivalent of ~/.bashrc AFAIK.

 

 

From: devel@... <devel@...> On Behalf Of miem@...
Sent: 12 July 2018 16:12
To: devel@...
Subject: [Zephyr-devel] ZEPHYR_BASE environment variableIs setup #gettingstartedguide

 

Hi,

I have to set the the ZEPHYR_BASE environment variableIs every time I creat a new command window session to compile a project. Is there any way to save the ZEPHYR_BASE environment variableIs in windows setup and have it worked for all sessions?

Regards,
Miem

Re: ZEPHYR_BASE environment variableIs setup #gettingstartedguide

Carles Cufi
 

I assume you are on Windows from what you say.

 

If you have a single copy of the repo on your disk you can add ZEPHYR_BASE as a permanent environment variable. I recommend https://www.rapidee.com/en/about to do that.

 

Windows doesn’t have the equivalent of ~/.bashrc AFAIK.

 

 

From: devel@... <devel@...> On Behalf Of miem@...
Sent: 12 July 2018 16:12
To: devel@...
Subject: [Zephyr-devel] ZEPHYR_BASE environment variableIs setup #gettingstartedguide

 

Hi,

I have to set the the ZEPHYR_BASE environment variableIs every time I creat a new command window session to compile a project. Is there any way to save the ZEPHYR_BASE environment variableIs in windows setup and have it worked for all sessions?

Regards,
Miem

ZEPHYR_BASE environment variableIs setup #gettingstartedguide

miem@...
 

Hi,

I have to set the the ZEPHYR_BASE environment variableIs every time I creat a new command window session to compile a project. Is there any way to save the ZEPHYR_BASE environment variableIs in windows setup and have it worked for all sessions?

Regards,
Miem
STM32L4 CAN Driver status

leonard.bise@...
 

Hello Alexander,

I would like to use the STM32L4 CAN driver, as I understand you were the one that coded it, I wanted to ask if you could provide a status on this?
I tried to compile the samples/drivers/CAN sample on the master branch for the nucleo_l432kc board and I get compilation errors related to the CAN_InitTypeDef type in the HAL.

/home/lbise/gitrepo/zephyr/drivers/can/stm32_can.c:245:11: error: ‘CAN_InitTypeDef {aka struct <anonymous>}’ has no member named ‘TTCM’
  hcan.Init.TTCM = DISABLE;
           ^
/home/lbise/gitrepo/zephyr/drivers/can/stm32_can.c:246:11: error: ‘CAN_InitTypeDef {aka struct <anonymous>}’ has no member named ‘ABOM’
  hcan.Init.ABOM = DISABLE;
           ^
/home/lbise/gitrepo/zephyr/drivers/can/stm32_can.c:247:11: error: ‘CAN_InitTypeDef {aka struct <anonymous>}’ has no member named ‘AWUM’
  hcan.Init.AWUM = DISABLE;
           ^
/home/lbise/gitrepo/zephyr/drivers/can/stm32_can.c:248:11: error: ‘CAN_InitTypeDef {aka struct <anonymous>}’ has no member named ‘NART’
  hcan.Init.NART = DISABLE;
           ^
/home/lbise/gitrepo/zephyr/drivers/can/stm32_can.c:249:11: error: ‘CAN_InitTypeDef {aka struct <anonymous>}’ has no member named ‘RFLM’
  hcan.Init.RFLM = DISABLE;
           ^
/home/lbise/gitrepo/zephyr/drivers/can/stm32_can.c:250:11: error: ‘CAN_InitTypeDef {aka struct <anonymous>}’ has no member named ‘TXFP’
  hcan.Init.TXFP = DISABLE;
           ^
/home/lbise/gitrepo/zephyr/drivers/can/stm32_can.c:252:11: error: ‘CAN_InitTypeDef {aka struct <anonymous>}’ has no member named ‘SJW’
  hcan.Init.SJW  = swj;
           ^
/home/lbise/gitrepo/zephyr/drivers/can/stm32_can.c:253:11: error: ‘CAN_InitTypeDef {aka struct <anonymous>}’ has no member named ‘BS1’
  hcan.Init.BS1  = bs1;

Is there something broken or is it on my end?
Thanks.

Best regards,
Léonard.
Factory Reset: using power On/Off

vikrant8051 <vikrant8051@...>
 

Hi,

To push device into factory reset mode, there is one solution :
1) As soon as device get power it'd read variable store on SoC flash
2) And would immediately increase it by +1 & again stored it on SoC flash
3) After say 5 secs, it'd set that value to Zero & restore it on flash.

So in this method if after reboot, device found that value greater than 5, then it'd push device into factory reset mode.

How to implement it using #FCB & setting layer ? I wanna use this method along with #BluetoothMesh sample/demo examples. Could we make it as software module for all microcontrollers or SoCs which could be enable/disable using prj.conf ?

Thank You !!
Re: Has anyone used the USB HS port used as a USB FS on STM32F4?

Aurelien Jarno
 

On 2018-07-11 13:04, Yannis Damigos wrote:
All the STM32F7 SoCs except the STM32F723 have an on-chip FS PHY, just
like the STM32F4 family. The STM32F723 only has an on-chip HS PHY and
does not have the FS PHY.

You can see that on RM0431, pages 1172 and 1173.

The idea is to disable the ULPI clock for SoCs which do not have an HS
PHY, as the FS PHY should be used instead. If USB_HS_PHYC is defined,
the SoC has an HS PHY but not FS PHY, when it is not defined, it has a
FS PHY but no HS PHY.
Thanks for the pointers. I updated my tree accordingly.
Thanks, I confirm it works well on STM32F723E-DISCO, by just changing
the device tree to disable usbotg_fs and enable usbotg_hs.

Aurelien

--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurelien@... http://www.aurel32.net
Re: Has anyone used the USB HS port used as a USB FS on STM32F4?

Yannis Damigos
 

All the STM32F7 SoCs except the STM32F723 have an on-chip FS PHY, just
like the STM32F4 family. The STM32F723 only has an on-chip HS PHY and
does not have the FS PHY.

You can see that on RM0431, pages 1172 and 1173.

The idea is to disable the ULPI clock for SoCs which do not have an HS
PHY, as the FS PHY should be used instead. If USB_HS_PHYC is defined,
the SoC has an HS PHY but not FS PHY, when it is not defined, it has a
FS PHY but no HS PHY.
Thanks for the pointers. I updated my tree accordingly.

Yannis
Re: Has anyone used the USB HS port used as a USB FS on STM32F4?

Aurelien Jarno
 

On 2018-07-11 11:03, Yannis Damigos wrote:
Hi Aurelien,

Thanks for reviewing it.

- The PHY has to be USB_OTG_HS_EMBEDDED_PHY on that board as it doesn't
have an embedded full-speed PHY
Strange. STM32F72xxx SoC reference manual mentions an on-chip full-speed PHY.
All the STM32F7 SoCs except the STM32F723 have an on-chip FS PHY, just
like the STM32F4 family. The STM32F723 only has an on-chip HS PHY and
does not have the FS PHY.

You can see that on RM0431, pages 1172 and 1173.

- The check on CONFIG_SERIES_STM32F7X is wrong and should be
CONFIG_SOC_SERIES_STM32F7X instead.
Fixed.

I also I believe that the STM32F7 SoCs without embedded HS speed behave
the same than the STM32F4. Therefore I think that both OTGHSULPI and
OTGPHYC clocks should be enabled if the SoC has an internal HS PHY,
otherwise OTGHSULPI should be disabled.
I agree. That's why I am trying to find a way to define the PHYs
(maybe in device tree).

diff --git a/drivers/usb/device/usb_dc_stm32.c b/drivers/usb/device/usb_dc_stm32.c
index f11233535..c85bca9a5 100644
--- a/drivers/usb/device/usb_dc_stm32.c
+++ b/drivers/usb/device/usb_dc_stm32.c
@@ -248,17 +248,14 @@ static int usb_dc_stm32_clock_enable(void)

#ifdef CONFIG_USB_HS_BASE_ADDRESS

-#ifdef CONFIG_SERIES_STM32F7X
- LL_AHB1_GRP1_EnableClock(LL_AHB1_GRP1_PERIPH_OTGHSULPI);
-
#ifdef USB_HS_PHYC
+ /* Enable ULPI interface and internal high-speed PHY clocks */
+ LL_AHB1_GRP1_EnableClock(LL_AHB1_GRP1_PERIPH_OTGHSULPI);
LL_APB2_GRP1_EnableClock(LL_APB2_GRP1_PERIPH_OTGPHYC);
-#endif /* USB_HS_PHYC
-
#else
/* Disable ULPI interface (for external high-speed PHY) clock */
LL_AHB1_GRP1_DisableClock(LL_AHB1_GRP1_PERIPH_OTGHSULPI);
-#endif /* CONFIG_SERIES_STM32F7X */
+#endif /* USB_HS_PHYC */

#endif /* CONFIG_USB_HS_BASE_ADDRESS */
USB_HS_PHYC is not defined on all STM32F7 SoCs, so enabling ULPI clock
if it is defined won't
work on other SoCs.
The idea is to disable the ULPI clock for SoCs which do not have an HS
PHY, as the FS PHY should be used instead. If USB_HS_PHYC is defined,
the SoC has an HS PHY but not FS PHY, when it is not defined, it has a
FS PHY but no HS PHY.

@@ -285,7 +282,11 @@ static int usb_dc_stm32_init(void)
#endif
usb_dc_stm32_state.pcd.Init.dev_endpoints = CONFIG_USB_NUM_BIDIR_ENDPOINTS;
usb_dc_stm32_state.pcd.Init.speed = USB_OTG_SPEED_FULL;
+#ifdef USB_HS_PHYC
+ usb_dc_stm32_state.pcd.Init.phy_itface = USB_OTG_HS_EMBEDDED_PHY;
+#else
usb_dc_stm32_state.pcd.Init.phy_itface = PCD_PHY_EMBEDDED;
+#endif /* USB_HS_PHYC */
usb_dc_stm32_state.pcd.Init.ep0_mps = USB_OTG_MAX_EP0_SIZE;
usb_dc_stm32_state.pcd.Init.vbus_sensing_enable = DISABLE;
The PR is focused on enabling FS mode on OTG_HS that's why I didn't
change PHY interface.
I understand that, that's why my patch didn't change USB_OTG_SPEED_FULL
(but I have verified it work in HS mode). That said given that there is
no FS PHY when there is an HS PHY, we need to use it in FS mode instead.

Aurelien

--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurelien@... http://www.aurel32.net
Re: Has anyone used the USB HS port used as a USB FS on STM32F4?

Li, Jun R
 

Yes, it works. The two lines are not needed, actually. Sorry for confusing!

Regards,
Jun


On 7/11/18, 01:16, "Yannis Damigos" <giannis.damigos@...> wrote:

Hi Jun,

thanks for testing.

> I double checked your code again and found you removed the following two lines on the line 247 which I had recommended:
>
> LL_AHB1_GRP1_DisableClockLowPower(RCC_AHB1LPENR_OTGHSULPILPEN);
>
> LL_AHB1_GRP1_EnableClockLowPower(RCC_AHB1LPENR_OTGHSLPEN);
>

Why do you enable the clocks in low power mode?

Line 260 in my tree
LL_AHB1_GRP1_DisableClock(LL_AHB1_GRP1_PERIPH_OTGHSULPI); disables
ULPI clock.
OTG_HS clock is enabled by lines 184-187.

STM32Cube HAL defines:
#define LL_AHB1_GRP1_PERIPH_OTGHS RCC_AHB1ENR_OTGHSEN
#define LL_AHB1_GRP1_PERIPH_OTGHSULPI RCC_AHB1ENR_OTGHSULPIEN

and functions LL_AHB1_GRP1_EnableClock, LL_AHB1_GRP1_DisableClock,
LL_AHB1_GRP1_DisableClockLowPower,
LL_AHB1_GRP1_EnableClockLowPower mentions
LL_AHB1_GRP1_PERIPH_OTGHSULPI and LL_AHB1_GRP1_PERIPH_OTGHSULPI
as valid parameters.

Could you check again I found a typo in ifdefs which didn't disable ULPI clock?

Yannis
Re: Has anyone used the USB HS port used as a USB FS on STM32F4?

Yannis Damigos
 

Hi Jun,

thanks for testing.

I double checked your code again and found you removed the following two lines on the line 247 which I had recommended:

LL_AHB1_GRP1_DisableClockLowPower(RCC_AHB1LPENR_OTGHSULPILPEN);

LL_AHB1_GRP1_EnableClockLowPower(RCC_AHB1LPENR_OTGHSLPEN);
Why do you enable the clocks in low power mode?

Line 260 in my tree
LL_AHB1_GRP1_DisableClock(LL_AHB1_GRP1_PERIPH_OTGHSULPI); disables
ULPI clock.
OTG_HS clock is enabled by lines 184-187.

STM32Cube HAL defines:
#define LL_AHB1_GRP1_PERIPH_OTGHS RCC_AHB1ENR_OTGHSEN
#define LL_AHB1_GRP1_PERIPH_OTGHSULPI RCC_AHB1ENR_OTGHSULPIEN

and functions LL_AHB1_GRP1_EnableClock, LL_AHB1_GRP1_DisableClock,
LL_AHB1_GRP1_DisableClockLowPower,
LL_AHB1_GRP1_EnableClockLowPower mentions
LL_AHB1_GRP1_PERIPH_OTGHSULPI and LL_AHB1_GRP1_PERIPH_OTGHSULPI
as valid parameters.

Could you check again I found a typo in ifdefs which didn't disable ULPI clock?

Yannis
Re: Has anyone used the USB HS port used as a USB FS on STM32F4?

Yannis Damigos
 

Hi Aurelien,

Thanks for reviewing it.

- The PHY has to be USB_OTG_HS_EMBEDDED_PHY on that board as it doesn't
have an embedded full-speed PHY
Strange. STM32F72xxx SoC reference manual mentions an on-chip full-speed PHY.

- The check on CONFIG_SERIES_STM32F7X is wrong and should be
CONFIG_SOC_SERIES_STM32F7X instead.
Fixed.

I also I believe that the STM32F7 SoCs without embedded HS speed behave
the same than the STM32F4. Therefore I think that both OTGHSULPI and
OTGPHYC clocks should be enabled if the SoC has an internal HS PHY,
otherwise OTGHSULPI should be disabled.
I agree. That's why I am trying to find a way to define the PHYs
(maybe in device tree).

diff --git a/drivers/usb/device/usb_dc_stm32.c b/drivers/usb/device/usb_dc_stm32.c
index f11233535..c85bca9a5 100644
--- a/drivers/usb/device/usb_dc_stm32.c
+++ b/drivers/usb/device/usb_dc_stm32.c
@@ -248,17 +248,14 @@ static int usb_dc_stm32_clock_enable(void)

#ifdef CONFIG_USB_HS_BASE_ADDRESS

-#ifdef CONFIG_SERIES_STM32F7X
- LL_AHB1_GRP1_EnableClock(LL_AHB1_GRP1_PERIPH_OTGHSULPI);
-
#ifdef USB_HS_PHYC
+ /* Enable ULPI interface and internal high-speed PHY clocks */
+ LL_AHB1_GRP1_EnableClock(LL_AHB1_GRP1_PERIPH_OTGHSULPI);
LL_APB2_GRP1_EnableClock(LL_APB2_GRP1_PERIPH_OTGPHYC);
-#endif /* USB_HS_PHYC
-
#else
/* Disable ULPI interface (for external high-speed PHY) clock */
LL_AHB1_GRP1_DisableClock(LL_AHB1_GRP1_PERIPH_OTGHSULPI);
-#endif /* CONFIG_SERIES_STM32F7X */
+#endif /* USB_HS_PHYC */

#endif /* CONFIG_USB_HS_BASE_ADDRESS */
USB_HS_PHYC is not defined on all STM32F7 SoCs, so enabling ULPI clock
if it is defined won't
work on other SoCs.

@@ -285,7 +282,11 @@ static int usb_dc_stm32_init(void)
#endif
usb_dc_stm32_state.pcd.Init.dev_endpoints = CONFIG_USB_NUM_BIDIR_ENDPOINTS;
usb_dc_stm32_state.pcd.Init.speed = USB_OTG_SPEED_FULL;
+#ifdef USB_HS_PHYC
+ usb_dc_stm32_state.pcd.Init.phy_itface = USB_OTG_HS_EMBEDDED_PHY;
+#else
usb_dc_stm32_state.pcd.Init.phy_itface = PCD_PHY_EMBEDDED;
+#endif /* USB_HS_PHYC */
usb_dc_stm32_state.pcd.Init.ep0_mps = USB_OTG_MAX_EP0_SIZE;
usb_dc_stm32_state.pcd.Init.vbus_sensing_enable = DISABLE;
The PR is focused on enabling FS mode on OTG_HS that's why I didn't
change PHY interface.

Yannis
Re: Has anyone used the USB HS port used as a USB FS on STM32F4?

Li, Jun R
 

Hi Yannis,

I verified your branch with samples/subsys/usb/cdc_acm on my customized STM32F429 board, and found enumeration issues:

 

[6176209.029339] usb 1-1.5.2.1: new full-speed USB device number 30 using ehci-pci

[6176209.437330] usb 1-1.5.2.1: device not accepting address 30, error -32

[6176209.525325] usb 1-1.5.2.1: new full-speed USB device number 31 using ehci-pci

[6176209.933339] usb 1-1.5.2.1: device not accepting address 31, error -32

[6176209.933545] usb 1-1.5.2-port1: unable to enumerate USB device

 

I double checked your code again and found you removed the following two lines on the line 247 which I had recommended:

        LL_AHB1_GRP1_DisableClockLowPower(RCC_AHB1LPENR_OTGHSULPILPEN);

        LL_AHB1_GRP1_EnableClockLowPower(RCC_AHB1LPENR_OTGHSLPEN);

 

Without these two lines, the USB_OTG_HS port doesn't work, can't be enumerated.

 

After adding those two lines, the usb was correctly enumerated and the cdc_acm works well:

 

[6176395.476959] usb 1-1.5.2.1: new full-speed USB device number 32 using ehci-pci

[6176395.587715] usb 1-1.5.2.1: New USB device found, idVendor=2fe3, idProduct=0100

[6176395.587729] usb 1-1.5.2.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3

[6176395.587732] usb 1-1.5.2.1: Product: Zephyr CDC ACM sample

[6176395.587734] usb 1-1.5.2.1: Manufacturer: ZEPHYR

[6176395.587736] usb 1-1.5.2.1: SerialNumber: 0.01

[6176395.588150] cdc_acm 1-1.5.2.1:1.0: ttyACM2: USB ACM device

 

So, can you add those two lines back to your branch?

 

Best Regards,

Jun

 

On 7/10/18, 01:30, "devel@... on behalf of Yannis Damigos" <devel@... on behalf of giannis.damigos@...> wrote:

 

    Hi Jun and Aurelien,

   

    I created the following branch in my repository to add support for OTG

    HS: https://github.com/ydamigos/zephyr/commits/stm32_otg_hs

   

    It was tested on stm32f429 SoC by Jun and on STM32F723E-DISCO by Aurelien.

   

    I updated my repository following your comments. Could you test it

    again because I don't have the hw?

   

    Before opening a PR upstream I would like to add support for the

    boards you tested it. Could you open a pull request to my branch?

   

    Please note that only one interface should be enabled at a time, OTG

    FS or OTG HS. The driver will raise an error if both are enabled.

   

    The USB API should change if we want to have them both enabled.

   

    Yannis

   

    

   

    
3701 - 3720 of 8575