Технический форум по робототехнике.
=DeaD= » 29 май 2009, 11:43
blindman писал(а):Прочитали 20 байт в буфер, реально на шину ушло 15 - 5 байт потеряны навсегда.
Почему потеряны? Мы разве следующим запросом не можем еще раз читать продолжить?
blindman писал(а):=DeaD=, недостаток твоего подхода в том, что он не позволяет драйверам сохранять состояние между запросами - только один запрос к определённому регистру, возможно разбитый на несколько более мелких, ограниченных размерами буферов или чем-то ещё. Последующие запросы никак не зависят от предыдущего
Не понял, а твой побайтовый вариант от моего по-20-байтового кроме размера передаваемого блока чем еще отличается?
Добавлено спустя 1 минуту 37 секунд:blindman писал(а):Vooon писал(а):Порядок байт: старший — младший.
Есть этому какие-то веские причины?
Я бы тоже такой порядок принял, читать удобней при отладке. И писать потом в инструкциях проще - меньше вопросов от пользователей модулей.
Vooon писал(а):На данный момент и при работе через юсарт на уровне виртуального слейва мы не знаем сколько байт запрошено.
Можно в этом случае передавать ему это, как ограничение на размер буфера.
blindman » 29 май 2009, 11:49
=DeaD= писал(а):blindman писал(а):Прочитали 20 байт в буфер, реально на шину ушло 15 - 5 байт потеряны навсегда.
Почему потеряны? Мы разве следующим запросом не можем еще раз читать продолжить?
blindman писал(а):=DeaD=, недостаток твоего подхода в том, что он не позволяет драйверам сохранять состояние между запросами - только один запрос к определённому регистру, возможно разбитый на несколько более мелких, ограниченных размерами буферов или чем-то ещё. Последующие запросы никак не зависят от предыдущего
Не понял, а твой побайтовый вариант от моего по-20-байтового кроме размера передаваемого блока чем еще отличается?
Да дело на самом деле не в деталях реализации. Вопрос простой : может ли драйвер сохранять состояние между запросами, или мы объявляем, что результат запроса к драйверу не зависит от предыдущих запросов? Вариант "запрос, потом еще один к тому же регистру" считаем за 1 запрос
=DeaD= » 29 май 2009, 11:59
blindman писал(а):Вариант "запрос, потом еще один к тому же регистру" считаем за 1 запрос
Сразу нет, зачем так делать? Тогда проще не прекращать предыдущий запрос. Или надо какой-то специальный способ тогда сказать, что мы новый запрос начинаем - а я себе не вижу способа красиво это сделать.
blindman » 29 май 2009, 12:04
Как это "нет"? Это же как раз то что ты предлагаешь - внешний по отношению к драйверу буфер, остаток которого можно повторно использовать в следующем запросе, без обращения к драйверу. То есть для драйвера это и выглядит как 1 запрос.
Давайте пока ненадолго отойдем от деталей. Какие мнения вот по этому вопросу :
blindman писал(а):Да дело на самом деле не в деталях реализации. Вопрос простой : может ли драйвер сохранять состояние между запросами, или мы объявляем, что результат запроса к драйверу не зависит от предыдущих запросов? Вариант "запрос, потом еще один к тому же регистру" считаем за 1 запрос
=DeaD= » 29 май 2009, 12:15
Так моё мнение то простое - должно быть 2 вида запросов - начало нового запроса (тогда передаем регистр к которому обращаемся и буфер по ответ с ограничением этого буфера) и продолжить чтение ответа на предыдущий запрос (передаём буфер для возврата очередной части ответа и ограничение буфера).
blindman » 29 май 2009, 12:19
Другими словами - "драйвер сохраняет свое состояние только между запросами к одному и тому же регистру. запрос к другому регистру или другому драйвера сбрасывает состояние драйвера"
=DeaD= » 29 май 2009, 12:46
Не совсем так. Явный запрос к этому же регистру так же сбросит состояние драйвера. Должна быть операция "продолжить чтение предыдущего ответа с устройства X", хотя она и так есть.
Добавлено спустя 35 секунд:
Отсутствие явного запроса к этому же регистру - зло. Повторная передача регистра при продолжении чтения - ненужная информация.
blindman » 29 май 2009, 12:51
Я прекрасно понял что ты имеешь в виду. И означает это то, что нельзя прочитать данные одного драйвера, потом другого, а потом продолжить чтение из первого с того места, где остановились.
=DeaD= » 29 май 2009, 13:03
Да, именно так. Потому что это жесткое ограничение архитектуры i2c которую мы приняли в качестве основы. Логично будет сделать этот функционал на уровне регистров драйвера. Чтобы и2с-слэйвы могли его также прозрачно реализовывать. Реально я считаю, что такая потребность будет достаточно редкой, поэтому рушить из-за этого совместимость с идеологией и2с - зло.
Добавлено спустя 1 минуту 35 секунд:
Однако готов сформулировать единый подход к реализации такой фишки на уровне и2с регистров, чтобы от драйвера к драйверу методы не плавали и можно было бы на стороне хоста реализовать однотипную обвязку для работы с такими запросами.
blindman » 29 май 2009, 13:04
=DeaD= писал(а):Да, именно так. Потому что это жесткое ограничение архитектуры i2c которую мы приняли в качестве основы.
Нет у I2C такого ограничения. Логика целиком определяется девайсом, и каких-то рамок просто нет
=DeaD= » 29 май 2009, 13:06
Например, можно разнести 2 регистра - получения данных (который будет всегда тупо выдавать всё подряд из буфера) и сброса обращения и загрузки новых данных в буфер. Это позволит в редких случаях возвращения огромных объемов информации получать их единым образом для всех устройств.
Добавлено спустя 50 секунд:blindman писал(а):Нет у I2C такого ограничения. Логика целиком определяется девайсом, и каких-то рамок просто нет
Если бы мы не держали по 10 драйверов на 1 и2с адресе - это было бы правдой. А так - это неправда
Добавлено спустя 1 минуту 12 секунд:Но я не вижу пока в массовом количестве никаких реальных задач где нужно по и2с гонять гигантские объемы данных. Чтобы из-за этого разбазаривать и2с адреса начинать.
Digit » 29 май 2009, 13:14
=DeaD= писал(а):Но я не вижу пока в массовом количестве никаких реальных задач где нужно по и2с гонять гигантские объемы данных. Чтобы из-за этого разбазаривать и2с адреса начинать.
А задач, где будут использованы все 127 адресов (а при 10-битной адресации - вообще дофига) в одном устройстве - много?
Добавлено спустя 1 минуту 37 секунд:Но идея каждому драйверу выдать адрес мне тоже не нра, т.к. хардварно не получится мониторить адреса. МК прийдется на каждый обмен на шине выпадать в прерывание и "вручную" проверять адрес на соответствие своему списку драйверов.
=DeaD= » 29 май 2009, 13:17
Дело в том, что драйверов в одном контроллере может легко перевалить за десяток. А еще на шине i2c всякие сонары висят, I2C-It, акселерометры, гироскопы и прочая прелесть, при этом у них у всех адреса или диапазоны адресов фиксированные, а значит в своих контроллерах драйвера надо будет делать обходя эти заслоны - не слишком ли близко сразу подбираемся к верхней границе?
PS: 10-битная адресация в топку. Как и мультимастер - проще надо быть.
Добавлено спустя 49 секунд:Digit писал(а):Но идея каждому драйверу выдать адрес мне тоже не нра, т.к. хардварно не получится мониторить адреса.
Тем более.
Добавлено спустя 1 минуту 3 секунды:PS: Забыл сказать - наших контроллеров может быть пяток в сложном роботе совершенно спокойно. Так что 15 драйверов * 5 = уже 75 адресов заняты, а еще всякой мути полно. Короче уже тесно.
Digit » 29 май 2009, 13:19
А в чем проблемы потери байтов из буфера?
Ну, если как
blindman говорил: прочитали в буфер 20 байт, забрали у нас только 15, - 5 потерялись.
Раз их не забрали - значит они не нужны.
Если АЦП выгрузило 20 замеров в буфер, а мы забрали только 15 - ну и фик с оставшимися 5...
blindman » 29 май 2009, 13:32
Digit писал(а):А в чем проблемы потери байтов из буфера?
Если данные постоянно обновляются, и нас интересуют только самые свежие - проблем никаких. Если важен порядок поступления данных, то потеря части - это проблема.
=DeaD= писал(а):Если бы мы не держали по 10 драйверов на 1 и2с адресе - это было бы правдой. А так - это неправда
Конечно я могу ошибаться. Но только не надо обвинять меня во лжи, а то так наш диалог может выйти за рамки конструктивного
Пример навскидку - драйвер ЖКИ (имеется в виду реальная I2C микруха NXP). Можно последовательно читать данные из видеопамяти, потом считать показания датчика температуры, и вернуться к чтению памяти. Подобных примеров можно немало привести