Мелкие вопросы по МК-51 а-ка MCS-51, ASM и не только..

[Rtmip]

Приветствую
Понятно, про удлинение и дополнительный контроллер. Нет у вас желания усложнить свою "программную" жизнь,
но облегчить "железную"? Например, использовать в качестве микросхемы для опроса кнопок микросхему от
импортного кнопочного телефонного аппарата, а ее соединять всего парой проводов с МК.
Но придется программно декодировать DTMF посылки
Что такое "макрос IRPC" не очень знаю, могу только озвучить догадки, почему так получается, если надо, конечно?
По поводу отправки строки в UART.
Я бы сделал на основании вашей программы примерно так:

Спойлер

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

; Где-то внутри главного цикла
   mov   DPTR,#AT_CMGS         ; Загружаем адрес 1 символа команды
   call    Send_comm
;=======
Send_comm:                                              ; Подпрограмма отправки
   clr   A                                       ; Очистим АСС
   movc   A,   @A+DPTR                         ; Поместим очередной символ команды в АСС   
   mov   SBUF,   A                               ; Скопируем его в буфер передатчика
   jnb     TI,$                          ; Нет флага ТІ (окончания посылки) - топчемся на месте
   clr   TI               ; Был флаг ТІ, байт ушел, сбросим флаг ТІ
   inc   DPTR                                    ; Возьмем следующий символ
   jnz   Send_comm         ; Если конец команды, выходим
   ret
;=======
Serial_int:                  ; Обработчик прерываний посл. порта
   clr   EA               ; Запретим все прерывания
   jb   RI,   Receive            ; Если есть флаг RI, значит это прием
   jmp     Serial_end
Receive:                  ; Это прием
   mov   A,   SBUF            ; Это прием, примем байт
   clr   RI               ; Сбросим флаг RI
Serial_end:
   setb   EA               ; Разрешим все прерывания
   reti

Так и овцы будут целы и волки-прерывания сыты...

[Пока_без_кота]

... Нет у вас желания усложнить свою "программную" жизнь, но облегчить "железную"?...
... могу только озвучить догадки, почему так получается, если надо, конечно?...
... Так и овцы будут целы и волки-прерывания сыты...

Спасибо, очень неплохая идея, особенно учитывая,что UART у меня уже занят под обмен с GSM-модулем и меня напрягало делать подобие сетки на базе UART. Посмотрю, что смогу достать из ДТМФ кодеров, и от этого буду отталкиваться.
Озвучьте пожалуйста
То есть в прерывании у нас только прием ? Я уже так пробовал, получалось, но я думал что это "непрофессионально"

[BOB51]

тогда уж "дистанционку":
viewtopic.php?p=2593182#p2593182

[Rtmip]

BOB51, эти вот TX5 и RX5, это те, которые китайцы в радиоуправление машинками ставят?

Озвучьте

Если кратко, то мне кажется, что тут дело в разных макро ассемблерах. Например, кейл пишет так. Там понятный пример приведен.
А вот tasm предлагает взять текст в угловые скобки, остальное так же остается. Точнее не скажу, не пользовался. Может попробую позже.

То есть в прерывании у нас только прием ? Я уже так пробовал, получалось, но я думал что это "непрофессионально"

Тут, я думаю, все зависит от логики и целесообразности. Исходя из вашей задачи, мне этот вариант кажется надежнее.
Не будучи в прерывании, не пропустим важные события, а другие прерывания не испортят передачу.
Вообще, я не программист, поэтому, если волнует вопрос профессиональности, то подождем, что скажут "гуру"
P.S. попробовал ваш макрос:

Спойлер

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

irpc   Pass,   123
   db   'Pass'
endm

транслируется вот в это:
Код:
db   '1'
db   '2'
db   '3'

проще говоря, одинарные кавычки надо в тело макроса поставить.

[BOB51]

Угу...
"Те самые" - купил как-то некоторый запасец (у нас по дармоцене валямс).
Только вот никак не доберусь то железко под ИК приспособить - в даташитах нигде данных по параметрам резистора нету, а макетом пытать пока обломсс.

[Пока_без_кота]

Итак. Из DTMF-кодеров достать ничего пока не удалось. Тем более что я так понимаю, для декодирования DTMF-кода нужно, чтобы в микроконтроллере был АЦП, а в моей модели AT89S52 его нет. Так что пока отложим этот вариант как возможный альтернативный. По поводу того, чтобы по UART одновременно связать МК с GSM-модулем и клавиатурным блоком. Попалась мне тут одна клавиатурная панель от факса. И я загорелся использовать ее в качестве выносной панели управления. В ней помимо клавиатурного блока есть однострочный дисплей на 16 символов. Сперва и полагал, что в ней для передачи данных используется DTMF. Однако методом колупания в настройках терминальной программы выяснилось, что в качестве интерфейса связи в ней используется UART на скорости 2400 б/с. Также выяснилось одна интересная особенность: перед кодом каждой клавиши она шлет байт-маркер "F1". Я уже написал обработчик, который при приеме этого байта переходит в специальнуя ветку, в которой и принимается следующий байт, байт нажатой клавиши. Все что будет приниматся вне этой ветки, я буду принимать как байт информации от GSM-модуля. Сама панель молча проглатывает почти любые байты, что очень хорошо, с ней не будет ничего происходить, пока я буду слать байты в GSM-модуль. Но при приеме ASCII-кода клавиши Enter она начинает выводить все последующие принятые символы на экран. Так что я уже вывожу на клавиатурный модуль надписи типа "GoodPass" и "BadPass!" (правда пока только до 8 символов, потому что понятия не имею, как сделать перевод курсора на 2 половину экрана), дающие понять правильный или нет введен пароль. Прекратить вывод символов на экран можно послав ASCII-код клавиши Backspace. Вот так эта клавиатурная панель от факса помогла мне решить этот интересный вопрос. И если что-нибудь с ней произойдет, я легко могу сам сделать панель с такой же, и даже покруче функциональностью. Сейчас немного перерабатываю программу, часть функционала ведь уехала в клавиатурный модуль, а также купил наконец себе GSM-модуль и даже запустил его (звонил и принимал звонки, правда пока только с помощью терминальной программы, а не МК). Сейчас интересует вопрос, есть ли у кого-то наработки под связь MCS-51 с GSM-модулем на асме. Везде нахожу только на Си Если не найду, буду писать свой велосипед, в котором как обычно будет куча ошибок, и я приду сюда с вопросами

[Rtmip]

...Тем более что я так понимаю, для декодирования DTMF-кода нужно, чтобы в микроконтроллере был АЦП, а в моей модели AT89S52 его нет...

Вообщем, можно и без него, компаратор только нужен, хотя бы на логике, раньше так в АОНах делали. Но теперь это и не надо,
у вас есть интереснее вариант!

...Сейчас интересует вопрос, есть ли у кого-то наработки под связь MCS-51 с GSM-модулем на асме...

ну, так-то, есть в инете, на забугорных ресурсах требуют регистрацию, а вот по нашему пример1, пример2, пример3, поможет?

...есть однострочный дисплей на 16 символов...правда пока только до 8 символов...как сделать перевод курсора на 2 половину экрана...

Вот этого не понял? Что понимается под половинкой, ведь там одна строка?

... и я приду сюда с вопросами

приходите!

[Пока_без_кота]

Спасибо огромное за ссылки, то что надо: на асме, с коментариями, на русском
Блин. Несколько часов убил из-за того, что почему-то начала глючить система. Нажимаю кнопку на выносной панели, и ничего не происходит (а на экран должна выводиться *). Оказалось, микроконтроллер глючил, заменил на другой и все работает. Что-то очень нежные 51 в плане программирования по SPI (когда начинал осваивать АВР-ки, за ними такого ни разу не замечал). Уже 2 штуки нерабочими стало Этот стал глючить после того, как я попытался прошить его с посаженым на ноги программирования (MOSI,MISO,SCK) убитым дисплеем, который сильно просаживал питание (это все я уже потом заметил). Но до сегодняшнего дня он отлично работал, за исключение того, что у него после того случая испортилась синатура (стала 0С:52:06 вместо 1Е:52:06). А теперь к испорченой сигнатуре добавилась проблема с работой приемопередатчика. Оставлю как запасной контроллер для каких-то бегущих огней, выбросить рука не поднимается, тем более что их у меня их всего пару штук осталось. Если так дело дальше пойдет, скоро без материалов для обучения останусь Достал еще пару штук АТ89С51RD2-IM (крутой контроллер, даже PWM вроде в нем есть, жаль только EEPROM нет), но я не могу найти чем их запрограммировать. Они вроде как имеют неубиваемый UART-загрузчик, но я никак не могу до него достучатся с помощью атмеловской утилиты FLIP, хотя все вроде делаю как надо: EA = 1, PSEN = 0, нажимаю ресет, и ...утилита не видит контроллер. Может кто имеет опыт пользования ею ? Или есть какой-то программатор/софт, который эти контроллеры понимает ?

