roboforum.ru

blindman писал(а):Прочитали 20 байт в буфер, реально на шину ушло 15 - 5 байт потеряны навсегда.

Почему потеряны? Мы разве следующим запросом не можем еще раз читать продолжить?

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

Не понял, а твой побайтовый вариант от моего по-20-байтового кроме размера передаваемого блока чем еще отличается?

Добавлено спустя 1 минуту 37 секунд:

blindman писал(а):

Vooon писал(а):Порядок байт: старший — младший.

Есть этому какие-то веские причины?

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

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

Можно в этом случае передавать ему это, как ограничение на размер буфера.

=DeaD= писал(а):

blindman писал(а):Прочитали 20 байт в буфер, реально на шину ушло 15 - 5 байт потеряны навсегда.

Почему потеряны? Мы разве следующим запросом не можем еще раз читать продолжить?

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

Не понял, а твой побайтовый вариант от моего по-20-байтового кроме размера передаваемого блока чем еще отличается?

Да дело на самом деле не в деталях реализации. Вопрос простой : может ли драйвер сохранять состояние между запросами, или мы объявляем, что результат запроса к драйверу не зависит от предыдущих запросов? Вариант "запрос, потом еще один к тому же регистру" считаем за 1 запрос

blindman писал(а):Вариант "запрос, потом еще один к тому же регистру" считаем за 1 запрос

Сразу нет, зачем так делать? Тогда проще не прекращать предыдущий запрос. Или надо какой-то специальный способ тогда сказать, что мы новый запрос начинаем - а я себе не вижу способа красиво это сделать.

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

Давайте пока ненадолго отойдем от деталей. Какие мнения вот по этому вопросу :

blindman писал(а):Да дело на самом деле не в деталях реализации. Вопрос простой : может ли драйвер сохранять состояние между запросами, или мы объявляем, что результат запроса к драйверу не зависит от предыдущих запросов? Вариант "запрос, потом еще один к тому же регистру" считаем за 1 запрос

Так моё мнение то простое - должно быть 2 вида запросов - начало нового запроса (тогда передаем регистр к которому обращаемся и буфер по ответ с ограничением этого буфера) и продолжить чтение ответа на предыдущий запрос (передаём буфер для возврата очередной части ответа и ограничение буфера).

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

Не совсем так. Явный запрос к этому же регистру так же сбросит состояние драйвера. Должна быть операция "продолжить чтение предыдущего ответа с устройства X", хотя она и так есть.

Добавлено спустя 35 секунд:
Отсутствие явного запроса к этому же регистру - зло. Повторная передача регистра при продолжении чтения - ненужная информация.

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

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

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

=DeaD= писал(а):Да, именно так. Потому что это жесткое ограничение архитектуры i2c которую мы приняли в качестве основы.

Нет у I2C такого ограничения. Логика целиком определяется девайсом, и каких-то рамок просто нет

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

Добавлено спустя 50 секунд:

blindman писал(а):Нет у I2C такого ограничения. Логика целиком определяется девайсом, и каких-то рамок просто нет

Если бы мы не держали по 10 драйверов на 1 и2с адресе - это было бы правдой. А так - это неправда

Добавлено спустя 1 минуту 12 секунд:
Но я не вижу пока в массовом количестве никаких реальных задач где нужно по и2с гонять гигантские объемы данных. Чтобы из-за этого разбазаривать и2с адреса начинать.

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

А задач, где будут использованы все 127 адресов (а при 10-битной адресации - вообще дофига) в одном устройстве - много?

Добавлено спустя 1 минуту 37 секунд:
Но идея каждому драйверу выдать адрес мне тоже не нра, т.к. хардварно не получится мониторить адреса. МК прийдется на каждый обмен на шине выпадать в прерывание и "вручную" проверять адрес на соответствие своему списку драйверов.

Дело в том, что драйверов в одном контроллере может легко перевалить за десяток. А еще на шине i2c всякие сонары висят, I2C-It, акселерометры, гироскопы и прочая прелесть, при этом у них у всех адреса или диапазоны адресов фиксированные, а значит в своих контроллерах драйвера надо будет делать обходя эти заслоны - не слишком ли близко сразу подбираемся к верхней границе?

PS: 10-битная адресация в топку. Как и мультимастер - проще надо быть.

Добавлено спустя 49 секунд:

Digit писал(а):Но идея каждому драйверу выдать адрес мне тоже не нра, т.к. хардварно не получится мониторить адреса.

Тем более.

Добавлено спустя 1 минуту 3 секунды:
PS: Забыл сказать - наших контроллеров может быть пяток в сложном роботе совершенно спокойно. Так что 15 драйверов * 5 = уже 75 адресов заняты, а еще всякой мути полно. Короче уже тесно.

А в чем проблемы потери байтов из буфера?
Ну, если как blindman говорил: прочитали в буфер 20 байт, забрали у нас только 15, - 5 потерялись.
Раз их не забрали - значит они не нужны. Если АЦП выгрузило 20 замеров в буфер, а мы забрали только 15 - ну и фик с оставшимися 5...

Digit писал(а):А в чем проблемы потери байтов из буфера?

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

=DeaD= писал(а):Если бы мы не держали по 10 драйверов на 1 и2с адресе - это было бы правдой. А так - это неправда

Конечно я могу ошибаться. Но только не надо обвинять меня во лжи, а то так наш диалог может выйти за рамки конструктивного Пример навскидку - драйвер ЖКИ (имеется в виду реальная I2C микруха NXP). Можно последовательно читать данные из видеопамяти, потом считать показания датчика температуры, и вернуться к чтению памяти. Подобных примеров можно немало привести