Date   

Re: i can debug my STM32-F411RE running zephyr with OpenOCD and arm-none-eabi-gdb, but how can i do this with arduino_due board with the same tools?

Erwan Gouriou
 

Hi,

Are you using Nulceo_f411RE?
If this is the case, this board embeds a ST-LINK debugger/programmer that
helps you controling your board with USB.
This is specific to ST developpement boards like Nucleo, Disco or Eval.

If you want to debug on Arduino, please refer to dedicated wiki page:
https://wiki.zephyrproject.org/view/Arduino_101

Cheers

On 25 January 2017 at 09:51, 曹子龙 <13824125580(a)163.com> wrote:

Hi all:

i can debug my STM32-F411RE running zephyr with OpenOCD and
arm-none-eabi-gdb, the BOARD and the PC host connected directly with the
USB wire, i can use this simple things to debug the zephyr flow from _reset.

what puzzle me is that from the document of OpenOCD, we must be connect
to the JTAG of the board, but i use the usb of F411re do the same thing, i
dont know why?

and if i want to do the debug operation on arduino_due, did this can be
done by using the same tools like F411re ? thanks for your kindly reply.


i can debug my STM32-F411RE running zephyr with OpenOCD and arm-none-eabi-gdb, but how can i do this with arduino_due board with the same tools?

曹子龙 <13824125580 at 163.com...>
 

Hi all:


i can debug my STM32-F411RE running zephyr with OpenOCD and arm-none-eabi-gdb, the BOARD and the PC host connected directly with the USB wire, i can use this simple things to debug the zephyr flow from _reset.


what puzzle me is that from the document of OpenOCD, we must be connect to the JTAG of the board, but i use the usb of F411re do the same thing, i dont know why?


and if i want to do the debug operation on arduino_due, did this can be done by using the same tools like F411re ? thanks for your kindly reply.


Re: samples/net/zoap_server - blockwise transfers?

Bober, Wojciech <Wojciech.Bober@...>
 

Hi Vinicius,

Thanks for the reply. Sure, feel free to add me to the review.

Kind regards,
Wojtek

-----Original Message-----
From: Vinicius Costa Gomes [mailto:vinicius.gomes(a)intel.com]
Sent: 24 January 2017 19:43
To: Bober, Wojciech <Wojciech.Bober(a)nordicsemi.no>; devel(a)lists.zephyrproject.org
Subject: [devel] Re: samples/net/zoap_server - blockwise transfers?

Hi Wojtek,

"Bober, Wojciech" <Wojciech.Bober(a)nordicsemi.no> writes:

Hi,

I'm playing around with zoap_server on nrf52_pca10040 but I can't get the blockwise transfers to work.
There are still some bugs in the implementation, I am working on solving them, I just noticed it when I was running a CoAP test suite
(californium) against zoap-server. Seems that my previous tests were incomplete.

When I do GET to /large I get "[zoap-server] [ERR] udp_receive: No handler for such request (-22)" in the log. The large_get handler fails at zoap_update_from_block() function. It doesn't matter if the block2 option is present in the request or not.

I also have issue with PUT to /large-update. The behaviour is inconsistent: sometimes I get the same error as above other times I get a reply to the request but I've also seen ACK Continue with Block2 (I think it should be Block1).

Any ideas what might be wrong?
In short, there was a stupid bug in parsing of integer options (this was already merged into the net branch), but I am still working on it, I can add you as reviewer as I propose the changes, if you are interested.


Kind regards,
Wojtek

Cheers,
--
Vinicius


Re: How to overcome timer delay

Dinh, Kien T
 

Thank you so much for the explanations, Ben.

Kien

On 2017/01/25 1:23, "Benjamin Walsh" <benjamin.walsh(a)windriver.com> wrote:

> > > I’m developing an app which requires fast sampling rate (~500 times
> > > per sec) via the ADC on the Arduino 101. It was alright using
> > > nano_timer_init/start/test APIs up version 1.5. However, after
> > > upgrading to version 1.6, noticeable time delay has been observed. To
> > > remove possible effects from other drivers, I’ve used the following
> > > code to test the time delay and got the below results.
> > >
> > > It seems that the amount of delay is inversely proportional to the
> > > interval. For interval = 1000 ms, the delay is just 10 ms. But for
> > > interval as high as 10 ms, the delay becomes 1000 ms, making it
> > > impossible to use for high sampling rate app. Is there any Kconfig
> > > needs to be set or any way to minimize such delay?
> >
> > When we changed the new API to take ms instead of kernel ticks for
> > timeouts, we also decided the timeouts mean "wait for at least this
> > time" instead of "wait for at most this time".
> >
> > The system is still tick-based though. So we convert ms to ticks
> > internally.
> >
> > If you want to wait "at most" an amount of time, you have to ask for
> > one tick less. So if you know your tick rate is 100Hz, and you want to
> > wait at most 20ms, you have to ask for 10ms (that would give you two
> > ticks).
> >
> > Now, you say your sampling rate is 500Hz: however, the default tick rate
> > is 100Hz. You have to change CONFIG_SYS_CLOCK_TICKS_PER_SEC to 500.
> > However (again), since with a tick freq of 500Hz, if you wait for 2ms
> > you'll wait for "at least" 2ms, you might wait for 4ms. So what you
> > probably want is a CONFIG_SYS_CLOCK_TICKS_PER_SEC of 1000, and wait for
> > 1ms, which will make you wait at most for 2ms.
> >
> > I'm starting to wonder if we should have macros for this in the API,
> > e.g. AT_MOST()/AT_LEAST(), where you could do:
> >
> > k_timer_start(&my_timer, AT_MOST(INTERVAL), 0);
> >
> > This is all because the kernel is still tick-based. We would like to
> > move to a tickless kernel, where these would not be an issue anymore.
> >
> > > =====
> > >
> > > #include <zephyr.h>
> > > #include <misc/printk.h>
> > >
> > > #define INTERVAL 1
> > >
> > > static int count;
> > > static int t;
> > >
> > > void timer_handler(struct k_timer *a_timer)
> > > {
> > > count += INTERVAL;
> > > if (count % 1000 == 0) {
> > > printk("Count %d, delta = %d\n", count,
> > > k_uptime_get_32() - t);
> > > t = k_uptime_get_32();
> > > }
> > > }
> > >
> > > void main(void)
> > > {
> > > struct k_timer my_timer;
> > >
> > > printk("Hello World! %s\n", CONFIG_ARCH);
> > > k_timer_init(&my_timer, timer_handler, NULL);
> > > t = k_uptime_get_32();
> > > while (1) {
> > > k_timer_start(&my_timer, INTERVAL, K_FOREVER);
> > ^^^^^^^^^
> > You cannot use K_FOREVER in this API: if you do not want periodic
> > repetition, you have to use 0.
> >
> > I'm surprised this did not blow up. Actually, if you ran with
> > CONFIG_ASSERT=y, you would have hit the one at the top of
> > _add_timeout():
> >
> > __ASSERT(timeout_in_ticks > 0, "");
> >
> >
> > > k_timer_status_sync(&my_timer);
> > > }
> > > }
> > > ====
> > >
> > > I got the same following outputs for both x86 qemu and Arduino 101 (x86):
> > >
> > > * INTERVAL = 1000 (one second)
> > > Count 1000, delta = 1010
> > > Count 2000, delta = 1010
> > > Count 3000, delta = 1010
> > > …
> > >
> > > * INTERVAL = 100 (one hundred millisecs)
> > > Count 1000, delta = 1100
> > > Count 2000, delta = 1100
> > > Count 3000, delta = 1100
> > > …
> > >
> > > * INTERVAL = 10 (ten millisecs)
> > > Count 1000, delta = 2000
> > > Count 2000, delta = 2000
> > > Count 3000, delta = 2000
> > > …
> > >
> > > * INTERVAL = 1 (one millisec)
> > > Count 1000, delta = 20000
> > > Count 2000, delta = 20000
> > > Count 3000, delta = 20000
> >
> > You're getting these numbers because your tick rate is probably 100.
> > With 1000 you would probably get:
> >
> > * INTERVAL = 1000 (one second)
> > Count 1000, delta = 1001
> > Count 2000, delta = 1001
> > Count 3000, delta = 1001
> > …
> >
> > * INTERVAL = 100 (one hundred millisecs)
> > Count 1000, delta = 1010
> > Count 2000, delta = 1010
> > Count 3000, delta = 1010
> > …
> >
> > * INTERVAL = 10 (ten millisecs)
> > Count 1000, delta = 1100
> > Count 2000, delta = 1100
> > Count 3000, delta = 1100
> > …
> >
> > * INTERVAL = 1 (one millisec)
> > Count 1000, delta = 2000
> > Count 2000, delta = 2000
> > Count 3000, delta = 2000
>
> Thank you for your reply and advices. Setting
> CONFIG_SYS_CLOCK_TICKS_PER_SEC=1000 does improve the results like you
> said. Increasing the parameter also shortens the delay:
>
> With interval=1ms:
> * CONFIG_SYS_CLOCK_TICKS_PER_SEC=1000
> Count 1000, delta = 2000
> Count 2000, delta = 2000
> Count 3000, delta = 2000
> …
>
> * CONFIG_SYS_CLOCK_TICKS_PER_SEC=2000
> Count 1000, delta = 1500
> Count 2000, delta = 1500
> Count 3000, delta = 1500
> …
>
> * CONFIG_SYS_CLOCK_TICKS_PER_SEC=10000
> Count 1000, delta = 1100
> Count 2000, delta = 1100
> Count 3000, delta = 1100
> …
>
> * CONFIG_SYS_CLOCK_TICKS_PER_SEC=100000
> Count 1000, delta = 1010
> Count 2000, delta = 1010
> Count 3000, delta = 1010
> main-loop: WARNING: I/O thread spun for 1000 iterations

