Kumar, This is currently being worked on. There is an issue with the host OS where the yocto build is not completing the build. Anas

Are there continuous builds of the SDK in jenkins? Not seeing anything and was hoping to grab a “nightly” snapshot out of there. - k

NEW JIRA items within last 24 hours: 0 UPDATED JIRA items within last 24 hours: 4 [ZEP-67] building a Zephyr app out of tree puts some files in wrong place

NEW within last 24 hours: - https://gerrit.zephyrproject.org/r/1994 : sensors: add driver for DHTxx sensors - https://gerrit.zephyrproject.org/r/1993 : drivers/nble: Add timeout before Conn Param

I had a recent need to explain in detail the x86 IRQ implementation to some colleagues working on Quark CPUs, and wrote this document. Eventually I would like to clean this up, discuss other arches,

NEW within last 24 hours: - https://gerrit.zephyrproject.org/r/1971 : Bluetooth: L2CAP: Refactor l2cap_chan_get() in l2cap.c - https://gerrit.zephyrproject.org/r/1951 : Bluetooth: L2CAP: Introduce

Hi David, Try to activate some debugging in the cc2520 driver first. Set CONFIG_TI_CC2520_DEBUG=y in your projects conf file. If that shows that network packets are not sent, then you can start

Hi sir, I am porting cc2520 driver to arduino_due board, when sending udp packet over cc2520. the packet is never transmitted by cc2520 driver. I don't know if cc2520 driver has run correctly on any

Hi Vlad, Not sure in what context you are taking this, the workqueue and work should be 2 different objects, the workqueue object may or may not carry its fiber_config depending if you want to share

NEW JIRA items within last 24 hours: 6 [ZEP-295] Consolidate and simplify GPIO driver configuration options https://jira.zephyrproject.org/browse/ZEP-295 [ZEP-294] Consolidate and simplify SPI

NEW within last 24 hours: - https://gerrit.zephyrproject.org/r/1949 : Bluetooth: Use tinycrypt for ecc in LE SC only sample - https://gerrit.zephyrproject.org/r/1948 : Bluetooth: SMP: Reduce stack

I'll wait for your implementation before commenting more, but yes, the only thing that I saw was similar between the two was that the fiber could be shared, and of course, that means that both the

I have posted another version of the patches on Gerrit. The only major change is that I've added another test, as Luiz suggested. I see architectural comments are rather favorable so I won't post

I'm not sure that helps in the bigger picture (although I admit I had overlooked this possibility when I first asked you the question :]). Consider the case where we have multiple instances of the

Hi Ben, <benjamin.walsh(a)windriver.com> wrote: Actually submitting work with a fifo is pretty similar, the delayed version will probably only need a _nano_timeout and the workqueue pointer so we can

NEW JIRA items within last 24 hours: 1 [ZEP-291] Driver for the ENC28J60 ethernet device https://jira.zephyrproject.org/browse/ZEP-291 UPDATED JIRA items within last 24 hours: 0 CLOSED JIRA

OK, but I don't think the two implementations will share much except the system fiber that the callbacks will run in. There is not much that is similar between your callout implementation and the

NEW within last 24 hours: - https://gerrit.zephyrproject.org/r/1936 : doc: use table for Kconfig option reference - https://gerrit.zephyrproject.org/r/1935 : Bluetooth: Fix NULL dereference -

Hi Vlad, Just have it in a super struct: struct config { struct fiber_config fg; char __stack[STACK_SIZE]; } I didn't say you have to change there, but it seems this is wrong there as well

Hi Vlad, I guess it would be wise to add tests for submitting work from both fiber and task, it appear this is only done for a task. Also it is super important that submitting work from the handler