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
|
|
Re: add pyocd user scripy cause pylint issue
FrankLi
Thanks mbolivar give the solution:
|
|
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
|
|
SDK 0.11.2 Release
Kumar Gala
Hi,
Some fixes based on usage of SDK v0.11.x and addition of some new xtensa variants to enable work from the Sound Open Firmware Project (https://www.sofproject.org). The SDK can be found here: https://github.com/zephyrproject-rtos/sdk-ng/releases/tag/v0.11.2 Please download and try things out and report any issues. • Fixed issue with setjmp/longjmp not existing on x86 32-bit build • Fixed python support on GDB: NOTE: Since python support is enabled in GDB the host system needs python3.6 installed. Otherwise you might get an error like: arm-zephyr-eabi-gdb: error while loading shared libraries: libpython3.6m.so.1.0: cannot open shared object file: No such file or directory On newer fedora systems this can show up and be fixed by: sudo dnf install python36 • Added support for Intel BDW and BDW Audio DSP xtensa toolchains. • Added support for NXP IMX8 and IMX8M Audio DSP xtensa toolchains. • Updated xtensa targets to GDB 8.3.1 (except S1000) Thanks to all that contributed fixes and enhancements to this version of the SDK. - k
|
|
Re: Getting Started Guide
Tommy Lin (林志聰) <Tommy.Lin@...>
Hi Andrew Sorry, I have attached btmon log to Attachment.
I have found a similar problem as following:
following up above link , I don’t set the static address manually , but it show an abnormal behavior after auto-power root@localhost:~# btattach -B /dev/serial/by-id/usb-FTDI_Quad_RS232-HS-if01-port0 -S 1000000 -P h4 & [1] 4014 Attaching Primary controller to /dev/serial/by-id/usb-FTDI_Quad_RS232-HS-if01-port0 root@localhost:~# Switched line discipline from 0 to 15 Device index 0 attached root@localhost:~# btmgmt --index 0 [hci0]# auto-power Waiting for index 0 to appear [hci0]#
Can Zephyr Kernel: 2.2.0 support nRF51 chip ?
Thank You, Tommy
From: Boie, Andrew P <andrew.p.boie@...>
Sent: Friday, February 14, 2020 3:44 AM To: Tommy Lin (林志聰) <Tommy.Lin@...>; Cufi, Carles <Carles.Cufi@...>; zephyr-devel@... Cc: devel@...; Isaac Chen (陳尚航) <Isaac_Chen@...> Subject: RE: [Zephyr-devel] Getting Started Guide
Tommy,
when reporting issues, either here or in GitHub, can you copy/paste your terminal output instead of posting screen shots?
Andrew
From:
devel@... <devel@...>
On Behalf Of Tommy Lin (???)
Hi Carles, Thanks for your suggestion. Now, I can download code and build it successfully. Kernel: 2.2.0 SDK: 0.11.1
When I burn zephyr.hex into our chip (NRF51824) , and I encounter an issue. In my previous version (kernel: 1.13 SDK: 0.9.5) , the issue is absence .
Could you give us some suggestions.
Thank You Tommy From: Cufi, Carles <Carles.Cufi@...>
Hi there,
Zephyr requires Python 3.6 or later, and from your log you seem to be using Python 3.5.
Please update your Python installation. If you are on Ubuntu something like this should work:
sudo apt install python3.7 sudo update-alternatives --config python3
Carles
From:
devel@... <devel@...>
On Behalf Of Tommy Lin (???) via Lists.Zephyrproject.Org
Hi Zephyr, I following Getting Started Guide . https://docs.zephyrproject.org/latest/getting_started/index.html
In ‘west update’ , I encounter an error:
My PC is Ubuntu 16.04 LTS Could you give us some suggestions
Thank You, Tommy
|
|
Re: Getting Started Guide
Carles Cufi
Hi Tommy,
This doesn’t seem to be an issue with Zephyr or the controller, but with BlueZ. I have copied Luiz, Szymon and Johan, they might be able to help.
Carles
From: Tommy Lin (林志聰)
<Tommy.Lin@...>
Sent: 14 February 2020 07:46 To: Boie, Andrew P <andrew.p.boie@...>; Cufi, Carles <Carles.Cufi@...>; zephyr-devel@... Cc: devel@...; Isaac Chen (陳尚航) <Isaac_Chen@...> Subject: RE: [Zephyr-devel] Getting Started Guide
Hi Andrew Sorry, I have attached btmon log to Attachment.
I have found a similar problem as following:
following up above link , I don’t set the static address manually , but it show an abnormal behavior after auto-power root@localhost:~# btattach -B /dev/serial/by-id/usb-FTDI_Quad_RS232-HS-if01-port0 -S 1000000 -P h4 & [1] 4014 Attaching Primary controller to /dev/serial/by-id/usb-FTDI_Quad_RS232-HS-if01-port0 root@localhost:~# Switched line discipline from 0 to 15 Device index 0 attached root@localhost:~# btmgmt --index 0 [hci0]# auto-power Waiting for index 0 to appear [hci0]#
Can Zephyr Kernel: 2.2.0 support nRF51 chip ?
Thank You, Tommy From: Boie, Andrew P <andrew.p.boie@...>
Tommy,
when reporting issues, either here or in GitHub, can you copy/paste your terminal output instead of posting screen shots?
Andrew
From:
devel@... <devel@...>
On Behalf Of Tommy Lin (???)
Hi Carles, Thanks for your suggestion. Now, I can download code and build it successfully. Kernel: 2.2.0 SDK: 0.11.1
When I burn zephyr.hex into our chip (NRF51824) , and I encounter an issue. In my previous version (kernel: 1.13 SDK: 0.9.5) , the issue is absence .
Could you give us some suggestions.
Thank You Tommy From: Cufi, Carles <Carles.Cufi@...>
Hi there,
Zephyr requires Python 3.6 or later, and from your log you seem to be using Python 3.5.
Please update your Python installation. If you are on Ubuntu something like this should work:
sudo apt install python3.7 sudo update-alternatives --config python3
Carles
From:
devel@... <devel@...>
On Behalf Of Tommy Lin (???) via Lists.Zephyrproject.Org
Hi Zephyr, I following Getting Started Guide . https://docs.zephyrproject.org/latest/getting_started/index.html
In ‘west update’ , I encounter an error:
My PC is Ubuntu 16.04 LTS Could you give us some suggestions
Thank You, Tommy
|
|
Re: Getting Started Guide
Boie, Andrew P
Tommy,
when reporting issues, either here or in GitHub, can you copy/paste your terminal output instead of posting screen shots?
Andrew
From: devel@... <devel@...>
On Behalf Of Tommy Lin (???)
Sent: Thursday, February 13, 2020 3:27 AM To: Cufi, Carles <Carles.Cufi@...>; zephyr-devel@... Cc: devel@...; Isaac Chen (陳尚航) <Isaac_Chen@...> Subject: Re: [Zephyr-devel] Getting Started Guide
Hi Carles, Thanks for your suggestion. Now, I can download code and build it successfully. Kernel: 2.2.0 SDK: 0.11.1
When I burn zephyr.hex into our chip (NRF51824) , and I encounter an issue. In my previous version (kernel: 1.13 SDK: 0.9.5) , the issue is absence .
Could you give us some suggestions.
Thank You Tommy From: Cufi, Carles <Carles.Cufi@...>
Hi there,
Zephyr requires Python 3.6 or later, and from your log you seem to be using Python 3.5.
Please update your Python installation. If you are on Ubuntu something like this should work:
sudo apt install python3.7 sudo update-alternatives --config python3
Carles
From:
devel@... <devel@...>
On Behalf Of Tommy Lin (???) via Lists.Zephyrproject.Org
Hi Zephyr, I following Getting Started Guide . https://docs.zephyrproject.org/latest/getting_started/index.html
In ‘west update’ , I encounter an error:
My PC is Ubuntu 16.04 LTS Could you give us some suggestions
Thank You, Tommy
|
|
Upcoming Event: Zephyr Project: Dev Meeting - Thu, 02/13/2020 8:00am-9:00am, Please RSVP
#cal-reminder
devel@lists.zephyrproject.org Calendar <devel@...>
Reminder: Zephyr Project: Dev Meeting When: Thursday, 13 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
|
|
Re: Getting Started Guide
Tommy Lin (林志聰) <Tommy.Lin@...>
Hi Carles, Thanks for your suggestion. Now, I can download code and build it successfully. Kernel: 2.2.0 SDK: 0.11.1
When I burn zephyr.hex into our chip (NRF51824) , and I encounter an issue. In my previous version (kernel: 1.13 SDK: 0.9.5) , the issue is absence .
Could you give us some suggestions.
Thank You Tommy
From: Cufi, Carles <Carles.Cufi@...>
Sent: Wednesday, February 12, 2020 8:17 PM To: Tommy Lin (林志聰) <Tommy.Lin@...>; zephyr-devel@... Cc: devel@... Subject: RE: Getting Started Guide
Hi there,
Zephyr requires Python 3.6 or later, and from your log you seem to be using Python 3.5.
Please update your Python installation. If you are on Ubuntu something like this should work:
sudo apt install python3.7 sudo update-alternatives --config python3
Carles
From:
devel@... <devel@...>
On Behalf Of Tommy Lin (???) via Lists.Zephyrproject.Org
Hi Zephyr, I following Getting Started Guide . https://docs.zephyrproject.org/latest/getting_started/index.html
In ‘west update’ , I encounter an error:
My PC is Ubuntu 16.04 LTS Could you give us some suggestions
Thank You, Tommy
|
|
Dev-Review Meeting Agenda Feb 13
Kumar Gala
All,
Meeting Minutes: https://docs.google.com/document/d/1vfgwa1oRVuLA0f4VZW9pMBD2n2kf7ZgI9QCw_4s01gA/edit?usp=sharing Agenda: - GitHub PR/Issues: * N/A (None at time of publish, will look at start of meeting - Device Tree: * Continue discussions: (Continued from last week) Roundup of DT agenda items for the dev review meeting from nordic: - doing system initialization in DT dependency ordinal order (I want to discuss this) - issue roundup: - https://github.com/zephyrproject-rtos/zephyr/issues/19285 - https://github.com/zephyrproject-rtos/zephyr/issues/21369 (edited) #19285 devicetree: fixed non-alias reference to specific nodes #21369 devicetree: clearly define constraints on identifier/property name conflicts (New for this week) NODELABEL: - https://github.com/zephyrproject-rtos/zephyr/issues/22555 PATH: - https://github.com/zephyrproject-rtos/zephyr/issues/22554 - usage of aliases for samples/tests - reviewing Github project board - pinmux
|
|
Re: Getting Started Guide
Carles Cufi
Hi there,
Zephyr requires Python 3.6 or later, and from your log you seem to be using Python 3.5.
Please update your Python installation. If you are on Ubuntu something like this should work:
sudo apt install python3.7 sudo update-alternatives --config python3
Carles
From: devel@... <devel@...>
On Behalf Of Tommy Lin (???) via Lists.Zephyrproject.Org
Sent: 12 February 2020 12:59 To: zephyr-devel@... Cc: devel@... Subject: [Zephyr-devel] Getting Started Guide
Hi Zephyr, I following Getting Started Guide . https://docs.zephyrproject.org/latest/getting_started/index.html
In ‘west update’ , I encounter an error:
My PC is Ubuntu 16.04 LTS Could you give us some suggestions
Thank You, Tommy
|
|
Getting Started Guide
Tommy Lin (林志聰) <Tommy.Lin@...>
Hi Zephyr, I following Getting Started Guide . https://docs.zephyrproject.org/latest/getting_started/index.html
In ‘west update’ , I encounter an error:
My PC is Ubuntu 16.04 LTS Could you give us some suggestions
Thank You, Tommy
|
|
Re: ARMv7 Cortex-A port for Xilinx Zynq7000
Immo Birnbaum
Hi Henrik,
I'll keep you updated. Thanks for the offer regarding the pull request preparation, I'll likely get back to you on that :) Regards, Immo
|
|
Re: ARMv7 Cortex-A port for Xilinx Zynq7000
Hi Carlo, Just a quick note that being the ARMv7/Cortex-A still a 32bit arch, that is probably closer to the current ARMv7/Cortex-R work than to my ARMv8/Cortex-A work. To my knowledge, the most significant differences are MMU vs. MPU and the newer interrupt controller in the Cortex-R, which expanded the old controller's basic secure/non-secure model into a multiple-priority model. Other than the FPU stuff, I didn't mess much with the assembly code that implements the context switch. Did you try to use the Zephyr SDK? My memory on that is a bit hazy, as I started back in November, but to my best recollection I followed the standard 'getting started' procedure at first, including the SDK setup. Yet, the first Zephyr-compatible board I came across at work was an NXP eval kit based around a Cortex-M33 (the LPCXPRESSO55S69), and compiling the demos with the supplied cross-compiler failed as it did not yet support the M33. That's how I ended up with the alternative ARM toolchain as described in the "3rd party toolchains" section. I can easily set up a fresh development VM and give the Zephyr SDK another try, as the A9 is a proven piece of hardware that has long been supported. What's the issue with the remaining tests? Fortunately, there's no technical issue here - it's just an issue of me not yet having had time to read up on how the test framework works. Are you able to use QEMU to emulate a working hardware? The QEMU template for the Zynq7000 supports all important components (GIC, TTC, UART) plus the two Ethernet controllers. There's also USB which I'm not looking at right now, plus some SPI/I2C support mostly relevant for flash memory connectivity. While the bitstream programming of the FPGA can be simulated, IP cores such as the GPIO don't seem to be on board, so GPIO won't work while the rest will. IMO the next step is making sure you are able to pass as many tests as possible in a QEMU environment when using the Zephyr SDK.Will do, but prior to that I'll most likely start by updating my codebase and merging my changes into the new AARCH32/AARCH64 structure. I guess with separate assembly code for each architecture's context switch, that part might be a lot more uncluttered compared to what I have right now. Thanks for the advice! Regards, Immo
|
|
Xtensa architecture support in LLVM
Ivan Grokhotkov <ivan@...>
Hi,
Since Zephyr RTOS includes support for the Xtensa architecture, I'd like to bring attention to the Xtensa LLVM backend, which is currently in review on LLVM Phabircator. This backend was developed by Espressif, with the initial targets being ESP8266 and ESP32 chips. As some of the Zephyr developers (mainly from Intel) have access to the Xtensa architecture documentation, we would like to ask for reviews on this series of patches. I think having Xtensa supported in LLVM would also be beneficial for the Zephyr project, as the LLVM backend allows adding new Xtensa core configurations in a much more straightforward way, compared to GCC. Links to the patch series: D64826: [Xtensa 1/10] Recognize Xtensa in triple parsing code. https://reviews.llvm.org/D64826 D64827: [Xtensa 2/10] Add Xtensa ELF definitions. https://reviews.llvm.org/D64827 D64829: [Xtensa 3/10] Add initial version of the Xtensa backend. https://reviews.llvm.org/D64829 D64830: [Xtensa 4/10] Add basic *td files with Xtensa architecture description. https://reviews.llvm.org/D64830 D64831: [Xtensa 5/10] Add Xtensa MCTargetDescr initial functionality. https://reviews.llvm.org/D64831 D64832: [Xtensa 6/10] Add Xtensa basic assembler parser. https://reviews.llvm.org/D64832 D64833: [Xtensa 7/10] Add Xtensa instruction printer. https://reviews.llvm.org/D64833 D64834: [Xtensa 8/10] Add support of the Xtensa shift/load/store/move and processor control instructions. https://reviews.llvm.org/D64834 D64835: [Xtensa 9/10] Add basic support of Xtensa disassembler. https://reviews.llvm.org/D64835 D64836: [Xtensa 10/10] Add relaxations and fixups. Add rest part of Xtensa Core Instructions. https://reviews.llvm.org/D64836 The patches are maintained at https://github.com/espressif/llvm-project. This repository can also be used to submit issues. Thank you, Ivan Grokhotkov Espressif Systems
|
|
Re: ARMv7 Cortex-A port for Xilinx Zynq7000
Immo Birnbaum
Hi Carles,
thanks for those initial pointers! I'll also keep an eye on what's going on regarding the Cortex-R port besides the ARMv8 Cortex-A port, as Carlo mentioned, the ARMv7 Cortex-A and the Cortex-R are quite close relatives.
|
|
Re: ARMv7 Cortex-A port for Xilinx Zynq7000
Henrik Brix Andersen
Hello Immo,
toggle quoted messageShow quoted text
That is great news! Thank you for working on this. I started on add Cortex-A9/Zynq7000 support to Zephyr a couple of weeks ago, but stalled it while awaiting the Cortex-R port (which is very similar) to stabilise. I am very interested in this port and I would be more than happy to help in reviewing and testing a pull request for adding this to mainline Zephyr. I started out with qemu and the xilinx-zynq-a9 machine defintion, but did not get as far as what you describe below. Please keep us posted on any progress and let me know if you need help in creating a pull request for this. Best regards, Brix -- Henrik Brix Andersen
On 11 Feb 2020, at 14.53, Immo Birnbaum <immo.birnbaum@freenet.de> wrote:
|
|
Re: The topic-gpio branch has been merged to master
Piotr Mienkowski
Hi all,
I would like to provide a bit more information about the recent change to the GPIO API. The main drive behind the rework was to support GPIO DTS bindings https://github.com/torvalds/linux/blob/master/include/dt-bindings/gpio/gpio.h as known from Linux DTS. That meant introduction of new flags: - GPIO_ACTIVE_HIGH, GPIO_ACTIVE_LOW - GPIO_OPEN_DRAIN, GPIO_OPEN_SOURCE - GPIO_PULL_UP, GPIO_PULL_DOWN All of the above flags are meant to be located in the DTS, typically at the board level. This allows to decouple application / driver code from the properties of the hardware they happen to work with. As an example, if gpio pin is connected to a button it could be described in the board DTS file as follows: button0: button_0 { gpios = <&gpio0 17 (GPIO_PULL_UP | GPIO_ACTIVE_LOW)>; label = "Push button 0"; }; It means that the GPIO driver will need to enable a pull up on a pin and that the pin is active low. All this is transparent to the application which simply needs to pull in the DTS flags when configuring the pin. To access the flags generated from the DTS at the application level it is best to use the so called DT_ALIAS defines. The special DTS aliases node aliases { sw0 = &button0; }; is a convenient way to give generic application level names to specific DTS nodes. The resulting call in the application code could look like this gpio_pin_configure(dev_button, DT_ALIAS_SW0_GPIOS_PIN, DT_ALIAS_SW0_GPIOS_FLAGS | GPIO_INPUT); To access the flags at the driver level we should ideally be using the so called DT_INST defines. But here the situation is a little bit more complicated. The two new flags that had the biggest impact on the shape of the new GPIO API are GPIO_ACTIVE_HIGH and GPIO_ACTIVE_LOW. They define pin active level known in the new API as logical pin level. From the documentation "If pin is configured as Active High, a low physical level will be interpreted as logical value 0. If pin is configured as Active Low, a low physical level will be interpreted as logical value 1." At the application level the two flags encode cause -> effect relationship. In the above example of a button the GPIO_ACTIVE_LOW flag means that regardless of the specific design of the hardware button and the circuitry surrounding it if the button is pressed the pin will see low physical value. This relationship should be defined in DTS bindings. This level of abstraction is useful not only when building a generic application that reacts to the press of a button or has to turn on an LED but also when building a driver for a well documented external hardware module. Such module, e.g. a sensor connected over I2C bus, can provide an active high interrupt pin that should be routed to a GPIO pin on a SoC. A driver for the hardware module which is using pin logical rather than pin physical level allows for the possibility that the interrupt signal from the hardware module is routed to the GPIO pin via an inverter, e.g. because external module is in a different power domain. Once again the active level of the interrupt pin will be defined in DTS and allows the driver code to be decoupled from the specifics of the PCB design. An application can get / set pin logical level by calling gpio_pin_get, gpio_pin_set functions. It is still possible to access pin physical level, if required, by calling gpio_pin_get_raw, gpio_pin_set_raw functions. All these concepts are not entirely new. The old GPIO API provided flags such as GPIO_INT_ACTIVE_LOW and GPIO_POL_INV which aimed to achieve similar goal. However, they were not very well documented and not consistently implemented. Other modifications to the GPIO API include: - Interrupt configuration was moved to the dedicated gpio_pin_interrupt_configure() function. Configuring interrupts via gpio_pin_configure() is still supported but this feature will be removed in future releases. - New set of flags allows to define arbitrary interrupt configuration (if supported by the driver) based on pin physical or logical levels. The include/drivers/gpio.h contains in fact two sets of interrupt related flags, one targeted at the driver developers and the other at the users of the API. Only the latter is documented at https://docs.zephyrproject.org/latest/reference/peripherals/gpio.html and should be used by the applications. - New set of port functions that operate simultaneously on multiple pins that belong to the same controller. - New set of flags to configure pin as input, output or in/out as well as set output initial state. Majority of the old GPIO API has been deprecated and, to limit impact on the code size, re-implemented in terms of the new API. While the care was taken to preserve backward compatibility due to the scope of the work it was not possible to fully achieve this goal. We recommend to switch to the new GPIO API as soon as possible. Areas where the deprecated API may behave differently to the original old implementation are: - Configuration of pin interrupts, especially involving GPIO_INT_ACTIVE_LOW and GPIO_POL_INV flags. - Behavior of gpio_pin_configure() when invoked without interrupt related flags. In the new implementation of this deprecated functionality the interrupts remain unmodified. In the original implementation some of the GPIO drivers would disable the interrupts. Regards, Piotr
|
|
Upcoming Event: Zephyr Project: APIs - Tue, 02/11/2020 9:00am-10:00am, Please RSVP
#cal-reminder
devel@lists.zephyrproject.org Calendar <devel@...>
Reminder: Zephyr Project: APIs When: Tuesday, 11 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 Live meeting minutes: https://docs.google.com/
|
|
API meeting: agenda
Carles Cufi
Hi all,
The topics for today: - New API: DAC - https://github.com/zephyrproject-rtos/zephyr/pull/21805 - Overall post-GPIO triage and decision on what to tackle next 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
|
|