1. users@lists.zephyrproject.org
   Date   
Communication between native_posix board and external hardware via router

Lei Xu <lei.xu@...>
 

Hi everyone!


I'm trying to setup the communication between a native_posix board and a sensor. The sensor is connected to my router, and the native_posix program is running on my Linux host, which is also connected to the same router.


I have tried to setup a zeth interface using the provided net-tools. The configuration file used for setup zeth is as follows:

INTERFACE="$1"
HWADDR="00:00:5e:00:53:21"
IPV6_ADDR_1="2001:db8:2100::1"
IPV6_ROUTE_1="2001:db8:2100::/64"
IPV4_ADDR_1="192.168.1.104/24"
IPV4_ROUTE_1="192.168.1.0/24"
ip link set dev $INTERFACE up
ip link set dev $INTERFACE address $HWADDR
ip -6 address add $IPV6_ADDR_1 dev $INTERFACE nodad
ip -6 route add $IPV6_ROUTE_1 dev $INTERFACE
ip address add $IPV4_ADDR_1 dev $INTERFACE
ip route add $IPV4_ROUTE_1 dev $INTERFACE > /dev/null 2>&1


Correspondingly, the configurations in my native_posix project are as follows:

CONFIG_NET_CONFIG_MY_IPV4_ADDR="192.168.1.105"
CONFIG_NET_CONFIG_MY_IPV4_GW="192.168.1.1"
#CONFIG_ETH_NATIVE_POSIX_STARTUP_AUTOMATIC=y
CONFIG_ETH_NATIVE_POSIX_RANDOM_MAC=n
CONFIG_ETH_NATIVE_POSIX_MAC_ADDR="00:00:5e:00:53:22"
CONFIG_ETH_NATIVE_POSIX_DRV_NAME="zeth"

where "192.168.1.1" is the router's address.


After building and running the native_posix program, it can only communicate with the local host but cannot communicate with my sensors. May someone figure out what's the problem?


Best regards,

Lei
Scan and advertise on single channel - Bluetooth, Zephyr

edyta.bosacka@...
 

I would like to advertise and scan ONLY on one bluetooth channel (for example channel 37). Is there any way to do this in Zephyr? I tried to search parametr responsibles for it in this structure:
struct bt_le_scan_param scan_param = {
.type = BT_HCI_LE_SCAN_PASSIVE,
.options = BT_LE_SCAN_OPT_NONE,
.interval = 0x0010,
.window = 0x0010,}
but i dont think that this is solution.

I also found a file lll_chan in zephyrproject\zephyr\subsys\bluetooth\controller\ll_sw\nordic\lll. TI includes channel selection algorithms, but i dont see where can i select just one advertising channel?
Scan and advertise only on single bluetooth channel

Edyta Bosacka <edyta.bosacka@...>
 

Hi, Is it possible in Zephyr to advertise and scan through Bluetooth only on single channel ( for example channel37)? I found some file III_chan with channel selection algorithms and I wonder: do i need to change this file somehow or theere is some simple way to do this?
Re: [Zephyr-devel] SDK 0.11.4 Release

Wu, Wentong <wentong.wu@...>
 

Any plan to have 1.14 LTS branch upgrading SDK as master does? IMHO, we should do that because we claim it's LTS branch.

Thanks

-----Original Message-----
From: devel@lists.zephyrproject.org <devel@lists.zephyrproject.org> On Behalf Of Kumar Gala
Sent: Friday, June 26, 2020 10:46 AM
To: zephyr-users@lists.zephyrproject.org; zephyr-devel <zephyr-devel@lists.zephyrproject.org>; announce@lists.zephyrproject.org
Subject: [Zephyr-devel] SDK 0.11.4 Release

Hi,

Some minor fixes related to newlib and a packaging related fix for the individual arch toolchain packages (missing the cmake files)

The SDK can be found here:

https://github.com/zephyrproject-rtos/sdk-ng/releases/tag/v0.11.4

Please download and try things out and report any issues.

- General:
* Fixed issue with cmake files not being installed in arch specific
toolchan packages

