IDMA für IDE

[DBoxBaer]

Moin!

Ich werfe hier mal für die Experten ein Thema in den Raum, an
dem ich schon ein paarmal überlegt habe, ob das am Ende was
bringt. Vielleicht kennt sich ja jemand damit aus und kann
was beitragen.

Vorher vielleicht ein paar Infos, wie das IDE Interface bisher
funktioniert (darf auch gerne, (nach Überarbeitung...) ins Wiki
gestellt werden...)

Das IDE System besteht bekanntlich aus einem 16 Bit Daten-Bus und
ein paar Adressleitungen. Über diese kann man ein paar Register
in der Platte ansprechen. Die meisten Register sind dabei sogar
nur 8 Bit breit, bis auf das Datenregister, das 16 Bit enthält.
Zugriffe auf die 8 Bit Register sind relativ unkritisch was das
Timing betrifft, die eigentliche Performance wird für das
Datenregister benötigt (einen Sektor lesen/schreiben: 6-10 Zugriffe
auf die 8-Bit Register, und 256 auf das Datenregister, und
dank Multi-Sektor Kommandos sogar noch längere "Bursts").

Mein erster einfacher Ansatz war nun, das der CPLD Memory Zugriffe
erkennt: Das ist einfach, ich musste nur dafür sorgen das der
CPLD Schreibzugriffe annimmt, und für Lesezugriffe Daten liefert.

Dabei ist das Timing aber von der CPU bestimmt und z.B. das Lesen
ist recht knapp: 3-4 Takte nach dem Anfang müssen die Daten auf
dem Bus liegen. In der kurzen Zeit kann man aber keinen IDE Zugriff
durchführen. Daher war die Idee, das ich zwei CPU Zugriffe verwende:
Der eine Zugriff sagt dem CPLD, das ein Wort vom IDE Interface
organisiert werden soll, und der zweite (deutlich spätere) Zugriff
liefert diese Daten dann zur CPU. Dazwischen wartet die CPU einfach
einen kleinen Augenblick, damit der CPLD die Aufgabe erledigen
kann.

Dummerweise kann die Platte über eine Leitung einen Zugriff ausbremsen.
Das ist z.B. auch notwendig, wenn das Kabel nicht gut ist, und die
Platte keine stabilen Signale sieht oder einfach langsam ist. Daher
müsste die CPU dafür relativ lange warten, das der CPLD den Zugriff
auch sicher für gebremste Kommandos ausführen kann.

Das funktioniert(e) zwar, bremst das System aber sinnlos aus, wenn die
Platte das Brems-signal nicht benutzt hat... Daher war die zweite Idee,
den Chip selbstständiger arbeiten zu lassen: (Ich beschreibe hier
jetzt immer nur das Lesen, Schreiben funktioniert natürlich sehr
ähnlich)

Die CPU schreibt ein Kommando in den CPLD, das ein FIFO gefüllt werden
soll. Der CPLD holt nun selbstständig von der Platte Datenworte. Und
zwar mit dem Timing das die Platte erlaubt. Wenn der FIFO voll ist,
stoppt der CPLD von alleine. Er macht ebenfalls von alleine weiter
wenn wieder Platz im Fifo ist, d.h. alles ohne weitere Kommandos.
Kurz vor dem Ende der Übertragung wird dieses Fifo-Füllen natürlich
von der CPU abgestellt.

Die CPU greift bei Lesezugriffen dann auf diesen Fifo zu und holt dort
die Datenworte heraus. Nebenbei kann sie das nun mit 32 Bit Zugriffen
tun. (Auch bei meiner ersten Variante gab es das aber auch schon...)
Allerdings muss die CPU noch prüfen, ob überhaupt Daten im Fifo stehen,
und das ist mindestens ein weiterer Zugriff (Hier schliesst sich der
Kreis zu dem Hinweis in meinem Posting zum MMC-Bit Bang Optimieren:
eine Abfrage über einen IO-Pin könnte das evtl. beschleunigen und auch
stark vereinfachen: Wenn das da doch nur 75ns kostet...)

So weit, so gut. Doch da der CPLD nur eine sehr begrenzte Menge an
FlipFlops hat, ist der Fifo nicht beliebig gross sondern speichert nur
vier 16 Bit (IDE) Worte oder zwei 32 Bit (CPU) Worte.

