Hallo zusammen! Ich habe wahrscheinlich eine eher einfache und vielleicht auch etwas dumme Frage. Aber ich da ich anscheinend irgendwie auf Kriegsfuß mit Pointern stehe, muss ich die Frage hier mal in die Runde werfen! Zu meinem Problem: Ich möchte mir gerne den Wert der im externen Speicher meines µC auf der Adresse 0x400000 steht über printf ausgeben lassen. Wie zum Teufel pack ich das in meinen C-Code ohne das der Compiler mit mir meckert und dazu auch noch das gewünschte Ergebniss raus kommt? Gruß Andreas
printf("%02X", *((uint8_t *) 0x400000));
oder
printf("%08X", *((uint32_t *) 0x400000));
oder beliebige Permutationen davon.
Zuerst einmal Danke für die schnelle Antwort! Allerdings motz mein herzallerliebster Tasking Compiler bei dem Code rum:
1 | printf("Wert der Speicheradresse 0x400000 = %06X \n \n", *((uint16_t *) 0x400000)); |
2445: printf("Wert der Speicheradresse 0x400000 = %06X \n \n",
*((uint16_t *) 0x400000));
E 42: syntax error, expecting statement
E 14: ';' inserted
total errors: 2, warnings: 0
An der Zeile selbst kann es nicht liegen. Zeig mal ein bisschen von der Umgebung, in der Du diese Zeile verwendest. Ansonsten ist %06X ein merkwürdiger Formatspezifizierer für einen uint16_t.
Ich glaube, ich hab das Problem nach langem durchstöbern des Internets gefunden. uint8_t & Co sind AVR-spezifische Variablentypen die im AVR-Framework definiert sind. Da ich hier nen XC161 habe und dieser über den Tasking Compiler gefüttert wird gibt es für den eben diese Variablentypen nicht. Ich versuch es jetzt erst einmal mit einem normalen int und schau mal was raus kommt!
Andreas Schunkert schrieb: > uint8_t & Co sind AVR-spezifische Variablentypen die im AVR-Framework > definiert sind. nein sind sie nicht. http://de.wikipedia.org/wiki/C-Standard-Bibliothek > stdint.h
Na also! Mit int meckert der Compiler auch nicht mehr und am Ende bekomme ich auch den erwarteten Wert auf der Speicheradresse angezeigt! :-) Danke für die Hilfe! Gruß Andreas
Dein sündhaft teurer Tasking kennt kein uint8_t? Und nennt sich C-Compiler? Da du embedded unterwegs bist noch ein Tip: auch wenn "int" an dieser Stelle funktioniert, lass es! Nimm lieber einen der "neuen" Typen, sonst kannst du dir unter Umständen unerklärliche Fehler einhandeln...
Hans schrieb: > Dein sündhaft teurer Tasking kennt kein uint8_t? > Und nennt sich C-Compiler? Naja, C99 wird nach wie vor nicht von jedem kommerziellen C-Compiler unterstützt. Und also ist stdint.h auch nicht unbedingt dabei -- oder wurde hier einfach nur vergessen, diese einzubinden?
Aus dem "TASKING VX-toolset for C166 User Guide" von 2006, das auch die XC16x-Controller abdeckt:
1 | The header files stdint.h and inttypes.h provide additional declarations |
2 | for integer types and have various characteristics. The stdint.h header |
3 | file contains basic definitions of integer types of certain sizes, and |
4 | corresponding sets of macros. This header file clearly refers to the |
5 | corresponding sections in the ISO C99 standard. |
Aber man muss stdint.h natürlich explizit includen, sonst gibt's kein uint16_t :)
Andreas Schunkert schrieb: > Na also! Mit int meckert der Compiler auch nicht mehr und am Ende > bekomme ich auch den erwarteten Wert auf der Speicheradresse angezeigt! Du weißt aber schon, dass int vorzeichenbehaftet ist, und von der Wortbreite des Prozessors abhängig?
:
Bearbeitet durch User
Ich (C/Cpp-Anfänger) habe es mal unter CodeBlocks ausprobiert. Einfaches Programm zeigt 256-Byte-Speicherblock in 16 Zeilen zu je 16 Bytes an. Mit o.g. Adresse 0x400000 klappt es. Wenn ich aber z.B. bis zu 64 MB davon abweiche, kommt eine Fehlermeldung wie "Programm memview.exe funktioniert nicht mehr.", manchmal auch mit den Optionen "Online nach Lösungen suchen" und "Programm schliessen ?". Woran kann es liegen ? Habe Quelltext mehrmals editiert, beim Compilieren bestimmter Versionen trat Trojaner-Alarm der AV-Software auf (wie auch bei einigen Beispiel-Quelltexten aus meinem C-Einsteigerhandbuch). Ist das normal ? Was ist mit Windows-Speichermanager ? Habe mal gelesen, daß dieser keinen eigenmächtigen Zugriff auf fremde Speicherbereiche zuläßt. Ist ja hier der Fall, da ein Zugriff ohne Windows-Speicher-Handle erfolgt. Wegen dem hier genannten ist der Win7-Zuverlässigkeitsverlauf randvoll mit Problemberichten, die an µsoft gesendet werden. Läßt sich das abstellen, ohne wichtige Problemberichte zu behindern ? Ich finde Option zum Löschen einzelner Berichte nicht mehr. Any help ? Thank you !
Rainer V. schrieb: > Woran kann es liegen ? Die Speicherverwaltung des Betriebssystems füllt nicht jede Adresse im 4-GB-Adressraum eines Prozesses mit Speicher, sondern fängt Zugriffe auf unbelegte Speicherbereiche ab. Solange Dein Programm keinen Exception-Handler installiert, um diese Windows-Exceptions abzufangen, wird Dein Programm mit einer entsprechenden Fehlermeldung beendet. Speicher wird mit den Win32-API-Funktion GlobalAlloc bzw. LocalAlloc angefordert, wenn Du die Speicherverwaltung der C-Runtime-Library (malloc/free) umgehen möchtest. > Läßt sich das > abstellen, ohne wichtige Problemberichte zu behindern ? Glaubst Du, daß es überhaupt irgendwas bringt, "Problemberichte" an MS zu senden? Stell den Kram einfach komplett ab. Im übrigen plenkst Du.
Danke für Hinweis! Was über Plenken gelernt. So besser? Problemberichte stelle ich auf "Vor Senden bestätigen". Ich habe noch nie eine Antwort erhalten. Besser, sonst wäre sicher eine Zahlungsaufforderung dabei. Wegen vieler Bluescreens habe ich mal wochenlang den µsoft-Support durchwühlt. Das haben die gemerkt, Messagebox: "Stundenlohn 72 Euro". Eine Weile später war FAQ-Auflistung plötzlich zu Ende, letztes Thema hieß "Wo hat der Leopard seine braunen Flecken her?" (welcher, der von freepascal.org?). Nach Anklicken erschien keine Antwort, sondern die µsoft-Startseite. Exeption Handling: engl.-sprach. Tutorials im Web, auf en.wikibooks.org wird einiges gut erklärt. Bin aber erst noch mit Grundlagen beschäftigt, auch Pointer, Typecast, malloc(), realloc() usw., Inline-Assembler und Fenstererzeugung mit WinAPI. Letzteres kenne ich nur aus OOP in TPascal für Windows, kenne aber auch gute Tutorials, z.B. auf pronix.de. Blöde Frage: Kann man das System zerhämmern, wenn in C/Cpp die Syntax bei Pointern und Typecast verwechselt und durch falsch gesetzten Asterix (*) nicht aus dem Speicher gelesen, sondern da hineingeschrieben wird?
Rainer V. schrieb: > Blöde Frage: Kann man das System zerhämmern, wenn in C/Cpp die Syntax > bei Pointern und Typecast verwechselt und durch falsch gesetzten Asterix > (*) nicht aus dem Speicher gelesen, sondern da hineingeschrieben wird? Wenn du mit 'das System' Windows meinst: Genau das sollte ein ordentliches Betriebssystem verhindern, indem es deine Speicherzugriffe überwacht und dich nicht in Speicherbereiche schreiben lässt, die nicht zu deinem Programm gehören.
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.