Hallo! Ich bin gerade debei ein System mit SPI Bus aufzubauen, und bin auf einige Probleme gestoßen, bei denen ich mir nicht sicher bin: 1. wenn ich den spi bus mit einer bestimmten datenrate betreibe z.B.: 5 MHz, und ich schreibe ein byte in das SPI datenregister SPDR wird dieses unmittelbar nach dem schreiben übermittelt. nun meine Frage: ich möchte x byte in folge übertragen, d.h. es sollte kein delay zwischen den einzelnen bytes am bus geben. Ist das möglich? oder ist mein controller (atmega325, 10mhz) dafür einfach zu langsam? danke!
Da der SPI-Bus ja nun mal über eine Clockleitung verfügt, ist ein Delay zwischen den Bytes doch unerheblich. Wenn die Daten aus einem Buffer kommen, würde ich mich des SPIF-Flags bedienen und das ganze per Interruppt laufen lassen. LG EC
danke für deinen tip! das problem ist, das die clockleitung zwischenzeitlich unterbrochen wird (aufgrund einer rf schnittstelle), und auf der empfängerseite automatisch wieder synchronisiert wird). der clock auf der empfangsseite läuft automatisch weiter.
Die Empfängerseite find ich interessanter. Woher weiss der, dass neue Daten anstehen? Da der Takt durchläuft, muss er permanent die SPI auf neue Daten überwachen. Da macht der mit Sicherheit nichts anderes mehr als nur dies, für andere Jobs bleibt keine Zeit.
auf der empfängerseite kann der rf ic diese funktion übernehmen - sobald eine gewisse preamble sequenz detektiert wird, wird ein interrupt beim controller ausgelöst welcher dan sein spi interface aktiviert. das problem ist aber - sobald der controller sein spi aktiviert hat und daten liest, läuft der takt weiter - auch wenn der sender durch das neuschreiben des spi databytes eine verzögerung auf der datenleitung verursacht. gibts hierfür eine lösung?
Normales AVR-SPI ist nicht gepuffert, damit dürfte es in dieser Geschwindigkeitsklasse keine Lösung geben. Das USART-SPI neuerer AVR ist gepuffert, da könnte man mal per Oszi nachmessen, ob bei hinreichend schneller Beschickung kontinuierlicher Sendebetrieb stattfindet. Controller mit höher entwickelten synchronen seriellen Schnittstellen (z.B. SSP/SSC bei diversen ARM7-Reihen, u.U. mit DMA) sind da klar im Vorteil.
Der SPI-Transmitter ist ungepuffert, d.h. es bleibt bestenfalls ein Bruchteil der Zeit eines einzigen übertragenen Bits, um das Senderegister rechtzeitig wieder zu füllen. Sofern es überhaupt prinzipiell geht (m.E. unwahrscheinlich).
Hallo Das gibt ja schon fast Schmerzen, was hier so alles steht. Also bei SPI ist einer der Master, der andere Slave. Master gibt den Takt aus, Slave empfängt. (*) Die Daten werden auf BEIDEN controllern ins SCHIEBEREGISTER geschrieben. Dann taktet der Master exakt soviele Takte auf der Clockleitung wie Bits vorhanden sind. Das heißt: beide Controller müssen die GLEICHE Einstellung der Datenlänge haben. Normalerweiße üblich ist Datenlänge 8 Bit oder 16 Bit, je nach Schieberegister größe. Theoretisch ist aber jede länge von 1 Bit bis größe des Schieberegisters möglich. Nach der entsprechenden Anzahl der Takte wird ein Receive Data Flag im Controller gesetzt. Diese Flag kann IRQ auslösen oder gepollt werden. Danach werden die Daten auf BEIDEN Controller aus dem SCHIEBEREGISTER ausgelesen. Sollen weitere Übertragungen erfolgen siehe (*) Deine Aufgabe ist es dafür zu sorgen das beide Controller bereit sind bevor der Master den Takt anlegt. Wenn der Master mit dem Takten anfängt bevor der Slave seine Daten in das Schieberegister gelegt hat, sind die im Master empfangene Daten MÜLL. Den Unterschied zwischen Pollen und IRQ in Punkto Systemauslastung muss woh nicht mehr erklärt werden, oder ?
Das Orginalprobem kurz Zusammengefasst: Du willst eine unidirektionale SPI-Verbindung statt über drei Verbindungen (CS, Data, Clock) nur über eine laufen lassen. Mit Taktrückgewinnung beim Slave und 5MHz. Geht meiner Meinung nach nicht mit nem 10MHz AVR. Nimm besser den UART, der ist mit seinen Start-Bits eher dafür geeignet, erreicht aber mit UBRR=0 und U2X=1 nur so knapp über 1Mbps... /Ernst
also zu geschwindigkeit: der rf chip schafft sowieso nur max. 384 kbit (die 5mhz waren nur ein "dummes" beispiel) mit uart hab ich bereits verschiedene tests gemacht - aber das problem ist - ohne synchronisierung durch einen takt ist es ab ca 150kbit/s nicht mehr möglich die daten sauber zu dekodieren (zumindest nicht uart)
Thread beobachten
Seitenaufteilung abschaltenBitte 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.