[C][ATMEGA16] - Wymiana atmega16 na atmega32 lub 644 lub 1284

Witam państwa. Mam szybkie pytanie. Skonstruowałem układ na atmega16 podłączyłem wszystko wgrałem program(90% zajętości pamięci) lecz przejście całego programu trwa koło sekundy, to zdecydowanie za długo szczególnie ze chce jeszce dodać TIMER i strasznie go muli. Zwykłe dodanie na końcu programu n++ i wyświetlenie n, inkrementuje go co sekundę. (nie mam żadnych _delay_ms w kodzie. ani pętli opóźniających, tylko jedna while(1))

W związku z tym, czy jeżeli wymienię atmegę na szybszą, np atmega32, atmega644 czy nawet atmega1284 czy odmuli trochę program? Czy piny wszystkie będą mi pasować (wystarczy wpiąć nowszy w podstawkę i zaprogramować? )

A w jakim znaczeniu mega32 jest szybsza od 16? Rdzeń procesora jest ten sam i max. częstotliwość poprawnej pracy także. Nowsze megi mają co prawda podniesione o 4MHz (20 vs 16) a xmegi nawet do 32MHz, ale jeśli jest kolega pewien, że program zawsze robi to co musi i aż tyle czasu to zajmuje to zastanowiłbym się nad analizą co ile czasu zajmuje i ewentualnie optymalizacją, a większy MCU wziąć tylko jeśli się nie zmieści już wsad do mega16. Nie wiem co kolegi program robi, ale możliwe, że samo przejście na xmega mogłoby część rzeczy usprawnić (np. event system czy dma odciążające procesor) ale jeśli w programie są jakieś skomplikowane obliczenia na floatach to nie ma się co łudzić.
Co do kompatybilności - trzeba zwrócić uwagę czy różnice między rodzinami będą musiały wymagać zmian w programie. Trzeba przyjrzeć się odpowiednim dokumentom atmela. Np. http://www.atmel.com/Images/doc8001.pdf

Reasumując - daj znać co to za program i co rozumiesz przez "przejście programu"

jest to program stacji pogodowej. Załączone sa biblioteki z czujnikow cisnienia, pola magnetycznego, temperatury i wilgotności. W głównym programie main są instukcje wywołujące je na wyświetlacz LCD. Jeśli usunę z programu kilka czujników odświeżanie pomiarów jest bardzo szybkie, dodając pozostałe czujniki i wyświetlanie ich na LCD spowalnia atmegę i już pomiary są co sekundę. chcę wypiąć z podstawki atmega16 i wpiąć inną i ciekaw jestem czy to przyspieszy jego pracę.

A z jakiego powodu miałoby przyspieszyć, jeżeli chcesz użyć takiego samego procesora pracującego z taką samą częstotliwością? Procesor we wszystkich ATmega jest ten sam.

@rav88pl - skoro taki program zażyna ci MCU, to powiem brutalnie, może się obrazisz, ale kiedyś dojedziesz do etapu, kiedy przyznasz mi rację - skasuj czym prędzej ten program i napisz go od nowa.
Domyślam się, że w twoim programie dominują różne delay lub aktywne czekanie a określony stan czujników, w efekcie program 99% czasu spędza w martwej pętli. Pokaż przykładową obsługę jednego z czujników... Jeśli mam rację, to nawet wykorzystanie MCU taktowanego 180 MHz nic nie zmieni, bo problem leży gdzie indziej.

nie obrażę się, moze i masz rację, optymalizacja kodu jest niezbyt dobra, ale przyznam szczerze, siedzę nad tym kodem parę dobrych miesięcy, orłem nie jestem, a obronę pracy dyplomowej mam za miesiąc, nie mogę sobie pozwolić na skasowanie kodu
wszystko działa pięknie, ale dodając czujnik hallotronowy, który działa właściwie jak przycisk, i zbliżenie do niego magnesu powinno np zliczać impulsy, to muszę trafić w moment czasowy kiedy w kodzie jest akurat analizowany warunek IF (stan wysoki na pinie), wtedy n++.

