PIC 16F627A wrażenia i pytanie dotycząc

Radek napisał(a): planowałem przełączyć

Co toznaczy "mocniejszy rezystor"? Podciągasz MCLR do +5V przez 10k na przykład i po krzyku. Jeśli wykorzystasz to jako wejście, to nie może ono wymusić stanu niskiego podczas programowania. Zdodnie z aplikacją ICD.

nie, problemów nie ma. Dostałeś jakiegoś warninga, ale na pewno nie takiego że nie można mieć tego pinu jako wejście, bo to nie ma nic wspólnego z INTOSC

jak zrobisz wejście zamiast mclr to resetu nie potrzeba bo niby reset czego? :-) . A jeśli chcesz mieć reset to najprostszy to dwa oporniki i kondensator

spoko, nie popalisz

więc po rlf zrób bcf status,c , a jeśli C potrzebujesz później do czegoś to go przechowaj

no czasem się przydaje ale nie czesto

pzdr.

szlovak napisał(a):

A skąd to wiesz? Moze mieć jakąś zależność sprzętową lub błąd sprzętowy z którego ona wynika. Błędów w procesorkach nie brakuje i nie brakuje ich w samym Mplabie. Warningi trzeba czytać i zastanawiać się z czego wynikają, to dobry zwyczaj.

W ten sposób nie, ale bardzo łatwo załatwić procesor programatorem ICD, jeśli się do tego bezmyślnie zabrać. I potem taki procesor może "działywać", gubić dane, przekłamywać licznik rozkazów...

A.Grodecki napisał(a):

OK - doszedłem z czego wynikał problem i dlaczego czasami się pojawiał a czasami nie (kłopot z reprogramowaniem).

Tekst warninga: "ICDWarn0033: MPLAB ICD 2 does not support programming this device if both the internal oscillator and internal MCLR are selected. You may continue programming, but you are encouraged to cancel, reconfigure your device, and try again."

Po dalszej lekturze - chodzi o to, że 12V nie jest odrazu podłączone do pinu z MCLR/VPP. Przez chwilę procesor będzie wykonywał normalny kod i może zapisać coś do pinów clock i data co może zablokować możliwość komunikacji z programatorem.

Związek z użyciem wewnętrznego oscylatora jest taki, że używając zewnętrznego ma się gwarancję, że cpu nie wykona żadnej instrukcji przed pojawieniem się 12V na Vpp więc nie ma możliwości zablokowania pinów PGD/PGC.

W sumie to logiczne choć upierdliwe - można więc zaprogramować układ tak aby działał z wewnętrznym MCLR i oscylatorem ale mogą się pojawić kłopoty z ponownym programowaniem. Całe szczęście dało się odblokować po którejś próbie z kolei te 3 kości jakie zapaćkałem w ten sposób.

Mój dylemat polega na tym, że MCLR trzeba podciągnąć do Vdd i teraz jak to zrobić aby nie było jakiś cyrków przy programowaniu w układzie po podłączenia napięcia 12V do tego pinu. Rozumiem, że zwykły rezystor 10k w zupełności wystarczy i nie będzie żadnych kłopotów z programowaniem "ISP". Dotychczas robiłem to przy użyciu odpowiedniego adaptora i gniazdka ale ciągłe wyjmowanie/wsadzanie scalaków robi się już nudne. :)

Pozdrawiam,

Radek

To jest shift logiczny a ja chcę 8 bitowy "barrel shifter". :) Więc trzeba najpierw bcf C/btfsc (skrajny bit)/bsf C i dopiero rlf/rrf.

4 instrukcję zamiast 1... :))

Mi się już swapf przydał bo zredukował 4 x rrf + movlw/andwf właśnie do

1 x swapf. :)

Pozdrawiam,

Radek

Ciągle plus movlw/andwf ale i tak to zysk. :)

Pozdrawiam,

Radek

Na pewno nie w tak prostych procesorach. Co innego dsPIC, troche błędów niektóre mają.

Jak niby można załatwić procesor programatorem? Chyba że źle działającym, oprócz niektórych procesorów z literą J których nie można programowac bez kasowania to nie wiem o co Tobie chodzi. Nigdy nie miałem żadnych problemów ze wszystkimi procesorami tj. pic10f200,

