Closed luc-github closed 8 years ago
Starting looking at documentation seems SDK is available to make this module autonomous for a mini webserver so need to build fw for it, so should avoid too many change in Davinci FW for this support but push it to ESP8266 FW.
GPIO pin on this module is available, so can add led to give a visual status: connected, on, off...
also may need an additional pin to control the hard reset from printer
would be good to connect a switch to power off/on manually the module to avoid to unplug it if need flash arduino and there is conflict, this should allows to hard control the module
one part need to check if one module can listen 2 ports : one for serial connection with host one for web server or another way to filter communication with host and communication with webserver
need to see if UART0 is not available for any reason, can we use software serial ? need pins available like using top sensor pin, jam sensor pin, spool EEPROM communication pin, etc....
an interesting task so far ^_^
http://rancidbacon.com/files/kiwicon8/ESP8266_WiFi_Module_Quick_Start_Guide_v_1.0.4.pdf http://voltivo.com/forum/davinci-hwmods/775-using-a-5-wi-fi-module-i-now-have-a-wi-fi-enabled-da-vinci Thanks to g mcclean for pointing this ^_^ http://hackerspace.pbworks.com/w/page/88183850/ESP8266 http://playground.boxtec.ch/doku.php/wireless/esp8266
I need to finish 0.92.2 and 0.92.3 import and code cleaning first so will do next week
(Different alias but I'm the person who created the ESP8266 thread on the Voltivo forum)
The board I suggest to you on the Voltivo forum, the ESP-01, has limited GPIO but there are other versions such as the ESP-07 and ESP-12 that provide access to more of the the chips GPIO pins.
The following site shows some of the variations. http://l0l.org.uk/2014/12/esp8266-modules-hardware-guide-gotta-catch-em-all/
It should be possible to reset the ESP8266 by wiring its reset pin to the main processors reset pin so that a reset on one causes a reset on the other. Causing the watchdog to fail in software would then reset both. I believe the Da Vinci reset line is accessible via the right hand pads of SW2 which is the "Reset button" on V1 boards). My board did not have the button populated but I added it to make it easier when re-flashing the DDa Vinci firmware.
Hardware resetting of the ESP8266 is really only necessary if using the LUA I provided. After you questioned me on the Voltivo forum I thought about it some more and I think I should have stuck with my original plan and used the AT firmware for the ESP8266. While it involves a lot more changes to the repetier firmware the results would be far superior.
I'd be happy to do some work on this but I still need to get a better understanding of the repeter firmware before making changes and I don;t have a lot of free time.
Hi welcome and again thanks for pushing this module, really good one - I was looking for this for another project and it match exactly my needs, so I will definitly jump on it ^_^
For GPIO I was just thinking about led, so I guess 2 are enough, I think the needs of more GPIO will be defined when we will better defined what we want the module do with printer.
About reset, actually I was mentioned it because I read on one forum that the board could stay in busy state if web browser is closed when displaying the web page - they mentioned (was in 2014) in future it could have a SW update fixing that, but waiting for this, a hard reset may be necessary to reset board time to time. I just read and did not checked, but I preferred to put in the todo list than forget it ;)
Same for LUA or AT or new SDK based FW, I read people did a FW with embedded web server, and some create a library to help to build one, but did not did out more, too much to check, I read lua based can be easy, but I saw all samples using AT may need a FW update for carriage return, so actually I have no opinion, just a big willing to try all, to see what is best, but if you have already experience / opinion please share it - I am always willing to learn.
About Repetier FW -I am currently cleaning/reformating/commenting the code, I need to separate more clearly what is repetier and what is for davinci specific, as it is becoming harder for me to see quickly what impact a new update of repetier will have on Davinci FW. When looking at their github, they mix several updates at once without clear explanation, so it is not easy to follow weekly, and sometimes of course with some bugs... That is why I do not push daily. no mention that some updates are incompatibles with some changes I did. Repetier guys is more focus on Delta AVR when we (Davinci) only focus on Cartesian/Due. UI is now fully different and I introduced some feature before repetier that I need to merge now because Davinci has a lot.
All that to say: understand Repetier FW will be easier once I will clean up code, so no worry
I also would be really happy to work with you and learn from you on this. ^_^
Ok 0.92.3 Import is finally done so now working on this promising topic
I flashed my module with latest AT FW 0.9.5.2 which allow a connection at 115000 by default I have read what can be done using AT FW and the one using SDK My understanding is using the SDK is more for non arduino connected purpose / stand alone module like ESP8266 with some sensors and 2 batteries. as need to flash ESP module for any FW modification
The AT FW allows to configure the Module and change GPIO state, a webserver is also possible but handled by arduino : http://allaboutee.com/2014/12/30/esp8266-and-arduino-webserver/
I did not play with NodeMCU FW yet, but this guy made several videos using it https://www.youtube.com/user/AllAboutEE, looks like in between standalone - need to flash the scripts to ESP - but they can be called from serial according the needs.
Seems one module read only one port - so I do not see the way to use same module to be IP/Serial bridge for Host and be a web server to provide a LCD like UI - may need 2 modules
Ok connector soldered - cables/plug done - Really not easy to do soldering on 2mm pins female connector.... so far printer still alive and Wifi module now power up - Still need to think how and where to fix it and need to add a switch to be able to disable it without open the back of the printer.
Connector before and after :
The module plugged :
Tomorrow I will implement the module in FW using AT commands and a command to disable wifi in menu I am thinking to use a command like M101 "SSID","Password" to store SSID and Password in EEPROM to avoid to hard code something in FW, and may be a M102 "AT Command" to handle the Module like scanning available networks, or any other useful command.
There is a ESP8266 holder on Thingiverse (http://www.thingiverse.com/thing:642456)
It is possible to host a webserver directly on the ESP8266 without any addational hardware, see http://www.esp8266.com/viewtopic.php?f=6&t=376, however given it is being connected to the Da Vinci processor it probably makes more cense for its processor to handle the task.
It really just boils down to a design decision and how far do you want to stray away from the master Repetier firmware.
The following article might help if you want to know more about directly programming the ESP8266 i.e. bypassing the AT or LUA firmware images to create you own application directly on the device.
yes saw the holder, do you use it ? actually I think AT based module is only for building a bridge with repetier host
to get webserver allowing to start a print from sd, giving status and sending message when done, it is better to build embeded fw on module to avoid to overload Davinci (due) board, but need to hook some events in repetier fw to trigger some status\messages
I do not think it is necessary to have both feature at once because repetier host allows push messages already,but in this case it make no sense to have to flash module according usage, better just to choose on printer menu
what do you think? from your perspective what do you expect the module/printer provide to you?
No, I just have the device dangling out the rear of the printer :-)
First let me say I do not understand why "Repetier Host" supports TCP connections yet there is no support in "Repetier Firmware". Are there plans to support TCP in the Repeiter firmware?
Knowing the answer to this would make the following an easier choice.
If the Repeiter firmware is not going to support TCP connections/settings then it makes sense to use a feature of the ESP8266 where it can simultaneously acts as both an AP and a AP-Client simultaneously. In this mode you would connect to the ESP8266’s AP, be presented with a web page hosted on the ESP8266 that allows scanning the local Wi-Fi, selection of a SSID, definition of the Wi-Fi password and to see the allocated IP once a connection has been made to the private Wi-Fi. The ESP8266 would then remember both the SSID and password which it would use to automatically log back on to the local Wi-Fi when power on. So basically the web interface is just used to connect the ESP8266 to you LAN and the Repeiter firmware has no knowledge of any of the settings.
This is basically what this example is doing http://www.esp8266.com/viewtopic.php?f=6&t=376
However there is no reason why the SSID and Wi-Fi password could not be set via the Da Vinci LCD.
It is just this would require adding new settings to the Repeiter EEPROM values which is why I asked the first question.
about tcp/ip support here one answer: http://forums.reprap.org/read.php?267,396191 so no plan in fw Yes acting like ap to setup to configure network is common way I agreed, I did not think about it as originaly printer is connected to usb to flash the fw, so short path was to end by configuring network, and my idea to use M101 to setup ssid/password is just because of bad ergonomy using printer keys to select alphanum entries, but of course can be done. thanks for sharing , this bring more TODO ^_^
about ssid/password storage, you mean there is a way to store them in esp8266 fw ? I did not found AT command for this, I need to see in SDK
The ESP8266 has a small external flash chip which is used for storing its firmware. This can also be used for persistent storage of configuration data. The LUA and possibly the AT versions of the firmware do this so to allow automatic reconnection on power on.
As for the alternative, I presumed it would be possible to create new variables in the EEPROM data and at those variables would automatically become editable in Repetier Host bypassing the need for alphanumeric entry via the LCD i.e. the EEPROM data is self-describing. This is not something I checked!
well a network password in clear is not a good idea, it should be encrypted or at least not easily visible, that is why the idea of M101 command, which store password in EEPROM but not visible and encrypted but if there is a way to to store it in esp8266, even better, will check the docs
One point of not using Host UI : Repetier EEPROM has no type for string, neither variable length data, all is based on strict position in EEPROM, so if need to use the EEPROM interface for password it means rewrite the all EEPROM functions and we cannot rewrite the host part so it won't be possible.
M101 command instead could be based on M117 command which accept string,
Just sharing,
Ok seems when setup is done, all nework informations are stored automatically - no need to mention need to store ( at least with AT commands) so when module is power down, then power up, connection is done automatically, so no need to care about SSID/Password storage - just to provide information at initial setup- my bad I missed this point during my first tests
This FW looks doing the bridge : https://github.com/beckdac/ESP8266-transparent-bridge I will test released binaries present in Github before building the full compilation tool chain and do some modifications (if necessary) OOPS :@disneysw, seems you already play with for a while : http://www.esp8266.com/viewtopic.php?f=6&t=864 it is not good ?
I have now a module with latest nodemcu-firmware, the flasher did not worked for my board the esptool.py was fine I started to play with the lualoader but module become not responsive, or may be it is due the lualoader itself, I had to restart module and reflash it.
It seems the modules I have are little bit different: one has blue and red led blinking when power on, when the second one has only the red led blinking - and initial FW were different when I got them.
Lua bring definitly more control compare to AT commands, and also allows to print less garbage during communications. Now I am able to store SSID/Password in ESP module in a file, using a script and loading them in another one to connect to AP. I did not found an automatic way like with AT command, calling wifi.sta.config(SSID,PWD) seems necessary at each module restart.
So we can imagine a script that store all preferences to start AP or Station, DHCP or Static so when module is starting just need to call the script "connect.lua", that will setup the IP connection then call the server setup or set the bridge. I am not sure yet if it is good to include connection in init.lua, if something is wrong and module crash or is in loop, soft reset is not working, so the only way is to reflash the FW, adding a timing delay as suggested in wiki could also be a solution to access module before init.lua start.
Additionnally, because when server listener is in loop, there is no way to stop it without adding a check that would decrease the bridge performance - I think adding a pin to do the hard reset if we want to change configuration when server is started would be a good solution IMHO, but need also to reset the serial connection in same time with module.
:@disneysw I saw you setup 19200 in your script - any reason not to set 115200 or even higher?
Web UI should looks like this one for configuration
with some Javascript
based on the very simple code of http://randomnerdtutorials.com/esp8266-web-server/
so actually module can have 3 modes, only one at once : Configuration / Bridge / Front End, default one will be Configuration of course if no configuration file Can have 2 access modes : Station / AP, by default for configuration will be AP(SSID:Davinci/Davinci) if no configuration file And 2 network modes : DHCP or Static IP
Save will save the changes and apply them at next restart, Apply will save the changes and apply them immediately. I will implement Configuration and Bridge mode first, for Front End, need to define what should be done.
Any comments/suggestions about this ?
You seem to be getting on well.
Above 19200 baud I ran into issues due to lack of flow control on the serial connection. The Repetier firmware is based on processing a single character at a time but TCP connections transmit packets. I believe it is the burst nature of the packets which is causing the problem. This could probably be resolved on the Da Vinci side by increasing the serial buffer size or changing the GCode::readFromSerial() routine to deal with packet structures rather than processing the individual characters.
You are probably thinking wait, the repetier protocol has a concept of acknowledging receipt of commands (ping-pong), but this increases the latency of individual commands so is not a great strategy when using a guaranteed transmission service like TCP.
Thanks for the info on the EEPROM. Glad I did not waste time on that idea!
Sounds like the only way forward is to use the Web UI for configuration.
If that is the case there is probably no requirement to have any UI via the Da Vinci LCD. The ESP8266 could either be enabled using a #define during the build or the repetier firmware could be modified to take commands from both USB and serial simultaneously.
Thank you for the feedback as did no test connection with repetier , just simulating answer on keyboard to see if basic is ok, will test using bigger cache size, I am just afraid the about the impact on pause command. I will keep the modification of the readserial() for the end. About repetier protocol ( binary one not text one) - in addition of acknowledgement there is a checksum (https://github.com/luc-github/Repetier-Firmware-0.92/blob/master/repetier%20communication%20protocol.txt)
About UI on printerm, it would be simple in case of no PC on USB and new access point for any reason, in a wifi menu : 1 - to allow to enable/disable wifi (flag stored in EEPROM) 2 - to reset AP with default SSI/password (if forget password) 3 - to allow to switch to config mode any time (if local network is no more accessible) 4 - Get Network information SSID/IP/Connection status
I think UI and repetier should be ready next week as all is pretty clear and defined so far.
Sorry to be slow for implementation, I am also busy building another printer from scratch and real life ^_^,
Thanks again for bringing this nice module, your code and sharing your experience
Ok - still fighting with lua and nodemcu bugs and limitations:
Anyway - I am almost ok for UI page, just 2 bugs to solve before first release on github, I should find a solution this week end if no new bug,
I am following this with interest. But I looks as if you're trying to invent the square wheel. Implementing the serial to wifi bridge in Lua is ineffective, and others have problems getting any reliable throughput.
Have you seen https://github.com/beckdac/ESP8266-transparent-bridge?
It only lacks configuration from the serial side, and you could then do all configuration from the Repetier firmware.
Also I'm guessing you could add the ESP8266 to the "bluetooth" serial port of Repetier and have it as a 2nd connection, so USB is primary (firmware updates) and the ESP8266 is for everyday use (printing etc).
Well yes I saw it, read above : https://github.com/luc-github/Repetier-Firmware-0.92/issues/58#issuecomment-85509108- but did not test it, I saw @disneysw tested it - but he did not feedback yet - @disneysw any feedback ? and he is the one who provided the lua code for the bridge
-- Transparent WiFi to UART Server
-- -------------------------------
-- Once started the only way to terminate this app is via a hw reset
-- Open a listening port on 8080
sv=net.createServer(net.TCP, 60)
global_c = nil
sv:listen(8080, function(c)
-- Loop around reading/writing data
if global_c~=nil then
global_c:close()
end
global_c=c
c:on("receive",function(sck,pl) uart.write(0,pl) end)
end)
uart.on("data",4, function(data)
if global_c~=nil then
global_c:send(data)
end
end, 0)
I did not experienced performance issue on communication, but I did not stressed it yet. also my purpose is not to only do a bridge but also have a simple front end to handle / get status of printing Job, like on phone, right now I am only focused on UI to configure network. That said I am still discovering the module, I played with AT FW and found lua one is better, I have no doubt creating an embeded fw will be better - just more heavy to do, so I keept it for the end if lua does not fit the needs.
@lkarlslund did you tried the bridge FW ? any feedbacks ? you have which Davinci board ?
so no feedback on this embeded fw ?
lua fw seems having some memory management issue, but I found a workaround using protected mode, it allow to call function without getting the not enough memory error neither crash application and bring more error control.
so config script now allows special chars for password, trim spaces, it is almost done, just need to add a button to do module restart using new configuration. NB: no check about ip format, password size, SSID format is done yet
I am still wondering if network setup should be in init.lua or an independant script called independently any though ?
with https://github.com/nodemcu/nodemcu-firmware/tree/0.9.6-dev_20150331 the output for web page is limited to 2920 bytes and randomly loose some at the end which is little bit too short using bootstrap css so I removed it keeping basic HTML, less fancy. code and html template is minimized to fit the memory constraints, just at the limit ... just adding little change bring a not enough memory message.
I have some concern about the esp8266 file system as after several file refresh it become unstable and need to be reformated but normally when configuration is done no need to change often so should be ok also uploading using Lualoader is painful, files are randomly corrupted and need to a cat to check file is ok .....
I plan to use :
M800 S1`` to ask printer to do a module restart
M801 [Message]to give printer an error message
M802 [Message]to give a status message
M803 [IP,SSID,AP/STA,GAYTEWAY,MASK,BRIDGE/FE]to give config parameter
M804 [STATUS]``` to give status [TBD]
I have created a branch for ESP8266 testing and will upload the lua scripts today with a draft readme to explain each scrip, how to flash esp, these will allow to test without repetier
I will start modify repetier today after testing the latest lua fw which bring several interesting changes and may be fix some memory issues
Sorry for not getting back to you. Easter and family time was first priority.
I am struggling a bit with the embedded firmware. It loads up as it should, but I get no AP SSID or anything. I have only tried with the binary pre-compiled firmware, as I haven't had the time to install the compilers etc.
I still think that a "transparent" solution would be the nicest. What you seem to be doing with NodeMCU are 1) configuration from webpage 2) configuration from Repetier firmware 3) transparent gateway.
I think that is really great, because if you do not use the modified Repetier firmware, you can just configure from the webpage. That will mean that other type of firmware users can also benefit from this.
Can I suggest that if you tie one of the GPIO pins to ground when powering up, your script resets to factory defaults (with some reasonable SSID), so you can always get back in even if you messed up the settings?
you mean make the module fully independent and not driven by FW ? so in this case need to add a way to configure the baud rate in web UI to avoid any need of FW interaction: so if GPIO2 is ground when init.lua check it , it should start module with the AP mode using something like EPS8266 SSID with simple password and defined IP, then launch the webconfig.lc script. and when module is normally starting automaticaly start network and bridge module or front end module
Currently I was planning to let the printer FW to drive the connection after module started (init.lua is only supposed to set the default baud rate to 9600 - changed after by printer), printer fw is also in charge of launching the connect.lc script to set wifi according parameters file then if wifi is ok , printer fw will launch action.lc, which start the bridge or the front end according also the configuration file. I am also planning to connect GPIO2 pin to one free printer pin, to stop the bridge when it is in action, as currently it only can be stopped by hw reset, so not convenient if need to communicate with module after bridge is started.
I think the 2 scenari can be merged by adding an auto/manual launch flag in addition of the baud rate in configuration file/Web UI. The only difficulty I see is: will the memory of the the module allow to add the 2 parameters in webconfig.lc ? knowing that I am already close to the limit, (seems to be a known issue looking at the issue tracker)- May be using webconfig.lc instead of webconfig.lua should make the trick but TBC I am also not sure if launching webconfig.lc from init.lua will give enough memory, again TBC
Just pushed some files today - still lot of to be done for readme and scripts https://github.com/luc-github/Repetier-Firmware-0.92/tree/Test-esp8266/src/ArduinoDUE/ESP8266 Currently if you first setup wifi by lualoader you can launch the webconfig.lc (need to be compiled from lua file) it need page.tpl to work, connect script is supposed to work as far I tested when datasave is created by the webconfig.lc script - you can do a cat to check if fine
Did not started repetier changes yet as I want to finish modules scripts first. I spent time testing latest fw today (0.9.6-dev_20150406 ), and no matching fixes, same limited memory and same limited web output, same buggy filesystem after several file copies.
webconfig.lua is just at the limit of available memory any change even minor may bring a not enough memory error, after copy all files and compiling them but init.lua the best is to do a restart and launch the lc version
with all memory errors with lua based fw I am now considering the embeded FW I build the tool chain, installed the SDK (0.95 and 1.01) and got some random good results just with the samples - output is messy - basics samples are not working - just got the IoT demo working but with lot of trash in serial. May be it is the lack of up to date documentation, may be my toolchain as some issue, may be I do not integrate the SDK properly, may be I do not flash properly, etc,,, I have no time to spend to learn all what is necessary to set for a good tool chain, and proper SDK integration, then be able to code the FW. toooooo many variables.... that make my motivation down :sob:
So I am now evaluating arduino IDE for ESP8266 : https://github.com/esp8266/Arduino http://www.esp8266.com/viewforum.php?f=25
First program I did using this IDE, generated a fw that was flashed by IDE without problem, and this FW did what it was supposed to do!!!! without trash data neither errors!!! which is nice after fighting with previous solutions...
So even I did not finished lua solution, (I may do the missing part later) most task is done, based on my first tests, and looking at issue tracker, current nodemcu is not mature enough to get the expected performances. Neither installation process: flash FW, then format fs, then copy lua files, then configuration, it is definitly not the easiest way compare to flash FW and that's all.
Because I do not want to spend time on toolchain, I think Arduino IDE for ESP8266 may be a good way. Unless someone came with a ready FW matching the specs defined in readme I will try to do the FW like this.
More over due to the direction of Arduino 1.6.3 and board manager - I am pretty sure ESP will be integrated soon.
It may be obvious to go to this direction, and I may should try it from the beginning, but as it is new thing for me, I like to have choice and try all paths to be sure the chosen one is the right one.
I hope the integration will be ok soon
Hi Luc, That is really really great news. I am used to Arduino development, and I can give you a hand when time permits. I have just finished a new Delta printer, that begs for the ESP8266 to be connected ;) Lars
Thanks Lars, I need to review what are the available commands first and I think I will be able to tell next week
Yes using Arduino IDE / embeded FW vs lua FW is like night and day - only some issue related to IDE 1.6.1 because 1.6.3 seems not working well with the standalone package yet - but I guess all will be ok soon.
I have already a configuration class to read/save all parameters, including the serial baud rate, and so far so good - I will work on configuration web page display tomorrow - I am currently using a private git repository at home, but I will setup a new public github repository on my github for the ESP8266 FW this week end with what I have done, I think it is better to separate Repetier and ESP repositories and discussions
I just bought an ESP07 because same price as ESP01 and many more GPIO, to test if FW is also compatible, but this one need 2mm pins which I do not have..., so compatibility test will be delayed Anyway, I still think ESP01 is enough for the bridge/printer
More update this week end
Just head up: Until now I was using IDE 1.6.1 for ESP8266, coming from : https://github.com/esp8266/Arduino because standalone package 0.0.2 from : https://github.com/sandeepmistry/esp8266-Arduino was not working with 1.6.3, but today, I tried recently released 0.0.3 package with 1.6.3 and so far so good!! so now can use one IDE for all Devt :tada:
I'm very much looking forward to the Arduino code for your progress. I'm have basic communication running, but will not be implementing the same as you, that would be a waste of time.
Please upload your work in progress when you're ready to share. Thanks!
I am not in bridge level - I am busy with several other things so little bit slow. I have also building a cable for easily flash and test hard reset using jumpers.
What is working right now and planned before first upload : 1- Settings : read / save / reset to defaults / dump to serial (Done) 2 - Test on GPIO2 if low 2~8 seconds after module start to reset settings to default one as you suggested - seems starting module with GPIO2 connected to GND boot to special mode, so need to delay the jumper usage just after start (Done) 3 - Wifi setup according settings on EEPROM, AP/STA/DHCP (Done), now working on Static IP, I found IP expected format and functions to setup, so just need to implement today) 4 - Web server setup displaying configuration (no modification yet) ( should be tonight or tomorrow) 5 - Web server allowing setting modification (tomorrow)
so once part 5 is done I will upload, as before nothing to check actually - still discovering the API
I was thinking about configuration, not via webpage but just via the printer.
You mentioned implementing new commands in the Repetier firmware, but I'm not sure that is necessary.
Repetier 0.92 has optional bluetooth support on secondary serial ports. We can use this to connect the WiFi module, and still use USB connection to the printer as well.
The way I read the firmware for Repetier, it recieves data on both USB and bluetooth serial ports in parallel, if bluetooth is compiled in. Also it sends the same output to BOTH the USB port and the bluetooth port.
So if you send M84, it echoes back via serial that the command has been executed. If you send it "gibberish" (a command it does not support) it sends back the command and also "not understood" or similar.
That means that if you implement some simple commands that the 8266 firmware understands, we can remotely configure it via USB:
1) user wants AP mode, SSID printer, KEY secretcode 2) he sends ESP:AP/printer/secretcode as a command in Repetier Host 3) printer returns error, echoing command back with error message (this is sent both to USB and bluetooth) 4) ESP8266 firmware picks up the command and changes settings
Basically the ESP8266 should just be in bridge mode all the time, but eavesdrop on the communication. If it recieves something on the serial port it recognizes as a command, it parses it and makes the changes.
I still think the web-page is a lot of work, but you must decide.
well I did not do test but I am afraid if ESP module need to filter all commands before passing to serial or to web - it will bring a lot of performance issue - I may be wrong - that is why I planned to use the GPIO2 to stop bridge and send command to module get answer then put bridge back - if need to parse all data going by module you do not think it will be overloaded when a print is ongoing ? Also my printer is a Davinci (it is Due based arch with complete pin remapping - no bluethooth) not like your rumba If you do not need web part I will upload just when Wifi is done
I think it will not degrade performance. It acts as a bridge, but saves every line of data it recieves (i.e. until linefeed character). Every time it gets a complete line, It then does a lastline.indexOf("ESPcommand:"). If nothing found, it just continues, otherwise it parses it and does what its told.
This will have zero impact on normal use, remember it still passes everything on character by character. The only difference is it saves all characters for the last line, and when it recieves a linefeed, does the .indexof function or similar.
On 04/16/2015 02:06 PM, Luc wrote:
well I did not do test but I am afraid if ESP module need to filter all commands before passing to serial or to web - it will bring a lot of performance issue - I may be wrong - that is why I planned to use the GPIO2 to stop bridge and send command to module get answer then put bridge back - if need to parse all data going by module you do not think it will be overloaded when a print is ongoing ? Also my printer is a Davinci (it is Due based arch with complete pin remapping - no bluethooth) If you do not need web part I will upload just when Wifi is done
— Reply to this email directly or view it on GitHub https://github.com/luc-github/Repetier-Firmware-0.92/issues/58#issuecomment-93718007.
Ok if not noticeable performance impact so no need to use the GPIO2 to stop the bridge - this will make simple. I am still fighting with strtok not implemented on ESP but will done ip tonight
Ok code uploaded : https://github.com/luc-github/ESP8266 with basic readme need some clean up but it is working.
1- Settings : read / save / reset to defaults / dump to serial (Done) 2 - Test on GPIO2 if low 2~8 seconds after module start to reset settings to default one as you suggested - seems starting module with GPIO2 connected to GND boot to special mode, so need to delay the jumper usage just after start (Done) 3 - Wifi setup according settings on EEPROM, AP/STA/DHCP/Static IP (Done),
code read settings - if no settings in EEPROM it create default settings then connect to wifi according to settings - loop is just dumping EEPROM setting every second to Serial I will continue tomorrow - the new repo has issue tracker for discussion/bug/etc...
Changing the static IP for AP was not implemented in ESP8266 arduino module - and several others functions are missing - I just add it today Also the nice thing using this FW is Web config / front end can use one port eg:80 when printer configuration use another one eg:81, and this in same time, which was not possible with AT/Lua FW so It will simplify some code and flow and allow bridge and status in same time no need to switch
Fantastic work, Luc! How do you find the time? ;)
Looking forward to testing it.
From: Luc [mailto:notifications@github.com] Sent: 17. april 2015 11:18 To: luc-github/Repetier-Firmware-0.92 Cc: Lars Karlslund Subject: Re: [Repetier-Firmware-0.92] Add Support for ESP8266 wifi module (#58)
Changing the static IP for AP was not implemented in ESP8266 arduino module - and several others functions are missing - I just add it today Also the nice thing using this FW is Web config / front end can use one port eg:80 when printer configuration use another one eg:81, and this in same time, which was not possible with AT/Lua FW so It will simplify some code and flow and allow bridge and status in same time no need to switch
— Reply to this email directly or view it on GitHubhttps://github.com/luc-github/Repetier-Firmware-0.92/issues/58#issuecomment-93950099.
Well I have to read code /understand and test - actually I am slow - all these should be done before but I am not full time on it - real life keep me busy :)
Embeded FW for ESP8266 development is slow but promising - now I know the complete SDK and all functions - I already have a web interface which list all possible parameters and status, it helped me also to know the limitations and the optimal settings to apply - so I will be able to build the configuration web interface soon
Luc, thanks for the update. I have been fighting with SilentStepStick TMC2100 drivers (try them!) on my mini kossel, so I haven't had any time at all to play with the ESP8266 module. But I look forward to see what you achieve, and I will probably get the ESP8266 soldered into the printer in two weeks time.
On 04/28/2015 03:20 PM, Luc wrote:
Embeded FW for ESP8266 is slow but promising - now I know the complete SDK and all functions - I already have a web interface which list all possible parameters and status, it helped me also to know the limitations and the optimal settings to apply - so I will be able to build the configuration web interface soon
— Reply to this email directly or view it on GitHub https://github.com/luc-github/Repetier-Firmware-0.92/issues/58#issuecomment-97060691.
current status is :
as this device is very cheap ~5$ and only need 2 pins and +/- hardware changes are not hard to implement, thank g mcclean for pointing this out. connection can be done using UART0 non populated connector on main board or any other available pins using softserial Request is already done in repetier tracker but no response so far.
the goal is: 1 - to see if can allow TCP/IP connection with repetier host 2 - to get a replica of LCD panel on a web page