Pracuję właśnie nad pewnym projektem retro, składanym ze starych części.
Pracą urządzenia steruje mikroprocesor WDC65C02, jest też trochę innych
peryferiów, m.in UART R65C51. Urządzenie zdaje się pracować prawidłowo,
uruchomiłem większość podzespołów, problemy zaczęły się właśnie przy w
przypadku portu szeregowego.

1) Sam R65C51 zdaje się działać prawidłowo. Kiedy podpiąłem go do
przelotki USB-UART (linia CTS tymczasowo ściągnięta do masy) wszystko
działa prawidłowo. Urządzenie przechodzi inicjalizację i na komputerze
mogę odbierać wysyłane przez nie komunikaty. Transmisji w drugą stronę
jeszcze nie testowałem.
2) Urządzenie inicjuje się także wtedy, gdy do R65C51 nie jest
podłączony ani konwerter USB-UART, ani RS232.
3) Jednak gdy włożę w podstawkę układ MAX232, urządzenie nie przechodzi
inicjalizacji. Najwyraźniej zawiesza się właśnie na inicjalizacji
R65C51. Dopiero podłączenie do komputera za przez kabel RS232 naprawia
sytuację - wtedy urządzenie znów zaczyna się prawidłowo uruchamiać, a w
terminalu pojawiają się komunikaty.

Sęk w tym, że UART ma służyć do konfiguracji i diagnostyki urządzenia.
Nie mogę sobie pozwolić na sytuację, żeby jego uruchomienie wymagało
podpięcia do komputera.

Ktoś ma jakiś pomysł odnośnie tego, co robię źle?

Kod inicjujący UART jest relatywnie prosty:

void mos6551_init (void) {
//initialise 6551 ACIA
ACIA_RES = 0xFF; //soft reset (value not important)
ACIA_CMD = 0x0B; //set specific modes and functions
ACIA_CTL = 0x1E; //8-N-1, 9600 baud
}

Za pomocą CC65 kompiluje się do następującego kodu asemblerowego:

; ----------------------------------------------------
-----------
; void __near__ mos6551_init (void)
; ----------------------------------------------------
-----------

.segment "CODE"

.proc _mos6551_init: near

.segment "CODE"

lda #$FF
sta $6001
lda #$0B
sta $6002
lda #$1E
sta $6003
rts

.endproc

do góry

W dniu 13.08.2020 o 07:59, Atlantis pisze:
> Pracuję właśnie nad pewnym projektem retro, składanym ze starych części.
> Pracą urządzenia steruje mikroprocesor WDC65C02, jest też trochę innych
> peryferiów, m.in UART R65C51. Urządzenie zdaje się pracować prawidłowo,
> uruchomiłem większość podzespołów, problemy zaczęły się właśnie przy w
> przypadku portu szeregowego.
>
> 1) Sam R65C51 zdaje się działać prawidłowo. Kiedy podpiąłem go do
> przelotki USB-UART (linia CTS tymczasowo ściągnięta do masy) wszystko
> działa prawidłowo. Urządzenie przechodzi inicjalizację i na komputerze
> mogę odbierać wysyłane przez nie komunikaty. Transmisji w drugą stronę
> jeszcze nie testowałem.
> 2) Urządzenie inicjuje się także wtedy, gdy do R65C51 nie jest
> podłączony ani konwerter USB-UART, ani RS232.
> 3) Jednak gdy włożę w podstawkę układ MAX232, urządzenie nie przechodzi
> inicjalizacji. Najwyraźniej zawiesza się właśnie na inicjalizacji
> R65C51. Dopiero podłączenie do komputera za przez kabel RS232 naprawia
> sytuację - wtedy urządzenie znów zaczyna się prawidłowo uruchamiać, a w
> terminalu pojawiają się komunikaty.
>
> Sęk w tym, że UART ma służyć do konfiguracji i diagnostyki urządzenia.
> Nie mogę sobie pozwolić na sytuację, żeby jego uruchomienie wymagało
> podpięcia do komputera.

Na szybko i na moje oko to poza tx i rx masz podpięte pewnie inne sygnały.

Pozdrawiam

DD

do góry

On 13.08.2020 08:17, Dariusz Dorochowicz wrote:

> Na szybko i na moje oko to poza tx i rx masz podpięte pewnie inne sygnały.

Tak, MAX232 obsługuje jeszcze dwie linie: RTS (podłączony do pinu 7
gniazdka RS232) oraz CTS (podłączony do pinu 8).
Połączenie z komputerem jest wykonane przez scrossowany kabel.
Wejścia DSR i DCD są na stałe połączone z masą. Wyjście DTR nie jest do
niczego podłączone.

do góry

W dniu 13.08.2020 o 08:39, Atlantis pisze:
> On 13.08.2020 08:17, Dariusz Dorochowicz wrote:
>
>> Na szybko i na moje oko to poza tx i rx masz podpięte pewnie inne sygnały.
>
> Tak, MAX232 obsługuje jeszcze dwie linie: RTS (podłączony do pinu 7
> gniazdka RS232) oraz CTS (podłączony do pinu 8).
> Połączenie z komputerem jest wykonane przez scrossowany kabel.
> Wejścia DSR i DCD są na stałe połączone z masą. Wyjście DTR nie jest do
> niczego podłączone.

No to jak nie masz tam nic podłączonego to nie dziwne że nie działa.
Zewrzyj RTS z CTS albo je programowo ignoruj (jak się da, zapewne się
da) i pewnie będzie lepiej. Oczywiście chodzi o zwarcie po jednej
stronie bez przeprowadzania kabla do komputera.

Pozdrawiam

DD

do góry

On 13/08/2020 07:59, Atlantis wrote:
> 3) Jednak gdy włożę w podstawkę układ MAX232, urządzenie nie przechodzi
> inicjalizacji. Najwyraźniej zawiesza się właśnie na inicjalizacji
> R65C51. Dopiero podłączenie do komputera za przez kabel RS232 naprawia
> sytuację - wtedy urządzenie znów zaczyna się prawidłowo uruchamiać, a w
> terminalu pojawiają się komunikaty.

Bardzo podejrzane. Włożenie MAX232 nic nie powoduje. Nawet stan lini
wejściowych nie powinien sie wyraźnie zmienić.

Sprawdzałeś co się stanie jak podniesiesz linie wejściowe do +5V przez
jakieś rezystory? Też się "psuje"?

Co to znaczy "urządzenie nie przechodzi inicjalizacji". W sensie
zawiesza się na jakiejś pętli?

Rozumiem że brałeś kod i schemat z tego miejsca?

http://retro.hansotten.nl/6502-sbc/lee-davison-web-s
ite/acia-6551/

do góry

Dnia Thu, 13 Aug 2020 07:59:06 +0200, Atlantis napisał(a):
> Pracuję właśnie nad pewnym projektem retro, składanym ze starych części.
> Pracą urządzenia steruje mikroprocesor WDC65C02, jest też trochę innych
> peryferiów, m.in UART R65C51. Urządzenie zdaje się pracować prawidłowo,
> uruchomiłem większość podzespołów, problemy zaczęły się właśnie przy w
> przypadku portu szeregowego.
>
> 1) Sam R65C51 zdaje się działać prawidłowo. Kiedy podpiąłem go do
> przelotki USB-UART (linia CTS tymczasowo ściągnięta do masy) wszystko
> działa prawidłowo. Urządzenie przechodzi inicjalizację i na komputerze
> mogę odbierać wysyłane przez nie komunikaty. Transmisji w drugą stronę
> jeszcze nie testowałem.
> 2) Urządzenie inicjuje się także wtedy, gdy do R65C51 nie jest
> podłączony ani konwerter USB-UART, ani RS232.

> 3) Jednak gdy włożę w podstawkę układ MAX232, urządzenie nie przechodzi
> inicjalizacji. Najwyraźniej zawiesza się właśnie na inicjalizacji
> R65C51. Dopiero podłączenie do komputera za przez kabel RS232 naprawia
> sytuację - wtedy urządzenie znów zaczyna się prawidłowo uruchamiać, a w
> terminalu pojawiają się komunikaty.

> void mos6551_init (void) {
> //initialise 6551 ACIA
> ACIA_RES = 0xFF; //soft reset (value not important)
> ACIA_CMD = 0x0B; //set specific modes and functions
> ACIA_CTL = 0x1E; //8-N-1, 9600 baud
> }
>
> Za pomocą CC65 kompiluje się do następującego kodu asemblerowego:
>
> ; ----------------------------------------------------
-----------
> ; void __near__ mos6551_init (void)
> ; ----------------------------------------------------
-----------
>
> .segment "CODE"
>
> .proc _mos6551_init: near
>
> .segment "CODE"
>
> lda #$FF
> sta $6001
> lda #$0B
> sta $6002
> lda #$1E
> sta $6003
> rts
>
> .endproc


Tu nie ma nic, co by moglo sie zawiesic.
Szukaj gdzies dalej.

Moze dalej program na jakis stan linii czeka, moze przerwania sie
aktywuja, moze stale cos odbiera.

Niepodlaczone linie kosci powinny miec stan "1" czyli nieaktywne,
ale Max232 tez powinien na nich "1" ustawic, jesli kabla brak.

A moze wlasnie program chce wyslac cos na port, wiec czeka na linie
CTS ?

J.

do góry

On 13.08.2020 09:02, heby wrote:

> Co to znaczy "urządzenie nie przechodzi inicjalizacji". W sensie
> zawiesza się na jakiejś pętli?

