Jump to content

    
Sign in to follow this  
Сергей Борщ

Чем УАПП(UART) от NXP лучше УАПП от ST

Recommended Posts

2 hours ago, aaarrr said:

И где в SLIP "хидер" с длиной?

Так важно что-ли? Ну перепутал. Смысл вопроса-то в другом был.

43 minutes ago, Сергей Борщ said:

В прерывании ПДП разгребать заголовок и перенастраивать ПДП на прием тела уже известной длины

Кстати, да! Спасибо за идею!

Share this post


Link to post
Share on other sites
1 час назад, esaulenka сказал:

Сергей, а как вы это делаете? Ведь с ДМА, если не делать костыль "запускаем отправку в конце пакета" это получается ОЧЕНЬ неудобно!

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

при добавлении данных увеличиваю один из указателей и счетчик. В прерывании по окончанию пересылки ПДП заряжаю новую пересылку, увеличиваю второй указатель на содержимое счетчика, счетчик обнуляю. Естественно, обрабатываю переход из конца буфера в начало. Не сказал бы, что ОЧЕНЬ неудобно.

Share this post


Link to post
Share on other sites
16 часов назад, Сергей Борщ сказал:

Idle frame - это высокий уровень на линии приема в течении времени передачи одного байта (с учетом длительностей старта, стопа, четности):

Если это действительно так, то тогда нет никакого толку от использования этого Idle frame для обнаружения пауз в RX-DMA. Ибо если скажем передатчик будет передавать слова данных с паузами между ними скажем длиной в одно слово, то на приёме будем получать прерывания Idle с частотой == 1/(2_длины_слова). А в этом случае теряется смысл от использования DMA на приём вообще.

Так что без поллинга для работы с RX-DMA потоком для UART на STM32 - никак не обойтись. Конечно если по каналу идёт modbus, то в этом случае Idle поможет. В остальных случаях - нет.

Так что работа с RX-DMA на STM32 будет такой же как на LPC - периодический поллинг.

2 часа назад, Сергей Борщ сказал:

В прерывании ПДП разгребать заголовок и перенастраивать ПДП на прием тела уже известной длины. По прерыванию IDLE перезапускать все сначала.

Ну да, а если скажем передатчик (а это независимое устройство видимо) перезапустился или по другой причине передумал продолжать передачу, то такой алгоритм спокойно повиснет навсегда.  :biggrin:

Прикладной уровень обработки протокола и уровень работы с потоком байт на уровне железа - должны быть независимы. И не надо смешивать мух с котлетами. ISR пишет в FIFO приёма (или перемещает его указатель) и затем пингует задачу, которая разбирает это FIFO, обрабатывая протокол обмена. И так - для любого протокола - стандартно и универсально.

Share this post


Link to post
Share on other sites
3 hours ago, jcxz said:

по другой причине передумал продолжать передачу

Так на этот случай нам и нужно прерывание "idle" от DMA. Если передачтик по какой-то причине перестал передавать, то в этом прерывании мы сможем принять адекватные действия.

Share this post


Link to post
Share on other sites
3 часа назад, haker_fox сказал:

Так на этот случай нам и нужно прерывание "idle" от DMA. Если передачтик по какой-то причине перестал передавать, то в этом прерывании мы сможем принять адекватные действия.

Это прерывание (IDLE) делает сомнительным само использование DMA. Зачем Вам тогда DMA?

Цель использования DMA вместо прямого IO в порты в ISR: не дёргаться на каждый байт, а значит -> снизить загрузку CPU. Но если скажем передающая сторона станет слать байты с дыркой между ними равной или больше длины символа, то получаем частоту прерываний IDLE всего в 2 раза ниже частоты символов. Т.е. - на 921600 бод получим 92160/2 = ~46кГц. Вот с такой частотой и будете "перезапускать всё сначала". 

Я об этом писал выше. Конечно передающая сторона не обязательно будет передавать с дырками. Но может, так как имеет право, ибо UART - это асинхронный интерфейс.

Share this post


Link to post
Share on other sites
26 минут назад, jcxz сказал:

Но если скажем передающая сторона станет слать байты с дыркой между ними равной или больше длины символа

А зачем она так станет делать?

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this