roboforum.ru

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

на казусе в статье писал(а): 1. Комбинированные форматы могут быть использованы, например, для управления последовательной памятью. Во время первого байта данных можно передавать адрес в памяти, который записывается во внутреннюю защелку. После повторения сигнала СТАРТа и адреса ведомого выдаются данные из памяти.
2. Все решения об авто-инкременте или декременте адреса, к которому произошел предыдущий доступ, принимаются конструктором устройства
3. Каждый байт завершается битом подтверждения, обозначенным А или А^ на рисунках
4. I2C-совместимые устройства должны сбрасывать логику шины при получении сигнала СТАРТ или повторный СТАРТ и подготавливаться к приему адреса.

Ну так это для простой памяти, там это оправдано.
Правда не ясно как там формируется NAck для последнего байта.

Vooon писал(а):И мне вовсе не очевидно что второй байт регистра 20 есть регистр 21.
Номер регистра лишь указывает с какой областью памяти работать

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

Добавлено спустя 57 секунд:
Есть какие-то предпосылки чтобы так не делать кроме того, что хочется сэкономить регистры?

Добавлено спустя 25 секунд:
Кроме того такой подход значительно упрощает работу с регистрами и2с на стороне контроллера.

=DeaD= писал(а):А я за то чтобы делать именно так - это очень красивый и прозрачный способ за 1 запрос читать всё что нужно.

Я и предлагаю читать все - пишем номер регистра, тут же читаем всю инфу о нем. Длину блока информации запрашивать необязательно - просто запрашиваем максимум байт (64? 255?) - драйвер вернет столько, сколько надо.

=DeaD= писал(а):Кроме того такой подход значительно упрощает работу с регистрами и2с на стороне контроллера.

I2C здесь совершенно ни при чем

blindman писал(а):Я и предлагаю читать все - пишем номер регистра, тут же читаем всю инфу о нем. Длину блока информации запрашивать необязательно - просто запрашиваем максимум байт (64? 255?) - драйвер вернет столько, сколько надо.

Стоп, номер драйвера может быть, а не номер регистра?
Длину блока запрашивать надо - т.к. это нужно для совместимости с и2с.

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

В I2C длину читаемого блока можно и не знать - читаем пока не получим NACK

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

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

Сейчас NAck работает для сообщения об ошибке, хотя думаю можно при записи указать A/N.

И не забываем про буферы:
1. serialgate использует два буфера по 128 байт (in, out)
Грубо чтобы в них поместилось 64 байта в хексе
2. main предоставляет буфер для registers, 65 байт (i/o)
3. spi_driver для внутренних нужд использует буфер в 64 байта

Добавлено спустя 2 минуты 25 секунд:
Те если мастер получил NAck когда не его ожидал, буфер выхода будет сброшен и сообщено от ошибке 07

В любом случае инфа о конкретном драйвере должна читаться вся сразу. Да, согласен, буфер вносит ограничение. Тогда можно сделать так: пишем номер драйвера, читаем - сколько байт информации доступно. Следом сразу читаем X байт, возможно в несколько последовательных запросов чтения. Какая инфа о драйвере должна возвращаться мы знаем, соответственно определяем структуру передаваемых данных. Запись номера драйвера сбрасывает автомат в начальное состояние

blindman писал(а):В любом случае инфа о конкретном драйвере должна читаться вся сразу.

Не-не-не Предлагаю разделить инфу о драйвере на 2 части - обязательную (типа идентификатор, версия, стартовый адрес регистра, количество выделенных регистров) и факультативную - читаемую уже напрямую из регистров драйвера.

blindman писал(а):Тогда можно сделать так: пишем номер драйвера, читаем - сколько байт информации доступно. Следом сразу читаем X байт, возможно в несколько последовательных запросов чтения. Какая инфа о драйвере должна возвращаться мы знаем, соответственно определяем структуру передаваемых данных. Запись номера драйвера сбрасывает автомат в начальное состояние

Очень плохо когда система будет оперировать с данными о которых ничего не знает, я не видел ни разу средства общей интроспекции выдающие специфичные для драйверов типы данных. Вроде ничего не упускал в последних тенденциях?

Хм, тогда

S AA 00 00 S AB 01 P
SWAASR02P
S AA 00 01 S AB 01 P
SWAASR06P
S AB 06 P
SR123456785051P

-> [1..4] UID 12345678 предположим это идентификатор SPI
-> [5..6] регистры

Добавлено спустя 3 минуты 58 секунд:
Хотя, в этом варианте нет UID'ов для регистров,
используя UID можно точно определить что это за регистр (PORTA, DDRA, PWM1...)

=DeaD= писал(а):Не-не-не Предлагаю разделить инфу о драйвере на 2 части - обязательную (типа идентификатор, версия, стартовый адрес регистра, количество выделенных регистров) и факультативную - читаемую уже напрямую из регистров драйвера.

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

=DeaD= писал(а):Очень плохо когда система будет оперировать с данными о которых ничего не знает, я не видел ни разу средства общей интроспекции выдающие специфичные для драйверов типы данных. Вроде ничего не упускал в последних тенденциях?

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

blindman писал(а):Я говорю только об обязательной информации, которая позволит начать общение с драйвером. Какую инфу конкретный драйвер может выдавать через свои собственные регистры - это уже вопрос реализации этого драйвера.

Можно пример такой информации? Что нам может принципиально не позволить выдать эту информацию уже самим драйвером по первому его адресу? В целом мне кажется что это неоправданное усложнение системы, супер-драйвера и размазывание функционала

blindman писал(а):См. выше. Мы заранее знаем какую инфу о драйвере хотим получить - значит мы можем ожидать получить определённую структуру, которую и должен формировать "супер-драйвер"

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

=DeaD= писал(а):Можно пример такой информации? Что нам может принципиально не позволить выдать эту информацию уже самим драйвером по первому его адресу? В целом мне кажется что это неоправданное усложнение системы, супер-драйвера и размазывание функционала

Я говорю то же самое Прочитай внимательнее

=DeaD= писал(а):супер-драйвер зато об этой структуре ничего не знает, тупо выдаёт набор из скольки-то байт. Не видел чтобы кто-то так делал, можно примеры такой интраспекции реализованной хоть где?

Как это не знает ? И что че он тогда выдает? Набор случайных чисел?

blindman писал(а):Я говорю то же самое Прочитай внимательнее

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

blindman писал(а):

=DeaD= писал(а):супер-драйвер зато об этой структуре ничего не знает, тупо выдаёт набор из скольки-то байт. Не видел чтобы кто-то так делал, можно примеры такой интраспекции реализованной хоть где?

Как это не знает ? И что че он тогда выдает? Набор случайных чисел?

Хм, я под супердрайвером понимаю только средство общей интроспекции. А дальше через ядро\шлюз по адресам уже конкретного драйвера мы с ним работаем (в т.ч. читаем дополнительную информацию необходимую для работы с ним).

Или я невнятно изъясняюсь, или кто-то по диагонали читает Я именно это и имею в виду - супер-драйвер возвращает только информацию, которую драйвера сообщили ядру во время своей регистрации.