12f508, 16f84a, 16f628, 16f877, 16f877a, 16f872. A jak były komplikacje to jak zwykle przez moje niedopatrzenia.

łatwo można załatwić programatorem Atmele, z tym się moge zgodzić

Radek napisał(a):

Ja nie rozumiem dlaczego niby tak by miało być. Normalne jest, że dane i zegar ICD sa uzywane do innych funkcji niż tylko programowanie. I po pojawieniu sie podwyższonego napięcia na MCLR te piny są zwalniane dla ICD. Mozliwe że po prostu w tym konkretnym scalaku coś jest skopane w strukturze i stąd ostrzeżenie. MOze bierze się to stąd, że wcześniejsze wersje tych układów nie miały możliwości współpracy z ICD i implementacja funkcji jest mnoieco inna niż w układach które miały ICD od początku.

A dlaczego miałby być jakikolwiek "cyrk". Ile prądu popłynie przez 10k?

0.7mA niec nie zmieni w zasilanu układu na linii 5V. A że trzeba pamiętać, aby odpowiednio używać linii ICD w przcującym układzie... no trudno - coś za coś.

To może zacytuje z dokumentacji MPLABa:

"ICDWarn0033: You have selected Internal MCLR and Internal Oscillator in your configuration settings. If your code makes use of port pins that correspond to Clock and Data pins in programming mode, you may not be able to reprogram your device. See on-line help for this warning for more information. (OK/Cancel)

When Internal MCLR is used with MPLAB ICD 2 for programming, both Vpp and Vdd are powered together, and then Vpp is pulled high to Vihh to enter programming mode. This means that your code will be running before Vpp goes to Vihh. If that code makes use of port pins that correspond to Clock and Data pins in programming mode, there is a chance their values may not be 0, as necessary to enter programming mode. Therefore, the device could not be reprogrammed."

Feature, bug a może coś jeszcze?

Biorąc jednak pod uwagę to, że daje się odblokować scalak po kilku próbach i zaprogramować "normalnie" imho jest to problem w oprogramowaniu MPLABa (i innym). Po prostu 16F627A wymaga nieco innej procedury przy tym, może poprawią to kolejnej wersji?

Też tak sądziłem ale wolałem się zapytać. :) (bo doświadczeniach jakie opisałem okazało się, że bardzo drobne szczegóły mają jednak znaczenie)

Pozdrawiam,

Radek

szlovak napisał(a):

Błędów w procesorkach nie brakuje i

Na pewno co? Erraty jakieś czytałeś?

No właśnie o tym mówię - niedopatrzeniach. Np chwilowy brak kontaktu na złączu icd przy programowaniu z zasilaniem przez icd. Albo jakiś upływ do sieci przez niskiej jakości zasilacz impulsowy, albo impuls po petli masy przez programator... Wiele przyczyn których zabezpieczenia struktury nie wytrzymają. Załatwiłem kilka PIC-ów w swoim życiu i wszystkie podczas programowania. A używałem wyłącznie Picstarta, ICD i ICD2, których mam 2 sztuki. ICD2 też zresztą można rozwalić przy odrobinie pecha, programując w warunkach bojowych

Radek napisał(a):

...

To wydaje się potwierdzać moją teorię.

I prosty jest na to sposób - trzymać piny jakiś czas w bezpiecznym stanie po resecie.

Bardzo wiele jest układów które nmają nieco inny tryb programowania przez co ICD2 musi przeładować sobie soft. Dlatego mam 2, żeby nie robić tego zbyt często (używam bardzo różnych procesorów, nawet w jednym projekcie).

Święte słowa.

Jeśli nie grodzi złapaniem zakłóceń, możesz na ten pin dać większy opornik niż 10k, np 47k. Zobacz w specyfikacji jaki jest prąd polaryzacji tego wejścia.

Radek napisal:

IMHO jest to faktycznie blad w oprogramowaniu programatora. Uzywalem

