mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik [8052(t51)] und Peripherie über XRAM Leitungen


Autor: Christian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Leute,

wir arbeiten seit einiger Zeit an einem Uni Projekt und benutzen dafür 
unter anderem den 8052(t51) von opencores.org. Wir haben den Chip auf 
ein Spartan 3E Board gepackt und alle Funktionen wie Display ansteuern, 
über den uART senden, Timer benutzen, usw. erfolgreich getestet und 
benutzt.

Jetzt haben wir einen selbstgebauten CAN-Controller bekommen und würden 
den gerne an unseren Core anschließen. Also haben wir uns gedacht, 
packen wir den einfach an unsere XRAM Leitungen, da wir eh keinen 
externen Speicher verwenden.
(Der CAN funktioniert übrigens tadellos, da unsere Kollegen den bereits 
mit einem HC08, einem AVR und anderen Cores benutzen können.)

Unser Problem an der ganzen Sache ist, dass wir nicht genau wissen, ob 
wir irgendein spezielles SFR setzen müssen, wenn man auf die XRAM 
Leitungen zugreifen möchte.
Sprich: Wie bekommen wir das hin, dass das Signal "ext_ram_en" in 
8052.vhd auf eins gesetzt wird? Dieses hat damit ja quasi zu tun.

Ich weiss, dass man im Assembler anstelle von "movc", "movx" benutzen 
müsste, wenn man eine externe Speicherstelle ansprechen möchte, aber wie 
implementiere ich sowas in C bzw. in VHDL?
Und geht es überhaupt, wenn wir keinen Speicher dort angeschlossen 
haben?

Danke im Voraus.

mfg

Christian


PS: Ich habe im Forum gesucht, aber nicht wirklich was dazu gefunden, 
obwohl ein Artikel sich mit ähnlichem beschäftigt. Man muss dazu sagen, 
wir haben uns gut in das Thema eingearbeitet, aber natürlich noch viele 
Wissenlücken. Vielleicht kann uns ja jemand auf die Sprünge helfen oder 
Tipps geben.

Autor: Christian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Achja, ich hab nicht gesehen, wie ich diesen Beitrag dem 8051 Unterpunkt 
zuordnen kann. Das bitte ich zu entschuldigen bzw. den Thread dahin zu 
verschieben.
Danke.

Autor: Ralf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
In Assembler benutzt man dafür, wie du bereits hast, movx. Vorher wird 
der Datenpointer DPTR auf die entsprechende Adresse gesetzt.

mov dptr,#CAN_REG0  ;Adresse des CAN-Controllers bzw. dessen Register
movx a, @dptr       ;liest aus dem CAN-Controller
movx @dptr, a       ;schreibt in den CAN-Controller

Alternativ dazu gibt es noch die Möglichkeit, movx-Befehle über R0 bzw. 
R1 auszuführen.

In C legt man eine Variable im xdata-Bereich an.

uchar xdata ucCAN-Controller at 0x1234

Das o.g. Beispiel ist aber Pseudocode, da es hier immer auf den 
verwendeten C-Compiler ankommt, das heisst, du musst das Handbuch des 
Compilers bemühen.
Ausserdem sollten die entsprechenden Variablen als Volatile deklariert 
werden, weil es sonst vorkommen kann, dass der Compiler die Zugriffe 
wegoptimiert.

Ralf

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich benutze als 8051 mit CAN den AT89C51CC03 und bin sehr zufrieden 
damit.

Das CAN ist in den SFR-Bereich gemappt, man kann also direkt auf die 
Register und Bits zugreifen.
Geht nen ordentlichen Zacken schneller und Code sparender, als über 
XDATA.

Über den CAN-Bootloader kann er auch komfortabel umprogrammiert werden.


Peter

Autor: Christian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hey,

ich danke Euch beiden schonmal sehr für Eure Antworten.
Habe allerdings noch ein paar Fragen:

1) Ralf_schrieb :
"In Assembler benutzt man dafür, wie du bereits hast, movx. Vorher wird
der Datenpointer DPTR auf die entsprechende Adresse gesetzt.
mov dptr,#CAN_REG0  ;Adresse des CAN-Controllers bzw. dessen Register
movx a, @dptr       ;liest aus dem CAN-Controller
movx @dptr, a       ;schreibt in den CAN-Controller"

