Date   

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

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

Reminder: Zephyr Project: Dev Meeting

When: Thursday, 16 January 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


Re: zephyr_cc_option(-O0) issue in 1.14.99 (nrf52840)

pawel.dunaj@...
 

Hi,

I suggest checking the stack sizes. CONFIG_NO_OPTIMIZATIONS is sometimes used to decide which size to apply. Stack overflow could cause strange issues.
You can enlarge stacks enable stack analysis and see how much you need.

Regards,


Re: zephyr_cc_option(-O0) issue in 1.14.99 (nrf52840)

Abderrezak Mekkaoui <ab.mekka@...>
 

Hi Chris and All,

I replied too quickly. CONFIG_NO_OPTIMIZATIONS=y  only delays the point at which the program hangs.
In my case it starts by displaying data and BLE advertising as expected, but crashes when a BLE connection is attempted.
It still runs as expected if
zephyr_cc_option(-O0)  and CONFIG_NO_OPTIMIZATIONS=y are not used. The zephyr sample
peripheral_esp  behaves the same way.

This is a queer behavior. Any hint is most welcome.

kind regards

Abder

build command:

>west build -b nrf52840_pca10056 src -- -G"Eclipse CDT4 - Ninja" -DCMAKE_ECLIPSE_NINJA_ARGUMENTS=-j100 -DCMAKE_ECLIPSE_VERSION=4.7

original description of the issue:

I had a program than ran with no problems in 1.13. But would crash in 1.14.99 if  zephyr_cc_option(-O0) is present in the CMakeLists.txt file.
The program is based on the peripheral_esp sample. The peripheral_esp sample itself has the same problem: builds and runs if zephyr_cc_option(-O0)
is not present and would crash if it is present. Strangely it does not have any problem with zephyr_cc_option(-On) n=1,2 or 3.
Other programs, not using Bluetooth, have no problem with this option.
Any hints on what I might be doing wrong?

On 1/15/2020 1:46 PM, Abderrezak Mekkaoui wrote:

Thanks Chris.
That works. And using zephyr_cc_option(-O0) with CONFIG_NO_OPTIMIZATIONS=y  does not cause any trouble.
Still seems strange that other program do not seem to bother!

Kind regards

Abder

On 1/15/2020 1:12 PM, Christopher Friedt wrote:

Hi Ab,

On Wed., Jan. 15, 2020, 12:54 p.m. Abderrezak Mekkaoui, <ab.mekka@...> wrote:
I had a program than ran with no problems in 1.13. But would crash in
1.14.99 if  zephyr_cc_option(-O0) is present in the CMakeLists.txt file.

Have you tried using CONFIG_NO_OPTIMIZATIONS=y ? I've found that will achieve the same ends as explicitly changing CMakeLists.txt to use -O0.


Re: zephyr_cc_option(-O0) issue in 1.14.99

Abderrezak Mekkaoui <ab.mekka@...>
 

Thanks Chris.
That works. And using zephyr_cc_option(-O0) with CONFIG_NO_OPTIMIZATIONS=y  does not cause any trouble.
Still seems strange that other program do not seem to bother!

Kind regards

Abder

On 1/15/2020 1:12 PM, Christopher Friedt wrote:

Hi Ab,

On Wed., Jan. 15, 2020, 12:54 p.m. Abderrezak Mekkaoui, <ab.mekka@...> wrote:
I had a program than ran with no problems in 1.13. But would crash in
1.14.99 if  zephyr_cc_option(-O0) is present in the CMakeLists.txt file.

Have you tried using CONFIG_NO_OPTIMIZATIONS=y ? I've found that will achieve the same ends as explicitly changing CMakeLists.txt to use -O0.


Re: zephyr_cc_option(-O0) issue in 1.14.99

Christopher Friedt
 


Hi Ab,

