Abstimmung eines Motors auf maximale Leistung
-
Gast
hmmm...insofern ist mir immer noch nicht klar, ob bei einer Einstellung um 1,1 der Motor wirklich einen Schaden nimmt, zumal die 1,1 ja nur in einem kleinen Drehzalbereich vorgesehen ist...
...oder ob die höhere kurzzeitige Hitzeentwicklung auch positiv gesehen werden kann zwecks Reinigung bei doch sonst sehr fettem Gemisch...
...oder ob die höhere kurzzeitige Hitzeentwicklung auch positiv gesehen werden kann zwecks Reinigung bei doch sonst sehr fettem Gemisch...
-
Frank
Grundsätzlich besteht bei zu hohen Lambdawerten die Gefahr, daß der Motor überhitzt (durchgebrannte Kolbenböden, abgerissene Ventile, Kolbenklemmer, Risse im Kopf...). Es ist aber möglich, Motoren konstruktionsmäßig für diesen Betriebszustand auszulegen, was gegen Ende der Vergaserära auch bei einigen Herstellern gemacht wurde. Ergebnis: hervorragende Verbrauchswerte. Zur Erzielung einer hohen Standfestigkeit gibt es mehrere Möglichkeiten: hochwarmfeste Legierungen, Ventile mit Natriumfüllung, gekühlte Kolben usw. Auch Merkmale wie die Verdichtung verstärken die Wirkung bzw. setzen sie herab. Die Entstehung von Ölzersetzungsprodukten hängt ebenfalls sehr von den Spitzentemperaturen ab. Lackartige Rückstände an Kolben und festgehende Kolbenringe sind typische Merkmale mageren Betriebs mit rückständigen Ölen.
Motorschäden durch zu mageres Gemisch sind übrigens recht häufig. Die Spannweite reicht von verschmutzen Vergasern über Fremdluft bis hin zu Problemen bei der Lambdaregelung. Bei Ford z.B. wurden Lambdasonden mit interner Masseverbindung auf Sonden ohne interne Masseverbindung umgestellt. Da die Signalspannung des Differenzverstärkers im Stzeuergerät über hochohmige Widerstände auf +5V liegt, interpretiert das Steuergerät diese Zustand als zu fettes Gemisch. In Verbindung mit einer unvollständigen Firmware kommt es hierdurch zu Rissen im Kopf.
Zu fettes Gemisch ist aus den bekannten Gründen ebenfalls Gift für den Motor. Schmierfilm im Zylinder wird abgewaschen, Öl verdünnt, Verdichtung erghöht sich durch Ablagerungen in der Brennkammer usw.
Motorschäden durch zu mageres Gemisch sind übrigens recht häufig. Die Spannweite reicht von verschmutzen Vergasern über Fremdluft bis hin zu Problemen bei der Lambdaregelung. Bei Ford z.B. wurden Lambdasonden mit interner Masseverbindung auf Sonden ohne interne Masseverbindung umgestellt. Da die Signalspannung des Differenzverstärkers im Stzeuergerät über hochohmige Widerstände auf +5V liegt, interpretiert das Steuergerät diese Zustand als zu fettes Gemisch. In Verbindung mit einer unvollständigen Firmware kommt es hierdurch zu Rissen im Kopf.
Zu fettes Gemisch ist aus den bekannten Gründen ebenfalls Gift für den Motor. Schmierfilm im Zylinder wird abgewaschen, Öl verdünnt, Verdichtung erghöht sich durch Ablagerungen in der Brennkammer usw.
-
heizer_2
Eine selbstregelnde einspritzanlage wäre die lösung.
Was allerdings immer vergessen wird: (herkömmliche) lambdasonden sind recht träge, und relativ ungenau... Als alternative gibt es z.B. von bosch breitbandlamdasonden welche bandbreiten von bis zu 100Hz ermöglichen.
Aber zum sparsamen fahren bei l 1,1 im mittleren bereich sollte das reichen.
Beim beschleunignen würde ich die gasgriffstellung als indiz dafür nehmen, dass volle leistung gefordert ist und das gemisch ordentlich anfetten.
Kennfeld anlegen und mit fuzzy (;-)) die impulse für die zündung und die einsprizventile berechnen.
Eine selbsgefriemelte EFI wäre die lösung. Das squirt projekt ist ja schon lange auf dem gleichen stand, weiß garnicht, ob sich da noch was tut...
(Und ob der 16Mhz AVR für nen ZXR motor der mit 12500 u/min dreht ausreichned ist??)
Evtl. finde ich ja nach der diplomarbeit zeit an meinem traum eine sparsame EFI an die ZXR zu portieren...
Es gibt auf jedenfall braucht man eine alternative zu vergasern, da diese nicht mehr zu bekommnen sind... Bei ebay gibt es nur ausgenuddelte vergaser mit denen das moppie nicht optimal läuft. Und die steigenden benzinpreise machen einen "sparmodus" am motor echt nötig...
@ragi
Ich weiss nicht ob es mit flachies möglich ist die gewünschte l kurve hinzubekommen. Mit ner einspritzung + regleung ist das ne feine sache
Was allerdings immer vergessen wird: (herkömmliche) lambdasonden sind recht träge, und relativ ungenau... Als alternative gibt es z.B. von bosch breitbandlamdasonden welche bandbreiten von bis zu 100Hz ermöglichen.
Aber zum sparsamen fahren bei l 1,1 im mittleren bereich sollte das reichen.
Beim beschleunignen würde ich die gasgriffstellung als indiz dafür nehmen, dass volle leistung gefordert ist und das gemisch ordentlich anfetten.
Kennfeld anlegen und mit fuzzy (;-)) die impulse für die zündung und die einsprizventile berechnen.
Eine selbsgefriemelte EFI wäre die lösung. Das squirt projekt ist ja schon lange auf dem gleichen stand, weiß garnicht, ob sich da noch was tut...
(Und ob der 16Mhz AVR für nen ZXR motor der mit 12500 u/min dreht ausreichned ist??)
Evtl. finde ich ja nach der diplomarbeit zeit an meinem traum eine sparsame EFI an die ZXR zu portieren...
Es gibt auf jedenfall braucht man eine alternative zu vergasern, da diese nicht mehr zu bekommnen sind... Bei ebay gibt es nur ausgenuddelte vergaser mit denen das moppie nicht optimal läuft. Und die steigenden benzinpreise machen einen "sparmodus" am motor echt nötig...
@ragi
Ich weiss nicht ob es mit flachies möglich ist die gewünschte l kurve hinzubekommen. Mit ner einspritzung + regleung ist das ne feine sache
-
Frank
Der AVR wurde in der 2-er Version ersetzt durch eine Tochterplatine mit Motorola MC68HC908GP32 erweitert.
Für die Standardaufgaben reicht ein 8 Bit AVR jedoch aus. Die IRQ Bearbeitung ist hinreichend schnell für die Verarbeitung der Zündimpulse. Die Neuberechnung der Parametersätze ist auch hinreichend schnell, da die Massenträgheit des Motors und der Ansaugluft verhindern, daß der Motor sich von einer Zündung zur nächsten sich in einem völlig anderen Arbeitspunkt befindet. Die meisten älteren ECUs arbeiteten auch im PKW mit 8 Bit CPUs, oft genug auch mit angestaubten 8051 Varianten, die intern noch eine saftige Taktteilung besitzen. Im Vergleich dazu ist ein Mega 8 schon elitär.
Besonders gut geeignet sind natürlich 16 Bit CPUs wie der MSP430, die elegant Zeigeroperationen und damit Tabellenverabeitung gestatten. Beim AVR sind entsprechende Operationen umständlicher und weniger effizient (erst Laden der 2x8 Bit Zeiger, dann Spezialbefehle für Pointerzugriff).
Kernfrage ist das Konzept:
-Luftmassenmesser oder nicht? Die Lösung mit diesem Element vereinfacht die Programmierung erheblich. Mit der bekannten Luftmasse sind die meisten Kennfelder schon offline in sehr guter Näherung programmierbar; der Feinabgleich auf dem Prüfstand entsprechend schnell erledigt. Variable Motorparameter sind weitgehend ohne Einfluß. Nachteil: der teure, recht große Luftmassenmesser und dessen Anfälligkeit.
-MAP Sensor + Ansaugluft-Temperatursensor + Drehzahlsignal. Ist die derzeit bevorzugte Methode, da hinreichend genau, hardwaremäßig einfach zu realiseren und noch mit vertretbarem Aufwand auf dem Prüfstand zu optimieren. Die vorherige Abschätzung nach N=(p*V)/(K*T) wird alleine schon genauer als ein optimiwerter Vergaser. Das Motormodell ist einfach per Drehzahltabelle erledigt.
-Reine Realisierung nach Drosselklappenwinkel und Drehzahl (Alpha-N) kommt nicht in Frage.
Obwohl veile >Parameter gemeinsam benötigt werden, soll Zündsteuerung + Einspritzung auf der Digitalseite getrennt realisiert werden. Analoges Frontend natürlich nur 1x für alles. Gedacht ist das Projekt für einen alten NSU Motor...
Für die Standardaufgaben reicht ein 8 Bit AVR jedoch aus. Die IRQ Bearbeitung ist hinreichend schnell für die Verarbeitung der Zündimpulse. Die Neuberechnung der Parametersätze ist auch hinreichend schnell, da die Massenträgheit des Motors und der Ansaugluft verhindern, daß der Motor sich von einer Zündung zur nächsten sich in einem völlig anderen Arbeitspunkt befindet. Die meisten älteren ECUs arbeiteten auch im PKW mit 8 Bit CPUs, oft genug auch mit angestaubten 8051 Varianten, die intern noch eine saftige Taktteilung besitzen. Im Vergleich dazu ist ein Mega 8 schon elitär.
Besonders gut geeignet sind natürlich 16 Bit CPUs wie der MSP430, die elegant Zeigeroperationen und damit Tabellenverabeitung gestatten. Beim AVR sind entsprechende Operationen umständlicher und weniger effizient (erst Laden der 2x8 Bit Zeiger, dann Spezialbefehle für Pointerzugriff).
Kernfrage ist das Konzept:
-Luftmassenmesser oder nicht? Die Lösung mit diesem Element vereinfacht die Programmierung erheblich. Mit der bekannten Luftmasse sind die meisten Kennfelder schon offline in sehr guter Näherung programmierbar; der Feinabgleich auf dem Prüfstand entsprechend schnell erledigt. Variable Motorparameter sind weitgehend ohne Einfluß. Nachteil: der teure, recht große Luftmassenmesser und dessen Anfälligkeit.
-MAP Sensor + Ansaugluft-Temperatursensor + Drehzahlsignal. Ist die derzeit bevorzugte Methode, da hinreichend genau, hardwaremäßig einfach zu realiseren und noch mit vertretbarem Aufwand auf dem Prüfstand zu optimieren. Die vorherige Abschätzung nach N=(p*V)/(K*T) wird alleine schon genauer als ein optimiwerter Vergaser. Das Motormodell ist einfach per Drehzahltabelle erledigt.
-Reine Realisierung nach Drosselklappenwinkel und Drehzahl (Alpha-N) kommt nicht in Frage.
Obwohl veile >Parameter gemeinsam benötigt werden, soll Zündsteuerung + Einspritzung auf der Digitalseite getrennt realisiert werden. Analoges Frontend natürlich nur 1x für alles. Gedacht ist das Projekt für einen alten NSU Motor...
-
heizer_2
Hallo Frank,
ich dachte im squirt wird zündung + einspritzung gemeinsam von der MCU berechnet. Das der avr gegen nen 8-bitter von motorola getauscht wurde wusste ich nicht
.
Warum sind denn zeigeroperationen mit dem avr nicht so elegant zu lösen?
Einfach adresse ins Z register laden (4 takte) dann mit lpm zeiger aus programmspeichertabelle laden (3 takte).
Den MSP gibt es bis dato "nur" mit 8 Mhz. Bei jedem compilerbenchmark schneidet der MSP meist schlechter ab als der AVR.
Der MSP braucht ein takt weniger (6 takte) für zeiger-zeiger operationen.
Bei Interruptabbarbeitung ist der MSP langsamer (min. 11 takte).
Na ja, wenn zündung und einspritzung hardwaremäßig getrennt werden, dann reicht der AVR allemal locker aus. Zumal es versionen mit 20Mhz gibt...
Die luftmassenmessergeschichte wäre die ideale lösung. Aber evtl. funzt es auch mit der breitbandlambdasonde, da diese schnell genug reagiert. Dann passt das gemisch immer eine zündung später.
ich dachte im squirt wird zündung + einspritzung gemeinsam von der MCU berechnet. Das der avr gegen nen 8-bitter von motorola getauscht wurde wusste ich nicht
.Warum sind denn zeigeroperationen mit dem avr nicht so elegant zu lösen?
Einfach adresse ins Z register laden (4 takte) dann mit lpm zeiger aus programmspeichertabelle laden (3 takte).
Den MSP gibt es bis dato "nur" mit 8 Mhz. Bei jedem compilerbenchmark schneidet der MSP meist schlechter ab als der AVR.
Der MSP braucht ein takt weniger (6 takte) für zeiger-zeiger operationen.
Bei Interruptabbarbeitung ist der MSP langsamer (min. 11 takte).
Na ja, wenn zündung und einspritzung hardwaremäßig getrennt werden, dann reicht der AVR allemal locker aus. Zumal es versionen mit 20Mhz gibt...
Die luftmassenmessergeschichte wäre die ideale lösung. Aber evtl. funzt es auch mit der breitbandlambdasonde, da diese schnell genug reagiert. Dann passt das gemisch immer eine zündung später
.-
Frank
Unser eigenes Projekt entsteht um 2 AT-Mega 16, getrennt für Zündung und Einspritzung. Grund ist: in vielen Fällen soll nur die alte Zündung durch eine frei programmierbare ersetzt werden - der Vergaser bleibt erhalten. In den anderen Fällen stört der zusätzliche Chip nicht, da kostenmäßig irrelevant.
Habe die CPU Reihenfolge gemischt+falsch genannt. Korrekt ist diese Abfolge:
-MegaSquirt: MC68HC908 (8 Bit, Leistunghsdaten vergleichbar mit AVR)
-MegaSquirt-II: HC9S12C32 (16 Bit)
-MegaSquirt Ultra: MCF5234 (32 Bit)
Nehmen wir an, die Tabelle sei mit 8-Bit-Werten gefüllt (sonst unfair). Jedoch 16 Bit Pointer, da 64kB Adressraum. Ausgangspunkt: der Pointer ist schon vorher berechnet worden und existiert nun als 16 Bit-Wert in einem bzw. 2 Registern. Es soll der an dieser Stelle im Programmspeicher hinterlegte Wert in ein Register kopiert werden.
Atmel:
-Adresse aus Register in HIGH und LOW vom Pointer Z laden. Benötigt 2x MOV von Register zu Register, also 2x 1 Takte.
-Den hinter dem Pointer abgelegten Wert aus dem Programmspeicher in ein Register laden. Benötigt 1x LPM, also 1x 3 Takte. [Bei Daten im SRAM geht es einen Takt schneller].
Summe: 5 Takte.
MSP: Der MOV Befehl beim MSP hat Quelle und Ziel vertauscht.
-Kopieren der Adresse vom Register zu Pointer entfällt, da jedes Register selbst schon als Pointer benutzt werden kann.
-Den Wert aus dem Programmspeicher laden: MOV.B @R9, R8
Der Wert hinter dem Pointer R9 wird als Byte (.B) ins Register R8 kopiert.
Der Indirekte Registermodus benötigt nur 2 Takte !!
Extremfall: man kopiert z.B. mit Offset zu beiden Pointern einen Wert vom Programmspeicher ins RAM: MOV.W 0300h(R7), 0300h(R12) Benötigt 6 Takte und im schlimmsten Fall 3 Worte Speicher. Mit dem AVR ist eine gleichwertige Operation doch recht lästig.
IRQs dauern beim MSP 6 Takte Latenz bis zum ersten Befehl in der Routine + 5 Takte für den RET. RETI braucht aber auch beim AVR 4 bis 5 Takte, je nach Länge des Programmzählers (für die meisten Typen 4 Takte). Latenz ist auch min. 4 Takte, wobei Instruktionen mit mehreren Takten Länge erst beendet werden, was sehr oft zusätzliche Verzögerungen bringen wird. Ein großer Vorteil der MSPs ist es auch, daß beliebige Port-PINs als Interrupt-Quellen dienen können.
Bezüglich der Taktraten ist anzumerken, daß der MSP auch jetzt schon mit 16 MHz verfügbar ist (2000er Linie), was sich in Zukunft sicher ausbauen wird. Atmel wird natürlich ebenfalls die Chips weiterentwickeln.
Ein Streit um den besten Controller hat sich nie gelohnt. Es sind immer wieder Anwendungen denkbar, wo gewonnene Ergebnisse nicht mehr stimmen oder ein dritter Controller wieder sein Spezialgebiet hat. Es läßt sich jedoch eindeutig sagen, daß der MSP für Tabellenbearbeitung wie Kennfelder im MCUs sich besonders eignet. Habe ihn auch für FIR Filter eingesetzt, was einfach elegant auch in ASM zu coden ist. 12 Bit ADC Werte geschwind aufaddiert und fertig! Direkt jeweils ADD-Befehl zwischen ADC-Ergebnis und SRAM angewendet! Aktuelle Devices haben auch sehr leistungsstarke ADCs mit 16 Bit und einigen 100k samples. Und DACs.
Ein Vorteil der AVRs ist für mich das Gehäuse: auch als DIL lieferbar ist es mit einfachsten Mitteln auch ohne Headerboards einsetzbar. Und das STK500 ist den für den MSP verfügbaren Entwicklerboards überlegen. Auch mit dem AVR Studio läßt es sich in ASM gut arbeiten.
Habe die CPU Reihenfolge gemischt+falsch genannt. Korrekt ist diese Abfolge:
-MegaSquirt: MC68HC908 (8 Bit, Leistunghsdaten vergleichbar mit AVR)
-MegaSquirt-II: HC9S12C32 (16 Bit)
-MegaSquirt Ultra: MCF5234 (32 Bit)
Nehmen wir an, die Tabelle sei mit 8-Bit-Werten gefüllt (sonst unfair). Jedoch 16 Bit Pointer, da 64kB Adressraum. Ausgangspunkt: der Pointer ist schon vorher berechnet worden und existiert nun als 16 Bit-Wert in einem bzw. 2 Registern. Es soll der an dieser Stelle im Programmspeicher hinterlegte Wert in ein Register kopiert werden.
Atmel:
-Adresse aus Register in HIGH und LOW vom Pointer Z laden. Benötigt 2x MOV von Register zu Register, also 2x 1 Takte.
-Den hinter dem Pointer abgelegten Wert aus dem Programmspeicher in ein Register laden. Benötigt 1x LPM, also 1x 3 Takte. [Bei Daten im SRAM geht es einen Takt schneller].
Summe: 5 Takte.
MSP: Der MOV Befehl beim MSP hat Quelle und Ziel vertauscht.
-Kopieren der Adresse vom Register zu Pointer entfällt, da jedes Register selbst schon als Pointer benutzt werden kann.
-Den Wert aus dem Programmspeicher laden: MOV.B @R9, R8
Der Wert hinter dem Pointer R9 wird als Byte (.B) ins Register R8 kopiert.
Der Indirekte Registermodus benötigt nur 2 Takte !!
Extremfall: man kopiert z.B. mit Offset zu beiden Pointern einen Wert vom Programmspeicher ins RAM: MOV.W 0300h(R7), 0300h(R12) Benötigt 6 Takte und im schlimmsten Fall 3 Worte Speicher. Mit dem AVR ist eine gleichwertige Operation doch recht lästig.
IRQs dauern beim MSP 6 Takte Latenz bis zum ersten Befehl in der Routine + 5 Takte für den RET. RETI braucht aber auch beim AVR 4 bis 5 Takte, je nach Länge des Programmzählers (für die meisten Typen 4 Takte). Latenz ist auch min. 4 Takte, wobei Instruktionen mit mehreren Takten Länge erst beendet werden, was sehr oft zusätzliche Verzögerungen bringen wird. Ein großer Vorteil der MSPs ist es auch, daß beliebige Port-PINs als Interrupt-Quellen dienen können.
Bezüglich der Taktraten ist anzumerken, daß der MSP auch jetzt schon mit 16 MHz verfügbar ist (2000er Linie), was sich in Zukunft sicher ausbauen wird. Atmel wird natürlich ebenfalls die Chips weiterentwickeln.
Ein Streit um den besten Controller hat sich nie gelohnt. Es sind immer wieder Anwendungen denkbar, wo gewonnene Ergebnisse nicht mehr stimmen oder ein dritter Controller wieder sein Spezialgebiet hat. Es läßt sich jedoch eindeutig sagen, daß der MSP für Tabellenbearbeitung wie Kennfelder im MCUs sich besonders eignet. Habe ihn auch für FIR Filter eingesetzt, was einfach elegant auch in ASM zu coden ist. 12 Bit ADC Werte geschwind aufaddiert und fertig! Direkt jeweils ADD-Befehl zwischen ADC-Ergebnis und SRAM angewendet! Aktuelle Devices haben auch sehr leistungsstarke ADCs mit 16 Bit und einigen 100k samples. Und DACs.
Ein Vorteil der AVRs ist für mich das Gehäuse: auch als DIL lieferbar ist es mit einfachsten Mitteln auch ohne Headerboards einsetzbar. Und das STK500 ist den für den MSP verfügbaren Entwicklerboards überlegen. Auch mit dem AVR Studio läßt es sich in ASM gut arbeiten.
-
Frank
Was ich bei unserem Projekt anders realisieren wollte:
-Eine Linie mit weniger Optionen, da sonst zu zerklüftet und schwer zu pflegen
-Ansteuerung für Einspritzventile mit aktiver Entmagnetisierung auf hohem Potential und Energierückgewinnung. D-C-Snubber mit 100V liefert über primitiven Tiefsetzsteller Energie zurück. Daher keine Ballastwiderstände und keine Wärme. Je nach Ventil Ansteuerung mit 12V (bei niedriger Impedanz) oder mit hochgesetzter Spannung aus DC-DC Wandler.
-Ansteuerung der Zündspulen erfolgt nicht nur mit 12V, sondern optional mit hochgesetzter Gleichspannung. Optional jedoch deshalb, weil die Lösung der Doppelfunkenspulen bei den Drehzahlen nicht so schnell an ihre Grenzen kommt. Jedoch gibt es Spulensätze, die hier kritisch sind (Honda Bol d'Or und Verwandte). Auch im PKW Bereich gibt einige Exemplare, wo das Zündsystem insgesamt am Limit läuft und bei Spannungseinbrüchen schnell Zündaussetzer auftreten.
-Eine Linie mit weniger Optionen, da sonst zu zerklüftet und schwer zu pflegen
-Ansteuerung für Einspritzventile mit aktiver Entmagnetisierung auf hohem Potential und Energierückgewinnung. D-C-Snubber mit 100V liefert über primitiven Tiefsetzsteller Energie zurück. Daher keine Ballastwiderstände und keine Wärme. Je nach Ventil Ansteuerung mit 12V (bei niedriger Impedanz) oder mit hochgesetzter Spannung aus DC-DC Wandler.
-Ansteuerung der Zündspulen erfolgt nicht nur mit 12V, sondern optional mit hochgesetzter Gleichspannung. Optional jedoch deshalb, weil die Lösung der Doppelfunkenspulen bei den Drehzahlen nicht so schnell an ihre Grenzen kommt. Jedoch gibt es Spulensätze, die hier kritisch sind (Honda Bol d'Or und Verwandte). Auch im PKW Bereich gibt einige Exemplare, wo das Zündsystem insgesamt am Limit läuft und bei Spannungseinbrüchen schnell Zündaussetzer auftreten.
-
heizer_2
So arg viel hab ich mit den MSP´s noch nicht gemacht, hab auch nur das instruktions set überflogen.
Das es jetzt schon MSP430 mit 16mhz gibt, wusste ich auch nicht (hab auch noch keine auf der Ti website gesehen).
Den avr kenn ich halt ganz gut, da ich ihn schon 4 jahre verwende.
Einen FIR Filter hab ich auch mal mit nem AVR realisiert.
Aber für sowas nehm ich dann doch lieber einen richtigen DSP.
Momentan habe ich mich gerade mit den neuen ARM9´s angefreundet. Allerdings sind diese dann schon für richtige embeddet systeme (linux) geeignet, und für steuerrungssachen haben diese zu wenig MCU funktionalität.
Das es jetzt schon MSP430 mit 16mhz gibt, wusste ich auch nicht (hab auch noch keine auf der Ti website gesehen).
Den avr kenn ich halt ganz gut, da ich ihn schon 4 jahre verwende.
Einen FIR Filter hab ich auch mal mit nem AVR realisiert.
Aber für sowas nehm ich dann doch lieber einen richtigen DSP
.Momentan habe ich mich gerade mit den neuen ARM9´s angefreundet. Allerdings sind diese dann schon für richtige embeddet systeme (linux) geeignet, und für steuerrungssachen haben diese zu wenig MCU funktionalität.
-
Frank
MSP hatte ich vor einiger Zeit für eine Studienarbeit eingesetzt. Vor Beginn mochte ich diesen Ökoprozessor garnicht, heute habe ich mich mit ihm angefreundet. Ein lästiges Problem ist, daß die neu erscheinenden Typen nicht mehr 5V tolerant sind. Während das bei dem portablen Einsatz okay ist, stört es doch an mehren Stellen im industriellen Einsatz und im Hobby.
Die ARMs sind mir schon aufgefallen, habe bisher aber keine Erfahrungen damit gesammelt und auch kein Demoboard hier. Gegen Linux als Embedded-OS werde ich mich sträuben, so lange es geht! Lieber ein Multitasking-BIOS wie beim DSP.
Die ARMs sind mir schon aufgefallen, habe bisher aber keine Erfahrungen damit gesammelt und auch kein Demoboard hier. Gegen Linux als Embedded-OS werde ich mich sträuben, so lange es geht! Lieber ein Multitasking-BIOS wie beim DSP.