roboforum.ru

И еще UIDы разнёс по разным контроллерам зачем-то может всё-таки не надо?

Добавлено спустя 17 минут 49 секунд:
Я предлагаю интроспектором отвечать на запрос 0xFF последовательностью из 2 байт, в которой каждый бит 0..15 (A-Q) - это есть или нет этот порт на МК среди GPIO портов. Т.е. на OR-AVR-M32-D это будет
11110000b, 00000000b

На OR-AVR-M128-S это будет
10000100b, 00000000b

Внутри порты нумеруются по порядку букв, т.е. в регистрах GPIO на OR-AVR-M32-D будут в порядке A,B,C,D, а на OR-AVR-M128-S будут A,F.

Странно, я вроде комитил последний код, в котором я отказался от эвента для запуска супертаска...

Добавлено спустя 10 минут 45 секунд:
Исправил.

Добавил драйвер серв для OR-AVR-M64-S.

2 регистра. Нулевой пока зарезервировал. Базовый номер регистра сервоконтроллера в текущей сборке - 0x0C.

Код: Выделить всё • Развернуть

L 40
S 40 00 01 S 41 06 P
SWAASR003001000C02P
# Установить длительность импульса на выходе №17 в 1200 мкс (0x04B0)
S 40 0D 11 B004 P
SWAAAAP
# Установить длительность импульса на выходах 0,1,2 в 512, 768 и 1024 мкс
S 40 0D 00 0002 01 0003 02 0004 P
SWAAAAAAAAAAP

blindman писал(а):Следует ли сделать 8 регистров, по 1 на канал?

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

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

Конечно же нет, обязательно возвращаем 8 бит, если не в 11 битном режиме.

blindman писал(а):Драйвер не знает, сколько байт запрошено для чтения. Это не дает возможности эффективно реализовать автоинкремент. Например драйвер АЦП может выдать до 8 значений - но я вынужден был сделать, чтобы он всегда выдавал все значения до конца таблицы. Предлагаю в параметре data_len передавать драйверу количество запрошенных байт, а не доступный размер буфера.

Чем это плохо? Производительность?

blindman писал(а):Надо определиться с порядком байт для 2-байтных(и более) значений. Мне кажется естественным передавать сначала младший байт, именно такой порядок используется в контроллерах AVR.

Чисто визуально это будет тяжелее для понимания. Хотя мне всё равно, но как-то зафиксировать это надо.

Вопрос не решился. Попробую поподробнее описать суть проблемы.

Если работаем через уарт - проблем нет, количество байт для чтения известно до обращения к драйверу. Но при использовании шлюза как подчиненного на I2C, количество байт неизвестно, нужно возвращать по одному пока не прекратятся запросы. Вижу 2 варианта

1. При поступлении запроса на чтение из регистра запрашиваем у драйвера некоторое количество байт и помещаем их в буфер. Байты выдаем из буфера, пока он не опустеет, затем опять обращаемся к драйверу за новой порцией. Состояние буфера сохраняем, и если следующий запрос приходит на чтение из того же регистра, сначала выдаем данные из буфера, иначе буфер сбрасываем, и обращаемся к соответствующему драйверу за порцией данных.
   Pro:
   • Относительная простота реализации
   • Быстродействие
   Contra:
   
   • Если между обращениями к одному регистру будут обращения к другому, часть данных будет потеряна.
2. Запрашиваем данные у драйвера по одному байту. Драйвер при этом, если необходимо, поддерживает [небольшой] внутренний буфер.
   Pro:
   • Произвольная последовательность обращения к регистрам
   • Нет потерь данных
   Contra:
   
   • Более сложная логика работы драйвера
   • Снижение быстродействия

В общем, обычный выбор быстро/хорошо/дёшево

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

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

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

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

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

Почему это не знаем, если это явно прописывается в запросе?