Source of truth for components/core2forAWS?

[nuchi]

I notice that the code for the core2forAWS component seems to be (mostly?) duplicated across the various projects. Is there a single authoritative source for this code, if I should want to use it in my own projects? The various versions appear to not always have all the same commits, and it's not clear to me which to refer to. A git submodule in each project pointing to the same external repo (but potentially different commits) would allow development to happen in a single place elsewhere, while not forcing each project to update code simultaneously. It would also make it easier for users to pull in just that component as a submodule without having to copy a subdirectory out of version control.

Thanks for your work on this! It's been very helpful so far.

[rashedtalukder]

Hi @nuchi, I appreciate the feature/enhancement request. Submodules are a great idea for the benefits you've listed out and we'll keep this transition in mind for a future.

While the projects have different commit histories, all the core2forAWS libraries are identical. The best source of truth however is the Blinky-Hello-World project. It is the project that we test any changes to the BSP on.

[joshka]

I echo @nuchi's comments - there's a bunch of stuff in here that seems m5stack specific, not AWS specific. I'd love to see this extracted into a M5Stack Core2 BSP component, (and perhaps contribute the lvgl specific changes back to the lvgl_esp32_drivers project, which has a M5Stack configuration which doesn't seem to currently work with the Core2). Massive props on the getting started docs. They are excellent. This idea is for the use case that starts with I want to make something real, not just educational.

[rashedtalukder]

Hearing you both. Can either and/or both of you describe the outcome you want to achieve?

@joshka, how would you define "something real" that you want?

[joshka]

I’m working on a personal project using the core2, and which will need to use lvgl for display and some of the other parts that have drivers in the core2 for Aws component. I could copy paste this component from the Blinky examples and then keep checking for updates, but this is error prone and duplicated work which the submodule approach solves. In effect I’d have to maintain both my project and a bsp for the kit. A proper bsp allows the transition from tutorial coding to a real world project.

[rashedtalukder]

Got it. This is helpful. Do you want to also think it's valuable to provide supporting content to "transition" from the tutorials to your own personal device project, or are there enough resources readily available that makes that a moot exercise?

[joshka]

My viewpoint is as a fairly experienced software developer, though I've done significantly more .Net / Java / Ruby / JavaScript than microcontroller stuff. Going from the tutorial to a real world project (on the core2) requires choosing whether to use esp-idf vanilla, or platform.io with esp-idf, or even looking at Arduino / circuit python as options. Having a clear tutorial to starting a project from scratch showing how the various pieces fit would definitely shorten the ramp up time.

A question I'd flip back at you is: if you were starting a new IoT project using the M5Stack Core2, what would be the first 5-10 things you'd do after git init? (Both right now and ideal state are two good thought exercises for this question).

Also, I appreciate you for answering these questions on the weekend. For me this is just a hobby, so I have no real expectations of support here. Thank you regardless.

[rashedtalukder]

No problem, it's a lazy Sunday here and I can respond on my phone. How individuals want to build projects and use the BSP is what I'm trying to understand. An example is that we could use git submodules for a separate BSP repository. However, that could cause frustrations (e.g. repository not cloned recursively with submodules) for users with errors that won't be obvious. Another possibility, we could choose the route to use PlatformIO libraries and for new projects, that is the route we'd recommend.

We're just exploring what people would like to see and why from opinions outside our own.

[nuchi]

I'm happy to describe my workflow so far. I've already worked around most of the issues I've found, so this would just be a "nice to have for others" and not anything urgent for me at all.

Context: I'm new to the m5 stack, to the esp32, and to embedded programming in general, though I have software engineering experience in other contexts. I'm building an application with heavy digital signal processing (for audio) that's pushing the cpu pretty hard.

I started by simply modifying the Hardware-Features-Demo project in place, since it provided good examples of using the screen and speaker. I then started writing my own project from scratch so that I could organize my code better, at which point I created this issue.

Some assorted observations:

• I added this entire repo as a git submodule and then symlinked the blinky/components/core2forAWS directory into my own components directory. I then had to also symlink esp-cryptoauthlib — it might be nice to have a way to not import that requirement to core2forAWS if one is not using any of its features.
• I also copied the sdkconfig.defaults and partitions_16MB.csv files into my project. I don't know enough to know whether I need them — I just figured they were "magic" and that I'd better include them.
• The MPU code has some calls to vTaskDelay with parameters that aren't wrapped in pdMS_TO_TICKS. I modified this so that I could set the tick speed from 100Hz to 1000Hz without changing the functional behavior.
• I wanted to use the display without the touch screen — I had to edit the component's Kconfig in order to permit this. I think maybe the dependency is backwards? Right now, if you use the display you must use the touch screen, but should it not be the other way around?
• When initializing the GUI, the component creates its own semaphore. However there is also an spi_mutex for (I think) the display, and this one must be created by application code, which seems inconsistent and also it confused me. Is there a natural place to put that creation inside the component initialization code?
• The button, gui, and touch screen code are opinionated about which core they run on and at what priority. I found this problematic and had to reach in to the component code and edit this. That's because I wanted to dedicate core 1 to my cpu-heavy DSP code. I moved the gui code to core 0, and ended up just disabling the touch screen, because the touch screen is also opinionated about how it sets up interrupts. I don't know a whole lot about this, but from what I understand there are multiple ways to set up interrupts that are incompatible with each other, and whatever the touch screen was doing was incompatible with setting up i2s to send audio samples to the speaker.
  • I think it would be really great to expose the core and priority as parameters when initializing the various subcomponents. If someone doesn't care about that, they could use the defaults, but if someone does care then they can pass different options. For example if the init code contained only task creation, then I could just create the task directly and pass different parameters:

  void Button_Init() {
-     button_lock = xSemaphoreCreateMutex();
      xTaskCreatePinnedToCore(Button_UpdateTask, "Button", 2 * 1024, NULL, 1, NULL, 0)
  }

  ...
  
  static void Button_UpdateTask(void *arg) {
+     button_lock = xSemaphoreCreateMutex();
      ...
  }

Then I can do either Button_Init() or for example xTaskCreatePinnedToCore(Button_UpdateTask, "Button", 2 * 1024, NULL, 1, NULL, 1).

I think that's it for now! Happy to answer more questions or post more as I remember.

[joshka]

I also opened https://github.com/lvgl/lvgl_esp32_drivers/issues/57 to talk a bit more about where / how / if the lvgl stuff fits in that repo (and the changes that would be necessary to make it work for the Core2). I think my best way forward for now though is to copy the blink core2 code and start from there instead of trying to make the lvgl_drivers code work.

[rashedtalukder]

Thank you @nuchi and @joshka. The level of detail that you've shared here is incredibly helpful. This provided a lot to think about. Let's see how to think of a solution (both short term and long term) to some of the items you've brought up so that it helps the greatest number of people in the program.

[rashedtalukder]

@nuchi, we fixed the spi_mutex definition issue and moved that to Core2ForAWS_InIt(). We don't recommend moving most tasks to core 0 of the ESP32 since that's typically reserved for asynchronous network usage. You can read more about it here: https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-guides/freertos-smp.html

For a list of running tasks and their priorities, there are those from the Core2 for AWS BSP itself, and many more that are run by the various drivers by Espressif. We wouldn't be able to document every task that runs since there are variations. We added an API reference that should also help answer some of your questions or suggestions and we will also think about adding the tasks each of the features uses, the task priority, stack allocation, and core affinity.

[mongonta0716]

Hi,

I've been working with the esp-who repository and noticed that there is a way to place components in one repository instead of submodules. In this case, the demo project should be placed under examples. I think this method is also useful, so please consider it.

https://github.com/espressif/esp-who

Add the following line to CMakeLists.txt of each project to refer to the common components.

set(EXTRA_COMPONENT_DIRS ../../../components)

https://github.com/espressif/esp-who/blob/master/examples/single_chip/detection_with_web/CMakeLists.txt#L5

[rashedtalukder]

This method is fine for people who have spent days or weeks trying to figure out how CMake works. For other developers who are newer to IoT, the nest that this creates makes it next to impossible to understand how to create your own functioning project.

In my personal opinion, the non-standardization of folder structures (e.g. some use “examples,” “demos,” “samples”) and lengthy folder nesting paths is one thing that has created an artificial barrier for individuals coming in to IoT across silicon providers. I appreciate what PlatformIO tried to do early on by requiring a specific project structure.

On Sep 3, 2021, at 10:43 PM, Takao Akaki @.***> wrote:

 Hi,

I've been working with the esp-who repository and noticed that there is a way to place components in one repository instead of submodules. In this case, the demo project should be placed under examples. I think this method is also useful, so please consider it.

https://github.com/espressif/esp-who

Add the following line to CMakeLists.txt of each project to refer to the common components.

set(EXTRA_COMPONENT_DIRS ../../../components) https://github.com/espressif/esp-who/blob/master/examples/single_chip/detection_with_web/CMakeLists.txt#L5

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android.

[mongonta0716]

That's for sure. In that case, the best way is to make a submodule under components.

Thanks!