Forum: Mikrocontroller und Digitale Elektronik Welchen günstigen µC für Sampling/Konvertierung?


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 Harstad (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hi,

ich muss ein proprietäres, serielles Signal konvertieren und benötige 
dazu eine möglichst preisgünstige Lösung (also irgend einen einfachen 
08/15-Mikroprozessor).

Das Signal besteht aus einer Clock-, einer Sync- und drei 
Datenleitungen. Das ganze leider nicht passend zu SPI/I2C oder ähnlichen 
Standards, weswegen der µC die 5 Datenleitungen permanent pollen müsste 
um die HIGH/LOW-Zustände der Eingänge zu erkennen. Die Clock- bzw. 
Bitfrequenz der Datenleitungen liegt bei max 2 MHz, der Cntroller 
bräuchte also ein bisschen Power.

Auf der anderen Seite sind zwei oder drei DACs anzusteuern (mindestens 
16 Bit), welche aus den übertragenen Daten ein Analogsignal fabrizieren.

Meine Frage hierzu: welcher Controller wäre empfehlenswert UND dabei 
auch noch halbwegs leicht zu programmieren (also in C, nicht mit 
Assembler ;-) )?

Ich habe mich schon mal bei den Atmels umgesehen, aber die haben 
entweder zu wenig Leistung oder - wenn sie mehr Power haben - dann 
wieder viel zu viele andere Features, welche nur den Preis erhöhen und 
vor allem Design/Fertigung verkomplizieren.

Jeder Tipp für eine möglichst einfache Lösung ist willkommen :-)

Danke!

von Sascha (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Also ATxmega8E5 der ist schnell und hat Event Unterstützung mit 
programmierbarer Logic.
Amtel Studio7 mit gcc Compiler geht eigentlich sehr gut.
Gruß Sascha

von H.Joachim S. (crazyhorse)


Bewertung
0 lesenswert
nicht lesenswert
Dann schmeiss ich mal den STM32F030 (STM32F030K6T6 z.B.) in die Runde.
Nett am Rande: 16bit-SPI mit DMA.

von Irgendwer (Gast)


Bewertung
2 lesenswert
nicht lesenswert
Harstad schrieb:
> Das Signal besteht aus einer Clock-, einer Sync- und drei
> Datenleitungen. Das ganze leider nicht passend zu SPI/I2C oder ähnlichen
> Standards, weswegen der µC die 5 Datenleitungen permanent pollen müsste
> um die HIGH/LOW-Zustände der Eingänge zu erkennen.

Warum pollen wenn du einen clock hast?
Mit dem hast du den genauen Zeitpunkt wenn du die Pins anfragen muss.
Jetzt muss du nur noch ermitteln wieviele Taktzyklen deine 
Interrupt-Routine voraussichtlich benötigen wird und was der µC nebenbei 
noch so tun soll und du hast die Taktrate die du mindestens benötigst.
Welcher genau ist nahezu egal solange er deine Mindestanforderungen 
erfüllt.

von Joe F. (easylife)


Bewertung
1 lesenswert
nicht lesenswert
Ein CPLD käme evtl. auch in Frage, VHDL oder Verilog ist nicht 
allzuschwer zu lernen. Oder evtl. auch eine einfache Schaltung aus CMOS 
Bauteilen.
Wie sieht das Eingangssignal denn genau aus?

: Bearbeitet durch User
von Harstad (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Irgendwer schrieb:
> Warum pollen wenn du einen clock hast?

Im Prinzip hast du recht, aber das ist ein Implementationsdetail.

Selbst wenn ich einen IRQ auf den Clock lege, muss ich innerhalb der ISR 
die verbleibenden 4 Eingänge trotzdem noch alle lesen, auswerten (Sync 
oder nicht) und die Daten zusammenbauen (Bits zusammenschieben oder 
komplette Datenworte ausgeben). Und das braucht schon ein bissl Zeit :-)

von Harstad (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Joe F. schrieb:
> Wie sieht das Eingangssignal denn genau aus?

Digitale HIGH/LOW-Werte, also nix spannendes. Spannungsbereich kann ich 
dir gerade nicht sagen, aber die auf einen kleinen, passenden Wert 
runterbringen ist jetzt ja nicht so das Problem :-)

von (º°)·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.· (Gast)


Bewertung
0 lesenswert
nicht lesenswert
> Das Signal besteht aus einer Clock-, einer Sync- und drei  Datenleitungen.

Mal Dir erstmal eine Statemachine die das ganze realisiert.

Bei 2 MHz Clock hast Du 500 ns fuer die komplette Runde:
Also Sync erkennen, 3 mal Daten einsammeln und daraus 3 DAs bedienen.
Und dann auf die naechste Clockflanke warten.

Dann hast Du schonmal einen Ansatzpunkt ab wieviel MHz CPU-Clock
Dein Controller startet.

Entwickeln macht gelegentlich halt auch mal Arbeit.

von Joe F. (easylife)


Bewertung
0 lesenswert
nicht lesenswert
Harstad schrieb:
> Digitale HIGH/LOW-Werte, also nix spannendes.

Ja schon klar.
Die Frage wäre, wie sind die Daten angeordnet (MSB first, LSB first), es 
scheint ja ein serielles Signal auf 3 Kanälen zu sein.
Wie sieht das Sync Signal aus?

Vielleicht hast du ja ein Timing-Diagramm für das Protokoll.
Evtl. ist es gar nicht so besonders. Es gibt auch noch andere Formate 
wie z.B. I2S, TDM, left-justified, right-justified, die in Frage kämen. 
Und dafür gäbe es DACs, die direkt angeschlossen werden könnten.

: Bearbeitet durch User
von Harstad (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Joe F. schrieb:
> Ja schon klar.
> Die Frage wäre, wie sind die Daten angeordnet (MSB first, LSB first), es
> scheint ja ein serielles Signal auf 3 Kanälen zu sein.

Es werden 20 Bit übertragen, wovon die ersten 4 Bit Steuerbits sind, der 
Rest sind Daten (MSB). Ein Bit wird mit der steigenden CLock-Flanke 
markiert und SYNC ist für die gesamte Dauer des letzten Bit auf LOW.

von Sebastian S. (amateur)


Bewertung
0 lesenswert
nicht lesenswert
Normale Risc µP mit 20 MHz machen einen Tick pro Tackt - manchmal auch 
weniger, wenn’s um Adressen geht.

Bei einem Signal von 2 MHz bleiben dann gerade noch maximal 10 Befehle 
pro Flankenwechsel. Also Pegelerkennung und Auswertung des vorherigen 
Zustandes, merken des aktuellen Zustandes und wenn auf die Frage: "Seid 
ihr denn auch alle da?" die Antwort "Ja" erschallt, auch noch das Merken 
und Auswerten. So Sachen wie Asynchronität noch nicht mal mitgerechnet 
und auch ohne "zeitliche" Betrachtungen.

Also würde ich sagen: Ein bissel mehr darf’s auch schon sein - oder ein 
FPGA bzw. seine Brüder.

von Joe F. (easylife)


Bewertung
0 lesenswert
nicht lesenswert
Harstad schrieb:
> Es werden 20 Bit übertragen, wovon die ersten 4 Bit Steuerbits sind, der
> Rest sind Daten (MSB). Ein Bit wird mit der steigenden CLock-Flanke
> markiert und SYNC ist für die gesamte Dauer des letzten Bit auf LOW.

Also relativ üblich.
Man müsste jetzt die Steuerbits durch 0 ersetzten (Datenleitungen über 
ein AND Gatter), und evtl. das Sync-Signal an die richtige Stelle 
schieben. Dann können die seriellen Daten (nach dem AND) auch direkt zum 
DAC.

Ich würde das einfach in CMOS bauen. 2 MHz sind auch noch auf Lochraster 
möglich.

Mit "Ein Bit wird mit der steigenden CLock-Flanke markiert" meinst du 
die Daten ändern sich mit fallenden Flanken und werden bei steigenden 
Flanken (in der Bit-Mitte) übernommen, oder ist die CLK Polarität 
umgekehrt?

: Bearbeitet durch User
von Harstad (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Joe F. schrieb:

> Man müsste jetzt die Steuerbits durch 0 ersetzten (Datenleitungen über
> ein AND Gatter), und evtl. das Sync-Signal an die richtige Stelle
> schieben.

Leider nein, die Steuerbits sind auszuwerten - es gibt nämlich z.B. 
bestimmte Bitmuster, bei denen die nachfolgenden Daten zu ignorieren 
sind.

> Mit "Ein Bit wird mit der steigenden CLock-Flanke markiert" meinst du
> die Daten ändern sich mit fallenden Flanken und werden bei steigenden
> Flanken (in der Bit-Mitte) übernommen

Ja genau :-)

von Joe F. (easylife)


Bewertung
0 lesenswert
nicht lesenswert
Harstad schrieb:
> Leider nein, die Steuerbits sind auszuwerten - es gibt nämlich z.B.
> bestimmte Bitmuster, bei denen die nachfolgenden Daten zu ignorieren
> sind.

Was soll der DAC dann in einem solchen Fall machen? Das letzte Datenwort 
nochmal ausgeben?
Wie sieht dieses Bitmuster aus?

von Stefan K. (stefan64)


Bewertung
0 lesenswert
nicht lesenswert
Nimm einen STM32Fx.
Den clock schliesst Du an einen externen Takteingang eines Timers an, 
z.B. Timer 1.
Darüber triggerst Du den DMA und liest den Port, an dem Deine 
Datenleitungen und Sync anliegen, per DMA ein.

Den Sync am besten auch auf einen Interrupt- oder dma-fähigen Pin legen.

Die CPU muss dann nur am Ende der Übertragung aus den 20 eingelesenen 
Worten die 4 seriellen Datenstreams zusammensuchen und an die DACs 
ausgeben. Das ist aber keine zeitkritische Sache mehr.

Falls das Audio-DACs sind: die (meisten?) STM32F haben eine 
Schnittstelle für Audio-Codecs.

Viele Grüße, Stefan

von Sascha (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Die STM32Fxxx sind doch viel zu teuer, da würde ich die Kinetis von NXP 
ex. Freescale vorher nehmen, da gibts deutlich preiswertere Chips und 
sogar eine IDE mit Expert Modus um die Peripherie zu konfigurieren.

VHDL extra dafür zu lernen würde ich dir abraten, so einfach ist das 
nicht, und vor allem nicht so schnell gemacht.

Es ist auch immer noch die Frage welche Tools stehen dir zur verfügung 
oder müssen erst noch angeschaft werden. Preis ? Aufwand ?

Lass dich nicht irreführen von den tollen Ratschlägen hier im Forum, 
nimm den kleinsten Nenner.

Gruß Sascha

von Schorsch X. (bastelschorsch)


Bewertung
0 lesenswert
nicht lesenswert
Sascha schrieb:
> Die STM32Fxxx sind doch viel zu teuer, da würde ich die Kinetis von NXP
> ex. Freescale vorher nehmen, da gibts deutlich preiswertere Chips und
> sogar eine IDE mit Expert Modus um die Peripherie zu konfigurieren.

Fällt das bei einer solchen Entwicklung überhaupt ins Gewicht ? Oder 
wird das 1000x gebaut ?

von Joe F. (easylife)


Bewertung
0 lesenswert
nicht lesenswert
Sascha schrieb:
> Lass dich nicht irreführen von den tollen Ratschlägen hier im Forum,
> nimm den kleinsten Nenner.

Das ist immer Ansichtssache, was der kleinste Nenner ist ;-)
In die Irre führen möchte hier bestimmt keiner.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.