Date   

Re: Doing job of porting Zephyr to ARMV5-TE and ARMV7-A arch.

Nashif, Anas
 

Hi,

Thank you for your interest in Zephyr.

 

To submit your work upstream, you need to start by porting the changes to the latest status of the code and submit it against master.

Do this in multiple steps (commits) starting with the architecture related changes and additions, then with additional commits add the support for the platforms and board and any samples. Please avoid submitting everything you have as a single commit.

Please make sure you follow the coding style guidelines and use checkpatch to verify your changes before submission. You can cleanup the source files with uncrustify tool if needed, a configuration file for Zephyr exists under scripts/.

 

Follow the document http://docs.zephyrproject.org/contribute/contribute_guidelines.html for more details.

 

Thanks

Anas

 

 

From: zephyr-devel-bounces@... [mailto:zephyr-devel-bounces@...] On Behalf Of ???
Sent: Friday, November 17, 2017 10:28 PM
To: zephyr-devel@...
Subject: [Zephyr-devel] Doing job of porting Zephyr to ARMV5-TE and ARMV7-A arch.

 

Hi everyone:

 

     i am working on some project for porting Zephyr to armv5te(arm926ej-s) and ARMV7-A(A9) arch for some reason.  my job is based on the Zephyr 1.9.1 version and now it can do some traditional application demos, for example, DVB player and Media player, playing movies with zephyr sdk and other open source muti-media library.  and i want to see if i can merge my work(basically about the new arch support) to the mainline, and i dont know how to do this.

 

thanks for your advice.

 


 


Re: Regarding documentation of ble mesh developed under Zephyr project

Johan Hedberg
 

Hi Ashish,

Please try to keep the discussion on the mailing list. There are others
also trying to get things working with mesh, and they may benefit from
any information that's part of the discussion.

On Sun, Nov 19, 2017, ashish.shukla@... wrote:
There isn't much relevant information there. All, I could figure out was
that I can visit include files and find some information. I will try to
make use of that.
The sample code may be at least as helpful (if not more).

One more thing, is there going to an Android app for provisioning by
Zephyr? I tried to make use of Android app by SiLabs. After disabling OOB
security feature, this app successfully provisions the node, but the
configuration page doesn't open. Did you do some hacks to configure using
SiLabs app?
I'm not really familiar with the SiLabs app (I don't have an Android
phone) so I can't really help out with that. You might want to send
questions regarding it directly to SiLabs.

Another option for configuring Zephyr Mesh is meshctl from BlueZ. It's
GATT-only, just like the SiLabs app.

Another fairly new option is Zephyr's mesh shell support. I.e. you can
now send configuration model messages through the local network
interface to Zephyr itself. At the moment the support is part of the
Bluetooth shell app (tests/bluetooth/shell), but there's a pull request
that will move it to a dedicated tests/bluetooth/mesh_shell app:

https://github.com/zephyrproject-rtos/zephyr/pull/5046

Johan


Re: Regarding documentation of ble mesh developed under Zephyr project

Johan Hedberg
 

Hi Ashish,

On Sat, Nov 18, 2017, ashish.shukla@... wrote:
I'm working with ble mesh by Zypher. I was looking for documentation of the
code, I didn't find any documentations in detail about functions and
structures used in the code.
Would you guys please share some resources for the same.
There was another thread[0] on the same subject on this list a few days
ago. Hopefully you'll find some answers there.

https://lists.zephyrproject.org/pipermail/zephyr-devel/2017-November/008406.html

Johan


Re: Doing job of porting Zephyr to ARMV5-TE and ARMV7-A arch.

Carles Cufi
 

Hi there,

 

I am sure there would be interest for those arch ports among some of Zephyr’s users and contributors.

What I would recommend you do is you create 2 Pull Requests on GitHub (one for each arch) with a title that starts with “[RFC] [DNM]” (Request For Comments, Do Not Merge) with the basics of the port. There you will gather feedback from the community in order to refine the PRs and get them ready for merging in time.

 

I also recommend you read the contents of this page before you submit your PRs:

http://docs.zephyrproject.org/contribute/contribute_guidelines.html

 

Regards,

 

Carles

 

From: <zephyr-devel-bounces@...> on behalf of 曹子 <13824125580@...>
Date: Saturday, 18 November 2017 at 04:43
To: "zephyr-devel@..." <zephyr-devel@...>
Subject: [Zephyr-devel] Doing job of porting Zephyr to ARMV5-TE and ARMV7-A arch.

 

Hi everyone:

 

     i am working on some project for porting Zephyr to armv5te(arm926ej-s) and ARMV7-A(A9) arch for some reason.  my job is based on the Zephyr 1.9.1 version and now it can do some traditional application demos, for example, DVB player and Media player, playing movies with zephyr sdk and other open source muti-media library.  and i want to see if i can merge my work(basically about the new arch support) to the mainline, and i dont know how to do this.

 

thanks for your advice.





 


Regarding documentation of ble mesh developed under Zephyr project

ashish.shukla@corvi.com <ashish.shukla@...>
 

Dear all, 

I'm working with ble mesh by Zypher. I was looking for documentation of the code, I didn't find any documentations in detail about functions and structures used in the code. 
Would you guys please share some resources for the same. 

--
Warm regards,
Ashish Shukla
Jr. Embedded Engineer
Research & Development


Please consider the environment before printing this e-mail or its attachments.

Disclaimer: The information contained herein (including any accompanying documents) is confidential and is intended solely for the addressee(s). If you have erroneously received this message, please immediately delete it and notify the sender. Also, if you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution or taking any action in reliance on the contents of this message or any accompanying document is strictly prohibited and is unlawful. The organization is not responsible for any damage caused by a virus or alteration of the e-mail by a third party or otherwise. The contents of this message may not necessarily represent the views or policies of Corvi


Doing job of porting Zephyr to ARMV5-TE and ARMV7-A arch.

曹子龙
 

Hi everyone:

     i am working on some project for porting Zephyr to armv5te(arm926ej-s) and ARMV7-A(A9) arch for some reason.  my job is based on the Zephyr 1.9.1 version and now it can do some traditional application demos, for example, DVB player and Media player, playing movies with zephyr sdk and other open source muti-media library.  and i want to see if i can merge my work(basically about the new arch support) to the mainline, and i dont know how to do this.

thanks for your advice.



 


Re: New Defects reported by Coverity Scan for Zephyr

Leandro Pereira
 

Jammy,

On 11/16/2017 06:30 PM, Jammy Zhou wrote:
Is there some tool to do the scan locally?
Running Coverity locally requires a license; the Zephyr project has a free license that's kindly offered for open source projects, so there are some limitations as to the frequency of code scans. Since the scans are made periodically and the whole tree is compiled while capturing data for Coverity, it's better if just one person runs it.

There are alternatives to Coverity out there that might find the same bugs; some are even open source. Maybe it's possible to use Clang Static Analyzer and cppcheck.

Cheers,
Leandro


Re: accelerometer/gyroscope applications

Tamra Oyama <tamrako@...>
 

Hello Punit,

I can run the BMI160 and scan_adv samples separately. Basically, I am trying to combine the two so I can print both outputs, the xyz outputs and the scan_adv output (RSSI values and address). I think it's because the xyz values are written to a buffer?

Thank you,
Tamra


On Fri, Nov 17, 2017 at 4:27 AM, punit vara <punitvara@...> wrote:
Hi Tamra

I think Its not available at the moment. But you can use BMI160 which has both Accelerometer and gyroscope. You can get xyz from same sample app. 

Regards
PV

On Nov 17, 2017 10:10 AM, "Tamra Oyama" <tamrako@...> wrote:
Hello all,

I am trying to incorporate the accelerometer and gyroscope data into an application. I want to print the xyz values from the buffer of with other data outputs like rssi values in scan_adv so it would look like,

Device found: 1c:3d:94:52:70:b6 (random) (RSSI -79)
accel/gyroscope data

I can run each sample individually, but I cannot seem to mesh the two. Any ideas?

Thank you,
Tamrra

_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@...ct.org
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel



Re: What is the acceptable license for documentation files in Zephyr?

David Brown
 

On Fri, Nov 17, 2017 at 03:36:37PM +0000, Kinder, David B wrote:

Best though, would be to avoid inclusion of GPL content (docs or code) into the
Zephyr tree. The nice thing about content is you can write a short summary in
the Zephyr docs in your own words, and then include a link to the Linux
documents for more details, rather than directly including them. You could
also include short quotes and properly cite the source material with a link to
provide due credit to the authors.
Has anyone tried to figure out what the GPL even would mean for
documentation? Forming a derived work kind of makes sense, but what
about compiling and source code? Would including a chapter of GPL
documentation into a document under another license cause the rest of
the work to be a derived work?

There is a reason the FSF doesn't use the GPL for their documentation.

David


Re: Zephyr Based Bluetooth Mesh implementation on nRF52840-PDK boards

Kinder, David B <david.b.kinder@...>
 

Hmm... indeed something is amiss with generation of the mesh API documentation.
I'm heading out for Thanksgiving vacation, so for now, indeed the header files should be consulted. I'll submit a github issue and look into this more when I return, unless someone else wants to look into this before then.

-- david

-----Original Message-----
From: Johan Hedberg [mailto:johan.hedberg@...]
Sent: Thursday, November 16, 2017 11:43 PM
To: Kinder, David B <david.b.kinder@...>
Cc: Vikrant More <vikrant8051@...>; zephyr-
users@...; zephyr-devel@...
Subject: Re: [Zephyr-devel] Zephyr Based Bluetooth Mesh implementation
on nRF52840-PDK boards

Hi David,

On Fri, Nov 17, 2017, Kinder, David B wrote:
The documents from the master branch (including the doxygen API
material) are published nightly to
docs.zephyrproject.org<http://docs.zephyrproject.org>
Thanks, I suppose the right place should then be:

http://docs.zephyrproject.org/api/bluetooth.html#mesh-profile

However, that seems to be broken/incomplete at the moment, since it only
lists the doxygen group bt_mesh but doesn't provide any links to its
subgroups (there are many of them). If I tracked this down right the page
gets generated from doc/api/bluetooth.rst, so that likely needs fixing.
Meanwhile, it seems the best source for Mesh documentation right now is to
look at the header files directly.

Johan


Re: What is the acceptable license for documentation files in Zephyr?

Kinder, David B <david.b.kinder@...>
 

Hi Bobby,

 

There is a process documented here for how to get non Apache-2.0 material into the Zephyr tree. 

 

Best though, would be to avoid inclusion of GPL content (docs or code) into the Zephyr tree.  The nice thing about content is you can write a short summary in the Zephyr docs in your own words, and then include a link to the Linux documents for more details, rather than directly including them.  You could also include short quotes and properly cite the source material with a link to provide due credit to the authors.

 

-- david

 

 

From: zephyr-devel-bounces@... [mailto:zephyr-devel-bounces@...] On Behalf Of b0661
Sent: Friday, November 17, 2017 5:52 AM
To: zephyr-devel@...
Subject: [Zephyr-devel] What is the acceptable license for documentation files in Zephyr?

 

Hello,

I wan´t to partly re-use doumentation from Linux for Zephyr documentation (rst files not source files). Linux documentation is (presumably) GPLv2.

The documentation file header might become:

..
    Copyright (c) 2017 Linux
    Copyright (c) 2017 ...
    SPDX-License-Identifier: GPL-2.0

Is it possible to include such GPLv2 documentation in Zephyr?

Thanks

Bobby


Re: accelerometer/gyroscope applications

punit vara <punitvara@...>
 

Hi Tamra

I think Its not available at the moment. But you can use BMI160 which has both Accelerometer and gyroscope. You can get xyz from same sample app. 

Regards
PV

On Nov 17, 2017 10:10 AM, "Tamra Oyama" <tamrako@...> wrote:
Hello all,

I am trying to incorporate the accelerometer and gyroscope data into an application. I want to print the xyz values from the buffer of with other data outputs like rssi values in scan_adv so it would look like,

Device found: 1c:3d:94:52:70:b6 (random) (RSSI -79)
accel/gyroscope data

I can run each sample individually, but I cannot seem to mesh the two. Any ideas?

Thank you,
Tamrra

_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@lists.zephyrproject.org
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel


What is the acceptable license for documentation files in Zephyr?

Bobby
 

Hello,

I wan´t to partly re-use doumentation from Linux for Zephyr documentation (rst files not source files). Linux documentation is (presumably) GPLv2.

The documentation file header might become:

..
    Copyright (c) 2017 Linux
    Copyright (c) 2017 ...
    SPDX-License-Identifier: GPL-2.0

Is it possible to include such GPLv2 documentation in Zephyr?

Thanks
Bobby


Resources for ble mesh development

ashish.shukla@corvi.com <ashish.shukla@...>
 


Hi all, 

I find very less documentation for ble mesh developed under Zephyr project. Can you please suggest links and resources for detailed documentation of the mesh implementation. 
--
Warm regards,
Ashish Shukla
Jr. Embedded Engineer
Research & Development


Please consider the environment before printing this e-mail or its attachments.

Disclaimer: The information contained herein (including any accompanying documents) is confidential and is intended solely for the addressee(s). If you have erroneously received this message, please immediately delete it and notify the sender. Also, if you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution or taking any action in reliance on the contents of this message or any accompanying document is strictly prohibited and is unlawful. The organization is not responsible for any damage caused by a virus or alteration of the e-mail by a third party or otherwise. The contents of this message may not necessarily represent the views or policies of Corvi


Re: NRF5x I2C driver and the sensor/th02 example

Arthur Mühlbeier <arthur.muehlbeier@...>
 

Hello Andrzej,

thank you for the informative reply. You are totally right. I am getting the answers. I was using printk wrong
printk("T:%.1f%cC\n",   sensor_value_to_double(val),  223);
I changed it to first create a string and then print the string.
char myTemperature[16];
sprintf(myTemperature, "T:%.1f%cC", sensor_value_to_double(val), 223 /* degree symbol */);
printk("%s\n", myTemperature);

Now it is working. Also I overlooked that I was sleeping with the Raspi for 500 ms after I triggered the measurement and with the Zephyr Node I tried to get the measurement instantly. That is why it was polled and the logic analyzer output was different.
Thank you very much. I was unable to see the wood for the trees.

Have a nice day and best regards,
Arthur

On 17.11.2017 11:52, Głąbek, Andrzej wrote:

Hi Arthur,

 

There is nothing wrong in the sequence you presented. Raspberry PI just does the communication a bit differently:

  • 1.055657625000000,I2C,Setup Write to ['128'] + ACK
  • 1.055747625000000,I2C,'3' + ACK
  • 1.055837625000000,I2C,'17' + ACK

It waits 500 ms here. And reads 3 registers - STATUS (0 -> the result is ready), DATAh, DATAl - in a row:

  • 1.558392000000000,I2C,Setup Write to ['128'] + ACK
  • 1.558482000000000,I2C,'0' + ACK
  • 1.558650875000000,I2C,Setup Read to ['129'] + ACK
  • 1.558740875000000,I2C,'0' + ACK
  • 1.558830875000000,I2C,$ + ACK
  • 1.558920875000000,I2C,'140' + NAK

Now the driver from Zephyr:

  • 1.631275625000000,I2C,Setup Write to ['128'] + ACK
  • 1.631315375000000,I2C,'3' + ACK
  • 1.631363125000000,I2C,'17' + ACK
  • 1.631439375000000,I2C,Setup Write to ['128'] + ACK
  • 1.631479125000000,I2C,'0' + ACK
  • 1.631538750000000,I2C,Setup Read to ['129'] + ACK
  • 1.631574625000000,I2C,'1' + NAK

There was no waiting so the /RDY bit in the STATUS register is 1 (result not ready). It is then polled a couple of times:

  • 1.631641000000000,I2C,Setup Write to ['128'] + ACK
  • 1.631680750000000,I2C,'0' + ACK
  • 1.631740375000000,I2C,Setup Read to ['129'] + ACK
  • 1.631776125000000,I2C,'1' + NAK
  • 1.631842500000000,I2C,Setup Write to ['128'] + ACK
  • 1.631882375000000,I2C,'0' + ACK
  • 1.631942000000000,I2C,Setup Read to ['129'] + ACK
  • 1.631977750000000,I2C,'1' + NAK
  • ...
  • 1.763528625000000,I2C,Setup Write to ['128'] + ACK
  • 1.763568375000000,I2C,'0' + ACK
  • 1.763628000000000,I2C,Setup Read to ['129'] + ACK
  • 1.763663750000000,I2C,'0' + NAK

And here the /RDY bit is finally 0, so the result can be read. But it is done here in two “read register” transactions, for DATAh and DATAl separately (and perhaps this could be improved).

  • 1.763730250000000,I2C,Setup Write to ['128'] + ACK
  • 1.763770000000000,I2C,'1' + ACK
  • 1.763829625000000,I2C,Setup Read to ['129'] + ACK
  • 1.763865375000000,I2C,M + NAK
  • 1.763931625000000,I2C,Setup Write to ['128'] + ACK
  • 1.763971250000000,I2C,'2' + ACK
  • 1.764030875000000,I2C,Setup Read to ['129'] + ACK
  • 1.764066625000000,I2C,'160' + NAK

 

Could you then describe what is actually not working for you?

 

Best regards,

Andrzej

 

 

From: zephyr-devel-bounces@... [mailto:zephyr-devel-bounces@...] On Behalf Of Arthur Mühlbeier
Sent: Thursday, November 16, 2017 5:07 PM
To: zephyr-devel@...
Subject: [Zephyr-devel] NRF5x I2C driver and the sensor/th02 example

 

Hello,

