profile
viewpoint
朱天龙 (Armink) armink @RT-Thread Shanghai, China

armink/EasyLogger 1455

An ultra-lightweight(ROM<1.6K, RAM<0.3k), high-performance C/C++ log library. | 一款超轻量级(ROM<1.6K, RAM<0.3k)、高性能的 C/C++ 日志库

armink/EasyFlash 1172

Lightweight IoT device information storage solution: KV/IAP/LOG. | 轻量级物联网设备信息存储方案:参数存储、在线升级及日志存储 ,全新一代版本请移步至 https://github.com/armink/FlashDB

armink/FreeModbus_Slave-Master-RTT-STM32 758

Add master mode to FreeModbus. | 在 FreeModbus 中添加主机模式

armink/CmBacktrace 755

Advanced fault backtrace library for ARM Cortex-M series MCU | ARM Cortex-M 系列 MCU 错误追踪库

armink/FlashDB 283

An ultra-lightweight database that supports key-value and time series data | 一款支持 KV 数据和时序数据的超轻量级数据库

armink/HackSTLinkUpgrade 37

暴力升级你的 ST-Link 及 STM32CubeIDE

armink/EasyDataManager 23

A c language advanced framework of data manager. Support static data and dynamic data. Supply easy and simple interface for app.

armink/MpyOnRtt 7

MicroPython port for RT-Thread on STM32F4 board

armink/CmBacktraceFlashLogDemo 5

The CmBacktrace flash log demo base on Pandora IoT Board | 基于潘多拉 IoT 开发板的 CmBacktrace Flash 日志存储示例

armink/CharsetConvert 3

A java implement charset convert tool .Such as hex to utf-8, hex to gbk, utf-8 to hex and gbk to hex.Suitable for use in a network, serial debugging process.

pull request commentzephyrproject-rtos/zephyr

boards: arm: add stm32f103_mini board

Thanks for this addition! Adding a new stm32f103 soc is a bit tricky, so please follow may advices. Also please clarify the flash procedure.

Thank you for your review and pointing out those issues, and I have fixed them. Looking forward to your furthur opinions, thanks again.

wuhanstudio

comment created time in 16 minutes

issue commentzephyrproject-rtos/zephyr

usb: stm32: MCU fall in deadlock when calling sleep API during USB transfer

@jfischer-no thx for reply. Do you mean you want tweaked sample apps of zephyr main tree?

easternblack

comment created time in 20 minutes

Pull request review commentzephyrproject-rtos/zephyr

device: refactor declare/define macros to support device definition and reference from devicetree nodes

 void main(void) 	bool led_is_on = true; 	int ret; -	dev = device_get_binding(LED0);+	dev = device_if_ready(DEVICE_DT_GET(CTLR_NODE));

I'd say drop the change to the sample for now and we can deal with it once we've got the full class of drivers converted over. I'm guessing we'll end up introducing a helper that does both the DEVICE_DT_GET and ready check at the same time.

pabigot

comment created time in an hour

pull request commentzephyrproject-rtos/zephyr

device: refactor declare/define macros to support device definition and reference from devicetree nodes

I don't know. ebe20f9 added it for a reason, and I remember finding it useful to have it explicit in another situation (but not why, or whether that effort got anywhere). It'll all be reworked when we get moving on device power management anyway.

Any sense if its better/more useful for it to be NULL or device_pm_control_nop?

pabigot

comment created time in an hour

issue commentzephyrproject-rtos/zephyr

Bluetooth mesh example not working

wow, Do you mean that replace the NRF52DK_NRF52832 by NRF52_VBLUNO52 and and finally run on E73-2G4M04S1B the ZEPHYR ?

I am having the same problem, my E73-2G4M04S1B does not run ZEPHYR!

NilsMinor

comment created time in 2 hours

Pull request review commentzephyrproject-rtos/zephyr

boards/arm: Adding Contextual Electronics Advanced BLE Cell board to Zephyr