- newlib:
* Fix setting of -DMISSING_SYSCALL_NAMES consistent on all builds
* Set march=pentium for 32-bit x86 build

- k
Re: [Zephyr-devel] Post 2.3.0 PR merging

Nashif, Anas
 

Hi,

 

Here some data…

 

What I have just posted on slack…

 

 

So, go do some reviews please 😊

 

 

Thanks

Anas

 

From: <devel@...> on behalf of Carles Cufi <carles.cufi@...>
Date: Tuesday, 7 July 2020 at 06:42
To: Simon Glass <sjg@...>
Cc: "devel@..." <devel@...>, "users@..." <users@...>
Subject: Re: [Zephyr-devel] Post 2.3.0 PR merging

 

Hi Simon,

 

Not to my knowledge, no. But perhaps Ioannis or Anas know if it’s also documented elsewhere. 

 

Regarding the “stamp of approval” that was mentioned earlier in the thread, I think we could adopt a middle ground. If the person with merge rights is reasonably knowledgeable about the area of the change, and understands the implications, their +1 could count even if they are not a maintainer. I feel that in many cases this could unblock PRs without compromising the quality of the code being merged. 

 

Carles 



Am 06.07.2020 um 22:20 schrieb Simon Glass <sjg@...>:

Hi Carles,

 

OK I see. Since you called out the 2-approver change as a cause of the bottleneck, I'm assuming there is data available on this.

 

I was looking around for discussion about the decision. The closest I found was here. Is there something else?

 

Regards,

SImon

 

 

On Mon, 6 Jul 2020 at 12:23, Cufi, Carles <Carles.Cufi@...> wrote:

Hi Simon,

 

A decision like that would need to go through the TSC, and in order to be able to vote we’d need to have clear stats on how many PRs are actually blocked by this policy. I was thinking about this recently, and given that those in Zephyr with merge rights can in fact add their +1 and they typically rely on a maintainer’s review to decide whether to merge a PR or not, this might not have as big as an impact as I originally thought.

 

That said, I believe we need a new GitHub filter to help us. Right now, we have one that lists PRs that are approved, passing CI and ready to merge, but what we need is one that shows all PRs that are partially approved (i.e. a single +1) and passing CI. Then those of us with merge rights could go over those regularly (like we do for the former) and, provided there’s a +1 from a maintainer, we could take one additional look at the PR, approve it and merge it.

 

I’d very much like to hear the opinion of others with merge rights in this thread.

 

Regards,

 

Carles

 

From: Simon Glass <sjg@...>
Sent: 06 July 2020 19:46
To: Cufi, Carles <Carles.Cufi@...>
Cc: devel@...; users@...
Subject: Re: [Zephyr-devel] Post 2.3.0 PR merging

 

Hi Carles,

 

On Fri, 12 Jun 2020 at 03:19, Carles Cufi <carles.cufi@...> wrote:

Hi all,

We currently have 170+ Pull Requests that pass CI but require one or more approvals in order to be merged, in part due to the fact that we have increased the minimum number of approvals required from 1 to 2.

 

Perhaps given the situation this should be reversed?

 

Regards,

Simon 

 


Help reviewing those PRs is greatly appreciated:

https://github.com/zephyrproject-rtos/zephyr/pulls?q=is%3Apr+is%3Aopen+base%3Amaster+review%3Arequired+status%3Asuccess+-label%3ADNM+draft%3Afalse

Thanks,

Carles
Re: [Zephyr-devel] Post 2.3.0 PR merging

Carles Cufi
 

Hi Simon,

Not to my knowledge, no. But perhaps Ioannis or Anas know if it’s also documented elsewhere. 

Regarding the “stamp of approval” that was mentioned earlier in the thread, I think we could adopt a middle ground. If the person with merge rights is reasonably knowledgeable about the area of the change, and understands the implications, their +1 could count even if they are not a maintainer. I feel that in many cases this could unblock PRs without compromising the quality of the code being merged. 

Carles 

