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

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

Не хочется создавать большой кольцевой буфер для PRINTF. Поступил по - другому. С задержкой.

Посчитав что PRINTF работает через int fputc(int ch, FILE *f), в ней и написал:

Код

int fputc(int ch, FILE *f)                  //Внутри функции реализована задержка заполнения
{                                            //буфера для уменьшения размера буфера.
static unsigned int StreamWaitCnt = 0;        //
    StreamWaitCnt++;                        //Счетчик числа передаваемых байт
    if (StreamWaitCnt > PC_TxBufSize-5)        //Если счеттчик достиг размера буфера
        {                                    //
            StreamWaitCnt = 0;                //Обнулить счетчик
            HAL_Delay(30);                    //Задержка пока буфер улетит в порт
        }                                    //
    return (PC_Putchar(ch));                 //
}                                            //

Т.е. когда буфер заполняется, происходит задержка для ожидания завершения передачи буфера в порт. Передача осуществляется через прерывание:

Код

int PC_Putchar(int ch)                         //Передача. Функция помещает Ch в кольцевой буфер.
{                                             //Указатель головы кольцевого буфера перемещается на
    int tmphead = (PC_TxHead + 1) & PC_TX_BUFFER_MASK; //одну позицию, символ помещается в кольцевой буфер.
    PC_TxBuf[tmphead] = (char)ch;               //Если передача первая после опустошения
    PC_TxHead = tmphead;                    //буфера(переданы все символы), взводится флаг L86_Complete,
        if (PC_Complete==0)                    //Передаваемый символ помещается в передающий регистр порта
        {                                     //(L86_UsartTx();) и инициируется первая передача
            PC_Complete = 1;                //в цепочке - разрешением прерывания.
            PC_UsartTx();                     //Флаг начала цепочки передач
            PC_En_Tranfer_Interrupt;        //Положить первый символ в DR
        }                                     //
    return (ch);                            //
}                                             //

Само прерывание:

Код

void USART2_IRQHandler(void)
{
    if (USART2->ISR & USART_ISR_TC)                 //Bit 6 TC: Transmission complete
    {                                             //
        PC_UsartTx();                             //
    }                                            //
    if (USART2->ISR & USART_ISR_RXNE)             //Bit 5 RXNE: Read data register not empty
    {                                             //
        PC_UsartRx();                            //Функция кладет байт из приёмного регистра в кольцевой буфер
    }                                             //
  HAL_UART_IRQHandler(&huart2);
}

Код

void PC_UsartTx(void)                         //
{                                             //
    if (PC_TxHead != PC_TxTail)                //Check if all data is transmitted
    {                                         //
        PC_TxTail = (PC_TxTail + 1) & PC_TX_BUFFER_MASK;//Перемещение указателя по кольцевому буферу
        USART2->TDR = (int)PC_TxBuf[PC_TxTail];    //Start transmition
    }                                         //
    else                                    //
    {                                        //
        PC_Complete=0;                        //Цепочка передачи окончена
        PC_Dis_Tranfer_Interrupt;            //Запретить прерывание на передачу Bit 6 TCIE:
    }                                        //
}                                             //

Самой задержки (30мс) по идее должно хватать. Т.е. при скорости 115200 за 1 секунду улетает 10килобайт. Примерно. Значит за милисекунду - 10 байт. Итого - 300байт при буфере в 256.

Такой подход по идее должен разрешать иметь любой малый (в разумных пределах) буфер для передачи. На практике же это не работает - часть выводимой информации теряется. И только когда я делаю #define PC_TxBufSize 8192, передача осуществляется без потерь.

Где же я не прав, может кто подскажет?

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

[jcxz]

Самой задержки (30мс) по идее должно хватать.

Задержки - типичный ардуино-подход, дилетантский.
Для вывода в поток с помощью printf() никаких задержек вообще не нужно. И размер буфера может быть абсолютно любым, хоть 1 байт. Буфер только даёт возможность более эффективно использовать быстродействие CPU - в среднем уменьшает загрузку CPU.
Если у Вас что-то не работает из-за изменения размеров буфера или требует каких-то задержек - правьте консерваторию.

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

Задержки - типичный ардуино-подход, дилетантский.
Для вывода в поток с помощью printf() никаких задержек вообще не нужно. И размер буфера может быть абсолютно любым, хоть 1 байт. Буфер только даёт возможность более эффективно использовать быстродействие CPU - в среднем уменьшает загрузку CPU.
Если у Вас что-то не работает из-за изменения размеров буфера или требует каких-то задержек - правьте консерваторию.

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

[Эдди]

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

Сам он это не выплюнет, он сделает так, как ему разработчик велел. И если разработчик не проверяет коды возврата из процедур, это его личные проблемы!
Если хочется использовать printf (хотя эта штука ну слишком уж жирная!), то она, если что, тоже возвращает количество принятых символов. И вместо фиксированного времени ожидания можно лишь подождать, пока буфер не освободится и закинуть в него критическое сообщение. Некритическое же вообще можно опустить (но для этого придется дописать простой макрос, возвращающий количество свободных символов в буфере).

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

Сам он это не выплюнет, он сделает так, как ему разработчик велел. И если разработчик не проверяет коды возврата из процедур, это его личные проблемы!
Если хочется использовать printf (хотя эта штука ну слишком уж жирная!), то она, если что, тоже возвращает количество принятых символов. И вместо фиксированного времени ожидания можно лишь подождать, пока буфер не освободится и закинуть в него критическое сообщение. Некритическое же вообще можно опустить (но для этого придется дописать простой макрос, возвращающий количество свободных символов в буфере).

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

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

можно лишь подождать, пока буфер не освободится

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

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

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

[adnega]

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

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

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

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

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

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

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

[kolobok0]

Дошел до ..

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

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


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

[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, ...