|
west and (no) data loss, was: Re: [Zephyr-users] Do not use west v0.6.1; upgrade to v0.6.2
Paul Sokolovsky
Hello Marti,
On Wed, 4 Sep 2019 16:39:22 +0000 "Bolivar, Marti" <marti.bolivar@nordicsemi.no> wrote: Marti Bolivar <marti.bolivar@nordicsemi.no> writes:Hi, Speaking of data loss... I figure I have local changes in modules managed (stroked thru) initially checked out by west. Can west be trusted: 1) To never touch those changes during normal development process, i.e. building and running apps? 2) To likewise never overwrite those changes on "west update"? I guess it boils down to questions: a) "Is it true that west never tries to perform any unattended module updates, and does that only if explicitly asked (west update)" and b) "Is it true that west, when asked to update modules, doesn't run any workcopy-destructive commands, like git reset, some forms of git checkout; or, if it does, it first performs (regression-tested) check for local changes in the corresponding modules ?" Thanks. [] -- 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
|
|
|
|
Video 4 Zephyr - call for reviews
Loic Poulain
Hi all, This pull request introduces a generic Video API, highly inspired by existing API/frameworks like V4L2, gstreamer, and OpenMAX. A video device can be a video capture device (e.g. camera) a memory-to-memory device (e.g. encoder) or an output device (e.g. display). The main operation consists of enqueuing and dequeuing video buffer(s) to video device's endpoint(s). The video buffer can then be filled (capture), or consumed (output) depending endpoint type. The API is designed for 'zero-copy' and easy pipeline creation (e.g. camera->encoder->display). In order to keep the API simple but scalable, each video device can implement video 'controls' identified by control-id (CID) which can either be video generic, class generic (camera, encoder...) or vendor/device specific. This PR adds the definition of the API, support for NXP MCUX CSI (CMOS sensor interface) and MT9M114 sensor. Allowing to capture frames with the mimxrt1064-evk board. For testing purpose, It also adds a software pattern generator which outputs a static colorbar pattern. Two samples have been implemented, a simple 'capture' sample counting captured frame from any available video device and a 'tcpserversink' sample forwarding captured frames to a TCP client, which can then display the frames with e.g. gstreamer. Regards, Loic
|
|
|
|
why the reschrdule not permitted if lock key nested ?
"曹子龙
HI guys: in kerne impl. many scenarios would call the z_reschedule to yield volunteer if the thread`s resource request did not meets. but the "resched" condition check confuse me, it seems only the case that the l"z_arch_irq_unlocked" is true, which means the previous irq lock status is unlock, can the schedule be permitted. in this case, the irq lock depth only 1 is permitted. but Why design like this, in many rtos impl. the voluteer yield operation can happen without care bout how depth the lock level, why zephyr need care about this? static inline int resched(u32_t key) |- { |- #ifdef CONFIG_SMP |- if (!_current_cpu->swap_ok) { |- return 0; |- } |- _current_cpu->swap_ok = 0; | #endif | | return z_arch_irq_unlocked(key) && !z_is_in_isr(); | } | | void z_reschedule(struct k_spinlock *lock, k_spinlock_key_t key) | { |- if (resched(key.key)) { |- z_swap(lock, key); |- } else { |- k_spin_unlock(lock, key); |- } |- } |- 曹子龙 珠海全志科技股份有限公司 BU1-PSW 地址：广东省珠海市高新区唐家湾镇科技2路9号 TEL：13824125580 Email：caozilong@... 网址： http://www.allwinnertech.com
|
|
|
|
Re: OpenThread development guide
Lubos, Robert
Hi Arun,
I’m afraid I’m not in the position to make any statements about OpenThread integration roadmap at this point.
Regards, Robert
From: Benjamin Lindqvist [mailto:benjamin.lindqvist@...]
Sent: Friday, September 6, 2019 08:46 To: Arun Kumar <arun.ece.nitp@...> Cc: Lubos, Robert <Robert.Lubos@...>; devel@... Subject: Re: [Zephyr-devel] OpenThread development guide
Hi Arun,
The NCP should probably not be high in the list of priorities - I doubt it makes a huge difference for the infrastructure that the NCP was compiled from some Nordic SDK or whatever.
This is just the opinion from a Thread non-expert but what I feel should be prioritized is making sure there's plenty of clean samples and good documentation. It would be nice with an actual Zephyr control interface as well, possibly utilizing the IFUP/IFDOWN signaling mechanisms, options for delaying Thread initialization until credentials are added and of course an API for altering the credentials.
On Fri, Sep 6, 2019 at 8:37 AM Arun Kumar <arun.ece.nitp@...> wrote:
|
|
|
|
Re: OpenThread development guide
Hi Benjamin, I agree with you about priorities and all. I was looking of an overall road map for further developments around openthread and zephyr. As Robert mentioned the lack of resources, i was thinking of contributing into that. So, it would be a bit easy if there will be a clear road map.
On Fri, Sep 6, 2019 at 12:16 PM Benjamin Lindqvist <benjamin.lindqvist@...> wrote:
--
Arun kumar Software Engineer Contact: +91-8877229320 Email: arun.ece.nitp@... Linkedin: https://www.linkedin.com/in/arunkumar31/
|
|
|
|
Re: OpenThread development guide
Benjamin Lindqvist
Hi Arun, The NCP should probably not be high in the list of priorities - I doubt it makes a huge difference for the infrastructure that the NCP was compiled from some Nordic SDK or whatever. This is just the opinion from a Thread non-expert but what I feel should be prioritized is making sure there's plenty of clean samples and good documentation. It would be nice with an actual Zephyr control interface as well, possibly utilizing the IFUP/IFDOWN signaling mechanisms, options for delaying Thread initialization until credentials are added and of course an API for altering the credentials.
On Fri, Sep 6, 2019 at 8:37 AM Arun Kumar <arun.ece.nitp@...> wrote:
|
|
|
|
Re: OpenThread development guide
Hi Robert, Do we have clear road map for openthread integration in zephyr (I mean integration of NCP like things we are lacking so far) ? with regards,
On Mon, Sep 2, 2019 at 4:21 PM Lubos, Robert <robert.lubos@...> wrote:
--
Arun kumar Bachelor of Technology Electronics & Communication Engineering Nit Patna Contact: +91-8877229320 Email: arun.ece.nitp@... Linkedin: https://www.linkedin.com/in/arunkumar31/
|
|
|
|
Re: How to build external drivers
Bolivar, Marti
Joris Offouga <offougajoris@gmail.com> writes:
Le 05/09/2019 à 19:24, Bolivar, Marti a écrit :Great! Glad it helped."Joris Offouga via Lists.Zephyrproject.Org"Hi Marti,
|
|
|
|
Re: How to build external drivers
Le 05/09/2019 à 19:24, Bolivar, Marti a écrit :
"Joris Offouga via Lists.Zephyrproject.Org"Hi Marti, Thanks for your help, I was inspired by the nrf repo and I could build my driver. Best Regards, Joris Offouga Best regards, -- Best Regards, Joris Offouga
|
|
|
|
Re: How to build external drivers
Bolivar, Marti
"Joris Offouga via Lists.Zephyrproject.Org"
<offougajoris=gmail.com@lists.zephyrproject.org> writes: Hi all,Just a couple of notes: - the board doesn't have to be specified twice - the default source directory is the current working directory So this could be written a bit more simply as: $ west build -b board_name -- -DBOARD_ROOT=<path_to_board> This is supported: https://github.com/zephyrproject-rtos/zephyr/issues/8379 As far as I can tell, there's nothing to do. For example, the downstream nrf repository has out of tree drivers in its drivers/ directory: https://github.com/NordicPlayground/fw-nrfconnect-nrf This supports building applications with west build out of the box. E.g. you can build nrf/applications/nrf_desktop with an out of tree board, using the out of tree pmw3360 driver, with: west build -b nrf52840_pca20041 -- -DBOARD_ROOT=$HOME/ncs/nrf (The BOARD_ROOT is not strictly necessary here because of some magic in the nrf build system, but it doesn't hurt so I've put it in for your reference.) Please note that if you're going to try to replicate this exact example yourself, you need to create a separate west installation using the downstream getting started guide: https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrf/getting_started.html Otherwise, hopefully it's a starting point for you. Best, Marti
|
|
|
|
Re: How to build external drivers
Hi Sebastian,
toggle quoted messageShow quoted text
Thanks for your quick reply, does it have to have a specific folder structure like for boards too? If yes which one ?
Le 05/09/2019 à 17:44, Bøe, Sebastian a écrit :
Yes, --
Best Regards, Joris Offouga
|
|
|
|
Re: How to build external drivers
Sebastian Boe
Yes,
you can add out-of-tree directories that contain CMakeLists.txt files that define zephyr libraries (like drivers), by doing west build -b board_name . -- -DZEPHYR_EXTRA_MODULES<path_to_driver> ________________________________________ From: devel@lists.zephyrproject.org <devel@lists.zephyrproject.org> on behalf of Joris Offouga via Lists.Zephyrproject.Org <offougajoris=gmail.com@lists.zephyrproject.org> Sent: Thursday, September 5, 2019 5:39:37 PM To: devel@lists.zephyrproject.org Cc: devel@lists.zephyrproject.org Subject: [Zephyr-devel] How to build external drivers Hi all, How to build external drivers with zephyr, like board with example : west build -b board_name . -- -DBOARD=board_name -DBOARD_ROOT=<path_to_board>. is there a similar command for drivers? Best regards, Joris Offouga -- Best Regards, Joris Offouga
|
|
|
|
How to build external drivers
Hi all,
How to build external drivers with zephyr, like board with example : west build -b board_name . -- -DBOARD=board_name -DBOARD_ROOT=<path_to_board>. is there a similar command for drivers? Best regards, Joris Offouga -- Best Regards, Joris Offouga
|
|
|
|
Re: Dev-Review Meeting Agenda (Sept 5)
Peter A. Bigot
Discussing individual issues doesn't seem like an effective use of time, though discussing how issue assessments can be done offline and reviewed in summary form might be helpful.
But I'd like to get an understanding of what's going to be in 2.1 first. E.g. updated GPIO is, updated controlled delay (timeout) API is. Pinmux? Other API changes? Devicetree improvements? Knowing the overall vision of how 2.1 improves the life of Zephyr users would impact what issues and existing PRs should be dusted off in order to reach that goal. Peter
|
|
|
|
Upcoming Event: Zephyr Project: Dev Meeting - Thu, 09/05/2019 8:00am-9:00am, Please RSVP
#cal-reminder
devel@lists.zephyrproject.org Calendar <devel@...>
Reminder: Zephyr Project: Dev Meeting When: Thursday, 5 September 2019, 8:00am to 9:00am, (GMT-07:00) America/Los Angeles Where:https://zoom.us/j/993312203 An RSVP is requested. Click here to RSVP Organizer: devel@... Description: Join Zoom Meeting
|
|
|
|
Re: NRF52810
Miguel Wisintainer <tcpipchip@...>
It can run on SKYLAB VG01
De: Miguel Wisintainer <tcpipchip@...>
Enviado: quarta-feira, 4 de setembro de 2019 21:37 Para: Bolivar, Marti <Marti.Bolivar@...>; Brett Preston <bpreston@...>; devel@... <devel@...> Assunto: RE: [Zephyr-devel] NRF52810
Solved tks!
De: Bolivar, Marti <Marti.Bolivar@...>
Enviado: quarta-feira, 4 de setembro de 2019 20:30 Para: tcpipchip@... <tcpipchip@...>; Brett Preston <bpreston@...>; devel@... <devel@...> Cc: devel@... <devel@...> Assunto: Re: [Zephyr-devel] NRF52810 Hi,
" via Lists.Zephyrproject.Org" <tcpipchip=hotmail.com@...> writes: > Thank you Preston > > See attached team It looks like Carles helped you out on Slack and your question was answered. (Posting this just to track the status on this for people only watching the ML.) Marti > > After i compile successfully the beacon sample, i tried to burn with J-LINK to NRF52810 and nothing is detected in my scanner! > > [cid:4cf00658-f2bb-40c7-88b4-f51242b96dec] > I choose the HEX > > Is there anything else that i forgot ? > > It´s a SKYLAB VG01 beacon that i am replacing the code! > > Thank you so much! > > > ________________________________ > De: Brett Preston <bpreston@...> > Enviado: quarta-feira, 4 de setembro de 2019 17:12 > Para: tcpipchip@... <tcpipchip@...> > Cc: Team <info@...> > Assunto: Re: New submission from Contact Us > > Hi Miguel, > > Please direct technical questions for Zephyr to devel@...<mailto:devel@...> > > Thank you, > > > Brett > > On Wed, Sep 4, 2019 at 10:09 AM Zephyr Project - General Contact Form <webmaster@...<mailto:webmaster@...>> wrote: > Name > Miguel Wisintainer > tcpipchip@...<mailto:tcpipchip@...> > Comment > Sir, > Did you test Zephyr on NRF52810 ? > Does it works ? > I am testing on Beacon example! Btw, will i need to use a softdevice (wich version) ? Or not necessary! > Thanks! > > > -- > Brett Preston > Sr. Program Manager > The Linux Foundation > +1 (971) 303-9030 > bpreston@...<mailto:bpreston@...> > > >
|
|
|
|
Re: NRF52810
Miguel Wisintainer <tcpipchip@...>
Solved tks!
De: Bolivar, Marti <Marti.Bolivar@...>
Enviado: quarta-feira, 4 de setembro de 2019 20:30 Para: tcpipchip@... <tcpipchip@...>; Brett Preston <bpreston@...>; devel@... <devel@...> Cc: devel@... <devel@...> Assunto: Re: [Zephyr-devel] NRF52810 Hi,
" via Lists.Zephyrproject.Org" <tcpipchip=hotmail.com@...> writes: > Thank you Preston > > See attached team It looks like Carles helped you out on Slack and your question was answered. (Posting this just to track the status on this for people only watching the ML.) Marti > > After i compile successfully the beacon sample, i tried to burn with J-LINK to NRF52810 and nothing is detected in my scanner! > > [cid:4cf00658-f2bb-40c7-88b4-f51242b96dec] > I choose the HEX > > Is there anything else that i forgot ? > > It´s a SKYLAB VG01 beacon that i am replacing the code! > > Thank you so much! > > > ________________________________ > De: Brett Preston <bpreston@...> > Enviado: quarta-feira, 4 de setembro de 2019 17:12 > Para: tcpipchip@... <tcpipchip@...> > Cc: Team <info@...> > Assunto: Re: New submission from Contact Us > > Hi Miguel, > > Please direct technical questions for Zephyr to devel@...<mailto:devel@...> > > Thank you, > > > Brett > > On Wed, Sep 4, 2019 at 10:09 AM Zephyr Project - General Contact Form <webmaster@...<mailto:webmaster@...>> wrote: > Name > Miguel Wisintainer > tcpipchip@...<mailto:tcpipchip@...> > Comment > Sir, > Did you test Zephyr on NRF52810 ? > Does it works ? > I am testing on Beacon example! Btw, will i need to use a softdevice (wich version) ? Or not necessary! > Thanks! > > > -- > Brett Preston > Sr. Program Manager > The Linux Foundation > +1 (971) 303-9030 > bpreston@...<mailto:bpreston@...> > > >
|
|
|
|
Dev-Review Meeting Agenda (Sept 5)
Kumar Gala
This week we are going to use the dev-review meeting to work on the backlog of issues/enhancements/feature requests.
The idea here is to triage issues, close out one’s that we aren’t going to handle, try and see if there are some common areas we need to focus on for the 2.1 release. I’ve asked Maureen to lead the call as I will not be able to make it. Thanks - k
|
|
|
|
Re: NRF52810
Bolivar, Marti
Hi,
" via Lists.Zephyrproject.Org" <tcpipchip=hotmail.com@lists.zephyrproject.org> writes: Thank you PrestonIt looks like Carles helped you out on Slack and your question was answered. (Posting this just to track the status on this for people only watching the ML.) Marti
|
|
|
|
Re: Do not use west v0.6.1; upgrade to v0.6.2
Marc Herbert
it seems extremely serious, considering that west basically has one job (versioning).One of those jobs that everyone needs but no one wants to do? PS: versioning plus a bit more https://docs.zephyrproject.org/latest/guides/west/why.html
|
|
|