I am trying to get running the example sensor/th02 with the nrf52_pca10040 or nrf51_pca10028. I disbaled the Grove LCD display in menuconfig. I configured the I2C drivers like
https://imgur.com/Q6bh1XJ
I set the priority to 8 and tried also other values. I tried also different pins. This is what I get from the logic analyzer with both boards and different pins.
Time [s], Analyzer Name, Decoded Protocol Result

  • 1.631275625000000,I2C,Setup Write to ['128'] + ACK
  • 1.631315375000000,I2C,'3' + ACK
  • 1.631363125000000,I2C,'17' + ACK
  • 1.631439375000000,I2C,Setup Write to ['128'] + ACK
  • 1.631479125000000,I2C,'0' + ACK
  • 1.631538750000000,I2C,Setup Read to ['129'] + ACK
  • 1.631574625000000,I2C,'1' + NAK
  • 1.631641000000000,I2C,Setup Write to ['128'] + ACK
  • 1.631680750000000,I2C,'0' + ACK
  • 1.631740375000000,I2C,Setup Read to ['129'] + ACK
  • 1.631776125000000,I2C,'1' + NAK
  • 1.631842500000000,I2C,Setup Write to ['128'] + ACK
  • 1.631882375000000,I2C,'0' + ACK
  • 1.631942000000000,I2C,Setup Read to ['129'] + ACK
  • 1.631977750000000,I2C,'1' + NAK
  • ...
  • 1.763528625000000,I2C,Setup Write to ['128'] + ACK
  • 1.763568375000000,I2C,'0' + ACK
  • 1.763628000000000,I2C,Setup Read to ['129'] + ACK
  • 1.763663750000000,I2C,'0' + NAK
  • 1.763730250000000,I2C,Setup Write to ['128'] + ACK
  • 1.763770000000000,I2C,'1' + ACK
  • 1.763829625000000,I2C,Setup Read to ['129'] + ACK
  • 1.763865375000000,I2C,M + NAK
  • 1.763931625000000,I2C,Setup Write to ['128'] + ACK
  • 1.763971250000000,I2C,'2' + ACK
  • 1.764030875000000,I2C,Setup Read to ['129'] + ACK
  • 1.764066625000000,I2C,'160' + NAK


So it seems that there is some working I2C functionality. But it seems to not working after the read command.
I tried the sensor with the Raspberry PI to find out what the expected output is and whether the sensor is working.
Raspi Log:

  • Time [s], Analyzer Name, Decoded Protocol Result
  • 1.055657625000000,I2C,Setup Write to ['128'] + ACK
  • 1.055747625000000,I2C,'3' + ACK
  • 1.055837625000000,I2C,'17' + ACK
  • 1.558392000000000,I2C,Setup Write to ['128'] + ACK
  • 1.558482000000000,I2C,'0' + ACK
  • 1.558650875000000,I2C,Setup Read to ['129'] + ACK
  • 1.558740875000000,I2C,'0' + ACK
  • 1.558830875000000,I2C,$ + ACK
  • 1.558920875000000,I2C,'140' + NAK

I have already asked for help in the IRC channel. I know that the "wrong" sequence is received after

if (offset == 0) {
      SYS_LOG_DBG("STARTRX");
      twi->TASKS_STARTRX = 1;
} in i2c_nrf5.c     function i2c_nrf5_read

Am I miconfiguring the I2C driver or is there a bug with the driver. Any help would be greatly appreciated. Thank you and have a nice day.

Arthur

 



Re: NRF5x I2C driver and the sensor/th02 example

Andrzej G??bek
 

Hi Arthur,

 

There is nothing wrong in the sequence you presented. Raspberry PI just does the communication a bit differently:

  • 1.055657625000000,I2C,Setup Write to ['128'] + ACK
  • 1.055747625000000,I2C,'3' + ACK
  • 1.055837625000000,I2C,'17' + ACK

It waits 500 ms here. And reads 3 registers - STATUS (0 -> the result is ready), DATAh, DATAl - in a row:

  • 1.558392000000000,I2C,Setup Write to ['128'] + ACK
  • 1.558482000000000,I2C,'0' + ACK
  • 1.558650875000000,I2C,Setup Read to ['129'] + ACK
  • 1.558740875000000,I2C,'0' + ACK
  • 1.558830875000000,I2C,$ + ACK
  • 1.558920875000000,I2C,'140' + NAK

Now the driver from Zephyr:

  • 1.631275625000000,I2C,Setup Write to ['128'] + ACK
  • 1.631315375000000,I2C,'3' + ACK
  • 1.631363125000000,I2C,'17' + ACK
  • 1.631439375000000,I2C,Setup Write to ['128'] + ACK
  • 1.631479125000000,I2C,'0' + ACK
  • 1.631538750000000,I2C,Setup Read to ['129'] + ACK
  • 1.631574625000000,I2C,'1' + NAK

There was no waiting so the /RDY bit in the STATUS register is 1 (result not ready). It is then polled a couple of times:

  • 1.631641000000000,I2C,Setup Write to ['128'] + ACK
  • 1.631680750000000,I2C,'0' + ACK
  • 1.631740375000000,I2C,Setup Read to ['129'] + ACK
  • 1.631776125000000,I2C,'1' + NAK
  • 1.631842500000000,I2C,Setup Write to ['128'] + ACK
  • 1.631882375000000,I2C,'0' + ACK
  • 1.631942000000000,I2C,Setup Read to ['129'] + ACK
  • 1.631977750000000,I2C,'1' + NAK
  • ...
  • 1.763528625000000,I2C,Setup Write to ['128'] + ACK
  • 1.763568375000000,I2C,'0' + ACK
  • 1.763628000000000,I2C,Setup Read to ['129'] + ACK
  • 1.763663750000000,I2C,'0' + NAK

