Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: AVR и ПК
Форум разработчиков электроники ELECTRONIX.ru > Сайт и форум > В помощь начинающему
GSK
Подскажите пожалуйста кто делал проекты использующие обмем с компьютером.

Дело в следующем. Есть ATmega16 и рабочая и отлаженная плата. Посылать и принимать байты в комьпьютер получаеться беспроблем. А вот когда пытаюсь передовать строки или даже просто слова по присходит какая-то ерунда. Да и вообще с алгоритмом что-то не получаеться, как-то коряво выходит.
Может кто-то ужесталкивался с подобными проблемами. Интересуют исходники на С или Бейсике (так легче понять алгоритм). В идеале интересует следующие.
1. Компьютер выдает запрос и котроллер выдает значение одной из переменных в зависемости от запроса. Причем переменная может быть либо число, либо строка - т.е длина ответа теременна.
2. Котроллер выдает запрос и компьютер выдает значение одной из переменных в зависемости от запроса.
3. Всегда проверяеться контрольная сумма.
4. Компьютер включает выхода.
и т.д.

Заранее благодарен.
Непомнящий Евгений
Не понимаю, какие проблемы. Придумываете протокол или берете готовый. Пример:
STX Команда Данные ETX CRCL CRCH
В УАРТ-овских прерываниях получаете\передаете пакет. Когда пакет получен и CRC верна - выставляете флаг, по которому вне прерывания обрабатываете пакет и, если надо, формируете ответ.
Судя по вашему описанию, инициаторами обмена может быть либо компьютер, либо МК. Тогда возможно, надо добавить в пакет некий номер, по которому можно разрулить ситуацию при встречных пакетах...
tyro
Цитата(GSK @ Oct 15 2007, 19:16) *
Подскажите пожалуйста кто делал проекты использующие обмем с компьютером.
Заранее благодарен.

Посмотрите здесь:_http://www.caxapa.ru/lib/wake/
GSK
Цитата
Непомнящий Евгений

Я так понимаю, что Вы некогда не сталкивались с моей задачей. Отсюда и
Цитата
Не понимаю, какие проблемы......


Пррочитал по последней ссылке. "tyro" спасибо. Буду разбираться. Но информации много не бывает. Интересно посмотреть на чей-нибудь проект.
Непомнящий Евгений
Цитата(GSK @ Oct 16 2007, 07:21) *
Я так понимаю, что Вы некогда не сталкивались с моей задачей.

C вашей - скорее всего нет smile.gif Но с компьютером чем-нибудь обмениваюсь постоянно...
Цитата
Интересно посмотреть на чей-нибудь проект.

У меня они довольно наворочены и специфичны, вырезать лишнее лень.
Дык а собственно что вам не понятно в моем предыдущем объяснении?
GSK
Да в обьяснении все понятно. Спасибо за помощь.
Но теория это одно, а практика совсем другое.
tyro
Цитата(GSK @ Oct 16 2007, 08:32) *
Да в обьяснении все понятно. Спасибо за помощь.
Но теория это одно, а практика совсем другое.

Вот книжки, где кое-что есть
Применение микроконтроллеров AVR. Схемы, алгоритмы, программы (Баранов В.Н.).
Кузьминов А.Ю. Интерфейс RS232. Связь между компьютером и микроконтроллером. - М. Радио и связь, 2004. - 168 с ил.
IEC
Хорошо работать когда PC выступает в роли ведущего, а МК в роли ведомого. В обратном случае необходимо PC вешать в режим ожидания, что сильно его клинит, если работать через API.
tyro
Цитата(GSK @ Oct 15 2007, 19:16) *
Подскажите пожалуйста кто делал проекты использующие обмем с компьютером.
Заранее благодарен.

Для работы со стороны компьютера есть хорошая dll от моха, идет с кучей примеров, безплатная.
Взять можно здесь:http://web4.moxa.com/support/download.asp?id=87(после инсталяции в директории примеры на СИ,Бейсик,делфи).
vladimir_ad
Цитата(IEC @ Oct 16 2007, 10:57) *
Хорошо работать когда PC выступает в роли ведущего, а МК в роли ведомого. В обратном случае необходимо PC вешать в режим ожидания, что сильно его клинит, если работать через API.
Ничего подобного. Ожидание события на порту в API нормально реализовано. Или синхронно читайте с настроенной COMMTIMEOUTS.
Axxel
Цитата(GSK @ Oct 15 2007, 22:16) *
А вот когда пытаюсь передовать строки или даже просто слова по присходит какая-то ерунда. Да и вообще с алгоритмом что-то не получаеться, как-то коряво выходит.

