Autor: Christian Siemers, Technische Universit\u00e4t Clausthal, Institut f\u00fcr Prozess- und Produktionstechnik<\/p>\n
Ein Thema wie\u00a0Hardwarenahe Programmierung<\/em>\u00a0(in einer Hochsprache) sollte es eigentlich gar nicht geben, denn Hochsprache impliziert Hardwareunabh\u00e4ngigkeit<\/em>\u00a0\u2013 und nicht ein spezifisches Eingehen auf die Eigenheiten selbiger. Dennoch ist dieses Thema aus der Praxis aus folgenden Gr\u00fcnden nicht wegzudenken:<\/p>\n Bei hardwarenaher Programmierung handelt es sich oftmals auch um eine Systementwicklung mit Elementen aus dem Bereich Hardware-\/Software-Co-Design.<\/p>\n Fouriertransformation (FT)<\/strong>: Der \u00dcbergang von periodischen auf aperiodische Signalformen ergibt dann den \u00dcbergang vom diskreten auf das kontinuierliche Spektrum. Umgekehrt kann man die urspr\u00fcngliche Signalform g(x) durch phasen- und amplitudenkorrektes \u00dcberlagern der im Spektrum vorhandenen Frequenzen wieder erzeugen (Fourier-Synthese). Hier die Formeln zur Berechnung in der reellen Schreibweise, wobei angenommen wird, dass g(x) eine reellwertige Funktion ist (siehe Abbildung 1a,\u00a0PDF<\/a>).<\/p>\n Diskrete Fouriertransformation (DFT)<\/strong>: Damit werden die Berechnungsintegrale der allgemeinen Fouriertransformation zu Berechnungs\u00adsummen, die vergleichsweise einfach in Form von Algorithmen implementiert werden k\u00f6nnen [1]. T bezeichnet in den Gleichungen (Bild 1b, siehe\u00a0PDF<\/a>) die Periode des Signals, Dt den zeitlichen Abstand zweier aufeinanderfolgender Messpunkte.<\/p>\n Die DFT wird genutzt, wenn die Zahl der Messpunkte pro Periode nicht vorherbestimmt oder ungleich einer Zweierpotenz ist. Bei Zweierpotenzen wie 512 oder 1024 jedoch bietet sich die Implementierung als Fast Fourier Transformation (FFT) an. Die Komplexit\u00e4t der DFT liegt bei O(N\u00b2), die der FFT bei O(N*log(N)).<\/p>\n Die Formeln in Bild 1 b) (s.\u00a0PDF<\/a>) k\u00f6nnen vergleichsweise leicht in einem Algorithmus aufgenommen werden, z.B. in C:<\/p>\n void vComputeDFT( unsigned int uiNumOfPoints, int *iValue )<\/p>\n {<\/p>\n \u00a0\u00a0 unsigned int k, m;<\/p>\n \u00a0\u00a0 double dCoeffAtemp, dCoeffBtemp;<\/p>\n \u00a0\u00a0 for( k = 0; k < NUM_OF_COEFFICIENTS; k++ )<\/p>\n \u00a0\u00a0 {<\/p>\n \u00a0\u00a0\u00a0\u00a0\u00a0 dCoeffAtemp = 0.L;<\/p>\n \u00a0\u00a0\u00a0\u00a0\u00a0 dCoeffBtemp = 0.L;<\/p>\n \u00a0\u00a0\u00a0\u00a0\u00a0 for( m = 0; m < uiNumOfPoints; m++ )<\/p>\n \u00a0\u00a0\u00a0\u00a0\u00a0 {<\/p>\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 dCoeffAtemp += (double)*(iValue+m) * \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 dCoeffBtemp += (double)*(iValue+m) * \u00a0\u00a0 \u00a0\u00a0\u00a0}<\/p>\n \u00a0\u00a0\u00a0\u00a0\u00a0 dCoeffA[k] = dCoeffAtemp \/ (double)uiNumOfPoints;<\/p>\n \u00a0\u00a0\u00a0\u00a0\u00a0 dCoeffB[k] = dCoeffBtemp \/ (double)uiNumOfPoints;<\/p>\n \u00a0\u00a0 }<\/p>\n }<\/p>\n Dieses Programm beinhaltet mit NUM_OF_COEFFICIENTS eine Konstante, die anzeigt, wie viele Koeffizienten a und b aus Bild 1 (siehe\u00a0PDF<\/a>) berechnet werden sollen; diese Konstante kann nat\u00fcrlich auch leicht als Variable formuliert werden. Was man aber sehr leicht beurteilen kann: Hier sind eine Menge an Additionen und Multiplikationen enthalten, von der Berechnung der Sinus- und Cosinuswerte ganz abgesehen. Dieser Algorithmus auf einem Mikroprozessor oder DSP implementiert, der keine Floating-Point-Unit aufweist, kann schon \u00fcberraschend gro\u00dfe Laufzeiten aufweisen, da das Floating-Point-Format recht umst\u00e4ndlich emuliert werden muss.<\/p>\n Es liegt also nahe, die Umsetzung in ein Festkommaformat durchzuf\u00fchren und dann mit erh\u00f6hter Performance zu rechnen. Eine weitere Verbesserung ist z.B. geringerer Platzbedarf, was aber ggf. zweitrangig ist. Die grunds\u00e4tzliche Formel zur Umsetzung ist (siehe Gleichung 1,\u00a0PDF<\/a>)<\/p>\n wobei mit \u0394 der so genannte Offset (Versatz des Nullpunkts) und mit Q zun\u00e4chst ein linearer Skalierungsfaktor bezeichnet wird. Diese Abbildung betrifft aber zun\u00e4chst nur das Mapping einer physikalischen (Prozess-) Gr\u00f6\u00dfe auf eine analoge (!) Gr\u00f6\u00dfe. Interpretiert man die Formel (1) jedoch so, dass Q eine Quantisierungsgr\u00f6\u00dfe darstellt, und dass die Abbildung in Quanten erfolgt, dann erhalten wir die gew\u00fcnschte Abbildung von physikalischen Gr\u00f6\u00dfen in Darstellungen in Computer-verwendbaren Datenwerten.<\/p>\n Gleichung (2, siehe\u00a0PDF<\/a>) wird gerne noch dahingehend vereinfacht, dass man den Offset \u0394 zu Null setzt. Hierdurch werden arithmetische Operationen wie Addition, Subtraktion usw. erheblich vereinfacht.<\/p>\n So sch\u00f6n einfach die Formel (2) auch erscheint, sie birgt noch einen Pferdefu\u00df in sich, denn sie gilt nur f\u00fcr einen eingeschr\u00e4nkten Wertebereich von xphys<\/sub>. Diese Gr\u00f6\u00dfe repr\u00e4sentiert ja die physikalische Au\u00dfenwelt bzw. eine Messgr\u00f6\u00dfe, und da der Zahlenbereich aller Darstellungen im Rechner beschr\u00e4nkt ist, ist auch die Messgr\u00f6\u00dfe in einem zul\u00e4ssigen Intervall zu halten.<\/p>\n Mehr noch, wenn man xphys<\/sub>\u00a0durch xfloat<\/sub>\u00a0ersetzt \u2013 genau dies soll hier ja geschehen, es soll die Flie\u00dfkomma- durch eine Fixkomma-Darstellung ersetzt werden \u2013, dann gelten f\u00fcr beide Zahlenformate Intervallgrenzen f\u00fcr die Zul\u00e4ssigkeit, aber eben unterschiedliche. Dies muss bei der Umsetzung unbedingt ber\u00fccksichtigt werden.<\/p>\n Das verwendbare Festkommaformat muss man sich als Abwandlung des bekannten Integer-Formats denken, bei dem der Abstand zwischen zwei benachbarten darstellbaren Werten eben nicht 1, sondern z.B. 0,5, 0,25 oder 0,1 ist. \u00dcblicherweise nimmt man in der digitalen Welt auch hierf\u00fcr Zweier-Potenzen, und das resultierende Format wird als Qn.m bezeichnet.<\/p>\n Der Index\u00a0n<\/em>\u00a0steht hierbei f\u00fcr die Anzahl der Bits vor dem Komma,\u00a0m<\/em>\u00a0f\u00fcr die Anzahl danach. Ferner wird wie im Integer-Fall zwischen vorzeichenlosen und vorzeichenbehafteten Darstellungen unterschieden, wobei dies nicht in der Formatbezeichnung sichtbar wird.<\/p>\n Rechnen mit Qn.m unterscheidet sich nicht sonderlich vom Rechnen mit Integerzahlen, solange das Komma bei den Operanden immer an der gleichen Stelle steht. Sind die Darstellungen der Operanden allerdings unterschiedlich, d.h., stimmen n und m f\u00fcr die jeweiligen Operanden untereinander nicht mehr \u00fcberein, dann ist Gehirnarbeit und Bitschieberei angesagt.<\/p>\n Und es wartet noch eine Aufgabe im Sourcecode (Listing 2), die f\u00fcr eine \u00dcbersetzung gel\u00f6st werden muss: Die transzendenten Funktionen Sinus und Cosinus. Diese Funktionen sind \u00fcblicherweise f\u00fcr Flie\u00dfkommawerte in Bibliotheken vorhanden, aber genau dieser Datentyp soll hier nicht verwendet werden.<\/p>\n #define PI\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 3.14159265358979L<\/p>\n #define LIMIT\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 2048<\/p>\n #define FRACTION_BITS\u00a0\u00a0 30<\/p>\n \/* This results in a Q1.30 format with sign\u00a0 *\/<\/p>\n #define LIMIT_TEST\u00a0\u00a0\u00a0\u00a0\u00a0 960<\/p>\n void main()<\/p>\n {<\/p>\n \u00a0\u00a0 int k;<\/p>\n \u00a0\u00a0 long int lResult;<\/p>\n \u00a0\u00a0 double dfResult;<\/p>\n \u00a0\u00a0 for( k = 0; k < LIMIT; k++ )<\/p>\n \u00a0\u00a0 {<\/p>\n \u00a0\u00a0\u00a0\u00a0\u00a0 dfResult = sin( 2.L * PI * (double)k \/ (double)LIMIT );<\/p>\n \u00a0\u00a0\u00a0\u00a0\u00a0 lResult = (long int) (dfResult * (1 << FRACTION_BITS));<\/p>\n \u00a0\u00a0\u00a0\u00a0\u00a0 printf( \u201e%lf\u00a0 %08x \u201c, dfResult, lResult );<\/p>\n \u00a0\u00a0 }<\/p>\n }<\/p>\n Die L\u00f6sung besteht z.B. darin, die Sinus- und Cosinuswerte\u00a0vor<\/em>\u00a0der Laufzeit zu berechnen und in einem Datenbereich im Qn.m-Format (hier z.B. vorzeichenbehaftetes Q1.30) zu speichern (siehe Listing 2). Um dann zur Laufzeit pr\u00e4zise Werte zu allen Eingangsparameter verf\u00fcgbar zu haben, kann man sich aus der Grundtabelle eine zweite Tabelle (oder direkt die Werte) durch lineare Interpolation erstellen. Dieses Verfahren ist sehr schnell, auch f\u00fcr einfache Prozessoren.<\/p>\n Mit den gerade diskutierten Ans\u00e4tzen zur hardwarenahen Softwareentwicklung wird nun die Transformation des Algorithmus aus Listing 1 in eine Version, die lediglich Integer-Wert nutzt, durchgef\u00fchrt. Folgende Details sind dabei wichtig:<\/p>\n <\/p>\n Die zentrale Routine zur Berechnung der DFT lautet nun:<\/p>\n void vComputeDFT( uint16 ui16NumOfPoints, int16 *i16Value )<\/p>\n {<\/p>\n \u00a0\u00a0 uint16 k, m, ui16Index;<\/p>\n \u00a0\u00a0 int32 i32CoeffATemp, i32CoeffBTemp;<\/p>\n \u00a0\u00a0 for( k = 0; k < NUM_OF_COEFFICIENTS; k++ )<\/p>\n \u00a0\u00a0 {<\/p>\n \u00a0\u00a0\u00a0\u00a0\u00a0 i32CoeffATemp = 0;<\/p>\n \u00a0\u00a0\u00a0\u00a0\u00a0 i32CoeffBTemp = 0;<\/p>\n \u00a0\u00a0\u00a0\u00a0\u00a0 for( m = 0, ui16Index = 0; m < ui16NumOfPoints; )<\/p>\n \u00a0\u00a0\u00a0\u00a0\u00a0 {<\/p>\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 i32CoeffATemp += *(i16Value+m) * \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 i32CoeffBTemp += *(i16Value+m) * i32SineTable[ui16Index];<\/p>\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 m++;<\/p>\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 ui16Index = (ui16Index + k) % ui16NumOfPoints;<\/p>\n \u00a0\u00a0\u00a0\u00a0\u00a0 }<\/p>\n \u00a0\u00a0\u00a0\u00a0\u00a0 i32CoeffA[k] = i32CoeffATemp;<\/p>\n \u00a0\u00a0\u00a0\u00a0\u00a0 i32CoeffB[k] = i32CoeffBTemp;<\/p>\n \u00a0\u00a0 }<\/p>\n }<\/p>\n Als Testfunktion wird ein Rechteckt mit 5 Perioden auf 1000 Punkte gew\u00e4hlt, da hier das Ergebnis bekannt ist: Wenn die Grundwelle eine H\u00f6he von 1 aufweist, dann sind alle geraden Oberwellen 0, und alle ungeraden Oberwellen (Index\u00a0k<\/em>) weisen eine Amplitude von 1\/k<\/em>\u00a0auf. Bild 2 zeigt das Ergebnis f\u00fcr die in Floating Point realisierte Variante, Bild 3 (siehe\u00a0PDF<\/a>) f\u00fcr die im Festkommaformat.<\/p>\n Die Bilder weisen un\u00fcbersehbare Unterschiede auf, obwohl sie den gleichen Algorithmus imple\u00admentieren. Zudem sieht man zumindest qualitativ, dass Bild 2 (siehe\u00a0PDF<\/a>) ein korrektes Ergebnis anzeigt, da das Ergebnis mit der Theorie \u00fcbereinstimmt. Hierzu gleich eine Anmerkung: Will man die wirkliche Korrektheit der Ergebnisse pr\u00fcfen, muss man zu einer logarithmische Darstellung wechseln und die Differenz der berechneten und der theoretischen Werte logarithmisch betrachten. Je nach Anzahl der signifikanten Bits ergibt dies einen Wert, der unter dem erreichbaren Signal\/Rausch-Abstand liegen muss.<\/p>\n Zur\u00fcck zur Auswertung: Der Grund f\u00fcr das Scheitern der DFT-Berechnung im Festkommaformat sind Daten\u00fcberl\u00e4ufe. Die Berechnung verwendet Sinus- und Cosinuswerte von 16 bit Breite. Diese werden in dem Beispiel mit 13 bit Werten (dem gew\u00e4hlten Format f\u00fcr das Rechteck, 12 bit Wert + Vorzeichen) multipliziert, dies ergibt 29 signifikante Bits, und dann 1000fach aufsummiert, was zu 10 weiteren Bits f\u00fchrt (10 = log2<\/sub>(1024)). Insgesamt k\u00f6nnen die Ergebnisse also 39 Bit Breite aufweisen, da wundert es nicht, wenn es f\u00fcr 32 bit Variablen \u00fcberlaufen kann.<\/p>\n Man kann nun an 2 verschiedenen Schrauben justieren, um das Problem des Daten\u00fcberlaufs zu l\u00f6sen: geringere Datenbreiten, also ein Verlust an Genauigkeit, oder gr\u00f6\u00dfere Datentypen, z.B. also 64 bit. Der erste Weg bietet sich an, wenn die Genauigkeit, die erzielbar w\u00e4re, gar nicht gefordert ist; der zweite, wenn der Genauigkeitsverlust nicht akzeptabel ist. Die Aufteilung auf zwei Variablen, also die Emulation h\u00f6herer Datenbreiten durch softwarem\u00e4\u00dfige Kopplung bleibt ebenfalls als durchaus performante L\u00f6sung. Bild 4 (siehe\u00a0PDF<\/a>) zeigt das Ergebnis der Fouriertransformation f\u00fcr einen korrekten, die entstehenden Datenbreiten ber\u00fccksichtigenden Algorithmus im Festkommaformat.<\/p>\n Die Performance ist dabei schon beeindruckend. W\u00e4hrend ein DSP mit einer intrinsischen Datenbreite von 16 Bit ohne Flie\u00dfkommaeinheit f\u00fcr eine 1000-Punkte-DFT immerhin 7 Sekunden ben\u00f6tigte, schlugen f\u00fcr die Festkommavariante nur 700 ms und nach Optimierung (Abbildung der Divisions\u00adbefehle auf sukzessive Subtraktion) nur 120 ms zu Buche.<\/p>\n Als Fazit bleibt, dass beim \u00dcbergang auf Festkommadarstellung ein einfaches Codieren des Algo\u00adrithmus oft nicht zielf\u00fchrend ist, da insbesondere bei arithmetischen Operationen mit Daten\u00fcberl\u00e4ufen zu rechnen ist. Es ist dringend zu empfehlen, sich mit den m\u00f6glichen Datenwerten, auch den Zwischenergebnissen, zu befassen.<\/p>\n Ein ganz anderes Thema sind Lese- und Schreibzugriffe auf Bereiche, die sich im Programm wie RAM-Speicher verhalten (Lese- und Schreizugriffe), diesen aber nur durch eine besondere Funktionalit\u00e4t emulieren. Wenn dann der Compiler oder der Treiber diesen Zugriff noch verdeckt, kann es schon zu unerw\u00fcnschten Wechselwirkungen kommen.<\/p>\n Das Thema „Variablen im ROM“ sieht nach einem Widerspruch in sich aus, stellt doch ein ROM einen Festspeicher, ein Read-Only Memory dar. Seit der Einf\u00fchrung von EEPROM, also einem elektrisch l\u00f6schbarem, wiederbeschreibbarem ROM, ist das jedoch kein Widerspruch mehr, und einige Compiler unterst\u00fctzen das sogar, indem mithilfe des (nicht-Standard-) Schl\u00fcsselwortes\u00a0eeprom<\/strong>\u00a0dem Compiler\/Linker angezeigt wird, die Werte auch im EEPROM abzulegen.<\/p>\n Angenommen, ein Satz von 16 Daten soll in das EEPROM eines Mikrocontrollers geschrieben werden, weil die Werte bei Abschalten der Spannung gespeichert sein sollen. Dies k\u00f6nnen z.B. Konfigurationswerte sein, die bei jedem Neustart geladen werden.<\/p>\n Das Schreiben in das EEPROM wird wie erw\u00e4hnt von entsprechenden C-Compilern mithilfe von Laufzeitbibliotheken unterst\u00fctzt, aus Sicht der Anwendungsprogrammierung ist dies eine einfache Sache:<\/p>\n eeprom int eepIBasicConfig[16];<\/p>\n int k, iConfig[16];<\/p>\n \u2026<\/p>\n for( k = 0; k < 16; k++ )<\/p>\n eepIBasicConfig[k] = iConfig[k];<\/p>\n Das Gef\u00e4hrliche an dieser Codesequenz ist, dass hinter der scheinbar einfachen Wertzuweisung an eepIBasicConfig[] eine ganze Laufzeitroutine mit blockierender Kommunikation steckt, was so nicht ersichtlich ist. Meistens wird der erste Wert sofort geschrieben (weil in der Hardware ein Pufferplatz vorhanden ist), ab dem zweiten Wert wartet man dann auf die Fertigstellung des Schreibens des Vorg\u00e4ngerwerts \u2013 was durchaus einige Millisekunden dauern kann.<\/p>\n Im Klartext: Ein derartiges Schreiben in den Speicher, im RAM z\u00fcgig durchf\u00fchrbar, kann hier zu \u00fcberraschend langen Laufzeiten f\u00fchren. \u00c4hnliche Effekte ergeben sich, wenn man auf Peripherie \u00fcber ein Netzwerk- oder Bussystem (z.B. I\u00b2C bzw. TWI in kleinen Mikrocontrollersystemen) zugreift, das durchaus durch andere Teilnehmer blockiert sein kann, auch hier k\u00f6nnen lange, sogar unbestimmte Wartezeiten entstehen.<\/p>\n Die Kunst der nicht-blockierenden Kommunikation will es nun, dass man nur hineinschreibt, wenn dies sofort m\u00f6glich ist (weil der Puffer oder das Netzwerk frei ist, die notwendigen Ressourcen also verf\u00fcgbar sind), ansonsten sich merkt, dass noch etwas zu schreiben\/lesen ist, und zur weiteren Programmausf\u00fchrung zur\u00fcckkehrt. Hierbei muss dann gew\u00e4hrleistet sein, dass das Schreiben etwa durch zyklisches Design irgendwann fertig gestellt wird, und dass es keine Seiteneffekte gibt.<\/p>\n Ideal ist es hier, wenn man im Rahmen eines kleinen Betriebssystems einen Thread starten kann, der genau die gew\u00fcnschte Aktion startet und sich mit dem gleichen Parameter aufruft, falls die Aktion nicht durchf\u00fchrbar war. Wenn der erneute Aufruf sp\u00e4ter wieder aktiviert wird, wird erneut gepr\u00fcft, ob die Aktion durchzuf\u00fchren ist, bis alles fertiggestellt ist bzw. anderweitig abgebrochen wird.<\/p>\n Dies bedeutet allerdings einen etwas h\u00f6heren Initialaufwand. Wie es ohne Betriebssystem gemacht wird, steht beispielsweise in [1], ansonsten kann man solche nicht-blockierende Kommunikation auch in Interrupt-Service-Routinen, durch einen Timer aufgerufen, unterbringen.<\/p>\n Es sollte hier exemplarisch gezeigt werden, was eine hardwarenahe Softwareentwicklung bedeutet und welche Konsequenzen das f\u00fcr die Entwicklung hat. Die Software verliert hierbei nat\u00fcrlich ihren Anspruch, Hardware-unabh\u00e4ngig und damit portierbar zu sein. Dies ist eine h\u00e4ufig implizit vorhandene extrafunktionale Anforderung.<\/p>\n Andererseits werden andere, ebenfalls extrafunktionale Anforderungen erf\u00fcllbar(er), so dass es sich lohnt, \u00fcber einige Anpassungen nachzudenken.<\/p>\n In jedem Fall bedeutet hardwarenahe Softwareentwicklung, dass man sich mit der Hardware und ihren Eigenschaften und\/oder den Eigenschaften von Datentypen befassen muss, sowohl, um diese auszunutzen, als auch, um nicht zu scheitern.<\/p>\n [1]\u00a0 Christian Siemers, Embedded Systems Engineering Handbuch. Beitrag als PDF downloaden<\/strong><\/a><\/p>\n Wollen Sie sich auf den aktuellen Stand der Technik bringen?<\/strong><\/p>\n Dann informieren Sie sich\u00a0hier<\/strong>\u00a0<\/a>zu Schulungen\/ Seminaren\/ Trainings\/ Workshops und individuellen Coachings von MircoConsult zum Thema Implementierung \/Embedded- und Echtzeit-Softwareentwicklung.<\/p>\n Training & Coaching zu den weiteren Themen unseren Portfolios finden Sie\u00a0hier<\/a>.<\/strong><\/p>\n Wertvolles Fachwissen zum Thema Implementierung\/\u00a0Embedded- und Echtzeit-Softwareentwicklung steht\u00a0hier\u00a0<\/strong><\/a>f\u00fcr Sie zum kostenfreien Download bereit.<\/p>\n\n
Ressourcenbeschr\u00e4nkungen am Beispiel der diskreten Fouriertransformation<\/h2>\n
\nDie Fouriertransformation ist die Analyse eines (meist zeit-) konti\u00adnuierlichen Signals auf die beinhalteten Frequenzen. Hierbei geht man zun\u00e4chst von periodischen Signalen aus, die sich also nach einer bestimmten Zeit wiederholen. Diese Wiederholungsfrequenz ergibt dann die so genannte Grundfrequenz, das Frequenzspektrum ist diskret.<\/p>\n
\nIn Rechnern ist die „Zeitachse“ niemals kontinuierlich, sondern immer diskret. Dies liegt u.a. daran, dass selbst die AD-Wandler niemals zeitkontinuierlich, sondern immer nur zeitdiskret von der analogen in die digitale Welt \u00fcbertragen k\u00f6nnen. AD-Wandler diskretisieren sowohl Daten- als auch Zeitwerte.<\/p>\nDFT-Algorithmus mit Flie\u00dfkommazahlen<\/h3>\n
\ncos(2.L * PI * m * k \/ uiNumOfPoints);<\/p>\n
\nsin(2.L * PI * m * k \/ uiNumOfPoints);<\/p>\nUmsetzung in ein Festkommaformat<\/h3>\n
Das Qm.n-Format<\/h3>\n
Sinus und Cosinus<\/h3>\n
… und nun die DFT<\/h3>\n
\n
\ni32CosineTable[ui16Index];<\/p>\nDie L\u00f6sung des Problems<\/h2>\n
Zugriff auf Hardware mit besonderen Eigenschaften<\/h2>\n
Variablen im EEPROM<\/h3>\n
Die Kunst der nicht-blockierenden Kommunikation<\/h3>\n
Fazit<\/h2>\n
Literatur<\/h2>\n
\nhttps:\/\/www.elektronikpraxis.vogel.de\/themen\/embeddedsoftwareengineering\/management\/articles\/340538\/<\/p>\n
\nImplementierung – unsere Trainings & Coachings<\/h2>\n
\nImplementierung – Fachwissen<\/h2>\n