1. devel@lists.zephyrproject.org
  2. Messages
   Date   
Does zephry support standard c io library?

ljh_dev@...
 

I finded zephyr source stdio.h only support a minimal io system, it did not include such as FILE ..defines,etc, does it support c io library ?
Re: Opus codec on nrf52840

Zięcik, Piotr <piotr.ziecik@...>
 

Hi.

 

Great to hear that!

Do you have any information about resource usage (Flash/RAM used, CPU load etc)?

 

Piotr ZIĘCIK | Senior Firmware Engineer
M +48 698 726 973| Kraków, Poland
nordicsemi.com | devzone.nordicsemi.com

Nordic_logo_signature

 

From: nicolas lantz <nicolas.lantz@...>
Sent: Wednesday, December 19, 2018 10:15 AM
To: Zięcik, Piotr <Piotr.Ziecik@...>; Cufi, Carles <Carles.Cufi@...>; devel@...
Subject: Re: [Zephyr-devel] Opus codec on nrf52840

 

Hello,

I have a "net_opus" server sample that is able to compress and then decode an audio PCM stream with the opus codec.
- It work on the fly in realtime with an opus codec configured in low complexity on the nrf52840-dk board.
- the stream come from a  TCP client like netcat, it's encoded with opus, then decoded, and the output pcm stream is sent back to the TCP client.

Running the demo give something like that :
nc 192.0.2.1 4242 < Test_16000Hz_mono_16bit.raw  | aplay -t raw -f S16_LE -r 16000 -c 1 -

If someone is interested on it :
https://gitlab.com/ubicore/zephyr/commit/177a410c6902ecacb9552c907f1e4f60e7a23b1a



Regards,
Nicolas
 
Nicolas LANTZ
M : +33 (0)6 19 07 43 43
T : +33 (0)9 52 96 81 86
www.ubicore.net

Le 04/12/2018 à 10:38, nicolas lantz a écrit :

Thanks you for the reponse.
I took the time to extract the modified opus library code from the Smart Ready project (from the .exe to linux) and compared it to the origin opus lib.
Now i will try to use it in a zephry project
 
Regards,
 
Nicolas
Nicolas LANTZ
M : +33 (0)6 19 07 43 43
T : +33 (0)9 52 96 81 86
www.ubicore.net

Le 29/11/2018 à 12:56, Zięcik, Piotr a écrit :

Hello.

 

I can recommend looking into https://www.nordicsemi.com/eng/Products/Bluetooth-low-energy/nRFready-Smart-Remote-3-for-nRF52-Series

Unfortunately it is not based on the Zephyr, however it implements audio streaming using Opus and contains an optimized version of the codec

(with reduced memory requirements as well as using DPS extensions available on the Nordic chips).

 

If you require any further information, feel free to contact me.

Piotr ZIĘCIK | Senior Firmware Engineer
M +48 698 726 973| Kraków, Poland
nordicsemi.com | devzone.nordicsemi.com

Nordic_logo_signature

 

From: Cufi, Carles
Sent: Thursday, November 29, 2018 12:49 PM
To: nicolas lantz <nicolas.lantz@...>; devel@...; Zięcik, Piotr <Piotr.Ziecik@...>
Subject: RE: [Zephyr-devel] Opus codec on nrf52840

 

+ Piotr

 

From: devel@... <devel@...> On Behalf Of nicolas lantz
Sent: 29 November 2018 12:41
To: devel@...
Subject: [Zephyr-devel] Opus codec on nrf52840

 

Hi,

I would like to use the Opus codec with zephyr on a nrf52840 to encode or decode an audio stream.
Has anyone have a suggestion on this project?


Regards,
 
Nicolas
 

 

 
Re: Opus codec on nrf52840

nicolas lantz
 

Hello,

I have a "net_opus" server sample that is able to compress and then decode an audio PCM stream with the opus codec.
- It work on the fly in realtime with an opus codec configured in low complexity on the nrf52840-dk board.
- the stream come from a  TCP client like netcat, it's encoded with opus, then decoded, and the output pcm stream is sent back to the TCP client.

Running the demo give something like that :
nc 192.0.2.1 4242 < Test_16000Hz_mono_16bit.raw  | aplay -t raw -f S16_LE -r 16000 -c 1 -

If someone is interested on it :
https://gitlab.com/ubicore/zephyr/commit/177a410c6902ecacb9552c907f1e4f60e7a23b1a


Regards,
Nicolas

Nicolas LANTZ
M : +33 (0)6 19 07 43 43
T : +33 (0)9 52 96 81 86
www.ubicore.net
Le 04/12/2018 à 10:38, nicolas lantz a écrit :

Thanks you for the reponse.
I took the time to extract the modified opus library code from the Smart Ready project (from the .exe to linux) and compared it to the origin opus lib.
Now i will try to use it in a zephry project

