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
intmain()
2
{
3
MOT_OPEN_oe=1;
4
MOT_CLOSE_oe=1;
5
6
for(;;){
7
charstop=KEY_STOP0||KEY_STOP1;
8
charstop_open=END_OPEN||stop;
9
charstop_close=END_CLOSE||stop;
10
charmot_stillstand=!MOT_OPEN&&!MOT_CLOSE;
11
charstart=KEY_START&&mot_stillstand;
12
charstart_open=END_CLOSE&&start;
13
charstart_close=!start_open&&start;
14
15
MOT_OPEN=(MOT_OPEN||start_open)&&!stop_open;
16
MOT_CLOSE=(MOT_CLOSE||start_close)&&!stop_close;
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
> 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.
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"
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
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.
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
Thread beobachten
Seitenaufteilung abschalten