Teraz widzę, że urządzenie prawdopodobnie zawiesza się na pierwszej
probie wysłania czegokolwiek - w tym wypadku będzie to komunikat
oznajmujący koniec inicjalizacji peryferiów. Do pętli głównej kod nie
dochodzi, bo nie zawarty w niej kod nie wykonuje się ani razy (a trochę
różnych rzeczy wykonywał zanim w ogóle zaczynał korzystać z UART-a).

Czyżby stan wysoki na CTS powodował, że flaga oznaczająca zajęty bufor
nadawczy nigdy nie była zerowana? Moja procedura nadawania znaku
faktycznie czeka na jej zwolnienie...

Czy mogę programowo sprawdzić status CTS, aby w przypadku stanu
wysokiego program po prostu rezygnował z próby nadawania? Czy też jedyną
opcją jest przerobienie układu i zrezygnowanie z obsługi CTS/RTS?


> Rozumiem że brałeś kod i schemat z tego miejsca?
>
> http://retro.hansotten.nl/6502-sbc/lee-davison-web-s
ite/acia-6551/

Dzięki za podesłanie linku. Zerknięcie na schemat uświadomiło mi, że
miałem trywialny błąd -zamiast dwóch kondensatorów między pinem 2 i VCC
orz pinem 6 i masą miałem jeden kondensator między tymi pinami. To
jednak nie to było powodem opisywanych problemów - po usunięciu błędu
problem nadal występuje.

do góry

On 13/08/2020 22:38, Atlantis wrote:
> Czy mogę programowo sprawdzić status CTS, aby w przypadku stanu
> wysokiego program po prostu rezygnował z próby nadawania? Czy też jedyną
> opcją jest przerobienie układu i zrezygnowanie z obsługi CTS/RTS?

CTS/RTS ma sens *jedynie* kiedy twoje urządzenia są zbyt powolne aby
odbierać znaki jeden po drugim.

> jednak nie to było powodem opisywanych problemów - po usunięciu błędu
> problem nadal występuje.

Jak ustawisz asercje na RTS/CTS (+5V bodaj) to nagle się główna pętla
odblokuje?

do góry

On 13/08/2020 23:31, heby wrote:
> Jak ustawisz asercje na RTS/CTS (+5V bodaj) to nagle się główna pętla
> odblokuje?

Jeszcze jedno: mimo że cpu nie ma debugu, to mógłbyś wpiąć się w linie
adresowe i ocenić gdzie się miota. Może z pomocą analizatora ustalisz
jaki kod jest wykonywany w pętli, albo choć kilka starszych bitów adresu
uda się zidentyfikować (zwróć uwagę na pin SYNC).

Osobiście wziąłbym jakiś softwareowy emulator tego cpu, wrzucił kod i
napisał jakiś trywialny emulator scalaka do transmisji szeregowej... ale
to robota dla programisty. Ma to zaletę że można debugować bez hardware,
w czystych i powtarzalnych warunkach.

do góry

Atlantis <m...@w...pl> napisał(a):
> Teraz widzę, że urządzenie prawdopodobnie zawiesza się na pierwszej
> probie wysłania czegokolwiek - w tym wypadku będzie to komunikat
> oznajmujący koniec inicjalizacji peryferiów. Do pętli głównej kod nie
> dochodzi, bo nie zawarty w niej kod nie wykonuje się ani razy (a trochę
> różnych rzeczy wykonywał zanim w ogóle zaczynał korzystać z UART-a).
> Czyżby stan wysoki na CTS powodował, że flaga oznaczająca zajęty bufor
> nadawczy nigdy nie była zerowana? Moja procedura nadawania znaku
> faktycznie czeka na jej zwolnienie...

Wysoki stan na pinie CTS oznacza, że drugie urządzenie nie jest gotowe do
odbioru. Nadawanie nie rozpocznie się dopóki CTS nie znajdzie się w stanie
niskim.

O ile dobrze rozumiem, zostałeś zaskoczony działającą funkcją sprzętowej
kontroli przepływu. Nie znam tego procka, więc nie wiem czy tak jest
konfigurowany UART po resecie czy też ustawia to kod inicjalizacyjny. Z
komentarzy to nie wynika.

> Czy mogę programowo sprawdzić status CTS, aby w przypadku stanu
> wysokiego program po prostu rezygnował z próby nadawania? Czy też jedyną
> opcją jest przerobienie układu i zrezygnowanie z obsługi CTS/RTS?

Stan CTS możesz oczywiście sprawdzać programowo i ewentualnie rezygnować
zamiast czekać. Będzie to trochę wbrew standardowi, bo wysoki CTS oznacza
"wyślij mi te dane później" a nie rezygnację. Ale i tak jest kwestia czy ta
sprzętowa kontrola przepływu jest Ci do czegoś potrzebna. Jeśli port
szeregowy ma robić za konsolę, to ja bym to wyłączył.

--
Grzegorz Niemirowski
https://www.grzegorz.net/

do góry