Benutzer Diskussion:PicNick - Versionsgeschichte

SprinterSB_alt: Wunschthemen

2006-02-23T10:08:31Z

Wunschthemen

SprinterSB_alt am 6. Februar 2006 um 14:05 Uhr

2006-02-06T14:05:30Z

PicNick am 3. Februar 2006 um 09:14 Uhr

2006-02-03T09:14:05Z

SprinterSB_alt: /* Signallänge messen mit avr-gcc */

2006-02-03T08:57:57Z

‎Signallänge messen mit avr-gcc

PicNick am 3. Februar 2006 um 08:42 Uhr

2006-02-03T08:42:49Z

SprinterSB_alt: /* Signallänge messen mit avr-gcc */

2006-02-03T08:09:41Z

‎Signallänge messen mit avr-gcc

PicNick am 2. Februar 2006 um 18:18 Uhr

2006-02-02T18:18:19Z

SprinterSB_alt am 2. Februar 2006 um 16:28 Uhr

2006-02-02T16:28:08Z

Neue Seite

===Signallänge messen mit avr-gcc===
In [[Sourcevergleich]] hab ich den Abschnitt "[[Sourcevergleich#GCC (Signallänge messen)|GCC (Signallänge messen)]]" geändert. Vielleicht schaust du mal nach, ob's in deinem Sinne ist. --[[Benutzer:SprinterSB|SprinterSB]] 17:28, 2. Feb 2006 (CET)

← Nächstältere Version		Version vom 23. Februar 2006, 10:08 Uhr
Zeile 48:		Zeile 48:
	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.		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)		--[[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)

← Nächstältere Version		Version vom 6. Februar 2006, 14:05 Uhr
Zeile 39:		Zeile 39:

	--PicNick 10:14, 3. Feb 2006 (CET)		--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)

← Nächstältere Version		Version vom 3. Februar 2006, 09:14 Uhr
Zeile 28:		Zeile 28:

	--[[Benutzer:SprinterSB\|SprinterSB]] 09:57, 3. Feb 2006 (CET)		--[[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)

← Nächstältere Version		Version vom 3. Februar 2006, 08:57 Uhr
Zeile 22:		Zeile 22:

	--PicNick 09:42, 3. Feb 2006 (CET)		--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)

← Nächstältere Version		Version vom 3. Februar 2006, 08:42 Uhr
Zeile 19:		Zeile 19:

	----		----
		+	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)

@@ 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
 --PicNick 19:18, 2. Feb 2006 (CET)

← Nächstältere Version		Version vom 2. Februar 2006, 18:18 Uhr
Zeile 1:		Zeile 1:
	===Signallänge messen mit avr-gcc===		===Signallänge messen mit avr-gcc===
	In [[Sourcevergleich]] hab ich den Abschnitt "[[Sourcevergleich#GCC (Signallänge messen)\|GCC (Signallänge messen)]]" geändert. Vielleicht schaust du mal nach, ob's in deinem Sinne ist. --[[Benutzer:SprinterSB\|SprinterSB]] 17:28, 2. Feb 2006 (CET)		In [[Sourcevergleich]] hab ich den Abschnitt "[[Sourcevergleich#GCC (Signallänge messen)\|GCC (Signallänge messen)]]" geändert. Vielleicht schaust du mal nach, ob's in deinem Sinne ist. --[[Benutzer:SprinterSB\|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)