Hallo! Ich habe meinen ersten etwas komplexeren Code geschrieben und würde mich freuen wenn ein paar Profis drüberschauen und kommentieren. Damit sich keine Fehler für meine "Programierzukunft" einschleichen. Das Programm läuft auf einem ATmega 8 und liest über RS 232 ein Navilock NL550ERS GPS Modul aus. Auf einem 2*16 LCDisplay werden geographische Breite und Länge, Zeit in UTC und GPS Höhe angezeigt. Eine Frage jetzt schon: Das Display flackert fast unmerklich und sehr schnell. Man kann gradezu sehen wie der ATmega arbeitet. Kann man das durch geschickte Programierung ändern? Vielen Dank schonmal!
@ Attila (Gast) >Eine Frage jetzt schon: Das Display flackert fast unmerklich und sehr >schnell. Man kann gradezu sehen wie der ATmega arbeitet. Kann man das >durch geschickte Programierung ändern? Sicher, das Diplay NICHT löschen sondern überschreiben. Und das auch nur mit 1-5 Hz, schneller braucht das eh keiner. MFG Falk
Nabend, Attila schrieb: > Eine Frage jetzt schon: Das Display flackert fast unmerklich und sehr > schnell. Man kann gradezu sehen wie der ATmega arbeitet. Kann man das > durch geschickte Programierung ändern? Mal dir ein Flussdiagramm, dieses wird einige Klarheiten beseitigen :-) MfG
1 HZ wär schon ganz nett da meine UTC Zeit mit Sekunden angezeigt wird ;-) Ansonsten Danke schon mal!
Fang damit an, offensichtliche Teilfunktionalitäten in Unterprogramme auszulagern. Dazu gehört zb: LCD initialisieren einen String auf dem LCD auszugeben Dazu solltest du dir ein Konzept überlegen, wie du Strings speichern willst. Dein ganzes Programm ist mit Annahmen gespickt, was die Anzahl empfangener Zeichen betrifft. zb
1 | ldi ZL,LOW(BREITE) ;Z-pointer für SRAM Segment "Breite" |
2 | ldi ZH,HIGH(BREITE) |
3 | |
4 | rcall receive ;Geographische Breite abspiecher |
5 | st z+,temp |
6 | rcall receive |
7 | st z+,temp |
8 | rcall receive |
9 | st z+,temp |
10 | rcall receive |
11 | st z+,temp |
12 | rcall receive |
13 | st z+,temp |
14 | rcall receive |
15 | st z+,temp |
16 | rcall receive |
17 | st z+,temp |
18 | rcall receive |
19 | rcall receive |
20 | rcall receive |
21 | rcall receive |
22 | st z+,temp |
die geographische Breite von deinem NMEA Gerät kennzeichnet sich NICHT dadurch aus, dass da genau 11 Zeichen daher kommen. Die geographische Breite sind die Zeichen, die daherkommen, bis zum nächsten ',' Zeichen! Dein Code funktioniert jetzt vielleicht bei dir zu Hause, aber am anderen Ende der Welt, mit einer anderen Zeichenzahl für die Breite, funktioniert er nicht mehr.
Attila schrieb: > 1 HZ wär schon ganz nett da meine UTC Zeit mit Sekunden angezeigt wird > ;-) Ähm. 5Hz ist schneller als 1Hz 1 Hz ... 1 mal pro Sekunde 5 Hz ... 5 mal pro Sekunde
Aua! Ja das mit den 5HZ stimmt natürlich! Was ein "string" ist weiss ich nicht aber das werde ich hier nachlesen und umsetzen. Das mit dem ',' habe ich nun garnicht vertstanden. Das GGA Protokoll spuckt eine Unmenge von Kommata aus. Und was ich auch nicht verstehe: Wieso soll denn eine geograghische Breite nicht immer die gleiche Anzahl Zeichen haben? Bevor jetzt jemand schimpft: Ja! Ich lese ein Zeichen zuwenig für die Länge aus! Das sieht schöner auf dem Display aus und es ist nicht anzunehmen dass ich mich in absehbarer Zukunft nach 100 plus Grad Ost oder West bewege.
>Was ein "string" ist weiss ich nicht http://forum.finanzen.net/board/anonymize/attachment.m?aid=254343 SCNR "String" ist die englische Bezeichnung für "Zeichenkette". >Wieso soll denn eine geograghische >Breite nicht immer die gleiche Anzahl Zeichen haben? Hm... 5° = 1 Zeichen 25° = 2 Zeichen ?
Attila schrieb: > Aua! Ja das mit den 5HZ stimmt natürlich! > > Was ein "string" ist weiss ich nicht aber das werde ich hier nachlesen > und umsetzen. Ein string ist eine Ansammlung von Textzeichen. "Attila" ist ein String. Er besteht aus den Buchstaben 'A' 't' 't' 'i' 'l' und 'a'. Und irgendeinem Verfahren, das dir erlaubt das Ende eines Strings zu erkennen. > Das mit dem ',' habe ich nun garnicht vertstanden. Das GGA Protokoll > spuckt eine Unmenge von Kommata aus. Aus guten Grund. Damit man per Programm feststellen kann, wo eine Information zu Ende ist und eine ander anfängt > Und was ich auch nicht verstehe: Wieso soll denn eine geograghische > Breite nicht immer die gleiche Anzahl Zeichen haben? Weil 0.123 nun mal über weniger 'Buchstaben' verfügt als 42.786 Aber es ist ja nicht nur die Breite. Du hast ja in der Länge dieselbe Annahme gemacht. Einmal kurz nach England fliegen, und schon ändern sich die 15.876 Grad östlicher Länge zu 1.265 Grad westlicher Länge. Oder nach Australien. Da sind es dann irgendwas bei 180.234 Grad > > Bevor jetzt jemand schimpft: Ja! Ich lese ein Zeichen zuwenig für die > Länge aus! Das sieht schöner auf dem Display aus und es ist nicht > anzunehmen dass ich mich in absehbarer Zukunft nach 100 plus Grad Ost > oder West bewege. Darum gehts nicht. Wenn du es richtig machst, spielt es keine Rolle wo du bist. Und kürzer wird dein Programm ausserdem.
Also: Ich sehe ein das man es wohl anders machen muss als einfach nur eine betimmte Anzahl Zeichen anzunehmen. Allein schon für irgendwas was in der Zukunft auf mich zukommt und ausgelesen werden muss aber: Zumindest bei dem Protokoll was mein GPS auspuckt ist es immer die gleiche Anzahl Zeichen. Es kommen dann Nullen an die Stelle die nicht gebraucht wird. Im Datasheet so beschrieben: Message Structure: $GPGGA,hhmmss.ss,Latitude,N,Longitude,E,FS,NoSV,HDOP,msl,m,Altref,m,Diff Age,DiffStation*cs<CR><LF> Example: $GPGGA,092725.00,4717.11399,N,00833.91590,E,1,8,1.01,499.6,M,48.0,M,,0*5 B
Attila schrieb: > Zumindest bei dem Protokoll was mein GPS auspuckt ist es immer die > gleiche Anzahl Zeichen. Es kommen dann Nullen an die Stelle die nicht > gebraucht wird. Da hast du wohl recht. Das war mir noch gar nie bewusst. Liegt wohl daran, dass ich mich lieber am ',' orientiere, als bestimmte Stellenanzahlen zu verlangen. Ist auch Codetechnisch simpler, wenn man ein Abschlusszeichen hat rec_info: Empfange Zeichen ist es ',' Ja -> Sprung nach rec_Ende Speichere das Zeichen über das Z register springe nach rec_info rec_ende: noch ein 0-Byte an den Text anhängen um den String abzuschliessen return und schon hab ich eine Routine, die sowohl Breite als auch Länge empfangen kann. Ich muss nur das Z Register vorher mit der Adresse füllen, wo die Information im SRAM abgelegt werden soll. Selbiges für die Ausagberoutine lcd_string hole Zeichen über Z ist es 0? ja -> lcd_string_ende Zeichen ausgeben spring nach lcd_string lcd_string_ende: return Z Register auf den Anfang des Strings setzen und schon gibt er aus, was er dort vorfindet. Und da die empfangsfunktion am Ende des Textes eine 0 abgelegt hat, kann die Ausgabefunktion diese 0 benutzen um das Ende des Textes festzustellen Ich hab nur 2 Funktionen, die mit beliebig langen Texten umgehen können, solange ich nur im SRAM genügend Speicher dafür vorgesehen habe.
Karl! Da ich noch Anfänger bin ist mir nicht ganz klar wie Du das machst aber mir ist klar (glaube ich) was Du da machst. Jetzt Frage ich mich aber: Wie sortierst Du das richtige Komma aus den unzähligen Kommata aus? Aber ist schon mal ein sehr lehrreicher Diskurs hier!
Hi >Ich sehe ein das man es wohl anders machen muss als einfach nur eine >betimmte Anzahl Zeichen anzunehmen. Als erstes solltest du das Einlesen des NMEA-Strings im Hintergrund laufen lassen. Erst wenn der vollständig vorliegt werden die Werte extrahiert und angezeigt. Im Anhang mal ein Stück Code aus dem Programm zu dem hier: Beitrag "Re: Zeigt her Eure Kunstwerke !" Wie du siehst ist die 'mainloop' kurz und übersichtlich. Der NMEA-String wird im RX-Interrupt eingelesen und bei Vollständigkeit ein Flag gesetzt. Wenn das gesetzt ist verzweigt die 'mainloop' zu Verarbeitung. MfG Spess
Ok dann möchte ich mal kurz etwas zu deinem Code sagen vom Stil her. Ich kann mich ansonsten nur den Vorrednern anschließen. Also kommen wir zu nächst zu den ausgerollten Schleifen.
1 | st z+,temp |
2 | rcall receive |
3 | ... |
4 | rcall receive |
5 | st z+,temp |
6 | rcall receive |
7 | ... |
8 | rcall receive |
Dieser Stil ist in diesem Programm meines erachtens nach nicht angebracht. Das Problem ist folgendes. Dieses kleine Programm ist später teil eines größeren Projektes und du musst den Namen recieve ändern - spätestens dann hast du ein Problem. Daher solltest du das ein einer schleife verpacken. Dadurch wird dein Programm wartbarer. Das hat zweierlei Vorteile, zum einem ist es wartbar und zum zweiten schont es dein Programmspeicher. Für ein kleines Programm ist es natürlich nicht immer relevant den Programmspeicher zu schonen, nur bei ein wenig größeren Projekten kann dir das ausrollen dein Genick brechen ;). Das ausrollen von Schleifen kann Sinn machen aber nur dann, wenn du wirklich Zeitkritische Dinge hast die du auf 1-2 Takte genau benötigst. Dann gehe ich mal weiter, kommen wir mal zum Naming:
1 | test: |
2 | |
3 | D: rcall receive ; NMEA Protokol "GGA" identifizieren |
4 | cpi temp,'$' |
Das "D" stört mich zunächst erstmal gewalltig, es sagt nichts aber überhaupt nichts aus. Ich kann weder beurteilen was es macht und einen einzelnen Buchstaben übersieht man leicht. Desweiteren "recieve" finde ich auch unglücklich und zwar sehe ich das ich etwas empfange aber nicht was. Das kann aber zT. sehr wichtig sein. Daher würde ich eher sowas hinschreiben: "rec_GPS_char" oder sowas in der Art (nur die erste Idee von mir). Zu der Formatierung:
1 | .include "m8def.inc" |
2 | |
3 | .def temp = r16 |
4 | .def temp1 = r17 |
5 | .def temp2 = r18 |
6 | |
7 | .equ F_CPU = 8000000 ; Systemtakt in Hz |
8 | .equ BAUD = 38400 ; Baudrate |
9 | ... |
10 | main: |
11 | ldi temp, HIGH(RAMEND) ;Stackpointer initialisieren |
12 | out SPH, temp |
13 | ldi temp, LOW(RAMEND) |
14 | out SPL, temp |
15 | |
16 | ldi temp, 0b11111110 ;Port D auf Ausgang |
17 | out DDRD,temp |
18 | ... |
19 | init: rcall zeit |
20 | ... |
21 | HOHE: .byte 10 ;10 Byte unter dem Namen 'HOHE' reservieren |
Auch hier wäre es sehr angenehm wenn du das wirklich einheitlich gestaltest. und zwar EINE Spalte Label, Befehl, Operand "präprocessor direktiven" sollten sich ebenfalls in einer festen Spalte befinden. So das wars von meiner Seite...
Spitze! Als ich den Code hier eingestellt habe hatte ich genau solche Kommentare erhofft wie sie jetzt hier kommen! Einfach Klasse! Ich sehe schon das viel aber spannende "Arbeit" auf mich zukommt! Danke schonmal!
Attila schrieb: > Karl! > > Da ich noch Anfänger bin ist mir nicht ganz klar wie Du das machst aber > mir ist klar (glaube ich) was Du da machst. Jetzt Frage ich mich aber: > Wie sortierst Du das richtige Komma aus den unzähligen Kommata aus? genauso wie du das auch machst Du weisst ja, in welcher Reihenfolge die 'Felder' daherkommen und was nach dem jeweils nächsten Komma kommt
> Ich habe meinen ersten etwas komplexeren Code geschrieben und würde mich > freuen wenn ein paar Profis drüberschauen und kommentieren. Damit sich > keine Fehler für meine "Programierzukunft" einschleichen. Noch eine ganz prinzipelle Frage: Wieso in Assembler? ("Profis" nehmen kein Assembler, zuminderst nur in Ausnahmefällen)
Ich habe am Anfang irgendwo gelesen dass es ganz schlau ist erst einmal assembler zu lernen bevor man eine "höhere" Sprache lernt. Ausserdem glaube ich dass es in allem was man so machen kann auf dieser Welt Profis gibt.
Attila schrieb: > Ich habe am Anfang irgendwo gelesen dass es ganz schlau ist erst einmal > assembler zu lernen bevor man eine "höhere" Sprache lernt. Natürlich, stimmt schon. Aber die meisten schwenken dann ab einer gewissen Komplexität auf eine höhere Programmiersprache um. Irgendwann hat man in Assembler einfach zuviel unproduktiven Aufwand rundherum, so dass es sich nicht mehr lohnt. > Ausserdem glaube ich dass es in allem was man so machen kann auf dieser > Welt Profis gibt. Industriell sehen die Zahlen in etwa so aus: Man rechnet, dass ein Programmierer durchschnittlich am Tag in etwa 10 Zeilen fehlerfreien Code produziert (10 Anweisung, alles in eine Zeile quetschen gilt nicht). Das darfst du dir jetzt nicht so vorstellen, dass er nur 10 Zeilen schreibt, sondern da ist auch alle Zeit für Vorbereitung, Testen und Debugging, Fehlersuche und Fehlerbehebung mit eingerechnet und auf die komplette Projektlaufzeit umgelegt. Es gibt natürlich Tage, an denen man seitenweise Code schreibt und es gibt natürlich Tage an denen man überhaupt nichts schreibt sondern nur auf Fehlersuche ist. Auch die 10 sind nicht Gott gegeben, sondern hängen vom Schwierigkeitsgrad des Projekts ab. Ob das jetzt 10 oder 15 sind ... geschenkt. Aber irgendwo in diesem Bereich bewegt sich die Zahl in einem realen Projekt. Das Interessante daran ist, dass diese Anzahl ziemlich unabhängig von der Programmiersprache ist. Hat man eine höhere Programmiersprache, dann kann man in einer Anweisung sehr viel mehr ausdrücken als in Assembler. Daher ist man in einer höheren Sprache auch produktiver. Eben weil der Compiler den ganzen Routineteil zwischen den Anweisungen übernimmt. Je mächtiger die Sprache ist, desto mehr kann man in ca. 10 Zeilen ausdrücken.
@ Karl heinz Buchegger (kbuchegg) (Moderator) >Compiler den ganzen Routineteil zwischen den Anweisungen übernimmt. Je >mächtiger die Sprache ist, desto mehr kann man in ca. 10 Zeilen >ausdrücken. play(chess); ;-)
Ich würd gerne mal die Label-Namen kritisieren. Man kann auch in Assembler lange, sprechende Namen verwenden (macht die resultierende Binary nicht größer - scheint bei manchen die Sorge zu sein), dann kann auch jemand der den Code zum ersten Mal sieht (oder man selbst, nach längerer Zeit, beim Debuggen), direkt am Namen erkennen, was eine Fuktion machen soll. z.B. statt "receive" -> "receiveOneCharacterFromUART" statt "zeit" -> "wait80milliseconds" (wo man sich ja schon die Mühe macht einen Kommentar "eine 80ms Warteschleife" rein zu schreiben) Ich mach auch gerne "Trennstriche" zwischen Funktionen, macht es auch noch etwas übersichtlicher.
1 | ------------------------- |
2 | clearDisplay: |
3 | ldi temp, 0b00000001 ;Clear display, return cursor to home |
4 | rcall sendDataToDisplay |
5 | ret |
6 | |
7 | ------------------------- |
8 | jumpTo2ndLine: |
9 | ldi temp, 0b11000000 ;zur zweiten Zeile im Display springen |
10 | rcall sendDataToDisplay |
11 | ret |
12 | |
13 | ------------------------- |
14 | receiveOneCharacterFromUART: |
15 | sbis UCSRA, RXC |
16 | rjmp receiveOneCharacterFromUART |
17 | in temp, UDR |
18 | ret |
Also vielen Dank bisher für die konstruktive Kritik aber vielmehr dafür dass ich mich , aufgrund der Kommentare, entschlossen habe C zu lernen. Ich denke meine asm Kenntnisse sind ausreichend um jetzt darauf basierend auf C umzusteigen. Auch wäre ich ohne die Beiträge hier nicht auf die Idee gekommen "asm vs C" hier im Forum durchzulesen was wiederum zu der Erkenntnis führte das ich auf C umsteigen sollte. Vielen Dank dafür und bis bald mit Anfängerfragen in C hier im Forum :-) Ach so: play(chess); ist natürlich genial :-) :-) :-)
@Karl heinz Buchegger:
> ... Da sind es dann irgendwas bei 180.234 Grad ...
War nicht irgendwie bei +- 180 Grad schluß?
Oder meinst Du Gon (Neugrad), das ging glaub ich bis 400.
Grüße
Jay
Hi >Ich denke meine asm Kenntnisse sind ausreichend um jetzt darauf >basierend auf C umzusteigen. Nun, wenn ich mir dein ASM Programm so anschau... also, da ist noch viel besser zu machen. Nicht, das ich gegen C wäre, Aber Assembler zwingt geradezu kleine Programmblöcke zu schreiben, damit der Überblick nicht verloren geht. Bei höheren Sprachen ist's aber ähnlich. Auch hier sind kleine Codeabschnitte von Proceduren oder Functions hilfreich, aber man verliert leicht den Bezug zur Hardware. Schnell hat man in einen Atmega ein paar überflüssige Codes geschrieben, weil eben C mehr als nur eine Anweisung in eine Zeile bekommt, oder man wundert sich, das 70% vom Speicher schon belegt sind, obwohl noch so viel offen ist. Also, meine Empfehlung, bleib erst noch ein Weilchen im Bereich Assembler, bis du in deriner Programmierung etwas modularer wirst. Zumindest im Bereich der µC's. Dafür empfehle ich, weils vielleicht nicht so stressig ist, im PC Bereich mit C-Programmen zu arbeiten. Z.B. Software, um deinen Controllern Daten zu entlocken und diese zu bearbeiten oder Parameter in die Controler zu schieben, um andere Funktionalität ohne Programmänderung zu erreichen. Das Übt. Gruß oldmax
Hallo oldmax! Du hast sicher recht aber was ist denn mit den ganzen Leuten die in C programieren und haben sich noch nie mit assembler beschäftigt?
Attila schrieb: > Hallo oldmax! > > Du hast sicher recht aber was ist denn mit den ganzen Leuten die in C > programieren und haben sich noch nie mit assembler beschäftigt? Auch die müssen sich durch die Datenblätter/Handbücher quälen. Allerdings haben sie meistens etwas verschrobene Vorstellungen davon, was da auf der CPU wirklich passiert. Als Assembler Programmierer bist du direkt am Geschehen. Sozusagen: Autofahren ohne Servolenkung und ABS. Und gebremst wird, indem du mit den Händen die Bremsbacken zusammendrückst.
Naja durch Datenblätter usw habe ich mich ja bereits gequält und zwar nicht zu knapp. ich werde es ja sehen ob meine assemblerkenntnisse auf deisem Stand tatsächlich zu mangelhaft sind um in C weitermachen zu können. Ich kann es mir kaum vorstellen ehrlich gesagt.
Attila schrieb: > Naja durch Datenblätter usw habe ich mich ja bereits gequält und zwar > nicht zu knapp. ich werde es ja sehen ob meine assemblerkenntnisse auf > deisem Stand tatsächlich zu mangelhaft sind um in C weitermachen zu > können. Ich kann es mir kaum vorstellen ehrlich gesagt. Denk ich nicht. Nach dem Code oben zu urteilen, hast du noch Bedarf in den Themen "Codeorganisation" und "Allgemeine Programm-Strategien". Das ist in C auch nicht anders als in Assembler. Nur eben auf einem anderen Niveau. In C schiebst du Funktionalität in Funktionen und arbeitest mit Hilfsvariablen ohne mit der Wimper zu zucken. In Assembler musst du immer aufpassen "hab ich jetzt die richtigen Register", "zerstör ich mir da jetzt Register", "was ist mit den Flags", etc. Alles Dinge, um die sich der C-Compiler kümmert.
Attila, hier http://www.roboternetz.de/phpBB2/viewtopic.php?t=54671&sid=ccf684586a42004a666b0906cffdb25d hatte ich mit robo_wolf auch mal einen AVR-Assembler-Lernkurs angelegt. Ist vllt in Hinblick auf einen modularen Programmierstil interessant. mare_crisium
@Harald: Danke! @Karl: Aber genau das will ich eben nicht: Wissen wann wo welcher Flag und wie man dividiert wenn man nur + und - zur Auswahl hat. Ich hatte beim Studium das assembler Tutorials eben NICHT den Eindruck dass es um Programmstartegien geht sondern eher darum dass es eben tatsächlich nur + und - gibt. Und das es register gibt und Flags usw usw. Ich habe ein wenig den Eindruck das ich lernen soll ein Ventil auszutauschen und es nicht reicht zu wissen dass ein Motor Ventile hat und wofür die sind. Dabei will ich doch nur Auto fahren!
Hi
>Dabei will ich doch nur Auto fahren!
Ich glaub, hier verwechselst du etwas. Wer sich (privat) mit µC's
beschäftigt, der will eben nicht nur Autofahren, der will ein Formel 1
Fahrzeug um die Kurven jagen.
Wenn du nur Auto fahren willst, dann mach es wie die unzähligen PC User,
schreibe Briefe in Word und kalkuliere deine Kosten in ExCell oder
spiele stundenlang irgend ein Game.
Aber egal, welche Programmiersprache... du mußt lernen zu analysieren
und Aufgaben zu verteilen.
Hier ist nix mit "ich setz mich mal eben hin und dreh den Schlüssel um"
und Hui... auf geht's.
Auch auf Controllern ist die Sprache meiner Erachtens letztlich abhängig
von der Anwendung. Und ich denke, wer im professionellen Bereich
Programme schreibt, der hat auch gute Compiler. Was ich aber bei einem
Anflug von Wissensdrang mit BASCOM und e-Lab (Pascal) erlebt habe, war
jenseits von Speichersparend. Da sind ein paar Zeilen mit Aufrufen von
ein paar Funktionen und schon ist der halbe Flash voll....
Bitte nicht darüber diskutieren, ich weiß, das ich da überhaupt keine
Ahnung von hatte und vieles falsch angesetzt war. Aber trotzdem wollt
ich erwähnen, es ist schon ein Unterschied, ob die Software für lau oder
ein professionelles Entwicklungssystem dahintersteckt....
Ach ja, noch was. Glaub nicht, das eine Programmierung in C leichter
erlernbar wie Assembler ist. Ich möchte sogar fast behaupten, Assembler
ist einfacher.
Gruß oldmax
Ja! Ich habe auch den Eindruck dass assembler einfacher ist! Ich möchte aber jetzt den Kurs zwischen 2 Koordinaten berechnen. Und da komme ich nicht weiter. Ich will NICHT wissen wie man das in assembler macht. Ich kann es mir vorstellen wie man es macht. Aber mein Ziel ist es Anwendungen zu "basteln" Und mir nicht den Kopf darüber zu zerbrechen wie man assembler erklärt den arkustangens zu berechnen! Darum fragte ich hier im Forum schon mal nach einem "Taschenrechnermodul" Und gäbe es eine Bibliothek aus der man solche operationen kopieren könnte (habe ich nicht gefunden) dann wäre auch gut. Ein Modelboot soll ein viereck auf einem See abfahren. Da kann ich keinen PC draufschrauben und exel nützt mir da auch wenig. Aber: Ein qC Ein GPS Modul und ein Servo sind das Richtige Alles läuft....bis auf die Berechnung des Kurses! Vielleicht habe ich die Problematik so besser beschrieben?
Hi Ja, du hast die Problematik so besser beschrieben. >Ich habe meinen ersten etwas komplexeren Code geschrieben und würde mich >freuen wenn ein paar Profis drüberschauen und kommentieren. Damit sich >keine Fehler für meine "Programierzukunft" einschleichen. Und das war der Einstiegssatz aus deinem ersten Posting. Warum fragst du nicht gleich nach Winkelberechnungen ? Sorry, aber wenn du Antworten bekommst, die du NICHT willst, dann liegt es daran, das du eine Frage gestellt hast, auf die du scheinbar KEINE Antwort haben willst. Gruß oldmax
Sorry oldmax! Das hat sich während der Diskussion so entwickelt! Ursprünglich ging es tatsächlich nur um den Code aber im Rahmen der Diskussion (und es sind ja auch ein paar Tage vergangen) wurde die Problematik auch für mich wesentlich klarer. Soll ich jetzt ein neues Posting erstellen oder kann das auch in Diesem behandelt werden?
Hi Bei mir brauchst du dich nicht zu entschuldigen, aber wenn du anfängst, Betonung in deine Sätze zu bringen, solltest du zumindest wissen, wovon du ursprünglich mal geredet hast. Und dazu brauchst du eigentlich nur deine Überschrift lesen.... Sie steht übrigends zur Erinnerung über jedem Beitrag. Nie nicht vergessen, das du hier Hilfe suchst. Sonst sind die, die es könnten, schnell weg. Übrigends, ich kann dir auch nicht helfen, aber habe ich mal ein solches Problem nehme ich die üblichen Hilfsmittel. Ja, auch diese und andere Foren sind da durchaus geeignet, bei angemessenem Ton. Gruß oldmax
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.