Ich wollte (aus Stromspargründen) einem µC das downloaden von files
beibringen, jedoch findet sich im web (google) nichts brauchbares (nur
high-level (benutzung einer best. gui) oder download-angebot zeug) ich
brauch aber nunmal eine Beschreibung auf "byte-ebene" (oder wenigstens
einen tipp welches Protokoll ich googeln muss). Interessant wäre auch
auf welchem Port das ganze abläuft...
Ich hoffe auf eure Antworten...
Max
PS: Reicht ein AVR um mit < 128 kB/s (DSL1000) auf ne SD-Karte zu downen
oder muss da ein arm ran?
noch ein paar links:
https://openwrt.org/
Damit bekommst du Linux auf vielen Routern fuer ca. 20 Euros zum laufen.
Das ist immer cooler als etwas selbst zu machen weils schon fertig ist
und well-established.
Ich habe viele Router umgeknackt und es hat immer geklappt. Man muss
sich natürlich vorher informieren.
Falls du das Netzwerk meinst: HTTP,TCP,IP in Wikipedia. Aber das willst
du dir wahrscheinlich nicht antun.
Grüße
- cl
Max schrieb:> Ich wollte (aus Stromspargründen) einem µC das downloaden von files> beibringen, [...]
Das musst Du schon etwas genauer spezifizieren, bevor Dir hier jemand
sinnvoll antworten kann. Download ueber http? Filesharing? FTP? ...
Volker
>ich>brauch aber nunmal eine Beschreibung auf "byte-ebene" (oder wenigstens>einen tipp welches Protokoll ich googeln muss). Interessant wäre auch>auf welchem Port das ganze abläuft...
FTP? Schau dich mal bei den AVR Webservern um. Da soll es sowas
ja mal gegeben haben;)
>PS: Reicht ein AVR um mit < 128 kB/s (DSL1000) auf ne SD-Karte zu downen>oder muss da ein arm ran?
Geht mit AVR grad so. Eher weniger.
Christoph Lechner schrieb:> uCs reichen nie!> knacke einen WLAN Router mit USB Schnittstelle um.
Warum sollten µC nicht reichen? Selbst bei den erwaehnten AVRs sehe ich
da kein Problem. 125000 Takte sollten doch wohl ausreichen um ein Byte
zu empfangen und weg zu schreiben, oder nicht?
Und die Router mit embedded Linux sind oftmals nicht die sparsamsten
Geraete... Und um's Stromsparen geht's doch hier.
Volker
Max schrieb:> Ich wollte (aus Stromspargründen) einem µC das downloaden von files> beibringen,
Auhaua... ;-)
> jedoch findet sich im web (google) nichts brauchbares (nur> high-level (benutzung einer best. gui) oder download-angebot zeug) ich> brauch aber nunmal eine Beschreibung auf "byte-ebene" (oder wenigstens> einen tipp welches Protokoll ich googeln muss).
RFC-791, RFC-792, RFC-793, RFC-768. Dann noch alles was darauf aufbaut.
> Interessant wäre auch auf welchem Port das ganze abläuft...
Das kommt darauf an: FTP, HTTP, HTTPS, Steam, NNTP, ...?
Für jedes davon gibt es wieder einen eigenen Standard oder es ist wie
Steam proprietär.
> PS: Reicht ein AVR um mit < 128 kB/s (DSL1000) auf ne SD-Karte zu downen> oder muss da ein arm ran?
Schwierig, Du hättest pro Byte so um die 160 Maschinenbefehle.
Andererseits haben ein paar Verrückte auf einem (irgendwie
aufgebohrten?) C64 sowas zum Laufen gebracht soweit ich weiss.
Jasch schrieb:> [...]> Schwierig, Du hättest pro Byte so um die 160 Maschinenbefehle.
Stimmt, ich habe mich um den Faktor 1000 verrechnet. :S
Bei 16MHz Takt waeren es 125 Takte zwischen zwei Bytes. Aber immer noch
im Bereich des Moeglichen, die vollen 1000 kBit/s zu schaffen...
Volker
Du willst mit 125 Takten das tcp/ip-Protokoll, das darauf aufsetzende
Dateiübertragungsprotokoll (http oder ftp) sowie die Ansteuerung der
SD-Karte und den darauf aufsetzenden Dateisystemtreiber (FAT16 oder eher
FAT32) hinbekommen?
Das ist hust unrealistisch. Sehr.
ich würde nur jedes zweite Bit (oder doch nur Byte ???) empfangen - man
würde damit satte 50% Energie sparen ...
Den Rest könnte man sich aus den CRC-Daten errechnen ..
Jens G. schrieb:> ich würde nur jedes zweite Bit (oder doch nur Byte ???) empfangen - man> würde damit satte 50% Energie sparen ...> Den Rest könnte man sich aus den CRC-Daten errechnen ..
Mach das zweimal, dann sparst du sogar 75% Energie!
Also ich danke erstmal allen für ihre konstruktiven Beiträge, dass das
schwierig werden wird war mir klar, aber darin liegt ja der Reiz des
ganzen :). Ich hab mir das in etwa so vorgestellt:
- Ich seh nen link im Inet (z.b: das neueste avr-studio von der atmel
seite...
- Ich schick den Link (mit nem chrome-plugin (später) oder nem schnellen
qt-Proggi (zum entwickeln) über das lokale Netzwerk an das netio (oder
wasauchimmer für hardware ich dann hab)
- das verbindet sich dann mit dem Server, lädt die datei (wenn ichs
richtig verstanden hab per http) runter und speichert sie (während des
DLs) auf ne sd-karte (zb. die auf dem netio extension board)
- am nächsten morgen komm ich und kuk nach (wie auch immer, is hier
nebensächlich) ob die Datei fertig is
- wenn ja nehm ich die Sd-Karte raus und schieb sie in meinen Pc rein
- fertig
Ich wär auch über ein low-level beispiel für einen (linux) PC schon
glücklich (einfach um mal ein gefühl zu bekommen).
Mein "Standard" framework (qt) hat dafür schon ziemlich fertige klassen
und verwendet die auch in seinem tutorial :(..
HTTP und FTP sind möglich - HTTP beschreibe ich hier:
Dafür benötigst Du einen TCP/IP-Stack.
Damit mußt Du eine Verbindung (http ist Port 80 TCP - kann aber auch ein
anderer genutzt werden) zu dem Server aufbauen.
Dann schickst Du die Anfrage an die Datei und wie der Server heißt an
diesen.
(Manche Server benutzen virtuelle Server, daher wird der Name benötigt,
da die IP nicht eindeutig ist)
Beispiel - ich hole eine Datei 'testfile.txt' mit dem Inhalt
'ABCDEFGHIJKLMNOPQRSTUVWXYZ' von meinem Webserver 'web' ab. Im Browser
würde man 'http://web/testfile.txt'; eingeben:
Du schickst dem Webserver:
1
GET /testfile.txt HTTP/1.1
2
Host: web
Und Du bekommst:
1
HTTP/1.1 200 OK
2
Date: Fri, 09 Sep 2011 23:45:14 GMT
3
Server: Apache/1.3.33 (Unix)
4
Last-Modified: Fri, 09 Sep 2011 23:44:57 GMT
5
Accept-Ranges: bytes
6
Content-Length: 27
7
Content-Type: text/plain
8
9
ABCDEFGHIJKLMNOPQRSTUVWXYZ
Danach schließt Du die Verbindung wieder - oder der Webserver tut es
nach einiger Zeit.
Evtl. mußt Du auch noch Cookies mitschicken. Das würde ich allerdings
erst im zweiten Schritt einbauen.
Volle Geschwindigkeit wirst Du sicherlich nicht schaffen. Mußt Du aber
auch nicht. Um Paketverluste kümmert sich der Stack.
Ach ja: Du benötigst natürlich auch die IP-Adresse, denn mit dem Namen
kann der Stack vermutlich so nichts anfangen. Dazu mußt Du eine
Namensauflösung (DNS - Port 53 UDP) machen. - Oder Du gibst beim Start
die IP gleich mit.
Gruß
Jobst
Rufus Τ. Firefly schrieb:> Du willst mit 125 Takten das tcp/ip-Protokoll, das darauf aufsetzende> Dateiübertragungsprotokoll (http oder ftp) sowie die Ansteuerung der> SD-Karte und den darauf aufsetzenden Dateisystemtreiber (FAT16 oder eher> FAT32) hinbekommen?>> Das ist hust unrealistisch. Sehr.
Wenn der µC auf unterster Ebene schalten und walten soll funktioniert
das mit diesem Takt natuerlich nicht, man muss das Ganze schon modular
aufbauen. Im Idealfall benoetigt das SD-Card-Modul nur das zu
schreibende Byte und den File-Handler einer (zuvor geoeffneten) Datei.
Das Netzwerkmodul bringt idealerweise schon einen TCP/IP-Stack inkl.
Fehlerkorrektur mit. Ob HTTP oder FTP (wobei wir hier vom TO ja immer
noch nichts genaues wissen) waere nach dem Header auch egal, da alle
Pakete nur noch aus Nutzdaten bestuenden (ein Encoding kann man ja mit
entsprechendem Request verhindern). Nach dem initiieren des Downloads
wuerde der µC also nur noch als Vermittler arbeiten: Byte und
Connection-Handler holen, Connection-Handler dem File-Handler zuordnen,
Byte und File-Handler schreiben. Und dann mit den uebrigen Takten noch
eine Fortschrittsanzeige realisieren! ;)
Steht hinter dem Projekt denn das Verlangen nach echtem Nutzen oder eher
der Ehrgeiz? ;)
Volker
Jens G. schrieb:> ich würde nur jedes zweite Bit (oder doch nur Byte ???) empfangen - man> würde damit satte 50% Energie sparen ...> Den Rest könnte man sich aus den CRC-Daten errechnen ..
Lass es mal lieber ganz sein, dann sparst du 100% Energie. CRC in
Software kostet einiges an Rechenzeit, da dürfte der Empfang des zweiten
Bytes weniger Zeit kosten. Außerdem kann ich mir nicht vorstellen, mit
CRC Daten wiederherzustellen, bei dem 50% fehlen.
Jens G. schrieb:> Den Rest könnte man sich aus den CRC-Daten errechnen ..
Toll, mach mal vor. Und hol dir anschließend alles an Preisen ab, was
die Fachwelt und WIssenschaft so anzubieten hat.
@Max
erzähl mal wo hier der Spareffekt entstehen soll ...
Mit einem AVR+ENC28J60 a'la NetIO über HTTP auf SD-Karte wirst du nur
einen Datendurchsatz von unter 3kB/s schaffen. Das währe (grob gerundet)
1/50 von 128kB/s. Damit würde der Download mit einem PC/Notebook 50x
schneller gehen. Wenn dein AVR 2W braucht aber 50x so lange läuft, so
ist der Download mit dem PC (mit dem Notebook auf jeden Fall) sparsamer.
Sascha
Nimm Linux und wget, vermutlich kann das dein vorhandener DSL-Router
schon.
Auf meiner Fritzbox 7240 kann ich mich z.B. mit Telnet einloggen und
einen wget-Befehl absetzen. Die Daten können dann an einen
angeschlossenen USB-Stick abgelegt werden.
Gruß
Roland
Um endlich mal die Frage zu beantworten. Nimm Wireshark. Damit kannst Du
auf Ethernet oder serieller Schnittstelle die Bytes mitloggen und dann
erklärt anschauen was da alles passiert. Du kannst auch nach Kriterien
filtern, so dass alles was Du nicht haben willst draußen ist.
Und ja, der AVR reicht, ist halt nicht irrsinnig schnell.
Ach ja, zum Argument, dass der AVR ja nur n Taktzyklen zur Verfügung
hätte um ein Byte zu verarbeiten. Das ist Unsinn. TCP führt eine
Flusssteuerung ein. Im Prinzip schickt der Sender erst dann neue Daten,
wenn der Empfänger die alten bestätigt hat. Streng genommen sendet der
Sender um die "Window Size" mehr Daten, diese wird aber von beiden
Teilnehmern ausgehandelt.
Also wie schon gesagt, besorg Dir Wireshark, schau Dir einen Download
an, versuche ihn zu verstehen, und Du solltest einschätzen können, was
zu tun ist. Es gibt ein paar kleine TCP/IP Stacks für AVRs die auch
client-Verbindungen unterstützen, die Benutzung würde ich Dir aber erst
empfehlen, wenn Du die Protokolle zumindest ansatzweise verstanden hast.
Eine der Befehle im Wireshark, die Dich interessieren werden ist
übrigens "Follow TCP-Stream", über den Rechtsklick zu erreichen, wenn
man ein TCP-Paket anklickt.
Ein zweites Programm was zweckmäßig ist, ist netcat. Damit kannst Du
auch mal eine TCP-Verbindung zu einem Sever aufbauen.
Rufus Τ. Firefly schrieb:> Du willst mit 125 Takten das tcp/ip-Protokoll, das darauf aufsetzende> Dateiübertragungsprotokoll (http oder ftp) sowie die Ansteuerung der> SD-Karte und den darauf aufsetzenden Dateisystemtreiber (FAT16 oder eher> FAT32) hinbekommen?>> Das ist hust unrealistisch. Sehr.
Und nicht vergessen, darunter kommt beim üblichen DSL noch mindestens
Ethernet und PPPoE.
Der Einfachheit halber würde ich einen ARM mit Linux drauf empfehlen -
da ist das praktisch alles schon vorhanden, man muss es bloss noch
benutzen.
Christian Berger schrieb:> Ach ja, zum Argument, dass der AVR ja nur n Taktzyklen zur Verfügung> hätte um ein Byte zu verarbeiten. Das ist Unsinn.
Im Durchschnitt stimmt das schon...
Innerhalb eines IP-Paketes stimmt es sogar hart - verlierst Du ein im
festen Zeitraster ankommendes Byte hast Du, hehehe, verloren. Vielleicht
puffert ja das Ethernet-IF noch etwas, aber wenn nicht (ist ja
vermutlich kein richtiger NIC mit Ring-Buffern, DMA und all dem modernen
Schnickschnack)?
Mal ganz abgesehen von der Codegröße, das alles in ein paar KB zu
quetschen ist schon Heldenarbeit.
> TCP führt eine Flusssteuerung ein. Im Prinzip schickt der Sender> erst dann neue Daten, wenn der Empfänger die alten bestätigt hat.> Streng genommen sendet der Sender um die "Window Size" mehr Daten,> diese wird aber von beiden Teilnehmern ausgehandelt.
Also wie schon gesagt würde ich mit einem AVR nicht rumbothern.
Flusssteuerung hin oder her, der hat zu wenig RAM und zu wenig
CPU-Leistung um da etwas wirklich brauchbares hinzukriegen.
Eine Lösung zwecks DSW wäre etwas anderes.
Jasch schrieb:> Innerhalb eines IP-Paketes stimmt es sogar hart - verlierst Du ein im> festen Zeitraster ankommendes Byte hast Du, hehehe, verloren. Vielleicht> puffert ja das Ethernet-IF noch etwas, aber wenn nicht (ist ja> vermutlich kein richtiger NIC mit Ring-Buffern, DMA und all dem modernen> Schnickschnack)?
Jedes Ethernet-IF muss mindestens ein komplettes Ethernet Paket
speichern können. Das sind 1500 Bytes. Sonst würde auch ein ARM das
nicht wirklich schaffen.
