I forgot to include the overlay file…here it is.

We are trying to understand how to configure sercom3 to allow I2C support.
The I2C device is the adafruit_oled_featherwing.
I believe I have the I2C, SSD1306, framebuffer (cfg), and display.  
Below is the relevant portions of the prj.conf file

Our app builds with these setting, but doesn't seem to conduct I2C traffic.
We going though the SAMD21 datasheet, but it is very confusing.
We don't understand how the pinmux is being driven to set the pad to I2C mode.

Are there any examples showing how to configure I2C for the adafruit_feather_m0_basic board or any other samd21 type board?

Dne 06.01.2020 v 18:31 Andy Ross napsal(a):

On 1/5/20 4:30 AM, Martin Kozusky [newsgroups] wrote:

1 - what is the best solution to call my function every 1ms (or will
it be 1.007ms?), is it ok just to use k_timer? Is "next expiration
time" calculated just by adding period to current time (that would
make a big time diff after many calls) or does it use
k_uptime_get*number of expirations to calculate next expiration
time?

Periodic k_timer's do not work in fractional ticks, no. If you
schedule a 1000ms timeout it will be rounded up internally to exactly
33 hardware cycles, and that process will repeat each cycle.  So you
would see the ~993 Hz tick rate you calculated.  If you want to work
in fractional ticks, the application needs to do that math itself.

is it 1000ms timeout = 33 cycles, or 1ms timeout = 33 cycles? This is acceptable for short-term timeouts.

2 - what is the best solution for most precise long-term time
keeping?  Let's say i don't want more that 1 minute diff in 20
days. Can I just use k_uptime_get?

Long term time is kept as a 64 bit count of ticks, so it's not subject
to the kind of round-off errors that periodic timers are.  As long as
your app isn't dropping or delaying the counter interrupts, the uptime
value should be as accurate as your crystal is.

If you want to get 1 callback per second as a long term average, you
can (with care) compute your timeout as an offset from system start or
some other time reference instead of "now" (i.e. the Nth timeout will
happen at "N * 1000ms", plus a little precision slop due to the clock
mismatch).  There's actually an API change which will make this kind
of code significantly easier, see
https://github.com/zephyrproject-rtos/zephyr/issues/21305

When this gets into 2.2, can I use "k_uptime_ticks() / 32768" to get the exact time in seconds?

As far as using a different oscillator to drive the timer, that's
possible but requires some driver fiddling.  I'll let the Nordic folks
speak to that.  One option might be to use the generic ARM SysTick
driver, which doesn't have the rate mismatch issues of the 32kHz
timer, but doesn't have the low power idle characteristics.

On another project, I would like to be sleeping most of the time to save power and want to be woken by pin interrupt or 1 sec timeout, so it is good idea to have clock in low-power.

BTW: When I enter to sleep by k_sleep(), is there  any change in power consumption besides thread being put to sleep? Or do I have to call device_set_power_state(DEVICE_PM_LOW_POWER_STATE) to enter low-power mode? Will I be automaticaly put to DEVICE_PM_ACTIVE_STATE when there is an pin interrupt and is there any way how to get number of ticks I've been in low-power mode since I was woken by pin interrupt? (are ticks also incremented in low-power mode?) (on bare-metal I would set RTC modulo to wake after 1 second, go to low-power and if I got woken earlier by pin interrupt, I would read RTC counter to get the exact time I was sleeping or if I got woken by RTC INT, I would know it was exactly 1 sec, then do some stuff, again setup RTC, go to sleep  ... is this even possible with Zephyr and NRF52832? )

Andy

Thanks,
Martin

On 1/5/20 4:30 AM, Martin Kozusky [newsgroups] wrote:

1 - what is the best solution to call my function every 1ms (or will
it be 1.007ms?), is it ok just to use k_timer? Is "next expiration
time" calculated just by adding period to current time (that would
make a big time diff after many calls) or does it use
k_uptime_get*number of expirations to calculate next expiration
time?

Periodic k_timer's do not work in fractional ticks, no. If you
schedule a 1000ms timeout it will be rounded up internally to exactly
33 hardware cycles, and that process will repeat each cycle. So you
would see the ~993 Hz tick rate you calculated. If you want to work
in fractional ticks, the application needs to do that math itself.

2 - what is the best solution for most precise long-term time
keeping? Let's say i don't want more that 1 minute diff in 20
days. Can I just use k_uptime_get?

Long term time is kept as a 64 bit count of ticks, so it's not subject
to the kind of round-off errors that periodic timers are. As long as
your app isn't dropping or delaying the counter interrupts, the uptime
value should be as accurate as your crystal is.

If you want to get 1 callback per second as a long term average, you
can (with care) compute your timeout as an offset from system start or
some other time reference instead of "now" (i.e. the Nth timeout will
happen at "N * 1000ms", plus a little precision slop due to the clock
mismatch). There's actually an API change which will make this kind
of code significantly easier, see
https://github.com/zephyrproject-rtos/zephyr/issues/21305

As far as using a different oscillator to drive the timer, that's
possible but requires some driver fiddling. I'll let the Nordic folks
speak to that. One option might be to use the generic ARM SysTick
driver, which doesn't have the rate mismatch issues of the 32kHz
timer, but doesn't have the low power idle characteristics.

Andy

Hi,
I understand that there are some problems because of 32768Hz RTC (I am now using NRF52-DK and want to use NRF52832 in my new HW) as referenced here: https://github.com/zephyrproject-rtos/zephyr/issues/9904   there are some already merged PRs (like https://github.com/zephyrproject-rtos/zephyr/pull/16782 )  and some waiting to merge.

