Date   

LWM2M: Call for proposals

Nashif, Anas
 

Hi,

In different forums and discussions around Zephyr features and the roadmap some interest was shown for getting LWM2M support in Zephyr.

Talking with different people and organizations we realized that there a few teams working on porting or have intentions to port existing LWM2M implementation to Zephyr. All is good news, however it would make sense to start talking about this on the mailing list and show intentions and progress and submit proposals so we can join forces and work on something common if possible.

Generally, we would like to adopt or support implementations that fit the architecture of Zephyr and that re-use existing components provided by Zephyr (CoAP, DTLS, ..). There are different approaches and ways this could be implemented, for example:

1. Native LWM2M support in Zephyr (native)
2. Import existing implementation into Zephyr and adapt it (fork)
3. Add support for Zephyr in existing implementation and support building for Zephyr (external)
4. Pull external code supporting zephyr as a module during build time (module)
5. Provide an LWM2M API in zephyr and allow external modules to implement those APIs (api)

I personally would have preferred native, but this would be a duplication given the number of implementations already out there, forking is not a favorite, so the remaining 3 options remain.

If you are working on LWM2M for Zephyr, please provide some information about your intentions or better provide a proposal by sending an RFC providing implementation details and how you want to integrate with rest of Zephyr.

Thanks,
Anas


Re: Daily digests...

Marti Bolivar <marti.bolivar@...>
 

+1, I miss these and it would be good to have them back.

On 16 March 2017 at 07:46, Marcus Shawcroft <marcus.shawcroft@gmail.com> wrote:
Folks, We don't appear to have had any daily gerrit digests since
7/3/2017. Does anyone know what this issue is?

Cheers
/Marcus
_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@lists.zephyrproject.org
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel


Re: File volume stats

Thomas, Ramesh
 

On Mon, Mar 20, 2017 at 23:19:02, phani karthik cs wrote:
Allocation unit size = 1024
This is 1024 bytes right?

Free space in f_frsize units = 1795
So free space would be (1795*1024)bytes.
Am I correct here?
That is correct.


On 21 Mar 2017 06:22, "Thomas, Ramesh" <ramesh.thomas@intel.com
<mailto:ramesh.thomas@intel.com> > wrote:


On Sun, Mar 19, 2017 at 22:22:05, phani karthik cs wrote:
> Hello all,
> Iam having trouble interpreting the fs_statvfs function. How
to
> interpret the below results that i ran on arduino 101
> -------------------------------------------------
> Optimal transfer block size = 512

This is the sector size. Data transfer size of the physical
storage media.

> Allocation unit size = 1024

Minimum size of storage the file system will allocate when
writing new
data. Will be multiples of block size.

> Volume size in f_frsize units = 2028
> Free space in f_frsize units = 1795

f_frsize is allocation unit size

> ------------------------------------------------ given the
above
> output, how much free memory do I have in bytes???
>
> Thank You
> Phani Karthik C S



Re: about multicasting with IPv4

Jukka Rissanen
 

Hi,

it is not enough to just add an API for adding the multicast address to
the interface. In order to routers send multicast traffic to the
device, it needs to also join IPv4 multicast group.
For IPv6 there is MLDv2 (Multicast Listener Discovery) support that was
added recently, so something similar should be done for IPv4.

Cheers,
Jukka

On Tue, 2017-03-21 at 08:13 +0000, 황윤희 wrote:
Dear Jukka,
 
Thanks for kind response.
I have a quesiton.
Is it possible to support IPv4 if only we make the api to add
multicast address?
Is that the only thing to do for enabling multicasting with IPv4 ?
I'm not sure if it's meaningful job that I make that api.
If then, I think I can try to do it.
But if not, it's impossible to me.
That's why I ask you about it.
 
Thanks and regards,
Hwang, Yunhee (Eunice)  
IoT Lab ,Software R&D Center
SAMSUNG ELECTRONICS CO.,LTD

TEL: +82-2-6147-7654
Moblie: +82-10-3421-1574
E-mail: yunhee.hwang@samsung.com
 
 
 
 
 
--------- Original Message ---------
Sender : Jukka Rissanen <jukka.rissanen@linux.intel.com>
Date : 2017-03-16 23:54 (GMT+9)
Title : Re: [Zephyr-devel] about multicasting with IPv4
 
Hi,

IPv4 multicast support is not really there yet. We have space in
net_if
struct (see net_if.h) for storing the IPv4 multicast addresses but
currently there is no API to set and/or use them.

Feel free to send patches to fix this if you can.

Cheers,
Jukka


On Thu, 2017-03-16 at 13:13 +0000, 황윤희 wrote:
Hello all,
 
I have a question about IPV4 dev status.
I check some networking funtions with IPv4. 
It seems to me that Zephyr doesn't have the api to set IPv4
multicast
address .
Doesn't Zephyr support IPv4 multicasting?
If it does, could anybody let me know how to enable it?
 
Thanks and regards,
Hwang, Yunhee (Eunice)  
IoT Lab ,Software R&D Center
SAMSUNG ELECTRONICS CO.,LTD
 