Am 06.07.2020 um 22:20 schrieb Simon Glass <sjg@...>:


Hi Carles,

OK I see. Since you called out the 2-approver change as a cause of the bottleneck, I'm assuming there is data available on this.

I was looking around for discussion about the decision. The closest I found was here. Is there something else?

Regards,
SImon



On Mon, 6 Jul 2020 at 12:23, Cufi, Carles <Carles.Cufi@...> wrote:

Hi Simon,

 

A decision like that would need to go through the TSC, and in order to be able to vote we’d need to have clear stats on how many PRs are actually blocked by this policy. I was thinking about this recently, and given that those in Zephyr with merge rights can in fact add their +1 and they typically rely on a maintainer’s review to decide whether to merge a PR or not, this might not have as big as an impact as I originally thought.

 

That said, I believe we need a new GitHub filter to help us. Right now, we have one that lists PRs that are approved, passing CI and ready to merge, but what we need is one that shows all PRs that are partially approved (i.e. a single +1) and passing CI. Then those of us with merge rights could go over those regularly (like we do for the former) and, provided there’s a +1 from a maintainer, we could take one additional look at the PR, approve it and merge it.

 

I’d very much like to hear the opinion of others with merge rights in this thread.

 

Regards,

 

Carles

 

From: Simon Glass <sjg@...>
Sent: 06 July 2020 19:46
To: Cufi, Carles <Carles.Cufi@...>
Cc: devel@...; users@...
Subject: Re: [Zephyr-devel] Post 2.3.0 PR merging

 

Hi Carles,

 

On Fri, 12 Jun 2020 at 03:19, Carles Cufi <carles.cufi@...> wrote:

Hi all,

We currently have 170+ Pull Requests that pass CI but require one or more approvals in order to be merged, in part due to the fact that we have increased the minimum number of approvals required from 1 to 2.

 

Perhaps given the situation this should be reversed?

 

Regards,

Simon 

 


Help reviewing those PRs is greatly appreciated:

https://github.com/zephyrproject-rtos/zephyr/pulls?q=is%3Apr+is%3Aopen+base%3Amaster+review%3Arequired+status%3Asuccess+-label%3ADNM+draft%3Afalse

Thanks,

Carles
Re: [Zephyr-devel] Post 2.3.0 PR merging

Simon Glass <sjg@...>
 

Hi Carles,

OK I see. Since you called out the 2-approver change as a cause of the bottleneck, I'm assuming there is data available on this.

I was looking around for discussion about the decision. The closest I found was here. Is there something else?

Regards,
SImon



On Mon, 6 Jul 2020 at 12:23, Cufi, Carles <Carles.Cufi@...> wrote:

Hi Simon,

 

A decision like that would need to go through the TSC, and in order to be able to vote we’d need to have clear stats on how many PRs are actually blocked by this policy. I was thinking about this recently, and given that those in Zephyr with merge rights can in fact add their +1 and they typically rely on a maintainer’s review to decide whether to merge a PR or not, this might not have as big as an impact as I originally thought.

 

That said, I believe we need a new GitHub filter to help us. Right now, we have one that lists PRs that are approved, passing CI and ready to merge, but what we need is one that shows all PRs that are partially approved (i.e. a single +1) and passing CI. Then those of us with merge rights could go over those regularly (like we do for the former) and, provided there’s a +1 from a maintainer, we could take one additional look at the PR, approve it and merge it.

 

I’d very much like to hear the opinion of others with merge rights in this thread.

 

Regards,

 

Carles

 

From: Simon Glass <sjg@...>
Sent: 06 July 2020 19:46
To: Cufi, Carles <Carles.Cufi@...>
Cc: devel@...; users@...
Subject: Re: [Zephyr-devel] Post 2.3.0 PR merging

 

Hi Carles,

 

On Fri, 12 Jun 2020 at 03:19, Carles Cufi <carles.cufi@...> wrote:

Hi all,

We currently have 170+ Pull Requests that pass CI but require one or more approvals in order to be merged, in part due to the fact that we have increased the minimum number of approvals required from 1 to 2.

 

