Помогите разобраться с 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

[mcheb]

Я бился с такой проблемой, не решил. Сделал так. Отказался от передачи ТХ в прерывании, то есть перешёл на поллинг. В терминальной программе поставил задержку после передачи новой строки на 1 миллисекунду. Увеличение буфера до 8кБ помогает, но не всегда. Причём это в Виндоуз и в Линуксе. А файл 1кБ отлично передавался и с буфером 256 байт.

[adnega]

часть выводимой информации теряется.

А вы уверены, что теряет не приемная сторона?

[mcheb]

А вы уверены, что теряет не приемная сторона?

Я делал USB-UART на STM32F103 и на CC2511. RX замкнут на TX. На CC2511 нормально работало до 1 МГц, на STM32F103 после 9600 были сбои на длинных файлах. Так и не разобрался.

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

Я бился с такой проблемой, не решил. Сделал так. Отказался от передачи ТХ в прерывании, то есть перешёл на поллинг. В терминальной программе поставил задержку после передачи новой строки на 1 миллисекунду. Увеличение буфера до 8кБ помогает, но не всегда. Причём это в Виндоуз и в Линуксе. А файл 1кБ отлично передавался и с буфером 256 байт.

Вы правы. В случае поллинга все работает исправно.

Код

USART2->TDR = ch;
if(UART_WaitOnFlagUntilTimeout(&huart2, UART_FLAG_TC, RESET, 100) != HAL_OK)
    {

    }

Но поллинг накладывает временные ограничения на выполнение. Я пишу код MBED TLS и в этом случае не проходит даже handshake. Либо в моем софте еще один глюк...

Видимо без буфера не обойтись.

Я делал USB-UART на STM32F103 и на CC2511. RX замкнут на TX. На CC2511 нормально работало до 1 МГц, на STM32F103 после 9600 были сбои на длинных файлах. Так и не разобрался.

У меня были сбои на 460800 пока я не перешел на кварц. Хотя на 9600 смещение частоты вряд ли скажется...

А вы уверены, что теряет не приемная сторона?

Уверен что приемная сторона нипричем. Сделал поллинг - вывод сработал исправно.

[adnega]

на STM32F103 после 9600 были сбои на длинных файлах. Так и не разобрался.

Я при помощи STM32F103C8 гнал поток 2.25 Мбод (RX замкнут с TX). Ни один байт не потерялся за значительное время.

[x893]

Я при помощи STM32F103C8 гнал поток 2.25 Мбод (RX замкнут с TX). Ни один байт не потерялся за значительное время.

Конечно не будет теряться, если код написан правильно.
Я на 926000 тоже нормально гонял на другое устройство.

[adnega]

Конечно не будет теряться, если код написан правильно.

Я писал так

Код

void USART2_IRQHandler(void)
{
    if(USART2->ISR & (1 << USART_ISR_TXE))
    {
        if(con.tx_t != con.tx_b) USART2->TDR = bl_export.bl_sp_tx_pop(&con);
        else USART2->CR1 &= ~(1 << USART_CR1_TXEIE);
    }
    if(USART2->ISR & (1 << USART_ISR_ORE))
    {
        USART2->ICR = (1 << USART_ISR_ORE);
    }
    if(USART2->ISR & (1 << USART_ISR_RXNE))
    {
        con.rx_tm = 0;
        bl_export.bl_sp_rx_push(&con, USART2->RDR);
    }
}

push и pop помещают и извлекают байты из кольцевых буферов tx и rx.

[jcxz]

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

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

[x893]

Я делал совсем по простому
2 буфера линейных
ПДП
таймер
всё пузЫрилось на ура.

[Эдди]

Проверяйте в функции отправки сообщения статус возврата! Если ошибка — либо пропускайте (сообщение некритичное), либо ждите подтверждения отправки.
Соответственно, функция, заполняющая буфер просто будет возвращать OK если место есть и ошибку, если буфер полностью заполнен и надо подождать, пока "уедет".

Если используете линейный буфер (тогда удобней делать двойную буферизацию), отправка реализуется при помощи DMA, а буферы меняются местами по флагу, выставленному в прерывании по окончании DMA.
Если буфер кольцевой, придется в обработчике прерывания TXE выполнять основную работу.

Но в любом случае ни в коем случае не надо лепить паузы! Это же не абдурина!!! Если буфер заполняется слишком быстро, либо повышайте скорость передачи, либо увеличивайте буфер.

[mcheb]

