Страница 1 из 1

Добавлено: Чт окт 08, 2009 07:35:03
uldemir
В прерывании достаточно сохранить и потом восстановить контекст: помимо W, status сохрани FSR и PCLATH.

Код: Выделить всё

; вход по прерыванию
        org     4
PUSH    MOVWF   W_TEMP          ; Copy W to TEMP register,
        SWAPF   STATUS, W       ; Swap status to be saved into W
        MOVWF   STATUS_TEMP     ; Save status to STATUS_TEMP register
        MOVF    PCLATH, W
        MOVWF   PCLATH_TEMP
        MOVF    FSR, W
        MOVWF   FSR_TEMP
; --------------------------------
        banksel 0
        clrf    pclath
;
.................
POP:
        MOVF    FSR_TEMP, W
        MOVWF   FSR
        MOVF    PCLATH_TEMP, W
        MOVWF   PCLATH
        SWAPF   STATUS_TEMP, W  ; Swap nibbles in STATUS_TEMP register
                                ; and place result into W
        MOVWF   STATUS          ; Move W into STATUS register
                                ; (sets bank to original state)
        SWAPF   W_TEMP, F       ; Swap nibbles in W_TEMP and place result in W_TEMP
        SWAPF   W_TEMP, W       ; Swap nibbles in W_TEMP and place result into W
        retfie                  ; GIE должен тут установиться.
;
Один в один как в даташите.

А прерывания нужны для удобства. Был у меня один знакомый который их тоже непризнавал... Но он программы не пишет.

Добавлено: Чт окт 08, 2009 11:41:05
uldemir
С PCLATH не всё просто/безопасно, недавно написал тут
Там видно только ваше непонимание. ВСЕ команды return вернут в точку вызова call независимо от PCLATH. Заботиться надо только о call и goto.
Для сохранения контекста достаточно этих 4 регистров, хотя большинство кристаллов отводит по 16 ячеек, которые видны из всех страниц памяти данных. А все остальное - НА УСМОТРЕНИЕ РАЗРАБОТЧИКА. Т.е. - проблем нет. А использовать прерывания или нет - на такие философские рассуждения у меня сейчас нет времени. Когда я смотрю код на радиокоте других разработчиков - меня коробит, я бы писал по-другому. Думаю, их будет коробить не меньше, если они увидят мои исходники. Лично я пишу практически все с использованием прерываний. Были даже проекты где в основном теле программы после инициализации стояло goto $.
А прерывание - не одна процедура, из неё другие вызываются...
Обработчки прерываний должны быть лаконичными, как программа на форте.

Добавлено: Чт окт 08, 2009 20:32:46
uldemir
А там про retlw непонимание. Специально "мостик" пришлось сделать, превращающий retlw на другие 2кб в retlw на те же 2кб + return на другие 2кб. Иначе не работало.
На время выполнения "мостика" прерывания запрещаю.
А какова цель? Большая таблица? Я в такой ситуации использовал такой код:

Код: Выделить всё

       call runner
       pagesel   metka
       goto      metka
....
runner:
        movf    frameptrh, w
        movwf   PCLATH
        movf    frameptrl, w
        movwf   PCL
Эта таблица занимает ВСЮ память 16f876 за исключением небольшого кусочка кода. И никаких "мостиков". Разумеется в прерывании PCLATH сохраняется и в конце востанавливается.
Потому и не обращаюсь личным письмом с вопросом, а тему на форуме
Здесь маловато пикоманов. Сплошь аврщики ;-). Ну да всё, я сдал экзамен на вистовский сертификат - теперь могу расслабиться и по-философствовать.
Например, половину событий обрабатывать прерываниями, остальные по флажкам в майнцикле.
Вот видишь, "основное ты постиг". Если что-то нужно сделать быстро и это просит очень малого - в прерывание. Остальное в основном цикле. Кстати, как конкурирующую технологию, можно использовать "машину состояний". Люди с помощью этой технологии тоже обходятся без прерываний. (Хотел приложить ссылку на такой образчик, но ссылка оказалась уже мертвая...)
Но лучше, послушай советов и сделай по-своему.

