Thanks Wayne, that's very interesting, I think it helps explain the disconnect here.
I understood David Simmons to be suggesting that Makers (like me) are the target end-users, i.e: that MyNewt would be an alternative to, say, Arduino (and why not). However, in your use-case, you are the end-user of MyNext, and Makers are your end-users, no? i.e: a layer lower in the stack. So, in that case MyNewt would be positioned as an alternative to an RTOS (or no RTOS) for embedded C programmers building devices for Makers. So, if I may, I'd suggest that we step back and ask Sterling who exactly he envisages as the end user of this project: Makers, or embedded C developers building devices for Makers? David On Wed, Jun 8, 2016 at 10:35 AM, Wayne Keenan <wayne.kee...@gmail.com> wrote: > On 8 June 2016 at 17:14, David Moshal <dmos...@gmail.com> wrote: > >> David you make good points, though I have to say, sadly, that serial >> vs JTag is the least of MyNewt's worries when it comes to targeting >> the Maker market, if indeed that is your target market. Just saying. >> >> I'm happy to explain that statement further if anyone is interested. >> > > I'd like to hear more please, it's very relevant to aspects of my mission > at the moment... > > To make things simpler for the Maker market I have a MicroPython prototype > up and running on MyNewt. It comes with a couple of Python modules for > accessing GPIO (very basic) and configuring BLE (support for: uuid16 or > uuid128 bit GATT Services/Characteristics and Eddystone beacons) it also > has a simple Python 'single line eval' (a not yet multiline indentation > tolerant REPL) on serial. > > So from this perspective the only thing to flash might be the text of a > Python Script in part of a flash filesystem, but, I'd still like to be able > to upgrade the MicroPython 'app' using a boot loader that was always > present for app recovery/reflashing. > > All the best > Wayne > >> >> >> >> On Wed, Jun 8, 2016 at 8:37 AM, David G. Simmons <santa...@mac.com> wrote: >> > I’ll add a +1 here. Especially for the ‘Maker’ market, etc. where access >> to a JTAG programmer may be cost prohibitive. least common denominator >> (serial, typically over USB) is a great thing. >> > >> > Having a bootloader that will *always* run, and is accessible via >> serial, makes debugging bad firmware a lot easier, makes recovering a >> bricked device possible, and makes simple programming of a device easy. If >> developers don’t have to re-flash a bootloader, but just send over a new >> app, that makes things simple for developers. Especially for the relatively >> inexperienced developer who will have a greater tendency to send over a bad >> image and cause havoc on the device. I’d also advocate for a separate >> process for flashing a new bootloader just to add an extra level of >> protection in case someone *does* alter the bootloader code, flash it, and >> it’s bad. What I’m saying is that we should make it very hard, if almost >> impossible, for software to kill hardware. >> > >> > Best regards, >> > dg >> > >> >> On Jun 7, 2016, at 1:37 PM, Kevin Townsend <ke...@adafruit.com> wrote: >> >> >> >> I think I would probably argue as well that the bootloader should be >> able to run completely independent with no user image flashed, with the >> ability to flash a first image over serial, but that's just my own opinion >> and biased expectations in a bootloader. Obviously, I'm curious to hear >> what everyone else thinks! >> >> >> >> There should perhaps also be an options for a fail-safe mechanism to >> boot into 'bootloader only' mode (polling a pin at startup) where no >> firmware is executed, but you can still talk to the bootloader via the >> 'newtmgr' tool to flash an image, etc. >> >> >> >> BLE complicates things, but keeping 'serial' as a baseline in the core >> bootloader image should add a great deal more resilience to mynewt devices, >> particularly if you're devices cost several hundreds dollars per unit and >> aren't just say $30 nodes that you can pull out and replace. >> >> >> >> K. >> > >> > -- >> > David G. Simmons >> > (919) 534-5099 >> > Web • Blog • Linkedin • Twitter • GitHub >> > /** Message digitally signed for security and authenticity. >> > * If you cannot read the PGP.sig attachment, please go to >> > * http://www.gnupg.com/ Secure your email!!! >> > * Public key available at keyserver.pgp.com >> > **/ >> > ♺ This email uses 100% recycled electrons. Don't blow it by printing! >> > >> > There are only 2 hard things in computer science: Cache invalidation, >> naming things, and off-by-one errors. >> > >> > >>
