Date   
Zephyr Toolchain Working Group Meeting – 20 Feb 2020

Rasmussen, Torsten
 

Hi,

 

Today’s meeting minutes:

https://docs.google.com/document/d/1IQKBK-GcJNZG0O9QArqYfvb6Huk5xHscN-XIGEZr-z8/

 

  • Toolchain support, github overview:
    • https://github.com/zephyrproject-rtos/zephyr/issues/5517

 

  • Experiences shared from Metaware toolchain work:
    • PR#22668 : Good feedback in the PR.
    • Many primitives are supported in metaware, so no problems here
    • most issues faced in relation to linker scripts, linker script are very gcc centric.
    • Certain features used in gcc cannot be used in Metaware.
    • Lot of time spend on things done in relation to binutils, such as mapping features from e.g. objcopy
    • User space / section rename relies heavily on some advanced features of gcc
    • Assembly code has difference

 

  • When a toolchain is stated as supported, it means:
    • Whole codebase compiles with that toolchain
    • To ensure this is possible, the following should be ensured:
      • Stick to standard C, ensure this through PR reviews
      • Consider imposing rules regarding, e.g. gcc extensions
      • There should be no to little need for assembly, as most things can be worked around in C.

Assembly should be isolated to special cases.

      • Look at CMSIS-intrinsic, ARM C Language Extensions (ACLE), as those are supported in gcc, llvm, IAR compilers
      • Minimize or remove the need for gcc preprocessing, one example is KConfig failures when trying to pre-process with IAR

 

  • Documentation:
    • Build system workflow is well described, but adding a new toolchain requires deeper knowledge.

 

  • Toolchain abstraction in build system that must be addressed
    • The abstraction of toolchains should be improved in Zephyr
      • Use learnings from Metaware work.
    • Evolve linker script to be more commercial toolchain friendly.
      • experience with ICC, Compiling was fast, but failed on linking
    • Python scripts makes lot of assumptions that are gcc/ld specific
    • PR#22668 is a good starting point for introducing needed improvements.

 

  • Oticon shared their experiences:
    • Current toolchain abstraction is sufficient
    • Oticon completely bypass toolchain / linking in Zephyr by using own and specialized linker script

 

  • IAR support:
    • IAR is willing to do work to ensure support for IAR
    • Hello World is a first goal, acceptable to use gcc as linker.

Comment: should not be too difficult to also support IAR linker

    • IAR linker can do optimizations not possible with gcc

 

 




Actions

  • Wayne: PR22668: Continue work, and use as base for better toolchain abstraction
  • Thomas: IAR: Get basic hello world compiling, (linking with GCC)
  • Everyone: Give feedback on PR#22688, and issue: #5517

 

Best regards

 

Torsten Tejlmand Rasmussen

           

 

Upcoming Event: Zephyr Project: Dev Meeting - Thu, 02/20/2020 8:00am-9:00am, Please RSVP #cal-reminder

devel@lists.zephyrproject.org Calendar <devel@...>
 

Reminder: Zephyr Project: Dev Meeting

When: Thursday, 20 February 2020, 8:00am to 9:00am, (GMT-08:00) America/Los Angeles

Where:https://zoom.us/j/993312203

An RSVP is requested. Click here to RSVP

Organizer: devel@...

Description: Join Zoom Meeting
https://zoom.us/j/993312203

One tap mobile
+16699006833,,993312203# US (San Jose)
+16465588656,,993312203# US (New York)

Dial by your location
        +1 669 900 6833 US (San Jose)
        +1 646 558 8656 US (New York)
        +1 877 369 0926 US Toll-free
        +1 855 880 1246 US Toll-free
Meeting ID: 993 312 203
Find your local number: https://zoom.us/u/ankEMRagf

Zephyr Toolchain Working Group - Thu, 02/20/2020 #cal-notice

devel@lists.zephyrproject.org Calendar <noreply@...>
 

Zephyr Toolchain Working Group

When:
Thursday, 20 February 2020
9:00am to 10:00am
(GMT-06:00) America/Chicago

Where:
https://zoom.us/j/967549258

Description:
Zephyr Working Group is inviting you to a scheduled Zoom meeting.

Topic:  Zephyr Toolchain Working Group
Time: Feb 20, 2020 09:00 AM Central Time (US and Canada)
        Every 2 weeks on Thu, until Jul 23, 2020, 12 occurrence(s)
        Feb 20, 2020 09:00 AM
        Mar 5, 2020 09:00 AM
        Mar 19, 2020 09:00 AM
        Apr 2, 2020 09:00 AM
        Apr 16, 2020 09:00 AM
        Apr 30, 2020 09:00 AM
        May 14, 2020 09:00 AM
        May 28, 2020 09:00 AM
        Jun 11, 2020 09:00 AM
        Jun 25, 2020 09:00 AM
        Jul 9, 2020 09:00 AM
        Jul 23, 2020 09:00 AM
