Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: Помогите разобраться с PRINTF
Форум разработчиков электроники ELECTRONIX.ru > Микроконтроллеры (MCs) > Cредства разработки для МК > Keil
Страницы: 1, 2
Димон Безпарольный
Не хочется создавать большой кольцевой буфер для 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, передача осуществляется без потерь.

Где же я не прав, может кто подскажет?
mcheb
Я бился с такой проблемой, не решил. Сделал так. Отказался от передачи ТХ в прерывании, то есть перешёл на поллинг. В терминальной программе поставил задержку после передачи новой строки на 1 миллисекунду. Увеличение буфера до 8кБ помогает, но не всегда. Причём это в Виндоуз и в Линуксе. А файл 1кБ отлично передавался и с буфером 256 байт.
adnega
Цитата(Димон Безпарольный @ Feb 16 2018, 06:26) *
часть выводимой информации теряется.

А вы уверены, что теряет не приемная сторона?
mcheb
Цитата(adnega @ Feb 16 2018, 09:39) *
А вы уверены, что теряет не приемная сторона?

Я делал USB-UART на STM32F103 и на CC2511. RX замкнут на TX. На CC2511 нормально работало до 1 МГц, на STM32F103 после 9600 были сбои на длинных файлах. Так и не разобрался.
Димон Безпарольный
Цитата(mcheb @ Feb 16 2018, 07:24) *
Я бился с такой проблемой, не решил. Сделал так. Отказался от передачи ТХ в прерывании, то есть перешёл на поллинг. В терминальной программе поставил задержку после передачи новой строки на 1 миллисекунду. Увеличение буфера до 8кБ помогает, но не всегда. Причём это в Виндоуз и в Линуксе. А файл 1кБ отлично передавался и с буфером 256 байт.

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

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

    }




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

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

Цитата(mcheb @ Feb 16 2018, 08:51) *
Я делал USB-UART на STM32F103 и на CC2511. RX замкнут на TX. На CC2511 нормально работало до 1 МГц, на STM32F103 после 9600 были сбои на длинных файлах. Так и не разобрался.

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

Цитата(adnega @ Feb 16 2018, 08:39) *
А вы уверены, что теряет не приемная сторона?

Уверен что приемная сторона нипричем. Сделал поллинг - вывод сработал исправно.
adnega
Цитата(mcheb @ Feb 16 2018, 08:51) *
на STM32F103 после 9600 были сбои на длинных файлах. Так и не разобрался.

Я при помощи STM32F103C8 гнал поток 2.25 Мбод (RX замкнут с TX). Ни один байт не потерялся за значительное время.
x893
Цитата(adnega @ Feb 16 2018, 09:16) *
Я при помощи STM32F103C8 гнал поток 2.25 Мбод (RX замкнут с TX). Ни один байт не потерялся за значительное время.

Конечно не будет теряться, если код написан правильно.
Я на 926000 тоже нормально гонял на другое устройство.
adnega
Цитата(x893 @ Feb 16 2018, 09:55) *
Конечно не будет теряться, если код написан правильно.

Я писал так
Код
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
Цитата(Димон Безпарольный @ Feb 16 2018, 05:26) *
Самой задержки (30мс) по идее должно хватать.

Задержки - типичный ардуино-подход, дилетантский.
Для вывода в поток с помощью printf() никаких задержек вообще не нужно. И размер буфера может быть абсолютно любым, хоть 1 байт. Буфер только даёт возможность более эффективно использовать быстродействие CPU - в среднем уменьшает загрузку CPU.
Если у Вас что-то не работает из-за изменения размеров буфера или требует каких-то задержек - правьте консерваторию.
x893
Я делал совсем по простому
2 буфера линейных
ПДП
таймер
всё пузЫрилось на ура.
Эдди
Проверяйте в функции отправки сообщения статус возврата! Если ошибка — либо пропускайте (сообщение некритичное), либо ждите подтверждения отправки.
Соответственно, функция, заполняющая буфер просто будет возвращать OK если место есть и ошибку, если буфер полностью заполнен и надо подождать, пока "уедет".

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

