Forum: Mikrocontroller und Digitale Elektronik ATMega8 und ATMega16 - Geschwindigkeitsunterschied?


von Markus F. (nidhoegger)


Lesenswert?

Hi,

ich habe ein kleines Projekt, das sehr viele LEDs in einer Matrix 
Multiplexen muss und sehr viele schleifen immer wieder in einem Timer 
ausgeführt werden. Ich habe den code jetzt an jeder stelle, an der ich 
denke das es möglich ist, optimiert, soweit es geht (Space for Time). 
Nun habe ich immernoch ein ganz leichtes flackern in der matrix. Ich 
überlege auf einen ATMega16 (momentan ATMega8) umzusteigen. Bringt das 
mehr geschwindigkeit mit sich? Oder wie verhält sich das?

Bringt ein Quarz mehr geschwindigkeit? Momentan läuft der ATMega8 auf 
12Mhz, soweit ich weiß kann ich ja bis auf 16MhZ hoch. Sorry für die 
frage, ich bin einfach noch anfänger!

von Jiro (Gast)


Lesenswert?

Der Kern der beiden ist gleich nur die Ausstattung ist verschieden, 
bleibt nur die Möglichkeit den Takt anzuheben.

von Markus F. (nidhoegger)


Lesenswert?

Also einfach ein 16MhZ quarz reinstecken (mach das zum glück immer auf 
IC sockel ^^) und die timings im code anpassen...oder seh ich das 
falsch? Gehen bei einem 16mhz quarz die 27pF kondensatoren? bzw wie 
berechnet man die ohnehin?

von Thomas (kosmos)


Lesenswert?

die µC sind bei gleichem Takt auch gleich schnell. Jetzt ohne in die 
Datenblätter verglichen zu haben, müssten beide bis 16 MHz zugelassen 
sein. Die werden aber sicherlich auch mit 20 MHz laufen.

Wenn deine Geschwindigkeit unter der Schieberei leidet solltest du 
parallel Latches nehmen. Da kannst du mehrere parallel an einen Port 
hängen. Gibts die 8 Bit Daten raus und teilst über eine Steuerleitung 
Latch 1 mit es soll die Daten übernehmen, danach gibst du wieder andere 
Daten an den Port und forderst  Latch 2 zur Datenübernahme auf. Das 
machst du dann mit allen deinen Latches nacheinander und gibst dann mit 
einen Portpin das Signal an alle Latches das sie die übernommenen Daten 
jetzt an ihren Ausgängen ausgeben.

Aber vielleicht ist dein Programm einfach nur zu schlecht und bremmst 
dadurch alles aus.

von Markus F. (nidhoegger)


Lesenswert?

Nein ich denke da stößt der ATMega8 einfach an seine grenzen. Und ganz 
ehrlich: ich hab kein wort verstanden aus deinem beitrag, ich bin erst 
seit knapp ner woche mit µC programmierung dabei (und ca seit einem 
monat mit "projekte nachlöten").

Das problem ist: wenn der timer am zuge ist passiert:
2 ineinanderverschachtelte schleifen je von 0 bis 9, also 100 
schleifenschritte mit je max. 16 zuweisungen, abhängig von 16 ifs

dannach nochmal eine ähnliche schleife (ja, es ist zwingend, sie 
nacheinander laufen zu lassen!) mit 4 vergleichen und max. 10 
zuweißungen.

Ich denke dadurch entsteht das flacken, der ATMega ist mit dem Timer 
einfach zu lange zu gange, um ein flackerfreies anzeigen einer 10x10 LED 
Matrix anzuzeigen.

Hast du für deine idee vielleicht ein tutorial?

von Karl H. (kbuchegg)


Lesenswert?

Markus Foitschik schrieb:
> Nein ich denke da stößt der ATMega8 einfach an seine grenzen. Und ganz
> ehrlich: ich hab kein wort verstanden aus deinem beitrag, ich bin erst
> seit knapp ner woche mit µC programmierung dabei (und ca seit einem
> monat mit "projekte nachlöten").
>
> Das problem ist: wenn der timer am zuge ist passiert:
> 2 ineinanderverschachtelte schleifen je von 0 bis 9, also 100
> schleifenschritte mit je max. 16 zuweisungen, abhängig von 16 ifs
>
> dannach nochmal eine ähnliche schleife (ja, es ist zwingend, sie
> nacheinander laufen zu lassen!) mit 4 vergleichen und max. 10
> zuweißungen.

