turnon

LevelX

Выделение заданного бита или по маске из заданного регистра - это есть. Я думал что-то хитрое подразумевается под "описатели битовых полей, объединения битовых полей" А вот есть какая-то замороченная адресация битовых полей:

Первый раз про такое слышу. Это не из стандарта modbus? Очень хорошо бы пример или название прибора, а там в инструкции будет видно, как это работает.

Приведите примеры, пожалуйста. Ну или хотя бы дайте название прибора, где такое встречается. А что будет если прочитать и не записать? Есть. Номера функций чтения и записи, можно привести только номер функции чтения, можно только записи, можно обе { "read":1, "write":5, "start":0x7530, "regs":[ "ON;c" ] } Так для того и сделал тему, чтобы выяснить разные возможные варианты.

Делаю устройство/мастер RS485, где регистры modbus, из размер, типы конфигурируются через API. Цель - получать значения регистров в уже переваренном для пользователя виде - в нужных единицах, с суффикcом единицы измерения, со значением "null" при определенном значении регистра и т.д. Вроде учел всевозможные случаи, но может у кого есть на памяти какие-то безумные конфигурации регистров, которые не удалось обработать стандартными возможностями ПО и приходилось программировать для отображения пользователю. Все возможные типы данных: MRT_COIL, MRT_BOOL, MRT_I8, MRT_U8, MRT_I16, MRT_U16, MRT_I32, MRT_U32, MRT_I64, MRT_U64, MRT_F32, MRT_F64, MRT_STRING Для MRT_STRING задается размерность, напеример "s8"- строка 8 символов Все возможные порядки байт: MRBO_BE, // Float - Big Endian (ABCD), UINT16 - Big Endian (AB) MRBO_LE, // Float - Little Endian (DCBA), UINT16 - Little Endian (BA) MRBO_MBE, // Float - Mid-Big Endian (BADC) MRBO_MLE, // Float - Mid-Little Endian (CDAB) Строка конфигурации регистра выглядит как перечисление через точку с запятой, например: "T;i16; °C;v/100;v==-32768" - name, type, unit, valueExpr, nullExpr valueExpr - выражение для вычисления значения из значения регистра nullExpr - если выражение возвращает true, значит вместо значения регистра выводим "null" Далее примеры.

А где держат?

Хорошо бы, чтобы и данные не пропадали. Но лишиться всей файловой системы - это полный крах.

Для меня цель устойчивой к сбоям ФС - не разрушить саму ФС, надо внести минимальные изменения, которые переведут систему в новое корректное состояние.

Если во время записи сектора на носитель пропадет питание. при старте этот сектор будет восстановлен из сектора журнала. Если во время записи сектора журнала на носитель пропадет питание - просто потеряем данные одного сектора. Хотя тут напрашивается вопрос - а какое максимальное количсество секторов в FAT необходимо записать для перевода ФС из одного корректного состояния в другой.

Выглядит действительно просто. Можно в FatFS в disk_write все сначала писать в журнал, а затем уже с журнала перенос на реальный носитель. Журнал сделать размером сектора (512 байт), если в disk_write приходит на запись больше одного сектора - последовательно писать сначала в журнал. затем на носитель. Журнал размером 512 байт храним на том же носителе. Почему же нет реализаций открытых, если все так просто?

Если так все просто, почему нет чего-то типа jffs, но не жрущего 128K памяти? Если для вас просто - изложите пожалуйста подробно алгоритм или дайте ссылку на реализацию. Это будет прорыв. LittleFS, jffs и прочее - поудаяют репозитории с гитхаба или где оно там лежит.

Срабатывание вочдога, мощная помеха - кривизна рук тут ни при чем, программ без багов не бывает.

Тут скорее важна не сохранность, а целостность ФС. Аппаратные средства имеется в виду резервное питание? Но это не спасет от непредвиденного ресета МК.

Для вас нет проблем, для остальных, как видите, есть. Не все же такие продвинутые. Так выложите наработки, все будут очень благодарны. Ну или хотя бы поделитесь идеями с автором LittleFS, а то он бедный уже зарылся в багах. Может бросит эту LittleFS.

Ну это, извините, уже не файловая система, а поделие из г-на и палок.