Perhaps given the situation this should be reversed?

 

Regards,

Simon 

 


Help reviewing those PRs is greatly appreciated:

https://github.com/zephyrproject-rtos/zephyr/pulls?q=is%3Apr+is%3Aopen+base%3Amaster+review%3Arequired+status%3Asuccess+-label%3ADNM+draft%3Afalse

Thanks,

Carles
Re: [Zephyr-devel] Post 2.3.0 PR merging

Nashif, Anas
 

Agreed. Those who can merge, should take 2 approvals and all other checks as a sign that it is ready to merge, no need for the approval of the person who merges, although a 3rd approval might give the PR a strong “Go”. This is actually what we agreed on 😊

 

Anas

 

 

From: <users@...> on behalf of Lawrence King <lawrence.king@...>
Date: Monday, 6 July 2020 at 15:41
To: Carles Cufi <carles.cufi@...>, Simon Glass <sjg@...>
Cc: "devel@..." <devel@...>, "users@..." <users@...>
Subject: Re: [Zephyr-users] [Zephyr-devel] Post 2.3.0 PR merging

 

Hi Charles:

 

This just my personal opinion on the subject. Two approvals is the right thing to do and what the TSC approved earlier this year.

 

BUT, if the second +1 is just a rubber stamp approval of the maintainer’s +1 then there is no point having two approvals.

 

The second +1 should come from someone who is: knowledgeable in the area, has studied the changes, and approves.

 

Lawrence King

Principal Developer

+1(416)627-7302

 

From: devel@... <devel@...> On Behalf Of Carles Cufi
Sent: Monday, July 6, 2020 2:23 PM
To: Simon Glass <sjg@...>
Cc: devel@...; users@...
Subject: Re: [Zephyr-devel] Post 2.3.0 PR merging

 

Hi Simon,

 

A decision like that would need to go through the TSC, and in order to be able to vote we’d need to have clear stats on how many PRs are actually blocked by this policy. I was thinking about this recently, and given that those in Zephyr with merge rights can in fact add their +1 and they typically rely on a maintainer’s review to decide whether to merge a PR or not, this might not have as big as an impact as I originally thought.

 

That said, I believe we need a new GitHub filter to help us. Right now, we have one that lists PRs that are approved, passing CI and ready to merge, but what we need is one that shows all PRs that are partially approved (i.e. a single +1) and passing CI. Then those of us with merge rights could go over those regularly (like we do for the former) and, provided there’s a +1 from a maintainer, we could take one additional look at the PR, approve it and merge it.

 

I’d very much like to hear the opinion of others with merge rights in this thread.

 

Regards,

 

Carles

 

From: Simon Glass <sjg@...>
Sent: 06 July 2020 19:46
To: Cufi, Carles <Carles.Cufi@...>
Cc: devel@...; users@...
Subject: Re: [Zephyr-devel] Post 2.3.0 PR merging

 

Hi Carles,

 

On Fri, 12 Jun 2020 at 03:19, Carles Cufi <carles.cufi@...> wrote:

Hi all,

We currently have 170+ Pull Requests that pass CI but require one or more approvals in order to be merged, in part due to the fact that we have increased the minimum number of approvals required from 1 to 2.

 

Perhaps given the situation this should be reversed?

 

Regards,

Simon 

 


Help reviewing those PRs is greatly appreciated:

https://github.com/zephyrproject-rtos/zephyr/pulls?q=is%3Apr+is%3Aopen+base%3Amaster+review%3Arequired+status%3Asuccess+-label%3ADNM+draft%3Afalse

Thanks,

Carles
Re: [Zephyr-devel] Post 2.3.0 PR merging

Lawrence King
 

Hi Charles:

 

This just my personal opinion on the subject. Two approvals is the right thing to do and what the TSC approved earlier this year.

 

BUT, if the second +1 is just a rubber stamp approval of the maintainer’s +1 then there is no point having two approvals.

 

The second +1 should come from someone who is: knowledgeable in the area, has studied the changes, and approves.

 

Lawrence King

Principal Developer

+1(416)627-7302

 

From: devel@... <devel@...> On Behalf Of Carles Cufi
Sent: Monday, July 6, 2020 2:23 PM
To: Simon Glass <sjg@...>
Cc: devel@...; users@...
Subject: Re: [Zephyr-devel] Post 2.3.0 PR merging

 

Hi Simon,

 

A decision like that would need to go through the TSC, and in order to be able to vote we’d need to have clear stats on how many PRs are actually blocked by this policy. I was thinking about this recently, and given that those in Zephyr with merge rights can in fact add their +1 and they typically rely on a maintainer’s review to decide whether to merge a PR or not, this might not have as big as an impact as I originally thought.

 

That said, I believe we need a new GitHub filter to help us. Right now, we have one that lists PRs that are approved, passing CI and ready to merge, but what we need is one that shows all PRs that are partially approved (i.e. a single +1) and passing CI. Then those of us with merge rights could go over those regularly (like we do for the former) and, provided there’s a +1 from a maintainer, we could take one additional look at the PR, approve it and merge it.

 

I’d very much like to hear the opinion of others with merge rights in this thread.

 

Regards,

 

Carles

 

From: Simon Glass <sjg@...>
Sent: 06 July 2020 19:46
To: Cufi, Carles <Carles.Cufi@...>
Cc: devel@...; users@...
Subject: Re: [Zephyr-devel] Post 2.3.0 PR merging

 

Hi Carles,

 

On Fri, 12 Jun 2020 at 03:19, Carles Cufi <carles.cufi@...> wrote:

Hi all,

We currently have 170+ Pull Requests that pass CI but require one or more approvals in order to be merged, in part due to the fact that we have increased the minimum number of approvals required from 1 to 2.

 

Perhaps given the situation this should be reversed?

 

Regards,

Simon 

 


Help reviewing those PRs is greatly appreciated:

https://github.com/zephyrproject-rtos/zephyr/pulls?q=is%3Apr+is%3Aopen+base%3Amaster+review%3Arequired+status%3Asuccess+-label%3ADNM+draft%3Afalse

Thanks,

Carles
Re: [Zephyr-devel] Post 2.3.0 PR merging

Carles Cufi
 

Hi Simon,

 

A decision like that would need to go through the TSC, and in order to be able to vote we’d need to have clear stats on how many PRs are actually blocked by this policy. I was thinking about this recently, and given that those in Zephyr with merge rights can in fact add their +1 and they typically rely on a maintainer’s review to decide whether to merge a PR or not, this might not have as big as an impact as I originally thought.

 

That said, I believe we need a new GitHub filter to help us. Right now, we have one that lists PRs that are approved, passing CI and ready to merge, but what we need is one that shows all PRs that are partially approved (i.e. a single +1) and passing CI. Then those of us with merge rights could go over those regularly (like we do for the former) and, provided there’s a +1 from a maintainer, we could take one additional look at the PR, approve it and merge it.

 

I’d very much like to hear the opinion of others with merge rights in this thread.

 

Regards,

 

Carles

 

From: Simon Glass <sjg@...>
Sent: 06 July 2020 19:46
To: Cufi, Carles <Carles.Cufi@...>
Cc: devel@...; users@...
Subject: Re: [Zephyr-devel] Post 2.3.0 PR merging

 

Hi Carles,

 

On Fri, 12 Jun 2020 at 03:19, Carles Cufi <carles.cufi@...> wrote:

Hi all,

We currently have 170+ Pull Requests that pass CI but require one or more approvals in order to be merged, in part due to the fact that we have increased the minimum number of approvals required from 1 to 2.

 

Perhaps given the situation this should be reversed?

 

Regards,

Simon 

 


Help reviewing those PRs is greatly appreciated:

https://github.com/zephyrproject-rtos/zephyr/pulls?q=is%3Apr+is%3Aopen+base%3Amaster+review%3Arequired+status%3Asuccess+-label%3ADNM+draft%3Afalse

Thanks,

Carles
Re: [Zephyr-devel] Post 2.3.0 PR merging

Simon Glass <sjg@...>
 

Hi Carles,

On Fri, 12 Jun 2020 at 03:19, Carles Cufi <carles.cufi@...> wrote:
Hi all,

We currently have 170+ Pull Requests that pass CI but require one or more approvals in order to be merged, in part due to the fact that we have increased the minimum number of approvals required from 1 to 2.

Perhaps given the situation this should be reversed?

Regards,
Simon 
 

Help reviewing those PRs is greatly appreciated:

https://github.com/zephyrproject-rtos/zephyr/pulls?q=is%3Apr+is%3Aopen+base%3Amaster+review%3Arequired+status%3Asuccess+-label%3ADNM+draft%3Afalse

Thanks,

Carles
test coverage

novello
 

In a x86_64 ubuntu 18.04

I have made this test :
/scripts/sanitycheck --all --enable-slow
and it work .

I have made those test and I get the result  and is fine.
sanitycheck --coverage -p native_posix -T tests/kernel

Those test. and thay work.
sanitycheck --device-testing --device-serial /dev/ttyACM0 -p frdm_k82f -T tests/kernel

I can't do this test.
sanitycheck --coverage --device-testing --device-serial /dev/ttyACM0 -p frdm_k82f  -T tests/kernel
May someone  help me ?
Best Regards
Novello G.
Re: HAL architecture

Noëlle Clement
 

{sent again because I forgot to also send it to the mailing list!} 

Thank you a lot both! 
Over the past few weeks I've unexpectedly had to work on some other part of the board port, so only now I'm starting on the low power management.

The good news is that by now I also have a bit better understanding of Zephyr and the power management, partially thanks to your advice! However, now that I've actually started on this part, I have many questions. I thought it would be more useful to ask through the mailing list, in case Francois is busy. The power management is crucial for our application, which is part of a prototype I'm developing for my Bachelor thesis, and I'm on a tight schedule haha. 

I have looked through the PR Erwan mentioned, regarding the low power support for the STM32L4, but there's still some parts that are raising questions. 

Some extra technical details:
- We use the STM32L151CC on our custom board. This board has already been ported by me (or at least the configuration part required for flashing and running the application).
- We need to use the stop mode with RTC
- During 'normal' operation the HSI is used, during the stop mode the LSE is used 
- If I understood correctly, currently the wake up is caused through a timed interrupt from the RTC 

