Search results for:

hello :)

Nicely done !
( special mention to the "keys" used to link a code to text to be displayed on the LCD ;) )

Also, it makes me realize really gotta try Espruino on the ESP8266 NodeMCU board ^^
( I'll see if I can do so later today , & try your code as well ;) )

This being said, do you have any experience with the Apple Dock connector ?

Thinking about the way you handled the "keys", we could print the received IR code key first, and then the answer from the Dock Tx/Rx stuff

Also, thinking about some older code for keypad matrices, It could be nice to map "long button presses" on the IR remote to different codes to be sent from the dock connector ( allowing to control most of the dock's available stuff with our std remotes :p )

+

Hi there :)

I have a nearly finished "Apple Remote" module ( currently only for the old IR remote ) & an ongoing "AppleDock" module hosted at the following repo: https://github.com/stephaneAG/iDeviceRemote.

While the remote module just needs some polish, the dock one has currently just the codes added, and as I'm not that confident in translating the original code all on my own ( & pretty sure it's bread & butter for some fellas ;p ), any help/contribution is hugely welcome :D

I'm still waiting for the "pod breakouts" ordered, and 'll be posting updates as soon as I get those & corresponding code working :)

Well, 5:35 -> "Now goin' to sleep mode" ;p

cheers +

Hi there :)

Thanks for the link on capacitive sensing on the Pico -> it seems to be precisely what I've been looking after :D
I wonder how close the same code 'd be for the original Espruino board ..

Now, while your suggestions are worth the look, I did find a "softpot" in my mess & took that as an opportunity for a quick hardware POC / to focus on the software ( on the laptop ).

The softpot used seems pretty sensible from the test I ran, & right now I'm trying to think of the simplest way to track "cross limit" finger movements:https://github.com/stephaneAG/Espruino_tests/tree/master/SoftPotTest

The idea is to periodically read the analog value coming from the sensor & forward it's state
If it's smaller than previous one, then we are moving CW, else CCW.
Depending on the difference between the previous value and the current one, we can deduce the speed of the movement.

Once the above is done "correctly" ( handling some special cases & thresholds .. ), I have an ongoing http://stephaneadamgarnier.com/ScratchyWAA/playMp3.htmlPOC for the software running on the laptop

The idea is basically to load an audio file, get its buffer's channels data & build up a reversed version, and then allow to mess with the playbackRate of both while "playing" ( actually connecting to the speakers as AudioContext.destination ) one of those alternatively.
( the above seems needed since we can't set the playbackRate.value to negative values .. ).

The end goal being able to either change playback rate & direction as well as "seek" to specific parts of the buffer or it's reversed version.

As far as I could check, the "seek()" fcn is available for elements, and the only way to do the same stuff with the Web Audio API is to create another buffer ( since we can't use "start(time)" more than once on a specific audio buffer ) for each "seeking action".

Since we're talking about the Web Audio API, I started to digg the code used for Audio Jack Rx, to learn a little more about the "ScriptProcessor" & "onaudioprocess" stuff ( .. ) :)

As I was wondering if it may be better to save a reversed audio file & then load both original & reversed in separate elements, I started diggin how to save audio files from stuff done using the web audio APi, and ended up to a link pointing to some PCM stuff :)
-> I wonder if we can make use of that to be able to write a little tool that'd convert audio for proper playback from SD ( instead of overkill Audacity .. ) ?

-> so, any experience on saving audio files / Web Audio API "seek" / above stuff anyone ? :D

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/creating-custom-parts/
http://blog.fritzing.org/2012/10/09/new-parts-editor-released/

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

Hi there !

@allObjects Thanks ;)

I plan to bring out the connections for [A4..B8] as a square of 4 pins on each side of the board, right next to the GPIN & GPOUT of the MAX, 8 pins each on both sides of the USB host plug

Somehow a reason: I don't know yet which pins require special capabilities & also didn't add the SD nor a bluetooth/wifi footprint yet :/ ( SD/Ble/wifi as three logging/extras capabilities 'd be neat :) )

Indeed, having the "square" pins & the GPI/O in double header configuration 'd mean no longer breadboard friendly ( although, the goal here is to minimize the size, but it's an idea to digg ;p )

I am currently wondering how to add the SD ( & what about using a flex ribbon cable to be able to "slip" it it some enclosure, right above the USB host plug )

