Odczyt parametrów karty CF

W dniu 03.10.2020 o 11:11, Atlantis pisze:

Ok, też już n to trafiłem. Okazuje się, że mój kod jest w porządku. Niejednoznaczne wyniki były wynikiem zastosowania złego typu zmiennej w procedurze, która raportowała odczytaną liczbę sektorów.

To teraz kolejne pytanie: czy istnieje jakaś prost biblioteka do obsługi systemu plików, którą mógłbym skompilować za pomocą CC65? Eksperymentowałem z FatFS. Po wprowadzeniu kilku drobnych zmian udało mi się go skompilować, jednak nawet przy rozsądnej konfiguracji zajmuje dużo miejsca w pamięci programu (w tech chili po dołączeniu tej biblioteki mam zajęty prawie cały 32kB EPROM). Rozpatruję PetitFS, ale on tutaj znowu będą bolały ograniczenia odnośnie pisania do (a właściwie dopisywana do) pliku.

Na dobrą sprawę nie musi to być nawet FAT, byleby tylko nośnik dało się zamontować pod Linuksem. Nie potrzebuję obsługi katalogów, wystarczy zapis do głównego katalogu karty CF.

Poszperaj za "microcontroller file system"

Nie wiem czy jest taki ktory ci podejdzie ale kiedys najprostsze to bylo po prostu zbudowanie sobie na sztywno 10-100 plikow w glownym katalogu i pisanie do nich po calym sektorze.

Tak dlugo jak nie bedziesz tych plikow przenosic to mozna jets otwierac na komputerze i czytac a sporo programow jes bedzie potrafic zapisac (chodzi o to aby nie zmienialy pozycji na dysku).

Taki FS jest najprostszy i najmniej pamieciozerny. Do wielu zastosowan sie nadaje.

A jak nie schesz samego FS-a to w sumie starczy ci troche skryptu bash-a. Na dysk sobie piszesz jak ci tam pasuje i tylko utrzymujesz sobie gdzies tablice gdzie ci sie pliki zaczynaja i koncza a potem sprawne uzycie dd ci to z karty zczyta albo na karte wrzuci.

Do zmontowania chyba w jeden wieczor.

W ramach testu odpaliłem na tym sprzęcie FatFS-. Jak już chyba wspominałem, potrzebne były drobne poprawki żeby go skompilować, bo nie CC65 nie radził sobie z niektórymi wyrażeniami użytymi w kodzie. Po skompilowaniu z wyłączoną większością opcjo rozmiar mojego projektu urósł dość znacznie, jednak wciąż mam jeszcze około 7kB wolnej przestrzeni pamięci EPROM, co powinno wystarczyć na zaimplementowanie funkcji, które chciałbym tam jeszcze dodać.

Pamięcią RAM się specjalnie nie przejmuję, bo 8kB w tego typu urządzeniu jest dostatecznie dużą ilością, żeby nie trzeba było się przejmować brakiem miejsca na bufory.

Pierwszy test wypadł w miarę pozytywne. Udało mi się zamontować system plików na karcie CF - instrukcja f_mount(&cffs, "", 1) zwraca 0 (jeśli usunę kartę zwraca 3)_. Instrukcja f_open(&file, "name.txt", (FA_OPEN_ALWAYS | FA_WRITE)) również zwraca taką samą wartość.

Wskazuje to na to, że występuje prawidłowa komunikacja pomiędzy kartą a systemem plików. Problem pojawia się dopiero, gdy próbuję wykonać zapis do pliku, za pomocą następującego ciągu instrukcji:

feed_hungry_watchdog(); res = f_write(&file, "Test\r\n", 6, NULL); feed_hungry_watchdog(); mos6551_puts("File write: "); utoa(res, buf, 10); mos6551_puts(buf); mos6551_puts("\r\n"); feed_hungry_watchdog(); f_close(&file); prepare_disp();

Urządzenie się resetuje, UART nie wysyła żadnej informacji o wartości zwróconej przez f_write. Co ciekawe jednak, na wyświetlaczu pojawia się efekt działania prepare_disp().

Watchdog jest ustawiony w ten sposób, żeby zresetować urządzenie dopiero po 1,2s braku aktywności. Jak widać resetuję go tuż przed i zaraz po wywołaniu f_write(). Chyba zapis paru znaków nie zabierze tyle czasu, nawet systemowi z 1 MHz 6502... Poza tym to nie wyjaśniłoby wykonania prepare_disp()...

Ktoś ma jakiś pomysł?

Pełny, aktualny kod tutaj: