Каковы особенности внутренней работы PIC'ов с данными ?
 Ответ:
 [Вернуться в категорию "Микроконтроллеры семейства PIC"]
Небольшое предисловие: употребляемые далее формулировки типа "нечто _может_ произойти" ("значение _может_ измениться") отнюдь не означают какой-то случайности этого события, все полностью предсказуемо, но оговаривать в каждом случае влияющие факторы было бы излишним (чаще всего это pull-up или pull-down на соответствующем выводе). В документации (параграф "Выполнение команд") указывается, что после чтения и декодирования команды производится чтение байта данных, АЛУ выполняет требуемую операцию, затем результат записывается по требуемому адресу (W или адрес операнда). То есть _все_ операции над данными выполняются как "чтение-модификация-запись" (read-modify-write, далее в этом пункте - RMW), даже если одно или два из этих трех элементарных действий излишни в каком-то конкретном случае. Естественно, в АЛУ используются только те данные, которые реально нужны для этой команды. Так например, для команды "movwf PCLATH" безразлично старое значение PCLATH. Конечно, такой подход приводит к выполнению "бесполезных" действий, однако не замедляет работу, так как те узлы, которые выполняют эти "бесполезные" действия все равно никак не могли бы помочь в выполнении действий "полезных". А реализацию процессора это существенно упрощает. Hо иногда RMW приводит к некоторым неочевидным эффектам. Так, например, команда "tstf XXX" (которая на самом деле "movf XXX,f", то есть "пересылка из XXX в XXX") действительно выполнит запись в XXX. Конечно, в большинстве случаев это ни на чем не отражается, но для некоторых регистров бывает важен сам факт записи. Таковы, например, TMR0 и PCL. Иногда к неочевидным последствиям может привести не запись, а чтение данных. Похоже, что именно это (чтение в неподходящий момент, сам _факт_ чтения) является первопричиной некоторых ошибок, отраженных в errata. При работе с портами важен не факт чтения, а само прочитанное значение в сочетании с последующей записью. Это может давать отмеченый в документации побочный эффект (возможное изменение содержимого бита регистра данных порта, если соответствующий вывод настроен как вход). При чтении документации этот момент кажется очевидным и не всегда запоминается как источник возможной ошибки. А источник коварный. Ситуации "тут работаем с одним битом порта, а десятью строками выше (или ниже) - с другим, причем забыв о RMW" отслеживаются легко. Hо то же самое может произойти и при обработке прерывания, если оно использует [другие] биты того же порта. Hапример, такой участок кода (команды переключения страниц опущены): clrf TRISB bcf PORTB,0 ; выход, состояние '0' (важно что _известное_) Part1: ... ; что-то делаем, но RB0 не трогаем bsf TRISB,0 ; RB0 в hi-Z, но его буфер по-прежнему '0' Part2: ... ; здесь нет обращений к PORTB bcf TRISB,0 ; надеемся получить на RB0 уровень '0' Если во время исполнения фрагмента Part2 произойдет прерывание, изменяющее какой-либо бит в PORTB (кроме нашего RB0, разумеется), то после "bcf TRISB,0" сигнал на выводе RB0 вполне может оказаться '1' (зависит от внешних цепей). В частности, фрагмент Part2 может быть и пустым (непосредственно за bsf следует bcf), что создает ничем не обоснованную иллюзию, что между bsf и bcf "ну вообще нет никаких обращений к PORTB". Да, такая необходимость переключать вывод из hi-Z непосредственно в _требуемое_ состояние возникает не очень часто (обычно при эмуляции открытого коллектора при реализации I2C master), но иногда это бывает нужно. Очевидно, что для обеспечения невмешательства потусторонних сил достаточно просто запретить прерывания на время от установки требуемого значения в регистре данных порта до переключения этого разряда порта в режим выхода. Cходный побочный эффект от RMW при работе с портами описан и в следующем вопросе.[Микроконтроллеры семейства PIC]
|
