Hallo, ich arbeite derzeit an meiner Bachelorarbet und bräuchte eine kleine Ideen-Hilfestellung von euch. Hat jemand eine Idee welches Protokoll am besten für den Datenaustausch zwischen einem CPLD (MaxII) und µC (Atmega32) wäre. Verbunden sind Sie über einen 8-Bit Breiten Bus (gehen am Atmega auf PortD), der PortPin PC7 (CLK0) geht zusätlich an einen CLK-Eingang des CPLD, also synchrone Datenübertragung möglich. Am PB4 (PCINT4) ist vorgesehen das der CPLD einen Interrupt auslösen kann. Standardmäßig soll die kommunikation vom Atmega als Master ausgehen, also er Sendet Daten an den CPLD um z.B das Steuerwerk zu setzen, der CPLD soll dann z.b Daten aus einem angeschlossenen RAM oder aus internen Registern bzw. UFM an den Atmega zurückschicken. Auch soll der CPLD den Atmega zum Auslesen eines Statusregisters anstoßen (quasi "Hallo, ich schick dir nen Interrupt guck mal in meinem Statusregister was los is"). Meine Frage nun: Kennt jemand ein Protokoll welches auf diese Weise arbeitet? Mein Hauptproblem ist momentan die Bidirektionalität, also woher weis z.B. der CPLD das er seinen Tristate auf Senden stellen darf ohne eine ENABLE vom µC Leitung... Danke Gruß AndZ
Schrotty schrieb:
> SPI
SPI vom Atmega ist schon belegt...
Oder meinst du eine art Parallele Version davon? Also quasi PPI?
Falls dein SPI-Port mit einem SPI-Slave belegt ist, kannst du auch mehrere SPI-Slaves in "Reihe" schalten. Alternativ kannst du natürlich auch einen SPI-Port in SW mit ganz normalen IO-Pins "nachbilden"
Schrotty schrieb: > Falls dein SPI-Port mit einem SPI-Slave belegt ist, kannst du auch > mehrere SPI-Slaves in "Reihe" schalten. > Alternativ kannst du natürlich auch einen SPI-Port in SW mit ganz > normalen IO-Pins "nachbilden" OK, danke...also wenn dann "nachbilden", weil die Verdrahtung zwischen den beiden ist Fix, also ich hab nur die oben genannten Verbindungen. Zwar ne Verschwendung der schönen 8 Datenleitungen, aber vermutlich erstmal die einfachste möglichkeit.
Einfachere Alternative : Paralleler Bus 4 Bit breit 1 x Clock (optional) 1 x Read/Write 1 x high/low Nibble selektor 1 x Data/Address Selektor 4 x Data Dazu überlegst Du dir ein einfaches Timing, z.B. Datenübername bei abfallender oder steigender Flanke Clock. Mit Data/Address = '1' wird ein Address-Register beschrieben, mit dem man das zu lesende/schreibende Register selektiert. Danach wird mit Data/Address = 0 auf das Register selbst zugegriffen. Ist auf einem CPLD vielleicht einfacher zu implementieren als ein SPI Interface. Du musst ja nicht nur das SPI interface implementieren, sondern danach die Daten in die entsprechenden Register bringen.
Danke Klaus...sehr gute idee...werd ich mich gleich mal ranmachen...die idee mit dem getrennten Daten/Adresselektor is echt gut...
> SPI vom Atmega ist schon belegt... Häh, du kannst an den SPI mehrere Slaves anschliessen, das weißt du schon? Du brauchst dazu nur 1 zusätzliches Slave-Select: http://www.lothar-miller.de/s9y/categories/17-SPI
Lothar Miller schrieb: >> SPI vom Atmega ist schon belegt... > Häh, du kannst an den SPI mehrere Slaves anschliessen, das weißt du > schon? > Du brauchst dazu nur 1 zusätzliches Slave-Select: > http://www.lothar-miller.de/s9y/categories/17-SPI Jo schon klar...aber der Atmega is in dem Fall der Slave...Ausserdem ist wie gesagt die Verdrahtung schon Fix...
Hm...also soweit hab ich das konzept mal durchdacht, aber ein kleines Problem habe ich noch: Mein System arbeitet mit 100MHz, also die Register und der Bus arbeiten mit diesem Takt. Wenn jetz ne Anfrage vom Atmega kommt und dieser dann die Register mit seinem eigenen Takt abfrägt wird es ja vermutlich krachen wegen der unterschiedlichen Taktdomänen... Die einzige (auf einem CPLD ohne Blockram um einen FiFo zu bauen) realiserbare Möglichkeit die mir hier einfällt ist, dass der Atmega voll die Kontrolle über den CPLD übernimmt während der Abfrage, also der Globale Takt, welcher normal eben die 100MHz hat, wird auf den Takt welcher vom Atmega kommt umgeschaltet, so dass es immer nur eine Taktdomäne geben kann. Oder habe ich was übersehen. Danke.
Andy Müller schrieb: > Die einzige (auf einem CPLD ohne Blockram um einen FiFo zu bauen) > realiserbare Möglichkeit die mir hier einfällt ist, dass der Atmega voll > die Kontrolle über den CPLD übernimmt während der Abfrage, also der > Globale Takt, welcher normal eben die 100MHz hat, wird auf den Takt > welcher vom Atmega kommt umgeschaltet, so dass es immer nur eine > Taktdomäne geben kann. Oder habe ich was übersehen. Nein, das solltest Du wirklich nicht. Eine Umschaltung des Taktes ist das schlechteste, das man machen kann. Wenn eine Anfrage vom µC kommt, dann wird das einsynchronisiert und der aktuelle Wert wird in ein Zwischenregister gespeichert. Die Schnittstelle zum Atmega kann diesen Wert dann in aller Ruhe auslesen.
HmHmHm...einsynchronisieren ist auf jedenfall mal n guter plan...langsam gehn mir die FlipFlops in meinem CPLD aus ;-) Also da Problem ist folgendermaßen: Ich habe 2 Register (Statusregister und Steuerregister), wobei das Statusregister eigentlich nur lesenden zugriff braucht, das steuerregeister evtl nur schriebenden. Und einen 16 Bit breiten Datenbus auf den nur lesend zugegriffen wird. Im "normalbetrieb", also wenn der Atmega nicht eingreift, werden daten im 100MHz Takt über den Datenbus zwischen einer Schnittstelle und einem externen RAM hin- und hergeschaufelt. Intern gibt es noch einen Adresszähler für den RAM und das ganze wird über ein Steuerwerk gesteuert. Wenn der Atmega nun ins spiel kommt, so übernimmt er die kontrolle über das Steuerwerk (durch das Statusregister) und ist dann hauptsächlich damit beschäftigt über den Datenbus den RAM auszulesen. Wir hatten an der Uni mal ein Projekt wo wir ein ähnliches Problem hatten. Da haben wir auch einen Datenbus im Fullspeed betrieben (50MHz) und bei bedarf konnte man über die serielle Schnittstelle "mitlauschen". Dazu haben wir die Kontrolle des Taktes der seriellen Schnittstelle überlassen. Das umstellen des Taktes hat eigentlich keine Probleme verursacht. Ich dachete immer das schlimmste was man machen kann sin 2 Taktdomänen. Also was ist schlimm am Umschalten des Taktes (wenn man z.b. vorher die Flanken synchronisiert).
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.