AT89C2051 - porty w stanie wysokim po resecie, dioda LED nie miga

Po każdym resecie (zwieranie pinu RST do zasilania) procesor zachowuje sie tak samo, czyli na wszystkich portach są "1". Wg. manuala oznacza to że procesor jest ciągle w stanie resetu, a tak nie jest..

Zbudowałem prosty układ sterujący diodą LED z portu P1.2, reagujący na zero logiczne, w Keilu komendą SBIT ustawiam najpierw 1 na tym porcie, później jest opóźnienie, później 0, opóźnienie i tak w kółko, czyli chce żeby dioda mrugała.. programuję procesor w programatorze PROGAT, następnie montuję go w prostym układzie, gdzie jest tylko rezonator 10Mhz, dwa kondensatory 39pF podpięte do masy, tranzystor jako klucz w porcie P1.2 i na końcu dioda.. zwierając ręcznie baze tranzystora do masy dioda świeci, procesor natomiast nie chce tego robić..
Po resecie wszystkie porty automatycznie idą w stan 1..
Męcze sie już tym drugi dzień i nie wiem co robić, zmieniałem rezonator napierw na 6Mhz, później na 13Mhz, teraz mam 10Mhz, obudowe rezonatora uziemiłem, dodałem rezystor 100k podciągający pin RST do masy (polecenie z manuala) i ciągle nic..
Czy to świadczy o uszkodzeniu procesora?
Dodam, że nawet pusty procesor zachowuje sie tak samo, tzn. czyszcząc mu pamięć programem MikroLUK (same 0xFF) po wykonaniu RST dzieje sie tak samo...

Zmierz jakie napięcie masz na nóżce RST. U mnie, jak miał około 2,5 V to też ciągle był w resecie. Rezystor do masy daj 1k lub 2k. 100k to zdecydowanie za dużo.

Zastosowałem sie do rady, zmieniłem 100k na 1k.. dalej to samo
Napięcie na pinie RST po resecie wynosi 1.3mV...

Zaquadnik napisał:

Zmierz jakie napięcie masz na nóżce RST. U mnie, jak miał około 2,5 V to też ciągle był w resecie. Rezystor do masy daj 1k lub 2k. 100k to zdecydowanie za dużo.

Ja daje sam kondensator 220nF pomiedzy RST i Vcc. Zamiesc program, schemat i moze bede mogl Ci pomoc.
Tranzystor mozesz pominac, podlacz diode pod port i przez rezystor do Vcc.

Kod programu:

#include <REG52.H>
#include <absacc.h>


sbit PORT=P1^0;

main()
{
int x;
while(1)
{
PORT = 0;
for(x=0;x<1000;x++);
PORT = 1;
for(x=0;x<1000;x++);
}
}

A schemat "testera" mrugającego jest w załączniku..

No to napisz jeszcze prostrzy program, ktory po resecie na twojej lini ustawi zero, i sprawdz co sie wtedy bedzie działo.

Pisałem wyżej, że nawet zmieniając program (wpisując puste instrukcje), ciągle po resecie wszystkie porty przechodzą w stan 1, w związku z czym, mało prawdopodobne jest iż wina leży po stronie oprogramowania.
Obstawiam przy "dziwnym" uszkodzeniu procesora....

To nie uszkodzenie. One tak mają. Porty w 2051 po resecie przechodzą w
stan wysoki. To nie ATmega niestety. Trzeba programowo potem ustawiać stan
niski. No i trzeba to brać pod uwagę podczas projektowania układów bo coś
może się na chwilę załączać po resecie µC albo po włączeniu zasilania.
Prawdopodobnie masz coś nie tak z programem.

szod napisał:

...Prawdopodobnie masz coś nie tak z programem.

Lub rezonator nie pracuje i proc "stoi"
Jeśli masz woltomierz o rezystancji wejściowej >1Mohm/V , to sprawdź napięcie na pinach XTAL - powinno wynosić w przybliżeniu połowę napięcia zasilania

Piotrek

szod
Dzięki za uświadomienie nie miałem zielonego pojęcia że to tak ma być
zumek
hmm, sprawdziłem napięcia, układ zasilany jest 5V, więc na wyprowadzeniach rezonatora mam 2,23V i 2,45V ...czy pomimo tego, że są prawidłowe napięcia, rezonator może nie pracować ? jak to sprawdzić ?
bo jeśli to wyeliminuje, to wtedy będe miał pewność, że na 100% jest błąd w kodzie..
ale, to jak napisać poprawny kod? dokładnie taki sam program napisałem na labolatorium dla modułu AVT-2250 i tam port był sterowany tak jak powinien.. tworząc nowy projekt w Keil'u wybrałem odpowiedni procesor Atmela, jedyne czego nie jestem pewny, to w opcjach jest ustawiana wartość rezonatora, domyślnie jest na 24Mhz, czy musze te wartość zmieniać aby była taka sama jak w moim testowym układzie? ..a co z modelem pamięci? ..czy może lepiej wogóle nic tam nie ruszać, skoro wybrałem procesor, program sam wie jakie wartości pamięci i rezonatora ma sobie ustawić ?

