(Wunschthemen) |
|||
| (5 dazwischenliegende Versionen von 2 Benutzern werden nicht angezeigt) | |||
| Zeile 3: | Zeile 3: | ||
---- | ---- | ||
| + | |||
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 | 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) | --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). | ||
| + | |||
| + | --[[Benutzer:SprinterSB|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) | ||
| + | |||
| + | ---- | ||
| + | |||
| + | Öhm, das versteh ich jetzt nicht. Welche Klasse PortIO denn? Und wo wird DDRx verwendet? Das ist doch ein C-Beispiel, ich steh da aufm Schlauch. Oder reden wir von was ganz anderem? "Ausprägungen" hast du ja keine hier, es wird ein Zeiger übergeben und die Struktur einem SFR-Bereich übergestülpt. | ||
| + | |||
| + | --[[Benutzer:SprinterSB|SprinterSB]] 09:57, 3. Feb 2006 (CET) | ||
| + | |||
| + | ---- | ||
| + | Usage: Nun, das Pin/Port wird auf input gesetzt | ||
| + | |||
| + | pPort->bDdr &= ~mMask; // define PINx as Input | ||
| + | |||
| + | Jedes I/O Port hat drei SFR, PINx, DDRx, PORTx und mit denen kann man ganz bestimmte Dinge tun. Diese drei Register und die Art, damit umzugehen, stellt eine Klasse/Object/Datenkapsel/.etc... dar. | ||
| + | Und für jedes physische Port gibt's das, ("ausprägung/instance/wasweissich"). | ||
| + | Übergestülpt: So kann man es auch sehen. Was denkst du denn, wie objectorientierte Programme de facto funktionieren ? Memory, ein Pointer drauf, und der rest steht im Code. | ||
| + | |||
| + | --PicNick 10:14, 3. Feb 2006 (CET) | ||
| + | |||
| + | ---- | ||
| + | |||
| + | Das stimmt allerdings, tatsächlich sieht man oft, daß unter OO prozedural programmiert wird... | ||
| + | |||
| + | Mit einer Objekt-orientierten (OO) Sprache wird man das PulseIn wohl als Methode für ein Port-Pin-Objekt implementieren: PortD1.getPulseLength (level). Port-Objekte zu machen und diese wie auch immer an eine Funktion getPulseLength (...) zu übergeben, wäre auch denkbar (prozedural eben). | ||
| + | |||
| + | Speziell bei C++ steht man aber früher oder später am Scheideweg. Entweder, man implementiert die Basis-Methoden wie Port-Pin-Setzen als static inline und hat die gewünschte Effizienz. Oder man wählt den abstrakten Weg und leitet ab. Das ist einfach und flexibel anwendbar, wie man es von OO gewohnt ist. Es ist jedoch praktisch nicht benutzbar aus Effizienzgründen, und für rtti (Runtime Type Information) muss man schon ''etwas'' Aufwand teiben... Wie auch immer, ich hab's einfach in der Quelle angemerkt. | ||
| + | --[[Benutzer:SprinterSB|SprinterSB]] 15:05, 6. Feb 2006 (CET) | ||
| + | |||
| + | == Wunschthemen == | ||
| + | |||
| + | Hallo, du hattest auf meiner [[Benutzer_Diskussion:SprinterSB|Diskussionsseite]] was zu meinem Eintrag in den Wunschthemen geschrieben, aber nicht weiter darauf geantwortet. Vielleicht schreibst du ja was dazu, am besten wohl [[Benutzer_Diskussion:SprinterSB|dort]]. Ich fände es schon sehr interessant, mal zu sehen, welchen Code die verschiedenen AVR-C-Cmpiler erzeugen, vor allem auch die "profissionellen" wie IAR. Ich selbst könnte bestenfalls etwas zu avr-gcc sagen, mehr aber nicht. --[[Benutzer:SprinterSB|SprinterSB]] 11:08, 23. Feb 2006 (CET) | ||
Aktuelle Version vom 23. Februar 2006, 11:08 Uhr
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)
Öhm, das versteh ich jetzt nicht. Welche Klasse PortIO denn? Und wo wird DDRx verwendet? Das ist doch ein C-Beispiel, ich steh da aufm Schlauch. Oder reden wir von was ganz anderem? "Ausprägungen" hast du ja keine hier, es wird ein Zeiger übergeben und die Struktur einem SFR-Bereich übergestülpt.
--SprinterSB 09:57, 3. Feb 2006 (CET)
Usage: Nun, das Pin/Port wird auf input gesetzt
pPort->bDdr &= ~mMask; // define PINx as Input
Jedes I/O Port hat drei SFR, PINx, DDRx, PORTx und mit denen kann man ganz bestimmte Dinge tun. Diese drei Register und die Art, damit umzugehen, stellt eine Klasse/Object/Datenkapsel/.etc... dar. Und für jedes physische Port gibt's das, ("ausprägung/instance/wasweissich"). Übergestülpt: So kann man es auch sehen. Was denkst du denn, wie objectorientierte Programme de facto funktionieren ? Memory, ein Pointer drauf, und der rest steht im Code.
--PicNick 10:14, 3. Feb 2006 (CET)
Das stimmt allerdings, tatsächlich sieht man oft, daß unter OO prozedural programmiert wird...
Mit einer Objekt-orientierten (OO) Sprache wird man das PulseIn wohl als Methode für ein Port-Pin-Objekt implementieren: PortD1.getPulseLength (level). Port-Objekte zu machen und diese wie auch immer an eine Funktion getPulseLength (...) zu übergeben, wäre auch denkbar (prozedural eben).
Speziell bei C++ steht man aber früher oder später am Scheideweg. Entweder, man implementiert die Basis-Methoden wie Port-Pin-Setzen als static inline und hat die gewünschte Effizienz. Oder man wählt den abstrakten Weg und leitet ab. Das ist einfach und flexibel anwendbar, wie man es von OO gewohnt ist. Es ist jedoch praktisch nicht benutzbar aus Effizienzgründen, und für rtti (Runtime Type Information) muss man schon etwas Aufwand teiben... Wie auch immer, ich hab's einfach in der Quelle angemerkt. --SprinterSB 15:05, 6. Feb 2006 (CET)
Wunschthemen
Hallo, du hattest auf meiner Diskussionsseite was zu meinem Eintrag in den Wunschthemen geschrieben, aber nicht weiter darauf geantwortet. Vielleicht schreibst du ja was dazu, am besten wohl dort. Ich fände es schon sehr interessant, mal zu sehen, welchen Code die verschiedenen AVR-C-Cmpiler erzeugen, vor allem auch die "profissionellen" wie IAR. Ich selbst könnte bestenfalls etwas zu avr-gcc sagen, mehr aber nicht. --SprinterSB 11:08, 23. Feb 2006 (CET)