I want to ask:

 1 - what is the best solution to call my function every 1ms (or will it be 1.007ms?), is it ok just to use k_timer? Is "next expiration time" calculated just by adding period to current time (that would make a big time diff after many calls)  or does it use k_uptime_get*number of expirations to calculate next expiration time?

 2 -  what is the best solution for most precise long-term time keeping?  Let's say i don't want more that 1 minute diff in 20 days. Can I just use k_uptime_get? I would like to make my HW design without aditional external RTC, which can be almost as expensive as another NRF52832 - is it even possible somehow? Or do you have any tip for some cheap low-power RTC?

 3 - would using external 16MHz/32MHz (or another frequency) oscilator solve anything?

 4 - as someone already wrote here: https://lists.zephyrproject.org/g/users/topic/28021125  would it be possible to use timer peripheral (with external osc.) to generate better timing (as I would normaly do on bare-metal)?


Thanks.

Hi,
I understand that there are some problems because of 32768Hz RTC with NRF52832 as referenced here: https://github.com/zephyrproject-rtos/zephyr/issues/9904  , there are some already merged PRs (like https://github.com/zephyrproject-rtos/zephyr/pull/16782 )  and some waiting to merge, so what is the actual state at 2.1.0?

I want to ask:

 1 - what is the best solution to call my function every 1ms (or will it be 1.007ms?), is it ok just to use k_timer? Is "next expiration time" calculated just by adding period to current time (that would make a big time diff after many calls)  or does it use k_uptime_get*number of expirations to calculate next expiration time?

 2 -  what is the best solution for most precise long-term time keeping?  Let's say i don't want more that 1 minute diff in 20 days. Can I just use k_uptime_get? I would like to make my HW design without aditional external RTC, which can be almost as expensive as another NRF52832 - is it even possible somehow? Or do you have any tip for some cheap low-power RTC?

 3 - would using external 16MHz/32MHz (or another frequency) oscilator solve anything?

 4 - as someone already wrote here: https://lists.zephyrproject.org/g/users/topic/28021125  would it be possible to use timer peripheral (with external osc.) to generate better timing (as I would normaly do with bare-metal sources)?


Thanks.

Instead of adding k_usleep(30),
I changed the SPI clock from 210kHz to 406kHz for STM32F769.

Then, the problems of A and B are gone.
Still I have the problem of C.
I receive 0x07 instead of 0x01.



From what I read throught the internet, the CRC for CMD is 0x95. But in Zephyr, the CRC is 0x94.
I wonder whether this difference cause some problem. However, for STM32L476, this works.

I will check further on this. 

From what I checked:

- A. 74 clocks stop with a change in CS without sufficient delay
- B. CMD0 (0x40 0x00 0x00 0x00 0x00 0x94) fails to send 0x40... (instead send 0x20...)
- C. CMD0 fails to receive 0x01

I added `k_usleep(30); // usec` before sdhc_spi_set_cs(data, 0); in sdhc_spi_go_idle() of disk_access_spi_sdhc.c.
Then, the above A and B are solved.
However, I still have the problem of C.
This may be caused without sufficient delay after sending 0x94. I am checking how to add delay after 0x94.

I also checked the clock frequency.
- STM32L476: 312kHz
- STM32F768: 210kHz

I am not sure whether this difference in the frequency makes the failure and success of the process.

Dear Marti

Thank you very much for your reply.
I can understand the difference now.

Best regards

Yasuhiko Okada

Hi,

I should probably start by saying that I’m brand new to Zephyr and that I’m pretty sure I’m missing something obvious or just overlooked parts of the (great!) documentation.

I’m trying to configure my project to use the NRF 802.15.4 radio driver coming with Zephyr (in the modules/hal/nordic/drivers/nrf_radio_802154) without any of the other Zephyr networking support, but I can’t figure out a project config that would help me achieve this. I played with various configs, and the most promising seems to be

CONFIG_NETWORKING=n
CONFIG_IEEE802154=y
CONFIG_IEEE802154_NRF5=y
CONFIG_IEEE802154_RAW_MODE=n
CONFIG_HAS_NORDIC_DRIVERS=y

but Kconfig won’t let me set CONFIG_HAS_NORDIC_DRIVERS manually (which is required to include the drivers subfolder, see modules/hal/nordic/CMakeLists.txt).

As a desperate measure I tried to set every CONFIG_IEEE802154_xxx config flag to no and instead include the driver as an extra module via

set(ZEPHYR_EXTRA_MODULES [some_directory]/modules/hal/nordic/drivers/nrf_radio_802154)

but no luck either.

Any ideas what else I could try?

Thanks,
Axel

Hi Justin,

"Justin Huang via Lists.Zephyrproject.Org"
<justin.y.huang=live.com@lists.zephyrproject.org> writes:

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.

DEVICE_GET() might not be the right thing here. Are you trying to get a
pointer to your device from the device driver C file itself, or from
some other file?

If you're trying to get a pointer to your device from some application
source code, you should probably be using device_get_binding() instead of
DEVICE_GET().

I have placed the following in the driver source code:

DEVICE_INIT(my_dev, CONFIG_MYDEV_NAME, my_dev_init,
my_dev_device_ctrl, NULL,
APPLICATION, CONFIG_MYDEV_INIT_PRIORITY);

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

If (and only if) the DEVICE_GET() line is in the same file as the above
DEVICE_INIT(), then it should work properly when paired with
DEVICE_DECLARE(), as shown with example code in this documentation page:

https://docs.zephyrproject.org/latest/reference/drivers/index.html#single-driver-multiple-instances

However, note that DEVICE_INIT allocates a static struct device, so you
can't use DEVICE_GET() to access that device from another file.

If you're trying to get a pointer to your struct device from another
C file, you need to use something like this instead:

struct device *mydev = device_get_binding(CONFIG_MYDEV_NAME);

BR,
Martí

Thanks,
Justin

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