A czy jesteś pewny że ten procek jest zaprogramowany ? Może się on nie programuje ?

Wrzuć taki oto program do procesora.
Pozdrawiam

moze wrzucic na reset 10uF do plusa i nie podpinac nic wiecej do resetu ( rezystor jest wewnetrzny w procku) , raz sie spotkalem ze bylo chyba 100n do plusa i nie bardzo chcialo wstawac ale po zmiane na wiekszy zaczelo chodzic.

GienekS
..na 100% pewien nie jestem, ale programując procesor jednym programem, ten sam kod odczytuję w drugim programie.. więc programować raczej programuje..
przemek20
mógłbyś przybliżyć co "robi" ten program? może kod w ASM lub lepiej w C?
zagwizdow
spróbuje dać sam kondensator, w module AVT-2250 też jest rzędu 10uF, o wynikach dam znać

Bardzo dziękuje wszystkim za zainteresowanie:!:
Czekam na odpowiedź od przemek20

Masz tu program który ustawia tylko cały port P1 na zero.
Sprawdz woltomierzem czy wszystkie linie P1 są zerami.
Jeśli nie będą , to wtedy szykaj w elektronice.

Mój kod w asm wygląda nastepująco:


Żeby uniknac problemów z jego kompilacją umiescilem plik .hex.
Podejrzewam ze autor tematu nie sprawdzil tego w tak elementarny sposób.
Widze ze olekewaagata ma identyczny pomysł.
Koniecznie daj opornik do masy. Bez opornika potrafią sie dziac niezłe cuda np reset przy zbliżeniu dłoni.

Sprawa wyjaśniona
przemek20 i olekewaagata, dziękuje za odpowiedzi, sukces! ..zaprogramowałem procesor plikami od Was i wszystko OK, same zera na porcie P0
Teraz mam 100% pewność że układ i progamator działają, więc wina leżała po stronie Keila.. tylko dlaczego? Zauważyłem, że podczas kompilacji z C do HEX, plik zajmuje około 90bajtów, jednak zarówno PROGAT jak i MikroLUK krzyczą, że "program przekracza wewnętrzy bufor mikrokontrolera", PROGAT się wyłącza, a MikroLUK przechodzi dalej.. zastanawiam sie dlaczego, hmm, obcina część kodu i przez to do procesora wgrywany jest niepełny kod?
Do znawców Keil uVision2, czy to normalne?
Zależy mi na programowaniu w C, więc jakie polecacie inne kompilatory C dla mikrokontrolerów oprócz Keil'a i SDCC:?:

Micek64 napisał:

... Zauważyłem, że podczas kompilacji z C do HEX, plik zajmuje około 90bajtów, jednak zarówno PROGAT jak i MikroLUK krzyczą, że "program przekracza wewnętrzy bufor mikrokontrolera", PROGAT się wyłącza, a MikroLUK przechodzi dalej.. zastanawiam sie dlaczego, hmm, obcina część kodu i przez to do procesora wgrywany jest niepełny kod?
Do znawców Keil uVision2, czy to normalne?...

Gdybyś od razu o tym napomknął , to byśmy się tu niepotrzebnie nie gimnastykowali
Masz kompilator w wersji DEMO(również nie pisnąłeś słówkiem) , a to oznacza , że kompilator generuje kod , który należy zapisać w przestrzeni programu zaczynającej się od bodajże 0x800 , o czym lojalnie poinformowały Cię "programatory"
Przestroga na przyszłość:
a)zanim użyjesz jakiegoś narzędzia , zajrzyj do jego instrukcji.
b)zanim napiszesz o nękających Cię problemach , przeczytaj "instrukcję obsługi" tego , czy też innego forum.

Tyle marudzenia i życzę powodzenia

Piotrek

PS
Dlaczego nie SDCC

