art_zh, ничего личного, ваша тема важна, но все-таки не совсем попадает в рамки этой =)
тут скорее уместнее будет прогресс работы над использованием Колибри на конкретных аппаратах, кои в начале темы показаны
Колибри в робототехнике
-
И мы уже давно не пешки,
Мы пули, мы орлы, и решки!
Война ютит бинарный код,
Умри, или иди вперед!
да дорогой, ты совершенно запутался. ИлиGluk wrote:Нужно всего лишь создать тему "Детали для роботов, безотносительно Колибри" в разделе "Разное", перенести соответствующие посты туда, и попросить модератора перенести вышеописанную тему в соответствующий раздел ("Оффтоп").
Разницу между словами детали, узел, устройство неужели не видно?art_zh wrote:в упор не желаешь видеть
Мне удивительно думать, что это не понятно современным студентам...
Раз все так сложно, расставим точки над Ё.
Детали, например: колеса, аккумулятор, корпус, гайки, оси, тяги.
К устройствам уверенно можно относить любую сборочную единицу, комплесное изделие: муфта, двигатель, плата управления, управляющий контроллер, коробка передач.
Так вот. Я ведь про детали речь не вел, я про устройства. Причем не механические, а интеллектуально-программные, комплесные. Это мат-платы со стороны ОСи с одной стороны и серва, например с другой или движёк совместно с его контроллером.
Хочешь Колибри? Пожалуйста. Операционная система Колибри, равно, как любая другая операционная система, предполагает выполнение "ряда операций" над "внутренним" и внешним оборудованием. В данном сабже основное ударение логично упирается именно во внешние.
Внешние - это физические интерфейсы и соответственно их логические интерфейсы.
В широком общем смысле физика интерфейсов - это порты ввода-вывода.
Алгоритмическая логика работы с ними тем или иным способом - это и есть логический интерфейс.
Оба они предполагают драйверное решение. Как правило это отдельные драйвера.
Хороший, наглядный пример - семиуровневая модель Ethernet. Там и физика и логика. Все разфасовано.
Контроллеры сервомашин и приводов, что выше приведены, имеют "интеллектуальное общение", т.е. и физический и логический (команды) интерфейсы. Заюзав их получают полномасштабное управление (по паспорту изделия) приводом в комплексе! Т.е. это и мотор и контроллер в целом.
Должно быть понятно, так же, что на стыке контроллер-мотор тоже есть "физика" и логика интерфейса. Интерфейса мотора, как ни странно это может звучать.
В самом общем смысле, цель его, применительно к безколлекторным движкам - создание эффективного вращающегося магнитного поля внутри мотора!
"Физика" тут - импульсы постоянного тока нужной ширины и периодичности во времени, которая определяется "логикой", т.е. программной реализацией "внутри контроллера" мотора!
Чтобы заюзать комплекс: контроллер + мотор, их нужно либо УЖЕ знать. Либо разобраться, изучить, освоить, создать драйвер...
Если не знать, что, как в каком формате нужно послать, скажем по COM порту контроллеру двигателя, то как его использовать? ОтветЫ более чем очевидны!
Уважаемые Гуру. Если не затруднит, можете обрисовать принцип работы с СОМ-портом из Колибри? Есть задумка написать программу для связи с платой Arduino. На ардуинках много народу делает простейших роботов, поэтому, думаю, и Сообществу будет полезно.
Соединяй, и здравствуй.
Eruman, есть два варианта - юзермодное приложение и драйвер. Пример юзермодного приложения есть в SDK - rtdata.asm, в качестве примера драйвера можно посмотреть на драйвер com-мыши com_mouse.asm из исходных текстов дистрибутива.
Сделаем мир лучше!
Eruman
Это конечно хорошая идея, но насколько она актуальна? Сейчас практически все дуинки идут с преобразователем USB->UART (например, на FT232). Да и заливать скетчи из КОС смысла нет (нет Java). Думаю лучше начать с терминала типа Serial Monitor.
Если реализуешь что-нибудь для COM-портов или Arduino, могу попытаться потестировать.
Это конечно хорошая идея, но насколько она актуальна? Сейчас практически все дуинки идут с преобразователем USB->UART (например, на FT232). Да и заливать скетчи из КОС смысла нет (нет Java). Думаю лучше начать с терминала типа Serial Monitor.
Если реализуешь что-нибудь для COM-портов или Arduino, могу попытаться потестировать.
2Albom: В дуинки заливается обычный поток данных, насколько помню. Загрузчик хавает и перепрошивает МК. Если ему правильно дать посылку - перепрошьется на ура.
Я говорил пока только о связи с дуинкой. Т.е. есть прошитый МК, к нему по ЮАРТ приходят байты и уходят байты. Вот такую слушалку-отсылалку на стороне Колибри и думаю накрутить. Не более, пока.
Про USB: в дуинке между УСБ и МК есть преобразователь, минуя который можно прекрасно связываться с UART непосредственно микроконтроллера.
2CleverMouse: Драйвер - это круто
rtdata.asm в дистре Колибри не нашел, но в Минуэтовском есть. Похоже это то, что мне надо, буду изучать. Спасибо.
Я говорил пока только о связи с дуинкой. Т.е. есть прошитый МК, к нему по ЮАРТ приходят байты и уходят байты. Вот такую слушалку-отсылалку на стороне Колибри и думаю накрутить. Не более, пока.
Про USB: в дуинке между УСБ и МК есть преобразователь, минуя который можно прекрасно связываться с UART непосредственно микроконтроллера.
2CleverMouse: Драйвер - это круто
rtdata.asm в дистре Колибри не нашел, но в Минуэтовском есть. Похоже это то, что мне надо, буду изучать. Спасибо.
Соединяй, и здравствуй.
лет 7 назад создал "юзермодное" приложение для работы с COM портами под менуэтом...Eruman wrote:можете обрисовать принцип работы с СОМ-портом из Колибри?
После длительных боев с проблемой "потери байт" при дуплесном обмене через нульмодемный кабелек COM1-COM2 сначала пришел к тому что:
- скорость более ~56000 нельзя получить в принципе даже с FIFO 16 байт
- затем понял, что нужен полноценный драйвер со всеми "реалиями IRQ" для конкретного COMа
- затем понял, что ядро нужно переписывать, а не плодить еще один COM костыль, т.к. это лишь единичный случай из обильного списка темы "ядро-драйвера"...
В Колибри тебе, под реализацию COM портовых дел только листинг драйверка под COM-мышь подойдет "com_mouse.asm" с адаптацией естественно хотябы "под себя".
Он без существенных изменений из менуэта пришел и заточен только на 1200 скорость...
Про юзермод забудь сразу, разве что тебе уверенная и надежная скорость типа 9600...38400 - за глаза хватит и тяп-ляп реализация прокатывает.
Eruman
Да, всё верно, обычный поток и UART после ft232 (не на всех, но есть). Я имел в виду, что разработку вести не получится (т.е. скомпилировать скетч). А для связи - просто замечательно должно получиться, даже на скорости 9600. Сейчас делаю самодельную дуинку (уже имею Freeduino 2009), в которой можно будет переключать USB или RS232.
Да, всё верно, обычный поток и UART после ft232 (не на всех, но есть). Я имел в виду, что разработку вести не получится (т.е. скомпилировать скетч). А для связи - просто замечательно должно получиться, даже на скорости 9600. Сейчас делаю самодельную дуинку (уже имею Freeduino 2009), в которой можно будет переключать USB или RS232.
я получаю данные на СОМ порт со скоростью 115200 и битых пакетов ~1,5%... сеть RS485 ~200м. + RS232 3м.
*****:
;дух машины, мой бубен сильнее твоей тупости
*****:
;дух машины, мой бубен сильнее твоей тупости
*****:
скорость собственно это еще не все, что нужно...
Есть такое понятие, как пропускная способность канала (количество полезной информации в единицу времени), которая со стороны ядра лимитируется для COMов за счет непроизводительной работы при работе с портами "напрямую" через API и без аппаратных вещей DMA, IRQ...
хотя наличие 16 байтного FIFO у UARTа 16С550 (например, как самый ходовой на PCях) в некотором роде сглаживает ситуацию, но это далеко от совершенства при работе с потоковыми последовательными асинхронными приемо-предачами канала связи(ей).
"под этим соусом" пост за 25 апреля viewtopic.php?f=25&t=897&p=32958#p32958 чтобы "понять расклад", как оно есть в широком смысле, остался без ответа...
полный, непрерывный дуплекс без пауз и ожиданий... битовые потоки "в обе струи" - вот такой тестинг этой проблемы.VaStaNi wrote:с проблемой "потери байт" при дуплесном обмене
Есть такое понятие, как пропускная способность канала (количество полезной информации в единицу времени), которая со стороны ядра лимитируется для COMов за счет непроизводительной работы при работе с портами "напрямую" через API и без аппаратных вещей DMA, IRQ...
хотя наличие 16 байтного FIFO у UARTа 16С550 (например, как самый ходовой на PCях) в некотором роде сглаживает ситуацию, но это далеко от совершенства при работе с потоковыми последовательными асинхронными приемо-предачами канала связи(ей).
"под этим соусом" пост за 25 апреля viewtopic.php?f=25&t=897&p=32958#p32958 чтобы "понять расклад", как оно есть в широком смысле, остался без ответа...
Eruman, rtdata.asm не в дистрибутиве, он в SDK.
Сделаем мир лучше!
Да, уже скачал/нашел/ковыряю. Спасибо
Соединяй, и здравствуй.
Возвращаясь к оригинальной теме этой ветки, закинул удочку на сайте англоязычных роботостроителей на базе Vortex86DX (тех, что используют специальную доску с сервомоторами): http://robosavvy.com/forum/viewtopic.php?p=31446
Авось кто-нибудь заинтересуется
Авось кто-нибудь заинтересуется
Так как там Энергия 3.0? Ездит уже? Фото есть?
нет, нет =(
И мы уже давно не пешки,
Мы пули, мы орлы, и решки!
Война ютит бинарный код,
Умри, или иди вперед!
Мы пули, мы орлы, и решки!
Война ютит бинарный код,
Умри, или иди вперед!
Who is online
Users browsing this forum: No registered users and 1 guest