Очень может быть, что сбои (потери) байтов из-за плохой трассировки печатной платы. Изменение буферов, скоростей, поллинга-прерываний изменяют наводки от фронтов Rx-Tx и уменьшение скорости тогда единственный выход.

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

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

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

[Эдди]

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

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

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

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

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

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

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

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

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

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

[Эдди]

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

[HardEgor]

Видимо автору не нужна реальная помощь, а просто хочется потрепаться...

Для меня автор выглядит школьником, который прочитал книгу как программировать STM32, да в школе недавно программирование изучали - нафантазировал перспективы, а тут и задачка подвернулась крутая - но нам всё по плечу, вот и взялся делать.
Просто я лет в 14 понял как работают логические схемы, прочитал книгу японца про компьютеры и в своих фантазиях строил крутейшие компьютеры, если бы тогда предложили его построить - я бы взялся. Это сейчас я понимаю что в одиночку облажался бы.
Но у автора есть интернет и там множество форумов по всем темам, и специалистов хватает - помогут же, вот и заваливает он всех дилетантскими вопросами по различным темам.

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

И кому из нас здесь хочется потрепаться? Столько букф - ради чего?

[jcxz]

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

О! Ещё и USB всплыл... Угадайка продолжается?
Где в Вашей архитектуре он фигурирует и в каком качестве?
И опять магические костылизадержки на которых всё только и держится

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

FT232. Странное дело. Вроде компов - то с комом не осталось... Слушай, хочешь потрепаться - иди в другую тему. Толку от тебя все равно нет. А на задержках - да, держится. Через сутки я разберусь в чем проблема и сотру этот код вместе с задержками.

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

[jcxz]

FT232. Странное дело. Вроде компов - то с комом не осталось...

Действительно странное. На домашнем компе - 2x COM на MB, на работе - COM на MB + мультипортовка-PCI, на старой работе - мультипортовка-PCI.
Видимо это глюки это у меня. Видимо их всё-таки нет
Если у Вас чего-то нет, то не нужно думать, что все такие бедные.

Слушай, хочешь потрепаться - иди в другую тему.

Слушайте - не нужно меня посылать. И мы с вами на брудершафт не пили.

Через сутки я разберусь в чем проблема и сотру этот код вместе с задержками.

ну-ну. ...и слепите новые костыли.

PS: Не нужны советы - нафига тогда вообще сюда писать? Не умеете прочитать и понять советы - это ваша проблема, а не тех кто советует.

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

Зачем столько букв писать? Я получил информацию от людей, за что им большое спасибо. А ты загаживаешь мою тему хламом, расходуя на это самое дорогое что у человека есть - время. Еще раз, для непонятливых - мне не нужны ТВОИ советы. Они не содержат информации.

[adnega]

А ты загаживаешь мою тему хламом, расходуя на это самое дорогое что у человека есть - время. Еще раз, для непонятливых - мне не нужны ТВОИ советы. Они не содержат информации.

Еще в посте #9 уважаемый jcxz посоветовал проверить консерваторию. Я полностью поддерживаю его совет, а от себя посоветовал бы не переходить на необоснованное хамство в отношении людей. Подход, который вы используете не годится для решения коммерческих задач, а поскольку у вас есть руководство, то осмелюсь предположить, что ваша задачка не поделка выходного для. Если вы для себя или для начальства хотите получить подтверждение "эта задача не может быть решена", то вы ошибаетесь - задача элементарная, но вы решаете ее не с того края, отсюда и сложности. Попробуйте успокоиться и понять, что вам советуют. Я сам в том месяце работал с ESP8266 и МК уровня STM32F0. От сервера приходят UDP-пакеты и я на каждый должен ответить. Но пока я отвечаю на предыдущий, ко мне может прилетесь еще несколько новых. Памяти на всех нет в принципе. Поэтому, получив и обработав пакет, я помечаю, что нужно отправить ответ (один флаг). Получив другие пакеты - обрабатываю их и устанавливаю соответствующие флаги. Когда есть возможность отправить ответ, смотрю первый попавшийся флаг и отправляю соответствующий ответ сбросив флаг. Расход памяти минимальный, все пакеты обрабатываются, никто не теряется, никаких задержек нет. Предыдущий код требовал, чтобы сервер не отправлял UDP-пакет, не получив ответ на предыдущий, т.к. буфера перетерались.
Все решает грамотная архитектура, а необходимость задержек, зависимость от размера буферов и т.п. являются свидетельством неграмотной архитектуры или ее отсутствия. Кто-то называет это консерваторией. Подход "через сутки разберусь, а дальше меня не волнует" тоже не признак профессионализма. Завтра начальство захочет новую фичу, и вы с большой вероятностью не сможете ее добавить, т.к. ваш подход обладает плохой масштабируемостью. Пару раз по банальным фичам ответите начальству отказом - на вашем месте будет работать другой программист. Оно вам надо?

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

