Разбираюсь с PIC18F14K50

Zhuk72

Первая серия.

Угораздило меня взяться за 18-ю серию, а именно за PIC18F14K50. Привлекло малое, но достаточное для большинства моих потребностей количество ног, функциональная насыщенность, "современность" МК, поддержка в ПИККИТ2, ну и наличие USB. Оно мне пока не нужно, но мало ли, вдруг поумнею и решусь задействовать.

Пока чипы в пути (заказал парочку) решил начать разбираться. До этого ничего из современного не трогал, только со старыми испытанными ПИЛ12 и 16 дело имел. Так вот прилепил к нему в Протеусе дисплей от 3310, энкодер с кнопкой и DS1307, чтоб в I2C попрактиковаться. Отработанные куски кода для дисплея и энкодера у меня есть, потому и задействовал их, как удобный визуально-управленческий блок.

Накидал начальные настройки битов, основные регистры законфигурировал, USB отключил, т.к. его выводы завязаны на энкодер, и на дисплей пустил выводить циклическую картинку для теста.
Это все заработало Протеусе (т.е. картинка выводится), но сотнями сыпались ошибки о том, что USB device not recognized. Крутил по всякому, читал и перечитывал описание портов, работу с USB, все правильно вроде. Там же фактически только один бит в регистре UCON, который отключает/включает его, а у меня Протеус показывает, что в нем прыгают биты, что-то там происходит непонятное.

Короче говоря, я это исправил. Каким образом? Просто в командах удалил последний 0, который согласно формату команд, например, movwf f,d,a должен указывать на access ram. Про организацию памяти я, конечно, прочитал, но почему это так влияет на работу, я не понял. Вернее как эта буква в конце влияет на память. Может кто-нибудь популярным языком вкратце объяснит?

Реклама

КРАМ

Тут дело такое.
18-ая серия имеет 16 разрядное слово команды. Таким образом, для непосредственной адресации большой оперативной памяти не хватает ее длины.
Поэтому ОЗУ разбито на страницы(банки). При адресации всего поля памяти данных необходимо в регистре BSR указать номер страницы с которой предстоит работать.
Поскольку обращение к ОЗУ с непосредственной адресацией чаще всего происходит к малому числу переменных, но к большому полю спецрегистров SFR, то видится целесообразным установить два режима доступа.
1. Режим 0, при котором сохраняется видимость 96 ячеек ОЗУ, и почти все SFR (160 регистров). BSR при этом игнорируется.
2. Режим 1, при котором адресация самого ОЗУ осуществляется через BSR и видимость SFR становится полной.
Если спецрегистр лежит не в зоне видимости режима 0, необходимо перейти на режим 1, а прежде одной командой установить BSR на последнюю страницу.
Буква а в конце команды - это и есть режим 0 или 1.
Это немного напоминает банки 12...16 серии, но фактически употребляется только при инициализации части SFR.
Вообще то все это расписано в даташите...

ЗЫ. У Вас странный выбор контроллера. Вообще то 14К50 предназначен для работы в МОСТАХ USB-UART или неких гаджетах с выходом на HID USB.
Если USB не нужен, то логичней применять PIC18F25K22.

Реклама

Zhuk72

Спасибо большое за пояснение, пока соображаю туго. Надо собраться.
С BSR и страничной памятью все понятно, я его потом обнулил, чтобы общаться только с первым банком. А вот безбанковская адресация пока не доходит.

Выбор МК обусловлен тем, что я еще и сам не знаю, что в конце у меня получится. Вернее куда занесет полет фантазии ))
Так что USB может понадобится, а может и нет.
Да и не в нем проблема, а в моей ошибке работы с памятью.

Dmitry Dubrovenko

Кстати, в 18 серии есть возможность, в некоторых чипах, включать "расширенную систему команд".
Там вообще адресация несколько по другому происходит.

Реклама

Zhuk72

Знаю, но я ее отключил. Мне бы пока с обычной системой разобраться. Пока есть некоторые непонятки, непривычные для понимания BN, BZ и иже с ними. Со статус-регистром как-то роднее было.
Но больше всего понравились BTG и MOVFF. Особенно первый )) Для всяческих миганий на порту в самый раз.

А для расширенного набора надо в config4L бит поднять и в МПЛАБе галочку поставить.

Реклама

HHIMERA

MOVFF там с причудами... а расширенные... больше катят для СИ...

Реклама

Zhuk72

Еще один вопрос.
Почему на нем не проходят финты типа goto $-1 ?
При компиляции выдает ошибку:

Error - file 'тра-та-та', section '.org_2', Symbol '_.org_2_00AA' is not word-aligned.

Не люблю из-за такой мелочи метки ставить

HHIMERA

Дык... написано же... "is not word-aligned"...
Пользуйтесь метками... тогда не нужно умножать на два... $-2... $-4... $-10...

