ex-man възможните ти пропуски според мен са:

MOVLW 0X07 ;IZkliochwane na komparatora i
MOVWF CMCON ;pozwoliawa I/O MODE NA PORTA


Виж си и банките.

Ако ползваш Протон
ALL_DIGITAL = True

И не ти пука за банките.

Не му е това проблема, защото ако не беше изключил компараторите нямаше да му работят инструкциите ВИНАГИ, а не "Ако го откача от схемата - няма проблеми... ". Ама никой ли не чете дейташийтове?
На проба-грешка ли го карате само? Хора, как пресичате улиците тогава?
Нищо ли не ви говори Read Performing Write? Ама защо ли питам!

П.П.
Двама.

Сега разбирам че има термин Read Performing Writе
В кой дейташийт е описан че нещо в мойте го няма.

П.П.
Не съм имал грижи нито с този пик нито с другите.
Да не почнат проблемите като се отворя на тази RPW далавера?

Ами няма кой да ги чете явно, щото там пише че проблем може да има при последователни bcf/bsf инструкции на един и същи порт и различни пинове. Айде сега ми кажи как единствена инструкция bcf ще сгафи по този начин? Или още по-зле - movwf portx??? Между другото термина е Read-Modify-Write ша знайш... (пише го там дет' си "чел"... ).

EDIT:
Eй тъй за обмяна опит питам - вий във вашта фирма на стограмки ли ги "четете" документациите или на халби?

Добре де, без да се дразните, като съм ги чел тези неща, съм разбрал, че може да има проблем само при четене, ако преди това съм разклатил някой пин, т.е. това ще влияе на входовете, ама на изходите как ще влияе ? Нали изходите се вземат от latch регистъра, той как ще се промени ? Или и не съм чел както трябва Досега не съм имал проблем, ако нещо се усъмня, чета целия порт и после andwf и iorwf.

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

аааа, ами така кажи бе човек
пика не е виновен да ти кажа...
като четеш, четеш това което е на крачето. ако на крачето има кондензатор, след превключване на пина няма да прочетеш това което си му задал веднага, а чак след известно време. ако пък си го праснал към захранване през малък резистор, няма да прочетеш нивгаш вярна стойност. но изхода на пика си е записан - отпушен е правилния транзистор и води неравна борба със външния товар. ако откачиш товара, крачето ще заеме вярна стойност, без да го презаписваш наново. за това в някои пикове има лачове - те пазят какво си записал и можеш да четеш от тях.

Не е там работата според мене.
С това краче управлявах ресета на друга схема. Имаше резистор 10к към 5V ако не се лъжа. Толкоз. Не съм го чел, само пиша. R-M-W процедурата може да навреди примерно ако сетнеш два пина последователно, и отвън има тежък товар. Сетваш първия, той започва да се сетва (демек полегато се запътва към VCC), сетваш втория, и тъй като процедурата е R-M-W, първо се чете целия порт (четат се изводите! не latch регистрите), а първия пин все още е достатъчно ниско, се въприема като 0. В края на операцията се оказва че въпросния пин е нулиран, щото latch регистъра му е записан с 0 при втората bsf инструкция...
Ама аз сетвам пин-а и... нищо. Най-интересно е защо се бъгва като го сетна с movwf...

Както и да е...

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

ша зная, колега, аз и до сега си знаех, че не е хубаво да изтъкваш гафовете си по причина на личното си невежество, като поучителен опит! Ако гафовете бяха признак за знания, щяхме да се обръщаме към вас с "господин Професоре!". И е малко смешно, да съветваш тоя или оня да не ползва даден процесор, само защото ТИ не си успял да го подкараш. Както често обичам да казвам, проблема е в задклавиатурното устройство, ша знайш!

Ей тъй за обмяната на опит да ти кажа, мъжете това дето се пие с халби, не го пият на стограмки! Но ти няма от къде да знаеш, нали?

Явно никой не може да се мери с теб и твоите гафове, затова просто приключвам да споря.

Не, не е така колега! Прав си - разгорещих се повече от колкото е полезно, приеми искрените ми извинения, не беше целта ми да те обидя (макар че като си прочета постовете, май това се е получило), подразни ме това, което си помислих, че е обобщение от сорта "аз имах проблеми с това нещо=това нещо е много бъгаво". Peace!

Колкото за проблема с порта, случвало ми се е подобно нещо, с друг пик и разбира се, проблема беше в това, че ниската и средна серия на майкрочип всъщност не пише директно в изходния регистър, а първо прочита състоянието на пиновете. От известна гледна точка това си е бъг и то голям! Но явно се дължи на архитектурата на порта, тъй като в 18-та серия заради това са добавили LATH регистрите, заобикаляйки по този начин тази "особеност" на портовете. В моя случай се оказа, че имам известен капацитет на пиновете, които трябваше да се превключват асинхронно и доста чевръсто. Като взех мерки да намаля капацитета - всичко си легна на мястото. За всеки случай си направих софтуерен LATH на този порт и стана съвсем здраво. Губи се обаче за всяка операция с порта още една-две инструкции и разбира се една клетка РАМ. От тогава за по-критични места - винаги го правя по този начин и никога не ми се е получавал този "ефект". Пишеш, че с този пин си ресетвал друга схема. Не е ли възможно да си имал капацитет за POR (ресетване при включване на захранването)? Или както беше написал някой по-горе да си го понатоварил този порт, тъй като изходите на пиковете имат изходен ток 25mA и ако е бил без тригер на Шмидт този вход, може и да е "клекнал", което е предизвикало грашното му прочитане. Не е и невъзможно да е имало и нещо софтуерно, например прекъсване някое да ти го "пипа" порта. Това може да се провери като направиш навсякъде, където имаш обръщане към порта да сменяш състоянието (примерно) на друг пин (от друг порт!) и с осцилографа веднага ще видиш.
Въпреки мнението на много колеги в този форум, процесорите на майкрочип се държат достатъчно стабилно дори и в силно електромагнитно зашумена среда и за ценовия си клас са най-доброто. В повечето случаи това, което наричаме "бъгове" са си грешки на проектиращия, като например лошо опроводяване, софтуерна грешка и т.н. Би било добре всички ние да се опитаме да сме по-обективни, т.к. преполагам никой не би искал само за това, че някой не е успял да подкара устройство проектирано от него, да почне да приказва, че от него нищо не става и въобще е голям боклук!

@mash
628 наистина е бъгав ,даже попаднах на една поредица в QFN корпус (трябваше да запомня ревизията)
която умираше след 1,2 програмирания.
872 имам окол 20 излишни - за експерименти са идеални

Извиненията са приети .
Както винаги истината е някъде по средата. Поради тази причина, за да бъда честен, ще кажа че си погледнах преди малко кода и видях следната тъпотия



която очевидно е аналогична на bsf (имаше и друга тъпотия, аналогична на bcf ) която явно съм написал в пристъп на умствено затъмнение, причинено от желанието час по-скоро да подкарам нещото, плюс факта че за първи път ми се налага да се боря с този така добре документиран бъг .

Иначе проца си има подобаващо дълга ерата... така че по принцип с е бъгав