Date   

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


Daily JIRA Digest

donotreply@...
 

NEW JIRA items within last 24 hours: 7
[ZEP-1452] cross-platform support for interrupt tables/code in RAM or ROM
https://jira.zephyrproject.org/browse/ZEP-1452

[ZEP-1449] samples: logger_hook
https://jira.zephyrproject.org/browse/ZEP-1449

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

[ZEP-1441] event logger: context switch event is not supported at ARC
https://jira.zephyrproject.org/browse/ZEP-1441

[ZEP-1447] zephyr/tests/crypto/test_mbedtls: when build the app `ROM' overflowed
https://jira.zephyrproject.org/browse/ZEP-1447

[ZEP-1443] Samples/net/zperf: Build fail as net_private.h can not be founld
https://jira.zephyrproject.org/browse/ZEP-1443

[ZEP-1442] Samples/net/dhcpv4_client: Build fail as No rule to make target `prj_.conf
https://jira.zephyrproject.org/browse/ZEP-1442


UPDATED JIRA items within last 24 hours: 50
[ZEP-1038] Hard real-time interrupt support
https://jira.zephyrproject.org/browse/ZEP-1038

[ZEP-1400] IoTivity
https://jira.zephyrproject.org/browse/ZEP-1400

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

[ZEP-819] 6LowPAN-GHC: Generic Header Compression for IPv6
https://jira.zephyrproject.org/browse/ZEP-819

[ZEP-811] The Trickle Algorithm
https://jira.zephyrproject.org/browse/ZEP-811

[ZEP-822] Simple Network Management Protocol v2
https://jira.zephyrproject.org/browse/ZEP-822

[ZEP-799] HTTP over TLS
https://jira.zephyrproject.org/browse/ZEP-799

[ZEP-839] Thread Requirements on RFC6282
https://jira.zephyrproject.org/browse/ZEP-839

[ZEP-834] Thread Requirements on RFC1122
https://jira.zephyrproject.org/browse/ZEP-834

[ZEP-835] Thread Requirements on RFC2460
https://jira.zephyrproject.org/browse/ZEP-835

[ZEP-836] Thread Requirements on RFC4291
https://jira.zephyrproject.org/browse/ZEP-836

[ZEP-837] Thread Requirements on RFC4443
https://jira.zephyrproject.org/browse/ZEP-837

[ZEP-838] Thread Requirements on RFC4944
https://jira.zephyrproject.org/browse/ZEP-838

[ZEP-814] Routing Metrics used in Path Selection
https://jira.zephyrproject.org/browse/ZEP-814

[ZEP-815] Objective Function Zero for RPL
https://jira.zephyrproject.org/browse/ZEP-815

[ZEP-816] Minimum Rank with Hysteresis (RPL)
https://jira.zephyrproject.org/browse/ZEP-816

[ZEP-810] Network Time Protocol v4
https://jira.zephyrproject.org/browse/ZEP-810

[ZEP-886] 802.15.4 - MAC command frame support
https://jira.zephyrproject.org/browse/ZEP-886

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

[ZEP-742] nRF5x Series: System Clock driver using NRF_RTC
https://jira.zephyrproject.org/browse/ZEP-742

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

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

[ZEP-734] Port AES-CMAC-PRF-128 [RFC 4615] encryption library for Thread support
https://jira.zephyrproject.org/browse/ZEP-734

[ZEP-801] DNS Extensions to support IPv6
https://jira.zephyrproject.org/browse/ZEP-801

[ZEP-795] Path MTU Discovery for IPv6
https://jira.zephyrproject.org/browse/ZEP-795

[ZEP-800] DHCPv6
https://jira.zephyrproject.org/browse/ZEP-800

[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-1205] Create test for LIFO kernel object using native unified kernel API
https://jira.zephyrproject.org/browse/ZEP-1205

[ZEP-1207] Create test for semaphore kernel object using native unified kernel API
https://jira.zephyrproject.org/browse/ZEP-1207

[ZEP-1211] Create test for mutex kernel object using native unified kernel API
https://jira.zephyrproject.org/browse/ZEP-1211

[ZEP-1206] Create test for FIFO kernel object using native unified kernel API
https://jira.zephyrproject.org/browse/ZEP-1206

[ZEP-1213] Create test for stack kernel object using native unified kernel API
https://jira.zephyrproject.org/browse/ZEP-1213

[ZEP-1216] Create test for pipe kernel object using native unified kernel API
https://jira.zephyrproject.org/browse/ZEP-1216

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

[ZEP-828] IPv6 - Multicast Join/Leave Support
https://jira.zephyrproject.org/browse/ZEP-828

[ZEP-806] Link-local Multicast Name Resolution
https://jira.zephyrproject.org/browse/ZEP-806

[ZEP-803] Dynamic Configurarion of IPv4 Link-local Addresses
https://jira.zephyrproject.org/browse/ZEP-803

[ZEP-817] Neighbor Discovery Optimization for IPv6 over 6LowPAN
https://jira.zephyrproject.org/browse/ZEP-817

[ZEP-802] DNS Configuration Options for DHCPv6
https://jira.zephyrproject.org/browse/ZEP-802

[ZEP-829] IPv4 - Multicast Join/Leave Support
https://jira.zephyrproject.org/browse/ZEP-829

[ZEP-808] IPv6 Stateless Autoconfiguration (SLAAC)
https://jira.zephyrproject.org/browse/ZEP-808

[ZEP-963] Consolidate different versions of DEVICE_* and SYS_* macros
https://jira.zephyrproject.org/browse/ZEP-963

[ZEP-1012] NATS client port to new IP stack
https://jira.zephyrproject.org/browse/ZEP-1012

[ZEP-812] Compression Format for IPv6 over 802.15.4
https://jira.zephyrproject.org/browse/ZEP-812

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

[ZEP-883] IP Stack L2 Interface Management API
https://jira.zephyrproject.org/browse/ZEP-883

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

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

[ZEP-1429] NXP MCR20A Driver
https://jira.zephyrproject.org/browse/ZEP-1429


CLOSED JIRA items within last 24 hours: 5
[ZEP-788] (Done) UDP
https://jira.zephyrproject.org/browse/ZEP-788

[ZEP-805] (Done) Internet Control Message Protocol (ICMP) v6
https://jira.zephyrproject.org/browse/ZEP-805

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

[ZEP-789] (Done) IPv4
https://jira.zephyrproject.org/browse/ZEP-789

[ZEP-1233] (Fixed) mbedDTLS DTLS client stability does not work on top of the tree for the net branch
https://jira.zephyrproject.org/browse/ZEP-1233


RESOLVED JIRA items within last 24 hours: 0


Daily Gerrit Digest

donotreply@...
 

NEW within last 24 hours:
- https://gerrit.zephyrproject.org/r/9091 : libc: add support for risc v
- https://gerrit.zephyrproject.org/r/9094 : tests: bitfield: exclude riscv since it is not supported
- https://gerrit.zephyrproject.org/r/9093 : sanitycheck: add support for risc v boards
- https://gerrit.zephyrproject.org/r/9092 : sanitycheck: riscv: add vector to recognised sections
- https://gerrit.zephyrproject.org/r/9088 : Merge bluetooth branch into master
- https://gerrit.zephyrproject.org/r/9077 : samples/mbedtls_sslclient: Using native IP stack
- https://gerrit.zephyrproject.org/r/9075 : samples: bmi160: replace printf with printk
- https://gerrit.zephyrproject.org/r/9073 : drivers: bmi160: use direct GPIO trigger instead of IPM
- https://gerrit.zephyrproject.org/r/9072 : boards: arm: add support for redbear ble nano 2
- https://gerrit.zephyrproject.org/r/9070 : net: statistics: Have a dedicated struct for rpl data
- https://gerrit.zephyrproject.org/r/9071 : net: statistics: Expose relevant information through net mgmt API

UPDATED within last 24 hours:
- https://gerrit.zephyrproject.org/r/7064 : arch: added support for the riscv32 architecture
- https://gerrit.zephyrproject.org/r/8711 : timer: added support for the riscv-qemu timer driver
- https://gerrit.zephyrproject.org/r/7067 : timer: added timer driver for the pulpino SOC
- https://gerrit.zephyrproject.org/r/8709 : riscv32: added support for the pulpino soc
- https://gerrit.zephyrproject.org/r/7615 : boards: add initial support for STM32373C-EVAL with SoC STM32F373VC
- https://gerrit.zephyrproject.org/r/7614 : boards: add initial support for Nucleo-64 with Soc STM32F334
- https://gerrit.zephyrproject.org/r/8960 : gpio: added support for the pulpino GPIO controller driver
- https://gerrit.zephyrproject.org/r/6291 : Bluetooth: SDP: Initial SDP client interface API
- https://gerrit.zephyrproject.org/r/7068 : boards: added support for the zedboard_pulpino board
- https://gerrit.zephyrproject.org/r/7066 : unified: added _MOVE_INSTR for RISCV32 architecture
- https://gerrit.zephyrproject.org/r/8713 : boards: added support for the qemu_riscv32 board
- https://gerrit.zephyrproject.org/r/8712 : serial: added support for the riscv-qemu UART driver
- https://gerrit.zephyrproject.org/r/7065 : kernel: updated default IDLE_STACK_SIZE to 512 for RISCV32
- https://gerrit.zephyrproject.org/r/7063 : scripts: added Makefile to handle an external riscv32 toolchain
- https://gerrit.zephyrproject.org/r/8710 : riscv32: added support for the riscv32-qemu soc
- https://gerrit.zephyrproject.org/r/7613 : soc/stm32: add initial support for STM32F3X series
- https://gerrit.zephyrproject.org/r/9010 : cc3200: Move UART peripheral clock enable into soc init
- https://gerrit.zephyrproject.org/r/9053 : cc3200: Use peripheral driver library functions from ROM
- https://gerrit.zephyrproject.org/r/7496 : soc/stm32f1: Add the new type of SoC STM32F107
- https://gerrit.zephyrproject.org/r/7611 : boards: add initial support for STM3210C-EVAL board with SoC STM32F107VC
- https://gerrit.zephyrproject.org/r/8985 : kernel: fix typo
- https://gerrit.zephyrproject.org/r/8984 : sample/philosphers: ignore format-security warning
- 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/8811 : kernel/arch: enhance the "ready thread" cache
- https://gerrit.zephyrproject.org/r/9029 : drivers: timer: Optimize RTC driver and prevent past events
- https://gerrit.zephyrproject.org/r/7661 : RFC: random: Add random driver for nRF5
- https://gerrit.zephyrproject.org/r/7622 : clock/stm32: add STM32F107 reset and clock control
- https://gerrit.zephyrproject.org/r/7625 : exti/stm32: add support for F334 & F373 MCUs
- https://gerrit.zephyrproject.org/r/7626 : flash/stm32: flash driver for STM32F3x series microcontrollers
- https://gerrit.zephyrproject.org/r/7623 : clock/stm32: add STM32F3X reset and clock control
- https://gerrit.zephyrproject.org/r/8714 : [DO NOT SUBMIT] RFC: Bluetooth: SDP client API user concept draft
- https://gerrit.zephyrproject.org/r/9052 : tests: crypto: mbedtls: Adding mbedTLS test suite for ECJPAKE
- https://gerrit.zephyrproject.org/r/7738 : RFC: Add device tree support for ARM platforms
- https://gerrit.zephyrproject.org/r/9012 : samples: bmi160: use direct GPIO trigger instead of ipm
- https://gerrit.zephyrproject.org/r/9067 : RFC: random: Introduce random device API.
- https://gerrit.zephyrproject.org/r/9051 : frdm_k64f: Fix basic button sample
- https://gerrit.zephyrproject.org/r/9035 : net: statistics: Provide specific Kconfig options
- https://gerrit.zephyrproject.org/r/9034 : net: statistics: Make statistics calculation fully private
- https://gerrit.zephyrproject.org/r/9033 : net: statistics: Move current statistics code to its own file
- https://gerrit.zephyrproject.org/r/9024 : dhcpv4: Provide prj file for frdm_k64f
- https://gerrit.zephyrproject.org/r/8824 : drivers: spi_k64: Set PCS as activ low and continuous per default
- https://gerrit.zephyrproject.org/r/9023 : k64f: Default the ETH_KSDK on if NET_L2_ETHERNET enabled.
- https://gerrit.zephyrproject.org/r/9050 : frdm_k64f: hexiwear_k64: Fix basic blinky sample
- https://gerrit.zephyrproject.org/r/8823 : drivers: spi_k64: Fix slave select

