Datenerfassung, Analog -> USB / RS232

[Reginald L. (Firma: HEGRO GmbH) (reggie)]

Hallo liebe Gemeinde!


Zuersteinmal möchte ich mich für die Kleinschreibung entschuldigen, bei 
etwas längeren Texten in Foren geht mir das flüssiger von der Hand, 
bitte habt Verständnis. Habt auch bitte Verständnis dafür, dass ich mich 
u.U. nicht präzise ausdrücken kann, da ich nicht aus dem Elektroniker- 
sondern aus dem Mechanikerbereich komme. Habe das Internet schon nach 
meiner Fragestellung durchsucht, Teilaspekte wurden mir für mein Projekt 
klarer. allerdings möchte ich hier nochmal anfragen, wozu hat man denn 
ein Forum :)

Ich habe eine Wuchtmaschine für mittelgroße Rotoren entwickelt und 
gebaut. Der Antrieb hängt an einem Frequenzumrichter der per RS232 mit 
eigens programmierter Bibliothek angesprochen wird. Für die 
Datenerfassung habe ich zwei Beschleunigungsaufnehmer und eine 
IR-Reflexlichtschranke, deren Daten (mager aufbereitet) mit einem 
programmierbaren Oszilloskop in meine Programmierumgebung (MatLab) 
eingeworfen werden. Dort habe ich ein GUI programmiert, das den Antrieb 
steuert und mir alle wichtigen Daten zur Unwucht mitteilt. Soviel zur 
Vorgeschichte. Es geht nun um Folgendes:

Ich möchte den Umweg über das Oszilloskop nicht nutzen, sondern eine 
eigene Schaltung für die Datenerfassung entwerfen, die direkt an der 
Maschine sitzt und die Daten, bei Anfrage, an den PC sendet. Ich weiss 
zwar, dass es dafür spezielle DAQ-Karten oder Messlabore gibt, aber 
entweder sind sie zu teuer, haben viel zu viele Kanäle, sind nicht 
programmierbar oder erfüllen andere, grundlegende Anforderungen nicht. 
Falls es da doch etwas Fertiges und Bezahlbares gibt, würde ich mich 
eher dafür entscheiden, gefunden habe ich allerdings nichts. Folgende 
Eckdaten:

- Min 3 analoge Eingänge, 100kS/s / Kanal, min 12bit besser mehr, 
synchrone Datenerfassung
- Zwischenspeicher, darf auch möglichst groß sein, jedoch mindestens 
ausreichend für 100kS/s / Kanal bei 12bit, ich komme da auf 450KB, 
stimmt das?
- RS232 / USB Ausgang, es darf ruhig länger dauern bis die Daten 
vollständig am PC angekommen sind, "Echtzeit" ist nicht gefordert
- Programmierbarkeit über MatLab muss gegeben sein

Wie ich bereits erwähnte, habe ich im Internet nach Infos gesucht, wie 
ich so etwas bauen kann, bitte prüft ob das so der richtige Ansatz wäre:

1. Aufbereitung der Signale mit OPVs / Filtern (habe ich schon erledigt) 
->
2. ADC's -> SPI-Schnittstelle (oder besser eine andere?) ->
3. Mikrocontroller (der programmiert werden muss, nehme ich an) ->
4. Hier bin ich mir jetzt nicht sicher, die Daten sollen auf jeden Fall 
in einem Speicher zwischengespeichert werden. ich habe von FIFOs und 
Flash-Speichern gelesen, aber stehe hier vollkommen auf dem Schlauch. 
Ist der im Mikrocontroller integriert oder nicht? Was wäre hier für 
meine Zwecke von Vorteil? ->
5. USB / RS232 Schnittstelle, ich vermute über RS232 wäre es für mich 
einfacher die Daten aus dem Speicher anzufordern (programmiertechnisch)? 
Bei USB benötige ich wohl spezielle Treiber für meine 
Programmierumgebung? Wie gesagt, "Echtzeit" ist nicht der Knackpunkt. 
Wenn es eine Minute dauert damit die Daten am pc sind, ist das kein 
Problem.

Ich habe auch gesehen, dass es schon fertige IC's gibt, die das alles 
(oder fast alles) schon in einem Gehäuse beinhalten. Würdet ihr mir eher 
zu so etwas raten? Meine oben genannten Kriterien müssen natürlich auch 
erfüllt werden.


Hier soll natürlich keiner eine Schaltung für mich entwerfen. Ich bitte 
nur um Hilfestellung, damit ich in das Thema schneller und besser 
reinkomme.


Vielen Dank für eure Hilfe :)

Liebe Grüße
reggie


Edit: Für Klaus und alle anderen die sich daran stören, Klein- und 
Großschreibung beachtet ;)

[Michael K. (Gast)]

Ob USB oder RS232 ist für Dich nicht von Belang wenn Du einen USB / 
Seriell Wandler einsetzt der sich im System als Virtual Com Port (VCP) 
anmeldet und genau wie ein normaler Com Port zu benutzen ist.

Der Rest der Anforderungen hört sich nach einem 'normalen' 
Mikrocontroller mit entsprechender Programmierung an.
Ob die Beschleunigungssensoren unbedingt Analog ausgelesen werden müssen 
oder gleich digital auszulesen sind liegt an Dir.

Deine 'durch Matlab programmierbar' Anforderung ist ja ziemlich 
schwammig formuliert. Jeder Mikrocontroller kann das was Du ihm 
beibringst, also sollte auch das kein Problem sein.

Bei drei mal 12bit ( als 16bit übertragen) und 100Ksamples hast Du 
gerade mal 600KByte/s.
Für USB eigentlich kein Problem aber für VCP Übertragungen schon.
siehe: Beitrag "FTDI USB 2.0 Chips Virtual COM Port Geschwindigkeit?"

Überleg Dir ob Du unbearbeitete Daten übertragen willst, dafür aber 
speichern musst oder ob Du gleich sinnvoll komprimierts und alles in 
Echtzeit wegschaufelst.

[Reginald L. (Firma: HEGRO GmbH) (reggie)]

Die Wandler kenne ich, allerdings macht es ja wenig Sinn, von RS232 nach 
USB und wieder zu RS232 zu wandeln. Ich dachte entweder direkt mit USB 
an den PC oder eben direkt über RS232. Nun habe ich aber noch nie über 
USB etwas eigens programmiert. Das Oszi bietet da ja eine Bibliothek die 
ich abrufe, aber wie genau das Protokoll arbeitet weiss ich eben nicht. 
Um USB über MatLab ansprechen zu können, brauche ich aber die 
entsprechenden Treiber. Wenn ich nun eine Kommunikation über USB 
realisieren möchte, muss ich darauf achten ob der Chiphersteller da 
Treiber für MatLab zur Verfügung stellt? Andererseits macht es keinen 
Sinn bei den Datenmengen, oder (siehe weiter unten)? Würde RS232 ja 
ausreichen.

Die Sensoren liefern analoge Signale, das ist vorgegeben, diese müssen 
also gewandelt werden. Muss natürlich nicht im IC geschehen, kann da 
auch Wandler zwischenschalten. Frage ist nur, was eurer Meinung nach 
sinnvoller für mich wäre.

Mit "durch Matlab programmierbar" meinte ich, dass ich den Controller 
über die RS232 Schnittstelle, mit MatLab, programmieren möchte. MatLab 
kann den Code auch in C umwandeln, um ihn dann über die Serielle 
Schnittstelle zu schicken. Oder ist es nötig, den Chip mit einem Brenner 
zu beschreiben? Praktischer wäre es für mich ihn direkt, in eingebautem 
Zustand über RS232 zu programmieren.

Wie gesagt, Echtzeit benötige ich nicht. Die Daten sollen im Speicher 
auf der Platine bleiben, mit einem Befehl möchte ich dann die Daten auf 
den PC übertragen. Ob das dann 10sek dauert ist für mich nicht von 
Belang. Müsste doch praktisch möglich sein, die Vorgehensweise?

Ich möchte unbearbeitete Daten in den PC schaufeln. Echtzeit ist, wie 
gesagt, nicht von Nöten. Um das näher zu erläutern: Beim Triggern der 
Lichtschranke soll die Datenaufzeichnung (je nach Frequenz des Rotors 
mit verschiedenen Sample-Intervallen) erfolgen. Dies soll so lange 
geschehen bis der Speicher voll ist. Die Daten aus dem Speicher sollen 
nun an den PC übermittelt werden. Je nachdem welche Datenmenge ich nun 
am PC benötige um einen Mittelwert zu bilden, soll sich der ganze 
Vorgang x-mal wiederholen. Ob das alles nun 1s oder 1min dauert, ist mir 
ziemlich latte, der Rotor kann sich auch y-mal weitergedreht haben, 
bevor eine neue Aufzeichnung beginnt :)

[Thomas F. (igel)]

Reginald L. schrieb:
> Nun habe ich aber noch nie über
> USB etwas eigens programmiert. Das Oszi bietet da ja eine Bibliothek die
> ich abrufe, aber wie genau das Protokoll arbeitet weiss ich eben nicht.

Es ist dein Aufgabe hier ein Übertragungsprotokoll zu entwickeln.

> Um USB über MatLab ansprechen zu können, brauche ich aber die
> entsprechenden Treiber. Wenn ich nun eine Kommunikation über USB
> realisieren möchte, muss ich darauf achten ob der Chiphersteller da
> Treiber für MatLab zur Verfügung stellt?

Die übliche Verdächtigen FT232 oder CH340 haben treiber dabei, die dir 
im Windows dann einen neuen, virtuellen COM-Port anbieten. Diesen 
sprichst du aus deiner Software wie einen normalen COM-Port an. Mit 
Matlab hat das erst mal wenig zu tun.


> Mit "durch Matlab programmierbar" meinte ich, dass ich den Controller
> über die RS232 Schnittstelle, mit MatLab, programmieren möchte. MatLab
> kann den Code auch in C umwandeln, um ihn dann über die Serielle
> Schnittstelle zu schicken.

Hab noch nicht mit Matlab programmiert. Aber ich denke du bist dann auf 
Controller beschränkt die von Matlab unterstützt werden.

Alternativ die Controller mit Entwicklungsumgebung programmieren: Keil, 
Atollic, Coocox.....

> Oder ist es nötig, den Chip mit einem Brenner
> zu beschreiben? Praktischer wäre es für mich ihn direkt, in eingebautem
> Zustand über RS232 zu programmieren.

Brenner benutzt man hier nicht mehr. Die Controller werden üblicherweise 
immer eingebaut programmiert, entweder über USB oder eigene 
Programmierschnittstellen.
https://www.mikrocontroller.net/articles/ISP


Um einfach mal etwas Hardware in den Raum zu werfen:

https://www.mikrocontroller.net/articles/STM32F4-Discovery
Beitrag "STM32 boards unterstuetzen Arduino und mbed"

[Reginald L. (Firma: HEGRO GmbH) (reggie)]

