running EBB firmware as software?

[snoyer]

It would be great to be able to compile and run a "dummy" software EBB on a PC, either as:

• an executable that takes EBB commands on standard input and produces the same responses as an EBB would on standard output, as well as the state of the board (timer, step counters, servo state, ...).
• a shared library that exposes functions to put commands in a buffer, retrieve the response buffer, access the various state variables, ...

This could be used as a base for:

• testing of the firmware itself
• testing of client applications
• end-user plot simulation: a software EBB could be hosted behind a virtual serial port so that an existing client application (such as the Inkscape extension) could use it transparently and produce an accurate visualization of what the transmitted commands would actually do, in real time or near instantly as a software EBB could run way faster than a real one.
• internal plot simulation: having faithful state simulation allows client applications to do precise drawing time/distance estimation, optimization (for example grouping multiple commands defining a single move, find safe points to inject QBs for pausing), etc., of arbitrary command streams.

This can all be implemented independently, but it requires a lot of guess work, empirical testing, reversing/porting... to reproduce a behavior that is already right there in C.

tl;dr: Is there any way to re-use the core code of the firmware and build an executable/library with alternative i/o around it?

[EmbeddedMan]

Agreed - this would be really cool. Also, if done right, certain types of unit tests could be easily created and quickly run on the PC to help catch firmware bugs. What this would take is a sort of hardware abstraction layer to be added to the firmware code, which would then allow the same code to be run on a PC or on the EBB using the same codebase. The HAL would abstract things like getting and putting a byte to the USB serial port, and properly simulating interrupts on the PC side. I honestly don't think this would be a complete rewrite by any means, but is also not a trivial change. We will have to figure out what would be a good environment on the PC side - like how do you even create a virtual serial port in C? (I've never done that - but always wanted to.) There will be lots to decide - would it be coded as a full up PC application, or just a library to be included in other source? If you're going to use it for things like simulating actual plotting, how do you get the 'outputs' (step and direction pins and RC servo outputs) into virtual forms that are useful to a host application? I'd like to look into adding this feature after the main refactoring and feature additions are done for v3.0.0. It may be a sort of long-term goal for the project : not something likely to happen soon but a really good thing to work on as time permits. We'll have to figure out how useful it is compared to the other things we want to change/add to EBB firmware over time.

…

On Wed, Jul 1, 2020 at 3:15 AM snoyer ***@***.***> wrote: It would be great to be able to compile and run a "dummy" software EBB on a PC, either as: - an executable that takes EBB commands on standard input and produces the same responses as an EBB would on standard output, as well as the state of the board (timer, step counters, servo state, ...). - a shared library that exposes functions to put commands in a buffer, retrieve the response buffer, access the various state variables, ... This could be used as a base for: - testing of the firmware itself - testing of client applications - end-user plot simulation: a software EBB could be hosted behind a virtual serial port so that an existing client application (such as the Inkscape extension) could use it transparently and produce an accurate visualization of what the transmitted commands would *actually* do, in real time or near instantly as a software EBB could run way faster than a real one. - internal plot simulation: having faithful state simulation allows client applications to do precise drawing time/distance estimation, optimization (for example grouping multiple commands defining a single move, find safe points to inject QBs for pausing), etc., of arbitrary command streams. This can all be implemented independently, but it requires a lot of guess work, empirical testing, reversing/porting... to reproduce a behavior that is already *right there* in C. tl;dr: Is there any way to re-use the core code of the firmware and build an executable/library with alternative i/o around it? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#140>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AADN4CEBFZYVNNOGMQQVVHLRZLWDLANCNFSM4ONFAUHQ> .

[snoyer]

As far as I am concerned I'd say setting up an abstraction layer would be all that is needed from the firmware team side, if that is done right then building applications and/or libraries happens on top of the firmware code and is therefore independent.

For example, for the virtual serial port use-case, you wouldn't necessarily need to implement it in C, a software build of the EBB could talk to stdin/stdout, and one could pipe to it through something like socat (in the linux world, at least) as needed.
For the in-app use-case, if we assume a python application I would prefer having bindings (multiple options here: boost::python, cython, cffi, ... but again irrelevant at this point) to a shared library that would allow to directly access the appropriate C function/variables.

From a quick look at the existing code it seems that there's already a bit of the idea in there with the output being done using printf and the "hijacked" to the USB buffer with a custom putc. Pushing in that direction all the way and making sure the abstraction done right is all I would expect from your side. Basically the firmware does not need more actual functionality (such as virtual ports baked in and the like), only some (obviously non trivial) refactoring to untangle the logic from the i/o and and offer the possibility to build around it.

[EmbeddedMan]

Gotcha. Makes sense. If all we're talking about is emulating the USB serial I/O (i.e. no servo/stepper output sim) that makes things easier. At least, that's a good place to start - more can always be added later.

One thing I'm concerned with on this vein is getting the code to compile on a modern PC C compiler. The compiler we're using for this firmware is an older Microchip compiler called C18 which was pretty close to standard C, but not quite in every way. I guess we'll just have to try it and see, and #ifdef any parts that are problems.

OK, for now, I'm going to continue on the refactoring effort for v3.0.0. One that's in a 'not finished but getting pretty close' state, we can come back to this thread and see what changes would be necessary to support compiling and running on a PC.