Date   

Where should special purpose GPIO drivers go?

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

I know $subject it's an oxymoron but it's accurate. I have some special
purpose registers to drive hardwired fixed function pins and I'm making
these available to the rest of the system using drivers which implement
the GPIO API. I was wondering whereabouts under the drivers/ directory
they belong.

E.g. one register type is for accessing a pair open collector data/clk
pins wired for bitbang I2C [1]. Does the driver for this belong under
drivers/i2c because it's being used for I2C or under drivers/gpio
because it implements the GPIO API, or somewhere else?

I also have a general purpose driver to represent any 32-bit memory
mapped register using the GPIO API, where would that live? I created
that because my SoC (actually FPGA [2]) has several miscellaneous
registers, some of the bits of which are used for things like SPI chip
select, so I need a GPIO based API to use with the SPI driver.

Note, the SoC also has proper GPIO but the above functions aren't part
of that IP block, so I believe separate drivers are appropriate.

[1] http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0447j/Bbajdjeg.html
[2] https://www.arm.com/products/tools/development-boards/versatile-express/cortex-m-prototyping-system.php

--
Tixy


Daily Gerrit Digest

donotreply@...
 

NEW within last 24 hours:
- https://gerrit.zephyrproject.org/r/9231 : net: if: Add NET_IF_UP flag
- https://gerrit.zephyrproject.org/r/9243 : timer: hpet: rename debug function to avoid conflict
- https://gerrit.zephyrproject.org/r/9242 : arm: remove old GDB_INFO support
- https://gerrit.zephyrproject.org/r/9230 : gpio/nrf5: Support drive strength configuration.
- https://gerrit.zephyrproject.org/r/9241 : samples: remove obsolete KERNEL_TYPE
- https://gerrit.zephyrproject.org/r/9240 : Bluetooth: shell: Add option to specify BR/EDR discovery length
- https://gerrit.zephyrproject.org/r/9238 : Bluetooth: SDP: Initial implementation of bt_sdp_discover API
- https://gerrit.zephyrproject.org/r/9237 : samples: echo: Support connecting CC2520 to Hexiwear
- https://gerrit.zephyrproject.org/r/9239 : Bluetooth: SDP: Add connected and disconnected handlers
- https://gerrit.zephyrproject.org/r/9236 : samples: cc2520: Add configuration for CC2520 and hexiwear_k64
- https://gerrit.zephyrproject.org/r/9235 : tests: add gdb server test
- https://gerrit.zephyrproject.org/r/9234 : debug: gdb: move to new kernel APIs
- https://gerrit.zephyrproject.org/r/9229 : gpio: Support drive strength configuration.
- https://gerrit.zephyrproject.org/r/9228 : hexiwear_k64: Set pinmux for SPI0
- https://gerrit.zephyrproject.org/r/9216 : samples/basic/disco: Add support for Nucleo F401RE and A101
- https://gerrit.zephyrproject.org/r/9227 : dhcpv4: Add support for router option.
- https://gerrit.zephyrproject.org/r/9226 : dhcpv4: Add option parsing diagnostics.
- https://gerrit.zephyrproject.org/r/9225 : echo-client: Adjust print format specified to match parameter type.
- https://gerrit.zephyrproject.org/r/9223 : echo_server: Fix frdm_k64f build in the absence of CC2520
- https://gerrit.zephyrproject.org/r/9221 : samples: net: Fix Makefile and conf file
- https://gerrit.zephyrproject.org/r/9215 : kernel: remove unused and obsolete headers

UPDATED within last 24 hours:
- https://gerrit.zephyrproject.org/r/6291 : Bluetooth: SDP: Initial SDP client interface API
- https://gerrit.zephyrproject.org/r/9204 : debug: fixed style and align code
- https://gerrit.zephyrproject.org/r/9209 : kernel: move kernel code to kernel/ directly
- https://gerrit.zephyrproject.org/r/9195 : kernel: kconfig: move event logger options into file
- https://gerrit.zephyrproject.org/r/9198 : doc: rename shell section to simply: Shell
- https://gerrit.zephyrproject.org/r/9205 : object_tracing: fixed style
- https://gerrit.zephyrproject.org/r/9072 : boards: arm: add support for redbear ble nano 2
- https://gerrit.zephyrproject.org/r/9194 : kernel: kconfig: replace task/fiber with threads
- https://gerrit.zephyrproject.org/r/9203 : debug: move debug features from misc to subsys/debug
- https://gerrit.zephyrproject.org/r/9196 : kernel: kconfig: move power management options out
- https://gerrit.zephyrproject.org/r/9211 : tracing: rename CONFIG_DEBUG_TRACING_KERNEL_OBJECTS
- https://gerrit.zephyrproject.org/r/9208 : kernel: merge kernel Kconfigs into one
- https://gerrit.zephyrproject.org/r/9210 : kconfig: group options into menus
- https://gerrit.zephyrproject.org/r/9199 : logging: move sys_log to subsys/logging
- https://gerrit.zephyrproject.org/r/9193 : kernel: Isolate logger options
- https://gerrit.zephyrproject.org/r/9206 : kernel: fixed description of THREAD_CUSTOM_DATA
- https://gerrit.zephyrproject.org/r/9192 : kernel: rename NANOKERNEL_TICKLESS_IDLE_SUPPORTED
- https://gerrit.zephyrproject.org/r/9197 : kconfig: remove unused TASK_DEBUG options
- https://gerrit.zephyrproject.org/r/9207 : x86: remove obsolete comment about tasks/fibers
- https://gerrit.zephyrproject.org/r/9212 : logging: fix ring buffer usage and initialize variables.
- https://gerrit.zephyrproject.org/r/5504 : dma: Introduce STM32F4x DMA driver
- https://gerrit.zephyrproject.org/r/9213 : scripts: fixed typo swab->swap
- https://gerrit.zephyrproject.org/r/9214 : kernel: remove nano/micro wording and usage

