Guten Abend, eine theoretische Frage: Bei Mouser findet man externes SRAM bis zu 1Mbit, das sich über SPI ansprechen lässt. Meine Frage ist nun, wofür man das genau benötigen könnte? Klar, wenn der Controller selbst zu wenig RAM hat. Aber das Problem ist doch viel eher, wie man dieses externe RAM per SPI in den eigenen Code einfügt ohne Handstände machen zu müssen? Ich bezweifle, dass sich ein C-Compiler dazu überreden lässt, das externe SRAM in den Controller-Eigenen Speicherbereich einzubinden und dann automatisch (SPI)-Lese- und Schreibvorgänge auszuführen, sollte auf Variablen im externen SRAM zugegriffen werden (lesend oder schreibend - je nach dem). D.h. rein praktisch gesehen lässt sich externes SRAM nur für große, aneinanderhängende Daten verwenden (z.B. große Arrays oder Strukturen), sehe ich das richtig? Alles andere würde nach meiner kurzsichtigen Denkweise keinen Sinn machen, ein Beispiel: Für eine uint8_t Variable müsste ich mir im Controller die (je nach externem SRAM) 20-bit lange Adresse merken, was natürlich viel mehr Platz benötigt, als die Variable gleich im internen RAM abzulegen. Für ein großes Array oder eine große Struktur merke ich mir dann nur die Startadresse und die Länge und lese das sukzessive aus dem externen SRAM aus. Oder hab ich da etwas komplett falsch verstanden? Mehr Sinn würde externes RAM machen, dass man über eine eigene Peripherie, die der Controller schon mitbringt, parallel ansteuern kann und für das Compiler auch Unterstützung mitbringen.
Max M. schrieb: > Ich bezweifle, dass sich ein C-Compiler dazu überreden lässt, das > externe SRAM in den Controller-Eigenen Speicherbereich einzubinden Dafür braucht's den Compiler auch gar nicht. Der Controller bildet diesen externen Speicherbereich auf seinen adressierbaren Speichrbereich ab und regelt den Zugriff transparent. Schau dir 'mal das QSPI-Interface bei den großen STM32-Controllern an. Jens
Max M. schrieb: > D.h. rein praktisch gesehen lässt sich externes SRAM nur für große, > aneinanderhängende Daten verwenden (z.B. große Arrays oder Strukturen), > sehe ich das richtig? ja. > Mehr Sinn würde externes RAM machen, dass man über eine eigene > Peripherie, die der Controller schon mitbringt, parallel ansteuern kann > und für das Compiler auch Unterstützung mitbringen. Auch das wurde bereits vor über 50 Jahren erfunden. Die meisten Mikrocontroller haben allerdings keinen externen Adress-/Datenbus - die sind darauf optimiert, dass alles intern ablaufen kann. Da muss man dann eben einen auswählen, der die eigenen Bedürfnisse abdeckt. fchk
Typisches Beispiel wo sowas Sinn machen kann: Du hast einen schnellen, seriellen ADC und willst mit dem eine kurze Zeitspanne sampeln und die Daten dann hinterher aufwendiger auswerten. Der µC hat dafür meist nicht das nötige RAM und nicht die Leistung um das live zu machen. Dann kannst Du zuerst die Daten vom ADC direkt ins serielle RAM schieben und dann hinterher in aller Ruhe auswerten. Natürlich wäre ein µC oder FPGA mit (DDR-)DRAM schöner, aber oft auch deutlich größer und aufwendiger.
Ich habe mir damit einen Analyzer gebaut. Dabei werden 8-Bit-Daten mit einem Latch abgetastet und mit bis zu 10MHz in 8 parallele SPI-RAMs geschrieben. Ein AVR kümmert sich dabei um die Triggerung und schiebt die Daten, nachdem eine Sequenz eingelesen ist, per UART an einen PC, der sie dann in aller Ruhe mit seiner Core-I-Power anzeigen und auswerten kann. Der große Vorteil der SPI-RAMs gegenüber normalen statischen RAMs ist, daß die Adressen automatisch inkrementiert werden.
Thomas E. schrieb: > Ich habe mir damit einen Analyzer gebaut. Dabei werden 8-Bit-Daten mit > einem Latch abgetastet und mit bis zu 10MHz in 8 parallele SPI-RAMs > geschrieben. Ein AVR kümmert sich dabei um die Triggerung und schiebt > die Daten, nachdem eine Sequenz eingelesen ist, per UART an einen PC, > der sie dann in aller Ruhe mit seiner Core-I-Power anzeigen und > auswerten kann. Der große Vorteil der SPI-RAMs gegenüber normalen > statischen RAMs ist, daß die Adressen automatisch inkrementiert werden. Naja, nette Spielerei und wahrscheinlich in ASM. Aber 10 MBit RAM kriegt man als DRAM deutlich kleiner und einfacher. Die pappt man an den passenden Controller mit exterer Speicherschnittstelle und gut. Beitrag "Re: Viel RAM am kleinen Controller"
Falk B. schrieb: > Die pappt man an den passenden Controller mit exterer > Speicherschnittstelle und gut. Die AtXmega sind glaub ich eher die Ausnahme als die Regel wenn es um ein Interface für externen Speicher geht. Normalerweise muss man da eher in Richtung M4 schauen, normale 8bitter haben sowas nicht.
Da wird anscheinend eine eigene malloc Funktion "psmalloc" verwendet. Könnte man so nicht auch vorgehen, über eine eigene malloc funktion? Ich verstehe nicht, warum man die "MMU" vom ESP32, die mit dem SRAM kommuniziert, nicht auch in Software nachbauen kann?
Andere Variante: Wenn das SRAM als Ebenen-Puffer für ein Display dient. Oft kann man dann - ohne die Daten nochmal über den µC zu leiten - die Pixel dann direkt vom SRAM ins Display takten.
Falk B. schrieb: > Naja, nette Spielerei und wahrscheinlich in ASM. Ja sicher. Aber ASM? Ich? Steht das SM nicht für Saso Mado oder so ähnlich? Und das A für Analog ohne og?
Max M. schrieb: > Normalerweise muss man da eher in Richtung M4 schauen, normale 8bitter > haben sowas nicht. eZ80 z.B. schon, und alle wirklich alten 8bit-CPUs. Allerdings nur 64k, aber das konnte man im vorigen Jahrtausend schon erweitern. Was man für normal hält ist natürlich rein subjektiv. Georg
Habe ich verwendet für: - Messwertpuffer und späteres Übertragen per Draht/Funk - Bildschirmpuffer - Puffer für ein kleines Webinterface - Dynamischen Puffer für Updates: per X- bzw. Y-Modem hochladen und danach optional ins EEPROM Unterbau ist fast immer ein kleiner ATMega.
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.