Но в любом случае ни в коем случае не надо лепить паузы! Это же не абдурина!!! Если буфер заполняется слишком быстро, либо повышайте скорость передачи, либо увеличивайте буфер.
mcheb
Очень может быть, что сбои (потери) байтов из-за плохой трассировки печатной платы. Изменение буферов, скоростей, поллинга-прерываний изменяют наводки от фронтов Rx-Tx и уменьшение скорости тогда единственный выход.
Димон Безпарольный
Цитата(jcxz @ Feb 16 2018, 10:36) *
Задержки - типичный ардуино-подход, дилетантский.
Для вывода в поток с помощью printf() никаких задержек вообще не нужно. И размер буфера может быть абсолютно любым, хоть 1 байт. Буфер только даёт возможность более эффективно использовать быстродействие CPU - в среднем уменьшает загрузку CPU.
Если у Вас что-то не работает из-за изменения размеров буфера или требует каких-то задержек - правьте консерваторию.

Интересная точка зрения. Ну допустим буфер 128 байт. Кольцевой. За пару милисекунд проц настрочил 5кб текста и выплюнул все это в кольцевой буфер. А с одним байтом будет еще прикольнее. Наверно только первый байт от 5кб и попадет в терминал. Мож и не первый...
Эдди
Цитата(Димон Безпарольный @ Feb 16 2018, 12:44) *
За пару милисекунд проц настрочил 5кб текста и выплюнул все это в кольцевой буфер.

Сам он это не выплюнет, он сделает так, как ему разработчик велел. И если разработчик не проверяет коды возврата из процедур, это его личные проблемы!
Если хочется использовать printf (хотя эта штука ну слишком уж жирная!), то она, если что, тоже возвращает количество принятых символов. И вместо фиксированного времени ожидания можно лишь подождать, пока буфер не освободится и закинуть в него критическое сообщение. Некритическое же вообще можно опустить (но для этого придется дописать простой макрос, возвращающий количество свободных символов в буфере).
Димон Безпарольный
Цитата(Эдди @ Feb 16 2018, 13:18) *
Сам он это не выплюнет, он сделает так, как ему разработчик велел. И если разработчик не проверяет коды возврата из процедур, это его личные проблемы!
Если хочется использовать printf (хотя эта штука ну слишком уж жирная!), то она, если что, тоже возвращает количество принятых символов. И вместо фиксированного времени ожидания можно лишь подождать, пока буфер не освободится и закинуть в него критическое сообщение. Некритическое же вообще можно опустить (но для этого придется дописать простой макрос, возвращающий количество свободных символов в буфере).

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

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

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


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

В данном случае это ПОКА неприемлимо. Сервер выкидывает HandShake, следом сертификаты. Так вот. С выводом debug информации не получается успевать декодировать первое сообщение - его затирает втрое.
Эдди
Цитата(Димон Безпарольный @ Feb 16 2018, 13:50) *
printf использует библиотека MBEDTLS, нужен форматирванный вывод.
Если вы не можете обойтись без дырявой библиотеки, правьте ее код и высылайте пулл-риквесты автору.
x893
Цитата(Димон Безпарольный @ Feb 16 2018, 13:50) *
printf использует библиотека MBEDTLS, нужен форматирванный вывод.

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



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

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

Для этого люди придумали блокирующий и неблокирующий вывод.
Ещё есть вывод через RTT (тоже нескольких типов).
Вы уж определитесь, что Вам нужно, а потом можно код строчить.
jcxz
Цитата(Димон Безпарольный @ Feb 16 2018, 11:44) *
За пару милисекунд проц настрочил 5кб текста и выплюнул все это в кольцевой буфер. А с одним байтом будет еще прикольнее. Наверно только первый байт от 5кб и попадет в терминал. Мож и не первый...

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

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

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

P.S.
Я даже не ардуинщик - я тупой и еще тупее. Пнумпень вообщем. Это чтоб Вам было спокойней.
HardEgor
Цитата(Димон Безпарольный @ Feb 16 2018, 17:50) *
В данном случае это ПОКА неприемлимо. Сервер выкидывает HandShake, следом сертификаты. Так вот. С выводом debug информации не получается успевать декодировать первое сообщение - его затирает втрое.

Хех, природу не наебе.. обманешь.
Если скорость поступления байтов от сервера выше чем скорость обработки и вывода printf, то либо увеличивайте буфер, либо просите сервер подождать с передачей пакетов а также размер пакета от сервера уменьшайте до размера вашего буфера.
Димон Безпарольный
Цитата(HardEgor @ Feb 16 2018, 16:42) *
Хех, природу не наебе.. обманешь.
Если скорость поступления байтов от сервера выше чем скорость обработки и вывода printf, то либо увеличивайте буфер, либо просите сервер подождать с передачей пакетов а также размер пакета от сервера уменьшайте до размера вашего буфера.

