Вопросы по PIC
Q: Какие кросс-средства есть для PIC и где их взять?
Q: Компилятор HiTech выдает сообщения об ошибках там где он их раньше не выдавал, или там где их явно нет.
Q: Мне не удается повторно запрограммировать кристалл с УФ стиранием. Стираю его так же как и все другие кристаллы, а программатор сообщает что кристалл не чистый
Q: Странно себя ведет RA4 сконфигурированный на выход
Q: Каковы особенности внутренней работы PIC'ов с данными ?
Q: PORTA (и PORTE) в PIC'е с АЦП как-то странно работает ?
Q: Странно ведет себя бит порта сконфигурированный для работы со спецфункцией в двунаправленном режиме (например в режиме I2C), он самопроизвольно меняет направление (вход/выход) вовсе не в соответствии с алгоритмом работы спецфункции (например вызывает блокировку шины I2C).
Q: Можно ли перепрошить программную память FLASH PICов через интерфейсы RS232, I2C, SPI и др.?
Q: Программа ранее разработанная для OTP PIC16C77 и отлаженная в нем не работает в FLASH версии PIC16F877. Почему, ведь это 100% аналоги, исключая EEPROM у F877.
Q: Как с помощью PicStart+ запрограммировать PIC17C756? Почему не удается это сделать с "фирменным" адаптером для PicStart+ для PLCC68 корпусов?
Q: А можно прочитать PIC, если у него установлены биты защиты ?
А реализацию процессора это существенно упрощает. 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 при работе с портами описан и в следующем вопросе. >Q: PORTA (и порт E) в PIC'е с АЦП как-то странно работает ? A: Владимир Клочко
В документации на PIC описано, что выводы, сконфигурированные как аналоговые (регистр ADCON1), перестают работать как цифровые входы. Это связано с тем, что при конфигурировании вывода как аналогового запрещается работа его [цифрового] входного буфера, чтобы подача промежуточных значений напряжения не приводила к протеканию сквозных токов в этом буфере. Такие входы читаются как '0'. Однако работа выходного буфера не запрещается и он по-прежнему управляется соответствующими битами регистров TRISA (TRISE) и PORTA (PORTE). Поэтому естественно, что для реального использования вывода как аналогового следует перевести его выходной буфер в hi-Z. Если же это не так, и выходной буфер активизирован (TRIS=0, предполагается отсутствие конфликта с внешними цепями, подключенными к этому выводу), то это никак не повлияет на работу модуля АЦП, и при выборе этого канала он будет добросовестно преобразовывать напряжение на этом выводе (а уж осмысленность этого останется на совести разработчика). Из вышеизложенного следует, что выводы, сконфигурированные как аналоговые, при необходимости (а выводы, как и любые другие ресурсы, чаще в дефиците, чем в избытке) вполне можно задействовать как цифровые выходы. Однако работать с ними (и другими цифровыми выходами портов A и E, если таковые имеются) придется аккуратнее, чем обычно. "Опасность" представляют циклы "чтение-модификация-запись", то есть арифметические и логические операции с портом, а также установка и сброс битов.
В отличие от этого, команды "movwf" или "clrf" никак не используют старое значение и не могут иметь побочного эффекта. Hо команда "tstf" - имеет (см.вопрос о внутренней работе с данными). Пусть, например, в ADCON1 часть выводов (или все) включены как аналоговые, но 0-й бит регистра TRISA сброшен (то есть RA0 - выход) и RA0=1 (на RA0 высокий уровень). Тогда ничем не примечательная команда "bsf PORTA,4" приведет (помимо желаемого результата) также и к сбросу RA0, так как в этот разряд регистра данных порта запишется '0', прочитанный из-за того, что цифровой входной буфер на RA0 при этом выключен. Другой пример. Пусть в системе на pic16c74 (77, etc.) требуются 6 аналоговых входов и 2 цифровых выхода. Очевидно, что придется выбрать как аналоговые все 8 входов (регистр ADCON1), но 2 из них использовать как цифровые выходы. Если это будут 2 вывода _одного_ порта (A или E), то _независимо_ манипулировать ими при помощи команд bsf и bcf не удастся. Следует также помнить, что после сброса ADCON1=0, то есть все аналоговые входы включены именно как аналоговые. И это вполне логично, так как уровни на них могут оказаться отнюдь не цифровые. Так что даже если в конкретной системе АЦП вообще не используется, то все равно придется "работать с АЦП": модифицировать регистр ADCON1, чтобы переключить выводы в цифровой режим. >Q: Странно ведет себя бит порта сконфигурированный для работы со спецфункцией в двунаправленном режиме (например в режиме I2C), он самопроизвольно меняет направление (вход/выход) вовсе не в соответствии с алгоритмом работы спецфункции (например вызывает блокировку шины I2C). A: Михаил Евстафьев
Это из-за особенностей схемотехники портов PICов... См. примечание на стр... >Q: Можно ли перепрошить программную память FLASH PICов через интерфейсы RS232, I2C, SPI и др.? A: Михаил Евстафьев
Да ... >Q: Программа ранее разработанная для OTP PIC16C77 и отлаженная в нем не работает в FLASH версии PIC16F877. Почему, ведь это 100% аналоги, исключая EEPROM у F877. A: Михаил Евстафьев
Включен режим низковольтного внутрисхемного программирования (LVP) в байте конфигурации кристалла. >Q: Как с помощью PicStart+ запрограммировать PIC17C756? Почему не удается это сделать с "фирменным" адаптером для PicStart+ для PLCC68 корпусов? A: Михаил Евстафьев
Hужно изготовить адаптер по схеме... >Q: А можно прочитать PIC, если у него установлены биты защиты ? A: Алексей Владимиров
По-разному для разных кристаллов. Для PIC16C5X/PIC12C5XX адреса 000-03F можно считать (и допрограммировать) и после установки бита защиты. Ссылка на эту особенность есть в фирменной документации. Для PIC16C8X существует метод взлома, опубликованный Давидом Тайтом на http://www.brouhaha.com/~eric/pic/84security.html. Аналогичный метод для PIC16C8X/PIC16F8X используется в программаторе PICPROG фирмы Телесистемы http://www.telesys.ru/english/picprog.htm. Можно воспользоваться и сервисом, предлагаемым на http://u1.chat.ru/hack84.htm. Возможно, эти методы применимы и к новым PIC16F8xx. Для PIC16C61/71 существует метод взлома, описанный Дежаном Калевичем (ссылка перестала работать) Для других PIC пока ничего, кроме физических методов считывания (электронный микроскоп и т.п.), мне не встречалось. Еесли возникает задача считывания, можно обратиться, например, на http://www.mts.net/~tgrand/index.html