You probably should not use tick rates that are that high, or you'll
spend all time in the timer interrupt handler (unless you also enable
tickless idle). :)

> So, although increasing it improves the delay, there is a limit. And
> for the TICKS_PER_SEC as high as 10000, there is still 100ms delay
> over 1000 counts (10%). I think that in practice a mechanism to
> compensate the delay to make it a more precise. Is there any better
> way?

For your case, that is what I was saying above: if you set the tick rate
to 1000, and you ask for a delay of 1ms, this means at least 1ms, so the
system will wait for 2 ticks (the partial current one + the next one),
so it will wait for around 2ms. That is with the system clock timer,
which has a finite granularity.

If you want more precision, I would look if your board has a second
timer that your application could take ownership of so that you could
program it to fire periodically every 2ms.

Cheers,
Ben


[RFC]DMA API Update

Liu, Baohong
 

Hi everyone,

I made minor update, the following is the final format.

Data Structure Definitions
-------

/**
* @brief DMA block configuration structure.
*
* source_address is block starting address at source
* source_gather_interval is the address adjustment at gather boundary
* dest_address is block starting address at destination
* dest_scatter_interval is the address adjustment at scatter boundary
* dest_scatter_count is the continuous transfer count between scatter boundaries
* source_gather_count is the continuous transfer count between gather boundaries
* block_size is the number of bytes to be transferred for this block.
* config is a bit field with the following parts:
* source_gather_en [ 0 ] --0-disable, 1-enable
* dest_scatter_en [ 1 ] --0-disable, 1-enable
* source_addr_adj [ 2 : 3 ] --00-increment, 01-decrement, 10-no change
* dest_addr_adj [ 4 : 5 ] --00-increment, 01-decrement, 10-no change
* source_reload_en [ 6 ] --reload source address at the end of block transfer
* 0-disable, 1-enable
* dest_reload_en [ 7 ] --reload destination address at the end of block transfer
* 0-disable, 1-enable
* fifo_mode_control [ 8 : 11 ] --How full of the fifo before transfer start. HW specific.
* flow_control_mode [ 12 ] --0-source request served upon data availability
* 1-wait until destination request happens
* RESERVED [ 13 : 15 ]
*/
struct dma_block_config {
uint32_t source_address;
uint32_t source_gather_interval;
uint32_t dest_address;
uint32_t dest_scatter_interval;
uint16_t dest_scatter_count;
uint16_t source_gather_count;
uint32_t block_size;
struct dma_block_config *next_block;
uint16_t config;
}

/**
* @brief DMA configuration structure.
*
* config is a bit field with the following parts:
* dma_slot [ 0 : 5 ] --which peripheral and direction(HW specific)
* channel_direction [ 6 : 8 ] --000-memory to memory, 001-memory to peripheral,
* 010-peripheral to memory ...
* complete_callback_en [ 9 ] --0-callback invoked at completion only
* 1-callback invoked at completion of each block
* error_callback_en [ 10 ] --0-err callback enabled
* 1-err callback disabled
* source_handshake [ 11 ] --0-HW, 1-SW
* dest_handshake [ 12 ] --0-HW, 1-SW
* channel_priority [ 13 : 16 ] --DMA channel priority
* source_chaining_en [ 17 ] --enable/disable source block chaining
* 0-disable, 1-enable
* dest_chaining_en [ 18 ] --enable/disable destination block chaining
* 0-disable, 1-enable
* RESERVED [ 19 : 31 ]
* config_size is a bit field with the following parts:
* source_data_size [ 0 : 7 ] --number of bytes
* dest_data_size [ 8 : 15 ] -- number of bytes
* source_burst_length [ 16 : 23 ] -- number of source data units
* dest_burst_length [ 24 : 31 ] -- number of destination data units
* dma_callback is the callback function pointer. If enabled, callback function will be invoked
* at transfer completion or when error happens (non zero error_code).
*/
struct dma_config {
uint32_t config;
uint32_t config_size;
uint32_t block_count;
struct dma_block_config *head_block;
void (*dma_callback)(struct device *dev, uint32_t channel, int error_code); }

API Interfaces
-------

/**
* @brief Configure individual channel for DMA transfer.
*
* @param dev Pointer to the device structure for the driver instance.
* @param channel Numeric identification of the channel to configure
* @param config Data structure containing the intended configuration for the
* selected channel
*
* @retval 0 If successful.
* @retval Negative errno code if failure.
*/
static inline int dma_config(struct device *dev, uint32_t channel,
struct dma_config *config)
{
}

/**
* @brief Enables DMA channel and starts the transfer, the channel must be
* configured beforehand.
*
* @param dev Pointer to the device structure for the driver instance.
* @param channel Numeric identification of the channel where the transfer will
* be processed
*
* @retval 0 If successful.
* @retval Negative errno code if failure.
*/
static inline int dma_start(struct device *dev, uint32_t channel)
{
}

/**
* @brief Stops the DMA transfer and disables the channel.
*
* @param dev Pointer to the device structure for the driver instance.
* @param channel Numeric identification of the channel where the transfer was
* being processed
*
* @retval 0 If successful.
* @retval Negative errno code if failure.
*/
static inline int dma_stop(struct device *dev, uint32_t channel)
{
}

All existing data structure definitions and APIs will be deprecated.

-----Original Message-----
From: Liu, Baohong [mailto:baohong.liu(a)intel.com]
Sent: Wednesday, January 11, 2017 11:50 AM
To: devel(a)lists.zephyrproject.org
Subject: [devel] [RFC]DMA API Update


Hi everyone,

I would like to propose the update for DMA API.
(https://jira.zephyrproject.org/browse/ZEP-873).

Known Problems
--------

Struct dma_channel_config consists of quite a few variables of enum types,
two callback function pointers, and one callback user data pointer.

- The enums can be collapsed into a bit field.
This will reduce the size of the data structure.

- The two callback function pointers (for normal and error cases) can be
combined.
A parameter of error code can be used to differentiate the two cases. So,
the
current callback parameter of user data pointer will be replaced by two new
parameters. One for error code and the other one for channel id.

- Callback data pointer can be removed.
Currently, this field holds user data. It can be moved to driver data structure.
The callback function can dig out the information from dev pointer and
channel id passed to it.

Proposed Solution
--------

-- The following are the enums we have now.

handshake_interface /* which peripheral and direction*/
hankshake_polarity /* high or low*/
channel_direction /* memory to memory, memory to peripheral ... */
Source_transfer_width /* source data size */
Destination_transfer_width /* destination data size */
Source_burst_length /* source burst length */
Destination_burst_length /* destination burst length */

All these will be collapsed into a bit field. Some of them will have new names.

Besides the above, three new items will be added.
source_handshake /* HW or SW */
dest_handshake /* HW or SW */
channel_priority /* DMA channel priority */

-- For the callback function, there will be three parameters. They are device
pointer,
channel_id, and error code. As said above, the error callback will be
removed.

-- The callback_data pointer will be removed.

Final API Format
--------

/**
* @brief DMA configuration structure.
*
* config is a bit field with the following parts:
* dma_slot [ 0 : 5 ] --which peripheral and
direction(HW specific)
* hankshake_polarity [ 6 ] --high or low
* channel_direction [ 7 : 9 ] --0-memory to memory, 1-
memory to peripheral,
* 2-peripheral to memory
* source_data_size [ 10 : 12 ] --source data size(8,16,32,64,128
and 256 bits)
* dest_data_size [ 13 : 15 ] --destination data
size(8,16,32,64,128 and 256 bits)
* source_burst_length [ 16 : 18 ] --number of source data
unit(1,4,8,16,32,64,128 and 256)
* dest_burst_length [ 19 : 21 ] -- number of dest data
unit(1,4,8,16,32,64,128 and 256)
* source_handshake [ 22 ] --HW or SW
* dest_handshake [ 23 ] --HW or SW
* channel_priority [ 24 : 27 ] --DMA channel priority
* RESERVED [ 28 : 31 ]
* dma_callback is the callback function pointer
*/
struct dma_channel_config {
uint32_t config;
void (*dma_callback)(struct device *dev, uint32_t channel, int
error_code); }

The remaining parts will stay the same.
No change to the structure dma_transfer_config.
No change to the API function prototypes:
dma_channel_config(...)
dma_transfer_config(...)
dma_transfer_start(...)
dma_transfer_stop(...)

(Note: for xx_data_size and xx_burst_length in the above bit field, the value
will only serve as an index. For example, for source_data_size, bit field values
of 0, 1, 2, 3, 4 and 5 will correspond to sizes of 8,16,32,64,128 and 256 bits.)

Suggestions and comments are welcome.


RFC: API for "direct" interrupts

Boie, Andrew P
 

This is a new API for connecting interrupts that bypasses a lot of the common code, for those interrupts which need the lowest possible latency. I have been working on this with Carles, Chuck, Jon, Ben, and a few others. Details on usage and caveats in the patch itself.

Review appreciated: https://gerrit.zephyrproject.org/r/#/c/10183/

Andrew


Re: [RFC]DMA API Update

Liu, Baohong
 

Hi Piotr,

From: Piotr Mieńkowski [mailto:piotr.mienkowski(a)gmail.com]
Sent: Tuesday, January 24, 2017 5:25 AM
Subject: Re: [devel] [RFC]DMA API Update
[...]
"Instead, the callback would provide the pointer of struct dma_channel_config which triggered it. Then, up to the user to relevantly design his own data structure to be able to use CONTAINER_OF() with that pointer."

So we would need to pass a pointer to dma_config.
For the callback function to get the dma config info, channel id and device pointer are good enough.
A dma userdata pointer is not needed.

[...]
I'm not saying that we need to go to the old dma_api_channel_config/dma_api_transfer_config split. We may try to think about something else, e.g. have dma_start take something like the old dma_transfer_config struct as a parameter.
We need to take care of both single block and block chaining. What's your proposal?

[...]
Is one driver accessing other driver via a private and not public API violating some Zephyr design guideline?
If a driver (e.g. SPI or I2C driver) needs to use DMA, it should be using the DMA APIs
but not through any private API.


Re: samples/net/zoap_server - blockwise transfers?

Vinicius Costa Gomes
 

Hi Wojtek,

"Bober, Wojciech" <Wojciech.Bober(a)nordicsemi.no> writes:

Hi,

I'm playing around with zoap_server on nrf52_pca10040 but I can't get the blockwise transfers to work.
There are still some bugs in the implementation, I am working on solving
them, I just noticed it when I was running a CoAP test suite
(californium) against zoap-server. Seems that my previous tests were
incomplete.

When I do GET to /large I get "[zoap-server] [ERR] udp_receive: No handler for such request (-22)" in the log. The large_get handler fails at zoap_update_from_block() function. It doesn't matter if the block2 option is present in the request or not.

I also have issue with PUT to /large-update. The behaviour is inconsistent: sometimes I get the same error as above other times I get a reply to the request but I've also seen ACK Continue with Block2 (I think it should be Block1).

Any ideas what might be wrong?
In short, there was a stupid bug in parsing of integer options (this was
already merged into the net branch), but I am still working on it, I can
add you as reviewer as I propose the changes, if you are interested.


Kind regards,
Wojtek

Cheers,
--
Vinicius


Re: uint32_t typedef differences causes issues

Benjamin Walsh <benjamin.walsh@...>
 

On Tue, Jan 24, 2017 at 10:57:21AM -0500, Anas Nashif wrote:
On Fri, Jan 20, 2017 at 7:09 AM, Szymon Janc <ext.szymon.janc(a)tieto.com>
wrote:

Hi,

On Fri, Jan 20, 2017 at 12:21 PM, Anas Nashif <nashif(a)gmail.com> wrote:



On Fri, Jan 20, 2017 at 5:26 AM, Marcus Shawcroft <
marcus.shawcroft(a)gmail.com> wrote:

On 20 January 2017 at 04:06, Kumar Gala <kumar.gala(a)linaro.org> wrote:

As Anas said, I don’t think we can expect 3rd party software to
utilize PRIu32. The fact that newlib and minimal libc different in the way
the typedef (u)int32_t seems like a pointless difference for us to maintain
and have to deal with a lot of pain if one switches between them.

This is not a choice between alternatives. There are two separate
decisions here:

1) Do we align minimal C with newlib in order to have consistent
breakage in /ext irrespective of the users choice between newlib and
minimal lib.

