Поклонники продукции Microchip Technology Inc тусуются тут.
Ответить

Вычисляемый переход - проблема

Вс сен 02, 2018 06:22:11

Прошу помощи коты. Контроллер PIC18F2620.
Вычисляемый переход работает как то неверно, т. е. если я присваиваю W=0, попадаю к CODE_0,
при W=1, попадаю к CODE_2,
при W=2, попадаю к CODE_2,

при W=3, попадаю к CODE_4,
при W=4, попадаю к CODE_4,

при W=5, попадаю к CODE_6,
при W=6, попадаю к CODE_6.

Почему такой дубляж?

TABL_COD_PICTURE
MOVLW .5 ;ПРИСВАИВАЮ W=0; 1; 2; 3; 4; 5; 6...
MULLW .2 ;УМНОЖАЮ НА 2.
MOVF PRODL,W ;КЛАДУ В W

ORG 0X600
ADDWF PCL
GOTO CODE_0
GOTO CODE_2
GOTO CODE_4
GOTO CODE_6
GOTO CODE_8
;...

Re: Вычисляемый переход - проблема

Вс сен 02, 2018 06:56:18

Читайте внимательно о системе команд и особенностях операций с PCL.
Раздел:
"PCL как источник данных и регистр назначения при выполнении команды"
Во всех случаях даже у среднемладших в старший байт адреса идет содержимое PCLATH, причем перенос из результата действия с содержимым PCL игнорируется.
У 18-х еще добавлен PCLATU.
и перезапись занчения из PC в PCLATU:PCLATH при чтении из PCL
Помимо того еще добавлено аппаратное приведение бита PCL.0 результата операции с PCL к 0.
Так что... ежли не изменялся PCLATU:PCLATH прыжок будет в область 0х0000
Помимо прочего добавится мозготреп по сохранению/восстановлению предыдущего содержимого тех PCLATU:PCLATH в исходное состояние для последующего корректного исполнения программы.
Или... все подпрограммы храним в сегменте 0х0000.
Фокусы с PCLATU:PCLATH не только вычисляемого перехода касаются!
:beer:

Re: Вычисляемый переход - проблема

Вс сен 02, 2018 07:06:27

В PIC18, на сколько мне известно, есть косвенный вызов подпрограмм. К чему эти все выкрутасы ?

Re: Вычисляемый переход - проблема

Вс сен 02, 2018 13:45:44

Почему такой дубляж?

Патамушта адрес в программной памяти инкрементируется на 2. То есть бывает ТОЛЬКО ЧЕТНЫЙ. Нечетным может быть только СТАРШИЙ БАЙТ программного слова при обращении к нему как к байту, иначе четный и нечетный байт читается идентично, либо приводит к ошибке адреса (в 16-разрядной платформе). Это справедливо для PIC18, PIC24 и dsPIC30/33.

Re: Вычисляемый переход - проблема

Вс сен 02, 2018 14:48:26

В PIC18, на сколько мне известно, есть косвенный вызов подпрограмм. К чему эти все выкрутасы ?

CALLW - это из "расширенных инструкций" для 18-х - мозготрепа с ними для начинающих еще больше.
Другое дело из "улучшенных среднемладших" - команды BRA addr, CALLW и BRW те действительно штука весьма вкусненькая!
:hunger:

Re: Вычисляемый переход - проблема

Вс сен 02, 2018 16:46:52

Про четный нечетный читал. Решил, что для этого хватить того, что я умножаю число на 2.
Как же этим пользоваться? Есть у кого нибудь решение? Брало с документации микрочипа коды, но не работает!

Re: Вычисляемый переход - проблема

Вс сен 02, 2018 17:13:22

Проверьте текущий банк памяти перед MOVF PRODL,W и ADDWF PCL...

Re: Вычисляемый переход - проблема

Вс сен 02, 2018 17:37:51