TEL: +82-2-6147-7654
Moblie: +82-10-3421-1574
E-mail: yunhee.hwang@samsung.com
 
 
 
  
  
_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@lists.zephyrproject.org
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel


File system in zephyr flashed on Arduino 101

Ani
 

I am using zephyr RTOS on Arduino 101. Ihave flashed the file system code where in the data is written in a file using fs_write as mentioned in the sample code. The changes I made are :
1. changed FS_SEEK_SET to FS_SEEK_END in fs_seek
2. and not deleting the file after writing

The problem is that after executing the code the no. of free blocks reduced from 1700+ to 200 . Now I am not able to retrieve the blocks again even after deleting. Can anyone help


Thanks and Regards, 
Anila


Re: about multicasting with IPv4

황윤희 <yunhee.hwang@...>
 

Dear Jukka,

 

Thanks for kind response.

I have a quesiton.

Is it possible to support IPv4 if only we make the api to add multicast address?

Is that the only thing to do for enabling multicasting with IPv4 ?

I'm not sure if it's meaningful job that I make that api.

If then, I think I can try to do it.

But if not, it's impossible to me.

That's why I ask you about it.

 

Thanks and regards,

Hwang, Yunhee (Eunice)  
IoT Lab ,Software R&D Center

SAMSUNG ELECTRONICS CO.,LTD

TEL: +82-2-6147-7654

Moblie: +82-10-3421-1574

E-mail: yunhee.hwang@...

 

 

 

 

 

--------- Original Message ---------

Sender : Jukka Rissanen <jukka.rissanen@...>

Date : 2017-03-16 23:54 (GMT+9)

Title : Re: [Zephyr-devel] about multicasting with IPv4

 

Hi,

IPv4 multicast support is not really there yet. We have space in net_if
struct (see net_if.h) for storing the IPv4 multicast addresses but
currently there is no API to set and/or use them.

Feel free to send patches to fix this if you can.

Cheers,
Jukka


On Thu, 2017-03-16 at 13:13 +0000, 황윤희 wrote:
> Hello all,
>  
> I have a question about IPV4 dev status.
> I check some networking funtions with IPv4. 
> It seems to me that Zephyr doesn't have the api to set IPv4 multicast
> address .
> Doesn't Zephyr support IPv4 multicasting?
> If it does, could anybody let me know how to enable it?
>  
> Thanks and regards,
> Hwang, Yunhee (Eunice)  
> IoT Lab ,Software R&D Center
> SAMSUNG ELECTRONICS CO.,LTD
> 
> TEL: +82-2-6147-7654
> Moblie: +82-10-3421-1574
> E-mail: yunhee.hwang@...
>  
>  
>  
>   
>   
> _______________________________________________
> Zephyr-devel mailing list
> Zephyr-devel@...
> https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel

 

 


Re: File volume stats

phani karthik cs <phanikartcs@...>
 

> Allocation unit size          = 1024
This is 1024 bytes right?

> Free space in f_frsize units  = 1795
So free space would be (1795*1024)bytes.
Am I correct here?

On 21 Mar 2017 06:22, "Thomas, Ramesh" <ramesh.thomas@...> wrote:
On Sun, Mar 19, 2017 at 22:22:05, phani karthik cs wrote:
> Hello all,
> Iam having trouble interpreting  the fs_statvfs function. How to
> interpret the below results that i ran on arduino 101
> -------------------------------------------------
> Optimal transfer block size   = 512

This is the sector size.  Data transfer size of the physical storage media.

> Allocation unit size          = 1024

Minimum size of storage the file system will allocate when writing new
data. Will be multiples of block size.

> Volume size in f_frsize units = 2028
> Free space in f_frsize units  = 1795

f_frsize is allocation unit size

> ------------------------------------------------ given the above
> output, how much free memory do I have in bytes???
>
> Thank You
> Phani Karthik C S



Re: File volume stats

Thomas, Ramesh
 

On Sun, Mar 19, 2017 at 22:22:05, phani karthik cs wrote:
Hello all,
Iam having trouble interpreting the fs_statvfs function. How to
interpret the below results that i ran on arduino 101
-------------------------------------------------
Optimal transfer block size = 512
This is the sector size. Data transfer size of the physical storage media.

Allocation unit size = 1024
Minimum size of storage the file system will allocate when writing new
data. Will be multiples of block size.

Volume size in f_frsize units = 2028
Free space in f_frsize units = 1795
f_frsize is allocation unit size

------------------------------------------------ given the above
output, how much free memory do I have in bytes???

Thank You
Phani Karthik C S


File volume stats

phani karthik cs <phanikartcs@...>
 

Hello all,
Iam having trouble interpreting  the fs_statvfs function. How to interpret the below results that i ran on arduino 101
-------------------------------------------------
Optimal transfer block size   = 512
Allocation unit size          = 1024
Volume size in f_frsize units = 2028
Free space in f_frsize units  = 1795
------------------------------------------------ given the above output, how much free memory do I have in bytes???

