Преобразовать 128 ТТЛ в 8

[Falconist]

Сама мысля правильная, но как синхронизацию делать будете?

[omercury]

иду на таран - две ПЛИС (по одной - прием/передача) и вся логика внутри

Это самый быстрый вариант, только "голуба" всё затормозит.

это немецкая вязальная промышленная машина, по игольнице ездит каретка, к которой идет куча проводов.

Я боюсь, что эта затея вообще не прокатит - собьётся синхронизация положения каретки с управляющими сигналами. По крайней мере с блютузом и UART - точно.
ПЛИС в данной ситуации может прокатить(хотя не уверен - в реальном времени работает), только от быстрой линии передачи всё равно не избавиться. Может оптоволокно спасёт?

UPD.
Одного только не пойму - как немцам удалось организовать такую ненадёжную линию связи?
У нас ЧПУ с прошлого тысячелетия работают...

[jump]

как немцам удалось организовать такую ненадёжную линию связи?

может она и шьет только эти линии, чтоб меняли

У нас ЧПУ с прошлого тысячелетия работают...

так может она 19го века

есть немало самосинхронизирующихся протоколов, начиная от ПДУ телевизоров, в ПЛИС может поместиться и софт-МК с приемопередатчиком (не радио), например, встроенный LVDS (подобное применяют как DVI/HDMI) или быстрый внешний RS-485 (до 20-30Мбит)

[lviv21]

Про Мегу8515/8535 уже jump говорил, а к ней можно еще 4 шт 8255 добавить. Дешево и сердито, хоть и старовато.

[evg111]

Утро всем доброе!
ПЛИС - это хорошо, но неосвояемо тогда уж лучше по 2 проводам DTMF гудеть

к сожалению, "8 групп по 16 контактов" тоже не получится - uart в блюсусе 8-битный.

Вариант Falconist`а в редакции baiderin`а, имхо, для меня наиболее приемлемый.

Т.е., выглядеть будет примерно так:
- 16 любых (ну или практически любых) 8 - out TTL микросхем,
- МК поочередно подавая питание на них (как вариант вводя в высокоимпедансное состояние выводы) поочередно считывает с них информацию,
- блютус формируем uart с передачей стопов и чего ему там еще надо.
- ну а на обратной стороне - то же самое, только зеркально

[Unknown]

Простите, а зачем вообще БТ?
Ведь проблема, как я понимаю, состоит конкретно в 128-жильных (или более) кабелях.
Так ведь с помощью простейшей логики можно это количество уменьшить на порядок.
Ведь от проводов питания, как я понимаю, всё равно не избавиться?
Ну так пусть будет 8данных+4адрес+2питание и всё!
Либо на регистрах (1данные+1такт+1сброс+2питани е).
Полтора десятка (или 5 на регистрах) жил элементарно можно сделать на мягких МГТФ или остатках от фирменных кабелей.

Минусы: грубо, примитивно
Плюсы: просто, простая жесткая логика без программирования, любые скорости, и НИКАКОЙ РАССИНХРОНИЗАЦИИ даже теоретически не будет!

[evg111]

Простите, а зачем вообще БТ?

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

PS. Бейсику учили, Си-шником не стал, но PHP еще помню

[whoim]

evg111, если uart + spi (для 595 не обязательно аппаратный) то tiny2313 например подойдет, из avr. В плюсах - наличие тысяч примеров пользования. По 74hc595 и я подкину вечерком софтовую реализацию, там просто.

[Falconist]

evg111, разовью свою мыслю дальше.

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

[evg111]

ок, спасибо.
Эта неделя, к сожалению, пройдет без паяльника - сегодня ночью лететь в Москву... в номере обещали wi-fi, но как-то неуверенно... так что не теряйте, и если что, считайте коммунистом

А тут еще подумалось - а зачем вообще МК, если все равно ставить 16 буферных микросхем? Его задача (МК) - только делать сдвиг в соответствии с синхроимпульсом. Так кварцевый генератор и сдвиговый регистр (например К155ИР31) справятся с этим.
Или я чего-то не понимаю?