Der ideale(?) Ablauf wäre daher so:
A)
1. CPU schreibt Kommando zum lesen
2. CPU wartet, CPLD beginnnt zu lesen
3. CPU liest FIFO und erkennt das 4 Worte da sind,
4. CPU liest 4 Worte (dabei beginnt der CPLD bereits
wieder IDE Worte zu lesen)
5. CPU wartet kurz
6. weiter bei 3

Oder alternativ auch so:
B)
1. CPU schreibt Kommando zum lesen
2. CPU wartet, CPLD beginnt zu lesen
3. CPU liest FIFO und erkennt das >2 Worte da sind
4. CPU liest 2 Worte
5. CPU wartet kurz
6. weiter bei 3

bei A) gibt es für zwei CPU Worte einen Fifo-Zustands-
Read. Bei B) gibt es für jedes CPU-Wort ein Fifo-Zustands-
Read, allerdings kann der CPLD kontinuierlicher
lesen.

Zeiten:
A):
IDE: 4 Worte lesen -> 4 * 120ns = 480ns
zwei CPU Worte lesen + FIFO Füllstand -> 3 * 90ns = 270ns
-> 210ns warten.

B):
IDE: 2 Worte lesen -> 2 * 120ns = 240ns
CPU: Ein Wort lesen + FIFO Füllstand -> 2 * 90ns = 180ns
-> 60ns warten

210ns oder 60ns warten bekommt man aber gar nicht so einfach
hin, denn das ist dann doch wieder verdammt kurz... Und
bereits die Entscheidung, wie es weiter geht kostet schon
mehr Zeit.

Variante C) wäre dann vielleicht die Mischung: Wenn >=2 und
<4 IDE-Worte da sind, ein CPU Zugriff, wenn 4 Worte da sind,
zwei Zugriffe.

Ach ja: Alle solche Optimierungen beziehen sich sowieso nur
auf den "guten" Fall, das die Platte nicht bremst. Das ist
mit einer gewissen Wahrscheinlichkeit aber der Fall.

Da der Kernel beim IDE System an anderen Stellen ne Menge
Zeit liegen lässt, habe ich diesen Teil ab einem bestimmten
Zeitpunkt nicht weiter optimiert, denn insgesamt wirken sich
diese Optimierungen kaum noch aus: Sie senken zum Teil "nur"
die CPU Last (wenige %), aber bringen kaum noch den
Gesamt-Durchsatz nach vorne.

Leider ist durch den "grossen" Fifo der Chip aber nun sehr
voll (fast alle Resourcen sind bei 99%), wodurch andere
Features schwierig zu ergänzen sind, z.B. ein MMC
Interface.

Schön wäre natürlich ein Chip mit OnChip-RAM gewesen, der
gleich 512 Bytes aufnehmen kann. Die kosten aber deutlich
mehr, und ich hatte ja meinen Prototypen schon, also sollte
es damit eine Lösung geben.

Allerdings (um zum Thema zurückzukommen):

Ein ganz anderer Zugriff wäre denkbar und könnte sehr
helfen: DMA...

Da der CPLD selbst keinen Buszugriff ins Memory initiieren
kann, wird die CPU dafür gebraucht, diese bietet aber dafür
eine Möglichkeit, und zwar "IDMA", und hier speziell für
uns interessant ist der "Fly By" Mode:

Der Ablauf wäre dann (in etwa) dieser:
1. CPU sagt CPM, das IDMA verwendet wird.
2. CPU sagt CPLD, das er IDE Zugriffe machen soll.
3. CPLD meldet an CPM, das 32 Bit von der Platte
vorhanden sind. (DMA Request)
4. CPM beginnt RAM Zugriff und meldet CPLD, das
die Daten auf den Bus sollen (DMA Ack).
5. CPLD legt die Daten auf den Bus und somit
ins RAM.
5. CPM beendet RAM Zugriff.
6. weiter bei 3, bis der CPM genug Daten transportiert
hat.
7. CPM generiert Int an CPU, das IDMA fertig ist.
8. CPU bearbeitet die Daten.

Das ganze _kann_ eine Verbesserung sein, wenn/weil:
1. Die DMA Request und Ack Leitung zur Verfügung stehen.
2. Die Latenz-Zeit zwischen DMA Reqest und DMA Ack
(typisch) sehr kurz ist (~200-300ns)
3. Die CPU dabei weiterläuft, der Core also nicht
blockiert wird (der Bus ja schon immer mal wieder...)
4. der CPLD weniger resourcen benötigt. Insbesondere
muss er eigentlich nur noch etwa 32 Bit zwischenspeichern,
wodurch etwa 32 Flipflops wieder frei werden. Damit hätte
ich "gewaltig" Luft für andere Dinge...
5. Bei der Platte die DMA Modi verwendet werden können,
und dadurch evtl. höhrere Transferraten möglich werden.

