Сергей Борщ 134 25 июля, 2019 Опубликовано 25 июля, 2019 · Жалоба 8 часов назад, esaulenka сказал: У NXP вообще всё лучше было сделано. И уарты Это которые аналог 16c550? Что в них лучшего, у них нет даже прерывания по окончанию передачи (именно передачи, а не освобождению FIFO), нет возможности узнать реальное заполнение FIFO, только два признака - "пуст" и "полон". Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 235 25 июля, 2019 Опубликовано 25 июля, 2019 · Жалоба 3 минуты назад, Сергей Борщ сказал: Это которые аналог 16c550? Что в них лучшего, у них нет даже прерывания по окончанию передачи (именно передачи, а не освобождению FIFO), нет возможности узнать реальное заполнение FIFO, только два признака - "пуст" и "полон". Зато есть FIFO! А это - многого стоит! Ибо позволяет работать на высоких скоростях без DMA. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Сергей Борщ 134 25 июля, 2019 Опубликовано 25 июля, 2019 · Жалоба 8 минут назад, jcxz сказал: Ибо позволяет работать на высоких скоростях без DMA. Меня работа с ПДП не напрягает. В FIFO надо грузить вручную, да еще и проверяя "а влезет ли еще и этот байтик" или дожидаться его опустошения перед началом передачи очередной порции. ПДП копирования не требует, "пустил-забыл". В общем маялся я с этим УАПП в LPC2214 лет десять, удовольствия так и не получил. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 235 25 июля, 2019 Опубликовано 25 июля, 2019 · Жалоба 8 минут назад, Сергей Борщ сказал: Меня работа с ПДП не напрягает. В FIFO надо грузить вручную, да еще и проверяя "а влезет ли еще и этот байтик" или дожидаться его опустошения перед началом передачи очередной порции. Ничего там сложного: если FIFO опустошилось - пишем в него <= FIFO_SIZE байт. Пока не опустошилось - не пишем ничего. 8 минут назад, Сергей Борщ сказал: ПДП копирования не требует, "пустил-забыл". В общем маялся я с этим УАПП в LPC2214 лет десять, удовольствия так и не получил. Ну да, только с RX-DMA (на STM32) нужно ещё реализовать его периодический поллинг когда не известен размер принимаемых данных. Вроде бы для обнаружения завершения передачи (о чём Вы писали) есть битик и прерывание, но поллинг всё равно нужен. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Сергей Борщ 134 25 июля, 2019 Опубликовано 25 июля, 2019 · Жалоба 1 час назад, jcxz сказал: Пока не опустошилось - не пишем ничего Браво. Аплодисменты. Это и есть то самое "работать на высоких скоростях без DMA"? Я же не против FIFO, но зачем было спустя 20 лет драть x550 один-в-один? Сделали бы регистр заполненности FIFO, было бы удобно. А так убожество какое-то получилось. От чего тут пИсать кипятком и чем это лучше чем УАПП у того же STM (вопрос риторический)? 1 час назад, jcxz сказал: Ну да, только с RX-DMA (на STM32) нужно ещё реализовать его периодический поллинг когда не известен размер принимаемых данных. У УАПП для этого случая есть битик и прерывание IDLE. Чем тут помогает FIFO у LPC я снова не понял. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
esaulenka 7 25 июля, 2019 Опубликовано 25 июля, 2019 · Жалоба 3 hours ago, Сергей Борщ said: у них нет даже прерывания по окончанию передачи Я забыл уже. Да, кажется, Вы правы. Но 485 я в живом виде видел только один раз (и там уже был STM32F4), а с обычным 232 этот бит и не нужен был... 3 hours ago, Сергей Борщ said: нет возможности узнать реальное заполнение FIFO Я 2214 не застал, а в 2368/1768, насколько помню, добавили флажок с состоянием FIFO. Ну и каюсь: DMA на UART'ах так и не запустил. Приём делает какой-нибудь конечный автомат, его в любом случае побайтно надо кормить. Скорости выше 115200 тоже как-то не использовали никогда - для больших объемов более удобные интерфейсы есть. Так и дрыгаются эти прерывания на приём. А где приём, там и передачу можно запустить, это ещё десяток строчек. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 235 25 июля, 2019 Опубликовано 25 июля, 2019 · Жалоба 4 часа назад, Сергей Борщ сказал: Сделали бы регистр заполненности FIFO, было бы удобно. Непонятно зачем Вам сдался этот "регистр заполненности"? И почему без него никак? Сколько писал для LPC-шек разных драйверов - нужды в нём не ощущал. 4 часа назад, Сергей Борщ сказал: От чего тут пИсать кипятком и чем это лучше чем УАПП у того же STM (вопрос риторический)? Сравните: для передачи одного байта без FIFO нужно войти в прерывание, записать байт, выйти из прерывания. Итого: на передачу одного байта нужно несколько десятков тактов. С FIFO эти десятки тактов размазываются на 16 слов FIFO. Т.е. - накладные расходы в разы меньше. 4 часа назад, Сергей Борщ сказал: У УАПП для этого случая есть битик и прерывание IDLE. Чем тут помогает FIFO у LPC я снова не понял. И как этот битик использовать? Из мануала на STM32F4 этого совершенно не понять. Судя по мануалу там должен посылаться некий Idle frame (цитата): It wakes up when an Idle frame is detected. Если бы это прерывание генерилось, когда RX-линия находится в простое N-ое количество времени, то да - можно было бы использовать. Но если там какой-то кадр надо посылать, то - ну его нафиг. 3 часа назад, esaulenka сказал: Я забыл уже. Да, кажется, Вы правы. Но 485 я в живом виде видел только один раз (и там уже был STM32F4), а с обычным 232 этот бит и не нужен был... Прерывание по окончанию передачи не обязательно нужно для RS-485. Иногда ещё бывают батарейные устройства, которым нужно уснуть по завершении передачи. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 235 25 июля, 2019 Опубликовано 25 июля, 2019 · Жалоба 3 часа назад, esaulenka сказал: Скорости выше 115200 тоже как-то не использовали никогда - для больших объемов более удобные интерфейсы есть. Осталось только производителей разных микросхем убедить перевести их на эти "более удобные" с UART-а. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Сергей Борщ 134 25 июля, 2019 Опубликовано 25 июля, 2019 · Жалоба 4 минуты назад, jcxz сказал: Непонятно зачем Вам сдался этот "регистр заполненности"? Чтобы одним чтением узнать, сколько байтов я могу запихать в это FIFO без всяких дополнительных проверок и спокойно уйти заниматься другими делами до прерывания об опустошении FIFO, в котором уже записывать в FIFO остаток. 8 минут назад, jcxz сказал: С FIFO эти десятки тактов размазываются на 16 слов FIFO. Т.е. - накладные расходы в разы меньше. С ПДП эти десятки тактов размазываются на три записи в регистры: откуда, сколько и, собственно, "поехали". При этом байтов может быть существенно больше 16. 10 минут назад, jcxz сказал: И как этот битик использовать? Из мануала на STM32F4 этого совершенно не понять. Судя по мануалу там должен посылаться некий Idle frame (цитата): It wakes up when an Idle frame is detected. Да, описания у ST не всегда понятны. Idle frame - это высокий уровень на линии приема в течении времени передачи одного байта (с учетом длительностей старта, стопа, четности): Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 235 25 июля, 2019 Опубликовано 25 июля, 2019 · Жалоба 11 минут назад, Сергей Борщ сказал: Чтобы одним чтением узнать, сколько байтов я могу запихать в это FIFO без всяких дополнительных проверок и спокойно уйти заниматься другими делами до прерывания об опустошении FIFO, в котором уже записывать в FIFO остаток. Размер FIFO - известен. Получили прерывание о его опустошении -> пишем количество байт <= размеру_FIFO. И всё. И так - до следующего прерывания об опустошении -> в котором опять пишем <=FIFO_SIZE байт. И никаких состояний FIFO не нужно. Написать: uint i = MIN(dataSize, 16); dataSize -= i; do uart->DR = *data++; while (--i); что-ли сложно? 11 минут назад, Сергей Борщ сказал: С ПДП эти десятки тактов размазываются на три записи в регистры: откуда, сколько и, собственно, "поехали". При этом байтов может быть существенно больше 16. Никто не спорит про ПДП. И в LPC он тоже есть. Но есть и FIFO. А в STM32 - только ПДП. Что не всегда удобно/нужно так как более громоздко и занимает эти самые ПДП-каналы, которых тоже не очень много. На прошлой работе у меня были проекты содержавшие по 5-6 UART-ов. И это кроме прочей периферии. DMA-каналов на обслуживание всего этого не хватит ни в одном STM32. Поэтому (одна из причин) и отказались там от STM32. Взяли МК с нормальным FIFO в UART-ах и написали драйвера без DMA, оставив их для быстрой периферии. Вобщем - всегда лучше когда есть и то и другое, чем когда нет выбора. 11 минут назад, Сергей Борщ сказал: Да, описания у ST не всегда понятны. Idle frame - это высокий уровень на линии приема в течении времени передачи одного байта (с учетом длительностей старта, стопа, четности): Ок, надо будет глянуть внимательнее его когда снова вернусь к проекту на STM32F4. Когда писал соответствующие драйвера на STM32F4, то из мануала я не понял работу этого Idle line и поэтому повесил поиск дырки в приёме на поллинг по таймеру. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
haker_fox 61 26 июля, 2019 Опубликовано 26 июля, 2019 · Жалоба 11 hours ago, esaulenka said: Ну и каюсь: DMA на UART'ах так и не запустил Запускал (давно), но только на передачу. Скорость была 921 кбит. На передачу запустить несложно, ибо знаем сколько передавать. А вот с приёмом что делать? Насколько я понимаю, невозможно заставить DMA парсить "хидер" пакета, вытащить оттуда количество байт данных, и настроиться на приём оных. Естественно, я подразумеваю пакетную передачу, по типу протокола Wake, Slip и т.п. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
aaarrr 69 26 июля, 2019 Опубликовано 26 июля, 2019 · Жалоба 3 hours ago, haker_fox said: Slip И где в SLIP "хидер" с длиной? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Сергей Борщ 134 26 июля, 2019 Опубликовано 26 июля, 2019 · Жалоба 13 часов назад, jcxz сказал: Размер FIFO - известен. Получили прерывание о его опустошении -> пишем количество байт <= размеру_FIFO. И всё. И так - до следующего прерывания об опустошении -> в котором опять пишем <=FIFO_SIZE байт. И никаких состояний FIFO не нужно. Написать: uint i = MIN(dataSize, 16); dataSize -= i; do uart->DR = *data++; while (--i); что-ли сложно? Да, почти так и приходилось делать. Но я люблю есть слона по частям: отправлять пакет прямо по мере его формирования. Сначала послать "Слава мне", а потом " - победителю драконов!". Поэтому мне приходилось иметь отдельный счетчик "сколько байтов я уже запихнул", который увеличивался с записью каждого байта в FIFO и сбрасывался в прерывании по опустошению FIFO. По этому счетчику я мог примерно определить, сколько байтов я могу еще должить в FIFO не дожидаясь прерывания об его опустошении (на то ведь оно и FIFO, чтобы докладывать не дожидаясь, правда?). Примерно - потому что этот счетчик не мог учесть, сколько из засунутых байтов уже передано. Если бы я мог получить от УАПП информацию о свободном месте в FIFO, этот костыль был бы не нужен. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Сергей Борщ 134 26 июля, 2019 Опубликовано 26 июля, 2019 · Жалоба 5 часов назад, haker_fox сказал: А вот с приёмом что делать? Насколько я понимаю, невозможно заставить DMA парсить "хидер" пакета, вытащить оттуда количество байт данных, и настроиться на приём оных. Настраивать ПДП на размер заголовка с полем длины включительно и задействовать прерывание IDLE, которое будет срабатывать если принято меньше, чем размер заголовка. В прерывании ПДП разгребать заголовок и перенастраивать ПДП на прием тела уже известной длины. По прерыванию IDLE перезапускать все сначала. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
esaulenka 7 26 июля, 2019 Опубликовано 26 июля, 2019 · Жалоба 22 minutes ago, Сергей Борщ said: Но я люблю есть слона по частям: отправлять пакет прямо по мере его формирования. Сначала послать "Слава мне", а потом " - победителю драконов!". Сергей, а как вы это делаете? Ведь с ДМА, если не делать костыль "запускаем отправку в конце пакета" это получается ОЧЕНЬ неудобно! Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться