Hallo,
ich bin noch ein blutiger Anfänger in der Mikrocontrollertechnik. Ich
habe jetzt mit AVR Studio 5.1 und meinem ATMEL Evaluationsboard 2.01
mehrere kleine Assembler-Codes geschrieben und getestet, um eben zu
sehen, wie der Mikrocontroller reagiert und was man damit eben alles so
machen kann.
Ich habe zum Beispiel ein Zufallsgenerator geschrieben, der also von
00-11 zählt (weil eben erstmal nur 2 LED´s auf dem Board sind). Wenn man
aber Taster1 auf dem Board drückt, dann stoppt der Mikrocontroller mit
der Zählung und zeigt die Zahl dann an (z.B. 11=3).
Klingt zwar einfach, doch als ich dann den umgekehrten "Effekt" haben
wollte (sprich, wenn ich drücke zählt der Mikrocontroller durch und wenn
ich eben nicht drücke, dann zeigt er mir die Zahl an), kam es zu einem
merkwürdigen Problem:
Wenn ich drücke, dann oszilliert der µC brav durch, doch wenn ich die
Taste1 nicht mehr drücke, dann gibt er immer die binäre Zahl 2 (=10)
aus.
Das verstehe ich nicht...
Kann mir da jemand helfen?
Hier mal die beiden Codes. Der erste ist der funktionierende (nicht
drücken=oszillieren) und unten der nicht funktionierende
(drücken=oszillieren).
Mir ist schon klar, dass es dafür Tutorials gibt und ich den Code auch
anders realisieren kann. Doch bis jetzt habe ich immer meine eigenen
Fehler gefunden. Nur eben bei diesem Code noch nicht.
Später realisiere ich so eine Schaltung vllt. anders, aber jetzt würde
ich gerne wissen, >>was an dem Code falsch ist<<. Mehr nicht.
Danke im Voraus!
Das ist statischer Code. Wo soll der Zufall bleiben ? In diesem Code
sicher nicht. Zieh dir mal die rueckgekoppelten Schieberegister rein :
Xilinx Application notes 210, 211, 217 & 220 ( XApp210.pdf, XApp211.pdf,
XApp217.pdf, XApp220.pdf )
zB
http://www.xilinx.com/support/documentation/application_notes/xapp210.pdf
Gut..ich gebe ja zu, dass das auf jeden Fall ein Pseudozufallsgenerator
ist und das eben kein "wirklicher" Zufall entsteht. Doch bei einer
Taktrate von 1 MHz kann kein Mensch in dem Moment drücken, wo er das
auch will.
Es ist also kein realer Zufallsgenerator.
Trotzdem weiß ich noch immer nicht, warum der µC immer eine 2 (=10)
ausgibt.
In der Theorie kann ich immer die selbe Zahl kriegen. Nicht aber in der
Praxis.
Deswegen nochmal: Warum funktioniert der untere Code nicht (s. oben).
Danke im Voraus!
Das Schieberegsiter ist auch statischer Code. Von dem weiss man aber wie
er sich verhaelt. Ein 20bit Schieberesister wiederholt sich nach 2^20 =
1 million bits. Mit 30 bit ist man bei einer Milliarde. In der genannten
Appnote gibt's noch laengere.
Stimmt. Denn wenn man nur einen Code hat, dann IST das ein PSEUDOZUFALL.
Man könnte nun aber auch sagen, wenn man einen Kondensator hat mit
starker Selbstentladung und mithilfe des z.B. ADC-Wandlers die Spannung
in einen Binärwert umwandelt und somit einen Zähler stoppt, der dann
eine Zahl ausgibt, dass dies ein Zufallsgenerator sei.
Doch mit physikalischen Formeln kann man ja auch die Selbstentladung des
Kondensators berechnen. Also ist auch die ein Pseudozufallsgenerator.
Und in der Theorie gibt es auf jeden Fall keine Zufälle.
Aber trotzdem wieder zurück zum Code:
Warum geht der zeite Code nicht bzw. warum gibt er IMMER 2 (=10) aus?
Danke im Voraus!
Nun, wenn Du dieses unnütze Geraffel hier
.equ IPA=PINA
.equ IPB=PINB
.equ IPC=PINC
.equ IPD=PIND
.equ OPA=PORTA
.equ OPB=PORTB
.equ OPC=PORTC
.equ OPD=PORTD
.equ DRA=DDRA
.equ DRB=DDRB
.equ DRC=DDRC
.equ DRD=DDRD
mal rückgängig machst und dazu den Code noch ein wenig kommentierst,
dann mache ich mir vielleicht die Mühe das mal anzuschauen. Und das
einzige wofür sich wirklich equs gelohnt hätten, nämlich für die 5, 6
und 2, hat keines. So ist es einfach Krampf.
Funktional im Moment nicht entscheidend aber dennoch wichtig für die
Zukunft: Es fehlt die Initialisierung der ISR-Vektoren.
Das hier kannst Du auch gleich mal rauslöschen. Ist überflüssig. Wenn
dieser Befehl unmittelbar vor der angesprungenen Marke kommt, dann ist
der Programmcounter ja schon da.
Näheres erklärt die Befehlsreferenz.
rjmp binaer0
...
rjmp binaer1
...
rjmp binaer2
...
rjmp binaer3
Zum Portd,2 , an dem die Taste angeschlossen ist:
Schau Dir nochmal an, wie solche eine Taste am Kontroller angeschlossen
werden muss (Hardware).
-und was in der Software für diese Taste getan werden muss.
Begriffe dabei : Eigenschaft offener Pins(ohne Beschaltung),
Störsicherheit, pull-up.
Also ich habe als erstes den internen Pull-up aktiviert --> das gleiche
Spiel.
Danach habe ich die Kondensatoren an den einzelnen Tastern auf dem ATMEL
Evaluations-Board entfernt --> das gleiche Spiel.
An den internen Pull-up kann es also nicht liegen.
Wo liegt bloß der Fehler? Ist eurer Meinung nach der Code also richtig?
Danke im Voraus!
Hi!
Die Frage ist gut gestellt. Gleich mit Source Code und verwendetem
Board.
Mir gefällt auch, dass du was lernen möchtest.
Versuch das Programm mal folgendermaßen aufzubauen: Das Programm läuft
wie bisher die ganze Zeit durch. Allerdings werden die Pins P5 und P6
für die LEDs nur geändert wenn die Taste gedrückt ist. Falls sie nicht
gedrückt ist, werden die Befehle für das Setzen der Pins übersprungen.
Gruß
Nachtrag:
Ist das hier das besagte Board?
http://www.pollin.de/shop/downloads/D810074B.PDF
Falls ja, dann haben die Taster bereits einen Pull Down Widerstand
(R7, R8, R11). Du solltest also die internen Pull Up Widerstände
deaktivieren. Entweder nur Pull Up oder nur Pull Down, aber nicht beides
gemischt.
Wenn der Taster gedrückt ist, dann sieht der Controller Low.
Wenn der Taster nicht gedrückt ist, dann sieht der Controller High.
Gruß
Der schrieb:> Nachtrag:>> Ist das hier das besagte Board?> http://www.pollin.de/shop/downloads/D810074B.PDF> Falls ja, dann haben die Taster bereits einen Pull Down Widerstand> (R7, R8, R11). Du solltest also die internen Pull Up Widerstände> deaktivieren. Entweder nur Pull Up oder nur Pull Down, aber nicht beides> gemischt.>> Wenn der Taster gedrückt ist, dann sieht der Controller Low.> Wenn der Taster nicht gedrückt ist, dann sieht der Controller High.>> Gruß
Hallo Der,
ist zwar freundlich, dass du es schön findest, dass ich das mache, aber
bei einer Sache liegst du falsch!
Wenn man den Taster drückt, dann sieht der Controller HIGH und nicht LOW
(s. Seite 6 beim Datenblatt des Boards).
Siehst du vllt. den Fehler an dem Code?
1
.include "m32def.inc"
2
sbi DDRD,5
3
sbi DDRD,6
4
cbi DDRD,2
5
// Hier beginnt das Hauptprogramm
6
rjmp binaer0
7
binaer0:
8
// binaere 0 laden
9
cbi PORTD,5
10
cbi PORTD,6
11
// Wenn Taster1 gedrueckt, dann gehe zur naechsten Sprungmarke
12
// ansonsten gehe zur aktuellen (binaer0) Sprungmarke
Wie gesagt, schreibe das Programm um, und zwar so, dass die Ports nur
geändert werden, wenn der Taster gedrückt ist. Die LEDs zählen dann 00
bis 11 durch. Wenn der Taster nicht gedrückt wird, dann werden die Ports
nicht geändert und behalten ihren vorherigen Wert. Die Anzeige bleibt
also bei einer zufälligen Zahl stehen.
Philipp Buchmann schrieb:> Wenn man den Taster drückt, dann sieht der Controller HIGH und nicht LOW
Stimmt, habe ich falsch gesehen.
>Wie gesagt, schreibe das Programm um, und zwar so, dass die Ports nur>geändert werden, wenn der Taster gedrückt ist.
Ehm, das ist seine funktionierende Ausgangssituation...
Um es kurz zu machen: Im Code kann ich keine Fehler entdecken. An deiner
Stelle wäre mein nächster Schritt das Programm mal im Simulator des
AVR-Studios laufen zu lassen. Erst normal, dann Schritt für Schritt.
Funktioniert es dort ohne Probleme liegt es auch erstmal nicht am Code.
Denke auch daran dass ein AVR auf einem PIN mehrere Funktionen zur
Verfügung stellt. Eventuell ist hier etwas im Hintergrund ungewollt in
Betrieb was stört. Hänge die Ein und Ausgänge einfach mal auf komplett
andere Pins.
Also, ich habe endlich den Fehler gefunden, wobei es ein sehr, sehr
merkwürdiger Fehler ist:
Wenn ich Zeitschleifen setze, dann funktioniert das ganze:
1
.include "m32def.inc"
2
sbi DDRD,5
3
sbi DDRD,6
4
cbi DDRD,2
5
// Hier beginnt das Hauptprogramm
6
rjmp binaer0
7
binaer0:
8
// binaere 0 laden
9
cbi PORTD,5
10
cbi PORTD,6
11
// Zeitschleife Anfang
12
ldi r17, $09
13
WGLOOP0:
14
ldi r18, $6E
15
WGLOOP1:
16
dec r18
17
brne WGLOOP1
18
dec r17
19
brne WGLOOP0
20
ldi r17, $01
21
WGLOOP2:
22
dec r17
23
brne WGLOOP2
24
// Zeitschleife Ende
25
sbis PIND,2
26
rjmp binaer0
27
rjmp binaer1
28
binaer1:
29
cbi PORTD,5
30
sbi PORTD,6
31
// Zeitschleife Anfang
32
ldi r17, $09
33
WGLOOP0:
34
ldi r18, $6E
35
WGLOOP1:
36
dec r18
37
brne WGLOOP1
38
dec r17
39
brne WGLOOP0
40
ldi r17, $01
41
WGLOOP2:
42
dec r17
43
brne WGLOOP2
44
// Zeitschleife Ende
45
sbis PIND,2
46
rjmp binaer1
47
rjmp binaer2
48
binaer2:
49
sbi PORTD,5
50
cbi PORTD,6
51
// Zeitschleife Anfang
52
ldi r17, $09
53
WGLOOP0:
54
ldi r18, $6E
55
WGLOOP1:
56
dec r18
57
brne WGLOOP1
58
dec r17
59
brne WGLOOP0
60
ldi r17, $01
61
WGLOOP2:
62
dec r17
63
brne WGLOOP2
64
// Zeitschleife Ende
65
sbis PIND,2
66
rjmp binaer2
67
rjmp binaer3
68
binaer3:
69
sbi PORTD,5
70
sbi PORTD,6
71
// Zeitschleife Anfang
72
ldi r17, $09
73
WGLOOP0:
74
ldi r18, $6E
75
WGLOOP1:
76
dec r18
77
brne WGLOOP1
78
dec r17
79
brne WGLOOP0
80
ldi r17, $01
81
WGLOOP2:
82
dec r17
83
brne WGLOOP2
84
// Zeitschleife Ende
85
sbis PIND,2
86
rjmp binaer3
87
rjmp binaer0
Ich habe die Zeitschleifen mit einem Zeitschleifengenerator erzeugt.
Jetzt sieht man wenigstens, dass die LED blinkt (wenn auch sehr schnell)
und man kann auch mal andere Zahlen, als nur die 2 (=10) bekommen.
Danke nochmal für eure Hilfe.
Hm, das ist schonmal ein Ansatz, aber leider keine Lösung.
Du hast ja selber geschrieben, dass du wissen willst wie ein
Mikrocontroller funktioniert. Offenbar hast du in deinem gesamten Aufbau
irgendeinen Fehler. Die Symptome des Fehlers hast du durch einen
Workaround behoben. Gewöhne dir so etwas besser nicht an. Das Ergebnis
wird sonst sein, dass du zukünftig sehr wartungsintensiven
fehleranfälligen Code schreibst. Denn wer sagt dir, dass wenn du nun den
Code erweiterst und noch ein paar weitere Zeilen hinzufügst, der Fehler
nicht wieder auftritt?
Fehler sind dazu da um zu lernen, und wenn du wirklich die Ursache
rausgefunden hast, wird dieser Fehler nicht so schnell wieder passieren.
Hast du den Code mal im Simulator laufen lassen, oder andere I/O-Pins
probiert?
Higg G. schrieb:> Offenbar hast du in deinem gesamten Aufbau> irgendeinen Fehler.
Es ist in der Tat ein komischer Fehler. Aber da es ein Evaluationboard
ist, wird die Platine an sich wohl in Ordnung sein. Ein Kurzschluss
zwischen den LEDs kann es eigentlich nicht sein, da sie sich einzeln
ansteuern lassen.
Wenn ich mir den Code aus dem Startpost ansehe fällt mir was auf:
1
...
2
binaer0:
3
cbi OPD,5
4
cbi OPD,6
5
...
Dieser Teil wird (wenn ich es richtig sehe) immer ausgeführt, also
unabhängig vom Taster. Allerdings müssten dann die LEDs immer aus sein.
Mysteriös...
Der schrieb:> Falls ja, dann haben die Taster bereits einen Pull Down Widerstand
Wer kommt denn auf solche sch*achsinnigen Ideen?
Die Kurzschlußströme, die bei jedem Tastendruck auf die
330nF-Kondensatoren fließen (C17,C18,C19), die Kontakte verbratzeln und
die Versorgungsspannung einbrechen lassen, möchte ich gar nicht sehen.
Dein MC ist zu schnell,deine Hand zu langsam, darum gehts auch mit den
Verzögerungen.
cbi PORTD,5
cbi PORTD,6
cbi PORTD,5
sbi PORTD,6
sbi PORTD,5
cbi PORTD,6
usw.
wie will man da etwas sehen
Kartoffelbauer schrieb:> Dein MC ist zu schnell,deine Hand zu langsam, darum gehts auch mit den> Verzögerungen.>> ...>> wie will man da etwas sehen
Das ist ja der Witz an der Sache! Es geht so schnell das man nicht bei
der Zahl anhalten kann, die man gerade möchte.
Wenn die Zahlen nur im Sekundentakt wechseln, dann kann man die Zahl
"würfeln", die man gerade braucht.
Der schrieb:> Higg G. schrieb:>> Offenbar hast du in deinem gesamten Aufbau>> irgendeinen Fehler.>> Es ist in der Tat ein komischer Fehler. Aber da es ein Evaluationboard> ist, wird die Platine an sich wohl in Ordnung sein. Ein Kurzschluss> zwischen den LEDs kann es eigentlich nicht sein, da sie sich einzeln> ansteuern lassen.>> Wenn ich mir den Code aus dem Startpost ansehe fällt mir was auf:...> binaer0:> cbi OPD,5> cbi OPD,6> ...> Dieser Teil wird (wenn ich es richtig sehe) immer ausgeführt, also> unabhängig vom Taster. Allerdings müssten dann die LEDs immer aus sein.>> Mysteriös...
Hmm...also, dass ist völlig korrekt, was du sagst, aber warum ist das
denn mysteriös?? Also dieser Codeteil geht auf jeden Fall. Es ist ja
schließlich egal, ob der PORTD Bit 5 und 6 dauernd entfernt werden.
Kommt ja immer auf dasselbe hinaus.
>@Philipp Buchmann>>Hast du das Board selbst zusammengelötet?
Nein, das Board habe ich als Bauteil gekauft. Alles schon
zusammengelötet.
Der schrieb:> Kartoffelbauer schrieb:>> Dein MC ist zu schnell,deine Hand zu langsam, darum gehts auch mit den>> Verzögerungen.>>>> ...>>>> wie will man da etwas sehen> Das ist ja der Witz an der Sache! Es geht so schnell das man nicht bei> der Zahl anhalten kann, die man gerade möchte.> Wenn die Zahlen nur im Sekundentakt wechseln, dann kann man die Zahl> "würfeln", die man gerade braucht.
Genau! Also, ich möchte, dass man die Zahl eben zufällig "würfelt".
Wäre doch bescheuert, wenn die LED im Sekundentakt oszillieren würde. Da
würde ja jeder bei Mensch-ärgere-dich-nicht o. ä. gewinnen :D.
> könntest du folgenden Code testen?
Der Code ist zwar nicht schlecht, aber leider entspricht er die Funktion
meines ersten funktionierenden Codes:
1
// "include"-Dateien laden
2
.include "m32def.inc"
3
// Variablen deklarieren
4
.def temp=r16
5
.equ IPA=PINA
6
.equ IPB=PINB
7
.equ IPC=PINC
8
.equ IPD=PIND
9
.equ OPA=PORTA
10
.equ OPB=PORTB
11
.equ OPC=PORTC
12
.equ OPD=PORTD
13
.equ DRA=DDRA
14
.equ DRB=DDRB
15
.equ DRC=DDRC
16
.equ DRD=DDRD
17
// Datenrichtungsregister definieren
18
sbi DRD,5
19
sbi DRD,6
20
cbi DRD,2
21
// Hauptcode
22
rjmp binaer0
23
binaer0:
24
cbi OPD,5
25
cbi OPD,6
26
sbis IPD,2
27
rjmp binaer1
28
rjmp binaer0
29
binaer1:
30
cbi OPD,5
31
sbi OPD,6
32
sbis IPD,2
33
rjmp binaer2
34
rjmp binaer1
35
binaer2:
36
sbi OPD,5
37
cbi OPD,6
38
sbis IPD,2
39
rjmp binaer3
40
rjmp binaer2
41
binaer3:
42
sbi OPD,5
43
sbi OPD,6
44
sbis IPD,2
45
rjmp binaer0
46
rjmp binaer3
> Die Symptome des Fehlers hast du durch einen> Workaround behoben. Gewöhne dir so etwas besser nicht an.
Genau das ist ja das Schlimme. Alle Codes, die ich bis jetzt geschrieben
habe (nur kleine Codes wie T-FlipFlop, D-FlipFlop, Blinkprogramme,
Inverter, Folger etc.) funktionierten. Nur dieser nicht.
Und das noch schlimmere ist: ich habe noch immer nicht den eigentlichen
Fehler gefunden.
Denn wie schon gesagt: aus reiner Logik muss mein Code funktionieren und
das haben ja schon einige aus dem Forum bestätigt.
Ich bin neugierig: Die meisten von euch (oder alle, damit ich keinen
beleidige :D) haben doch bestimmt mehr Erfahrung und viele Projekte
gemacht.
Kann mir nicht einmal einer von euch "Würfel-Projekte" schicken bzw. in
das Forum posten?
Danke im Voraus!
Philipp Buchmann schrieb:> Denn wie schon gesagt: aus reiner Logik muss mein Code funktionieren
Sehe ich nicht so... Dein "Würfel" hat keinen stabilen Zustand und
deshalb gibt es nur zwei (sichtbare) Zustände:
- Taster dauerhaft gedrückt
- Taster dauerhaft losgelassen
(jeweils vorausgesetzt die Hardware stimmt)
Das es noch jeweils zufällige Zwischenstände gibt sei mal unbestritten,
diese siehst du nur nicht schnell genug.
Ein Würfel ist doch perfekt um sich mal mit Timer und Interrupt zu
beschäftigen:
- Ein 8bit Timer der immer durchläuft
- Ein Taster am Interrupt Pin
- Im (Tasten)Interrupt den Zählerstand auf einen Port mit LEDs ausgeben
Das der Taster prellt ist hier auch erst mal egal, und bei jedem
Tastendruck wirst du dann eine neue zufällige Zahl auf den LEDs haben.
Wenn du das dann noch auf die Zahlen 1-6 Einschränken willst kann man
sich gleich im Anschluss mal mit dem CTC Modus beschäftigen und je nach
gewürfelter Zahl 1-6 LEDs leuchten lassen.
Der schrieb:> Higg G. schrieb:>> Offenbar hast du in deinem gesamten Aufbau>> irgendeinen Fehler.>> Es ist in der Tat ein komischer Fehler. Aber da es ein Evaluationboard> ist, wird die Platine an sich wohl in Ordnung sein.
Nein, ist es nicht.
Dass der Anschluss der Taster auf dem Pollin Board schwachsinnig ist,
ist bekannt. Dass dieser Anschluss zu allerlei Fehlverhalten führt auch.
Bau dein Board entsprechend um, so dass es so funktioniert, wie die
restliche Welt Tasten anschliesst:
Der Taster schaltet den Pin nach GND durch und du musst am Portpin den
Pullup einaschalten. Ein nicht gedrückter Taster liefert dann eine 1,
ein gedrückter Taster eine 0.
Zum Umbau
Beitrag "design fehler am atmel evaluations-board - programm stuerzt ab"Beitrag "Pollin AVR Board Fehler beim drücken der Taster / Qualität der Bauteile"
Entschuldigt meine Frage
Aber was wird das eigentlich?
Ein Wettbewerb für
Wie kann ich möglichst kompliziert in einer Schleife von 0 bis 3
(respektive 0 bis 5) zählen, solange eine Taste gedrückt ist und nach
dem Loslassen den letzten Zählerastand anzeigen bis die Taste erneut
gedrückt wird?
Karl Heinz Buchegger schrieb:> solange eine Taste gedrückt ist und nach> dem Loslassen den letzten Zählerastand anzeigen bis die> Taste erneut gedrückt wird?
Das Problem ist eben es gibt nicht den Zustand "bis die Taste erneut
gedrückt wird" sondern das rauscht fröhlich durch...
Läubi .. schrieb:> Karl Heinz Buchegger schrieb:>> solange eine Taste gedrückt ist und nach>> dem Loslassen den letzten Zählerastand anzeigen bis die>> Taste erneut gedrückt wird?> Das Problem ist eben es gibt nicht den Zustand "bis die Taste erneut> gedrückt wird" sondern das rauscht fröhlich durch...
Für einen simulierten Würfel passt das doch.
Karl Heinz Buchegger schrieb:> Für einen simulierten Würfel passt das doch.
Naja aber nicht ohne Entprellung und "Endzustand", im Moment rasselt das
wohl einfach durch, sodass man immer im gleichen Zustand landet.
Läubi .. schrieb:> Karl Heinz Buchegger schrieb:>> Für einen simulierten Würfel passt das doch.>> Naja aber nicht ohne Entprellung
Darüber hab ich auch mal ein wenig nachgedacht. Die Frage ist: in wie
weit verfälscht das Prellen eigentlich die Zufälligkeit.
Ich bin zu keiner eindeutigen Antwort gekommen. Auf der einen Seite hat
man durch das Prellen keine eindeutig definierte 'Niederdrückzeit' mehr.
Auf der anderen Seite schafft es sowieso kein Mensch eine Taste auf ein
paar µs genau zu drücken.
Im Moment denke ich, es spielt keine Rolle. Die Ergebnisse sind deswegen
nicht schlechter. Obwohl. Bei Zufallszahlen muss man vorsichtig sein.
Die Verteilung ist schnell zerstört bzw. man hat einen Bias drinnen.
> wohl einfach durch,
genau so hätte ich das auch angedacht. Und da kein Mensch eine Taste
gezielt auf µs genau in der Zeitdauer drücken kann, kriegt man bei jedem
Druck ein anderes Ergebnis.
while( 1 )
{
if( key_is_pressed )
{
cube++;
if( cube == 6 )
cube = 0;
}
display( cube + 1 );
}
Ich nutz einfach aus, dass man als menschlicher Benutzer nicht gezielt
steuern kann, wieviele Durchläufe durch die Schleife gemacht werden.
Karl Heinz Buchegger schrieb:> Im Moment denke ich, es spielt keine Rolle. Die> Ergebnisse sind deswegen> nicht schlechter.
Das nicht, der TE hat aber einfach die Sprungbefehle getauscht anstelle
sbic durch sbis zu ersetzen, so wie du es in C gemacht hast wäre auch
mein Ansatz und dann ist das prellen auch egal.
Du brauchst eine Statemaschine, sonst ist das nur ein wirres
Umhergespringe, wo keiner durchsieht.
Eine gleiche Warscheinlichkeit ist in der Tat nicht trivial. Ich benutze
daher einen Timerinterrupt zum Einlesen des Loslassens. Damit ist die
Warscheinlichkeit für jede Ziffer gleich und unabhängig von der
Mainloop.
Die Mainloop macht nur die Statemaschine.
Um den Eindruck zu erwecken, man könnte den Würfel manipulieren, läuft
der sichtbare Würfel extra langsam. Der eigentliche Würfel läuft aber
unsichtbar, erst wenn der sichtbare Würfel ausgerollt ist, sieht man
ihn.
Der C-Code läßt sich leicht auf einen AVR anpassen.
Peter
Thread beobachten
Seitenaufteilung abschalten