Archiv verlassen und diese Seite im Standarddesign anzeigen : ansteuerung mit einem string, der auch gleich daten enthält
pebisoft
15.08.2005, 13:38
"vor120", wie kann ich diesen string trennen in 2 gruppen, einmal einen string "vor" zum aufruf der unterroutine und einmal eine integerzahl 120 , die in der unterroutine verarbeitet wird mit winavr-c
mfg pebisoft
Das gleiche Prob hatte ich vor kurzem in Bascom.
Da gings mit "Left","Mid" unf "Right"
Gibts da evtl in C auch??
MfG Xtreme
Hi,
ist das immer in der Reihenfolge ??
Das einzige was mir spontan dazu einfaellt ist "isalpha()"(http://www.cppreference.com/stdstring/isalpha.html).
for(i=0; isalpha(str[i]); i++); //durchlaufen bis zur Zahl
i=atoi(str+i); //Zahlenstring in int convertieren
str[i]=0x00; //Nullerminierung
Dann wuerde in i deine 120 als int stehen und im String str steht nur noch Dein "vor".
hi
ich nehme an, es geht nicht nur um dieses beispiel, sondern generell um die auftrennung eines strings in befehl und daten?
am besten definierst du dir irgend ein 'protokoll' im sinne von die ersten x bytes sind immer befehl, anschliessend kommen y bytes daten, etc
damit kannst du recht effizient arbeiten ...
wieviele verschiedene kommandos müssen denn übermittelt werden können? wenn es weniger als 256 sind, würde es eigentlich reichen, nur ein byte dafür zu verwenden (ok, der wert 37 ist weniger schön als 'vor', aber du musst dafür 2 bytes weniger übertragen)
dasselbe gilt für den integer - muss der wirklich zuerst in einen string verpackt und dann wieder umgerechnet werden?
cu
chris
pebisoft
15.08.2005, 14:39
hallo, klappt wunderbar (isalpha). vielen dank.
ich will damit den encoder am robby sagen z.b. das er "vor"wärts 100 encoder-werte fahren soll. komando bekommt er über funk.
mfg pebisoft
Wenn ich annehme, der String kommt vom Terminal, dann kriegst du den String ja Zeichenweise
Als erstes liest du also den string einfach ein bis <CR> ( ein "\0" hängst du am besten gleich an. )
In deinem Fall kannst du brutal die ersten 3 Byte mit "vor" vergleichen,
if (memcmp (string, "vor", 3 ) == 0)
und dann die Zahl
nn = atoi((char*)&string[3]) ( die ersten 3 bytes sin ja jetzt schon weg)
Es gibt mindestens 357 Lösungsvarianten, das ist ca Nr 37
pebisoft
15.08.2005, 16:20
die letzte lösung geht auch wunderbar.
welche nimmt mehr speicher weg.
ich mache 8 abfragen.
was heissen diese warnmeldungen:
uart.c: In function `main':
uart.c:29: warning: passing arg 1 of `memcmp' discards qualifiers from pointer target type
uart.c:31: warning: passing arg 1 of `usart_writeString' discards qualifiers from pointer target type
mfg pebisoft
Wenn du sagst
if ( (string[0] == 'v')
&& (string[1] == 'o')
&& (string[2] == 'r')
{
nn = atoi(string[3])
}
ist das sicher eine der billigsten Varianten, nur halt nicht gut zu lesen.
Ja, aber auch recht speicherfressend und nicht sonderlich flexibel...
Wenn da noch andere Befehle (auch spaeter mal zukommen sollen) wuerd ich das so nicht machen.
Wuerde da ein schoenes Struckt empfehlen in dem der Name als String gespeicher ist und ein Pointer auf die Funktion (setzt allerdings vorraus das die alle den gleichen Uebergabeparameter haben...). Dann machst Du ein Array aus diesen Struckt (halt fuer jede Funktion eins..) und Gehts dann in der for Schleife solange durch alle durch bis Du das richtig gefunden hast. Klingt jetzt evt etwas aufwendig, aber ich wage zu behaupten das Du da deutlich weniger Speicher benoetigst als mit der Variante von PicNick.
(Vor allem brauchst nicht so viel Tippen... ;) Und das aendern/hinzufuegen geht auch schnell weil Du nur das Array erweitern musst).
Ich geb dir teilweise recht und teilweise nicht:
Ich selbst würde das in meinem Leben nicht so machen wie ich das da hingeschrieben habe. Wie du es sagst, von wegen flexibel, modularisierung und überhaupt.
ABER SPEICHERFRESSEND ist das nicht
Den 3 von mir genannten Vergleichen steht beim "memcmp" und jeder allgemeinen Function eine Call-prozedur plus einer Schleifenkonstruktion für die Länge gegenüber, damit letztlich im Kern genau wieder diese 3 Byte verglichen werden.
Außerdem muß er sich ggf. deine Vergleichstrings erstmal aus dem Flash holen, damit die function sie überhaupt lesen kann
Also recht teuer gegen drei "if's"
NumberFive
15.08.2005, 18:52
mal ne frage warum den die daten so und im klar text übertragen. ich mache es so bei mir ich schicke immer 4 byte A<byte><byte>E.
so mit habe ich ein feste länge. das erste byte nach dem a ist das was und das zweite ist der wert. ist das nicht einfacher so ? und ich habe auch gleich einbisschen das telegram geprüft.
@Nr-5: Kommt eben drauf an.
Wenn du mit einem Programm auf der anderen Seite quasselst, ist das anders, als wenn du irgendeinen Dummy auf einer Tastatur hast.
Ich wett schon, daß der Pebisoft eh nur ein einziges Kommando hat, das mit "V" anfängt, also würde das sicher auch reichen.
Andererseits ich mag die UnIX Line-Commands auch nicht besonders
(XYZ -f -? -X12 -C34 - Mwtlbrnft<ENTER>)
Aber über Geschmack läßt sich nicht streiten, also nicht gleich schlagen)
NumberFive
15.08.2005, 19:41
es ist in meinen Augen nicht gesagt von wo der Befhelt kommt ob es um ein User interface geht oder um daten austausch zweier Programme.
Bei dem User Interface währe mein Übertragung sicher sehr krüptisch das stimmt.
Aber mal ehrlich würde man als Front end nicht besser ein Programm machen ? ich glaube das pebisoft eh ein Programm Frontend hat.
zu PicNick:
Hmm, hab das eben mal probiert... Hast recht, ist mehr...
Wie würdest Du das den am idealsten lösen ?? Hab auch gerade eine ähnliche Problematik und hab das wie oben beschreiben gemacht. Bin eigentlich auch sehr zufrienden damit, aber Optimieren/dazulenen kann nie schaden :)
Zum Thema Klartext/Kryptisch:
Das ist wirklich geschmackssache und hängt von der Anwendung ab. Ich persönlich würde mir in solch einem Fall immer die Option offen halten das auch mal ohne frontend zu machen, besonders in der Entwicklungsphase...
Wenn dann ales fertig ist und funz kann man das ja noch mal optimieren(wozu man dann aber meist keine Lust hat, weils ja auch so läuft und nicht in Serienfertigung geht ;))
Morgen, Männer ! (oder sin' auch Mädels da ?)
PSIYOU: Mich hat auch der Schlag getroffen, als ich mir klargeworden ist, daß bei RISC in vielen Fällen ein Spaghetticode effizienter ist als Modulare, flexible, eierlegende und Wolle gebende Schleifen. Besonders dann, wenn die Schleifenlänge beim kompilieren schon feststeht.
Trotzdem kann ich auch nicht aus der Haut.
Ich selbst mache (für sophisticated programs) Input routinen immer zentral mit State, Focus pointer und Parametern. Denn wenn man (minimalen) Eingabe-Komfort mit Korrektureingaben und Pi-pa-po machen will, kommt da schon was zusammen.
Für wirklich komplexen Input bau ich mir ein PC-Programm zum Vorkosten, da kann ich dann mit Slidern und Radio buttons und Tralala arbeiten und spare dafür beim Controller.
Für interne Schnellschussprogramme is mir natürlich alles wurst, da gibt's keine Regeln, da soll er sich an der Tastatur die Finger brechen.
"IDEAL": Gibt's das ? Wenn du es findest, sag's mir bitte
pebisoft
16.08.2005, 08:31
" ich glaube das pebisoft eh ein Programm Frontend hat."
das programm was ich habe für den robby fordert daten an vom pc und gib ausgewertete an den pc zurück und der avr steuert mit den ausgewerteten daten auch den robby.
mein robby ist wie ein marsmobil im unbekannten raum. er fährt zu einem vorgegeben ziel was im i2c-eeprom als daten steht. am ziel übernehme ich sozusagen die steuerung (als wenn von der erde auf dem mars das mobil gesteuert wird), danach muss er mit den daten die er eingesammlet hat wieder selbstständig zu mir zurückkommen (klappt meistens noch nicht).
das ist ist mein hobby am robby.
mfg pebisoft
@ PicNick
Ja, werd ich dann mal machen ;)
Aber vorher musst Du mir noch mal auf die Spruenge helfen... Bin in dem Programierer Jargon nicht so zu hause...
Was meinst Du mit State, Focus pointer ???
Kann mir das gerade nicht so vorstellen, ein kleiner Beispielcode der bei Dir noch rumliegt waehre nett ;)
Philipp
Powered by vBulletin® Version 4.2.5 Copyright ©2024 Adduco Digital e.K. und vBulletin Solutions, Inc. Alle Rechte vorbehalten.