1. devel@lists.zephyrproject.org
  2. Messages
   Date   
Re: Using BLE IPSP with a Smartphone or Tablet as Host

Carles Cufi
 

Hi Häring,

 

I believe that neither Android nor iOS support IPSP, so this might not be possible at all.

That said I’ve copied a couple of people to this thread who might have more information.

 

Regards,

 

Carles

 

From: <devel@...> on behalf of "Häring Benjamin (haej)" <haej@...>
Date: Friday, 2 November 2018 at 14:27
To: "devel@..." <devel@...>
Subject: [Zephyr-devel] Using BLE IPSP with a Smartphone or Tablet as Host

 

Hello everyone

 

I would like to wirelessly connect some sensor nodes with IPv6 to a smartphone or tablet. I plan to use 6LoWPAN over BLE with the help of IPSP. I have already successfully put the IPSP sample project into operation and tested it. This is basically what I tried to accomplish. Now I want to replace the Linux host with a smartphone or tablet. For this procedure, I did some research on the internet and found this post in the Nordic Forum:

https://devzone.nordicsemi.com/f/nordic-q-a/25337/6lowpan-with-android-ios-mobile-devices

 

According to this thread, it is not possible to do this with an iOS or Android mobile device. However, this post is already older than 1 year. Nevertheless, I cannot find any further information on this topic.

 

Has anyone tried or implemented anything similar before? Does anyone have more information on this?

 

Regards

Benjamin
Re: Highlights from the TSC meeting during ELCE

Nashif, Anas
 

Rationale:

-          Slack offers the project more control (for example fighting spam)

-          Very good Integration with GitHub and other platforms we use (Shippable). We are trying a few apps that would make it easier for us to keep control of the number of PRs and almost replaces the need to receiving emails from GH

-          Feature-rich: We are a software project, not being able to share code snippets in a clean way is a major issue on IRC.

-          Offers permanent connection to everybody: Not everyone can afford a permanent connect to follow discussions that happened while they are asleep. Slack gives developer a way to keep up with discussions and conversations and makes it possible for everyone to connect with each other.

-          Many other Pros, google for slack vs irc, for example: https://www.slant.co/versus/4553/4557/~slack_vs_irc

-          It is 2018 J

 

If you want to try it go to https://tinyurl.com/y8eusuhs. Btw, this workspace has been active for almost 2 years now.

 

The TSC will have the final vote next week.

 

Anas

 

 

From: Perez-Gonzalez, Inaky
Sent: Monday, October 29, 2018 2:21 PM
To: Nashif, Anas <anas.nashif@...>; devel@...
Cc: tsc@...
Subject: RE: Highlights from the TSC meeting during ELCE

 

Thanks for the summary, Anas

 

>> 4.       We are considering a new communication platform to replace IRC. Candidates are Slack and gitter. This has not been decided yet, if you have any feedback, please let us know.

 

I'd like to ask what is the rationale behind IRC replacement, what is trying to be solved?

 

IRC is:

- easy to access for everyone from every platform

- well integrated into everyone's favourite messaging client

- does not depend on a single corporation (looking at you, Slack)

 
Re: [RFC] k_poll_signal name and MISRA

Flavio Ceolin
 

Hi,

Hello,

On Mon, 29 Oct 2018 08:48:46 +0100
"Erwan Gouriou" <erwan.gouriou@...> wrote:

Making different names is good, but then I think one should be able to
identify quickly which is struct and which isn't,
What about k_struct_poll_signal or k_poll_signal_struct ?
Well, that should be simple: a noun is a struct, so k_poll_signal
remains a structure. A subroutine which performs action should contain
a verb. To avoid tautology, it may be k_poll_signal_set(). Or perhaps,
signals are raised? Then k_poll_signal_raise().
Agree, other projects I've seen do this.


That's a basic idea which many projects follow, and which is mostly,
but not consistently, seems to be followed by Zephyr. As many other
things in Zephyr, such conventions would rather be formalized.
Yeah, we need to formalize it.


Flavio, one good way to approach questions like this is to do some
research/analysis and offer 3-4 alternative variants for people to
choose from (or base further alternatives on). Fairly speaking, I didn't
reply earlier in this thread, because I wanted to do such an analysis
myself, but as usual, it's backlogged by other tasks.
Yeah, I came up with something I used to see in EFL. Next time I'll
present more options. To be honest, I just raised this question thinking
that this had already been discussed but not applied.


A variant presented above is just a "low-hanging" one. We could go
further, e.g.

2. Challenge the name "signal", it may be confusing.
3. Challenge the "_poll" infix part of the name, that's again
confusing due to noun/verb ambiguity.

Thanks,
Paul


On Thu, 25 Oct 2018 at 22:07, Flavio Ceolin <flavio.ceolin@...>
wrote:

Hi guys,

MISRA-C rule 5.7 says that a tag name shall be a unique identifier,
also reuse tag names is an undefined behavior recognized in C99
(Section 6.7.2.3).

It happens that we have in Zephyr both a struct and a function
called k_poll_signal (there may be others cases in the project),
the question is, what it is preferable, change the function to
something like, k_pll_signal_signal() or change the struct nam ? In
the latter, what is the suggestion ? Remembering that I'll follow
this pattern if necessary.


Regards,
Flavio Ceolin






--
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
Regards,
Flavio Ceolin
Re: [Zephyr-users] BT840F EV mesh without crystal

Chettimada, Vinayak Kariappa
 

FYI: https://github.com/zephyrproject-rtos/zephyr/pull/11038

I have discovered a regression related to RCOSC non-blocking startup, please try the PR and comment as necessary in the PR.

- Vinayak

-----Original Message-----
From: <users@...> on behalf of Venkat Rao Vallapaneni <vallapaneni@...>
Date: Thursday, 25 October 2018 at 4:14 PM
To: "users@..." <users@...>
Subject: [Zephyr-users] BT840F EV mesh without crystal

Hi,
I have tried mesh on-off sample program on nRF52 DK with and without using crystal and it works fine. I am able to provision nRF52 DK using bluez.
When I try mesh program on Fanstel BT840F evaluation board with crystal, I am able to provision BT840F. But when I disable by crystal by adding these below lines to my prj.conf, I am not able to provision. I am able to see it as unprovisioned node which
means advertising is fine but not sure why provision fails. Any quick help/hint on debug is appreciated. BT840F is nrf52840 based and nrf52 DK is nrf52832 based. As RC is internal to SoC, I am not expecting any issues with DK or EV as they are working fine
with crystal. I am using nrf52840_pca10056 as board definition.

Is there anything wrong in configuration for nrf52840 as compared to nrf52832 in relation to crystal?


prj.conf:
CONFIG_CLOCK_CONTROL_NRF5_K32SRC_XTAL=n
CONFIG_CLOCK_CONTROL_NRF5_K32SRC_RC=y

Bluez meshctl log:
[meshctl]# discover-unprovisioned on
SetDiscoveryFilter success
Discovery started
Adapter property changed
[CHG] Controller 00:1A:7D:DA:71:13 Discovering: yes
Mesh Provisioning Service (00001827-0000-1000-8000-00805f9b34fb)
Device UUID: 9f05b4608cd600000000000000000000
OOB: 0000
Mesh Provisioning Service (00001827-0000-1000-8000-00805f9b34fb)
Device UUID: c911d60241cf00000000000000000000
OOB: 0000
[meshctl]# provision c911d60241cf00000000000000000000
Trying to connect Device CF:41:02:D6:11:C9 nRF52DK
Adapter property changed
[CHG] Controller 00:1A:7D:DA:71:13 Discovering: no
Failed to connect: org.bluez.Error.Failed
[meshctl]#


Thanks,
Venkat.
Using BLE IPSP with a Smartphone or Tablet as Host

Häring Benjamin (haej)
 

Hello everyone

 

I would like to wirelessly connect some sensor nodes with IPv6 to a smartphone or tablet. I plan to use 6LoWPAN over BLE with the help of IPSP. I have already successfully put the IPSP sample project into operation and tested it. This is basically what I tried to accomplish. Now I want to replace the Linux host with a smartphone or tablet. For this procedure, I did some research on the internet and found this post in the Nordic Forum:

https://devzone.nordicsemi.com/f/nordic-q-a/25337/6lowpan-with-android-ios-mobile-devices

 

According to this thread, it is not possible to do this with an iOS or Android mobile device. However, this post is already older than 1 year. Nevertheless, I cannot find any further information on this topic.

 

Has anyone tried or implemented anything similar before? Does anyone have more information on this?

 

Regards

Benjamin
Re: Communication between onoff-app Zephyr sample and light switch example of NRF52 Mesh SDK

Martin <ma@...>
 

