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
Wenn ich das richtig sehe kann der keine Phase-shift PWM, und das ist ein absolutes muss.
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
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.
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
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.