Даже не представляю как на стадии Hanshake это сделать. Стандарт этого не предусматривает. Более того, после HandShake в меня через миллисекунды вываливаются сертификаты. Если не успеть обработать Hanshake, то его в буфере забивают сертификаты. А мне бы хотелось еще и DEBUG почитать. Но Вы правы. Кроме огромного 8кБ буфера кажется решений не существует.
Эдди
Почему же? Есть еще одно решение: отдельно выделенный микроконтроллер, который только и будет что "общаться".
Но лучше уж, если так надо много данных хранить, взять МК пожирней.
adnega
Цитата(Димон Безпарольный @ Feb 16 2018, 13:50) *
Сервер выкидывает HandShake, следом сертификаты. Так вот. С выводом debug информации не получается успевать декодировать первое сообщение - его затирает втрое.

А по какому каналу связь с сервером? Какой протокол?
Димон Безпарольный
Цитата(adnega @ Feb 16 2018, 17:51) *
А по какому каналу связь с сервером? Какой протокол?

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

Дошел до parse certificate. Застрял с проблемой вывода отладочной информации. Сервер internetofthings.ibmcloud.com
kolobok0
Цитата(Димон Безпарольный @ Feb 16 2018, 20:02) *
Дошел до ..


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

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


удачи вам
(круглый)
adnega
Цитата(Димон Безпарольный @ Feb 16 2018, 20:02) *
Протокол MQTT уже отлажен.

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

Вы можете стандартными средствами TCP притормозить выдачу данных удаленной стороной, чтобы она вам буфер не перезаписывала.
HardEgor
Цитата(Димон Безпарольный @ Feb 16 2018, 20:49) *
Даже не представляю как на стадии Hanshake это сделать. Стандарт этого не предусматривает. Более того, после HandShake в меня через миллисекунды вываливаются сертификаты. Если не успеть обработать Hanshake, то его в буфере забивают сертификаты. А мне бы хотелось еще и DEBUG почитать. Но Вы правы. Кроме огромного 8кБ буфера кажется решений не существует.

Что за дурацкий протокол без подтверждения приема?
Стоп, а каким образом на незавершенный hanshake начинают слать сертификаты? Вы же еще не договорились с удаленной стороной?
А если вы не успели обработать сертификаты, сервер начинает слать данные, которые забивают сертификаты??? 8-)
Либо в протоколе всё это есть и вы не разобрались с самой сложной частью протокола, либо протокол тупо рассчитан на большие компьютеры и естественно плохо ложится на микроконтроллеры.
Димон Безпарольный
Цитата(adnega @ Feb 16 2018, 22:41) *
Вы можете стандартными средствами TCP притормозить выдачу данных удаленной стороной, чтобы она вам буфер не перезаписывала.

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

Цитата(HardEgor @ Feb 17 2018, 02:50) *
Что за дурацкий протокол без подтверждения приема?
Стоп, а каким образом на незавершенный 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Кб. Информация выводится без потерь.
jcxz
Цитата(kolobok0 @ Feb 16 2018, 19:33) *
2) если у вас буффер(или предполагаете его юзать) - то ждать надо не абстрактное число мкс а именно свободное место в буффере вывода. Но буффер для дебажного вывода - не есть гуд. когда мозги подвисают - всё самое интересное именно не успеет уйти...

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

Цитата(Димон Безпарольный @ Feb 17 2018, 03:54) *
Не нашел такой возможности у модулей Quectel M95. Наверно аппаратно можно RTS - CTS. Но они не заведены.

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

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

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

Да, обнаружилась таки еще проблема уже с железом не связанная. При больших потоках байты таки теряются уже в интерфейсе USB. Приходится таки выдавать с задержками. Тогда работает.
HardEgor
Цитата(jcxz @ Feb 17 2018, 17:23) *
Видимо автору не нужна реальная помощь, а просто хочется потрепаться... wacko.gif

