Ето два съвета по проблеми които са ми загубили доста време с пикльовците:

1. Тези пикове които има компаратор, след Reset по подразбиране правят прилежащите пинове да обслужват тази функция. Това значи че даже и да бъзикате TRIS/PORT/LAT регистрите тези пинове може и да не работят коректно. Ако няма да ползвате компаратора - изключете го веднага след Reseta. Такъв проблем съм имал с мъниците (12F).

2. Средно големите пикове (напр. 18F452) имат един такъв модул - PSP. Когато е включен тоя модул арбитрира порт D. Аз лично разумно приложение не съм му открил. По подразбиране е спрян (което е добре). Великата тъпотия е че включването/изключването на тоя модул става с бит който е в регистъра ???TRISE???. Много на място нали. Идиотското е че точно тоя процесор физически има само 3 I/O-та на порт Е и пичовете решили че останалите свободни битове в TRISE, могат да служат за друго - т.е за PSP модула. Нищо лошо, ама някой индивиди като мен, имат навика да правят по подразбиране пиновете които физически не съществуват - входове. Т.е RA6,RA7, RE3+ аз по подразбиране им пиша 1 в TRIS-a. Е съответно тъпия модул се включва и порт D ми става недостъпен. Седя аз и се пуля, всички регистри обикалям, ама кой да се сети да гледа в TRIS регистъра на съседния порт.

Да не губите време. Аз хем съм се блъскал в тая стена, днес пак утепах час по втория проблем.

...

Нищо ново под слънцето. Особено при пилкльовците се среща често нещата да не са реализирани по интуитивен начин. Аз поне редовно си дописвам пдф-овете на пиковете с които работя. Добре че го има proteus че бързо да се изхващат такива проблеми.

Темата е полезна .

Абсолютно задължително, защото и аз се въртях на шиш .
Затова сега си имам три програматора .

...

По мое скромно мнение е наистина "що годе" - подобно на книгата на "МК". Ако човек се сблъсква за първи път с контролер и не знае що е процесор, ще успее да накара някой светодиод да мига.
Ако обаче иска да направи устройство, което наистина да върши нещо трябва да забрави за тези книги, а да се запознае подробно с асемблера и след няколко работещи програми да премине към С.
В тази връзка, дай някакъв линк към подобно ръководство за С.

Много интересна тема...тук ще се изпише доста Няколко неща които научих от опит...
1. Голяма главоблъсканица със прекъсванията - например в 18F452 на 20MHz съм написал "bcf GIE", обаче проверявам след 2-3 инструкции, тоя флаг пак си е горе!!! Мой колега (gnm_soft ) предложи интересна идея Адски тъпо...обаче работи.
2. Голям проблем с I2C периферията (по-точно с MSSP-тo) - има някаква тъпа хардуерна връзка нейде из пикльото... Като включа I2C шината, RC5 (в моя случай го ползвах за Enable/Disable на RS485) става неизползваем...не мога да пиша и чета от него, независимо какво пиша в TRISC, LATC или PORTC!!!

Имат и още много изцепки, за които ме домързява да пиша... И тва всичкото си е губене на време...

...

Говоря за MSSP на PIC16F877A и PIC18F452 (абсолютно еднакъв АСМ код и за двата). Нямам спомен как точно го бях написал, но при Маster I2C, RC5 ми зависва... Доста време ми отне да разбера че проблема е там. Явно има някакъв гаф с превключването на I2C и SPI

...

Накои неща които описвате не са бъгове, а са следствие от организацията на самия чип и са добре описани от Microchip.
Липсата на реакция при bcf GIE не е BUG .
Просто нулирането на този бит не може да спре веднага активирано прекъсване след тази инструкция. Бита се нулира но за да блокира
прекъсването е необходимо още време за реакция на процесора след инструкцията.Ако следващия цикъл (след bcf GIE) е преход към прекъсване то не може да бъде спряно. Прекъсването завършва с
RETFIE, което връща GIE в 1. Затова bcf GIE остава без
реакция и е необходимо да се използва:
do{GIE = 0}while{GIE=1}

Блокирането на премането при USART при препълване също не е BUG . Просто трябва да се проверява наличие на препълване,( което се прави нормално при всички други системи) и ако има препилване е необходимо да се нулира хардуера.


btfss RCSTA,OERR ; RC_OVERFLOW
goto GETCHAR
bcf RCSTA,CREN ; CLR HARDWARE
NOP
bsf RCSTA,CREN

Всичко това е описано и е особеност на хардуерната организация на чиповете им и според мен не трябва да ги квалифицираме като бъгове, а като специфични особености.

...

Абе това с забраната на прекъсванията направо ме уби. Никога не съм забелязал подобен ефект. Веднага го пробвах и не мога да възпройзведа проблема (ICD2, код генериран от C18, 18F452). Значи имам си инструкция BCF 0xFF2, 0x7, ACCESS - работи си абсолютно коректно. Поне бита със сигурност се нулира веднага. Опитах и с точка на прекъсване в следващата инструкция - когато спра там, бита вече е нула. 20 инструкции след това не е мръднал. Как го правите това, да не се нулира коректно? Бита със сигурност мърда коректно според мен. А единствения начин след това да има некоректен резултат би бил ако прекъсването е започнало преди инструкцията за нулиране на бита. Заради латентноста на прекъсването то се активира 2 инструкции след настъпването му. Ако една от тези две инструкции е въпросното нулиране на бита, най-вероятно ще се активира прекъсване въпреки това. Тогава теоретично може и да възникне въпросния проблем - тъй като пика ще вдигне бита на излизане от прекъсването. Но тогава и вашия while цикъл не е 100% решение.

P.S. Сега се порових в документацията. Излиза че и предположението ми за възникнало прекъсване непосредствено преди забраната не би следвало да е проблем, тъй като при възникване на прекъсване, ядрото наистина изпълнява още две инструкции, но те са симулирани Nop(), следователно след излизане от прекъсването бита би следвало да се нулира от инструкцията за нулиране която ще се изпълни коректно след прекъсването.

Вие говорите че все пак въпросния проблем е упоменат някъде в документацията на Микрочип. Насочете ме.

А за препълването на UART-a, също не мога да ти възпройзведа проблема - за да го пробвам - препълвам UART-a. Детектирам грешката - изчитам буферите, рисетвам модула през CREN бита и след това пак започвам да приемам данни. Няма проблем. Е не ползвам 9 бит. И процесора е 18F452. Но проблем с успиване на UART-a, нямам. В интерес на истината съм правил доста устройства със RS232 комуникация, препълването на UART-а съм го виждал много пъти при разработката, но никога не съм имал случай процесора да ми умира след това, и да не мога да възобновя комуникацията. Може би не попадам в точно същите условия като теб.

ох, кога ще взема и аз да разбирам за какво говорите