Hi!
Thanks guys, Virkrant pointed me into the right direction. It seems as
if for the NRF52 Mesh SDK to process STATUS messages sent from
bt_mesh_model_publish(), it has to explicitly subscribe to a group
address to which the STATUS messages are published. And thanks Johan
for the clarification regarding _send and _publish. I think I've got
in now :)

Martin
Am Fr., 2. Nov. 2018 um 05:32 Uhr schrieb Vikrant More <vikrant8051@...>:


Hi,
In case of Board executing Nordic SDK (Client) , to accept published message by
NODE executing Zephyr(Server) should subscribe to address on which Server is publishing.


Do following configuration to received published message from Server:

In case of Server:
Subscribed it to 0xC000
& let it Publishing on 0xC00A

In case of Client:
Publish it on 0xC000
& Subscribed it on 0xC00A




On Fri, Nov 2, 2018 at 5:12 AM Martin <ma@...> wrote:

Hi,
While doing experiments with the OnOff samples provided, I stumbled
across a strange phenomenon:
There are two ways used to send STATUS messages in
samples\boards\nrf52\mesh\onoff-app: One is by using
bt_mesh_model_send (line 319 ff.), and the other one is by using
bt_mesh_model_publish (line 352 ff.). When I run Zephyr on both of my
boards, everything works fine. But when I run Zephyr on one of the
boards and install the light switch client example of NRF52 Mesh SDK
on the other, only STATUS messages that are sent by using
bt_mesh_model_send appear on the board powered by the NRF52 Mesh SDK.
I am kind of stuck here and wondering why I get these differring
results. Does anyone have an idea on what is the reason for it might
be (e.g. difference in behavior of _publish and _send)?

Thanks,
Martin
Re: lwip integration with OpenThread #nrf52840 #lwip #openthread

Paul Sokolovsky
 

Hello Deepa,

On Fri, 02 Nov 2018 00:17:52 -0700
deepa.gopinath@... wrote:

Hi all,

I have found that Zephyr;s code base Echo client & server Example
application can be built either on third paty lwip stack
Where did you find it? Do you have any links/etc.?

or else on
OpenThread stack based on config file. Do the Echo client & server
Example application which is built on OpenThread stack supports all
the features of OpenThread stack such as Mesh Network Formation,
Active Scan, To Join new node to the network etc., ?

Thanks in Advance!!

Regards,
Deepa
--
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: lwip integration with OpenThread #nrf52840 #lwip #openthread

deepa.gopinath@...
 

Hi all,

I have found that Zephyr;s code base Echo client & server Example application can be built either on third paty lwip stack or else on OpenThread stack based on config file.
Do the Echo client & server Example application which is built on OpenThread stack supports all the features of OpenThread stack such as Mesh Network Formation, Active Scan, To Join new node to the network etc., ?

Thanks in Advance!!

Regards,
Deepa
Re: Communication between onoff-app Zephyr sample and light switch example of NRF52 Mesh SDK

Johan Hedberg
 

Hi Martin,