Regards,
 
Nicolas
Nicolas LANTZ
M : +33 (0)6 19 07 43 43
T : +33 (0)9 52 96 81 86
www.ubicore.net
Le 29/11/2018 à 12:56, Zięcik, Piotr a écrit :

Hello.

 

I can recommend looking into https://www.nordicsemi.com/eng/Products/Bluetooth-low-energy/nRFready-Smart-Remote-3-for-nRF52-Series

Unfortunately it is not based on the Zephyr, however it implements audio streaming using Opus and contains an optimized version of the codec

(with reduced memory requirements as well as using DPS extensions available on the Nordic chips).

 

If you require any further information, feel free to contact me.

Piotr ZIĘCIK | Senior Firmware Engineer
M +48 698 726 973| Kraków, Poland
nordicsemi.com | devzone.nordicsemi.com

Nordic_logo_signature

 

From: Cufi, Carles
Sent: Thursday, November 29, 2018 12:49 PM
To: nicolas lantz <nicolas.lantz@...>; devel@...; Zięcik, Piotr <Piotr.Ziecik@...>
Subject: RE: [Zephyr-devel] Opus codec on nrf52840

 

+ Piotr

 

From: devel@... <devel@...> On Behalf Of nicolas lantz
Sent: 29 November 2018 12:41
To: devel@...
Subject: [Zephyr-devel] Opus codec on nrf52840

 

Hi,

I would like to use the Opus codec with zephyr on a nrf52840 to encode or decode an audio stream.
Has anyone have a suggestion on this project?

Regards,
 
Nicolas
 
STM32F091 - UARTs sharing IRQ don't work together

Rodrigo Peixoto <rodrigopex@...>
 

Hello everyone.

I am facing issues when trying to use UART3 and UART4 of the STM32F091 (they were not available at the original DTS, I had to include them). I have noticed that these UARTs share the same interrupt number 29. When both are enabled I can send no data to them. Any clue?

I will try to do a pull request after solving the problem. 

Thank you.
Best regards,
Rodrigo Peixoto
Co-founder and Technical advisor

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

Carles Cufi
 

Hi all,

Apologies for the late notice. Due to most TSC members being on vacation we are not going to have our regular API and Release Readiness meeting today.

Regards,

Carles
compare mcumgr image hash with compiled/signed .bin/.hex hash

florian.gaertner@...
 

Hi there,

Is there an easy way to compare the mcumgr image hash response to the hash of the hex or binary file (signed or unsigned)?

# mcumgr --conntype ble --connstring ctlr_name=hci0,peer_name='Zephyr' image list

e.g. with
# sha256sum signed-image.hex

Best regards
Florian
How to integrated BLE central code with RPL Node example? #nrf52832 #zephyrbluetoothmesh

Akash Naidu <akashnaiduece@...>
 

Hi All,
I have been working on RPL node example(which is in zephyr/samples/net/rpl_node), to work it as both central and peripheral concurrently.
I have successfully integrated peripheral code with RPL node example, and device has been able to Advertise and able to establish the connection also.
To act as peripheral, i have edited "prj.conf" file and has been working as peripheral.
If i do same thing for central, device was not getting enter into scan mode.
my aim is, each device should act as peripheral and central and on top of BLE links will send IPV6 packets by using RPL protocol.

could you please help me to integrate Central(nrf52832 DK) with RPL_node?

Thanks in Adavnce.
BR
Akash.
Disabling Multithreading

Raj Gundi
 

Hi Carles,

 

I am trying to build Zephyr to fit in a memory constrained device of 64kB. My device doesn’t require multithreading and hence I disabled multithreading to save on the memory. However, this is throwing me exceptions since I have UART and SPI Flash drivers enabled. It appears the semaphore accesses in those drivers are not “single-thread” aware. Is there anything that can be done to work-around this? Does just “nop”ing it out suffice? Please let me know.

 

Regards,

Raj
problems linking custom board (terasic sockit) and soc for altera nios2

mazaun@...
 

Hi,
I'm working on creating a custom out-of-tree board with soc for the Terasic SocKit board. Though there are certainly many things not done correct yet, I'm currently stuck at linking the simple hello_world sample. I uploaded the code to https://github.com/mzau/altera-sockit-zephyr. Please see https://github.com/mzau/altera-sockit-zephyr/tree/master/hello_world/README.md  for details.

Any help or hints are very appreciated :)

Regards
Re: To current Zephyr HTTP API users

Paul Sokolovsky
 

Hello Jukka,

On Thu, 13 Dec 2018 18:01:42 +0200
"Jukka Rissanen" <jukka.rissanen@linux.intel.com> wrote:

Hello,