Some of my questions are:
1. In this issue (https://github.com/zephyrproject-rtos/zephyr/issues/19755) only a few series part of the STM32 family are mentioned. Does this mean that low power management is already supported in Zephyr as-is for the other series (like the STM32L1xxx series), or just that they are not a priority or the like?
2. Why was it necessary to create a power.c file specifically for the STM32L4XXX? Is that always required for the STM32 SOCs, or was it only because the sleep modes didn't 'align' with the stop modes?
3. In the (modules/hal/stm32/stm32cube/stm32l1xx/drivers/include/) 'stm32l1xx_ll_pwr.h' file I can't find variables specifying specific stop modes, like in the 'stm32l4xx_ll_pwr.h' file. Why is this the case? How will I specify the specific stop mode if it's not in the HAL? 
4. Are there still things that need to be included / written in the application source, for the power management to work properly, with the way it was set up for the STM32L4xxx (creating the separate power.c file)?

There's a bit of overlap in these questions, as you may have noticed. I guess the main question is 'help, I'm not sure how to set up the power management', since I'm simultaneously learning about power management configuration and how this is done in Zephyr. But I tried to give more direction where I'm most confused haha.
  
Have a great day!

From: Erwan Gouriou <erwan.gouriou@...>
Sent: Thursday, June 4, 2020 5:06 PM
To: Cufi, Carles <Carles.Cufi@...>
Cc: Noëlle Clement <n.clement@...>; users@... <users@...>; Glaropoulos, Ioannis <Ioannis.Glaropoulos@...>; Francois RAMU <francois.ramu@...>
Subject: Re: HAL architecture
 
Additionally to Carles's answer, let me point you to an on going PR that aims at implementing lp modes on stm32:

It only supports L4/WB series for now, but you can contact François in CC if you have some questions to adapt this to your use case.

Cheers

On Thu, 4 Jun 2020 at 16:58, Cufi, Carles <Carles.Cufi@...> wrote:

Hi Noëlle,

 

Thanks for the kind words.

You can use CMSIS, which is built-in with Zephyr, for WFI.

 

Simply use:

 

__WFI();

 

in your C code.

 

The definition is here:

https://github.com/zephyrproject-rtos/cmsis/blob/master/CMSIS/Core/Include/cmsis_gcc.h#L909

 

That said, are you sure you  need to invoke the WFI instruction manually? this is automatically done by Zephyr when the core can be powered down, for example:

https://github.com/zephyrproject-rtos/zephyr/blob/master/arch/arm/core/aarch32/cpu_idle.S#L101

 

Thanks,

 

Carles

 

From: users@... <users@...> On Behalf Of Noëlle Clement via lists.zephyrproject.org
Sent: 04 June 2020 15:09
To: users@...
Subject: [Zephyr-users] HAL architecture

 

Hi everyone!

 

First of all: thanks specifically to Carles Cufi for taking the time a few months ago to give very detailed answers to my questions on whether Zephyr would be a right choice for our device. Partially because of this we're going with Zephyr for now - at least for the upcoming phase where I'm going to develop a prototype!

 

The first step for this prototype is making sure that the OS actually supports the low power mode we need to still meet our battery life requirements. Some context:

- We use the STM32L151CC MCU

- We need to be able to request the WFI (wait_for_interrupt) instruction (we use that one right now)

- In our current (bare-metal) code we use CMSIS +  a separate library (STM32 Standard Peripheral Library), of which the latter actually includes functions for requesting low power modes (including WFI)

 

I'm trying to figure out whether this specific instruction is already part of the HAL of Zephyr for the STM32Lxx MCU's. However, I'm kind of getting lost in the code, since the abstraction seems to be dispersed over multiple locations. I've looked into the documentation of course, but wasn't able to find an answer for my specific question. 

 

It would help me tremendously if someone could point me in the right direction or give a summary of the architecture, so I can check whether it's already supported or can start with implementing it myself.

 

Quick note that I'm relatively new to this, so if you need more information to understand my question or help me, I'm happy to provide it!

 

All the best,

Noelle 

 
How to write, compile and run in native_posix board with USB-CH341A converter #driver

honestech
 

Hello, everyone.
I am a beginner in zephyr RTOS. I want to make and run SPI driver with USB-CH341(SPI/I2C) programmer. I got the linux driver for it.
Here is a link.https://github.com/gschorcht/spi-ch341-usb
I have compiled and loaded this driver on Ubuntu 18.04 LTS. Then I can call this device like "/dev/spidev0.0".
I wrote the test code and tested, but I used the linux functions such as open, ioctl etc.

    ...
int spi = open("/dev/spidev0.1", O_RDWR);
    ...
ret = ioctl(spi, SPI_IOC_WR_MODE, &mode);
   ...

Now I want to make the driver for this device that can be used in zephyr native_posix board to test some SPI LCDs.
I have read the zephyrproject help and referenced its github samples. but I have got stuck. :-/

Could you tell me how to make, build and test?
I need much more help. I want to like this forum. :)

Thanks in advance.
Pengxiang
Re: device_get_binding() returns NULL #i2c #sensor

Jeremy Herbert
 

Have you tried to connect a logic analyser to your I2C pins to see if there are any transactions occurring?

Thanks,
Jeremy

On Sat, 27 Jun 2020 at 12:12, <straton.florin.c@...> wrote:

Hi,

I am trying to connect a BME280 sensor to NXP MiMX RT1020 and run samples/sensor/bme280 application but the output is always 

