www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik MC mit 4 capture-Eingängen?


Autor: crazy horse (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kennt einer einen? AVR wäre mir am liebsten, habe aber keinen gefunden.
Das ganze wird ziemlich zeitkritisch werden, hier gehts um 4
ABS-Sensoren auf CAN, mit normalen ext. Interrupts werde ich
wahrscheinlich nicht auskommen, da rel. viel CAN-Kommunikation via
Interrupt läuft. Bitte keine Laien-Hinweise auf ABE, Versicherung etc.
:-)

Autor: der inoffizielle WM-Rahul (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Pinchange-Interrupt vielleicht?
Bei jedem Interrupt halt einen Timerwert sichern...

Autor: Dietmar (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Falls auch eine andere Controllerfamilie in Frage kommt:

Arbeite zur Zeit mit den Philips LPC2000-Serien (ARM7), z.B. LPC2129,
benötige dort auch Capture und CAN. Meine Capture-Interruptfrequenz
liegt bei bis zu 100 kHz. Die Auflösung ist für mich noch ganz
passabel, da der Timer mit 60 MHz zählen kann. Nebenbei sendet,
empfängt und sortiert die CAN-Software noch mal eben 1000 Messages pro
Sekunde, und laufen fast alle weiteren vorhandenen Peripherals. Die
LPC2000 haben insgesamt 8 Capture Inputs, je 4 auf 2 Timer aufgeteilt.
Da man einen Timer für Zeitrastergenerierung o.ä. benötigt, steht der
andere Timer dann mit 4 Capture-Inputs zur freien Verfügung.

Eval-Boards gibt es z.B. von Keil, Hitex, IAR, oder hier im Shop auch
von Olimex.

Gruß

Dietmar

Autor: crazy horse (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jo, das schaut nicht schlecht aus, wollte sowieso mal mit den ARMs
anfangen. Stellt sich wieder das Compilerproblem, Keil oder IAR will
ich mir für vorläufig 1 Projekt nicht unbedingt antun.
Besten Dank, den schau ich mir mal näher an.

Autor: Jens D. (jens) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo
http://www.msc.de/d/newsletter/atmel/newsletter_12.html
Recht Preiswer fuer Einsteiger in die ARM Welt..

und ein SAM7S32 ist auch nicht sonderlich teuer

Gruss

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der AT89C51CC01 hat neben den 3 Timern (davon T2 mit 1*Capture) noch ein
PCA mit 5*Capture/PWM-Einheiten und CAN.

Er hat auch 4 Interruptprioritäten, d.h. wenn die Capture sauschnell
sein müssen, können sie ja einfach den CAN-Interrupt unterbrechen.

Compiler wären z.B. SDCC, Wickenhäuser, Keil


Peter

Autor: Gast ein Anderer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Für ARM’S gibt es ja WINARM.
Mit CAN und viel capture-inputs fällt mir noch die Fujitsu - F²MC-16LX
Familie ein.
Kostenlose CD mit Datenblättern und Software, Workbench (wohl auch C)
Gibt es bei Glyn. Ich kenne diese Prozessoren allerdings nicht aus
eigner Erfahrung. Eval-Boards sind bei Glyn aber meist sehr günstig.
Gruß

Autor: Dietmar (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Und noch eine Betrachtung:

Habe Ende 2004 eine qualitative Energieverbrauchsmessung zwischen
SiLabs C8051F0120 (8051-Derivat, 100 MHz) und Philips LPC2129 (ARM7, 60
MHz) gemacht.

Dort liegt der 32 Bitter bei gleicher Taktrate deutlich unter dem 8
Bitter, allein das ist eine reife Leistung.

Er generiert für Mathematik deutlich effizienteren und kleineren Code:

Für Embedded Anwendungen macht er bisher "verbotene" Floating Point
Berechnungen, die schneller sind als Integer-Arithmetik.

Was soll ich da sonst noch sagen?

Gruß

Dietmar

Autor: Robert (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Crazy Horse
Compiler fuer LPC2129? Obwohl ich ehrlich gesagt Keil und IAR am
liebsten mag, es gitb auch Rowley, basierend auf GNU aber eigene Libs
und sehr guten Support, WinARM wie bereits erwaehnt und noch ein paar
andere GNU basierende Implementierungen.
Einsteiger Boards koennten sein:
http://www.keil.com/MCB2100
http://www.embeddedartists.com/products/boards/lpc...
http://www.olimex.com/dev/lpc-h2129.html

@ Jens
SAM7S hat keinen CAN
@ Peter
Wuerdest Du ehrlich heute noch mit einem AT89C51CC01 anfangen. Der
kostet aehnlich wie der LPC2119 hat deutlich weniger Funktionen und
einen Bruchteil des Speichers.

Gruss, Robert

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Robert

"Wuerdest Du ehrlich heute noch mit einem AT89C51CC01 anfangen."

Na klar, er ist ein sehr zuverlässiges Arbeitspferd und ich kenne alle
seine Macken (er hat keine).

Außerdem ist der Keil Compiler sehr effizient und schnell. Floating
point setze ich natürlich auch ein, er hat ja genügend Flash (32kB).

Ich hab sogar mal alle 4 Interruptprioritäten benötigt (der LPC hat ja
nur 2).

Irgendwo gabs mal nen Flyer, daß er besonders für den rauhen Einsatz in
Kfz spezifiziert wurde.


Wir setzen auch die LPC2xxx ein, aber die sind doch sehr kompliziert.
Der Kollege, der ihn programmiert, hat allein 2 Wochen gebraucht, um
dem Spurious Interrupt Bug auf die Schliche zu kommen und den
Workaround aufzusetzen. Er machts entgegen der Application Note (keinen
verdoppelten Handler sondern nur nen Dummy) und es scheint trotzdem zu
funktionieren.
Und der Bug, daß man die PLL ausschalten muß, bevor man ein bestimmtes
Register ändert, hat ihn auch Nerven gekostet.


"Der kostet aehnlich wie der LPC2119 hat deutlich weniger Funktionen
und einen Bruchteil des Speichers."

Der Preis eine MC schlägt sich im Preis des kompletten Gerätes kaum
nieder und mehr Features nützen überhaupt nichts, wenn ich sie nicht
brauche.
Weniger Entwicklungszeit (Erfahrungen, Bugsuche) hat aber schon einen
erheblichen finanziellen Wert (Time to market).


Peter

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Dietmar

"Für Embedded Anwendungen macht er bisher "verbotene" Floating
Point
Berechnungen, die schneller sind als Integer-Arithmetik."


Float schneller als int auf ner CPU ohne float-Coproz.

Das solltest Du aber schleunigst als Patent anmelden !

Oder war das nur ein verspäteter Aprilscherz ?


Ich hab auch nicht gewußt, daß float verboten war, ich habs die ganzen
Jahre aufm 8051 verwendet. Krieg ich nun ne Strafanzeige ?

Es kommt doch immer darauf an, wo man es benutzt. Um einen Zahlenwert
zu berechnen und anzuzeigen, kostet float kaum CPU-Zeit, die benötigte
Ablesezeit des Meschen ist um ein vielfaches länger.
In einem schnellen Interrupthandler könnte float aber ungünstig sein
(auch beim LPC).


Peter

Autor: Dietmar (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Peter:

>Float schneller als int auf ner CPU ohne float-Coproz.
>Das solltest Du aber schleunigst als Patent anmelden !
>Oder war das nur ein verspäteter Aprilscherz ?

Nein, das haben die Typen von ARM schon erledigt, und ohne Coprozessor.
Bei 32 Bit ist vieles anders. Wie gesagt, 32 Bit rechnet verdammt
schnell gegen 8 Bit, da effizienterer Code. Probier's doch einfach
aus, und du wirst sehen.

Mit Float Coprozessor gibt es dann noch mal einen Schub, wenn man es
braucht. Aber, wie gestaltet sich das eigentlich, wo bekäme ich einen
passenden Co-Prozessor her, wenn ich noch mehr Performance für den LPC
brauchte?

>Ich hab auch nicht gewußt, daß float verboten war, ich habs die
>ganzen Jahre aufm 8051 verwendet. Krieg ich nun ne Strafanzeige ?

--> Ab mit dir ins Mikrocontrollerforum-Gefängnis, sofort:-)

Na, Floating Point und Echtzeit auf dem 8051, da wissen wir doch beide,
wie das ausfällt. Habe schon zu Zeiten, als Windows gerade aufkam, auf
DOS und per Assembler 8051 Divisionen und BIN-BCD Wandlungen
implementiert. Und die sind schrecklich lang. Wenn man nicht gerade
einen 80C517 mit integriertem MDU Peripheral verwendet.

Übrigens, kann man sich erweiterte Interruptprioritäten beim ARM in
Software gestalten (z.B. Nested Interrupt Technik). Man ist dann sogar
noch flexibler und frei in der Gestaltung. Und Interrupt-Handler per
Software: Das Ding ist ja irre schnell genug. Mir reicht zur Zeit die
Standard-Priorisierung und der FIQ. Da ist das Ding für mich
maßgeschneidert.

>Wir setzen auch die LPC2xxx ein, aber die sind doch sehr kompliziert.
>Der Kollege, der ihn programmiert, hat allein 2 Wochen gebraucht, um
>dem Spurious Interrupt Bug auf die Schliche zu kommen und....

Ja, ergeht mir hier leider ebenso. Da könnte man sich, wenn man wollte,
aber austauschen, hier über das Forum, damit es für jeden was einspart,
oder? Mal 2 Wochen für dieses, dann 2 Wochen für jenes, die Krönung war
letztens, daß Keil den CARM-Compiler eingestellt hat und als Ersatz
einfach ARM RealView empfiehlt. Und wieder 2 Wochen, z.B. Erstellung
von Scatter Description Files ohne jegliche Beispiele, etc.:-(

Wir haben einfach nur versucht, für unsere Anwendung einen passenden µC
zu finden, der auch für die nächsten 3-5 Jahre noch genug Futter in
Performance bietet. Natürlich, gibt es unter der immensen Auswahl an µC
immer bessere oder schlechtere. In welche Nesseln wir uns im Detail
setzen, war bei der Auswahl nicht abzusehen. Hier 2 Wochen, da 2 Wochen
für irgendwelchen Firlefanz, mein Chef ist da manchmal etwas säuerlich,
ich auch, denn wir wollen nicht, sondern müssen mit der
"zuverlässigen" Anwendung auch mal Geld verdienen.

Gruß

Dietmar

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.