mc68360 QUICC Wer hat Erfahrungen damit?

Hast du dich auch /buchstabengetreu/ an das Beispiel im QICCS-Manual (7.11.8 SMC UART Example) gehalten?

Hallo, Ich habe Dir in dem .zip File die Assemblerroutinen für den SCC#1 angehängt, die ich vor 30 Jahren geschrieben habe. Vielleicht findest Du da etwas was bei Dir fehlt. Hoffe es hilft.

Gruss, Kurt

@Cartman E. @Kurt M.

Danke Euch beiden, ich schau mir das noch mal in Ruhe an... Das (freescale) Datenblatt, welches ich bei NXP runter laden konnte, hat diverse Fehler, die auch das 30-seitige Error Addendum nicht alle auflöst, (Einige konnte ich selbst korrigieren).

P. O. schrieb:

Ich habe gebrauchte 3,3V Varianten @25MHz (und einem 8-Bit ROM)

Woran sieht man einem 68360 eigentlich die 3,3 V Variante an? Ich habe nur das Motorola Manual, und die Suchmaschinen geben sich zugeknöpft bei dem Thema.

Hier liegen auch noch 4 68360 Boards mit 4 MB Flash, 1 MB RAM, 1 MB Bootrom und einem Custom-IC unbekannter Funktion. Die Boards laufen zumindest bei Versorgung mit 5 V artig los. ☺ Da ihnen ihre /Umgebung/ fehlt, tun sie natürlich noch nichts sinnvolles. Oder ich erkenne den Sinn nicht.

Cartman E. schrieb:

Woran sieht man einem 68360 eigentlich die 3,3 V Variante an?

Am "L" bei MC68360RC25L. Es gibt bei NXP dazu eine Textdatei:

1

ISSUE DATE: 23-Mar-1998   NOTIFICATION #:3519

2

EFFECTIVE DATE: 02-Jul-1998   ISSUING DIVISION:ATX-NETWORK

3

4

TITLE: INTRODUCTION OF REVISION L FOR MC68360 FAMILY (3.3V ONLY)

5

6

Motorola is pleased to announce a new revision for the 3.3V versions of the 68360, 68EN360, and 68MH360 Quad Intergrated Communications Controllers (QUICC).

7

8

Revision L (Rev L) is supported by new mask sets OH84G (68MH360) and 1H84G (68360/68EN360) and provides improved manufacturability for the 3.3V products. This new revision utilizes the same fabrication site and technology as the previously qualified revision K devices, processed on MOS 11's fully qualified 0.55 micron UDR1 technology. Rev L is completely backward compatible with the Rev C.1/E/K devices.

9

10

These new products will be identified by an 'L' suffix at the end of the part number and will also be labeled with mask set 'OH84G' (68MH360) or '1H84G' (68360/68EN360).

Oder ich erkenne den Sinn nicht.

Ich bin absoluter Spätzünder (in anderen Worten: hab selbst kaum Ahnung) und habe den 68360 erst vor ca. 2 Jahren entdeckt, nach dem ich 2020 über den 68302 stolperte o_o;

Außer den Dokumenten bei NXP habe ich auch so gut wie nix gefunden, außer etwas Code, ähnlich Deinem, für einen Linux-Treiber o.ä.

Übrigens scheint der wesentlichste Unterschied (zwischen meinem und Deinem Code) zu sein, dass Du 1995 für den SCC1 am Port das -CTS Signal verwendest. Laut Datenblatt sollte das aber auch ohne gehen.

@Kurt hat mich mit [7.11.8 SMC UART Example] auf den SMC gestupst, der im Unterschied zum SCC, diese Modem Steuersignale gar nicht erst hat. Ich hab mal auf die schnelle von SCC1 auf SMC1 "umgehäckt", es tut sich nun immerhin schon was am SMTXD1(PB6) Pin, aber richtig funktioneren tut's (leider) noch nicht... (vermutlich was mit den TX-Buffern)

Auf meinen Boards ist die 5 V Version in PQFP mit 240 Pins.

Kennst du das schon?

https://community.element14.com/cfs-file/__key/communityserver-wikis-components-files/00-00-00-01-46/1524.Freescale.Application_5F00_Library.zip

Das ist die Software/Treibersammlung zum QUADS360. QUADS360 war die Entwicklungsplattform für den 68360 von Motorola.

