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.
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.
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"
Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.
Wichtige Regeln - erst lesen, dann posten!
Groß- und Kleinschreibung verwenden
Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang
Announcement: there is an English version of this forum on 
Thread beobachten
Seitenaufteilung abschalten