Signallänge messen mit avr-gcc
In Sourcevergleich hab ich den Abschnitt "GCC (Signallänge messen)" geändert. Vielleicht schaust du mal nach, ob's in deinem Sinne ist. --SprinterSB 17:28, 2. Feb 2006 (CET)
Super, schaut ja gleich viel sauberer aus. Danke. Bleibt halt die Frage, ob die Methode, gewissermaßen durch reverse-engineering (also rückwirkend C-Source bauen aus .LSS Assembler-listing) überhaupt eine Alternative zur reinen Assemblerlösung darstellt. Assembler muß man ja offenbar so oder so können. Naja, was soll's
--PicNick 19:18, 2. Feb 2006 (CET)
Jepp, Inline Assembler ist nicht der Hype und ich hab auch schon überlegt, wie man da drumrum kommt. Das Beispiel versucht ja ohne Systemresourcen auszukommen. Das schafft es zwar nicht (das Interrupt-System wird implizit verwendet. Ok, BASCOM lässt das auch unter'n Tisch fallen), aber egal...
Das einzige was mir einfällt, ist eine Dummy-Messung. Nach dem Reset macht man eine Messung und verwendet einen Systemtimer, der die Ausführungszeit bestimmt. Die Zeit wird in Zyklen umgerechnet und in einer Variablen abgelegt, die später verwendet wird. Das ist unproblematisch, denn in der Applikation wird der Timer nicht mehr benötigt und kann nach der Kalibrierung initialisiert werden wie man will -- oder auch brach liegen. Damit wäre man unabhängig von der Codegenerierung und Aufdröseln von lst-Files. Der Code würde kein Inline Assembler mehr enthalten und zeigen, wie man einen Timer initialisiert. Allerdings würde es auf die Genauigkeit gehen, weil man mit der Rasterung nicht unter 3 Zyklen kommt und hätte einen Fehler von max. 1 Zyklus (-1, 0 oder 1).
Noch etwas zur IO_REG Struktur: Damit sieht man zwar, wie man indirekt auf Ports zugreifen kann, aber auf großen AVRs wie ATmega128 fällt man damit auf die Nase, weil die SFRs für Ports jenseits von PORTD nicht so angeordnet sind und wild im I/O-Bereich verteilt liegen. Verwendet wird ja nur das PINx-Register. Nur das zu verwenden würde den Code kürzen und den Fehler ausschliessen (der Fehler tritt hier nicht auf, weil PINx vorne steht im struct, jedoch dann, wenn man versucht, zB auf DDRE zuzugreifen über die Struktur).
--SprinterSB 09:09, 3. Feb 2006 (CET)
IO_REG: Für die Klasse "PortIO" mit der Ausprägung f.portD sind das eben die privaten daten, und da braucht er auch das DDRx. Für andere IO-functions sieht das natürlich anders aus, und auf anderer Hardware natürlich in vielen Fällen auch. logo.
--PicNick 09:42, 3. Feb 2006 (CET)
