Hey zusammen, ich habe vor eine Geschwindigkeitsmessung mit Radar zu machen. Dazu muss ich eine Frequenz aufzeichnen, diese durch 44 Teilen und dann auf 3 7 Segment Anzeigen darstellen. Ich hab leider nichts wirklich hilfreiches zu Input Capture gefunden (in Assembler, C gibt es ja zu hauf). Ich hoffe ihr könnt mir weiterhelfen, wie ich bei Input Capture vorgehen muss. Grüße freakyuser
Wenn man das Datenblatt verstanden hat, sollte der Input capture nicht besonders schwerig sein. wo liegt denn das Problem ? Hardware verstanden ?
freakyuser schrieb: > Dazu muss ich eine Frequenz aufzeichnen Was heißt das? Zum Aufzeichnen über länger Zeit brauchst du hauptsächlich Speicher. In welcher Form kommt die Frequenz an, d.h. wie sie das Signal aus, das am uC ankommt?
freakyuser schrieb: > Hey zusammen, ... > > Ich hab leider nichts wirklich hilfreiches zu Input Capture gefunden (in > Assembler, C gibt es ja zu hauf). ... > Hallo, seltsam. Ok vielleicht ist es zu einfach. Also die Funktion so einer " Input Capture Unit " ist ja in etwa folgende : Ein Pin ( ICPn )der zur Input Capture Einheit gehört, muß erstmal entsprechend den Anforderungen konfiguriert werden (Eingang, Steigende oder fallede Flanke usw. ). Beim Eintreffen des Ereignisses ( z.B. steigende Flanke ) wird das Zählerregister ( TCNTn ) in das Input Capture Register ( ICRn ) übertragen. Der Zähler ( TCNTn ) zählt weiter. Diesen Wert holt man sich vor dem eintreffen des nächsten Ereignisses aus diesem Register (ICRn )und überträgt ihn in ein Arbeitsregister ( rXX ). Beim nächsten Ereignis ( wieder steigende Flanke wegen Periodendauer ) wird nun der Wert aus dem Arbeitsregitster ( rXX ) vom aktuellen Wert im ICRn subtrahiert. Aus dieser Differenz und dem Wissen wie lange ein Takt des Timer/Counter dauert ist die Periodendauer in Sekunden Errechenbar und somit auch die Frequenz f = 1 / S. Wie man mit Interrupts arbeitet weißt Du hoffentlich. Sonst solltest Du Dich da auch mal einarbeiten. Bernd_Stein
Hallo Bernd, auch wenn Dein Beitrag schon eine Weile her ist, will ich kurz mal was dazu schreiben: So wie Du das hier erklärt hast, hat das auch (hoffentlich) meine letzten Fragen zu dem Thema ICP beantwortet. Ich weiß, Du hast nur Basics angesprochen - aber es kommt manchmal auf das WIE an: Einfach, aber auf den Punkt. Auch ich habe nur C-Beispiele gefunden. In ASM war nicht wirklich was dabei. Vielleicht hat ja jemand Zeit und Lust ein schönes Tutorial mit Assembler-Beispielen zu schreiben... Schade, dass freakyuser kein Feedback mehr gegeben hat. (vielleicht sind wir ja inzwischen schonmal irgendwo von ihm gemessen worden). Danke! Gruß - Nico ;o)
Die Umsetzung von C in ASM ist in der Regel nicht so schwer. Das kann sogar schon der Compiler. Gerade wenn es um die Bedienung von Peripherie geht ist das fast nur ein Register lesen / schreiben, also noch einfacher C Code ohne große Komplikationen.
Nicolas K. schrieb: > So wie Du das hier erklärt hast, hat das auch (hoffentlich) meine > letzten Fragen zu dem Thema ICP beantwortet. > Ich weiß, Du hast nur Basics angesprochen - aber es kommt manchmal auf > das WIE an: Einfach, aber auf den Punkt. > Auch ich habe nur C-Beispiele gefunden. In ASM war nicht wirklich was > dabei. Der Witz bei den AVR besteht doch darin, dass dir die Hardware schon viel abnimmt. Die Konfigurationsregister der einzelnen Komponenten funktionieren in Assembler auch nicht anders als in C. Identische Bits bewirken dasselbe. Ist ja auch kein Wunder, handelt es sich ja immer um dasselbe Konfigurationsregister. Nur die Schreibweise zum Setzen/Löschen von Bits ist eine andere. Und beim Aufsetzen von Interrupts muss man ein bissi mehr Handarbeit machen. Wer sich allerdings in Assembler ein wenig auskennt, den stellt das sicher nicht vor Hürden. Und wegen der Rechnerei. Nun ja, deswegen benutzt man ja Hochsprachen, damit man sich da nicht um derartige Kleinigkeiten wie Rechnen mit 64 Bit selber kümmern muss.
Karl Heinz Buchegger schrieb: > Der Witz bei den AVR besteht doch darin, dass dir die Hardware schon > viel abnimmt. Die Konfigurationsregister der einzelnen Komponenten > funktionieren in Assembler auch nicht anders als in C. Identische Bits > bewirken dasselbe. Ist ja auch kein Wunder, handelt es sich ja immer um > dasselbe Konfigurationsregister. Nur die Schreibweise zum Setzen/Löschen > von Bits ist eine andere. > Und beim Aufsetzen von Interrupts muss man ein bissi mehr Handarbeit > machen. Wer sich allerdings in Assembler ein wenig auskennt, den stellt > das sicher nicht vor Hürden. > > Und wegen der Rechnerei. Nun ja, deswegen benutzt man ja Hochsprachen, > damit man sich da nicht um derartige Kleinigkeiten wie Rechnen mit 64 > Bit selber kümmern muss Hi, es ist ja nett, dass Du versuchst mir C näher zu bringen. Etwas eingelesen habe ich mich da auch schon. Aber ich programmiere seit 8051-Beginn (viele Monde her) hardwarenah in Assembler. Und bei C-Compilierungen habe ich bisher die Erfahrung gemacht, dass der entstandene ASM-Code oft recht holprig und zum Teil etwas "unsauber" ist. Ansonsten habe ich nichts gegen Hochsprachen. Zum angesprochenen Tutorial: Ich denke, dass generell die Beispiele min in ASM sein sollten (ausser natürlich bei C-Tutorials), weil damit - zumindest die meisten, die ich kenne - die Abläufe besser (weil hardwarenaher) nachvollziehbar sind. Aber da hat ja jder so seine eigene Meinung... ;o) P.S.: Das hat man davon, wenn man mal ein Lob einfließen läßt... ;-)
Nicolas K. schrieb: > Zum angesprochenen Tutorial: Ich denke, dass generell die Beispiele min > in ASM sein sollten (ausser natürlich bei C-Tutorials), weil damit - > zumindest die meisten, die ich kenne - die Abläufe besser (weil > hardwarenaher) nachvollziehbar sind. Da bin ich deutlich anderer Meinung. Wie man dir bereits mehrfach gesagt hat, ändert C ja weder am Hardwarezugriff noch am Funktionsprinzip irgendetwas. Man spart sich das Rumgeschubse ins Arbeitsregister und viele Sprünge. An der Art und Weise wie man ein gewisses Problem löst, ändert das nichts. Siehe auch: Karl Heinz Buchegger schrieb: > Die Konfigurationsregister der einzelnen Komponenten > funktionieren in Assembler auch nicht anders als in C. Identische Bits > bewirken dasselbe. Ist ja auch kein Wunder, handelt es sich ja immer um > dasselbe Konfigurationsregister. Nur die Schreibweise zum Setzen/Löschen > von Bits ist eine andere. Nicolas K. schrieb: > Und bei > C-Compilierungen habe ich bisher die Erfahrung gemacht, dass der > entstandene ASM-Code oft recht holprig und zum Teil etwas "unsauber" > ist. Der Compiler ist ja auch kein Mensch und wir veranstalten hier ja auch keinen "Schönprogrammierwettbewerb". Gerade heute ist mein Arbeitgeber daran interessiert, dass ich effektiv und übersichtlich arbeite, damit a) Zeit (also Geld) gespart wird und b) andere Leute auch am Code arbeiten können. Beides ist in Assembler deutlich schlechter als in C. Oben drein ist der von C compilierte Assemblercode (soweit es techn. Möglich ist) optimierter, als der vom Menschen. Nicolas K. schrieb: > es ist ja nett, dass Du versuchst mir C näher zu bringen. Ich persönlich halte es für unwirtschaftlich größere Projekte in Assembler zu realisieren. Sobald es mit Anzeigen (LCD, Menüführung, etc) losgeht ist es einfach nicht mehr rentabel. Wenn ich sehr zeitkritische Aufgaben habe bei denen ich Takte zählen muss, dann kann ich akzpieren, dass ich auf ASM zurückgreife. Ansonsten ist es IMHO zurückgeblieben.
Hi Na, haben wir mal wieder Pro & Contra... Nebenbei, ich bevorzuge auch Assembler. Was bitte schön ist an Assembler nicht lesbar und was ist an C so schnell, das ich meine Anwendung zig mal schneller erstelle... ? Wo sind Probleme bei Teamwork, die Schnittstellen sind doch festgelegt. Ich glaub nicht, das ein Kollege gern im Code eines anderen herumfummelt. Egal, welche Sprache. Es gibt für jede Sprache ein "für" und ein "Wider". Und sicherlich ist aufgrund umfangreicher Bibliotheken auch ein Zeitvorteil zu finden. Dennoch verstehe ich jeden, der seinen Controller auch gern mal an die Register fasst... Ich betreibe die Programmierung der Controller mehr oder weniger nebenbei. Aber ich programmiere auch in Pascal und (ich schäm mich fast dafür) auch in Basic. Ach ja, und dann sind noch die Programmiersprachen, die ich beruflich brauche. Ich weiß da schon, wo die Vor- und Nachteile liegen, zumindestens glaube ich es zu wissen... Und daher würd ich nie nich sagen "du musst Assembler lernen, nur so kannst du einen Controller richtig verstehen.. " und auch nicht " lern C, dein Arbeitgeber wird dich nicht für Trödeleien mit Assembler bezahlen..." Gruß oldmax
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.