Date   

Re: RFC: Extension to External Interrupt API

Andy Ross
 

Vinayak Kariappa Chettimada wrote:
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.
Yeah, this got some water-cooler attention last week. So it seems
what you're really asking for is an interrupt bottom half framework
for zephyr. So you can have your fiber scheduled alongside the
hardware interrupts when needed.

And (Ben needs to jump in here, I'm no expert) it seems like we have
most of what is needed already in the fiber scheduler. All that I can
see we'd need is:

1. Map the available hardware interrupt priorities to the top N fiber
priorities.

2. Mask off equal and lower interrupt priorities during the execution
of a fiber at those levels. This may be tricky to specify on all
architectures, and may involve some of them running "bottom half"
fibers with interrupts disabled. It might plausibly break some
assumptions in existing code that has an "in an ISR" notion (the
definition of "ISR" gets fuzzy).

3. Arrange to have the exit code for every ISR call _Swap() to
reschedule instead of returning directly to the interrupted task.
This would have some code size cost (maybe a tiny stub to wrap the
user-defined ISRs), though not huge.

But at that point, you don't need to muck with architecture-specific
interrupts to get what you want. You just wake up your work fiber(s)
from your existing ISRs with whatever IPC mechanism you want (give a
semaphore, write a command to a fifo, whatever) and they get scheduled
at the IRQ-scale priority you want.

What did I miss?

Andy


Re: [RFC]PWM API Update

Andy Ross
 

Liu, Baohong wrote:
get_cycles_per_usec(void); /* we can find better name:) */
Senseless nitpick: this unit choice will hit precision issues.
Many/most PWM implementations in the wild work on clocks in the low
MHz, so this is only going to return a few bits of frequency
precision. I'd suggest cycles_per_sec() (works as long as the clock
isn't GHz scale) or cycle_time_ps() (starts to lose precision above a
few GHz, also not everyone knows what a picosecond is) or something
equivalent.

Andy


Daily Gerrit Digest

donotreply@...
 

NEW within last 24 hours:
- https://gerrit.zephyrproject.org/r/4837 : rfc: net: yaip: Add nbuf APIs to read/write across multiple fragments
- https://gerrit.zephyrproject.org/r/4836 : lib/http: Add test-case for HTTP header fields
- https://gerrit.zephyrproject.org/r/4823 : net: Make sure that local port selected by Zephyr gets used by uIP.
- https://gerrit.zephyrproject.org/r/4829 : net: yaip: Added a define for unused bytes length in ICMPv6 header
- https://gerrit.zephyrproject.org/r/4833 : net: tests: Add tests for route management API
- https://gerrit.zephyrproject.org/r/4831 : net: yaip: Add more debugging prints to neighbor cache
- https://gerrit.zephyrproject.org/r/4830 : net: yaip: Fix reachable timer accessing NULL pointer
- https://gerrit.zephyrproject.org/r/4828 : net: yaip: Add function to return neighbor by the index
- https://gerrit.zephyrproject.org/r/4832 : net: yaip: Generic route handling
- https://gerrit.zephyrproject.org/r/4827 : net: yaip: Fix function prototype documentation in neighbor header
- https://gerrit.zephyrproject.org/r/4825 : tinycrypt: Add test case for the ECC DH algorithm
- https://gerrit.zephyrproject.org/r/4824 : tinycrypt: Add test case for the ECC DSA algorithm

UPDATED within last 24 hours:
- https://gerrit.zephyrproject.org/r/4794 : Bluetooth: A2DP: Initialization of A2DP
- https://gerrit.zephyrproject.org/r/3922 : lib: Add HTTP support for Zephyr
- https://gerrit.zephyrproject.org/r/4780 : unified: Fix semaphore group tests
- 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/4781 : unified: Enable semaphore group use in test_mail
- https://gerrit.zephyrproject.org/r/4779 : unified: Add support for semaphore groups
- https://gerrit.zephyrproject.org/r/4321 : Bluetooth: BR/EDR: Refactor distribution of security procedure status
- https://gerrit.zephyrproject.org/r/3527 : console: shell: Shell enhancement - Support multiple modules
- https://gerrit.zephyrproject.org/r/4487 : Bluetooth: SDP: Server: Support service record registration
- 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/4705 : power_mgmt: Mark old device pm API functions as deprecated
- https://gerrit.zephyrproject.org/r/4808 : Bluetooth: L2CAP: Limit user I/O actions timeout in GAP context
- https://gerrit.zephyrproject.org/r/4795 : Bluetooth: L2CAP: Refactor handling connection response
- https://gerrit.zephyrproject.org/r/4796 : Bluetooth: L2CAP: Handle security procedure non successful path
- https://gerrit.zephyrproject.org/r/4822 : arduino 101: fix PHYS_LOAD_ADDR for arduino_101

MERGED within last 24 hours:
- https://gerrit.zephyrproject.org/r/4834 : Bluetooth: init: Add CONFIG_BLUETOOTH_RFCOMM to prj_20.conf
- https://gerrit.zephyrproject.org/r/3895 : tests/kernel/test_multilib: Test for proper multilib selection.
- 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


zoap architecture question...

Marcus Shawcroft <marcus.shawcroft@...>
 

Hi!

Neither the sample/zoap-server application nor the zoap implementation
itself appear to handle the generation of RST messages in response to
message format errors in an initial CON message (or did I miss
something?). Is the intention that the logic to generate such RST
messages will live within the zoap layer or is it intended to be
handled by the layer above?

Cheers
/Marcus


Re: Galileo Gen 1 GPIO

Tomasz Bursztyka
 

Hi Fábio,

Unfortunately, we do not support Galileo v1 pinmuxing, thus: the whole
board is basically unusable at this stage.
You won't be able to get very far unless you provide the cypress chip
driver.

Can you use another board? We support quite a few (see boards directory
in zephyr's tree)

Br,

Tomasz

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.


Question about non-XIP boot

Tidy(ChunHua) Jiang <tidyjiang@...>
 

Hi All,

I'm reading the boot code for cortex-m, but confused about something,
please help me.

Before jumping to C code:

void _PrepC(void)
{
relocate_vector_table();
enable_floating_point();
_bss_zero();
_data_copy();
_Cstart();
CODE_UNREACHABLE;
}

---------------------------------------------------------

#ifdef CONFIG_XIP
static inline void relocate_vector_table(void) { /* do nothing */ }
#else
static inline void relocate_vector_table(void)
{
/* vector table is already in SRAM, just point to it */
_scs_relocate_vector_table((void *)CONFIG_SRAM_BASE_ADDRESS);
}
#endif

-----------------------------------------------------------

In non-XIP mode, from my view, before relocate vector table to RAM, we
should copy the data from flash to RAM. But above code firstly relocates
and then copy data, why ?

Thx & Rgds.


Re: A possible case of TCP server no-response, was: Re: bufs lost in TCP connection establishment

Paul Sokolovsky
 

Hello,

On Thu, 15 Sep 2016 02:51:49 -0000
"Flavio Santes" <flavio.santes(a)intel.com> wrote:

One particularly naughty conditions I experienced is that while my
usual testcase usually proceeded beyond connect() call, sometimes I
got time "strips" when connect() call just hanged (I don't use
[]

This is a hardware-agnostic issue, see:
https://jira.zephyrproject.org/browse/ZEP-428. The issue description
is not really useful, although comments will help. BTW, we apply the
same workaround: restart the server :)
Thanks, I read it, but not sure it's the same issue as I described
above - indeed, there're many different issues. I checked into Z source,
and found that it actually tries to make a random local port number (if
user passed one as 0). But Wireshark still shows that after a restart,
1025 is what gets actually sent on wire, and the situation got pretty
unpleasant when I moved from local servers to knocking on AWS IoT ones,
which, well, I can't restart.

So, digging further, turned that Zephyr networking layer and uIP live
their own separate lives wrt to local port numbering.
https://gerrit.zephyrproject.org/r/#/c/4823/ makes them talk together,
though on uIP's terms (using global variables). As patch description
says, I'm open to suggestions to redo it via adding function arguments.



Thanks,
Paul


On Wed, 7 Sep 2016 15:26:23 +0000
Rohit Grover <Rohit.Grover(a)arm.com&gt; wrote:
Regards,
Flavio


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


Daily JIRA Digest

donotreply@...
 

NEW JIRA items within last 24 hours: 0

UPDATED JIRA items within last 24 hours: 1
[ZEP-555] correct libgcc not getting linked for CONFIG_FLOAT=y on ARM
https://jira.zephyrproject.org/browse/ZEP-555


CLOSED JIRA items within last 24 hours: 0

RESOLVED JIRA items within last 24 hours: 0


Daily Gerrit Digest

donotreply@...
 

NEW within last 24 hours:
- https://gerrit.zephyrproject.org/r/4822 : arduino 101: fix PHYS_LOAD_ADDR for arduino_101
- https://gerrit.zephyrproject.org/r/4821 : drivers: gpio: reuse gpio Kconfigs for sensor subsystem

UPDATED within last 24 hours:
- 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/4450 : tests: Add gcov support
- https://gerrit.zephyrproject.org/r/4357 : tests: Add a sample for testing natively
- https://gerrit.zephyrproject.org/r/4354 : ztest: Add documentation
- https://gerrit.zephyrproject.org/r/4356 : tests: convert tests/net/buf to the new framework
- https://gerrit.zephyrproject.org/r/4355 : ztest: Add simple integration and unit tests
- https://gerrit.zephyrproject.org/r/4118 : tests: Add a generic testing framework
- https://gerrit.zephyrproject.org/r/4353 : ztest: Add native building support

MERGED within last 24 hours:
- https://gerrit.zephyrproject.org/r/4622 : eth: Add full-duplex configuration to ENC28J60
- https://gerrit.zephyrproject.org/r/4621 : eth: Initial release to tx semaphore for the ENC28J60 driver.
- https://gerrit.zephyrproject.org/r/4620 : eth: Adjust ENC28J60 MAC configuration.
- https://gerrit.zephyrproject.org/r/4803 : Merge bluetooth branch into master


Exception debugging with qemu_x86/gdb

Paul Sokolovsky
 

Hello,

I have a crash ("CPU exception 13") somewhere in networking code. My
next step would be to run the app (BOARD=qemu_x86) under GDB, wait for
crash, type "backtrace". I follow
https://www.zephyrproject.org/doc/reference/kbuild/kbuild_project.html#application-debugging
, but when exception occurs, I don't end up in GDB, Zephyr's own
exception handler keeps running, e.g.:

***** CPU exception 13
***** Exception code: 0x00004074
Current thread ID = 0x00177f60
Faulting segment:address = 0x00000008:0x001782da
eax: 0x0000ff0e, ebx: 0x00178350, ecx: 0x00177f60, edx: 0x00177f60
esi: 0x00000000, edi: 0x00178400, ebp: 000169398, esp: 0x0017830c
eflags: 0x00004046
Fatal essential fiber error! Spinning...

I tried to look for Kconfig options, but the only relevant I found was
CONFIG_EXCEPTION_DEBUG, setting it to "n" from default "y" doesn't
help. Well, another option is CONFIG_GDB_SERVER, but that embeds
actual GDB debug stub into the *application*. But we use QEMU's debug
stub on the meta-level, so CONFIG_GDB_SERVER shouldn't be needed (and
enabling it just garbles console, as it tries to communicate via
serial).