2) Do we write portable conforming code in our own tree outside of
/ext using the standards defined PRI macros.


We can do both, they are not alternatives:
- Number 2 is valuable because writing portable code leaves our
options open in the future.
- Number 1 is valuable because it will ensure consistent breakage under
/ext.

Ironically, that said, not doing 1) helps with 2) because it flushes
out broken code.

But either way, whether or not we do 1) I strongly advocate that for
our own code we adopt 2).

That sounds reasonable to me. Change minimal libc to align with newlib
and apply 2, the question is if we want to enforce usage of PRI macros.

A bit off topic, but could someone shed some light on why Zephyr has
support for two libc implementations?
ie Why not just always use newlib ?
The reason why we have minimal libc... it did the job for a basic kernel
implementation and mostly was used only for testing the kernel internals.
It is also a control we have (had), making sure the kernel does not rely on
libc functions and is self-contained. There is lots of history behind that,
probably Ben can add to this :-)
That's basically it.

IMHO, I think that this reasoning was bogus anyway, and only meant we
had (probably worse) re-implementation of some libc routines, with
different names, or not. :-/

Over the last 2 years I have seen developers implement clones of libc
functions to overcome the lack of support of those functions in the minimal
libc. We have been adding libc function on individual basis, sometimes
pulling those functions from different sources creating a frankenstein libc
implementation that will be difficult to maintain going forward.

Given that the zephyr project now is more than just a kernel and that any
application based on Zephyr will most likely want to use newlib anyways, I
do not think there is a reason why we should continue using minimal libc as
the default, we need however to keep an eye on usage of libc functions
inside the kernel and monitor the footprint (ram and rom) if we follow this
approach.
+1.


Re: How to overcome timer delay

Benjamin Walsh <benjamin.walsh@...>
 

I’m developing an app which requires fast sampling rate (~500 times
per sec) via the ADC on the Arduino 101. It was alright using
nano_timer_init/start/test APIs up version 1.5. However, after
upgrading to version 1.6, noticeable time delay has been observed. To
remove possible effects from other drivers, I’ve used the following
code to test the time delay and got the below results.

It seems that the amount of delay is inversely proportional to the
interval. For interval = 1000 ms, the delay is just 10 ms. But for
interval as high as 10 ms, the delay becomes 1000 ms, making it
impossible to use for high sampling rate app. Is there any Kconfig
needs to be set or any way to minimize such delay?
When we changed the new API to take ms instead of kernel ticks for
timeouts, we also decided the timeouts mean "wait for at least this
time" instead of "wait for at most this time".

The system is still tick-based though. So we convert ms to ticks
internally.

If you want to wait "at most" an amount of time, you have to ask for
one tick less. So if you know your tick rate is 100Hz, and you want to
wait at most 20ms, you have to ask for 10ms (that would give you two
ticks).

Now, you say your sampling rate is 500Hz: however, the default tick rate
is 100Hz. You have to change CONFIG_SYS_CLOCK_TICKS_PER_SEC to 500.
However (again), since with a tick freq of 500Hz, if you wait for 2ms
you'll wait for "at least" 2ms, you might wait for 4ms. So what you
probably want is a CONFIG_SYS_CLOCK_TICKS_PER_SEC of 1000, and wait for
1ms, which will make you wait at most for 2ms.

I'm starting to wonder if we should have macros for this in the API,
e.g. AT_MOST()/AT_LEAST(), where you could do:

k_timer_start(&my_timer, AT_MOST(INTERVAL), 0);

This is all because the kernel is still tick-based. We would like to
move to a tickless kernel, where these would not be an issue anymore.

=====

#include <zephyr.h>
#include <misc/printk.h>

#define INTERVAL 1

static int count;
static int t;

void timer_handler(struct k_timer *a_timer)
{
count += INTERVAL;
if (count % 1000 == 0) {
printk("Count %d, delta = %d\n", count,
k_uptime_get_32() - t);
t = k_uptime_get_32();
}
}

void main(void)
{
struct k_timer my_timer;

printk("Hello World! %s\n", CONFIG_ARCH);
k_timer_init(&my_timer, timer_handler, NULL);
t = k_uptime_get_32();
while (1) {
k_timer_start(&my_timer, INTERVAL, K_FOREVER);
^^^^^^^^^
You cannot use K_FOREVER in this API: if you do not want periodic
repetition, you have to use 0.

I'm surprised this did not blow up. Actually, if you ran with
CONFIG_ASSERT=y, you would have hit the one at the top of
_add_timeout():

__ASSERT(timeout_in_ticks > 0, "");


k_timer_status_sync(&my_timer);
}
}
====

I got the same following outputs for both x86 qemu and Arduino 101 (x86):

* INTERVAL = 1000 (one second)
Count 1000, delta = 1010
Count 2000, delta = 1010
Count 3000, delta = 1010


* INTERVAL = 100 (one hundred millisecs)
Count 1000, delta = 1100
Count 2000, delta = 1100
Count 3000, delta = 1100


* INTERVAL = 10 (ten millisecs)
Count 1000, delta = 2000
Count 2000, delta = 2000
Count 3000, delta = 2000


* INTERVAL = 1 (one millisec)
Count 1000, delta = 20000
Count 2000, delta = 20000
Count 3000, delta = 20000
You're getting these numbers because your tick rate is probably 100.
With 1000 you would probably get:

* INTERVAL = 1000 (one second)
Count 1000, delta = 1001
Count 2000, delta = 1001
Count 3000, delta = 1001


* INTERVAL = 100 (one hundred millisecs)
Count 1000, delta = 1010
Count 2000, delta = 1010
Count 3000, delta = 1010


* INTERVAL = 10 (ten millisecs)
Count 1000, delta = 1100
Count 2000, delta = 1100
Count 3000, delta = 1100


* INTERVAL = 1 (one millisec)
Count 1000, delta = 2000
Count 2000, delta = 2000
Count 3000, delta = 2000
Thank you for your reply and advices. Setting
CONFIG_SYS_CLOCK_TICKS_PER_SEC=1000 does improve the results like you
said. Increasing the parameter also shortens the delay:

With interval=1ms:
* CONFIG_SYS_CLOCK_TICKS_PER_SEC=1000
Count 1000, delta = 2000
Count 2000, delta = 2000
Count 3000, delta = 2000


* CONFIG_SYS_CLOCK_TICKS_PER_SEC=2000
Count 1000, delta = 1500
Count 2000, delta = 1500
Count 3000, delta = 1500


* CONFIG_SYS_CLOCK_TICKS_PER_SEC=10000
Count 1000, delta = 1100
Count 2000, delta = 1100
Count 3000, delta = 1100


* CONFIG_SYS_CLOCK_TICKS_PER_SEC=100000
Count 1000, delta = 1010
Count 2000, delta = 1010
Count 3000, delta = 1010
main-loop: WARNING: I/O thread spun for 1000 iterations
You probably should not use tick rates that are that high, or you'll
spend all time in the timer interrupt handler (unless you also enable
tickless idle). :)

