Date   

Re: Trouble configuring arduino101 via zephyr

Anjali Asar <anjaliasar@...>
 

Some pins have been pulled up and some have been pulled down. Not able to change it. It seems to be perpetually stuck in that mode. Also pin 8 (Zephyr pin 16) not functioning. Any suggestions?

On 01-Feb-2017 5:19 PM, "Anjali Asar" <anjaliasar@...> wrote:
Hi, not sure if this is the right forum for this, but trying my luck. if not, please do direct me towards the right one.

I'm having trouble flashing the arduino101.
i've followed all the instructions available still, tho it says download complete, the code doesnt seem to have been downloaded.

The code i am trying is the sample code provided, "blinky". The LED doesn't light up. i have tried various pins apart from the on board LED too.

 Is there any extra configuration that i have to do to make it work?
Note: i am using a windows 8 pc


did the zephyr kernel support the nested interrupt on all the supported arch?

曹子龙
 

hi all:

     i have reviewed the cortex-m arch about the interrupt flow, and found that cortex-m support max 255 interrupt entry and  it allows  interrupt with higher prio  preempted  another one with lower priority interrupt, 

i did not see other arch`s code but just want to know about, is this the feature of zephyr kernel? for the strong real-time feature? or  arch related?  

thanks for your  kindly support. 



 


Re: Problems managing NBUF DATA pool in the networking stack

Piotr Mienkowski
 

Hi,

While I agree we should prevent the remote to consume all the buffer
and possible starve the TX, this is probably due to echo_server design
that deep copies the buffers from RX to TX, in a normal application
Indeed the echo server could perhaps be optimized not to deep copy
thus removing the issue.  The wider question here is whether or not we
want a design rule that effectively states that all applications
should consume and unref their rx buffers before attempting to
allocate tx buffers.   This may be convenient for some applications,
but I'm not convinced that is always the case.  Such a design rule
effectively states that an application that needs to retain or process
information from request to response must now have somewhere to store
all of that information between buffers and rules out any form of
incremental processing of an rx buffer interleaved with the
construction of the tx message.
If you read the entire email it would be clearer that I did not
suggest it was fine to rule out incremental processing, in fact I
suggested to add pools per net_context that way the stack itself will
not have to drop its own packets and stop working because some context
is taking all its buffers just to create clones.
So, what should be the final solution to the NBUF DATA issue? Do we want to redesign echo_server sample application to use shallow copy, should we introduce NBUF DATA pool per context, a separate NBUF DATA pool for TX and RX? Something else?

In my opinion enforcing too much granularity on allocation of data buffers, i.e. having a separate nbuf data pool per context, maybe another one for networking stack will not be optimal. Firstly, Kconfig would become even more complex and users would have hard time figuring out a safe set of options. What if we know one context will not use many data buffers and another one a lot. Should we still assign the same amount of data buffers per context? Secondly, every separate data pool will add some spare buffers as a 'margin error'. Thirdly, Ethernet driver which reserves data buffers for the RX path has no notion of context, doesn't know which packets are meant for the networking stack, which one for the application. It would not know from which data pool to take the buffers. It can only distinguish between RX and TX path.

In principle, having shared resources is not a bad design approach. However, we probably should have a way to guarantee a minimum amount of buffers for the TX path. As a software engineer, if I need to design a TX path in my networking application and I know that I have some fixed amount of data buffers available I should be able to manage it. The same task becomes much more difficult if my fixed amount of data buffers can at any given moment become zero for reasons which are beyond my control. This is the case currently.

Regards,
Piotr


Re: Adding support for CC2650 SoC

Gil Pitney
 

Hi Geoffrey,

Good question.

I understand "SimpleLink" to describe a family of connectivity SoC's.

But an SoC can include a heterogeneous mix of CPU core types: ARM
cores (of different types), DSP cores, custom processors.

We may be able to designate only one of the SoC cores as the
"master", and distinguish the Zephyr SoC family based on that master
core; but, master core can depend on the application.

I would argue, since the SoCs all still fall within the SimpleLink
"family", that the cc26xx/ subdirectory can go under the
arch/arm/soc/ti_simplelink/ directory. It seems the cc26xx Kconfig
and its new Device Tree files will still be separate from the cc32xx,
so that the fact their SoCs include different CPU cores should not
cause a conflict.

BR,
- Gil





On 13 February 2017 at 03:12, Geoffrey LE GOURRIEREC
<geoffrey.legourrierec@smile.fr> wrote:
Hello Gil,

I am starting to work on supporting Zephyr on Texas Instruments' "SensorTag"
device.

To this end, I need to add support for the CC2650 MCU. I looked at the
support you
added for the CC32xx family of MCUs, and am having trouble deciding on
wether to
integrate my work or not in the arch/arm/soc/ti_simplelink subdirectory.

This is my first time contributing to Zephyr, and I gather SoCs are
primarily
differentiated regarding the CPU type they use. However, the "SimpleLink"
family
is more of a commercial name, and CC26xx / cc32xx devices, in particular,
differ
in this respect (Cortex M-3 / M-4 respectively). Other families of MCUs
already
supported (e.g. Atmel's SAME70) at least share the CPU type.

Should I use your existing work as common ground?
Or should we reckon "SimpleLink family" is not really usable as a SoC
"family"?

Thanks for your advice,

Best regards,

--
Geoffrey Le Gourriérec


Re: FRDM eth driver and TCP apps

Marcus Shawcroft <marcus.shawcroft@...>
 

On 13 February 2017 at 17:13, Santes, Flavio <flavio.santes@intel.com> wrote:
Hello,

This patch https://gerrit.zephyrproject.org/r/#/c/11176/ is breaking some network applications (i.e. samples/net/mqtt_publisher). A local revert solves the issue for me.
Can you raise a JIRA issue and add some details of the failure you are seeing ?

Thanks
/Marcus


FRDM eth driver and TCP apps

Santes, Flavio <flavio.santes@...>
 

Hello,

This patch https://gerrit.zephyrproject.org/r/#/c/11176/ is breaking some network applications (i.e. samples/net/mqtt_publisher). A local revert solves the issue for me.

Regards,
Flavio


Daily Gerrit Digest

donotreply@...
 

NEW within last 24 hours:
- https://gerrit.zephyrproject.org/r/11183 : sensor: fix typo in sensor.h
- https://gerrit.zephyrproject.org/r/11166 : ext/lib/mbedtls: Add the TLS configuration file
- https://gerrit.zephyrproject.org/r/11182 : toolchain.gccarmemb: set DTC for building targets that use devicetrees
- https://gerrit.zephyrproject.org/r/11185 : tests: kernel: add test point k_delayed_work_remaining_get
- https://gerrit.zephyrproject.org/r/11184 : sensor: add sensor_channel_count function
- https://gerrit.zephyrproject.org/r/11177 : tests: kernel: added test case k_fifo_is_empty
- https://gerrit.zephyrproject.org/r/11174 : tests: kernel: added test case k_is_preempt_thread
- https://gerrit.zephyrproject.org/r/11172 : defconfig: Enable Watchdog for ATMEL SAM SoCs
- https://gerrit.zephyrproject.org/r/11173 : tests: kernel: remove unsupported tests
- https://gerrit.zephyrproject.org/r/11167 : riscv32: move riscv privileged architecture specifics within a common header file

UPDATED within last 24 hours:
- https://gerrit.zephyrproject.org/r/11160 : hosttools-tarball.bb: Integrate YAML library into SDK
- https://gerrit.zephyrproject.org/r/10807 : net/mqtt: Add BT support to MQTT publisher sample
- https://gerrit.zephyrproject.org/r/10804 : net/mqtt: Add support for IBM BlueMix Watson topic format
- https://gerrit.zephyrproject.org/r/5504 : dma: Introduce STM32F4x DMA driver
- https://gerrit.zephyrproject.org/r/10814 : Added sensor driver for SI1153. Added proximity sensor_channel entries in sensor.h
- https://gerrit.zephyrproject.org/r/11029 : watchdog: Add wdt driver for Atmel SAM SoCs
- https://gerrit.zephyrproject.org/r/10991 : eth/mcux: Add temporary workaround to unbreak IPv6 ND features.
- https://gerrit.zephyrproject.org/r/10812 : Added sensor driver for ADXL362
- https://gerrit.zephyrproject.org/r/10902 : eth/mcux: Add basic PHY support.
- https://gerrit.zephyrproject.org/r/11088 : doc: boards: Move nRF5x DK board doc from the wiki to git
- https://gerrit.zephyrproject.org/r/6384 : stm32lx: spi add SPI driver for STM32Lx family
- https://gerrit.zephyrproject.org/r/10369 : ataes132a: Adds a driver to support ATAES132A device
- https://gerrit.zephyrproject.org/r/10645 : Bluetooth: HFP HF: Handling AG Network error
- https://gerrit.zephyrproject.org/r/11101 : samples/net/http: Add HTTP over TLS sample application

MERGED within last 24 hours:
- https://gerrit.zephyrproject.org/r/11176 : eth/mcux: Add basic PHY support.
- https://gerrit.zephyrproject.org/r/11164 : net/http: Add QEMU support to the HTTP server sample app
- https://gerrit.zephyrproject.org/r/11165 : net/http: Improve network configuration routines
- https://gerrit.zephyrproject.org/r/11175 : net/mqtt: Fix inline doc for MQTT
- https://gerrit.zephyrproject.org/r/11170 : net/dns: Update QEMU prj file
- https://gerrit.zephyrproject.org/r/11171 : net: remove obsolete CONFIG_NET_YAIP
- https://gerrit.zephyrproject.org/r/11051 : net/dhcpv4: Fix event/state mismatch
- https://gerrit.zephyrproject.org/r/11052 : net/dhcpv4: Remove unused dhcpv4 offer state
- https://gerrit.zephyrproject.org/r/11093 : net/dhcpv4: Ensure udp header checksum is computed correctly
- https://gerrit.zephyrproject.org/r/11103 : samples: net: Add .conf file for qemu_cortex_m3 in echo_*
- https://gerrit.zephyrproject.org/r/11079 : samples/zoap-server: Update docs with information about libcoap
- https://gerrit.zephyrproject.org/r/11078 : iot/zoap: Improve zoap.h documentation
- https://gerrit.zephyrproject.org/r/11080 : iot/zoap: Fix handling of 16-bytes block-wise transfers
- https://gerrit.zephyrproject.org/r/11081 : iot/zoap: Fix header indentation
- https://gerrit.zephyrproject.org/r/11082 : iot/zoap: Add missing const modifier to header file


Re: did the scheduler need report the misuse of k_sched_lock before k_sleep?

Benjamin Walsh <benjamin.walsh@...>
 

Hi,

i review the code of zephyr of riscv arch, with the aim that to
porting this to the mips arch because the reiscv is the most like
the mips,


when i read the function" __irq_wrapper" , and want to know whether
the it should cope with the situation like this:
...............
k_sched_lock();


k_sleep(1);


k_sched_unlock();
....................

and it obviously wrong because of the paradox, but i found the
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

I'm not sure what this means... This code is valid. The scheduler lock
is per-thread. If the thread goes to sleep, it relinquishes the CPU, but
when it comes back from sleeping, the scheduler will be locked again. Of
course, anything could have happened during the time that it slept, so
the code has to account for that.

The same holds for irq_lock() too. This code is also valid:

int key = irq_lock();
k_sleep(1);
irq_unlock(key);

The kernel records the value of 'key' when it pends the thread and
restores the value of 'key' for the incoming thread.

The k_thread.base.sched_lock count is only used when exiting an
interrupt, to see if a reschedule operation has to be attempted or not.
The k_sleep() operation does not take it into account: the thread chose
to sleep, it will sleep, even if its sched_lock count is non-zero. It
removes the thread from the ready queue, puts it on the timeout_q, and
then calls _Swap(), to choose another thread to run. _Swap() does not
look at the sched_lock count, nor the irq_lock key for that matter: it
does not decide _if_ a reschedule must happen, but only swaps the
current thread with the thread in the ready q cache.

Now, I am not familiar with the riscv port: if its implementation of
_Swap() does not follow this rule, that's a bug.

Regards,
Ben

"__irq_wrapper" would realy do the actual switch action with this,
because the flow direct go to the schedule label when it found the
scheduler is involked because of "ecall" in _Swap, with out judge the
preempted object, so i want to know if it should be this?
--
Benjamin Walsh, SMTS
WR VxWorks Virtualization Profile
www.windriver.com
Zephyr kernel maintainer
www.zephyrproject.org


Adding support for CC2650 SoC

Geoffrey LE GOURRIEREC <geoffrey.legourrierec@...>
 

Hello Gil,

I am starting to work on supporting Zephyr on Texas Instruments' "SensorTag" device.

To this end, I need to add support for the CC2650 MCU. I looked at the support you
added for the CC32xx family of MCUs, and am having trouble deciding on wether to
integrate my work or not in the arch/arm/soc/ti_simplelink subdirectory.

This is my first time contributing to Zephyr, and I gather SoCs are primarily
differentiated regarding the CPU type they use. However, the "SimpleLink" family
is more of a commercial name, and CC26xx / cc32xx devices, in particular, differ
in this respect (Cortex M-3 / M-4 respectively). Other families of MCUs already
supported (e.g. Atmel's SAME70) at least share the CPU type.

Should I use your existing work as common ground?
Or should we reckon "SimpleLink family" is not really usable as a SoC "family"?

Thanks for your advice,

Best regards,

--
Geoffrey Le Gourriérec

 


did the scheduler need report the misuse of k_sched_lock before k_sleep?

曹子龙
 

hi all:

  i review the code of zephyr of riscv arch, with the aim that to porting this to the mips arch because the reiscv is the most like the mips,  

when i read the function" __irq_wrapper"  , and want to know whether the it should cope with the situation like this:
     ...............
   k_sched_lock();

   k_sleep(1);

   k_sched_unlock();
   ....................


and it obviously wrong because of the paradox, but i found the "__irq_wrapper" would realy do  the actual  switch action with this,  because the flow direct go to the  schedule label when it found the scheduler is involked because of "ecall" in _Swap, with out judge the preempted object, so i want to know if it should be this?

 thanks for your help, and much appreciate for your help.





 


Daily Gerrit Digest

donotreply@...
 

NEW within last 24 hours:
- https://gerrit.zephyrproject.org/r/11163 : Revert tests: disable qemu_riscv32 on test_ecc_dh test [REVERT ME]
- https://gerrit.zephyrproject.org/r/11162 : tinycrypt: allow use of tinycrypt ecc for riscv32
- https://gerrit.zephyrproject.org/r/11161 : boards: tinyTILE: enable USB console by default
- https://gerrit.zephyrproject.org/r/11160 : hosttools-tarball.bb: Integrate YAML library into SDK

UPDATED within last 24 hours:
- https://gerrit.zephyrproject.org/r/11112 : Merge remote-tracking branch 'origin/core' into master
- https://gerrit.zephyrproject.org/r/10140 : tests/gpio: enable gpio cases to run on more platforms
- https://gerrit.zephyrproject.org/r/10862 : ARC: fix I2C SPI and GPIO default name issue for ARC
- https://gerrit.zephyrproject.org/r/10788 : xtensa: apply overlay to newlib

MERGED within last 24 hours:
- https://gerrit.zephyrproject.org/r/9947 : tests/pwm: enable PWM case to work on D2000 board
- https://gerrit.zephyrproject.org/r/10793 : tests/gpio: fix test GPIO_INT_EDGE bug
- https://gerrit.zephyrproject.org/r/9820 : tests: add zephyr adc driver api test case
- https://gerrit.zephyrproject.org/r/10784 : pinmux: fix default pinmux driver for quark_se_ss
- https://gerrit.zephyrproject.org/r/11025 : tests: add zephyr counter and timer api test
- https://gerrit.zephyrproject.org/r/10826 : xtensa: fix assembling bb[cs]i.l on big-endian targets
- https://gerrit.zephyrproject.org/r/10785 : xtensa: remove unneeded patches
- https://gerrit.zephyrproject.org/r/10787 : xtensa: add recipes-devtools-xtensa
- https://gerrit.zephyrproject.org/r/10786 : xtensa: fix endianness


Daily Gerrit Digest

donotreply@...
 

NEW within last 24 hours:
- https://gerrit.zephyrproject.org/r/11101 : samples/net/http: Add HTTP over TLS sample application
- https://gerrit.zephyrproject.org/r/11114 : arc: add _tsc_read
- https://gerrit.zephyrproject.org/r/11109 : arm: cortex-m: allow configurable ROM offset
- https://gerrit.zephyrproject.org/r/11112 : Merge remote-tracking branch 'origin/core' into master
- https://gerrit.zephyrproject.org/r/11103 : samples: fix for qemu_cortex_m3 build error in net/samples/echo_*
- https://gerrit.zephyrproject.org/r/11093 : net/dhcpv4: Ensure udp header checksum is computed correctly
- https://gerrit.zephyrproject.org/r/11092 : net/dhcpv4: Refactor msg type representation.

UPDATED within last 24 hours:
- https://gerrit.zephyrproject.org/r/10783 : samples: bmi160: use new device name
- https://gerrit.zephyrproject.org/r/10376 : WIP stack sentinel x86
- https://gerrit.zephyrproject.org/r/11018 : net/mqtt: Fix inline doc for MQTT
- https://gerrit.zephyrproject.org/r/3313 : samples/drivers/crypto: crypto sample app
- https://gerrit.zephyrproject.org/r/3312 : drivers/crypto: TinyCrypt shim driver
- https://gerrit.zephyrproject.org/r/10369 : ataes132a: Adds a driver to support ATAES132A device
- https://gerrit.zephyrproject.org/r/3311 : include/crypto: Crypto abstraction header
- https://gerrit.zephyrproject.org/r/11088 : doc: boards: Move nRF5x DK board doc from the wiki to git
- https://gerrit.zephyrproject.org/r/11079 : samples/zoap-server: Update docs with information about libcoap
- https://gerrit.zephyrproject.org/r/11080 : iot/zoap: Fix handling of 16-bytes block-wise transfers
- https://gerrit.zephyrproject.org/r/11082 : iot/zoap: Add missing const modifier to header file
- https://gerrit.zephyrproject.org/r/11081 : iot/zoap: Fix header indentation
- https://gerrit.zephyrproject.org/r/11024 : qemu_cortex_m3: fixed network connectivity
- https://gerrit.zephyrproject.org/r/11078 : iot/zoap: Improve zoap.h documentation
- https://gerrit.zephyrproject.org/r/11077 : riscv32: pulpino does not support XIP
- https://gerrit.zephyrproject.org/r/10685 : drivers: mcr20a: cleanup and refactor interrupt processing
- https://gerrit.zephyrproject.org/r/10814 : Added sensor driver for SI1153. Added proximity sensor_channel entries in sensor.h
- https://gerrit.zephyrproject.org/r/11052 : net/dhcpv4: Remove unused dhcpv4 offer state
- https://gerrit.zephyrproject.org/r/11051 : net/dhcpv4: Fix event/state mismatch
- https://gerrit.zephyrproject.org/r/10991 : eth/mcux: Add temporary workaround to unbreak IPv6 ND features.

MERGED within last 24 hours:
- https://gerrit.zephyrproject.org/r/11159 : tests: pipe: remove unsupported tests
- https://gerrit.zephyrproject.org/r/11158 : tests: memory pool: remove unsupported tests
- https://gerrit.zephyrproject.org/r/11150 : dts: hexiwear: fix fixup to use correct define
- https://gerrit.zephyrproject.org/r/11151 : arm: sam70: refactor clearing of exception faults to common code
- https://gerrit.zephyrproject.org/r/11152 : newlib: make sure the chain of includes has generated_dts_board.h
- https://gerrit.zephyrproject.org/r/11153 : tests: net: whitelist boards for telnet server
- https://gerrit.zephyrproject.org/r/11154 : tests: benchmarks: add new boards
- https://gerrit.zephyrproject.org/r/11155 : mvic: include stdint for uint32_t
- https://gerrit.zephyrproject.org/r/11156 : tests: xip: pulpino does not support XIP
- https://gerrit.zephyrproject.org/r/11157 : tests: disable qemu_riscv32 on test_ecc_dh test [REVERT ME]
- https://gerrit.zephyrproject.org/r/11110 : Merge arm branch into master
- https://gerrit.zephyrproject.org/r/11091 : add curie_ble board for all curie based boards
- https://gerrit.zephyrproject.org/r/11090 : boards: add tinytile board
- https://gerrit.zephyrproject.org/r/11115 : samples: bmi160: use correct device name
- https://gerrit.zephyrproject.org/r/11106 : misc: fix more variable type mismatches
- https://gerrit.zephyrproject.org/r/11111 : libc-hooks: Fix include file for arch ARM
- https://gerrit.zephyrproject.org/r/11104 : xtensa: fix numerous checkpatch issues
- https://gerrit.zephyrproject.org/r/11113 : xtensa: more checkpatch fixes
- https://gerrit.zephyrproject.org/r/11105 : arm: include: Add DTS generated file to arch.h
- https://gerrit.zephyrproject.org/r/11102 : sanitycheck: only disable tryrun when using SDK
- https://gerrit.zephyrproject.org/r/11098 : Xtensa port: Removed trailing spaces and unused macros. Reformatted comments.
- https://gerrit.zephyrproject.org/r/11100 : Bluetooth: GATT: Fix compilation error
- https://gerrit.zephyrproject.org/r/11096 : sanitycheck: fix defconfig regex
- https://gerrit.zephyrproject.org/r/11095 : Xtensa port: Fixed Xtensa timer in case of tickles idle.
- https://gerrit.zephyrproject.org/r/11094 : Merge bluetooth branch into master
- https://gerrit.zephyrproject.org/r/9883 : i2c: Adds a functions set that supports flexible addressing.
- https://gerrit.zephyrproject.org/r/10718 : tests: dma: update dma loop transfer app
- https://gerrit.zephyrproject.org/r/10836 : kernel: Add OpenOCD support
- https://gerrit.zephyrproject.org/r/11027 : gen_isr_tables: New static interrupt build mechanism
- https://gerrit.zephyrproject.org/r/11028 : arm: use gen_isr_tables mechanism for interrupts
- https://gerrit.zephyrproject.org/r/11062 : arm: enable direct interrupts feature
- https://gerrit.zephyrproject.org/r/11071 : tests: add test for gen_isr_table
- https://gerrit.zephyrproject.org/r/11072 : nios2: use gen_isr_tables mechanism
- https://gerrit.zephyrproject.org/r/11070 : grove: fix variable type mismatch
- https://gerrit.zephyrproject.org/r/11003 : quark_se: Save/restore debug registers.
- https://gerrit.zephyrproject.org/r/11017 : grove: fix variable type mismatch
- https://gerrit.zephyrproject.org/r/10889 : make_zephyr_sdk.sh: Bump version to 0.9.1
- https://gerrit.zephyrproject.org/r/10591 : arm: cmsis: Convert _ScbIsNestedExc to use direct CMSIS register access
- https://gerrit.zephyrproject.org/r/10592 : arm: cmsis: Convert FaultEnable to use direct CMSIS register access
- https://gerrit.zephyrproject.org/r/10593 : arm: cmsis: Convert _ScbActiveVectorGet to use direct CMSIS register access
- https://gerrit.zephyrproject.org/r/10594 : arm: cmsis: Convert _ScbHardFaultIsForced to use direct CMSIS register access
- https://gerrit.zephyrproject.org/r/10595 : arm: cmsis: Convert _ScbDivByZeroFaultEnable to use direct CMSIS register access
- https://gerrit.zephyrproject.org/r/10597 : arm: cmsis: Convert _Scb*FaultAddrGet to use direct CMSIS register access
- https://gerrit.zephyrproject.org/r/10600 : arm: cmsis: Convert _Scb*Fault*Reset to use direct CMSIS register access
- https://gerrit.zephyrproject.org/r/10601 : arm: cmsis: Remove last bits of scs/scb as we've converted to CMSIS
- https://gerrit.zephyrproject.org/r/10605 : arm: cmsis: cleanup use of _SCS_CPACR_CP1{0,1}_Pos define
- https://gerrit.zephyrproject.org/r/10596 : arm: cmsis: Convert _Scb*FaultIs* & _ScbIs*Fault to use CMSIS register access
- https://gerrit.zephyrproject.org/r/10598 : arm: cmsis: Convert printing of MMFSR, BFSR, and UFSR to CMSIS
- https://gerrit.zephyrproject.org/r/10599 : arm: cmsis: Convert _ClearFaults to use direct CMSIS register access
- https://gerrit.zephyrproject.org/r/10670 : xtensa port: Added arch .ini file to support xt-sim
- https://gerrit.zephyrproject.org/r/10690 : tests: Introduced new config option to add extra stack size for tests.
- https://gerrit.zephyrproject.org/r/10855 : cc3200: Enable device tree usage for CC3200
- https://gerrit.zephyrproject.org/r/10857 : nucleo_l476rg: Enable device tree usage for Nucleo
- https://gerrit.zephyrproject.org/r/10860 : v2m_beetle: uart: Add DTS support to UART driver
- https://gerrit.zephyrproject.org/r/10628 : dts: arm: Kinetis: Add FRDM_K64F support
- https://gerrit.zephyrproject.org/r/10856 : dts: arm: Add base DTS support for STM32 Nucleo board
- https://gerrit.zephyrproject.org/r/10859 : arm: dts: Add base DTS support for v2m_beetle
- https://gerrit.zephyrproject.org/r/10629 : dts: arm: Kinetis: Add support for Hexiwear K64
- https://gerrit.zephyrproject.org/r/10626 : dts: arm: Add base DTS and YAML definitions
- https://gerrit.zephyrproject.org/r/10627 : dts: arm: Kinetis: Add base support for Kinetis
- https://gerrit.zephyrproject.org/r/7738 : dts: Add support for Device Tree
- https://gerrit.zephyrproject.org/r/10858 : stm32: uart: Add DTS support to STM32 UART driver
- https://gerrit.zephyrproject.org/r/10854 : dts: arm: Add base DTS support for TI CC3200
- https://gerrit.zephyrproject.org/r/10920 : kw41z: add base DTS support
- https://gerrit.zephyrproject.org/r/11076 : REVERTME: tests: stackprot: disable on xtensa
- https://gerrit.zephyrproject.org/r/11026 : interrupts: use fixed section name for vector table
- https://gerrit.zephyrproject.org/r/11075 : REVERTME: cpp_synchronization: disable on Xtensa
- https://gerrit.zephyrproject.org/r/10944 : drivers: Remove unnecessary CONFIG_SYS_POWER_DEEP_SLEEP
- https://gerrit.zephyrproject.org/r/10997 : kernel: Use SYS_DLIST_FOR_EACH_CONTAINER
- https://gerrit.zephyrproject.org/r/10926 : slist: Introduce CONTAINER macros
- https://gerrit.zephyrproject.org/r/10927 : tests/slist: Exercise CONTAINER macros
- https://gerrit.zephyrproject.org/r/10992 : dlist: Introduce CONTAINER macros
- https://gerrit.zephyrproject.org/r/10993 : tests/common: Add tests for sys_dlist_*
- https://gerrit.zephyrproject.org/r/10998 : net: Convert FOR_EACH macro instances to use CONTAINER
- https://gerrit.zephyrproject.org/r/10999 : Bluetooth: Convert FOR_EACH macro instances to use CONTAINER
- https://gerrit.zephyrproject.org/r/11000 : drivers: Convert FOR_EACH macro instances to use CONTAINER
- https://gerrit.zephyrproject.org/r/11089 : boards: panther: Use 115200 baudrate for BLE UART
- https://gerrit.zephyrproject.org/r/11085 : arduino_101: bmi160: use new device name
- https://gerrit.zephyrproject.org/r/11087 : Merge net branch into master


Re: Inconsistent and ever-changing device naming in Zephyr

Chuck Jordan <Chuck.Jordan@...>
 

Actually, I'm leaning toward the opinion that the names of the I/O shouldn't matter.
But what does matter, are the properties associated with that object.

Take GPIO, for example. Some GPIO implementation may support special capabilities like debounce and interrupts.
Other GPIO may not.
So given a NAME of an instance, you would want some means of fetching the "gestalt" (old Apple term) for that object.
Each named I/O instance, register with the I/O subsystem, probably needs to have "key-value" pairs that convey things about the instance.
You would also need to be able to iterate over I/O instances, and FILTER thru them to find ones that have the capabilities you're looking for. For example, you might want to search all I/O that are both GPIO, have DEBOUNCE and have INTERRUPT capability.
Or, suppose you want to search thru all I/O that is UART, and can support baud rates greater than 115200.
Or to search for a file-system capable mass storage device that has free space greater than 1MB.
The I/O abstraction layer should provide these details.

This allows the application developer, once they've figured out what name to use during an OPEN, to also check, via ioctl or some such, that their I/O is capable of supporting what they are after.
So the problem is not just knowing the name, its also knowing whether that named instance has the right-stuff.

-ChuckJ

-----Original Message-----
From: zephyr-devel-bounces@lists.zephyrproject.org [mailto:zephyr-devel-bounces@lists.zephyrproject.org] On Behalf Of Paul Sokolovsky
Sent: Friday, February 10, 2017 4:31 AM
To: Maureen Helm <maureen.helm@nxp.com>
Cc: devel@lists.zephyrproject.org
Subject: Re: [Zephyr-devel] Inconsistent and ever-changing device naming in Zephyr

Hello Maureen,

On Tue, 7 Feb 2017 21:45:24 +0000
Maureen Helm <maureen.helm@nxp.com> wrote:

[]

1. frdm_k64f GPIO port naming changed from "GPIO_0" to (!!)
"gpio_porta".
This is my fault. I was not aware the port names were being used this
way. I tend to use the config names rather than the strings
themselves. For example, in boards/arm/frdm_k64f/Kconfig.defconfig:

config FXOS8700_GPIO_NAME
default GPIO_MCUX_PORTC_NAME

Please, please let me know if you encounter problems like this again.
Thanks for understanding of these issues.

[]
The question what to do about this. Possible high-level approaches
can be:

a) Establish (well, reconfirm/clarify) and uphold consistent naming
conventions across ports, architectures, and boards.
Since you're most affected, mind making a proposal?
Ok, let me also start with facts (in preference of starting with my own opinion).

1. So, mentioned previously Zephyr.js project has code like this:
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_01org_zephyr.js_blob_master_src_zjs-5Fgpio.c-23L459&d=DwICAg&c=DPL6_X_6JkXFx7AXWqB0tg&r=Ur8eT0ZY1DOjJtZ8biKXp_CyOvecmZtsphp7SXIsE1Y&m=Gw9v9P4sBeBQB2qCQBmDvQccbUBgnraP5ao9FIaBh98&s=EcdSrQuy87WyLUQVduyfZhZloOcN8_WXoy128Vjhbjo&e= . In other words, Zephyr.js expects GPIO_0, GPIO_1, GPIO_2, etc. It used to be a fatal error if any device could not be opened. Couple of months ago I contributed a patch which makes it a non-fatal condition, at at the same time argued that it wouldn't scale for Zephyr.js to use such naming and make other assumptions, like the # of ports available, etc.

2. Let's see how GPIO devices are named across various ports in 1.6.0 (I take that version as having old naming for Kinetis ports). (The list is made using manual filtering of grep -i -r '"GPIO' results):

The config params for naming is also split between:

arch/ :

arc/soc/em9d/Kconfig.defconfig: default "GPIO_PORTA"
arc/soc/em11d/Kconfig.defconfig: default "GPIO_PORTB"
arc/soc/em7d/Kconfig.defconfig: default "GPIO_PORTC"
x86/soc/intel_quark/quark_x1000/Kconfig.defconfig.series: default "GPIO_CW"
x86/soc/intel_quark/quark_x1000/Kconfig.defconfig.series: default "GPIO_RW"
x86/soc/intel_quark/quark_x1000/Kconfig.defconfig.series: default "GPIO_0"

and drivers/gpio/:

gpio_stm32.c:GPIO_DEVICE_INIT("GPIOA", a, GPIOA_BASE, STM32_PORTA,
Kconfig.cmsdk_ahb: default "GPIO_0"
Kconfig.dw: default "GPIO_0"
Kconfig.k64: default "GPIO_0"
Kconfig.nrf5: default "GPIO_0"
Kconfig.pcal9535a: default "GPIO_P0"
Kconfig.qmsi: default "GPIO_0"
Kconfig.qmsi: default "GPIO_SS_1"
Kconfig.sch: default "GPIO_0"

So, from this listing it's clear that simplistic "use numbers for identification, start from 0", as assumed by the Z.js code above, wouldn't be achievable. One basic reason is given by Erwan Gouriou in his response - if a vendor datasheet names devices (not necessarily GPIO
ports) from 1, and not 0, then it would be hard time to argue that Zephyr should still count from 0, as indeed, that would be recurring confusion point.

That would mean that point "b) Send a strong message to application developers that they should not rely on any patterns of Zephyr device naming" would be there no matter what.

Does that mean that there should not be any convention to Zephyr device naming? Just as other participants in the discussion, I think it's better to have them, because lack of conventions and directions may mean that there would be "random" changes, as in case of Kinetis/MCUX port name change discussed above.

Looking at the grep results above, I'd formulate guidelines as:

1. Devices of similar type should have consistent prefix, e.g. "GPIO_", "I2C_", etc.
2. Device name should be uppercase.
3. Underscores should be used as separators.
4. Device type prefix should be separated by an underscore too (all devicenames above follow that, except stm32 with "GPIOA", "GPIOB", etc.) 5. Device names should be short and avoid having superfluous parts.
E.g., it's a basic GPIO hardware fact that GPIO ping go packed in ports. So, "GPIO_PORTA" is way too verbose and doesn't convey much useful information in its "PORT" part.

Examples of good names: GPIO_0, GPIO_99, GPIO_A, GPIO_AA (27th port),
GPIO_SS_0 (as used by multicore-core Quark SoC above to differentiate ports on different cores, hard to argue they shouldn't be doing that, though I have no idea what "SS" means).

Examples of bad names: GPIOA (missing underscore), GPIO_PORTA (too verbose, "PORT" is superfluous), GPIO_P0 ("P" apparently means port, superfluous), gpio_1 (should be upper case), PIN_1 (even if it happens to be 1 pin on a port, follow the standard prefix), GPO_1 (even if it's output-only port/pin, follow the standard prefix).


b) Send a strong message to application developers that they should
not rely on any patterns of Zephyr device naming, and even on the
naming at all, and instead should treat it as a configuration
parameter, which ultimately should be set by a user (and thus apps
should make such configuration explicit and easy for users).
[]

--
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs Follow Linaro: https://urldefense.proofpoint.com/v2/url?u=http-3A__www.facebook.com_pages_Linaro&d=DwICAg&c=DPL6_X_6JkXFx7AXWqB0tg&r=Ur8eT0ZY1DOjJtZ8biKXp_CyOvecmZtsphp7SXIsE1Y&m=Gw9v9P4sBeBQB2qCQBmDvQccbUBgnraP5ao9FIaBh98&s=ZKgYBpmkadgt4k-GWgxk0qpEr54xDeQDKSf-91I0unU&e=
https://urldefense.proofpoint.com/v2/url?u=http-3A__twitter.com_-23-21_linaroorg&d=DwICAg&c=DPL6_X_6JkXFx7AXWqB0tg&r=Ur8eT0ZY1DOjJtZ8biKXp_CyOvecmZtsphp7SXIsE1Y&m=Gw9v9P4sBeBQB2qCQBmDvQccbUBgnraP5ao9FIaBh98&s=pO_5cWLMg5XInmbA0OiEkBQSYK6IbxbX9-lnHVlwirA&e= - https://urldefense.proofpoint.com/v2/url?u=http-3A__www.linaro.org_linaro-2Dblog&d=DwICAg&c=DPL6_X_6JkXFx7AXWqB0tg&r=Ur8eT0ZY1DOjJtZ8biKXp_CyOvecmZtsphp7SXIsE1Y&m=Gw9v9P4sBeBQB2qCQBmDvQccbUBgnraP5ao9FIaBh98&s=CAFTnOsX1RZEqPKcLxbzK6nNCHo37S76ZsuUf6UNfqk&e=
_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@lists.zephyrproject.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.zephyrproject.org_mailman_listinfo_zephyr-2Ddevel&d=DwICAg&c=DPL6_X_6JkXFx7AXWqB0tg&r=Ur8eT0ZY1DOjJtZ8biKXp_CyOvecmZtsphp7SXIsE1Y&m=Gw9v9P4sBeBQB2qCQBmDvQccbUBgnraP5ao9FIaBh98&s=NICXw6qnd35aaKp2WfCFJND4zLjD53CZSxNLBk8sOkI&e=


Re: Inconsistent and ever-changing device naming in Zephyr

Andy Gross
 

On 10 February 2017 at 08:43, Paul Sokolovsky
<paul.sokolovsky@linaro.org> wrote:
On Fri, 10 Feb 2017 11:47:02 +0000
"Jon Medhurst (Tixy)" <tixy@linaro.org> wrote:

On Thu, 2017-02-09 at 22:56 -0600, Andy Gross wrote:
As for matching device names to #defines to device tree data, I
think the solution for that lies in the YAML file itself. As part
of the config, we put in the device name we want and this is used
to parse the DT and get the right mapping. In addition this allows
us to generate whatever device specific prefix we need.
Hmm, my concern was about having to have per-board or per-soc yaml
files (which I think is a wrong step) e.g. to have to do mappings
from say FOO_UART_<REG_ADDRESS> to FOO_UART_0, FOO_UART_1 etc. Seems
to me that DT parser can be smart and sort things by <REG_ADDRESS>
and assign them instance numbers 0..N.
SoC uart mappings are one thing. Board uart mappings are another.
SoC uart mappings are merely assigning an index to a base address and
then generating the label based on some prefix. The yaml is just
about how to parse and build up the labels for the contents of the DT.
The DT needs to specify what the board uart mappings are and you will
have a per board DT file which includes a SoC file. And with a DT
overlay, we can then support application layer changes which today are
done in the prj files.


I understand this discusses details of DT bindings and processing, but
for my own and other folks' understanding, I'd like to point that for a
device name (as in: the string you pass to device_get_binding()
indeed), any automatic means of derivation e.g. based on base address
won't work. That's because ultimately these names should match a
datasheet (I guess it would be hard to find someone who'd challenge
that), and those means of identification are vendor-specific and look
arbitrary for the reset of the world.
The thing is, there is the datasheet and there is the board. From a
end user perspective, the only thing that matters is the board's
labeling. Board uart 0 may be SoC uart 3. And they did that because
they couldn't use uart0 because the rx/tx pins for that were being
used for something else.

And, the base address can't really be used to derive index because
there are plenty of vendors who don't to ordered addresses on nodes,
or they skip around.

On top of that, what if you have more than one unique UART IP on the
board? Which is uart0 then?

For example, UART1's base address doesn't have to be greater than
UART0's. Examples of identification starting from 1 and using other
sequences (e.g. letters) were given before. And there can be arbitrary
gaps, e.g. a specific SoC may have Timers: 3, 4, and 7 (ditto for GPIO
ports, ditto for anything).
Exactly.


Re: Inconsistent and ever-changing device naming in Zephyr

Paul Sokolovsky
 

On Fri, 10 Feb 2017 15:08:29 +0000
"Jon Medhurst (Tixy)" <tixy@linaro.org> wrote:

On Fri, 2017-02-10 at 17:43 +0300, Paul Sokolovsky wrote:
Hmm, my concern was about having to have per-board or per-soc yaml
files (which I think is a wrong step) e.g. to have to do mappings
from say FOO_UART_<REG_ADDRESS> to FOO_UART_0, FOO_UART_1 etc.
Seems to me that DT parser can be smart and sort things by
<REG_ADDRESS> and assign them instance numbers 0..N.
I understand this discusses details of DT bindings and processing,
but for my own and other folks' understanding, I'd like to point
that for a device name (as in: the string you pass to
device_get_binding() indeed), any automatic means of derivation
e.g. based on base address won't work.
Yes, I agree with that. That's why I original asked about which 'name'
aliases in DT we're being used for, a) the name you pass to
device_get_binding, or b) the name used in C macro name inside the
device implementation, or, I guess c) both, if you have different
aliases to do that.

a) makes sense and what this email thread seems to agree on, but b)
was what was hinted at when I asked about avoiding the need for the
current fixup file workaround in the RFC patchset. So I was trying to
get some clarity. (Guess that means I sorta hijacked the thread,
sorry)
Nope, I really appreciate different people approaching this from
different sides, and considering the usecases and details they have in
mind. Well, I myself raised it with just one case in mind: how Zephyr
middleware like Zephyr.js, MicroPython, etc. can deal with that, but
of course there're more facets to it. And I don't hold my breath
for an immediate solution, but starting to search for a common ground
is definitely useful.


--
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog


Daily Gerrit Digest

donotreply@...
 

NEW within last 24 hours:
- https://gerrit.zephyrproject.org/r/11062 : arm: enable direct interrupts feature
- https://gerrit.zephyrproject.org/r/11087 : Merge net branch into master
- https://gerrit.zephyrproject.org/r/11089 : boards: panther: Use 115200 baudrate for BLE UART
- https://gerrit.zephyrproject.org/r/11088 : doc: boards: Move nRF5x DK board doc from the wiki to git
- https://gerrit.zephyrproject.org/r/11051 : net/dhcpv4: Fix event/state mismatch
- https://gerrit.zephyrproject.org/r/11078 : iot/zoap: Improve zoap.h documentation
- https://gerrit.zephyrproject.org/r/11080 : iot/zoap: Fix handling of 16-bytes block-wise transfers
- https://gerrit.zephyrproject.org/r/11077 : riscv32: pulpino does not support XIP
- https://gerrit.zephyrproject.org/r/11085 : arduino_101: bmi160: use new device name
- https://gerrit.zephyrproject.org/r/11083 : samples: bmi160: use new SPI driver name
- https://gerrit.zephyrproject.org/r/11082 : iot/zoap: Add missing const modifier to header file
- https://gerrit.zephyrproject.org/r/11081 : iot/zoap: Fix header indentation
- https://gerrit.zephyrproject.org/r/11079 : samples/zoap-server: Update docs with information about libcoap
- https://gerrit.zephyrproject.org/r/11076 : REVERTME: tests: stackprot: disable on xtensa
- https://gerrit.zephyrproject.org/r/11075 : REVERTME: cpp_synchronization: disable on Xtensa
- https://gerrit.zephyrproject.org/r/11072 : nios2: use gen_isr_tables mechanism
- https://gerrit.zephyrproject.org/r/11071 : tests: add test for gen_isr_table
- https://gerrit.zephyrproject.org/r/11070 : grove: fix variable type mismatch
- https://gerrit.zephyrproject.org/r/11052 : net/dhcpv4: Remove unused dhcpv4 offer state
- https://gerrit.zephyrproject.org/r/11054 : sanitycheck: Let waitpid script kill Xtensa ISS if user hits ctrl+c.

UPDATED within last 24 hours:
- https://gerrit.zephyrproject.org/r/10814 : Added sensor driver for SI1153. Added proximity sensor_channel entries in sensor.h
- https://gerrit.zephyrproject.org/r/10596 : arm: cmsis: Convert _Scb*FaultIs* & _ScbIs*Fault to use CMSIS register access
- https://gerrit.zephyrproject.org/r/10599 : arm: cmsis: Convert _ClearFaults to use direct CMSIS register access
- https://gerrit.zephyrproject.org/r/10598 : arm: cmsis: Convert printing of MMFSR, BFSR, and UFSR to CMSIS
- https://gerrit.zephyrproject.org/r/11024 : qemu_cortex_m3: fixed network connectivity
- https://gerrit.zephyrproject.org/r/10813 : Added sensor driver for ADXRS290
- https://gerrit.zephyrproject.org/r/10811 : BME280 added support for SPI comunication. quark_se_c1000_ss added support for third Slave Select of SS_SPI0
- https://gerrit.zephyrproject.org/r/10853 : drivers: Add Atmel SAM RTC driver
- https://gerrit.zephyrproject.org/r/10920 : kw41z: add base DTS support
- https://gerrit.zephyrproject.org/r/10902 : eth/mcux: Add basic PHY support.
- https://gerrit.zephyrproject.org/r/10369 : ataes132a: Adds a driver to support ATAES132A device
- https://gerrit.zephyrproject.org/r/10684 : driver: mcr20a: cleanup and use semaphore for PHY access
- https://gerrit.zephyrproject.org/r/3311 : include/crypto: Crypto abstraction header
- https://gerrit.zephyrproject.org/r/10993 : tests/common: Add tests for sys_dlist_*
- https://gerrit.zephyrproject.org/r/11000 : drivers: Convert FOR_EACH macro instances to use CONTAINER
- https://gerrit.zephyrproject.org/r/10999 : Bluetooth: Convert FOR_EACH macro instances to use CONTAINER
- https://gerrit.zephyrproject.org/r/10998 : net: Convert FOR_EACH macro instances to use CONTAINER
- https://gerrit.zephyrproject.org/r/10997 : kernel: Use SYS_DLIST_FOR_EACH_CONTAINER
- https://gerrit.zephyrproject.org/r/10992 : dlist: Introduce CONTAINER macros
- https://gerrit.zephyrproject.org/r/10927 : tests/slist: Exercise CONTAINER macros
- https://gerrit.zephyrproject.org/r/10857 : nucleo_l476rg: Enable device tree usage for Nucleo
- https://gerrit.zephyrproject.org/r/10860 : v2m_beetle: uart: Add DTS support to UART driver
- https://gerrit.zephyrproject.org/r/10859 : v2m_beetle: Add base DTS support
- https://gerrit.zephyrproject.org/r/10627 : RFC: DTS: Kinetis: Add base support for Kinetis
- https://gerrit.zephyrproject.org/r/10855 : cc3200: Enable device tree usage for CC3200
- https://gerrit.zephyrproject.org/r/10858 : stm32: uart: Add DTS support to STM32 UART driver
- https://gerrit.zephyrproject.org/r/10628 : RFC: DTS: Kinetis: Add FRDM_K64F support
- https://gerrit.zephyrproject.org/r/10629 : RFC: DTS: Kinetis: Add support for Hexiwear K64
- https://gerrit.zephyrproject.org/r/10854 : cc3200: dts: Add base DTS support for TI CC3200
- https://gerrit.zephyrproject.org/r/10856 : stm32: Add base DTS support for Nucleo board
- https://gerrit.zephyrproject.org/r/7738 : RFC: Add support for Device Tree
- https://gerrit.zephyrproject.org/r/10626 : RFC: DTS: Add base DTS and YAML definitions
- https://gerrit.zephyrproject.org/r/10605 : arm: cmsis: cleanup use of _SCS_CPACR_CP1{0,1}_Pos define
- https://gerrit.zephyrproject.org/r/10601 : arm: cmsis: Remove last bits of scs/scb as we've converted to CMSIS
- https://gerrit.zephyrproject.org/r/10600 : arm: cmsis: Convert _Scb*Fault*Reset to use direct CMSIS register access
- https://gerrit.zephyrproject.org/r/10597 : arm: cmsis: Convert _Scb*FaultAddrGet to use direct CMSIS register access
- https://gerrit.zephyrproject.org/r/10718 : tests: dma: update dma loop transfer app
- https://gerrit.zephyrproject.org/r/11027 : gen_isr_tables: New static interrupt build mechanism
- https://gerrit.zephyrproject.org/r/11026 : interrupts: use fixed section name for vector table
- https://gerrit.zephyrproject.org/r/11028 : arm: use gen_isr_tables mechanism for interrupts
- https://gerrit.zephyrproject.org/r/11017 : grove: fix variable type mismatch
- https://gerrit.zephyrproject.org/r/10690 : tests: Introduced new config option to add extra stack size for tests.
- https://gerrit.zephyrproject.org/r/10944 : drivers: Remove unnecessary CONFIG_SYS_POWER_DEEP_SLEEP
- https://gerrit.zephyrproject.org/r/11025 : tests: add zephyr counter and timer api test
- https://gerrit.zephyrproject.org/r/11003 : quark_se: Save/restore debug registers.
- https://gerrit.zephyrproject.org/r/10812 : Added sensor driver for ADXL362
- https://gerrit.zephyrproject.org/r/10606 : build: multicore project sample
- https://gerrit.zephyrproject.org/r/9883 : i2c: Adds a functions set that supports flexible addressing.

MERGED within last 24 hours:
- https://gerrit.zephyrproject.org/r/11084 : Bluetooth: nble: Catch and handle non-zero fn_index
- https://gerrit.zephyrproject.org/r/11086 : Bluetooth: Fix missing connection cleanup in some scenarios
- https://gerrit.zephyrproject.org/r/11050 : net/dhcpv4: Ensure the retransmission attempts counter gets reset.
- https://gerrit.zephyrproject.org/r/11044 : net: nbuf: Fix constness of data param in net_nbuf_append
- https://gerrit.zephyrproject.org/r/11045 : net: if: Change the addr param type in net_if_ipv6_maddr_add/rm
- https://gerrit.zephyrproject.org/r/11047 : net: context: Fix the multicast address lookup in bind
- https://gerrit.zephyrproject.org/r/11046 : net: if: Change the iface param in net_if_ipv6_maddr_lookup
- https://gerrit.zephyrproject.org/r/11067 : Bluetooth: Fix not clearing signaled flag for conn_change signal
- https://gerrit.zephyrproject.org/r/11053 : doc: Fix encoding problem
- https://gerrit.zephyrproject.org/r/11060 : kernel/poll: refactor is_polling()
- https://gerrit.zephyrproject.org/r/11061 : kernel/poll: fix registrations that were not always cleared
- https://gerrit.zephyrproject.org/r/11063 : test/kernel/poll: fix putting wrong .signaled to 0
- https://gerrit.zephyrproject.org/r/11064 : kernel/poll: fix signal.signaled not being set when k_poll() waits
- https://gerrit.zephyrproject.org/r/11065 : tests/kernel/poll: verify .signaled is set correctly
- https://gerrit.zephyrproject.org/r/11074 : doc: update make clean to remove doxygen folder
- https://gerrit.zephyrproject.org/r/11073 : doc: update .gitignore
- https://gerrit.zephyrproject.org/r/11066 : sanity: filter the build-all test for ethernet
- https://gerrit.zephyrproject.org/r/11069 : Xtensa port: Fixed compilation errors caused by last rebase on master.
- https://gerrit.zephyrproject.org/r/11068 : Xtensa port: Prevent preemption of locked threads.
- https://gerrit.zephyrproject.org/r/11055 : linker quark_se: Fix operator precedence bug
- https://gerrit.zephyrproject.org/r/11048 : boards: add sensor subsystem for panther
- https://gerrit.zephyrproject.org/r/11049 : boards: fix board name for panther
- https://gerrit.zephyrproject.org/r/10996 : Bluetooth: AVDTP: Moving structures to headerfile
- https://gerrit.zephyrproject.org/r/10676 : gpio/stm32: fix in setting alternative function
- https://gerrit.zephyrproject.org/r/10801 : board: add nucleo_l476rg documentation
- https://gerrit.zephyrproject.org/r/10489 : api: dma: dma api update
- https://gerrit.zephyrproject.org/r/10541 : drivers: dma_shim: update dma qmsi shim driver
- https://gerrit.zephyrproject.org/r/10693 : tests: dma: update dma block transfer app
- https://gerrit.zephyrproject.org/r/11043 : Merge net branch into master
- https://gerrit.zephyrproject.org/r/10646 : hexiwear_k64: Add RST board documentation
- https://gerrit.zephyrproject.org/r/10413 : gpio: update stm32 gpio to support LL clock control driver
- https://gerrit.zephyrproject.org/r/10414 : pinmux: update stm32 pinmux to support LL clock control driver
- https://gerrit.zephyrproject.org/r/10415 : uart: update stm32 uart to support LL clock control driver
- https://gerrit.zephyrproject.org/r/10416 : i2c: stm32: change deprecated constant
- https://gerrit.zephyrproject.org/r/10417 : i2c: update stm32 i2c_lx to support LL clock control driver
- https://gerrit.zephyrproject.org/r/10418 : pwm: update stm32 pwm to support LL clock control driver
- https://gerrit.zephyrproject.org/r/10419 : flash: update stm32 flash_f3x to support LL clock control driver
- https://gerrit.zephyrproject.org/r/10422 : board: nucleo_f334r8: enable support of LL Cube clock control driver
- https://gerrit.zephyrproject.org/r/10648 : clock_control: stm32: code optimization
- https://gerrit.zephyrproject.org/r/10424 : boards: nucleo_l476rg: enable support of LL Cube clock control driver
- https://gerrit.zephyrproject.org/r/10472 : clock control: clean up after stm32cube LL driver
- https://gerrit.zephyrproject.org/r/10423 : board: stm32373c_eval: enable support of LL Cube clock control driver
- https://gerrit.zephyrproject.org/r/10473 : drivers: stm32: clean up after stm23cube based clock control
- https://gerrit.zephyrproject.org/r/10412 : clock control:stm32: provide STM32Cube LL based driver
- https://gerrit.zephyrproject.org/r/10420 : soc: stm32l4xx: support of Cube LL Clock driver
- https://gerrit.zephyrproject.org/r/10421 : soc: stm32f3xx: support of Cube LL Clock driver
- https://gerrit.zephyrproject.org/r/10470 : soc: stm32l4x: clean up after Cube LL clock control
- https://gerrit.zephyrproject.org/r/10471 : soc: stm32f3x: clean up after Cube LL clock control


Re: Inconsistent and ever-changing device naming in Zephyr

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

On Fri, 2017-02-10 at 17:43 +0300, Paul Sokolovsky wrote:
Hmm, my concern was about having to have per-board or per-soc yaml
files (which I think is a wrong step) e.g. to have to do mappings
from say FOO_UART_<REG_ADDRESS> to FOO_UART_0, FOO_UART_1 etc. Seems
to me that DT parser can be smart and sort things by <REG_ADDRESS>
and assign them instance numbers 0..N.
I understand this discusses details of DT bindings and processing, but
for my own and other folks' understanding, I'd like to point that for a
device name (as in: the string you pass to device_get_binding()
indeed), any automatic means of derivation e.g. based on base address
won't work.
Yes, I agree with that. That's why I original asked about which 'name'
aliases in DT we're being used for, a) the name you pass to
device_get_binding, or b) the name used in C macro name inside the
device implementation, or, I guess c) both, if you have different
aliases to do that.

a) makes sense and what this email thread seems to agree on, but b) was
what was hinted at when I asked about avoiding the need for the current
fixup file workaround in the RFC patchset. So I was trying to get some
clarity. (Guess that means I sorta hijacked the thread, sorry)

--
Tixy


Re: Inconsistent and ever-changing device naming in Zephyr

Paul Sokolovsky
 

On Fri, 10 Feb 2017 11:47:02 +0000
"Jon Medhurst (Tixy)" <tixy@linaro.org> wrote:

On Thu, 2017-02-09 at 22:56 -0600, Andy Gross wrote:
As for matching device names to #defines to device tree data, I
think the solution for that lies in the YAML file itself.  As part
of the config, we put in the device name we want and this is used
to parse the DT and get the right mapping.  In addition this allows
us to generate whatever device specific prefix we need.
Hmm, my concern was about having to have per-board or per-soc yaml
files (which I think is a wrong step) e.g. to have to do mappings
from say FOO_UART_<REG_ADDRESS> to FOO_UART_0, FOO_UART_1 etc. Seems
to me that DT parser can be smart and sort things by <REG_ADDRESS>
and assign them instance numbers 0..N.
I understand this discusses details of DT bindings and processing, but
for my own and other folks' understanding, I'd like to point that for a
device name (as in: the string you pass to device_get_binding()
indeed), any automatic means of derivation e.g. based on base address
won't work. That's because ultimately these names should match a
datasheet (I guess it would be hard to find someone who'd challenge
that), and those means of identification are vendor-specific and look
arbitrary for the reset of the world.

For example, UART1's base address doesn't have to be greater than
UART0's. Examples of identification starting from 1 and using other
sequences (e.g. letters) were given before. And there can be arbitrary
gaps, e.g. a specific SoC may have Timers: 3, 4, and 7 (ditto for GPIO
ports, ditto for anything).

[]

--
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog


Re: Inconsistent and ever-changing device naming in Zephyr

Paul Sokolovsky
 

Hello Andy,

On Thu, 9 Feb 2017 22:56:40 -0600
Andy Gross <andy.gross@linaro.org> wrote:

[]

That brings us to the device names themselves. I am of two minds on
this. On one hand, the names need to match the names on the board or
board documentation. It makes it difficult for users to have to
determine the zephyr name that matches the silkscreen name. On the
other hand, having all these different formats trigger my OCD. I feel
stronger about the silkscreen/documentation matching the names. So
place my vote in the chaos column.
Well, there're dozens of architectures in the world. Thousands of
individual SoC/MCU models using them, and millions of individual board
models using those SoCs. Generally, no OS can support this
million-variety upstream, and even if it gives *perfect* and the
*easiest* to use tools for that downstream, a lot of vendors behind
those millions of boards still won't use them right or at all
(projections roughly based on the Linux experience).

So, the talk is that "SoC" level should be the primary, and naming for
one SoC should be reasonably consistent with all the rest. Than a board
OEM can save a bunch of trouble both themselves and their users by just
naming their board signals what the SoC calls them - or go thru the
trouble of overriding them on OS, etc. levels, documenting how their
virtual signals map to real SoC's, etc.

[]

--
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog


Re: Inconsistent and ever-changing device naming in Zephyr

Paul Sokolovsky
 

Hello Daniel,

On Fri, 10 Feb 2017 11:54:27 +0000
Daniel Thompson <daniel.thompson@linaro.org> wrote:

On 09/02/17 19:27, Chuck Jordan wrote:

Personally I'm not a fan of gratuitously different naming (for
example different driver writers arbitrarily selecting ALLCAPS and
lowercase). However I *am* a fan of selecting labels from "facts"
about the board (silk screening, datasheet port/connector names,
etc).
As a trivial example I'd really dislike a system where "for
consistency" we force BSPs to call something "UART-0" when the
silkscreen (or front-panel) says "DB9-1".
I guess that is an argument *against* board-to-board consistency!
[chuck] Minor point, but the device driver talks to a UART and the
UART may have a different designation on the schematic, not visible
to the outside user. A name like "DB9-1" is a physical connector
name, and it can be unclear which UART is attached to it, which
jumpers need to be changed, whether there is another layer of
switching between UART and connector and so forth. I've seen boards
where a UART can be directed to one of many different connectors via
jumper choices.
Quite so, board designers have so many different ways they can make
serial ports harder than necessary to use.

In fact that's *exactly* why peripheral naming needs ultimately
should be a per-board decision in the BSP (possibly expressed via
DT). Note that this does *not* mean that SoC-wide defaults are bad.
SoC-wide defaults are great and simplify things for uses of sane or
simple board designs.
To clarify, the concern behind my original mail is exactly regarding
having a good consistent scheme for "SoC-wide defaults". Across SoCs of
course, and with an idea that "reference" boards for these SoCs (as
available in Zephyr upstream) would follow them.

With a usecase you present above - support for widely varying OEM
boards, I agree that it should be possible to override "anything", and
the only scalable way to do that appears to be the Device Tree.

(I would argue whether each and every OEM should override too much for
a particular board, and if many actually would do that, but that's
not the point of the discussion, it instead being that Zephyr should
provide flexibility to do so, while hopefully also giving good
guidelines on suggested naming, and provide in-tree device ports which
adhere to these guidelines).

[]

--
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog

5561 - 5580 of 8046