here's an updated version of the pcb layout

Nb: I don't know the "best" footprint to use for the caps & the resistors ( I'm not used to SMD stuff yet ;p ), if you have any hints, they 're welcome :)

https://123d.circuits.io/circuits/2182347-espruino-pico-usb-host-sd-shim#pcb

back ;)

The updated version of the shematic & pcb using a correct Pico footprint is available at the following url https://123d.circuits.io/circuits/2182347-espruino-pico-usb-host-sd-shim

Also, I wonder what'd be the best way to position the micro SD slot while still allowing access to the LEDs, the button, as well as the back side of the Pico .. any hint / fork is welcome ;)

There's also the question of MAX_GPIN's & MAX_GPOUT's as well as the unused pins of the Pico

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-footprint - 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/multithreading-in-emscripten-with-html5.html
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 +

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_tests/blob/master/EspruinoMimetism/EspruinoBoards_wip.ai :) - I wonder if Github 'll follow Google in previewing .ai .. )

I could find the following thread http://forum.fritzing.org/t/espruino-pico-microcontroller-board-anyone/123 which points here https://github.com/fritzing/fritzing-parts/blob/master/core/EspruinoPico_8fb644a5b6642112445ed6d90bc494d8_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_breadboard.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 +

Hi there :)

First of all, these links seems to be worth of reading ( even if I didn't have time to do so - don't get everything ;p ):
MAX3421E.pdf
game controller to USB mouse
USB Enumeration Code (and More) for the MAX3420E
Programming Guide

And the above links are from this page: MAX3421E.html

I did a quick circuit with was seems to be the bare minimum from the schematics I could find, it's hosted at the following url https://123d.circuits.io/circuits/2108375-espruino-pico-usb-host-shim/edit#schematic

Now, I already did a "schematic view component" for the Espruino Pico on 123DCircuits, but I didn't ( I know that's a shame, but I don't know Eagle .. yet ? :| ) add a correct PCB footprint for it ( got one, but no correctly sized, yet I need a clean one if I want that shim ;p ) .. any soul willing to help me ( and many others who use that neat tool, yayyyyy ^^) on this ?

Also, concerning the USB plug placement, I'm wondering what's best between a tinier yet fatter result, or a longer but thinner one .. ( and also what about having the plug "in the middle" of one end of the shim ? -> gotta draw some stuff from theses thoughts, to make that clearer ;) )

Code side, I wonder if it's best to digg the Arduino sources before/after/while reading the official docs, but at least for now, I don't know enough in SMT low level stuff to be of any help I'm afraid :/ ..

Hi there !

As said in the title, I'm working on a project that'd be pretty much a dumb controller for a laptop connected

To achieve my goal ( playing normally / in reverse audio & altering the play speed in ~realtime ), I need the following capabilities:

• detect touch on the discs ( presumably done using capacitive sensing )
  
• detect rotation speed & direction of the discs ( ' got my little idea on that, somewhat inspired of our multimeters wheel - more on this in a later post ;p )
  
• rotate the discs at a certain speed & a certain direction - as well as use them as "force feedbacks" ( when the disc is touched, to make exponentially harder turning the disc by hand as it goes far forward/ backward the original "touch position" )
  
  

After digging a little, there seems to be many ways to do the three above steps, but I'd like to design the different parts separately / check their alternatives before having the complete circuit ;)

• on the capacitive touch side of things, I have to test an "RC oscillator + freq comparator" circuit to see if I can rely on that, but I was wondering how hard it'd be to implm a freq comparator in Espruino ( or even write a lib that - as the CapSense lib does for the Arduino - uses a capacitive voltage divider & a touchpad directly connected to one of the uC pins ) ?

• to detect rotation speed & direction while still being able to drive the motors to turn the discs, I plan to use traces on the bottom face of the discs that'd connect to 3 different points of a voltage divider which 'd in turn pass a specific voltage to a uC pin: sensing the 3 different voltages 'd provide info on the direction, while the change rate of the voltage 'd indicate the rotation speed. This being said, it seems we can also use motors as sensors, but gotta digg & test that to know how precise it can be ( .. )

• to drive the motors ( which 'd be steppers I guess, to be able to drive them slowly ) normally, no troubles ( I hope ), but to use them as "force feedback", I'm wondering how to make sure I don't damage them

Lastly, to have sort of a vinyl aspect, I originally planned to use conductive paste on a black non-conductive material & "draw concentric circles by removing matter", but it didn't end up well just while testing with acrylic paint on a copper plate I found in my junk stuff ( there are blobs of paint in places, & the result is not as clean as expected )
I'll have to test with the cutting tool instead of a sharp wood stick to see if it renders better, or even cut in the copper plate & then get it tainted black while preserving touch capability ? ( .. )

Right now, I'm testing my plan to detect rotation speed & dir, starting by using some conductive ink ( & hoping it 'll work as intended ;p )

Last but not least, any hint is very welcome :D

Thanks for the reading ;)

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_tests/tree/master/EspruinoMimetism

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_t­ests/tree/master/EspruinoMimetism

Cheers,

Hi there !

I was ( and am still ) looking for the most practical ways to sense voltage, current & wattage, and ended up using the "Power Gauge" from Adafruit ( provides an nice TTL output to read from )
if it's of any use, I wrote the following Espruino code for it https://github.com/stephaneAG/Espruino_tests/blob/master/currentMeasurement/powerConsumption.js

While this is nice ( & I still have to code stuff to connect directly to the Power Gauge A0 pin - directly connected to the INA169 "Current Shunt Monitor" ), I'm still looking for alternative ways to doing so, starting with:

• a custom implm of the circuit that uses an INA169 https://123d.circuits.io/circuits/2078847-current-measurement-circuit-ina169-version ( not yet tested - code should be close as below one )

• a custom implm of a circuit that does nearly the same job https://123d.circuits.io/circuits/2045597-current-measurement-circuit-ad623-version ( to be tested soon - code related ( converted from Arduino ) not yet tested here https://github.com/stephaneAG/Espruino_tests/blob/master/currentMeasurement/getAmps.js )

• using a hall effect sensor to be able to take measurement while not directly connected

• have a clean hack to know exactly how much a power supply provides ? ( I know we gotta digg the specs for that, but I'm still wondering, convinced that the reason I don't know is my lack of knowledge on this, if there's some trick out there to doing so ;p )

Any thoughts ? :)

Back ! :)

@allObjects I meant we could ease the use of the GPIOs the way we write the lib ;)

Also related to the MAX3421e:
https://www.circuitsathome.com/chome_downloads/UHS_mini_10.pdf
https://www.sparkfun.com/datasheets/DevTools/Arduino/USBHostShield-v13.pdf

As the guy(s) behind https://www.circuitsathome.com/products-page/arduino-shields/usb-host-shield-for-arduino-pro-mini have surely a good idea of caveats / hints on implementing it, I just sent them a mail, asking politely for stuff & forwarded the topic :)

@Gordon the following shield uses a different chip but is provided flashed to support different stuff http://www.hobbytronics.co.uk/usb-host-mini

I also wonder if the shim should still provide access to some of the Pico pins not used ( in other words, have wider, 2 row pinouts on edges of the Pico, providing access to the GPIOs of the MAX' ) ?

Anyway, I plan to add the schematics found in the datasheet / the Sparkfun's one / the CircuitsAtHome's one to a repo on 123D Circuits to easily share & update stuff on this ( .. )

Lastly ( not that related - only to Espruino ;p ): I had a little fun messing with a simple RGB LED ( common cathode ) with Espruino yesterday, and as I couldn't see any tutorial on these on the Espruino website ( yet there are at least 5 tuts on adressable LEDs ^^ ), the infos ( while really basic ) & the code may be helpful to others ( and may be also hugely improved I guess) :D
--> https://github.com/stephaneAG/Espruino_tests/blob/master/dummyRgbLEDsTests/fadeRgbLEDs_Espruino.js
Nb: the code is loosely adapted from the Adafruit's one ( thx guys ;p ) https://learn.adafruit.com/rgb-led-strips/example-code, and this one is also of interest https://learn.adafruit.com/adafruit-arduino-lesson-3-rgb-leds/arduino-sketch

:)

.. indeed a challenge :|

also, I just stumbled upon the following, which has a nice form factor ( although I'd prefer to have the Pico on top )

@allObjects yeah, the GPIOs are a neat thing to have, moreover if we can control those as easy as the Pico's own pins ( I guess for that, we may benefit from going "lower level ? " - though the USB inputs may already require us to do so .. )

for the part itself, I guess I'll have to check the european resellers for small qttys () since it seems I can't find it on ebay ? :/ .. )

