1v85 release

Hi,

Just wondering how everyone is getting on with the current 'cutting edge' builds of Espruino? I haven't heard anything bad. I've been using them for a while and they seem pretty stable too.

I'd like to release a 1v85 version soon - which would hopefully include builds for micro:bit and ESP8266.

@tve are there commits that you have not applied to the esp8366 build that should be in for 1v85?

ESP8266 isn't perfect, but it's working remarkably well.

Update: I think these issues are severe enough that they should be considered prior to ESP8266 release:
https://github.com/espruino/Espruino/iss­ues/796 (analog read returns 1~1023 like Arduino)
https://github.com/espruino/Espruino/iss­ues/665 (no application-controllable serial)
https://github.com/espruino/Espruino/iss­ues/708 (no analogWrite() )

Main focus of ESP8266 is to support Wifi.
Mostly ESP-01s are sold, and this boards only have gpio0 and gpio2.
Also based on 1400 memory blocks only, ESP8266 will never be 1st choice if you want to have and use a lot of interfaces.
If you need analog and serial, pico is a better choice. Or may be wait for node32 from espressif.
IMHO, those 3 issues @DrAzzy mentioned, should not be a showstopper.

I don't thing wanting to use the hardware serial on the ESP8266 is unreasonable.

I'm flagging these up because these are omissions that make the Espruino on ESP8266 still feel like it is in a beta state.

Update: I think these issues are severe enough that they should be considered prior to ESP8266 release:
github.com/espruino/Espruino/issues/796 (analog read returns 1~1023 like Arduino)

I think on the later builds this has been addressed but not cross referenced on github....

I don't have any changes queued. I'm not aware of any show-stopper from the esp8266 point of view. There's no question that there are improvements to be made, but we have reached a usable state. Whether it continues to be called 'beta' or not, I don't have any string opinion :-).

@DrAzzy, sorry for a misunderstanding. I would like to have full serial support in ESP8266, no question. I have to connect an Espruino which works as a datalogger. Handshaking of data and commands between both is not smart, but it is doable.
Right now as a given fact, there is nobody having time, knowledge and interest to implement full serial support. Its the same status like other boards. Lot of them have restrictions, are not 100% compatible with Espruino Boards.
Still, main job of ESP8266 is Wifi and having in mind the price, Espruino working on this chip is great and helpful in projects. Last not least, in my experience, Espruino on ESP8266 is more reliable than nodemcu or standard firmware.
Using lack of full Serial support as a showstopper, would be (IMHO) an overkill and not helpful for Espruino itself.

Ok, I'll take a look at a release then - but I'll quickly change the analogRead thing, and tweak at least the serial receive handler.

I wonder whether all the comments on GitHub about wanting software serial would actually just go away if people used the existing hardware serial instead...

I think working hardware serial on ESP8266 would kill all or most of the demand for software serial from ESP8266 users. I see that you checked in a change to fix this. I'm looking forward to testing it. It looks like I'll need to get a build working.

I've also had some experience using software serial implementations on other platforms (arduino in particular) and realized how awful it tended to be. It's still a nice thing to have, but my feelings on it's importance have fallen dramatically after seeing other software serial implementations in action.

I'll quickly change the analogRead

Are you creating an A0 pin for this? I think that would be the cleanest solution since it's really a separate pin. If you do, please don't use pin number 16 to represent it but perhaps 17 or higher 'cause some day we may want to add D16 (which is not a true gpio pin but is often referred to as such in the esp8266 world).

I now see your commit and commented. Nice!

It looks like I'll need to get a build working

http://www.espruino.com/binaries/travis/­master/ ?

Are you creating an A0 pin for this?

That'd be nice - but right now the use of new Pin() screws us over. Espruino tends to store pins in order A0..x,B0..x,C..x,D..x - so adding A0 - at least as things are right now - would shift the pin numbers up and break everyone's code.

Also I bet ESP8266 code doesn't use pinInfo[pin].pin, so that'd need tweaking too.

Mind you, I just added the Pin() is deprecated text, so I could probably get away with it?

You don't think Pin() should be kept in order to be able to choose a pin dynamically? I.e. convert int to Pin?
Where is the code that decides that A pins come before D pins?

I think it's probably jspin.c. At some point (after the real_prototype_chain branch) I may just shove them in the symbol table and it'll be ok.

Well, I'm still keeping Pin, I just think it needs to do something to warn or people will keep using it on ESP8266. It won't error if you convert a string or float to a Pin, so you can still do that.

Or in fact you can just do digitalWrite(1,1) - it still works fine.

Pin() should be kept, I think - but it's something that the user should rarely be touching, since you can use pin numbers directly when referring to the pins (and it does the same thing behind the scenes), and there are already constants defined if you like them to have a letter in them.

Pin() with an integer argument is nigh useless on an STM32 - and maybe anything else except ESP8266?

Pin() with an integer argument is nigh useless on an STM32 - and maybe anything else except ESP8266?

Yes, pretty much. And it should really be useless on ESP8266 too, because A0 would usually be 0, making D0 1, and so on....

Having said that, Nordic chips are sensible and have pins numbered 0..31, so it does make some sense there.