Aaaaaah OK, dh. falls ich mich für USB entscheide: Übertragungsrate 
zwischen FT232 Chip und PC ist höher, ich greife von MatLab auf diesen 
über einen virtuellen COM Port zu, der von MatLab als normaler COM-Port 
erkannt wird. Der Chip übersetzt die seriellen Daten vom Mikrocontroller 
zu USB für den PC. Da ich aber keine hohen Übertragungsgeschwindigkeiten 
benötige, könnte ich über RS232, dann mit geringerer Übertragungsrate, 
direkt an einen Mikrocontroller ran, falls dieser eine RS232 
Schnittstelle besitzt. Falls der Mikrocontroller nur eine 
SPI-Schnittstelle besitzt, bräuchte ich also einen SPI-RS232-Umsetzer.

Das Übertragungsprotokoll muss ich selber entwickeln, OK. Man wächst ja 
an seinen Aufgaben :) Dh. bevor ich überhaupt die o.g. Schnittstelle 
benutzen kann, muss ich anderweitig auf den Chip zugreifen um das 
Protokoll einzuprogrammieren. Ich nehme an das geht dann, wie du 
beschreibst, je nach Chip mit den Programmen der Hersteller? Gewohnt 
über RS232?

Mit MatLab ist es möglich Controller die in C programmiert werden, auch 
zu programmieren, da MatLab einen C-Umsetzer hat. Meine Frage 
beschränkte sich eher darauf, wie das dann programmiert wird. RS232 
einstöpseln, Programm schreiben (mithilfe der Funktionsliste des 
Chip-PDFs?) und senden?

Was haltet ihr von einer "Fertiglösung" ala Komplett-IC? Habe gesehen es 
gibt da welche die integrierte ADCs, Speicher und RS232 Schnittstellen 
haben. Wäre das für einen Anfänger besser geeignet? Gibt es da auch die 
Möglichkeit einen externen Speicher anzubinden? Die ICs die ich gesehen 
habe, kommen da mit weniger Speicher anher.


Vielen Dank erstmal für die zahlreichen Infos von allen!

EDIT: Vllt etwas Missverständlich ausgedrückt: Mit der "Fertiglösung" 
meinte ich natürlich, dass die Bauteile alle in einem Gehäuse sitzen. 
Dass ich da das Protokoll und das Programm dafür schreiben muss ist mir 
klar. Wie gesagt, man wächst an seinen Aufgaben und Spaß macht es 
allemal ;)

[Thomas F. (igel)]

Reginald L. schrieb:
> Falls der Mikrocontroller nur eine
> SPI-Schnittstelle besitzt, bräuchte ich also einen SPI-RS232-Umsetzer.

Ic kenne jetzt keinen Mikrocontroller ohne RS232-Schnittstelle. Viele 
haben auch schon USB On-Board.

> Dh. bevor ich überhaupt die o.g. Schnittstelle
> benutzen kann, muss ich anderweitig auf den Chip zugreifen um das
> Protokoll einzuprogrammieren.

Du wirst erst mal ein Programm flashen müssen. Die beiden Beispiele von 
mir haben schon einen USB-Bootloader drauf, d.h. das programmieren 
erfolgt schon über USB.

> Mit MatLab ist es möglich Controller die in C programmiert werden, auch
> zu programmieren,

Kenne mich damit nicht aus.

> Was haltet ihr von einer "Fertiglösung" ala Komplett-IC?

Meinst du fertige Platinen, wie die beiden vorgeschlagenen?

> Habe gesehen es
> gibt da welche die integrierte ADCs, Speicher und RS232 Schnittstellen
> haben. Wäre das für einen Anfänger besser geeignet?

Die haben all das mit dabei. Und du musst keine Platine herstellen, 
löten, ...

> Gibt es da auch die Möglichkeit einen externen Speicher anzubinden?

Ja.

> EDIT: Vllt etwas Missverständlich ausgedrückt: Mit der "Fertiglösung"
> meinte ich natürlich, dass die Bauteile alle in einem Gehäuse sitzen.

Als Anfänger möchtest du wohl keinen ARM-Controller im 144-Pin Gehäuse 
von Hand auflöten. Daher mein Vorschlag mit den fertigen Boards.

[Reginald L. (Firma: HEGRO GmbH) (reggie)]

Thomas F. schrieb:
> Meinst du fertige Platinen, wie die beiden vorgeschlagenen?

Nee, ich meinte einen fertigen Chip in einem Gehäuse. Mit Prozessor, 
Speicher, ADCs und RS232. Dh. mein Daten rein, über RS232 an PC raus.

Thomas F. schrieb:
> Die haben all das mit dabei. Und du musst keine Platine herstellen,
> löten, ...

Mit einer komplett fertigen Platine wäre ich natürlich auch 
einverstanden. Allerdings sind das dann eben Messlabore bzw. Messkarten. 
Der STM32F4 hat ja noch Mikrofone, Mems, LEDs, etc. pp. Dann kann ich ja 
gleich mein Oszi an die Maschine heften ;). Ich möchte schon eine 
diskrete Schaltung. Analoge Signale rein und per RS232 raus. Von ADCs 
habe ich bei dem von dir geposteten Board nichts gelesen? Das Teil 
erscheint mir auch viel zu Umfangreich als für meine Zwecke notwendig?

Thomas F. schrieb:
> Als Anfänger möchtest du wohl keinen ARM-Controller im 144-Pin Gehäuse
> von Hand auflöten. Daher mein Vorschlag mit den fertigen Boards.

Mit löten habe ich kein Problem, zumindest nicht in DIP. Wenns die 
benötigten Teile nur ne Nummer kleiner gibt, werde ich das auch 
hinbekommen. Mit Anfänger meine ich nicht blutiger Anfänger ;) Habe nur 
noch nie mit Mikrocontrollern zu tun gehabt die ich programmieren muss.

[Reginald L. (Firma: HEGRO GmbH) (reggie)]

Habe die halbe Nacht durchgemacht und bin immer noch nicht auf einen 
grünen Zweig gekommen. Gibt es jemanden der aus der nähe Ulm kommt, sich 
mit diesem Thema auskennt und mir etwas von seiner kostbaren Zeit 
schenkt, um mir in der Theorie, vllt auch bei nem Bier, aushilft? Ich 
habe soviele Fragen :>

[m.n. (Gast)]

Da die Datenübertragung nicht zeitkritisch ist und auch per 
RS232/USB-Wandler erledigt werden kann, kann man diesen Punkt abhaken.

Definiere die Aufgaben, die das Erfassung-Interface zu erledigen hat. 
Damit kann es ein festes Programm bekommen, das man über Befehle steuern 
kann. Minimal müßten folgende Funktionen vorhanden sein: Start, Stopp, 
Statusabfrage, Meßwertabfrage (mit start-stopp oder als Paket mit fester 
Länge). Das reicht aus, um die Rohdaten zu erfassen und extern 
weiterzuverarbeiten.

Du schreibt mindestens drei Kanäle mit mindestens 12 Bit Auflösung 
(Genauigkeit?) und Pufferung eines kompletten Datensatzes. Hier klingeln 
die Ohren der STM32-Nutzer, da der STM32F4xx bis zu drei ADC-Kanäle mit 
12 Bit auf dem Chip hat. Allerdings reicht sein internes RAM wohl nicht 
aus. Wenn mehr als drei Kanäle gewünscht werden, geht er auch in diesem 
Punkt in die Knie.
Was der STM32 (und auch µCs z.B. von Renasas RX6xx) bieten, ist hohe 
Verarbeitungsgeschwindigkeit.

Mein Vorschlag wäre ein 32 Bit µC, ein externes RAM und externe 16 Bit 
ADCs (z.B. LTC1864). Wenn man die max. Anzahl der ADC-Kanäle auf acht 
begrenzt, würde ich die seriellen Daten aller ADCs parallel an einem 8 
Bit Port einlesen, wobei die Signale 'CONV' und 'SCK' synchron für alle 
ADCs erzeugt werden. Daß die Daten im Speicher anders als gewohnt 
angeordnet sind, stört nicht, da der schnelle µC sie in ein beliebiges 
Ausgangsformat bringen kann.

Realisierung:
Die ADCs nebst Signalaufbereitung müssen auf jeden Fall eine Platine 
bekommen, sodaß Lötarbeit notwendig ist. Von Bausteinen im DIL-Gehäuse 
muß man sich zwangsläufig verabschieden. Ferner ist ein ext. RAM 
notwendig, was ruhig statisch arbeiten kann und damit einfach 
anzusteuern ist.
Zu überlegen wäre, ein Entwicklungsboard zu verwenden, welches schon das 
ext. RAM enthält und dann nur noch huckepack die ADCs und ggf. den 
RS232-Wandler aufzustecken. Die zusätzlichen ICs auf dem Board werden 
entweder entfernt, falls sie wichtige I/O-Leitungen blockieren, oder 
einfach ignoriert.

So bekommt man eine überschaubare Lösung. Ob Du das jetzt alleine 
umsetzen kannst, glaube ich weniger, aber es kann für Dich ein Ansatz 
sein.

Deine Groß-/Kleinschreibung hat es mir ermöglicht, Deinen Text zu lesen 
und zu antworten. Das solltest Du auf jeden Fall beibehalten.

[Reginald L. (Firma: HEGRO GmbH) (reggie)]

m.n. schrieb:
> Mein Vorschlag wäre ein 32 Bit µC, ein externes RAM und externe 16 Bit
> ADCs (z.B. LTC1864). Wenn man die max. Anzahl der ADC-Kanäle auf acht
> begrenzt, würde ich die seriellen Daten aller ADCs parallel an einem 8
> Bit Port einlesen, wobei die Signale 'CONV' und 'SCK' synchron für alle
> ADCs erzeugt werden. Daß die Daten im Speicher anders als gewohnt
> angeordnet sind, stört nicht, da der schnelle µC sie in ein beliebiges
> Ausgangsformat bringen kann.

Ist es so realisierbar, dass die Daten synchron erfasst und in den 
Speicher geschrieben werden? Ich habe schon an je einen kleinen 
Mikrocontroller pro Eingang gedacht, die die Daten erstmal synchron in 
den Speicher schieben. Von dort aus über den Hauptcontroller dann an 
RS232.

m.n. schrieb:
> Zu überlegen wäre, ein Entwicklungsboard zu verwenden, welches schon das
> ext. RAM enthält und dann nur noch huckepack die ADCs und ggf. den
> RS232-Wandler aufzustecken. Die zusätzlichen ICs auf dem Board werden
> entweder entfernt, falls sie wichtige I/O-Leitungen blockieren, oder
> einfach ignoriert.

Ich habe heute Nacht schon gegoogelt, genauer gesagt erstmal nach den 
Mikrocontrollern. Wäre hier der erste Schritt zu machen? Es gibt auch 
Entwicklungsboards die eigentlich nur das Nötigste beinhalten, was ich 
nicht gewusst habe. Ist der Sinn dahinter nur jener, dass man die 
Lötfummelei nicht hat?

m.n. schrieb:
> So bekommt man eine überschaubare Lösung. Ob Du das jetzt alleine
> umsetzen kannst, glaube ich weniger, aber es kann für Dich ein Ansatz
> sein.

Hast du nen Tipp für gute Literatur oder Internetseiten für Anfänger im 
Bereich Mikrocontroller das mir bei meiner Aufgabe helfen kann? Bis vor 
nem Jahr wusste ich noch nichts vom Programmieren. Heute habe ich hier 
eine Datenerfassungssoftware mit Frequenzumrichteransteuerung vor mir 
liegen. Ich traue mir das schon zu, allerdings ist der erste Einstieg 
immer das schwierigste, weshalb ich hier auf Hilfe hoffe. Mir schwirren 
tausend Fragen im Kopf rum und ich weiss auch nicht so richtig wo ich 
Anfangen soll. Ich will ja weniger probieren als schon systematisch 
Bauteile besorgen und wenigstens ein bisschen wissen was ich da 
fabriziere :)

[m.n. (Gast)]

Reginald L. schrieb:
> Ist es so realisierbar, dass die Daten synchron erfasst und in den
> Speicher geschrieben werden?

Auf jeden Fall, da alle ADCs wie einer angesprochen werden und nur die 
seriellen Daten separat gehandhabt werden. Die (schönen) RX µCs von 
Renesas können das sogar per exDMA im Hintergrund erledigen. Aber selbst 
ein STM32F407 macht dies locker per Software.


> Ich habe schon an je einen kleinen
> Mikrocontroller pro Eingang gedacht, die die Daten erstmal synchron in
> den Speicher schieben. Von dort aus über den Hauptcontroller dann an
> RS232.

Wie klein soll den der µC sein? Er braucht zumindest einen hinreichend 
schnellen 12 Bit ADC und auch genügend Speicher. Da würde mir der 
STM32F411 einfallen, der 128 kB RAM auf dem Chip hat. Damit könnte man 
typisch ca. 0,6 s speichern, oder komprimiert etwa 0,8 s. Reicht das?
Für ihn gibt es ein einfaches Nucleo-Board. Wie man die Datenausgabe 
organisiert, lasse ich zunächst außer Acht und ebenso, wie 'synchron' 
die Daten erfaßt werden.

> Es gibt auch
> Entwicklungsboards die eigentlich nur das Nötigste beinhalten, was ich
> nicht gewusst habe. Ist der Sinn dahinter nur jener, dass man die
> Lötfummelei nicht hat?

Ja. Ein STM32F407 Discovery-Board ist einfacher zu handhaben, als den µC 
nebst Spannungsversorgung und Programmier-Schnittstelle selber 
aufzubauen, insbesondere, wenn es ein Einzelstück bleiben soll. Sonst 
ist ein spezielles Layout günstiger, weil man Alles so verdrahten kann, 
wie man es braucht.


> Hast du nen Tipp für gute Literatur oder Internetseiten für Anfänger im
> Bereich Mikrocontroller das mir bei meiner Aufgabe helfen kann?

Nein, den habe ich nicht. Gute Literatur gibt es fast garnicht mehr. 
Entweder bleiben die Ausführungen bei Banalitäten stecken oder sind zu 
abstrakt, daß der praktische Bezug fehlt (Das ist meine Erfahrung, wenn 
ich im Urlaub mal den Weg in einen größeren Buchladen finde.) Die beste 
Lektüre sind noch die Datenblätter der Hersteller nebst Applikationen 
dazu.

Einen Einstieg könntest Du vielleicht finden, indem Du Deine 
Anforderungen erst einmal zurücknimmst. Bleibe bei drei Kanälen und 12 
Bit und reduziere auf 10 kS/s. Dann könnte ein STM32F407 Discovery-Board 
die Grundfunktionen erledigen.


> Ich will ja weniger probieren als schon systematisch
> Bauteile besorgen

Das solltest Du zunächst vergessen. Ohne jegliche Erfahrung muß man 
Irrwege einplanen, allein schon, um seine Erfahrungen zu machen. Erst 
dadurch weißt Du am Ende, warum Du es so und nicht anders gemacht hast!

[Reginald L. (Firma: HEGRO GmbH) (reggie)]

m.n. schrieb:
> Auf jeden Fall, da alle ADCs wie einer angesprochen werden und nur die
> seriellen Daten separat gehandhabt werden. Die (schönen) RX µCs von
> Renesas können das sogar per exDMA im Hintergrund erledigen. Aber selbst
> ein STM32F407 macht dies locker per Software.

Das heisst also, dass ich die ADCs gleichzeitig anspreche und sie dann 
gleichzeit in verschiedene Speicherbereiche schreiben lasse(also 
programmiertechnisch zu lösen)? Verstehe ich das richtig, dass ich per 
Programmierung des Mikrocontrollers sehr große Möglichkeiten habe, was 
meine Bauteile wann tun sollen, ähnlich Software Programmierung am PC? 
Hardware vorausgesetzt, natürlich.
OK, exDMA ... du sprichst gegen eine Wand ;)

m.n. schrieb:
> Wie klein soll den der µC sein? Er braucht zumindest einen hinreichend
> schnellen 12 Bit ADC und auch genügend Speicher. Da würde mir der
> STM32F411 einfallen, der 128 kB RAM auf dem Chip hat. Damit könnte man
> typisch ca. 0,6 s speichern, oder komprimiert etwa 0,8 s. Reicht das?
> Für ihn gibt es ein einfaches Nucleo-Board. Wie man die Datenausgabe
> organisiert, lasse ich zunächst außer Acht und ebenso, wie 'synchron'
> die Daten erfaßt werden.

Damit meinte ich diskrete µC und ADCs. Da hätte ich freiere Auswahl in 
Bezug auf meine Anforderungen. Das ist eben auch die Frage, ist es 
programmiertechnisch sehr viel komplexer, wenn ich diskrete Bauelemente 
verwende oder darf ich mir hier ruhig Bauelemente aussuchen die meine 
Anforderungen am besten erfüllen? Von der Löttechnik mal abgesehen.
0,6s sind mir schon sehr knapp, ich habe lieber ordentlich Luft nach 
oben raus. Deshalb auch min. 100kS/s und 12bit, Aufzeichnungsdauert 
sollte bei mindestens einer Sekunde liegen, lieber etwas mehr. Ums Geld 
gehts mir übrigens auch nicht. Obwohl sich die Kosten ja im Rahmen 
halten in der Elektronikindustrie. Zumindest was Bauelemente angeht.

m.n. schrieb:
> Sonst
> ist ein spezielles Layout günstiger, weil man Alles so verdrahten kann,
> wie man es braucht.

Ich habe meine bisherige Verstärkerschaltung synchron am Steckbrett und 
auf KiCAD aufgebaut. Mit dem Layouter habe ich mich auch schon 
beschäftigt und habe auch vor die Platine nach der Tonertransfermethode 
zu ätzen. Sorgen mache ich mir nur um die Führung der Leiterbahnen und 
die Positionierung der Bauteile, da ich hier absolut keine Erfahrung 
habe, geschweige denn theoretisches Wissen. Naja, was heißt "Sorgen"... 
bin eher gespannt was dabei herauskommt.

m.n. schrieb:
> Die beste
> Lektüre sind noch die Datenblätter der Hersteller nebst Applikationen
> dazu.

Die Datenblätter lese ich schon fleißig, da erfährt man tatsächlich 
viel. Wusste nur nicht, dass die Erkenntnisse Allgemeingültig, in Bezug 
auf ähnliche Bauelemente, sind?

m.n. schrieb:
> Einen Einstieg könntest Du vielleicht finden, indem Du Deine
> Anforderungen erst einmal zurücknimmst. Bleibe bei drei Kanälen und 12
> Bit und reduziere auf 10 kS/s. Dann könnte ein STM32F407 Discovery-Board
> die Grundfunktionen erledigen.

Inwiefern erleichtert sich der Einstieg für mich, wenn ich mit den 
Samples runtergehe?

m.n. schrieb:
> Das solltest Du zunächst vergessen. Ohne jegliche Erfahrung muß man
> Irrwege einplanen, allein schon, um seine Erfahrungen zu machen. Erst
> dadurch weißt Du am Ende, warum Du es so und nicht anders gemacht hast!

Ja, dessen bin ich mir bewusst, das habe ich schon hier bei der 
Verstärkerschaltung erfahren. Vllt habe ich mich falsch ausgedrückt: Ich 
möchte verstehen, warum ich mir ein bestimmtes Bauelement aussuche. 
Nicht einfach in die Kiste grabschen und das tollste und teuerste Teil 
rausholen.


Vielen lieben Dank, dass du dir die Zeit für mich nimmst!

Hast du eine Quelle für mich, wenn es um Taktraten von µC, Speichern und 
Co geht? Ich blick da irgendwie den Zusammenhang nicht. Mir ist bewusst, 
dass ein Prozessor mit einem Taktschema arbeitet. Ich weiss auch, dass, 
beispielsweise im PC, der Hauptprozessor mit einer höheren Frequenz 
arbeitet als die Speicherchips. Die verschiedenen Bussysteme im Rechner 
arbeiten auch mit verschiedenen Taktraten. Wie kriegt man das denn alles 
unter einen Hut? Google spuckt mir nur PCGames, computerbase, etc, 
-Foren aus.

[m.n. (Gast)]

Reginald L. schrieb:
> Hast du eine Quelle für mich, wenn es um Taktraten von µC, Speichern und
> Co geht? Ich blick da irgendwie den Zusammenhang nicht.

Die Zusammenhänge mußt Du zunächst nicht überblicken, da die genannten 
µCs für diese Aufgabe schnell genug sind. Als Überblick: 
http://www.st.com/web/en/resource/technical/document/datasheet/DM00037051.pdf
Und hier steht etwas zum exDMA: 
http://www.glyn.de/data/glyn/media/doc/2013_02_13_RX63N_hm_rev150.pdf 
;-)

Reginald L. schrieb:
> m.n. schrieb:
>> Einen Einstieg könntest Du vielleicht finden, indem Du Deine
>> Anforderungen erst einmal zurücknimmst. Bleibe bei drei Kanälen und 12
>> Bit und reduziere auf 10 kS/s. Dann könnte ein STM32F407 Discovery-Board
>> die Grundfunktionen erledigen.
>
> Inwiefern erleichtert sich der Einstieg für mich, wenn ich mit den
> Samples runtergehe?

Du kannst mit einem fertigen, kostengünstigen Board arbeiten und die 
Programmierung angehen, wie sie auch abschließend funktionieren muß. 
Erst wenn Du die Erfassungsrate steigern willst, muß ein zusätzlicher 
Speicher (RAM) angeschlossen werden. Oder wenn ext. ADCs hinzukommen 
sollen, muß nur noch an einer Schraube gedreht werden.

Beim abschließenden Layout vergiß Deine Möglichkeiten, Platinen 
irgendwie selber aufs Kupfer zu bringen. Ein 4-lagiges Layout mit 
Lötstopplack auf beiden Seiten von einem passenden Anbieter ist 
günstiger und zuverlässiger, als der ganze Bastelkram.

[Reginald L. (Firma: HEGRO GmbH) (reggie)]

m.n. schrieb:
> Die Zusammenhänge mußt Du zunächst nicht überblicken, da die genannten
> µCs für diese Aufgabe schnell genug sind. Als Überblick:
> http://www.st.com/web/en/resource/technical/document/datasheet/DM00037051.pdf
> Und hier steht etwas zum exDMA:
> http://www.glyn.de/data/glyn/media/doc/2013_02_13_RX63N_hm_rev150.pdf
> ;-)

