Falk B. schrieb:
Was soll der Käse? Du hast IMMMER noch nicht verstanden, wie externer
SDRAM funktioniert! Aus Sicht des C-Programmierers genau so wie interner
RAM! Da braucht es keine Spezialfunktion!
Es ist nicht sinnvoll, den TE dafür zu beschimpfen, dass er sich offenbar strikt an die Dokumentation des HAL hält. Demnach sollen tatsächlich alle Zugriffe über die besagten Funktionen HAL_SDRAM_* erfolgen, weil darin auch eine Zustandsvariable und eine Verriegelung konkurrierender Zugriffe enthalten sind. Der eigentliche Kopiervorgang ist ein memcpy() für Arme. Es ist sogar ein "Speicherschutz" vorgesehen, der aber keineswegs einen Zugriff auf ein entsprechendes FMC-Register beinhaltet, sondern nur über die o.a. Zustandsvariable realisiert wird.
Vermutlich versucht ST damit, ein einheitliches Interface für alle möglichen externen Speicher zu schaffen, d.h. auch serielle Flashes usw.. Bei parallel angebundenem SDRAM ist das natürlich völlig sinnfrei. Es gibt durchaus manche Softwarearchitekten, denen besonders einheitliche und schicke Diagramme wichtiger sind als die technische Funktionalität; ich kann mir sehr gut vorstellen, dass solche elektronischen Hochglanzfolien dann als Implementierungsgrundlage dienten. Natürlich sieht das zunächst schön einheitlich und stimmig aus, so dass man damit ab einer gewisser Entscheiderebene punkten kann. Und man kann auch in den Werbeprospekt reinschreiben, dass es einheitliche APIs für alle externen Speicher gibt, unabhängig von ihren physikalischen Eigenschaften. Und so etwas finden auch manche Entscheider auf Kundenseite hochgradig attraktiv.
Ggf. war sogar mal in der technischen Beschreibung ein Hinweis auf die direkte Adressierbarkeit des SDRAM-Bereich enthalten, aber bei irgendeiner QS-Runde wurde dann festgestellt, dass hierdurch von der definierten Softwarearchitektur abgewichen würde. Zwecks Einheitlichkeit dürften dann solche dreisten Umgehungen nicht mehr Kunden gegenüber beschrieben werden. Außerdem wird dadurch ja der o.a. "Speicherschutz" umgangen.
Ein winziges Fünkchen Sinn könnte ich noch erkennen, wenn die Adresse im SDRAM relativ zur Startadresse angegeben würde. Hier ist ST aber inkonsequent und verlangt tatsächlich einen Pointer im gesamten Adressraum.
Du kannst einfach mit einem Pointer drauf zugreifen!
Exakt. Man konfiguriert das SDRAM ja auch nicht ständig um.
So wie das oben mit SDRAM_START_ADDRESS gemacht
wird. Aber im Normalfall schreibt man Variablen mit Kleinbuchstaben.
Alles in Großbuchstaben sind #defines. Das ist eine recht weit
verbreitete Regel.
Volle Zustimmung. Ggf. wäre es sinnvoll, einen Pointer (kleingeschrieben) mit einer Konstanten (z.B. großgeschrieben) zu initialisieren, sofern man z.B. einen Pufferbereich referenzieren will. Dennoch ist es WESENTLICH sinnvoller, nicht direkt mit den Adressen zu hantieren, sondern über den Linker die Platzierung der entsprechenden Variable im SDRAM zu steuern.
Eine ähnliche Diskussion hatte ich vor ca. 26 Jahren mit einem Hardwareentwickler, der auch nicht einsehen wollte, dass ich in meinem Programmcode keine expliziten Zugriffsfunktionen für den Speicher definieren muss, sondern dass der Programmcode direkt aus dem Speicher ausgeführt wird und ich auch für Datenzugriffe nicht explizit an den Steuerleitungen (/CS, /WR, /RD, o.ä.) wackeln muss.
