Hallo Freunde. Hab schon das Forum und auch das Internet durchsucht, nur hatte einen solchen Fehler bisher anscheinend niemand. Es stellt sich wie folgt dar: Wenn ich ein Programm mit AVR-Studio in Assembler erstelle, compiliere und dann auf den ATMega8 übertrage, ist alles i.O. - so wie es sein soll. Da meine Programmierkenntnisse in Assembler allerdings nicht so gut sind wie in Basic, habe ich begonnen, mein Basic wieder aufzufrischen - mit an sich lohnendem Erfolg. Das Erstellen der Programme gestaltet sich großartig - wenn da nicht ein großer Haken an der ganzen Sache dran wäre: Sobald ich die Ports via "Config PORTB = output" als Ausgang deklariere, werden diese sofort negiert und die LED am Ausgang des STK500 beginnen fröhlich zu leuchten. Ich mag mich irren, aber bei den Inputs scheint es genauso zu sein. Dort nutze ich "Config PIND.0 = input". Das Problem ist, dass die Programmerstellung enorm erschwert ist, wenn alle Ein- und Ausgänge sofort nach der Zuweisung negiert werden. In den EInstellungen von BASCOM hab ich nichts großartig verändert, außer Baudrate, AVR-Einstellungen (eingestellt auf ATMEGA 8 mit 8MHz) und dem COM-Port. Zusätzlich hab ich noch das STK500-Plugin geladen, damit ich direkt via BASCOM programmieren und auch übertragen kann. Aber auch mit AVR-Studio als Programmer tritt besagter Fehler auf. Mittlerweile bin ich arg verzweifelt. Würden die Eingänge wenigstens auf LOW bleiben, wenn ich diese gleich zu Anfang zusätzlcih auf LOW setzen, jedoch sobald ich einen Tastendruck als Aktor programmiere, fallen sämtliche Ausgangs-Ports wieder auf HIGH zurück. Freue mich auf Lösungen. MFG MAik
Die Leds sind gegen Vcc geschaltet, sie gehen bei GND-Signal an.
Andreas S. schrieb: > Setze den Port z.b. auf 255. > > portb=255 'led´s aus > > mit z.b. portb.0 = 0 ist die LED an B0 an. Wie schalte ich die LED dann wieder an? portb=0? Das ist sehr umständlich, gerade wenn ich mit verschachtelten Programmen und z.B. dem Toggle-Befehl arbeiten muss. Ich probiere das mal aus - mal sehen ob das klappt. MFG
Maik Schulze schrieb: > Andreas S. schrieb: >> Setze den Port z.b. auf 255. >> >> portb=255 'led´s aus >> >> mit z.b. portb.0 = 0 ist die LED an B0 an. > > Wie schalte ich die LED dann wieder an? > > portb=0? > > Das ist sehr umständlich Und portb = 1 ist weniger "umständlich"? > gerade wenn ich mit verschachtelten Programmen > und z.B. dem Toggle-Befehl arbeiten muss. wenn das ein Problem ist, dann ist das ein sicheres Zeichen, dass dein Programmaufbau nicht stimmt (oder deine BASCOM Kentnisse noch verbesserungswürdig sind)
Maik Schulze schrieb: > Wenn ich ein Programm mit AVR-Studio in Assembler erstelle, compiliere > und dann auf den ATMega8 übertrage, ist alles i.O. - so wie es sein > soll. Wo ist denn da der Unterschied ? Auch in Assembler werden die Leds bei Level Low leuchten, das ist nicht SW, sondern STK500-bedingt. Ansonsten definiert man sich Konstanten und verwendet die, z.B. um Leds einzeln an- oder auszuschalten
1 | Const Led_Ein = 0 |
2 | Const Led_Aus = 1 |
3 | PortB.0 = Led_Ein |
4 | PortB.1 = Led_Aus |
Und sollte man mal den Code für Leds aktiv-high benötigen, stellt man nur die Konstanten für Led_Ein/_Aus um.
Hallo, warum hat Atmel beim STK500 eigentlich diese "Invertierte" Logik (also low = LED ein) ? Verwirrt doch nur beim programmieren bzw. umsetzen(testen) des Ergebnisses für die spätere Endanwendung, welche ja nicht auf den STK 500 Board läuft sondern auf der Platine des entsprechenden Projektes. Hat das einen technischen Grund, oder war das eine Laune des Entwicklers vom STK 500 ? Die unterschiedlichen Ströme die die AVRs als Senke oder Quelle aushalten sollten doch nicht die Ursache sein, da ja sowieso externe Transistoren als Treiberstufe auf den STK500 benutzt werden. mfg "Bastler"
Bastler schrieb: > Die unterschiedlichen Ströme die die AVRs als Senke oder Quelle > aushalten sollten doch nicht die Ursache sein, da ja sowieso externe > Transistoren als Treiberstufe auf den STK500 benutzt werden. auf dem STK500. Ja. Aber ein Entwicklungsboard sollte dann ja wohl auch die übliche Verwendung abseits vom Entwicklungsboard wiederspiegeln, damit man nicht nachher mit einem Programm dasteht, in welchem man alle Ausgaben dann erst recht wieder 0/1 spiegeln muss. Ausserdem ist das nun wirklich kein Thema. Richtig programmiert ist diese Umstellung eine Sache auf ein paar Sekunden und im Programmtext selber taucht 0 oder 1 gar nicht mehr auf sondern nur noch Begriffe wie EIN bzw. AUS. MWS hat ja schon gezeigt, wie man das macht.
Bastler schrieb: > warum hat Atmel beim STK500 eigentlich diese "Invertierte" Logik (also > low = LED ein) ? Dürfte an der Anpassung der Led-Helligkeit per Transistor über VTG liegen, siehe DB, das wär' andersrum nicht gegangen. > Verwirrt doch nur beim programmieren bzw. umsetzen(testen) des > Ergebnisses für die spätere Endanwendung, welche ja nicht auf den STK > 500 Board läuft sondern auf der Platine des entsprechenden Projektes. Nö, für den µC ist's wurscht, wohin der schaltet, das eigene Projekt kann genauso angelegt werden, also VCC/R/Led/µC und das wird auch oft so gemacht. Bastler schrieb: > da ja sowieso externe > Transistoren als Treiberstufe auf den STK500 benutzt werden. Das ist keine Treiberstufe.
stiefei schrieb: > Gegen Masse sind die Pins mehr Belastbar, sonst muss der AVR den ganzen > Strom liefern... Mag bei manchen ICs so sein, der Avrs haben jedoch symmetrische Ausgangsstufen.
OK, THX. Nächsten Fragen: Ich möchte die Ports in einer unetrschiedlichen Ablauffolge schalten. Als Grundbeispiel: Marke1: reset portb.0 waitms 100 set portb.0 waitms 100 goto marke1 end Dieses Programm erzeugt ja eine wiederkehrende Schleife und lässt Ausgang B.0 blinken. Nun soll diese Schleife genau 3 mal wiederholt werden und dann zu einer nächsten Schleife springen, welche sich ebenfalls 3 mal wiederholt. Der Schleifenablauf sollte im Hauptprogramm bzw. Unterprogramm vordefiniert ist. Beispiel: Wenn ich einen 4 LED-Ports synchron 3 mal blinken lassen will, wird der oben stehende Text mehr als 3mal so lang. Wenn danach auch noch 4 weitere Ports synchron 3 mal blinken sollen, habe ich schon einen 6mal so langen Text, und das nur für eine Anwendung mit EINEM Taster. Ziel des Programms ist es, dass ich über jeden Taster einen bestimmten Programmablauf starte, wo einfach immer nur die Schleifen in einem bestimmten Ablauf ablaufen sollen... Wäre echt dankbar für brauchbare Vorschläge. Die Variante mit "Dim X as Byte" hat leider nicht funktioniert. Mfg Maik
Hm, das Forum hilft Dir zwar bei 'nem konkreten Problem, es wird Dir aber nicht das selbstständige Lernen abnehmen, genauso wie ich bezweifle, daß es Dich in die untersten Basics der Bascom-Programmierung einweihen wird. Lern' doch erst einmal ein paar grundsätzliche Befehle, bzw. arbeite Dich durch die Beispiele, die Du im Bascom-AVR/samples Verzeichnis findest, dort u.a. for_next.bas, deboun.bas, usw.
Maik Schulze schrieb: > Dieses Programm erzeugt ja eine wiederkehrende Schleife und lässt > Ausgang B.0 blinken. Nun soll diese Schleife genau 3 mal wiederholt > werden und dann zu einer nächsten Schleife springen, welche sich > ebenfalls 3 mal wiederholt. Der Schleifenablauf sollte im Hauptprogramm > bzw. Unterprogramm vordefiniert ist. Sagtest du nicht, du hättest früher schon mal programmiert? Die FOR-NEXT Schleife ist schon lange erfunden. > Ziel des Programms ist es, dass ich über jeden Taster einen bestimmten > Programmablauf starte, wo einfach immer nur die Schleifen in einem > bestimmten Ablauf ablaufen sollen... Und da beginnt dann jetzt das ganze Gebilde zusammenzubrechen. Damit einzelne Taster unabhängig voneinander Blinksequenzen ein/ausschalten können, muss man anders an die Sache herangehen. Der Weg geht dann über einen Timer, der in regelmässigen Zeitabständen eine ISR aufruft (zb alle 1 Sekunde) und in der ISR wird dann in allen aktiven Sequenzen bestimmt, welche LEDs zu leuchten haben. Aber: Da auch Rom nicht an einem Tag erbaut wurde und das dann schon in die Kategorie "etwas fortgeschrittenere Programmierung" fällt, solltest du dieses Endziel erst mal fallenlassen und dein Basic bzw. BASCOM erst mal gründlich mit den Grundlagen aufpolieren.
Und noch was. Man muss nicht mittels PortD.0 = 0 auf das 0-te Bit am PortD zugreifen. Man kann es. Man kann aber auch direkt auf den ganzen Port in einem Rutsch zugreifen. .... DIM I as BYTE do PortD = I i = i + 1 waitms 500 Loop (und gewöhn dir das GOTO gleich wieder ab)
Du musst ja nicht jedes Bit/LED einzeln setzen. Man kann auch sowas machen: PORTB = &B00001111 oder PORTB = 15 Schau doch bitte mal in die BASCOM Hilfe, da gibt es doch Beispiele inkl. Erklärung oder auch mal eins der Beispielprogramm ansehen. Gruß, avrGerd
bei Bascom geht auch Set PortX.n Reset PortX.n Toggle PortX.n
@ Karl Heinz: Es gibt einen Unterschied zwischen AVR-Programmierung und Anwendungsprogrammierung. Die Programme, die ich früher erstellt hatte, drehten sich in erster Linie um Rechenoperationen und PRINT-Bildschirmausgaben. Da gab es auch wiederkehrende Routinen, aber keine Schleifen. Der Befehl FOR_NEXT ist mir somit neu. Bitte vielmals um Verzeihung, dass ich nicht die komplette BASCOM-Hochsprache beherrsche und deshalb fragen muss. @ all: Gibbet eigentlich auch ein Tutorial, welches sich auf SOLCHE Programmierbeispiele konzentriert? Ich habe schon viele Tutorials durchsucht, aber schon nach kurzer Aufwärmphase wird dort fast immer gleich zu den Rechenoperationen gesprungen, mit welchen ich net viel anfangen kann. Ich meine - ich will die Ports steuern, und nicht irgendwelche Zahlen auf meinem "nicht vorhandenen" Display ausgeben. MFG MAik
Maik Schulze schrieb: > Ich meine - ich will die Ports steuern, und nicht > irgendwelche Zahlen auf meinem "nicht vorhandenen" Display ausgeben. Entweder Du liest Dir die Antworten hier nicht durch oder Du bist in gewissem Maß verständnisresistent. Ich schrieb doch, schau im samples-Verzeichnis nach, dort findest Du auch Port.bas, da sind die Portbefehle erklärt. Wenn Du alles dort verstanden hast, dann bist Du schon ein Stück weiter. Die Bascom Hilfe gibt's als Pdf im Unterverzeichnis Bascom-AVR/pdf, da sind auch alle Befehle mit Beispielen aufgelistet. Wenn Du dann noch nicht klarkommst, kauf Dir ein Buch, von Claus Kühnel gibt's ein gutes über Bascom. Nürnberger Trichter sind leider aus, sonst könntest Du einen haben.
Maik Schulze schrieb: > keine Schleifen. Der Befehl FOR_NEXT ist mir somit neu. Bitte vielmals > um Verzeihung, dass ich nicht die komplette BASCOM-Hochsprache > beherrsche und deshalb fragen muss. Dann erzähl auch nicht, das du früher programmiert hast. Das ist so, wie wenn du sagt, du kennst dich in Mathe aus, hast aber noch nie Multipliziert. FOR NEXT ist in Basic weder exotisch noch selten. FOR NEXT sind Grundlagen und ich kann mir kaum ein Programm vorstellen, welches ohne auskommt. Ausser vielleicht ganz primitive Anfängerbeispiele: Geben sie einen Radius ein - Ihr Kreis hat xyz Meter Umfang. Danke für die Programmbenutzung.
Karl Heinz Buchegger schrieb: > FOR NEXT sind > Grundlagen und ich kann mir kaum ein Programm vorstellen, welches ohne > auskommt. Wer Basic durch Versuch & Irrtum unter Windoof mit M$-VB gelernt hat, könnte sich an For-Next vorbeigemogelt haben. Denn die Mainloop läuft unsichtbar im Hintergrund und man programmiert Code für "Ereignisse". Hat man Basic aber von der Pike auf gelernt (alte 8-Bit-Homecomputer, M$-QBASIC), dann sollte man auch Schleifen kennen (es gibt ja noch einige mehr als nur For-Next). ...
Ich verstehe nicht, warum ich alles kennen und verstehen muss, nur weil ich früher einfache Programme geschrieben habe, Karl Heinz. Hannes hingegen ist da weitaus offener für Situationen wie die Meine und hat den Nagel auf sofort auf den Kopf getroffen: Punkt 1: Zwar ist Programmieren wie Fahrrad fahren und man verlernt das nicht so schnell, jedoch habe ich die letzten Programme mit 19 geschrieben, das ist also schon über 11 Jahre her. Da darf ich - denke ich - getrost ein großes Maß an Unkenntnis an den Tag legen und muss mich nicht einmal dafür schämen. Punkt 2: Sämtliche Programmierkenntnisse hatte ich mit Qbasic im kompletten Eigenstudium erfahren. Da darf getrost einiges an mir vorbei gegangen sein. Ich hatte damals ein Buch, allerdings ist dies bei Umzügen mit den Jahren verloren gegangen. Es ist also nicht verwunderlich, dass ich nicht alles wissen kann, sonst würde ich ja nicht fragen. Auch stelle ich mir in explizit dem Fall Deiner Antwort die Frage, wieso es überhaupt ein Forum für Mikrocontroller und Programmerstellung gibt, wenn ich doch eh auf das fachliche Studium durch Literatur (Bücher) zurück verwiesen werde. Mir wurde zu Beginn des Themas gesagt, dass ich getrost Fragen stellen darf. Nun tue ich dies und ich bekomme als Antwort: "Kauf Dir doch ein Buch". Na recht vielen Dank auch. Das hab ich gebraucht. Frage: For_Next hat bei mir irgendwie net so funktioniert wie ich das wollte. Beispiele zur praktischen Anwendung habe ich keine weiter gefunden. Hab das Internet zur Suche benutzt, aber ohne Erfolg. Die While-Schleife sah vielversprechend aus, war für meine Belange jedoch auch letztenendes untauglich, da ich die Schleife nicht mehr verlassen konnte, selbst wenn ich den Eingabepunkt mit der Variable verknüpft habe oder die Schleife nur einmal durchlaufen wurde und danach konnte ich nicht mehr starten (Wenn Taster gedrückt dann erhöhe Wert um 1, verlasse Schleife wenn Wert größer als 1, gehe in Schleife wenn Wert gleich 1). Nun habe ich entsprechende Wiederholungen mit einer einfachen if_then_else-Schleife programmiert, in welcher als "Then" ein "gosub"-Befehl zum Unterprogramm verzweigt wurde. Am Ende jedes Unterprogramms wurde Variable X um 1 erhöht und in das Hauptprogramm gesprungen, wo die erhöhte Variable eine neue "Gosub" erzeugte. Funzt eigentlich prima und macht was es soll. Nur sind die Schleife halt nicht endlos. Könnte mir jemand Bitte ein gutes Programmbeispiel erläutern bzw. zeigen, in dem For_Next praktisch demonstriert wird? Die meisten Beispiele, die dazu gefunden habe, sind oberflächlich und es fehlen alle Variablen. Ein gutes Beispiel genügt schon. Nächste Frage: Die Hauptschleife (Do_Loop) kann ja vom Prinzip her ganz einfach verlassen werden. Allerdings wird die Schleife dann komplett links liegen gelassen. Wenn ich mit mehreren Tastern mehrere Programme gleichzeitig laufen lassen möchte - wie muss das dann aussehen und ist das überhaupt möglich? Ich meine - ein Controller taktet 1000000 Zyklen und mehr je Sekunde, da muss doch das Abrufen eines weiteren Programms möglich sein noch während ein anderes Unterprogramm läuft. Als einfaches Beispiel: Taster1 wird getastet und LED1 blinkt autonom mit 5 Herz. Dies ist ja möglich, indem man eine Schleife schreibt, in welche nach Drücken von Taster1 gesprungen wird. Nun soll Taster2 getastet werden können und LED2 und LED3 sollen nun abwechselnd blinken, und zwar zusätzlich zu LED1. Das wären dann 2 Programmabläufe parallel. Möglich oder nicht? Wenn ja - wie und wo finde ich ein Anwendungsbeispiel? Noch einmal möchte ich mich aufrichtig entschuldigen, dass ich keine Lehrer habe, der mir das Programmieren eines AVR beibringen kann. Auch hatte ich keinen Informatik-Kurs in der Schule, der mir das erleichtert. Alles Eigenstudium, aber ich werde langsam besser. Geht halt nicht alles von heut auf morgen, so wie Einige es sich wünschen. Thema Bücher: Ich habe mir einige Bücher bereits angeschaut, jedoch waren die Rezessionen fast immer mies oder zwiespältig. Ist der oben genannte Buchvorschlag haltbar oder gibt es bessere Bücher? Denn eines ist Fakt: Ich möchte mir nicht 10 Bücher kaufen müssen, nur um alle für mich relevanten Informationen zusammen tragen zu können. Das ist nicht vertretbar und nebenbei hab ich auch kein so dickes Bankkonto wie Bill Gates. Bei den Preisen von fast 50,-€ je Buch sind 2 Bücher eher die Obergrenze, sonst steigt mir meine Frau aufs Dach! Vielen Dank für eure Antworten und Lösungsvorschläge. MFG MAik
Fast vergessen: Gibt es irgendwo die BASCOM-Helpdatei auch auf deutsch? Im Ordner .pdf sind bei mir keine Dateien vorhanden... Die Port.bas habe ich gefunden und schaue mir gerade das entsprechende Beispiel an. Vielen Dank ;) MFG Maik
Maik Schulze schrieb: > Ich verstehe nicht, warum ich alles kennen und verstehen muss, nur weil > ich früher einfache Programme geschrieben habe, Karl Heinz. Ich glaub' Du tust ihm unrecht... > Hannes > hingegen ist da weitaus offener für Situationen wie die Meine und hat > den Nagel auf sofort auf den Kopf getroffen: > > Punkt 1: Zwar ist Programmieren wie Fahrrad fahren und man verlernt das > nicht so schnell, jedoch habe ich die letzten Programme mit 19 > geschrieben, das ist also schon über 11 Jahre her. Da darf ich - denke > ich - getrost ein großes Maß an Unkenntnis an den Tag legen und muss > mich nicht einmal dafür schämen. Nunja, seit den Achzigern befasse ich mich gelegentlich mit BASIC. Zuerst rein theoretisch (Bücher lesen), dann auf Homecomputer (KC-Nachbau eines Bekannten, eigener Commodore Plus/4), dann PC-QBASIC, VB6, ein bissel Bascom. > > Punkt 2: Sämtliche Programmierkenntnisse hatte ich mit Qbasic im > kompletten Eigenstudium erfahren. Da darf getrost einiges an mir vorbei > gegangen sein. Ich hatte damals ein Buch, allerdings ist dies bei > Umzügen mit den Jahren verloren gegangen. Qbasic besticht aber durch seine verdammt gute Online-Hilfe. > Es ist also nicht > verwunderlich, dass ich nicht alles wissen kann, sonst würde ich ja > nicht fragen. > Auch stelle ich mir in explizit dem Fall Deiner Antwort die Frage, wieso > es überhaupt ein Forum für Mikrocontroller und Programmerstellung gibt, > wenn ich doch eh auf das fachliche Studium durch Literatur (Bücher) > zurück verwiesen werde. Naja, C ist z.B. ohne Fachbücher kaum erlernbar bzw. beherrschbar (kann ich auch nicht), da ist der Spruch "Kauf' Dir ein C-Buch, ehe wir weiter reden" schon legitim. > Mir wurde zu Beginn des Themas gesagt, dass ich > getrost Fragen stellen darf. Nun tue ich dies und ich bekomme als > Antwort: "Kauf Dir doch ein Buch". Na recht vielen Dank auch. Das hab > ich gebraucht. Naja, Frage stellen und Frage stellen ist Zweierlei. Etwas Grundlagenwissen in der bevorzugten Programmiersprache sollte man sich schon ohne große Fragerei erarbeiten. Mit ddem Vermitteln der kompletten Grundlagen ist ein Forum überfordert. Hier werden konkrete Fragen zum Verständnis gelöst, dabei oft nur Tips in Form von Schlagwörtern (zum weiter recherchieren) gegeben. > > > Frage: > For_Next hat bei mir irgendwie net so funktioniert wie ich das wollte. > Beispiele zur praktischen Anwendung habe ich keine weiter gefunden. Hab > das Internet zur Suche benutzt, aber ohne Erfolg. Klassisches Hallo-Welt-Beispiel am Homecomputer oder DOS-PC: For i = 1 to 20 print i, i*i, i*i*i next i > Die While-Schleife sah > vielversprechend aus, war für meine Belange jedoch auch letztenendes > untauglich, da ich die Schleife nicht mehr verlassen konnte, selbst wenn > ich den Eingabepunkt mit der Variable verknüpft habe oder die Schleife > nur einmal durchlaufen wurde und danach konnte ich nicht mehr starten > (Wenn Taster gedrückt dann erhöhe Wert um 1, verlasse Schleife wenn Wert > größer als 1, gehe in Schleife wenn Wert gleich 1). > > Nun habe ich entsprechende Wiederholungen mit einer einfachen > if_then_else-Schleife programmiert, Sorry, das ist keine Schleife, sondern eine Verzweigung. > in welcher als "Then" ein > "gosub"-Befehl zum Unterprogramm verzweigt wurde. Am Ende jedes > Unterprogramms wurde Variable X um 1 erhöht und in das Hauptprogramm > gesprungen, wo die erhöhte Variable eine neue "Gosub" erzeugte. Funzt > eigentlich prima und macht was es soll. Nur sind die Schleife halt nicht > endlos. Auch das Zurückspringen im Programmcode mit Goto ist eine Schleife. So arbeitet man in Asembler. In Hochsprachen wird diese Art aber gemieden wie die Pest, weil sie bei Unaufmerksamkeit fehlerträchtig ist und weil Hochsprachen spezielle Schleifenkonstrukte zur Verfügung stellen, die den Programm-Quelltext lebarer machen. > > Könnte mir jemand Bitte ein gutes Programmbeispiel erläutern bzw. > zeigen, in dem For_Next praktisch demonstriert wird? Die meisten > Beispiele, die dazu gefunden habe, sind oberflächlich und es fehlen alle > Variablen. Ein gutes Beispiel genügt schon. Siehe oben. > > > Nächste Frage: > > Die Hauptschleife (Do_Loop) kann ja vom Prinzip her ganz einfach > verlassen werden. Damit wird dann der Programmlauf verlasen und der Programmzeiger zeigt dann auf Speicherzellen, die keinen gültigen Programmcode enthalten, worauf der Controller Amok läuft. Im einfachsten Fall interpretiert er leere Speicherzellen als NOP und landet nach dem Speicherende wieder am Anfang (der Adressraum ist ja ein Ring) und beginnt das Programm von vorn. Es ist also keine gute Idee, die Hauptschleife zu verlassen. > Allerdings wird die Schleife dann komplett links > liegen gelassen. > Wenn ich mit mehreren Tastern mehrere Programme gleichzeitig laufen > lassen möchte - wie muss das dann aussehen und ist das überhaupt > möglich? Ja sicher ist das möglich, nur mit dem Basic-Wissen einfacher Programme, die für Tastatur und Bildschirm geschrieben wurden, wird das nix. Hier musst Du Multitasking programmieren, nein, nicht Windoof, sondern auch auf kleinen AVRs. Dazu zerlegst Du Deine Aufgaben in ganz kleine Stücke und arbeitest in einer schnellen Hauptschleife immer nur ein kleines Stück aller anstehenden Aufgaben ab. Du wartest also beim Blinken nicht mehr mittels Wait bis zum erneuten Toggeln, sondern zählst lediglich einen "Blinkzeitzähler" herunter und prüfst ihn auf 0. Erreicht er 0, dann toggelst Du den Ausgang und setzt den Blinkzeitzähler wieder auf Startwert. Und diese Hauptschleife erledigt in jedem Durchlauf noch andere Dinge. So z.B. das Entprellen der Tasten (natürlich ohne Wait-Befehl, dafür mit Entprellzähler), das Lesen von ADC, das Abfragen der UART-Schnittstelle auf neue Daten usw. Die Hauptschleife enthält also viele kleine überschaubare Zustandsautomaten (State machine), von dene jeder eine logische Einheit ist und bei Bedarf auf den Zustand eines anderen Zustandsautomaten zugreifen kann. Beispiel: Eine Tastenentprellung entprellt mehrere Tasten und stellt den entprellten Tastenzustand als mehrere Merker (Bitmerker, Booleans, Flags, Semaphores) in einem Byte bereit. Sie hat auch eine Flankenerkennung und stellt Merker bereit, die Aussagen, ob eine Taste erneut betätigt wurde. Mit diesen erkern kann man Zustandsflags toggeln, um Funktionen ein bzw. aus zu schalten. Jeder Blink-Task (Multitasking?) prüft seinen an/aus-Merker. Ist er aus, macht er das Licht aus und stellt den Blinkdauerzähler auf Startwert. Ist er an, dann zählt er den Blinkdauerzähler herunter und prüft ihn auf 0. Ist er 0, dann toggelt er den Blinker und setzt den Blinkdauerzähler wieder auf Startwert. Jeder Blinktask arbeitet also unabhängig von anderen Blinktasks, kümmert sich nur um "seinen" Merker und je nach dessen Status um "seinen" Blinker. Dabei kann jeder Blinker mit einem anderen Startwert arbeiten und somit eine andere Frequenz erzeugen. Die Hauptschleife muss dazu in einem konstanten Tempo laufen, das so gewählt wird, dass sie alle ihre Jobs (Tasks) schafft und dass am Ende noch etwas Rechenzeit als Reserve für Erweiterungen übrig bleibt. Für unabhängig schaltbare Blinker würde ich 10 ms als Intervall empfehlen. Der einfachste Weg ist es, alle 10 ms einen Timer-Interrupt auszulösen, der einen Merker setzt, der besagt, dass 10 ms verstrichen sind. Die Hauptschleife prüft nun diesen Merker (IF in Basic) und verzweigt bei nicht gesetztem Merker zum Ende, weist also den Code aller Tasks ab. Ist der Merker gesetzt, dann wird er gelöscht (Verzweigung ist ja bereits erfolgt) und es werden alle Jobs ausgeführt, also in allen Tasks ein Schritt ausgeführt. Wenn alle Tasks fertig sind, wartet die Hauptschleife wieder auf den Startschuss des Timers, also auf des Setzen des Startmerkers. > Ich meine - ein Controller taktet 1000000 Zyklen und mehr je > Sekunde, da muss doch das Abrufen eines weiteren Programms möglich sein > noch während ein anderes Unterprogramm läuft. Als einfaches Beispiel: > > Taster1 wird getastet und LED1 blinkt autonom mit 5 Herz. Dies ist ja > möglich, indem man eine Schleife schreibt, in welche nach Drücken von > Taster1 gesprungen wird. > Nun soll Taster2 getastet werden können und LED2 und LED3 sollen nun > abwechselnd blinken, und zwar zusätzlich zu LED1. Das wären dann 2 > Programmabläufe parallel. Möglich oder nicht? Wenn ja - wie und wo finde > ich ein Anwendungsbeispiel? Viel zu kompliziert gedacht. Du brauchst einen gemeinsamen Nenner und für jede Verzögerung einen eigenen Zähler. > > > Noch einmal möchte ich mich aufrichtig entschuldigen, dass ich keine > Lehrer habe, der mir das Programmieren eines AVR beibringen kann. Auch > hatte ich keinen Informatik-Kurs in der Schule, der mir das erleichtert. > Alles Eigenstudium, aber ich werde langsam besser. Geht halt nicht alles > von heut auf morgen, so wie Einige es sich wünschen. Ich hatte auch keinen Lehrer, zu meiner Schul- und Lehrzeit (50er und 60er Jahre) gab es noch keine allgemein verfügbare EDV bzw. MC-Technik. > > Thema Bücher: Ich habe mir einige Bücher bereits angeschaut, jedoch > waren die Rezessionen fast immer mies oder zwiespältig. Ist der oben > genannte Buchvorschlag haltbar oder gibt es bessere Bücher? Denn eines > ist Fakt: Ich möchte mir nicht 10 Bücher kaufen müssen, nur um alle für > mich relevanten Informationen zusammen tragen zu können. Das ist nicht > vertretbar und nebenbei hab ich auch kein so dickes Bankkonto wie Bill > Gates. Bei den Preisen von fast 50,-€ je Buch sind 2 Bücher eher die > Obergrenze, sonst steigt mir meine Frau aufs Dach! > > > Vielen Dank für eure Antworten und Lösungsvorschläge. > > > MFG MAik ...
hi! http://www.dieelektronikerseite.de/uC%20Ecke/Lections/Bascom%20AVR%20-%20Befehlsreferenz.htm cya The_Ride
Hallo Hannes. Vielen Dank für Deine sehr gut formulierte Ausführung. Die habe ich auch gut verstanden. Bis zur Umsetzung wird allerdings noch eine Menge Zeit vergehen. Fakt ist: Das Programm für die Beleuchtungssteuerung eines meiner im Bau befindlichen Modelle ist zu 85% fertig. Hierbei sind sämtliche Räume im Modell beleuchtet und sollen via Taster separat geschaltet werden können. Über einen Sondertaster (später PWM-Signal - das sind die ersten fehlenden 10%) sollen dann alle Beleuchtungen in einer bestimmten zeitlich getimten Modulation geschaltet und bei erneutem Impuls abgeschaltet werden. Dabei sollen die Raumbeleuchtungen einen Leuchtstoff-Start-Effekt simulieren. Das klappt schon perfekt. Zeitgleich kann ich eh nur einen Taster betätigen, von daher ist das erledigt (leicht, ich weiß). Die letzten 5% sind eine Schleife, die nebenbei bei Betätigung eines Tasters abläuft, nämlich das konstante Blinken eines oder mehrerer vordefinierter Pin. Das Programm muss aber nebenher laufen und den Zugriff auf alle anderen Programme trotzdem noch erlauben. Und genau hier muss Dein Lösungsvorschlag ansetzen. Tja, was soll ich sagen. So tief bin ich nie in die Materie hervor gedrungen. Mit Qbasic erreichte ich irgendwann schnell einen toten Punkt, bei welchem ich keinen Rat fand. Internet hatte ich zu diesem Zeitpunkt noch nicht. Kurz darauf hatte ich dann auch über Jahre keinen Rechner mehr und auch keine Zeit zum weiteren Programmieren. Nun habe ich wieder angefangen, endlich ein Board, welches auch Ergebnisse visualisiert und einen Programmer, mit dem ich direkt aus Basic und AVR Studio auf den Controller schreiben kann. Übrigens: Das Buch "BASCOM AVR" hab ich mir nun bestellt. Sollte spätestens am Dienstag eintreffen. Ich hoffe, dass die 35,-€ keine sinnlose Investition waren. Aus Büchern lernt man ja bekanntlich, kauft aber auch immer ne Menge Schrott mit dazu. Meine Ziele: Ich bin im Modellbau sässhaft und werde das auch bleiben. Das Programmieren mache ich echt nur nebenbei (also teile ich meine Freizeit nach der Arbeit mit Frau, Hobby und Hobby). Als Ziel habe ich mir die Steuerung von Motoren gesetzt. Sowohl Bürsten- als auch Brushless-Motoren. Die Steller zu bauen ist net sonderlich schwer. Allerdings brauche ich halt neben den Controllern auch ein Programm. An diese Materie will ich aber noch nicht heran, denn das Auswerten von PWM-Signalen ist mir zu diesem Zeitpunkt noch nicht möglich. Ich habe kein Oszilloskop. MFG Maik
Maik Schulze schrieb: > denn das Auswerten von > PWM-Signalen ist mir zu diesem Zeitpunkt noch nicht möglich. http://www.hanneslux.de/avr/index.html ...
Ich hänge Dir mal ein paar Beispiele in Bascom an. Einige Programme laufen in der ISR und haben eine leere Mainloop. Die meisten Programme nutzen Merker. Das 8_Taster-Programm hat eine sehr gute hocheffiziente Tastenentprellung. Das Seilbahnprogramm verdeutlicht das SM-Konzept. Die Gaak-Programme werten Servoimpulse (ich mag die nicht PWM nennen) aus. In einigen Programmen gibt es For-Next-Schleifen. Viel Spaß beim Analysieren und Verstehen. Die meisten Programme schreibe ich aber in ASM, ist effizienter und geht mir (trotz meiner langjährigen Basic-Praxis) besser von der Hand. Bascom benutze ich nur mal so zum Spaß, so richtig fit bin ich damit nicht. Richtig Ahnung von Bascom hat hier im Thread MWS. Und wenn (d)er schon meint, Du solltest erstmal anhand der mit Bascom mitgelieferten Beispiele Grundlagen lernen, dann würde ich mir das zu Herzen nehmen anstatt mich gnatzig zu entschuldigen, dass ich nicht alles weiß... ...
Das hat nix mit gnatz zu tun. Grundlagen hab ich - nur halt nicht alle... :D Also ich werde mir Deine Website durchstudieren und "abarbeiten". Die Beispiele sind sicher genau das, was ich brauche. Ich denke, dass du nix gegen eine "Adaption" einiger Beispielprogramme hast, oder? Sollte ich Fragen haben, werde ich diese hoffentlich stellen dürfen. Fragen gibbet immer reichlich. Naja - im Modellbau nutzen wir halt die entsprechende Sprache. Und da sind das keine Servo-Signale sondern PWM-Signale. Ich weiß, du nennst das so, aber in meiner "Ecke" kann man das schnell verwechseln bzw. falsch verstehen. Denn nicht nur Servos werden mit Hilfe von PWM-Signalen gesteuert, sondern auch Fahrregler und Relaiskarten. Quasi alles, was im Modellbau am Empfänger angeschlossen werden kann. Hast du eigentlich ein Oszilloskop? Ich brauch mal eines, wenn ich in Zukunft auch mal einen Fahrregler bauen möchte. Die Bauteile hab ich zu 90%, u.A. wird die Leistungsendstufe mit mehreren BTS555. Mehr als 500A wird ein Regler wohl nicht fressen :D Das mit den Bascom Hilfedateien ist so eine Sache. Ich hab fast 2 Stunden gebraucht, nur um diese Dateien erst einmal ausfindig zu machen. Danach noch mal gute 2 Stunden gebraucht, nur um die öffnen zu können, da Windoof mir die Rechte dafür entzogen und diese einfach mal eben auf den Trustet Installer verschoben hatte. Vielen Dank für Deine Hilfe. Weiß ich sehr zu schätzen.
Maik Schulze schrieb: > Das hat nix mit gnatz zu tun. Grundlagen hab ich - nur halt nicht > alle... :D Sah aber so aus. > > Also ich werde mir Deine Website durchstudieren und "abarbeiten". Die > Beispiele sind sicher genau das, was ich brauche. Naja, Bascon wirst Du da nicht (viel) finden, ich werkele normalerweise in Assembler. > Ich denke, dass du nix > gegen eine "Adaption" einiger Beispielprogramme hast, oder? Dann hätte ich sie nicht ins Netz stellen dürfen. Ich habe lediglich etwas gegen gewerbliche Nachnutzung, also wenn andere Leute mit meinen Programmen dickes Geld verdienen. > Sollte ich > Fragen haben, werde ich diese hoffentlich stellen dürfen. Fragen gibbet > immer reichlich. Es kommt auf die Fragen an. Assembler kann und will ich Dir nicht beibringen. Bascom auch nicht. Konzept-Ideen kannst Du den Beispielen im obigen Archiv entnehmen. Konkrete Fragen zu Details sind natürlich erlaubt. > > Naja - im Modellbau nutzen wir halt die entsprechende Sprache. Und da > sind das keine Servo-Signale sondern PWM-Signale. Naja, PWM hat mit Tastgrad zu tun, den gibt man in Prozent an, so z.B. beim Betreiben von DC-Motoren (mit Kollektor) mit PWM-Tastgrad von 0% bis 100%. Beim Servoimpuls (Servosignal nenne ich das nicht) kommt es auf die exakte Impulsbreite an, nicht auf den Tastgrad. Und da vermeide ich (und viele Andere) den Begriff PWM. > Ich weiß, du nennst > das so, aber in meiner "Ecke" kann man das schnell verwechseln bzw. > falsch verstehen. Genau wegen der Verwechselungsgefahr nenne ich das Servoimpuls. > Denn nicht nur Servos werden mit Hilfe von > PWM-Signalen gesteuert, sondern auch Fahrregler und Relaiskarten. Quasi > alles, was im Modellbau am Empfänger angeschlossen werden kann. Ich weiß, da brauchst Du mich nicht belehren. Ich habe genug Programme für etliche dieser Anwendungen geschrieben. > > Hast du eigentlich ein Oszilloskop? Ja selbstverständlich, allerdings kein hochmodernes. > Ich brauch mal eines, Das gebe ich allerdings nicht aus dem Haus. Ist halt ein Werkzeug, das ich zwar nicht jeden Tag benutze, das aber immer bereit stehen muss. > wenn ich in > Zukunft auch mal einen Fahrregler bauen möchte. Fahrtregler habe ich schon einige entwickelt und gebaut. Der Umfangreichste wird hier vorgestellt: http://www.hanneslux.de/planet5b/details/lokregler-platine.html Dabei geht es nicht um maximale Motorleistung, sondern um Bedienkomfort und Flexiblität. Das Gesamtprojekt ist hier beschrieben: http://www.hanneslux.de/planet5b/index.html Die Seite ist aber nicht mehr aktuell, es gab inzwischen etliche Verbesserungen, die noch nicht veröffentlicht wurden. Der Fahrtregler arbeitet übrigens mit Tiny2313, liest 5 Kanäle des Empfängers ein, arbeitet mit einer einstellbaren (Motor-) PWM-Frequenz bis 28,8 kHz, steuert neben dem Motor noch Zusatzfunktionen und ein Soundmodul, das Programm ist in ASM geschrieben und arbeitet mit 5 Interrupts und etlichen Jobs in der Mainloop. Mit Bascom wäre es nicht realisierbar gewesen. > Die Bauteile hab ich zu > 90%, u.A. wird die Leistungsendstufe mit mehreren BTS555. Mehr als 500A > wird ein Regler wohl nicht fressen :D Ab etwas über 5 Ampere Motorstrom wirst Du ganz andere Sorgen haben als die Software des Fahrtreglers. Dann geht es nämlich hauptsächlich um die Entstörung der Anlage. Für Modelle, die Strom im zweistelligen Ampere-Bereich ziehen, sollte man schon von Fachingenieuren durchgestylte industrielle Fahrtregler einsetzen, da halte ich nichts mehr von Bastlerprojekten. Da rate ich Dir, erstmal kleine Brötchen zu backen, Du hast noch einen weiten Weg vor Dir... > > Das mit den Bascom Hilfedateien ist so eine Sache. Ich hab fast 2 > Stunden gebraucht, nur um diese Dateien erst einmal ausfindig zu machen. Na die erreicht man doch über Help in der Menüleiste oder mit der F1-Taste, wenn der Cursor im Editor auf einem Schlüsselwort steht. > Danach noch mal gute 2 Stunden gebraucht, nur um die öffnen zu können, > da Windoof mir die Rechte dafür entzogen und diese einfach mal eben auf > den Trustet Installer verschoben hatte. Na Du hast ja ein nettes Betriebssystem... > > Vielen Dank für Deine Hilfe. Weiß ich sehr zu schätzen. ...
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.