|
Anzeige
|
Frage an die STM32-Experten:Guten Morgen, ich schaue mir gerade nach STM32-Boards um, die Arduino-Kompatibel sind. Dabei sehe ich einen STM32F405 von Adafruit (https://www.adafruit.com/product/4382). Dort steht das er 1MB Flash hat. Soweit so gut. Zusätzlich steht da 2 MB SPI Flash chip. Frage: Kann ich in dem 2MB SPI Flash auch Programmcode ablegen oder ist das wie eine kleine SD-Karte zu betrachten? Wenn nein, welchen STM32 kann man extern mit Flash versehen um z.b. 256MBit oder gar 512MBit (64MB) zu bekommen?
Direkt in den Addressraum einblenden geht nur mit FSMC Interface (das wäre z. B. für parallele Flash) oder QSPI/OctoSPI-Interface. Der F407 hat nur FSMC, also für serielles Flash: Nein.
Wie oben gesagt: Für serielle Flash alle mit QSPI/OctoSPI, also "neuere" F4 (etwa F446), alle F7, H7, U5 und teilweise bei anderen Familien -> Datenblätter wälzen oder in CubeMX nachsehen. Je nach Pinzahl muss man aber aufpassen, ob auch wirklich alle benötigen Signale an Pins zur Verfügung stehen.
Beim F405 eher wie eine klein SD-Karte um Daten abzulegen.
Wenn du sowas willst schau dir mal AN4760 (https://www.st.com/resource/en/application_note/an4760-quadspi-interface-on-stm32-microcontrollers-and-microprocessors--stmicroelectronics.pdf) an. Da sind die unterstützten STM32 drin inkl. einer Reihe von Erklärungen dazu.
Leider ist das nicht gerade Up-to-Date und listet nur QSPI auf, OctoSPI fehlt komplett, und das ist gerade standardmäßig bei allen neuere "Dickschiffen" (statt QSPI!) drin.
Ich frage mich gerade, was für eine Anwendung es geben könnte, 64MB Programmspeicher auf so einem uc zu haben. Was hast du vor?
Programmsspeicher ist mehrdeutig. Was ausführbaren Code anbelangt, kommt man bei 64 MByte sicher etwas ins Grübeln. Aber ein GUI wird leicht gefräßig. Natürlich gibt es keinen zwingenden Grund, die ganzen Icons etc. im direkt zugänglichen Programmspeicher abzulegen statt auf einem Sekundärspeicher. Aber bequemer ist es irgendwie schon ... Man spart sich das ständige Umschaufeln übers RAM.
Mir geht es tatsächlich um ausführbaren Code. Nicht etwa weil ich so viel brauche, sondern falls ich ihn bräuchte. Eventuell kann man einen Teil des Flash als Laufwerk hernehmen und dort Daten direkt ablegen. Aber das ist nur ein Anwendungsfall der momentan nicht im Raum steht.
Sehr, sehr wenige Mikrocontroller-Anwendungen haben so viel Code. So viel Code kannst du unmöglich selber schreiben, und selbst mit TCP/IP-Stack, Webserver und diversen weiteren Protokollen kommst du bei weitem nicht in diese Größenordnung.
Wenn man TouchGFX nutzt geht das vollautomatisch.
Die ganz großen Controller haben noch den FMC, welcher auch paralleles NAND und NOR ansteuern und in den Adressraum einblenden kann. Wobei ich mich ein bisschen frage wie das dann mit dem Wear-Leveling vom NAND funktioniert, schließlich nutzt der sich ja auch durchs Lesen ab.
SUPER Entscheidungskriterium. Warum nicht radhard mit Bitcoinminer ? Nicht dass du das brauchst, aber falls du es mal bräuchtest.
Anscheinen gibt es doch Kunden die das brauchen. z.B. STM32H74/5 gibt es mit max. 2 MByte internem Flash. Wer mehr braucht kauft die (billigere) "Value Line" Version mit nur 128 KByte Flash. Dann kann man bis zu 256 MByte über QSPI als "memory mapped" Flash einbinden. Im internen Flash liegt dann nur der Bootloader der QSPI und den externen Flash initialisiert und in den Addressraum einblendet. Ich denke nicht das STM das aus Spaß gemacht hat. Interner Flash ist natürlich schneller. Ein fertiges Board mit H750 und 8Mbyte QSPI Flash gibts bei Ali für ca 25€. Als Anwendung könnte ich mir vielleicht elektronischen Bilderrahmen vorstellen. ps. Die H7 sind meiner Meinung nach nichts für (blutige) Anfänger ;-).
Völlig egal - Hauptsache "Arduino-Kompatibel". Da kommen dann auch schon mal so große Programme zusammen. µCs ohne SSD-Interface sind eigentlich nicht mehr vorstellbar :-(
Zitat aus der SW Entwicklung: "Von einer einzigen konkreten Implementierung zu abstrahieren ist schlecht, aber von gar keiner zu abstrahieren ist eine Katastrophe."
Brauchen schon, aber nicht alles als Programmspeicher. So kann man beispielsweise bei einfacheren grafischen Sachen für Displays die Bilder gleich im internen Flash speichern und selbiges bei Webservern, wo man einfachere Websites dann auch gleich im internen Flash speichert und sich so den externen Speicher sparen kann.
Musst du dich durchs Datenblatt wühlen, ob der am FSMC hängt. Dann sollte das gehen. Eine weitere Option wäre, den Chip per Dateisystem einzuhängen, dann kannst du dort Daten ablegen und lesen und damit machen was du willst. FAT über SPI auf eine SD-Karte konnte schon der Cortex-M3 vor 12 Jahren... SD besser noch über SDIO oder MMC, dann geht das auch richtig fix, das haben ja auch viele STM32. Die Disco Boards mit H7 und Display haben auch große zusätzliche Speicher drauf, sowohl RAM als auch Flash. Der CubeProgrammer kann diesen Flash auch beschreiben indem ein Stub ins RAM geladen wird, man muss da also nicht immer ein riesiges binary flashen wenn nur etwas im Code geändert wird. So machen es auch die Demo Apps mit denen die Boards ausgeliefert werden.
Danke. H7 sehe ich als BGA. Die möchte ich vermeiden. Habe ich zwar früher schon gemacht, aber fürs Hobby muss ich mir das nicht antun. Vor allem nicht, wenn ich das selbst löten muss. Denke ein STM32F446ZC als LQFP144 scheint nett zu sein. Da ist sogar ein Display-Interface dabei. Die Frage nach dem externen Flash: wenn man den steckbar macht, kann man Firmwareupdates ohne PC/Laptop beim Kunden durchführen. Und das in Sekunden. Für den Fall das es produktiv angewendet wird.
Man kann auch über eine SD-Karte oder USB-Stick den internen Flash updaten, oder vollautomatisch über WiFi oder Mobilfunk. Keiner tauscht mehr manuell Speichermodule beim Kunden aus.
Ja sicher, weil es heute noch zeitgemäß ist, einen Flash auszutauschen für ein FW Update. Das macht man, wenn es offline sein muss, über ein standardmäßiges Speichermedium wie USB Stick oder SD Karte.
Klar, und wenn das Update nicht geht, wars das. Rücktausch nicht möglich. Aber es spielt ja eh keine Rolle, da ich ja nicht Frage warum du Golf spielst oder Angeln gehst. Du tust es einfach und willst wissen wie man den neuen Köder am einfachsten durchtauschen kann. Daher macht es auch keinen Sinn dir zu erklären das ich es nicht verstehe und du es auch nicht sein lassen wirst. Fisch im Supermarkt zu kaufen ist für mich viel sinnvoller. Deine Intention eine andere. Ich werde dich dennoch nicht versuchen dich davon zu überzeugen das Kaufen leichter ist als Angeln. Also unterlasse dies bitte auch bei mir.
Rücktausch passiert vollautomatisch dank A/B-Update.
Nicht wenn man es richtig macht. Und da es quer durch ganze Industrien so gemacht wird, scheint es wohl möglich zu sein.
Darum geht es hier nicht. Wenn das implementiert ist, ok. Aber auf die Frage warum so viel Flash, weil unnötig, spielt keine Rolle. Ich habe eine Frage und ein Ziel. Ein warum ist daher unnötig, solange du deine Gewohnheiten nicht an meine anpasst. Frage an dich Niklas G.: wie gut kennst du dich mit diesen STM32 aus?
Du hast eher viele Fragen aber kein Ziel. Die Hardware wird nach den Anforderungen ausgesucht und nicht schon mal vorab, prophylaktisch 1GB Flash eingeplant und 2 Jahre damit verbracht wie man den am besten anbindet, um dann später zwei LEDs blinken zu lassen. Das führt eben nur zu viel was-wäre-wenn rumlabern. Implementiert bekommst du so jedenfalls nichts.
Merkt man an den Posts.
Kann sein. Was ist aber wenn ich das ignoriere und es dennoch mache?
Da gibt es fertige Implementationen für. Das ist Standard. Du handelst dir wahrscheinlich mehr Ärger durch wackelige / korrodierende Kontakte des Programmspeichermoduls ein als du durch ein OTA-Update jemals haben wirst. Mir graut bei dem Gedanken QSPI über ein Steckinterface zu führen bei einer Industrieanlage; die Vibrationen sorgen für Wackelkontakt bei einzelnen Bits und du wunderst dich warum der Controller hin und wieder was völlig unvorhersehbares macht. Die Kosten für die Arbeitszeit des Technikers der zum Gerät hinlaufen und Speichermodule stecken muss sind sehr schnell höher als die für ein LTE-Modul plus IoT-eSIM.
Wenn die gängige Technik dein Ziel nicht besonders gut erreichbar macht, sollte man sich Gedanken machen, ob es da nicht bessere Möglichkeiten gibt.
Ganz passabel.
Dann mach. Bisher redest du nur.
Meine Frage war nach dem Speicher am STM32. OTA kam von euch. Darauf hin kam ich mit steckbarem Speicher. Könnte noch gelbe Leiterplatte einwerfen, wenn es euch darum geht zu labern.
Hast Angst ich mache dir Konkurrenz?
Also bist du kein STM32-Experte?
Das war andersrum. Du wolltest den Programmspeicher auf ein steckbares Modul bauen:
Darauf hin habe ich dich darauf hingewiesen, dass das nicht zeitgemäß ist, OTA-Updates die bessere Lösung sind, und das somit auch kein Argument für externen Programmspeicher ist.
Im Vergleich zu dir schon.
Nein, ich habe nach dem Speicher gefragt am STM32. Das Modul kam erst nach dem OTA-Vorschlag, den ich aber gar nicht brauche.
Es geht hier aber nicht um den Vergleich zu mir, sondern zu den echten Experten. Du bist also keiner, also hättest dir das Kommentieren sparen können.
Alternative Fakten?
Mein Vorschlag mit dem OTA-Update bezog sich direkt auf deinen Wunsch, das Speichermodul steckbar zu machen.
Ich habe genug Industrieprojekte mit STM32 umgesetzt um zu wissen, dass externer Programmspeicher, noch dazu steckbar, ziemlicher Overkill ist. Aber die Frage wurde ja beantwortet: Du kannst Speicher mit QSPI oder FMC ansteuern. Viel Spaß damit. Hallo Jens, Du willst dir ein Arbuino Board kaufen ? Mach das. Du willst den Spi-Flash-Chip darauf steckbar machen ? Das sind 8 Pin Chips dafür gibt es Buchsen und Stecker im passenden Raster. Mach das. Sind noch Fragen offen ? ;-)
Ja! Woher nimmst du diese Annahme für deine oben gestellten Fragen?
Tja, "schwätzen" kann jeder! Beweise doch dass du es kannst oder gar gemacht hast!
Weißt du überhaupt noch selber was du tun willst?
Willst du meine diversen Arbeitgeber anrufen oder was? Ansonsten kann ich natürlich meine STM32-Tutorials sehr empfehlen, ARM-ASM-Tutorial und USB-Tutorial mit STM32
Gerade kam ein Kollege und meinte "den kenn ich". Ist lachend weggelaufen.
Dann muss der wohl ein großer STM32-Experte sein. Frag ihn doch.
STM32 ist ARM, und ARM kann auch Code aus dem RAM ausführen. Den darfst Du von überall her laden - CF, SD, Lochkarten etc. Und Du kannst je nach Typ auch hinreichend viel RAM anschließen. Das wäre eine universellere Lösung, mit der Du deutlich flexibler bist. H7 ist im übrigen nicht zwangsweise BGA. Da gibts z.B. den STM32H743BI im LQFP208 Package. Das ist noch handlötbar. fchk
Also jeder der dich kennt ist automatisch ein STM32 Experte? Ganz schön arrogant. Überrascht mich aber nicht, denn das hat mein Kollege auch gerade gemeint. Ich werde ihn mal ausquetschen woher er dich kennt und wann du vom Kunden gekündigt wurdest.
Er muss ja offenbar meine Kompetenz beurteilen können.
Na wir sind alle gespannt wenn der Märchenonkel was zu erzählen hat. Ich hol Popcorn. Nachdem du aber jemand bist der sich an seine eigenen Beiträge ein paar Stunden später nicht erinnern kann, hab ich nicht allzu viel zu befürchten.
Zeit den Thread zu schließen. War von Anfang bis Ende sowieso nur Unfug und jetzt machst du dich vollends lächerlich.
Vielleicht weil ich lesen kann ? Es soll z.B. auch Datenblätter geben, die nicht nur Experten lesen können. Antwort schreibenBitte melde dich an, um einen Beitrag zu schreiben. |
Anzeige
|