Наверняка используете стандартные функции компилятора типа getstring() или putstring() wink.gif
Используйте прерывания, как в этом небольшом примере, но это не проект, а просто тест.
Таймаут проверяйте тоже через прерывания таймера. И конечно лучше прочитать описание
кокого-нибудь стандартного протокола, типа modbus.
МК для исходника-2313.
Dog Pawlowa
Цитата(IEC @ Oct 16 2007, 09:57) *
Хорошо работать когда PC выступает в роли ведущего, а МК в роли ведомого. В обратном случае необходимо PC вешать в режим ожидания, что сильно его клинит, если работать через API.

А какая разница, если все равно нужно ждать ответ в течение тайм-аута.
GSK
Парни, как говориться ".. забудь дедукцию, давай продукцию.."
Вот, вчера нашел.
http://www.serasidis.gr/circuits/RS232inte...2_interface.htm
GSK
Просмотрел всю доступную информацию.
wake слишком тяжеловесна. А остальные примеры слишком просты. (правда модбас я еще не смотрел). Вообще не понимаю, почему эту тему преревели в подкатегорию "для начинающих"? Ведь эта проблема больше интересна тем, кто уже имеет опыт. Передавать байтики туда-сюда - проблем не составляет. Проблемы начинаються тогда, когда передаються большие массивы информации, на пределе пропускной способности канала для данной скорости.
Как бороться с ошибками? как считать контрольные суммы? какую скорость выбрать для меньшей ошибки рассогласования частот? какой протокол обмена? и т.д.

Так что без отработанных примеров не обойтись. Если есть ссылки, буду безмерно благодарен?
Непомнящий Евгений
Цитата
Как бороться с ошибками?

Ошибка в ответе: мастер повторяет посылку N раз, после чего считает, что нет связи и как-то это обрабатывает.
Ошибка в запросе: подчиненный игнорирует весь запрос.
Цитата
как считать контрольные суммы?

Да любой алгоритм. CRC-16 к примеру.
Цитата
какую скорость выбрать для меньшей ошибки рассогласования частот?

если с компьютером по нормальному шнурку - 115200 вполне нормально.
Если RS-485 и большие расстояния - 4800. Где-то видел табличку с предельными скоростями в зависимости от типа и длины кабеля.
Цитата
какой протокол обмена? и т.д.

Простейший протокол:
М(астер)->В(едомый):
STX Команда Данные ETX CRCL CRCH
В->М
STX Команда Данные ETX CRCL CRCH
Данные могут отсутствовать. В качестве CRC можно взять CRC-16. Не хотите заморачиваться - просто сумму по модулю.
Судя по вашему начальному сообщению, вам он вполне подойдет.
GSK
Значит принцип такой:
М(астер) посылает данные и В(едомый) получив их отвечает, что получил. Если В(едомый) не ответил, то после нескольких попыток М(астер) считает, что нет связи. Правильно?
Проясните пожалуйста:
STX - ?
ETX - ?
CRCL - Старший байт контрольной суммы
CRCH - Младший байт контрольной суммы

И насчет выбора скорости. Я говорил не о зависимости скорости от длины передачи, а об отклонение частоты от стандартной из за фиксированной частоты кварца микроконтроллера. Как правильно выбирать скорость обмена?
Непомнящий Евгений
Цитата(GSK @ Nov 30 2007, 08:00) *
Значит принцип такой:
М(астер) посылает данные и В(едомый) получив их отвечает, что получил. Если В(едомый) не ответил, то после нескольких попыток М(астер) считает, что нет связи. Правильно?

Да.
"отвечает, что получил" - ведомый отвечает то, что требуется в зависимости от команды.

STX - начало сообщения - стартовый символ пакета. Нужен, чтобы выделить пакет, если в линии может быть мусор. Если использовать кодировку ASCII - берите стандартный из таблицы. Если hex-кодировку - берите любой. Если этот байт может встречаться в теле пакета, можно использовать экранирование.
ETX - конец пакета. Нужен для определения конца пакета. Вместо него можно использовать байт длины или пакеты фиксированной длины.
Цитата
И насчет выбора скорости. Я говорил не о зависимости скорости от длины передачи, а об отклонение частоты от стандартной из за фиксированной частоты кварца микроконтроллера. Как правильно выбирать скорость обмена?

Тут я некомпетентен. Мы используем кварцы, кратные скоростям УАРТа (7372800, 11059200 и т.д.), так что с этой проблемой не сталкивался.
AndryG
Цитата
И насчет выбора скорости.

Считается допустимым отклонение до 2% между фактическими скоростями UART устройств.
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.