Hello,

"yasokada via Lists.Zephyrproject.Org"
<yasokada=gmail.com@lists.zephyrproject.org> writes:

Application Development
https://docs.zephyrproject.org/latest/application/index.html
at several lines above the Source Tree Structure ( https://docs.zephyrproject.org/latest/application/index.html#source-tree-structure )

Zephyr does not support “in-tree” builds.

The "in-tree" and "out-of-tree" may be used in linux as being part of the system or not, I think.
Linux kernel: meaning of source-tree, in-tree and out-of-tree ( https://unix.stackexchange.com/questions/208638/linux-kernel-meaning-of-source-tree-in-tree-and-out-of-tree )

In the above sentence for Zephyr, what does the "in-tree" builds mean?

For example, I guess, the "in-tree" builds means that the build can be performed only partly for some module, not for all the application project.

That is not correct.

Am I mistaken?

An "in-tree" build is when build artifacts (object files, generated
code, etc.) are created in the same directories as the source code. E.g.
if CMake places the object file for zephyr/kernel/init.c in the same
directory (zephyr/kernel), that would be an in-tree build, but that is
not supported by the Zephyr build system.

Zephyr's build system requires "out-of-tree" builds, which means that
the build directory is separate from the source directories.

Martí

Thanks in advance

Hi,

I am building a device driver for Zephyr and when calling the macro, DEVICE_GET(), like DEVICE_GET(my_dev), I get a build error complaining about undefined __device_my_dev.
I tried to locate where the variable is assembled during the build process but have no luck so far.

I have placed the following in the driver source code:


Could you please shed some light on where to look for what might go wrong?

Thanks,
Justin

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.

Dear Yannis
(I have sent private reply, but for other people, I send this reply again).

Thank you very much.

I added the description for &spi2 in an overlay file.
It worked.

I appreciate it.

-------- Forwarded Message --------
Subject: Private: Re: [Zephyr-users] SPI2 definition is not found for STM32L476 device tree. How to add?
Date: Fri, 27 Dec 2019 15:40:46 -0800
From: yasokada@gmail.com
To: Yannis Damigos <giannis.damigos@gmail.com>



Dear Yannis


Thank you very much for your quick reply.

It worked!

Hi,

### How to add?

I may need to add the spi2 definition for STM32L476.

Where should I add the definition?

You don't need to add it. It exists in dts/arm/st/l4/stm32l471.dtsi

A. stm32l4.dtsi
B. nucleo_l476rg.dts> C. <BOARD>.overlay file located in the project directory

I just wonder why there is a definition for SPI2 for the supported board web page, but it is not actually supported by the device tree.

To enable it just add the following in nucleo_l476rg.dts or an overlay file:

&spi2 {
status = "okay";
};

Yannis

My environment:
Ubuntu 18.04 LTS
STM32L476 Nucleo_64 (hereafter STM32L476)
STM32F769 Discovery Kit (hereafter STM32F769)
Zephyr 2.1.0-rc1

### SPI2 for STM32L476 

https://docs.zephyrproject.org/latest/boards/arm/nucleo_l476rg/doc/index.html

In the above page, there is the definition of SPI2 (and SPI3).
However, when I west build the project with the SPI_2 set, I have the following errors.

```

```
### How to add?

I may need to add the spi2 definition for STM32L476.

Where should I add the definition?

A. stm32l4.dtsi
B. nucleo_l476rg.dts
C. <BOARD>.overlay file located in the project directory

I just wonder why there is a definition for SPI2 for the supported board web page, but it is not actually supported by the device tree.

Good day,

I have decided to dive head first into Zephyr with a project of mine.

I have a LIS2DH and a W25Q128JV Flash on the same SPI bus, with two GPIOs to control the chip selects. I have a STM32F413VGT6 microcontroller, and the Zephyr version is

However, I am having some trouble. When the FLASH SPI is initialized (in function spi_nor_read_id called by  spi_not_configure) to read the JEDEC ID, the LIS2DH chip select is still not initialised, ie its low, so I have two devices selected at the same time. This results in an incorrect JEDEC ID.

Later when I try to use the LIS2DH, no chip selects are being controlled, leading to a problem in getting data from the LIS2DH.

I cannot find any place in the code where the cs-gpios from the dts file is used. In fact I have been able to ascertain that the chip select list is not initialized with the following test:


At the time the SPI NOR flash is initialised the output from the above function is:
Test0 1
Test1 0x20000f78
Test2 0x20000f84
Test3 0x200050fc,GPIOD
Setting CS End
Test0 0
Test1 0x20000f78
Test2 0x20000f84
Test3 0x200050fc,GPIOD
Setting CS End
(And I can see the NOR Flash chip select activated)

but by the time I want to use the LISD2H, the output is:
Test0 1
Test1 0x20000f5c
Setting CS End
Test0 0
Test1 0x20000f5c
Setting CS End
(No chip select activity since the chip select GPIO list ctx->config->cs is NULL)

I have seen the debate on where chip select control is to be done here:
https://github.com/zephyrproject-rtos/zephyr/issues/12698 and
https://github.com/zephyrproject-rtos/zephyr/issues/12226
but none of these really helped my to solve my problem.

Here is an extract from my dts file:



Does anyone know of a good working example with multiple Chip selects on a SPI bus where the CS lines are controlled with GPIOs, or can someone point me in the right direction to solve this problem?

Thanks in advance, any help is appreciated.

Greeting from South Africa

Hi all,

This week we will focus on two Stable API Change RFCs and GPIO.
I am unable to attend but Peter Bigot has kindly offered to chair the meeting instead.

Reminder on the Stable API Change RFCs: The purpose of discussing them in this meeting is to raise awareness and talk about any objections or potential problems the change may introduce. The final acceptance is gated by the Pull Request itself.

- RFC: API Change: PWM: add support for inverted PWM signals
- https://github.com/zephyrproject-rtos/zephyr/issues/21384

- RFC: API Change: usb: Make users call usb_enable. Provide global status callback.
- https://github.com/zephyrproject-rtos/zephyr/issues/21419

- GPIO: Update on progress
- Proposal from Peter Bigot: Port remaining users without testing them on hardware
- 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

Hello Zephyr users,

Now that Zephyr 2.1 has been released, I am proposing we make Python 3.6
the minimum supported Python version for 2.2:

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

The pull request has been approved and was discussed without objection
by the Technical Steering Committee today, so I'm trying to raise
awareness about it as it seems likely to me it will be merged for 2.2
unless someone objects.

Comments or objections in the PR if possible, please.

Thanks!

Dear all,

I am doing silly motor driver for worm-gear dc-motor with stm32f411e-disco board (and L298). The dc-motor has HAL-sensor for feedback - providing raising/lowering edge for every turn. Now, as the HAL sensor is attached before the worm-gear, so the RPM will be something. To have it handled with ease i was thinking to connect the HAL sensor output to STM32 as external clock input -> i can get the count from the timer register with zero load to processor.

As far as i know (and have tested - it compiles) i can use the HAL_TIM_XYZ functions and they should work -> i can use them to configure timer to be in external clock mode.

But how does one handle the overflow of the timer? In normal STM32 HAL code one would get interupt from this but i have no glue how to do it with Zephyr. I do know i could poll it with very little overhead, but that seems bit brute-force.

Would it be easy to set up interrupt handler for timer overflow? Could somebody point out tips what would be the steps required (or just say its not doable without weeks of work)? What Zephyr source files i should look at? Any change of samples that would even have some similarity?

BR,
Pauli

Hi all,

This week we will focus on API Changes and GPIO:

- Changing a stable API:
- https://github.com/zephyrproject-rtos/zephyr/pull/21013

- GPIO: Update on progress
- 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

I just realized I responded to you privately by accident, Lawrence. Sorry about that. I will copy the message I sent to you to the group so that the discussion is up to date.

The suggestion regarding testing the gpio with gpio_pin_read is exactly what I am currently doing, and it does indeed work well, but I had the same thought about spurious pulses potentially causing issues here. I haven't observed issues with this yet, but it certainly was a concern of mine.

As for your second suggestion, I have not tried that! My understanding was that calling gpio_pin_configure a second time would (re)configure the gpio, not append additional configurations. So I have been configuring the gpio with interrupt flags which are bitwise OR'd. If the API can in fact allow me to have multiple pin configurations with different callbacks then it should work perfectly. This will require a bit of refactor for my current project, but I can at least test this concept fairly quickly. 

Thanks for the suggestions! I will let you know if it works.
Brian