Please download and import the following iCalendar (.ics) files to your calendar system.
Weekly: https://zoom.us/meeting/tJIqcu2hrD4id0z59MlGQgtjfduqRH_iTA/ics?icsToken=98tyKuCuqT4uE9aQuF39e7cqA97lbN-1i3UesPYEsRPCMidHaAXyI_NwGo12JPmB

Join Zoom Meeting
https://zoom.us/j/967549258

Meeting ID: 967 549 258

One tap mobile
+16699006833,,967549258# US (San Jose)
+16465588656,,967549258# US (New York)

Dial by your location
        +1 669 900 6833 US (San Jose)
        +1 646 558 8656 US (New York)
        855 880 1246 US Toll-free
        877 369 0926 US Toll-free
        +1 647 558 0588 Canada
        855 703 8985 Canada Toll-free
Meeting ID: 967 549 258
Find your local number: https://zoom.us/u/abfRKTHWtN

Live meeting minutes: https://docs.google.com/document/d/1IQKBK-GcJNZG0O9QArqYfvb6Huk5xHscN-XIGEZr-z8/edit#heading=h.x36xe8bnwr9r

Upcoming Event: Zephyr Toolchain Working Group - Thu, 02/20/2020 9:00am-10:00am #cal-reminder

devel@lists.zephyrproject.org Calendar <devel@...>
 

Reminder: Zephyr Toolchain Working Group

When: Thursday, 20 February 2020, 9:00am to 10:00am, (GMT-06:00) America/Chicago

Where:https://zoom.us/j/967549258

View Event

Organizer: Maureen Helm

Description: Zephyr Working Group is inviting you to a scheduled Zoom meeting.

Topic:  Zephyr Toolchain Working Group
Time: Feb 20, 2020 09:00 AM Central Time (US and Canada)
        Every 2 weeks on Thu, until Jul 23, 2020, 12 occurrence(s)
        Feb 20, 2020 09:00 AM
        Mar 5, 2020 09:00 AM
        Mar 19, 2020 09:00 AM
        Apr 2, 2020 09:00 AM
        Apr 16, 2020 09:00 AM
        Apr 30, 2020 09:00 AM
        May 14, 2020 09:00 AM
        May 28, 2020 09:00 AM
        Jun 11, 2020 09:00 AM
        Jun 25, 2020 09:00 AM
        Jul 9, 2020 09:00 AM
        Jul 23, 2020 09:00 AM
Please download and import the following iCalendar (.ics) files to your calendar system.
Weekly: https://zoom.us/meeting/tJIqcu2hrD4id0z59MlGQgtjfduqRH_iTA/ics?icsToken=98tyKuCuqT4uE9aQuF39e7cqA97lbN-1i3UesPYEsRPCMidHaAXyI_NwGo12JPmB

Join Zoom Meeting
https://zoom.us/j/967549258

Meeting ID: 967 549 258

One tap mobile
+16699006833,,967549258# US (San Jose)
+16465588656,,967549258# US (New York)

Dial by your location
        +1 669 900 6833 US (San Jose)
        +1 646 558 8656 US (New York)
        855 880 1246 US Toll-free
        877 369 0926 US Toll-free
        +1 647 558 0588 Canada
        855 703 8985 Canada Toll-free
Meeting ID: 967 549 258
Find your local number: https://zoom.us/u/abfRKTHWtN

Live meeting minutes: https://docs.google.com/document/d/1IQKBK-GcJNZG0O9QArqYfvb6Huk5xHscN-XIGEZr-z8/edit#heading=h.x36xe8bnwr9r

Zephyr Toolchain Working Group Meeting – 20 Feb 2020

Rasmussen, Torsten
 

Hi All,

 

 

For today’s meeting let’s go through existing issues / PRs relevant for the working group.

 

Where:
https://zoom.us/j/967549258

Agenda

 

 

Feel free to send a mail, if you would like additional topics to be discussed.

 

Best regards

 

Torsten T. Rasmussen           

 

Live meeting minutes: https://docs.google.com/document/d/1IQKBK-GcJNZG0O9QArqYfvb6Huk5xHscN-XIGEZr-z8/edit#heading=h.x36xe8bnwr9r

 

Dev-Review Meeting Agenda Feb 20

Kumar Gala
 

All,

Meeting Minutes:

https://docs.google.com/document/d/1vfgwa1oRVuLA0f4VZW9pMBD2n2kf7ZgI9QCw_4s01gA/edit?usp=sharing

General:
• Kumar on vacation next 2 weeks, Marti will lead meetings

GitHub PR/Issues:
• n/a

