Search results for:

Hi,

Recently we've had a whole lot of 'issues' posted on the Espruino forums that relate to the Espruino software running on the ESP8266. (This isn't the same as connecting a ESP8266 module to an Espruino board).

The port of Espruino is still under heavy development, and there are quite a few gotchas. Please look and post here for any issues related to it - you're much more likely to find an answer, and less likely to confuse any users who have bought an official Espruino board :)

@tve is there actually a separate A0 pin, or is it the same as D0? I wouldn't duplicate pin names - that'd just get confusing.

Cool - thanks for posting up! For others looking at this, the last 2 code snippets here are ESP8266-specific

Ok, I just filed an issue for this: https://github.com/espruino/Espruino/iss­ues/736

I'm not sure when I'll get around to it, but I'll see what can be done. It doesn't look like it'll be too painful to implement.

Depends what you're doing, but you could just convert both objects to a String with JSON.stringify and compare the strings?

Can you file a bug for instanceof? I'm kind of surprised about that - I thought those kind of issues had been ironed out a while back.

I think in JS, an array is Array, which is also an instance of Object. Espruino currently has a bit of a shonky prototype chain implementation, and it's possible instanceof has fallen foul of that.

Just to add, whether it is safe depends on jsAccessPointArray. If that hasn't been created or locked previously then you could end up unlocking too many times, which would probably cause an assert fail.

Yes, that looks fine to me. It's safe because jsiQueueEvents will add references to all the stuff it cares about, so even when unlocked it won't get freed.

In that case I'd consider using jsvUnLock3 though - it's stupid, but I changed all the multiple unlocks to calls to jsvUnLock2 and jsvUnLock3, and saved about 10kB of flash IIRC :)

Also there's jsvUnLockMany that you can use on arrays of JsVars

It is nasty though. If you get the latest from GitHub I added a few comments.

Just to add, I've now committed a DMX module that will work with 1v83 of Espruino when it is released (or the latest builds).

When 1v83 is released, the module will be available at this link.

It uses the 'framing error' hardware of the USART, so you don't need the resistor/capacitor.

The method above isn't bad or unreliable, it's just easier if you don't need any external components.

For the bullet points, I'm a bit lost. Actual code is here:

https://github.com/espruino/Espruino/blo­b/master/scripts/build_docs.py#L75-L87

So from what I can see if what you're doing, it should work if (like you seem to be doing) the line starts with *. Do you want to have a poke around? I can definitely stick it on my todo list, but I won't manage it tonight I'm afraid.

Honestly, up to you. Or WiFi. I was wondering about that but I have no real preference, just not wIfI or wIFI :)

