Forum: Mikrocontroller und Digitale Elektronik XMega AVR, wie lange dauert der SDRAM Refresh genau?


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Roy H. (roy01)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Curby23523 N. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Möchtest du den SDRAM mit Ebi oder einer Kommunikationsschnittstelle 
anschließen (SPI, I²C)?

Falls Ebi, würden mich da Erfahrungen auch interessieren.

von Jim M. (turboj)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Falk B. (falk)


Bewertung
0 lesenswert
nicht lesenswert
@ 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.

von Falk B. (falk)


Bewertung
0 lesenswert
nicht lesenswert
@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.

von Roy H. (roy01)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Roy H. (roy01)


Bewertung
0 lesenswert
nicht lesenswert
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

von Falk B. (falk)


Bewertung
1 lesenswert
nicht lesenswert
@ 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.

von Roy H. (roy01)


Bewertung
0 lesenswert
nicht lesenswert
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.

von c-hater (Gast)


Bewertung
-4 lesenswert
nicht lesenswert
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.

von Roy H. (roy01)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Falk B. (falk)


Bewertung
0 lesenswert
nicht lesenswert
@ 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 ;-)

von c-hater (Gast)


Bewertung
-3 lesenswert
nicht lesenswert
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.

von Gu. F. (mitleser)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Roy H. (roy01)


Bewertung
0 lesenswert
nicht lesenswert
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.

von m.n. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
@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.

von Falk B. (falk)


Bewertung
0 lesenswert
nicht lesenswert
@  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.

von m.n. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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 ;-)

von Roy H. (roy01)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Steffen H. (avrsteffen)


Bewertung
0 lesenswert
nicht lesenswert
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"

von Falk B. (falk)


Bewertung
0 lesenswert
nicht lesenswert
@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

Antwort schreiben

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

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.