Forum: Mikrocontroller und Digitale Elektronik Funktionen in Software oder in Hardware lösen?


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Kibo (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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é

von Cragy Wägy (Gast)


Bewertung
2 lesenswert
nicht lesenswert
Man versucht möglichst viel in SW zu lösen - die kann man über 
Bootloader immer wieder updaten - das geht mit Hardware nicht.

von Arduino Fanboy D. (ufuf)


Bewertung
1 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
von Matthias S. (Firma: matzetronics) (mschoeldgen)


Bewertung
0 lesenswert
nicht lesenswert
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.

von jemand (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Anno (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Industriebastler (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von jemand (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Andreas S. (Firma: Schweigstill IT) (schweigstill) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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.

von Axel S. (a-za-z0-9)


Bewertung
1 lesenswert
nicht lesenswert
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.

von Peter D. (peda)


Bewertung
0 lesenswert
nicht lesenswert
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."

von Thomas F. (thomas_82)


Bewertung
0 lesenswert
nicht lesenswert
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

von Sven B. (scummos)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Kibo (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von H.Joachim S. (crazyhorse)


Bewertung
0 lesenswert
nicht lesenswert
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.

von jemand (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Der Teufel steckt in der Software (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
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

von H.Joachim S. (crazyhorse)


Bewertung
0 lesenswert
nicht lesenswert
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 :-)

von Andreas S. (Firma: Schweigstill IT) (schweigstill) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
von jemand (Gast)


Bewertung
1 lesenswert
nicht lesenswert
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.

von Fitzebutze (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Fitzebutze (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Cragy Wägy (Gast)


Bewertung
0 lesenswert
nicht lesenswert
>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.

von jemand (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Cyblord -. (cyblord)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Toni Tester (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
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?

von Der Teufel steckt in der Software (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von DH1AKF W. (wolfgang_kiefer) Benutzerseite


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
"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.

von Peter D. (peda)


Bewertung
0 lesenswert
nicht lesenswert
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.

von jemand (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Andreas S. (Firma: Schweigstill IT) (schweigstill) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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.

von FastDino (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
@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
1
#define BLINK_DELAY_MS 1000
2
3
void setup() {
4
 /* set pin 5 of PORTB for output*/
5
 DDRB |= _BV(DDB5);
6
}
7
8
void loop() {
9
    /* set pin 5 high to turn led on */
10
  PORTB |= _BV(PORTB5);
11
  _delay_ms(BLINK_DELAY_MS);
12
 
13
  /* set pin 5 low to turn led off */
14
  PORTB &= ~_BV(PORTB5);
15
  _delay_ms(BLINK_DELAY_MS);
16
17
}

pin mapping:
https://www.quora.com/What-is-the-pin-names-mapping-from-Arduino-to-the-actual-AVR-pin-mapping-I-need-to-use-the-board-for-pure-AVR-programming-The-Arduino-board-uses-an-ATmega328P-PU-chip

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]
  • [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.