Date   

How to parse and read JSON file correctly?

adnan
 

Hi guys,

I am using the nRF52832 board and I want to parse and read my JSON file. I don't have too much experience working with cJSON and here you will find my simple code where I try to understand how to define things properly. I will appreciate a lot if you can help me with some advice or better if you can suggest me where I made errors.

Best regards,

Adnan.


Re: [RFC] SMP support for RISC-V privilege architecture

Boie, Andrew P
 

(*)QEMU RV32 virt pc:
https://github.com/zephyrproject-rtos/zephyr/pull/28749
That PR looks fine. But you definitely will have some work to do to get SMP working on Risc-V, starting with changing the arch to select CONFIG_SWITCH, and then implement arch_start_cpu(), arch_curr_cpu(), etc.

But I don't understand Zephyr's SMP mechanism perfectly and don't know
required conditions (Ex. regression tests) if I want to change these area.
There are an assortment of tests with 'smp' in their tags, defined by testcase.yaml.

So you can do:

sanitycheck -p <your target name> -t smp

To quickly run these.

HTH
Andrew

-----Original Message-----
From: devel@... <devel@...> On
Behalf Of Katsuhiro Suzuki
Sent: Tuesday, October 6, 2020 1:54 AM
To: zephyr-devel <zephyr-devel@...>
Subject: [Zephyr-devel] [RFC] SMP support for RISC-V privilege architecture

Hello All,

I'm working on SMP support for RISC-V privilege architecture.
https://github.com/katsuster/zephyr/tree/riscv_virt_pc_smp

It seems worked well on QEMU RV32 virt pc (*) porting.
(RV64 not tested yet)

But I don't understand Zephyr's SMP mechanism perfectly and don't know
required conditions (Ex. regression tests) if I want to change these area.

I'm welcome comments or review of my patch.



Command line:
qemu-system-riscv32 -nographic -machine virt -net none \
-chardev stdio,id=con,mux=on -serial chardev:con \
-mon chardev=con,mode=readline -kernel zephyr/zephyr.elf \
-cpu rv32 -smp cpus=4 -bios none

Best Regards,
Katsuhiro Suzuki




Re: [RFC] SMP support for RISC-V privilege architecture

Katsuhiro Suzuki
 

Hello Kumar,

Sorry for multi posting. Zephyr ML has very long delay to deliver my mail...??

Anyway, thanks a lot for your comment.

On 2020/10/06 23:57, Kumar Gala wrote:

On Oct 6, 2020, at 4:04 AM, Katsuhiro Suzuki <katsuhiro@...> wrote:

Hello All,

I'm working on SMP support for RISC-V privilege architecture.
https://github.com/katsuster/zephyr/tree/riscv_virt_pc_smp

It seems worked well on QEMU RV32 virt pc (*) porting.
(RV64 not tested yet)

But I don't understand Zephyr's SMP mechanism perfectly and
don't know required conditions (Ex. regression tests) if I
want to change these area.

I'm welcome comments or review of my patch.

(*)QEMU RV32 virt pc:
https://github.com/zephyrproject-rtos/zephyr/pull/28749

Diffs of config from default:
CONFIG_RISCV_USE_SWITCH=y (added by me)
CONFIG_SMP=y
CONFIG_MP_NUM_CPUS=4

Command line:
qemu-system-riscv32 -nographic -machine virt -net none \
-chardev stdio,id=con,mux=on -serial chardev:con \
-mon chardev=con,mode=readline -kernel zephyr/zephyr.elf \
-cpu rv32 -smp cpus=4 -bios none

Best Regards,
Katsuhiro Suzuki
Would probably be good to add a second SMP config for qemu_riscv32 for SMP=y. You can look at the boards/x86/qemu_x86 to see examples of having different configs.
I'll add the config.

BTW, QEMU can choose SMP mode or non-SMP mode by command option.
qemu_x86 Zephyr users never want to use non-SMP mode?

