BrewPiLess
BrewPiLess copied to clipboard
Porting to ESP32
Hi Vito: There is so far some work done to port to ESP32? I think there are many advantages as mensions in http://vito.tw/?p=720#comment-25109
- TLS
- More pins
- BLE
- And it is also less demanding on the source of energy.
I offer to collaborate to the best of my ability Regards
Hi,
I did start a port attempt some time ago but my lack of C++ expertise made me stop, too many errors!
I tried my best to make it compiled. However, there seems like some library issue with platformio. ESP32 uses whole different flash layout. I need to study it to make it work. Before that, I am stuck on the LCD display with framework 1.8.0.
You can try if you want. https://github.com/vitotai/BrewPiLess/tree/ESP32Attempt
Hello: I tried to compile but as mentioned @allthepies, there are too many errors.
Have you been able to detect which libraries have conflict? I am not familiar with the Brewpiless code, is it possible to isolate parts of the code to be able to correct by parts? Anyway, as soon as I have a time I will try the branch that you just shared with me.
I will return with news, Thank you
El jue., 4 oct. 2018 a las 5:18, vitotai ([email protected]) escribió:
I tried my best to make it compiled. However, there seems like some library issue with platformio. ESP32 uses whole different flash layout. I need to study it to make it work. Before that, I am stuck on the LCD display with framework 1.8.0.
You can try if you want. https://github.com/vitotai/BrewPiLess/tree/ESP32Attempt
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/vitotai/BrewPiLess/issues/128#issuecomment-426927238, or mute the thread https://github.com/notifications/unsubscribe-auth/AcqFZ4R5vHFFLbo0KkFtvtBM6oPFuxVaks5uhcREgaJpZM4XEkBM .
Hi Vito: I was with little time these weeks, yesterday I could compile and load it in my esp32.
This is the serial output:
Setup () SPIFFS.being () Success. Init LCD ... LCD Initialized .. syscfg: 0, timeinfo: 156, gdc: 168, tempSchedule: 204, brewStatus: 300, logFileIndexes: 320, remoteLogginInfo: 636, autoCapSettings: 1080, parasiteTempControlSettings: 1092 Starting WiFi ... AP SSID: BrewPi pass: BrewPi AP Mode WiFi Donate! Load saved time: 36910 HTTP server started {"" W "," SPIFFS space: 1347040 start volatiel log mode ␀ => or startVolatileLog, mode = o, beerteemp = 32767
Start as AP, I can connect to the network from my cell phone but I can not access 192.168.4.1
Do you have any suggestion?
It crashed when connected. I tried to decode the stack dump, and it seems like issues in WString.cpp. If the string library or use of it is a problem, there will be a lot of work to do. Not only I use it, but most of the libraries use it. I hesitated to use STRING for being not comfortable about memory management but ended up using it because of convenience. Now we have it.
Also interested in an esp32 port. And will gladly help out.
I also plan on digging into this with the ultimate goal of integrating the tilt hydrometer
Hi all, I made some progress. (Honestly, upgrading to 1.9 framework seems to be the biggest one.) Please check here: https://github.com/vitotai/BrewPiLess/tree/ESP32.test
The way to make ESP32 save network information seems to complicated for general user, or to me. Therefore, I coded to manually save it. There are some issues in the WiFiSetup Class, too. I found Auto Reconnect doesn't behavior as what I've thought.
The next step is defining PIN usage. What do you think?
Great stuff Vito! What does it do so far ?
There seems to be issues related to AsyncTcp library, and WebSocket doesn't work as expected. I am investigating this issue.
There's a ton of potential there with the ESP32, however, so far I've not found it as stable. Whether it's the core or the supporting libs, it just doesn't seem to be as dependable as the ESP8266. That's a damned shame.
I'm hoping the ESP32-S2's arrival will re-spark the community around these chips and they will get some additional love.
@vitotai regarding AsyncTCP i assume you are getting the issue where the wifiscan data isn't being returned properly? At least that's where i've hit trouble in my own efforts. Scan results are being generated but the response is not being sent. Interestingly enough, every once in a while it works just fine.
Regarding pins, in my config.h
i've avoided pins 12-15 as they are the hardware debug pins on the dev board i'm using (nodemcu-32s). Recently found the inexpensive ESP-prog JTAG debugger which works with PIO, and got it up and running using this tutorial perhaps that might be useful to those working on this.
@vitotai regarding AsyncTCP i assume you are getting the issue where the wifiscan data isn't being returned properly? At least that's where i've hit trouble in my own efforts. Scan results are being generated but the response is not being sent. Interestingly enough, every once in a while it works just fine.
Regarding pins, in my
config.h
i've avoided pins 12-15 as they are the hardware debug pins on the dev board i'm using (nodemcu-32s). Recently found the inexpensive ESP-prog JTAG debugger which works with PIO, and got it up and running using this tutorial perhaps that might be useful to those working on this.
Thank you for the head-up about PIN usages. It is what I am looking for. I too buy a JTAG debugger because I don't have any idea about the WString exception, which disappears after upgrading to 1.9 framework. I haven't setup the debugger, and thank you for the information, too.
If you turned on the debug message, you can see some "Too Many Message..." message, which is printed by WebSocket plug-in. My guts tells me that it might be the same cause of not-sending data and it might be something related to the "GreetingInMainLoop" option, which is a work-around for a design flaw I found in ESPAsyncTCP library. We'll see after I return home.
I was wrong. It's wasn't what I have thought, but I make it work by workaround without knowing the exact cause of issue.
The problem now is that the sensor cannot be detected.
https://github.com/brettbeeson/esp32/tree/master/brew32
Some update:
- DS18B20 doesn't work on certain PINs, like 25 and 26. I am not sure if it is just my board.
- My latest push seems to work fine, although there are still some issues.
- Working on Rotary Encoder now, but I need JTAG to work for an crash.
Happy to see all of the positive progress on this, thanks so much for your effort.
I can report that PIN 25 and 26 are working with the DS18B20 both in BPL and simple test programs on my board. I'm using the NodeMCU-32S devkit. Pins 25 & 26 are DAC pins but that really shouldn't matter so not 100% sure what would cause it not to work.
I've noticed a little bit of instability with the latest push, including a seemingly random crash/reboot, and the wifiscan is still giving problems, but at least everything seems to be generally working. I need to order some more hardware and may be able to help diagnose some issues in the coming weeks when I can find the time.
Thanks again
Basically, the rotary encoder works. However, I am stuck at a exception:
Guru Meditation Error: Core 1 panic'ed (Cache disabled but cached memory region accessed)
Mine works fine. At least it survived through 24 hours if I don't touch anything. Do you using "local logging"? I am guessing something wrong with FLASH writing.
https://youtu.be/B2wUG_49lAk
The rotary encoder is working now!
I went to wrong directions because of not familiar or ignoring Harvard architecture of ESP32.
The WiFi scanning issue should have something to do with "WiFi Auto Reconnect", which will causes disconnection in AP mode. It might because that WiFi library uses all resource to search lost network. Try this branch. (My git tree are a mess now, and I can't push to previous branch.) https://github.com/vitotai/BrewPiLess/tree/ESP32.trial
Just uploaded that branch and I can confirm the WiFi issue seems to be resolved and is working properly. Good job!
Did notice that the latest doesn't seem to be detecting my onewire temp sensors, but that could be an issue on my end. I'll look into it deeper once i get some more time.
Try the latest push, which includes an OneWire library. The discussion: https://github.com/espressif/arduino-esp32/issues/1335
I've tried back and forth, with and without this OneWire library. Sometimes it makes differences, sometimes it doesn't. It should depends on the run-time condition of I-CACHE.
That seems to have solved it for me. Thanks!
Compilation errors on ESP32.trial:
src/TempControl.cpp: In static member function 'static void TempControl::increaseEstimator(temperature*, temperature)':
src/TempControl.cpp:500:55: error: invalid operands of types '__gnu_cxx::__enable_if<true, double>::__type {aka double}' and 'int' to binary 'operator
>>'
temperature factor = 614 + constrainTemp(abs(error)>>5, 0, 154); // 1.2 + 3.1% of error, limit between 1.2 and 1.5
^
src/TempControl.cpp: In static member function 'static void TempControl::decreaseEstimator(temperature*, temperature)':
src/TempControl.cpp:510:55: error: invalid operands of types '__gnu_cxx::__enable_if<true, double>::__type {aka double}' and 'int' to binary 'operator
>>'
@allthepies This is an issue with the latest version of arduino-esp32 (v1.0.3), which is now used in the latest version of platform-espressif32 (1.10.0). I've submitted the issue with espressif here.
For now you can fix the issue in your platformio.ini by setting platform = [email protected]
Thanks, compiles with that workaround.
I've experienced compiling errors, unexpected exceptions, and etc. Upgrading to framework 1.9.0 seems to solve most of the problems.
Now that all functions I've thought of are working, I am thinking the next step. BLE has been tried, but it takes too much memory to work with. I will wait until NimBLE library is available. HTTPS seems not yet supported on ESP32. What do you have in mind?
Eventually i'd like to get the Tilt Hydrometer working which will require BLE. I'm sure you've seen the tiltbridge project. Hydrometer data doesn't need to be checked continuously so maybe it would be possible to poll for data every 15 minutes so that might be a viable way to work around the memory issues?
Maybe a next step would be to abstract out the gravity code so that in the future it would be easier to switch devices since everything is tightly integrated around the iSpindle.
Frequency doesn't matter in this case. It's about memory, not computing power.
It's easy to integrate Tilt. The problem is that I don't have a Title to test.
Saw the vid that you got the ~~potentiometer~~ rotary encoder to work, great job! Have you decided on a pinout yet? Was thinking of making a few PCB's for the ESP32 version!