Добавлено: Пт окт 09, 2009 05:54:01
NiceMAN
Господа, если задачи и алгоритмы становятся сложными и запутанными, как насчет поднять RTOS. Я правда, не пикоман), но сама идея для AVR тут
http://easyelectronics.ru/avr-uchebnyj- ... l#more-138
http://easyelectronics.ru/avr-uchebnyj- ... l#more-144
http://easyelectronics.ru/avr-uchebnyj- ... l#more-147
http://easyelectronics.ru/avr-uchebnyj- ... l#more-149
http://easyelectronics.ru/avr-uchebnyj- ... l#more-150

Добавлено: Пт окт 09, 2009 07:45:57
uldemir
Господа, если задачи и алгоритмы становятся сложными и запутанными, как насчет поднять RTOS. Я правда, не пикоман), но сама идея для AVR тут
Если задачи черезчур запутанны, то, может, не стоит заниматься программированием? Когда я начал тупеть, до меня с трудом доползла одна мысль. Человек пишет настолько большую программу - насколько он в состоянии удержать ее в голове. Поэтому крутые пишут на ассемблере, те кто по-слабее - на Си или паскале. А кто даже это неспособны удержать в голове - правят конфиги. О клиническом случае - таскать объекты мышкой - я вообще не говорю. Не думаю, что для микроконтроллера с 2к памяти программ надо делать RTOS. Хотя вот порылся... оказывается есть - AN777

Код: Выделить всё

This application note covers a Real-Time Operating System (RTOS) running on a PIC16F877. The application is written in C using the HI-TECH C compiler. MPLAB ® IDE is used as the Integrated Development Environment. This RTOS is unique, in that it is intended for microcontroller applications where memory is severely limited. The application runs on a prototype PCB that monitors temperature, accepts user input and displays important temperature information.
Хм. У меня на столе стоит такая же конструкция - мониторит и отбражает температуру, время, принимает нажатия на кнопки и показывает график изменения температуры за последние сутки. Без всяких RTOS. Но с машиной состояний и прерываниями (правда, только от таймера).
RTOS по-моему просто помогает разбить задачу на кусочки, которые программист способен удержать в голове. Но это не освобождает его от обязанности видеть всё! Если это игнорируется, то и получаются программы из трех строчек, в которых нечего отлаживать, но которые глючат "ни па децки". Поэтому чтобы эффективно использовать RTOS надо досконально знать ее внутренности. Но обычно, чтобы досконально знать внутренности, не проще ли самому это написать? С другой стороны лень делать то, что уже сделано.

Добавлено: Пт окт 09, 2009 12:30:49
NiceMAN
Хм. У меня на столе стоит такая же конструкция - мониторит и отбражает температуру, время, принимает нажатия на кнопки и показывает график изменения температуры за последние сутки. Без всяких RTOS. Но с машиной состояний и прерываниями (правда, только от таймера).
такая система не сильно критична к времени. А кокда необходимо в реальном времени выполнять несколько взаимосвязанных процессов, тогда RTOS как вариант.
Человек пишет настолько большую программу - насколько он в состоянии удержать ее в голове.
В RTOS можно "собирать" программу по частям, отлаживая каждую задачу по отдельность, потом отлаживать их взаимосвязь.

Добавлено: Сб окт 10, 2009 17:41:04
dosikus
uldemir писал(а):
Человек пишет настолько большую программу - насколько он в состоянии удержать ее в голове. Поэтому крутые пишут на ассемблере, те кто по-слабее - на Си или паскале.
Держать программу большого размера в мозгах ,способны только гении или шизофреники 8) ( что по последним данным весьма близко)
надо алгоритм в башке держать ... :music: