Servus, mich würde interessieren wie die Standardlösung für folgende Problematik in der Industrie aussieht: Nehmen wir mal einen Mikrocontroller (eher klein mit wenigen Ressourcen) in einer beliebigen Maschine, der sich dort um so ziemlich alles kümmern muss. D.h. z.B. Taster, LCD, Temperatursensor, PWM Ausgänge, Drehzahlsensor usw. Da stößt man ja schnell auf das Problem mit den parallel ablaufenden Prozessen. Wie man sowas lösen kann ist mir einigermaßen klar. Aber wie sieht das denn mit dem obigne Beispiel aus, wenn ich sehr kurze Zeiten (Drehzahlgeber) und sehr lange Zeiten (Zeitsteuerung im Sinne von Maschine immer um 9 Uhr einschalten) messen muss? Nehme ich mir dann einen Hardwaretimer, erzeuge einen Takt von <1 ms und gucke dann in der ISR welche meiner Softwaretimer gerade aktiv sind und inkrementiere dann bei bedarf die Zählvariable? Gefühlsmäßig wird die ISR doch dann relativ lange oder? Und was, wenn nun ein Prozess mal länger braucht? Schon werden meine Frequenzmessungen und die Software PWM abartig ungenau... versteht ihr einigermaßen was ivh meine? Vielleicht kann mir hier mal jemand der in der Industrie entwickelt das Schema F Vorgehen in so einem Fall beschreiben. Gruß, Entwickler
Entwickler schrieb: > Nehmen wir mal einen Mikrocontroller (eher klein mit wenigen Ressourcen) > in einer beliebigen Maschine, Das passt nicht zusammen. Entwickler schrieb: > Schon werden meine Frequenzmessungen und die > Software PWM abartig ungenau... Entweder per Interrupt oder einen größeren µC mit mehr Leistung. Oder die besagte eierlegende Wollmilchsau. Noch etwas: Hast Du schon einmal einen µC in der Hand gehabt?
Entwickler schrieb: > Schon werden meine Frequenzmessungen und die > Software PWM abartig ungenau... versteht ihr einigermaßen was ivh meine? Nein. Definiere erstmal "abartig ungenau". D.h. gib die konkreten Frequenzen an und den tolerierbaren Fehler. Viele MCs haben eine Input-Capture Funktion und damit ist die Messung unabhängig von Programmlaufzeiten. Für SW-PWM kann man das gleiche erreichen, indem man die Ausgänge mit einem HW-PWM Ausgang latcht. Man braucht dann ein externes Latch (z.B. 74HC595 oder 74HC574).
m.n. schrieb: > Noch etwas: Hast Du schon einmal einen µC in der Hand gehabt? Ja, klar und nicht nur einmal ;) Habe Erfahrungen mit Atmel und Freescale Controllern. Ich möchte jetzt eben lernen wie man an diverse Probleme in der Industrie ran geht, um sowas mal auszuprobieren im kleineren Stil. Erfahrungen sammeln schadet ja sicher nicht im Hinblick auf den Beruf dann. Da gibt's ja auch meistens viel Lesestoff. Also manche Aufgaben machen eben für mich den Eindruck als wären sie von einem 8bit Prozessor mit ~8 MHz ressourcentechnisch noch zu bewältigen, wenn man viel Zeit für die Softwareentwicklung aufbringt. Sich das immer wieder neu zu überlegen lohnt aber doch manchmal nicht. Greift man dann tatsächlich einfach aus Bequemlichkeit zum größeren Controller wo man nicht so auf die Ressourcen achten muss oder könnte man sich da nicht mal eine Art minimal OS machen, das sich in der Grundstruktur auf viele Controller übertragen lässt?
Ein erfahrener Entwickler wird abschätzen, was er an Ressourcen mindestens braucht. Dann fordert er das Vierfache und lässt sich von den BWLern um 50% herunterhandeln. Damit sind dann beide Seiten zufrieden. Merke: Im Laufe des Entwicklungsprozesses steigen die Anforderungen laufend und irgendetwas hast du bestimmt vergessen. Also immer mit viel Reserven planen. PWM und Ticker mit nur einem Timer ist ungeschickt. Das würde ich immer trennen. Sonst gibt es Gewürge. Alle Ticker abhängigen Aufgaben tragen sich in eine Liste ein. Bei jedem Interrupt schaut der Ticker nach, ob nun eine Aufgabe gestartet werden muss. Wenn ja, wird der Task aktiviert und fertig. Wichtig ist, die Ticker-ISR (wie alle anderen ISRs auch) so kurz wie möglich zu halten. Es ist sinnvoll, sich schon beizeiten um ein RTOS zu kümmern. Da gibt es mittlerweile ausgereifte und bezahlbare Lösungen. Man muss nicht alles selbst neu erfinden.
@Peter Also ich habe jetzt hier kein konkretes Projekt, wo ich was lösen muss. Aber nehmen wir mal an Messung von 500 KHz mit +- 10 Hz und PWM für einen Servomotor o.ä. mit Toleranz von max. 1%.
Entwickler schrieb: > Aber nehmen wir mal an Messung von 500 KHz Diese Frequenz misst man (bei Taktraten von <100MHz) nicht über Taktanzahl einer Periode sondern man misst die Anzahl von Perioden für eine bestimmte Torzeit. Je länger die Torzeit desto genauer, aber desto länger dauert halt eine Messung und das Ergebnis.
Hi Ich lass jetzt mal die Ausstattung und Leistungsfähigkeit außer acht und erzähl einfach mal, wie bei mir Programmaufbau aussieht. Vielleicht wird dadurch deutlich, wie auch große Maschinen mit all ihren kleinen Nebentätigkeiten zurecht kommen. 1. Grundsatz: Auch Multitasking läuft in einer Schleife ( aber schlagt mich nicht dafür) 2. Grundsatz: Der "Bearbeiter" reagiert auf Ereignisse Wie sieht das bei mir aus: Beispiel: Es gibt einen Timerinterrupt, der Ein Byte mit Zeitflags beschreibt: z.B. 1 mSek, 10 mSek etc. Also Zeitereignisse, die in meinem Programm benötigt werden. Schnelle und im detail kurze Impulse werden mit Interrupteingängen erfasst und eine Vorverarbeitung in der ISR durchgeführt. z. B. einen Zähler hochsetzen. Serielle Daten werden ebenfalls über Interrupt in einen Ringpuffer geschrieben. Außer diesen Ereignissen gibt es natürlich noch die unkritischen langsamen Signale. Diese werden im Polling erfasst und ebenfalls in Ereignisflags nach Entprellung geschriben. Nun hat die Schleife vom Hauptprogramm alle Zeit der Welt, sich um diese Ereignisse zu kümmern. Sie fragt die Zeitflags ab, führt evtl. eine Bearbeitung durch und setzt dann das Flag zurück. Bei Zählern wird mit einem alten Stand verglichen und bei Abweichung evtl. etwas neu berechnet. Den Ringpuffer früft man duch Vergleich von Schreib- und Lesezeiger und die normalen Signaleingänge ebenfalls über die Flags oder Bits. Wichtig: Nach der Bearbeitung wird das Ereignis wieder gelöscht und erst ein neues Ereignis ruft die zugehörigen Routinen auf. Das hält ein Hauptprogramm rel. klein in der Zykluszeit. Außerdem sind soche Programme leicht pflegbar, weil neue Ereignisse lediglich in der Programmschleife abgefragt und eine Beahandlung, ein Task, wenn du willst, aufgerufen werden muss. Es ist auch leicht zu kontrollieren, ob die Routinen auch sauber arbeiten. Natürlich hat ein solches Vorgehen auch Nachteile, aber die sind so gering und fallen für Standartaufgaben kaum ins Gewicht. Ich hoffe, das du dir nun vorstellen kannst, wie "Multitasking" funktionieren könnte.... Gruß oldmax
Entwickler schrieb: > Aber nehmen wir mal an Messung von 500 KHz mit +- 10 Hz und PWM für > einen Servomotor o.ä. mit Toleranz von max. 1%. Messung: von - bis, Meßdauer 1ms oder 10s? Toleranz: der Spannung, der Drehzahl, der Positiongenauigkeit? Warte ab, bis Du ein konkretes Problem hast. Alles andere wird Spinnerei oder heiße Luft - wie immer!
Nachtrag: Eine Messung von 500 KHz bei max. Fehler von +-10Hz also 0,002% müsstest du (einen hochgenauen Oszillator vorausgesetzt) bei Torzeitmessung mindestens 0,1s lang messen, bei Messung der Taktrate bräuchtest du einen Oszillator mit mindestens 5*10e5*5*10e4 = 2,5*10e10 also 25 GHz. Wenn ich nmich nicht verrechnet habe.
Das war dann wohl doch etwas utopisch wie ich sehe... So sehr ins Detail wollte ich eigentlich gar nicht gehen. Martin Vogel und Georg G. eure Beiträge haben mir geholfen!
Hi Dann haben sie ihren Zweck erfüllt. Gruß oldmax
Martin Vogel schrieb: > Dann haben sie ihren Zweck erfüllt. Auf alle Fälle. Sie zeigen zumindest, dass ich mit meiner (hier nicht geäußerten) Einstellung nicht alleine dastehe. ;-) ...
Würde mich freuen, wenn noch mehr Leute hier ihre Vorgehensweise erläutern würden :-)
Auch ein Ansatz ist die Einteilung in harten und weichen Tasks. Harte Tasks über Timer für Messaufgaben und den Signalpfad. z.B.: 1ms 10ms ... Weiche Tasks für LCD, etc. z.B.: frühestens nach 10ms / 100ms wenn er erst nach 101 oder 106ms kommt ist egal. Und größere Tasks mit Statemachines zerteilen.
Entwickler schrieb: > ... ein Mikrocontroller mit wenigen Ressourcen in einer beliebigen >Maschine,der sich dort um so ziemlich alles kümmern muss. (...) Wie oben schon erlaeutert, ist dies nicht gerade eine ideale Basis. Wie oben ebenfalls schon erlaeutert: - Für Drehzahlmessung benutzt man Input-Capture - Für PWM einen entsprechenden Timer mit entsprechendem Ausgang Meine persönliche Software-Strategie ist die: Wenn MCU grenzwertig arbeitet (ich gehe aber immer noch von einer Taktrate von 8MHz aus), implementiere ich einen 100us Timer und hechle im MainLoop alle notwendigen Funktionen durch. Auch Interrupts (Uart oder was auch immer) setzten nur ein Flag, der ebenfalls von dieser Mainloop abgearbeitet wird. Bis heute ist es mir nur einmal passiert, dass ich diesen Timer auf 10us setzen musste. Wenn ich etwas mehr Resourcen habe, setze ich als Scheduler Protothreads von Adam Dunkels ein. Aber obiges Prinzip bleibt dasselbe. Und wenn ich dann aus den Vollen schöpfen kann, nehme ich ein RTOS (scmRtos). Damit zu arbeiten macht am meisten Spass.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.