Search results for:

The file would need:
Boot loader,user1.bin,padding, user2.bin. It would not be able to be loaded onto the esp01 with 512k rom.

Not sure if this the bridging you are looking for, the Apple TV 3 & 4 are Apple HomeKit hubs... This is a project that talks HomeKit, that might be of some use:

https://github.com/aanon4/HomeKit

Rather than joining two bits.....

@tve
Here is an idea that would prevent the need to virtual addressing:
For the esp8266 module 512.. Everything stays the same.

If the EPROM is larger, use the current save code location, but extend from 12k to 16k, and keep the compressed code.
Then the next region I mentioned above, 16k could be used for saveBootCode and modules, and this area would not be compressed so the strings are directly usable.

@jumjum - it's good to know the release ones work...

Now, I wonder what is up with your versions? Have you got the math lib .o file that was introduced a while back - I guess you must have otherwise it would not build?

The other thing to try would be an erase first, then a flash.

Perhaps the new promise additions to the new 1.86 firmware would allow you to easily manage the queuing and next event via JavaScript?

Is the 512k version of the esp8266 still usable ( @jumjum) reported issues on gitter. (I've cooked my esp01 so I can't test).

If longer supported, there is a 20k block of flash that could be used:

0x07C000	496KB	16KB	512KB flash: Espressif SDK system params, else unused
0x080000	512KB	4KB	Unused

Perhaps this area could be used for E.setBootCode, or to store modules?

Also a set of duplicated Graphics functions with "2" appended (e.g. fillRect2()) that can be used in place of the standard functions, but allow for the inclusion of a color parameter to set the drawing color.

Why not create a pen object that you set the colour on, and then call the same function with the same arguments on that object. It's constructor could take the lcd as as a param and a colour.

@MaBe

Does it work with the standard firmware? Then you can be sure that the change is related to the new code..

I'm using 1v85.tve_master_124390c Copyright 2016 G.Williams with the 1.5.4 SDK, on a NodeMCU board.

I'm getting the same behaviour.

I wonder if this is related to the router model?

Get rid of the on init and save code- get it working on direct upload, as you might have issues with the pinmode setup.

You could swap out gpio15 for gpio9 - not sure what the nodemcu:dx pin that corresponds to..

Are you using the code above?
Keep the code the same, and you need the wiring to the pins:

GPIO4, GPIO5, and GPIO13, GPIO14, GPIO15.

It looks like GND, VCC and backlight are ok - as the display is on!

If you are powering everything off the FTDI board it might not have enough current to power everything.

Not sure what you are asking here - what is the issue you have?

Have you connect to wifi first? What ip address did you get?

@user65754

The current implementation is limited to 125 chars. To use larger the module would be need to be implemented to split the data over multiple packets which complicates things quite a bit.

Do you have a sample of the data you want to send? There might be a way of reducing the amount of data, especially if there are large text descriptors in the data. You can also store the data in a struct, and the convert that to json to send. The json can be self describing, so you could split your message into chunks that are under the 125 byte limitation.

@tve

1700 vars is better until you run out of memory each time you open several connections. That's what happens to me. 1700 vars doesn't work for me.

Are these inbound to the ESP8266 or outbound? Is it in AP mode Station Mode?

When you say running out of memory - are you running out of heap?

I think @tve is experimenting with the new sdk 1.5.4, and if all ok it will get rolled into the mainline build.

Disconnect usb and plug it in again then from the web ide set the serial speed to 115200 and connect.

You can see web requests, connecting to the SSID ESP and with a browser on http://192.168.4.1

if you then 'telnet 192.168.4.1 53', we can attempt to trigger the callback, however it's not called.

If the port is changed, to say 55 - the callback works.

This means that in AP mode the ESP is already listening on port 53, so it would require changes to the firmware to allow the captive type mode.

This fires up a web server and attempts to listen to DNS requests on port 53:

var counter = 1;
var wifi=require("wifi");
wifi.startAP('ESP');


function getPage(req,res) {
  console.log(req.url);
    res.writeHead(200, {'Content-Type': 'text/html'});
    res.write('<html><head><meta http-equiv="refresh" content="5"></head><body><img src="favicon.ico"/>'+(counter++)+'</body></html>');

  res.end();
}

require("http").createServer(getPage).listen(80);

var net=require('net');


function callbackdata(data) {
  console.log({data:data});
}

net.createServer(callbackdata).listen(53);

https://www.kickstarter.com/projects/1795343078/lopy-the-lora-wifi-and-bluetooth-iot-development-p/description

Or how about the dual core 512kb ram with Bluetooth module

http://www.aliexpress.com/store/product/ESP-32-wireless-Bluetooth-serial-WIFI-module-Transcend-ESP8266/1813344_32646340441.html

For those who has not sent this on gitter, here is a blog that talks about the insides...

http://tech.scargill.net/itead-slampher-and-sonoff/

The relay is on gpio12.

Also on dx.com
http://www.dx.com/p/diy-smart-wi-fi-wireless-switch-w-abs-shell-case-for-home-white-422387#.V1lWlcqeqrV

I think it will be a power supply issue. When espurino on the esp8266 boots for the first time, the AP mode is on which draws more current.

From memory the ftdi boards can can't supply enough current.

I can't claim the sonoff find - it's being discussed on gitter

https://gitter.im/espruino/Espruino

There is now thread here with people testing...

http://forum.espruino.com/conversations/288230/#comment13033307

https://www.itead.cc/sonoff-wifi-wireless-switch.html