Mhz Signale in Khz Applikation messen

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

Pulslänge über Tiefpass mitteln und ADC wandeln?

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

Ist irgendwie dieselbe Aufgabenstellung wie das hier, oder?
Beitrag "Maximale Abtastrate mit FPGAs"

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

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