Re: Use of os_error_t and OS_OK

If nothing else, unifying around sys/defs makes sense, although currently -1 in sys/defs is mapped to SYS_ENOMEM and grepping for SYS_EUNKNOWN didn't turn anything up. I'd still like to work on the patch to get everything in line, although I'd appreciate some guidance on what for a few cases.

Re: I2C not working on nrf52xxx's rb-nano2

Szymon, thanks! That sounds really promising. Looking forward to it. Not sure if RTT is going to work with my OpenOCD/CMSIS-DAP debugger but for now I can use gdb when UART is disabled. Will, I think I managed to pinpoint the place where my app fails once the UART_0 is disabled. Below is my

Re: Bluetooth 5 support - configurability

Hi, On Monday, 10 April 2017 22:42:53 CEST will sanfilippo wrote: > +1 on opt-in for BT5 although I do think there are quite a few configuration > variables for features that are on by default. Not sure there is a rhyme or > reason, other than possibly the thought that “most people would be

Re: https://github.com/apache/incubator-mynewt-core/pull/197

Hi, On Monday, 10 April 2017 20:50:15 CEST aditi hilbert wrote: > Hi Marko, > > Ideally, we should try to follow the release policy. And that means leaving > the old API in, marking it “deprecated”, and pushing up the new API in > parallel. The new app in the PR can work with the new functions

Re: Bluetooth 5 support - configurability

+1 on opt-in for BT5 although I do think there are quite a few configuration variables for features that are on by default. Not sure there is a rhyme or reason, other than possibly the thought that “most people would be enabling this, so let’s have it on by default”. > On Apr 10, 2017, at

Re: Bluetooth 5 support - configurability

Hi, On 10 April 2017 at 18:15, will sanfilippo wrote: > I think #3 is fine as well. If, for some reason, folks do not want to > claim 5.0 support they can always use release 1.0.0 of Mynewt. > > > > On Apr 10, 2017, at 6:16 AM, Szymon Janc wrote: > >

Re: https://github.com/apache/incubator-mynewt-core/pull/197

Hi Marko, Ideally, we should try to follow the release policy. And that means leaving the old API in, marking it “deprecated”, and pushing up the new API in parallel. The new app in the PR can work with the new functions and the old app can remain as is. The PR touches a lot of files so this

Re: DC/DC regulator enable for nrf52. Where should it go?

There is a syscfg value called BOOT_LOADER that is defined by the bootloader app. I think this is sufficient. Agreed? Will > On Apr 10, 2017, at 9:55 AM, Sterling Hughes > wrote: > > Agree- but there should be some way of easily knowing whether called by

https://github.com/apache/incubator-mynewt-core/pull/197

Hi, I've tried this, and was wondering whether to merge it in it’s current form or not. This PR includes API changes for shell and console. While we have this: https://cwiki.apache.org/confluence/display/MYNEWT/Release+and+Support+Policy

Re: DC/DC regulator enable for nrf52. Where should it go?

Agree- but there should be some way of easily knowing whether called by boot loader or actual system. Sterling > On Apr 10, 2017, at 6:53 PM, will sanfilippo wrote: > > Thinking about this more… (which is almost never a good thing with me): > > Cortex-M MCU manufacturers

Re: DC/DC regulator enable for nrf52. Where should it go?

Thinking about this more… (which is almost never a good thing with me): Cortex-M MCU manufacturers produce a file called system_.c (where xxx is the name of the mcu). There is a function in that file called SystemInit. Generally, this is something that should be called as early as possible

Re: Bluetooth 5 support - configurability

I think #3 is fine as well. If, for some reason, folks do not want to claim 5.0 support they can always use release 1.0.0 of Mynewt. > On Apr 10, 2017, at 6:16 AM, Szymon Janc wrote: > > Hello Community, > > We are currently upstreaming Bluetooth 5 functionality into

Re: Use of os_error_t and OS_OK

> On Apr 10, 2017, at 7:42 AM, Sterling Hughes > wrote: > > I don’t think we ever came to agreement, and things are a bit of a mishmash. > Ben brings up a good point. > > Mynewt wide, in my view: > > * os_error is a relic, and sys/defs codes should be

Re: Use of os_error_t and OS_OK

On Mon, Apr 10, 2017 at 04:42:09PM +0200, Sterling Hughes wrote: > I don’t think we ever came to agreement, and things are a bit of a > mishmash. Ben brings up a good point. > > Mynewt wide, in my view: > > * os_error is a relic, and sys/defs codes should be used. > > * All functions should

Re: Use of os_error_t and OS_OK

Well, I replied quite differently, but I did not realize that os_error_t was a relic. If that is the case, I agree with what you have here :-) +1 > On Apr 10, 2017, at 7:42 AM, Sterling Hughes > wrote: > > I don’t think we ever came to agreement, and things

Re: Use of os_error_t and OS_OK

I don’t think we ever came to agreement, and things are a bit of a mishmash. Ben brings up a good point. Mynewt wide, in my view: * os_error is a relic, and sys/defs codes should be used. * All functions should return “int” and not “os_error_t” or a specific error type. * 0 and -1 are

Re: I2C not working on nrf52xxx's rb-nano2

Just an FYI: I was playing around with some code for something I was working on and I was able to disable UART0 although I did not try to re-purpose the pins. The UART was certainly not enabled did not attempt to grab the gpio. This was using the nrf52dk bsp though. Anyway, I think it worth a

Re: Use of os_error_t and OS_OK

Not sure if anyone answered this. This is just my opinion of course: * The OS functions should use return type os_error_t. * Those functions should return OS_OK or some other OS error. * Checks against functions with type os_error_t should be against OS_OK and not 0. The bubbling up of errors,

Bluetooth 5 support - configurability

Hello Community, We are currently upstreaming Bluetooth 5 functionality into Apache Mynewt. Sine all of the new features are optional to support (excluding internal dependencies) we could make Mynewt code configurable per feature. It shouldn't be too much hasle to support this via syscfg.yml

Re: I2C not working on nrf52xxx's rb-nano2

Hi, On Sunday, 9 April 2017 21:47:26 CEST Łukasz Wolnik wrote: > Later I found out that my pull-up resistors were actually 100 Ohms instead > of 10k. So actually above change to the drive wasn't necessary (it should > stay as GPIO_PIN_CNF_DRIVE_S0D1) but I have to say that fixing hardware >