I remember a help of CONFIG_USE_SWTCH said that:
"In uniprocess situations where the
architecture provides both, _arch_switch incurs more somewhat
overhead and may be slower.".

I think RISC-V may cover high-end from low-end, so I try to keep
old style context switch mechanism. On the other hand, it seems
x86_64 port don't implement old style.
Should we keep old one or it depends on each architectures?


As for testing, I’m guessing the main test to make sure runs and passes is tests/kernel/smp.
Andrew, can probably mention other tests or aspects to be aware of.
Thanks! I'll try it and report results.


- k
Best Regards,
Katsuhiro Suzuki


Zephyr Project: APIs - Tue, 10/06/2020 4:00pm-5:00pm, Please RSVP #cal-reminder

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

Reminder: Zephyr Project: APIs

When: Tuesday, 6 October 2020, 4:00pm to 5:00pm, (GMT+00:00) UTC

Where:Microsoft Teams Meeting

An RSVP is requested. Click here to RSVP

Organizer: devel@...

Description:

Meeting decisions/discussions in their respective PRs, tracked here: https://github.com/zephyrproject-rtos/zephyr/projects/18


________________________________________________________________________________
+1 321-558-6518 United States, Orlando (Toll)
Conference ID: 317 990 129#
Local numbers | Reset PIN | Learn more about Teams | Meeting options
 
 
________________________________________________________________________________


Re: API meeting: agenda

Carles Cufi
 

Hi all,

An additional item for today:

- Cleanup of work queue API doc
- PR: https://github.com/zephyrproject-rtos/zephyr/pull/28824

-----Original Message-----
From: Cufi, Carles
Sent: 06 October 2020 15:39
To: devel@...; users@...
Subject: API meeting: agenda

Hi all,

Agenda for today, sorry for the short notice.

- Pinmux and pinctrl API: Decide what the priorities for this are, and how
to get to LTS with it
- Issue: https://github.com/zephyrproject-rtos/zephyr/issues/22748

Since there are no other new items in the Triage column, I would propose
we go through the To Do and In Progress items and make sure they are still
applicable and they have a person assigned who is actively working on
them.

Teams link: https://teams.microsoft.com/l/meetup-
join/19%3ameeting_NWU2MjZlYWEtZDcwMi00MWQzLTgwMjEtNDdkYjQwMjBjMmFj%40threa
d.v2/0?context=%7b%22Tid%22%3a%22af0096d9-700c-411a-b795-
b3dd7122bad2%22%2c%22Oid%22%3a%22841a7c92-7816-4faf-9887-
5e334e88f6d8%22%7d

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: [RFC] SMP support for RISC-V privilege architecture

Kumar Gala
 

On Oct 6, 2020, at 4:04 AM, Katsuhiro Suzuki <katsuhiro@...> wrote:

Hello All,

I'm working on SMP support for RISC-V privilege architecture.
https://github.com/katsuster/zephyr/tree/riscv_virt_pc_smp

It seems worked well on QEMU RV32 virt pc (*) porting.
(RV64 not tested yet)

But I don't understand Zephyr's SMP mechanism perfectly and
don't know required conditions (Ex. regression tests) if I
want to change these area.

I'm welcome comments or review of my patch.

(*)QEMU RV32 virt pc:
https://github.com/zephyrproject-rtos/zephyr/pull/28749

Diffs of config from default:
CONFIG_RISCV_USE_SWITCH=y (added by me)
CONFIG_SMP=y
CONFIG_MP_NUM_CPUS=4

Command line:
qemu-system-riscv32 -nographic -machine virt -net none \
-chardev stdio,id=con,mux=on -serial chardev:con \
-mon chardev=con,mode=readline -kernel zephyr/zephyr.elf \
-cpu rv32 -smp cpus=4 -bios none

Best Regards,
Katsuhiro Suzuki
Would probably be good to add a second SMP config for qemu_riscv32 for SMP=y. You can look at the boards/x86/qemu_x86 to see examples of having different configs.

