logo elektroda
logo elektroda
X
logo elektroda
Adblock/uBlockOrigin/AdGuard mogą powodować znikanie niektórych postów z powodu nowej reguły.

[Atmega644][C] nazwy przerwań UART, FatFS -obsługa FAT16,Przypadłość ATMega644 ?

hexen2k 09 Maj 2011 18:40 2045 6
  • #1 9488787
    hexen2k
    Poziom 16  
    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 ;)
  • #2 9488999
    Piotrek_P
    Poziom 18  
    Cześć,

    Że tak zapytam. Testy robiłeś z podłączonym programatorem, czy z odłączonym? Z tym SPI to różnie bywa przy takich testach, jak wiszą na magistrali dwa układy, a nie ma w danej chwili jasno określone z którym chcemy gadać. Może w tych okolicach posprawdzaj :?:
    Na razie tyle mi przychodzi do głowy.
    Pozdrawiam
    Piotrek
  • #3 9489033
    hexen2k
    Poziom 16  
    Dzięki za zainteresowanie !

    ....sprawdzałem też z odłączonym programatorem ISP (USBASP), niestety bez zmian...
  • #4 9489115
    piotrva
    VIP Zasłużony dla elektroda
    Spróbuj jeszcze raz sprawdzić, czy CI kompilator nie zmienił jakichś ustawień programatora/kompilatora...
    I powiedz, czy wgrywasz stary hex, czy zrekompilowany
  • #5 9489433
    Piotrek_P
    Poziom 18  
    To idźmy dalej ;-) Czy przypadkiem te dwa procki nie mają ustawionej w FUSE'bitach innej częstotliwosci taktowania :?: Albo w ustawieniach obu projektów nie ma różnicy co do taktowania :?:
    Code::Blocks mam ale nie znam. Ja w AVRStudio ten tego ;-)
  • #6 9489897
    janbernat
    Poziom 38  
    Taki cień podejrzenia- nowe nazwy przerwań zostały wprowadzone dość dawno.
    A nie pamiętam czy przypadkiem ATmega644 nie był wprowadzony potem.
    Może coś w IDE rozpoznało że jest to nowszy procesor?
    No bo:
    "Po kompilacji i wgraniu - klops!"
    Gdyby tylko wgrać- a tak to była powtórna kompilacja.
    Ale nie znam code:bloks i to tylko przypuszcenia.
    Może jednak lepiej stosować nowe nazwy przerwań konsekwentnie.
  • #7 9489899
    hexen2k
    Poziom 16  
    piotrva napisał:
    Spróbuj jeszcze raz sprawdzić, czy CI kompilator nie zmienił jakichś ustawień programatora/kompilatora...
    I powiedz, czy wgrywasz stary hex, czy zrekompilowany


    w zasadzie kompilacja przebiega w taki sposób że wywołuję polecenie make z opcjami clean, all, program w zależności od potrzeb więc całe ustawienia sprowadzają się do pliku makefile. Plik makefile był na 100% nie zmieniany.
    Co do wgrywania hex'a to przed kompilacją usuwałem nawet ręcznie pliki wszystkie oprócz c i h ( w tym także właśnie hex) aby zobaczyć czy to nie wina jakichś starych plików... bez skutku. Pomogła dopiero zmiana tych nazw przerwań na nowy format.

    Cytat:
    To idźmy dalej Czy przypadkiem te dwa procki nie mają ustawionej w FUSE'bitach innej częstotliwosci taktowania Albo w ustawieniach obu projektów nie ma różnicy co do taktowania
    Code::Blocks mam ale nie znam. Ja w AVRStudio ten tego


    częstotliwość ustawiona w obu przypadkach na 16MHz, próbowałem różnych ustawień FuseBitów - także bez zmian...
    W obu projektach tak samo po 16MHz, w pliku makefile też F_CPU=16000000

    Do obecnej chwili nie wiem jak to tłumaczyć, nic nie przychodzi do głowy.
    Dodam że pracuje na Win XP. Próbowałem także restartów samego komputera - bezskutecznie... jakiś urok chyba ;)

    Cytat:
    Taki cień podejrzenia- nowe nazwy przerwań zostały wprowadzone dość dawno.
    A nie pamiętam czy przypadkiem ATmega644 nie był wprowadzony potem.
    Może coś w IDE rozpoznało że jest to nowszy procesor?
    No bo:
    "Po kompilacji i wgraniu - klops!"
    Gdyby tylko wgrać- a tak to była powtórna kompilacja.
    Ale nie znam code:bloks i to tylko przypuszcenia.
    Może jednak lepiej stosować nowe nazwy przerwań konsekwentnie.


    No tak w przypadku M644 to jeszscze bym to mógł tak próbować tłumaczyć choć w plikach nagłówkowych grzebałem i też widziałem stare i nowe nazwy dostępne, ale cały urok polega na tym że to na ATMega32 te nazwy przerwań musiałem zmienić aby mi ten program ruszył...

    Co do stosowania nowych nazw - OK zgadzam się w 100% i tak też robię pisząc swoje programy, lecz akurat w tym przypadku był to kod oryginalny, nie mojego autorstwa (Elm Chan) i najpierw działało a potem nagle przestalo - i to mnie nurtuje dlaczego coś takiego miało miejsce... Zwłaszcza na uC tak pospolitym jak Mega32 ;)
REKLAMA