Date   

Daily Gerrit Digest

donotreply@...
 

NEW within last 24 hours:
- https://gerrit.zephyrproject.org/r/4819 : tests/zoap: Add tests for the observe feature
- https://gerrit.zephyrproject.org/r/4817 : iot/zoap: Add port information to network addresses
- https://gerrit.zephyrproject.org/r/4816 : iot/zoap: Add support for observing resources
- https://gerrit.zephyrproject.org/r/4815 : tests/zoap: Add simple test for retransmission
- https://gerrit.zephyrproject.org/r/4818 : iot/zoap: Add helpers for dealing with integer options
- https://gerrit.zephyrproject.org/r/4814 : iot/zoap: Fix retrieving the token for every reply
- https://gerrit.zephyrproject.org/r/4813 : iot/zoap: Fix subtly wrong indentation
- https://gerrit.zephyrproject.org/r/4812 : x86: introduce new segmentation.h header

UPDATED within last 24 hours:
- https://gerrit.zephyrproject.org/r/4803 : Merge bluetooth branch into master
- https://gerrit.zephyrproject.org/r/4447 : Bluetooth: AVDTP: Module Initialization
- https://gerrit.zephyrproject.org/r/4809 : Bluetooth: Controller: Clean up naming in the HCI driver
- https://gerrit.zephyrproject.org/r/4798 : unified: Enable memory pools in mailbox tests
- https://gerrit.zephyrproject.org/r/4797 : unified: Implement memory pools
- https://gerrit.zephyrproject.org/r/4781 : unified: Enable semaphore group use in test_mail
- https://gerrit.zephyrproject.org/r/4799 : unified: Make memory pool test unified capable
- https://gerrit.zephyrproject.org/r/4779 : unified: Add support for semaphore groups
- https://gerrit.zephyrproject.org/r/4810 : unified: Add _is_next_thread_current()
- https://gerrit.zephyrproject.org/r/4785 : unified: Add timeslice support
- https://gerrit.zephyrproject.org/r/4796 : Bluetooth: L2CAP: Handle security procedure non successful path
- https://gerrit.zephyrproject.org/r/4780 : unified: Fix semaphore group tests
- https://gerrit.zephyrproject.org/r/4777 : unified: Include _timeout structure in tcs_base
- https://gerrit.zephyrproject.org/r/4776 : unified: Conditionally define __printf_like() macro
- https://gerrit.zephyrproject.org/r/4795 : Bluetooth: L2CAP: Refactor handling connection response
- https://gerrit.zephyrproject.org/r/4321 : Bluetooth: BR/EDR: Refactor distribution of security procedure status
- https://gerrit.zephyrproject.org/r/4808 : Bluetooth: L2CAP: Limit user I/O actions timeout in GAP context
- https://gerrit.zephyrproject.org/r/4489 : Bluetooth: SDP: Server: Support ServiceAttrReq and ServiceSearchAttrReq
- https://gerrit.zephyrproject.org/r/4487 : Bluetooth: SDP: Server: Support service record registration
- https://gerrit.zephyrproject.org/r/4488 : Bluetooth: SDP: Server: Support ServiceSearchRequest
- https://gerrit.zephyrproject.org/r/4486 : Bluetooth: SDP: Server: Initialize and accept incoming connections
- https://gerrit.zephyrproject.org/r/4463 : power_mgmt: Update Power Management device driver API
- https://gerrit.zephyrproject.org/r/4677 : ARM: irq: Add _arch_irq_enable_keep external interrupt API
- https://gerrit.zephyrproject.org/r/4679 : ARM: irq: Add _arch_irq_is_enabled external interrupt API
- https://gerrit.zephyrproject.org/r/4678 : irq: Add irq_is_enabled external interrupt API
- https://gerrit.zephyrproject.org/r/4676 : irq: Add irq_enable_keep external interrupt API
- https://gerrit.zephyrproject.org/r/4680 : irq: Add irq_pending_clear external interrupt API
- https://gerrit.zephyrproject.org/r/4662 : irq: Add irq_pending_set external interrupt API
- https://gerrit.zephyrproject.org/r/4682 : irq: Add irq_is_priority_equal external interrupt API
- https://gerrit.zephyrproject.org/r/4784 : unified: Preemption check to include sched lock

MERGED within last 24 hours:
- https://gerrit.zephyrproject.org/r/4820 : trivial: fixed typos
- https://gerrit.zephyrproject.org/r/4811 : known-issues: update rule for TCF summary line
- https://gerrit.zephyrproject.org/r/4687 : arduino 101: make factory bootloader config the default
- https://gerrit.zephyrproject.org/r/4774 : intel_quark: move X86_IAMCU to defconfig


Re: RFC: Extension to External Interrupt API

Chettimada, Vinayak Kariappa
 


OK with this, what's the use-case though?
I am implementing a "work" (tasklet in Linux terms), a "work", being a function/routine, is invoked as a direct call i.e. if the caller is in the same priority as the ISR and the software interrupt (my "work" group) that would have been offloaded to (if were at another priority) is enabled. Hence, the need for irq_is_enabled().
In theory, each h/w interrupt can have separate/own bottom-half "work" group (ISR). Why, to have priority levels for the bottom-halves.


NACK. This isn't easily portable to other arches. You brought this up
as a candidate to replace irq_offload(), but irq_offload() only exists
as a debug feature, so that we can run some unit tests in IRQ context.
Advanced stuff like your needs, do this in your application.


Fine w/this.


NACK, for the same reasons as irq_pending_set().

Andrew
As explained above. Seemed like I was thinking or was inspired by Tasklet, definitely solving my design needs. Some day a device/subsystem will look for a similar solution.

