Witajcie, mam problem który wykracza poza dotychczas posiadaną wiedzę i granice rozumowania mojego umysłu
Otóż uruchomiłem bibliotekę FatFS (przykład do obsługi kart SD przez UART) na procesorze ATMega32 na płytce testowej (dokładnie ZL3AVR jeśli to w czymkolwiek może pomóc), wszystko ładnie działało bez zarzutu - karty działały szybko i niezależnie od posiadanego systemu plików (FAT16/32). Wraz z rozwojem projektu który aktualnie tworzę przyszła potrzeba przejścia na "większy/pojemniejszy" procesor. Z racji zgodności wyprowadzeń z ATMega32 zdecydowałem się na ATMega644 w obudowie DIP40 oczywiście. Przykład obsługi FatFS przez UART skopiowałem w całości jak leci do innego folderu aby go tam przerobić na M644. W M644 zmienione jest część nazw rejestrów (najczęściej przez dodanie 0) dlatego oprócz zmian w MakeFile (wpisanie procesora atmega644) musiałem aktualizować nazwy tych rejestrów od UART'a. Po kompilacji udało się wgrać program do uC M644, okazało się jednak że jeszcze coś nie działa - powodem były nieco inne nazwy przerwań od UART'a, zmieniłem zatem te nazwy i po kompilacji (wcześniejszym oczyszczeniu) i wgraniu do uC M644 przykład do obsługi kart ruszył pięknie. W porównaniu do Mega32 mam tylko jedną różnicę w działaniu samych kart, po wklepaniu polecenia fs (pokazuje info o partycji) uC M644 zatrzymuje się na około 5 sekund i dopiero wyświetli pełną informacje o partycji. Co ważne taki objaw mam tylko na kartach z systemem plików FAT16 - na FAT32 od razu szybko wyświetla te informacje. Co ciekawe na Mega32 nie miałem problemów z przywieszaniem sie uC - zarówno FAT16 jak i FAT32 działały równie szybko i poprawnie.
Czy ktoś ma jakiś cień choćby przypuszczeń dlaczego tak może być ?
Druga sprawa, po uruchomieniu tego na M644 chciałem wrócić do przykładu na M32. Zmieniłem więc uC na płytce testowej zamknąłem program Code Blocks w którym tworzę programy na uC, otworzyłem projekt z innego folderu który wcześniej był uruchomiony na M32 i działało wszystko sprawnie. Po kompilacji i wgraniu - klops! uC nie działał - na UART nie leciały żadne dane. Po długich męczarniach doszedłem do tego że M32 i przykład ruszyły po wpisaniu nazw przerwań wg. nowego standardu tj. ISR(...);
te stare nazwy przerwań (SIGNAL(SIG_UART_RECV)) tak jakby przestały działać ?!
Jak to możliwe ? Czy kompilator przestawia sobie jakieś opcje wewnętrzne ?
Nie wchodzi w grę możliwość tego że mieniłem sobie pliki między projektami na M32 i M644 bo w przypadku projektu na M32 miałem porobione specjalne archiwa które tworzę po odpaleniu projektu - nawet po odtworzeniu archiwum do innego folderu, czyszczenia przed kompilacją przykłady nie uruchomiły sie do póki nie zmieniłem tych nazw...
Czy ktoś ma jakieś pomysły z czym np. mogło by to być związane ? Bo jak w pierwszym pytaniu o te karty w FAT16 to mógłbym sobie tłumaczyć innym sprzętem i jakimiś różnicami, ale w tym przypadku wszystko jest jak było i nie działa...
Chyba o czymś nie wiem albo "odkryłem" jakieś dziwne czary mary które skutecznie zabrały mi trochę życia... ;>
Za pomoc i wszelkie sugestie już teraz dziękuje
Otóż uruchomiłem bibliotekę FatFS (przykład do obsługi kart SD przez UART) na procesorze ATMega32 na płytce testowej (dokładnie ZL3AVR jeśli to w czymkolwiek może pomóc), wszystko ładnie działało bez zarzutu - karty działały szybko i niezależnie od posiadanego systemu plików (FAT16/32). Wraz z rozwojem projektu który aktualnie tworzę przyszła potrzeba przejścia na "większy/pojemniejszy" procesor. Z racji zgodności wyprowadzeń z ATMega32 zdecydowałem się na ATMega644 w obudowie DIP40 oczywiście. Przykład obsługi FatFS przez UART skopiowałem w całości jak leci do innego folderu aby go tam przerobić na M644. W M644 zmienione jest część nazw rejestrów (najczęściej przez dodanie 0) dlatego oprócz zmian w MakeFile (wpisanie procesora atmega644) musiałem aktualizować nazwy tych rejestrów od UART'a. Po kompilacji udało się wgrać program do uC M644, okazało się jednak że jeszcze coś nie działa - powodem były nieco inne nazwy przerwań od UART'a, zmieniłem zatem te nazwy i po kompilacji (wcześniejszym oczyszczeniu) i wgraniu do uC M644 przykład do obsługi kart ruszył pięknie. W porównaniu do Mega32 mam tylko jedną różnicę w działaniu samych kart, po wklepaniu polecenia fs (pokazuje info o partycji) uC M644 zatrzymuje się na około 5 sekund i dopiero wyświetli pełną informacje o partycji. Co ważne taki objaw mam tylko na kartach z systemem plików FAT16 - na FAT32 od razu szybko wyświetla te informacje. Co ciekawe na Mega32 nie miałem problemów z przywieszaniem sie uC - zarówno FAT16 jak i FAT32 działały równie szybko i poprawnie.
Czy ktoś ma jakiś cień choćby przypuszczeń dlaczego tak może być ?
Druga sprawa, po uruchomieniu tego na M644 chciałem wrócić do przykładu na M32. Zmieniłem więc uC na płytce testowej zamknąłem program Code Blocks w którym tworzę programy na uC, otworzyłem projekt z innego folderu który wcześniej był uruchomiony na M32 i działało wszystko sprawnie. Po kompilacji i wgraniu - klops! uC nie działał - na UART nie leciały żadne dane. Po długich męczarniach doszedłem do tego że M32 i przykład ruszyły po wpisaniu nazw przerwań wg. nowego standardu tj. ISR(...);
te stare nazwy przerwań (SIGNAL(SIG_UART_RECV)) tak jakby przestały działać ?!
Jak to możliwe ? Czy kompilator przestawia sobie jakieś opcje wewnętrzne ?
Nie wchodzi w grę możliwość tego że mieniłem sobie pliki między projektami na M32 i M644 bo w przypadku projektu na M32 miałem porobione specjalne archiwa które tworzę po odpaleniu projektu - nawet po odtworzeniu archiwum do innego folderu, czyszczenia przed kompilacją przykłady nie uruchomiły sie do póki nie zmieniłem tych nazw...
Czy ktoś ma jakieś pomysły z czym np. mogło by to być związane ? Bo jak w pierwszym pytaniu o te karty w FAT16 to mógłbym sobie tłumaczyć innym sprzętem i jakimiś różnicami, ale w tym przypadku wszystko jest jak było i nie działa...
Chyba o czymś nie wiem albo "odkryłem" jakieś dziwne czary mary które skutecznie zabrały mi trochę życia... ;>
Za pomoc i wszelkie sugestie już teraz dziękuje
