Давайте не скатываться в срач о выборе процессора. Выбор процессора - важный пункт, но мы во-первых его уже по нашим критериям уже выбрали, а во-вторых - мы действительно собираемся писать так, чтоб можно было при необходимости перенести на другой.

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

сложные алгоритмы это сложные алгоритмы. я не буду рассказывать ни про цикломатическую сложность ПО, ни про метрику, ни про время вывода продукта на рынок и затраты на разработку ПО в человеко-часах. Это всем понятно. Да, кодогенерация крайне неоптимальна, но тем не менее такие проекты как DSPACE и ETAS широко используются при разработке ECU во всем мире.
Я как-то работал над проектом который достался от NVIDIA. Что касается coding standards там все было по-правильному, но что касается архитектуры - так годы, за которые этот проект развивался, превратили ее в спагетти. В какой-то момент NVIDIA закрыла проект, так и не решив многих проблем, и которые пришлось решать мне. Проблемы весьма тривиальные, но вот на их решение, ввиду сложности кода, приходилось тратить недели.
3 млн строк вообще не показатель сложности проекта. Если проект разбивается на отдельные функционально независимые модули, каждый из которых может отлаживаться отдельно, то количество строк это прежде всего показатель трудоемкости проекта.

P.S Господа, я делюсь реальным опытом, как оно все обстоит на самом деле. Люди, которые разрабатывают автоэлектронику, далеко не пальцем подкованные, так что не будем выставлять их кретинами, включая тех, кто разрабатывал ECU для тойоты.

Я думаю достаточно про тоёту. История там тёмная, мы всю историю всё равно не угадаем - а в реалиях японской компании они нам не расскажут.

У меня работа в проекте на 2 миллиона строк кода - так что я в курсе, что такое спаггеди и что такое старый код. Тому проекту 8 или 9 лет - и по коду это конечно же видно. Итак, давайте ближе к телу rusEfi

Итак, я закоммитил починенный IAR проект. Основной сборщик у нас gcc/Makefile, кстати у нас есть continues integration - http://jenkins.rusefi.com/ - и даже немного юнит тестов, так что стараемся можно.

несколько warning я убрал, самые плохие с моей точки зрения были про enum/int.

Осталось очень много
implicit conversion from floating point to integer
я к нему противоречиво отношусь, может быть его просто глобально выключить?
Ну и классический
statement is unreachable
в конце методов-потоков while(true), тоже не уверен как лучше с этим поступить. Как лучше?


Update:
посмотрел на примеры "mplicit conversion from floating point to integer", нашёл две баги. Так что это предупреждение конечно же полезное - пойду сейчас везде починю.

для начала можно определится надо ли вообще данную переменную держать в float
и никто не мешает в коде в явном виде преобразовывать float в int

Спасибо, я в курсе явного преобразования - вопрос был как правильнее поступить - забить, фиксить или еще скрывать. В итоге понял, что забивать или скрывать нельзя и и правда нужно фиксить

Сделал лучше:


Осталось в основном unreachable statement после while(1)
Есть вариант делать while(!chThreadTerminated()), но это лишние байтики ради ворнинга. Есть ли варианты лучше?

Хорошо, если Вам не нравится слово идиоты, то я назову ето по другому. Люди которые БЕЗДУМНО вставляют в управляющую программу МИКРОКОНТРОЛЛЕРА ВЫПОЛНЯЮЩЕГО ВЫСОКООТВЕТСТВЕННОЕ ПРИЛОЖЕНИЕ В ЖЕСТКОМ РЕАЛЬНОМ ВРЕМЕНИ результат кодогенерации в матлабе или в другом софте(однозначно менее качественном, т.к. инвестиции в тот спецсофт на порядки меньше, чем в матлаб) возможно не идиоты. Возможно они преступники и сознательно пытаются убить пользователей их "продукта".
А профессиональные разработчики в таких случаях обычно используют матлаб и другие инструменты для моделирования, а результат - таблицы, коэфф полиномов и т.д. вставляют затем ручками в свой исходник. Тогда все четко, и никаких 11000 глобальных переменных.



в свете таких реалий я чувствую надо поставить все машины на прикол, и срочно вливаться в проект Андрея. И потом ездить на своих "мозгах", а не на "профессиональных".
p.s. был бы премного благодарен за информацию в машинах каких марок следует ожидать электроники спроектированной с вот таким профессионализмом.

еще ваша входная аналоговая схема напрягает.

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



Андрей а здесь можно поподробнее - ты собрал проект 3 разными компиляторами ?
Т.Е. это не 3 разных проекта с синхронизируемыми исходниками, а именно 1 с разными makefile's и конф. файлами среды ?

скачал проект, случайно ткнулся в первый попавшийся модуль. Попал в crc. Ты его вычисляешь. Зачем ? для crc нужно делать таблицу, и получать его за 2 команды. как то так:

char CRC8(void *data,usint size_data){
uchar *a,crc=0;
usint i;
a=(uchar *)data;
for(i=0;i<size_data;i++){
crc=CrcTable[crc ^ *a];
a++;
}
return crc;
}

const uchar CrcTable[256]={0, 94, 188, 226, 97, 63, 221, 131, 194, 156,
126, 32, 163, 253, 31, 65, 157, 195, 33, 127, 252, 162, 64, 30, 95, 1,
227, 189, 62, 96, 130, 220, 35, 125, 159, 193, 66, 28, 254, 160, 225,
191, 93, 3, 128, 222, 60, 98, 190, 224, 2, 92, 223, 129, 99, 61, 124,
34, 192, 158, 29, 67, 161, 255, 70, 24, 250, 164, 39, 121, 155, 197,
132, 218, 56, 102, 229, 187, 89, 7, 219, 133, 103, 57, 186, 228, 6,
88, 25, 71, 165, 251, 120, 38, 196, 154, 101, 59, 217, 135, 4, 90,
184, 230, 167, 249, 27, 69, 198, 152, 122, 36, 248, 166, 68, 26, 153,
199, 37, 123, 58, 100, 134, 216, 91, 5, 231, 185, 140, 210, 48, 110,
237, 179, 81, 15, 78, 16, 242, 172, 47, 113, 147, 205, 17, 79, 173,
243, 112, 46, 204, 146, 211, 141, 111, 49, 178, 236, 14, 80, 175, 241,
19, 77, 206, 144, 114, 44, 109, 51, 209, 143, 12, 82, 176, 238,
50, 108, 142, 208, 83, 13, 239, 177, 240, 174, 76, 18, 145, 207, 45, 115,
202, 148, 118, 40, 171, 245, 23, 73, 8, 86, 180, 234, 105, 55, 213, 139,
87, 9, 235, 181, 54, 104, 138, 212, 149, 203, 41, 119, 244, 170, 72, 22,
233, 183, 85, 11, 136, 214, 52, 106, 43, 117, 151, 201, 74, 20, 246, 168,
116, 42, 200, 150, 21, 75, 169, 247, 182, 232, 10, 84, 215, 137, 107, 53};

Ну а можно немного констуктивнее? Ну как-бы мысли пока в текущем сообщении не очень много.
Чем именно напрягает? Как можно улучшить?
Я же более чем открыт к предложениям

Не совсем тремя компиляторами.

Двумя компиляторами - что-то там внутри IAR и GCC. Исходники одни, и три файла как бы проекта: 1) iar 2) Makefile (gcc) 3) Eclipse (gcc)

#2 - самый стабильный, потому что крутиться на jenkins. Я испольщую Eclipse проект - но там нюансы со сменой версии ARM plugin - так что мне нужно переехать на новую версию плагина в моём Eclipse проекте. Ну и IAR иногда отстаёт при добавлении новых файлов - но сейчас актуален.

А про CRC - она работает и бог с ней Всё-таки преждевременная оптимизация - это зло. Сейчас CRC нужна только в момент старта - там экономить смысле нет, это один раз выполняется. Скоро CRC нужна будет для второй версии TunerStudio протокола - опять же, на фоне тормозов передачи данных ускорением CRC алгоритма можно пренебречь. Да и память под таблицу не бесплатная - короче есть нюансы

Про произовдительность текущий нюанс например http://forum.easyelectronics.ru/viewtopic....f=7&t=17529

пасибки, ето нам очень понра...