Device Tree:
• Modified plan for topic-devicetree - from discussion last week. Plan is now to treat topic-devicetree as a normal topic branch and have PRs go through normal review. I’ve posted an initial set of DT_INST conversions. Next major batch requires closing on https://github.com/zephyrproject-rtos/zephyr/pull/22612 for nodelabel support
• DT Naming consistent convention - https://github.com/zephyrproject-rtos/zephyr/issues/22964
• Loss of configurability from Kconfig -> DT - https://github.com/zephyrproject-rtos/zephyr/pull/22772
• System initialization in DT dependency ordinal order - Marti
• “Naming” one device for unique purpose (OpenISA system timer, STM32 lptimer)
• usage of aliases for samples/tests
• fixed non-alias reference to specific nodes: https://github.com/zephyrproject-rtos/zephyr/issues/19285
• clearly define constraints on identifier/property name conflicts https://github.com/zephyrproject-rtos/zephyr/issues/21369

Re: make menuconfig for STM32MP157 activating STM32Cube ?

friedtj@...
 

This answered the question: adding a Kconfig with the STM32Cube modules
solved the issue, without including objects in the CMakeLists.txt despite
having STM32Cube in $ZEPHYR_BASE/../modules/hal/stm32/stm32cube.

Thank you, Jean-Michel

----- Mail original -----
De: "Erwan Gouriou" <erwan.gouriou@...>
À: friedtj@...
Cc: "devel" <devel@...>
Envoyé: Mardi 18 Février 2020 08:56:39
Objet: Re: [Zephyr-devel] make menuconfig for STM32MP157 activating STM32Cube ?


Hi,


Can you check following readme section and see if it answers your point?


https://github.com/zephyrproject-rtos/hal_stm32/blob/master/README.rst#use-stm32cube-in-your-application



Cheers
Erwan

Le sam. 15 févr. 2020 à 17:45, < friedtj@... > a écrit :


I am building https://github.com/STMicroelectronics/logicanalyser (RPMSG
and VirtIO example for the STM32MP157 using OpenAMP) for Zephyr and have been
facing the issue of linking with the STM32Cube library functions.

I am using the external arm-none-eabi-gcc compilation toolchain under
Debian/GNU Linux with
export ZEPHYR_TOOLCHAIN_VARIANT=cross-compile
export CROSS_COMPILE=/usr/bin/arm-none-eabi-

The tree structure I have (west init && cd zephyr && west update)
has created modules/hal/stm32/stm32cube/ at the same level than zephyr.

This ST example relies heavily on the STM32Cube framework I had to link with.
I achieved a functional result by adding in my CMakeLists.txt the following statement

target_sources(app PRIVATE src/main.c src/rpmsg_hdr.c src/openamp.c src/mbox_ipcc.c src/rsc_table.c src/copro_sync.c $ENV{ZEPHYR_BASE}/../modules/hal/stm32/stm32cube/stm32mp1xx/drivers/src/stm32mp1xx_hal_dma.c $ENV{ZEPHYR_BASE}/../modules/hal/stm32/stm32cube/stm32mp1xx/drivers/src/stm32mp1xx_hal_gpio.c $ENV{ZEPHYR_BASE}/../modules/hal/stm32/stm32cube/stm32mp1xx/drivers/src/stm32mp1xx_hal_rcc_ex.c $ENV{ZEPHYR_BASE}/../modules/hal/stm32/stm32cube/stm32mp1xx/drivers/src/stm32mp1xx_hal_ipcc.c $ENV{ZEPHYR_BASE}/../modules/hal/stm32/stm32cube/stm32mp1xx/drivers/src/stm32mp1xx_hal_cortex.c $ENV{ZEPHYR_BASE}/../modules/hal/stm32/stm32cube/stm32mp1xx/drivers/src/stm32mp1xx_hal_tim_ex.c $ENV{ZEPHYR_BASE}/../modules/hal/stm32/stm32cube/stm32mp1xx/drivers/src/stm32mp1xx_hal_pwr.c $ENV{ZEPHYR_BASE}/../modules/hal/stm32/stm32cube/stm32mp1xx/drivers/src/stm32mp1xx_hal_tim.c)

following the advice I read at
https://github.com/intel/zephyr/tree/master/ext/hal/st/stm32cube
stating

"Plus add HAL driver file (when needed):
obj-$(CONFIG_SERIAL_HAS_DRIVER) += stm32yyxx/drivers/src/stm32yyxx_hal_uart.o"

This is most probably *not* the right way and hence my question to this list:
if I wish to activate these functions in STM32Cube, make menuconfig in the build directory
shows
-*- <HAS_STM32CUBE>
in red, but then all other subsystems (eg - - <USE_STM32_HAL_DMA> or
- - <USE_STM32_HAL_IPCC>) which I believe would fill the cmake configuration
file properly are disabled and cannot be enabled. I fail to understand what
option prevents me from activating these functionalities.

Could anyone explain what I am doing wrong in this configuration ?

