Ensure rpmFilter is resized before the updateTask is created.

[MichMich]

This commit addresses a critical issue in the initialization order within the begin() method of the MT6701 class. Previously, the asynchronous update task created by xTaskCreatePinnedToCore could potentially attempt to access the rpmFilter vector before it had been properly initialized and resized. This scenario could lead to undefined behavior, including crashes due to accessing uninitialized memory.

Changes made:

The call to rpmFilter.resize(rpmFilterSize); has been moved to occur before the creation of the update task with xTaskCreatePinnedToCore. This ensures that by the time the update task runs, rpmFilter is already appropriately sized and ready for use. This change prevents a race condition where the update task might execute updateRPMFilter(float newRPM) or any other method relying on rpmFilter, encountering a vector that has not yet been resized. Such a condition was observed to cause a "Guru Meditation Error: Core 1 panic'ed (StoreProhibited)" due to attempts to access or modify the vector before its initialization. Additional inline documentation has been added to clarify the importance of the initialization order for future maintenance and readability. Rationale:

Ensuring the proper initialization sequence in multi-threaded applications is crucial for stability and reliability, especially on platforms like ESP32 where tasks may preempt each other. By resizing rpmFilter before the update task starts, we eliminate the risk of accessing an uninitialized or incorrectly sized vector, thus enhancing the robustness of the encoder's RPM filtering functionality.

This fix is a preventative measure against potential undefined behavior, ensuring that all components are correctly initialized in a deterministic order, which is especially important in a real-time operating system environment like FreeRTOS.

[noranraskin]

Thank you for the fix!