Помогите разобраться с PRINTF, Большой обьем выводимой информации - 5К Опции

[Эдди]

printf использует библиотека MBEDTLS, нужен форматирванный вывод.

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

[x893]

printf использует библиотека MBEDTLS, нужен форматирванный вывод.

Суть во всем это одна -



Я так и делал, но другим способом - наблюдая за головой и хвостом.

В данном случае это ПОКА неприемлимо. Сервер выкидывает HandShake, следом сертификаты. Так вот. С выводом debug информации не получается успевать декодировать первое сообщение - его затирает втрое.

Для этого люди придумали блокирующий и неблокирующий вывод.
Ещё есть вывод через RTT (тоже нескольких типов).
Вы уж определитесь, что Вам нужно, а потом можно код строчить.

[jcxz]

За пару милисекунд проц настрочил 5кб текста и выплюнул все это в кольцевой буфер. А с одним байтом будет еще прикольнее. Наверно только первый байт от 5кб и попадет в терминал. Мож и не первый...

Проц сам ничего не "строчит". Если Вы так пишете своё ПО, что у Вас байты попадают или не попадают куда-то по воле случая, то пенять надо только на себя.
Если немного включить голову и понять, что при заполнении буфера, задачу в которой выполняется printf(), можно заблокировать до момента освобождения места в этом буфере, то всё получится с любым размером буфера. ISR или DMA передаст часть данных из буфера в UART и сообщит об этом ждущей задаче (с printf-ом), разбудит её, чтобы она могла дописать ещё байты в буфер.
И всё. Всё элементарно. Но ардуинщики продолжают городить задержки, и удивляются что у них кто-то куда-то "строчит" и уже не хватает даже килобайтов памяти на ерундовую задачу...
PS: У меня printf вполне себе нормально формирует HTTP-ответы (в HTTP-сервере) большими потоками и нескольким клиентам параллельно. И обходится минимальными буферами.

[Димон Безпарольн...]

можно заблокировать до момента освобождения места в этом буфере, то всё получится с любым размером буфера.

Можно и дальше гнуть свое, не читая что я пишу, но толку от этого не будет. Много букв и все впустую.

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

P.S.
Я даже не ардуинщик - я тупой и еще тупее. Пнумпень вообщем. Это чтоб Вам было спокойней.

[HardEgor]

В данном случае это ПОКА неприемлимо. Сервер выкидывает HandShake, следом сертификаты. Так вот. С выводом debug информации не получается успевать декодировать первое сообщение - его затирает втрое.

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

[Димон Безпарольн...]

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

Даже не представляю как на стадии Hanshake это сделать. Стандарт этого не предусматривает. Более того, после HandShake в меня через миллисекунды вываливаются сертификаты. Если не успеть обработать Hanshake, то его в буфере забивают сертификаты. А мне бы хотелось еще и DEBUG почитать. Но Вы правы. Кроме огромного 8кБ буфера кажется решений не существует.

[Эдди]

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

[adnega]

Сервер выкидывает HandShake, следом сертификаты. Так вот. С выводом debug информации не получается успевать декодировать первое сообщение - его затирает втрое.

А по какому каналу связь с сервером? Какой протокол?

[Димон Безпарольн...]

А по какому каналу связь с сервером? Какой протокол?

Протокол MQTT уже отлажен. Теперь надо все закрыть TLS.

Дошел до parse certificate. Застрял с проблемой вывода отладочной информации. Сервер internetofthings.ibmcloud.com

Сообщение отредактировал Димон Безпарольный - Feb 16 2018, 17:07

[kolobok0]

Дошел до ..

чисто по коду в первом посте...
1) задержку надо делать не после а ДО вывода. Тогда возможно шансов упереться в ожидание - снижается, хотя фокусов не бывает. поток вывода из мк, должен обеспечивать скорострельность софта генерящего эти мессаги.
2) если у вас буффер(или предполагаете его юзать) - то ждать надо не абстрактное число мкс а именно свободное место в буффере вывода. Но буффер для дебажного вывода - не есть гуд. когда мозги подвисают - всё самое интересное именно не успеет уйти...

по поводу вообще логики логгирования и метрии..
- рекомендую глянуть готовую либу libp7-baical. Она под мк так-же...


удачи вам
(круглый)

[adnega]

Протокол MQTT уже отлажен.

Протокол MQTT работает на прикладном уровне поверх TCP/IP

Вы можете стандартными средствами TCP притормозить выдачу данных удаленной стороной, чтобы она вам буфер не перезаписывала.

[HardEgor]

Даже не представляю как на стадии Hanshake это сделать. Стандарт этого не предусматривает. Более того, после HandShake в меня через миллисекунды вываливаются сертификаты. Если не успеть обработать Hanshake, то его в буфере забивают сертификаты. А мне бы хотелось еще и DEBUG почитать. Но Вы правы. Кроме огромного 8кБ буфера кажется решений не существует.