--> Wir sind uns ja einig, dass wir keinen externen Speicher besitzen, 
da wir an die XRAM Leitungen ja den CAN angeschlossen haben. Wo genau 
kann ich denn dann die Adresse des CAN_Controller speichern wenn nicht 
im externen? Speicher ich die im normalen internen Datenspeicher und 
verweise dann mit dem Pointer darauf?
Und movx aktiviert dann die XRAM Leitungen und schickt alles auf den 
Leitungen hin und her? Das ist mir noch nicht ganz klar ...


2) Peter Dannegger_schrieb :
"Das CAN ist in den SFR-Bereich gemappt, man kann also direkt auf die
Register und Bits zugreifen.
Geht nen ordentlichen Zacken schneller und Code sparender, als über
XDATA."

--> Es wurde uns jetzt schon von mehreren Seiten geraten, den CAN in 
unsere SFR zu integrieren. Könntest Du mir da ein kurzen Denkanstoß 
geben, wie man da genau vorgeht?
Also wir haben einen Treiber für unseren CAN (ein Header File, wo eine 
BaseAdress steht und alle weiteren benötigten Werte sind in Relation zur 
BaseAdress gesetzt)
Vorher haben wir einfach die BaseAdress an eine freie Stelle im internen 
Speicher gelegt. Müssen wir jetzt alle speziellen SFR´s zuweisen?
Und wie genau wird das dann Hardwareseitig gelöst? Muss ich mir zu allen 
erschaffenen SFR´s zusätzlich Signale in VHDL bauen? Weil irgendwie muss 
ich ja die Verbindung vom CAN_Controller zum 8051 herstellen, da wir die 
XRAM Leitungen in dem Fall ja nicht mehr nutzen.
Irgendwie fehlt mir da so der Anfang bzw. die genau Logik.


Ich danke Euch schonmal für Eure Hilfe :-)

Autor: Skua (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Geht auch über PORT zugriffe sind ja min 16 Pins frei.

Autor: Ralf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
zu Frage 1):
Ich geh jetzt mal von einem allgemeinen 8051- bzw. µC-Design aus, 
welches eben einen externen Daten-/Adress-/Steuerbus zur Verfügung 
stellt (das lässt sich dann schön für die Allgemeinheit erklären). 
Desweiteren gehe ich davon aus, dass eine Dekodierlogik vorhanden ist, 
die abhängig von der Adresse, auf die zugegriffen wird, 
Chip-Select-Signale generiert.

Als Beispiel hat das System 64kB Adressraum (wie z.B. bei einem 8051), 
von dem die letzten 256 Byte (also 0xFF00 - 0xFFFF) den 
Chip-Select-Signalen zugeordnet sind.

Also:

0x0000 - 0xFEFF    verfügbar für RAM
0xFF00 - 0xFFFF    verfügbar für Peripherie

Wenn auf Peripherie zugegriffen wird, ist das RAM gesperrt, und 
umgekehrt.

So, jetzt nehmen wir noch an, du hast innerhalb der letzten 256 Bytes 
(=Adressen) durch die Dekodierlogik insgesamt 8 Chip-Select-Signale zur 
Verfügung:

0xFF00 - 0xFF1F    Chip-Select 0
0xFF20 - 0xFF3F    Chip-Select 1
...
0xFFE0 - 0xFFFF    Chip-Select 7

Der Hardware-Entwickler verknubbelt die Peripherie mit einem der 
Chip-Selects... und muss das eben auch dem Softwerker mitteilen, auf 
welchem CS das Teil liegt.
Der Softwerker wird in seiner Software folgendes machen:

ASM:

CAN_REG0   equ 0xFF20 ;CAN-Controller an Chip-Select 1
CAN_REG1   equ 0xFF21 ;(oder besser CAN_REG0+1, dann muss nur die 
Basisadresse geändert werden, der Rest verschiebt sich dann automatisch)

C (Compiler abhängig(!!!)):
#define CAN_ADRESS 0xFF20

unsigned char xdata * CAN0_REG _at_ CAN_ADRESS;

Achtung, es gibt je nach Compiler unterschiedliche Implementationen bzw. 
Implementationsmöglichkeiten --> HANDBUCH!!!

> Wo genau kann ich denn dann die Adresse des CAN_Controller speichern
> wenn nicht im externen? Speicher ich die im normalen internen
> Datenspeicher und verweise dann mit dem Pointer darauf?
Nicht im Datenspeicher, sondern im Code selbst! Die Adresse wird wie 
oben beschrieben während dem Compilieren/Assemblieren direkt fest in das 
Programm eingebaut (sie verschiebt sich ja eh nicht mehr).

zu Frage 2):
Also, ich denke, Peter kann da sicher genaueres sagen, aber ob es so 
ohne weiteres geht, einen 8051-Core so mit einem CAN-Core zu 
verknubbeln, dass der CAN-Controller über die SFRs des 8051 angesteuert 
werden kann, wag ich zu bezweifeln. Gibt's für solche Aktionen nicht 
diesen... wie heisst das doch gleich... Wishbone-Bus (o.ä.)?
Sorry, wenn ich was falsches sag, aber FPGA kommt bei mir erst noch an 
die Reihe, von daher wär ne Aussage, ob/wie das geht, auch für mich 
interessant ;)

Ralf

Autor: Christian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Super Ralf,

ich danke Dir schonmal. Echt super von Dir.
Werde morgen mal alles in Ruhe lesen und mich dran versuchen.
Weitere Tipps sind natürlich trotzdem gern gesehen :-)

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ralf wrote:
> Also, ich denke, Peter kann da sicher genaueres sagen, aber ob es so
> ohne weiteres geht, einen 8051-Core so mit einem CAN-Core zu
> verknubbeln

Also mit FPGAs habe ich noch nichts gemacht.

Mir wurde auch in einem Xilinx FPGA-Seminar gesagt, daß es sich nicht 
lohnt, nen 8051 alleine in nen FPGA zu pappen, weder vom Zeitaufwand, 
noch von den Kosten her.
Lohnen tut es sich erst dann, wenn man eh Aufgaben hat, die nur ein FPGA 
lösen kann und man dann den 8051 nur nebenbei mit reinpackt.


Der AT89C51CC03 ist ein realer Chip, man kann sich aber angucken, wie 
dort das CAN realisiert ist und in die SFRs gemappt ist.
Weitere reale 8051-er mit CAN sind z.B. der C505C oder XC888 von 
Infineon.


Peter

Autor: Christian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also ich hatte da wohl einige Denkfehler noch drin.
Ich dachte ich muss den CAN an eine bestimmte Stelle im Speicher setzen, 
damit er verwendet werden kann.
Da man ihn aber auf die XRAM Leitungen mappt, reicht es ja, wenn man ihm 
eine fiktive Speicher Adresse gibt (0x8000 bei uns) und dann in 
Hardware/VHDL eine Fallunterscheidung setzt.
So gaukelt man dem Core ja quasi vor, das externer Speicher 
angeschlossen ist.
Bei 0x8000 ist bei uns das Basis Register des CAN.

Sobald auf dem Adressbus also eine "1000000000" anliegt, schalten wir 
die XRAM Leitungen auf die entsprechenden CAN Leitungen durch.
(Wir überprüfen nur die ersten 10 Bit, da die unteren 6 nur noch für den 
CAN interessant sind. Die werden dann auch weitergeleitet und geben dem 
CAN Controller entsprechende Befehle durch.

Heute scheint sich dann auch endlich unser Problem gelöst zu haben, dass 
die Signale nicht weitergeleitet wurden, bzw. auf bestimmten Leitungen 
keine Werte ankamen.
Wir hatten die Variablen im C File nicht mit dem Zusatz "xdata" 
versehen.
So hat der Core nie versucht auf die XRAM Leitungen zu schrieben, 
sondern auf die normalen RAM Leitungen.

Die Idee kam uns bei einme Blick in den Assembler Code. Da gab es nur 
reine MOV und keine MOVX Befehle.

Morgen testen wir es mal auf unserem FPGA mit angeschlossener Hardware 
über den CAN.

Autor: Ralf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> ...
> Wir hatten die Variablen im C File nicht mit dem Zusatz "xdata" versehen.
> ...
> Die Idee kam uns bei einme Blick in den Assembler Code. Da gab es nur
> reine MOV und keine MOVX Befehle.
Na, dann habt ihr heut ja wohl einige Erfolgserlebnisse gehabt :)
Weiterhin viel Erfolg und viel Spass... Falls es ein OpenSource-Projekt 
ist, könnt ihr es ja hier ins Forum setzen (wobei ich nicht weiss, in 
welche Rubrik man es denn setzen sollte), oder aber eure Erfahrungen 
bzgl. dem T51-Core und der (VHDL/FPGA)-Verbindung mit einer 
(CAN-)Peripherie-Einheit als Artikel in die Artikelsammlung einpflegen, 
das wäre sicher für den einen oder anderen interessant (vor allem für 
mich grins).