And here the /RDY bit is finally 0, so the result can be read. But it is done here in two “read register” transactions, for DATAh and DATAl separately (and perhaps this could be improved).

  • 1.763730250000000,I2C,Setup Write to ['128'] + ACK
  • 1.763770000000000,I2C,'1' + ACK
  • 1.763829625000000,I2C,Setup Read to ['129'] + ACK
  • 1.763865375000000,I2C,M + NAK
  • 1.763931625000000,I2C,Setup Write to ['128'] + ACK
  • 1.763971250000000,I2C,'2' + ACK
  • 1.764030875000000,I2C,Setup Read to ['129'] + ACK
  • 1.764066625000000,I2C,'160' + NAK

 

Could you then describe what is actually not working for you?

 

Best regards,

Andrzej

 

 

From: zephyr-devel-bounces@... [mailto:zephyr-devel-bounces@...] On Behalf Of Arthur Mühlbeier
Sent: Thursday, November 16, 2017 5:07 PM
To: zephyr-devel@...
Subject: [Zephyr-devel] NRF5x I2C driver and the sensor/th02 example

 

Hello,

I am trying to get running the example sensor/th02 with the nrf52_pca10040 or nrf51_pca10028. I disbaled the Grove LCD display in menuconfig. I configured the I2C drivers like
https://imgur.com/Q6bh1XJ
I set the priority to 8 and tried also other values. I tried also different pins. This is what I get from the logic analyzer with both boards and different pins.
Time [s], Analyzer Name, Decoded Protocol Result

  • 1.631275625000000,I2C,Setup Write to ['128'] + ACK
  • 1.631315375000000,I2C,'3' + ACK
  • 1.631363125000000,I2C,'17' + ACK
  • 1.631439375000000,I2C,Setup Write to ['128'] + ACK
  • 1.631479125000000,I2C,'0' + ACK
  • 1.631538750000000,I2C,Setup Read to ['129'] + ACK
  • 1.631574625000000,I2C,'1' + NAK
  • 1.631641000000000,I2C,Setup Write to ['128'] + ACK
  • 1.631680750000000,I2C,'0' + ACK
  • 1.631740375000000,I2C,Setup Read to ['129'] + ACK
  • 1.631776125000000,I2C,'1' + NAK
  • 1.631842500000000,I2C,Setup Write to ['128'] + ACK
  • 1.631882375000000,I2C,'0' + ACK
  • 1.631942000000000,I2C,Setup Read to ['129'] + ACK
  • 1.631977750000000,I2C,'1' + NAK
  • ...
  • 1.763528625000000,I2C,Setup Write to ['128'] + ACK
  • 1.763568375000000,I2C,'0' + ACK
  • 1.763628000000000,I2C,Setup Read to ['129'] + ACK
  • 1.763663750000000,I2C,'0' + NAK
  • 1.763730250000000,I2C,Setup Write to ['128'] + ACK
  • 1.763770000000000,I2C,'1' + ACK
  • 1.763829625000000,I2C,Setup Read to ['129'] + ACK
  • 1.763865375000000,I2C,M + NAK
  • 1.763931625000000,I2C,Setup Write to ['128'] + ACK
  • 1.763971250000000,I2C,'2' + ACK
  • 1.764030875000000,I2C,Setup Read to ['129'] + ACK
  • 1.764066625000000,I2C,'160' + NAK


So it seems that there is some working I2C functionality. But it seems to not working after the read command.
I tried the sensor with the Raspberry PI to find out what the expected output is and whether the sensor is working.
Raspi Log:

  • Time [s], Analyzer Name, Decoded Protocol Result
  • 1.055657625000000,I2C,Setup Write to ['128'] + ACK
  • 1.055747625000000,I2C,'3' + ACK
  • 1.055837625000000,I2C,'17' + ACK
  • 1.558392000000000,I2C,Setup Write to ['128'] + ACK
  • 1.558482000000000,I2C,'0' + ACK
  • 1.558650875000000,I2C,Setup Read to ['129'] + ACK
  • 1.558740875000000,I2C,'0' + ACK
  • 1.558830875000000,I2C,$ + ACK
  • 1.558920875000000,I2C,'140' + NAK

I have already asked for help in the IRC channel. I know that the "wrong" sequence is received after

if (offset == 0) {
      SYS_LOG_DBG("STARTRX");
      twi->TASKS_STARTRX = 1;
} in i2c_nrf5.c     function i2c_nrf5_read

Am I miconfiguring the I2C driver or is there a bug with the driver. Any help would be greatly appreciated. Thank you and have a nice day.

Arthur

 


Re: Zephyr Based Bluetooth Mesh implementation on nRF52840-PDK boards

Johan Hedberg
 

Hi David,

On Fri, Nov 17, 2017, Kinder, David B wrote:
The documents from the master branch (including the doxygen API
material) are published nightly to
docs.zephyrproject.org<http://docs.zephyrproject.org>
Thanks, I suppose the right place should then be:

http://docs.zephyrproject.org/api/bluetooth.html#mesh-profile

However, that seems to be broken/incomplete at the moment, since it only
lists the doxygen group bt_mesh but doesn't provide any links to its
subgroups (there are many of them). If I tracked this down right the
page gets generated from doc/api/bluetooth.rst, so that likely needs
fixing. Meanwhile, it seems the best source for Mesh documentation right
now is to look at the header files directly.

Johan


Re: Zephyr Based Bluetooth Mesh implementation on nRF52840-PDK boards

Kinder, David B <david.b.kinder@...>
 

The documents from the master branch (including the doxygen API material) are published nightly to docs.zephyrproject.org

-- david kinder

On Nov 16, 2017, at 10:42 PM, Johan Hedberg <johan.hedberg@...> wrote:

Hi Vikrant,

On Fri, Nov 17, 2017, Vikrant More wrote:
Could you please share in details documentation for Bluetooth Mesh
implementation for Zephyr ?

The API is documented with the usual doxygen syntax. I'm not sure how
frequently documentation in the master branch gets generated onto the
website, so it might be better for you to generate the documentation
either yourself, or perhaps simpler, look at the header files directly.
They can be found under include/bluetooth/mesh/ in the master branch.

