Most recent activity
-
try now :)
-
That is odd - I'm pretty sure I've had people doing exactly that and it's been fine.
The other thing you could try is http://www.espruino.com/Puck.js#hard-reset (do it after installing the espruino firmware version you want to use)
Windows always tries to create a secure connection to the Puck for Bluetooth HID, which means that encryption keys get stored on the Puck. I guess it's possible that something has gone wrong somehow and the Puck has the wrong keys stored - doing that hard reset should remove them and might help?
-
It's odd that I didn't experience any issues until recently though.
It might have been some recent changes in 'cutting edge' Espruino firmware. Espruino used to always get polled every 20ms when connected, which uses up a bunch of power. Now it polls every 7.5ms which makes everything way faster, but after a minute or so of inactivity it drops down to every 200ms until stuff happens again.
It means your Puck will now last a year on its battery even when it's connected, but if you just press the button after > 1 minute of inactivity then the sending of the button press and release will take 400ms. It's way more likely that you can press the button twice within that 400ms period :)
You can turn it back to default behavior with
NRF.setConnectionInterval(20)if you need to. -
My main concern was the time it takes to execute and the lack of any visual hint on that the browser is working on something
We could at least add that as a status indicator... Does it take a very long time then? Surely it's got to be better than the current web request to the closure compiler (which is also without any status indication)
-
could be a nice idea - I'll have a think! I've been meaning to try some contests - for example I reckon now tweets are 280 chars you could do some really interesting things in hardware JS :)
@Robin as @allObjects says, each command you write on the left-hand side after you upload is changing the state of the interpreter. If you thought that each command you typed was executed on a fresh instance of your code it could actually be a really big cause of the problems you're having.
Please check out some of the comments below - they might help.
>var tb = new TestBind(); =TestBind: { "vX": 25 } <---- was there a command missing here? =25 >tb.setX = 42; <---- after this, tb.setX is now set to 42. It's no longer a function =42 >print tb.getX(); <---- again, this is NOT how you use print or call a function in JS. if you want the console to say '=value' just type 'tb.getX()' - you don't need 'print' =25 >var bg = g.bind(tb); <---- as allObjects says - there must be some code here you're not posting up as you didn't define 'g' previously, but lets assume that code was 'g = tb.getX()'. 'g' will be 25, so is a number and won't have a 'bind' method Uncaught Error: Function "bind" not found! at line 1 col 12 var bg = g.bind(tb); ^ >print bg <---- not how you call print, as mentioned above. However the code above errored so you wouldn't expect it to have written anything to 'bg' =undefined >tb.setX(42); <---- If you did this right at the start, it would have worked. Since you called it after 'tb.setX = 42', 'tb.setX' is now 42 so it is not a function you can call Uncaught Error: Expecting a function to call, got Number at line 1 col 4 tb.setX(42); ^ -
Wow, sounds like a fun project!
I think that's something that would be doable on-chip with an Espruino device, but you may need to carefully craft some C/assembler code to handle the ASIC4 protocol.
As @allObjects says, something like the MDBT42Q boards/modules might be an option. It's not WiFi, but is very low power and would allow you to create a Bluetooth LE connection to a phone/desktop where you could use the phone's WiFi connection and storage?
The nRF52 used for Espruino's Bluetooth boards has some neat tricks up its sleeve too. The on-chip peripherals can be 'glued' together a little like with an FPGA - see http://www.espruino.com/NRF52LL
I'm not sure if it's good enough to use to decode/recreate the 12 bit packets (I doubt it) but it might be handy. It'd be ok if all you needed to do was receive, but handling the transmit side requires a very quick response.
Is the data always clocked out at 3.84MHz? It strikes me that the easiest way to handle it might be to just use Espruino's inline assembler. You could just arrange that your function gets called when the CLK line first changes state, then you could read in or output the bits of data one at a time, just inserting the odd
NOP(no-operation) command to pad everything out until the 12 bit packet had finished.Realistically in order for you to not go completely insane you're going to need to get a digital storage scope though so you can see what's going on!
... having said all that, small FPGAs are quite cheap (or CPLDs - basically the same but they definitely remember what they were programmed to do when powered off - not all FPGAs do). Decoding 12 bits of data is actually something that would be a really fun and instructive project to do with one of them.
-
Wow, nice idea! I'd say definitely go for Serial between Espruino and the Arduino - it's nice and easy to wire up, and to debug with a USB-TTL converter.
To be honest even the I2C reader & decoder on something like Pixl.js would be a great debug tool - you could plug it into any HDMI device and see what it was capable of.
I should really add I2C and SPI slave support to Espruino - the issue really has been how to handle it when the JS takes so long to execute. It could just be a bunch of registers since that's what most I2C devices seem to do - but anyway, that's sidetracking the thread - I guess it should be a GitHub issue.
-
Is there some obvious issue with the code from https://www.espruino.com/MCP23xxx (eg http://www.espruino.com/modules/MCP23017.js) that is causing it not to work?
If so it'd be good to get it fixed so others don't hit the same problems :)
-
I'd say the Seeed one looks good - they have a WiFi page on it here: http://wiki.seeedstudio.com/Relay_Shield_v3/
Where it mentions that it works fine on 3.3v Arduino boards.
There also seem to be a load of relay shields in that kind of layout/form factor - eg this one on eBay that look promising. I've ordered one to check it out - it's possible their little transistor circuit works in such a way that it tries to put 5v on Pixl.js's IO pins (which wouldn't be good news), but if they're sensible it should be fine.
If you can find any example code and sending a
1turns the relay on then you should be fine.
There isn't - it's more that the existing solution is there to work with
require- if we only uploaded tree-shaken code then you'd never be able to dorequire(x)on the left-hand side of the IDE. Also I bet it doesn't preserve line-numbers for debug/etc, so could only ever be an option (not the default).Trying to pull in NPM modules could be quite painful - again, we wouldn't want to reimplement NPM, but trying to include NPM, babel, etc in an online IDE would probably make it huge and slow.
Having a bundling solution does seem great though. Part of me wonders whether we wouldn't be better off if I just made it a service on the Espruino website? I could then use NPM, babel, closure, etc as-is. Only problem is that'd screw over ESP8266/ESP32 users because I'm not going to want to spend half my server time supporting them for free. I could happily open it to Patreon/etc users though, but I can imagine it'll still annoy a bunch of people.