[haker_fox 60]

3 minutes ago, jcxz said:

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

У меня драйвера сделаны в виде классов. И, например, арбитр шины SPI представляет из себя драйвер, единственно работающий с железным драйвером SPI. Но в его "слоты" можно добавить драйвера виртуальных шин, который для конечных потребителей будут смотреться как обычные драйвера аппаратных шин. Вот эти драйвера виртуальных шин и будут использовать всякие АЦП, память и т.п. Т.е получается цепочка: устройство - драйвер виртуальной шины - арбитр - железный драйвер шины. Если же устройство одно, то к железному драйверу шины подключаем сразу микросхему. Получается цепочка: устройство - железный драйвер шины. Арбитр сделан отдельной задачей. вот только систему приоритетов, как я хотел сделать, у меня не вышло. Но в целом всё работает. Естественно, использую три кита ООП.

8 minutes ago, Forger said:

Вы все перепутали )) 

Вполне возможно, у меня тут уже 00:31, и я малость устал за день)))) Но я, поверьте, понимаю о чём вы говорите. Но излагать уже плохо получается. Надо дрыхнуть идти)

[jcxz 184]

16 минут назад, Forger сказал:

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

Не обязательно. Если из ISR-а например посылаются события в мэйлбоксы/семафоры, на которые ждут задачи, то можно после каждой такой отправки в мэйлбокс внутри всех таких ISR-ов дёргать функцию решедулинга ОС, которая будет определять какую задачу перевести сейчас в состояние "выполняется" (и нужно ли). Тогда время реакции на сообщение в мэйлбокс будет минимальным. А можно функцию решедулинга дёргать только в прерываниях таймера ОС с частотой тиков ОС. Время реакции на сообщение в мэйлбоксе будет меньше. Но и загрузка ЦП такими вызовами решедулинга будет меньше. Как именно поступить - в зависимости от потребностей проекта, можно и так и так.

[haker_fox 60]

11 minutes ago, jcxz said:

И тогда придётся не только заново пересобирать все старые проекты,

А если использовать систему контроля версий. И драйвера хранить в отдельном репозитарии. Затем отпочковать ветку под новую версию и использовать её для нового проекта. репозитарий подключить "сабмодулем" к проекту. Понимаю, что маленько запутанно. Но это то, что пришло в голову сразу, так сказать)))

[Forger 17]

7 minutes ago, jcxz said:

Не обязательно. 

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

 

4 minutes ago, haker_fox said:

А если использовать систему контроля версий. И драйвера хранить в отдельном репозитарии. 

В принципе, именно так и делаю :)

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

Но при отладки библиотеки (в частности для добавления к ней функционала) в том или ином проекте, к нему подключается ветка из исходников библиотеки. 

 

 

[jcxz 184]

10 минут назад, haker_fox сказал:

А если использовать систему контроля версий. И драйвера хранить в отдельном репозитарии. Затем отпочковать ветку под новую версию и использовать её для нового проекта. репозитарий подключить "сабмодулем" к проекту. Понимаю, что маленько запутанно. Но это то, что пришло в голову сразу, так сказать)))

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

[haker_fox 60]

7 minutes ago, Forger said:

не ссылка на библитоеку, лежащую где-то там, а сама уже собранная библиотека

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

1 minute ago, jcxz said:

Можно, только это уже не будет "одно отлаженное решение из проекта в проект"

Ну смотря с какой стороны смотреть. В любом случае по меняется и развивается от проекта к проекту. Просто система контроля версий делает эти изменения более контролируемыми. А в целом - библиотека, я полагаю, будет оставаться одинаковой. Я лишь только о высокоуровневом коде говорю. Не о машинном)))

[Forger 17]

12 minutes ago, haker_fox said:

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

Да все, что угодно!

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

Все в своем репозитарии, отдельно от других проектов.

 

Всегда делаю ДВА вида библиотек: RELEASE и DEBUG, оба с максимальной оптимизацией, но DEBUG имеет функционал для сборки данных, трейсинга и т.п. отладочной "ботвы". Ну и соотв  в RELEASE-сборке все это напрочь выпилено, оставлено только самое нужно.

