вопрос безотносительно к бутлоадеру (не знаю где обсуждение) - протокол не поразумевает инициативу робота при общении. То есть если сработал бампер или другой сенсор - ПК не узнает об этом, если сам не спросит?
Именно, в этой системе не реализована возможность подписки на сервисы, как это сделано в концепции MSRS. В дальнейшем может быть пересмотрим подход для совместимости со студией.
Добавлено спустя 44 секунды: Но всё равно подход может быть максимум поменян на уровне UART до ПК, на шине I2C так уж повелось, что мастер всех опрашивать должен.
подумал, может я что-то упустил. Продолжаю потихоньку свой проект, подумал, что в [[MiniBot-SerControl]] протокол уже в некоторой степени реализован, так что его взял. Но обнаружил, что сенсоры не инициируют события. А вообще обсуждение этой темы где-то есть - чтобы из темы про бутлоадер вынести? И есть ли вариант такой прошивки под стандартную конфигурацию Минибота? Думаю, что не все готовы припаивать другой кварц и переустанавливать под него фьюзы (хотя под бутлоадер все равно придется), а проект интересный.
SMT писал(а):Но обнаружил, что сенсоры не инициируют события.
Как же i2c сонар или ИК-дальномер может инициировать события? так что всё это будет реально опрос, я не вижу пока критичной разницы через что опрашивать, особенно если у нас пока не 100 сенсоров.
=DeaD= писал(а):Как же i2c сонар или ИК-дальномер может инициировать события?
имелось ввиду, что при управлении роботом с ПК робот не только получает с ПК команды, но и сообщает ПК о "интересных" изменениях состояний своих сенсоров - МК робота опрашивает сенсоры, если это требуется, и при необходимости посылает сообщение об измененях на ПК. Например: щелкнул бампер - сообщаем об этом ПК. МК робота ведь проще опросить свои сенсоры, чем ПК опросит их через радиоканал канал. Или мы о разном говорим?
SMT писал(а):сообщает ПК о "интересных" изменениях состояний своих сенсоров
Это о каких интересных? Эдак мы и до программирования МК опять уйдём. Это же от программы зависит чего ей интересно. ИК-дальномеры шарп и сонары вообще каждый раз разные измерения дают, а уже в головной программе смотрим чего с ними делать - или нижнюю границу ставить или складывать 3 измерения подряд или еще что...
mandigit писал(а):Например: щелкнул бампер - сообщаем об этом ПК. МК робота ведь проще опросить свои сенсоры, чем ПК опросит их через радиоканал канал. Или мы о разном говорим?
О разном вы говорите о простых сенсорах типа бампер, а я о сложных, выдающих инфу с погрешностью, вот её и нельзя понять как часто выдавать и в каком виде - это вопрос верхнего уровня и конкретного алгоритма.
а не согласен с ПК мы можем указать - какой сенсор интересен и на каких значениях о нем сообщать. А в роботе все равно нужно некоторую логику держать типа BIOS-а, для работы с "низкоуровневыми" устройствами. Как в DOS-е - можно было комфортно так через 21-е прерывание работать, а можно аккуратненько через 10-е - из BIOSа
В текущей реализации все запросы генерирует мастер. В принципе я уже думал добавить регистр состояния, опрашивая который, мастер может понять что произошло.
SMT писал(а):а не согласен с ПК мы можем указать - какой сенсор интересен и на каких значениях о нем сообщать. А в роботе все равно нужно некоторую логику держать типа BIOS-а, для работы с "низкоуровневыми" устройствами. Как в DOS-е - можно было комфортно так через 21-е прерывание работать, а можно аккуратненько через 10-е - из BIOSа
А понимаю, но это всё равно почти DSS надо на МК тогда городить, чтобы полноценно и концептуально было, а нам пока не до этого. Да ресурсы там не те...
Vooon писал(а):Бутлоадер есть и под стандартного минибота
ха, так я за него и благодарил - поставил уже и программирую успешно
Добавлено спустя 2 минуты 57 секунд:
=DeaD= писал(а):А понимаю, но это всё равно почти DSS надо на МК тогда городить, чтобы полноценно и концептуально было, а нам пока не до этого. Да ресурсы там не те...
ну ты это загнул, кажись ничего, что я снова на ты опрашивать запрошенные с ПК датчики или обработать затребованное прерывание разве просто в цикле не достаточно?
SMT писал(а):ну ты это загнул, кажись ничего, что я снова на ты опрашивать запрошенные с ПК датчики или обработать затребованное прерывание разве просто в цикле не достаточно?
Да ничего конечно
Это на словах всё так просто, но ведь в DSS нагорожено не просто так всё. А частота опроса разных датчиков совпадать должна? Так это менее эффективно и управляемо тогда, чем у меня в шлюзе. А механизм подписки на какие-то датчики, и запрос на остановку подписки? Дальше продолжать?
не, не продолжай - я наверное понял. Имеется ввиду довольно простое устройство - пока еще не манипулятор с N-степенями свободы и защитой от коллизий. Если рассматривать робот в смысле мультиплексора, обеспечивающего раздачу и сбор данных с сенсоров и исполнительных механизмов, то его мозгов для этого должно как раз хватить. А вот что делать с этими данными - это как раз задача DSS на ПК.
Самое главное - если сделать тупо трансляцию инфы с робота, тогда надо бесконечный канал, чтобы все датчики 100% на нужных частотах вещали, а этого не бывает
наверно я все-же что-то не улавливаю. Это для ASIMO, если его контролировать удаленно с ПК нужен такой канал, но вряд-ли для миниробота, у которого часть информации обрабатывается или отсеивается на борту, а какие-то функции (типа "проехать до конца стенки" и сообщить о завершении команды) он вообще по одной команде может делать.
так что всё это будет реально опрос, я не вижу пока критичной разницы через что опрашивать, особенно если у нас пока не 100 сенсоров.
ничего, что я снова на ты 