Thank You
Phani Karthik C S


NXP FRDM-K64F and OpenOCD from 0.9.0 SDK issue

Piotr Król <piotr.krol@...>
 

Hi all,
I'm not sure why, but OpenOCD from SDK can't flash and debug my K64F:

```
[16:51:40] pietrushnic:hello_world git:(master*) $ make BOARD=frdm_k64f flash
make[1]: Entering directory '/home/pietrushnic/storage/wdc/projects/2017/acme/src/zephyr'
make[2]: Entering directory '/home/pietrushnic/storage/wdc/projects/2017/acme/src/zephyr/samples/hello_world/outdir/frdm_k64f'
Using /home/pietrushnic/storage/wdc/projects/2017/acme/src/zephyr as source for kernel
GEN ./Makefile
CHK include/generated/version.h
CHK misc/generated/configs.c
CHK include/generated/generated_dts_board.h
CHK include/generated/offsets.h

make[3]: 'isr_tables.o' is up to date.

Flashing frdm_k64f
Flashing Target Device
Open On-Chip Debugger 0.9.0-dirty (2017-01-08-19:49)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
Info : only one transport option; autoselect 'swd'
Info : add flash_bank kinetis k60.flash
adapter speed: 1000 kHz
none separate
cortex_m reset_config sysresetreq
Error: unable to find CMSIS-DAP device

Done flashing
```

I compiled OpenOCD from master and with that version flashing and debugging works:

```
[16:51:46] pietrushnic:hello_world git:(master*) $ OPENOCD=/usr/local/bin/openocd make BOARD=frdm_k64f flash
make[1]: Entering directory '/home/pietrushnic/storage/wdc/projects/2017/acme/src/zephyr'
make[2]: Entering directory '/home/pietrushnic/storage/wdc/projects/2017/acme/src/zephyr/samples/hello_world/outdir/frdm_k64f'
Using /home/pietrushnic/storage/wdc/projects/2017/acme/src/zephyr as source for kernel
GEN ./Makefile
CHK include/generated/version.h
CHK misc/generated/configs.c
CHK include/generated/generated_dts_board.h
CHK include/generated/offsets.h
make[3]: 'isr_tables.o' is up to date.
Flashing frdm_k64f
Flashing Target Device
Open On-Chip Debugger 0.10.0+dev-00093-g6b2acc0243f6 (2017-03-18-15:52)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
Info : auto-selecting first available session transport "swd". To override use 'transport select <transport>'.
Info : add flash_bank kinetis k60.flash
adapter speed: 1000 kHz
none separate
cortex_m reset_config sysresetreq
Info : CMSIS-DAP: SWD Supported
Info : CMSIS-DAP: Interface Initialised (SWD)
Info : CMSIS-DAP: FW Version = 1.0
Info : SWCLK/TCK = 0 SWDIO/TMS = 1 TDI = 0 TDO = 0 nTRST = 0 nRESET = 1
Info : CMSIS-DAP: Interface ready
Info : clock speed 1000 kHz
Info : SWD DPIDR 0x2ba01477
Info : k60.cpu: hardware has 6 breakpoints, 4 watchpoints
Info : MDM: Chip is unsecured. Continuing.
TargetName Type Endian TapName State
-- ------------------ ---------- ------ ------------------ ------------
0* k60.cpu cortex_m little k60.cpu running
Info : MDM: Chip is unsecured. Continuing.
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x00001a28 msp: 0x20000640
auto erase enabled
Info : Probing flash info for bank 0
Warn : Flash Configuration Field written.
Warn : Reset or power off the device to make settings effective.
wrote 12288 bytes from file /home/pietrushnic/storage/wdc/projects/2017/acme/src/zephyr/samples/hello_world/outdir/frdm_k64f/zephyr.bin in 0.995954s (12.049 KiB/s)
Info : MDM: Chip is unsecured. Continuing.
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x00001a28 msp: 0x20000640
Error: timed out while waiting for target halted
target halted due to debug-request, current mode: Thread
xPSR: 0x41000000 pc: 0x000018f8 psp: 0x20000730
Error: error executing cortex_m crc algorithm
verified 10520 bytes in 20.876684s (0.492 KiB/s)
Info : MDM: Chip is unsecured. Continuing.
shutdown command invoked
Done flashing
make[2]: Leaving directory '/home/pietrushnic/storage/wdc/projects/2017/acme/src/zephyr/samples/hello_world/outdir/frdm_k64f'
make[1]: Leaving directory '/home/pietrushnic/storage/wdc/projects/2017/acme/src/zephyr'
```

The only thing I'm worry about is `error executing cortex_m crc algorithm` any idea what maybe wrong ?

Is there any way to fix `unable to find CMSIS-DAP device` in SDK OpenOCD ?

Best Regards,
--
Piotr Król
Embedded Systems Consultant
http://3mdeb.com | @3mdeb_com


Re: [RFC] MPU support for debugging

Piotr Mienkowski
 


