haker_fox 61 15 января, 2019 Опубликовано 15 января, 2019 · Жалоба 3 minutes ago, jcxz said: Если для второго варианта использовать драйвер из первого варианта, то будет куча лишнего, неиспользуемого. У меня драйвера сделаны в виде классов. И, например, арбитр шины SPI представляет из себя драйвер, единственно работающий с железным драйвером SPI. Но в его "слоты" можно добавить драйвера виртуальных шин, который для конечных потребителей будут смотреться как обычные драйвера аппаратных шин. Вот эти драйвера виртуальных шин и будут использовать всякие АЦП, память и т.п. Т.е получается цепочка: устройство - драйвер виртуальной шины - арбитр - железный драйвер шины. Если же устройство одно, то к железному драйверу шины подключаем сразу микросхему. Получается цепочка: устройство - железный драйвер шины. Арбитр сделан отдельной задачей. вот только систему приоритетов, как я хотел сделать, у меня не вышло. Но в целом всё работает. Естественно, использую три кита ООП. 8 minutes ago, Forger said: Вы все перепутали )) Вполне возможно, у меня тут уже 00:31, и я малость устал за день)))) Но я, поверьте, понимаю о чём вы говорите. Но излагать уже плохо получается. Надо дрыхнуть идти) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 241 15 января, 2019 Опубликовано 15 января, 2019 · Жалоба 16 минут назад, Forger сказал: Так это измеряется скорее в тактах проца, ведь время реакции напрямую зависит от ядра и его тактовой частоты (если грубо). Не обязательно. Если из ISR-а например посылаются события в мэйлбоксы/семафоры, на которые ждут задачи, то можно после каждой такой отправки в мэйлбокс внутри всех таких ISR-ов дёргать функцию решедулинга ОС, которая будет определять какую задачу перевести сейчас в состояние "выполняется" (и нужно ли). Тогда время реакции на сообщение в мэйлбокс будет минимальным. А можно функцию решедулинга дёргать только в прерываниях таймера ОС с частотой тиков ОС. Время реакции на сообщение в мэйлбоксе будет меньше. Но и загрузка ЦП такими вызовами решедулинга будет меньше. Как именно поступить - в зависимости от потребностей проекта, можно и так и так. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
haker_fox 61 15 января, 2019 Опубликовано 15 января, 2019 · Жалоба 11 minutes ago, jcxz said: И тогда придётся не только заново пересобирать все старые проекты, А если использовать систему контроля версий. И драйвера хранить в отдельном репозитарии. Затем отпочковать ветку под новую версию и использовать её для нового проекта. репозитарий подключить "сабмодулем" к проекту. Понимаю, что маленько запутанно. Но это то, что пришло в голову сразу, так сказать))) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Forger 26 15 января, 2019 Опубликовано 15 января, 2019 · Жалоба 7 minutes ago, jcxz said: Не обязательно. В коммерческих целях в своих рекламных проспектах производители ОС демонстрируют минимальное время реакции в мкс или нс, но обязательно указывают проц и его тактовую. Но сути это не меняет 4 minutes ago, haker_fox said: А если использовать систему контроля версий. И драйвера хранить в отдельном репозитарии. В принципе, именно так и делаю :) Но в проекте обязательно подключается не ссылка на библитоеку, лежащую где-то там, а сама уже собранная библиотека той или иной версии с соотв. hpp-файлами. Но при отладки библиотеки (в частности для добавления к ней функционала) в том или ином проекте, к нему подключается ветка из исходников библиотеки. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 241 15 января, 2019 Опубликовано 15 января, 2019 · Жалоба 10 минут назад, haker_fox сказал: А если использовать систему контроля версий. И драйвера хранить в отдельном репозитарии. Затем отпочковать ветку под новую версию и использовать её для нового проекта. репозитарий подключить "сабмодулем" к проекту. Понимаю, что маленько запутанно. Но это то, что пришло в голову сразу, так сказать))) Можно, только это уже не будет "одно отлаженное решение из проекта в проект", а просто - набор решений в чём-то похожих. Я собственно примерно так и делаю и не говорю что у меня одно решение на все проекты. Конечно беру наработки из старых проектов насколько это возможно. Но и переделываю их под новые требования. По ходу и новые идеи улучшений приходят. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
haker_fox 61 15 января, 2019 Опубликовано 15 января, 2019 · Жалоба 7 minutes ago, Forger said: не ссылка на библитоеку, лежащую где-то там, а сама уже собранная библиотека Да, да. Я это и имел в виду. Т.е.. мы берём из репозитария драйверов текущий стабильный релиз, и работаем с ним. Но, если проект в процессе разработки, или отладки, то можем взять "релиз-кандидат" или "бету". В любом случае, для работы с проектом энной давности, у нас могут быть расставлены и теги. 1 minute ago, jcxz said: Можно, только это уже не будет "одно отлаженное решение из проекта в проект" Ну смотря с какой стороны смотреть. В любом случае по меняется и развивается от проекта к проекту. Просто система контроля версий делает эти изменения более контролируемыми. А в целом - библиотека, я полагаю, будет оставаться одинаковой. Я лишь только о высокоуровневом коде говорю. Не о машинном))) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Forger 26 15 января, 2019 Опубликовано 15 января, 2019 · Жалоба 12 minutes ago, haker_fox said: Да, да. Я это и имел в виду. Т.е.. мы берём из репозитария драйверов текущий стабильный релиз, и работаем с ним. Но, если проект в процессе разработки, или отладки, то можем взять "релиз-кандидат" или "бету". В любом случае, для работы с проектом энной давности, у нас могут быть расставлены и теги. Да все, что угодно! Но смысл вы правильно поняли - базовую для всех проектов часть (ОСь, стеки, библиотека для периферии) кладем отдельно, отлаживаем на каком нить-тестовом проекте, который лежит как правило там же, собираем, рассовываем по реальным проектам, пользуемся. Для отладки прекрасно подходит соотв демоборда, Все в своем репозитарии, отдельно от других проектов. Всегда делаю ДВА вида библиотек: RELEASE и DEBUG, оба с максимальной оптимизацией, но DEBUG имеет функционал для сборки данных, трейсинга и т.п. отладочной "ботвы". Ну и соотв в RELEASE-сборке все это напрочь выпилено, оставлено только самое нужно. Далее в DEBUG версии некого проекта подключается соотв. DEBUG версия библиотеки, а переключаемся на RELEASE, то автоматом подключится соотв. библиотека. Просто, и ... универсально ;) У меня библиотеки собираются под семейства, а не под ядра. Поскольку в эту общую сборку входит как минимум библиотека для периферии и ОСь. В итоге в дереве проектов нет груды "посторонних" файлов, а только соотв. библиотеки и только те файлы (в т. ч. драйверы - если следовать терминологии jcxz), которые относятся только к этому проекту. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
haker_fox 61 15 января, 2019 Опубликовано 15 января, 2019 · Жалоба 1 minute ago, Forger said: а переключаемся на RELEASE, то автоматом подключится соотв. библиотека. Просто, и ... универсально ;) Понимаю, что в теории debug/release должны работать одинаково. Но всё же. При переключении в релиз не бывало, что вылазили баги, которых в отладочной версии не было? А вообще мне ваш подход очень понравился!!! Сейчас как раз нахожусь в раздумиях создания чего-то подобного (фреймворка в терминах уважаемого @AlexandrY), и тут как раз кстати такая тема на форуме образовалась!!! Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Forger 26 15 января, 2019 Опубликовано 15 января, 2019 · Жалоба 9 minutes ago, haker_fox said: Понимаю, что в теории debug/release должны работать одинаково. Но всё же. При переключении в релиз не бывало, что вылазили баги, которых в отладочной версии не было? Увы, раньше такое случалось частенько ... лечил традиционно - всякими "костылями" Но тогда у меня хватало глобальных объектов, структура самих проектов оставляла желать лучшего ... Сейчас такого уже нет Можно сказать, что для этого - уход от костылей - я и проектировал заново структуру всех своих новых проектов, особенно после того, как познакомился с "идеологией" Qt. Quote А вообще мне ваш подход очень понравился!!! Да пользуйтесь на здоровье! Но и делитесь своими решениями! Уверен, это многим будет интересно :) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
mantech 50 15 января, 2019 Опубликовано 15 января, 2019 (изменено) · Жалоба 1 час назад, Forger сказал: Всегда делаю ДВА вида библиотек: RELEASE и DEBUG, оба с максимальной оптимизацией, но DEBUG имеет функционал для сборки данных, трейсинга и т.п. отладочной "ботвы". Ну и соотв в RELEASE-сборке все это напрочь выпилено, оставлено только самое нужно. А почему всю эту ботву нельзя подключать дефайнами, чтоб иметь одну версию библиотеки? Всегда так делаю и не жалуюсь Изменено 15 января, 2019 пользователем mantech Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Forger 26 15 января, 2019 Опубликовано 15 января, 2019 · Жалоба 9 minutes ago, mantech said: А почему всю эту ботву нельзя подключать дефайнами, чтоб иметь одну версию библиотеки? Всегда так делаю и не жалуюсь Ну, и я именно так это и делаю, когда собираю сами библиотеки и сами проекты, но к проектам подключаются уже собранные соотв. библиотеки, а не их исходники. Для каждого семейства все ДВЕ библиотеки: RELEASE и DEBUG. Их перепутать невозможно )) Мне так удобнее. Но конечно же ничто не мешает подключить к проекту исходники библиотеки и пересобрать все в нужной сборке RELEASE/DEBUG Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
alexunder 4 15 января, 2019 Опубликовано 15 января, 2019 · Жалоба Как и @Forger, я сторонник создания как можно более общей (generic) базы и повышения уровня абстракции. @AlexandrY, существуют ли аналоги матлабовского StateFlow? Интересный инструмент, очень привлекает наглядный top-level view, с которым должно быть удобнее рассматривать сложные системы. P.S. Не пора ли тему переименовать или перенести последние страницы в какую-то новую тему по обсуждению архитектурных решений? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Forger 26 15 января, 2019 Опубликовано 15 января, 2019 · Жалоба 41 minutes ago, alexunder said: Как и @Forger, я сторонник создания как можно более общей (generic) базы и повышения уровня абстракции. Безусловно, здорово, когда после прорисовки структуры проекта в некой среде нажимаешь волшебную кнопочку и вуаля! - проект набит файлами с нужным базовым содержимым (куб не предлагать, он для этого не годится). Примерно по такому принципу построена в QtCreator, где видгеты соединяются через соотв. слоты/сигналы и все это сделано визуально. Код формируется и дополняется автоматически. С интересом наблюдаю за тем, когда же разработчики Qt наконец-то нормально приладят все это на baremetal хотя бы со своей гуи и сетевыми стеками ... Quote P.S. Не пора ли тему переименовать или перенести последние страницы в какую-то новую тему по обсуждению архитектурных решений? Слово за модератором Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
haker_fox 61 16 января, 2019 Опубликовано 16 января, 2019 · Жалоба 2 hours ago, alexunder said: Не пора ли тему переименовать или перенести последние страницы в какую-то новую тему по обсуждению архитектурных решений? Ой, я бы тему не трогал, а закрепил. А от неё сделал бы продолжение по ссылке на более "чистую" тему, если нужно. А то при разделении иногда теряется логический смысл и предпосылки. Особенно это заметно, когда пользуешься такими темами лет через 5 - 10 после их создания. Теряется нить повествования))) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
dxp 65 16 января, 2019 Опубликовано 16 января, 2019 · Жалоба 15 часов назад, jcxz сказал: "Генерируются скриптом" - это лечение головной боли при помощи топора. Зачем притягивать ещё какие-то левые сущности если это можно сделать штатными средствами асм/си или их препроцесора? Как всегда, не разобравшись в вопросе, выдали пузырь в лужу. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться