roboforum.ru

Виктор Казаринов писал(а):Вот и к нормальному решению приходим. Без обычного PC со всеми его приладами навряд ли в дальнейшем можно что-то интересное сделать в робототехнике.

Ну это не нормальное, это "начального уровня", нормальное полноценное это будет OR-USB-UART + OR-AVR-M128-DS

Виктор Казаринов писал(а):Я так полагаю, что относительно легко можно будет этот контроллер дооснащать всякими-разными программами на PC? Тогда либо непосредственно по железу программировать придется, либо желательно чтобы были родные драйверы от производителя шелезяки как и на все обычное железо для PC с простым, удобным API и хорошей документацие и примерами.

Копаем в сторону ROS.

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

Dmitri Vladimirovich писал(а):Я за 16МГц
У меня до 480200Бод нормально без ошибок на 16Мгц
Зато не надо будет пересобирать бутлоадер, и будут нормально работать скорости в районе 9600. 57600 для отладки уже не к чему, в глазах рябит.

Ничего не понял

1. 9600 на кварцах 7372800 и 14742800 нормально работает, или я чего-то не знаю?
2. А как связаны рябь и скорость передачи? Вроде всегда проблема была в частоте вывода с МК, иначе буфер на МК тупо переполнится и всё. Это ведь не задача UART'а ограничивать скорость вывода на экран. Не?

Dmitri Vladimirovich писал(а):Если 14.76** необходимо, то может тогда поставить SIP разъем, а в комплект какой нибудь один класть? Я почти на все свои борды такой сокет для кварца ставлю

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

Ага, я только что ROS хотел упомянуть. Мне мое нутро подсказывает, что как бы с ROS не получилось как и с MSRS.
Если все здесь более игрушечное, то зачем такой сложный инструмент на все случаи жизни как ROS? М.б. тут нужна PicoROS?

9600 на кварцах 7372800 и 14742800 нормально работает, или я чего-то не знаю?

Вот у меня на M128-DS частота 9600 не то что глючит, оно просто не работает! Там какие - то символы идут и все.

А как связаны рябь и скорость передачи? Вроде всегда проблема была в частоте вывода с МК, иначе буфер на МК тупо переполнится и всё. Это ведь не задача UART'а ограничивать скорость вывода на экран. Не?

Ну допустим если у меня примитивная прога, которая считает энкодеры и выводит их на экран,

то на 115200 я вообще в терминале не вижу что пишется, а на 9600 все ок.

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

Это я имею ввиду, если вы соберете таки бутлоадер на 14Мгц, то чтоб была возможность выбора. Либо Ардуиновский на 16Мгц, либо Ваш на 14Мгц

Виктор Казаринов писал(а):Если все здесь более игрушечное, то зачем такой сложный инструмент на все случаи жизни как ROS? М.б. тут нужна PicoROS?

И запускать её будем под PicoWindows или PicoLinux?

Нет уж, пора приобщаться к актуальным разработкам. Там всё достаточно просто и правильно, что в ROS, что в MSRS, просто MSRS закрытый продукт и не смогла его MS прокачать, а ROS открытый и активно развивается.

Добавлено спустя 2 минуты 8 секунд:

Dmitri Vladimirovich писал(а):Вот у меня на M128-DS частота 9600 не то что глючит, оно просто не работает! Там какие - то символы идут и все.

Условия эксперимента в студию. Только в соотв. ветку про Arduino IDE и OR-AVR-M128-*.

Dmitri Vladimirovich писал(а):Ну допустим если у меня примитивная прога, которая считает энкодеры и выводит их на экран, то на 115200 я вообще в терминале не вижу что пишется, а на 9600 все ок.

Ну ты же частоту процессора в ПК не снижаешь чтобы вывод на экран замедлить? А тут с чего такие неожиданные ходы?

Dmitri Vladimirovich писал(а):Это я имею ввиду, если вы соберете таки бутлоадер на 14Мгц, то чтоб была возможность выбора. Либо Ардуиновский на 16Мгц, либо Ваш на 14Мгц

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

только отсутствие готового бутлоадера

Добавлено спустя 52 секунды:

Ну ты же частоту процессора в ПК не снижаешь чтобы вывод на экран замедлить? А тут с чего такие неожиданные ходы?

по незнанию

Добавлено спустя 48 секунд:

отдельный пин городить не хочется

в каком смысле отдельный пин?

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

За 14'7456МГц практически гарантированное отсутствие ошибок в UART на высоких скоростях.
За 16МГц отсутствие необходимости править/заменять boards.txt в Arduino IDE.

Готовый бутлоадер на любую скорость не есть проблема.

Добавлено спустя 59 секунд:
С точки зрения нас - нам конечно проще поставить 16МГц, чтобы не париться с поддержкой актуального boards.txt

Добавлено спустя 3 минуты 16 секунд:
Но на ардуино-форумах пишут:

16mhz (default on most arduino) gives 3.7% error, which usually is too much for the other side to work without error correction.

Тогда не знаю. Как по мне так вполне 16Мгц со скоростью в 57600 хватило бы. Для тележки с парой тройкой дальномеров, парой серв, двумя моторами и нетбуком. С ручным управлением и простенькой автономностью типа бегать по комнате и упираться в препятствия, а по вайфаю передавать карту местности.

И потом - половина моих знакомых, работавших с Ардуино в глаза не видели файл boards.txt

Возможно сделаем просто два варианта - кому какой надо, тот такой и берет

Тогда помойму мы отходим от смысла данного модуля. Это ведь вариант для новичков, так?
И задачи на нем будут выполняться типа таких, как я написал. Зачем для таких задач скорость в 1МБод?

Я думаю что тут надо оставить 16 Мгц, а поддержку суперскоростей включить уже в более серьезный модуль на АТмега128

Добавлено спустя 58 секунд:
ИМХО

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

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

Хотя аудитория, которая захочет запрограммировать такой модуль на Arduino IDE тоже скорее всего окажется не так уж и мала, так что для начала попробуем делать оба варианта, а там посмотрим что людям надо, благо для этого не нужно делать две разные платы или заказывать разный монтаж

Ок

Добавлено спустя 3 минуты 17 секунд:
Ждем выпуска

Что за !!!
Смотреть http://media.vehq.ru/avr/bauds.html просвещаться.

Ты имеешь в виду что 115200 на 16МГц нормально будет или что?

Я понятия не имею, как часто ненулевой % ошибки даёт реальную ошибку в передаче

=DeaD= писал(а):115200 на 16МГц нормально будет или что?

из практики при U2X=1 - нормально, если на другом конце скорость точно стоит.

Добавлено спустя 5 минут 13 секунд:

=DeaD= писал(а):Я понятия не имею, как часто ненулевой % ошибки даёт реальную ошибку в передаче

Эмм... да там практически детерминировано все. От длины фрейма зависит. Ошибка в скорости на 5% дает гарантированную ошибку в передаче.
В худшем случае (эти 5% делятся поровну между приемником и передатчиком) по 2.5% на сторону. Ну, с небольшими вариациями в зависимости от хитроумности конструкторов конкретного УАРТа.

А это ваше "нормально будет" - это какая вероятность ошибки на практике при передаче 1 байта?