Thinking aloud:
1. driver/interrupt_controller needs unification.
2. Introduce "work" feature now in BLE controller in a separate patch.

-Vinayak


Re: RFC: Extension to External Interrupt API

Chettimada, Vinayak Kariappa
 

Do you have ideas on how this would be implemented for the other
architectures in Zephyr? If we can't have it as a general API, I'm
not really sure I see the value for having it in-tree. All of what
you're doing can (and, I gather, is) doable for specific hardware on a
per-app basis anyway, right?
Yes, for now from the Zephyr source, there is so much duplication, I can do the same thing :-). for example:
drivers/interrupt_controller/exti_stm32.c
drivers/interrupt_controller/arcv2_irq_unit.c
drivers/interrupt_controller/ioapic_intr.c
drivers/interrupt_controller/loapic_intr.c
...

Everything is so wrong or missing for ARM, NVIC should truely be an interrupt_controller driver in Zephyr. May be that is how I should implement for ARM then, may be inconsistent based on NVIC as I see it is so now in the drivers/interrupt_controller for others!. This will make a subsystem like a BLE controller a portability nightmare, unless there is an interrupt controller driver model, is there one? irq.h is the closest i could find.

Honestly it seems like what you have with the BLE work is tied very
closely to your hardware environment, and might need to be generalized
a bit. Can you explain what exactly you need from these features that
you can't get with Zephyr in other ways now? I mean, if your goal
with irq_pending_set() is to just have another interrupt handler
called after the current one completes, can't you implement that with
a function call at the bottom of the ISR? :)
I am trying to generalise. I need a bottom-half, a routine that is scheduled by the top half to be executed later, at a safer time. irq_offload in Zephyr sense, but I really want is Tasklets.

-Vinayak


Re: [RFC]PWM API Update

Liu, Baohong
 

-----Original Message-----
From: Tomasz Bursztyka [mailto:tomasz.bursztyka(a)linux.intel.com]
Sent: Thursday, September 15, 2016 11:41 PM
To: devel(a)lists.zephyrproject.org
Subject: [devel] Re: Re: [RFC]PWM API Update

Hi Baohong,
-----Original Message-----
From: Ross, Andrew J
Sent: Thursday, September 15, 2016 8:04 AM
To: Liu, Baohong <baohong.liu(a)intel.com>;
devel(a)lists.zephyrproject.org
Subject: Re: [devel] [RFC]PWM API Update

Liu, Baohong wrote:
As for the unit for period and pulse width, I understand that both
time
(micro-second) and clock cycles are popularly used. To cater for
this, the above-mentioned API will be expanded into two.

pwm_set_pin_usec(uint8_t pin, uint32_t period_usec, uint32_t
pulse_usec) pwm_set_pin_cycles(uint8_t pin, uint32_t period_cycles,
uint32_t pulse_cycles)
When PWM is used correctly, this shouldn't make any difference at all
because the period will be much, much longer than the underlying
clock (which is the whole point).

Why bother with having two ways to do this when they're going to be
exactly equivalent in all but the weirdest apps? Just set them in
arbitrary units of "cycles". And if an application really, truly
needs to know the underlying cycle time of the hardware (which is
going to be device-dependent), give them an API like
"pwm_get_cycle_time()" which returns a cycle time in picoseconds or
something.
I personally prefer two APIs. Somebody also suggested two APIs in ZEP-745.
Looks two APIs is the way to go so far.
In the end, both do the same, but:

there is actually an implementation issue with pwm_set_pin_usec() as the
driver will have to do calculation according to the underlying hw cycle time.
So this piles up more work in driver side. Though, from user perspective, it
might be simpler to use yes.
(no hand-computation needed from the user).

Actually, with Andy's proposal of providing a pwm_get_cycle_time() along
with pwm_set_pin_cycles(), I believe (tell me if I am wrong) you could
implement
pwm_set_pin_usec() as a generic pwm function instead of a driver API
function.
Sounds like the best option to me: you keep the driver API concise, and you
still end up providing both functions in the end.
I understand what you mean. I compared both methods. In my opinion,
there is no significant difference.

By the way, it looks odd to me to add pwm_get_cycle_time() into PWM driver.
It should be a common utility function instead of a PWM API?

For now, let's go with what Andy and you proposed, unless I hear any strong
objection from others. That's:

pwm_set_pin(struct device *dev, uint8_t pin, uint32_t period_cycles,
uint32_t pulse_cycles); /* PWM API */
get_cycles_per_usec(void); /* we can find better name:) */

As you mentioned, the usec one will be a generic PWM function instead of a API.


Tomasz


Galileo Gen 1 GPIO

Fábio Iaione <fabio.iaione at gmail.com...>
 

Dear Sirs,
I am using Galileo Gen 1 (Cypress I/O expander) and I can not change the GPIO levels.
What GPIO driver should I set in menuconfig tool (DesignWare, PCAL9535, MMIO, Intel SCH)?
What driver name and pin numbers should I use in functions API (gpio_pin_configure, gpio_pin_write, ....)?
Thank you very much.


Re: RFC: Extension to External Interrupt API

Maureen Helm
 

-----Original Message-----
From: Benjamin Walsh [mailto:benjamin.walsh(a)windriver.com]
Sent: Friday, September 16, 2016 11:21 AM
To: Andy Ross <andrew.j.ross(a)intel.com>
Cc: Vinayak Kariappa Chettimada
<vinayak.kariappa.chettimada(a)nordicsemi.no>;
devel(a)lists.zephyrproject.org; Benjamin Walsh
<benjamin.walsh(a)windriver.com>
Subject: [devel] Re: Re: RFC: Extension to External Interrupt API

On Fri, Sep 16, 2016 at 09:06:13AM -0700, Andy Ross wrote:
Benjamin Walsh wrote:
IIUC, he wants to queue work in another interrupt of the same
priority, serve the other interrupts of same priority that are
already pending, and then only execute the work he's queued. Kinda
some sort of cooperative yielding, but at interrupt level. This is
exactly how fibers (cooperative threads) are scheduled in Zephyr
BTW. What he's not getting if was to queue work to fibers instead,
is that when his delayed work would run would be depending on what
work is already being done in a fiber when he handles his interrupt
and what other interrupts of lower priority might be pending.
Does that work? Are pended ARM interrupts really "queued" like that?
If you have multiple pending interrupts of the same priority I'd have
to believe the order of delivery would be arbitrary and
hardware-dependent (i.e. whatever fixed precedence the hardware
designers picked in a mux somewhere).

If that works, then I agree this sounds cool. But my suspicion is
IIRC, you can have sub-priorities on Cortex-M.

Actually:

http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0552a/BAB
HGEAJ.html

http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0552a/Cihe
hdge.html

However, IIRC as well, Zephyr programs the interrupt priorities with 0
subgroups, so that would not work. We could have a config option that asks for
the number of subgroups though, not hard to add.
Agreed. I think subgroups could make that work, but I don't think you have many options when there are only a few priority bits implemented. On the nrf52 you've only got 3 bits implemented, 2 priorities are reserved for the kernel, so I think you can only use one bit for subpriority.

Isn't x86 able to do that as well, in the IDT in each 16-vector block, based on the
vector position within the block ?

that the only promise you get with this irq_pend_set() implementation
is that the IRQ will run at its fixed priority sometime after your
call completes and before ISRs of lower priority or user code get to
run. And if *that's* true then you should be able to just test for
the pending state of those other known IRQs* at the end of your
function and call the one of your choice to get the same behavior.
No?

Andy

* Not ones higher than the current handler, which by definition aren't
pending. And not ones lower than the target which wouldn't run
anyway. That's going to be a small, tractable list. And
importantly one accessible to application code in Zephyr without
exposing ARM's writable interrupt pending bits.


Re: Porting to ARM M0, M0+

Boie, Andrew P
 

Thanks Andrew (and the others who've responded...I'm working w/ 1.5.0 now and anxiously await 1.6! Is there a planned release date for 1.6?
Should be the end of November. We are on a 3 month release cycle.
Work is done out in the open, just clone the 'master' branch of the Zephyr git tree if you want to see the latest and greatest.

Andrew


Re: Porting to ARM M0, M0+

Phil Keating <pkeating@...>
 

Thanks Andrew (and the others who've responded...I'm working w/ 1.5.0 now and anxiously await 1.6! Is there a planned release date for 1.6?


Re: RFC: Extension to External Interrupt API

Benjamin Walsh <benjamin.walsh@...>
 

On Fri, Sep 16, 2016 at 12:20:56PM -0400, Benjamin Walsh wrote:
On Fri, Sep 16, 2016 at 09:06:13AM -0700, Andy Ross wrote:
Benjamin Walsh wrote:
IIUC, he wants to queue work in another interrupt of the same priority,
serve the other interrupts of same priority that are already pending,
and then only execute the work he's queued. Kinda some sort of
cooperative yielding, but at interrupt level. This is exactly how fibers
(cooperative threads) are scheduled in Zephyr BTW. What he's not getting
if was to queue work to fibers instead, is that when his delayed work
would run would be depending on what work is already being done in a
fiber when he handles his interrupt and what other interrupts of lower
priority might be pending.
Does that work? Are pended ARM interrupts really "queued" like that?
If you have multiple pending interrupts of the same priority I'd have
to believe the order of delivery would be arbitrary and
hardware-dependent (i.e. whatever fixed precedence the hardware
designers picked in a mux somewhere).

If that works, then I agree this sounds cool. But my suspicion is
IIRC, you can have sub-priorities on Cortex-M.

Actually:

http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0552a/BABHGEAJ.html

http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0552a/Cihehdge.html

However, IIRC as well, Zephyr programs the interrupt priorities with 0
subgroups, so that would not work. We could have a config option that
asks for the number of subgroups though, not hard to add.

Isn't x86 able to do that as well, in the IDT in each 16-vector block,
based on the vector position within the block ?
Nevermind, INTx is a synchronous trap, doesn't work.


Re: RFC: Extension to External Interrupt API

Boie, Andrew P
 

On Fri, 2016-09-16 at 04:52 +0000, Vinayak Kariappa Chettimada wrote:
Hi,

Welcome your valuable comments on the proposed extension to External
Interrupt API.

*irq_enable_keep*
https://gerrit.zephyrproject.org/r/#/c/4676/1
https://gerrit.zephyrproject.org/r/#/c/4677/1
Fine w/this.

*irq_is_enabled*
https://gerrit.zephyrproject.org/r/#/c/4678/1
https://gerrit.zephyrproject.org/r/#/c/4679/1
OK with this, what's the use-case though?

*irq_pending_set*
https://gerrit.zephyrproject.org/r/#/c/4662/3
https://gerrit.zephyrproject.org/r/#/c/4663/3
NACK. This isn't easily portable to other arches. You brought this up
as a candidate to replace irq_offload(), but irq_offload() only exists
as a debug feature, so that we can run some unit tests in IRQ context.
Advanced stuff like your needs, do this in your application.

*irq_pending_clear*
https://gerrit.zephyrproject.org/r/#/c/4680/1
https://gerrit.zephyrproject.org/r/#/c/4681/1
Fine w/this.

*irq_is_priority_equal*
https://gerrit.zephyrproject.org/r/#/c/4682/2
https://gerrit.zephyrproject.org/r/#/c/4683/2
NACK, for the same reasons as irq_pending_set().

Andrew


Re: RFC: Extension to External Interrupt API

Benjamin Walsh <benjamin.walsh@...>
 

On Fri, Sep 16, 2016 at 09:06:13AM -0700, Andy Ross wrote:
Benjamin Walsh wrote:
IIUC, he wants to queue work in another interrupt of the same priority,
serve the other interrupts of same priority that are already pending,
and then only execute the work he's queued. Kinda some sort of
cooperative yielding, but at interrupt level. This is exactly how fibers
(cooperative threads) are scheduled in Zephyr BTW. What he's not getting
if was to queue work to fibers instead, is that when his delayed work
would run would be depending on what work is already being done in a
fiber when he handles his interrupt and what other interrupts of lower
priority might be pending.
Does that work? Are pended ARM interrupts really "queued" like that?
If you have multiple pending interrupts of the same priority I'd have
to believe the order of delivery would be arbitrary and
hardware-dependent (i.e. whatever fixed precedence the hardware
designers picked in a mux somewhere).

If that works, then I agree this sounds cool. But my suspicion is
IIRC, you can have sub-priorities on Cortex-M.

Actually:

http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0552a/BABHGEAJ.html

http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0552a/Cihehdge.html

However, IIRC as well, Zephyr programs the interrupt priorities with 0
subgroups, so that would not work. We could have a config option that
asks for the number of subgroups though, not hard to add.

Isn't x86 able to do that as well, in the IDT in each 16-vector block,
based on the vector position within the block ?

that the only promise you get with this irq_pend_set() implementation
is that the IRQ will run at its fixed priority sometime after your
call completes and before ISRs of lower priority or user code get to
run. And if *that's* true then you should be able to just test for
the pending state of those other known IRQs* at the end of your
function and call the one of your choice to get the same
behavior. No?

Andy

* Not ones higher than the current handler, which by definition aren't
pending. And not ones lower than the target which wouldn't run
anyway. That's going to be a small, tractable list. And
importantly one accessible to application code in Zephyr without
exposing ARM's writable interrupt pending bits.


Re: RFC: Extension to External Interrupt API

Andy Ross
 

Benjamin Walsh wrote:
IIUC, he wants to queue work in another interrupt of the same priority,
serve the other interrupts of same priority that are already pending,
and then only execute the work he's queued. Kinda some sort of
cooperative yielding, but at interrupt level. This is exactly how fibers
(cooperative threads) are scheduled in Zephyr BTW. What he's not getting
if was to queue work to fibers instead, is that when his delayed work
would run would be depending on what work is already being done in a
fiber when he handles his interrupt and what other interrupts of lower
priority might be pending.
Does that work? Are pended ARM interrupts really "queued" like that?
If you have multiple pending interrupts of the same priority I'd have
to believe the order of delivery would be arbitrary and
hardware-dependent (i.e. whatever fixed precedence the hardware
designers picked in a mux somewhere).

If that works, then I agree this sounds cool. But my suspicion is
that the only promise you get with this irq_pend_set() implementation
is that the IRQ will run at its fixed priority sometime after your
call completes and before ISRs of lower priority or user code get to
run. And if *that's* true then you should be able to just test for
the pending state of those other known IRQs* at the end of your
function and call the one of your choice to get the same
behavior. No?

Andy

* Not ones higher than the current handler, which by definition aren't
pending. And not ones lower than the target which wouldn't run
anyway. That's going to be a small, tractable list. And
importantly one accessible to application code in Zephyr without
exposing ARM's writable interrupt pending bits.


Re: RFC: Extension to External Interrupt API

Benjamin Walsh <benjamin.walsh@...>
 

On Fri, Sep 16, 2016 at 08:38:35AM -0700, Andy Ross wrote:
Vinayak Kariappa Chettimada wrote:
Welcome your valuable comments on the proposed extension to External
Interrupt API.
As has been mentioned in gerrit, there is worry about the portability
of a lot of this, which is a mostly 1:1 transcription of an ARM
feature as I understand it.

In particular irq_pending_set() seems to be pretty non-standard. Not
all architectures have a visible system-wide interrupt latch (x86
does, but only for external hardware interrupts), and AFAIK only ARM
allows it to be written (x86 can synchronously trigger an interrupt,
which isn't quite the same thing).

Do you have ideas on how this would be implemented for the other
architectures in Zephyr? If we can't have it as a general API, I'm
not really sure I see the value for having it in-tree. All of what
you're doing can (and, I gather, is) doable for specific hardware on a
per-app basis anyway, right?

Honestly it seems like what you have with the BLE work is tied very
closely to your hardware environment, and might need to be generalized
a bit. Can you explain what exactly you need from these features that
you can't get with Zephyr in other ways now? I mean, if your goal
with irq_pending_set() is to just have another interrupt handler
called after the current one completes, can't you implement that with
a function call at the bottom of the ISR? :)
IIUC, he wants to queue work in another interrupt of the same priority,
serve the other interrupts of same priority that are already pending,
and then only execute the work he's queued. Kinda some sort of
cooperative yielding, but at interrupt level. This is exactly how fibers
(cooperative threads) are scheduled in Zephyr BTW. What he's not getting
if was to queue work to fibers instead, is that when his delayed work
would run would be depending on what work is already being done in a
fiber when he handles his interrupt and what other interrupts of lower
priority might be pending.


Daily JIRA Digest

donotreply@...
 

NEW JIRA items within last 24 hours: 1
[ZEP-901] Test
https://jira.zephyrproject.org/browse/ZEP-901


UPDATED JIRA items within last 24 hours: 8
[ZEP-883] IP Stack L2 Interface Management API
https://jira.zephyrproject.org/browse/ZEP-883

[ZEP-885] 802.15.4 - Beacon frame support
https://jira.zephyrproject.org/browse/ZEP-885

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

[ZEP-884] 802.15.4 - CSMA-CA Radio protocol support
https://jira.zephyrproject.org/browse/ZEP-884

[ZEP-328] HW Encryption Abstraction
https://jira.zephyrproject.org/browse/ZEP-328

[ZEP-454] Add driver API reentrancy support to UART shim drivers
https://jira.zephyrproject.org/browse/ZEP-454

[ZEP-248] Add a BOARD/SOC porting guide
https://jira.zephyrproject.org/browse/ZEP-248

[ZEP-854] CoAP with DTLS sample
https://jira.zephyrproject.org/browse/ZEP-854


CLOSED JIRA items within last 24 hours: 0

RESOLVED JIRA items within last 24 hours: 2
[ZEP-788] (Fixed) UDP
https://jira.zephyrproject.org/browse/ZEP-788

[ZEP-698] (Fixed) samples/task_profiler issues
https://jira.zephyrproject.org/browse/ZEP-698


Re: RFC: Extension to External Interrupt API

Andy Ross
 

Vinayak Kariappa Chettimada wrote:
Welcome your valuable comments on the proposed extension to External
Interrupt API.
As has been mentioned in gerrit, there is worry about the portability
of a lot of this, which is a mostly 1:1 transcription of an ARM
feature as I understand it.

In particular irq_pending_set() seems to be pretty non-standard. Not
all architectures have a visible system-wide interrupt latch (x86
does, but only for external hardware interrupts), and AFAIK only ARM
allows it to be written (x86 can synchronously trigger an interrupt,
which isn't quite the same thing).

Do you have ideas on how this would be implemented for the other
architectures in Zephyr? If we can't have it as a general API, I'm
not really sure I see the value for having it in-tree. All of what
you're doing can (and, I gather, is) doable for specific hardware on a
per-app basis anyway, right?

Honestly it seems like what you have with the BLE work is tied very
closely to your hardware environment, and might need to be generalized
a bit. Can you explain what exactly you need from these features that
you can't get with Zephyr in other ways now? I mean, if your goal
with irq_pending_set() is to just have another interrupt handler
called after the current one completes, can't you implement that with
a function call at the bottom of the ISR? :)

Andy


Daily Gerrit Digest

donotreply@...
 

NEW within last 24 hours:
- https://gerrit.zephyrproject.org/r/4797 : unified: Implement memory pools
- https://gerrit.zephyrproject.org/r/4809 : Bluetooth: Controller: Remove traces of "native"
- https://gerrit.zephyrproject.org/r/4810 : unified: Add _is_next_thread_current()
- https://gerrit.zephyrproject.org/r/4808 : Bluetooth: L2CAP: Limit user I/O actions timeout in GAP context
- https://gerrit.zephyrproject.org/r/4803 : Merge bluetooth branch into master
- https://gerrit.zephyrproject.org/r/4807 : net: yaip: tests: Add a simple IEEE 802.15.4 Beacon frame test
- https://gerrit.zephyrproject.org/r/4806 : net: yaip: Add IEEE 802.15.4 Beacon frame validation support
- https://gerrit.zephyrproject.org/r/4800 : unified: fix some leftover K_<obj>_DEFINE macros
- https://gerrit.zephyrproject.org/r/4799 : unified: Make memory pool test unified capable
- https://gerrit.zephyrproject.org/r/4798 : unified: Enable memory pools in mailbox tests

UPDATED within last 24 hours:
- https://gerrit.zephyrproject.org/r/4321 : Bluetooth: BR/EDR: Refactor distribution of security procedure status
- https://gerrit.zephyrproject.org/r/4662 : irq: Add irq_pending_set external interrupt API
- https://gerrit.zephyrproject.org/r/4785 : unified: Add timeslice support
- https://gerrit.zephyrproject.org/r/4784 : unified: Preemption check to include sched lock
- https://gerrit.zephyrproject.org/r/4796 : Bluetooth: L2CAP: Handle security procedure non successful path
- https://gerrit.zephyrproject.org/r/4795 : Bluetooth: L2CAP: Refactor handling connection response
- https://gerrit.zephyrproject.org/r/4777 : unified: Include _timeout structure in tcs_base
- https://gerrit.zephyrproject.org/r/4776 : unified: Conditionally define __printf_like() macro
- https://gerrit.zephyrproject.org/r/4781 : unified: Enable semaphore group use in test_mail
- https://gerrit.zephyrproject.org/r/4780 : unified: Fix semaphore group tests
- https://gerrit.zephyrproject.org/r/4779 : unified: Add support for semaphore groups
- https://gerrit.zephyrproject.org/r/4489 : Bluetooth: SDP: Server: Support ServiceAttrReq and ServiceSearchAttrReq
- https://gerrit.zephyrproject.org/r/4488 : Bluetooth: SDP: Server: Support ServiceSearchRequest
- https://gerrit.zephyrproject.org/r/4487 : Bluetooth: SDP: Server: Support service record registration
- https://gerrit.zephyrproject.org/r/4486 : Bluetooth: SDP: Server: Initialize and accept incoming connections
- https://gerrit.zephyrproject.org/r/4447 : Bluetooth: AVDTP: Module Initialization
- https://gerrit.zephyrproject.org/r/4482 : mqtt: Remove the app_buf structure
- https://gerrit.zephyrproject.org/r/4794 : Bluetooth: A2DP: Initialization of A2DP
- https://gerrit.zephyrproject.org/r/3311 : include/crypto: Crypto abstraction header
- https://gerrit.zephyrproject.org/r/4540 : Bluetooth: AVDTP: Connect and Disconnect API
- https://gerrit.zephyrproject.org/r/4353 : ztest: Add native building support
- https://gerrit.zephyrproject.org/r/4682 : irq: Add irq_is_priority_equal external interrupt API
- https://gerrit.zephyrproject.org/r/4683 : ARM: irq: Add _arch_irq_is_priority_equal external interrupt API
- https://gerrit.zephyrproject.org/r/4663 : ARM: irq: Add _arch_irq_pending_set external interrupt API
- https://gerrit.zephyrproject.org/r/4687 : arduino 101: make factory bootloader config the default
- https://gerrit.zephyrproject.org/r/4774 : intel_quark: move X86_IAMCU to defconfig
- https://gerrit.zephyrproject.org/r/4688 : boards: rename arduino_101_sss to arduino_101_ss
- https://gerrit.zephyrproject.org/r/4500 : usb: add Kconfig options for CDC ACM VID/PID
- https://gerrit.zephyrproject.org/r/4511 : unified/doc: Kernel primer for unified kernel
- https://gerrit.zephyrproject.org/r/3312 : drivers/crypto: TinyCrypt shim driver
- https://gerrit.zephyrproject.org/r/3313 : samples/drivers/crypto: crypto sample app
- https://gerrit.zephyrproject.org/r/4757 : sanity: test_context build only for qemu arm
- https://gerrit.zephyrproject.org/r/3527 : console: shell: Shell enhancement - Support multiple modules
- https://gerrit.zephyrproject.org/r/4559 : misc: Add an helper for memory alignement
- https://gerrit.zephyrproject.org/r/3459 : soc: Add soc id and version interface
- https://gerrit.zephyrproject.org/r/4705 : power_mgmt: Mark old device pm API functions as deprecated
- https://gerrit.zephyrproject.org/r/4704 : power_mgmt: Update sample and drivers according to new pm device API
- https://gerrit.zephyrproject.org/r/4463 : power_mgmt: Update Power Management device driver API
- https://gerrit.zephyrproject.org/r/4430 : Link-time symbol priority-based replacement
- https://gerrit.zephyrproject.org/r/4676 : irq: Add irq_enable_keep external interrupt API
- https://gerrit.zephyrproject.org/r/4429 : Makefile: unify linker behavior, all architectures use two-pass linking
- https://gerrit.zephyrproject.org/r/4431 : printk: Use link-time aliasing to share implementation with printf
- https://gerrit.zephyrproject.org/r/4428 : Makefile: Clean up x86 second stage linker pass
- https://gerrit.zephyrproject.org/r/3895 : tests/kernel/test_multilib: Test for proper multilib selection.
- https://gerrit.zephyrproject.org/r/4427 : Makefile: Don't hide the "prebuilt" kernel
- https://gerrit.zephyrproject.org/r/4118 : tests: Add a generic testing framework
- https://gerrit.zephyrproject.org/r/4623 : eth: Adjust ENC28J60 transmission/reception return codes.
- https://gerrit.zephyrproject.org/r/4355 : ztest: Add simple integration and unit tests
- https://gerrit.zephyrproject.org/r/4356 : tests: convert tests/net/buf to the new framework
- https://gerrit.zephyrproject.org/r/4450 : tests: Add gcov support

MERGED within last 24 hours:
- https://gerrit.zephyrproject.org/r/4805 : arm/nrf52: Set CPU_HAS_FPU
- https://gerrit.zephyrproject.org/r/4804 : Bluetooth: eddystone: Add missing characteristics
- https://gerrit.zephyrproject.org/r/4801 : build: use 'vercomp' without relying on it being in PATH
- https://gerrit.zephyrproject.org/r/4802 : Bluetooth: eddystone: Fix byteorder of advertisement
- https://gerrit.zephyrproject.org/r/4791 : Bluetooth: Controller: Refactor HCI files
- https://gerrit.zephyrproject.org/r/4422 : boards: rename Quark SE Devboard to Quark SE C1000
- https://gerrit.zephyrproject.org/r/4670 : intel_quark: Group Quark SoCs under intel_quark/
- https://gerrit.zephyrproject.org/r/4684 : quark_x1000: move the X1000 into the intel_quark family
- https://gerrit.zephyrproject.org/r/4671 : soc: intel_quark: move quark d2000 to intel_quark family
- https://gerrit.zephyrproject.org/r/4689 : parse board defconfig at the very end
- https://gerrit.zephyrproject.org/r/4420 : boards: rename Quark SE Devboard to Quark SE C1000 (Sensor Subsystem)
- https://gerrit.zephyrproject.org/r/4423 : MAINTAINERS: add maintainer for some of the boards
- https://gerrit.zephyrproject.org/r/4790 : fs: Fixes a bug that limits volume size to 1MB
- https://gerrit.zephyrproject.org/r/4755 : sdk: zephyr: check for minimum required version of SDK
- https://gerrit.zephyrproject.org/r/4600 : samples: heartrate-monitor: Fixes for following issues.
- https://gerrit.zephyrproject.org/r/4693 : tests: remove dependency on architecture and use one prj.conf
- https://gerrit.zephyrproject.org/r/4694 : tests: fp_sharing: removing dependency on ARCH
- https://gerrit.zephyrproject.org/r/4788 : linker: fix typos
- https://gerrit.zephyrproject.org/r/4789 : unified/x86: fix IAMCU build
- https://gerrit.zephyrproject.org/r/4101 : tests/mem_safe: place test buffers at the edges of RAM
- https://gerrit.zephyrproject.org/r/4100 : build: allow specifying a custom linker script relative to project


Re: [RFC]PWM API Update

Tomasz Bursztyka
 

Hi Baohong,

-----Original Message-----
From: Ross, Andrew J
Sent: Thursday, September 15, 2016 8:04 AM
To: Liu, Baohong <baohong.liu(a)intel.com>; devel(a)lists.zephyrproject.org
Subject: Re: [devel] [RFC]PWM API Update

Liu, Baohong wrote:
As for the unit for period and pulse width, I understand that both
time
(micro-second) and clock cycles are popularly used. To cater for this,
the above-mentioned API will be expanded into two.

pwm_set_pin_usec(uint8_t pin, uint32_t period_usec, uint32_t
pulse_usec) pwm_set_pin_cycles(uint8_t pin, uint32_t period_cycles,
uint32_t pulse_cycles)
When PWM is used correctly, this shouldn't make any difference at all
because the period will be much, much longer than the underlying clock
(which is the whole point).

Why bother with having two ways to do this when they're going to be exactly
equivalent in all but the weirdest apps? Just set them in arbitrary units of
"cycles". And if an application really, truly needs to know the underlying
cycle time of the hardware (which is going to be device-dependent), give
them an API like "pwm_get_cycle_time()" which returns a cycle time in
picoseconds or something.
I personally prefer two APIs. Somebody also suggested two APIs in ZEP-745.
Looks two APIs is the way to go so far.
In the end, both do the same, but:

there is actually an implementation issue with pwm_set_pin_usec() as
the driver will
have to do calculation according to the underlying hw cycle time. So
this piles up more
work in driver side. Though, from user perspective, it might be simpler
to use yes.
(no hand-computation needed from the user).

Actually, with Andy's proposal of providing a pwm_get_cycle_time() along
with
pwm_set_pin_cycles(), I believe (tell me if I am wrong) you could implement
pwm_set_pin_usec() as a generic pwm function instead of a driver API
function.
Sounds like the best option to me: you keep the driver API concise, and
you still end
up providing both functions in the end.

Tomasz


RFC: Extension to External Interrupt API

Chettimada, Vinayak Kariappa
 

Hi,

Welcome your valuable comments on the proposed extension to External Interrupt API.

*irq_enable_keep*
https://gerrit.zephyrproject.org/r/#/c/4676/1
https://gerrit.zephyrproject.org/r/#/c/4677/1

*irq_is_enabled*
https://gerrit.zephyrproject.org/r/#/c/4678/1
https://gerrit.zephyrproject.org/r/#/c/4679/1

*irq_pending_set*
https://gerrit.zephyrproject.org/r/#/c/4662/3
https://gerrit.zephyrproject.org/r/#/c/4663/3

*irq_pending_clear*
https://gerrit.zephyrproject.org/r/#/c/4680/1
https://gerrit.zephyrproject.org/r/#/c/4681/1

*irq_is_priority_equal*
https://gerrit.zephyrproject.org/r/#/c/4682/2
https://gerrit.zephyrproject.org/r/#/c/4683/2

I have had a barebone execution architecture in the contributed BLE controller code,
consisting of thread mode, ISR and work on ARM architectures. 'work' is an offloaded
function to another or same ISR priority (usually to a s/w interrupt).

To further a close integration of the controller, the above extension to external
interrupt APIs is desired.

Thanks in advance.

Regards,
Vinayak


Re: [RFC]PWM API Update

Liu, Baohong
 

-----Original Message-----
From: Ross, Andrew J
Sent: Thursday, September 15, 2016 8:04 AM
To: Liu, Baohong <baohong.liu(a)intel.com>; devel(a)lists.zephyrproject.org
Subject: Re: [devel] [RFC]PWM API Update

Liu, Baohong wrote:
As for the unit for period and pulse width, I understand that both
time
(micro-second) and clock cycles are popularly used. To cater for this,
the above-mentioned API will be expanded into two.

pwm_set_pin_usec(uint8_t pin, uint32_t period_usec, uint32_t
pulse_usec) pwm_set_pin_cycles(uint8_t pin, uint32_t period_cycles,
uint32_t pulse_cycles)
When PWM is used correctly, this shouldn't make any difference at all
because the period will be much, much longer than the underlying clock
(which is the whole point).

Why bother with having two ways to do this when they're going to be exactly
equivalent in all but the weirdest apps? Just set them in arbitrary units of
"cycles". And if an application really, truly needs to know the underlying
cycle time of the hardware (which is going to be device-dependent), give
them an API like "pwm_get_cycle_time()" which returns a cycle time in
picoseconds or something.
I personally prefer two APIs. Somebody also suggested two APIs in ZEP-745.
Looks two APIs is the way to go so far.


Andy


Daily JIRA Digest

donotreply@...
 

NEW JIRA items within last 24 hours: 21
[ZEP-886] 802.15.4 - MAC command frame support
https://jira.zephyrproject.org/browse/ZEP-886

[ZEP-887] 802.15.4 - Management service: RFD level support
https://jira.zephyrproject.org/browse/ZEP-887

[ZEP-889] 802.15.4 - Management service: FFD level support
https://jira.zephyrproject.org/browse/ZEP-889

[ZEP-892] 802.15.4 - TSCH Radio protocol support
https://jira.zephyrproject.org/browse/ZEP-892

[ZEP-888] 802.15.4 - Security support
https://jira.zephyrproject.org/browse/ZEP-888

[ZEP-879] 6LoWPAN - Stateless Address Autoconfiguration
https://jira.zephyrproject.org/browse/ZEP-879

[ZEP-880] 6LoWPAN - Multicast Address Mapping
https://jira.zephyrproject.org/browse/ZEP-880

[ZEP-882] 6LoWPAN - IPv6 Next Header Compression
https://jira.zephyrproject.org/browse/ZEP-882

[ZEP-881] 6LoWPAN - Frame Delivery in a Link-Layer Mesh
https://jira.zephyrproject.org/browse/ZEP-881

[ZEP-876] 6LoWPAN - Offset based Reassembly of 802.15.4 packets
https://jira.zephyrproject.org/browse/ZEP-876

[ZEP-878] 6LoWPAN - Unicast-Prefix based IPv6 Multicast (dst) address compression
https://jira.zephyrproject.org/browse/ZEP-878

[ZEP-877] 6LoWPAN - Mesh Header compression and uncompression
https://jira.zephyrproject.org/browse/ZEP-877

[ZEP-875] 6LoWPAN - Context based compression support
https://jira.zephyrproject.org/browse/ZEP-875

[ZEP-891] 802.15.4 - Update existing Management commands
https://jira.zephyrproject.org/browse/ZEP-891

[ZEP-890] 802.15.4 - IE list support
https://jira.zephyrproject.org/browse/ZEP-890

[ZEP-893] 802.15.4 - Multipurpose frame support
https://jira.zephyrproject.org/browse/ZEP-893

[ZEP-894] 802.15.4 - LLDN frame support
https://jira.zephyrproject.org/browse/ZEP-894

[ZEP-873] DMA API Update
https://jira.zephyrproject.org/browse/ZEP-873

[ZEP-874] SQL Database
https://jira.zephyrproject.org/browse/ZEP-874

[ZEP-898] Remove 1MB limit in file system
https://jira.zephyrproject.org/browse/ZEP-898

[ZEP-872] Unable to flash Zephyr on Arduino 101 using Ubuntu and following wiki instructions
https://jira.zephyrproject.org/browse/ZEP-872


UPDATED JIRA items within last 24 hours: 11
[ZEP-827] HTTP Client sample application
https://jira.zephyrproject.org/browse/ZEP-827

[ZEP-798] IPv6
https://jira.zephyrproject.org/browse/ZEP-798

[ZEP-792] ARP
https://jira.zephyrproject.org/browse/ZEP-792

[ZEP-785] Enable MQTT Paho samples to run on quark se board
https://jira.zephyrproject.org/browse/ZEP-785

[ZEP-865] convert filesystem sample to a runnable test
https://jira.zephyrproject.org/browse/ZEP-865

[ZEP-240] printk/printf usage in samples
https://jira.zephyrproject.org/browse/ZEP-240

[ZEP-614] Port tinycrypt 2.0 test cases to Zephyr
https://jira.zephyrproject.org/browse/ZEP-614

[ZEP-365] Zephyr's MQTT library
https://jira.zephyrproject.org/browse/ZEP-365

[ZEP-847] IoT protocol functionality must be moved from samples to lib/iot
https://jira.zephyrproject.org/browse/ZEP-847

[ZEP-867] misuse of "select" in SOC/board Kconfigs
https://jira.zephyrproject.org/browse/ZEP-867

[ZEP-895] Initial release to tx semaphore for the ENC28J60 driver.
https://jira.zephyrproject.org/browse/ZEP-895


CLOSED JIRA items within last 24 hours: 10
[ZEP-821] (Duplicate) MQTT v3.1.1 port to the new IP Stack
https://jira.zephyrproject.org/browse/ZEP-821

[ZEP-762] (Fixed) unexpected "abspath" and "notdir" from mingw make system
https://jira.zephyrproject.org/browse/ZEP-762

[ZEP-467] (Fixed) Hang using UART and console.
https://jira.zephyrproject.org/browse/ZEP-467

[ZEP-849] (Fixed) dma driver fails to build on quark d2000
https://jira.zephyrproject.org/browse/ZEP-849

[ZEP-848] (Fixed) test_context fails on quark d2000
https://jira.zephyrproject.org/browse/ZEP-848

[ZEP-733] (Fixed) Minimal libc shouldn't be providing stddef.h
https://jira.zephyrproject.org/browse/ZEP-733

[ZEP-199] (Fixed) Zephyr driver model is undocumented
https://jira.zephyrproject.org/browse/ZEP-199

[ZEP-690] (Fixed) TCF isn't setting ARCH when running testcases
https://jira.zephyrproject.org/browse/ZEP-690

[ZEP-503] (Fixed) qmsi uart shim reentrancy support is breaking Bluetooth
https://jira.zephyrproject.org/browse/ZEP-503

[ZEP-602] (Fixed) unhandled CPU exceptions/interrupts report wrong faulting vector if triggered by CPU
https://jira.zephyrproject.org/browse/ZEP-602


RESOLVED JIRA items within last 24 hours: 9
[ZEP-789] (Fixed) IPv4
https://jira.zephyrproject.org/browse/ZEP-789

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

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

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

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

[ZEP-757] (Fixed) tests/kernel/test_context/ fail in Arduino 101 and Quark SE C1000
https://jira.zephyrproject.org/browse/ZEP-757

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

[ZEP-685] (Fixed) many sample programs are not built by CI
https://jira.zephyrproject.org/browse/ZEP-685

[ZEP-871] (Won't Do) cannot find -lgcc when build qemu_x86 with issm toolchain
https://jira.zephyrproject.org/browse/ZEP-871

6561 - 6580 of 8046