currently Zephyr has HTTP server & client APIs that are built on top
of net-app API. As we are currently trying to deprecate the net-app
API, the HTTP APIs would need to be rewritten to use the BSD socket
API instead of net-app API.

Would there be anyone interested in writing such HTTP server / client
APIs?
Well, I kinda was interested in this, given all my criticism of the
older API and implementation. But I'm in reservations after the TLS
zstream case, where a bunch of effort was spent to do it right, and all
that went to /dev/null.

If there are no users for existing HTTP APIs, we could also
optionally start to deprecate them.
IMHO before we provide a replacement, we should not deprecate
anything.

The new HTTP APIs could also be
based to some existing open source library if you know any.
I think that given that we have "in house" implementation of COAP,
LWM2M, MQTT, that it would be indeed a refreshing change to not try to
invent our own API, but try to port an existing. Well, at least to
survey the landscape trying to find one which would be suitable for our
code/RAM size requirements.

So please
raise your hand if you could help here.
So, I think we should decide if it would be OK to bet on 3rd-party
lib at all, then focus a call exactly like that: Are there suggestions
of existing lib to port, satisfying our requirements (which is, again,
being small)?

Myself, I think my plate is more than full for 1.14, and I already
subscribed to port another lib to Zephyr (OPC-UA). However, if we agree
on 3rd-party solution to be OK in principle, I start surveying too in
the background in the meantime.



Cheers,
Jukka
[]

--
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
To current Zephyr HTTP API users

Jukka Rissanen
 

Hello,

currently Zephyr has HTTP server & client APIs that are built on top of
net-app API. As we are currently trying to deprecate the net-app API,
the HTTP APIs would need to be rewritten to use the BSD socket API
instead of net-app API.

Would there be anyone interested in writing such HTTP server / client
APIs? If there are no users for existing HTTP APIs, we could also
optionally start to deprecate them. The new HTTP APIs could also be
based to some existing open source library if you know any. So please
raise your hand if you could help here.


Cheers,
Jukka
Re: Mesh: Limit of PDUs sent within a moving 10-second window

Johan Hedberg
 

Hi Martin,

On 12 Dec 2018, at 14.42, Martin <ma@jgs-wg.de> wrote:
the Bluetooth Mesh Profile specification says that "A node should
originate less than 100 Lower Transport PDUs in a moving 10-second
window." on p. 94.
Can anyone tell me if Zephyr OS is observing this limit and possibly
discarding packets that break this constraint or whether I have to
ensure that I do not break this limit on my own?
We’re not trying to enforce anything like that as receivers. As senders it’s also not really possible to exceed it currently. Even with the minimum advertising interval (20ms) and default Network Transmit State (with 2 retransmissions) the stack takes 120ms to send out any given PDU, so even if you had a continuous flow of outgoing packets you’ll still be below the recommended maximum (note that it’s a recommended, not required one since the spec uses “should” for this.

In the future, once we have Mesh vendor HCI extensions in place we might be able to do send out packets more efficiently, and then we can revisit this issue to see if some enforcement needs to be done in the stack or whether to leave this up to the application.

Johan
Mesh: Limit of PDUs sent within a moving 10-second window

Martin <ma@...>
 

Hi,
the Bluetooth Mesh Profile specification says that "A node should
originate less than 100 Lower Transport PDUs in a moving 10-second
window." on p. 94.
Can anyone tell me if Zephyr OS is observing this limit and possibly
discarding packets that break this constraint or whether I have to
ensure that I do not break this limit on my own?

Thanks,
Martin
Re: USB controller driver usb_dc_ep_write

Loic Poulain
 



On Tue, 11 Dec 2018 at 12:28, Cufi, Carles <carles.cufi@...> wrote:

+ Johann, Andrei, Pawel

 

From: devel@... <devel@...> On Behalf Of Mark Wang
Sent: 10 December 2018 13:37
To: devel@...
Subject: [Zephyr-devel] USB controller driver usb_dc_ep_write

 

Hi all,

I see many USB controller drivers implement usb_dc_ep_write function with one copy, copy the data (passed to usb_dc_ep_write) to one self’s buffer then do the transfer.

Do I need do this when implementing one new USB controller driver?


There is no requirement to copy the data, but usually, usb device drivers copy the data to the controller FIFO.

Does the Zephyr USB stack limit the data (pass to usb_dc_ep_write) is in RAM?

 
There is no defined data size limit when calling the function, but at then end, driver decides how much data is written (e.g. size of the FIFO).

The function prototype is as follow:

int usb_dc_ep_write(const u8_t ep, const u8_t *const data,

                  const u32_t data_len, u32_t *const ret_bytes)


For USB users (e.g. class/gadget drivers, app) the high level usb_transfer() function can be used to execute USB data transfer.

Regards,
Loic


 

 

Mark Wang

Thanks

 
Re: USB controller driver usb_dc_ep_write

Carles Cufi
 

+ Johann, Andrei, Pawel

 

From: devel@... <devel@...> On Behalf Of Mark Wang
Sent: 10 December 2018 13:37
To: devel@...
Subject: [Zephyr-devel] USB controller driver usb_dc_ep_write

 

Hi all,

I see many USB controller drivers implement usb_dc_ep_write function with one copy, copy the data (passed to usb_dc_ep_write) to one self’s buffer then do the transfer.

Do I need do this when implementing one new USB controller driver? Does the Zephyr USB stack limit the data (pass to usb_dc_ep_write) is in RAM?

The function prototype is as follow:

int usb_dc_ep_write(const u8_t ep, const u8_t *const data,

                  const u32_t data_len, u32_t *const ret_bytes)

 

Mark Wang

Thanks

 
USB controller driver usb_dc_ep_write

Mark Wang
 

Hi all,

I see many USB controller drivers implement usb_dc_ep_write function with one copy, copy the data (passed to usb_dc_ep_write) to one self’s buffer then do the transfer.

Do I need do this when implementing one new USB controller driver? Does the Zephyr USB stack limit the data (pass to usb_dc_ep_write) is in RAM?

The function prototype is as follow:

int usb_dc_ep_write(const u8_t ep, const u8_t *const data,

                  const u32_t data_len, u32_t *const ret_bytes)

 

Mark Wang

Thanks

 
Re: CONFIG_BT_PRIVACY cannot be enabled with Hci_uart sample #nrf52832 #hci

icephyr
 

Thanks Carles, I have realized it.
Re: Ble mesh stack not compatilbe with c++ #ble #bluetoothmesh

Carles Cufi
 

Hi Robert,

 

Can you please open a GitHub issue and assign it to @jhedberg ?

 

Thanks,

 

Carles

 

From: devel@... <devel@...> On Behalf Of robert.konc@...
Sent: 27 November 2018 14:56
To: devel@...
Subject: [Zephyr-devel] Ble mesh stack not compatilbe with c++ #ble #bluetoothmesh

 

Hi,

When could we expect that blemesh code will be usable in c++.
Most header files in zephyr are compatible with c++ but not ble mesh headers.
No #ifdef __cplusplus in headers.

Regards,
Robert
Re: Suggestions on rpl_border_router and rpl_node #bluetoothmesh #nrf52480 #nrf52832 #zephyrbluetoothmesh

Ravi kumar Veeramally
 

Hi Akash,

Look the at the hardware information and setup procedure in

"samples/net/rpl_border_router/README.rst".

- Ravi

On 12/7/18 12:14 PM, Akash Naidu wrote:

Hi All,

I have been working on ipv6 over ble on zephyr RTOS to form mesh network.I have been successfully integrated "rpl_node"(which is in zephyr/samples/net/rpl_node) with ble(nrf52832), and it has been able to connected and able to getting the response(if i ping).

Now, i am in quite confusion for how to use "rpl_border_router"(which is in zephyr/samples/net/rpl_border_router).

which board is suitable to configure it as a rpl_border_router?.

I have 5 nrf52 modules which will acts as "rpl_nodes", but how to connect these boards to "rpl_border_router" to form DAG network?

could you please suggest me that how to form DAG Network by using "rpl_border_router" and "rpl_node" on Zephyr RTOS?

I am totally new to network concepts, if possible please provide some useful documents where i can form the DAG network by using RPL protocol.

 

Advance in thanks.

 

BR

Akash. 

Re: Suggestions on rpl_border_router and rpl_node #bluetoothmesh #nrf52480 #nrf52832 #zephyrbluetoothmesh

Serafin
 

Hi


There is a platform_whitelist in the sample.yaml file. In your case:

"platform_whitelist: frdm_k64f "


So you need this nxp board or have to port the sample to another board.


Greetings

Serafin


On 07/12/2018 11:14, Akash Naidu wrote:

Hi All,

I have been working on ipv6 over ble on zephyr RTOS to form mesh network.I have been successfully integrated "rpl_node"(which is in zephyr/samples/net/rpl_node) with ble(nrf52832), and it has been able to connected and able to getting the response(if i ping).

Now, i am in quite confusion for how to use "rpl_border_router"(which is in zephyr/samples/net/rpl_border_router).

which board is suitable to configure it as a rpl_border_router?.

I have 5 nrf52 modules which will acts as "rpl_nodes", but how to connect these boards to "rpl_border_router" to form DAG network?

could you please suggest me that how to form DAG Network by using "rpl_border_router" and "rpl_node" on Zephyr RTOS?

I am totally new to network concepts, if possible please provide some useful documents where i can form the DAG network by using RPL protocol.

 

Advance in thanks.

 

BR

Akash. 

2661 - 2680 of 8204