Отладочные коды Марлина (коды D) и статус LTS у ветки 2.0

После отката прошивки (для латы BTT E3 RRF V1.1) из ветки 2.1 (2.1.2 и bugfix-2.1*) в ветку 2.0 (2.0.8.2) перестала нормально работать инициализация EEPROM. Проявлялось это в виде неправильных значений параметров hybrid threshold для осей, из-за чего приходилось записывать из вручную. Вероятно, причина этого в изменении форматов (разметки) сохранения данных в EEPROM, принятых в ветке 2.1.

Стало ясно, что необходимо стереть данные в EEPROM, чтобы Marlin смог полностью проинициализировать его, как это происходит на только что купленных платах. Была идея стереть EEPROM программатором, подключив его к микросхеме при помощи прищепки, но это оказалось невозможно (EEPROM упакована в TSSOP-8, а не SOI/SOIC-8). 

На гитхабе мне подсказали, что эту проблему можно решить включением MARLIN_DEV_MODE и, затем, использованием кода D1. В общем, я включил в прошивке MARLIN_DEV_MODE, после чего началась самая интересная часть этой истории.

Но что бы я ни делал – EEPROM никак не стирался. Каждый раз после ввода кода D1 проходило небольшое время, плата перезагружалась, но данные в EEPROM не стирались. Это было видно по тому, что после кода Д1 никак не изменялись прежние данные в статистике работы принтера.

То же самое было и с кодом D3, я проверил это и в 2.0.8.2, и в 2.0.8.9.

Максимум, что смогли посоветовать активные участники сообщества в этой ситуации – проверять физическую работоспособность микросхемы EEPROM (заведомо исправной, см. выше).

Что ж, раз программисты не смогли - пришлось самому смотреть, в чем же проблема. Вот что мне удалось выяснить.

В модуле gcode_d.cpp работа с EEPROM реализована через модуль eeprom_bl24cxx.cpp. Для которого требуется объявление EEPROM через IIC_BL24CXX_EEPROM. И это —  важный нюанс.

Дело в том, что для современных плат (таких, как вышеупомянутая BTT E3 RRF V1.1) используется определение EEPROM как I2C_EEPROM с одновременным определением MARLIN_EEPROM_SIZE. Вероятно, могут быть (и наверняка есть) и другие варианты определения EEPROM, но это уже не ко мне.

Что же в итоге получается? А получается, что модуль gcode_d.cpp не выполняет свои функции на новых платах. Он просто не видит на них EEPROM. При этом всё компилируется и как бы выполняется. Баг, мягко говоря, эпичный, так как сидит в реализации режима прошивки для разработчиков.

В итоге, багом это не признали и пометили как F (request feature). Особенно восхитило требование проверить bugfix-2.1. 

We’re not going to backport fixes to previously tagged versions. Please download bugfix-2.1.x to test with the latest code and let us know if you're still having this issue.

Это при том, что gcode_d.cpp в bugfix-2.1. тот же самый, а ветка 2.0 и, в частности, 2.0.9.6  (вышла около месяца назад) заявлена там как LTS. Т.е. как бы продолжает поддерживаться.