Далее в DEBUG версии некого проекта подключается соотв. DEBUG версия библиотеки, а переключаемся на RELEASE, то автоматом подключится соотв. библиотека. Просто, и ... универсально ;)

У меня библиотеки собираются под семейства, а не под ядра. Поскольку в эту общую сборку входит как минимум библиотека для периферии и ОСь. 

В итоге в дереве проектов нет груды "посторонних" файлов, а только соотв. библиотеки и только те файлы (в т. ч. драйверы - если следовать терминологии jcxz),  которые относятся только к этому проекту.

[haker_fox 60]

1 minute ago, Forger said:

а переключаемся на RELEASE, то автоматом подключится соотв. библиотека. Просто, и ... универсально ;)

Понимаю, что в теории debug/release должны работать одинаково. Но всё же. При переключении в релиз не бывало, что вылазили баги, которых в отладочной версии не было?

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

[Forger 17]

9 minutes ago, haker_fox said:

Понимаю, что в теории debug/release должны работать одинаково. Но всё же. При переключении в релиз не бывало, что вылазили баги, которых в отладочной версии не было?

Увы, раньше такое случалось частенько ... лечил традиционно -  всякими "костылями" 

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

 

Сейчас такого уже нет 

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

 

 

Quote

А вообще мне ваш подход очень понравился!!! 

Да пользуйтесь на здоровье!  Но и делитесь своими решениями! Уверен, это многим будет интересно :)

[mantech 34]

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

Всегда делаю ДВА вида библиотек: RELEASE и DEBUG, оба с максимальной оптимизацией, но DEBUG имеет функционал для сборки данных, трейсинга и т.п. отладочной "ботвы". Ну и соотв  в RELEASE-сборке все это напрочь выпилено, оставлено только самое нужно.

А почему всю эту ботву нельзя подключать дефайнами, чтоб иметь одну версию библиотеки? Всегда так делаю и не жалуюсь

Изменено 15 января, 2019 пользователем mantech

[Forger 17]

9 minutes ago, mantech said:

А почему всю эту ботву нельзя подключать дефайнами, чтоб иметь одну версию библиотеки? Всегда так делаю и не жалуюсь

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

Для каждого семейства все ДВЕ библиотеки: RELEASE и DEBUG. Их перепутать невозможно ))

Мне так удобнее. Но конечно же ничто не мешает подключить к проекту исходники библиотеки и пересобрать все в нужной сборке RELEASE/DEBUG

 

 

[alexunder 4]

Как и @Forger, я сторонник создания как можно более общей (generic) базы и повышения уровня абстракции.

@AlexandrY, существуют ли аналоги матлабовского StateFlow? Интересный инструмент, очень привлекает наглядный top-level view, с которым должно быть удобнее рассматривать сложные системы.

P.S. Не пора ли тему переименовать или перенести последние страницы в какую-то новую тему по обсуждению архитектурных решений?

[Forger 17]

41 minutes ago, alexunder said:

Как и @Forger, я сторонник создания как можно более общей (generic) базы и повышения уровня абстракции.

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

 

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

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

 

Quote

P.S. Не пора ли тему переименовать или перенести последние страницы в какую-то новую тему по обсуждению архитектурных решений?

Слово за модератором 

[haker_fox 60]

2 hours ago, alexunder said:

Не пора ли тему переименовать или перенести последние страницы в какую-то новую тему по обсуждению архитектурных решений?

Ой, я бы тему не трогал, а закрепил. А от неё сделал бы продолжение по ссылке на более "чистую" тему, если нужно. А то при разделении иногда теряется логический смысл и предпосылки. Особенно это заметно, когда пользуешься такими темами лет через 5 - 10 после их создания. Теряется нить повествования)))

[dxp 34]

15 часов назад, jcxz сказал:

"Генерируются скриптом" - это лечение головной боли при помощи топора. Зачем притягивать ещё какие-то левые сущности если это можно сделать штатными средствами асм/си или их препроцесора?

Как всегда, не разобравшись в вопросе, выдали пузырь в лужу.