Hallo Programmierer,
ich quäle mich hier schon seit Stunden mit diesem unsäglichen Arduino
ab. Kurz die Randbedingungen: Arduino Nano 3.0, Arduino IDE,
ENC28J60-Modul über SPI, UIPEthernet-Library. Lib schon erfolgreich
eingesetzt, also funktioniert!
Bei dieser Zeile:
1
Serial.write(client.read());
bei der die ankommenden Daten (byteweise?) direkt zur seriellen
Schnittstelle schickt, möchte ich einzelne Zeichen durch andere ersetzen
(konkret "$" durch ","). Dafür habe ich schon folgendes probiert:
1
client.read(string2send);
2
string2send.replace("$",",");
3
Serial.write(string2send);
sowie auch:
1
string2send=client.read();
2
string2send.replace("$",",");
3
Serial.write(string2send);
bekomme aber nur Fehlermeldungen in der ersten Zeile. Ich weiss, ich
vermische irgendwas mit Klassen und Variablen, aber ich habe keine
Ahnung von diesem unsäglichen C. Und wieso sind Strings einmal einfach
Variablen und einmal (char-)Arrays?
Mit folgendem Code bringe ich die Fehlermeldung in der ersten Zeile weg:
1
Stringstring2send=String(client.read());
2
string2send.replace("$",",");
3
Serial.write(int(string2send));
Scheint irgendwie logisch, obwohl ich es nicht zu 100% verstehe. Aber
jetzt hängt er in der dritten Zeile. Und auch ein:
1
Serial.write(int(string2send));
bringt nichts. Irgendwie schaft er die "Typenrücktransformation" nicht.
Was kann man da machen?
Gruss Chregu
Ach weisst Du wie mir der Unterschied zwischen C++ und chinesisch
vorkommt?
Das eine ist eine unlogische, unstrukturierte Aneinanderreihung von
Buchstaben, und das Andere ist eine von vielen Chinesen gesprochene
Sprache!
Gruss Chregu
Pic T. schrieb im Beitrag #4556244 (+1c):
> { char ch=client.read();> if (ch=='$') ch=',';> Serial.write(ch);}
Ja, das funktioniert tatsächlich perfekt! Danke!
Chregu
Christian M. schrieb:> Ach weisst Du wie mir der Unterschied zwischen C++ und chinesisch> vorkommt?> Das eine ist eine unlogische, unstrukturierte Aneinanderreihung von> Buchstaben, und das Andere ist eine von vielen Chinesen gesprochene> Sprache!
Und weißt du, was die Gemeinsamkeit ist? Wenn man keine Ahnung davon
hat, kommt man nicht wirklich mit wildem rumraten und irgendwas
hinschreiben voran. In beiden Fällen muss man die Sprache lernen, um sie
zu verstehen.
Ach Don und Rolf,
Ihr wart noch nie im Ausland in den Ferien, denke ich. Denn da muss man
die Sprache beherschen um sich zu verständigen. Ein bisschen wichtige
Sätze lernen und mit Handzeichen bringt gar nichts.
Vielen Dank für Eure konstruktiven Beiträge. Entspricht genau dem Wind
im Forum!
Gruss Chregu
Christian M. schrieb:> Entspricht genau dem Wind im Forum!
Entspricht meist dem Wind, den der Fragesteller fahren lässt.
Bei dir stinkt der Wind nach Faulheit.
Christian M. schrieb:> Ein bisschen wichtige Sätze lernen und mit Handzeichen
Probier doch mal aus ob der Compiler intelligent genug ist deine
Handzeichen richtig zu deuten.
> Entspricht genau dem Wind> im Forum!
Nein, das ist der Kälte Wind der erbarmungslosen Realität. Wenn du dir
den Pelz waschen willst musst du akzeptieren dabei nass zu werden. Wenn
du einen Computer programmieren willst dann musst du seine Sprache
lernen. Wenn du keine Zeit dafür hast musst du jemanden der das bereits
kann dazu motivieren das für dich zu tun, so einfach ist das.
Christian M. schrieb:> Ihr wart noch nie im Ausland in den Ferien, denke ich. Denn da muss man> die Sprache beherschen um sich zu verständigen. Ein bisschen wichtige> Sätze lernen und mit Handzeichen bringt gar nichts.
Hä?
tut mir leid, bisher habe ich nie die Sprache des Landes gelernt. Könnte
ich auch gar nicht, denn ich hab für Sprachen kein guten Händchen.
Du glaubst gar nicht, wie weit man mit Händen und Füßen und ein wenig
guten Willen kommt. Im schlimmsten Fall tun es auch ein paar brocken
Englisch.
The D. schrieb:> Glaubt hier jemand ernsthaft, dass der TO die empörten posts noch liest> ?
Nein, warum auch? Er hat eine konstruktive Antwort bekommen, die ihm
half. Dafür hat er sich bedankt. Damit ist die Sache erledigt.
Howlin Wolf schrieb:> Er hat eine konstruktive Antwort bekommen, die ihm> half.Christian M. schrieb:> ENC28J60-Modul über SPI, UIPEthernet-Library.> ...> ich habe keine> Ahnung von diesem unsäglichen C
Die einzige Antwort, die ihm wirklich weiterhilft, ist diese:
Don schrieb:> C++ lernen. Rumraten bringt nichts.
Oliver
Howlin Wolf schrieb:> Er hat eine konstruktive Antwort bekommen, die ihm> half. Dafür hat er sich bedankt. Damit ist die Sache erledigt.
Aber für wie lange? Beim nächsten Problem schlägt er wieder hier auf.
Gib einem Mann einen Fisch und du ernährst ihn für einen Tag. Lehre
einen Mann zu fischen und du ernährst ihn für sein Leben.
Konfuzius
Er wird also um das Lernen nicht herumkommen.
Frank M. schrieb:> Gib einem Mann einen Fisch und du ernährst ihn für einen Tag. Lehre> einen Mann zu fischen und du ernährst ihn für sein Leben.
Das ist zu hoch für die Guttenberg Generation.
Frank M. schrieb:> Gib einem Mann einen Fisch und du ernährst ihn für einen Tag.
Bitteschön:
><((((*>Frank M. schrieb:> Er wird also um das Lernen nicht herumkommen.Christian M. schrieb:> Ach weisst Du wie mir der Unterschied zwischen C++ und chinesisch> vorkommt?> Das eine ist eine unlogische, unstrukturierte Aneinanderreihung von> Buchstaben, und das Andere ist eine von vielen Chinesen gesprochene> Sprache!
Volltreffer!
Nur: Wer zwingt Dich, mit diesem Kram zu arbeiten? Nimm eine Sprache, in
der die Syntax nicht so ein verworrenes Zeug ist. Es bringt nur Verdruß,
in 5 Minuten ein Programmgerüst in Pseudocode zu Papier zu bringen und
sich dann 5 Tage mit der Syntax einer Zeile Quelltext herumärgern zu
müssen.
Howlin Wolf schrieb:> Es bringt nur Verdruß,> in 5 Minuten ein Programmgerüst in Pseudocode zu Papier zu bringen
Du glaubst doch nicht dass der TO weiss was Pseudocode ist.
Howlin Wolf schrieb:> Nimm eine Sprache, in> der die Syntax nicht so ein verworrenes Zeug ist.
Auf deine Vorschläge bin ich jetzt aber gespannt. Die praktische
Einschränkung "Arduino Nano 3.0" sollte allerdings schon beachtet
werden...
Oliver
Oliver S. schrieb:> Auf deine Vorschläge bin ich jetzt aber gespannt.
Um die Spannung nicht in's Unermeßliche zu steigern ;-)
-Bascom
-Assembler
Oliver S. schrieb:> Die praktische> Einschränkung "Arduino Nano 3.0" sollte allerdings schon beachtet> werden...
Das ist keine Einschränkung. Dem Kontroller ist es gleichgültig, womit
die .hex-Datei erstellt wurde, mit der er geflasht wird.
Man kann die Arduino-Programmierumgebung nutzen -/muß/ man aber nicht.
Howlin Wolf schrieb:> -Assembler
Du glaubst ernsthaft, dass der TE, der schon mit ein bisschen
Stringverarbeitung in C++ überfordert ist, ein auch nur ansatzweise
benutzbares Assemblerprogramm aus dem Boden gestampft bekäme?
Eher lernt Moby C++. :-)
Howlin Wolf schrieb:> Um die Spannung nicht in's Unermeßliche zu steigern ;-)>> -Bascom> -Assembler
Tja.. merkt ihr was?
Merkt ihr inzwischen was - oder wirklich noch immer nix?
Die Liste der Alternativen ist wirklich ein bissel kurz, gelle?
Ja, wir haben uns das selber zu verdanken, daß wir heutzutage nur noch
zwischen C, C++ und Assembler oder auf wenigen Systemen BASCOM wählen
können.
Aber wir waren ja jahrzehntelang alle so unendlich klug, so daß wir auf
jede Alternative mit vollster Verachtung herabgeschaut haben und sie
nicht benutzten.
So sind die Alternativen inzwischen eingegangen, vertrocknet wie die
Primeln und die Szene ist eben nicht entwicklerfreundlicher geworden,
sondern das Gegenteil.
Selbst sowas einfaches wie ein HW-Register:
haben können. Aber wer nicht gewollt hat, kriegst's nimmermehr (IAR
lassen wir mal vorab.)
Ätsch, selber dran schuld. Das ist ziemlch genauso wie beim Autokauf, wo
man nur noch Mercedes, BMW und Audi zu je 30% im Markt hat (Passat als
Rest) und beim Aufrufen der Preise für's Blechle einem schlecht wird.
Ebenfalls ätsch.
Es ist durch alle Sparten hindurch das gleiche Schema.
W.S.
Erstens sehe ich keine Äquivalenz zwischen deinen beiden Beispielen und
zweitens: glaubst du wirklich, daß Millionen von Entwicklern zu dumm
sind zu begreifen, was sie falsch oder richtig machen?
W.S. schrieb:> Selbst sowas einfaches wie ein HW-Register:"#define SYSTICK_CTRL> (*(volatile unsigned long*) 0xE000E010)">> hätte man leserlicher alsvar> SYSTICK_CTRL : dword absolute $E000E010;> haben können. Aber wer nicht gewollt hat, kriegst's nimmermehr (IAR> lassen wir mal vorab.)
Was ist denn daran überhaupt logisch? Die obere Zeile ist normales C und
wenn man das Prinzip verstanden hat einfach und simpel. Dein
Geschreibsel dagegen ist kein C und man müsste die Syntax modifizieren.
Abgesehen davon dass ich nicht weiß was das absolute soll, fehlt in
deiner Version das unsigned und volatile.
C ist alles andere als komplziert, wenn man das Prinzip verstanden hat.
C++ setzt noch eins obendrauf, das Design ist trotzdem logisch
aufgebaut, hat aber eine gewisse Komplexität. Über Bascom und Assembler
müssen wir hier gar nicht erst sprechen. Die Möglichkeiten in den beiden
Sprachen sind im Vergleich zu C++ verschwindend gering.
Auch wenn es dir nicht gefällt: C bzw. C++ hat sich eben etabliert, weil
damit effektive Hardwarenahe Programmierung möglich ist. Der Trend geht
sogar inzwischen in Richtung C++. Nur weil du damit nicht zurecht
kommst, trifft das nicht auf den Rest der Welt zu.
W.S. schrieb:
> Selbst sowas einfaches wie ein HW-Register:"#define SYSTICK_CTRL> (*(volatile unsigned long*) 0xE000E010)">> hätte man leserlicher alsvar> SYSTICK_CTRL : dword absolute $E000E010;> haben können. Aber wer nicht gewollt hat, kriegst's nimmermehr (IAR> lassen wir mal vorab.)
Volatile braucht eben nur ein C(++)-Compiler, denn das andere Zeugs kann
mit diesem Hinweis eh nix anfangen. Das braucht man nur, wenn man soweit
optimieren kann, daß man den Unterschied "zwischen jederzeit (von der
HW) änderbar" oder "nur von aktuellen Code abhängig" überhaupt bemerkt.
Hochsprachen ohne C im Namen ahnen davon meist nichts.
avr schrieb:> W.S. schrieb:>> Selbst sowas einfaches wie ein HW-Register:"#define SYSTICK_CTRL>> (*(volatile unsigned long*) 0xE000E010)"> Die obere Zeile ist normales C und
Die obere Zeile ist eben kein C.
C ist leider so arm, dass trotz aller
"Vielseitigkeit"/"Mächtigkeit"/"Systemnähe" nicht auf eine separate
Präprozessor-/Makrosprache verzichtet weden kann.
Die obere Zeile ist Präprozessor (CPP)
M.M.n. ist Arbeitsmässig (sog. Professionell) nur so überwältigend viel
C/C++ vorhanden, weil damit dermassen viele Böcke geschossen wurden dass
eben Unmengen an Nacharbeit, Reimplementationen, Redesigns,
Folgeprodukte usw. nötig wurden.
Hat sich also zum Selbstläufer entwickelt - aber eben nicht weil es
"gut" ist (für viele Metriken von "gut").
Programmiersprachentheaterintendant schrieb:> avr schrieb:>> W.S. schrieb:>>> Selbst sowas einfaches wie ein HW-Register:"#define SYSTICK_CTRL>>> (*(volatile unsigned long*) 0xE000E010)">>> Die obere Zeile ist normales C und>> Die obere Zeile ist eben kein C.> C ist leider so arm, dass trotz aller> "Vielseitigkeit"/"Mächtigkeit"/"Systemnähe" nicht auf eine separate> Präprozessor-/Makrosprache verzichtet werden kann.
Falsch. Geht auch ohne #define. Z.B. als Konstante.
> Die obere Zeile ist Präprozessor (CPP)>> M.M.n. ist Arbeitsmässig (sog. Professionell) nur so überwältigend viel> C/C++ vorhanden, weil damit dermassen viele Böcke geschossen wurden dass> eben Unmengen an Nacharbeit, Reimplementationen, Redesigns,> Folgeprodukte usw. nötig wurden.> Hat sich also zum Selbstläufer entwickelt - aber eben nicht weil es> "gut" ist (für viele Metriken von "gut").
Da lehnst du dich zu weit aus dem Fenster. Es werden auch jede Menge
Neuentwicklungen damit gemacht und das nicht nur, weil es eine breite
Skillbasis dafür gibt. Die ist auch bei anderen Sprachen vorhanden. Man
darf halt nicht stur immer das gleiche tun sondern muß bewusst die
Werkzeuge wählen, die die meisten Anforderungen abdecken.
>> C ist leider so arm, dass trotz aller>> "Vielseitigkeit"/"Mächtigkeit"/"Systemnähe" nicht auf eine separate>> Präprozessor-/Makrosprache verzichtet werden kann.>> Falsch. Geht auch ohne #define. Z.B. als Konstante.
Ein Symbol für einen Wert definieren: ja, sehr gerne - ist schliesslich
der vorzuziehene Weg.
Ein "include guard": na dann mach Du das mal als Konstante, oder
sonstwie ohne CPP...
Programmiersprachentheaterintendant schrieb:> Die obere Zeile ist eben kein C.> C ist leider so arm, dass trotz aller> "Vielseitigkeit"/"Mächtigkeit"/"Systemnähe" nicht auf eine separate> Präprozessor-/Makrosprache verzichtet weden kann.> Die obere Zeile ist Präprozessor (CPP)
Der Präprozessor ist Teil von C. Er ist in jedem C-Compiler enthalten
und hat eine in der C-Norm genau definierte Syntax. Jedes C-Programm,
das etwas erkennbares tut, nutzt den Präprozessor. Zu behaupten, das sei
kein C, ist Unsinn.
avr schrieb:> Auch wenn es dir nicht gefällt: C bzw. C++ hat sich eben etabliert, weil> damit effektive Hardwarenahe Programmierung möglich ist. Der Trend geht> sogar inzwischen in Richtung C++. Nur weil du damit nicht zurecht> kommst, trifft das nicht auf den Rest der Welt zu.
Es ist auch ganz normal, dass technische Dinge, die man nicht versteht,
wahlweise wie Magie oder wie konfuses Zeug wirken. Man hat dann drei
Möglichkeiten, damit umzugehen: Man lernt es, man beschäftigt sich
einfach mit was anderem, oder man macht sich in einem Forum lächerlich.
Rolf M. schrieb:> Es ist auch ganz normal, dass technische Dinge, die man nicht versteht,> wahlweise wie Magie oder wie konfuses Zeug wirken. Man hat dann drei> Möglichkeiten, damit umzugehen: Man lernt es, man beschäftigt sich> einfach mit was anderem, oder man macht sich in einem Forum lächerlich.
Das ist signaturverdächtig. ;-)
Rolf M. schrieb:> Der Präprozessor ist Teil von C. Er ist in jedem C-Compiler enthalten> und hat eine in der C-Norm genau definierte Syntax. Jedes C-Programm,> das etwas erkennbares tut, nutzt den Präprozessor. Zu behaupten, das sei> kein C, ist Unsinn.
...und auf Grund der Unzulänglichkeit von C/C++ muss der
Präprozessor/Makroprozessor auch entsprechend mächtig sein. Das ist
nichts weiter als ein aufgepeppter Makro-Assembler.
Gottseidank das C auf dem absteigenden Ast ist, finde heutzutage mal
noch gute C/C++ Entwickler, die Meisten machen doch schon längst in Java
und anderem Sprachmatsch. Das Einzige was die neuen Sprachen mit C
gemeinsam haben ist die geschweifte Klammer und das Semikolon.
Mike schrieb:> ...und auf Grund der Unzulänglichkeit von C/C++ [..] die Meisten> machen doch schon längst in Java und anderem Sprachmatsch.[...]> Das Einzige was die neuen Sprachen [...] geschweifte Klammer
Und was schlägst Du nun vor nach dieser vernichtenden allumfassenden
Kritik?
Mike schrieb:> ...und auf Grund der Unzulänglichkeit von C/C++ muss der> Präprozessor/Makroprozessor auch entsprechend mächtig sein.
In C++ gibt es für die meisten Stellen, an denen in C Makros benötigt
werden, Alternativen.
> Das ist nichts weiter als ein aufgepeppter Makro-Assembler.
Und was ist daran schlimm?
> Gottseidank das C auf dem absteigenden Ast ist, finde heutzutage mal> noch gute C/C++ Entwickler, die Meisten machen doch schon längst in Java> und anderem Sprachmatsch.
Auf µCs? Ich kann da nicht viel absteigendes bei C erkennen, und Java
spielt dort keine Rolle.
Normalerweise beteilige ich mich nicht an solchen Threads wie, "C/C++
ist blöd" oder "C/C++ ist die tollste Programmiersprache".
Trotzdem würde ich gern ein paar alternative Vorschläge zu C bzw. C++
hören und zwar für den embedded Bereich (8-32bit Mikrocontroller wie ARM
Cortex M0..M4 STM8 AVR).
Mir fallen da wirkliche keine ein.
Java in dem Bereich war wohl als Witz gemeint. In welche Sprache wird
denn die VM für Java geschrieben?
Die Sprache sollte nicht platformspezifisch sein wie z.B. BASCOM.
Matthias K. schrieb:> Trotzdem würde ich gern ein paar alternative Vorschläge zu C bzw. C++> hören und zwar für den embedded Bereich (8-32bit Mikrocontroller wie ARM> Cortex M0..M4 STM8 AVR).
Es gibt wohl den einen oder anderen real existierende Pascal Compiler
und auch bei FPC gibts wohl ein paar angefangene aber noch unfertige
Backends für einige Controller, ARM-Cortex scheint wohl am weitesten
fortgeschritten zu sein: http://wiki.freepascal.org/TARGET_Embedded> Mir fallen da wirkliche keine ein.
Ja, leider recht wenig bis gar keine Auswahl.
Danke für den Hinweis.
Naja das ganze scheint aber wirklich noch am Anfang zu stehen...
Ich persönlich finde Pascal hat ein paar Merkmale die die Sprache
"besser" bzw. sicherer macht (Zuweisung mit ":=" statt "="), aber einige
Eigenschaften sind halt echte Einschränkungen, wenn man C++ kennt
(Bitoperationen, direkte Zuweisung wie z.B. i += a; oder i &= 1).
Thread beobachten
Seitenaufteilung abschalten