Поезд смены платы ушёл. Линукс это круто, но не для управлением форсунки - в линуксе нужно дико шаманить в сторону 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"

Сообщение отредактировал Андрей239 - Jan 13 2014, 15:31

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

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

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