[Solved] Program na AT89S52 nie działa na AT89C2051

Witam!

Posiadam tablice LED, które wygrzebałem z... no nie ważne. Ważne, że nic o tym układzie nie wiem, zgranie programu się udało, ale odczytanie jak to działało, nie jest warte zachodu .

Long story short: siedzą tam dwa typy procków: AT89S51 oraz AT89C2051 oba są podłączone w taki sposób, że „na świat” wystawiony jest tylko jeden pin oraz kwarc 12M. Zatem stworzyłem sobie program, w którym jest funkcja delay50ns() oparta na nop'ach (czas 50ns skalibrowany za pomocą arduino). Program czeka, aż na pinie wejściowym pojawi się 1, czeka 50 ns i sprawdza czy dalej jest jeden czy zero. Krótki sygnał to bit 0, długi 1. W ten sposób przesyłanych jest 5 * 8 bitów. Pierwszy bajt to „identyfikator” panelu, reszta instrukcja.

Program wgrany na S51 przez ISP działa. Natomiast na 2051, równolegle - nie. Oba się uruchamiają (mrugnięcie po uruchomieniu), pierwszy odbiera instrukcje, drugi nie.

Program na AT2051:


Program na AT89S51:


Program na Arduino (wysyłający instrukcje):


Dodam tylko, że 2051 musiałem zdemontować dwa razy (błąd we wgranym programie =/) więc trochę tej temperatury przyjął. Czy to może być przyczyną?

Pozdrawiam!

A dlaczego dla AT89C2051 wykorzystujesz #include <mcs51reg.h> ?

Zastanawiałem się nad tym, ale po prostu znalazłem przykład, w którym tak to było rozwiązane. Wyżej deklaracja właściwego procesora.
Zajrzałem do tego pliku nagłówkowego, ale się specjalnie nie przyglądałem.
Przeszło mi przez myśl, że te procesory są prawie identyczne, więc adresy (kompatybilne przecież z 8051) powinny być takie same, ale nie skupiłem się na tym i przyjąłem jak jest.
Czy stąd wynika problem?

Dodano po 8 [godziny] 16 [minuty]:

Moja znajomość tematu tego typu układów jest dosyć mała, ale jak teraz przyglądam się tym nagłówkom, to:

https://github.com/darconeous/sdcc/blob/master/device/include/mcs51/at89x52.h


https://github.com/darconeous/sdcc/blob/master/device/include/mcs51/mcs51reg.h


Chyba to wygląda tak samo.
Kompiluję sdcc na linuksie.

Nie zauważyłem wcześniej, że poprawnie użyłeś
#define MICROCONTROLLER_AT89CX051 i dlatego moje pytanie się pojawiło.
Musiałbyś sprawdzić czy podczas wylutowywania procesora nie uszkodziłeś któregoś portu.

Czyli stawiamy raczej na uszkodzenie układu? Ale to by oznaczało, że właśnie P3_0 uległ uszkodzeniu... Tylko on jest używany poza P1, który działa, bo mruga.

W takim razie kupię nowy AT89C2051 i kwarc, i spróbuję „in vitro” zbadać działanie układów

Przy okazji czy działanie tych dwóch układów i w ogóle układów z serii 51/52 [pomijając dodatkowe układy jak te porty dwa porty, komparatory itp.] mogą się czymkolwiek różnić? Chodzi mi o to, że jak kalibrowałem funkcję delay 50us (jak bardzo to jest godne zaufania?) dla S52 na kwarcu 12M to czy to nadal będzie 50 us dla 2051 na kwarcu 12M. Generalnie jak dobrze rozumiem opisy rodziny, to jest to praktycznie to samo.

Gloomwing wrote:

Oba się uruchamiają (mrugnięcie po uruchomieniu), pierwszy odbiera instrukcje, drugi nie.

Jak są różne to maja prawo działać w sposób odmienny. Co mi wyrzuca program diff

Może tu jest przyczyna?

Gloomwing wrote:

mogą się czymkolwiek różnić?

Jasne, czasem literka na końcu może zmienić niektóre rzeczy w sposób zasadniczy. Czasem nawet te same oznaczenia ale inny producent, chociaż przeważnie każdy dodaje tam swoje literki.
.

trol.six wrote:

Gloomwing wrote:

mogą się czymkolwiek różnić?

Jasne, czasem literka na końcu może zmienić niektóre rzeczy w sposób zasadniczy. Czasem nawet te same oznaczenia ale inny producent, chociaż przeważnie każdy dodaje tam swoje literki.
.

