Ами ето за какво става дума.
PIC16F84A - програмира се , проверка се прави (ICPROG & JDM2 programer) , всичко точно.
Слагам го аз на схемичката. Пускам му 5в където трябва, 4мхз кварц както си трябва. Меря има ги , обаче
на 18 крак , където трябва да има сигнал не само според мен , но и според PROTEUS; няма абсолютно нищо.

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

Схемата не е нищо особено.

5 - GND , 14 - +5V , 15:16 - кварц с два кондензатора, както си му е реда и на 18 следя.

програмта е тази -> http://www.mcu-bg.com/mcu_site/viewtopic.php?t=955

И се чудя възможно ли е част;/някой модул/ от ПИК-а да не работи , примерно ALU-то, или PC-то или знам ли аз, а да може да се програмира.?

Въпроса може и да е смешен, но си нямам идея

На последния ти въпрос - не. На останалите - чак се чудя. Темата ти стана по разхвърляна от кода.

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

Да естествено , че това е решение, но въпроса относно частичното 'изгаряне' на пика ми се виждаше добра причина за това, което става , ако беше възможно такова нещо

И въпреки това не ти ли се вижда нелогично
на proteus дава сигнал , същия хекс/кекс отива на pic-a и нъц.
Ей сега ще пробвам все пак това горното.

ЕДИТ:

Става ми все по-весело и по-весело.
Има на 18 крак сигнал като просто пусна 0xFF на PORTA ...

Сега обаче отивам да се чудя защо с програмта ми,която ми трябва на PROTEUS-a вади сигнал през интервал както го искам , а на схемата кьорав сигнал не вади.

Хищика е прав,пробвай нещо съвсем елементарно от сорта


BANK0

clrf TRISA // be outputs

label clrf PORTA ;set all to low
nop
mowlf 0xff
movwf PORTA ;set all to high
nop
goto label
И бодни осцилоскопа или честотомера нейде да видиш какво става.

! виж дали случайно не си забравил конфигурирането на осцилатора на RC
по мои наблюдения осцилациите са най стабилни при HS въпреки ,че за <=4Mhz препоръчват XT
!+5v на MCLR? (много често ми се случва)

А колкото до въпроса за частично работещ чип имам следните случки:
Пробил към 0 пин C3 (след 25 волта подадени по погрешка)но чипа работи 16F877A
Смарт карта със 16F84A флаша се чете и пише коректно но като CPU не работи (фабрично)

всъщност това доло май напълно достатъчно

clrf TRISA
incf PORTA,f
goto $-1

Хоуп то хелп рийш ли

Хех тъкмо написах какво стана - горе виж предния пост -> едит; и ти се разписа

Ами на MCLR - ресета нямам нищо, не го ползвам напърво време просто защото преди да почна да правя нещо искам да си направя RS232 порт софтуерно* за PIC16F84/т.е такива , който нямат/.

На HS го ползвах в началото, после реших , че XT както казват хората

*За Хищника- чрез използване на TMR0INT

edit:

И написаното от теб Димитър (бай дъ уей сме адаши ) означава , че може PIC частично да е повреден.
И въпреки казаното от Хищника ще си позволя да изкажа следната теория - повреден/изгорял/както искате го наречете TMR0/таймер0 имам

едит2: и ей сега ще го пробвам като вместо wait цикъл ползвам TMR0 int за отчитане на ~1sec.

Извинявай ама какво значи "Ами на MCLR - ресета нямам нищо, не го ползвам напърво време ..."
То без 5v там никога и нищо няма да тръгне

Хах....гарантирам ти че не можеш да изгориш TMR0 а останалата част от контролера да е здрава....иска се доста ентусиазъм за това...Стига си се пънал с твоята каша, дадох ти RS232.inc, само добавяш името му в хедъра на програмата и продължаваш напред . Само си губиш времето.
PS: И наистина много тъпо звучи "MCLR не го ползвам"!!! Закачи го на +5V!

"То без 5v там никога и нищо няма да тръгне "

Чакайте бе .. нали MCLR е 4 крак - т.е РЕСЕТ-а ...
PIC-а почва да работи , в момента , в койт му се подадът 5в.
така че какво му е тъпото , все едно да не си ползвате ресета на ПЦ-то в началотo < така де ... вкл. и го изкл. от poweron бутона.

---
друго
пак подобна история:

простата програма ,която пуска 1-ци на PORTA работи

с ТМР0 вече отказа и нищо.
прикрепил съм я и бтв пак на PROTEUSA работи както очаквам.
на ~2s си сменя състоянието PORTA (целия).

ps: Хищник , да прати ми го ,но ти казах искам TMR0 int < за да мога да правя _НЕЩО_ следа контактор примерно , докато пращам , а не докато пращам или приемам нищо друго да не мога да правя.

