|
zephyr thread
Florian Fouillet <Florian.Fouillet@...>
Hi everyone,
I am currently working on the Zephyr OS with a FDRM_K64f board from NXP.
To create thread I was first using K_THREAD_DEFINE.
I want to create an abstraction layer if I need to use different OS (a platform with generic definition for thread) so I won't have to modify the source code.
Since I can't call K_THREAD_DEFINE inside a function (I was ending up with an error). I am trying to use k_thread_create.
It's working when I create 1 thread but I have error as soon as I am trying to create multiple one.
Here for example I am creating 2 threads:
struct k_thread thread1 ; k_thread_stack_t threadStack1 ;
struct k_thread thread2 ; k_thread_stack_t threadStack2 ;
k_thread_create(&thread1, & threadStack1, 1024, (void*)DL_StateMachine_ModeHandler, NULL, NULL, NULL, 7, 0, K_NO_WAIT); k_thread_create(&thread2, & threadStack2, 1024, (void*)DL_StateMachine_MsgHandler, NULL, NULL, NULL, 7, 0, K_NO_WAIT);
it compiles but then when I am trying to execute it I have the following issue:
Does anyone know how to correctly use the k_thread_create? My other question is, what’s k_thread_stack_t and what to do with it?
Thank you,
|
|
|
|
swapnil <swapnil2007kadam@...>
Hello, In order to use the peripheral and central device for energy efficient application, I performed some power measurement test with the following configuration using nrf52 DK. Central_hr sample application is used as it is without making any changes. In Peripheral_hr sample application notification time is changed to 1 sec. In menuconfig : · Device drivers: o Console drivers o Serial drivers o GPIO drivers o Use legacy SPI API are disabled · Debugging Options: everything is disabled · Bluetooth: none of the debug option is enabled
The average Current consumption on Peripheral device is 390 μA and average power consumption is 1.31mW with 3.35 V source.
Once the peripheral starts notifying, there are continuous spikes in the measurements between 2 notifications. I also checked with different connection intervals and different notification periods but still, there are same spikes.
|
|
|
|
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
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, 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
|
|
|
|
Re: Opus codec on nrf52840
nicolas lantz
Hello,
toggle quoted messageShow quoted text
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 :
|
|
|
|
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
|
|
|
|
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,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 alsoIMHO before we provide a replacement, we should not deprecate anything. The new HTTP APIs could also beI 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 pleaseSo, 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. [] -- 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
Hi Martin,
On 12 Dec 2018, at 14.42, Martin <ma@jgs-wg.de> wrote: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:
There is no requirement to copy the data, but usually, usb device drivers copy the data to the controller FIFO.
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).
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
|
|
|
|
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
|
|
|
|
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,
|
|
|