So, although increasing it improves the delay, there is a limit. And
for the TICKS_PER_SEC as high as 10000, there is still 100ms delay
over 1000 counts (10%). I think that in practice a mechanism to
compensate the delay to make it a more precise. Is there any better
way?
For your case, that is what I was saying above: if you set the tick rate
to 1000, and you ask for a delay of 1ms, this means at least 1ms, so the
system will wait for 2 ticks (the partial current one + the next one),
so it will wait for around 2ms. That is with the system clock timer,
which has a finite granularity.

If you want more precision, I would look if your board has a second
timer that your application could take ownership of so that you could
program it to fire periodically every 2ms.

Cheers,
Ben


Re: uint32_t typedef differences causes issues

Anas Nashif
 

On Fri, Jan 20, 2017 at 7:09 AM, Szymon Janc <ext.szymon.janc(a)tieto.com>
wrote:

Hi,

On Fri, Jan 20, 2017 at 12:21 PM, Anas Nashif <nashif(a)gmail.com> wrote:



On Fri, Jan 20, 2017 at 5:26 AM, Marcus Shawcroft <
marcus.shawcroft(a)gmail.com> wrote:

On 20 January 2017 at 04:06, Kumar Gala <kumar.gala(a)linaro.org> wrote:

As Anas said, I don’t think we can expect 3rd party software to
utilize PRIu32. The fact that newlib and minimal libc different in the way
the typedef (u)int32_t seems like a pointless difference for us to maintain
and have to deal with a lot of pain if one switches between them.

This is not a choice between alternatives. There are two separate
decisions here:

1) Do we align minimal C with newlib in order to have consistent
breakage in /ext irrespective of the users choice between newlib and
minimal lib.

2) Do we write portable conforming code in our own tree outside of
/ext using the standards defined PRI macros.


We can do both, they are not alternatives:
- Number 2 is valuable because writing portable code leaves our
options open in the future.
- Number 1 is valuable because it will ensure consistent breakage under
/ext.

Ironically, that said, not doing 1) helps with 2) because it flushes
out broken code.

But either way, whether or not we do 1) I strongly advocate that for
our own code we adopt 2).

That sounds reasonable to me. Change minimal libc to align with newlib
and apply 2, the question is if we want to enforce usage of PRI macros.

A bit off topic, but could someone shed some light on why Zephyr has
support for two libc implementations?
ie Why not just always use newlib ?
The reason why we have minimal libc... it did the job for a basic kernel
implementation and mostly was used only for testing the kernel internals.
It is also a control we have (had), making sure the kernel does not rely on
libc functions and is self-contained. There is lots of history behind that,
probably Ben can add to this :-)

Over the last 2 years I have seen developers implement clones of libc
functions to overcome the lack of support of those functions in the minimal
libc. We have been adding libc function on individual basis, sometimes
pulling those functions from different sources creating a frankenstein libc
implementation that will be difficult to maintain going forward.

Given that the zephyr project now is more than just a kernel and that any
application based on Zephyr will most likely want to use newlib anyways, I
do not think there is a reason why we should continue using minimal libc as
the default, we need however to keep an eye on usage of libc functions
inside the kernel and monitor the footprint (ram and rom) if we follow this
approach.

Anas




--
BR
Szymon Janc


Daily Gerrit Digest

donotreply@...
 

NEW within last 24 hours:
- https://gerrit.zephyrproject.org/r/10427 : Bluetooth: add storage flag for secure connection pairing LTK
- https://gerrit.zephyrproject.org/r/10426 : Bluetooth: HFP HF: Enable extended AG Error Result Code
- https://gerrit.zephyrproject.org/r/10409 : soc: arm: mps2: Add configuration for CMSDK Driver
- https://gerrit.zephyrproject.org/r/10424 : boards: nucleo_l476rg: enable support of LL Cube clock control driver
- https://gerrit.zephyrproject.org/r/10420 : soc: stm32l4xx: support of Cube LL Clock driver
- https://gerrit.zephyrproject.org/r/10416 : i2c: stm32: change deprecated constant
- https://gerrit.zephyrproject.org/r/10419 : flash: update stm32 flash_f3x to support LL clock control driver
- https://gerrit.zephyrproject.org/r/10423 : board: stm32373c_eval: enable support of LL Cube clock control driver
- https://gerrit.zephyrproject.org/r/10414 : pinmux: update stm32 pinmux to support LL clock control driver
- https://gerrit.zephyrproject.org/r/10418 : pwm: update stm32 pwm to support LL clock control driver
- https://gerrit.zephyrproject.org/r/10422 : board: nucleo_f334r8: enable support of LL Cube clock control driver
- https://gerrit.zephyrproject.org/r/10417 : i2c: update stm32 i2c_lx to support LL clock control driver
- https://gerrit.zephyrproject.org/r/10421 : soc: stm32f3xx: support of Cube LL Clock driver
- https://gerrit.zephyrproject.org/r/10413 : gpio: update stm32 gpio to support LL clock control driver
- https://gerrit.zephyrproject.org/r/10415 : uart: update stm32 uart to support LL clock control driver
- https://gerrit.zephyrproject.org/r/10370 : Bluetooth: Controller: Fix build error with newlib
- https://gerrit.zephyrproject.org/r/10412 : clock control:stm32: provide STM32Cube LL based driver
- https://gerrit.zephyrproject.org/r/10411 : doc: Update mps2_an385 documentation
- https://gerrit.zephyrproject.org/r/10410 : boards: arm: mps2_an385: Enable CMSDK Drivers
- https://gerrit.zephyrproject.org/r/10403 : gpio/stm32: Move from the OPEN_DRAIN interface to the DRIVE_STRENGTH interface
- https://gerrit.zephyrproject.org/r/10404 : gpio: Merge the OPEN_DRAIN interface with the DRIVE_STRENGTH interface.
- https://gerrit.zephyrproject.org/r/10405 : net: tcp: Only return -ETIMEDOUT if timeout>0 in connect
- https://gerrit.zephyrproject.org/r/10394 : samples: net: irc_bot: handle messages across multiple fragments
- https://gerrit.zephyrproject.org/r/10398 : samples: net: irc_bot: remove NET_TESTING config in Makefile
- https://gerrit.zephyrproject.org/r/10396 : samples: net: irc_bot: add FRDM K64F project .conf
- https://gerrit.zephyrproject.org/r/10395 : samples: net: irc_bot: add Linaro copyright
- https://gerrit.zephyrproject.org/r/10393 : samples: net: irc_bot: create semi-unique IRC user names
- https://gerrit.zephyrproject.org/r/10402 : doc: net: Fix networking documentation
- https://gerrit.zephyrproject.org/r/10392 : samples: net: irc_bot: !buf in on_context_recv() is disconnected
- https://gerrit.zephyrproject.org/r/10391 : samples: net: irc_bot: dont hardcode NET_SYS_LOG_LEVEL
- https://gerrit.zephyrproject.org/r/10390 : samples: net: irc_bot: use irc parameter's connection
- https://gerrit.zephyrproject.org/r/10389 : samples: net: irc_bot: fix null pointer deref
- https://gerrit.zephyrproject.org/r/10388 : samples: net: irc_bot: expand some char buffers
- https://gerrit.zephyrproject.org/r/10387 : samples: net: irc_bot: simplify connect path
- https://gerrit.zephyrproject.org/r/10386 : samples: net: irc_bot: make some functions more accessible
- https://gerrit.zephyrproject.org/r/10385 : samples: net: irc_bot: use #defines for server and port
- https://gerrit.zephyrproject.org/r/10384 : samples: net: irc_bot: make panic() more accessible
- https://gerrit.zephyrproject.org/r/10383 : samples: net: irc_bot: remove sockaddr globals
- https://gerrit.zephyrproject.org/r/10382 : samples: net: irc_bot: add helper function in_addr_set()
- https://gerrit.zephyrproject.org/r/10381 : samples: net: irc_bot: remove unneeded typecasts and extra var
- https://gerrit.zephyrproject.org/r/10380 : samples: net: irc_bot: release net_context reference upon error
- https://gerrit.zephyrproject.org/r/10379 : samples: net: irc_bot: establish privmsg callback typedef
- https://gerrit.zephyrproject.org/r/10378 : samples: net: irc_bot: run sample process as a thread
- https://gerrit.zephyrproject.org/r/10377 : samples: net: irc_bot: fix SYS_LOG_NET_LEVEL in prj_qemu_x86.conf
- https://gerrit.zephyrproject.org/r/10375 : samples/coaps_client CoAP over DTLS client example app using mbedTLS
- https://gerrit.zephyrproject.org/r/10401 : Bluetooth: shell: Use API to get record handle
- https://gerrit.zephyrproject.org/r/10400 : Bluetooth: SDP: Add API to get Record handle
- https://gerrit.zephyrproject.org/r/10365 : frdm_kw41z: Add frdm_kw41z board
- https://gerrit.zephyrproject.org/r/10397 : samples: net: Add IRC bot example
- https://gerrit.zephyrproject.org/r/10366 : MAINTAINERS: Add frdm_kw41z board
- https://gerrit.zephyrproject.org/r/10364 : kw41z: Add kw41z SoC
- https://gerrit.zephyrproject.org/r/10363 : k64: Rename security_frdm_k64f section
- https://gerrit.zephyrproject.org/r/10362 : serial: Introduce new mcux lpuart shim driver
- https://gerrit.zephyrproject.org/r/10360 : mcux: Import mcux for kw41z
- https://gerrit.zephyrproject.org/r/10361 : flash: Update mcux shim to new mcux version

UPDATED within last 24 hours:
- https://gerrit.zephyrproject.org/r/8759 : samples/drivers: Add Counters example
- https://gerrit.zephyrproject.org/r/10286 : Xtensa port: Added support in arch/cpu.h for Xtensa cores.
- https://gerrit.zephyrproject.org/r/5504 : dma: Introduce STM32F4x DMA driver
- https://gerrit.zephyrproject.org/r/10310 : tests: kernel: test_mpool_concept: increase STACK_SIZE to 1024 for riscv32
- https://gerrit.zephyrproject.org/r/10311 : tests: kernel: threads_customdata: increase STACK_SIZE to 512 for riscv32
- https://gerrit.zephyrproject.org/r/9663 : Bluetooth: AVDTP: Add AVDTP Receive Function
- https://gerrit.zephyrproject.org/r/9460 : Bluetooth: AVDTP: Add AVDTP Discover Function Definition
- https://gerrit.zephyrproject.org/r/9975 : net: tcp: Make the connect callback on success, not transmission
- https://gerrit.zephyrproject.org/r/10313 : doc: nios2 altera max 10 board documentation
- https://gerrit.zephyrproject.org/r/10312 : docs: add Arduino 101 board documentation
- https://gerrit.zephyrproject.org/r/10346 : boards/bbc_microbit: Enable and configure default I2C_NRF if I2C is enabled.
- https://gerrit.zephyrproject.org/r/10345 : i2c/nrf5: Implement NRF5 I2C driver.
- https://gerrit.zephyrproject.org/r/9230 : gpio/nrf5: Support drive strength configuration.
- https://gerrit.zephyrproject.org/r/9229 : gpio: Support drive strength configuration.
- https://gerrit.zephyrproject.org/r/10344 : i2c: Sort Makefile in alphabetical order.
- https://gerrit.zephyrproject.org/r/10320 : Xtensa port: Added Xtensa specific C files.
- https://gerrit.zephyrproject.org/r/10319 : Xtensa port: Added Xtensa specific assembly files.
- https://gerrit.zephyrproject.org/r/10249 : samples/coaps_server CoAP over DTLS server example app using mbedTLS
- https://gerrit.zephyrproject.org/r/9711 : Bluetooth: SDP: Get ProtocolDescriptorList attribute internals
- https://gerrit.zephyrproject.org/r/9714 : Bluetooth: shell: Add getting ProfileDescriptorList attribute
- https://gerrit.zephyrproject.org/r/9715 : Bluetooth: SDP: Add API to get SupportedFeature attribute
- https://gerrit.zephyrproject.org/r/9712 : Bluetooth: shell: Add SDP client support
- https://gerrit.zephyrproject.org/r/9713 : Bluetooth: SDP: Add API to get ProfileDescriptorList attribute
- https://gerrit.zephyrproject.org/r/9717 : Bluetooth: shell: Add support to retrieve A2SRC record
- https://gerrit.zephyrproject.org/r/9716 : Bluetooth: shell: Use SupportedFeature attribute API
- https://gerrit.zephyrproject.org/r/9976 : net: tcp: Issue connection callback on RST
- https://gerrit.zephyrproject.org/r/10176 : Add support for STM32Cube HAL_PCD USB driver
- https://gerrit.zephyrproject.org/r/10175 : cdc_acm - Use endpoint 2 instead of endpoint 4 for IN BULK endpoint
- https://gerrit.zephyrproject.org/r/10304 : Bluetooth: Move Bluetooth docs to rst
- https://gerrit.zephyrproject.org/r/10183 : irq: introduce 'direct' interrupt API definition
- https://gerrit.zephyrproject.org/r/3311 : include/crypto: Crypto abstraction header
- https://gerrit.zephyrproject.org/r/10291 : drivers: Add Atmel SAM Timer Counter (TC) driver
- https://gerrit.zephyrproject.org/r/9977 : samples: net: "Mini HTTP" example & validator for TCP layer
- https://gerrit.zephyrproject.org/r/10318 : Xtensa port: Added support for Xtensa architecture in zephyr include files.
- https://gerrit.zephyrproject.org/r/10322 : Xtensa port: Added Xtensa specific include files.
- https://gerrit.zephyrproject.org/r/10288 : Xtensa port: Added fields offset support for kernel and thread structures.
- https://gerrit.zephyrproject.org/r/10287 : Xtensa port: Added support for Xtensa cores in toolchain/gcc.h.
- https://gerrit.zephyrproject.org/r/9883 : i2c: Adds a functions set that supports 16 bit addressing.
- https://gerrit.zephyrproject.org/r/10323 : Xtensa port: Added linker script for several Xtensa cores.
- https://gerrit.zephyrproject.org/r/10321 : Xtensa port: Added Kbuild file for Xtensa arch.
- https://gerrit.zephyrproject.org/r/10307 : stm32f4 - add configuration option to set flash latency
- https://gerrit.zephyrproject.org/r/10133 : Windows Build: ussing a precompiled kbuild on windows
- https://gerrit.zephyrproject.org/r/10295 : MAINTAINERS: add xtensa arch

MERGED within last 24 hours:
- https://gerrit.zephyrproject.org/r/10425 : tests: newlib: disable bluetooth for now
- https://gerrit.zephyrproject.org/r/10407 : net: bt: Fix warning when compiling without debug
- https://gerrit.zephyrproject.org/r/10406 : net: bt: Fix not checking channel state
- https://gerrit.zephyrproject.org/r/10399 : Bluetooth: Doc: RFCOMM PICS file
- https://gerrit.zephyrproject.org/r/10373 : Merge arm branch into master
- https://gerrit.zephyrproject.org/r/10374 : samples: power_mgmt: Convert README to RST format
- https://gerrit.zephyrproject.org/r/10350 : tests: arm_irq_vector_table: Use CMSIS NVIC APIs directly
- https://gerrit.zephyrproject.org/r/10349 : arm: cmsis: Convert relocate_vector_table to use CMSIS
- https://gerrit.zephyrproject.org/r/10359 : commit-message: skip length checks for http/https URLs
- https://gerrit.zephyrproject.org/r/9982 : drivers: spi: enable gpio driver automatically when needed
- https://gerrit.zephyrproject.org/r/9638 : Bluetooth: HFP HF: Handle +CIEV reponse
- https://gerrit.zephyrproject.org/r/10276 : sensor: fxos8700: expand trigger requirement to include pulse config
- https://gerrit.zephyrproject.org/r/10300 : filter-known-issues: add warning support, clean up, add more help
- https://gerrit.zephyrproject.org/r/10317 : tests: kernel: mbox_api: fix uninit variable and unchecked value
- https://gerrit.zephyrproject.org/r/10316 : tests: kernel: mpool: fix assert side effect
- https://gerrit.zephyrproject.org/r/10315 : tests: kernel: mpool: fix unchecked return value
- https://gerrit.zephyrproject.org/r/9356 : quark_se: PM: Add multicore support
- https://gerrit.zephyrproject.org/r/10334 : tests: kernel: msgq: fix unused value
- https://gerrit.zephyrproject.org/r/10327 : kernel: remove K_STATIC
- https://gerrit.zephyrproject.org/r/10332 : build: add _ASMLANGUAGE to all asm files
- https://gerrit.zephyrproject.org/r/10325 : kernel: move volatile from k_thread.prio to k_thread.sched_locked
- https://gerrit.zephyrproject.org/r/10326 : kernel: include kernel.h in kernel_structs.h in asm files
- https://gerrit.zephyrproject.org/r/10328 : kernel: rename thread states symbols
- https://gerrit.zephyrproject.org/r/10329 : kernel: move K_ESSENTIAL from thread_state to execution_flags
- https://gerrit.zephyrproject.org/r/10330 : kernel/x86: move INT_ACTIVE/EXC_ACTIVE to thread_state
- https://gerrit.zephyrproject.org/r/10331 : kernel/arch: streamline thread user options
- https://gerrit.zephyrproject.org/r/9373 : Bluetooth: AVDTP: Add AVDTP Discover API Prototype
- https://gerrit.zephyrproject.org/r/9809 : samples: ieee802154: add MCR20A
- https://gerrit.zephyrproject.org/r/9805 : ext: mcux: add MCR20Overwrites.h
- https://gerrit.zephyrproject.org/r/9806 : boards: frdm_k64f: add pinmux settings for MCR20A
- https://gerrit.zephyrproject.org/r/9807 : drivers: ieee802154: add MCR20A driver
- https://gerrit.zephyrproject.org/r/10281 : samples: net: add configs for MCR20A
- https://gerrit.zephyrproject.org/r/10347 : net: samples: Fix config option
- https://gerrit.zephyrproject.org/r/10338 : net: Use lighter printk() instead of printf()
- https://gerrit.zephyrproject.org/r/10341 : net: tests: Use lighter printk() instead of printf()
- https://gerrit.zephyrproject.org/r/10340 : net: samples: Use lighter printk() instead of printf()
- https://gerrit.zephyrproject.org/r/10339 : net: Fix 80 line character limit
- https://gerrit.zephyrproject.org/r/10337 : net: tests: Fix invalid config option in 6lo tests
- https://gerrit.zephyrproject.org/r/10106 : samples: net: Add DHCPv4 sample application README file
- https://gerrit.zephyrproject.org/r/9874 : arm: cmsis: Convert enable_floating_point to use CMSIS
- https://gerrit.zephyrproject.org/r/9923 : arm: cmsis: Convert systick to CMSIS
- https://gerrit.zephyrproject.org/r/9924 : arm: cmsis: Convert DO_REBOOT to use CMSIS
- https://gerrit.zephyrproject.org/r/9970 : arm: cmsis: Introduce CMSIS layer
- https://gerrit.zephyrproject.org/r/9922 : arm: cmsis: Remove unused code from scb/scs layers
- https://gerrit.zephyrproject.org/r/9971 : timer: nrf_rtc: Use CMSIS NVIC APIs directly
- https://gerrit.zephyrproject.org/r/9972 : clock_control: nrf5_power: Use CMSIS NVIC APIs directly
- https://gerrit.zephyrproject.org/r/9973 : Bluetooth: Controller: Use CMSIS NVIC APIs directly
- https://gerrit.zephyrproject.org/r/10244 : doc: update MAINTAINERS for .rst files
- https://gerrit.zephyrproject.org/r/10277 : arm: soc: Add SoC series for ARM's Cortex-M Prototyping System (MPS2)
- https://gerrit.zephyrproject.org/r/10278 : boards: arm: Add board for MPS2 with AN383
- https://gerrit.zephyrproject.org/r/10309 : boards: arduino 101: set user LED values correctly
- https://gerrit.zephyrproject.org/r/9984 : spi: Add shared default configs
- https://gerrit.zephyrproject.org/r/9986 : k64: Change the default spi driver to the mcux shim
- https://gerrit.zephyrproject.org/r/9985 : spi: Introduce new mcux shim driver
- https://gerrit.zephyrproject.org/r/9987 : tests: Update spi driver test for mcux
- https://gerrit.zephyrproject.org/r/9989 : spi: k64: Remove the k64 spi driver
- https://gerrit.zephyrproject.org/r/9988 : samples: net: Increase spi log level