As for testing, I’m guessing the main test to make sure runs and passes is tests/kernel/smp.

Andrew, can probably mention other tests or aspects to be aware of.

- k


API meeting: agenda

Carles Cufi
 

Hi all,

Agenda for today, sorry for the short notice.

- Pinmux and pinctrl API: Decide what the priorities for this are, and how to get to LTS with it
- Issue: https://github.com/zephyrproject-rtos/zephyr/issues/22748

Since there are no other new items in the Triage column, I would propose we go through the To Do and In Progress items and make sure they are still applicable and they have a person assigned who is actively working on them.

Teams link: https://teams.microsoft.com/l/meetup-join/19%3ameeting_NWU2MjZlYWEtZDcwMi00MWQzLTgwMjEtNDdkYjQwMjBjMmFj%40thread.v2/0?context=%7b%22Tid%22%3a%22af0096d9-700c-411a-b795-b3dd7122bad2%22%2c%22Oid%22%3a%22841a7c92-7816-4faf-9887-5e334e88f6d8%22%7d

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


[RFC] SMP support for RISC-V privilege architecture

Katsuhiro Suzuki
 

Hello All,

I'm working on SMP support for RISC-V privilege architecture.
https://github.com/katsuster/zephyr/tree/riscv_virt_pc_smp

It seems worked well on QEMU RV32 virt pc (*) porting.
(RV64 not tested yet)

But I don't understand Zephyr's SMP mechanism perfectly and
don't know required conditions (Ex. regression tests) if I
want to change these area.

I'm welcome comments or review of my patch.

(*)QEMU RV32 virt pc:
https://github.com/zephyrproject-rtos/zephyr/pull/28749

Diffs of config from default:
CONFIG_RISCV_USE_SWITCH=y (added by me)
CONFIG_SMP=y
CONFIG_MP_NUM_CPUS=4

Command line:
qemu-system-riscv32 -nographic -machine virt -net none \
-chardev stdio,id=con,mux=on -serial chardev:con \
-mon chardev=con,mode=readline -kernel zephyr/zephyr.elf \
-cpu rv32 -smp cpus=4 -bios none

Best Regards,
Katsuhiro Suzuki


[RFC] SMP support for RISC-V privilege architecture

Katsuhiro Suzuki
 

Hello All,

I'm working on SMP support for RISC-V privilege architecture.
https://github.com/katsuster/zephyr/tree/riscv_virt_pc_smp

It seems worked well on QEMU RV32 virt pc (*) porting.
(RV64 not tested yet)

But I don't understand Zephyr's SMP mechanism perfectly and
don't know required conditions (Ex. regression tests) if I
want to change these area.

I'm welcome comments or review of my patch.

(*)QEMU RV32 virt pc:
https://github.com/zephyrproject-rtos/zephyr/pull/28749

Diffs of config from default:
CONFIG_RISCV_USE_SWITCH=y (added by me)
CONFIG_SMP=y
CONFIG_MP_NUM_CPUS=4

Command line:
qemu-system-riscv32 -nographic -machine virt -net none \
-chardev stdio,id=con,mux=on -serial chardev:con \
-mon chardev=con,mode=readline -kernel zephyr/zephyr.elf \
-cpu rv32 -smp cpus=4 -bios none

Best Regards,
Katsuhiro Suzuki


[RFC] SMP support for RISC-V privilege architecture

Katsuhiro Suzuki
 

Hello All,

I'm working on SMP support for RISC-V privilege architecture.
https://github.com/katsuster/zephyr/tree/riscv_virt_pc_smp

It seems worked well on QEMU RV32 virt pc (*) porting.
(RV64 not tested yet)

But I don't understand Zephyr's SMP mechanism perfectly and
don't know required conditions (Ex. regression tests) if I
want to change these area.

I'm welcome comments or review of my patch.

(*)QEMU RV32 virt pc:
https://github.com/zephyrproject-rtos/zephyr/pull/28749

