Forum: Mikrocontroller und Digitale Elektronik poor man's Ethernet-oszi mit STM32, FIFO und AD9288


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


Angehängte Dateien:

Lesenswert?

gesucht:
eine preisgünstige, anpassbare Ethernet-Oszi-Lösung, die fest verbaut 
werden kann.

gefunden - uralt, aber gut:
Beitrag "100MHz DSO Selbstbau ohne FPGA mit STM32?"

Kontext mein aktuelles Projekt:
resonanter DC-DC Gegentaktwandler 3... 5 kW, 48 <-> 570 V, um meine 
Gabelstapler-Akkus nach v2g ("vehicle-to-grid")-Manier in meine 
PV-Stromspeicherung einzubinden.

Vorlage u.a. TI Design Guide: TIDM-02002 (s. Bild)
Challenge: tuning von Bauteilen und Taktung für ZVS / ZCS (zero-voltage 
- zero-current switching)

Wunschzettel für eine inline-Diagnose:
- 6 Signale: je DC-Spannung und Strom sowie Brückenstrom primär und 
sekundär
- 4 galvanische level
- 100 ... 200 ... 500 kHz Betriebsfrequenz
- Auflösung 50 samples / Vollzyklus minimal, 200 wäre schön
- oszis in der Brücke fest verbaut
- Triggern und Abfrage letztendlich über LAN

Inspiration1: xprotolab - das kann aber nur 100 kHz
Inspiration2: DSO203 - auch noch zu teuer, falsches Bedienerinterface
Aber die Schaltung des DSO203 kann als Vorlage dienen:
- OPA354 zur Signalaufbereitung
- AD9288 dual AD 8 bit - 40 Ms (gibts auch mit 80 oder 100 Ms)
- "ICE65L04F_VQ100" - dürfte ein FPGA sein
- STM32F103VCT6

Den STM32 gibts als "Bluepill" für ca 2€ bei aliexpress, AD9288 dito.
Die Lernkurve eines FPGA schreckt mich.
Andere Leute empfehlen an der Stelle AL422 FIFO (384k, 8 bit, 20 ns).
Ist zwar EOL, aber bei Ali für 1€ noch zu haben.

Also laß ich vom Konzept des DSO203 alles weg was stört und Geld kostet: 
Gehäuse, Akku, Meßbereichswahl, Display, Knöpfe, USB.

Stattdessen nehm ich so was als "Boilerplate":
https://github.com/AlexPuts/Modbus-TCP-for-stm32-blue-pill/blob/master/ModbusIP_ENC28J60_STM32/examples/modbus_IP_STM_example/modbus_IP_STM_example.ino
Modbus-TCP - perfekt und immer wieder mal zu gebrauchen.

Die erste Überlegung war, die ADC des STM32 zu verwenden.
Die sind zwar 12 bit, aber max 1 MHz.
Da krieg ich bei der Resonanzfrequenz meines Konverters von 200 k grad 5 
Punkte pro Vollzyklus - zu wenig. Zumindest für den Brückenstrom, von 
dem ich das Überschwingverhalten sehen möchte.

Also ist ein Highspeed-AD wie der AD9288 irgendwie im Boot.
Aber wie ansteuern?

Es gibt für ca 5€ Clones von "Saleae 24MHz 8-ch  Logic analyzers".
Die sind sicher gut für einen Testaufbau.
Aber inline macht deren USB mehr Ärger als Freude, auch wenn sie wohl 
unter sigrok an einer Linux-Kiste ansprechbar wären.

Der STM kann wohl per DMA parallele Datenflüsse direkt in 16 bit Breite 
von GPIO lesen. ST AN4666 "Parallel synchronous transmission using GPIO 
and DMA" betreibt das bis zu 10 MHz. Ich denke, der STM32 sollte dazu 
die Timing-Signale für den ADC mit generieren können.

Das wären 50 Samples pro Voll- oder 25 pro Halbzyklus in Resonanz - 
knapp, aber besser als gar nix. Im überresonanten Betrieb - da wo 
eigentlich der Stromverlauf interessant wird - hab ich noch 10 
Samples/Halbzyklus.
Das ist schon arg wenig.

Wenn ich jetzt pro AD-Channel einen 8-bit fifo dazwischen häng, braucht 
der STM32 dem AD nur mehr Takt, Start und Rest senden. Das Auslesen des 
FIFO kann dann ja durchaus noch per DMA oder auch einfachem asynchronen 
polling erfolgen.

Wenn ich das Datenblatt richtig verstehe, dann kann ich über die PLL den 
externen Takt HSE von 8MHz auf 4MHz runter teilen, per PLL auf 40 MHz 
hoch skalieren und an einem GPIO als MCO ausgeben.

Könnte natürlich sein, daß ich zwischen AD und FIFO eine 
Phasenverschiebung brauche, damit die stabil kommunizieren.
Krieg ich das auch noch über den STM hin?
Oder einfach Gatterlaufzeiten eines 74HC?

Klingt das jetzt alles machbar?
Hat das schon mal jemand gemacht?
Wenn ich es nirgends im Detail beschrieben seh' - ist das, weil es nicht 
klappt, oder weil es so straightforward ist, oder es noch einfacher 
geht?

von Wolfgang R. (wjr)


Angehängte Dateien:

Lesenswert?

So sieht der erwartete Stromverlauf im unterresonanten Betrieb aus.
In Resonanz (200 kHz) gibts nur mehr kleine Rippel auf dem Sinus.
Im Überresonanten Betrieb sehen die Rippel anders aus und sind feiner.
Meßtechnisch gesehen ist das also die höhere Anforderung.

In der ST AN4031 bin ich auf folgenden Satz gestoßen

"This example is applicable to products STM32F2, STM32F405/415, 
STM32F407/417,
STM32F427/437 and STM32F429/439 lines.

The ADC is configured in _continuous triple Interleaved mode_
In this mode, it converts continuously one analog input channel __at the 
maximum ADC speed (36 MHz).__
The ADC prescaler is set to 2, the sampling time is set to 1.5 cycles, 
and the delay between two consecutive ADC samples of the Interleaved 
mode is set to 5 cycles."


Diesen continuous triple Interleaved mode  muß ich wohl ergooglen.....
Der Bluepill hat einen STM32F103C8T6 verbaut, fällt also nicht in diese 
Liste.
Andereseits - wenn der Aufbau einfacher wird, kann ich auch ein paar € 
mehr für das Board ausgeben.

von Planloser (Gast)


Lesenswert?

Wolfgang R. schrieb:
> Diesen continuous triple Interleaved mode  muß ich wohl ergooglen.....
> Der Bluepill hat einen STM32F103C8T6 verbaut, fällt also nicht in diese
> Liste.
> Andereseits - wenn der Aufbau einfacher wird, kann ich auch ein paar €
> mehr für das Board ausgeben.

Für 8-9€ bekommst Du schon eines dieser STM32F407-Chinaboards. Die haben 
dann auch schon zusätzlichen Flash-Speicher und SD-Kartenleser mit auf 
dem Board.
Und im Gegensatz zur Bluepill sind die nicht größtenteils mit 
"Fake-"Controllern bestückt.

von Wolfgang R. (wjr)


Lesenswert?

OK, wenn ich das mit dem "interleaved mode" richtig verstanden hab, dann 
werden einfach zwei (oder mehr) ADC parallel um einen halben Zyklus 
versetzt und die Ergebnisse ineineinander reißverschlußmäßig verquickt.

Hier etwas Theorie dazu
https://www.analog.com/en/analog-dialogue/articles/interleaving-adcs.html
https://tutcris.tut.fi/portal/files/7836689/Singh_1398.pdf

Das bringt bei 2 ADC des Bluepill also max 2 MHz.

Vielleicht kann ich noch etwas höher gehen, wenn ich die Auflösung 
zurück fahr?
Limitierend scheint der ADC-Takt vom max 14 MHz zu sein.
Also schätz ich mal je einen Takt für jedes der 12 bit und 2 extra als 
"overhead".

Dann käm ich bei 8 bit auf 10 Takte , 1.4 MHz sampling rate, 2,8 MHz 
dual interleaved?
Hab' aber das Problem von extra Störsignalen durch ADC mismatch.

Vielleicht passt das ja bei einer anderen Anwendung - mir ist es noch zu 
langsam.
Falls jemand den Faden nochmal aufnehmen möchte:

STM32... ref manual  "11.9.3 Fast interleaved mode"

von Hans-Georg L. (h-g-l)


Lesenswert?

Da würde ich eher die 25€ für ein Nucleo Board mit STM32H743Zi ausgeben.

Der hat 3 16bit ADC mit je 3,6 Msps, die sich auch im triple Mode 
betreiben lassen. Dann kommst du auf 10,5 Msps und Ethernet ist auch mit 
auf dem Board .