Re: [RFC]DMA API Update

Jon Medhurst (Tixy) <tixy@...>
 

On Tue, 2017-01-24 at 02:37 +0100, Piotr Mieńkowski wrote:
[...]
* I know that this comment is coming very late but I was wondering if
we really want the device drivers to use this DMA API? Device
drivers are always written for a specific SoC
No they aren't. The same IP blocks gets reused in multiple SoCs,
sometimes from different manufactures. E.g ARM provide IP for lots of
generic devices that then gets integrated by different manufacturers
into their SoC. Other companies do too, e.g. Synopsys has DesignWare IP.
Then there's things not on the SoC itself that the board manufacturer
adds. They need drivers and I'm sure people would prefer not to have to
cut'n'paste an existing driver and hack it to fit the DMA driver for the
particular SoC there using.

and their code doesn't
need to be portable between architectures,
What about drivers that talk to other devices over things like SPI or
I2C busses? They are completely SoC and architecture agnostic.
There's also people integrating things like 16550 compatible UARTs in
devices of different architectures, which could have a common driver.

[...]
Is one driver accessing other driver via a
private and not public API violating some Zephyr design guideline?
It's breaking common sense on how you design an OS that's pretending to
be in any way generic.

--
Tixy


samples/net/zoap_server - blockwise transfers?

Bober, Wojciech <Wojciech.Bober@...>
 

Hi,

I'm playing around with zoap_server on nrf52_pca10040 but I can't get the blockwise transfers to work.

When I do GET to /large I get "[zoap-server] [ERR] udp_receive: No handler for such request (-22)" in the log. The large_get handler fails at zoap_update_from_block() function. It doesn't matter if the block2 option is present in the request or not.

I also have issue with PUT to /large-update. The behaviour is inconsistent: sometimes I get the same error as above other times I get a reply to the request but I've also seen ACK Continue with Block2 (I think it should be Block1).

Any ideas what might be wrong?

Kind regards,
Wojtek


Re: "/samples/net/coap_server" example is not working on "nrf52_pca10040" board

Appala Raju <raju.ga@...>
 

Hi Carles,

I can understand that and that would be fine for me. I hope this is also applicable in all other OS like Contiki & RIOT and even in Nordic SDK.

Thanks,
Raju


Re: [RFC]DMA API Update

Piotr Mieńkowski <piotr.mienkowski at gmail.com...>
 

Hi Baohong,

Thanks for preparing the new DMA API and am very sorry for not replying
earlier. I was busy with other things. I do have some comments to the
proposal.

* the callback data pointer was removed, the reasoning was as follows:

"Currently, this field holds user data. It can be moved to driver
data structure. The callback function can dig out the information
from dev pointer and channel id passed to it."

I believe that's not correct. The callback function will have no way
to dig out the required information from the DMA dev pointer. The
original idea as described in the Jira issue by Tomasz Bursztyka was
different.

"Instead, the callback would provide the pointer of struct
dma_channel_config which triggered it. Then, up to the user to
relevantly design his own data structure to be able to use
CONTAINER_OF() with that pointer."

So we would need to pass a pointer to dma_config. I'm however not
sure if that's really the right way to go. Using CONTAINER_OF() is
an extremely clever idea to save a byte of RAM but also one which
will keep many users scratching their heads. We are talking here
about public API, one which should be straightforward to use and
accessible also to less experienced users. Maybe the original
concept was better?

* Often, when working with DMA, we need to configure DMA channel once
and then perform several transfers where the only difference to the
last setup is the location of the source or the destination buffer.
Yet again I think the original concept was a little bit better as it
split channel configuration in two parts exactly along this lines.
That way we didn't have to go through a somewhat lengthy process of
fully reconfiguring the DMA channel when we wanted to change source
address only. One could argue that it's what linked lists are for
but in practice we do not always know up front what will be the
location of the next buffer so setting up a linked list transfer is
not always an option. I'm not saying that we need to go to the old
dma_api_channel_config/dma_api_transfer_config split. We may try to
think about something else, e.g. have dma_start take something like
the old dma_transfer_config struct as a parameter.

* I know that this comment is coming very late but I was wondering if
we really want the device drivers to use this DMA API? Device
drivers are always written for a specific SoC and their code doesn't
need to be portable between architectures, i.e. Quark DMA driver
will never be used with Atmel DAC driver. When writing Atmel or
Quark DAC driver I would rather access private API of Atmel/Quark
DMA module and not this one. Private APIs correlate well with the
documentation, put no limits on features the hardware module can
offer and add only a thin layer of code. This API has to be
universal and that's good but there is a price to pay. All the
various bit field parameters which we defined will have to be
translated to the device native format. Cutting a bit field and
moving it elsewhere is actually not a very expensive operation but
we have a lot of parameters to process and not all of them will be
straightforward to translate. So this API adds a relatively thick
layer of code. Maybe it would be better if it was targeted
exclusively at user space programs? The only use case involving a
user space program and DMA driver that I can think of is a memory to
memory transfer. Any memory to peripheral or peripheral to memory
transfer will be handled by a respective device driver. Or am I
wrong on this one? Is one driver accessing other driver via a
private and not public API violating some Zephyr design guideline?

Regards,
Piotr

On 01/23/2017 10:53 PM, Liu, Baohong wrote:
Hi everyone,

Based on the feedbacks, the following is the final format.

Data Structure Definitions
-------

/**
* @brief DMA block configuration structure.
*
* source_address is block starting address at source
* source_gather_interval is the address adjustment at gather boundary
* dest_address is block starting address at destination
* dest_scatter_interval is the address adjustment at scatter boundary
* dest_scatter_count is the continuous transfer count between scatter boundaries
* source_gather_count is the continuous transfer count between gather boundaries
* block_size is the number of bytes to be transferred for this block.
* config is a bit field with the following parts:
* source_gather_en [ 0 ] --0-disable, 1-enable
* dest_scatter_en [ 1 ] --0-disable, 1-enable
* source_addr_adj [ 2 : 3 ] --00-increment, 01-decrement, 10-no change
* dest_addr_adj [ 4 : 5 ] --00-increment, 01-decrement, 10-no change
* source_reload_en [ 6 ] --reload source address at the end of block transfer
* 0-disable, 1-enable
* dest_reload_en [ 7 ] --reload destination address at the end of block transfer
* 0-disable, 1-enable
* fifo_mode_control [ 8 : 11 ] --How full of the fifo before transfer start. HW specific.
* flow_control_mode [ 12 ] --0-source request served upon data availability
* 1-wait until destination request happens
* RESERVED [ 13 : 15 ]
*/
struct dma_block_config {
uint32_t source_address;
uint32_t source_gather_interval;
uint32_t dest_address;
uint32_t dest_scatter_interval;
uint16_t dest_scatter_count;
uint16_t source_gather_count;
uint32_t block_size;
struct dma_block_config *next_block;
uint16_t config;
}

/**
* @brief DMA configuration structure.
*
* config is a bit field with the following parts:
* dma_slot [ 0 : 5 ] --which peripheral and direction(HW specific)
* channel_direction [ 6 : 8 ] --000-memory to memory, 001-memory to peripheral,
* 010-peripheral to memory ...
* complete_int_en [ 9 ] --completion interrupt enable
* 0-disable, 1-enable
* block_int_en [ 10 ] --block completion interrupt enable
* 0-disable, 1-enable
* source_int_en [ 11 ] --source completion interrupt enable
* 0-disable, 1-enable
* dest_int_en [ 12 ] --destination completion interrupt enable
* 0-disable, 1-enable
* error_int_en [ 13 ] --error interrupt enable
* 0-disable, 1-enable
* source_handshake [ 14 ] --0-HW, 1-SW
* dest_handshake [ 15 ] --0-HW, 1-SW
* channel_priority [ 16 : 19 ] --DMA channel priority
* source_chaining_en [ 20 ] --enable/disable source block chaining
* 0-disable, 1-enable
* dest_chaining_en [ 21 ] --enable/disable destination block chaining
* 0-disable, 1-enable
* RESERVED [ 22 : 31 ]
* config_size is a bit field with the following parts:
* source_data_size [ 0 : 7 ] --number of bytes
* dest_data_size [ 8 : 15 ] -- number of bytes
* source_burst_length [ 16 : 23 ] -- number of source data units
* dest_burst_length [ 24 : 31 ] -- number of destination data units
* dma_callback is the callback function pointer
*/
struct dma_config {
uint32_t config;
uint32_t config_size;
uint32_t block_count;
struct dma_block_config *head_block;
void (*dma_callback)(struct device *dev, uint32_t channel, int error_code);
}

API Interfaces
-------

/**
* @brief Configure individual channel for DMA transfer.
*
* @param dev Pointer to the device structure for the driver instance.
* @param channel Numeric identification of the channel to configure
* @param config Data structure containing the intended configuration for the
* selected channel
*
* @retval 0 If successful.
* @retval Negative errno code if failure.
*/
static inline int dma_config(struct device *dev, uint32_t channel,
struct dma_config *config)
{
}

