Re: Thoughts on deprecating LOG_VERSION 2 and making the default LOG_VERSION 3

Fine with me too :-) > On Nov 8, 2019, at 8:02 AM, marko kiiskila wrote: > > > >> On 7 Nov 2019, at 16.50, Christopher Collins wrote: >> >> On Thu, Nov 07, 2019 at 11:56:36AM -0800, Vipul Rahane wrote: >>> Hello, >>> >>> LOG_VERSION 2 has been around for quite some time but is mostly just

Re: Unifying Newtmgr (NMP) protocol and MCUmgr (SMP) into the MCUmgr repo

+1 on my part but not sure I am in the best position to vote :-) > On Oct 9, 2019, at 12:42 PM, Vipul Rahane wrote: > > Hello, > > While making the changes for MCUmgr, we came across nmgr_uart which is a > predecessor of nmgr_shell. So far, from what I gather, the functionality is > the same

Re: Question about FPGA's

Not sure if anyone answered you Rafael but porting the stack to a new processor can be tricky depending on what you want to port. The controller would be quite tricky but the host would be doable. Not sure if that is something you want to explore. I took a quick peek at the RN-42 but could not

Re: Mynewt test facilities

Some comments inline. > On Feb 27, 2019, at 6:08 PM, Christopher Collins wrote: > > Hello all, > > In this email, I would like to discuss Mynewt's test facilities. > > ### INTRO (AKA TL;DR) > > Unit tests come in two flavors: 1) simulated, and 2) real hardware. > Writing a test capable of

Re: Disconnect reason message Nimble / BTShell

Looks like Chris and my responses crossed paths a bit here. However, I want to clarify a few things: 1) All packets sent get sent with a 24-bit CRC. This includes all forms of packets sent by the controller (advertisements and data channel PDU’s). 2) The MIC only gets appended to data channel

Re: Disconnect reason message Nimble / BTShell

The MIC stands for “message integrity check”. If you are using Link Layer encryption, which is seems like you are given some of the output you displayed in your email (supervision_timeout=256 encrypted=1 authenticated=1 bonded=1), there is a 4-byte MIC appended to every PDU sent by the link

Re: Sharing the HFXO on the nRF series

Amr: I cannot answer your question regarding what plans folks may have on using the HFXO manager. Generally I would think folks would send an email to this list if they had any plans… I think something was missed in the initial implementation of the nRF hal_timers and the HFXO. Well, maybe

Re: LoRa end device unable to consistently join

One thing you might want to check out is the lora public/private network setting. This uses different start words and occasionally the wrong start word will still work. The syscfg value for this is: LORA_NODE_PUBLIC_NWK and the default is 0 (meaning it is default to private network) > On Jan

Re: Setting and displaying time

My reply was definitely a bit confusing based on Chris’s reply. He is correct and if you use those API to set/get time of day what I was saying you need to do in firmware is already done for you. Hopefully that clears up any confusion. > On Dec 27, 2018, at 9:21 AM, will sanfilippo wr

Re: Unlikely recoverable failures

Chris: Sorry was away so did not comment on this prior to your implementation. All sounds good; I like DEBUG_PANIC for the name (I liked it better than DEV_PANIC). Will > On Oct 19, 2018, at 11:14 AM, Christopher Collins wrote: > > FYI- I have submitted a PR that implements this new macro:

Re: Controlled shutdown

Some comments: 1) Are there are any other cases you can see for a controlled shutdown? I get the reset command. I am trying to think of others. 2) I am curious: how do you know how many of these functions, or which ones, return in progress? Curious to know how you were going to implement that

Re: msec and nsec delay in mynewt OS

I would say there are two ways to do this: 1) As Marko mentions os_cputime is good for these types of delays. If you are using the bluetooth stack it forces os cputime to count at a frequency of 32768 Hz (~30.51 usecs). If you are not using the bluetooth stack you can modify os_cputime to

Re: I2C retries

I do not think a driver requires an os device personally. You could write a driver that does not have os dev functionality in it. I do agree that it seems most people implement drivers with os dev functionality but I do not think it is a requirement. > On Aug 31, 2018, at 9:51 AM, Christopher

Re: FCB revamp

entries take up some > space (only the offset is added). > > KInd regards, > > Jehudi > > Op ma 30 jul. 2018 om 23:16 schreef Cufi, Carles : >> >> + Andrzej >> >> On 30/07/2018, 18:45, "will sanfilippo" wrote: >> >>I guess

Re: FCB revamp

