nun habe ich endlich meinen ersten Arduino in der Hand und kann mal alles praktisch ausprobieren. Für's erste bin ich begeistert, wie einfach alles ist. Für meinen ersten Anwendungsfall (Auswerten eines Tastendrucks und senden des Ergebnisses an einen Rechner) musste ich nichtmal das Handbuch wälzen - das gaben schon die Beispiele her. Am Ende muss das ganze noch über's Netz aber das sollte ja auch recht simpel sein. Für eine Taster-Zu-Ethernet-Lösung ist das ganze zwar sicher etwas überdimensioniert aber für einen Hardware- und µc-Laien wäre sowas ohne solch Technik ganz unmöglich.
Inzwischen bin ich ein wenig am Rumspielen und habe auch gleich ein paar Fragen. Am Uno hägt ja an Pin 13 eine LED dran. Trotzdem gibt es einen nach außen geführten Pin13. Ist das dann der selbe?
Auf Pin13 gibt es ja kein PWM. Mit delayMicroseconds (z.B. im Verhältnix 50:1) bekomme ich die LED aber recht sauber auf ca. 50% Leuchtkraft.
Das Fade-Beispiel bekommt man damit auch ganz gut hin, ohne eine LED am PWM zu benötigen. Die eingebaute LED wird dann ja extrem oft aus- und angeschaltet - kann ich damit was kaputt machen?
Das Input-Pullup-Beispiel wollte zunächst nicht mit einem anderen Pin außer der 2 gelingen bis mir auffiel, dass dort der Pin nicht als Konstante definiert war, so dass ich immer nur eine von 2 Stellen geändert habe. Auch hier die Frage: kann ich was kaputt machen, wenn ich aus versehen einen Pin auf OUT stehen habe und gegen GND schalte?
Als nächstes geht's zu Conrad, den 433MHz Receiver kaufen
Ach ja, wo kann ich ein gutes Beispiel finden, wie ich einen Timer Interrupt nutzen kann, so dass ich z.B. ein PWM (oder ein einfaches Blinken) auf Pin 13 realisieren kann, ohne die loop-Schleife zu verwenden? Die PWMs sind doch auch nur Software im µc und damit austauschbar oder?
mwyraz:
Am Uno hägt ja an Pin 13 eine LED dran. Trotzdem gibt es einen nach außen geführten Pin13. Ist das dann der selbe?
Ja, das ist der selbe. Du kannst die Beschaltung im Hardwarebereich auf der Hauptseite einsehen und bei Fragen: einfach frage...
mwyraz:
Auf Pin13 gibt es ja kein PWM. Mit delayMicroseconds (z.B. im Verhältnix 50:1) bekomme ich die LED aber recht sauber auf ca. 50% Leuchtkraft.
Das Fade-Beispiel bekommt man damit auch ganz gut hin, ohne eine LED am PWM zu benötigen. Die eingebaute LED wird dann ja extrem oft aus- und angeschaltet - kann ich damit was kaputt machen?
Nein, das sollte sie unbeschadet überstehen. Genauso funktioniert eine PWM.
mwyraz:
Auch hier die Frage: kann ich was kaputt machen, wenn ich aus versehen einen Pin auf OUT stehen habe und gegen GND schalte?
Wenn du an diesen Ausgang mit digitalWrite(); ein High-Pegel anlegst und den Pin gegen Masse schaltest erzeugst du ja einen Kurzschluss, also einen Stromfluss, der höher als die maximal zulässigen 40mA sind. Wir wollen doch nichts kaputt machen...
mwyraz:
Ach ja, wo kann ich ein gutes Beispiel finden, wie ich einen Timer Interrupt nutzen kann, so dass ich z.B. ein PWM (oder ein einfaches Blinken) auf Pin 13 realisieren kann, ohne die loop-Schleife zu verwenden?
Timer sind ein sehr komplexes Thema, ich würde Einsteigern das noch nicht zumuten wollen. Soll eine LED unabhängig vom restlichen Programm blinken, schau dir das Beispiel BlinkWithoutDelay an.
mwyraz:
Die PWMs sind doch auch nur Software im µc und damit austauschbar oder?
Die PWMs sind Hardware im Mikrocontroller, die kann man nicht einfach auf andere Pins umbiegen.
Vielen Dank für die schnelle Antwort.
Was passiert bei >40mA? Irgendwo habe ich mal was von automatischen Fuses (Sicherungen?) gelesen.
Beim BlinkWithoutDelay Beispiel ist das blinken ja gerade nicht unabhängig vom restlichen Code. Wenn der mehr als "delay" an Zeit benötigt, blinkt es nicht mehr richtig. Wenn man damit sowas wie PWM realisieren würde, bleibt nicht mehr viel für den eigentlichen Code. Das ganze ist dann eher sowas wie kooperatives Multitasking, bekannt aus der Windows 3.1 Zeit
Ich dachte, die PWMs wären "nur" Software, weil die ja die gleichen Interrupts verwenden, wie die anderen Timer. Wenn in den Interrupt nun für eine PWM-Software verwenden würde (statt für die eingebauten PWMs), käme ich dann auch die gleiche Leistungsfähigkeit? (nicht dass ich das vorhätte aber es trägt sicher einiges zum Verständniss bei).
Du kannst dich in dem Fall mindestens von diesem Pin verabschieden. Oder vom gesamten Port. Oder vom Mikrocontroller.
Irgendwo habe ich mal was von automatischen Fuses (Sicherungen?) gelesen.
Die Sicherung gibt es, die springt aber nicht unbedingt beim Kurzschluss eines Pins an. Und bitte nicht mit den Fuses des Mikrocontrollers durcheinanderbringen, das ist dann wieder was ganz anderes.
Beim BlinkWithoutDelay Beispiel ist das blinken ja gerade nicht unabhängig vom restlichen Code. Wenn der mehr als "delay" an Zeit benötigt, blinkt es nicht mehr richtig. Wenn man damit sowas wie PWM realisieren würde, bleibt nicht mehr viel für den eigentlichen Code. Das ganze ist dann eher sowas wie kooperatives Multitasking, bekannt aus der Windows 3.1 Zeit
Du hast es hier aber nicht mit nem multitaskingfähigen Quadcore-Prozessor mit 64bit zu tun. Wenn du den restlichen Code mit delays ausbremst, machst du definitiv was verkehrt.
Ich dachte, die PWMs wären "nur" Software, weil die ja die gleichen Interrupts verwenden, wie die anderen Timer. Wenn in den Interrupt nun für eine PWM-Software verwenden würde (statt für die eingebauten PWMs), käme ich dann auch die gleiche Leistungsfähigkeit? (nicht dass ich das vorhätte aber es trägt sicher einiges zum Verständniss bei).
Ich bin bei weitem kein Experte, was Timer und Interrupts angeht. Da sollte dir jemand beistehen, das besser versteht und besser erklären kann als ich. Udo? Wo bist du?
mwyraz:
Auf Pin13 gibt es ja kein PWM. Mit delayMicroseconds (z.B. im Verhältnix 50:1) bekomme ich die LED aber recht sauber auf ca. 50% Leuchtkraft.
Das Fade-Beispiel bekommt man damit auch ganz gut hin, ohne eine LED am PWM zu benötigen. Die eingebaute LED wird dann ja extrem oft aus- und angeschaltet - kann ich damit was kaputt machen?
Damit des LED 50% hell ist muß das Timing 50% an und 50% aus sein und nicht 50:1. Achtung, das Helligkeitsempfinden des menschlichen Auges ist nicht linear und Dein Gehirn macht auch einige automatische korrekturen.
mwyraz:
Das Input-Pullup-Beispiel wollte zunächst nicht mit einem anderen Pin außer der 2 gelingen bis mir auffiel, dass dort der Pin nicht als Konstante definiert war, so dass ich immer nur eine von 2 Stellen geändert habe. Auch hier die Frage: kann ich was kaputt machen, wenn ich aus versehen einen Pin auf OUT stehen habe und gegen GND schalte?
Der microcontroller ist ziemlich robust aber drauf ankommen würde ich es trotzdem nicht lassen. Du reskierst etwas kaputtzumachen. Was genau ist ein wenig Zufall.
mwyraz:
Ich dachte, die PWMs wären "nur" Software, weil die ja die gleichen Interrupts verwenden, wie die anderen Timer. Wenn in den Interrupt nun für eine PWM-Software verwenden würde (statt für die eingebauten PWMs), käme ich dann auch die gleiche Leistungsfähigkeit? (nicht dass ich das vorhätte aber es trägt sicher einiges zum Verständniss bei).
Die PWM-Signale werden Hardwaremäßig erzeugt. Jeweils 2 Ausgänge pro Timer. Darum funktionieren die PWM unabhängig vom abgearbeiteten Sketch. Wenn Du die PWM softwaremäßig realisierst erreichst Du nicht die mögliche max. Frequenz und der Controller ist damit beschäftigt.
Das mit dem An-Aus Verhältnis verwundert mich auch ein wenig. Aber wenn ich (sehr schnelles) 50% an und 50% aus mache, brennt die LED gefühlt mit 100% Helligkeit. Wer weiß, woran es liegt. Könnte die evtl. "träge" sein bzw. irgendwo ein Kondensator dranhängen?
Das mit dem Kurzschluss sehe ich ein, ich wollte nur wissen, ob ich vorsichtig oder sehr sehr vorsichtig sein muss - vorsichtig reicht denke ich aus.
Wenn ich auf dem PC entwickle, suspende ich nicht benutzte Threads, da die sonst die komplette CPU-Power verbraten. Wenn ich im Loop keinerlei Delay drin habe, passiert das gleiche ja auch auf dem µc (ein Loop, der 100% der CPU-Power verbrät). Ist das in irgend einer Form ungünstig? Wenn man das auf einer CPU macht, verbraucht die z.B. Unmengen an Strom.
Ansonsten wäre es ja sinnvoll, ganz auf Delays zu verzichten und zeitgesteuerte Dinge anhand der Zeit zu triggern (wenn nicht gleich via Interrupt).
Wenn man das auf einer CPU macht, verbraucht die z.B. Unmengen an Strom.
Ansonsten wäre es ja sinnvoll, ganz auf Delays zu verzichten und zeitgesteuerte Dinge anhand der Zeit zu triggern (wenn nicht gleich via Interrupt).
50 mA ( der "normale" Arduino-Stromverbrauch ohne externes wie Ethernet o.ä. ) sind Unmengen, verglichen mit getunten µA Werten.
Wenn du an Batteriebetrieb denkst, solltest du über verlustärmere Stromversorgung und sleep nachdenken, ansonsten ist das nicht sehr relevant.
Auf Delays zu verzichten ist immer gut, verwenden von Interrupts in der Arduino IDE ist einfacher als direkte Timer - Manipulationen.
Beim BlinkWithoutDelay Beispiel ist das blinken ja gerade nicht unabhängig vom restlichen Code.
Im restlichen Code ist delay() natürlich auch tabu. Die ganze loop() sollte in der Regel feststellen, dass nichts zu tun ist und sich beenden, damit sie wenige µsec später wieder das gleiche macht.
vorsichtig reicht denke ich aus
Ganz vorsichtige bevorzugen einen Arduino mit steckbarem Controller und einen 328P-PU als Reserve, da ist der Schaden auf 5 EUR begrenzt. Ausserdem fängt man dann schnell an, in Richtung "Arduino on a Breadboard" zu experimentieren.
mwyraz:
Das mit dem An-Aus Verhältnis verwundert mich auch ein wenig. Aber wenn ich (sehr schnelles) 50% an und 50% aus mache, brennt die LED gefühlt mit 100% Helligkeit. Wer weiß, woran es liegt. Könnte die evtl. "träge" sein bzw. irgendwo ein Kondensator dranhängen?
Das mit dem Kurzschluss sehe ich ein, ich wollte nur wissen, ob ich vorsichtig oder sehr sehr vorsichtig sein muss - vorsichtig reicht denke ich aus.
Wenn ich auf dem PC entwickle, suspende ich nicht benutzte Threads, da die sonst die komplette CPU-Power verbraten. Wenn ich im Loop keinerlei Delay drin habe, passiert das gleiche ja auch auf dem µc (ein Loop, der 100% der CPU-Power verbrät). Ist das in irgend einer Form ungünstig? Wenn man das auf einer CPU macht, verbraucht die z.B. Unmengen an Strom.
Ansonsten wäre es ja sinnvoll, ganz auf Delays zu verzichten und zeitgesteuerte Dinge anhand der Zeit zu triggern (wenn nicht gleich via Interrupt).
Hast Du einen Vorwidersgtand auf dem LED?
Der µController arbeitet immer mit 100% leistung auf dem Sketch da der Arduino kein Betriebsystem hat und auch kein Multitasking system ist.
Grüße Uwe
mwyraz:
Das mit dem An-Aus Verhältnis verwundert mich auch ein wenig. Aber wenn ich (sehr schnelles) 50% an und 50% aus mache, brennt die LED gefühlt mit 100% Helligkeit. Wer weiß, woran es liegt. Könnte die evtl. "träge" sein bzw. irgendwo ein Kondensator dranhängen?
Ein Kondensator hängt da nicht drin, dein Auge ist träge und eine Helligkeit können Menschen sowieso schlecht beurteilen - siehe Uwes Posting.
Wenn ich auf dem PC entwickle, suspende ich nicht benutzte Threads, da die sonst die komplette CPU-Power verbraten. Wenn ich im Loop keinerlei Delay drin habe, passiert das gleiche ja auch auf dem µc (ein Loop, der 100% der CPU-Power verbrät). Ist das in irgend einer Form ungünstig? Wenn man das auf einer CPU macht, verbraucht die z.B. Unmengen an Strom.
Die Architektur kann man nicht direkt vergleichen. Es ist ein Irrglaube, wenn man denkt, dass man in Delays Strom sparen könnte. Das geht hier nur durch die Sleep-Modi - zum Aufwecken kommen dann jedoch wieder die Interrupts ins Spiel. Sinnvoll ist dies durchaus bei batterie- bzw. akkubetriebenen Schaltungen, die auf lange Haltbarkeit ausgelegt sind, der durchschnittliche Arduino-Nutzer kümmert sich darum nicht. Er verbrät lieber 7V am Spannungsregler...
Keine Ahnung, das ist die eingebaute LED - ich teste heute Abend nochmal ein wenig rum.
Hab mir eben erst das Breadboard bestellt, damit ich ein wenig Hardware dranbasteln kann Dann kram ich auch gleich mal in der Hardware-Kiste, was sich an Peripherie finden lässt und an den Arduino passt. Ein Nokia E60 gibt's auf jeden Fall noch aber da habe ich nichts zum Display finden können.
Das mit den 100% Leistung leuchtet mir ein. D.h. man kann eigentlich kaum was "falsch" programmieren, solange die Software das macht, was sie soll.
Wenn der Arduino mehrere zeitgesteuerte Dinge gleichzeitig machen soll, wäre es dann sicher sinnvoll, das zu abstrahieren oder gleich eine Timer-Lib zu suchen/zu schreiben. Ich kann mir vorstellen, dass der Sketch kaum noch wartbar ist, wenn man 10 verschiedene Funktionen in 10 verschiedenen Intervallen betreiben möchte...
mwyraz:
Wenn der Arduino mehrere zeitgesteuerte Dinge gleichzeitig machen soll, wäre es dann sicher sinnvoll, das zu abstrahieren oder gleich eine Timer-Lib zu suchen/zu schreiben. Ich kann mir vorstellen, dass der Sketch kaum noch wartbar ist, wenn man 10 verschiedene Funktionen in 10 verschiedenen Intervallen betreiben möchte...
Ich glaube du unterschätz auch ein bisschen die Performance des kleinen ATMega. Ich habe auf einem 328 eine Ladedruckregelung für meinem Volvo laufen der hat 13kB Programm ca 700 Zeilen Code und ich habe eine "Zykluszeit" von 3ms das heisst der schaut bei meinem "Blink without delay" 333mal in der Sekunde vorbei ob er da schon was "machen" muss. Also wenn du keine Ultraschnellen Berechnungen bzw Steuerungen machen musst kannst du das alles erstmal in der Loop machen. Wenn das nicht klappt kannst du die Timmer LIB nutzten.
Ist einfacher vom Handling her als "Anfänger". Je kompakter bzw. kleiner dein Programm desto schneller ist der kleine. Alles vorrausgesetzt du nutzt keine delays!
