Hallo, ich bin auf der Suche nach einem Prozessor (32 oder 64 Bit) mit ca. 150! IO-Ports. Habe leider keinen mit dieser Anzahl an IO-Pins gefunden, vileicht könnt Ihr mir ja weiterhellfen.
Gast
#258838
Sorry Thorran! Prozessoren mit sovielen IO-Port's wirds wohl so nicht geben. Um Porterweiterung wirst wohl nicht herumkommen. Wegen 32 oder 64 Bit Prozessoren könntest mal bei Phytec vorbeischauen die bieten fertige Systeme an. Sollte hier keine Schleichwerbung sein es gibt sicherlich auch andere Hersteller Gruß Klaus
Gast
#258839
150 I/O-Ports à 8 Bit ? Das wären 1200 Pins.
Ich hab noch keine so großen IO's bei uCs gesehen, aber das kannst dir ja einfach selbst bauen mit Latches. Sag einfach mal für was du das brauchst. Ausgang, Eingang oder beides?
Gast
#258841
82c55 ist ein guter portabaustein. der duerfte fuer dich geeignet sein
Gast
#258842
meinte Pins nicht Ports sorry
Gast
#258843
Die STR71xF-Serie (ARM7TDMI) von ST hat ein 10*16Bit SPI, d.h. wenn Du da 20* 74HC595 und 20* 74HC165 ranhängst, hast Du insgesamt 160 Ins und 160 Outs. Einfach die SPI-FIFO mit 10 Words füllen und wennse fertig ist, die 74HC595 latchen und die 10 aus den 74HC165 eingelesenen Words abholen. Peter P.S.: Der 82C55 Witz ist wirklich gut, hab mich fast totgelacht.
Gast
#258844
das Problem ist, daß es ein Zeitkritische Sache wird, mit mehreren interruptquellen, deshalb sollte es schon ein Proz mit so vielen Ports (sorry Pins) sein.
Gast
#258845
"das Problem ist, daß es ein Zeitkritische Sache wird" Definiere mal zeitkritisch, d.h. wieviel µs Zeit hast Du konkret vom Ereignis bis zum Ende der Bearbeitung ? Peter
Gast
#258846
Hallo, es sollte doch ansonsten kein problem sein an ein Businterface Portbausteine anzuhängen. Sollte bei dem Projekt eher eins der kleineren Probleme sein. Eckhard
Gast
#258847
Mal eine eine andere Frage. Wie währe es mit einer SPS. Die ist echtzeitfähig und können so viele I/O's unterstützen. Schau dir mal die SPSen von B&R an http://www.br-automation.com/cps/rde/xchg/br-productcatalogue/hs.xsl/products_5300_DEU_HTML.htm Die können normalerweise RS232 haben einen Can-Bus und sind Netzwerkfähig. Der Nachteil ist halt dass sie eine eigene Programiersoftware benötigen. Da hast du dann aber die freihe Wahl wie du programieren willst. KOP(Kontaktplan->ähnlich den Stromlaufplänen), AWL(Anweisungsliste->ähnlich dem Asembler), FUB(Funktionsbausteine->Man stöpselt die einzelnen Elemente wie Logikbausteine auf einem Steckbrett zusammen), ST(Struktured Text->Ähnlich dem Basic) und vieles mehr.
Gast
#258848
@Sepp: "Echtzeitfähig" ist eine SPS mit sicherheit nicht! :-) Höchstens sauschnell... :-D Sie holt alle Zustände von den Eingängen in einen Cach, macht einen Programmdurchlauf und gibt das aktuelle Verknüpfungs-Ergebnis aus. Wo ist da die Echtzeit? ;-)
@ techniker (tschuldigung für die zurechtstutzung) ""Echtzeitfähig" ist eine SPS mit sicherheit nicht! :-)" absolute falschaussage und nicht fragen wo die echtzeit ist sonder was ist echtzeit. kurz gesagt: die rechtzeitige verarbeitung und wertausgabe. ob das 10µs oder 100ms sind vom system abhängig. über zeiten wurde hier noch nichts gesagt.
Gast
#258850
@Michael: Wenn Thorran schon sagt, dass seine Anwendung sehr zeitkritisch wird, dann ist eine SPS mit Sicherheit die falsche Wahl, da die jeweils mehere Zyklen braucht, um eine komplexe Aufgabe zu lösen! Abgesehen davon würde ich nie etwas Zeitkritisches mit einer SPS machen, da die alle Ereignisse wären der Zykluszeit schlichtweg ignoriert! (Stichwort: Interrupt!) Und ein Zyklus von einer SPS ist mit enormer Wahrscheinlichkeit länger, als ein Takt eines modernen µC! :-) Mehr will ich hier jetzt nicht schreiben, solange keine konkreten Werte genannt worden!
Hallo! @Michael Walther: Da möcht ich mal weiterstutzen: Wenn manns genau nimmt, heißt "echzeitfähig" nicht rechtzeitig, sondern "nach einem genau definierten Zeitintervall". :-) mfg Reinhard
@Techniker "Und ein Zyklus von einer SPS ist mit enormer Wahrscheinlichkeit länger, als ein Takt eines modernen µC! :-)" ja sicher ist das so. da hst du recht. blos mit einem takt von deinem µc hast du auch nur eine befehl abgearbeitet genauso wie es eine sps macht. denn takt ist takt und zyklus ist zyklus "Stichwort: Interrupt!" finde ich gut. wie wärs mit OB40-47 ? und wirklich zeitkritische sachen kann man hier zb auf eigenständigen FM übergeben ich möchte heir keien haarspalterei betreiben dies ist nicht in meinem sinn blos die dogmas von einigen hier gegenüber sps glätten. dis kisten sind nichts anderes als ein mikroprozessorsystem mit einem deterministischen betriebssystem. und ja sie haben ihre daseinsberechtigung schau dir mal farb (nicht bunt) druckmaschinen an sämmtliche antriebe sind im gleichlauf und ja per sps. @Reinhard auch könnte man hier haare spalten. selbst bei uns an der fh scheiden sich da zwischen den profs, bei 1-2 feinheiten, immer mal die geister. "nach einem genau definierten Zeitintervall" finde ich nicht gelungen wenn die ergebnisse zu spät kommen http://de.wikipedia.org/wiki/Echtzeit-System hier steht aber auch keine definition
Gast
#258853
Hallo! Ich finde auch, dass eine SPS absolut nicht mit einem µC konkurrieren kann!! Wenn ich jetzt dein Beispiel mit einem SPS-Zyklus von 10µs nehme, dann wären dies 0,1MIPS. Ein 0-8-15 AVR kann hat schon fast 16MIPS! Wenn ich jetzt was spezielles brauch, dann such ich mir den passenenden Controller aus und komm in den hunderter-Bereich! Also jenseits der Leistung einer SPS! Ich zitiere dich hier auch: "denn takt ist takt und zyklus ist zyklus" Mit dem Unterschied, dass ein Controller auch während der Programmabarbeitung jederzeit in eine ISR "hüpfen" kann und somit SOFORT auf ein Ereignis regiert! Kann dies eine SPS auch? ;-) SPS haben ihre Daseinsberechtigung - ohne Zweifel! Aber die sind im Bereich "grober Automatisierung" und nicht im Bereich wo es auf µs ankommt! :-) Nichts für ungut, aber ich schließ mich hier der Meinung von Reinhard und Techniker an! Cu!
@Joachim sing ich? OB 40- 47 zB. sind ereignissgestuert also reagieren auf interrupts. 1. wurde der begriff echtzeit von mir nochmal aufgegriffen. 2. sind sps interruptfähig 3. wurden die begrifen takt und zyklus wahllos durcheinander geworfen 4. sagte ich das sich durch FM für kritische sachen das probelmlos erweitern lässt aber schön das du partei ergreifst ich persönlich denke du hast noch nicht so viel mit sps zu tun gehabt denn die vergleiche die du anbringst ... . zb bitschubsereien gehen mit 0,1µs wortoperationen 0,2µs gleitpunktarithmetik 6µs ich hab die werte von einem µc nicht im kopf aber auf jeden fall lädst du einen wert, verwurstest diesen und gibst ihn aus (meist mit maske also wieder verwurstet) deine 16mips wären bei 1 takt befehlen das waren gerade 4 befehle wenns reicht. ach ja sps en haben einen 32 bit breiten akku .... Mischa
noch was, ich bin kein sps crack / freak. ich spiele auch lieber mit µcs. aber würde ichtrozdem nicht kategorisch sps ausschliesen die könen mehr als manch einer denkt
Gast
#258856
Die heutiges SPS Baugruppen haben nicht umsonst 32 Bit Prozessoren drinne. Nicht NUR um Eindruck zu schinden. Vielleicht kann Thoran seine Anwendung mal ein bischen näher umschreiben. Und wenn´s denn wirklich soviele I/O-Ports sein sollen, dann bleibt immer noch die Möglichkeit sich einen solchen in einem FPGA selber zu programmieren. Das wäre evtl. für eine solche Anwendung die bessere Lösung. Gruß Thomas
Gast
#258857
Preisvergleich bei gl. Anforderungen: SPS: >1000EUR µC: <150EUR Ich würde sagen, dass dies ein weiterer Grund ist, keine SPS einzusetzen! (Mal von der Programmiersoftware abgesehen!) Nächster Punkt: Abmessung! Brauche ich einen "halben Schaltschrank" zur unterbringung, oder reicht eine PCB im Euroformat? Und dann wären dann noch Stromverbrauch, und und und... SPS für grobe Sachen in rauher Industrieumgebung: JA! Aber ansonsten ein klares: NEIN! -meine meinung-
Gast
#258858
@Thorran: Bevor das hier in eine massenschlägerei ausartet, gib mal weitere Infos! :) -Was bedeutet Zeitkritisch für dich? -Welche Technik würdes du gerne einsetzen? -Was hast du mit den 150 Datenleitungen vor? (Willst du Motoren steueren = Leistung, oder ein Display treiben = Datentransfer??)
Gast
#258859
Da uns über das Projekt nichts bekannt ist außer die Zahl der I/O Pins, auch ein spekulativer Einwurf von mir. Große Logigarray Bausteine verwende. Die Dinger sind Sau schnell aber nicht alles geht damit, aber dafür geht vieles was mir Prozessoren nicht geht. Oder mehrere Controller koppeln/syncronisieren.
Der 32192 von Renesas hat 97 I/O-Pins, 1MB Flash, 176KB RAM und 160MHz. Da fehlt zwar noch ein bischen zu den geforderten 150 I/O-Pins, aber die werden ja wohl nicht alle so zeitkritisch sein? Markus
Gast
#258861
Dickes FPGA und daran eine (ausreichend) dicke CPU klatschen. Ist halt etwas Arbeit... ...aber bestimmt Interessant: IO-Controller und Interuptcontroller im FPGA implementieren, CPU-Bus-Anbindung ist ja nicht weiter kompliziert. Alternativ kannst Du Dir den kompletten Prozessor natürlich auch im FPGA selbst implementieren. Noch eine Alternative wäre, ein FPGA mit integriertem Prozessor zu verwenden... Xilinx hat da ganz brauchbare Sachen, z.B.: XC 2VPX20: - 22.032 Logikzellen - 88 Hardware Multiplizierer - 1 PowerPc Prozessor-Kern - 552 User-IOs Da hast Du sogar noch rund 400 Pins Reserve... Viel Erfolg!
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.