On Wed., Jan. 15, 2020, 12:54 p.m. Abderrezak Mekkaoui, <ab.mekka@...> wrote:
I had a program than ran with no problems in 1.13. But would crash in
1.14.99 if  zephyr_cc_option(-O0) is present in the CMakeLists.txt file.

Have you tried using CONFIG_NO_OPTIMIZATIONS=y ? I've found that will achieve the same ends as explicitly changing CMakeLists.txt to use -O0.


zephyr_cc_option(-O0) issue in 1.14.99

Abderrezak Mekkaoui <ab.mekka@...>
 

Hi All,

I had a program than ran with no problems in 1.13. But would crash in 1.14.99 if  zephyr_cc_option(-O0) is present in the CMakeLists.txt file.
The program is based on the peripheral_esp sample. The peripheral_esp sample itself has the same problem: builds and runs if zephyr_cc_option(-O0)
is not present and would crash if it is present. Strangely it does not have any problem with zephyr_cc_option(-On) n=1,2 or 3.
Other programs, not using Bluetooth, have no problem with this option.
Any hints on what I might be doing wrong?

Thanks

Abderrezak


Output of peripheral_esp sample when build with zephyr_cc_option(-O0):


***** Booting Zephyr OS build zephyr-v1.14.0-2216-g3da2985b2837 *****
Bluetooth initialized
Advertising successfully started
***** USAGE FAULT *****
  Illegal load of EXC_RETURN into PC
***** Hardware exception *****
Current thread ID = 0x20000048
Faulting instruction address = 0x20001e28
Fatal fault in thread 0x20000048! Aborting.


Re: Porting Zephyr HCI Layer

Carles Cufi
 

Hi there,

 

Combining the Bluetooth Host from Nordic with the Zephyr Controller is not an option, because the SoftDevice is hardcoded to contain both Host and Controller and they cannot be decoupled.

I understand that you have your own Host running on FreeRTOS that you want to combine with the Zephyr Link Layer. Porting the Zephyr controller to FreeRTOS is not going to be trivial, but it shouldn’t be too hard either if you are willing to do the work and maintain it. The controller uses mainly bare-metal with some Zephyr-specific primitives mostly in HCI and the ULL.

 

Here you have the following options:

  • Drop your Host, use Zephyr’s
  • Port your Host to Zephyr, replacing Zephyr’s Host. This should be fairly straightforward.
  • Use another open source controller that runs of FreeRTOS (though I am not sure how easy it is to combine the controller in that stack with your Host). See nimBLE: https://github.com/apache/mynewt-nimble

 

Carles

 

From: devel@... <devel@...> On Behalf Of ryan.kayesimmons via Lists.Zephyrproject.Org
Sent: 14 January 2020 22:26
To: Hedberg, Johan <johan.hedberg@...>
Cc: devel@...
Subject: Re: [Zephyr-devel] Porting Zephyr HCI Layer

 

Hi Johan

 

Thank you for your quick reply.

 

Yes, as you mentioned and as I already understand, hci_uart is for separating the controller and host on different chips. 

 

In this situation, I need to run my own Bluetooth host stack on the nrf52840 (same chip) with some hci interface - Nordic does not supply this hci interface which is why I'm looking at Zephyr.

 

The difficulty here is that my Bluetooth host stack is using FreeRTOS.. so as you said, it would be easier to port Zephyr to my Bluetooth host stack than to port the Zephyr LL to FreeRTOS. 

That might be the only way to continue with my issue and to get full access to the hci & link layer? 

 

Kind Regards,

Ryan Kaye-Simmons

 

 

 


From: Hedberg, Johan <johan.hedberg@...>
Sent: Wednesday, January 15, 2020, 1:17 AM
To: ryan.kayesimmons@...
Cc: devel@...
Subject: Re: [Zephyr-devel] Porting Zephyr HCI Layer


Hi Ryan, On 14. Jan 2020, at 9.13, ryan.kayesimmons@... wrote: > I am currently trying to port the Zephyr HCI UART example (for nrf52840_pca10056) to FreeRTOS but and am having some difficulties doing so. The reasoning behind this is that I want to run a Host application, that uses FreeRTOS, What do you mean by a “Host application”? A Bluetooth host application? Using what APIs? > on the same chip. That’s a bit confusing. hci_uart is for cases where the Bluetooth controller and host are on different chips, with a UART transport in between. > Correct me if I’m wrong, but it looks like the Zephyr OS is tightly coupled with the HCI layer and would take a lot of time to decouple and replace with FreeRTOS – is this a fair statement to make? The hci_uart application is a fairly light-weight piece of code that enables one of the possible HCI drivers in Zephyr and then adapts that to the standard UART HCI transport protocol. In the case of the nRF52840 the underlying HCI driver maps to the full native Bluetooth link layer of Zephyr, i.e. that’s where the bulk of the code is, and that’s tightly coupled to Zephyr. > I guess I just want to know if I’ll be wasting a lot of my time if I take this approach! I’m left with many open questions based on your email, but I get the feeling you might want to explore the feasibility of porting your “host application” to Zephyr rather than vice-versa. Johan


NFFS support removal

Puzdrowski, Andrzej
 

NFFS support will be removed from the zephyr-project codebase.

 

It was decided to take such action as NFFS has few serious issue which made it unreliable (Such issues were not fixed since a long time, after deep analyze: need a lot of effort to be fixed).

As Litlefs support is available in the zephyr since while it doesn't make any sense to keep NFFS support as it lost even education value: LitleFS is better substitute.

Littlefs is one of zephyr VFS backend, so application level API is the same as was for NFFS.

 

Regards,

Andrzej

 


Re: ARM Cortex-R user mode -- should system call handlers be running with external interrupts disabled?

Boie, Andrew P
 

Phil,

 

I sent a PR which adds a test for this:

 

https://github.com/zephyrproject-rtos/zephyr/pull/21920

 

It passes on all the emulated targets we have (including Cortex-M), but if this is broken for your target please file a bug in GitHub.

 

Regards,

Andrew

 

From: devel@... <devel@...> On Behalf Of Boie, Andrew P
Sent: Tuesday, January 14, 2020 1:39 PM
To: phil.erwin@...; devel@...
Subject: Re: [Zephyr-devel] ARM Cortex-R user mode -- should system call handlers be running with external interrupts disabled?

 

Interrupts should be unlocked when handling system calls, and indeed a thread in a system call can sleep or be preempted. Sounds like you have found a bug. And a gap in testing, we ought to have a test that validates this.

 

Andrew

 

From: devel@... <devel@...> On Behalf Of phil.erwin@...
Sent: Tuesday, January 14, 2020 4:55 AM
To: devel@...
Subject: [Zephyr-devel] ARM Cortex-R user mode -- should system call handlers be running with external interrupts disabled?

 

I've noticed that on ARM Cortex-R with user mode enabled, that when we enter the system call handlers, such as z_hdlr_k_str_out(), that interrupts are disabled.  It seems to me that external interrupts should be enabled during this time. 

In looking through the Cortex-M support, I don't see where interrupts are enabled there either, so I wanted to poll the community to ask what the expectations are: external interrupts enabled or disabled?

Phil


Re: ARM Cortex-R user mode -- should system call handlers be running with external interrupts disabled?

Boie, Andrew P
 

Interrupts should be unlocked when handling system calls, and indeed a thread in a system call can sleep or be preempted. Sounds like you have found a bug. And a gap in testing, we ought to have a test that validates this.

 

Andrew

 

From: devel@... <devel@...> On Behalf Of phil.erwin@...
Sent: Tuesday, January 14, 2020 4:55 AM
To: devel@...
Subject: [Zephyr-devel] ARM Cortex-R user mode -- should system call handlers be running with external interrupts disabled?

 