On 14.03.2017 20:08, Boie, Andrew P wrote:
On Tue, 2017-03-14 at 17:29 +0100, Piotr Mienkowski wrote:
I would like to add one more point to the discussion. It is maybe not directly
related to the topic but should likely be considered when designing MPU
support.

Occasionally, mainly in case of device drivers, on MCUs that have cache it is
required to use the so called non-cacheable RAM regions. A memory region for
which caching has been turned off. This task is typically done by MPU/MMU and
Zephyr MPU architecture should also support it. I.e. as a developer I would
like to have a possibility to place a specific variable / set of variables in
a non-cacheable RAM region.
This is a great topic to bring up. In addition to an MPU policy to protect
threads for debugging, we do need to specify a system-level policy that get
applied at boot, even if we are not protecting individual threads.

Are you thinking that this would be something declared at the SOC level? I think
because of the size and alignment constraints of MPU regions, we may want to
configure these reasons in a central area. You may be interested to look at
Vincenzo's patches, which define MPU regions for a few ARM SOCs at boot:

https://gerrit.zephyrproject.org/r/#/q/topic:zephyr_mpu
I was indeed thinking that non-cachable RAM region would be declared at the SoC level. It's simple and efficient. However, probably not compatible with per thread memory protection as a security feature model.

Thanks for the link. That looks interesting indeed, though to support non-cachable RAM region we would also need to modify the linker script. It would probably be best to do it at the same time or after we touch the linker script to add support for all the features we are talking about here.
Looking at this another way, maybe we need to consider different levels of
memory protection support, each building on top of the previous level. What
level any given board target supports will be determined by the available memory
protection hardware and its capabilities, as well as how much extra RAM we can
waste to accommodate the alignment constraints of the MPU hardware:

1) No memory protection

2) System-wide memory protection policy, set at boot by board or SOC code.

3) Per-thread stack overflow protection. We configure the MPU, on a per-thread
basis, to trigger an exception if the thread tries to write past its available
stack space. I think this should only require 1 extra region, just a sentinel
area immediately before the thread's stack to catch writes, with the struct
k_thread stored elsewhere. I think this is something simple we can do which will
make a lot of people happy given how painful stack overflows can be to debug if
you don't know they are happening.

4) Per-thread memory protection. User threads can only write to their own stack
+ additional runtime-configurable memory regions. System calls to interact with
the kernel, whose memory is otherwise untouchable. Basically what we have been
talking about so far.

5) Virtualized memory (MMU). Application and kernel run in different virtualized
memory spaces. Introduce the possibility of different isolated zephyr processes.
That all sounds very reasonable. Every next level of memory protection support builds upon the effort spent and experience gained at the previous one. The only danger with having multiple protection levels is that it may become opaque to the end user.

I have question to the per-thread memory protection model. Maybe the answer is obvious. What about data passed between threads, like data buffers passed through FIFOs? E.g. our networking stack supports zero copy mechanism. A pointer to the data buffer that was filled in by a data link layer driver (working typically in the interrupt context) is passed to the RX thread, user application thread, maybe TX thread. Are such data buffers going to live in a memory region that is accessible to all?

Regards,
Piotr


Re: about multicasting with IPv4

Jukka Rissanen
 

Hi,

IPv4 multicast support is not really there yet. We have space in net_if
struct (see net_if.h) for storing the IPv4 multicast addresses but
currently there is no API to set and/or use them.

Feel free to send patches to fix this if you can.

Cheers,
Jukka

On Thu, 2017-03-16 at 13:13 +0000, 황윤희 wrote:
Hello all,
 
I have a question about IPV4 dev status.
I check some networking funtions with IPv4. 
It seems to me that Zephyr doesn't have the api to set IPv4 multicast
address .
Doesn't Zephyr support IPv4 multicasting?
If it does, could anybody let me know how to enable it?
 
Thanks and regards,
Hwang, Yunhee (Eunice)  
IoT Lab ,Software R&D Center
SAMSUNG ELECTRONICS CO.,LTD

TEL: +82-2-6147-7654
Moblie: +82-10-3421-1574
E-mail: yunhee.hwang@samsung.com
 
 
 
  
  
_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@lists.zephyrproject.org
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel


Re: Upgrade of RTC api.

Michał Kruszewski <mkru@...>
 

I have just realized that my previous idea with alarm descriptors has one drawback.

Lets suppose the counter value is 4. If rtc needs 2 ticks to start working and catch compare events (for example nordic RTC) then if we set an alarm on value 5 we will miss it.
In above example interrupt has to be triggered in rtc_set_alarm_function(). According to solution with alarm descriptors interrupt would be triggered before alarm_descriptor would be returned.
Instead alarm descriptor I propose to pass a pointer to alarm callback function to rtc_set_alarm function.
Here is git diff:

