Date   

Re: Porting to Cortex-M0+

Euan Mutch <euan.mutch@...>
 

So the best way forward is to add the device headers to /hal/asf and change sam3 to the family/series hierarchy?

There are some really weird things going on with the Atmel drivers, especially some of the really horrible macros they use. Took me a full day just to decipher the clock init code.

Quick (newbie) question:
I have currently added just the M0+ specific bits of asf, but I can't get it to link properly and so get "undefined reference to 'system_init'" when I try to use it. It is really hard to figure out how to do certain things in zephyr such as adding external stuff... Although that could just be because I have never worked on something like this before.
I don't understand how the other HALs work since they also have drivers in them, I have exactly the same setup as those. Which seems to just be including the files and never building anything?


Daily JIRA Digest

donotreply@...
 

NEW JIRA items within last 24 hours: 0

UPDATED JIRA items within last 24 hours: 2
[ZEP-635] Add FS API to grow a file
https://jira.zephyrproject.org/browse/ZEP-635

[ZEP-622] Add FS API to truncate/shrink a file
https://jira.zephyrproject.org/browse/ZEP-622


CLOSED JIRA items within last 24 hours: 0

RESOLVED JIRA items within last 24 hours: 1
[ZEP-528] (Fixed) ARC has 2 almost identical copies of the linker script
https://jira.zephyrproject.org/browse/ZEP-528


Daily Gerrit Digest

donotreply@...
 

NEW within last 24 hours:
- https://gerrit.zephyrproject.org/r/4382 : Bluetooth: Clean up feature test macros

UPDATED within last 24 hours:
- https://gerrit.zephyrproject.org/r/4378 : Bluetooth: Extend HCI to cover all BLE commands and events
- https://gerrit.zephyrproject.org/r/4377 : Bluetooth: GATT: Fix notifications to non-bonded peers
- https://gerrit.zephyrproject.org/r/4376 : Bluetooth: GAP: Support multiple peripheral role connections
- https://gerrit.zephyrproject.org/r/3895 : tests/kernel/test_multilib: Test for proper multilib selection.

MERGED within last 24 hours:
- https://gerrit.zephyrproject.org/r/4381 : Bluetooth: Fix feature page count for single-mode configuration
- https://gerrit.zephyrproject.org/r/4380 : Bluetooth: Fix reading local features
- https://gerrit.zephyrproject.org/r/4379 : Bluetooth: Make lmp_ext_feat_capable() more generic
- https://gerrit.zephyrproject.org/r/4173 : tests: kernel: fix incorrect printk() usage
- https://gerrit.zephyrproject.org/r/4170 : printk: make _char_out globally accessible
- https://gerrit.zephyrproject.org/r/4366 : test_cbc: fix indentation
- https://gerrit.zephyrproject.org/r/4183 : samples: zperf: fix incorrect printk() usage
- https://gerrit.zephyrproject.org/r/4184 : drivers: console_handler_shell: fix incorrect printk() usage
- https://gerrit.zephyrproject.org/r/4188 : samples: i2c_fujitsu_fram: fix incorrect printk() usage
- https://gerrit.zephyrproject.org/r/4169 : printk: "support" some modifier codes
- https://gerrit.zephyrproject.org/r/4172 : tests: crypto: fix incorrect printk() usage
- https://gerrit.zephyrproject.org/r/4171 : tests: test_printk: crude printk test case
- https://gerrit.zephyrproject.org/r/4207 : printk: print leading '0x' for %p
- https://gerrit.zephyrproject.org/r/4363 : test_sha256: fix indentation
- https://gerrit.zephyrproject.org/r/4206 : libc: minimal: add reduced inttypes.h
- https://gerrit.zephyrproject.org/r/4190 : printk: warn on incorrect printf-style usage
- https://gerrit.zephyrproject.org/r/4176 : tests: benchmark: fix incorrect printk() usage
- https://gerrit.zephyrproject.org/r/4174 : tests: net: fix incorrect printk() usage
- https://gerrit.zephyrproject.org/r/4185 : drivers: ipm_console: fix incorrect printk() usage
- https://gerrit.zephyrproject.org/r/4181 : samples: fat_fs: fix incorrect printk() usage
- https://gerrit.zephyrproject.org/r/4179 : nios2: fix incorrect printk() usage
- https://gerrit.zephyrproject.org/r/4177 : net: fix incorrect printk() usage
- https://gerrit.zephyrproject.org/r/4186 : x86: fix incorrect printk() usage
- https://gerrit.zephyrproject.org/r/4182 : samples: ipm: fix incorrect printk() usage
- https://gerrit.zephyrproject.org/r/4180 : arc: fix incorrect printk() usage
- https://gerrit.zephyrproject.org/r/4178 : arm: fix incorrect printk() usage
- https://gerrit.zephyrproject.org/r/4175 : tests: bluetooth: fix incorrect printk() usage
- https://gerrit.zephyrproject.org/r/4187 : drivers: pci: fix incorrect printk() usage
- https://gerrit.zephyrproject.org/r/4365 : test_ctr: fix indentation
- https://gerrit.zephyrproject.org/r/4364 : test_hmac: fix indentation
- https://gerrit.zephyrproject.org/r/4257 : lib: Use offsetof() builtin with GCC


Daily JIRA Digest

donotreply@...
 

NEW JIRA items within last 24 hours: 5
[ZEP-744] USB WebUSB
https://jira.zephyrproject.org/browse/ZEP-744

[ZEP-748] Enable mbedtls_sslclient sample to run on quark se board
https://jira.zephyrproject.org/browse/ZEP-748

[ZEP-745] Revisit design of PWM Driver API
https://jira.zephyrproject.org/browse/ZEP-745

[ZEP-746] API documentation doesn't link to conceptual documentation
https://jira.zephyrproject.org/browse/ZEP-746

[ZEP-747] Nano FIFO reserving first four bytes of user data isn't well-documented
https://jira.zephyrproject.org/browse/ZEP-747


UPDATED JIRA items within last 24 hours: 4
[ZEP-244] Multiple Published Versions Support
https://jira.zephyrproject.org/browse/ZEP-244

[ZEP-655] QMSI shim driver: PWM: Implement suspend and resume callbacks
https://jira.zephyrproject.org/browse/ZEP-655

[ZEP-517] build on windows failed "zephyr/Makefile:869: *** multiple target patterns"
https://jira.zephyrproject.org/browse/ZEP-517

[ZEP-539] Jenkins marks patches -1 verified for style issues
https://jira.zephyrproject.org/browse/ZEP-539


CLOSED JIRA items within last 24 hours: 6
[ZEP-658] (Fixed) QMSI shim driver: GPIO: Implement suspend and resume callbacks
https://jira.zephyrproject.org/browse/ZEP-658

[ZEP-650] (Fixed) Quark SE: Implement PM reference application
https://jira.zephyrproject.org/browse/ZEP-650

[ZEP-662] (Fixed) QMSI shim driver: Pinmux: Implement suspend and resume callbacks
https://jira.zephyrproject.org/browse/ZEP-662

[ZEP-659] (Fixed) QMSI shim driver: UART: Implement suspend and resume callbacks
https://jira.zephyrproject.org/browse/ZEP-659

[ZEP-739] (Fixed) warnings when building samples for quark_se devboard
https://jira.zephyrproject.org/browse/ZEP-739

[ZEP-642] (Fixed) Inconsistent interpretation of pwm_pin_set_values arguments among drivers
https://jira.zephyrproject.org/browse/ZEP-642


RESOLVED JIRA items within last 24 hours: 0


Daily Gerrit Digest

donotreply@...
 

NEW within last 24 hours:
- https://gerrit.zephyrproject.org/r/4378 : Bluetooth: Extend HCI to cover all BLE commands and events
- https://gerrit.zephyrproject.org/r/4365 : test_ctr: fix indentation
- https://gerrit.zephyrproject.org/r/4366 : test_cbc: fix indentation
- https://gerrit.zephyrproject.org/r/4364 : test_hmac: fix indentation
- https://gerrit.zephyrproject.org/r/4363 : test_sha256: fix indentation
- https://gerrit.zephyrproject.org/r/4377 : Bluetooth: GATT: Fix notifications to non-bonded peers
- https://gerrit.zephyrproject.org/r/4376 : Bluetooth: GAP: Support multiple peripheral role connections
- https://gerrit.zephyrproject.org/r/4375 : tests: fixed resulting binary name in README
- https://gerrit.zephyrproject.org/r/4372 : fs: Adds file system API to grow or shrink a file
- https://gerrit.zephyrproject.org/r/4371 : win-build: fixes to build with alternative make implementations

