Если данная шина не предусматривает несколько master, арбитраж и 10-битовую адресацию устройств, это не делает этот протокол отличным от протокола I2С.
SVI не позволяет многое в дополнение к тому, что вы перечислили. Единственное, что поддерживается из протокола fast-mode I2C - это передача 1 байта ведомому устройству с 7-битной адресацией. Заодно SVI несовместим с I2C по совокупности программной модели и используемых таймингов . Так что никак не получится заменить SVI на I2C.
Chai писал(-а):
Не вижу никаких проблем.
Сейчас нарисуем проблемы .
Вариант 1 - общение SVI ведущего с I2C ведомым, который может работать в режиме fast-mode. Проблема - ведомый может не успеть понять, что происходит передача. Т.е. ведомый гарантированно может сообразить, что нужно "притормозить" ведущего, за 1,3 мкс (за мЕньшее время спецификация I2C этого не гарантирует). При этом весь период для передачи 1 бита с таймингами high-speed будет составлять примерно 0,6 мкс (для большой емкости линии) или 0,3 мкс (для малой емкости линии).
Вариант 2 - общение SVI ведущего с I2C ведомым, который может работать в режиме high-speed. Проблема - ведомый не поймет, что к нему обращаются. Т.е. нет передачи master code.
Chai писал(-а):
Еще раз повторить?
От того, что вы много раз повторите свой бред, данные не станут командами.
Для того, чтобы можно было рассуждать о командах, нужно иметь разные действия по этим командам. В случае же SVI выполняется одно и то же действие - занесение бита PSI-L и VID'ов в соответствующие ячейки данных ШИМа. Есть производители, которые используют термин "Set VID command" (команда - в единственном числе) по отношению ко всей посылке SVI (старт+адрес+данные+стоп).
Chai писал(-а):
Здесь структура команды - из самой команды и ее аргумента.
Масло слегка масляное.
Chai писал(-а):
В случае с SVI-командами у команд нет аргумента.
Согласно вашей логике при добавлении одного VID'а "команд" сразу станет в 2 раза больше, но при этом вы так и не сможете дать им названия . Забавная логика. Надо будет применить эту логику к EEPROM - у них количество команд будет сильно зависеть от их емкости .
Chai писал(-а):
В итоге они все же оказались 16-битными?
Зависит от того, что вы понимаете по 16-битностью. Меня с точеи зрения 32-битности вполне устраивает возможность оперировать 32-битными РОН и использовать плоскую модель памяти.
Забавно еще то, что вы поднимаете этот вопрос, не заглянув в прошивку вашего ноутбука.
Chai писал(-а):
Встроенная ROM - этого достаточно.
Причем используется для хранения таблицы преобразования (датчики с нелинейной характеристикой), т.е. к затронутому вопросу не имеет никакого отношения.
Вариант 1 - общение SVI ведущего с I2C ведомым, который может работать в режиме fast-mode. Проблема - ведомый может не успеть понять, что происходит передача. Т.е. ведомый гарантированно может сообразить, что нужно "притормозить" ведущего, за 1,3 мкс (за мЕньшее время спецификация I2C этого не гарантирует). При этом весь период для передачи 1 бита с таймингами high-speed будет составлять примерно 0,6 мкс (для большой емкости линии) или 0,3 мкс (для малой емкости линии).
Вариант 2 - общение SVI ведущего с I2C ведомым, который может работать в режиме high-speed. Проблема - ведомый не поймет, что к нему обращаются. Т.е. нет передачи master code.
Для того, чтобы можно было рассуждать о командах, нужно иметь разные действия по этим командам. В случае же SVI выполняется одно и то же действие - занесение бита PSI-L и VID'ов в соответствующие ячейки данных ШИМа. Есть производители, которые используют термин "Set VID command" (команда - в единственном числе) по отношению ко всей посылке SVI (старт+адрес+данные+стоп).
Забавно еще то, что вы поднимаете этот вопрос, не заглянув в прошивку вашего ноутбука.