[00:00:00.000,000] <dbg> BME280.bme280_init: initializing BME280
[00:00:00.000,000] <dbg> BME280.bme280_chip_init: ID read failed: -5
[00:00:00.000,000] <dbg> BME280.bme280_init: BME280 failed
*** Booting Zephyr OS build v2.3.0-rc1-384-g8b5b7fcf8d84  ***
No device "BME280" found; did initialization fail?


the board overlay that i created is 

&lpi2c4 {
	bme280@76 {
		compatible = "bosch,bme280";
		reg = <0x76>;
		label = "BME280";
	};
};
i don't have any idea what could be wrong

clearly i'm a newbie not only with zephyr

 
device_get_binding() returns NULL #i2c #sensor

straton.florin.c@...
 

Hi,

I am trying to connect a BME280 sensor to NXP MiMX RT1020 and run samples/sensor/bme280 application but the output is always 

[00:00:00.000,000] <dbg> BME280.bme280_init: initializing BME280
[00:00:00.000,000] <dbg> BME280.bme280_chip_init: ID read failed: -5
[00:00:00.000,000] <dbg> BME280.bme280_init: BME280 failed
*** Booting Zephyr OS build v2.3.0-rc1-384-g8b5b7fcf8d84  ***
No device "BME280" found; did initialization fail?


the board overlay that i created is 

&lpi2c4 {
	bme280@76 {
		compatible = "bosch,bme280";
		reg = <0x76>;
		label = "BME280";
	};
};
i don't have any idea what could be wrong

clearly i'm a newbie not only with zephyr

 
CAn STM32F446VET6 micro usb , re-enumerated as mass storage or as camera interface?

ramuvsign@...
 

I have STM32F446VET6 devkit from https://www.96boards.org/product/stm32/.  Is it possible to use micro USB ie.,On-board ST-LINK debugger/programmer this USB by re-enumeration as mass storage?
If possible, please provide the sources.
SDK 0.11.4 Release

Kumar Gala
 

Hi,

Some minor fixes related to newlib and a packaging related fix for the individual arch toolchain packages (missing the cmake files)

The SDK can be found here:

https://github.com/zephyrproject-rtos/sdk-ng/releases/tag/v0.11.4

Please download and try things out and report any issues.

- General:
* Fixed issue with cmake files not being installed in arch specific
toolchan packages

- newlib:
* Fix setting of -DMISSING_SYSCALL_NAMES consistent on all builds
* Set march=pentium for 32-bit x86 build

- k
WINC1500 driver... #WINC1500

rdsingh@...
 

Is this driver a working/tested implementation? Or this is never debugged on real hardware?

It seems that currently it fails to work beyond reading the MAC address of the WINC1500 module. When stepped through with the help of Eclipse debugging extension, it seems to be failing at the point where SPI bulk write is performed.

Can someone who worked on this driver elaborate on this. Am I missing something obvious?

regards,
RDS
Re: [EXT] [Zephyr-users] Custom Ethernet driver and IPv4 #ipv4 #ethernet #networking

Andrei Gansari
 

Hello,

 

Have you added ETH_NET_DEVICE_INIT In your code?

Do you have CONFIG_NET_IPV4=y set in your application?

 

What sample are you using?

You can have a look at enc28j60 code, that is an SPI ethernet device as well.

 

From: users@... <users@...> On Behalf Of m.vermeulen via lists.zephyrproject.org
Sent: Wednesday, June 24, 2020 3:40 PM
To: users@...
Subject: [EXT] [Zephyr-users] Custom Ethernet driver and IPv4 #ipv4 #ethernet #networking

 

Caution: EXT Email

I am working to implement a driver for a SPI Ethernet controller.

The code is being called at initialization, but I am stuck at testing the driver. I would like to use the Net Shell, so net ping xxx.xxx.xxx.xxx for example. Unfortunately, I notice that the code fails in net_icmpv4_send_echo_request() when checking iface->config.ip.ipv4.

Do I need to take extra steps to use IPv4 over my custom ethernet driver, beside enabling the driver and net shell? I could image I would have to bind my ethernet interface to the network stack somewhere, but I haven't found exactly where.
381 - 400 of 2467