uC -> USB mass storage -> PC

Hallo,

nachdem der serielle Port endgültig ausgestorben ist, möchte ich mir einen AVR-Prommer für USB bauen. Dabei ist mir folgende Idee gekommen:

Der Prommer gibt sich als Mass Storage-Gerät aus, d.h. wird unter Windows/Linux/Mac als herkömmliches Speichermedium erkannt. (Hat den Riesenvorteil, dass für keine der drei Betriebssysteme irgendein Treiber oder Prommer-Software geschrieben werden muss)

Ein uC simuliert ein FAT-Dateisystem mit ein paar Dateien (Beispiel: als Laufwerk G: eingebunden): G:\FLASH G:\EEPROM G:\FUSEBITS Indem man diese Dateien überschreibt, kann der AVR programmiert werden. Auslesen ist natürlich ebenfalls möglich.

Ich bin überzeugt, dass diese Idee funktioniert, nur weiss ich nicht, wie ich sie realisieren soll. Mit dem 245BM von FTDI hab ich schon ein bisschen gebastelt, aber der kann meines Wissens nicht als Mass-Storage fungieren, oder irre ich mich da?

Was ich also suche, ist ein Chip, der sich per USB anschliessen lässt und sich als Mass Storage-Gerät ausgibt, und an den man einen uC anschliessen kann, der die ganze Dateisystem- und Programmiergeschichte übernimmt.

Gruss, Stephan Walter

Reply to
Stephan Walter
Loading thread data ...

Auslesen ist

Klingt auf den ersten Blick gut, auf den zweiten nicht.

Weil: Beim Programmieren möchte man Checks wie Empty/Verify usw. starten können und die Ergebnisse sehen.

Außerdem: Woher soll der Programmierer wissen, wann er beim Flash mit dem Löschen loslegen soll, das kommt bekanntlich vor dem Umprogrammieren.

Und last not least: Der Baustein-Typ will eingestellt sein ...

sie realisieren

kann meines

Du könntest einen intelligenten Treiber schreiben, der deren DLL anspricht. Der kann dann auch mit einem Popup die geeigneten Befehle und Statusmeldungen austauschen.

Gruß Oliver

--
Oliver Bartels + Erding, Germany + obartels@bartels.de
http://www.bartels.de + Phone: +49-8122-9729-0 Fax: -10
Reply to
Oliver Bartels

Stephan Walter schrieb:

sie realisieren

kann meines

Scheint mir nicht sinnvoll. Es gibt an frei verfügbaren MSD eigentlich nur USB-IDE bridges und USB-Flashcontroller für Memorysticks. Der Aufwand, sowas an die Erfordernisse des Proggers anzupassen dürfte sehr hoch sein.

Wenn Du schon FTDI in den Mund nimmst, warum machst Du es nicht mit der USB-Serial Bridge?

- carsten

--
Audio Visual Systems                          fon: +49 (0)2234 601886
Carsten Kurz                                  fax: +49 (0)2234 601887
 Click to see the full signature
Reply to
Carsten Kurz

AVR-Prommer

Windows/Linux/Mac

Warum so umständlich? Zwei Möglichkeiten fallen mir spontan ein:

  1. Umsetzerchip von USB nach RS232, z.B. FTDI, SiliconLabs, etc.
  2. uC mit USB, der sich als Human Interface Device ausgibt. Datenrate zwar nicht sehr hoch, aber dafür kann man ihn einfach unter jedem Betriebssystem ansprechen.
  3. uC, der sich als Soundkarte ausgibt, braucht ebenfalls keine speziellen Treiber.
Reply to
Erik Hermann

AVR-Prommer

Windows/Linux/Mac

keine der

werden muss)

Laufwerk G:

Auslesen ist

Die Idee ist gut. Aber wenn du einen fertigen USB zu IDE adapter verwendest brauchst du "nur" eine festplatte simulieren.

Ich habe dieses Problem allerdings mit einem usb nach seriallwandler gelöst. Damit läuft unter Linux und Windows auch die alte Software. Dos-soft geht leider nicht.

--
MFG Gernot
Reply to
Gernot Fink

Hallo Gernot!

gelöst.

Welchen USBRS232-Wandler benutzt du denn mit welcher Programmer-Software? Bei vielen Wandlern kommt es zu riesigen Verzögerungen bei der Programmierung, da scheinbar von Softwareseite nach jeder Zustandsänderung an einer Leitung zurückgelesen wird - so dass die USB-Puffer extrem ausbremsen.

Grüße Andreas

Reply to
Andreas Neuzner

md5sum? Ist aber nicht so komfortabel

Beim AVR muss man nicht löschen, sondern kann einfach überschreiben. Für andere uCs müsste man halt die Daten zwischenspeichern, löschen und dann schreiben.

Naja, mittlerweile sehe ich ein, dass es wohl doch nicht so einfach wäre wie ich mir das vorgestellt habe. Trotzdem danke für deine Antwort

Stephan

Reply to
Stephan Walter

Das nähme mich auch Wunder, ich habe nämlich schon CHF40 für einen USB->serial Wandler ausgeben, der überhaupt nicht funktionierte, jedenfalls nicht mit meinem Selbstbau-Billig-Prommer (ohne uC, nur ein paar Dioden/Widerstände). Der USB->serial hatte einen Prolific Chip.

Stephan

Reply to
Stephan Walter

Ich benutze einen pl2303 mit einer eigenen software umter linux. Ein gewisses ausbremsen merkt man vor allem dann wenn weniger als

2 oder 3 byte auf einmal übertragen werden. Ab 16-Byteblöcken bei 38400 Baud stört das nicht mehr so stark.

Das mit den Zustandsänderungen ist auch richtig. Jede Statusänderung erzeugt ein Datenpaket. Das sollte man beim Design beachten und möglichst verhindern.

Die problematische Richtung ist vom Pc zum uc. Am besten geht bei mir

32 byte zu senden und dann auf ein Quittungszeichen zu warten. Dieses sendet der uC nachdem er 16 Zeichen empfangen hat. Daraufhin sendet der Pc die nächsten 16 Zeichen.

Dadurch komm ich mit 32 Zeichen Puffer aus und hab relativ wenig verzögerung.

--
MFG Gernot
Reply to
Gernot Fink

Stimmt. Das Bitklimpern war auch im Kernelmodul für linux nicht richtig eingebunden.

--
MFG Gernot
Reply to
Gernot Fink

Stephan Walter schrieb:

Das kann auch nicht gehen, den direkten Registerzugriff auf die Portpins erlauben diese Dinger nicht. Da muss schon ein uC drin sein, der das zu programmierende File über normale serielle Kommunikation erhält.

- Carsten

--
Audio Visual Systems                          fon: +49 (0)2234 601886
Carsten Kurz                                  fax: +49 (0)2234 601887
 Click to see the full signature
Reply to
Carsten Kurz

Stephan Walter schrieb:

Sorry, aber das ist (für den Flash -- anders beim EEPROM) Unfug. Dort braucht's schon einen chip erase. (Beim Programmieren aus dem Bootloader heraus kann man auch seitenweise löschen.)

--
Jörg Wunsch

"Verwende Perl. Shell will man können, dann aber nicht verwenden."
 Click to see the full signature
Reply to
Joerg Wunsch

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.