-
        

Ergebnis 1 bis 9 von 9

Thema: Industrieprojekt / Schafft das ein Mega128 ?

  1. #1

    Industrieprojekt / Schafft das ein Mega128 ?

    Anzeige

    Hallo,

    bin zur Zeit bei der Auswahl eines µC für unser Studienbedingtes Industrieprojekt. Es geht dabei um Sensorerfassung eines Formula Student Fahrzeugs.
    Zu erledigen ist folgendes mit annähernd Echtzeitbedingungen (werden wir sowieso nicht hinbekommen, aber mit kompletten Auslesezyklen von gut 1 bis 2 Sekunden wäre ich schon sehr zufrieden):
    - Datenerfassung aus einem Steuergerät über RS232 (eigentlich kein Problem, Daten müssen nur gelesen werden, keine Bearbeitung notwendig)
    - Erfassung von 4x Induktiven Werten zur Drehzahlbestimmung an jedem Rad (Thema ABS-Ring, Sensorerfassung)
    - Erfassung von Öltemperatur
    - Erfassung von Öldruck (beides wohl eher ein kleineres Problem)
    - Geschwindigkeitserfassung von Getriebe
    - Beschleunigung und Querkräfte über G-Sensor
    - Erfassen von 4 Drucksensoren für Federwege
    - Speichern der Daten auf einer SD-Karte
    - übermitteln der Daten über RS232 und entweder RN-Funk oder GSM ö.ä.
    - Möglichkeit der BUS-Übertragung (TWI) der Raddrehzahl an weiteren Mega

    Denkt ihr, dass ist mit einem ATMega bei 16 MHz Taktung möglich oder wäre dann gleich der Schritt zu einem ARM oder FPGA besser?

    Was meint ihr?

    Danke

    Michl

  2. #2
    Erfahrener Benutzer Roboter Experte
    Registriert seit
    30.07.2005
    Beiträge
    569

    Re: Industrieprojekt / Schafft das ein Mega128 ?

    Zitat Zitat von Crashmichl
    - Datenerfassung aus einem Steuergerät über RS232 (eigentlich kein Problem, Daten müssen nur gelesen werden, keine Bearbeitung notwendig)
    Möglich

    Zitat Zitat von Crashmichl
    - Erfassung von 4x Induktiven Werten zur Drehzahlbestimmung an jedem Rad (Thema ABS-Ring, Sensorerfassung)
    Möglich

    Zitat Zitat von Crashmichl
    - Erfassung von Öltemperatur
    Möglich

    Zitat Zitat von Crashmichl
    - Erfassung von Öldruck (beides wohl eher ein kleineres Problem)
    Möglich

    Zitat Zitat von Crashmichl
    - Geschwindigkeitserfassung von Getriebe
    Möglich, an welche Art der Datenerfassung hast du gedacht ?

    Zitat Zitat von Crashmichl
    - Beschleunigung und Querkräfte über G-Sensor
    Möglich

    Zitat Zitat von Crashmichl
    - Erfassen von 4 Drucksensoren für Federwege
    Möglich

    Zitat Zitat von Crashmichl
    - Speichern der Daten auf einer SD-Karte
    Möglich, würde ich aber auslagern (z.B. auf einen zweiten ATmega)

    Zitat Zitat von Crashmichl
    - übermitteln der Daten über RS232 und entweder RN-Funk oder GSM ö.ä.
    Möglich, würde ich aber auslagern (z.B. auf einen zweiten ATmega)

    Zitat Zitat von Crashmichl
    - Möglichkeit der BUS-Übertragung (TWI) der Raddrehzahl an weiteren Mega
    Möglich.


    Bei grober Betrachtung ist eine Vielzahl dieser Aufgaben mit einem Mikrocontroller möglich. Allerdings ist dieses unter anderem von den verwendeten Sensoren abhängig. Ein paar Details wären dazu recht interessant.

    Grüße,
    Hanni
    Grundregeln des Forenpostings:
    1. Nutze niemals die Suchfunktion!
    2. Überprüfe niemals die Topics nach Ähnlichkeiten!
    3. Schreibe alles in hellgelb!

  3. #3
    Serri,

    danke für die schnelle Antwort.
    Bislang weiß ich noch nichts über die Sensorik, weil ich bis dato noch nicht weiß, welche Hardwarebedingt (muss Anschlussmöglichkeiten am Motor/Getriebe berücksichtigen - den habe ich bislang noch nicht gesehen), da wir momentan noch bei einer groben "Stoffsammlung" sind. Das alles einzeln möglich ist, habe ich schon fast vermutet. Allerdings werde ich wohl nur einen Controller zur Verfügung haben. Desweiteren vermute ich, dass ein GPS Sensor noch benötigt wird, um die Position anschließend wieder rekonstruieren zu können.
    Das Auslesen über RS232 des Steuergerätes und das Erfassen des Drucks und der Temperatur macht mir auch nix, eher habe ich Angst, dass ich den kleinen Mega dann überfordere...

    Grüßle

    Michl

  4. #4
    Erfahrener Benutzer Roboter Experte
    Registriert seit
    30.07.2005
    Beiträge
    569
    Naja, ich sehe eigentlich nur einen etwas störenden Punkt bei der ganzen Angelegenheit: die SD Karte ... die Schreib Lese Routinen dafür dürften echte Zeitfresser sein ....

    Die üblichen GPS Empfänger kann man übriges recht gut über eine serielle Schnittstelle auslesen (Stichwort NMEA).
    Je nach zu der Datenmenge würde ich evtl noch etwas externen RAM vorsehen.

    Insgesamt ist es sicherlich möglich auch ohne 1-2 Sekunden lange Auslesezyklen.
    Grundregeln des Forenpostings:
    1. Nutze niemals die Suchfunktion!
    2. Überprüfe niemals die Topics nach Ähnlichkeiten!
    3. Schreibe alles in hellgelb!

  5. #5
    Hmm... OK... am Montag früh haben wir einen Termin mit nem Prof wegen dem Thema, dann werde ich in jedem Fall einen ATMega vorschlagen...
    Vielleicht verteile ich doch lieber auf 2 ATMega.
    Daten wie Drehzahl und Federweg liest der eine ein, die sollen in recht flotten Zyklen gelesen werden, die anderen Daten sammelt ein zweiter, da stören längere Zyklenzeiten eher weniger.
    Kommunikation über TWI auf einen dritten kann man dann auch vorbereiten und gut is.

    Danke für deine Hilfe

    Michl

    EDIT: Das schreiben auf SD kann dann auch der zweite machen....

  6. #6
    Erfahrener Benutzer Robotik Einstein Avatar von SprinterSB
    Registriert seit
    09.06.2005
    Ort
    An der Saar
    Beiträge
    2.801
    Zitat Zitat von Crashmichl
    Das schreiben auf SD kann dann auch der zweite machen....
    SPI und FAT32 sind ja keine Hexerei. Aber:

    [-( Bevor du vor Anfang des Projekts schon einen dritten µC sinnierst, nimm lieber nen gscheiten Controller...

    Für ein solches Projekt ist ein TriCore wesentlich besser geeignet! (Und wird auch in der Industrie für Automotive dafür eingesetzt).

    Schau dir mal bei Infineon den TC1796 an.

    An Peripherie hast du dann:

    ASC (asynchrone, serielle Schnittstellen), SSC (synchrone, serielle Schnittstellen), MLI, CAN, IrDA, GPTA (ca 96 Timer-Zellen, geeignet für mehrere synchrone 3-Phasen-PWM und komplexere Wellenformen), FPU, schnelle ADC, programmierbare PLL, CDU, Quadratur-Decoder, bis 150MHz CPU-Takt, OCDS, JTAG, EBU (32 Bit Daten, bis 32 Bit Adresse), 32-Bit-Maschine, Protection, Code ist aus dem RAM ausführbar, Unterstützung von Watchpoints, Protection, DSP-fähig, Leistungsfähige C/C++-Compiler und Echtzeit-Betriebssysteme (für harte Echtzeit, d.g.*ohne* IRQ-Sperren im System-Kern!) verfügbar, ...

    Was hab ich alles vergessen...?
    Disclaimer: none. Sue me.

  7. #7
    Hallo,

    der dritte µC is nicht mein Aufgabengebiet, ich muss nur Daten bereitstellen, damit die für ein anderes Projekt abrufbar sind.
    Der TC1796 ist schön und gut, aber für so ein Studentenprojekt eher unerschwinglich. Wie gesagt, am Montag noch mal mit nem Prof hier reden, evtl. hat der eine gute Idee... wobei ich eher sage, dass die Drehzahl/Rad Erfassung wahrscheinlich sowieso gekickt wird.
    Hatte heute eine Unterhaltung mit einem Prof, der bei Bosch war. Der meinte, die haben die Daten bei ESP im ms-Takt abgefragt. Für uns hier wohl eher unrealistisch, bzw. zu teuer. Und wenn wir das in einem Semester unterbekommen, dann werden wohl bei Bosch 400 Leute entlassen und wir eingestellt (So sein sinngemässer Wortlaut)

    Gruß aus dem Frankenland

    Michl

  8. #8
    Erfahrener Benutzer Robotik Einstein Avatar von SprinterSB
    Registriert seit
    09.06.2005
    Ort
    An der Saar
    Beiträge
    2.801
    Für die geplanten Anwendungen ist einiges an Hard- und Software zu realisieren/notwendig. Die Sensoren liefern idR ihre Werte entweder als analog oder als PWM. Du brauch also mehrere schnelle ADC und nicht ne Schnarchmütze wir in der AVR-Peripherie, die zudem nur einen einzigen ADC hat und nicht mehrere (mehrer ADC-Kanäle gehen nur über t-MUX). Gleiches gilt für den CapCom (Campture & Compare) für PWM-Auswertung.

    Softwaremässig brauchst du Puffer für die Daten. Selbst wenn das Flash eines ATmega128 ausreichend ist, dem winzigen RAM geht rucki-zucki die Puste aus. Bei CapCom geht es um kleine IRQ-Latenzen, so daß du möglichst viel parallelisieren musst (also Hardware benutzen). Wenn du bei jedem Befehl nachrechnen musst, wieviel RAM der braucht und ob eine Funktion nicht einen zu großen Frame bekommt, bist du ewig am rumfrickeln.

    Vielleicht stellt der Prof die Aufgabe etwas realistischer -- verkleinert also den Graben zwischen Voraussetzungen und Anforderungen -- und nicht aus dem Elfenbeinturm raus à la
    Zitat Zitat von Aus dem Elfenbeinturm
    So was ist doch alles schon mal gemacht worden und nur schnöde Praxis, theoretisch total belanglos und nix Neues, lediglich popelige Anwendung. Die Jungs brauchen ja nur die Sensoren an einen µC zu stöpseln und ein paar Bits hin- und der zu schieben...
    Der TC1796 ist nicht sonderlich teuer, weniger als 20 Euronen. Was teuer sind, sind die Boards. Der Prof muss also nur noch ein Board besorgen, wo der billige Käfer drauf sitzt

    Immerhin setzt auch Bosch den TC1796 ein und ihr sollt in dem Projekt doch lernen, was in der Industrie abgeht um später fit zu sein für die harte Konkurrenz aus Indien und Singapur

    Wenn der Prof was taucht, dann putzt er die Klingen bei Infineon und hat ruck-zuck ein gratis-Board. Wenn es eine "Kooperation" mit der Industrie ist (will meinen: die Firma bekommt teure Entwicklerzeit für lau und ihr ein Paper und nen warmen Händedruck), ist die Firma der Ansprechpartner für gscheite Hardware.

    Aber wie auch immer...

    Viel Glück und viel Spaß beim Bosseln, Hacken und Abrauchen!
    Disclaimer: none. Sue me.

  9. #9
    Danke für den Tipp... die alternative, die wir zunächst noch rausgesucht haben ist ein FPGA, allerdings fehlt halt die Erfahrung mit VHDL.
    Unser Bosch Prof meinte, die ADWin wäre hier richtig, aber für den Betrieb zu unhandlich.
    Das große Problem dreht sich hier leider um die 2x 4 Sensoren zum Drehzahlerfassen und Federweg berechnen... ich warte jetzt zunächst mal ab, was unser E-Tech Prof dazu meint, dann muss man mal sehen

    Danke für die vielen Tips!

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •