Date   

Upcoming Event: Zephyr Project: APIs - Tue, 08/27/2019 9:00am-10:00am, Please RSVP #cal-reminder

devel@lists.zephyrproject.org Calendar <devel@...>
 

Reminder: Zephyr Project: APIs

When: Tuesday, 27 August 2019, 9:00am to 10:00am, (GMT-07:00) America/Los Angeles

Where:https://zoom.us/j/177647878

An RSVP is requested. Click here to RSVP

Organizer: devel@...

Description: Join from PC, Mac, Linux, iOS or Android: https://zoom.us/j/177647878

Or iPhone one-tap :
    US: +16465588656,,177647878# or +16699006833,,177647878# 
Or Telephone:
    Dial(for higher quality, dial a number based on your current location): 
        US: +1 646 558 8656 or +1 669 900 6833 or +1 855 880 1246 (Toll Free) or +1 877 369 0926 (Toll Free)
    Meeting ID: 177 647 878
    International numbers available: https://zoom.us/zoomconference?m=ioAR9GK1OE5LkN1ojt-heTCl7yPcJrhY


 Live meeting minutes: https://docs.google.com/document/d/1lv-8B5QE2m4FjBcvfqAXFIgQfW5oz6306zJ7GIZIWCk/edit?usp=sharing


Re: [RFC] Enabling %lld, %llu (long long) support for newlib's stdio

Carles Cufi
 

Hi Paul,

And perhaps the problem space considered thoroughly first. As an
example, not everyone knows that there're two "nano" Newlib's. The
latest contender is https://keithp.com/newlib-nano/ . It would be easy
to discount it as something from someone who's not even aware that
"nano" is already taken, but that's @keithp of X.org, etc, fame. So,
either he indeed doesn't known that Newlib already has "nano" mode, or
he thinks that the old nano is not nano enough.
This one seems to have been renamed "picolibc":
https://salsa.debian.org/electronics-team/toolchains/picolibc

Carles


Re: [RFC] Enabling %lld, %llu (long long) support for newlib's stdio

Paul Sokolovsky
 

Hello,

On Mon, 26 Aug 2019 08:29:14 -0500
Kumar Gala <kumar.gala@linaro.org> wrote:

On Aug 25, 2019, at 2:18 AM, Paul Sokolovsky
<paul.sokolovsky@linaro.org> wrote:

Hello,

We have a patch to enable format specifiers %lld, %llu (i.e. dealing
with "long long" C types) for Newlib libc in the next Zephyr SDK
release: https://github.com/zephyrproject-rtos/sdk-ng/pull/101
[]


There are some other options, but they require more development
effort.

1. Add support for newlib nano for long long.
2. Add support to crosstool-ng to build multiple newlib variants.
And build 2 variants similar to what the ARM embedded toolchains do
today (one nano, one full).
Right, those are useful options to keep in mind and explore. But given
that they require more development effort, IMHO they should be treated
as separate tasks/projects with their own stakeholders.

And perhaps the problem space considered thoroughly first. As an
example, not everyone knows that there're two "nano" Newlib's. The
latest contender is https://keithp.com/newlib-nano/ . It would be easy
to discount it as something from someone who's not even aware that
"nano" is already taken, but that's @keithp of X.org, etc, fame. So,
either he indeed doesn't known that Newlib already has "nano" mode,
or he thinks that the old nano is not nano enough.

The result is a library that offers broad API support, including
things like complex numbers, high quality math functions that support
both float and double values, a complete string library with wide
char support but with a stdio API that takes only a 20 bytes of RAM.
And that's only the beginning. I personally have an impression that I
see a new libc popping up in github like every month. Hardly they would
be useful for our usecase, but I guess someone wanting to invest time
in developing and maintaining a particular solution would want to check
them out first nonetheless.

And all that is a nice rabbit hole to follow, but from project
management/"enterprise-grade" software engineering perspective, seems
to be quite distinct from an issue at hand of enabling a missing
feature in already selected component, especially that the feature
starts to look like security-related
(https://github.com/zephyrproject-rtos/sdk-ng/pull/101#issuecomment-525300825)


- k

--
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog


OpenThread development guide

Benjamin Lindqvist
 

Hi,

I've verified basic OT functionality using the echo_client/server samples with the openthread overlays. That's nice, but it's not obvious to me how I proceed after this. A few things that had me confused:

- how do I configure my Zephyr device as a sleepy end device?
- can I setup my west.yml to clone openthread + dependencies as a module to prevent cmake from doing it at build every time?
- can I modify the network credentials at run-time? Or in other words, does Zephyr support anything but hardcoded OT commissioning?
- can I build NCP firmware for a border router using Zephyr?

etc. Right now I get the impression that the openthread integration is in a sort of proof-of-concept stage. Is this the case? If not, it would be nice with some more documentation, perhaps even a sample app...


API meeting: agenda

Carles Cufi
 

Hi all,

This week we will look at:

Agenda:

- Sensor API: Update on progress
- GPIO: Update on https://github.com/zephyrproject-rtos/zephyr/pull/16648 and possibly merging it

Additional items in the "Triage" column in the GitHub project may be discussed if time permits.
If you want an item included in the meeting, please add it to the GitHub project.

https://github.com/zephyrproject-rtos/zephyr/wiki/Zephyr-Committee-and-Working-Group-Meetings#zephyr-api-discussion
https://github.com/zephyrproject-rtos/zephyr/projects/18
https://docs.google.com/document/d/1lv-8B5QE2m4FjBcvfqAXFIgQfW5oz6306zJ7GIZIWCk/edit

Regards,

Carles


Re: 回复:[Zephyr-devel] Is The tick handler "z_clock_announce" in SMP mode dupulicate caculated?

Andy Ross
 

Indeed, that looks like a bug in the driver when SMP and !TICKLESS are set.  Can you file an issue on github?


Andy


On 8/24/2019 3:23 AM, "曹子龙 wrote:
Hi andrew:
 
   i find the place you said laste emai, it seems only xtensa and x84 arch supports the SMP mode, so take xtensa for exmaple.

it seems the mechanism you said in the laste email only effect when "CONFIG_TICKLESS_KERNEL" enabled.
if the macro CONFIG_TICKLESS_KERNEL not enabled,  the z_clock_announce still pased the 1 tick for each core, so the cur_tick would be doubled, where am i wrong?

 thanks for your kindly help.

static void ccompare_isr(void *arg)
{
    ARG_UNUSED(arg);

    k_spinlock_key_t key = k_spin_lock(&lock);
    u32_t curr = ccount();
    u32_t dticks = (curr - last_count) / CYC_PER_TICK;

    last_count += dticks * CYC_PER_TICK;

    if (!IS_ENABLED(CONFIG_TICKLESS_KERNEL) ||
        IS_ENABLED(CONFIG_QEMU_TICKLESS_WORKAROUND)) {
        u32_t next = last_count + CYC_PER_TICK;

        if ((s32_t)(next - curr) < MIN_DELAY) {
            next += CYC_PER_TICK;
        }
        set_ccompare(next);
    }

    k_spin_unlock(&lock, key);
    z_clock_announce(IS_ENABLED(CONFIG_TICKLESS_KERNEL) ? dticks : 1);
}


曹子龙

珠海全志科技股份有限公司      BU1-PSW

地址:广东省珠海市高新区唐家湾镇科技2路9号

TEL:13824125580

Email:caozilong@...

网址: http://www.allwinnertech.com

 


------------------------------------------------------------------
发件人:Andy Ross <andrew.j.ross@...>
发送时间:2019年8月23日(星期五) 23:35
收件人:曹子龙 <caozilong@...>; devel <devel@...>
主 题:Re: [Zephyr-devel] Is The tick handler "z_clock_announce" in SMP mode dupulicate caculated?

This is the responsibility of the timer driver.  The ticks announced needs to be globally correct.  The existing drivers do this by locking a "last count" state variable and updating it, so they see the updates made by the other cores.


Andy


On 8/23/2019 8:14 AM, "曹子龙 wrote:
Hi  friends:
    
  a puzzle in the timer tick interrupt handler in SMP mode.  look at below,  the SMP mult cores share the same "cur_tick" object to remeber the current time, each cpu would increment it when the tick hander  excutes on each CPU.
so, could this would accelerate the timer compare with the realworld?  for example, if 4cores  exist, the cur_tick would 4 times incmrent than the read world, i cant fingure out where am a wrong, so, could you figure me out?  thanks for your kinldy supply. 

void z_clock_announce(s32_t ticks)
{
#ifdef CONFIG_TIMESLICING
 z_time_slice(ticks);
#endif

 k_spinlock_key_t key = k_spin_lock(&timeout_lock);

 announce_remaining = ticks;

 while (first() != NULL && first()->dticks <= announce_remaining) {
  struct _timeout *t = first();
  int dt = t->dticks;

  curr_tick += dt;
  announce_remaining -= dt;
  t->dticks = 0;
  remove_timeout(t);

  k_spin_unlock(&timeout_lock, key);
  t->fn(t);
  key = k_spin_lock(&timeout_lock);
 }

 if (first() != NULL) {
  first()->dticks -= announce_remaining;
 }

 curr_tick += announce_remaining;
 announce_remaining = 0;

 z_clock_set_timeout(next_timeout(), false);

 k_spin_unlock(&timeout_lock, key);
}




曹子龙

珠海全志科技股份有限公司      BU1-PSW

地址:广东省珠海市高新区唐家湾镇科技2路9号

TEL:13824125580

Email:caozilong@...

网址: http://www.allwinnertech.com

 




Re: [RFC] Enabling %lld, %llu (long long) support for newlib's stdio

Kumar Gala
 

On Aug 25, 2019, at 2:18 AM, Paul Sokolovsky <paul.sokolovsky@linaro.org> wrote:

Hello,

We have a patch to enable format specifiers %lld, %llu (i.e. dealing
with "long long" C types) for Newlib libc in the next Zephyr SDK
release: https://github.com/zephyrproject-rtos/sdk-ng/pull/101

Unfortunately, enabling it also requires to disable
CT_LIBC_NEWLIB_NANO_FORMATTED_IO which accounts for noticeable code
saving in Newlib formatting implementation. The net result of disabling
nano formatting and enabling long long support is +13K/+100% code size
increase for a simple printf() call:
https://github.com/zephyrproject-rtos/sdk-ng/pull/101#issuecomment-524606258

I personally vote up this change because:

1. The reason we have the Minimal libc in Zephyr, even as the default,
is to exactly because of things like that: minimal libc is what we
carefully size-control and optimize (and so should continue do that in
the future, and it should stay the default).

2. On the other hand, there should be a way to port existing software
(a lot of software!) to Zephyr without being swamped with patching it.
And Zephyr lacks many things in that regard so far, so porting existing
code becomes a firefighting with array of issues. If we can cross some
of those issues in 3rd-party components now, and concentrate on things
which belong to Zephyr, we should do that.


But in general, I find it pretty surprising that I advocate changes
which increase the codesize of a simple app twice. Maybe, there're
people with good arguments on the other side?
There are some other options, but they require more development effort.

1. Add support for newlib nano for long long.
2. Add support to crosstool-ng to build multiple newlib variants. And build 2 variants similar to what the ARM embedded toolchains do today (one nano, one full).

- k


MESH DEMO

Muhammad Muh <muhammad.muh83@...>
 

Dear Sir/Madam,

Hope you will be fine and in best of health. I am a beginner and done with the Zephyr BLE Beacon example with NRF52840 Dongle. It is requested if i can be helped to run the Bluetooth Mesh Demo Sample example step by step in Zephyr i will be grateful.


Best Regards
Muhammad


From: Muhammad Muh <muhammad.muh83@...>
Sent: Saturday, August 3, 2019 3:24 PM
To: Thea Aldrich <aldrich.thea@...>
Subject: Re: WAtched your Video
 

Dear Respected Madam,


Thank you very much for your kind email. It is my honor to talk and to learn from such an extraordinary expert like you.


It is requested that I have purchased the board nrf52840 Dongle for doing the examples as given in your Zephyrs Boards Documentation.


I have succesfully checked the Dongle with the help of NRFCONNECT Application


I am doing my best to learn the Zephyr but facing many issues to run the Blinky and Mesh Example with NRF52840 Dongle. I will be grateful if you can help me in doing these examples so that i can have a start on Zephyr.


A) Talking of BLINKY Example.