Zhuk72

Что написано я понимаю. Непонятно, почему в младших сериях это работает, а здесь нет.

Длинные переходы через $ я не делаю, потому что при добавлении или удалении команд внутри перехода часто забываешь об этом и долго думаешь, где же напортачил.

HHIMERA

Другая организация памяти...

3.1.1 PROGRAM COUNTER

The PC addresses bytes in the program memory. To
prevent the PC from becoming misaligned with word
instructions, the Least Significant bit (LSb) of PCL is
fixed to a value of ‘0’. The PC increments by 2 to
address sequential instructions in the program memory.

The CALL, RCALL, GOTO and program branch
instructions write to the program counter directly. For
these instructions, the contents of PCLATH and
PCLATU are not transferred to the program counter.

Zhuk72

Только зашел написать, что уже понял причину, увидев следующий после btfss адрес равный +2. Значит goto $-1 просто уходил в пустоту.
Спасибо!

Между двумя подряд call-ми 4 адресных пространства. Да уж, придется на метки разоряться ))

Dmitry Dubrovenko

Кстати, данную особенность надо учитывать при использовании вычисляемого перехода (если по каким-то соображениям не используются табличные команды).
Также заполнять память, например директивой DE, необходимо чётным числом байтов. Иначе компилятор сам дополнит недостающий байт нулём.

master19

и еще имейте в виду - у pic18f14k50, нет встроенной отладки, т.е. прошить его можно хоть чем - pickit, icd и т.д. а отлаживать внутрисхемно - никак. только через переходник в который запаян специальный 14k50 - отладочный.

Zhuk72

Dmitry Dubrovenko писал(а):Кстати, данную особенность надо учитывать при использовании вычисляемого перехода (если по каким-то соображениям не используются табличные команды).
Также заполнять память, например директивой DE, необходимо чётным числом байтов. Иначе компилятор сам дополнит недостающий байт нулём.

По этому вопросу назрел вопрос.

Вторая серия.
Нужно вывести на графический дисплей цифры. Использую такую конструкцию:

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

; Чтение цифры. digit=digit*12 - цифра, которую необходимо отобразить.
    movlw   .6
    movwf   count           ; Запускаем счетчик байтов для 5х7 символов (последний всегда 0 для пробела).
    lfsr    0,digits             ; Загружаем в FSR0 начальный адрес дампа памяти с графикой,
    movf    digit,w           ; смещение, кратное 12, для считывания с нужного адреса
    addwf   FSR0L,f         ; добавляется к младшему байту FSR0 (FSR+12*digit).
sd1
    movff   POSTINC0,display         ; INDF0->display, increment FSR0
    call    lcdta                               ; Отправка байта на дисплей.
    decfsz  count,f                          ; Повторяем до обнуления счетчика.
    goto    sd1
    retlw   0

Дамп памяти задаю методом

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

digits
    dw  0x3E, 0x51, 0x49, 0x45, 0x3E, 0x00  ; 0
    dw  0x00, 0x42, 0x7F, 0x40, 0x00, 0x00  ; 1
    dw  0x42, 0x61, 0x51, 0x49, 0x46, 0x00  ; 2
    и т.д.

В результате в регистр display всегда загружается 0, несмотря на то, что адресация и приращение FSR0 происходит нормально.

Кусок дампа памяти выглядит так:

Новый рисунок (9).jpg

Пробовал после метки sd1 дополнительно наращивать FSR0L, чтобы из 003Е вытаскивать именно 3Е, не помогло.
Где я накосячил, знаКОТы, не подскажете?

КРАМ

А ничо, что FSR адресует ОЗУ, а оный "дамп" находится во флеше?
Вы отличаете одно от другого? Это ГАРВАРДСКАЯ архитектура, уважаемый...
Чтение флеша производится через команду *tblrd

Zhuk72

Было такое подозрение, но я его отмел в сторону

Попробовал и TBLRD*+, но не сразу смог сообразить, как скормить ему адрес дампа. Правда потом дошло, что надо было делать по кусками, их же 3. Сейчас попробую еще раз.
Спасибо!

КРАМ

Это команда ТОЛЬКО ЧТЕНИЯ из флеша в буфер.
Прежде надо указать в tblptr адрес чего читать, а потом после tblrd считать это в защелке tablat

Zhuk72

Это я знаю. В pointer задать адрес, из latch забирать байт. Просто ошибся при написании поста. Из 3-х кусков именно указатель таблицы состоит.

Обновление:

С табличным чтением получилось, но кривовато. Сейчас уже не до разбирательств, завтра буду думать, как сделать по-человечески.

Dmitry Dubrovenko

Zhuk72 писал(а):Было такое подозрение

Так собственно, в этом ничего нового.
В 16-м семействе точно так же, только нет специальных команд табличного чтения.