This took a lot longer to release than planned, but just wanted to share
this for anyone interested: https://www.adafruit.com/product/3574
Just waiting for the iOS app we wrote to get approved and some
documentation cleanup, and it will be available in the shop shortly, and
I'll be happy to
a flashed stlink v2
with bmp firmware .. but you can still write them as single image ..
that would be a cheap production option …
On 15 Aug 2017, at 23:04, Kevin Townsend <ke...@adafruit.com.INVALID> wrote:
It doesn't have an on-board J-Link, but that's why it's relatively inexpensive,
a
have to buy this new version?
>
>
> > On Aug 15, 2017, at 2:42 PM, Kevin Townsend <ke...@adafruit.com.INVALID>
> wrote:
> >
> > This took a lot longer to release than planned, but just wanted to share
> this for anyone interested: https://www.adafruit.com/prod
I've put together a first (rough!) pass at some documentation for the
Mynewt board, and we just made a first batch live for sale.
We'll expand this with more details (and corrections I'm sure), but
there are some notes on debugging with GDB and might be useful to some
people:
?mt=8)
I'll try with the newtmgr commands again on a clean machine. It may well
be that the error message is an artifact of some previous system or tool
configuration.
Kevin
On 22/08/17 20:00, Christopher Collins wrote:
Hi Kevin,
On Wed, Aug 16, 2017 at 11:45:52PM +0200, Kevin Townsend
Hi Vipul,
On 15/09/17 23:19, Vipul Rahane wrote:
That is interesting. I have never really used one but sounds cool.
IMO, we should create a driver group - input_devices just like sensors.
I think this is different enough from sensors that it deserves a
dedicated group, yes.
I don’t know
I'm working on some sensor drivers for Mynewt 1.4, and have run into an
issue that I'm not sure has a single perfect answer, but should perhaps
be addressed or further discussed.
Most sensors have specific timing constraints, and in certain instances
these can change dynamically. The TSL2561
support don't have 1-wire specific hardware, so why
not have a general implementation(using hal_timer) instead of one
implementation per MCU?
Thanks,
Miguel
On Mon, Jul 2, 2018 at 8:10 PM Kevin Townsend
wrote:
Is there any interest is discussing how to add Dallas 1-Wire support to
the HAL? https
Is there any interest is discussing how to add Dallas 1-Wire support to
the HAL? https://en.wikipedia.org/wiki/1-Wire
It's a bit of a niche item, but an interesting protocol (you can power
some devices from the single GPIO line) and there are some very common
and cheap waterproof temp sensors
ntended to be - I've taken the assumption that the API aims to cover
simply taking a single measurement from the sensor, rather than
providing a fully processed and always-up-to-date result.
On Sat, 30 Jun 2018 at 00:02, Kevin Townsend wrote:
I'm working on some sensor drivers for Mynewt 1.4, and ha
To try to frame this in a concrete example, I've pushed out a PR with
the initial TSL2591 driver. It would be worthwhile discussing there how
to handle minimum delays between valid sensor reads:
https://github.com/apache/mynewt-core/pull/1237
On 30/06/18 19:12, Kevin Townsend wrote:
Hi Amr
1 wire device fits the timing constraints of your UART peripheral.
Just thought it was worth mentioning, might be something to consider.
Sam
On Tue., 3 Jul. 2018, 6:11 am Kevin Townsend,
wrote:
Hi Miguel,
Good to hear!
Yeah, GPIO is the only way I've ever implemented this and I think a
sim
implement the ‘1-wire’ API, and chip drivers would then
depend on that API.
The PJRC API is simple, which I like. Seems like a good starting point.
On Jul 3, 2018, at 3:31 PM, Kevin Townsend wrote:
Hi Marko,
IMHO, The PJRC lib is a sensible basis for a Mynewt 1-Wire package since it's
seen a fair
TVOC (total volatile organic compound, in units of ppb).
IMO, this is a good starting point.
BR,
Andrey
On 19.07.2018 17:18, Kevin Townsend wrote:
Hi Amr,
I think gas is a common enough value that it should be added, but the
difficulty is what standard/SI type unit and scale should we use f
Hi Amr,
I think gas is a common enough value that it should be added, but the
difficulty is what standard/SI type unit and scale should we use for that
since 'gas' is pretty generic. For light it's easy (lux), or acceleration
(m/s^2), but do you have any proposition for what value would be an
Thanks for your comments @Kevin and @Andrey. I think for the BME680,
I'll stick with USER_DEFINED for now until we can come up with a more
general system. Ultimately, the gas sensor resistance is not really a
final value to be used and so I think it's OK for it to fall under the
USER_DEFINED
This page might be worth updating since I came to the same mistaken
conclusion based on the last line here:
http://mynewt.apache.org/v1_2_0/os/modules/baselibc/ ... and implemented my
own %f solution before discovering that there IS in fact basic float
support with FLOAT_USER. :) The current
The additions to the newt tool in recent releases makes things like package
creation much easier, and pulling the code from Github is a good idea to
keep things up to date.
In my own workflow, unit tests are a major part of package development
since I can quickly and easily run functions
I pushed out a simple PR to add I2C stubs for the simulator
(https://github.com/apache/mynewt-core/pull/1251), but the end goal is
to try to simulate specific sensors via callbacks as naturally as
possible to transparently switch between sim and HW targets.
There needs to be some sort of
Hi Jacob,
But Kevins code snippet brings up something im thinking about. In his
comments he has
CONFIG_NFFS: 1# Initialize and configure NFFS into the
system
I dont agree with that comment, whats thats actually doing is turning on
the config subsystem and telling it to create its
+1 ... this all seems very reasonable to me.
The lower the learning curve to get started the better, and most people
have simple logging needs to get started.
On Fri, 6 Jul 2018 at 00:18, Christopher Collins wrote:
> Hello all,
>
> My logging obsession continues. I have submitted a giant PR
>
Hi Chris,
The error codes that come back in newtmgr responses are always (or at
least should be) MGMT_ERR codes:
https://github.com/apache/mynewt-core/blob/42bb5acc2f049d346c81f25e8c354bc3c6afefd4/mgmt/mgmt/include/mgmt/mgmt.h#L65
`MGMT_ERR_ENOENT` is indicated when the newtmgr command isn't
I'm doing some initial development using only the simulator (for
convenience sake), and was testing out 'newtmgr fs' support to quickly
get data to and from the simulator.
My sim target is setup to use NFFS using mostly default values:
# NFFS filesystem
FS_CLI: 1 #
In the sys/config package, there are two main flags to test against in
code, depending on your implementation:
* CONFIG_FCB (storage in FCB)
* CONFIG_NFFS (storage in NFFS)
https://github.com/apache/mynewt-core/blob/master/sys/config/syscfg.yml
I'd like to add config key-pairs as an option
Hi Chris,
I don't know if this helps in your particular case, but you can specify
"-f " to use a local file for internal flash (assuming the app
calls `mcu_sim_parse_args()` in main). If you specify the name of an
existing file, the simulator will reuse its contents.
It doesn't look like
Hi Chris,
I think cases like the one you described are usually solved by adding a
> new setting to the driver package (e.g., `TSL2591_CONFIG`). If that
> setting is enabled, the driver package depends on `sys/config`, e.g.,
>
> pkg.deps.TSL2591_CONFIG:
> -
Sorry, I can see the flash writes here starting at 32KB testing against
the default file (/tmp/native_flash.XX) as well as a hard-coded path
(-f simflash.bin).
$ xxd -s 0x8000 -l 128 simflash.bin
0008000: e231 8ab9 8c42 b07f 5382 e0ac 8efc 85b1 .1...B..S...
0008010: 0040
Hi Jacob,
Excellent point about the flash usage, and figuring out how to perhaps
make it easier for packages to play well together in a single filesystem
without hijacking the config system out of necessity.
I dont agree with that comment, whats thats actually doing is turning on
the config
There's a lot of good development activity happening with mcuboot lately.
Is it realistic to consider making an official switch over to that for 1.5,
before things diverge even further in mynewt-core?
On Sat, Oct 13, 2018 at 12:31 AM Szymon Janc
wrote:
> Dear Apache Mynewt Community,
>
> It has
Hi Chris,
Replies inline ...
On Thu, Nov 8, 2018 at 8:45 PM Christopher Collins wrote:
> I agree this would be a very useful feature. Did you end up
> investigating this? I have written some of my thoughts on the subject
> below. All comments welcome.
>
I haven't explored the idea further,
+1 to the idea of being able to handle this at the module/package level to
subscribe to 'shutdown' or 'sleep' events. The package level is the right
place to handle this since the package itself is aware of the transport
being used for drivers (I2C/SPI/etc.), and the pins that can be switched to
I've been trying to implement NFFS config-backed settings in a driver, but
going through the documentation and some of the examples in the core github
repo it isn't clear to me exactly when/where/how to correctly persist the
data to the NFFS partition.
I have the following two values to persist
I've been working on a number of packages for my own use, and can make a PR
to include these in apache-mynewt-core if there is interest, but I've made
the following two packages public for review if anyone is interested in
testing them or providing feedback before a PR:
-
33 matches
Mail list logo