On Fri, Nov 02, 2018, Martin wrote:
There are two ways used to send STATUS messages in
samples\boards\nrf52\mesh\onoff-app: One is by using
bt_mesh_model_send (line 319 ff.), and the other one is by using
bt_mesh_model_publish (line 352 ff.). When I run Zephyr on both of my
boards, everything works fine. But when I run Zephyr on one of the
boards and install the light switch client example of NRF52 Mesh SDK
on the other, only STATUS messages that are sent by using
bt_mesh_model_send appear on the board powered by the NRF52 Mesh SDK.
I am kind of stuck here and wondering why I get these differring
results. Does anyone have an idea on what is the reason for it might
be (e.g. difference in behavior of _publish and _send)?
The bt_mesh_model_publish() API depends on the model publication state.
So if that state hasn't been set correctly (e.g. the publish address)
then you wont get the results that you expect. The bt_mesh_model_send()
API on the other hand is more explicit and intended for any
non-publishing messaging (e.g. a server model's responses or client
model messages which aren't part of model publication).

Johan
Communication between onoff-app Zephyr sample and light switch example of NRF52 Mesh SDK

Martin <ma@...>
 

Hi,
While doing experiments with the OnOff samples provided, I stumbled
across a strange phenomenon:
There are two ways used to send STATUS messages in
samples\boards\nrf52\mesh\onoff-app: One is by using
bt_mesh_model_send (line 319 ff.), and the other one is by using
bt_mesh_model_publish (line 352 ff.). When I run Zephyr on both of my
boards, everything works fine. But when I run Zephyr on one of the
boards and install the light switch client example of NRF52 Mesh SDK
on the other, only STATUS messages that are sent by using
bt_mesh_model_send appear on the board powered by the NRF52 Mesh SDK.
I am kind of stuck here and wondering why I get these differring
results. Does anyone have an idea on what is the reason for it might
be (e.g. difference in behavior of _publish and _send)?

Thanks,
Martin
Re: #nrf52840 #ble unstable connection #nrf52840 #ble

Chettimada, Vinayak Kariappa
 

Hi Randy,

Could you please let us know the LF clock src used in your EVB?

If you are using 32KHz external crystal as source (CONFIG_CLOCK_CONTROL_NRF5_K32SRC_XTAL=y),
and the accuracy is not the default 20 ppm (CONFIG_CLOCK_CONTROL_NRF5_K32SRC_20PPM=y),
please select the correct one, i.e. if 250 ppm then CONFIG_CLOCK_CONTROL_NRF5_K32SRC_250PPM=y.

If you are using built-in 32KHz RC oscillator as source (CONFIG_CLOCK_CONTROL_NRF5_K32SRC_RC=y),
then please use CONFIG_CLOCK_CONTROL_NRF5_K32SRC_500PPM=y.

Do send us your application generated .config file, in case you want me to check what is configured in comparison to the source and actual accuracy of the clock source in your EVB.

Regards,
Vinayak

-----Original Message-----
From: <devel@...> on behalf of Randy Chou <rchou3@...>
Date: Thursday, 1 November 2018 at 4:03 AM
To: "devel@..." <devel@...>
Subject: [Zephyr-devel] #nrf52840 #ble unstable connection




Hi community,
I'm using nrf52840 on our own development board, I met one problem about abnormal disconnect.


* environment:

[Central] use BLE nRF connect run on nRF52840_PCA10056 (Windows)
[Peripheral 1] Zephyr peripheral_hids sample application runs on nRF52840_PCA10056
[Peripheral 2] Zephyr peripheral_hids sample application runs on our EVB (nRF52840)

* result:

[per 1] the connection keeps.
[per 2] abnormal disconnect while I move the central a bit far away from peripheral (< 1m).


* experiment


1. move the central device close next to peripheral 2. it can keeps connection.

2. change the connection interval from 30ms to 7.5ms/10ms/15ms, it can keeps connection

3. use our own FW which uses SoftDevice as Bluetooth stack. The distance won't affect the connection.


I'm wondering is this issue related to frequency drift.
As my understanding, in SoftDevice, it will do the clock calibration automatically.
I only find one related configuration (CONFIG_CLOCK_CONTROL_NRF5_K32SRC_250PPM).
Does it also have same feature in Zephyr?
or do you have other comment about this issue?

Thanks,
Randy
usb host

qianfan Zhao
 

Hi:
Is there has anyone who are developing usb host stack or has any plan about that?
#nrf52840 #ble unstable connection #nrf52840 #ble

Randy Chou <rchou3@...>
 

Hi community,
I'm using nrf52840 on our own development board, I met one problem about abnormal disconnect.

  • environment:
[Central] use BLE nRF connect run on nRF52840_PCA10056 (Windows)
[Peripheral 1] Zephyr peripheral_hids sample application runs on nRF52840_PCA10056
[Peripheral 2] Zephyr peripheral_hids sample application runs on our EVB (nRF52840)
  • result:
[per 1] the connection keeps.
[per 2] abnormal disconnect while I move the central a bit far away from peripheral (< 1m).

  • experiment
  1.  move the central device close next to peripheral 2. it can keeps connection.
  2. change the connection interval from 30ms to 7.5ms/10ms/15ms, it can keeps connection
  3. use our own FW which uses SoftDevice as Bluetooth stack. The distance won't affect the connection.
I'm wondering is this issue related to frequency drift.
As my understanding, in SoftDevice, it will do the clock calibration automatically.
I only find one related configuration (CONFIG_CLOCK_CONTROL_NRF5_K32SRC_250PPM).
Does it also have same feature in Zephyr? 
or do you have other comment about this issue?

Thanks,
Randy
Re: Zephyr Memory Heap Size

"K.I.R.A.
 

Hi Chintan,
I'm not sure we can do like that.
But you might define your customized mem pool, and take use of k_mem_alloc* instead.

Looking forward to more ideas!

Best Regards,
Bub

---Original---
From: " via Lists.Zephyrproject.Org"<meetcd=yahoo.com@...>
Date: Wed, Oct 31, 2018 21:43 PM
To: "devel@..."<devel@...>;"K.I.R.A."<38900484@...>;
Cc: "devel"<devel@...>;
Subject: Re: [Zephyr-devel] Zephyr Memory Heap Size


Hi Bub,

Thanks for reply.

My question is related to only HEAP MEM POOL and not GENERIC MEM POOL.

In other words can I have CONFIG_HEAP_MEM_POOL_SIZE greater than 16k bytes? My heap requirement to satisfy all k_malloc() is higher.

Regards,
Chintan

On Wednesday, October 31, 2018, 5:25:22 PM GMT+5:30, K.I.R.A. <38900484@...> wrote:


Hi Chintan,
It's a single maximum size block.
I'm wondering which scenario you need such big block.

Best Regards,
Bub

---Original---
From: " via Lists.Zephyrproject.Org"<meetcd=yahoo.com@...>
Date: Wed, Oct 31, 2018 18:04 PM
To: "devel@..."<devel@...>;
Cc: "devel"<devel@...>;
Subject: [Zephyr-devel] Zephyr Memory Heap Size

Hi Community,

As per Zephyr Documentation in this link.


The size of the heap memory pool is configurable. The following sizes are supported: 256 bytes, 1024 bytes, 4096 bytes, and 16384 bytes.

Does that mean we can not have heap size greater than 16384 bytes? Please clarify.

Regards,
Chintan
Re: Zephyr Memory Heap Size

Chintan Patel <meetcd@...>
 


Hi Bub,

Thanks for reply.

My question is related to only HEAP MEM POOL and not GENERIC MEM POOL.

In other words can I have CONFIG_HEAP_MEM_POOL_SIZE greater than 16k bytes? My heap requirement to satisfy all k_malloc() is higher.

Regards,
Chintan

On Wednesday, October 31, 2018, 5:25:22 PM GMT+5:30, K.I.R.A. <38900484@...> wrote:


Hi Chintan,
It's a single maximum size block.
I'm wondering which scenario you need such big block.

Best Regards,
Bub

---Original---
From: " via Lists.Zephyrproject.Org"<meetcd=yahoo.com@...>
Date: Wed, Oct 31, 2018 18:04 PM
To: "devel@..."<devel@...>;
Cc: "devel"<devel@...>;
Subject: [Zephyr-devel] Zephyr Memory Heap Size

Hi Community,

As per Zephyr Documentation in this link.


The size of the heap memory pool is configurable. The following sizes are supported: 256 bytes, 1024 bytes, 4096 bytes, and 16384 bytes.

Does that mean we can not have heap size greater than 16384 bytes? Please clarify.

Regards,
Chintan
Re: Zephyr Memory Heap Size

"K.I.R.A.
 

Hi Chintan,
It's a single maximum size block.
I'm wondering which scenario you need such big block.

Best Regards,
Bub

---Original---
From: " via Lists.Zephyrproject.Org"<meetcd=yahoo.com@...>
Date: Wed, Oct 31, 2018 18:04 PM
To: "devel@..."<devel@...>;
Cc: "devel"<devel@...>;
Subject: [Zephyr-devel] Zephyr Memory Heap Size

Hi Community,

As per Zephyr Documentation in this link.


The size of the heap memory pool is configurable. The following sizes are supported: 256 bytes, 1024 bytes, 4096 bytes, and 16384 bytes.

Does that mean we can not have heap size greater than 16384 bytes? Please clarify.

Regards,
Chintan
Re: I2C Driver nfrx_twi BUSY state #nrf52840

Rodrigo Peixoto
 

Why aren't you using the Zephyr i2c driver instead of nrfx?

On Tue, 30 Oct 2018 at 23:49 Rodrigo Peixoto <rodrigopex@...> wrote:
I would suggest you to use the mutex or even a semaphore to deal with the concurrent access to the driver. It seems to be the simple way in my point of view.

Indeed I guess the first "workaround" you suggest could be added to the driver. It would be better than return always an EIO.

Best regards,
Rodrigo Peixoto
On Tue, 30 Oct 2018 at 12:47 <aurelien.vouaillat@...> wrote:
Hi,

I'm currently using the i2c_nrfx_twi driver to process i2c transfers with some peripherals.
I have several slave units on the same i2c bus and use multi-threading to deal with all of them.

I have to face the problem that at least two threads have to use the i2c bus at the same time.
Unfortunately the i2c_nrfx_twi_transfer() function doesn't handle this issue and only returns
-EIO  even if the real problem comes from the busy state of the i2c bus:

nrfx_err_t res = nrfx_twi_xfer(&get_dev_config(dev)->twi,
                           &cur_xfer,
                           (msgs[i].flags & I2C_MSG_STOP) ?
                           0 : NRFX_TWI_FLAG_TX_NO_STOP);


        if (res != NRFX_SUCCESS) {
            LOG_ERR("Error nrfx_twi_xfer with %d", res);
            return -EIO;
        }

Easy workarounds was to :

1- Add another if case :
if (res != NRFX_ERROR_BUSY)
and return a -EBUSY

OR

2- Protect the function with a mutex and leaving the kernel handle this using the priority of each threads

I don't know if there are better/cleaner solution than these two ones but i would really appreciate some help

Thanks
Aurelien
--
Rodrigo Peixoto
Co-founder and Technical guru

+55 (82) 98144-8585
http://ayna.tech | Skype: rodrigopex

.

--
Rodrigo Peixoto
Co-founder and Technical guru

+55 (82) 98144-8585
http://ayna.tech | Skype: rodrigopex

.
Zephyr Memory Heap Size

Chintan Patel <meetcd@...>
 

Hi Community,

As per Zephyr Documentation in this link.


The size of the heap memory pool is configurable. The following sizes are supported: 256 bytes, 1024 bytes, 4096 bytes, and 16384 bytes.

Does that mean we can not have heap size greater than 16384 bytes? Please clarify.

Regards,
Chintan
Re: I2C Driver nfrx_twi BUSY state #nrf52840

Rodrigo Peixoto
 

I would suggest you to use the mutex or even a semaphore to deal with the concurrent access to the driver. It seems to be the simple way in my point of view.

Indeed I guess the first "workaround" you suggest could be added to the driver. It would be better than return always an EIO.

Best regards,
Rodrigo Peixoto

On Tue, 30 Oct 2018 at 12:47 <aurelien.vouaillat@...> wrote:
Hi,

I'm currently using the i2c_nrfx_twi driver to process i2c transfers with some peripherals.
I have several slave units on the same i2c bus and use multi-threading to deal with all of them.

I have to face the problem that at least two threads have to use the i2c bus at the same time.
Unfortunately the i2c_nrfx_twi_transfer() function doesn't handle this issue and only returns
-EIO  even if the real problem comes from the busy state of the i2c bus:

nrfx_err_t res = nrfx_twi_xfer(&get_dev_config(dev)->twi,
                           &cur_xfer,
                           (msgs[i].flags & I2C_MSG_STOP) ?
                           0 : NRFX_TWI_FLAG_TX_NO_STOP);


        if (res != NRFX_SUCCESS) {
            LOG_ERR("Error nrfx_twi_xfer with %d", res);
            return -EIO;
        }

Easy workarounds was to :

1- Add another if case :
if (res != NRFX_ERROR_BUSY)
and return a -EBUSY

OR

2- Protect the function with a mutex and leaving the kernel handle this using the priority of each threads

I don't know if there are better/cleaner solution than these two ones but i would really appreciate some help

Thanks
Aurelien

--
Rodrigo Peixoto
Co-founder and Technical guru

+55 (82) 98144-8585
http://ayna.tech | Skype: rodrigopex

.
I2C Driver nfrx_twi BUSY state #nrf52840

aurelien.vouaillat@...
 

Hi,

I'm currently using the i2c_nrfx_twi driver to process i2c transfers with some peripherals.
I have several slave units on the same i2c bus and use multi-threading to deal with all of them.

I have to face the problem that at least two threads have to use the i2c bus at the same time.
Unfortunately the i2c_nrfx_twi_transfer() function doesn't handle this issue and only returns
-EIO  even if the real problem comes from the busy state of the i2c bus:

nrfx_err_t res = nrfx_twi_xfer(&get_dev_config(dev)->twi,
                           &cur_xfer,
                           (msgs[i].flags & I2C_MSG_STOP) ?
                           0 : NRFX_TWI_FLAG_TX_NO_STOP);


        if (res != NRFX_SUCCESS) {
            LOG_ERR("Error nrfx_twi_xfer with %d", res);
            return -EIO;
        }

Easy workarounds was to :

1- Add another if case :
if (res != NRFX_ERROR_BUSY)
and return a -EBUSY

OR

2- Protect the function with a mutex and leaving the kernel handle this using the priority of each threads

I don't know if there are better/cleaner solution than these two ones but i would really appreciate some help

Thanks
Aurelien
3501 - 3520 of 8833