32Bit µP od. µC mit 40 Datenregister

Herstellerseiten durchsuchen.

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.

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 ?

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

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

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 ?

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

Bleibe dabei, da geht nen 8 BITter.

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

>> (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 ;-))

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

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.

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

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.

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.

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

oder halt die version mit µC + Latch oder Schieberegister

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

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

@ 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.

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

@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

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.

>> 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 ?

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

>> 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 !?!?

>> 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 !?!?

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

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.

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

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

hmm wahrscheinlich scheitert das an der anzahl der adressleitungen...

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.

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?

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.