MERGED within last 24 hours:
- https://gerrit.zephyrproject.org/r/9224 : Bluetooth: controller: Move call to k_sem_give() out of the ISR
- https://gerrit.zephyrproject.org/r/9222 : Bluetooth: RFCOMM: Respond to RLS command
- https://gerrit.zephyrproject.org/r/9186 : k64f: Default the ETH_KSDK on if NET_L2_ETHERNET enabled.
- https://gerrit.zephyrproject.org/r/9187 : dhcpv4_client: Remove unnecessary ETH_KSDK configuration.
- https://gerrit.zephyrproject.org/r/9188 : dhcpv4: Adjust prj file selection.
- https://gerrit.zephyrproject.org/r/7028 : Bluetooth: AT: Improve API() to work with buffer increment
- https://gerrit.zephyrproject.org/r/9115 : Bluetooth: RFCOMM: Remove unneeded NULL checks


mqtt - tcp client connection - samples

Jorge Ramirez <jorge.ramirez-ortiz@...>
 

Hi,

I am looking for some sample code that shows how to connect an mqtt
publisher/subscriber to a broker or gateway.

The MQTT code in lib/iot requires that before the MQTT connect packet
can be sent, the MQTT device needs to have established a TCP connection
to the broker.

However the TCP_connect test code in tests/net/tcp/src/main.c has been
compiled out (last time I asked it was work in progress (scheduled for
December) since the actual stack support was not there yet).

I can see the following cards in JIRA:

* ZEP-613: TCP/UDP client and server mode functionality [in progress]
https://jira.zephyrproject.org/browse/ZEP-613

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


A far as I can see lib/iot/mqtt contains the MQTT high level API - this
was delivered a couple of weeks ago;
however there is no MQTT sample code other than the MQTT packet
validation in tests/iot/.

I suppose the MQTT sample code and the actual functionality is still
blocked by ZEP-613?

TIA
Jorge


Re: Eddystone TLM

Carles Cufi
 

Hi Marcio, Luiz,

-----Original Message-----
From: Luiz Augusto von Dentz [mailto:luiz.dentz(a)gmail.com]
Sent: Monday, December 19, 2016 12:00
To: Marcio Montenegro <mtuxpe(a)gmail.com>
Cc: devel(a)lists.zephyrproject.org
Subject: [devel] Re: Eddystone TLM

Hi Marcio,

Well I don't think the HCI interface, up to 4.2, offers this kind of
interface, it does have commands to set the AD and then enable it but
the link layer don't tell us exactly when the advertisement is sent over
the air.
Even if we had such an interface we still wouldn't know for sure if a potential observer/scanner had received the adv packet at all. One way to address this would be to add a Vendor Specific HCI event on reception of a Scan Request event. This has been done in the past with good results, and it can be used by the app as a confirmation that an advertisement packet has been received by a peer. It obviously requires scannable advertising.


There is perhaps some ways to build around with new commands added in
Bluetooth 5.0, for example there is LE Advertising Set Terminated Event
which we might support eventually but it would probably require some API
changes, or adding a new ones, to deal with multiple advertisement
instances, etc.
There is already a radio_active_callback() in the current Bluetooth Controller in Zephyr that can be used for this purpose in combined builds (Host + Controller). What it might be missing is an ID of some sort indicating which kind of operation (conn event, adv event, etc) took place.
We would of course need to expose this to the application via a public interface.

Thanks,

Carles


Re: Eddystone TLM

Luiz Augusto von Dentz
 

Hi Marcio,

Well I don't think the HCI interface, up to 4.2, offers this kind of
interface, it does have commands to set the AD and then enable it but
the link layer don't tell us exactly when the advertisement is sent
over the air.

There is perhaps some ways to build around with new commands added in
Bluetooth 5.0, for example there is LE Advertising Set Terminated
Event which we might support eventually but it would probably require
some API changes, or adding a new ones, to deal with multiple
advertisement instances, etc.

On Mon, Dec 19, 2016 at 12:19 PM, Marcio Montenegro <mtuxpe(a)gmail.com> wrote:
Hi all,
It´s easy to build TLM eddsytone package for Zephyr,
Unfortunately the data payload inside eddystone TLM is not fixed. ADV_CNT is
incremented after advertising and SEC_CNT is incremented after 0.1 second.
After calling bt_le_adv_start() I can´t find information if the last data
was transmitted and when the stack is ready for new data.
Is there any notification from radio on zephyr kernel ? If not any
suggestion of how notification or other solution can be implemented ?
Regards,

https://github.com/google/eddystone/blob/master/eddystone-tlm/tlm-plain.md
--
Luiz Augusto von Dentz


Eddystone TLM

Marcio Montenegro
 

Hi all,
It´s easy to build TLM eddsytone package for Zephyr,
Unfortunately the data payload inside eddystone TLM is not fixed. ADV_CNT
is incremented after advertising and SEC_CNT is incremented after 0.1
second.
After calling bt_le_adv_start() I can´t find information if the last
data was transmitted and when the stack is ready for new data.
Is there any notification from radio on zephyr kernel ? If not any
suggestion of how notification or other solution can be implemented ?
Regards,

*https://github.com/google/eddystone/blob/master/eddystone-tlm/tlm-plain.md
<https://github.com/google/eddystone/blob/master/eddystone-tlm/tlm-plain.md>*


Daily JIRA Digest

donotreply@...
 

NEW JIRA items within last 24 hours: 6
[ZEP-1464] Review files in source tree and add missing licences
https://jira.zephyrproject.org/browse/ZEP-1464

[ZEP-1466] Memory Protection Unit Support
https://jira.zephyrproject.org/browse/ZEP-1466

[ZEP-1461] Add zephyr support to openocd upstream
https://jira.zephyrproject.org/browse/ZEP-1461

[ZEP-1463] Add Zephyr Support in segger SystemView
https://jira.zephyrproject.org/browse/ZEP-1463

[ZEP-1465] Daily Fossology builds to check for licensing issues and violations
https://jira.zephyrproject.org/browse/ZEP-1465

[ZEP-1467] Cleanup misc/ and move features to subsystems in subsys/
https://jira.zephyrproject.org/browse/ZEP-1467


UPDATED JIRA items within last 24 hours: 2
[ZEP-931] Finalize kernel file naming & locations
https://jira.zephyrproject.org/browse/ZEP-931

[ZEP-630] Features support matrix for supported boards
https://jira.zephyrproject.org/browse/ZEP-630


CLOSED JIRA items within last 24 hours: 2
[ZEP-1308] (Fixed) zephyr thread function k_sleep does'nt work with nrf51822
https://jira.zephyrproject.org/browse/ZEP-1308

