Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: Как бы выкрутится из такого поожения?
Форум разработчиков электроники ELECTRONIX.ru > Микроконтроллеры (MCs) > AVR
Pyku_He_oTTyda
Постораюсь ясно изложить мысль:
МК (мега8) занимается управлением камерой по LANCпротоколу (тот же самый UART со стороны камеры, но с открытым коллектором ), со стороны МК отслеживаем старт-биты и подаем команды притягиванием линии к земле. Передается фреймами по 8 байт, во время передачи команды (одно и то же повторяем несколько фреймов - может затянутся на насколько секунд) нельзя пропускать фреймы.
То есть МК занят, на остальную работу остается порядка 9милисек (промежуток между фреймами)
Все бы ничего, но параллельно надо принимать другую команду, длительностью порядка 44 милис.
Есть идея по фронту внешней команды запускать capture timer на время 45 мс и после оценивать состояние регистра ICR.
Покритикуйте идею.
bodja74
Непонятно ,а что мешает МК принимать данные по УСАРТ по прерыванию?
Pyku_He_oTTyda
Прерывание УСАРТ возникает при окончании приема, а мне нужен старт-бит
bodja74
Тогда старт бит ловим по INT и в обработчике прерывания делаем команды.
Можно также по INT запускать таймер для другой команды и по нему же останавливать если не требуется суперточности. smile.gif
Dog Pawlowa
Цитата(Pyku_He_oTTyda @ Jun 12 2007, 21:30) *
Постораюсь ясно изложить мысль:
МК (мега8) занимается управлением камерой по LANCпротоколу (тот же самый UART со стороны камеры, но с открытым коллектором ), со стороны МК отслеживаем старт-биты и подаем команды притягиванием линии к земле. Передается фреймами по 8 байт, во время передачи команды (одно и то же повторяем несколько фреймов - может затянутся на насколько секунд) нельзя пропускать фреймы.
То есть МК занят, на остальную работу остается порядка 9милисек (промежуток между фреймами)
Все бы ничего, но параллельно надо принимать другую команду, длительностью порядка 44 милис.
Есть идея по фронту внешней команды запускать capture timer на время 45 мс и после оценивать состояние регистра ICR.
Покритикуйте идею.

Это напоминает обычный программный УАРТ, и действительно, легко реализуется по прерыванию по стартовому биту. Далее запускается таймер на длительность бита с поправками на длительность прерывания и поехали. Вопрос в параметрах - какова длительность бита, и какой допустимый джиттер. Реализовать абсолютно фоновый УАРТ на двух прерываниях получается достаточно просто.
Pyku_He_oTTyda
то есть вы предлагаете вплотную занятся приемом "длинной "команды как основной, а УАРТ обрабатывать в фоновом режиме по прерываниям?
Длительность длинная - 104мкс (9600).
oran-be
Если добавить примерно 1$ можно мегу 8 заменить на мегу 162. Там 2 УАРТа. Можно без извращенных методов фсе реализовать и спать спокойно. Влдожения окупаются с лихвой на экономии времени. Если конечно не учитывать потерянного сонительного удовольствия от акта отладки левых алгоритмов...
Pyku_He_oTTyda
а зачем мне вообще 2 нардварных УАРТА?
Dog Pawlowa
Цитата(Pyku_He_oTTyda @ Jun 13 2007, 06:38) *
то есть вы предлагаете вплотную занятся приемом "длинной "команды как основной, а УАРТ обрабатывать в фоновом режиме по прерываниям?
Длительность длинная - 104мкс (9600).

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

Я всего лишь утверждаю, что на микроконтроллере АВР вполне реализуем вариант двух программных УАРТов, работающих в фоновом режиме со скоростью 9600. Во всяком случае, один на 19200 получился просто, джиттер меньше 5 процентов, экстраполируя на два УАРТа 9600, я предполагаю вполне хорошие результаты.

Кстати, а что, только прием команд? Тогда задача еще проще - в прерываниях не нужно анализировать режим порта.
Да, еще по поводу использования логики захвата. Действительно, можно упростить фоновый алгоритм - писать в буфер содержимое таймера, когда входной сигнал поменял полярность, а потом анализировать. Я так делал для приема посылок по радио, очень прозрачно и удобно.
arttab
можно попробовать делать опрос что на линии по прераванию от таймера, а хардуарт использовать для "нормальной" команды.
Pyku_He_oTTyda
В первом посте неправильно выразился, "другая команда" это не УАРТ, там свой протокол. Минимальная длительность импульса 1мс, максимальная - 6мс. Вот на 44мили и набегает.
Dog Pawlowa
Цитата(Pyku_He_oTTyda @ Jun 13 2007, 15:09) *
В первом посте неправильно выразился, "другая команда" это не УАРТ, там свой протокол. Минимальная длительность импульса 1мс, максимальная - 6мс. Вот на 44мили и набегает.

Ну неважно, обработка вряд ли принципиально отличается от программного УАРТа - поймать первый фронт (по прерыванию от порта) а потом с привязкой по времени (прерывания от таймера) считывать состояние входа (или менять при передаче).
Я программными УАРТами измерял ресурсы. Как попугаями - удава smile.gif

1ms - это вагон времени. У меня фоновое прерывание таймера, в котором клавиатура и прочие сервисы, работает с периодом 1 мс.
=GM=
Цитата(Pyku_He_oTTyda @ Jun 12 2007, 17:30) *
То есть МК занят, на остальную работу остается порядка 9 милисек (промежуток между фреймами)

Интересно, чем это МК занят при передаче по уарту? Толкнул 1 байт на передачу и спи 1 мс, потом следующий байт. По-моему, МК у вас просто простаивает...
Pyku_He_oTTyda
После посылки байта остается спать 250мкс (LANC такой).
Я боюсь, что в прерывании по обнаружению старт-бита с ЛАНКа, пропущу
внешнюю команду
ReAl
Цитата(Pyku_He_oTTyda @ Jun 16 2007, 09:36) *
После посылки байта остается спать 250мкс (LANC такой).

Так говорилось же уже сварганить передачу LANC на двух прерываниях.
По спаду старт-бита - прерывание запуска процесса, лучше всего - ICP. В этом прерывании инициализируем передачу команды в камеру (счётчик бит, ...) и делаем
OCR1A = ICR1 + длина_полутора_бит; /* таймер 1 бежит свободно */
В прерывании по OCR1A выталкиваем бит и делаем для следующего прерывания
OCR1A += длина_бита;
Итого процессор будет свободен кучу времени, иногда (не чаще раза на бит) совсем ненадолго отвлекаясь на LANC. Период бита 104мкс @ 9600, при 8 мегагерцах такта это больше 800 тактов, прерывание OCR1A уложится в несколько десятков, более 90% времени процессор гуляет.
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.