Mikrocontroller.net - Benutzerbeiträge [de]

PiBla

2021-06-18T15:29:36Z

172.26.40.198:

PiBla ist eine in VHDL geschriebene 8-Bit CPU. Die Grundarchitektur und der Befehlsatz entspricht dem des PicoBlaze Controllers für Xilinx-PLDs.

==Überblick==
Eine Beschreibung des Vorbildes - der Picoblaze - findet sich in der Wikipedia:
[http://de.wikipedia.org/wiki/Picoblaze], die Orginalbeschreibung von Xilinx dort: [http://www.xilinx.com/products/ipcenter/picoblaze.htm]. Der PiBla entstand auf dem Wunsch einen eigenen Controller zur Lernen und Forschen zu Schreiben, ohne selbst einen Assembler schreiben zu müssen oder völlig von Null (Architekturentwurf) anzufangen. Der Orginale Xilinx-Core kommt zwar auch als VHDL daher, allerdings beschreibt dies einen Netzliste aus Primitiven und eignet sich nicht wirklich um eigene Modifikation auszuforschen.

Der Pibla besteht aus dem eigentlichen Controller-Core und einem Block-Ram in der Befehlscode hinterlegt ist. Das eigentliche Programm wird in Assembler geschrieben, übersetzt und in ein Initialisierungsfile für den BlockRam umgewandelt.

==Zielhardware==
Der core wurde für den Spartan3 entwickelt und läuft auf dem Spartan3 Evalboard von Xilinx. Er ist ca 20% größer als der orginale picoblaze, da aber noch nicht völlig entwanzt, ist er auch noch nicht optimiert. Maximale Taktfrequenz lag so um 60 MHz.
Probeweise wurde der core auch für Altera cyclone ii übersetzt. Der Ramblock für den Programmspeicher muss extra generiert (MegaFunction) werden und es werden FF statt RamBlöcke für das RegisterFile, Subroutine-Stack und ScratchPad-Ram FlopFlops implementiert. Der Core ist also ohne weitere Handarbeiten deutlicher größer im Vergleich zum Spartan 3 (mit distributed Ram).

==Unterschiede==
Zum PicoBlaze gibt es folgende Unterschiede:
*jeder Befehl wird in einem Takt abgearbeitet
*der VHDL-Code ist eine Verhaltensbeschreibung (keine Netzliste wie der Picoblaze)

==Architekturdetails==
===Registerfile===
Alle 16 Register sind durch einen 16x8bit DualPort RAM realisiert. Die beiden Source-register werden durch die beiden 4 bit Vectoren
''freg_aSx'' und ''freg_aSy'' addressiert, das Zielregister durch ''freg_ai''. Der Dualport RAM ist als Feld von 16 Elementen integer beschreiben, die integer sind auf den Wertebereich 0 bis 255 eingeschränkt.
===Call/Return addressstack===
Der Speicher für die 10 bit breiten Rücksprungaddressen ist als Feld von 30 Elementen beschrieben und als "Last In" - "First Out"
Memory realisiert. Bei jedem Abspeichern (''save_pc = true'') wird der Addresspointer des Stacks um eins erhöht, sonst beim Rücksprung
(''restore_pc = true'') dekrementiert.. Ist beim Speichern die adresse 30 erreicht wird der pointer auf die erste Adresse ("1") gesetzt -overflow, ist beim Rücksprung dagegen die unterste Adresse aktive wird der pointer auf die höchste Adresse gesetzt -underflow.

===Programm counter PC===
Die Adresse mit dem nächsten Befehlscode kann sein:
*die aktuelle addresse im PC um eins inkrementiert: ''nx_address'',
*die Adresse 0x3FF bei Interrupt-requests
*die bits 9 bis 0 des aktuellen OpCodes (Sprung-adresse): ''instruction(9 downto 0)''
*der letzte Eintrag im call/Return-Stack ''addr4stack''

<syntaxhighlight lang="vhdl">
addr4stack <= stack(stack_addr);

nx_address <= (others => '0') when count_q = "1111111111" else
count_q + 1;

ld_address <= "1111111111" when (interrupt = '1') and (interrupt_del_q = '0') and int_ena_q else
instruction(9 downto 0) when (load_pc or save_pc) else
addr4stack;
--mux: Instructionpointer (PC) is loaded with a) jump address or instruction stack (subprogramm) b) next address (incremented)
count <= unsigned(ld_address) when load_pc or restore_pc else
nx_address;

process(clk)
begin
if rising_edge(clk) then
count_q <= count;
end if;
end process;
</syntaxhighlight>

===Arithmetik/Logikeinheit - ALU ===

==Status==

2010-Dez-10: Alle Befehle sind implementiert, allerdings sind einige (Logic-Befehle, SUB) noch nicht komplett überprüft.

