www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik 32Bit µP od. µC mit 40 Datenregister


Autor: PeterK (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hello

ich bin auf der suche nach einem µC oder µP mit 32Bit Datenregister und 
Adressregister (wie z.B. der uralte MC68000) nur mit insgesamt 40 
Datenregister und 15 Adressregister (mind. 8 Adressregister) mit 32Bit


PeterK

Autor: Obelix (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Herstellerseiten durchsuchen.

Autor: yalu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Den gibt es wahrscheinlich nicht.

Es sei denn, du definierst den Bergiff "Register" etwas weitläufiger
und nennst RAM-Speicherzellen ebenfalls Register. Dann hast du
plötzlich ganz viele davon :-)

Was ich damit sagen möchte: Du hast vergessen zu schreiben, welche
Eigenschaften von Prozessorregistern für dich so wichtig sind, bspw.:

- Viele Register machen manchmal den Einsatz von externem RAM
  überflüssig, damit kann Platz eingespart werden. Alternative: Nimm
  einen Prozessor mit internem RAM.

- Die Zugriffszeiten auf die Daten sollen sehr kurz sein. Alternative:
  Nimm schnelles RAM und einen schnellen Prozessor.

Andere Gründe, warum man so viele Register bräuchte, fallen mir nicht
ein. Aber dir vielleicht.

Autor: Joe (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Besser du beschreibst was du machen willst, nen 32 BITter ist für viele 
Standardaufgaben völlig oversized. Gibt es irgendeinen zwingenden Grund 
für deine 32 BIT Entscheidung ?

Autor: A.K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
AMD 29000 (tot) und Intel Itanium erfüll(t)en diese Bedingungen. Andere 
nur wenn man Fliesskommaregister grosszügig mitzählt.

Autor: PeterK (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ich möchte gerne 32Bit zeitgleich (ohne Verzögerung) in einem 
Assemblerbefehl rausjagen;

Im µC werden die Bits zuerst richtig angeordnet in einem 32Bit Register, 
damit schon mal alle 32 Werte die zeitgleich rausmüssen in einem 
Register liegen

die bits werden alle 20ms rausgeschickt und müssen zueinander synchron 
sein

PeterK



Autor: Fabian B. (fabs)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
nimm ne 32Bit lange Schieberegisterkette (4stk 595), lade die und latche 
sie alle gemeinsam, damit haste auch alle Zeitgleich am Bus... dafür 
reicht auch locker ein 8bitter. Und bei "alle 20ms" ist der mit 1Mhz 
noch gelangweilt.

Gruß
Fabian

Autor: Joe (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also die 20 mSec. sind ja eher gemütlich, wie sieht es mit 4 8 BIT 
Latches aus welche ein gemeinsames enable Signal verwenden. Du kannst 
dann deine 32 BIT beliebig einlatchen (asynchron) und mittels 
gemeinsamen enable Signal freischalten. Schon geht ein 8 BITter ;-)) 
gibt es weitere Gründe für 32 BIT ?

Autor: PeterK (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
über ein Sync-Signal werden die 32Bits rausgeschickt - zeitgleich... 
zuvor liegen sie an den Datenregistern nur an

Autor: Joe (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bleibe dabei, da geht nen 8 BITter.

Autor: PeterK (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
das mit den Latches hab ich mir auch schon überlegt, aber ich hab drei 
mögliche Synchronquellen, mit denen der Sendeimpuls ausgelöst werden 
kann - je nach dem welche halt ausgewählt wird. Die Impulse sind extern 
(z.B. über SMPTE)... deshalb dachte ich, wenn ich eh schon einen µC oder 
µP benötige, der auch noch gewisse Pausen generieren muss (deshalb 10MHz 
Takt, damit exakt die Zeiten ausrechnen kann, indem ich den Takt viertel 
etc.)

PeterK

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
PeterK wrote:

> die bits werden alle 20ms rausgeschickt und müssen zueinander synchron
> sein

Also 20ms is ja ne ganze Ewigkeit.

Ein AVR braucht um 4 Bytes rauszujagen 0,0002ms.

Das sollte doch dann synchron genug sein.


Ich würde allerdings 4 * 74HC595 dranpappen, dann isses auf mindestens 
5ns (= 0,000005ms) synchron.

Peter

Autor: Joe (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>> (z.B. über SMPTE)

Reden wir hier von TimeCode ? das ist doch sehr gemütlich und locker mit 
nem 8 BIT MC zu schaffen.

Beschreib doch mal dein Idee ;-))

Autor: PeterK (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
die 20ms sind die Abstände zwischen den Signalen - aber nicht zu 
verwechseln mit den Toleranzen innerhalb diese Signale liegen müssen... 
die sind deutlich kleiner...

Zum Thema: es kommen über 8 Datenleitungen Bits an, die im µC richtig 
sortiert werden müssen und dann via Impuls (SMPTE etc.) rausgejagt 
werden. Zusätzlich müssen die Pausen etc. im µC generiert werden - aber 
nebnsache, ,mit 10MHz kann ich die mir alle genau herstellen.

@Joe
ja über Timecode (SMPTE oder anderen) werden die Signal getriggert bzw. 
zu andere Quellen synchronisiert


@Peter
die 4Bytes werden über separate Leitungen rausgeschickt, nicht über 
eine. d.h. 32Pins für die Ausgabe. Wie berechnen sich die 0,0002ms, nur 
damit ich das überschlagen kann?

PeterK

Autor: Joe (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nochmal, das Ganze ist mit nem 8 BIT MC locker zu schaffen. Es gibt jede 
Menge 8 BIT Typen die Maschinentakte im nSec. Bereich schaffen. Deine 32 
BIT lassen sich über Latches oder Schieberegister lösen.

Wie rechnet man so etwas ? Schau dir die Anzahl der Maschinentakte pro 
Befehl an und dann rechne es aus.

Autor: PeterK (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
nur noch eine frage - wieso brach ich dann noch Latches? Also wenn dann 
würd ich über einen 8Bit µC den ich brauch wegen den externen Signalen 
und der Auswahl über welchen Timecode das ganze laufen soll, und fertig.

4Ports mit 8Pins --> ca. 0.0008ms zeitlicher Abstand zwischen dem ersten 
8Pins und den letzten 8Pins. Die Pins von einem Port können zeitgleich - 
also ohne Verzögerung - mit einem Inhalt eines Registers befüllt werden, 
oder?



@Joe
das mit der zeit ist mir auch grad aufgefallen - krggs...

PeterK

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
PeterK wrote:

> die 4Bytes werden über separate Leitungen rausgeschickt, nicht über
> eine. d.h. 32Pins für die Ausgabe. Wie berechnen sich die 0,0002ms, nur
> damit ich das überschlagen kann?

Bei 20MHZ dauert ein OUT 50ns also 4 OUTs = 200ns
Die Asynchronität ist dann die Zeit für 3 OUTs (150ns) bzw. 0,00075%.


Oder mit den 4 * 74HC595 kann man alle Ausgänge gleichzeitig latchen, 
die Asynchronität dürfte weit unter 5ns liegen (Laufzeitdifferenz der 
CMOS-Gatter).


Peter



Autor: Joe (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Du willst 32 BIT synchron ausgeben. Mit einem 8 BIT Controller ist es 
nicht möglich diese Synchron in die Latches zu schreiben z.B. 4x 8 BIT 
auf die Latches schreiben.

Beispiel: Du verwendest Schieberegister wie z.B. das 4094 und 
kaskadierst die zu 32 BIT. Nun muß der MC dein 32 BIT Datenwort in die 
Schieberegister hineinschreiben, das benötigt Zeit. Ist das 32 BIT 
Datenwort in die Schieberegister übertragen so lassen sich die 32 BIT 
mittels einem Freigabesignal auf einen Schlag herausschrieben (so wie du 
es brauchst). Das Ganze ist also nur eine Denksportaufgabe für ein 
entsprechendes Design.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Joe wrote:
> Du willst 32 BIT synchron ausgeben. Mit einem 8 BIT Controller ist es
> nicht möglich diese Synchron in die Latches zu schreiben


Doch, wenn man Synchron definiert als Verhältnis zum Ausgabetakt und da 
sind 150ns alle 20ms schon verdammt synchron.


Exakt synchron ist auch mit nem 32Bit-Register absolut unmöglich 
(unterschiedliche Gatterlaufzeiten, Leiterzuglängen, 
Schaltungskapazitäten, Schaltschwellen).


Peter

Autor: Joe (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Synchron ist Synchron und das was ich beschrieben habe kann mittels 
Synchronsignal die 32 BIT aus den Schieberegistern entlassen.

Da wo ich arbeite sind 150 nSec. nicht synchron.

Allerdings reden wir am Thema vorbei.

Autor: PeterK (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hallo Joe,

das mit den Schieberegistern klingt gut - jedoch muss ich ja ein paar 
Formatierungen machen an den einzelnen Bits in punkto Reihenfolge und 
noch ein paar andere sachen, so dass ich einen µC oder µP auf jeden fall 
benötige, bevor ich die 32bit ausgeben kann.

Das is genau das Problem, ich brauch einen µC mit dem ich 32Bit 
gleichzeitig synchron ausgeben kann.

PeterK

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Joe wrote:

> Da wo ich arbeite sind 150 nSec. nicht synchron.

Bezogen auf was ?

Alles klar, Deine Wohnungsheizung muß auch auf 0,0001°C genau regeln, 
sonst wären es ja nicht "genau" 20°C.

Kein numerischer Wert steht nur so im Raum, es braucht immer eine 
Bezugsbasis, um ihn zu beurteilen.


Peter

Autor: PeterK (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
oder halt die version mit µC + Latch oder Schieberegister

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
PeterK wrote:

> Das is genau das Problem, ich brauch einen µC mit dem ich 32Bit
> gleichzeitig synchron ausgeben kann.

Nein, Dein Problem ist, daß Du nicht definierst, was "gleichzeitig 
synchron" in Deiner Aufgabenstellung überhaupt bedeutet.


Viele Projekte scheitern schon am Pflichtenheft (d.h. am Fehlen 
desselben).


Peter

Autor: PeterK (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
sorry vergessen anzugeben - natürlich gibt es vorgaben, ansonsten könnte 
man ja nichts rechnen etc.

also zwischen den signalen liegen 20ms Zeitdifferenz und die 
Synchronität zwischen den 32 Signalen muss innerhalb von 100ns liegen - 
da die sensoren 200 Signale innerhalb dieser 20ms wahrnehmen können; 
d.h. ich benötige eine genauigkeit von max. 100ns besser im bereich von 
50ns, damit die sensoren genau feststellen von wo das signal wann kam.

PeterK

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
PeterK wrote:

> d.h. ich benötige eine genauigkeit von max. 100ns besser im bereich von
> 50ns, damit die sensoren genau feststellen von wo das signal wann kam.

Na das is doch schonmal ne Hausnummer.
Kann der AVR nicht ohne externe Register.

Wenn Dir fine-pitch Löten nichts ausmacht, würde ich zur LPC2xxx-Serie 
raten (von NXP), das ist ein populärer preiswerter 32Bitter (ARM7-TDMI).


Peter

Autor: PeterK (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hallo Peter,

das fine-pitch löten ist sekundär - wichtig ist echt, diese zeiten 
einzuhalten sprich das wirklich alle synchron sind und nicht als andere 
signale gewertet werden können.

der preis spielt nahezu keine rolle - manchmal kann man ja auch mit 
einem intel z.B. ziemlich gut werben etc. und der preis wird zur 
nebensache, wenn die ware so funktioniert wie man es haben möchte

PeterK


Autor: Joe (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Peter Danegger

>> Bezogen auf was ?

Bezogen auf Video SDI Signale ;-)) Damit beschäftige ich mich z.B., war 
auch nur nen Beispiel, synchron ist synchron und nicht irgend etwas.

@ Peter K

Zu irgendeinem Zeitpunkt müssen deine 32 BIT Synchron zur Verfügung 
stehen und das tun sie dann auch. Zu einem anderen Zeitpunkt bereitest 
du deine 32 BIT in den Schieberegistern vor. Das bedeutet das dass 
Enable Signal aus dem Sync. Signal generiert wird und somit paßt alles.

Kannst du mal nen Flußdiagramm mit Timing erstellen ? dann ergibt sich 
auch ein ganzes Bild für mich.

Was muß in welcher Zeit ausgewertet werden. Mach mal exakte Angaben. 
Vielleicht teilt man die Aufgabe auch auf 2 MC's auf.

Autor: PeterK (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Zu irgendeinem Zeitpunkt müssen deine 32 BIT Synchron zur Verfügung
stehen und das tun sie dann auch. Zu einem anderen Zeitpunkt bereitest
du deine 32 BIT in den Schieberegistern vor. Das bedeutet das dass
Enable Signal aus dem Sync. Signal generiert wird und somit paßt alles.

Kannst du mal nen Flußdiagramm mit Timing erstellen ? dann ergibt sich
auch ein ganzes Bild für mich.

Was muß in welcher Zeit ausgewertet werden. Mach mal exakte Angaben.
Vielleicht teilt man die Aufgabe auch auf 2 MC's auf.

Hallo Joe,

mit SDI-Signalen gehts bei dem Projekt, an dem ich arbeite unter anderem 
auch zur sache - hat aber mit meinem gerät nichts zu tun;

im Prinzip gibt es ein Netzwerk 1000Base-T über welches viele Geräte 
talken (deshalb 1000Base-T) - mein Gerät besitzt auch eine solche 
Ethernet-Schnittstelle (mit einem Intel-Ethernet-Controller - nur das 
beste). über diese Schnittstelle kommen die daten rein und müssen 
zwischengespeichert werden. Es kommen zwei Protokolle vor - UDP und TCP. 
Über UDP wird nur zwischendurch abgefragt, wer denn so im netzwerk ist 
und wo die daten somit hingehen sollen. Mit dem TCP gehen die Daten dann 
nur an diese IPs und MACs. die TCP-Pakete beinhalten neben dem Header 
544Byte an Daten. In meinem Gerät müssen diese ausgewertet werden und 
zwar steht im Header drinnen welche Bits für welches Gerät (welcher 
Anschluss von den 32 Stück verwendet werden soll) übertragen werden 
sollen. Die Daten über die Ethernet-Schnittstelle kommen max. mit einer 
Rate von 0.2ms an. Zu einem Paket welches dann an den 32 Outputs liegt 
gehören max. 32 Pakete -> 6.4ms dann ist alles da --> jetzt kann ich die 
arbeiten machen und hab dafür noch 13.6ms Zeit.

Alle 32 Pakete müssen also gespeichert werden - (muss ich mir noch 
überlegen ob externer SRAM oder interner RAM ca. 60kB). Eine Aufteilung 
zwischen zwei µC - der eine für Ankunft der Daten zuständig + 
Usereinstellungen im Meenü und der andere für die synchrone ausgabe ist 
dahingehend eine alternative, weil mann ja ziemlich viele Pins benötigt. 
Das Ethernet läuft ja über 4 Doppel-Adernpaare. Über I²C das Display, 
32Pins für den Output der Daten, plus vielleicht externer SRAM (8 
Datenleitungen, 15 Adressleitungen) oder anders organisiert.

Die Arbeit die nach Ankunft der 32 Pakete - können auch weniger sein, je 
nachdem wieviele Geräte an meinem angeschlossen sind - max. halt 32 
Geräte, daher 32 Outputs etc. Die Pakete müssen alle richtig 
zusammengestellt werden in Registern oder SRAM damit ich schnell 
draufzugreifen kann und zur gleichen Zeit alles richtig rausgeschickt 
wird.

zwischen den Signalen bestehen ja 20ms Abstand - d.h. natürlich, dass 
ich in dieser Zeit sämtliche Operationen versuche abzubilden, um wieder 
32Bit an den Ausgängen zu haben, um diese synchron rausschicken zu 
können. Dann kommt das Sync-Signal (SMPTE) und losgehts - raus damit. 
und immer so weiter - der user kann zwischen drei verschiedenen 
Sync-Signalen auswählen. An jedem Output gehen also stets 17Bits raus - 
alle mit einer genauigkeit von 5ns. -> dann gehts wieder von vorne los 
20ms Pause während wieder die neuen Pakete vom Ethernet kommen.

PeterK


Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ PeterK

>das fine-pitch löten ist sekundär - wichtig ist echt, diese zeiten
>einzuhalten sprich das wirklich alle synchron sind und nicht als andere
>signale gewertet werden können.

Nun bring doch mal Butter bei die Fische!
Es haben mehrere Leute schon mehr als genug gesagt, dass ohne KONKRETE 
ZAHLEN diese Diskussion zu einem Stammtischgelaber wird.
Also. Wieviel Nanosekunden sind für dich "Synchron"?
1ns?
5ns?
100ns?
1us?
1ms?

Und sag jetzt nicht so genau wie möglich!

Was soll dabei eigentlich rauskommen? Gehts um das hier?

http://de.wikipedia.org/wiki/SMPTE-Timecode

Wenn ja, ist die Lösung per Schieberegister mit <5ns Zeitversatz mehr 
als ausreichend. Ein 8Bit uC langweilt sich dabei zu Tode.

>der preis spielt nahezu keine rolle - manchmal kann man ja auch mit

Klingt für mich nach "Ich hab keine Ahnung aber viel Geld". Sowas sieht 
man öfter. Tut mir leid, aber das musste jetzt sein.

MFG
Falk

Autor: PeterK (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Falk

>Und sag jetzt nicht so genau wie möglich!

versteh deine frage nicht --> steht doch schon längst alles in diesem 
thread drinnen! bitte zuerst lesen und dann antworten...
Datum: 02.06.2007 18:27

SMPTE = SMPTE-Timecode --> ja, richtig; was anderes gibt es meines 
Wissens unter SMPTE nicht.

Bei der Genauigkeit spielt der SMPTE-Synchronimpuls nur sekundäre Rolle 
- steht auch in diesem Thread. Wichtig ist die Genauigkeit der Sensoren 
bzw. deren Auflösungsvermögen. der SMPTE sagt nur wann die Bits 
losgeschickt werden, aber nicht mit welcher Genauigkeit...

PeterK

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ PeterK

>versteh deine frage nicht --> steht doch schon längst alles in diesem
>thread drinnen! bitte zuerst lesen und dann antworten...

Uuups, das hab ich wohl übersehen. Naja, dann ist doch alles klar. 
Enweder 4 Schieberegister oder 4 Latches mit gemeinsamen Strobe.

MFg
Falk


Autor: Joe (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wo stehst du denn jetzt bei deinem Projekt ?

Den Netzwerk Anteil hast du derzeit auch noch nicht auf MC Ebene gelöst 
? Mit anderen Worten der gesamte Netwerkanteil muß erst einmal gelöst 
werden. Selbst wenn du ein schönes GIGABIT Netwerk verwendest sagt das 
noch nichts darüber aus ob du die "Sensor Daten" (welche das auch sein 
mögen) in dem von dir gewünschten Zeitfenster angeliefert bekommst (will 
sagen Netwerkapplikationen haben nichts mir "real time Anwendungen" 
gemein ;-)) sorry, ist aber so.

Du könntest ja im ersten Schritt deinen Netwerkanteil mal auf einem PC 
programmieren und austesten. Dein 32 BIT Register ist jedenfalls das 
kleinste Problem.

Hast du dich schon mit UDP / TCP/IP, respektive mit MC's und Netzwerk 
beschäftigt ? Das wäre zumindestens der erste Schritt.

Autor: Joe (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>> Zu einem Paket welches dann an den 32 Outputs liegt gehören max. 32 Pakete
>> -> 6.4ms dann ist alles da -->

Das ist reine Theorie oder hast du das getestet und am laufen ?

Autor: PeterK (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hab das ganze schon am laufen - allerdings nicht auf µC-Ebene sondern 
mit C# programmiert auf einem standard-windows-rechner. Daher stammen 
auch die Werte.

>Das ist reine Theorie oder hast du das getestet und am laufen ?

natürlich ist das viel Theorie, weil ich keinen einfluss darauf habe wie 
lange es dauert, dass alle 32 Pakete ankommen. Hängt ja auch vom 
letztendlichen Traffic ab - denn ich nicht simulieren kann, weil die 
anderen Komponenten (Rechner etc.) nicht da sind - z.B. werden über das 
gleiche Netzwerk zeitgleich auch videodaten übertragen.

>Hast du dich schon mit UDP / TCP/IP, respektive mit MC's und Netzwerk
> beschäftigt ? Das wäre zumindestens der erste Schritt.

TCP / IP u. UDP sind keine Fremdwörter für mich - will heißen, ich weiß 
wie die Pakete aufgebaut sind (hab die Daten ja in der C#-Lösung auch 
aufgebrochen und neu zusammengewürfelt etc. Mit µC und Ethernet hab 
keinen so großen Erfahrungsbereich. Ich weiß, dass die 
Checksummen-Auswertung der einzelnen Pakete bereits auf einem 
Ethernet-Controller ausgewertet wird und um den Rest muss sich der µC 
selbst kümmern.

PeterK

Autor: Joe (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>> natürlich ist das viel Theorie, weil ich keinen einfluss darauf habe wie
>> lange es dauert, dass alle 32 Pakete ankommen.

Genau das wird dein Hauptproblem werden.

>> hab das ganze schon am laufen - allerdings nicht auf µC-Ebene sondern
>> mit C# programmiert auf einem standard-windows-rechner.

Na, das ist doch ne Grundlage. Eigentlich wäre der nächste Schritt nun 
exakt diesen Anteil auf einen MC zu implementieren, hast du hier schon 
eine Entscheidung getroffen ? Erste Gehversuche ?

Ansonsten wäre ein embedded LINUX Board vielleicht die bessere Wahl !?!?

Autor: Joe (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>> z.B. werden über das gleiche Netzwerk zeitgleich auch videodaten
>> übertragen.

Wenn die mit priorisierung laufen dann wirds schwer. Können in diesem 
Netwerk bis zu 32 Devices Video Daten schaufeln ? Was sind das für Daten 
? MXF ? welche Bandbreite ? Unter Umständen muß man auch das 
Nutzdatennetz vom "Steuernetz" trennen !?!?

Autor: PeterK (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
das problem wie lange es dauert, dass die daten ankommen, muss wenn 
notwendig im netzwerk geregelt werden über prioritäten etc. Das hat mit 
meinem Gerät erstmal so nichts zutun; das gerät muss nur in der lage 
sein, die daten in dieser geschwindigkeit aufnehmen zu können und 
verarbeiten zu können.

>diesen Anteil auf einen MC zu implementieren, hast du hier schon
>eine Entscheidung getroffen ? Erste Gehversuche ?

da bin ich gerade dabei - allerdings noch auf der theoretischen ebene. 
Suche mir quasi die einzelnen Komponenten gerade aus, um möglichst ohne 
viel aufwand das zu bewerkstelligen.

- Ethernet Controller (z.B. Intel 82573EI mit Checksum-Berechnung für 
TCP, UDP, TCP Segmentation)

- externer SRAM für den Webserver + Daten-Pakete

- µC: Hier steh ich grad - schon etwas länger; ist es sinnvoll alles auf 
einem µC abzuwälzen oder lieber zwei µC (der zweite z.B. nur für die 
reine Ausgabe der Daten und der Bitumwandlung + SMPTE-SyncSignal 
zuständig; der erste µC für die Annahme der Daten-Pakete, Display u. 
Webserver-Aktivitäten) oder doch nur einen µC - oder doch nur einen 
großen µC

- die ARMs gefallen mir ganz gut...

PeterK


Autor: Joe (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das kann man pauschal nicht beantworten. Aus dem Bauch heraus würde ich 
das Ganze mit mindestens 2 MC's machen. Einer Grundweg für die 
Netwerkaufgaben und alle anderen Aufgaben mit nem 2ten.

Autor: PeterK (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
nein, über dieses netzwerk laufen ganz viele verschiedene sachen - unter 
anderem auch videodaten, aber mit einer geringen priorität... also kein 
live-stream.

Autor: PeterK (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
mit den zwei µC wäre auch so mein vorschlag - allerdings auf den zweiten 
würde ich nur die Daten-Pakete bearbeiten und rausschicken und mit dem 
ersten die Daten-Pakete entgegennehmen und Webserver + Display abwälzen.

Gibt es eine Möglichkeit (wahrscheinlich nicht) die 600Byte daten in 
einem RAM abzuspeichern, worauf der zweite µC zugreifen könnte und zwar 
auf die einzelnen Bits? das wäre aus meiner sicht die genialste lösung, 
weil dann brauch ich keine Bits umändern mit mehreren Befehlen sondern 
hol sie mir aus dem RAM so wie ich sie brauch.

PeterK

Autor: PeterK (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hmm wahrscheinlich scheitert das an der anzahl der adressleitungen...

Autor: Joe (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja und nein. Für so etwas hat man früher einmal dual port RAM's 
verwendet, damit geht so etwas.

Im Prinzip kann man das aber auch mit nem Standard RAM machen. Du mußt 
nur sicherstellen das zum Zeitpunkt des Zugriffs von MC2 auf die RAM 
Daten, MC1 sozusagen seine Anschlüsse gegenüber dem RAM abschaltet.

Beispiel: Eine leere Speicherzelle (RAMzelle) = 0xFF. Wenn zum Zeitpunkt 
des Zugriff von MC2, MC1 an seinen Anschlüssen logisch 1 oder hochohmig 
führt dann gehts. Die Enable Leitung des RAM mußt du nur an beide MC's 
führen und so etwas wie ein MC1 busy an MC2 melden. So etwas habe ich 
schon gemacht und ist im Prinzip keine große Sache.

Autor: PeterK (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
gut ein SRAM zum Datenaustausch zwischen den beiden µC klingt gut - die 
verwaltung wann wer sprechen darf, kann ich mir auch nicht so shcwer 
vorstellen.

welche MHz-Zahl würdest du beim ersten µC wählen? Beim zweiten hab ich 
sie bis jetzt sogewählt, dass ich mir jegliche Timer sparre und über 
nop() die Zeiten / Pausen alle genau erzeugen kann.

und für die Ausgabe der 32 Datenpakete am zweiten µC würdest du jetzt 
Latches oder Schieberegister verwenden?

Autor: Joe (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Geschwindigkeit des MC's in MHz ist nicht entscheidend, kommt darauf 
an wie schnell ein MC mit entsprechenden Takt arbeitet. Bei einem 8 
BITter würde ich z.B. einen Silabs Typ aus der 8x51 Familie wählen (der 
ist schnell genug ;-))

http://www.silabs.com/tgwWebApp/public/index.htm

>> und für die Ausgabe der 32 Datenpakete am zweiten µC würdest du jetzt
>> Latches oder Schieberegister verwenden?

Mit Latches bist du eindeutig schneller. Es kommt nun auf das konkrete 
Timing an. Mit Schieberegistern gehts ebenso. Mal unterstellt du clockst 
die 32 BIT mit ner uSec. pro BIT herein dann benötigst du zum Laden des 
SR 32 uSec.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.