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.
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.
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
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
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 :-)
Geht auch über PORT zugriffe sind ja min 16 Pins frei.
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
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 :-)
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
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.
> ... > 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
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
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.
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
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 ;-)
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
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.