UPDATED within last 24 hours:
- https://gerrit.zephyrproject.org/r/4177 : net: fix incorrect printk() usage
- https://gerrit.zephyrproject.org/r/4183 : samples: zperf: fix incorrect printk() usage
- https://gerrit.zephyrproject.org/r/4181 : samples: fat_fs: fix incorrect printk() usage
- https://gerrit.zephyrproject.org/r/4178 : arm: fix incorrect printk() usage
- https://gerrit.zephyrproject.org/r/4175 : tests: bluetooth: fix incorrect printk() usage
- https://gerrit.zephyrproject.org/r/4184 : drivers: console_handler_shell: fix incorrect printk() usage
- https://gerrit.zephyrproject.org/r/4182 : samples: ipm: fix incorrect printk() usage
- https://gerrit.zephyrproject.org/r/4179 : nios2: fix incorrect printk() usage
- https://gerrit.zephyrproject.org/r/4176 : tests: benchmark: fix incorrect printk() usage
- https://gerrit.zephyrproject.org/r/4172 : tests: crypto: fix incorrect printk() usage
- https://gerrit.zephyrproject.org/r/4174 : tests: net: fix incorrect printk() usage
- https://gerrit.zephyrproject.org/r/4173 : tests: kernel: fix incorrect printk() usage
- https://gerrit.zephyrproject.org/r/4206 : libc: minimal: add reduced inttypes.h
- https://gerrit.zephyrproject.org/r/4357 : tests: Add a sample for testing natively
- https://gerrit.zephyrproject.org/r/3459 : soc: Add soc id and version interface
- https://gerrit.zephyrproject.org/r/4081 : power_mgmt: Updated Power Management device driver API
- https://gerrit.zephyrproject.org/r/3845 : x86: remove dynamic interrupts and exceptions
- https://gerrit.zephyrproject.org/r/3856 : x86: declare internal API for interrupt controllers
- https://gerrit.zephyrproject.org/r/3953 : sanitycheck: complain loudly about missing platforms
- https://gerrit.zephyrproject.org/r/3847 : arm: remove dynamic IRQs and exceptions
- https://gerrit.zephyrproject.org/r/3846 : arc: remove deprecated dynamic interrupt implementation
- https://gerrit.zephyrproject.org/r/4187 : drivers: pci: fix incorrect printk() usage
- https://gerrit.zephyrproject.org/r/4170 : printk: make _char_out globally accessible
- https://gerrit.zephyrproject.org/r/4169 : printk: "support" some modifier codes
- https://gerrit.zephyrproject.org/r/4171 : tests: test_printk: crude printk test case
- https://gerrit.zephyrproject.org/r/3957 : microkernel: remove deprecated task IRQs
- https://gerrit.zephyrproject.org/r/3844 : test_context: don't test dynamic exceptions
- https://gerrit.zephyrproject.org/r/3843 : zephyr: remove deprecated dynamic interrupt API
- https://gerrit.zephyrproject.org/r/4190 : printk: warn on incorrect printf-style usage
- https://gerrit.zephyrproject.org/r/4188 : samples: i2c_fujitsu_fram: fix incorrect printk() usage
- https://gerrit.zephyrproject.org/r/4186 : x86: fix incorrect printk() usage
- https://gerrit.zephyrproject.org/r/4185 : drivers: ipm_console: fix incorrect printk() usage
- https://gerrit.zephyrproject.org/r/4180 : arc: fix incorrect printk() usage
- https://gerrit.zephyrproject.org/r/4207 : printk: print leading '0x' for %p
- https://gerrit.zephyrproject.org/r/4359 : ksdk: Allow KSDK selection via Kconfig
- https://gerrit.zephyrproject.org/r/3895 : tests/kernel/test_multilib: Test for proper multilib selection.
- https://gerrit.zephyrproject.org/r/4341 : Bluetooth: HFP HF: Initialize Handsfree profile
- https://gerrit.zephyrproject.org/r/4354 : ztest: Add documentation
- https://gerrit.zephyrproject.org/r/4360 : ksdk: Add KSDK RNGA driver.
- https://gerrit.zephyrproject.org/r/4336 : Bluetooth: RFCOMM: Introduce helper to create rfcomm pdu

MERGED within last 24 hours:
- https://gerrit.zephyrproject.org/r/4367 : latency test: remove references to unused legacy "KERNEL" preproc flag
- https://gerrit.zephyrproject.org/r/4368 : tests/crypto: rename MICROKERNEL entry from 'mainloop' to 'main'
- https://gerrit.zephyrproject.org/r/4361 : ext/hal: add maintainers for both cmsis and ksdk
- https://gerrit.zephyrproject.org/r/4374 : MAINTAINERS: fix email syntax
- https://gerrit.zephyrproject.org/r/4362 : device: small typo in comment
- https://gerrit.zephyrproject.org/r/4373 : Merge master branch into bluetooth
- https://gerrit.zephyrproject.org/r/4370 : Zephyr 1.5.0
- https://gerrit.zephyrproject.org/r/4369 : sanitychecks: update release data
- https://gerrit.zephyrproject.org/r/4310 : Make outdir board-specific to avoid build collisions
- https://gerrit.zephyrproject.org/r/3956 : arc: unify copied linker script
- https://gerrit.zephyrproject.org/r/4246 : nano_work: Make use of ATOMIC_DEFINE for the flags
- https://gerrit.zephyrproject.org/r/4330 : arc/soc: remove unused CONFIG_TIMER0_CLOCK_FREQ
- https://gerrit.zephyrproject.org/r/4300 : Bluetooth: Enable Secure Connections if supported
- https://gerrit.zephyrproject.org/r/4349 : Bluetooth: Read local extended features on init
- https://gerrit.zephyrproject.org/r/4299 : Bluetooth: Add support for P256 Link Keys
- https://gerrit.zephyrproject.org/r/4298 : Bluetooth: Refactor Link Key notification event handling


Daily JIRA Digest

donotreply@...
 

NEW JIRA items within last 24 hours: 1
[ZEP-741] Network TCP API is adhoc and makes arbitrary assumptions
https://jira.zephyrproject.org/browse/ZEP-741


UPDATED JIRA items within last 24 hours: 2
[ZEP-172] tests/kernel/test_task_priv/test FAILED in QEMU
https://jira.zephyrproject.org/browse/ZEP-172

[ZEP-735] Several Tests and Samples are broken for CONFIG_DEBUG
https://jira.zephyrproject.org/browse/ZEP-735


CLOSED JIRA items within last 24 hours: 3
[ZEP-616] (Fixed) OS X setup instructions not working on El Capitan
https://jira.zephyrproject.org/browse/ZEP-616

[ZEP-423] (Fixed) Quark D2000 CRB documentation should include instructions to flash bootloader
https://jira.zephyrproject.org/browse/ZEP-423

[ZEP-68] (Fixed) Final image contains duplicates of some routines
https://jira.zephyrproject.org/browse/ZEP-68


RESOLVED JIRA items within last 24 hours: 0


Re: Porting to Cortex-M0+

Maureen Helm
 

-----Original Message-----
From: Piotr Mienkowski [mailto:Piotr.Mienkowski(a)schmid-telecom.ch]
Sent: Thursday, August 25, 2016 4:22 AM
To: devel(a)lists.zephyrproject.org
Subject: [devel] Re: Re: Re: Re: Porting to Cortex-M0+

Hi,

I have the same problem. I would like to add support for Atmel SAM E70 chip
(Cortex-M7) and was thinking that using the header files provided by Atmel as
part of their ASF would make the job much, much easier.

Euan, did you already add files to ext/hal/ folder? Have you talked to Maureen
Helm, the ARM architecture maintainer? Should we agree on folder structure
so support for future Atmel chips can be easily added?
I agree it would make sense to add the device header files from Atmel to ext/hal. We already have the CMSIS Core header files from ARM in ext/hal/cmsis, which are being used by the NXP ksdk and Nordic mdk. As far as folder structure goes, I think anything under ext/hal/asf (or whatever we end up calling it) has some freedom to do what makes sense. For ext/hal/cmsis and ext/hal/ksdk, I tried to preserve the structure from the original source as much as possible. The folder structure under arch/arm/soc is intended to be more standardized, though you may have noticed that some SoCs have a family/series hierarchy (nxp_kinetis) and some don't (atmel_sam3). To add SAM E70, we'll need to first convert the existing atmel_sam3 to the family/series hierarchy. Something like this:

arch/arm/soc/atmel_smart/sam3
arch/arm/soc/atmel_smart/same7x


My thoughts:
I think we should only add header files that define register access and do not
add any device drivers. While header files are valuable the Atmel
implementation of device drivers looks low quality, at least the SAM E70
package. The way API is written is not directly useful for any serious
development, neither it follows CMSIS standard. While some drivers look good,
some are incomplete and some are buggy. We would need to fix them and
cooperate with Atmel to push changes upstream. I reckon using third party
source code which is not maintained in open source model is not a viable long
term solution. Not mentioning the fact that device drivers will have to be tightly
integrated with Zephyr kernel. I believe it's easier to write our own drivers
from scratch. Anyway, that's only my opinion.
I can't comment on the state of the Atmel drivers, but at least for NXP we do a lot of testing on the ksdk drivers and they are actively maintained. Intel is doing a similar thing with their qmsi drivers.


The text of SAM Software Package License included in the source code (and
header files) looks actually very permissive but IANAL, also the ext/hal/ folder
has already a selection of proprietary code with similar licenses. In any case we
should probably get an official green light from someone.
IANAL either, but will check with someone at LF on this.


Cheers,
Piotr


Re: Atomicity in GPIO pin changes

Maciek Borzecki <maciek.borzecki@...>
 

On Fri, Aug 26, 2016 at 4:57 PM, Jon Medhurst (Tixy) <tixy(a)linaro.org> wrote:
On Fri, 2016-08-26 at 10:32 -0400, Benjamin Walsh wrote:
Spinlocks don't give you anything more than interrupt or scheduler
locking in a uniprocessor system with a scheduler like Zephyr's, since
you need to lock interrupts and/or scheduling as well when you're holing
them or there is a good chance you'll deadlock. You probably want just
interrupt or scheduler locking instead. Scheduler locking is coming up
in the upcoming unified kernel, but is not available at the moment;
interrupt locking is of course available.
I figured that interrupt locking was the way to go, was just wary of it
since it would break with SMP. Guess when that arrives all interrupt
disabling will need to be audited and converted to spinlocks if
appropriate.