Что за дурацкий протокол без подтверждения приема?
Стоп, а каким образом на незавершенный hanshake начинают слать сертификаты? Вы же еще не договорились с удаленной стороной?
А если вы не успели обработать сертификаты, сервер начинает слать данные, которые забивают сертификаты??? 8-)
Либо в протоколе всё это есть и вы не разобрались с самой сложной частью протокола, либо протокол тупо рассчитан на большие компьютеры и естественно плохо ложится на микроконтроллеры.

[Димон Безпарольн...]

Вы можете стандартными средствами TCP притормозить выдачу данных удаленной стороной, чтобы она вам буфер не перезаписывала.

Не нашел такой возможности у модулей Quectel M95. Наверно аппаратно можно RTS - CTS. Но они не заведены.

Что за дурацкий протокол без подтверждения приема?
Стоп, а каким образом на незавершенный hanshake начинают слать сертификаты? Вы же еще не договорились с удаленной стороной?
А если вы не успели обработать сертификаты, сервер начинает слать данные, которые забивают сертификаты??? 8-)
Либо в протоколе всё это есть и вы не разобрались с самой сложной частью протокола, либо протокол тупо рассчитан на большие компьютеры и естественно плохо ложится на микроконтроллеры.

Второе от части верно. Может я неправильно выразился. Первая часть hanshake - это когда сервер сообщает о выбранном шифронаборе из предложенных абонентом. После этого вываливает сертификаты. Но контроллер то не слабый - Cortex M3. L151 STM.

Проблему частично решил пока вставив в некритичные во времени места библиотеки TLS функцию:

Код

void Wait_PC_USART_TX_FLUSH(void)
{
    while(PC_TxHead == PC_TxTail)
        {PC_En_Tranfer_Interrupt;}
}

Это позволило уменьшить буфер с 8 до 2Кб. Информация выводится без потерь.

Сообщение отредактировал Димон Безпарольный - Feb 17 2018, 02:26

[jcxz]

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

Если надо одномоментно выдать большой объём данных без приостановки процесса их выдающего, то тут - или увеличивать буфер или увеличивать скорость канала связи. Больше никак.
А с подвисанием мозгов, если такое имеет место быть, надо бороться отдельно - сперва устранить причины зависания, а потом думать о корректном выводе отладочной информации. Естественно, что все fault-ы должны корректно обрабатываться и выводиться в лог. Тогда количество "зависаний" резко сократится.

Не нашел такой возможности у модулей Quectel M95. Наверно аппаратно можно RTS - CTS. Но они не заведены.

Видимо этот косяк надо исправить.
Хотя аппаратный flowcontrol по UART может быть управлением потоком только именно по UART, между модулем и МК. И никак не влиять на TCP-сокет. Управлять потоком надо именно в TCP-сокете, т.е. - там где расположен стек.

PS: Изначально автор писал о переполнении вывода по UART, постепенно нарисовался ещё TCP (где-то) и, видимо, этот TCP находится в некоем модуле, подключенном по UART (другому или этому же самому?). А переполнение видимо идёт в другом UART (?), через который выводится отладочный лог. Или не так?
Автор в шапке треда написал чрезмерно много буков, но не удосужился даже мельком описать свою архитектуру.
Вобщем - для форумчан предлагается очередной конкурс-угадайка для экстрасенсов. Видимо автору не нужна реальная помощь, а просто хочется потрепаться...
Если для проблемного вывода отладки используется именно отдельный интерфейс, то тут только или тормозить отлаживаемый процесс (управлением потоком), или увеличить скорость отладочного интерфейса. Не вижу проблем поднять скорость UART до 921600 даже на таком дохлом МК как у автора (RC-генератор - не есть препятствие для этого, препятствие есть - не использование DMA на таком МК). Ещё больше поднять скорость можно заменив вывод в UART, каким-то другим интерфейсом, например: вывод в параллельный порт, USB, Ethernet, ...

[Димон Безпарольн...]

Да, наверно надо было рассказать об архитектуре. К процессору по уартам подключены модули ESP-05 WiFi и M95 GSM.
По отдельному порту работает DEBUG. C ним и проблемы.

Задача - собрать информацию и отправить ее на MQTT сервер. Это отлажено и работает уже в железках. Теперь начальство возгордилось своим детищем и решило закрыть все это TLSом. Подводная лодка же. Вот тут и начались проблемы описанные выше. Скорость Debug сейчас 460800.

Да, обнаружилась таки еще проблема уже с железом не связанная. При больших потоках байты таки теряются уже в интерфейсе USB. Приходится таки выдавать с задержками. Тогда работает.

Сообщение отредактировал Димон Безпарольный - Feb 17 2018, 12:18