I am using two different BLINKY example one is done with the help of CMAKE and the other is with WEST respectively. The web links of example are as follows:


https://docs.zephyrproject.org/1.13.0/boards/arm/nrf52840_pca10059/doc/nrf52840_pca10059.html


https://docs.zephyrproject.org/latest/samples/basic/blink_led/README.html


Problems Using CMAKE:

Command 1: cmake -GNinja -DBOARD=nrf52840_pca10059 ..

In my view going well kindly see as follows:


Command 1: muh@muhammad:~/zephyrproject/zephyr/samples/basic/blink_led/build$ cd /home/muh/zephyrproject/zephyr/samples/basic/blinky/

muh@muhammad:~/zephyrproject/zephyr/samples/basic/blinky$ mkdir build && cd build

muh@muhammad:~/zephyrproject/zephyr/samples/basic/blinky/build$ cmake -GNinja -DBOARD=nrf52840_pca10059 ..

Zephyr version: 1.14.0

-- Found PythonInterp: /usr/bin/python3 (found suitable version "3.6.8", minimum required is "3.4")

-- Selected BOARD nrf52840_pca10059

-- Found west: /home/muh/.local/bin/west (found suitable version "0.5.7", minimum required is "0.5.6")

-- Loading /home/muh/zephyrproject/zephyr/boards/arm/nrf52840_pca10059/nrf52840_pca10059.dts as base

-- Overlaying /home/muh/zephyrproject/zephyr/dts/common/common.dts

nrf52840_pca10059.dts.pre.tmp:312.23-315.5: Warning (simple_bus_reg): /soc/virtualcom: missing or empty reg/ranges property

Parsing Kconfig tree in /home/muh/zephyrproject/zephyr/Kconfig

Loading /home/muh/zephyrproject/zephyr/boards/arm/nrf52840_pca10059/nrf52840_pca10059_defconfig as base

Merging /home/muh/zephyrproject/zephyr/samples/basic/blinky/prj.conf

Configuration written to '/home/muh/zephyrproject/zephyr/samples/basic/blinky/build/zephyr/.config'


warning: UART_INTERRUPT_DRIVEN (defined at drivers/serial/Kconfig:37) was assigned the value 'y' but

got the value 'n'. You can check symbol information (including dependencies) in the 'menuconfig'

interface (see the Application Development Primer section of the manual), or in the Kconfig

reference at

http://docs.zephyrproject.org/latest/reference/kconfig/CONFIG_UART_INTERRUPT_DRIVEN.html (which is

updated regularly from the master branch). See the 'Setting configuration values' section of the

Board Porting Guide as well.


warning: the choice symbol UART_0_NRF_UARTE (defined at drivers/serial/Kconfig.nrfx:34) was selected

(set =y), but no symbol ended up as the choice selection. You can check symbol information

(including dependencies) in the 'menuconfig' interface (see the Application Development Primer

section of the manual), or in the Kconfig reference at

http://docs.zephyrproject.org/latest/reference/kconfig/CONFIG_UART_0_NRF_UARTE.html (which is

updated regularly from the master branch). See the 'Setting configuration values' section of the

Board Porting Guide as well.

-- Cache files will be written to: /home/muh/.cache/zephyr

-- The C compiler identification is GNU 8.3.0

-- The CXX compiler identification is GNU 8.3.0

-- The ASM compiler identification is GNU

-- Found assembler: /opt/zephyr-sdk/arm-zephyr-eabi/bin/arm-zephyr-eabi-gcc

-- Performing Test toolchain_is_ok

-- Performing Test toolchain_is_ok - Success

Including module: tinycbor

-- Configuring done

-- Generating done

-- Build files have been written to: /home/muh/zephyrproject/zephyr/samples/basic/blinky/build



Command 2: ninja

In my view going well as it is completing from 1 to 107. Kindly see as follows 


Command 2: muh@muhammad:~/zephyrproject/zephyr/samples/basic/blinky/build$ ninja