Ralf

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mich würde mal interessieren, warum ihr keinen fertigen MC mit CAN 
benutzt.
Ist das nur zu Ausbildungszwecken oder hat das auch einen praktischen 
Aspekt?

Was ist das fürn FPGA, ist das ein BGA oder noch etwas selber lötbares?

Mit welcher Frequenz läuft der 8051-Core maximal?
Ich hab mal ne Vorführung gesehen, wo der 8051-Core nur mit kleinen 
Frequenzen laufen konnte. Als dann versehentlich die PLL auf 50MHz hoch 
gesetzt wurde, ist er abgestürzt.


Peter

Autor: Christian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sorry das ich mich jetzt erst melde, aber war in letzter Zeit etwas viel 
unterwegs gewesen :-)
An welchen nicht-kommerziellen hättest Du da gedacht?
Haben uns 4 Opensource Cores genommen, damit es keine Probleme gibt.
Haben die soweit lauffähig gemacht, dass sie unseren Ansprüchen genügen 
und wir damit arbeiten können.
Einen CAN hatten wir gesucht, aber keinen akzeptablen frei verfügbaren 
gefunden, also haben wir uns einen eigenen gebaut und Treiber dafür 
geschrieben ;-)

Benutzen tun wir FPGA-Sparten 3e-s500 Boards, die mit 50 Mhz laufen.
Speziell der 8052 lief darauf schon ohne Probleme und wir konnten jede 
Peripherie wie z.B. LCD, uART oder ähnliches erfolgreich laufen lassen.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Christian wrote:
> An welchen nicht-kommerziellen hättest Du da gedacht?

An einen fertigen MC.
Meine Frage war, warum überhaupt einen FPGA?
Was sind dessen Vorteile?


> Einen CAN hatten wir gesucht, aber keinen akzeptablen frei verfügbaren
> gefunden, also haben wir uns einen eigenen gebaut und Treiber dafür
> geschrieben ;-)

Wenn ich dran denke, wieviel Bugs die ersten CAN-Chips hatten, dann wird 
diese Aufgabe wohl nicht leicht gewesen sein.
Habt ihr denn schon praktische Tests in einem richtigen CAN-Netzwerk 
gemacht?


> Benutzen tun wir FPGA-Sparten 3e-s500 Boards, die mit 50 Mhz laufen.

Und mit wieviel MIPS läuft dann der 8051, d.h. wie lange dauert ein NOP?

Die maximale FPGA-Frequenz sagt ja nichts über die maximale Frequenz 
einer Schaltung aus.
Außerdem teilt ja ein 8051 noch je nach Typ durch 1, 2, 4, 6 oder 12.


Peter

Autor: Christian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Naja was sind die Nachteile?
Ich mein wir haben Mitte Oktober angefangen. Unser Wissen war bis dahin 
sehr theoretisch und unser Prof gab das Ziel aus, das wir mindestens 2 
SoC´s auf einem FPGA zusammen laufen lassen wollen. Quasi ein Netzwerk.
Also haben wir uns FPGA´s besorgt um die Chips selbst, und mit 
Peripherie, zu testen.
Was hätten wir Deiner Meinung da nach nehmen sollen?
Ich muss gestehen, da wir erst seit kurzen in diesem Bereich richtig 
arbeiten, ist mein Wissen nocht nicht so umfangreich, dass ich mich in 
allen Bereichen auskenne.