/**
* @brief Enables DMA channel and starts the transfer, the channel must be
* configured beforehand.
*
* @param dev Pointer to the device structure for the driver instance.
* @param channel Numeric identification of the channel where the transfer will
* be processed
*
* @retval 0 If successful.
* @retval Negative errno code if failure.
*/
static inline int dma_start(struct device *dev, uint32_t channel)
{
}

/**
* @brief Stops the DMA transfer and disables the channel.
*
* @param dev Pointer to the device structure for the driver instance.
* @param channel Numeric identification of the channel where the transfer was
* being processed
*
* @retval 0 If successful.
* @retval Negative errno code if failure.
*/
static inline int dma_stop(struct device *dev, uint32_t channel)
{
}

All existing data structure definitions and APIs will be deprecated.

-----Original Message-----
From: Liu, Baohong
Sent: Tuesday, January 10, 2017 6:29 PM
To: 'Liu, Baohong' <baohong.liu(a)intel.com>
Subject: [RFC]DMA API Update

Hi everyone,

I would like to propose the update for DMA API.
(https://jira.zephyrproject.org/browse/ZEP-873).

Known Problems.
--------

Structure dma_channel_config consists of quite a few variables of enum type,
two callback pointers, and one callback data pointer.

- The enums can be collapsed into a bit field.
This will reduce the size of the data structure.

- The two callback pointers (for normal and error cases) can be combined.
One new callback parameter will be used to return error code.

- Callback data pointer will be removed.
Currently, this field actually holds user data. So, it can be moved to driver
data
structure. The callback function can dig out the information from dev
pointer and
channel id passed to the callback function.

Proposed Solution
--------

-- The following are the enums we have now.

handshake_interface /* which peripheral and direction*/
hankshake_polarity /* high or low*/
channel_direction /* memory to memory, memory to peripheral ... *.
Source_transfer_width /* source data size */
Destination_transfer_width /* destination data size */
Source_burst_length /* source burst length */
Destination_burst_length /* destination burst length */

All these will be collapsed into a bit field.

Besides the above, three new items will be added into the bit field.
source_handshake /* HW or SW */
dest_handshake /* HW or SW */
channel_priority /* DMA channel priority */

-- For the callback function, there will be three parameters. They are device
pointer, channel_id, and error code. As said above, the error callback will be
removed.

-- The callback_data pointer will be removed.

Final API Format
--------

/**
* @brief DMA configuration structure.
*
* config is a bit field with the following parts:
* handshake_interface [ 0 : 3 ] --which peripheral and
direction(HW specific)
* hankshake_polarity [ 4 ] --high or low
* channel_direction [ 5 : 7 ] --0-memory to memory, 1-
memory to peripheral,
* 2-peripheral to memory
* source_transfer_width [ 8 : 10 ] --source data size(8,16,32,64,128
and 256 bits)
* dest_transfer_width [ 11 : 13 ] --destination data
size(8,16,32,64,128 and 256 bits)
* source_burst_length [ 14 : 16 ] --source burst
length(1,4,8,16,32,64,128 and 256)
* dest_burst_length [ 17 : 19 ] -- destination burst
length(1,4,8,16,32,64,128 and 256)
* source_handshake [ 20 ] --HW or SW
* dest_handshake [ 21 ] --HW or SW
* channel_priority [ 22 : 24 ] --DMA channel priority
* RESERVED [ 25 : 31 ]
* dma_callback is the callback function pointer
*/
struct dma_channel_config {
uint32_t config;
void (*dma_callback)(struct device *dev, uint32_t channel, int
error_code); }

The remaining parts will stay the same.
No change to the structure dma_transfer_config.
No change to the API calls:
dma_channel_config(...)
dma_transfer_config(...)
dma_transfer_start(...)
dma_transfer_stop(...)

Suggestions and comments are welcome.


Re: How to overcome timer delay

Dinh, Kien T
 

Hi Benjamin,

Thank you for your reply and advices. Setting CONFIG_SYS_CLOCK_TICKS_PER_SEC=1000
does improve the results like you said. Increasing the parameter also shortens the delay:

With interval=1ms:
* CONFIG_SYS_CLOCK_TICKS_PER_SEC=1000
Count 1000, delta = 2000
Count 2000, delta = 2000
Count 3000, delta = 2000


* CONFIG_SYS_CLOCK_TICKS_PER_SEC=2000
Count 1000, delta = 1500
Count 2000, delta = 1500
Count 3000, delta = 1500


* CONFIG_SYS_CLOCK_TICKS_PER_SEC=10000
Count 1000, delta = 1100
Count 2000, delta = 1100
Count 3000, delta = 1100


* CONFIG_SYS_CLOCK_TICKS_PER_SEC=100000
Count 1000, delta = 1010
Count 2000, delta = 1010
Count 3000, delta = 1010
main-loop: WARNING: I/O thread spun for 1000 iterations

So, although increasing it improves the delay, there is a limit. And for the TICKS_PER_SEC as high
as 10000, there is still 100ms delay over 1000 counts (10%). I think that in practice a mechanism
to compensate the delay to make it a more precise. Is there any better way?

Thanks,
Kien

PS: It would be fun blowing up the HW with some code. I used to blow up
the circuit with a capacitor soldered mistakenly in opposite way. Please let
me follow your advice not to use K_FOREVER in this case.

On 2017/01/24 1:16, "Benjamin Walsh" <benjamin.walsh(a)windriver.com> wrote:

Hi Kien,

> I’m developing an app which requires fast sampling rate (~500 times
> per sec) via the ADC on the Arduino 101. It was alright using
> nano_timer_init/start/test APIs up version 1.5. However, after
> upgrading to version 1.6, noticeable time delay has been observed. To
> remove possible effects from other drivers, I’ve used the following
> code to test the time delay and got the below results.
>
> It seems that the amount of delay is inversely proportional to the
> interval. For interval = 1000 ms, the delay is just 10 ms. But for
> interval as high as 10 ms, the delay becomes 1000 ms, making it
> impossible to use for high sampling rate app. Is there any Kconfig
> needs to be set or any way to minimize such delay?

When we changed the new API to take ms instead of kernel ticks for
timeouts, we also decided the timeouts mean "wait for at least this
time" instead of "wait for at most this time".

The system is still tick-based though. So we convert ms to ticks
internally.

If you want to wait "at most" an amount of time, you have to ask for
one tick less. So if you know your tick rate is 100Hz, and you want to
wait at most 20ms, you have to ask for 10ms (that would give you two
ticks).

Now, you say your sampling rate is 500Hz: however, the default tick rate
is 100Hz. You have to change CONFIG_SYS_CLOCK_TICKS_PER_SEC to 500.
However (again), since with a tick freq of 500Hz, if you wait for 2ms
you'll wait for "at least" 2ms, you might wait for 4ms. So what you
probably want is a CONFIG_SYS_CLOCK_TICKS_PER_SEC of 1000, and wait for
1ms, which will make you wait at most for 2ms.

I'm starting to wonder if we should have macros for this in the API,
e.g. AT_MOST()/AT_LEAST(), where you could do:

k_timer_start(&my_timer, AT_MOST(INTERVAL), 0);

This is all because the kernel is still tick-based. We would like to
move to a tickless kernel, where these would not be an issue anymore.

> =====
>
> #include <zephyr.h>
> #include <misc/printk.h>
>
> #define INTERVAL 1
>
> static int count;
> static int t;
>
> void timer_handler(struct k_timer *a_timer)
> {
> count += INTERVAL;
> if (count % 1000 == 0) {
> printk("Count %d, delta = %d\n", count,
> k_uptime_get_32() - t);
> t = k_uptime_get_32();
> }
> }
>
> void main(void)
> {
> struct k_timer my_timer;
>
> printk("Hello World! %s\n", CONFIG_ARCH);
> k_timer_init(&my_timer, timer_handler, NULL);
> t = k_uptime_get_32();
> while (1) {
> k_timer_start(&my_timer, INTERVAL, K_FOREVER);
^^^^^^^^^
You cannot use K_FOREVER in this API: if you do not want periodic
repetition, you have to use 0.

I'm surprised this did not blow up. Actually, if you ran with
CONFIG_ASSERT=y, you would have hit the one at the top of
_add_timeout():

__ASSERT(timeout_in_ticks > 0, "");


> k_timer_status_sync(&my_timer);
> }
> }
> ====
>
> I got the same following outputs for both x86 qemu and Arduino 101 (x86):
>
> * INTERVAL = 1000 (one second)
> Count 1000, delta = 1010
> Count 2000, delta = 1010
> Count 3000, delta = 1010
> …
>
> * INTERVAL = 100 (one hundred millisecs)
> Count 1000, delta = 1100
> Count 2000, delta = 1100
> Count 3000, delta = 1100
> …
>
> * INTERVAL = 10 (ten millisecs)
> Count 1000, delta = 2000
> Count 2000, delta = 2000
> Count 3000, delta = 2000
> …
>
> * INTERVAL = 1 (one millisec)
> Count 1000, delta = 20000
> Count 2000, delta = 20000
> Count 3000, delta = 20000

You're getting these numbers because your tick rate is probably 100.
With 1000 you would probably get:

* INTERVAL = 1000 (one second)
Count 1000, delta = 1001
Count 2000, delta = 1001
Count 3000, delta = 1001


* INTERVAL = 100 (one hundred millisecs)
Count 1000, delta = 1010
Count 2000, delta = 1010
Count 3000, delta = 1010


* INTERVAL = 10 (ten millisecs)
Count 1000, delta = 1100
Count 2000, delta = 1100
Count 3000, delta = 1100


* INTERVAL = 1 (one millisec)
Count 1000, delta = 2000
Count 2000, delta = 2000
Count 3000, delta = 2000

Cheers,
Ben

> …
>
> Thanks,
> Kien

--
Benjamin Walsh, SMTS
WR VxWorks Virtualization Profile
www.windriver.com
Zephyr kernel maintainer
www.zephyrproject.org


[RFC]DMA API Update

Liu, Baohong
 

Hi everyone,

Based on the feedbacks, the following is the final format.

Data Structure Definitions
-------

/**
* @brief DMA block configuration structure.
*
* source_address is block starting address at source
* source_gather_interval is the address adjustment at gather boundary
* dest_address is block starting address at destination
* dest_scatter_interval is the address adjustment at scatter boundary
* dest_scatter_count is the continuous transfer count between scatter boundaries
* source_gather_count is the continuous transfer count between gather boundaries
* block_size is the number of bytes to be transferred for this block.
* config is a bit field with the following parts:
* source_gather_en [ 0 ] --0-disable, 1-enable
* dest_scatter_en [ 1 ] --0-disable, 1-enable
* source_addr_adj [ 2 : 3 ] --00-increment, 01-decrement, 10-no change
* dest_addr_adj [ 4 : 5 ] --00-increment, 01-decrement, 10-no change
* source_reload_en [ 6 ] --reload source address at the end of block transfer
* 0-disable, 1-enable
* dest_reload_en [ 7 ] --reload destination address at the end of block transfer
* 0-disable, 1-enable
* fifo_mode_control [ 8 : 11 ] --How full of the fifo before transfer start. HW specific.
* flow_control_mode [ 12 ] --0-source request served upon data availability
* 1-wait until destination request happens
* RESERVED [ 13 : 15 ]
*/
struct dma_block_config {
uint32_t source_address;
uint32_t source_gather_interval;
uint32_t dest_address;
uint32_t dest_scatter_interval;
uint16_t dest_scatter_count;
uint16_t source_gather_count;
uint32_t block_size;
struct dma_block_config *next_block;
uint16_t config;
}

/**
* @brief DMA configuration structure.
*
* config is a bit field with the following parts:
* dma_slot [ 0 : 5 ] --which peripheral and direction(HW specific)
* channel_direction [ 6 : 8 ] --000-memory to memory, 001-memory to peripheral,
* 010-peripheral to memory ...
* complete_int_en [ 9 ] --completion interrupt enable
* 0-disable, 1-enable
* block_int_en [ 10 ] --block completion interrupt enable
* 0-disable, 1-enable
* source_int_en [ 11 ] --source completion interrupt enable
* 0-disable, 1-enable
* dest_int_en [ 12 ] --destination completion interrupt enable
* 0-disable, 1-enable
* error_int_en [ 13 ] --error interrupt enable
* 0-disable, 1-enable
* source_handshake [ 14 ] --0-HW, 1-SW
* dest_handshake [ 15 ] --0-HW, 1-SW
* channel_priority [ 16 : 19 ] --DMA channel priority
* source_chaining_en [ 20 ] --enable/disable source block chaining
* 0-disable, 1-enable
* dest_chaining_en [ 21 ] --enable/disable destination block chaining
* 0-disable, 1-enable
* RESERVED [ 22 : 31 ]
* config_size is a bit field with the following parts:
* source_data_size [ 0 : 7 ] --number of bytes
* dest_data_size [ 8 : 15 ] -- number of bytes
* source_burst_length [ 16 : 23 ] -- number of source data units
* dest_burst_length [ 24 : 31 ] -- number of destination data units
* dma_callback is the callback function pointer
*/
struct dma_config {
uint32_t config;
uint32_t config_size;
uint32_t block_count;
struct dma_block_config *head_block;
void (*dma_callback)(struct device *dev, uint32_t channel, int error_code);
}

API Interfaces
-------

/**
* @brief Configure individual channel for DMA transfer.
*
* @param dev Pointer to the device structure for the driver instance.
* @param channel Numeric identification of the channel to configure
* @param config Data structure containing the intended configuration for the
* selected channel
*
* @retval 0 If successful.
* @retval Negative errno code if failure.
*/
static inline int dma_config(struct device *dev, uint32_t channel,
struct dma_config *config)
{
}

/**
* @brief Enables DMA channel and starts the transfer, the channel must be
* configured beforehand.
*
* @param dev Pointer to the device structure for the driver instance.
* @param channel Numeric identification of the channel where the transfer will
* be processed
*
* @retval 0 If successful.
* @retval Negative errno code if failure.
*/
static inline int dma_start(struct device *dev, uint32_t channel)
{
}

/**
* @brief Stops the DMA transfer and disables the channel.
*
* @param dev Pointer to the device structure for the driver instance.
* @param channel Numeric identification of the channel where the transfer was
* being processed
*
* @retval 0 If successful.
* @retval Negative errno code if failure.
*/
static inline int dma_stop(struct device *dev, uint32_t channel)
{
}

All existing data structure definitions and APIs will be deprecated.

-----Original Message-----
From: Liu, Baohong
Sent: Tuesday, January 10, 2017 6:29 PM
To: 'Liu, Baohong' <baohong.liu(a)intel.com>
Subject: [RFC]DMA API Update

Hi everyone,

I would like to propose the update for DMA API.
(https://jira.zephyrproject.org/browse/ZEP-873).

Known Problems.
--------

Structure dma_channel_config consists of quite a few variables of enum type,
two callback pointers, and one callback data pointer.

- The enums can be collapsed into a bit field.
This will reduce the size of the data structure.

- The two callback pointers (for normal and error cases) can be combined.
One new callback parameter will be used to return error code.

- Callback data pointer will be removed.
Currently, this field actually holds user data. So, it can be moved to driver
data
structure. The callback function can dig out the information from dev
pointer and
channel id passed to the callback function.

Proposed Solution
--------

-- The following are the enums we have now.

handshake_interface /* which peripheral and direction*/
hankshake_polarity /* high or low*/
channel_direction /* memory to memory, memory to peripheral ... *.
Source_transfer_width /* source data size */
Destination_transfer_width /* destination data size */
Source_burst_length /* source burst length */
Destination_burst_length /* destination burst length */

All these will be collapsed into a bit field.

Besides the above, three new items will be added into the bit field.
source_handshake /* HW or SW */
dest_handshake /* HW or SW */
channel_priority /* DMA channel priority */

-- For the callback function, there will be three parameters. They are device
pointer, channel_id, and error code. As said above, the error callback will be
removed.

-- The callback_data pointer will be removed.

Final API Format
--------

/**
* @brief DMA configuration structure.
*
* config is a bit field with the following parts:
* handshake_interface [ 0 : 3 ] --which peripheral and
direction(HW specific)
* hankshake_polarity [ 4 ] --high or low
* channel_direction [ 5 : 7 ] --0-memory to memory, 1-
memory to peripheral,
* 2-peripheral to memory
* source_transfer_width [ 8 : 10 ] --source data size(8,16,32,64,128
and 256 bits)
* dest_transfer_width [ 11 : 13 ] --destination data
size(8,16,32,64,128 and 256 bits)
* source_burst_length [ 14 : 16 ] --source burst
length(1,4,8,16,32,64,128 and 256)
* dest_burst_length [ 17 : 19 ] -- destination burst
length(1,4,8,16,32,64,128 and 256)
* source_handshake [ 20 ] --HW or SW
* dest_handshake [ 21 ] --HW or SW
* channel_priority [ 22 : 24 ] --DMA channel priority
* RESERVED [ 25 : 31 ]
* dma_callback is the callback function pointer
*/
struct dma_channel_config {
uint32_t config;
void (*dma_callback)(struct device *dev, uint32_t channel, int
error_code); }

The remaining parts will stay the same.
No change to the structure dma_transfer_config.
No change to the API calls:
dma_channel_config(...)
dma_transfer_config(...)
dma_transfer_start(...)
dma_transfer_stop(...)

Suggestions and comments are welcome.


Re: "/samples/net/coap_server" example is not working on "nrf52_pca10040" board

Carles Cufi
 

Hi Raju,

-----Original Message-----
From: Appala Raju [mailto:raju.ga(a)gmail.com]
Sent: Monday, January 23, 2017 18:39
To: devel(a)lists.zephyrproject.org
Subject: [devel] Re: Re: Re: Re: Re: Re: Re: Re: Re: Re:
"/samples/net/coap_server" example is not working on "nrf52_pca10040"
board

As per this post "https://devzone.nordicsemi.com/question/6566/how-to-
get-6-byte-mac-address-at-nrf51822/" we can have unique Mac address but
it seems this is not mapped in this OS properly. Can we implement the
same.
I'll try to send a patch to read the FICR address in the nRF5x. But even then remember that you will end up with a *random static* address, since the Nordic nRF5x ICs do not come with a public address by default. That said, it will be the same random static address every time you boot.

Regards,

Carles


Re: "/samples/net/coap_server" example is not working on "nrf52_pca10040" board

Johan Hedberg
 

Hi,

On Mon, Jan 23, 2017, Appala Raju wrote:
As per this post
"https://devzone.nordicsemi.com/question/6566/how-to-get-6-byte-mac-address-at-nrf51822/"
we can have unique Mac address but it seems this is not mapped in this
OS properly. Can we implement the same.
That's indeed a good idea. If someone wants to pick up the task, I think
following would probably be the appropriate location:

--- a/subsys/bluetooth/host/hci_core.c
+++ b/subsys/bluetooth/host/hci_core.c
@@ -3285,6 +3285,10 @@ static int set_static_addr(void)
}
}

+ if (IS_ENABLED(CONFIG_SOC_FAMILY_NRF5)) {
+ /* Read address from nRF5-specific storage */
+ }
+
BT_DBG("Generating new static random address");

err = bt_addr_le_create_static(&bt_dev.id_addr);

Johan

5701 - 5720 of 8054