[tonyk_av 45]

39 minutes ago, Forger said:

Так делайте все машинных кодах, это - тоже "проверенное решение" 🙂

Причём тут машинные коды? От них как раз ушли как от малоэффективного в большинстве применений решения.

Если бы Forger читал стандарты на функциональную безопасность, то знал бы, что даже на Ассемблере для задач управления писать ПО можно с определённым числом оговорок, не говоря уже о машинных кодах. И требованиям к языкам программирования задач управления машкоды вообще не соответствуют.

 

19 minutes ago, haker_fox said:

Интересно, кто же брал на себя ответственность за их проверку?))

Тот, кто реализовывал проекты, в которых цена ошибки была близка к нулю.

[Forger 26]

39 minutes ago, turnon said:

Потому да, голый USB HID самое то.

Или Mass Storage )

 

 

 

3 minutes ago, tonyk_av said:

Причём тут машинные коды?

Именно - не при чем, как и архаичный FTP.

 

3 minutes ago, tonyk_av said:

Если бы Forger читал стандарты на функциональную безопасность,

Увы, "трясти медальками" у меня не очень получается. Тут сдаюсь 

[amaora 25]

4 hours ago, Solonovatiy said:

И если в том же JS, можно вполне обойтись общими возможностями тестового фреймворка, то для сишного приложения вам скорее всего придется писать свой тестовый фреймворк поверх общего. (и покрывать его тестами). Иначе ну совсем жопа =\.

Не так чтобы именно TDD, но регрессионные тесты делаю на C. Тестируется один основной модуль (несколько .c файлов), написанный достаточно абстрактно, чтобы работать в виртуальном окружении. Всякий HAL и уровень задач RTOS не покрыт тестами. Да, для этого написана имитация всего необходимого окружения, заданы сценарии, заданы критерии корректности результата (это наверно самая слабая часть). Пока все далеко от идеала, есть существенные отличия симуляции от реальности. Количество тестов не велико, и не всегда полностью ясны критерии по которым надо оценивать результат. Тестами для тестового фреймворка являются данные, полученные с испытаний в железе, ручной анализ.

Первоначальная разработка/отладка так же проводится в этом тестовом окружении, что гораздо быстрее и дешевле. Но надо не ленится и формировать тестовые сценарии на долговременное использование, а не только сиюминутные проверки. Циклы разработки действительно могут получаться короткими (десятки секунд), но тестовые сценарии изменяются в процессе а не созданы заранее. Можно ли это назвать TDD?

[xvr 12]

2 hours ago, tonyk_av said:

Я сторонник использования проверенных решений, а не новомодных штучек.

3 hours ago, Forger said:

Протоколу HTTP - 26 лет. Как то не попадает он под 'новомодные штучки'

[tonyk_av 45]

20 minutes ago, xvr said:

Протоколу HTTP - 26 лет

FTP на 10 лет старше.

[Forger 26]

2 minutes ago, tonyk_av said:

FTP на 10 лет старше.

Над вами тут все уже отрыто стебутся, но вы не обращайте внимания, продолжайте 😎

[tonyk_av 45]

1 hour ago, Forger said:

Над вами тут все уже отрыто стебутся, но вы не обращайте внимания, продолжайте 😎

Ну, если говорить "Мы, Forger,..", то да, все.

 

3 hours ago, Forger said:

Тут сдаюсь 

Не удивительно, кроме эмоций про FTP и HTTP Forger ничего и не сказал. До такого ответа, коротко и по делу, Forger  ещё надо дорасти.

[Forger 26]

39 minutes ago, tonyk_av said:

До такого ответа .... ещё надо дорасти.

у вас все получится )

 

Как видите, вам не удалось убедить местных коллег в перспективности античного FTP перед другими решениями. Предлагаю на этом закончить этот офф.

[std 8]

On 12/6/2022 at 12:51 PM, Solonovatiy said:

Я писал в ТДД на JS и пробовал писать на СИ. Вот по моему мнению, TDD это то, что лезет в СИ из яваскрипта, не взирая на специфику. 
ТДД по замыслу его авторов и евангелистов подразумевает работу циклами редактирование-отладка по 2-3 минуты. (некоторые в десятках секунд вообще меряют). Т.е. вы вносите изменения в код и тут же видите результаты теста, тут же их правите, тут же видите обновленные результаты. Это позволяет писать вообще не особо подключая мозги. Это все очень круто, особенно в высокоуровневых языках, а если с динамической типизацией, так вообще шик.
Каждый тест можно в 3 строки упаковывать: данные, процедура, проверка.

Быстрые итерации это лишь один из аспектов разработки ПО.
Вы сильно ушли от темы, интересны все-таки архитектурные вопросы, проблемы из-за игнорирования архитектурных принципов и их решения.
 

On 12/6/2022 at 12:51 PM, Solonovatiy said:

Сами тесты на СИ выглядят просто ужасно и с легкостью по сложности превосходят сам тестируемый код, они против всех заветов, сами вскоре начинают требовать тесты.
И если в том же JS, можно вполне обойтись общими возможностями тестового фреймворка, то для сишного приложения вам скорее всего придется писать свой тестовый фреймворк поверх общего. (и покрывать его тестами). Иначе ну совсем жопа =\.

Советую глянуть The Progmatic programmers "Test-Driven Development for Embedded C" James W. Grenning.   Это автор тестовых C фреймворков.
 

On 12/6/2022 at 12:51 PM, Solonovatiy said:

