roboforum.ru

Вообще-то ногодрыганьем должны заниматься постпроцессоры да хоть ардуины. Это так сказать спинной мозг станка или робота. С ними связь можно организовать по-разному, но мне нравится UART и подобное. А всякими тяжеловесными но не такими реалтаймовыми делами, у которых каждый такт на счету, пусть занимается бортовой компьютер. И этот компьютер может быть маленьким и славбеньким или большим и мощным или чем-то средним в зависимости от задачи. Ведь операционок с по-настоящему жестким реалтаймом ширпотребных вроде как нет.

ИМХО, по нынешним временам, если есть такая задача "у которой каждый такт на счету", то на эту задачу можно поставить и отдельный компутер.
Мысль об арджунке как "спинном мозге" мне тоже в голову приходила, хотя я бы её скорее "насекомой ганглией" обозвал

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

Постпроцессоров можно подключить несколько к одному центральному процу. Тогда и ножек и тактов хватит. Центральный комп нужен такой, чтобы в мягком реалтайме выполнять основные операции. И центральный процессор также можно разделить на несколько отвечающих за отдельные функции процессоры. Но это нужно делать тогда, когда такое разделение действительно дает выигрыш. Ведь появятся накладные расходы по обмену информацией между такими процессорами.

... т.о. снова возвращаемся к теме оптимального кода.
Потому, что если использовать стандартные (индусские ?) библиотеки, вы, в конечном итоге, и будете постоянно упираться в их быстродействие, а отнюдь не железа.
Напр., мосты USB-UART (PL2303HX) вполне нормально работают на 12Mbs.
Но кто-нибудь использовал их в таком режиме ?

Я что-то от мостов не в восторге. Стараюсь не работать с USB. Просто UART. Видимо сказывается боязнь косячных драйверов.

Ну вот Какой смысл тогда говорить о (возможной) недостаточной скорости обмена между цпу и периферией, если выше "стандартных" 115200 как бы и не было причины подыматься.
А между тем, там ничего не косячит, во всяком случае, на 6MBs все работает неделями без каких-либо багов и зависонов.

Как бы мне донести правильно мои соображения. Чаще всего в МК имеется UART. И программа, управляющая этим МК также чаще всего работает с UART. Но т.к. в компе уже почти не ставят их, а имеется множество USB, то пользуются виртуальным UART. Получается несколько преобразований информации:
Программа компьютера->Драйвер виртуального UART->Драйвер USB->Передача по кабелю USB->Преобразователь USB-UART->Получение программой МК данных от программы компьютера.
В случае с только UART несмотря на меньшую скорость передачи преобразований меньше. Есть еще одно - это временной лаг между выдачей компьютером и получением информации МК. В случае с мостом задержка может быть немаленькой из-за всей этой длинной цепочки преобразований и из-за, например, пакетной обработки драйверами ОС.
И последнее, USB создавался в качестве отпрыска AplleTalk - настольной простенькой сети, соединяющей медленные устройства вроде клавиатуры и мыши. Потом только стали увеличивать скорость передачи. UART же был и остается одним из промышленных коммуникационных средств. Да и расстояния, на которых он работает, гораздо больше, чем USB. Я помню как одно время мы все время маялись с подбором USB кабелей к принтерам. Шалили они, однако.
Появился промышленный USB и даже оптический, но все проблемы USB это не решило.
При правильной постановке дела от центрального процессора к постпроцессору можно передавать очень небольшой объем командной информации и получать краткие ответы от него.

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

Внутрисистемные междумордия - вообще больной зуб.

Понятно, что там где арджунка, там UART и ни чего тут не поделать.
Но покажите же мне этот "центральный компьютер" из которого бы торчал десяток... ну ладно, хотя бы штуки три UART`а???

Значит, не UART... А значит не просто арджунка, а с нашлёпкой

уарт обычно один. вместо трёх выдают попользоваться губозакаточной или предлагают купить немного юсб-уартов.
арджунки... опять махабхарату читали?

>Но покажите же мне этот "центральный компьютер" из которого бы торчал десяток... ну ладно, хотя бы штуки три UART`а???
Зачем три уарта? Быстрый I2C не? CAN?