8051 to nie AVR czy tym bardziej ARM. W samym CPU od strony języka maszynowego, nie ma różnic. Pomiędzy różnymi uC różnice są w wielkości pamięci FLASH, RAM i peryferii. Porównanie not AT89S52 i AT89C2051 wyjaśni wszelkie wątpliwości, z najważniejszych (poza RAM i FLASH) z punktu widzenia programu to timer T2 w 89S52. Z nieistotnej z tego punktu widzenia tego przypadku różnicy jest możliwość programowania 89S5x przez SPI. Czy 89S5x może ma SPI tylko do programowania czy może też działać w roli mastera/slave nie pamiętam. Nie używam 8051 od ok 10 lat więc ciężko z pamięci coś więcej napisać zwłaszcza o 89S5x bo "karierę" z 8051 zakończyłem na 89C5x.

W wielkim skrócie, program z 89C2051, o ile nie używa komparatora, zadziała na 89S5x. W drugą stronę niekoniecznie ale programy, które widzę działać powinny, tylko nie wiem czemu są różne? Pewnie ta różnica robi problem.

trol.six wrote:

Może tu jest przyczyna?

Przepraszam, zapomniałem napomknąć: 2051 ma podpięty „na świat” inny pin - stąd różnica P3_0 i P3_1.
Adres, to numer urządzenia - docelowo chcę zrobić tak, żeby wszystkie były sterowane jednym przewodem (bardziej cel dla zabawy niż faktyczna potrzeba), stąd pierwszy wysyłany bajt jest adresem. Urządzenie na S52 otrzymało numer 2 i dla tego reaguje gdy na arduino wgrany jest program "b[0] = 2;", natomiast 2051 powinien reagować gdy "b[0] = 3;".

LChucki wrote:

W samym CPU od strony języka maszynowego, nie ma różnic. Pomiędzy różnymi uC różnice są w wielkości pamięci FLASH, RAM i peryferii. Porównanie not AT89S52 i AT89C2051 wyjaśni wszelkie wątpliwości, z najważniejszych (poza RAM i FLASH) z punktu widzenia programu to timer T2 w 89S52.

Do podobnych wniosków doszedłem czytając materiały w internecie, na timer nie zwróciłem chyba uwagi, bo wiedziałem, że mnie nie interesuje.
Natomiast kwestia braku SPI, to właściwie przyczyna problemów, bo gdybym mógł 2051 programować przez SPI, to bym go przeprogramował już milion razy sprawdzając co działa, a co nie i nie musiałbym Wam zawracać głowy.

Więc, niestety, róznice, które zauważyliście wynikają z zamierzonego działania. Pozostajemy przy wersji z uszkodzonym układem? Czy ktoś się z Was kiedyś spotkał z takim „małym” uszkodzeniem?

Gloomwing wrote:

2051 ma podpięty „na świat” inny pin - stąd różnica P3_0 i P3_1.

Dlaczego do komunikacji nie używasz UART?

Gloomwing wrote:

bo gdybym mógł 2051 programować przez SPI,

89LP2051 i podobne albo emulator 89C2051. W czaszach (ubiegłe tysiąclecie) gdy 8051 był na topie można było kupić emulatory tych uC, teraz to już tylko z odzysku.

LChucki wrote:

Nie używam 8051 od ok 10 lat więc ciężko z pamięci coś więcej napisać zwłaszcza o 89S5x bo "karierę" z 8051 zakończyłem na 89C5x.

Też raczej nie zostanę dużym fanem, chyba głównie ze względu na brak SPI. Traktuję to raczej jak impuls do jakiegoś rozwoju. Dzięki temu w ogóle wiem co to jest asembler i trochę bardziej rozumiem architekturę tych urządzeń. Moje dalsze przygody, pójdą raczej w różne atmegi i attiny.

Dodano po 2 [minuty]:

LChucki wrote:

Dlaczego do komunikacji nie używasz UART?

Bo w S52 miałem wyprowadzone tylko TX, więc „wymyśliłem” taki sposób komunikacji (inspirowany one-wire).

Gloomwing wrote:

stąd różnica P3_0 i P3_1.

I to są jedyne różnice jakie widzisz? Dlaczego w takim razie zmieniłeś warunek z 1 na 0 ?
.

Gloomwing wrote:

gdybym mógł 2051 programować przez SPI

Jest dostępny AT89S2051 :

https://www.tme.eu/pl/details/at89s2051-24pu/rodzina-8051-8-bit/microchip-atmel/

Gloomwing wrote:

Dzięki temu w ogóle wiem co to jest asembler

W dzisiejszych czasach nie warto sobie zawracać głowy assemblerem.

Gloomwing wrote:

i trochę bardziej rozumiem architekturę tych urządzeń.

Poczytaj raczej o Z-80 do którego to było DMA.

Gloomwing wrote:

Moje dalsze przygody, pójdą raczej w różne atmegi i attiny.

Raczej ARM, nie warto wchodzić a przestarzałe technologie, drogie i o małych możliwościach.

LChucki wrote:

89LP2051 i podobne albo emulator 89C2051. W czaszach (ubiegłe tysiąclecie) gdy 8051 był na topie można było kupić emulatory tych uC, teraz to już tylko z odzysku.

Poczytam o tym.

trol.six wrote:

Gloomwing wrote:

stąd różnica P3_0 i P3_1.

I to są jedyne różnice jakie widzisz? Dlaczego w takim razie zmieniłeś warunek z 1 na 0 ?

No, to mamy winowajcę!
Jak pierwszy raz zamontowałem układ spowrotem zauważyłem typo polegające na tym, że nie zmieniłem jednego z P3_0 na P3_1 - najwyraźniej zmieniłem, ale złą jedynkę (tę za '=='), potem, jak programowałem drugi raz, poprawiłem, ale tylko pierwszą część.

W poniedziałek postaram się to sprawdzić i napisać czy mi się powiodło.

Gloomwing wrote:

LChucki wrote:

89LP2051 i podobne albo emulator 89C2051. W czaszach (ubiegłe tysiąclecie) gdy 8051 był na topie można było kupić emulatory tych uC, teraz to już tylko z odzysku.

Poczytam o tym.

Przeszukaj archiwum EP. Znajdziesz tam AVT-497. Używałem tego bardzo długo nawet mam jeszcze 2 szt, zmontowane, sprawne, w obudowie.

LChucki wrote:

W dzisiejszych czasach nie warto sobie zawracać głowy assemblerem.

nie planuję programować w asemblerze, ale zrozumienie kroku pomiędzy językiem wysokiego poziomu a językiem maszynowym zbliża mnie do zrozumienia jak w ogóle działają procesory (jestem po lekturze kilku rozdziałów z książki elektronika w pytaniach i odpowiedziach).

LChucki wrote:

Raczej ARM, nie warto wchodzić a przestarzałe technologie, drogie i o małych możliwościach.

Czyli nie czytać o Z80, nie pchać się w układy atmela tylko od razu iść w stronę ARM (Raspery Pi?).

Szczerze myślę, o tym, żeby na poważnie rozwinąć swoje umiejętności dotyczące mikroukładów i ich programowania w C++ - to o czym teraz mówimy jest całkiem fundamentalne jeśli chodzi o „przyszłość”. Gdzie jest teraz popularność i zapotrzebowanie na programistów? Mocny OT, ale póki temat nie jest rozwiązany...

Gloomwing wrote:

nie planuję programować w asemblerze, ale zrozumienie kroku pomiędzy językiem wysokiego poziomu a językiem maszynowym zbliża mnie do zrozumienia jak w ogóle działają procesory

Jakkolwiek nie uczyłem się z książek o Z-80, to bardzo dabra literaturą jest seria książek MIK Stanisława Gardynika o CA-80. Legalne skany znajdziesz na Elektrodzie.

Gloomwing wrote:

Czyli nie czytać o Z80

Jak chcesz poznać budowę CPU, peryferii, DMA to najłatwiej właśnie na Z-80.

Gloomwing wrote:

nie pchać się w układy atmela

W AVR nie ma sensu, SAM też nie są zbyt popularne.

Gloomwing wrote:

iść w stronę ARM

Na Forbocie znajdziesz kursy. CubeMX ułatwia start, zainteresuj się wiec STM32.

Gloomwing wrote:

Raspery Pi?)

Do Raspberry nie trzeba znać architektury ARM, trzeba znać Linux.

Gloomwing wrote:

Gdzie jest teraz popularność i zapotrzebowanie na programistów?

Ucz się mandaryńskiego.

LChucki wrote:

Jakkolwiek nie uczyłem się z książek o Z-80, to bardzo dabra literaturą jest seria książek MIK Stanisława Gardynika o CA-80. Legalne skany znajdziesz na Elektrodzie.

W ciągu tych paru dni już trochę przeczytałem (jedną książkę o Z80). Jeśli chodzi o poznanie procesora, to bardziej jestem ciekaw co się dzieje jak procesor odczyta instrukcję (struktura tranzystorów). Ale może do tego dojdę jeszcze...
Znalazłem w swych zapasach bebechy z maszyny wytrzymałościowej (lata 80 może), z UB880 (któraś wersja) z całą gamą peryferii i paronastoma pamięciami - powalczę, może uda mi się coś z tym zdziałać.

Rozważę STM32.

LChucki wrote:

Ucz się mandaryńskiego.

Nie podoba mi się składnia.

Wracając do tematu. Po porawieniu literówki zauważonej przez trol.six'a i wgraniu programu wszystko śmiga jak trzeba. Dziękuję wszystkim za uwagę i pomoc. Punkty rozdane.