Diffs of config from default:
CONFIG_RISCV_USE_SWITCH=y (added by me)
CONFIG_SMP=y
CONFIG_MP_NUM_CPUS=4

Command line:
qemu-system-riscv32 -nographic -machine virt -net none \
-chardev stdio,id=con,mux=on -serial chardev:con \
-mon chardev=con,mode=readline -kernel zephyr/zephyr.elf \
-cpu rv32 -smp cpus=4 -bios none

Best Regards,
Katsuhiro Suzuki


Zephyr SDK 0.12.0-alpha-1 available for testing

Kumar Gala
 

Hi,

Latest version of the SDK can be found here:

https://github.com/zephyrproject-rtos/sdk-ng/releases/tag/v0.12.0-alpha-1

Please download and try things out and report any issues. Please report issues here:

https://github.com/zephyrproject-rtos/sdk-ng/issues

Known issues:

* some xtensa platforms may need updating w/regards to Zephyr & Xtensa HAL
[ https://github.com/zephyrproject-rtos/zephyr/pull/23142 ]

* known issue with arm64 and linking C++ & newlib:
[ https://github.com/zephyrproject-rtos/zephyr/issues/28650 ]

Changes since the last release:

• General:

• Updated to using buildkite for CI
• Updated yocto 3.1.1
• Build aarch64 (arm64) linux host toolchains.
• Moved to using a zephyr fork of crosstool-ng
• Update bossa to 1.9.1+
• cmake: Set HOST_TOOLS_HOME based on OS_PLATFORM
• QEMU:

• Updated to QEMU 5.1.0
• Added icount support for ARC
• OpenOCD:

• Updated to 20200928 snapshot
• newlib:

• Updated to version 3.3
• Updated xtensa to version 3.3 (in sync with all arch's)
• binutils:

• updated to version 2.35.1
• gcc:

• Updated to version 10.2.0
• gdb:

• Updated to version 9.2
• xtensa:

• remove HAL from SDK build


- k


Network forum agenda

Jukka Rissanen
 

Hi all,

There is a network forum meeting tomorrow Tuesday 6 Oct at 8AM PDT /
17.00 CET.

Agenda:

- TCP2 is now the default TCP implementation, legacy TCP implementation
is not yet removed. We can discuss possible issues and how to proceed.

https://github.com/zephyrproject-rtos/zephyr/issues/28587
https://github.com/zephyrproject-rtos/zephyr/pull/28832


- Modem power management support. Two alternative implementations
proposed for generic GSM modem, and one for offloaded modem.

https://github.com/zephyrproject-rtos/zephyr/pull/28475
https://github.com/zephyrproject-rtos/zephyr/pull/27731
https://github.com/zephyrproject-rtos/zephyr/pull/27927


If you have anything else you want to discuss, please let me know.

Link to the Teams meeting:

https://teams.microsoft.com/l/meetup-join/19%3ameeting_NDU5ODRkNzktZDBmNC00MDg5LWI2OWEtNzM0MGZjMDU0Yjgw%40thread.v2/0?context=%7b%22Tid%22%3a%22af0096d9-700c-411a-b795-b3dd7122bad2%22%2c%22Oid%22%3a%22841a7c92-7816-4faf-9887-5e334e88f6d8%22%7d


Cheers,
Jukka


Re: SMP support for ARM architecture

Boie, Andrew P
 

Hi Krzysztof,

 

I'm assuming that you're referring to ARM Cortex-A? A patch recently landed to implement switch instead of swap: https://github.com/zephyrproject-rtos/zephyr/pull/27766. There is a GitHub enhancement for ARM64 SMP support https://github.com/zephyrproject-rtos/zephyr/issues/26952 but nobody is working on it AFAIK.

 

CPU affinity is currently implemented via the k_thread_cpu_mask_* APIs in include/kernel.h. So if you get SMP working on your arch the scheduling infrastructure is there.

 

This is just the first step, to fully implement SMP you'll need per-cpu variables, IPIs, some extra arch_* APIs implemented, etc. We don't have a porting guide for SMP yet, and having not done this myself I'm not quite an expert in this area but I would reach out to Andy Ross for general SMP enabling questions, and for ARM64 stuff I would coordinate with  Carlo Caione who has done much of the work so far.

 

We have SMP working on x86_64, ARC, and Xtensa so reviewing that may also be helpful.

 

HTH

Andrew

 

From: devel@... <devel@...> On Behalf Of Krzysztof Walczak via lists.zephyrproject.org
Sent: Friday, October 2, 2020 5:09 AM
To: devel@...
Subject: [Zephyr-devel] SMP support for ARM architecture

 

Hi,

 

For our multicore ARM based project we would like to use SMP and affinity mechanism in Zephyr. When digging into the code I found that it is not implemented.

Mainly, there is an implementation of arch_switch() missing needed by SMP. Can someone give me any guideline as to what would be required for implementation to have an SMP/afinity mechanism operational in Zephyr on ARM platform.

 

rgds

Krzysztof


Re: RFC: API Change: k_work

Peter A. Bigot
 

This RFC has been withdrawn.  Instead the documentation of the existing API will be updated to describe its behavior more precisely, and ultimately deprecated in favor of a new API and recommended usage that eliminates the problems.  See this and subsequent comments.


SMP support for ARM architecture

Krzysztof Walczak
 

Hi,

For our multicore ARM based project we would like to use SMP and affinity mechanism in Zephyr. When digging into the code I found that it is not implemented.
Mainly, there is an implementation of arch_switch() missing needed by SMP. Can someone give me any guideline as to what would be required for implementation to have an SMP/afinity mechanism operational in Zephyr on ARM platform.

rgds
Krzysztof


Zephyr Project: Dev Meeting - Thu, 10/01/2020 3:00pm-4:00pm, Please RSVP #cal-reminder

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

Reminder: Zephyr Project: Dev Meeting

When: Thursday, 1 October 2020, 3:00pm to 4:00pm, (GMT+00:00) UTC

Where:Microsoft Teams Meeting

An RSVP is requested. Click here to RSVP

Organizer: devel@...

Description:

________________________________________________________________________________
+1 321-558-6518 United States, Orlando (Toll)
Conference ID: 483 314 739#
Local numbers | Reset PIN | Learn more about Teams | Meeting options
 
 
________________________________________________________________________________


Re: Dev-Review Meeting Agenda Oct 1

Kumar Gala
 

On Oct 1, 2020, at 7:49 AM, Kumar Gala via lists.zephyrproject.org <kumar.gala=linaro.org@...> wrote:

Here’s the agenda topics for this week:

* List property label for all active ADCs regardless of the board used:
- https://github.com/zephyrproject-rtos/zephyr/issues/28566

* DTS default usage guidelines
- https://github.com/zephyrproject-rtos/zephyr/issues/25164
- https://github.com/zephyrproject-rtos/zephyr/pull/28817

* Any PR/issues w/dev-review tag

https://github.com/zephyrproject-rtos/zephyr/labels/dev-review

* Any topics anyone else has.
Added to agenda:

drivers: flash: nrf_qspi_nor: remove multithreading dependency
- https://github.com/zephyrproject-rtos/zephyr/pull/28740

For discussion on our policy w/regards to updates & fixes for deprecated features in general.


Dev-Review Meeting Agenda Oct 1

Kumar Gala
 

Here’s the agenda topics for this week:

* List property label for all active ADCs regardless of the board used:
- https://github.com/zephyrproject-rtos/zephyr/issues/28566

* DTS default usage guidelines
- https://github.com/zephyrproject-rtos/zephyr/issues/25164
- https://github.com/zephyrproject-rtos/zephyr/pull/28817

* Any PR/issues w/dev-review tag

https://github.com/zephyrproject-rtos/zephyr/labels/dev-review

* Any topics anyone else has.


Review of LoRaWAN PR

Mani Sadhasivam <manivannanece23@...>
 

Hi Folks,

There is a LoRaWAN PR posted a while ago [1] and it has undergone
reviews from several developers. But it still got stuck and I'd appreciate
any help to move this forward. This will be a great addition to the Zephyr
ecosystem once merged.

[1] https://github.com/zephyrproject-rtos/zephyr/pull/23664

Thanks,
Mani

--
மணிவண்ணன் சதாசிவம்


STM32: Moving devices pin configuration to device tree

Erwan Gouriou
 

TL;DR:
- Upcoming device tree based pin configuration for STM32 based boards
- Script generated, SoC package specific *-pinctrl.dtsi files are available in hal_stm32 modules
- Each *.pcintrl.dtsi file provides a complete set of valid pin configurations for targeted STM32
package
- Generation script is provided and can be used to generate new pin configuration variants (low
power, ...)
- One driver (STM32 serial) and two boards converted today as proof of concept
- Contributions are welcome to achieve deprecation of existing pinmux.c files within V2.5.0 
merge window


To all STM32 users and developers,

We're in the final step of reviewing PR #25996 "stm32: devices signals configuration from dt
This PR introduces the required material to enable device pin configuration using device tree.

With this method, device pin configuration should no longer be done in pinmux.c board file, but
in .dts file. For instance, to enable PB6 as TX and PB7 as RX on USART1, the following lines
should be added in .dts board file, in usart1 node:

 &usart1 {
        current-speed = <115200>;
+      pinctrl-0 = <&usart1_tx_pb6 &usart1_rx_pb7>;
+      pinctrl-names = "default";
        status = "okay";
 };

As a consequence, pin configuration can now be done at device driver level, opening the way
to dynamic pin configuration, which could be useful in various fields such as low power
management. Also, it provides flexibility in application configuration as pin configurations could
then be modified in using overlays.

Pin control nodes are defined using Linux pinctrl bindings. For instance, usart1_tx_pb6 is
defined as
+usart1_tx_pb6: usart1_tx_pb6 {
+       pinmux = <STM32_PINMUX('B', 6, AF7)>;
+       bias-pull-up;
+};

Definition of nodes usart1_tx_pb6 and usart1_rx_pb7 could be provided manually but to assist
in board configuration, SoC variant package specific -pinctrl.dtsi files are provided and should
be included in the board dts files.

For instance, for board disco_l475_iot1:
 #include <st/l4/stm32l475Xg.dtsi>
+#include <st/l4/stm32l475r(c-e-g)tx-pinctrl.dtsi>
 #include "arduino_r3_connector.dtsi"

*-pinctrl.dtsi files provide known working pin configurations which could be overwritten at
board level to fit a specific need. These files are hosted in hal_stm32 module (under dts/st/),
one for each STM32 SoC package. These files are generated from STM32 .xml description files
(currently delivered in ST STM32CubeMx tool). Using the appropriate -pinctrl.dtsi file allows
benefiting from the full list of valid pinctrl nodes for a SoC package that is used on a board,
reducing the risk of pin misconfiguration.
The -pinctrl.dtsi generation script is also provided and could be used to add or modify pinctrl
node variants, or to provide a new set of -pinctrl.dtsi files if a new STM32 SoC shows up.

This new method could coexist with current pinmux.c configuration (beware of the pin conflicts
as usual, though). 

For now, PR #25996 only provides the tooling for dts based pin configuration. Only one driver
(STM32 serial) and 2 boards have been modified as proof of concept (cf PR for more details).
Next step is to extend its usage to existing STM32 boards and drivers. Target is to get rid of in
tree pinmux.c files for V2.5.0, so their usage could be deprecated.
I invite STM32 codeowners and contributors to help us in this task. Out of tree users are also
encouraged to perform this change on their respective boards.

Big thanks to Gerard Marull-Paretas (@gmarull) who helped me with this PR and provided the
pinctrl.dtsi files generation script.

Cheers
Erwan