Die Aufgabe mit dem CAN entstand eher spontan. Wir brauchten einen und 
kommerzielle waren teuer und die Opensource nicht wirklich zu 
gebrauchen.
Und da wir ein, zwei Genies dabei haben, haben die "mal eben" einen 
gebaut und geschrieben.
War natürlich ein riesen Aufwand, aber gut ... :-) Es läuft tipp topp.
Aktuell funktionieren sogar alle Core´s mit kompletter Peripherie und 
CAN Anbindung.
Testaufbauten haben wir auch funktionsfähig. Unter anderem können wir 
einen Scheinwerfer bzw. Gangwahlschalter ohne Probleme ansteuern. (Alles 
an den CAN angeschlossen).

Wie würde ich die MIPS auf einem FPGA Board messen können?
Bzw. wie genau schicke/implementiere ich den NOP Befehl?
Gibt es dafür einen Standard Mini Porgramm mit Timer, der das zeitlich 
misst und umrechnet?
Ausgeben könnten wir das Ergebnis ja auf dem LCD ;-)

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Christian wrote:
> Naja was sind die Nachteile?

FPGAs haben ne Menge Nachteile, deshalb setzt man sie nur dort ein, wo 
ein fertiger MC nicht mehr reicht.

Es entstehen ja deutlich höhere Kosten durch den Baustein selber, die 
nötige Außenbeschaltung (Boot-Flash) und das komplexere Layout.
Die Stromaufnahme dürfte auch deutlich höher sein und wenn man andere 
5V-ICs anschließen muß, sind sie nicht 5V-tolerant (haufen Pegelanpasser 
nötig).


> Ich mein wir haben Mitte Oktober angefangen. Unser Wissen war bis dahin
> sehr theoretisch und unser Prof gab das Ziel aus, das wir mindestens 2
> SoC´s auf einem FPGA zusammen laufen lassen wollen.

Wenn man als Vorgabe einen FPGA verwenden muß, ist das natürlich ein 
Grund.
Allerdings wären Aufgaben besser, die auch einen praktischen Aspekt 
haben.
Ist aber nicht Deine Schuld, sondern die Deines Prof..



> Und da wir ein, zwei Genies dabei haben, haben die "mal eben" einen
> gebaut und geschrieben.

Mal eben was zusammenschustern dauert etwa 5% der Zeit, bis es dann aber 
richtig fehlerfrei läuft, braucht man die restlichen 95%.



> Testaufbauten haben wir auch funktionsfähig. Unter anderem können wir
> einen Scheinwerfer bzw. Gangwahlschalter ohne Probleme ansteuern. (Alles
> an den CAN angeschlossen).

Eine CAN-Implementierung muß ja nicht nur bei einem Paket zwischen 2 
Teilnehmern funktionieren, sondern auch bei vielen Teilnehmern und 
richtig Traffic (100%) auf dem Bus.
D.h. mit Fehlern, Signalverschleifungen, Störeinstreuungen, 
Pufferüberlauf, Retry usw.
Häufige Probleme bei CAN-Implementierungen sind gleichzeitige Zugriffe 
der Hardware und der Software, da geht öfters mal ein Bit verloren oder 
wird falsch gesetzt, wenn man das nicht richtig implementiert hat.

Ich will Deine Arbeit nicht schmälern, aber in der Praxis ist es immer 
noch ein sehr weiter Weg von den ersten Zuckungen eines Funktionierens 
bis zum fertigen, wirklich zuverlässig funktionierenden Gerät.


> Bzw. wie genau schicke/implementiere ich den NOP Befehl?

D.h. Du hast keinerlei Ahnung vom 8051-Core?

Mache eine Schleife (z.B. 65536 mal) und messe die Ausführungszeit.
Dann füge ein NOP ein und messe wieder. Die Differenz ist die Zeit für 
65536 NOPs.


> Ausgeben könnten wir das Ergebnis ja auf dem LCD ;-)

Nein.
Du mußt schon extern messen, z.b. mit einem Frequenzmesser mit 
Pulsdaueranzeige.
Ne CPU kann ja nicht ihre eigene Frequenz messsen.


Die Befehlsausführungszeit eines MCs muß man immer wissen.
Viele MC-Anwendungen leben davon, daß Sachen zu einer genau bestimmten 
Zeit für eine genau bestimmte Zeit ausgeführt werden.

Ohne Kenntnis der Taktfrequenz kann man also keine sinnvollen Programme 
schreiben. Nichtmal ein einfaches Blinklicht geht dann, außer Du machst 
es mit Trial&Error (planloses Rumprobieren).


Peter

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.