Thank you, Jean-Michel

Re: west imports and destination paths

Marc Reilly
 

Hi Carles,

This sounds like it’s covered in this issue:

https://github.com/zephyrproject-rtos/west/issues/367

 

Please comment on it to make sure it covers all of your requirements.


Thats it, thanks very much, added my $0.02

Cheers
Marc

Re: west imports and destination paths

Carles Cufi
 

Hi Marc,

 

This sounds like it’s covered in this issue:

https://github.com/zephyrproject-rtos/west/issues/367

 

Please comment on it to make sure it covers all of your requirements.

 

Regards,

 

Carles

 

From: devel@... <devel@...> On Behalf Of Marc Reilly via Lists.Zephyrproject.Org
Sent: 19 February 2020 10:18
To: devel@...
Cc: devel@...
Subject: [Zephyr-devel] west imports and destination paths

 

Hi all,

 

I like the (new?) west import feature, it makes it easy to checkout zephyr and associated modules along side an application/project.

 

Is there a way to specify where a 'sub-modules' of an import will end up?

At the moment it seems to just be relative to the base folder. From what I can tell, specifying a path as the import value itself is mainly concerned with how west _sources_ the import, not where it ends up.

 

An example, with a basic west.yml file (like Example 1.1 of current docs) which is effectively:

 

#west.yml

manifest:

  projects:

    - name: my-app

      remote: whatever

    - name: zephyr

      remote: as_normal

      import: true

#

 

when zephyr is imported, zephyr's modules end up in the 'base' west folder, like this:

 

.../my-project

    - west.yml

    - my-app/

    - bootloader/

    - tools/

    - modules/

    - zephyr/

 

But what I'd like to end up with is zephyr and submodules under their own subfolder,

something like:

 

.../my-project

    - west.yml

    - my-app/

    - zephyrproject/

        - bootloader/

        - tools/

        - modules/

        - zephyr/

 

(ie, bootloader, tools, modules, etc are all siblings of the zephyr/ folder which was the nominated import)

 

So I alter the path for the zephyr project in the west.wml like so:

 

#west.yml  v2

manifest:

  projects:

    - name: my-app

      remote: whatever

    - name: zephyr

      remote: as_normal

      import: true

      path: zephyrproject/zephyr

 

 

But what this yields is only the zephyr project ends up at the desired path, it's modules still end up in the base folder

something like this:

 

.../my-project

    - west.yml

    - my-app/

    - zephyrproject/

        - zephyr/

    - bootloader/

    - tools/

    - modules/

 

Is there a way to make it so that the zephyr imported modules end up where I want them? (eg the folders zephyr, bootloader, tools, modules etc all end up in a nominated sub folder)

 

Cheers,

Marc

 

west imports and destination paths

Marc Reilly
 

Hi all,

I like the (new?) west import feature, it makes it easy to checkout zephyr and associated modules along side an application/project.

Is there a way to specify where a 'sub-modules' of an import will end up?
At the moment it seems to just be relative to the base folder. From what I can tell, specifying a path as the import value itself is mainly concerned with how west _sources_ the import, not where it ends up.

An example, with a basic west.yml file (like Example 1.1 of current docs) which is effectively:

#west.yml
manifest:
  projects:
    - name: my-app
      remote: whatever
    - name: zephyr
      remote: as_normal
      import: true
#

when zephyr is imported, zephyr's modules end up in the 'base' west folder, like this:

.../my-project
    - west.yml
    - my-app/
    - bootloader/
    - tools/
    - modules/
    - zephyr/

But what I'd like to end up with is zephyr and submodules under their own subfolder,
something like:

.../my-project
    - west.yml
    - my-app/
    - zephyrproject/
        - bootloader/
        - tools/
        - modules/
        - zephyr/

(ie, bootloader, tools, modules, etc are all siblings of the zephyr/ folder which was the nominated import)

So I alter the path for the zephyr project in the west.wml like so:

#west.yml  v2
manifest:
  projects:
    - name: my-app
      remote: whatever
    - name: zephyr
      remote: as_normal
      import: true
      path: zephyrproject/zephyr


But what this yields is only the zephyr project ends up at the desired path, it's modules still end up in the base folder
something like this:

.../my-project
    - west.yml
    - my-app/
    - zephyrproject/
        - zephyr/
    - bootloader/
    - tools/
    - modules/

Is there a way to make it so that the zephyr imported modules end up where I want them? (eg the folders zephyr, bootloader, tools, modules etc all end up in a nominated sub folder)

Cheers,
Marc

Upcoming Event: Zephyr Project: APIs - Tue, 02/18/2020 9:00am-10:00am, Please RSVP #cal-reminder

devel@lists.zephyrproject.org Calendar <devel@...>
 

Reminder: Zephyr Project: APIs

