Date   

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:

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:

Hi Benjamin,

 

Sorry for late reply, I’ve just came back from holiday. See my responses inline.

 

Regards,

Robert

 

From: devel@... [mailto:devel@...] On Behalf Of Benjamin Lindqvist via Lists.Zephyrproject.Org
Sent: Tuesday, August 27, 2019 13:31
To: devel@...
Cc: devel@...
Subject: [Zephyr-devel] OpenThread development guide

 

Hi,

 

I've verified basic OT functionality using the echo_client/server samples with the openthread overlays. That's nice, but it's not obvious to me how I proceed after this. A few things that had me confused:

 

- how do I configure my Zephyr device as a sleepy end device?

 

It is not possible to configure Sleepy End Device on current master, there is a PR that adds this functionality though (https://github.com/zephyrproject-rtos/zephyr/pull/15552). It’s been open for some time now, feel free to comment in there if it’s a desired feature for you.

 

- can I setup my west.yml to clone openthread + dependencies as a module to prevent cmake from doing it at build every time?

 

This has already been done recently, make sure to check out the current master. West will now download OpenThread for you as a Zephyr module, and use it during OT samples builds.

 

- can I modify the network credentials at run-time? Or in other words, does Zephyr support anything but hardcoded OT commissioning?

 

Zephyr supports two ways of obtaining network credentials (commissioning):

  1. Use a preconfigured, hardcoded defaults, specified by Kconfig (good for samples, not really for real applications),
  2. Or perform a commissioning procedure defined by Thread specification during startup (see CONFIG_OPENTHREAD_JOINER_AUTOSTART option).

 

Both methods will configure your device during initial startup, and store network parameters in the flash. If, for whatever reason, you’d want to modify the network credentials afterwards, you’d need to call OpenThread API directly, there’s no support in Zephyr for that. See https://github.com/zephyrproject-rtos/openthread/blob/0dbecf508e7a79aae8ed9631f1a63fc65478b213/include/openthread/thread.h#L393 for available API functions. Just note, that in order to use OT API directly, you’d need to obtain OT context first from the OT network interface.

 

- can I build NCP firmware for a border router using Zephyr?

 

No, Zephyr cannot be configured as a NCP. For a NCP application, check the OpenThread repository.

 

etc. Right now I get the impression that the openthread integration is in a sort of proof-of-concept stage. Is this the case? If not, it would be nice with some more documentation, perhaps even a sample app...

 

Well, for sure I’d not call it a proof-of-concept at this point, yet indeed there’s still work to do. Lack of time/resources to push it forward is the only answer I can provide for now.


 

--

Arun kumar

Bachelor of Technology

Electronics & Communication Engineering

Nit Patna

Contact: +91-8877229320

Email: arun.ece.nitp@...

Linkedinhttps://www.linkedin.com/in/arunkumar31/


Re: OpenThread development guide

Arun kumar
 

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

Hi Benjamin,

 

Sorry for late reply, I’ve just came back from holiday. See my responses inline.

 

Regards,

Robert

 

From: devel@... [mailto:devel@...] On Behalf Of Benjamin Lindqvist via Lists.Zephyrproject.Org
Sent: Tuesday, August 27, 2019 13:31
To: devel@...
Cc: devel@...
Subject: [Zephyr-devel] OpenThread development guide

 

Hi,

 

I've verified basic OT functionality using the echo_client/server samples with the openthread overlays. That's nice, but it's not obvious to me how I proceed after this. A few things that had me confused:

 

- how do I configure my Zephyr device as a sleepy end device?

 

It is not possible to configure Sleepy End Device on current master, there is a PR that adds this functionality though (https://github.com/zephyrproject-rtos/zephyr/pull/15552). It’s been open for some time now, feel free to comment in there if it’s a desired feature for you.

 

- can I setup my west.yml to clone openthread + dependencies as a module to prevent cmake from doing it at build every time?

 

This has already been done recently, make sure to check out the current master. West will now download OpenThread for you as a Zephyr module, and use it during OT samples builds.

 

- can I modify the network credentials at run-time? Or in other words, does Zephyr support anything but hardcoded OT commissioning?

 

Zephyr supports two ways of obtaining network credentials (commissioning):

  1. Use a preconfigured, hardcoded defaults, specified by Kconfig (good for samples, not really for real applications),
  2. Or perform a commissioning procedure defined by Thread specification during startup (see CONFIG_OPENTHREAD_JOINER_AUTOSTART option).

 

Both methods will configure your device during initial startup, and store network parameters in the flash. If, for whatever reason, you’d want to modify the network credentials afterwards, you’d need to call OpenThread API directly, there’s no support in Zephyr for that. See https://github.com/zephyrproject-rtos/openthread/blob/0dbecf508e7a79aae8ed9631f1a63fc65478b213/include/openthread/thread.h#L393 for available API functions. Just note, that in order to use OT API directly, you’d need to obtain OT context first from the OT network interface.

 

- can I build NCP firmware for a border router using Zephyr?

 

No, Zephyr cannot be configured as a NCP. For a NCP application, check the OpenThread repository.

 

etc. Right now I get the impression that the openthread integration is in a sort of proof-of-concept stage. Is this the case? If not, it would be nice with some more documentation, perhaps even a sample app...

 

Well, for sure I’d not call it a proof-of-concept at this point, yet indeed there’s still work to do. Lack of time/resources to push it forward is the only answer I can provide for now.



--

Arun kumar

Bachelor of Technology

Electronics & Communication Engineering

Nit Patna

Contact: +91-8877229320

Email: arun.ece.nitp@...

Linkedinhttps://www.linkedin.com/in/arunkumar31/



--

Arun kumar

Software Engineer

Contact: +91-8877229320

Email: arun.ece.nitp@...

Linkedinhttps://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:
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:

Hi Benjamin,

 

Sorry for late reply, I’ve just came back from holiday. See my responses inline.

 

Regards,

Robert

 

From: devel@... [mailto:devel@...] On Behalf Of Benjamin Lindqvist via Lists.Zephyrproject.Org
Sent: Tuesday, August 27, 2019 13:31
To: devel@...
Cc: devel@...
Subject: [Zephyr-devel] OpenThread development guide

 

Hi,

 

I've verified basic OT functionality using the echo_client/server samples with the openthread overlays. That's nice, but it's not obvious to me how I proceed after this. A few things that had me confused:

 

- how do I configure my Zephyr device as a sleepy end device?

 

It is not possible to configure Sleepy End Device on current master, there is a PR that adds this functionality though (https://github.com/zephyrproject-rtos/zephyr/pull/15552). It’s been open for some time now, feel free to comment in there if it’s a desired feature for you.

 

- can I setup my west.yml to clone openthread + dependencies as a module to prevent cmake from doing it at build every time?

 

This has already been done recently, make sure to check out the current master. West will now download OpenThread for you as a Zephyr module, and use it during OT samples builds.

 

- can I modify the network credentials at run-time? Or in other words, does Zephyr support anything but hardcoded OT commissioning?

 

Zephyr supports two ways of obtaining network credentials (commissioning):

  1. Use a preconfigured, hardcoded defaults, specified by Kconfig (good for samples, not really for real applications),
  2. Or perform a commissioning procedure defined by Thread specification during startup (see CONFIG_OPENTHREAD_JOINER_AUTOSTART option).

 

Both methods will configure your device during initial startup, and store network parameters in the flash. If, for whatever reason, you’d want to modify the network credentials afterwards, you’d need to call OpenThread API directly, there’s no support in Zephyr for that. See https://github.com/zephyrproject-rtos/openthread/blob/0dbecf508e7a79aae8ed9631f1a63fc65478b213/include/openthread/thread.h#L393 for available API functions. Just note, that in order to use OT API directly, you’d need to obtain OT context first from the OT network interface.

 

- can I build NCP firmware for a border router using Zephyr?

 

No, Zephyr cannot be configured as a NCP. For a NCP application, check the OpenThread repository.

 

etc. Right now I get the impression that the openthread integration is in a sort of proof-of-concept stage. Is this the case? If not, it would be nice with some more documentation, perhaps even a sample app...

 

Well, for sure I’d not call it a proof-of-concept at this point, yet indeed there’s still work to do. Lack of time/resources to push it forward is the only answer I can provide for now.



--

Arun kumar

Bachelor of Technology

Electronics & Communication Engineering

Nit Patna

Contact: +91-8877229320

Email: arun.ece.nitp@...

Linkedinhttps://www.linkedin.com/in/arunkumar31/


Re: OpenThread development guide

Arun kumar
 

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:

Hi Benjamin,

 

Sorry for late reply, I’ve just came back from holiday. See my responses inline.

 

Regards,

Robert

 

From: devel@... [mailto:devel@...] On Behalf Of Benjamin Lindqvist via Lists.Zephyrproject.Org
Sent: Tuesday, August 27, 2019 13:31
To: devel@...
Cc: devel@...
Subject: [Zephyr-devel] OpenThread development guide

 

Hi,

 

I've verified basic OT functionality using the echo_client/server samples with the openthread overlays. That's nice, but it's not obvious to me how I proceed after this. A few things that had me confused:

 

- how do I configure my Zephyr device as a sleepy end device?

 

It is not possible to configure Sleepy End Device on current master, there is a PR that adds this functionality though (https://github.com/zephyrproject-rtos/zephyr/pull/15552). It’s been open for some time now, feel free to comment in there if it’s a desired feature for you.

 

- can I setup my west.yml to clone openthread + dependencies as a module to prevent cmake from doing it at build every time?

 

This has already been done recently, make sure to check out the current master. West will now download OpenThread for you as a Zephyr module, and use it during OT samples builds.

 

- can I modify the network credentials at run-time? Or in other words, does Zephyr support anything but hardcoded OT commissioning?

 

Zephyr supports two ways of obtaining network credentials (commissioning):

  1. Use a preconfigured, hardcoded defaults, specified by Kconfig (good for samples, not really for real applications),
  2. Or perform a commissioning procedure defined by Thread specification during startup (see CONFIG_OPENTHREAD_JOINER_AUTOSTART option).

 

Both methods will configure your device during initial startup, and store network parameters in the flash. If, for whatever reason, you’d want to modify the network credentials afterwards, you’d need to call OpenThread API directly, there’s no support in Zephyr for that. See https://github.com/zephyrproject-rtos/openthread/blob/0dbecf508e7a79aae8ed9631f1a63fc65478b213/include/openthread/thread.h#L393 for available API functions. Just note, that in order to use OT API directly, you’d need to obtain OT context first from the OT network interface.

 

- can I build NCP firmware for a border router using Zephyr?

 

No, Zephyr cannot be configured as a NCP. For a NCP application, check the OpenThread repository.

 

etc. Right now I get the impression that the openthread integration is in a sort of proof-of-concept stage. Is this the case? If not, it would be nice with some more documentation, perhaps even a sample app...

 

Well, for sure I’d not call it a proof-of-concept at this point, yet indeed there’s still work to do. Lack of time/resources to push it forward is the only answer I can provide for now.



--

Arun kumar

Bachelor of Technology

Electronics & Communication Engineering

Nit Patna

Contact: +91-8877229320

Email: arun.ece.nitp@...

Linkedinhttps://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 :
"Joris Offouga via Lists.Zephyrproject.Org"
<offougajoris=gmail.com@lists.zephyrproject.org> writes:
Hi Marti,

Thanks for your help, I was inspired by the nrf repo and I could build
my driver.

Best Regards,

Joris Offouga
Great! Glad it helped.


Re: How to build external drivers

Joris Offouga
 

Le 05/09/2019 à 19:24, Bolivar, Marti a écrit :
"Joris Offouga via Lists.Zephyrproject.Org"
<offougajoris=gmail.com@lists.zephyrproject.org> writes:

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

is there a similar command for drivers?
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
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,

Joris Offouga



--
Best Regards,

Joris Offouga


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

How to build external drivers with zephyr, like board with example :
west build -b board_name . -- -DBOARD=board_name
-DBOARD_ROOT=<path_to_board>.
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>


is there a similar command for drivers?
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


Best regards,

Joris Offouga



--
Best Regards,

Joris Offouga


Re: How to build external drivers

Joris Offouga
 

Hi Sebastian,

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,

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

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

Joris Offouga
 

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
https://zoom.us/j/993312203

One tap mobile
+16699006833,,993312203# US (San Jose)
+16465588656,,993312203# US (New York)

Dial by your location
        +1 669 900 6833 US (San Jose)
        +1 646 558 8656 US (New York)
        +1 877 369 0926 US Toll-free
        +1 855 880 1246 US Toll-free
Meeting ID: 993 312 203
Find your local number: https://zoom.us/u/ankEMRagf


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
> Email
>         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@...>
>
>
>

Livre de vírus. www.avast.com.


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
> Email
>         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@...>
>
>
>

Livre de vírus. www.avast.com.


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 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@linuxfoundation.org>
Enviado: quarta-feira, 4 de setembro de 2019 17:12
Para: tcpipchip@hotmail.com <tcpipchip@hotmail.com>
Cc: Team <info@zephyrproject.org>
Assunto: Re: New submission from Contact Us

Hi Miguel,

Please direct technical questions for Zephyr to devel@lists.zephyrproject.org<mailto:devel@lists.zephyrproject.org>

Thank you,


Brett

On Wed, Sep 4, 2019 at 10:09 AM Zephyr Project - General Contact Form <webmaster@lfprojects.linuxfoundation.org<mailto:webmaster@lfprojects.linuxfoundation.org>> wrote:
Name
Miguel Wisintainer
Email
tcpipchip@hotmail.com<mailto:tcpipchip@hotmail.com>
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@linuxfoundation.org<mailto:bpreston@linuxfoundation.org>



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


NRF52810

Miguel Wisintainer <tcpipchip@...>
 

Thank you Preston

See attached team

After i compile successfully the beacon sample, i tried to burn with J-LINK to NRF52810  and nothing is detected in my scanner!


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

Thank you,


Brett

On Wed, Sep 4, 2019 at 10:09 AM Zephyr Project - General Contact Form <webmaster@...> wrote:
Name
  Miguel Wisintainer
Email
  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


Re: Do not use west v0.6.1; upgrade to v0.6.2

Bolivar, Marti
 

"Youse, Charles via Lists.Zephyrproject.Org"
<charles.youse=intel.com@lists.zephyrproject.org> writes:

Hi Marti,

In spite of the fact that it doesn't cause data loss, it seems
extremely serious, considering that west basically has one job
(versioning).
I agree that it is a serious bug (see "high impact", below), and again,
I'm sorry for the lack of test coverage that led to it happening in the
first place. I'm grateful to the reporter for bringing it up.

Now that the hotfix is out in the 0.6.x branch, I'm going to be adding
regression testing. I do my best to make sure fixes get regression
tests.

Thanks,
Marti


Thanks,
Charles


-----Original Message-----
From: devel@lists.zephyrproject.org [mailto:devel@lists.zephyrproject.org] On Behalf Of Bolivar, Marti
Sent: Wednesday, September 4, 2019 12:39 PM
To: users@lists.zephyrproject.org; devel@lists.zephyrproject.org
Subject: Re: [Zephyr-devel] Do not use west v0.6.1; upgrade to v0.6.2

Marti Bolivar <marti.bolivar@nordicsemi.no> writes:

Hi,

West v0.6.1 contains a high impact bug in the "west update" behavior
that is fixed in v0.6.2. Users of v0.6.0 and earlier are not affected.
I was requested to add a link to the bug:

https://github.com/zephyrproject-rtos/west/issues/298

It won't cause data loss, but it will cause west update to fail to check out the correct revision in some cases.

Marti


If you are using west v0.6.1 (check with west --version), please
upgrade now using the usual process:

Linux:

pip3 install -U --user west

macOS and Windows:

pip3 install -U west

Thanks,
Marti


1441 - 1460 of 7688