search

m5stack / Core2-for-AWS-IoT-Kit

Accompanying code for use with AWS IoT Kit content. Works with PlatformIO and ESP-IDF v4.2.
https://m5stack.com/collections/m5-core/products/m5stack-core2-esp32-iot-development-kit-for-aws-iot-edukit
MIT License
127 stars 66 forks source link

Source of truth for components/core2forAWS? #54

Open nuchi opened 3 years ago

nuchi commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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:

  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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

@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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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

Thanks!