[VCucumber 0]

в обратную строну их КС при одновременной передаче следующего пакета

минимум это и надо

Ещё немного - и изобретём CAN :laughing:

я бы в первую очередь изобрёл can, если бы его в своё время изобрёл изобретатель ibm/pc

но тот был чрезмерно глуп ибо не смог изобрёсти ни одного нормального интерфейса

Вот этот терминал уже 20 лет так работает и все довольны

я ж не отрицаю, что работает

люди вон на костылях как-то ходят и тоже довольны, даже весьма

[Tarbal 4]

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

 

Я же не спорю, что если делать криво, то иногда тоже будет работать. Однако для массовой продукции это недопустимо. Вероятно тому кто делает сначала надо ответьть на вопрос какое решение ему надо. Надежное или через одно место, но проще. Мой программатор для БМВ по I-BUS устойчиво работал даже в машине, где другие устройства слали свои пакеты по той же I-BUS.

 

Я давно уже просто не рассматриваю убогие решения.

[gerber 8]

я бы в первую очередь изобрёл can, если бы его в своё время изобрёл изобретатель ibm/pc

но тот был чрезмерно глуп ибо не смог изобрёсти ни одного нормального интерфейса

На мой взгляд, RS-232 просто блестящий интерфейс.

[krux 8]

На мой взгляд, RS-232 просто блестящий интерфейс.

позвольте вас поправить, вы неправильно именуете ITU-T V.10/V.11 ;-)

на RS-232 никаких официальных документов, или обязывающих стандартов не существует.

 

но таки-да, в быту и головах название RS-232 известно в более широких кругах.

[VCucumber 0]

Я давно уже просто не рассматриваю убогие решения.

убогие - я вам сходу назвал три косяка, которых не должно быть в нормальном протоколе

На мой взгляд, RS-232 просто блестящий интерфейс.

был бы он блестящий - не было бы ни параллельного порта, ни юсб

другими словами ему нужно было _изначально_:

- добавить битрейта до 10мбит

- добавить симметричности линий tx/rx

- убрать линии управления

- обязательный пин с питанием

- вероятно, манчестер

- и весьма неплохо гальваническую развязку

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

минимум это и надо

ещё интересная мысль пришла - иногда полезно поменять местами хост с таргетом, расставляет всё по своим местам

[sigmaN 0]

ИМХО в те времена 10мбит было чем-то космическим.

Так и что, в итоге какой протокол будет?

[mantech 53]

был бы он блестящий - не было бы ни параллельного порта, ни юсб

В те времена это было очень удачное решение, усб тоже неплохо, но надежности 232го ему очень не хватает..

 

другими словами ему нужно было _изначально_:

- добавить битрейта до 10мбит

- добавить симметричности линий tx/rx

- убрать линии управления

- обязательный пин с питанием

- вероятно, манчестер

- и весьма неплохо гальваническую развязку

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

 

Без гальваноразвязки - это и есть усб.

ИМХО в те времена 10мбит было чем-то космическим.

И никому не нужным, кроме локалки. К этому порту мышки и модемы подключали.

[VCucumber 0]

ИМХО в те времена 10мбит было чем-то космическим.

да ладно, 800 что-то кбайт было на параллельном порте, а это уже 8 мбит

чего-чего, а сдвиговые регистры на 8 мбит были

 

Так и что, в итоге какой протокол будет?

остановлюсь на собственном недоперетисипи овер недоюдипи

чтобы понятнее, то всё просто - делим поток на пакеты байтом 0xff, числа которые встречаются, преобразуюм в сс по основанию 255

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

и это однозначно не будет tcp, хоть и похоже, ибо и проще, и лучше

 

Без гальваноразвязки - это и есть усб.

это не юсб, это firewire, если хотите

 

И никому не нужным, кроме локалки.

локалка - это 100 и 300 метров, а я говорю про настольный интерфейс, пусть 3 метра

 

К этому порту мышки и модемы подключали.

и ещё принтеры подключали

понятно, что для ацпу его хватало, а для матричного графического, тем более для лазерного, были нужны те самые 10 мбит

будь такой порт, вместо дорогой сетевой карты появились бы дешёвые сетевые модемы

Изменено 23 июля, 2017 пользователем Огурцов

[mantech 53]

чего-чего, а сдвиговые регистры на 8 мбит были

А не забыли, что ком-порт - это не только логика, но еще и выходные ключи и приемник +\-12В. Они в то время на 8 Мбит работали?

 

будь такой порт, вместо дорогой сетевой карты

 

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

 

ЗЫ. Год назад глянул на цену 485го драйвера с развязкой - 450рэ!! Еще б все это было дешевое, лет н-цать назад...

Изменено 23 июля, 2017 пользователем mantech

[VCucumber 0]

выходные ключи и приемник +\-12В.

зачем там 12 ? 12 - это глупо, 5 более чем достаточно

 

Они в то время на 8 Мбит работали?

может 174пс1 или эсл какой-нибудь - хоть 100

было бы желание - это всё ещё можно замакетировать в реале

 

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

нет, потому что сетевуха - это гораздо более, чем сдвиговый регистр

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

Изменено 23 июля, 2017 пользователем Огурцов

[Tarbal 4]

убогие - я вам сходу назвал три косяка, которых не должно быть в нормальном протоколе

 

Я стараюсь избегать религиозных дискуссий. Дальше без меня.

[VCucumber 0]

Я стараюсь избегать религиозных дискуссий. Дальше без меня.

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

 

[sigmaN 0]

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

[VCucumber 0]

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

хорошо, для однозначности дополняю условие - для пакетов разной длинны

Изменено 25 июля, 2017 пользователем Огурцов

[sigmaN 0]

Если в протоколе есть четкая связь между "типом пакета" и его длиной то явно передавать ее не придется.

Но она все равно всплывет. Возможно у вас будет байт(или биты) "тип пакета", откуда будет следовать ожидаемая длина...

 

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