roboforum.ru

Ну вот и началось Я потому и сделал сначала - младший байт первый. А вы - network order, network order ...

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

Там нет ядра в том виде как оно присутствует у нас - снаружи девайса

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

А где я сказал что это на уровне ядра такой регистр?

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

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

Мы же вроде были против мультибуферов? Как тут без них?

Ну щас еще на 5 страниц будут объяснения кто что сказал Там все немного по-другому, вся логика сосредоточена в одном месте. А у нас же изолированные части, которые друг о друге ничего не знают

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

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

=DeaD= писал(а):Мы же вроде были против мультибуферов? Как тут без них?

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

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

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

Еще раз : как драйвер узнает к какому регистру обращение, если ему передано FF?

Я предлагаю передавать номер регистра с установленным старшим битом, если это новый запрос, и сброшенным - если продолжение

Да, я раньше для минибота сделал little-endian, а потом мне было очень "весело" работать вручную.
Поэтому сейчас я предпочитаю использовать big-endian для текстового обмена.
(Хотя сетевых приложений я не писал, только читал исходники...)

Кроме того для пользователя BE более интуитивно понятен.

Будем холивар устраивать или нет? Мне лениво...

Я предлагаю передавать номер регистра с установленным старшим битом, если это новый запрос, и сброшенным - если продолжение

Уж лучше наоборот.

Vooon писал(а):Будем холивар устраивать или нет? Мне лениво...

Нет, я одинаково хорошо читаю в обоих направлениях

Vooon писал(а):

Я предлагаю передавать номер регистра с установленным старшим битом, если это новый запрос, и сброшенным - если продолжение

Уж лучше наоборот.

А вот за это подеремся

Мне вот только остается не ясным как формировать NAck в конце чтения будешь?
Может не нужно придумывать все это шаманство с буферами?

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

Всё бы ок, если бы опять не этот злосчастный повторяющийся регистр

blindman писал(а):Еще раз : как драйвер узнает к какому регистру обращение, если ему передано FF?

А зачем ему знать? У него в буфере инфа, он её выдаёт.

blindman писал(а):Я предлагаю передавать номер регистра с установленным старшим битом, если это новый запрос, и сброшенным - если продолжение

Это значит регистров сразу в 2 раза меньше себе сделали, при том что реально это нужно будет в единичных случаях и реально в 90% драйверов не надо будет длинные ответы возвращать, всё будет умещаться в 20 байтный буфер.

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

Vooon писал(а):Мне вот только остается не ясным как формировать NAck в конце чтения будешь?
Может не нужно придумывать все это шаманство с буферами?

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

=DeaD= писал(а):А зачем ему знать? У него в буфере инфа, он её выдаёт.

А что он будет делать если ее там нет? Просто тупо кончилась, и надо подгрузить?

=DeaD= писал(а):Это значит регистров сразу в 2 раза меньше себе сделали, при том что реально это нужно будет в единичных случаях и реально в 90% драйверов не надо будет длинные ответы возвращать, всё будет умещаться в 20 байтный буфер.

Тебе не хватит 128 регистров на 1 драйвер? Да ты гигант

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

=DeaD= писал(а):Всё бы ок, если бы опять не этот злосчастный повторяющийся регистр

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

Где логика?

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

Vooon писал(а):Мне вот только остается не ясным как формировать NAck в конце чтения будешь?

Драйвер может вернуть меньше данных чем у него запросили - когда данные кончились, тогда и NAck

Ну пока я вижу что нужно это только для ограниченного кол-ва драйверов, а именно: для чтения серв и результатов ацп.
Вот для этого имхо не нужно перетряхивать все ядро.
И добавлять в структуру драйвера считаю лишним.

ПС: имхо этот диф не нужен, т.к. собственный процесс нужен малому кол-ву драйверов
проще (и экономней) сделать так:

Код: Выделить всё

GATE_RESULT init_my_driver(void)
{
    GATE_RESULT res;
    // ...
    // ...
    res = gate_driver_register(&driver);
    if (res == GR_OK) {
        res = gate_task_register(&task);
    }
    return res;
}


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

blindman писал(а):Драйвер может вернуть меньше данных чем у него запросили - когда данные кончились, тогда и NAck

В конце каждого чтения должен быть NAck. Если данных считали меньше и получили Ack в конце, то это ошибка.
Если мастер должен еще считать больше данных, но получил NAck, то это ошибка.

blindman писал(а):А что он будет делать если ее там нет? Просто тупо кончилась, и надо подгрузить?

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

blindman писал(а):Тебе не хватит 128 регистров на 1 драйвер? Да ты гигант

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

blindman писал(а):Где логика?

Я думал ты на уровне обращения к контролеру по уарту хочешь включать или нет этот бит.

blindman писал(а):Драйвер может вернуть меньше данных чем у него запросили - когда данные кончились, тогда и NAck

А так часто делают приличные люди?

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

Строго говоря, и для АЦП с сервами это не критично, я АЦП использовал лишь как пример. Но если действительно понадобится - придется не только ядро перетряхнуть, но и драйвера все.

Vooon писал(а):ПС: имхо этот диф не нужен, т.к. собственный процесс нужен малому кол-ву драйверов
проще (и экономней) сделать так:

Проще - вряд ли, экономнее - да. Отменил

blindman писал(а):Но если действительно понадобится - придется не только ядро перетряхнуть, но и драйвера все.

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

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

Кто обратится? Драйвер? К драйверу?

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

Помнить на уровне ядра надо в любом случае. Откуда ты определишь факт что это продолжение запроса или новый? Лучше в одном месте этот признак иметь, чем в каждом драйвере.

=DeaD= писал(а):Я думал ты на уровне обращения к контролеру по уарту хочешь включать или нет этот бит.

Не. это ядро его форировать будет

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

blindman писал(а):Драйвер может вернуть меньше данных чем у него запросили - когда данные кончились, тогда и NAck

А так часто делают приличные люди?

Как иначе?

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

А если 200 раз подряд обратились? Где ты таких буферов наберешься? И что ты так уперся в этот FF? Один бит передаваемый вместе с номером - идеальное решение.