Это все хорошо, но вот только частенько кому-нибудь HAL или библиотекам популярным, вообще наплевать на это и вам что бы их затолкать в код написанный по этим принципам, надо еще тонну и тележку связующего кода написать. В лучшем случае надо делать свой BSP и над ними городить портянки еще, т.к. иначе, со сменой МК даже внутри серии может поменяться интерфейс BSP и все по....Я не к тому, что это все ненужно, скорее про то, что блин с таким скрипом это приходиться заталкивать, что очень часто легче забить.

 
ST HAL в своей идее зародился и поддерживается как слой для Demos & Examples, реализован малокомпетентным персоналом.
 

On 12/6/2022 at 12:51 PM, Solonovatiy said:

Вот об эту штуку я сильно сильно обжегся. Я не знаю способа сделать это БЕЗ строк. А строки в большинстве случаев не особо доступны (статическое выделение вся фигня), да и вообще жалко памяти строки гонять.  Без строк - у меня нет понимания внятного способа, как пользоваться типизацией и как безопасно гонять объекты в С++. Т.к. по факту нужно их сериализировть, а потом десериализировать. В каждом принимающем\отправляющем модуле.

Строки и сериализация? Вряд ли.  (полагаю у вас Javascript прошлое и отсюда такие идеи).
Самое простое для вас это ознакомиться с реализацией сообщений в WinAPI, AmigaOS или погуглить "osCreateMesgQueue".   (чистый C).

 

[turnon 1]

On 12/5/2022 at 6:05 PM, tonyk_av said:

Я склоняюсь к использованию FatFS. МК STM32F407, память W25Q64. Использую GCC. Прикручу FatFS к stdio, чтобы пользоваться стандартной библиотекой. Замечу, что все данные, которые я будут записывать, сопровождаются контрольной суммой. Ну а 4М на борту дадут возможность загружать через LAN прошивку для обновления.

Ваш FatFS протрет дыру в W25Q64, вместе с контрольной суммой.

 

On 12/5/2022 at 7:00 PM, Forger said:

а второй диск (внешняя флэшка или sd карта) - журнал событий, сбои ему не так критичны, т.к. эта файловая система поддерживает т.н журналирование.

Пробовали журналирование? Как работает, сколько требует RAM, восстановление из журнала сколько времени занимает?

Я пробовал µC-FS, в ней и журналирование, и выравнивание износа. В итоге не понравилось тем что работа с журналом может занимать недопустимо много времени, срабатывал вочдог. А выравнивание износа начинает тормозить при флешке больше 1 МБ.

В итоге отказался от файловой системы вообще и сделал свой вариант кольевого буфера на NOR, как описал @jcxz здесь

[turnon 1]

On 12/5/2022 at 7:00 PM, Forger said:

вот уж прям ресурсоемкая вещь )))

хотя из готовых в открытом доступе действительно есть довольно "тяжелые"

То что популярно у ардуинщиков для JSON, это конечно жуть.

Для JSON использовал jsmn, но он требует буфер для хранени токенов, при увеличени размера файла (количества токенов) нужен и больший буфер, это неприемлемо.

Нашел вот такую штуку - mjson, не требует никаких буферов (ничего не хранит в RAM), для извлечения элемента парсит весь json, но меня это устраивает.

[tgruzd 11]

6 минут назад, turnon сказал:

json

 Я использовал cJSON.  Использует динамическое выделение памяти, особой легкостью не отличается, в целом неплох. 

[Forger 26]

34 minutes ago, turnon said:

не требует никаких буферов (ничего не хранит в RAM), для извлечения элемента парсит весь json, но меня это устраивает.

Я использовал coreJSON, есть на гитхабе. Использовал его только для чтения json настроек.

Каждую пару ключ-значение парсит с самого начала (или откуда указать). Для свое работы тоже не требует буферов. Умеет проверять валидность всего файла.

Но для ускорения под весь json-файл выделяю в куче сколько надо, потом высвобождаю (куча не стоковая на базе tlsf).

 

 

55 minutes ago, turnon said:

Пробовали журналирование?

Да, работает. Каких-то особых требований нет, все расписано в описании и ограничениях.

Разве что я старался не работать с большими файлами, а чаще создавать новые (если речь о журналировании каких-то событий в проекте). Чтобы избежать файлового бардака, использовал вложенные каталоги.

Обязательно писал в атрибуты файлов системное время и дату. Но это не имеет отношения к тому журналированию, это просто способ избежать бардака с сотнями мелких файлов.

Ибо при сбое системы с включенным журналированием просто будет утерян последний файл. А при таком подходе это уже не так критично.

1 hour ago, turnon said:

Ваш FatFS протрет дыру в W25Q64, вместе с контрольной суммой.

Это сделает вообще любая файловая система без кэширования )))

W25Q64 имеет минимальный блок для стирания 8кб, а не 512 как было бы идеально. Это сильно усубляет ситуацию.

Но даже один кэш в 8к значительно ускоряет работу (при записи) и износ первых блоков, где лежит FAT.

В своем случае с этой же памятью я применял самописный кэш на 8к на запись, это по сути спасло проект от переделок платы на другую память :)

 

[tgruzd 11]

4 часа назад, Forger сказал:

8кб

4 часа назад, Forger сказал:

Но даже один кэш в 8к значительно ускоряет работу (при записи)

Как это отражается на вероятности повредить данные, при внезапном пропадании питания?

[Forger 26]

57 minutes ago, tgruzd said:

Да, забыл уже ) Отложилась цифра 8, очевидно перепутал с 8 секторами по 512 ))

 

57 minutes ago, tgruzd said:

Как это отражается на вероятности повредить данные, при внезапном пропадании питания?

Ну там же написано в описании - теряется последний сохраняемый файл, если его изменения не успели записаться в FAT.

Восстановление соотв. утилитой в винде, которая из одной живой таблицы FAT продублирует во вторую поврежденную.