Hallo liebes Forum, bin gerade bei meinem Projekt an die grenzen den ATMega1284 gestoßen. In 1. Linie was den RAM betrifft, aber auch die Timer und Ports. Nun möchte ich eine neue Platine machen und umsteigen auf den ATXMEGA128A1. Es handelt sich dabei um eine Art CNC, aber das nur mal am Rande. Der bisherige AVR ist eigentlich auch schnell genug, da es in Assembler geschrieben ist und ganz schön optimiert noch dazu. Nun die konkrete Frage. Wenn ich an einen XMega einen SDRAM anbaue um vom Speicher her ganz viel im voraus berechnetes puffern zu können, wie schnell ist das, oder was gibt es für Verzögerungen mit dem Refresh des Speicherblocks der immer wieder dazwischen haut. Kann ich da wie bisher vom ATMega gewohnt, immer wann ich es brauche, (Zeitkritisch) auf beliebige Stellen im SDRAM zugreifen oder geht das nicht so einfach. Der XMega würde den Refresh ja schon von alleine machen. Ist es angebracht, bei sowas, das erst mal vom externen RAM in den internen zu laden (wenn Zeit ist) und den internen dann für Zeitkritisches zu verwenden? Kann mir darauf jemand eine Antwort geben? Wie viel CPU Takte entspricht der Refresh? Danke schon mal im voraus.
Möchtest du den SDRAM mit Ebi oder einer Kommunikationsschnittstelle anschließen (SPI, I²C)? Falls Ebi, würden mich da Erfahrungen auch interessieren.
Ich würde da lieber PSRAM einsetzen. Das wird von außen wie SRAM angesteuert und man muss sich nicht im µC um Refresh kümmern. Ist nicht viel teuerer als SDRAM - wenn man nicht grade GBytes an Speicher braucht. SDRAM braucht einen komplexen Speichercontroller. Du schreibst leider nicht wie zeitkritisch das Programm ist - ms? µs? Die EBIs von kleineren 8-Bittern unterstützen meist nur (P)SRAM.
@ Roy H. (roy01) >Es handelt sich dabei um eine Art CNC, aber das nur mal am Rande. >Der bisherige AVR ist eigentlich auch schnell genug, da es in Assembler >geschrieben ist und ganz schön optimiert noch dazu. Ob das immer so sinnvoll ist? >Wenn ich an einen XMega einen SDRAM anbaue um vom Speicher her ganz viel >im voraus berechnetes puffern zu können, wie schnell ist das, oder was >gibt es für Verzögerungen mit dem Refresh des Speicherblocks der immer >wieder dazwischen haut. Wenn gleich der SDRAM am XMEGA nicht rasend schnell ist, so gibt es aus Programmierersicht keine Verzögerungen. Beitrag "Re: Viel RAM am kleinen Controller" >Kann ich da wie bisher vom ATMega gewohnt, immer wann ich es brauche, >(Zeitkritisch) auf beliebige Stellen im SDRAM zugreifen Ja, der SDRAM verhält sich genauso wie der interne RAM oder externer SRAM. Nur ist er einen Tick langsamer, er braucht pro Zugriff 5 CPU-Takte anstatt 2 beim internen SRAM. >Der XMega würde den Refresh ja schon von alleine machen. Ja. >Ist es angebracht, bei sowas, das erst mal vom externen RAM in den >internen zu laden (wenn Zeit ist) und den internen dann für >Zeitkritisches zu verwenden? Jain. >Wie viel CPU Takte entspricht der Refresh? Nebensächlich. Wenn du nicht EXAKT taktgenau über viele tausende von Takten arbeiten musst, mogelt dir der SDRAM Controller den Refresh unter, ohne daß du davon was merkst. Im Zweifelsfall dauert dann halt ein Zugriff halt 10 statt 5 CPU-Takte, weil der Refresh einen Tick schneller war.
@Jim Meba (turboj) >Ich würde da lieber PSRAM einsetzen. Das wird von außen wie SRAM >angesteuert und man muss sich nicht im µC um Refresh kümmern. Das muss man bei einem uC mit echtem SDRAM-Controller auch nicht. >SDRAM braucht einen komplexen Speichercontroller. Der ist schon im Xmega drin, kostet nix extra ;-) > Du schreibst leider >nicht wie zeitkritisch das Programm ist - ms? µs? Die EBIs von kleineren >8-Bittern unterstützen meist nur (P)SRAM. Xmega auch SDRAM.
Ich möchte den RAM an das EBI (External Bus Interface) anschließen, so wie es Atmel vorgesehen hat. Das XPlain Board ist ja genau so gemacht.
Ja danke, das wollte ich wissen! Wenn es wirklich nur 10 Takte sind, das ist noch in Ordnung. Mir geht es darum das der Refresh nicht mit Beispielsweise 50µs Wartezeit hier und da unvorhersehbar dazwischen haut und mir alles durcheinander bringt. CNC Projekt: (läuft jetzt mit 20MHz) - Kommunikation zum PC - Interpretation G-Code - Interpolation - Puffer - Ausgabe 3 Schrittmotore (aktuell Halbschritt, dann Microschritt 1/16) Läuft aktuell sehr gut, es sind auch noch einige Reserven da. Ich will nur nicht, das ein neuer Ansatz mit XMega und ext. SDRAM mir das harte Echtzeitverhalten kaputt macht. Ich glaube irgendwo mal gelesen zu haben das der XMega intern mit einem Takt auf den RAM zugreift, anders als die alten AVRs. Danke
@ Roy H. (roy01) >CNC Projekt: (läuft jetzt mit 20MHz) >- Kommunikation zum PC >- Interpretation G-Code >- Interpolation >- Puffer Das ist alles zeitunkritisch, wenn man es richtig macht. >- Ausgabe 3 Schrittmotore (aktuell Halbschritt, dann Microschritt 1/16) Ok, das ist schon eher zeitkritisch. >Läuft aktuell sehr gut, es sind auch noch einige Reserven da. Der Xmega kann mit bis zu 32 MHz getaktet werden, der SDRAM mit 64MHz. >Ich will nur nicht, das ein neuer Ansatz mit XMega und ext. SDRAM mir >das harte Echtzeitverhalten kaputt macht. Macht er nicht. >Ich glaube irgendwo mal gelesen zu haben das der XMega intern mit einem >Takt auf den RAM zugreift, anders als die alten AVRs. ??? Das ist alles getaktet, weil es alles synchron arbeitende Logik ist.
Danke Falk Ja richtig kritisch ist nur die gleichmäßige Ausgabe das stimmt. Dennoch sind viele Sachen nebenbei zu erledigen. Da die CNC Programme ja mit CAM erzeugt werden können das schon sehr viele Programmsätze für einen kleinen Verfahrweg sein. Auch schon mal 50-100 Sätze pro Sekunde, natürlich auch wieder mal weniger. Deshalb ist ein großer Puffer wichtig. Es läuft bis jetzt auch sehr Performant, hätte ich erst selbst nicht gedacht. Möchte es noch um paar Funktionen erweitern und brauche RAM. Laut Datenblatt ist das so. Da beim XMEGA der RAM mit der doppelten Frequenz getaktet wird. AVR 2 Takte, XMega 1 Takt intern.
Roy H. schrieb: > Wenn es wirklich nur 10 Takte sind, das ist noch in Ordnung. Wenn ein 150% geringerer RAM-Durchsatz noch in Ordnung geht, dann kann es mit der Optimierung irgendwie nicht gar so sehr weit her sein... Sprich: da sind wohl noch erhebliche Reserven. > - Kommunikation zum PC > - Interpretation G-Code > - Interpolation > - Puffer > - Ausgabe 3 Schrittmotore (aktuell Halbschritt, dann Microschritt 1/16) Eigentlich braucht nichts davon wirklich viel RAM. Vermutlich ist die Interpolation lausig ineffizient umgesetzt, du schaffst deswegen die Echtzeit nicht und berechnest ersatzweise in Stillstandszeiten riesige Wertetabellen vor, um dann die vorberechneten Bahnen abzufahren. Das ist Mist. Wenn das nötig ist, obwohl angeblich 150% weniger RAM-Durchsatz kein Problem wären, dann zeugt es von extrem schlechter Ausnutzung der Rechenzeit. Sprich: statt des Controllers sollte eher das Software-Design ausgetauscht werden. > Ich glaube irgendwo mal gelesen zu haben das der XMega intern mit einem > Takt > auf den RAM zugreift, anders als die alten AVRs. Das stimmt schlicht nicht. Was aber stimmt: sbi/cbi brauchen statt zwei nur einen Takt.
Hallo, ich muss da jetzt doch noch mal darauf antworten, eigentlich müsste ich es nicht! Mein Vorschlag wäre, ich tausche meine Firmware einfach gegen Deine (c-hater) aus und schon ist alles viel viel besser und effektiver. Ich beschäftige mich seit 12 Jahren mit µCs, Assembler und C. Beruflich bin ich CNC Programmierer und Bediener, bin daher damit schon ganz schön vertraut. Das ganze ist auch noch ein klein wenig anspruchsvoller als das 3D Drucker Zeug. Wenn eine CNC nichts im voraus macht, woher soll sie dann Wissen, wann ein Umkehrpunkt kommt um rechtzeitig abzubremsen? Erhebliche Reserven? 32Bit und sogar 64Bit Quadratwurzel mit einem 8Bit-er. Ich werde mich nun an ein neues Design mit dem XMega wagen, die ineffiziente Software freut sich schon darauf. Danke.
@ Roy H. (roy01) >ich muss da jetzt doch noch mal darauf antworten, >eigentlich müsste ich es nicht! In der Tat. Lass dich von unserem Haty nicht anmachen, der kann ja nix für seine schlimme Kindheit. >Ich beschäftige mich seit 12 Jahren mit µCs, Assembler und C. >Beruflich bin ich CNC Programmierer und Bediener, bin daher damit schon >ganz schön vertraut. > rechtzeitig abzubremsen? >Erhebliche Reserven? >32Bit und sogar 64Bit Quadratwurzel mit einem 8Bit-er. Kommt drauf an, ob man WIRKLICH 64 Bit braucht. Im Ernstfall macht man es über Tabellen und bissel Interpolation, die sind auch euf ne 8 Bitter recht fix. >Ich werde mich nun an ein neues Design mit dem XMega wagen, die >ineffiziente Software freut sich schon darauf. Tu das und viel Spaß und Erfolg. Das Xmega Explained Board ist ein guter, preiswerter Anfang, da musst du nicht mit der Hardware kämpfen. Allerdings musst du den SDRAM hochtakten, das Beispiel von Atmel arbeitet nur mit 2 MHz (Hallo Atmel, nennt ihr sowas eine gelungene Demonstration der Leistungsfähigkeit?) Kann man aber alles in Software machen. Internen 32 MHz Oszillator wählen, PLL ein, Spaß haben ;-)
Roy H. schrieb: > Das ganze ist auch noch ein klein wenig anspruchsvoller als das 3D > Drucker Zeug. Nicht wirklich. > Wenn eine CNC nichts im voraus macht, woher soll sie dann > Wissen, wann ein Umkehrpunkt kommt um rechtzeitig abzubremsen? Ganz einfach: Jede Bahn hat einen Anfangspunkt und einen Endpunkt und letzteren berechnet man als allererstes. Dann ist während des Weges für jeden Punkt sehr leicht der Abstand zum Endpunkt ermittelbar. Außerdem kent man die Grundform der Bahn. Und aus diesen Informationen kann man sehr leicht ableiten, ab wann abgebremst werden muss. Schlimmstenfalls (bei gekrümmten Bahnen) bremst man mit diesem Ansatz etwas früher ab, als es unbedingt nötig wäre, wodurch sich die Bearbeitungszeit gegenüber dem Optimum geringfügig erhöht.
Roy H. schrieb: > ich muss da jetzt doch noch mal darauf antworten, > eigentlich müsste ich es nicht! Lass dich von dem Kerl nicht provozieren. Der Typ ist ein forenbekannter Troll.
Hallo und guten Abend. Bin sehr offen für Anregungen und neue Ideen. Vielmals ergibt sich auch aus Differenzen und Diskussion eine neue Sichtweise für Alle oder auch die Zündente Lösung. Da beim 3D Druck die *.stl Modelle ja eh nicht so genau aufgelöst sind reicht da eigentlich 0,1mm Genauigkeit zwischen den Stützpunkten und dazwischen wird linear verfahren. Wenn man beim CNC fräsen ein Kreisrundes Teil fertigt, dann muss das auch Kreisrund werden. Das heißt, auf 0,001mm sollte aufgelöst werden. Man MUSS bei der "CNC" keinen Endpunkt berechnen, da der ja im G-Code schon als Endpunkt angegeben ist! !!!!!!! Wie steht es denn mit Gerade an Gerade in gleicher Richtung, oder tangentiale Übergänge ? Soll da die CNC immer erst mal abbremsen bevor sie weiter fährt? Die CNC muss schon etwas in die Zukunft schauen können um eine Saubere und schonende Bahn zu fahren. Dafür gibt es Speicher! Man benötigt da keine GByte aber paar kByte sind schon nötig. So einfach ist es leider nicht! Selbst Professionelle CNC Maschinen der letzten 10-15 Jahre haben ihre Probleme mit bestimmten Bewegungsabläufen ab einer bestimmten geforderten Geschwindigkeit.
@TO An Deiner Stelle wäre ein Blick auf stärkere µCs angebracht. Nicht, um Dir unbedingt eine Umstellung aufzuschwatzen, sondern um mit der erheblich höheren Prozessorleistung zukünftig nicht mehr in einen Leistungsengpaß zu geraten. Obwohl anfangs eine gewisse Einarbeitungszeit erfoderlich ist, könntest Du schon jetzt von deutlich mehr internem Speicher und einfacher Programmierung profitieren. Beim Umstieg ATmega1284 auf ATxmega mußt Du zwangsläufig auch auf 3 V Technik und SMD Bestückung umsteigen. Dann ist es auch egal, ob Du gleich einen ARM, PIC oder RX verwendest.
@ m.n. (Gast) >An Deiner Stelle wäre ein Blick auf stärkere µCs angebracht. Ob er dann noch seinem geliebten Assembler fröhnen kann? >Du schon jetzt von deutlich mehr internem Speicher und einfacher >Programmierung profitieren. Also C. Kann er das? Will er das? >Beim Umstieg ATmega1284 auf ATxmega mußt Du zwangsläufig auch auf 3 V >Technik und SMD Bestückung umsteigen. Dann ist es auch egal, ob Du >gleich einen ARM, PIC oder RX verwendest. Jaja, das bissel Softwareumstellung und Einarbeitung ist ja auch nix . . . Er könnte sogar beim old school AVR bleiben und einem mit SRAM erweitern, von 16 auf knapp 64 kB ist schon ein ganz netter Sprung.
Falk B. schrieb: >>An Deiner Stelle wäre ein Blick auf stärkere µCs angebracht. > > Ob er dann noch seinem geliebten Assembler fröhnen kann? Das kann er nach wie vor, muß es aber nicht. >>Du schon jetzt von deutlich mehr internem Speicher und einfacher >>Programmierung profitieren. > > Also C. Kann er das? Will er das? Roy H. schrieb: > Ich beschäftige mich seit 12 Jahren mit µCs, Assembler und C. Er kann es, er weiß, was er will, und mit seiner langen Erfahrung kann er den Nutzen durchaus selber bewerten. >>Beim Umstieg ATmega1284 auf ATxmega mußt Du zwangsläufig auch auf 3 V >>Technik und SMD Bestückung umsteigen. Dann ist es auch egal, ob Du >>gleich einen ARM, PIC oder RX verwendest. > > Jaja, das bissel Softwareumstellung und Einarbeitung ist ja auch nix . . > . Wenn ich das geschafft habe, dann schafft er das auch ;-)
Mal sehen, hatte mir vor Monaten die XMegas schon mal her gelegt, bin dann aber nie dazu gekommen. Hatte damals einfach mit dem AVR begonnen. Obwohl mir da auch schon viele abgeraten hatten, "das geht niemals". Und mein Ehrgeiz war geweckt. Bin eher von der Seite, mit wenig viel zu machen. Natürlich kann man auch ein 64Bit Quadcore, ein Linux Kernel und und und nehmen um einen Wechselblinker zu bauen. (sehe das als keine gute Entwicklung, was Ressourcen aber auch das lernen und verstehen an geht.) Einige Projekte habe ich auch schon in C geschrieben. Da das mit dem SDRAM geht, wird es auch der XMEGA werden. Wollte mich nur noch mal vergewissern, da man da keine richtigen Angaben findet.
Ich kann mich nur erinnern, das dieses EBI Interface für SDRAM nur 4bit kann oder nur auf 4bit zu greift. Hab schon lange nix mehr damit gemacht. Aber der XMega hat auch DMA wenn du nur Daten auslagern oder hin&her schaufeln willst. Ich hatte da mal ein paar sachen mit dem Xmega und in Assembler probiert.. Beitrag "Re: Xmega Programmierung in ASM"
@Steffen H. (avrsteffen) >Ich kann mich nur erinnern, das dieses EBI Interface für SDRAM nur 4bit >kann oder nur auf 4bit zu greift. Es kann auch 8 Bit. https://www.mikrocontroller.net/topic/goto_post/3931791
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.