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?
uCs reichen nie! knacke einen WLAN Router mit USB Schnittstelle um.
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
Wiznet und die Varianten wären eine Alternative. Da ist der TCP/IP-Stack schon in großen Teilen fertig drin.
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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.