When: Tuesday, 18 February 2020, 9:00am to 10:00am, (GMT-08:00) America/Los Angeles

Where:https://zoom.us/j/177647878

An RSVP is requested. Click here to RSVP

Organizer: devel@...

Description: Join from PC, Mac, Linux, iOS or Android: https://zoom.us/j/177647878

Or iPhone one-tap :
    US: +16465588656,,177647878# or +16699006833,,177647878# 
Or Telephone:
    Dial(for higher quality, dial a number based on your current location): 
        US: +1 646 558 8656 or +1 669 900 6833 or +1 855 880 1246 (Toll Free) or +1 877 369 0926 (Toll Free)
    Meeting ID: 177 647 878
    International numbers available: https://zoom.us/zoomconference?m=ioAR9GK1OE5LkN1ojt-heTCl7yPcJrhY


 Live meeting minutes: https://docs.google.com/document/d/1lv-8B5QE2m4FjBcvfqAXFIgQfW5oz6306zJ7GIZIWCk/edit?usp=sharing

API meeting: agenda

Carles Cufi
 

Hi all,

The topics for today:

- Discussion on whether to move the hw_info API to stable

- PR: generalize async notification and add queued operation manager
- https://github.com/zephyrproject-rtos/zephyr/pull/22853

- Defining the expected behavior of API calls in different contexts: settle on documentation guidelines
- https://github.com/zephyrproject-rtos/zephyr/issues/18970


Additional items in the "Triage" column in the GitHub project may be discussed if time permits.
If you want an item included in the meeting, please add it to the GitHub project.

https://github.com/zephyrproject-rtos/zephyr/wiki/Zephyr-Committee-and-Working-Group-Meetings#zephyr-api-discussion
https://github.com/zephyrproject-rtos/zephyr/projects/18
https://docs.google.com/document/d/1lv-8B5QE2m4FjBcvfqAXFIgQfW5oz6306zJ7GIZIWCk/edit

Regards,

Carles

Re: make menuconfig for STM32MP157 activating STM32Cube ?

Arnaud POULIQUEN
 

Hi,

Regarding your link : https://github.com/intel/zephyr/tree/master/ext/hal/st/stm32cube

Seems that you don't point to the good zephyr project
Please refer to https://github.com/zephyrproject-rtos for the code
Stm32cube HALs are available here: https://github.com/zephyrproject-rtos/hal_stm32/tree/master/stm32cube

If you want an example of OpenAMP implementation for stm32mp1 : https://github.com/zephyrproject-rtos/zephyr/pull/16985

Regards,
Arnaud

-----Original Message-----
From: devel@... <devel@...> On
Behalf Of friedtj@...
Sent: samedi 15 février 2020 17:00
To: devel@...
Subject: [Zephyr-devel] make menuconfig for STM32MP157 activating
STM32Cube ?

I am building https://github.com/STMicroelectronics/logicanalyser (RPMSG
and VirtIO example for the STM32MP157 using OpenAMP) for Zephyr and
have been facing the issue of linking with the STM32Cube library functions.

I am using the external arm-none-eabi-gcc compilation toolchain under
Debian/GNU Linux with export ZEPHYR_TOOLCHAIN_VARIANT=cross-
compile
export CROSS_COMPILE=/usr/bin/arm-none-eabi-

The tree structure I have (west init && cd zephyr && west update) has
created modules/hal/stm32/stm32cube/ at the same level than zephyr.

This ST example relies heavily on the STM32Cube framework I had to link
with.
I achieved a functional result by adding in my CMakeLists.txt the following
statement

target_sources(app PRIVATE src/main.c src/rpmsg_hdr.c src/openamp.c
src/mbox_ipcc.c src/rsc_table.c src/copro_sync.c
$ENV{ZEPHYR_BASE}/../modules/hal/stm32/stm32cube/stm32mp1xx/driver
s/src/stm32mp1xx_hal_dma.c
$ENV{ZEPHYR_BASE}/../modules/hal/stm32/stm32cube/stm32mp1xx/driver
s/src/stm32mp1xx_hal_gpio.c
$ENV{ZEPHYR_BASE}/../modules/hal/stm32/stm32cube/stm32mp1xx/driver
s/src/stm32mp1xx_hal_rcc_ex.c
$ENV{ZEPHYR_BASE}/../modules/hal/stm32/stm32cube/stm32mp1xx/driver
s/src/stm32mp1xx_hal_ipcc.c
$ENV{ZEPHYR_BASE}/../modules/hal/stm32/stm32cube/stm32mp1xx/driver
s/src/stm32mp1xx_hal_cortex.c
$ENV{ZEPHYR_BASE}/../modules/hal/stm32/stm32cube/stm32mp1xx/driver
s/src/stm32mp1xx_hal_tim_ex.c
$ENV{ZEPHYR_BASE}/../modules/hal/stm32/stm32cube/stm32mp1xx/driver
s/src/stm32mp1xx_hal_pwr.c
$ENV{ZEPHYR_BASE}/../modules/hal/stm32/stm32cube/stm32mp1xx/driver
s/src/stm32mp1xx_hal_tim.c)