MERGED within last 24 hours:
- https://gerrit.zephyrproject.org/r/9087 : net: remove unused variable pkt1
- https://gerrit.zephyrproject.org/r/9086 : net: multicast_eth_addr is use only with IPV6
- https://gerrit.zephyrproject.org/r/9085 : net: remove unused variable dis
- https://gerrit.zephyrproject.org/r/9082 : drivers: spi: Fix the help on sys log level
- https://gerrit.zephyrproject.org/r/9083 : net: tests: Remove unused variables from dhcpv4 unit test
- https://gerrit.zephyrproject.org/r/9081 : Bluetooth: Remove unnecessary runtime kernel object initialization
- https://gerrit.zephyrproject.org/r/9080 : net: buf: Fix incorrect reference to net_buf_get_debug
- https://gerrit.zephyrproject.org/r/9079 : Bluetooth: RFCOMM: Fix channel range documentation
- https://gerrit.zephyrproject.org/r/9076 : iot/mqtt: Fix rlen_decode size check.
- https://gerrit.zephyrproject.org/r/9069 : Revert "samples/logger-hook: Initialize variable to 0"
- https://gerrit.zephyrproject.org/r/8925 : cc3200: Ensure UART can wake up Zephyr after wfi in idle
- https://gerrit.zephyrproject.org/r/9039 : Bluetooth: SMP: Add support for CT2 auth bit
- https://gerrit.zephyrproject.org/r/9038 : Bluetooth: SMP: Add H7 crypto implementation and unit tests
- https://gerrit.zephyrproject.org/r/7090 : arc: Define _arc_v2_irq_unit device
- https://gerrit.zephyrproject.org/r/6911 : arcv2_irq: Add power management suspend/resume
- https://gerrit.zephyrproject.org/r/6912 : arcv2_timer0: Add suspend and resume support
- https://gerrit.zephyrproject.org/r/6913 : power: Add ARC core suspend and resume support
- https://gerrit.zephyrproject.org/r/8903 : net: Fix incorrect logging format specifiers
- https://gerrit.zephyrproject.org/r/9066 : net: ieee802154: ACK reply needs to set all FCF attributes.
- https://gerrit.zephyrproject.org/r/9055 : net: buf: Introduce net_buf_destroy() wrapper
- https://gerrit.zephyrproject.org/r/9057 : net: buf: Remove the need for net_buf_pool_init()
- https://gerrit.zephyrproject.org/r/9059 : net: buf: Remove redundant user_data_size from buffers
- https://gerrit.zephyrproject.org/r/9056 : net: buf: Switch from k_fifo to k_lifo for free buffers
- https://gerrit.zephyrproject.org/r/9063 : Bluetooth: Controller: tune the xtal and hard realtime radio start offsets
- https://gerrit.zephyrproject.org/r/9018 : samples: net: Add dedicated dhcpv4 prj.conf for frdm k64f board
- https://gerrit.zephyrproject.org/r/8846 : samples: net: Add Arduino 101 dedicated config for dhcpv4_client
- https://gerrit.zephyrproject.org/r/8936 : drivers: eth_ksdk: Theres is no longer 'ETHERNET' Kconfig option
- https://gerrit.zephyrproject.org/r/8845 : samples: net: Remove useless prj.mdef from dhcpv4_client
- https://gerrit.zephyrproject.org/r/8854 : samples: net: mbedtls: Let's enable fastest enc28j60 speed on a101
- https://gerrit.zephyrproject.org/r/9017 : drivers: eth_ksdk: Simplifying MAC address generation
- https://gerrit.zephyrproject.org/r/8937 : drivers: eth_ksdk: There is a unique L2 driver
- https://gerrit.zephyrproject.org/r/8855 : drivers: enc28j60: Removing useless legacy driver
- https://gerrit.zephyrproject.org/r/8844 : drivers: enc28j60: Expose RX thread stack size and prio config
- https://gerrit.zephyrproject.org/r/8843 : drivers: enc28j60: Add logging
- https://gerrit.zephyrproject.org/r/8842 : drivers: ennc28j60: There is a unique L2 driver
- https://gerrit.zephyrproject.org/r/8841 : drivers: enc28j60: Fix one tiny naming issue
- https://gerrit.zephyrproject.org/r/8840 : drivers: enc28j60: Fix a Kconfig comment
- https://gerrit.zephyrproject.org/r/8839 : drivers: enc28j60: Fix a tiny style issue
- https://gerrit.zephyrproject.org/r/8838 : drivers: ethernet: Enable sys log levels depending on NET_ETHERNET_L2
- https://gerrit.zephyrproject.org/r/8837 : drivers: ethernet: Push DW specific Kconfig options to its own file
- https://gerrit.zephyrproject.org/r/8836 : drivers: enc28j60: Let's remove the CRC in the end of the frame
- https://gerrit.zephyrproject.org/r/8835 : net: l2: ethernet: Handle Ethernet II minimal frame size relevantly
- https://gerrit.zephyrproject.org/r/9049 : sanity: filter the build-all test for ethernet


ARC timer: straddled tick check and idle deep sleep

Julien Quelen <julienx.quelen@...>
 

Hi,

I am facing a conflict between the straddled tick check of the ARC timer0 and our implementation of the Idle+deepsleep mechanism.

In _timer_idle_enter(), if _ARC_V2_TMR_CTRL_IP bit is high, the flag straddled_tick_on_idle_enter is set high because we know that a timer0 interrupt is going to occur. Then, we abort _timer_idle_exit() in order to let _timer_int_handler() account for 1 tick.

However, in our implementation of the idle+deepsleep (ARC in low power) mode, we stop all ARC drivers, reset the timer0 and as a consequence, we lose the pending timer0 IRQ. So on idle+deepsleep exit, we do not jump into timer0 ISR. But straddled_tick_on_idle_enter is still high. And in the scenario where we program another Idle period just after the deepsleep, in the subsequent _timer_idle_exit(), we return without announcing the programmed ticks. The consequence is the loss of these programmed ticks -> OS delay in ticks counting.

A quick fix for that would be to reset to false straddled_tick_on_idle_enter flag in _sys_clock_driver_init(). I think that in general, it makes sense resetting to false straddled_tick_on_idle_enter flag while initializing the timer0 (when calling _sys_clock_driver_init())

Do you agree?


Re: gpio pin configuration.

Tomasz Bursztyka
 

Hi Marcus,

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


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

And actually, better use BIT() macro for all these flags.


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.


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
Preferably. Let's ignore the flags if it's unsupported.

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).
Definitely :)

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??
Let's wait for more reactions.

Tomasz


Re: gpio pin configuration.

Marcus Shawcroft <marcus.shawcroft@...>
 

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


Re: gpio pin configuration.

Chuck Jordan <Chuck.Jordan@...>
 

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.

-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


gpio pin configuration.

Marcus Shawcroft <marcus.shawcroft@...>
 

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


Daily JIRA Digest

donotreply@...
 

NEW JIRA items within last 24 hours: 4
[ZEP-1437] AIO: Fail to retrieve pending interrupt in ISR
https://jira.zephyrproject.org/browse/ZEP-1437

[ZEP-1438] AIO: AIO Comparator is not stable on Quark D2000
https://jira.zephyrproject.org/browse/ZEP-1438

[ZEP-1439] +1 verified from JobBuilder is not removed on patch rebase
https://jira.zephyrproject.org/browse/ZEP-1439

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


UPDATED JIRA items within last 24 hours: 14
[ZEP-1024] GPIO API Update
https://jira.zephyrproject.org/browse/ZEP-1024

[ZEP-1251] Abstract driver re-entrancy code
https://jira.zephyrproject.org/browse/ZEP-1251

[ZEP-293] Reduce Kconfig variables in sensor drivers
https://jira.zephyrproject.org/browse/ZEP-293

[ZEP-958] simplify pinmux interface and merge the pinmux_dev into one single API
https://jira.zephyrproject.org/browse/ZEP-958

[ZEP-552] Makefile can be enhanced to call out error when a configuration is not valid to build
https://jira.zephyrproject.org/browse/ZEP-552

[ZEP-781] Streamline GPIO, Pinmux driver API
https://jira.zephyrproject.org/browse/ZEP-781

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

[ZEP-578] handle configuration changes with more code coverage
https://jira.zephyrproject.org/browse/ZEP-578

[ZEP-1178] Provide a MinGW environment for Building on Windows
https://jira.zephyrproject.org/browse/ZEP-1178

[ZEP-1103] Propose and implement synchronization flow for multicore power management
https://jira.zephyrproject.org/browse/ZEP-1103

[ZEP-1181] zephyrSDK + newlib: unexpected warning raised when print "uint32_t" with "%u"
https://jira.zephyrproject.org/browse/ZEP-1181

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

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

[ZEP-1060] Contributor guide for documentation missing
https://jira.zephyrproject.org/browse/ZEP-1060


CLOSED JIRA items within last 24 hours: 3
[ZEP-1411] (Fixed) Deprecate device_sync_call API and use semaphore directly
https://jira.zephyrproject.org/browse/ZEP-1411

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

[ZEP-1433] (Fixed) Jira daily digest fails to install pip package
https://jira.zephyrproject.org/browse/ZEP-1433


RESOLVED JIRA items within last 24 hours: 0


Daily Gerrit Digest

donotreply@...
 

NEW within last 24 hours:
- https://gerrit.zephyrproject.org/r/9050 : frdm_k64f: hexiwear_k64: Fix basic blinky sample
- https://gerrit.zephyrproject.org/r/9068 : RFC: samples: Add random driver sample.
- https://gerrit.zephyrproject.org/r/9067 : RFC: random: Introduce random device API.
- https://gerrit.zephyrproject.org/r/9056 : net: buf: Switch from k_fifo to k_lifo for free buffers
- https://gerrit.zephyrproject.org/r/9057 : net: buf: Remove the need for net_buf_pool_init()
- https://gerrit.zephyrproject.org/r/9055 : net: buf: Introduce net_buf_destroy() wrapper
- https://gerrit.zephyrproject.org/r/9059 : net: buf: Remove redundant user_data_size from buffers
- https://gerrit.zephyrproject.org/r/9066 : net: ieee802154: ACK reply needs to set all FCF attributes.
- https://gerrit.zephyrproject.org/r/9064 : net_buf: Add helper function to support 64 bit data type
- https://gerrit.zephyrproject.org/r/9063 : Bluetooth: Controller: tune the xtal and hard realtime radio start offsets
- https://gerrit.zephyrproject.org/r/9065 : 64 bit - byte order conversion
- https://gerrit.zephyrproject.org/r/9061 : tests: Add Zephyr watchdog timer test case
- https://gerrit.zephyrproject.org/r/9053 : cc3200: Use peripheral driver library functions from ROM
- https://gerrit.zephyrproject.org/r/9045 : binutils (ARC): Cleanup
- https://gerrit.zephyrproject.org/r/9048 : hosttools-tarball: remove openocd-legacy
- 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/9052 : tests: crypto: mbedtls: Adding mbedTLS test suite for ECJPAKE
- https://gerrit.zephyrproject.org/r/9051 : frdm_k64f: Fix basic button sample
- https://gerrit.zephyrproject.org/r/9049 : sanity: filter the build-all test for ethernet
- https://gerrit.zephyrproject.org/r/9041 : arm: better handling of IRQ priorities reserved by the kernel
- https://gerrit.zephyrproject.org/r/9040 : arm: add CPU_CORTEX_M_HAS_PROGRAMMABLE_FAULT_PRIOS kconfig flag
- https://gerrit.zephyrproject.org/r/9042 : arm: relinquish one IRQ priority reserved by kernel
- https://gerrit.zephyrproject.org/r/9036 : counter: cmsdk: Add Dualtimer as a Timer
- https://gerrit.zephyrproject.org/r/9039 : Bluetooth: SMP: Add support for CT2 auth bit
- https://gerrit.zephyrproject.org/r/9038 : Bluetooth: SMP: Add H7 crypto implementation and unit tests