проще просто прочитать PCL (предварительно сохранив PCLATU:PCLATH)
а еще удобнее воспользоваться старой рекомендацией мелкощипа - все вектора переходов ставить в банке 0.
:dont_know:
Со среднемладшими подсказать проще, с 18-й пока только "разбор полетов" по системе команд прорадатывал - редкостный кристалл и дорогой для тренировок, да и задачку надо для такого посолиднее "лампочек-кнопочек" (пока не нашел чего примутить)...
:(

Re: Вычисляемый переход - проблема

Вс сен 02, 2018 17:38:49

я умножаю число на 2

Достаточно левого логического сдвига (rlncf WREG, f). Умножение тут лишнее. Это первое. А второе, команды goto, которые Вы изволили применить вместо bra, занимают ДВА МАШИННЫХ СЛОВА, то есть ЧЕТЫРЕ байта. От того и баг.
:tea:

Re: Вычисляемый переход - проблема

Пн сен 03, 2018 15:48:34

я умножаю число на 2

Достаточно левого логического сдвига (rlncf WREG, f). Умножение тут лишнее. Это первое. А второе, команды goto, которые Вы изволили применить вместо bra, занимают ДВА МАШИННЫХ СЛОВА, то есть ЧЕТЫРЕ байта. От того и баг.
:tea:


BRA BRA BRA!!!!

Спасибо тебе добрый человек! Про одно и два слова GOTO и BRA читал, но не знал что на счетчик РС действует. Умножать или сдвигать разницы нет конечно, тем паче из микрочипа брал где то.
Самое прикольное я ведь пробовал с BRA, только не всю таблицу и часть GOTO оставил, а как до GOTO доходил, так сбой!
А то я уже начал с XORWF городить огород, проверяя 16 числе))))).
Бесконечное тебе спасибо человек! Не зря я сюда за помощью пришел)))).


; CLRF PCLATH
; CLRF PCLATU
RLNCF temp_code,W ; СДВИГ, УМНОЖАЮ НА 2
ORG 0X600
ADDWF PCL,F
BRA CODE_0
BRA CODE_1
BRA CODE_2
BRA CODE_3
BRA CODE_4
BRA CODE_5
BRA CODE_6
BRA CODE_7

Re: Вычисляемый переход - проблема

Вт окт 30, 2018 07:45:28

Прошу помощи ... Контроллер PIC18F2620.
Вычисляемый переход работает как то неверно, т. е. если я присваиваю W=0, попадаю к CODE_0,

Хороший вопрос, лично я не быстро нашёл ответ.
Надо помнить что защёлки указателя исполняемого адреса - не заполняются сами по себе, а лишь при явном обращении проги к PC на чтение.
Надо помнить что защёлки указателя исполняемого адреса - могут портится в прерываниях и тогда их тоже надо сохранять при входе/выходе прерывания.
Лично я при написании/отладке прожекта http://vfd.psw2.ru/ использовал 4 варианта вычисляемого перехода:
Спойлер
Код:
Все способы портят WREG, так что это не считается за особенность.
1. Самый надёжный способ, но нет изохронности.
; Если веток мало (дзен около 5-7, зависит от контроля границ) или сохранять PCLAT не хочется - то быстрее/удобнее работает тупой перебор:
; без порчи защёлок вычисляемым переходом и без необходимости контролировать номер ветки:
   movf   Case_Num,W,ACCESS   ;
 bz      Case_0 ;
   dcfsnz   WREG,W,ACCESS   
 bra      Case_1 ;
   dcfsnz   WREG,W,ACCESS   
 bra      Case_2 ;
   dcfsnz   WREG,W,ACCESS   
 bra      Case_3 ;
; Если номер > 3 то выполняется 4 ветка
;   dcfsnz   WREG,W,ACCESS   

2. Макрос GoToWreg  - остатки моей попытки просто складывать 24 бита адреса
GoToWreg   macro   TempBuff,Adr1 ; Использует Tmp 1 байт
; Переход на количество команд - смещение из WREG
; Команды располагаются непосредственно за макросом
; 20/03/2017 пробую укоротить максимально,  Вроде 10 команд если 1 сдвиг

 local BeginJumpBlock;
   movwf   TempBuff,Adr1; Спасаем РабРег

   movlf   High(BeginJumpBlock),PCLATH,ACCESS   ;   ПОРТИТ РАБРЕГ
    bcf      _C            ; Чистим входной перенос

   rlcf    TempBuff,W,Adr1   ; Удваиваем номер байта для вычисляемого перехода

   addlw    Low(BeginJumpBlock)   ; смещение в РабРеге,
   btfsc   _C   ; Перенос был при сложении ?
      incf   PCLATH,F,ACCESS      ; прибавляю 1 к среднему байту

   clrf   PCLATU,ACCESS      ; Верхний - всегда =0
    movwf   PCL,ACCESS ; Заполняем PCLAT
BeginJumpBlock
   endm

3. Макрос BraReg ; 8 команд, но BRA шагает лишь на 2^10 команд
BraReg   macro   RegPoint,Adr1 ; смещение номера БРА - в регистре
; Смещение - не изменяется
; Переход на количество команд - смещение из Регистра
; Команды располагаются непосредственно за макросом
 local BeginJumpBlock;,Continue,Continue1   ;
 movlf   High(BeginJumpBlock),PCLATH,ACCESS   ;   ПОРТИТ РАБРЕГ
 bcf      _C            ; Чистим входной перенос
 rlcf   RegPoint,W,Adr1   ; Удваиваем номер байта для вычисляемого перехода
 addlw   Low(BeginJumpBlock)   ; смещение в РабРеге,
 btfsc   _C   ; Перенос был при сложении ?
   incf   PCLATH,F,ACCESS      ; прибавляю 1 к среднему байту
   clrf   PCLATU,ACCESS      ; Верхний - всегда =0
 movwf   PCL,ACCESS ; Заполняем PCLAT
BeginJumpBlock
   endm

4. Интересная сабпрога какого-то американца, примерно 6+4 циклов команд
; K8LH RE: PIC18F4331: COMPUTED GOTO!• Thursday, August 17, 2006 8:22 AM (permalink)
;http://www.microchip.com/forums/m182713.aspx javascript:void(showMsgNum(182838))
; Вариант вычисляемых переходов через саб прогу - быть могет удобен ?
; Две точки входа у одной сабпроги - в зависимости от используемых команд перехода.
CaseGoTo:   ;; Смещение - WREG
   bcf   _C   ; автор не чистил входной перенос - Чистка переноса на входе для пары сдвигов
      rlncf   WREG,F,ACCESS   ; первый сдвиг
CaseBra:   ; Второй вход - единственный сдвиг
      rlncf   WREG,F,ACCESS   ;
   bcf   WREG,0,ACCESS   ; чистка младшего бита для одного сдвига
   addwf   TOSL,f,ACCESS ; младший
   movlw   0x0           ; авторская метка/фишка вместо традиционного CLRF WREG чистим
   addwfc  TOSH,f,ACCESS ; средний
;addwfc  TOSU,f,ACCESS; старший for > 64-kbyte memory
   return; Адрес возврата суммирован со смещением из WREG

Другое дело из "улучшенных среднемладших" - команды BRA addr, CALLW и BRW те действительно штука весьма вкусненькая!

А можно подробнее - в чём именно их вкусность и как именно её использовать ?
а еще удобнее воспользоваться старой рекомендацией мелкощипа - все вектора переходов ставить в банке 0.

Это удобно если "под каждую задачу - свой мелкопроц" повышать продажи микрочипов.
Это неудобно если проект модульный и перерастает 256 команд. Как делить первые 256 команд между модулями, которых может не быть ?
Как преодолевать границы 256 байт "страниц" памяти программ, если блок переходов не вписывается в страницу ?
Варианты выше - они были найдены именно для преодоления границ 256 команд и тупого сложения смещения с PC, работают в любом месте кода.
Если кода более 64 кб - то надо раскоментить обработку/присваивание PCLATHU.
BRA BRA BRA!!!!
Бесконечное тебе спасибо человек! Не зря я сюда за помощью пришел)))).
Код:
;    CLRF   PCLATH
;    CLRF   PCLATU
    RLNCF   temp_code,W ; СДВИГ, УМНОЖАЮ НА 2
    ORG      0X600
    ADDWF   PCL,F   ; по лично мне здесь ошибка - используются PCLATH и PCLATU но в них неизвестные значения
; которые при сбросе могут быть любыми
    BRA      CODE_0
    BRA      CODE_1
    BRA      CODE_2
    BRA      CODE_3
    BRA      CODE_4
    BRA      CODE_5
    BRA      CODE_6
    BRA      CODE_7