Nie wiedziałem że ma to istotne znaczenie czy oprogramowanie to wersja demo czy nie, na labolatorium też używamy wersji demo i tam wszystko działało poprawnie.
Skoro już wyjaśniło się że to wersja demo (za co przepraszam że nie umieściłem adekwatnej infromacji wcześniej ) to jak "zmusić" kompilator do tego żeby mimo wszystko generował kod od przestrzeni 0x80h ? W opcjach kompilatora są rubryki na ręczne wstawienie początków adresu ale dla pamięci CODE i XDATA... próbowałem z obiema lecz mimo to kompilator dalej "robi swoje" ..
tzn. dziwne to jest, bo jak podglądam kod asemblera generowany przez kompilator, to tam przy początkowym adresie 0x00 jest instrukcja LJMP do adresu 0x80 i dopiero czyna się kod mojego programu.. w związku z czym wydaje sie że to jednak nie to, że kod programu nie jest umieszczany tam gdzie powinien..... Co z tym zrobić ?

PS. a dlaczego nie SDCC ? ... jakoś nie lubie porgramów "nie interfejsowych" ...no chyba że tu jest też coś o czym nie wiem.. ale ściągając SDCC pod Win dostałem tylko kilkadziesiąt plików EXE których używa sie jedynie w ścieżce poleceń... a taka zabawa troche jest mi nie na ręke...

Micek64 napisał:

.... Co z tym zrobić ?

Daruj sobie

Micek64 napisał:

PS. a dlaczego nie SDCC ? ... jakoś nie lubie porgramów "nie interfejsowych" ...no chyba że tu jest też coś o czym nie wiem.. ale ściągając SDCC pod Win dostałem tylko kilkadziesiąt plików EXE których używa sie jedynie w ścieżce poleceń... a taka zabawa troche jest mi nie na ręke...

Gwoli ścisłości , to kompilatory Keil-a działają też z linii poleceń , tylko że z kompilatorami dostajesz(?) IDE .
Jeśli zaś chodzi o SDCC , to od czego są sieciowi przyjaciele
Za darmochę masz IDE do SDCC , które nazywa się MIDE.Niestety , obsługuje tylko projekty jednoplikowe . Do tej pory używałem IDE firmy Ceibo(darmowe w domku , dla komercji płatne) , ale niedawno znalazłem coś free , które jak Ceibo potrafi kompilować projekty wieloplikowe , a nazywa się Code::Blocks.Sciągnij , poświęć godzinkę na zapoznanie się z nim i ... programisto do dzieła

Sciągnij Code::Blocks

Piotrek

Uparłem sie na tego Keila, załatwiłem sobie nawet PEŁNĄ wersje uVision3.. i wszystko pięknie działa, ale ładując HEX'a do programu MikroLUK (jak i PROGAT) DALEJ jest to samo... czyli wyskakuje piękne okienko z napisem "Dane w pliku xxxxx wychodzą po za obszar bufora wybranego układu" ...no ręce opadają
Już nie mam sił na to i kompletnie nie wiem dlaczego tak sie dzieje..
Pozostaje mi spróbować tych Ceibo lub Code::Blocks..

Pytanie do zumek: spotkałeś się kiedyś z tym, że HEX nie chce sie załadować? tzn. z postu powyżej wynika że tak, ale Twoim rozwiązaniem było zmiana oprogramowania lub wersji programu na pełną.. a co zrobić jeśli dalej to nie działa.. chciałbym to jakoś rozwiązać, bo zmienić program to tylko "zatuszować" problem...

Wrzuć tego HEX-a na forum , to zobaczymy co to z cudak

Piotrek

Proszę bardzo
Oto kod w C:

#include <REG2051.H>
#include <stdio.h>

void main (void)
{
int x;
P1_0 = 1;
P1_3 = 0;
while(1)
{
for(x=0;x<1000;x++);
P1_1 = 1;
for(x=0;x<1000;x++);
P1_1 = 0;
}
}

..a w załączniku plik HEX (zmieniłem rozszerzenie bo nie mogłem załączyć gołego HEX'a)

Micek64 napisał:

Proszę bardzo
Oto kod w C:...

Jest tak jak pisałem , czyli kod programu (poza wektorem RESET) zaczyna się od adresu 0x800.A tak na marginesie - naucz się "czytać" pliki HEX , albo sprawdź w debbugerze , w oknie Disassembly

Micek64 napisał:

Uparłem sie na tego Keila, załatwiłem sobie nawet PEŁNĄ wersje uVision3..

Koło PEŁNEJ , to chyba nawet nie leżała

Piotrek

PS
W załączniku Twój kod , a mój Keil

Pokłony dla Kolegi zumek
Masz racje, to była pełna wersja ale tylko teoretycznie, bo praktycznie to było skrakowane demo
Ściągnąłem sobie CEIBO, zainstalowałem, napisałem kod sterujący portami i WSZYSTKO jest OK

Jeszcze raz bardzo dziękuje wszystkim za pomoc
Temat uważam za zamknięty
Pozdrawiam