Date   

API meeting: Agenda

Carles Cufi
 

Hi all,

I cannot attend today so Peter Bigot will kindly chair the meeting instead.

The discussion will be centered exclusively around the completion of the GPIO transition into its new API.

- Driver conversion check:
- https://github.com/zephyrproject-rtos/zephyr/issues/18530

- Users conversion check:
- https://github.com/zephyrproject-rtos/zephyr/issues/20017

- Walk-through of the proposed merge procedure by the topic-gpio branch active manager, Peter Bigot:
- https://github.com/zephyrproject-rtos/zephyr/issues/21789#issuecomment-578810880
- Establish a timeline for completion of the full process

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: Sample app hello_world fails with z_arm_usage_fault in arm_core_mpu_enable when linked in RAM

robmcgurrin@...
 

Hi Maureen,
Thank you for your reply. I will give it a try.  Just to follow up, what if I want to run my code out of SDRAM?
Thanks
Rob


On Mon, Jan 27, 2020 at 4:04 PM Maureen Helm (OSS) <maureen.helm@...> wrote:

Hi Rob,

You can set the following Kconfigs in your prj.conf:

 

CONFIG_CODE_ITCM=y

CONFIG_DATA_DTCM=y

 

See soc/arm/nxp_imx/rt/Kconfig.soc for more details.

 

Maureen

 

From: users@... <users@...> On Behalf Of robmcgurrin via Lists.Zephyrproject.Org
Sent: Friday, January 24, 2020 12:22 PM
To: users@...
Cc: users@...
Subject: [Zephyr-users] Sample app hello_world fails with z_arm_usage_fault in arm_core_mpu_enable when linked in RAM

 

Hi,
I am running on a nxp i.mx RT1064 eval, board mimxrt1064_evk.
I created a custom linker file to link the app to SRAM.  Here are the mods I made to the default linker file include/arch/arm/aarch32/cortex_m/scripts/linker.ld to force everything into SRAM:

#ifdef CONFIG_XIP

  #define ROMABLE_REGION SRAM

  #define RAMABLE_REGION SRAM

#else

  #define ROMABLE_REGION SRAM

  #define RAMABLE_REGION SRAM

#endif

And then I added this to prj.conf

CONFIG_HAVE_CUSTOM_LINKER_SCRIPT=y

CONFIG_CUSTOM_LINKER_SCRIPT="foo_linker.ld"

When I run the app I get this fault:
z_arm_usage_fault () at arch/arm/core/aarch32/fault_s.S:92      

Any suggestions?
Is there a better way to link my app to RAM?

Thanks in advance,
Rob


Bluetooth peripheral - correct way of updating internal characteristic's value

Martin Kozusky
 

Hello,
I have defined characteristic, which can be read, it's user_data is pointing to buffer1.
Now when I want to read the data by central, Characteristic Attribute read callback is called.
In this callback, I can  do something like in "samples/bluetooth/peripheral"

static ssize_t read_vnd(struct bt_conn *conn, const struct bt_gatt_attr *attr,
            void *buf, u16_t len, u16_t offset)
{
    const char *value = attr->user_data;

    return bt_gatt_attr_read(conn, attr, buf, len, offset, value,
                 strlen(value));
}

and just return the content of buffer1 itself (if  I am correct and attr->user_data points to it)

now the question is - I have a new content for buffer1 prepared in buffer2 and in procedure called from main(), I do memcpy(buffer1,buffer2,sizeof(buffer1)).  Can it happen, that the memcpy instructions are interrupted by read callback, so that buffer1 is inconsistent and I should use some locking mechanism (which one?) or is memcpy safe operation and buffer1 should always be ok?

Or is there any other suggested way of updating characteristic's value than just modifying the buffer1 directly?

Thanks.


Re: Sample app hello_world fails with z_arm_usage_fault in arm_core_mpu_enable when linked in RAM

Maureen Helm
 

Hi Rob,

You can set the following Kconfigs in your prj.conf:

 

CONFIG_CODE_ITCM=y

CONFIG_DATA_DTCM=y

 

See soc/arm/nxp_imx/rt/Kconfig.soc for more details.

 

Maureen

 

