logo elektroda
logo elektroda
X
logo elektroda
Adblock/uBlockOrigin/AdGuard mogą powodować znikanie niektórych postów z powodu nowej reguły.

[Rozwiązano] Dlaczego program nie działa na AT89C2051, a na AT89S51 tak? [Tablice LED]

Gloomwing 23 Mar 2019 01:16 1203 17
  • #1 17861178
    Gloomwing
    Poziom 17  
    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:
    Kod: C / C++
    Zaloguj się, aby zobaczyć kod


    Program na AT89S51:
    Kod: C / C++
    Zaloguj się, aby zobaczyć kod


    Program na Arduino (wysyłający instrukcje):
    Kod: C / C++
    Zaloguj się, aby zobaczyć kod


    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!
  • #2 17861390
    Gienek
    Poziom 37  
    A dlaczego dla AT89C2051 wykorzystujesz #include <mcs51reg.h> ?
  • #3 17861529
    Gloomwing
    Poziom 17  
    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
    Kod: C / C++
    Zaloguj się, aby zobaczyć kod


    https://github.com/darconeous/sdcc/blob/master/device/include/mcs51/mcs51reg.h
    Kod: C / C++
    Zaloguj się, aby zobaczyć kod


    Chyba to wygląda tak samo.
    Kompiluję sdcc na linuksie.
  • #4 17862615
    Gienek
    Poziom 37  
    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.
  • #5 17862708
    Gloomwing
    Poziom 17  
    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.
  • Pomocny post
    #6 17863029
    trol.six
    Poziom 31  
    Gloomwing napisał:
    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
    Kod: Text
    Zaloguj się, aby zobaczyć kod

    Może tu jest przyczyna?

    Gloomwing napisał:

    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.
    .
  • Pomocny post
    #7 17863051
    LChucki
    Poziom 31  
    trol.six napisał:

    Gloomwing napisał:

    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.
  • #8 17863207
    Gloomwing
    Poziom 17  
    trol.six napisał:
    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 napisał:
    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?
  • #9 17863225
    LChucki
    Poziom 31  
    Gloomwing napisał:
    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 napisał:
    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.
  • #10 17863245
    Gloomwing
    Poziom 17  
    LChucki napisał:
    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 napisał:
    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).
  • Pomocny post
    #11 17863527
    trol.six
    Poziom 31  
    Gloomwing napisał:
    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 ?
    .
  • #12 17863719
    ArturAVS
    Moderator
    Gloomwing napisał:
    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/
  • #13 17863758
    LChucki
    Poziom 31  
    Gloomwing napisał:
    Dzięki temu w ogóle wiem co to jest asembler

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

    Gloomwing napisał:
    i trochę bardziej rozumiem architekturę tych urządzeń.

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

    Gloomwing napisał:
    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.
  • #14 17863763
    Gloomwing
    Poziom 17  
    LChucki napisał:
    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 napisał:
    Gloomwing napisał:
    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.
  • #15 17863770
    LChucki
    Poziom 31  
    Gloomwing napisał:
    LChucki napisał:
    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.
  • #16 17863776
    Gloomwing
    Poziom 17  
    LChucki napisał:
    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 napisał:
    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...
  • Pomocny post
    #17 17863806
    LChucki
    Poziom 31  
    Gloomwing napisał:
    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 napisał:
    Czyli nie czytać o Z80

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

    Gloomwing napisał:
    nie pchać się w układy atmela

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

    Gloomwing napisał:
    iść w stronę ARM

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

    Gloomwing napisał:
    Raspery Pi?)

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

    Gloomwing napisał:
    Gdzie jest teraz popularność i zapotrzebowanie na programistów?

    Ucz się mandaryńskiego.
  • #18 17867195
    Gloomwing
    Poziom 17  
    LChucki napisał:
    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 napisał:
    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.
REKLAMA