roboforum.ru

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

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

Правила форума
Правила раздела OpenRobotics
Ответить

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

Vooon » 22 май 2009, 12:40

Сейчас доступ к порту байтовый, т.е. пишем сразу все 8 бит,
но зарезервированные пины не изменяются, используется маска.

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

Например можно сделать так:

Wllpp0701 — записать в бит 7 порта pp 1.
а
Wllpp04 — записать в порт pp 0x04

Версию драйвера предлагаю назначить 2.0.

ПС: да чаржер хороше бы, но к нему еще и 8 быстро-заряжаемых банок...
а так использую старые банки варта Ni-Mh 1700 mA/h

Добавлено спустя 23 секунды:
посадил за неделю

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

=DeaD= » 22 май 2009, 12:43

Побитовый доступ думаю лучше сделать не так, а с маской:

Передаём либо 1 байт - тогда выставляем все биты которые под управлением драйвера, либо 1 байт маски - что выставляем и 2 байт - содержимое.

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

Vooon » 22 май 2009, 12:46

хм, это отлично ложится на апи портов

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

=DeaD= » 22 май 2009, 12:56

В скелете драйвера предлагаю как-то так комменты поставить.

XX //In this function you must declare code, what will be executed, then kernel
XX // translate "read" request to your driver
XX //
XX //Input parameters:
XX // * reg - number register, passed in "read" request
XX // * data - pointer to data buffer, there we will place our answer
XX // * data_len - pointer to variable, in which we get buffer size and return answer size
48 static GATE_RESULT driver_read(uint8_t reg, uint8_t* data, uint8_t* data_len)
49 {
50 switch (reg) {
51 // ....
52 };
53 return GR_OK;
54 }

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

Vooon » 22 май 2009, 14:52

Да, документирование нужно, но оно вечно отстает от основной разработки :)

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

Объясняю для чего это нужно:
сейчас главный цикл выполняется один, весь прописан в serialgate.
и только во время вызова того или иного регистра выполняется код драйвера.
Но есть драйверы, которым требуется работать и остальное время.
Например драйверу пушки нужно отслеживать положение затвора, но пушка устройство медленное,
мы не можем на такое время останавливать шину (порядка 20-25 сек.)

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

Кстати в лего тоже сделаны задачи.

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

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

=DeaD= » 22 май 2009, 15:26

А давайте пока без простой оськи обойдёмся? :) И без общих таймеров, а потом выпустим второй релиз с ними? :)

Добавлено спустя 7 минут 13 секунд:
Хотя с АЦП и управлением моторами вопрос конечно... давайте соберем все драйверы которые нужно будет вести не только в момент запроса, или которые работают не атомарное время (т.е. больше скажем 30 тактов):

1. АЦП;
2. Моторы (шасси);
3. Сервы;
4. Датчик ёмкостный (линии, цвета поверхности).

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

blindman » 22 май 2009, 18:37

я сейчас занимаюсь драйвером серв на or-avr-m32, в процессе появляются мысли по использованию таймеров.

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

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

Vooon » 22 май 2009, 18:59

Ок, тогда ждем :)

Re: Разработка Open Robotics: Контроллер под сервы, SMD-вариант

Vooon » 23 май 2009, 15:05

Жаль у блиндмана с инетом напряги...

Здесь, как я понимаю, нужен будет свой драйвер серв, да и драйвер портов должен иметь другой UID.

Re: Разработка Open Robotics: Контроллер под сервы, SMD-вариант

=DeaD= » 23 май 2009, 15:07

Почему драйвер портов должен иметь другой UID?

Re: Разработка Open Robotics: Контроллер под сервы, SMD-вариант

Vooon » 23 май 2009, 15:12

Т.к. другой набор портов.
А моим программам на ПК нет дела до юидов, им главное чтоб в словаре регистров были их регистры

Re: Разработка Open Robotics: Контроллер под сервы, SMD-вариант

=DeaD= » 23 май 2009, 15:35

Хм, так UID'ов не напасешься :) надо чтобы драйвер сам говорил сколько у него портов. Мне так кажется. Чтобы программы на ПК можно было писать не заморачиваясь на то, какие сервоконтроллеры или GPIO-контроллеры подцепят.

Re: Разработка Open Robotics: Контроллер под сервы, SMD-вариант

blindman » 23 май 2009, 15:42

Согласен, что драйвер GPIO может быть единым для всех контроллеров

Re: Разработка Open Robotics: Контроллер под сервы, SMD-вариант

=DeaD= » 23 май 2009, 16:04

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

Добавлено спустя 3 минуты 18 секунд:
2blindman: Ждём обещанных выкладок, чтобы двигаться дальше по драйверам. Для OR-AVR-M64-S прошивку явно надо сразу по архитектуру ORFA делать, не под моё же старьё :)

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

blindman » 23 май 2009, 16:30

В общем мысли по использованию таймеров такие.

Таймеров у нас практически всегда не менее 3. При этом всегда один-два из них будут заняты под специфические функции - ШИМ для моторов + генерация импульсов для серв. Фактически, использовать мы можем для прочих целей только 1 8-битный таймер. Поэтому предлагаю закрепить 1 таймер за ядром. Ядро стартует таймер, который будет работать в непрерывном режиме. Разрешаем драйверам регистрировать 2 дополнительных функции. Одна реализует "основной цикл" драйвера, вероятнее всего в виде КА, другая - вызывается периодически по таймеру (обе функции опциональные). В основном цикле шлюза перебираем драйверы, и вызываем "основной цикл" каждого драйвера, который зарегистрировал соответствующую функцию.

При этом таймер может быть использован для отсчёта временных интервалов в тех драйверах, где это требуется, в "основном цикле" драйвера - например датчик линии или бампер. Каждый драйвер может на некоторое [разумное] время запрещать прерывания в своём в "основном цикле". Например, бамперу надо программно генерировать пачку импульсов определённой частоты - прерывания на это время желательно запретить.

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

=DeaD= писал(а):Для OR-AVR-M64-S прошивку явно надо сразу по архитектуру ORFA делать, не под моё же старьё :)

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


Rambler\'s Top100 Mail.ru counter