Aber die Anfragen / Antworten müssen doch irgendwie koordiniert werden, 
wenn mit verschiedenen Takten gearbeitet wird? Oder hängt das gar nicht 
mit der Kommunikation zusammen, soll heißen, das ist ein interner Takt 
im µC oder eben im Speicher und beschreibt in erster Näherung nur die 
"Schnelligkeit" der Verarbeitung in jenem Bauteil? Braucht man also die 
verschiedenen Bauelemente nicht vom Takt her irgendwie abzustimmen? 
Heute Nacht werde ich wohl wieder nicht schlafen können und googlen :)
Aaaaah OK, exDMA ist ein eigener Controller im Controller für die 
Speicheranbindung. Wie im PC der Speichercontroller im CPU (AMD) fürs 
DDR-RAM, nehme ich an. Hört sich interessant an. Und praktisch. Und 
kompliziert. Nur gut, dass der RX631 dann doch zu teuer ist für mich ;)

m.n. schrieb:
> Du kannst mit einem fertigen, kostengünstigen Board arbeiten und die
> Programmierung angehen, wie sie auch abschließend funktionieren muß.
> Erst wenn Du die Erfassungsrate steigern willst, muß ein zusätzlicher
> Speicher (RAM) angeschlossen werden. Oder wenn ext. ADCs hinzukommen
> sollen, muß nur noch an einer Schraube gedreht werden.

Du hast absolut recht. Die µC kosten nicht die Welt. Ich werde jetzt mal 
nach ein oder zwei passenden µC auf Evaluationsboards suchen, um erst 
mal zu schnuppern wie das alles funktioniert.

m.n. schrieb:
> Beim abschließenden Layout vergiß Deine Möglichkeiten, Platinen
> irgendwie selber aufs Kupfer zu bringen. Ein 4-lagiges Layout mit
> Lötstopplack auf beiden Seiten von einem passenden Anbieter ist
> günstiger und zuverlässiger, als der ganze Bastelkram.

Ich möchte doch keine Platine aufs Kupfer bringen, sondern das Kupfer 
von der Platine ätzen ;) Nee, im Ernst, ich möchte das auf jeden Fall 
versuchen. Dass 4-lagige Platinen zuverlässiger und Störunempfindlicher 
sind, ist mir bewusst. Warscheinlich wirds am Ende auch eine gekaufte. 
Vorerst aber erstmal nicht.


Und nochmals vielen lieben Dank, ich bin einen Schritt weiter!

EDIT: Würde sich so was hier zum Schnuppern anbieten?
http://www.conrad.de/ce/de/product/1221356/Entwicklungsboard-MikroElektronika-MIKROE-1105?ref=searchDetail

[m.n. (Gast)]

Reginald L. schrieb:
> Aaaaah OK, exDMA ist ein eigener Controller im Controller für die
> Speicheranbindung. Wie im PC der Speichercontroller im CPU (AMD) fürs
> DDR-RAM, nehme ich an. Hört sich interessant an. Und praktisch. Und
> kompliziert. Nur gut, dass der RX631 dann doch zu teuer ist für mich ;)

Oh, mal Jemand der Datenblätter liest ;-)

Der RX631 kostet < 10 Euro als Einzelstück, nur kennt ihn hier kaum 
einer (außer Olaf und ...).
Es ist im Vergleich zum STM32F4xx ein Edel-Prozessor. Achte mal auf die 
Interrupt-Vektoren, die für jedes einzelne Ereignis vorhanden sind. Beim 
STM muß in der ISR immer noch geprüft werden, welcher Kanal (beim Timer 
z.B.) den Interrupt ausgelöst hat.
Dann die DMA-Controller: die schaufeln die Daten von überall nach 
überall, vorwärts und rückwärts und ggf. auch mit frei wählbaren Abstand 
(Offset-Register).
Der Vorteil des STM32F407 ist seine Geschwindigkeit und die 
Unterstützung, die man hier im Forum finden kann.


> Ich werde jetzt mal
> nach ein oder zwei passenden µC auf Evaluationsboards suchen, um erst
> mal zu schnuppern wie das alles funktioniert.

Verfügbar und günstig ist das erwähnte STM32F407 Discovery-Board. Es 
sind noch viele I/O-Pins frei. Es gibt neuere Discovery-Boards mit ..429 
oder STM32F7xx. Mein Rat: Finger weg, da zu verspielt!
Dann sieh Dir die Seite vom 'Exponenten' an: 
http://mikrocontroller.bplaced.net/wordpress/?page_id=4908
Vielleicht hat er noch ein freies Board schon mit viel Speicher. 
Zumindest findest Du bei ihm Einiges an Software. Als IDE würde ich 
allerdings emBlocks vorschlagen, ohne das jetzt begründen zu wollen.


> EDIT: Würde sich so was hier zum Schnuppern anbieten?
> 
http://www.conrad.de/ce/de/product/1221356/Entwicklungsboard-MikroElektronika-MIKROE-1105?ref=searchDetail

Nicht so richtig, da ST-Link fehlt.

[Reginald L. (Firma: HEGRO GmbH) (reggie)]

m.n. schrieb:
> Oh, mal Jemand der Datenblätter liest ;-)

Haha, wenn du wüsstest wieviel PDFs ich hier aufm Werkstatt-Rechner habe 
;)

m.n. schrieb:
> Es ist im Vergleich zum STM32F4xx ein Edel-Prozessor. Achte mal auf die
> Interrupt-Vektoren, die für jedes einzelne Ereignis vorhanden sind. Beim
> STM muß in der ISR immer noch geprüft werden, welcher Kanal (beim Timer
> z.B.) den Interrupt ausgelöst hat.
> Dann die DMA-Controller: die schaufeln die Daten von überall nach
> überall, vorwärts und rückwärts und ggf. auch mit frei wählbaren Abstand
> (Offset-Register).

Mit Interrupts kann ich was anfangen ja, ansonsten... Wand ;)

m.n. schrieb:
> Verfügbar und günstig ist das erwähnte STM32F407 Discovery-Board. Es
> sind noch viele I/O-Pins frei.

Da ist ja jede Menge Kruscht drauf. Ich würde gerne was haben, was 
"clean" ist. So wird es doch nur unübersichtlicher für mich?

m.n. schrieb:
> Nicht so richtig, da ST-Link fehlt.

Ach, so direkt über USB ist nicht? Dh. also ich benötige den Adapter von 
ST und ein Board das dies unterstützt, nehme ich an? Ist der Adapter 
nicht direkt an den µC angeschlossen?

[Frank K. (fchk)]

Mal ne Frage:
1. Wie sieht es mit galvanischer Trennung aus? Bei gewünschten 12 oder 
mehr Bits könnte das sinnvoll sein.

2. Musst Du synchron abtasten?

3. Musst Du unbedingt puffern?

Schau Dir mal den FTDI FT2232H bzw FT4232H an:
http://www.ftdichip.com/Support/Documents/DataSheets/ICs/DS_FT2232H.pdf
http://www.ftdichip.com/Support/Documents/DataSheets/ICs/DS_FT4232H.pdf

oder neu und besonders interessant für Dich:
http://www.ftdichip.com/Support/Documents/DataSheets/ICs/DS_FT4222H.pdf
USB-Quad SPI Bridge.

Das sind USB High Speed Devices, d.h. damit solltest Du die geforderten 
Abtastraten erzielen können. Vorteil:
1. Du hast die Daten dann schon im PC
2. Du ersparst Dir die Programmierung eines zweiten Prozessors
-> Du bist schneller fertig.

Und was die Platinenfertigung angeht: Lass das Profis machen. Speziell 
bei QFN Packages wie beim FT4222H hast Du sonst echte Probleme, wenn Du 
keinen Lötstopplack hast. Das Löten ist schon auf einem professionell 
gefertigten Board haarig genug.

fchk

[Reginald L. (Firma: HEGRO GmbH) (reggie)]

Frank K. schrieb:
> 1. Wie sieht es mit galvanischer Trennung aus? Bei gewünschten 12 oder
> mehr Bits könnte das sinnvoll sein.

Hab hier schon zwei lineare Optos rumliegen ;)

Frank K. schrieb:
> 2. Musst Du synchron abtasten?

Unbedingt! Das, und mindestens(!) 1k Abtastungen / Rotorumdrehung.
EDIT: Ok, um genauer darauf einzugehen: Mit Synchron meine ich maximal 
10µs Phasenverschoben. Geschätzter Wert, würde 1° Abweichung 
entsprechen. Ich möchte alle Verfälschung so gering wie möglich halten, 
weil ich nicht weiss, wie sich das am Ende zusammen auswirkt.

Frank K. schrieb:
> 3. Musst Du unbedingt puffern?

Hehe, das solltest du jemanden fragen, der sich mit Elektronik besser 
auskennt als ich ;) Im Ernst: An sich, könnten die Daten gleich in den 
Ram meines PCs. Da ich aber keinerlei Erfahrung auf dem Gebiet habe, bin 
ich davon ausgegangen, es wäre sicherer die Daten erstmal in Sicherheit 
zu bringen. Danach sind die erst mal da und dann sehen wir weiter. Bin 
für Anregungen offen, teilet euer Wissen mit mir :)

> 2. Du ersparst Dir die Programmierung eines zweiten Prozessors

Wie meinst du das? Wenn ich den Mikrocontroller programmiert habe, 
müsste ich doch die Daten am PC abholen können?

Frank K. schrieb:
> Und was die Platinenfertigung angeht: Lass das Profis machen. Speziell
> bei QFN Packages wie beim FT4222H hast Du sonst echte Probleme, wenn Du
> keinen Lötstopplack hast. Das Löten ist schon auf einem professionell
> gefertigten Board haarig genug.

Gott behüte, QFN... da hört der Spaß auf, ich hab von SOIC oder sowas 
geredet ;)

[Frank K. (fchk)]

Reginald L. schrieb:

>> 2. Du ersparst Dir die Programmierung eines zweiten Prozessors
>
> Wie meinst du das? Wenn ich den Mikrocontroller programmiert habe,
> müsste ich doch die Daten am PC abholen können?

Mit den genannten FTDI-Bausteinen kommt man oft ohne aus. Das ist meine 
Idee dahinter.

fchk

[Reginald L. (Firma: HEGRO GmbH) (reggie)]

Frank K. schrieb:
> Mit den genannten FTDI-Bausteinen kommt man oft ohne aus. Das ist meine
> Idee dahinter.

Verstehe ich das folgendermaßen richtig: Ich nehme ADCs die die gleiche 
Schnittstelle bereitstellen, wie die von dir geposteten USB-Controller, 
programmiere ein Protokoll und bekomme durchgehend Daten geliefert?

[Frank K. (fchk)]

Reginald L. schrieb:
> Frank K. schrieb:
>> Mit den genannten FTDI-Bausteinen kommt man oft ohne aus. Das ist meine
>> Idee dahinter.
>
> Verstehe ich das folgendermaßen richtig: Ich nehme ADCs die die gleiche
> Schnittstelle bereitstellen, wie die von dir geposteten USB-Controller,
> programmiere ein Protokoll und bekomme durchgehend Daten geliefert?

Ja, so ähnlich.

Als ADC schau Dir mal den hier an:

http://www.analog.com/en/products/analog-to-digital-converters/ad-converters/ad7658-1.html#product-overview

Der hat nicht nur 6 Eingänge (3 Paare), sondern 6 ADCs, die wirklich 
gleichzeitig arbeiten können. Jedes Paar kann über einen Pin getriggert 
werden, d.h. Du hast Null Phasendifferenz. Jedes Paar hat einen eigenen 
seriellen Ausgangsdatenpin. Das dann an einen FT4222H im QSPI-Modus 
könnte es schon sein.

Der kritische Punkt ist USB und das Echtzeitverhalten von Windows. Aber 
einen Versuch wäre es wohl wert.

fchk

[Reginald L. (Firma: HEGRO GmbH) (reggie)]

Das Prinzip hört sich klasse an, wusste auch gar nicht, dass sowas 
direkt geht. Aber wie du schon sagst, USB und Windows. Und 
Echtzeitübertragung ist bei mir auch nicht gefordert. Ich werde beim µC 
bleiben, habe da jetzt richtig lust darauf bekommen ;) Danke für den 
Tipp!

[Frank K. (fchk)]

Reginald L. schrieb:
> Das Prinzip hört sich klasse an, wusste auch gar nicht, dass sowas
> direkt geht. Aber wie du schon sagst, USB und Windows. Und
> Echtzeitübertragung ist bei mir auch nicht gefordert. Ich werde beim µC
> bleiben, habe da jetzt richtig lust darauf bekommen ;) Danke für den
> Tipp!

Dann bleib aber beim von mir genannten ADC. Die allermeisten 
Microcontroller haben nämlich nur einen einzigen ADC mit Multiplexer 
davor.

fchk

[Reginald L. (Firma: HEGRO GmbH) (reggie)]

Frank K. schrieb:
> Dann bleib aber beim von mir genannten ADC. Die allermeisten
> Microcontroller haben nämlich nur einen einzigen ADC mit Multiplexer
> davor.

Ich wollte eigentlich zu differentiellen, Sigma-Delta ADCs greifen, kann 
doch synchron auf alle zugreifen, wie vorher von m.n. geschrieben?

Ich benutze den ADC im Controller nur um mich erst mal in die Materie 
einzuarbeiten. Da hat mir m.n. n super Tipp gegeben. Ich hab den Wald 
schon vor lauter Bäumen nicht mehr gesehen. Absolut logisch erstmal nur 
an den Controller ranzugehen.

Kannst du mir gerade verraten, wie das mit der Verbindung zum 
Programmieren des µC funktioniert? Habe bisher nur das hier gefunden:
http://www.st.com/web/en/catalog/sense_power/FM142/CL1499/SC172/PF245141
Ist das der IC der zwischen ST-Link Adapter und STM32 sitzt? Oder wie 
kann ich mir das mit ST-Link vorstellen? Direkt über RS232 / USB an den 
µC, um ihn zu programmieren, funktioniert wohl anscheinend nicht?

EDIT: Quatsch, das ist was ganz anderes :> Ich finde da nix zu.
EDIT2: Ah OK, das haben anscheinend nur die Nucleos und Discoverys von 
ST?

[Frank K. (fchk)]

Reginald L. schrieb:
> Frank K. schrieb:
>> Dann bleib aber beim von mir genannten ADC. Die allermeisten
>> Microcontroller haben nämlich nur einen einzigen ADC mit Multiplexer
>> davor.
>
> Ich wollte eigentlich zu differentiellen, Sigma-Delta ADCs greifen, kann
> doch synchron auf alle zugreifen, wie vorher von m.n. geschrieben?

Gut, hier hast Du alle in einem Chip. AD hat noch mehr von der Sorte.

> Kannst du mir gerade verraten, wie das mit der Verbindung zum
> Programmieren des µC funktioniert?

Das Programmieren geht über JTAG und ist bei allen ARMs prinzipiell 
gleich. Es gibt ARMs, die ROMs mit USB- oder UART-Bootloadern haben, 
aber zum Debuggen brauchst Du dann noch wieder einen JTAG-Adapter. 
Empfehlenswert ist der JLINK - die Lösungen der Chip-Hersteller sind auf 
die jeweiligen Hersteller beschränkt.

fchk

[Reginald L. (Firma: HEGRO GmbH) (reggie)]

Frank K. schrieb:
> Empfehlenswert ist der JLINK - die Lösungen der Chip-Hersteller sind auf
> die jeweiligen Hersteller beschränkt.

Ich habe jetzt zum ST-Link/V2 gegriffen. Bis ich mal so weit bin, dass 
ich nen andern Chip programmiere als den der jetzt kommt, werden wohl 
Jahre vergehen ;)

Im übrigen habe ich den STM32F407VGT6 (Discovery) bestellt, wie 
empfohlen.

Und nochmals ein ganz dickes Dankeschön für eure Hilfe!

[vloki (Gast)]

Reginald L. schrieb:
> Gibt es jemanden der aus der nähe Ulm kommt, sich
> mit diesem Thema auskennt ...

Gibt es da eigentlich an der HS Ulm niemanden ?
Was ist denn das für ein Saftladen ;-)

Im Ernst, da hat es doch bestimmt Leute, die entsprechende Vorlesungen 
und Labore anbieten. (Vielleicht nicht unbedingt in deinem Fachbereich)
Dort könntest du dann trotzdem mal nachfragen bzw. die Unterlagen 
anschauen, Tools ausleihen ...

[Reginald L. (Firma: HEGRO GmbH) (reggie)]

vloki schrieb:
> Gibt es da eigentlich an der HS Ulm niemanden ?
> Was ist denn das für ein Saftladen ;-)

Du glaubst doch wohl nicht ernsthaft, dass man so etwas an der 
Hochschule lernt ;) Bestimmt gibt es da ein paar Studenten die wirklich 
mit dem Herzen dabei sind, aber finde mal so einen. Ich kenne zwar einen 
der Elektrotechnik studiert, aber ganz ehrlich: Bei dem läuft der limes 
der Anwendbarkeit in Abhängigkeit seiner theoeretischen Kenntnisse gegen 
Null. Die meisten wollen doch nur eins: Später das dicke Geld verdienen, 
in gehobener Position, am besten im Anzug. Denen ist es relativ egal ob 
Ingi, BWLer oder sogar Künstler. Ist meine persönliche Erfahrung und wie 
gesagt, natürlich trifft das nicht auf alle zu.

vloki schrieb:
> Dort könntest du dann trotzdem mal nachfragen bzw. die Unterlagen
> anschauen, Tools ausleihen ...

Daran habe ich noch gar nicht gedacht. Es sind jetzt eh Semesterferien, 
da haben die Profs evtl. sogar etwas Zeit. Danke für den Anstoß ;)

[Reginald L. (Firma: HEGRO GmbH) (reggie)]

Nachts im Bett, beim Einschlafen und Nachdenken, entstehen die besten 
Ideen:

Ich benötige gar nicht so einen großen Speicher. Ich kann eine Umdrehung 
des Rotors in den µC-Speicher laden, von dort aus in den PC scheffeln. 
Wenn der µC danach bereit ist, kann die nächste Umdrehung geladen 
werden, ob dazwischen noch Umdrehungen stattgefunden haben, interessiert 
nicht. Das habe ich gestern hier im Forum ja auch geschrieben. Aber 
irgendwie war das nicht in mein Kleinhirn vorgedrungen.
Gerade ist mir aufgefallen, dass ab etwa 15Hz (Rotordrehzahl) und den 
besagten 1000Sa / Hz, entweder der Klebestreifen für die Lichtschranke 
breiter ausfallen oder aber mit mehr Sa / Hz aufgezeichnet werden muss. 
Beim späteren Auswuchten ist es praktisch, wenn der Klebestreifen 
möglichst schmal ist. Deshalb muss ich hier mit mehr Samples abtasten. 
Das heißt auch, dass ich mit den geforderten 100kSa/s am Ende nicht mehr 
auskomme. Somit würde ich zu ADCs greifen, die eher an 1MSa/s rankommen. 
Wieviel genau, werde ich mir später durch den Kopf gehen lassen, wenn 
ich mich mit dem µC angefreundet habe.


Hierzu nochmals zwei Fragen:

1. Die Abtastrate bestimmt ja der ADC. Aber wie geht es weiter auf der 
Schnittstelle zwischen ADC und µC? Die Übertragungsrate muss dann vom µC 
ja beherrschbar sein. Wenn der STM32 auf der SPI-Leitung bis zu 42MBit/s 
schafft und der ADC überträgt, beispielsweise, 16bit und 1MS/s 
(16Mbit/s? kommt da noch Overhead dazu?), dann wäre alles im grünen 
Bereich? Schafft der STM32 zusammen auf allen SPI-Leitungen die 42MBit/s 
oder gilt das jeweils? Das konnte ich dem Datenblatt noch nicht 
entnehmen.

2. Interessieren mich in dem Zusammenhang die unterschiedlichen 
Taktraten zwischen ADC und µC?

Danke, mal wieder!

[Frank K. (fchk)]

Reginald L. schrieb:

> 1. Die Abtastrate bestimmt ja der ADC. Aber wie geht es weiter auf der
> Schnittstelle zwischen ADC und µC? Die Übertragungsrate muss dann vom µC
> ja beherrschbar sein. Wenn der STM32 auf der SPI-Leitung bis zu 42MBit/s
> schafft und der ADC überträgt, beispielsweise, 16bit und 1MS/s
> (16Mbit/s? kommt da noch Overhead dazu?), dann wäre alles im grünen
> Bereich? Schafft der STM32 zusammen auf allen SPI-Leitungen die 42MBit/s
> oder gilt das jeweils? Das konnte ich dem Datenblatt noch nicht
> entnehmen.

Das kann kritisch werden. Oft ist es nicht so einfach, dass die Daten 
kontinuierlich per SPI abfallen. Du musst die Wandlung starten, Du musst 
warten, bis die Wandlung fertig ist, und erst dann kannst Du Deinen Wert 
abholen.

Es gibt Wandler mit parallelem Interface, bei denen das nicht so ist. 
Beispiel:
http://www.analog.com/media/en/technical-documentation/data-sheets/AD9221_9223_9220.pdf

Da kommt mit jedem Takt an CLK ein Wert raus, d.h. da musst Du nicht 
warten. Aber: Zwischen dem Einlesen eines Wertes und der Ausgabe 
vergehen drei Takte, die der Chip für die Wandlung braucht. Wenn diese 
Latenz wichtig ist, musst Du sie berücksichtigen.

Letztendlich kann es durch die veränderten Anforderungen sein, dass Du 
mit Deinem STM32 gar nicht so viel anfangen kannst, weil das meiste in 
Hardware realisiert werden muss. Sprich: Du hast drei Kanäle, jeder mit 
einem dieser ADCs bestückt, dazu eine gemeinsame Taktquelle. Hinter 
jedem ADC sind zwei FIFOs, zB solche:
http://www.idt.com/document/dst/72v01-72v06-datasheet

