roboforum.ru

=DeaD= писал(а):С того что мы прописали жестко - если обращаемся к этому же i2c устройству к другому регистру - считай что сказал что тебе по старому запросу данные больше ненужны

И где же мы это прописали?

=DeaD= писал(а):Или тогда надо, как я уже и предлагал, разделить обращение к каким регистрам - продолжить чтение ответа, а к каким - инициировать помещение в буфер нового ответа.

Не, путаницу не надо плодить. Слишком сложно

blindman писал(а):С чего это оно сбрасывает? Драйвер то отдал уже данные - может они еще валидны, откуда ядро-то об этом знает?

Пусть сбрасывает. У нас же 2 случая:
1. Пофик, теряем байты или нет. АЦП то же.
2. Не пофик - какой-то ЖКИ.
Если жестко прописываем, что происходит сброс, то АЦП надо будет сказать, что не только разрядность поменяли, но и читать хотим с 4-го канала. Если не указали откуда читать - читаем сначала. Точно так же и с ХКИ. Что-то поменяли в регистрах - будем указывать по-новой откуда читать и что.
Зато все системы будут работать однотипно и прозрачно.

А иначе: "тут играем, тут не играем, а тут рыбу заворачивали..."

Добавлено спустя 37 секунд:
в общем, вы тут быстрее успеваете договариваться, чем я - формулировать

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

blindman писал(а):Пример. Читаем АЦП в 16-битном режиме. Нужно прочитать 4 канала, от 0 до 3. Ядро запросило 10 байт, в результате драйвер выдал данные 5 каналов. Теперь надо прочитать каналы 4-7 в 8-битном режиме. Пишем значение в регистр конфигурации, начинаем читать 4 байта. В результате получаем лажу в первых 2 прочитанных байтах.

Пример не очень, кстати. С чего вдруг ядро запросило 10 байт, а не 2 или 20? И задачи 16-битного запроса и 8-битного - это разные задачи. Логично их разделять.
Это я к тому, что задач что-то не густо, где сохранение буфера необходимо.

blindman писал(а):

=DeaD= писал(а):С того что мы прописали жестко - если обращаемся к этому же i2c устройству к другому регистру - считай что сказал что тебе по старому запросу данные больше ненужны

И где же мы это прописали?

Вот!

=DeaD= писал(а):Обращение к регистру сбрасывает все буферы. Продолжаем читать только если не было обращений к регистрам.

blindman писал(а):Не, путаницу не надо плодить. Слишком сложно

Ничего не понял, а ты что предлагаешь? Только давай в терминах i2c протокола с точки зрения i2c-слейва

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

Digit писал(а):Это я к тому, что задач что-то не густо, где сохранение буфера необходимо.

Вот и я про то же хотя я согласен от драйвера по байту принимать

Добавлено спустя 5 минут 42 секунды:

blindman писал(а):Я не помню что это за микросхема. Вот пример микрухи попроще, но то же самое - можно читать из памяти, потом прочитать статус, потом возобновить чтение памяти.

По моему это не и2с, а какая-то штук, завернутая в и2с, снижающая эффективность этого самого и2с

При этом от регистров которые я говорю сделать разные для перезапуска запроса или продолжения чтения она не сильно отличается

Так, по итогам обсуждения предлагаю зафиксировать такие правила:

1. В структуру драйверов добавляем функцию сброса.
2. Ядро получив запрос читает некое количество байт из драйвера в свой буфер, все последующие запросы на чтение из этого же регистра обслуживаются из буфера, при необходимости подгружая данные из драйвера.
3. При получении запроса к регистру, отличному от того, с которым работали в предыдущем запросе (или при том же регистре, но при смене направления с чтения на запись), ядро сбрасывает свой буфер, и посылает сигнал драйверу, с которым работали последний раз - "сброс".
4. Клиент, которому надо принять н-е кол-ва байт из регистра, не должен разрывать операцию чтения другими запросами, либо перед каждым чтением устанавливать параметры операции чтения (номер канала АЦП например).

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

