...I guess I see where you are heading: do some development of Espruino code and run it without having a board at hand... for one part, and to mime things in tutorial.
It works for all time uncritical things... I followed a similar approach by developing the .js part in a .html file I run in the browser. Hardware items - pins, etc - are objects with some behavior and ability to create an event. Most of the time they also have a UI component (visual DOM node) to display state, get a trigger/event going, input field(s) to set what the event's payload. As simple sub/pub helper piece of code creates the support for callback registration.
To do everything, it gets quite nifty... therefore, I just resorted to the point where I develop and test just logic stuff / processing parts. The overall system I break down into pieces that are hardware oriented and the others are just processing / sw oriented. If the logic has to invoke some hard ware functions, I provide stubs (which may just log in the console).
For example, when working on a memory manager, I visualized the memory content, and also coded regression testing. See mm.html link at the bottom of earlier, subject unrelated post, which you can click to 'run' the memory manager. Looking at the the document source, you see how I did it... not as sophisticated and visually pleasant, but sufficient for my needs. Subsequent posts of mentioned post show a bit how to use the UI to play with the memory manager and see what it does.
Espruino is a JavaScript interpreter for low-power Microcontrollers. This site is both a support community for Espruino and a place to share what you are working on.
...I guess I see where you are heading: do some development of Espruino code and run it without having a board at hand... for one part, and to mime things in tutorial.
It works for all time uncritical things... I followed a similar approach by developing the .js part in a .html file I run in the browser. Hardware items - pins, etc - are objects with some behavior and ability to create an event. Most of the time they also have a UI component (visual DOM node) to display state, get a trigger/event going, input field(s) to set what the event's payload. As simple sub/pub helper piece of code creates the support for callback registration.
To do everything, it gets quite nifty... therefore, I just resorted to the point where I develop and test just logic stuff / processing parts. The overall system I break down into pieces that are hardware oriented and the others are just processing / sw oriented. If the logic has to invoke some hard ware functions, I provide stubs (which may just log in the console).
For example, when working on a memory manager, I visualized the memory content, and also coded regression testing. See mm.html link at the bottom of earlier, subject unrelated post, which you can click to 'run' the memory manager. Looking at the the document source, you see how I did it... not as sophisticated and visually pleasant, but sufficient for my needs. Subsequent posts of mentioned post show a bit how to use the UI to play with the memory manager and see what it does.