Мне этот подход знаком - самое главное не замечать что хамство и переход на личность начался с 29 поста и обвинять в этом только меня. Терпел до последнего, но господин принял вежливость за слабость и не унялся.

Здесь вполне уважаемые люди, но без гнильцы не обходится ни один форум. У товарища гонору как у Циолковского, а желания разбираться нет. Видимо и знаний тоже нет.

Здесь только один человек придрался к задержкам не пожелав разобраться в сути. Даже когда я написал, что проблема УЖЕ не в контроллере, пакеты теряются за ним - он не унялся. Число байт ушедших в DR больше чем выплюнул терминал на 1-3байта на 8Кб информации. Поскольку данные не искажаются, я склонен полагать что частоты не смещены. И только ЗАДЕРЖКА в некритичных во времени местах решила эту проблему, я думаю что Вы уже догадались почему.

У Вас желания тоже не нашлось. У меня другая ситуация чем то, что Вы написали. Замечательно что Вы обошлись без памяти и у Вас просто все это работает. Рад за Вас. Вы просто герой.

Я НЕ могу ничего отложить. В меня последовательно выплевывают тремя пакетами - таков алгоритм HANDSHAKE. Я должен их обработать в реальном времени. Задержка между пакетами - милисекунды. Поэтому если я занимаюсь выводом DEBUG информации с ОЖИДАНИЕМ появления в буфере свободного места - я ПРОСТО ТЕРЯЮ ПАКЕТЫ.

ЗДЕРЖКА в некритичных во времени местах помогает снизить размер кольцевого буфера PC порта с 8 до 2кБ. Предложите другой способ - обсудим.

Ну как до "светочей" разума и всяких свидомитов донести эту простую мысль? Третий раз пишу. А мне намекают на консерваторию. Зачем тартить жизнь на написание глупостей особенно если считаешь себя Циолковским?

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

[adnega]

Я должен их обработать в реальном времени.

Дык, вы же их обрабатываете без проблем. Просто вы хотите параллельно зачем-то сгенерить гораздо большую по объему отладочную информацию и успеть ее выплюнуть. Старайтесь в отладку выкидывать только ошибки и результат обработчика HardFault. Что вам мешает подключиться к uart от модема и записывать весь обмен, а затем его обрабатывать (в том числе и с помощью спецутилит)?

Ну как до "светочей" разума и всяких свидомитов донести эту простую мысль? Третий раз пишу.

Дык, попытайтесь писать суть, а не "много букв". Не всегда, чем длиннее текст, тем там больше информации.
Как называется ваша тема? И при чем тут printf, когда причина у вас в совершенно другом месте?
Боюсь, если вы не поменяете манеру общения, то заработаете на этом форуме себе такую репутацию, что большинство профи откажутся вам помогать.
У меня позиция, что отвечая на форуме - помогаешь не ТС, а всем, т.к. кто-то может столкнуться с аналогичной проблемой в будущем.

[Сергей Борщ]

Предложите другой способ - обсудим.

Неа. Тут уже правильно писали: проблема в консерватории. Прислушайтесь к этому совету:

Боюсь, если вы не поменяете манеру общения, то заработаете на этом форуме себе такую репутацию, что большинство профи откажутся вам помогать.

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

Дык, вы же их обрабатываете без проблем. Просто вы хотите параллельно зачем-то сгенерить гораздо большую по объему отладочную информацию и успеть ее выплюнуть. Старайтесь в отладку выкидывать только ошибки и результат обработчика HardFault. Что вам мешает подключиться к uart от модема и записывать весь обмен, а затем его обрабатывать (в том числе и с помощью спецутилит)?


Дык, попытайтесь писать суть, а не "много букв". Не всегда, чем длиннее текст, тем там больше информации.
Как называется ваша тема? И при чем тут printf, когда причина у вас в совершенно другом месте?
Боюсь, если вы не поменяете манеру общения, то заработаете на этом форуме себе такую репутацию, что большинство профи откажутся вам помогать.
У меня позиция, что отвечая на форуме - помогаешь не ТС, а всем, т.к. кто-то может столкнуться с аналогичной проблемой в будущем.

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

