Tach HMV,

Die Frage erübrigt sich eigentlich, oder?
Für gute 30 Kröten hätte ich eine funktionierende Hard- und Software.
Würde es mir nur darum gehen, einem AVR ein paar Stackprotokolle beizubringen, wäre das der einfachste Weg gewesen.
Die nächsteinfacheren Wege wären dann das Kopieren bereits existenter Projekte.
Kanns also auch nicht sein.

Geht es dir nicht manchmal so, etwas selbst zu entwicklen? Ich zumindest kann wesentlich besser mit Eigenentwicklungen arbeiten, als mit fremden.

Ökonomisch sollte man als Bastler doch eh nicht denken, kam dieser Spruch nicht mal von dir?

Trotzdem, danke für die Rückmeldung

_________________

also für die 20 Euronen die der Bausatz kostet hab ich keinen Gedanken an Selbstbau verschwendet und der NetIO ist auch eine prima Grundlage für unkopierte eigene Software. Dafür bekommt man eine richtig schöne Platine und alle Bauteile, was will man mehr? Ätzen um des Ätzens willen muss ich nicht haben.

_________________
Tschüüüüüüüs

Her Masters Voice
aka
Frank

***********************************
Der optimale Arbeitspunkt stellt sich bei minimaler Rauchentwicklung ein...
***********************************

Jaja, ich verstehe deine argumentative Grundlage.

Aber dann könnte die Hälfte aus dem Forum, die (noch) kein Geld damit verdient, eigentlich dicht machen - der Selbstbau lohnt meistens nicht.

Ich zumindest habe (noch?) Freude am Selbstbau, inkl. Ätzen, solcher Dinge.
Kann sein, und wird auch so sein, dass es anders wird, wenn hinter den Bauten die Lebensgrundlage steckt.


Achja, als der ENC28J60 noch nicht so berühmt war, habe ich das an einer ISA-Karte probiert... Die Zeiten ändern sich.

Genaugenommen hätte ich auch einen größeren ARM nehmen können, die haben manchmal eine NIC an Board.


_________________

@DonComi:

Ich finde es klasse, dass mein alter Thread wieder weiterdiskutiert wird.
Allerdings möchte ich folgendes erwähnen:

Es gibt bereits ein solches Projekt mit Open-Source von Ulrich Radig:
Hier der Link dazu.
Hier fast das selbe nochmal, allerdings perfekt für ein Hutschienen-Gehäuse.

Integriert sind Display, eine Mini-Kamera, Schnitstelle zum Erweitern, ...
Die Software enthält dies auch alles, zusätzlich noch viele Extras wie Temperatursensoren, Temperaturabhängige Schaltvorgänge ohne laufenden PC, ....
Hier das offizielle Forum dazu, einfach mal unter ETH_M32_EX oder AVR-Webmodule nachlesen.

Code für ETH
Code für AVR-Webmodul

Ich würde mir auch gerne das fürs Hutschienengehäuse besorgen, allerdings hätte ich gerne Taster-Ausgänge und die Weboberfläche so, dass neben jedem Butten zum Aktivieren eines Ausgangs für ca. 1 Sek eine Anzeige eines Eingangs ist, mit der man den Schaltzustand überwacht.
Somit kann man noch zusätzliche Taster ohne PC verwenden.

Das glaube ich wäre eine sinnvolle Anwendung.


Und:
Ein Gegenstück fehlt noch! Also ein Teil, an dem man Schalter/Taster anschließt, die Signale übers Netzwerk übertragen werden und von einem dieser Geräte von Uli Radig wieder ausgegeben werden.

Gruß
sebra

Hallo,

Opensource bedeutet, dass der Kode offen liegt, du kannst ihn also auch deinen Wünschen anpassen.

Ich werde mit diesem Projekt sicherlich nicht alles von Grund auf neu machen, wozu auch.

Mir schweben da aber jetzt schon Dinge vor, die man mit den genannten Modulen nicht machen kann.

Denkbar ist eine absolute Miniversion, in der die RJ45-Buchse den meisten Platzt einnimmt, wozu auch immer man derlei Miniaturisierung benötigt.


Man sieht zwischen Ethernetcontroller und Mikrocontroller eine zweipolige Pfosten-"leiste", an der kann man weitere Peripherie über UART anschließen.
Zudem wäre die Platine ohne den ext. SRAM wesentlich kleiner, würde man ENC28J60 und AVR in SMD-Version verbauen würde man alles in ein Hutschienengehäuse mit 1TE bekommen, mit ein paar Relais zusätzlich bräuchte man mehr Platz.

_________________