diff --git a/include/rtc.h b/include/rtc.h
index 40c24c5..6b68fca 100644
--- a/include/rtc.h
+++ b/include/rtc.h
@@ -50,6 +50,7 @@ enum clk_rtc_div {


struct rtc_config {
+       clk_rtc_div divider;
        uint32_t init_val;
        /*!< enable/disable alarm  */
        uint8_t alarm_enable;
@@ -60,12 +61,19 @@ struct rtc_config {
        void (*cb_fn)(struct device *dev);
};

+struct rtc_alarm {
+       uint32_t alarm_val;
+       /*!< Pointer to function to call when alarm value
+        * matches current RTC value */
+       void (*cb_fn)(struct device *dev);
+};
+
typedef void (*rtc_api_enable)(struct device *dev);
typedef void (*rtc_api_disable)(struct device *dev);
typedef int (*rtc_api_set_config)(struct device *dev,
                                  struct rtc_config *config);
typedef int (*rtc_api_set_alarm)(struct device *dev,
-                                const uint32_t alarm_val);
+                                const struct rtc_alarm *alarm_val);
typedef uint32_t (*rtc_api_read)(struct device *dev);
typedef uint32_t (*rtc_api_get_pending_int)(struct device *dev);

Michal Kruszewski


about multicasting with IPv4

황윤희 <yunhee.hwang@...>
 

Hello all,

 

I have a question about IPV4 dev status.

I check some networking funtions with IPv4. 

It seems to me that Zephyr doesn't have the api to set IPv4 multicast address .

Doesn't Zephyr support IPv4 multicasting?

If it does, could anybody let me know how to enable it?

 

Thanks and regards,

Hwang, Yunhee (Eunice)  
IoT Lab ,Software R&D Center

SAMSUNG ELECTRONICS CO.,LTD

TEL: +82-2-6147-7654

Moblie: +82-10-3421-1574

E-mail: yunhee.hwang@...

 

 

 

 

 


Re: Upgrade of RTC api.

Michał Kruszewski <mkru@...>
 

>> I wanted to implement rtc driver for nrf chips and I think that rtc.h api is too loosely defined.
>> Chips from IC vendors are very different in terms of RTC peripheral, for example:
>> a) different number of RTC instances
> Do you think we will have systems with multiple RTC in them? I’m generally for supporting multiples of a given device type, just wonder about RTCs.

Current API already supports multiple instances of a given device
driver, so that's fine.

You are right, there is not need to change that

>> b) different number of compare/alarm registers

That is missing indeed. Or, more precisely, the only current way to
support this is to
have a struct device instance per set of compar/alarm on an rtc, which
is not what we want I guess.

