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
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 nichthttp://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:
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:
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
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
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.
@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
