[1891ВМ12Я 0]

Мы используем Миландровский 1986ВЕ1Т с тактовой 144 МГц. На такой частоте по Вашей оценке можно реализовать программный контроллер RS-485 со скоростью 2 Мбит/с?

Вы это серьезно? Я думал это технический сайт, а не юмористический :)

[@Ark 0]

2 МБод на 144МГц тактовой? Может как-то и получится, но думаю процессор только этим и будет заниматься.

От загрузки канала зависит. Сколько времени идет прием/передача, столько и будет отвлекаться на это процессор. Плюс небольшие накладные расходы.

Если по RS485 идет сплошной поток в ту или другую сторону, то на остальное времени почти не останется...

Изменено 18 ноября, 2017 пользователем @Ark

[jcxz 184]

От загрузки канала зависит. Сколько времени идет прием/передача, столько и будет отвлекаться на это процессор.

А если канал сильно недогружен, то может имеет смысл во столько же раз уменьшить скорость?

А если не уменьшили, то видимо нельзя - не успевают передавать.

Так что мимо кассы - процессор должен уметь принять и непрерывный поток.

[Edit2007 3]

Мы используем Миландровский 1986ВЕ1Т с тактовой 144 МГц. На такой частоте по Вашей оценке можно реализовать программный контроллер RS-485 со скоростью 2 Мбит/с?

Спасибо за ответы, только у Миландра - это приемопередатчики, а нужен бы специализированный контроллер. Почему не можем использовать UART - потому что скорости не хватает - 921600 бод, а нам надо около 2 Мбит (RS-485 с такими скоростями позволяет работать)

У вас наверняка устаревшие данные. В описании сказано UART до 9 Мбит/сек, IrDA 460800 Мбит/сек. (Описание от 31.01.2014 г. стр 323)

Изменено 20 ноября, 2017 пользователем редактор

[@Ark 0]

А если канал сильно недогружен, то может имеет смысл во столько же раз уменьшить скорость?

Не всегда.

Например, для внешнего устройства, работающего в связке с ПК, зачастую предпочтительнее быстро передать пакет данных на высокой скорости. Чтобы освободить линию связи и собственные ресурсы МК до передачи следующего пакета. А не растягивать этот процесс на низкой скорости.

А когда устройств на линии предполагается много, то их максимальное количество будет напрямую зависеть от выбранной скорости обмена. "Сильно недогруженный канал" с точки зрения МК, "догружается" другими устройствами на линии, вплоть до непрерывного потока. ;)

 

 

[jcxz 184]

А когда устройств на линии предполагается много, то их максимальное количество будет напрямую зависеть от выбранной скорости обмена. "Сильно недогруженный канал" с точки зрения МК, "догружается" другими устройствами на линии, вплоть до непрерывного потока. ;)

И что?

Эти данные, передаваемые "другими устройствами" будут также поступать на вход RX микроконтроллера и загружать его процедурой приёма байт.

В чём разница-то?

Ситуация даже хуже получается: даже когда к устройству нет обращений от ПК, его процессор всё равно будет сильно загружен приёмом чужих обменов.

[richie 0]

...

Почему не можем использовать UART - потому что скорости не хватает - 921600 бод,

...

а нам надо около 2 Мбит

...

(RS-485 с такими скоростями позволяет работать)

Контроллеру среда передачи пофигу должна быть, хоть RS-232, хоть RS-485, хоть RS-422.

Зависит от устройства и способов его использования.

Уровень приложения знать не должен, какая среда используется.

Только максимум в драйвере протокола может быть управление направлением передачи.

 

P.S. С каких пор полудуплекс стал быстрее полного дуплекса?

[@Ark 0]

И что?

Эти данные, передаваемые "другими устройствами" будут также поступать на вход RX микроконтроллера и загружать его процедурой приёма байт.

В чём разница-то?

Разница в том, что линия связи освобождается для работы других устройств.

МК, конечно, придется анализировать поток на линии. Чем он, в основном, и будет заниматься. Когда придет запрос, адресованный именно данному устройству, он обрабатывается, передается ответ. А дальше устройство снова "курит бамбук", анализируя линию и ожидая следующего запроса. Это достаточно часто встречающаяся ситуация...

 

 

[jcxz 184]

А дальше устройство снова "курит бамбук", анализируя линию и ожидая следующего запроса. Это достаточно часто встречающаяся ситуация...

Я Вам говорю о том, что это "курит бамбук" при программном UART-е на 2МБод-а выльется в очень большую загрузку CPU. Что уже как-то не похоже на "курит бамбук".

И как раз часто встречающаяся ситуация, когда устройство занимается ещё чем-то, кроме того, что ждёт запроса от ПК. Оно же для чего-то создавалось, чтобы выполнять какую-то работу, а не просто "курить бамбук".

И при программном UART-е 2МБод оно будет в основном заниматься анализом потока на линии, как Вы правильно заметили. И на другие (полезные) дела ресурсов уже не останется.

 

P.S. С каких пор полудуплекс стал быстрее полного дуплекса?

Как Вы себе представляете полный дуплекс на 2х-проводном RS-485 (автор вроде его имел в виду) ?

[@Ark 0]

И при программном UART-е 2МБод оно как раз будет в основном заниматься анализом потока на линии, как Вы правильно заметили. И на другие (полезные) дела ресурсов уже не останется.

.. За исключением случаев, когда "полезные дела" выполняются устройством только "по команде" (по запросу). Что, поверьте, не редкость...

Устройства разные бывают, в том числе совсем простые, с очень ограниченными ресурсами. И их может быть много на одной линии. Ставить в каждое процессор с аппаратной поддержкой 2Мбит по UART не всегда рационально. Вот тогда программный UART рулит...

 

 

[Obam 30]

…IrDA 460800 Мбит/сек

? 450Гбит/с ??? Запятая где, всё-таки, должна стоять?

[VCucumber 0]

450Гбит/с ???

ну это же православный контроллер

 

[Obam 30]

ну это же православный контроллер

Да ладно гнать, ядро бесовскОе-англичанское (;

[mantech 35]

Разница в том, что линия связи освобождается для работы других устройств.

МК, конечно, придется анализировать поток на линии. Чем он, в основном, и будет заниматься. Когда придет запрос, адресованный именно данному устройству, он обрабатывается, передается ответ. А дальше устройство снова "курит бамбук", анализируя линию и ожидая следующего запроса. Это достаточно часто встречающаяся ситуация...

 

Часто, но на более медленных скоростях, когда "долбежка" проца не отнимает много времени. Для скоростной связи с компом лучше выбрать другой интерфейс, например еще один уарт(485), усб или эзернет, как уже говорил.

 

Вот тогда программный UART рулит...

 

Только тогда, когда нет никакой возможности использовать аппаратный порт.

Изменено 20 ноября, 2017 пользователем mantech

[@Ark 0]

... Для скоростной связи с компом лучше выбрать другой интерфейс, например еще один уарт(485), усб или эзернет, как уже говорил.

... Только тогда, когда нет никакой возможности использовать аппаратный порт.

Еще один RS485 - это еще одна линия...

USB - это только для "настольных игр"...

Эзернет... - про цену вопроса не забывайте.

И умножьте ее, скажем, на 100 (устройств в линии)... ;)