i was looking for a web server working with B4R and i found a good candidate with aWOT library for arduino.
result: raWOT is a wrapper for aWOT library from Lasse Lukkari
full library with examples : https://github.com/lasselukkari/aWOT
full documentation : https://awot.net/
with aWOT we can create a web server working on Wifi or Ehternet, and on a large panel of boards.
aWOT is able manage GET, HEAD, POST, PUT, DELETE, PATCH, OPTIONS, ALL, USE
Under Arduino aWOT can support multiple clients, but i was not able to make it working with B4R.
on arduino side, management of this libray is done by multiple callbacks: one callback is created for each routing created and one callback is created for each middleware created.
On B4R it is not possible to used dynamic callback managed by pointer: for B4R, in raWOT we have only one callback for all middlewares and we can select one middleware with an index. (256 index possible)
at last, result is the same, just in middleware callback, we have to make a select/case on index to send callback to the good sub.
with aWOT, we have 5 types of objects to manage:
Application : This class is used for mounting Middleware / Routers and to process the incoming HTTP requests.
in B4R, Application can address Routers and Middleware by an index number
Router: this class is used for mounting Routers, to make complementary routing, or to mount final Middleware
we can have 256 routers index in B4R and each router can address routers or middlewares
Middleware: this object is a sub called by callback from conditions define by app and rout. It is a sub to handle request/response of server
we can have 256 middlewares index in B4R and each index will address a sub
Response: this class is used in Middleware callback to manage server responses
Request: this class is used in Middleware callback to manage server requests
In aWOT we have 4 class to manage server:
app.xxxx
rout.xxx
rep.xxxx
req.xxxx
in raWOT the 4 class are in the same class raWOT and conversion index/pointer is done in wrapper.
aWOT.app_xxxx
aWOT.rout_xxxx
aWOT.rep_xxxx
aWOT.req_xxxx
To manage web server, at end we have a tree in this way in appstart:
app => Mid_01
app => Mid_02
app => Rout_2
Rout_2 => Mid14
Rout_2 => Mid15
Rout_2 => Rout_3
Rout_3 => Mid_13
Rout_3 => Mid_16
app => Rout_4
Rout_4 => Mid10
Rout_4 => Mid11
Rout_4 => Mid12
Rout_4 => Rou5
Rout_5 => Mid_17
Rout_5 => Mid_18
Rout_5 => Rout_6
Rout_6 => Mid_19
Rout_6 => Mid_20
each middleware sub will handle Request part and Response part
raWOT handle 99% of aWOT library functions
tests were done on esp8266 and esp32 with Firefox/Edge navigators on a PC and with B4R project "testaWOT" in esp (added at Zip)
summary of tests done:
- redirection page to page
- get
- post
- upload of file from PC to eeprom esp
- download of file from eeprom esp to Firefox on PC
i think we can do a lot more with this library, but i am not expert of html/javascript.
i hope this wrapper can help the community and at last, it was a very good exercise for me
21/11/27 new version with option to send html code to library in string or in arraybyte
included 2 test codes with direct string and also with strings stored with PROGMEM
in both cases, it don't take more than 200bytes for stack
08/12/2021 new version with some improvements:
a few modifications were done on wrapper raWOT:
a mime management is added to provide content-type from file ext
a function ClientIP provide IP of client connected
improvement of function req_form: now buffers include string received and spaces after
now we have 4 demo for test of raWOT in diffents configurations:
one demo with html/css/js included in B4R source
same demo with html/css/js included in PROGMEM storage, in code part
same demo with html/css/js included in html file in flash of esp and managed by littleFS
same demo with html/css/js included in gzip file, in flash of esp and managed by littleFS
this demo include :
an authentication page
a menu to access at all demo pages
a page multi-inputs to define a configuration of esp
a page with text input
a page to show/define led status
a page to show/define pins status
a page to manage files in flash with littleFS
a page to show loading of pictures
some traces are added to check what is received in webserver from navigator
2 process are used for GET/POST:
- GET/POST launched from a form
- GET/POST launched from XMLHttpRequest
with current library,
1) each connection client <=> is closed at end of actions planed in webserver and an other client can be connected
=> we can manage several clients in parallel
2) client IP is provider to B4R interface
=> answer of webserver can be depending of client IP
3) a parameter <head><meta http-equiv='refresh' content='60' can be added in html page and client will reload the page every 60sec
=> websever can know clients connected to server
=> with the 3 inputs, we can make basic multi-client in webserver side
to avoid multi manipulations of strings, (ans stack increasing) wrapper accept several interfaces :
- we have print() and println() to avoid joinstring/joinbytes
- string, for strings in B4R code
- Arraybyte, for strings in B4R code
- Arraybyte, from PROGMEM storage
=> a tool can help et transfert of string Code => PROGMEM and also PROGMEM to Code
- file transfert direct from LittleFS file
(index.htm, style.css, picture.png files can be downloaded from LittleFS in text format or gzip format)
12/12/2021 new version of test files
now, you can have several types of project, depending of what you want to do:
- code html/css/JS scripts added in B4R project
it is easy for development and for test, but not easy to maintain
- html/css/JS scripts are stored in PROGMEM structure at end of file.
code is more clear and less memory is used
- html/css/JS scripts can be extract from PROGMEM and added in external file downloaded directly by web server
only code is in B4R project, but file have to be stored in flash with LittleFS and web server take more time to download files
- html/css/LS scripts/jpg/png can be stored in files and files can be compressed in gzip files, stored in Flash, accessible with LittleFS
download time for files is correct, it can be a fiable configuration, but you need first access at flash to updates all files needed
- html/css/JS script/jpg/pnng files can be integreated in a static module under PROGMEM format
download time is good, everything is in the project, it is ideal for a final project.
the tool "PSPAD_B4Rprogmem" is usefull to move strings from code to PROGMEM, to external files, to gzip files and to gzip files included in a statis module under PROGMEM
from tests done, we can make a very good and complete web server under B4R with this very good library aWOT
result: raWOT is a wrapper for aWOT library from Lasse Lukkari
full library with examples : https://github.com/lasselukkari/aWOT
full documentation : https://awot.net/
with aWOT we can create a web server working on Wifi or Ehternet, and on a large panel of boards.
aWOT is able manage GET, HEAD, POST, PUT, DELETE, PATCH, OPTIONS, ALL, USE
Under Arduino aWOT can support multiple clients, but i was not able to make it working with B4R.
on arduino side, management of this libray is done by multiple callbacks: one callback is created for each routing created and one callback is created for each middleware created.
On B4R it is not possible to used dynamic callback managed by pointer: for B4R, in raWOT we have only one callback for all middlewares and we can select one middleware with an index. (256 index possible)
at last, result is the same, just in middleware callback, we have to make a select/case on index to send callback to the good sub.
with aWOT, we have 5 types of objects to manage:
Application : This class is used for mounting Middleware / Routers and to process the incoming HTTP requests.
in B4R, Application can address Routers and Middleware by an index number
Router: this class is used for mounting Routers, to make complementary routing, or to mount final Middleware
we can have 256 routers index in B4R and each router can address routers or middlewares
Middleware: this object is a sub called by callback from conditions define by app and rout. It is a sub to handle request/response of server
we can have 256 middlewares index in B4R and each index will address a sub
Response: this class is used in Middleware callback to manage server responses
Request: this class is used in Middleware callback to manage server requests
In aWOT we have 4 class to manage server:
app.xxxx
rout.xxx
rep.xxxx
req.xxxx
in raWOT the 4 class are in the same class raWOT and conversion index/pointer is done in wrapper.
aWOT.app_xxxx
aWOT.rout_xxxx
aWOT.rep_xxxx
aWOT.req_xxxx
To manage web server, at end we have a tree in this way in appstart:
app => Mid_01
app => Mid_02
app => Rout_2
Rout_2 => Mid14
Rout_2 => Mid15
Rout_2 => Rout_3
Rout_3 => Mid_13
Rout_3 => Mid_16
app => Rout_4
Rout_4 => Mid10
Rout_4 => Mid11
Rout_4 => Mid12
Rout_4 => Rou5
Rout_5 => Mid_17
Rout_5 => Mid_18
Rout_5 => Rout_6
Rout_6 => Mid_19
Rout_6 => Mid_20
each middleware sub will handle Request part and Response part
raWOT handle 99% of aWOT library functions
tests were done on esp8266 and esp32 with Firefox/Edge navigators on a PC and with B4R project "testaWOT" in esp (added at Zip)
summary of tests done:
- redirection page to page
- get
- post
- upload of file from PC to eeprom esp
- download of file from eeprom esp to Firefox on PC
i think we can do a lot more with this library, but i am not expert of html/javascript.
i hope this wrapper can help the community and at last, it was a very good exercise for me
21/11/27 new version with option to send html code to library in string or in arraybyte
included 2 test codes with direct string and also with strings stored with PROGMEM
in both cases, it don't take more than 200bytes for stack
08/12/2021 new version with some improvements:
a few modifications were done on wrapper raWOT:
a mime management is added to provide content-type from file ext
a function ClientIP provide IP of client connected
improvement of function req_form: now buffers include string received and spaces after
now we have 4 demo for test of raWOT in diffents configurations:
one demo with html/css/js included in B4R source
same demo with html/css/js included in PROGMEM storage, in code part
same demo with html/css/js included in html file in flash of esp and managed by littleFS
same demo with html/css/js included in gzip file, in flash of esp and managed by littleFS
this demo include :
an authentication page
a menu to access at all demo pages
a page multi-inputs to define a configuration of esp
a page with text input
a page to show/define led status
a page to show/define pins status
a page to manage files in flash with littleFS
a page to show loading of pictures
some traces are added to check what is received in webserver from navigator
2 process are used for GET/POST:
- GET/POST launched from a form
- GET/POST launched from XMLHttpRequest
with current library,
1) each connection client <=> is closed at end of actions planed in webserver and an other client can be connected
=> we can manage several clients in parallel
2) client IP is provider to B4R interface
=> answer of webserver can be depending of client IP
3) a parameter <head><meta http-equiv='refresh' content='60' can be added in html page and client will reload the page every 60sec
=> websever can know clients connected to server
=> with the 3 inputs, we can make basic multi-client in webserver side
to avoid multi manipulations of strings, (ans stack increasing) wrapper accept several interfaces :
- we have print() and println() to avoid joinstring/joinbytes
- string, for strings in B4R code
- Arraybyte, for strings in B4R code
- Arraybyte, from PROGMEM storage
=> a tool can help et transfert of string Code => PROGMEM and also PROGMEM to Code
- file transfert direct from LittleFS file
(index.htm, style.css, picture.png files can be downloaded from LittleFS in text format or gzip format)
12/12/2021 new version of test files
now, you can have several types of project, depending of what you want to do:
- code html/css/JS scripts added in B4R project
it is easy for development and for test, but not easy to maintain
- html/css/JS scripts are stored in PROGMEM structure at end of file.
code is more clear and less memory is used
- html/css/JS scripts can be extract from PROGMEM and added in external file downloaded directly by web server
only code is in B4R project, but file have to be stored in flash with LittleFS and web server take more time to download files
- html/css/LS scripts/jpg/png can be stored in files and files can be compressed in gzip files, stored in Flash, accessible with LittleFS
download time for files is correct, it can be a fiable configuration, but you need first access at flash to updates all files needed
- html/css/JS script/jpg/pnng files can be integreated in a static module under PROGMEM format
download time is good, everything is in the project, it is ideal for a final project.
the tool "PSPAD_B4Rprogmem" is usefull to move strings from code to PROGMEM, to external files, to gzip files and to gzip files included in a statis module under PROGMEM
from tests done, we can make a very good and complete web server under B4R with this very good library aWOT
Attachments
Last edited:
