ESPRESSIF update for ESP8266

I have to say the people at Expressif are starting to be really helpful – SO – if you are using the binaries of their AT software (released today) – the loading addresses stay the same – ie…

boot.bin—>0x00000
user1.bin—>0x01000
default.bin—>0x7c000
blank.bin—>0x7e000

Default baud rate is 115200

I hope that is useful. They are making other updates I’ve requested and will release update for CYGWIN next week. I can’t wait! For example this might lend the possibility to easily add port bit control to their existing AT software – and possibly even finally get to understand the IOT demo and put it on a useful baud rate!

Programming Tool for ESP8266

I’m a Windows guy – no, I don’t want to use a command line or a Linux VM if possible thank you. And so it was that I’ve been using Coolterm – and very nice too – for programming the little ESP8266 boards. The problem comes when you have to type the same thing over and over or in the case of LUA programming, wrap the whole lot in some prefix or suffix like wrapping “end” in “file.writeline([[end]]” etc.

tmpF342So a couple of nights ago  I made a start on my own serial terminal – so in thanks for the advice that people have sent in as I’ve gone down the route of learning about these devices, here’s the first stab at my contribution. It’s a bog-standard install, if works on Windows 7 and 8 – NO guarantees, NO support right now… but if you want it, it’s yours.

Run the setup, it should appear. Set your baud rate and possibly COM port, press OPEN and if you have that all correct you should be able to talk to your board by putting AT into the left box and pressing SEND. You can put multiple lines in the left box, you can CLEAR the left and right boxes. You can inject text (left dropdown box) into the left box (left arrow) – or fire straight out to the ESP8266 with the little right arrow.

If you prefix a line in the left box with + (left most column for now) then that LUA wrapper stuff will be added when it is sent out – and in any case – ANY stuff going out to the 8266 will have a line by line delay of 300ms or whatever you set in the top right box (you need to close, set the value, open).

both the delay and baud rate are persistent but you’ll have to set the port every time if you have more than one until I figure out how to automate that. And that hopefully should make life a little easier for some of you. As time goes on I may well improve this and I’ll put a note in here to say what I’ve done.  The Dropbox link is here. Note this will NOT work on XP as apparently said operating system does not support .NET 4.5 – sorry.

12:11PM – Update on ESP8266, ESPRESSIF will in a couple of days update their docs to put in the things I’ve been hammering about in other entries – I’ve also asked them if they’ll explain the CYGWIN stuff a little better as I can’t compile code with it (errors). I have to say this is starting to go somewhere.

Weekend ESP8266

Early start this morning..   the LUA Interpreter which can help make the ESP8266 run stand-alone has been updated – but just minor fixes – so it will still have the memory leak issue I referred to in an earlier blog.

Meanwhile ESPRESSIF have been busy – yesterday they released a new version of the AT command set – but that had bugs – which I and others reported and about an hour ago, a version came out which seems to work. However they’ve still not documented where to put the BIN files and for a while a “user2.bin” file appeared which now seems to have gone.  I’m busy testing the code – but for those of you who are trying to compile your own in Windows – the code does not compile in the new CYGWIN environment – I have no idea if this new update  compiles in the Linux environments. Why would I be interested? Because there are no commands in there to talk to the ports and it really would be nice to be able to interrogate or set GPIO0 and GPIO2 for example.  I’ve noted also they’ve introduced a transparent TCP/IP – Serial link but only in one mode – that of server mode where the ESP8266 sets an address for the connection. To me, the LISTENER version would have been far more helpful – however, the updates SEEM to work – if you spot any bugs (please only in the latest version here do let us know in the blog.

ESP8266 for Windows

I could not believe my luck when the email appeared – one of my readers let me know there’s a Windows environment for the ESP8266 AT LAST. No more messing with VMs.

Excitedly I downloaded the package here and followed the instructions TO THE LETTER (that’s important). I ran the batch file and LO – a DOS box popped up on my Windows 7 machine – and… I could compile the code !!!

Well, I saw some open and closing directories – whereas the instructions for MAKE suggested it might take 5 minutes or so…. I tried the second instruction and that looked more promising ….and yes, it generated BINARIES – two of them. That was a bit worrying as the AT demo has more binaries than that. Anyway, the FLASHER popped up and I blew the firmware for the board, SO excited.. and..

Nothing. Can’t see any common sense at 9600, 56k or 115k. Something’s coming out of the board initially but it doesn’t make any sense.

Want to give it a try and tell me what happens? And if you figure it out – come in here and let everyone else know so finally we can get on and experiment without having to delve into Linux… yes, despite the setback – I’m still excited…

ESP8266 New AT Code

Is there new firmware out for the ESP8266? You bet.

tmpC94CThe new Espressif AT code is out for the ESP8266 boards – this I understand is largely a development of the code they had me testing a week or so ago but there is new stuff in there – only one problem – here is the code – but the instructions for loading the BIN files indicate using only 3 files – and they DO seem to work.. which begs the question what are the others for?

This is a major update – the BUSY is still there and still unexplained but like the test version I had, it’s not a show stopper any more.

This does leave me with some questions however  here’s the code.  There is a transparent SERVER mode but as far as I can tell no transparent LISTENER mode – and yet that surely would be the most obvious use – if you’re using a micro to talk to this board, then you might want a mobile device to send instructions… and have responses sent back… it would be the LISTENER mode that would allow that as the mobile would always initiate the conversation.

There is also the ability to set the Soft Access point NAME – but it doesn’t work properly – it adds a “0” on the end – it’s still usable but that needs fixing.

Anyone any thoughts on that, have I missed something?

What is happening with ESP8266 Development

Lots of exciting possibilities for the little chip but nothing concrete. The FRANKENSTEIN development gets more promising by the day, he’s even thinking about adding a LUA interpreter to his own offering. The LUA development has seen nothing new for a couple of days. The fellow who developed the original web server using the ESP8266 (NOT the LUA version) has made no further changes as far as I’m aware and his implementation has a severe issue in that if you do not already have an IP address setup, it can’t do a search for access points. Meanwhile today, in theory, ESPRESSIF will put out an update to their AT command set code.

Could be an interesting weekend. For links to everything see my previous blog posts.

Regards

Peter Scargill

Another ESP8266 Ray of Hope

As I’ve been testing code for the ESP-01 boards, I’ve had a few false starts but this week the LUA implementation is getting so close,

Meanwhile, ESPRESSIF should have some updates on Friday but today’s conversation with ANDREW of FRANKENSTEIN fame has been the most interesting. He’s put some updates on there further to a discussion we’ve been having (you’ll see it in the relevant area on Github)  and that’s now coming along (use Putty to test, NOT Coolterm). His plan is for a transparent Serial <—> TCP/IP bridge which is exactly what I need for my own purposes – and if you think about it – a winner for internal comms between devices.  None of this is working yet but as you’ll see in the blog  – he’s onto it –  suggest getting in there and offering encouragement to both Andrew and Zeroday to get their code sorted… we could all win from this.

Meanwhile we’re looking at a little board design to harbour the ESP-01 with a half-decent regulator and level shifting… more on that when we get a prototype up.

I’m out of here until Friday now, short trip to Brussels to test some new EU Dispute Resolution software and test out my new Canon camera (if it’s not raining).

Feel free to follow me on Google+ if you want to see more stuff on home control etc. https://plus.google.com/+PeterScargill/posts

The Tuesday ESP8266 Update

As of yesterday (Tuesday) there is a better version of the LUA software (see previous blog items here) but it still has serious memory issues – it’s not stopping me running a little controller from my phone – but there’s no way it would run for more than a few days without running out of memory – I’m fairly confident that will get fixed soon – the designer is fixing some and he’s contacted Espressif for others. Meanwhile the Frankenstein implementation is still far from complete (https://github.com/nekromant/esp8266-frankenstein) but at least now he has a readme file which explains why the output always looked like crap to me – I was using the wrong terminal program! I think this one is still very much a work in progress.  Espressif themselves will be releasing an update of their AT command set software based on a version I’ve been testing – that comes out Friday.. so lots going on! Meanwhile my colleague has taken the plunge and ordered a short run of Atmega1284 boards with a socket for the WIFI units – talk about faith!

08:22AM Wednesday – Update on the Frankenstein code – it crashes at the drop of a hat. On the other hand the writer Andrew was quick to respond and will now fix the issue I had.

Busy..S ESP8266

For those of you who have been struggling to get the ESPRESSIF AT command set working with the pesky BUSY…S problem on the little ESP8266 and similar boards, I’ve been testing various versions with them and last week they produced what was called TEST3.  The problem did not disappear entirely but it definitely stopped the ESP-01 boards from locking up completely  – i.e. the busy message went away pretty quickly. I’m guessing you could poll it. In the AT demo my code worked.  This morning they wrote to me to acknowledge that the current release of their software still has the BUSY…S issue but that this Friday they’ll be releasing a new version based on the test code. Espressif do of course also produce the SDK but you must have to be very patient to want to wade through all of that.

Suggest you keep an eye out for it.

Meanwhile the LUA implementation of the socket listener I detailed earlier is still working – I’ve left it sitting there and occasionally check my APP to see if it will talk to the board. It will. I have modified the code to actually turn 2 LEDS on and off – ie on ports GPIO0 and GPIO2 and they absolutely work.  Elsewhere, Dave Allan has detailed how the soldering expert can grab back some more I/O pins. Use of the socket code can still lead to eventual memory degradation at this point however. I’m also having problems getting input from the serial line without it being interpreted.. so for example io.read() does not work – the interpreter seems to know nothing about io.  Any input to the serial is run through the interpreter. That makes it pretty much impossible to use the code to talk to, say an arduino.

ESP8266 Monday Woes and a LIGHT at the end?

I’m not having a lot of luck with any of the firmware implementations at the minute for the little ESP8266 board. ESPRESSIF have gone quiet with one possible exception.

I sent queries about the attempt at a replacement for the Expressif v9.2.2 code – nothing all weekend and nothing this morning.

There is an IGGR update to his AT command set but I had problems with that – awaiting a response..

And then there is LUA – there is a new slight update out today (just blow the one firmware file in the folder onto your board) – NOT a fix for RAM issues but read on – you may find it worthwhile.

In my example I have a mobile phone app which sends 4 status requests GO1 GO2 GO3 and GO4 constantly when the App is displaying –  it’s asking for the status of 4 inputs – and expects a “1” or a “0” (in all cases followed by a single return “/n”).  It also might get a request to turn one of those outputs on or of. Requests are simple “YES1”, “NO1”, “YES2”,”NO2” etc. again followed by “\n” – I’ve used this kind of approach with 200ms polling for responses – for much of my home control using hardwired ETHERNET and my goal has always been to replicate this on the ESP8266  (I also need to grab the time but given RAM issues we’ll park that for now.

I tried the example of a port listener on port 4000 for one simple dummy output.
 

  l1=”0\n”
     sv=net.createServer(net.TCP, 90)    — 30s time out for a inactive client
     sv:listen(4000,function(c)
      c:on(“receive”, function(sck, pl)
                    print(pl)
                    if (pl==”GO1\n”) then c:send(l1)
                    elseif pl==”YES1\n” then l1=”1\n” c:send(“OK\n”)
                    elseif pl==”NO1\n” then l1=”0\n” c:send(“OK\n”)
                    else c:send(“0\n”)               
                    end
                    end)
      end)

Absolutely worked a TREAT over several minutes – returning the right information to my mobile phone All – and that’s on polls every 200ms. GREAT.  So I changed the code to handle 4 “devices”..

    l1=”0\n”
    l2=”0\n”
    l3=”0\n”
    l4=”0\n”
     sv=net.createServer(net.TCP, 90)    — 30s time out for a inactive client
     sv:listen(4000,function(c)
      c:on(“receive”, function(sck, pl)
                    print(pl)
                    if (pl==”GO1\n”) then c:send(l1)
                    elseif pl==”GO2\n” then c:send(l2)
                    elseif pl==”GO3\n” then c:send(l3)
                    elseif pl==”GO4\n” then c:send(l4)       
                    elseif pl==”YES1\n” then l1=”1\n” c:send(“OK\n”)
                    elseif pl==”NO1\n” then l1=”0\n” c:send(“OK\n”)
                    elseif pl==”YES2\n” then l2=”1\n” c:send(“OK\n”)
                    elseif pl==”NO2\n” then l2=”0\n” c:send(“OK\n”)
                    elseif pl==”YES3\n” then l3=”1\n” c:send(“OK\n”)
                    elseif pl==”NO3\n” then l3=”0\n” c:send(“OK\n”)
                    elseif pl==”YES4\n” then l4=”1\n” c:send(“OK\n”)
                    elseif pl==”NO4\n” then l4=”0\n” c:send(“OK\n”)
                    else c:send(“0\n”)               
                    end
                    end)
      end)

WELL – The interpreter never got to that last line in bold – instead – the ESP-01 exploded – sorry, rebooted – I tried this several times and it always reboots in the same place.  I’m thinking.. RAM!

And so here was my guess and a helpful fellow in the forums came to the same conclusion!!  I figured that as the code was being built up to be executed, it was being built up in RAM – and there’s a PAINFUL shortage of RAM – I’d seen a recommendation elsewhere to store things as files and run them from there…. using dofile   ie dofile(“fred.lua”)

So I stored the lot as a file (always ensure you remove any previous version first)

>
> file.remove(“mylistener.lua”)
> file.open(“mylistener.lua”,”w”)
> file.writeline([[l1=”0\n”]])
> file.writeline([[l2=”0\n”]])
> file.writeline([[l3=”0\n”]])
> file.writeline([[l4=”0\n”]])
> file.writeline([[sv=net.createServer(net.TCP, 90) ]])
> file.writeline([[sv:listen(4000,function(c)]])
> file.writeline([[c:on(“receive”, function(sck, pl) ]])
> file.writeline([[print(pl) ]])
> file.writeline([[if (pl==”GO1\n”) then c:send(l1) ]])
> file.writeline([[elseif pl==”GO2\n” then c:send(l2)]])
> file.writeline([[elseif pl==”GO3\n” then c:send(l3)]])
> file.writeline([[elseif pl==”GO4\n” then c:send(l4) ]])
> file.writeline([[elseif pl==”YES1\n” then l1=”1\n” c:send(“OK\n”) ]])
> file.writeline([[elseif pl==”NO1\n” then l1=”0\n” c:send(“OK\n”) ]])
> file.writeline([[elseif pl==”YES2\n” then l2=”1\n” c:send(“OK\n”) ]])
> file.writeline([[elseif pl==”NO2\n” then l2=”0\n” c:send(“OK\n”) ]])
> file.writeline([[elseif pl==”YES3\n” then l3=”1\n” c:send(“OK\n”)]])
> file.writeline([[elseif pl==”NO3\n” then l3=”0\n” c:send(“OK\n”)]])
> file.writeline([[elseif pl==”YES4\n” then l4=”1\n” c:send(“OK\n”)]])
> file.writeline([[elseif pl==”NO4\n” then l4=”0\n” c:send(“OK\n”)]])
> file.writeline([[else c:send(“0\n”)]])
> file.writeline([[end]])
> file.writeline([[end)]])
> file.writeline([[end)]])
> file.close()

That worked – looked like my RAM theory was correct.  All that remained was to say dofile(“mylistener.lua”)

So I added that to my startup..

file.remove(“init.lua”)
file.open(“init.lua”,”w”)
file.writeline([[print(“Pete’s LUA module 0.1”)]])
file.writeline([[tmr.alarm(4000, 0, function() dofile(“thelot.lua”) dofile(“mylistener.lua”) end )]])  
file.close()

The bit in bold is the bit I added. THELOT.LUA is another file that sets up the connection. And THAT worked.

Note the added dofile on the right.  Works – from power-up the board is now a listener able to make effective responses.!

I have hammered this to DEATH – I turned the phone off, swapped apps, left it off for 5 minutes at a time…unbelievably this will NOT fall over.

But what I really need is for the board to get one of those requests in – and then instead of sending out a fixed response I want it to wait for the serial to provide that response OR send a message to say no response was forthcoming!!! That’s so I can use it with an Arduino… flashing a couple of lights on the little board is FUN and if we get temperature sensing code for the little Dallas chips, a light and a sensor might indeed be all we need for some jobs – but the time will come – some of my setups have MANY I/O combinations – an Arduino would be the perfect companion here.  That is my next challenge – not a clue right now how to do that….  so despite the CHRONIC lack of RAM – and the DESPERATE NEED of this interpreter to crash… it DOES look as if it is possible to make it work… I am, right now, unable to crash this particular example!!!

Of course the REAL world tool will need to be WAY more complex… what if there is no connection? What if one has not been setup – we’ll need a screen to list the access points and select one… now THAT bit could be fun right now with the shortage of RAM and the heap management issues. BUT it’s a start!!! and all of this at 9600 serial (of course in a working scenario there would be no need for serial display).

And what of the memory bug? Ram slowly going down the tubes?  I’ve held off on writing this blog until I’d given it a hammering – the loop has run thousands of times now… still working. For the first time since I started with this little board and at times I’ve been THAT far off throwing it in the fire…   I think we might be onto something here. Much to be done but it’s a start.

05:06PM – There is a memory loss going on here if I turn the phone app on and off… repeatedly.. check this out…. the number is the amount of RAM left in bytes.

8456
GO1

8456
GO2

8456
GO3

8456
GO4

8456
GO1

8456
GO2

6112
GO1

6112
GO3

6112
GO4

6112
GO2

6112
GO1

6112
GO3

6112