Zum Start werden die FIFOs resettet. Dann werden mit jedem Sampletakt 
Daten in die FIFOs geschrieben, bis sie voll sind. Wenn Das Full Flag 
gesetzt ist, stoppt die Abtastung, und Du kannst die Fifoinhalte 
beliebig langsam zB mit einem FT2232H auslesen.

Früher hätte man die erforderliche Logik mit diskreten Zählern 
realisiert, heute nimmt man ein kleines CPLD oder FPGA dazu. Viele FPGAs 
haben bereits Speicherblöcke, die sich als FIFO konfigurieren lassen, so 
dass Du Dir die FIFO-Chips sparst.

Diese Methode ist nur durch die Geschwindigkeit der ADCs begrenzt (die 
FPGAs selber sind schnell genug), d.h. ein Abtastintervall von 100ns 
entsprechend 10 MHz (AD9220) ist so problemlos möglich, und die 
Abtasttiefe wird dadurch begrenzt, wie viel Block RAM Dein FPGA hat. Mit 
einem schnelleren ADC geht auch noch eine Zehnerpotenz mehr.

Vielleicht ist das der sinnvollere Weg.

fchk

[m.n. (Gast)]

Reginald L. schrieb:
> Nachts im Bett, beim Einschlafen und Nachdenken, entstehen die besten
> Ideen:

Na, dann schlaf noch ein paar Nächte und kläre uns über Klebestreifen am 
Horizont und Sample-Raten auf.
Für eine schnelle Abtastung ist es notwendig, daß auch die Sensoren 
überhaupt so schnelle Änderungen an ihren Ausgängen zeigen. Was sind das 
für Sensoren und wozu werden 12 Bit benötigt? Sind absolute Spannungen 
auszuwerten oder kann man ratiometrisch messen?

Reginald L. schrieb:
> Somit würde ich zu ADCs greifen, die eher an 1MSa/s rankommen.

Jeder der drei ADCs im STM32F407 schafft 2,4 MS/s. Per DMA kann er die 
Daten ins interne Ram schreiben, dessen Zugriffszeit bei 6 ns liegt.
Ist das nichts? ;-)

Laß Dich hier nicht verrückt machen mit irgendwelcher galvanischer 
Trennung, seriellen Übertragungraten oder einem JTAG-Adapter, der 
garnicht notwenig ist.

Reginald L. schrieb:
> Im übrigen habe ich den STM32F407VGT6 (Discovery) bestellt, wie
> empfohlen.

Gut, damit hast Du erst einmal genug zu tun. Wenn der interne Speicher 
doch reichen sollte (ca. 180 kB wären nutzbar), hättest Du damit fast 
eine fertige Lösung.

[Reginald L. (Firma: HEGRO GmbH) (reggie)]

Frank K. schrieb:
> Das kann kritisch werden. Oft ist es nicht so einfach, dass die Daten
> kontinuierlich per SPI abfallen.

Kannst du mir das näher erläutern?


Frank K. schrieb:
> Letztendlich kann es durch die veränderten Anforderungen sein, dass Du
> mit Deinem STM32 gar nicht so viel anfangen kannst, weil das meiste in
> Hardware realisiert werden muss.

Irgendetwas brauch ich ja um die Daten in den PC zu bekommen ;) Mir 
schwirren auch noch viele Kleinigkeiten im Kopf rum, die ich gerne an 
der Maschine hätte, aber mangels Analogausgängen am PC nicht imstande 
bin zu realisieren.


Frank K. schrieb:
> Du hast drei Kanäle, jeder mit
> einem dieser ADCs bestückt, dazu eine gemeinsame Taktquelle. Hinter
> jedem ADC sind zwei FIFOs

Diese bzw. eine ähnliche Lösung war eigentlich mein erster Ansatz, 
nachdem ich mir auf http://sigrok.org/ die Hardware der Oszis angeschaut 
hatte.


m.n. schrieb:
> Für eine schnelle Abtastung ist es notwendig, daß auch die Sensoren
> überhaupt so schnelle Änderungen an ihren Ausgängen zeigen. Was sind das
> für Sensoren und wozu werden 12 Bit benötigt? Sind absolute Spannungen
> auszuwerten oder kann man ratiometrisch messen?

Für Messung der Unwucht sind das piezoelektrische 
Beschleunigungsaufnehmer, hab hier mehrere, die nach unterschiedlichen 
Prinzipien arbeiten, rumliegen. Welche es am Ende tatsächlich werden, 
stellt sich noch heraus. Ab +-0.5g bis +-9000g, welche mit 
Ladungsausgang, andere mit integrierter Schaltung. Die sind extra für 
Schwingungsmessungen gefertigt worden. Die 12Bit (wie gesagt, je mehr, 
desto besser) werden für die Auswertung dieser benötigt. Je nach 
Frequenz und Unwucht kann man sehr unterschiedliche 
peak-to-peak-Spannungen erhalten. Wichtig ist, dass man eine möglichst 
hohe Auflösung hat, damit man sowohl starke als auch schwache Unwuchten 
erkennnen kann. Bin da auf keine Idee gekommen, wie man die Sinuskurven 
bei hohen Unwuchten in Ihren Amplituden abschwächen könnte. Vllt wisst 
ihr das ja :)

Der Phasengeber ist ein MRL601: 
http://www.strippenstrolch.de/downloads/182230-da-01-de-Reflex_Lichtschranke_MRL_601.pdf
Da bin ich am überlegen, ob ich auf einen Induktivgeber umsteigen 
sollte. Ansonsten benötige ich nochmal einen MRL601 um die 
Tageslichtschwankungen abzufangen. Momentan drehe ich noch am Trimmer :D 
Andererseits habe ich mit dem Induktivgeber auch wieder ein höheres 
Gewicht am Rotor.

Die Beschleunigungsaufnehmer erzeugen die zu messende Spannung selbst, 
hier brauche ich keine Ratiometrie. Bzw. ist diese schon in den 
Messwertaufnehmern integriert, das weiss ich nicht.


m.n. schrieb:
> Jeder der drei ADCs im STM32F407 schafft 2,4 MS/s. Per DMA kann er die
> Daten ins interne Ram schreiben, dessen Zugriffszeit bei 6 ns liegt.
> Ist das nichts? ;-)

Du willst mir doch nur den Spaß am Löten nehmen ;D
Im Ernst: Dh. ich brauche für jeden Zugriff, ob Schreiben oder Lesen, 
mindestens 6ns? Wenn der ADC nun alle 0,4µs (bei vollem Sampling) Daten 
in den Speicher schieben möchte, funktioniert das? Würde nach Adam Riese 
ja für meine Zwecke ausreichen.


m.n. schrieb:
> hättest Du damit fast
> eine fertige Lösung.

Na, dann hätte ich mir ja auch gleich ne Wuchtmaschine kaufen können^^

[m.n. (Gast)]

Reginald L. schrieb:
> m.n. schrieb:
>> hättest Du damit fast
>> eine fertige Lösung.
>
> Na, dann hätte ich mir ja auch gleich ne Wuchtmaschine kaufen können^^

Das bezog sich auf die Hardware. Die Software selber wird Dich noch 
einige schlaflose Nächte kosten - mindestens ;-)

[Reginald L. (Firma: HEGRO GmbH) (reggie)]

Halte mich von mir aus für einen Masochisten. Aber ich freue mich schon 
richtig darauf ;)

[Volker S. (vloki)]

Reginald L. schrieb:
> Gerade ist mir aufgefallen, dass ab etwa 15Hz (Rotordrehzahl) und den
> besagten 1000Sa / Hz, entweder der Klebestreifen für die Lichtschranke
> breiter ausfallen oder aber mit mehr Sa / Hz aufgezeichnet werden muss.
> Beim späteren Auswuchten ist es praktisch, wenn der Klebestreifen
> möglichst schmal ist. Deshalb muss ich hier mit mehr Samples abtasten.
> Das heißt auch, dass ich mit den geforderten 100kSa/s am Ende nicht mehr
> auskomme.

Mit wie viel Samples pro Umdrehung möchtest du denn eigentlich deine 
Sensoren abtasten ? Bei 15 U/s und 100kHz hättest du 6667 Abtastwerte.

Das mit dem Klebestreifen ist mir auch nicht ganz klar. Der dient als 
"großflächiger" Reflektor für deinen Sensor. Aus dem Signal generierst 
du dann irgendwie deinen Trigger für die Messung.
Wie klein müsste der Klebestreifen eigentlich sein, damit 6667 
Abtastwerte
nicht ausreichen, und würde das dann noch "großflächig" genug sein damit 
der Sensor überhaupt funktioniert ?

Hast du schon über andere Möglichkeiten nachgedacht dein Triggersignal 
zu erzeugen ?

[Thomas F. (igel)]

Reginald L. schrieb:
> 1. Die Abtastrate bestimmt ja der ADC. Aber wie geht es weiter auf der
> Schnittstelle zwischen ADC und µC? Die Übertragungsrate muss dann vom µC
> ja beherrschbar sein. Wenn der STM32 auf der SPI-Leitung bis zu 42MBit/s
> schafft und der ADC überträgt, beispielsweise, 16bit und 1MS/s

Wieso willst du denn immer einen externen ADC per SPI anhängen?
Nutze doch die internen ADCs des STM32.

> Gerade ist mir aufgefallen, dass ab etwa 15Hz (Rotordrehzahl) und den
> besagten 1000Sa / Hz, entweder der Klebestreifen für die Lichtschranke
> breiter ausfallen oder aber mit mehr Sa / Hz aufgezeichnet werden muss.

Den Geber für die Referenz tastet man nicht ab. Den hängt man an einen 
Interrupteingang des Controllers.

Versuche doch nicht alle Probleme der Welt in der Theorie und schon im 
Vorraus zu lösen.
Nimm erst mal dein Discovery-Board und mach dich damit vertraut.

[Reginald L. (Firma: HEGRO GmbH) (reggie)]

Volker S. schrieb:
> Mit wie viel Samples pro Umdrehung möchtest du denn eigentlich deine
> Sensoren abtasten ? Bei 15 U/s und 100kHz hättest du 6667 Abtastwerte.
>...damit der Sensor überhaupt funktioniert ?