[BOB51]

Прожки для прошивки весьма "капризные"... У меня относительно устойчиво только AT89S51 и AT89S52 обрабатываются (AECISP/ISP programmer + STK200). Остальное оччень напряжненько.
Одначе под WIN98 старое самодельное железо прекрасно все МК прошивало - протокол прошивки был самопалкин по даташитам (параллельно-"высоковольтный").Сейчас проблема для восстановления того железа в основном из-за отсутствия возможностей/навыков написания программ для ПК - нужно использовать стандартный Rx-Tx пересыл массивов между ПК и программатором...

[Rtmip]

...Что-то очень нежные 51 в плане программирования по SPI (когда начинал осваивать АВР-ки, за ними такого ни разу не замечал)...

Иногда люди жалуются, что стирается сигнатура при последовательном программировании АВР, а обратно не восстановить...

..Этот стал глючить после того, как я попытался прошить его с посаженым на ноги программирования (MOSI,MISO,SCK) убитым дисплеем,
который сильно просаживал питание...
...испортилась синатура (стала 0С:52:06 вместо 1Е:52:06)...

Таким образом сигнатура была испорчена? Вообще ток пина у них меньше, чем у АВР...

...АТ89С51RD2-IM...но я не могу найти чем их запрограммировать. Они вроде как имеют неубиваемый UART-загрузчик,
но я никак не могу до него достучатся с помощью атмеловской утилиты FLIP, хотя все вроде делаю как надо: EA = 1, PSEN = 0,
нажимаю ресет, и ...утилита не видит контроллер.

Кстати у вашего МК еще и 1,7 кБ внешнего ОЗУ на борту и SPI, что очень приятно
Флипом еще не пробовал, но в планах держу, интересно проверить, есть МК, подобный вашему.
Там случаем не надо PSEN = 1, после отпускания ресета? Вообще, я не разбирался еще с этим протоколом, но понимаю так,
что если стоят лок-биты, то только параллельный программатор поможет все стереть. Не получится ли стереть через флип?
Кстати, а скорость там не надо устанавливать, послав букву "U" вроде, не помню? И может пробовать разный бит-рейт?
Кстати, вот посмотрите, более понятно расписано, собрано все сразу, а не размазано на несколько страниц

[BOB51]

Сигнатуры (и прочее) "сносит" при некорректном прерывании незавершенного процесса (выдернулся кабло при пересылке данных). Имел такой "нюёнс" при самодельном железа для АТ89С2051.

[Пока_без_кота]

... Таким образом сигнатура была испорчена?...

Да, видимо убитый дисплей своими выводами исказил поток данных в МК, и "что-то пошло не так". А первый контроллер угробил почти как описал ВОВ51, нажал "читать сигнатуру" до того как закончилась операция чтения памяти. И получил вообще мертвый чип, сигнатура вообще не читается, даже Willem его не видит. Теперь все эти дела (прошивка, верификация, стирание) провожу неторопливо

[BOB51]

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

[Rtmip]

Вроде, все должно работать, если обходить чтение сигнатуры.
Пока_без_кота, посмотрел еще про флип, вроде должен быть ответ от МК, даже если
адрес загрузчика изменен.

[Пока_без_кота]

Доброго времени суток. Прошу подсказать, как можно оптимизировать по скорости выполнения следующий код

Спойлер

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

; Для начала надо сконфигурировать системный таймер, чтобы он генерировал нам системные тики. У меня за один тик принята 1мс.
; Поэтому я настраиваю таймер таким образом, чтобы он мне каждую миллисекунду генерировал прерывание. А вот в его прерывании мы и учиним беспредел.

bank_0	macro
	anl	PSW,	#11100111b
	endm

bank_3	macro
	orl	PSW,	#00011000b
	endm

Frequency	equ	12000
Koeficient	equ	12000/Frequency
Timer_Period    equ     64542*Koeficient		; for 1 ms
TH_def          equ     high(Timer_Period)
TL_def          equ     low(Timer_Period)
Num_of_Timers	equ	6                       	; количество софт-таймеров, до 8 шт. больше не хватает быстродействия контроллера
Timer_1_Task	equ	3Fh                             ; адрес задачи 1 таймера, следующий адрес - младший байт таймера, следующий - старший байт таймера, следующий - адрес задачи 2 таймера и т.д. Каждый следующий адрес - на 1 меньше предыдущего
Timer		equ     3h
Timers_Counter  equ     R2                              ; 3 банка
Timer_Pointer   equ     R1                              ; 3 банка
Tail_           equ     R1                              ; 0 банка

