68332 - Erfahrungen?
Ralf A. Eckhardt
Für eine komplexere Ablauf-Steuerungsaufgabe ziehe ich Erwägung, den
68332 einzusetzen. Nun bin ich etwas hellhörig geworden durch
<news:3AB0A79B...@tu-harburg.de> und zaudere, ob es nicht
doch lieber ein größerer AVR werden soll.
Hat jemand über den '332 positive oder negative Erfahrungen mitzuteilen?
Eventuelle "Zicken" oder Hardware-Marotten von dem Teil?
Das, was da ablaufen soll, wäre ungefähr angemessen für einen 68000
mit 16 MHz. Vom '332 erwarte ich eine gewisse Leistungsreserve und
einen kostengünstigeren Aufbau. (z.B. nur ein EPROM statt zwei).
Das Teil soll (inklusive Peripherie) im wesentlichen:
* drei RS232-Schnittstellen (max 56k) verarzten,
* ein bis zwei dutzend i/o-Pins in die Steuerung einbeziehen
* viel rechnen (16/32-Bit integer, kein float, kein 8-Bit)
* rudimentäre Timing-Aufgaben erledigen (ein einziger 1ms-Ticker)
* die ganzen interessanten Timing-Features werden nicht gebraucht.
Falls also jemand gute oder böse Erfahrungen damit machen konnte/mußte:
Vielen Dank im Voraus
und 'nen schönen Gruß;
Ralf.
--
Ralf A. Eckhardt
a.eck...@t-online.de
Hartmut Schaefer
> 68332 einzusetzen. Nun bin ich etwas hellhörig geworden durch
> <news:3AB0A79B...@tu-harburg.de> und zaudere
wenn ich da den richtigen Artikel gelesen habe: Dass jemand seinen 332
kaputtkriegt ist noch kein Grund, am Controller zu zweifeln. Ich
verwende den 332 und den 376 recht haeufig und so schnell gehen die
nicht kaputt, jedenfalls nicht, solange man's nicht drauf anlegt.
> Hat jemand über den '332 positive oder negative Erfahrungen mitzuteilen?
Positiv:
- angenehm in Assembler zu programmieren
- akzeptable Rechenleistung
- ich liebe das BDM Interface, jeder Controller sollte eins haben...
- In der Regel lieferbar
- TPU, falls man sie braucht
- grosse Auswahl an Entwicklungssystemen, Assemblern, Compilern,
Debuggern etc..
- Universelles Businterface mit CS-Generatoren
- gibt es inzwischen mit 25 MHz
Negativ:
- so'n altes Ding koennte schon billiger sein...
- die serielle Schnittstelle ist a) eine zu wenig und hat b) keinen FIFO
- waere schoen, wenn's mal eine TPU gaebe, die mit vollem Prozessortakt
laeuft
- braucht externen Speicher, wenn man nicht die Flash-Version nimmt,
aber der Speicher
reicht sowieso nicht.
- SCI und Systemtakt koennen nicht getrennt werden. Schlimmer noch beim
68376: SCI-,
Sytemtakt und CAN-Takt koennen nicht getrennt werden.
- Systemtakt nur max. 25 MHz :-). Hallo Motorola: Warum gibt es noch
keinen Coldfire
mit TPU???? Haeh???
> Eventuelle "Zicken" oder Hardware-Marotten von dem Teil?
Nein, in der Regel funktioniert er schon. Ist ja auch kein Frischling
mehr und millionenfach im Einsatz.
> Das, was da ablaufen soll, wäre ungefähr angemessen für einen 68000
> mit 16 MHz. Vom '332 erwarte ich eine gewisse Leistungsreserve und
> einen kostengünstigeren Aufbau. (z.B. nur ein EPROM statt zwei).
Der 332 hat gegenueber einem Ur-68k nur den Vorteil der geringfuegig
verbesserten CPU (CPU32), die manche Befehle schneller abarbeitet und
eine 3er bzw auch 2er Buszykuls erlaubt. Die Leistungsreserven liegen
sonst nur in der hoeheren Taktfrequenz und dem schnelleren Buszyklus.
Nimmst Du nur einen 8-Bit Bus, ist dieser Vorteil mehr als futsch.
> Das Teil soll (inklusive Peripherie) im wesentlichen:
> * drei RS232-Schnittstellen (max 56k) verarzten,
d.h. externe serieller Controller. Der SCI wuerde ich nicht mehr als
38400 Baud zumuten.
> * ein bis zwei dutzend i/o-Pins in die Steuerung einbeziehen
Da reichen die Ports des 332 auch nicht. Also externe Latches/Treiber.
> * viel rechnen (16/32-Bit integer, kein float, kein 8-Bit)
Das sollte gehen.
> * rudimentäre Timing-Aufgaben erledigen (ein einziger 1ms-Ticker)
Das macht der PIT auch noch, wenn es nicht exakt 1.000 ms sein muessen.
> * die ganzen interessanten Timing-Features werden nicht gebraucht.
Haeh? Warum dann den 332 nehmen? Dann tut es doch _jeder_ 32/16 Bit
Controller, wenn Du bei 68k bleiben willst, der 331, oder ein Coldfire,
oder C166, oder SuperH oder ...
Gruss
Hartmut
Carsten Pankow
<a.eck...@t-online.de> wrote:
>Für eine komplexere Ablauf-Steuerungsaufgabe ziehe ich Erwägung, den
>68332 einzusetzen. Nun bin ich etwas hellhörig geworden durch
><news:3AB0A79B...@tu-harburg.de> und zaudere, ob es nicht
>doch lieber ein größerer AVR werden soll.
Latchup-Tode können wohl alle Controller sterben.
>Hat jemand über den '332 positive oder negative Erfahrungen mitzuteilen?
>Eventuelle "Zicken" oder Hardware-Marotten von dem Teil?
Hardware ist mit ein wenig Hilfe aus den Motorola-Datenbüchern kein
großes Problem. Es gibt keine hochempfindlichen AD-Eingänge, jedoch
einige Pins, welche bei Reset zur Auswahl von Hardwaremodi multiplexed
sind. Mit BDM leicht zu debuggen bzw. zu programmieren (ext. Flash)
>Das, was da ablaufen soll, wäre ungefähr angemessen für einen 68000
>mit 16 MHz. Vom '332 erwarte ich eine gewisse Leistungsreserve und
>einen kostengünstigeren Aufbau. (z.B. nur ein EPROM statt zwei).
Sollte der 16,78MHz-Typ nicht ausreichen, kann man noch ein wenig
Performance mit dem 20MHZ-Typ gewinnen.
Auf jeden Fall solltest Du 16-bittige Speicher (RAM, Flash) benutzen.
Die 68000-er sind nicht auf 8-bittige Speicherzugrife optimiert.
>Das Teil soll (inklusive Peripherie) im wesentlichen:
> * drei RS232-Schnittstellen (max 56k) verarzten,
Das Riecht nach G-Typ. Der hat als TPU-Funktionen die UART incl.
> * ein bis zwei dutzend i/o-Pins in die Steuerung einbeziehen
> * viel rechnen (16/32-Bit integer, kein float, kein 8-Bit)
hoffentlich reicht das interne 2kByte-Ram
> * rudimentäre Timing-Aufgaben erledigen (ein einziger 1ms-Ticker)
PIT!
Olaf Kaluza
>68332 einzusetzen. Nun bin ich etwas hellhörig geworden durch
><news:3AB0A79B...@tu-harburg.de> und zaudere, ob es nicht
>doch lieber ein größerer AVR werden soll.
Hm..was steht denn da so boeses?
>Hat jemand über den '332 positive oder negative Erfahrungen mitzuteilen?
>Eventuelle "Zicken" oder Hardware-Marotten von dem Teil?
Ich programmie da jetzt schon seit einem Jahr eine ziemlich
unfangreiche Steuerung drauf und bin sehr zufrieden.
>Das Teil soll (inklusive Peripherie) im wesentlichen:
> * drei RS232-Schnittstellen (max 56k) verarzten,
> * ein bis zwei dutzend i/o-Pins in die Steuerung einbeziehen
> * viel rechnen (16/32-Bit integer, kein float, kein 8-Bit)
> * rudimentäre Timing-Aufgaben erledigen (ein einziger 1ms-Ticker)
> * die ganzen interessanten Timing-Features werden nicht gebraucht.
Also ich habe 5x RS232 allerdings nur 9600B, dafuer aber noch 320x200
GrafikLCD. Der Rest entspricht so deiner Vorgabe. Ich habe das Dingen
mit 16MHz laufen, konnte alles Problemlos in C programmieren und die
ganz wenigen Probleme die bisher auftauchten liessen sich alle auf
meine Unfaehigkeit zurueckfuehren und waren daher loesbar. :)
Mit anderen Worten ich kann den Prozessor empfehlen. Konkret habe ich
uebrigens einen MEGA332 vom Elektronikladen mit C-Compiler und
Debugger. Damit kann man schon ganz entspannt arbeiten, besonders der
Debugger auf Sourcecodeebene ist schon eine tolle Sache.
Olaf
--
D.i.e.s.S. (K.)
Ralf A. Eckhardt
> [...] Es gibt keine hochempfindlichen AD-Eingänge, jedoch einige Pins,
> welche bei Reset zur Auswahl von Hardwaremodi multiplexed sind.
Warum das Muxen bei einem 144-Pin "Dackelbein-Gehäuse" sein muß, ist mir
noch immer nicht vollständig klar, aber Motorola macht ja klare Angaben,
wie das zu beschalten ist. Ich dachte u.a. auch an Timing-"Zicken", wie
es anno-dunnemal der 8255 gehabt hat, je nachdem ob von Intel, NEC,
oder...
> Sollte der 16,78MHz-Typ nicht ausreichen, kann man noch ein wenig
> Performance mit dem 20MHZ-Typ gewinnen.
Ich dachte letztlich an 25MHz. (wenn-schon, denn schon...)
>> * viel rechnen (16/32-Bit integer, kein float, kein 8-Bit)
> hoffentlich reicht das interne 2kByte-Ram
Nö, das reicht ganz sicher nicht. Das wird 128k x16 RAM oder mehr
werden. Da paßt dann auch gleich der Programmcode mit rein.
> Auf jeden Fall solltest Du 16-bittige Speicher (RAM, Flash) benutzen.
> Die 68000-er sind nicht auf 8-bittige Speicherzugrife optimiert.
Yep. Außerdem: die zu bearbeitenden Datenstrukturen sind fast nur
16/32-Bit ints, also ist 16-Bit auch die natürliche Größe für's RAM.
8-Bit wollte ich nur zum "booten" vom EPROM benutzen.
>> * drei RS232-Schnittstellen (max 56k) verarzten,
> Das Riecht nach G-Typ. Der hat als TPU-Funktionen die UART incl.
Hm... kann der die Funktionalität von externen UARTS mit FIFO
nachbilden?
>> * rudimentäre Timing-Aufgaben erledigen (ein einziger 1ms-Ticker)
> PIT!
^^^
Hilf mir etwas auf die Sprünge: "Peripheral+Io+Timer", oder wer?
Ich war der Meinung, der 332 könnte sich das durch seine internen
Timer-Features selbst basteln...
<Morgen-noch-mal-das-Datenblatt-GANZ-genau-lesen>
Vielen Dank für die Tips und
Ralf A. Eckhardt
[eine hilfreiche Evaluation des '332]
Erstmal vielen Dank für die Mühe!
> Der 332 hat gegenueber einem Ur-68k nur den Vorteil der geringfuegig
> verbesserten CPU (CPU32), die manche Befehle schneller abarbeitet und
> eine 3er bzw auch 2er Buszykuls erlaubt. Die Leistungsreserven liegen
> sonst nur in der hoeheren Taktfrequenz und dem schnelleren Buszyklus.
Ich habe die Beschreibung vom Entwicklungs-Kit "Scotty-332" von NTW
(Elektronikladen) vor mir liegen und die behaupten, das ganze sei
gegenüber 68000 (8MHz Vers.?) um einen Faktor 6 schneller.
Sonst hätte ich auch gleich 'nen 68000 genommen...
> Nimmst Du nur einen 8-Bit Bus, ist dieser Vorteil mehr als futsch.
Mein Ansatz: Booten vom 8-Bit EPROM, dann alles vom 16-Bit RAM.
Geht doch hoffentlich, oder habe ich das Manual flsach interpretiert?
> Haeh? Warum dann den 332 nehmen? Dann tut es doch _jeder_ 32/16 Bit
> Controller, wenn Du bei 68k bleiben willst, der 331, oder ein Coldfire,
> oder C166, oder SuperH oder ...
Da hast Du völlig recht. Der '331 täte es auch, ist aber /noch/ teurer
als der '332 :-(( Im Grunde suche ich ein 68k-Derivat, welches in der
Leistung einem 16MHz-68000 vergleichbar ist (vielleicht etwas
schneller...) und gleichzeitig ein einfaches Interfacing zur Peripherie
ermöglicht. 68020 scheint mir schon eine Nummer zu wuchtig.
Wenn es da allerdings was ganz anderes (auch nicht-68k) gibt, was viel
geschickter ist... ich lasse mich da gern noch in meiner Entscheidung
beeinflussen; deswegen habe ich den Thread schließlich angefangen. :o)
ööh...Coldfire?
Ralf A. Eckhardt
> Hm..was steht denn da so boeses?
Das das Teil ge-latch-up'ed wurde. Und ich fragte mich, ob es
vielleicht /besonders/ anfällig dafür sei. Scheint den anderen
Antworten zufolge aber eher nicht so zu sein.
> Ich programmie da jetzt schon seit einem Jahr eine ziemlich
> unfangreiche Steuerung drauf und bin sehr zufrieden.
Das klingt gut!
> Also ich habe 5x RS232 allerdings nur 9600B
On Chip(??) oder mit Peripherie? Bislang bin ich davon ausgegangen, daß
ich bei 56kB um richtige[tm] SIOs mit FIFO wohl nicht herumkommen
werde...
> Konkret habe ich uebrigens einen MEGA332 vom Elektronikladen mit
> C-Compiler und Debugger. Damit kann man schon ganz entspannt [...]
Fast genau dasselbe schwebt mir auch vor. Allerdings eine Nummer
kleiner mit dem "Scotty-332" und dann noch Peripherie dazugestrickt.
Die Doku dazu macht auf mich einen ganz hervörragenden Eindruck.
Schon mal Danke für das 'feedback' und
Martin Müller
Olaf Kaluza schrieb:
> Hm..was steht denn da so boeses?
Stimmt, bisher habe ich auch nur positive Erfahrungen gesammelt...
> Mit anderen Worten ich kann den Prozessor empfehlen. Konkret habe ich
> uebrigens einen MEGA332 vom Elektronikladen mit C-Compiler und
> Debugger. Damit kann man schon ganz entspannt arbeiten, besonders der
> Debugger auf Sourcecodeebene ist schon eine tolle Sache.
Aha, das wäre für mich evtl. auch interessant. In der Produktbeschreibung
steht aber nix von Debugger. Kannst Du noch mal etwas genauer beschreiben, ob
der dabei ist und wie er funktioniert?
Danke,
Martin
Martin Schneider
Martin Müller schrieb:
<..>
> > Mit anderen Worten ich kann den Prozessor empfehlen. Konkret habe ich
> > uebrigens einen MEGA332 vom Elektronikladen mit C-Compiler und
> > Debugger. Damit kann man schon ganz entspannt arbeiten, besonders der
> > Debugger auf Sourcecodeebene ist schon eine tolle Sache.
Alternativ (d.h., ich kenne den Compiler nicht: ECO-C?) sollte immer
die GNU-C variante incl. Debugger gehen. Als Crossumgebung für Windows
oder Linux.
>
> Aha, das wäre für mich evtl. auch interessant. In der Produktbeschreibung
> steht aber nix von Debugger. Kannst Du noch mal etwas genauer beschreiben, ob
> der dabei ist und wie er funktioniert?
In der CPU ist ein Background-Debug-Interface eingebaut (BDM32), daß
eine
vollständige Beeinflussung aller Register und CPU Teile ermöglicht
(etwa wie ein JTAG-Interface), ohne Mitwirkung einer Software im Target.
Das ganze besteht aus einem 10pol. Anschluß, einem entsprechenden
Adapter
(Freewareschaltung verfügbar) und der Debugsoftware: Freeware von
Motorola,
angepaßter GNU-Debugger oder was käufliches.
Das Teil kann von einfacher Grundeinstellung einzelner Register bis zur
kompletten Firmware-Flashprogrammierung eingesetzt werden...
> Danke,
> Martin
Ahoi, Martin
Martin Schneider
Ich habe ein bißchen Erfahrungen mit dem '332 in Motor-Controllern.
"Ralf A. Eckhardt" schrieb:
>
<..>
> wie das zu beschalten ist. Ich dachte u.a. auch an Timing-"Zicken", wie
> es anno-dunnemal der 8255 gehabt hat, je nachdem ob von Intel, NEC,
> oder...
Kenn' ich nicht. Das Datenblatt von Motorola ist da ziemlich gut.
>
> > Sollte der 16,78MHz-Typ nicht ausreichen, kann man noch ein wenig
> > Performance mit dem 20MHZ-Typ gewinnen.
>
> Ich dachte letztlich an 25MHz. (wenn-schon, denn schon...)
Für Basteleinsatz: die Taktfrequenz wird bei Verwendung eines
Uhrenquarzes (32 kHz) mit der PLL eingestellt:
Ich habe meine Prototypen (16MHz-spec.) schon 1994 mit 32 MHz laufen
lassen... Allerdings ist die Umgebungstemperatur dann auf max 40 Grad
beschränkt, darüber gibt's häufiger Absturz.
<..>
> >> * drei RS232-Schnittstellen (max 56k) verarzten,
> > Das Riecht nach G-Typ. Der hat als TPU-Funktionen die UART incl.
> Hm... kann der die Funktionalität von externen UARTS mit FIFO
> nachbilden?
UART ja, FIFO nein (in der eingebauten Variante). Evtl. kann man das
selbst produzieren, ist aber nicht ganz trivial. Ob die TPU drei
schnelle Schnittstellen behandeln kann, hängt stark von der
Auslastung ab, 56k eher nicht.
>
> >> * rudimentäre Timing-Aufgaben erledigen (ein einziger 1ms-Ticker)
> > PIT!
> ^^^
> Hilf mir etwas auf die Sprünge: "Peripheral+Io+Timer", oder wer?
> Ich war der Meinung, der 332 könnte sich das durch seine internen
> Timer-Features selbst basteln...
Genau: "Periodic Interrupt Timer", damit erzeugt man problemlos
einen internen Takt aus der externen Frequenz.
Allerdings ist der Teilerfaktor nicht beliebig wählbar, in meiner
Applikation (32kHz Uhrenquarz->PLL->15.991 MHz) habe ich 976µs
erzeugt (1s / 1024).
> <Morgen-noch-mal-das-Datenblatt-GANZ-genau-lesen>
>
> Vielen Dank für die Tips und
> 'nen schönen Gruß;
> Ralf.
>
Ahoi, Martin
Olaf Kaluza
>> Also ich habe 5x RS232 allerdings nur 9600B
>On Chip(??) oder mit Peripherie?
Einmal OnBoard und vier Stueck extern als UART.
>Bislang bin ich davon ausgegangen, daß
>ich bei 56kB um richtige[tm] SIOs mit FIFO wohl nicht herumkommen
>werde...
Das wuerde ich auch so sehen. Besonders wenn du auch noch mal was
anderes machen moechtest als nur auf die Schnittstelle zu schauen.
Es gibt wohl auch eine Version wo der eingebaute Zusatzprotz als UART
arbeitet aber ich glaube dem waren da auch sehr enge Grenzen
gesetzt. Die normalen koennen das aber nicht.
Aber die TPU ist auch eine tolle Sache, sowas sollte jeder Protz haben.
>> Konkret habe ich uebrigens einen MEGA332 vom Elektronikladen mit
>> C-Compiler und Debugger. Damit kann man schon ganz entspannt [...]
>Fast genau dasselbe schwebt mir auch vor. Allerdings eine Nummer
>kleiner mit dem "Scotty-332" und dann noch Peripherie dazugestrickt.
>Die Doku dazu macht auf mich einen ganz hervörragenden Eindruck.
Naja, die Doku besteht zu 80% aus abdrucken von GNU-Dokus die man eh
schon kennt. Aber ich will mich nicht beschweren. Bisher hat die Doku
noch jede Frage beantwortet und als sie es einmal doch nicht getan hat
und auch das nur weil ich die Stelle im Handbuch ueberlesen hatte, da
hat mir der Hersteller innerhalb eines Tages auf eine Email
geantwortet und mir die Seite im Handbuch genannt die ich uebersehen
hatte. .-)
Ich hab den Scotty jetzt nicht im Kopf, aber wenn es dafuer ein
BDM-Interface gibt und du die Kohle hast dann wuerd ich mir das
goennen. Wenn du den Scotty mit kommerziellem Hintergrund kaufst dann
wuerde ich da keinesfalls drauf verzichten. Die 1kDM Zusatzkosten hast
du durch Zeitersparnis beim debuggen sehr schnell wieder drin.
Auf die Windowsoberflaeche habe ich aber verzichtet. Ein jed reicht
mir. Ausserdem scheint mir das recht viel Kohle fuer dieses
zweifelhafte Vergnuegen dieser verzweifelten Grafikoberflaeche zu
sein.
Olaf
--
D.i.e.s.S. (K.)
Olaf Kaluza
>> Sollte der 16,78MHz-Typ nicht ausreichen, kann man noch ein wenig
>> Performance mit dem 20MHZ-Typ gewinnen.
>Ich dachte letztlich an 25MHz. (wenn-schon, denn schon...)
Also ich loese meine Probleme immer mit dem zweitschnellsten
Prozessor. Dann hat man naemlich Reserven wenn man spaeter feststellt
das es doch knapp wird. .-)
>>> * drei RS232-Schnittstellen (max 56k) verarzten,
>> Das Riecht nach G-Typ. Der hat als TPU-Funktionen die UART incl.
>Hm... kann der die Funktionalität von externen UARTS mit FIFO
>nachbilden?
Ich hab das Handbuch in der Firma und kann jetzt nicht nachschauen,
aber ich glaube nicht das er so fix ist wie du das brauchst. Ich meine
es waren 8x RS232 mit 9600B als Obergrenze drin. Aber ich kann mich da
jetzt vertuen.
><Morgen-noch-mal-das-Datenblatt-GANZ-genau-lesen>
Blatt? Also die Buecher muss man mehr als einmal gelesen haben....
Olaf
--
D.i.e.s.S. (K.)
Ralf A. Eckhardt
>> <Morgen-noch-mal-das-Datenblatt-GANZ-genau-lesen>
>
> Blatt? Also die Buecher muss man mehr als einmal gelesen haben....
Ok, war etwas untertrieben;-) Inzwischen überfüllen die ausgedruckten
PDFs einen ganzen 80mm-Ordner. Gottseidank kann ich das meiste überfliegen,
weil das doch noch recht nah am 68000/68020 scheint. Ich habe die bitterböse
Vorahnung, daß sich diese Flapsigkeit früher oder später rächen wird...
Macht aber alles einen sehr hautfreundlichen Eindruck.
Olaf Kaluza schrieb in <GAII2...@criseis.ruhr.de>:
>> Die Doku dazu macht auf mich einen ganz hervörragenden Eindruck.
> Bisher hat die Doku noch jede Frage beantwortet und [...] da
> hat mir der Hersteller innerhalb eines Tages auf eine Email [...]
Jo. Genau diese Eigenschaften meinte ich auch. Das erleichtert den
Tag ungemein und ist leider wohl nicht selbstverständlich.
> aber wenn es dafuer ein BDM-Interface gibt [...] dann wuerd ich mir das
> goennen. Die 1kDM Zusatzkosten hast du durch Zeitersparnis [...]
Ack. Ist aber IIRC nur knapp die Hälfte an Zusatzkosten (Dos-Version),
inclusive Compiler, Debuger, Flash, Entwicklungsumgebung, ...
Kommt auf jeden Fall ins Einkaufskörbchen. :o)
Ich befürchte, daß ich den eigentlich interessanten Teil (TPU) erstmal
nach hinten schieben muß, weil ich ohnehin nur wenig Zeit habe.
Mit externen SIOs (incl. FIFO) kann ich wenigstens im Vorwege abschätzen,
daß die Sache mit Sicherheit[tm] funktionieren wird.
Ich habe läuten gehört, daß es da spezielle TPU-Assembler geben soll.
Ich werde mich mal auf die Suche begeben.
BTW: Weiß jemand den Grund, warum es den 332 in zwei verschiedenen
Gehäuseformen (136/144-pin) gibt? Beim 144er sind, soweit ich das
überblickt habe, die überzähligen Pins einfach nur n/c.
Ralf A. Eckhardt
>> [Zicken vom 8255]
> Kenn' ich nicht. Das Datenblatt von Motorola ist da ziemlich gut.
Ack. Den Eindruck habe ich schon von Motorola seit den 6809-Tagen.
> Für Basteleinsatz: [...] Ich habe meine Prototypen (16MHz-spec.)
> schon 1994 mit 32 MHz laufen lassen... Allerdings ist die
> Umgebungstemperatur dann auf max 40 Grad beschränkt [...]
Oh, no-no... isnogud... Das kann/wird böse[tm] enden. <bin-feige>
Zumindestens am Anfang möchte ich gern zwischen Fehlern unterscheiden
können, die aus meiner Hardware und aus meiner Software herrühren.
Da will ich ganz bestimmt kein möglicherweise erratisches Verhalten
des Prozessors im Hinterkopf behalten müssen.
Aber immerhin: Es spricht für die Zuverlässigkeit der '322, wenn
die solche Reserven in den Specs haben! Ist beruhigend.
> Genau: "Periodic Interrupt Timer", damit erzeugt man problemlos
> einen internen Takt aus der externen Frequenz.
Das spart wieder einen Stückchen externe Logik :o)
Olaf Kaluza
>Aha, das wäre für mich evtl. auch interessant. In der Produktbeschreibung
>steht aber nix von Debugger. Kannst Du noch mal etwas genauer beschreiben, ob
>der dabei ist und wie er funktioniert?
Den muss man extra kaufen. Lag IMHO so bei 1kDM. Kann aber sein das es
da noch Unterschiede gab ob mit BDM oder nur ueber RS232. Das steht
aber im Katalog vom Elektronikladen. (liegt in der Firma)
Bei dem Debugger handelt es sich um den gdb den ihr vermutlich alle
von Linux her kennt. <BG> So wie es sich auch bei dem Compiler um den
gcc handelt.
Damit ist natuerlich klar das alles leistungsfaehig ist und perfekt
funktioniert. .-)
Du kannst mit dem Debugger das laufende Programm jederzeit anhalten
und dir die SOURCECODE-Zeile anschauen wo du bist. Du kannst
natuerlich Breakpoints setzen, du kannst einzelne Sourcecodezeilen
ausfuehren, du kannt die Variableninhalte anschauen und auch in
Abhaengigkeit von Variableninhalten bestimmte Dinge durchfuehren
lassen. Letzeres habe ich aber noch nicht probiert, soll aber die
Programmausfuehrung verlangsamen.
Die einzige Frage die da noch auftaucht, ob das wirklich alles so
teuer sein muss wenn man bedenkt das 90% der Soft GNU
sind. Andererseits gibt es sicherlich Entwicklungssysteme die teurer
und schlechter sind.
Bisher habe ich nur ein einziges Problem feststellen koennen und das
liegt, wenn wundert es, mal wieder bei Microsoft. Der Compiler laeuft,
wenn man nicht extra fuer +=1kDM die WinOberflaeche mitkauft unter
DOS. Und DOS kommt leider nicht mit sehr langen Kommandozeilen
klar. Wenn man nun ein ordentlicher PRogrammierer ist der das Programm
in sinnvoll grosse Teilstuecke aufteilt, bei mir so 30 einzelne Files,
so tritt bei DOS7.0 beim linken das Problem auf das die Zeile zu lang
wird und DOS darauf reagiert indem es einfach eine neue Shell startet
und das Kommando vergisst.
Ich habe das Problem dann geloesst indem ich eine Libary erzeugt habe
die ich dann nur einmal am Stueck dabeilinken muss. (natuerlich alles
automatisch im Makefile)
Insgesammt ist mein Programm um die 10000Zeilen gross, betreut 5
RS232, einen GrafikLCD mit kompletter Oberflaeche, ein Hitachi
Standard-LCD, I2C-Bus, einen recht aufwendigen Timerinterrupt der
Dutzende von Dingen erledigt, FolienTastatur, eine MMC-Card am SPI,
und ich bin mit dem System sehr zufrieden. Bis auf die schon erwaehnte
Kleinigkeit wo ich zu bloed war das Handbuch richtig zu lesen und die
Sache mit der Dos-Kommandozeile gab es niemals ernste Probleme. Ich
kann es also empfehlen.
Olaf
--
D.i.e.s.S. (K.)
Martin Müller
Olaf Kaluza schrieb:
> [...]
danke für die Beschreibung
> Insgesammt ist mein Programm um die 10000Zeilen gross, betreut 5
> RS232, einen GrafikLCD mit kompletter Oberflaeche, ein Hitachi
> Standard-LCD, I2C-Bus, einen recht aufwendigen Timerinterrupt der
> Dutzende von Dingen erledigt, FolienTastatur, eine MMC-Card am SPI,
Hui, das versuche ich auch seit einiger Zeit hinzukriegen (leider vergeblich...)
Die MMC antwortet auf meine Initialisierung ziemlich willkürlich. Wenn Deine
Anwendung nicht copyright-geschützt ist, würde ich mich freuen, bei dem
MMC-Interface ein bißchen spicken zu dürfen (gerne auch per PM).
Schönen Abend wünscht,
Martin Müller
Olaf Kaluza
>Aber immerhin: Es spricht für die Zuverlässigkeit der '322, wenn
>die solche Reserven in den Specs haben! Ist beruhigend.
Naja vielleicht kannst du ja auch einen Kuehler draufpappen. Ich meine
ist ja bei Intel mittlerweile Standard und sollte doch dann eigentlich
auch bei Motorolla funktionieren.
Ich wollte uebrigens immer mal so zum Spass ausprobieren wie stark man
eigentlich einen MCS51 z.B 89C2051 uebertakten kann. Bin ich aber noch
nicht zu gekommen....
Aber eigentlich bin ich bis jetzt noch nie an Grenzen gestossen was
Geschwindigkeit angeht. Manchmal habe ich den Eindruck ohne Windows
und ohne Spiele, also Computer nur zum zuverlaessigen Arbeiten<g>, und
wir haetten heute noch alle einen 8086. :-)
Z.B hatte ich bei der Ansteuerung meines Grafikdisplays (320x200) am
332 ein paar Probleme damit das mir der Bildaufbau etwas langsam
war. Das lag aber nicht am Prozessor sondern daran das man dem
Grafikdisplay die Daten einfach nicht schneller reinschubsen
konnte. Liess sich dann durch etwas mehr Gehirnschmalz an der
richtigen stelle (nur im Display updaten was sich wirklich
aendert) hinbiegen.
Olaf
--
D.i.e.s.S. (K.)
Ralf A. Eckhardt
> Aber eigentlich bin ich bis jetzt noch nie an Grenzen gestossen was
> Geschwindigkeit angeht. Manchmal habe ich den Eindruck ohne Windows
> und ohne Spiele, also Computer nur zum zuverlaessigen Arbeiten<g>, und
> wir haetten heute noch alle einen 8086. :-)
Naja... mein TeX kann 100 Seiten auf'm P2 schon um einiges schneller
übersetzen, als auf 'ner V20... Bei W**d weiß ich das nicht aus eigener
Anschauung, aber ich höre auch die Kollegen fluchen, die nen P3 haben.
Ich stimme Dir zu: Textverarbeitung, Assembler und sowas geht
fantastisch sogar auf ner alten Z80. Auf irgendeiner Hannover-Messe
wurde mir sowas mal als professionelles High-End-Gerät verkauft.
Damals[tm]...
Aber wenn ich bleistiftsweise Echtzeit-Bildanalyse betreibe (oder auch
nur nen C++-Compiler laufen lasse), dann bin ich eigentlich froh, daß
Billyboy und die Spiele einen gewissen Bedarf an leistungsgesteigerter
Hardware geweckt haben :-)
Was den '332 angeht, der kommt hier ins Spiel, /weil/ wir mit
nem '51er AVR-Konzept ganz deutlich an Grenzen gestoßen sind.
'nen schönen Gruß;
Ralf.
--
"Software von Gestern für die Hardware von Morgen!"
(unbekannter, von langen Kaffeepausen genervter M$-Benutzer)
Martin Schneider
"Ralf A. Eckhardt" schrieb:
>
<..>
> Ich habe läuten gehört, daß es da spezielle TPU-Assembler geben soll.
> Ich werde mich mal auf die Suche begeben.
Ja, gibt es. Wenn du nicht fündig wirst, frag mich mal per PM,
ich grabe dann in meiner Wühlkiste mal nach. Ist allerdings
nicht ganz trivial, die TPU.
Ahoi, Martin
Hartmut Schaefer
> Ich habe die Beschreibung vom Entwicklungs-Kit "Scotty-332" von NTW
> (Elektronikladen) vor mir liegen und die behaupten, das ganze sei
> gegenüber 68000 (8MHz Vers.?) um einen Faktor 6 schneller.
> Sonst hätte ich auch gleich 'nen 68000 genommen...
hatte der alte Scotty nicht eine 68008-CPU? Dann stimmt der Faktor 6 bei
16-Bit Busbreite und mindestens doppelter Taktfrequenz in etwa.
Gegenueber einer 68000 CPU glaube ich das nicht ganz.
> Mein Ansatz: Booten vom 8-Bit EPROM, dann alles vom 16-Bit RAM.
> Geht doch hoffentlich, oder habe ich das Manual flsach interpretiert?
Das geht. Musst beim Initialisieren eben alles 'rueberkopieren. Wenn Du
hinterher auf das EPROM verzichten kannst, kannst Du dann das RAM auf
den Speicherbereich des EPROMs setzen. Wenn nicht, musst Du daran
denken, dass sich durch das Kopieren die absoluten Adressen verschieben.
Daher muss dann alles mit relativen Adressen programmiert werden. Ist
beim CPU32 kein Problem, muss aber gemacht werden, bzw. man muss des dem
Compiler beibringen. Oder beim Brennen des EPROMs zwei verschiedene
Speicherbereiche zusammenkopieren oder...
> schneller...) und gleichzeitig ein einfaches Interfacing zur Peripherie
> ermöglicht. 68020 scheint mir schon eine Nummer zu wuchtig.
Dann ist ist der 332 schon ok. Den 68020 kann ich dann nicht empfehlen.
> ööh...Coldfire?
Ist auch von Motorola, und im wesentlichen kompatibel zum 68k Assembler.
Leider sind einige DIV und MUL Befehle wieder 'rausgeflogen, die die
CPU32 gegenueber der 68k-CPU mehr drin hatte, aber damit kann man
zurechtkommen.
Der grosse Vorteil ist die deutlich hoehere Rechenleistung bei
Takfrequenzen bis zu 160 MHz. Zur Zeit gibt es leider nur Varianten ohne
TPU, daher habe ich bisher noch keinen eingesetzt, aber wenn Du mehr
Rechenleistung brauchst, solltest Du die Datenblaetter mal ansehen.
Allerdings werden natuerlich die Anforderungen an die
Speicherzugriffsgeschwindigkeit hoeher, so richtig low cost wird das
dann nicht mehr.
Siehe auch:
http://e-www.motorola.com/webapp/sps/prod_cat/sel_guide.jsp?catId=M9
Gruss
Hartmut
Ralf A. Eckhardt
> hatte der alte Scotty nicht eine 68008-CPU? Dann stimmt der Faktor 6 bei
> 16-Bit Busbreite und mindestens doppelter Taktfrequenz in etwa.
> Gegenueber einer 68000 CPU glaube ich das nicht ganz.
Der ganz alte. Inzwischen hat der 'alte' Scotty08 eine 68EC000.
Zum Scotty332 schreibt NTW wörtlich:
|
| [...] im Vergleich zur 'gewöhnlichen' 68000er CPU [...] ergibt dies
| eine Leistungssteigerung, die so etwa beim Faktor sechs liegt."
|
Hm...da werde ich wohl doch mal Zyklen zählen müssen :-)
> Daher muss dann alles mit relativen Adressen programmiert werden.
Nönö, das wird gleich für die Ziel-Adresslage compiliert. Hat sich
bisher auch beim Booten von 68060ern von PCMCIA-SRAMS bewährt.
[coldfire]
> Takfrequenzen bis zu 160 MHz.
Ui, sieht nach High-End-Controllern[tm] aus... Ich suche eher
MID-Price und /gut und zuverlässig verfügbar/ ...
Aber ich werd's mal im Auge behalten.
Auf jeden Fall: Danke für die Hinweise und
'nen schönen Gruß;
Ralf.
Aguja
->68332 einzusetzen. Nun bin ich etwas hellhörig geworden durch
-><news:3AB0A79B...@tu-harburg.de> und zaudere, ob es nicht
->doch lieber ein größerer AVR werden soll.
Ich habe vor ein paar Wochen durch ein 'ungünstiges' Schaltnetzteil mehrere
PIC 16F873 und ein paar AT 90S2313 gekillt - das wird jetzt wohl ausschlag-
gebend dafür sein, das die gesamte Erdbevölkerung diese Chips nicht mehr
anfasst...
->Hat jemand über den '332 positive oder negative Erfahrungen mitzuteilen?
->Eventuelle "Zicken" oder Hardware-Marotten von dem Teil?
Also mit den 68k-Motorolas (68000, Dragonball) habe ich gute Erfahrungen
gemacht - einfach zu programmieren, einfach anzuschließen, zuverlässig -
nur eben nicht ganz so einfach zu bekommen und nicht ganz so flott..
cu,
Aguja
-->> This email-address expires 04-01-2001 ! (Spamprotection) <<--
*** www.PROuC.de >>> Free AVR-, PIC- & 8051-Programmers, Apps & Tips ***
Ralf A. Eckhardt
[Anfrage zu Erfahrungen mit 68332]
Vielen Dank an Alle für die zahlreichen Rückmeldungen und
hilfreichen Tips - auch per PM.
Zusammenfassend gibt es (wie vermutlich zu den AVRs auch)
- ausschließlich positive Reaktionen
(also niemanden, der über 332 flucht, wie andere Leute (ich auch) über M$)
- viele hilfsbereite Leute, die viel Erfahrung mit dem '332 haben
- Supportsoftware in großer Verfügbarkeit
- kaum Lieferschwierigkeiten
Das hat geholfen!
'nen schönen Gruß;
Ralf.