Timer driver refactoring - #3120
Conversation
|
Despite the fact that now all timers present on the CPU are included into the code (previously they were guarded by Before: After: |
9835147 to
b2bb115
Compare
06e65bb to
cd8bd18
Compare
523b95b to
4942b6d
Compare
|
Rebased, tested on REVO |
|
Size before: After: Timer tables are bigger - they now store all timers available on the CPU, not the used ones as before. But simpler and cleaner general timer code pays back - flash usage is not bigger. |
|
There's +1K in BSS on F7 and +500 on F3, looks like from the globals in timer.c. Is there any easy way to make them readonly so they can use TEXT instead? Maybe we could automatically generate the code for timer metadata, since it has to be done only one per MCU. |
|
It's the timer run-time state that eats up bss. Maybe it's time to make this state dynamically allocated... State for each timer is 41 bytes (44 bytes if aligned), but it's only used when timer is configured for input (Softserial RX or PPM/PWM in). |
|
Switched to dynamic timer state allocation. Finally dynmemory allocator is used for something 😆 |
1ee9491 to
de34c58
Compare
DzikuVx
left a comment
There was a problem hiding this comment.
@digitalentity this is just too long ;) I trust you that if it works then it works ;)
|
@DzikuVx I'd appreciate if you could test if SOFTSERIAL and LEDTRIP features work for you ;) |
|
This I can do around Tuesday |
|
@DzikuVx if it works for you, please go ahead and merge this. I'll be in Moscow next week and most likely will have very limited connectivity. |
56685b2 to
eabd6e1
Compare
1f1079f to
24b9a7d
Compare
24b9a7d to
7cfd241
Compare
|
Ok, this is now merged. Let's see how it will work out |
|
flight tested on MATEKF405 and QUARKF4. Nothing bad happened. |
|
Good to know, thanks for testing @stronnag |
Code simplification, de-duplication and better timer driver abstraction.
Work in progress. Seems to work well on REVO