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!
Also ATxmega8E5 der ist schnell und hat Event Unterstützung mit programmierbarer Logic. Amtel Studio7 mit gcc Compiler geht eigentlich sehr gut. Gruß Sascha
Dann schmeiss ich mal den STM32F030 (STM32F030K6T6 z.B.) in die Runde. Nett am Rande: 16bit-SPI mit DMA.
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.
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
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 :-)
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 :-)
> 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.
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
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.
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.
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
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 :-)
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?
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
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
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 ?
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.
Thread beobachten
Seitenaufteilung abschaltenBitte 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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.