Siehe:
https://www.st.com/resource/en/application_note/dm00628458-getting-started-with-the-stm32h7-series-mcu-16bit-adc-stmicroelectronics.pdf

von Wolfgang R. (wjr)


Lesenswert?

Danke - klingt auf den ersten Blick gar nicht schlecht.

Hast Du praktsiche Erfahrung mit den "interleaving spurs"? Ein 12-bit AD 
sollte ja gegenüber 8 bit um den Faktor 16 genauer sein - auch relativ 
zueinander. Wenn mir also die 8 bit reichen, sind dann die interleaving 
spurs gar kein Thema?

Und könnte ich die ADC dann auch schneller betreiben, d.h. gleicher 
Takt, weniger Zyklen? Dann wär ich schon bei 15 MHz, also 37 Samples im 
resonanten Halbzyklus.

von Hans-Georg L. (h-g-l)


Lesenswert?

Wolfgang R. schrieb:
> Danke - klingt auf den ersten Blick gar nicht schlecht.
>
> Hast Du praktsiche Erfahrung mit den "interleaving spurs"? Ein 12-bit AD
> sollte ja gegenüber 8 bit um den Faktor 16 genauer sein - auch relativ
> zueinander. Wenn mir also die 8 bit reichen, sind dann die interleaving
> spurs gar kein Thema?
>
> Und könnte ich die ADC dann auch schneller betreiben, d.h. gleicher
> Takt, weniger Zyklen? Dann wär ich schon bei 15 MHz, also 37 Samples im
> resonanten Halbzyklus.

Ich habe so ein Board für andere Zwecke und den ADC noch nicht benutzt. 
Sehe gerade die max Sample Rate gilt auch nur für das BGA Gehäuse, 
verbaut ist aber ein TQFP.

von Andreas Rückert (Gast)


Lesenswert?

Wolfgang R. schrieb:
> Das bringt bei 2 ADC des Bluepill also max 2 MHz.
>
> Vielleicht kann ich noch etwas höher gehen, wenn ich die Auflösung
> zurück fahr?
> Limitierend scheint der ADC-Takt vom max 14 MHz zu sein.
> Also schätz ich mal je einen Takt für jedes der 12 bit und 2 extra als
> "overhead".

Es gab mal einen Artikel, wo gezeigt wurde, wie weit man den ADC des 
stm32 übertakten kann, und da wurde viel mehr rausgeholt.

Hast Du mal diesen Mega-Thread '10$ Scope revisited' gelesen? Da wurden 
doch etlich Varianten diskutiert.

von Wolfgang R. (wjr)


Lesenswert?

Danke für den Tip. Nachdem sich Google sträubt, und ich trotz 
aussagefähiger Begriffe eine viertel Stunde gebraucht hab, hier für die 
Nachwelt ein Link:

https://sparklogic.ru/projects/10-o-scope-revisited.html

"$10 O-Scope revisited"
isses das?

von Wolfgang R. (wjr)


Lesenswert?

OK, so weit man das beim Querlesen beurteilen kann, haben sich die da 
richtig rein gestresst. Wenns richtig an's bauen geht, werd' ich da 
vielleicht noch mal den einen oder anderen Tip suchen, grad was timer 
und dma angeht.

Die haben mit interleaving aus dem Blupill 2 Msamples rausgeholt, 
allerding mit deutlichen interleaving spurs.

Das hilft mir wenig, denn genau in diesem Frequenzbereich vermute ich 
die parastären Schwingungen, wenn das Timing meiner Brücke nicht stimmt.

Die glatten Rechtecke schienen alle von deutlich langsameren Messungen 
zu sein - oder von der Ausmittelung benachbarter Punkte. Was aber dann 
die Bandbreite wieder halbiert, wegen der man ja vorher das Interleaving 
gemacht hat...

Entweder ich hab's überlesen, oder die Überlegung, einen externen 
schnelleren ADC zu verwenden, kommt in dem Thread nicht vor.

Aber vllt geh ich mit meiner Überlegung ja in den thread..?

von oerks (Gast)


Lesenswert?

Wenn man schnelle ADs ohne Gehampel braucht, und nicht gleich
einen 2 Kerner von NXP verbauen will, gibt es von TI seit einigen
Jahren schon den TMS320F2809.
Dessen ADC ist mit 12.5 MSPS spezifiziert, und der Rest vom
Controller kann mit den Daten auch noch umgehen.

Ist fuer dich vielleicht eine Herausforderung, weil man dafuer
eben keine Billigteile vom Chinamann bekommt.

