www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Auswahl des richtigen µc


Autor: Jan M. (Gast)
Datum:

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

Autor: Weingut Pfalz (weinbauer)
Datum:

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

Autor: H.Joachim Seifert (crazyhorse)
Datum:

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

Autor: Jan M. (Gast)
Datum:

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

Autor: Andreas Schweigstill (Firma: Schweigstill IT) (schweigstill) Benutzerseite
Datum:

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

Autor: Markus Müller (mmvisual)
Datum:

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

Autor: Anja (Gast)
Datum:

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

Autor: Falk Brunner (falk)
Datum:

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

Autor: Bastler (Gast)
Datum:

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

Autor: Jan M. (Gast)
Datum:

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

Autor: Markus Müller (mmvisual)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Jan M. (Gast)

Schaue doch mal den Artikel an:
http://www.mikrocontroller.net/articles/STM32

Damit müsstest Du hin kommen.

Autor: Alexander Schmidt (esko) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Zustimmung zu Beitrag #1666166.
Warum wurde der gelöscht?

Autor: Bastler (Gast)
Datum:

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

Autor: Falk Brunner (falk)
Datum:

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

Autor: Jan (Gast)
Datum:

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

Autor: Markus Müller (mmvisual)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nimm den STM32F103C8. Dann klappt es.

Autor: MarioT (Gast)
Datum:

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

Autor: Falk Brunner (falk)
Datum:

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

Autor: Anja (Gast)
Datum:

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

Autor: Stefan Wimmer (wswbln)
Datum:

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

Autor: Alexander Schmidt (esko) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> TPU
Was ist eine TPU?

Autor: spess53 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

>> TPU
>Was ist eine TPU?

Es wird Zeit, das jemand eine Suchmaschine erfindet.

MfG Spess

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@  Alexander Schmidt (esko) Benutzerseite

>> TPU
>Was ist eine TPU?

Time Processing Unit. Ein komplexer, programmierbarer Timer, quasi ICP, 
OCP und Zeugs in einem.

Autor: Alexander Schmidt (esko) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Danke Falk


spess53 schrieb:
>>Was ist eine TPU?
> Es wird Zeit, das jemand eine Suchmaschine erfindet.

Die Ergebnisse siehe Anhang.

Autor: spess53 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

>Die Ergebnisse siehe Anhang.

Auch gurgeln will gelernt sein. Z.B. 'TPU µC'.

MfG Spess

Autor: Abdul K. (ehydra) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Erstaunlich wie wenig manche wissen. Scheint aber im Leben nix 
auszumachen.

Autor: spess53 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

@esko

Übrigens hättest du an erster Stelle deiner Anforderungsliste 
'automotive' anführen sollen.

MfG Spess

Autor: Alexander Schmidt (esko) Benutzerseite
Datum:

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

Autor: Falk Brunner (falk)
Datum:

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

Autor: spess53 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

>Ich habe übrigens nichts mit dem OP zu tun.

Dann gebe ich es an Jan weiter.

MfG Spess

Autor: Peter Dannegger (peda)
Datum:

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

Autor: Stefan Wimmer (wswbln)
Datum:

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

;-)

Autor: Peter Dannegger (peda)
Datum:

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

Autor: faustian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: Andreas Schweigstill (Firma: Schweigstill IT) (schweigstill) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Upps, ich hatte in meiner Aufstellung natürlich auch die
aktuellen Automotive-Prozessoren von Micronas vergessen, die
es auch in 12V-Ausführung gibt.

Autor: Abdul K. (ehydra) Benutzerseite
Datum:

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

Autor: Falk Brunner (falk)
Datum:

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

Autor: horst (Gast)
Datum:

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

Autor: Abdul K. (ehydra) Benutzerseite
Datum:

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

Autor: Jan M. (Gast)
Datum:

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

Autor: MarioT (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Woher weiß Dein µC bei 35 Zähnen wo der Totpunkt ist?

Autor: Jan M. (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Die Zähne sind so angeordnet als wären es 36 aber einer fehlt.
siehe Bild

mfg Jan

Autor: Markus Müller (mmvisual)
Datum:

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

Autor: Abdul K. (ehydra) Benutzerseite
Datum:

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

Autor: Horst (Gast)
Datum:

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

Autor: Horst (Gast)
Datum:

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

Autor: Jan B. (manax)
Datum:

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

Autor: Markus Müller (mmvisual)
Datum:
Angehängte Dateien:

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

Autor: Falk Brunner (falk)
Datum:

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

Autor: Markus Müller (mmvisual)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Was kostet denn eine FPGA Entwicklungsumgebung?
Ich meine, gibt es OpenSource oder so?

Autor: Horst (Gast)
Datum:

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

Autor: Falk Brunner (falk)
Datum:

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

Autor: Markus Müller (mmvisual)
Datum:

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

Autor: Falk Brunner (falk)
Datum:

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

Autor: Markus Müller (mmvisual)
Datum:

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

Autor: Stefan Wimmer (wswbln)
Datum:

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

Autor: Jan B. (manax)
Datum:

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

Autor: Markus Müller (mmvisual)
Datum:

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

Autor: A. K. (prx)
Datum:

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

Autor: Jan B. (manax)
Datum:

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

Autor: Karlheinz (Gast)
Datum:

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

Autor: Jan B. (manax)
Datum:

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

Autor: Markus Müller (mmvisual)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das "SPS" kenne ich nicht. Im Datenblatt ist davon nichts beschrieben.

Hier ein Link zu Farnell:
http://de.farnell.com/stmicroelectronics/stm32f103...
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.

Autor: Thomas Burkhart (escamoteur)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: A. K. (prx)
Datum:

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

Autor: Markus Müller (mmvisual)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Thomas Burkhart
Ich hab den Link in den Artikel mit übernommen.

@Jan, dann nimm den...

Autor: Hotte (Gast)
Datum:

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

Autor: Abdul K. (ehydra) Benutzerseite
Datum:

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

Autor: MBK (Gast)
Datum:

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

Autor: Stefan Wimmer (wswbln)
Datum:

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

Autor: anonymous (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@MBK kennst du jemanden, der freiwillig mit infineon-controllern 
arbeitet, wenn sichs vermeiden lässt?

Autor: Falk Brunner (falk)
Datum:

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

Autor: Jan B. (manax)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Naja ankommen ist ja auch net schlecht @Falk Brunner

Autor: Abdul K. (ehydra) Benutzerseite
Datum:

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

Autor: Abdul K. (ehydra) Benutzerseite
Datum:

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

Autor: Jan B. (manax)
Datum:

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

Autor: Abdul K. (ehydra) Benutzerseite
Datum:

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

Autor: Oh no! (Gast)
Datum:

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

Autor: MBK (Gast)
Datum:

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

Autor: Abdul K. (ehydra) Benutzerseite
Datum:

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

Autor: MBK (Gast)
Datum:

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

Autor: Abdul K. (ehydra) Benutzerseite
Datum:

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

Autor: Jan B. (manax)
Datum:

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

Autor: TManiac (Gast)
Datum:

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

Autor: Markus Müller (mmvisual)
Datum:

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

Autor: MBK (Gast)
Datum:

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

Sonst zu Knock Detection,etc. findest Du hier auch Infos (aber für 
TriCore):
http://www.infineon.com/cms/en/product/channel.htm...

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.

Autor: MBK (Gast)
Datum:

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

Autor: Michael (Gast)
Datum:

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

Autor: Jan B. (manax)
Datum:

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

Autor: Markus Müller (mmvisual)
Datum:

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

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.