cseg

Timer0:                                                 ; Timer0 interrupt heandler
	mov	TH0,	#TH_def                         ; перезагрузим таймер
	mov	TL0,    #TL_def
	push	ACC
	push	PSW                                     ; сохраним рабочий банк памяти
	bank_3                                          ; выберем 3 банк
	mov	Timers_Counter,#Num_of_Timers		; загрузим количество софт-таймеров
	mov	Timer_Pointer,#Timer_1_Task		; загрузим адрес задачи 1 софт-таймера
Next_Timer:
	mov	A,	@Timer_Pointer                  ; загрузим в АСС номер задачи этого софт-таймера
	jz	Skip_Set_Task                           ; если 0 - пропускаем этот софт-таймер
	dec	Timer_Pointer                           ; выберем младший байт этого софт-таймера
	mov	Timer,	@Timer_Pointer			; загружаем содержимое младшего байта софт-таймера в проверяемую ячейку
	djnz	Timer,	Skip_Set_Task_2			; проверяем, и если не ноль - пропускаем установку флага этого таймера
	mov	@Timer_Pointer,Timer			; обновим содержимое младшего байта софт-таймера
	dec	Timer_Pointer				; младший байт таймера = 0, вибираем старший байт
	mov	Timer,	@Timer_Pointer			; загружаем содержимое старшего байта софт-таймера в проверяемую ячейку
	djnz	Timer,	Skip_Set_Task_3			; проверяем, и если не ноль - пропускаем установку флага этого таймера
	bank_0
	mov	@Tail_,	A				; загрузим в конец очереди номер задачи этого софт-таймера
	dec	Tail_					; подвинем хвост для следующей задачи
	bank_3
	inc	Timer_Pointer                           ; вернем ячейку номера задачи
	inc	Timer_Pointer
	mov	@Timer_Pointer,#0                       ; и обнулим номер задачи
Skip_Set_Task:
	dec	Timer_Pointer                           ; пропускаем младший байт этого софт-таймера
	dec	Timer_Pointer                           ; пропускаем старший байт этого софт-таймера
Next_Timer_2:
	dec     Timer_Pointer                           ; берем следующий софт-таймер
	djnz	Timers_Counter,Next_Timer		; перебор всех софт-таймеров
	pop	PSW                                     ; восстановим банк памяти
	pop     ACC
	reti
Skip_Set_Task_2:
	mov     @Timer_Pointer,Timer			; обновим содержимое младшего байта софт-таймера
	dec     Timer_Pointer                           ; пропускаем старший байт этого софт-таймера
	jmp     Next_Timer_2
Skip_Set_Task_3:
	mov     @Timer_Pointer,Timer			; обновим содержимое старшего байта софт-таймера
	jmp     Next_Timer_2
end

Кратко по сути. Это масив програмных таймеров с индивидуальными задачами. То есть таймер дощелкал - и бросает в очередь задач номер своей задачи, которая достается из очереди и выполняется в главном цикле диспетчером. Все работает безупречно, пока таймеров немного, 7 штук еще нормально, 8 тоже, но иногда проскакивает сброс всех таймеров. 9 - совсем часто сбрасываются. Я прикинул по тактам, получается при самых неблагопритных условиях (одновремнно выщелкали все 8 таймеров) прерывание занимает 18 (общее начало) + 29*8шт. + 6 (концовка) = 256 тактов. Прерывания у меня почти каждые 1000 тактов. На основной цикл остается 750 тактов. Почему тогда получается затык ? Сейчас я написал код так, чтобы как можно быстрее выполнять самый длинный цикл - когда таймер выщелкал, а побочные ветки (когда таймер еще не выщелкал) у меня джампами выведены в отдельные ветки. Поэтому выход из прерывания посреди обработчика. И таймер я не останавливаю, чтобы количество програмных таймеров никак не влияло на период прерывания. Помогите увеличить количество програмных таймеров, если это возможно.

[BOB51]