ну как бы я не сказал что ето оптимизация. ето просто одна из форм записи функции
не думаю, что 256 байт флеша ето дорого. впрочем, я не настаиваю


в операционках всегда жуткие тормоза с printf. в qnx на x86 упирались в то же самое...
я бы предложил буферизовать/логгить во внешнюю ферритовую память. Обожаю Everspin. 30$/16 Мбайт, НО:

память энергонезависимая (типа флеш)
есть spi/параллельный интерфейс
бесконечное количество циклов записи
запись/чтение в память происходит не как во флеш, а со скоростью статики

MR4A16B - параллельная память 16 Мбайт 30$ в Америке цикл 35 нс
MR25H40 - последовательная SPI 4 Мбайт 11$ в Америке частота интерфейса 40 МГц
кстати если решишься на логгинг туда, то есть довольно неплохая (на мой взгляд) реализация кольцевого буффера во флеши. не моя, честно краденая, но код мне там понра, а хозяин буде рад

va_start/va_arg/va_end отвечают просто за перемещение указателя стека для выборки неявных параметров функции.
Никаких тормозов вызвать не могут. Быстродействие их может зависеть только от количества дополнительных параметров.
А ввод/вывод чисел с плавающей запятой действительно очень долгий. Ибо тогда в printf идет много делений и умножений.
В этом смысле библиотеки компиляторов по производительности различаются кардинально.
IAR для ARM-Cortex хороший выбор. У него самые быстрые библиотеки в целом и printf в частности.

Кстати странно, что такие вопросы возникают. Вы разве не используете профайлер в IAR с JTAG/SWD отладчиком?

А вот зачем вы там используете тулс под названием TunerStudio?
Какую пользу он вам приносит?
Это ведь просто визуализатор логов, никих алгоритмов, апроксимаций, интерполяций, а тем более моделей управления он не подсказывает, не так ли?

Да, и куда новый софт залили? Смотрю на http://sourceforge.net/projects/rusefi/fil...oad?source=pdlp. Там лежит все тот же проект. Ничего не изменилось.

Торможит chprintf - это имплементация из ChibiOS, в том топике есть ссылка - к стандартным либам отношения не имеет. И там замеряется конкретный вызов который печатает строки - так что %f тут явно не при чём

о! профайлер в IAR - не знал. буду смотреть и пробовать! как уже говорил, я обычно в Eclipse

TunerStudio чуть-чуть больше, чем визуализатор логов. Он во-первых показывает живые данные, а во-вторых позволяет менять настройки - карту топлива редактировать и так далее. Короче всё-таки полезно.

Изменения всё-таки в SVN - кототорый тоже на SF, http://svn.code.sf.net/p/rusefi/code/trunk/firmware/
Я сейчас в поле, мне тут не проверить head - так что новый tag делать не могу.

Да варнингов стало 29.

Но самые опасные, на мой взгляд, такие: Warning[Pa082]: undefined behavior: the order of volatile accesses is undefined in this statement C:\Temp\RUSEFI\chibios\os\hal\platforms\STM32\OTGv1\usb_lld.c 606
Если тип volatile выбран не без оснований, то где во первых мьютексы (или что-либо другое для защиты), во вторых действительно такие переменные надо читать с особой осторожностью.
Последствия таких ошибок как правило сразу не проявляются. Могут вылезти когда кажется все уже отлажено.

Потом сообщения типа: Warning[Pe068]: integer conversion resulted in a change of sign C:\Temp\RUSEFI\console\status_loop.c 53
тоже очень плохие. Не следите за знаками? Присваиваете беззнаковому типу отрицательное значение?

Неужели GCC этих предупреждений не показывает?

Будете смеяться - но да, совершенно осознанно присваивают беззнаковому отрицательное значение, потому что присвоить я хочу (MAX_VALUE - 1000) - и присваиваю его как раз как -1000. Так что именно тут всё в порядке.

Про volatile сейчас посмотрю, это сорцы rtos - но им можно написать.

Если мы хотим педантично от ворнингов избавиться - то нужно что-то делать с unreachable statement. Какие будут предложения?

Убрать все эти return-ы.
А зачем они нужны если реально из циклов перед ними нету выхода?

