[Forger 26]

6 hours ago, jcxz said:

Причём тут "глобальные флажки"? Глобальными объектами нужно делать только те, которые нужны разным файлам. Если (как указывалось) пишется драйвер чего-либо, и этот драйвер в себя включает  ISR + набор переменных/констант + задачу ОС, то никаких проблем нет разместить всё это в отдельном файле.

Именно так раньше и делал. Но когда выродилась по сути своя библиотека периферии для МК, то она по логике вещей должна была утащить с собой хотя бы управление прерываниями, которые относится к тому или иному экземпляру периферии. 

Душа требовала красоты и лаконичности, а решение с голыми extern "C" векторами оказались как палка в колесе 

 

В итоге решил этот вопрос (как описал в этой теме), "автоматом" стартап (у меня Vectors) попали в эту же библиотеку. Каждая библиотека = одно семейство (не камень).

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

Повторюсь - МНЕ так удобно, МНЕ так понятно и легко читаемо, поскольку для МЕНЯ лично читаемость кода имеет очень важное значение.

Короче, не навязываю, применять/не применять - уже ваше дело.

[jcxz 234]

7 часов назад, dxp сказал:

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

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

[jcxz 234]

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

Именно так раньше и делал. Но когда выродилась по сути своя библиотека периферии для МК, то она по логике вещей должна была утащить с собой хотя бы управление прерываниями, которые относится к тому или иному экземпляру периферии. 

Любая попытка универсализации работы с периферией сразу приводит к неэффективности кода. Более эффективный код == более специализированный код.

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

Или Вы всю жизнь один проект пилите на одном МК?    Ну тогда вашей безмятежной жизни можно даже позавидовать. 

[AlexandrY 3]

1 hour ago, jcxz said:

Ну тогда вашей безмятежной жизни можно даже позавидовать. 

Да не, от такой жизни можно застрелиться.

Все стартапы уже давно написаны, они есть и у Kiel-а, и у IAR-а, и в mbed и у всех. Даже MATLAB! их имеет.
А в Zephyr вам даже не дадут писать стртап, ибо он там генерится в процессе компиляции. 

[AlexandrY 3]

19 hours ago, haker_fox said:

Что-то в этом есть. Но уж слишком гладко всё получается. Ведь есть, же наверняка, какой-то подвох?
Тогда возможны правки исходников. А это уже нарушение такой идеологии. 

Вы уже сделали с помощью этого инструмента реально продаваемые изделия?

Стек TCP/IP если свой захочется сделать, его вряд ли целесообразно строить на диаграммах.

Кстати! Портируемость у такого решения тоже под вопросом.

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

Прям сейчас пишу для проданного изделия в StatetFlow.

Свой TCP стек если писать с нуля , не вижу никакого другого способа как делать в стэйт диаграммах. 
Только раньше диаграммы были отдельно, а код отдельно, как у уважаемого Forger. А теперь диаграммы и код являются одним и тем же и не надо дублировать работу.

Портируемость даже не стоит обсуждать. StateFlow умеет генерить MISRA код и документацию готовую к сертификации ПО. Вы понимаете сколько это экономит денег?  

[Forger 26]

2 hours ago, jcxz said:

Любая попытка универсализации работы

Вы увидели то, чего тут нет. Уверяю )

 

Quote

с периферией сразу приводит к неэффективности кода. 

И тут мимо - работа напрямую через регистры всегда будет быстрее любых SPL/HAL и уж тем более кубов. Именно так я и тут делал.

 

Quote

Всегда пишу драйвера периферии

А я один раз сделал, и применяю отлаженное решение из проекта в проект 

Если чего-то не хватает, добавляю по ходу дел.

Ведь любой драйвер по сути - это набор функций. Дополнить недостающей - никаких проблем.

Уже существующие проекты от этого никак уже не изменятся даже после ребилда с новой версией библиотеки - ведь они не используют эти новые функции, линкер их туда не добавит :)

Точно также сделаны SPL / HAL, но меня они не устраивают по ряду причин.

Самое сложное - структура всей библиотеки - вот она как раз полностью спроектирована и уже проверена на нескольких разных проектах, переделки уже не требует.

До недавнего времени основной "костыль" был с обработчиками прерываний, но и он решен, как я описал выше. Теперь полная нирвана и вселенская джа 

 

 

[haker_fox 61]

3 hours ago, AlexandrY said:

А в Zephyr

А вот у меня вопрос такой академический))) Вы очень много работали (работаете) с осями. Из ваших сообщений на форуме, я сдела вывод, что вы используовали: FreeRTOS, MQX, Zephyr, RTX, другие, названия которых уже не помню. Есть ли какая-то одна-две, которые бы вы могли посоветовать для архитектур Cortex-M0/M3/M4(F)? Просто не всегда очевидно, какую ось выбрать (ну и middleware, конечно). Может быть у вас есть критерии выбора?

Допустим, девайсы не должны иметь очень много коммуникационных интерфейсов, ну достаточно: can, rs-232/485, tcp/ip (http, ftp, tftp, sntp, telnet, ssh), usb host, usb device. Графический интерфейс не особо нужен, но как формальность может и присутствовать. Реального времени в пределах 1 мкс не надо))) Достаточно от 100 мкс. Задачи не особо перегружены математикой, но БПФ вполне возможен.

Я понимаю, что критерии - так себе заданы. Более точно формализовать пока не в состоянии)))

Можно ли на основе них что-то посоветовать. Просто ваше мнение интересно)))

3 hours ago, AlexandrY said:

Вы понимаете сколько это экономит денег?  

Догадываюсь) Спасибо за подробный ответ!

[Forger 26]

26 minutes ago, haker_fox said:

Реального времени в пределах 1 мкс не надо))) Достаточно от 100 мкс.

Реальное время не измеряется в мкс или мс или чем-то еще. Оно реальное просто само по себе.

А вот период системного таймера ОС действительно измеряется в таких единицах, но скорее не в "мкс", а в "мс" :)

 

ОС не имеет никакого отношения к интерфейсам и чему-то там еще.

ОС - это просто программа, точнее - некая библиотека функций, которые вы подключаете к своему проекту.

Выбирайте любую, которая имеет 'порт" под выбранное семейство, изучайте ее функционал и пользуйтесь себе на здоровье ))

[haker_fox 61]

3 minutes ago, Forger said:

Реальное время не измеряется в мкс или мс или чем-то еще.

Здесь я подразумевал время отклика сервисов ОС на события, на прерывания. Кстати, я маленько загнул со 100 мкс. Это много. Наверно правильно сказать, как можно быстрее.

3 minutes ago, Forger said:

которая имеет 'порт" под выбранное семейство

Сам по себе порт не очень интересн, ещё интересны драйвера, стеки. @AlexandrY, как я сделал выводы, попробовал их в большом количестве)

[Forger 26]

7 minutes ago, haker_fox said:

Здесь я подразумевал время отклика сервисов ОС на события, на прерывания.

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

 

7 minutes ago, haker_fox said:

Кстати, я маленько загнул со 100 мкс. Это много. Наверно правильно сказать, как можно быстрее.

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

 

7 minutes ago, haker_fox said:

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

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

 

7 minutes ago, haker_fox said:

ещё интересны драйвера, стеки.

А при чем здесь ОС? Она в принципе не имеет отношения к этому.

Другое дело - комплект: ОС+стеки, то такие есть и micrium и во freertos и в той же RTX от Keil, да и в многих других.

 

[haker_fox 61]

3 minutes ago, Forger said:

то любой интерес к этой ОС на этом обычно сразу заканчивается

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

4 minutes ago, Forger said:

Она в принципе не имеет отношения к этому

Напрямую - никакого. Но я имел ввиду комплект. Тогда ос - уже вторичное. Т.е. она зависит от комплекта.

[jcxz 234]

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

А я один раз сделал, и применяю отлаженное решение из проекта в проект 

Вы сами себе противоречите. Сначала: "нет универсализации", затем: "одно решение из проекта в проект". 

Тогда что это если не универсализация? Или у вас все проекты одинаковые?   Видимо точно - пилите один и тот же проект всю карьеру.  

Для примера:

В одном проекте у меня на SPI-канале висит гроздь устройств, соответственно есть отдельно драйвер SPI-канала (арбитр транзакций) и набор работающих через него драйверов устройств (SPI-flash, SPI-FRAM, датчики, etc.). С регистрами IO SPI-периферии работает естественно SPI-драйвер. Дочерние драйверы работают через его API (выставляя флажки запросов обслуживания, которые SPI-драйвер обслуживает поддерживая сложную систему приоритетов).

В другом проекте на одном SPI-канале висит только одно устройство (SPI-flash), соответственно отдельного арбитра транзакций нет, и собственно драйвер SPI-flash является и драйвером SPI. И с регистрами SPI-периферии работает тоже он сам.

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

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

Ведь любой драйвер по сути - это набор функций. Дополнить недостающей - никаких проблем.

Уже существующие проекты от этого никак уже не изменятся даже после ребилда с новой версией библиотеки - ведь они не используют эти новые функции, линкер их туда не добавит :)

Не верю! Сказки рассказывайте новичкам. Любой, кто хоть когда-то занимался разработкой сложного ПО, знает что при добавлении нового функционала в существующее ПО, очень часто оказывается что необходимо что-то переделать в API, так как или новые фичи неудобно добавлять со старым API или просто - придумано лучшее решение чего-либо. И тогда придётся не только заново пересобирать все старые проекты, которые используют эту "либу", но и заново их отлаживать.

Например: в старой версии API были какие-то данные, для хранения которых хватало размера char, они и были сделаны типом char. Но потом захотелось добавить новые функции, но размера char уже маловато, приходится API переделывать под short. Только не надо рассказывать байки про то, что Вы "всё заранее предусматриваете". Никто даже семи пядей во лбу не сможет предусмотреть что может понадобиться завтра.

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

[Forger 26]

2 minutes ago, haker_fox said:

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

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

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

А если ОС полностью создана под CMSIS, и некий middleware тоже то их можно легко объединить друг с другом, даже если они от разных контор.

Но как правило, если есть middleware, то и соотв. ОС тоже есть.

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

 

[jcxz 234]

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

Здесь я подразумевал время отклика сервисов ОС на события, на прерывания. Кстати, я маленько загнул со 100 мкс. Это много. Наверно правильно сказать, как можно быстрее.

Нет ничего универсального "для всех проектов". Где-то времени реакции в 10 мс - за глаза, а где-то нужно 10 мкс или меньше.

[Forger 26]

19 minutes ago, jcxz said:

Вы сами себе противоречите. Сначала: "нет универсализации", затем: "одно решение из проекта в проект". 

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

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

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

 

ps

Вот не пойму, чего вы пытаетесь доказать?

Я выложил свое решение библиотеки для работы с периферией. Если не нравится, проходите мимо или уже если критикуйте, то, пожалуйста, предметно!