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.

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

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.

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?

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!

Thanks for pointing out, Will remove.

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

Fixed with new commit

Fixed by rebase

Rebased on top of develop

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.

Rebased over develop and addressed this.

Should be if(!i2c_acquire()) {

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

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.

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

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

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.

拉取/合并请求描述：(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

done now.

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.

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.

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

#1250. Closing this.

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.

This page is removed. This comment can be removed.