Побайтовое чтение я хоть и предлагал, но все же это довольно накладно.

Добавлено спустя 2 минуты 15 секунд:

=DeaD= писал(а):При этом от регистров которые я говорю сделать разные для перезапуска запроса или продолжения чтения она не сильно отличается

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

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

-1, см. ниже.

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

+1. Подробности см. ниже

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

-1. Предлагаю сделать проще: если ядро обращается к регистру 0xFF драйвера - значит продолжаем читать, иначе сброс и начинаем новый запрос с указанного нам регистра.

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

+1, если я правильно всё понял.

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

+1

blindman писал(а):Побайтовое чтение я хоть и предлагал, но все же это довольно накладно.

+1

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

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

Ну а я что говорю? Один регистр для рестарта запроса - регистр в который пишем адрес памяти. И один регистр для продолжения чтения - из которого читаем. Один в один

blindman писал(а):Так, по итогам обсуждения предлагаю зафиксировать такие правила:

Вроде нормальные правила.
Единственно, я б не фиксировал жестко правило 4, а делал бы "на усмотрение устройства". Типа как в и2с автоинкремент регистра сделан.

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

=DeaD= писал(а):По моему это не и2с, а какая-то штук, завернутая в и2с, снижающая эффективность этого самого и2с

Чтоб у Филипса, и непонятно что, завернутое в и2с? не верю!

Digit писал(а):А почему накладно читать из драйвера в ядро побайтно? В любом случае драйверу данные готовить...

Потому что вызов функции - это время.

Digit писал(а):Чтоб у Филипса, и непонятно что, завернутое в и2с? не верю!

У них тут два интерфейса, при этом i2c дублирующий - глянь даташит

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

А чем это проще? Те же яйца, только в профиль
Что там вызов функции, что тут

=DeaD= писал(а):У них тут два интерфейса, при этом i2c дублирующий - глянь даташит

Гляжу )
Но моя ИМХА - Филипс, как хозяин стандарта, не должен делать кастрированный и2с

Digit писал(а):

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

А чем это проще? Те же яйца, только в профиль
Что там вызов функции, что тут

Тем что тут 1 функция, а там две разные. А мы всё-таки в МК пишем

Digit писал(а):Но моя ИМХА - Филипс, как хозяин стандарта, не должен делать кастрированный и2с

А ты всё-таки глянь в даташит

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

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

-1. Предлагаю сделать проще: если ядро обращается к регистру 0xFF драйвера - значит продолжаем читать, иначе сброс и начинаем новый запрос с указанного нам регистра.

Нет, это не проще. Ядро все равно должно понить к какому регистру обращались, а так еще и в драйвере это придется запоминать. Получит он FF - а продолжать-то откуда ? Надо будет запоминать - при том, что ядро и так это уже помнит.

Иначе в драйвере может потребоваться 25 буферов (ака "те самые мультибуферы") по количеству регистров. ИМХО в топку эти усложнения, проще надо быть.

Можно ввести дополнительный флаг "новый запрос" - и передавать его вместе с номером регистра, в старшем бите.

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

Digit писал(а):Но моя ИМХА - Филипс, как хозяин стандарта, не должен делать кастрированный и2с

А ты всё-таки глянь в даташит

Глянул Ну да, нестандартный у них вышел и2с

=DeaD= писал(а):Ну а я что говорю? Один регистр для рестарта запроса - регистр в который пишем адрес памяти. И один регистр для продолжения чтения - из которого читаем. Один в один

Ага, только там ядра нет, которое должно знать что это регистр какой-то специальный.

Ну почему нет? Раньше регистр 0 перехватывался, на том уровне можно перехватить любой регистр(ы).

Меня тут немного более приземленные вещи интересуют:
нам нужны реализации ф-ций htons, htonl, ntohs, ntohl из <netinet/in.h>.
Вообще в оптимизированном варианте это макросы к __bswap_16()/__bswap_32() из <bits/swap.h>.
Это реализованные на ассемблере ф-ции перекидывания байт в 16и битном и 32х битном слове.