von Jonas B. (jibi)


Lesenswert?

>TMS320F2809

Gibt's dafür den mittlerweile einen freien Compiler, das ist doch ein 
DSP, wenn ich mich recht erinnere?

von oerks (Gast)


Lesenswert?

> einen freien Compiler

Ob der nun ganz frei ist, weiss ich nicht.

Wenn es etwas aelter sein darf: C2000 Code Composer Studio v3.3.
Das letzte Release (CC338319) findet man TI.
Das hat die "Unart" seine Konfiguation in seinem eigenen
Installationsverzeichnis speichern zu wollen, und laeuft damit
nur als Admin. Dann aber auch unter Win10 ohne Probleme.
Oder als normaler Benutzer, der kann die Konfiguration dann
wenigstens nicht versaubeuteln.

Aber man kann auch problemlos eine der neueren Versionen nehmen.
Die sind dann Eclipse-basiert. Ob man fuer die eine Lizenz braucht,
verraet die TI-Webseite.
Bislang war TI fuer den privaten Gebrauch immer sehr kulant bei
der Vergabe von Lizenzen.

Das man "keine" Lizenz zur Nutzung braucht, ist den politisch
Engstirnigen ja aber oft nicht "frei" genug...

von Wolfgang R. (wjr)


Lesenswert?

Eigentlich spring ich ja nur ungern über dieses Stöckchen, weil der 
Thread sonst rettungslos abdriftet. Aber ich hab' ja mit einer Schaltung 
der Texaner begonnen.
Diese App-Note besteht zu einem Viertel aus Abriss des Brückenverhaltens 
(gut und knackig) und zu zwei Drittel aus "klicke hier ... trage 'foo' 
ins Menü 'bar' " der DSP-Entwicklungsumgebung ein.

Die ganze App-Note besteht nur aus Sirenengesängen für TI DSP.
Weil die ihren DSP verkaufen wollen. Dürfen sie ja. Darf ich aber auch 
nicht kaufen wollen. Weil ich nicht mag. Das ist ein Hobby-Projekt. Da 
ist bereits die Entscheidung, es anzugehen, rational nicht zu begründen.

Aber ich glaub, ich versteh' jetzt, wie das in der App Note eigentlich 
läuft. Ich hab' immer nach dem Oszi gesucht, aber nicht gefunden. 
Offensichtlich läuft das wirklich so, daß der DSP sowohl die Regelung 
als auch die Datenerfassung macht und man das über die 
Entwicklungsumgebung dann auslesen kann? Schon geil, irgendwie. 
Virtuelles Oszi, quasi?

Aber es scheint mir wie eine Black Box: wenn die Hex-Hex-Kiste nicht 
mehr tut was ich will? Beim rumgoogeln bin ich immer wieder auf 
kafkaeske Support-Anfragen bei TI gestoßen: Die stehen vor der großen 
Burg und finden nicht mal das Tor.

Beim STM32 bin ich jetzt so weit, daß ich mit ein paar halbseidenen 
Forumseinträgen mir den richtigen Suchbegriff zusammen klaube, um mich 
durch 1134 Seiten Datasheet zu greppen. Und denke, es zu verstehen.

Ich will den zu meiner eierlegenden IoT Wollmilchsau machen, nachdem ich 
mit dem ESP8266 ungewollt in der WLAN-Ecke stecken geblieben bin. Und 
diese Entcheidung nicht revidieren, weil ein einzlenes Problem knackig 
wird.

Was meinen Brückencontroller angeht: Ich bin da etwas altmodisch und 
hätte gerne für die Regelung und für die Überwachung jeweils ein 
eigenenes "Kästchen", also getrennter redundante Systeme. Also auch 
extra Oszi.

von Wolfgang R. (wjr)


Angehängte Dateien:

Lesenswert?

Zurück zum Eingemachten.

Nach den Datenblättern sollten sich die Komponenten µC, FIFO und ADC 
recht gut vertragen. Läuft alles unter 3,3 V. Ich denke, die Busse kann 
man direkt verbinden.

Der FIFO verfügt über einen Tri-State-Ausgang. Das würde auch einfaches 
Multiplexing ohne extra Komponenten erlauben. Kanäle bis zum 
Abwinken.... ;-)

Ich könnte auch überlegen, beide Kanäle mit jeweils 8 bit Breite separat 
einzulesen.


Der FIFO verlangt, daß sowohl eingangs- als auch ausgansseitig permanent 
ein clock-Signal zwischen 1 und 50 MHz anliegt. Das könnte asynchrones 
Pollen der Daten zum Glücksspiel werden lassen. Das einfachste wird wohl 
sein, die Daten im Burst in einem Zug über DMA abzurufen (zumimdest so 
weit der Speicher des µC reicht). Dazu würde ich den Out-Clock des FIFO 
mit einem Timer auf 1 MHz laufen lassen und mit dem selben Timer dann 
die DMA passend getimed triggern.

Ggf könnte man da auch schneller gehen, aber die Daten müssen ja dann 
auch noch übers Netz verschickt werden.

Vom GPIO-A-Bus sind 2 Pins für die Bootloader-Schnittstelle belegt, vom 
B-Bus einer für "boot2". Ich denke, das sollte im Betrieb kein Problem 
sein. Also hab' ich noch freie Auswahl, auch wenn ich mit 16 bit Breite 
aus 2 FIFO parallel lesen will.

Die Steuersignale von AD und FIFO sind überschaubar. Ich denke, es 
sollten noch genug GPIO übrig sein, um die direkt zu bedienen. Das 
exakte Timing des Aufzeichnungsstartes könnte knifflig werden, aber ich 
denke, das kann man getrost ignorieren und den Beginn der validen Daten 
später bei der Auswertung fest legen.

