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

8 часов назад, esaulenka сказал:

У NXP вообще всё лучше было сделано. И уарты

Это которые аналог 16c550? Что в них лучшего, у них нет даже прерывания по окончанию передачи (именно передачи, а не освобождению FIFO), нет возможности узнать реальное заполнение FIFO, только два признака - "пуст" и "полон".

[jcxz 184]

3 минуты назад, Сергей Борщ сказал:

Это которые аналог 16c550? Что в них лучшего, у них нет даже прерывания по окончанию передачи (именно передачи, а не освобождению FIFO), нет возможности узнать реальное заполнение FIFO, только два признака - "пуст" и "полон".

Зато есть FIFO! А это - многого стоит! Ибо позволяет работать на высоких скоростях без DMA.

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

8 минут назад, jcxz сказал:

Ибо позволяет работать на высоких скоростях без DMA.

Меня работа с ПДП не напрягает. В FIFO надо грузить вручную, да еще и проверяя "а влезет ли еще и этот байтик" или дожидаться его опустошения перед началом передачи очередной порции. ПДП копирования не требует, "пустил-забыл". В общем маялся я с этим УАПП в LPC2214 лет десять, удовольствия так и не получил.

[jcxz 184]

8 минут назад, Сергей Борщ сказал:

Меня работа с ПДП не напрягает. В FIFO надо грузить вручную, да еще и проверяя "а влезет ли еще и этот байтик" или дожидаться его опустошения перед началом передачи очередной порции.

Ничего там сложного: если FIFO опустошилось - пишем в него <= FIFO_SIZE байт. Пока не опустошилось - не пишем ничего.

8 минут назад, Сергей Борщ сказал:

ПДП копирования не требует, "пустил-забыл". В общем маялся я с этим УАПП в LPC2214 лет десять, удовольствия так и не получил.

Ну да, только с RX-DMA (на STM32) нужно ещё реализовать его периодический поллинг когда не известен размер принимаемых данных. Вроде бы для обнаружения завершения передачи (о чём Вы писали) есть битик и прерывание, но поллинг всё равно нужен.  

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

1 час назад, jcxz сказал:

Пока не опустошилось - не пишем ничего

Браво. Аплодисменты. Это и есть то самое "работать на высоких скоростях без DMA"? Я же не против FIFO, но зачем было спустя 20 лет драть x550 один-в-один? Сделали бы регистр заполненности FIFO, было бы удобно. А так убожество какое-то получилось. От чего тут пИсать кипятком и чем это лучше чем УАПП у того же STM (вопрос риторический)?

1 час назад, jcxz сказал:

Ну да, только с RX-DMA (на STM32) нужно ещё реализовать его периодический поллинг когда не известен размер принимаемых данных.

У УАПП для этого случая есть битик и прерывание IDLE. Чем тут помогает FIFO у LPC я снова не понял.

[esaulenka 5]

3 hours ago, Сергей Борщ said:

у них нет даже прерывания по окончанию передачи

Я забыл уже. Да, кажется, Вы правы. Но 485 я в живом виде видел только один раз (и там уже был STM32F4), а с обычным 232 этот бит и не нужен был...

3 hours ago, Сергей Борщ said:

нет возможности узнать реальное заполнение FIFO

Я 2214 не застал, а в 2368/1768, насколько помню, добавили флажок с состоянием FIFO.

 

Ну и каюсь: DMA на UART'ах так и не запустил. Приём делает какой-нибудь конечный автомат, его в любом случае побайтно надо кормить. Скорости выше 115200 тоже как-то не использовали никогда - для больших объемов более удобные интерфейсы есть. Так и дрыгаются эти прерывания на приём. А где приём, там и передачу можно запустить, это ещё десяток строчек.

[jcxz 184]

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 184]

3 часа назад, esaulenka сказал:

Скорости выше 115200 тоже как-то не использовали никогда - для больших объемов более удобные интерфейсы есть.

Осталось только производителей разных микросхем убедить перевести их на эти "более удобные" с UART-а.  

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

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 184]

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 60]

11 hours ago, esaulenka said:

Ну и каюсь: DMA на UART'ах так и не запустил

Запускал (давно), но только на передачу. Скорость была 921 кбит. На передачу запустить несложно, ибо знаем сколько передавать. А вот с приёмом что делать? Насколько я понимаю, невозможно заставить DMA парсить "хидер" пакета, вытащить оттуда количество байт данных, и настроиться на приём оных. Естественно, я подразумеваю пакетную передачу, по типу протокола Wake, Slip и т.п.

[aaarrr 63]

3 hours ago, haker_fox said:

Slip

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

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

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, этот костыль был бы не нужен.

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

5 часов назад, haker_fox сказал:

А вот с приёмом что делать? Насколько я понимаю, невозможно заставить DMA парсить "хидер" пакета, вытащить оттуда количество байт данных, и настроиться на приём оных.

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

[esaulenka 5]

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

Но я люблю есть слона по частям: отправлять пакет прямо по мере его формирования. Сначала послать "Слава мне", а потом " - победителю драконов!".

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