So, I would naively think that QEMU's GDB stub would override any
relevant guest exception handling, but that apparently not happen. What
am I missing? I tried to look for other related options to QEMU
(besides -s -S), but don't see nothing relevant. The only doc I found
is http://wiki.qemu.org/Documentation/Debugging which is pretty short
at best.


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


Daily JIRA Digest

donotreply@...
 

NEW JIRA items within last 24 hours: 36
[ZEP-906] [unified] Add scheduler time slicing support
https://jira.zephyrproject.org/browse/ZEP-906

[ZEP-909] Adapt tickless idle + power management for ARM
https://jira.zephyrproject.org/browse/ZEP-909

[ZEP-908] Add task offload to fiber support
https://jira.zephyrproject.org/browse/ZEP-908

[ZEP-910] Adapt tickless idle for x86
https://jira.zephyrproject.org/browse/ZEP-910

[ZEP-907] Test memory pool support (with mailboxes)
https://jira.zephyrproject.org/browse/ZEP-907

[ZEP-911] Refine thread priorities & locking
https://jira.zephyrproject.org/browse/ZEP-911

[ZEP-924] Revise documentation for Interrupts
https://jira.zephyrproject.org/browse/ZEP-924

[ZEP-923] Revise documentation for Timing
https://jira.zephyrproject.org/browse/ZEP-923