n. >>> There’s 3 different options when starting FCB: inherit from flash, force 16 >>> bit, or force 8 bits. If the flash region >>> has not been initialized with anything, then the ‘inherit’ option will >>> prefer 16 bits over 8 bits. >>> So if you ne

Re: FCB revamp

I realize I am a bit late with these comments but better late than never I guess. Well, maybe some or all of these comments should never be made :-) This could be a horrible idea but why not just make it backward incompatible? (for #2). Maybe have a syscfg for folks that want to use the old

Re: Logging (again!)

+1 This all seems quite reasonable to me. > On Jul 5, 2018, at 3:18 PM, Christopher Collins wrote: > > Hello all, > > My logging obsession continues. I have submitted a giant PR > (https://github.com/apache/mynewt-core/pull/1249) which changes all > existing packages to use the modlog

Re: Sleep modes in mynewt

Generally speaking it is up to the developer to implement various “low power states” for their application. If you are running on a cortex-M processor the OS uses “tickless idle”. This means that the CPU is halted on a WFI instruction until the OS needs to do something next. Other than that the

Re: Different Bluetooth controller

Jeff: I may not be answering the question you want but the controller itself runs on the nordic chips only so you will not be able to run the nimble controller on those devices. What *is* supported is the nimble host. The nimble host should be able to talk to any controller. The set of HCI

Re: shell commands for multiple instantiated modules

Not sure I have a strong opinion on this one. My initial reaction was option 1 but I can understand why some of the other options might be better. > On Jun 25, 2018, at 4:07 AM, Michał Narajowski > wrote: > > Hi Paul, > > IMO Option 1 seems like the best option here. I don't think the

Re: ADC device not allowed multiple opens

so I did not worry about it > too much ;-) > > Best, > Andrzej > > > On Wed, Jun 6, 2018 at 10:56 PM will sanfilippo wrote: >> >> Chris and Vipul: >> >> That does indeed seem to be a decent option! I will see if others chime in >> and if not,

Re: ADC device not allowed multiple opens

6, 2018 at 11:57:34AM -0700, will sanfilippo wrote: >>> Chris: >>> >>> I might be missing something here, but given that os_dev already has a >>> reference count and that handles multiple folks opening/closing the device, >>> does the underlying adc

Re: ADC device not allowed multiple opens

that os_dev_open() and os_dev_close() always call the open/close handlers regardless of reference count. I wonder if that should be changed (meaning only call open/close once)? > On Jun 6, 2018, at 10:13 AM, Christopher Collins wrote: > > On Wed, Jun 06, 2018 at 08:50:34AM -0700, will s

ADC device not allowed multiple opens

Hello: I am not the most familiar with the ADC device so it is possible that it was being used incorrectly but in any event I ran across something I wanted to discuss. The call to os_dev_open() allows a device to be opened multiple times (there is a reference count there). However, the call to

Re: how to put nRF52 in "System Off" mode?

Mynewt does not provide a way to do this currently. There are hooks in the bsp code for power modes and you could add that code to the deepest power savings mode if you like (user-defined what happens on various power states). > On Apr 30, 2018, at 10:54 PM, Carl Turner

Re: os data.core memory section

Markus: I presume you are referring to these definitions: #define sec_data_core __attribute__((section(".data.core"))) #define sec_bss_core__attribute__((section(".bss.core"))) #define sec_bss_nz_core __attribute__((section(".bss.core.nz"))) As far as I know there is no real magic here

Re: [GitHub] sdalu opened a new issue #985: Building Lora with SPI > 0

I think this is just some legacy code. At least, I cannot see any restrictions in the code that would necessitate spi 0 being used. I do seem to recall there being a reason for this but as far as I can tell it is no longer needed. > On Apr 2, 2018, at 2:15 AM, GitBox wrote: >

Re: [DISCUSSION] Moving NimBLE to separate project

My thoughts: 1. Since the 1.4 release is coming up very quickly I would do this for 1.5 (personally). 2. I would choose 2a. 3. Seems a bit confusing to me to label nimBLE releases with same number as Mynewt releases. Why not just make the first stable release of nimBLE 1.0? Not a big deal

Re: HAL API change request

Either sounds fine to me > On Jan 17, 2018, at 4:34 PM, markus <mar...@bibi.ca> wrote: > > doesn't that imply a guarantee the HAL apparently doesn't make? > > how about > hal_gpio_toggle_basic() > hal_gpio_toggle_hw() > > > On Wed, 17 Jan 2018

Re: HAL API change request

iven plenty of heads up before anything >> changes. I I think Will's idea of adding a new function is a good >> way to start the process. >> >> Chris >> >>> >>> >>> On Wed, 17 Jan 2018 14:10:24 -0800 >>> will sanfilippo <wi..

Re: HAL API change request

Markus (and all): I think there may be some confusion here or misinterpretations. I think most would agree that there is no absolute requirement for a hal_gpio_toggle() API if you can both read and write a gpio. The API was added as a helper since toggling a gpio is a fairly common construct.

Re: Cannot build lora_app_shell

see and get you to the next one :-) > On Dec 8, 2017, at 4:29 AM, K Dmitry <dimka...@yandex.ru> wrote: > > > > 01.12.2017, 20:34, "will sanfilippo" <wi...@runtime.io>: >> Something does not quite make sense I have to say. Where it was crashing w