That still leaves the issue that current GPIO drivers look dodgy without
any locking.
Not entirely. A particular SoC may provide means of setting/resetting
GPIO in an atomic fashion. Driver implementation should use such
mechanism if present.

For instance, STM32 GPIO peripheral has 2 dedicated bit set/reset
registers (GPIOx_BSRR/BRR) that allow for switching individual line
states in an atomic fashion. In this case, the driver does not perform
an intermediate read, but rather writes a desired value to the
register.

Cheers,
--
Maciek Borzecki


Daily Gerrit Digest

donotreply@...
 

NEW within last 24 hours:
- https://gerrit.zephyrproject.org/r/4341 : Bluetooth: HFP HF: Initialize Handsfree profile
- https://gerrit.zephyrproject.org/r/4359 : ksdk: Allow KSDK selection via Kconfig
- https://gerrit.zephyrproject.org/r/4353 : ztest: Add native building support
- https://gerrit.zephyrproject.org/r/4356 : tests: convert tests/net/buf to the new framework
- https://gerrit.zephyrproject.org/r/4357 : tests: Add a sample for testing natively
- https://gerrit.zephyrproject.org/r/4355 : ztest: Add simple integration and unit tests
- https://gerrit.zephyrproject.org/r/4358 : net: samples: Revamp QEMU-QEMU networking in echo_server & echo_client
- https://gerrit.zephyrproject.org/r/4349 : Bluetooth: Read local extended features on init
- https://gerrit.zephyrproject.org/r/4354 : ztest: Add documentation
- https://gerrit.zephyrproject.org/r/4360 : ksdk: Add KSDK RNGA driver.
- https://gerrit.zephyrproject.org/r/4345 : kernel: Rename CONFIG_CUSTOM_RANDOM_GENERATOR to CONFIG_RANDOM_GENERATOR
- https://gerrit.zephyrproject.org/r/4336 : Bluetooth: RFCOMM: Introduce helper to create rfcomm pdu
- https://gerrit.zephyrproject.org/r/4347 : net: yaip: User connectivity API documentation
- https://gerrit.zephyrproject.org/r/4346 : net: yaip: Initial architecture documentation
- https://gerrit.zephyrproject.org/r/4344 : Bluetooth: RFCOMM: Remove BT_RFCOMM_SEND_RESERVE
- https://gerrit.zephyrproject.org/r/4343 : Bluetooth: shell: Use bt_rfcomm_create_pdu() in rfcomm send
- https://gerrit.zephyrproject.org/r/4342 : Bluetooth: Kconfig: Be consistent with the use of tabs vs spaces
- https://gerrit.zephyrproject.org/r/4339 : drivers/nble: Rename nrf51 power management functions
- https://gerrit.zephyrproject.org/r/4330 : arc/soc: remove unused CONFIG_TIMER0_CLOCK_FREQ
- https://gerrit.zephyrproject.org/r/4326 : net: Tighten ETHERTYPE decode.
- https://gerrit.zephyrproject.org/r/4327 : fix: "uninitialized" variables break DEBUG sanity

UPDATED within last 24 hours:
- https://gerrit.zephyrproject.org/r/4299 : Bluetooth: Add support for P256 Link Keys
- https://gerrit.zephyrproject.org/r/4321 : Bluetooth: BR/EDR: Disconnect legacy device on auth failed
- https://gerrit.zephyrproject.org/r/4118 : tests: Add a generic testing framework
- https://gerrit.zephyrproject.org/r/4300 : Bluetooth: Enable Secure Connections if supported
- https://gerrit.zephyrproject.org/r/4298 : Bluetooth: Refactor Link Key notification event handling
- https://gerrit.zephyrproject.org/r/4226 : net: Do not fill in TCP option bytes for all packets
- https://gerrit.zephyrproject.org/r/4197 : Bluetooth: AVDTP: Module intialization
- https://gerrit.zephyrproject.org/r/4303 : loop-slip4.sh: Wrapper script to run tunslip for IPv4 connection to QEMU
- https://gerrit.zephyrproject.org/r/3459 : soc: Add soc id and version interface
- https://gerrit.zephyrproject.org/r/4171 : tests: test_printk: crude printk test case
- https://gerrit.zephyrproject.org/r/4310 : Make outdir board-specific to avoid build collisions
- https://gerrit.zephyrproject.org/r/4323 : usb: Allow to register and handle vendor specific commands
- https://gerrit.zephyrproject.org/r/4231 : net/yaip: Use the dummy L2 frame format for Qemu

MERGED within last 24 hours:
- https://gerrit.zephyrproject.org/r/4348 : Bluetooth: Build RFCOMM documentation
- https://gerrit.zephyrproject.org/r/4338 : Bluetooth/samples: Fix missing argument in printf for btusb
- https://gerrit.zephyrproject.org/r/4337 : Bluetooth/drivers: Fix missing argument in printf for h5 driver
- https://gerrit.zephyrproject.org/r/4334 : Zephyr 1.5.0-rc4
- https://gerrit.zephyrproject.org/r/4332 : build: xtools: fix 'make qemu'
- https://gerrit.zephyrproject.org/r/4329 : Bluetooth: Controller: Fix assert on advertise start
- https://gerrit.zephyrproject.org/r/4328 : Bluetooth: Controller: Fix coding style, use of (void)
- https://gerrit.zephyrproject.org/r/4295 : Bluetooth: Enable and disable BLE chip sleep mode dynamically
- https://gerrit.zephyrproject.org/r/3997 : Bluetooth: L2CAP: Implement connect command on BR/EDR
- https://gerrit.zephyrproject.org/r/4311 : samples: pwm: adapt to new api argument definition
- https://gerrit.zephyrproject.org/r/4277 : drivers: pwm_shim: correct api argument inconsistency
- https://gerrit.zephyrproject.org/r/4230 : net: yaip: Fix listening on IPv6 ports
- https://gerrit.zephyrproject.org/r/4229 : drivers/slip: Fix warnings when TAP support is disabled
- https://gerrit.zephyrproject.org/r/4325 : net: buf: Fix minor typo in documentation
- https://gerrit.zephyrproject.org/r/4224 : Bluetooth: shell: Add support for RFCOMM send data
- https://gerrit.zephyrproject.org/r/4223 : Bluetooth: RFCOMM: Implement send data API


Re: Atomicity in GPIO pin changes

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

On Fri, 2016-08-26 at 10:32 -0400, Benjamin Walsh wrote:
Spinlocks don't give you anything more than interrupt or scheduler
locking in a uniprocessor system with a scheduler like Zephyr's, since
you need to lock interrupts and/or scheduling as well when you're holing
them or there is a good chance you'll deadlock. You probably want just
interrupt or scheduler locking instead. Scheduler locking is coming up
in the upcoming unified kernel, but is not available at the moment;
interrupt locking is of course available.
I figured that interrupt locking was the way to go, was just wary of it
since it would break with SMP. Guess when that arrives all interrupt
disabling will need to be audited and converted to spinlocks if
appropriate.

That still leaves the issue that current GPIO drivers look dodgy without
any locking.

--
Tixy


Re: QEMU networking: CONFIG_NET_TESTING breaks things, echo_server IPv6 address is "wrong"

Paul Sokolovsky
 

Hello Jukka,

On Fri, 19 Aug 2016 14:37:10 +0300
Jukka Rissanen <jukka.rissanen(a)linux.intel.com> wrote:

[]


Patches for these items can be now found in
https://gerrit.zephyrproject.org/r/#/c/4199/
I appreciate all the improvements done to networking documentation and
testing setup via the above and other patches during this week. There're
also some further concerns/issues, which I initially shared in
post-review comments to https://gerrit.zephyrproject.org/r/#/c/4200/ ,
and would like to duplicate here so they weren't lost:

* QEMU-host networking now works out of the box, but changes for that
regressed QEMU-QEMU case. I attempt to fix that in
https://gerrit.zephyrproject.org/r/4358 , but it needs review for
changes it does regarding NETWORKING_WITH_15_4 option.

* #4199, #4200 above went to "net" branch. Any ETA/plan for merging
them to master? My guess they went to "net" to avoid (incomplete)
changes soon before 1.5.0 release, but would be nice to get an
official ack.

* Finally, the latest one: I tried QEMU networking with qemu_cortex_m3,
and it doesn't work where qemu_x86 does. Which makes me wonder if
networking with qemu_cortex_m3 is supported/known to have worked at
all.


Thanks,
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


Re: having trouble getting the echo client to work using TCP/uIP on K64F

Rohit Grover
 

Paul,

With tcpip_poll_tcp() reverted to its original version:

void
tcpip_poll_tcp(struct uip_conn *conn, struct net_buf *data_buf)
{
/* We are sending here the initial SYN */
struct net_buf *buf = ip_buf_get_tx(conn->appstate.state);
uip_set_conn(buf) = conn;
conn->buf = ip_buf_ref(buf);

process_post_synch(&tcpip_process, TCP_POLL, conn, buf);
}

I can now connect and send a packet using the following code run either as a fiber or a task:

