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é
Man versucht möglichst viel in SW zu lösen - die kann man über Bootloader immer wieder updaten - das geht mit Hardware nicht.
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.
:
Bearbeitet durch User
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
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
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.