From: users@... <users@...> On Behalf Of robmcgurrin via Lists.Zephyrproject.Org
Sent: Friday, January 24, 2020 12:22 PM
To: users@...
Cc: users@...
Subject: [Zephyr-users] Sample app hello_world fails with z_arm_usage_fault in arm_core_mpu_enable when linked in RAM

 

Hi,
I am running on a nxp i.mx RT1064 eval, board mimxrt1064_evk.
I created a custom linker file to link the app to SRAM.  Here are the mods I made to the default linker file include/arch/arm/aarch32/cortex_m/scripts/linker.ld to force everything into SRAM:

#ifdef CONFIG_XIP

  #define ROMABLE_REGION SRAM

  #define RAMABLE_REGION SRAM

#else

  #define ROMABLE_REGION SRAM

  #define RAMABLE_REGION SRAM

#endif

And then I added this to prj.conf

CONFIG_HAVE_CUSTOM_LINKER_SCRIPT=y

CONFIG_CUSTOM_LINKER_SCRIPT="foo_linker.ld"

When I run the app I get this fault:
z_arm_usage_fault () at arch/arm/core/aarch32/fault_s.S:92      

Any suggestions?
Is there a better way to link my app to RAM?

Thanks in advance,
Rob


Re: Feedback requested on west manifest imports

Bolivar, Marti
 

Hello,

I've cut a new west pre-release today (0.6.99.dev5) which is feature complete for manifest imports.

The main new feature since 0.6.99.dev4 is you can now use whitelists and blacklists to filter what projects you import, with a slight change of plan from the original proposal which is reflected in the documentation.

We'd like to wrap up this west release in the next week or two, so if you have any more feedback, please let us know!

This introductory file is still valid:
https://github.com/mbolivar/my-zephyr-app/blob/master/README.rst

The working documentation build is still here:
https://builds.zephyrproject.org/zephyrproject-rtos/zephyr/20433/docs/guides/west/manifest.html#manifest-imports

You may need to clear your browser cache and reload to get the latest build.

Thanks,
Marti


Sample app hello_world fails with z_arm_usage_fault in arm_core_mpu_enable when linked in RAM

robmcgurrin@...
 

Hi,
I am running on a nxp i.mx RT1064 eval, board mimxrt1064_evk.
I created a custom linker file to link the app to SRAM.  Here are the mods I made to the default linker file include/arch/arm/aarch32/cortex_m/scripts/linker.ld to force everything into SRAM:
#ifdef CONFIG_XIP
  #define ROMABLE_REGION SRAM
  #define RAMABLE_REGION SRAM
#else
  #define ROMABLE_REGION SRAM
  #define RAMABLE_REGION SRAM
#endif

And then I added this to prj.conf
CONFIG_HAVE_CUSTOM_LINKER_SCRIPT=y
CONFIG_CUSTOM_LINKER_SCRIPT="foo_linker.ld"

When I run the app I get this fault:
z_arm_usage_fault () at arch/arm/core/aarch32/fault_s.S:92      

Any suggestions?
Is there a better way to link my app to RAM?

Thanks in advance,
Rob



Re: Windows hosted development

Carles Cufi
 

Hi Peter,

 