Тема о правильной организации вывода debug информации. Она выводится через printf. Эта информация генерится библиотекой mbedtls. Вывод раскидан в три файла по 5-7 тысяч строк каждый. В общей сложности 150 точек вывода примерно. Ей Богу, править и раскидывать по уровням debuglevel - не лучший выход.

Не я что - то там выкидываю отладочное в порт, а автор библиотеки. Ну и я потом печатаю принятый дамп уже в некритичном по времени месте.

Сейчас это работает и очень помогает мне разобраться в сути.

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

[adnega]

Сейчас это работает и очень помогает мне разобраться в сути.

Что ж остается лишь пожелать вам удачи.

[jcxz]

Боюсь, если вы не поменяете манеру общения, то заработаете на этом форуме себе такую репутацию, что большинство профи откажутся вам помогать.
У меня позиция, что отвечая на форуме - помогаешь не ТС, а всем, т.к. кто-то может столкнуться с аналогичной проблемой в будущем.

Не утруждайте себя, коллега. Товарищ уже показал тут во всей красе кем он является - тут уже ничего не исправимо.
У него все вокруг виноваты: и не правильно советуют, и автор некоей "библиотеки" неправильно что-то там делает.
И сплошной поток хамства в ответ на попытки помочь ему...
Товарищ уже в игнор-листе.

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

Попытки "помочь" как раз и начались у этого "помошника" с хамства в 29-м посту. Остальное - чистая ложь. Ное ему не привыкать.

[adnega]

Попытки "помочь" как раз и начались у этого "помошника" с хамства в 29-м посту. Остальное - чистая ложь. Ное ему не привыкать.

Перечитал пост #29. Кроме

Видимо автору не нужна реальная помощь, а просто хочется потрепаться

все остальное по делу и справедливо. Хотя, и процитированное предположение имеет право на жизнь.

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

Хоть тут мне и приписали что я обвиняю в чем - то авторов MBED TLS (вероятно тоже "по делу"), хочу отдать должное - ребята грамотные, постарались на славу. Благодаря debug информации, проверкам конфигурации такая сложная библиотека не так уж трудно отлаживается. Респект.

Что касается самого DBUG, то сколько тут местные "помощники" ни надрывались, ничего нового не придумали - не можешь ждать, делай буфер шире. Как промежуточное решение - задержка перед критическим во времени местом выполнения, чтобы войти в этот кусок кода с чистым буфером. Тогда буфер можно сделать меньше. Это вкратце.

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

[adnega]

то сколько тут местные "помощники" ни надрывались, ничего нового не придумали - не можешь ждать, делай буфер шире.

Ровно так же никто из профи не сможет ничего придумать, чтобы по вашему желанию "2х2=5".
Грамотное решение - попросить вторую сторону не присылать данные, к обработке которых вы не готовы.
TCP позволяет это делать, причем очень гибко и грамотно. Если вы не хотите разобраться как это сделать, то да - увеличивайте буфер,
но не надо в код вставлять задержки, даже если сейчас это работает. И точно не нужно хамить людям, которые считают такой подход
дурным тоном программирования.

[Эдди]

Хоть тут мне и приписали что я обвиняю в чем - то авторов MBED TLS (вероятно тоже "по делу"), хочу отдать должное - ребята грамотные, постарались на славу.

Да ладно!
То-то чрез одно место оно работает…
Хотя, надо еще уточнить, по чьей вине: то ли вы, товарищ, неправильно документацию читаете, то ли авторы этой библиотеки...

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

Ровно так же никто из профи не сможет ничего придумать, чтобы по вашему желанию "2х2=5".
Грамотное решение - попросить вторую сторону не присылать данные, к обработке которых вы не готовы.
TCP позволяет это делать, причем очень гибко и грамотно. Если вы не хотите разобраться как это сделать, то да - увеличивайте буфер,
но не надо в код вставлять задержки, даже если сейчас это работает. И точно не нужно хамить людям, которые считают такой подход
дурным тоном программирования.

Никто и не собирался изначально хамить. Хамство и переход на личности начался с 29 поста. Я лишь вежливо просил не гадить в этой теме. Но "помошник" так и не понял о чем его просят.

Что касается 2х2 =5, люди предлагают иногда нестандартные решения. На это и надеялся. Но нарвался на хама . знал бы - не начинал бы сюда писать.

На стадии handshake сервер ждать не будет. Так обьяснили инженеры IBM. Связано с загрузкой серверов. Да и я не представляю сейчас как это сделать через M95 в котором TCP реализован внутри.

Да ладно!
То-то чрез одно место оно работает…
Хотя, надо еще уточнить, по чьей вине: то ли вы, товарищ, неправильно документацию читаете, то ли авторы этой библиотеки...

Ну Вам конечно виднее. Вы же код писали - не я. Работает нормально. Третий час - без сбоев.

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

[Эдди]

Это оно без сбоев работает, пока не понадобилось еще что-то добавить. А там опять та же песня пойдет?

[HardEgor]

На стадии handshake сервер ждать не будет. Так обьяснили инженеры IBM. Связано с загрузкой серверов. Да и я не представляю сейчас как это сделать через M95 в котором TCP реализован внутри.

Завтра у них немного изменится размер hadshake, сертификатов, или задержка в одном месте появится, а в другом исчезнет и у вас внезапно всё перестанет работать. Или вдруг сервер сменится....

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

Завтра у них немного изменится размер hadshake, сертификатов, или задержка в одном месте появится, а в другом исчезнет и у вас внезапно всё перестанет работать. Или вдруг сервер сменится....

Вы наверно стандарт не читали. Весь мир работает с серверами MQTT IBM. В России кучу железа понаделали. Откуда столько страхов?

[adnega]

Да и я не представляю сейчас как это сделать через M95 в котором TCP реализован внутри.

Почитать Инструкцию

When the data transfer should be suspended, the CTS line is set inactive until the transfer from the receiving buffer has
completed. When the receiving buffer is ok to receive more data, CTS goes active once again.

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

Я уже писал, что аппаратная реализация не предусматривает пару RTS - CTS. К тому же в модулях ESP - 05 эти сигналы наружу не выведены. В изделии два радиомодуля.



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

[adnega]

Я уже писал, что аппаратная реализация не предусматривает пару RTS - CTS. К тому же в модулях ESP - 05 эти сигналы наружу не выведены. В изделии два радиомодуля.

Вам же для отладки нужно. Киньте проводком. Когда все отладите - отключите debug-вывод портянок и уберете провод.

[HardEgor]

Вы наверно стандарт не читали. Весь мир работает с серверами MQTT IBM. В России кучу железа понаделали. Откуда столько страхов?

А мне и не надо читать. Если в программе требуется подбор задержек - значит программа неправильно построена. И эта неправильность внезапно вылезет в самый неподходящий момент. Вы же сами писали:

На стадии handshake сервер ждать не будет. Так обьяснили инженеры IBM. Связано с загрузкой серверов.

А завтра у инженеров IBM что-нибудь еще возникнет и они еще чего-нибудь поменяют....
Вот в этом и состоит разница между между профессиональным и дилетантским(читай начинающего) подходом, профессионал во-первых руководствуется правилами и стандартами при разработке, во-вторых он видит и понимает "подводные камни" которые могут возникнуть или точно проявятся и смотрит в перспективу. А дилетант говорит - у меня всё работает отлично, остальное меня не волнует.
У меня студенты на практику приходят, типичные дилетанты, я им это сразу говорю и они делятся на две группы - одних ничего не интересует, главное чтобы заработало, они начинают подбирать в программах задержки, в схемах резисторы и конденсаторы, а другие пытаются разобраться и потом осознанно применяют.

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

Стандарт как раз такое допскает. Задержка нужна была на стадии отладки как временное решение. Ее уже нет, как и вывода массива DBUG информации. Стандарт на TLS допускает такую работу сервера. Дилетант как раз и говорит:

А мне и не надо читать.

и не разобравшись в сути делает вывод:

Если в программе требуется подбор задержек

Ничего подбирать не требовалось. Читайте выше. Не делайте глупых выводов раз Вы кого - то там учите.

Вам же для отладки нужно. Киньте проводком. Когда все отладите - отключите debug-вывод портянок и уберете провод.

Так уже. DEBUG отключен. Библиотека TLS работает AS - IS, без изменения кода библиотеки.

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

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

Может кому пригодится - когда начал дорабатывать вывод в порт заметил что контроллер виснет на строке

Код

while(PC_TxHead != PC_TxTail)

если переменные объявлять без volatile. Получается так:



Если объявлять:

Код

volatile uint8_t  PC_TxHead=0;
volatile uint8_t  PC_TxTail=0;

То получается совсем другая картина:





Оптимизация Level 3.

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

[x893]

Это уже всем ёжикам известно.
Но за заботу огромное спасибо.

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

Какие же все таки люди злые.