Hi there !

I was about to write a post on USB host stuff, but I got my info from above:

Espruino doesn't support being a USB host, so it's not possible to capture anything from USB devices.

While this is a pretty clear answer, and while I was hoping some hack existed to handle that, I'm still wondering how long it'd take / how hard it'd be to use a max3421e & handle it via SPI ?

Actually, if this was possible, I was planning to design a little shim that'd go on the back of the Pico to allow it to get keyboard key presses & log/save those to the flash or an SD ? ^^ , & also have the ability to "replay" them back later ( also, the ability to handle "key combos" to change modes 'd be neat ( .. ) )
-> so yes, a keygrabber :D

I plan to digg that when I have enough time to ( & also finish that SIM800L lib ;p)

I'll be back when I receive the good stuff ( or as soon as I see nome neat feeback here ;p )

Cheers +

Hello

I wasn't sure about .replace(/\n/g, "\x1B\x0A"): I just saw it was used in the code of the IDE when sending & was wondering what it exactly aimed for -> now I know, and that's not what I wanna do :)
Now that I do know, I won't, and 'll just forward the file's content to the Espruino "as is" :D

For the flash part ,I bet it'd be harder to implm, and I actually don't need that ( but I'll dig the code anyway, hoping to get a glimpse of what's happening ^^ )

For the Already sending data - calling callback immediately!"that I got on os x in the console logs while I can't write to / receive from it ( yet able to connect to it ), now I know it's not related ( I thought it may be somehow (..) ).

For the "throttled send queue", understood :)
I did "deferred calls" based on time, not buffer fillness, a while ago, so I get the point, although I'll have to see how I handled the callback there (..)

On the Mac os x 10.6.8 troubles, I made some tiny progresses:

• I wrote a reminder on how to allow/debug serial ports access: https://github.com/stephaneAG/Arduino
  
• I tried modding the USBFTDI .kext to add a definition for the Pico, but it seems the .kext is unloaded as soon as it's loaded ( ?! )
  
• I tried using the Espruino IDE's console to talk to a connected Espruino: it worked flawlessly !
  
  

So, my last guess is it comes from Chrome / some of its dependencies ( else I wouldn't be able to talk to the device using "native" apps that rely on the OS's implm ):

I'll try reinstalling it & see if the troubles goes away

Lastly, I'm currently adding the step-by-step instruction on how to build Me4e, and thanks to you I'll be posting the sources of the desktop app soon :)

Keep up the good work ++

Hi

Sorry to hear about that, it's just not fair to do so !

Additionally to the given credit & donation links, if they also still forwards to your repos & left the compiler linking to use your computing power, they could have at least forward part of the money they'll be making from the boards to support the project :/

Did you have the chance to have a chat with them ?

For what it's worth, I'll be supporting the project, & buy official boards ( additionally to ESPs ;p )

Also, did they even add some modules or participate with some lib ? ..

Wishing you the best on this ( .. )

a little update:

I can now send stuff to Espruino from Ubuntu using:

 chrome.serial.write(str2ab("<some expression>;\r"), callback)

