Date   

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@lists.zephyrproject.org> on behalf of Venkat Rao Vallapaneni <vallapaneni@socoptimum.com>
Date: Thursday, 25 October 2018 at 4:14 PM
To: "users@lists.zephyrproject.org" <users@lists.zephyrproject.org>
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@gmail.com>:


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@jgs-wg.de> 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@pathpartnertech.com 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@lists.zephyrproject.org> on behalf of Randy Chou <rchou3@logitech.com>
Date: Thursday, 1 November 2018 at 4:03 AM
To: "devel@lists.zephyrproject.org" <devel@lists.zephyrproject.org>
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 <rodrigopex@...>
 

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

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


Re: [Zephyr-tsc] [Zephyr-devel] Highlights from the TSC meeting during ELCE

Sigvart Hovland
 

[]

1. Development channel on IRC
2. I believe there is/was something like #zephyr-bluetooth on IRC
too. I never understood why, but I heard there was.
3. Slack channel.
4. Reddit subreddit
... more
Not sure if I get this, but I think you are suggesting we combine both
IRC and Slack. While I don't think that's the greatest of situations
to find ourselves in, I would have no problem using both (I already do
in fact). But then we'd need the devs to also frequent the Slack
channel, otherwise it'd be a bit pointless.
Right, and besides that "potentially pointless" situation (or more specifically, depending on the goodwill of developers), there 2 other
choices: don't change anything, let it work like it worked for decades, people who need will find their way on IRC. Or, forcibly move everyone elsewhere.
Isn't there a 3rd option which does require some more work than the other two other options and that is to have both slack and IRC while mirroring the channels from IRC to slack with an IRC-slack bridge[0](sort of like this but you could make it more advanced)? At least that's what we did when we migrated to slack on another project I worked on. That way devs don't have to frequent slack as it's optional but a nice addition.

One of the big pain points I've had with these bridges is however if the slack-IRC bot disconnects for some reason you'll lose history synchronisation between the sides, also there is maintenance and upkeep. So someone has to be responsible for making sure it's alive and kicking at least. Another problem I've faced is that the bridge does not support threading so if people start a discussion in a thread on slack, this will be lost on IRC. Maybe some newer bridges have support for this.

At least the problems I see with IRC at this point is that if you are not connected continuously (paying for web-based clients) or running on your own server, you'll lose history. This can be mitigated with an IRC bot where you could /msg history or public logs, but I don't see either in the project at the moment. Maybe I'm looking in the wrong place [1]?

I'm curious which route will be taken. But I'm sure that whichever will, it will be for the greater good of the project.
Anyway, while that was the more controversial point in Anas' email, I guess the most *important* is upcoming PR/patch process changes. So, I guess I'll wait for more info on that part from now on. (But I do hope that more people will cast their "votes" of IRC vs non-IRC matter yet.)
So I'll cast my "vote" right in the middle and ask for the consideration of having both with an integration in between them where you mirror the channels to slack(this way you could also see which channels are being used). I also think these kinds of bridges exists for gitter. This will also give new developers/users from a younger age group or those who are inexperienced with IRC a lower barrier of entry and maybe they'll eventually migrate over to IRC or visa versa.

[0] https://github.com/ekmartin/slack-irc
[1] https://freenode.irclog.whitequark.org/


Re: [Zephyr-tsc] [Zephyr-devel] Highlights from the TSC meeting during ELCE

Paul Sokolovsky
 

On Mon, 29 Oct 2018 22:08:55 +0000
"Cufi, Carles" <Carles.Cufi@nordicsemi.no> wrote:

Hi Paul,
[]

For what is worth, I (relatively) regularly comment and post on
Reddit about Zephyr. On r/embedded to be precise, but also on other
subreddits.
Great to know, you must be <...> then ;-) (Well, nick is skipped for
privacy reasons).

1. Development channel on IRC
2. I believe there is/was something like #zephyr-bluetooth on IRC
too. I never understood why, but I heard there was.
3. Slack channel.
4. Reddit subreddit
... more
Not sure if I get this, but I think you are suggesting we combine
both IRC and Slack. While I don't think that's the greatest of
situations to find ourselves in, I would have no problem using both
(I already do in fact). But then we'd need the devs to also frequent
the Slack channel, otherwise it'd be a bit pointless.
Right, and besides that "potentially pointless" situation (or more
specifically, depending on the goodwill of developers), there 2 other
choices: don't change anything, let it work like it worked for decades,
people who need will find their way on IRC. Or, forcibly move everyone
elsewhere.

I'm curious which route will be taken. But I'm sure that whichever
will, it will be for the greater good of the project.

Anyway, while that was the more controversial point in Anas' email, I
guess the most *important* is upcoming PR/patch process changes. So, I
guess I'll wait for more info on that part from now on. (But I do hope
that more people will cast their "votes" of IRC vs non-IRC matter yet.)


Carles


--
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: [Zephyr-tsc] [Zephyr-devel] Highlights from the TSC meeting during ELCE

Paul Sokolovsky
 

On Mon, 29 Oct 2018 21:58:22 +0000
Marti Bolivar <marti@foundries.io> wrote:

[]

Slack is a proprietary de facto standard in this context, at
least in the west.
Love that argument. So, perhaps we shouldn't look for easy ways and
embrace diversity in general, and look for WeChat that you
mentioned or QQ?
This sentence is hard to parse, but I suspect you (and Flavio) have
both missed my point, which was that if you're talking about
"everyone's" favorite chat clients by raw number of users, IRC
integration is basically non-existent. So claiming that as a plus
seems bogus.
I personally never talked about "favorite chat clients" or something. I
just calmly use mine, based on the projects' requirements, and those
requirements for last 10-15 years were consistent - IRC (so yes, I
had to acquire my favorite IRC client, etc.). Now requirements seem to
change, so I'm just trying to understand why, and make sure that if
change is made, no improvement opportunities are missed or hasty
decisions are made, like trading "east" for "west", etc.

[]

The more dissemination we have, the better. Just randomly searched
for "zephyr rtos" (no hope for just "zephyr") on Reddit, and
disappointedly, #1 hit is still the post for 1.9 release I made a
year ago. If we can't make semi-regular posts on popular IT crowd
sites like Reddit, let's at least create a Slack channel. Or can do
both actually. Or all of them:

1. Development channel on IRC
2. I believe there is/was something like #zephyr-bluetooth on IRC
too. I never understood why, but I heard there was.
3. Slack channel.
4. Reddit subreddit
... more
So "do all the things"?
Yes, and weekly summaries of Zephyr changes too. Why not?

For one, I hope there won't be external directives where to go,
especially represented as a "community decision". (Note that I
personally happy to follow any project requirements, especially if
it's clear where they originate from and what are their purpose.)

but I think we
ought to be honest with ourselves that this is really what we are
arguing about.

[]
Since you deleted most of the rest of the context in this thread so
far, I'm not sure what including the above followed by "[]" means.
That's easy: "[]" is a common placeholder for deleted text; there was
a complaint that quoting of the thread was broken, moreover I don't
think that every participant of such threads should comment every
point of other participants, a couple of important is enough, or
discussion get unwieldy. Finally, I really appreciate your call to be
honest with ourselves of what we're arguing about, so I tried to say in
fair manner what I think about these matters.


Thanks,
Marti
[]

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

3001 - 3020 of 8330