roboforum.ru

С уартом и и2ц согласен, там функции переписать. А с GPIO - мы жестко задаем что порт 8-битный, и каждый бит отвечает за одну ногу. А например в LPC2101 режим 32 ног задается 2 32-битными регистрами. И там описать порт как "адрес регистра конфигурации + адрес регистра ввода + адрес регистра вывода" не получится

А чего там задаётся? Ну или выйди в аську

А что мешает добавить условия сборки?
libserialgate.a можно cобрать для PC, если не дефайнить AVR_IO
который и определяет что использовать.
Добавить ARM7_LPC_IO и соответствующий код.

Драйвера желательно вынести, не очень удобно собирать проект: make clean && make program
приходится писать, вместо make program

Я говорю об инфраструктуре ORFA.

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

typedef struct GATE_PORT_ {
    uint8_t  number;/**< Уникальный номер, однозначно идентифицирующий порт */
    uint8_t* PORT;  /**< Адрес регистра PORTx в адресном пространстве ОЗУ */
    uint8_t* PIN;   /**< Адрес регистра PINx в адресном пространстве ОЗУ */
    uint8_t* DDR;   /**< Адрес регистра DDRx в адресном пространстве ОЗУ */
    uint8_t  default_busy_mask; /**< Маска, определяющая биты порта, которые не могут использоваться (например используются для внутренних целей контроллера) */
    uint8_t  busy_mask; /**< Маска, определяющая биты порта, которые используются драйверами устройств */
    struct GATE_PORT_* next;
} GATE_PORT;

Попробуйте описать в такой структуре конфигурацию порта на LPC2103

Да я понял о чем ты, там разве нельзя к регистрам обратиться через указатель? (uint32_t* reg)
А многие драйвера для арма будут другими, имхо это нормально.
Тем более что есть возможность спросить девайс "а что ты умеешь".

blindman писал(а):Я говорю об инфраструктуре ORFA.
Попробуйте описать в такой структуре конфигурацию порта на LPC2103

А что в этой структуре не так? Разве нельзя будет по ней задавать порты на LPC2103 превратив все 8-битки в 32-битки?

Vooon писал(а):Да я понял о чем ты, там разве нельзя к регистрам обратиться через указатель? (uint32_t* reg)

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

Правильное занятие - всячески за и готов участвовать

Я думаю вынести драйвера из libregisters.a

Предлагаю сделать так:

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

vovan@vovan-laptop:~/src/orfa/drivers$ tree
.
|-- OR-AVR-M168-DX
|   |-- motor_driver.c -> ../OR-AVR-M32-D/motor_driver.c
|   |-- motor_driver.h -> ../OR-AVR-M32-D/motor_driver.h
|   |-- ports_driver.c -> ../OR-AVR-M32-D/ports_driver.c
|   |-- ports_driver.h -> ../OR-AVR-M32-D/ports_driver.h
|   |-- spi_driver.c -> ../OR-AVR-M32-D/spi_driver.c
|   `-- spi_driver.h -> ../OR-AVR-M32-D/spi_driver.h
|-- OR-AVR-M32-D
|   |-- motor_driver.c
|   |-- motor_driver.h
|   |-- ports_driver.c
|   |-- ports_driver.h
|   |-- spi_driver.c
|   `-- spi_driver.h
`-- OR-AVR-M64-S
    |-- motor_driver.c -> ../OR-AVR-M32-D/motor_driver.c
    |-- motor_driver.h -> ../OR-AVR-M32-D/motor_driver.h
    |-- ports_driver.c -> ../OR-AVR-M32-D/ports_driver.c
    |-- ports_driver.h -> ../OR-AVR-M32-D/ports_driver.h
    |-- spi_driver.c -> ../OR-AVR-M32-D/spi_driver.c
    `-- spi_driver.h -> ../OR-AVR-M32-D/spi_driver.h

3 directories, 18 files

Т.е. для каждого модуля формируется свой набор драйверов, чтобы не отслеживать одинаковые драйвера
делать симлинки (у братьев наших меньших, с недавних пор тоже работает)
меркуриалом симлинки поддерживаются.

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

Добавлено спустя 17 минут 58 секунд:
Деад, я не согласен, что UID определяет только протокол драйвера
и для всех драйверов портов/моторов/т.д. он должен быть один, а определять по версии.

Нет Unique IDentificator на то и уникальный, что указывает на конкретный драйвер с его протоколом (может стандартным для всего класса уст-в а может и нет) и его ограничениями.

Например драйвер порта на M32 и M168 имеют разные параметры (кол-во портов)
почему они должны иметь один UID? Да протокол доступа один и тот-же, но портов то меньше!
Почему должна отличаться версия?

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

Vooon писал(а):Деад, я не согласен, что UID определяет только протокол драйвера
и для всех драйверов портов/моторов/т.д. он должен быть один, а определять по версии.

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

Vooon писал(а):Например драйвер порта на M32 и M168 имеют разные параметры (кол-во портов)
почему они должны иметь один UID? Да протокол доступа один и тот-же, но портов то меньше!
Почему должна отличаться версия?

Как это почему один UID? Это один тип устройства. Видеокарта - это всегда видеокарта, независимо от объема видеопамяти.

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

А вот здесь "это сразу нет!"

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

2. Если обеспечим обратную совместимость - не надо будет переписывать кучу софта на ПК который уже работает с этими драйверами, а мы тут выпустили новую версию.

Короче dll-ки с их версиями не дураки придумали.

Добавлено спустя 2 минуты 12 секунд:
Разумеется иногда надо будет сказать "Хватит" и сделать новый протокол, избавившись от груза атавизмов, которые поддерживаются для совместимости. Тогда и меняем UID, но мы сможем сделать это плавно - даже можно оба драйвера ставить в устройство - только старый UID помечаем как "Not for new design!".

Ладно, будем считать второе порывом все переделать...
А по первой части поста что скажете?

Драйвера раскидать - пока рано, пока всё делаем для OR-AVR-M32-D, ну и надо перевариться идее. Вроде тоже не горит?

Я вижу смысл раскидывать драйвера только если они будут универсальными, конфигурируемыми. Чтобы например при изменении набора портов можно было просто описать конфигурацию, и использовать готовый код драйвера.

Этот подход позволит четко определить в какой набор драйверов будет в конкретном контроллере
ну не может драйвер серв для -S быть совместимым с -D или -DX
хотя драйвер серв для -D может работать как на -DX, так и на -S.

Во время сборки добавляется дефайн используемого контроллера, практически они нужны
чтобы менять настройку масок в ports_driver.c и т.п.
Т.е. для смены конфигурации (возможно и для смены некоторых участков кода, характерных для конкретного МК)

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

Добавлено спустя 1 минуту 55 секунд:
Короче говоря: нужно подумать на изменениями скриптов сборки,
чтобы сборку можно было более гибко настраивать.

Я обычно все дефайны которые определяют опции для сборки помещаю в отдельный мэйкфайл, подключаемый в главном.