Самодельная ЭСУД, Может кто-то захочет поучаствовать Опции

[Андрей239]

Скоро будет год, как я начал делать себе самодельный блок управления двигателем с использованием stm32 discovery и chibios. У меня есть работающий прототип, сейчас я пытаюсь всё это приблизить к юзабельному состоянию. Если вдруг кто-то захочет поучаствовать - буду рад

Моя идея - написать код проще, чем у существующих систем, и сделать аппаратную часть набором независимых функциональных модулей. Я в курсе, что есть несколько в разной степени аналогов - и всё-таки верю, что в смогу сделать платформу, более удобную и понятную в некоторых аспектах.

Видео прототипа - http://www.youtube.com/watch?v=GcxLY697WwM
Исходники живут https://sourceforge.net/projects/rusefi/
Сайт проекта - http://rusefi.com/

[Андрей239]

Спрятал эти return от IAR - потому что GCC они нужны. И да, у GCC нет ворнингов в этих местах и как-то выглядит, что у IAR с ворнингами ситуация круче.

Остались ворнинги, по которым надо думать - так что завёл тикет, чтоб не забыть: https://sourceforge.net/p/rusefi/tickets/39/



Ну а чтоб не замыливался взгляд кстати в GCC есть другой инструмент - там некоторые ворнинги можно перевести в категорию ошибок, ошибку пропустить уже сложнее

Я думаю с ворнингами мы позитивно продвинулись вперёд, теперь можно читать сам код уже более высокого уровня?

[AlexandrY]

Я думаю с ворнингами мы позитивно продвинулись вперёд, теперь можно читать сам код уже более высокого уровня?

Ну как понимаете, реверсить 18 тыс. строк кода не такая быстрая задача.
Но интереса ради посмотрел только начало.

Консоль сделана оригинально. Где подсмотрели идею регистрировать обработчики консоли динамически?
Только вот вопрос зачем?
У вас ведь не появятся новые обработчики пока работает одна и та же программа. (и загрузчика нет, ну может пока )
Т.е. все обработчики и так ясны на этапе компиляции. Почему бы их было не собрать в одном массиве в одном месте?

А в результате что получилось:
Заметьте, что консоль это отдельная задача.
Самой задаче выделили 384 байт стека.
Стек очень маленький. И вот по всем исходникам там и тут начинаете динамически регистрировать обработчики (узнаю стиль линукса ) .
Постепенно забывая где и какие обработчики зарегистрировали, насколько они сложны и сколько требуют стека.
В коментах к обработчикам нет никаких грозных предупреждений, что они работают в такой-то задаче с таким маленьким стеком.
Хуже того, забывая что эти обработчики в отдельной задаче вы не ставите мьютексы или семафоры или другую синхронизацию для защиты общих для задач переменных.
Спокойно читаете АЦП и проч. в консоли в то время как какая-то другая задача может туда писать.
Что еще трагично, RTOS chibios держит управляющую структуру задачи в том же стеке задачи.
Т.е. пропатчить RTOS и использовать встроенный в Cortex-M механизм защиты памяти скорее всего не получится .
Инверсия приоритетов хоть и кажется далекой абстракцией на самом деле при таких обработчиках встанет в полный рост.
А смешанный с управляющими структурами стек может привести к особо тяжелым сбоям.

Еще что интересно.
Разрабатываете как бы real-time систему, а _idle_thread пустой. Т.е. не следите за загруженностью процессора, хотя это единственный способ достоверно знать действительно ли вы работаете в реальном времени.