ВходНаше всё Теги codebook 无线电组件 Поиск Опросы Закон Воскресенье
22 декабря
1012909 Топик полностью
Связанные сообщения
Logger
[protodb] Protocol Debugger. Отладка и реверс-инжиниринг протоколов.2023-11-12
В плюсах можно сделать шикарнейший логгер. Во-первых не занимающий програмной памяти или памяти данных (оперирует адресами текст...2020-09-12
+1. Проблемы с детектированием наезда, на необработанные данные, обгона указателя чтения, можно решить, если использовать не ука...2020-05-17
Нормальный логгер, к сожалению, делается только на C++... На C сам язык начинает сильно мешать. Что потенциально можно было бы ...2019-12-11
Так рассуждать, труды автора fmtlib тоже не оправданы. Мол есть printf, он всё делает. Но это не так, очень даже оправданы. Там ...2019-11-13
Использование gdb для распечатки значений в контрольных точках. Демонстрация концепции по ссылке.2019-11-08
Помимо прочего при нормальном программировании всегда делается какой-то "логгер" ведущий протокол работы программы. Потому, что ...2019-08-10
fk0, легенда (18.06.2020 14:15, просмотров: 1219) ответил dxWAk на Используем ThreadX в составе платформы Renesas Synergy, для отладки есть TraceX,
Допустим, я хочу сделать в threadX логгер. Он будет писать в кольцевой буфер в памяти, из которого медленно и печально будет выпечатываться в компорт. Задача достаточно классическая. Логгировать одновременно могут все потоки. Как сделать кольцевой буфер -- понятно. В принципе он может быть реализован на lockless-алгоритмах, но.... Но поскольку компорт медленный, то буфер может быть в переполненном состоянии (регулярно), то потоки пытающиеся писать в лог должны ожидать 

освобождения места в буфере. Кроме того, буфер может быть пуст, и после помещения в него записи нужно стартовать процесс передачи в компорт. Итого, в общем случае, при записи в лог необходимо:


1) попытаться аллоцировать свободное место в буфере, если успешно -- шаг 3;

2) иначе ожидать увеличения объёма свободной памяти в буфере, потом шаг 1;

3) скопировать в буфер текст выводимый в логгер;

4) сигнализировать потоку, осуществляющему запись в компорт, о том чтоб буфер не пуст.


В потоке работающим с компортом необходимо:


5) ожидать пока буфер пуст;

6) ожидать пока FIFO-буфер компорта полон;

7) считать очередной байт из буфера и передать в компорт, переход на шаг 6 если вся запись не передана;

8) освободить место в буфере и сигнализировать ожидающим потокам о появлении дополнительной памяти.


Вроде просто? Вопрос на засыпку: через какой механизм синхронизации ThreadX можно выполнить шаги 2 и 8? Очевидно так же, что шаги 1 и 3 должны выполняться когда данные буфера защищены мьютексом, например.


Шаги 4 и 5, понятно, выполняются с помощью любого типа семафора.

[ZX]