As you will have noticed in our Getting Started Guide for Windows (https://docs.zephyrproject.org/latest/getting_started/index.html), we only really propose two solutions:

 

  • Using native cmd.exe (default, recommended)
  • Using WSL (boils down to then following the Linux instructions, it is stated as non-recommended)

 

So I really don’t think that the statement “Getting started guide has too many open ended solutions for windows host” is accurate.

 

Regarding your requirements:

 

Windows IDE-support of some kind, such as visual studio or eclipse,

including both build and debug working out of the box.

 

Those are easily achieved using the default cmd.exe instructions and then either Eclipse or VS Code.

In fact, the section describing Eclipse debugging assumes running on a Windows host:

https://docs.zephyrproject.org/latest/application/index.html?highlight=eclipse#eclipse-debugging

 

If you’d like to contribute instructions on how to use VS Code instead, please do so as a pull request.

A starting point for that might be: https://github.com/bus710/zephyr-rtos-development-in-linux

Most of the instructions in that GitHub repo should apply to Windows.

 

Regards,

 

Carles

 

From: users@... <users@...> On Behalf Of PeterFromSwe via Lists.Zephyrproject.Org
Sent: 23 January 2020 15:45
To: users@...
Cc: users@...
Subject: [Zephyr-users] Windows hosted development

 

Hi

 

Are options for windows development documented somewhere. Getting started guide has too many open ended solutions for windows host I think.

 

There are so many alternatives such as

Two separate physical boxes including everything. Turn chair to switch...

Windows host with some remote desktop to physical machine.

Windows host with some  remote desktop to virtualmachine.

Windows host with shared folders to virtualmachine and ssh.

Windows host with linux subsystem

Windows host with CMD 

(Possibly Linux host combinations as well but that is another topic...)

 

What is important to achieve is

Windows IDE-support of some kind, such as visual studio or eclipse,

including both build and debug working out of the box.

 

Riot has a convenient virtual machine (through vagrant) for builds and windows hosted debugging in eclipse supported through shared folders to vm. Maybe some inspiration from there?

 

Regards

/Peter


SDK 0.11.0 Release

Kumar Gala
 

Hi,

Latest version of the SDK can be found here:

https://github.com/zephyrproject-rtos/sdk-ng/releases/tag/v0.11.0

Please download and try things out and report any issues.

General:

• Replaced riscv32 tools with multilib for riscv64 toolchain
• Dropped package of MIPS toolchain at this point
• Removed x86 IAMCU toolchain
• Improved install process / packaging of tools
• can get individual arch toolchains
• don't need to install as root
• prompt for setting up env for you
• Replaced multiple x86 toolchains with single x86_64 toolchain for 32 & 64-bit
• Improve support for building on Ubuntu 18.04 host
• ARM aarch64 support
• Added SPARC support [experimental]
OpenOCD:

• Bump baseline to 20200116
• Removed support for Quark
• Various ARC fixes/updates
QEMU:

• Bump to version 4.2.0
• Pull in Xilinx Cortex-R support
• Pull in LEON2 SPARC support
GCC:

• Bumped to GCC 9.2.0
Host Tools:

• Removed sound-open-firmware-tools as it wasnt used
NEWLIB:

• Added nano-variant builds
• Enabled long-long support in full newlib build
• Support newlib retargetable locking configuration

Thanks to all that contributed fixes and enhancements to this version of the SDK.

- k


Windows hosted development

PeterFromSwe
 

Hi

Are options for windows development documented somewhere. Getting started guide has too many open ended solutions for windows host I think.

There are so many alternatives such as
Two separate physical boxes including everything. Turn chair to switch...
Windows host with some remote desktop to physical machine.
Windows host with some  remote desktop to virtualmachine.
Windows host with shared folders to virtualmachine and ssh.
Windows host with linux subsystem
Windows host with CMD 
(Possibly Linux host combinations as well but that is another topic...)

What is important to achieve is
Windows IDE-support of some kind, such as visual studio or eclipse,
including both build and debug working out of the box.

Riot has a convenient virtual machine (through vagrant) for builds and windows hosted debugging in eclipse supported through shared folders to vm. Maybe some inspiration from there?

Regards
/Peter


UART DFU from nRF9160 to nRF52840

ljaynes87@...
 

I am looking to DFU an nrf52840 over UART from an nRF9160. The board is set up similar to the Thingy:91. The firmware will be downloaded over LTE on the 9160 and will need to be sent over to the 52840 via UART. Would be best place to start be the smp_svr sample? I know the sample instructions suggest using the mcumgr Command-Line Tool but I need to do this from the 9160. Does the smp_svr provide support for the 9160 to run the DFU commands and start an update on the 52840?


Re: API meeting: agenda

Carles Cufi
 

Hi all,

I'd like to amend the agenda for today's meeting with the following PRs which have been waiting for resolution for a while:

- PR: Validate pin ordinals in wrapper functions
- https://github.com/zephyrproject-rtos/zephyr/pull/20115

- PR: Add discussion of terms that define API behavior
- https://github.com/zephyrproject-rtos/zephyr/pull/21678

Regards,

Carles

-----Original Message-----
From: devel@lists.zephyrproject.org <devel@lists.zephyrproject.org> On
Behalf Of Cufi, Carles via Lists.Zephyrproject.Org
Sent: 20 January 2020 18:05
To: devel@lists.zephyrproject.org; users@lists.zephyrproject.org
Cc: devel@lists.zephyrproject.org
Subject: [Zephyr-devel] API meeting: agenda

Hi all,

Tomorrow we will discuss an RFC that is ready to be merged, two items
that were raised in last week's TSC and we will check on progress with
the GPIO porting.

- RFC (ready to merge): on-off service request and release
- https://github.com/zephyrproject-rtos/zephyr/pull/21090

- Discussion: Stability documentation for APIs. Should it be documented
in Doxygen?

- Discussion: What exactly is subject to the API lifecycle deprecation
policies described in
https://docs.zephyrproject.org/latest/development_process/api_lifecycle.
html?
- Options:
- APIs only
- APIs, Kconfig options, DeviceTree format
- APIs, Kconfig options, DeviceTree format, subsystems, drivers,
boards and SoCs

- GPIO update (users)
- https://github.com/zephyrproject-rtos/zephyr/issues/20017

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: Signaling/Messaging Userspace from Kernel

Justin Huang
 

Thank you Andrew very much for the explanation! Very helpful.

Justin


From: Boie, Andrew P <andrew.p.boie@...>
Sent: Sunday, January 19, 2020 5:49 PM
To: Justin Huang <justin.y.huang@...>; users@... <users@...>
Subject: RE: [Zephyr-users] Signaling/Messaging Userspace from Kernel
 
  • I see some examples using callback functions, but wonder if that is a good practice: it is generally a security risk to run a function provided by a userspace application in the supervisor mode.

 

If you look closely you will see that there is no capability for user mode functions to install a callback handler. This type of operation is supervisor mode only.

 

  • Could someone shed some light on ways in Zephyr for Kernel to signal, or send a message to, threads running in the userspace?

 

In the callback handler the application has registered from supervisor mode (typically at application initialization), use an IPC object to wake up a user thread for further processing.

 

There’s some example code in samples/userspace/prod_consumer

 

This is something we’d like to iterate on further so if you can come up with some scenarios that you don’t think are well supported please file GH enhancement tickets and assign to  me for further discussion.

 

HTH,

Andrew

 

 

From: users@... <users@...> On Behalf Of Justin Huang
Sent: Saturday, January 18, 2020 10:38 AM
To: users@...
Subject: [Zephyr-users] Signaling/Messaging Userspace from Kernel

 

Hi,

 

Could someone shed some light on ways in Zephyr for Kernel to signal, or send a message to, threads running in the userspace?

 

I see some examples using callback functions, but wonder if that is a good practice: it is generally a security risk to run a function provided by a userspace application in the supervisor mode.

 

Any thoughts/pointers/suggestions would be greatly appreciated.

 

Many thanks in advance and 

with kind regards,

 

Justin


API meeting: agenda

Carles Cufi
 

Hi all,

Tomorrow we will discuss an RFC that is ready to be merged, two items that were raised in last week's TSC and we will check on progress with the GPIO porting.

- RFC (ready to merge): on-off service request and release
- https://github.com/zephyrproject-rtos/zephyr/pull/21090

- Discussion: Stability documentation for APIs. Should it be documented in Doxygen?

- Discussion: What exactly is subject to the API lifecycle deprecation policies described in https://docs.zephyrproject.org/latest/development_process/api_lifecycle.html?
- Options:
- APIs only
- APIs, Kconfig options, DeviceTree format
- APIs, Kconfig options, DeviceTree format, subsystems, drivers, boards and SoCs

- GPIO update (users)
- https://github.com/zephyrproject-rtos/zephyr/issues/20017

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: Signaling/Messaging Userspace from Kernel

Boie, Andrew P
 

  • I see some examples using callback functions, but wonder if that is a good practice: it is generally a security risk to run a function provided by a userspace application in the supervisor mode.

 

If you look closely you will see that there is no capability for user mode functions to install a callback handler. This type of operation is supervisor mode only.

 

  • Could someone shed some light on ways in Zephyr for Kernel to signal, or send a message to, threads running in the userspace?

 

In the callback handler the application has registered from supervisor mode (typically at application initialization), use an IPC object to wake up a user thread for further processing.

 

There’s some example code in samples/userspace/prod_consumer

 

This is something we’d like to iterate on further so if you can come up with some scenarios that you don’t think are well supported please file GH enhancement tickets and assign to  me for further discussion.

 

HTH,

Andrew

 

 

From: users@... <users@...> On Behalf Of Justin Huang
Sent: Saturday, January 18, 2020 10:38 AM
To: users@...
Subject: [Zephyr-users] Signaling/Messaging Userspace from Kernel

 

Hi,

 

Could someone shed some light on ways in Zephyr for Kernel to signal, or send a message to, threads running in the userspace?

 

I see some examples using callback functions, but wonder if that is a good practice: it is generally a security risk to run a function provided by a userspace application in the supervisor mode.

 

Any thoughts/pointers/suggestions would be greatly appreciated.

 

Many thanks in advance and 

with kind regards,

 

Justin


Signaling/Messaging Userspace from Kernel

Justin Huang
 

Hi,

Could someone shed some light on ways in Zephyr for Kernel to signal, or send a message to, threads running in the userspace?

I see some examples using callback functions, but wonder if that is a good practice: it is generally a security risk to run a function provided by a userspace application in the supervisor mode.

Any thoughts/pointers/suggestions would be greatly appreciated.

Many thanks in advance and 
with kind regards,

Justin


Re: Removing an item from the Device tree

Lawrence King
 

Excellent solution. Thank you.

Lawrence King
Principal Developer
+1(416)627-7302

-----Original Message-----
From: Kumar Gala <kumar.gala@linaro.org>
Sent: Wednesday, January 15, 2020 9:52 AM
To: Lawrence King <lawrence.king@irdeto.com>
Cc: Zephyr-users@lists.zephyrproject.org
Subject: Re: [Zephyr-users] Removing an item from the Device tree

You can use /delete-property/, something like:

&uart0 {
/delete-property/ rts-pin;
/delete-property/ cts-pin;
};

In your overlay should work.

- k


On Jan 15, 2020, at 8:49 AM, Lawrence King <lawrence.king@irdeto.com> wrote:

I have a little problem with the device tree

In zephyrproject/zephyr/boards/arm/nrf52840_mdk/nrf52840_mdk.dts the uart is defined as:

&uart0 {
compatible = "nordic,nrf-uart";
current-speed = <115200>;
status = "okay";
tx-pin = <20>;
rx-pin = <19>;
rts-pin = <5>;
cts-pin = <7>;
};

Which works just fine. However I am not using the RTS and CTS pin features of the UART, and I need to use the pins for other things. I can simply go into the DTS file and comment out the two pins:

&uart0 {
compatible = "nordic,nrf-uart";
current-speed = <115200>;
status = "okay";
tx-pin = <20>;
rx-pin = <19>;
/* rts-pin = <5>; */
/* cts-pin = <7>; */
};

And all is good. However I would prefer to use an overlay in my local working directory instead of making changes to the zephyr tree. I did try redefining uart0 in the local overlay, but RTS and CTS are still there.

What is the right way to remove RTS and CTS?

Lawrence King
Principal Developer
Connected Transport Market Unit
https://www.Irdeto.com
+1(416)627-7302

<image001.png> <image003.png> <image005.png> <image007.png> <image009.png> <image011.png>

CONFIDENTIAL: This e-mail and any attachments are confidential and intended solely for the use of the individual(s) to whom it is addressed. It can contain proprietary confidential information and be subject to legal privilege and/or subject to a non-disclosure Agreement. Unauthorized use, disclosure or copying is strictly prohibited. If you are not the/an addressee and are in possession of this e-mail, please delete the message and notify us immediately. Please consider the environment before printing this e-mail. Thank you.




Re: Removing an item from the Device tree

Kumar Gala
 

You can use /delete-property/, something like:

&uart0 {
/delete-property/ rts-pin;
/delete-property/ cts-pin;
};

In your overlay should work.

- k

On Jan 15, 2020, at 8:49 AM, Lawrence King <lawrence.king@irdeto.com> wrote:

I have a little problem with the device tree

In zephyrproject/zephyr/boards/arm/nrf52840_mdk/nrf52840_mdk.dts the uart is defined as:

&uart0 {
compatible = "nordic,nrf-uart";
current-speed = <115200>;
status = "okay";
tx-pin = <20>;
rx-pin = <19>;
rts-pin = <5>;
cts-pin = <7>;
};

Which works just fine. However I am not using the RTS and CTS pin features of the UART, and I need to use the pins for other things. I can simply go into the DTS file and comment out the two pins:

&uart0 {
compatible = "nordic,nrf-uart";
current-speed = <115200>;
status = "okay";
tx-pin = <20>;
rx-pin = <19>;
/* rts-pin = <5>; */
/* cts-pin = <7>; */
};

And all is good. However I would prefer to use an overlay in my local working directory instead of making changes to the zephyr tree. I did try redefining uart0 in the local overlay, but RTS and CTS are still there.

What is the right way to remove RTS and CTS?

Lawrence King
Principal Developer
Connected Transport Market Unit
https://www.Irdeto.com
+1(416)627-7302

<image001.png> <image003.png> <image005.png> <image007.png> <image009.png> <image011.png>

CONFIDENTIAL: This e-mail and any attachments are confidential and intended solely for the use of the individual(s) to whom it is addressed. It can contain proprietary confidential information and be subject to legal privilege and/or subject to a non-disclosure Agreement. Unauthorized use, disclosure or copying is strictly prohibited. If you are not the/an addressee and are in possession of this e-mail, please delete the message and notify us immediately. Please consider the environment before printing this e-mail. Thank you.




Removing an item from the Device tree

Lawrence King
 

I have a little problem with the device tree

 

In zephyrproject/zephyr/boards/arm/nrf52840_mdk/nrf52840_mdk.dts the uart is defined as:

 

&uart0 {

        compatible = "nordic,nrf-uart";

        current-speed = <115200>;

        status = "okay";

        tx-pin = <20>;

        rx-pin = <19>;

       rts-pin = <5>;

        cts-pin = <7>;

};

 

Which works just fine. However I am not using the RTS and CTS pin features of the UART, and I need to use the pins for other things. I can simply go into the DTS file and comment out the two pins:

 

&uart0 {

        compatible = "nordic,nrf-uart";

        current-speed = <115200>;

        status = "okay";

        tx-pin = <20>;

        rx-pin = <19>;

/*      rts-pin = <5>;  */

/*      cts-pin = <7>;  */

};

 

And all is good. However I would prefer to use an overlay in my local working directory instead of making changes to the zephyr tree. I did try redefining uart0 in the local overlay, but RTS and CTS are still there.

 

What is the right way to remove RTS and CTS?

 

Lawrence King

Principal Developer

Connected Transport Market Unit

https://www.Irdeto.com

+1(416)627-7302

 

1  2 - linkedin  3 - instagram  4 - youtube  6 - facebook  7

            

CONFIDENTIAL: This e-mail and any attachments are confidential and intended solely for the use of the individual(s) to whom it is addressed. It can contain proprietary confidential information and be subject to legal privilege and/or subject to a non-disclosure Agreement. Unauthorized use, disclosure or copying is strictly prohibited. If you are not the/an addressee and are in possession of this e-mail, please delete the message and notify us immediately. Please consider the environment before printing this e-mail. Thank you.

 

 

 


Re: NVS on flash with erase page size 64k or larger #nvs

Puzdrowski, Andrzej <Andrzej.Puzdrowski@...>
 

NVS on flash with erase page size 64k or larger #nvs

 Marco

Jan 2   

 

  • Hi there

    > In my application I try to use NVS on an external SPI flash (M25P16) which has an erase page size of 64k.

    > As I realised, NVS seems to have some limit on its maximum sector size of just below those 64k, since the variable storing it is an u16_t.

    > Is there any workaround to get this combination to work anyway, or is even an enhancement planned, to overcome this limit?
    > Since there are still quite a few memories on the market with page sizes exceeding those 64k it might be interesting generally.

    > Thanks and regards.

 

Hi.

 

64k sector is known limitation – it is not planed by us to support more right now. Although a patch witch configurable extension will be accepted.

(a I know the code, it shouldn’t be hard to add such extension).

AndrzejR

 


Re: Feedback requested on west manifest imports

Jørn Villesen Christensen <jvc@...>
 

On 14/01/2020 19:33, Bolivar, Marti wrote:
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!

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.
Just had a read through your documentation; it looks nice. Have not
tested the code, but judging from the documentation, it looks useful.

Thank you :-)

~Jørn

841 - 860 of 2707