Further work to Esp32 arch. #2151
Conversation
mikee47
force-pushed
the
dev/esp32
branch
3 times, most recently
from
87e5085
to
7ab1929
Compare
mikee47
force-pushed
the
dev/esp32
branch
3 times, most recently
from
a454b1a
to
c869424
Compare
mikee47
force-pushed
the
dev/esp32
branch
5 times, most recently
from
9bc577e
to
61ba0f5
Compare
mikee47
force-pushed
the
dev/esp32
branch
4 times, most recently
from
71f7b6c
to
c040c2c
Compare
|
@slaff Although I've had some esp32 modules for a couple of years, I've not touched them until now and was impressed with how easily Sming builds and runs on them. Awesome work! Something which grates a little about the IDF is the amount of stuff that needs to be installed. If we assume that this specific IDF installation is only for use with Sming, there are some further improvements to be had:
The fastest setup could be achieved by adding slimmed-down, pre-configured IDF and tool images to the |
|
Re #2100 here's a docker script to try out: |
|
I've added the
This will avoid any conflict with the Esp32 (or Esp8266) SDK and make the build more robust and code easier to follow. Note I'm specifically using a lower-case convention for these names to identify them as low-level code, and differentiate from regular framework Components. Thoughts? |
|
@mikee47 If you are ready with the planned improvements for this PR then let merge it as it is. |
|
@slaff The only thing holding me up now is timers, specifically the |
mikee47
changed the title
|
@slaff OK, ready for review |
…or PolledTimer use
|
@mikee47 The changes look awesome! Thanks a lot for your help! I have tried the Basic_Serial sample and it is constantly segfaulting for me. Can you try to reproduce it on your Linux box? IDF version: Steps to reproduce: Application output: It looks to me as if IDFs code is clashing with our uart code. The decoded backtrace points to the following error stack: Config: |
|
Ok, the following small change helped me stop the Basic_Serial application from segfaulting. --- a/samples/Basic_Serial/app/application.cpp
+++ b/samples/Basic_Serial/app/application.cpp
@@ -285,10 +285,11 @@ void init()
debugf("(DEBUG) print me again on UART0");
// Initialise and prepare the second (debug) serial port
+#ifndef ARCH_ESP32
Serial1.begin(SERIAL_BAUD_RATE);
-#ifdef ARCH_ESP32
+#else
// Default pins are occupied by flash lines
- Serial1.pins(17, 16);
+ Serial1.begin(SERIAL_BAUD_RATE, SERIAL_8N1, SERIAL_FULL, 17, 16);
Serial1.onDataReceived([](Stream& stream, char arrivedChar, unsigned short availableCharsCount) {
debug_e("arrivedchar: %c, avail = %d", arrivedChar, availableCharsCount);
});
Also it seems that there is bigger variety in ESP32 pinout compared to ESP8266 and the one that I use is ESP32 WROOM with TX1 and RX1 29 and 28 respectively. So we should move the pin numbers as const variables in the sample. |
|
I re-tested with builds on both Windows and Linux and all fine. Your esp32 uses the same pins as mine, but clearly doesn't like being configured with the defaults. Fix forthcoming. |
|
@mikee47 Something broke the generation of the documentation. Excerpt from travis logs(https://travis-ci.org/github/SmingHub/Sming/jobs/746741886) Can it be that Esp32 arch is now removing/adding python stuff that breaks the generation of the documentation? |
|
@slaff I've reviewed logs and the fault happened with the Basic_AWS commit. In either case I don't believe we did anything! Comparing working/failed logs shows that the Python 3.7 distro package version changed and that's where the fault is triggered. Some preliminary tests have failed to fix the problem, and I think we'll have to upgrade some doc packages which will probably meanmoving off sphinx 1.8.5. That is pretty old now... |
Is there something in particular holding us back at version 1.8.5? If not let's upgrade to the latest Sphinx version. As far as I can see on my Ubuntu distribution the pip version is 3.3.x: $ pip install -U sphinx
Collecting sphinx
Downloading Sphinx-3.3.1-py3-none-any.whl (2.9 MB) |
|
My digging into the Travis logs showed the following: From: https://api.travis-ci.org/v3/job/742560539/log.txt The used packages where the build is succeeding are the ones below (excerpt from the same log file) And in the latest builds below are the ones that are failing: The major difference is
I have to read a bit more about |
|
See #2160. |
Awesome work thanks to you ;-) And with your help and the help from other contributors things will only get better. We may add soon support for the RISC-V based ESP32 microcontroller. |
Build changes:
export.sh(simplifies usage, especially with eclipse)Structural changes:
Fixes:
flashmem_get_addressusing mmap registersesp_attr.hfile to support this.TODO:
init_priorityattribute get placed first, in other builds they're first.Implement timers - don't use task(get stack overflow errors running HostTests) increase task timer stack sizeBasic_Serialsample (enable receive on second port).For separate PR:
Hallayer to minimise code duplication and provide consistent interface between framework and arch hardwaremalloc_count, doesn't work