Hi Marko, Sounds great, a console 'raw uart' mode makes sense, and is a lot simpler than the tree surgery I've done.
It would also be very useful to expose the console's CONSOLE_RX_BUF_SZ & CONSOLE_TX_BUF_SZ #defines as tweakable pkg and target config settings. WishList ticket: https://issues.apache.org/jira/browse/MYNEWT-469 All the best Wayne On 3 November 2016 at 17:11, marko kiiskila <[email protected]> wrote: > Hi Wayne, > > > On Nov 3, 2016, at 9:08 AM, Wayne Keenan <[email protected]> wrote: > > > > Hi, > > > > On 3 November 2016 at 15:18, marko kiiskila <[email protected]> wrote: > > > >> Hi Wayne, > >> > >>> On Nov 2, 2016, at 10:53 AM, Wayne Keenan <[email protected]> > >> wrote: > >>> > >>> I've not had a chance to look, but is there a low level UART HAL > (perhaps > >>> with basic buffer support) that the console, stdio, assert can all > depend > >>> on in more recent development versions of Mynewt? > >>> > >> > >> I recommend having console/full, but not include shell package. This is > >> what > >> some of the sample apps do, like apps/bleprph. > >> > > > >> Alternatively we could have a knob in console/full that turns off normal > >> I/O, > >> only keeping output when system crashes. > >> > > > > Ah ok, but I still need unfettered access to the serial data... > > > > > >> > >> Is there something missing from the console/shell interface that you > need? > >> > > > > Yes.. a Python context aware console with auto-tab indentation :) > > I seriously don't expect Mynewt todo this, it's obviously way too > > application specific. > > I believe similar things would be useful for other scripting packages as > well. > Interactive mode is nice to have :) > > > Instead, under the banner of 'reuse' & maximum compatibility I've wired > the > > MicroPython REPL code to the UART HAL, hence bypassing the console. > > Going this route also required a tweak to Mynewt's core mynewt.c > 'stdout'. > > Having todo this step is why I thought that the core shouldn't depend on > a > > higher level package as the console.IMHO. > > > > An alternative would be to implement a new Mynewt package, say > > 'python_repl_cons_tty', that followed the same API as the current > > 'cons_tty' package and performed the uPy REPL functions. Perhaps some > time > > later, but I doubt it because it's less of a uPy REPL compatibility > > headache not to. > > Currently console collects input until a newline, and then calls up with > the data > it received. It also echoes the data back in RX interrupt context. > Obviously, I > had a certain kind of model in mind head about what kind of an app would > sit > on top of it. > > However, we could adjust that a bit. If the package above needs straight > up access to > raw bytes which are coming in, I could have console call in right away. And > then console_read() would deliver as many bytes that have been received by > then. > > Downside (of course), is the added number of context switches. But those > would > only be happening when there’s console input coming in, which is > acceptable. > > Benefit of this would be that it would be possible for all to have > getchar()/getc() > without as much trouble as you’ve had to go through :), while not having to > go straight to HAL to get stdin input. Also, I think we need getchar() to > ease up > getting other scripting languages more easily running on mynewt. > > What do you think? > >
