Druckbare Version
ich habe es schon geschrieben - ich will keinen streit.
Dieser vorschlag passt. Steht aber nicht auf der ersten seite (um deine worte mal zu nutzen), sondern war erst der dritte schuss. Trotzdem danke....
Evtl. in zukunft weniger aus der hüfte schiessen, mehr zuhören und in ruhe lesen was die anderen schreiben. Und nicht vergessen, es gibt viele anfänger hier, für die ist nix "einfach"....
Ich kenne weder die RP6 lib noch bin ich Gott. Ja, ich habe es nicht gewusst!Zitat:
Ausrede! "natürlich nicht gewusst"!!
Hier gehts um C. Ich kenne mich mit C aus, deshalb wüsste ich nicht warum ich mich nicht einmischen sollte.Zitat:
Und man sollte dort supporten, wo man sich auskennt, hier im RP6 bereich habe ich auf jeden fall noch nicht so viel von dir gehört.
Nein, aber Peter hat zumindest schon auf der 2 Seite den Hinweis dazu gegeben, denn aber jeder ignoriert hat weil es ja ein sogenannter "RP6-Experte" aus dem RP6-Forum besser wusste.Zitat:
Dieser vorschlag passt. Steht aber nicht auf der ersten seite (um deine worte mal zu nutzen), sondern war erst der dritte schuss. Trotzdem danke....
Tut mir Leid dass ich nicht Gott bin und alles beim ersten mal weiß. Ich muss auch alle möglichen Lösungen erst durchprobieren. Ein Schütze muss auch erst viele Schüsse abgeben, bevor er perfekt trifft.Zitat:
Evtl. in zukunft weniger aus der hüfte schiessen, mehr zuhören und in ruhe lesen was die anderen schreiben. Und nicht vergessen, es gibt viele anfänger hier, für die ist nix "einfach"....
UND ICH WAR HIER DER LETZTE, DER STREIT GESUCHT HAT. DAS WARST NUR DU! ICH HABE NUR VERSUCHT DIR ZU HELFEN!
ICH WAR AUCH NICHT IMMER PERFEKT, ABER ICH HABE DEN LEUTEN NICHT GESAGT, DASS SIE SICH HIER SOWIESO NICHT AUSKENNEN UND VERSCHWINDEN SOLLEN.
SOWAS IST EINFACH NUR EINE FRECHHEIT DEINERSEITS!!!!
DU BIST HIER EINFACH WIE EIN INKOMPETENTER B*ASTARD AUFGETRETEN UND GENAU DAS IST AB JETZT AUCH MEINE MEINUNG VON DIR. EINFACH UNGLAUBLICH SOWAS
@ Peter(TOO):
Zitat von Dirk: "uint8_t kennt der Compiler in diesem Fall."
Woher ?
... aus der stdint.h, die bei den RP6 Libs immer mit eingebunden wird (in diesem Fall in der RP6Control.h).
hier wäre es die frage wieso erst das includen der stdint.h in meine standard.h hier abhilfe gebracht hat? Die RP6control.h ist in meinem projekt eingebunden...
Vlt weil du Genie erst die standard.h eingebunden hast und dann die RP6CL.h. Das macht nämlich nen Unterschied.Code:#include "standard.h"
#include "RP6ControlLib.h"
mfg
? Bombardement der USA? Ein schütze muss erst viele Schüsse abgeben? Du bist nicht Gott? Bitte mal beim Thema bleiben, nicht rum schimpfen, und schon gar nicht andere user beschimpfen mit "b*stard" oder sonst was! Ist ja nicht zu glauben!
Inka ist Anfänger (wie ich auch) und als solcher gibt es sicherlich keine blöden fragen, und es kann nie einfach genug sein.
Wenn du keine konstruktive Kritik hast, dann lass es bitte stecken.
Danke
ja, die reihenfolge spielt eine rolle, danke für den hinweis...
Und - genie ist anders. Ich habe mir die bezeichnung beim avatar nicht ausgesucht...
Hallo Wsk8,
Da habe ich vermutlich mehr Erfahrung als du!Zitat:
Zitat von Wsk8
Ich programmiere jetzt seit 25 Jahren in C, hauptsächlich auf Microcontrollern, also ohne bestehendes Betriebssystem. Betriebssysteme habe ich auch schon ein paar geschriben. Zudem war ich an der Entwicklung mehrerer C-Compiler beteiligt.
Beruflich programmiere ich Microprozessoren seit 1976, anfangs mit einem KIM-1, alles von Hand auf Papier assembliert und Hex eingegeben. War eine heiden Arbeit!
Das waren damals Prüfprogamme, mit denen Hardware in der Fabrikation getestet wurde.
Sollte eigentlich an Erfahrung genügen.
Das ist mit Garantie so.Zitat:
Zitat von Wsk8
Der Compiler kennt uint8_t nicht, also wird es lexikalisch als Bezeichner gewertet. Bei der syntaktischen Prüfung ist dann uint8_t kein Datentyp, muss also eine Variable sein, folglich kann daruf nur ein ",", eine andere Variable oder eine ")" folgen!
Folglöich kennt der Compiler an dieser Stelle uint8_t nicht, dass hast du aber bestritten!
Ich habe nicht immer die Zeit und Lust lange Romane zu schreiben!
Deshalb meine Kurze Bemerkung, dass der Compiler uint8_t nicht kennt und der eigentliche Fehler irgendwo vorher zu suchen ist.
Ich habe es schon zur genüge erlebt, dass in Projeten ein Tippfel in eine HeaderDatei, erst viele Seiten und andere Includes später zu einem Fehler führt.
Jeder der etwas mehr Erfahrung mit C hat, kennt das eben, dass der Fehler zwischen Anfang und der gemeldeten Stelle liegt.
Das hängt halt eben auch mit der Freiheit der Sprache zusammen, je restriktiver eine Sprache ist, umso genauer kann die Syntax-Fehlerstelle angegeben werden.
MfG Peter(TOO)
Dann frage ich mich aber, welche Compiler du verwendest?! Der GCC, den ich verwende, gibt die Fehler zu 98% sehr genau aus!! Wenns nicht so genau ist, dann liegts im Normalfall daran, dass man ein Semikolon oder eine Klammer vergessen hat. Und bei solchen Fehlern treten meistens sowieso mehrere Fehler auf, da die ganze Struktur nicht passt.Zitat:
Da habe ich vermutlich mehr Erfahrung als du!
Ich programmiere jetzt seit 25 Jahren in C, hauptsächlich auf Microcontrollern, also ohne bestehendes Betriebssystem. Betriebssysteme habe ich auch schon ein paar geschriben. Zudem war ich an der Entwicklung mehrerer C-Compiler beteiligt.
Beruflich programmiere ich Microprozessoren seit 1976, anfangs mit einem KIM-1, alles von Hand auf Papier assembliert und Hex eingegeben. War eine heiden Arbeit!
Das waren damals Prüfprogamme, mit denen Hardware in der Fabrikation getestet wurde.
Sollte eigentlich an Erfahrung genügen.
Auch frage ich mich, wie du zu der Ansicht gelangt bist, dass der Fehler wo anders als an der angegebenen Stelle liegt? Der Fehler war nämlich mitten in der Parameterliste und uint8_t ist kein selbstdefinierter Typ wo man mal ein Semikolon etc vergisst.
Ich habe gar nichts bestritten :confused: Dazu kann ich mich sogar selbst zitieren:Zitat:
Folglöich kennt der Compiler an dieser Stelle uint8_t nicht, dass hast du aber bestritten!
Zitat:
Nein, aber Peter hat zumindest schon auf der 2 Seite den Hinweis dazu gegeben, denn aber jeder ignoriert hat weil es ja ein sogenannter "RP6-Experte" aus dem RP6-Forum besser wusste.
Du musst auch keinen langen Romane schreiben. Die einfachste Antwort war einfach: "#include <stdint.h>"Zitat:
Deshalb meine Kurze Bemerkung, dass der Compiler uint8_t nicht kennt und der eigentliche Fehler irgendwo vorher zu suchen ist.
mfg
Hallo,
Meistens trifft der Compiler auch die Stelle, aber:Zitat:
Zitat von Wsk8
1. Der Pre-Prozessor funktioniert, etwas vereinfacht, wie "suchen und ersetzen" in einen Texteditor. Fehler welche durch Macros entstehen, treten daher nicht an der Stelle wo das "#define" steht auf, sondern dort wo das Macro verwendet wird.
2. Selbiges gilt auch, wie in diesem Fall, für fehlende "typedef". Wobei ich jetzt keine Ahnung habe, wie die Definition in der verwendeten Implementierung gemacht wird. Grundsätlich ist die Verwendung von "typedef" und "#define" in diesem Fall gleichwertig.
3. Eine fehlende "}" wird oft erst bei der Definition der nächsten Funktion erkannt. Das liegt an der gültigen Syntax von C.
uint8_t gibt es in Standard-C erst seit C99.Zitat:
Zitat von Wsk8
Compilertechnisch, bleibt es aber ein selbst definierter Datentyp.
Das dieser in stdint.h hinterlegt ist, ist eine implementierungsspezifische Erweiterung, dieser muss nicht in einer konkreten Implementierung vorhanden sein.
Hier mal die Datentypen welche Standard-C kennt:
http://en.wikipedia.org/wiki/C_data_types
C ist wohl die am meisten falsch verstandene Sprache.
Der Compiler kennt nur um die 30-40 Schlüsselwörter und eine Hand voll Operatoren.
Der ganze Rest wie z.B. itoa();, printf(); usw., sind Funktionen welche sich in, heute standartisierten, Bibliotheken befinden und sich aber, aus Sicht des Compilers, in keiner Weise von eigenen Funktionen unterscheiden.
Ursprünglich, nach K&R, waren die ganzen Bibliothen nicht direkter Bestandteil der Sprachdefinition.
Dies mach aber die ganze Stärke von C aus!
In Pascal gab es z.B. keine Möglichkeit, Funktionen mit variabler Parameterzahl zu schreiben. Einzig write() konnte dies, weil write() ein Schlüsselwort war und der Compiler bei diesem eine Ausnahme machte. Änlich ist es bei BASIC mit PRINT.
Bei C kann ich problemlos das printf() durch eine eigene Funktion ersetzen und dann Programme, ohne Änderung, überersetzen und mit meinem printf() linken.
Auch kann man in C ein eigenes Dateisystem schreiben. Ich habe das bei vielen µP-Anwendungen gemacht. Da gab es vielleicht nur zwei Datwenstrukturen, welche als Datei angesprochen werden konnten. Das Dateisystem konnte deshalb nur mit zwei, fest vorgegebenen "Dateinamen" arbeiten, auf die konnte man dann aber über die "normalen Dateifunktionen" zugreifen. Dies hatte den Vorteil, dass der selbe Sourcecode auch auf einem PC verwendet werden konnte, auf dem µP aber kein aufwändiges Dateisysten programmiert werden musste. Zudem konnte jeder C-Programmierer erkennen, was der Code macht.
Dies gilt scheinbar nur bei dem verwendeten Compiler und den, bzw. die verwendeten Bibliotheken, kenne ich (noch) nicht, da ich bisher nicht mit dem AVR gearbeitet habe.Zitat:
Zitat von Wsk8
Zudem gibt es auch noch das Problem der richtigen Reihenfolge, da war der UP auch recht zurückhaltend.
MfG Peter(TOO)