Coprozessor

f

ed

Schau mal bei denen vorbei:

dann im Forum: Da gibt es bestimmt einige die sich damit auskennen.

Gru=DF Mathias

Thorsten Kiefer schrieb:

Hallo Thorsten,

warum benutzt du nicht einfach die beiden eingebauten CAN's ?

Solange du nicht sagst welchen xc164, welchen externen CAN, und ob du den externen Daten und Adressenbus bereits benutzt, kann man dir schlecht einen Rat geben.

Gruß

Hans-Georg

Hallo Hans-Georg, es ist ein Infineon XC164CM16ff. Und der CAN-Controller ist ein Boasch CC770. Der Can-Controller ist mit seinen AD0-15-Leitungen an die Ports

1 und 3 des uC angeschlossen. Ich kann den eingebauten Can-Controller des uC nicht benutzen, weil er in Zukunft ausgetauscht werden kann und der CanController der Hauptakteur ist.

Gruß Thorsten

Hans-Georg Lehnard wrote:

Der CC770 scheint für den direkten Anschluss an einen 8051 Prozessor gedacht zu sein. Zumindest deuten die Pin-Bezeichnungen AD0-AD7 und A8-A15 und ALE darauf hin. Beim XC164 gibt es einen 8-Bit multiplexed bus mode. Ohne das Datenblatt genau gelesen zu haben würde ich mal darauf tippen, dass es genau darum geht.

Einfach mal nachsehen, wie man einen 8051 ein externes RAM oder EProm anschließt. Das müsste man 100.000-mal im WWW finden können.

z.B. hier:

Dann den Demultiplexer 74HC573 (seltener 74HC373) wegdenken und dann nachsehen, wie das beim XC164 funktioniert.

Gruß

Stefan DF9BI

Hab grad gesagt bekommen, daß der XC164 keinen externen Bus hat. Das könnte natürlich ein unlösbares Problem werden, nicht wahr ? Link zum Datenblatt kann ich dir geben, wenn du magst.

Stefan Brörr> Thorsten Kiefer wrote:

Hallo Thorsten, bitte mache Dir doch die Mühe und lies das Datenblatt oder das Users Manual oder auch nur das "XC164CS-16FF Product Overview" selbst durch!

Darin findest Du, dass der XC164 eine "external Bus Contro Unit (EBC)" hat die man für die verschiedensten Buskonfigurationen konfigurieren kann. Im Product Overview ist das auf Seite 9 beschrieben. Und spätestens im Pinout des TQFP-100 Gehäuses (Seite 30 des "XC164CS-16FF Product Overview" siehst Du, dass für den Betrieb des externen Busses viele Pins der Ports "geopfert" werden müssen.

Auf den Seiten 31ff sind die doppelten und dreifachen Belegungen der Ports sogar für jeden Pin in Tabellen beschrieben.

Zum Thema "wir benutzen keine interne Perpherie des Controllers, weil wir später umsteigen können wollen" kann ich nur sagen, dann nimm doch gleich eines der zukünftigen Derivate ohne Peripherie, dann sparst Du Dir die Anpassung Deiner Entwicklungsumgebung an das neue Teil und Du frickelst nur einmal die externe Peripherie an einen Controller/Prozessor. Ansonsten ist das integrierte Twin-CAN-Interface des XC164 wohl ganz brauchbar und mit Sicherheit besser und fixer in das Interrupt und Bus Konzept des Controllers eingebunden als es der externe Controller sein wird.

Ich sage das hier nur, weil ich unter solchen Restriktionen auch mal entwickeln musste und wir in Hard- und Software ordentlich Klimmzüge veranstaltet haben um (quasi-pseudo-) unabhängig vom eingesetzen Controller zu sein. Das Ganze endete dann in einer Peripherienachbildung in FPGAs. Das war aufgrund der FPGAs und vor allem der Leiterplatte (viele Layer) richtig teuer und die Abhängigkeit wurde vom Controller auf die externen Peripheriebausteine und FPGAs verschoben. Ist schon bekloppt, wenn die eigentlich "flexible" Software so unflexibel ist, dass man nicht mal die low-level Treiber an andere UARTs, Timer oder auch CAN-Controller anpassen kann.

Gruß Ing.olf

Hm, merkwürdig. Das sah für mich anders aus. Hab das Datenblatt aber auch nur kurz überflogen.

Die Beschränkung auf die externen Controller kann ich allerdings auch nicht nachvollziehen. Wenn die Software vernünftig durchstrukturiert ist, spricht doch nichts dagegen, den internen Controller zu verwenden und wenn nötig später auszutauschen.

Unausgegorene Zukunftsplanungen, die einem das Grundkonzept unnötig verkomplizieren, sind in der Regel sowieso für die Mülltonne.

Gruß

Stefan DF9BI

Wohl wahr.

Einen externen CAN zu nehmen, wenn es einen guten internen gibt, und die Software nicht so zu modularisieren, dass man das tauschen kann, klingt nach Design by Manager.

Da kommen dann irgendwelche Schlipse und machen Vorgaben, was bittschön alles an IC's verbaut werden muss, egal ob das passt oder nicht, und die "wir kuschen brav" Ingenieure machen alles mit.

Gruß Oliver

--
Oliver Bartels + Erding, Germany + obartels@bartels.de
http://www.bartels.de + Phone: +49-8122-9729-0 Fax: -10

Hallo Inglof, danke für die ausführliche Antwort. Ich hab mir gerade das Datasheet des XC164CM-16ff angeschaut. Das ist übrigens unser Controller, nicht die CS-Version ! Auf jeden Fall gibts da ein EBC, aber da ist nur der TwinCAN angeschlossen, und die EBC ist nicht nach außen geführt. Beim CM gibt es wohl keine Möglichkeit, externe Peripherie memory-mapped anzusteuern, oder ?? Ich vermute mal, wenn wir den CC770 anschließen wollen, müssen wir auf die CS-Version umsteigen, oder ??

Gruß Thorsten

Manchmal sind es auch Möchtegern-Ingenieure oder Anfänger, die sich alles offen halten möchten und anstatt eine einfache Lösung zu realisieren jede Menge Erweiterungsmöglichkeiten vorsehen, die später irgendwann einmal genutzt werden könnten, die aber bei der Grundversion bereits Probleme bereiten, weil Dinge kapput gehen, die gar nicht benötigt werden.

Gruß

Stefan DF9BI

Thorsten Kiefer schrieb:

Oops, Pech im Unglück, die CM-Variante hat tatsächlich kein externes Businterface. Ich würde den internen Twin-CAN nehmen und gut, oder gleich das zukünftige Derivat. Zum Thema "Manager-Entscheidung" ist glaube ich soweit Alles gesagt...

Gruß aus Kiel Ing.olf

Ok, danke euch für die Unterstützung !!!

Gruß Thorsten

Thorsten Kiefer schrieb:

...

Hallo Thorsten,

immerhin habe wir dich dazu gebracht das Datenblatt zu lesen ;-)

Wer denkt sich denn so etwas aus ..

CAN Controller sind von der Software aus gesehen alle ähnlich. Wenn die Software nicht genauso umständlich realisiert wird, sollte ein Umstieg auf einen anderen Prozessor ohne grösseren Aufwand machbar sein.

Gruß

Hans-Georg