Hallo, ich suche Informationen (Beschreibunge, Datenblätter,..) zu Motorola 68k Prozessoren. Mit was programmiert man die am besten? Welche Compiler nimmt man da? Werd nämlich ein Projekt mit diesem Controller machen und hab noch keine Erfahrungen damit. Danke Mario
Du nennst "Motorola 68k" und "Controller" in einem Atemzug. Bist Du Dir sicher? Der 68K (ausgeschrieben: MC68000) wurde von Motorola 1979 auf den Markt gebracht und war ein 32-Bit-Prozessor mit externem 16 Bit breitem Daten- und 24 Bit breitem Adressbus. Verbaut wurde er unter anderem in frühen Apple Macintosh-Modellen, dem Atari ST und dem Commodore Amiga. Ein Controller ist das nicht, sondern eine CPU, die eine ganze Menge Beschaltung benötigt, bis man damit auch nur irgendwas anfangen kann (RAM, ROM, Peripherie, Takterzeugung, Adressdecodierung etc.). Könnte es sein, daß Du vielleicht doch irgendetwas anderes meinst?
Hi, wie Rufus schon gesagt hat, die 68000er sind keine mal eben so anzuprogrammierenden Chips, die brauchen ein Umfeld (zu finden z.B. in einem alten Atari oder Amiga oder was vom Apfel). Wer so fragt, dem ist wahrscheinlich hier vorerst am besten geholfen http://www.freescale.com/webapp/sps/site/homepage.jsp?nodeId=0162468449&tid=tmhb Einfach auf einen der Controller klicken, dann erscheint auch die gesammte Doku dazu. Die 8-bittigen Tierchen sind ja aus dem 6800er hervorgegangen. Vielleicht war auch das gemeint. Mit einem C-Compiler anzufangen halte ich für nicht sinnvoll, noch dazu gibt es diese kaum für lau (manche sind dennoch mit deftigen Einschränkungen verwendbar - macht die Sache aber auch nicht einfacher.) Noch vor kurzem hießen die übrigens Motorola, aber man hat sich ja daran gewöhnt, dass das Gute ausgegliedert wird. Gruß Gerd K.
@ Rufus T. *): "Du nennst "Motorola 68k" und "Controller" in einem Atemzug. Bist Du Dir sicher?" Wo ist das Problem? "Der 68K (ausgeschrieben: MC68000) wurde von Motorola 1979 auf den Markt gebracht und war ein 32-Bit-Prozessor mit externem 16 Bit breitem Daten und 24 Bit breitem Adressbus. Verbaut wurde er unter anderem in frühen Apple Macintosh-Modellen, dem Atari ST und dem Commodore Amiga." 68K ist eine ganze Familie und 68K steht bei Motorola nicht für 68000, sondern für (unter anderem): - 68000 - 68008 - 68012 - 68EC000 - 68HC000 - 68020 - 68EC020 - 68030 - 68EC030 - 68040 - 68EC040 - 68LC040 - 68060 - CPU32 - CPU32+ - Coldfire - Dragonball wobei die letzten vier keine Prozessorfamilien, sondern Mikrocontrollerfamilien sind. "Ein Controller ist das nicht, sondern eine CPU, die eine ganze Menge Beschaltung benötigt, bis man damit auch nur irgendwas anfangen kann (RAM, ROM, Peripherie, Takterzeugung, Adressdecodierung etc.)." Leider völlig falsch, siehe oben. Ausserdem erkläre mir bitte, wieso der Prozessor 68000 RAM braucht? Komisch, die Platine vor mir hat keins und hat doch mal einwandfrei funktioniert... "Könnte es sein, daß Du vielleicht doch irgendetwas anderes meinst?" Tja, an anderer Stelle hier im Forum gab es einen schönen Spruch, ich denke, Du weißt, was ich meine... *) T. != T-Punkt, also nicht zu verwechseln mit dem phonetisch gleichen Läden eines großen deutschen Telekommunikationsunternehmens
@Oswald: Wie Rufus, d.d.E, schon erwähnte, hat Motorola ihren 68k Core in eine ganze Reihe von Microcontrollern integriert (genauso wie andere Hersteller 8051- oder ARM-Kerne integrieren). Ooops, jetzt habe ich ja 'Motorola', '68k' und 'Controller in einem Atemzug genannt! Ein bekanntes Beispiel ist der 68328, der u.a. auch in den PalmIII-V und vielen Händies werkelt. Die Halbleitersparte von Motorola wurde ausgegliedert und heißt jetzt Freescale. Unter http://www.freescale.com/webapp/sps/site/homepage.jsp?nodeId=0162468rH3YTLC findest du jede Menge Infos. Entwicklungstools gibt es freie wie auch kommerzielle. Wenn du in Google nach 68k, 68000 oder 68328 suchst, wirst du alles finden, was du so brauchst und noch viel mehr. Ein paar gute Infos und Links gibts unter http://members.ozemail.com.au/~davidwilliams/ddl_home.htm Um welchen Controller, CPU oder welches Board handelt es sich denn genau? Gruß, Christian.
@Oswald: Du wirst jetzt vermutlich vor Schreck vom Stuhl fallen, aber daß unter dem Namen "68K" 'ne ganze Menge von Microprozessoren existieren, das ist mir bekannt. Die 68k-Varianten, die tatsächlich als Microcontroller verkauft werden, werden -wie Du selbst aufgezählt hast- nicht unter der Bezeichnung "68k" verkauft. Und Du hast also eine Platine mit einem 68000 drauf, auf der kein RAM ist und die irgendwas sinnvolles macht, außer Wärme zu produzieren? Das ist schön für Dich, und schön für den Prozessor, der dank nicht vorhandenem Stack nur sehr primitive Programme ausführen darf. Wozu ein Prozessor RAM benötigt? Hast Du mir wirklich diese Frage gestellt? Welche der von Dir aufgezählten angeblich von Motorola zur 68K-Familie gerechneten Varianten erfüllt denn Deiner Ansicht nach die Definition eines Controllers (internes RAM, internes ROM, interne Peripherie)? Wenn Du mir schon Falschaussagen unterstellst, dann solltest Du das auch belegen.
Hallo Ich habe mit dem 68332 gearbeitet. Dieser Controller programiert sich sehr gut in Assambler. Es gibt ein sehr gute Bücher von Werner Hilf. Meine Gehversuche habe ich mit dem NF300 absolviert. http://www.elektronik.vhf.de/nf300/nf300.html Zu meiner Zeit hat es mit einem freien C Compiler geharpert. Es gab schon einen GNU Crosscompler, jedoch war ich nicht in der Lage die letzen Anpassungen durchzuführen.
Hi @all, Rufus T.F. hat vollkommen recht. Denn Oswald fragte ursprünglich nach 68k-Prozessoren. Dazu gehören sämtliche Exemplare begonnen bei 68000 bis hin zum 68060. Dies sind unbestreitbar alles Prozessoren. Alles was mehr enthält und damit zu den Controllern gezählt wird, gehört nicht zur 68k-Familie. Dies sind alles Controller mit 68k-Core (und natürlich Peripherie)! Ein kleiner, feiner Unterschied. Ich habe zwar schon eine längere Zeit kein Blick mehr in ein Datenblatt von Freescale geworfen, aber als es noch Motorola war, las man es so in Dokumetationen. Funbirdy
Hi!
Als Compiler kann der gcc eingesetzt werden. Je nach Derivat (z. B.
Coldfire) macht es Sinn einen speziell angepassten gcc zu verwenden.
Nützliche Infos kannst Du z. B. unter www.uclinux.org finden.
Gruß
Dirk
Ich bin an dem Linkerscript gescheitert. Das muss spezifisch für das Board angepasst werden.
@Oswald: Eine Entschuldigung ist angebracht. Nicht Dich wollte ich mit meinem heutigen Beitrag (von etwa halb neun) ansprechen, sondern die Lebensform, die sich "Rufus, das dicke Ei" nennt und um 6:26 wichtiges hier zu posten meinte. Dir sei dennoch die Frage gestellt, was exakt Du mit "diesem Controller" meinst. (Genaue Typenbezeichnung)
Rufus T. F., funbirdy: totaler Schmarrn. Wie man hier sieht: http://www.freescale.com/webapp/sps/site/homepage.jsp?nodeId=0162468rH3YTLC werden unter '68k' zuerst die Mikrocontroller (MC683*) aufgezählt.
Wenn Du die 68K-Familie programmieren willst/mußt, würde ich Dir Assembler empfehlen. Bei einem C-Compiler ist es fast egal, welcher Prozessor/Controller die Befehle ausführt. Die 68Ks (Plural) lassen sich zum einen sehr gut in Assembler programmieren und vermitteln z.B. wegen der vielen Adressierungsarten einen sehr hohen Lerneffekt (Variablen auf Stack, link-unlink, verkettete Listen,...)
Aha. Weil Freescale das jetzt so will, bekommt eine seit 1979 (!) bestehende Bezeichnung urplötzlich eine völlig andere Bedeutung? Klasse. Da entscheidet also die Reihenfolge, in der irgendein Hilfsdödel Texte auf einer Website unterbringt, über die Bedeutung von Begriffen. Also: Leute, die nicht nur auf ein schickes Webdesign hereinfallen, sondern sich schon einige Jahre lang mit Dingen beschäftigen, haben eine andere Vorstellung davon, was "68K" bedeutet, als diese Website. Selbst die Lebensform mit dem eigenartigen Namen zählte zuerst 13 Varianten der 68K-Familie auf, die keine Microcontroller sind.
Keiner! 2000 = 2k(ilo) <sarkasmusan>Ist nur eine Abkürzung, weil es sehr aufwendig ist 2 Zeichen mehr zu tippen<sarkasmusaus> ;-) Funbirdy
Also danke mal für die vielen Antworten. Ich hab damit (und damit die falsche Bezeichnung gewählt) die Mikrocontroller mit 68k-Core gemeint. Also Sorry an alle, dass sowas wegen meiner falschen Bezeichnung rausgekommen ist. Gibt es gute Bücher zu solchen µC's oder auch gute Seiten (speziell in Richtung Programmierung)?? Danke
@Oswald: Gut, daß das jetzt geklärt ist. Die prinzipielle Programmierung in 68K-Assembler dürfte ja von der Tatsache her, ob sie für einen µC oder einem "richtigen" Prozessor stattfindet, sich nicht sonderlich unterscheiden. Über 68K-Assembler dürfte sich auf Grund der hohen Verbreitung dieser Prozessorarchitektur in den 80er Jahren reichlich Sekundärliteratur anfinden (Atari ST, VC Amiga). Allgemeiner gehalten gab es damals im Tewi-Verlag die Bücher "M68000 Familie - Grundlagen und Architektur" ISBN 3-921803-16-0 und "M68000-Familie - Anwendungen und Bausteine" ISBN 3-921803-30-6 von Werner Hilf und Anton Nausch. Von Hilf erschienen noch weitere Bücher im Markt&Technik-Verlag und im Franzis-Verlag. Davon sollte sicherlich irgendwas antiquarisch aufzutreiben sein (www.zvab.de ist möglicherweise eine Anlaufstelle). Die Ansteuerung der Peripherie ist der Punkt, wo sich die Dinge dann zu unterscheiden beginnen, aber bei der 68K-Reihe wird sowieso nur mit "memory mapped I/O" gearbeitet; ob an einer Adresse nun RAM, ROM oder ein Register eines Peripheriebausteines liegt, macht in Bezug auf den Zugriff darauf keinen Unterschied aus. 68k-Assembler sollte einem recht gut "von der Hand gehen", da die Architektur ziemlich orthogonal ist, viele Daten- und Adressregister und leistungsfähige Adressierungsarten zur Verfügung stellt. Es gibt auch eine ucLinux-Portierung für MMU-losen 68K (das war, wenn ich mich recht entsinne, sogar der "Urvater" davon), so daß sowohl die übliche Linux/gcc-Toolchain für diese Prozessorfamilie verfügbar sein dürfte. Viel Erfolg!
Also ich programmiere den 68332 beruflich und halte es fuer ziemlichen Unsinn den in Assembler zu programmieren! Und das nicht weil ich etwas gegen Assembler habe. Man setzt so einen fetten Prozessor ja normalerweise nur ein wenn man auch entsprechend aufwendige Probleme zu loesen hat. Da wuerde ich dann doch dringend zu C raten. Hinzu kommt noch das die Dinge wo Assembler normalerweise seine Qualitaeten entfaltet, genaues Einhalten von Timings, schnelle kurze Interruptroutinen, mehrere Sachen parallel machen ohne den Ueberblick ueber das Timing zu verlieren, dass all dies sehr gut von der eingebauten TPU uebernommen wird. Damit will ich nicht sagen das man die nicht auch in Assembler programmieren kann wenn man denn unbedingt will, aber das ist wirklich einer der Controller wo dies am wenigsten notwendig ist. Und was die Doku angeht, es gibt von Motorala zu den Teilen Datenblaetter und Handbuecher. Ich wuesste wirklich nicht was man sonst noch brauchen sollte. Privat wuerde ich so eine CPU uebrigens nicht nutzen. Und zwar deshalb weil ich nicht glaube das man die mit weniger als vier lagen Multilayer einsetzen kann. Olaf
Ich bin der gleichen Meinung wie Olaf, die 68k Kisten sind schon gute Zugpferde und sind für komplexe Sachen sehr gut geeignet. Solche Sachen sind mit Hochsprachen zu erledigen. Assambler ist gut für Mikrokontroller mit geringen Speicher und Bitschubserei geeignet. Es gibt eine Grenze wo Assembler nicht mehr sinnvoll ist.
@Olaf Ob Sinn oder Unsinn, entscheidend ist, was Mario vor hat. Natürlich verwende auch ich C, um zu Potte zu kommen. Aber mit 68K hat das dann eher wenig zu tun. Die Familie fängt bei 68008 an, der ohne Probleme 2-lagig zu 'layouten' ist. Die neueren Coldfire im BGA sind sicherlich nichts mehr für Bastelarbeiten, aber sehr feine Teile. Bei den 'alten' CPUs würde ich die Ausführungsgeschwindikeit kritisieren, die nicht mehr zeitgemäß sind. Aber im Kern sind sie alle gleich zu programmieren.
"sondern die Lebensform, die sich "Rufus, das dicke Ei" nennt und um 6:26 wichtiges hier zu posten meinte." Kann es sein, Rufus T., daß Du immer dann ausfallend wirst, wenn Dir jemand Paroli bietet und Deine Fehler aufzeigt? Dein Ton hat sich ja in den letzten Wochen in der Tat gemäßigt, aber wenn Du hier von "Lebensform" schreibst, dann zeigt das doch ganz deutlich, daß Dir offensichtlich die Argumente ausgegangen sind. Ist im Übrigen auch ein deutlicher Hinweis auf große Charakterdefizite... "Weil Freescale das jetzt so will, bekommt eine seit 1979 (!) bestehende Bezeichnung urplötzlich eine völlig andere Bedeutung?" So ein Blödsinn. Ich habe hier noch alte Vertriebsunterlagen, in den Motorola höchstselbst die Controller auch als 68K bezeichnet. Die haben den guten Ruf, den der gute alte 68000er begründet hat, ordentlich ausgeschlachtet. Warum auch nicht? "Klasse. Da entscheidet also die Reihenfolge, in der irgendein Hilfsdödel Texte auf einer Website unterbringt, über die Bedeutung von Begriffen." Hmmm, "Lebensform", "Hilfsdödel", da fühlt sich einer aber als etwas Besseres, wie? Ein Psychologe würde wohl einen Minderwertigkeitskomplex im Endstadium diagnostizieren... "Also: Leute, die nicht nur auf ein schickes Webdesign hereinfallen, sondern sich schon einige Jahre lang mit Dingen beschäftigen, haben eine andere Vorstellung davon, was "68K" bedeutet, als diese Website." Tja, das solltest Du in der Tat einmal machen. "Selbst die Lebensform mit dem eigenartigen Namen zählte zuerst 13 Varianten der 68K-Familie auf, die keine Microcontroller sind." Oh, schon wieder...
@Rufus T. Firefly: Jetzt hast Du es mir aber gegeben. Privat läuft es wohl nicht so, was?
Meine Güte, seit ihr kindisch. Tauscht doch Telefonnummern aus, und regelt das privat. Warum hat nur jeder was gegen RTF?
Hallo Ich möchte mich ja nur ungern einmischen, aber diese Streitereien gehen mir auf die nerven. Für so Sachen wie: >>>@Rufus T. Firefly: >>>Jetzt hast Du es mir aber gegeben. Privat läuft es wohl nicht so, >>>was? sollte die IP von "Rufus, das dicke Ei" auf dieser Seite, meiner Meinung nach, gesperrt werden. (wenn das was bringt, wegen wahrscheinlich dynamischer IP???) Sorry für das einmischen und nicht Mikrocontroller bezogene Posting. Damit der Posting nicht ganz sinnlos ist: Ich schreibe zwar (fast) nie Beiträge lese aber täglich das Forum, und finde das (die meisten von) Rufus T. Firefly's Beiträge von sehr hoher Qualität sind. Vielen Dank dafür (auch an alle anderen die Fachliche Beiträge schreiben).
Vielleicht, weil er keine Kritik vertragen kann, aber immer ordentlich draufhaut? Dazu - siehe oben - seine niveaulosen Beschimpfungen...
Nein, dickes Ei, daran liegt es sicher ist. Sein Fehler ist einfach, daß er sich immer wieder auf die ganzen Diskussionen einläßt und oft das letzte Wort haben will. Vielleicht sollte er einfach schwachsinnige Beiträge ignorieren, irgendwann verlieren auch die ganzen Hohlblocks den Spaß an der Sache. Aber ich weiß, es ist manchmal extrem schwer, den Mund zu halten. Man siehts ja an meinem Posting, die Sache geht mich nichts an und trotzdem addiere ich meinen Senf.
P.S.: Mit meinem Beitrag möchte ich niemanden persönlich angreifen! Wer sich dennoch angegriffen fühlt, kann halt keine Kritik vertragen :)
Für den 68000er Mikroprozessor gibt es eine integrierte Entwicklungsumgebung IDE68K (google doch mal!) für Windows 9x (meine ältere Version v1.1 ist Shareware) die C-Code nach 68k-Assembler übersetzen kann und daraus ein Hexfile erzeugt, mit der Möglichkeit dieses über die Serielle Schnittstelle an ein 68000er Prozessorboard zu schicken. Welches Prozessor- bzw. Hardware-Umfeld beim 68000 hierfür benötigt wird, weiss ich momentan nicht. Der Simulator funktioniert aber auch so und schaut ganz nett aus (gibt vermutl. auch neuere Versionen). Der Vorteil, den die Mikrocontroller von Motorola (Freescale) z.B. die 68HC11 gegenüber dem 68000er Prozessor haben ist, dass für das Senden solcher Programme nicht nur eine eingebaute serielle Schnittstelle (das SCI = Serial Communication Interface) im Mikrocontroller vorhanden ist, sondern sie haben zusätzlich noch eine spezielle Boot-Laderoutine, den sog. "special bootstrap modus". Wenn der Controller (68HC11, 68HC908 oder dergleichen) das Programm über die Serielle Schnittstelle empfangen hat wird automatisch ein Reset im Controller ausgelöst und die Abarbeitung des empfangenen Programms begonnen. Diese Eigenschaft des Bausteins macht es besonders einfach den Mikrocontroller für eigene Bastelzwecke einzusetzen, sonst müßte erst einmal ein Monitorprogramm von außen in den Controller eingebracht werden (z.B. über externe Speicherbausteine) , das dann die Kommunikation nach außen ermöglicht. Nebenbei erwähnt, der Assembler-Code für die 32-bittigen 68000er Flagschiffe ist deutlich umfangreicher als der für die 8-bit Controller. Die Befehle wollen z.B. zusätzlich noch Wortbreiten .b .w .l angegeben wissen, was den Überblick nicht gerade vereinfacht, die Interrupt-Verwaltung ist auch deutlich komplizierter, aber das muss jeder selber beurteilen. Wer es sich aussuchen kann sollte besser mit den Mikrocontrollern beginnen. Vielleicht bringt das etwas Klarheit anstatt sich ständig nur mit dem Begriff 68K zu beschäftigen. Gruß Gerd K.
@Gerd Ich muß Dir in vielen Punkten widersprechen. Interruptroutinen beim 68K sind ganz einfach zu programmieren: benötigte Register 'pushen', Programmcode dazu, Register 'popen' und RETI. Der Vektor auf die Routine muß wie bei jedem anderen Prozessor zuvor gesetzt werden. Und wenn man will, kann man die Interrupts mit einer Priorität versehen, oder IO-Bausteine verwenden, die zusätzlich einen Vektor auf die Int-Routine liefern; man muß es aber nicht. Daß man den Befehlen ein .B, .W oder .L dazugeben kann (nicht unbedingt muß) ist doch kein Problem; bei C werden ja auch 'char', 'int' oder 'long' verwendet, um die Größe von Variablen zu deklarieren. Und wenn man es braucht, hat ein 68K noch viel mehr Vorzüge gegenüber den 'popeligen' 8-Bittern, wie z.B. großer linearer Adressraum. Auf Anforderung kann externe Logik (ein anderer Prozessor) den Prozessorbus übernehmen: der 68K schaltet dabei seine Adress-, Daten- und Steuerleitungen passiv. Der Befehl TAS erlaubt es, Prozesse zu synchronisieren. Das alles machen schon die allerersten MC68000er aus den '70er Jahren. Und wenn man den 68000 verstanden hat, greift man heutzutage zu einem Coldfire, der keine Wünsche offen läßt.
"Coldfire, der keine Wünsche offen läßt" Ausser dass man dieser Familie auf Assembler-Ebene die Kompromiss-Natur deutlich anmerkt. Abstammend von dem in 683xx verwendeten Core und noch weitgehend (Subset-) kompatibel, fehlt jedoch manches was 68K angenehm machte und der Befehlssatz wirkt etwas unvollständig und unlogisch. Einige Designfehler mussten daher später wieder korrigiert werden. Dafür sind die Dinger halt einfacher herzustellen. Und von wegen Wünsche offen lassen... beim Preis hätte ich da schon noch welche offen.
Heute morgen sind bei mir zwei Coldfire (5206E 50MHz) und 4 2MB EDO Ram Chips bekommen... das alles gibts im Moment SEHR preiswert bei ebay! Lötbar ist die CPU noch gut, dafür leider auch recht wuchtig (QFP 160). Naja mal sehen wann ich mich dazu aufraffe ein Testboard zu ätzen aber ich denke dieses Bauteil ist für den Preis (um die 3) einen Versuch wert.
@Michael So wie Oswald Mario in seinem ersten Posting fragte kennt er sich wenig bis gar nicht aus, d.h. er ist Anfänger. Solchen Leuten würde ich jedenfalls nicht empfehlen mit einem 68000 oder Nachfolger sein Platinen-Projekt zu beginnen. Es kann schon schwierig genug sein ein vernünftiges Layout für einen einfachen Mikrocontroller auf die Beine zu stellen, das auch dann noch funktioniert wenn eine Störquelle in geringem Abstand auftritt. Die zahlreichen Varianten der verschiedenen Controller machen die Übersicht auch nicht einfacher. Die von dir zu unrecht verächtlich genannten "popligen 8-bitter" genügen völlig für die meisten Steuerungsaufgaben und falls nicht greift man eben zu stärkeren Zugpferden (aber eben nicht mit Kanonen auf Spatzen schießen!). Der Begriff linearer Adressraum ist in diesem Zusammenhang unsinnig bzw. überflüssig, es geht ja hier nicht um x86-Architektur. Der 68HC11 hat auch einen "linearen Adressraum", wenn auch nur 64 kByte. Und lieber Michael, z.B. schon der 16-bittige HC12 ist deutlich komplexer als seine 8-bittigen Urgesteine und das zeichnet sich dann auch in der Programmierung ab. Also bitte nicht den Fragestellern einen 68000er als einfacher gegenüber einem 8-bitter zu verkaufen versuchen. Ich hab auch nur versucht kurz darzustellen wo einer der wesentlichen Unterschiede zwischen Prozessor und Controller aus der Sicht desjenigen liegt, der einen schnellen Erfolg haben möchte. Und ES IST EIN UNTERSCHIED, ob man sich einen Chip mit ein paar wenigen Bauteilen beschafft und mittels serieller PC-Schnittstelle relativ schnell loslegen kann oder ob man sich am Layout, ähnlich des eines Amigas oder Ataries versucht. Den Schlagabtausch um Begriffe halte ich jedenfalls für den Streit um des Kaisers Bart, damit kann man sich höchstens schön seine Zeit verplempern. Grüße Gerd K.
""Werd nämlich ein Projekt mit diesem Controller machen und hab noch keine Erfahrungen damit."" Was immer die Beweggründe sind, er will es machen und ich werde es ihm nicht ausreden, auch wenn es viele Gründe gäbe sich anders zu entscheiden. Von Motorola/Freescale bin ich persönlich abgekommen, da Preise, Lieferzeiten und Ankündigungen von nicht lieferbaren Teilen mehr Fruist als Lust machten. Zur Klarstellung: den 68K habe ich nicht als einfacher als einen 8-Bitter beschrieben und mit 'großem linearen Adressraum' meine ich deutlich mehr als 64K. Ich denke, Mario wird wissen was er macht. Vorher oder nachher :-)
Hallo, also es gehtim speziellen darum, dass ich ein Projekt für eine Firma machen soll, wo die komplette Hardware schon zu Verfügung steht, ich bis jetzt aber noch nichts weiß außer das ein 65k Prozessor/Controller eingesetzt wird. Und ich will mich einfach vorm Kick-Off Meeting einwenig über den Prozessor/Controller und dessen Programmiermöglichkeiten informieren. Und einwenig Erfahrung hab ich schon (8051, 286er, PIC, ATMEGA,...). Aber ihr konntet mir bis jetzt schonmal einen guten Überblick geben und ich bin für weitere Informationen dankbar. Mario
Naja, die 68k sind prinzipiel genauso CPU/Microcontoller wie jeder anderer auch. Ungewoehnlich fuer jedemanden der erstmals darauf trifft ist vielleicht das Businterface. Das unterscheidet sich naemlich von dem was man von anderen CPUs gewohnt ist. Ein anderer Punkt ist die schon erwaehnte TPU in den Microcontrollern auf 68k Basis. Das ist im Prinzip eine zweite kleine relativ doofe CPU, oder ein sehr intelligenter Portbaustein. Das Handbuch allein ueber die TPU ist etwa genauso umfangreich wie das eines ganzen AVRs. Olaf
Was ich vielleicht noch für erwähnenswert halte: Wenn man sich schon mal für 68xxx entschieden hat und dann z.B. den 68332 wegen seiner umfangreichen On-Chip-Peripherie gewählt hat, ist es sehr sinnvoll für die ersten Tests sich ein Board von VHF-Elektronik zu besorgen. Auf den Boards ist das lästigste am Prototypen schon erledigt, nämlich RAM und FLASH hinzudengeln, ohne gleich alle Chipselectleitungen zu verbraten und hinterher lauter Designfehler korrigieren zu müssen. Der Preis ist moderat, wenn auch nicht billig. Weiterhin sollte man auf die Eigenschaften des BDM-Interfaces aufmerksam machen. Mit dieser Schnittstelle kann man ohne den UART des Controllers zu blockieren Software in den angeschlossenen RAM laden, selbigen wieder auslesen, die Ausführung an beliebigen Punkten starten, stoppen, Register modifizieren, Fehler fangen und schrittweise die Codebearbeitung steuern. Das BDM-Kabel für den Parport gibt's fast geschenkt. Der GDB kann zur direkten Steuerung der 683xx-CPU gepatcht werden. Unter Linux brauchts dann noch einen Kernelpatch. Hut zum Gruß, Moritz
Welche guten Entwicklungsumgebungen bzw. C-Compiler gibt es den für derartige Prozessoren/Controller? Mario
Nu, immerhin hat meiner Erinnerung nach der GNU-Compiler auf Suns 68020ern das Licht der Welt erblickt. Ist also gewissermassen grad dafür geschrieben worden.
Hallo Leute, ich verwende den Mc68332 und bin von dem Controller sehr begeistert. Ich programmiere in C und empfehle jedem, wenn er es kann, dies auch zu tun. Bei etwas größeren Programmen ist es doch eine Erleichterung. Aber ich habe auch ein Problem. Mir fehlen IO-Pins. Daher will ich den TP4-Kanal als IO-Pin schalten. Laut Manual geht das auch, aber ich habe es noch nicht geschafft TP4 als digitalen Ein- gang zu schalten. Wer kann mir dabei helfen? Horst
Mehr als im TPU-Handbuch steht, kann ich dir auch nicht schreiben, weil ich das selber nocht nicht gemacht habe. Da steht, dass das Schalten eines TPU-Kanals als diskrekter IO etwa so abläuft. Man programmiert für den TPU-Kanal die Funktion "DIO", das ist beim Maskenset A 0x8 und beim Maskenset G gibt's das nicht. Dann muss man noch den Host Service Request Code 3 absetzen und den Host Sequence Code auf 2 setzen. Man kann sich auch die Transitions zählen lassen, aber das willst du wohl nicht. Wenn das nicht hinhaut, könntest du noch eine Periodendauermessung programmieren, damit kann man auch Input Pins überwachen. Ich kann auch nochmal genauer nachlesen, wenn die Tips nicht ausreichen. Grüße, Moritz
Vielen Dank für die schnelle Antwort. So wie Du es beschreibst, hatte ich auch schon programmiert. Ich wußte nur nicht wie ich das Parameter Ram programmieren sollte. Ich hatte auch Schwierigkeiten im Parameterram den Pin_Level richtig zu interpretieren. Beim Lesen des Pin_Level wird der aktuelle Zustand des Pins in Bit 15 geschrieben. Beim nächsten Lesevorgang wird der vorhergehende Zustand nach Bit 14 verschoben und der aktuelle Zustand in Bit 15 geschrieben. Man muß Bit 15 maskieren, sonst erhält man bei jedem Lesevorgang ein anderes Ergebnis. Unter http://www.freeskale-com/webapp/sps/site/... ist die TPU sehr gut beschrieben. Hier mein Testprogramm in C. #include <stdio.h> #include <target.h> int main(viod) { int hz1; INTERN.tpu.tmcr = 0x2000; INTERN.tpu.cfsr2 |=8: // DIO Funktion INTERN.tpu.c[4].p[0] = 0x0f; // Eingabe INTERN.tpu.cpr1 |=0x200; // mitlere Priorität INTERN.tpu.hsrr1 |=300; // initialisieren INTERN.tpu.hsqr1 |=200; hz1=INTERN.tpu.c[4],p[1] & 0x8000; // Pin_Level printf("%X",hz1); printf("/n"); return 0; }
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.