Wie kann man mir da nun helfen? Im wesentlichen sind das zwei
Bereiche:

1. den CPM Teil so zu programmieren, das IDMA verwendet wird.
Die Leitungen dafür sind bei Nokia Boxen wenigstens möglich,
weil am Modem Connector. Bei den anderen Boxen sieht das evtl.
nicht so gut aus, aber vielleicht findet sich da ja doch
noch was, z.B. wenn man so eine Leitung durch den CPLD
jagt.

2. Da DMA verwendet wird, ist der Treiber komplizierter.
Aber bei IDE ist DMA ja eigentlich nicht so ungewöhnlich.

Den Teil im CPLD kriegt man dann schon hin :-)


Soweit mal zu dem Thema.

Ciao,

DboxBaer

PS:
Eine Bitte: Kommentare wie "das ist aber kompliziert" oder
"ich versteh kein Wort" vielleicht hier mal weglassen und nur
echte Beiträge zum Thema posten?

[Günther]

Bei Freescale gibt es eine Beispiel zum IDMA:
http://www.freescale.com/webapp/sps/sit ... 01DFTQDKCb MPC821IDMADRV.zip
Habe noch nicht reingeschaut, aber vielleicht ganz brauchbar?

[Günther]

Sieht schon ganz brauchbar aus:

SINGLE BUFFER MODE IDMA
The single buffer mode DMA is used to transfer only one buffer of data. When the buffer has
been completely transferred (transfer count exhausted) the channel operation is terminated.
This mode of operation is restricted to flyby transfers only, and is supported only on IDMA
channel 1. This mode of operation is a subset of the buffer chaining mode, but guaranties reduced
latency.
und

Code: Alles auswählen

/*
 * FILE:		idma1.c
 *
 * DESCRIPTION:
 *
 * This driver provides a set of functions to setup
 * the IDMA channel 1 to transfer a memory block of
 * to another memory block, a memory block to
 * a I/O device, or a I/O device to a memory block.
 *
 * In the first case, Memory to Memory transfer, DMA
 * transfer starts as soon as DREQ0 is asserted assumming
 * the buffer descriptor is valid.
 * The DMA will perform buffer aligment if the buffers
 * are not aligned on a cache line or 16 byte boundary,
 * then burst the data from the source buffer into
 * its internal holding buffer, and finally burst the
 * data out to the destination buffer.
 *
 * For later cases, an I/O device must assert a DMA
 * request to DREQ0* signal, and wait until SDACK*
 * to be asserted then get or put the data on the bus
 * depending on the direction of the transfer.
 * Note that in this mode, DMA uses the single address
 * fly-by mode for each requests. There is no busrt
 * access is performed in this mode. If a I/O device
 * such as FIFO that can handle burst cycles,
 * i.e. four consecutive cycles, addtional micro code
 * must be downloaded to accommondate this type of device
 * for faster transfer. The compiler switch
 * BURST_SINGLE_ADDR_FLYBY allows to do so.

Da gibt es sogar einen Microcode Fly-By-burst

Code: Alles auswählen

  * Microcode for burst single address fly-by IDMA
 * mode for MPC821 Rev 0.2 and 0.3 (Author: YR)

Für die ganze Sache würde sich IDMA1 (PB23 und PC15) anbieten. Bei Sagem liegt der PC15 nämlich immerhin auf dem Modem-Port. Den anderen PB23 müßte man aber löten .. (bei Nokia ist eh kein Problem)

[DBoxBaer]

Danke schonmal für den Hinweis. Statt gleich in den Kernel kann man
den Code zum Testen mal in den u-boot reinbauen: Von IDE Zugriffen
bin ich da ja noch weit weg, erstmal muss der CPLD die Requests
richtig machen... Vielleicht komme ich mal die Woche dazu.

Für echte Bursts wird das aber wohl nix mit dem CPLD, da reichen
die Flipflops ja leider nicht. Das es aber tatsächlich Micro-Code dafür
gibt habe ich nie gesehen... Hätte Gurgel vielleicht doch nen
echten FPGA mit On-Chip RAM nehmen sollen?

Bevor man da gross an Sagems lötet kann man ja auf Nokia die
Latenz von Request -> Acknowledge messen. Wenn die schön
kurz ist, lohnt sich der Aufwand für einen entsprechenden CPLD,
uind dann findet sich sicher auch für die Sagems einen Lösung.

PC15 wusste ich noch, den habe ich ja auch (deswegen) als
Interrupt verwendet.

[just_me]

Allerdings muss die CPU noch prüfen, ob überhaupt Daten im Fifo stehen, und das ist mindestens ein weiterer Zugriff ...

Wenn (wegen der geringen Puffergröße) jeweils für einen 32 bit Read ein zusätzlicher Check (also ebenfalls ein 32 bit Read) anfällt, könntest Du (beim Polling Read) auch in einem 32bit Read ein 16bit Datenwort und 1 Statusbit verstecken?!

In beiden Fällen wären so für jeweils 32 bit zwei Read Zugriffe notwendig.
Das Kombinieren von zwei 16Bit Worten zu 32 bit käme ja, wie in dem Thread "MMC Treiber Optimierung mittel Bit Bang Optimierung" deutlich wurde , nahezu umsonst.

Der Vorteil fürs Verpacken des Statusbits wäre, dass Du mit ein (bis zwei) 16bit Registern im CPLD weniger auskommen könntest, ohne das Interface merklich zu bremsen: Der PowerPC wäre vermutlich ein Quäntchen schneller als die 120ns pro 16bit Wort, daher wäre auch ein größerer Puffer tendentiell leer.

Unter Umständen gings vielleicht auch mit nur zwei (oder vielleicht sogar einem?) 16 Bit Puffern im CPLD und bei Bedarf Direktschaltung vom IDE zum SDRAM Slot und folgendem Code?

Code: Alles auswählen

unsigned int read_block_polling(unsigned int *dest)
{
    volatile unsigned int *ide_in; /* bit 31 is used as busy bit
                                      bit 30..16 might be used for something else
                                      bit 15..0 hold the word as read from IDE bus
                                    */
    unsigned int in1,in2,tmp;
    unsigned int error = 0;
    unsigned int i;

    for( i=0; i<512/4; i++) {
        do{                        // optimistic timing:
            in1 = *ide_in;         // 5 Takte LSTU (load store unit)
        } while( in1&0x80000000 ); // 1/2 Takte BranchUnit
        in1 <<= 16;                // 1 Takt ALU/BFU (parallel?!)
        do{
            tmp = *ide_in;         // 5 Takte LSTU (load store unit)
        } while( tmp&0x80000000 ); // 1/2 Takte BranchUnit
        in1 |= tmp & 0xffff;       // 1 Takt ALU/BFU (parallel)


        do{                        // (timing wie weiter oben)
            in2 = *ide_in;
        } while( in2&0x80000000 );
        in2 <<= 16;
        do{
            tmp = *ide_in;
        } while( tmp&0x80000000 );
        in2 |= tmp & 0xffff;

        StoreMultipleWord(dest, in1, in2 /*in3, in4*/ ); // 6 Takte LSTU + serialize, ..?
    }                                       // 2 Takte BranchUnit, 1 Takt ALU/BFU (parallel?)
    //error = *ide_ctl_in;

    return error;
}

All bugs belong to me!

Nach meiner optimistischen Schätzung fallen hiermit je 16 bit Wort hiermit vermutlich etwa (6 + 8/4) Takte entsprechend 120ns an, der PC könnte also gerade so mithalten.
Wenn je Schleifendurchgang statt 64bit 128bit gelesen würden wäre man noch ein Ideechen schneller als die Platte.

Dieser Post war etwas off-topic, weil er sich nicht auf IDMA sondern auf die Übertragung im Polling mode bezieht, aber wenn im CPLD dadurch Platz für MMC würde, dient es ja einem guten Zweck

Frieder

[DBoxBaer]

Vielleicht OT zum IDMA, aber trotzdem wichtig...

Die Variante ist, dank der Vorüberlegung beim MMC Treiber,
vielleicht nicht schlecht, von wegen den Abläufen, die parallel
weiter gehen, also das "verodern".
Allerdings ist ein SDRAM-Zugriff (was ja zum CPLD hin
passiert) noch etwas langsamer, ich glaube es sind 6 Takte,
also 90ns.

Ursprünglich bin ich mal von dieser Überlegung ausgegangen:
Status lesen
Daten lesen (32 Bit)
Daten lesen (32 Bit)
sind 3 Zugriffe für 64 Bit/8 Byte

Bei nur 16Bit pro Read benötige ich dafür aber vier Zugriffe.
Da nun die CPU nicht immer kontinuierlich liest, sondern
auch die Daten ins RAM pumpen muss, kommen
mindestens noch die Burst Reads (8 Takte) und Writes (7 Takte) ins
RAM dazu. (Im Gegensatz zum MMC Treiber sind die hier
im Verhältnis dann ja doch teuer)

Für 512 Bytes, also 256x 16-Bit Worte ergibt das bei mir aus
CPU Sicht:
Variante A: 1xStatus, 2xData Read
270ns für 8Byte -> 64x -> 17.280ns
255ns für 16Byte -> 32x -> 8.160ns
-> 25.440ns
also ungefähr 100ns pro 16 Bit Wort. Das ist ein schönes
Stück schneller als die Platte Daten liefert.

Variante B: Data Read mit Status
90ns für 2 Byte -> 256x -> 23.040ns
255ns für 16 Byte -> 32x -> 8.160ns
-> 31.200ns
Das sind dann leider bereits knapp über 120ns pro 16 Bit Wort.

(Vielleicht habe ich mich aber auch verrechnet?)

Dummerweise kriege ich diesen idealen Ablauf aber sowieso
nicht von der CPU, daher wird B) aus meiner Sicht leider
langsamer sein.
Real habe ich eine Mischform probiert: Wenn 4x16 Bit im Fifo,
dann lese auch 2x32 Bit, wenn nur 2x16 Bit im Fifo, dann
lese wenigstens 1x32 Bit und es passiert tatsächlich beides
ungefähr gleich oft.

Eine Mischform mit einem 3x16 Bit Fifo wäre natürlich auch
denkbar: Einmal 16 Bit lesen mit Status. In einem Bit steht
dann ob da Daten dabei waren. Und wenn ja, steht in einem
zweiten Bit, ob noch weitere 32 Bit vorhanden sind, die man
dann auf einmal auslesen kann. Wenn man kompakten Code
hinbekommt, der das zusammenschiebt, könnte es sogar
was bringen...

Zurück zum Thema:
Bei IDMA mit FlyBy fällt dabei einiges raus: Da die Daten nicht
erst in die CPU gepumpt werden und dank doofen Cache
Problemen nicht sinnlos aus dem RAM gelesen werden muss,
um dort zu schreiben. Es sind dann tatsächlich nur ein 32 Bit
Zugriff mit 90ns für 2x 16-Bit IDE-Daten. Allerdings kommt
noch die unbekannte Latenzzeit des CPM dazu, der hat aber
tatsächlich schonmal 150ns Zeit, ohne das wir überhaupt was
verlieren. Meine Hoffnung ist nun, das die Zeit vielleicht auch
kürzer sein kann, dann gehen die schnelleren DMA Modi zur
Platte sogar. Und wenn nicht, dann wird der Bus und der
CPU Core deutlich weniger belastet, was ja auch nicht so
schlecht ist: Immerhin vergehen zum Teil halbe Ewigkeiten
bis die Platte überhaupt mal Daten zur Verfügung stellt :-).
Wenn der Transport dann ein paar us länger dauert, fällt
das nicht ins Gewicht, wenn die CPU dabei nicht ausgebremst
wird. DMA halt.

Ciao,

DboxBaer

[Günther]

Hallo DBoxBaer,

wenn ich Dich beim IDMA untersützen kann, laß es mich wissen. Ich habe die nächsten Abende ein bisschen Zeit

Die SMC2 Optimierung habe ich soeben aufgegeben. Irgendwie stürtzt die ganze Kiste immer ab, wenn ich den SMC2 loslaufen lasse (per Sync von einem anderen PORT). Ich werde da gerade nicht schlau draus und selbst wenn - so wie es nach dem Manual aussieht läßt sich der SMC wahrscheinlich nicht punktgenau starten. Ein paar CLOCKs werden wohl immer schon raus sein, bevor der SMC starten und somit werden ein paar bits fehlen. Also im Moment rein akademischer Natur (wobei mich das natürchlich schon wurmt, daß es überhaupt nicht geht ).

