Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

noPoll (WebSockets) and Roadmap? (GIT8266O-683) #1108

Open
Jasata opened this issue Jun 26, 2021 · 2 comments
Open

noPoll (WebSockets) and Roadmap? (GIT8266O-683) #1108

Jasata opened this issue Jun 26, 2021 · 2 comments

Comments

@Jasata
Copy link

Jasata commented Jun 26, 2021

Current /README.md tells us (under "Roadmap", item 3) that actions for v3.0 include updating some third-party libraries, one being listed is noPoll. This is the only occurrence of "nopoll" currently, which is to say that the current SDK version (v3.4) doesn't have it. A couple of issues also ask for WebSocket examples (#901 and #831).

Is the roadmap out-of-date, or does it refer to actions for v3.x versions in general? Is noPoll still in the plans, or should README.md be updated?

Is there a recommendation that could be given to those seeking noPoll / WebSocket solutions (if such advice is something else than "go do it with ESP32")? If so, could it be added to the README.md, for time being?

Personally, this item has some additional weight as ESP8266 are considered as a teaching material, and exercise planning brought this up. It would be nice to have an idea if WebSocket support is planned, or if it needs to be realized separately (in Spring 2022).

@github-actions github-actions bot changed the title noPoll (WebSockets) and Roadmap? noPoll (WebSockets) and Roadmap? (GIT8266O-683) Jun 26, 2021
@i3water
Copy link

i3water commented Jul 12, 2021

https://github.com/blinker-iot/blinker-esp-idf/tree/dev2.0/ESP8266/components/esp_http_server

i worte this websocket components(refer to ESP-IDF 4.3.0).Tested can run on ESP8266 with the example

18:21:29.325 -> �[0;32mI (45) boot: ESP-IDF v3.4-rc-dirty 2nd stage bootloader�[0m
18:21:29.325 -> �[0;32mI (45) boot: compile time 18:15:26�[0m
18:21:29.325 -> �[0;32mI (45) qio_mode: Enabling default flash chip QIO�[0m
18:21:29.325 -> �[0;32mI (53) boot: SPI Speed      : 40MHz�[0m
18:21:29.325 -> �[0;32mI (59) boot: SPI Mode       : QIO�[0m
18:21:29.359 -> �[0;32mI (65) boot: SPI Flash Size : 2MB�[0m
18:21:29.359 -> �[0;32mI (71) boot: Partition Table:�[0m
18:21:29.359 -> �[0;32mI (77) boot: ## Label            Usage          Type ST Offset   Length�[0m
18:21:29.359 -> �[0;32mI (88) boot:  0 nvs              WiFi data        01 02 00009000 00006000�[0m
18:21:29.394 -> �[0;32mI (100) boot:  1 phy_init         RF data          01 01 0000f000 00001000�[0m
18:21:29.394 -> �[0;32mI (111) boot:  2 factory          factory app      00 00 00010000 000f0000�[0m
18:21:29.394 -> �[0;32mI (123) boot: End of partition table�[0m
18:21:29.394 -> �[0;32mI (129) esp_image: segment 0: paddr=0x00010010 vaddr=0x40210010 size=0x5e008 (385032) map�[0m
18:21:29.533 -> �[0;32mI (274) esp_image: segment 1: paddr=0x0006e020 vaddr=0x4026e018 size=0x115c4 ( 71108) map�[0m
18:21:29.568 -> �[0;32mI (299) esp_image: segment 2: paddr=0x0007f5ec vaddr=0x3ffe8000 size=0x0063c (  1596) load�[0m
18:21:29.568 -> �[0;32mI (300) esp_image: segment 3: paddr=0x0007fc30 vaddr=0x40100000 size=0x00080 (   128) load�[0m
18:21:29.603 -> �[0;32mI (310) esp_image: segment 4: paddr=0x0007fcb8 vaddr=0x40100080 size=0x05560 ( 21856) load�[0m
18:21:29.603 -> �[0;32mI (331) boot: Loaded app from partition at offset 0x10000�[0m
18:21:29.638 -> �[0;32mI (355) system_api: Base MAC address is not set, read default base MAC address from EFUSE�[0m
18:21:29.672 -> �[0;32mI (357) system_api: Base MAC address is not set, read default base MAC address from EFUSE�[0m
18:21:29.707 -> phy_version: 1163.0, 665d56c, Jun 24 2020, 10:00:08, RTOS new
18:21:29.707 -> �[0;32mI (422) phy_init: phy ver: 1163_0�[0m
18:21:29.707 -> �[0;32mI (435) example_connect: Connecting to mostfun...�[0m
18:21:29.844 -> �[0;32mI (562) wifi:state: 0 -> 2 (b0)
18:21:29.844 -> �[0m�[0;32mI (564) wifi:state: 2 -> 3 (0)
18:21:29.844 -> �[0m�[0;32mI (566) wifi:state: 3 -> 5 (10)
18:21:29.879 -> �[0m�[0;32mI (577) wifi:connected with xxx, aid = 2, channel 11, HT20, bssid = 24:69:68:3b:94:eb
18:21:29.879 -> �[0m�[0;32mI (1347) tcpip_adapter: sta ip: 192.168.0.118, mask: 255.255.255.0, gw: 192.168.0.1�[0m
18:21:30.637 -> �[0;32mI (1349) example_connect: Connected to xxx�[0m
18:21:30.637 -> �[0;32mI (1352) example_connect: IPv4 address: 192.168.0.118�[0m
18:21:30.671 -> �[0;32mI (1361) ws_echo_server: Starting server on port: '80'�[0m
18:21:30.671 -> �[0;32mI (1373) ws_echo_server: Registering URI handlers�[0m
18:21:42.016 -> �[0;32mI (12710) ws_echo_server: Got packet with message: 123�[0m
18:21:42.016 -> �[0;32mI (12711) ws_echo_server: Packet type: 1�[0m
18:21:57.356 -> �[0;32mI (28048) ws_echo_server: Got packet with message: 123456789�[0m
18:21:57.356 -> �[0;32mI (28050) ws_echo_server: Packet type: 1�[0m

@Jasata
Copy link
Author

Jasata commented Jul 13, 2021

https://github.com/blinker-iot/blinker-esp-idf/tree/dev2.0/ESP8266/components/esp_http_server

i worte this websocket components(refer to ESP-IDF 4.3.0).Tested can run on ESP8266 with the example

ESP-IDF's http_server, with a lot of changes (diff between your changes and the ESP-IDF seems extensive). Having WS support in the SDK's HTTPD would of course be preferred to libraries.

Thank you - I will look into it this week!

I am still unclear about this SDK's roadmap or how it might progress. After writing this issue, a few other "missing pieces" have been encountered, and it is looking like perhaps we should get ESP32's instead of ESP8266's for the students. (...if we need to have all intended exercises planned for Spring 2022).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants