Forum: Mikrocontroller und Digitale Elektronik Controller für DCDC Converter


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


Bewertung
0 lesenswert
nicht lesenswert
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

von Stampede (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Niemand?

von Stephan B. (matrixstorm)


Bewertung
0 lesenswert
nicht lesenswert
Atmel ATxmega128A3U ?

: Bearbeitet durch User
von Stampede (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Wenn ich das richtig sehe kann der keine Phase-shift PWM, und das ist 
ein absolutes muss.

von Martin S. (led_martin)


Bewertung
0 lesenswert
nicht lesenswert
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

von Stampede (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Schneckenepilierer (Gast)


Bewertung
0 lesenswert
nicht lesenswert
STM32F4?

von Martin S. (led_martin)


Bewertung
0 lesenswert
nicht lesenswert
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

von Stampede (Gast)


Bewertung
0 lesenswert
nicht lesenswert
@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.

von Martin S. (led_martin)


Bewertung
0 lesenswert
nicht lesenswert
@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

von Schaulus Tiger (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von Schaulus Tiger (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Natürlich, das dicke Ende kommt nach: der STM32F334 ist ein 
Stromfresser, der wird heiß. Aber dafür gibt's den bei Mouser ab 4 Euro.

von Florian V. (florianv)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Stampede (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von Schneckenepilierer (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Florian V. (florianv)


Bewertung
0 lesenswert
nicht lesenswert
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 ;-)

von Stampede (Gast)


Bewertung
0 lesenswert
nicht lesenswert
> 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 :)

von temp (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von Dom (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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).

von Stampede (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

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]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [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.