Bez pokazania kodu nikt ci nic nie poradzi. Wymiana jednej Atmegi na inną, jak już ci napisano nic nie da, bo taktowanie podciągniesz co najwyżej o 4 MHz (wymiana na XMEGA to istotna przeróbka kodu), ale zmiana taktowania i tak nic nie da, jeśli w programie masz pętle oczekiwania np. na gotowość z czujnika. Generalnie należałoby się skupić na porządnym napisaniu komunikacji z czujnikami z maksymalnym wykorzystaniem dostępnych w MCU peryferii.

kod umieszczony wyżej

Cytat:

double mx = 0;
double my = 0;
double mz = 0;

Czy to w avr-libc nie jest traktowane jak float (fp32)? Bo tak chyba w dokumentacji mi się otarło. Jak jest ten czas konwersji DSa rozwiązany? Tj. zlicza ci to jakiś timer, a w międzyczasie robisz coś innego jak rozumiem? Bo jeśli nie to masz pierwszego winowajcę.

Oj, przejrzałem pobieżnie kod - uwierz mi - skasuj go.
W C jest coś takiego jak funkcje - wykorzystaj to, kod, który masz jest kompletnie nieczytelny. Każdy normalny promotor by to coś uwalił chociażby za to.
Co do szybkości działania - pokaż kod funkcji odpowiedzialnych za komunikację z czujnikami. Z kodu, który masz:
- funkcjie piszące do LCD są zapewne blokujące, każda zajmuje niepotrzebnie dużo czasu MCU, można je zamienić na nieblokujące, wykorzystując przerwania,
- to samo dotyczy komunikacji po USART.
- przypuszczam, że kompletną tragedią są funkcje obsługi 1-wire. Jeśli jest tam chociaż jedno delay to masz główną przyczynę, która ci pochłania 99% czasu procesora. Nie wspominając o tym zakomentowanym _delay_ms(750) - na czas konwersji temperatury.
- przypuszczam, że ten sam problem dotyczy BMP085 - ten czujnik ma linię żądania przerwania nieprzypadkowo.
- kolejna sprawa - jeśli timer ma zliczać do 40 to ustaw odpowiedni tryb pracy timera, żeby sobie do tych 40 liczył, a nie jakieś if(CNT==40), bo to nawet nie działa tak jakbyś chciał. Nie prościej ustawić timer w tryb w którym top=40 i zrobić mu np. przerwanie overflow jak sobie doliczy do tej wartości? TCNT się wyzeruje samo, a ty sobie możesz np. w ISR zrobić co tam potrzebujesz przy tej okazji. To tylko na początek.
Wiele przykładów nieblokującej obsługi LCD, USART, czy 1-wire masz w darmowych przykładach do książki "Język C dla mikrokontrolerów AVR...".

timer zlicza czas w jakichś tam odstępach i dodaje do licznika +1. (wyeliminowano przepełnienia timera) . Jeśli jest impuls z halotronu (magnes kręci sie na łyżkach wiatromierza) to znaczy ze wykonano jeden obrót, i wtedy ten czas jaki zleciał do momentu przejechania magnesu, (np 1/50 sekundy) przeliczam na prędkość.

Tylko do tego timera używam.

Biblioteka DS to:

używam standardowych bibliotek z internetu i w nich nic nie zmieniam.


Chodzi mi o to że nie zawsze łapie mi ten impuls z hallotronu na porcie atmegi.

tutaj



Jak wyczyszczę procesor z pozostałych instukcji idealnie załapije