Aber zurück zum IDMA. Der Beispiel-Code von freescale schein ja schon ganz brauchbar zu sein. Bei Bedarf kann ich ja ein bisschen vorarbeit leisten (ev. müßtest Du mich aber noch mal bezüglich DMA aufschlauen

Günther

[PauleFoul]

@ DBoxBaer

Bist Du denn an dem Punkt schon irgendwie weiter gekommen??

Kannst uns ja vielleicht mal über den aktuellen Stand berichten...


Gruß
____Paule

[DBoxBaer]

@ DBoxBaer

Bist Du denn an dem Punkt schon irgendwie weiter gekommen??

Kannst uns ja vielleicht mal über den aktuellen Stand berichten...


Gruß
____Paule

Moin!

Nee, da ist gar nichts passiert. War nämlich gar nicht da (Hochzeitsreise stand noch aus...) und habe ja auch sonst ein Leben neben der Box...

Zum Thema Unterstützung:
Auch ohne CPLD sollte man messen können, ob IDMA schnell oder langsam auf einen Request reagiert:
Schnell: < 1us
Langsam: > 1us

Wenn wir unter 500ns liegen, sollte ich eigentlich sofort anfangen einen CPLD zu bauen, der das verwendet... Bei >1us lohnt sich das ganze aber eigentlich gar nicht.

Darum muss man irgendwie was messen:
real muss man ja nicht mal wirklich Daten auf dem Bus legen, sondern nur an der Request-Leitung wackeln und die Zeit bis zum Ack messen: mit nem Pulsgenerator und nem Oszi zum Beispiel.

Der Messaufbau hängt dabei nur am Modem Connector (wenigstens bei einer Nokia Box)... Und natürlich muss man zum Beispiel einen u-boot laden, der IDMA irgendwie verwendet, einen Code Abschnitt dazu gab es ja bereits hier.

Wenn also jemand die Möglichkeit und das KnowHow hat, das mal zu messen, steigt der Druck, den Rest zu liefern bei mir natürlich stark an.

Ciao,

DboxBaer

PS:
Die Werte sind real möglich: Sowohl schnell als auch langsam:
Der CPM beim Ethernet kann, so denke ich, nur 32 Bit buffern. Bei 10MHz, also 100ns pro Bit, sind das 3.2us. Also muss der per DMA die Daten in 3.2us loswerden können. Das wäre eine Obergrenze, nur ist die recht "lahm" für unsere Zwecke. (eben LAN Geschwindigkeit...)
Nach unten: Ein Memory-Buszugriff dauert <150ns. Auch die des CPU-Kern selbst. (Bei "IO-Zugriffen" auch länger, aber die sind nicht so oft?!). Angenommen, das die Zugriffe gleiche Prio haben, muss man den aktiven Zugriff wenigstens abwarten. Da mich nicht der Worst-Case interessiert, ist das aber schon alles: Kann also gut sein, das es so 150ns sind bis der reagiert. Der Zugriff dauert selbst auch ~120ns. Dann bin ich bei 13MB/s. Allerdings eben ohne CPU Last (und mit 50% Bus-Last für IDE).

[Liontamer]

[...]mit nem Pulsgenerator und nem Oszi zum Beispiel.[...]

Hab nen einfachen Frequenzgenerator und ein billiges 2-Kanal Scope von Conrad hier zu Hause rumstehen. Damit sollte das doch theoretisch funktionieren, oder nicht?

Hab allerdings aufgrund eines Vollzeitstudiums und zusätzlichem 10h Job nicht viel Zeit das zu testen.

Ich würde mich aber dazu bereit erklären, wenn mir Anleitung und Software (fertiges uboot) gegeben werden.


PS: Zur Not kann ich auch auf Professionelles Equipment zugreifen, aber das kostet mich noch mehr Zeit.

[palace]

@DBoxBaer: My 2 Cents: Selbst wenn es nicht schneller wird, dafür aber die CPU schont, würde es sich lohnen..

[Liontamer]

Nächsten Montag und Dienstag hätte ich Zeit dafür. Also nur zu, ich bin für Schandtaten bereit

[DBoxBaer]

Nächsten Montag und Dienstag hätte ich Zeit dafür. Also nur zu, ich bin für Schandtaten bereit :lol:

Gut: Kommt jemand hier am Wochenende dazu in einen u-boot ne IDMA Routine einzuhängen?!
So dass der CPM Teil des 823 IDMA machen will und eben auf nen Request an dem entsprechenden Pin wartet?

Bei mir sieht es leider schon wieder schlecht aus...

DboxBaer

[Günther]

Bei mir leider auch - das Wetter soll ja schön werden, dann gehts in die Berge . Aber wie schon mal geschrieben, das IDMA Beispiel von freescale war ja schon ganz brauchbar.

[Rochvellon]

Wie weit ist denn die DMA-Unterstuetzung gediegen?

Wie sieht es denn aus, koennte auch ein neuerer, schnellerer Prozessor verbaut werden? Vllt. koennte sowas auch entwickelt und dort gleich das IDE-IF integriert werden.