Die Idee finde ich super!
Eine Miniversion, also Lan-Buchse und ein digitaler Ausgang (Relais oder Transistor oder was auch immer).

Ein Webinterface sollte natürlich schon dabei sein. IP-Adressenänderung ganz einfach über das Interface. Und drei Buttons dazu:
- Einschalten
- Ausschalten
- Impuls (also für ca. 1 Sek einschalten, dann wieder aus)


Ich denke, dass so ein Teil wirklich gut ankommt, bei mir tuts das bestimmt. Wer will nicht Dinge vom PC aus steuern...
Ein Eli kann das Teil sicherlich z.B. in eine Senseo integrieren (intern oder extern), und der Kaffee wird vom PC aus gekocht...
(Müsste man nur noch wissen, mit welcher Spannung die Senseo-Bedienung läuft)

Gruß
sebra

Hallo,

Aktuell bin ich noch dabei, IP korrekt zum Laufen zu kriegen.
Rein praktisch läuft es jetzt schon, zumal ich jetzt sogar eine IP-Kopfdatenbereich-Prüfsumme errechne, nur das ID-Feld wird nicht korrekt ausgefüllt. Wenn ich dort eine Konstante reinschreibe, klappt es, aber sobald ich einen variablen Wert (z.B. Resultat einer Berechnung) einfügen will, kommt nur Murks raus (Prüfsumme stimmt nicht mehr u.ä.). Vielleicht optimiert der Compiler Sachen weg, die nicht weg sollen... Muss ich mir noch anschauen.

Ansonsten hab ich vorerst erstmal nur UDP auf Transportschicht eingebaut. TCP kommt später, wenn ich Zeit dafür habe, ist ja doch ein wenig aufwändiger als UDP.

Rein theoretisch sind viele Dinge denkbar, von statischer IP-Zuweisung (hart kodiert), über Änderung der IP während der Laufzeit (Web-Interface) bis zum automatischen Bezug einer IP über DHCP und eigenem Aliasnamen über DNS.

Allerdings müssen dazu die Schichten darunter erstmal vorhanden sein, nämlich Auflösung von IP- zu MAC-Adresse (arp).


Naja, ich werde das Stück für Stück machen, hab nebenbei ja schließlich noch anderes zu tun.


Das Schwierige dabei ist nicht die jeweilige Funktion, wie z.B. von dir vorgeschlagen, sondern die Vielfalt an Funktionen. Änderung am Quellkode inkl. Rückschreiben des Programmes auf den µC bringt eine sehr variable Anpassungsmöglichkeit an die jeweiligen Einsatzbedingungen. Nur, und das ist das Problem, es ist zu kompliziert. Da müsste man sich eine Scriptsprache ausdenken, die einfach zu lernen ist und dessen Interpreter man zusätzlich implementieren müsste.
Man könnte dann das Script über Webinterface laden und ausführen. Es würde dann die Steuerung der Hardware übernehmen. So ist alles denkbar, ohne den Programmkode des µCs zu manipulieren.

Aber ich muss aktuell keine Diplomarbeit schreiben, das spare ich mir auf... .



_________________

Zitat :

Nur, und das ist das Problem, es ist zu kompliziert. Da müsste man sich eine Scriptsprache ausdenken, die einfach zu lernen ist und dessen Interpreter man zusätzlich implementieren müsste.

Da lohnt es sich vielleicht einen Blick auf Forth zu werfen. http://de.wikipedia.org/wiki/Forth_(Informatik)

Tach perl,

Nicht schlecht!
Zudem scheint es bereits eine Implementierung für AVRs zu geben.
Außerdem bräuchte ich dann (nicht nochmal ) das Rad neu zu erfinden.

Naja, jetzt muss ich in den nächsten Wochen erstmal einige Protokolle unterstützbar machen.

Hatte vorhin auch noch das Problem, dass die MAC-Adresse falsch waren: AVRs benutzen Little Endian, die Network Byte Order (Netzwerkbytereihenfolge; ich liebe unsere Sprache ) ist aber Big Endian.
Aufgefallen ist mir das erst richtig, als ich an zwei Switchports gelauscht habe, denn die Pakete wurden schön an alle weiterverteilt. Ist ja auch kar, da kein Knoten mit dieser MAC-Adresse existierte.

Man sollte sich die Frames schon genauer anschauen, bevor man höher auf den Stack (der Protokolle) klettert, ohne das überhaupt klar ist, dass es auf ethernet-Ebene läuft...

Naja, ist ja auch vorerst nicht so wichtig.

Edit:
@Sebra:

Zitat :