Biblioteki z Internetu - hmm, mam swoje zdanie na ten temat, nie podzielę się nim, bo moderator by musiał ten post wrzucic do kosza, a i ostrzeżenie zapewne bym dostał
Zacznijmy od hallotronu - podepnij go pod pin, który generuje przerwanie i ustaw przerwanie z pinu na zbocze. W przerwaniu sobie zliczaj impulsy z hallotronu. Dodaj na wejście jakiś prosty filtr RC, żeby śmieci nie zbierał. Można oczywiście zakłócenia wyfiltrować programowo, czyli np. po wykryciu zbocza nie zliczać kolejnych impulsów przez czas równy minimalnemu sensownemu odstępami pomiędzy kolejnymi impulsami z Halla.
Co do 1-wire - masz oparte o manglowanie pinem IO - normalnie sensownie robi się to wykorzystując USART (kolega BlueDraco powiedziałby ci, że timer, też ok). Ale sama komunikacja nie trwa długo, więc to przyśpieszyłoby, ale trzebaby istotnie zmienić podejście do obsługi 1-wire. Po wydaniu polecenia CONVERT do czujnika, czekasz na zakończenie konwersji? Jeśl tak, to to czekanie usuń, nie jest potrzebne, gdyż do czasu zakończenia konwersji czujnik zwraca ostatnią zmierzoną temperaturę. Przy BMP085 już pisałem - masz przerwanie IRQ, któe się aktywuje po zakończeniu konwersji. Znowu - w funkcji obsługi tego przerwania odczytaj wynik. I2C też warto oprzeć o przerwania, z racji powolności tego interfejsu.
Kolega @tronics słusznie zauważył zmienne o typie zmiennopozycyjnym - przy tych czujnikach nie ma żadnych obliczeń uzasadniających ich użycie. Wszystko można policzyć na int/long przeskalowując współczynniki, a jak chcesz prosto i w miarę efektywnie to masz w gcc fixed-point math. Nie tylko obliczenia przyśpieszą 20-100 razy, ale program się odchudzi o kilka kB.
Nie aktualizuj też LCD na raty, bo to jest wolne - lepiej przygotować w pamięci wszystko co masz do wyświetlenia i wysłać na raz do VRAM, bez tych goto(x,y) itd. Możesz też skorzystać z nieblokującej biblioteki do LCD, którą zamieściłem w przykładach. Ale zacznij od obsługi czujników, bo tam spedzasz najwięcej czasu i tam kryje się duży potencjał do ulepszeń.

Czegoś tu nie rozumiem. Kolega Autor uważa że problemem jest szybkość działania procesora, czemu więc nie "podkręci zegara"? Ta atmega naprawdę chodzi na 1MHz (#define F_CPU), czy to niedopatrzenie? Swoją drogą definiowanie F_CPU za inkludem "delay.h" to jakoś tak... bez sensu do kwadratu

ten #define F_CPU podkreśla mi na żółto że jest bezsensu właśnie spróbuje popracowąć nad wskazówkami tmf ( dzięki bardzo) oraz jak podkręcić zegar?

Dodano po 2 [minuty]:




tutaj? Mogę bezkarnie zmienić tą wartość ? nic nie uszkodzę?

Tam powinieneś... #define F_CPU powinno być w ustawieniach projektu, a nie w samym pliku źródłowym. A podkreśla bo pewnie masz "redefine" (czyli zdefiniowane w kilku miejscach), albo jak wyżej napisane w złej kolejności.

Przy czym to #define F_CPU ma znaczenie tylko dla wyliczeń np. delay w programie. Kompletnie to nie wpływa na częstotliwość taktowania MCU, która zależy od podłączonego kwarcu i ustawień fusebitów.

To ja dołożę o bibliotekach z internetu, świeże doświadczenia, jak to dał się młody wyjadacz nabrać.
Mianowicie 2h stracone na szukaniu błędu w programie, zanim zajrzałem do "sprawdzonej przez użytkowników internetu" biblioteki, gdzie okazało się, że raz na ileś wywołań nadpisywała ona pamięć RAM - pozdrawiam