Для меня автор выглядит школьником, который прочитал книгу как программировать STM32, да в школе недавно программирование изучали - нафантазировал перспективы, а тут и задачка подвернулась крутая - но нам всё по плечу, вот и взялся делать.
Просто я лет в 14 понял как работают логические схемы, прочитал книгу японца про компьютеры и в своих фантазиях строил крутейшие компьютеры, если бы тогда предложили его построить - я бы взялся. Это сейчас я понимаю что в одиночку облажался бы.
Но у автора есть интернет и там множество форумов по всем темам, и специалистов хватает - помогут же, вот и заваливает он всех дилетантскими вопросами по различным темам.
Димон Безпарольный
И кому из нас здесь хочется потрепаться? Столько букф - ради чего?
jcxz
Цитата(Димон Безпарольный @ Feb 17 2018, 14:15) *
Да, обнаружилась таки еще проблема уже с железом не связанная. При больших потоках байты таки теряются уже в интерфейсе USB. Приходится таки выдавать с задержками. Тогда работает.

О! Ещё и USB всплыл... Угадайка продолжается? rolleyes.gif
Где в Вашей архитектуре он фигурирует и в каком качестве?
И опять магические костылизадержки на которых всё только и держится rolleyes.gif
Димон Безпарольный
FT232. Странное дело. Вроде компов - то с комом не осталось... Слушай, хочешь потрепаться - иди в другую тему. Толку от тебя все равно нет. А на задержках - да, держится. Через сутки я разберусь в чем проблема и сотру этот код вместе с задержками.
jcxz
Цитата(Димон Безпарольный @ Feb 17 2018, 14:56) *
FT232. Странное дело. Вроде компов - то с комом не осталось...

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

Цитата(Димон Безпарольный @ Feb 17 2018, 14:56) *
Слушай, хочешь потрепаться - иди в другую тему.

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

Цитата(Димон Безпарольный @ Feb 17 2018, 14:56) *
Через сутки я разберусь в чем проблема и сотру этот код вместе с задержками.

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

PS: Не нужны советы - нафига тогда вообще сюда писать? Не умеете прочитать и понять советы - это ваша проблема, а не тех кто советует.
Димон Безпарольный
Зачем столько букв писать? Я получил информацию от людей, за что им большое спасибо. А ты загаживаешь мою тему хламом, расходуя на это самое дорогое что у человека есть - время. Еще раз, для непонятливых - мне не нужны ТВОИ советы. Они не содержат информации.
adnega
Цитата(Димон Безпарольный @ Feb 17 2018, 16:34) *
А ты загаживаешь мою тему хламом, расходуя на это самое дорогое что у человека есть - время. Еще раз, для непонятливых - мне не нужны ТВОИ советы. Они не содержат информации.

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

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

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

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

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

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

Ну как до "светочей" разума и всяких свидомитов донести эту простую мысль? Третий раз пишу. А мне намекают на консерваторию. Зачем тартить жизнь на написание глупостей особенно если считаешь себя Циолковским?
adnega
Цитата(Димон Безпарольный @ Feb 18 2018, 05:38) *
Я должен их обработать в реальном времени.

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

Цитата(Димон Безпарольный @ Feb 18 2018, 05:38) *
Ну как до "светочей" разума и всяких свидомитов донести эту простую мысль? Третий раз пишу.

Дык, попытайтесь писать суть, а не "много букв". Не всегда, чем длиннее текст, тем там больше информации.
Как называется ваша тема? И при чем тут printf, когда причина у вас в совершенно другом месте?
Боюсь, если вы не поменяете манеру общения, то заработаете на этом форуме себе такую репутацию, что большинство профи откажутся вам помогать.
У меня позиция, что отвечая на форуме - помогаешь не ТС, а всем, т.к. кто-то может столкнуться с аналогичной проблемой в будущем.
Сергей Борщ
QUOTE (Димон Безпарольный @ Feb 18 2018, 04:38) *
Предложите другой способ - обсудим.
Неа. Тут уже правильно писали: проблема в консерватории. Прислушайтесь к этому совету:
QUOTE (adnega @ Feb 18 2018, 09:11) *
Боюсь, если вы не поменяете манеру общения, то заработаете на этом форуме себе такую репутацию, что большинство профи откажутся вам помогать.