16f627 skonfigurowanego na wewnetrzny oscylator i wejscie na lini MCLR z "samorobnym" programatorkiem (bufor na ls244 AFAIR) i programem "picprog" pod linuksa. Program przy kazdym starcie testowal czy hardware jest podlaczone i jesli tak skonfigurowany procesor byl w zlaczu stwierdzal ze programotor jest niepodlaczony lub zepsuty. Wystarczalo przeczekac testowanie i wetkac proc pozniej. Przypuszczlnie ICD jest zbyt "inteligentne" i niepotrzebnie przejmuje sie tym co proc wyrabia pomimo uaktywnienie MCLR :) GRG

dokładnie, errate któregoś dsPICa

Miałem na myśli niedopatrzenia które powodowały inny błąd, a nie uszkodzenie procesora.

No to jesteś pechowy, ja używałem JDM z zasilaniem własnym i ICD2 i tych cykli programowania było bardzo dużo i nadal wszystko działa. Jedyne co mi się zjarało to włożona na odwrót pamięć 24c64.

szlovak napisał(a):

Nie tylko dspise mają erraty, wszystkie inne też.

Ja tego nie postrzegam jako pech. Klips ma prawo nie zakontaktować na układzie SOIC na przykład, albo na złączy krawedziowym, co innego jeśli jest złącze szpilkowe. Raz na kilkaset operacji coś się ma prawo zdarzyć, szczególnie jeśli często chodzi o prototypowe konstrukcje zamontowane w środowisku przemysłowym.

Przesuwanie bez Carry robi się w 2 cyklach a nie w 4 ;)

rlf ZMIENNA, W rlf ZMIENNA, F

sword

W starszych wersjach ICD2 ubijały się nagminnie bufory wyjściowe, naprawiałem tego na kilogramy. Nawet nie trzeba się było zbytnio starać ;)

Pozdrawiam, sword

Wątek przeczytałem i widzę, że nie do końca łapiecie dlaczego tak się dzieje. Ostrzeżenia MPLABa są jak najbardziej poprawne i nie ma to związku z bugami w krzemie. Wszystko rozchodzi się o warunki wejścia w tryb programowania.

Wystawienie na MCLR napięcia Vpp wcale nie wystarcza do wejścia w ten tryb, dodatkowym warunkiem jest utrzymywanie portów DATA i CLOCK w stanie "0".

Jeśli procesor pracuje na wewnętrznym oscylatorze i ma dodatkowo wyłączony zewnętrzny MCLR to programator nie jest w stanie zatrzymać procesora. Poprawny sygnał powinien być ("H") -> "0" -> Vpp Przy powyższym układzie sygnał "0" nie dotrze do układu resetu bo jest odciety, a będzie to tylko "H" -> Vpp. Jeśli w tym czasie procesor generuje jakieś sygnały na DATA i CLOCK i w danym momencie pojawi się tam jakaś "1" to wystawienie sygnały Vpp nic nie daje i procesor nie wchodzi w tryb programowania.

Procesor w takim stanie wcale się nie zatrzaskuje tylko wymaga poprawnego wystawienia sygnałów. Najprostszym rozwiązaniem w tej sytuacji jest podanie napięcia tylko podczas programowania. Procesor nie zdąży wtedy wystartować i bez problemów wejdzie w tryb programowania.

Dodatkowym warunkiem na wejście w tryb programowania jest wystawienie stromego zbocza "0" -> Vpp na MCLR z tych samych powodów - aby procesor przechodząc przez poziom "H" nie zdążył wystartować. Szczególnie ważne jest to przy oscylatorach RC, które bardzo szybko startują w porównaniu do kwarcu.

No i ostatnia rzecz związana z powyższym, jeśli na MCLR "wisi" jakieś RC do opóźniania startu trzeba zastosować diodę separującą, żeby kondensator nie "zepsuł" tego zbocza. Alternatywnie zamiast diody można zastosować układ rezystorowy opisany w pdfie o ICSP.

Samą sekwencją programującą nie da się ubić procesora jeśli nie wystąpiły jakieś niezależne czynniki zewnętrzne.

Pozdrawiam, sword

Sprytne a ja jak zwykle przekombinowałem... ;)

Pozdrawiam,

Radek

Adam Jurkiewicz napisał(a):

Dzięki za informację, nigdzie tego nie doczytałem, że w tym samym momencie muszą być zera. Podejrzewałem coś takiego, ale tylko tyle.