www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Einteilung von data, pdata, xdata, code?


Autor: Stefan S. (stefanst)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Stefan S. (stefanst)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Ralf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Bernhard M. (boregard)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Ralf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Was den Adressbereich und die Größe der Speichersegmente angeht, sollte 
die Angabe des richtigen Derivats in Keil bereits alles automatisch 
erledigen...

Ralf

Autor: Stefan S. (stefanst)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Abdul K. (ehydra) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Stefan S. (stefanst)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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

Autor: Ralf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Ralf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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

Autor: Stefan S. (stefanst)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Ralf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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_me...
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_bi...

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

Autor: Stefan S. (stefanst)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Stefan S. (stefanst)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Ergänzung:
Ich habe nun mal folgende Einstellungen vorgenommen (siehe Screenshots), 
funktioniert aber trotzdem nicht...

Autor: Abdul K. (ehydra) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 :-()

Autor: Stefan S. (stefanst)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Ralf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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

Autor: Stefan S. (stefanst)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Ralf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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

Autor: Ralf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Stefan S. (stefanst)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Ralf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Stefan S. (stefanst)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Ralf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Stefan S. (stefanst)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Ralf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> ...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

Autor: Stefan S. (stefanst)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.cf...

> ...dass der Code bei 0x0080 beginnen sollte...
hat das vielleicht irgendwas mit vorbelegten Adressen zu tun?

Stefan

Autor: Abdul K. (ehydra) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.cf...

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.

Autor: Stefan S. (stefanst)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Ralf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Stefan S. (stefanst)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Ralf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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

Autor: Stefan S. (stefanst)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: holger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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.

Autor: Stefan S. (stefanst)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Stefan S. (stefanst)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
hier der Screenshot

Autor: Ralf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sieht ja soweit nicht schlecht aus, was steht unten im 
Linker-Control-String?
Hast du probiert, ob's damit geht?

Ralf

Autor: Stefan S. (stefanst)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Stefan S. (stefanst)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
... wieder den Anhang vergessen...
also hier ist er!

Autor: Ralf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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

Autor: Stefan S. (stefanst)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Abdul K. (ehydra) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Stefan S. (stefanst)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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??

Autor: Ralf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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_ab...

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

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Ralf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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_ab...) 
müsste der Linker maulen...

Ralf

Autor: holger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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.

Autor: Ralf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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

Autor: Stefan S. (stefanst)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Ralf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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

Autor: Ralf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>> 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

Autor: Stefan S. (stefanst)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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?!

Autor: Stefan S. (stefanst)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Ralf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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

Autor: Stefan S. (stefanst)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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"?

Autor: Ralf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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

Autor: Stefan S. (stefanst)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Ralf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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

Autor: holger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>> 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?

Autor: Stefan S. (stefanst)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: holger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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.

Autor: Stefan S. (stefanst)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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)

Autor: Ralf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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):
unsigned char xdata buffer[10];    //char-Buffer in XDATA
unsigned char xdata * data bufptr;  //XDATA-char-Pointer in DATA

...
bufptr = &buffer[0];      //Adresse auf erstes Element
*bufptr++ = 0xAA;      //in erstes Element schreiben und 
          //Pointer inkrementieren
...

...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

Autor: Ralf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Stefan S. (stefanst)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Ralf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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

Autor: holger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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.

Autor: Stefan S. (stefanst)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Ralf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Stefan S. (stefanst)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Stefan S. (stefanst)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
das gibts nicht... schon wieder ohne Anhang weggeschickt... also HIER 
IST ER :)

Autor: Ralf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Stefan S. (stefanst)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Ralf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>> 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

Autor: Abdul K. (ehydra) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mal ne andere Frage: Wo willst du den an2131 noch kaufen? Hat das einen 
speziellen Grund genau diesen Controller zu nehmen?

Autor: Stefan S. (stefanst)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Ralf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Stefan S. (stefanst)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Stefan S. (stefanst)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
... wie immer ...

Autor: Ralf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Ralf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Öhm... Gibts hierzu auch noch Rückmeldung, ob's geklappt hat?

Ralf

Autor: Stefan S. (stefanst)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Ralf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Stefan S. (stefanst)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.