Hallo, für ein Projekt zur Signalübertragung über Leitungen wird ein möglichst preisgünstiger Controller gesucht, der neben klassischer µC-Aufgaben auch die digitale Signalverarbeitung beherrscht. Es sollen eine FSK moduliert und demoduliert sowie höhere Ebenen des Kommunikationsprotokolls realisiert werden. Die Übertragungsraten sind eher gering (300 bps würde genügen), so dass die DSP-Anforderungen nicht allzu hoch sind. Dennoch müssen Abtastraten im 10kHz-Bereich verarbeit werden, so dass 8bit µCs an ihre Grenzen stossen, vor allem wegen der sehr langsamen Multiplikation. Das wichtigste Kriterium ist neben dem Preis der Energieverbrauch, der µC sollte schaltbare Taktfrequenzen haben und über einen Schlafmodus verfügen, falls es gearde nichts zu kommunizieren gibt. Idealerweise befinden sich möglichst alle wichtigen Hardwarekomponenten auf einem Chip (Speicher, AD/DA-Wandler). Bei klassischen DSPs sieht es bei letzterem relativ schlecht aus. 1. DSPic von Microchip - günstig und scheint gut für die Aufgabe geeignet, allerdings nicht wirklich sparsam. 2. Texas Instrument C5000 - Serie: Hohe DSP-Leistung bei gleichzeitig niedriger Stromaufnahme. Allerdings aufwändige Beschaltung - zusätzliche Spannungsversorgung für Core, externer Programmspeicher, daher teurer 3. 32bit Universal-µC: MIPS (PIC32) oder ARM Cortex. Sehr preisgünstig und auch gute Stromsparmöglichkeiten, allerdings keine echten DSP-Funktionen. Persönlich würde ich die Microchip (PIC) Produkte bevorzugen, da ich mich mit deren Entwicklungssystemen gut auskenne. Aber kennt jemand noch weitere Chips für ein derartiges Anforderungsprofil?
> Die Übertragungsraten sind eher gering (300 bps würde genügen), ... > so dass 8bit µCs an ihre Grenzen stossen, vor allem wegen der > sehr langsamen Multiplikation. Das macht ein 8-Bitter wie z. B. der AtMega328 mit links!
Ich kann auf einem xmega Audiosamples mit 256kSp modulieren, Frrequenzüberlagerung etc. und brauche trotzdem nur einen Bruchteil meiner Rechenzeit - und das ganz ohne DSP Funktionen (gute Algorithmen machens möglich). 300 bps schafft selbst ein Mega8!
Mike schrieb: > 3. 32bit Universal-µC: MIPS (PIC32) oder ARM Cortex. Sehr preisgünstig > und auch gute Stromsparmöglichkeiten, allerdings keine echten > DSP-Funktionen. Was unterscheidet denn "echte" von unechten DSP-Funktionen? Ein Cortex M3 aktuellerer Bauart wird den dsPIC mindestens einholen, ein Cortex M4 zersägt ihn (hat aber auch DSP Befehle). Dazu gibt es von ARM höchst selbst eine recht umfangreiche Bibliothek an fertigen Funktionen. Je nachdem welche Stückzahlen Du planst, bleib entweder bei den dsPIC weil Du die schon kennst oder nimm einen Cortex M3-M4. Schnell genug sind die alle.
STK500-Besitzer schrieb: > STM32F4 Das ist unnötig riesig, fett und teuer, und sauft gigantische Mengen an Strom. Ich habe einmal FSK-Demodulation mit >60kHz mit einem kleinen CortexM0 umgesetzt. Weil das demodulieren in Software geschehen ist, man musste den Takt auf 100% aufdrehen, es ging aber problemlos. Wir hatten eine FSK mit mehreren kBd über eine Zweidrahtleitung. Der hat die FSK in Software demoduliert, sogar der Komparator war im µC. Das war relativ billig, weil der µC <1€ kostet, und extern nur noch ein Low-Cost-OPV und ein bisserle Hühnerfutter nötig war. Mein Tipp wäre ein STM32F051 oder alternativ ein äquivalenter PIC32. Wenn der Stromverbrauch wichtig ist, wäre auch ein PIC24 einen Blick wert. Beachte unbedingt folgendes: Wenn du einen µC nimmst, mit dem du viele aufwändige Sachen in die Hardware verlagen kannst, wäre das enorm günstig für den Stromverbrauch, weil du den Takt reduzieren kannst. Sieh dir die Datenblätter also genau an. DMA wäre so ein Fall, der viel bringen kann (wenn für die Anwendung nutzbar).
Hi, > > Persönlich würde ich die Microchip (PIC) Produkte bevorzugen, da ich > mich mit deren Entwicklungssystemen gut auskenne. Aber kennt jemand noch > weitere Chips für ein derartiges Anforderungsprofil? Ich würde mich mal auch bei den kleinen Blackfin-Derivaten (BF529 o.ä.) von Analog Devices umsehen. Die bringen mW immer noch die höchste MIPS/uW-Ratio und lassen sich sehr gut drosseln/schlafenlegen. Zudem sind sie lange verfügbar. Nachteil: Sie sind in Europa schlecht verbreitet und die Distis verkaufen lieber TI. Entwicklungstools sind auch ein bisschen ein trauriges Thema.
@Mike (Gast) >Kommunikationsprotokolls realisiert werden. Die Übertragungsraten sind >eher gering (300 bps würde genügen), so dass die DSP-Anforderungen nicht >allzu hoch sind. In der Tat, das schafft ein normaler 8-Bitter ala AVR, MSP430 etc. >Dennoch müssen Abtastraten im 10kHz-Bereich verarbeit >werden, Warum muss man für 300 bps mit 10 kHz abtasten? Das klingt nach einer sehr akademischen Modulation bzw. Verarbeitung. >so dass 8bit µCs an ihre Grenzen stossen, vor allem wegen der >sehr langsamen Multiplikation. Wieso? Ein AVR macht eine 8x8 Bit Multiplikation in 2 Takten. Man wird wohl kaum mit Fließkomma arbeiten wollen/müssen. >Das wichtigste Kriterium ist neben dem Preis der Energieverbrauch, der >µC sollte schaltbare Taktfrequenzen haben und über einen Schlafmodus >verfügen, Das haben heute fast alle.
> Falk B. schrieb: > > Warum muss man für 300 bps mit 10 kHz abtasten? Das klingt nach einer > sehr akademischen Modulation bzw. Verarbeitung. > Als Modulationsverfahren soll FSK verwendet werden mit 2 oder 4 Frequenzen im Bereich 1-3 kHz. Eine sinnvolle Abtastrate beträgt mindestens das 4-fache der oberen Grenzfrequenz. Natürlich könnte man auch knapp über Nyquist abtasten, aber dann wäre ein sehr steilflankiger analoger Tiefpass als Anti-Aliasing-Filter nötig. Nach der Abstastung wird die Bandbreite dann mittels Digitalfilter reduziert. Im speziellen Fall ist das Signal von starken Störungen überlagert, z.B. durch Schaltimpulse angeschlossener Verbraucher oder von DC-DC-Wandlern. Eine simple Demodulation durch Nulldurchgangzählen scheidet also hier aus. >>so dass 8bit µCs an ihre Grenzen stossen, vor allem wegen der >>sehr langsamen Multiplikation. > > Wieso? Ein AVR macht eine 8x8 Bit Multiplikation in 2 Takten. Man wird > wohl kaum mit Fließkomma arbeiten wollen/müssen. > 16x16->32 bit sollte es schon sein. Das lässt sich zwar im Prinzip aus 4 8x8 Multiplikationen und einigen Additionen zusammenbauen, wirklich effizient ist das aber nicht mehr, insbesondere, wenn vorzeichenbehaftete Zahlen multipliziert werden. >>Das wichtigste Kriterium ist neben dem Preis der Energieverbrauch, der >>µC sollte schaltbare Taktfrequenzen haben und über einen Schlafmodus >>verfügen, > > Das haben heute fast alle. Als möglicher µC käme noch die MSP430-Serie in Frage, die eine 16x16-> 32bit Multipliaktionseinheit mit MAC-Akkumulator und Sättigungslogik enthält.
>300 bps schafft selbst ein Mega8! Hier gibt es ein Beispiel: https://github.com/arms22/SoftModem läuft aber mit 1225 BPS FSK.
ChrisMicro schrieb: > Hier gibt es ein Beispiel: > > https://github.com/arms22/SoftModem > > läuft aber mit 1225 BPS FSK. Der Code scheint aber nur eine einfache Frequenzmessung über Periodenzähler zu machen. Irgendeine digitale Filterung kann ich nicht erkennen. Für kurze dedizierte Leitungen ist das OK. In meiner Anwendung wäre das nicht zielführend, da auf der Leitung neben der Kommunikation auch noch die Versorgungsspannung übertragen wird und die Störsignale in der gleichen Größenordnung wie die Signalamplituden liegen. Der Algorithmus wurde auf einer simulierten Übertragungsstrecke mittels MATLAB bereits getestet.
Mike schrieb: >> Falk B. schrieb: >>>so dass 8bit µCs an ihre Grenzen stossen, vor allem wegen der >>>sehr langsamen Multiplikation. >> >> Wieso? Ein AVR macht eine 8x8 Bit Multiplikation in 2 Takten. Man wird >> wohl kaum mit Fließkomma arbeiten wollen/müssen. >> > 16x16->32 bit sollte es schon sein. Wozu? Hast du denn überhaupt 16 Bit Abtastwerte? > Das lässt sich zwar im Prinzip aus 4 > 8x8 Multiplikationen und einigen Additionen zusammenbauen, wirklich > effizient ist das aber nicht mehr, insbesondere, wenn > vorzeichenbehaftete Zahlen multipliziert werden. Und? Gibt es irgendwie Geld zurück für nichtverbrauchte Taktzyklen? Die Frage ist doch nur, ob es schnell genug ist. Das erscheint mir alles überhaupt nicht zielführend. Deine Anforderungen sind um (geschätzt) Faktor 10 überzogen. Wie kommt das? Willst du einfach nur deinen Arsch bedeckt halten? Wenn es nicht klappt, bist du wenigstens nicht daran schuld, zu kleine Hardware gewählt zu haben? Sonst mach es halt so wie man das immer macht, wenn man die Anforderungen nicht seriös abschätzen kann: bau einen Prototyp mit richtig fetter Hardware und skaliere den nachher runter.
>Der Code scheint aber nur eine einfache Frequenzmessung über >Periodenzähler zu machen. Irgendeine digitale Filterung kann ich nicht >erkennen. Hier gibt es ein anspruchsvolleres, was die Signalverarbeitung angeht: https://github.com/markqvist/MicroModemGP/blob/master/hardware/AFSK.c Letztendlich zeigen diese Projekte, dass es geht. Aber die Entwicklung war sicherlich nicht einfach, weil Signalverarbeitung im Audiobereich den AVR an seine Grenzen bringt und man immer Taktzyklen zählen muss. 32 Bit Prozessoren sind da schon deutlich bequemer.
Mike schrieb: >>>so dass 8bit µCs an ihre Grenzen stossen, vor allem wegen der >>>sehr langsamen Multiplikation. >> >> Wieso? Ein AVR macht eine 8x8 Bit Multiplikation in 2 Takten. Man wird >> wohl kaum mit Fließkomma arbeiten wollen/müssen. >> > 16x16->32 bit sollte es schon sein. Das lässt sich zwar im Prinzip aus 4 > 8x8 Multiplikationen und einigen Additionen zusammenbauen, wirklich > effizient ist das aber nicht mehr, insbesondere, wenn > vorzeichenbehaftete Zahlen multipliziert werden. Da reicht ein kleiner PIC24 locker aus. Fast ein beliebiger. Der kann 16x16bit in Hardware. Alternativ ein PIC32MM: http://www.microchip.com/wwwproducts/en/PIC32MM0032GPL020 Der schafft einen 16x32Multiply in einem Takt. Der kostet <1€ / Stück und ist sparsam. PS: Auch ich glaube, dass das ein 8-Bitter mühelos schaffen sollte. Aber warum überhaupt überlegen - schließlich ist ein AVR ist teurer als der genannte PIC32 oder ein STM32F051.
Mike schrieb: > Dennoch müssen Abtastraten im 10kHz-Bereich verarbeit > werden, so dass 8bit µCs an ihre Grenzen stossen, vor allem wegen der > sehr langsamen Multiplikation. Wie wäre es mit einem der neuen 18er PIC. Die haben Hardware-Multiplier, je nach Modell ADC / DAC, diverse Timer, nanoWatt, können bis 80 Mhz getaktet werden und die Programmierung insbesondere in ASM ist wesentlich einfacher als beim PIC32. Die DSP-Funktionen sollten doch auch in Software funktionieren und trotzdem wirst du den µC nicht auslasten. Alternativ ein PIC24, der hat 16bit Hardware-Multiplikation und mehr Speicher.
:
Bearbeitet durch User
Jens P. schrieb: > getaktet werden und die Programmierung insbesondere in ASM ist > wesentlich einfacher als beim PIC32. Die DSP-Funktionen sollten doch Der von mir genannte PIC32MM0032GPL020 kostet weniger als 1€. Um den Preis bekommt man kaum einen 8-Bitter mit gleicher Flash-Größe (32kB). Man muss also gleich viel oder mehr für den µC zahlen, bekommt aber weniger Leistung. Warum sollte das irgendjemand freiwillig tun? Der PIC32 sind in C nicht komplizierter zu programmieren als der PIC18. Das ist wie gewohnt bei Microchip, man kann durchaus das Datenblatt abtippen, Harmony ist nicht zwingend. Speziell bei den simplen PIC32. Für die Anwendung des TO wird der freie Compiler reichen, denke ich.
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.