Espruino Mimetism

Hi everyone !

I recently had some fun in writing Illustrator plugins, so I decided it was time to take some .. time ( ^^) to actually use it to do Illustrations ;)

As I also use a lot 123DCircuits ( neat tool for circuit stuff thx to Autodesk ), I'll try to "forward" that up to the interested ones ( if it's possible to add it to the available stuff -> see FAKE ui screenshot ;p )

On the said "Espruino Mimetism", it's just a bunch of code that aims to have interactive Espruino ( Original & Pico) SVGs.

Aside from blinking/pulsating the LEDs, when writing the POC I had in mind all those times where I didn't have my Pico handy & needed to test some code's logic better than in my browser ..

I also still think that it'd be pretty neat to visualise some pins activity, have a layout of the pins used for a particular project, search the pins & filter those that supports specific stuff, .. and why not connect real peripherals to a virtual Pico ( ex: using the Chrome Serial stuff to talk with real TTL devices or use an actual Pico to draw on a canvas LCD, .. ) ? or render a real Pico's activity in the SVG ?

Last but not least, it could be used as Illustrations of the connected board(s) in the Web IDE, be used within tutorial to represent the connections, or be used in an interactive presentation of the board(s), ..

So, hoping it'll reveal itself useful, here you have it ( attached stuff )

ps: the .ai seems to have some troubles getting there, so you'll find them, as well as the poc code, hosted at the following url github.com/stephaneAG/Espruino_tests/tre­e/master/EspruinoMimetism

Cheers,

3 Attachments

the .ai seems to have some troubles getting there, so you'll find them, as well as the poc code, hosted at the following url https://github.com/stephaneAG/Espruino_t­ests/tree/master/EspruinoMimetism

...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.

Wow, those look great! There were actually already some SVGs that are used for the Fritzing components, but actually yours look far nicer. I wonder if we could update the Fritzing ones :)

It turns out that you can compile Espruino with emscripten. It'd need a bit of tweaking (workers?) so you could call it without it blocking the main thread - but it would be extremely cool to be able to have a totally online version available. You could actually use the existing Web IDE as a terminal - which can already run online: https://espruino.github.io/EspruinoWebID­E/

Hi there :)

@allObjects -> exactly, & precisely ! ^^

On "miming things" tutorials, we could have step-by-step / timed popus telling stuff while some buttons are "pressed" ( with maybe an animated arrow showing emphasing the btn press ? ) or just record a quick gif on what a circuit does ( less flexible than the above, yet understood immediately )
Ex: I wish there was a "gif showing the circuit in use" while hovering the vignette of a circuit on 123DCircuits ( matter of adding a record/stop/erase button & registering mouse movements & clicks, to then recreate moving virtual pointer in the "gif" view - reminds me of the way a member of Panic could produce very nice looking gifs - which were not ;p )

Yes, it seems we're indeed ending up doing the same sort of things ( for me, it's often some D&D in a F12 console to quickly poke the logical blocks with dumb vars )

Nice work ! ( I'd say it's another sort of "visually pleasant" ;p )
It's clean & serves its purpose ( & wouldn't need more "niceties" - agreed to more than often "less is more" ( .. ) )
-> I'll digg your post & your tool with pleasure ;)

@Gordon
:D
Glad you appreciate this little contribution & also "my bad", I didn't check beforehand ;) ..

Actually, I kinda like yours with the onboard traces, & if you see the color I used when designing it in Illu, it seems we used the same gray-ish taint ( I just uploaded the file to the repo, if of any use https://github.com/stephaneAG/Espruino_t­ests/blob/master/EspruinoMimetism/Esprui­noBoards_wip.ai :) - I wonder if Github 'll follow Google in previewing .ai .. )

I could find the following thread http://forum.fritzing.org/t/espruino-pic­o-microcontroller-board-anyone/123 which points here https://github.com/fritzing/fritzing-par­ts/blob/master/core/EspruinoPico_8fb644a­5b6642112445ed6d90bc494d8_6.fzp

From looking at the .fzp, I guess updating the SVG 'd be replacing the id's in my SVG by those in

<breadboardView>
     <p layer="breadboardbreadboard" svgId="connector8pin"/>
    </breadboardView>

as well as the file pointed by

<views>
  <breadboardView>
   <layers image="breadboard/EspruinoPico_breadboar­d.svg">
    <layer layerId="breadboardbreadboard"/>
   </layers>
  </breadboardView>

Am I right, or is there any other work that's to be done on the pins & cie to make it possible to "stick" wires on those in Fritzing ?

If so, then it'd be just a matter of uploading the right file at the right place, & "update" parts for Fritzing users ?
-> I'd be happy to do so ;)

On the said SVGs, I am cleaning the Original Espruino's one ( reordering layers, mainly, & tagging what's not tagged yet .. )
-> oh, I wonder if you saw the pulsating LEDs ^^ ( yeah, that's lame, but I loved it when it blinked ;p )

On the Espruino IDE side, I have some thought that may be interesting:

• when selecting audio serial, then clicking on the connect button, wouldn't it be logical to be shown a jack icon instead of a usb one ?
  
• when selecting an official or supported peripheral, it could be pretty sweet to have it's icon on the right side of the bar representing it in the "select a port" popup ( so left: protocol | middle: device name & stuff | right: icon of board )
  
• we could also have the SVG of the connected board in the prefs menu ( section board ? ^^ ), or use it to somehow represent an activity on a pin ( with possible graphs showing props on the state of the pin, .. ) ?
  
  

Using the Web IDE term 'd be sweet, even more if we can have that "fully online cake" ;D
On those two, I'm facing few things:

Concerning the Espruino API, I was wondering how hard it was coupled with the underlying hardware ( I was hoping to get some lightweight stuff by having "pins" available as window.PIN ( as well as board.PIN / board['PIN'] & board.type.PIN - where type is either LED, button, of PIN, for both traces & pin holes ) plus same functions headers - possibily left utouched - just enough to "emulate" the lower level needs )
Without further knowledge on Epsruino's Core, I'm pretty sure I'll face a wall here ( and not sure to build myself a harpoon .. no nails or hammer here ;p ) :/ ..

Which brings me to that fact that sadly, I can't get neither the IDE nor its web version to communicate with my Espruinos on OS X 10.6.8 - and not able to type in the left side pane for both :/
-> BUT good news: I took the time to re-test the audio serial code from outside of the web IDE ( using some code I borrowed for a project using the WebAudioAPI ), and IT WORKED ( ! )
Nb: I only had a TRRS jack handy, & only tested the Tx capability, but the wiring that worked differs from the one posted in the tuts ( I took some quick notes & post a clean update ( .. ) )
On this, to do the Rx part, do I have to extract the fcnality from the Web IDE or did someone already did it ? ( I kinda remember a post on this need .. )
-> As soon as I got it, I can try the Tx/Rx combo on a TRRS jack & this 'll surely work on OS X, happily bypassing what's wrong with my install of ChromeApp ( .. ) :D

I leave you on this, I promised not to write too long posts ;p

Cheers +

With Fritzing - there's a part editor built in. I think the safest bet is to use that and change the SVG in it - they have a tutorial online. It's not that hard when you get used to it - as long as the SVG has the correct layers.

when selecting audio serial, then clicking on the connect button, wouldn't it be logical to be shown a jack icon instead of a usb one ?

Yes, it would. I'm not sure many people use it at the moment, but if you wanted to make a pull request that'd be cool :)

when selecting an official or supported peripheral, it could be pretty sweet to have it's icon on the right side of the bar representing it in the "select a port" popup ( so left: protocol | middle: device name & stuff | right: icon of board )

Yeah - on some computers I think horizontal space is at a premium, but I like the idea of having a separate LHS icon showing USB plus an Espruino logo or something.

we could also have the SVG of the connected board in the prefs menu ( section board ? ^^ ), or use it to somehow represent an activity on a pin ( with possible graphs showing props on the state of the pin, .. ) ?

I think that might be going a bit far :) At the moment there's no 'invisible' way to communicate between Espruino and the PC - it's all done by the console - so I'm not sure how you'd mimic pin states locally.

But if you were emulating it then yes, that's be cool, and easier.

OSX 10.6.8

Are you using an up to date firmware on Espruino? I thought I'd managed to improve this a lot in the last few versions. I just updated my wife's mac so I no longer have 10.6.8 to test with, but I definitely had both working on that (even if the bootloader doesn't).

window.PIN

I'm not sure what you're after here. If you're talking about getting an emscripten-compiled Espruino to set window.PIN to the current pin state then it shouldn't be that hard. Espruino has all the pin stuff abstracted away, so it'd just be a matter of writing a stub that does whatever Emscripten requires to set up JS variables.

But I think it's going to require someone with a bit of knowledge of emscripten to get it running nicely, and I'm a bit too busy at the moment to learn how to do it.

Back :)

With Fritzing - there's a part editor built in ..

All right for Fritzing, I'll DL the latest version & follow the tut to using the parts editor & making the necessary changes ;)
Nb: while I'm pretty satisfied of my Illu, it's not as precise as I'd have liked ( ex: the placement of the outside pinouts )
Nb2: I just did the footprint ( SMD version ) of the Pico in 123DCircuits, hosted here 2174315-espruino-pico-rev-1-4-smd-footpr­int - would you tell me it it's precise enough ?
Nb3: As i did the footprint from the SVG found in the Espruino boards repo for Fritzing, I realized while duplicating the measurements that there were not all equal ( on the right side of the footprint, the pads have a X the differs for A4:38,903 | A3:380,892 | A2->B8:38,894 => I chose to use the latter, but feel free to tell me which to update the Fritzing SVG with ;) )