И как, устойчиво работает ?
Особенно при наличии нескольких таких вычисляемых переходов в проге ?
Со среднемладшими подсказать проще, с 18-й пока только "разбор полетов" по системе команд прорадатывал - редкостный кристалл и дорогой для тренировок, да и задачку надо для такого посолиднее "лампочек-кнопочек" (пока не нашел чего примутить)...

Быть могет частотничек для компрессора в гараже запилить ?

Re: Вычисляемый переход - проблема

Вт окт 30, 2018 10:41:17

[uquote="titr",url="/forum/viewtopic.php?p=3448530#p3448530"]Прошу помощи ... Контроллер PIC18F2620.
...
Если кода более 64 кб - то надо раскоментить обработку/присваивание PCLATHU....

Для таких задач надо и соответствующий МК подбирать, с наиболее приемлемой системой команд и наличием соответствующей аппаратной начинки.
То уже или 24-33я серии или другие семейства (АVR или АРМ к примеру, или еще чего специализированного).
8)

Re: Вычисляемый переход - проблема

Ср окт 31, 2018 10:02:49

Для таких задач надо и соответствующий МК подбирать

Кому именно - надо ?
Производителям мелкопроцов хочеццо впаривать более мощные камни для поощрения лени и тупости программера ?
Кому выгодно умение забивать микроскопом гвозди и моргать светодиодом на гигагерцовой/гигабайтной малинке ?
"Прогресс" не остановить, ибо тупость везде ?
Напомню - Билли Гейц всю жысь гордился тем, что он написал загрузчик более компактный чем Пол Аллен (или Стив Балмер) при цейтноте в самолёте.
Тем самым считал это соревнование интеллектов - выигранным у своего кореша, навсегда.
И он же признал Си "языком, пригодным для". Именно по причине использования ЧУЖИХ библиотек с закрытым кодом и обновлениями.
Дающими внезапно не декларированный функционал, например после "обновления".
Ну кроме тормозов, нагрузки на стек и жадности до камня/оперативы.
А для возвращения на землю - лично я не написал ни строки кода/асма на dsPIC и уж тем более на Pic32/STM32/ARM - именно по причине сложности начальной инициализации этих платформ.
А про малинку/банану и вообще речи нет, хотя заманчиво, согласен. Но как почитаешь описание проца - так и понимаешь что слаб умом.
И это началось ещё с описания процессора Пентиум толщиной 550 страниц в бумажном переплёте выпросил у кого-то на выставке ИВТ в 90е годы.
с наиболее приемлемой системой команд и наличием соответствующей аппаратной начинки.

Это конечно широко, некоторые производители сразу FPGA лепят на макетку, в который можно залить проц на выбор.
Но это лишь как метод забивать гвозди микроскопом пожирнее, согласен.
То уже или 24-33я серии или другие семейства (АVR или АРМ к примеру, или еще чего специализированного).

Речь в теме была про работающие реализации вычисляемых переходов в контексте PIC18.
Лично я показал то, что написал и нагуглил, применимое к теме.
Есть чем дополнить или возразить/поправить указанные методы вычисляемых переходов ?

Re: Вычисляемый переход - проблема

Ср окт 31, 2018 11:16:45

Речь в теме была про работающие реализации вычисляемых переходов в контексте PIC18.
Лично я показал

Собственно вопрос был закрыт. Я не слишком понял идею Вашего объяснения, если ошибка автора темы состояла лишь в том, что он не учел адресную длину инструкции goto.
Что до микроскопов и гвоздей, то использование 16 разрядных простейших PIC24FххKAххх решает все проблемы связанные с вычисляемым переходом, ни разу не поднимает цену МК, а даже наоборот, а так же упрощает множество других задач, не поднимая потребление и не имея избыточности по частоте. Даже архитектура ядра у них проще в понимании.

Re: Вычисляемый переход - проблема

Ср окт 31, 2018 12:09:40

...
[uquote="BOB51",url="/forum/viewtopic.php?p=3448814#p3448814"]Другое дело из "улучшенных среднемладших" - команды BRA addr, CALLW и BRW те действительно штука весьма вкусненькая!

А можно подробнее - в чём именно их вкусность и как именно её использовать ?...