==Sourcedepot==
Auch auf diesem Server: [svn://mikrocontroller.net/pibla|SVN-Protokoll] für SVN-Clients oder [http://www.mikrocontroller.net/svnbrowser/pibla] Webbrowser (HTML).

[[Kategorie:FPGA-Projekte]]
[[Kategorie:FPGA und Co]]
[[Kategorie:VHDL]]
[[Kategorie:C]]

Vervielfachung der Frequenz mittels Multiplikation

2021-06-18T15:27:35Z

172.26.40.198:

''von [[Benutzer:engineer|J.S.]]''

Die ist ein Konzept eines einfachen mathematischen Frequenzvervielfachers mittels Multiplikation:

Für den Fall perfekter Sinuswellen, welche symmetrisch zur X-Achse liegen oder deren Mittelwert bekannt und konstant ist, können die ganzzahligen Oberwellen durch eine simple Multiplikation mit der Grundwelle erzeugt werden.

Das Prinzip besteht darin, eine durch die Multiplikation entstehende Verschiebung infolge eines offsets wieder zu eliminieren.

<gallery caption="Beispiel" widths="300" perrow=2>
Datei:Frequenzvervielfachung-durch-multiplikation.gif | Mathematische Darstellung in Excel für X2 und X3
Datei:Chipscope-screen-wave-multiplier.gif | Mehrere Verdopplungen in Xilinx FPGA (25MHz * 256)

</gallery>

Wichtig ist, dass die Welle tatsächlich zur X-Achse symmetrisch und offsetfrei ist. In den Fällen, in denen das nicht der Fall ist, muss die Welle nachgesteuert oder vorgefiltert werden. In Echtzeit kann das mit einem Tiefpass geschehen.

==Anwendung==
* Soundgenerator
* Waveform Generator
* Klangsynthese
* Messinstrumente
* Oberwellendetektor

==Links==

[[Kategorie:Grundlagen]]
[[Kategorie:Signalgeneratoren]]
[[Kategorie:Signalverarbeitung]]
[[Kategorie:FPGA-Projekte]]

Erweiterung von digitalen IO-Ports

2021-06-18T15:23:59Z

172.26.40.198: /* Links */

Für einfache Steueraufgaben werden oft Referenzspannungen benötigt, die man nur relativ langsam oder gar nicht ändern muss. Dafür sollen gfs. keine Chips und weitere Pins am Controller verwendet werden. Um die Zahl der Ports zu erweitern, können folgende Schaltungen eingesetzt werden:

== Schieberegister ==

[[Datei:Erweiterung digitaler ausgaenge 1.png|thumb|right|320px|Multiplex-PWM als Port-Erweiterung für FPGAs]]
Die nebenstehende Schaltung besteht aus einem Schieberegister, das mit einem schnellen Taktsignal getrieben wird. Es erzeugt 4 unabhängige digitale Signale, die sich infolge der Dämpfungsglieder nicht schnell mitändern können. Auf diese Weise werden multiplexte PWM-Ausgänge geschaffen, die mit einem 1/4-tel der Taktfrequenz arbeiten. Die Fehlschaltungen, die beim Durchtakten eines neuen Schaltmusters entstehen, können bei der PWM-Generation im FPGA berücksichtigt werden. Um sie als echte digitale Ausgänge nutzen zu können, kann ein Buffer nachgeschaltet werden, der auch als Leistungstreiber agieren kann.
{{Absatz}}

== Schieberegister mit Latch==

[[Datei:Erweiterung digitaler ausgaenge 2.png|thumb|right|320px|Stabile Zusatzports mit Latch]]
Ist ein reiner digitaler Ausgang benötigt, der nicht zittern darf, sollte ein Latch eingesetzt werden, das dann mit nur einem der künstlich erzeugten Bits getaktet werden muss. Dazu muessen doppelt soviele Befehlssequenzen ausgegeben werden, wobei das Latch-enable eine 0/1 sehen muss. Es sollte ein Latch mit Schmitt-Trigger-Eingängen verwendet werden.

{{Absatz}}

Dafür eignen sich die Bausteine HC165 und HC595.

== Links ==
* Artikel zur PWM-Glättung: [[Glättungsfilter für 1-Bit DA-Wandlung|1-Bit Digital-Analog-Wandlung]]
* Porterweiterung mit SPI : [[Porterweiterung mit SPI]]
* Porterweiterung mit Standard-Chips : [[Porterweiterungen]]

[[Kategorie:Grundlagen]]
[[Kategorie:Bauteile]]
[[Kategorie:Portexpander]]

Analog-IO mit digitalen Bausteinen

2021-06-18T15:21:26Z

172.26.40.198:

Oft werden bei der Nutzung digitaler Bausteine einfache Analogeingaben oder -ausgaben benötigt, um langsame Signale zu erfassen. Nicht immer lohnt dabei der Einsatz eines AD-Wandlers, weil er zu teuer ist bzw. nicht mehr nachgerüstet werden kann oder mehrere Kanäle benötigt werden, die zuviel Platz beanspruchen, oder zuviele Pins belegen würden.

Im Artikel werden Funktionen aufgezeigt, die mit maximal 2 Pins auskommen.

== Einfacher 1pin-DAC ==
Die Ausgabe erfolgt z.B. mit einer [[PCM]] oder [[PWM]] mit anschließender analoger Filterung. Diese kann mit einem einfachen RC-Glied, einem T-Filter oder einem aktiven Filter geschehen. Siehe Artikel [[1-Bit Digital-Analog-Wandlung|1-Bit Digital-Analog-Wandlung]].

=== Beispiel Audio ===

[[Datei:Fpga-pwm-output-audio.png|thumb|right|320px|Filter für Audio-PWM: C1=470nF, C1*=4,7uF, R1=2700, R2=1000, C2=33nF, fg=15kHz, Ri>1kOhm]]
Die Abbildung rechts zeigt eine Dimensionierung für den Audiobereich. Mit Ra < 100 Ohm und Ri im Bereich einigen kOhm reicht ein Filter, das selbst einig km Widerstand hat und ab 5kHz-10kHz beginnt, abzufallen. Das Filter setzt konkret 3,3V auf den benötigten Pegel von +/- 0,45V herab und hat eine Netto-GF von ca 15kHz. Durch den geringen Innenwiderstand können unterschiedliche Geräte mit variablen Impedanzen angeschossen werden, ohne die Werte zu optimieren. Mit den o.a. Werten wird wird eine Dämpfung von 60dB für PWM-Frequenzen von 1 MHz erreicht. Diese lassen sich im uC mit einem Timer realisieren.

{{Absatz}}

== Einfacher 1pin ADC ==
[[Datei:Adc-with-1pin-for-fpga.png|thumb|right|320px|1-Bit-Analog-IO für FPGAs und DPSs]]

Durch Anwendung eines Komparators, der das zu messende Eingangssignal permanent mit einer Rauschquelle vergleicht, kann ein 1-Bit-Digitalsignal ähnlich einer [[Pulsdichtemodulation]] generiert werden, welches durch Filterung mit einem Dezimationsfilter (z.B. SINC-Filter) in einen digitalen Datenstrom aus Integer-Werten überführt werden kann. Auch möglich ist die Benutzung einer hochfrequenten Sinuswelle, wenn deren Frequenz und gfs. Phase bekannt ist und die mit einem steilen Notchfilter analog abgezogen oder intern per Signalverbeitung verrechnet wird. In FPGAs ist eine solche Lösung leicht realisierbar, wenn der LVDS-Eingang (mit Komparator) genutzt wird. Als Rauschquelle kann diese Schaltung verwendet werden: [[Dithering#Analog-Digital-Wandler]]

{{Absatz}}

== Kombinierter 2pin DAC ADC ==
[[Datei:Adc-with-2pins-for-fpga.png|thumb|right|320px|2-Bit-Analog-IO für FPGA]]

In Erweiterung der beiden o.g. Methoden kann für niedrige Frequenzen eine Regelung gebaut werden, die einem analogen Eingangssignal folgen kann. Dazu wird mit einem internen Komparator entschieden, ob die per PWM erzeugte externe Analogspannung die eingespeiste Messspannung über- oder unterschritten hat und diese entsprechend angepasst. Die Nachführung der Regelung muss langsamer geschehen, als die Änderungsgeschwindkeit, die durch die Bandbreite PWM-Glättung gegeben ist.

Insgesamt ist diese Schaltung etwas schneller, als die Lösung mit unkontrolliertem Rauschen.
{{Absatz}}

=== Beispiele ===
==== Ultraschall ====
Mit o.g. Schaltung können bei einem FPGA mit 50MHz eine genügend gute PWM mit <10% ripple erzeugt und letztlich 50kHz pro Pin mit einer Auflösung besser als 1% gescannt werden. Die Schaltung ist so in einer Applikation seit mehren Jahren im Gebrauch. Die OPs sind in einem Mehrfachgehäuse zusammengefasst, dazu wird ein analoges Notch-Vorfilter nach dem Komparator benutzt. Eine PWM wurde benutzt, um unabhängig von der Phase das so eingespeiste Rauschen wieder abziehen zu können.

==== Consumer-Audio ====
Mit den heute üblichen Taktfrequenzen von FPGAs können leicht PWM-Ausgaben von 100MHz erzeugt werden, die auch mit einfachen Filtern gut auf ein akzeptables Rauschniveau herabgesetzt werden können. Die Überabtastung von >10000 schafft genug head room für ein Filter entsprechender Dämpfung. Bei 10KHz-Grenzfrequenz sind im wichtigen Bereich Klangqualitäten von >6Bit (5kHz) bis zu 10Bit (50Hz) zu erreichen, was für einfache Tonausgaben und Sprache absolut reicht.

== 3-Pin DAC ==
[[Datei:R-2R.png|thumb|right|320px|Ladder Filter]]
Eine oft genutze Möglichkeit ist die Verwendung eines [[Widerstandsnetzwerk|R2R-Netzwerks]], um mit wenigen Pins ein quasi analoges Signal zu erzeugen. Damit wird eine direkte DA-Wandlung realisiert. Diese kann noch mit einer PWM oder PDM kombiniert werden, die auf dem untersten Bit arbeitet. Im Bereich Hi-End-Audio sind damit bereits 32-Bit-Wandler mit > 130dB SPDR realisiert worden. Allerdings erfordern diese ein hochgenaues Netzwerk und einen exakten Abgleich der Ansteuerung mit Kalibrierung, sowie einen sehr soliden analogen Aufbau.

== 3-Pin ADC ==
Auch umgekehrt kann ein einfacher linearer Wandler erzeugt werden. Mit 4 identischen Widerständen sind die Referenzpunkte 75% 50% und 25% eines gepufferten Signals abgreifbar. Dadurch kommt es beim Anstieg des treibenden Signals zu einem Durchschreiten des Schaltpunktes der 3 Eingänge. Durch Variation der Widerstände kann eine Spannungslupe aufgebaut werden, mit der eine Betriebsspannung überwacht werden kann, z.B. 1k,100,100,1k bei Schaltschwelle 50%.

== Erweiterung der Ports==
Wenn nicht genug IO-Ports für die Erzeugung von R2R-Ausgängen oder PWM-Kanälen zur Verfügung stehen, kann diese Schaltung zur [[Erweiterung von digitalen IO-Ports]] verwendet werden.

== Links ==
* Artikel zur PWM-Glättung: [[Glättungsfilter für 1-Bit DA-Wandlung|1-Bit Digital-Analog-Wandlung]]
* [[AD-Wandler]]
* [[Soft-PWM]]
* [[OneBitSound]]
* [[DA-Wandler]]

== Weblinks ==

[[Kategorie:FPGA-Projekte]]
[[Kategorie:Audio]]
[[Kategorie:DSP]]
[[Kategorie:Grundlagen]]
[[Kategorie:Bauteile]]

TEA6420

2021-06-18T15:18:16Z

172.26.40.198:

Der TEA6420 ist ein elektronischer Baustein und stellt eine Audioswitchmatrix dar, die 5 (Stereo-)Eingänge auf 4 Ausgänge schalten kann. Z.B. kann man Eingang 2 auf Ausgänge 1 und 3 legen, und Eingang 4 auf Ausgang 3 und 4. Gesteuert wird er über eine I2C-Schnittstelle.
== Erforderliche Hardware ==
* TEA6420
* Ein Breakout Board. Der TEA6420 hat nur einen Pin Abstand von 1,778 mm.
* Kondensatoren
** 18x 4,7 µF
** 01x 22 µF
** 1x 100 nF
* stabile 9V
und natürlich einen Microcontroller mit I2C.
<ref>http://f5ad.free.fr/Docs_ATV/TEA6420.pdf</ref>
== Anschluss ==
Es kursieren im Internet mehrere Datenblätter des TEA6420. [http://f5ad.free.fr/Docs_ATV/TEA6420.pdf Eins ist von 1996], es gibt aber auch eins von 2003, in dem einige wichtige Details nicht drin stehen. Auf Seite 4 sieht man wunderbar den Anschluss, und unten steht (nur im DB von 1996) auch, dass C1 bis C18 4,7 µF sein müssen.
Der Anschluss "SW" ändert die Adresse.
Und egal wie fest der TEA6420 in einem Breakout Board sitzt, man sollte ihn wirklich anlöten.
== Ansteuerung ==
Hier wird's knifflig. Es fängt an mit der Adresse; laut Datenblatt ist die (je nach SW):
{| class="wikitable"
|-
! SW/ADDR Pin !! Binär !! Hex
|-
| Nicht verbunden / 50kΩ Pull-up<ref>http://f5ad.free.fr/Docs_ATV/TEA6420.pdf</ref> || 1001 1010 || 0x9A
|-
| Masse || 1001 1000 || 0x98
|}<ref>http://f5ad.free.fr/Docs_ATV/TEA6420.pdf</ref>
Allerdings sind I2C-Adressen nur 7 bit lang. Der letzte Bit sagt aus, ob gelesen oder geschrieben wird.<ref>https://de.wikipedia.org/wiki/I²C#Adressierung</ref> Die "richtigen" Adressen sind also:
{| class="wikitable"
|-
! SW/ADDR Pin !! Binär !! Hex
|-
| Nicht verbunden / 50kΩ Pull-up<ref>http://f5ad.free.fr/Docs_ATV/TEA6420.pdf</ref> || 100 1101 || 0x4D
|-
| Masse || 100 1100 || 0x4C
|}
Der Aufbau der Datenpakete ist auf Seite 3 des Datenblattes verständlich beschrieben.
Tipp: In der Arduino IDE nutzt man die Funktion <code>Wire#send(B01001100)</code><ref>https://www.arduino.cc/en/Reference/WireSend</ref>, mit dem Beispiel Ausgang 3, Eingang 5, 4dB Verstärkung.<ref>http://f5ad.free.fr/Docs_ATV/TEA6420.pdf</ref>

[[Kategorie:Bauteile]]
[[Kategorie:Audio]]

Saugdrossel / balancing choke

2021-06-18T15:14:14Z

172.26.40.198:

Autor: user/show/eprofi

Die Aufgabe einer Saugdrossel ist z.B. bei einem 12-pulsigen Gleichrichter, die beiden 6-pulsigen Hälften zu verbinden. Läßt man sie weg, sinkt der Stromflusswinkel in den Trafospulen und Dioden, so dass sich die Trafoverluste verdoppeln.

Momentan sehe ich eher einen 1:1-Spartrafo (eine Wicklung mit Mittelanzapfung) ohne Luftspalt.

Alternativ kann man zwei ungekoppelte Drosseln verwenden (nur geringfügige Verschlechterung) oder die beiden Hälften in Reihe schalten.

Da man hierzu nur sehr wenig Informationen findet, habe ich 2009 einen wikipedia-Eintrag erstellt, der kommentarlos vom umstrittenen Power-Lösch-User Millbart ins Nirwana befördert wurde.

Im wikipedia-Eintrag https://de.wikipedia.org/wiki/Dreiphasengleichrichter heißt es bei https://de.wikipedia.org/wiki/Dreiphasengleichrichter#Zw%C3%B6lfpulsgleichrichter :
"In Reihenschaltung, auch als B6-2S Schaltung bezeichnet, ergibt sich eine doppelte Ausgangsspannung, die Stromstärke der Schaltung entspricht der Stromstärke der einzelnen Brücken:"
 
Das stimmt aber nicht ganz: die Spannung ist weniger als die Summe der beiden Hälften, und der eigenltiche Grund der Reihenschaltung wird gar nicht genannt: die oben erwähnte Halbierung der Trafoverluste durch Erhöhung des Stromflußwinkels.

Im Absatz danach ein Bild der Parallelschaltung, bei dem die Saugdrossel fehlt:
"In Parallelschaltung, auch als B6-2P Schaltung bezeichnet, ergibt sich ein hoher Ausgangsstrom, die Ausgangsspannung entspricht der Spannung der einzelnen Brücken:"
 Hier eine LTspice-Simulation:
[[Datei:12pulsGleichrichterVariationen.png]]
Die Wicklungsströme der 4 Varianten:
[[Datei:12pulseWindingCurrents.png]]
Die Verlustleistung der 4 Varianten:
[[Datei:12pulseWindingLosses.png]]
Man sieht deutlich den kurzen hohen Stromfluss. Mit Ctrl+Klick auf den Graph-Namen im Plot-Pane kann man die Durchschnittsleistung anzeigen lassen, ebenso findet sich eine Liste in der Log-Datei, die man mit Ctrl+L anzeigen lassen kann. 
Hier die LTspice-Datei:
[[Datei:12pulsGleichrichterVariationen.asc]] 
die dazugehörige Plot-Datei zeigt gleich nach der Simulation die relevanten Ströme:
[[Datei:12pulsGleichrichterVariationen.plt]]

[[Kategorie:Bauteil]]

Software-Architektur

2021-06-18T15:13:24Z

172.26.40.198:

= Grundlagen =

== Einleitung ==
Die vermutlich häufigste Problematik, die sich Programmierern bei der Entwicklung von Software stellt, ist die nach einer systematischen Erzeugung von 'gutem' Code und qualitativ hochwertiger Software - sprich nach der Entwicklung von Software als Qualitätsprodukt. '''Software Engineering''' ist also nach IEEE-Definition die Anwendung ingenieursmäßiger Entwurfsmethodiken auf den Bereich des Softwareentwicklung. Mit genau dieser Fragestellung beschäftigt sich der Teilbereich der Softwaretechnik in der Informatik.

Zweck dieses Artikels ist es, grundlegende Techniken vorzustellen, mit denen man als Entwickler seine Software etwas besser strukturieren und flexibler gegenüber Änderungen gestalten kann. Zum Verständnis dessen, wie das erreicht werden kann, müssen daher zunächst einige grundlegende Konzepte erklärt werden.

== Daten ==
Essentiell für datenverarbeitende System ist der grundlegende Begriff des 'Datums' bzw. der Daten. Darunter versteht man die zeit- und wertdiskrete Repräsentation analoger Größen ('''Informationen'''). Beispielsweise resultiert aus der Messung einer analogen Größe (z.B. Temperatur) eine digitale Zahl (AD-Wandlung). Im Umkehrschluss können aus digitalen Daten auch wieder analoge Größen erzeugt werden (DA-Wandlung).

Daten besitzen immer ein Format, da ein diskretes Rechensystem selbst bestimmte Repräsentationen für die Berechnung an sich nutzen muss. Für Fließkommazahlen wird z.B. die IEEE-754 Repräsentation genutzt, aber selbst die Darstellung als Integer impliziert schon ein minimales und ein maximales Element und eine Zahlenauflösung dazwischen. Im Codebespiel dieses Artikels wäre ein internes 8.1 Bit-Format vom Sensor [https://www.mikrocontroller.net/part/DS1621 DS1621] in eine Komma-Darstellung zu konvertieren.

Das heißt in der Quintessenz: Konvertierungen zwischen Datenformaten sind essentieller Bestandteil jeder Software. Entsprechend wichtig ist Konsistenz dieser Daten im Gesamtsystem.

=== E/R Modell ===
Zur Modellierung von Daten eines Softwaresystems wird häufig das [https://de.wikipedia.org/wiki/Entity-Relationship-Modell Entity-Relationship-Modell] verwendet. Mit dieser Diagramm-Notation kann eindeutig ein gemeinsames und konsistentes Format von Daten spezifiziert werden. Das Codebeispiel dieses Artikels beschreibt nur die Verarbeitung eines Temperaturwerts, daher sei für kompliziertere Systeme auf die entsprechende Literatur verwiesen (Chen/IBM).

=== Erweiterte Backus-Naur-Form ===
Zur Darstellung von Datenformaten eignet sich sehr gut eine Notation in der [https://de.wikipedia.org/wiki/Erweiterte_Backus-Naur-Form '''EBNF''']. Diese kontextfreie Sprache dient zur eindeutigen Spezifikation von Daten und kann leicht durch [https://de.wikipedia.org/wiki/Syntaxdiagramm Syntaxdiagramme] visualisiert werden. Sie dient hauptsächlich zur Beschreibung von Transformationen von Daten durch Prozesse.

== Datenfluss ==

Software fällt nur in den seltesten Fällen innerhalb von ein paar Stunden vom Himmel und ist dann für immer einfach da. Stattdessen unterliegt die Entwicklung derselbigen eines Prozesses, also eines zeitlich dauernden Vorgangs, durch den definierte Eingaben durch Arbeit zu Ausgaben transformiert werden.

[[Datei:01-Dataflow.png|mini|Datenflussprinzip]]

Die Strukturierte Analyse und Design von Ed Yourdon u.a setzt darauf auf, zunächst zu identifizieren und zu spezifizieren, was die Software überhaupt leisten soll (Requirements bzw. Anforderungsanalyse) und mündet in einem Anforderungsdokument.

Aus diesem Anforderungsdokument werden nun die Funktionen abgeleitet, welche die Software tatsächlich während ihres Betriebs leisten muss.

Diese funktionalen Anforderungen werden innerhalb der Software auch als ein 'Prozess' betrachtet - einen Prozess, den die Software zur Durchführung der jeweiligen Funktion durchlaufen muss. Für das Code-Beispiel zum Artikel wäre die dort maßgebliche 'Funktion' der Software, die Werte eines I2C-Thermometers auf UART und LCD darzustellen. Der I2C-Slave ist also die Datenquelle, UART und LCD sind Datensenken.

Durch die Kombination der Definition eines 'Prozess' mit der hierarchischen Dekomposition eines komplizierten Vorgangs in kleinere Vorgänge ('Teile-und-Herrsche') kommen also also zwei Grundprinzipien der Informatik zum Tragen:

* Prozess = '''I'''nput-'''P'''rocessing-'''O'''utput ('''E'''ingabe-'''V'''erarbeitung-'''A'''usgabe)
* Teile-und-Herrsche zur Unterteilung von Prozessen in Subprozesse

Yourdons Datenflussdiagramme (DFD) dienen dazu, diese Zerlegungen von Software-Funktionen zu beschreiben. Sie beschreiben, '''woher''' Daten kommen ('''Datenquelle'''), '''welche''' Transformationen sie in ihrer Verarbeitung durchlaufen und '''wohin''' die Daten am Ende ihrer Transformation fließen ('''Datensenke'''). Das wird letztlich als Datenflussprinzip formuliert. Diese DFDs werden immer im Zusammenhang mit Entity-Relationship-Diagrammen (ER-Diagramme) erstellt, beschreibt, was die eigentlichen Daten überhaupt sind und was relevant für die Datenhaltung ist.

Als Datenquellen/senken in DFDs dienen Datenbanken (Persistenz, Symbol: Ξ) und Terminals (Benutzerinteraktion, Symbol: Rechtecke). Verarbeitungen werden als Prozesse in Kreisen symbolisiert. Das Code-Beispiel verwendet keine Persistenz für die Sensordaten - dort müssten sowohl der I2C-Sensor als Datenquelle, sowie die Datensenken (UART, LCD) mit einem Terminal-Symbol verwendet werden. Zum Einen, weil die formatierten Daten direkt dem Anwender gezeigt werden (LCD) oder weil sie von anderen externen Teilnehmern stammen (I2C-Sensor) bzw. zu extern geliefert werden (z.B. UART).

Die Kombination aus DF- und ER-Diagrammen dient als erstes Design-Dokument, welches spezifiziert, was die Software überhaupt für Funktionen hat! Für den Praktiker ist an dieser Stelle wichtig, dass es gut ist, Daten fließen zu lassen und nicht zur Unkenntlichkeit zu zerstückeln.

Um es mit Mitteln der Elektrotechnik etwas griffiger zu formulieren: Datenflussdiagramme stellen im Prinzip die Leiterbahnen und die 'Verbraucher' dar. Analog zum 'Prozess' ist der Stromfluss zwischen den Potentialen (von Quellen zu den Senken) - die Dauer des Prozesses kann man als Äquivalent zur elektrischen Arbeit interpretieren (⇒ was sie auf etlichen Abstraktionsebenen unterhalb der Softwareebene letztlich auch ist).

== Kontrollfluss ==
Zur Erklärung des Kontrollflusses soll das Beispiel des Stromflusses erweitert werden. Oft reicht bereits einfach ein geschlossener Stromkreis (zwischen Quelle und Senke) aus, sodass ein Strom fließt und an einem Verbraucher Arbeit verrichtet wird. Manchmal muss dieser Prozess aber abhängig von bestimmten Bedingungen gemacht werden - z.B. sollte ein Dämmerungsschalter bei Tag (in nicht-arktischen Gegenden) keinen Strom fließen lassen. '''Bedingungen''' werden mit '''Kontrolle''' gleichgesetzt - man benötigt eine Instanz zum Kontrollieren, ob die Bedingung eingehalten ist. Z.B. ob ein bestimmtes Flag gesetzt ist oder ein bestimmter Schwellwert überschritten wurde. Kontrollfluß ist also etwas, was kostet (im Sinne von 'den Datenfluss ausbremst') und was immer an Daten gekoppelt ist. Unter Kontrollmechanismen versteht man in etwa die klassischen '''if'''/'''for'''/'''while'''/'''switch'''-Konstrukte. Kontrolle ist immer schlecht - je mehr man hat, desto mehr Overhead kann man damit erzeugen (i.S.v. die Kontrolleure kontrollieren) und dementsprechend mehr Fehlerpotential in seine Software generieren. Ziel eines sauberen Designs ist es also, Kontrolle zu minimieren.

Datenflussdiagramme können diese Aufgabe der Kontrolllogik nicht übernehmen - sie stellen nur dar, wie Daten fließen sollen und geben somit noch kein direktes Design vor.

=== Structure Charts ===

Um aus den entstandenen ER- und DF-Diagrammen ein Design abzuleiten,
wird eine Darstellung als [https://en.wikipedia.org/wiki/Structure_chart Structure Chart] verwendet. Diese entsprechen einem Baum aus Funktionsaufrufen und visualieren, zwischen welchen Komponenten Datenfluss und wo Kontrollfluss stattfindet.

Dieser Vorgang nutzt die in den DFDs identifizierten Prozesse und stellt diese in einer Baumstruktur dar. Datenfluss von und zu Subprozessen wird durch kleine weiße Pfeile symbolisiert. Übernimmt ein Subprozess eine Kontrollaufgabe symbolisiert ein kleiner schwarzer Pfeil das Ergebnis dieser Prüfung ('''Kontrolltoken'''). Der Aufbau des Baums erfolgt weitestgehend wieder nach IPO-Muster von links nach rechts (linkester Teilbaum prüft Eingabe des Gesamtprozess, rechtester übernimmt Ausgabeformatierung).

Der '''Schwerpunkt''' eines Prozesses (also eines Top-Level-IPO-Vorgangs) wird auch als '''Zentrum der Transformation''' bzw. objektorientiert als '''Top-Level-Controller''' bezeichnet. Hat der Baum an dieser Stelle seine Wurzel, erhält man ein Design ohne unnötige Kontrollinstanzen.

Für ANSI-C und strukturierte Entwicklung ist man an dieser Stelle fertig. Bei Anwendung objektorientierter Analyse und Design-Methodiken werden nun die dort üblichen Handwerkszeuge vorgestellt.

= Entwurfsmuster (Design Patterns) =

In der Software-Architektur gibt es Konstrukte, die sich als gut funktionierend erwiesen haben und bei korrekter Anwendung ein Design drastisch verbessern können. An dieser Stelle verhält sich die Softwaretechnik als "praktisches Handwerk" analog zu anderen Tätigkeitsbereichen, wie etwa beim Design von [[Richtiges_Designen_von_Platinenlayouts|Leiterplatten]] oder in der Mechanik - also eine Art Katalog von Do's und Don'ts, die ein Softwaredesign verbessern können.

Die hier vorgestellten Entwurfsmuster sind grundsätzlich objekt-orientierter Natur, sie setzen also ein grundlegendes Verständnis des Konzeptes eines 'Objekts' voraus, was aber die Verwendung der Muster für die rein prozedurale Programmierung (ANSI-C) nicht ausschließt.

Im Artikel wird unter einer 'Variable' also ein 4-Tupel verstanden, aus:
* Adresse zur Laufzeit
* Zustand (Wert)
* Bezeichner
* Datentyp

Ein Objekt ist also einfach eine spezielle Variable von einer Klasse/Struktur/Union (Datentyp) mit den speziellen Eigenschaften:

* Adresse zur Laufzeit: 'this'-Pointer
* Zustand: Zustände aller Member-Variablen
* Datentyp: (Klasse/Struktur/Union)

und dem gedanklichen Trick, der die Objektorientierung ausmacht, dem Konzept der '''Datenkapsel''': ein Objekt beinhaltet also nur logisch irgendwie zusammenhängende Daten und Funktionen. Der Grad, in dem ein Objekt abhängig von anderen Komponenten ist, wird in der Softwaretechnik als '''Kopplung''' bezeichnet. Der Grad, wie stark logisch zusammenhängend ein Objekt zu seinen Member-Variablen ist, ist dagegen als '''Kohäsion''' bekannt. Ziel beim Entwurf einer Software-Architektur ist es, '''Kohäsion zu maximieren''' und '''Kopplung zu minimieren''', sodass austauschbare Software-'Bausteine' entstehen.

Entwurfsmuster sind dabei die Mittel, mit denen diese Minimierung von Kopplung und die Maximierung von Kohäsion erreicht werden kann.

== Strategy-Pattern (Strategie) ==

Das einfachste Entwurfsmuster, welches die Grundlage für fast alle weiteren Muster bildet, ist die Strategie. Das Muster zeichnet sich einfach durch Polymorphie der Implementierungen gegenüber einer abstrakten Basisklasse aus. Jede Implementierung dieser Schnittstelle ist letztlich eine wählbare Strategie.

== State-Pattern ==
Verbindet man das Strategiemuster mit mehreren gleichzeitig wählbaren Strategien, entsteht ein Zustandsmuster. Eine Ampel, die zeitabhängig mehrere Zustände von alleine durchläuft, ist ein Beispiel für das State-Pattern.

== Observer-Pattern (Beobachter) ==

Das Beobachter-Muster beschreibt die Interaktion zwischen Objekten zur Laufzeit. Ein Beobachter möchte über Änderungen eines anderes Objektes benachrichtigt werden. Dieses Objekt stellt demzufolge einen Subscribe/Unsubscribe-Mechanismus bereit, über den sich ein abstrakter Beobachter registrieren darf. Ändert sich das Objekt, werden alle registrierten Beobachter mit dem aktuellen Objektzustand benachrichtigt.

= Architekturmuster =

Wie für die Strukturierte Analyse beschrieben, ist es auch bei objektorientierten Methodiken das Ziel, Kontrolle zu minimieren. Anhand der ''Structure Charts'' wurde ein Vorgehen zur hierarchischen Erstellung eines Designs beschrieben. Das objektorientierte Pendant zur Modellierung von kohäsiven und wenig gekoppelten Kontrollinstanzen stellen die Kompositmuster '''Model-View-Controller''' bzw. dessen vereinfachte Form '''Model-View-Presenter''' dar.

== Model-View-Controller ==
[[Datei:02-MVC.png|mini|Model-View-Controller]]

Das MVC-Muster ist ein etwas komplizierteres Muster, welches im Wesentlichen das Ziel hat, Verantwortlichkeiten zu trennen (also Objekte wirksam zu entkoppeln).

In Anlehnung an die Objekthierarchie bildet es eine Baumstruktur, in welcher die Kontrollinstanz (der '''Controller''') an der Spitze des Dreiecks sitzt. Dieser ist in dem Dreigespann auch der Einzige, der die Daten direkt verändern darf. Streng genommen zählen auch die registrierten Beobachter als Teile vom Datenmodell, daher darf deren Registrierung/Deregistrierung auch nur über den Controller verwaltet werden.

Das '''Datenmodell''' (die Daten) selber kann im Prinzip beliebig sein. Wie im Beispiel für die ThermometerGeneric<>-Policy kann das Datenmodell selber auch wieder ein Subcontroller-MVP/MVC sein. Wichtig für das Datenmodell ist eigentlich nur, dass das Datenmodell selber feststellen können muss, ob es geändert wurde oder nicht. Diese Aufgabe darf nicht durch den Controller übernommen werden (siehe Structure Charts und Anmerkung zu Kontrollfluss). Idealerweise ruft also der Controller einfach einen Setter des gewählten Datenmodells auf und dieses prüft darin, ob sich der aktuelle Parameter vom gespeicherten Zustand unterscheidet (onChange).

Die Sichten ('''Views''') stellen letztlich nur die Ausgabeformatierung der eigentlichen Nutzdaten dar. Eine Sicht darf sich beim Controller an- bzw. abmelden, Aktualisierungen über Datenänderungen zu erhalten. Wird über den Controller eine Änderung des Datenmodells impliziert, werden die registrierten Sichten über diese Änderung benachrichtigt.

Ziel beim Schreiben eines MVC-Compounds sind dabei:
stupide Views, dünne Controller-Klassen und fette Datenmodelle.

Für eine direkte Implementierung benötigt es im Gegensatz zu MVP Polymorphie für die Views (im Beispiel durch IView dargestellt) sowie für die Datenmodelle (im Beispiel IThermometer). Das lässt sich nicht vermeiden, benötigt aber letztlich auch nur einen Funktionsaufruf mehr, der bei einer klaren Objekthierarchie und klarem Kontrollfluss nicht teuer ist.

== Model-View-Presenter ==
[[Datei:03-MVP.png|mini|Model-View-Presenter]]

MVC ist ein sehr flexibler Mechanismus, mit dem sehr gut eine Trennung von Daten und deren Darstellung erreicht werden kann. Manchmal ist dessen volle Flexibilität gar nicht nötig und man möchte z.B. auf die Polymorphie des Datenmodells verzichten. In diesem Fall kann man ähnliche Ergebnisse auch mit einem ''Passive-View'' bzw. einem ''Supervising Controller'' erzielen. Im Codebeispiel generiert die Template-Policy Thermometer<> (cpp_generic/thermometer.hpp) eine MVP-Klasse aus Port (cpp_generic/i2cclient.hpp) und DS1621-Treiber (cpp_generic/sensor_ds1621.hpp). Die beiden Views (LCD+UART) registrieren sich auf Updates und werden bei Änderungen des Datenmodells benachrichtigt. Wesentlicher Unterschied gegenüber MVC ist es, dass das Datenmodell nicht mehr dem Benutzer gegenüber exponiert wird, sondern jeglicher Datenzugriff über den Controller (-> Presenter) passiert.

== Kombinationen ==
[[Datei:04-MVC-MVP-Compound.png|mini|MVC-MVP-Verschachtelung]]

Wie bereits angemerkt, kann eine Verschachtelung von MVP/MVC erfolgen, wodurch Komplexität durch weitere Dekomposition gelöst werden kann. Im mvc-tutorial/cpp_generic_final wird dies demonstriert, was einer FatClient-Implementierung entsprechen sollte. Das wäre z.B. beim RaspberryPi der Fall, wo unterschiedliche Sensorentypen an SPI oder I2C hängen können und per UI zur Laufzeit des Programms selektiert werden. Die Thermometer-Klasse dient somit als ein Proxy für die reale Implementierung durch die MVP-Policy. Vorteil ist für den Anwendungsentwickler, dass die Thermometer-Komponente immer durch die gleiche API bedient wird, aber erweiterbar für neue Sensorentypen bleibt.

= Anwendung =

Im Anhang des Artikels ist ein GitHub-Repository verlinkt, welches anhand eines Thermometer-ICs die Anwendung der beschriebenen Architekturmuster zeigen soll. Das Beispiel abstrahiert dabei den Sensor vollständig von der konkreten I2C-Slave-Implementierung, weswegen letztere als hardwareabhängiges Backend auch bewusst weggelassen wurde. Das Beispiel auf PIC, AVR oder ARM bzw. zu adaptieren bzw. in ein vorhandenes Framework zu integrieren ist nicht die direkte Aufgabe des Artikels.

Generiert man sich mit Hilfe von SWIG einen C-Wrapper für die C++-Implementierung, erhält man letztlich eine Implementierung, die der Structure-Chart-Lösung sehr ähnlich sehen sollte.

[[Datei:Thermometer.svg|mini|Codechart-ähnliche Darstellung des hierarchischen Aufbaus der Thermometer-API]]

= Links =
* [https://github.com/db8fs/mvc-tutorial Sourcen zum Artikel]
* [http://yourdon.com/strucanalysis/wiki/index.php/Chapter_9 Tutorial zu DFDs in der Strukturierten Analyse (Ed Yourdon)]
* [http://martinfowler.com/eaaDev/PresentationModel.html Model-View-Presenter (Martin Fowler) ]

[[Kategorie:Grundlagen]]
[[Kategorie:C]]

Sensorlose BLDC Ansteuerung

2021-06-18T15:12:11Z

172.26.40.198:

== Grundlegendes zum Artikel ==
Dieser Artikel ist im Wesentlichen als Ergänzung zu:
* [http://www.mikrocontroller.net/articles/Brushless-Controller_f%C3%BCr_Modellbaumotoren Brushless-Controller für Modellbaumotoren]
zu verstehen. Es wird jedoch nicht mit einem analog Komparator, sondern mit einem ADC gearbeitet,
wie hier beschrieben:
* [https://www.youtube.com/watch?v=szgVUfyX8JM Texas Instruments Artikel ]

== Einleitung==
Bei der sensorlosen Ansteuerung wird üblicherweise die BEMF der in der Luft hängenden Phase
des BLDCs ausgewertet, um den nächsten Kommutierungsschritt einzuleiten.
Hierbei treten diverse Probleme auf:
* Die BEMF ist bei niedrigen Drehzahlen nur sehr gering und von daher schwer zu erfassen
* Der BLDC muss häufig lange Zwangskommutiert werden, bevor er startet
* Die Inbetriebnahme ist umständlich und müßig
* Einkoppelnde Störungen auf den analog Komparator durch die PWM

== Abhilfe ==
Man integriert die BEMF Spannung. Dabei achtet man darauf, dass die BEMF-Spannung größer bzw. kleiner als Endstufenspannung/2 ist, bevor man anfängt zu integrieren.
Synchronisiert man seine Messung nun noch mit der PWM, so sind auch eingekoppelte Störungen kein nennenswertes Problem mehr.

== Mikrocontroller ==
Bei der Wahl des µC entschied ich mich für meinen lieblings 8-Bit AVR, den Atmegaxx8. Dieser, so dachte ich, hat genügend Ressourcen. Jedoch trat ein Problem auf, das mich im Nachhinein aber nur bedingt stört, da es ja funktioniert:

'''Der ADC ist zu langsam:'''
Der ADC eines normalen AVRs kann mit maximal 200kHz samplen. Bei 20MHz CPU Clock ergibt sich ein Prescaler von 128, somit läuft der ADC auf 156,25kHz. Eine Wandlung dauert somit 83,2µs. Demnach wählte ich eine PWM Frequenz von 10kHz (100µs Periodendauer, pfeift furchtbar) um noch etwas Reserven zu haben. Idealerweise müsste ich die BEMF auch mit 10kHz samplen, was ja grundsätzlich möglich wäre, wenn nicht noch andere Werte mit gesamplet werden müssten wie:
* Spannung an der Endstufe
* Strom
* Flussintegralgrenzwert

Somit entschied ich mich, die BEMF mit 5kHz bzw. jede zweite Messung zu machen, und die anderen drei Werte nur jede 5KHz/3. Bei einer nächsten Version würde ich wohl auf einen STM32F4 zurück greifen. Dessen ADC(s) sind viel schneller und auch komfortabler zu bediehnen.
Der ADC des AVR wird von einem Timer automatisch gestartet (10KHz), welcher aber kurz vor Beginn des nächsten PWM-Zyklus den ADC startet.

== Schaltung ==
Zur Schaltung gibt es im Wesentlichen nicht viel zu sagen. Die Endstufe besteht aus 6 MOSFETs und wird vom µC gesteuert. Ein 100mR Widerstand ermöglich eine Überwachung des Motorstroms; falls dieser zu hoch wird setzt die Strombegrenzung ein und die Endstufe wird kurz abgeschaltet. Es ist taktisch sinnvoll, sowohl BEMF-Spannungsteiler als auch Versoungsspannungsteiler im selben Verhältnis zu skalieren, so lassen sich die Werte direkt zueinander in Bezug setzen, ohne das herumskalieren zu müssen. Alle Bauteile mit "n.i.p." sind nicht bestückt.

<gallery>
Datei:BLDC Drive Power 1 .jpg|Endstufe
Datei:BLDC Drive Power 2 .jpg|Treiber
Datei:BLDC Drive uC .jpg|Mikrocontroller
</gallery>

== Software ==
Die Software ist in C geschrieben und wurde mit Atmel Studio entwickelt. Das Programm ist sehr überschaubar.
In der while(1)-Schleife werden Werte über die serielle Schnittstelle ausgegeben, das wars schon.
Der Rest spielt sich in der PWM-ISR ab, welche mit 10kHz aufgerufen wird:

Als erstes wird das ADC-Register in Abhängigkeit vom letzten ADMUX ausgelsen. Anschliessend wird der MUX für die nächste Messung vorbereitet. Die eigentliche Messung wird jeweils kurz vorm Timerüberlauf gestartet, damit der ADC mit seiner Messung beginnt, kurz nachdem die PWM wieder von vorn beginnt (Der ADC benötigt durchaus etwa 12µs bis er misst, nachdem er sein Startsignal bekommen hat :-) ).

Danach wird eigentlich nur noch geguckt, was mit den Werten los ist. Ist der Strom in Ordnung bzw. hat die BEMF schon U/2 über bzw. unterschritten und kann mit der Integration begonnen werden?
Wird die Integrationsgrenze überschritten wird weiter kommutiert.

Für den Fall, dass der BLDC ungünstig steht und nicht sofort anläuft wird einmal "per Hand" bzw. alle 100ms eine Zwangskommutierung durchgeführt. In der Praxis muss eigentlich bei meinem 2 polpaarigen Modellbau BLDC nur 1x Zwangskommutiert werden bzw. manchmal auch garnicht.

Da der Motor immer im Interrupt kommutiert, lässt sich auch recht bequem die Drehzahl errechnen indem man die Interrupts zwischen 6 Kommutierungen zählt. Daraus lässt sich dann die Drehzahl einfach berechnen:

<math> n = \frac{f_{pwm} \cdot 60}{Counts \cdot Polpaarzahl} </math>{{clear}}

wobei man natürlich gleich 60 und Polpaarzahl miteinander verrechnen könnte.

[[Datei:Programm.zip|miniatur|links]]

== Oszillogramme ==
<gallery>
Datei:BEMF1.jpg|BEMF1
Datei:BEMF2.jpg|BEMF2
Datei:Startvorgang.jpg|Startvorgang
</gallery>

== Aufbau ==
<gallery>
Datei:Aufbau BLDC.jpg|
</gallery>

== Known Issues ==
Der AVR-ADC ist für hohe Drehzahlen zu langsam bzw. ist die PWM -und Samplefrequenz mit 10/5KHz zu langsam um ausreichen Auflösung für das Flussintegral zu bekommen. Die Problematik ist dann, dass nur 1-2 Samples pro Kommutierungsschritt zur Verfügung stehen, was vorn und hinten nicht ausreichend ist.

'''Lösungen:'''
* Man verwendet einen schnelleren externen ADC
* Man schaltet bei hohen Drehzahlen in den Komparatormodus
* Anderer µC mit schnellerem ADC verweden z.B. STM32F4 - Derivat

== Lösung mit einem schnelleren Controller ==
Der Controller wurde durch einen STM32F050K6 ersetzt. Dieser sampelt nun im Center-Aligned PWM Mode in der Pulsmittte alle Werte und schaufelt diese per DMA in einen Buffer. Die PWM Frequenz beträgt 20kHz.
Klappt alles prima.

Ich habe den BLDC nun in ein Plexiglaswürfel "gesperrt" und weiter geforscht. Es funktioniert nun sehr gut. Es wird vor dem Anlauf die Rotorposition bestimmt und der Rotor in eine bestimmte Stellung gebracht. Das Ergebnis ist, dass der Rotor sauber anläuft.

Hier das Programm:
[[Datei:Programm_STM32.zip]]

[[Kategorie:Grundlagen]]

SDR

2021-06-18T15:10:15Z

172.26.40.198:

Die Methode des Software Defined Radio, kurz SDR, erlaubt es, verschiedenste Aufgaben der digitalen Signalerfassung und -bearbeitung im Hochfrequenzbereich zu übernehmen. Im Gegensatz zu klassischen Empfangs- und Sendekonzepten erfolgt hier der Großteil der Signalverarbeitung softwareseitig. Nur auf einen kleinen Frequenzbereich abgestimmte Analoghardware ist nicht vorhanden, wodurch die Geräte z.B. nicht auf einen Funkstandard allein beschränkt sind und flexibel eingesetzt werden können.

[[Kategorie:Grundlagen]]
[[Kategorie:Signalverarbeitung|P]]

Altera Max10 Breakout Board

2021-06-18T14:57:53Z

172.26.40.198:

==Projektseite==
https://hackaday.io/project/13245-altera-max10-breakout-board

== Warum Max10? ==
* Aktuell (Aug 2016) der einzig verfügbare FPGA in QFP bis 50K LUT. 
**Eignung für geringe Stückzahlen, Handbestückung, Test/Inbetriebnahme
* Geringe BOM: Flash on package, single-supply
* 3 temperature grades für QFP: C,I,A

== Überschlagsrechnung BOM-Kosten 10M04SC ==
* 10M04SC, digikey 8,22 EUR (Abnahme 25 Stück) ODER
* 10M04SC, digikey 10,29 EUR (Abnahme 01 Stück)

* PCB, dirtypcb 0,65 USD (10mal 10x10 für 25USD -> 25/(10*4))
* MEMS CLK, digikey 1,00 EUR
* Caps (keine volle Bestückung für 04SC) 1,xx EUR
* Pin header, ebay/ali 0,35 EUR
10 bis 15 EUR

== Anforderungen ==
* A1. OpenSource; Design einfach modifizierbar und verwendbar
* A2. Max10 04K LUT bis 50K LUT QFP single-supply
* A3. geringe Material-Kosten für kleine Stückzahlen
* A4. händisch lötbar, wenig Bauteile
* A5. Gute GND-Anbindung auf Ansteckmodule/Baseboards
* A6. Auf Steckbrett verwendbar
* A7. Mit 2.54mm Pinheadern verwendbar
* A8. Breakout von möglichst vielen I/Os
* SI. Signal Integrity; PDN. power distribution network

== Spezifikation ==
* S1. Kicad-Design (A1)
* S2. Zwei PCBs mit Pin-kombatiblen Breakout für die package-Linien 04-25 und 40-50 (A2).
*** Die pinouts dieser beiden package-Linien sind ähnlich aber nicht gleich.
* S3. 2-Layer-PCB; max 50mm x 50mm (A3, SI)
* S4. Mindestens 0603; Footprints für händische Bestückung (A4)
* S5. Single row 1.27mm THT pin header (A8, A3, A4)
** Anordnung/Distanz zueinander: Vielfaches von 2.54mm
** A6 erfüllt bei Nutzung jedes 2. pins (GND geeignet positionieren)
** A7 wie folgt erfüllt: Breakout auf 2.54mm double row mittels
*** Adapter oder
*** Ribbon cable mit Klemmstecker (Seite1: 1.27mm single; Seite2: 2.54 double)
* S6. Optionale Bestückung mit 1.27mm THT double row für zusätzliche GND pins (A5, SI)

== Details (Spezifikation) ==
* D1. Pin header an allen 4 Seiten
* D2. Zwischen QFP und pin header: top layer für Signal; bottom layer GND (A5, SI)
* D3. (Fast) alle caps direkt unter das QFP (D2)
* D4. Möglichst wenig Überschneidungen der Power Traces (SI)
* D5. 0612 caps für HF decoubling (A4, SI, PDN)
* D6. Pcb thickness: 0.6mm oder 0.8mm (SI, PDN)
* D7. Leiterbahnbreite, spacings: 0.150mm; drill: 0.300mm (A3)

== Bewertung ADC ==
* Den FPGA gibt es im QFP als SA (1Msps ADC) und als SC (ohne ADC). Beim FPGA beträgt der Preisunterschied zwischen SA und SC 4-8EUR. Ein 1Msps ADC kostet ca. 4EUR.
* Der ADC verursacht auch im deaktivierten Zustand einen Stromverbrauch an den ADC-Pins (Device Datasheet Seite 8)
* Bei Verwendung des ADC sind zusätzlich erforderlich: GND-ADC, VREF-ADC, VCC-ADC
** Dies ist zusätzlich auf 2 Lagen schwierig zu realisieren.

-> Zunächst auf ADC verzichten und erst einmal schauen, wie gut das PDN ohne die zusätzliche ADC-Beschaltung ist.

== Betrachtung zum PDN ==
* In der Mitte des Package befindet sich ein GND-Pad. Dieses muss elektrisch gut von allen 4 Seiten mit der GND-Fläche verbunden werden.
* Anzahl supplies, filter
** Der Fall Single-Supply ohne ADC ist dargestellt in "Device Family Pin Connection Guidelines" auf Seite 32 und 33. Hier werden 2 regulators vorgeschlagen.
** Aus Datei "Device Family Pin Connection Guidelines":
*** Auf Seite 33 wird ein Filter zwischen VCC_ONE und VCCA vorgeschlagen.
*** Auf Seite 32 steht: "Both VCCA and VCC_ONE must share a single power source using proper isolation filter."
** Aus Datei "Power Management User Guide":
*** Bildchen auf Seite 4: Die VCC_ONE pins und VCCA pins sind im Package direkt miteinander verbunden.
** Anfrage beim Support ergibt: VCCA pins und VCC_ONE pins sind im package NICHT miteinander verbunden.

* -> Spannungsversorgung des Boards über einen einzelnen 3V3-Pin.
* -> VCC_ONE und VCCO werden auf dem PCB gemeinsam als VCC_ONE_ geführt.
* -> VCCA wird über einen Filter realisiert

== Arbeitspakete ==
=== P1 Config pins (DONE) ===

=== P2 Betrachtung Clocks (done): ===
* Im Datenblatt wird auf eine relativ hohe Kopplung der pins im
E144-package hingewiesen. Datenleitungen sollten nicht direkt neben
einem CLK pin mit "hoher" Frequenz angeschlossen werden.

=== P3 Betrachtung Unterschiede 10M04 pinout vs 10M50 pinout (done): ===

=== P4 Anordnung der caps und Führung der Power traces (DONE) ===

=== P5 Schematic Symbole und PCB footprints erstellen DONE lrs) ===

===P6 Layout für breakout pcbs erstellen (DONE lrs) ===
* erfordert P5

=== P7 Bestückung (TODO) ===
* erfordert P6

=== P8 Basebord1 Schematic TODO) ===
: (̶f̶̶ü̶̶r̶̶ ̶̶p̶̶e̶̶r̶̶f̶̶o̶̶r̶̶m̶̶a̶̶n̶̶c̶̶e̶-̶t̶̶e̶̶s̶̶t̶̶s̶)
* ̶̶i̶/̶o̶-̶p̶̶i̶̶n̶̶s̶̶ ̶̶d̶̶e̶̶s̶̶ ̶̶f̶̶p̶̶g̶̶a̶̶ ̶̶m̶̶i̶̶t̶̶e̶̶i̶̶n̶̶a̶̶n̶̶d̶̶e̶̶r̶̶ ̶̶v̶̶e̶̶r̶̶b̶̶i̶̶n̶̶d̶̶e̶̶n̶
: Dafür kann man auch 2 breakout boards aufeinander stecken und gegeneinander testen.
* JTAG
* Jumper für configpin JTAGEN
* USB conn
* LDO an USB conn

=== P9 Basebord1 Layout (TODO) ===
* erfordert P7, P8

=== P10 Inbetriebnahme mit Baseboard (TODO) ===
* erfordert P7, P9

=== P11 Basebord2 Schematic (optional, TODO) ===
* JTAG
* Jumper für configpin JTAGEN
* USB conn
* LDO an USB conn
* Pinheader für typisches NRF24
* Footprint für ESP8266
* Pin header für FTDI UM232H-B (oder ähnlich)
* Pin header für wiz850io
* ...?

=== P12 Basebord2 Layout (optional, TODO) ===
* erfordert P7, P11

== Links ==
[http://www.m-pression.com/solutions/boards/odyssey/max10-teardown odyssey max10 teardown]

[[Category:FPGA und Co]]