+/*+ * Copyright (c) 2020 Analog Life LLC+ *+ * SPDX-License-Identifier: Apache-2.0+ */++/dts-v1/;+#include <nordic/nrf52840_qiaa.dtsi>++/ {+	model = "nRF52840 BLE Cell";+	compatible = "nordic,nrf52840-ble-cell";++	chosen {+		zephyr,console = &uart0;+		zephyr,shell-uart = &uart0;+		zephyr,sram = &sram0;+		zephyr,flash = &flash0;+		zephyr,code-partition = &slot0_partition;+	};+};++&gpiote {+	status = "okay";+};++&gpio0 {+	status = "okay";+};++&gpio1 {+	status = "okay";+};++&uart0 {+	compatible = "nordic,nrf-uart";+	status = "okay";+	current-speed = <115200>;++	tx-pin = <7>;+	rx-pin = <6>;+};++arduino_serial: &uart1 {+	status = "okay";+	current-speed = <115200>;++	/* UART Pin info. */+	rx-pin  = <20>;+	tx-pin  = <24>;+	rts-pin = <17>;+	cts-pin = <16>;++	/* Use hardware flow control. */+	hw-flow-control;++	/* BG9x description. */+	quectel_bg9x {+		compatible = "quectel,bg9x";+		label      = "quectel-bg9x";+		status     = "okay";++		mdm-power-gpios = <&gpio1 5  0>;+		mdm-reset-gpios = <&gpio1 6  0>;+		mdm-dtr-gpios   = <&gpio0 22 0>;+	};+};++arduino_i2c: &i2c0 {+	compatible = "nordic,nrf-twi";+	status = "okay";+	sda-pin = <27>;+	scl-pin = <26>;++	/* This I2C device is interfaced with the "BQ25895R" charger. */+};++&spi2 {+	compatible = "nordic,nrf-spi";+	status = "okay";+	sck-pin  = <19>;+	mosi-pin = <23>;+	miso-pin = <21>;++	/* This SPI device is interfaced with the SD card. */+};++&flash0 {+	/*+	 * For more information, see:+	 * https://docs.zephyrproject.org/latest/guides/dts/legacy-macros.html#legacy-flash-partitions

Thanks for pointing out, Will remove.

bwasim

comment created time in 3 hours

pull request commentcontiki-ng/contiki-ng

Contrib/simplelink base demo enhanced

@jsolderitsch

Hi James. As you may have seen from notification noise, Alex and I have been going through / fixing / merging various simplelink sensor-related PRs. #1283 and #1290 are in, #1285 we are working on improving with respect to the MPU code.

Given the amount of work required to get things to work to a good standard, we have deferred the lot to the next release in spring. This gives us time to get things done properly.

There is a lot of good code here in your PR. Do you think you can do a clean code rebase in order to exclude from the history here all the commits that are already part of branch develop? Once we have a clean history, we'll give you some change requests.

@alexstanoev ping for info.

Always happy to support with git-related commands - poke us on gitter. Thanks for your time to contribute to the project!

jsolderitsch

comment created time in 3 hours

Pull request review commentcontiki-ng/contiki-ng

Add I2C manipulation module for platform Simplelink

+/*+ * Copyright (c) 2018, Texas Instruments Incorporated - http://www.ti.com/+ * Copyright (c) 2020, George Oikonomou - http://www.spd.gr+ * All rights reserved.+ *+ * Redistribution and use in source and binary forms, with or without+ * modification, are permitted provided that the following conditions+ * are met:+ * 1. Redistributions of source code must retain the above copyright+ *    notice, this list of conditions and the following disclaimer.+ * 2. Redistributions in binary form must reproduce the above copyright+ *    notice, this list of conditions and the following disclaimer in the+ *    documentation and/or other materials provided with the distribution.+ * 3. Neither the name of the copyright holder nor the names of its+ *    contributors may be used to endorse or promote products derived+ *    from this software without specific prior written permission.+ *+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS+ * ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT+ * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS+ * FOR A PARTICULAR PURPOSE ARE DISCLAIMED.  IN NO EVENT SHALL THE+ * COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,+ * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES+ * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR+ * SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)+ * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,+ * STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)+ * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED+ * OF THE POSSIBILITY OF SUCH DAMAGE.+ */+/*---------------------------------------------------------------------------*/+/**+ * \addtogroup cc13xx-cc26xx-i2c+ * @{+ *+ * \file+ *   Implementation of the I2C HAL driver for CC13xx/CC26xx.+ *+ * \author+ *   Edvard Pettersen <e.pettersen@ti.com>+ * \author+ *   George Oikonomou <george@contiki-ng.org>+ */+/*---------------------------------------------------------------------------*/+#include "contiki.h"+#include "i2c-arch.h"++#include <stddef.h>+#include <stdbool.h>+#include <stdint.h>+/*---------------------------------------------------------------------------*/+bool+i2c_arch_write_read(I2C_Handle i2c_handle, uint_least8_t slave_addr,+                    void *wbuf, size_t wcount, void *rbuf,+                    size_t rcount)+{+  I2C_Transaction i2cTransaction = {+    .writeBuf = wbuf,+    .writeCount = wcount,+    .readBuf = rbuf,+    .readCount = rcount,+    .slaveAddress = slave_addr,+  };++  if(i2c_handle) {

