roboforum.ru

Технический форум по робототехнике.


Обсуждение реализации шлюз-контроллера [ORFA]

Разработка стандартизированных модулей для домашнего робостроения.
Правила форума
Правила раздела OpenRobotics

Re: Обсуждение реализации шлюз-контроллера [ORFA]

Сообщение blindman » 17 май 2009, 15:27

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

Day OFF? You must be pulling my leg! Stop making humor before someone sees you, fool!

Аватара пользователя
blindman
 
Сообщения: 4130
Зарегистрирован: 29 апр 2008, 21:15
Откуда: Хабаровск
прог. языки: C,C++,Assembler,PHP,Javascript,Ruby, SPIN,Java(?)
ФИО: Андрей Юрьевич

Re: Обсуждение реализации шлюз-контроллера [ORFA]

Сообщение =DeaD= » 17 май 2009, 15:32

А чего там задаётся? Ну или выйди в аську :)
Проект [[Open Robotics]] - Универсальные модули для построения роботов
Аватара пользователя
=DeaD=
 
Сообщения: 24218
Зарегистрирован: 06 окт 2004, 18:01
Откуда: Ебург
прог. языки: C++ / PHP / 1C
ФИО: Антон Ботов

Re: Обсуждение реализации шлюз-контроллера [ORFA]

Сообщение Vooon » 17 май 2009, 16:28

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

Драйвера желательно вынести, не очень удобно собирать проект: make clean && make program
приходится писать, вместо make program
Linux user | Firefox user
Аватара пользователя
Vooon
Site Admin
 
Сообщения: 3339
Зарегистрирован: 09 фев 2006, 15:36
Откуда: Москва
Skype: vooon341
прог. языки: Python, C, Bash, JavaScript, C++, PHP
ФИО: Владимир Ермаков

Re: Обсуждение реализации шлюз-контроллера [ORFA]

Сообщение blindman » 17 май 2009, 16:33

Я говорю об инфраструктуре 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
Проект [[Open Robotics]] - универсальные модули для построения роботов
Модули Open Robotics можно приобрести в магазине shop.roboforum.ru

Day OFF? You must be pulling my leg! Stop making humor before someone sees you, fool!

Аватара пользователя
blindman
 
Сообщения: 4130
Зарегистрирован: 29 апр 2008, 21:15
Откуда: Хабаровск
прог. языки: C,C++,Assembler,PHP,Javascript,Ruby, SPIN,Java(?)
ФИО: Андрей Юрьевич

Re: Обсуждение реализации шлюз-контроллера [ORFA]

Сообщение Vooon » 17 май 2009, 16:43

Да я понял о чем ты, там разве нельзя к регистрам обратиться через указатель? (uint32_t* reg)
А многие драйвера для арма будут другими, имхо это нормально.
Тем более что есть возможность спросить девайс "а что ты умеешь".
Linux user | Firefox user
Аватара пользователя
Vooon
Site Admin
 
Сообщения: 3339
Зарегистрирован: 09 фев 2006, 15:36
Откуда: Москва
Skype: vooon341
прог. языки: Python, C, Bash, JavaScript, C++, PHP
ФИО: Владимир Ермаков

Re: Обсуждение реализации шлюз-контроллера [ORFA]

Сообщение =DeaD= » 17 май 2009, 16:52

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

А что в этой структуре не так? Разве нельзя будет по ней задавать порты на LPC2103 превратив все 8-битки в 32-битки?
Проект [[Open Robotics]] - Универсальные модули для построения роботов
Аватара пользователя
=DeaD=
 
Сообщения: 24218
Зарегистрирован: 06 окт 2004, 18:01
Откуда: Ебург
прог. языки: C++ / PHP / 1C
ФИО: Антон Ботов

Re: Обсуждение реализации шлюз-контроллера [ORFA]

Сообщение blindman » 17 май 2009, 16:53

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


Да, можно. Я хочу избежать ситуации, когда при переходе на новый процессор прийдется перекраивать софт для старого, чтобы он был совместимым с новым. Вот и ищу, где могут быть грабли.
Проект [[Open Robotics]] - универсальные модули для построения роботов
Модули Open Robotics можно приобрести в магазине shop.roboforum.ru

Day OFF? You must be pulling my leg! Stop making humor before someone sees you, fool!

Аватара пользователя
blindman
 
Сообщения: 4130
Зарегистрирован: 29 апр 2008, 21:15
Откуда: Хабаровск
прог. языки: C,C++,Assembler,PHP,Javascript,Ruby, SPIN,Java(?)
ФИО: Андрей Юрьевич

Re: Обсуждение реализации шлюз-контроллера [ORFA]

Сообщение =DeaD= » 17 май 2009, 16:54

Правильное занятие - всячески за и готов участвовать :)
Проект [[Open Robotics]] - Универсальные модули для построения роботов
Аватара пользователя
=DeaD=
 
Сообщения: 24218
Зарегистрирован: 06 окт 2004, 18:01
Откуда: Ебург
прог. языки: C++ / PHP / 1C
ФИО: Антон Ботов

Re: Обсуждение реализации шлюз-контроллера [ORFA]

Сообщение Vooon » 19 май 2009, 18:07

Я думаю вынести драйвера из 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а?
Да ни чем, имхо даже удобней было-бы: есть одна таблица идов со всеми параметрами драйвера,
а неизвестные параметры мы точно знаем как запросить.
Linux user | Firefox user
Аватара пользователя
Vooon
Site Admin
 
Сообщения: 3339
Зарегистрирован: 09 фев 2006, 15:36
Откуда: Москва
Skype: vooon341
прог. языки: Python, C, Bash, JavaScript, C++, PHP
ФИО: Владимир Ермаков

Re: Обсуждение реализации шлюз-контроллера [ORFA]

Сообщение =DeaD= » 19 май 2009, 18:40

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

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

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

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

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

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

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

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

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

Добавлено спустя 2 минуты 12 секунд:
Разумеется иногда надо будет сказать "Хватит" и сделать новый протокол, избавившись от груза атавизмов, которые поддерживаются для совместимости. Тогда и меняем UID, но мы сможем сделать это плавно - даже можно оба драйвера ставить в устройство - только старый UID помечаем как "Not for new design!".
Проект [[Open Robotics]] - Универсальные модули для построения роботов
Аватара пользователя
=DeaD=
 
Сообщения: 24218
Зарегистрирован: 06 окт 2004, 18:01
Откуда: Ебург
прог. языки: C++ / PHP / 1C
ФИО: Антон Ботов

Re: Обсуждение реализации шлюз-контроллера [ORFA]

Сообщение Vooon » 19 май 2009, 19:43

Ладно, будем считать второе порывом все переделать... :)
А по первой части поста что скажете?
Linux user | Firefox user
Аватара пользователя
Vooon
Site Admin
 
Сообщения: 3339
Зарегистрирован: 09 фев 2006, 15:36
Откуда: Москва
Skype: vooon341
прог. языки: Python, C, Bash, JavaScript, C++, PHP
ФИО: Владимир Ермаков

Re: Обсуждение реализации шлюз-контроллера [ORFA]

Сообщение =DeaD= » 19 май 2009, 19:44

Драйвера раскидать - пока рано, пока всё делаем для OR-AVR-M32-D, ну и надо перевариться идее. Вроде тоже не горит?
Проект [[Open Robotics]] - Универсальные модули для построения роботов
Аватара пользователя
=DeaD=
 
Сообщения: 24218
Зарегистрирован: 06 окт 2004, 18:01
Откуда: Ебург
прог. языки: C++ / PHP / 1C
ФИО: Антон Ботов

Re: Обсуждение реализации шлюз-контроллера [ORFA]

Сообщение blindman » 19 май 2009, 19:49

Я вижу смысл раскидывать драйвера только если они будут универсальными, конфигурируемыми. Чтобы например при изменении набора портов можно было просто описать конфигурацию, и использовать готовый код драйвера.
Проект [[Open Robotics]] - универсальные модули для построения роботов
Модули Open Robotics можно приобрести в магазине shop.roboforum.ru

Day OFF? You must be pulling my leg! Stop making humor before someone sees you, fool!

Аватара пользователя
blindman
 
Сообщения: 4130
Зарегистрирован: 29 апр 2008, 21:15
Откуда: Хабаровск
прог. языки: C,C++,Assembler,PHP,Javascript,Ruby, SPIN,Java(?)
ФИО: Андрей Юрьевич

Re: Обсуждение реализации шлюз-контроллера [ORFA]

Сообщение Vooon » 19 май 2009, 20:08

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

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

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

Добавлено спустя 1 минуту 55 секунд:
Короче говоря: нужно подумать на изменениями скриптов сборки,
чтобы сборку можно было более гибко настраивать.
Linux user | Firefox user
Аватара пользователя
Vooon
Site Admin
 
Сообщения: 3339
Зарегистрирован: 09 фев 2006, 15:36
Откуда: Москва
Skype: vooon341
прог. языки: Python, C, Bash, JavaScript, C++, PHP
ФИО: Владимир Ермаков

Re: Обсуждение реализации шлюз-контроллера [ORFA]

Сообщение blindman » 19 май 2009, 20:12

Я обычно все дефайны которые определяют опции для сборки помещаю в отдельный мэйкфайл, подключаемый в главном.
Проект [[Open Robotics]] - универсальные модули для построения роботов
Модули Open Robotics можно приобрести в магазине shop.roboforum.ru

Day OFF? You must be pulling my leg! Stop making humor before someone sees you, fool!

Аватара пользователя
blindman
 
Сообщения: 4130
Зарегистрирован: 29 апр 2008, 21:15
Откуда: Хабаровск
прог. языки: C,C++,Assembler,PHP,Javascript,Ruby, SPIN,Java(?)
ФИО: Андрей Юрьевич

Пред.След.

Вернуться в Open Robotics

Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 1

Mail.ru counter