UPDATED within last 24 hours:
- https://gerrit.zephyrproject.org/r/9024 : dhcpv4: Provide prj file for frdm_k64f
- https://gerrit.zephyrproject.org/r/9023 : k64f: Default the ETH_KSDK on if NET_L2_ETHERNET enabled.
- https://gerrit.zephyrproject.org/r/7661 : RFC: random: Add random driver for nRF5
- https://gerrit.zephyrproject.org/r/8998 : scripts: fix wrong RAM reporting on ARM
- https://gerrit.zephyrproject.org/r/8903 : net: Fix incorrect logging format specifiers
- 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/7263 : Bluetooth: HFP HF: Implement missing callback for indicators
- https://gerrit.zephyrproject.org/r/7077 : Bluetooth: HFP HF: SLC query indicators present value
- https://gerrit.zephyrproject.org/r/7030 : Bluetooth: HFP HF: SLC Connection send/parse CIND
- https://gerrit.zephyrproject.org/r/7028 : Bluetooth: AT: Improve API() to work with buffer increment
- https://gerrit.zephyrproject.org/r/9029 : drivers: timer: Optimize RTC driver and prevent past events
- https://gerrit.zephyrproject.org/r/7625 : exti/stm32: add support for F334 & F373 MCUs
- https://gerrit.zephyrproject.org/r/7626 : flash/stm32: flash driver for STM32F3x series microcontrollers
- https://gerrit.zephyrproject.org/r/9035 : net: statistics: Provide specific Kconfig options
- https://gerrit.zephyrproject.org/r/9033 : net: statistics: Move current statistics code to its own file
- https://gerrit.zephyrproject.org/r/9034 : net: statistics: Make statistics calculation fully private
- https://gerrit.zephyrproject.org/r/9032 : net: statistics: Fix comment length issue
- https://gerrit.zephyrproject.org/r/8714 : [DO NOT SUBMIT] RFC: Bluetooth: SDP client API user concept draft
- https://gerrit.zephyrproject.org/r/6291 : Bluetooth: SDP: Initial SDP client interface API
- https://gerrit.zephyrproject.org/r/6913 : power: Add ARC core suspend and resume support
- https://gerrit.zephyrproject.org/r/9025 : Bluetooth: AVDTP: Fix Coding style
- 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/8986 : kernel: enhance realtime-ness when handling timeouts
- https://gerrit.zephyrproject.org/r/9007 : arm: move IRQ_PRIORITY_OFFSET to header file, rename to _IRQ_PRIO_OFFSET
- https://gerrit.zephyrproject.org/r/8836 : drivers: enc28j60: This controller provides a full frame to l2
- https://gerrit.zephyrproject.org/r/8835 : net: l2: ethernet: Handle Ethernet II full frame relevantly
- https://gerrit.zephyrproject.org/r/8842 : drivers: ennc28j60: There is a unique L2 driver
- https://gerrit.zephyrproject.org/r/8844 : drivers: enc28j60: Expose RX thread stack size and prio config
- https://gerrit.zephyrproject.org/r/9006 : arm: add CPU_CORTEX_M_HAS_BASEPRI kconfig flag
- https://gerrit.zephyrproject.org/r/9031 : counter: cmsdk: Add DualTimer as Counter
- https://gerrit.zephyrproject.org/r/8759 : samples/drivers: Add Counters example
- https://gerrit.zephyrproject.org/r/9001 : counter: cmsdk: Add Timer 0 and 1 as Timers
- https://gerrit.zephyrproject.org/r/9002 : board: v2m_beetle: Update defconfig
- https://gerrit.zephyrproject.org/r/4457 : DONT MERGE - cause checkpatch warnings
- https://gerrit.zephyrproject.org/r/7664 : second test
- https://gerrit.zephyrproject.org/r/3114 : DONT MERGE - break doc
- https://gerrit.zephyrproject.org/r/5137 : DONT MERGE - add changes to two different branches
- https://gerrit.zephyrproject.org/r/5895 : DONT MERGE - test CI time with only 1 level
- https://gerrit.zephyrproject.org/r/5445 : DONT MERGE - break sanity
- https://gerrit.zephyrproject.org/r/4541 : DONT MERGE - break checkpatch
- https://gerrit.zephyrproject.org/r/5475 : DONT MERGE - break sanity AND checkpatch
- https://gerrit.zephyrproject.org/r/8930 : subsys: disk: Refactor disk_access stuff into a directory
- https://gerrit.zephyrproject.org/r/8811 : kernel/arch: enhance the "ready thread" cache
- 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/7496 : soc/stm32f1: Add the new type of SoC STM32F107
- https://gerrit.zephyrproject.org/r/8802 : board: add initial support for Nucleo-64 with Soc STM32F411RE

MERGED within last 24 hours:
- https://gerrit.zephyrproject.org/r/9054 : Bluetooth: Controller: ctrl pdu processing based on available CPU time
- https://gerrit.zephyrproject.org/r/9062 : Bluetooth: RFCOMM: Rename tmp with next
- https://gerrit.zephyrproject.org/r/9060 : Bluetooth: Remove unnecessary NULL check
- https://gerrit.zephyrproject.org/r/9037 : Bluetooth: SMP: Fix key_id length in smp_h6_test
- https://gerrit.zephyrproject.org/r/8979 : kernel: remove NANOKERNEL and MICROKERNEL configs
- https://gerrit.zephyrproject.org/r/9013 : Bluetooth: RFCOMM: Handle DM from peer
- https://gerrit.zephyrproject.org/r/8992 : Bluetooth: RFCOMM: Disconnect session after last dlc disconnection
- https://gerrit.zephyrproject.org/r/9014 : Bluetooth: Remove inline declaration from bt_le_conn_params_valid
- https://gerrit.zephyrproject.org/r/7217 : meta-zephyr-sdk: disable MIPS
- https://gerrit.zephyrproject.org/r/9027 : tests: Remove unnecessary CONFIG_TEST_RANDOM_GENERATOR
- https://gerrit.zephyrproject.org/r/8871 : random: Restructure RANDOM Kconfig
- https://gerrit.zephyrproject.org/r/9028 : net: Switch net dependency to CONFIG_RANDOM_GENERATOR
- https://gerrit.zephyrproject.org/r/8944 : sensor: remove unused Q16_16 value type
- https://gerrit.zephyrproject.org/r/8945 : sensor: remove SENSOR_VALUE_TYPE_INT
- https://gerrit.zephyrproject.org/r/8946 : sensor: use integers for simple value calculations
- https://gerrit.zephyrproject.org/r/8947 : sensor: update drivers to not return double values
- https://gerrit.zephyrproject.org/r/5652 : net: buf: Redesigned pool & buffer allocation API
- https://gerrit.zephyrproject.org/r/9011 : Prefix timestamps on archived console logs


Issue About Windows Environment Setup

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

Hi ,


I'm trying to build zephyr in win7. I followed the document, but got an error when building the hello sample. The console displays:


$ make
make[1]: Entering directory `/d/me/zephyr-master'
make[2]: Entering directory `/d/me/zephyr-master/samples/hello_world/outdir/qemu_x86'
HOSTCC scripts/basic/fixdep
In file included from d:/me/zephyr-master/scripts/basic/fixdep.c:126:0:
c:\mingw\include\winsock2.h:103:2: warning: #warning "fd_set and associated macros have been defined in sys/types. This may caus
e runtime problems with W32 sockets" [-Wcpp]
#warning "fd_set and associated macros have been defined in sys/types. \
^
C:\Users\Tidy\AppData\Local\Temp\ccpQ4tIt.o:fixdep.c:(.text+0xd2): undefined reference to `_ctype_'
C:\Users\Tidy\AppData\Local\Temp\ccpQ4tIt.o:fixdep.c:(.text+0xdd): undefined reference to `_impure_ptr'
C:\Users\Tidy\AppData\Local\Temp\ccpQ4tIt.o:fixdep.c:(.text+0xf6): undefined reference to `_impure_ptr'
C:\Users\Tidy\AppData\Local\Temp\ccpQ4tIt.o:fixdep.c:(.text+0x12a): undefined reference to `_impure_ptr'
C:\Users\Tidy\AppData\Local\Temp\ccpQ4tIt.o:fixdep.c:(.text+0x168): undefined reference to `__swbuf'
C:\Users\Tidy\AppData\Local\Temp\ccpQ4tIt.o:fixdep.c:(.text+0x17c): undefined reference to `__swbuf'
C:\Users\Tidy\AppData\Local\Temp\ccpQ4tIt.o:fixdep.c:(.text.startup+0xb0): undefined reference to `_impure_ptr'
C:\Users\Tidy\AppData\Local\Temp\ccpQ4tIt.o:fixdep.c:(.text.startup+0x200): undefined reference to `_impure_ptr'
C:\Users\Tidy\AppData\Local\Temp\ccpQ4tIt.o:fixdep.c:(.text.startup+0x4b4): undefined reference to `_ctype_'
C:\Users\Tidy\AppData\Local\Temp\ccpQ4tIt.o:fixdep.c:(.text.startup+0x4e1): undefined reference to `_impure_ptr'
C:\Users\Tidy\AppData\Local\Temp\ccpQ4tIt.o:fixdep.c:(.text.startup+0x509): undefined reference to `_impure_ptr'
C:\Users\Tidy\AppData\Local\Temp\ccpQ4tIt.o:fixdep.c:(.text.startup+0x54f): undefined reference to `_impure_ptr'
C:\Users\Tidy\AppData\Local\Temp\ccpQ4tIt.o:fixdep.c:(.text.startup+0x5e5): undefined reference to `_impure_ptr'
C:\Users\Tidy\AppData\Local\Temp\ccpQ4tIt.o:fixdep.c:(.text.startup+0x619): undefined reference to `_impure_ptr'
C:\Users\Tidy\AppData\Local\Temp\ccpQ4tIt.o:fixdep.c:(.text.startup+0x65a): more undefined references to `_impure_ptr' follow
collect2.exe: error: ld returned 1 exit status
make[4]: *** [scripts/basic/fixdep] Error 1
make[3]: *** [scripts_basic] Error 2
Using /d/me/zephyr-master as source for kernel
GEN ./Makefile
CHK include/generated/version.h
make[2]: *** No rule to make target `include/config/auto.conf', needed by `prepare1'. Stop.
make[2]: Leaving directory `/d/me/zephyr-master/samples/hello_world/outdir/qemu_x86'
make[1]: *** [sub-make] Error 2
make[1]: Leaving directory `/d/me/zephyr-master'
make: *** [all] Error 2


Has anybody encounterd the same ?


Thanks.
tidyjiang(a)163.com


Re: Quark Flash driver application issue

Liu, Baohong
 

The starting address will need to be a valid address in the SoC flash memory range. Also please be cautious that the flash address you will use in your test app cannot be ANY address in that range as the SoC flash is where your image (text and read-only data) is resided and running or you can overwrite and corrupt your own image itself. In other words, you will need to know where you are erasing and flashing is not being used by the image.

Thanks
Baohong

From: Mahendravarman Rajarao (RBEI/EAA3) [mailto:Mahendravarman.Rajarao(a)in.bosch.com]
Sent: Tuesday, December 13, 2016 10:26 AM
To: Liu, Baohong <baohong.liu(a)intel.com>; devel(a)lists.zephyrproject.org
Subject: RE: Quark Flash driver application issue

Yes I know that app is for spi flash , but I have already mentioned in the mail that I have modified the SPI flash application to suite the Quark Flash.

I have used device_get_binding("QUARK_FLASH"); which is getting binded.

But, subsequent erase gets failed..thats my query that should I need to do any further modifications to test soc flash ?

Best regards


From: Liu, Baohong [mailto:baohong.liu(a)intel.com]
Sent: Tuesday, December 13, 2016 11:52 PM
To: Mahendravarman Rajarao (RBEI/EAA3) <Mahendravarman.Rajarao(a)in.bosch.com<mailto:Mahendravarman.Rajarao(a)in.bosch.com>>; devel(a)lists.zephyrproject.org<mailto:devel(a)lists.zephyrproject.org>
Subject: RE: Quark Flash driver application issue

The app is for spi flash, not for soc flash.

Thanks
Baohong

From: Mahendravarman Rajarao (RBEI/EAA3) [mailto:Mahendravarman.Rajarao(a)in.bosch.com]
Sent: Tuesday, December 13, 2016 10:20 AM
To: Liu, Baohong <baohong.liu(a)intel.com<mailto:baohong.liu(a)intel.com>>; devel(a)lists.zephyrproject.org<mailto:devel(a)lists.zephyrproject.org>
Subject: RE: Quark Flash driver application issue

Hi Liu

Thanks for the reply

Its given as #define FLASH_TEST_REGION_OFFSET.

Offset means I thought that starting address + offset ( eg: 0x40000000 + 0)

So, you meant to say , I need to give FLASH_TEST_REGION_OFFSET as 0x40000000 ?


Best regards
From: Liu, Baohong [mailto:baohong.liu(a)intel.com]
Sent: Tuesday, December 13, 2016 11:26 PM
To: Liu, Baohong <baohong.liu(a)intel.com<mailto:baohong.liu(a)intel.com>>; Mahendravarman Rajarao (RBEI/EAA3) <Mahendravarman.Rajarao(a)in.bosch.com<mailto:Mahendravarman.Rajarao(a)in.bosch.com>>; devel(a)lists.zephyrproject.org<mailto:devel(a)lists.zephyrproject.org>
Subject: RE: Quark Flash driver application issue

SoC flash is on the system address space. Here are the size and starting address on quark SE SoC.

System Flash 192KB 0x40000000
System ROM 8KB 0xFFFFE000

Thanks
Baohong

From: Liu, Baohong [mailto:baohong.liu(a)intel.com]
Sent: Tuesday, December 13, 2016 9:30 AM
To: Mahendravarman Rajarao (RBEI/EAA3) <Mahendravarman.Rajarao(a)in.bosch.com<mailto:Mahendravarman.Rajarao(a)in.bosch.com>>; devel(a)lists.zephyrproject.org<mailto:devel(a)lists.zephyrproject.org>
Subject: [devel] Re: Quark Flash driver application issue

Starting address is not zero. Please use the same address x86 cpu uses when it accesses the soc flash.

Regards
Baohong

From: Mahendravarman Rajarao (RBEI/EAA3) [mailto:Mahendravarman.Rajarao(a)in.bosch.com]
Sent: Tuesday, December 13, 2016 6:09 AM
To: devel(a)lists.zephyrproject.org<mailto:devel(a)lists.zephyrproject.org>
Subject: [devel] Quark Flash driver application issue

Hi

I have referred samples/drivers/spi_flash and modified main.c to support the quark c1000 flash.
Driver binding is successful , but its giving erase failure.
I have attached the code and prj.conf files