Re: Cannot build lora_app_shell

ed nrf52dk yesterday and app was > crashing. Today I've changed pins and syscfg according to example by will > sanfilippo and app works.

Re: Cannot build lora_app_shell

0x9258 in os_init (main_fn=0x84dd ) at > repos/apache-mynewt-core/kernel/os/src/os.c:186 > #14 0x82ec in _start () at > repos/apache-mynewt-core/libc/baselibc/src/start.c:37 > #15 0x8122 in Reset_Handler () at > repos/apache-mynewt-core/hw/bsp/nrf51dk/src/arch/cortex_m0/gcc_start

Re: Cannot build lora_app_shell

func=func@entry=0x0, e=e@entry=0x0) at > repos/apache-mynewt-core/kernel/os/src/arch/cortex_m0/os_fault.c:119 > #13 0x9258 in os_init (main_fn=0x84dd ) at > repos/apache-mynewt-core/kernel/os/src/os.c:186 > #14 0x82ec in _start () at > repos/apache-mynewt-core/libc/

Re: Cannot build lora_app_shell

Could you also tell us what your target looks like: newt target show Thanks > On Nov 29, 2017, at 8:26 AM, Christopher Collins <ch...@runtime.io> wrote: > > On Wed, Nov 29, 2017 at 07:43:20AM -0800, will sanfilippo wrote: >> I doubt it was ever tested with no sx1276 actu

Re: Cannot build lora_app_shell

I doubt it was ever tested with no sx1276 actually connected. Where is it crashing? What function is at 0x81bc? > On Nov 29, 2017, at 6:20 AM, K Dmitry wrote: > > Thanks! That helped. I had to define few more pins and was able to build app. > Now I'm trying to test it

Re: Inconsistent HAL GPIO semantics

+1 Sounds good to me. > On Nov 13, 2017, at 5:24 PM, Christopher Collins <ch...@runtime.io> wrote: > > On Mon, Nov 13, 2017 at 04:32:58PM -0800, will sanfilippo wrote: >> Chris: >> >> Personally, I think there should be separate API as it is more flexible and

Re: Inconsistent HAL GPIO semantics

Chris: Personally, I think there should be separate API as it is more flexible and the API names more accurately describe what the API is doing. I do realize that this is more work and given that there currently is no API to clear a pending interrupt, I suspect that everyone who used the

Re: [RFC] Deprecation of bletiny application

+1 for deprecating ble(not so)tiny > On Nov 8, 2017, at 1:14 AM, Szymon Janc wrote: > > Hello, > > This was vaguely discussed in the past when btshell was introduced but I > wanted to bring it up again. > > In short: I propose to deprecate bletiny application (which

Re: LoRa power consumption

che.org), > the best free email app for work > > On Nov 7 2017, at 1:14 am, will sanfilippo <wi...@runtime.io> wrote: >> Marco: >> >> Not sure if you are referring to the current mynewt LoRa implementation or >> LoRa in general. The Semtech SX1276 chip draws 11-

Re: Mutex oddities with v1.0.0

ther option could be to change mutex_release() to >> write something other than 0 at mu_owner, and then add a conditional >> hardware watchpoint which looks if anything tries to zero out mu_owner >> of your send_mutex. >> >> Good luck with the hunt. >> >>> O

Re: LoRa power consumption

Marco: Not sure if you are referring to the current mynewt LoRa implementation or LoRa in general. The Semtech SX1276 chip draws 11-12mA in receive mode. The processor will add to this of course. If you are asking about mynewt specifically the current drain has not been measured but there are

Re: Mutex oddities with v1.0.0

What this looks like to me is that there was a nested pend without the same number of releases. Maybe some path out of some code that is rarely hit where a mutex is granted but not released? Just a guess... > On Nov 5, 2017, at 8:26 PM, Jitesh Shah wrote: > > Hey Guys,

Re: How hard to do the following....

:22 AM, Christopher Collins <ch...@runtime.io> wrote: > > On Thu, Nov 02, 2017 at 09:10:59AM -0700, will sanfilippo wrote: >> Others can correct me if I am wrong but I will attempt to answer some of >> these: >> >> 1. Yes, the current code supports this. >

Re: How hard to do the following....

Others can correct me if I am wrong but I will attempt to answer some of these: 1. Yes, the current code supports this. 2. Yes, the current code supports this assuming you want to use a different random address for each advertiser. 3. Yes, you can scan 100% of the time. Of course, if you

Re: BLE Host - Removing the BLE_GAP_EVENT_CONN_CANCEL event type

+1 Sounds good to me. > On Oct 25, 2017, at 9:53 PM, aditi hilbert wrote: > > >> On Oct 25, 2017, at 6:46 PM, Christopher Collins wrote: >> >> On Thu, Oct 19, 2017 at 12:07:58PM -0700, Christopher Collins wrote: >>> On Fri, Oct 13, 2017 at 10:18:14AM

Re: LORA api changes for transmit data rate

). > >> On Oct 24, 2017, at 5:08 PM, will sanfilippo <wi...@runtime.io> wrote: >> >> I understand your point and it is a valid concern meaning that I can see why >> it might be nice to be able to configure different ports as you suggest. >> Howeve

Re: BLE + LoRa

ackets overlap in time). > > We've tried it with several different device<->programmer setups (always on > the EE-02), and with a couple different gateways. > > It would be interesting to hear if you have the same experience, or any > inkling of an explanation. > > On Mon

Re: nRF51 SPI1 Slave failing after time

Hello Joe: I do not have any ideas off the top of my head. Can you copy/paste a register dump of the SPI peripheral? That might help. Making sure that all interrupts are still enabled would be a good thing as well. Thenks > On Oct 1, 2017, at 5:18 PM, Joe Broxson

Re: BLE + LoRa

I'd love to know what else needs to be set correctly for LoRa and BLE to > work together! We've spent a lot of time already figuring out this timing > issue. > > On Mon, Sep 25, 2017 at 5:38 PM, will sanfilippo <wi...@runtime.io> wrote: > >> LORA and BLE definitel

Re: BLE + LoRa

LORA and BLE definitely needs some work. There are some other things that need to be set correctly for this to work as well so it is not just the settle time. We have just started with the lora support and I suspect there will be a fair amount of changes to that code, especially getting both to

Re: I2C, SPI: BSP->MCU

I think the MCU is the proper place for the definition and either bsps, apps or targets can override/set the variables. +1 for me too. Will > On Sep 21, 2017, at 11:19 AM, Vipul Rahane wrote: > > I did take a look at the discussion and it seems that moving the SPI/I2C >

Re: Trimming controller code size with BLE_EXT_ADV

he Central role. Is that no longer > possible in 1.2? (Sorry, I'd check but I'm on the road in France) > > Thanks > Wayne > >> On 11 Sep 2017, at 16:28, will sanfilippo <wi...@runtime.io> wrote: >> >> There were always plans to separate central from peripheral in the

Re: Trimming controller code size with BLE_EXT_ADV

There were always plans to separate central from peripheral in the controller to save space but was never added since we always seemed to manage to fit it by doing other things. I think separating these two is a good idea for those who need the flash. Just my two cents. Will > On Sep 11,

Re: Premature supervision timeout

Glad other folks were answering you Simon; I was away for a bit. I do not have anything else to add. The only thing is that if you do not have a sniffer one (possible) way to determine what is going on is to look at statistics. You need to look at the stats directly before and after the issue

Re: Premature supervision timeout

I do not think this is really an answer but it is the best I can do without more information. When a device initially “connects” the state of the connection is not considered established until a data frame is received from the other device in the connection. The initial supervision timeout is

LF clock and nordic chip support in mynewt

Hello: Recently there has been some offline discussion about issues with the LF clock for nrf52-based BSPs that did not have an external 32khz oscillator. There has also been a recent commit to introduce a different source for the LF clock (the internal RC oscillator). After looking at the

Re: console_queue_char() in interrupt context

I dont know enough about the console code to make an intelligent suggestion. There is no task associated with the console, right? If not, and the purpose of this is to wait some time maybe the only thing to do is set a timer to wake up and deal with this? Not sure that this would work though…

Re: Why not use -std=gnu99?

I do not think there is any need to support other compilers (imho). Too much extra support work and no really compelling reason that I can see. WIth that said, doing some small things to increase compiler portability seems reasonable (for example, macros for packed structures; things like