[ZEP-1357] (Fixed) iot/dns: Client is broken
https://jira.zephyrproject.org/browse/ZEP-1357


RESOLVED JIRA items within last 24 hours: 0


Daily Gerrit Digest

donotreply@...
 

NEW within last 24 hours:
- https://gerrit.zephyrproject.org/r/9214 : x86: remove nano/micro wording
- https://gerrit.zephyrproject.org/r/9213 : scripts: fixed typo swab->swap
- https://gerrit.zephyrproject.org/r/9199 : logging: move sys_log to subsys/logging
- https://gerrit.zephyrproject.org/r/9212 : logging: fix ring buffer usage and initialize variables.
- https://gerrit.zephyrproject.org/r/9210 : kconfig: group options into menus
- https://gerrit.zephyrproject.org/r/9207 : x86: remove obsolete comment about tasks/fibers
- https://gerrit.zephyrproject.org/r/9195 : kernel: kconfig: move event logger options into file
- https://gerrit.zephyrproject.org/r/9206 : kernel: fixed description of THREAD_CUSTOM_DATA
- https://gerrit.zephyrproject.org/r/9196 : kernel: kconfig: move power management options out
- https://gerrit.zephyrproject.org/r/9198 : doc: rename shell section to simply: Shell
- https://gerrit.zephyrproject.org/r/9209 : kernel: move kernel code to kernel/ directly
- https://gerrit.zephyrproject.org/r/9193 : kernel: Isolate logger options
- https://gerrit.zephyrproject.org/r/9204 : debug: fixed style and align code
- https://gerrit.zephyrproject.org/r/9208 : kernel: merge kernel Kconfigs into one
- https://gerrit.zephyrproject.org/r/9205 : object_tracing: fixed style
- https://gerrit.zephyrproject.org/r/9197 : kconfig: remove unused TASK_DEBUG options
- https://gerrit.zephyrproject.org/r/9194 : kernel: kconfig: replace task/fiber with threads
- https://gerrit.zephyrproject.org/r/9203 : debug: move debug features from misc to subsys/debug
- https://gerrit.zephyrproject.org/r/9211 : tracing: rename CONFIG_DEBUG_TRACING_KERNEL_OBJECTS
- https://gerrit.zephyrproject.org/r/9192 : kernel: rename NANOKERNEL_TICKLESS_IDLE_SUPPORTED

UPDATED within last 24 hours:
- https://gerrit.zephyrproject.org/r/8960 : gpio: added support for the pulpino GPIO controller driver
- https://gerrit.zephyrproject.org/r/8930 : subsys: disk: Refactor disk_access stuff into a directory

MERGED within last 24 hours:
- https://gerrit.zephyrproject.org/r/9202 : doc: update architecture porting guide to unified kernel
- https://gerrit.zephyrproject.org/r/9200 : kernel/arch: remove obsolete instances of irq_connect
- https://gerrit.zephyrproject.org/r/9201 : kernel/arch: rename ARCH_HAS_NANO_FIBER_ABORT to ARCH_HAS_THREAD_ABORT
- https://gerrit.zephyrproject.org/r/9189 : kernel: set CONFIG_MDEF by default
- https://gerrit.zephyrproject.org/r/9167 : samples: add configuration for single threaded hello world
- https://gerrit.zephyrproject.org/r/9168 : kernel: fix warnings when CONFIG_MULTITHREADING=n
- https://gerrit.zephyrproject.org/r/9181 : kernel: initialize system work queue after kernel is up


Re: Zephyr JIRA maintenance Saturday Dec 17, 2016 @ 18:00 - 20:00 PT (Sun Dec 18, 2016 @ 02:00 - 04:00 UTC)

Andrew Grimberg <agrimberg@...>
 

This maintenance has now been completed.

-Andy-

On 12/17/2016 05:53 PM, Andrew Grimberg wrote:
This maintenance will be starting shortly.

-Andy-

On 12/16/2016 07:56 AM, Andrew Grimberg wrote:
What: The Linux Foundation will be performing an upgrade on the Zephyr
JIRA instance as well as trying to resolve some issues with issue
conversions that requires database changes

When: Saturday December 17, 2016 @ 18:00 - 20:00 PT (Sunday December 18,
2016 @ 02:00 - 04:00 UTC)

Why: The current version of JIRA is several minor point revisions behind
the current release. Additionally, there are several reports of problems
converting issues from one type to another and research indicates that a
few different versions of JIRA can be prone to this issue and it
requires database fixes with JIRA offline to resolve.

Impact: JIRA will be offline during most of the upgrade and will likely
be bounced a couple of times during it.

A start and end notice will be posted to the mailing lists as well as to
#zephyrproject on Freenode IRC.

-Andy-
--
Andrew J Grimberg
Systems Administrator
Release Engineering Team Lead
The Linux Foundation


Re: Zephyr JIRA maintenance Saturday Dec 17, 2016 @ 18:00 - 20:00 PT (Sun Dec 18, 2016 @ 02:00 - 04:00 UTC)

Andrew Grimberg <agrimberg@...>
 

This maintenance will be starting shortly.

-Andy-

On 12/16/2016 07:56 AM, Andrew Grimberg wrote:
What: The Linux Foundation will be performing an upgrade on the Zephyr
JIRA instance as well as trying to resolve some issues with issue
conversions that requires database changes

When: Saturday December 17, 2016 @ 18:00 - 20:00 PT (Sunday December 18,
2016 @ 02:00 - 04:00 UTC)

Why: The current version of JIRA is several minor point revisions behind
the current release. Additionally, there are several reports of problems
converting issues from one type to another and research indicates that a
few different versions of JIRA can be prone to this issue and it
requires database fixes with JIRA offline to resolve.

Impact: JIRA will be offline during most of the upgrade and will likely
be bounced a couple of times during it.

A start and end notice will be posted to the mailing lists as well as to
#zephyrproject on Freenode IRC.

-Andy-
--
Andrew J Grimberg
Systems Administrator
Release Engineering Team Lead
The Linux Foundation


Daily JIRA Digest

donotreply@...
 

NEW JIRA items within last 24 hours: 5
[ZEP-1457] Add SPDX Tags to Zephyr licence boilerplate
https://jira.zephyrproject.org/browse/ZEP-1457

