uC -> USB mass storage -> PC

S

Stephan Walter

Guest
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
 
On 21 Jun 2004 14:15:40 +0200, "Stephan Walter"
<stephan.walter@epfl.ch> wrote:
Indem man diese Dateien überschreibt, kann der AVR programmiert werden. Auslesen ist
natürlich ebenfalls möglich.
Klingt auf den ersten Blick gut, auf den zweiten nicht.
Click to expand...

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 ...

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?
Du könntest einen intelligenten Treiber schreiben, der deren DLL
Click to expand...
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
 
Stephan Walter schrieb:

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?
Click to expand...
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
Von-Werth-Straße 111 email: audiovisual@t-online.de
50259 Pulheim / Germany WGS84:N50°57'50.2" E06°47'28.5"
 
Stephan Walter wrote:
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
Click to expand...
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.
 
In article <40d6d16c$1@epflnews.epfl.ch>,
"Stephan Walter" <stephan.walter@epfl.ch> writes:
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.
Click to expand...
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
 
Hallo Gernot!

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.
Click to expand...
Welchen USB<=>RS232-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
 
Oliver Bartels wrote:
Weil: Beim Programmieren möchte man Checks wie Empty/Verify usw.
starten können und die Ergebnisse sehen.
Click to expand...
md5sum? Ist aber nicht so komfortabel

Außerdem: Woher soll der Programmierer wissen, wann er beim Flash
mit dem Löschen loslegen soll, das kommt bekanntlich vor dem
Umprogrammieren.
Click to expand...
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.

Und last not least: Der Baustein-Typ will eingestellt sein ...
Click to expand...
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
 
Andreas Neuzner wrote:
Ich habe dieses Problem allerdings mit einem usb nach seriallwandler

Welchen USB<=>RS232-Wandler benutzt du denn mit welcher Programmer-Software?
Click to expand...
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
 
In article <cb74bq$9d5$01$1@news.t-online.com>,
"Andreas Neuzner" <andreas.neuzner@t-online.de> writes:
Hallo Gernot!

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.

Welchen USB<=>RS232-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.
Click to expand...
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
 
In article <40d73dc0@epflnews.epfl.ch>,
Stephan Walter <stephan.walter@epfl.ch> writes:
Andreas Neuzner wrote:
Ich habe dieses Problem allerdings mit einem usb nach seriallwandler

Welchen USB<=>RS232-Wandler benutzt du denn mit welcher Programmer-Software?

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.

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

--
MFG Gernot
 
Stephan Walter schrieb:

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.
Click to expand...
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
Von-Werth-Straße 111 email: audiovisual@t-online.de
50259 Pulheim / Germany WGS84:N50°57'50.2" E06°47'28.5"
 
Stephan Walter <stephan.walter@epfl.ch> schrieb:

Beim AVR muss man nicht löschen, sondern kann einfach überschreiben.
Click to expand...
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."
Kristian Köhntopp, de.comp.os.unix.misc
 
You must log in or register to reply here.

Welcome to EDABoard.com

Sponsor

Back
Top