when selecting audio serial, then clicking on the connect button, wouldn't it be logical to be shown a jack icon instead of a usb one ?

All right the, I'll see which pretty jack icon I can find & adapt/create one with the correct dimensions :)

separate LHS icon ..

Agreed ( nb: don't know what is 'LHS' ? ^^): having the port/connection & the peripheral name + icon is neat :D

SVG of the connected board in the prefs menu ..

^^ I was thinking at first about the pinouts of a board, represented visually, & maybe with filters that can be used to 50% opacity other than PWM, ADC, ..
About the "visual pin feedback", yes, it'd indeed be done via a Serial msg callback to the laptop ( or maybe just when doing stuff to a pin, whatever if an actual physical is connected or not - in other words, changes of a pin state in code 'd be reflected visually on the SVG, be them forwarded/actually running or not on the Pico .. plus I'd love to see realtime canvas graphs of PWM activity of some pins, just like AST helps to visualize sounds thx to the WebAudioAPI ;) )

if you were emulating it then yes, that's be cool, and easier.

Indeed easier ;p
Still, I'll have to see how to keep the same code for the simulated lower level stuff ( ..), but it'd surely be pretty neat :)

using an up to date firmware on Espruino

I guess I'll retry by updating using my laptop @ then checking with OS X ..
Thing is: I could do stuff normally before messing with my Electron & NodeJS install, & I still can connect to the Espruino using a term or even the Arduino IDE's console: just not any chrome packaged app that used to allow serial communication :/
( I also wonder if it's indeed my mess that screwed up the thing, or the fact that I can't get chrome updates no more on 10.6.8 - result being the same: no serial comm in any chrome app, although I can't remember if I succeded with an old chrome app & an arduino peripheral => I'll try your suggestion , & re-test that nayway to make sure of the result ( .. ) )

(even if the bootloader doesn't).

What do you mean by that ? :)

window.PIN

I was referring to "unnecessary poluting" the window namespace/scope ( ex: in a browser -> js console ) to be able to pass refs to pin as objects ( like doStuff(PIN) - implicitely doStuff(window.PIN) ) instead of just being able to pass PIN names strings ( like doStuff( 'PIN' ) ) or pass the parent obj ( like doStuff(board.PIN) or doStuff(board['PIN']) ) )

Espruino has all the pin stuff abstracted away, so it'd just be a matter of writing a stub that does whatever ..

Cool, so even a quick & dirty simu 'd be feasable )

bit of knowledge of emscripten to get it running nicely, and I'm a bit too busy at the moment to learn how to do it.

Haha, agreed & understood ! ^^
I didn't have time yet to try emscripten ( although I heard about it, as well as NaCl & Cie ? ), so it'd be the occasion to learn a little bit about it ;)
I did do a quick search right after seeing your post, which led me to the followings ( as a reminder for later or a skilled individual were to leave some hints on the subject .. )
https://github.com/google/pepper.js/wiki­/Development
http://flohofwoe.blogspot.fr/2013/01/mul­tithreading-in-emscripten-with-html5.htm­l
https://groups.google.com/forum/#!topic/­emscripten-discuss/gQQRjajQ6iY

I'll post the Espruino Original final SVG as soon as I get it done, & 'll follow by updating the Fritzing stuff & digg that tut' ;)

Cheers +

I just did the footprint ( SMD version ) of the Pico - would you tell me it it's precise enough ?

It looks ok, but honestly I have no idea how I'd check. Best bet would be to print it out to scale, place an unpinned Pico over it, and check it looks fine.

About the "visual pin feedback", yes, it'd indeed be done via a Serial msg callback to the laptop

Honestly, this would be a nightmare to do - if you sent back a message every time the pin changed state, the state changes would be so slow that the Pico would be effectively useless.

In simulation it'd be fine, but in real life I don't think it's useful. If you want the functionality it's better to just spend £50 on a logic analyser :)

even if the bootloader doesn't

I mean that while you can update the Pico's firmware - you can't easily update the bootloader (so its harder to brick the Pico :). That means that you will likely not be able to use the 10.6.8 to update the Pico's firmware, but once it is updated on another PC, you can use it fine.

hello there :)

print it out to scale, place an unpinned Pico over it

I guess it's indeed the best way to know :)

"visual pin feedback" ...

Makes sense ;) ( I'll digg that :) )

update the Pico's firmware ...

I'll do so right now & hope for the best ( & hopefully, be wrong about the chrome bug stuff .. )

On the Fritzing subject, it seems they just changed the ways stuff is done :/
http://fritzing.org/learning/tutorials/c­reating-custom-parts/
http://blog.fritzing.org/2012/10/09/new-­parts-editor-released/

So, I'll digg the aboves & do the necessary ;p