Hallo allerseits! Heute stelle ich Euch ein neues Projekt vor, ein Basisboard für eigene AVR-Netzwerkanwendungen. Schon vorhanden sind folgende Hardwareeinheiten: - ATmega128 mit 64 kBytes externem RAM - Netzwerk-Interface mit dem ENC28J60 - MMC/SD-Interface - USB-RS232-Wandler FTDI FT232R - Standard-ISP-Schnittstelle - Erweiterungssteckerleiste mit I2C, SPI, ADC Natürlich ist die Idee nicht ganz neu, aber ich wollte es selbermachen. Die Herausforderung für mich war aber eher die Software, insbesondere der Netzwerkstack. uIP finde ich ziemlich umständlich zu verwenden, vor allem wegen einem fehlenden Datenpuffer, so dass die Anwendung für Paketwiederholungen die Daten erneut erzeugen muss. Enthalten sind im Moment also folgende Software-Module: - Ethernet/MAC, IP, ARP, ICMP-Ping, UDP, TCP - MMC/SD-Unterstützung mit FAT16 des sd-reader - SPI, UART, XMEM - Systemuhr, Timer - DHCP-Client - HTTP-Server mit GET/HEAD/POST-Unterstützung und Authorisierung Der Server stellt im Moment die Dateien der Speicherkarte ins Netz und listet Verzeichnisinhalte auf. - Periodische Uhr-Synchronisierung übers Netzwerk mit dem TIME-Protokoll (RFC868) Von den 128 kBytes Flash sind inkl. aller Anwendungen und Demos ca. 38 kBytes belegt. Die RAM-Nutzung ist sehr stark abhängig von der Netzwerkkonfiguration. Bei maximal drei TCP-Verbindungen mit Pufferspeicher für je ein maximal großes Paket in Sende- und Empfangsrichtung werden ca. 13 kBytes benötigt. Zu finden ist all das unter http://www.roland-riegel.de/mega-eth/ Die Quelltexte habe ich auch an diese Nachricht angehängt, den Schaltplan und das Layout gibts auf der Website. Einige Dinge würde ich in der Zukunft noch gerne entwickeln oder verbessern: - einfacher(er) Zugriff auf I/O-Hardware über HTTP, vielleicht mit einer simplen Textersetzungs-/Skriptsprache - ausführlichere Tests bzgl. unterschiedlicher Netzwerkkonfigurationen - bessere TCP-Flusskontrolle, soweit möglich - usw. Viel Spaß damit, Kommentare sind natürlich willkommen. Gruß, Roland
Hier noch ein Bild von dem Board in Betrieb. Gruß, Roland
Angehängte Dateien:
-
mega-eth_rev10.jpg
(62 KB)
Hi, interesanntes Projekt! Leider in C (wie viele WebServer-Projekte auch). Gibt es auch Quellen in Bas? Grüße Alex
Gast
#869733
Hi Alex, gibt es doch, sogar in Bascom! http://heldt-intern.dyndns.org/index.php?page=webserver Leider ist die Resonanz nicht groß genug für eine Platinenauflage!!!
Hallo, klasse Projekt. Finde es super das auch andere Leute sich die mühe machen und ihren eigenen besseren TCP/IP Stack schreiben als den µIP. Ich selber programmiere auch gerade in die selbe Richtung und bin fast fertig. Ich hatte vor wenn ich fertig bin mit meinem Studium (ca in 2 Monaten) das Teil auch online stellen für die Allgemeinheit :-). Solange kann ich nur sagen weiter so!!!. Wir können uns ja auch mal austauschen wenn du willst, da ich in etwa im selben Stadium stecke wie du. CA Dirk
Gast
#870015
Hallo Roland, läßt Du davon (mehrere?) Bords machen? Viele Grüße Achim
@Alex, Nein, Bascom-Quelltexte habe ich keine. Wäre ja auch ein bisschen komisch, wenn ich mir die Programmierung nach C nochmal in Basic antun würde... @Dirk, Kannst meine Quellen ja mal durchsehen, vielleicht hilft Dir ja das ein oder andere weiter. Ansonsten einfach ne Mail schreiben. @Achim, Nein, im Moment habe ich nicht vor, weitere Platinen herstellen zu lassen. Mein eigenes Board beruht noch auf der geringfügig fehlerhaften Revision 1.0. Davon habe ich hier noch drei rumliegen, gefertigt bei Haka. Bei Interesse würde ich die zum Selbstkostenpreis von ca. 15 Euro abgeben. Einfach eine Mail an feedback(at)roland-riegel.de, Zuschlag nach Reihenfolge des Eingangs. Bei der alten Revision 1.0 ist 1. die Spannungsbuchse ein klein wenig zu weit rechts, so dass das Bohrloch ein wenig verdeckt wird (zumindest mit meiner Buchse), und 2. beim ISP-Stecker die MISO/MOSI-Leitungen vertauscht, was man mit zwei kurzen Brücken auf der Rückseite korrigieren muss. Gruß, Roland
Hier ein kleines Software-Update zur ursprünglichen Version. Die Änderungen sind vor allem im FAT16-Code zu finden. Neben Optimierungen der Codegröße werden jetzt vor allem Verzeichnisse schneller durchsucht. Dies hilft auch dem HTTP-Server auf die Sprünge, der deshalb zuvor bei gut gefüllten Verzeichnissen recht träge antwortete. Gruß, Roland
Gast
#892277
Hi, hast du vielleicht eine Bauteilliste? Würd das gerne nachbaun und in Betrieb nehmen. Hab schon länger nach sowas gesucht. Aber Bauteile wie den FB2022 finde ich hier in Österreich nirgends. Mfg, Donald
Hmm, ne fertige Liste habe ich nicht, Du kannst sowas aber aus Eagle heraus exportieren. Die meisten Teile (vor allem SMD) habe ich von Segor. Die anderen, insbesondere den Karten-Slot, den ENC28J60 inkl. Quarz und den FB2022 von CSD. Gruß, Roland
Gast
#892754
Danke für die schnelle Antwort =) Hab bis jetzt so gut wie jedes Bauteil auftreiben können. Nur an ein paar Teilen wie den, FB2022 und den SRAM bin ich gescheitert. Mfg, Donald
Hallo Roland kann ich noch eine Platine bekommen ? LG Vajk
Ja kannst Du. Näheres in der privaten Nachricht. Gruß, Roland
Hallo Roland, klasse Projekt! Errinnert mich irgendwie an Ethernut - hast Du schon mal NUT OS auf dem Board ausprobiert? Gibt´s noch Platinen? - Gruß w.
Gast
#996674
Hast du auch noch eine für mich ? .... ich hoffe das ich das hin bekomm ... was smd angeht bin ich leider nicht so fit ...
@BillX Siehe Mail. @Wolfgang Eine habe ich noch. Siehe private Nachricht. Gruß, Roland
Hallo ich hab mir passend dazu eine Schnittstellen-Schaltkarte gebaut ... und passe gerade meine Software an ... und irgendwie komme ich da in eine Begrenzung .. Anbei der Code, wenn ich im Bereich von HTTPD_MODULE_REASON_HANDLE_REQUEST_CONTINUE den Maximalwert von sbx auf 4 setze geht alles pirma bei 8 bleibt er irgendwo hängen, obwohl ich keine Stelle gefunden habe, wo der Speicher überlaufen kann, *) es kommen auch nur 5 (statt 8) Zeilen im Bauser an ... Irgend eine Idee, was da schief laufen kann ... komm grad nicht weiter und falls ins Bett :-) LG Vajk *(denke da an hpptd_session.c / httpd_session_write_content_P hier buffer 32, aber gequeed)
... Ergänzung, da muß was in die Begrenzung laufen ... Text geändert und es gibt eine Zeile mehr Seiten-Quelltexte des Browsers anbei ... Was mir noch auffällt, daß dieser Bereich nach einem Button-Druck 3 mal durchlaufen wird (via USB ausgegeben) Irgendeine Idee ?
@ Vajk .v.i. Ähnliches habe ich bei einer der frühen 2008er AVR-GCC Versionen gesehen wenn Pointer auf Arrays auf dem Stack benötigt wurden. Du kannt zum Testen ja mal dein "buffi[10]" static machen (damit lief es dann bei mir).
Hallo Vajk, Du kannst nicht endlos Daten mit httpd_session_write_content() rausschreiben. Dafür ist der Puffer zu klein, denn die Daten werden ja erst nach Verlassen der Funktion verschickt. Den freien Platz kannst Du mit httpd_session_get_write_buffer_size() in Erfahrung bringen. Falls Du mehr Daten senden willst, musst Du Dir die aktuelle Position merken und von dort fortsetzen, wenn der Callback wieder mit HTTPD_MODULE_REASON_HANDLE_REQUEST_CONTINUE aufgerufen wird. Dafür solltest Du auch den Rückgabewert von httpd_session_write_content() verwenden. Erst wenn Du httpd_session_end_content() und httpd_session_close() aufrufst, wird der Callback nicht mehr aufgerufen und die TCP-Verbindung geschlossen. Für ein Beispiel schau Dir auch mal httpd_module_file_callback() an. Hier werden die Dateien der Speicherkarte stückweise rausgeschickt. Gruß, Roland
Hallo Roland, jetzt hab ich das alles mal geändert ... .. und geht .. nur nach dem zweiten oder dritten Zugriff (Klick) gehts manchmal super lange oder wird gar nicht verarbeitet ... bleibt aber nicht hängen auf der Konsole .. irgend eine Idee, woran das noch liegen könnte oder ist der atmel einfach überlastet mit zwei bis drei zu verarbeitenden klicks .... Und noch ne Fragen, kann man die Url verändern, die zum browser geht ? LG Vajk
Hallo Vajk, > jetzt hab ich das alles mal geändert ... Das sieht prinzipiell schon ganz gut aus. Ich hätte die Infos zum Schalten der Portzustände allerdings per GET-Parameter in der URL angegeben, aber das ist nur ein Detail. > .. und geht .. nur nach dem zweiten oder dritten Zugriff (Klick) gehts > manchmal super lange oder wird gar nicht verarbeitet ... bleibt aber > nicht hängen auf der Konsole .. Nach dem Abrufen einer Seite wird die dazugehörige HTTPD-Session bzw. die TCP-Verbindung erst nach einigen Sekunden geschlossen. Bei vielen Anfragen schnell hintereinander gehen die TCP-Sockets und/oder die HTTPD-Sessions aus, weshalb der ATmega dann erst bei eventuellen Retransmits des Browsers reagiert (oder bei einem Timeout eben gar nicht mehr). Je nach RAM-Ausstattung kannst Du die Anzahl der TCP-Sockets/-Verbindungen und der HTTPD-Sessions erhöhen: - TCP_MAX_SOCKET_COUNT/TCP_MAX_CONNECTION_COUNT in tcp_config.h - HTTPD_MAX_SESSIONS in httpd_config.h Alternativ oder zusätzlich kannst Du auch das Warteintervall des TCP-Protokolls verringern, nach dem die Sockets freigegeben werden und somit für neue Verbindungen zur Verfügung stehen: - TCP_TIMEOUT_TIME_WAIT in tcp_config.h > Und noch ne Fragen, kann man die Url verändern, die zum browser geht ? Meinst Du diese Versuche in Deinem Code? strcpy(session->uri, "/"); strcpy(session->arguments, "\0"); Wenn Du damit den Browser umleiten willst, geht das so nicht. Stattdessen musst Du in der Antwort einen "Location:"-Header angeben (siehe die vorhandenen Beispielmodule und HTTP-RFCs). Aber warum willst Du überhaupt umleiten? Gruß, Roland
Hallo Roland, > Das sieht prinzipiell schon ganz gut aus. Ich hätte die Infos zum > Schalten der Portzustände allerdings per GET-Parameter in der URL > angegeben, aber das ist nur ein Detail. ja wollte ich auch, aber das doofe ? mag ich nicht und post ging im beispielcode, aber dann nicht mehr ... .. und "links zum klicken" sind "smarter" und "links"-verträglicher (Konsolenbrowser). Danke für die Tipps. >> Und noch ne Fragen, kann man die Url verändern, die zum browser geht ? > Meinst Du diese Versuche in Deinem Code? > Wenn Du damit den Browser umleiten willst, geht das so nicht. ne ging mir nur um das Säubern der url-Zeile. Herzlichen Dank Vajk
Vajk .v.i. wrote: > .. und "links zum klicken" sind "smarter" und "links"-verträglicher > (Konsolenbrowser). Naja, genau das ginge aber auch mit GET. Vielleicht kannst Du ja Deine ?-Antisympathie noch überwinden... ;-) Sag Bescheid wenn Du weitere Fragen hast, hier oder auch per Mail. Gruß, Roland
Ich habe gerade angefangen mich in dieses Projekt einzulesen. Exzellente Arbeit! Das AVR-Studio mag aber mit dem makefile nicht richtig umgehen und wirft die bekannte Meldung "Object file not found on expected location". Deswegen habe ich ein Projektfile fürs Studio und einen Patch angehängt, evtl. hilft das dem einen oder anderen. Die richtigen Einstellungen fürs XMEM waren gar nicht so einfach zu finden.
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.