Fixed with new commit

g-oikonomou

comment created time in 3 hours

Pull request review commentcontiki-ng/contiki-ng

Add I2C manipulation module for platform Simplelink

 enable_sensor(bool enable) static bool read_data(uint16_t *local_tmp, uint16_t *obj_tmp) {-  bool spi_ok = false;+  bool i2c_ok = false;    uint8_t status_data[] = { REG_STATUS };   uint16_t status_value = 0; -  spi_ok = i2c_write_read(status_data, sizeof(status_data),-                          &status_value, sizeof(status_value));-  if(!spi_ok) {+  i2c_handle = i2c_arch_acquire(Board_I2C0);++  if(i2c_handle) {

Fixed by rebase

g-oikonomou

comment created time in 3 hours

pull request commentcontiki-ng/contiki-ng

Add I2C manipulation module for platform Simplelink

Rebased on top of develop

g-oikonomou

comment created time in 3 hours

push eventcontiki-ng/contiki-ng

George Oikonomou

commit sha beadda90f192ca73fd328e0897515280486ecbcb

Provide a value to the BOARD definition macro For platform simplelink we currently pass `-D<BOARD>` (e.g. `-DBOARD_SENSORTAG=1`) instead of `-D<BOARD>=1`. This comment changes this behaviour to improve consistency between the cc26x0-cc12x0 and the simplelink platforms.

view details

George Oikonomou

commit sha 630920cc73c3d4480d7e0ef47a93be85b8023e3a

Fix the I2C peripheral acquire/release logic (OPT3001)

view details

George Oikonomou

commit sha 97dfd495a8fd8eda636f0db8125fa0c49a820cfd

Fix the I2C peripheral acquire/release logic (BMP280)

view details

George Oikonomou

commit sha bcb82ca911a3bd8387fb370f2365d475d5ff9334

Fix the I2C peripheral acquire/release logic (HDC1000)

view details

George Oikonomou

commit sha f002df0291fe095f892d098f479aafe97253b8da

Fix the I2C peripheral acquire/release logic (TMP007)

view details

George Oikonomou

commit sha bc59f298125790d58f10faaa73df91417f5b7caf

Fix i2c_acquire() conditional logic

view details

Alex Stanoev

commit sha 85eb980d09c8b198cd5e383b89381f12aa808962

Merge pull request #1283 from g-oikonomou/bugfix/simplelink-sensors Various fixes for Simplelink/sensortag sensors

view details

push time in 3 hours

PR merged contiki-ng/contiki-ng

Various fixes for Simplelink/sensortag sensors bug bug/medium pr/bugfix

This PR starts addressing some of the sensortag sensor flaws identified for platform Simplelink in #1282

  • We fix an error in a CPP conditional which resulted in the platform startup code failing to initialise the sensors module correctly.
  • We fix the I2C acquire/release logic for the OPT3001 sensor driver
  • We fix the I2C acquire/release logic for the BMP280 sensor driver
  • We fix the I2C acquire/release logic for the TMP007 sensor driver
  • We fix the I2C acquire/release logic for the HDC1000 sensor driver
  • We pass -D<board>=1 instead of -D<board> at compile time. This is done to make this platform consistent with platform cc26x0-cc13x0.

@jsolderitsch any help with testing appreciated.

+216 -51

4 comments

5 changed files

g-oikonomou

pr closed time in 3 hours

Pull request review commentcontiki-ng/contiki-ng

Various fixes for Simplelink/sensortag sensors

 read_data(uint16_t *local_tmp, uint16_t *obj_tmp)   uint8_t status_data[] = { REG_STATUS };   uint16_t status_value = 0; +  if(i2c_acquire()) {

Rebased over develop and addressed this.

g-oikonomou

comment created time in 3 hours

Pull request review commentcontiki-ng/contiki-ng

Various fixes for Simplelink/sensortag sensors

 read_data(uint16_t *local_tmp, uint16_t *obj_tmp)   uint8_t status_data[] = { REG_STATUS };   uint16_t status_value = 0; +  if(i2c_acquire()) {

Should be if(!i2c_acquire()) {

g-oikonomou

comment created time in 3 hours

pull request commentzephyrproject-rtos/zephyr

Bluetooth: controller: Fix ull_conn LSTO for must_expire

Separate into two different PRs, so that I can approve the Random Forced scheduling Kconfig.

Regarding is_must_expire, please add a simple upstream test to cover it, so that any future upstream regressions get caught of the features that not enabled by default in upstream samples.

Can this be a part of a later PR? I need to figure out how to create a test running on upstream code, without support for the "must_expire" feature in Nordic ULL. Ant ideas?

mtpr-ot

comment created time in 3 hours

pull request commentzephyrproject-rtos/zephyr

Bluetooth: controller: Fix ticker collision update race

@mtpr-ot Feel free to clean up my commit, may be have inline functions for handling ticker state, but can be a different PR.

I think it's fine - good catch. Thanks for your help.

mtpr-ot

comment created time in 4 hours

push eventcontiki-ng/contiki-ng

George Oikonomou

commit sha 502982d38921dbda37b4449e33e70f04980ab326

Move the cc26x0-demo to its own directory

view details

George Oikonomou

commit sha b39f3018d8671532b653b463ad8010ecbede5e21

Update the base demo's README

view details

George Oikonomou

commit sha f0800b400ef88d72e28e658a67427c37452a9eda

Adjust the example's Makefile

view details

George Oikonomou

commit sha 57f901e07608af688a30e71a3f97ae9c271ebb7c

Change the cc26xx demo to support both platforms This commit changes the cc26x0 demo to work on both the older `cc26x0-cc13x0` platform as well as the new `simplelink` platform.

view details

George Oikonomou

commit sha 17e30e8e3e56362bf23c20537b91f110b991c670

Test the CC13xx/CC26xx base demo for both supported platforms

view details

Alex Stanoev

commit sha 7c6dc551b9f620ed18c928af7224c2c4645406f0

Merge pull request #1290 from g-oikonomou/contrib/simplelink-base-demo Make the CC13xx/CC26xx base demo work for platform simplelink too

view details

push time in 4 hours

PR merged contiki-ng/contiki-ng

Reviewers
Make the CC13xx/CC26xx base demo work for platform simplelink too pr/enhancement

This pull changes the baseline cc26xx-demo under examples/platform-specific/cc26x0-cc13x0 to work for both CC13xx/CC26xx platforms (the older cc26x0-cc13x0 but now also the newer simplelink platform).

Firstly, we move the demo to its own subdirectory and we rename it to base-demo, since it was never CC26xx-specific anyway, it always also supported all CC13xx flavours. This allows us to add platform-specific subdirs without making the top-level dir structure confusing.

Secondly, we adjust the example such that it supports both intended platforms.

Lastly, we add tests to make sure the example builds correctly for both supported platforms. In compliance with the paperwork reduction act, we remove a test that is now redundant ;)

We currently don't have any simplelink-specific example projects. This PR will provide simplelink platform users with an example that demonstrates the platform's hardware-specific features.

+159 -41

5 comments

9 changed files

g-oikonomou

pr closed time in 4 hours

pull request commentcontiki-ng/contiki-ng

Various fixes for Simplelink/sensortag sensors

Following a discussion with @alexstanoev, we are deferring this to v4.7. We have changed the base branch for this PR back to develop.

g-oikonomou

comment created time in 4 hours

pull request commentcontiki-ng/contiki-ng

Make the CC13xx/CC26xx base demo work for platform simplelink too

Following a discussion with @alexstanoev, we are deferring this to v4.7. We have changed the base branch for this PR back to develop.

g-oikonomou

comment created time in 4 hours

issue commentzephyrproject-rtos/zephyr

OTA using Thread

I have a working FOTA over OT that I'm using successfully for more than a year and half in a test bed of more than 10 FTD and SED devices. It's based on @mike-scott work on https://github.com/foundriesio/dm-lwm2m , but not sure what its license is, and could we use it on Zephyr. If he confirm that it's OK to use it as a base I could push a PR for review here.

Hello retfie, can you please suggest to me how you do OTA with Openthread or you can provide some steps to follow( link or code)?

Thanks Nehal

HI Hehal, sorry for late response, but here is the essential change that you need on lwm2m-client re-based on current zephyr master branch:

https://github.com/retfie/zephyr/commit/3b9dd7281845c281106b2e85eca604f2665919a6

You need mcuboot bootloader on device and a working leshan server to register on. Then use 5/0/0 or 5/0/1 resource to send zephyr.signed.bin to lwm2m_client. Then look for status (5/0/3) to became 2 (ready to apply), then start update with Exec on /5/0/2.

nehalrohit

comment created time in 4 hours

PR opened RT-Thread/rt-thread

[kernel] rt_object_delete函数优化重置object->type

拉取/合并请求描述:(PR description)

[ object->type = 0; 改为 object->type = RT_Object_Class_Null; 一个东西,但是提高源码可读性

]

以下的内容不应该在提交PR时的message修改,修改下述message,PR会被直接关闭。请在提交PR后,浏览器查看PR并对以下检查项逐项check,没问题后逐条在页面上打钩。 The following content must not be changed in the submitted PR message. Otherwise, the PR will be closed immediately. After submitted PR, please use a web browser to visit PR, and check items one by one, and ticked them if no problem.

当前拉取/合并请求的状态 Intent for your PR

必须选择一项 Choose one (Mandatory):

  • [ ] 本拉取/合并请求是一个草稿版本 This PR is for a code-review and is intended to get feedback
  • [x] 本拉取/合并请求是一个成熟版本 This PR is mature, and ready to be integrated into the repo

代码质量 Code Quality:

我在这个拉取/合并请求中已经考虑了 As part of this pull request, I've considered the following:

  • [x] 已经仔细查看过代码改动的对比 Already check the difference between PR and old code
  • [x] 代码风格正确,包括缩进空格,命名及其他风格 Style guide is adhered to, including spacing, naming and other styles
  • [x] 没有垃圾代码,代码尽量精简,不包含#if 0代码,不包含已经被注释了的代码 All redundant code is removed and cleaned up
  • [x] 所有变更均有原因及合理的,并且不会影响到其他软件组件代码或BSP All modifications are justified and not affect other components or BSP
  • [x] 对难懂代码均提供对应的注释 I've commented appropriately where code is tricky
  • [x] 本拉取/合并请求代码是高质量的 Code in this PR is of high quality
+1 -1

0 comment

1 changed file

pr created time in 4 hours

Pull request review commentzephyrproject-rtos/zephyr

WIP: Various sanitycheck fixes and improvements..

 def info(what):         sys.stdout.write(what + "\n")         sys.stdout.flush() -    def update_counting(self):-        self.total_tests = len(self.instances)-        self.total_cases = 0-        self.total_skipped = 0-        self.total_skipped_cases = 0-        self.total_passed = 0+    def update_counting(self, results=None, initial=False):+        results.set_skipped(0)         for instance in self.instances.values():-            self.total_cases += len(instance.testcase.cases)+            if initial:+                results.increment_cases(len(instance.testcase.cases))             if instance.status == 'skipped':-                self.total_skipped += 1-                self.total_skipped_cases += len(instance.testcase.cases)+                results.increment_skipped()

done now.

nashif

comment created time in 4 hours

issue commentzephyrproject-rtos/zephyr

Device model: add debug helpers for when device_get_binding() fails

Yes, something is going to keep track of which devices are in demand, and ensure that they're ready to go before they're used: the device_if_ready() API description in #30196 is prepared for the possibility that you have to verify more than once. It's unclear how the runtime dependencies are going to be tracked.

mbolivar-nordic

comment created time in 4 hours

pull request commentzephyrproject-rtos/zephyr

device: refactor declare/define macros to support device definition and reference from devicetree nodes

Do we care about having a convention of using device_pm_control_nop vs NULL?

I don't know. ebe20f99c779fc351b84f38246d000290a8396ff added it for a reason, and I remember finding it useful to have it explicit in another situation (but not why, or whether that effort got anywhere). It'll all be reworked when we get moving on device power management anyway.

pabigot

comment created time in 4 hours

issue closedcontiki-ng/contiki-ng

Add support for MQTT v5

MQTT v5 is out: http://docs.oasis-open.org/mqtt/mqtt/v5.0/mqtt-v5.0.html

Adding support for v5 would be great. We currently support aspects of 3.1. We never added support for 3.1.1 (perhaps a good idea to do so, but not sure how much work it'd be).

closed time in 4 hours

g-oikonomou

issue commentcontiki-ng/contiki-ng

Add support for MQTT v5

#1250. Closing this.

g-oikonomou

comment created time in 4 hours

Pull request review commentzephyrproject-rtos/zephyr

device: refactor declare/define macros to support device definition and reference from devicetree nodes

 void main(void) 	bool led_is_on = true; 	int ret; -	dev = device_get_binding(LED0);+	dev = device_if_ready(DEVICE_DT_GET(CTLR_NODE));

Doesn't this break until we convert all the GPIO drivers over to DEVICE_DT_DEFINE?

Yes, though it's surprising only frdm_k64f fails CI.

I'm not sure whether to mark this DNM, hope somebody does a Changes Requested pending removal of the commit, or remove the commit now and deal with concerns about why there aren't examples when they arise.

pabigot

comment created time in 4 hours

Pull request review commentzephyrproject-rtos/zephyr

boards/arm: Adding Contextual Electronics Advanced BLE Cell board to Zephyr

+/*+ * Copyright (c) 2020 Analog Life LLC+ *+ * SPDX-License-Identifier: Apache-2.0+ */++/dts-v1/;+#include <nordic/nrf52840_qiaa.dtsi>++/ {+	model = "nRF52840 BLE Cell";+	compatible = "nordic,nrf52840-ble-cell";++	chosen {+		zephyr,console = &uart0;+		zephyr,shell-uart = &uart0;+		zephyr,sram = &sram0;+		zephyr,flash = &flash0;+		zephyr,code-partition = &slot0_partition;+	};+};++&gpiote {+	status = "okay";+};++&gpio0 {+	status = "okay";+};++&gpio1 {+	status = "okay";+};++&uart0 {+	compatible = "nordic,nrf-uart";+	status = "okay";+	current-speed = <115200>;++	tx-pin = <7>;+	rx-pin = <6>;+};++arduino_serial: &uart1 {+	status = "okay";+	current-speed = <115200>;++	/* UART Pin info. */+	rx-pin  = <20>;+	tx-pin  = <24>;+	rts-pin = <17>;+	cts-pin = <16>;++	/* Use hardware flow control. */+	hw-flow-control;++	/* BG9x description. */+	quectel_bg9x {+		compatible = "quectel,bg9x";+		label      = "quectel-bg9x";+		status     = "okay";++		mdm-power-gpios = <&gpio1 5  0>;+		mdm-reset-gpios = <&gpio1 6  0>;+		mdm-dtr-gpios   = <&gpio0 22 0>;+	};+};++arduino_i2c: &i2c0 {+	compatible = "nordic,nrf-twi";+	status = "okay";+	sda-pin = <27>;+	scl-pin = <26>;++	/* This I2C device is interfaced with the "BQ25895R" charger. */+};++&spi2 {+	compatible = "nordic,nrf-spi";+	status = "okay";+	sck-pin  = <19>;+	mosi-pin = <23>;+	miso-pin = <21>;++	/* This SPI device is interfaced with the SD card. */+};++&flash0 {+	/*+	 * For more information, see:+	 * https://docs.zephyrproject.org/latest/guides/dts/legacy-macros.html#legacy-flash-partitions

This page is removed. This comment can be removed.

bwasim

comment created time in 5 hours

push eventzephyrproject-rtos/zephyr

Kumar Gala

commit sha 52ad9a468c1a3ae9a00d1e5aac389c5bfcf087ec

ci: run_ci.sh: retry failed west update for PR builds We made a similar change for the nightly builds, but the PR builds invoke run_ci.sh, so we need the same change here. Signed-off-by: Kumar Gala <kumar.gala@linaro.org>

view details

push time in 5 hours

more