Hallo miteinander Ich beschäftige mich schon länger mit uC's und der Hardware-Entwicklung. Jetzt sind bei mir ein paar Fragen aufgetaucht: 1) Wie kann man schnelle Schaltungen mit uC's entwerfen? (Klar ist, dass die Ports möglichst gerade auf die Peripherie gehen, aber was noch?) 2) Kann man für schnelle IO Aktionen irgendwie die Schaltung so auslegen, dass die DDR's nicht immer umgeschaltet werden müssen? Denke mir, dass hier auch von der Geschwindigkeit her etwas gemacht werden kann. 3) Programmiertechnisch könnte man ja irgendwie zuerst mehrere Bytes lesen, dann auf schreiben umstellen. Und nicht immer ein Byte lesen, DDR wechseln, schreiben, DDR wechseln, lesen... Was habt ihr so für Erfahrungen gemacht? MFG Patrick
Wieso überhaupt umschalten? Ich ändere am DDR im Betrieb nichts. Für die Kommunikation gibt es ja UART SPI I2C
Bastler schrieb: > Wieso überhaupt umschalten? > Ich ändere am DDR im Betrieb nichts. > > Für die Kommunikation gibt es ja UART SPI I2C Daten-Bus? Da gibt es das ganze bidirektional. I2C ist sehr langsam (100 und 400kHz wirklich unterstütz, wobei zweites schon seltener ist), UART das selbe. SPI kann man auch nicht mit jeder Frequenz betreiben. Die einzig vernünftig schnelle Schnittstelle ist CAN. Aber da ich schon viele Schaltungen gesehen habe die zwingend einen parallelen Daten sowie Adressbus hatten, dachte ich mir, dass hier ja irgendetwas auch optimiert sein muss, denn das Umschalten brauch ja auch wieder Zeit (DDR setzen, Latch löschen, neu setzen, DDR zurück...)
Ich verstehe dein Problem nicht. Wenn dir die Geschwindigkeit nicht reicht, dann greife auf einen FPGA zurück. Ich habe da gerade eine SPI bei 80 MHz CLK-Takt auf FPGA laufen. Das viel größere Problem ist woher die Daten kommen und wohin damit wenn man sie empfängt. Ich verstehe auch nicht warum du dir an dieser Stelle Gedanken machst: gehen wir mal auf einen Mikrocontroller - das setzen von Registern wie z.B. DDR dauert einen Takt lang. Ich empfehle dir mal das Verhältniss von einen Takt vs. ISR zum gesamten Empfang sich verhält. Der limitierende Faktor ist mit SIcherheit nicht das DDR Register ...
Es gibt Controller die haben einen "Externen Daten-Adressbus Modus". Dann werden die IO/s als Bus behandelt. Wenn man es selber mit normalen IOs nachbilden will bleibt einem nichts anderes übrig als ständig das DDR umzuinitialisieren. Also, nimm einen entsprechenden Controller für entsprechende Aufgaben.
Patrick B. schrieb: > Die einzig vernünftig schnelle Schnittstelle ist CAN. Irkkkkkkkkks - mal ein paar Gegenargument: + USB 2.0 + FireWire + eSATA + PCIExpress + ... oben genannte Schnittstellen sind keine Standarts im µC Bereich aber auf FPGA in einem sehr gut machbaren Bereich. CAN ist ein Witz von Geschwindigkeitsseiten. Er ist rel zuverlässig in Störumgebungen (KFZ, etc.). Diese wundervollen Geschwindigkeiten sind aber nur bei kurzen Kabellängen erreichbar ... siehe: http://de.wikipedia.org/wiki/Controller_Area_Network#.C3.9Cbertragungsrate_und_Leitungsl.C3.A4nge
Lehrmann Michael schrieb: > Ich verstehe dein Problem nicht. Wenn dir die Geschwindigkeit nicht > reicht, dann greife auf einen FPGA zurück. Ich habe da gerade eine SPI > bei 80 MHz CLK-Takt auf FPGA laufen. Ich habe zwar von Standart-Bauelementen geredet, und nicht irgendwelche HI-End FPGAs (hast mir zwar gerade eine neue denkweise gezeigt) Bastler schrieb: > Es gibt Controller die haben einen "Externen Daten-Adressbus Modus". > Dann werden die IO/s als Bus behandelt. > Wenn man es selber mit normalen IOs nachbilden will bleibt einem nichts > anderes übrig als ständig das DDR umzuinitialisieren. > > Also, nimm einen entsprechenden Controller für entsprechende Aufgaben. Kannst du hier ein paar Beispiele nennen? Lehrmann Michael schrieb: > oben genannte Schnittstellen sind keine Standarts im µC Bereich aber auf > FPGA in einem sehr gut machbaren Bereich. Nun, es gibt sehr viele Projekte in meinem Betrieb die nicht auf FPGAs aufgebaut sind. USB 2.0 gibts auch bei 32Bit Kontrollern, aber meistens werden doch keine 32 Bit Controller eingesetz, nur um eine schnellere Übertragung zu erreichen? Mein Problem bei einem Projekt ist, dass sehr viele Peripherie-Elemente über Adress und Datenbus verbunden sind. Adressbus ist klar Ausgang, aber der Datenbus... MFG
Hi >> Also, nimm einen entsprechenden Controller für entsprechende Aufgaben. >Kannst du hier ein paar Beispiele nennen? Bei AVRs: ATMega640/1280/1281/2560/2561, ATMega64/128, ATMega8515... MfG Spess
Patrick B. schrieb: > Nun, es gibt sehr viele Projekte in meinem Betrieb die nicht auf FPGAs > aufgebaut sind. USB 2.0 gibts auch bei 32Bit Kontrollern, aber meistens > werden doch keine 32 Bit Controller eingesetz, nur um eine schnellere > Übertragung zu erreichen? > > Mein Problem bei einem Projekt ist, dass sehr viele Peripherie-Elemente > über Adress und Datenbus verbunden sind. Adressbus ist klar Ausgang, > aber der Datenbus... Deshalb gibt's seit Ewigkeiten Controller mit nach außen geführtem Adress/Datenbus (entweder Intel-Style 80 (/RD, /WR, ALE (wenn's gemultiplext ist) oder Motorola 68 EN, R/W)) wo die Umschalterei ganz klassisch in Hardware gemacht wird (teilweise mit konfigurierbarem Timing). Sowas gibt's bei 8-Bit Controllern AVR, div. 8051ern, 16-Bit PIC24, dsPIC und 32-Bit Controllern ala PIC32, SHs, ARM7,9,11 und einigen Cortex-M3 und vielen die ich hier vergessen habe.. Letztlich ist die Frage, ob der Controller passend für die Aufgabe gewählt wurde.
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.