>> c) some can generate additional events like TICK for tick-less RTOS
>> d) some have registers for current time and format of that time can also differ
> We need to have a standard view of time regardless of how different RTCs encode this.
>
>> e) different size of COUNTER register (that's actually not a big issue cause you can always implement 32 bit counter in software).
>>
>> I would like to implement more advanced rtc api and I would like you to help me define how it should look like. For example:
>> 1. How many alarms can be set on single RTC, should it be configured via Kconfig (even with single alarm register it is possible to implement it in software) or the number of alarms should equal to number of available compare registers?
> I think this will more depend on what interface we expose to applications for utilizing alarms. If most RTCs provide more than a single alarm (I’d assume they would) than we should allow apps to request alarms until they run out of the resource.

You will need to revert the current way rtc is configured I believe.

The device driver would own as many struct rtc_config pointers as it has
of compare/alarm set of registers.

rtc_set_config() would, if a slot is free, install the given
configuration. If not it would get a -EAGAIN

It would require a rtc_remove_config() or rtc_unset_config(), to
un-install the given config pointer.

Just thinking out loud though, maybe there is a better way. The point is
to avoid application to know the number of alarms at built time.
I should be ready to deal with the impossibility to get a slot I think.

About software emulation on top of 1 unique counter/alarm set, sounds a
bit like what we have in kernel as timers.
Code could be generic for that.

Maybe mixing hw and emulation even, if struct rtc_config gets a
sys_dlist node? (bloats a bit the rtc_config struct though).
I mean: being directly installed on an available hw or being emulated,
would be transparent for the app. But it adds up complexity on driver side.

>
>> 2. Should we keep track of current time inside rtc driver or should there be some higher module that would only use rtc driver, if yes then what format of time should we use, should it be configurable?
> We should have probably a slightly generic api to get time built on top of rtc to abstract some of the differences to the app.

Agree on that

>
>> 3. Should we implement different modes for alarms (single shot, periodic) or maybe alarm channels should be allocated and then freed when not needed?
> Seems like you are asking about 2 different things here. But I would say yes, we allow for different types and allow for alloc/free of alarms.

add a uint8_t type in struct rtc_config
After rethinking, this feature is also easy to implement in some higher level code. I think drivers should be simple and reproduce what is inside hardware.
There is no register or bit that can be changed in order to change mode to periodic, so do not implement it in driver, implement it higher.
>
>> 4. What about some extra events like TICK, OVERFLOW?
> This would be a counter feature, correct?

We do mix features in 2 distinct APIs for now.
Shall we move stuff into one unique timer.h API for instance?

Are there hw limitations though? isn't there rtc that can be only
counters? (then it would blow up the idea I guess).

You are right, I have come to realize that TICK and OVERFLOW features are not needed in zephyr. If someone needs it then he can embed it in application specific code.

>
>> 5. Should there be only one callback function? rtc_api_set_alarm could then return descriptor to alarm and inside callback function we could check what exact alarm was triggered. Or maybe we should pass pointer to callback function as an argument to rtc_api_set_alarm function?
> Not sure I follow. Maybe work up a draft API interface with some comments for further discussion

struct rtc_config pointer could be provided to the callback.

Being allocated by the application, it could then with CONTAINER_OF()
retrieve some private data, if the struct rtc_config is part of private
structure holding private data.


TO SUM UP:
I would like to RFC in rtc.h api to enable setting multiple alarms on single RTC. Here is git diff on rtc.h
diff --git a/include/rtc.h b/include/rtc.h
index 40c24c5..44beb3d 100644
--- a/include/rtc.h
+++ b/include/rtc.h
@@ -50,6 +50,7 @@ enum clk_rtc_div {


struct rtc_config {
+       enum clk_rtc_div divider;
        uint32_t init_val;
        /*!< enable/disable alarm  */
        uint8_t alarm_enable;
@@ -66,15 +67,17 @@ typedef int (*rtc_api_set_config)(struct device *dev,
                                  struct rtc_config *config);
typedef int (*rtc_api_set_alarm)(struct device *dev,
                                 const uint32_t alarm_val);
+typedef int (*rtc_api_get_alarm_descriptor)(struct device *dev);
typedef uint32_t (*rtc_api_read)(struct device *dev);
typedef uint32_t (*rtc_api_get_pending_int)(struct device *dev);

struct rtc_driver_api {
        rtc_api_enable enable;
        rtc_api_disable disable;
-       rtc_api_read read;
        rtc_api_set_config set_config;
        rtc_api_set_alarm set_alarm;
+       rtc_api_get_alarm_descriptor get_alarm_descriptor;
+       rtc_api_read read;
        rtc_api_get_pending_int get_pending_int;
};

@@ -116,6 +119,13 @@ static inline int rtc_set_alarm(struct device *dev,
        return api->set_alarm(dev, alarm_val);
}

+static inline int rtc_get_alarm_descriptor(struct device *dev)
+{
+       const struct rtc_driver_api *api = dev->driver_api;
+
+       return api->get_alarm_descriptor(dev);
+}

Here is an example on how this api could be used on chips where RTC can handle multiple alarms:
#define ALARM (RTC_ALARM_SECOND)
#define ALARM_2 (5*RTC_ALARM_SECOND)

/* Following variables are used by nrf chips, where single RTC can set multiple
* alarms. */
int ad_1; /* Alarm descriptor 1 */
int ad_2; /* Alarm descriptor 2 */

#if defined(CONFIG_QMSI)
void test_rtc_interrupt_fn(struct device *rtc_dev)
{};
#elif defined(CONFIG_SOC_FAMILY_NRF5)
void alarm_1_handler(struct device *rtc_dev)
{};

void alarm_2_handler(struct device *rtc_dev)
{};

void test_rtc_interrupt_fn(struct device *rtc_dev)
{
        int alarm_descriptor;
        alarm_descriptor = rtc_get_alarm_descriptor(rtc_dev);

        /* Check alarm descritor to determine which alarm hanlder should be
        * called. Valid only for RTC capable of handling multiple alarms */
        if (alarm_descriptor == ad_1) {
                alarm_1_handler(rtc_dev);
        } else if (alarm_descriptor == ad_2) {
                alarm_2_handler(rtc_dev);
        }
}
#endif

void main(void)
{
        struct rtc_config config;
        struct device *rtc_dev;

        printk("Test RTC driver\n");
        rtc_dev = device_get_binding(CONFIG_RTC_0_NAME);

        config.divider = RTC_CLK_DIV_1;
        config.init_val = 0;
        config.alarm_enable = 1;
        config.alarm_val = ALARM;
        config.cb_fn = test_rtc_interrupt_fn;

       rtc_enable(rtc_dev);

#if defined(CONFIG_QMSI)
        rtc_set_config(rtc_dev, &config);
#elif defined(CONFIG_SOC_FAMILY_NRF5)
        ad_1 = rtc_set_config(rtc_dev, &config);
        if (ad_1 == -EAGAIN) {
                printk("Can't configure RTC cause there is at least one alarm set\n");
        } else {
                printk("RTC configured and alarm descriptor returned if you have set alarm_enable field\n");
        }

        ad_2 = rtc_set_alarm(rtc_dev, ALARM_2);
        if (ad_2 == -ENOMEM) {
                printk("Can't set an alarm, no more resources for alarms\n");
        } else {
                printk("Alarm set, alarm descriptor returned\n");
        };
#endif

        while (1) {
        }
}

My change has no impact on devices where only one alarm can be set on RTC.

Michał Kruszewski

Sent with ProtonMail Secure Email.


Re: Upgrade of RTC api.

Tomasz Bursztyka
 

Hi, (quick resend for the thread owner)

I wanted to implement rtc driver for nrf chips and I think that rtc.h api is too loosely defined.
Chips from IC vendors are very different in terms of RTC peripheral, for example:
a) different number of RTC instances
Do you think we will have systems with multiple RTC in them? I’m generally for supporting multiples of a given device type, just wonder about RTCs.
Current API already supports multiple instances of a given device driver, so that's fine.

b) different number of compare/alarm registers
That is missing indeed. Or, more precisely, the only current way to support this is to
have a struct device instance per set of compar/alarm on an rtc, which is not what we want I guess.

c) some can generate additional events like TICK for tick-less RTOS
d) some have registers for current time and format of that time can also differ
We need to have a standard view of time regardless of how different RTCs encode this.

