| Re: mem.copy: Quell-Array Position? Kategorie: Programmierung (von André H. - 21.01.2005 19:25) | ||
| Als Antwort auf Re: mem.copy: Quell-Array Position? von Thomas - 18.01.2005 23:55 | ||
| ||
|
Hallo Thomas, > > Wenn Du viel Zeit mit dem Pollen des Busses verbringst, wird es mit anderen Controllern sicher > > nicht schneller gehen. Denn die meiste Zeit geht dann für den Bus drauf. > > da hätte ich dann aber eine Interrupt-Eingang bzw. könnte in C eine Interrupt-Handler installieren. Das würde aber kaum einen Unterschied zu der Lösung machen, einen eigene Thread für die Interruptbehandlung zu schreiben. Das Nadelör bei der Ausführung wäre dann der I²C-Bus. Gut, würde man alles in ASM schreiben, könnte man die Sache vielleicht mit dem Faktor zwei bis drei beschleunigen. Nur sollten Interruptroutinen immer so kurz, wie möglich gehalten werden. Also z.B. keine I²C-Zugriffe, da 1. dies einfach zu lange dauert (ca. 100µS pro übertragenen Byte) 2. Du in der Interrupt-Routine eine bestehende I²C-Kommunikation mit Sicherheit störst. Also baue Dir einfach einne Pseudo Interrupt-Handler in C2 auf: thread interrupt { wait not ports.get(IntPort); // ... // Anweisungen,die bei einem Interrupt ausgeführt werden sollen. // Dies können Funktionen, direkte Lesezugriffe oder auch // das Starten von Threads sein. } Man kann diesen Thread sogar eine höhere Priorität geben, sobald ein I²C-Bus-Baustein einen Interrupt auslösen will. > Das werde ich auf jeden Fall ausprobieren. Auf die Idee bin einfach nicht gekommen. /INT gehört halt > an /INT :-) Tja, Interrupt ist eben nicht gleich Interrupt. Bei I²C-Bus-Bausteinen ist die INT-Leitung eben nur ein Signal, was bedeutet: "Bei mir hat sich etwas geändert, lies mich aus." ;-) > > Das wichtigste ist jedoch, die Bausteine immer komplett abzufragen und nciht Portweise. > > Also beim PCF8574 den kompletten Byteport bzw. beim MAX7311 den kompletten Wordport. > > Das mache ich auch so - sonst würde vor lauter Busabfragen wohl auch gar nichts anderes mehr > passieren. Hmm. Dann gibt es in Deinem Programm irgendwo noch grö�ere Verzögerungen zwischen den Abfragezyklen. > > Das geht nur mit Array-Variablen. Dazu gehören auch Strings und eigene Datentypen. > > Ansonsten mu� man über den Stack arbeiten, was auch kein Problem ist. > > > Wenn > > > das geht, brauche ich eigentlich nur noch meine Sammlung um ein weiteres Assembler-Buch zu > > > ergänzen :-) > > > > Hierfür gibt es kein Buch. > > Rudimentär spreche ich noch ein wenig 6502, 8080, Z80, 680x0 :-) Ein Buch muss auf jeden Fall her. Achso, Du meinst für die ASM-Programmierung allgemein. Ich dachte Du meintest ein Buch bei dem der Umgang mit dem CC2-OS in ASM näher erläutert wird. Für ASM-Programmierung sind einerseits die Kapitel von "MSR mit CC2" ganz hilfreich - eines befindet sich unter "Bücher" zum reinlesen -, andererseits soll das "C166er Leerbuch" von Elektor sehr gut sein. Ich selbst kann das nicht beurteilen, da ich es nicht hab'. Jedoch habe ich schon lange vor, es mir zu kaufen. Ich komme nur vor lauter Arbeit nicht dazu. ;-) > > Jedoch sollte z.B. der ASM-Treiber sys0001 die Parameterübergabe verdeutlichen. > > Danke für Deine Hinweise. Den sys0001 werde ich mir anschauen (sobald ich den Assembler ein wenig > lesen kann). Ich finde, der C166er Assembler ist sehr einfach zu lesen, wenn man dies z.B. mit dem HC05 bzw. HC08 Assembler der CC1 vergleicht. ;-) Allerdings sagen andere wieder, 16Bit-Assembler sei schwerer, als 8Bit. ;-) (Was ich, erhlich gesagt, nicht verstehe. ;-) ) MfG André H. Antworten bitte nur ins Forum! Fragen per EMail auf Forum-Postings werden nicht beantwortet! Das macht meine Heizung gerade | ||
Antwort schreiben Antworten: | ||