- Пользуйся:2020-06-11
- Есть ли "нормальный mutex" в IAR ARM ?2020-06-09
-
- ChibiOS посмотрите. Мелкая и удобная. antm(202 знак., 18.06.2020 20:39, ссылка)
- я FreeRTOS использую, ключевое приемущество - чето не нравится -
взял и переписал или доделал. на заре пользовал ThreadX. когда
памяти больше чем нужно и процессор быстрее чем быстро - то
экономия в разработке есть - велосипед писать не нужно. - klen(18.06.2020 19:32)
- Я ее немного использую - пока в академических целях - OlegPowerC(19.06.2020 13:32)
- Используем ThreadX в составе платформы Renesas Synergy, для отладки
есть TraceX, dxWAk(240 знак., 18.06.2020 13:55, картинка)
- Да, интересно, а насколько легковесны такие вызовы (в тактах, например): fk0легенда(294 знак., 18.06.2020 15:47)
- Допустим, я хочу сделать в threadX логгер. Он будет писать в
кольцевой буфер в памяти, из которого медленно и печально будет
выпечатываться в компорт. Задача достаточно классическая.
Логгировать одновременно могут все потоки. Как сделать кольцевой
буфер -- понятно. В принципе он может быть реализован на
lockless-алгоритмах, но.... Но поскольку компорт медленный, то
буфер может быть в переполненном состоянии (регулярно), то потоки
пытающиеся писать в лог должны ожидать fk0легенда(1061 знак., 18.06.2020 14:15)
- Я бы использовал очередь, в потоке, который логирует ошибку dxWAk(447 знак., 18.06.2020 15:05, картинка)
- Собственно и вопрос-то в том как сделать самодельную очередь. Потому, например, что готовая очередь может по каким-то причинам не подходить. Например, работает только с сообщениями фиксированного размера. Да, можно пересылать указатели на сообщения, но тогда на каждое нужно выделять память. Кроме того, если очередь реализована, условно, через системный вызов -- то работа с такой очередью становится очень тяжёлой, по сравнению с другими примитивами синхронизации, которые по fk0легенда(213 знак., 18.06.2020 15:13)
- я не знаю за threadX но на тнео, фриртос итд так. abivan(788 знак., 18.06.2020 15:02)
- Тут есть принципиальная проблема, даже две, на шагах 2 и 8: ожидать
факта освобождения памяти в буфере может одновременно *несколько*
потоков. Пробудить ты должен один или все -- зависит от
стратегии... И одновременно с пробуждением поток должен захватить
мьютекс для операций с буфером. Кольцевой буфер существует как раз
чтоб предельно ускорить и упростить аллокацию -- других аллокаций
не нужно. Ну и раз ты использовал готовую очередь, то к чему тогда
вообще буфер? - fk0легенда(18.06.2020 15:20)
- пробуждать поток будет ось в зависимости от приоритета. мьютекс мне не нужен, ос очередью рулит. abivan(254 знак., 18.06.2020 15:54)
- Тут есть принципиальная проблема, даже две, на шагах 2 и 8: ожидать
факта освобождения памяти в буфере может одновременно *несколько*
потоков. Пробудить ты должен один или все -- зависит от
стратегии... И одновременно с пробуждением поток должен захватить
мьютекс для операций с буфером. Кольцевой буфер существует как раз
чтоб предельно ускорить и упростить аллокацию -- других аллокаций
не нужно. Ну и раз ты использовал готовую очередь, то к чему тогда
вообще буфер? - fk0легенда(18.06.2020 15:20)
- Бинарный семафор. Самый приоритетный из ожидающих проснется,
заберет семафор, проверит место. Если места достаточно - отправит
данные. Если недостаточно - снова встанет на этом же самом
семафоре. - LightElf(18.06.2020 15:01)
- A остальные что, будут вечно спать? Я забыл уточнить, но записи в
буфере не фиксированного размера (логгер -- текстовые строчки,
вроде очевидно). Да и посылаются в компорт может быть не по одной.
Вместо одной ушедшей можно 5 новых записать, и наоборот. Будить
нужно всех ожидающих. И потом, между моментом проверки (нет места)
и засыпанием на семафоре запросто могло появиться свободное место.
И наоборот, после получения сигнала семафора другой поток мог
занять всё своими fk0легенда(343 знак., 18.06.2020 15:41)
- У тебя привычка обобщать все по самое некуда :) И в этом самом
некуда - находить неразрешимые проблемы. Не бывает единого драйвера
под разные OS и радикально разное железо. LightElf(1187 знак., 18.06.2020 22:49)
- Я не обобщаю, я подвожу к сложности реализации такой элементарной
сущности как условная переменная. Без которой нормально задачу не
решить. Да, её можно построить на базе пары семафоров, причём один
нужен в TLS (а в ThreadX есть TLS?), или можно сделать как в SDL,
по семафору на каждого ждуна (что реально плохо выглядит когда их
много -- я уже как-то писал про это). В данной задаче можно
схалявить и сделать недоделку (не являющуюся полноценной условной
переменной, но fk0легенда(6968 знак., 19.06.2020 00:55, ссылка)
- Ну вот опять
за рыбу деньгипопытка найти единое универсальное решение. Первое, что стоит сказать - на мелких процессорах системный вызов, как правило, легкий по тактам. Второе, чаще всего есть возможность просто и дешево сделать короткую критическую секцию, например запретив прерывания. Третье, там обычно нет SMP. Все это меняет развесовку описанных тобою проблем. LightElf(948 знак., 19.06.2020 02:13)- А какое должно быть решение? Можно подумать, что какие-то
фундаментальные принципы в "computer science" чем-то отличны в
зависимости от фирмы выпустившей микропроцессор. Может и не UART
вовсе, а TCP/IP, и не микроконтроллер, а Core I9. Суть от этого не
меняется. А ты хочешь сказать, мол в зависимости от того какой
глубины UART в МК всё кардинально меняется... На верхнем уровне
абстракции ничего о реализации нижнего знать не положено. Принято,
что есть некий метод write, fk0легенда(1601 знак., 19.06.2020 02:49)
- Ну вот есть у тебя абстракция write, пользуй ее и не ломай голову
как она внутри устроена. Конкретная реализация write будет зависеть
от OS, а конкретная реализация драйвера UART - от конкретного
железа. А если не UART, а Ethernet - там будут другие реализации и
другие драйвера. Будет ли там условная переменная, два семафора или
отдельный сопроцессор с блекджеком и программистками - это вопрос
конкретной реализации, а не фундаментальных принципов. LightElf(2323 знак., 19.06.2020 12:42)
- В таком варианте вместо запрета прерываний следует использовать
мьютекс -- они для этого и существуют. Причём мьютексов связанных с
разными и независимыми защищаемыми наборами данных может быть
много, а флаг прерываний -- один всего. Мьютекс более эффективен.
Более того, запрещать прерывания более чем несколько тактов --
дичь! Вопрос же не как критическую секцию сделать, а как сделать
атомик (на основе которого уже можно сделать тот же мьютекс или
критическую секцию). fk0легенда(2371 знак., 19.06.2020 15:27)
- Ну так никто не запрещает реализовать атомик через запрет прерывания, если подходящих инструкций процессору не завезли. Получатся как раз те самые несколько тактов. В FreeRTOS-е можно блокироваться из критической секции, система отслеживает такую ситуацию. - LightElf(23.06.2020 16:32)
- Ввиду не установки драйвера rookie.sys на сервере сахары пост
читать можно только кликнув на него... - fk0легенда(19.06.2020 15:30)
- Имеешь в виду, что кнопочка "развернуть [под]ветку" не работает? У меня на старом FF 52 - тоже не работает. - Toчкa oпopы(19.06.2020 16:35)
- В таком варианте вместо запрета прерываний следует использовать
мьютекс -- они для этого и существуют. Причём мьютексов связанных с
разными и независимыми защищаемыми наборами данных может быть
много, а флаг прерываний -- один всего. Мьютекс более эффективен.
Более того, запрещать прерывания более чем несколько тактов --
дичь! Вопрос же не как критическую секцию сделать, а как сделать
атомик (на основе которого уже можно сделать тот же мьютекс или
критическую секцию). fk0легенда(2371 знак., 19.06.2020 15:27)
- Интересно, если использовать язык Rust, эти проблемы останутся? =AK=(58 знак., 19.06.2020 12:41)
- Ну вот есть у тебя абстракция write, пользуй ее и не ломай голову
как она внутри устроена. Конкретная реализация write будет зависеть
от OS, а конкретная реализация драйвера UART - от конкретного
железа. А если не UART, а Ethernet - там будут другие реализации и
другие драйвера. Будет ли там условная переменная, два семафора или
отдельный сопроцессор с блекджеком и программистками - это вопрос
конкретной реализации, а не фундаментальных принципов. LightElf(2323 знак., 19.06.2020 12:42)
- А какое должно быть решение? Можно подумать, что какие-то
фундаментальные принципы в "computer science" чем-то отличны в
зависимости от фирмы выпустившей микропроцессор. Может и не UART
вовсе, а TCP/IP, и не микроконтроллер, а Core I9. Суть от этого не
меняется. А ты хочешь сказать, мол в зависимости от того какой
глубины UART в МК всё кардинально меняется... На верхнем уровне
абстракции ничего о реализации нижнего знать не положено. Принято,
что есть некий метод write, fk0легенда(1601 знак., 19.06.2020 02:49)
- Ну вот опять
- Я не обобщаю, я подвожу к сложности реализации такой элементарной
сущности как условная переменная. Без которой нормально задачу не
решить. Да, её можно построить на базе пары семафоров, причём один
нужен в TLS (а в ThreadX есть TLS?), или можно сделать как в SDL,
по семафору на каждого ждуна (что реально плохо выглядит когда их
много -- я уже как-то писал про это). В данной задаче можно
схалявить и сделать недоделку (не являющуюся полноценной условной
переменной, но fk0легенда(6968 знак., 19.06.2020 00:55, ссылка)
- У тебя привычка обобщать все по самое некуда :) И в этом самом
некуда - находить неразрешимые проблемы. Не бывает единого драйвера
под разные OS и радикально разное железо. LightElf(1187 знак., 18.06.2020 22:49)
- A остальные что, будут вечно спать? Я забыл уточнить, но записи в
буфере не фиксированного размера (логгер -- текстовые строчки,
вроде очевидно). Да и посылаются в компорт может быть не по одной.
Вместо одной ушедшей можно 5 новых записать, и наоборот. Будить
нужно всех ожидающих. И потом, между моментом проверки (нет места)
и засыпанием на семафоре запросто могло появиться свободное место.
И наоборот, после получения сигнала семафора другой поток мог
занять всё своими fk0легенда(343 знак., 18.06.2020 15:41)
- Я бы использовал очередь, в потоке, который логирует ошибку dxWAk(447 знак., 18.06.2020 15:05, картинка)
- "времянки, логи, состояние" можно смотреть через J-Scope - BlackMordaмудак(18.06.2020 12:58)
- С каким JLink'ом ты его юзаешь? - RxTx(18.06.2020 13:35)
- Не знаю. У меня зоопарк. По моему 9-ой версии. Самый слабый дает
срез 50Гц. - BlackMordaмудак(18.06.2020 19:18)
- У меня зоопарка Jlink'ов нет, потому что ежели фирменные, то как-то
дороговато. Взял недавно фирменный JLink EDU 10, так у него как-то
подозрительно медленный обмен JlinkDCC, даже печатать с нормальной
скоростью не может, такое впечатление что по UART 9600 передаю.
Выяснение отчего так свелось к тому что сам JLink забирает
медленно. - RxTx(19.06.2020 00:12)
- Самый простой дает выборку 50Гц. У меня фирменный очень старый,
только JTAG. BlackMordaмудак(86 знак., 19.06.2020 13:15, ссылка)
- Спасибо тебе. Да, у меня есть STLink, я им пользуюсь тоже в режиме SWO (trace, ITM_* функции итд). - RxTx(23.06.2020 20:51)
- Самый простой дает выборку 50Гц. У меня фирменный очень старый,
только JTAG. BlackMordaмудак(86 знак., 19.06.2020 13:15, ссылка)
- У меня зоопарка Jlink'ов нет, потому что ежели фирменные, то как-то
дороговато. Взял недавно фирменный JLink EDU 10, так у него как-то
подозрительно медленный обмен JlinkDCC, даже печатать с нормальной
скоростью не может, такое впечатление что по UART 9600 передаю.
Выяснение отчего так свелось к тому что сам JLink забирает
медленно. - RxTx(19.06.2020 00:12)
- Не знаю. У меня зоопарк. По моему 9-ой версии. Самый слабый дает
срез 50Гц. - BlackMordaмудак(18.06.2020 19:18)
- С каким JLink'ом ты его юзаешь? - RxTx(18.06.2020 13:35)
- Ага. А с чего будет снижение затрат-то? На борьбу с ОСью не будет
не потрачено ничего, особенно на синхронизацию? В одном большом
проекте половина багов -- синхронизация (дедлоки, data race и т.п.)
А у тебя Valgrind (DRD, Hellgrind) не будет. Ты ж про
"синтетический порт" на ПК и слышать небось не хочешь. Мол одной
левой и так отладим. Основной функцией ОС является распрделение
ресурсов вычислительной системы. И она нужна, если ты это руками
сделать не можешь. И в fk0легенда(2533 знак., 18.06.2020 11:00)
- С многопоточностью и синхронизацией у меня ок из-за того что до
этого на PC я делал несколько многопоточных и многопроцессных втч
network проектов, как либ, так и серваков или там GUI приблуд. Так
что этого я не боюсь. Про RTOS я подумываю не потому что мне нужна
вытесняющая многозадачность. Как раз нет, RxTx(1898 знак., 19.06.2020 00:17, ссылка, ссылка)
- Да, трассировка выглядит интересно. А физически, внутри-то как
сделано? Как программа понимает, что вот-это нужно в трассировку
отправить? Макросы какие-то специальные, функции? А физически
внутри оно как упаковывается и отсылается? Т.е. там какой-то
бинарный формат сообщений типа ключ-значение, где ключ -- номер
точки трассировки, где на ПК она получает имя, ссылку на строку
программы и т.п.? - fk0легенда(19.06.2020 01:02)
- Ты про P7/байкал? В своем коде руками везде прописываешь (я обычно на той же строке trailing' (справа) кодом, плюс свои макро наколхозил + цвет в IDE). Да, бинарный формат ключ значение, автором приняты шаги по оптимизации и компрессии. Ты качни либу, она с сорцами жеж и унутре PDF, почитай. Поэкспериментируй, там пара экзамплов с либой идет. Конечно стиль нейминга в коде у него... но на вкус и цвет товарища нет. На PC он полагается на RDTSC таймстамп, поэтому имеет точность RxTx(312 знак., 19.06.2020 01:22)
- Про графики и логгер -- логи должны парситься на ПЦ (конечными
автоматами в скрипте на awk/perl/tcl/python...) и там рисоваться
как угодно. Для этого уж точно не RTOS нужна. - fk0легенда(19.06.2020 00:58)
- Парсится/рисоваться да. А остальное хочется икаропки. В мои годы запал юности "А НАПИШУ-КА Я ВСЁ САМ!!" че-то уже прошел... Мне надо решить основную задачу автоматического управления системы, самонаведения. Писать и отлаживать LowLevel (файловые системы, сеть, коммуникацию ,протоколы) и проч. нет месяцев на это. - RxTx(19.06.2020 01:40)
- Да, трассировка выглядит интересно. А физически, внутри-то как
сделано? Как программа понимает, что вот-это нужно в трассировку
отправить? Макросы какие-то специальные, функции? А физически
внутри оно как упаковывается и отсылается? Т.е. там какой-то
бинарный формат сообщений типа ключ-значение, где ключ -- номер
точки трассировки, где на ПК она получает имя, ссылку на строку
программы и т.п.? - fk0легенда(19.06.2020 01:02)
- Можно использовать ADA с рантаймом Ranvenscar - там есть задачи - OlegPowerC(18.06.2020 14:28)
- Если ресурсов немеряно, задача распределения ресурсов решается проще. Приходишь на склад - а там столько, что не унести. А достоинства RTOS никуда не делись - пишешь потоки и ффсе. Нужно просто подобрать удобные потоки под RTOS, а все, требующее сложной синхронизации сделать ручками. - VLLV(18.06.2020 13:16)
- Полагаю, что готовые библиотеки работы с Ethernet и выше
(WEB-сервер, SSL, что там еще понадобиться может) они требуют ОС.
Их использование, вместо изобретения велосипеда, это снижение
затрат. В остальном согласен, скорее всего ОС там не поможет. - AlexBi(18.06.2020 12:39)
- FNET прекрасно работает с сокетами, SSL, WEB-серверами и чертом
лысым - без всякой OS. И вообще - много их, IP стеков, хороших и
разных. На любой вид, цвет, вкус и кошелек. Поиск по форуму даст
полдюжины бесплатных вариантов. - LightElf(18.06.2020 23:07)
- А можешь список дополнить? - fk0легенда(19.06.2020 01:04, ссылка)
- LwIP оська не особо нужна, если сокетами не пользоваться - evgeniy1294(18.06.2020 15:04)
- FNET прекрасно работает с сокетами, SSL, WEB-серверами и чертом
лысым - без всякой OS. И вообще - много их, IP стеков, хороших и
разных. На любой вид, цвет, вкус и кошелек. Поиск по форуму даст
полдюжины бесплатных вариантов. - LightElf(18.06.2020 23:07)
- +1 - evgeniy1294(18.06.2020 11:07)
- С многопоточностью и синхронизацией у меня ок из-за того что до
этого на PC я делал несколько многопоточных и многопроцессных втч
network проектов, как либ, так и серваков или там GUI приблуд. Так
что этого я не боюсь. Про RTOS я подумываю не потому что мне нужна
вытесняющая многозадачность. Как раз нет, RxTx(1898 знак., 19.06.2020 00:17, ссылка, ссылка)