Hi Kollegen, ich möchte gerne das meine Variablen im C Programm beim starten einen definierten Wert haben z.B. 0. Der Compiler den ich benutze tut dies nicht von alleine daher stellt sich mir dir Frage wie ich das bei einem PIC32 anstelle. Beim PIC18F war das recht einfach mit einem Pointer der nacheinander alle RAM Adressen mit 0 beschrieben hat. Im PIC32 ist der RAM jedoch aufgeteilt in diverse Bereich die offenbar dazu noch unterschiedlichen Typen zugeordnet sind (Kernel, User). Wie kann ich im PIC32 die RAM Bytes einzeln nacheinander Adressieren und beschreiben? Hat das schon mal jemand gemacht? Den Variablen bei der deklaration gleich einen Wert zuzuweisen ( int i = 0; ) kommt nicht in Frage da sowohl viele kleine Variablen als auch große Arrays benutzt werden. Danke für eure Ideen
Die Größe der arrays spielt doch keine rolle. uint8_t blubb[64] = {0};
feddich
Wenn du so viele variablen hast die alle mit 0 initialisiert sein müssen
dann machst du doch irgendwas falsch.?!
Oli Holli schrieb: > ich möchte gerne das meine Variablen im C Programm beim starten einen > definierten Wert haben z.B. 0. Der C Standard schreibt vor, dass globale und statische Variablen automatisch mit 0 initialisiert werden. Woran sich ein Compiler also tunlichst halten sollte. Wenn nicht: Tonne auf, rein damit, Tonne zu. Oder rauskriegen, was man selber falsch gemacht hat. Für nicht-statische lokale Variablen gilt das freilich nicht. Bei denen ist explizite Initialisierung Pflicht, einen anderen Weg gibt es nicht. Ein Versuch, das durch direktes Beschreiben vom RAM zu erreichen, wird sehr wahrscheinlich im Nirvana enden und ohnehin nicht den erwünschten Effekt bringen. Und es ist mit Sicherheit der falsche Ansatz.
Oli Holli schrieb: > Der Compiler den ich benutze tut dies > nicht von alleine Auf welchen Namen hört den der Herr Compiler ? MfG Klaus
Hallo, wenn man defensiv programmiert (das ist wie defensives Autofahren - man versucht, einen Unfall auch dann zu vermeiden, wenn man eigentlich im Recht ist), sollte man JEDE Variable selbst initialisieren. Beim Start den Speicher zu testen und dann auf Null zu setzen ist keine dumme Idee, nützt aber bloss was für globale Variablen. Gruss Reinhard
A. K. schrieb: > Der C Standard schreibt vor, dass globale und statische Variablen > automatisch mit 0 initialisiert werden. Woran sich ein Compiler also > tunlichst halten sollte. Ist das beim GNU C Compiler nicht auf "externe Mitarbeiter" ausgelagert :-) ? Reinhard Kern schrieb: > sollte man JEDE Variable selbst initialisieren. Das wird den GCC im globalen Fall nicht immer beindrucken, die Standard-Einstellung ist "-fzero-initialized-in-bss", d. h. der GCC erkennt die Zuweisungen auf 0 und optimiert diese weg. Nutze ich gerne für die kleinen µCs, um Flash zu sparen. Selbst wenn dies nicht der Fall wäre, würde man damit eher ein anderes Problem kaschieren, denn gemäß Standard ist es 0. Fehler beim "alignment" in Linker-Skripten sind so selten nicht, und mir persönlich ist es lieber, wenn Probleme sofort auftreten. http://stackoverflow.com/questions/8721475/if-a-global-variable-is-initialized-to-0-will-it-go-to-bss
Timmo H. schrieb: > Die Größe der arrays spielt doch keine rolle. uint8_t blubb[64] = {0}; > feddich > Wenn du so viele variablen hast die alle mit 0 initialisiert sein müssen > dann machst du doch irgendwas falsch.?! Danke für die vielen Antworten. uint8_t blubb[64] = {0}; Verbessert mich bitte wenn ich falsch liege, aber so initialisiere ich doch nur das erste Element eines Array und nicht die reslichen 63 oder nicht ? Der Compiler den ich benutzte ist der mikroC Pro für PIC32 von MikroElektronika welcher mir ausgesprochen gut gefällt im Gegensatz zu denen aus dem Hause Microchip.
Roland H. schrieb: > Ist das beim GNU C Compiler nicht auf "externe Mitarbeiter" ausgelagert Die feinsinnige Unterscheidung zwischen den einzelnen Produkten Präprozessor, Compiler, Assembler, Linker, IDE und Library hatte ich mir diesmal erspart. Ausserdem geht es hier nicht um den GCC.
Reinhard Kern schrieb: > Hallo, > > wenn man defensiv programmiert (das ist wie defensives Autofahren - man > versucht, einen Unfall auch dann zu vermeiden, wenn man eigentlich im > Recht ist), sollte man JEDE Variable selbst initialisieren. > > Beim Start den Speicher zu testen und dann auf Null zu setzen ist keine > dumme Idee, nützt aber bloss was für globale Variablen. > > Gruss Reinhard Das sehe ich genauso alle Variablen zu definieren sorgt für klare Verhältnisse und sorgt außerdem dafür das man Fehler schneller aufspüren kann. Bei bisherigen Controller Programmen habe ich daher zuerst den ganzen RAM auf Null gesetzt und musste folglich nur noch Variablen initialisieren die nicht Null sein sollten, was meist sehr selten ist. Sinn macht das allerdings nur wenn das sehr einfach zu bewerkstelligen ist, was bei den bisherigen Projekten der Fall war. Bei einem PC Programm macht das sicher keinen Sinn. Handbuch des Compilers: http://www.mikroe.com/downloads/get/1608/mikroc_pro_pic32_v100.pdf Da mir die Begriffe static, global, local nicht besonders geläufig sind hab ich schwierigkeiten herauszulesen ob der Compiler alles globale mit 0 initialisiert oder nicht (Seite 195).
Oli Holli schrieb: > Danke für die vielen Antworten. uint8_t blubb[64] = {0}; Verbessert mich > bitte wenn ich falsch liege, aber so initialisiere ich doch nur das > erste Element eines Array und nicht die reslichen 63 oder nicht ? Bei globalen oder statischen Daten besteht kein Unterschied, da sowieso alles auf 0 gesetzt wird. Und eine Initialiserung lokaler Arrays gibt es noch nicht so lang - ob das der mikroC überhaupt unterstützt?
A. K. schrieb: > Roland H. schrieb: >> Ist das beim GNU C Compiler nicht auf "externe Mitarbeiter" ausgelagert > > Die feinsinnige Unterscheidung zwischen den einzelnen Produkten > Präprozessor, Compiler, Assembler, Linker, IDE und Library hatte ich mir > diesmal erspart. Ausserdem geht es hier nicht um den GCC. Da muss ich Roland recht geben es geht nicht um den GCC sondern um MikroC for PIC32, nichts desto trotz war die Idee hilfreich ob der Compiler vielleicht diese Arbeit schon erledigt und der Fehler in meinem Programm liegen.
A.K. muss ich recht geben, meinte ich. Bin mit den Zitaten durcheinander gekommen.
Oli Holli schrieb: > Handbuch des Compilers: Wie man sich bettet, so liegt man: "In the mikroC PRO for PIC32, static duration objects are not initialized to zero (or null) in the absence of any explicit initializer." Wenn man sich freiwillig einem Compiler unterwirft, der den C Standard geflissentlich ignoriert, dann sollte man sich auch auf andere Überraschungen gefasst machen. Ob die Initialisierung des ersten Elementes auch die anderen initialisiert, das könnten dir deshalb nur intime Kennner dieses speziellen Compilers verraten. Mit normalem C hat das ja nicht mehr viel zu tun. Ähnlich ist das mit deiner Idee, das RAM zu nullen. Wann das in welcher Weise möglich ist, und ob überhaupt, das weiss auch nur ein intimer Kenner dieses Compilers.
A. K. schrieb: > Oli Holli schrieb: >> Handbuch des Compilers: > > Wie man sich bettet, so liegt man: "In the mikroC PRO for PIC32, static > duration objects are not initialized to zero (or null) in the absence of > any explicit initializer." > > Wenn man sich freiwillig einem Compiler unterwirft, der den C Standard > geflissentlich ignoriert, dann sollte man sich auch auf andere > Überraschungen gefasst machen. Wie gesagt ist der Compiler eine echte Empfehlung was ich weder für MPLAB IDE und noch weniger für MPLAB X vergeben würde. Den Compiler nur auf die Initialisierungs von Variablen zu reduzieren für eine Bewertung ist denke ich unangebracht. Ich versichere dir das der Compiler mit ganz neuen Ideen aufwartet um das programmieren zu erleichtern.
Oli Holli schrieb: > auf die Initialisierungs von Variablen zu reduzieren für eine Bewertung > ist denke ich unangebracht. Auch wenn ich diese Entscheidung des Autors für zweifelhaft halte ist das hier nicht wirklich der Punkt. Da der Compiler vom Standard abweicht sind nur Antworten brauchbar, die sich auf diesen speziellen Compiler beziehen. Erfahrungen mit normalem C oder PIC32 generell helfen dir deshalb nicht weiter. Und da dieses Produkt hier vermutlich nicht allzu verbreitet ist, bist du in einem Forum speziell für dieses Produkt möglicherweise besser dran. Die Chancen, dort Leute zu finden, die dieses Produkt genau kennen, sind dort grösser. Generell würde ich dir aber dringend raten, alles explizit zu initialisieren, was initialisert werden soll. Und bei Arrays entweder in den Code rein zu sehen, was tatsächlich passiert, oder beim Hersteller anzufragen, oder memset() bemühen.
A. K. schrieb: > Ähnlich ist das mit deiner Idee, das RAM zu nullen. Wann das in welcher > Weise möglich ist, und ob überhaupt, das weiss auch nur ein intimer > Kenner dieses Compilers. So geht das eh nicht, Ram testen und nullen geht nur ganz am Anfang im Startup, lange bevor das C-Programm startet. Wenn Stack und Heap eingerichtet sind und benutzt werden, hat das nicht mehr viel Sinn. Siehe PC-BIOS. Man muss nur wissen, welcher Code-Teil nach Reset als erstes ausgeführt wird. Gruss Reinhard
Reinhard Kern schrieb: > A. K. schrieb: >> Ähnlich ist das mit deiner Idee, das RAM zu nullen. Wann das in welcher >> Weise möglich ist, und ob überhaupt, das weiss auch nur ein intimer >> Kenner dieses Compilers. > > So geht das eh nicht, Ram testen und nullen geht nur ganz am Anfang im > Startup, lange bevor das C-Programm startet. Wenn Stack und Heap > eingerichtet sind und benutzt werden, hat das nicht mehr viel Sinn. > Siehe PC-BIOS. > > Man muss nur wissen, welcher Code-Teil nach Reset als erstes ausgeführt > wird. > > Gruss Reinhard Wenn ich in meine Main-Schleife also als erstes ein sagen wir "RAM_Killer" Funktion aufrufe ist das Quasi schon zu spät? Verstehe ich das richtig?
Reinhard Kern schrieb: > So geht das eh nicht, Ram testen und nullen geht nur ganz am Anfang im > Startup, lange bevor das C-Programm startet. Nicht unbedingt. Startup-Code von µCs ist oft so einfach, dass man u.U. den BSS Bereich auch erst in main() intialisieren könnte - wenn es der Startup-Code nicht sowieso schon täte. Die Grenzen dieses Bereichs sind bei GCC Lösungen üblicherweise durch vom Linker generierte Symbole gegeben. Aber dies ist natürlich dann auch eine hochspezifische Lösung. Und taugt nicht für C++.
Oli Holli schrieb: > Wenn ich in meine Main-Schleife also als erstes ein sagen wir > "RAM_Killer" Funktion aufrufe ist das Quasi schon zu spät? Verstehe ich > das richtig? Die exakte Auskunft kennen nur intime Kenner des Compilers. Das Risiko, sich damit selbst abzuschiessen, ist aber hoch. Wenn schon, dann müsste man rausfinden, wo die Grenzen des RAM Bereichs für nicht explizit intialisierte statische Variablen liegen, sofern die bei diesem Compiler überhaupt am Stück liegen. Selbst dann wäre es immer noch möglich, dass man irgendwelche vorher stattfindenden Intialisierungen im Startup damit zerlegt. Überdies ist ein solcher Hack versionsabhängig. Schon die nächste Version des Compilers kann dir deine fein zurecht gedrechselte Lösung vernichten.
Nagut dann ist es also offensichtlich ein besserer Ansatz eine Funktion für diesen Vorgang zu nutzen die ein "normales" C Programm enthält. Was ist denn wenn ich einen Pointer benutze um damit Byte für Byte im ganzen RAM zu löschen ? Springe ich mit einem Pointer immer von Variable zu Variable oder von Byte zu Byte ? Im Handbuch hab ich mitlerweile folgende Aussage gefunden: - The mikroC PRO for PIC32 does not provide automatic initialization for objects. Uninitialized globals and objects with static duration will take random values from memory. Da die Funktion im Compiler nicht vorhanden ist, ist die Diskussion umso wichtiger wie man das mit C erreichen kann. Die Beiträge sagen mir, "Hier ist doch geballtes C wissen am Start" da muss es doch ne Möglichkeit geben wenigstens die Globalen Variablen zu initialisieren.
Oli Holli schrieb: > Was ist denn wenn ich einen Pointer benutze um damit Byte für Byte im > ganzen RAM zu löschen ? Springe ich mit einem Pointer immer von Variable > zu Variable oder von Byte zu Byte ? Erwartest du ernsthaft, dass es ausreicht, die gleiche Frage immer und immer wieder zu stellen, in der Hoffnung, dass du irgendwann eine andere günstigere Antwort erhältst? > Die Beiträge sagen mir, "Hier ist doch geballtes C wissen am Start" da > muss es doch ne Möglichkeit geben wenigstens die Globalen Variablen zu > initialisieren. Geballtes C Wissen nützt nichts, wenn es sich nicht um C handelt. Und da der Compiler hier vom Standard abweicht, sind Experten für diesen einen Compiler gefragt. Die einzige generische Antwort lautet daher: Tu das was das Manual vom Compiler dir sagt. Intialisiere alles explizit, notfalls mit memset().
Die Fragestellung wurde keinesfalls wiederholt, stattdessen war die Frage ob der neue Ansatz einen Pointer zu benutzen Sinn macht. Darüber handelt es sich selbstverständlich sehr wohl um C die einzigen Ausnahmen sind folgende wovon einige klare Vorteile zum Standard darstellen: ------------------------------------------------------------------------ - Case Sensitivity. Check identifiers - The mikroC PRO for PIC32 treats identifiers declared with the const qualifier as “true constants” (C++ style). This allows using const objects in places where ANSI C expects a constant expression. If aiming at portability, use the traditional preprocessor defined constants. See Type Qualifiers and Constants. - The mikroC PRO for PIC32 allows C++ style single–line comments using two adjacent slashes (//). The comment can start at any position and extends until the next new line. See Comments. - A number of standard C libraries (ctype, math, stdlib, string) have been implemented; check the individual functions for divergence. - The mikroC PRO for PIC32 does not provide automatic initialization for objects. Uninitialized globals and objects with static duration will take random values from memory. - Anonymous unions and structures are now supported. ------------------------------------------------------------------------ - MPLAB ist darüber hinaus ebenso mit den "code" und "data" Befehlen erweitert was ebenfalls nicht zum C Standard gehört. Folglich hätten die MPLAB Compiler deiner Meinung nach also auch nichts mit C zu tun. Die Wortwahl es handle sich nicht um C ist daher unglücklich gewählt. Der Tipp mit memset() ist darüber hinaus doch schonmal ein sehr brauchbarer Anfang.
Oli Holli schrieb: > Die Wortwahl es handle sich nicht um C ist daher unglücklich gewählt. Also anders: In dem speziellen Aspekt der Initialisierung statischer Daten hält sich der Compiler ausdrücklich nicht an den C Standard. Deshalb sind bei diesem Compiler Fragen an C Experten zur Initialisierung statischer Daten sinnlos. > Die Fragestellung wurde keinesfalls wiederholt, Nicht wörtlich, aber dem Sinn nach.
ich versteh den ansatz ein RAM zu "nullen" schon mal garnicht. was soll dir das bringen? irgendwann kommt dort doch evtl. ein datum rein. und davon abgesehen initialisiere alle varibalen und arrays mit null wenn dir das so wichtig ist. für ein array kannst du eine schleife verwenden oder wie schon beschrieben wurde die memset() funktion. das ist gängige praxis meiner meinung nach, den RAM "nullen" ist hier ein wunsch der im nirvana enden wird. und wenn der compiler wie oben beschrieben vom gängigen C abweicht dann kann er doch nicht so toll sein wie du behauptet hast. die C18 oder high-tech compiler, welche mplab gern benutzt finde ich super. hatte damit noch nie probleme, aber das ist geschmackssache
busche schrieb: > und wenn der compiler wie oben beschrieben vom > gängigen C abweicht dann kann er doch nicht so toll sein wie du > behauptet hast. es sei den der Compiler möchte etwas besseres anbieten als den Standard ! Ich Empfehle dir mit beiden mal zu arbeiten, erst dann kannst du auch nach unterschieden suchen. Ich für meinen Teil habe schon mit beiden gearbeitet und kann klare Unterschiede feststellen. Ich denke ich werde die Variablen bei der Deklaration, wie üblich, initialisieren und die Arrays wie von euch empfohlen mit Memset.
Memset() funktioniert sehr gut, auch wenn ich jedes Array einzeln initialisieren muss ist es eine vertretbare Lösung. Danke soweit schonmal.
Nur weil die PIC32 Familie Speicher Virtualisierungen anbietet, heißt das noch lange nicht, dass du den Physikalischen Bereich nicht mit Pointern leeren kannst...? Im Gegenteil, da hat der Compiler vermutlich weniger Arbeit als bei der PIC18 Familie, weil er nicht dauernd Bank switchen muss.
Das ist ja der Witz dran. Eigentlich ist es sehr einfach, solche Daten vorab en bloc zu löschen. Ich kann nur spekulieren, dass dies aus Absicht unterbleibt, um einem sich nach einem Soft-Reset neu startenden Programm die Möglichkeit zu geben, ohne spezielle Attributierung bestehende Daten weiterverwenden zu können.
Ich würde das gerne versuchen, ich kann auch aus dem Datenblatt und internen Registern die Positionen der Physikalischen Speicherbereiche herausbekommen, aber ich habe keine Idee wie ich mit C auf physikalische Adressen zeigen kann um die dann Byte für Byte zu löschen.
LASS ES Du weisst weder, welche Speicherstellen du löschen darfst und welche nicht, noch hast du erkennbar einen Schimmer davon, was auf dieser Ebene eigentlich geschieht. Das was ich gerade schrieb bezieht sich auf den vom konkreten Compiler (bzw. dessen Entwicklungsumgebung) definierten Startup-Code, der in Kenntnis des betreffenden Speicherbereichs diesen löschen kann. So geschieht das in avr-gcc und diversen arm-gcc. Ohne tiefe Kenntnis der Arbeitsweise von der Enwicklungsumgebung, den verwendeten Speicherlayout und dem Startup-Code ist das nicht angebracht. Es ist ja noch nicht einmal klar, ob diese Daten überhaupt am Stück liegen. Es könnte leicht passieren, dass neben Stacks alle explizit und nicht mit 0 initialisierten Daten bei deinem Versuch über den Jordan gehen, inklusiver derer in der Library.
Hallo, es ist völlig egal, ob du memset, Assembler oder sonstwas benutzt, um physikalischen Speicher zu löschen, solange du nicht exakt weisst, was an der betreffenden Stelle steht bzw. stehen sollte. Deswegen habe ich ja den Startupcode direkt nach Reset vorgeschlagen, weil es da noch keine Stacks, Heaps und sonstige bereits benutzte Speicherplätze gibt. Ich mache das auch so, weil es zugleich mit dem Test des Speichers verbunden ist, den man später auch nicht mehr durchführen kann, natürlich lasse ich dabei z.B. batteriegestützte Speicherbereiche aus, wo die Messdaten des laufenden Experiments stehen. Auch da muss man also die Belegung kennen, es ist aber um ein Vielfaches einfacher als bei einem laufenden C-Programm. Du hast aber von der Belegung nicht die geringste Ahnung und es interessiert dich offensichtlich auch nicht, du fragst bloss immer nach einer Methode, egal ob das dann zum Abschuss des Systems führt - was bei wildem Herumlöschen im Speicher irgendwann passieren wird. Du kommst mir vor wie auf dem Besuchersteg im Federsee - ein Holzweg, der mitten im Sumpf aufhört. Mit den entsprechenden Mitteln kannst du ja auch den Speicher deines PC nullen, du siehst dann bloss nichts mehr vom Ergebnis. Auch wenn du noch zehnmal fragst wie man das am besten macht. Gruss Reinhard
Reinhard Kern schrieb: > Mit den entsprechenden Mitteln kannst du ja auch den Speicher deines PC > nullen, du siehst dann bloss nichts mehr vom Ergebnis. NB: Ich mach das ab und zu tatsächlich. Also sowas wie dd if=/dev/zero of=/dev/kmem Das Ergebnis ist unübersehbar, auf dem Error-Display vom Server.
Oli Holli schrieb: > es sei den der Compiler möchte etwas besseres anbieten als den Standard Was soll denn an diesem Compiler jetzt "besser" sein als der C-Standard? Oli Holli schrieb: > Ich versichere dir das der Compiler mit ganz neuen Ideen aufwartet um > das programmieren zu erleichtern. Und welche wären das?
Wenn du der Meinung bist das ich etwas nicht weiß dann könntest du mir doch einfach erklären was ich nicht weiß anstatt mich dafür an den Pranger zu stellen. Dafür das man in einem Forum Fragen stellt muss sich keiner beleidigen lassen. Wenn noch jemand sachdienliche Hinweise hat, darf er die gerne hier präsentieren, wer lieber noch ein paar Beleidigungen los werden möchte geht besser zu Vera am Mittag.
Rufus Τ. Firefly schrieb: > Oli Holli schrieb: >> es sei den der Compiler möchte etwas besseres anbieten als den Standard > > Was soll denn an diesem Compiler jetzt "besser" sein als der C-Standard? > > Oli Holli schrieb: >> Ich versichere dir das der Compiler mit ganz neuen Ideen aufwartet um >> das programmieren zu erleichtern. > > Und welche wären das? Dazu gehört z.B. - die PIC konfiguration über eine GUI die weit übersichlicher ist als das Datenblatt. - die bereits eingebundenen 500 Bibliotheken - eine vom Hersteller eingerichtete Websites zum hoch und runterladen von Bibliotheken - Ein Interrupt Assistent der beim Einrichten von Interrupts hilft - Diverse Zusatzsoftware zum erstellen von Graphiken für TFT Display, Bootloader, HID Terminal, ... - Er ist sehr günstig im gegensatz zu Microchip Produkten - Er bietet diverse Optionen zur Code Optimierung - Ein Blick auf die Internetseite versorgt dich mit weiteren infos.
Oli Holli schrieb: > anstatt mich dafür an den Pranger zu stellen. Wen meinst Du jetzt? Mich etwa? Ich habe Dir nur zwei wertneutrale Fragen gestellt. > Dafür das man in einem Forum Fragen stellt muss sich keiner beleidigen > lassen. Nein, mich kannst Du wirklich nicht gemeint haben.
Oli Holli schrieb: > Wenn du der Meinung bist das ich etwas nicht weiß dann könntest du mir > doch einfach erklären was ich nicht weiß anstatt mich dafür an den > Pranger zu stellen. Es gibt Dinge, die man nicht "einfach" erklären kann. Sondern nur aufwendig. Zumal wenn zu viel Grundlagen fehlen. Du könntest das ausserdem selber machen. Sowas musst du dir nämlich nicht erklären lassen, das kannst du selber herausfinden. Indem du ein Programm disassembliert oder den Quellcode von Startup und Library findest und ab Reset Befehl für Befehl durchgehst, um herauszufinden, was dort getan wird. Und das dann mit Linker-Mapfile und -Symboltabelle korrelierst, um die Speicherbelegung und den Umgang damit zu eruieren. Das ist zwar auch nicht unbedingt einfach, zumal anfangs. Aber so erfährst du ebenfalls, ob das überhaupt sinnvoll möglich ist. Und wenn ja wo und wie. Da dieser Compiler hier im Forum nicht sonderlich verbreitet ist, und von denen die ihn kennen (überhaupt jemand?) niemand dieses Problem anging, hat niemand eine Lösung für dich parat. Kann dir nicht sagen, wie der das macht. Ich habe solche Startups analysiert, geschrieben und auch Entwicklungssysteme gebaut. Aber zu wissen, wie andere Compiler das machen, hilft zwar bei der Analyse, bietet aber keine Lösung für dein Problem. Wohl aber liefert es eine Ahnung von den Risiken, die du eingehst, wenn du mit einer Schrotflinte blind um dich schiesst.
Rufus Τ. Firefly schrieb: > Oli Holli schrieb: >> anstatt mich dafür an den Pranger zu stellen. > > Wen meinst Du jetzt? Mich etwa? Ich habe Dir nur zwei wertneutrale > Fragen gestellt. > >> Dafür das man in einem Forum Fragen stellt muss sich keiner beleidigen >> lassen. > > Nein, mich kannst Du wirklich nicht gemeint haben. Keine Sorge das galt vorwiegend dem Reinhard Kern. Wer mich nicht beleidigt muss auch nicht zu Vera am Mittag, der darf im Forum bleiben (auch wenn schon der Moderator ist;-) ).
PS: Der Tonfall hat etwas mit dem Eindruck zu tun, dass du ein Nein als Antwort nicht zu akzeptieren scheinst. Obwohl du diesem Forum eine gewisse Kompetenz zusprichst.
> Memset() funktioniert sehr gut, auch wenn ich jedes Array einzeln > initialisieren muss ist es eine vertretbare Lösung. > > Danke soweit schonmal. 1. Hast du mir schon eine Lösung angeboten (Wer sagt nein?) und 2. Hab ich mich schon dafür bedankt (Lösung akzeptiert)! 3. Wenn ich eins in 8 Jahren Assembler und C programmierung gelernt habe, dann das es für die meisten Probleme mindestens eine Lösung gibt. Es kommt vor allen dingen darauf an mit wem oder was man nach der Lösung sucht.
A. K. schrieb: > das kannst du selber herausfinden. Indem du ein > Programm disassembliert oder den Quellcode von Startup und Library > findest und ab Reset Befehl für Befehl durchgehst, um herauszufinden, > was dort getan wird. Und das dann mit Linker-Mapfile und -Symboltabelle > korrelierst, um die Speicherbelegung und den Umgang damit zu eruieren. Für den mips-elf-gcc wären das # Startup http://pinguino32.googlecode.com/svn/branches/x.4/p32/obj/non-free/crt0.S # Linker script http://pinguino32.googlecode.com/svn/branches/x.4/p32/lkr/elf32pic32mx.x Oli Holli schrieb: > - Er bietet diverse Optionen zur Code Optimierung Das wäre m. E. das einzige wirklich interessante, da der freie mips-elf-gcc im Vergleich zu den anderen, vom GCC bedienten Plattformen relativ große Kompilate erzeugt.
Ich denke, dass ihm mit dem Zeugs für seinen Compiler mehr gedient wäre, als mit dem für mips-elf-gcc. Denn das was darin passiert hängt weniger von der Zielmaschine ab, als vom Speicherlayout des Entwicklungssystems und evtl. von Aspekten der Library. Insofern nützt ihm das nicht einmal dann allzu viel, wenn dahinter tatsächlich der gcc stecken sollte.
Oli Holli schrieb: > Keine Sorge das galt vorwiegend dem Reinhard Kern. Da dich meine sachlichen Angaben ja nicht im mindesten interessieren, kannst du auch den Ton einfach ignorieren. Wundern solltest du dich aber nicht, denn es nervt dann doch allmählich, wenn dir rund 20mal etwa das Gleiche gesagt wurde und du die Einwände einfach nicht zur Kenntnis nimmst, wie ein quengeliges Kind. Ansonsten ist zum Thema selbst längst alles gesagt. Aber natürlich steht es dir frei, deine Frage noch ein paarmal zu wiederholen. Gruss Reinhard
A. K. schrieb: > Denn das was darin passiert hängt weniger > von der Zielmaschine ab, als vom Speicherlayout des Entwicklungssystems > und evtl. von Aspekten der Library. Das Speicherlayout des Entwicklungssystems/Library und das von der Zielmaschine können so verschieden sein? Mein Horizont beschränkt sich in der Tat auf GNU ld. Wenn also der Aufbau des Linker-Skripts nicht dem daher bekannten Schema folgt, dann bringt das nichts. Dennoch kann er sich davon überzeugen, dass Speicherlayout der CPU, Startup und Linker-Skript im Falle von MIPS32 nicht die einfachsten Fälle sind.
Roland H. schrieb: > Das Speicherlayout des Entwicklungssystems/Library und das von der > Zielmaschine können so verschieden sein? Natürlich. Stell dir einfach mal vor, ein Compiler/Linker würde statics nicht in ein geschlossenes BSS legen, sondern zusammen mit den explizit initialisierten Daten allozieren. Und bei expliziter Initialisierung Code dafür erzeugen. Ob das wirklich sinnvoll wäre ist hier nicht der Punkt, aber dieser Schweizer Käse aus initialisierten und nicht initialisierten Daten wäre dermassen abweichend von der gängigen Praxis, dass sie dir nicht viel weiterhilft. In main() löschen, wie es bei einem BSS evtl. möglich wäre, wäre in diesem Modell unmöglich. Es ist auch nicht selbstverständlich, dass man bei einem gegebenen proprietären Entwicklungssystem überhaupt den Startup-Code mit sinnvollem Aufwand ersetzen kann. > Mein Horizont beschränkt sich in der Tat auf GNU ld. > Wenn also der Aufbau des Linker-Skripts nicht dem daher bekannten Schema > folgt, dann bringt das nichts. Verwendet das Entwicklungssystem, um das es hier geht, überhaupt GCC/LD? Es liegt zwar nahe, das Rad nicht neu zu erfinden, aber selbstverständlich ist das nicht. Und wenn das nicht der Fall ist, dann gibt es möglicherweise auch kein Linker-Script. Und keine Symbole, die die Grenzen der Sektionen signalisieren.
A. K. schrieb: > Wie man sich bettet, so liegt man: "In the mikroC PRO for PIC32, static > duration objects are not initialized to zero (or null) in the absence of > any explicit initializer." Das macht im embeded Bereich Sinn da nach einem Reset die static values erhalten bleiben. > > Wenn man sich freiwillig einem Compiler unterwirft, der den C Standard > geflissentlich ignoriert, dann sollte man sich auch auf andere > Überraschungen gefasst machen. Die Dinger von Mikroe sind dem gekrampfe von Microchip um längen voraus. In Sachen usability, speed, fedatures etc. pp. und "Überraschungen" halt jede Suite zur genüge bereit. > > Ob die Initialisierung des ersten Elementes auch die anderen > initialisiert, das könnten dir deshalb nur intime Kennner dieses > speziellen Compilers verraten. Mit normalem C hat das ja nicht mehr viel > zu tun. Die Abweichungen zum Standard sind Dokumentiert und fast immer sinnvoll. Man kann davon ausgehen das die Anweisungen C konform sind. > > Ähnlich ist das mit deiner Idee, das RAM zu nullen. Wann das in welcher > Weise möglich ist, und ob überhaupt, das weiss auch nur ein intimer > Kenner dieses Compilers. Ein Nullaussage die man auch auf die Eigenschaften von Walfischtran anwenden kann ;-) Das nullen macht aber prinzipiell keinen Sinn da der physikalische Speicherplatz lokaler (nonstatic) Variablen außerhalb ihres Kontextes ja wiederverwendbar und somit ohne Initialisierung unbestimmt ist.
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.