Another good reference is how the mesh sample applications use the API,
so you could look e.g. at samples/bluetooth/src/main.c. Yet another
fairly good reference is the implementation of the foundation models,
which you can find in subsys/bluetooth/host/mesh/cfg_srv.c and
subsys/bluetooth/host/mesh/health_srv.c (note that these are only valid
for the latest master branch since the files were recently renamed).

Johan
_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@...
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel


Re: Zephyr Based Bluetooth Mesh implementation on nRF52840-PDK boards

Johan Hedberg
 

Hi Vikrant,

On Fri, Nov 17, 2017, Vikrant More wrote:
Could you please share in details documentation for Bluetooth Mesh
implementation for Zephyr ?
The API is documented with the usual doxygen syntax. I'm not sure how
frequently documentation in the master branch gets generated onto the
website, so it might be better for you to generate the documentation
either yourself, or perhaps simpler, look at the header files directly.
They can be found under include/bluetooth/mesh/ in the master branch.

Another good reference is how the mesh sample applications use the API,
so you could look e.g. at samples/bluetooth/src/main.c. Yet another
fairly good reference is the implementation of the foundation models,
which you can find in subsys/bluetooth/host/mesh/cfg_srv.c and
subsys/bluetooth/host/mesh/health_srv.c (note that these are only valid
for the latest master branch since the files were recently renamed).

Johan


Re: Zephyr Based Bluetooth Mesh implementation on nRF52840-PDK boards

Vikrant More <vikrant8051@...>
 

Could you please share in details documentation for Bluetooth Mesh implementation for Zephyr ?

On Fri, Nov 17, 2017 at 11:43 AM, Vikrant More <vikrant8051@...> wrote:
patch are giving me error. 

So please share original files.

what is original file for bluez-mesh.patch ?


On Fri, Nov 17, 2017 at 11:28 AM, Vikrant More <vikrant8051@...> wrote:
I simply add nrf52840.h & nrf_delay.h from nrf52_SDK into --> zephyr/boards/arm/nrf52840_pca10056.

And include these headder file in main.c ( Zephyr Mesh Example)

After that I add following line for testing of integration of newly added files with Zephyr project.



void main(void)
{
int err;
        
        NRF_P0->DIR |= 0x0001E000;
        NRF_P0->OUTSET |= 0x0001E000;
        
        while(1)
        {
           printk("Initializing...\n");

           NRF_P0->OUT ^= 0x0001E000;
        
          nrf_delay_ms(100);

        } 

/* Initialize the Bluetooth Subsystem */
err = bt_enable(bt_ready);
if (err) {
printk("Bluetooth init failed (err %d)\n", err);
}
}


After executing this on PDK board, I get result as expected .....All four LEDs are blinking continuously.



Next,

I removed above mentioned while loop & edit 

static void gen_onoff_get(struct bt_mesh_model *model,
  struct bt_mesh_msg_ctx *ctx,
  struct net_buf_simple *buf)
{
    NRF_P0->OUT |= 0x0001E000;
}

static void gen_onoff_set(struct bt_mesh_model *model,
  struct bt_mesh_msg_ctx *ctx,
  struct net_buf_simple *buf)
{
    NRF_P0->OUT &= 0xFFFE1FFF;
}


-------------------------------------------------------------------------------------

After giving onoff 1 / get on [on/off: Target=0111]# terminal I get following error -->

Failed to write


After trying same command again it does not reply anything. But LEDs status is also not changes on the Board.

On Thu, Nov 16, 2017 at 7:32 PM, Steve Brown <sbrown@...> wrote:
Here is the code I've been working with.

There is a patch to sample/bluetooth/mesh/main.c and another one to
bluez's mesh stuff.

The first one adds the led code. Some is commented out for working on
another board. I had all 4 leds working at 0100, 0101, 0102 & 0103. Per
the mesh specs, 0100 is the primary element and is the only one with a
config and health server. It also adds an onoff client for the button.
I only hooked up one button. If you want to experiment with group
addresses, you need to configure the button client (element 0100 &
model 1001) to publish to a group address, like c000 and set one or
more buttons to subscribe to c000. That way the button can control more
than one led. Also, the provisioning UUID is set to the MAC address of
the board instead of dddd00...000 so you don't have to power the boards
up one at a time.

You can't use meshctl to send onoff to group addresses. That isn't
implemented yet in the bluez mesh stack.

The bluez's patch adds some informational diagnostics, fixes a bug in
ascii oob input and adds heartbeat and subscribe commands.

I'm certain this is all very buggy, but it's been pretty educational
getting this far.

Steve


