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

NXP 89c51rc2 vs ATMEL 89c51rc2 - różnice w odczycie z bufora komunikacyjnego

RomanFilipecki 03 Lut 2018 12:08 1011 12
  • #1 17009301
    RomanFilipecki
    Poziom 18  
    Czy znane są Wam jakieś niekompatybilności pomiędzy tymi mikrokontrolerami, nie chodzi o ISP ale aplikację.
    Ten sam program na NXP działa poprawnie, na Atmelu prawie. Problem dotyczy odczytu z bufora komunikacyjnego w xram, w pierwszych 256 bajtach.
  • #2 17009410
    JarekC
    Poziom 32  
    Problem prawdopodobnie dotyczy bitu XRAM w rejestrze AUXR.
    W P89C51RC2 (NXP) ten bit ma po resecie wartość domyślną '0' czyli dostęp do wewnętrznego XRAM.
    Natomiast w AT89C51RC2 (ATMEL) po resecie ten bit jest ustawiany zgodnie z bitem 3 rejestru protekcji HSB . Stan HSB ustalany jest na etapie programowania uP.
    Oczywiście potem możesz nadpisać stan rejestru AUXR, ale jeżeli tego nie robisz w programie to możliwe że masz wyłączony dostęp do wewnętrznego XRAM.

    Procesory te różnią się też Watchdogiem, NXP ma stałą wartość timera, w ATMELu można zmieniać czas zadziałania.

    Szczegóły znajdziesz w karcie katalogowej AT89C51RC2.

    Pozdrawiam
    JarekC
  • #3 17009439
    RomanFilipecki
    Poziom 18  
    Dziękuję za zainteresowanie.

    Było by to zbyt proste. Inicjalizacja jest poprawna.
    Bufor komunikacyjny w xram użyty jest przez procedury obsługujące dwa protokoły. Problemy sprawia tylko jeden z nich.

    Daję sobie jeden dzień na poszukowania.
    Projekt sprzed kilkunastu lat, potrzebna powtórka, są płytki a tu niespodzianka. Procki od NXP raczej niedostępne...

    Planuję migrację do STM32.
  • #5 17009617
    RomanFilipecki
    Poziom 18  
    Nieprawidłowo działą parser komunikatu jednego z protokołów.
    Zachowuje się tak że odczytując typ pakietu ( pakiet pomidzy EOT i ETX) odczytany znak to ':' a oczekuje S, C, M, F.
    Procedura odbierająca komunikację działa w przerwaniach i ustawia wskaźnik gotowości po skompletowaniu pakietu pomiędzy EOT .... ETX.
    Ten wskaźnik jest ustawiany poprawnie ( podglądam komunikację) , natomiast parsowanie idzie w buraki.
    Z drugim protokołem nie ma problemu, działą na tym smym buforze, protokoły nie działają jednocześnie.
  • #7 17010243
    RomanFilipecki
    Poziom 18  
    Mam fizycznie zarówno NXP i Atmel.
    Ten sam kod w jednym i drugim. NXP ok, Atmel problem.
    Ale przypomniałem sobie podobny problem z 2001 chyba roku. Trafił mi się Atmel 89c51RD i zachowywał się tak jakby Xramu fizycznie nie było.
    Sprawdzę jutro na innymm Atmelu.
  • #9 17014770
    RomanFilipecki
    Poziom 18  
    Tak z ciekawostek uzyskałem poprawne działanie protokołu po mmodyfikacji o 1 wrtosci rejestru RCAP2L.
    Problematyczny protokół pracuje na 4800, ten który funkconował na 9600.
    Na NXP obydwa pracują na starych nastawach.
    Sterownik taktowany jest 12MHz.
    Zbadam temat głębiej.
  • #11 17014993
    RomanFilipecki
    Poziom 18  
    Źródłem taktowania uart jest T2
  • #12 17015604
    JarekC
    Poziom 32  
    Dla 12MHz:
    Taktowanie przez T2
    Baudrate 4800 RCAP2H =0xFF, RCAP2L =0x64, rzeczywista prędkość 4807bodów, błąd 0.15%
    Baudrate 9600 RCAP2H =0xFF, RCAP2L =0xB2 rzeczywista prędkość 9615bodów, błąd 0.16%

    Dla AT89c51RX2 możliwe wykorzystanie dedykowanego Baudrate Generator przy czym błędy będą podobne.
  • #13 17016015
    RomanFilipecki
    Poziom 18  
    Może to nie chodzi bezpośrednio taktowanie a o funkcjomalność sekwencera odbioru bitu ( bodu). Sekwencer z kilu próbek stanu portu w trakcie trwania bitu określa jego stan. Przykładowo sekwencer używany w portach szeregowych PC jest dużo dokładniejszy, czyli jego wykonania są różne. Nie wiemy jak są wykonane w tych 51.
    Wcześniej w tym projekcie używałem NXP w wersjach C, V, CV. Ten sam kod i nigdy nie było takiego problemu.
    Faktem jest że ten projekt w tej postaci musi dokończyć żywot ale sam jestem ciekawy problemu, pomyślę jeszcze o tym.
REKLAMA