Hallöchen! Ich wollte mal fragen, ob mir jemand erklären kann, wie die Speicheraufteilung (ich besitze den AN2131) in data, pdata, xdata und code aussieht. Oder gibts dafür ein Datenblatt (im TRM des AN2131 hab ich nichts gefunden)? Viele Grüße, Stefan
hmm... vielleicht kann mir ja jemand diese Frage beantworten: Warum funktioniert das Programm im Anhang, wenn die Eingaben bei "Options for Target" im Tab "BL51 locate" so wie vorhanden stehen und wenn ich diese Angaben rausnehme, tut sich nix mehr (sinnvolles)? Grüße
42... Was ist ein AN2131? Du musst schon mehr Infos(z.B.Datenblatt) zur Verfügung stellen, damit dir jemand hilft... Ich konnte bis jetzt nur rauslesen, dass es sich um einen 8051 handelt und du mit dem Keil C51-Compiler arbeitest... Ralf
Stefan S. schrieb: > Hallöchen! > > Ich wollte mal fragen, ob mir jemand erklären kann, wie die > Speicheraufteilung (ich besitze den AN2131) in data, pdata, xdata und > code aussieht. Oder gibts dafür ein Datenblatt (im TRM des AN2131 hab > ich nichts gefunden)? > > Viele Grüße, > Stefan Na ja, wenn ich davon ausgehe, daß es ein 8051 Derivat ist, dann ist "data" das interne RAM des Controllers, "code" ist der Programmspeicher (intern oder extern) und "xdata" ist das externe RAM. Es hängt natürlich von Deinem Controller ab, was er an internen RAM hat, vom Controller und Beschaltung, was er an code hat und von der Beschaltung ob und wieveile (und wo) er xdata hat. Und das muss man dem Linker mitteilen, offensichtlich im "BL51 locate" tab. Sorry, daß ich nicht genauer darauf eingehen kann, aber zum einen fehlen Informationen von Dir, zum anderen ist mein 8051 und Keil-C Wissen ca. 15 Jahre alt... Gruß, Bernhard
Was den Adressbereich und die Größe der Speichersegmente angeht, sollte die Angabe des richtigen Derivats in Keil bereits alles automatisch erledigen... Ralf
Also ich nutze den AN2131 von Cypress und µVision3. Das Datenblatt des AN2131 findet ihr im Anhang und ja, es ist ein Chip, der auf dem 8051 basiert. > Was den Adressbereich und die Größe der Speichersegmente angeht, sollte > die Angabe des richtigen Derivats in Keil bereits alles automatisch > erledigen... Das dachte ich auch, aber das Programm funktioniert leider nicht mehr, wenn ich die Angaben, die im Tab "BL51 locate" des Dialogs "Options for Target" enthalten sind, lösche... Grüße
Ich kenne deine Anordnung so nicht, habe aber Erfahrung mit dem Keil-Compiler und mit Cypress-Chips ansich. Allerdings nicht mit deinem. Klingt auch eher nach abgekündigt?? Zumindest die Typennummer wäre im Tech-Jargon eine für eine Applicatio Note. Warum löschst du die offensichtlich notwendigen Parameter? Sieht nach Linker-Steuerung aus, damit der weiß wo er was hinlegen darf. Damit du die Unterschiede der Speicherbereiche verstehst, mußt du dir Grundlagen zum 8051 reinziehen. Von welchen Chips dein AN2131 stammt, steht ja im Datenblatt. Also dort weiter einlesen. Zum 8051 gibt es endlos viele Referenzen im Web. PDATA ist übrigens der interne RAM, der per Page-Befehle adressierbar ist. Ein anderer Weg wäre über den guten Cypress-Support oder auch über Keil. Mannoman, diese alte 8051-Mühle will einfach nicht aussterben. Ganz im Gegenteil. Es kommen immerwieder neue Varianten raus. Die überlebt mich glatt.
> Warum löschst du die offensichtlich notwendigen Parameter? Sieht nach > Linker-Steuerung aus, damit der weiß wo er was hinlegen darf. Ich will verstehen, was die Angaben dort genau machen, denn da mein Programm größer geworden ist (im Vergleich zum Basisprogramm) und ich unter anderem mit dem memory-model, das vorher eingestellt war, nicht mehr auskomme, wollte ich das entsprechend abändern ;-) nur wenn man keine Ahnung hat, was das bedeutet, man was abändert und dann nur merkt, dass es gar nicht mehr funktioniert, ist es schlecht... > Damit du die Unterschiede der Speicherbereiche verstehst, mußt du dir > Grundlagen zum 8051 reinziehen. Von welchen Chips dein AN2131 stammt, > steht ja im Datenblatt. Also dort weiter einlesen. Zum 8051 gibt es > endlos viele Referenzen im Web. Okay, hab ich gemacht (data, code und xdata). Da steht aber nix von pdata... Was ich gelesen habe: Es gibt einen Bereich, der "data" heißt, der ist im internen RAM (= direkt adressierbar), dann gibt es noch "code" und "xdata", die jeweils im externen RAM liegen (indirekt adressierbar). Alle Bereiche sind voneinander getrennt (haben aber parallele Adressen). Man kann also sagen, es gibt 3 verschiedene Speicherbereiche (hab ich so verstanden). > PDATA ist übrigens der interne RAM, der per Page-Befehle adressierbar > ist. pdata ist doch "eine page" des xdata-Bereiches, oder?? Grüße
Aaaalso... CODE = Programmspeicher von 0x0000 - 0xnnnn (nnnn = max.Speicher), wird durch DPTR indirekt adressiert, einige Derivate bieten die Möglichkeit, bis zu 24 Bit (= 16 Mbyte) zu adressieren (üblich sind 16 Bit = 64kByte), kann aber durch geschicktes Programmieren auch in Software gelöst werden DATA = direkt adressierbares internes RAM von 0x00 bis 0x7F (128 Bytes, entspricht dem indirekt adressierbaren RAM, inkl. 4 Bänke á 8 Registern und 16 bitadressierbaren Bytes) und SFRs von 0x80 bis 0xFF (ohne Rest durch 8 teilbare SFR-Adressen sind bitadressierbar) IDATA = indirekt durch R0/R1 adressierbares internes RAM von 0x00 bis 0x7F (128 Bytes, entspricht dem direkt adressierbaren RAM) und von 0x80 bis 0xFF (entspricht nicht den SFRs, sondern ist ein eigenständiger RAM-Bereich und nur durch indirekte Adressierung ansprechbar) -> Aus Sicht des 805x liegt der Stack im internen indirekt adressierbaren RAM) PDATA = ein 256-Byte großer indirekt adressierter Block im externen RAM (on-chip oder off-chip), wird durch R0/R1 adressiert, die Seite wird normalerweise durch P2 ausgewählt, einige Derivate haben eigene SFRs dafür -> wird P2 (= das High-Byte der Adresse) nicht geändert, so gilt die aktuelle Code-Seite XDATA = Datenspeicher von 0x0000 - 0xnnnn (nnnn = max.Speicher), wird durch DPTR oder R0/R1 (= PDATA) immer indirekt adressiert, Programmcode kann bei externem Codespeicher-Interface (RD, WR, ALE, PSEN) im externen Speicher abgelegt werden. Einige Derivate bieten die Möglichkeit, bis zu 24 Bit (= 16 MByte) zu adressieren (üblich sind 16 Bit = 64kByte).Im XDATA-Bereich werden auch ICs mit parallelem Interface integriert (z.B. FT245) So, ich hoffe, ich hab nix vergessen/falsch geschrieben :) Und jetzt kannste ja noch n Screenshot von deinem Linker/Locator-Dialog posten, und Fragen dazu stellen, so denn noch welche offen sind :) Ralf
> Im XDATA-Bereich werden auch ICs mit parallelem Interface integriert (z.B. > FT245) Sorry, der FT245 ist ein schlechtes Beispiel, der hat keinen ChipSelect :( Hab nicht nachgedacht... Ja, dann halt irgendein Display (T6963C/HD44780) etc. :) Ralf
Angehängte Dateien:
-
Clipboard01.jpg
120 KB -
Clipboard02.jpg
140 KB
Danke erstmal für deine reichliche Erklärung der Speicherarchitektur :D (wobei ich noch nicht so weit bin, dass ich mit "ICs mit parallelem Interface" integriere ;-)) An sich habe ich (denke ich mal) den Speicheraufbau verstanden, aber wie man ihn bei µVision einstellen soll, das ist mir noch ein Rätsel... (anscheinend MUSS man es ja einstellen, denn sonst würde mein Programm ja auch funktionieren, wenn ich die entsprechenden Felder leer lasse...) Hier zwei Screenshots von dem "Options for Target"-Dialog (ein mal die Registerkarte "Target" und ein mal die Registerkarte "BL51 locate"). Wäre toll, wenn du mir erklären kannst, wozu die einzelnen Angaben sind ;-) Viele Grüße, Stefan
Jetzt wo ich das Bild sehe, wird mir klarer, warum's nicht geht... Der Haken "use memory layout from target" setzt die Werte automatisch anhand deines gewählten Derivates. Machst du den Haken raus, kannst du die Speicheradressen selber bestimmen. Wenn du dann allerdings die Felder leer lässt, gibt's natürlich Murks. Das ist so wie wenn du zum Postboten sagst: "Liefer das Paket ab" "Lieferadresse" "Weiss nicht, aber liefers ab" Da ist halt nix :) Die meisten Sachen sind in der µV3/C51-Hilfedatei bzw. auf der Homepage beschrieben. Wir machen einen Deal, ich versorg dich mit ein paar Links, und wenn dann noch Fragen sind, klären wir die, okay? Sonst schreib ich mir die Finger wund :) Bei den Links immer den Listen-Baum nebendran beachten, da kannst du in den Unterkategorien jeweils detailliertere Infos abgraben: http://www.keil.com/support/man/docs/c51/c51_le_memareas.htm http://www.keil.com/support/man/docs/c51/c51_le_memmodels.htm http://www.keil.com/support/man/docs/c51/c51_le_memtypes.htm http://www.keil.com/support/man/docs/c51/c51_le_sfrs.htm http://www.keil.com/support/man/docs/c51/c51_le_bitaddrobj.htm Für die Screenshots noch ne (kurze) Beschreibung: Target-Dialog: use on-chip XRAM: Wird für die Konfiguration der Datei STARTUP.A51 verwendet und aktiviert das Löschen des externen RAMs. Die Größe des RAMs ist im Fall von on-chip XRAM vorgegeben, im Fall von extern angeschlossenem XRAM muss die Größe und die Anfangsadresse entsprechend eingetragen werden. Die Adressen von on- und off-chip XRAM können sich überlagern, dazu muss aber dann FAR MEMORY TYPE SUPPORT aktiviert werden und spezielle Assembler-Funktionen in der zusätzlich zu verwendenden XBANKING.A51 geschrieben/modifiziert werden -> hab ich z.B. gemacht, um das interne EEPROM eines AT89C51ED2 wie ganz normale Variablen ansprechen zu können. Die Assembler-Funktionen regeln dann das Mappen des EEPROMs in den XDATA-Bereich und die Abfrage, ob das EEPROM bereit ist etc. Extern angeschlossener Programmspeicher kann ebenfalls angegeben werden. Code-Banking ist ein Weg, um den Programmspeicher zu vergrößern. Hier kann mehr als 64kB Programmspeicher verwendet werden. Die Adressierung verläuft ähnlich wie bei PDATA seitenweise, wobei dann ebenfalls spezielle Assembler-Funktionen geschrieben werden müssen, um die Umschaltung zwischen den Seiten zu realisieren. Ausserdem muss die Programmstruktur entsprechend angepasst werden. Use multiple DPTR registers: Hat ein Derivat mehrere Datenpointerregister, so können diese miteinander verwendet werden, ansonsten wird nur der Standard-DPTR verwendet. Hat z.B. Geschwindigkeitsvorteile bei blockweisen Kopiervorgängen ins XRAM (Datenpointer müssen nicht ständig modifiziert werden, sondern jeweils nur inkrementiert). Der BL51/Locate-Dialog erklärt sich fast von selbst, hier legst du fest, welcher Speichertyp welchen Adressbereich hat. PDATA ist ohne Code-Modifikationen übrigens immer fix auf die angegebene Seite festgelegt! Über die Segmente kannst du z.B. festlegen, an welcher Adresse sich Funktionen befinden sollen (kann manchmal nötig sein), indem du definierst, dass eine Funktion in einem Segment liegen soll. Z.B. basiert meine oben erwähnte EEPROM-Ansteuerung auf einem solchen Segment, allerdings wird dort mit 24 Bit Adressen gearbeitet, und das High-Byte definiert, ob es EEPROM-Zugriff ist -> du siehst, man kann viele Sachen machen :) So, jetzt glühen meine Finger doch, aber wenn Fragen da sind, einfach her damit ;) Ralf
Hey, danke für die superlange Antwort!! Also das erste, was ich aus deinen Erklärungen entnommen habe: An für sich brauche ich von den vielen möglichen Optionen (mit erweiteerbarem RAM, etc.) im Moment nichts :P Um so mehr verwundert es mich, dass das Programm nicht funktioniert... Ich habe nun mal ausprobiert, was passiert, wenn ich das Häkchen bei "use memory layout from target" setze: Das Programm funktioniert wieder nicht... (egal, ob ich dann im Feld "xdata" den Eintrrag stehen lasse oder ebenfalls lösche...) Eigentlich ist meine Hardware ganz einfach: An meinem AN2131 habe ich weder zusätzliches RAM, noch irgendwas in der Art (nur ein EEPROM, mit dem ich in dem Programm aber nichts anfangen will) Grüße, Stefan
Angehängte Dateien:
-
Clipboard03.jpg
140 KB -
Clipboard04.jpg
120 KB
Ergänzung: Ich habe nun mal folgende Einstellungen vorgenommen (siehe Screenshots), funktioniert aber trotzdem nicht...
OK, das mit PDATA scheint durch Ralf geklärt. Das hatte ich wohl in falscher Erinnerung. Ist aber auch schon mindestens 15 Jahre bei mir her. Damals lief Keil noch auf DOS. Übrigens konnte der Keil-Compiler schon damals ein Banking-Schema über 64K im Compiler selbst unterstützen. Gab sogar verschiedene Varianten zum Auswählen. Das war damals der letzte Schrei und ich hatte es auch sogleich in meine erste Hardware-Entwicklung als Student integriert lol Und nun brüht Cypress nur wegen Lizenzen in den neuesten Controllern wieder u.a. 8051 auf. Als wäre der besser als der M8C :-()
Stefan S. schrieb: > Hey, danke für die superlange Antwort!! Also das erste, was ich aus > deinen Erklärungen entnommen habe: An für sich brauche ich von den > vielen möglichen Optionen (mit erweiterbarem RAM, etc.) im Moment > nichts :P Ich hoffe, du denkst jetzt nicht, dass ich deinen Beitrag nicht gelesen hätte ;-)soweit hab ich es jetzt verstanden und festgestellt, dass mich die verschiedenen Optionen (!!theoretisch!!) nicht betreffen dürften, schließlich nutze ich ja keinen externen RAM-Baustein oder Ähnliches... Aber warum funktioniert das Programm niciht, wenn ich die Einstellungen komplett dem Compiler überlasse?!?! Viele Grüße, Stefan
> Ich habe nun mal folgende Einstellungen vorgenommen (siehe Screenshots), > funktioniert aber trotzdem nicht... Und welcher Unterschied besteht zu der funktionierenden Variante? Hast du nur eine Datei neu gelinkt oder das ganze Projekt? Ralf
Vom Quelltext her besteht kein Unterschied, nur von den Compilereinstellungen (siehe Secreenshots)... Die Angaben bei "code" kann ich sogar rausnehmen (egal ob "use memory layout from target" aktiviert ist oder nicht) und es funktioniert. Wenn ich aber das 0x800 bei "xdata" wegnehme, so funktioniert das Programm nicht mehr...
> Wenn ich aber das 0x800 bei "xdata" wegnehme, so funktioniert das Programm > nicht mehr... Na, dann wird doch schon mal vieles klarer... Die erste Frage wäre, sind irgendwelche Variablen als XDATA oder PDATA deklariert? Zweite Frage, verwendest du in der aktuellen Software bereits USB? Die Endpunkt-Buffer sind im externen RAM! Dritte Frage, welche C51 Version? Und Voll- oder Demoversion? 0x800 passt zu der Demobeschränkung von 2kB und die Demo generiert einen 2kB Offset auf das Programm, und bei einem AN2131 liegt das Programm ebenfalls im XRAM! -> Das bedeutet: Dein Programm + Daten darf nicht größer als 2kB sein! Die Angabe "0x800" allein reicht eigentlich nicht aus, wenn ich's richtig im Sinn habe, muss da ein Segment-_Name_ hin, und dahinter in Klammern der Adressbereich... "Clipboard04.jpg" zeigt, dass du das interne RAM verwendest, also sollte eigentlich keine weitere Aktion notwendig sein... Weiter oben hattest du geschrieben, dass du das Memory-Modell ändern musst, weil du mit dem "alten" (welches? SMALL ? ) nicht mehr weitergekommen bist. Lief das Programm bereits nach dem Umstellen nicht mehr? Was genau lief nicht mehr? Nur ein Teil des Programms? Kannst du das eingrenzen? Ralf
PS: Bitte zippe einmal das funktionierende und das nichtfunktionierende Programm, und hängs hier rein, vielleicht finde ich raus, woran es liegen könnte... Ralf
Also, im Anhang findest du: 1. das funktionierende Programm 2. 2 Varianten, wie es z.B. nicht funktioniert 3. das Programm, auf dem ich meines aufgebaut habe und von dem ich damit auch die Einstellungen anfangs übernommen habe (kannst ja dort nachschauen) Anfangs hatte ich nur die Demoversion von µVision2, jetzt die Vollversion von µVision3. Dass das Programm nicht funktioniert, merke ich z.B. daran, dass die Variablen var0...var7, die ich vom PC aus überwache (deswegen sind sie auch mit at an festgelegte Speicherzellen gebunden). Zur Zeit reicht aber schon ein simples "auf die Platine schauen", denn wenn das Programm funktioniert, blinkt die LED, die an Port A4 angeschlossen ist (siehe in der ISR in Main.c)... und das tut sie zur Zeit (bei den nicht funktionierenden Versionen nicht... sie leuchtet ständig oder leuchtet gar nicht) Viele Grüße, Stefan PS: Vielen Dank schonmal, dass du mir so engagiert hilfst :D
Moment, moment, jetzt blick ich's gar nicht mehr... Du schreibst, wenn du die Angabe für XDATA rausnimmst, dann tut's nicht, aber in allen Projekten ist die Angabe vorhanden, dafür ist bei den nicht funktionierenden Programmen die Angabe "Coderange" nicht vorhanden... ??? Wat denn nu? ;) Ist vielleicht auch schon zu spät für mich, schauen wir mal, was morgen rauskommt, okay? Ralf
Angehängte Dateien:
-
funktionierend0.jpg
120 KB -
funktionierend1.jpg
120 KB -
funktionierend2.jpg
120 KB -
nicht_funktionierend1.jpg
130 KB -
nicht_funktionierend2.jpg
120 KB
Okay, ich glaube ich bin selbst ein bisschen verwirrt... Nach einigem ausprobieren ist mir z.B. passiert, dass -wenn ich für XDATA-range 0xFFFF [also 4 F's] eingesetzt habe- µVision nicht mehr reagiert (okay, war wahrscheinlich eine zu große angabe ;-)) Außerdem habe ich noch ein wenig herumexperimentiert: Für Code-range und für XDATA kann ich verschiedene Bereiche wählen und das Programm funktioniert in manchen Fällen, in manchen Fällen aber auch nicht (siehe Screenshots)... Ich habe das so verstanden, dass man mit diesen Angaben dem Compiler sagen kann, wohin er CODE-Daten und wohin er XDATA-Daten legen darf. Eigentlich müsste es doch egal sein, ob ein Array oder eine Variable jetzt an Speicherstelle 0x0000 oder an Speicherstelle 0x0300 abgelegt wird, oder? Warum funktioniert dann die Speicherbereichzuweisung nicht bei allen Screenshots? Es mag eine dumme Frage sein, aber sie ist ernst gemeint: Wie viel XDATA- und wie viel CODE-Speicher hat der AN2131S überhaupt? Im Tab "Device" des "options for Target"-Dialog steht für den "AN21XX" etwas von "4K or 8K Bytes XRAM" Was für ein Speicher ist das genau? Ist das der externe RAM? Und ist der aufgeteilt in CODE und XDATA? Wenn ich die Speichergrößen wüsste, wäre es natürlich auch eine Idee, einfach bei CODE-Range und bei XDATA-Range die maximale Größe einzutragen... So, jetzt bin ich totmüde... gute Nacht! Viele Grüße, Stefan
Moin Stefan, > Ich habe das so verstanden, dass man mit diesen Angaben dem Compiler > sagen kann, wohin er CODE-Daten und wohin er XDATA-Daten legen darf. Korrekt. > Eigentlich müsste es doch egal sein, ob ein Array oder eine Variable > jetzt an Speicherstelle 0x0000 oder an Speicherstelle 0x0300 abgelegt > wird, oder? Warum funktioniert dann die Speicherbereichzuweisung nicht > bei allen Screenshots? Ja, normalerweise schon, aber vergiss nicht, dass der AN2131 den Programmcode ebenfalls im XRAM hat! > ... und das Programm funktioniert in manchen Fällen, in manchen Fällen > aber auch nicht (siehe Screenshots)... Das verwirrt mich, dass das Programm dem Dateinamen nach bei - funktionierend0.jpg und - funktionierend2.jpg tatsächlich läuft, denn die Bereiche sind identisch, somit überschneiden sich ja CODE und XDATA, was im AN2131 für Verwirrung sorgen dürfte... - nicht_funktionierend2.jpg sollte eigentlich laufen, vorausgesetzt, der Code passt in den Bereich von 0x0080-0x0190... Ralf
Hi Ralf! > Ja, normalerweise schon, aber vergiss nicht, dass der AN2131 den > Programmcode ebenfalls im XRAM hat! Ich glaube an dieser Stelle ist meine Frage aus dem vorigen Post angebracht: Der AN2131 verfügt über einen XRAM-Speicher, gut, und dieser Speicher wird in CODE und XDATA aufgeteilt? Also befinden sich alle DATA-Variablen ich sage mal "galvanisch getrennt" in einem komplett anderen Speicher (internem RAM); die CODE- und XDATA-Variablen dagegen befinden sich im gleichen Speicher (externem RAM), sollten von der Sofware aber auch als getrennte Bereiche angesehen werden? > Das verwirrt mich... Um zu beurteilen, ob das Programm funktioniert, habe ich bisher leider nur 2 Anhaltspunkte gehabt: 1. die LED an Port A4 blinkt wie durch die Interruptroutine vorgesehen und 2. die Variablen var0...var7 beinhalten die Werte, die ich erwarte Sobald eines dieser Kriterien nicht erfüllt war, habe ich das Programm als "nicht funktionierend" angesehen... Da gibts doch bestimmt noch professionellere Möglichkeiten, das zu beurteilen, oder? Nach meinem Erachten könnte es bei meiner Methode ja auch passieren, dass ein überschneidender Speicherbereich zufällig nicht genutzt wird und das Programm "läuft", obwohl es in Zukunft crashen kann... Viele Grüße, Stefan
> ...und dieser Speicher wird in CODE und XDATA aufgeteilt? Also befinden > sich alle DATA-Variablen ich sage mal "galvanisch getrennt" in einem > komplett anderen Speicher (internem RAM) Ja, so würde ich das sehen, allerdings ist mir dann rätselhaft, warum hier: http://www.cypress.com/?rID=26737 steht, dass der Code bei 0x0080 beginnen sollte... > die CODE- und XDATA-Variablen dagegen befinden sich im gleichen Speicher > (externem RAM), sollten von der Sofware aber auch als getrennte Bereiche > angesehen werden? Genau, aber für die Trennung muss offenbar der User sorgen... Was kam bei deinen Anfragen im Keil-Forum raus? Ralf
Hey Ralf, leider kam bei der Frage im Keil-Forum noch nix größeres raus... ich habe eben auch mal einen Post im Cypress-Forum gemacht, vielleicht können die ja etwas dazu sagen ;-) Hier die Links zu den Themen diesbezüglich: http://www.keil.com/forum/docs/thread15763.asp#msg79915 http://www.cypress.com/forums/forum/messageview.cfm?catid=7&threadid=5906&enterthread=y > ...dass der Code bei 0x0080 beginnen sollte... hat das vielleicht irgendwas mit vorbelegten Adressen zu tun? Stefan
Stefan S. schrieb: > Hey Ralf, > > leider kam bei der Frage im Keil-Forum noch nix größeres raus... ich > habe eben auch mal einen Post im Cypress-Forum gemacht, vielleicht > können die ja etwas dazu sagen ;-) > Hier die Links zu den Themen diesbezüglich: > > http://www.keil.com/forum/docs/thread15763.asp#msg79915 > http://www.cypress.com/forums/forum/messageview.cfm?catid=7&threadid=5906&enterthread=y Forum? Ich würde einen Support-Case aufmachen. Dann antwortet eigentlich immer einer innerhalb weniger Tage. Ist der Case einfach, wird er in Indien beantwortet, ansonsten landet er Tage später in Californien bei den Experten. > >> ...dass der Code bei 0x0080 beginnen sollte... > hat das vielleicht irgendwas mit vorbelegten Adressen zu tun? > Ich hab das nicht mehr im Kopf. Aber unten sind die Interrupt-Vektoren. Dein Programm und die Daten sowie der Stack müssen drüber liegen. Womit wir bei der nächsten Frage wären: Hat der Chip intern XDATA-RAM? Das gibt es bei vielen Derivaten. Strukturmäßig ist das externer Speicher, der aber intern vorhanden ist! Zumindest bei den Siemens-Typen war es so, daß der interne XDATA-Bereich den möglichen externen überdeckt hat. Wo also eine Adresse auf intern paßt, wird auch intern angesprochen und extern nicht benutzt. Alle anderen gehen in den off-Chip Bereich raus. Und dann mußt du noch klären, ob der XDATA-Bereich als Von-Neumann designt ist. Wenn ja, dürfen sich dort CODE und Daten adressmäßig nicht überschneiden.
Okay, hab mal eine Email an den Support geschrieben... mal sehen, was da zurückkommt ;-) Ich glaube schon, dass deer AN2131 "internen XRAM" hat (soweit ich das verstanden habe 4k oder 8k)... Ob der auf der VN-Architektur aufbaut, habe ich keine Ahnung... ich habe mal den entsprechenden Teil aus der TRM angehängt. So ganz verstanden, was der AN2131S genau hat, habe ich noch nicht...
In dem Fall ist das von Neumann, wenn der EA-Pin 0 ist, was auf deinem Board denke ich der Fall ist... Deswegen hatte ich ja oben geschrieben, dass es mich verwirrt hat, welche Einstellungen gehen und welche nicht, weil die funktionierenden Programme dann hätten crashen müssen... Ralf
Ralf schrieb: > In dem Fall ist das von Neumann, wenn der EA-Pin 0 ist, was auf deinem > Board denke ich der Fall ist... Da stehe ich ebenfalls vor einem Rätsel: Der AN2131 S hat keinen EA-Pin...
> Da stehe ich ebenfalls vor einem Rätsel: Der AN2131 S hat keinen > EA-Pin... Dann diktiert die Logic, dass er den internen Speicher verwendet, denn ich glaube nicht, dass ein externes EEPROM/RAM angeschlossen ist... Ralf
Hm. Momentan ist kein zusätzliches EEPROM oder RAM angeschlossen, das stimmt. Wenn der interne Speicher verwendet wird, betrifft mich dann im Datenblatt eigentlich die Figur 3-1 oder 3-2? Daraus kann man doch dann ablesen, wie viel Speicher (RAM) mir für XDATA+CODE zur verfügung stehen, oder? Wenn ich das richtig verstehe, habe ich entweder 0x1B3F oder 0x0FFF freien Speicher? Grüße
>Wenn ich das richtig verstehe, habe ich entweder 0x1B3F >oder 0x0FFF freien Speicher? Hast du eigentlich einen blassen Schimmer welche CPU du hast? Das solltest du als erstes mal feststellen. Die 4K Version geht bis 0x0FFF die 8k Version bis 0x1B3F. Da liegst du schon mal richtig. Code und XDATA Bereich dürfen sich nicht überschneiden! Und zerstückele die Bereiche nicht. Für die 4k Version probier doch einfach Code 0x0080-0x07FF 2kB für das Programm Xdata 0x0800-0x0FFF 2kB Xdata RAM Für die 8k Version dann halt entsprechend.
Okay, ich weiß nun, wie viel RAM der AN2131S hat... hätte einfach besser im TRM nachschauen müssen... es sind 8kB. 1. Also sollte ich am besten den RAM wie folgt aufteilen? 0x80-0x0D5F für CODE 0x0D60-0x1B3F für XDATA 2. Habe ich das eigentlich an der richtigen Stelle eingetragen (siehe Screensshot)? Wenn ich es bisher richtig verstanden habe, müssten sich die Felder darunter auf die Aufteilung der verschiedenen Speicherbereiche in verschiedene Segmente (z.B. Funktionen) aufteilen.
Sieht ja soweit nicht schlecht aus, was steht unten im Linker-Control-String? Hast du probiert, ob's damit geht? Ralf
Na logo hab ichs ausprobiert! Es scheint zu funktionieren :D Im Anhang findest du die .m51-Datei Eine letzte Frage habe ich aber noch: Ich habe einige Variablen ja mit absoluten Adressen als xdata deklariert. Und diese Adressen liegen im jetzt als code-Speicher angegebenen RAM. Wieso gibt der Linker oder der Compiler keine Warung raus, dass ich xdata-variablen im Code-Bereich ablege?
> Eine letzte Frage habe ich aber noch: grins Wenn's nicht die letzte Frage ist, bekomm ich n Kasten Bier :) > Ich habe einige Variablen ja mit absoluten Adressen als xdata deklariert. > Und diese Adressen liegen im jetzt als code-Speicher angegebenen RAM. > Wieso gibt der Linker oder der Compiler keine Warung raus, dass ich xdata- > variablen im Code-Bereich ablege? Wahrscheinlich(!) deswegen, weil in die absolute Adresse vermuten lässt, dass du weisst, was du tust, und das deswegen okay für ihn ist. Hast du die Adresse mit dem at-Schlüsselwort definiert oder über einen Pointer? Ralf
Ralf schrieb: >> Eine letzte Frage habe ich aber noch: > grins Wenn's nicht die letzte Frage ist, bekomm ich n Kasten Bier :) Mist, ich glaube, ich kann schonmal einkaufen gehen :P > Hast dudie Adresse mit dem at-Schlüsselwort definiert oder über einen > Pointer? Mit at. Müsste er nicht denken, dass das code-Speicher ist und man das, was im Codespeicher drin ist (also z.B. Variablenwerte), nicht verändern kann (das ist doch der Unterschied zwischen CODE und XDATA)? Oder hab ich da nur was missverstanden und der Compiler weiß, dass das XRAM des AN2131 sowohl für XDATA, als auch für CODE zu gebrauchen ist? Ich hatte nämlich noch folgendes im Hinterkopf: TRM des AN2131 schrieb: > The 8051 partitions its memory spaces into code memory and data memory. > The 8051 reads code memory using the signal PSEN# (Program Store > Enable), reads data memory using the signal RD# (Data Read) and writes > data memory using the signal WR# (Data Write). The 8051 MOVX (move > external) instruction generates RD# or WR# strobes. Demnach müsste ein Ändern von Werten im Code-Bereich ja unmöglich sein... Viele Grüße, Stefan
Damals zu DOS-Zeiten hat der Keil-Compiler ausführliche Warnings generiert. Kontrolliere mal, ob du überhaupt das richtige Speichermodell ihm mitgeteilt hast und welche Warnings er ausspuckt. Hast du dir die jemals angesehen? Wenn du z.B. Harvard definiert hast und dann VN benutzt, kann er natürlich nicht wissen, das das adressmäßige Übereinanderlegen von Objekten das Programm stören wird.
Abdul K. schrieb: > Damals zu DOS-Zeiten hat der Keil-Compiler ausführliche Warnings > generiert. Kontrolliere mal, ob du überhaupt das richtige Speichermodell > ihm mitgeteilt hast und welche Warnings er ausspuckt. Hast du dir die > jemals angesehen? ja, das habe ich. Hier die Warnings: Build target '1Wire-Temperature-Sensor' compiling essential_ROM_Commands.c... ESSENTIAL_ROM_COMMANDS.C(50): warning C173: missing return-expression ESSENTIAL_ROM_COMMANDS.C(50): warning C290: missing return value linking... *** WARNING L16: UNCALLED SEGMENT, IGNORED FOR OVERLAY PROCESS SEGMENT: ?PR?OWREADBYTE?ONEWIRE *** WARNING L16: UNCALLED SEGMENT, IGNORED FOR OVERLAY PROCESS SEGMENT: ?PR?OWFAMILYSKIPSETUP?SEARCHROM *** WARNING L16: UNCALLED SEGMENT, IGNORED FOR OVERLAY PROCESS SEGMENT: ?PR?_OWFINDFAMILY?ESSENTIAL_ROM_COMMANDS Program Size: data=52.0 xdata=1554 code=1459 creating hex file from ".\Output\1WTemp"... User command #1: .\HEX2BIN.EXE .\Output\1WTemp.hex .\Output\1WTemp.bin User command #2: .\hex2bix.exe -i -o Output\1WTemp.iic Output\1WTemp.hex Intel Hex file to EZ-USB Binary file conversion utility Copyright (c) 1997-1999, Cypress Semiconductor Inc. 1475 Bytes written. Total Code Bytes = 1459 Conversion completed successfully. ".\Output\1WTemp" - 0 Error(s), 5 Warning(s). > Wenn du z.B. Harvard definiert hast und dann VN benutzt, kann er > natürlich nicht wissen, das das adressmäßige Übereinanderlegen von > Objekten das Programm stören wird. Das kann man einstellen?! Wo geht denn das??
> Das kann man einstellen?! Wo geht denn das?? Das definierst du über die Adressen/den Bereich von XDATA und CODE. Harvard: getrennter Speicher für Befehle und Daten -> Adressen dürfen sich überlappen Von Neumann: gemeinsamer Speicher für Befehle und Daten -> Adressen dürfen sich nicht überlappen > Mit at. Müsste er nicht denken, dass das code-Speicher ist und man > das, was im Codespeicher drin ist (also z.B. Variablenwerte), nicht > verändern kann (das ist doch der Unterschied zwischen CODE und XDATA)? > Oder hab ich da nur was missverstanden und der Compiler weiß, dass das > XRAM des AN2131 sowohl für XDATA, als auch für CODE zu gebrauchen ist? > Ich hatte nämlich noch folgendes im Hinterkopf: > TRM des AN2131 schrieb: >> The 8051 partitions its memory spaces into code memory and data memory. >> The 8051 reads code memory using the signal PSEN# (Program Store >> Enable), reads data memory using the signal RD# (Data Read) and writes >> data memory using the signal WR# (Data Write). The 8051 MOVX (move >> external) instruction generates RD# or WR# strobes. > Demnach müsste ein Ändern von Werten im Code-Bereich ja unmöglich > sein... Hm... Eigentlich schon, aber da ein 8051 ja Harvard-Architektur ist, ist es erstmal prinzipiell möglich, mit einem Datenbefehl auf den Programmspeicher zuzugreifen. Im Fall deines Controllers sowieso, weil prinzipiell beide Befehle (MOVX/MOVC) auf den XRAM zugreifen. Für die Verwendung von AT steht in der Keil-Hilfe, dass es einen Fehler generieren müsste, wenn die Speicherbereiche nicht passen: http://www.keil.com/support/man/docs/c51/c51_le_absvarloc.htm Ich hab übrigens rausgefunden, warum man den Speicher nicht unter 0x0080 anlegen sollte: http://www.cypress.com/?rID=28901 http://www.cypress.com/?id=4&rID=26999 Hat also was mit dem Interrupt-Vektor und dem Speicherbedarf des Downloaders zu tun... Das hier dürfte auch interessant sein, zwecks automatischem Monitor-Download, der wohl jedesmal beim Anstecken gemacht wird: http://www.cypress.com/?docID=4629 Ralf
Ralf schrieb: > Wahrscheinlich(!) deswegen, weil in die absolute Adresse vermuten lässt, > dass du weisst, was du tust, und das deswegen okay für ihn ist. Hast du > die Adresse mit dem at-Schlüsselwort definiert oder über einen Pointer? Genau so isses. Alle Bereichsangaben sind nur bindend, wenn der Linker selber die Variablen plazieren darf. Was Du plazierst, prüft der Linker nicht mehr. Er geht davon aus, daß Du Dir dabei was gedacht hast. Wenn nicht, dann laß es sein. Peter
Hi Peter, > Was Du plazierst, prüft der Linker nicht mehr. Er geht davon aus, daß Du > Dir dabei was gedacht hast. Wenn nicht, dann laß es sein. Das ist ja das, was mich verwirrt, denn nach oben bereits gepostetem Link(http://www.keil.com/support/man/docs/c51/c51_le_absvarloc.htm) müsste der Linker maulen... Ralf
>denn nach oben bereits gepostetem >Link(http://www.keil.com/support/man/docs/c51/c51_le_ab...) >müsste der Linker maulen... Dort steht nix davon das der Linker mault. Und hör auf Peters Worte: Lass es sein. Die Festlegung der Adresse einer Variablen mit at braucht man bei einem C-Compiler normalerweise überhaupt nicht. Ausnahme: Externe Geräte die MemoryMapped angeschlossen sind. Ansonsten ist das at quasi überflüssig.
> Dort steht nix davon das der Linker mault. Doch, steht: >> The absolute address following the at keyword must conform to the >> physical boundaries of the memory space for the variable. The Cx51 >> Compiler checks for and reports invalid address specifications. > Die Festlegung der Adresse einer Variablen mit at braucht man bei einem > C-Compiler normalerweise überhaupt nicht. Das ist richtig, aber wenn er schon fragt, können wir's ihm auch beantworten... Dass er's lassen soll, wenn er's nicht unbedingt braucht, dürfte ihm klar sein. Ralf
Ralf schrieb: >> Dort steht nix davon das der Linker mault. > Doch, steht: > >>> The absolute address following the at keyword must conform to the >>> physical boundaries of the memory space for the variable. The Cx51 >>> Compiler checks for and reports invalid address specifications. Also ich sehe da zwei mögliche Bedeutungen drin: 1. Die Adressen müssen im Umfang des physikalischen Speichers liegen (das würde bedeuten, dass der Compiler nur prüft, ob die Adressen die 8kByte nicht überschreiten [-> holger]) oder 2. Die Adressen müssen den Angaben, die dem Compiler im BL51-tab gemacht werden genügen [-> Ralf]. >> Die Festlegung der Adresse einer Variablen mit at braucht man bei einem >> C-Compiler normalerweise überhaupt nicht. > Das ist richtig, aber wenn er schon fragt, können wir's ihm auch > beantworten... Dass er's lassen soll, wenn er's nicht unbedingt braucht, > dürfte ihm klar sein. Normalerweise verwende ich auch kein at, aber für einige wenige Variablen, deren Werte ich vom PC auslesen will, nutze ich at. > Ich hab übrigens rausgefunden, warum man den Speicher nicht unter 0x0080 > anlegen sollte Danke! Genau soetwas habe ich auch gesucht... aber nicht gefunden... grazie! Grüße
> Normalerweise verwende ich auch kein at, aber für einige wenige > Variablen, deren Werte ich vom PC auslesen will, nutze ich at. Dann nehme ich an, du sendest die Werte nicht per Firmware, sondern greifst per Debugger o.ä. drauf zu? Sonst wäre eigentlich auch hier kein AT notwendig... Ralf
>> Ich hab übrigens rausgefunden, warum man den Speicher nicht unter 0x0080 >> anlegen sollte > Danke! Genau soetwas habe ich auch gesucht... aber nicht gefunden... > grazie! Bitte. Aber ist mir schleiferhaft, warum man es machen soll, weil sich der Keil C51 darum eigentlich automatisch kümmert... Egal, Hauptsache, es funzt :) Ralf
Angehängte Dateien:
-
Clipboard00.jpg
120 KB -
Clipboard01.jpg
460 KB
Noch eine Ergänzung: > Das hier dürfte auch interessant sein, zwecks automatischem > Monitor-Download, der wohl jedesmal beim Anstecken gemacht wird: > http://www.cypress.com/?docID=4629 Das finde ich jetzt wieder komisch. Ich habe die Einstellungen wie im in den oberen Beiden Eingabefeldern vorgenommen (siehe Screenshot1). Hier wird daas aber nicht dort vorgenommen (siehe Screenshot2)... warum das denn?!
Ralf schrieb: >> Normalerweise verwende ich auch kein at, aber für einige wenige >> Variablen, deren Werte ich vom PC auslesen will, nutze ich at. > Dann nehme ich an, du sendest die Werte nicht per Firmware, sondern > greifst per Debugger o.ä. drauf zu? Sonst wäre eigentlich auch hier kein > AT notwendig... Ja, ich habe ein kleines Delphi-Programm, das ständig die Variablenwerte im xdata-Bereich ausliest.
> Das finde ich jetzt wieder komisch. Ich habe die Einstellungen wie im in > den oberen Beiden Eingabefeldern vorgenommen (siehe Screenshot1). Hier > wird daas aber nicht dort vorgenommen (siehe Screenshot2)... warum das > denn?! Ich denke, weil's im Prinzip das gleiche ist, wobei im einen Fall halt keine Endadresse angegeben wird... > Ja, ich habe ein kleines Delphi-Programm, das ständig die Variablenwerte > im xdata-Bereich ausliest. Okay, aber das Auslesen ist über ne Debugfunktion realisiert, oder? Ralf
Ralf schrieb: > Ich denke, weil's im Prinzip das gleiche ist, wobei im einen Fall halt > keine Endadresse angegeben wird... Also weiß hier da der Compiler selbst, wie viel Speicher er verwenden darf. >> Ja, ich habe ein kleines Delphi-Programm, das ständig die Variablenwerte >> im xdata-Bereich ausliest. > Okay, aber das Auslesen ist über ne Debugfunktion realisiert, oder? Dazu nutze ich eine Unit, die ich nicht selbst geschrieben habe (deswegen kenne ich mich damit leider nicht aus)... Hier die entsprechende Funktion in der Unit: function RdRAM(Adr: Word): Byte; var USBTemplateHandle: THandle; USBDeviceHandle: THandle; nBytes: DWord; MyRequest: _VENDOR_REQUEST_IN; Buffer: Array [1..2] of Byte; begin USBError := False; USBTemplateHandle := 0; myRequest.bRequest := $A0; myRequest.wValue := Adr; myRequest.wIndex := 0; myRequest.wLength := 1; myRequest.direction := 1; // Read myRequest.bData := $00; USBDeviceHandle := CreateFile (pGeraet,Generic_write,File_Share_write,nil,open_existing, 0,USBTemplateHandle); If USBDeviceHandle = INVALID_HANDLE_VALUE Then USBError := True; DeviceIoControl(USBDeviceHandle,IOCTL_BinTerm_VENDOR_REQUEST,@myRequest, 10,@Buffer,SizeOf(Buffer),nBytes, nil); CloseHandle (USBDeviceHandle); Result := Buffer[1]; end; Meinst du das mit "Debugfunktion"?
> Also weiß hier da der Compiler selbst, wie viel Speicher er verwenden darf. Gute Frage :) Ich halte die Bereichsangabe für sinnvoller/sicherer. > Meinst du das mit "Debugfunktion"? Jain. Ich kenne ja die restliche Firmware nicht. Das sieht nach einem ganz normalen USB-Request aus, aber das muss dir jemand anders aussagekräfitg beantworten :) Debug-Funktion heisst für mich, entweder Zugriff über ein Monitorprogramm oder einen Debugadapter etc. Ralf
Achso, nein, das habe ich nicht... ich habe an meinem Board nämlich keinen anderen Anschluss, als nur den einen USB-Anschluss... >> Also weiß hier da der Compiler selbst, wie viel Speicher er verwenden >>darf. >Gute Frage :) >Ich halte die Bereichsangabe für sinnvoller/sicherer. Und die Tatsache, dass die das in andere Feldern eingetragen haben, muss mir nicht zu denken geben?
> Achso, nein, das habe ich nicht... ich habe an meinem Board nämlich > keinen anderen Anschluss, als nur den einen USB-Anschluss... Dann würde ich auf das AT verzichten, und lieber einen Weg suchen, der unabhängig von der Variablenposition ist. > Und die Tatsache, dass die das in andere Feldern eingetragen haben, muss > mir nicht zu denken geben? Nun, wenn du sicher gehen willst, trägst du es halt zusätzlich ein, CODE-Ende = XDATA-Anfang - 1. Oder funktioniert es dann wieder nicht mehr? Ich sehe da kein Problem, aber bestätigen kannst es nur du... Ralf
>> Und die Tatsache, dass die das in andere Feldern eingetragen haben, muss >> mir nicht zu denken geben? Gibt es beim Keil denn keine Grundkonfigdatei die du für deinen uC einsetzen kannst?
Ralf schrieb: >> Achso, nein, das habe ich nicht... ich habe an meinem Board nämlich >> keinen anderen Anschluss, als nur den einen USB-Anschluss... > Dann würde ich auf das AT verzichten, und lieber einen Weg suchen, der > unabhängig von der Variablenposition ist. Was für Möglichkeiten gibts dazu denn noch? Mir würden nur spontan Pointer einfallen... aber man müsste dann ja trotzem eine Variable an festgelegter Position haben (in der die Startadresse für ein Array aus den abzufragenden Variablen abgespeichert ist...) > CODE-Ende = XDATA-Anfang - 1. Was soll denn das heißen? > Gibt es beim Keil denn keine Grundkonfigdatei die > du für deinen uC einsetzen kannst? Ich weiß von keiner... Grüße
>Was für Möglichkeiten gibts dazu denn noch? Mir würden nur spontan >Pointer einfallen... aber man müsste dann ja trotzem eine Variable an >festgelegter Position haben (in der die Startadresse für ein Array aus >den abzufragenden Variablen abgespeichert ist...) So ein Quatsch! Du hast ein Array im uC: unsigned char myarray[13]; Dein PC Programm möchte das erste Byte aus dem Array lesen. ReadArray(0); Dann schreibst du in deinem uC Programm: SendValue(myarray[0]); Siehst du dort irgendeine feste Adresse? Nein, siehst du nicht. Warum nicht? Weil es nicht nötig ist.
holger schrieb: >>Was für Möglichkeiten gibts dazu denn noch? Mir würden nur spontan >>Pointer einfallen... aber man müsste dann ja trotzem eine Variable an >>festgelegter Position haben (in der die Startadresse für ein Array aus >>den abzufragenden Variablen abgespeichert ist...) > > ReadArray(0); > SendValue(myarray[0]); Und wie soll ich den Funktionsaufruf "ReadArray(0);" vom PC an den µC senden (genauso: wie soll ich an den PC das Byte zurücksenden)? (Mit der USB-Programmierung habe ich noch keine Erfahrung)
> Mir würden nur spontan Pointer einfallen... Richtig. > ...aber man müsste dann ja trotzem eine Variable an festgelegter Position > haben (in der die Startadresse für ein Array aus den abzufragenden > Variablen abgespeichert ist...) Nein, die Position muss nicht festgelegt sein, sondern die kennt ja der Linker... Wenn du also schreibst (Beispielcode):
1 | unsigned char xdata buffer[10]; //char-Buffer in XDATA |
2 | unsigned char xdata * data bufptr; //XDATA-char-Pointer in DATA |
3 | |
4 | ...
|
5 | bufptr = &buffer[0]; //Adresse auf erstes Element |
6 | *bufptr++ = 0xAA; //in erstes Element schreiben und |
7 | //Pointer inkrementieren
|
8 | ...
|
...sollte das funktionieren. Es gibt auch noch Wege, den Pointer selber nicht mehr zu verändern, sondern mit einem Offset zu arbeiten, aber die Wege müsst ich erst nachschlagen. Vorteil ist halt, dass der Linker die Adressen kennt, und du dich keinen Fussel um die Adressverteilung kümmern musst... Sehr hilfreich, wenn du einmal feststellen solltest, dass du mit deinem reservierten Codespeicher platzmäßig nicht hinkommst, dann brauchst du nur den CODE-Bereich erweitern und den XDATA-Bereich verschieben, ohne dass du noch an den jeweiligen manuell vergebenen Adressen rumschrauben musst... >> CODE-Ende = XDATA-Anfang - 1. > Was soll denn das heißen? Okay, zugegeben, ungünstig geschrieben :) Ich meinte damit, der XDATA-Bereich startet direkt nach dem CODE-Bereich ;) Ralf
Oh, da ging noch was, während ich schrieb... > Und wie soll ich den Funktionsaufruf "ReadArray(0);" vom PC an den µC > senden (genauso: wie soll ich an den PC das Byte zurücksenden)? > (Mit der USB-Programmierung habe ich noch keine Erfahrung) Gegenfrage: Was kommt den im µC an? Das ist ohne Bezug auf USB! Es könnte genauso gut RS232 o.ä. sein. Jetzt ist natürlich die Frage, wo genau denn deine Variablen liegen? Hoffentlich nicht direkt im USB-Endpoint-Buffer! Du müsstest uns ja eigentlich sagen können, wie deine Firmware die Anfrage vom PC handhabt, also was da genau passiert bzw. welcher Firmware-Code da dann ausgeführt wird... Ralf
Fange ich mit dem an, was ich beantworten kann: > Jetzt ist natürlich die Frage, wo genau denn deine Variablen liegen? > Hoffentlich nicht direkt im USB-Endpoint-Buffer! Nein, das tun sie nicht ;-) Sie liegen im frei vervendbaren RAM (0x0080 - 0x1B3F) > Du müsstest uns ja eigentlich sagen können, wie deine Firmware die > Anfrage vom PC handhabt, also was da genau passiert bzw. welcher > Firmware-Code da dann ausgeführt wird... Hm... ich glaube, da muss ich dich enttäuschen... so hardwarenah habe ich noch nie gearbeitet... kann ich mich da einarbeiten? Viele Grüße, Stefan
> Hm... ich glaube, da muss ich dich enttäuschen... so hardwarenah habe > ich noch nie gearbeitet... kann ich mich da einarbeiten? Ja, klar kannst du dich da einarbeiten. Hurtig, hurtig, auf ans Werk... Du musst halt rausfinden, wie sich deine Firmware anmeldet (HID, VCP, etc.). Dann kannst du im Programmcode die Stelle suchen, die die Anforderung vom PC, die Daten zu senden, übernimmt und passt sie entsprechend an. Ausserdem empfehle ich das Studium der Beispielsoftware, zu der es sicherlich eine Erklärung geben wird, wie sie funktioniert und aufgebaut ist... Hatte denn die Beispielsoftware, auf der deine Firmware basiert, auch bereits feste Adressen für Variablen implementiert? Ralf PS: Wenn du noch nie so hardwarenah programmiert hast, ist die Ansteuerung eines 1W-Sensors dann nicht ein bisschen viel? staun
>Nein, das tun sie nicht ;-) Sie liegen im frei vervendbaren RAM (0x0080 >- 0x1B3F) Das ist dein Code Bereich. Da gehören keine Variablen hin. Wenn die Variablen in diesen Bereich sollen, dann muss dein Code Bereich woanders hin.
Ralf schrieb: >> Hm... ich glaube, da muss ich dich enttäuschen... so hardwarenah habe >> ich noch nie gearbeitet... kann ich mich da einarbeiten? > Ja, klar kannst du dich da einarbeiten. Hurtig, hurtig, auf ans Werk... > Du musst halt rausfinden, wie sich deine Firmware anmeldet (HID, VCP, > etc.). Dann kannst du im Programmcode die Stelle suchen, die die > Anforderung vom PC, die Daten zu senden, übernimmt und passt sie > entsprechend an. Also ich habe mal gesucht... und soooooooo viel gefunden, von dem ich zum einen nicht weiß, ob es das richtige ist und das zum anderen einfach erschlagend viel ist... > Ausserdem empfehle ich das Studium der Beispielsoftware, zu der es > sicherlich eine Erklärung geben wird, wie sie funktioniert und aufgebaut > ist... Meinst du mit Beispielsoftware die von Keil? > Hatte denn die Beispielsoftware, auf der deine Firmware basiert, auch > bereits feste Adressen für Variablen implementiert? Das Programm befindet sich im Anhang. (Ja, hatte es...) > PS: Wenn du noch nie so hardwarenah programmiert hast, ist die > Ansteuerung eines 1W-Sensors dann nicht ein bisschen viel? *staun* Naja, das Onewireprotokoll finde ich eigentlich relativ einfach (okay, hat mir schon viele Probleme bereitet, aber die Logik finde ich einfach ;-)) An sich klappt es ja mittlerweile soweit ganz gut ;-) >>Nein, das tun sie nicht ;-) Sie liegen im frei vervendbaren RAM (0x0080 >>- 0x1B3F) >Das ist dein Code Bereich. Da gehören keine Variablen hin. >Wenn die Variablen in diesen Bereich sollen, dann muss dein >Code Bereich woanders hin. Mooooooooment ;-) Jetzt habe ich endlich eine meiner Meinung nach sinnvolle Erklärung gefunden, jetzt Erklärst du sie wieder für falsch... also dann sage ich mal, was ich weiß und du kommentierst das, wenns wo falsch ist ;-) Der AN2131S hat nach meiner Erkenntnis frei verwendbaren RAM von 0x0000 - 0x1B3F (siehe Anhang). Da wir einen Bereich für CODE und für XDATA brauchen, müssen wir diesen RAM dafür aufteilen. Was ist daran falsch? Viele Grüße, Stefan
Hi Stefan, > Meinst du mit Beispielsoftware die von Keil? Ich meine die Software, auf der deine Software aufbaut :) > Das Programm befindet sich im Anhang. (Ja, hatte es...) Öhm... ich seh da bloß n Datenblatt in deiner aktuellen Antwort?!? >>>Nein, das tun sie nicht ;-) Sie liegen im frei vervendbaren RAM (0x0080 >>>- 0x1B3F) >>Das ist dein Code Bereich. Da gehören keine Variablen hin. >>Wenn die Variablen in diesen Bereich sollen, dann muss dein >>Code Bereich woanders hin. >Mooooooooment ;-) Jetzt habe ich endlich eine meiner Meinung nach >sinnvolle Erklärung gefunden, jetzt Erklärst du sie wieder für falsch... >also dann sage ich mal, was ich weiß und du kommentierst das, wenns wo >falsch ist ;-) Moooooment, ich hab das nicht geschrieben :) >Der AN2131S hat nach meiner Erkenntnis frei verwendbaren RAM von 0x0000 >- 0x1B3F (siehe Anhang). Da wir einen Bereich für CODE und für XDATA >brauchen, müssen wir diesen RAM dafür aufteilen. >Was ist daran falsch? Da ist nix dran falsch, nur deine Antwort war zu allgemein, da sie den Gedanken aufkommen lässt, dass dein XDATA-Bereich bereits bei 0x0080 beginnt... Deswegen schrieb Holger, dass sie da nicht hingehören (was aus seiner Sicht ja richtig ist, da erstmal der CODE-Bereich folgt, und dann XDATA). Ralf
Ralf schrieb: >> Das Programm befindet sich im Anhang. (Ja, hatte es...) > Öhm... ich seh da bloß n Datenblatt in deiner aktuellen Antwort?!? > Ähm, sorry, hab wieder mal am Ende vom Schreiben vergessen, den Anhang anzuhängen... also hier ist das Basisprogramm ;-) >>Der AN2131S hat nach meiner Erkenntnis frei verwendbaren RAM von 0x0000 >>- 0x1B3F (siehe Anhang). Da wir einen Bereich für CODE und für XDATA >>brauchen, müssen wir diesen RAM dafür aufteilen. >>Was ist daran falsch? > Da ist nix dran falsch, nur deine Antwort war zu allgemein, da sie den > Gedanken aufkommen lässt, dass dein XDATA-Bereich bereits bei 0x0080 > beginnt... Deswegen schrieb Holger, dass sie da nicht hingehören (was > aus seiner Sicht ja richtig ist, da erstmal der CODE-Bereich folgt, und > dann XDATA). Okay, stimmt... also hier nochmal für alle gaaaanz deutlich: Code von 0x80-0x0D5F Xdata von 0x0D60-0x1B3F Grüße, Stefan
das gibts nicht... schon wieder ohne Anhang weggeschickt... also HIER IST ER :)
Okay, das Basisprogramm macht offenbar gar nix mit USB (super Beispielcode, wenn du mich fragst :) ). Dann schieb bei Gelegenheit mal das jetzige Programm komplett her, vielleicht finden wir dann raus, wie die Firmware auf die Variablen zugreift, so dass du evtl. auf die festen Adressen verzichten kannst... Ralf
Okay, gerne :) (das Programm ist noch nicht fertig) Also zu meinem Vorgehen bezüglich USB bisher: Ich habe das "EZ-USB-Control Panel" geöffnet und da dann die .hex Datei des Programms mit "Download" in den Chip geladen. > Okay, das Basisprogramm macht offenbar gar nix mit USB (super > Beispielcode, wenn du mich fragst :) ). Stimmt schon :) dewegen habe ich mich auch gewundert, was ich daran bezüglich USB lernen soll :P Viele Grüße, Stefan
>> Okay, das Basisprogramm macht offenbar gar nix mit USB (super >> Beispielcode, wenn du mich fragst :) ). > Stimmt schon :) dewegen habe ich mich auch gewundert, was ich daran > bezüglich USB lernen soll :P Hast du doch oben geschrieben: Das Runterladen aufs Board =) Ich gucks mir bei Gelegenheit mal an... Ralf
Mal ne andere Frage: Wo willst du den an2131 noch kaufen? Hat das einen speziellen Grund genau diesen Controller zu nehmen?
Ralf schrieb: > Hast du doch oben geschrieben: Das Runterladen aufs Board =) Meinst du den "Download" des Programmes (was ich bisher mit dem Controlpanel gemacht habe?) > Ich gucks mir bei Gelegenheit mal an... Und, schon Ideen dazu gehabt? :D Abdul schrieb: > Mal ne andere Frage: Wo willst du den an2131 noch kaufen? Hat das einen > speziellen Grund genau diesen Controller zu nehmen? Den AN2131 gibts meines wissens nirgends mehr groß zu kaufen... aber mein Lehrer hat noch ca. 100 Stück von denen auf Lager ;-) Ich verwende diesen Controller, weil ich im Elektronikunterricht meiner Schule damit ein Board gebaut habe und mich somit mit diesem Chip vertraut gemacht habe (mehr oder weniger...). Nun mache ich das als Projekt für meine besondere Lernleistung fürs Abi :D Viele Grüße, Stefan
Hi Stefan, sorry für die späte Rückmeldung. Ich hab mir die Software mal angeguckt, auch dort finde ich nix, was auch nur ansatzweise vermuten lässt, dass da über USB aktiv kommuniziert wird (oder ich hab Siliziumwaver auf den Augen) Daher vermute ich, dass der Zugriff eher über eine Art eingebautes Debug-Interface stattfindet, welches über USB angesprochen wird. Wenn das tatsächlich stimmt, hast du zwei Möglichkeiten: 1. Du sorgst dafür, dass deine Bereichsangaben stimmen, und setzt die Variablen mit AT im für XDATA-Variablen vorgesehenen Bereich ein. Auch wenn der Compiler nicht mault, wenn die Variablen mit AT auf einer Adresse des CODE-Bereichs liegen, solltest du drauf achten, dass sie immer im XDATA-Bereich liegen. Um das ein bisschen zu entschärfen, kannst du die Variablen-Adressen ja vom Ende des XDATA-Bereichs an abwärts platzieren, dann sparst du dir die erneute Adressvergabe der Variablen, falls du feststellen solltest, dass der CODE-Bereich zu klein ist. 2. Du implementierst dein Device als eine der USB-Klassen (HID, VCP, etc.). Vorteil ist, dass du die Adressvergabe knicken kannst, und stattdessen auf einen Befehl vom Host hin die Daten sendest. Hier muss nur der Controller (= Linker) wissen, wo die Variablen sind, dir kann es egal sein. Und du kannst bestimmen, ob du dein Gerät z.B.als virtuellen COM-Port anmeldest, was für andere (nicht selbst geschriebene) Programme transparent ist und diese nicht geändert werden müssen (oder können).Nachteil könnte einmal der Aufwand sein, um die USB-Klasse zu implementieren und dein verfügbarer Code-Speicher reduziert sich. Du hast hier: Beitrag "Re: Einteilung von data, pdata, xdata, code?" einen Fetzen PC-Code gepostet. Ich dachte zuerst, dass das ein Programmteil ist, welcher für eine der USB-Klassen (HID, VCP, etc.) zuständig ist und sich dein Device entsprechend ansteuert. Da ich in deiner Firmware nix dazu finden kann, vermute ich, dass das doch eine Debug-Funktion ist. Gibt es dazu eine ApplicationNote o.ä. wo die Funktionen näher beschrieben sind? Ralf
Gut, also ich habe mich eher für Variante 2 entschieden (schließlich habe ich mich no nie tiefer mit der USB-slave zu USB-host Komunikation beschäftigt...) Eine Debug-Funktion? Was soll ich mir darunter vorstellen (der Begriff Debuggen sagt mir was, aber Debug-Funktion nicht...). Ich habe im Anhang mal die komplette Datei mitgeschickt (in der der "Codefetzen" enthalten ist). Vielleicht hilft dir das ja bei der "Diagnose" ;-) Von einem Applicationnote weiß ich leider nichts... Viele Grüße, Stefan
Fette Sache... Woher stammen die Code-Fetzen? Da wo du sie herhast, müsste es doch auch ne Doku dazu geben, oder nicht? Wegen dem Begriff "Debug" hier ein Auszug aus Wikipedia: Häufig wird auch der Begriff „debugging“ (dt.: entwanzen) auf Grace Hopper zurückgeführt. 1947 hatte während der Arbeiten an Mark II eine Motte für den Ausfall eines Relais dieses Computers gesorgt. Grace Hopper hat die (tote) Motte in das Logbuch geklebt und mit dem Satz „First actual case of bug being found.“ („Das erste Mal, dass tatsächlich ein Bug gefunden wurde.“) kommentiert. Der Begriff „Bug“ war im Englischen unter Ingenieuren bereits seit längerer Zeit als Bezeichnung für Fehlfunktionen in Gebrauch. Den kompletten Artikel kannst du hier nachlesen: http://de.wikipedia.org/wiki/Debugger Viele Hersteller implementieren in die Controller die Möglichkeit, auf die Register/Peripherie/etc. zuzugreifen und Werte zu lesen/schreiben, ohne dass es der Controller mitbekommt. Auch das schrittweise Abarbeiten der Befehle ist möglich (u.v.m.). Meistens wird über das gleiche Interface auch der Controller programmiert. Im Fall der AVRs ist das die JTAG Schnittstelle. SiLabs hat für die 8051er dafür hauptsächlich das C2-Interface. Dadurch, dass man die Werte abfragen kann, sieht man z.B. ob ein Wert falsch berechnet wird, etc. Früher ging das über sog. Monitorprogramme, die mit in den eigentlichen Code integriert waren. Hatte aber den Nachteil, dass man das Monitorprogramm an bestimmte Adressen im Code setzen musste, nicht alle Interrupts/Schnittstellen waren verfügbar, die Hardware musste bisweilen speziell dafür ausgelegt sein, etc. Heute eben wie gesagt über Hardware. Hat den Vorteil, dass der "reale" unveränderte Code gestestet werden kann. Die Controllerhersteller stellen dafür eben ihre sog."Debug"-Adapter zur Verfügung, zusammen mit entsprechender Software. In einigen Fällen wird auch die Möglichkeit geboten, per DLL o.ä. über die Programmiersprache deiner Wahl mit dem Controller über eben jenes Hardware-Interface kommunizieren zu können. So kann man sich z.B. eigene Download-Tools basteln etc. So, lange Rede, kurzer Sinn, ich denke, du greifst über eben jene integrierte Debugschnittstelle per USB zu, was erklären könnte, warum in deiner Firmware kein bisschen USB-Code steckt. Konkret vermute ich, dass du das verwendest: http://www.cypress.com/?rID=34870 Richtig? In dem Fall lies bitte mal das hier: http://www.cypress.com/?docID=4516 Das hilft vielleicht schon mal dem Verständnis, wie denn die Kommunikation momentan abläuft, auch wenn du nicht .NET verwendest. Ich würde dir raten, bei dem momentanen Stand nicht eine der USB-Klassen zu implementieren. Mach erst die Funktion, die du realisieren willst, fertig, und dann kannst du dich um die eigentliche USB-Kommunikation kümmern. Alles andere könnte dich sonst bremsen, weil du an zwei Seiten rumdoktorst. Ralf
Öhm... Gibts hierzu auch noch Rückmeldung, ob's geklappt hat? Ralf
Hey Ralf, sorry für die späte Rückmeldung (hab dich nicht vergessen, nur da die Schule mittlerweile wieder begonnen hat, bin ich da leider wieder ziemlich eingebunden...)! > Woher stammen die Code-Fetzen? Da wo du sie herhast, > müsste es doch auch ne Doku dazu geben, oder nicht? Tja, da ist leider der Haken... den Code hat jemand anderes ein paar Jahre zuvor als besondere Lernleistung entwickelt. Von daher gibt es keine direkte Dokumentation, aber ich kann ggf. die betreffende Person fragen, ob sie mir Infos geben kann ;-) Die Story mit der Motte hab ich auch schonmal gehört xD wobei es bei mir eher unwahrscheinlich ist, dass sich ne Motte zwischen die Transistoren setzte :P > Konkret vermute ich, dass du das verwendest: > http://www.cypress.com/?rID=34870 Ich weiß leider nicht, ob ich das irgendwo mal mitinstalliert habe... bewusst nutzen tue ich es jedenfalls nicht... > Ich würde dir raten, bei dem momentanen Stand nicht eine der > USB-Klassen zu implementieren. Mach erst die Funktion, die du > realisieren willst, fertig, und dann kannst du dich um die eigentliche > USB-Kommunikation kümmern. Alles andere könnte dich sonst bremsen, weil > du an zwei Seiten rumdoktorst. Da stimme ich dir vollkommen zu ;-) das wäre glaube ich ein neues Thema für eine weitere besondere Lernleistung... von daher schaue ich erstmal, dass das mit der Onewire-Übertragung und -Messung klappt und danach kann ich mich ggf. noch mit der USB-Kommunikation beschäftigen ;-) Also, an dieser Stelle nochmals -> VIELEN HERZLICHEN DANK FÜR DEINE GROßARTIGE HILFE!!! <- Ich hätte sonst wahrscheinlich noch nen ganzen Monat an den Einstellungen für den Speicher rumgedoktort... Viele Grüße, Stefan
Hi Stefan, > sorry für die späte Rückmeldung (hab dich nicht vergessen, nur da die > Schule mittlerweile wieder begonnen hat, bin ich da leider wieder > ziemlich eingebunden...)! Kein Thema, ich dachte ich frag halt mal... :) Schule? Ich bin zwar seit zehn Jahren raus, aber soweit ich weiss, sind doch grad Herbstferien? staun >> Konkret vermute ich, dass du das verwendest: >> http://www.cypress.com/?rID=34870 > Ich weiß leider nicht, ob ich das irgendwo mal mitinstalliert habe... > bewusst nutzen tue ich es jedenfalls nicht... argl :) Wenn du keinen USB-Code verwendest, bleibt ja nicht viel übrig :) Wie sonst wird denn das Teil programmiert? > Da stimme ich dir vollkommen zu ;-) das wäre glaube ich ein neues Thema > für eine weitere besondere Lernleistung... von daher schaue ich erstmal, > dass das mit der Onewire-Übertragung und -Messung klappt und danach kann > ich mich ggf. noch mit der USB-Kommunikation beschäftigen ;-) Jo, bis dahin dürfte dein Erfahrungsschatz was die Programmierung betrifft auch noch mal gewachsen sein, was dir wiederum bei USB dann sicher hilft. Ralf
Ralf schrieb: > Schule? Ich bin zwar seit zehn Jahren raus, aber soweit ich weiss, sind > doch grad Herbstferien? *staun* Jajaa... ich bin aus Hessen... und da hat die Schule am Montag wieder angefangen... > Wenn du keinen USB-Code verwendest, bleibt ja nicht viel übrig :) Wie > sonst wird denn das Teil programmiert? Wie gesagt: Ich nutze das "EZ-USB-Control-Panel", um den Code, den ich vorher mit µVision3 programmiert und kompiliert habe, in den Chip zu laden. Viele Grüße, Stefan
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.