e) different size of COUNTER register (that's actually not a big issue cause you can always implement 32 bit counter in software).

I would like to implement more advanced rtc api and I would like you to help me define how it should look like. For example:
1. How many alarms can be set on single RTC, should it be configured via Kconfig (even with single alarm register it is possible to implement it in software) or the number of alarms should equal to number of available compare registers?
I think this will more depend on what interface we expose to applications for utilizing alarms. If most RTCs provide more than a single alarm (I’d assume they would) than we should allow apps to request alarms until they run out of the resource.
You will need to revert the current way rtc is configured I believe.

The device driver would own as many struct rtc_config pointers as it has of compare/alarm set of registers.

rtc_set_config() would, if a slot is free, install the given configuration. If not it would get a -EAGAIN

It would require a rtc_remove_config() or rtc_unset_config(), to un-install the given config pointer.

Just thinking out loud though, maybe there is a better way. The point is to avoid application to know the number of alarms at built time.
I should be ready to deal with the impossibility to get a slot I think.

About software emulation on top of 1 unique counter/alarm set, sounds a bit like what we have in kernel as timers.
Code could be generic for that.

Maybe mixing hw and emulation even, if struct rtc_config gets a sys_dlist node? (bloats a bit the rtc_config struct though).
I mean: being directly installed on an available hw or being emulated, would be transparent for the app. But it adds up complexity on driver side.


2. Should we keep track of current time inside rtc driver or should there be some higher module that would only use rtc driver, if yes then what format of time should we use, should it be configurable?
We should have probably a slightly generic api to get time built on top of rtc to abstract some of the differences to the app.
Agree on that


3. Should we implement different modes for alarms (single shot, periodic) or maybe alarm channels should be allocated and then freed when not needed?
Seems like you are asking about 2 different things here. But I would say yes, we allow for different types and allow for alloc/free of alarms.
add a uint8_t type in struct rtc_config


4. What about some extra events like TICK, OVERFLOW?
This would be a counter feature, correct?
We do mix features in 2 distinct APIs for now.
Shall we move stuff into one unique timer.h API for instance?

Are there hw limitations though? isn't there rtc that can be only counters? (then it would blow up the idea I guess).


5. Should there be only one callback function? rtc_api_set_alarm could then return descriptor to alarm and inside callback function we could check what exact alarm was triggered. Or maybe we should pass pointer to callback function as an argument to rtc_api_set_alarm function?
Not sure I follow. Maybe work up a draft API interface with some comments for further discussion
struct rtc_config pointer could be provided to the callback.

Being allocated by the application, it could then with CONTAINER_OF() retrieve some private data, if the struct rtc_config is part of private structure holding private data.

Tomasz


Daily digests...

Marcus Shawcroft <marcus.shawcroft@...>
 

Folks, We don't appear to have had any daily gerrit digests since
7/3/2017. Does anyone know what this issue is?

Cheers
/Marcus


Re: Upgrade of RTC api.

Tomasz Bursztyka
 

Hi,

I wanted to implement rtc driver for nrf chips and I think that rtc.h api is too loosely defined.
Chips from IC vendors are very different in terms of RTC peripheral, for example:
a) different number of RTC instances
Do you think we will have systems with multiple RTC in them? I’m generally for supporting multiples of a given device type, just wonder about RTCs.
Current API already supports multiple instances of a given device driver, so that's fine.

b) different number of compare/alarm registers
That is missing indeed. Or, more precisely, the only current way to support this is to
have a struct device instance per set of compar/alarm on an rtc, which is not what we want I guess.

c) some can generate additional events like TICK for tick-less RTOS
d) some have registers for current time and format of that time can also differ
We need to have a standard view of time regardless of how different RTCs encode this.

