PIC18F452: Глюк ?

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From Russian to

Threaded View
                   ----- Приветствую, _All_ ! -----

   Hаписал я программку, которая при старте даёт переменной ind_val
определённое значение. Значение это прописано в цикле start, прописанном по
адресу 0x0. Принимаемые данные по RS232 заносятся в ind_val. Каждую
миллисекунду значение ind_val выводится на индикаторы.
Включён модуль USART.
   Так вот. При подачи питания на камень, если к нему не прицеплены буферы
(использую 1488, 1489), на индикатор выводится значение 0x0 (ind_val==0x0 ???).
Если же в момент старта буфера прицеплены - на индикатор выводится значение
ind_val.

Вот сама программа:

#include <P18F452.inc>
     list p=pic18f452
     ; Цепляется к ком-порту.
     ; Выводит данные, посылаемые в ком-порт,
     ; на два 8-ми разрядных индикатора.
     ; RD0-RD4 - ко входу КР514ИД2,
     ; RA0 - к аноду единичного индикатора
     ; RA1 - к аноду десятичного индикатора
(...)
ind_num EQU 0x6; 1 - ед. инд, 0 - активен десятичный индикатор
ind_val EQU 0x7; Значение, выводимое на оба индикатора (0x59)
     ORG     0x0
     goto start
     ORG       0x8
     goto hight_int
     ORG       0x18
     goto low_int
hight_int
(...)
     movf RCREG,w,0; Считываем регистр и сбрасываем тем самым флаг RCIF
     movwf     ind_val
(...)
     retfie

low_int
(...)
     ; Переключаем разряд индикатора
     incf ind_num,f
     bcf       PORTD,0,0
     bcf       PORTD,1,0
     bcf       PORTD,2,0
     bcf       PORTD,3,0
     btfsc     ind_num,1
     goto dec_ind
     ; Выводим значение ind_val (млад. 4 бита) в еденичный индикатор
     bcf       PORTA,1,0
     bsf       PORTA,0,0
     btfsc     ind_val,0
     bsf       PORTD,0,0
     btfsc     ind_val,1
     bsf       PORTD,1,0
     btfsc     ind_val,2
     bsf       PORTD,2,0
     btfsc     ind_val,3
     bsf       PORTD,3,0
     goto end_low_int
dec_ind
     ; Выводим значение ind_val (старш. 4 бита) в десятичный индикатор
     clrf ind_num
     bcf       PORTA,0,0
     bsf       PORTA,1,0
     btfsc     ind_val,4
     bsf       PORTD,0,0
     btfsc     ind_val,5
     bsf       PORTD,1,0
     btfsc     ind_val,6
     bsf       PORTD,2,0
     btfsc     ind_val,7
     bsf       PORTD,3,0
end_low_int
(...)
     retfie

start
     clrf BSR,0; первый банк памяти
(...)
     movlw     0x36
     movwf     ind_val
main
     nop
     nop
     nop
     goto main
     end


Что интересно, так это то, что если строчки (movlw 0x36,movwf ind_val) загнать
в обработку прерывания низкого уровня, либо в цикл main(), то даже при
отсутствии буферов получаем на индикаторах 0x36. А если их в "start" оставить -
странности... Почему так ?

-----------------

   В режиме шестнадцатиричной работы TMR0 при любой записи в TMR0L в TMR0H
пишется 0xFF. При записи в TMR0H в онном регистре ничего не изменяется, запись
игнорируется... :( Как быть ?

-----------------

   Как определяются байты конфигурации в программе у данного проца ?

     list p=pic18f452

 __CONFIG что ?

В смысле, как в исходнике отключить всю защиту и LVD, включив HS&PLL,
BOR,PWRTE,POR, и указав BOR=2.7V, ?


... На парте:"Забей на учёбу,Она не товарищ-Да здравствует хлюпанье Женских
вла&#ищ


Re: PIC18F452: Глюк ?
Hемедленно нажми на RESET, Vadim Tzirulnicov!



 VT>    Так вот. При подачи питания на камень, если к нему не прицеплены буферы
 VT> (использую 1488, 1489), на индикатор выводится значение 0x0 (ind_val==0x0
 VT> ???).

  Асинхронный последовательный интерфейс для отметки начала передачи
использует т.н. "стартовый бит". Он у тебя при отключенном
буфере-инверторе и становится активным (как и остальные сигналы...)
Вот и принимается байт. Далее, поскольку стоп-бита там нет (вечный
1 на всех входах), то должно возникать состояние ошибки "обрыв",
или как-то так.

 VT> Если же в момент старта буфера прицеплены - на индикатор выводится
 VT> значение
 VT> ind_val.

  Правильно, там вечный 0 на входе и считается, что ничего не
передаётся.

 VT> hight_int
 VT>      movwf     ind_val

 VT> low_int
 VT>      btfsc     ind_val,0

  Так не делается. ind_val должно быть защищено от изменения при
считывании вне функции обработки прерывания high_int. Самое простое --
запрещать все прерывания на момент переноса значения из ind_val
в какой-либо промежуточный регистр. Hадо понимать, что прерывание,
и следовательно изменение ind_val, может произойти в любой момент
времени.

 VT> Что интересно, так это то, что если строчки (movlw 0x36,movwf ind_val)
 VT> загнать
 VT> в обработку прерывания низкого уровня, либо в цикл main(), то даже при
 VT> отсутствии буферов получаем на индикаторах 0x36. А если их в "start"
 VT> оставить -
 VT> странности... Почему так ?

  В данном случае ind_val периодически переустанавливается...

 VT>    В режиме шестнадцатиричной работы TMR0 при любой записи в TMR0L в TMR0H
 VT> пишется 0xFF. При записи в TMR0H в онном регистре ничего не изменяется,
 VT> запись
 VT> игнорируется... :( Как быть ?

  RTFM внимательно. Там всё описано, каков порядок работы с таймерами.

 VT>    Как определяются байты конфигурации в программе у данного проца ?
 VT>      list p=pic18f452
 VT>  __CONFIG что ?

  RTFM от конкретного ассемблера. Типично, слово конфигурации просто
помещается по конкретному адресу. Что-то вроде следующего:

   ORG blablabla
   DW OPTION_1 + OPTION_2 + OPTION_3 ...

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

  Загляни в файл P18F452.inc, там в комментариях наверняка описано как
производится конфигурация.


Re: PIC18F452: Глюк ?

сообщил/сообщила в новостях следующее:
Quoted text here. Click to load it
Подозреваю, что когда буферов нет, на входе USARTA так же ничего нет, т.е. 0,
т.е. USART воспринимает это как старт и принимает значение 0х00, которое у тебя
и выводится на индикатор. Попробуй подтяни вход USARTа к + через резистор и
посмотри, что будет.


Site Timeline