|
Anzeige
|
USB Stick mit AVR/STM32 und CFI
Gast
#6087892
Hallo Angenommen ich möchte einen kleinen USB Stick bauen, mit einem AVR oder STM32 und einen modernen standartisierten CFMI Flashchip verwenden. Wie ist vorzugehen? Kann ein solcher uC überhaupt direkt einen solchen Flashchip ansteuern? Existieren libarys für USB Mass storage device, sowie für die ganzen Flashsachen... Badblocktabelle etc? Das ganze sollte eher ein Spass Projekt werden und hat keine komerziellen Absichten.... MiroSD Karte bzw Slot via SPI anschließen ist eine Größenordnung einfacher und billiger.
Gast
#6088185
Jim M. schrieb: > MiroSD Karte bzw Slot via SPI anschließen ist eine Größenordnung > einfacher und billiger. und langsamer.
Gast
#6088188
USB Stick schrieb: > Das ganze sollte eher ein Spass Projekt werden und hat keine > komerziellen Absichten.... Damit du auch richtig Spass hast sollen wir gleich alles für dich suchen und entwickeln, gelle? Einfach mal warten bis einem die gebratenen Tauben in den Mund fliegen. Nur einen Moment, gleich werden hilfsbereite Jünger auf dich zukommen.
Gast
#6088219
Nachtigall schrieb: > Damit du auch richtig Spass hast sollen wir gleich alles für > dich suchen und entwickeln, gelle? ja :-) Nee natürlich nicht. Anyway wear leveling bad block management etc. ist nicht etwas was im rahmen eines spass projektes reinfällt. Also ohne library oder Vorarbeit irgendwelcher Art wirds wohl nicht gehen.
Gast
#6088220
Stefan ⛄ F. schrieb: > Jim M. schrieb: >> MiroSD Karte bzw Slot via SPI anschließen ist eine Größenordnung >> einfacher und billiger. > > und langsamer. wieso nicht gleich ein EMMC. Oder gleich einen USB Stick bei mediamarkt kaufen? :P
Gast
#6088230
Viele STM32 haben einen Flexible Memory Controller für SRAM und FLASH, QUAD SPI und SDIO/SDMMC. Damit solltest du alles an Speicher abdecken können was du so findest. Außerdem entsprechende USB-Schnittstellen mit integriertem PHY. Das ist allerdings auf Full Speed beschränkt. Es gibt auch einen High Speed USB der braucht allerdings ein externes PHY. Eine Mass Storage Class für den USB gibt es von ST, allerdings wirst du die Schnittstelle zwischen USB Class und deinem Speicherinterface selber machen müssen. Auch FatFS gibt es von ST, jedoch komplett fertig nur für die SD-Karte. Es gibt aber die Möglichkeit das FatFS auch auf anderen Speichertypen zu verwenden, da muss man seine LL Verbindung von FatFs zum Speicherinterface selber implementieren. Die meiste Geschwindigkeit wirst du vermutlich über eMMC oder FLASH rausholen. Je nach Speichertyp hast du da bis zu 16 Datenleitungen (ich glaube es gibt mittlerweile auch mehr? bin da nicht so auf dem aller neuesten Stand.) Der µC sollte möglichst viel RAM haben, aber erwarte keine überragende Performance.
Gast
#6088366
mit Mbed sind das nur ein paar Zeilen Code, siehe Beispiel am Ende der Seite: https://os.mbed.com/docs/mbed-os/v5.15/apis/usbmsd.html Auch wenn es aussieht das da etwas fehlt: nein, es ist ein komplett funktionsfähiges Programm. Als Dateisystem wird das verwendet was auf der SD Karte drauf ist. Das MSD arbeitet Blockorientiert und braucht daher nur ein Blockdevice. Davon bietet Mbed gleich mehrere, mit dem Austauch einer Zeile kannst du die Daten in einen SPI Flash, QSPI Flash, ins RAM des µC, in den Flashspeicher des µC oder sonstwo hinlegen. Nachtigall schrieb: > Damit du auch richtig Spass hast sollen wir gleich alles für > dich suchen und entwickeln, gelle? Muss jetzt jede Flachzange hier antworten das sie es nicht kann? W.S. Disclaimer: der o.g. verlinkte Code darf natürlich von studierten Informatikern benutzt werden die nichts mehr lernen müssen.
Gast
#6089789
Danke Johannes, damit ist das Problem der USB schnittstelle gelöst. Das Problem mit dem Flash sehe ich weiterhin. Klar SD karten Emmc etc können direkt über SPI angeschlossen werden. Ziel ist jedoch ein direkter Anschluss eines modernen Flash chips. Das entsprechende managemant müsste dan der uC übernehmen. Interface, Blöcke löschen/umschreiben, wear leveling, bad block tabelle, ECC usw. Also ein Low Level access zum Flash.
Gast
#6089818
Es können wie geschrieben auch Speicherchips wie W25Qxxx durch Austausch des BD benutzt werden. Ein BD kann auch ein Filter sein das man zwischen dem Speicher und dem MSD einschleift. In dem Filter kommt die Schreib/Lese Anforderung rein und dann man sein wear leveling, Statistik, read only oder sonstwas machen. Das geht schön generisch, da haben sich einige schon richtig ausgelassen: https://os.mbed.com/docs/mbed-os/v5.15/apis/blockdevice.html Als Beispiel mal das https://github.com/ARMmbed/mbed-os/blob/master/features/storage/blockdevice/ProfilingBlockDevice.cpp da werden read/write 1:1 durchgereicht und einfach gezählt für eine Statistik. USB Stick schrieb: > Das Problem mit dem Flash sehe ich weiterhin. Klar SD karten Emmc etc > können direkt über SPI angeschlossen werden. > Ziel ist jedoch ein direkter Anschluss eines modernen Flash chips. Das > entsprechende managemant müsste dan der uC übernehmen. Interface, Blöcke > löschen/umschreiben, wear leveling, bad block tabelle, ECC usw. Also ein > Low Level access zum Flash. Was lässt Dich denn glauben, daß ein Low-Level Management des Flash "modern" wäre? So wie ich den Markt sehe, wäre das eigentlich eine gute Idee, hat sich aber im Embedded-Markt nicht durchgesetzt. Was sich am Markt durchgesetzt hat ist entweder QSPI-NOR-Flash für kleinere Speichergrößen und für alles über ein paar Megabytes dann eMMC. Ein Grund den ich mir dafür vorstellen könnte, ist daß es recht aufwendig ist mit rohem NAND einen zuverlässigen Bootloader zu implementieren. Denn auch die ersten Sektoren, die normalerweise gerne für Bootblöcke verwendet werden, sollten bei NAND Teil des Defect-Management und Wear-Leveling sein. Antwort schreibenBitte melde dich an, um einen Beitrag zu schreiben. |
Anzeige
|