e) different size of COUNTER register (that's actually not a big issue cause you can always implement 32 bit counter in software).

I would like to implement more advanced rtc api and I would like you to help me define how it should look like. For example:
1. How many alarms can be set on single RTC, should it be configured via Kconfig (even with single alarm register it is possible to implement it in software) or the number of alarms should equal to number of available compare registers?
I think this will more depend on what interface we expose to applications for utilizing alarms. If most RTCs provide more than a single alarm (I’d assume they would) than we should allow apps to request alarms until they run out of the resource.
You will need to revert the current way rtc is configured I believe.

The device driver would own as many struct rtc_config pointers as it has of compare/alarm set of registers.

rtc_set_config() would, if a slot is free, install the given configuration. If not it would get a -EAGAIN

It would require a rtc_remove_config() or rtc_unset_config(), to un-install the given config pointer.

Just thinking out loud though, maybe there is a better way. The point is to avoid application to know the number of alarms at built time.
I should be ready to deal with the impossibility to get a slot I think.

About software emulation on top of 1 unique counter/alarm set, sounds a bit like what we have in kernel as timers.
Code could be generic for that.

Maybe mixing hw and emulation even, if struct rtc_config gets a sys_dlist node? (bloats a bit the rtc_config struct though).
I mean: being directly installed on an available hw or being emulated, would be transparent for the app. But it adds up complexity on driver side.


2. Should we keep track of current time inside rtc driver or should there be some higher module that would only use rtc driver, if yes then what format of time should we use, should it be configurable?
We should have probably a slightly generic api to get time built on top of rtc to abstract some of the differences to the app.
Agree on that


3. Should we implement different modes for alarms (single shot, periodic) or maybe alarm channels should be allocated and then freed when not needed?
Seems like you are asking about 2 different things here. But I would say yes, we allow for different types and allow for alloc/free of alarms.
add a uint8_t type in struct rtc_config


4. What about some extra events like TICK, OVERFLOW?
This would be a counter feature, correct?
We do mix features in 2 distinct APIs for now.
Shall we move stuff into one unique timer.h API for instance?

Are there hw limitations though? isn't there rtc that can be only counters? (then it would blow up the idea I guess).


5. Should there be only one callback function? rtc_api_set_alarm could then return descriptor to alarm and inside callback function we could check what exact alarm was triggered. Or maybe we should pass pointer to callback function as an argument to rtc_api_set_alarm function?
Not sure I follow. Maybe work up a draft API interface with some comments for further discussion
struct rtc_config pointer could be provided to the callback.

Being allocated by the application, it could then with CONTAINER_OF() retrieve some private data, if the struct rtc_config is part of private structure holding private data.

Tomasz


Re: Testing random number generators

Daniel Thompson <daniel.thompson@...>
 

On 15/03/17 13:37, Kumar Gala wrote:
On Mar 13, 2017, at 11:10 AM, Geoffrey LE GOURRIEREC <geoffrey.legourrierec@smile.fr> wrote:

Hi all,

I realized recently that no random number generation API
test framework was available in Zephyr (apart from a very simple test
in tests/kernel/common/src/rand32.c).
I realize hardware number generators differ in expected "quality"
and that such a framework should allow tuning expected results,
like the generators' guaranteed period, for instance.

I took a look recently at the ENT program (http://www.fourmilab.ch/random/),
which performs a battery of tests on streams of bytes, and
provides global metrics at the end of the tests (correlation, mean value...).

This is only a suggestion, but we could write a simple generic framework using
the UART serial line to run the test with ENT running on the host computer.
I find ENT to be simple to use, and besides, its byte-level granulatity matches
the API exposed by random.h. I don't have extensive experience with hardware
number generators and therefore am probably unaware of potential issues
regarding the efforts to make generic test metrics (lack of hardware documentation
comes to my mind).

Any ideas or critics are welcome.

Regards,
Seems like a pretty worth while thing to work on. We have some
support for a few random number generators in the tree already
(drivers/random). So I think a test app as you described shouldn’t
be too difficult to work up and writeup how to connect with ENT.
Would be a great idea. Especially useful to bring to the surface RNGs that have been interfaced to the system without a whitening filter...


Daniel.


Re: Testing random number generators

Kumar Gala
 

On Mar 13, 2017, at 11:10 AM, Geoffrey LE GOURRIEREC <geoffrey.legourrierec@smile.fr> wrote:

Hi all,

I realized recently that no random number generation API
test framework was available in Zephyr (apart from a very simple test
in tests/kernel/common/src/rand32.c).
I realize hardware number generators differ in expected "quality"
and that such a framework should allow tuning expected results,
like the generators' guaranteed period, for instance.

I took a look recently at the ENT program (http://www.fourmilab.ch/random/),
which performs a battery of tests on streams of bytes, and
provides global metrics at the end of the tests (correlation, mean value...).

This is only a suggestion, but we could write a simple generic framework using
the UART serial line to run the test with ENT running on the host computer.
I find ENT to be simple to use, and besides, its byte-level granulatity matches
the API exposed by random.h. I don't have extensive experience with hardware
number generators and therefore am probably unaware of potential issues
regarding the efforts to make generic test metrics (lack of hardware documentation
comes to my mind).

Any ideas or critics are welcome.

Regards,
Seems like a pretty worth while thing to work on. We have some support for a few random number generators in the tree already (drivers/random). So I think a test app as you described shouldn’t be too difficult to work up and writeup how to connect with ENT.

- k

5121 - 5140 of 7734