[ZEP-927] Enhancements to memory maps
https://jira.zephyrproject.org/browse/ZEP-927

[ZEP-925] Enhancements to message queues
https://jira.zephyrproject.org/browse/ZEP-925

[ZEP-929] Verify the preempt-thread-only and coop-thread-only configurations
https://jira.zephyrproject.org/browse/ZEP-929

[ZEP-926] Enhancements to memory pools
https://jira.zephyrproject.org/browse/ZEP-926

[ZEP-931] Finalize kernel file naming & locations
https://jira.zephyrproject.org/browse/ZEP-931

[ZEP-930] Cutover to unified kernel
https://jira.zephyrproject.org/browse/ZEP-930

[ZEP-912] Finish renaming kernel object types
https://jira.zephyrproject.org/browse/ZEP-912

[ZEP-937] Adapt networking to unified kernel
https://jira.zephyrproject.org/browse/ZEP-937

[ZEP-936] Adapt drivers to unified kernel
https://jira.zephyrproject.org/browse/ZEP-936

[ZEP-934] NIOS_II port
https://jira.zephyrproject.org/browse/ZEP-934

[ZEP-935] Kernel logger support (validation)
https://jira.zephyrproject.org/browse/ZEP-935

[ZEP-933] ARC port
https://jira.zephyrproject.org/browse/ZEP-933

[ZEP-916] Eliminate kernel object API anomalies
https://jira.zephyrproject.org/browse/ZEP-916

[ZEP-918] Add ring buffer support
https://jira.zephyrproject.org/browse/ZEP-918

[ZEP-917] Add abort handler support
https://jira.zephyrproject.org/browse/ZEP-917

[ZEP-914] Improving locking algorithms in kernel objects
https://jira.zephyrproject.org/browse/ZEP-914

[ZEP-921] Miscellaneous documentation work
https://jira.zephyrproject.org/browse/ZEP-921

[ZEP-919] Purge obsolete microkernel & nanokernel code
https://jira.zephyrproject.org/browse/ZEP-919

[ZEP-922] Revise documentation for Kernel Event Logger
https://jira.zephyrproject.org/browse/ZEP-922

[ZEP-928] Enhancements to event handling
https://jira.zephyrproject.org/browse/ZEP-928

[ZEP-932] Adapt kernel sample & test projects
https://jira.zephyrproject.org/browse/ZEP-932

[ZEP-913] Place thread stacks in their own linker section
https://jira.zephyrproject.org/browse/ZEP-913

[ZEP-920] Investigate malloc/free support
https://jira.zephyrproject.org/browse/ZEP-920

[ZEP-915] O(1) pend queue support
https://jira.zephyrproject.org/browse/ZEP-915

[ZEP-903] Create APIs for app to create and mount FS
https://jira.zephyrproject.org/browse/ZEP-903

[ZEP-904] Look into supporting additional file systems under Zephyr FS API
https://jira.zephyrproject.org/browse/ZEP-904

[ZEP-902] Reduce the use of Kconfig for FS to minimum
https://jira.zephyrproject.org/browse/ZEP-902

[ZEP-905] hello_world compilation for arduino_due target fails when using CROSS_COMPILE
https://jira.zephyrproject.org/browse/ZEP-905


UPDATED JIRA items within last 24 hours: 4
[ZEP-812] Compression Format for IPv6 over 802.15.4
https://jira.zephyrproject.org/browse/ZEP-812

[ZEP-809] IPv6 over 802.15.4
https://jira.zephyrproject.org/browse/ZEP-809

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

[ZEP-796] DHCPv4
https://jira.zephyrproject.org/browse/ZEP-796


CLOSED JIRA items within last 24 hours: 0

RESOLVED JIRA items within last 24 hours: 3
[ZEP-584] (Fixed) warn user if SDK is out of date
https://jira.zephyrproject.org/browse/ZEP-584

[ZEP-758] (Fixed) Rename Quark SE Devboard to its official name: Quark SE C1000
https://jira.zephyrproject.org/browse/ZEP-758

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


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.

6321 - 6340 of 7817