following the advice I read at
https://github.com/intel/zephyr/tree/master/ext/hal/st/stm32cube
stating

"Plus add HAL driver file (when needed):
obj-$(CONFIG_SERIAL_HAS_DRIVER) +=
stm32yyxx/drivers/src/stm32yyxx_hal_uart.o"

This is most probably *not* the right way and hence my question to this list:
if I wish to activate these functions in STM32Cube, make menuconfig in the
build directory shows
-*- <HAS_STM32CUBE>
in red, but then all other subsystems (eg - - <USE_STM32_HAL_DMA> or
- - <USE_STM32_HAL_IPCC>) which I believe would fill the cmake
configuration file properly are disabled and cannot be enabled. I fail to
understand what option prevents me from activating these functionalities.

Could anyone explain what I am doing wrong in this configuration ?

Thank you, Jean-Michel

Re: hci_uart application with flow control disable #uart #samples #ble #hci #nrf52480

Mayank
 

Hi Johan,

Should i go with the Hardware flow control as enable to solve the buffer flow issue ? Not using HWFC could have any other adverse effect?

As my current implementation is based on flow control as disabled, from processor side i have written beacon scanning application which scans beacons for 10 secs and then immediately flushes the UART buffer. So is it sufficient or still it would be better to go with the HWFC.

Thanks,
Mayank

Re: hci_uart application with flow control disable #uart #samples #ble #hci #nrf52480

Johan Hedberg
 

Hi Mayank,

On 18. Feb 2020, at 11.29, Mayank <@mayank_patel> wrote:
I have a doubt regarding one of the sample application of zephyr (samples/bluetooth/hci_uart).
This 'hci_uart' application has Hardware flow control enable by default in its nrf.conf file. (CONFIG_UART_0_NRF_FLOW_CONTROL=y)

I have build this sample app with CONFIG_UART_0_NRF_FLOW_CONTROL=n. So, i have only configured Tx, Rx from zephyr side.

I have one custom board based on IMX6ULL processor, and on that i have connected nordic's nRF52840 chip over UART ( Flashed nRF52840 with above mentioned hci_uart application).
Purpose: To scan BLE beacons for 10 seconds, Sleep for 10 sec, Scan for 10 sec, and so on (Continuous).

From processor side also i have disabled the hardware flow control (Hence,Only using Tx, Rx).

Q1: As i'm not using HW flow control, Can i have any flow control related problem if there will be more number of devices/beacons available for the scanning.
You might get lucky with disabling hardware flow control, however this standard HCI transport officially requires it (see Vol 4, Part A section 3 in Bluetooth Core Specification 5.2).

Q2: Can i implement software flow control in hci_uart application ? If yes then how?
Yes, but it should be its own application rather than an extension of samples/bluetooth/hci_uart. The standard HCI transport for UART in the situation where you don’t have hardware flow control available is is called the Three-wire UART transport protocol and you can find it in Vol 4, Part D of the Bluetooth Core Specification 5.2. We don't currently have a sample application for this, but a contribution would be very welcome. We do have an HCI driver in drivers/bluetooth/hci/h5.c, but that’s the host side implementation of this transport (you’re interested in the controller side).

Q3: What is the meaning of this flag in zephyr confiuration : CONFIG_BT_HCI_ACL_FLOW_CONTROL?
I don’t think I can explain it any better than its Kconfig documentation (please read it if you haven’t!), but it’s not something that’s directly relevant for you regarding the UART setup, since ACL flow control is a higher level construct. Since you’re doing a controller-only build you may want to enable it (the host can then later choose if it wants to use it or not), but this is not going to help you with the HCI transport situation.

Johan

Re: hci_uart application with flow control disable #uart #samples #ble #hci #nrf52480

lairdjm
 

Hi,

> Q1: As i'm not using HW flow control, Can i have any flow control related problem if there will be more number of devices/beacons available for the scanning.

Yes, that is the purpose of flow control, to prevent one device sending data when the over side is unable to handle it. Will you see that issue? We can’t give you an answer to that, it’s application, area and hardware dependant e.g. if your main CPU has a UART buffer size of 16 bytes and is busy with a critical task, the nRF52840 could then send e.g. 20 bytes of data and overflow the UART buffer, then when your CPU is finished with the critical task, it’s lost at least 4 bytes.


> Q2: Can i implement software flow control in hci_uart application ? If yes then how?

The hardware flow control is actually handled in-hardware on the nRF52840, it does not have hardware to support software flow control so if you wanted to add that, you’d have to create all the code for it

Thanks,
Jamie

 

