Hallo zusammen, ich hätte hier mal ein paar Fragen an eingefleischte Harwareprogrammierer. Ich bin jetzt am Ende meiner Ausbildung und wurd sozusagen vor 1 - 1,5 Jahren in das Thema Hardwareprogrammierung mit C hinein geworfen. Ich programmiere einen ARM Prozessor (STM32F429BI) mit der "JumpStart C for Cortex-M" IDE von Imagecraft. Diese IDE hat mir vorallem am Anfang den Arsch mit der jsapi.h Library gerettet. Dort waren wichtige FUnktionalitäten wie USART oder I2C schon als ferige Funktionen verfügbar, die mir am Anfang den Arsch gerettet haben.(Habe mittlerweile I2C selber nochmal nachgebaut) Jetzt, wo ich jedoch schon weiter bin, frage ich mich, wie das andere Firmen/Programmierer machen. Was machen die besser/anderst und wie kann ich damit meinen Code verbessern. Ich will jetzt einmal alles anhand meines/eines ARM Prozessor abarbeiten. Programmieren andere Firmen I2C, USART oder SPI komplett selber, oder greifen die auch auf Bibliotheken zurück ? Wenn ja, auf welche genau? Wie programmiert man normalerweise ein Delay (z.B. für ein UART oder I2C als Clock Takt)? Ich habe da schon sehr viele Varianten gehört. ASM und NOP, oder auch eine for-Schleife. Aber wie macht man das richtig, das man z.B. mit dem der Clock Frequenz des Mikrocontrollers oder einem Quarz eine exakte Uhr/Delay erstellt? Aktuell greife ich auch mit den Funktionen der Bibliothek auf die Pins zu, ich habe es auch schon mit dem Ansteuern der Register probiert, musste aber feststellen, das ich insgesammt deutlich mehr Code Zeilen benötige. Wie ist das in großen Firmen gehandhabt ? Und als letzte Frage, könnt Ihr mir ein Buch zur Hardwareprogrammierung in C empfehlen, in der ich alles geballt lernen/lesen kann? Wo alles drin steht, der Funktion von Assert, über Interrupts, über wichtige Tipps zur Codesicherheit, bis hin zu schnellen Hardwarezugriffen mit einem FPGA.
Lern Assembler für deine CPU. Noch direkter geht es nicht.
Raphael K. schrieb: > Programmieren andere Firmen I2C, USART oder SPI komplett selber Meistens. Raphael K. schrieb: > oder greifen die auch auf Bibliotheken zurück ? Z.B. ein Bootloader wird bei Automotive z.B. bei Vector oder KPIT bestellt. Dann kann man von manchen Firmen Bibliotheken zum produktiveinsatz lizensieren, wie z.B. CAN-Stack oder Regelungstechnik-Gedöns. Kostet aber einen... Raphael K. schrieb: > Arsch ...voll Kohle, da meist pro produziertem Gerät was den Kunden erreicht, Lizenzgebühren anfallen können. Raphael K. schrieb: > Wie programmiert man normalerweise ein Delay (z.B. für ein UART oder I2C > als Clock Takt)? Ich habe da schon sehr viele Varianten gehört. ASM und > NOP, oder auch eine for-Schleife. Gar nicht. Man verwendet einen Mikrocontroller mit entsprechender eingebauter Peripherie. Zumindest verwendet man einen Timer und tut in der Main-Loop was Sinnvolles, statt mit NOPs Rechenlast zu erzeugen. Raphael K. schrieb: > Aber wie macht man das richtig, das > man z.B. mit dem der Clock Frequenz des Mikrocontrollers oder einem > Quarz eine exakte Uhr/Delay erstellt? Uhrenquarz oder Abgleich des Quarzoszillators oder https://www.mikrocontroller.net/articles/AVR_-_Die_genaue_Sekunde_/_RTC nach Kalibrierung oder oder oder... Raphael K. schrieb: > Aktuell greife ich auch mit den Funktionen der Bibliothek auf die Pins > zu, ich habe es auch schon mit dem Ansteuern der Register probiert, > musste aber feststellen, das ich insgesammt deutlich mehr Code Zeilen > benötige. Hast du eine vorkompilierte Bibliothek benutzt, siehst du die "deutlich mehr Code Zeilen" nicht. Raphael K. schrieb: > Wie ist das in großen Firmen gehandhabt ? Modulare Software a) Nicht schützendwerter Quellcode, da trivial: "deutlich mehr Code Zeilen" direkt sichtbar im Quellcode des Moduls, wenig Application- und Config-Code b) Schützenswerter Quellcode, da Intellectual Property (soll z.B. für Chinesische oder Amerikanische Kollegen nicht sichtbar sein): "deutlich mehr Code Zeilen" im Quellcode des Moduls => Vorkompilieren => vorkompilierte Library => wenig Application- und Config-Code mfg mf
Raphael K. schrieb: > Wie programmiert man normalerweise ein Delay (z.B. für ein UART oder I2C > als Clock Takt)? Ich habe da schon sehr viele Varianten gehört. Das machen die Prozessoren doch selber. Die haben eine (oder mehrere) Hardware I2C Einheit, und die arbeitet das im Hintergrund ab. Ich habe noch nie einen Delay dafür programmiert. Assert habe ich auch noch nie benutzt. Und FPGA ist ein Thema, mit dem man sich 1 Jahr beschäftigen muss, bevor man irgendetwas brauchbares hin bekommt. Das ist etwas vollkommen anderes als Programmieren.
Raphael K. schrieb: > eingefleischte Harwareprogrammierer. Da fehlt ein -d-. Durchgehend. Das, was du beschreibst ist lediglich "hardwarenahe Programmierung". Nämlich die Konfigurierung der µC-Komponenten auf eine Art, dass dann mit Low-Level-Routinen auf die Aussenwelt oder µC-Peripherie zugegriffen werden kann. > bis hin zu schnellen Hardwarezugriffen mit einem FPGA. Wie spielt hier ein FPGA mit rein? Die "Hardwareprogrammierung" eines FPGAs ist keine Programmierung im Sinne eines Programms für einen µC. Beim µC müssen "nur" fertige Komponenten richtig initialisiert und bedient werden, dann läuft der Laden. Bei der FPGA Entwicklung musst du aber erst eine Schaltung ausdenken, und die dann mit einer HardwareBESCHREIBUNGSsprache HDL wie Verilog oder VHDL beschreiben. Aus dieser Beschreibung macht dann der Synthesizer deine Hardware. Im RTL (Register Transfer Level) Schaltplan kannst du dann nachschauen, ob der Synthesizer deine Beschreibung richtig verstanden und die entsprechende Schaltung daraus gemacht hat. Diese Schaltung wird dann von den nachfolgenden Komponenten der Toolchain (Mapper, Place&Route, Bitstreamgenerator) in eine Konfiguration umgesetzt, die beim Powerup in das FPGA geladen wird. Und vor allem die Debugging-Strategien unterscheiden sich bei der hardwarenahen Programmierung und der Hardwarbeschreibung signifikant: während beim µC einfach mal ein Breakpoint gesetzt werden kann, der die Programmausführung stoppt, wird eine HDL-Beschreibung im Simulator gegen eine Testbench laufen gelassen und das Verhalten mit Meldungen oder im Waveform-Viewer analysiert.
Nur zum Timing:meist gibt es ein oder zwei "Herzschläge", in deren Takt delays etc. billig sind. Z.b. 1ms als Ticker. Eine Pause von 1,2, ...n ms kostet dann kaum Overhead. Schlimm ist dann alles deutlich darunter aber deutlich über Quarzfrequenz: z.b. 10us delay bei 100MHz Takt. Für Task-Wechsel zu kurz, eigener timer-Interrupt zu individuell, für nops zu lang. Wenn das 50 Mal pro ms vorkommen kann, geht dein Rechner in die Knie. Wenn dein Controller das dann nicht per Auftragspuffer und DMA in HW erledigt, dann musst Du das individuell frickeln.
Raphael K. schrieb: > Jetzt, wo ich jedoch schon weiter bin, frage ich mich, wie das andere > Firmen/Programmierer machen. Ich hatte damals mit einem kleinen Prozessor (Z80, nicht Mikrocontroller) angefangen. Zuerst habe ich auf einem fertige Heimcomputer dessen Programmierung gelernt, danach hatte ich ihm mit RAM, ROM-Emulator und Peripherie auf eigenen Platinen verwendet. Das ist Schnee von gestern, heute verwendet man Mikrocontroller, so wie du. Bei denen gehe ich so vor: Ich kaufe mir fertige Platinen, wo die Programmierschnittstelle und minimale Bestückung schon drauf ist. Dann nehme ich mir das Datenblatt (und Referenzhandbuch) vor und benutze einfache Schnittstellen (LED Blinken, Temperatur mit ADC messen, Serielle Kommunikation). Ich probiere anfangs nicht alle Details aus, denn das kommt kommt später mit konkreten Anwendungen. DMA ist zum Beispiel eine Sache, die ich auf Mikrocontrollern bisher noch gar nicht verwendet habe. Frameworks wie Arduino und Cube HAL umgehe ich Anfangs, denn sie behindern das Lernen so wie Stützräder am Fahrrad oder Schwimmflügel im Schwimmbad. Ich habe es versucht, bin aber mehrfach auf Bugs gestoßen, die ich nicht lösen konnte, weil mir die Grundlagen fehlten und die Struktur der Frameworks zu komplex war. Mittlerweile bin ich bei AVR fit und kann das Arduino Framework sinnvoll einsetzen und erweitern. Das Arduino Framework selbst bringt mir keinen Mehrwert, wohl aber einige 3rd party Libraries die darauf aufbauen. Deswegen nutze ich Arduino doch ab und zu. Ähnlich sieht es bei Cube HAL aus. Die Grundlagen der STM32 (Cortex M0, M3, M4) Controller habe ich inzwischen gelernt und ich habe mich mit der Eclipse basierten IDE vertraut gemacht. Mittlerweile kann ich mutmaßliche und echte Fehler in der HAL analysieren und beheben. Dazu habe ich hier im Forum großartige Hilfe gefunden - alleine wäre ich nicht so weit gekommen. Für die HAL habe ich allerdings noch keine echte Anwendung gefunden. Bisher habe ich alles, was ich machen wollte, ohne HAL realisiert. Ich fühle mich dabei wohler, weil ich so besser unter Kontrolle habe, was unter der Haube passiert. Außerdem habe ich das Gefühl, dass die HAL massiv RAM, Flash und Leistung verheizt. So ist das halt, wenn man eierlegende Wollmilchsäue baut. Du hast so viele blutige Anfänger Fragen. Vielleicht fängst du erstmal mit einem Tutorial an, das in die ersten Schritte der Programmierung ohne HAL einführt: http://stefanfrings.de/stm32/index.html > Wie programmiert man normalerweise ein Delay? Zwei Varianten sind üblich: a) Eine blockierende Warteschleife (wie hier: http://stefanfrings.de/stm32/stm32f1.html#delayloop), macht nur selten Sinn. b) Indem man einen Timer verwendet, der einen Zähler fortlaufend erhöht (Sekundentakt oder kleinere Intervalle). Arm Cortex Controller haben dazu alle den Systick Timer: http://stefanfrings.de/stm32/stm32f1.html#systick In Multi-Threaded Anwendungen sind Warteschleifen der Form a) weitgehend tabu. Siehe http://stefanfrings.de/multitasking_arduino/index.html (gilt auch für nicht-Arduino Projekte) > Aktuell greife ich auch mit den Funktionen der Bibliothek auf die Pins > zu, ich habe es auch schon mit dem Ansteuern der Register probiert, > musste aber feststellen, das ich insgesammt deutlich mehr Code Zeilen > benötige. Dann musst du irgend etwas grob falsch gemacht haben. Schau Dir das oben verlinkte delay Beispiel an, da blinkt eine LED, dazu dann noch diese Erklärung: http://stefanfrings.de/stm32/stm32f1.html#digital > Aber wie macht man ... eine exakte Uhr/Delay erstellt? Siehe http://stefanfrings.de/stm32/stm32f1.html#rtc > Und als letzte Frage, könnt Ihr mir ein Buch zur > Hardwareprogrammierung in C empfehlen, in der ich alles geballt > lernen/lesen kann? Die Programmiersprache lernt man meiner Meinung nach besser auf einem PC. Erst danach würde ich mich an Mikrocontroller heran wagen. Für AVR Mikrocontroller habe ich ein Buch geschrieben, was die Programmierung in C recht detailliert erklärt: http://stefanfrings.de/mikrocontroller_buch/index.html Ich kann das nur empfehlen - auch wenn es wegen der 8bit Technik schon etwas angestaubt ist. Diese kleinen AVR Controller haben ein wesentlich übersichtlicheres Datenblatt und weniger Funktionen, weswegen sie einfacher zu programmieren sind. Die Grundlagen, die du dabei lernst, gelten zu 95% auch für 32bit ARM Controller. Alles, was anders ist, habe ich meine Homepage geschrieben. Dort findest du übrigens auch meine weiterführenden Buch-Empfehlungen. Assert und FPGA habe ich noch nie benutzt, dazu musst du mal die Antworten der anderen abwarten. Mein Gefühl sagt mir, dass FPGA nichts für Anfänger sind. Da diese Fragen immer wieder gestellt werden und ich sie ebenfalls selbst hatte, habe ich Antworten, die ich gut fand, auf meiner Homepage gesammelt. Anfangs war die Seite noch lückenhaft und enthielt falsche bzw schlechte Tipps. Im Laufe von vielen Jahren habe ich sie aber immer weiter verfeinert. Das ist der Vorteil des Internet im Vergleich zu gedruckten Büchern. Ich will nicht behaupten, dass meine Seite der Weisheit letzter Schluss ist, aber sie ist ganz sicher für dich hilfreich. Nimm Dir die Zeit, dich dort durch zu klicken. Nachtrag: Die Links oben beziehen sich alle auf den STM32F1. Ich habe auch einiges zu F3 und L0 Serien geschrieben. Zu deinem F4 habe ich leider gar nichts konkretes, ich weiß aber, dass er sehr ähnlich programmiert wird. Wenn du erstmal mit einem kleineren Modell anfängst, zu dem genug Anleitungen vorliegen, wird Dir der Wechsel auf den F4 sicher leicht fallen.
habe mit AVR angefangen Das war Anfangs ohne libs, ohne HAL oder irgendwas. Eben direkter Registerzugriff. Da lernt man aber wie Peripherie funktioniert. Dann Cortex M0. Das gleiche versucht , aber immer grob aus der LL Lib von ST abgeguckt. Ist deutlich mehr Register und daher auch schwerer im Kopf zu behalten. Aktuell verwende ich Cortex M7. Hier mit RTOS und HAL lib. Warum? Das Ding is so Riesig und Komplex .. hier brauch man schon Hilfe. Gerade wenn man seine Aufmerksamkeit eher der Applikation schenkt. Man möchte dann nicht mehr im Urschleim der Peripherie wühlen (es sei denn die HAL funktioniert nicht wie gewünscht). Gerade M4 / M7 finde ich , sind mit RTOS besser beherschbar. Die HAL hat einen gewissen overhead der aber nicht mehr so brutal auffällt. Und bis auf den USB HOST konnte ich mich nicht wirklich über Fehler in der HAL beschweren. Ethernet, SAI(I²S ) , I²C , U(S)ART , RTC , CRC , HASH , RND ... Das scheint erstmal Grundsätzlich zu laufen. Ich binde die HAL in 10minuten ein und verbringe tage damit die Applikation zu schreiben. CUBE nutze ich zB sehr gern um einen Passenden µC auszuwählen.. Mit welchem µC kann ich diese und jene Peripherie parallel nutzen. Welches Footprint liefert mi diese Eigenschaften. Danach frage ich das Bauteil erst an. Insgesammt lernt man das aber nur durch Anwenden... Nur lesen bringt nichts.
Raphael K. schrieb: > Jetzt, wo ich jedoch schon weiter bin, frage ich mich, > wie das andere Firmen/Programmierer machen. Wir benutzen (größtenteils) ein BSP (Board Support Package) des SoC-Herstellers. Die von uns eingesetzten SoCs werden von der Linux-Community als "die komplexesten auf diesem Planeten" bezeichnet und sind für Dritte nicht mehr sinnvoll auf Systemebene programmierbar. Ab einer gewissen Firmengröße lässt man die Chiphersteller selbst entwickeln (bzw. entwickelt in Zusammenarbeit mit diesem), entsprechende Kommunikation läuft dann über einen TAM (Technical Account Manager).
Raphael K. schrieb: > Wie programmiert man normalerweise ein Delay (z.B. für ein UART oder I2C > als Clock Takt)? Gar nicht, die haben entsprechende Vorteiler für die Baudrate, die man setzen muß. Bei 32Bit-Boliden sind die Konfigurationsmöglichkeiten allerdings deutlich komplexer als bei bei einem 8Bitter. Und auch die Einstellungen für die Verwendung von Interrupts oder DMA. Am besten schaut man sich dafür Beispielcode an. Bei den 8Bittern (AVR, 8051) reicht in der Regel die Registerbeschreibung im Datenblatt völlig aus, um in wenigen Minuten die UART zum Laufen zu bringen.
Raphael K. schrieb: > ich hätte hier mal ein paar Fragen an eingefleischte > Harwareprogrammierer. > Ich bin jetzt am Ende meiner Ausbildung und wurd sozusagen vor 1 - 1,5 > Jahren in das Thema Hardwareprogrammierung mit C hinein geworfen. > > Ich programmiere einen ARM Prozessor (STM32F429BI) mit der "JumpStart C > for Cortex-M" IDE von Imagecraft. Diese IDE hat mir vorallem am Anfang > den Arsch mit der jsapi.h Library gerettet. Huch: "Hardware-Programmierung" versus "Software-Programmierung" etwa? Dein Denken ist noch konfus, das solltest du deutlich verbessern. Also: Hardware programmiert man nicht, sondern man benutzt sie. Der Chip, für den du Programme schreibst, ist so eine Hardware. Aber auch ein Stecker oder ein SN74LS00 oder ein LM358 ist eine ebensolche Hardware. Und das "Programmieren" besteht aus dem Konstruieren einer Schaltung. Was du vermutlich meinst, ist das Schreiben von Lowlevel-Treibern für die diversen Peripherie-Cores auf deinem Chip. Zweck der Übung: daß man diese Cores tatsächlich benutzen kann und daß die Ebene der Algorithmen in deiner Firmware sich nicht um die Details der physischen Ebene zu kümmern braucht. Also sowas wie MotorEin(void) anstelle GPIO7_BSR=(1<<tralala) Raphael K. schrieb: > Jetzt, wo ich jedoch schon weiter bin, frage ich mich, wie das andere > Firmen/Programmierer machen. Das ist höchst unterschiedlich und wenn du 3 verschiedene Leute hier fragst, wirst du mindestens 4 völlig verschiedene Ansichten zu lesen kriegen. Es ist im übrigen auch herzlich egal, ob und was für eine IDE du gerade benutzt. Hier gilt auch: 3x fragen, 4x verschiedene Antworten kriegen. Und wie man sowas angeht - das hängt vor allem davon ab, ob jemand sich auf das Zeugs einlassen will, was der Hersteller so anbietet oder nicht. Wenn ja, dann nagelt man sich damit auf diesen Hersteller fest, wenn nein, dann schreibt man sich seine LL-Treiber selber und achtet daraf, daß deren Interface nach oben hin hersteller- und chip-UN-abhängig ist. Macht anfangs mehr Mühe, erleichtert aber das Wechseln zwischen verschiedenen Angeboten. Sowas muß ein jeder mit sich selber ausmachen. Meine inzwischen langjährige Erfahrung besagt, daß man am besten fährt, wenn man sauber trennt zwischen den Algorithmen und den Lowlevel-Treibern - und wenn man vor dem Quellcode-Schreiben die Interfaces der Treiber sauber definiert und allen Beteiligten als ausgedrucktes PDF auf den Schreibtisch legt. W.S.
W.S. schrieb: > Was du vermutlich meinst, ist das Schreiben von Lowlevel-Treibern für > die diversen Peripherie-Cores auf deinem Chip. Könntest du bitte aufhören, Peripherieeinheiten als "Cores" zu bezeichnen? Oder legst du es darauf an, deine Leser zu verwirren? Mikrocontroller mit mehreren Cores gewinnen derzeit an Verbreitung.
minifloat schrieb: > Raphael K. schrieb: >> Programmieren andere Firmen I2C, USART oder SPI komplett selber > > Meistens. Nein. Selten. Es wird auf die vom Hersteller gelieferten BSP zurückgegriffen. Dann werden hardwarespezifische Änderungen vorgenommen. Die Funktion des eigentlichen Schnittstellenprotokolls wird meist nicht angefasst.
Axel S. schrieb: > Könntest du bitte aufhören, Peripherieeinheiten als "Cores" zu > bezeichnen? Oder legst du es darauf an, deine Leser zu verwirren? So nennt man die Dinger aus Hardwaresicht aber... guck mal ins FPGA-Forum. Jeder einzelne Peripherieblock ist da ein "IP-Core". Im Übrigen steht da "Peripherie-Core", das ist eindeutig kein Prozessor. > Mikrocontroller mit mehreren Cores gewinnen derzeit an Verbreitung. Du meinst "CPU-Cores". Das ist eine ganz bestimmte Bedeutung von "Core".
Ich kenne CPU-Kern und Peripherie-Einheit.
Stefanus F. schrieb: > Ich kenne CPU-Kern und Peripherie-Einheit. Ich wiederum kenne des Pudels Kern und Einheit von Wirtschafts- und Sozialpolitik.
S. R. schrieb: > Axel S. schrieb: >> Könntest du bitte aufhören, Peripherieeinheiten als "Cores" zu >> bezeichnen? Oder legst du es darauf an, deine Leser zu verwirren? > > So nennt man die Dinger aus Hardwaresicht aber... guck mal ins > FPGA-Forum. Jeder einzelne Peripherieblock ist da ein "IP-Core". Auch dir sollte aufgefallen sein, daß es hier um µC geht und nicht um FPGA. Außerdem ist "IP-Core" etwas anderes als "Core". Immerhin expandiert der unschuldig aussehende Vorsatz "IP" zu "intellectual property" und wird damit zu einem wesentlichen Bestandteil des Wortes. Tatsächlich ist das "core" da bloß noch Dekoration und es ist vollkomen offen, ob dieser IP-Core nachher tatsächlich der Kern des Designs ist, oder nicht. Ein UART oder I²C Block bildet jedenfalls definitiv nicht den Kern eines µC. > Im Übrigen steht da "Peripherie-Core", das ist eindeutig kein Prozessor. In vorherigen Posts hat W.S. ganz ohne diese Unterscheidung von "Cores" gesprochen: Beitrag "Re: Erfahrung mit NXP Kinetis" Beitrag "Re: Erfahrung mit NXP Kinetis" >> Mikrocontroller mit mehreren Cores gewinnen derzeit an Verbreitung. > > Du meinst "CPU-Cores". Das ist eine ganz bestimmte Bedeutung von "Core". Das ist im Kontext von Mikrocontrollern die einzig verbreitete Bedeutung. Ich finde W.S. Sprachgebrauch einfach nur verwirrend und bin damit sicher nicht der einzige. Der TE gehört mit an Sicherheit grenzender Wahrscheinlichkeit ebenfalls zum Kreis derer, die keine Ahnung haben, was W.S. mit "Cores" meinen könnte.
Raphael K. schrieb: > Programmieren andere Firmen I2C, USART oder SPI komplett selber, oder > greifen die auch auf Bibliotheken zurück ? Wenn ja, auf welche genau? Ja, alleine schon weil viele Bibliotheken einfach Schrott sind. Zudem gibt es kaum schlimmeres als sich durch Projekte zu debuggen, die irgendein Amateur solange aus Beispielcode und Fremdbibliotheken zusammenkopiert hat bis "es läuft". Weil es halt wie immer schnell gehen musste. Wobei ich sagen muss, dass die CMSIS-Bibliotheken eigentlich ganz passabel sind: Die scheinen tatsächlich von Profis geschrieben worden zu sein und werden auch gepflegt (!). Die hat eher nicht irgendein Trainee zusammengeschustert, der danach entweder befördert oder entlassen wurde. Aber davon abgesehen, dass ich es grundsätzlich für besser halte die low-level-Treiber selbst zu schreiben, bleibt einem im sicherheitskritischen Bereich auch selten etwas anderes übrig (strenge Voraussetzungen für OTS-Software, Unit-Tests, statische Codeanalyse, ...). Man muss ja nicht immer bei Adam und Eva anfangen, sondern kann für bestimmte Controller firmeninterne Bibliotheken aufbauen und pflegen. > Und als letzte Frage, könnt Ihr mir ein Buch zur Hardwareprogrammierung > in C empfehlen, in der ich alles geballt lernen/lesen kann? > > Wo alles drin steht, der Funktion von Assert, über Interrupts, über > wichtige Tipps zur Codesicherheit, bis hin zu schnellen > Hardwarezugriffen mit einem FPGA. Ich kenne leider kein einziges wirklich gutes Buch auf diesem Gebiet. Das meiste lernt man durch Erfahrung, von Blogs, Vorträgen, Compiler-Manuals (!), Coding Guidelines wie MISRA usw. Bestimmt kann man aus fast jedem Buch etwas nützliches ziehen. Aber gerade im Bereich C gibt es echt viel wirklich schlechte Literatur. Da würde ich fast eher allgemein gehaltene Werke, wie "Clean Code", empfehlen.
P. S. schrieb: > Raphael K. schrieb: >> Wo alles drin steht, der Funktion von Assert, über Interrupts, über >> wichtige Tipps zur Codesicherheit, bis hin zu schnellen >> Hardwarezugriffen mit einem FPGA. > > Ich kenne leider kein einziges wirklich gutes Buch auf diesem Gebiet. In der Vergangenheit hat es mal Bücher gegeen die dem Anspruch von "Alles drin" nahe kommen wie: -PC intern https://www.mitinet.de/pc-intern-systemprogrammierung/ oder -PC-Hardwarebuch, ISBN 3-8273-1461-5 Aber da sich leider die Meinung breit gemacht hat, man brauche keine gut sortierte Handbibliothek mehr, weil man alles im Internet findet oder durch penetrantes Stellen dummer Frage aus einen Internet-Forum "prügeln" kann, findet sich keiner meh,r der seine Lebenszeit opfert um ein gutes Buch zu schreiben.
Ja. Auch du opferst deine Lebenszeit (wieviel hast du noch davon?) lieber, um hier rumzustänkern.
Stefanus F. schrieb: >> Wie programmiert man normalerweise ein Delay? > > Zwei Varianten sind üblich: > a) Eine blockierende Warteschleife (wie hier: > http://stefanfrings.de/stm32/stm32f1.html#delayloop), macht nur selten > Sinn. > b) Indem man einen Timer verwendet, der einen Zähler fortlaufend erhöht > (Sekundentakt oder kleinere Intervalle). Arm Cortex Controller haben > dazu alle den Systick Timer: > http://stefanfrings.de/stm32/stm32f1.html#systick Beide Varianten verbraten sinnlos die Zeit und können nur durch Interrupts durchbrochen werden.
Tatsächlich? schrieb: > Beide Varianten verbraten sinnlos die Zeit und können nur durch > Interrupts durchbrochen werden. Meine beiden oben genannten Beispiele sind single-Threaded, da ist der Vorteil von Timern versus Delay-Schleife kaum erkennbar. Wie kann man denn sinnvoll Zeit verbraten? Vermutlich gar nicht. Aber, wenn man Timer benutzt, kann man die CPU während des Wartens z.B. schlafen legen oder herunter takten. So spart man dabei wenigstens Strom. Wenn man Zustandsautomaten für Multi-Threading verwendet, ergibt es aber ganz offensichtlich Sinn. Deswegen habe ich ein solches Beispiel direkt hinterher geschoben.
Raphael K. schrieb: > Wie funktioniert Harwareprogrammierung normalerweise ? Ich würde sagen, so: http://computermuseum.informatik.uni-stuttgart.de/pics/dex100/dex100_2s.jpg
Raphael K. schrieb: > Programmieren andere Firmen I2C, USART oder SPI komplett selber, oder > greifen die auch auf Bibliotheken zurück ? I2C und SPI steuern fast immer Peripherie an und diese erfordert jeweils eigene Sequenzen für den Zugriff. Daher fällt es schwer, dafür ein universelles Interface zu schreiben. Z.B. der MAX1300 (16 Bit ADC) benötigt 3 1-Byte Pakete (Mode setzen, Kanal auswählen, Messung starten. Dann muß man die Wandlungszeit abwarten (Pin einlesen oder Delay) und dann 2 Byte auslesen. Ein SPI-DAC oder SPI-Flash erfordern wiederum völlig andere Sequenzen. Bzw. ein I2C-RTC, ein I2C-IO-Expander, ein I2C-EEPROM usw. sind auch nicht unter einen Hut zu bringen.
Peter D. schrieb: > Daher fällt es schwer, dafür ein > universelles Interface zu schreiben. Nun, für I2C geht das aber: 1. Funktion: Bus bekommen, Slave adressieren. 2. Funktion: Daten zum Slave schreiben 3. Funktion: Daten vom Slave lesen 4. Funktion: Ende, also StopCond. Das ist mMn. ausreichend abstrahiert, sodaß man alle Handler für Uhren, ADC's, LCD's, EEPROM's und so weiter, die darauf aufsetzen, plattformunabhängig schreiben kann. Im Übrigen ist es so, wie du schreibst: Bei sowas muß man eben auf diese Funktionen warten. Ob die zu erwartenden Wartezeiten jedoch ein aufwendiges System zum Ausnutzen der Wartezeit (RTOS etc.) rechtfertigen, sei mal dahingestellt. Axel S. schrieb: > Könntest du bitte aufhören, Peripherieeinheiten als "Cores" zu > bezeichnen? Nein, das tue ich nicht, denn ich bin gerade in so einem Thread für Klarheit und Exaktheit. Was dabei herauskommt, wenn Leute die betreffenden Fachbegriffe nicht kennen und offenbar auch nicht gewillt sind, selbiger zu erlernen - das sieht man an diesem Thread und insbesondere an seiner Überschrift. W.S.
Beitrag #6006983 wurde vom Autor gelöscht.
Thread beobachten
Seitenaufteilung abschalten
Bitte 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.