-
That'd be great - thanks!
The module itself isn't in a great state, and I've had some trouble getting the SIM900 modules I bought working here (region problems) so I haven't really been able to do much about it. Not sure if it helps, but the ESP8266WiFi_0v25 module might help out as I think it tries to handle a lot of things in a more sane way.
-
-
Yes, the
No navigator.getUserMedia
log message is the problem there.Looking at the demo which does work, it doesn't do any recording. Maybe if you can find a
getUserMedia
demo that works online I can see what they do differently, but I think in all likelihood, Apple have chosen not to implement it on iOS. -
Ahh, it's because
jshReset
hasn't been implemented on ESP8266. It should reset the hardware to power-on states.As I usually say...
If you bought a proper Espruino Board, this would be working correctly :)
I'm moving this thread to the Porting area of the forum for now - it's an ESP8266-specific issue that I'm sure will be fixed soon.
-
The thing I worked on did both actually - it'd create HDL based on the code you provided, and would make opcodes for that special soft core, but in a relatively optimised way.
It gave a neat little report of all the ALUs and their usage each clock cycle, and then you could use macros to give the compiler hints, like 'do this add on that adder unit'.
... so it effectively let you design the processor and a VLIW code in parallel. As I understood it, it made it into Altera's set of tools soon after I left - but it's been 10 years since so I have no idea what's happened to it now!
-
dump()
tries to work out what the pins were set to by looking at the state of the hardware. My guess is that D12-14 are used for something like the serial port, but the Espruino compile for the ESP8266 that you're using isn't aware of that.For @Kolban and @tve it's to do with the
IS_PIN_USED_INTERNALLY
macro created bybuild_platform_config
-
-
-
-
-
-
-
It seems to get the size down the DigiSpark does something strange with USB, but I think the main culprit is the voltage regulator. Bigger voltage regulators tend to waste quite a bit of power - I had to put quite an expensive regulator on the Pico to get a high-ish current while still not drawing much power.
What kind of sampling speed did you have in mind for the Pico? You can do some very basic processing at ~10kHz speeds (check out http://www.espruino.com/Waveform) in JavaScript, but realistically if you want higher you're going to have to compile your own firmware with C code in it, and maybe access the hardware directly.
There's no RTOS (well, Espruino is the RTOS) but you can schedule tasks to happen every so often in an IRQ, so it makes life easier for you.
It's not that bad, but you need to be pretty used to writing embedded code to get that C working nicely.
As far as the choice of JS: It's just about accessibility - way more people know JavaScript than C, and it works well with a REPL - which was a lot of the point of Espruino. Espruino isn't that fast at execution (MicroPython will be faster) but it is extremely efficient when it comes to memory usage because of the way it executes directly from source.
If you're interested in the internals, you could look at http://www.espruino.com/Performance and http://www.espruino.com/Internals pages
-
-
I don't know if it helps, but @DrAzzy makes these prototype boards that have SOIC pinouts on them as well as space for a Pico - as far as I know, they're 0.05" pitch.
-
-
-
@Kolban there's some code in network.c that will properly format the Mac address into a string. Check out how WIZnet does it
networkPutAddressAsString(data, "mac", &gWIZNETINFO.mac[0], 6, 16, ':');
-
Yes, absolutely! I'm using the PMEG3005AEA on the rev 1v4 boards, which is a bit better.
Link from Farnell is: http://uk.farnell.com/nxp/pmeg3005aea/diode-schottky-sod-323/dp/8737975
-
Yes, 536 MSS is definitely the way to go! As things currently stand, Espruino's never going to fill up even those packets.
As far as builds go, I'll include the binary in the download bundle and on the Espruino site itself. I still need to polish http://www.espruino.com/binaries/travis/ but when that is done with symlinks to the latest build I think we should put builds there and retire EspruinoBuilds - so it's then the same as every other board.
I looked at doing GitHub uploads from travis, but as @tve said it's a bit of an abuse of GitHub, and it also seemed a bit awkward to do.
-
Hi Jon, that's a really odd one.
I think first steps would be to check
gsm.debug()
and to see what the current state of the sockets is (socks
- you'll need to know what the socket number was but you could see that from the debug data). If it'swait
or not true then somehow theCONNECT OK
got missed - maybe it had extra stuff on the start of the line?Otherwise it's a matter of poking around in the actual HTTP implementation, but I'm not sure that would be an issue as it's been used quite a lot to date. The SIM900 module is by far the mode likely culprit.
If you are in the
Wait
state, maybe start adding print statements to the connect code to see where it's got to.Hope that's some help - let us know how you get on!
What are your changes? If you could contribute them back it'd be great - anything that cleans up the SIM900 code or makes it more reliable would be great.
-
-
On the latest version 1v82 of Espruino?
var foo = ["keep", "onInit", "SPI", "SPI2", "Ethernet", "eth", "Server", "Socket", "Serial", "Pipe", "LoopbackA", "LoopbackB", "fullreset", "reset"]; foo.forEach(function(n) { console.log(n, foo.indexOf(n)); }); keep 0 onInit 1 SPI 2 SPI2 3 Ethernet 4 eth 5 Server 6 Socket 7 Serial 8 Pipe 9 LoopbackA 10 LoopbackB 11 fullreset 12 reset 13
So for me, that works perfectly. I tried it with
Object.keys(global)
too and it works fine. -
I'm not sure I really understand the question... If you want to use arrays of arrays, you could just write a small bit of code to convert them into one single array before sending.
You might also be able to use
lodash
directly - I haven't looked at it (it's possible it's too big though).