void activity(void)
{
printk("starting activity\n");

// int expecting_len = 0;
int status;

/* CONNECT */
net_context_tcp_init(unicast, NULL, NET_TCP_TYPE_CLIENT);
printk("activity: returned from net_context_tcp_init; waiting for status to change\n");

while ((status = net_context_get_connection_status(unicast)) != 0) {
#if defined(CONFIG_MICROKERNEL)
task_sleep(100);
#else
fiber_sleep(100);
#endif
}
printk("activity: status = %d\n", status);

/* SEND */
struct net_buf *buf = ip_buf_get_tx(unicast);
if (buf) {
uint8_t *ptr;
int sending_len = 64;

printk("activity: filling in net_buf with %u bytes from ipsum+%u\n", sending_len, ipsum_len - sending_len);
ptr = net_buf_add(buf, sending_len);
memcpy(ptr, lorem_ipsum + ipsum_len - sending_len, sending_len);

ip_buf_appdatalen(buf) = sending_len;

while ((status = net_send(buf)) < 0) {
printk("activity: got status %d; retrying in a while\n", status);
#if defined(CONFIG_MICROKERNEL)
task_sleep(100);
#else
fiber_sleep(100);
#endif
}
printk("activity: net_send returned %d\n", status);
}
}

This is already an improvement over the state where I could not send using a microkernel.
Sending out a second packet before processing the receipt of the first hasn't worked yet, but I'll leave that investigation for next week.

Regards,
Rohit.