[1/107] Preparing syscall dependency handling


[102/107] Linking C executable zephyr/zephyr_prebuilt.elf

Memory region Used Size Region Size %age Used

FLASH: 12876 B 1020 KB 1.23%

SRAM: 3904 B 256 KB 1.49%

IDT_LIST: 56 B 2 KB 2.73%

[107/107] Linking C executable zephyr/zephyr.elf


Command 3: ninja flash

Causing error.


Command3: muh@muhammad:~/zephyrproject/zephyr/samples/basic/blinky/build$ ninja flash

[0/1] Flashing nrf52840_pca10059

Using runner: nrfjprog

Traceback (most recent call last):

File "/home/muh/.local/bin/west", line 11, in <module>

sys.exit(main())

File "/home/muh/.local/lib/python3.6/site-packages/west/_bootstrap/main.py", line 499, in main

wrap(wrap_argv)

File "/home/muh/.local/lib/python3.6/site-packages/west/_bootstrap/main.py", line 485, in wrap

west.main.main(argv)

File "/home/muh/zephyrproject/.west/west/src/west/main.py", line 580, in main

args.handler(args, unknown)

File "/home/muh/zephyrproject/.west/west/src/west/main.py", line 332, in ext_command_handler

command.run(*west_parser.parse_known_args(argv))

File "/home/muh/zephyrproject/.west/west/src/west/commands/command.py", line 90, in run

self.do_run(args, unknown)

File "/home/muh/zephyrproject/zephyr/scripts/west_commands/flash.py", line 32, in do_run

'ZEPHYR_BOARD_FLASH_RUNNER')

File "/home/muh/zephyrproject/zephyr/scripts/west_commands/run_common.py", line 228, in do_run_common

runner.run(command_name)

File "/home/muh/zephyrproject/zephyr/scripts/west_commands/runners/core.py", line 407, in run

self.do_run(command, **kwargs)

File "/home/muh/zephyrproject/zephyr/scripts/west_commands/runners/nrfjprog.py", line 92, in do_run

board_snr = self.get_board_snr_from_user()

File "/home/muh/zephyrproject/zephyr/scripts/west_commands/runners/nrfjprog.py", line 53, in get_board_snr_from_user

snrs = self.check_output(['nrfjprog', '--ids'])

File "/home/muh/zephyrproject/zephyr/scripts/west_commands/runners/core.py", line 485, in check_output

return subprocess.check_output(cmd)

File "/usr/lib/python3.6/subprocess.py", line 356, in check_output

**kwargs).stdout

File "/usr/lib/python3.6/subprocess.py", line 423, in run

with Popen(*popenargs, **kwargs) as process:

File "/usr/lib/python3.6/subprocess.py", line 729, in __init__

restore_signals, start_new_session)

File "/usr/lib/python3.6/subprocess.py", line 1364, in _execute_child

raise child_exception_type(errno_num, err_msg, err_filename)

FileNotFoundError: [Errno 2] No such file or directory: 'nrfjprog': 'nrfjprog'

FAILED: zephyr/cmake/flash/CMakeFiles/flash

cd /home/muh/zephyrproject/zephyr/samples/basic/blinky/build && /home/muh/cmake-3.13.1-Linux-x86_64/bin/cmake -E env /home/muh/.local/bin/west flash --skip-rebuild

ninja: build stopped: subcommand failed.



Problems Using West:


Command 1:

muh@muhammad:~/zephyrproject$ west build -b nrf52840_pca10059 zephyr/samples/basic/blinky

source directory: /home/muh/zephyrproject/zephyr/samples/basic/blinky

build directory: /home/muh/zephyrproject/build

BOARD: nrf52840_pca10059

Error: could not find CMAKE_PROJECT_NAME in Cache

ERROR: command exited with status 1: /home/muh/cmake-3.13.1-Linux-x86_64/bin/cmake --build /home/muh/zephyrproject/build

run as "west -v build -b nrf52840_pca10059 zephyr/samples/basic/blinky" for a stack trace


Command 2:


Tried west -v build -b nrf52840_pca10059 zephyr/samples/basic/blinky


muh@muhammad:~/zephyrproject$ west -v build -b nrf52840_pca10059 zephyr/samples/basic/blinky

ZEPHYR_BASE=/home/muh/zephyrproject/zephyr (origin: env)

args: Namespace(board='nrf52840_pca10059', build_dir=None, cmake=False, command='build', force=False, help=None, source_dir=None, target=None, verbose=1, version=False, zephyr_base=None) remainder: ['zephyr/samples/basic/blinky']

source_dir: zephyr/samples/basic/blinky cmake_opts: None

source directory: /home/muh/zephyrproject/zephyr/samples/basic/blinky

build directory: /home/muh/zephyrproject/build

BOARD: nrf52840_pca10059

not running cmake; build system is present

Error: could not find CMAKE_PROJECT_NAME in Cache

ERROR: command exited with status 1: /home/muh/cmake-3.13.1-Linux-x86_64/bin/cmake --build /home/muh/zephyrproject/build

Traceback (most recent call last):

File "/home/muh/zephyrproject/.west/west/src/west/main.py", line 580, in main

args.handler(args, unknown)

File "/home/muh/zephyrproject/.west/west/src/west/main.py", line 332, in ext_command_handler

command.run(*west_parser.parse_known_args(argv))

File "/home/muh/zephyrproject/.west/west/src/west/commands/command.py", line 90, in run

self.do_run(args, unknown)

File "/home/muh/zephyrproject/zephyr/scripts/west_commands/build.py", line 158, in do_run

cmake.run_build(self.build_dir, extra_args=extra_args)

File "/home/muh/zephyrproject/.west/west/src/west/cmake.py", line 40, in run_build

run_cmake(['--build', build_directory] + list(extra_args), quiet=quiet)

File "/home/muh/zephyrproject/.west/west/src/west/cmake.py", line 35, in run_cmake

subprocess.check_call(cmd, **kwargs)

File "/usr/lib/python3.6/subprocess.py", line 311, in check_call

raise CalledProcessError(retcode, cmd)

subprocess.CalledProcessError: Command '['/home/muh/cmake-3.13.1-Linux-x86_64/bin/cmake', '--build', '/home/muh/zephyrproject/build']' returned non-zero exit status 1.



Waiting for your kind response.


Best Regards






From: Thea Aldrich <aldrich.thea@...>
Sent: Friday, July 26, 2019 12:15:18 AM
To: Muhammad Muh <muhammad.muh83@...>
Subject: Re: WAtched your Video
 
Hi Muhammad,
No need to apologize at all! Things of that nature don't trouble me at all. :) I wanted to let you know that  I recently  changed jobs so I am no longer the paid Developer Advocate for Zephyr RTOS. I am still very much active in the community however and am very happy to see you are enjoying Zephyr. The learning curve is indeed pretty rough. If you stick with it you'll very quickly become an expert. 

I noticed your question to the mailing list was answered by Carles. Carles is a great guy and is one of the core creators of Zephyr Project. He is definitely one of the best people to stay in touch with as you learn. Always feel free to reach out to me directly if you have any questions or are unable to get a response from the community.

Best,
Thea

On Tue, Jul 23, 2019 at 7:39 PM Muhammad Muh <muhammad.muh83@...> wrote:

Dear Madam,


I saw your video on the web related to Zephyr RTOS. Sorry to address you with the 'Mr' in my last email. I did not know you before. Really happy that Developer Advocate has very nicely replied to my query. I am very thankful. I really want to be expert in Zephyr RTOS. Hope i start of well. Waiting for your kind help despite of your busy schedule.


Best Regards


[RFC] Enabling %lld, %llu (long long) support for newlib's stdio

Paul Sokolovsky
 

Hello,

We have a patch to enable format specifiers %lld, %llu (i.e. dealing
with "long long" C types) for Newlib libc in the next Zephyr SDK
release: https://github.com/zephyrproject-rtos/sdk-ng/pull/101

Unfortunately, enabling it also requires to disable
CT_LIBC_NEWLIB_NANO_FORMATTED_IO which accounts for noticeable code
saving in Newlib formatting implementation. The net result of disabling
nano formatting and enabling long long support is +13K/+100% code size
increase for a simple printf() call:
https://github.com/zephyrproject-rtos/sdk-ng/pull/101#issuecomment-524606258

I personally vote up this change because:

1. The reason we have the Minimal libc in Zephyr, even as the default,
is to exactly because of things like that: minimal libc is what we
carefully size-control and optimize (and so should continue do that in
the future, and it should stay the default).

2. On the other hand, there should be a way to port existing software
(a lot of software!) to Zephyr without being swamped with patching it.
And Zephyr lacks many things in that regard so far, so porting existing
code becomes a firefighting with array of issues. If we can cross some
of those issues in 3rd-party components now, and concentrate on things
which belong to Zephyr, we should do that.


But in general, I find it pretty surprising that I advocate changes
which increase the codesize of a simple app twice. Maybe, there're
people with good arguments on the other side?

--
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog


回复:[Zephyr-devel] Is The tick handler "z_clock_announce" in SMP mode dupulicate caculated?

"曹子龙
 

Hi andrew:
 
   i find the place you said laste emai, it seems only xtensa and x84 arch supports the SMP mode, so take xtensa for exmaple.

it seems the mechanism you said in the laste email only effect when "CONFIG_TICKLESS_KERNEL" enabled.
if the macro CONFIG_TICKLESS_KERNEL not enabled,  the z_clock_announce still pased the 1 tick for each core, so the cur_tick would be doubled, where am i wrong?

 thanks for your kindly help.

static void ccompare_isr(void *arg)
{
    ARG_UNUSED(arg);

    k_spinlock_key_t key = k_spin_lock(&lock);
    u32_t curr = ccount();
    u32_t dticks = (curr - last_count) / CYC_PER_TICK;

    last_count += dticks * CYC_PER_TICK;

    if (!IS_ENABLED(CONFIG_TICKLESS_KERNEL) ||
        IS_ENABLED(CONFIG_QEMU_TICKLESS_WORKAROUND)) {
        u32_t next = last_count + CYC_PER_TICK;

        if ((s32_t)(next - curr) < MIN_DELAY) {
            next += CYC_PER_TICK;
        }
        set_ccompare(next);
    }

    k_spin_unlock(&lock, key);
    z_clock_announce(IS_ENABLED(CONFIG_TICKLESS_KERNEL) ? dticks : 1);
}


曹子龙

珠海全志科技股份有限公司      BU1-PSW

地址:广东省珠海市高新区唐家湾镇科技2路9号

TEL:13824125580

Email:caozilong@...

网址: http://www.allwinnertech.com

 


------------------------------------------------------------------
发件人:Andy Ross <andrew.j.ross@...>
发送时间:2019年8月23日(星期五) 23:35
收件人:曹子龙 <caozilong@...>; devel <devel@...>
主 题:Re: [Zephyr-devel] Is The tick handler "z_clock_announce" in SMP mode dupulicate caculated?