Быстро "по ассоциации" - когдай-то был у меня макет "процедурные часы" на 16 таймеров с секундным разрешением... Вполне работоспособный. Но меньший интервал считать надо... плюс организация размещения данных в ОЗУ продумана. Прерывание в пакетном анализе только флаг в байте данных соответствующего таймера ставит ( ежли таймер разрешен), а внешняя прожка уже анализ с обработкой выполняет.
Особое замечание - таймер имеет десятичный эквивалент 0-59 т.е. занимает максимум 6 бит, 2 бита "свободно" - они и есть флаги.

[Пока_без_кота]

Ну у меня первоначальный вариант похожий был, когда в основном цикле крутился флаговый автомат (флагов было много, но именно таймерных 8 штук, как раз 1 байт, поэтому в то время я этот глюк и не словил), который, к слову, просто отлично реализуется на 51 ассемблере. Но когда программа разрастается, и флагов становится больше 2 десятков, уже не так удобно, прыгать надо через промежуточные метки, да и наглядность уменьшается. Раскурил управляемый вектор перехода, и написал простенький диспетчер (пока без приоритетов). Пока раздельно мигал 8 светодиодами вроде все было ок, а добавил динамик со своей частотой озвучивания (по сути 9 задача со своей частотой), и появились явные затыки. Вот и хотелось бы разобратся, как увеличить количество таймеров без появления сбоев, если это возможно.

[BOB51]

В таком случае единственный тайм-маркер (дубль переполнения одного из системных) и потом последовательно разбираемся с остальными интервалами.
Превичная задача там, где интервал соизмерим с прерыванием, более медленные процессы оставляем на "свободное время".
Векторный обход как вариант... однако есть более скоростное "отсеивание" (в случае "массива кухоннвх таймеров" с дискретностью в 1 минуту) - в регистре косвенной адресации (ri) указатель на точку в массиве счетчиков (адрес конца массива=adr_end), в каждом счетчике флаг переполнения (f_inc_min) и флаг разрешения работы (f_ensec):

Спойлер

start:
mov a,@ri
jnb A.f_ensec,goo
work:
inc @ri
cjne @ri,#60,goo
mov @ri,(1<<f_inc_min | 1<<f_ensec) ; т.е. флаг режима неизменный, добавим флаг переполения и сбросим значение счетчика в 0
goo:
inc ri
cjne ri,#adr_end,start
reti

воть как-то так...

Ну и "на закусь" - "вывернутый вариант" - основной цикл есть прерывание, а возврат делаем в соответствующую текущую точку программы. Но то ужж... больно извратно - проще несколько мелких периферийных добавок на основе PIC/AVR довесить в схемку с собственными аппаратно-программными ресурсами.

[Пока_без_кота]

Я вот заметил, что Вы в уже не в первый раз в пропагандируете MCS-51 в качестве управляющего контроллера, а AVR и PIC в качестве мозгов периферии, разных датчиков. Мне эта идея тоже нравится, только накладно это по средствам. А так да, классно подцепить какой-то Attiny26 в качестве "умного АЦП" , и по собственному протоколу (на безе того же ЮАРТ-а или И2С) передавать команду старта преобразования, и через заранее договоренное время (или по флажку какому-то) забирать рузультат.

[BOB51]

В вышеприведенном пара ошибок закралась...
имеем
jnb A.f_ensec,goo
надо
jnb AСС.f_ensec,goo
и
cjne @ri,#60,goo
тогда как в маске надо учитывать активный флаг f_ensec, т.е.
cjne @ri,#(1<<f_ensec | 60),goo
это ежли препроцессор компилятора конструкцию вида (1<<f_ensec | 60) поддержит...
в противном случае там банальное #0b01111100 (при f_ensec=7).
Насчет "умного АЦП" - гораздо приятнее будет АТтини25 (45, 85) - всего-то 100 российских рубчиков у нас. А возможностей при 8 лапках...
В принципе подход несколько иной - использование распределенных самодельных СБИС, изготовленных из "подручно-доступных" (и заранее проработанных как по ресурсам, так и по корпусировке/совместимости) доступных семейств МК. Ежли задачка посильна одному МК - вполне съедобно, а если цеплять несколько штук... Более практична 51-я (для того и разрабатывалась). Вполне удобоваримы АВР. И весьма вкусненькие PIC24. НО... "кусаются".
Среднмладшие ПИКи выгоднее в роли спецконтроллеров периферии. А STM8 уж больно под СИ заточены (хоша... их ассемблер поставлен на изучение в неспешном порядке).