Przeczytałem, rozumiem.
Z tym kodem końca transmisji to tylko moje przypuszczenie.
Jak pracowałem na obrabiarce numerycznej to komputerek współpracował z tym na maszynie SIENENS.
Transmisja była po RS-232 i koniec transmisji sygnalizowany był kodem 00. Po prostu na końcu pliku umieścić należało dwa bajty zerowe.
Dla komputerka napisałem procedury zapisu, odczytu które uwzględniały ten fakt i współpracowało aż miło.

Tu, jak nadpisuje plik o tej samej nazwie pokaże się komunikat czy zatwierdzić T/N, ale potem jak pisałem kursor miga i DOS czegoś oczekuje.... poczekam dłużej, może ten timeout to czas trzech miesięcy... :)

Nie próbowałem z przełącznikami komend. Popróbuję.
Swoje doświadczenia opieram na instrukcji do komputerka, a tam jest że goła komenda COPY wystarcza
Przed laty miałem innego PCta z chyba Windowsem95,98 ???? Nie pamiętam i działało.
Potem zmieniłem sprzęt etc..etc... i DOSa wywołuję przez CMD i transmisja do PC nie jest tym czym było.
Do komputerka mam różne przystawki dorobione, ważne że do niego przesłać mogę dane, odczyt danych mniej istotny. Ostatecznie do tej pory radziłem sobie w wyżej opisany sposób.
Zapytałem, bo fajnie by było jakby transmitowało w obie strony bez cudowania.

A komputerek z Atari dogaduje się perfekcyjnie, więc zakładam że jego procedury są OK, a coś w PC źle ustawione.... ja coś źle robię ???.....Niestety na PC znam się tak jak na chirurgi, więc nic nie wymyślę.

Jest tak jak piszesz. Siedzę i kombinuję. Może coś w ustawieniach trzeba zmienić.
Po latach wracam do dawnych zabawek. Programuję sobie jazdę modelu samochodu na gąsienicach sterowanego procesorem AT89C2051. Może uda się komputerek zaprezentować na jednym z "posiedzeń" na Atari on line, jako coś co było.
Fajnie byłoby gdyby działało jak dawniej. Jak nie, trudno. Zapis/odczyt działa mi przy współpracy z Atari. Na PC piszę procedurki, asembleruję do postaci INTELHEX. Gdyby reszta działała, byłoby super.
I tak dobrze że gotowy plik można przesłać do komputerka z programować ATMELA, nie muszę korzystać z pomocy ATARI.

:)
1. Nie uważam za wadę. Atari jest zbyt cenne by kabelkiem łączone było z dużym bratem.
2. Łatwo powiedzieć, żebym wiedział jak to zrobić (wstyd, ale nie wiem)

Komputerek przesyła plik w formacie INTELHEX. Ma w sobie procedurę do tego napisaną. Podaje się adres początku danych w pamięci, adres końca i wyślij i transmituje
Kabelek RS-232 używa tylko trzech sygnałów, masa, wyślij, odbierz, bez potwierdzeń. Tak to zostało zaprojektowane, opisane i zrobione
Może w projekcie coś było niedopracowane i nie działa jak trzeba.
Sam format INTELHEX jako ostatni rekord zawiera w sobie informację że plik się kończy. Tu pewnie leży przyczyna że PC nie reaguje na to. Jakieś ustawienia w konfiguracji transmisji trzeba zrobić.... coś tam, coś tam.... nie mam zielonego pojęcia.

Hej!

@Zenon: z tego co pamiętam z czasów używania RS-ów, Modemów i DOS-a to transmisja z kanału znakowego jakim może być port COM: była kończona gdy w strumieniu danych znalazł się tzw. control-character oznaczający koniec pliku (EOF), a przypadku PC/DOS była to sekwencja generowana po naciśnięciu control+Z, więc jeżeli to ATMEL nadaje w stronę PC to spróbuj jako ostatni wysyłany bajt pliku wysłać bajt o wartości 26 (dec), czyli 0x1A (hex).

Nie sprawdziłem tego jeszcze więc traktuj moje wywody z dużą dawką ostrożności, bo piszę "z pamięci" która bywa mocno zawodna.

Na pytanie dlaczego kiedyś to działało, odpowiedź może być taka że być może kiedyś BIOS czy DOS inaczej traktowały odbiór danych i miały założony jakiś timeout po którym po prostu kopiowanie się kończyło lub oczekiwane było nadanie znaku "BREAK" na linii transmisyjnej (zero logiczne utrzymujące się dłużej niż 10 bitów). Nie wiem czy obecne systemy Windows potrafią prawidłowo taki sygnał zinterpretować. Wszystko też zależy od portu jaki masz na płycie, nie wiem czy używasz prawdziwego RS232 czy też jakiejś przejściówki RS232-USB, ale część takich przejściówek nie potrafi prawidłowo rozpoznać sygnału BREAK na linii RX.

Podsumowując ta moją nieco przydługą odpowiedź, możesz spróbować wysyłać ten dodatkowy bajt na końcu danych (#26 / $1A) lub też po zakończonej transmisji ustawić linię TX po stronie ATMEL-a na logiczne "0", na tyle długo aby komputer PC zorientował się że został nadany sygnał BREAK.

Jeżeli nie chcesz niż przerabiać po stronie kodu w ATMEL-u, to jeżeli korzystasz z windows i program w ATMEL wysyła to jako IntelHEX, a więc właściwie ciąg znaków ASCII, to można wykorzystać jakiś program terminalowy (np. "TerraTerm Pro" lub PuTTY i używając którychś z tych programów, można mieć konsolę terminala która będzie mogła odebrać ciąg znaków z portu COM. Potem to co wyszło na konsolę można sobie albo zapisać do pliku albo skopiować do schowka i gdzieś przenieść. Nie potrzeba odpalać CMD i używać polecenia Copy. Nie wiem którego Windows używasz, jeżeli jakiegoś starszego to w nim był wbudowany program terminalowy (HyperTerminal).

A jeżeli dodatkowo trzeba wysyłać jakieś dziwne sekwencje do tej płytki z ATMEL-em aby cokolwiek zechciała odpowiedzieć (np. jakąś nie czysto tekstową sekwencję bajtów) to można skorzystać z takiego narzędzia jak terminal od Br@y++. Jest to dość wiekowy soft, używałem go za czasów windows 7, miał mocno rozbudowane opcje wysyłania różnych sekwencji bajtów, makra, etc. Niestety nie wiem czy obecnie działa to jeszcze pod Windows 10, nie mam pod ręką żadnego nowożytnego Windows aby to sprawdzić.

Jest też trzecia opcja, trzeba by napisać sobie prosty program który odbierze taki plik intel-hex z portu szeregowego i zapisze go do pliku.

ps) grzebanie w przeszłości, szczególnie takiej może dać dużo radości :) Zatem życzę owocnego grzebania w projekcie :D

Dzięki za info! Warto wiedzieć że ten program nadal funkcjonuje pod nowszymi wersjami windy :)

To może suma kontrolna transmisji sie nie zgadza i pc nie sygnalizuje błędu a jedynie zawisa transmisja?