Help me out am I missing something in the code or any extra settings I need to give in prj.conf


Best regards
Mahendra


Re: Using/misusing k_sem_init()

Luiz Augusto von Dentz
 

Hi,

On Tue, Dec 13, 2016 at 9:14 PM, Benjamin Walsh
<benjamin.walsh(a)windriver.com> wrote:
On Tue, Dec 13, 2016 at 09:59:31AM +0000, Daniel Thompson wrote:
On 12/12/16 18:10, Benjamin Walsh wrote:
Let's focus on the transmit path. Assuming we have two transmission
buffers and each buffer can store one full Ethernet frame the Ethernet
driver can send up to two frames to the MAC module but to send a third
frame it has to wait until a free buffer becomes available. This is a
perfect case for using counting semaphores.

<snip>

However, now we can have a situation where the driver (transmit thread)
has sent two frames, stopped on k_sem_take() call when trying to send a
third one and at that moment an unrecoverable transmission error
happens. At this point I would like to reinitialize the descriptor list
and also reinitialize the semaphores,
To reinitialize things here implies that the owner of the buffer has
lost so much state that it can no longer release it as normal. Why
does an unrecoverable error cause such a catastrophic loss of state?


Would that be OK, is there a better solution?
One thing you could do would be to abort the thread, then re-init the
semaphore, then respawn the thread.

We could maybe add a k_sem_flush() API, that unpend all threads waiting
on the semaphore, but returning them an errno.
To avoid race conditions its likely a flush would have to be sticky,
causing everything to return an error until the next init.
Yeah, I guess, and there has to be some protocol between the thread that
does the flush which then has to wait for the threads that take the
semaphore which then all have to reply to it before it can do the
re-init.

Basically in a situation where you resource tracking is borked to
the point that you no longer know how to resolve the situation with
the "give" API then its likely you can't know, when calling
k_sem_flush(), that all the threads are nicely blocked waiting for
the flush.

On that basis, perhaps any proposed API should be more explicit,
k_sem_set_error().

I admit a degree of skepticism here. The code to handle the new
semaphore error paths may end up more complex than the code to
correctly track buffer ownership within the IP stack error paths.
Btw, this design looks completely different than what the IP stack
expect, the so called NET_BUF_POOL uses k_fifo so it doesn't really
use k_sem API, furthermore there doesn't seem to be any mention to
net_buf which probably means that there is another type of buffer
being used so the driver will end up having to copying data.



--
Luiz Augusto von Dentz


Re: Using/misusing k_sem_init()

Benjamin Walsh <benjamin.walsh@...>
 

On Tue, Dec 13, 2016 at 09:59:31AM +0000, Daniel Thompson wrote:
On 12/12/16 18:10, Benjamin Walsh wrote:
Let's focus on the transmit path. Assuming we have two transmission
buffers and each buffer can store one full Ethernet frame the Ethernet
driver can send up to two frames to the MAC module but to send a third
frame it has to wait until a free buffer becomes available. This is a
perfect case for using counting semaphores.

<snip>

However, now we can have a situation where the driver (transmit thread)
has sent two frames, stopped on k_sem_take() call when trying to send a
third one and at that moment an unrecoverable transmission error
happens. At this point I would like to reinitialize the descriptor list
and also reinitialize the semaphores,
To reinitialize things here implies that the owner of the buffer has
lost so much state that it can no longer release it as normal. Why
does an unrecoverable error cause such a catastrophic loss of state?


Would that be OK, is there a better solution?
One thing you could do would be to abort the thread, then re-init the
semaphore, then respawn the thread.

We could maybe add a k_sem_flush() API, that unpend all threads waiting
on the semaphore, but returning them an errno.
To avoid race conditions its likely a flush would have to be sticky,
causing everything to return an error until the next init.
Yeah, I guess, and there has to be some protocol between the thread that
does the flush which then has to wait for the threads that take the
semaphore which then all have to reply to it before it can do the
re-init.

Basically in a situation where you resource tracking is borked to
the point that you no longer know how to resolve the situation with
the "give" API then its likely you can't know, when calling
k_sem_flush(), that all the threads are nicely blocked waiting for
the flush.

On that basis, perhaps any proposed API should be more explicit,
k_sem_set_error().

I admit a degree of skepticism here. The code to handle the new
semaphore error paths may end up more complex than the code to
correctly track buffer ownership within the IP stack error paths.


Re: Using/misusing k_sem_init()

Benjamin Walsh <benjamin.walsh@...>
 

On Tue, Dec 13, 2016 at 03:57:38PM +0100, Piotr Mienkowski wrote:
Hi Ben,

What is the behaviour you expect exactly ? What would a semaphore
re-init signal to the thread pending on the semaphore in your
application ?
Sorry, I wrote a somehow longish description of the issue but didn't
mentioned the expected behavior.

When I clean up the descriptor list and re-initialize the semaphores I
would expect the pending thread to be awaken and continue as normal. At
that point the resources (transmission buffers) are available again so
the transmit thread can send the data (copy them to transmission buffers
and let the MAC module know there is new data).

You could give the semaphore twice (since you initialize it with '2') to
flush the threads pending on it, but that would probably just cause them
to pend again on the semaphore. Worst, the thread would probably just
think it got the semaphore and just try to do the operation expected of
it when it is able to get the semaphore.
I'm not sure I understand what is meant by flushing the threads. I
I meant that would wake up the thread waiting on the semaphore, since
reinitializing it would not do that.

believe that using k_sem_give() in a loop instead of k_sem_init() would
do exactly the job I need, the transmit thread would be awaken and
continue as normal. It's only that this solution seemed not very elegant
especially in cases where the initial semaphore count is high.

That said, I redesigned my Ethernet driver code not to copy the data.
The network buffers passed to the driver by the higher layer are
released directly by the IRQ handler with net_buf_unref() after the data
are sent by the MAC module. At the moment my code is not using any
semaphores and for me the issue is resolved.
OK, cool. No need to add a feature to the semaphore API that does not
have at least one real use-case. :)

Cheers,
Ben


Re: Chain booting in Zephyr

David Brown
 

On Tue, Dec 13, 2016 at 06:12:49PM +0000, Chuck Jordan wrote:

[chuckj] Yes indeed. A CPU exception might occur as well.

Also, in terms of “common” failures that can occur. If the vector
table is at address 0 and in RAM, a common software bug is to have a
NULL pointer to do a store access relative to  address 0, corrupting
the vector table. People have addressed this with memory protection
unit, MMU, or by moving the vector table to a non-zero location, OR by
having the vector table in a read-executed memory (with no write
access).
This is one of the reasons I'd like to at least be able to keep the
vector table in ROM.