Чакайте бе .. нали MCLR е 4 крак - т.е РЕСЕТ-а ...
PIC-а почва да работи , в момента , в койт му се подадът 5в.
така че какво му е тъпото , все едно да не си ползвате ресета на ПЦ-то в началотo < така де ... вкл. и го изкл. от poweron бутона.

Мухахахахах ....... ти направо "изби рибата" с тоя коментар ве човек

Значи ... слушаи сега :

Ако не си вържеш MCLR към Vcc и БОГ неможе да ти помогне да си стартираш програмката ... тва не ти е PC а PIC !
PC /program counter/ ще продължава да се връшта не адрес 0х0000 (Reset vector) до тогава до когато не деактивираш MCLR (разбираи го вързан към Vcc) !!!!!!!

Значи .. предполагам че нищо ти няма на професора .... и всичко се дължи на гореспоменатото ....
това че тръгва с Протеус не означава че ще тръгне наистина .... ако си забелязъл в Протеус може да не свържеш кварц към MCU'то и пак да тръгне ... а ма я го пробваи тва в реалния живот ... същото се отнася и за MCLR ...

Аре успех

относно:
ps: Хищник , да прати ми го ,но ти казах искам TMR0 int < за да мога да правя _НЕЩО_ следа контактор примерно , докато пращам , а не докато пращам или приемам нищо друго да не мога да правя.
-------------------------------------------------------------------

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

Имал съм подобни сътресения със един мой протокол при който симулирам RS точно със твоя пик само ,че в смарт карта и кадъра беше дълъг 40 бита
и там имам паузи реализирани с двайсетина NOP-ове които варират с точност до 1 инструкция!
Един повече или по малко и комуникацията се нарушава .
Както и да е ако ти е много важно да е точно с този пик мога да ти драсна нещо в работно време

пс
Наистина ти е малко разхвърлян кода ако искаш мога да ти пратя едни библиотечки от макроси които съм писал от 'Асемблерния ми период' които правят кода доста прегледен и лесен за редакции

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

Относно TMR0INT и идеята ми скоро ще я направя като хората, най-малкото ще напиша просто в чист текст какво искам да се получи и после ще говорим.

Относно MCLR - значи аз не съм разбрал, за какво служи. Хъх ... иде ми да се скрия от срам .

И да най-вероянто това е проблема , естествено

Благодаря на всички за отделеното време !

90% от проблемите при един процесор/контролер са свързани с кварца и ресета. Естествено, че трябва да вържеш ресета към плюс - и не само да го свържеш, ами по точно определен начин да го направиш. Факта, че не си вързал ресета никъде ми подсказва, че сега започваш и си още лаик в тая област - и ако е така позапознай се първо с основните неща и по-елементарни програмки - един софтуерен UART ще е като висш пилотаж за теб . И при положение, че имаш проблеми с елементарните неща - идея си нямаш тоя софтуерен UART поради колко други причини може да не работи или да си работи горе-долу. Контролерите (процесорите) не са само софтуер и факта, че работи в протеус или друг симулатор, въобще не ти дава 100% гаранция, че и върху чипа трябва да работи. И помни един от най-важните принципи - контролера прави това, което си му казал и го прави така, както си му казал. Т.е. ако не прави това, което очакваш ти - си виновен само ТИ.

Малко ме е яд за лотото първо впечатление, но времето ще покаже

1. PIC Микроконтролери @ МладКонструктор 2003 съм я прочел почти с кориците - 99%
2. Случва се човек да се обърка , просто съм се заблудил , че с вкл. на напрежението микроконтролера получава НУ и тръгва работата. MCLR го приехмах точно като ресет, пък и схемите си пише MCLR/РЕСЕТ - не помагат , само залъгват "гадовете"
3. Относно SOFTWARE USART-a: Грешиш - твърдо го заявявам .! Няма да ми се опре , да ще има няколко неща проблеми най-веч епоради това, че не съм програмирал на ASM и лично според мен неточни определения в книгата по-горе / та много често си се консултирам с Datasheets на MPLAB & PIC16F84A. та така.

Хардуерни USART , който го има примерно в 16F628А не ми харесва, защото точно по-средата на PORTB са го забили , което е просто гениялано в ". Това си е мое мнение.

и едно offtopic: лично аз нямам проблем,но все пак трбява да отбележа , че има разлика между newbie и lamer.



С една дума , някой който си мисли , че е нещо , което не е и постоянно се опитва да се искара пред другите това "нещо". Има разлика. Надявам се ме разбра.

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

ТоНи е прав. Аз сам ползвал софтуерен на 84-ка до 38400, ама ми се е*а бойната слава
То зависи и от приложението де.
А за дефектните чипове - имам 2 броя samples от Майкричип - 18Ф1320 на който еепрома му се записва "понякога", без значение дали програмно или с ICD2 или с Picstart+ и един 18Ф4320, дето програматорите казват, че няма кво да програмират, щото няма вързан чип към тях - т.е. въобще няма признаци на живот. И двата са чисто нови.