This is the responsibility of the timer driver.  The ticks announced needs to be globally correct.  The existing drivers do this by locking a "last count" state variable and updating it, so they see the updates made by the other cores.


Andy


On 8/23/2019 8:14 AM, "曹子龙 wrote:
Hi  friends:
    
  a puzzle in the timer tick interrupt handler in SMP mode.  look at below,  the SMP mult cores share the same "cur_tick" object to remeber the current time, each cpu would increment it when the tick hander  excutes on each CPU.
so, could this would accelerate the timer compare with the realworld?  for example, if 4cores  exist, the cur_tick would 4 times incmrent than the read world, i cant fingure out where am a wrong, so, could you figure me out?  thanks for your kinldy supply. 

void z_clock_announce(s32_t ticks)
{
#ifdef CONFIG_TIMESLICING
 z_time_slice(ticks);
#endif

 k_spinlock_key_t key = k_spin_lock(&timeout_lock);

 announce_remaining = ticks;

 while (first() != NULL && first()->dticks <= announce_remaining) {
  struct _timeout *t = first();
  int dt = t->dticks;

  curr_tick += dt;
  announce_remaining -= dt;
  t->dticks = 0;
  remove_timeout(t);

  k_spin_unlock(&timeout_lock, key);
  t->fn(t);
  key = k_spin_lock(&timeout_lock);
 }

 if (first() != NULL) {
  first()->dticks -= announce_remaining;
 }

 curr_tick += announce_remaining;
 announce_remaining = 0;

 z_clock_set_timeout(next_timeout(), false);

 k_spin_unlock(&timeout_lock, key);
}




曹子龙

珠海全志科技股份有限公司      BU1-PSW

地址:广东省珠海市高新区唐家湾镇科技2路9号

TEL:13824125580

Email:caozilong@...

网址: http://www.allwinnertech.com

 




Re: What branch should I be using for the 1.14 LTS release?

Marc Herbert
 

It's still not clear to me what you're looking for but maybe this git command will help:

git log --decorate --no-walk --oneline $(git tag -l v1.14*) upstream/v1.14-branch

5ad3f4a6930d (tag: v1.14.1-rc2, upstream/v1.14-branch) release: bump release to 1.14.0-rc2
03a52401c682 (tag: v1.14.1-rc1) release: bump version to 1.14.1-rc1
cebe11544ebe (tag: zephyr-v1.14.0, tag: v1.14.0) release: Zephyr 1.14.0
9e81cbea7df8 (tag: v1.14.0-rc3) release: Zephyr 1.14-rc3
350f6f715632 (tag: v1.14.0-rc2) release: Zephyr 1.14-rc2
588d7b068c91 (tag: v1.14.0-rc1) release: Zephyr 1.14-rc1

On 23 Aug 2019, at 16:32, Manu R <manu@culvertengineering.com> wrote:

Thanks Anas, I should have been clearer in my question, apologies.

It looks like there is a 1.14.1 brewing, I presume that is bug fixes on the 1.14 release. When it is released, I will probably want that, but for now, the last released version is v1.14.0, is that correct?

Manu

On Fri, Aug 23, 2019 at 4:24 PM Nashif, Anas <anas.nashif@intel.com> wrote:
v1.14-branch is the branch, all others are tags on the branch.



Anas





From: <devel@lists.zephyrproject.org> on behalf of Manu R <manu@culvertengineering.com>
Date: Friday, 23 August 2019 at 18:38
To: "devel@lists.zephyrproject.org" <devel@lists.zephyrproject.org>
Subject: [Zephyr-devel] What branch should I be using for the 1.14 LTS release?



when I do a zephyr (v1.14-branch) $ git checkout v1.14<tab>
v1.14-branch v1.14.0 v1.14.0-rc1 v1.14.0-rc2 v1.14.0-rc3 v1.14.1-rc1



Thanks

Manu




Re: What branch should I be using for the 1.14 LTS release?

Manu R
 

Thanks Anas, I should have been clearer in my question, apologies.

It looks like there is a 1.14.1 brewing, I presume that is bug fixes on the 1.14 release. When it is released, I will probably want that, but for now, the last released version is v1.14.0, is that correct?

Manu 

On Fri, Aug 23, 2019 at 4:24 PM Nashif, Anas <anas.nashif@...> wrote:

v1.14-branch is the branch, all others are tags on the branch.

 

Anas

 

 

From: <devel@...> on behalf of Manu R <manu@...>
Date: Friday, 23 August 2019 at 18:38
To: "devel@..." <devel@...>
Subject: [Zephyr-devel] What branch should I be using for the 1.14 LTS release?

 

when I do a zephyr (v1.14-branch) $ git checkout  v1.14<tab>
v1.14-branch   v1.14.0        v1.14.0-rc1    v1.14.0-rc2    v1.14.0-rc3    v1.14.1-rc1

 

Thanks

Manu

 


Re: What branch should I be using for the 1.14 LTS release?

Nashif, Anas
 

v1.14-branch is the branch, all others are tags on the branch.

 

Anas

 

 

From: <devel@...> on behalf of Manu R <manu@...>
Date: Friday, 23 August 2019 at 18:38
To: "devel@..." <devel@...>
Subject: [Zephyr-devel] What branch should I be using for the 1.14 LTS release?

 

when I do a zephyr (v1.14-branch) $ git checkout  v1.14<tab>
v1.14-branch   v1.14.0        v1.14.0-rc1    v1.14.0-rc2    v1.14.0-rc3    v1.14.1-rc1

 

Thanks

Manu

 


回复:[Zephyr-devel] Is The tick handler "z_clock_announce" in SMP mode dupulicate caculated?

"曹子龙
 

I still cant understand this flow after read the code.
take cortex-m arch for exmaple, z_clock_isr, is hooked for NVIC vector table, so each cores would call this following the frequency.
so,  there must be a z_clock_announce invoked on each cpu, so the current tick would be duplicate caculated? although i know zephyr would nod be exsis such issue, but  i did not figure out
where am i wrong, from the coretex-m arch flow, i cant find where block the z_clock_announce calling from each cpu core?


    .word __pendsv
#if defined(CONFIG_SYS_CLOCK_EXISTS)
    .word z_clock_isr
#else
    .word __reserved
#endif

void z_clock_isr(void *arg)
{
    ARG_UNUSED(arg);
    u32_t dticks;

    cycle_count += last_load;
    dticks = (cycle_count - announced_cycles) / CYC_PER_TICK;
    announced_cycles += dticks * CYC_PER_TICK;

    overflow_cyc = SysTick->CTRL; /* Reset overflow flag */
    overflow_cyc = 0U;

    z_clock_announce(TICKLESS ? dticks : 1);
    z_ExcExit();
}



曹子龙

珠海全志科技股份有限公司      BU1-PSW

地址:广东省珠海市高新区唐家湾镇科技2路9号

TEL:13824125580

Email:caozilong@...

网址: http://www.allwinnertech.com

 


------------------------------------------------------------------
发件人:Andy Ross <andrew.j.ross@...>
发送时间:2019年8月23日(星期五) 23:35
收件人:曹子龙 <caozilong@...>; devel <devel@...>
主 题:Re: [Zephyr-devel] Is The tick handler "z_clock_announce" in SMP mode dupulicate caculated?

This is the responsibility of the timer driver.  The ticks announced needs to be globally correct.  The existing drivers do this by locking a "last count" state variable and updating it, so they see the updates made by the other cores.


Andy


On 8/23/2019 8:14 AM, "曹子龙 wrote:
Hi  friends:
    
  a puzzle in the timer tick interrupt handler in SMP mode.  look at below,  the SMP mult cores share the same "cur_tick" object to remeber the current time, each cpu would increment it when the tick hander  excutes on each CPU.
so, could this would accelerate the timer compare with the realworld?  for example, if 4cores  exist, the cur_tick would 4 times incmrent than the read world, i cant fingure out where am a wrong, so, could you figure me out?  thanks for your kinldy supply. 

void z_clock_announce(s32_t ticks)
{
#ifdef CONFIG_TIMESLICING
 z_time_slice(ticks);
#endif

 k_spinlock_key_t key = k_spin_lock(&timeout_lock);

 announce_remaining = ticks;

 while (first() != NULL && first()->dticks <= announce_remaining) {
  struct _timeout *t = first();
  int dt = t->dticks;

  curr_tick += dt;
  announce_remaining -= dt;
  t->dticks = 0;
  remove_timeout(t);

  k_spin_unlock(&timeout_lock, key);
  t->fn(t);
  key = k_spin_lock(&timeout_lock);
 }

 if (first() != NULL) {
  first()->dticks -= announce_remaining;
 }

 curr_tick += announce_remaining;
 announce_remaining = 0;

 z_clock_set_timeout(next_timeout(), false);

 k_spin_unlock(&timeout_lock, key);
}




曹子龙

珠海全志科技股份有限公司      BU1-PSW

地址:广东省珠海市高新区唐家湾镇科技2路9号

TEL:13824125580

Email:caozilong@...

网址: http://www.allwinnertech.com

 




What branch should I be using for the 1.14 LTS release?

Manu R
 

when I do a zephyr (v1.14-branch) $ git checkout  v1.14<tab>
v1.14-branch   v1.14.0        v1.14.0-rc1    v1.14.0-rc2    v1.14.0-rc3    v1.14.1-rc1

Thanks
Manu


回复: [Zephyr-devel] Is The tick handler "z_clock_announce" in SMP mode dupulicate caculated?

"曹子龙
 

could you show me where the logic you said locates? i still cant catches it, thank you

------------------------------------------------------------------
发件人:Andy Ross<andrew.j.ross@...>
日 期:2019年08月23日 23:32:07
收件人:曹子龙<caozilong@...>; devel<devel@...>
主 题:Re: [Zephyr-devel] Is The tick handler "z_clock_announce" in SMP mode dupulicate caculated?

This is the responsibility of the timer driver.  The ticks announced needs to be globally correct.  The existing drivers do this by locking a "last count" state variable and updating it, so they see the updates made by the other cores.


Andy


On 8/23/2019 8:14 AM, "曹子龙 wrote:
Hi  friends:
    
  a puzzle in the timer tick interrupt handler in SMP mode.  look at below,  the SMP mult cores share the same "cur_tick" object to remeber the current time, each cpu would increment it when the tick hander  excutes on each CPU.
so, could this would accelerate the timer compare with the realworld?  for example, if 4cores  exist, the cur_tick would 4 times incmrent than the read world, i cant fingure out where am a wrong, so, could you figure me out?  thanks for your kinldy supply. 