Димон Безпарольный
Цитата(adnega @ Feb 18 2018, 10:11) *
Дык, вы же их обрабатываете без проблем. Просто вы хотите параллельно зачем-то сгенерить гораздо большую по объему отладочную информацию и успеть ее выплюнуть. Старайтесь в отладку выкидывать только ошибки и результат обработчика HardFault. Что вам мешает подключиться к uart от модема и записывать весь обмен, а затем его обрабатывать (в том числе и с помощью спецутилит)?


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

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

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

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

Сейчас это работает и очень помогает мне разобраться в сути.
adnega
Цитата(Димон Безпарольный @ Feb 18 2018, 12:09) *
Сейчас это работает и очень помогает мне разобраться в сути.

Что ж остается лишь пожелать вам удачи.
jcxz
Цитата(adnega @ Feb 18 2018, 09:11) *
Боюсь, если вы не поменяете манеру общения, то заработаете на этом форуме себе такую репутацию, что большинство профи откажутся вам помогать.
У меня позиция, что отвечая на форуме - помогаешь не ТС, а всем, т.к. кто-то может столкнуться с аналогичной проблемой в будущем.

Не утруждайте себя, коллега. Товарищ уже показал тут во всей красе кем он является - тут уже ничего не исправимо. smile3046.gif
У него все вокруг виноваты: и не правильно советуют, и автор некоей "библиотеки" неправильно что-то там делает.
И сплошной поток хамства в ответ на попытки помочь ему...
Товарищ уже в игнор-листе.
Димон Безпарольный
Попытки "помочь" как раз и начались у этого "помошника" с хамства в 29-м посту. Остальное - чистая ложь. Ное ему не привыкать.
adnega
Цитата(Димон Безпарольный @ Feb 18 2018, 16:26) *
Попытки "помочь" как раз и начались у этого "помошника" с хамства в 29-м посту. Остальное - чистая ложь. Ное ему не привыкать.

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

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

Что касается самого DBUG, то сколько тут местные "помощники" ни надрывались, ничего нового не придумали - не можешь ждать, делай буфер шире. Как промежуточное решение - задержка перед критическим во времени местом выполнения, чтобы войти в этот кусок кода с чистым буфером. Тогда буфер можно сделать меньше. Это вкратце.
adnega
Цитата(Димон Безпарольный @ Feb 18 2018, 17:54) *
то сколько тут местные "помощники" ни надрывались, ничего нового не придумали - не можешь ждать, делай буфер шире.

Ровно так же никто из профи не сможет ничего придумать, чтобы по вашему желанию "2х2=5".
Грамотное решение - попросить вторую сторону не присылать данные, к обработке которых вы не готовы.
TCP позволяет это делать, причем очень гибко и грамотно. Если вы не хотите разобраться как это сделать, то да - увеличивайте буфер,
но не надо в код вставлять задержки, даже если сейчас это работает. И точно не нужно хамить людям, которые считают такой подход
дурным тоном программирования.
Эдди
Цитата(Димон Безпарольный @ Feb 18 2018, 17:54) *
Хоть тут мне и приписали что я обвиняю в чем - то авторов MBED TLS (вероятно тоже "по делу"), хочу отдать должное - ребята грамотные, постарались на славу.

Да ладно!
То-то чрез одно место оно работает…
Хотя, надо еще уточнить, по чьей вине: то ли вы, товарищ, неправильно документацию читаете, то ли авторы этой библиотеки...
Димон Безпарольный
Цитата(adnega @ Feb 18 2018, 18:23) *
Ровно так же никто из профи не сможет ничего придумать, чтобы по вашему желанию "2х2=5".
Грамотное решение - попросить вторую сторону не присылать данные, к обработке которых вы не готовы.
TCP позволяет это делать, причем очень гибко и грамотно. Если вы не хотите разобраться как это сделать, то да - увеличивайте буфер,
но не надо в код вставлять задержки, даже если сейчас это работает. И точно не нужно хамить людям, которые считают такой подход
дурным тоном программирования.



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

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

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



Цитата(Эдди @ Feb 18 2018, 18:32) *
Да ладно!
То-то чрез одно место оно работает…
Хотя, надо еще уточнить, по чьей вине: то ли вы, товарищ, неправильно документацию читаете, то ли авторы этой библиотеки...

Ну Вам конечно виднее. Вы же код писали - не я. Работает нормально. Третий час - без сбоев.
Эдди
Это оно без сбоев работает, пока не понадобилось еще что-то добавить. А там опять та же песня пойдет?
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.