Da war ich mal wieder zu langsam. Ist doch ne schöne Fingerübung gewesen:
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
13 | |
14 | |
15 | |
16 | |
17 | |
18 | |
19 | |
20 | |
21 | |
22 | |
23 | |
24 | |
25 | |
26 | |
27 | |
28 | |
29 | |
30 | |
31 | |
32 | |
33 | |
34 | |
35 | |
36 | |
37 | |
38 | |
90 Byte Code aufm ATtiny24. Peter
Gast
#2776220
Ich weiß ja nicht, aber diese in sich verschachtelte Schleifen mit break usw., da erschließt sich die Logik beim Lesen doch nicht sofort. Ok, in der SPS-Welt hat man ein konsistentes Eingans- und Ausgangs-Abbild, aber für diese kleine Aufgabe kann man das doch auch in C recht schön formulieren:
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
13 | |
14 | |
15 | |
16 | |
17 | |
18 | |
Wer will, kann auch in C++ formulieren, und so die Schlüsselwörter "and", "or" und "not" verwenden, dann wird es noch leserlicher und einsichtiger. So ein "deklaratives" Programm kann man selbst auch nach 5 Jahren nochmals problemlos anpassen oder eine Fremder schon morgen.
Ja, das sieht auch nicht schlecht aus. Statt Abfragen logischen Gleichungen zu benutzen. Leider kann das der AVR-GCC nicht optmieren, der Assemblercode ist ein vielfaches größer. Es gibt bestimmt auch noch andere Ansätze. Wenn man die beiden Stop-Tasten parallel schaltet, reicht sogar ein ATtiny13 aus. Ein Xmega ist daher völlig oversized. Bei Dir ist ein kleiner Fehler drin, bei offenen Endschaltern soll das Tor aufgehen. Peter
Gast
#2777098
> Statt Abfragen logischen Gleichungen zu benutzen. Mache ich in letzter Zeit vermehrt. Am Anfang ist es recht schwierig, so zu denken, mit der Zeit wird es besser. Wie immer, alles eine Frage der Übung. Ein Vorteil den ich sehe, ist, dass logische Gleichung in Verbindung mit treffenden Namen für Teilgleichungen sich sehr schnell in das Programm wieder einarbeiten lässt, nach einiger Zeit. Allerdings ist gute Namen finden nicht so einfach. > Leider kann das der AVR-GCC nicht optmieren, der Assemblercode ist > ein vielfaches größer. Ja, das ist sehr schade. Wird vermutlich einfach viel zu selten gemacht, und darum gibt es keine Optimier-Läufe dafür (zumindest in AVR-GCC). Prinzipiell sag ich mir, das ist das Problem vom Compiler. Kommt eben der nächst-größere Controller rein. Bei Einzelstücken ist das kein Kostenfaktor. Ok, bei Serienprodukten sieht es anders aus. Aber auch da nicht immer. > Es gibt bestimmt auch noch andere Ansätze. Ja. Daran bin ich immer interessiert. Wie kann man eine Lösung für so eine einfache Aufgabe noch anders formulieren? > Bei Dir ist ein kleiner Fehler drin, bei offenen Endschaltern soll > das Tor aufgehen. Ja, das stimmt. Man könnte auch noch mehr Verriegelungen einbauen. Z.B. MOT_OPEN gegen MOT_CLOSE etc. Start nicht bei Stop usw. Immer wieder erstaunlich wie man selbst bei offensichtlichen und trivialen Programmen Fehler einbauen kann.
Gast
#2777109
Ist das wieder mal ein Beispiel für die Zensurwut der Mods? Fragen löschen aber Antworten stehen lassen? Es gibt so viele Threads in diesem Forum, in denen Lösungen für Probleme gepostet werden, ohne das man die Fragestellung nachvollziehen kann. Was soll der Blödsinn?
Hinze schrieb: > Ist das wieder mal ein Beispiel für die Zensurwut der Mods? Fragen > löschen aber Antworten stehen lassen? Es gibt so viele Threads in diesem > Forum, in denen Lösungen für Probleme gepostet werden, ohne das man die > Fragestellung nachvollziehen kann. Was soll der Blödsinn? Der Originalthread war nach einhelliger Meinung keiner mit einer technischen Frage. Das war ein "wer kann mir meine Studium-Seminararbeit machen, weil ich selber das ganze Semester lang keine Übungen gemacht habe und daher die einfachsten Dinge nicht hinkriege"-Thread. Und die wollen wir hier nicht haben. Hilfe - ja Aber Faulheit unterstützen - nein. Beitrag "Suche dringend microcontroller Programmierer mit C in Deutschland"
Gast
#2777170
Hi >Der Originalthread war nach einhelliger Meinung keiner mit einer >technischen Frage. >Das war ein "wer kann mir meine Studium-Seminararbeit machen, weil ich >selber das ganze Semester lang keine Übungen gemacht habe und daher die >einfachsten Dinge nicht hinkriege"-Thread. Also, das kann ich so nicht richtig nachvollziehen. Wenn jemand Dumme sucht, dann laßt doch bitte die Suchanzeige stehen. Ich geb euch völlig recht, das Faulheit nicht unterstützt werden darf, weil morgen vielleicht schon der Faule der Chef ist... aber wenn die Frage gelöscht ist, hier aber noch munter irgendwelche Lösungswege diskutiert werden, dann ist das nicht wirklich sinnvoll. Abgesehen davon, das die Lösungen keinen Sinn machen, aber da muss man auch erst einmal drüber schauen, denn vielleicht ist es schon etwas aus der Trickkiste, und das will wohl keiner verpassen. Mein Vorschlag, und dann ist auch das "Warum" klarer, laßt unverschämte Schmarotzerbeiträge ruhig stehen, aber sperrt diese für Antworten. Obwohl ich zugeben muss, ab und zu brauch ich mal wen, den ich so richtig fertigmachen kann........ da ist doch so ein begnadeter Nichtsversteher ein willkommenes Opfer. Gruß oldmax
oldmax schrieb: > Hi >>Der Originalthread war nach einhelliger Meinung keiner mit einer >>technischen Frage. >>Das war ein "wer kann mir meine Studium-Seminararbeit machen, weil ich >>selber das ganze Semester lang keine Übungen gemacht habe und daher die >>einfachsten Dinge nicht hinkriege"-Thread. > > Also, das kann ich so nicht richtig nachvollziehen. Wenn jemand Dumme > sucht, dann laßt doch bitte die Suchanzeige stehen. Ich hab ihn nicht gelöscht. Keine Ahnung wers war. Das ganze war halt auch ein blöder Zufall, weil PeDa aus Lust an der Freude eine Lösung gebaut hat, mit der der TO nichts anfangen kann. Wärs anders gelaufen, würde heute kein Hahn mehr nach dem Thread krähen.
Zumindest muß man dem Fragesteller zugutehalten, daß er die Funktion verständlich und umfassend beschrieben hat. Wäre nur ein Punkt unklar gewesen, hätte ich es nicht versucht. Daran mangelt es leider oft in vielen anderen Threads und man muß den Leuten alles erst umständlich aus der Nase ziehen. Oder nach 20 Lösungsideen kommt die Antwort, daß alles doch ganz anders ist. Es ist doch erstaunlich, wie schwer es manchen fällt, ihr Problem zu beschreiben und daraus eine Aufgabenstellung zu formulieren. Solange das nicht erfolgt ist, kann man natürlich auch keine Lösung finden. Programmieren fängt man nicht an Tastatur und Bildschirm an, sondern im Kopf. Peter P.S.: Die 2 Verweise auf den original Thread sollten nun reichen.
>>Es ist doch erstaunlich, wie schwer es manchen fällt, ihr Problem zu >>beschreiben und daraus eine Aufgabenstellung zu formulieren. Das hängt unmittelbar mit der Erfahrung und dem Grundwissen zusammen. Wenn jemand keinen Wechselstrom kennt, schreibt er 12V und nicht 12V DC...etc
Gast
#2777508
Karl Heinz Buchegger schrieb: > Wärs anders gelaufen, würde heute kein Hahn mehr nach dem Thread krähen. ack. vergessen und gut, kein Grund für (mal wieder) 10 Seiten Grundsatzdiskussion.
Hallo! Ich bin zwar noch ein klein wenig Anfänger, was C betrifft, aber ich denke, ich habe die grobe Funktion des Codes von PeDa verstanden. Nur eine Stelle verstehe ich nicht: Peter Dannegger schrieb: > #include "sbit.h" > > #define MOT_OPEN PORT_B0 > #define MOT_OPEN_oe DDR_B0 > #define MOT_CLOSE PORT_B1 > #define MOT_CLOSE_oe DDR_B1 > #define END_OPEN PIN_B2 > #define END_CLOSE PIN_B3 > #define KEY_START PIN_B4 > #define KEY_STOP0 PIN_B5 > #define KEY_STOP1 PIN_B6 > > > int main() > { > MOT_OPEN_oe = 1; > MOT_CLOSE_oe = 1; > for(;;){ > MOT_OPEN = 0; > MOT_CLOSE = 0; > for(;;){ > if( KEY_STOP0 ) > break; > if( KEY_STOP1 ) > break; > if( KEY_START ){ > if( END_OPEN ) > MOT_CLOSE = 1; > if( MOT_CLOSE == 0 ) <----?? > MOT_OPEN = 1; > } > if( END_OPEN ) > MOT_OPEN = 0; > if( END_CLOSE ) > MOT_CLOSE = 0; > } > } > } müsste dort nicht stehen, if( END_CLOSE )? Den Rest verstehe ich ganz gut, nur an der Stelle kapier ichs irgendwie nicht. MfG Dennis
Mh, ich glaube, ich habs gerade doch kapiert, in die Schleife geht er ja nur, wenn die Start-Taste gedrückt wurde, und da soll er runter fahren, wenn das Tor oben ist und ansonsten immer hochfahren, also auch aus der Mitte. Aus der Mitte würde er mit meiner Idee nicht wieder starten. :-) hab eben bissel länger gebraucht, sry :) MfG Dennis
Dennis H. schrieb: > müsste dort nicht stehen, if( END_CLOSE )? > > Den Rest verstehe ich ganz gut, nur an der Stelle kapier ichs irgendwie > nicht. Etwas umgangssprachlicher ausgedrückt: Du drückst Start. Was soll passieren? Laut Code: wenn der Motor nicht schon nach unten fährt, dann soll er nach oben fahren. Damit sind 2 Fälle abgedeckt: Das Tor steht in der unteren Endposition Das Tor steht irgendwo in der Mitte -> Der Motor fährt also bei Start mehr oder weniger immer nach oben, es sei denn durch den oberen Endschalter ist ihm eine Fahrt nach unten vorgeschrieben worden. Und genau darauf prüft er: Wenn der Motor nicht schon auf dem Weg nach unten ist, .... Edit: zu spät. Du hast es selbst rausgefunden. Ja, aus PeDas Code kann man eine Menge lernen. Und er macht ganz wenige Fehler und sein Code ist oft voll von ineteressanten Wendungen, deren Sinn man nicht gleich sieht.
Man hätte es auch so schreiben können
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
allerdings ist das auch nicht ganz dasselbe. Stell dir einfach mal vor, was passiert, wenn der Benutzer die Start Taste einfach nicht loslässt. (Das sind nämlich die gemeinen Nebenbedingungen - Fehlerbehandlung). Was nie passieren darf: Das MOT_OPEN und MOT_CLOSE gleichzeitig 1 werden. Mit dem Code hier ist das möglich. Mit PeDa-s Code nicht. In seinem Code steckt noch mehr drinnen, als man auf den ersten Blick sieht. In seinem Code steckt nämlich an dieser Stelle noch die Nebenbedingung drinnen: Damit der Motor nach oben fahren kann, muss er erst zum Stillstand gekommen sein. Eine klitzekleine Möglichkeit für Fehler gibt es in seinem Code. Wenn der Motor nach oben fährt, der Startknopf gedrückt ist/bleibt und der obere Endschalter auslöst. Dann kann er den Motor für sehr kurze Zeit in eine Situation maövrieren, in der MOT_OPEN und MOT_CLOSE gleichzeitig auf 1 sind. Das in der Schleife abschliessende if bereinigt dann zwar den Zustand, aber für ein paar µC existiert dieser Fehlerzustand.
@ Karl Heinz Buchegger (kbuchegg) (Moderator) >Ja, aus PeDas Code kann man eine Menge lernen. Jain. Er macht bisweilen auch unnötige Mikrooptimierungen, die wenig Vorteil bringen aber viel Lesbarkeit zerstören. >Und er macht ganz wenige >Fehler und sein Code ist oft voll von ineteressanten Wendungen, deren >Sinn man nicht gleich sieht. Eben das macht ihn oft schwer leserlich. Ich bin ja auch ein Freund von smartem Code, aber er sollte dennoch gut lesbar sein. Sein Code ist eine lose, mehr oder weniger parallele Auswertung von ein paar IOs. Klar, die Aufgabe braucht nicht mehr. Aber es ist KEIN Beispiel für ein solides, übersichtliches, ausbaufähiges Konzept. Senn sobald die Aufgabe etwas größer und komplexer wird, kann man das hier vergessen. Stichwort statemachine.
Karl Heinz Buchegger schrieb: > Stell dir einfach mal vor, > was passiert, wenn der Benutzer die Start Taste einfach nicht loslässt. > (Das sind nämlich die gemeinen Nebenbedingungen - Fehlerbehandlung). Ja, diese Denkweise kenne ich gut, ich durfte in meiner Meisterprüfung auch so eine Torsteuerung programmieren, allerdings mit einer Art Mini-SPS, einer Easy von Glöckner-Möller. Auf dieser hat man nur Logikelemente wie und, oder,... und auch Zeitglieder. Bei dem Code oben kann selbst ein Trottel beide Tasten gleichzeitig drücken, da passiert nix, außer das der Motor vielleicht ein Müh ruckt, aber ich denke nicht, das man das sehen könnte, schließlich müssten am Controller ja noch größere Schaltelemente, am besten Schütze sein, die nie so schnell anziehen können, wie der Code abgearbeitet ist. Deswegen sollte auch dein angesprochener Mini-Fehler nicht wirklich auffallen. MfG Dennis
Für eine professionelle Lösung sind natürlich noch weitere Funktionen nötig. Oftmals mögen Motoren es nicht, wenn die Richtung ohne Stillstand geändert wird. Auch haben Schütze keine definierte An- und Abfallzeit. Es ist also nach jeder Fahrt eine Totzeit einzubauen. Sinnvoll ist es auch, nach der Fahrt erstmal auf Start losgelassen zu warten. Sonst fährt das Tor ständig hin und her, falls die Taste klemmt. Auch würde ich die Tasten entprellen, damit kurze Störimpulse nicht plötzlich eine Fahrt auslösen oder vorzeitig anhalten. Peter
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.