Cartman E. schrieb:

Das ist die Software/Treibersammlung zum QUADS360.

Danke. Während ich mit dem C-Code nix anfangen kann, sind ein paar Assembler Beispiele dabei, die sich direkt auf's Datenblatt beziehen. (Unter anderem auch eine Initialisierung - welche ich im Grunde auch schon so hatte.)

Kannst Du sehen, wie auf Deinen Boards der Reset gemacht ist? Ich habe derzeit nur einen Resetgeber mit "push-pull" Ausgang und habe jetzt erst gesehen, dass eben auch [-RESETH] 'aktiv' vom 68360 nach Triggern 20µs (512 Zyklen x 1/25MHz) auf 0V gezogen wird. Das Resetsignal hängt danach aber die restlichen 200ms bei grenzwertigen 0,5V... o_o;

Ich hab jetzt erst mal nur einen Pull-up mit Taste dran und der 68360 started damit nach Spannunganlegen nach ca. 1,5s. Nur ist dies ein betriebssicherer Start? (Ansonsten muss ich mir einen anderen Resetgeber oder einen open-drain-buffer besorgen.)

Kleener Zwischenbericht: SMC1 sendet und empfängt nun, wie gewünscht via jeweilig mehreren Buffer-Diskriptoren. Ein Problem hatte ich mit der Baudrate, weil ich das sog. oversampling übersehen oder nicht in Betracht gezogen hatte.

Danke Euch beiden für Eure Hinweise! ^_^b

P. O. schrieb:

Cartman E. schrieb:

Das ist die Software/Treibersammlung zum QUADS360.

Danke. Während ich mit dem C-Code nix anfangen kann, sind ein paar Assembler Beispiele dabei, die sich direkt auf's Datenblatt beziehen. (Unter anderem auch eine Initialisierung - welche ich im Grunde auch schon so hatte.)

Deinen Post hab ich erst heut gesehn.

Es gubt genug! (GC)C-Compiler die auch 68360 können. Die deLuxe Variante wäre wohl CodeWarrior for 68k.

Kannst Du sehen, wie auf Deinen Boards der Reset gemacht ist? Ich habe derzeit nur einen Resetgeber mit "push-pull" Ausgang und habe jetzt erst gesehen, dass eben auch [-RESETH] 'aktiv' vom 68360 nach Triggern 20µs (512 Zyklen x 1/25MHz) auf 0V gezogen wird. Das Resetsignal hängt danach aber die restlichen 200ms bei grenzwertigen 0,5V... o_o;

Muss ich mal sehen. Allerdings ist auf meinen Boards ja noch ein grosser Custom-IC. Ich fürchte mal, dass der da zuständig ist. Die Boards sind von 68360, RAM, Boot-Flash & Flash sehr sparsam bestückt.

Ich hab jetzt erst mal nur einen Pull-up mit Taste dran und der 68360 started damit nach Spannunganlegen nach ca. 1,5s. Nur ist dies ein betriebssicherer Start? (Ansonsten muss ich mir einen anderen Resetgeber oder einen open-drain-buffer besorgen.)

1,5 s klingt nach sehr gründlich. Reset ist Reset. ☺

Cartman E. schrieb:

Die deLuxe Variante wäre wohl CodeWarrior for 68k.

NXP listet scheinbar nur die späteren Varianten.

#1 Ich hatte den Empfangsbuffer auf 1 byte (ohne idle time-out) verkürzt, weil ich am PC (als Terminal) ein Nummern-Menü (0-9) nutze. Nun hab ich im SMC1 mit jedem Zeichen beim Empfang (regelmäßig!) "overrun" Fehler -_-; Selbst bei 4-byte Buffern mit 1 byte MAXIdle wird das nicht besser.

Das Datenblatt dokumentiert dies gar unter [7.11.7.10.1 Overrun Error.] "NOTE: The SMC UART may occasionally get an overrun when the line is at idle. The user should ignore an overrun error when the line is known to be at idle."

"Ignorieren" kann man die nicht, weil die jeweilig einen Buffer schließen. Ich bearbeite die und filtere die "fehlerlosen" Eingaben, aber es ist trotzdem irgendwie unbefriedigend: Dem 68k-Fanboy in mir bricht das Herz ~~q;