Andrew Holt
Hi,
On running: west build -b native_posix samples/hello_world I get the following error, any advice or suggestions ? -- west build: build configuration: source directory: /media/andrewh/SOURCE/Source/zephyrproject/zephyr/samples/hello_world
build directory: /media/andrewh/SOURCE/Source/zephyrproject/zephyr/build
BOARD: native_posix (origin: command line)
-- west build: generating a build system
CMake Error: The source directory "" does not exist.
Specify --help for usage, or press the help button on the CMake GUI.
ERROR: command exited with status 1: /usr/bin/cmake -B/media/andrewh/SOURCE/Source/zephyrproject/zephyr/build -S/media/andrewh/SOURCE/Source/zephyrproject/zephyr/samples/hello_world -GNinja -DBOARD=native_posix
|
|
Build posix sample problem (cmake error)
Andrew Holt
Hi,
I'm new to Zephyr, just starting to investigate it. I suspect I'm either missing something or doing something silly. When I run the following command in the /home/andrewh/Source/zephyrproject/zephyr folder: west build -b native_posix samples/hello_world
I get : -- west build: build configuration:
source directory: /media/andrewh/SOURCE/Source/zephyrproject/zephyr/samples/hello_world
build directory: /media/andrewh/SOURCE/Source/zephyrproject/zephyr/build
BOARD: native_posix (origin: command line)
-- west build: generating a build system
CMake Error: The source directory "" does not exist.
Specify --help for usage, or press the help button on the CMake GUI.
ERROR: command exited with status 1: /usr/bin/cmake -B/media/andrewh/SOURCE/Source/zephyrproject/zephyr/build -S/media/andrewh/SOURCE/Source/zephyrproject/zephyr/samples/hello_world -GNinja -DBOARD=native_posix
Any help much appreciated
|
|
Re: [RFC] Enabling %lld, %llu (long long) support for newlib's stdio
Paul Sokolovsky
On Tue, 27 Aug 2019 15:00:54 +0000
"Cufi, Carles" <Carles.Cufi@nordicsemi.no> wrote: Hi Paul,Good to know, thanks!And perhaps the problem space considered thoroughly first. As anThis one seems to have been renamed "picolibc":
-- 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
|
|
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 Live meeting minutes: https://docs.google.com/
|
|
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 anThis 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 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, includingAnd 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)
-- 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:
|
|
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: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
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.
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:
|
|
[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
|
|
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:
toggle quoted messageShow quoted text
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:
|
|
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:
|
|
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@...>
when I do a zephyr (v1.14-branch) $ git checkout v1.14<tab>
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
|
|
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
toggle quoted messageShow quoted text
------------------------------------------------------------------
|
|
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:
|
|