Fetch LED types from Bus classes (dynamic UI) #4129
Conversation
- provide LED types from BusManager for settings Credit: @netmindz for the idea.
- move macros to constexpr methods - introduce type capabilities for UI - add phase shifting (POC) to PWM - replace PWM CIE LUT with calculated curve CIE & phase shifting credit @DedeHai
- LEDC: allocate same timer for CCT PWM - use SOC constants BusManager update - use allocateMultiplePins for BusPwm
- phase shifting correction (limit to PWM CCT)
Clarifications
Add semaphoring Determine CCT overlap
- renamed variables - some tuning
fixed offsets and inverted signal plus dead time
- (credit @netmindz & @willmmiles) Tuning.
|
Re 43cc4ec, a quick thought offhand regarding oappend: I think there's really little value in using a stack buffer at all, since the two places where it's used immediately turn around and copy the contents to a heap allocated buffer anyways. With that in mind and since this limitation keeps coming up, I sketched a proof-of-concept "remove oappend" patch last week -- there's some more cleanup to be done, the API change would need to be applied to all usermods, and it probably wants to be extended to use a rope-like data structure like DynamicBufferList, but it should give the general idea for a possible future direction. |
|
Every time I see |
|
@netmindz & @willmmiles would you think this is good to be merged? @softhack007 do you have any second thoughts? |
| return &(_mappings[n]); | ||
| } | ||
|
|
||
| uint8_t getPixelColorOrder(uint16_t pix, uint8_t defaultColorOrder) const; | ||
|
|
||
| private: | ||
| uint8_t _count; | ||
| ColorOrderMapEntry _mappings[WLED_MAX_COLOR_ORDER_MAPPINGS]; | ||
| std::vector<ColorOrderMapEntry> _mappings; |
There was a problem hiding this comment.
Is the switch to std::vector intended to reduce memory usage?
One of the challenges is that std::vector has an exponential allocation strategy. Depending on the relationship between WLED_MAX_COLOR_ORDER_MAPPINGS and the number of entries actually used, it may end up using more memory. I checked the code for std::vector for ESP32 -- this implementation of push_back uses the classic "double the array length if it needs more memory" strategy. So for WLED_MAX_COLOR_ORDER_MAPPINGS == 10 (esp32), when you push the 9th element on to the list, the buffer will expand to 16 -- leaving 6 elements you pay for in RAM, but will never use.
What you can do to mitigate this is any of:
- You could ensure that the limits are powers of 2
- When loading the vector, figure out how many elements you need, then call
reserve()up front to allocate exactly the right amount of memory - Alternately, you can preallocate the maximum memory you plan to use with
reserve()at construct time; won't save any RAM but also guarantees you'll never allocate more than you need. - You could call
shrink_to_fit()after filling the vector, or make a copy and discard the original std::vector object. (Cost is the same, a complete copy and temporarily holding more RAM than it needs)
There was a problem hiding this comment.
Is the switch to
std::vectorintended to reduce memory usage?
No. It is to allow variable size (in the future) without the expense of pre-allocated memory. The question was "why 10 and why only 10?".
reserve() could be done, yes. That'll go into cfg.cpp and set.cpp. Thanks.
|
@jw2013 please rebase your branch(es). I'm going to delete |
The idea was sparked by @netmindz (#4056) to allow dynamic creation of enabled (compiled) LED types in LED settings UI instead of relying on editing HTML file to represent them.
This PR implements @netmindz principles while also improves JavaScript handling of implemented bus types in UI (no longer relies on magic numbers).
As a bonus BusPwm is enhanced to support "dithering" and "phase shifting" on ESP32. LEDC supports 4 fractional bits that enhance resolution by 1 bit using temporal statistical distribution (see ESP32 technical reference manual, LEDC chapter).
Phase shifting can be used to distribute load on PSU and, more importantly, drive H-bridge used for reverse-polarity PWM CCT LED strips (thanks goes to @DedeHai for debugging signals on the oscilloscope and adjusting calculations).
The downside of this PR is increased stack buffer size for
oappend()function as LED types are pushed into it. When the number of LED types reaches the limit of usable stack that information will have to be split into a separate HTTP/XHR request.What remains to be implemented is:
is16bit()function)Closes #4112 #4117