Hallo, ich möchte eine Schaltung entwerfen, die einen seriellen Bitstrom abschneidet. Hintergrund ist, dass ich gerne den HW SPI des µC nutzen möchte aber variable Bitlängen (1 bis 8Bit) benötige. Als FPGA hab ich MachOX2 + DevKits da. Die Frage wäre nun ob es generell möglich ist den SPI Clock als Eingang für den Bitzähler zu nehmen oder ob man einen kompletten Frame erst empfängt und danach ausgibt? Vielen Dank Mirco
Ja stimmt ist ein wenig abwegig, mir geht es mehr darum dass ich dadurch die Datenübertragung in HW machen kann und ich mehr CPU Zeit habe. Evt kann man das später auch mit DMA verbinden. Sollte aber sinniger sein als die Pins via Bitbanging zu setzen (zumindest von der CPU Last her).
Du könntest natürlich in dem CPLD die Bits mitzählen und dann entprechend nach dem n-ten Bit den Datenstrom abbrechen. Aber zeitlich wird dir das nichts bringen, da dein HW-SPI des uC die 8 Bit so oder so rausschieben wird. Das heißt, diese Zeit vergeht auf jeden Fall. Ob du dann nach dem n-ten Bit die Daten zu Null setzt, und wartest, bis das SPI von uC fertig ist, oder ob du einfach Nullen vom uC für die nicht benötigten Bits rausschreibst, ist doch vollkommen gleichgültig, oder?
In der Zeit die das SPI benötigt um die Daten zu shiften, wollte ich die nächsten Daten berechnen (dauert eine Weile). Mir geht es darum, dass ich mich in Verilog/VHDL noch nicht so gut auskenne und daher nicht weiß ob es vom Timing überhaupt hinhaut den Strom abzubrechen wenn man das SCK Signal auch als Takt für den Bitcounter nimmt? (will mich nicht schon am Anfang aufs falsche Pferd setzen).
Mirco Controller schrieb: > In der Zeit die das SPI benötigt um die Daten zu shiften, wollte ich die > nächsten Daten berechnen (dauert eine Weile) Die Zeit veränderst du aber nicht, wenn du extern vom Controller die "übrigen" Bits abschneidest, während der Controller weiter shiftet.. Mirco Controller schrieb: > Mir geht es darum, dass > ich mich in Verilog/VHDL noch nicht so gut auskenne und daher nicht weiß > ob es vom Timing überhaupt hinhaut den Strom abzubrechen wenn man das > SCK Signal auch als Takt für den Bitcounter nimmt? Klar, das geht vom Timing locker... Mirco Controller schrieb: > (will mich nicht > schon am Anfang aufs falsche Pferd setzen) Tust du aber, weil dein Vorhaben aus Systemsicht nichts bringt... Wenn du aber unbedingt willst: Baue einen Zähler, der nach für n Takte das SPI weiterreicht und nach n Takten solange den Ausgang dicht macht, bis er durch Wegnehmen von SS wieder zurückgesetzt wird.
Schlumpf schrieb: > Die Zeit veränderst du aber nicht, wenn du extern vom Controller die > "übrigen" Bits abschneidest, während der Controller weiter shiftet.. Das stimmt, ich kann jedoch schon anfangen während das SPI noch shiftet. Mache ich das ganze via Bitbanging muss ich in der Lese/Schreibe routine warten bis alle Bits durch sind. Schlumpf schrieb: > Baue einen Zähler, der nach für n Takte das SPI weiterreicht und nach n > Takten solange den Ausgang dicht macht, bis er durch Wegnehmen von SS > wieder zurückgesetzt wird. Ich werde es ausprobieren, danke.
Mirco Controller schrieb: > Das stimmt, ich kann jedoch schon anfangen während das SPI noch shiftet. > Mache ich das ganze via Bitbanging muss ich in der Lese/Schreibe routine > warten bis alle Bits durch sind. Entweder verstehe ich dich nicht, oder du mich nicht..
> Die Frage wäre nun ob es generell möglich ist den SPI Clock als Eingang > für den Bitzähler zu nehmen oder ob man einen kompletten Frame erst > empfängt und danach ausgibt? Willst du einen SPI-Master (Sender) oder einen SPI-Slave(Empfänger)? Der Frame ist die Slaveselectleitung. Abschneiden ist im MC eine einfacher UND Befehl. komme da auch nicht mit.
Mirco Controller schrieb: > Ja stimmt ist ein wenig abwegig, mir geht es mehr darum dass ich dadurch > die Datenübertragung in HW machen kann und ich mehr CPU Zeit habe. Evt > kann man das später auch mit DMA verbinden. Sollte aber sinniger sein > als die Pins via Bitbanging zu setzen (zumindest von der CPU Last her). Was ist dein eigentliches Problem? Natürlich kann ein FPGA die Daten/Signale in Echtzeit auswerten und ändern. Die Frage ist nur, ob das prinzipiell Sinn macht. Wenn du ein möglichst flexibles SPI Interface willst/brauchst, dann kannst du das frei programmierbar gleich komplett (und wenn nötig gleich ein paar davon) ins FPGA einbauen. Und per parallelem Bus mit hoher Bandbreite drauf zugreifen.
Lothar Miller schrieb: > Was ist dein eigentliches Problem? > Natürlich kann ein FPGA die Daten/Signale in Echtzeit auswerten und > ändern. Die Frage ist nur, ob das prinzipiell Sinn macht. Genau diese Frage stelle ich mir auch: Was bringt es, das SPI im uC alle n Takte durchtakten zu lassen und dann extern einen Teil davon abzuschneiden? Wenn ich extern abschneide, weil ich z.B. nur 5 Bit benötige, dann kann ich auch gleich im uC die übrigen 3 Bit zu Null setzen.. Oder man macht, wie du ja auch geschrieben hast, das komplette SPI im PLD und kann es dann genau so breit machen, wie man es braucht. Allerdings setzt das voraus, dass auch die Slaves dann mit dieser "schiefen" Breite umgehen können und man nicht am Ende der Übertragung noch "Stuff-Clocks" braucht, damit der Empfänger zufrieden ist. Alles in allem halte ich den Ansatz für äußerst fragwürdig..
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.