Hallo, ihr Wissende. Ich habe ein Verständnisproblem mit dem Bascom Befehl RND() Ich habe an einem Tiny13 5 LED an den Ausgängen. Das Programm ... Dim Z as Word Config PORTB = OUTPUT Do Z=RND(8) Z=Z+1 PORTB=Z Wait 1 Loop Die LEDs blinken auch lustig vor sich hin, aber mir sind zwei Sachen aufgefallen, die ich mir nicht erklären kann. - alle LEDs aus. Z sollte wenigstens 1 sein und damit LED an PB.0 leuchten. - alle LEDs an. Z sollte nicht größer 8 sein und damit LED an PB.4 dunkel. Jetzt suche ich jemand, der aus dem Wald,den ich nicht sehe, ein Brett hat, das er mir auf den Hinterkopf schlägt, damit mir ein Licht aufgeht. Schon mal vielen Dank im voraus. deka65
Detlef K. schrieb: > Hallo, ihr Wissende. > Ich habe ein Verständnisproblem mit dem Bascom Befehl RND() > Ich habe an einem Tiny13 5 LED an den Ausgängen. wie sind die LED angeschlossen? Sind die nach Vcc oder nach GND verschaltet? Wenn ersteres (und das ist oft so, dass deine PB.4 leuchtet, ist ein Indiz dafür), dann dreht sich alles um. Aber probiers einfach aus. Led eine 1 auf den PORTB (und sonst nichts). Welche LED leuchten?
:
Bearbeitet durch User
hallo, danke für die Antworten. @ karl heinz Portpin -> LED -> Widerstand -> GND Das mit PB.4 habe ich noch nicht verstanden. Da brauche ich noch Nachhilfe. deka65
Detlef K. schrieb: > hallo, > danke für die Antworten. > @ karl heinz > Portpin -> LED -> Widerstand -> GND > > Das mit PB.4 habe ich noch nicht verstanden. > Da brauche ich noch Nachhilfe. Wenn deine LED anders rum angeschlossen sind, dann wäre es völlig normal, dass bei einer Ausgabe der Zahlen von 0 bis 15 eine LED an PB.4 leuchten würde. Denn in dem Fall wäre das Bit 4 ja 0, was die LED (die am anderen Ende an Vcc angeschlossen ist) zum leuchten brächte. Hast du denn schon versucht, was passiert, wenn du einfach nur ein PORTB = 1 machst? welche LED leuchten dann?
Hallo, karl heinz habe gerade Z=1 programmiert. LED an PB.0 leuchtet, und nur die. Ich habe nochmal überprüft, ob ich nicht doch eine LED verpolt habe (kann ja mal passieren), ist aber nicht. deka65
Dann würde ich mal auch andere 2-er POtenzen probieren. Vielleicht hast du ja irgednwo ungewollte einen Kurzschluss produziert. Als Grundannahme können wir, denke ich, mal davon ausgehen, dass RND genau das tut, was es soll. D.h. wenn deine PB.4 leuchtet, was aber nicht möglich ist, wenn deine Berechnung keine Werte größer 8 produzieren kann, dann muss es ein anderes Problem geben.
Ich weiß zwar nicht, ob es daran liegt, aber PortB ist 8 bit breit und Z ist 16 bit breit - kannst ja Z mal als Byte deklarieren oder schreiben "PortB = low(z)" - vielleicht hilft's.
Oder Du hast den alten Fehler gemacht und bei 1 statt bei 0 angefangen die Beinchen zu zählen - denn eigentlich müssten es doch 6 LED sein? Wenn Du Reset nicht als Pin benutzt, stimmt's wieder..
:
Bearbeitet durch User
Karl H. schrieb: > was aber > nicht möglich ist, wenn deine Berechnung keine Werte größer 8 > produzieren kann, dann muss es ein anderes Problem geben. RDN(8) produziert doch eine Zahl von 0..7, richtig? Und wenn jetzt diese Zahl incrementiert wird, kann doch sehr wohl eine 8 dabei rauskommen. Detlef K. schrieb: > Z=RND(8) > Z=Z+1
hallo, ich habe jetzt mal eine For next Schleife von 0 bis 16 gemacht und damit PORTB angesteuert. Die LEDs leuchten jetzt "binaer". Alles so,wie es sein soll. Ich gehe jetzt davon aus, das die Hardware in Ordnung ist. Ich teste jetzt mal aus, was passiert, wenn ich PORTB=low(Z) programmiere. Das klärt aber noch nicht die Frage, warum Z >8 bzw Z=0 wird. ich melde mich wieder. deka65
Detlef K. schrieb: > Das klärt aber noch nicht die Frage, warum Z >8 bzw Z=0 wird. Weil
1 | RND(8) |
eine Integer-Zahl zwischen 0 und 7 liefert. Und als nächstes hast du
1 | Z=Z+1 |
stehen. Dadurch kommt die Zahl in den Bereich von 1..8!
Hallo, Ich habe jetzt das Programm dahingehend geändert, das PORTB=LOW(Z) ist. Ergebnis =0 . Es sind immer noch alle LEDs aus (Z=0) bzw alle LEDs an(Z>15). Nach meinem Verständnis sollte der Wert von Z zwischen 1 und 8 liegen. (Z=RND(8) -> Z=0 ->7) (Z=Z+1) -> Z=1 ->8) Wo ist jetzt der Fehler ? Liegt's an mir, am Programm, am Tiny oder an Bascom ? I don't know deka65
ist schon seltsam. das dünne Brett wäre noch do Z=RND(8) Z=Z+1 loop until Z < 9 :-)
1 | dim z as byte |
2 | |
3 | do
|
4 | z = rnd(7) + 1 |
5 | portb = z |
6 | wait 1 |
7 | loop
|
Da muss rauskommen, dass immer mindestens 1 LED an portB.0 bis .2 (!!) leuchtet. Falls du portB.0 bis .3 haben willst, also mindestens 1 aus 4 LEDs, dann rnd(15) statt rnd(7) schreiben. PortB.4 soll eigentlich erst leuchten bei rnd(31).
Hallo, Rainer U. schrieb: > do > Z=RND(8) > Z=Z+1 > loop until Z < 9 Versteh ich jetzt nicht ganz . Warum soll ich loopen bis Z kleiner 9 ist ? Mir ist aber noch eingefallen, wenn keine LED leuchtet, kann das ja auch 32 ,64, oder 128 sein. Das erklärt aber immer noch nicht, warum die RND funktion überhaupt Werte größer 7 ausgibt. ; ) ich wohne Paterre, da lohnt Fenstersturz nicht ; ) Humor ist, wenn man trotzdem lacht . deka65
wenn mehrere gleichzeitig leuchten dürfen/sollen: Do Z=RND(15) Z=Z+1 PORTB=PORTB AND &B0100000 PORTB=PORTB OR Z Wait 1 Loop ...oder wenn jeweils nur EINE leuchten soll: Do Z=RND(5) PORTB=PORTB AND &B0100000 PORTB.Z=1 Wait 1 Loop ...oder.... Do Z=RND(4) Z=2^Z PORTB=PORTB AND &B0100000 PORTB=PORTB OR Z Wait 1 Loop ...oder.... Do Z=RND(4) Dummy=1 Shift Dummy, Left, Z PORTB=PORTB AND &B0100000 PORTB=PORTB OR Z Wait 1 Loop
Hallo, Vielen Dank bis hierher an alle die bisher versucht haben, das Problem in den Griff zu bekommen. Aber bisher gehen alle Programmvorschläge davon aus, das der Bascom Befehl "RND(x)" auch funktioniert. Der Hintergrund meiner Frage geht aber weiter zurück. Ich habe ein Projekt, bei dem "zufällig" 2 LEDs unabhängig voneinander aus und wieder eingeschaltet werden sollen. Die ein-Zeit und die aus-Zeit wird über RND gesteuert. Ob nun die 1. oder 2. oder alle beide aus geschaltet werden, wird auch über RND gesteuert. Funktioniert soweit. Ich habe aber festgestellt, das immer nur die eine LED ausgeschaltet wird. Um den Fehler einzukreisen, habe ich den o.g Versuchsaufbau gemacht, um zu sehen, wie die Verteilung der "Zufallszahlen " ist. soweit zur Vorgeschichte . Ich habe festgestellt, das die Verteilung der Zahlen so schon in Ordnung ist. Aber wenn die Funktion auch Zahlen oberhalb des Frames (x) ausgibt, muß ich mein Projekt wohl nochmal überdenken. daher meine Frage zu Rnd im Thread, die mich langsam an mich zweifeln lässt. deka65
Detlef K. schrieb: > Aber wenn die Funktion auch Zahlen oberhalb des Frames (x) ausgibt, > muß ich mein Projekt wohl nochmal überdenken. Was allerdings in starkem Widerspruch zur Doku steht. Möglich ist natürlich alles, aber ich kann mir nicht wirklich vorstellen, dass der Hersteller so etwas einfaches wie eine Modulo-Division an dieser Stelle versaut hat.
Simpel schrieb: > PORTB=PORTB AND &B0100000 Wofür ist das? Soll bit 6 immer 1 sein? (was hier dann aber auch nicht garantiert ist)
"Aber wenn die Funktion auch Zahlen oberhalb des Frames (x) ausgibt, muß ich mein Projekt wohl nochmal überdenken." So intensiv habe ich RND(x) noch nicht untersucht. Aber es lässt sich leicht überprüfen, indem du eine PRINT-Ausgabe einer fortlaufenden RND-Zahlenreihe auf ein Terminalprogramm machst, oder den µC per Testroutine veranlasst, bei Frameüberschreitung der generierten Zahlen eine Fehler-LED einzuschalten... Dann siehst du, ob da ein Bug gegenüber der Doku exsitiert, oder alles paletti ist.
hallo, karl heinz Das ist es ja, was mich so zur Verzweiflung bringt. Ich gehe ja auch davon aus, das MCS weiß,was es tut. Ich habe auch schon einen 2. Tiny bemüht, gleiches Ergebnis. Ich habe auch schon an Störungen von draussen gedacht, aber kein Handy , Wlan, auch keine anderen Geräte, die strahlen. Stromversorgung aus Batterie, VCC , Gnd mit 100n geblockt. Ich werde dieses Problem wohl erst mal ins Wochenende schicken, und mich vegan ernähren (Hopfen, Malz, und frisches Quellwasser) deka65
Vielleicht ist ja wirklich irgendwas mit der RND Funktion nicht OK. Du kannst ja mal versuchen, den Modulo "von Hand" zu machen. Also
1 | Do |
2 | Z=RND(256) |
3 | Z=Z Mod 15 |
4 | Z=Z+1 |
5 | PORTB=Z |
6 | Wait 1 |
7 | Loop |
Es sollen ja min 1, max. 4 LEDs leuchten also sind alle Zahlen von 0+1 bis 14+1 (binär 00000001 bis 00001111) ok, daher der Modulo mit 15 (und nicht 8)
Detlef K. schrieb: > Versteh ich jetzt nicht ganz . Warum soll ich loopen > bis Z kleiner 9 ist ? Na ganz einfach - wenn dann immer noch die falschen LEDs leuchten, liegt es nicht am RND..
Hallo, nochmal Dank an alle, die sich hier zu diesem Thema gemeldet haben. Ich habe am Wochenende mal schnell auf Lochraster einen Max232 und eine Sub D9 -Buchse gesteckt und mit dem PC verbunden. Dann habe ich auf Tiny13 und Tiny2313 ein Programm laufen lassen, das RND(8) printet und auf dem Terminal ausgibt. Ergebnis, nach je 1000 Durchläufen nur Ziffern von 0 bis 7 ! Ich möchte jetzt auch nicht mehr darüber nachdenken. Sollte es irgendwann noch mal vorkommen, weiss ich, das es sowas gibt. damit kann ich leben. gruß deka65
Detlef K. schrieb: > Ergebnis, nach > je 1000 Durchläufen nur Ziffern von 0 bis 7 ! Was hast Du erwartet? Das ist doch genau das, was bei RND(8) kommen muß. MfG Paul
Paul B. schrieb: > Detlef K. schrieb: >> Ergebnis, nach >> je 1000 Durchläufen nur Ziffern von 0 bis 7 ! > > Was hast Du erwartet? Das ist doch genau das, was bei RND(8) kommen muß. > > MfG Paul Das ist richtig, aber seine bisherigen Ergebnisse sahen nicht so aus. Deshalb hat er sich ja gefragt, wie das kommen kann und diesen Thread eröffnet. Woran es lag, daß es nicht ging, weiß jetzt allerdings auch keiner :-)
Hallo, Paul B. schrieb: > Was hast Du erwartet? Das ist doch genau das, was bei RND(8) kommen muß. Ich habe ja auch nichts anderes erwartet. Jedoch sah das Resultat mit den LEDs anders aus, drum überhaupt meine Frage. Ich habe das alles noch mal probiert. LEDs an die Portpins B.0 -B.3 B.4 als Soft-UART. Das Ergebnis wie gehabt , verheerend. Dann habe ich die einzelnen Portpins als Ausgang deklariert. erst : PORTB = OUTPUT jetzt: PORTB.0 = OUTPUT ... PORTB.3 = OUTPUT und de Zuweisung der Zufallszahl Z dann an den Pin PORTB.0 = Z.0 ... PORTB.3 = Z.3 das Ergebnis kann sich sehen lassen. Die Leds leuchten jetzt ent sprechend dem Binaercode der auf dem Terminal ausgegebenen Ziffer. Auch die LED an PB.3 bleibt jetzt dunkel. So sollte es auch sein. Fazit : Ich denke, es lag nur an der "falschen" Konfiguration des Ports B, das zu diesen ominösen Ergebnissen führte. Nochmals vielen Dank an alle, die bei mir waren. Gruß deka65
Thread beobachten
Seitenaufteilung abschaltenBitte 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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.