void z_clock_announce(s32_t ticks)
{
#ifdef CONFIG_TIMESLICING
 z_time_slice(ticks);
#endif

 k_spinlock_key_t key = k_spin_lock(&timeout_lock);

 announce_remaining = ticks;

 while (first() != NULL && first()->dticks <= announce_remaining) {
  struct _timeout *t = first();
  int dt = t->dticks;

  curr_tick += dt;
  announce_remaining -= dt;
  t->dticks = 0;
  remove_timeout(t);

  k_spin_unlock(&timeout_lock, key);
  t->fn(t);
  key = k_spin_lock(&timeout_lock);
 }

 if (first() != NULL) {
  first()->dticks -= announce_remaining;
 }

 curr_tick += announce_remaining;
 announce_remaining = 0;

 z_clock_set_timeout(next_timeout(), false);

 k_spin_unlock(&timeout_lock, key);
}




曹子龙

珠海全志科技股份有限公司      BU1-PSW

地址:广东省珠海市高新区唐家湾镇科技2路9号

TEL:13824125580

Email:caozilong@...

网址: http://www.allwinnertech.com

 




Re: Is The tick handler "z_clock_announce" in SMP mode dupulicate caculated?

Andy Ross
 

This is the responsibility of the timer driver.  The ticks announced needs to be globally correct.  The existing drivers do this by locking a "last count" state variable and updating it, so they see the updates made by the other cores.


Andy


On 8/23/2019 8:14 AM, "曹子龙 wrote:
Hi  friends:
    
  a puzzle in the timer tick interrupt handler in SMP mode.  look at below,  the SMP mult cores share the same "cur_tick" object to remeber the current time, each cpu would increment it when the tick hander  excutes on each CPU.
so, could this would accelerate the timer compare with the realworld?  for example, if 4cores  exist, the cur_tick would 4 times incmrent than the read world, i cant fingure out where am a wrong, so, could you figure me out?  thanks for your kinldy supply. 

void z_clock_announce(s32_t ticks)
{
#ifdef CONFIG_TIMESLICING
 z_time_slice(ticks);
#endif

 k_spinlock_key_t key = k_spin_lock(&timeout_lock);

 announce_remaining = ticks;

 while (first() != NULL && first()->dticks <= announce_remaining) {
  struct _timeout *t = first();
  int dt = t->dticks;

  curr_tick += dt;
  announce_remaining -= dt;
  t->dticks = 0;
  remove_timeout(t);

  k_spin_unlock(&timeout_lock, key);
  t->fn(t);
  key = k_spin_lock(&timeout_lock);
 }

 if (first() != NULL) {
  first()->dticks -= announce_remaining;
 }

 curr_tick += announce_remaining;
 announce_remaining = 0;

 z_clock_set_timeout(next_timeout(), false);

 k_spin_unlock(&timeout_lock, key);
}




曹子龙

珠海全志科技股份有限公司      BU1-PSW

地址:广东省珠海市高新区唐家湾镇科技2路9号

TEL:13824125580

Email:caozilong@...

网址: http://www.allwinnertech.com

 



Is The tick handler "z_clock_announce" in SMP mode dupulicate caculated?

"曹子龙
 

Hi  friends:
    
  a puzzle in the timer tick interrupt handler in SMP mode.  look at below,  the SMP mult cores share the same "cur_tick" object to remeber the current time, each cpu would increment it when the tick hander  excutes on each CPU.
so, could this would accelerate the timer compare with the realworld?  for example, if 4cores  exist, the cur_tick would 4 times incmrent than the read world, i cant fingure out where am a wrong, so, could you figure me out?  thanks for your kinldy supply. 

void z_clock_announce(s32_t ticks)
{
#ifdef CONFIG_TIMESLICING
 z_time_slice(ticks);
#endif

 k_spinlock_key_t key = k_spin_lock(&timeout_lock);

 announce_remaining = ticks;

 while (first() != NULL && first()->dticks <= announce_remaining) {
  struct _timeout *t = first();
  int dt = t->dticks;

  curr_tick += dt;
  announce_remaining -= dt;
  t->dticks = 0;
  remove_timeout(t);

  k_spin_unlock(&timeout_lock, key);
  t->fn(t);
  key = k_spin_lock(&timeout_lock);
 }

 if (first() != NULL) {
  first()->dticks -= announce_remaining;
 }

 curr_tick += announce_remaining;
 announce_remaining = 0;

 z_clock_set_timeout(next_timeout(), false);

 k_spin_unlock(&timeout_lock, key);
}




曹子龙

珠海全志科技股份有限公司      BU1-PSW

地址:广东省珠海市高新区唐家湾镇科技2路9号

TEL:13824125580

Email:caozilong@...

网址: http://www.allwinnertech.com

 



Re: Md5 hash

Carles Cufi
 

Hi there,

 

Mbedtls comes with an MD5 implementation:

https://github.com/zephyrproject-rtos/mbedtls/blob/master/include/mbedtls/md5.h

 

Carles

 

From: <devel@...> on behalf of "Ruben Kertesz via Lists.Zephyrproject.Org" <rubenk=gmail.com@...>
Reply-To: "rubenk@..." <rubenk@...>
Date: Thursday, 22 August 2019 at 19:59
To: "devel@..." <devel@...>
Cc: "devel@..." <devel@...>
Subject: [Zephyr-devel] Md5 hash

 

Any recommendations on best methods to write a md5 hash function?

I didn't find one built in but maybe I overlooked.


Md5 hash

Ruben Kertesz
 

Any recommendations on best methods to write a md5 hash function?
I didn't find one built in but maybe I overlooked.

1981 - 2000 of 8183