Hallo Leutz Leider habe ich so meine Probleme bei der Auswahl des richtigen µc für mein Projekt. Daher dachte ich mir ich poste die Anforderungen hier und vielleicht hat ja jmd einen Gedankenblitz, da wenn ich es richtig gesehen habe atmel und pic rausfallen. Anforderungen - Max 28 Pins ( hobbymäßig lötbares Format besser noch Dip) - 60-80 Mips - 1 Uart - 2 Analog Comparator - 5-6 Timer ( mind 1 mal 16bit besser wären alle 16bit) - 1 mal external interrupt - Spannungsversorgung 5-12 Volt - Ideal wäre als passende Programmiersprache avr-gcc optional: Ethernet Interrupt management Ist jmd. ein passender Controller eingefallen ? Habe Liste um Liste durchforstet und leider nixs gefunden. mfg Jan
60 - 80 Mips und DIP / DIL und 12V wird sich ziemlich gegenseitig ausschließen ... was von der Rechenleistung her noch hin kommt wäre der Propeller von Parallax, der hat aber praktisch keine Sonderfunktionen on board Dafür 8 Cores http://www.parallax.com/propeller/
Troll?? 5-12V Versorgung??? Die schnellen Designs gibts eher nur in 3,3V. Und nicht mehr in DIL. Schau dich mal bei st.com um.
Danke für die schnellen Antworten. @ H.joachim Seifert Auf st.com hab ich auch schonmal geschaut leider gibts dort die entsprechenden µc s nur in 100 Pin Packages. Die Spannung ist ja Prinzipiell egal die kann ich ja über die galvanische Trennung ( die brauch ich eh ) runterdrehen 3.3Volt sind demnach kein Problem. @ Fhutdhb Ufzjjuz Das ist schon praktisch sehr nah an dem was ich suche. 12V wären natürlich ideal da ich dann nicht mit Optokopplern für die Endstufen arbeiten müsste aber nicht unbedingt notwendig. Leider haben die wenn ich es beim schnellen drüberschauen richtig gesehen habe keine Hardwaretimer und die Programmiersprache sollte schon c sein. Assembler kann ich leider nicht. mfg Jan
Ich finde es äußerst fragwürdig, zunächst einen Versorgungsspannungs- bereich von 5V-12V als knallharte Anforderung aufzustellen und dann doch noch zurückzurudern. Die einzigen Prozessoren mit 12V, die mir auf Anhieb einfallen, sind Intel 8080 und Texas Instruments TMS 9900. Jedoch sind das keine Microcontroller, sondern Mikroprozessoren mit externem Speicher. Zudem benötigen beide Typen auch noch +5V und -5V. Die Erhältlichkeit ist auch eingeschränkt, ebenso wie die Rechenleistung von deutlich weniger als 1 MIPS. Dafür gibt es sie im DIL-Gehäuse. Die Anforderungen werden wesentlich besser von Aufsteckmodulen erfüllt, die es auch im DIL-kompatiblen Format gibt, z.B. die DIL/NetPC-Familie von SSV Embedded http://www.dilnetpc.com/ oder das ADuC7020-Miniboard im DIL40-Format: http://www.analog.com/en/evaluation-boards-kits/evaluation-boards-kits/resources/analog-microcontrollers/analog-microcontrollers/listing.html
>Auf st.com hab ich auch schonmal geschaut leider gibts dort die >entsprechenden µc s nur in 100 Pin Packages. Die STM32F10x gibt es ab 48 Pins !!!!!!!!!!!!!!!!!!!
Hallo, hast Du dir schon den dsPIC30F3013 angeschaut? http://ww1.microchip.com/downloads/en/DeviceDoc/70139C.pdf Der kommt Deinen Anforderungen schon ziemlich nahe. Gruß Anja
@Jan M. (Gast) >Anforderungen Schreib mal lieber, wofür du glaubst diese Parameter zu benötigen. Ne LED kann man mit deutlich weniger Power blinken lassen ;-) MFG Falk
Ich vermute mal Jan weiß nicht was man mit ein paar MIPS machen kann. Er soll mal seine konkrete Anwendung posten, aber 60 - 80 MIPS sind schon ne Menge.
@ Andreas Schweigstill Nunja vielleicht etwas unglücklich formuliert obwohl man natürlich nach bestimmten Sachen unterscheiden könnte. Ein zusätzlicher Timer ist schwer in einen µc einzulöten ;). Während eine 3,3 V Spannungsversorgung doch recht leicht zu realisieren ist. @ Anja (Gast) Du hast recht er kommt dem was ich suche schon sehr nahe. Leider nur 30 Mips und auch ein Timer zu wenig. @ Falk Brunner Nachdem ich mein Projekt mit der verstellbaren Zündung für 2-Zylindermotoren abgeschlossen habe würde ich dieses gerne um eine kennfeldgeregelte ergänzen. Die Einspritzventile brauchen schon mächtig Saft genau wie die Zündung( kurzer Ampere peak 6A 2*~1,5 ms lang ) @ Bastler (Gast) Da kann ich eigentlich schon nixs mehr zu sagen. Ich habe berechnet wieviele Mips ich brauche um bis in einen bestimmten Drehzahlbereich mit sämtlichen Funktionen arbeiten zu können. Daher weiß ich schon relativ genau was man mit so ein paar Mips machen kann. Die Sache ist nunmal zeitkritisch daher muss da schon ein bisl Rechenpower für Zzp, Einspritzung, Sync, Zündaussetzererkennung, Protokollfunktion, Pc-Interface usw. drinstecken. mfg Jan
@Jan M. (Gast) Schaue doch mal den Artikel an: http://www.mikrocontroller.net/articles/STM32 Damit müsstest Du hin kommen.
Zustimmung zu Beitrag #1666166. Warum wurde der gelöscht?
Sollte keine Beleidigung sein. Für eine Motorregelung benötigt man schon einiges. Hier sind halt einige Fragensteller unterwegs, so: "Hilfe! Betreibe meinen Controller mit 8MHz und meine LED flackert noch. Ich brauch mehr Power"
@ Jan M. (Gast) >kennfeldgeregelte ergänzen. Die Einspritzventile brauchen schon mächtig >Saft genau wie die Zündung( kurzer Ampere peak 6A 2*~1,5 ms lang ) Und was hat das mit der RECHENLEISTUNG des uC zu tun? >Da kann ich eigentlich schon nixs mehr zu sagen. Ich habe berechnet >wieviele Mips ich brauche um bis in einen bestimmten Drehzahlbereich mit >sämtlichen Funktionen arbeiten zu können. Tolle Aussage. ;-) "Ich weiß dass ich recht habe, sag dir aber nicht wieso". Kleiner Tip [Netiquette]]. Wenn du mal ein paar Zahlen auf den Tisch legst, kann man sinnvoll drüber reden. NEIN, 60 MIPS ist deutlich zu wenig Information. >genau was man mit so ein paar Mips machen kann. Die Sache ist nunmal >zeitkritisch daher muss da schon ein bisl Rechenpower für Zzp, WAS soll in WELCHER Zeit gemacht werden? >Einspritzung, Sync, Zündaussetzererkennung, Protokollfunktion, >Pc-Interface usw. drinstecken. Protokollfunktion und PC-Interface macht jeder 0815 Controller mit 100 kHz Takt. Auch hier gilt die goldene Regel. 90% der Rechenleistung werden in 10% des Prorgamms verbraucht. Diese 10% müssen optimiert werden. Der nur solide hingeschrieben. MFG Falk
Falk Brunner schrieb: >>kennfeldgeregelte ergänzen. Die Einspritzventile brauchen schon mächtig >>Saft genau wie die Zündung( kurzer Ampere peak 6A 2*~1,5 ms lang ) > > Und was hat das mit der RECHENLEISTUNG des uC zu tun? Das war nicht auf die Rechenleistung bezogen sondern auf meinen Wunsch mit einer Spannung von 5-12 Volt zu arbeiten. >>Da kann ich eigentlich schon nixs mehr zu sagen. Ich habe berechnet >>wieviele Mips ich brauche um bis in einen bestimmten Drehzahlbereich mit >>sämtlichen Funktionen arbeiten zu können. > > Tolle Aussage. ;-) > "Ich weiß dass ich recht habe, sag dir aber nicht wieso". > > Kleiner Tip [Netiquette]]. > > Wenn du mal ein paar Zahlen auf den Tisch legst, kann man sinnvoll > drüber reden. NEIN, 60 MIPS ist deutlich zu wenig Information. Ich wollte nur klar stellen das ich mir bei diesem Wert sicher bin ohne euch mit entsprechenden Werten zu langweilen. Die Rechnung welche ich da angestellt habe. Hier mein Ansatz: Ein Triggerrad mit 35 Zähnen wird an einem Hallgeber vorbeilaufen. In der Zeit zwischen den einzelnen Zähnen müssen natürlich alle berechnungen abgeschlossen werden. Bei einer Drehzahlfestigkeit von 12000 1/min ergibt sich eine Zeit von ca 139 µs zwischen den einzelnen Zähnen. In 139 µs muss eine Berechnung für ZZP und Einspritzzeit abgeschlossen sein sonst funkt mir ja wieder die interruptroutine dazwischen. Allenfalls könnte man für jede Berechnung 4 Zähne nehmen ist ja pragrammiertechnisch recht leicht zu lösen. Was in dem Fall lange braucht ist a) eine Division ( um von Grad zzp auf µs Verzuögerung zu kommen) das konnte ich durch verschieben << aber schon auf 40µs reduzieren. b) das loggen der Werte über Uart. Trotz 115k baud dauerts leider 40µs Beide Zeitwerte beziehen sich auf eine Taktrate von 20Mhz. >>genau was man mit so ein paar Mips machen kann. Die Sache ist nunmal >>zeitkritisch daher muss da schon ein bisl Rechenpower für Zzp, > > WAS soll in WELCHER Zeit gemacht werden? > >>Einspritzung, Sync, Zündaussetzererkennung, Protokollfunktion, >>Pc-Interface usw. drinstecken. > > Protokollfunktion und PC-Interface macht jeder 0815 Controller mit 100 > kHz Takt. > > Auch hier gilt die goldene Regel. 90% der Rechenleistung werden in 10% > des Prorgamms verbraucht. Diese 10% müssen optimiert werden. Der nur > solide hingeschrieben. Ich habe bisher keine Möglichkeit gefunden das Programm weiter zu optimieren und habe dies in einem Thread in diesem Forum auch schonmal gepostet. Daher bezieht sich dieser Thread nur auf die Hardware ohne das ich euch mit den Berechnungen langweilen möchte. mfg Jan
Jan schrieb: > In > der Zeit zwischen den einzelnen Zähnen müssen natürlich alle > berechnungen abgeschlossen werden. Warum? 35 Zähne? Warum muß man bei einer Umdrehung 35 mal den zzp berechnen? Für das was Du vor hast reiche 4 Zähne. Oder hast Du angst, das sich die Drehzahl in der Zeit ändert? Warum eine ungerade Zahl von Zähnen? Dein µC wird sich beim Rechnen freuen.
@Jan (Gast) >a) eine Division ( um von Grad zzp auf µs Verzuögerung zu kommen) > das konnte ich durch verschieben << aber schon auf 40µs reduzieren. Braucht man da WIRKLICH eine Divison? Denn der Drehwinkel in Grad ist genau wie Periodenauer ein "Zeitmass" und kein Frequenzmass. Ich tippe mal darauf, dass man nur eine Multiplikation mit Festkommaarithmetik braucht. >b) das loggen der Werte über Uart. Trotz 115k baud dauerts leider 40µs Der UART arbeitet alleine. Die CPU muss nur ein Byte in den Puffer schieben. Fettig. Aufwand 1 Takt. HuH! Soviel dazu. Und ich wette, dass man da noch einiges durch Knoff Hoff einsparen bzw. verbessern kann. >Ich habe bisher keine Möglichkeit gefunden das Programm weiter zu >optimieren und habe dies in einem Thread in diesem Forum auch schonmal >gepostet. Wo? >Daher bezieht sich dieser Thread nur auf die Hardware ohne das ich euch >mit den Berechnungen langweilen möchte. Probleme solltem möglichst im Gasamtzusammenhang betrachtet und gelöst werden. Es nützt nix, in den Porsche einen Turbo einzubauen, wenn man immer mit angezogener Handbremse fährt. . . ;-) MFG Falk
Jan schrieb: > Bei einer Drehzahlfestigkeit von 12000 1/min ergibt sich eine Zeit von > ca 139 µs zwischen den einzelnen Zähnen. In 139 µs muss eine Berechnung > für ZZP und Einspritzzeit abgeschlossen sein sonst funkt mir ja wieder > die interruptroutine dazwischen. Hallo Jan, offensichtlich benutzt Du einen falschen Ansatz: Mit einem normalen 80C166 ( 6-10 Mips) bzw. den Nachfolgern C167 bzw. ST10 werden bei 60-2 Zähnen und Drehzahlen bis 10000 RPM seit Jahren schon 6 Zylinder bedient. Zur Erfassung reicht eine gute CCP-Unit. (der dsPIC kann bis zu 4 aufeinanderfolgende Flanken ohne CPU-Zugriff puffern). Ein 16-Bitter wie der dsPIC schafft eine Division in 18 Takten was bei 30 MHz < 1 us ist. Demzufolge wären 30 MHz beim DSPIC ca 320 Mips Deines 20 MHz Prozessors. Die Einspritzdaten brauchtst Du ja nicht jedes mal zu rechnen, sondern nur kurz vor der tatsächlichen Einspritzung. Das kann auch ein paar Zähne vor der Einspritzung erfolgen. Die Drehzahl ändert sich ja hoffentlich nicht plötzlich stark zwischen 2 Zähnen. Die Ansteuerung von den Endstufen wurde zumindest auf der High-Side (auf der Low-Side reichen evtl auch LL-Fets) immer schon mit entsprechenden externen Pegelwandlern durchgeführt. Gruß Anja
...und BMW macht(e) das Motormanagement für 6-Zylinder in den 80ern auch schon mit den 68332 Controllern von Motorola (heute Freescale) mit einer Taktfrequenz von max. 16MHz, was bei diesen CISC Maschinchen Rechenleistungen deutlich im unteren einstelligen MIPS Bereich ergibt. Stichwort TPU. Ein etwas aktuellerer Chip z.B. aus der Power-QUICC Serie mit eTPU würde da heutzutage wahrscheinlich sogar in Basic programmiert Kreise drumrum ziehen :-))
Hi >> TPU >Was ist eine TPU? Es wird Zeit, das jemand eine Suchmaschine erfindet. MfG Spess
@ Alexander Schmidt (esko) Benutzerseite >> TPU >Was ist eine TPU? Time Processing Unit. Ein komplexer, programmierbarer Timer, quasi ICP, OCP und Zeugs in einem.
Angehängte Dateien:
-
TPU_-_Google-Suche.png
50 KB
Danke Falk spess53 schrieb: >>Was ist eine TPU? > Es wird Zeit, das jemand eine Suchmaschine erfindet. Die Ergebnisse siehe Anhang.
Hi
>Die Ergebnisse siehe Anhang.
Auch gurgeln will gelernt sein. Z.B. 'TPU µC'.
MfG Spess
Erstaunlich wie wenig manche wissen. Scheint aber im Leben nix auszumachen.
Hi @esko Übrigens hättest du an erster Stelle deiner Anforderungsliste 'automotive' anführen sollen. MfG Spess
spess53 schrieb: > @esko > Übrigens hättest du an erster Stelle deiner Anforderungsliste > 'automotive' anführen sollen. Ich habe übrigens nichts mit dem OP zu tun.
@ Abdul K. (ehydra) Benutzerseite >Erstaunlich wie wenig manche wissen. Scheint aber im Leben nix >auszumachen. Gesülze. TPU ist ja nun weiß Gott nix alltägliches, auch nicht im uC Bereich. Wenn man weiß wonach man suchen muss ist es IMMER einfach!
Hi
>Ich habe übrigens nichts mit dem OP zu tun.
Dann gebe ich es an Jan weiter.
MfG Spess
Falk Brunner schrieb: > Time Processing Unit. Ein komplexer, programmierbarer Timer, quasi ICP, > OCP und Zeugs in einem. Da hat jeder MC-Hersteller seinen eigenen Abkürzungsfimmel. Wenn man den MC nicht kennt, ist es schwer, die Abkürzungen zu deuten. Beim 8051 heißt das Ding z.B. PCA (Programmable Counter Array). Peter
Hmm, ich kenne jetzt den PCA nicht (v.a . weil mir 8051+Derivate nicht an's Netzteil kommen :-) ), aber ich wage mal zu behaupten, dass zwischen einem (generischen?) Timer-Array und einem ursprünglich auf Getriebe- und Zündfeldsteuerungen spezialisierten (mikroprogrammierbaren) Timing-Prozessor noch gewisse Unterschiede bestehen... ;-)
Stefan Wimmer schrieb: > Hmm, ich kenne jetzt den PCA nicht (v.a . weil mir 8051+Derivate nicht > an's Netzteil kommen :-) ), aber ich wage mal zu behaupten, dass > zwischen einem (generischen?) Timer-Array und einem ursprünglich auf > Getriebe- und Zündfeldsteuerungen spezialisierten > (mikroprogrammierbaren) Timing-Prozessor noch gewisse Unterschiede > bestehen... Kann gut sein, daß das PCA für Motorsteuerungen entwickelt wurde. Es enthält einen Timer und 5 Pins mit Registern. Man kann also ein Register als Inputcapture zur Synchronisation konfigurieren und die anderen 4 als Outputcompare für die 4 Zylinder als Zündzeitpunkt. Peter
Upps, ich hatte in meiner Aufstellung natürlich auch die aktuellen Automotive-Prozessoren von Micronas vergessen, die es auch in 12V-Ausführung gibt.
Falk Brunner schrieb: > @ Abdul K. (ehydra) Benutzerseite > >>Erstaunlich wie wenig manche wissen. Scheint aber im Leben nix >>auszumachen. > > Gesülze. TPU ist ja nun weiß Gott nix alltägliches, auch nicht im uC > Bereich. Wenn man weiß wonach man suchen muss ist es IMMER einfach! Schön. ICH zumindest kenne das alles, obwohl nie selbst benutzt. ICH bewege mich eben auf höherer Ebene. Da verliert man ja oft die Bodenhaftung ;-)
@ Abdul K. (ehydra) Benutzerseite >bewege mich eben auf höherer Ebene. Da verliert man ja oft die >Bodenhaftung ;-) Dann solltest du Manager werden. Scheinst dafür optimal qualifiziert zu sein . . .
man benötigt definitiv keine 60 mips für eine Motorsteuerung. Intelligente Programmierung und ein Atmega16 oder 32 machen das auch. Beispiele (ATMEGA 16/32, PIC usw) http://megasquirt.de/ - Motorsteuerung komplett, open source projekt 12V http://www.silent-hektik.com/ 12V http://k750.myluna.de/ Zündung digital, programmierbar (6V & 12V) Entscheidende Bereiche der Berechnungen während des Betriebes werden vorberechnet und in Tabellen bzw. mehrdimensionalen Arrays gespeichert. Fließkommakrempel gehört in die Zeitkritischen Bereiche nicht hinein. Eine einfache Zünkennlinienberechnung inklusive Überwachung und Schnickschnack dauert dann maximal 240 ns. Je nach Auflösung des Timers und der Taktrate kannst du damit bis 20.000 1/min steuern. Das ganze mit 16-20 Mips (der Atmega32 lässt sich beispielsweise dauerhaft und stabil mit 20 Mhz betreiben falls notwendig)
Falk Brunner schrieb: > @ Abdul K. (ehydra) Benutzerseite > >>bewege mich eben auf höherer Ebene. Da verliert man ja oft die >>Bodenhaftung ;-) > > Dann solltest du Manager werden. Scheinst dafür optimal qualifiziert zu > sein . . . Alter, das bin ich doch schon manchmal.
@ horst (Gast) Das eine einzelne Projekt ( nur Zündung keine Einspritzung) arbeitet mit einem Atmel Kontroller. Die beiden anderen benutzen µc´s mit Hardwaredivider und schon etwas mehr Power und das sind auch keine 8-bit µc mehr. Da ich nunmal zusätzlich Sachen wie schon oben erwähnt loggen möchte und noch etwas Platz lassen will für z.B. Laptrigger LCD Display und Auspuff/Öltempsensor möchte ich einen etwas stärkeren µc benutzen. Meine jetzige Zündung (Einzylinder) funktioniert auch mit einem Atmel 20 Mhz und braucht 89 µs für die Berechnung des Zündzeitpunkts. Das geht natürlich mit einem 32bit-µc mit Hardware-Multiplikator schon besser. Vor allem weil ich zwei Zündzeitpunkte und Einspritzzeiten errechnen muss ( V-Motor). Moderne Bosch Steuergeräte benutzen einen ähnlichen Algorithmus und haben auch Chips drin die Fließkommaberechnungen machen. Ne einfache Division dauert ja bei nem Chip mit Hardware Multiplier auch net lange. Der Attiny2313 mit dem ich das im moment mache brauch leider 800 Ticks. @ faustian (Gast) Der ist für meine Anforderungen leider völlig ungeeignet. @ Anja Du hast schon recht mit deiner Aussage das meine Mips angabe etwas zu großzügig ist. Ich möchte aber auch net alle 3 Wochen ne Platine fertigen lassen daher hab ich ein paar Reserven eingeplant. Außerdem soll meine Zündung bis mind 16000 Umdrehungen funktionieren und auch noch andere späße enthalten als eine einfache V6 Zündung @ Markus Müller (mmvisual) Das ist schon fast der perfekte µc leider hat er einen Timer zu wenig( da könnte ich ja den großen Bruder nehmen) und kein Eprom. Das wäre mir aber schon sehr wichtig da ich Einspritzmenge und ZZp im laufenden Betrieb anpassen möchte(und sie sollen nach ausschalten der Spannung natürlich erhalten bleiben). Hat dieser Kontroller etwas vergleichbares ? ( hab nixs gefunden ) @ MarioT (Gast) Da hast du was falsch Verstanden damit mir der Uc nicht mit einem Interrupt dazwischenfunkt und mir das Temp-Register verwurschtelt wollte ich das zwischen zwei Zähnen die Berechnung abgeschlossen ist bei eimen 32-Bitter ist das etwas anders wenn ich mich nicht irre. Der Wert wird natürlich nur einmal pro Umdrehung berechnet. mfg Jan
Angehängte Dateien:
-
CIMG0722__640x480_.JPG
20 KB
Die Zähne sind so angeordnet als wären es 36 aber einer fehlt. siehe Bild mfg Jan
Der STM32F103RC hat 8 Timer. Ja, der Controller hat was vergleichbares. - das Flash - Backup-Register (16 Worte) (über VBatt mit Goldcap / Auto-Batterie) Oder was externes: - EEPROM 24LC256 oder so über I²C-Bus. Falls technische Unterstützung erwünscht wird, kann ich gerne aushelfen. Einfach mir ein Mail schreiben.
Werf mal einen Blick auf Cypress PSoC. Insbesondere die neuen Typen PSoC3 und 5. Da hast du eine Mischung Controller, FPGA und Analogtechnik. Vergleichbares gibt es nicht.
Hallo Jan, Jan M. schrieb: > Meine jetzige Zündung (Einzylinder) funktioniert auch mit einem Atmel 20 > Mhz und braucht 89 µs für die Berechnung des Zündzeitpunkts. > Das geht natürlich mit einem 32bit-µc mit Hardware-Multiplikator schon > besser. > Vor allem weil ich zwei Zündzeitpunkte und Einspritzzeiten errechnen > muss ( V-Motor). 89 µs sind ein guter Wert, wobei das natürlich von der Art der Berechnung abhängig ist. Eine Echtzeitberechnung (also nicht nur Tabellenabfrage) dauert selbst auf einem Atmega maximal 150-240 µs. Bei 8000 1/min dauert ja eine Kurbelwellenumdrehung 7,52 ms, d.h. selbst bei dieser Zeitspanne ist die Berechnung bereits weit vor dem nächsten Impuls abgeschlossen. Insofern also völlig ausreichend und genügend Zeit zum Däumchendrehen bei maximal 2 Zylindern. Die Maximale Drehzahl wird ja eigentlich nur durch die Auflösung des Timers begrenzt. Die ist ja bekanntlich entscheidend, wenn man die benötigte Zeit für eine Umdrehung mit den 360 Grad ins Verhältnis setzt. Lässt sich die Umdrehungszeit nicht in möglichst kleine "Ticks" teilen, kann man auch keinen genauen Einspritz-/Zündzeitpunkt berechnen. Ich gebe dir vollkommen Recht, dass für deine spezielle Anforderung und der hohen Drehzahl hier ein einzelner 8-Bitter zu lahm ist. Mit einem 16 Bitter ist das aber locker zu machen. Ich würde dazu auch lieber zwei getrennte Prozessoren verwenden als nur Einen der alles erledigt. Ich könnte mir vorstellen, dass der Aufwand zur Kalibrierung insbesondere der einzelnen Code-Segmente zueinander aufwändiger sind als wenn man es Modular aufbaut (siehe Kraftfahrzeug-Steuergeräte). Grüße, Horst
Nachtrag:
Für eine Steuerung an russischen V8-Motoren (wie amerikanische
aufgebaut) mit mehreren Atmega 32 trug übrigens der Entwickler der
letzten genannten Zündung oben die Idee bei, die Berechnung und die
Ausführung auf eine kuriose Art komplett voneinander zu trennen
("Meister und Geselle"): Ein Prozessor führt die Berechnungen aus
(Meister) und ein Weiterer setzt nur die Signale für die Endstufen um
(Geselle).
Da die Atmegas zu langsam waren um die geforderten Werte an den jeweilig
untergeordneten Prozessor seriell zu übermitteln, wurden die Koordinaten
einer Matrix per ADC-Signal XYZ an drei Ports gesetzt (jeweils Werte
0-1023). So musste der "Geselle" nur simple Arrayzugriffe auf die
Kennlinien/Kennfelder durchführen. Dazu kommt, dass die Berechnung
bestimmter Werte im übergeordneten Prozessor dann auch länger als eine
Umdrehung dauern können, da die Signale ja analog gehalten wurden.
Lustig dabei ist, das bei Absturz des "Meisters (besoffen)" der Motor
weiterläuft.
Klasse Idee wie ich finde :)
@ Markus Müller >Der STM32F103RC hat 8 Timer. > >Ja, der Controller hat was vergleichbares. > >- das Flash >- Backup-Register (16 Worte) (über VBatt mit Goldcap / Auto-Batterie) >Oder was externes: >- EEPROM 24LC256 oder so über I²C-Bus. > >Falls technische Unterstützung erwünscht wird, kann ich gerne aushelfen. >Einfach mir ein Mail schreiben. Der Stm32F103RC hat 8 timer das ist schon richtig davon entfallen aber -Watchdog -Systick Timer -Motorsteuerung Wenn ich das richtig verstanden habe haben diese Timer kein richtigen Compare interrupt Außerdem hab ich gar net gefunden ob der nen externen Interrupt hat. ( in der main Schleife abfragen geht auch find ich aber sehr unelegant) Alles in allem befürchte ich ich würde mich mit diesem Prozessor etwas übernehmen, da die Programmierung doch schon etwas anders ist als die der Atmels. Außerdem hat dieses Teil einen Timer ( 4 mit Compare einstellbaren Prescaler usw.) zu wenig und kein EEprom. Aus dem fehlenden timer ergibt sich rechnerisch eine maximale Drehzahl von ca 11000 rpm, wenn ich meine zylinderselektive Einspritzung realisieren möchte. Klar die externe Lösung ist auch super, aber hier würde ich glaub ich Programmiertechnisch verzweifeln. Zusätzlich hab ich auch noch das Problem das ich diesen µc nicht selbst löten kann. Die fertigung von Prototypen (mit bestücken) find ich recht teuer ( genauer Preis ka ich rechne so mit 80 €) Jetzt hab ich aber nur negative Sachen erwähnt, dass möchte ich auch nicht, da der Stm µc schon einer der letzten beiden ist, die ich zur Auswahl stehen. -Massenhaft Platz im Flash -richtig Power -Viele Pins -viele a/d wandler -32Bit erlauben eine echt entspannte Programmierung, da man die Auflösung stark erhöhen kann ohne das er mit Tempregistern usw rechnen muss. -Usb Onboard ist natürlich auch nett allgemein im Prinzip ein Hammerteil für so einen Technikfreak wie mich ;) @Abdul K. >Werf mal einen Blick auf Cypress PSoC. Insbesondere die neuen Typen >PSoC3 und 5. >Da hast du eine Mischung Controller, FPGA und Analogtechnik. >Vergleichbares gibt es nicht. Wenn ich das in dieser etwas unübersichtlichen Doku gesehen hab passt leider net ( Anzahl der timer usw ). @Horst (Gast) Mal abgesehen davon das ich Ami Motoren net mag ( die brauchen 4l Hubraum für 300 Ps tztztz ) hängt dieses Prinzip wohl mit der Tatsache zusammen, dass bei einem Motor mit so vielen schaltbaren Elementen die Berechnungen auf dem Chip einfach so lange brauchen, dass sie in 1 Umdrehung bei Volllast nicht abgeschlossen sind. Aktuelle Steuergeräte berechnen so viel ich weiß auch auf 2 verschiedenen Chips, aber sie berechnen beide dasselbe ( aus Sicherheitsgründen) und vergleichen das Endergebniss. Aufgrund der Tatsache die zu dieser Entwicklung geführt hat ( zu wenig Rechenpower) bin ich ja hier auf der Suche nach anderen µc. Was auch in der heutigen Zeit kein Problem ist. Vielen dank für die Vorschläge die ihr hier macht. Ich möchte auch keinen Vorschlag runtermachen und bitte zu entschuldigen falls es den Anschein macht. Ich wäge nur pro und contra ab. Im Laufe dieser Diskussion bin ich allerdings darauf gekommen das 50-60 Mips schon etwas sehr hoch gegriffen ist wenn man bedenkt, dass es doch auf einer 16 bzw 32 bit Platform mit Hardware Multiplikator und Dsp unit ehrheblicher schneller geht als hier mit meinem 8-bit Risc attiny2313 ohne dsp. Der braucht für eine Berechnung meines ZZP 800 Takte. Zu der Sache mit den Timern. Es sollten schon möglichst 5 sein. 1* 16-bit für die Drehzahlerfassung 2* 8 oder 16bit für die Zündspulen ( 2 an der Zahl und die Ladezeiten überschneiden sich wenn man kein Signal von der Nockenwelle aufnehmen kann). 2* 8 oder 16 bit Einspritzzeit ( Zylinderselektiv wegen der Verwirbelung des Kraftstoffs im Ansaugbereich) Der Motor rappelt schon genug Wenn ich jetzt ein Signal der Nockenwelle aufnehmen könnte wäre das Problem natürlich gelöst weil ich dann nur alle 2 Umdrehungen zünden und einspritzen müsste ) In meinem Fall leider unmöglich ist nur ein OV Motor Nockenwelle ist unten. Es geht auch noch Softwareseitig in der mainschleife aber die möchte ich so klein wie möglich lassen. Hier soll nur abgefragt werden. -Befehle über comport/usb angekommen -Soll Zündspule eingeschaltet werden (Timer starten und Port schalten) -Soll Kraftstoff Eingespritzt werden (Timer starten und Port schalten) -Übertragen der Motordaten an den Laptop (gaaaannnnz später vielleicht mal per Funk) Diese beiden µc sind übriggeblieben was meint hier Links zu den Datenblättern. http://ww1.microchip.com/downloads/en/devicedoc/70135C.pdf Ein paar Argumente -leider nur 16 bit -was sind denn 4 s/h inputs steht unten rechts Seite 3 bei den A/D wandler -Hardware Division und Multiplikation kann er wenn ich das richtig gelesen habe http://www.st.com/stonline/products/literature/ds/14611/stm32f103rc.pdf Ein paar Argumente -32 bit -nicht selber lötbar. Ich kann es zumindest nicht. -leider nur 4 Timer -LCD treiber on board Was meint ihr ?? mfg Jan p.s. Ich hab mich mal registriert ^^ das Jan M. am Anfang war ein tippfehler
Angehängte Dateien:
-
Dsc02552.jpg
110 KB
Hallo Jan, Mit den Timern muss ich was klar stellen. Der STM32F103RC hat: - 8 Timer (davon 2 nicht nach aussen geführt) (natürlich mit Compare-ISR) - 2 Watchdog-Timer, einer mit Window-Mode - 1 Systick Timer - 1 RTC Timer Wenn man so rechnen würde, dann hätte er 12 Stück. Alle IO-Pins können als Interrupt-Quelle gemapt werden. Man muss aber schon aufpassen weche Pins man nimmt, nicht dass dann der gleiche Interrupt ausgelöst wird. Also diese Pins werden, konfigurierbar Falled/Rised auf 7 Interrupts verodert. (Natürlich für jeden Pin parametrierbar) Mit dem dsPIC30 machen Sie sich nur unglücklich. Ich spreche aus Erfahrung. Ich schreibe von meinem Projekt: Ich musste einmal eine Schaltung entwickeln, die ein PWM für einen Magnetmotor und einem LVDT Wegaufnehmer für Stellung (+/- 1mm). Der PWM muss mit 10KHz laufen, so auch der Messaufnehmer. Ich musste bei jeder Halbwelle messen (alle 50 uS) wurde ein Spitzenwertgleichrichter abgefragt (AD-Wandlung), dann musste ich für 5us den Kondensator den Spitzenwertgleichrichters entladen. Das war ein komplexes Zusammenspiel aus Externen Interrupt, AD-Wandlung/Interrupt und Timer/Interrupt (Entladepuls). Dazwischen natürlich einen PID Regler für den Sollwert des PWM's. Das erste mal hatte ich das versucht mit einem dsPIC30F5011. Nach den ersten Versuchen wurde schnell kar, die CPU muss weg. Sie war einfach zu schwach. Ausserdem wurde die so Heiß, dass die fast noch gekühlt werden musste. Jetzt läuft in der Schaltung ein STM32, getaktet mit 48MHz, ganz gemütlich. Selbst sogar die Parametrierung über USB parallel zum Betrieb bereitet keine Probleme. Ausserdem: Bei den PICs ist es so, wenn man ein anderes Derivat einsetzen möchte, dann ist dort irgend eine Pheriperie anders, also das Programm ist nicht sonderlich leicht portierbar auf andere PICs. Die FW-Lib von ST ist wirklich sehr einfach an zu wenden. Es gibt sehr viele Demos, alle basierend auf diese eine FW-Lib. Bei Microchip gibt es zwar auch viele Demos, die aber zusammen zu bringen in das eigene Projekt ist fast so wie ein Kunstwerk, in jedem Fall viel aufwändiger. Dann bleibt nur noch der Nachteil internes EEPROM, dafür gibt es als Ersatz die Backup Register. Damit hätte man 16 x 16 Bit zur Verfügung. Diese halten ihren Wert so lange am Vbatt Pin Strom anliegt (via GoldCap oder Batterie oder geladen von der 12V Autobatterie). Der Vorteil des Backup-Register, man kann die so oft beschreiben wie man will. Den STM32 kann man von Hand löten. Anbei ein Foto meiner letzten Schaltung, selbst gelötet. So geht das: - Man nehme einen Lötkolben, nicht zu Schwach auf der Brust, 380°C und 1,5mm Lötzinn - Den Chip plazieren und an einer Ecke etwas löten - die Ecke gegenüber löten - Wenn der richtig plaziert ist alle Pins komplett mit Lötzinn eindecken. Ist ein dicker Kurzschluss, aber egal. Immer wieder pause machen, dass der Chip nicht zu heiß wird. - Jetzt mit Entlötsauglitze alle 3-4mm das Lötzinn wieder entfernen. (Kurze Pause wegen der Hitze machen) - Mit Lupe überprüfen. - Wenn noch Lötzinn-Reste dazwischen sind, nochmals neuen Lötzinn dran geben und mit Entlötsauglitze wieder weg machen. So geht ein defekter Chip wieder raus, ohne die Platine zu beschädigen: - Scharfes Tapeziermesser, Zange - Mit dem Tapeziermesser direkt am Gehäuse die Pins abtrennen, die Zange zum leichten klopfen auf das Messer verwenden. Aber nur die Pins gerade so getrennt sind, nicht zu tief schlagen. - Nun fällt das schwarze quadrat raus und ist zum wegwerfen. - jetzt mit einem Lötkolben die Pins weglöten - die Platine bleibt ganz - Klappt auch wenn man den Chip 2 oder 3 mal zerschießt und tauschen muss Wenn du mir ein mail schreibst können wir auch mal telefonieren um offene Punkte zu klären...
Für so ne Echtzeitgeschichte würde ich ein FPGA nehmen. Dort kann man das alles mühelos und mit minimalem Takt erledigen. Denn letztendlich sind die Berechnungen nicht allzu komplex, nur das Timing ist halt recht eng. Eine kleine Soft-CPU erledigt dann die Kommunikation zum PC/Whatever. Das kann man dann auf ein paar wenigen MHz takten, der parallelen Logik sei Dank. MFG Falk
Jan B. schrieb: > hängt dieses Prinzip wohl mit der Tatsache > zusammen, dass bei einem Motor mit so vielen schaltbaren Elementen die > Berechnungen auf dem Chip einfach so lange brauchen, dass sie in 1 > Umdrehung bei Volllast nicht abgeschlossen sind. du würdest staunen, reicht vollkommen aus, Berechnung wird vollständig abgeschlossen (locker bis 8000 1/min). Keine schlechte Leistung für die kleinen Atmega finde ich. > Es geht auch noch Softwareseitig in der > mainschleife aber die möchte ich so klein wie möglich lassen. > Hier soll nur abgefragt werden. Bloß nicht pollen in der Mainschleife, aber drin stehen darf da schon Einiges, da die Interrupts und Timer bevorzugt behandelt werden und die Main unterbrechen. > -Befehle über comport/usb angekommen > -Soll Zündspule eingeschaltet werden (Timer starten und Port schalten) > -Soll Kraftstoff Eingespritzt werden (Timer starten und Port schalten) > -Übertragen der Motordaten an den Laptop (gaaaannnnz später vielleicht > mal per Funk) > > Diese beiden µc sind übriggeblieben was meint hier > Links zu den Datenblättern. Ich kann mich meinem Vorredner nur anschließen. Der STM32 ist eine gute Wahl und völlig ausreichen für diese Art Steuerung. Dennoch würde ich Einspritzung und Zündung voneinander trennen. Das birgt eigentlich nur Vorteile.
@ Markus Müller (mmvisual) >Was kostet denn eine FPGA Entwicklungsumgebung? Die Software? Gar nichts, gibt es bei den Herstellern frei. Sicher nicht für alle und die größten FPGAs, aber für die Mittelklasse reicht es allemal. >Ich meine, gibt es OpenSource oder so? Nö. Weil zumindest die Backend Tools immer herstellerspezifisch sind. Und damit gut gehütete Firmengeheimnisse. Los, jetzt darf die Open Source Gemeinde darüber jammern und wehklagen ;-) MfG Falk
Mit FPGA hatte ich noch nichts gemacht. Allerdings hatte ich auch noch kein Anwendungsfall, in dem ich solch ein Chip hätte gebrauchen können. Was würde denn ein FPGA Chip kosten mit ca. 50-60 IO's und auf der man eine CPU mit laufen lassen kann?
@ Markus Müller (mmvisual) >Mit FPGA hatte ich noch nichts gemacht. Allerdings hatte ich auch noch >kein Anwendungsfall, in dem ich solch ein Chip hätte gebrauchen können. Das weißt du erst dann, wenn du weißt was ein FPGA kann (und was es nicht kann). >Was würde denn ein FPGA Chip kosten mit ca. 50-60 IO's und auf der man >eine CPU mit laufen lassen kann? Hausnummer: 10 EUR. So ne CPU im FPGA ist schick und hipp, ist aber bei knallharter Berechnung um EINIGES teurer als ein echter uC. Vor allem der Programmspeicher. Der ist im FPGA als superschneller, aber auch teurer SRAM ausgeführt. Der kann zwar 200MHz++, wird man so aber nicht direkt nutzen können. Und mal fix 64kB oder mehr Speicher im FPGA für den Soft-Core. Uuuups, war wohl nix (bezahlbares). http://www.mikrocontroller.net/articles/Kategorie:FPGA_und_Co FPGA Soft Core Picoblaze ist sehr niedlich und effizient. Microblaze, naja, kenn ich nicht wirklich aus der Praxis. Gefühlt würde ich aber das oben Gesagte hier ansetzen. Ein echter 32Bit uC ist billiger. IMO kommt ein FPGA meist in Verbindung mit einem uC voll zur Geltung. Der FPGA macht die zeitkritischen Sachen, Bitklimpern, Daten schaufeln etc. Der uC die Verwaltung, komplexen Abläufe (TCP/IP etc.). MFG Falk
Der STM32F103RC kostet 5,04 (500 St. bei Farnell, bei anderen Distris nach Verhandlung sicher günstiger) Jan möchte gerne ein bischen rechen und weniger Bitklimpern. Ist da nicht eine "echte" CPU besser? Ja, natürlich kann das auch ein FPGA, aber ich meine ist für Jan schlussendlich die "echte" CPU nicht die bessere Wahl anhand seiner Beschreibung der Anforderungen?
...Du solltest Dich wirklich mal in Freesales eTPU einlesen. Die wurde genau für sowas entworfen und macht z.B. eine missing-tooth Erkennung ganz ohne CPU-Last.
Stefan Wimmer schrieb: > ...Du solltest Dich wirklich mal in Freesales eTPU einlesen. Die wurde > genau für sowas entworfen und macht z.B. eine missing-tooth Erkennung > ganz ohne CPU-Last. Im Prinzip genau das richtige für die Entwicklung eines Steuergeräts. Da die Routinen bereits vorgegeben sind hab ich ja gar nixs mehr zu tun.^^ Mal abgesehen davon, dass ich soviele Sensoren überhaupt nicht habe fände ich es sehr Schade wenn ich meine in stundenlanger Arbeit erstellten Routinen jetzt wegwerfen müsste, obwohl sie genau auf diesen Motor zugeschnitten sind. Die kmpl. Routine Erkennung der Drehzahl und Erkennung von OT würde denke ich auf einer 32-Bit MCU ca 3-5 Ticks dauern. Das kann ich verschmerzen. @ Markus Müller Ich habe hier das Datenblatt für STM32F103xC/xD/xE Serie vor mir und sehe nur 4 allgemeine Timer auf dem µc. Bin ich blind ?? Warum gibts eigentlich soviele verschiedene STM32F103RCSPS STM32F103RCT6 STM32F103RCT6TR usw von den Daten her erkenne ich gar keine Unterschiede mfg jan
Hallo Jan, Siehe http://www.mikrocontroller.net/articles/STM32 Unter Features habe ich eine Grafik von genau dieser CPU eingebunden. (Kommt aus dem Datenblatt "STM32F103xC-D-E.pdf" Seite 12. Auf dem linken Bus APB2 ist der Timer TIM1 und TIM8. Auf dem rechten Bus APB1 ist der Timer TIM2, TIM3, TIM4, TIM5, TIM6, TIM7. Auf dem rechten Bus APB1 ist auch der RTC Timer und der Watchdog IWDG und WWDG. Der Systick-Timer ist bestandteil der CPU Cortex-M3 und nicht separat in diesem Schaubild aufgeführt. (Alle Cortex M3 CPUs haben das.) Die Varianten sind in dem Typschlüssel auf Seite 117 (von "STM32F103xC-D-E.pdf") gezeigt. - SPS muss eine spezieller vorprogrammierter Typ sein - T6 = LQFP, Temperaturbereich bis 85°C - T6TR = LQFP, Temperaturbereich bis 85°C in der Verpackung Tape&Real - T7 = LQFP, Temperaturbereich bis 125°C
Jan B. schrieb: > Ich habe hier das Datenblatt für STM32F103xC/xD/xE Serie vor mir und > sehe nur 4 allgemeine Timer auf dem µc. > Bin ich blind ?? Es gibt Timer mit unterschiedlicher Funktionalität. Wenn man alle Timer ohne direkte externe Funktion abzieht bleiben bei den xC/D/E Devices 6 Timer übrig, alle 6 mit 4fach PWM und Capture-Funktion, 2 davon mit erweiterter PWM-Funktion für Motorsteuerung. Man benötigt vielleicht auch nicht für jede Capture oder PWM-Funktion einen eigenen Timer. Manches lässt sich möglicherweise auch in den pro Timer 4fach vorhandenen Capture/PWM-Kanälen eines einzigen Timers zusammenfassen.
Oh sry Markus Müller da hab ich wohl net richtig im Datenblatt geschaut. Mal gucken ob ich das richtig verstehe Also wenn ich jetzt den St32F103RC nehmen möchte nehme ich für den Temperaturbereich -40 bis 85 °C im Package LQFP ( die anderen sind ja net lötbar mit nem Lötkolben) Mit diesem Beitrag "STM32 Programmiertool" Programmer die gibts ja auch fertig für ca39,95€ zu kaufen. Können dann natürlich nur über den integrierten Bootloader programmieren ( muss es dann ordertyp sps sein?) STM32 F 103 R C T 6 SPS ( oder besser STM32 F 103 R E T 6 SPS mehr Flash) Der wäre dann der entsprechende wenn ich die Verlustleistung richtig Interpretiert habe und ihn auf 32 Mhz laufen lasse müsste er ja dann schön kühl bleiben. Noch einmal zum Verständniss Also 4 Timer sind als freie Timer vorhanden die anderen beiden belegen ja die DAC Ports und die Motorports es existieren aber trotzdem ISR für diese ports für Compare Overflow ? Wie würdet ihr die Spannungsversorgung regulieren ? Ich dachte an zwei Festspannungsregler 3,3Volt mit einem mittleren ,einem kleinen Kondensator und eventuell ne Zenerdiode 3,3Volt zum Filtern der Störungen die durch einschalten der Zündspulen und Einspritzventile ins System kommen(Zündspule:periodisch ca 5-12 A //Einspritzventil: GESCHÄTZT 15 A PEAK und 5 A HOLD). Ich weiß ja net wie empfindlich der ST32 auf die Versorgungsspannung reagiert. Gibt es noch einen anderen guten Programmer der per JTag programmiert und über USB betrieben wird und den ihr empfehlen könnt ? ( Preisbereich ~50 €) http://www.segger.com/cms/flasher-arm.html der ist mir ins Auge gefallen kostet laut STM32 Seite hier auf mikrocontroller.net nur 60€ ? sieht teurer aus @ Falk Brunner (falk) Danke für den Hinweis mit den FPGA aber ich denke so Aktionen mit Softcore übersteigen meinen Horizont bei weitem. Es soll ja auch in absehbarer Zeit Erfolge zu verzeichnen geben, dass ich das Projekt wenn die Leute es möchten veröffentlichen kann.(und da hab ich beim ST32 schon befürchtugen wenn ich mir die Kommunikation mit dem RAM angucke) mfg jan p.s. Markus Müller ich hab dir mal Post geschrieben
... Ich habe berechnet wieviele Mips ich brauche um bis in einen bestimmten Drehzahlbereich mit sämtlichen Funktionen arbeiten zu können. ... Kannst du deine Berechnungen einmal posten, das Thema interessiert mich sehr.
Karlheinz schrieb: > ... Ich habe berechnet wieviele Mips ich brauche um bis in einen > bestimmten Drehzahlbereich mit sämtlichen Funktionen arbeiten zu können. > ... > > Kannst du deine Berechnungen einmal posten, das Thema interessiert mich > sehr. Puh das hab ich mir hier alles auf nem Schmierzettel aufgeschrieben. ;) Aber im laufe der Diskussion bin ich ja schon zurückgerudert, da die Kombination von DSP ( Hardware Multiplikation und Division die der ST32 beherrscht) und 32 bit schon einen erheblichen Performance boost gibt bei den Berechnungen. Ich kann dir das mal in Stickpunkten kurz aufschreiben. -Kommunikation von PC <-> Uc kompl mit der Änderung und dem senden von Kennfelddaten und ändern in Echtzeit bis zu der von mir gewünschten Drehzahl. -Berechnung von Einspritzzeitpunkt, Einspritzmenge -Berechnung von Zündzeitpunkt ( incl Lastverstellung ) -Berechnung der Kurbelwellenbeschleunigung ( Erkennung von Zündaussetzern) -Klopfkontrolle -Erfassung von Motorrelevanten daten wie Öldruck und evtl Auspufftemperatur alle ca 100 msec -ms genauer eingang für den Laptrigger ( induktionsschleife zur Messung der Rundenzeit) -Übertragung der Telemetriedaten per Funk -ca 10% Aufschlag für zukünftige Wahnsinnsideen und Zahlendreher meinerseits. -Anzeige der Daten auf einem LCD Display am Lenkrad Bevor ihr was sagt, mir ist schon klar das dass ein riesiges Projekt ist aber da es mein Hobby ist bin ich gerne bereit da Zeit zu investieren. Entwicklungen wie Laptrigger, Funk, LCD und Klopfkontrolle werden natürlich sehr lange bis zur Umsetzung brauchen, aber wenn die Hardware schonmal da ist, ist das ja net verkehrt. Rechtsschreibfehler könnter behalten ;) mfg Jan
Das "SPS" kenne ich nicht. Im Datenblatt ist davon nichts beschrieben. Hier ein Link zu Farnell: http://de.farnell.com/stmicroelectronics/stm32f103rct6/mcu-32bit-cortexm3-256k-flash-64lqfp/dp/1624136?Ntt=STM32F103RC Den habe ich auch in meinem Display im Einsatz. 256 KB Flash sollten völlig ausreichen, denn es kommt kein Grafikdisplay dran. (Das braucht viel Flash Speicher wegen der Schriftarten usw.) Mein Display lasse ich sogar nur mit 8MHz laufen und habe einen Main-Loop-Zähler, der 13000 Zyklen/Sek. zählt. Wenn ich die Kompiller Optimierungen aktivieren, dann erreiche ich sogar 19000 Zyk/Sek. Aber wie schnell Du Deine CPU einstellst ist abhängig von der Berechnung und die geforderte Zeit. Bei USB musst Du 48MHz oder 72MHz verwenden. Auch bei 48MHz wird die CPU nicht sonderlich warm. Ich verwende zu erst einen Spanngungsregler auf 5V, da einige Teile 5V benötigen, dann auf 3,3V. Der STM32 hat diverse ESD Schutzmaßnahmen eingebaut. Ich muss Sagen der läuft sehr stabil. ESD-Schutzbeschaltung bei solchen Störungen sind in jedem Fall zusätzlich zuempfehlen. von NXP gibt es einige Bauteile, die z.B. 4 IO Signale schützen und eine Z-Diode eingebaut haben. Hier gibts ein Schaltplan von einer Steuerung von mir: Beitrag "Re: Heizungssteurung im Eigenbau" Auch einige Schutzglieger überall drin. Als Programmer empfehle ich unbedingt ein JTAG Adapter. Seriell kann zwar auch ein fertiges Programm rein laden, aber bei Neuentwicklungen ist es schon nicht schlecht rein schauen zu können, was da für Werte wo stehen. Der Olimex ARM-USB-OCD http://olimex.com/dev/pdf/ARM-USB-OCD.pdf kostet ca. 60 EUR, den habe ich auch und der tut. Die kleinere Variante Tiny kostet 40 EUR, hat dafür keinen COM-Port (und hab ich nicht getestet). Der Preis des Segger Teiles mit 60 EUR hat ein anderer User in den Artikel geschrieben, in der Preisliste von Segger sehe ich immer nur 198 EUR (+ Gebühr für GDB Server). Vor 2 Jahren gab es von Segger eine Aktion 98 EUR für Privatanwender, den habe ich mir damals zugelegt. Der Segger J-Link ist mehr als doppelt so schnell als der Olimex, sozusagen der "Ferrari" unter den JTAG Interfaces. Bei den JTAG Adaptern kommt es natürlich auch immer auf die Entwicklungsumgebung drauf an. Ich nutze die Open-Source Lösung mit Eclipse/OpenOCD/Yagarto/Codesourcery. Ist ja klar, dass ein spezieller JTAG-Adapter nicht mit einer völlig anderen Software tut. Leider gibt es von Olimex nur Demo-Boards mit einem STM32F103RB, und der Chip hat wegniger Timer.
Jan B. schrieb: > 4 Timer sind als freie Timer vorhanden die anderen beiden belegen ja die > DAC Ports und die Motorports es existieren aber trotzdem ISR für diese > ports für Compare Overflow ? Nochmal: Es sind 6 allgemeine gleichartige Timer mit externen PWM und Capture Funktionen vorhanden. 2 davon besitzen zusätzlich erweiterte PWM-Funktionen wie dead time, die man nutzen kann aber nicht muss. Zusätzlich dazu sind 2 weitere Timer ohne externe Funktion vorhanden, die sich mit den DACs verbandeln lassen. Diese beiden (basic timer) haben mit den vorherigen 6 nichts zu tun. Es sind also in Summe 8 Timer, 6 davon mit Capture/PWM, 2 ohne. Systick und Realtime-Clock nicht mitgerechnet.
@ Thomas Burkhart Ich hab den Link in den Artikel mit übernommen. @Jan, dann nimm den...
Jan B. schrieb: > -Kommunikation von PC <-> Uc kompl mit der Änderung und dem senden von > Kennfelddaten und ändern in Echtzeit bis zu der von mir gewünschten > Drehzahl. > -Berechnung von Einspritzzeitpunkt, Einspritzmenge > -Berechnung von Zündzeitpunkt ( incl Lastverstellung ) > -Berechnung der Kurbelwellenbeschleunigung ( Erkennung von > Zündaussetzern) > -Klopfkontrolle > -Erfassung von Motorrelevanten daten wie Öldruck und evtl > Auspufftemperatur alle ca 100 msec > -ms genauer eingang für den Laptrigger ( induktionsschleife zur Messung > der Rundenzeit) > -Übertragung der Telemetriedaten per Funk > -ca 10% Aufschlag für zukünftige Wahnsinnsideen und Zahlendreher > meinerseits. > -Anzeige der Daten auf einem LCD Display am Lenkrad Sämtliche der von dir aufgeführten Funktionen lassen sich mit einem Atmel 16bitter (AT91S..) ausführen. Der ST32 sollte also dafür 100%ig ausreichen, davon kannst du ausgehen. Eine derartige Steuerung ist programmiertechnisch anspruchsvoll, aber auch nichts Besonderes. Für die Berechnungen benötigt man auch keine FPU oder einen DSP. Das ist hilfreich zwecks Performance, aber nicht notwendig. Keine der Daten (Einspritzung, Zündzeitpunkt) erfolgen in ihrer Berechnung komplett. Hierfür gibt es das Kennfeld und die entsprechenden Adaptionsparameter.
Falk Brunner schrieb: > Los, jetzt darf die Open Source Gemeinde darüber jammern und wehklagen > ;-) > Jammern nicht. Aber vielleicht solltest du erwähnen, das du FPGA-Gott bist und andere Monate für etwas komplexere Projekte brauchen werden. Die Lernkurve ist heftig. Zu den Cypress PSoC: Die Timer kannst du dir nach Belieben in Anzahl und Art konfigurieren. Gebe allerdings gerne zu, daß dies in der Doku für Uneingeweihte nicht so recht ersichtlich ist. Die Lernkurve sieht anders aus, ist aber auch länglich...
Sorry guys, aber Regelung von Verbrennungsmotoren ist Infineon-Domäne: XC2000 oder TriCore Für <4Zylinder oder <Euro4 reicht sicher der XC2000 bestens. ALso hier: http://www.infineon.com/cms/en/product/channel.html?channel=db3a3043243b5f170124c9447c2f4c9c oder schau hier: http://www.infineon.com/cms/en/product/applications/automotive/powertrain/index.html Also lasst mal Eure "Wald-und-Wiesen"-Mikro stecken ... Sorry, aber ehrlich ...
LOL! MBK: guck mal über den Tellerrand. Die Welt ist recht groß und Autos baut man auch anderswo (und deren Steuerungen mit anderen Prozessoren). Auch die Japaner haben z.B. ganz gute Prozessoren hierfür im Programm. Und solche Chips werden üblicherweise nicht vom Halbleiterhersteller in Vorleistung gebaut, um dann Kunden zu suchen, sondern da gehen etwas längere Abstimmungen mit den zukünftigen Kunden voraus. Gott sei Dank ist da Platz für etwas Vielfalt.
@MBK kennst du jemanden, der freiwillig mit infineon-controllern arbeitet, wenn sichs vermeiden lässt?
@ Abdul K. (ehydra) Benutzerseite >Aber vielleicht solltest du erwähnen, das du FPGA-Gott bist Huch, warum willst du mich denn in den Olymp hieven? > und andere Monate für etwas komplexere Projekte brauchen werden. > Die Lernkurve ist heftig. Ist doch ein Hobbyprojekt. Der Weg ist das Ziel. MFG Falk
Falk Brunner schrieb: > @ Abdul K. (ehydra) Benutzerseite > >>Aber vielleicht solltest du erwähnen, das du FPGA-Gott bist > > Huch, warum willst du mich denn in den Olymp hieven? Kennst das ja: Notfalls befördern... > >> und andere Monate für etwas komplexere Projekte brauchen werden. >> Die Lernkurve ist heftig. > > Ist doch ein Hobbyprojekt. Der Weg ist das Ziel. > In dem Fall ist das Hobby ziemlich extensiv. Wird bestimmt 2 Jahre programmieren.
anonymous schrieb: > @MBK kennst du jemanden, der freiwillig mit infineon-controllern > arbeitet, wenn sichs vermeiden lässt? Stimmt. Kenne keinen. Die meisten werden wohl über ihren Arbeitgeber gezwungen... Die Zeiten sind zumindest bei mir vorbei, in etwa seit Siemens nun Infineon heißt. Auf den Rückruf des Applikations-Ingenieurs warte ich wohl auch seit 3-4 Jahren. Dabei hätte er notfalls sogar bayrisch sprechen dürfen.
MBK schrieb: > Sorry guys, aber Regelung von Verbrennungsmotoren ist Infineon-Domäne: > XC2000 oder TriCore > Für <4Zylinder oder <Euro4 reicht sicher der XC2000 bestens. > ALso hier: > http://www.infineon.com/cms/en/product/channel.htm... > oder schau hier: > http://www.infineon.com/cms/en/product/application... > > Also lasst mal Eure "Wald-und-Wiesen"-Mikro stecken ... > > Sorry, aber ehrlich ... Also diese Wald und Wiesen micros sind besser geeeignet als die spezialisierten Infineon Prozessoren. Was ich aber recht interessant finde sind die Bausteine für die Einspritzventile auf der Seite spart mir ne Menge grübeln Thk dafür. mfg jan
Jan B. schrieb: > Also diese Wald und Wiesen micros sind besser geeeignet als die > spezialisierten Infineon Prozessoren. Was ich aber recht interessant > finde sind die Bausteine für die Einspritzventile auf der Seite spart > mir ne Menge grübeln Thk dafür. > Bedenke aber: 1. Wirst du die überhaupt kaufen dürfen und zu welchem Preis? 2. Bekommst du ein Ersatzteil in 10 Jahren? Genau wegen beider Punkt kannste Infineon eigentlich komplett vergessen. Die sind nur interessant, wenn du 100.000er Stückzahlen schiebst... Früher war das anders. Da hatte ich von denen jedes erreichbare Datenbuch und was es sonst so gab.
Bull Shit Bingo! Facts: http://search.digikey.com/scripts/DkSearch/dksus.dll?vendor=0&keywords=infineon+XC2700 Infineon ist genauso ein Longtime Supplier wie andere in der Autombilindustrie. Also labert nicht rum ... ... und die MCUs passen perfekt auf die genannten Anforderungen und haben außerdem Relevanz falls dieses Projekt einmal Leuten aus der Industrie vorgestellt werden soll. Die halten sich dann den Bauch wenn da ein Atmel oder STM32 drin ist. Wellcome to the World of real Realtime!
Danke "Oh No!" Entweder sind hier die feinen Marketeers von Atmel und STM unterwegs oder es fehlt an Wissen bzgl. Automotive-Anwendungen. Sorry, no bashing, but ... ... das Thema Regelung von Verbrennungsmotoren ist Fest in der Hand von MPCs, Tricore und C166 (damit die Dresdner noch genug Arbeit in den nächsten Jahren haben, empfehle ich Infineon - traurig welche Schneise Qimonda verursacht hat).
Na wenn sie bei digikey stocked sind, klingt das ja gut. Übrigens habe ich nie eine AVR oder STM programmiert, dafür aber die ersten 166 als sie auf dem Markt kamen. Stand noch ES drauf. Du liegst also mal komplett falsch. Hauptsache gelabert. Trotzdem bleibt eine Sache: Die Einarbeitung wird dann in einen 166 investiert. Wird das dann auch der Prozessor für die nächsten Projekte? Muß man sich vorher sehr gut überlegen.
Abdul, war nicht an Dich gerichtet. Aber wenn Jan in dem Umfeld weitere Projekte plant ist die Investition doch gut angelegt. Ich bezweifele, daß bei anderen Architekturen der Invest kleiner ist, da es um Echzeitregelung geht und eben nicht nur "Standard-vom-Internet-herunterladbar". Wenn Du die C166 kennst, weißt Du was ich meine. Der C167 ist ja Jahrzehnte im Auto angewendet worden. Mit XC2000 ist die Familie weitergeführt worden. Für solche Anwendungen, macht es Sinn sich in die CCU6- und die ADC-Funktionen einzuarbeiten. Dafür bekommt man eine perfekte Regelung.
Ja, sicher. Der 166 ist sauschnell, aber Siemens (damals noch) hatte nie die richtige Werbeidee. Anekdote: Mein streng hierarchisch aufgebauter Soft-i2c Code hatte ich vom 8051 auf 166 portiert. War ganz einfach: Nur drei Funktionen für die Ansteuerung der beiden Portbits geändert, da die I/O-Struktur beider Prozessoren komplett anders ist: 1. setBit(SCL or SDA) 2. clrBit(dito) 3. getBit(dito) Also in Keil-C einfach neucompiliert und probehalber laufenlassen... Hm, i2c EEPROM hat nicht geanwortet. Dabei wollte ich doch nur noch die Delay-Routine passend ändern. Scope an, oh clicke drehe guck, da war das gleiche Programm auf einmal satte Faktor 8000 schneller!! Das das dann nicht sofort laufen konnte, war sonnenklar. Delay-Routine Konstante geändert, ferrrtisch.
Oh no! schrieb: > Bull Shit Bingo! > > Facts: > > http://search.digikey.com/scripts/DkSearch/dksus.d... > > Infineon ist genauso ein Longtime Supplier wie andere in der > Autombilindustrie. Also labert nicht rum ... > > ... und die MCUs passen perfekt auf die genannten Anforderungen und > haben außerdem Relevanz falls dieses Projekt einmal Leuten aus der > Industrie vorgestellt werden soll. Die halten sich dann den Bauch wenn > da ein Atmel oder STM32 drin ist. > > Wellcome to the World of real Realtime! Einen Thread mit einer Beleidigung zu beginnen ist aber nicht die feine Englische Art. Zu meinen Anforderungen die durch den ST32 besser erfüllt werden -Passendes Format ... die Infineon gehen bei 100 Pins los -Usb Anschluss zur Logging Funktion ... hat nur Uart -LCD Anschluss für die Echtzeitanzeige der Daten... hatter net -Background division (32 / 16 bit) in 21 cycles .. wenn ich mich net furchtbar irre kann der St32 das wesentlich schneller -größere Community für ST32 Wo sind denn die Vorteile gegenüber ST32? Das die Atmels ungeeignet sind ist mir schon klar, ich hab sie auch nicht in der engeren Wahl. Ich schließe es nicht völlig aus das ich das mal irgendwem Vorstelle aber es ist sehr unwahrscheinlich. Also Pöbel net rum komm lieber mit Argumenten statt hier die Leute zu beleidigen die mir bei der Auswahl helfen möchten. mfg Jan
anonymous schrieb: > @MBK kennst du jemanden, der freiwillig mit infineon-controllern > arbeitet, wenn sichs vermeiden lässt? Hier ich zum Beispiel. :-D Habe nun mit allen vier Generationen der C166 Familie ausschließlich im Hobby gespielt. Ein wenig Atmel war während des Studiums und im Beruf nun mit PPC (unteranderem mit Typen die noch nicht käuflich sind). Und ich muss sagen, dass ich am besten mit dem Infineon zurecht komme. Das ist aber eigentlich Geschmackssache, die Kollegen schimpfen auch auf die TriCores. Aber zurück zum Fragenstellen: im XC2287 könnte man zum Beispiel die komplette Zündung und Einspritzung (bis zu acht kanäle) in Hardware ablaufen lassen. Da hat die CPU nr etwas beim Initialisiern zu tun. Der Rest der Rechenleistung kann für Fehlerüberwachung, Logging Kommunikation oder was einen sonst noch einfällt nutzen. Ist alles nur eine Frage der reichlichen Planung.
Nun die Argumente warum der STM32 für Jan besser ist: - Jan ist Hobby-Anwender und mit dem Cortex-Kern (z.B. STM32) Entwicklungsumgebung ist man nicht an einen STM32 von ST gebunden, sondern kann auch ARM7/ARM9 programmieren. Die wurden von vielen Herstellern in Chips gegossen. Also man hat eine enorm breite Auswahl. - Wenn Infioneon insolvent wird, gibts automatisch keine C166 mehr, denn man hat sich auf einen einzigen Hersteller fixiert, dann darf man schön in die Röhre schauen. - Kostenlose GCC Entwicklungsumgebung, Opensource, viele Demos im Internet. Nur der JTAG kostet 60 EUROs. - Schlechte Verfügbarkeit für Hobby-Anwender (C166) - Bessere Unterstützung hier im Forum. Ich habe schon lange kein Posting für einen C166 hier gesehen.
Kein Kommentar zur Nettikette, aber hier kann ich vielleicht weiterhelfen: - Gehäuse: kleinstes QFP64 (auf der Webseite sind aber noch kleinere angekündigt): http://www.infineon.com/cms/en/product/channel.html?channel=db3a304323b87bc20123e1c268d62454 - Must das Logging wirklich auf dem gleichen Chip laufen - passt dann die Performance für die Regelung? Welche Daten willst du loggen? - Auf den Kits von Infineon sind FTDIs als Schnittstelle zur JTAG drauf, wäre das eine Lösung? -LCD kannst Du über die EBC (External Bus Interface) anschliessen (meines Wissens erst ab 100piner) Community: Schade das so wenig zu dem Thema publiziert worden ist. Aber die Leute bei Bosch oder Conti teilen natürlich ungern Ihren Code in dem Forum. In China wäre das sicher einfacher ... ;-) Ich habe zu dem Thema Verbrennungsmotor auf dem Web nur noch die Interactive App Note für den TriCore für Flywheel, etc. gefunden: http://www.infineon.com/cms/en/product/channel.html?channel=ff80808112ab681d0112ab6b57a007df&parentChannelRef=db3a30431c69a49d011c70edc494011e_db3a30431c69a49d011c70edc494011e_db3a30431c69a49d011c70edc494011e_db3a30431c69a49d011c70edc494011e_db3a30431c69a49d011c70edc494011e_db3a30431c69a49d011c70edc494011e_db3a30431c69a49d011c70edc494011e_db3a30431c69a49d011c70edc494011e_db3a30431c69a49d011c70edc494011e_db3a30431c69a49d011c70edc494011e_db3a30431c69a49d011c70edc494011e Sonst zu Knock Detection,etc. findest Du hier auch Infos (aber für TriCore): http://www.infineon.com/cms/en/product/channel.html?channel=ff80808112ab681d0112ab6b64b50805 Wenn bei Dir die Regelung eines Verbrennungsmotors im Vordergrund steht würde ich auf IFX setzen und das Thema in diesem Forum unter der C166 Rubrik platzieren.
Markus Müller schrieb: > - Wenn Infioneon insolvent wird, gibts automatisch keine C166 mehr, denn > man hat sich auf einen einzigen Hersteller fixiert, dann darf man schön > in die Röhre schauen. Kein Cortex-MCU ist 1:1 baugleich und bei Echtzeitregelung wirst Du ein Teufel (sorry Robert) tun und alles in C auf der CPU laufen lassen. Da wirst du Die Stärken der Peripherie ausnutzen (egal ob IFX oder FS oder Hitachi, sorry Renesas). Free tool chain ist wirklich ein Thema, da gibt's erst einmal nur das limitierte Programm mit Tasking (siehe Internet). Aber was Jan vorhat ist ja auch nicht gerade ein Hobbyprojekt der Kategorie Atomzeituhr (nichts gegen die Entwickler aus dem Bereich). Und vielleicht hat er damit mehr vor, als nur für seine eigene Garage ... :-)
Es gibt Einige die das aktuell bereits realisiert haben. Es wurden ja schon welche genannt. Dazu mit schwächeren Prozessoren als dem STM32. Ich bin gar der Meinung dass der STM32 sogar oversized ist für diese Aufgabe. Einige Komponenten der Steuerung werden modular ausgeführt sein müssen. Denn durch Laufzeitänderungen innerhalb des Prozessors durch verschiedenste Szenarien und Eingangsdaten gibt es sehr unerwünschte Effekte. Ein monolithischer Aufbau rein in Software führt zwangsweise zu schwer kalibrierbaren und beherrschbaren Steuerungsabläufen. Insbesondere bei einer hohen Drehzahlanforderung ist eine exakte zeitliche Ausführung ja unablässlich. Nicht umsonst sind Prozessoren im automotive-Bereich spezialisiert. Modularer Aufbau mit Blick auf Nachbildung dieser Spezialisierungen sind aus meiner Sicht diskussionslos anerkannt. Demzufolge ist ein fetter Prozessor eventuell nicht das entscheidene Auswahlkriterium. Falls gewünscht, mache ich dich mit dem Entwickler bekannt und ihr könnt Eure Erfahrungen austauschen.
So da melde ich mich mal wieder zurück. Nachdem ich nun meine Hausaufgaben gemacht habe möchte ich euch meine Idee vorstellen und möchte natürlich eure Meinungen dazu hören. Prozessor soll wahrscheinlich werden ein STM32f103rc -Er hat 6Timer die ich für Steuerungsaufgaben benutzen kann -2 Mal Spi Buss -Genug AD Ports FM25CL64 -64Kb FRAM eventuell reichen auch 32kb -genug Platz für 200 Werte Zündung (200*8Bit) = 200Byte -genug Platz für 500 Werte Einspritzung = 500 Byte -eventuell noch etwas Platz für config von Peripheriegeräten und Datalogging -Kann über 20 Mhz Spi angesprochen werden Funktioniert das hier den DMA Kontroller zu benutzen? Würde CPU-Zeit sparen Man könnte das Kennfeld im laufenden Betrieb neu laden. RFM12 -100-200 Meter sollten reichen obwohl durch die Zündkerze natürlich Störung der Funkstrecke entstehen. Es reicht ja wenn einmal Pro Runde die Daten übertragen werden Grafikdisplay -Ich hab noch kein so dolles gefunden -Ich würde gerne 320x240 benutzen -Über Spi ansteuerbar das hier sieht im Prinzip nicht schlecht aus obwohl es kleiner ist http://www.lcd-module.de/deu/pdf/grafik/dogm132-5.pdf Stromversorgung -Ich benötige wahrscheinlich 3v3 und 5v. Diese will ich mit Linearreglern erzeugen jeweils 2 Parallel mit Sperr und Zenerdioden und unterschiedlichen Kondensatoren vor den ICs um die Störungen vom Aktivieren der Zündspule rauzufilten. Im 3v3 und 5v kommen natürlich danach noch einige Kondensatoren zur glättung obwohl ich gelesen hab das Linearregler schon relativ störungsarme Ausgangsspannungen erzeugen. Nun ist allerdings Programmiertechnisch schon wieder ein Problem aufgetaucht. Bei einer 36iger Zahnteilung auf dem Triggerrad hat man Zahnabstände von 104,167 µs Hier mal eine Aufstellung der Übertragungsdauer der einzelnen Funktionen die ich auf dem Pc anzeigen lassen möchte ( bei 115200 Baud) Datenmenge: Zündaussetzer (Wert von 0-255 max. 3*8-bit) || 0,24 ms Öltemperatur (Wert von 0-255 max. 3*8-bit) || 0,24 ms Zzp-Kennfeld (Wert von 0-255 *200 max. 3*200*8-bit) || 48 ms Einspritz-Kennfeld(Wert von 0-255 *200 max. 3*200*8-bit) || 48 ms RPM(Wert von 0-16000 max. 5*8-bit) || 0,4 ms Rundenzeit(120000 für 2min max. 6*8-bit) || 0,48 ms Zzp(Wert von 0-255 max. 3*8-bit) || 0,24 ms Einspritzmenge(Wert von 0-255 max. 3*8-bit) || 0,24 ms Die 48 Ms und sogar die schnellen 0,24 ms der Übertragung liegen oberhalb der 104,167 µs. Ich denke es wird Probleme geben wenn ein Interrupt in eine Funkübertragung // Übertragung über Usb dazwischenfunkt oder ? Zwei mögliche Lösungen sind mir eingefallen. Wie voher schon erwähnt könnte man einen µc ( Stm32) für die Berechnung und das setzen der Ausgänge und einen ( Typ unbekannt ) für die Protokollfunktion (LCD/USB/FUNK) Diese Methode finde ich nicht so elegant da ich eine Routine für die Kommunikation zwischen den beidne µc schreiben müsste. Eleganter wäre ein µc mit 2 Kernen ( einer rechnet/ einer protokolliert) eine Etpu würde denke ich schon reichen aber die Prozessoren die es hiervon gibt liegen ganz weit außerhalb meiner Programmiertechnischen Kenntnisse und Anforderungen( Display Usb usw). Was meint ihr ? Könnte man die Übertragung trotz Interrupt durchführen ? mfg Jan
Eigentlich sollten 100µS kein Problem für den STM32 darstellen. Die Daten die seriell zu verschicken sind müssen in einen Zwischenbuffer (RAM) geschrieben werden. Dieser wiederum wird über den UART/Interrupt ausgegeben. Um die Daten zusammen zu stellen sollte allerdings kein sprintf() verwendet werden, der ist relativ langsam, besser eigene Routinen schreiben die die Zahl in ASCII konvertiert und direkt in den Buffer schreibt. Auch die USB Bedienung im Hintergrund/Interrupt sollte keine Probleme bereiten. Wichtig ist vor allem, dass die Interrupt-Routinen relativ kurz sind und dass alles was nicht unbedingt dort rein muss im Main-Task berechnet wird. Bei guter Programmierung erreicht man ohne Probleme 50000 Main-Zyklen, da kommt man auch schnell genug vorbei um die Daten für die serielle Ausgabe zu berechnen. Meine letzte Steuerung (allerdings nicht Zeitkritisch) lasse ich den STM32 mit nur 8MHz laufen und der macht 5000 Main-Zyklen/Sek. (Bei Kompiller Optimierung 7500). In jedem Fall solltest Du solch eine Sekunden-Ausgabe der Zyklen drin haben, dann siehst Du sofort wenn irgendwo eine "Warteschleife" eingebaut wurde die das System ausbremst.
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.