Für die Beschleunigungsaufnehmer reichen an sich besagte 1000 
Abtastwerte / Hz, da hier das Signal immer eine Sinuswelle ist und man 
den Phasenwinkel beim späteren Auswuchten des Rotors eh nicht mehr 
genauer bestimmen kann, bzw. auch keinen Sinn macht (bei mittelgroßen 
Rotoren). Maximale Auswuchtfrequenz nehme ich großzügig mit 50Hz an. Da 
ich Luft nach oben haben möchte, fordere ich nicht 50kSa/s sondern 
100kSa/s je Kanal. Da komme ich dann im schlimmsten Fall auf 2000 
Abtastwerte bei 50Hz. Das Signal durchläuft dann auch noch einen 
Tiefpassfilter, weshalb ich den Sicherheitsfaktor mal eingeplant habe.
Hinzu kommt jetzt noch der Phasengeber: Dieser misst die Frequenz des 
Rotors sowie die Phasenlage der Unwuchten in Bezug auf ebendiese. Bei 
50Hz und einem 1° breiten Streifen (bezogen auf Rotordurchmesser) komme 
ich auf ein theoretisches Mindestabtastintervall von 55µs (in der Praxis 
benötigt man dann aber mehr, da sonst Umdrehungen übersehen werden). 
Hier kommt mein aktueller MRL601 wohl bald nicht mehr, wenn ich das 
richtig verstehe:
http://www.strippenstrolch.de/downloads/182230-da-01-de-Reflex_Lichtschranke_MRL_601.pdf
Bei kleinen Durchmessern ist die Annahme der Breite von 1° utopisch, bei 
größeren Durchmessern aber durchaus möglich und dann auch sinnvoll. 
Damit kommt man schonmal auf knapp 20kSa/s. Nun möchte ich nicht nur 
einen Wert des Phasengebers bekommen (bei großen Durchmessern OK), 
sondern möglichst, in Abhängigkeit der breite des Streifens, vor allem 
bei kleineren Durchmessern, eine nicht näher bestimmte Anzahl davon. Bei 
zwei Werten müsste ich schon bei 40kSa/s, bei 50Hz, sein. Ich bin hier 
jetzt nicht näher darauf eingegangen, sondern habe mal "ein paar" 
100kSa/s als Anforderung veranschlagt, deshalb auch meine Forderung an 
den / die ADC(s) um etwa 1MSa/s. Für die Drehzahl wird mithilfe den 
Datenpaketen, die jeweils 2 Umdrehungen beinhalten, ein Mittelwert 
gebildet.
Ich hoffe ich konnte das einigermaßen verständlich ausdrücken.


Volker S. schrieb:
> Hast du schon über andere Möglichkeiten nachgedacht dein Triggersignal
> zu erzeugen ?

Ja! Aber auf keinen grünen Zweig gekommen. Der MRL601 steht noch nicht 
entgültig als Phasengeber fest, mit irgendetwas musste ich mich ja in 
die Materie einarbeiten. Induktivgeber: Zusätzliche Unwucht am Rotor. 
Hinzu kommt, dass die mitlaufende Induktivität eine hinreichend große 
Zentripetalkraft bereitstellen muss, schon aus Gründen der Sicherheit^^
Vllt hast du ja eine Idee?


Thomas F. schrieb:
> Wieso willst du denn immer einen externen ADC per SPI anhängen?
> Nutze doch die internen ADCs des STM32.

Fürs erste werde ich das ja. Meine Frage war anderer Natur.


Thomas F. schrieb:
> Den Geber für die Referenz tastet man nicht ab. Den hängt man an einen
> Interrupteingang des Controllers.

Mal abgesehen davon, dass das eine grobe Verallgemeinerung darstellt, 
vor allem bei sich ändernden Bedingungen in Bezug auf die Referenz:
Gäbe es da die Möglichkeit die Zeit zwischen den Interrupts zu messen? 
Falls ja, wie genau? Kann man den Interrupt mit einer absteigenden 
Flanke auslösen oder muss ich das Signal erst aufbereiten?


Thomas F. schrieb:
> Versuche doch nicht alle Probleme der Welt in der Theorie und schon im
> Vorraus zu lösen.
> Nimm erst mal dein Discovery-Board und mach dich damit vertraut.

Werde ich morgen, sobald er da ist. Ich versuche nicht alle Probleme der 
Welt im Voraus zu lösen, sondern stelle Fragen zu bestimmten Bereichen, 
die ja wohl hier im Forum gut aufgehoben sind, oder nicht? Hinzu kommt, 
dass ich dazu erzogen wurde, zuerst nachzudenken und dann zum Werkzeug 
zu greifen. Bisher bin ich ganz gut damit gefahren :) Bei neuen 
Themengebieten ist es nur schwierig herauszubekommen, ab wann zum 
Werkzeug gegriffen werden kann.

Warum so genervt ;)

[m.n. (Gast)]

Reginald L. schrieb:
> Gäbe es da die Möglichkeit die Zeit zwischen den Interrupts zu messen?
> Falls ja, wie genau? Kann man den Interrupt mit einer absteigenden
> Flanke auslösen oder muss ich das Signal erst aufbereiten?

Alles kein Problem.
http://www.mino-elektronik.de/FM_407/fmeter_407.htm#a5

[Thomas F. (igel)]

Reginald L. schrieb:
> Bei kleinen Durchmessern ist die Annahme der Breite von 1° utopisch, bei
> größeren Durchmessern aber durchaus möglich und dann auch sinnvoll.
> Damit kommt man schonmal auf knapp 20kSa/s.

Vergiss das mit dem ständigen Auslesen. Auch verwendet man keinen ADC 
für solche Dinge.
Man benutzt nur einen Digital-IO und einen Timer-Capture-Interrupt 
zusammen mit einem internen Timer. Das Beispiel von m.n. funktioniert 
auch so.

Beitrag "reziproker Frequenzzähler mit STM32F4Discovery"

Timer Capture Interrupts funktionieren mit steigenden und fallenden 
Flanken und sind wesentlich schneller und genauer als du in Software 
jemals auslesen kannst.
Sowas wäre z.B. ein schöner Einstieg zum Kennenlernen:
Timer konfigurieren.
Capture Interrupt programmieren.
Signal an den IO-Pin anlegen.
Wert des Timer-Captures über UART an den PC schicken.
Freuen wenns geht.

[Reginald L. (Firma: HEGRO GmbH) (reggie)]

m.n. schrieb:
> Alles kein Problem.
> http://www.mino-elektronik.de/FM_407/fmeter_407.htm#a5

Supi, danke, werde ich mir anschauen, wenn es soweit ist.

Thomas F. schrieb:
> Timer Capture Interrupts funktionieren mit steigenden und fallenden
> Flanken und sind wesentlich schneller und genauer als du in Software
> jemals auslesen kannst.

Muss ich nochmal genau anschauen, wenn ich in die µC-Geschichte 
eingestiegen bin ;) Hört sich ja super an, wenn das den Zweck erfüllt.


Hintergrund:
Vom Phasengeber, ob induktiv oder optisch, bekomme ich ja nichts anderes 
als sinusähnliche Peaks. Je höher die Drehfrequenz, desto kleiner der 
Peak. Nun kann ich entweder den absoluten Peak auswerten, indem ich mit 
mehreren Samples abtaste oder direkt nur den Peak erfasse. Wie ich den 
absoluten Peak direkt erfassen soll, weiß ich nicht. Habe zwar gegoogelt 
aber naja...Anfänger halt. Deshalb habe ich bisher einen Komparator 
benutzt, der mir ne logische 1 ausgibt, wenn der Sinus über einer 
bestimmten Spannung ist, und eine 0, wenn er wieder daruntersaust. So 
weiß ich, dass der Peak relativ genau zwischen steigender und fallender 
Flanke liegt. Wenn ich sowas per Digital I/O irgendwie realisieren kann 
und dabei Samples spare, klar, warum nicht! Wenn ich euch richtig 
verstanden habe, dann ja. Aber nochmal: "Echtzeit" am PC ist hier nicht 
gefragt. Hauptsache eine Umdrehung liegt auf dem Chipspeicher. Oder 
meintest du damit die "Software", Thomas?

[Reginald L. (Firma: HEGRO GmbH) (reggie)]

So, der STM32 und der ST-Link sind angekommen. Nun weiss ich auch, dass 
ein ST-Link auf dem Board integriert ist^^ Das macht aber nichts, da ich 
an der Maschine ja nicht das Discovery Board haben möchte, sondern eine 
diskrete Schaltung.

Habe mich schon ein wenig umgeschaut, das Board als Maus laufen lassen, 
Speicher ausgelesen. Bin begeistert, was in dieser Welt alles möglich 
ist.

Ich halte euch auf dem Laufenden und komme anschließend auch wieder mit 
Fragen auf euch zu, wenn es genehm ist :)

Grüße
Reggie

EDIT: Achso, wo hab ich nur meinen Kopf:
Ich werde mich zuallererst mal an Diller Technologies's Tutorial halten. 
Das Problem ist auch, dass ich mit C noch nie programmiert habe, so 
wirds hier auch noch eine Weile dauern, bis ich reingekommen bin. Falls 
ihr noch gute und vor allem einfache Tutorials habt, die auf Anfänger in 
C UND STM32 abzielen, würde ich mich über einen Link freuen :)

[Reginald L. (Firma: HEGRO GmbH) (reggie)]

Sooooo :)

Ich saß jetzt seit heute Vormittag dran. Zwischen Matlab und C gibts 
doch schon einige Unterschiede. Wenn man dann auch noch damit nen µC 
programmieren will, wird der Kopf ganz schön voll :) Aber ich habs 
geschafft ein kleines Programm zu schreiben, in dem D14 leuchtet und D15 
leuchtet, wenn ich den USER-Button betätige. Was glaubt ihr wie Stolz 
ich auf mich bin^^

1.Ich habe die Std.Periph.Driver in mein Projekt eingefügt. Weise sie 
aber in meiner main.c nicht aus (dort ist nur die stm32f4xx.h 
"inkludiert"). Woher bekommt er z.B. die Funktion 
RCC_AHB1PeriphClockCmd?

2.Ich habe HSE_Value auf 8M gestellt, da bei mir ja auch ein 8MHz 
Oszillator verbaut ist. Die restlichen Taktraten habe ich ausgerechnet 
und sollten jetzt auch übereinstimmen. Mit einem kleinen Skript aus dem 
Internet habe ich dann die (durch 5 geteilte) Taktfrequenz des Cores mit 
dem Oszilloskop ausgelesen -> OK, 168 MHz. Nun macht es gar keinen 
Unterschied, ob ich SystemInit() aufrufe oder nicht, er taktet immer mit 
den 168MHz. Er soll aber anscheinend mit weniger takten, wenn 
SystemInit() nicht aufgerufen wird, da er dann mit dem HSI taktet. Was 
hab ich hier verbockt?

3. Wie schnell bekomme ich den STM32 kaputt? :) Ich habe schon etwas 
darüber nachgedacht, was ist beispielsweise, wenn ich mal ausversehen 
einen SetBit Befehl auf einen Ausgang jage, an dem ein Schalter an Masse 
hängt und ich diesen drücke?


Und vielen Dank (nochmals!) für die bisherige Hilfe und für den 
Ratschlag zum µC, bin absolut zufrieden, damit bekomme ich genau das hin 
was ich brauche!


PS: Sollte ich bei Fragen zum µC besser einen neuen Thread aufmachen, 
wenn es nicht zum Thema hier passt?

[m.n. (Gast)]

Reginald L. schrieb:
> 1.Ich habe die Std.Periph.Driver in mein Projekt eingefügt. Weise sie
> aber in meiner main.c nicht aus (dort ist nur die stm32f4xx.h
> "inkludiert"). Woher bekommt er z.B. die Funktion
> RCC_AHB1PeriphClockCmd?