I've noticed that on ARM Cortex-R with user mode enabled, that when we enter the system call handlers, such as z_hdlr_k_str_out(), that interrupts are disabled.  It seems to me that external interrupts should be enabled during this time. 

In looking through the Cortex-M support, I don't see where interrupts are enabled there either, so I wanted to poll the community to ask what the expectations are: external interrupts enabled or disabled?

Phil


Re: Porting Zephyr HCI Layer

ryan.kayesimmons@...
 

Hi Johan

Thank you for your quick reply.

Yes, as you mentioned and as I already understand, hci_uart is for separating the controller and host on different chips. 

In this situation, I need to run my own Bluetooth host stack on the nrf52840 (same chip) with some hci interface - Nordic does not supply this hci interface which is why I'm looking at Zephyr.

The difficulty here is that my Bluetooth host stack is using FreeRTOS.. so as you said, it would be easier to port Zephyr to my Bluetooth host stack than to port the Zephyr LL to FreeRTOS. 
That might be the only way to continue with my issue and to get full access to the hci & link layer? 

Kind Regards,
Ryan Kaye-Simmons




From: Hedberg, Johan <johan.hedberg@...>
Sent: Wednesday, January 15, 2020, 1:17 AM
To: ryan.kayesimmons@...
Cc: devel@...
Subject: Re: [Zephyr-devel] Porting Zephyr HCI Layer

Hi Ryan, On 14. Jan 2020, at 9.13, ryan.kayesimmons@... wrote: > I am currently trying to port the Zephyr HCI UART example (for nrf52840_pca10056) to FreeRTOS but and am having some difficulties doing so. The reasoning behind this is that I want to run a Host application, that uses FreeRTOS, What do you mean by a “Host application”? A Bluetooth host application? Using what APIs? > on the same chip. That’s a bit confusing. hci_uart is for cases where the Bluetooth controller and host are on different chips, with a UART transport in between. > Correct me if I’m wrong, but it looks like the Zephyr OS is tightly coupled with the HCI layer and would take a lot of time to decouple and replace with FreeRTOS – is this a fair statement to make? The hci_uart application is a fairly light-weight piece of code that enables one of the possible HCI drivers in Zephyr and then adapts that to the standard UART HCI transport protocol. In the case of the nRF52840 the underlying HCI driver maps to the full native Bluetooth link layer of Zephyr, i.e. that’s where the bulk of the code is, and that’s tightly coupled to Zephyr. > I guess I just want to know if I’ll be wasting a lot of my time if I take this approach! I’m left with many open questions based on your email, but I get the feeling you might want to explore the feasibility of porting your “host application” to Zephyr rather than vice-versa. Johan


Feedback requested on west manifest imports

Bolivar, Marti
 

Hello Zephyr users and developers,

We've just uploaded a pre-release version of west to PyPI with a new
feature: manifest imports. We would like your feedback!

For a short README you can follow to try it out, see:

https://github.com/mbolivar/my-zephyr-app

This new feature lets you import projects from a west.yml file
somewhere else (like zephyr/west.yml) into your own "downstream"
west.yml file.

The import gives you the zephyr repository and all its modules "for
free": you do not have to copy/paste projects from zephyr/west.yml into
your custom file and manually track changes. You can also add your own
repositories or override individual modules if you've got your own
forks, etc. See the README for links to more information.

Please let us know what you think. We'd like to get feedback before
the west 0.7 release, as making big changes after that time will be
harder to do.

Thanks!
Marti


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

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

Reminder: Zephyr Project: APIs

When: Tuesday, 14 January 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,

This week we will focus on a new RFC and GPIO.

- RFC: New counter_get_value() API call
- https://github.com/zephyrproject-rtos/zephyr/issues/21846

