Date   

Using Math function in zephyr

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

Hello everyone !

I'm to use round()  function in zephyr. How to include math functions in zephyr ?

--
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: [Zephyr-devel] Confusion about Zephyr ADC API semantics

Marti Bolivar
 

Hi Jonas,

Thanks for your response! I hope you don't mind I've added back the
users list as well.

I am leaving for holiday break at end of day and so likely won't have
more to say until the new year, but I will be sure to handle 12-bit
right aligned values in a u16_t array in anything I propose for the
core API.

FWIW, STM32 ADCs also support 12 bit conversion with configurable alignment.

Best,
Marti

On Thu, Dec 21, 2017 at 2:24 AM, Jonas Pfaff <jonas.pfaff@comsuisse.ch> wrote:
Hi Marti,

I understand your confusion as I had the same problem a few months ago.
I implemented the sam_afec driver using a 16bit array containing right
aligned 12bit values (can go up to 16bit depending on the ADC config)
because it seemed to be the most plausible and straightforward solution
in my use case.
I am curious to see your solution and would be happy to help where I
can.

Regards,
Jonas

Hello again,

Since about a week has passed by with no response, I assume that the
ADC infrastructure is currently unmaintained (or the maintainers are
on vacation), and will do my best to fix the core semantics as best I
can. I will also make a best effort to contact authors of existing ADC
drivers if I need help as regards to changes that might impact those.

I hope and expect to submit some PRs around this in the first week of
2018, now that I've spent a few days hacking on an nRF SAADC driver
and feel I understand the issues a bit better.

Please let me know if you'd like to help!

Thanks,
Marti

On Fri, Dec 15, 2017 at 9:00 PM, Marti Bolivar
<marti@opensourcefoundries.com> wrote:
Hi,

I've been reading through the ADC API, its users, and its test cases,
and I'm confused about the semantics of struct adc_seq_entry, in
particular the field named "buffer". The API docs are vague and the
users contradict each other; something seems wrong to me.

(I volunteer to try to improve the documentation if we can clear
things up; I'm working on an ADC driver and would like to make sure
I'm doing the right thing.)

The main header says "buffer" is a byte array:

https://github.com/zephyrproject-rtos/zephyr/blob/master/include/adc.h#L39

But it doesn't say anything about the contents. That's strange,
especially since common ADC IPs can do 12+ bit conversions. (I at
least expected a u16*, and something written about the left- or
right-alignment of sample data, e.g. how a 12 bit sample is stored in
a 16 bit word.)

That same header only has this to say about the returned values from
an adc_read() call:

* The sample data can be retrieved from the memory buffers in
* the sequence table structure.

So I looked at the API users to find out more, but the results were
even more confusing.

This "simple" test wants to interpret the results as though the buffer
field points at an array of u32 (note the _print_sample_in_hex
implementation and the "delta" printk in adc_test):

https://github.com/zephyrproject-rtos/zephyr/blob/master/tests/drivers/adc/adc_simple/src/main.c#L36

It also says buffer should be void*, which isn't true:

https://github.com/zephyrproject-rtos/zephyr/blob/master/tests/drivers/adc/adc_simple/src/main.c#L78

This "api" test thinks buffer is u16*:

https://github.com/zephyrproject-rtos/zephyr/blob/master/tests/drivers/adc/adc_api/src/test_adc.c#L53

The ADC-based grove temperature driver treats Zephyr samples as if
they were 12 bit right aligned values in a u16 array, and has a
comment saying that's the common convention:

https://github.com/zephyrproject-rtos/zephyr/blob/master/drivers/grove/temperature_sensor.c#L46

Can anyone clarify what the correct interpretation of this field is?

Thanks,
Marti


Problem in I2C interfacing with nrf52840

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


Hello everyone !!!

I'm trying to interface an EEPROM with nrf52840 using I2C protocol.

For this, I used  .../samples/drivers/i2c_fujitsu_fram example, I'm able to read bytes from memory, but I can't write anything in memory. It's write_bytes() function doesn't seem to be working.

Did someone faced the same issue? and what needs to be done to fix this?

--
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: Problem in working with Ozone and nRF52840

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

Thanks,
That solved the issue.


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


On Wed, Dec 20, 2017 at 8:25 PM, Cufi, Carles <Carles.Cufi@...> wrote:

Hi Ashish,

 

The “variable is out of scope” is pretty common and I get it all the time too. It usually happens with local variables only, and it’s mostly due to the compiler optimizations. So the 2 options you have is to either reduce the optimization level (say from –O3 to –O0) or, for a quick fix, store the variable you’re interested in in a temporary global.

 

Regards,

 

Carles

 

From: zephyr-users-bounces@lists.zephyrproject.org [mailto:zephyr-users-bounces@lists.zephyrproject.org] On Behalf Of ashish.shukla@...
Sent: 20 December 2017 06:22
To: zephyr-users@lists.zephyrproject.org; zephyr-devel@lists.zephyrproject.org
Subject: [Zephyr-users] Problem in working with Ozone and nRF52840

 

Hello everyone !!!

I'm just starting to work with Ozone for hardware debugging of nRF52840 uC.

When I enter a variable named cnt which is declared in main function, it says the variable is out of scope. I can't figure out what this means here, and how to resolve this.

Also, is there any way look at status of PINs of uC e.g. I want to look at changing status of pins as a graph.

I'm attaching snapshot of Ozone window. 

 

--

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: Confusion about Zephyr ADC API semantics

Marti Bolivar
 

Hello again,

Since about a week has passed by with no response, I assume that the
ADC infrastructure is currently unmaintained (or the maintainers are
on vacation), and will do my best to fix the core semantics as best I
can. I will also make a best effort to contact authors of existing ADC
drivers if I need help as regards to changes that might impact those.

I hope and expect to submit some PRs around this in the first week of
2018, now that I've spent a few days hacking on an nRF SAADC driver
and feel I understand the issues a bit better.

Please let me know if you'd like to help!

Thanks,
Marti

On Fri, Dec 15, 2017 at 9:00 PM, Marti Bolivar
<marti@opensourcefoundries.com> wrote:
Hi,

I've been reading through the ADC API, its users, and its test cases,
and I'm confused about the semantics of struct adc_seq_entry, in
particular the field named "buffer". The API docs are vague and the
users contradict each other; something seems wrong to me.

(I volunteer to try to improve the documentation if we can clear
things up; I'm working on an ADC driver and would like to make sure
I'm doing the right thing.)

The main header says "buffer" is a byte array:

https://github.com/zephyrproject-rtos/zephyr/blob/master/include/adc.h#L39

But it doesn't say anything about the contents. That's strange,
especially since common ADC IPs can do 12+ bit conversions. (I at
least expected a u16*, and something written about the left- or
right-alignment of sample data, e.g. how a 12 bit sample is stored in
a 16 bit word.)

That same header only has this to say about the returned values from
an adc_read() call:

* The sample data can be retrieved from the memory buffers in
* the sequence table structure.

So I looked at the API users to find out more, but the results were
even more confusing.

This "simple" test wants to interpret the results as though the buffer
field points at an array of u32 (note the _print_sample_in_hex
implementation and the "delta" printk in adc_test):

https://github.com/zephyrproject-rtos/zephyr/blob/master/tests/drivers/adc/adc_simple/src/main.c#L36

It also says buffer should be void*, which isn't true:

https://github.com/zephyrproject-rtos/zephyr/blob/master/tests/drivers/adc/adc_simple/src/main.c#L78

This "api" test thinks buffer is u16*:

https://github.com/zephyrproject-rtos/zephyr/blob/master/tests/drivers/adc/adc_api/src/test_adc.c#L53

The ADC-based grove temperature driver treats Zephyr samples as if
they were 12 bit right aligned values in a u16 array, and has a
comment saying that's the common convention:

https://github.com/zephyrproject-rtos/zephyr/blob/master/drivers/grove/temperature_sensor.c#L46

Can anyone clarify what the correct interpretation of this field is?

Thanks,
Marti


Re: UART flash

Carles Cufi
 

Hi Alan,

Forgot to reply to this:

At the moment it would have to be one UART for the Bluetooth one for the
updates?
No, it's the same UART, but you'll need to reboot into MCUboot's serial recovery mode, update the image and then reboot back into the new image.

Regards,

Carles


Re: UART flash

Carles Cufi
 

Hi Alan,

-----Original Message-----
From: Alan Martinovic [mailto:alan.martinovic@senic.com]
Sent: 20 December 2017 16:09
To: Cufi, Carles <Carles.Cufi@nordicsemi.no>
Cc: zephyr-users@lists.zephyrproject.org
Subject: Re: [Zephyr-users] UART flash

Cool, thanks.

Also in the future we'd like to map firmware update to HCI so that
it's all integrated.

The purpose of this is to be able to do updates on the same physical
UART on which the Bluetooth Host-Controller communication is taking
place?
Yes, and also not to have to enter the bootloader's recovery mode. Right now you'll need to force the bootloader to enter its recovery mode to upload a new image, which will be received by the bootloader code itself. The idea in the future is that you can interleave HCI packets that contains fragments of an image with normal HCI operation, so that once the whole image is uploaded the controller only needs to reboot and the bootloader will swap the images.

The HCI specs actually have this defines?
No, those will be vendor-specific commands. You can find the currently existing ones here: https://github.com/zephyrproject-rtos/zephyr/blob/master/doc/subsystems/bluetooth/hci.txt

Regards,

Carles


Re: UART flash

Alan
 

Cool, thanks.

Also in the future we'd like to map firmware update to HCI so that it's all integrated.
The purpose of this is to be able to do updates on the same physical
UART on which
the Bluetooth Host-Controller communication is taking place?
The HCI specs actually have this defines?


At the moment it would have to be one UART for the Bluetooth one for
the updates?

Be Well,
Alan


On Wed, Dec 20, 2017 at 3:53 PM, Cufi, Carles <Carles.Cufi@nordicsemi.no> wrote:
Hi there Alan,


-----Original Message-----
From: zephyr-users-bounces@lists.zephyrproject.org [mailto:zephyr-users-
bounces@lists.zephyrproject.org] On Behalf Of Alan Martinovic
Sent: 20 December 2017 12:46
To: zephyr-users@lists.zephyrproject.org
Subject: [Zephyr-users] UART flash

Hi,
we're using Zephyr for providing the HCI for a NRF52 chip.
The example from samples/bluetooth/hci_uart is working very well.

However the flashing is done using jtag (the integrated Segger chip on
the PAC10040 dev board).

Is there an option in Zephyr to have a bootloader that would support
flashing firmware through UART?
Yes, MCUboot supports serial recovery to upload flash images, and it's the main open source bootloader for Zephyr.

https://github.com/runtimeco/mcuboot

Also in the future we'd like to map firmware update to HCI so that it's all integrated.

Regards,

Carles


Re: Problem in working with Ozone and nRF52840

Carles Cufi
 

Hi Ashish,

 

The “variable is out of scope” is pretty common and I get it all the time too. It usually happens with local variables only, and it’s mostly due to the compiler optimizations. So the 2 options you have is to either reduce the optimization level (say from –O3 to –O0) or, for a quick fix, store the variable you’re interested in in a temporary global.

 

Regards,

 

Carles

 

From: zephyr-users-bounces@... [mailto:zephyr-users-bounces@...] On Behalf Of ashish.shukla@...
Sent: 20 December 2017 06:22
To: zephyr-users@...; zephyr-devel@...
Subject: [Zephyr-users] Problem in working with Ozone and nRF52840

 

Hello everyone !!!

I'm just starting to work with Ozone for hardware debugging of nRF52840 uC.

When I enter a variable named cnt which is declared in main function, it says the variable is out of scope. I can't figure out what this means here, and how to resolve this.

Also, is there any way look at status of PINs of uC e.g. I want to look at changing status of pins as a graph.

I'm attaching snapshot of Ozone window. 

 

--

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: UART flash

Carles Cufi
 

Hi there Alan,

-----Original Message-----
From: zephyr-users-bounces@lists.zephyrproject.org [mailto:zephyr-users-
bounces@lists.zephyrproject.org] On Behalf Of Alan Martinovic
Sent: 20 December 2017 12:46
To: zephyr-users@lists.zephyrproject.org
Subject: [Zephyr-users] UART flash

Hi,
we're using Zephyr for providing the HCI for a NRF52 chip.
The example from samples/bluetooth/hci_uart is working very well.

However the flashing is done using jtag (the integrated Segger chip on
the PAC10040 dev board).

Is there an option in Zephyr to have a bootloader that would support
flashing firmware through UART?
Yes, MCUboot supports serial recovery to upload flash images, and it's the main open source bootloader for Zephyr.

https://github.com/runtimeco/mcuboot

Also in the future we'd like to map firmware update to HCI so that it's all integrated.

Regards,

Carles


UART flash

Alan
 

Hi,
we're using Zephyr for providing the HCI for a NRF52 chip.
The example from samples/bluetooth/hci_uart is working
very well.

However the flashing is done using jtag (the integrated Segger chip
on the PAC10040 dev board).

Is there an option in Zephyr to have a bootloader that would support
flashing firmware through UART?

Be Well,
Alan


Problem in working with Ozone and nRF52840

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

Hello everyone !!!

I'm just starting to work with Ozone for hardware debugging of nRF52840 uC.

When I enter a variable named cnt which is declared in main function, it says the variable is out of scope. I can't figure out what this means here, and how to resolve this.

Also, is there any way look at status of PINs of uC e.g. I want to look at changing status of pins as a graph.

I'm attaching snapshot of Ozone window. 

--
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: Making use of Hardware debugger available with nrf52840 preview development kit

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

Hello all,

I got Ozone working for nrf52840 PDK. Thanks a lot. 


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


On Tue, Dec 19, 2017 at 2:16 AM, Cufi, Carles <Carles.Cufi@...> wrote:

Hi there,

 

Once the PR below is merged, you will be able to use GDB by simply typing “make debug” if you prefer it to Ozone:

 

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

 

Regards,

 

Carles

 

From: zephyr-users-bounces@lists.zephyrproject.org [mailto:zephyr-users-bounces@lists.zephyrproject.org] On Behalf Of ashish.shukla@...
Sent: 18 December 2017 13:20
To: zephyr-users@lists.zephyrproject.org; zephyr-devel@lists.zephyrproject.org
Subject: [Zephyr-users] Making use of Hardware debugger available with nrf52840 preview development kit

 

Hi !

I've got nrf52840 pdk and I'm working with blue tooth mesh developed by zephyr community.

I want to make use of hardware debugger available with development kit, i.e. I should be able see values of registers, values in memory address, halt processing at any specific line of code and examine those values.

I read documentation but didn't find anything related to what I'm looking for.

 

--

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: Making use of Hardware debugger available with nrf52840 preview development kit

Carles Cufi
 

Hi there,

 

Once the PR below is merged, you will be able to use GDB by simply typing “make debug” if you prefer it to Ozone:

 

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

 

Regards,

 

Carles

 

From: zephyr-users-bounces@... [mailto:zephyr-users-bounces@...] On Behalf Of ashish.shukla@...
Sent: 18 December 2017 13:20
To: zephyr-users@...; zephyr-devel@...
Subject: [Zephyr-users] Making use of Hardware debugger available with nrf52840 preview development kit

 

Hi !

I've got nrf52840 pdk and I'm working with blue tooth mesh developed by zephyr community.

I want to make use of hardware debugger available with development kit, i.e. I should be able see values of registers, values in memory address, halt processing at any specific line of code and examine those values.

I read documentation but didn't find anything related to what I'm looking for.

 

--

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: Making use of Hardware debugger available with nrf52840 preview development kit

Carles Cufi
 

Hi there,

 

You can use both GDB and Ozone using the built-in Segger chip.

 

Take a look at this page:

 

http://docs.zephyrproject.org/tools/nordic_segger.html#nordic-segger

 

Regards,

 

Carles

 

From: zephyr-users-bounces@... [mailto:zephyr-users-bounces@...] On Behalf Of ashish.shukla@...
Sent: 18 December 2017 13:20
To: zephyr-users@...; zephyr-devel@...
Subject: [Zephyr-users] Making use of Hardware debugger available with nrf52840 preview development kit

 

Hi !

I've got nrf52840 pdk and I'm working with blue tooth mesh developed by zephyr community.

I want to make use of hardware debugger available with development kit, i.e. I should be able see values of registers, values in memory address, halt processing at any specific line of code and examine those values.

I read documentation but didn't find anything related to what I'm looking for.

 

--

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: Sending notification with MTU size more than 23 bytes - BLE

dhguja@gmail.com
 

Hello Johan,
              Many thanks for the reply. I tried changing the configuration for CONFIG_BT_L2CAP_TX_MTU to my required size (30 bytes to test)
and used the nRF connect app as client on my phone. I only received data when there is 20 bytes (i assume some 3 bytes are used in GATT) in the buffer.
If i send one more character in the buffer (21 bytes) i did not receive any data at all in client. I used indications for my custom attribute.

Is it possible that my peripheral device itself is not sending any data beyond the 20 chars or client application is ignoring the data beyond default 23 bytes.
I did not try "bt_gatt_exchange_mtu()" call yet. May be i will test with simple client on zephyr also with that call.

I would like your opinion whether this is in right direction and if there any other app like nRFconnect to test BT connections with modifiable MTU size during connection.

Thanks in advance.

Regards,
DJ

On Sat, Dec 16, 2017 at 7:19 AM, Johan Hedberg <johan.hedberg@...> wrote:
Hi DJ,

On Fri, Dec 15, 2017, dhananjay gj wrote:
>       I have a question regarding handling MTU size more than 23 bytes
> during notification. I have a custom service on a peripheral device app to
> which client app(lets say android app) will subscribe to. When the
> peripheral device has some data ( usually more than 23 bytes) it will send
> the data to the client via 'notification'. I saw many solutions with
> respect to nRF SDK but i am not using any SDK but just developing the
> peripheral device app using zephyr's BLE APIs. I would like to know how to
> handle this?
>
> I came across MTU negotiation during connection while searching on this. I
> couldn't find any sample code on zephyr using this method. Does peripheral
> device app has to do anything during this negotiation?

The maxium ATT MTU Zephyr will use is based on the values you've given
to CONFIG_BT_L2CAP_TX_MTU and CONFIG_BT_L2CAP_RX_MTU. Additionally,
there's a runtime API bt_gatt_exchange_mtu() that can be used to trigger
the MTU negotiation if it doesn't otherwise happen.

Johan


Making use of Hardware debugger available with nrf52840 preview development kit

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

Hi !

I've got nrf52840 pdk and I'm working with blue tooth mesh developed by zephyr community.

I want to make use of hardware debugger available with development kit, i.e. I should be able see values of registers, values in memory address, halt processing at any specific line of code and examine those values.

I read documentation but didn't find anything related to what I'm looking for.

--
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: Sending notification with MTU size more than 23 bytes - BLE

Johan Hedberg
 

Hi DJ,

On Fri, Dec 15, 2017, dhananjay gj wrote:
I have a question regarding handling MTU size more than 23 bytes
during notification. I have a custom service on a peripheral device app to
which client app(lets say android app) will subscribe to. When the
peripheral device has some data ( usually more than 23 bytes) it will send
the data to the client via 'notification'. I saw many solutions with
respect to nRF SDK but i am not using any SDK but just developing the
peripheral device app using zephyr's BLE APIs. I would like to know how to
handle this?

I came across MTU negotiation during connection while searching on this. I
couldn't find any sample code on zephyr using this method. Does peripheral
device app has to do anything during this negotiation?
The maxium ATT MTU Zephyr will use is based on the values you've given
to CONFIG_BT_L2CAP_TX_MTU and CONFIG_BT_L2CAP_RX_MTU. Additionally,
there's a runtime API bt_gatt_exchange_mtu() that can be used to trigger
the MTU negotiation if it doesn't otherwise happen.

Johan


Re: [Zephyr-devel] I2C driver for nrf52840 not being compiled

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

Hi,

Thanks, it compiles and run successfully.


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


On Fri, Dec 15, 2017 at 1:53 PM, Puzdrowski, Andrzej <Andrzej.Puzdrowski@...> wrote:

Hi.

 

For nRF52840 I2C driver is zephyr. All its option are in general i2c Kconfig file.

I attached configuration I had used to compile example you mentioned.

 

BR

 

Andrzej

 

 

From: zephyr-devel-bounces@lists.zephyrproject.org [mailto:zephyr-devel-bounces@lists.zephyrproject.org] On Behalf Of ashish.shukla@...
Sent: Friday, December 15, 2017 5:56 AM
To: zephyr-users@lists.zephyrproject.org; zephyr-devel@lists.zephyrproject.org
Subject: [Zephyr-devel] I2C driver for nrf52840 not being compiled

 

Hello everyone !

I'm trying to interface an I2C device with nrf52840 controller.

When I look into ../zephyr/drivers/i2c directory, there is no Kconfig file corresponding to i2c_nrf5.c 

Again in Kconfig, this driver isn't included, consequently I'm not being able to compile ../zephyr/samples/drivers/i2c_fujitsu_fram  demo for nrf52840.

what needs to be done to fix this issue?  

 

--

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

 



Confusion about Zephyr ADC API semantics

Marti Bolivar
 

Hi,

I've been reading through the ADC API, its users, and its test cases,
and I'm confused about the semantics of struct adc_seq_entry, in
particular the field named "buffer". The API docs are vague and the
users contradict each other; something seems wrong to me.

(I volunteer to try to improve the documentation if we can clear
things up; I'm working on an ADC driver and would like to make sure
I'm doing the right thing.)

The main header says "buffer" is a byte array:

https://github.com/zephyrproject-rtos/zephyr/blob/master/include/adc.h#L39

But it doesn't say anything about the contents. That's strange,
especially since common ADC IPs can do 12+ bit conversions. (I at
least expected a u16*, and something written about the left- or
right-alignment of sample data, e.g. how a 12 bit sample is stored in
a 16 bit word.)

That same header only has this to say about the returned values from
an adc_read() call:

* The sample data can be retrieved from the memory buffers in
* the sequence table structure.

So I looked at the API users to find out more, but the results were
even more confusing.

This "simple" test wants to interpret the results as though the buffer
field points at an array of u32 (note the _print_sample_in_hex
implementation and the "delta" printk in adc_test):

https://github.com/zephyrproject-rtos/zephyr/blob/master/tests/drivers/adc/adc_simple/src/main.c#L36

It also says buffer should be void*, which isn't true:

https://github.com/zephyrproject-rtos/zephyr/blob/master/tests/drivers/adc/adc_simple/src/main.c#L78

This "api" test thinks buffer is u16*:

https://github.com/zephyrproject-rtos/zephyr/blob/master/tests/drivers/adc/adc_api/src/test_adc.c#L53

The ADC-based grove temperature driver treats Zephyr samples as if
they were 12 bit right aligned values in a u16 array, and has a
comment saying that's the common convention:

https://github.com/zephyrproject-rtos/zephyr/blob/master/drivers/grove/temperature_sensor.c#L46

Can anyone clarify what the correct interpretation of this field is?

Thanks,
Marti

2141 - 2160 of 2543