Sieh Dir noch einmal das Programmbeispiel zu meinem obigen Link an. 
Damit hast Du ein Gerüst, was mal etwas mehr macht als 
Weihnachtsbaumgeblinke ;-)
Wenn Du noch ein LCD-Modul anschließt, ergibt diese "Trockenübung" auch 
einen Sinn: 
Beitrag "LCD-Modul 2x16 am STM32F4Discovery-Board"

Die nächste, zielgerichtete Übung wäre dann, einen ADC-Eingang zu lesen 
und den Wert aufs Display zu bringen .....

Reginald L. schrieb:
> Er soll aber anscheinend mit weniger takten, wenn
> SystemInit() nicht aufgerufen wird, da er dann mit dem HSI taktet. Was
> hab ich hier verbockt?

Du hast nichts verbockt. Lasse alle Einstellungen zuerst einmal 
unverändert. Beim Aufruf von main() sind in der Regel der ext. Quarz 
berücksichtigt und die sinnvollen Maximaltaktfrequenzen eingestellt. 
Falls nicht, so ist der entscheidene Wert in PLL_M zu finden. 
Schlimmstenfalls läuft der µC Faktor 8/25 zu langsam.

[Reginald L. (Firma: HEGRO GmbH) (reggie)]

m.n. schrieb:
> Sieh Dir noch einmal das Programmbeispiel zu meinem obigen Link an.

Da sind die beiden Dateien ja ausdrücklich "inkludiert" (wie nennt man 
das richtig?). Bei mir jedoch nicht, woher bekommt er also die 
Funktionen? In der stm32f4xx.h sind sie ja nicht. Oder beachtet er die, 
wenn man die Dateien einfach nur in das Projekt einfügt? Somit müsste 
ich ja stm32f4xx.h ja auch nicht "inkludieren". Dann bringt mir der 
Debugger aber nen Fehler.


m.n. schrieb:
> Die nächste, zielgerichtete Übung wäre dann, einen ADC-Eingang zu lesen

Das wäre mein nächster Schritt gewesen. Ich würde das allerdings 
versuchen über USB auszulesen. Bisschen viel auf einmal, wenns nicht 
klappt, kommt ein LCD her :)


m.n. schrieb:
> Lasse alle Einstellungen zuerst einmal
> unverändert.

Eher ungern, da ich schon wissen möchte wann der µC was macht, teilweise 
auch wie. Das ist sozusagen das A und O. Sonst kommt am Ende unter 
Umständen Quatsch raus und man findet den Fehler nicht. Hinzu kommt, 
dass explizit darauf hingewiesen wird, SystemInit() als allererstes im 
Code aufzurufen. Ich muss verstehen, warum. Einfach so, Zeilen aus Codes 
copy-and-pasten, mag zum reinkommen ja OK sein, aber spätestens, wenn 
man "sein Ding" verwirklichen will, kann das schief gehen.


m.n. schrieb:
> Beim Aufruf von main() sind in der Regel der ext. Quarz
> berücksichtigt und die sinnvollen Maximaltaktfrequenzen eingestellt.
> Falls nicht, so ist der entscheidene Wert in PLL_M zu finden.
> Schlimmstenfalls läuft der µC Faktor 8/25 zu langsam.

Was macht denn genau main()? Ein Auszug aus der STM32-Hilfe, Kapitel 
CMSIS-CORE:
Methods for system initialization to be used by each MCU vendor. For 
example, the standardized SystemInit() function is essential for 
configuring the clock system of the device.


m.n. schrieb:
> Damit hast Du ein Gerüst, was mal etwas mehr macht als
> Weihnachtsbaumgeblinke ;-)

Heeeeey, lass mir mein Geblinke :) Was glaubst du was für ein Gefühl das 
war, als ich auf den Schalter gedrückt habe und die LED ausgegangen ist 
;)

[m.n. (Gast)]

Reginald L. schrieb:
> Eher ungern, da ich schon wissen möchte wann der µC was macht, teilweise
> auch wie. Das ist sozusagen das A und O.

Ich weiß ja nicht, welche IDE Du verwendest, aber starte Dein Programm 
im Einzelschrittbetrieb ab dem RESET und achte darauf, welche Funktion 
als erste aufgerufen wird; da kannst Du dann Alles ganz genau sehen.

[Reginald L. (Firma: HEGRO GmbH) (reggie)]

m.n. schrieb:
> Ich weiß ja nicht, welche IDE Du verwendest, aber starte Dein Programm
> im Einzelschrittbetrieb ab dem RESET und achte darauf, welche Funktion
> als erste aufgerufen wird; da kannst Du dann Alles ganz genau sehen.

Ich habe mit EMBlocks angefangen, das hat mir aber leider überhaupt 
nicht gepasst. Absolut ungeeignet beim Betrieb mit 2 Bildschirmen! Oder 
ich war zu blöd es richtig einzustellen, kein Kommentar ;) Momentan baue 
ich mit CrossStudio ein Projekt auf. Das sieht vielversprechend aus. 
Habe aber auch Keil und CooCox probiert. Sogar MS Visual Studio, da habe 
ich es aber überhaupt nicht hinbekommen. Ist wohl auch nicht so 
geeignet, zumindest finde ich relativ wenig Infos zu VS und µC. Schade, 
hätte gerne damit gearbeitet.

Jaaaa, Einzelschrittbetrieb. Das Stichwort habe ich vor ner Stunde etwa 
erst Entdeckt ;) Auch ist mir einiges klarer geworden in Bezug auf 
main(), SystemInit() und den Präprozessor-Definitionen. Wenn ich 
USE_STDPERIPH_DRIVER da drin habe, dann sind die Funktionen fürs 
Programm alle sichtbar, da die stm32f4xx.h sie, bzw. über 
Zwischenskripte, aufruft. Soweit ich das verstanden habe.

Auch C wird mir immer klarer. Ist schon ein himmelweiter Unterschied zu 
MatLab.

Wobei mir dann wieder andere, neue Dinge unklar sind. :) Was zum Teufel 
ist DSP. Ich weiss gar nicht was ich als erstes googlen soll ;)

[Reginald L. (Firma: HEGRO GmbH) (reggie)]

Hey m.n. :) kannst du mal einen Blick über den Code werfen und mir 
sagen, was ich wie ändern sollte? Sollte ich da Codeteile in andere 
Dateien auslagern? Wie macht man sowas "Normannähernd". Oder wie 
schreibst du deine Zeilen? Es gibt zwar echt viel hierzu im Internet, 
aber jeder hat ja auch ein bisschen seinen eigenen Schreibstil. Ich 
würde für den Anfang nur gerne wissen, wie du das handhabst.

Danke dir :)

EDIT: Haha, ich merk grad ich hab Bockmist zusammengeschrieben^^ 
Eigentlich wollte ich, dass der mir den Code oben erst im Main() 
ausführt. Habs korrigiert, jetzt aber.

[Reginald L. (Firma: HEGRO GmbH) (reggie)]

So, jetzt aber. Kannst irgendwie nicht hochladen:

main.c

#include "stm32f4xx.h"
#include "main.h"


int main(void)
{

SystemInit();

StartClock();
PortConfig();
Test();

while(1)
{

TestLoop();

}
}

main.h

///* Clock Ports *///
int StartClock()
{
  RCC_AHB1PeriphClockCmd(RCC_AHB1Periph_GPIOD | RCC_AHB1Periph_GPIOA | RCC_AHB1Periph_GPIOC, ENABLE);
}


///* Port Configuration *///
int PortConfig()
{
/* Port C */
GPIO_InitTypeDef GPIO_InitStructureC;
GPIO_StructInit(&GPIO_InitStructureC);
GPIO_InitStructureC.GPIO_Pin   = GPIO_Pin_9;
GPIO_InitStructureC.GPIO_Mode  = GPIO_Mode_AF;
GPIO_InitStructureC.GPIO_OType = GPIO_OType_PP;
GPIO_InitStructureC.GPIO_Speed = GPIO_Speed_100MHz;
GPIO_InitStructureC.GPIO_PuPd  = GPIO_PuPd_NOPULL;
/* Port A */
GPIO_InitTypeDef GPIO_InitStructureA;
GPIO_StructInit(&GPIO_InitStructureA);
GPIO_InitStructureA.GPIO_Pin   = GPIO_Pin_0;
GPIO_InitStructureA.GPIO_Mode  = GPIO_Mode_IN;
GPIO_InitStructureA.GPIO_OType = GPIO_OType_PP;
GPIO_InitStructureA.GPIO_Speed = GPIO_Speed_2MHz;
GPIO_InitStructureA.GPIO_PuPd  = GPIO_PuPd_NOPULL;
/* Port D */
GPIO_InitTypeDef GPIO_InitStructureD;
GPIO_StructInit(&GPIO_InitStructureD);
GPIO_InitStructureD.GPIO_Pin   = GPIO_Pin_15 | GPIO_Pin_14;
GPIO_InitStructureD.GPIO_Mode  = GPIO_Mode_OUT;
GPIO_InitStructureD.GPIO_OType = GPIO_OType_PP;
GPIO_InitStructureD.GPIO_Speed = GPIO_Speed_2MHz;
GPIO_InitStructureD.GPIO_PuPd  = GPIO_PuPd_NOPULL;
/* Port Initialization */
GPIO_Init(GPIOC,&GPIO_InitStructureC);
GPIO_Init(GPIOA,&GPIO_InitStructureA);
GPIO_Init(GPIOD,&GPIO_InitStructureD);
}

///* Test Code & Loop*///
int Test()
{
/* Set PD14 & PD15 @ON */
GPIO_SetBits(GPIOD,GPIO_Pin_15 | GPIO_Pin_14);
/* Set PC9 @SysClock */
RCC_MCO2Config(RCC_MCO2Source_SYSCLK, RCC_MCO2Div_5);
}
int TestLoop()
{
/* Get PA0 */
uint8_t PA0 = GPIO_ReadInputDataBit(GPIOA,GPIO_Pin_0);
if(PA0>0)
{
GPIO_ResetBits(GPIOD,GPIO_Pin_15);
}
else
{
GPIO_SetBits(GPIOD,GPIO_Pin_15);
}
}

[Reginald L. (Firma: HEGRO GmbH) (reggie)]

Hallo liebe Gemeinde,

wollte mich mal zurückmelden und meinen Dank an alle ausdrücken, die mir 
zum µC geraten haben und mir beim Einstieg sehr geholfen haben.

Inzwischen bin ich in C++ eingestiegen. Software am PC über VisualStudio 
und MFC, Controller mit VisualGDB programmiert. Am Controller bin ich 
von USB auf Ethernet umgestiegen, das eignet sich für die Anwendung um 
Längen besser. ADC, DAC, TIM, ITs, UART, ETH, überall wo möglich wird 
mit DMA gearbeitet, es tut alles das was es soll.

Ich hätte nie gedacht, dass ich da so schnell reinkomme. Es erscheint 
mir jetzt alles wesentlich weniger komplex als zu Anfang angenommen. Ich 
habe viel gelernt, vor allem im Bereich der C-Programmierung. Dafür ein 
herzliches Dankeschön an euch! Ihr habt einen neuen Verrückten unter 
euch :)

grüße reggie