Einzig die synchrone Taktung von AD und FIFO-in erscheint etwas 
anspruchsvoller.
Ich krieg wohl 40 MHz aus dem STM32 raus, aber nicht zwei in definierter 
Phasenlage mit ns-genauem Versatz. So was werd' ich aber wohl nach den 
Timing-Diagrammen brauchen:
- der AD löscht die "alten" Daten ca 2 ns nach clock rise und stellt 6 
ns nach clock rise die neune Daten bereit (rote Kurve, high="data 
valid").
- der FIFO lädt Daten bei clock rise , die dazu 6 ns vorher schon 
anstehen müssen und noch 2 ns gehalten. (blaue Kurve)
- wenn ich dem AD ein gegenüber dem FIFO um ca 7 ns verzögertes 
clock-Signal gebe, liegt das Lesefenster des FIFO ziemlich mittig im 
data-valid-Fenster des AD
- Die 74HC-Serie wird bei 3,3 V schon recht langsam. 10 ns delay sind 
bei 25 ns Zyklus ein no-go. Die Simulation zeigt nur mehr Dreiecks- 
statt Rechtecksignale.
- Ich denke, die Serie LVC ist hier angesagt. Die Schmitt-Trigger sind 
mit 2,1 ns bei 3,3 V ausgewiesen. Die angegebene Verzögerung mit 
RC-Glied hat in der LTspice-Simulation die gezeichneten Kurvenverläufe 
produziert.
- ... wenn ich mich denn auf die Modelle verlassen kann... Der Eingang 
des Schmitt-Triggers ist mit 2 pF im Datenblatt angegeben, aber beim 
Variieren des RC-Gliedes scheinen mir im Modell eher 5 pF hinterlegt.
- letztlich werd ich das wohl irgendwie messen müssen. Ich denke, die 
Schaltung kann man auch zum Frequenzgenerator rückkoppeln. Ich hab mir 
ein paar Gatter, Flip-Flops. Zähler etc für die Bastelkiste bestellt und 
hoffe, daß ich dann mit meinem Logic-Analyser auf die Frequenz und damit 
auf die Verzögerungsdauer rückschließen kann.

Der Analogteil des DSO203 scheint wegen der weiten Meßbereichsauswahl 
viel komplizierter als ich brauche. Ich denke, für Inline-Diagnose kann 
ich im Wesentlichen auf vorberechnete Gains zurückgreifen.

von oerks (Gast)


Lesenswert?

> zu zwei Drittel aus "klicke hier ... trage 'foo'
> ins Menü 'bar' " der DSP-Entwicklungsumgebung ein

Damit ist wohl die Konfiguration des RT-BIOS gemeint.
Das liegt leider nicht als Quelle vor, und die Konfiguration
ist, wenn man es benutzt, schon etwas umfaenglich.

> Darf ich aber auch nicht kaufen wollen.

Meine TMS320Fwxyz die ich hier hobbymaessig verbaue, sind ueberwiegend
Samples von TI. Aber so exklusiv sind die Preise auch nicht, als das
man sie nicht kaufen koennte.

> Offensichtlich läuft das wirklich so, daß der DSP sowohl die Regelung
> als auch die Datenerfassung macht und man das über die
> Entwicklungsumgebung dann auslesen kann?

Richtig. Es gibt neben der JTAG-Verbindung noch eine RTDX-Verbindung.
Und das RT-Betriebssystem DSP-BIOS hat dann noch eine RTA-Verbindung.
Da ein TMS320F2809 es auf insgesamt 16 AD Channels bringt, kann
man neben den eigentlichen Regelgroessen damit auch noch andere
Teile der Schaltung monitoren (wenn man will).
Und man sieht natuerlich genau die Signale die der Regelalgorithmus
verarbeitet/verarbeiten soll. Ein Oszi waere da nur zweite Wahl.
All das funktioniert parallel zu einem in Echtzeit laufenden Regler.

Wenn man das benutzen will, braucht man zwingend allerdings einen
"richtigen" Emulationsadapter (z.B. XDS-560). Die kleinen
XDS-100 FTDI-Adapter koennen das nicht.
Hat man den nicht, kann man aber immer noch z.B. mit einem
Cypress FX2LP die (AD-)Oszidaten per USB ausleiten.
So koennte die Messschnittstelle immer noch in der selben
"Schachtel" wie der Rest sein zu Hause finden. Der Mehraufwand
in Hard- und Software haelt sich da in engen Grenzen.

Ich bin allerdings auch jahrelang ohne diese zusaetzlichen
Moeglichkeiten ausgekommen, und erst vor kurzer Zeit an einen
gebrauchten BH-560m gekommen.


Trotzdem viel Erfolg bei deinem Vorhaben!

von Wolfgang R. (wjr)


Lesenswert?

Ja, das mit den TI-DSP hört sich alles durchaus interessant an.
Vielleicht überschätze ich da auch manche Hürde, wie etwa die Frage, wie 
ich so ein Teil auf eine grobmotorikfähige Platine kriege.

Mein limiterender Faktor ist halt die Zeit, in mehrere Plattformen 
einzusteigen.
Ich hab bestimmt ein Dutzend Anwendugnen im Kopf, wo ich 
netzwerkgebundene µC verbauen möchte. Die sind alle wesentlich einfacher 
gestrickt. Da ist ein STM32 meist overkill, aber was solls. Ich würd 
halt gern die noch aufzubauende Erfahrung recyclen können.

Mit einem 40 MHz Oszi kommt ein STM 32 vielleicht auch an seine Grenzen. 
Wenn ich das nicht im DSO gefunden hätte, wär ich auch gar nicht drauf 
gekommen.

von oerks (Gast)


Lesenswert?

> wie ich so ein Teil auf eine grobmotorikfähige Platine kriege.

Die gibt es auch in QFN. Mein "erster" TMS320C5502 (300 MHz)
sitzt auf einem QFN-Adapter. Das ist mittlerweile elf Jahre her.
Der Debugadapter war "Made by Olimex" eigentlich ein MSP430-JTAG
mit einer angepassten DLL fuer den Code Composter V3.3.

Zum "Reinschnuppern" gibt es relativ guenstige Startangebote
fuer die Piccolo-Serie von Controllern.
Das ist quasi der kleinere Ableger der TMS320F28er Serie.
Da muss man dann also selber erstmal gar nichts bauen.
Manche, z.B. das 28027-Launchpad haben sogar den Luxus eines
isolierenden JTAG-Adapters (allerdings ohne RTDX).
Was davon aktuell noch verfuegbar ist, weiss ich allerdings nicht.

Mein erster TI DSP mit dem ich experimentiert habe, war
uebrigens ein TMS320C15 im 40 pol. DIL-Gehaeuse.
(Noch laenger her.)

> wo ich netzwerkgebundene µC verbauen möchte

Da kommen/kamen bei mir STM32F107VC, LPC1768, LM3S9B96
und TM4C1294 zum Einsatz. Die beiden letzteren haben die PHY
schon integriert, was den Aufbau vereinfacht.


Wenn dir vor dem Loeten bange ist, dann waere wohl ein
Nucleoboard mit Ethernet und einigermassen schnellen AD-Wandlern
die erste Wahl. Man muss sich nur im klaren sein, dass
ein M7-ARM auch sehr komplex ist, und eben trotzdem nicht
die beste Loesung was Peripherie und Entwicklung angeht, ist.
In der Industrie die ich so kenne (Entwicklung und Fertigung
medizinischer Geraete) kommen immer noch TI-Controller ergaenzt
um FPGAs zum Einsatz.

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
Noch kein Account? Hier anmelden.