Hi, ich habe einen Mega16 mit 20 Tasten. Ich möchte - abhängig von der Betätigungsart - verschiedene Funktionen ausführen. Als Betätigung kommen in Betracht: Kurz oder Lang drücken sowie Doppelklick. Die Abfrage macht mir im Moment Kopfzerbrechen. Wer hat eine Idee wie man sowas machen könnte? Welche Strategie würdet Ihr nutzen? Timer mit Interupt? Polling mit Zähler ? Wer hat ne Idee ? Gruß und Danke Andreas
Peter Dannegger hat in der Code-Sammlung eine sehr gute Tastenentprellung mit Abfrage auf kurz und lang geschrieben. Diese lässt sicher bestimmt so erweitern wie du es haben möchtest. Gruß, Dominik
Hi, hole den Thread nochmals hoch ... Vielleicht erbarmt sich ja doch jemand :-) Ich habe mir Peters Routine angesehen und versucht zu vertehen. Irgendwie bringt mich das nicht richtig weiter. Zumal ich in C arbeite und seine Routine in Assembler ist. Ich möchte im übrigen auch keinen fertigen Code sondern habe Interesse an der Information wie sowas "normalerweise" professionell gemacht wird. Im Moment denke ich über eine Kombi aus Timerinterrupt (alle 0,1s) und Polling in der Routine nach. Bei gedrückter Taste wird dann ein globaler Zahlenwert ermittelt. Damit kann mal sehr schnell und einfach die Entprellung und das "lang-Drücken" machen. allerdings funzt das nicht mehr (ohne riesigen Aufwand) beim Doppelklick .... Nochmals: Wer hat ne Idee ? Gruß Andreas
Würde es was bringen, bei einem Tastendruck einen Counter o.ä. runterzuzählen, und wenn innerhalb der Counterzeit nochmals die gleiche Taste gedrückt wird, ein "Doppelklick-Flag" zu setzen? Ralf
Die Erkennung eines Doppelklicks hat immer etwas mit - der Benutzer klickt und der Rechner misst die Zeit zwischen den Klicks - zu tun Ergo ja: Das würde was helfen. Das Problem beim Doppelklick ist doch nicht die Erkennnug, die ist trivial. Das Problem ist: Du musst beim ersten Klick einen einfach Klick detektieren (und auch weitergeben) und wenn dann in einer gewissen Zeit noch ein zweiter Klick kommt, dann gilt der als Doppelklick. Dein Anwenderprogramm hat aber den Einfachklick schon bearbeitet, der jetzt eigentlich zurückgenommen werden müsste und durch einen Doppelklick ersetzt wird. Daher findest du in Windwos fast ausnahmslos die Syswtematik: Ein einfacher Klick selektiert ein Doppelklick führt aus. Dadurch gibt es keine Probleme, denn der Einfachklick selektiert ein Objekt und der darauffolgende 'Upgrade' auf Doppelklick führt eine Aktion aus. Aber ansonsten: sei kreativ: Da gibt es kein richtig und kein falsch. Was immer du als richtig definierst ist richtig.
Den Code von Peter gibt es auch in C - suchen hilft. Ich selbst habe die Routine auch erweitert um zwischen "kurz" - "lang" - und "gedrückt halten" zu unterscheiden.
uboot-stocki wrote: > kommen in Betracht: Kurz oder Lang drücken sowie Doppelklick. Hast Du mal überlegt, was Du da vorhast ? Wenn Du alle 3 Sachen implementierst, ist das Gerät unbedienbar, zumindest für andere. Doppelklick habe ich auch nur mit Maus gesehen, nie mit Tasten. Der Grund dürte das fehlende visuelle Feedback sein. Dafür erkennt die Maus kein lange Drücken. Kurz und lang Drücken dürfte schon komplex genug sein: Beitrag "Universelle Tastenabfrage" Peter
@Peter Dannegger >Wenn Du alle 3 Sachen implementierst, ist das Gerät unbedienbar, >zumindest für andere. Hmm, würde ich nicht so pauschal sagen. Wahrscheinilch hat er ein LCD oder LEDs, oder oder oder. Blindbedienung ist so oder so nicht sonderlich rauchbar. >Doppelklick habe ich auch nur mit Maus gesehen, nie mit Tasten. Der >Grund dürte das fehlende visuelle Feedback sein. Dafür erkennt die Maus >kein lange Drücken. Doch! Klick mal im Windows Explorer kurz auf eine Datei. Sie wird selektiert. Klicke nun mal "lang" drauf. Du kannst sie nun umbenennen. Dito mit dem USB-Symbol rechts unten zum Auswerfen von USB-Geräten. >Kurz und lang Drücken dürfte schon komplex genug sein: ??? Eine einfache Zählerauswertung. Sobald der Taster aktiv ist läuft ein Zähler hoch. Ist der Taster plötzlich nicht mehr aktiv (quasi High-Low Flanke) wird anhand des Zählerstandes entschieden ob es ein langer oder kurzer Tastendruck war. Dito für Doppelclick, hier muss das gleiche mit der Pause zwischen zwei steigenden Flanken gemacht werden. Das klingt für mich fast nur nach ner Fleissaufgabe + bissel clevere Schreibweise. Das Ganze dann per 10ms Timer periodisch aufrufen. MFG Falk
Falk wrote: >>Kurz und lang Drücken dürfte schon komplex genug sein: > > ??? Natürlich nicht die Implementierung, sondern rein aus der Sicht des Benutzers. > Eine einfache Zählerauswertung. Sobald der Taster aktiv ist läuft ein > Zähler hoch. Ist der Taster plötzlich nicht mehr aktiv (quasi High-Low > Flanke) wird anhand des Zählerstandes entschieden ob es ein langer oder > kurzer Tastendruck war. Hab ich doch gemacht. Das der Kurzdruck erst bei Loslassen reagiert, ist aber gewöhnungsbedürftig, der Nutzer erwartet erstmal die Reaktion beim Drücken. Diese Funktion sollte man daher sparsam einsetzen (nur, wenn unbedingt nötig). Deshalb habe ich auch ne Maske definiert, damit nur wenige Tasten so erweitert sind. > Dito für Doppelclick, hier muss das gleiche mit > der Pause zwischen zwei steigenden Flanken gemacht werden. Dagegen weigere ich mich. Schon die Vorstellung, mein Videorekorder hätte Doppelklickfunktionen, würde mich rasend machen. Ein solches Gerät würde wegen völliger Unbedienbarkeit sofort zurück gehen. Peter
Ein-Knopf-Bedienung ist die dümmste Idee seit dem Gorilla-Arm-Syndrom. http://jargon.watson-net.com/jargon.asp?w=gorilla+arm
@Peter Dannegger >Das der Kurzdruck erst bei Loslassen reagiert, ist aber >gewöhnungsbedürftig, der Nutzer erwartet erstmal die Reaktion beim >Drücken. Würde ich nicht so sehen. Aber Bedienphilosophien von Geräten sind eine Wissenschaft für sich. >> Dito für Doppelclick, hier muss das gleiche mit >> der Pause zwischen zwei steigenden Flanken gemacht werden. >Dagegen weigere ich mich. >Schon die Vorstellung, mein Videorekorder hätte Doppelklickfunktionen, >würde mich rasend machen. >Ein solches Gerät würde wegen völliger Unbedienbarkeit sofort zurück >gehen. Du benutzt ein solches Gerät jeden Tag. Nennt sich Computer. Genauer Maus. Und schau dir nur die armen MAC-User an. Die haben nur EINE Taste! ;-) MFG Falk
Bernhard wrote:
> Ein-Knopf-Bedienung ist die dümmste Idee seit dem Gorilla-Arm-Syndrom.
Ja, das wär am besten:
Wenn ich dann auf dem Rekorder aufnehmen will, drücke ich einfach:
.- ..- ..-. -. .- .... -- .
Bloß nicht an den Benutzer denken, Usability ist ja schließlich ein
Fremdwort.
Peter
>Wenn ich dann auf dem Rekorder aufnehmen will, drücke ich einfach: >.- ..- ..-. -. .- .... -- . Einige MP3-Player kommen da schon ganz schön nahe dran.
@Bernhard >>Wenn ich dann auf dem Rekorder aufnehmen will, drücke ich einfach: >>.- ..- ..-. -. .- .... -- . ;-) >Einige MP3-Player kommen da schon ganz schön nahe dran. Sowas lässt sich im SMS-Zeitalter problemlos verkaufen. Es ist aber auch ein Dilema. Die Geräte schrumpfen ohne Ende, da ist kein Platz für Tasten und Displays. Sprachsteuerung ist bisher nur begrenzt tauglich, Telemetrie durch Telepathie hat auch so seine Probleme ;-) MfG Falk
Is aber doch Schmarrn! Warum werden die Geräte dann immer kleiner gebaut, wenn man sie dann nur noch mit Zahnstocher oder Morsecode bedienen kann? Das gute alte Nokia 5110 hat doch schließlich auch inne Hosen- bzw. Handtasche gepasst. Bei einigen neuen Modellen hab ich echte Probleme, nur eine Taste zu drücken. Und ich finde nicht dass ich solche derben Wurstfinger hab :P
Hallo,
erstmal vielen Dank für Euere Kommentare. Ich bin nicht der Profi-Coder
aber ich habe vermutet sowas gibts schon. Offensichtlich ist das aber
nicht der Fall, da es Usability-Problene gibt.
Daher beschreibe ich jetzt mal was ich vor habe, vielleicht kann jemand
von euch einen Kommentar abgeben:
Es geht um eine Rolladensteuerung. Ich habe nur eine Taste um den
Rolladen zu bedienen (sebstverständlich gibt es 2 Tasten - eine für
"hoch" und die Andere für "runter") aber ich beschränke mich im
Folgenden auf eine allgemeine Taste (gilt für beide).
Wird die Taste einmal "kurz" gedrückt fährt der Rolladen bis an seine
Endposition (Der Rolladen fährt los, sobald die Taste gedrückt wird -
also noch vor dem Loslassen)
Wird die Taste "lang" gedrückt ("gehalten") fährt der Rolladen bis die
Taste losgelassen wird (Der Rolladen fährt los, sobald die Taste
gedrückt wird - also noch vor dem Loslassen)
Der viel diskutierte Doppelklick soll alle Rollläden im gesamten Haus in
die jeweilige Endposition fahren (Der erste Rolladen fährt los, sobald
die Taste gedrückt wird - also noch vor dem ersten Loslassen, die
restlichen sobald der Doppelklick erkannt wird)
M.E. nach ist das einen sehr gute Lösung. Wo sind Euere Kommentare ?
Gruß
Andreas
@uboot-stocki
>M.E. nach ist das einen sehr gute Lösung. Wo sind Euere Kommentare ?
Sehe ich auch so.
MfG
Falk
Ich habe es bei mir genau andersherum gemacht: kurzer Tastendruck bewegt kurz, langer Tastendruck fährt bis ans Ende. Allerdings habe ich auch Jalousien statt Rolläden, da werden definierte kurze Fahrzeiten benötigt, um den Jalousiewinkel einzustellen. Das Ganze funktioniert genau wie die Fensterheber im Auto. >Der viel diskutierte Doppelklick soll alle Rollläden im gesamten Haus in >die jeweilige Endposition fahren (Der erste Rolladen fährt los, sobald >die Taste gedrückt wird - also noch vor dem ersten Loslassen, die >restlichen sobald der Doppelklick erkannt wird) Vielleicht einen SEHR langen Tastendruck einführen, der dann alle Rolläden anspricht? Bei mir läuft die Tastenerkennung komplett im Timer-IR (ähnlich wie bei Peters Version). Das Hauptprogramm bekommt folgende Werte zurück: key_pressed key_released key_long_pressed key_long_released Damit kannst Du im Hauptprogramm praktisch alle Möglichkeiten. Gruß, Stefan
Hi, Ihr seht den Weg über den Timerinterrupt aber als den besten an? D.h. der Timerinterrupt wird ausgelöst und in der Interrupt-Routine wird die Taste gepollt? Alternativ könnte man ja auch einen Interrupt auslösen sobald eine Taste gedrückt wird? Mir ist übrigens aufgefallen, dass bei großen Interrupt-Zeiten (100ms pro UP-Aufruf) ein Entprellen nicht mehr nötig ist. Entspricht das Eueren Erfahrungen ? Gruß Andreas
@uboot-stocki >Ihr seht den Weg über den Timerinterrupt aber als den besten an? D.h. Ja. >der Timerinterrupt wird ausgelöst und in der Interrupt-Routine wird die >Taste gepollt? Ja. >Alternativ könnte man ja auch einen Interrupt auslösen sobald eine Taste >gedrückt wird? Nein. Das hatten wir schon. Warum? Siehe unten. >Mir ist übrigens aufgefallen, dass bei großen Interrupt-Zeiten (100ms >pro UP-Aufruf) ein Entprellen nicht mehr nötig ist. Entspricht das >Eueren Erfahrungen ? Genau DAS ist der Punkt. Durch das Pollen wird automatisch entprellt, während dein flankensensitiver Interrupt jeden Preller anzeigt. MFG Falk
>während dein flankensensitiver Interrupt jeden Preller anzeigt.
Nicht wenn du nach dem ersten INT diesen für 20ms sperrst. Dann ersparst
du dir das 100ms-gepolle.
@Sonic >>während dein flankensensitiver Interrupt jeden Preller anzeigt. >Nicht wenn du nach dem ersten INT diesen für 20ms sperrst. Dann ersparst >du dir das 100ms-gepolle. Ach ja? Und wie sperre ich ihn für 20 ms ohne den Prozessor in eine Delay Schleife zu verbannen? Mit nem Timer! Womit wir wieder bei der ursprünglichen Variante mit Timer Polling wären. Q.E.D. Falk
>Womit wir wieder bei der ursprünglichen Variante mit Timer Polling wären.
Nein!
Der Timer muss nur einen Zyklus machen, dann wird er wieder angehalten
(und kann für andere Zwecke verwendet werden). Um einen Taster ca. 20x
am Tag abzufragen muss man ihn nicht knapp 52 mio. mal abfragen. da legt
man den µC besser Schlafen.
Immer die verhältnismäßigkeit der Mittel im Auge behalten! ;-)
@ Sonic >>Womit wir wieder bei der ursprünglichen Variante mit Timer Polling wären. >Nein! >Der Timer muss nur einen Zyklus machen, dann wird er wieder angehalten >(und kann für andere Zwecke verwendet werden). Um einen Taster ca. 20x Der Timer kann so und so für andere Zwecke benutzt werden. Wer sagt, dass ein Timer ausschliesslich für Tastenentprellung verwendet werden kann? >am Tag abzufragen muss man ihn nicht knapp 52 mio. mal abfragen. da legt >man den µC besser Schlafen. Ok, in DIESEM Fall hast du wohl Recht. Aber wenn es um ein Gerät geht, welches ONLINE bedient wird mit LCD etc., ist die Timer Poll Methode IMHO die bessere Wahl. >Immer die verhältnismäßigkeit der Mittel im Auge behalten! ;-) Aber sicher. ;-) MfG Falk
>ist die Timer Poll Methode IMHO die bessere Wahl.
Geschmacksache. Ist jedem je nach Vorliebe selber überlassen.
Sonic wrote: > Der Timer muss nur einen Zyklus machen, dann wird er wieder angehalten > (und kann für andere Zwecke verwendet werden). Wie soll denn ein Timer noch andere Sachen machen, wenn er nicht freilaufend ist ? Irgendwie blöd, wenn die RTC nur geht beim Tastendrücken. Die Leute, die Timer anhalten schreien ganz schnell: "zu wenig Timer": Die anderen mit freilaufendem Timer sagen: "Wieso, ich hab sogar noch 2 übrig" (bei 3 Timern). Peter
>Irgendwie blöd, wenn die RTC nur geht beim Tastendrücken.
Du betreibst die RTC in 1/100s-Auflösung? Brauchst du diese Auflösung?
Naja, man kann's so machen, von eine Uhr war ja auch keine Rede, oder
hab' ich das überlesen?
"für andere Zwecke", damit meine ich Zählaufgaben, Frequenzmessung oder
andere Aufgaben die mit dem freilaufenden Timer nicht realisiert werden
können.
Wenn ich viele Zählvorgänge habe, die zeitgenau sein müssen mache ich
das auch mit einem freilaufenden Timer und verschiedenen Teilern darin,
aber nur wenn's unbedingt sein muss (Stoppuhr oder ähnliches.
Die eigendliche Tastenauswertung würde ich auf jeden Fall als Timer-IR machen. Per INT ist die Sache wesentlich komplizierter: Du musst nicht nur das Ein-Prellen, sondern auch das Aus-Prellen beachten. Ein Timer wird ja in jedem Fall benötigt, um lange Tastendrücke zu erkennen. Bei der INT-Methode können zudem Störungen die Tastenerkennung wesentlich leichter fehlerhaft auslösen. Die 20 Tasten des OP werden sehr wahrscheinlich als Matrix ausgewertet -> das Aus für die INT-Erkennung (würde ggf. mit einem moderneren ATmega funktionieren mit Pin-On-Change-Interrupts). Den verwendeten ATmega16 legt man wohl eh nur ungern in den Tiefschlaf, da er von sich aus nie mehr aufwachen kann (nur möglich durch externes Ereignis per INT-Pin). Auch da sind die modernen ATmega besser: die haben einen Watchdog-Timer, der den mc wecken kann, auch wenn der Quarz abgeschaltet ist. Mein Vorschlag, wenn ein Powerdown-Mode > Idle benötigt wird: * einen modernen ATmega verwenden * Tastenerkennung wie gehabt per Timer * Aufwecken aus dem Tiefschlaf separat per Pin-On-Change-IR Gruß, Stefan
Ich würds so machen: 1* klick: fahren, solange man drückt 2* klick: fahren bis zum Anschlag 3* klick: alle fahren bis zum Anschlag Ich denke aber, egal wie, es ist immer gewöhnungsbedürftig. Und da die Tasten ja bestimmt nicht nebeneinander sind, würde ich jedem Rolladen einen eigenen ATTiny13 spendieren: 2* Tasten, 2* Motor, 1* open drain für alle gleichzeitig. Peter
Sonic wrote: >>Irgendwie blöd, wenn die RTC nur geht beim Tastendrücken. > Du betreibst die RTC in 1/100s-Auflösung? Brauchst du diese Auflösung? Die Interruptfrequenz bestimmt das schnellste benötigte Intervall und alle anderen werden mit Zählvariablen daraus abgeleitet. Ist einfacher, als getrennte Timer nehmen. Und ob der Interrupt nun 1% oder 0,01% CPU-Zeit verbraucht, ist doch egal. Peter
Dann bleibt der Rolladen zwischen dem 1. und 2. klick stehen. Finde ich nicht so schön. Kurz/lang Drücken gibt es in vielen anderen Geräten, aber einen Doppelklick auf (Licht-)Taster habe ich noch nie gesehen. Deswegen wird der unbedarfte Benutzer das auch nicht probieren (und stattdessen den Taster drücken, bis der Rolladen unten ist). Gruß, Stefan
>Die Interruptfrequenz bestimmt das schnellste benötigte Intervall und >alle anderen werden mit Zählvariablen daraus abgeleitet. Ist bekannt, wird in der SPS-Programmierung auch so gemacht (mach ich übrigens auch). Nur kann's bei zeitkritischen Aufgaben wie Datenübertragung per USART (externes RAM, größere Datenmengen) oder einem Grafikdisplay zu unschönen Verzögerungen kommen. Habe das mal mit einer RTC mit Timer1 und dem Async.-Timer (ext. Quarz) an Timer2 verglichen, Datenausgabe über USART, 512kB, 115200 baud, da war ein ziemlicher Zeitunterschied bei OCR-INT alle 0.1s. bei 1s ging das Ganze schon schneller. Das Grafikdisplay hat sich auch in Zeitlupe aktualisiert. Aber wie gesagt: das ist die Freiheit jedes Einzelnen wie er das umsetzt, je nach Geschmack.
@ Sonic >Ist bekannt, wird in der SPS-Programmierung auch so gemacht (mach ich >übrigens auch). naja, SPS ist aber auch so ein Murks an sich . . . >Nur kann's bei zeitkritischen Aufgaben wie Datenübertragung per USART >(externes RAM, größere Datenmengen) oder einem Grafikdisplay zu >unschönen Verzögerungen kommen. Nicht wenn mans richtig macht. >Habe das mal mit einer RTC mit Timer1 und dem Async.-Timer (ext. Quarz) >an Timer2 verglichen, Datenausgabe über USART, 512kB, 115200 baud, da >war ein ziemlicher Zeitunterschied bei OCR-INT alle 0.1s. bei 1s ging >das Ganze schon schneller. >Das Grafikdisplay hat sich auch in Zeitlupe aktualisiert. Du konstruierst gern Katastrophen ;-) >Aber wie gesagt: das ist die Freiheit jedes Einzelnen wie er das >umsetzt, je nach Geschmack. Jain. Es gibt schon ein paar handfest Vorteile der Timermethode. MFG Falk P.S. Was wäre die Welt ohne religiösen Strei? ;-)
>Du konstruierst gern Katastrophen ;-) Definitiv ja! Um Schwächen zu finden muss man halt viel probieren und spielen. Ich mach' meine Erfahrungen gerne selber, dann merkt sich's bessser! ;-) >Nicht wenn mans richtig macht. Wie mache ich's denn richtig? Der Programmablauf wird definitiv alle 1/100s unterbrochen und wartet solange, bis die Uhr und alles Andere was in die INT-Routine muss, abgearbeitet ist. Und wenn da noch weitere Zähler drin sind dauert's halt einige Taktzyklen. Da beißt keine Maus einen Faden ab! >Es gibt schon ein paar handfest Vorteile der Timermethode. richtig, kommt aber immer auf den Anwendungsfall an.
@ Sonic >Definitiv ja! Um Schwächen zu finden muss man halt viel probieren und >spielen. Ich mach' meine Erfahrungen gerne selber, dann merkt sich's >bessser! >;-) Naja, man sollte aber im wesentlichen aus den Fehlern anderer lernen, das ist effektiver und bisweilen schwerzfrei. >>Nicht wenn mans richtig macht. >Wie mache ich's denn richtig? Der Programmablauf wird definitiv alle >1/100s unterbrochen und wartet solange, bis die Uhr und alles Andere was >in die INT-Routine muss, abgearbeitet ist. Und wenn da noch weitere Ja und? >Zähler drin sind dauert's halt einige Taktzyklen. Da beißt keine Maus >einen Faden ab! Wahnsinn, diese Erkenntnis! Viele Wege führen nach Rom, there are many ways to skin a cat. Man kann SEHR viel in die Main Loop legen und nur die Steuervariablen in den Interrupts schalten. Ist aber alles reichlich akademisch ohne das reale Problem direkt auf dem Tisch zu haben. MFG Falk
>Ja und? Daraus folgere ich, dass du sowas noch nicht realisiert und aufgebaut hast. >Man kann SEHR viel in die Main Loop legen und nur die Steuervariablen in den Interrupts schalten. Guten Morgen, alter Zopf! >Naja, man sollte aber im wesentlichen aus den Fehlern anderer lernen, >das ist effektiver und bisweilen schwerzfrei. Richtig, vor allem beim Heiraten! ;-) Trotzdem: "curiosity killed the cat", um bei den Anglizismen zu bleiben, abgucken, nachbauen, Gedanken machen wie's besser geht.
Sonic wrote: > Wie mache ich's denn richtig? Der Programmablauf wird definitiv alle > 1/100s unterbrochen und wartet solange, bis die Uhr und alles Andere was > in die INT-Routine muss, abgearbeitet ist. Und wenn da noch weitere > Zähler drin sind dauert's halt einige Taktzyklen. Da beißt keine Maus > einen Faden ab! Nehmen wir mal an, daß ist wirklich ne sehr große Interruptroutine, also etwa 1000 Zyklen. Das sind dann bei 100Hz*1000/10MHz gerade mal 1% CPU-Last. Eher hört man Flöhe 1km weit husten, als 1% weniger CPU-Leistung zu bemerken. Peter
>Eher hört man Flöhe 1km weit husten
Dann rechne das doch mal in Zeit um, wenn du 512kB Daten per USART
ausgibst.
Da können dich die hustenden Flöhe schon mal 7 Sekunden kosten ;-)
Sonic wrote: > Dann rechne das doch mal in Zeit um, wenn du 512kB Daten per USART > ausgibst. Häää ??? Du hältst den Timerinterrupt so lange an, bis aus der UART 512kB rausgeschlichen sind ? Wer macht denn solchen Quatsch. Der Timerinterrupt macht sein Ding und der UART-Interrupt die Datenausgabe und gut is. Wozu hat man denn schließlich verschiedene Interrupts. Peter
Hi, also ... zur weiteren Klärung: Ich habe vor EINE Steuerung zu bauen. Die sitzt dann im Sicherungskasten neben den Relais für die Rolläden. Für 8 Rolläden benötige ich 16 Eingänge und 16 Ausgänge. Deshalb habe ich den Mega16 gewählt. Natürlich habe ich auch 16 Relais ... Von jedem Schalter aus sollen die drei vorher beschriebenen Funktionen anwählbar sein. Ich baue diese Steuerung nur für mich und habe nicht vor sie zu verkaufen. Die Interrupt-Geschichte hätte genau den Nachteil, dass ich die 16 Eingänge über ein externes Oder (16 Dioden) auf den Interrupt-Eingang des Megas legen müsste. Ich versuche das Projekt mit so wenig Bauteilen wie möglich zu realisieren, da in dem Sicherungskasten nicht viel Platz ist und ich keine Platinen o.ä. Ätzen kann - schon gar kein SMD. Daher wird das wohl ein Lochraster-Aufbau werden. Ausser einer Aufbereitung der Betriebsspannung, des Megas selbst und 16 Logic-Level Fets sowie jede Menge Klemmen brauche ich eigentlich nichts weiter (Evtl. noch ein paar Widerstände um die Taster mit einem definierten Strom betreiben zu können) Daher denke ich, dass die Timer-Methode die bessere für mich ist, zumal ich sowieso einen "Systemtakt" brauche, da die Laufzeit der Rolläden unterschiedlich ist, muss ich unterscheidliche Impulszeiten für die Relais ausgeben. Vielleicht habt Ihr ja noch ein paar Kommentare zu meinen Überlegungen ... Gruß und schonmal Danke für Euere Inputs Andreas
Schon richtig. Aber irgendwann musst du die Daten ins UDR schreiben. Im schlimmsten Fall hast du bei 10MHz Taktfrequenz 524288 Byte * 100µs (INT-Abarbeitung) = 52.43s Da alle 115.2 Bytes (10 Bit) ein INT (1/100s) ausgeführt wird ergibt sich eine theoretische Verzögerung von 0.46s. Dazu kommt das Datenauslesen aus dem SRAM und diverse andere Kleinigkeiten in der main-loop. So kommst du schnell auf 7s. In meiner Anwendung jedenfalls.
>524288 Byte * 100µs (INT-Abarbeitung) = 52.43s >Da alle 115.2 Bytes (10 Bit) ein INT (1/100s) ausgeführt wird ergibt >sich eine theoretische Verzögerung von 0.46s. keine Ahnung was du da rechnest, wieso für jedes Byte ein Mal Timerinterupt? ich kann mich nur Peter anschließen: >Der Timerinterrupt macht sein Ding und der UART-Interrupt die >Datenausgabe und gut is.
Die Interrupts arbeiten nicht gleichzeitig. Und irgendwann muss ich dem USART sagen dass es senden soll (UDR beschreiben), wenn das vom INT blockiert wird dauert's eben länger bis gesendet wird. Nun gut, das gehört nicht hierher, vielleicht mach' mal einen eigenen Thread hierzu auf (soll keine Drohung sein ;-))
@Sonic, also ich rechne mal: Quarz = 16MHz Baudrate: 115200 Baud = 11520 Byte/s 16MHz / 11520 = 1388 Zyklen. Worst Case: Timerinterrupt kommt genau dann, wenn der Sendepuffer leer ist. Ein neues Byte muß reingeschrieben werden, ehe das Schieberegister leer ist, d.h. man hat genau eine Bytezeit Reserve. Also ein Timerinterrupthandler + UART-Interrupt Sendepuffer laden bis zu 1388 Zyklen Dauer verzögert die UART um genau garnichts (0µs). Peter
>Nun gut, das gehört nicht hierher
Erklärungsnotstand? ;-)
uboot-stocki wrote:
> Vielleicht habt Ihr ja noch ein paar Kommentare zu meinen Überlegungen
Ja, ist o.k., Batteriebetrieb brauchst Du ja nicht, also ist das mit dem
externen Interrupt eh nicht sinnvoll.
Die Tasten würde ich über Optokoppler entkoppeln.
Ob das Bedienkonzept hinhaut, hängt ganz davon ab, welche weiteren
Personen (Geschlecht, Alter) die Rollläden noch bedienen wollen :-)
Peter
@ Sonic >>Ja und? >Daraus folgere ich, dass du sowas noch nicht realisiert und aufgebaut >hast. ???? Ist das wieder die Sonic-Logik? Das "Ja und" heisst so viel wie "Schön und gut, aber was willst du damit sagen?". MFG Falk
@ uboot-stocki >Ich habe vor EINE Steuerung zu bauen. Die sitzt dann im Sicherungskasten >neben den Relais für die Rolläden. Für 8 Rolläden benötige ich 16 >Eingänge und 16 Ausgänge. Deshalb habe ich den Mega16 gewählt. Natürlich >habe ich auch 16 Relais ... Ach so, du brauchst den MEGA8 wegen der grossen Anzahl IO Pins. OK. >Die Interrupt-Geschichte hätte genau den Nachteil, dass ich die 16 >Eingänge über ein externes Oder (16 Dioden) auf den Interrupt-Eingang >des Megas legen müsste. Vergiss das. Polling und gut. >Ich versuche das Projekt mit so wenig Bauteilen wie möglich zu >realisieren, da in dem Sicherungskasten nicht viel Platz ist und ich >>Betriebsspannung, des Megas selbst und 16 Logic-Level Fets sowie jede Für 16 Relais solltest du 2x ULN2803 nehmen, die sind wesenlich kleiner und kompakter zu handhaben (Chip auf Lochraster stecken, verlöten, fertig.) MFG Falk
Was mich noch etwas stört: Hast du für die Rolläden keine Endschalter? Mit der Methode: Motor A muss 10 Sekunden laufen um die Endstellung zu erreichen hätte ich keine grosse Freude.
@ Falk und Peter D.: ihr scheint es nicht so mit dem Arbeiten zu haben, schließlich seit ihr fast rund um die Uhr hier im Forum vertreten. Also frage ich mich wo ihr irgendwelche Erfahrung hernehmen wollt? Da man hier NICHTS schreiben kann, ohne von derlei selbsternannten Experten auf eine sehr unschöne Art gemaßregelt zu werden, werde ich mich zukünftig auf lesenden Zugriff beschränken. Das dürfte euch doch auch recht sein, oder? Ihr merkt gar nicht mehr wie verbohrt ihr versucht, Anderen eure Weisheiten aufzudrücken, ohne irgendwelche anderen Lösungen auch nur ansatzweise in Betracht zu ziehen!
@ Sonic >ihr scheint es nicht so mit dem Arbeiten zu haben, schließlich seit ihr >fast rund um die Uhr hier im Forum vertreten. Also frage ich mich wo ihr Mach dir mal keine Sorgen um unser Arbeitszeitmodell. >Da man hier NICHTS schreiben kann, ohne von derlei selbsternannten >Experten auf eine sehr unschöne Art gemaßregelt zu werden, werde ich Massregeln? Kann es ein, dass du nicht sonderlich gut mit Kritik umgehen kanns? >mich zukünftig auf lesenden Zugriff beschränken. Das dürfte euch doch >auch recht sein, oder? Ihr merkt gar nicht mehr wie verbohrt ihr >versucht, Anderen eure Weisheiten aufzudrücken, ohne irgendwelche >anderen Lösungen auch nur ansatzweise in Betracht zu ziehen! Das haben wir/ich. Aber wir haben auch Argumente dagegen. Ist natürlich auch ein Lösung, die beleidigte Leberwurst spielen wenn einem die sachlichen Argumente ausgehen. MfG Falk, gegenüber konstruktiver Kritik immer offen
Hi, @Falk: Das mit den 2x ULN2803 habe ich noch garnicht bedacht. Ist sicherlich die einfachste Lösung - vielen Dank für den Tipp !! @Karl-Heinz: In den Rolläden sind selbstverständlich auch Endschalter verbaut. Mir schwebt (für eine spätere Ausbaustufe) vor, die Rolläden auch auf Position "halb" oder "dreiviertel" zu fahren. Ich denke da eine Sonnenstandsabhängige Steuerung ... sowas geht sicher nur über die Laufzeit der Rollläden. Als Vision habe ich da einen Lernmodus ... Jetzt beschäftige ich mich erstmal mit den Basics - habe immernoch Probleme mit meinem Doppelklick ... Gruß Andreas
Wenn Du zuwenig Pins für die ULN2803 hast: von TI gibt es ähnliche mit SPI-Eingang. Kannst Du hintereinander hängen und brauchst dann nur 4 Pins. TPIC6B595 Gibt es z.B. bei Segot. Gruß, Stefan
Wegen Endschalter: ich verwende bei einem Schiebeladen einfach den Motorstrom: der Laden fährt gegen eine mechanischen Anschlag, bei einem plötzlichen Stromanstieg schalte ich aus. Das ist auch ganz gut wenn jemand den Kopf reinsteckt ...
Sonic wrote: > Da man hier NICHTS schreiben kann, ohne von derlei selbsternannten > Experten auf eine sehr unschöne Art gemaßregelt zu werden, Huch, da ist aber einer angefressen. Ich komme gleich mal vorbei, Köpfchen tätscheln. Die Sache ist doch die, daß Du behauptet hast, Timerinterrupts würden merkbar Ressourcen fressen, aber nicht den geringsten Beweis (Beispielcode) dafür lieferst. Und ich hab daraufhin nur mal ausgerechnet, daß es im Promillebereich, also unmerkbar ist. Ich hab eigentlich kein Programm ohne schnellen Timerinterrupt. Wenn mir da auch nur 10% CPU Zeit verloren gingen, hätte es längs auffallen müssen. In der Regel sind die Programme aber sogar schneller, als funktionsgleiche andere Lösungen. > Anderen eure Weisheiten aufzudrücken, ohne irgendwelche > anderen Lösungen auch nur ansatzweise in Betracht zu ziehen! Nö, ich lerne gerne dazu. Bloß dann müßtest Du erstmal ne bessere Lösung zeigen. Ich kann nichts einschätzen und daran lernen, wenn Du nichts zeigst. Ich kann ja nicht hellsehen, womit Deine Timerinterrupts solche Unmengen von Zeit verbrauchen. Ich versuche jedenfalls, alle Interrupthandler möglichst kurz zu halten. Peter
Beitrag #5091953 wurde von einem Moderator gelöscht.
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.