Hallo zusammen, Ich hoffe es gab genau dieses Thema nicht schon mal. Habe allerdings auf die schnelle nichts entsprechendes gefunden. Zu den Grundlagen, die zu erwarten sind: habe Maschinenbau studiert und keine besonderen Kenntnisse, was µC oder Elektronik angeht. Und zwar experimentiere ich derzeit hobbymäßig ein wenig mit Arduinos rum. Dabei bin ich auf die Simulink Integration der Arduinos gestoßen, was für mich dann eine einfache Art der "Programmierung" darstellt, da ich mit dieser relativ vertraut bin. Durch Simulink wird die fundamentale Sample Time aus dem Modell quasi als Echtzeit-Zyklus auf den Controller eingeprägt, sodass auch die I/O Operationen auf diesem Takt (0.001s) laufen. Ein weiterer Eingriff in den Code ist wegen des geschlossenen Prozesses meiner Erfahrung nach nicht möglich, da ich nicht den Embedded Coder nutzen kann. Zum Problem: Jetzt habe ich jedoch einen Sensor, der je nach Messwert einen Puls über DigIn (etwa alle 0,25s) ausgibt, der jedoch im Bereich ~ 0.00005s / 20kHz liegt. Aufgrund der großen und unterschiedlichen Abstände der eintrudelnden Pulse hatte ich an einen Frequenzteiler gedacht. Ist das richtig? Dann müsste ich ja am Eingang wieder eine z.B. 32 x höhere Pulsdauer = 0.0016s ~ 550Hz messen können (Shannon-mäßig immer noch nicht top aber naja). Als Bauteil hatte ich den 74HC4060 im Auge. Dazu bräuchte ich dann wahrscheinlich noch einen Oszillator oder? Da würde ich dann einen 4Mhz Oszillator nehmen. Sieht das für euch so okay aus oder habe ich was elementares vergessen bzw. missverstanden, bevor ich jetzt die Komponenten bestelle? Bzw. bin ich mir immer noch nicht ganz sicher, ob das ein sinnvoller weg ist. Falls ihr Tipps habt oder Verbesserungsvorschläge, dann bin ich auf jeden Fall dankbar auch, wenn sie das "Konzept" komplett umwerfen. Was allerdings fix ist, ist für mich die simulink-basierte Programmierung. Grüße Sepp
Ist denn der Messwert des Sensors in der Impulslänge kodiert, oder dient der Impuls nur zur Info, daß eine Messung fertig ist? Oliver
Ach ja, Genau richtig interpretiert! ;) Der Messwert ist in der Pulslänge über einen Faktor zurückrechenbar enthalten. Daher muss ich die Pulslänge zumindest einigermaßen genau bestimmen können. Danke für die schnelle Antwort!
Ach was mir noch einfällt: die größte Pulslänge ist etwa ~ 0,01s 100Hz
Seppl schrieb: > Der Messwert ist in der Pulslänge über einen Faktor zurückrechenbar > enthalten. Daher muss ich die Pulslänge zumindest einigermaßen genau > bestimmen können. Hat der AVR nicht auch Capture-Timer Modi? Damit könnte man die Pulslängen in Hardware direkt mit dem µC messen.
Hi erstmal danke für die Antworten. Jim M. schrieb: > Hat der AVR nicht auch Capture-Timer Modi? Damit könnte man die > Pulslängen in Hardware direkt mit dem µC messen. Ja hat er prinzipiell ist ein ATMEGA 2560, allerdings hat man über die Simulink Geschichte nur Zugriff auf die Pins, kann leider nichts konfigurieren, was Richtung Interupt oder ähnlichem geht. Man ist da sehr eingeschränkt. :( Flo schrieb: > Pulslänge über Tiefpass mitteln und ADC wandeln? Geht mMn nicht, da nur ein einzelner Puls kommt und auch nicht in festen Abständen, sodass ich glaube, dass der Analog-In Value lediglich auf einen bestimmten Wert, je nach Pulslänge ansteigen würde und danach wieder abfällt. Prinzipiell kann man da bestimmt was über den max Wert schätzen, aber ich glaube mit Messen hat das nicht mehr viel zu tun. Wenn ich da falsch liege, würde ich mich über eine Aufklärung freuen! Grüße Sepp
Flo schrieb: > Pulslänge über Tiefpass mitteln und ADC wandeln? Im Digitalen Zeitalter in dem wir leben definitiv nicht so!
Wenn Du ein Feature des µC brauchst, für das es keinen Simulink-Treiber gibt, dann musst Du Dir einen basteln (lassen).
Johnny B. schrieb: > Im Digitalen Zeitalter in dem wir leben definitiv nicht so! Früher haben wir für sowas einen GAL gehabt. Allerdings haben die uCs doch auch inzwsichen schnelle Timer, die das können.
Hey, dankesehr. Weltbester FPGA-Pongo schrieb im Beitrag #5119156: > Ist irgendwie dieselbe Aufgabenstellung wie das hier, oder? > Beitrag "Maximale Abtastrate mit FPGAs" Ich denke es klingt vom Anforderungsspektrum her gleich. Ich wollte über vorgeschaltete Hardware versuchen das eingehende Signal im für die Applikation brauchbaren Bereich zu verlangsamen. Da darauf keiner eingegangen ist, was ich mir überlegt habe, gehe ich mal davon aus, dass es kein sinnvoller Weg ist, oder? Achim S. schrieb: > Wenn Du ein Feature des µC brauchst, für das es keinen Simulink-Treiber > gibt, dann musst Du Dir einen basteln (lassen). Um auf irgendwelche internen Funktionen des AVR zuzugreifen, müsste ich mir wohl eine Level-2 S-Function in C schreiben, was zum einen mit Aufwand (ist vermutlich schon vorhanden aber trotzdem mehr als 2 Bauteile anschließen und verkabeln) und zum anderen mit einiger Unsicherheit verbunden ist. Die Unsicherheit meinerseits kommt daher, dass ich überhaupt keine Ahnung habe, wie Simulink den Code generiert und dieser auch nicht einsehbar verfügbar ist. Sodass es auch gut sein kann, dass die S-Function falsch oder gar nicht ausgeführt wird. Des Weiteren arbeitet Simulink-Code immer mit Statemachines, sodass mir auch ein schneller Sensor im Zweifelsfall nichts bringen könnte, wenn die Modellvariablen nicht im schnelleren Takt geupdatet werden. Aber trotzdem Danke für eure Ideen!
Hey, ich denke das geht in die selbst Richtung, wie das mit den Treibern. Weltbester FPGA-Pongo schrieb im Beitrag #5119179: > Früher haben wir für sowas einen GAL gehabt. Allerdings haben die uCs > doch auch inzwsichen schnelle Timer, die das können. Ich hab "nativ" keinen Zugriff auf diese I/O, das liegt meiner Auffassung mehr an der Modell-Code Struktur und dessen Variablen Zugriff, als an den Hardware Möglichkeiten des AVR würde ich sagen.
Seppl schrieb: > Um auf irgendwelche internen Funktionen des AVR zuzugreifen, müsste ich > mir wohl eine Level-2 S-Function in C schreiben, was zum einen mit > Aufwand (ist vermutlich schon vorhanden aber trotzdem mehr als 2 > Bauteile anschließen und verkabeln) und zum anderen mit einiger > Unsicherheit verbunden ist Naja, du könntest im AVR eine Funktion haben, die dieses Signal auswertet und in Speicherstelle X oder Variable Y ablegt, zusammen mit einem Flag, ob ein neues Signal eingelaufen ist (was in der Praxis eher ein Zähler werden sollte, aber egal).
Achim S. schrieb: > Naja, du könntest im AVR eine Funktion haben, die dieses Signal > auswertet und in Speicherstelle X oder Variable Y ablegt, zusammen mit > einem Flag, ob ein neues Signal eingelaufen ist (was in der Praxis eher > ein Zähler werden sollte, aber egal). Hey danke dir! Unter normalen Bedingungen ist das auf jeden Fall eine gute Lösung. Aber ich muss für alle diese Dinge erstmal recherchieren, wie das funktionieren kann. Ich kann ohne weiteres meinem Simulink nicht sagen -> Lies Speicherstelle xy. Dafür müsste dann entsprechend wieder eine S-Function her, die die Speichervariable in das Modell holt. Somit ergibt sich dort auf jeden Fall einiges an Code, was prinzipiell an der "modelbased Idee" mit anschließender Codegenerierung vorbeigeht. Das soll jetzt nicht heißen, dass es schlecht ist,was ihr vorschlagt, sondern, dass ich mir das etwas anders vorgestellt hatte. Denn so werden auch schnelle Änderungen und die nachvollziehbarkeit im Modell deutlich geringer. Aber evtl. muss ich wegen den seitens mathworks eingeschränkten Möglichkeiten die IO-Zugriffe zu verwalten damit leben. Gibt es trotzdem jmd. der zu der von mir anfänglich angegebenen hardware-basierten Lösung noch eine Bewertung hat? Grüße Sepp
Seppl schrieb: > Ich wollte über vorgeschaltete Hardware versuchen das eingehende Signal > im für die Applikation brauchbaren Bereich zu verlangsamen. Da darauf > keiner eingegangen ist, was ich mir überlegt habe, gehe ich mal davon > aus, dass es kein sinnvoller Weg ist, oder? Wenn die Information in der Länge des Impulse liegt, dann bringt ein Frequenzteiler gar nichts, denn von der Impulslänge ist im geteilten Signal nichts mehr zu sehen. Wenn es die Frequenz der Impulse wäre, dann würde es gehen. Aber ganz allgemein ist das "von-hinten-durch-die-Brust-ins-Auge" gedacht. Ein µC kann i.d.R. ganz vorzüglich mit derart langsamen Signalen umgehen, notfalls unter Verwendung einer Capture-Einheit. Allerdings muß man ihn dafür auch "richtig" programmieren.
Ja das stimmt wohl. Ich denke ich werds wohl so machen müssen. Da ich einen zweiten Arduino besitze überlege ich gerade, ob es Sinn macht dem "richtig" programmierten das IO Handling zu überlassen und dem Modell-µC quasi die Logik zu verpassen. Das wäre evtl noch eine nette Option, die mit Bus-Kommunikation wohl auch ganz performant sein sollte und trotzdem der modelbased Ansatz zumindest für die "Intelligenz" nicht ganz verloren geht. Dann danke ich allen beteiligten für ihre Zeit! Grüße Sepp
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.