Przesył plików. Ciąg dalszy.

  Pierwsze próby przesyłania plików Intel Hex były udane, jednak pełna wersja programu iLoad zgłaszała błąd na początku czwartego rekordu. Postanowiłem to zbadać.

Błędy na początku czwartego rekordu.

Początkowo podejrzewałem, że zrobiłem błąd w czasie dostosowywania kodu do i8251, więc zrobiłem to jeszcze raz od początku. Mimo że program był inny, błąd pojawiał się dokładnie w tym samym miejscu. Zmiana prędkości transmisji nic nie zmieniała - wersja z kropką po każdym wczytanym rekordzie działa na wszystkich (2400, 4800, 9600 i 19200 baud), a pełna zawsze kończy w tym samym miejscu "Syntax error" lub "Checksum error!"

Dwa kilobajty przesłane bez błędu.

Znalazłem w ustawieniach TeraTerm opcję dodawania opóźnienia po każdym znaku lub po każdym rekordzie i spróbowałem obu. Dodanie 1 ms po bajcie rozwiązało problem - plik z programem c800-monitor (2kB kodu wynikowego czyli 128 rekordów) przesłany bez błędu. Transmisja trwała prawie 1.5 minuty... 

Opóźnienie 1 ms na znak pozwala na pracę przy 19200 bodach.

Nie liczyłem znaków odbieranych i wysyłanych, ale prawdopodobnie wysłanie znaku trwa zbyt długo (jest blokujące) i dochodzi do zgubienia znaku odbieranego. 8251 nie ma FIFO, więc trzeba czekać na opróżnienie rejestru nadawczego, żeby wpisać tam nowy znak. Usunąłem wyświetlanie dwukropka na początku rekordu i zgubiony znak wystąpił znacznie później - w trzydziestym drugim rekordzie. Krótkie programy dałyby się przesłać bezbłędnie.

Bez dwukropka wczytuje się więcej.

Pozostaje zmienić sposób wysyłania i odbierania znaków (bufor kołowy), albo pozostać przy wersji uproszczonej. Można też nie czekać na zwolnienie rejestru nadawczego, ale wtedy będą gubione wyświetlane znaki, czyli ewentualny wydruk będzie bez sensu.

Wydruk bez "zgubionych" znaków.

Jak widać gubione są CR i LF, bo wyświetlane są na końcu rekordu, kiedy program niczego nie przetwarza. Pozostałe znaki są wyświetlane po odebraniu kolejnej cyfry szesnastkowej, na którą czeka procedura odbierająca - też blokująca.