Hi Stefan,

To generate #define's from dt, you need to provide the matching yaml binding to indicate how fields should be decided, this should be done under dts/bindings/...

Generated #define's will be available in build directory, under zephyr/include/generated/generated_... 

You should be able to use them as you wish.

To make your driver somewhat generic (ie not depending on the node address, you'll need to provide intermediate #define in dts_fixup.h file (under soc/ or board/).

For more information, you can check in various drivers how DT_xxxx constants are used

Cheers

Erwan

Le ven. 4 janv. 2019 à 17:30, Stefan Jaritz <stefan@...> a écrit :

Hej,

I like to create an user app that uses 2 IC connected via I2C with my
MCU.  Doing this is a bit tricky because I am missing some
documentation, that is describing how the whole process goes.

My setup is simple:

1.) custom board based on the stm32f412RG

1.1) the IC are connected via I2C

1.2) dts changes:

&i2c1 {
     status = "ok";
     clock-frequency = <I2C_BITRATE_FAST>;

     codec1@48 {
         compatible = "xxx,codec1";
         reg = <0x48>;
         label = "codec1";
     };

     codec2@46 {
         compatible = "xxx,codec2";
         reg = <0x46>;
         label = "codec2";
         readAddr = <0x8F>;
         writeAddr = <0x8E>;
     };
};

2.) user app

2.1) custom driver (codec1.c and codec2.c)

How can I get the value of the I2C slave address from the dts inside of
my source code?

How can I find and access the c-files after the dts compilation?

How Zephyr connects the c code of the dts, kernel, drivers, user drivers
and app?


Any help is welcome!


Stefan

Hi,
I know it is a quite specific question, but I thought that maybe
someone has an idea into which direction to go..

I have some PCA10059 (nRF52-Dongles) lying around and would like to
make experiments with them running Zephyr OS. Unfortunately, I do not
have a an appropriate cable for connecting it to my nRF52 DK to flash
it and buying a cable would crash my budget.

Luckily, work has been ongoing to make flashing the PCA10059 possible
without an external debugger. The solution (how I understand it) is
that the stock Nordic bootloader remains on the PCA10059, loads
MCUboot, which in turn loads Zephyr OS. The merge request can be found
here: https://github.com/zephyrproject-rtos/zephyr/pull/11210

I have playing around with it (i.e. flash samples/bluetooth/mesh) and
can report that it is working. I had to make two modifications:
Comment storage_partition in
boards\arm\nrf52840_pca10059\nrf52840_pca10059.dts, such that there is
no duplicate collision with dts/common/nrf52840-nrf5-*.overlay and
strangely (I would interpret the documention differently) keep Kconfig
settings how they are (leave CONFIG_BOOTLOADER_MCUBOOT=n).

The "only" problem I have: Storage of settings does not work. The
symptoms are that I have to re-provision the PCA10059 every time it is
power-cycled.

I have been playing around with storage settings in the .dts-files
(changing the memory regions) with no success. Attached is the
_dts_compiled that is generated during the build phase and a
screenshot of nrf connect showing in which regions code resides.

Has anyone already gotten storage of settings with PCA10059 to work
(possibly even with the traditional debugger solution)? And does
anyone have a clue / an idea why it is not working and where I should
look into?

Thanks,
Martin

Uh... those instructions still tell you to get cmake 3.8.2 :)

The latest is currently at https://cmake.org/files/LatestRelease/cmake-3.13.2-Linux-x86_64.sh it seems.

Andy

s/not/now/ in the title J

 

From: devel@... [mailto:devel@...] On Behalf Of Nashif, Anas
Sent: Thursday, January 3, 2019 11:52 AM
To: devel@...
Subject: [Zephyr-devel] Minimum required CMake version is not 3.13.1

 

Hi,

 

We have changed the minimal requirement version of cmake to 3.13.1 meaning that you are required to update cmake on your system to build Zephyr.

 

Please follow the documentation below to satisfy the requirements:

 

https://docs.zephyrproject.org/latest/getting_started/installation_linux.html#install-requirements-and-dependencies

 

The reasons for a recent version of CMake is explain here:

 

https://github.com/zephyrproject-rtos/zephyr/pull/12022#issuecomment-446589193

 

We have a few requests to include CMake in the SDK, this is something we are considering in the new SDK based on crosstools-ng.

 

