Re: Smoke testing latest release

olimex and arduino zero good too. > On Nov 10, 2016, at 6:01 PM, will sanfilippo wrote: > > All: > > Just wanted to note I smoke tested the following boards/bps. The smoke test > is basically erasing the flash, loading the bootloader and blinky (and making > sure it

Re: [HEADS UP] MERGE INTO MASTER!

I created https://issues.apache.org/jira/browse/MYNEWT-482 What I usually do is I start ‘newt debug’, and then issue flash erase commands via gdb. Which is not too bad either. > On Nov 10, 2016, at 2:00 PM, David G. Simmons

Smoke testing latest release

All: Just wanted to note I smoke tested the following boards/bps. The smoke test is basically erasing the flash, loading the bootloader and blinky (and making sure it blinks!) nrf52dk nrf51dk nrf51dk-16kb bmd300 arduino mkr1000 nucleo-f401 We had a snafu with the arduino zero if the flash was

dev

Hello all, I wanted to send a quick note about the planned 1.0.0 beta 1 release. The pre-release branch has the following name: 1_0_0_b1_dev This branch has been created in the following repos: incubator-mynewt-blinky incubator-mynewt-core incubator-mynewt-newt

Re: [HEADS UP] MERGE INTO MASTER!

> On Nov 10, 2016, at 4:59 PM, Kevin Townsend wrote: > > >> Backwards-compatiblity-breaking changes have been made to the boot >> loader. Consequently, before using the latest, you will need to >> completely erase the boot and images slots in your devices' flash and >>

Re: [HEADS UP] MERGE INTO MASTER! (was: Re: 1_0_0_b1_dev branches)

On Thu, Nov 10, 2016 at 08:04:45PM +, Sterling Hughes wrote: > just making sure people see this :) This is the final heads up :). I'll be merging develop into master shortly. For those who are interested in using the latest code, there is one major change you should know about prior to

Re: Sensor Drivers and File Location

> On Nov 10, 2016, at 11:08 AM, Kevin Townsend wrote: > > Raw data is still important in my opinion. 90% of the time a shares API for > all accels or mags is the best choice, but there are instances where you will > want the raw data for DSP filtering, etc., and I think

Re: I2C Bus Scan Formatting

I just checked in and created a pull request for turning OS Ticks printing on/off. ? Commands: echo ?prompt ticks tasks mempools date b ticks on 248940:Ticks set to: 248940: Console Ticks on prompt on 249600: Prompt now on. 249600: > ticks off Console

Re: 1_0_0_b1_dev branches

FYI - I will be merging the develop branch into master later today. If you are using the master branch, and you are not prepared to switch over to the latest, then be careful with git pulls and newt syncs! Thanks, Chris On Thu, Nov 10, 2016 at 08:30:28AM -0800, Christopher Collins wrote: >

1_0_0_b1_dev branches

(changing subject to prevent mail from being categorized as a commit) On Thu, Nov 10, 2016 at 01:23:36PM +0100, Sterling Hughes wrote: > Is the idea to merge these from develop or master? > > I think we should probably merge develop->master now, prior to branching > anything. We should only be

Re: Sensor Drivers and File Location

Raw data is still important in my opinion. 90% of the time a shares API for all accels or mags is the best choice, but there are instances where you will want the raw data for DSP filtering, etc., and I think there should be a mechanism to get standard SI as well as 'raw' values back from a

Re: Sensor Drivers and File Location

Hi Sterling, I think this makes a lot of sense and the API is critical here. I definitely agree with the comments below that starting with the API is the right place. Being able to interrogate devices would also be very valuable, as well as some high level system to control sampling rates,

Re: Sensor Drivers and File Location

I should also mention, another option that we could do is have drivers for the individual sensors (just have them expose native APIs as drivers, e.g. bmp2085_read_val()), but also map into a generic sensor API, that we locate in hw/sensors, as an example. I’m not sure to what extent people

Re: Sensor Drivers and File Location

Hi Kevin, I have some thoughts, but I’m not sure they all directly address your concerns :-) More details on directory re-org and drivers below, but I wanted to mention upfront: I really think its worth thinking through the sensor api you mention in your PS, and then doing the directory org

Re: I2C Bus Scan Formatting

> On Nov 9, 2016, at 7:34 PM, Kevin Townsend wrote: > > This results in the following output on the shell: > > 5594:Scanning I2C bus 0 > 0 1 2 3 4 5 6 7 8 9 a b c d e f > 00: -- -- -- -- -- -- -- -- -- -- -- -- -- > 10: -- -- -- -- --

Re: Sensor Drivers and File Location

> On Nov 10, 2016, at 9:01 AM, Kevin Townsend wrote: > > >> This avoids the problem of a sensor that is has an accelerometer AND a >> magnetometer as they will typically both use the same bus. In the case of >> sensors that can use, say, I2C or SPI, you'd need 2 drivers

Re: [incubator-mynewt-blinky] Git Push Summary

On 10/11/16 13:23, Sterling Hughes wrote: Is the idea to merge these from develop or master? I think we should probably merge develop->master now, prior to branching anything. We should only be branching releases off of master (which I’m assuming is the intention.) +1 for this. :) It's

Re: [incubator-mynewt-blinky] Git Push Summary

Is the idea to merge these from develop or master? I think we should probably merge develop->master now, prior to branching anything. We should only be branching releases off of master (which I’m assuming is the intention.) Sterling On 10 Nov 2016, at 3:36, ccoll...@apache.org wrote:

Re: Sensor Drivers and File Location

This avoids the problem of a sensor that is has an accelerometer AND a magnetometer as they will typically both use the same bus. In the case of sensors that can use, say, I2C or SPI, you'd need 2 drivers anyway, so rather than having /hw/drivers/sensors/bno055/spi/ and

Re: Sensor Drivers and File Location

Many sensors support both i2c and SPI though which might pose a problem or oblige you to have two drivers, one for each bus? Le jeudi 10 novembre 2016, David G. Simmons a écrit : > I would actually go about this slightly differently ... > > All of these sensors come in,

Re: Sensor Drivers and File Location

I would actually go about this slightly differently ... All of these sensors come in, typically, one flavor. So there are SPI-based sensors, and ADC-based sensors, etc. Grouping them by the bus they use makes a certain amount of sense to me. Hw/drivers/SPI/... hw/drivers/ADC/... ... That