Страница 64 из 421
Добавлено: Ср фев 10, 2010 18:26:59
Avarges
Как на cvavr написать такой момент чтобы по окончанию обработчика прерывания int1 программа возвращалась не в ту точку main откуда она прервалась, а в указанную точку внутри main программы.
Иными словами, есть какой-нибудь глобальный goto, jump или что-то такое в cvavr?
Добавлено: Ср фев 10, 2010 20:18:37
ARV
Avarges писал(а):Как на cvavr написать такой момент чтобы по окончанию обработчика прерывания int1 программа возвращалась не в ту точку main откуда она прервалась, а в указанную точку внутри main программы.
Иными словами, есть какой-нибудь глобальный goto, jump или что-то такое в cvavr?
такая возможность есть, но надо быть крепко выпимши, чтобы придумать такое поведение программы! (это я мягко выражаюсь, если кто не понял).
сразу забудьте про эту идею! и никогда-никогда к ней не возвращайтесь!
Добавлено: Чт фев 11, 2010 15:15:07
Avarges
И так понятно что с точки зрения программирования это не хорошо, но лучше бы написали (если знаете
) ответ на вопрос.
Зачем мне это надо: в main процедуре я вызываю usart_receive и она ждёт входные данные и так она и ждёт пока данных нет, а тут происходит int1 который нужно немедленно обработать, естественно при входе в обработчик прерывания можно отключить usart, а в конце включить, только мне не понятно: int1 ведь вернёт управление куда-то в usart_receive и что дальше будет мне совершенно непонятно, поэтому хотелось бы просто начинать usart_receive с начала, потому что получать частичные/ошибочные данные из usart_receive крайне нежелательно.
Добавлено: Чт фев 11, 2010 15:58:05
ARV
с точки зрения программирования это не "не очень хорошо", а просто отвратительно! потому я, хоть и знаю, не буду рассказывать, как это сделать!
а вот как сделать правильно - расскажу.
во-первых, что вас смущает? пусть uart_resive ждет себе, пусть поступает и обрабатывается прерывание - в чем проблема? прерывания для того и предназначены, чтобы прерывать течение основной программы!
во-вторых, внутри обработчика прерывания для чего вы собираетесь отключать UART?! с какой-такой целью? чтобы поиметь побольше логических ошибок и потом с потом и кровью их отлавливать? не надо этого делать.
будьте проще, и люди к вам потянутся
то есть не люди, а байты (по USART)
Добавлено: Чт фев 11, 2010 16:13:44
Avarges
Хорошо, допустим вот этой функцией я принимаю:
Код: Выделить всё
unsigned char USART_Receive( void )
{
/* Wait for data to be received */
while ( !(UCSRA & (1<<RXC)) )
;
/* Get and return received data from buffer */
return UDR;
}
и вот случилось такое: функция уже приняла 4 бита от всего пакета (8 бит) и в этот момент происходит int1, который обрабатывается долго. Что произойдёт с остальными четырьмя непринятыми битами, они примутся тоже или они потреяются и что вернёт
"return UDR;" когда прерывание отработает и вернёт управление внутрь USART_Receive?
Добавлено: Чт фев 11, 2010 16:24:35
ARV
во-первых, любое прерывания обязано обрабатываться быстро. если оно у вас обрабатывается долго - это скорее всего указывает на неправльное построение алгоритма.
прием битов ведется аппаратно, при этом скорость работы USART (ну, пожалуй, максимум 115200 бит/сек) как минимум в 10 раз ниже скорости работы самого МК (ядра), с учетом того, что байт передается фактически минимум 10-ю битами, то времени достаточно для быстрой обработки прерывания. а если учесть, что во многих МК имеется USART (а не просто UART), который сможет принять второй байт без потери первого - времени вообще вагон!
так что не надо ничего бояться, ничего плохого с вашим UDR не произойдет. а вот если вы "остановите" UART - то наверняка повредите не до конца принятый байт.
Добавлено: Пт фев 12, 2010 11:42:29
ValBag
ARV писал(а):...во многих МК имеется USART (а не просто UART), который сможет принять второй байт без потери первого...
Можно добавить, что сдвиговый регистр, может служить буфером для третьего байта.
Добавлено: Сб фев 13, 2010 01:28:49
Avarges
Хотел свою первую прошивку коряво написанную по быстрому доделать, а теперь получается что надо по всем канонам научно-фантастического программирования всю структуру программы переделывать и тебе прерывание по быстрому обрабатывать и longjmp (так ведь
?) не использовать. Чего то в си замудроенный какой-то этот вариант setjmp, longjmp, и правда не тянет им пользоваться. Эх, дайте мне двойной ассемблер
Добавлено: Сб фев 13, 2010 09:41:05
ARV
Avarges писал(а):Хотел свою первую прошивку коряво написанную по быстрому доделать, а теперь получается что надо по всем канонам научно-фантастического программирования всю структуру программы переделывать и тебе прерывание по быстрому обрабатывать и longjmp (так ведь
?) не использовать. Чего то в си замудроенный какой-то этот вариант setjmp, longjmp, и правда не тянет им пользоваться. Эх, дайте мне двойной ассемблер
да у вас там и структуры нет никакой - тяп-ляп-лишьбыкак.
Добавлено: Сб фев 13, 2010 13:54:45
Avarges
ARV писал(а):да у вас там и структуры нет никакой - тяп-ляп-лишьбыкак.
Так про то и речь
Добавлено: Сб фев 13, 2010 20:01:48
andre_74
Доброго времени суток
Не пойму в чем дело: сделал переходник на виртуальный ком порт на ft232rl, соединил - передает, но! Взять к примеру простую процедуру - то, что принял от компа отправляет обратно в комп. Ответ от МК отображается кракозяброй, йероглифами. МК - atmega16. Что может быть?
Добавлено: Вс фев 14, 2010 14:00:56
smac
andre_74 писал(а):... Что может быть?
Диагностика обычна для ком-порта:
1. Проверить переходник с помощью ЭХА - соединить на выходе переходника RX и TX и добиться возвращения отправленного символа.
2. Выяснить точно на какой тактовой частоте работает микроконтроллер и проверить установку битовой скорости (baud-rate) и формата кадра (кол-во бит, четность).
3. ПОСЛЕ проверки переходника и выяснения тактовой частоты, попробовать написать минимальный исходник (только инициализация и эхо).
4. Если ничего не получается выложить исходник сюда, при этом указав от чего тактируется контроллер и собственно тактовую частоту.
Добавлено: Вс фев 14, 2010 16:16:15
dosikus
ARV, Проект отсюда
http://hardlock.org.ua/mc/tiny/termostat_v2/index.html
На старой версии (1.29) CVAVR собирается ошибок нет.
На новой 2.04.4a не видит глобальных переменных из функций обьявленных в внешнем файле , при компиляции ругается - что они не определены.
С AVR'ками мало общаюсь , тем более с компиляторами...
Добавлено: Вс фев 14, 2010 17:47:19
ARV
dosikus писал(а):ARV, Проект отсюда
http://hardlock.org.ua/mc/tiny/termostat_v2/index.html
На старой версии (1.29) CVAVR собирается ошибок нет.
На новой 2.04.4a не видит глобальных переменных из функций обьявленных в внешнем файле , при компиляции ругается - что они не определены.
С AVR'ками мало общаюсь , тем более с компиляторами...
а при чем тут я? проект не мой, с CVAVR я стараюсь никаких дел не иметь...
термостат свой собственный сделал на WinAVR
Добавлено: Вс фев 14, 2010 17:56:04
dosikus
ARV, Извиняюсь - смотрел по твоей активности здесь.
По твоему термостату вопросов нет, думаю и не будет - все пашет ,крутится, мигает ...
Добавлено: Вс фев 14, 2010 17:58:30
ARV
dosikus писал(а):ARV, Извиняюсь - смотрел по твоей активности здесь.
По твоему термостату вопросов нет, думаю и не будет - все пашет ,крутится, мигает ...
моя активность ограничена
общими вопросами по языку Си, которых в этой теме большинство. конкретно CVAVR я не занимаюсь...
Добавлено: Вс фев 14, 2010 21:44:44
L-29
При чтении FLASH из МК сохраняется в буфер. Подскажите, где этот буфер в CodeVisionAVR, где .hex искать?
Добавлено: Пн фев 15, 2010 05:32:35
AI_Disable
После чтения жмите File -> Save FLASH и сохраняйте прочитанный hex куда вам угодно.
Добавлено: Вт фев 16, 2010 09:56:46
ssvd
вот не могу понять где косяк! может кто увидит...
В реальности, если к схеме подключен 1датчик, то все нормально, а если 2 датчика, то показывается всякая фигня....
Если тоже самое делаю в Proteus, то там фигня постоянно показывается...
Уже все передумал, не могу понять..
Подскажите....
Добавлено: Ср фев 17, 2010 13:40:25
ssvd
что никто и не поможет?