А тогда здравствуй сверху 24LS256 или что наподобие.
Я не против... Я не против. Но... больной зуб

10 уартов, 20 gpio, 30 can`ов, 100 ethernet`ов,... кто больше? это тараканчики в голове, ну не прикалывайтесь. к мк, когда очень нужно, можно докидывать микры "quad serial uart", они частенько или с isp или c i2c интерфейсом. не факт, что не будет дешевле и проще ещё один мк прикрутить, у которого 4 или 6 уарта. для компа, если мало свободных юсб, так есть хабы и для богатых буратин что-то на подобии ft4232h. про цайпресовские камушки и прочие варианты вообще молчу.

Я совсем не против USB. Я против многократного преобразования информации в интерфейсной части. Если в МК имеется аппаратный USB, то конечно, нужно через него подключаться. Но если можно выбирать, то нужно брать те, которые более так сказать реалтаймистее. Все же понимают, что TCP имеет значительные задержки по причине наличия TCP стека.
Извините за оффтоп, но мне вспомнилось, как я для наиболее успешно продаваемых наших самодельных спектрумподобных компьютеров разработал в 1991 году еще до появления USB собственный последовательный интерфейс. Разъемами были круглые 5 штырьковые от старых магнитофонов. Он обеспечивал питание простой периферии прямо через интерфейсный кабель. Интерфейс поддерживал горячее подключение и мы наладили изготовление и продажу флешечных картирджей с программами в них. Мы в них помногу разнообразных игр упаковывали. Доходило до смешного. Иногда много детей - владельцев наших компьютеров в одном и том же многоэтажном доме загружали поочередно с одного нашего картриджа игры. Разработал я также и модуль энергонезависимой внешней оперативной памяти в виде картриджа к этому интерфейсу. И подключал разную периферию. Т.к. протокол поддерживал до 256 устройств, то можно было гирляндой или звездой навешивать множество периферии на один порт. Для этого я разработал специальный расширительный хаб.
Для устройств массовой памяти был специальный автоинкрементный режим. Счетчик адресов, находящийся в картридже автоматически приращивал адрес выбираемой ячейки памяти. Т.к. тогда дешевых МК не было, картриджи собиралось на малом количестве простой логики и микросхеме памяти. Картридж упаковывался в небольшую коробочку.
Чтобы не подумали что я все тут напридумал, вот нашел навскидку одно из обсуждений наших тогдашних разработок.
http://zx-pk.ru/showthread.php?t=255&highlight=%2525EE%2525F2%2525E5%2525F7%2525E5%2525F1%2525F2%2525E2%2525E5%2525ED%2525ED%2525EE%2525E3%2525EE&page=65
А здесь в википедии про этот компьютер тоже есть ссылка:
[url]https://ru.wikipedia.org/wiki/Клоны_ZX_Spectrum#Patisonic[/url]

мысль темы я потерял
но вот это высказывание абсолютно верное !

Виктор Казаринов писал(а):Получается несколько преобразований информации:
Программа компьютера->Драйвер виртуального UART->Драйвер USB->Передача по кабелю USB->Преобразователь USB-UART->Получение программой МК данных от программы компьютера.
В случае с только UART несмотря на меньшую скорость передачи преобразований меньше. Есть еще одно - это временной лаг между выдачей компьютером и получением информации МК. В случае с мостом задержка может быть немаленькой из-за всей этой длинной цепочки преобразований и из-за, например, пакетной обработки драйверами ОС.

Добавлено спустя 2 минуты 5 секунд:
в проектировании вычислительных кластеров это называется увеличение латентности и приводит к падению производительности.
кстати на некоторых типах задач обходится пакетированием (посылаем данных больше и заранее)