Поток варнингов при компиляции замыливает глаз. Очень легко пропустить что-то серьезное.

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

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



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

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

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

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

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

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

о! очень хорошие вопросы постараюсь ответить на каждый по порядку:

регистрировать обработчики консоли динамически - идею взял в своей голове, так показалось элегантно: каждый файлик самодостаточен, у него наружу в магическое место не торчат описание обработчиков или названия команд. Да, на этапе компиляции всё известно - можно бы было явно определить стуктуру, но был бы ворох #if для опциональных модулей и так далее.

Добавил немного комментариев в https://svn.code.sf.net/p/rusefi/code/trunk...console_logic.c
Стек маленький - это относится не только к потоку консоли, это относится ко всем потокам rusEfi. Там везде программирование в таком стиле, чтоб стек особо не был нужен. Не знаю, хорошо это или плохо - это не догма, просто пока стек большего размера нигде не был нужен.
По поводу контроля стека - там есть
#define CH_DBG_ENABLE_STACK_CHECK TRUE
которая включает ChibiOS механиизм контроля. Как он сделан я не знаю, но я на практике видел, что он работает - и я его пока доверился.

У этой консоли все задачи очень простые по определению - какой-то параметр поменять, что-то отладочное вывыести. Хоть консоль и не критическое место, но обработчки пишутся осознанно очень простыми - в том числе за счёт этого и не особо нужна явная синхронизация. Например, типисный обработчик setRevolutionPeriod - да, там выставляются две переменные и выставляются они не атомарно. Но там и нет проблемы в этом особо - т.е. синхронизации мало, потому что мало мест где она нужна (update: зарефакторил этот обработчик - одна переменная и не нужна была в виде глобальной переменной, всё стало еще честнее)
Ил вот printFullAdcReport - да, там не атомарности вывода состояния всех АЦП каналов. Так она там и не нужна. А атомарность чтения каждой 32 битной переменной у нас надеюсь гарантирована 32битной архитектурой?

Тот же volatile - я более чем в курсе, кто он и зачем. Но такой вопрос - а в нашей конкретной реализации stm32f407 volatile вообще актуален? Там есть промежуточные кеши, которые могут у разных потоков разойтись внутри единсвенного ядра? Хотя даже без кешей volatile на порядок операций конечно может влиять. И в теории хочется код конечно правильный в общем, без конкретно stm32f407. Ну, я не бог - где-то приходится срезать углы и писать good enough код.

А можно про idle_thread и слежение за загруженностью поподробнее? Буду рад совету на эту тему.
Сейчас ситуация такая: основной код в обработчиках прерываний, а текущая ChibiOS собирает статистику только по потреблению CPU потоками. (см. команду ths и метод cmd_threads) в следующей ChibiOS обещают собирать статистику по прерываниям.

А пока у меня есть своя доморощенная https://svn.code.sf.net/p/rusefi/code/trunk...til/histogram.c в которую через hsAdd замеряются два самых важных обработчика.
(Блин, давно пора заставить себя переименовать main_loop в main_event_handler)

Если посмотреть с другой стороны, то ваш подход модуле-центричен, а я бы придерживался потоко-центричной идеологии.

Ваша задача заставить приложение работать надежно и для этого вам нужно защитить потоки от разрушений.
Это легче сделать когда все процедуры потоков у вас в одном файле и не требуют бесконечных поисков по сорсам.
Второе вспомогательное средство это анализатор дерева вложений IAR-а.
Опять же из-за того что вы широко используете run-time инициализацию указателей на обработчики, у вас эта фича не работает.
Получается вы создали архитектуру котороая блокирует многие мощные инструменты анализа кода и исправления ошибок.
И это элегантность?

Вообще есть подозрение, что вы там уже запутались в своих обработчиках.
Можете опровергнуть мои подозрения и показать листинг запущенных задач и размеры занятых и свободных стековых пространств?

Иначе чем объяснить вот такое явление:
Нажмите для просмотра прикрепленного файла

Это структура вызовов в обработчике вызываемом в прерывании. Как видно дело доходит до того что, обработчик критического прерывания вызывает print!!!
Это тот который у вас до сих пор необъяснимо медленно работает. Хотя все объяснимо. Там же дальше за put идет еще длинная цепочка слоя эмуляции COM порта через USB c вообще непредсказуемыми задержками.
И это явно. А неявно там еще callbacks есть, которые могут указавать на еще более монструозные цепочки, но они нам не видны.

Знаете, что ключевым моментов в системе непрерывного виброконтроля на Саяно-Шушенской ГЭС был интерфейс USB. И ее тогда так и не ввели в нормальную эксплуатацию. И все рвануло.

Обращение к драйверу USB и вообще к любым print из прерываний надо убрать категорически.

Вы права, но есть нюансы - я не идиот
Обратите внимание - стек print включает в себя вызов метода chDbgPanic. Этот метод - это действительно panic, если он вызвался - то у нас проблемы посерьёзнее цепочки вызова put

А еще не путает котлету print с мухой printf, производительность которой у меня вызывает вопрос. Первая печатает в консоль, вторая - печатает в буффер памяти. Так что не всё так просто объяснимо

ths запущу, когда до дома доеду. А с потоками - всё-таки главное тут обработчик событий, к сожалению - не поток.

Предлагаю чуть-чуть снизить накал страстей, я надеюсь по моему коду видно, что школу я закончил уже давно. Я буду рад ответить на все вопросы, но пожалуйста не делайте поспешных выводов, как например с print, который внутри panic и котороый не printf

Не понял.
Не вы ли здесь жаловались на медлительность chvprintf?
А print ее как раз и вызывает.
Еще она вызывается в обработчиках через callbacks. Собственно прослеживая callbacks я на это место и вышел.

И что в вашем контексте хуже: мухи или котлеты ?

Честно говоря, я тоже использую форматированную печать в обработчиках исключений.
Но при этом пишу прямо в периферию фиксированного UART-а.
Никаких HAL, printf и прочих прослоек не использую . Шансов что все это будет живое после возникновения исключения почти никаких. Даже стек сразу переопределяю.

Я потерял нить

Итак, было сомнение в работе с оборудованием из обработчика событий - тут прояснили, что проблемы нет, потом что вызов только из panic

Сомнение в использовании HAL из panic - UART великолепно отрабатывает, потому что HAL это просто цепочка вызовов в данном случае не взаимодействующая с ОС видимо. В случае USB консоли - да, panic сообщение теряется. Это бы хотелось однажны побороть - так что хорошая идея завести тикет: https://sourceforge.net/p/rusefi/tickets/40/

По поводу chprintf в обработчкике: я пока не вижу причин его не использовать. Да, сейчас там что-то не так с перфомансом - ну так нужно взять и разобраться, почему именно. Я не вижу оснований, почему бы он был обязательно должен быть тормозным, когда дойдут руки - либо пофиксим перфоманс, либо когда точно будет понятно, что его не пофиксить - отойдём от chprintf. Тикет https://sourceforge.net/p/rusefi/tickets/35/ есть - значит проблема не забутиться.

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

Я говорил, что поинтер callbacks в обработчике прерывания указавает на функцию которая тоже использует chvprintf.
chvprintf в свою очередь работает с блокирующим! вызовом put.

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

Использование блокирующих вызовов в прерываниях - грубейшее нарушение принципов RTOS.

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

У меня кардинальное предложение.
А почему бы вам пока ваш проект достаточно маленький не перейти на другую платформу?
Я имею в виду микроконтроллеры серии K7x, например K70P256M150SF3.
Модуль так и быть, я бы вам нарисовал.
Получили бы гораздо более мощную бесплатную RTOS - MQX. Там и поддержка серьезней.
С портирвание вашего алгоритма помог бы.


Микроконтроллеры Freescale семейства Kinetis имеют такую замечательную фичу как аппаратный настраиваемый фильтр входных цифровых сигналов.
Такие интерфейсы как I2C, SPI, UART часто могут уходить в ступор при наличии глитчей на линиях. А Kinetis их успешно фильтрует.
Незаменимая вещь в условиях сильных помех. Сегодня меня буквально выручил.

Не совсем понимаю, давай(те) уточним.

Я вижу chvprintf которому передаются разные имплементации потоков вывода через chSequentialStreamPut. Мне кажется, что в обработчиках (кроме ситуации panic) передаётся неблокирующая имплементация