Wer will nicht Dinge vom PC aus steuern...

Darum geht es fast nur noch sekundär.
Steuern kann man auch per USB (lokal), RS232 (lokal) oder LPT (lokal) oder anderen denkbaren Schnittstellen (auch lokal...).
Der Reiz bei Netzwerk liegt darin, dass ab IP (Internet Protokoll) die Pakete routbar werden, man also rein theoretisch vom anderen Ende der Welt zu Hause das Licht ausschalten kann .
Das geht zwar auch ohne so ein Gerät (Router mit ssh-Server und Magigpacket zum Anschalten eines lokalen Rechners über Wake On Lan, auf dem dann bspw. ein zweiter ssh-Server läuft, der dann übr o.g. Schnittstellen steuert), aber so ist es bedeutend energie- und zeitsparender.

Klar, IP muss nicht zwingend auf Ethernet aufbauen, denkbar wäre auch RS232 mit Modem. Nur, Ethernet ist Standard für Netzwerk geworden und wir haben hier zu Hause seit der letzen Renovierung überall Leitungen inkl. Doppeldosen und zentralem Patchfeld. Darüber könnte man ergo vieles verwalten (was ich ehrlicherweise nie benötigte... ).

Da es aber nur ein Bastlerprojekt ist, sollte man das für bestimmte Aufgaben nicht einsetzen. Keines der Bastlerprojekte, inkl. der Pollinversion.

Elektrische Sicherheit geht nun mal vor alles, und da sollte man auf kommerzielle Dinge setzen.

Ich hatte mal kürzlich hier von einem User eine Anfrage, ob ich als E-Student sowas entwickeln könnte, für die Energieversorgung einer Fabrik
Hab freundlich abgelehnt .



_________________


[ Diese Nachricht wurde geändert von: DonComi am 28 Aug 2009 22:32 ]

Zitat :

Aktuell bin ich noch dabei, IP korrekt zum Laufen zu kriegen. Rein praktisch läuft es jetzt schon, zumal ich jetzt sogar eine IP-Kopfdatenbereich-Prüfsumme errechne, nur das ID-Feld wird nicht korrekt ausgefüllt. Wenn ich dort eine Konstante reinschreibe, klappt es, aber sobald ich einen variablen Wert (z.B. Resultat einer Berechnung) einfügen will, kommt nur Murks raus (Prüfsumme stimmt nicht mehr u.ä.). Vielleicht optimiert der Compiler Sachen weg, die nicht weg sollen... Muss ich mir noch anschauen.

Hallo,
Ist gelöst.

Das Problem lag, natürlich nicht, am Compiler, sondern an folgendem Problem:

In der Routine zum Übertragen eines Pakets in den Speicher des ENC28J60 werden die Zeiger auf das erste Byte und letzte Byte des Pakets korrekt geändert (ETXST und ETXND). Die Adresse im RAM wird automatisch inkrementiert (Bit AUTOINC).

Ich habe diesen Zeiger aber nie geändert, deshalb passierte folgendes:
Die MAC hat immer den selben Teil verschickt, die geänderten Daten landeten irgendwo anders im FIFO, da der Adressenzähler immer inkrementiert wurde, und ich beim erneuten Verschicken den Paket-Start-Zeiger immer an eine bestimme Position zeigen ließ.

Deshalb konnte ich einmalig ein Paket korrekt ausgeben, aber Änderungen in irgendwelchen Headern wurden nicht versendet, da immer der gleiche Bereich im RAM ausgegeben wurde...
Wenn der 8k-Bereich komplett automatisch durchgezählt und zugeschrieben wurde (übrigens auch der Teil, der als FIFO für das Empfangen von Paketen zuständig ist ) fing er wieder bei 0000h an, überschrieb also das erste Paket, das dann ausgegeben wurde. Je nach Länge des Pakets waren 50 Durchgänge möglich, bis er mir diesen Bereich überschrieben hat, danach kam nur noch Datensalat an .

Jedenfalls klappt es jetzt, nachdem ich auch EWRPT (Schreibzeiger sozusagen ) ändere.

_________________

So, wenn jemand sowas gerade sucht; hier ein UDP-Server.
Damit empfange ich aktuell Debugmeldungen über UDP, die dann direkt in die Shell geschrieben werden.

Zum Geschreibsel:
Beenden mit STRG+C, allerdings fängt das Programm dieses Signal nicht ab, brauchte halt nur was zum Anzeigen, nichts ernsthaftes. So kann auch ein Pufferüberlauf auftreten und sonstiges... .

