-
• #52
Just thought I'd let you know about this posting "An SDK for the ESP8266 WiFi Chip"
http://hackaday.com/2014/10/25/an-sdk-for-the-esp8266-wifi-chip/
-
• #53
Wow, thanks! I'd heard hints that people were working on it, but it's great to see it finally here.
When I get some time (not sure when now!) I'll have a play with it - I think there's not enough flash to fit Espruino in, but it's worth a try :)
-
• #54
Another more expensive module, maybe this would support Espruino http://2xod.com/articles/Arduino_Wifi_With_Hi_Flying_HF-LPT100_or_USR-WIFI232/
-
• #55
Looks interesting... And UART-based too. If it uses standard AT commands it could work using the same drivers as the the ESP8266,
-
• #58
From what I read in the docs, it uses MICO which an RTOS + wifi.
They reserved 768 Kbytes for MICO and I suppose some user application among which Espruino could run.
Specifically, there is 384 Kbytes reserved for OTA updates (section 5).Yet, this is a whole new development.
Just setting up a new compiling environment for this new processor/firmware will take a while. -
• #59
I'm trying @JumJum 's code init function allways return false. I'm a newbie, I don't know if my device works and wired properly.
I have tracked the code, I see that code enter in to sendCommandWaitFor() function but it never enters inside sp.on('data',function(d){}); function.
I think it means that I can send command but it doesn't return any data. So, my device doesn't wired properly or not working.Is my logic right?
-
• #60
Yes, my logic was right. It was about wiring problem. Code works fine for me except of getting IP address. I'm now trying to get an IP address.
-
• #61
Ok, great. If you're not getting an IP address it's going to be either:
- Problems with your WiFi access point name and key
- Insufficient power on the 3.3v line
- Problems with your WiFi access point name and key
-
• #62
How usable is this module? I have a project where I need WiFi but also need the 2 SPI ports so this UART WiFi would be perfect.
-
• #63
I think it's pretty good - but right now, while you can use it with Espruino the support isn't great.
It'll be sorted in a few months though, in time for the Espruino Pico.
-
• #64
Ah cool Thanks!
-
• #65
Just bought a few ESP8266 for an upcoming project. Great that Espruino can connect it fine! May I ask is it possible, at current stage or in near future, to support the Soft AP mode as well? Thanks!
For anyone who is interested attached please find a quick start guide made by one of the vendors. The part on making it a TCP server is on Page 9 and that on being an access point is on Page 10.
1 Attachment
-
• #66
It's possible right now if you send the relevant commands to the serial port yourself after the ESP8266 is initialiased. It's not part of the API right now, but I've made a bug for this: https://github.com/espruino/Espruino/issues/491
-
• #67
Thanks. Definitely agree at least an API like
wlan.sendCommand("AT+...", timeout, function(result) {});
would be so useful, not only for APs but other customizations too. -
• #68
Hmm, I've just been trying to get some ESP8266 modules working with my 1.3 board, but it doesn't seem to be working. I've tried both 1.73 and 1.72 ESP8266 builds but they don't work and the IDE says "Module ESP8266 not found".
I'm confused because I am using the right binary and I have a healthy regulator delivering 3.285v? Anyone have any advice?
-
• #69
My understanding of a 'build for a device' is that the functionality is built-in (in low level implementation) and does not need to be
required("ModuleName");
- also implied to me by the fact that there is a ESP8266 Class with .connect() method in Espruino Reference. Over time stuff that was available (in 'older' versions through a loadable module became integrated in 'newer' version in the firmware / build. I may be going on a limb, but I notice(d) that with the experienced growth, (available) documentation becomes outdated - and misleading - because it it is a lot of work keeping it up in all corners. -
• #70
Did you load the 8266 binary ?
http://www.espruino.com/binaries/espruino_1v73_espruino_1r3_esp8266.bin -
• #71
functionality is built-in (in low level implementation) and does not need to be required("ModuleName");
No, it still needs to be
require
d - there was a regression in a few versions that meant that it didn't, but that's fixed in the newer versions.I just tried with the binary linked above - specifically
http://www.espruino.com/binaries/espruino_1v73_espruino_1r3_esp8266.bin
(the forum re-writes links) and it does work. Maybe when you pasted in the URL you then clicked the normalFlash Firmware
button and not theAdvanced Flash Firmware
button? -
• #72
In order to get true low power wifi, the esp8266 module will have to be put into LIGHT_SLEEP mode. This brings power consumption to under 0.9mA between DTIM beacons. However, this means that we have to implement UART with the hardware flow control pins (RTS/CTS), so that the espruino can wake the esp8266 when sending AT commands over UART. Another advantage is that the espruino pico can go to sleep too and wait to be interrupted on the RTS pin when the esp8266 has new data to send.
Has anyone found the flow control pins on the Esp8266 breakout board? Does the espruino libraries have RTS support for ultra low power UART?
http://tinker.yeoman.com.au/2015/03/08/reducing-esp8266-power-consumption-using-deep-sleep/
-
• #74
There are two USARTs (well there's a third, but it doesn't work if using USB).
USART1 (ie, Serial1) can be used on pins B6, B7, or you can use just the receive on A10.
USART2 (ie, Serial2) can be used on pins A2, A3.You got the error because you were trying to set serial2 to use the B6, B7. Or you had TX/RX backwards.
-
• #75
@heri16 using deep sleep looks interesting. However the module that came with the Pico KickStarter is the ESP01, which doesn't have the relevant pins brought out. To use it you'd have to do this really nasty hack, or just buy and wire up the different ESP module used in that post.
Really interesting point about using RTS/CTS to wake Espruino though. That means Espruino itself can do deep sleep too (it can't wake on serial activity because by the time it has woken it's lost the first byte).
@JackJamesHoward I think @DrAzzy's answered your main question, but USART1 is listed twice because even though there are only 2 distinct USARTs, they can often be re-mapped to different pins. Same for SPI + I2C peripherals as well.
AT+CWJAP has a delay in new version before OK is returned.
In my test I could get IP adress (AT+CIFSR) directly after reading OK.
But I cannot see any confirmation in their docu about that.
Other guys recommend to call AT+CIFSR until you get an IP, and return error if this takes more than 10 secs.