Does ESP8266 support IPv6 at all? Currently internally Espruino uses uint32_t for IP addresses (so that's what the utility functions that do conversions expect), but if there's any chance of IPv6 that needs to change.

In terms of JS-land, strings all the way I think.

you always clear sendData

Ahh, but that's inside a if (!sendData) statement?

And the latest builds are now at: http://www.espruino.com/binaries/travis/­master/

Note: ironically Espruino and Pico builds won't work out of the box, because when flashed to the board they need offsetting by the bootloader size (16384 on the Pico, and 10240 on the Espruino board).

I don't understand github.com/espruino/Espruino/blob/master­/libs/network/socketserver.c#L660

I just looked at this again, and it's correct.

The else refers to the if (options). What it's saying is (in a roundabout way) is 'if we're an HTTP connection, send a header, else send nothing'.

If sendData is not undefined then we know the header has already been sent, and that if statement has no else on it.

For some reason the indentation there is confusing. I'll add some comments.

Just some thoughts here:

• Can getRSSI just be a field in getStatus? Seems odd to have a specific function for that one thing.
  
• Maybe onChange should be removed and wifi should just have events emitted on it, so you could do wifi.on('connected', ...)? You can document events via JSON - have a look at jswrap_http (I think).
  
• I know this wasn't in the Wiki version, but someone mentioned about positional parameters to connect and startAP - maybe the password/key should be in options instead, as it's not required if you connect to an insecure network?
  

Great!

For the async stuff - yes, you definitely need it async for devices connected on serial - as the processing of serial data only happens in the idle loop. Espruino (and also the ESP8266+GSM modules) would need some pretty major mods to fix that, but your optional callback sounds like a good idea... 'Use this to be portable, or if you don't care then just use the return value'.

With the doc formatting, it's because I have a really hacky markdown parser in build_docs.py. It'd be great if there was something simple that worked properly and could be pulled in (I'm tempted to use use node.js for building the docs, and marked works really well).

Is there a reason the network buffer for sending is so small:

It's that CC3000 needed a big static buffer to send the data (which I wanted to be as small as possible), but I think on non-CC3000 builds we could change that. If we could be sure the send function was only called from idle (I think it might be?) we'd be safe to allocate quite a large amount of data on the stack for that array.

The 500-odd bytes you talked about as the limit for packets on that ESP8266 build sounds good.

Why does clientRequestWrite in socketserver.c not kick off any transmission?

I think it's because when using GSM or ESP8266 via AT, JavaScript gets called to do the write - and so we don't fill the stack up it makes sense to do that on idle. People also tend to use multiple writes, when realistically you want to send in as few chunks as possible so you want to group writes together.

I don't understand github.com/espruino/Espruino/blob/master­/libs/network/socketserver.c#L660

Yes, that looks wrong - and a potential memory leak. I'm not sure why that hasn't caused problems before... It'd be interesting to see if we could trigger it with some code. I guess an HTTP chunked POST should do it?

the intermingling of HTTP into plain sockets is not exactly clean.

No... My reasoning was:

• There is still quite a lot of duplicated code in each and I was desperately trying to get code size down
  
• I wanted as few lists of sockets in memory as possible, so it made sense to stick them all in together and handle them as one.
  
  

But yeah, it was more of an issue before I abstracted out all the socket stuff, it seems a bit more pointless now.

I think MQTT should still be a JS module, as it currently is - the main addition would be WebSockets and UDP, but I think those should actually fit in quite well.

Just to add, you could also use E.toUint8Array() to prepare the array. You can do things like:

>E.toUint8Array([[1,2,3],[4,5,6],[7,8,9]­])
=new Uint8Array([1, 2, 3, 4, 5, 6, 7, 8, 9])

>E.toUint8Array([{data:[1,2,3], count:4},[7,8,9]])
=new Uint8Array([1, 2, 3, 1, 2, 3, 1, 2, 3, 1, 2, 3, 7, 8, 9])

Yes, maybe it's actually better for us to put the commit hash directly in the Espruino startup screen. After all, it's reported in process.env.GIT_COMMIT, I guess for non-release builds it could just be shoved in there?

Kind of - as far as I remember there was no actual description of the core, it was just one C++ file. I guess rather than a CPU designer, it was more of a way of designing hugely pipelined systems (while validating them very quickly by compiling to C).

Every variable represented a register and you could define how many bits was in each one, and what was attached to them (multiply, add, etc). Then, if you do myvariable = a*b it'd do a multiply using that multiplier (and any maths that you didn't tag would get assigned to the most suitable ALU available, or one would get made).

While you could just write C, you had to be prepared to look at the reports of hardware utilisation to get something working well - but when you did you could make something really fast and efficient - because you were designing a pipelined system you could get the clock rate right up near the maximum the FPGA could handle, with pretty much full utilisation.

I wish I could find it now, but I did a quick google and came up blank :(

It's the kind of thing that'd be really cool now - with that little bit more processing power it could run the compiler in the background and could give you a live update of exactly how your code mapped to hardware.

Yes, it should 'just work'. The only problem would be if the SIM900 didn't accept raw data when sending over a socket (maybe it wants some characters escaped), but I think you're probably safe.

Thanks, just done. It would actually be possible to come up with a new one-way serial driver for the online Web IDE, which would work on iOS - but then you don't get the serial console or any of the stuff that goes with that.

... but yes, it's quite likely that flashing to 0.25 would fix it, but ideally we could make the driver cope with 0v30 if that's what comes with Adafruit's boards now.

Wow, I never heard of that before, but what @DrAzzy says sound right (although it should still work at 9600 baud - albeit a bit slowly).

You could try running wifi.at.debug() to see what the module is sending back - it's possible it is working, but that after it boots it doesn't send the text ready. - for some reason they keep changing what it prints every so often!

Ahh, I'd have to look into that. mbedtls will definitely handle that - I just haven't exposed it.

Pull requests welcome :)