Hi Leute,
ich habe einen Phase-shift-DCDC gebaut, der derzeit zum Regeln einen
UCC28950 verwendet (f=100kHz). Auf längere Sicht soll der aber durch
einen Microcontroller ersetzt werden.
Dh. der Controller sollte neben einem hochauflösenden PWM Modul (<20ns)
einen flotten ADC haben (>=1MSps, 10Bit), für die Slope Compensation
idealerweise noch einen Komparator und einen DAC (10bit, schneller als
0,5µs Settlingtime), ggf noch einen Blankingfilter. CAN wäre auch
wünschenswert.
Ich denke dass die CPU mit mindestens 50MIPS laufen sollte, mehr ist
natürlich besser.
Bisher habe ich als Kandidaten ausgemacht, die die Anforderungen mehr
oder minder erfüllen:
Freescale MC56F84789
TI C2000 Picolo Serie
Microchip dsPIC33FJ64GS608
Alternativ wäre sicher auch ein FPGA plus ADC/DAC, was ich eher ungerne
einsetzen wollen würde.
Hast jemand auf die schnelle noch andere Controller die die
Anforderungen erfüllen? Oder gibts nen anderen Hersteller der Controller
für den oben Beschriebenen Anwendungsfall interessant sein könnte?
Cheers
Stampede
Stampede schrieb:> Wenn ich das richtig sehe kann der keine Phase-shift PWM, und das ist> ein absolutes muss.
Du könntest zwei Timer zeitversetzt, mit gleicher Frequenz laufen
lassen, und bei einem, durch kurzzeitiges erhöhen/verringern des
Endwertes, im CTC Modus, die Phase verändern.
Mit freundlichen Grüßen - Martin
Klar könnte man machen. Aber dann muss man Totzeiten etc. alles in
Software rechnen, und dann nehm ich mir lieber nen Controller der das
alles schon integriert hat als so ne gefrickelte Lösung.
War ja auch nur ein Vorschlag, für so gefrickelt halte ich das nicht,
einen kleinen Teil der, eh vorhandenen, Rechenleistung, dazu zu
benutzen, ein paar Bits, zum richtigen Zeitpunkt, in die richtige Lage
zu schubsen. Die Totzeiten macht der vorgeschlagene ATxmega in Hardware,
und bei einem ATmega, mit 2 Compare-Ausgängen pro Timer, ist das auch
nicht so wild. (OK, ich schreibe AVR-Assembler locker runter, ohne mich
durch Berge von Dokus zu wühlen.)
Mit freundlichen Grüßen - Martin
@Martin:
Ja, du wirst mir aber sicher Recht geben dass ein Controller, der das
alles schon in Hardware bietet, einfach sympathischer ist. Ich brauche
ja 4 PWMs für die H-Brücke plus 2 für den Gleichrichter.
Zudem ist es so, dass die o.g. Controller auch eine ADC Trigger-Logik
haben, die sich super mit den PWM Modulen kombinieren lässt für
Cycle-By-Cycle Current limit und die Slope-Compensation. Da gebe ich
einfach lieber 3€ mehr für den Controller aus und erspare mir den
zusätzlichen Softwareteil.
@Schneckenepilierer:
Da gibts ja tausende Typen. Vllt einen der für den o.g. Fall geeignet
wäre?
Besten Dank.
@Stampede:
Da hast Du durchaus Recht, wobei es die ADC Trigger-Logik auch bei
ATmega und ATXmega gibt, und beim Xmega sind die ADCs auch schnell
genug. Gute Sicherheits-, und Überwachungs-Mechanismen sind allerdings
nicht immer einfach zu realisieren, da können Spezial-Controller
natürlch mehr. Ohne sicher funktionierende Überwachung ist mir, bei
solchen Wandlern, auch nicht wohl. Ich sehe es halt, als Bastler, auch
als Herausforderung an, solche Sachen mit einem
Universal-Mikrocontroller, den ich gut kenne, zu machen.
Mit freundlichen Grüßen - Martin
Wenn du in der großen Auswahlbox "Comparator" und "DAC" auswählst,
bleiben nicht mehr so viele übrig, hauptsächlich STM32F3xx
Wenn's etwas mehr sein darf ;) STM32F334 mit 217ps PWM. Evt. kommst du
sogar mit dem 32-Pin-Gehäuse mit 0.8mm Pitch aus.
http://www.st.com/web/en/catalog/mmc/SC1169/SS1576/LN1820
Mit dem dsPIC33FJ64GS608 habe ich vor einiger Zeit einen 4-phasigen
Boost mit 125kHz realisiert. Neben der eigentlichen Regelung des
Schaltnetzteils hat der PIC auch haufenweise "Housekeeping",
Leistungsüberwachung und Fehlerüberwachung gemacht.
Was ich beim dsPIC etwas vermisst habe, ist eine interne
Slope-Compensation. Die musste ich mir extern an die
Spitzenstromregelung dranbasteln. Geht, aber die Picolos haben so etwas
wohl integriert.
Ich finde, dass sich die Entwicklung und das Debugging eines
Schaltnetzteils deutlich von einer "normalen" Controllerapplikation
unterscheidet. Normalerweise hast du deine Debugmöglichkeiten mit
Breakpoints und Einzelschritten. Bei einem Schaltnetzteil ist es
unmöglich, danach wieder in den Run-Modus zu wechseln, da jetzt die
Spannungen und Ströme alle nicht mehr dem Betriebszustand entsprechen.
Also stoppen, mal kurz eine Variable anzeigen/ändern, weiterlaufen ist
nicht. (Und beim dsPIC kommt noch dazu, dass die PWMs nach einem Stop eh
nicht mehr korrekt weiterlaufen. Merke: Versuche nie die Peripherie im
Einzelschrittmodus in Betrieb zu nehmen, da kommt nur Grütze bei raus.)
Wenn Du jetzt nicht drauf stehst, solche Debugfunktionalitäten selber zu
implementieren, solltest Du darauf achten, dass die Entwicklungsumgebung
so etwas mitbringt. Microchip macht das über die DMCI-Schnittstelle, da
kann man sich auch während der Laufzeit ganze Kurvenschriebe runterladen
- das fand ich extrem nützlich. Vermutlich wird das auch die Konkurrenz
haben, aber es schadet nicht, das vorher abzuklären.
Hallo,
danke für die Antworten, ich werde die STM32F3xx auch mal in Erwägung
ziehen.
@Florian:
>Was ich beim dsPIC etwas vermisst habe, ist eine interne>Slope-Compensation. Die musste ich mir extern an die>Spitzenstromregelung dranbasteln. Geht, aber die Picolos haben so etwas>wohl integriert.
Exakt, wobei ich das Gefühl habe, dass die Picolos die einzigen sind die
sowas integriert haben.
Wie hast du das extern gelöst? Eine analoge Rampe erzeugt und die dann
mit dem DAC als Triggerschwelle für den PWM Komparator benutzt oder wie
habe ich mir das vorzustellen?
Idealerweise würde ich die Slopekompensation auch gerne intern (im
Controller) haben. Es gibt ja scheinbar auch Möglichkeiten, die
Schaltschwelle in Software zu berechnen und den DAC zum Beginn eines
Zyklus entsprechend einstellen.
Leider müsste ich für den STM und den Piccolo eine komplette neue
Toolchain incl. Debugger organisieren. Bei dem dsPIC habe ich schon
zumindest mal einen ICD3 und viel Erfahrung mit MC.
Sonst hatte ich noch mit einen MPC5643L geliebäugelt, denn für die
MPC56xx habe ich auch schon ne Toolchain und nen Debugger...
Schwierige Entscheidung :P
Bei den STMs kannst du ein Discovery Boards als Debugger nutzen. Da ist
ein ST Link V2 drauf. Die Toolchain wäre dann die Frage. CoIDE (1.7.8)
tut es, aber ich weiß nicht ob es deine Anforderungen erfüllt.
Stampede schrieb:> Wie hast du das extern gelöst? Eine analoge Rampe erzeugt und die dann> mit dem DAC als Triggerschwelle für den PWM Komparator benutzt oder wie> habe ich mir das vorzustellen?
In der Tat, ich habe rein analog eine Rampe erzeugt und zum
Strommesssignal addiert. Das wurde dann dem Komparator zugeführt um die
PWM zu steuern.
> Idealerweise würde ich die Slopekompensation auch gerne intern (im> Controller) haben. Es gibt ja scheinbar auch Möglichkeiten, die> Schaltschwelle in Software zu berechnen und den DAC zum Beginn eines> Zyklus entsprechend einstellen.
Ja, aber die Methode die ich kenne erfordert eine Berechnung am Anfang
des PWM-Pulses jeder einzelnen Phase. Bei meinem 4-phasigen Design
bedeutet dies eine 500kHz-ISR - das ist recht sportlich. Vielleicht bei
meinem nächsten Design ;-)
> Ja, aber die Methode die ich kenne erfordert eine Berechnung am Anfang> des PWM-Pulses jeder einzelnen Phase. Bei meinem 4-phasigen Design> bedeutet dies eine 500kHz-ISR - das ist recht sportlich. Vielleicht bei> meinem nächsten Design ;-)
Ja, exakt. Die Berechnung muss natürlich für jeden Zyklus neu erfolgen.
Bei 100 bis 150kHz (die ich anvisiere) lässt sich das bei 50MIPS wohl
noch stemmen, allerdings auch schon sportlich. Vielleicht erzeuge ich
mir dann auch ne analoge Rampe als Backup falls die Rechenleistung nicht
ausreich :)
Es gibt bei den PICs welche:
dspic33ep64mc502
dspic33fj16gs502
würde ich aber nicht mehr verbauen, weil mir das Debuggen von den PICs
im gegensatz zu Cortex Mx zu nervig ist. Sonst sind das schöne Teile mit
genau solchen Hardwareeinheiten.
STM32F334 Cortex M4 (High-resolution Timer mit 217ps)
dem gibts auch als 32pin
LPC1549 Cortex M3 relativ neu aber verfügbar Timer auch über PLL
Freescale KE06 CortexM0+ 5V besonders robust
bei 48MHz ganz knapp über 20ns
Ich empfehle TI controller der Piccolo serie (TMS320F28027 und
aufwaerts).
Komfortabel zum debuggen, eigentlich alle notwendigen und benoetigten
Funktionen verfuegbar und vorallem recht robust gegen Stoerungen (z.B.
hohes di/dt im Burstmode Betrieb).
Hier steht ST (STM32F334) trotz hoeherer Performance und floating point
unit hinten an. Auch die TI PWM Aufloesung ist mit 150ps etwas hoeher
als die von ST, was in der DC-DC stage nie schadet. Zudem lassen sich
bei den Piccolos die ADC's besser verwalten, da den STM334 MCU's nur
eine ISR fuer beide ADC's und auch nur ein Register fuer die
umgewandelten Daten zur verfuegung stehen.
Die dsPICs (dsPIC33FJ64GS608) sind an sich auch nicht schlecht, haben
meiner Meinung nach jedoch gewisse Limitationen beim Debugging und auch
in der Signalverarbeitung, sind jedoch auch recht robust gegen
Stoerungen.
Ich bevorzuge stets TI Piccolo gefolgt von dsPIC falls keine zu
aufwaendigen Funktionen realisiert werden muessen oder evtl. Burstmode
verwendet werden soll (LLC) oder ST falls hohe Performance benoetigt
wird und Stoerfaktoren geringer ausfallen (HSFB) (hier dann dennoch auf
gutes Layout achten).
Hi Dom,
danke für deine Einschätzung. Ich habe in meinem aktuellen Prototypen
einen dsPIC33EP64GS506 verbaut, der bietet 70MIPS (kein CAN aber OK).
Grund war dass der so ziemlich alle Forderungen die ich habe erfüllt und
ich mich mit Microchip gut auskenne (und bereits einen ICD3 habe). Gut
gefällt mich auch die Tatsache, dass der volle 4 ADCs mit 12Bit
Auflösung und 3.25MSps mitbringt. Leider bietet die PWM "nur" 1.04ns
Auflösung.
Die bisherige Regelung mit 3p3z, einem PID und bissl weiterem Zeug
(Burstmode etc.) packt der auch ziemlich flott (3µs oder so). In Punkto
Rechenleistung ist der dsPIC also wirklich gut geeignet.
>Komfortabel zum debuggen, eigentlich alle notwendigen und benoetigten>Funktionen verfuegbar und vorallem recht robust gegen Stoerungen (z.B.>hohes di/dt im Burstmode Betrieb).>Hier steht ST (STM32F334) trotz hoeherer Performance und floating point>unit hinten an.
Woher stammen diese Erfahrungen? Hast du die Controller alle in einem
Design miteinander vergleichen können?
Ich habe eher das Problem, dass der Debugger wegen der Transienten
abschmiert, der Controller arbeitet aber problemlos weiter.
Grüße
Stampede
