Hallo Forum,
manchmal beschäftigen mich grundsätzliche Fragen, die mich nicht mehr
loslassen. Ich habe auf Hobbybasis angefangen mich mit Mikrocontrollern
zu beschäftigen und versuche stets meine Schaltungen und Codes
"professioneller" zu gestalten. Deshalb die Frage:
Wann sollte man Funktionen in Software und wann in Hardware zu lösen?
Ich könnte z.B. einen leistungsstarken Mikrocontroller nehmen, der viele
Funktionen hat und mit diesem alle Funktionen realisieren. Oder ich
verwende einen kleineren Mikrocontroller und lagere Funktionen, wie PWM,
etc. in Hardware oder in andere ICs aus, sodass der uC nur noch die
Aufgaben koordinieren muss. Wo geht da der Trend hin? Was sind die
Vorteile? Ist es ausfallsicherer Funktionen in Hardware zu realisieren?
Soll jetzt zwar eine Grundsatzdiskussion sein, aber ich kann euch gerne
ein Beispiel geben:
Als Hobby baue ich mir eigenes Lasertag Equipment. Hierzu erzeuge ich
u.a. mit einer Infrarot-LED ein Signal mit einer Trägerfrequenz von 38
kHz, welches nach dem RC5 Protokoll moduliert wird (600 us an, 600 us
aus, etc.).
Zusätzlich steuere ich einen Piezzo mit PWM an um Töne zu modulieren.
Gleichzeitig benötge ich noch ein paar Timer.
Zurzeit verwende ich einen Atmega8, da wird das mit den Timern und PWM
Kanälen etwas eng.
Ich überlege mir z.B., dass ich das Erzeugen des Trägersignals mit einem
NE555 realisiere, sodass der uC nur noch die 1er und 0er des Signals
modulieren muss. Dadurch könnte ich den uC bei entspannten 1 MHz laufen
lassen.
Gibt es allgemeine Vor- bzw. Nachteile beider Versionen? Z.B.
Lötaufwand, EMV, etc.? Hat da jemand Erfahrungen / Meinungen?
Liebe Grüße
René
Kibo schrieb:> Gibt es allgemeine Vor- bzw. Nachteile beider Versionen?
Natürlich!
Kibo schrieb:> Hat da jemand Erfahrungen / Meinungen?
Ja klar!
Befrage drei Imker zu einem Bienenproblem, und du wirst min. fünf
verschiedene Meinungen hören. Und alle haben ihre Berechtigung, obwohl
sie sich widersprechen.
Kibo schrieb:> Zurzeit verwende ich einen Atmega8, da wird das mit den Timern und PWM> Kanälen etwas eng.
Naja, mit dem Saurier kann es schon mal eng werden, aber warum nimmst du
nichts moderneres?
Die Mega48/88/168/328 sind pinkompatibel zum Mega8 und haben neben dem
Pinchange IRQ Feature auch noch mehr Speicher. Ein NE555 ist nicht nur
ein Stromverbraucher, sondern auch höchst unflexibel, was eine
Frequenzänderung betrifft.
Kibo schrieb:> Gibt es allgemeine Vor- bzw. Nachteile beider Versionen? Z.B.> Lötaufwand, EMV, etc.? Hat da jemand Erfahrungen / Meinungen?
Ich würde soviel wie mögich in Hardware lösen, aber solcher Hardware,
die im Controller drin ist.
D.h. als Peripheral im µC. Für das konkrete Beispiel würde ich halt
einen µC mit passender Timerstruktur nehmen.
Beispielprojekt von mir:
Ein IR-Sender als USB-Stick, umgesetzt mit einem PIC24F128GB202.
Datenblatt:
http://ww1.microchip.com/downloads/en/DeviceDoc/30005009c.pdf
Das IR macht ein OC-Timer + Data signal modulator + SPI. Theoretisch
könnte man so sogar über DMA senden, ohne den Kern zu beschäftigen. USB
macht das USB-Peripheral, das geht bei dem Controller ohne Quarz.
Entsprechend ist außer einer IRLED, einem MPC1755 (Spannungsregler) und
etwas Hasenfutter nichts nötig.
Die Platine ist winzig (größte Bauteile: Stecker), und trotzdem gut
verarbeitbar. Trotzdem macht sowas Spass, ist halt mehr Firmware als
Hardware.
Da kommts halt drauf an, was man machen will.
Geht so natürlich mit vielen verschiedenen µC-Familien, nicht nur PICs.
Da die Mikrocontroller immer leistungsfähiger geworden sind,
macht man heute, bis auf Spezialfunktionen wofür es extra ICs gibt,
fast alles mit µC.
Da auch leistungsfähige µCs sehr günstig sind, nimmt man gerne einen
überdimensionierten Typ. Dann braucht man nicht für jedes Projekt einen
anderen Typ. Deshalb überall die ARMs...
Genial finde ich das Eventsystem in den moderneren Prozessoren
(wie z.B. beim XMega)!
Da kannst du die eingebauten Peripherieeinheiten (wie Timer, PWM, DMA
und Schnittstellen) sehr komplex direkt miteinander "verdrahten".
Das hat gleich mehrere Vorteile:
- sehr schnell (ein Takt!) <==> Interupt (viele Takte nur für 'rein und
'raus)
- immer gleiches, verlässliches Timing!
- keine Prozessorlast, da dies von SW autonom abläuft
>> Dadurch könnte ich den uC bei entspannten 1 MHz laufen
lassen.
Das ist gar nicht entspannend, wenn du in SW Laufzeitprobleme bekommst!
Also wenns schnell gehen muss nimmt man die maximale Taktfrequenz.
Es sei denn, dass der Stromverbrauch wegen Akku ein Problem ist.
Kibo schrieb:> Wann sollte man Funktionen in Software und wann in Hardware zu lösen?
Wenn die Stückzahl gering ist nehme ich immer die höher integrierte
Lösung die meist ein paar % teurer ist => lieber fetterer µC als kleiner
µC + viel Hühnerfutter
YMMV
Anno schrieb:> Da auch leistungsfähige µCs sehr günstig sind, nimmt man gerne einen> überdimensionierten Typ. Dann braucht man nicht für jedes Projekt einen> anderen Typ. Deshalb überall die ARMs...
Besser man nimmt den richtigen µC als den schnellsten. Nur weil ARM
draufsteht, heißt das nicht, dass der µC besonders toll ist. Vom Kern
merkt der Programmierer sowieso wenig, und wenn das Konzept erfordert,
dass der Prozessorkern alles macht, ist es sowieso schon fast
gescheitert.
Egal wie schnell ein µC ist, ein spezialisiertes Peripheral schlägt er
nicht. Also nicht nach Kern aussuchen, sondern nach dem was man braucht.
Ob da ein ARM, RISC-V oder MIPS drin ist, kümmert im Höchstfall den
Compiler. Lediglich Leistungsklasse, vorhandene Software und Toolchain
müssen natürlich stimmen.
Weitere Möglichkeiten sind natürlich FPGA/CPLD und Bausteine wie Xilinx
Zynq, die dann interessant werden, wenn man mit der integrierten
Peripherie eines Microcontrollers nicht alle Anforderungen abdecken
kann. Für Demonstratoren und einige Produkte in Kleinserie nehme ich
daher gerne und erfolgreich ein Modul mit Artix-7 und Microblaze.
Preislich spielt das natürlich in einer anderen Liga als die meisten
Microcontroller.
Kibo schrieb:> Wann sollte man Funktionen in Software und wann in Hardware zu lösen?
Auf diese Frage gibt es keine allgemein gültige Antwort. Ich glaube
sogar, daß es auch für eine konkrete Problemstellung keine
allgemeingültige Antwort geben wird, weil das Optimum nicht nur vom
Problem, sondern auch vom Problemlöser abhängt.
Für jemanden, der noch nie einen µC programmiert hat, liegt das Optimum
ganz klar bei mehr Hardware. Hatten wir gerade einen Thread zu:
Beitrag "Schaltung für 5V für 4,5 oder 3V umbauen"
Für jemanden, der einen µC programmieren kann, ist dieses Logik-IC-Grab
ganz klar suboptimal und einfach mit einem z.B. ATMega48 zu ersetzen.
Für den TE dort, nach eigener Einschätzung
> absoluter Anfänger im Bereich Elektronik
wird aber nur das IC-Grab eine realistische Lösung sein.
Man kann die Frage aber auch unter anderen Gesichtspunkten betrachten.
Wenn man bspw. die Massenfertigung anschaut, dann gewinnt ganz klar die
Software, weil sie nicht auf die Stückkosten aufträgt.
Oder wenn es um den Spieltrieb geht, dann haben ganze Generationen von
Hackern (im positiven Wortsinn) versucht, durch geschickte
Programmierung das Maximum aus eigentlich beschränkter Hardware
herauszuholen. Man denke nur an die Demo-Szene von C64, Amiga & Co. Oder
an Leute wie Elm oder Linus Akesson.
Kibo schrieb:> Ich überlege mir z.B., dass ich das Erzeugen des Trägersignals mit einem> NE555 realisiere, sodass der uC nur noch die 1er und 0er des Signals> modulieren muss.
Der ATmega328PB hat bereits einen Output Compare Modulator:
"The Output Compare Modulator (OCM) allows generation of waveforms
modulated with a carrier frequency. The modulator uses the outputs from
the Output Compare Unit B of the 16-bit Timer/Counter3 and the Output
Compare Unit of the 16-bit Timer/Counter4."
Anno schrieb:> - sehr schnell (ein Takt!) <==> Interupt (viele Takte nur für 'rein und> 'raus)
So ich (Umsteiger von Arduino auf PIC) hänge mich mal ein.
Habe ich diesen Satz richtig verstanden das ein Interrupt an die MHZ
gekoppelt ist, sprich bei 20 MHZ, wird der externe Interrupt alle 50 ns
oder 20 Mio mal pro Sekunde ausgewertet.
Oder würde es ausreichen wenn der Externe Interrupt noch kürzer ist z.B.
1 ns ?
Oder macht es einen Unterschied ob es ein externer oder ein z.B.
Interner Timer Interrupt ist.
Aus der Arduino Welt weis ich halt das z.B. das Auslesen eines Pins
"relativ" lange dauert.
Ps. Hintergrund: Ich plane gerade eine Lichtschranke für
Insektenfotografie im Makro bereich und da sind ein paar Millisekunden
eine Rechnerische Katastrophe
Thomas F. schrieb:> Anno schrieb:>> - sehr schnell (ein Takt!) <==> Interupt (viele Takte nur für 'rein und>> 'raus)>>> So ich (Umsteiger von Arduino auf PIC) hänge mich mal ein.>> Habe ich diesen Satz richtig verstanden das ein Interrupt an die MHZ> gekoppelt ist, sprich bei 20 MHZ, wird der externe Interrupt alle 50 ns> oder 20 Mio mal pro Sekunde ausgewertet.>> Oder würde es ausreichen wenn der Externe Interrupt noch kürzer ist z.B.> 1 ns ?
Das steht im Datenblatt deines Controllers. Ein Takt wird aber
sicherlich reichen.
> Oder macht es einen Unterschied ob es ein externer oder ein z.B.> Interner Timer Interrupt ist.
Ein intern generierter Timer-Interrupt hat keine Länge ...
> Aus der Arduino Welt weis ich halt das z.B. das Auslesen eines Pins> "relativ" lange dauert.
Auslesen eines Pins und Triggern eines Interrupts sind zwei verschiedene
Dinge. Das eine tut die Software, das andere die Hardware.
Danke für die vielen Antworten, es macht richtig Spaß das Ganze zu
lesen!
Ich habe das jetzt so verstanden:
Aufgaben in Software lösen:
Pro:
-Kann später noch upgedated werden (Hardware beschränkt die Funktion)
-Weniger externe Bauteile (weniger Materialkosten und Lötarbeit)
-Baugröße
-ggf. geringerer Stromverbrauch
Con:
-?Wie sieht es mit Zuverlässigkeit aus (kommen bei erfahrenen
Programmierern keine Fehler mehr in der Programmierung vor)?
So noch zu ein paar Kommentaren:
Arduino Fanboy D. schrieb:> Befrage drei Imker zu einem Bienenproblem, und du wirst min. fünf> verschiedene Meinungen hören. Und alle haben ihre Berechtigung, obwohl> sie sich widersprechen.
Das fasziniert mich immer wieder. Ich habe oft gedacht, dass es für
jedes Problem eine Antwort aus dem Lehrbuch gibt. Ich bin immer wieder
erstaunt, wie oft es keine "perfekte" Lösung gibt.
Matthias S. schrieb:> Naja, mit dem Saurier kann es schon mal eng werden, aber warum nimmst du> nichts moderneres?
Ja, ich hatte mit dem Tutorial hier auf der Seite angefangen und da war
der Atmega8 verwendet worden. Deshalb hatte ich ihn gewählt.
Mittlerweile sind meine Kenntnisse schon besser aber für die jetzige
Generation vom Equipment werde ich wohl noch beim Atmega8 bleiben. In
Zukunft werde ich mich dann mal umschauen, was es noch so an uC gibt
(danke für die Tipps) und es dann auch in C und nicht mehr in Assembler
programmieren.
Mir ist auch die on-chip-Hardware das liebste.
Es gab/gibt auch den Ansatz, Hardware durch massive Rechenpower zu
ersetzen (Propellerchip, mehrere 32er Kerne mit damals gigantischen
80MHz, aber keine speziellen Peripherie-Funktionen).
Soweit ich das beurteilen kann hat sich das nicht so recht durchgesetzt.
Thomas F. schrieb:> Habe ich diesen Satz richtig verstanden das ein Interrupt an die MHZ> gekoppelt ist, sprich bei 20 MHZ, wird der externe Interrupt alle 50 ns> oder 20 Mio mal pro Sekunde ausgewertet.
Deine Frage ist komplizierter, als dir klar ist. Der Interrupt (ich gehe
davon aus, dass es ein asynchroner, externer Interrupt ist) muss auf den
Takt des µC einsynchronisiert werden. Das wird mal eine Taktperiode
dauern. Dann hat der µC selber möglicherweise eine Verzögerung.
Und dann dauert es, bis er in der ISR ist. Man nennt das Interrupt
Latency.
1ns wird nicht ausreichen!
Details kann man üblicherweise in den Datenblättern nachlesen.
Für PIC24 kann man das da nachlesen:
http://ww1.microchip.com/downloads/en/devicedoc/39707a.pdf
Allgemein wird dein Interrupt immer um mindestens 1 Taktperiode Jittern,
schon wegen der Synchronisation.
Cragy Wägy schrieb:> die kann man über> Bootloader immer wieder updaten - das geht mit Hardware nicht.
Gerade das ist ja der Vorteil von Hardware, die kann nach der
Auslieferung an den Kunden nicht durch das falsche Update Kaputt gemacht
werden...
Deshalb werden (Überlebenskritische) Funktionen in Hardware realisiert.
Und manche Software ist inzwischen so komplex, daß man sich nicht mehr
in der Lage sieht, deren 100% Korrektheit durch Tests nachzuweisen. Oder
ist einfach zu langsam, wenn schnell reagiert werden muß:
https://www.n-tv.de/wirtschaft/Neue-ICEs-bremsen-zu-langsam-article9599211.html
Der Teufel steckt in der Software schrieb:> Und manche Software ist inzwischen so komplex, daß man sich nicht mehr> in der Lage sieht, deren 100% Korrektheit durch Tests nachzuweisen.
Das ist nicht nur bei hochkomplexer Software so :-)
Der Teufel steckt in der Software schrieb:> Gerade das ist ja der Vorteil von Hardware, die kann nach der> Auslieferung an den Kunden nicht durch das falsche Update Kaputt gemacht> werden...
Ggf. trifft man einfach Vorkehrungen, damit der Kunde nicht selbst ein
Firmwareupdate durchführen kann. Bei (einigen) medizinischen
Röntgengeräten muss für ein Update eine versiegelte Klappe geöffnet und
das darunter befindliche EPROM entnommen und durch ein neues EPROM
ersetzt werden. Natürlich besitzt das EPROM ein entsprechendes
Sicherheitssiegel. Der Techniker des Herstellers bekommt auch nur die
EPROMs ausgehändigt, die er in den Geräten einbauen soll, und muss auch
alle ausgebauten EPROMs wieder zuhause abgeben. Natürlich könnte er
heimlich ein eigenes Geschäft betreiben, indem er die Firmware aus den
EPROMs ausliest und kopiert.
Bei neueren Geräten wird man wohl eher mit kryptografisch signierten
Firmware images arbeiten, die natürlich auch die entsprechenden
Kompatibilitätslisten zu Gerätetypen und vorherigen Firmwareständen
enthalten können. Ggf. kann man darin sogar auch die Seriennummern der
updatebaren Geräte unterbringen. Für einen Kunden habe ich hierbei ein
Updateverfahren entwickelt, bei dem nach der kryptografischen
Signaturprüfung ein im Firmwareimage enthaltenes Skript ausgeführt wird.
Hierdurch können z.B. auch Überprüfungen und Umstrukturierungen im
Flash-Dateisystem erfolgen, die in dieser Form bei älteren
Firmwareständen noch nicht angedacht waren.
Der Teufel steckt in der Software schrieb:> Deshalb werden (Überlebenskritische) Funktionen in Hardware realisiert.
Vor langer, langer Zeit, in einem Land, weit weit entfernt.
Geschichten aus 1001 Nacht :-)
Das ist schon lange nicht mehr so.
Ich habe schon an mehreren SIL3-Systemen gearbeitet. In jedem waren µC
im sicherheitskritischem Bereich verbaut.
Kibo schrieb:> Aufgaben in Software lösen:> Pro:> -Kann später noch upgedated werden (Hardware beschränkt die Funktion)> -Weniger externe Bauteile (weniger Materialkosten und Lötarbeit)> -Baugröße> -ggf. geringerer Stromverbrauch>
Beim FPGA kannst du auch nachträglich die Hardware updaten. Gibt
FPGA-Boards, die du übers Netzwerk mit einer neuen Identität bespielen
kannst.
Geringerer Stromverbrauch: Nur bedingt. Wenn du aufwendigere Rechnungen
durchführst, macht ein FPGA ev. die bessere Nummer.
> Con:> -?Wie sieht es mit Zuverlässigkeit aus (kommen bei erfahrenen> Programmierern keine Fehler mehr in der Programmierung vor)?
Haha. Und wie die vorkommen!
Da gibt es eine Menge Klassiker mit uninitialisierten Registern, usw.
Die treten in allen möglichen Code-Checks (MISRA, und weitere
Augenwischerei) nicht auf, dafür dann in der Simulation.
Ich würde behaupten, dass in Zukunft diesbezüglich nicht mehr gross
zwischen Hard/Software unterschieden wird, zumindest im Embedded
Computing.
Manche Leute (mich eingeschlossen) bauen sich auch eigene CPU-Systeme im
FPGA, um die korrekte Funktion vollständig nachweisen zu können. Da
verschwimmt Hard/Software ziemlich, d.h. du kannst der Software bitgenau
und zeitakkurat beim Zappeln zusehen.
jemand schrieb:> Das ist schon lange nicht mehr so.> Ich habe schon an mehreren SIL3-Systemen gearbeitet. In jedem waren µC> im sicherheitskritischem Bereich verbaut.
Ja, und dementsprechend gibt es da eine Menge Schluderei. Mir sind auch
schon SIL3-Systeme unter die Augen gekommen, wo offenbar MISRA-C und
etwas MTBF-Analyse ausreicht, um den TüV-Stempel zu bekommen. Trotz
verbautem, nicht sicherheitszertifiziertem ARM-Kern.
Gut, dass wenigstens Aerospace noch einigermassen Standard hat.
>Gerade das ist ja der Vorteil von Hardware, die kann nach der>Auslieferung an den Kunden nicht durch das falsche Update Kaputt gemacht>werden...
In HW kriegt man ihn dafür nie wieder raus.
>...deren 100% Korrektheit durch Tests nachzuweisen.
Man kann nur Anwesenheit von Bugs beweisen - aber nicht ihre
Abwesenheit. Das gilt generell - für HW und FW.
Fitzebutze schrieb:> Ja, und dementsprechend gibt es da eine Menge Schluderei. Mir sind auch> schon SIL3-Systeme unter die Augen gekommen, wo offenbar MISRA-C und> etwas MTBF-Analyse ausreicht, um den TüV-Stempel zu bekommen. Trotz> verbautem, nicht sicherheitszertifiziertem ARM-Kern.> Gut, dass wenigstens Aerospace noch einigermassen Standard hat.
Du glaubst, das wäre bei Hardware besser? Ich nicht.
Ich kenne eine Menge Entwicker, die ihre Hardware nicht ordentlich in
Betrieb nehmen. Einschalten, LED blinkt, fertig. Messen? Nur wenns
wirklich nicht anders geht.
Der TÜV nimmt dir auch das ab. Die haben doch nicht einmal Zeit, die
Doku zu lesen. Die Verantwortung liegt schon immer bei dir, nicht beim
TÜV.
Was den ARM angeht: Die Sicherheit ist im Normalfall so gelöst, dass der
ARM-Kern damit nichts am Hut hat. Das wird zweikanalig aufgebaut, wenn
sich die Kanäle uneinig sind -> Failsafe.
Dass bei Safety viel gepfuscht wird, ist leider korrekt. Drum bin ich
aus dem Thema rausgewechselt, in einem Bereich, der völlig
Sicherheitsirrelevant ist. Lebt sich viel angenehmer, weniger
Augenauswischerei.
Fitzebutze schrieb:> Ja, und dementsprechend gibt es da eine Menge Schluderei. Mir sind auch> schon SIL3-Systeme unter die Augen gekommen, wo offenbar MISRA-C und> etwas MTBF-Analyse ausreicht, um den TüV-Stempel zu bekommen. Trotz> verbautem, nicht sicherheitszertifiziertem ARM-Kern.> Gut, dass wenigstens Aerospace noch einigermassen Standard hat.
Völlig üblich. SIL3 mit 2x STM32 Controllern gibts als quasi
Fertiglösung vom Safety Dienstleister. Der ARM Kern muss da überhaupt
nicht zertifiziert sein, der Controller selbst auch nicht.
jemand schrieb:> Der Teufel steckt in der Software schrieb:>> Deshalb werden (Überlebenskritische) Funktionen in Hardware realisiert.>> Vor langer, langer Zeit, in einem Land, weit weit entfernt.> Geschichten aus 1001 Nacht :-)
Immer dran denken, du hast hier mit Menschen zu tun, die in einem Land
leben, deren (von besagten Einwohnern demokratisch gewählte) Elite Dinge
wie das Internet als Neuland betrachten und seit nahezu fast schon
Jahrzehnten regelmäßig mit "IT"-Projekten auf die Nase fallen.
Was erwartest du also von dessen Bewohnern - IT-Expertenwissen ist es ja
definitiv nicht?
Toni Tester schrieb:> jemand schrieb:>> Der Teufel steckt in der Software schrieb:>>> Deshalb werden (Überlebenskritische) Funktionen in Hardware realisiert.>>>> Vor langer, langer Zeit, in einem Land, weit weit entfernt.>> Geschichten aus 1001 Nacht :-)>> Immer dran denken, du hast hier mit Menschen zu tun, die in einem Land
Naja die Regeln das bei sicherkritische Funktionen abzuwägen ist, ob
besser in Hardware als in Software zu realisieren ist, stammt nicht aus
.de.
Schon mal was DO-256 resp. DO-178 gehört?
Und ja gerade wenn man Neuland betritt, sollte man einen Wanderstock bei
der Hand haben mit dem man seinen Halt zurückerlangt, wenn der Boden des
Neulandes mal wieder wie eine Seifenblase zusammenbricht.
"Hardware und Software auf gemeinsamem Chip",
das wäre auch meine Devise. Vor allem, wenn man die "Verdrahtung"
mittels Software erledigen kann. Das System "PSoC" (Programmable System
on Chip) gibt es bereits seit Jahren, aber hier in DL hat es sich wohl
noch nicht herumgesprochen.
Ich habe mal zwei Beispielbilder angehängt. Das erste zeigt einen
Entwurf, das zweite eine erweiterte Aufgabenstellung (Es sollte noch ein
Parameter per Hand einstellbar sein.)
Kein Grund, alles nochmal von vorn zu beginnen: Dreh- Encoder
angeschlossen, Programm erweitert- fertig!
Links:
http://wkiefer.de/x28/Verdrahtung%20im%20Chip%20mittels%20Software.htm
Ich bin zwar ein Anwender der PSoC- Systeme, (habe darüber mehrere
Artikel geschrieben,) aber ohne kommerziellen Hintergrund; nur weil ich
von diesem System überzeugt bin.
DH1AKF W. schrieb:> Das System "PSoC" (Programmable System> on Chip) gibt es bereits seit Jahren, aber hier in DL hat es sich wohl> noch nicht herumgesprochen.
Och, das ist schon bekannt. Nur braucht man eben auch die entsprechenden
Anwendungen, die das nutzen können. FPGAs benutzt man ja auch nur dann,
wenn die Anwendungen sauschnelle Verarbeitung erfordern.
Den Großteil der Anwendungen kann man aber mit MCs von der Stange
erschlagen.
Der Teufel steckt in der Software schrieb:> Schon mal was DO-256 resp. DO-178 gehört?
Du schließt von deiner kleinen Flugzeugniesche auf die gesamte Welt?
Der Großteil der SIL-Systeme sind in der Industrie und im
Automotive-Sektor angesiedelt.
Peter D. schrieb:> FPGAs benutzt man ja auch nur dann,> wenn die Anwendungen sauschnelle Verarbeitung erfordern.FPGAs verwendet man auch dann, wenn man sehr präzise Timings mit
Sonderlocken benötigt.
> Den Großteil der Anwendungen kann man aber mit MCs von der Stange> erschlagen.
Das ist ebenfalls korrekt.
@Thomas F.
>(Umsteiger von Arduino auf PIC)
pic@sucks:~$ pic-gcc
bash: pic-gcc: command not found
Arduino kann auch pures avr-gcc, damit dauert ein pin-read <1uS