Regards,

Anas

 

s/not/now/ in the title J

 

From: devel@... [mailto:devel@...] On Behalf Of Nashif, Anas
Sent: Thursday, January 3, 2019 11:52 AM
To: devel@...
Subject: [Zephyr-devel] Minimum required CMake version is not 3.13.1

 

Hi,

 

We have changed the minimal requirement version of cmake to 3.13.1 meaning that you are required to update cmake on your system to build Zephyr.

 

Please follow the documentation below to satisfy the requirements:

 

https://docs.zephyrproject.org/latest/getting_started/installation_linux.html#install-requirements-and-dependencies

 

The reasons for a recent version of CMake is explain here:

 

https://github.com/zephyrproject-rtos/zephyr/pull/12022#issuecomment-446589193

 

We have a few requests to include CMake in the SDK, this is something we are considering in the new SDK based on crosstools-ng.

 

Regards,

Anas

 

Hi,

We have changed the minimal requirement version of cmake to 3.13.1 meaning that you are required to update cmake on your system to build Zephyr.

Please follow the documentation below to satisfy the requirements:

https://docs.zephyrproject.org/latest/getting_started/installation_linux.html#install-requirements-and-dependencies

The reasons for a recent version of CMake is explain here:

https://github.com/zephyrproject-rtos/zephyr/pull/12022#issuecomment-446589193

We have a few requests to include CMake in the SDK, this is something we are considering in the new SDK based on crosstools-ng.

Regards,

Anas

Hi Raj,

The issue with CONFIG_MULTITHREADING is that it was never properly supported. It was added for MCUboot and considered for removal a couple of times, but that never happened because the size difference is still significant enough for many people.

The only option at this point is for you to submit a patch for the drivers you need that disables use of any primitives that require multithreading (semaphores, mutexes, etc) behind a macro, like it’s done here:

https://github.com/zephyrproject-rtos/zephyr/blob/master/drivers/flash/soc_flash_nrf.c#L68

This might not be trivial for SPI though, depending on how the driver is written.

Carles

Hi Carles,

Guess this mail got buried while you were away. Please help me out here.

Regards,

Raj

Hi Carles,

I am trying to build Zephyr to fit in a memory constrained device of 64kB. My device doesn’t require multithreading and hence I disabled multithreading to save on the memory. However, this is throwing me exceptions since I have UART and SPI Flash drivers enabled. It appears the semaphore accesses in those drivers are not “single-thread” aware. Is there anything that can be done to work-around this? Does just “nop”ing it out suffice? Please let me know.

Regards,

Raj

Hi Carles,

Number 2 works fine.
Thanks a lot.

Regards,
Bo

Hi Carles,

And thank you very much for your quick response.

I have renamed 'JLinkExe' to 'JLink.exe' in line 20 of my local jlink.py.
I also renamed  'JLinkGDBServer' to 'JLinkGDBServer.exe' in line 23 of my local jlink.py.

I then updated the PATH environment variable with "c:\Program Files (x86)\SEGGER\JLink_V640\", where the exe files are located.

After this I can type both JLink.exe and JLinkGDBServer.exe on the command line of the cmd window from the build directory of the "hello_world" sample, and both programs starts.

But if I type ninja flash, I still get the same error.

I hope this feedback can help fixing this Windows issue.

Best regards,
Bo

Hi Carles,

Guess this mail got buried while you were away. Please help me out here.

Regards,

Raj

Hi Carles,

I am trying to build Zephyr to fit in a memory constrained device of 64kB. My device doesn’t require multithreading and hence I disabled multithreading to save on the memory. However, this is throwing me exceptions since I have UART and SPI Flash drivers enabled. It appears the semaphore accesses in those drivers are not “single-thread” aware. Is there anything that can be done to work-around this? Does just “nop”ing it out suffice? Please let me know.

Regards,

Raj

Hi Carles,

I am trying to build Zephyr to fit in a memory constrained device of 64kB. My device doesn’t require multithreading and hence I disabled multithreading to save on the memory. However, this is throwing me exceptions since I have UART and SPI Flash drivers enabled. It appears the semaphore accesses in those drivers are not “single-thread” aware. Is there anything that can be done to work-around this? Does just “nop”ing it out suffice? Please let me know.

Regards,

Raj