and with a simple listener, I also get the callbacks ;D
( I'll try few stuff to have dynamic listeners to check for specific callbacks later ( .. ) )

I currently use Gordon's implm of str2ab ( found in the 'serial_chrome.js' ) as it handle some chars stuff that the chrome examples implms doesn't, but gotta try the other just to know if it'd work ^^

The issue is still not solved on os x 10.6.8 & I filed some stuff hoping to get a feedback ( among other forums, the issue may be close to this one: https://bugs.chromium.org/p/chromium/issues/detail?id=448698 )

+Gordon Nope, you're right: I want the minimum overhead possible, so just the bare minimum to send commands & send a file, and maybe later flash the board ( like in the Web IDE ).
On this subject, am I the only one interested in getting the minimized code sent from the IDE to Espruino saved to an external file ? this 'd ease sending minimized/optimized files afterward without the need for the complete IDE to be installed/run

As sending commands is almost done now, so I'm starting to digg how to replicate 'sendFile()' & 'flash()'
My two contexts are the D&D of a file on the chrome app:

var dnd = new DnDFileController('body', function(data) {
  var fileEntry = data.items[0].webkitGetAsEntry();
  displayPath(fileEntry); // display the fullpath to the entry
  // display the contents of the file
  fileEntry.file(function(file) {
    var reader = new FileReader();
    reader.onerror = errorHandler;
    reader.onloadend = function(e) {
      console.log(e.target.result);
      var theCode = "reset();\n" + "echo(0);\n" + e.target.result.replace(/\n/g, "\x1B\x0A") + "echo(1);\n" + "save();\r"; // code ready to be uploaded to the Espruino (nb: doesn't save any previous config nor update settings except those present in the file )
    };

    reader.readAsText(file);
  });
});

and getting one from the sandboxed fs:

theFs.root.getFile('/Firmwares/fakeFirmware.js', {}, function(fileEntry) {
  fileEntry.file(function(file) {
    var reader = new FileReader();
    reader.onloadend = function(e) {
      console.log(this.result);
      var toUpload = "reset();\n" + "echo(0);\n" + this.result.replace(/\n/g, "\x1B\x0A") + "echo(1);\n" + "save();\r"; // code ready to be uploaded to the Espruino (nb: doesn't save any previous config nor update settings except those present in the file )
    };
    reader.readAsText(file);     
  }, errorHandler);
}, errorHandler);

For 'sendFile()', can I send everything at once using the above concatenated stuff or do I have to do it line by line / by chunks ( or "throttled" serial write ) ?
( for 'flash()', I guess I'll see later, but I feel it'd be a little more complex .. :p )
Also, I based the above stuff from codeWriter.js

// ..to tell Espruino it's a new line but not to execute ( as Alt+Enter or Ctrl+LF ): stuff.replace(/\n/g, "\x1B\x0A");

Lastly, and this is the end of this post to keep it short, I noticed that the message I had in the Web IDE running on os x 10.6.8 comes from a call that resides in the serial.js file at line 147 ( https://github.com/espruino/EspruinoTools/blob/gh-pages/core/serial.js )

console.error("Already sending data - calling callback immediately!");

I was wondering why this fcn 'd be called in the context of the Espruino web IDE in its Chrome packaged app version, since calls should normally invoke functions declared in serial_chrome.js to use the chrome serial api ( as both are loaded in main.html, and as I didn't stumble upon the code that'd choose one or the other depending on some criterias ( line 66 of serial.js ? ) ).
This may be totally normal, but I never saw this in the console of the IDE while on Ubuntu, so if this could lead to solving some issues, I can't afford not to ask :)

looking forward to solving those & reading for yall ;p

all right .. just got my post erased by some CSRF verification that failed .. :/

thanks for the quick answer :)

+DrAzzy
it mays comes from ~4 vectors:
-mac app store install / update => possible kext bogus ?

• chrome version no longer supported => so can't comm over serial ?
  -electron install => did it mess with stg ?
  
• me trying to fix stuff but diggin my grave ..
  I'm still digging & trying, and 'll post a/the fix as soon as I get it/one ;)
  
  

+Gordon
currently trying to figure out the fcn call invoked by a click on the 'icon deploy' in the Web IDE, I'm trying to get EspruinoTool working with the minimum possible overhead to mix it easily with my chrome app ( it seems I have huge trouble in doing so, since stuff loads correctly only if I use the Web IDE src entirely :/ )
What I actually need is just the sendFile / expr / flash abilities ( and the libs used by those )

I'll post the src of the app & a screenshot/gif of it on the dedicate repo after a quick rest, and I'd be glad to find some useful hint lying here for me to catch ;D

If I recall correctly, porting from nw.js to electron 'd be a matter of using "nodeglyph stuff" ( no sure on this ), but I'm not confident enough in doing so ( I was trying to use Electron + serial before writing a chrome app, but Electron is not supported on Mac Os X 10.6.8 and I didn't have the time yet to try on Ubuntu )

As I think I'm nearly finished with the brains of Me4e, if I could have it's desktop app working at least on Ubuntu by the end of the week end it'd be great ;)
-> I really want the "upload animation" to actually do stg in the app ;p ( see gif on the repo ;p )

+

Hi again

I tried my best but something's just not right with Chrome Packaged Apps & serial on the OS X install I have: I can access an Arduino or an Espruino using screen, but can't neither receive or send to/from them in any Chrome Packaged App

I noticed it may come from the rights given to the /dev/tty.usbmodem131 ( Arduino ) or /dev/tty.usbmodem1431 ( Pico ), but it seems I just can't get them right ( although I did see a blink when connecting to an Arduino using Chrome Serial API & issuing a chmod 777 on the Arduino port beforehand .. :/ )

Too bad, since aside from this, the "big part" was checking how to push code to a connected pico & call js on it from the Me4e chrome app :|
-> on this, if I'm correct, I just have to include the espruino tools js file in my app & call 'CodeWriter.writeToEspruino()' when needed, right ?

I'll try to fix the above stuff as soon as I get some deserved rest ;p

Any help very welcome :D

hello

a quick update:

1: Me4e now has a repo & a gh-page website, with useful links:
http://stephaneag.github.io/I-Me4e/#v01a

2: as it seems I can't have electron apps running on my old 10.6.8 OS X install ( not supported by Electron as far as I can read in the different versions of the docs ), I guess I'll have to try mixing them with node-serial [ & fixing stuff if needed ] later & on linux ..
.. hence I did a quick Chrome Packaged App to handle updating the code on the Espruino ( using serial ), updating some settings ( stored on the SD card, through espruino's serial conn. ), getting latest stuff ( "firmware(s)" & settings config(s) ) from github, ..

It's available at: https://raw.githubusercontent.com/stephaneAG/I-Me4e/master/app/Me4e.crx
( code 'll be on github soon )

3: still on Mac OS X 10.6.8, I have a weird error in the Espruino Web IDE & neither can I update nor communicate with connected & recognized boards.
During my tests, I can use 'screen' to connect to it & do stuff ( without prefixing it with 'sudo' ), but using the IDe throws the message picture in the joined file & doesn't allow to either type in the left-hand side or upload code written on the right-hand side :/
"ERROR: Already sending data - calling callback immediately!"

Qu is: may it come from a "non properly closed" previous seiral conn. or do I have to use some "sudo usermod -aG " ?
( I noticed a difference while issuing a 'ls -l', I got .. " tty .." for most stuff in /dev/* but ".. root wheel .." for the tty associated with the connected Espruino ).

I noticed the espruino.rules file ( https://github.com/espruino/Espruino/blob/master/misc/45-espruino.rules ) to prevent it from appearing as "STM32 Virtual ComPort", but I wonder if it 'd work, with changed to reflect the productId & vendorId I have using the chrome serial API.

I really hope this only happens to "old" versions of OS X or to find some simple solution to this, to simply the end user usage ;)

4: on the repap-side of things, I stumbled upon the following link, which may interest some of us ;)https://github.com/lhartmann/esp8266_reprap

this being said, gottta start uploading the pics for the step by step instructions .. ;D

looking forward to reading your inputs ;)

Hi there !

+the1laz
thanks !
I did see this & sent myself a mail to digg it, but yet didn't took the time to even watch the video ..
.. and I just did: this tool seems pretty cool, especially when I saw the code tab pop ;)

'll have to digg that too :)

nb: I'd love to see some algo that organizes the mess left once you've done some concluding tests with the FPGA used ( not personally a fan of "linked nodes" UIs, but maybe it's caused by some known nib builder .. ;p )

Hi there !

+DrAzzy
-> sure , I did actually bought some on ebay ( of different diameter, also ;p ), but it never happened to me before to have only this type & not being able to make a correct & quick solder between multiple elements ( joining stuff to already soldered stuff has never been such a pain ! :/ ), plus I had to be done before late evening to make it for Valentine's day .. -> :|
-> on the hot glue stuff, I totally agree, I should have put some on all the pins to make it more bulletproof, but here I guess I had the chance to stuff enough cotton to keep stuff in place, plus the head doesn't contain any squeezable stuff [ on this version ? ;p ], so it shouldn't experience as much stress as the other parts.
-> still on the hot glue topic, I ended up sewing a little pouch for the battery to keep it in place internally ( I have sort of sections of cotton & sewed the parts that shouldn't move, like body sensor ), as I wasn't confident in hotglue-ing it to anything ( in my mind, hot glue + battery = incoming troubles ? )

+Gordon
-> thanks, I must say I had quite a fun time ( aside from the strees in the planned delivery time ) ;)
-> I'll have to digg how many flash is used by the Arduino implm of µSpeech ( as an average example ), yet using the Pico's flash is a indeed very neat idea ( gotta study that ;) )
-> yeah, µSpeech seems pretty neat considering its lightweight ( although I didn't tests it personaly yet ).I digged a little bit the online docs ( where there's a section on porting it ), & very quickly through the actual code: it seems quite simple when its author explains it, and quite remarkable in the usage => I gotta test that :P
-> thanks for the hint on E.sum, I'l hope it'll pop in my mind when needed ;p

=> now gotta try a quick implm of a audio 2/3 tracks webapp* for a friend of mine, I'll post updates when I have time to achive them :)

=> I'll also post the wip of Me4e on HaD.io at the following URL ( still gotta upload the pics & label the steps with few (yes, few ;p ) useful comments ): https://hackaday.io/project/9726-ime4e

• if anyone has a working & nice way to save audio files out of the Web Audio API ( also working on iOS/android)**, let me know :D
  ** ' already got some S.O. tabs open & gotta take some notes outta them in the meantime ;p
  
  

This being said, gotta make that bear dance .. ;p

+

Hi there !
Haha, sorry for that, I'll do my best to avoid that, starting now ;)

I have few points that can be explained "briefly" ( :p ):

-for the CNC & WiFi printing stuff, I have some stuff to digg, some note written down, ' just need some time mixing that up & taking hardware limitations in huge consideation ;)

• for the power supply/charger, it indeed sems to work great ( it did during my tests on directly connecting to USB / charge battery, & use battery ), and is quite simpler that other alternatives ( thanks to using the USB pins as well as an external uC handling battery stuff properly ).
  Side note on this, the chip used on the Adafruit shield I'm using is a MCP73831, & requires a bare minimum of 2 caps & 2 resistors to work ok ( from what I could see studying the Adafruit datasheet )

• for the "keeping it powered & when done ..", I'll have to digg the Pico's "Deep Sleep" ( & how to catch some pins activity while it's waking up, be them tied to btns or mikes .. )
  => the FET solution seems like a nice alternative / pretty close to what I had in mind ( & better, since we have a FET onboard already ^^ ), though I don't know enough yet on FET to my taste .. ( nor do I on NPNs & PNPs, but I feel more familiar to them :) )

• for the mikes, connecting was easy enough ( hum, 3 wires, one Gnd, one +V, where could we possibly use the third ? .. /!\ a tiny-tiny Pico ADC pin ^^ ), but I was talking about some existing lib ( that may use Waveform internally, for ex ) that 'd be pretty close to the Arduino's "µSpeech" lib ( I guess I'll just have port it / write a little one if not ( .. still gotta finish that SIM800L stuff :/ .. ) )

• on Me4e ( the cute pluche :D ), I'm gonna have to write the following:

• simple GUI on desktop [/tablets/phones] to flash the "brains" of it ( Pico ) via USB ( desktop ) & audio ( tablets / phones )

• way to flash it as well using a file stored on the SD card ( ' already got some tests code on that ( .. ) )

• "companion app" ( if I can't / need more that the above µSpeech stuff )

My question(s) is on the said "companion app": I plan 2 scenarii of using it in tandem with the pluche:
-A: talk to Me4e -> it streams audio to phone -> the app converts to txt, parses it, & send back some commands/data to Me4e -> Me4e then does/says stuff
-B: talk to phone app directly -------------->

Now, as you guessed already, I'm wondering if the ESP8266 can be used in such manner ( seeing stuff like http://hackaday.com/2015/06/06/esp8266-as-a-networked-mp3-decoder/) is interesting .. ), and whether or not it requires additional flash AND hardware fixes for flow control or other finicky stuff ( .. )

• lastly ( and I really hope I achieved a tinier post than the prev one ): I added some quick POC code to the SingleButtonMulticodesCombinationLock ( ^^! ) to handle patterns from different pins ( .. )
  
  

This being said, here's a few pics on the Me4e project, and while the schematic & pluche is done, I still have to write that brain of his ;p
I guess 'll be posting a detailled explanation of the project on HaD.io ( .. )

Looking forward to reading from you soon, thanks for the quick support when I needed it ( thanks to that I did indeed make it in time for Valentine's day ;) )

Cheers, & keep up the good work :D

ps: also, ' got 2 more Pico's coming, some Z-tape, and I really wanna try a circuit made of conductive ink laid down using the hacked CNC ;P
ps2: remember me to hang myself when I only have lead free solder left ..

++