| Re: ports zu langsam Kategorie: Sonstige Hardware (von Jo - 13.01.2009 16:42) | ||
| Als Antwort auf Re: ports zu langsam von noob - 26.04.2008 11:34 | ||
| ||
|
Hallo zusammen, ich bin auch schon ein paar mal an die Performance Grenzen gesto�en. Ich konnte mir bisher durch Oprimierung oder ein Stück zusätzliche HW und einem Lötkolben helfen. Ein guter Freund hat mir gute Erfahrung mit folgendem board gemacht. .... hier kommen Infos zu dem Board: http://elmicro.com/de/icnova-ap7000-base.html Preis: 79,95 EUR + Verpackung + MWST. Ggf. noch ein Steckernetzteil bei Stand-Alone-Betrieb. Ich betreibe es ohne Netzteil zum Testen am USB-Port. D.h. Power < 500 mA* 5W = < 2,5 W Das Board hat alle LED-Signale und jede Menge I/O-Ports auf den Steckerleisten. In der anliegenden Anleitung steht drin, wie man die I/O-Ports und die LEDs aus der Linux-Kommandozeile steuert. D.h. Du bräuchtest zunächst noch nicht einmal die Linux-EW-Umgebung installieren! Vom Steuer-PC aus kannst Du Dich per Script (z.B. per expect-Skript oder was anderem) einfach auf dem Linux-Board einloggen, die LEDs / IOs ein/ausschalten und Dich danach wieder ausloggen. Natürlich kannst Du auch ein kleines Programm auf dem Linux-Rechner schreiben, welches per TCP/IP oder per UDP sich vom Steuer-PC ansprechen lässt. Aber wie gesagt, es geht auch absolut ohne Linux-Programmierung. Als Alternative kannst Du natürlich auch bei einem Mini-ITX-Board den Printerport als Relaisansteuerung nehmen. Aber das Linux-Board hat mehr I/O-Pins, braucht sicher erheblich weniger Strom und dürfte in Bezug auf Grösse und Preis ebenfalls unschlagbar sein Allerdings hat er für seine Echtzeitsteueraufgaben LINUX Kernal Treiber Programmieren müssen. Dies ging nach anfänglichen Schwierigkeiten auch dank der vielen LINUX foren dann doch ganz gut. Ich selber bin jedoch wirklich auf die Inline Assembler Funktion gespannt, das dürfte die Einsatzmöglichkeit vom CC-Control vervielfachen. Ich hoffe das diese bald verfügbar sein wird. Nach meiner Erfahrung reicht in 90% meiner Projekte der Interpreter von der Performance, die Ladezeit und das Debuggen ist gut, nur für die Restlichen 10% ist das Fehlen des Assembers u.U. ein Showstopper. Viele Grü�e Jo > > Jetzt wo ihr es sagt. Doch, Interpreter hab ich gelesen aber es hat nicht geklingelt in meinem Kopf ^^ > mit Assembler hab ich schon mal versucht aber extrem viel zeit verbraten bis es mal funktioniert hat, > und bei gewissen problemen bin ich nie dahinter gekommen wieso mein Programm mit 20 Hex Ziffern > einfach nicht zuverlässig das macht was es soll. Daher eher ein Albtraum. Neben den bekannten > ueberlauf und status registern und wie die alle hiessen, muss es noch unbekannte Bitveschlucker Register > gehabt haben von denen niemand etwa wusste. > > Mein Programm ist eigentlich simpel. ich muss der reihe nach 256 ausgänge schalten, nach einem > bestimmten Zeitmuster. > Optimal wäre mittels 3 Taster 3 verschiedene Zeitmuster anzuwählen, die 3 Zeitmuster sind dann > in 3 Subroutinen fix programmiert. und das wiederholbar. > Das ist schon alles. > Aber ich müsste einen minimalen Zeitabstand von 3 mikrosekunden erreichen . > > Kann man mit einem trick auf die schnelle so etwas einbauen ? > > Gibt es ein Prozessor System das für noobs schnell begreifbar ist und diese zeiten hinkriegt ? > > Möglicherweise ein 16 Bit Prozessor ? > > MfG Noob > > Details: > > Mit hilfe von 74HC573 sieht dann das etwa so aus: > ' Ausgang 1 > ' 16 bit breiter Datenbus auf ausgänge schreiben > Port_Write(2,&HFF) ' lower byte von Datenbus auf die anschlussbeine > Port_Write(3,&HEF) ' hihger byte von Datenbus auf die anschlussbeine > ' entsprechendes Paar 74HC573 soll Daten vom Bus uebernehmen > Port_WriteBit(0,1) ' Latch Enable Paar 0 auf High > Port_WriteBit(0,0) ' Latch Enable Paar 0 auf Low > ' so schnell es geht > ' Ausgang 2 > ' 16 bit breiter Datenbus auf ausgänge schreiben > Port_Write(2,&HFE) ' lower byte von Datenbus auf die anschlussbeine > Port_Write(3,&HFF) ' hihger byte von Datenbus auf die anschlussbeine > ' entsprechendes Paar 74HC573 soll Daten vom Bus uebernehmen > Port_WriteBit(1,1) ' Latch Enable Paar 0 auf High > Port_WriteBit(1,0) ' Latch Enable Paar 0 auf Low > 'gewisse zeit warten > 'Ausgang 3 > u.s.w. > > > Hallo Noob, > > > > es wird demnächst Inline ASM geben, wir werden versuchen > > dadurch die Ports schneller zu machen. Jedoch versprechen > > kann ich noch nix. > > > > Grü�e Ulli > > > > > Hallo Noob, > > > > > > die C-Control Pro benutzt zur Abarbeitung der Programme einen Interpreter: �hnlich wie bei Java wird das > > > Programm in einen Bytecode übersetzt, der vom Interpreter in der Firmware abgearbeitet wird. Genauso > > > arbeiten auch C-Control I (beide Versionen) und C-Control II von Conrad. > > > > > > Es wird im Handbuch an vielen Stellen darauf verwiesen, das ein Bytecode Interpreter benutzt wird. Bitte sag > > > mir, welche Stellen Du im Handbuch gelesen hast, dann bekomme ich einen Eindruck, wo noch weiter auf > > > den Einsatz des Interpreters hingewiesen werden kann. > > > > > > Warum wurde ein Interpreter benutzt? Die Entwicklung eines Compilers, der effizeinten Assembler Code > > > erzeugt dauert mehrere Mannjahre. Da Conrad die Software umsonst herausgibt, war dieser Aufwand nicht > > > möglich, zumal da ja BASIC und C unterstützt werden sollten, hätte es denn Aufwand nochmal verdoppelt. > > > > > > Es ist augenfällig, das fast alle Compiler für den Atmel die Assembler erzeugen, nicht auf dem Chip selbst > > > debuggen können. Oft wird nur ein Simulator mitgeliefert. Die Option wäre der Support von AVR Studio > > > (das Conrad aus Lizenzgründen nicht mitliefern dürfte), aber da mu� man auch noch mindestens einen ISP > > > Adapter dazu kaufen. > > > > > > Am einsteigerfreundlichsten ist halt die Interpreterversion (die übrigens auch beim Speicherüberlauf warnt, > > > was eine Assemblerversion nicht kann), aber ein Interpreter ist halt nicht so schnell wie richtiger Maschinen- > > > code. > > > > > > Gruss Peter > > > > > > > Port_Write oder Port_WriteBit Befehle benötigen etwa 30 bi 36 mikrosekunden um die ports umzuschalten. > > > > das ist für meine applikation aber mindestens um eine grössenordnung zu langsam. > > > > > > > > wie kann man das schneller machen. > > > > > > > > ich bin davon ausgegangen dass ein risc prozessor etwa einen takt braucht um so ein port zu ändern. > > > > das wären dann aber 71 ns.mit 3 oder 4 takten wäre ich zufrieden gewesen. (300ns) > > > > > > > > liegt das am compiler ? > > > > > > > > ich wäre für einen tip oder trick sehr sehr dankbar da ich bereits etwa 600 Euro in meine Schaltung gesteckt > > > > habe, für eine abschlussarbeit. 3 mikrosekunden würden gerade noch gehen maximal. > > > > > > > > um das festzustellen habe ich eine subroutine geschrieben 1000 mal aufgerufen mal mit 24 Portwrite befehlen > > > > mal mit 48 und die zeitdifferenz die mir der ide angibt auseinander gerechnet. > > > > > > > > etwas geschockt Noob | ||
Antwort schreiben Antworten: | ||
Zur Übersicht - INFO - Neueste 50 Beiträge - Neuer Beitrag - Suchen - Zum C-Control-I-Forum - Zum C-Control-II-Forum