haker_fox 61 26 июля, 2019 Опубликовано 26 июля, 2019 · Жалоба 2 hours ago, aaarrr said: И где в SLIP "хидер" с длиной? Так важно что-ли? Ну перепутал. Смысл вопроса-то в другом был. 43 minutes ago, Сергей Борщ said: В прерывании ПДП разгребать заголовок и перенастраивать ПДП на прием тела уже известной длины Кстати, да! Спасибо за идею! Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Сергей Борщ 143 26 июля, 2019 Опубликовано 26 июля, 2019 · Жалоба 1 час назад, esaulenka сказал: Сергей, а как вы это делаете? Ведь с ДМА, если не делать костыль "запускаем отправку в конце пакета" это получается ОЧЕНЬ неудобно! имею буфер, два указателя (при запуске указывают на начало буфера) и счетчик (при запуске обнулен). при добавлении данных увеличиваю один из указателей и счетчик. В прерывании по окончанию пересылки ПДП заряжаю новую пересылку, увеличиваю второй указатель на содержимое счетчика, счетчик обнуляю. Естественно, обрабатываю переход из конца буфера в начало. Не сказал бы, что ОЧЕНЬ неудобно. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 243 26 июля, 2019 Опубликовано 26 июля, 2019 · Жалоба 16 часов назад, Сергей Борщ сказал: Idle frame - это высокий уровень на линии приема в течении времени передачи одного байта (с учетом длительностей старта, стопа, четности): Если это действительно так, то тогда нет никакого толку от использования этого Idle frame для обнаружения пауз в RX-DMA. Ибо если скажем передатчик будет передавать слова данных с паузами между ними скажем длиной в одно слово, то на приёме будем получать прерывания Idle с частотой == 1/(2_длины_слова). А в этом случае теряется смысл от использования DMA на приём вообще. Так что без поллинга для работы с RX-DMA потоком для UART на STM32 - никак не обойтись. Конечно если по каналу идёт modbus, то в этом случае Idle поможет. В остальных случаях - нет. Так что работа с RX-DMA на STM32 будет такой же как на LPC - периодический поллинг. 2 часа назад, Сергей Борщ сказал: В прерывании ПДП разгребать заголовок и перенастраивать ПДП на прием тела уже известной длины. По прерыванию IDLE перезапускать все сначала. Ну да, а если скажем передатчик (а это независимое устройство видимо) перезапустился или по другой причине передумал продолжать передачу, то такой алгоритм спокойно повиснет навсегда. Прикладной уровень обработки протокола и уровень работы с потоком байт на уровне железа - должны быть независимы. И не надо смешивать мух с котлетами. ISR пишет в FIFO приёма (или перемещает его указатель) и затем пингует задачу, которая разбирает это FIFO, обрабатывая протокол обмена. И так - для любого протокола - стандартно и универсально. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
haker_fox 61 26 июля, 2019 Опубликовано 26 июля, 2019 · Жалоба 3 hours ago, jcxz said: по другой причине передумал продолжать передачу Так на этот случай нам и нужно прерывание "idle" от DMA. Если передачтик по какой-то причине перестал передавать, то в этом прерывании мы сможем принять адекватные действия. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 243 26 июля, 2019 Опубликовано 26 июля, 2019 · Жалоба 3 часа назад, haker_fox сказал: Так на этот случай нам и нужно прерывание "idle" от DMA. Если передачтик по какой-то причине перестал передавать, то в этом прерывании мы сможем принять адекватные действия. Это прерывание (IDLE) делает сомнительным само использование DMA. Зачем Вам тогда DMA? Цель использования DMA вместо прямого IO в порты в ISR: не дёргаться на каждый байт, а значит -> снизить загрузку CPU. Но если скажем передающая сторона станет слать байты с дыркой между ними равной или больше длины символа, то получаем частоту прерываний IDLE всего в 2 раза ниже частоты символов. Т.е. - на 921600 бод получим 92160/2 = ~46кГц. Вот с такой частотой и будете "перезапускать всё сначала". Я об этом писал выше. Конечно передающая сторона не обязательно будет передавать с дырками. Но может, так как имеет право, ибо UART - это асинхронный интерфейс. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
AHTOXA 18 26 июля, 2019 Опубликовано 26 июля, 2019 · Жалоба 26 минут назад, jcxz сказал: Но если скажем передающая сторона станет слать байты с дыркой между ними равной или больше длины символа А зачем она так станет делать? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 243 26 июля, 2019 Опубликовано 26 июля, 2019 · Жалоба 1 час назад, AHTOXA сказал: А зачем она так станет делать? просто так. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
AHTOXA 18 26 июля, 2019 Опубликовано 26 июля, 2019 · Жалоба 10 минут назад, jcxz сказал: просто так. И как в таком случае вам поможет NXP-шный UART? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться