-
- FreeRTOS имеет специальную функцию idle BlackMorda(1 знак., 13.08.2025 20:34, ссылка)
- Если я вас правильно понял, вы предлагаете реализовывать печать в
IDLE? Нет, у меня печать имеет самый высокий приоритет - она
короткая, быстрая, не сильно мешает. Быстрее, чем передаёт UART, не
нагрузится. Зато все отладочные сообщения, которые задачи только
смогли положить в буфер - гарантированно напечатаются в порядке
очереди поступления. - Nikolay_Po(Вчера, 13:36)
- Чтобы печатать в порядке очереди поступления есть более щадящие средства чем критическая секция. ЫЫyкпy(433 знак., Сегодня, 05:58)
- Да. - Nikolay_Po(13.08.2025 21:28)
- Если я вас правильно понял, вы предлагаете реализовывать печать в
IDLE? Нет, у меня печать имеет самый высокий приоритет - она
короткая, быстрая, не сильно мешает. Быстрее, чем передаёт UART, не
нагрузится. Зато все отладочные сообщения, которые задачи только
смогли положить в буфер - гарантированно напечатаются в порядке
очереди поступления. - Nikolay_Po(Вчера, 13:36)
- Зачем печатать из задач? Класть в задаче в оперативку нужное.
Завести задачу с самым низким приоритетом и печатать из неё? - jlm(13.08.2025 20:03)
- Я ниже так и предложил, сделать по аналогии с ОС Windows, у которой
1 принтер и куча приложений/задач, желающих на нём попечатать. - vpv.vpv(14.08.2025 07:16)
- Так и есть в данном случае, один принтер на всю систему, называется
printf() и, что может быть логичней, чем брать и печатать на него
из любого места. - petrd(14.08.2025 07:49)
- откройте из двух терминалов один порт - Vit(14.08.2025 08:49)
- Такое нельзя сделать. Но это не аналогия для данной ситуации. - petrd(14.08.2025 09:13)
- А я думаю - аналогия! Я бы сделал одну задачу-драйвер, для UART,
как для принтера. В нашем случае, последовательного. Внутри этой
задачи прерывания, DMA, монопольный (!) доступ к телу (железу) и
пр.. А все остальне задачи обращаются не к UART'у, а к
обслуживающей его задаче, вернего уровня приложений: "Не будет ли
так любезен Джинн вот это вот передать?". И ждать, когда
UART'овский Джин твой флажок сбросит, т.е. запрос будет обработан. - vpv.vpv(Вчера, 10:54)
- Следите! Уже сделано так. Все имеют доступ к printf(), внутри него,
когда сообщение готово, вызывается _write() в котором сообщение
отправляется в завернутый в критическую обертку StreamBufferSend().
В задаче из завернутого в критическую обертку StreamBufferRecieve()
это сообщение копируется, его длина и адрес передается в DMA, пуск
DMA, начинается транзакция в UART, задача ставится на ожидание,
пока от прерывания DMA не придет уведомление о завершении
транзакции. C приходом petrd(503 знак., Вчера, 11:47)
- Начало новой транзакции никак не мешает завершению передачи
предыдущего символа. Вы же, по опустошению буфера DMA, UART не
выключаете? Nikolay_Po(213 знак., Вчера, 12:59)
- Нет, конечно, ничего не выключаю. Похоже на воду дую ....
размышляю, пришло уведомление о завершении транзакции ДМА, а UART
еще передает, задача успела вытащить следующее сообщение, засунула
адрес и длину в ДМА, стартует, а от UART запроса к ДМА еще не
поступало, ну и, значит, стоп, ДМА ждет когда придет запрос от
него. - petrd(Вчера, 13:21)
- Поясню: DMA можно запускать при неготовности периферии. Всего делов-то - DMA будет стоять на первой транзакции, не выполняя её, сохраняя исходное значение счётчика транзакций. Как только ранее положенный в буфер самого UARTа символ протолкнётся в освободившийся сдвиговый регистр, сразу же, по флагу transmit empty, DMA положит первый символ следующей транзакции. Nikolay_Po(372 знак., Вчера, 13:34)
- Стоп DMA никак не влияет на передачу уже поступившего и переданного в свдиговый регистр символа. Так что не переживайте. - Nikolay_Po(Вчера, 13:26)
- Нет, конечно, ничего не выключаю. Похоже на воду дую ....
размышляю, пришло уведомление о завершении транзакции ДМА, а UART
еще передает, задача успела вытащить следующее сообщение, засунула
адрес и длину в ДМА, стартует, а от UART запроса к ДМА еще не
поступало, ну и, значит, стоп, ДМА ждет когда придет запрос от
него. - petrd(Вчера, 13:21)
- Начало новой транзакции никак не мешает завершению передачи
предыдущего символа. Вы же, по опустошению буфера DMA, UART не
выключаете? Nikolay_Po(213 знак., Вчера, 12:59)
- Изобретаем journald вместе. Люблю такое :) - Cкpипaч(Вчера, 10:55)
- Следите! Уже сделано так. Все имеют доступ к printf(), внутри него,
когда сообщение готово, вызывается _write() в котором сообщение
отправляется в завернутый в критическую обертку StreamBufferSend().
В задаче из завернутого в критическую обертку StreamBufferRecieve()
это сообщение копируется, его длина и адрес передается в DMA, пуск
DMA, начинается транзакция в UART, задача ставится на ожидание,
пока от прерывания DMA не придет уведомление о завершении
транзакции. C приходом petrd(503 знак., Вчера, 11:47)
- не нужно передёргивать с ситуациями. компорт компа это USART с
дополнительными сигналами. здесь же аж голый USART. можете
семафорить, можете ещё как лочить, но обеспечьте отсутствие одновременного доступа Vit(1 знак., 14.08.2025 09:57, ссылка)
- Обычно при попытке открыть во втором терминале порта, открытого в
первом терминале второй терминал будет ругаться. Что не так?
Отсутствие "одновременного" доступа к чему? К UART? Так он только с
каналом ДМА взаимодействует, больше ни с кем. А данные в ДМА
поставляет единственный приемник
xStreamBufferReceive(uart_tx_stream....) завернутый в критическую
секцию, в который данные шлет единственный передатчик
xStreamBufferSend( uart_tx_stream, .....) тоже завернутый в petrd(126 знак., 14.08.2025 10:38)
- не хотите понимать. во время передачи (пока речь о) в USART из
буфера, как с FIFO, так и с DMA, весь этот ресурс должен быть
заблокирован. дальше можно не развивать. кто-то блокирует
заворачиванием в критическую секцию. ТС пишет о дебаг-выхлопе из
тучи задач. хорошо хоть не из обработчиков прерываний. если ресурс
захвачен одной задачей, то в другой можно либо отказаться, либо
ждать освобождения ресурса, либо отправить в программное устройство
отложенной отправки в. когда Vit(62 знак., 14.08.2025 11:34)
- Хочу понимать! Но не все понятно. Вы говорите "во время передачи
(пока речь о) в USART из буфера, как с FIFO, так и с DMA, весь этот
ресурс должен быть заблокирован" о каком ресурсе? О ДМА? Он
заблокирован. Я не теоретически, а практический разговор веду в
железе, независимо от топикстартера. - petrd(14.08.2025 11:49)
- ваша аналогия насчёт принтера не учитывает наличие службы спулера
печати (в винде Print Spooler). да были prn и lptx, а с ними как-то
употреблялись copy/type/print, но уже давно перешли на
использование именно службы печати - Vit(14.08.2025 12:33)
- Хорошо, без аналогий. Цель, изо всех мест программы, где требуется
вывод, без оглядки на FreeRTOS, писать printf() и получать вывод в
терминале. Говорю исключительно про МК. - petrd(14.08.2025 15:26)
- никто не мешает так писать:). но есть нюансы. при использовании без вытеснения (в т.ч. всяких вызовов в обработчиках прерываний) нужно, чтобы уход последнего байта контроллировался по TXC (если RS485 - аналогично снятию DE). при использовании DMA это не всегда решаемо без дополнительных сложностей, потому как событие окончания отправки по DMA возникает чуть раньше факического ухода байта. потому возникают варианты с расчетными таймаутами и т.п.. при вытеснении же всё то же, Vit(503 знак., Вчера, 08:38)
- Хорошо, без аналогий. Цель, изо всех мест программы, где требуется
вывод, без оглядки на FreeRTOS, писать printf() и получать вывод в
терминале. Говорю исключительно про МК. - petrd(14.08.2025 15:26)
- ваша аналогия насчёт принтера не учитывает наличие службы спулера
печати (в винде Print Spooler). да были prn и lptx, а с ними как-то
употреблялись copy/type/print, но уже давно перешли на
использование именно службы печати - Vit(14.08.2025 12:33)
- Хочу понимать! Но не все понятно. Вы говорите "во время передачи
(пока речь о) в USART из буфера, как с FIFO, так и с DMA, весь этот
ресурс должен быть заблокирован" о каком ресурсе? О ДМА? Он
заблокирован. Я не теоретически, а практический разговор веду в
железе, независимо от топикстартера. - petrd(14.08.2025 11:49)
- не хотите понимать. во время передачи (пока речь о) в USART из
буфера, как с FIFO, так и с DMA, весь этот ресурс должен быть
заблокирован. дальше можно не развивать. кто-то блокирует
заворачиванием в критическую секцию. ТС пишет о дебаг-выхлопе из
тучи задач. хорошо хоть не из обработчиков прерываний. если ресурс
захвачен одной задачей, то в другой можно либо отказаться, либо
ждать освобождения ресурса, либо отправить в программное устройство
отложенной отправки в. когда Vit(62 знак., 14.08.2025 11:34)
- Обычно при попытке открыть во втором терминале порта, открытого в
первом терминале второй терминал будет ругаться. Что не так?
Отсутствие "одновременного" доступа к чему? К UART? Так он только с
каналом ДМА взаимодействует, больше ни с кем. А данные в ДМА
поставляет единственный приемник
xStreamBufferReceive(uart_tx_stream....) завернутый в критическую
секцию, в который данные шлет единственный передатчик
xStreamBufferSend( uart_tx_stream, .....) тоже завернутый в petrd(126 знак., 14.08.2025 10:38)
- А я думаю - аналогия! Я бы сделал одну задачу-драйвер, для UART,
как для принтера. В нашем случае, последовательного. Внутри этой
задачи прерывания, DMA, монопольный (!) доступ к телу (железу) и
пр.. А все остальне задачи обращаются не к UART'у, а к
обслуживающей его задаче, вернего уровня приложений: "Не будет ли
так любезен Джинн вот это вот передать?". И ждать, когда
UART'овский Джин твой флажок сбросит, т.е. запрос будет обработан. - vpv.vpv(Вчера, 10:54)
- Такое нельзя сделать. Но это не аналогия для данной ситуации. - petrd(14.08.2025 09:13)
- откройте из двух терминалов один порт - Vit(14.08.2025 08:49)
- Так и есть в данном случае, один принтер на всю систему, называется
printf() и, что может быть логичней, чем брать и печатать на него
из любого места. - petrd(14.08.2025 07:49)
- Я ниже так и предложил, сделать по аналогии с ОС Windows, у которой
1 принтер и куча приложений/задач, желающих на нём попечатать. - vpv.vpv(14.08.2025 07:16)
- Завёл тему на форуме FreeRTOS Nikolay_Po(1 знак., 13.08.2025 19:37, ссылка)
- Дошёл до того, что сделал пример, демонстрирующий проблему. Демонстрирует. Nikolay_Po(3623 знак., Вчера, 13:42, ссылка)
- Перечитайте еще раз документацию на xStreamBufferReceive() где
сразу же сверху написано NOTE: Судя по вашему коду выполянется
vTaskSuspendAll(), но это ничего не дает и не является
сериализацией доступа ("последовательнизацией" для записывающих
потоков). Судя по всему, xStreamBuffer не потокобезопасный и у вас
просто "ломается", приходит во внутреннее неконсистентное
состояние. И там же, прямо написано как нужно сделать чтобы он
работал нормально. "One way to achieve such EmbedProg(336 знак., 14.08.2025 04:47,
, ссылка)
- Есть и другое мнение: Nikolay_Po(851 знак., 14.08.2025 13:55, ссылка)
- Поскольку вы уже достаточно глубоко погрузились в проблему и обнаружили, что ваша задача пропадает из списка на пробуждение, наверное вам будет не сложно поставить точку останова на изменение ячейки памяти с вашей задачей в списке на пробуждение, обнаружить когда ее изменяют, т.е. убирают, и найти в чем причина. - AlexBi(14.08.2025 15:22)
- Есть и другое мнение: Nikolay_Po(851 знак., 14.08.2025 13:55, ссылка)
- Сделал такую штуку для наблюдения за состоянием задач. Можно заглядывать в TaskState и StackRemainder: Nikolay_Po(1080 знак., 13.08.2025 14:00, картинка, картинка)
- Сделать так, как это сделано в других ОС, в которых UART один, а пользовательских задач и желающих что-то на него вывести - много. Тот же Windows и принтер. :))) Зачем изобретать велосипед? - vpv.vpv(13.08.2025 06:45)
- А к железке могут "единомоментно" несколько тысяч клиентов
подсоединиться? Иначе не понимаю, зачем там вообще ртось! - Eddy_Em(12.08.2025 21:34)
- Эдуард, ты не делал такого для такого использования. А я - делал.
Чуть попроще, чем это, новое. И оно, без ОСРВ, работает "в поле". И
мне дают спать спокойно. Nikolay_Po(636 знак., 12.08.2025 22:06)
- Кооперативная многозадачность позволяет делать то же самое, только
там всё проще. Нет проблем с "реентерабельностью", синхронизацией
потоков. Да, нужно вставлять yield() в циклы длительных ожиданий,
но таких мест мало, это совсем не сложно. - SciFi(12.08.2025 22:21)
- Кооперативная многозадачность не позволяет блокировать
низкоприоритетные задачи в пользу высокоприоритетных. В простых
проектах так и делаю. Но в конкретном, суммарная нагрузка по
запросам внешних интерфейсов - непредсказуема. И будут расставлены
приоритеты. Потому нужна вытесняющая ОС. - Nikolay_Po(14.08.2025 09:30)
- это, IMNHO, натягивание совы на глобус. приоритеты задач должны
быть разными аж в "дешёвых" реализациях вытеснения. разделяемый
ресурс - бич ограниченности подхода. вместо демонов-спулеров опять
используется парадигма приоритетности как простейшего способа
решения, который к оптимальности имеет далёкое отношение. благо в
той же FreeRTOS можно от этой разноприоритетности задач отказаться
по сути (ну разве что idle ниже). приоритет доступа к ресурсу это
дисциплина конкретного Vit(1151 знак., 14.08.2025 11:16)
- Непонятно, что вы хотите сказать? В чём меня упрекаете (по тону)? Nikolay_Po(440 знак., 14.08.2025 13:49)
- вы заявили, что кооперативная многозадачность чего-то (рулить приоритетами) не может. не согласен, хотя действительно часто да - не может, ибо нет необходимости. далее приоритеты нужны для руления при повышенной загрузке - смешиваете приоритеты задач и приоритеты доступа к ресурсу, а заодно базовый вопрос время-память. считаю, что утверждение о том, что руление приоритетами задач решает вопрос руления приоритетами доступа к ресурсу, заблуждением. и вообще наличие разных Vit(885 знак., 14.08.2025 14:41)
- Непонятно, что вы хотите сказать? В чём меня упрекаете (по тону)? Nikolay_Po(440 знак., 14.08.2025 13:49)
- это, IMNHO, натягивание совы на глобус. приоритеты задач должны
быть разными аж в "дешёвых" реализациях вытеснения. разделяемый
ресурс - бич ограниченности подхода. вместо демонов-спулеров опять
используется парадигма приоритетности как простейшего способа
решения, который к оптимальности имеет далёкое отношение. благо в
той же FreeRTOS можно от этой разноприоритетности задач отказаться
по сути (ну разве что idle ниже). приоритет доступа к ресурсу это
дисциплина конкретного Vit(1151 знак., 14.08.2025 11:16)
- Кооперативная многозадачность не позволяет блокировать
низкоприоритетные задачи в пользу высокоприоритетных. В простых
проектах так и делаю. Но в конкретном, суммарная нагрузка по
запросам внешних интерфейсов - непредсказуема. И будут расставлены
приоритеты. Потому нужна вытесняющая ОС. - Nikolay_Po(14.08.2025 09:30)
- Можно было сэкономить время и деньги, элементарно добавив туда
одноплатник с полноценным линуксом в качестве сетевой компоненты (и
тех же threads). А на МК делать то, что не умеет одноплатник. Eddy_Em(88 знак., 12.08.2025 22:11)
- Вот как раз с такими я и конкурирую. - Nikolay_Po(12.08.2025 22:34)
- Бесполезно. У них значительно ниже будет себестоимость (если, конечно, это - не opensource). - Eddy_Em(12.08.2025 22:37)
- Вот как раз с такими я и конкурирую. - Nikolay_Po(12.08.2025 22:34)
- Кооперативная многозадачность позволяет делать то же самое, только
там всё проще. Нет проблем с "реентерабельностью", синхронизацией
потоков. Да, нужно вставлять yield() в циклы длительных ожиданий,
но таких мест мало, это совсем не сложно. - SciFi(12.08.2025 22:21)
- Без обид, это потому что ты - диллетант. - Cкpипaч(12.08.2025 21:48)
- Без обид, но дилетант - ты. Хотя бы за грамматические ошибки ☺ Eddy_Em(382 знак., 12.08.2025 22:09)
- И нихера он не понимает, за что баксы берутся. Безнадёжен. - Nikolay_Po(12.08.2025 22:36)
- Как-то слышал притчу о том что профессионал никогда не ставит перед
собой задачу "сделать". Только суммы и сроки. Cкpипaч(417 знак., 12.08.2025 22:56)
- Ты - менеджер. А Эдуард - исполнитель. Вы оба профессионалы, но каждый на своём уровне бытия. - Бoмж(13.08.2025 12:30)
- Возможно, это одна из причин, почему ИТЭР никогда не сделает
термояд. Собрали в одном месте 1000 Эдуардов, они сделали 1000
прикольных штук. А термояд никому из них не нужен :-) - SciFi(13.08.2025 08:07)
- Одна из. - Kpoк(13.08.2025 23:35)
- Думаю что если "тысячу эдуардов" распылить по индустрии то вреда было бы куда больше. Да и присматривать за ними легче, чтобы "антиграв не зарисёчили" в чьи-то не те руки. - Cкpипaч(13.08.2025 08:30)
- Баксы берутся "за понты". Крайне редко - за надежность. Но "ПЛК" -
это просто трындец! Комплектуха там в основном - ширпотребное
говно. А прошивка - еще хуже. В общем, "ПЛК" я считаю таким же
злом, как и маздай. - Eddy_Em(12.08.2025 22:38)
- Я - счасливчик. Я могу среди белого дня созвониться и сьездить к авторам применяемых мной ПЛК прямо в лабораторию. Cкpипaч(139 знак., 12.08.2025 22:51)
- В каждой избушке свои погремушки :-) - SciFi(12.08.2025 22:40)
- Как-то слышал притчу о том что профессионал никогда не ставит перед
собой задачу "сделать". Только суммы и сроки. Cкpипaч(417 знак., 12.08.2025 22:56)
- И нихера он не понимает, за что баксы берутся. Безнадёжен. - Nikolay_Po(12.08.2025 22:36)
- Без обид, но дилетант - ты. Хотя бы за грамматические ошибки ☺ Eddy_Em(382 знак., 12.08.2025 22:09)
- Эдуард, ты не делал такого для такого использования. А я - делал.
Чуть попроще, чем это, новое. И оно, без ОСРВ, работает "в поле". И
мне дают спать спокойно. Nikolay_Po(636 знак., 12.08.2025 22:06)
- как вариант реализации, можно и на статическом буфере petrd(1218 знак., 12.08.2025 08:25)
- Это для какой ОС? Попробовал потоковый буфер. Nikolay_Po(1528 знак., 12.08.2025 19:00)
- FreeRTOS - petrd(12.08.2025 20:21)
- Из современного описания стримбуфера, ясно, что он, внутри,
передаёт уведомление получателю данных, без уведомлений вручную, не
как у вас в примере. Nikolay_Po(610 знак., 12.08.2025 21:08, ссылка, ссылка)
- В общем, зашёл на я на форум FreeRTOS. Авторизовался ГитХабом. Думаю, щас напишу вопрос. Открываю темы, открываю про ядро. И тут бац: прямо моя проблема: Nikolay_Po(73 знак., 13.08.2025 10:37, ссылка)
- Не спорю, возможно лишнее, разберусь чуть потом. Работает, проблем
не наблюдаю. - petrd(12.08.2025 21:58)
- А я вот, репу чешу. У меня не работает. - Nikolay_Po(12.08.2025 22:08)
- Из современного описания стримбуфера, ясно, что он, внутри,
передаёт уведомление получателю данных, без уведомлений вручную, не
как у вас в примере. Nikolay_Po(610 знак., 12.08.2025 21:08, ссылка, ссылка)
- FreeRTOS - petrd(12.08.2025 20:21)
- Я пока не использовал потокового буфера. Зачем делается отдельное уведомление задачи о приходе данных в буфер? Nikolay_Po(380 знак., 12.08.2025 08:47)
- Это для какой ОС? Попробовал потоковый буфер. Nikolay_Po(1528 знак., 12.08.2025 19:00)
- IMNHO, отжимать ресурс с монопольным доступом для какой-то отладки
это жЫрный моветон. неявное выделение памяти и неопределенность
аппетитов потребителей могут накрыть медным тазом любое разумное
начинание. припоминается форк-бомба. ну и зачем-то появился
vfprintf, кто-то когда-то использовал имена устройств вывода, а не
только стандартные потоки или файлы, явно. в том же фортране
форматрованный вывод можно было не только на терминал пользователя
запустить, но и на Vit(1497 знак., 12.08.2025 02:36)
- Как мне кажется, SWO не относится к быстрым механизмам. По сути это
тот же UART, пусть высокочастотный, но без ДМА и прерываний, т.е.
побайтовый вывод с ожиданием готовности в бесконечном цикле. RTT -
это быстро, но требует JLINK, подходит только для м/к, чье
отладочное ядро умеет читать-писать память без остановки
процессора, выхлоп RTT идет на сеггеровский терминал, т.е. добавить
свой анализатор вывода не просто. В современных м/к достаточно
много UART и DMA, мне пока не AlexBi(286 знак., 12.08.2025 09:18)
- Rtt работает и на st-link и на openocd. И выхлоп идет в телнет так
что парси сколько унодно. Главное ограничение в том что младшие
кортексы идут лесом из за невозможности чтения памяти в фоне - 3m_в_мeтpo(12.08.2025 09:58,
)
- У моего целевого МК, CH32V317, SDI. И оно может передавать данные только в режиме опроса. - Nikolay_Po(12.08.2025 10:03)
- Rtt работает и на st-link и на openocd. И выхлоп идет в телнет так
что парси сколько унодно. Главное ограничение в том что младшие
кортексы идут лесом из за невозможности чтения памяти в фоне - 3m_в_мeтpo(12.08.2025 09:58,
- Спасибо за мнение. Отладка у меня останется и в релизе. Оставлю
гребёнку с Rx/Tx UARTa - типа порта консоли. Компортов в МК у меня
штук шесть. Из них для работы требуется два-три. Так что выделение
ресурса для отладки - дело осознанное и умышленное. Nikolay_Po(95 знак., 12.08.2025 08:07)
- при отсутствии сборщика мусора эффективность динамической аллокации
может сильно зависеть от реализации. по FreeRTOS вопросы аллокации
и "черных ящиков" немного-таки беспокоят --> Vit(197 знак., 12.08.2025 13:36, ссылка, ссылка)
- >10лет использую связку tlsf + freertos, к аллокации вопросов
нет, есть устройства с аптаймом больше года, выделяю не только в
статике, но и постоянно в динамике. - Oman(12.08.2025 17:13)
- Использую связку tlsf + scmRTOS. На столько больших известных мне
аптаймов таких нет, но полет нормальный. Необходимо было заменить
встроенные функции выделения памяти на свои, чтобы предотвратить
одновременное обращение к ним нескольких процессов. - AlexG(12.08.2025 18:08)
- постарались, не перегрузили. прекрасно. - Vit(13.08.2025 07:40)
- да, семафор там повесить надо, но там прямо без выдумок все - Oman(12.08.2025 20:57)
- Угу. Спасибо. - Nikolay_Po(12.08.2025 17:47)
- Использую связку tlsf + scmRTOS. На столько больших известных мне
аптаймов таких нет, но полет нормальный. Необходимо было заменить
встроенные функции выделения памяти на свои, чтобы предотвратить
одновременное обращение к ним нескольких процессов. - AlexG(12.08.2025 18:08)
- Не знаю, что там имеется в виду под недертерминированностью. Но думаю это не относится к thread save. Функции pvPortMalloc и pvPortFree выключают планировщик на время выделения и освобождения памяти и ничего плохого в смысле thread save не может произойти. Там прямо написано: The wrapper simply makes the malloc() and free() functions thread safe. - mmc(12.08.2025 14:34)
- Хм. Первые две ссылки браузер помечает как уже посещённые мной :).
Где возможно - использую статик. Что-то простое и уже готовое,
отлаженное - если динамическое - пусть будет как есть. - Nikolay_Po(12.08.2025 14:18)
- printf из newlib как бы предполагает использование malloc - Vit(12.08.2025 15:43)
- Ну и пусть. К самому newlib-овскому printf-у у меня претензий нет. - Nikolay_Po(12.08.2025 16:38)
- у меня к старому были. и к варианту из nano. - Vit(13.08.2025 07:46)
- Ну и пусть. К самому newlib-овскому printf-у у меня претензий нет. - Nikolay_Po(12.08.2025 16:38)
- printf из newlib как бы предполагает использование malloc - Vit(12.08.2025 15:43)
- >10лет использую связку tlsf + freertos, к аллокации вопросов
нет, есть устройства с аптаймом больше года, выделяю не только в
статике, но и постоянно в динамике. - Oman(12.08.2025 17:13)
- Кстати, если вывод диагностики - по сути часть нормального функционала устройства, то к проектированию этой функции так и следует подходить - с той же тщательностью, что и у других функций. Потому что обычно отладочный выхлоп - это что-то слепленное на скорую руку: "по-быстрому вставлю printf тут и там, всё равно в релизе этого не будет". - SciFi(12.08.2025 08:57)
- при отсутствии сборщика мусора эффективность динамической аллокации
может сильно зависеть от реализации. по FreeRTOS вопросы аллокации
и "черных ящиков" немного-таки беспокоят --> Vit(197 знак., 12.08.2025 13:36, ссылка, ссылка)
- Как мне кажется, SWO не относится к быстрым механизмам. По сути это
тот же UART, пусть высокочастотный, но без ДМА и прерываний, т.е.
побайтовый вывод с ожиданием готовности в бесконечном цикле. RTT -
это быстро, но требует JLINK, подходит только для м/к, чье
отладочное ядро умеет читать-писать память без остановки
процессора, выхлоп RTT идет на сеггеровский терминал, т.е. добавить
свой анализатор вывода не просто. В современных м/к достаточно
много UART и DMA, мне пока не AlexBi(286 знак., 12.08.2025 09:18)
- [off] Eddy_Em(251 знак., 11.08.2025 23:10)
- Это потому, что тебе не нужно делать непонятно что к заданному сроку. А мне - нужно. И нужно быть готовым передать разработку для дальнейшей работы другому программисту. В этом смысле, использование ОСРВ - кайф. Задачи изолированы, синхронизируются через готовые механизмы ОС явным образом. - Nikolay_Po(11.08.2025 23:45)
- Я бы сделал так. Сделал задачу (поток) для передачи через UART.
Ссылки на данные и их размер передавал бы в этот поток из других
потоков. - mmc(11.08.2025 21:47)
- Это больше похоже на "закат солнца вручную". В том же TCP-IP
расширении для FreeRTOS, активно используется макрос вывода вида: Nikolay_Po(461 знак., 11.08.2025 22:09, ссылка, ссылка)
- Вместо библиотечного printf я использую xprintf (легко гуглится).
Он занимает меньше места, чем библиотечный. В IAR линковщик сам не
включает функцию, если она не встречается в исходнике. - mmc(11.08.2025 22:52)
- Гляну при случае. Вопрос - оно "потокобезопасно"? LTO у GCC не
только не включает не используемые функции, но и переиспользует
одинаковые фрагменты разных функций, в зависимости от стратегии
оптимизации. - Nikolay_Po(11.08.2025 23:43)
- Я использую функцию из xprintf для вывода лога из разных потоков в
проекте с scmRTOS в качестве ОС. На scmRTOS перешел с FreeRTOS
из-за жесткого дефицита места в флэше. Поэтому оптимизация по
размеру включена на максимум. С проблемами не сталкивался. Функции
из xprintf заняли 544 байта. Аналогичная функция из SEGGER_RTT
занимает около 1.5 килобайта. mmc(339 знак., 12.08.2025 00:44)
- Спасибо за отзыв о системах и за пояснение. Nikolay_Po(248 знак., 12.08.2025 01:11)
- Я использую функцию из xprintf для вывода лога из разных потоков в
проекте с scmRTOS в качестве ОС. На scmRTOS перешел с FreeRTOS
из-за жесткого дефицита места в флэше. Поэтому оптимизация по
размеру включена на максимум. С проблемами не сталкивался. Функции
из xprintf заняли 544 байта. Аналогичная функция из SEGGER_RTT
занимает около 1.5 килобайта. mmc(339 знак., 12.08.2025 00:44)
- Гляну при случае. Вопрос - оно "потокобезопасно"? LTO у GCC не
только не включает не используемые функции, но и переиспользует
одинаковые фрагменты разных функций, в зависимости от стратегии
оптимизации. - Nikolay_Po(11.08.2025 23:43)
- Вместо библиотечного printf я использую xprintf (легко гуглится).
Он занимает меньше места, чем библиотечный. В IAR линковщик сам не
включает функцию, если она не встречается в исходнике. - mmc(11.08.2025 22:52)
- Это больше похоже на "закат солнца вручную". В том же TCP-IP
расширении для FreeRTOS, активно используется макрос вывода вида: Nikolay_Po(461 знак., 11.08.2025 22:09, ссылка, ссылка)
- Стек раздуветься из за глубоко вложенных функций и локальных
переменных. Надо поискать есть ли аллокация локальных буферов и
перенести в кучу или аллоцировать глобально. - framer_bum(11.08.2025 21:43,
)
- Увы. Речь идёт о строке printf("task1_task\n"); Никаких переменных
в задаче, кроме внутри printf(). Nikolay_Po(305 знак., 11.08.2025 21:55)
- А сколько стека выделяете для task1_task? И сколько в
configTOTAL_HEAP_SIZE ? - framer(11.08.2025 22:14)
- Пока не знаю где посмотреть. Зато знаю что в конфиге ОС,
configUSE_NEWLIB_REENTRANT = 1, правда, пока не знаю, что оно
делает и зачем. - Nikolay_Po(11.08.2025 22:28)
- Да вот это скорей всего и жрало стек. framer(518 знак., 11.08.2025 22:43, ссылка)
- Спасибо! Мне спокойнее, когда есть объяснение (и оно похоже на правду). - Nikolay_Po(11.08.2025 22:47)
- Да вот это скорей всего и жрало стек. framer(518 знак., 11.08.2025 22:43, ссылка)
- Пока не знаю где посмотреть. Зато знаю что в конфиге ОС,
configUSE_NEWLIB_REENTRANT = 1, правда, пока не знаю, что оно
делает и зачем. - Nikolay_Po(11.08.2025 22:28)
- А сколько стека выделяете для task1_task? И сколько в
configTOTAL_HEAP_SIZE ? - framer(11.08.2025 22:14)
- И еще можно мониторить стек uxTaskGetStackHighWaterMark(). - framer(11.08.2025 21:46)
- Спасибо. Но сначала нужно добиться, чтобы работало. А потом буду смотреть сколько надо стека этой функцией. - Nikolay_Po(11.08.2025 21:56)
- Увы. Речь идёт о строке printf("task1_task\n"); Никаких переменных
в задаче, кроме внутри printf(). Nikolay_Po(305 знак., 11.08.2025 21:55)
- FreeRTOS имеет специальную функцию idle BlackMorda(1 знак., 13.08.2025 20:34, ссылка)