Hallo, sorry evtl. falsches Forum. Aber ich sehe bei der Siemens S7-1500 eine Bitbearbeitungszeit von 2 ns. Wow. Was ist denn da für eine MCU drin ? Die müsste ja mindestens mit 1 GHz getaktet sein, oder ? Gruß Dirk
Angehängte Dateien:
-
S7.png
23 KB
Dirk F schrieb: > Die müsste ja mindestens mit 1 GHz getaktet sein, oder ? Kein Problem. Nimm einfach einen ARM-Prozessor für 10€. Dort gibts solche CPU-Boards ab 39,95: https://www.toradex.com/products Also noch viel Luft nach oben bis zur 10k€-SPS.
Lothar M. schrieb: > Dirk F schrieb: >> Die müsste ja mindestens mit 1 GHz getaktet sein, oder ? > Kein Problem. Nimm einfach einen ARM-Prozessor für 10€. > Dort gibts solche CPU-Boards ab 39,95: https://www.toradex.com/products > > Also noch viel Luft nach oben bis zur 10k€-SPS. Danke.
Dirk F schrieb: > Aber ich sehe bei der Siemens S7-1500 eine Bitbearbeitungszeit von 2 ns. Das steht dort nicht. "2ns bit performance", könnte man als 2ns Bitleistung übersetzen. > Was ist denn da für eine MCU drin ? > Die müsste ja mindestens mit 1 GHz getaktet sein, oder ? Nö. Das ist so oder so nichtssagendes Marketinggeschätz. Auch die schnellste SPS hat mit Zeiten im 2ns Bereich nix zu tun. Damit meine ich den Hauptprozessor, nicht irgendwelche exotischen Interface- oder Spezialmodule. Ein 1G Ethernetport mit optischer Schnittstelle muss 1,25 Gbit/s brutto verarbeiten. Klingt viel, ist es aber nicht wirklich heutzutage, zumal diese Geschwindigkeit nur von einem kleinen Stück Hardware beherrscht werden muss. In Richtung CPU geht es dann meist mit 32 Bit Parallelbus, ggf. sogar DMA, das sind dann nur noch 125MB/s bzw. 31,25 MTransfers/s bei 32 Bit Busbreite. Das reißt heute keinen mehr vom Hocker.
Um einen Schalter in 2nS überhaupt nur zu sehen, darf die Zuleitung zum Eingang nicht länger als 30cm sein. Die SPS könnte damit Signale bis 500 Mhz abtasten. Also Druckfehler oder typisches Marketinggeschwätz von Siemens. Lichtgeschwindigkeit ist 299792458 m/sec.
J. V. schrieb: > Um einen Schalter in 2nS überhaupt nur zu sehen, darf die > Zuleitung zum > Eingang nicht länger als 30cm sein. Die SPS könnte damit Signale bis 500 > Mhz abtasten. Also Druckfehler oder typisches Marketinggeschwätz von > Siemens. Lichtgeschwindigkeit ist 299792458 m/sec. Es ist kein Druckfehler. Es geht hier nicht um das Prozessabbild der Eingänge sondern um die Bitbearbeitungszeit. D.h. um die Zeit in der ein Bitbefehl abgearbeitet wird. Die Gesamtzykluszeit setzt sich auf hunderten oder tausenden Befehlen zusammen. Das Prozessabbild er Eingänge wird pro Zyklus nur einmal aktualisiert.
2ns pro bit sind 65MHz fuer 1 byte. Nichts weltbewegendes. Das Oszi mit 1GS hat demnach 0,125ns oder 125ps pro bit.
Dirk F schrieb: > Was ist denn da für eine MCU drin ? Das sind proprietäre ASICs. Die für normale Entwickler zugängliche Programmiersprache AWL und das zugehörige Registermodell stellen somit eine Teilmenge des Funktionsumfanges der CPU dar. > Die müsste ja mindestens mit 1 GHz getaktet sein, oder ? Vermutlich. Es gibt ja auch etliche ARM-basierten Prozessoren mit Taktfrequenzen in diesem Bereich. Um auf eine "Bitbearbeitungszeit" (=Ausführungsdauer einfacher Befehle mit reinen Registerzugriffen) von 2 ns zu kommen, wird sicherlich wie bei jedem anderen Prozessor der letzten dreißig Jahre auf Pipelining usw. zugegriffen.
Lothar M. schrieb: > Kein Problem. Nimm einfach einen ARM-Prozessor für 10€. Das sind aber Anwendungsprozessoren. Die können nicht konsistent mit 500 MHz Pins samplen. Allein schon der Zugriff auf die IO-Register dauert Dutzende bis Hunderte Takte. Mit DMA kann man vielleicht so schnell samplen, aber nicht verarbeiten/reagieren. 2ns werden also höchstens bei internen Verarbeitungen erreicht, und das auch nicht garantiert immer. Man müsste also eher bei Cortex-R schauen, und da ist die Auswahl schon knapper (und teurer!).
Niklas G. schrieb: > Das sind aber Anwendungsprozessoren. Die können nicht konsistent mit 500 > MHz Pins samplen. Allein schon der Zugriff auf die IO-Register dauert > Dutzende bis Hunderte Takte. Mit DMA kann man vielleicht so schnell > samplen, aber nicht verarbeiten/reagieren. Hast Du Dich überhaupt schon einmal mit der Funktionsweise "richtiger" SPS befasst? Das (oder die) Prozessabbild(er) wird/werden nur zu festen Zeiten aktualisiert, d.h. die Zustände aller IO-Module in das RAM geklimpert bzw. ausgegeben. Und anschließend erfolgen die Zugriffe nur auf diesem Abbild. Ich gehe ganz schwer davon aus, dass bei den ASICs in den Siemens-SPS das Aktualisieren des Prozessabbildes für lokale Module(!) nahezu komplett in Hardware realisiert sein wird. > 2ns werden also höchstens bei > internen Verarbeitungen erreicht, und das auch nicht garantiert immer. Genau. Die Angabe bezieht sich wohl auf reine Registeroperationen ("Bitbefehle"). Im Gegensatz zu normalen Anwendungungsprozessoren muss aber nicht bei jeder Bitverarbeitung umfangreich maskiert werden. > Man müsste also eher bei Cortex-R schauen, und da ist die Auswahl schon > knapper (und teurer!). Auch Cortex-R-Prozessoren sind nicht auf Einzelbitverarbeitung optimiert.
Niklas G. schrieb: > Das sind aber Anwendungsprozessoren. Die können nicht konsistent mit 500 > MHz Pins samplen Es geht auch nicht um einen Eingang, sondern um ein Bit. Das ist eine logische Informationseinheit (löse mal ein paar Kreuzworträtsel, da wird das ab&zu gefragt) im Prozessor. Der Prozessor braucht für die Verarbeitung eines Bits überhaupt keine EA. Und deshalb ist es auch völlig irrelevant, wie schnell die Eingänge eingelesen werden können.
:
Bearbeitet durch Moderator
Andreas S. schrieb: > Hast Du Dich überhaupt schon einmal mit der Funktionsweise "richtiger" > SPS befasst? Nö, das kommt in meiner Profession (Informatik) absolut nicht vor. Andreas S. schrieb: > Ich gehe ganz schwer davon aus, dass bei den ASICs in den Siemens-SPS > das Aktualisieren des Prozessabbildes für lokale Module(!) nahezu > komplett in Hardware realisiert sein wird. Aha, aber bei den gezeigten Cortex-A wohl nicht. Andreas S. schrieb: > Die Angabe bezieht sich wohl auf reine Registeroperationen > ("Bitbefehle"). Wenn das so ist, macht es Sinn. Das kann ein Cortex-A im Durchschnitt (!) auch, aber eben nicht garantiert. Andreas S. schrieb: > Auch Cortex-R-Prozessoren sind nicht auf Einzelbitverarbeitung optimiert Aber darauf, Befehle mit vorhersehbarer Latenz auszuführen. Lothar M. schrieb: > löse mal ein paar Kreuzworträtsel Wenn ich in Rente bin. Lothar M. schrieb: > Und deshalb ist es auch völlig irrelevant, wie schnell die Eingänge > eingelesen werden können. Die Informationen müssen ja schon irgendwo her kommen, oder soll die Maschine lediglich simuliert werden?
Niklas G. schrieb: > Die Informationen müssen ja schon irgendwo her kommen Wer sagt das? Für so eine Marketingangabe/Werbeaussage/Idealzustand/Traumwert/usw. reicht es aus, anzunehmen, die Daten wären schon vorhanden. > oder soll die Maschine lediglich simuliert werden? Wenn dadurch eine Bitverarbeitungszeit von 2ns erreicht wird, dann darf man auch das annehmen. > Lothar M. schrieb: >> löse mal ein paar Kreuzworträtsel > Wenn ich in Rente bin. Immerhin ein Lichtschimmer am Ende des Tunnels.
:
Bearbeitet durch Moderator
Niklas G. schrieb: > Aha, aber bei den gezeigten Cortex-A wohl nicht. Es geht hier aber ganz konkret um die in Siemens S7-1500 enthaltenen Prozessoren/ASICs.
Andreas S. schrieb: > Niklas G. schrieb: > >> Aha, aber bei den gezeigten Cortex-A wohl nicht. > > Es geht hier aber ganz konkret um die in Siemens S7-1500 enthaltenen > Prozessoren/ASICs. Ich habe aber ganz konkret auf Lothars Anmerkungen geantwortet, dass das so mit dem Cortex-A ginge.
Im Datenblatt stehen auch die Ausführungszeiten von anderen Operationen. Und die Angabe reicht auch für dass was man damit macht.
Andreas S. schrieb: > Dirk F schrieb: >> Was ist denn da für eine MCU drin ? > > Das sind proprietäre ASICs. Die für normale Entwickler zugängliche > Programmiersprache AWL und das zugehörige Registermodell stellen somit > eine Teilmenge des Funktionsumfanges der CPU dar. Jain. AWL wird normalerweise auf der CPU interpretiert ( war schon immer so ) Inzwischen verwendet Siemens aber auch Compiler die AWL, KOP, FUP, ST (sowas wie Pascal) und neuerdings manchmal sogar C direkt in den passenden Maschinencode für die SPS übersetzen. Die 2ns beziehen sich auf compilierten Code. >> Die müsste ja mindestens mit 1 GHz getaktet sein, oder ? Ja sind sie auch. Der Inhalt des Gehäuses besteht zu 70% aus Kühlkörper, zusätzlich fungiert die Montageschiene als Wärmeableiter. > Vermutlich. Es gibt ja auch etliche ARM-basierten Prozessoren mit > Taktfrequenzen in diesem Bereich. Bei der ist aber kein ARM drinnen :-) Siemens verwendet alle möglichen Architekturen in Ihren PLCs. Gerade in den kleineren auch gerne aus dem Automotive Bereich.
Niklas G. schrieb: > Ich habe aber ganz konkret auf Lothars Anmerkungen geantwortet, dass das > so mit dem Cortex-A ginge. Ich habe nirgends behauptet, dass da drin ein Cortex A werkelt. Ich habe lediglich behauptet, dass schon eine 10€ CPU im GHz-Bereich solche logischen Elementarfunktionen im ns-Bereich abhandeln kann. Und dann auf die Deduktionsfähigkeit vertraut, dass eine tausendmal teurere Steuerung das sicher noch besser und schneller hinbekommt. Hat offenbar nicht bei jedem geklappt. Pech. Also nochmal die kurze Variante: Dirk F schrieb: > ich sehe bei der Siemens S7-1500 eine Bitbearbeitungszeit von 2 ns. Ja, der aktuelle Stand der Technik gibt das her.
Andreas M. schrieb: > Bei der ist aber kein ARM drinnen :-) Genau das hatte ich ja auch geschrieben. Da aber ein typischer SPS-Prozessor ganz grob ähnliche Anforderungen wie ein aktueller ARM hat, dürften hierfür ähnliche Halbleiterprozesse eingesetzt werden. Somit lassen sich dann auch ähnliche Taktfrequenzen erreichen.
Lothar M. schrieb: > Hat offenbar nicht bei jedem geklappt. Pech Das hab ich alles schon genau so verstanden. Ich weiß überhaupt nicht, wie man darauf kommt, dass ich behauptet hätte, SPS würden Cortex-A nutzen oder was eine SPS kann oder nicht kann. Ich wollte lediglich klar stellen, dass der Cortex-A (der sich NICHT in einer SPS befindet!!!) externe Pinsignale eben nicht mit 2ns Latenz bearbeiten kann, man also eben nicht mit einem Cortex-A so eine Verarbeitungszeit erreichen kann. Also nur der Cortex-A auf einem gängigen Board. Nicht in einer nichtexistenten SPS. Wenn der Cortex-A das nicht kann, folgt daraus nicht, dass die SPS das kann. Ob die SPS das tatsächlich doch kann oder die 2ns nur intern sind, weiß ich nicht. Der Preis ist übrigens ziemlich losgelöst von der Leistung. So ein ARM-Anwendungsprozessor ist um viele Größenordnungen komplexer und leistungsfähiger als ein ähnlich teurer Mikrocontroller, das kommt also nur von der Massenfertigung. Nur weil ein massengefertigter 10€-Prozessor etwas kann heißt das nicht, dass ein für SPS gebauter Spezialprozessor das auch für 10€ kann.
:
Bearbeitet durch User
Andreas S. schrieb: > Da aber ein typischer > SPS-Prozessor ganz grob ähnliche Anforderungen Heute wird in SPSen eigentlich nur noch Stangenware eingesetzt. Das höchste der Gefühle ist es einen Standard CPU Chiplet zu nehmen und den eventuell noch mit einem extra Chiplet für die Kommunikation im selben Package zu kombinieren. Meist ist aber der Kommunikationsprozessor extern per PCIe angebunden. Die ganz alten Simotion Controller D435 (Die es jetzt nicht mehr gibt, also nicht die D435-2) hatten z.B. ne Pentium III CPU + eine Siemens Profinet Baugruppe. Der Pentium wurden mit einem speziellen RT Linux betrieben, da konnte/musste man sogar Bios-Updates einspielen :-) Niklas G. schrieb: > Ob die SPS das tatsächlich doch kann oder die 2ns nur intern sind, weiß > ich nicht. Wie schon mehrfach in dem Thread beschrieben geht es hier rein um die Zeit die die SPS benötigt um zwei im RAM liegende Variablen miteinander Bit zu verküpfen. Und genau das beschreibt die Siemens Angabe. IOs sind bei solchen SPS fast immer remote, also über Netzwerk angeschlossen, Aktualisierungszeit typischerweise 1-2ms.
Dirk F schrieb: > Was ist denn da für eine MCU drin ? > Die müsste ja mindestens mit 1 GHz getaktet sein, oder ? Ich lese das als 500MHz (=1/2ns). Zum Vergleich: Ein Teensy 4.0 oder 4.1 hat einen 600 MHz µC drauf.
Jim M. schrieb: > Ich lese das als 500MHz (=1/2ns). Das 1GHz bzw. die 600MHz sind auch nur die Taktfrequenz zur schnellstmöglichen Ausführung eines NOPs.
Lothar M. schrieb: > Das 1GHz bzw. die 600MHz sind auch nur die Taktfrequenz zur > schnellstmöglichen Ausführung eines NOPs. Das ist die Kernkompetenz einer SPS, besonders von Siemens! ;-) Die Aussage ist, wie schon mehrfach festgestellt, wertloses Marketinggeschwätz. Ob eine SPS damit schnell ist oder nicht, entscheiden viele andere Komponenten, sei es das Betriebssystem, der Compiler und last but not least das Anwenderprogramm! Auch moderne PCs kann man MÜHELOS mit Müll in die Knie zwingen, das ist kinderleicht. Alles nix Neues.
Andreas S. schrieb: > Ich gehe ganz schwer davon aus, dass bei den ASICs in > den Siemens-SPS das Aktualisieren des Prozessabbildes für lokale > Module(!) nahezu komplett in Hardware realisiert sein wird. Nein, auch Deine sonstigen Vorstellungen über SPSen sind eher Träumereien. SPSen haben ganz normale Prozessoren. Die kleinen SPSen haben kleine Mikrocontroller, die mittleren SPSen haben mittlere Controller, und die fetten SPSen haben eben PC-Prozessoren. Der ASIC in SPSen ist der vom jeweiligen Hersteller propagierte, eigene Bus-Chip. Bei Siemens der Profinet-Kram, bei Beckhoff der Ethercat-Kram, usw. SPSen sind nicht besonders schnell. Sie sind eigentlich relative lahm im Vergleich zu einem normalen PC. Für manche Bewunderer erscheinen sie nur schnell, weil die Programme auf SPSen trivial sind. Die paar Kilobyte Daten und Programmcode passen komplett in den L1-Cache der verwendeten CPUs. Dazu fast ein komplett linearer Programmablauf, da kommt Prefetch voll zum tragen. Und auch die großen Kühlkörper haben einen simplen Grund: Mittelprächtige Alltagsprozessoren die passiv gekühlt auch bei höheren Umgebungstemperaturen laufen sollen. Nein, an einer SPS ist nichts besonderes dran. SPS ist viel Marketing und Vendor-Lockin und "Haben wir schon immer so gemacht". SPSen leben von ihrer modularen IO-Hardware die so robust und flexibel gebaut ist, dass sie auch der Behandlung von Grob-Elektrikern widersteht und auch bei Nichtbeachtung irgendwelcher EMV-Überlegungen durch unwissenden Elektrokonstrukteure trotzdem funktioniert. SPSen gibt es weil das Zeug mechanisch und elektrisch robust ist aber nicht wegen der mäßigen Rechenleistung der CPUs.
Siemens soll für SPS-Geräte einen eigenen Hauptprozessor haben? Das ich nicht lache. Die haben über Jahrzehnte hinweg nichts hinbekommen ausser den ollen (von Intel abgekupfterten) 8051, und '166er. (später dann TriCore (was definitiv gelogen ist, denn es sind keine 3 Kerne)). Auch steckt in der Angabe "2ns/Bitbefehl" keine Information, auf welch grossen Speicher sich das bezieht, ob es über SIMD geht, und wie das überhaupt adressiert werden kann. (es ist - falls es überhaupt stimmt - wohl jeweils das simpelste (!) anzunehmen) (auch kennt der typ. SPS-Programmier weder SIMD noch Adressierungsarten). Die Zykluszeit ist (wie schon genannt) auch grottenschlecht, Bereich ms nicht ns. Bei Siemens ist sehr viel Angebertum mit dabei. Stinknormale EPROM-Module haben die für hunderte EUR verkauft.
MCUA schrieb: > > (später dann TriCore (was definitiv gelogen ist, denn es sind keine 3 > Kerne)). Du hast offensichtlich nicht verstanden woher der Name "TriCore" kommt. Ein wenig dazu steht hier: https://de.wikipedia.org/wiki/Infineon_TriCore
"TriCore" kommt daher, dass Siemens den Leuten die Periferie als eigenen Kern (!) verklickern will, was Quatsch ist.
MCUA schrieb: > später dann TriCore (was definitiv gelogen ist, denn es sind keine 3 > Kerne)) Aktuelle TriCore haben bis zu 6 Kerne, und das sind echte Prozessorkerne, jeweils mit eigenen Speicherblöcken (SRAM+Flash) und Caches ausgestattet. Unter "ferner liefen" kommt noch ein 8051-LowPower-Prozessor dazu. Die Flash-Zugriffe erfolgen über 6 weitere Spezial-Prozessorkerne, welche man zum Flashen (z.B. Bootloader) mit Befehlen füttern muss. Das sind richtig komplexe Schlachtschiffe, so ein popeliger STM32H7 o.ä. ist nichts dagegen. Die Komplexität dürfte sogar einen Cortex-A8 übertreffen, so ein TI AM335x ist einfacher Bare Metal zu programmieren. Auch die Toolchains sind nicht ohne, da wünscht man sich die wunderschön einfach elegante STM32CubeIDE zurück.
Niklas G. schrieb: > richtig komplex > Komplexität > TI AM335x ist einfacher Bare Metal zu programmieren > Toolchains sind nicht ohne Wenn man nur genügend Komplexität in das System einbringt, kann man die Bugs vor lauter Komplexität gar nicht mehr finden, Genies sind das!!1
MCUA schrieb im Beitrag MCUA schrieb: > (später dann TriCore ( Wo hast du die Info her? Nie einen Tricore in einer 300 oder 400er gesehen.
...und wer verkauft das? TriCore ist raus gekommen 1997, 1 Kern, RISC-CPU mit DSP-Befehlen, Periferie, sollte ca 80MHz. Holz-Elektronik hat damit geprahlt wie sonst was. Spätestens 1999 wird das den Markt völlig umkrempeln, sagten die. Geliefert haben Sie: Nichts. Für GeneralPurpose ist TriCore eher nicht existent.
Fred R. schrieb: > > Nie einen Tricore in einer 300 oder 400er gesehen. Ich habe das mit den TriCore zwar nicht geschrieben aber hier sieht man zumindest einen TriCore auf der Platine: http://s7detali.narod.ru/S7_317/S7_317.html Ist das eine 300er oder eine andere Geräteklasse?
MCUA schrieb: > Die Zykluszeit ist (wie schon genannt) auch grottenschlecht, Bereich ms > nicht ns. Du hast Null Ahnung laberst aber einen Haufen Blödsinn. Die Trägheit einer Ventilinsel oder eines Temperatursensors ist Faktor 100 größer als 1ms Zykluszeit. Warum also den Bus (das Netzwerk) sinnlos mit Daten auslasten. Da packt man lieber 256 Remote I/Os bei 4ms oder ähnlich dran. (Das sind dann schon 50% bei 100 MBit/s) Die 400er CPUs können sogar noch mehr. Schließlich soll über die selbe Leitung ja auch noch IP Telefone am Ende der Halle und die Arbeiter PCs gehen. Eine 1517/1518 schafft deterministisch 250µs Zykluszeit in der Applikation mit einer Abweichnung von max 1µs (eher besser) über die gesamte Anlagenausdehnung, das können viele 100m Kabel sein.
Dieter schrieb: > http://s7detali.narod.ru/S7_317/S7_317.html > > Ist das eine 300er oder eine andere Geräteklasse? Ja, das ist eine (alte) 300er. Die hat noch nicht mal nen Ertec drinnen. (Hat nur einen Port) Die 300er sind aber schon länger am Auslaufen. Wobei sich die Modelle einer Baureihe massiv unterscheiden können. Die letzten zwei Ziffern sind ein Indikator für die Performance.
>> Die Zykluszeit ist (wie schon genannt) auch grottenschlecht, Bereich ms >> nicht ns. >Du hast Null Ahnung laberst aber einen Haufen Blödsinn. Du redest hier den Blödsinn. Schon mal eine CPU von innen gesehen? Die Zykluszeit ist so schlecht, wegen extrem grossen Overhead vom System. Wenige us sind damit nicht machbar. Und das eine schnarchlangsame Ventilinsel im ns_Bereich schalten soll hat hier keiner behauptet.
Dieter schrieb: > 2ns pro bit sind 65MHz fuer 1 byte. Nichts weltbewegendes. Das Oszi mit > 1GS hat demnach 0,125ns oder 125ps pro bit. So betrachtet könnt ein Marketeer die CPU meines Laptops mit 100 Femtosekunden pro Bit anbieten. ;-)
:
Bearbeitet durch User
(prx) A. K. schrieb: > So betrachtet könnt ein Marketeer die CPU meines Laptops mit 100 > Femtosekunden pro Bit anbieten. ;-) Hat das was mit Feminismus und #metoo zu tun?
Für dich: 0,1 ps. Jetzt komm aber nicht mit Autos. ;-)
:
Bearbeitet durch User
Andreas M. schrieb: > Dieter schrieb: >> http://s7detali.narod.ru/S7_317/S7_317.html >> >> Ist das eine 300er oder eine andere Geräteklasse? > > Ja, das ist eine (alte) 300er. Die hat noch nicht mal nen Ertec drinnen. > (Hat nur einen Port) Die 300er sind aber schon länger am Auslaufen. > Wobei sich die Modelle einer Baureihe massiv unterscheiden können. Die > letzten zwei Ziffern sind ein Indikator für die Performance. Auf der obigen Webseite findet man weiterer Bilder von anderen Geräteklassen. Interessant ist auch die Analyse des SoC einer 1200 hier: https://sec-consult.com/blog/detail/reverse-engineering-architecture-pinout-plc/
Bei einer Annahme ver-AND-ung von max 54 int. vorliegend. Bits mit anschliessender ver-OR-ung max 5 dieser Terme schafft das ein 95XLer-PLD in lediglich ca 0,0044 ns / Bitbefehl. Bei max 15 dieser Terme sind es lediglich ca 0,0022 ns / Bitbefehl.
MCUA schrieb: > ...und wer verkauft das? > TriCore ist raus gekommen 1997, 1 Kern, RISC-CPU mit DSP-Befehlen, > Periferie, sollte ca 80MHz. > Holz-Elektronik hat damit geprahlt wie sonst was. > Spätestens 1999 wird das den Markt völlig umkrempeln, sagten die. > Geliefert haben Sie: Nichts. > Für GeneralPurpose ist TriCore eher nicht existent. Der allererste TriCore den es gab, war tatsächlich mal für Industriezwecke angedacht und hatte sogar eine MMU und es gab ein portiertes Linux dafür. Inzwischen automotive only und eher als größere uC Architektur angedacht.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.