- GPIO: Update on progress
- Proposal from Peter Bigot: Port remaining users without testing them on hardware (accepted)
- Look at the PRs with driver conversion (https://github.com/zephyrproject-rtos/zephyr/issues/18530)
- Check users of GPIO APIs: https://github.com/zephyrproject-rtos/zephyr/issues/20017
- Tips for converting users can be found here: https://github.com/zephyrproject-rtos/zephyr/issues/20017#issuecomment-549315497 (thanks Peter!)
- Any additional outstanding PRs to topic-gpio

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: Porting Zephyr HCI Layer

Johan Hedberg
 

Hi Ryan,

On 14. Jan 2020, at 9.13, ryan.kayesimmons@clarinox.com wrote:
I am currently trying to port the Zephyr HCI UART example (for nrf52840_pca10056) to FreeRTOS but and am having some difficulties doing so. The reasoning behind this is that I want to run a Host application, that uses FreeRTOS,
What do you mean by a “Host application”? A Bluetooth host application? Using what APIs?

on the same chip.
That’s a bit confusing. hci_uart is for cases where the Bluetooth controller and host are on different chips, with a UART transport in between.

Correct me if I’m wrong, but it looks like the Zephyr OS is tightly coupled with the HCI layer and would take a lot of time to decouple and replace with FreeRTOS – is this a fair statement to make?
The hci_uart application is a fairly light-weight piece of code that enables one of the possible HCI drivers in Zephyr and then adapts that to the standard UART HCI transport protocol. In the case of the nRF52840 the underlying HCI driver maps to the full native Bluetooth link layer of Zephyr, i.e. that’s where the bulk of the code is, and that’s tightly coupled to Zephyr.

I guess I just want to know if I’ll be wasting a lot of my time if I take this approach!
I’m left with many open questions based on your email, but I get the feeling you might want to explore the feasibility of porting your “host application” to Zephyr rather than vice-versa.

Johan


ARM Cortex-R user mode -- should system call handlers be running with external interrupts disabled?

Phil Erwin Jr
 

I've noticed that on ARM Cortex-R with user mode enabled, that when we enter the system call handlers, such as z_hdlr_k_str_out(), that interrupts are disabled.  It seems to me that external interrupts should be enabled during this time. 

In looking through the Cortex-M support, I don't see where interrupts are enabled there either, so I wanted to poll the community to ask what the expectations are: external interrupts enabled or disabled?

Phil


Porting Zephyr HCI Layer

ryan.kayesimmons@...
 

Hi there,

 

I am currently trying to port the Zephyr HCI UART example (for nrf52840_pca10056) to FreeRTOS but and am having some difficulties doing so. The reasoning behind this is that I want to run a Host application, that uses FreeRTOS, on the same chip.

 

Correct me if I’m wrong, but it looks like the Zephyr OS is tightly coupled with the HCI layer and would take a lot of time to decouple and replace with FreeRTOS – is this a fair statement to make?

I guess I just want to know if I’ll be wasting a lot of my time if I take this approach!

 

Thank you in advance for your response. 😃

 

Kind Regards,

Ryan Kaye-Simmons

 


Re: Pinmux override

Stefan Jaritz
 

Morning,

As Erwan was telling, IMHO the pinmux variant is a good solution. For example if you doing power saving, you might power down parts of you pcb. Just image the case that you have a peripheral communicating via USART. If it is powered down down you should also configure your stm UART pins, to prevent that you stm is powering the IC via the RX, TX lanes. So you need to do this pinmux stuff not only at boot time.

If you image the board startup as just one use case of pin config, because your firmware will have different ones (like production, self test, operational, error state) you can imagine that the generating a static config via dts is not working in most of the cases. For my stm32f4 platform you can perfectly handle pinconfig with the stm32 pinmux port.

for example:

static void uart3_dma_gpio(bool on) {
   const struct pin_config pin_on[] = {
        {STM32_PIN_PC5, STM32F4_PINMUX_FUNC_PC5_USART3_RX},
        {STM32_PIN_PB10, STM32F4_PINMUX_FUNC_PB10_USART3_TX},
        {STM32_PIN_PB13, (STM32_PINMUX_ALT_FUNC_8 | STM32_PUPDR_NO_PULL | STM32_OSPEEDR_LOW_SPEED)},
        {STM32_PIN_PB14, (STM32_PINMUX_ALT_FUNC_7 | STM32_PUPDR_NO_PULL | STM32_OSPEEDR_LOW_SPEED)},
    };

    const struct pin_config pin_off[] = {
        {STM32_PIN_PC5, STM32_MODER_ANALOG_MODE},
        {STM32_PIN_PB10, STM32_MODER_ANALOG_MODE},
        {STM32_PIN_PB13, (STM32_MODER_ANALOG_MODE)},
        {STM32_PIN_PB14, (STM32_MODER_ANALOG_MODE)},
    };
    if (true == on) {
        stm32_setup_pins(pin_on, ARRAY_SIZE(pin_on));
    } else {
        stm32_setup_pins(pin_off, ARRAY_SIZE(pin_off));
    }
}

Stefan

On 11/01/2020 22:17, Marc Herbert wrote:

On 11 Jan 2020, at 12:52, Vincent - VLoTech via Lists.Zephyrproject.Org <vincent=vlotech.nl@lists.zephyrproject.org> wrote:

Hi all,

Device trees are used during compile time within Zephyr.
But what if you want to support several hardware revisions in the same binary?
(E.g. based on stored hw id or so)
To minimize the amount of binaries to distribute when you need to do an update over one or two years.

How should that be managed within zephyr? As most drivers use the provided DT output...
Looks like https://lists.zephyrproject.org/g/devel/topic/61321118



Re: Pinmux override

Marc Herbert
 

On 11 Jan 2020, at 12:52, Vincent - VLoTech via Lists.Zephyrproject.Org <vincent=vlotech.nl@lists.zephyrproject.org> wrote:

Hi all,

Device trees are used during compile time within Zephyr.
But what if you want to support several hardware revisions in the same binary?
(E.g. based on stored hw id or so)
To minimize the amount of binaries to distribute when you need to do an update over one or two years.

How should that be managed within zephyr? As most drivers use the provided DT output...
Looks like https://lists.zephyrproject.org/g/devel/topic/61321118


Re: Pinmux override

Vincent - VLoTech
 

Hi all,

Device trees are used during compile time within Zephyr. 
But what if you want to support several hardware revisions in the same binary? 
(E.g. based on stored hw id or so)
To minimize the amount of binaries to distribute when you need to do an update over one or two years. 

How should that be managed within zephyr? As most drivers use the provided DT output...

Vincent van der Locht

Op 11 jan. 2020 om 16:35 heeft Erwan Gouriou <erwan.gouriou@...> het volgende geschreven:


Hi Allen,

Pinmuxing is one of the remaining areas where device tree is not in use (except for socs with specific pin management such as nrf).
So we still rely on the c definition for this.

Cheers


Le sam. 11 janv. 2020 à 00:28, Allen Curtis <allen@...> a écrit :
I am obviously showing my ignorance here but I thought Zephyr was using device tree for this stuff. 

On Fri, Jan 10, 2020 at 2:28 AM Erwan Gouriou <erwan.gouriou@...> wrote:
Hi,

Modifying board pinmux.c  (along with boards .dst nd Kconfig.defconfig) is indeed the way to enable the device. It cannot be done otherwise.
Once this is done (and tested ok) you can submit the work  in github so we can get it merged in main zephyr tree.

Cheers
Erwan

On Fri, 10 Jan 2020 at 10:51, Joris Offouga <offougajoris@...> wrote:
Hi all,

I am using the stm32f4_disco board and I am trying to use the i2c ports,
but it is not defined in pinmux.c and I must thzn modify this file to
add the I2C configuration. Is there a better way to do this without
modifying the original file?

Best regards,

Joris



--
Best Regards,

Joris Offouga



--
Allen Curtis
Medical Device Architect
Critical Software Solutions, LLC

1541 - 1560 of 8183