esp-cpp / espp Goto Github PK

Is your feature request related to a problem?

Right now full / deep clone (recursing through all the submodules) takes a little while because the google/nearby repository is quite large / has a lot of submodules. We're actually not using much of what they've got there, and on top of it many users may not be wanting to use the gfps_service component.

Describe the solution you'd like.

Move gfps_service component to a separate repository and move the google/nearby (which is currently under espp/external/nearby) to be within that component's detail folder instead.

Describe alternatives you've considered.

Continuing to force people to fully download google/nearby just to use this repo?

Additional context.

No response

Answers checklist.

• I have read the documentation README and the issue is not addressed there.
• I have searched the issue tracker for a similar issue and not found a similar issue.

General issue report

Right now the example READMEs are all templates without any useful information. Since most of the examples have associated documentation (images / videos / text) on their associated PRs, it would be good to move some of that information over to the READMEs themselves for people who are browsing the repo and learning how to run the examples / use the components.

Is your feature request related to a problem? Please describe.

Controlling a motor is nice (having open & closed angle & velocity control), but it's even better to be able to use it to generate different feelings / sounds.

Describe the solution you'd like

A wrapper class (probably bldc_haptics that uses a bldc_motor to allow the user to easily specify and switch between different kinds of haptics settings and effects. Some examples might be proportional resistance, multiple clicky detents, and button press effects.

Describe alternatives you've considered

Not doing this? J/K I'd never think that.

Additional context

Inspiration & guidance comes from the smartknob project, such as the configurations found here

Is your feature request related to a problem? Please describe.

Don't always have enough GPIO for all the needs of a project, so having a GPIO expander (i2c, spi) would be helpful.

Describe the solution you'd like

A component which wraps the MCP23017 / MCP23S17 hardware to configure expandable GPIO with interrupt.

Describe alternatives you've considered

Additional context

• MCP23X17 datasheet

Describe the bug

As noticed when working on #5 - when enabling velocity filtering (either using Lowpass or Butterworth filters, the PID became unstable, however if I removed all filtering (just returning the raw input from the filter function in main()), then it stabilized and worked well.

This might not actually be a bug in the filters and may have more to do with the control system itself, but definitely warrants more investigation.

To Reproduce

Expected behavior

Filtering should not destroy the stability of the control system?

Screenshots / Images

Hardware / Software Configuration (please complete the following information):

• Hardware: [ESP32-S3-BOX]
• Software Version []
• Connected Peripherals [TMC 6300 BOB, Gimbal BLDC motor]

Additional context

Could be related to the delay that the filters add (esp. since it seems to also occur when using a simple moving average filter with an alpha less than 0.5.

Answers checklist.

• I have read the documentation ESP-IDF Programming Guide and the issue is not addressed there.
• I have searched the issue tracker for a similar issue and not found a similar issue.

What is the expected behavior?

I am review the bldc_driver code by comparing to your code and found some issue.

bldc_driver.set_pwm(25,25,25); // for example
I assume the A,B,C high pin should be 25% high, 75% low. But instead, the high pin now is 75% high, 25% low.

ESP_ERROR_CHECK(mcpwm_generator_set_actions_on_compare_event( gen_high, MCPWM_GEN_COMPARE_EVENT_ACTION(MCPWM_TIMER_DIRECTION_UP, comp, MCPWM_GEN_ACTION_HIGH), MCPWM_GEN_COMPARE_EVENT_ACTION(MCPWM_TIMER_DIRECTION_DOWN, comp, MCPWM_GEN_ACTION_LOW), MCPWM_GEN_COMPARE_EVENT_ACTION_END())); }
This function set gpio high at up direction and low at down direction.
For a counter counting from 0 -> 100->0, if set to 25%, the gpio will set high at 24->25 and set low at 26->25, which will give high time from 25->100->25 which is 75% high.

What is the actual behavior?

When set pwm to 25%, the high side at a_high_gpio show be 25% high, 75% low.

Steps to reproduce.

1. Step
2. Step
3. Step
   ...

Build or installation Logs.

No response

More Information.

I know it works with your FOC controller. If this is a issue, what will change in the FOC controller?
All the highs lows are inverted, May only change the motor direction?

Answers checklist.

• I have read the documentation and the issue is not addressed there.
• I have searched the issue tracker for a similar issue and not found a similar issue.

General issue report

I'm working on migrating LVGL from v8 to v9 and I've run into some issues in regards to your espp::Display class.

LVGL v9 no longer uses macro magic to populate the lv_color_t struct depending on the chosen color depth. Instead, it has different types for the different color depths, and lv_color_t represents RGB888.
This means that lv_color_t can no longer be the type of the framebuffers if the display in question uses the RGB565 format for example.

Now this is all fine and can be implemented in the different display driver classes, but currently, the espp::Display class uses lv_color_t as well.

The vram pointers can be void pointers (also what LVGL uses internally), but the vram_size_bytes() function uses sizeof(lv_color_t).
Should the AllocatingConfig and the NonAllocatingConfig structs also have a member that holds the buffer size in bytes, like the pixel_buffer_size?
Or, perhaps a member that holds the amount of bytes per pixel?

Additionally, I think that the uint16_t *vram0() and uint16_t *vram1() functions should instead also be void pointers to support all color depths.

Alternatively, the espp::Display class could be templated to indicate the pixel type, but that would be a rather large refactor.

What are your thoughts?

Answers checklist.

• I have read the documentation and the issue is not addressed there.
• I have searched the issue tracker for a similar issue and not found a similar issue.

General issue report

Gitlab CI basically doesn't work when submodules are linked via SSH URLs. For Git repos that are hosted on other Git servers than Gitlab, only HTTP(S) is supported. I request reverting the recent change (#256) of linking submodules via SSH to HTTPS. Thanks.

References:

• https://docs.gitlab.com/ee/ci/git_submodules.html#use-git-submodules-in-cicd-jobs
• https://www.perforce.com/manuals/gitswarm-ee/ci/git_submodules.html#:~:text=because%20GitLab%20CI%20only%20uses%20HTTP(S)%20for%20cloning%20your%20sources

Is your feature request related to a problem? Please describe.

• For a more dynamic system (e.g. for the camera-streamer RSTP rewrite) we'd liked to be able to dynamically spawn threads for each client and then easily exit the threads (from within the thread context) when the client disconnects

Describe the solution you'd like

• Update the thread callback function signature to return a boolean value indicating whether to stop the thread or not.

Describe alternatives you've considered

• Supporting multiple callback signatures and using a std::variant in the task class (one for void return that cannot be stopped and one for a bool return that can be stopped)
• Providing a different function that the thread function could call (via thread object context provided in the callback function)

Additional context

• Similar to std::jthread?

Is your feature request related to a problem? Please describe.

• Right now when making changes / fixing bugs / feature additions I have to manually re-build any potentially related test / example code in the components I think might be affected, but this is error prone and could be time consuming.

Describe the solution you'd like

• GH actions configuration to automatically build the examples in each component to have full test coverage and ensure all tests build when making (potentially API breaking) changes.

Describe alternatives you've considered

• Continuing to do this manually?

Additional context

Answers checklist.

• I have read the documentation and the issue is not addressed there.
• I have searched the issue tracker for a similar issue and not found a similar issue.

General issue report

I think you may have forgotten to check for BT_NIMBLE_ENABLED in gfps_service.cpp.
The source file does not include <string> and it can also not find the espp namespace when Nimble is disabled.

Adding the same macros as in other files from that component resolves the issue:

#include "gfps_service.hpp"

#if CONFIG_BT_NIMBLE_ENABLED || defined(_DOXYGEN_)

const std::string espp::GfpsService::MODEL_ID_UUID = "fe2c1233-8366-4814-8eb0-01de32100bea";
const std::string espp::GfpsService::KB_PAIRING_UUID = "fe2c1234-8366-4814-8eb0-01de32100bea";
const std::string espp::GfpsService::PASSKEY_UUID = "fe2c1235-8366-4814-8eb0-01de32100bea";
const std::string espp::GfpsService::ACCOUNT_KEY_UUID = "fe2c1236-8366-4814-8eb0-01de32100bea";

#endif

Describe the bug

CodeQL github action doesn't seem to be able to find code when it runs so it thinks there is nothing to analyze.

To Reproduce
Steps to reproduce the behavior:

1. Make a new PR with some new code.
2. Let CodeQL action run
3. See error

Expected behavior

CodeQL is able to find the code and analyze it.

Screenshots / Images

Is your feature request related to a problem? Please describe.

I think it would be cool to use the NFC tags I have to allow guests at my house to tap their phone to join the WiFi network nicely and securely.

Describe the solution you'd like

Add support for WiFi configuration token application/vnd.wfa.wsc to the ndef component.

Describe alternatives you've considered

• QR code (phone)
• QR code (printed on an 80's style printer)
• QR code (3D printed for some reason)
• Tattoo
• Having an easy to read / hear password for a change?

Additional context

• https://ndeflib.readthedocs.io/en/stable/records/wifi.html#configuration-token
• https://android.googlesource.com/platform/packages/apps/Nfc/+/master/src/com/android/nfc/NfcWifiProtectedSetup.java