PicNick am 24. Januar 2006 um 19:13 Uhr

2006-01-24T19:13:38Z

PicNick am 24. Januar 2006 um 18:23 Uhr

2006-01-24T18:23:26Z

Neue Seite

==Bascom Speicherstrukturen==

==Autor==
* [[Benutzer:PicNick|PicNick]]

==Siehe auch==
* [[Avr]]
* [[Bascom]]

[[Kategorie:Robotikeinstieg]]
[[Kategorie:Microcontroller]]
[[Kategorie:Software]]
[[Kategorie:Praxis]]
[[Kategorie:Quellcode Bascom]]

← Nächstältere Version		Version vom 24. Januar 2006, 19:13 Uhr
Zeile 1:		Zeile 1:
	==Bascom Speicherstrukturen==		==Bascom Speicherstrukturen==
		+	Das Bascom keine Datenstrukturen bilden läßt, ist zwar bedauerlich, es gibt aber durchaus Möglichkeiten, sich zu helfen.
		+
		+	==Einfache Strukturen==
		+	Da Bascom die Datenfelder im SRAM und im ERAM geschlossen in der Reihenfolge anlegt, wie sie dimensioniert werden, legt man die Felder von, sagen wir, eines Datenrecords auch hintereinander an.
		+	<pre>
		+	DIM Rec_Header AS BYTE
		+	DIM Rec_Length AS BYTE
		+	DIM Rec_Usrdata AS STRING * 23
		+	DIM Rec_Trailer AS BYTE
		+	</pre>
		+	Und wenn wir nun diesen Bereich redefinieren, wobei wir die Gesamtlänge leider ausrechnen müssen,
		+	DIM Record(27) AS BYTE AT Header OVERLAY
		+	können wir dieses Speicherbereich sowohl als "Record" als Byte-Array in der Länge 27 verwenden, aber auch die Felder einzeln ansprechen, was beim byte-seriellen Input/Output recht praktisch ist.
		+
		+	Natürlich ist das noch kein Ersatz für vordefinierte Strukturen, die dann auch mehrfach an beliebigen Stellen deklariert bzw. verwendet werden können, wie es z.B. bei C (GCC) üblich ist. Da hilft leider nur Cut & Paste und ein anderer Prefix (statt "Rec_").
		+
		+	==Mehrfache Strukturen a la malloc/new ==
		+	Aber für den Fall, daß wir sagen können, wieviele dieser "Strukturen" im Programm maximal verwendet werden (was meisten doch der Fall ist) können wir aus einfachen Tabellen auch mehrfache Strukturen bilden.
		+	Nicht so elegant wie "malloc(sizeof(Record))", aber immerhin:<br>
		+	wir definieren
		+	<pre>
		+	CONST Maxindex = nn ' Die Anzahl, die benötigt wird
		+
		+	DIM Usage_Index(Maxindex) AS BYTE ' Hilfstablle der benützen Elemente
		+	DIM Temp AS BYTE ' Hilfswert
		+	' -------------- die "struktur"--------------------
		+	DIM Rec_Header(Maxindex) AS BYTE
		+	DIM Rec_Length(Maxindex) AS BYTE
		+	DIM Rec_Usrdata(Maxindex) AS STRING * 23
		+	DIM Rec_Trailer(Maxindex) AS BYTE
		+	</pre>
		+	und wenn nun an einer Stelle eine neue Instanz der Struktur gebraucht wird:
		+	<pre>
		+	FOR Temp = 1 to Maxindex
		+	IF Usage_Index(Temp) = 0 then ' da ist was frei
		+	Usage_Index(Temp) = 1 ' reservieren
		+	EXIT FOR
		+	END IF
		+	NEXT
		+	' und nun haben wir einen Bereich und können ihn exklusiv verwenden
		+	Rec_Header(Temp) = nn
		+	Rec_Length(Temp) = nn
		+	Rec_Usrdata(Temp) = "aaaaaaa"
		+	Rec_Trailer(Temp) = nn
		+	</pre>
		+	Die reservierende Funktion wird sich "Temp" natürlich als "pointer" merken und kann ihr Bereich dann auch mal freigeben
		+	Usage_Index(Temp) = 0 ' unreserve
		+
		+	Für die "C"-Kundigen User:
		+	Rec_Length(pointer) <entspricht> pointer->Rec_Length
		+
		+	==Anmerkung==
		+	Von einer wirklichen "Heap" Verwaltung kann man wohl nicht sprechen. Aber vielleicht kann sich dieser oder jener User etwas von der Methodik für seine Zwecke adaptieren und verwenden.<br>
		+	Der größte Unterschied zu "malloc" ist natürlich, daß der aktuell nicht genutzte Bereich NICHT ohne Weiteres für andere Zwecke genutzt werden kann, wie es ja beim original "malloc" der Fall ist. Aber letzterer handelt sich auch eine Menge Probleme damit ein.
		+
		+
		+

Bascom Speicherstrukturen - Versionsgeschichte

PicNick am 24. Januar 2006 um 19:13 Uhr

PicNick am 24. Januar 2006 um 18:23 Uhr