Zeigen

von gast2 (Gast)


Lesenswert?

> Ich habe den code jetzt an jeder stelle, an der ich
> denke das es möglich ist, optimiert, soweit es geht

Ich behaupte mal, das das so nicht absolut stimmen wird, weil:

> ich bin erst seit knapp ner woche mit µC programmierung
> dabei (und ca seit einem monat mit "projekte nachlöten").

Oder anders gesagt:

Quelltext zeigen!

von horst (Gast)


Lesenswert?

> Ich habe den code jetzt an jeder stelle ... optimiert
schön, wenn das dein hobby ist.
Hast du auch kontrolliert, ob/was deine Optimierung gebracht hat? Dann 
lernst du wenigstens daraus.

> Ich habe den code ... optimiert
Für einen Anfänger der falsche Ansatz.
Versuche, die Struktur zu optimieren.
z.B.:
> wenn der timer am zuge ist passiert
> [lange Liste die ich mir nicht durchgelesen habe]
Muß das wirklich dann geschehen, wenn der Timer am Zug ist?
Wenn das Umschalten auf die gewünschten LEDs erst (Hausnummer) 3 
Timerzyklen später erfolgt, kann dass dann irgendwer mit freiem Auge 
erkennen?
Ich würde die Berechnung, welche LED leuchten soll, nicht im 
Timerinterrupt sondern in der Hauptroutine unterbringen. (oder in einem 
eigenen Task, falls ich soetwas wie AvrX verwende.) Natürlich muß man 
dann aufpassen, dass die Hauptroutine irgendwo anders nicht längere Zeit 
"hängt", z.B. warten auf eine Eingabe anstatt immer wieder abzufragen, 
ob die Eingabe erfolgt ist.

Tip: In Interruptroutinen immer nur dass, was unbedingt dort nötig ist.
Tip: Recherchiere, wie du mit einer State Machine in einer Routine 
mehrere Aufgaben parallel erfüllst. Es wird dazu wahrscheinlich nötig 
sein, deine Aufgaben in Teilaufgaben zu unterteilen, die nach einander 
abgearbeitet werden, damit dazwischen eine andere Teilaufgabe 
eingeschoben werden kann.

von Peter D. (peda)


Lesenswert?

Markus Foitschik schrieb:
> Ich habe den code jetzt an jeder stelle, an der ich
> denke das es möglich ist, optimiert, soweit es geht (Space for Time).

Code optimieren bringt nur wenig.
Den Programmablauf zu optimieren bringt dagegen sehr viel.
Du hast also an der falschen Sache optimiert.

Du must überlegen, was wirklich eilig ist (PWM im Timerinterrupt) und 
was garnicht so häufig oder dringend gemacht werden muß (neue PWM-Werte 
setzen).

Es bringt auch was, wenn Du mal in allen Einzelheiten beschreibst, was 
der Code genau machen soll. Es bringt Dir sogar was, wenn keiner drauf 
antwortet.


Peter

von Peter R. (pnu)


Lesenswert?

Wichtig ist der zeitliche Ablauf bei der Umschaltung.
Es darf nicht in der Reihenfolge geschehen:

Stelle ausgeben-rechnen-Segment ausgeben-rechnen-Stelle ausgeben-denn 
in den Rechenzeiten leuchten die Segmente an der alten Stelle kurzzeitig 
auf, bis die neue Stelle aktiv wird.

Also:

Segmente für neue Stelle berechnen-alte Stelle abschalten-Segmentmuster 
übergeben-neue Stelle einschalten-....

Wenn da in der Abfolge etwas nicht stimmt, leuchten Nachbarsegmente 
ungewollt auf, da sie in der Umschaltezeit Segmente der Nachbarstelle 
mit anzeigen.

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.