static msg_t put(void *ip, uint8_t {
MemoryStream *msp = ip;

if (msp->size - msp->eos <= 0)
return RDY_RESET;
*(msp->buffer + msp->eos) = b;
msp->eos += 1;
return RDY_OK;
}

Я здесь ничего страшного не вижу. Я где-то заблуждаюсь?

Как я уже несколько раз пытался сказать - в важных местах логгинг идёт через мой буффер в памяти

Таки, момент истины. я предлагаю плату с TI Integra. Там просто Linux, и вообще все круто)

Чтото уважаемый AlexandrY стал нагнетать...



Я конечно не великий гуру программирования. Но не объясните ли мне плз, как ето UART может перейти в ступор ?

Поезд смены платы ушёл. Линукс это круто, но не для управлением форсунки - в линуксе нужно дико шаманить в сторону OS реального времени.

пожелаем поезду успехов.

Ладно, еще покритикую если никто не против.

Я вот в коде выше вижу много "страшного". Буффер молча игнорирует данные и никого ни о чем не предупреждает в случае если в нем нет места.
Но вообще автор оси написал, что этот вызов должен быть блокирующим. Кстати put при пересылке через USB как раз блокирующий.
Ну ладно, скажем здесь автор сам не знал че хотел.

Но почему же в приикладном коде вообще не используются сервисы этой самой RTOS?
Ни мьютексы, ни семафоры, ни очереди. ничего!
Зачем тогда вообще эту ось выбрали. Только ради Serial-over-USB?

Но зато тут же начали изобретать велосипед в виде буфферизированных логеров (прекрасно решается очередями), вызовом блокировки прерываний (а по уму делают мьютексами) и т.д.
Кста, там нагородили с приоритетами в mcuconf.h. Посмотрите макрос CORTEX_PRIORITY_MASK , он явно не позволяет делать проритет больше 8.

Такое чувство что вы не доверяете доморощенной ОС-и? Правильно, я бы тоже не доверял.
Скажу больше.
Хоть автор там и уверяет, что его переключение контекста самое быстрое, но тем не менее примитивно сохряняет все возможные регисты ядра включая сопроцессор.
В то же время MQX селектирует задачи и для тех кто не использует сопроцессор, зря регистры не гоняет в стек и обратно.

Далее проблема стека. Все будут смеяться когда узнают, как chibios следит за стеком.
Там на самом деле нет функций монитороинга за свободным пространством стека, но зато есть проверка (только при переключении контекста) не вышел ли стек за свою границу.
И самое смешное после этого ось не меняя указателя стека начинает вовсю юзать свои сервисы пытаясь через USB драйвер нам сообщить об этом событии.
Это все равно как после кораблекрушения продолжать крутить штурвал.

Далее с определением свободного процессорного времени. Ось якобы может посчитать время выполнения задач.
Интересно, как можно узнать время выполнения задач всего лишь отмечая какая задача и сколько раз была прервана обработчиком прерывания системного таймера.


Ну и вообщем по прикладному алгоритму. Математики конечно минимум. Фильтация никакая не используется. Даже от датчика детонации похоже.
Но самое странное, как мне видится это, как двигателем можно управлять исключительно по пропорциональному закону хоть и через нелинейную таблицу.
Осцилляции и неоптимальность (по сути перерасход топлива) тут гарантированы.

Хотя на все конечно можно закрыть глаза.
Ведь проект этот просто по сути логгер имеющий мало отношения к риалтайму и надежности.

Это уже не критика, это уже догма головного мозга. Есть пять способов сделать буфферезированный вывод, и не мудро считать только один правильным. Есть пять способов контролировать стек - и не мудро считать только однин правильным.

Критика ОС в перемежку с критикой rusEfi - немного каша. Господи, что за зацикленность на MQX? У меня догма мозга чуть меньшая - я понимаю, что ОС всегда можно поменять на переправе, если на то будут весомые причины. Я считаю, что мне не нужно сделать идеально - мне нужно сделать хорошо. И я считаю, что я делаю хорошо

Но я открыт к помощи и предложениям. Я буду очень рад патчу, переводящему всё этот на MQX. Сложно не будет, потому что я сознательно минимизирую завязку на любую OS как раз для простоты портирования. Кстати, как там именно с лицензией, если отрезюмировать? В википедии вижу "royalty-free licensing" и "License: Proprietary"

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

MQX бесплатна пока вы применяете ее на микронтроллерах Freescale.
Патч не поможет, нужно все писать заново и начинать с bootloader-а.

Как, в MQX нет bootloader-а? Ну тогда спасибо не надо.
Ну и завязываться на Freescale я не планирую. А простота конечно же просто простота - никакой магии нет. В многопоточном программировании я более чем разбираюсь, все эти приметивы мне проще сделать самому и иметь над ними полный контроль - я считаю, что использовать сервисы каждой конкретной ОС нужно ровно в необходимых количествах, ОС не должна заменять мозг.

bootloader есть у меня.

Многопоточное программирование и realtime системы это разные вещи.
Я сам программировал многопоточные приложения на PC.
Это не сказал бы что легче чем realtime, но совсем другая специфика.

А в вашем проекте с реалтаймом ну полный провал.
У вас для критических секций используется исключительно запрещение прерываний уровня ядра.
Это так в линуксе можно. В RTOS так делают чтобы защитить максимум присвоение пары переменных.
А у вас и printf с запретом прерываний, или вот видел место где запрещаете прерывания и начинаете делать strlen и strcat на 5-и килобайтном массиве!
Ну хорошо еще что у вас там алгоритм без DSP обработки. События достотчно редкие. CAN интерфейс никакой.
USB правда есть, но уже и проблемы как бы с ним.
А если бы решили сделать фильтрацию (в референс дизайне от Freescale для одного цилиндра используют 7! фильтров) или ту же детонацию без внешней микросхемы или VR сенсор на внутренних ресурсах микроконтроллера (во! удешевили бы..) то бысто бы поняли, что на одних только обработчиках прерываний далеко не уедешь. Нужно разделять во времени прием данных и их обработку. Но запрещение прерываний ядра сильно уменьшает ресурсы времени.

А в MQX между прочим вы можете передавать события и сообщения в ядро прямо из обработчиков прерываний.

А если считаете свой дизайн "священной коровой", то зачем сделали его открытым?

Золотые слова про приём и обработку. Это 100% верно и мне действительно вероятно придётся эти места улучшать.

Именно для того, чтоб получить вот такую, ОЧЕНЬ ценную в целом критику, я и сделал всё открытым.

И таки да, многопоточное отличается от реального времени. И таки да, в этом мне еще некоторым вещам придётся научиться.

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

Итого: пошёл думать, какой именно тикет завести по итогам этого комментария.
Всё-таки MQX не вариант потому что Freescale не очень вариант. Уверен, что ChibiOS пока не тянет нас на глубину.

Еще раз хочу попросить поучаствовать программированием, но и за мысли уже огромное спасибо - мысли очень хорошие.

Груда металлолома управляет двигателем Субару. http://www.youtube.com/watch?v=r2dc_BvUXEc

Груда металлолома управляет электронным дросселем http://www.youtube.com/watch?v=8AiVcbKKczw (пока только PI).

надо ли объяснять что у груды металлолома нет ну ровным счетом никаких проблем ни с чем вообще!?

и да - я сторонний разработчик!

Я не квалифицирован судить о блоке МИКАС - я знаю, что процессор там слабый. Я знаю, что писать софт под быстрый процессор - проще, чем под медленный. Давайте в этом топике обсуждать в основном rusEfi

MaxiRPD кстати зарегестрирован на нашем форуме и даёт очень хорошие советы.

Андрей. Проблема систем управления вообще не стоит в написании софта. Сейчас у нас уйма софта в примерах разного качества под что угодно. Проблема в адекватных алгоритмах - а вот с ними плохо очень. Над ними приходится работать потому что никто на халяву не скажет как и что надо делать. Это все приходит только через моторы-опыт-время. И реализация на быстром процессоре и на медленном только вопрос владения языком. У меня нет проблем с MCS51 - я работаю с ним с 1988 года - и мне проще написать на нем чем на чем угодно вообще.


MaxiRPD это я. Я просто вспомнил что у меня тут давно есть аккаунт

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