Einfach mit make all oder make udp aufrufen. Anschließend mit ./udp starten.
Es wird auf Port 1025 gelauscht, IP-Adresse ist nicht festgelegt, kann jede sein.

Vielleicht benötigt jemand sowas, vielleicht auch nicht .

P.S.:
Eventuell gibt es Probleme bei Optimierungsstufe Os. Ggfs. im Makefile auf -Os2 ändern, oder Optimierung abschalten.


_________________

Hallo an alle,

ich bin neu hier und habe bis jetzt nur den kleinen Atmega8 programmiert.
Nun möchte ich diese kleinen einfachen Programme über Netzwerksteuern über UDP.

Ich habe folgende Hardware "AVR NET IO" gekauft.
Zum Programmieren nehme ich folgende software "Programmer´s Notepad"

ich habe zwar schon versucht eine webserver so abzuwandenl bin aber kläglich gescheiter. In der netzwerkthematik bin ich nicht so tief drin das ich den ganzen code verstehe.

ich suche nur einen code der eine UDP schnittstelle auf meinen Atmega32 bereitstellt.

hat hier jemand solch einen code?

Ich möchte dann diesen Code noch erweiten mit digitalen und analgogeb E/A´s.


Gruß
Househasi

Hallo househasi und herzlich Willkommen im Elektronikforum!
:sm12:

Ich hätte hier Kodeschnipsel für UDP herumliegen, ist eigentlich nichts Besonderes, allerdings habe ich momentan keine Zeit, mich weiter um das Projekt zu kümmern.

Hast du eine Art Treiber für den ENC28J60? Ich habe zwar auch einen eigenen, aber der ist nicht 100% getestet, da sich mein ENC28J60 merkwürdig verhält (der ist, je nach Rev. ziemlich verbugt, ist schon ziemlich zum Kotzen, wenn man sich nicht mal darauf verlassen kann, dass das Datenblatt auch stimmt... Die Workarounds sind auch nicht gerade der Hammer...).

Um UDP nutzen zu können benötigst du die Schicht darunter, IP und noch weiter unten in diesem Fall Ethernetframes.

Code :

#define PROTOCOL_UDP 0x11 typedef unsigned short int udp_port; typedef struct { udp_port udp_src_port; /* Source port */ udp_port udp_dst_port; /* Destination port */ uint16_t udp_lenght; /* Header and payload lenght */ uint16_t udp_chk; /* Checksum */ } ATTR_PACKED udp_header;

Das ist ein einfacher UDP-Header. Der liegt wiederum im Datenbereich des Internetprotokolls IP. Das muss nicht so sein, ist aber eigentlich Standard.

Da ich ungern ungetesteten Quelltext herausrücke und ich außerdem bei Weitem nicht der Einzige bin, solltest du erstmal auf umfangreich getestete Quellen zurückgreifen.

Allerdings, nachdem ich mit meinem Controller Probleme mit den INTs bekommen habe, habe ich mal ein wenig danach gegoogelt und es hat sich herausgestellt, dass der Controller nicht immer 100% zuverlässig und je nach Rev. auch die eine oder andere (meiner Meinung nach nicht hinnehmbare) Macke hat. Das muss dann selbst im Treiber umgangen werden und so sind die u.U. nicht sofort lauffähig auf der eigenen Version...

Bei mir klappte nach vielleicht einer Stunde das Senden von Paketen perfekt (das Abschreiben der Registeradressen hat am längsten gedauert )
Das Empfangen klappt allerdings überhaupt nicht. Konfiguriert ist er schon richtig, die Receive-Display-LED blinkt auch, wenn ich ihm Broadcasts reinschicke, aber es passiert, trotz aller abgeschalteten Filter (Broadcasts können gefiltert werden) nichts... Habe auch weder Zeit noch Lust, da aktuell weiter zu suchen, wird schon klappen irgendwann.

Öhm, ja wie gesagt, spielt kaum ne Rolle, von wem du den Quelltext bekommst, ein wenig ändern musst du ihn schon, und wenn das mit anderen nicht klappt, wirds mit meinem auch nicht klappen


Es gibt aber, wenn ich mich nicht irre, Software, die für dein Board geschrieben wurde, weil wohl auch einige nicht so zufrieden mit der Originalsoftware waren. Da müsstest du mal googeln, ob und wie man sich das auf UDP umstrikt. UDP ist einfacher als TCP, aber sobald man einen richtigen UDP-Stack aufbaut, um bspw. gleichzeitig mehrere "Verbindungen" zu gestatten, wirds auch da komplizierter. Verbindungen in Anführungszeichen, weil UDP-Datengramme keine Verbindungsorientierung besitzen.

_________________