Странен проблем имах с този пик.

Проблема се получи в декодер на IR протокол.
Значи програмата представлява непрекъснат цикъл в които се прави обработката и освен това имам активно прекъсване от TIMER2 в което не правя нищо,просто установявам един флаг които ползвам в тялото на програмата.
Проблема се получава върху 16 битови променливива върху която често прилагам << и доколкото успях да локализирам проблема е че точно тези операции << и >> дават понякога неверен резултат.
Реших проблема като пак ползвам таимера но не ползвам прекъсване като проверявам флага като не съм променил почти нищо. Но ми стана интересно в защо точно се получава така. Някой сблъсквал ли се е с подобен бъг в тоя пик?

Най-добре е да постнеш кода, в който мислиш че се получава грешката от шифтването. Досега не съм забелязал проблем в такава проста операция.

Mного е важно и с кой компилер се получава. Ако може, пусни и дизасемблерен листинг

Анализирах асемблер листинга няколко пъти. Вчера поне 10 часа го гоних тоя проблем но не намерих няква грешка в кода. Проследих асемблер листинга дали някъде дето не трябва се пише в тая променлива но няма. Не го запазих оня вариант, оттогава претърпя доста корекции.
Сега на свежа глава като помислих върху наблиуденията си вчера мога да кажа и точно кога става със сигурност.
=============================================
Mask = Mask << 1 ;
000371 1003 BCF 0x3, 0
000372 DAA RLF 0x2a, F
000373 DAB RLF 0x2b, F
=============================================

Ако прекъсването стане точно след BCF 0x3, 0 след връщане от прекъсването флага за препълване се получава че е 1. Вероятно същия е ефекта и след 2рата команда но това не води до объркване логиката на работа на програмата.

а кода на прекъсването
==========================================
void interrupt tc_int(void)
110: {
111: if ( TMR2IF )
000008 183 CLRF 0x3
000009 1C8C BTFSS 0xc, 0x1
00000A 280D GOTO 0xd
112: {
113: Reset_flag = 1;
00000B 14A6 BSF 0x26, 0x1
114: TMR2IF = 0;
00000C 108C BCF 0xc, 0x1
115: }
116: }
==========================================
По идеята ми в началото трябваше да инвертира и един друг флаг в прекъсването и затова го направих с прекъсване. Проблема изчезна като махнах прекъсването и ползвах TMR2IF вместо Reset_flag[/code]

Да не бъркаш някъде в прекъсванията, т.е. дай листинга на кода с който запазваш служебните регистри на процесора при възникване на прекъсване ( WREG, FSR, STATUS & PCLATH ). При PIC16F627A има някаква недомислица в процесора, уж е почти същия като PIC16F627, обаче не е точно така. Не издържа на допир с пръст по MCLR, програмната памет се сгомнясва много бързо и то на някои места, уж се записва, но при втора верификация се четат 0, EEPROM-а за данни също се държи по сходен начин.

Само едно прекъсване се позваше и то е точно това дето съм го дал.
Там не се пипа както виждам флага за препълване .
А това с програмната памет сериозно ли го говориш. Не съм чувал такова нещо пък и преди бях питал тук в форума за надежноста на флаш пиковете и никои тогава не каза да има проблеми.

Сериозно говоря, тия светофарните брочи по София и страната, съм ги правил с такъв професор, в началото бяха PIC16F627/628, по едно време Комет имаха само с буква А и почнахме от тях да ползваме. Докато да разбера какво става изпонатръшках 10-тина броя. Не съм се задълбавал да изследвам по-сериозно с буква А, но при мен така се получи, може и партидата да е била дефектна. По сходен начин се държат и PIC16F8xxA процесорите, някъде ги коментирахме преди време.

pirev
Дано наистина се шегуваш - не вярвам да има такива "дребни" своеволия тоя чип. Да не иска ресет чип (външен) или някакви екстри подобни?
Кондензатори навсякъде и т.н.

Не било бъг на процесора.
Сега добавих още код в програмата и като съхраних СТАТУС-а се сетих че проблема е че не съм си съхранил сатуса в въпросното прекъсване
Малко поработих на ИАР и придобих вреден навик, ИАР сам се грижи за съхраняването на контекста.

Кой компилатор използваш ?

Това беше на Hi-Tech,това съм го почнал миналата година че затова.
А напоследък гледам всичко да си го правя s IAR.
Има си го за всякакви процесори и има много глезотии. Особенно пълното му C++ си е голямо предимство;

@pirev
По сходен начин се държат и PIC16F8xxA процесорите.

В програмите си за тези процесори записваш ли в FLASH program memory, защото ако записваш, процесорите PIC16F8xxA и PIC16F8xx не са съвместими в тази си част.

User Writes to
FLASH
Write to FLASH program memory in 4-word blocks(с буква А), instead of
1-word blocks(без буква A)

Може да се погледне за инфо в DS39591A(и на други места)
PIC16F87X → PIC16F87XA Migration .

Не съм имал проблеми с FLASH на PIC16F8xxA( като се внимава с разликите).

Проблема с въпросните професори, не е когато от програмата си презаписвам програмната памет ( имах си аз да не знам, че се записва на блокове от 4 думи ), а когато ги записвам с програматор. Примерно вземам нов процесор, правят се няколко презаписа, пипна MCLR по време на работа и дотам, произволни блокове от програмната и паметта за данни отказват !

Баси - това е единствения пик, който ползвам в производство. Влагам го от както е излезнал и досега несъм имал никакви проблеми с него. Освен, че командата му за изтриване на програмната памет е различна от тази на версията без А .