On the devices I'm using, address 0 is ROM, so this is less of a
concern, but it is still possible to have rogue writes corrupt the
vector table. Until we have an MPU, it will be difficult to protect
this.

David


Re: Quark Flash driver application issue

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

Yes I know that app is for spi flash , but I have already mentioned in the mail that I have modified the SPI flash application to suite the Quark Flash.

I have used device_get_binding("QUARK_FLASH"); which is getting binded.

But, subsequent erase gets failed..thats my query that should I need to do any further modifications to test soc flash ?

Best regards



From: Liu, Baohong [mailto:baohong.liu(a)intel.com]
Sent: Tuesday, December 13, 2016 11:52 PM
To: Mahendravarman Rajarao (RBEI/EAA3) <Mahendravarman.Rajarao(a)in.bosch.com>; devel(a)lists.zephyrproject.org
Subject: RE: Quark Flash driver application issue

The app is for spi flash, not for soc flash.

Thanks
Baohong

From: Mahendravarman Rajarao (RBEI/EAA3) [mailto:Mahendravarman.Rajarao(a)in.bosch.com]
Sent: Tuesday, December 13, 2016 10:20 AM
To: Liu, Baohong <baohong.liu(a)intel.com<mailto:baohong.liu(a)intel.com>>; devel(a)lists.zephyrproject.org<mailto:devel(a)lists.zephyrproject.org>
Subject: RE: Quark Flash driver application issue

Hi Liu

Thanks for the reply

Its given as #define FLASH_TEST_REGION_OFFSET.

Offset means I thought that starting address + offset ( eg: 0x40000000 + 0)

So, you meant to say , I need to give FLASH_TEST_REGION_OFFSET as 0x40000000 ?


Best regards

From: Liu, Baohong [mailto:baohong.liu(a)intel.com]
Sent: Tuesday, December 13, 2016 11:26 PM
To: Liu, Baohong <baohong.liu(a)intel.com<mailto:baohong.liu(a)intel.com>>; Mahendravarman Rajarao (RBEI/EAA3) <Mahendravarman.Rajarao(a)in.bosch.com<mailto:Mahendravarman.Rajarao(a)in.bosch.com>>; devel(a)lists.zephyrproject.org<mailto:devel(a)lists.zephyrproject.org>
Subject: RE: Quark Flash driver application issue

SoC flash is on the system address space. Here are the size and starting address on quark SE SoC.

System Flash 192KB 0x40000000
System ROM 8KB 0xFFFFE000

Thanks
Baohong

From: Liu, Baohong [mailto:baohong.liu(a)intel.com]
Sent: Tuesday, December 13, 2016 9:30 AM
To: Mahendravarman Rajarao (RBEI/EAA3) <Mahendravarman.Rajarao(a)in.bosch.com<mailto:Mahendravarman.Rajarao(a)in.bosch.com>>; devel(a)lists.zephyrproject.org<mailto:devel(a)lists.zephyrproject.org>
Subject: [devel] Re: Quark Flash driver application issue

Starting address is not zero. Please use the same address x86 cpu uses when it accesses the soc flash.

Regards
Baohong

From: Mahendravarman Rajarao (RBEI/EAA3) [mailto:Mahendravarman.Rajarao(a)in.bosch.com]
Sent: Tuesday, December 13, 2016 6:09 AM
To: devel(a)lists.zephyrproject.org<mailto:devel(a)lists.zephyrproject.org>
Subject: [devel] Quark Flash driver application issue

Hi

I have referred samples/drivers/spi_flash and modified main.c to support the quark c1000 flash.
Driver binding is successful , but its giving erase failure.
I have attached the code and prj.conf files

Help me out am I missing something in the code or any extra settings I need to give in prj.conf


Best regards
Mahendra


Re: Quark Flash driver application issue

Liu, Baohong
 

The app is for spi flash, not for soc flash.

Thanks
Baohong

From: Mahendravarman Rajarao (RBEI/EAA3) [mailto:Mahendravarman.Rajarao(a)in.bosch.com]
Sent: Tuesday, December 13, 2016 10:20 AM
To: Liu, Baohong <baohong.liu(a)intel.com>; devel(a)lists.zephyrproject.org
Subject: RE: Quark Flash driver application issue

Hi Liu

Thanks for the reply

Its given as #define FLASH_TEST_REGION_OFFSET.

Offset means I thought that starting address + offset ( eg: 0x40000000 + 0)

So, you meant to say , I need to give FLASH_TEST_REGION_OFFSET as 0x40000000 ?


Best regards


From: Liu, Baohong [mailto:baohong.liu(a)intel.com]
Sent: Tuesday, December 13, 2016 11:26 PM
To: Liu, Baohong <baohong.liu(a)intel.com<mailto:baohong.liu(a)intel.com>>; Mahendravarman Rajarao (RBEI/EAA3) <Mahendravarman.Rajarao(a)in.bosch.com<mailto:Mahendravarman.Rajarao(a)in.bosch.com>>; devel(a)lists.zephyrproject.org<mailto:devel(a)lists.zephyrproject.org>
Subject: RE: Quark Flash driver application issue

SoC flash is on the system address space. Here are the size and starting address on quark SE SoC.

System Flash 192KB 0x40000000
System ROM 8KB 0xFFFFE000

Thanks
Baohong

From: Liu, Baohong [mailto:baohong.liu(a)intel.com]
Sent: Tuesday, December 13, 2016 9:30 AM
To: Mahendravarman Rajarao (RBEI/EAA3) <Mahendravarman.Rajarao(a)in.bosch.com<mailto:Mahendravarman.Rajarao(a)in.bosch.com>>; devel(a)lists.zephyrproject.org<mailto:devel(a)lists.zephyrproject.org>
Subject: [devel] Re: Quark Flash driver application issue

Starting address is not zero. Please use the same address x86 cpu uses when it accesses the soc flash.

Regards
Baohong

From: Mahendravarman Rajarao (RBEI/EAA3) [mailto:Mahendravarman.Rajarao(a)in.bosch.com]
Sent: Tuesday, December 13, 2016 6:09 AM
To: devel(a)lists.zephyrproject.org<mailto:devel(a)lists.zephyrproject.org>
Subject: [devel] Quark Flash driver application issue

Hi

I have referred samples/drivers/spi_flash and modified main.c to support the quark c1000 flash.
Driver binding is successful , but its giving erase failure.
I have attached the code and prj.conf files

Help me out am I missing something in the code or any extra settings I need to give in prj.conf


Best regards
Mahendra

5861 - 5880 of 7903