-----Original Message-----
> From: Rohit Grover
> Sent: 26 August 2016 12:07
> To: 'Paul Sokolovsky'
> Cc: devel(a)lists.zephyrproject.org; Jukka Rissanen
> Subject: RE: having trouble getting the echo client to work using TCP/uIP on
> K64F
>
> Paul,
>
> It is useful to work our way through the core BSD socket API in the context of
> Z-uIP.
>
> Let's take connect(). Assuming that a net_context has been setup, connect()
> can be implemented using the snippet:
>
> net_context_tcp_init(net_context, NULL /* bp */,
> NET_TCP_TYPE_CLIENT);
> while ((status = net_context_get_connection_status(unicast)) != 0) {
> fiber_sleep(SOME_SMALL_DURATION);
> }
>
> We're passing `bp' as NULL, but it seems un-necessary for net_context_init()
> to require a bp. This leads us to commit 61edc68c, by Jukka, where many of
> the APIs suddenly acquired an additional 'bp' parameter. In some cases, this
> led to code which I'm having trouble understanding. , I've attached the diff,
> but I'll highlight a snippet. Take the case of tcpip_poll_tcp(), which is
> responsible for sending out the initial SYN packet.
>
> @@ -837,12 +837,18 @@ tcpip_poll_udp(struct uip_udp_conn *conn) /*-----
> ----------------------------------------------------------------------*/
> #if UIP_TCP
> void
> -tcpip_poll_tcp(struct uip_conn *conn)
> +tcpip_poll_tcp(struct uip_conn *conn, struct net_buf *data_buf)
> {
> /* We are sending here the initial SYN */
> struct net_buf *buf = ip_buf_get_tx(conn->appstate.state);
> - uip_set_conn(buf) = conn;
> - conn->buf = ip_buf_ref(buf);
> + uip_set_conn(data_buf) = conn;
> +
> + /* The conn->buf will be freed after we have established the connection,
> + * sent the message and received an ack to it. This will happen in
> + * net_core.c:net_send().
> + */
> + conn->buf = ip_buf_ref(data_buf);
> +
> process_post_synch(&tcpip_process, TCP_POLL, conn, buf); }
>
> Here we see that we acquire a buf to send out a 'SYN' (refer to
> ip_buf_get_tx(...) above), but whereas previously we would associate it with
> the new connection and have its ref-count bumped, we now do those things
> for the 'data_buf' instead. This is a bit confusing. I don't see why the handling
> of the SYN buf needed to be changed.
>
> Rohit.
>
>
> > -----Original Message-----
> > From: Paul Sokolovsky [mailto:paul.sokolovsky(a)linaro.org]
> > Sent: 26 August 2016 00:57
> > To: Rohit Grover
> > Cc: devel(a)lists.zephyrproject.org; Jukka Rissanen
> > Subject: Re: having trouble getting the echo client to work using TCP/uIP
> on
> > K64F
> >
> > On Fri, 26 Aug 2016 01:07:29 +0300
> > Paul Sokolovsky <Paul.Sokolovsky(a)linaro.org> wrote:
> >
> > Some more info: Issues with IPv4/TCP can be seen building echo_server
> with
> > microkernel - making a TCP connection in this case hard locks-up QEMU
> VM,
> > not even pings work. Nothing special in the logging. However with
> > nanokernel, everything works, and send (reply) path doesn't involve
> > net_tx_fiber:
> >
> > Received packet 0x0010a4d0 len 7
> > receive: tcp received 7 bytes data
> > net: tcp_prepare_and_send (0010d27c): Packet output len 47
> > net: net_driver_slip_send (0010d27c): Sending 47 bytes, application data 7
> > bytes
> >
> >
> >
> > > On Mon, 22 Aug 2016 14:58:11 +0000
> > > Rohit Grover <Rohit.Grover(a)arm.com> wrote:
> > >
> > > > With my recent changes, I
> > > > manage to get the first packet bounce back successfully to the
> > > > echo-client. Successive packets aren't getting processed on their
> > > > way out from the client.
> > >
> > > I'm happy to report that I now see this too. Specifically, if using
> > > net_context_get()+net_send() (implicit connection establishment), data
> > > in first net_send() gets delivered (I see it in netcat), but not in
> > > subsequent calls to net_send().
> > >
> > > I'm however interested to emulate standard socket API paradigm, where
> > > you get all the standard and important calls like connect(), listen(),
> > > etc. For this, I explicitly call net_context_tcp_init(ctx, NULL,
> > > NET_TCP_TYPE_CLIENT) to emulate connect(). As netbuf is NULL in this
> > > call, only SYN/ACK handshake happens (with retries, just as you
> > > describe), and then first call
> > > net_send() doesn't send anything on wire. With logging it looks like:
> > >
> > > >>> s.connect(("192.0.2.1", 8083))
> > > resolved: 192.0.2.1
> > > net: net_driver_slip_send (001349e0): Sending 40 bytes, application
> > > data 0 bytes net: net_rx_fiber (001363e0): Received buf 0012c600
> > > ret=0
> > > >>> net: net_rx_fiber (001363e0): Received buf 0012d0f0
> > > net: net_rx_fiber (001363e0): Received buf 0012b598
> > > net: net_driver_slip_send (001363e0): Sending 40 bytes, application
> > > data 0 bytes
> > >
> > > >>> s.send("GET / HTTP/1.0\r\n")
> > > net: net_send (001349e0): context 0012dfa0 buf 00129a38 status 0
> > > net: net_tx_fiber (00135fe0): Sending (buf 00129a38, len 56) to IP
> > > stack 0
> > > >>>
> > >
> > > So, the difference is clear: SYN/ACK stuff goes to
> > > net_driver_slip_send(), but real app data get stuck in net_tx_fiber().
> > >
> > > I apply all your 3 patches, and they don't help.
> > >
> > >
> > > >
> > > > I find that uip_process() isn't getting called on successive
> > > > packets. It gets called for the first packet due to some
> > > > retransmission timer. The recently made change to eventhandler() in
> > > > tcpip.c (https://gerrit.zephyrproject.org/r/#/c/4050/) makes things
> > > > worse because the code meant to refresh certain periodic timers gets
> > > > skipped.
> > > >
> > > > These issues seem to arise from uIP. I would appreciate some help
> > > > from people who ported uIP to zephyr. I believe the problems will
> > > > surface if someone tries a TCP/IPV4 stream.
> > > >
> > > > rohit
> > >
> >
> >
> >
> > --
> > 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

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.


Re: Atomicity in GPIO pin changes

Benjamin Walsh <benjamin.walsh@...>
 

On Fri, Aug 26, 2016 at 12:10:40PM +0100, Jon Medhurst (Tixy) wrote:
Hi

I have a hardware register I want to change individual bits in as they
are used for different purposes on my SoC. I thought the GPIO APIs might
be the correct abstraction to represent that, and even if that wasn't
suitable I thought I could at least look at those to work out how
atomicity of updates is achieved (Zephyr doesn't seem to have spinlocks,
and mutexes and the like seem a bit heavyweight for the task, ...).
Spinlocks don't give you anything more than interrupt or scheduler
locking in a uniprocessor system with a scheduler like Zephyr's, since
you need to lock interrupts and/or scheduling as well when you're holing
them or there is a good chance you'll deadlock. You probably want just
interrupt or scheduler locking instead. Scheduler locking is coming up
in the upcoming unified kernel, but is not available at the moment;
interrupt locking is of course available.

A mutex is indeed too heavy for this, and they're currently not usable
by fibers (upcoming change in the unified kernel as well). A nanokernel
semaphore might be a good fit. Or interrupt locking.

However, looking at the GPIO API's and various implementations I can't
spot anything that serialises register updates, it just seems to boil
down to an unsafe "port |= (1 << bit_to_set)" or similar. Have I missed
things or is it expected that all users of a given port agree on a
mutual exclusion method? That doesn't seem very practical if they are
each different drivers or apps with no real need to know of each others
existence.


Re: System Design - Need feedback from developers

Benjamin Walsh <benjamin.walsh@...>
 

On Fri, Aug 26, 2016 at 05:35:11AM +0000, Mahendravarman Rajarao (RBEI/EAA3) wrote:
Hi Allan

Sorry I missed the line intrflag= 0 when typing the scenario
Please see the corrected scenario's

Scenario 1 :
=========
Int intflag = 0;

void interrupt_handler()
{
Printk ("interrupt handled \n");
------- set intrflag = 1

}

Int task1 ()
{

........interrupt initializations
........interrupt enable

While (1)
{
If (intrflag) { do something ..... ;
Intrflag=0;
} }
}


Scenario 2 :
========
Int intflag = 0;

void interrupt_handler()
{

Printk ("interrupt handled \n");
------- set intrflag = 1

}

Int task1 ()
{

........interrupt initializations
........interrupt enable

While (1)
{
Printk ("Inside while 1\n");
If (intrflag) { do something ..... ;
Intrflag=0;
}
}
}


Observations
============
In scenario 2 , if I put printk inside while 1 everything is working
correctly.. Intr is generated,handled, while 1 loop inside task1 is
called and intrflag is cleared and remains in while 1 loop Until next
interrupt situation occurs.

In scenario 1 , if I miss printk in while 1 loop , first interrupt is
occurred, interrupt handled and the task1 while 1 is not called again
..
Have you tried dissassembling the functions in both cases to see if
there is something different produced by the compiler ?

This suspiciously looks like code compiled out because it thinks
intrflag will never be 1. Have you tried adding 'volatile' to intrflag
like Al suggested ?

Your task is also busy-waiting on a flag, which is extremely
inneficient: you should really use a semaphore instead.



Best regards
Mahendravarman Rajarao



-----Original Message-----
From: Stephens, Allan [mailto:allan.stephens(a)windriver.com]
Sent: Friday, August 26, 2016 12:25 AM
To: Mahendravarman Rajarao (RBEI/EAA3) <Mahendravarman.Rajarao(a)in.bosch.com>; devel(a)lists.zephyrproject.org
Subject: RE: [devel] Re: System Design - Need feedback from developers

Mahendravarman Rajarao wrote:

-----Original Message-----
From: Mahendravarman Rajarao (RBEI/EAA3)
[mailto:Mahendravarman.Rajarao(a)in.bosch.com]
Sent: August-25-16 2:34 PM
To: Stephens, Allan; devel(a)lists.zephyrproject.org
Subject: RE: [devel] Re: System Design - Need feedback from developers

Hi Allan

Please help me to clarify the below behavior of zephyr.

Program feature:
One zephyr task named task1 and one interrupt handler.

Scenario 1 :
=========
Int intflag = 0;

void interrupt_handler()
{
Printk ("interrupt handled \n");
------- set intrflag = 1

}

Int task1 ()
{

........interrupt initializations
........interrupt enable

While (1)
{
If (intrflag) { do something }
}
}


Scenario 2 :
========
Int intflag = 0;

void interrupt_handler()
{

Printk ("interrupt handled \n");
------- set intrflag = 1

}

Int task1 ()
{

........interrupt initializations
........interrupt enable

While (1)
{
Printk ("Inside while 1\n");
If (intrflag) { do something }
}
}


Observation on scenario 1
===================
When first time interrupt occurs, the printk inside interrupt handler
is occurring and the program does not return to task1.

Observation on scenario 2
=====================
When first time interrupt occurs, the printk inside interrupt handler
is occurring and the program returns to main, prints the printk in
while loop and handles the flag If further interrupt occurs also the
program works correctly

How the printk inside the task1 helps the zephyr scheduler to schedule
the
task1 correctly in case of scenario2 ? what problem is caused in scenario 1 ?
One potential problem with your scenario 1 is that task1 is going to enter a tight loop once the first interrupt happens. That is, it's going to see the flag set, do the work, then immediately see the flag set again, do the work again, and so on. This means you're not giving the rest of the system a chance to do any work. With scenario 2 the printk done by task 1 might be providing a bit of breathing room to allow other things to happen. ... I admit that this wouldn't explain why you wouldn't see multiple printk's from the interrupt handler in scenario 1, though. I suppose it depends on what the "do something" step involves ... if it's disabling and re-enabling interrupts maybe that might explain it.

A colleague of mine asked when the flag was being reset to 0. Is that something that "do something" is supposed to be doing? He also said you might need to mark the flag as "volatile" to ensure the compiler causes it re-read the variable each time through the loop.

-- Al

I knew this problem can be solved by a semaphore.. but still curious
to know

Please clarify


Best regards

Mahendravarman Rajarao




-----Original Message-----
From: Stephens, Allan [mailto:allan.stephens(a)windriver.com]
Sent: Wednesday, August 03, 2016 6:58 PM
To: Mahendravarman Rajarao (RBEI/EAA3)
<Mahendravarman.Rajarao(a)in.bosch.com>; devel(a)lists.zephyrproject.org
Subject: [devel] Re: System Design - Need feedback from developers

Mahendravarman Rajarao wrote:

-----Original Message-----
From: Mahendravarman Rajarao (RBEI/EAA3)
[mailto:Mahendravarman.Rajarao(a)in.bosch.com]
Sent: August-03-16 1:20 AM
To: Stephens, Allan; devel(a)lists.zephyrproject.org
Subject: RE: [devel] System Design - Need feedback from developers

Hi Al

Please Clarify the below line

"certain types of object (for example, mailboxes) cannot be used by
interrupt handlers"

1. I have created a Mailbox inside TASK_A. ( taska_mailbox) 2. I
get an interrupt.. In interrupt call back Can I use
task_mailbox_put call to put some data into the taska_mailbox ??
Will Task_A take the data and perform the necessary actions ?
OR I can't use even task_mailbox_put inside interrupt handlers ??
You can't make *any* use of mailboxes from an interrupt handler. To
quote from the "Mailboxes: Concepts" section of the Zephyr Kernel Primer:

"A mailbox allows tasks to exchange messages. A task that sends a
message is known as the sending task, while a task that receives the
message is known as the receiving task. Messages may not be sent or
received by fibers or ISRs, ..."

If you want the interrupt handler to send data to a task, you can use
a nanokernel FIFO to do this. However, your code may need to create a
pool of "message items" that can be queued by the FIFO, in which case
you'll need to ensure the interrupt handler doesn't re-use an item
from the pool unless it has been dequeued and completely processed by the task.

Regards,
Al




Best regards

Mahendravarman Rajarao
RBEI/EAA



-----Original Message-----
From: Stephens, Allan [mailto:allan.stephens(a)windriver.com]
Sent: Wednesday, August 03, 2016 1:10 AM
To: Mahendravarman Rajarao (RBEI/EAA3)
<Mahendravarman.Rajarao(a)in.bosch.com>;
devel(a)lists.zephyrproject.org
Subject: RE: [devel] System Design - Need feedback from developers

See responses below:

-----Original Message-----
From: Mahendravarman rajarao
[mailto:mahendravarman.rajarao(a)in.bosch.com]
Sent: August-01-16 2:49 PM
To: devel(a)lists.zephyrproject.org
Subject: [devel] System Design - Need feedback from developers

Hi

Need clarifications on the system design , Consider the following
example

1. There is a main task named Main_task 2. There are two tasks
TASK_A and TASK_B .. Both these tasks are stared from the Main_task 3.
Main_Task is of higher priority.. Then comes TASK_A priority and
TASK_B priority 4. There is an shared Interrupt with callback
function

Which of the following method best suites for Zephyr environment
with RTOS scheduler ?

1. When Interrupt occurs set a flag in the Intr callback. In the
Main_Task that flags are maintained and

corresponding functions in the TASK_A and TASK_B are called ..

2. Initialize a mailbox in TASK_A and a mailbox for TASK_B . When
Interrupt occurs.. put the message into the TASK_A mailbox and
TASK_B mailbox
based on the message, certains functionality will be execute in
TASK_A and TASK_B

Which design can be used such that RTOS schedules the tasks
properly based on interrupt ?
Is both methods are same w.r.t schdueling or any difference is there ?

Please help
If I understand correctly, you're saying that you've got an
interrupt handler
(ISR) that needs to be able to inform one or more tasks of work that
needs to be done. The standard way of doing this is to have a set of
kernel synchronization objects or kernel data passing objects that
the ISR uses to notify the tasks what they need to do, and have the
tasks wait on these objects. For example, you might have the
following
arrangement:

- TASK_B waits on semaphore B.
- TASK_A waits on semaphore A.
- Main_Task waits on semaphore Main.
- The ISR handles an interrupt, then gives semaphore B, A, or Main
-- or a combination of these -- based on what work it requires the
task(s) to
do.
- The kernel scheduler will then schedule the tasks according to
their
priority.
That is, if Main_Task has work to do it will run first; otherwise,
TASK_A will run if it has work to do; otherwise, TASK _B will run.

Zephyr has a variety of kernel objects that the ISR can use to
notify the
tasks.
If it simply needs to tell a task to "go", you can use a nanokernel
semaphore, a microkernel semaphore, or a microkernel event object.
If it needs to pass additional data to the task, you can use a nanokernel FIFO.

The Zephyr Kernel Primer provides more information about the various
nanokernel and microkernel object types that are available for
synchronization and data passing. However, be sure to note that
certain types of object (for example, mailboxes) cannot be used by
interrupt handlers, which means they won't be suitable for your needs.

Regards,
Al
--
Benjamin Walsh, SMTS
Wind River Rocket
www.windriver.com
Zephyr kernel maintainer
www.zephyrproject.org


Atomicity in GPIO pin changes

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

Hi

I have a hardware register I want to change individual bits in as they
are used for different purposes on my SoC. I thought the GPIO APIs might
be the correct abstraction to represent that, and even if that wasn't
suitable I thought I could at least look at those to work out how
atomicity of updates is achieved (Zephyr doesn't seem to have spinlocks,
and mutexes and the like seem a bit heavyweight for the task, ...).

However, looking at the GPIO API's and various implementations I can't
spot anything that serialises register updates, it just seems to boil
down to an unsafe "port |= (1 << bit_to_set)" or similar. Have I missed
things or is it expected that all users of a given port agree on a
mutual exclusion method? That doesn't seem very practical if they are
each different drivers or apps with no real need to know of each others
existence.

--
Tixy


Re: having trouble getting the echo client to work using TCP/uIP on K64F

Rohit Grover
 

Paul,

It is useful to work our way through the core BSD socket API in the context of Z-uIP.

Let's take connect(). Assuming that a net_context has been setup, connect() can be implemented using the snippet:

net_context_tcp_init(net_context, NULL /* bp */, NET_TCP_TYPE_CLIENT);
while ((status = net_context_get_connection_status(unicast)) != 0) {
fiber_sleep(SOME_SMALL_DURATION);
}

We're passing `bp' as NULL, but it seems un-necessary for net_context_init() to require a bp. This leads us to commit 61edc68c, by Jukka, where many of the APIs suddenly acquired an additional 'bp' parameter. In some cases, this led to code which I'm having trouble understanding. , I've attached the diff, but I'll highlight a snippet. Take the case of tcpip_poll_tcp(), which is responsible for sending out the initial SYN packet.

@@ -837,12 +837,18 @@ tcpip_poll_udp(struct uip_udp_conn *conn)
/*---------------------------------------------------------------------------*/
#if UIP_TCP
void
-tcpip_poll_tcp(struct uip_conn *conn)
+tcpip_poll_tcp(struct uip_conn *conn, struct net_buf *data_buf)
{
/* We are sending here the initial SYN */
struct net_buf *buf = ip_buf_get_tx(conn->appstate.state);
- uip_set_conn(buf) = conn;
- conn->buf = ip_buf_ref(buf);
+ uip_set_conn(data_buf) = conn;
+
+ /* The conn->buf will be freed after we have established the connection,
+ * sent the message and received an ack to it. This will happen in
+ * net_core.c:net_send().
+ */
+ conn->buf = ip_buf_ref(data_buf);
+
process_post_synch(&tcpip_process, TCP_POLL, conn, buf);
}

Here we see that we acquire a buf to send out a 'SYN' (refer to ip_buf_get_tx(...) above), but whereas previously we would associate it with the new connection and have its ref-count bumped, we now do those things for the 'data_buf' instead. This is a bit confusing. I don't see why the handling of the SYN buf needed to be changed.

Rohit.

-----Original Message-----
> From: Paul Sokolovsky [mailto:paul.sokolovsky(a)linaro.org]
> Sent: 26 August 2016 00:57
> To: Rohit Grover
> Cc: devel(a)lists.zephyrproject.org; Jukka Rissanen
> Subject: Re: having trouble getting the echo client to work using TCP/uIP on
> K64F
>
> On Fri, 26 Aug 2016 01:07:29 +0300
> Paul Sokolovsky <Paul.Sokolovsky(a)linaro.org> wrote:
>
> Some more info: Issues with IPv4/TCP can be seen building echo_server with
> microkernel - making a TCP connection in this case hard locks-up QEMU VM,
> not even pings work. Nothing special in the logging. However with
> nanokernel, everything works, and send (reply) path doesn't involve
> net_tx_fiber:
>
> Received packet 0x0010a4d0 len 7
> receive: tcp received 7 bytes data
> net: tcp_prepare_and_send (0010d27c): Packet output len 47
> net: net_driver_slip_send (0010d27c): Sending 47 bytes, application data 7
> bytes
>
>
>
> > On Mon, 22 Aug 2016 14:58:11 +0000
> > Rohit Grover <Rohit.Grover(a)arm.com> wrote:
> >
> > > With my recent changes, I
> > > manage to get the first packet bounce back successfully to the
> > > echo-client. Successive packets aren't getting processed on their
> > > way out from the client.
> >
> > I'm happy to report that I now see this too. Specifically, if using
> > net_context_get()+net_send() (implicit connection establishment), data
> > in first net_send() gets delivered (I see it in netcat), but not in
> > subsequent calls to net_send().
> >
> > I'm however interested to emulate standard socket API paradigm, where
> > you get all the standard and important calls like connect(), listen(),
> > etc. For this, I explicitly call net_context_tcp_init(ctx, NULL,
> > NET_TCP_TYPE_CLIENT) to emulate connect(). As netbuf is NULL in this
> > call, only SYN/ACK handshake happens (with retries, just as you
> > describe), and then first call
> > net_send() doesn't send anything on wire. With logging it looks like:
> >
> > >>> s.connect(("192.0.2.1", 8083))
> > resolved: 192.0.2.1
> > net: net_driver_slip_send (001349e0): Sending 40 bytes, application
> > data 0 bytes net: net_rx_fiber (001363e0): Received buf 0012c600
> > ret=0
> > >>> net: net_rx_fiber (001363e0): Received buf 0012d0f0
> > net: net_rx_fiber (001363e0): Received buf 0012b598
> > net: net_driver_slip_send (001363e0): Sending 40 bytes, application
> > data 0 bytes
> >
> > >>> s.send("GET / HTTP/1.0\r\n")
> > net: net_send (001349e0): context 0012dfa0 buf 00129a38 status 0
> > net: net_tx_fiber (00135fe0): Sending (buf 00129a38, len 56) to IP
> > stack 0
> > >>>
> >
> > So, the difference is clear: SYN/ACK stuff goes to
> > net_driver_slip_send(), but real app data get stuck in net_tx_fiber().
> >
> > I apply all your 3 patches, and they don't help.
> >
> >
> > >
> > > I find that uip_process() isn't getting called on successive
> > > packets. It gets called for the first packet due to some
> > > retransmission timer. The recently made change to eventhandler() in
> > > tcpip.c (https://gerrit.zephyrproject.org/r/#/c/4050/) makes things
> > > worse because the code meant to refresh certain periodic timers gets
> > > skipped.
> > >
> > > These issues seem to arise from uIP. I would appreciate some help
> > > from people who ported uIP to zephyr. I believe the problems will
> > > surface if someone tries a TCP/IPV4 stream.
> > >
> > > rohit
> >
>
>
>
> --
> 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

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.


Re: System Design - Need feedback from developers

Mahendravarman Rajarao (RBEI/EAA3) <Mahendravarman.Rajarao@...>
 

Hi Allan

Sorry I missed the line intrflag= 0 when typing the scenario
Please see the corrected scenario's

Scenario 1 :
=========
Int intflag = 0;

void interrupt_handler()
{
Printk ("interrupt handled \n");
------- set intrflag = 1

}

Int task1 ()
{

........interrupt initializations
........interrupt enable

While (1)
{
If (intrflag) { do something ..... ;
Intrflag=0;
} }
}


Scenario 2 :
========
Int intflag = 0;

void interrupt_handler()
{

Printk ("interrupt handled \n");
------- set intrflag = 1

}

Int task1 ()
{

........interrupt initializations
........interrupt enable

While (1)
{
Printk ("Inside while 1\n");
If (intrflag) { do something ..... ;
Intrflag=0;
}
}
}


Observations
============
In scenario 2 , if I put printk inside while 1 everything is working correctly.. Intr is generated,handled, while 1 loop inside task1 is called and intrflag is cleared and remains in while 1 loop
Until next interrupt situation occurs.

In scenario 1 , if I miss printk in while 1 loop , first interrupt is occurred, interrupt handled and the task1 while 1 is not called again ..


Best regards
Mahendravarman Rajarao

-----Original Message-----
From: Stephens, Allan [mailto:allan.stephens(a)windriver.com]
Sent: Friday, August 26, 2016 12:25 AM
To: Mahendravarman Rajarao (RBEI/EAA3) <Mahendravarman.Rajarao(a)in.bosch.com>; devel(a)lists.zephyrproject.org
Subject: RE: [devel] Re: System Design - Need feedback from developers

Mahendravarman Rajarao wrote:

-----Original Message-----
From: Mahendravarman Rajarao (RBEI/EAA3)
[mailto:Mahendravarman.Rajarao(a)in.bosch.com]
Sent: August-25-16 2:34 PM
To: Stephens, Allan; devel(a)lists.zephyrproject.org
Subject: RE: [devel] Re: System Design - Need feedback from developers

Hi Allan

Please help me to clarify the below behavior of zephyr.

Program feature:
One zephyr task named task1 and one interrupt handler.

Scenario 1 :
=========
Int intflag = 0;

void interrupt_handler()
{
Printk ("interrupt handled \n");
------- set intrflag = 1

}

Int task1 ()
{

........interrupt initializations
........interrupt enable

While (1)
{
If (intrflag) { do something }
}
}


Scenario 2 :
========
Int intflag = 0;

void interrupt_handler()
{

Printk ("interrupt handled \n");
------- set intrflag = 1

}

Int task1 ()
{

........interrupt initializations
........interrupt enable

While (1)
{
Printk ("Inside while 1\n");
If (intrflag) { do something }
}
}


Observation on scenario 1
===================
When first time interrupt occurs, the printk inside interrupt handler
is occurring and the program does not return to task1.

Observation on scenario 2
=====================
When first time interrupt occurs, the printk inside interrupt handler
is occurring and the program returns to main, prints the printk in
while loop and handles the flag If further interrupt occurs also the
program works correctly

How the printk inside the task1 helps the zephyr scheduler to schedule
the
task1 correctly in case of scenario2 ? what problem is caused in scenario 1 ?
One potential problem with your scenario 1 is that task1 is going to enter a tight loop once the first interrupt happens. That is, it's going to see the flag set, do the work, then immediately see the flag set again, do the work again, and so on. This means you're not giving the rest of the system a chance to do any work. With scenario 2 the printk done by task 1 might be providing a bit of breathing room to allow other things to happen. ... I admit that this wouldn't explain why you wouldn't see multiple printk's from the interrupt handler in scenario 1, though. I suppose it depends on what the "do something" step involves ... if it's disabling and re-enabling interrupts maybe that might explain it.

A colleague of mine asked when the flag was being reset to 0. Is that something that "do something" is supposed to be doing? He also said you might need to mark the flag as "volatile" to ensure the compiler causes it re-read the variable each time through the loop.

-- Al

I knew this problem can be solved by a semaphore.. but still curious
to know

Please clarify


Best regards

Mahendravarman Rajarao




-----Original Message-----
From: Stephens, Allan [mailto:allan.stephens(a)windriver.com]
Sent: Wednesday, August 03, 2016 6:58 PM
To: Mahendravarman Rajarao (RBEI/EAA3)
<Mahendravarman.Rajarao(a)in.bosch.com>; devel(a)lists.zephyrproject.org
Subject: [devel] Re: System Design - Need feedback from developers

Mahendravarman Rajarao wrote:

-----Original Message-----
From: Mahendravarman Rajarao (RBEI/EAA3)
[mailto:Mahendravarman.Rajarao(a)in.bosch.com]
Sent: August-03-16 1:20 AM
To: Stephens, Allan; devel(a)lists.zephyrproject.org
Subject: RE: [devel] System Design - Need feedback from developers

Hi Al

Please Clarify the below line

"certain types of object (for example, mailboxes) cannot be used by
interrupt handlers"

1. I have created a Mailbox inside TASK_A. ( taska_mailbox) 2. I
get an interrupt.. In interrupt call back Can I use
task_mailbox_put call to put some data into the taska_mailbox ??
Will Task_A take the data and perform the necessary actions ?
OR I can't use even task_mailbox_put inside interrupt handlers ??
You can't make *any* use of mailboxes from an interrupt handler. To
quote from the "Mailboxes: Concepts" section of the Zephyr Kernel Primer:

"A mailbox allows tasks to exchange messages. A task that sends a
message is known as the sending task, while a task that receives the
message is known as the receiving task. Messages may not be sent or
received by fibers or ISRs, ..."

If you want the interrupt handler to send data to a task, you can use
a nanokernel FIFO to do this. However, your code may need to create a
pool of "message items" that can be queued by the FIFO, in which case
you'll need to ensure the interrupt handler doesn't re-use an item
from the pool unless it has been dequeued and completely processed by the task.

Regards,
Al




Best regards

Mahendravarman Rajarao
RBEI/EAA



-----Original Message-----
From: Stephens, Allan [mailto:allan.stephens(a)windriver.com]
Sent: Wednesday, August 03, 2016 1:10 AM
To: Mahendravarman Rajarao (RBEI/EAA3)
<Mahendravarman.Rajarao(a)in.bosch.com>;
devel(a)lists.zephyrproject.org
Subject: RE: [devel] System Design - Need feedback from developers

See responses below:

-----Original Message-----
From: Mahendravarman rajarao
[mailto:mahendravarman.rajarao(a)in.bosch.com]
Sent: August-01-16 2:49 PM
To: devel(a)lists.zephyrproject.org
Subject: [devel] System Design - Need feedback from developers

Hi

Need clarifications on the system design , Consider the following
example

1. There is a main task named Main_task 2. There are two tasks
TASK_A and TASK_B .. Both these tasks are stared from the Main_task 3.
Main_Task is of higher priority.. Then comes TASK_A priority and
TASK_B priority 4. There is an shared Interrupt with callback
function

Which of the following method best suites for Zephyr environment
with RTOS scheduler ?

1. When Interrupt occurs set a flag in the Intr callback. In the
Main_Task that flags are maintained and

corresponding functions in the TASK_A and TASK_B are called ..

2. Initialize a mailbox in TASK_A and a mailbox for TASK_B . When
Interrupt occurs.. put the message into the TASK_A mailbox and
TASK_B mailbox
based on the message, certains functionality will be execute in
TASK_A and TASK_B

Which design can be used such that RTOS schedules the tasks
properly based on interrupt ?
Is both methods are same w.r.t schdueling or any difference is there ?

Please help
If I understand correctly, you're saying that you've got an
interrupt handler
(ISR) that needs to be able to inform one or more tasks of work that
needs to be done. The standard way of doing this is to have a set of
kernel synchronization objects or kernel data passing objects that
the ISR uses to notify the tasks what they need to do, and have the
tasks wait on these objects. For example, you might have the
following
arrangement:

- TASK_B waits on semaphore B.
- TASK_A waits on semaphore A.
- Main_Task waits on semaphore Main.
- The ISR handles an interrupt, then gives semaphore B, A, or Main
-- or a combination of these -- based on what work it requires the
task(s) to
do.
- The kernel scheduler will then schedule the tasks according to
their
priority.
That is, if Main_Task has work to do it will run first; otherwise,
TASK_A will run if it has work to do; otherwise, TASK _B will run.

Zephyr has a variety of kernel objects that the ISR can use to
notify the
tasks.
If it simply needs to tell a task to "go", you can use a nanokernel
semaphore, a microkernel semaphore, or a microkernel event object.
If it needs to pass additional data to the task, you can use a nanokernel FIFO.

The Zephyr Kernel Primer provides more information about the various
nanokernel and microkernel object types that are available for
synchronization and data passing. However, be sure to note that
certain types of object (for example, mailboxes) cannot be used by
interrupt handlers, which means they won't be suitable for your needs.

Regards,
Al


Re: having trouble getting the echo client to work using TCP/uIP on K64F

Paul Sokolovsky
 

On Fri, 26 Aug 2016 01:07:29 +0300
Paul Sokolovsky <Paul.Sokolovsky(a)linaro.org> wrote:

Some more info: Issues with IPv4/TCP can be seen building echo_server
with microkernel - making a TCP connection in this case hard locks-up
QEMU VM, not even pings work. Nothing special in the logging. However
with nanokernel, everything works, and send (reply) path doesn't
involve net_tx_fiber:

Received packet 0x0010a4d0 len 7
receive: tcp received 7 bytes data
net: tcp_prepare_and_send (0010d27c): Packet output len 47
net: net_driver_slip_send (0010d27c): Sending 47 bytes, application data 7 bytes



On Mon, 22 Aug 2016 14:58:11 +0000
Rohit Grover <Rohit.Grover(a)arm.com> wrote:

With my recent changes, I
manage to get the first packet bounce back successfully to the
echo-client. Successive packets aren't getting processed on their
way out from the client.
I'm happy to report that I now see this too. Specifically, if using
net_context_get()+net_send() (implicit connection establishment), data
in first net_send() gets delivered (I see it in netcat), but not in
subsequent calls to net_send().

I'm however interested to emulate standard socket API paradigm, where
you get all the standard and important calls like connect(), listen(),
etc. For this, I explicitly call
net_context_tcp_init(ctx, NULL, NET_TCP_TYPE_CLIENT) to emulate
connect(). As netbuf is NULL in this call, only SYN/ACK handshake
happens (with retries, just as you describe), and then first call
net_send() doesn't send anything on wire. With logging it looks like:

s.connect(("192.0.2.1", 8083))
resolved: 192.0.2.1
net: net_driver_slip_send (001349e0): Sending 40 bytes, application
data 0 bytes net: net_rx_fiber (001363e0): Received buf 0012c600
ret=0
net: net_rx_fiber (001363e0): Received buf 0012d0f0
net: net_rx_fiber (001363e0): Received buf 0012b598
net: net_driver_slip_send (001363e0): Sending 40 bytes, application
data 0 bytes

s.send("GET / HTTP/1.0\r\n")
net: net_send (001349e0): context 0012dfa0 buf 00129a38 status 0
net: net_tx_fiber (00135fe0): Sending (buf 00129a38, len 56) to IP
stack 0
So, the difference is clear: SYN/ACK stuff goes to
net_driver_slip_send(), but real app data get stuck in net_tx_fiber().

I apply all your 3 patches, and they don't help.



I find that uip_process() isn't getting called on successive
packets. It gets called for the first packet due to some
retransmission timer. The recently made change to eventhandler() in
tcpip.c (https://gerrit.zephyrproject.org/r/#/c/4050/) makes things
worse because the code meant to refresh certain periodic timers gets
skipped.

These issues seem to arise from uIP. I would appreciate some help
from people who ported uIP to zephyr. I believe the problems will
surface if someone tries a TCP/IPV4 stream.

rohit


--
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


Re: having trouble getting the echo client to work using TCP/uIP on K64F

Paul Sokolovsky
 

On Mon, 22 Aug 2016 14:58:11 +0000
Rohit Grover <Rohit.Grover(a)arm.com> wrote:

With my recent changes, I
manage to get the first packet bounce back successfully to the
echo-client. Successive packets aren't getting processed on their way
out from the client.
I'm happy to report that I now see this too. Specifically, if using
net_context_get()+net_send() (implicit connection establishment), data
in first net_send() gets delivered (I see it in netcat), but not in
subsequent calls to net_send().

I'm however interested to emulate standard socket API paradigm, where
you get all the standard and important calls like connect(), listen(),
etc. For this, I explicitly call
net_context_tcp_init(ctx, NULL, NET_TCP_TYPE_CLIENT) to emulate
connect(). As netbuf is NULL in this call, only SYN/ACK handshake
happens (with retries, just as you describe), and then first call
net_send() doesn't send anything on wire. With logging it looks like:

s.connect(("192.0.2.1", 8083))
resolved: 192.0.2.1
net: net_driver_slip_send (001349e0): Sending 40 bytes, application data 0 bytes
net: net_rx_fiber (001363e0): Received buf 0012c600
ret=0
net: net_rx_fiber (001363e0): Received buf 0012d0f0
net: net_rx_fiber (001363e0): Received buf 0012b598
net: net_driver_slip_send (001363e0): Sending 40 bytes, application data 0 bytes

s.send("GET / HTTP/1.0\r\n")
net: net_send (001349e0): context 0012dfa0 buf 00129a38 status 0
net: net_tx_fiber (00135fe0): Sending (buf 00129a38, len 56) to IP stack
0
So, the difference is clear: SYN/ACK stuff goes to
net_driver_slip_send(), but real app data get stuck in net_tx_fiber().

I apply all your 3 patches, and they don't help.



I find that uip_process() isn't getting called on successive packets.
It gets called for the first packet due to some retransmission timer.
The recently made change to eventhandler() in tcpip.c
(https://gerrit.zephyrproject.org/r/#/c/4050/) makes things worse
because the code meant to refresh certain periodic timers gets
skipped.

These issues seem to arise from uIP. I would appreciate some help
from people who ported uIP to zephyr. I believe the problems will
surface if someone tries a TCP/IPV4 stream.

rohit
--
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


Re: System Design - Need feedback from developers

Stephens, Allan
 

Mahendravarman Rajarao wrote:

-----Original Message-----
From: Mahendravarman Rajarao (RBEI/EAA3)
[mailto:Mahendravarman.Rajarao(a)in.bosch.com]
Sent: August-25-16 2:34 PM
To: Stephens, Allan; devel(a)lists.zephyrproject.org
Subject: RE: [devel] Re: System Design - Need feedback from developers

Hi Allan

Please help me to clarify the below behavior of zephyr.

Program feature:
One zephyr task named task1 and one interrupt handler.

Scenario 1 :
=========
Int intflag = 0;

void interrupt_handler()
{
Printk ("interrupt handled \n");
------- set intrflag = 1

}

Int task1 ()
{

........interrupt initializations
........interrupt enable

While (1)
{
If (intrflag) { do something }
}
}


Scenario 2 :
========
Int intflag = 0;

void interrupt_handler()
{

Printk ("interrupt handled \n");
------- set intrflag = 1

}

Int task1 ()
{

........interrupt initializations
........interrupt enable

While (1)
{
Printk ("Inside while 1\n");
If (intrflag) { do something }
}
}


Observation on scenario 1
===================
When first time interrupt occurs, the printk inside interrupt handler is
occurring and the program does not return to task1.

Observation on scenario 2
=====================
When first time interrupt occurs, the printk inside interrupt handler is
occurring and the program returns to main, prints the printk in while loop and
handles the flag
If further interrupt occurs also the program works correctly

How the printk inside the task1 helps the zephyr scheduler to schedule the
task1 correctly in case of scenario2 ? what problem is caused in scenario 1 ?
One potential problem with your scenario 1 is that task1 is going to enter a tight loop once the first interrupt happens. That is, it's going to see the flag set, do the work, then immediately see the flag set again, do the work again, and so on. This means you're not giving the rest of the system a chance to do any work. With scenario 2 the printk done by task 1 might be providing a bit of breathing room to allow other things to happen. ... I admit that this wouldn't explain why you wouldn't see multiple printk's from the interrupt handler in scenario 1, though. I suppose it depends on what the "do something" step involves ... if it's disabling and re-enabling interrupts maybe that might explain it.

A colleague of mine asked when the flag was being reset to 0. Is that something that "do something" is supposed to be doing? He also said you might need to mark the flag as "volatile" to ensure the compiler causes it re-read the variable each time through the loop.

-- Al

I knew this problem can be solved by a semaphore.. but still curious to know

Please clarify


Best regards

Mahendravarman Rajarao




-----Original Message-----
From: Stephens, Allan [mailto:allan.stephens(a)windriver.com]
Sent: Wednesday, August 03, 2016 6:58 PM
To: Mahendravarman Rajarao (RBEI/EAA3)
<Mahendravarman.Rajarao(a)in.bosch.com>; devel(a)lists.zephyrproject.org
Subject: [devel] Re: System Design - Need feedback from developers

Mahendravarman Rajarao wrote:

-----Original Message-----
From: Mahendravarman Rajarao (RBEI/EAA3)
[mailto:Mahendravarman.Rajarao(a)in.bosch.com]
Sent: August-03-16 1:20 AM
To: Stephens, Allan; devel(a)lists.zephyrproject.org
Subject: RE: [devel] System Design - Need feedback from developers

Hi Al

Please Clarify the below line

"certain types of object (for example, mailboxes) cannot be used by
interrupt handlers"

1. I have created a Mailbox inside TASK_A. ( taska_mailbox) 2. I get
an interrupt.. In interrupt call back Can I use task_mailbox_put
call to put some data into the taska_mailbox ?? Will Task_A take the
data and perform the necessary actions ?
OR I can't use even task_mailbox_put inside interrupt handlers ??
You can't make *any* use of mailboxes from an interrupt handler. To quote
from the "Mailboxes: Concepts" section of the Zephyr Kernel Primer:

"A mailbox allows tasks to exchange messages. A task that sends a message
is known as the sending task, while a task that receives the message is
known as the receiving task. Messages may not be sent or received by fibers
or ISRs, ..."

If you want the interrupt handler to send data to a task, you can use a
nanokernel FIFO to do this. However, your code may need to create a pool of
"message items" that can be queued by the FIFO, in which case you'll need
to ensure the interrupt handler doesn't re-use an item from the pool unless
it has been dequeued and completely processed by the task.

Regards,
Al




Best regards

Mahendravarman Rajarao
RBEI/EAA



-----Original Message-----
From: Stephens, Allan [mailto:allan.stephens(a)windriver.com]
Sent: Wednesday, August 03, 2016 1:10 AM
To: Mahendravarman Rajarao (RBEI/EAA3)
<Mahendravarman.Rajarao(a)in.bosch.com>;
devel(a)lists.zephyrproject.org
Subject: RE: [devel] System Design - Need feedback from developers

See responses below:

-----Original Message-----
From: Mahendravarman rajarao
[mailto:mahendravarman.rajarao(a)in.bosch.com]
Sent: August-01-16 2:49 PM
To: devel(a)lists.zephyrproject.org
Subject: [devel] System Design - Need feedback from developers

Hi

Need clarifications on the system design , Consider the following
example

1. There is a main task named Main_task 2. There are two tasks
TASK_A and TASK_B .. Both these tasks are stared from the Main_task 3.
Main_Task is of higher priority.. Then comes TASK_A priority and
TASK_B priority 4. There is an shared Interrupt with callback
function

Which of the following method best suites for Zephyr environment
with RTOS scheduler ?

1. When Interrupt occurs set a flag in the Intr callback. In the
Main_Task that flags are maintained and

corresponding functions in the TASK_A and TASK_B are called ..

2. Initialize a mailbox in TASK_A and a mailbox for TASK_B . When
Interrupt occurs.. put the message into the TASK_A mailbox and
TASK_B mailbox
based on the message, certains functionality will be execute in
TASK_A and TASK_B

Which design can be used such that RTOS schedules the tasks properly
based on interrupt ?
Is both methods are same w.r.t schdueling or any difference is there ?

Please help
If I understand correctly, you're saying that you've got an interrupt
handler
(ISR) that needs to be able to inform one or more tasks of work that
needs to be done. The standard way of doing this is to have a set of
kernel synchronization objects or kernel data passing objects that the
ISR uses to notify the tasks what they need to do, and have the tasks
wait on these objects. For example, you might have the following
arrangement:

- TASK_B waits on semaphore B.
- TASK_A waits on semaphore A.
- Main_Task waits on semaphore Main.
- The ISR handles an interrupt, then gives semaphore B, A, or Main --
or a combination of these -- based on what work it requires the task(s) to
do.
- The kernel scheduler will then schedule the tasks according to their
priority.
That is, if Main_Task has work to do it will run first; otherwise,
TASK_A will run if it has work to do; otherwise, TASK _B will run.

Zephyr has a variety of kernel objects that the ISR can use to notify the
tasks.
If it simply needs to tell a task to "go", you can use a nanokernel
semaphore, a microkernel semaphore, or a microkernel event object. If
it needs to pass additional data to the task, you can use a nanokernel FIFO.

The Zephyr Kernel Primer provides more information about the various
nanokernel and microkernel object types that are available for
synchronization and data passing. However, be sure to note that
certain types of object (for example, mailboxes) cannot be used by
interrupt handlers, which means they won't be suitable for your needs.

Regards,
Al

6741 - 6760 of 8054