[ZEP-1455] ARM Cortex-M7: add support for non-cacheable RAM region
https://jira.zephyrproject.org/browse/ZEP-1455

[ZEP-1460] Sanity check reports some qemu step failures as 'build_error'
https://jira.zephyrproject.org/browse/ZEP-1460

[ZEP-1456] Asserts on nrf51 running Bluetooth hci_uart sample
https://jira.zephyrproject.org/browse/ZEP-1456

[ZEP-1458] tests/legacy/kernel/test_events: failure on ARC platforms
https://jira.zephyrproject.org/browse/ZEP-1458


UPDATED JIRA items within last 24 hours: 6
[ZEP-1400] IoTivity
https://jira.zephyrproject.org/browse/ZEP-1400

[ZEP-1387] Add a driver for HW Crypto module
https://jira.zephyrproject.org/browse/ZEP-1387

[ZEP-1320] Update Porting Guide
https://jira.zephyrproject.org/browse/ZEP-1320

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

[ZEP-1230] Optimize interrupt return code on ARC.
https://jira.zephyrproject.org/browse/ZEP-1230

[ZEP-1440] Kconfig choice for MINIMAL_LIBC vs NEWLIB_LIBC is not selectable
https://jira.zephyrproject.org/browse/ZEP-1440


CLOSED JIRA items within last 24 hours: 2
[ZEP-1361] (Fixed) IP stack is broken
https://jira.zephyrproject.org/browse/ZEP-1361

[ZEP-1454] (Fixed) CI is too strict with commit message line lengths
https://jira.zephyrproject.org/browse/ZEP-1454


RESOLVED JIRA items within last 24 hours: 0


Daily Gerrit Digest

donotreply@...
 

NEW within last 24 hours:
- https://gerrit.zephyrproject.org/r/9188 : dhcpv4: Adjust prj file selection.
- https://gerrit.zephyrproject.org/r/9187 : dhcpv4_client: Remove unnecessary ETH_KSDK configuration.
- https://gerrit.zephyrproject.org/r/9181 : kernel: initialize system work queue after kernel is up
- https://gerrit.zephyrproject.org/r/9186 : k64f: Default the ETH_KSDK on if NET_L2_ETHERNET enabled.
- https://gerrit.zephyrproject.org/r/9180 : Revert "kernel/arch: enhance the "ready thread" cache"
- https://gerrit.zephyrproject.org/r/9179 : Revert "kernel: fix warnings when CONFIG_MULTITHREADING=n"
- https://gerrit.zephyrproject.org/r/9178 : Revert "kernel: introduce single-threaded kernel"
- https://gerrit.zephyrproject.org/r/9177 : Revert "kernel: enable and optimize coop-only configurations"
- https://gerrit.zephyrproject.org/r/9176 : Revert "kernel: enhance realtime-ness when handling timeouts"
- https://gerrit.zephyrproject.org/r/9175 : Revert "kernel: fix dummy init thread prio in preempt-only configurations"
- https://gerrit.zephyrproject.org/r/9182 : tinycrypt: Update TinyCrypt to version 0.2.5
- https://gerrit.zephyrproject.org/r/9167 : samples: add configuration for single threaded hello world
- https://gerrit.zephyrproject.org/r/9168 : kernel: fix warnings when CONFIG_MULTITHREADING=n
- https://gerrit.zephyrproject.org/r/9147 : DRAFT: DO NOT MERGE: set SPDX identifier

UPDATED within last 24 hours:
- https://gerrit.zephyrproject.org/r/9112 : tests: spi: correct a spi buffer length issue
- https://gerrit.zephyrproject.org/r/9053 : cc3200: Use peripheral driver library functions from ROM
- https://gerrit.zephyrproject.org/r/5895 : DONT MERGE - test CI time with only 1 level
- https://gerrit.zephyrproject.org/r/4457 : DONT MERGE - cause checkpatch warnings
- https://gerrit.zephyrproject.org/r/7664 : second test
- https://gerrit.zephyrproject.org/r/9026 : Bluetooth: AVDTP: Add AVDTP_RTX_Timer & Handler
- https://gerrit.zephyrproject.org/r/8813 : driver: ethernet: adds reset signal to enc28j60 driver

MERGED within last 24 hours:
- https://gerrit.zephyrproject.org/r/9149 : samples: bmi160: code clean up
- https://gerrit.zephyrproject.org/r/9166 : boards: define onboard LED on quark se c1000 devboard
- https://gerrit.zephyrproject.org/r/9150 : Merge net branch into master
- https://gerrit.zephyrproject.org/r/9151 : Bluetooth: Fix priority event buffer availability when ECC is used
- https://gerrit.zephyrproject.org/r/9148 : net: nbuf: Initialize nbuf memory area after allocation
- https://gerrit.zephyrproject.org/r/9049 : sanity: filter the build-all test for ethernet
- https://gerrit.zephyrproject.org/r/9025 : Bluetooth: AVDTP: Fix Coding style
- https://gerrit.zephyrproject.org/r/9144 : sample: net: Updating qemu config for 802.15.4 testing
- https://gerrit.zephyrproject.org/r/9143 : samples: net: Fix echo applications setting for 15.4
- https://gerrit.zephyrproject.org/r/9142 : net: buf: Use buf->pool instead of now removed buf->free
- https://gerrit.zephyrproject.org/r/9140 : power_mgr: Update sample app with ARC DEEP_SLEEP
- https://gerrit.zephyrproject.org/r/9012 : samples: bmi160: use direct GPIO trigger instead of ipm
- https://gerrit.zephyrproject.org/r/9073 : drivers: bmi160: use direct GPIO trigger instead of IPM
- https://gerrit.zephyrproject.org/r/9075 : samples: bmi160: replace printf with printk
- https://gerrit.zephyrproject.org/r/9109 : Commit Message: Relax validation of lines length in commit messages


Zephyr JIRA maintenance Saturday Dec 17, 2016 @ 18:00 - 20:00 PT (Sun Dec 18, 2016 @ 02:00 - 04:00 UTC)

Andrew Grimberg <agrimberg@...>
 

What: The Linux Foundation will be performing an upgrade on the Zephyr
JIRA instance as well as trying to resolve some issues with issue
conversions that requires database changes

When: Saturday December 17, 2016 @ 18:00 - 20:00 PT (Sunday December 18,
2016 @ 02:00 - 04:00 UTC)

Why: The current version of JIRA is several minor point revisions behind
the current release. Additionally, there are several reports of problems
converting issues from one type to another and research indicates that a
few different versions of JIRA can be prone to this issue and it
requires database fixes with JIRA offline to resolve.

Impact: JIRA will be offline during most of the upgrade and will likely
be bounced a couple of times during it.

A start and end notice will be posted to the mailing lists as well as to
#zephyrproject on Freenode IRC.

-Andy-

--
Andrew J Grimberg
Systems Administrator
Release Engineering Team Lead
The Linux Foundation


Daily JIRA Digest

donotreply@...
 

NEW JIRA items within last 24 hours: 0

UPDATED JIRA items within last 24 hours: 16
[ZEP-1313] porting and user guides must include a security section
https://jira.zephyrproject.org/browse/ZEP-1313

[ZEP-1038] Hard real-time interrupt support
https://jira.zephyrproject.org/browse/ZEP-1038

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

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

[ZEP-1292] Update external mbed TLS library to latest version (2.4.0)
https://jira.zephyrproject.org/browse/ZEP-1292

[ZEP-628] Validate RPL Routing node support
https://jira.zephyrproject.org/browse/ZEP-628

[ZEP-797] Internet Group Management Protocol (IGMP) v2
https://jira.zephyrproject.org/browse/ZEP-797

[ZEP-1172] Update logger Api to allow using a hook for SYS_LOG_BACKEND_FN function
https://jira.zephyrproject.org/browse/ZEP-1172

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

[ZEP-749] TinyCrypt uses an old, unoptimized version of micro-ecc
https://jira.zephyrproject.org/browse/ZEP-749

[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-1454] CI is too strict with commit message line lengths
https://jira.zephyrproject.org/browse/ZEP-1454

[ZEP-1448] Samples/net/mbedtls_sslclient:Build fail as net/ip_buf.h can not be found
https://jira.zephyrproject.org/browse/ZEP-1448

[ZEP-1357] iot/dns: Client is broken
https://jira.zephyrproject.org/browse/ZEP-1357


CLOSED JIRA items within last 24 hours: 9
[ZEP-793] (Fixed) DNS Resolver
https://jira.zephyrproject.org/browse/ZEP-793

[ZEP-785] (Won't Do) Enable MQTT Paho samples to run on quark se board
https://jira.zephyrproject.org/browse/ZEP-785

[ZEP-1417] (Won't Do) Invalid bluetooth address displayed on show dev info identity
https://jira.zephyrproject.org/browse/ZEP-1417

[ZEP-1422] (Duplicate) Arduino_101 doesn't response ipv6 ping request affer enable echo_client ipv6
https://jira.zephyrproject.org/browse/ZEP-1422

[ZEP-1249] (Fixed) eth_ksdk is broken by unified kernel upgrade
https://jira.zephyrproject.org/browse/ZEP-1249

[ZEP-1444] (Duplicate) Arduino_101 doesn't response ipv4 ping request affer enable ipv4
https://jira.zephyrproject.org/browse/ZEP-1444

[ZEP-606] (Fixed) Doc files deleted from gerrit aren't deleted from website
https://jira.zephyrproject.org/browse/ZEP-606

[ZEP-1453] (Duplicate) board defconfig prevents custom configurations
https://jira.zephyrproject.org/browse/ZEP-1453

[ZEP-603] (Won't Do) In coap_server sample application, observable resource does not generate notification with 5.00 (Internal server error) if content-format gets modified
https://jira.zephyrproject.org/browse/ZEP-603


RESOLVED JIRA items within last 24 hours: 0


Daily Gerrit Digest

donotreply@...
 

NEW within last 24 hours:
- https://gerrit.zephyrproject.org/r/9144 : sample: net: Updating qemu config for 802.15.4 testing
- https://gerrit.zephyrproject.org/r/9096 : net: ip: Improve logging by adding a dedicated sys_log level
- https://gerrit.zephyrproject.org/r/9142 : net: buf: Use buf->pool instead of now removed buf->free
- https://gerrit.zephyrproject.org/r/9095 : net: buf: Change NET_BUF_DEBUG to NET_BUF_LOG and add a level option
- https://gerrit.zephyrproject.org/r/9145 : net: log: Do not select STDOUT_CONSOLE
- https://gerrit.zephyrproject.org/r/9146 : net: buf: Let's make use of func/line parameters when available
- https://gerrit.zephyrproject.org/r/9143 : samples: net: Fix echo applications setting for 15.4
- https://gerrit.zephyrproject.org/r/9140 : power_mgr: Update sample app with ARC DEEP_SLEEP
- https://gerrit.zephyrproject.org/r/9115 : Bluetooth: RFCOMM: Remove unneeded NULL checks
- https://gerrit.zephyrproject.org/r/9109 : Commit Message: Relax validation of lines length in commit messages
- https://gerrit.zephyrproject.org/r/9112 : tests: spi: correct a spi buffer length issue
- https://gerrit.zephyrproject.org/r/9111 : test message: please ignore
- https://gerrit.zephyrproject.org/r/9106 : net: tcp: Precompute appdata properly

UPDATED within last 24 hours:
- https://gerrit.zephyrproject.org/r/9026 : Bluetooth: AVDTP: Add AVDTP_RTX_Timer & Handler
- https://gerrit.zephyrproject.org/r/9015 : Bluetooth: AVDTP: Add AVDTP Pending Request
- https://gerrit.zephyrproject.org/r/9025 : Bluetooth: AVDTP: Fix Coding style
- https://gerrit.zephyrproject.org/r/5504 : dma: Introduce STM32F4x DMA driver
- https://gerrit.zephyrproject.org/r/8813 : driver: ethernet: adds reset signal to enc28j60 driver
- https://gerrit.zephyrproject.org/r/9075 : samples: bmi160: replace printf with printk
- https://gerrit.zephyrproject.org/r/9012 : samples: bmi160: use direct GPIO trigger instead of ipm
- https://gerrit.zephyrproject.org/r/9073 : drivers: bmi160: use direct GPIO trigger instead of IPM
- https://gerrit.zephyrproject.org/r/6291 : Bluetooth: SDP: Initial SDP client interface API
- https://gerrit.zephyrproject.org/r/7263 : Bluetooth: HFP HF: Implement missing callback for indicators
- https://gerrit.zephyrproject.org/r/7076 : Bluetooth: AT: Change API name skip_whitespace to skip_space
- https://gerrit.zephyrproject.org/r/7029 : Bluetooth: AT: Command parsing for range of values
- https://gerrit.zephyrproject.org/r/7028 : Bluetooth: AT: Improve API() to work with buffer increment
- https://gerrit.zephyrproject.org/r/7030 : Bluetooth: HFP HF: SLC Connection send/parse CIND
- https://gerrit.zephyrproject.org/r/7077 : Bluetooth: HFP HF: SLC query indicators present value
- https://gerrit.zephyrproject.org/r/7613 : soc/stm32: add initial support for STM32F3X series
- https://gerrit.zephyrproject.org/r/7614 : boards: add initial support for Nucleo-64 with Soc STM32F334
- https://gerrit.zephyrproject.org/r/7611 : boards: add initial support for STM3210C-EVAL board with SoC STM32F107VC
- https://gerrit.zephyrproject.org/r/7622 : clock/stm32: add STM32F107 reset and clock control
- https://gerrit.zephyrproject.org/r/7623 : clock/stm32: add STM32F3X reset and clock control
- https://gerrit.zephyrproject.org/r/9053 : cc3200: Use peripheral driver library functions from ROM
- https://gerrit.zephyrproject.org/r/9030 : counter: cmsdk: Add clock control to TMR Counters.
- https://gerrit.zephyrproject.org/r/9000 : soc: arm: beetle: Add Timers IRQ map
- https://gerrit.zephyrproject.org/r/8960 : gpio: added support for the pulpino GPIO controller driver
- https://gerrit.zephyrproject.org/r/9001 : counter: cmsdk: Add Timer 0 and 1 as Timers
- https://gerrit.zephyrproject.org/r/8917 : net: tcp: Select correct source address for SYNACK packets
- https://gerrit.zephyrproject.org/r/9009 : net: tcp: Swap tcp->context backpointers
- https://gerrit.zephyrproject.org/r/8714 : [DO NOT SUBMIT] RFC: Bluetooth: SDP client API user concept draft
- https://gerrit.zephyrproject.org/r/9094 : tests: bitfield: exclude riscv since it is not supported
- https://gerrit.zephyrproject.org/r/8711 : timer: added support for the riscv-qemu timer driver
- https://gerrit.zephyrproject.org/r/8713 : boards: added support for the qemu_riscv32 board
- https://gerrit.zephyrproject.org/r/9093 : sanitycheck: add support for risc v boards
- https://gerrit.zephyrproject.org/r/9091 : libc: add support for risc v
- https://gerrit.zephyrproject.org/r/7066 : unified: added _MOVE_INSTR for RISCV32 architecture
- https://gerrit.zephyrproject.org/r/8710 : riscv32: added support for the riscv32-qemu soc
- https://gerrit.zephyrproject.org/r/8709 : riscv32: added support for the pulpino soc
- https://gerrit.zephyrproject.org/r/8712 : serial: added support for the riscv-qemu UART driver
- https://gerrit.zephyrproject.org/r/7063 : scripts: added Makefile to handle an external riscv32 toolchain
- https://gerrit.zephyrproject.org/r/7065 : kernel: updated default IDLE_STACK_SIZE to 512 for RISCV32
- https://gerrit.zephyrproject.org/r/7064 : arch: added support for the riscv32 architecture
- https://gerrit.zephyrproject.org/r/7067 : timer: added timer driver for the pulpino SOC
- https://gerrit.zephyrproject.org/r/9092 : sanitycheck: riscv: add vector to recognised sections
- https://gerrit.zephyrproject.org/r/7068 : boards: added support for the zedboard_pulpino board
- https://gerrit.zephyrproject.org/r/7615 : boards: add initial support for STM32373C-EVAL with SoC STM32F373VC

MERGED within last 24 hours:
- https://gerrit.zephyrproject.org/r/9141 : MAINTAINERS: fixed email for sensor subsystem
- https://gerrit.zephyrproject.org/r/9118 : Bluetooth: GATT: Add BT_GATT_PERM_NONE convenience value
- https://gerrit.zephyrproject.org/r/9114 : drivers: sensor: replace device sync APIs with semaphores
- https://gerrit.zephyrproject.org/r/9117 : uart_cmsdk_apb: Fix cut'n'paste error in device 4 init code
- https://gerrit.zephyrproject.org/r/9116 : Bluetooth: samples: Add extern "C" { } block to GATT header files
- https://gerrit.zephyrproject.org/r/9105 : iot/dns: Add support for the FRDM K64F board
- https://gerrit.zephyrproject.org/r/9097 : iot/dns: Update Makefile
- https://gerrit.zephyrproject.org/r/9108 : iot/dns: Fix IPv6 compilation issue
- https://gerrit.zephyrproject.org/r/9104 : libc: rework libc selection and reduce Kconfigs
- https://gerrit.zephyrproject.org/r/9100 : kernel: enable and optimize coop-only configurations
- https://gerrit.zephyrproject.org/r/9098 : kernel: add k_cpu_idle/k_cpu_atomic_idle()
- https://gerrit.zephyrproject.org/r/9099 : kernel: add CONFIG_PREEMPT_ENABLED and CONFIG_COOP_ENABLED
- https://gerrit.zephyrproject.org/r/9102 : arch/all: simpler _SysFatalErrorHandler()
- https://gerrit.zephyrproject.org/r/9103 : kernel: introduce single-threaded kernel
- https://gerrit.zephyrproject.org/r/9101 : kernel: fix dummy init thread prio in preempt-only configurations
- https://gerrit.zephyrproject.org/r/9107 : Ship builds logs for meta-zephyr-sdk
- https://gerrit.zephyrproject.org/r/9088 : Merge bluetooth branch into master
- https://gerrit.zephyrproject.org/r/9029 : drivers: timer: Optimize RTC driver and prevent past events
- https://gerrit.zephyrproject.org/r/8802 : board: add initial support for Nucleo-64 with Soc STM32F411RE
- https://gerrit.zephyrproject.org/r/8987 : gpio: nrf5x: Add support for GPIOTE and GPIO callbacks
- https://gerrit.zephyrproject.org/r/9051 : frdm_k64f: Fix basic button sample
- https://gerrit.zephyrproject.org/r/9050 : frdm_k64f: hexiwear_k64: Fix basic blinky sample
- https://gerrit.zephyrproject.org/r/8982 : kernel/timers: move tick computation out of irq_lock block
- https://gerrit.zephyrproject.org/r/8981 : kernel: add defines for delta_ticks_from_prev special values
- https://gerrit.zephyrproject.org/r/8985 : kernel: fix typo
- https://gerrit.zephyrproject.org/r/8983 : kernel: fix mis-use of sys_dlist_t vs sys_dnode_t in _timeout
- https://gerrit.zephyrproject.org/r/8984 : sample/philosphers: ignore format-security warning
- https://gerrit.zephyrproject.org/r/8811 : kernel/arch: enhance the "ready thread" cache
- https://gerrit.zephyrproject.org/r/8986 : kernel: enhance realtime-ness when handling timeouts
- https://gerrit.zephyrproject.org/r/9010 : cc3200: Move UART peripheral clock enable into soc init
- https://gerrit.zephyrproject.org/r/9047 : openocd: Upgrade ARC
- https://gerrit.zephyrproject.org/r/9046 : newlib: Use upstream repository for IAMCU
- https://gerrit.zephyrproject.org/r/9048 : hosttools-tarball: remove openocd-legacy
- https://gerrit.zephyrproject.org/r/6913 : power: Add ARC core suspend and resume support
- https://gerrit.zephyrproject.org/r/6911 : arcv2_irq: Add power management suspend/resume
- https://gerrit.zephyrproject.org/r/9045 : binutils (ARC): Cleanup
- https://gerrit.zephyrproject.org/r/9006 : arm: add CPU_CORTEX_M_HAS_BASEPRI kconfig flag
- https://gerrit.zephyrproject.org/r/9007 : arm: move IRQ_PRIORITY_OFFSET to header file, rename to _IRQ_PRIO_OFFSET
- https://gerrit.zephyrproject.org/r/9040 : arm: add CPU_CORTEX_M_HAS_PROGRAMMABLE_FAULT_PRIOS kconfig flag
- https://gerrit.zephyrproject.org/r/9041 : arm: better handling of IRQ priorities reserved by the kernel
- https://gerrit.zephyrproject.org/r/9042 : arm: relinquish one IRQ priority reserved by kernel


Re: gpio pin configuration.

Marcus Shawcroft <marcus.shawcroft@...>
 

On 16 December 2016 at 09:52, Tomasz Bursztyka
<tomasz.bursztyka(a)linux.intel.com> wrote:

It was just a naming proposal, instead of:

GPIO_DS_0_HIGH
GPIO_DS_0_DISCONNECT
and
GPIO_DS_1_HIGH
GPIO_DS_1_DISCONNECT

we would have:
GPIO_DS_DFLT_HIGH (or *_DEFAULT_*)
GPIO_DS_DFLT_DISCONNECT

and:
GPIO_DS_ALT_HIGH (or *_ALTERNATE_*)
GPIO_DS_ALT_DISCONNECT

Of course my naming proposal is bogus. If I understand, should it be
GPIO_DS_OUTPUT_<LOW/HIGH or 0/1>_<HIGH/DISCONNECT> or?

It's just the _0_ and _1_ alone that are not telling anything by themselves.
Understood.

_low_ _high_ does make sense.

Cheers
/Marcus


Re: gpio pin configuration.

Tomasz Bursztyka
 

Hi Marcus,

I've failed to parse exactly what you mean here, either:
- you are referring to the 0 << 12 vs 1 << 12 and suggesting that the
GPIO_DS_[01]_STANDARD serves no purpose since it conveys no additional
information over and above simply not specifying any flag at all.
or
- you are referring to the two groups of flags GPIO_DS_0_* and
GPIO_DS_1_*, in which case I failed to clearly articulate the
intention that the mode/behaviour of the pin should be independently
configurable depending whether it is currently outputting a 0 or
outputting a 1 (nrf5 HW is one example of HW that supports this degree
of flexibility).
It was just a naming proposal, instead of:

GPIO_DS_0_HIGH
GPIO_DS_0_DISCONNECT
and
GPIO_DS_1_HIGH
GPIO_DS_1_DISCONNECT

we would have:
GPIO_DS_DFLT_HIGH (or *_DEFAULT_*)
GPIO_DS_DFLT_DISCONNECT

and:
GPIO_DS_ALT_HIGH (or *_ALTERNATE_*)
GPIO_DS_ALT_DISCONNECT

Of course my naming proposal is bogus. If I understand, should it be
GPIO_DS_OUTPUT_<LOW/HIGH or 0/1>_<HIGH/DISCONNECT> or?

It's just the _0_ and _1_ alone that are not telling anything by themselves.

Tomasz


Re: gpio pin configuration.

Marcus Shawcroft <marcus.shawcroft@...>
 

Hi Tomasz,

On 15 December 2016 at 10:31, Tomasz Bursztyka
<tomasz.bursztyka(a)linux.intel.com> wrote:

Something along the lines of:

#define GPIO_DS_0_STANDARD 0 <<12
#define GPIO_DS_0_HIGH 1 << 12
#define GPIO_DS_0_DISCONNECTED 2 <<12

1 << 13
The three modes standard, high, disconnected are mutually exclusive
hence the proposal to represent them as three values encoded in a two
bit field, the fourth possible encoding effectively becomes reserved
for future use. The two separate fields allow for the behaviour of
the pin to be configured independently when outputting a 0 or a 1. If
we were to stick with boolean flags only then we could do something
like:

#define GPIO_DS_0_HIGH 1 << 12
#define GPIO_DS_0_DISCONNECT 1<<13
#define GPIO_DS_1_HIGH 1 << 14
#define GPIO_DS_1_DISCONNECT 1<<15

(your point about BIT() taken).

In this scheme:
- the presence (or absence) of *_HIGH selects between the HWs standard
drive strength and a high/alternative drive strength (if supported).
- the {0,1}_DISCONNECT flag selects a high impedance/disconnected
behaviour for 0/1 output respectively, hence this flag would always,
irrespective of hw/driver, be mutually exclusive with the {0,1}_HIGH
flag.

I think the first view with multiple mutually exclusive values in a
single field to be the more intuitive of the two representations, but
I don;t feel strongly on this issue.

The standard drive strength flags are deliberately choosen to be 0
such that any existing user of the interface that does not specify a
drive strength flag will get the current behaviour of 'standard' drive
strength.

What about GPIO_DS_DFLT_* and GPIO_DF_ALT_*
0 and 1 are not telling much.
I've failed to parse exactly what you mean here, either:
- you are referring to the 0 << 12 vs 1 << 12 and suggesting that the
GPIO_DS_[01]_STANDARD serves no purpose since it conveys no additional
information over and above simply not specifying any flag at all.
or
- you are referring to the two groups of flags GPIO_DS_0_* and
GPIO_DS_1_*, in which case I failed to clearly articulate the
intention that the mode/behaviour of the pin should be independently
configurable depending whether it is currently outputting a 0 or
outputting a 1 (nrf5 HW is one example of HW that supports this degree
of flexibility).


Cheers
/Marcus


Re: gpio pin configuration.

Marcus Shawcroft <marcus.shawcroft@...>
 

On 15 December 2016 at 19:21, Chuck Jordan <Chuck.Jordan(a)synopsys.com> wrote:
However that doesn't cover the scenario where the gpio pin is being used by another peripheral in the SOC and the gpio_pin_write() implementation is not in the loop.
Ummmm. If the power-up-reset state of any GPIO is "input", then no software is necessary. If this is NOT true, then on any given target, code should be putting UNUSED gpio pins to input as an initial startup mode as early as possible. If they do not, lots of power can be wasted if the other side is also driving it as an output. It can also be DANGEROUS I think -- almost like a short.
I'm not an expert in this area though ... so perhaps someone who is can chime in.
An example of the scenario above would be an nrf5 i2c driver that
needs to use the nrf5 gpio driver to put the two pins used for clock
and data into an open collector mode.

Cheers
/Marcus


Re: gpio pin configuration.

Chuck Jordan <Chuck.Jordan@...>
 

However that doesn't cover the scenario where the gpio pin is being used by another peripheral in the SOC and the gpio_pin_write() implementation is not in the loop.
Ummmm. If the power-up-reset state of any GPIO is "input", then no software is necessary. If this is NOT true, then on any given target, code should be putting UNUSED gpio pins to input as an initial startup mode as early as possible. If they do not, lots of power can be wasted if the other side is also driving it as an output. It can also be DANGEROUS I think -- almost like a short.
I'm not an expert in this area though ... so perhaps someone who is can chime in.

-ChuckJ

-----Original Message-----
From: Marcus Shawcroft [mailto:marcus.shawcroft(a)gmail.com]
Sent: Thursday, December 15, 2016 2:19 AM
To: Chuck Jordan <Chuck.Jordan(a)synopsys.com>
Cc: devel(a)lists.zephyrproject.org
Subject: Re: [devel] gpio pin configuration.

Hi Chuck,

On 15 December 2016 at 02:04, Chuck Jordan <Chuck.Jordan(a)synopsys.com> wrote:
QUESTION: For those GPIO targets that don't support "disconnect", is that the same as setting it to "input"?
Is "disconnect" different from "input"? For example, would input be a load to the other side, and influence a transistor, where as "disconnect" is truly floating and truly NOT going to sink any current -- except into the surrounding air.
Configuring GPIO_DS_0_STANDARD | GPIO_DS_1_DISCONNECT is essentially setting up a pin as an open collector output. The pin is driven to 0, but a 1 output is left high impedance. I can imagine that a driver for HW that does not have support for this mode of operation could synthesize the behaviour by configuring the pin for input or otherwise disabling the pin within the driver code that implements gpio_pin_write(). I don't know if there are pitfalls in attempting to construct an open collector output in this manner. Iff this trick works, then one might argue that no additional gpio_pin_configure() flags are necessary to support open collector behaviour like this, instead, it can all be handled by flipping the configuration between output to drive a 0 and input for high impedance. However that doesn't cover the scenario where the gpio pin is being used by another peripheral in the SOC and the gpio_pin_write() implementation is not in the loop.

Cheers
/Marcus


-ChuckJ

-----Original Message-----
From: Marcus Shawcroft [mailto:marcus.shawcroft(a)gmail.com]
Sent: Wednesday, December 14, 2016 2:01 PM
To: devel(a)lists.zephyrproject.org
Subject: [devel] gpio pin configuration.

Hi,

The current include/gpio.h interface allows for basic configuration of a gpio pin.

The nRF5 hardware supports three different configurable drive strengths on each pin, independently for 0 and 1 outputs. The relevant manual describes these drive strengths as standard, high and disconnected. All permutations are supported with the exception of disconnected on 0 output + disconnected on 1 output.

The current nRF5 driver simply hardwires the standard drive stength for both 0 and 1 outputs.

Extending gpio.h to allow selection of at least some of the other modes is a pre-requisite for an nRF5 I2C driver. (The two pins used for I2C need to be placed into one of the disconnected modes).

I'm looking at adding two new fields into the gpio configuration 'flags', one field to configure the 0 output drive strength, the other field to configure the 1 output drive strength.

Something along the lines of:

#define GPIO_DS_0_STANDARD 0 <<12
#define GPIO_DS_0_HIGH 1 << 12
#define GPIO_DS_0_DISCONNECTED 2 <<12

#define GPIO_DS_1_STANDARD 0 <<14
#define GPIO_DS_1_HIGH 1 << 14
#define GPIO_DS_1_DISCONNECTED 2 <<14

The standard drive strength flags are deliberately choosen to be 0 such that any existing user of the interface that does not specify a drive strength flag will get the current behaviour of 'standard' drive strength.

There are three possible routes to define the behaviour of a driver for HW that does not support any of these modes:
1) Default to standard drive strength
2) Return ENOSUP from configure.
3) __ASSERT

Of these, 2) feels like the wrong answer, what would an app do if it got -ENOSUP, 3) feels rather inflexible and awkward. Hence I'm tempted to go with 1).

The terms 'standard' and 'high' are arbitrary. They are inflexible if we have HW that perhaps supports more than two drive strengths. From an applications perspective it is not clear what contract the a driver is really offering.

I've been pondering this on an off for a while and havn't been able to come up with a more elegant scheme.

Thoughts welcome on a better approach??

Thanks
/Marcus

6461 - 6480 of 8520