В случае с "улучшенной среднемладшей" (с четырьмя и более цифирьками в наименовании к примеру PIC12F1823, PIC16F1826) одна проблема - не все из этой серии на старом mplab8.92 поддерживаются.
:cry:
Касательно BRA и BRW - смотри описание раздела PCL and PCLATH в частности LOADING OF PC IN
DIFFERENT SITUATIONS
Эти команды НЕ ИСПОЛЬЗУЮТ PCLATH.
А CALLW вообще для "среднемладших" явление абсолютно новое (как и многое другое, позаимствованное от 18-й серии).
:beer:

Re: Вычисляемый переход - проблема

Ср окт 31, 2018 12:30:29

Речь в теме была про работающие реализации вычисляемых переходов в контексте PIC18.

Собственно вопрос был закрыт. Я не слишком понял идею Вашего объяснения, если ошибка автора темы состояла лишь в том, что он не учел адресную длину инструкции goto.

По лично мне ошибка ещё и в том, что защёлки не заполнялись перед использованием.
использование 16 разрядных простейших PIC24FххKAххх решает все проблемы связанные с вычисляемым переходом

Согласен что индивидуальные вектора прерываний и 16 бит адреса и несколько РОН - это лучше чем один РабРег.
Тем не менее - лично я первый Pic30F2010 для повторения какого-либо AN908 или AN984 купил лет 15 назад, на до макетки он так и не дошёл, ни одной строки асма не написал.
А "проблемы с вычисляемым переходом в Pic18" по лично мне полностью устраняются совокупностью 4х способов, указанных выше.
Ну и коль уж офтопить - то 8 выходов PWM с аппаратным защитным интервалом и центрально-симметричной генерацией для 4 фазы двигла-шаговика в DIP корпусе есть лишь в 18F4431.
А в совокупности с бортовым интерфейсом енкодера - это порождает интересную задачку из прикладной математики в реальном времени - электронная гитара токарного станка/электронный зуборез из делительной головки/электронная коробка подач ходового винта.
Интересную тем, что лично мне неизвестен способ решения такой задачи "в лоб" хоть на 8 бит хоть на 16 бит ядре.
А обходными путями - открытое соревнование интеллектов, согласен.
Кто может указать на имеющиеся реализации такой штуковины на мегах/стм32/пик32/иных более мелких процах с открытым исходным кодом ?
Ну или хотяб обсудить алгоритмы подступа к проблеме мат моделирования зубчатой пары например 13/17 или 239/241 зубьев без накапливания статической ошибки за 100500 оборотов и с динамической ошибкой не более пары единиц младшего разряда датчиков/исполнительных механизмов ?
С учётом что таблица синуса выходной генерации например 256 элементов, количество импульсов входного енкодера например 600 или 2500 на оборот, а количество зубьев шестерён в цифровой гитаре надо изменять без перекомпиляции прожекта, и это могут быть простые числа.

Re: Вычисляемый переход - проблема

Ср окт 31, 2018 14:03:40

8 выходов PWM с аппаратным защитным интервалом и центрально-симметричной генерацией для 4 фазы двигла-шаговика в DIP корпусе есть лишь в 18F4431.
А в совокупности с бортовым интерфейсом енкодера - это порождает интересную задачку

Стоимость старинного 18F4431 на сегодняшний день составляет примерно 450...500 рублей, что делает применение dsPIC33EP128MC202 стоимостью 200...250 рублей очевидно предпочтительнее.
Корпус DIP28 имеется.

По лично мне ошибка ещё и в том, что защёлки не заполнялись перед использованием.

В контексте вопроса это ошибкой не являлось. Речь шла о ПРИМЕРЕ ИСПОЛЬЗОВАНИЯ, а не практической реализации.

Re: Вычисляемый переход - проблема

Ср окт 31, 2018 16:28:09

Стоимость старинного 18F4431 на сегодняшний день составляет примерно 450...500 рублей, что делает применение dsPIC33EP128MC202 стоимостью 200...250 рублей очевидно предпочтительнее.
Корпус DIP28 имеется.

28 ног - накладные потери 6 ног = маловаато будет, на экран/кнопу остаётся, а это второй проц. Да, гальваноразвязка сразу, согласен.
А у dsPic накладные потери ещё выше, и 40 ног могет не хватить если на 1 проце делать всё.
И общий бюджет деталей частотника существенно выше чем просто мелкопроц, быть могет именно потому микрочип и не снижает цены на 4431/2831 - ибо в сравнении с MC3PHAC они стоят сущие копейки.
А на 18F4431 есть возможность попытаться экран/кнопы, АЦП контроля мотора, енкодер вала, 8 каналов ШИМ повесить на единственный мелкопроц решения цифровой гитары.
Вот бы ещё придумать алгоритм только детальный с привязкой к имеющемуся железу, как делить скорость и получать скорость.
В контексте вопроса это ошибкой не являлось. Речь шла о ПРИМЕРЕ ИСПОЛЬЗОВАНИЯ, а не практической реализации.

Не, ну если топстартер заранее записан в диванные теоретики/протеусные знатоки, далёкие от паяльника - то согласен, как много нам открытий чудных ...
Тем не менее - была там ещё ошибка - переполнение PC при сложении со смещением не учитывалось.
Контроля границ смещения перед использованием не было.
В итоге - если цель - моргать 1 светодиодой из 8 не выходя из протеуса/не слезая с дивана - то она достигнута.
Но лично я неоднократно указывал зависающим на компе в барби детишкам - добится "молодец" в реальной жизни существенно сложнее чем в виртуальной вселенной.
Так что.

Re: Вычисляемый переход - проблема

Ср окт 31, 2018 16:57:31

А у dsPic накладные потери ещё выше, и 40 ног могет не хватить
Я не понимаю необходимость DIP-ов.
В чем их сакральный смысл?
Можно поставить 44 или 64 ноги и забыть про недостаток пинов.
Зато имеет место быть РЕМАП почти всей периферии на почти все ноги. Зато есть уникальный модуль PTG, который только своим наличием может определить выбор МК. Зато есть ДСП ядро, позволяющее элементарно писать фильтры, а так же квадратурную демодуляцию сигналов.
Про систему команд я уже не говорю. Тут даже и не в РОНах дело. Изящный и компактный код даже на АСМе.
ЗЫ. В догон. ШИМов там 10. Шесть скоростных (7,5 нс дискрет) и 4 стандартных Output Compare с полным ШИМ функционалом, включая центровзвешенный ШИМ и дедтаймы.
А есть аналогичные чипы этого же семейства за 400 рублей у которых вместе с 6 скоростными ШИМами еще 8 стандартных.

потому микрочип и не снижает цены на 4431/2831

Вы ошибаетесь в причинах сохранения цен.
Это не базар, тут цены определяются ТОЛЬКО ПЛОЩАДЬЮ ЧИПА. А площадь чипа определяется проектными нормами.
Поэтому все новые МК, даже имея кучу оперативной памяти и набитые до отказа всякой периферией стоят В РАЗЫ ДЕШЕВЛЕ старых контроллеров.

Re: Вычисляемый переход - проблема

Ср окт 31, 2018 17:44:55

У каждого свой наработанный арсенал как самих МК так и средств разработки.
Пока задачи вписываются в имеющуюся базу того арсенала вполне достаточно, а вот когда уже ВСЕ имеющиеся возможности исчерпаны или поднадоели/изучены начинается поиск чего повкуснее.
Не всегда в явонм виде.
Так что ежли человеку 18-й серии достаточно - вполне объяснимо.
Я таки до неё и не добрался пока - лежит в запасниках.
Относительно DIP... штука хорошая крнечно, но... на сегодня таких корпусов и почти нету и стоимость...
В то же время готовые платки с начинкой той же адуринки вполне вместо "черна ящика" с энным числом лапок подходят (тем более, что платка в сборе по цене кристалла, а то и менее).
Это ежли для личного радиолюбительства. Там и АВРки и АРМы...
В принципе ЛЮБОЕ ХОРОШО ИЗУЧЕННОЕ из имеющейся в наличии элементной базы приветствуется.
Другое дело - кто-то лучше конкретное семейство знает, кто-то хуже - вот и делимся тем, что известно (один мыш - все те деталюшки ИМПОРТНЫЕ и документация отнюдь не на понятном русскм хорошо еще ежли не на иероглифах...)
:beer:
Ответить