Я завидую твоей памяти. Аккаунту 10 лет, а ты про него 'ВСПОМНИЛ'?

Все примеры которые так или иначе есть - написаны обычными программистами. Просто тебе это кажется не понятным - хотя это обычный автоматный метод. Да им сейчас мало кто владеет - но специалисты есть. Мало того я считаю что производительность не заменит тебе владение им (хотя это мое субъективное мнение)...

Хех, у меня тоже акк тут есть
emmibox, когда хочется/нужно что-то попробовать и предстоит ковырять чей то кривой (или просто очень оптимальный) код, то может оказатся, что трудозатраты этого просто не стоят. Железо дешевле труда программистов, так что сейчас уже можно позволить себе писать понятный код. Не максимально оптимизированный, не супер производительный, а понятный. Без понятного кода жизни не будет - проект будет доступен единицам. Ведь есть дизассемблированные прошивки, автором которых выступаете и вы. Но они надежно защищены

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

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

Очень дешевый путь получения ответов, пускай, есть. Вот нужен дешевый путь проверки и реализации.

Дизассемблирование - очень дешевый путь получения ответов. Но вот имплементировать свою версию этих алгоритмов проще в комфорте и уюте мощного процессора. Хотя как нам тут верно подсказывает AlexandrY, головой всё равно нужно думать.

Итого: блин, где же мне найти буквально одного умного программиста, а то почти одному тяжко тикеты стынут

всегда можно тупо подкинуть процессор. - просто еще один под задачу. любой! в любом виде!
и даже аргументировать состоятельность этого решения - "да тойота в стоке так делает"...
Только вот 10 лет уже как то в реальной жизни обходимся.

Потому что 10 лет опыта пропить сложно. Но сколько вас таких с таким опытом? Единицы. rusEfi пытается снизить порог вхождения. Хорошо это или плохо - отдельный вопрос

emmibox, очень хочется чтобы это был таки opensource еще и в том смысле, что к этому проекту должно быть легко подключиться. Если вдруг твой код придется перерабатывать кому-то другому, то его квалификация И мотивация вкупе с трудозатратами должны быть огромны. Велика вероятность, что делать этого никто не будет и код просто умрет. Очень высокая завязка как на тебя лично так и на квалификацию возможных последователей. Это, отчасти, является причиной смерти других проектов. Если кто-то хочет принять участие, то у него два пути - потратить несколько недель на разбирательство с кодом и результат этих действий ничего не гарантирует или просто забить. В результате каждый пилит свое, дублируя во многих местах одно и то же, тратя на эту дурную работу много времени. Все это касается программ вообще. Если код написан плохо, то вероятность того, что его будут развивать низкая, а вероятность того, что его будут развивать другие стремится к нулю.

Ориентированность на понятный код это то, что отличает rusEfi от других проектов. Практика показывает, что вокруг все чаще побеждают высокоуровневые, пускай и не имеющие максимальной производительности вещи. Какие-то ужасные интерпретируемые языки, высокие уровни абстракции и ООП. А все потому, что так проще программистам.

Да не определяется порог вхождения ни сложностью кода ни сложностью его написания.
Код - самое примитивное что там в принципе есть. в любой системе. любого производителя.
Да и не пишут его уже руками давным давно - он почти весь транслируется из моделей матлаба.
ЭСУД - чисто инженерная задача. с чисто инженерными заморочками. с очень маленькой долей электроники-програмиизма.

Что-то я запутался. У нас то ассемблер, то матлаб? Но я так, просто мысль вслух.

Я добавил информации в общее описание - оно живёт по адресу http://rusefi.com/docs/html/

Это реализация тех самых алгоритмов. Сначала алгоритм записывается кодом, потом кому-то надо будет из этого кода восстановить и понять алгоритм. Алгоритм работать будет и так и так, а вот насколько сложно будет все это понять и есть наш порог входа.

Вот и порог входа. Больше на стену похоже.

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

В мире нет реальных систем не с использованием интерпретируемых языков (на уровне ECU) ни с ООП в наборе. Абстракции только на уровне RTOS для переносимости опять же в пределах переносимости RTOS.

Я никому не указываю как оно должно быть. Я говорю о тенденциях вокруг и о том, что rusefi этим тенденциям вполне соответствует.