From: devel@... <devel@...> On Behalf Of Mayank via Lists.Zephyrproject.Org
Sent: 18 February 2020 09:29
To: devel@...
Cc: devel@...
Subject: [Zephyr-devel] hci_uart application with flow control disable #ble #hci #nrf52480 #uart #samples

 

EXTERNAL EMAIL: Be careful with attachments and links.

Hi All,

I have a doubt regarding one of the sample application of zephyr (samples/bluetooth/hci_uart).
This 'hci_uart' application has Hardware flow control enable by default in its nrf.conf file. (CONFIG_UART_0_NRF_FLOW_CONTROL=y)

I have build this sample app with CONFIG_UART_0_NRF_FLOW_CONTROL=n. So, i have only configured Tx, Rx from zephyr side.

I have one custom board based on IMX6ULL processor, and on that i have connected nordic's nRF52840 chip over UART ( Flashed nRF52840 with above mentioned hci_uart application).
Purpose: To scan BLE beacons for 10 seconds, Sleep for 10 sec, Scan for 10 sec, and so on (Continuous).

From processor side also i have disabled the hardware flow control (Hence,Only using Tx, Rx).

Q1: As i'm not using HW flow control, Can i have any flow control related problem if there will be more number of devices/beacons available for the scanning.
Q2: Can i implement software flow control in hci_uart application ? If yes then how?
Q3: What is the meaning of this flag in zephyr confiuration : CONFIG_BT_HCI_ACL_FLOW_CONTROL?

NOTE: Currently i'm not observing any problem while scanning around 70 beacons exists in the surrounding environment.

hci_uart application with flow control disable #uart #samples #ble #hci #nrf52480

Mayank
 

Hi All,

I have a doubt regarding one of the sample application of zephyr (samples/bluetooth/hci_uart).
This 'hci_uart' application has Hardware flow control enable by default in its nrf.conf file. (CONFIG_UART_0_NRF_FLOW_CONTROL=y)

I have build this sample app with CONFIG_UART_0_NRF_FLOW_CONTROL=n. So, i have only configured Tx, Rx from zephyr side.

I have one custom board based on IMX6ULL processor, and on that i have connected nordic's nRF52840 chip over UART ( Flashed nRF52840 with above mentioned hci_uart application).
Purpose: To scan BLE beacons for 10 seconds, Sleep for 10 sec, Scan for 10 sec, and so on (Continuous).

From processor side also i have disabled the hardware flow control (Hence,Only using Tx, Rx).

Q1: As i'm not using HW flow control, Can i have any flow control related problem if there will be more number of devices/beacons available for the scanning.
Q2: Can i implement software flow control in hci_uart application ? If yes then how?
Q3: What is the meaning of this flag in zephyr confiuration : CONFIG_BT_HCI_ACL_FLOW_CONTROL?

NOTE: Currently i'm not observing any problem while scanning around 70 beacons exists in the surrounding environment.

Re: make menuconfig for STM32MP157 activating STM32Cube ?

Erwan Gouriou
 

Hi,

Can you check following readme section and see if it answers your point?


Cheers
Erwan

Le sam. 15 févr. 2020 à 17:45, <friedtj@...> a écrit :
I am building https://github.com/STMicroelectronics/logicanalyser (RPMSG
and VirtIO example for the STM32MP157 using OpenAMP) for Zephyr and have been
facing the issue of linking with the STM32Cube library functions.

I am using the external arm-none-eabi-gcc compilation toolchain under
Debian/GNU Linux with
export ZEPHYR_TOOLCHAIN_VARIANT=cross-compile
export CROSS_COMPILE=/usr/bin/arm-none-eabi-

The tree structure I have (west init && cd zephyr && west update)
has created modules/hal/stm32/stm32cube/ at the same level than zephyr.

This ST example relies heavily on the STM32Cube framework I had to link with.
I achieved a functional result by adding in my CMakeLists.txt the following statement

target_sources(app PRIVATE src/main.c src/rpmsg_hdr.c src/openamp.c src/mbox_ipcc.c src/rsc_table.c src/copro_sync.c $ENV{ZEPHYR_BASE}/../modules/hal/stm32/stm32cube/stm32mp1xx/drivers/src/stm32mp1xx_hal_dma.c $ENV{ZEPHYR_BASE}/../modules/hal/stm32/stm32cube/stm32mp1xx/drivers/src/stm32mp1xx_hal_gpio.c $ENV{ZEPHYR_BASE}/../modules/hal/stm32/stm32cube/stm32mp1xx/drivers/src/stm32mp1xx_hal_rcc_ex.c  $ENV{ZEPHYR_BASE}/../modules/hal/stm32/stm32cube/stm32mp1xx/drivers/src/stm32mp1xx_hal_ipcc.c $ENV{ZEPHYR_BASE}/../modules/hal/stm32/stm32cube/stm32mp1xx/drivers/src/stm32mp1xx_hal_cortex.c $ENV{ZEPHYR_BASE}/../modules/hal/stm32/stm32cube/stm32mp1xx/drivers/src/stm32mp1xx_hal_tim_ex.c  $ENV{ZEPHYR_BASE}/../modules/hal/stm32/stm32cube/stm32mp1xx/drivers/src/stm32mp1xx_hal_pwr.c  $ENV{ZEPHYR_BASE}/../modules/hal/stm32/stm32cube/stm32mp1xx/drivers/src/stm32mp1xx_hal_tim.c)

following the advice I read at
https://github.com/intel/zephyr/tree/master/ext/hal/st/stm32cube
stating

"Plus add HAL driver file (when needed):
obj-$(CONFIG_SERIAL_HAS_DRIVER) += stm32yyxx/drivers/src/stm32yyxx_hal_uart.o"

This is most probably *not* the right way and hence my question to this list:
if I wish to activate these functions in STM32Cube, make menuconfig in the build directory
shows
-*- <HAS_STM32CUBE>
in red, but then all other subsystems (eg - - <USE_STM32_HAL_DMA> or
- - <USE_STM32_HAL_IPCC>) which I believe would fill the cmake configuration
file properly are disabled and cannot be enabled. I fail to understand what
option prevents me from activating these functionalities.

Could anyone explain what I am doing wrong in this configuration ?

Thank you, Jean-Michel



Re: add pyocd user scripy cause pylint issue

FrankLi
 

Thanks mbolivar give the solution:
# 'target' is global
# pylint: disable=undefined-variable

make menuconfig for STM32MP157 activating STM32Cube ?

friedtj@...
 

I am building https://github.com/STMicroelectronics/logicanalyser (RPMSG
and VirtIO example for the STM32MP157 using OpenAMP) for Zephyr and have been
facing the issue of linking with the STM32Cube library functions.

I am using the external arm-none-eabi-gcc compilation toolchain under
Debian/GNU Linux with
export ZEPHYR_TOOLCHAIN_VARIANT=cross-compile
export CROSS_COMPILE=/usr/bin/arm-none-eabi-

The tree structure I have (west init && cd zephyr && west update)
has created modules/hal/stm32/stm32cube/ at the same level than zephyr.

This ST example relies heavily on the STM32Cube framework I had to link with.
I achieved a functional result by adding in my CMakeLists.txt the following statement

target_sources(app PRIVATE src/main.c src/rpmsg_hdr.c src/openamp.c src/mbox_ipcc.c src/rsc_table.c src/copro_sync.c $ENV{ZEPHYR_BASE}/../modules/hal/stm32/stm32cube/stm32mp1xx/drivers/src/stm32mp1xx_hal_dma.c $ENV{ZEPHYR_BASE}/../modules/hal/stm32/stm32cube/stm32mp1xx/drivers/src/stm32mp1xx_hal_gpio.c $ENV{ZEPHYR_BASE}/../modules/hal/stm32/stm32cube/stm32mp1xx/drivers/src/stm32mp1xx_hal_rcc_ex.c $ENV{ZEPHYR_BASE}/../modules/hal/stm32/stm32cube/stm32mp1xx/drivers/src/stm32mp1xx_hal_ipcc.c $ENV{ZEPHYR_BASE}/../modules/hal/stm32/stm32cube/stm32mp1xx/drivers/src/stm32mp1xx_hal_cortex.c $ENV{ZEPHYR_BASE}/../modules/hal/stm32/stm32cube/stm32mp1xx/drivers/src/stm32mp1xx_hal_tim_ex.c $ENV{ZEPHYR_BASE}/../modules/hal/stm32/stm32cube/stm32mp1xx/drivers/src/stm32mp1xx_hal_pwr.c $ENV{ZEPHYR_BASE}/../modules/hal/stm32/stm32cube/stm32mp1xx/drivers/src/stm32mp1xx_hal_tim.c)

following the advice I read at
https://github.com/intel/zephyr/tree/master/ext/hal/st/stm32cube
stating

"Plus add HAL driver file (when needed):
obj-$(CONFIG_SERIAL_HAS_DRIVER) += stm32yyxx/drivers/src/stm32yyxx_hal_uart.o"

This is most probably *not* the right way and hence my question to this list:
if I wish to activate these functions in STM32Cube, make menuconfig in the build directory
shows
-*- <HAS_STM32CUBE>
in red, but then all other subsystems (eg - - <USE_STM32_HAL_DMA> or
- - <USE_STM32_HAL_IPCC>) which I believe would fill the cmake configuration
file properly are disabled and cannot be enabled. I fail to understand what
option prevents me from activating these functionalities.

Could anyone explain what I am doing wrong in this configuration ?

Thank you, Jean-Michel