On Thu, 2017-11-16 at 19:04 +0530, Vikrant More wrote:
> [meshctl]# configure 0109
> [config: Target = 0109]# add-appkey 1
> [config: Target = 0109]# bind 0 1 1000
> [config: Target = 0109]# back
> [meshctl]# onoff 0109
> [on/off: Target = 0109] onoff 1     // nothing changed on PDK serial
> terminal nor changed LED status
> [on/off: Target = 0109] onoff 0     // nothing changed on PDK serial
> terminal nor changed LED status
>
> I last mail you mentioned that, to change LED status we have to write
> code which will execute after giving onoff 1/0 command.
> So could you please help me it that ?
>
> I know this code to Turn LED1 ON:
> NRF_P0 ->OUT &= ~(1<<13);
>
> & for off -->  NRF_P0 ->OUT |= (1<<13);
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> On Thu, Nov 16, 2017 at 6:42 PM, Steve Brown <sbrown@...>
> wrote:
> > Looks like you are making progress.
> >
> > I'd recommend that you do a "git checkout mesh/*.json" when you
> > start
> > each session. Otherwise, the node/element data accumulates and it's
> > hard to keep track of which node is which. This initializes the
> > first
> > element to 0100.
> >
> > Before you can use the onoff server, you have to issue the
> > following
> > configure commands:
> >
> > add-appkey 1   # that's the appkey that meshctl uses for the onoff
> > app
> > bind 0 1 1000  # this binds that appkey to the onoff server
> >
> > Now the onoff server should be able to accept meshctl onnoff
> > commands.
> >
> > Steve
> >
> > On Thu, 2017-11-16 at 18:26 +0530, Vikrant More wrote:
> > > Thanks !!
> > >
> > > After following your idea,
> > >
> > > On [nRF52840 termianl]-->  provisined ......
> > >                                              Failed to advertise
> > > using Node ID (err -5)
> > >
> > > & after this PDK board stop advertising itself as "Zephyr"
> > >
> > >
> > > If I hit command as "provision dddd0000000000000000000000000000"
> > > then it give as o/p as --> Already provisioned with unicast 0106
> > >
> > > So unicast address is 0106
> > >
> > > Then I run --> configure 0106
> > > [config: Target = 0077]# help
> > >
> > >  Client Configuration Menu
> > > Available commands:
> > >   target <unicast>                          Set target node to
> > > configure
> > >   get-composition [<page_num>]              Get Composition Data
> > >   add-netkey <net_idx>                      Add network key
> > >   del-netkey <net_idx>                      Delete network key
> > >   add-appkey <app_idx>                      Add application key
> > >   del-appkey <app_idx>                      Delete application
> > key
> > >   bind <ele_idx> <app_idx> <mod_id> [cid]   Bind app key to a
> > model
> > >   set-ttl <ttl>                             Set default TTL
> > >   get-ttl                                   Get default TTL
> > >   set-pub <ele_addr> <pub_addr> <app_idx> <period (step|res)>
> > <model>
> > > Set publication
> > >   back                                      Back to main menu
> > >   help                                      Config Commands
> > >
> > >
> > > If I run --> onff 0106       it gives
> > >
> > > [on/off: Target = 0106]# help
> > > Client Configuration Menu
> > > Available commands:
> > >   target <unicast>                          Set node to configure
> > >   get                                       Get ON/OFF status
> > >   onoff <0/1>                               Send "SET ON/OFF"
> > command
> > >   back                                      Back to main menu
> > >   help                                      Config Commands
> > > [on/off: Target = 0106]#
> > >
> > > If I run --> [on/off: Target = 0106]#  onoff 0          it gives
> > > Failed to write
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > Then we test #
> > >
> > > On Thu, Nov 16, 2017 at 4:53 PM, Steve Brown <sbrown@...
> > >
> > > wrote:
> > > > In the 52840 terminal output, you will see something like:
> > > >
> > > > OOB Number: 6021
> > > >
> > > > That's the number to input to meshctl.
> > > >
> > > > Steve
> > > >
> > > > On Thu, 2017-11-16 at 16:11 +0530, Vikrant More wrote:
> > > > > On [meshctl] --> [mesh] Enter Numeric key:
> > > > > Here I input 1234
> > > > >
> > > > > On [nRF52840 termianl]--> Invalid Confirmation Value
> > > > >
> > > > >
> > > > >
> > > > > -----------------------------------------------------------
> > ----
> > > > ----
> > > > > ------------------------------------------
> > > > >
> > > > > On Thu, Nov 16, 2017 at 2:14 PM, Steve Brown <sbrown@cortland
> > .com
> > > > >
> > > > > wrote:
> > > > > > In looking at the output again, It doesn't look like
> > > > > > provisioningcompleted.
> > > > > >
> > > > > > The out-of-band code is output on the 52840's serial port
> > and
> > > > > > forwarded
> > > > > > to probably /dev/ttyACM0. That's the code you need to
> > enter.
> > > > > >
> > > > > > Steve
> > > > > >
> > > > > > On Thu, 2017-11-16 at 10:45 +0530, Vikrant More wrote:
> > > > > > > It is working now !!
> > > > > > > I run hcitool lescan on another terminal & { discover-
> > > > > > unprovisioned
> > > > > > > on , provision dddd0000000000000000000000000000 } on
> > messhctl
> > > > > > > terminal.
> > > > > > >
> > > > > > > Output -->
> > > > > > > -------------------------------------------------------
> > ----
> > > > ----
> > > > > > ----
> > > > > > > -------------------------------------------------------
> > ----
> > > > ----
> > > > > > ----
> > > > > > > -------------------------------------------------------
> > ----
> > > > ----
> > > > > > ----
> > > > > > > -----------------------------
> > > > > > >
> > > > > > > [meshctl]# discover-unprovisioned on
> > > > > > > set_scan_filter_uuids 00001827-0000-1000-8000-
> > 00805f9b34fb
> > > > > > > SetDiscoveryFilter success
> > > > > > > Discovery started
> > > > > > > Adapter property changed
> > > > > > > [CHG] Controller F0:03:8C:B7:5A:18 Discovering: yes
> > > > > > >               Mesh Provisioning Service (00001827-0000-
> > 1000-
> > > > 8000-
> > > > > > > 00805f9b34fb)
> > > > > > >                       Device UUID:
> > > > > > dddd0000000000000000000000000000
> > > > > > >                       OOB: 0000
> > > > > > > [NEW] Device EA:E8:05:9B:16:1D Zephyr
> > > > > > > [meshctl]# provision dddd0000000000000000000000000000
> > > > > > > Trying to connect Device EA:E8:05:9B:16:1D Zephyr
> > > > > > > Adapter property changed
> > > > > > > [CHG] Controller F0:03:8C:B7:5A:18 Discovering: no
> > > > > > > [Zephyr]# Connection successful
> > > > > > > [Zephyr]# Service added
> > > > > > > /org/bluez/hci0/dev_EA_E8_05_9B_16_1D/service0006
> > > > > > > Service added
> > > > /org/bluez/hci0/dev_EA_E8_05_9B_16_1D/service000a
> > > > > > > Char added
> > > > > > >
> > /org/bluez/hci0/dev_EA_E8_05_9B_16_1D/service000a/char000b:
> > > > > > > Char added
> > > > > > >
> > /org/bluez/hci0/dev_EA_E8_05_9B_16_1D/service000a/char000d:
> > > > > > > Services resolved yes
> > > > > > > Found matching char: path
> > > > > > >
> > /org/bluez/hci0/dev_EA_E8_05_9B_16_1D/service000a/char000b,
> > > > uuid
> > > > > > > 00002adb-0000-1000-8000-00805f9b34fb
> > > > > > > Found matching char: path
> > > > > > >
> > /org/bluez/hci0/dev_EA_E8_05_9B_16_1D/service000a/char000d,
> > > > uuid
> > > > > > > 00002adc-0000-1000-8000-00805f9b34fb
> > > > > > > Start notification on
> > > > > > >
> > /org/bluez/hci0/dev_EA_E8_05_9B_16_1D/service000a/char000d
> > > > > > > Characteristic property changed
> > > > > > >
> > /org/bluez/hci0/dev_EA_E8_05_9B_16_1D/service000a/char000d
> > > > > > > Notify started
> > > > > > > Notify for Mesh Provisioning Out Data started
> > > > > > > Open-Node: 0x1444640
> > > > > > > Open-Prov: 0x1446380
> > > > > > > Open-Prov: proxy 0x144a150
> > > > > > > GATT-TX:  03 00 10
> > > > > > > Attempting to write
> > > > > > >
> > /org/bluez/hci0/dev_EA_E8_05_9B_16_1D/service000a/char000b
> > > > > > > Initiated provisioning
> > > > > > > Characteristic property changed
> > > > > > >
> > /org/bluez/hci0/dev_EA_E8_05_9B_16_1D/service000a/char000d
> > > > > > > GATT-RX:       03 01 01 00 01 00 00 04 00 08 00 00 00
> > > > > > > Got provisioning data (12 bytes)
> > > > > > >        01 01 00 01 00 00 04 00 08 00 00 00
> > > > > > > GATT-TX:  03 02 00 00 02 03 04
> > > > > > > Attempting to write
> > > > > > >
> > /org/bluez/hci0/dev_EA_E8_05_9B_16_1D/service000a/char000b
> > > > > > > GATT-TX:  03 03 a8 09 93 50 18 6f 0d 3a cb af 39 40 28 60
> > > > > > > GATT-TX:  9b fa 15 c9
> > > > > > > Attempting to write
> > > > > > >
> > /org/bluez/hci0/dev_EA_E8_05_9B_16_1D/service000a/char000b
> > > > > > > Characteristic property changed
> > > > > > >
> > /org/bluez/hci0/dev_EA_E8_05_9B_16_1D/service000a/char000d
> > > > > > > GATT-RX:       03 03 3a bd 0b 6e 8a d8 dd a9 92 22 a9 3c
> > e4
> > > > c7
> > > > > > > GATT-RX:       fe c3 f1 08 d9 5b ef ff 56 49 87 aa 64 ca
> > 74
> > > > af
> > > > > > > GATT-RX:       ed 3d 89 b9 60 9c b8 19 a3 54 16 a4 dd 12
> > 8d
> > > > 3c
> > > > > > > GATT-RX:       f3 79 1c 18 15 2e 64 3a 4a e2 c1 34 19 c7
> > 39
> > > > ab
> > > > > > > GATT-RX:       9f e3
> > > > > > > Got provisioning data (65 bytes)
> > > > > > >        03 3a bd 0b 6e 8a d8 dd a9 92 22 a9 3c e4 c7 fe
> > > > > > >        c3 f1 08 d9 5b ef ff 56 49 87 aa 64 ca 74 af ed
> > > > > > >        3d 89 b9 60 9c b8 19 a3 54 16 a4 dd 12 8d 3c f3
> > > > > > >        79 1c 18 15 2e 64 3a 4a e2 c1 34 19 c7 39 ab 9f
> > > > > > >        e3
> > > > > > > Request decimal key (0 - 9999)
> > > > > > > [mesh] Enter Numeric key: 1234
> > > > > > > GATT-TX:  03 05 79 75 31 d9 3c ce a3 27 2c d7 1b 5d 90 f3
> > > > > > > GATT-TX:  30 27
> > > > > > > Attempting to write
> > > > > > >
> > /org/bluez/hci0/dev_EA_E8_05_9B_16_1D/service000a/char000b
> > > > > > > Characteristic property changed
> > > > > > >
> > /org/bluez/hci0/dev_EA_E8_05_9B_16_1D/service000a/char000d
> > > > > > > GATT-RX:       03 05 eb 68 f7 99 be 18 ef 71 6e 51 10 f6
> > f5
> > > > 05
> > > > > > > GATT-RX:       d2 40
> > > > > > > Got provisioning data (17 bytes)
> > > > > > >        05 eb 68 f7 99 be 18 ef 71 6e 51 10 f6 f5 05 d2
> > > > > > >        40
> > > > > > > GATT-TX:  03 06 af 78 37 46 88 64 92 8f f1 f4 9c c1 18 95
> > > > > > > GATT-TX:  a7 8d
> > > > > > > Attempting to write
> > > > > > >
> > /org/bluez/hci0/dev_EA_E8_05_9B_16_1D/service000a/char000b
> > > > > > > [Zephyr]#
> > > > > > >
> > > > > > > -------------------------------------------------------
> > ----
> > > > ----
> > > > > > ----
> > > > > > > -------------------------------------------------------
> > ----
> > > > ----
> > > > > > ----
> > > > > > > -------------------------------------------------------
> > ----
> > > > ----
> > > > > > ----
> > > > > > > -------------------------------------------------------
> > ----
> > > > ----
> > > > > > ----
> > > > > > > -------------------------------------------------------
> > ----
> > > > ----
> > > > > > ----
> > > > > > > ---
> > > > > > >
> > > > > > > Now what to do next ??
> > > > > > > I've repeat this procedure on all three board.
> > > > > > >
> > > > > > > How to control LEDs on these board using meshctl or any
> > > > android
> > > > > > APP
> > > > > > > ??
> > > > > > >
> > > > > > > Thank You!!
> > > > > > >
> > > > > > >
> > > > > > >
> > > > >
> > > > >
> > >
> > >
>
>



5021 - 5040 of 8692