Hi!
Da diese geniale Forum schliesslich ein Platz des Nehmens UND Gebens
ist, hier wieder mal ein Beitrag von mir ;)
Es handelt sich um eine einfachst Applikation für den ENC28J60.
Bewusst habe ich hier keine Server Software reingestellt(soweit bin ich
leider noch nicht :( ). Sonder nur mal die Grundsätzlichen Dinge,
die es braucht, um das kleine Kerlchen zum laufen zu bringen. Man kann
den beiden LED's beibringen zu blinken oder die link activity an zu
zeigen. Dies fand ich dann doch etwas wenig und konnte es nicht
lassen..
ich hab dann noch die ARP ICMP und UDP Unterstützung mit eingebaut.
Wobei zu sagen ist, dass bis jetzt nur auf Packete geantwortet werden
kann. Man kann noch kein UDP Packet von sich aus generieren und dieses
dann absenden. Allerdings kann man Anfragen an an die Schaltung senden,
worauf diese dann z.B. ADC Werte zurückliefert...
Ein kleines Beispiel für UDP ist auch dabei.
Genauere Erläuterungen, wie was genau eingestellt werden muss, bzw.
kann steht am Anfang der main.c.
Einen Schaltplan habe ich leider nicht. Ich hab mich gestern Stunden an
Eagle versucht, bis auf die Ethernet Buchse hat eigentlich auch alles
geklappt...Nun, ich bin zum Schluss gekommen, dass es wohl einfacher
ist, sich das Datenblatt der jeweiligen Buchse selbst anzusehen und
danach zu löten. Das des 40141 Magjack kommt im nächsten Post...
Die Verbindung zum Avr ist denkbar einfach; spi verbindungen sollten
klar sein, reset -> 3.3V und /CS kann angehängt werden, wo man gerade
Lust hat, man muss es einfach richtig einstellen(genaueres in main.c)
Möchte man den Code mit einem Anderen Controller verwenden, muss man
beachten, dass man die SPI Einstellungen ggf. noch ändern
muss(enc28j60.c in der init funktion)
Verwendet habe ich den AVR-GCC Version 3.4.3, Codegrösse alles
inklusive: 2024 Bytes.
Der Ram Verbrauch liegt etwa ~600bytes, man kann die Buffergrösse
allerdings noch ein wenig herunterschrauben..
So, das wärs glaube ich :-)
Nik
So, ich hab den Schaltplan doch noch hinbekommen. Allerdings habe ich
als Magjack einfach eine Stiftleiste verwendet, die Pin bezeichnungen
X1-1 bis X1-8 stehen dabei für die P1 bis P8 aus dem Magjack Datenblatt
von oben.
Für diejenigen die stattdessen Buchse&Übertrager nutzen empfehle ich
das ENC Datenblatt Seite 9...
Hallo Nik,
gefällt mir sehr gut. Ich wollte schon länger den Enc verwenden, habe
auch mittlerweile auch ein paar zu hause, aber mir fehlen noch die
Magjacks. Farnell liefert momentan nicht.
Ein paar Fragen hätte ich da:
Welche Spule hast du für L1 verwendet?
Verwendest du die LEDs (siehe Schaltplan) gar nicht? Der Magjack hat
doch welche.
Gruß Elektrikser
Ja eigentlich wollte ich das Magjack als Symbol benutzen, dann hätte ich
auch die Leds angeschlossen. Nur die Magjack Lib hat isch total seltsam
verhalten..naja oder ich habs einfach nicht hinbekommen wie ichs
hinbekommen wollte :)
Die Leds habe ich dennoch angeschlossen, 27k kommt gut hin für die
grünen. Für L1 hab ich zum Test vorerst einfach direkt nen Draht
genommen, nun läuft das ganze aber auf 2 Schaltungen ohne die Spule
nach 2 Wochen immer noch, da frage ich mich obs das Geld wert ist, mir
eine an zu schaffen. Aber 'korrekt' wäre es schon. Die Parameter für
L1 habe ich allerdings direkt aus dem ENC Datenblatt, dort steht leider
auch nicht mehr ausser rated for at least 100mA.
Nik
Hallo Nik,
hast du dich an TCP schon herangetraut?
Ich kämpfe immer noch mit Bauteilproblemen.
Die Magjacks habe ich gestern erhalten, aber mir fehlt noch der
25MHz-Quarz (ist zwar bestellt, aber das dauert...). Die restlichen
Bauteile, die ich für meinen Versuch brauche, hätte ich zusammen. Einen
Quarzoszillator mit 25Mhz könnte ich ausschlachten, aber dann fehlt mir
wieder ein IC, wie z.B 74LVX32D, mit dem ich das Oszillatorsignal
aufbereiten könnte. Ein Quarzoszillator will 5V Versorgung haben und
der Enc28J60 3,3V-Taktsignal oder eine Quarz-Kondensatorschaltung.
Also heisst es immer noch: viel Geduld und warten...
Gruß Elektrikser
Ach ja, noch zwei Sachen:
1. Der R1 soll laut den Erratas 2,7k sein statt den 2k. Gibt es da
keine Probleme?
2. Für die Leds 27k? Ist das nicht ein bißchen hoch? ;-)
Ach die Magjacks :-( Ich musste auch erst 2 Wochen auf die Dinger warten
...
1) Ich weiss ehrlich gesagt nicht, welche Revision ich von dem Enc
habe,
bei mir hats mit 2k allerdings gleich geklappt, ich werd mal die
Rev nummer auslesen, dann kann ich Bescheid geben obs trotz dem Errata
funzt, oder ob ich einfach die Version habe, bei der mit 2k alles glatt
läuft. Aber ich verwende sogar für die 50 Ohm wiederstände welche mit 47
ohm und 5% Toleranz und keine Spule, klappt aber dennoch
super(vielleicht habe ich einfach Glück :-) )
2) Ähhh, da sollte zwar schon 27 stehen, aber ohne k .. ;)
Zu Tcp: Leider ist wieder Schule :( nächste Woche wird ein ziemlicher
Stress, aber wenn nächstes WE schlechtes Wetter ist(dann hätte ich
Zeit) dann fange ich mal an. Ich habe zwar auch nun Zeit, aber ich
glaube sich da für eine Stunde hin zu setzen und zu erwarten, dass was
gescheites dabei raus kommt, daraus wird nichts, ich brauche mehr Zeit.
Also schlage ich es mir lieber gleich aus dem Kopf nun zu beginnen :-X
Nik
Zu 1.
Es steht in beiden Erratas die 2,7k drin. Aber wenn es funktioniert,
ist es doch gut.
Bei mir wird es auch erst im Juli wieder ruhiger (habe im Juni meine
Abschlußprüfung Teilzeit-Technikerschule und nebenbei gehe ich noch in
die Arbeit).
Aber da ich ja die Bauteile auch noch nicht habe, werde ich auch
erstmal schieben.
Hi Nik,
Ich finde deine Schaltung auch prima. Für den Anfang einfach
aufzubauen. Interessanter ist die Software, die gerne verstehen möchte.
Leider habe ich ein Problem mit dienen Quellen.
Wenn ich bei WinAVR auf "Make All" gehe, dann beginnt im
Outpot-Fenster eine Endlosschleife. Er versucht ständig die Quellen zu
compilieren. Abbruch ist dann nur Ctrl-Shift-K möglich. Sonst geht
nichts. Ich benutze WinAVR "v2.0.6.1 -ella".
Gruß und Danke
Guido
WinAvr20050214 scheint ein Problem damit zu haben. Er braucht unheimlich
lang, bis er es compiliert. Bei mir macht er es aber.
WinAvr20060125 hat dieses Problem nicht. Compilieren geht da ohne
Probleme. Allerdings erhalte ich ein paar Warnungen:
main.c:53: Warnung: Verarbeiten des Argumentes 1 von
»nicSetMacAddress« streicht Qualifizierer von Zeiger-Zieltypen
stack.c: In function `ip':
stack.c:87: Warnung: Zuweisung von inkompatiblem Zeigertyp
stack.c: In function `arp':
stack.c:107: Warnung: Zuweisung von inkompatiblem Zeigertyp
stack.c: In function `icmp':
stack.c:130: Warnung: Zuweisung von inkompatiblem Zeigertyp
stack.c: In function `udp':
stack.c:148: Warnung: Zuweisung von inkompatiblem Zeigertyp
WinAvr20060421 habe ich noch nicht getestet.
Gruß Elektrikser
Hi alle zusammen,
bin gerade mit dem ENC28 beschäftigt und habe eine Frage.
Ich versuche gerade, die LED's zum blinken zu bekommen. Habe aber
keinen Erfolg beim beschreiben des PhyRegAdr-Registers. Alle Register
sind gut auslesbar, aber nach beschreiben dieses Registers rehalte ich
immer nur den Wert 0x0 (iwe nach Reset) zurück. Gibt's da noch ein
Bit, das ich setzen muss, um es beschreiben zu können?
Was muss alles initialisert werden, um nur die LED's blinken zu
lassen?
Danke für die Hilfe.
Hallo,
eigentlich aollte das kein problem sein, ick lasse meine LEDs blinken
mit den befehl
enc28j60PhyWrite(0x14,0x0778);
Danach blinken beide LEDs mit einen stretching von etwas über 100ms
...
CA
Hi, sorry das es so lange gedauert hat, hab schon lange nicht mehr in
der Codesammlung vorbeigeschaut...
@elektrikser
also die Warnings bekomme ich auch, allerdings dauert es bei mir nur
ein paar sekunden bis fertig compiliert ist. Allerdings stammt meine
Version von avrgcc glaube ich noch aus dem nicht-winavr zeitalter, ich
hab pnotepad und gcc einzeln installiert, der GCC ansich ist jedenfalls
version : avr-gcc (GCC) 3.4.3
Die Warnings kann ich mir immer noch nicht erklären
stack.c: In function `ip':
stack.c:87: Warnung: Zuweisung von inkompatiblem Zeigertyp
Dieser Fehler tritt zum Beispiel in dieser Zeile auf:
ip = (struct IP_Header *)&buff[24];
Weshalb es dieses Warning gibt verstehe ich bis heute nicht, es
funktioniert nämlich trozdem so wie es soll :-(.
@Christoph
Gern geschehen :-)
@Michael
Wie man den ENC ohne die procyon lib anspricht, aber vielleicht kannst
du dir ja mal die Source von deren Files anschauen, dann klärt sich
dein problem vielleicht ;-)
http://members.home.nl/jmnieuwkamp1/AVRlib/docs/html/enc28j60_8c-source.html
so ich hab mir nun mal die neuste winavr (WinAvr20060421 hoffe ich)
runter geladen, die Warnings immer noch dieselben, aber funktionieren
tuts dennoch ;) Aber vielleicht kann mich ja jemand aufklären was ich
denn noch nicht so perfekt mache, dass es dem Compiler nicht gefällt ?
Nik
Ich bins mal wieder, habe noch entdeckt, dass ich im schaltplan 100
anstatt 10nF geschrieben hatte, Updates(so auch den korrigierten
Schaltplan) gibts ab jetzt auf meiner website:
http://www.nikbamert.com/index.php?seite=elektronik&subsite=udp
Nik
P.S. Bitte mit Firefox anschaun, im IE siehts nicht ganz so toll
aus...versuch ich noch zu verbessern..;)
Hallo,
toll das du noch dran bist, mich würde mal interessieren wie du den
IP-Stack gelöst hast. Ich habe inzwischen einen eigenen Stack gebastelt
der auch geht, mit TCP Unterstützung und auch für mehrere Verbindungen
gleichzeitig. Wäre toll wenn wir uns da mal austauschen könnten.
Hi Dirk - meinst du mit IP-Stack nur den Teil der den IP header macht
oder was genau? Sieht ja aus als ob du viel weiter bist als ich, das
TCP würde mich natürlich auch interessieren, hatte bis jetzt nämlich
keine Zeit dafür. Was mir aber wirklich Probleme bereitet sind die Syn
/ Acks, wie genau berechnen und hin und her (aus dem Packet raus und
wieder reinschreiben) mit einem Struct gehts ja nicht, da sie im packet
nicht so drinn stehen, wie sie der AVR abspeichert (-> MSB & LSB
vertauscht)
Ansonsten können wir uns auch gerne über email oder icq/msn weiter
unterhalten, sag mir einfach Bescheid.
Mein eigentliches Ziel ist es, einen kleinen Webserver auf mega168
Basis
zu 'erschaffen'. Erschaffen deshalb, weil das Ding ja bloss 1kb sram
hat und es somit nicht gerade ein leichtes sein wird den Code so
anzupassen, dass es geht. Aber ich bein eigentlich ziemlich
zuversichtlich, dass es irgendwie klappt. Die Tcp packete und die
beinhaltenden HTTP Requests sind bei IE und Firefox < 768
bytes(natürlich nur solange man keine kilometer lange URL hat)
Http request empfangen, filename zwischenspeichern, buffer löschen,
ersten sektor auslesen, neues tcp packet machen ...usw. :-) Vielleicht
klappts ja irgendwie. Wegen der Codegrösse weiss ich natürlich noch
nicht so bescheid - wie gross wird bei dir die ganze TCP Unterstützung?
Im Moment bin ich sozusagen am kleinen Bruder von dem geplanten
Serverchen. mega8, 2x8 Display, rotary encoder und sd karte.
Von der Sd karte liest sich der mega8 aus einem xml strukturierten file
die IP raus(dient als settings datei). Ansonsten beantwortet das
Kistchen vorerst aber nur Pings und verarbeitet UDP Paketchen. Man kann
zusätzlich per Rotaryencoder durch ein kleines Menü blättern. Das macht
insgesamt 5228 bytes, bleiben noch 10kb für TCP...vielleicht reichts ja
dann :P
Nik
Hallo,
ick meinte den ganzen Stack, also ethernet, IP, arp, udp ud tcp, also
eigentlich alles :-). ick bei mir habe bis jetzt Ethernet, IP, icmp,
arp und tcp eingebaut. Codegröße ist 7kb. Der RAM-verbrauch richtet
sich nach den einstellungen, ich habe das ganze schon auf einen atmega8
probiert. Mit einen kleinen Webserver komme ick so auf 7,5kb. Der
TCP-stack ist socketbasiert. Es können gleichzeit 4 TCP-verbindungen
geöffnet werden ( ist einstallbar ). Das ganze ist ein bischen
multithreadingfähig bei richtiger programmierung, da die kommunikation
über die sockets abläuft. Das arbeiten mit verbindungen geht dadurch
recht einfach von statten.
1. Port auf den gelauscht werden soll einstellen, man bekommt eine
SOCKET-nummer zurück
2. nachauen ob eine Verbindung auf diesen port/socket rein kam
3. schaun ob daten auf diesen socket im buffer liegen
4. buffer auslesen und verarbeiten
5. evtl. daten über dieses SOCKET zurück senden
6. Socket schließen
so lassen sich recht einfach kleine dienste programmieren. Zur zeit bin
ick mal wieder dabei den tcp-code umzuschreiben, da es ab und zu
probleme mit den ganzen ACKs gibt. Die ganzen SEQ und ACK nummer
speicher ich mit einer umwandelfunktion in einer SOCKET-Struct weg,
damit der avr damit rechnen kann. in diesen struct stehen auch alle
wichigen sachen zur verbindung an sich, damit kann man die TCP-packete
bauen zum versenden, nimmt pro socket etwa 28 byte weg, aber das
braucht man schon für ein bischen komfort.
so, jetzt erst al genug ...
Hi,
das klingt ja echt genial :P So komfortabel geht es bei mir leider
(noch...?) nicht:-(
Aber übersichtlich ist es meiner Meinung nach dennoch (siehe main.c in
meinem code)
Ich prüfe kontinuierlich auf neue Pakete, ist eins da, wird mit einer
if Abfrage festgestellt, um was für ein paket es sich handelt und wird
dementsprechend beantwortet(arp,icmp), oder einfach ausgewertet. Um die
Pakete zu beantworten reicht ein einfacher Befehl. Bei Udp Paketen lese
ich einfach die Daten direkt aus bzw vergleiche Sie mit einem Wert
("lighton" o.ä.). Dies funktioniert dann mit Strings. Um darauf eine
Antwort zu senden, kann man dann in den Datenbereich des UDP Pakets (ab
byte 42 glaube ich) schreiben und per
udp(&buff,reine_daten_laenge_in_bytes); die Antwort abschicken. &buff
ist dabei einfach ein Pointer auf den Anfang des Pakets.
Ist zwar nicht soo komfortabel, dafür braucht es aber auch nur einen
kleinen buffer für die Pakete(falls man nur icmp arp und KLEINE udp
packete verwendet sollten auch 256bytes reichen) - wird sich bei TCP
leider ändern, das mit den Sockets oder einer vereinfachten Form davon
braucht schliesslich einfach Platz. Ports, verbindungszustand,
ack/syn...
Das wäre dann auch schon alles, tcp hinkt noch hinterher, da ich mir
nicht sicher bin ob denn überhaupt eine Steuerung über den Browser
brauche und mir bis jetzt die Zeit ein bisschen gefehlt hat...Zudem ist
für reine Datenübertragung z.B. bei meinem Harddisk Mp3 Player Udp evt.
besser geeignet, da auf dem kleinen Avr damit höhere Geschwindigkeiten
möglich sind. Bei mir läuft das Gerät im Home Netzwerk, die Chance ein
Paket zu verlieren ist also ziemlich gering. Der Nachteil dabei ist
einfach, dass es auf dem sendenden Pc(sendet die Songs) ein spezielles
Programm braucht...geschafft habe ich damit bereits 250kbyte/s inkl
schreiben auf die HD und 270kbyte/sec, wenn ich die empfangenen Daten
jeweils einfach in einen buffer schreibe. Zudem habe ich mir einmal
einen kleinen UDP bootloader geschrieben, funktioniert auch
hervorragend, nur braucht man eben wieder ein eigenes programm dafür.
Die Codegrösse war ungefähr 2.5kb, die Geschwindigkeit lag so etwa bei
10kb/sec mit dem flashen.
Heute war übrigens die letzte Prüfung im Semester und in einer Woche
habe ich 5 Wochen Sommerferien, ich schau mal was ich da noch hinkriege
;-)
Nik
hallo,
ick kann dir ja mal meine sourcen schicken wenn du eine email an mich
sendest. bei tests habe ick ca 144kb/s per TCP/IP geschafft (Ohne
CRC-kontrolle). Ich habe den code genau aufgeteilt in die einzelnen
layer, also ethernet, ip oder arp dann icmp oder tcp. das ganze geht
bei mir im interrupt, dadurch kann man noch andere sachen machen im
hauptteil, da die kommunikation über die besagten sockets
funktioniert.
Wat studierst du denn eigentlich ? ich habe diese woche auch meine
letzten stünden für dieses semenster.
CA Dirk
Hi, sorry dass es meine email nicht anzeigt, hier ist sie
nikbamert (ät) bluewin . ch
Würde mich über deinen Source freuen, klingt perfekt, da kann ich mir
sicher etwas abschauen wenns dich nicht stört :-)
Studieren tue ich (leider) noch nicht, bin nun am Ende der vierten
Klasse im Gymnasium(Zürich).
Nik
Moin,
ich habe mir auch eine kleine Platine gestrickt, aber ich bekomme keine
Verbindung zum Hub. Das Konfigurieren des ENC28J60 klappt, ich kann die
LEDs blinken lassen. Wenn ich aber ein Netzwerkkabel anschließe
passiert nichts, die LINK-Led bleibt aus.
Was müsste denn an den TPIN/TPOUT-Pins passieren? Irgendwas das man
sinnvoll nachmessen kann (Oszilloskop ist vorhanden). Wieviel Strom
braucht die Schaltung bei euch?
Ich werde als nächstes versuchen Niks Code auf meine Hardware (mega16)
zu portieren, vielleicht hab ich ja nur etwas bei der Initialisierung
falsch gemacht...
Sebastian
Hi,
die Schaltung braucht bei mir ca. 200mA. hatte auch mal keinen Link -
Schuld war die falsche MagJack-Pinbelegung (pn 2-3-4 usw.) Die ist
anders als bei HALO.
Grüße,
MG.
Hallo,
hab mal eine Platine mit Mega32 und ENC28J60 aufgebaut und mit dem Code
von Nik angesteuert. Verbindung klappt. Leider ist nach ca. 5 bis 10
Pings ende. Jemand schon mal das gleiche Problem gehabt? komm der Sache
einfach nicht auf die schliche.
Mfg
Marco
Hallo,
hab das Problem gefunden. Ich hab einen anderen Pin als CS benutzt und
den SS Pin am avr nicht als Ausgang konfiguriert. Das war alles.
Die SPI am ENC scheint sowiso ziehmlich problematisch zu sein. Bei
kleineren Taktraten funtioniert auch nichts.
Mfg
Marco G.
Hallo,
das mit den kleineren Taktraten kann ich nicht bestätigen, ich habe
versuche bis runter auf 0.5MHz gemacht, ohne Probleme. Dieses Problem
scheind nur bei sehr alten Revisionen aufzutreten. Was als viel
problematischer anzusehen ist, ist die Abarbeitung der Packete im
Interrupt, und die Einstelltung der Puffer im ENC28j60 selber, da es
bei falscher Abarbeitung und Unterbrechung von anderen Interrupts zu
packetverlusten kommt. Solche Fehler sind nur schwer zu finden. Ich
werde die kommenden Tage mal meine Version für den ENC28j60 und
Atmega32 posten. Bis dahin erst mal ein kleiner Link, wo gerade ein
Projekt dazu entsteht. Unter
https://berlin.ccc.de/index.php/Mikrocontroller findet man einige Infos
wie Platine, Layout, Sourcen und Dokumentation. Alles befindet sich noch
im Aufbau.
MfG Dirk
Hallo Leute !
Könntet ihr mir einige "gute" Hompages empfehlen wo ich detailierte
Infos über die allg. TCP/IP header finden kann ?
Ich möchte wissen wie sich genau ein Paket zusammensetzt...
(Byte0 = MAC1, Byte1 = MAC2, ..., Byte23 = IP Type, ... )
Vielen Dank im Voraus !
Was eigentlich auch schon reichen tut ist die erklärung von wikipedia,
danach habe ick programmiert. und was man nicht vergessen wollte ist
sowas wie etherreal (jetzt wireshark) um sich die erzeugten packete
anzusehen, ethereal erklärt auch die packet sehr genau, so ds man dort
schon einiges lernen tut :-)
CA
Suuper !
Normalerweise halte ich nicht gerade viel von der wikipedia...
Aber diesmal habt ihr mich wirklich überzeugt !!!
Sehr gute Quellen bez. TCP/IP ! Nun werde ich mal ne kleine Platine mit
dem ATMega128 mit Eagle zeichnen und entwickeln lassen...dann kanns
losgehen !
Hallo,
nachdem ich lange nix mehr von mir hören lassen hab, wollte ich mal
einen kleinen überblick geben wie es um mein Projekt steht und
gleichzeitig mal wissen wie eure Projekte vorranschreiten.
Derzeitigr stand ist:
- Ethernet läuft (Interrupt- oder Pollingmode)
- Arp läuft (anfragen beantworten und stellen)
- IP läuft mit folgenden Protokollen
- ICMP (ping)
- TCP (ausgehende und eingehende Verbindungen)
- UDP (ausgehende Verbindungen)
- Netzwerkfunktionen:
- DHCP-Client
- NTP-Client (Danke an Simon für den gedankenstupser)
- HTTP-Server (derzeit nur eine statische Seite)
- Telnet (um informationen abzufragen)
Alles in allem bis jetzt ca 22kb compiliert. Die Dokumentation (per
Doxygen) ist gerade in der entwicklungphase plus Beispiele.
Auf der Todo-Liste stehen da noch sachen wie:
- weitere Hardwareunabhängigkeit erstellen
- Fat16/32 Unterstützung
- vieleicht DHCP-Server damit man kleiner Netze managen kann :-)
- MP3 steamingclient für Internetradio
- und Sachen die einen immer zwischendurch einfallen
So das wäre es erst mal. Für fragen stehe ich gerne bereit.
Jetzt wäre mal interessant wo ihr gerade alle so seid mit euern
Projekt, vielleicht kann man ja sachen untereinander austauschen oder
so.
MfG Dirk
Ich habe jetzt den µIP Stack auf meinem ATMega128 zum Laufen bekommen
und bin begeistert wie schnell das ging. Die Ladezeiten sind auch in
Ordnung. Warum schreibt hier jeder seinen eigenen Stack ? ;-)
Grüße,
Patrick
Naja, ich muss zugeben ich bin noch nicht wahnsinnig viel weiter als vor
2 Monaten :-X
Allerdings kann man nun auch über UDP Daten senden, ich sag dem nun mal
'aktiv', denn Pakete beantworten konnte man ja auch mit meinem alten
Stack schon immer, nur eben nicht selbst welche an beliebige Adressen
senden.
Bis jetzt funktioniert also:
- Ethernet (Pollingmode)
- Arp (anfragen beantworten und stellen)
- IP läuft mit folgenden Protokollen
- ICMP (ping)
- UDP (ausgehende und eingehende Verbindungen)
Ich musste einfach festellen, dass man TCP wohl nicht einfach so
schnell mal lernen kann. Ich möchte mir dafür auch die Zeit nehmen, nur
im Moment habe ich wieder Schule...was ich bräuchte wäre eine Woche
Ferien mit Regen damit ich gut arbeiten könnte... ;-)
Was ich auch noch realisiert habe, sind Sockets. Mein Ziel ist es
möglichst nahe an die 'echten' Socket Funktionen von Windows/Linux
heranzukommen, zugleich aber das ganze noch ein wenig zu vereinfachen.
Im Moment macht man zum Beispiel auf diese Weise ein neues Socket:
sckt = SocketCreate(UDP_HOST,1100,28965,"192.168.001.001");
1100 ist die lokale Portnummer, es wird noch nicht selbst nach einer
freien Portnummer gesucht, das finde ich aber sowiso überflüssig...
> Warum schreibt hier jeder seinen eigenen Stack ? ;-)
Bei mir ist es so, dass ich genau wissen möchte wie das Ganze
eigentlich so funktioniert... Zudem waren mir Stacks wie µIP zu gross,
vieles davon bräuchte ich gar nicht. Bei TCP bin ich mir immer noch
nicht wirklich sicher ob ich es überhaupt reinpacken soll, ausser
Webserver / FTP fällt mir dazu nämlich nicht gerade viel ein =X (Ich
lass mich aber natürlich gerne dazu überreden:P)
Grüsse,
Nik
> Warum schreibt hier jeder seinen eigenen Stack ? ;-)
Hm ... lernen und besser machen fällt mir nur ein :-) Das mit den
Verbindungen habe ich in etwa so wie Nik gebaut.
Verbindung zu einem Host aufbauen z.B.:
unsigned int SOCKET;
SOCKET = TCP_Connect2IP( IP, Port);
und fertig. Im SOCKET ist dann die SOCKETnummer gespeichert mit der man
dann kommuniziert. Das schaut dann so aus:
TCP_SendData( SOCKET, Datalenght, Databuffer );
das wars, empfangen geht ähnlich. Ich denke komfortabler gehts nicht
mehr :-).
Ach ja, außerdem ist es selber gemacht.
CAY
Ahoi,
ich schreibe ja auch gerne selber Sachen, aber bei der ganzen
Fragmentierung, etc. etc. war mir das dann doch etwas zuviel und ich
wollte mal den µIP Stack testen.
Das einzige was etwas doof für AVR Controller ist:
Die Webseiten werden im Ram abgelegt. Das muss ich gerade umschreiben.
Wenn das soweit läuft, ist es ein feiner Stack.
Allerdings würde ich gerne wissen wie man so einen geringen
Speicherverbrauch hinbekommt:
http://www.sics.se/~adam/uip/size.html
Da analysiere ich aber gerade herum, was denn soviel Platz benötigt.
Grüße,
Patrick
Hallo,
da hast du genau einen der kritikpunkte getroffen die so stören. Da ist
z.B. das der Stack allgemein gehalten ist für 8-bit Controller. Das der
AVR wie immer etwas anders ist :-) sind hier anpassungen nötig. Das mit
der Fragmentierung ist kann erzwingen im IP-Header, dann wird nicht mehr
Fragmetiert. Genauso kann man die Puffersize bei TCP mit übertragen und
die Maximale Transmissionsize. Da gibt es viele Schrauben wo man dran
drehen kann. Ein anderer Punkt ist z.b. das senden von Daten aus den
Flash herraus. Das beherrscht dieser Stack nicht, ist abr eine eigenart
des AVR, der knappe Speicher. Der ganze TCP/IP Stack be mir ist groesser
wegen dieser eigenarten, denn aus den RAM will man ja auch String senden
können per sprinft zum beispiel. Da gibt es etliche dinge :-). Z.b.
Beschreibt die Seite http://www.sics.se/~adam/uip/size.html nicht was
der HTTP-Server macht. Hm, einfach nur statische Seite senden denke ich
mal, da sind 1kb auch okay, aber bei komplexen sachen, braucht man mehr
speicher.
naja, genug der dinge ...
Hallo,
ich habe mir auch zum Ziel gesetzt einen kleinen Web-Server auf einen
128er zu laufen zu bekommen. Nur leider bin ich ein großer Neuling auf
dem Gebiet Ethernet. Die ganze Sache ist mir noch relativ Hoch!
Ich wurde mich freuen, wenn ihr euren Source zur Verfügung stellen
würdet.
So könnte ich was lernen bzw. mal eine andere Rangehensweise sehen und
vielleicht verstehen :-)
@Dirk:
Richtig, das mit dem Flash ist schwierig, aber wie es scheint nicht
unlösbar. Gestern habe ich schon einmal die ganzen Header (das waren
glaube ich 400 Byte) ins Flash verlagert. Jetzt muss ich nur noch die
Webseiten da reinbekommen.
Da sind momentan folgende Probleme an denen ich knabbere:
Die Daten muss ich aus dem Flash in einen Buffer laden, dieser Buffer
wird dann verschickt. Allerdings muss ich bei großen Seiten
(sizeof(PageData)>BufferLen) diese Versendung fragmentieren und danach
dann die weiteren Daten aus dem Flash laden.
Bei dem direkten RAM Zugriff geht das alles ganz easy, beim Flash
leider nur mit etwas Programmierarbeit. Außerdem muss man noch
berücksichtigen dass man ja eine Scriptsprache implementieren möchte
die dann Daten aus dem Flash läd und ihre Ergebnisse nur in diesen RAM
Buffer lädt.
Das wird interessant ;-)
@Klaus: Wenn mein Code Stable ist kann ich dir das wohl mal zukommen
lassen. Ansonsten brauchst du dir nur den uIP Stack runterladen und
alle Errors die beim compilieren auftauchen anpassen(das sind meistens
nur falsche Pfade zu den Header Dateien, je nachdem wie man diese Files
nutzt).
Grüße,
Patrick
Hallo Werner,
danke für den Tipp, prinzipiell ist das ja eine gute Idee. Wenn
allerdings eine Scriptsprache aufgesetzt werden soll müssen die
Ergebnisse des Skripts ja irgendwo gelagert werden. Dementsprechend
müsste man die Funktion so erweitern, dass z.B. ein "<?ms echo
"HALLO";?>" nur als "HALLO" ausgegeben wird. µIP lädt die Seite
soweit ich das mitbekomme habe in den RAM, führt dann seinen Script
Parser aus, welcher die Daten direkt im RAM ändert (Das muss ich aber
nochmal nachlesen).
Ich hoffe ich war nicht vollkommen unverständlich ;-)
Grüße,
Patrick
Hallo,
ich habe für jeden fall eine eigene Routine geschrieben. Damit ich ich
auch bei der Namengebung bleibe die beim AVR-GCC üblich ist.
TCP_SendBuffer( ....
TCP_SendBuffer_P( ....
u.s.w. ... ich denke mal das damit mehr leute klar kommen, da das
eindeutiger ist. Aber das ist geschmackssache.
Geschafft!
Der Stack ist soweit modifiziert dass Seiten aus dem Flash gelesen
werden.
@Dirk: Ich werde wohl nachher auch in send_file_P und send_file
unterscheiden. So kann man Files auch aus dem RAM aufrufen.
Grüße
Ich habe die "Filesystem" Funktionalität von uIP übernommen.
Das waren einfach nur Arrays(im RAM) mit den einzelnen Zeichen als
Hex.
Zum Indezieren habe ich eine struct welche mir für jeden Pfad das
richtige Array liefert.
quasi:
struct pages{
char *pathname;
int *pt_to_data;
};
Grüße,
Patrick
Ahoi,
für meine Zwecke soll der Webserver einfach nur so klein wie möglich
sein. Platz/Geld für eine SD-Card oder ähnliches ist nicht da.
Dementsprechend sollen die Files einfach nur im Flash liegen mit einer
schnellen Zugriffsmöglichkeit (ohne viel Verwaltungsoverhead).
Grüße,
Patrick
Weil die Frage oben schon aufgetaucht ist.
"Wieso schreibt hier jeder seinen eigenen Stack?". Ich würde mich
gern an einer Applikation beteiligen, aber dazu muss ein regelmäßiger
Upload gewährleistet sein ;-) Also ich wäre dankbar, für aktuelle
Sourcen ;-)
Hallo Thomas,
soweit ich das gesehen habe gibt es mehrere Stacks die vom Prinzip her
laufen. Interessant wäre hier mal ein (ordentlicher) Webserver für
Mikrocontroller. Da könnte man mal dran arbeiten.
Grüße,
Patrick
@Thomas:
Beim guten und sorgfältigen lesen dieses Threads sollte eigentlich
deine Frage beantwortet sein. Ich zumindest habe ein SVN eingerichtet
das man jeden Tag updaten kann ud welches ich fast jeden Tag update.
Also genau lesen und dann fragen. Aber Ich denke auch so einfach den
Stack von anderen zu benutzten ist eh nicht so toll wenn man ihn nicht
versteht, und dann auch noch mal eben nebenbei erwähnen, um nicht zu
sagen sich drüber zu beschweren, das keiner seinen Source postet finde
ich schon, sagen wir "blä".
MfG Dirk
mmh, beschweren wollte ich mich nicht! Ich habe deine Posts gelesen und
keinen Hinweis auf einen SVN gefunden...
Bitte verstehe meinen ersten Kommentar nicht falsch! Sicherlich lernt
man beim "selber schreiben" mehr, aber wie oben von anderen schon
gefragt "warum das Rad neu erfinden?". Ich würde mich viel lieber mit
einem Web-Server beschäftigen - vorallem wenn Teile vom Stack schon
fertig sind - so dass man "gemeinsam vorwärts kommt".
Schöner Thread. Ich habe keinerlei Ahhnung, was SVN ist. Wie komme ich
denn an die Quellcodes?!? (Allgemeinverständlich?).
Ich würde mich sehr über ein paar Informationen freuen.
Viele Grüße
Simon
SVN ist eine Versionsmanager Software, genannt Subversion. Die ist
eigentlich für Linux, ich denk mal das solltest du auch für Windows
finden. Damit kannst du dann die Files saugen wie beschrieben. Schön
ist wenn du auch gleich noch doxygen hast, damit kannst du die Doku die
in den C-Files sind erzeugen.
MfG Dirk
Ich habe den ganzen letzten Abend versucht in das SVN reinzukommen.
Fakt, ich komme nicht mehr rein - das Zertifikat ist anscheinend
abgelaufen (zumindest wird mir das gemeldet). Auf andere SVN's des CCC
komme ich drauf, wie z.B. CNC-Fräse ;-)Für ein paar Tipps wäre ich noch
sehr dankbar.
hm ... ich dachte die liegen im gleichen SVN. Ich werde mir das mal
ansehen. Wenn nicht schicke mir mal ne email, ud dann schicke ich dir
den aktuellen stand.
MfG Dirk
So, im Anhang die aktuellen sourcen Revision 60 von heute morgen :-).
Kann sein das unter Windows noch einige sachen im makefile angepasst
werden muessen, sollt aber nicht das problem darstellen. Im verzeichnis
html\main.html ist die doku zu finden, die ist aber noch nicht fertig,
weil ich erst letzte woche damit angefangen habe.
Der Source sollte so compilierbar sein, zumindest war das heute noch.
Default ist IRQ-Betrieb bei dem Enthernet-chip. DHCP und NTP ist
eingeschaltet und kann in main.c verändert werden.
Viel Spaß
Hi. Sorry for English, but I don't know Deutch.
I tried to build device mega8+enc28j60, but I can't do it work. After
power up ENC28J60 looks like powered 0 CLKOUT ping begins generating
6.4Mhz. BUT! I don't reply in SPI commands from mega8. I tried
diferent SPI speeds (from 500kHz to 10 MHz). What I can do wrong?
Hallo,
I hope I understand your problem. The CLKOUT is not an signal from the
SPI-Bus, it is a divided clocksignal from the external oscilator at the
ENC28J60. The SPI speeds makes by the ATmega8 and can be setup by the
SPI-prescaler. The wireshematic from the atmega8 to the ENC28J60 is:
ATmega8 <-> ENC28J60
SCK -> SCK
MISO <- SO
MOSI -> SI
SS -> CS (chip select)
I hope, I can help you.
No. You don't understand my problem. I see to CLKOUT as signal that
EN28J60 is powered up (by osciloscope). I know what is SPI and how it
work. But in this case it now work. Data from mega8 out to ENC28J60,
but ENC don't reply anything.
Hello Spider,
is your ENC28J60 able to build up a correct link? Your Link LED should
go on when you connect a Ethernet Cable (with a PC oder Switch behind),
even standalone without a microcontroller at the SPI Lines.
Greetings
P.s. Please post your schematics
Hello,
have connect ChipSelect correct ? Use the right config for the
datadirection ( DDR-register ) of your pinconfiguration ? Have the
correct wireschematic of the spi-bus like "natan" in prev post ? Or
post your schematics, then we can help you better.
CU
Hallo,
da bin ich wieder. Ich habe die letzten 2 Tage damit verbraucht Fehler
zu finden und suchen im TCP/IP-Stack, habe auch einige gefunden. Und
auch Fehler vom ENC28J60. Ich habe jetzt Revisionsabhängig Bugfixes
eingebaut damit der ENC28J60 ungestört seinen Dienst verrichten kann.
Ich werde heute abend, wenn ich es schaffe, den neuen Code mal Posten
für die nicht SVN-Leute. Jetzt läuft der Code richtig stabil und
überlebt auch Portscans :-), ich denke mal das sagt alles. Bis heute
Abend.
MfG Dirk
Zwecks SVN anbei ein Screenshot. Ich kann zwar dann auf "Fortsetzen"
klicken, lande aber dann letztendlich auf der "welcome to trac"
Seite.
Wäre super, wenn Du bei deinem Code auch wieder Doku anhängst. Freue
mich schon darauf!
Beste Grüße und vielen Dank im vorraus
Thomas
Habe schon versucht mich drum zu kümmern das das Zert wieder gültig ist,
aber habe leider keine root-rechte auf der Kiste. Die Doku die letztens
mit bei war wird aus den Sourcen gebaut per Doxygen, ein blick auf
diese Software lohnt sich auf jeden fall. Wenn andere Leute auch an den
Sourcen basteln, kann man so nebenbei auch die doku machen und alle
wissen wieder bescheid, sehr schick das Tool.
Ich lasse gerade einen Stresstest auf den TCP/IP-Stack los, um fehler
zu finden, aber bis jetzt schlägt der sich recht gut. Ich will
diese/nächste Woche dann noch ein paar Optimierungen vornehmen was die
Codegröße angeht, 21Kb für TCP/IP/UDP/ARP/DHCP/NTP/TELNET/HTTP ist
etwas zu groß, das kann kleiner werden :-).
I make up my ENC28J60 device to work. Now Link is lighting and SPI bus
is work. But I can't Send/Recive EthernetII packet. Can any one make
very SMALL test programm to send packet from mega8 to broadcast
(EthernetII+ARP for example)?
Hi,
take the programm from dirk, (post from 05.09.2006 09:53).
with a small modify you can send arp packages; create a loop and use
the "arp" function. take a look at main.c; it is selfexplanatory.
So, anbei die Rev66.
Verbesserungen?
Hm, eine ganze menge, hauptsächlich zur stabilität würde ick mal sagen.
Der TCP-Satck arbeitet jetzt stabil ( Hat letzt nacht über 17000
anfragen mit gemacht :-) ). Ein paar bugfixes im ENC28j60 modul
REVID-abhängig. Und hier und da ein bischen gebastelt. Mal schaun wenn
ich dieses WE zeit habe werde ick mal die Doku weiter machen und ein
bischen aufräumen. Viel Spaß mit der Software.
CA Dirk
Has anybosy know how to make FULLDUPLEX link status?
I tried to do:
enc28j60Write(MACON3, MACON3_FULDPX);
enc28j60Write(PHCON1, PHCON1_PDPXMD);
but it has not effect :(
And on more question.
How to make "UDP-Echo"?
I tried to make loop with next code:
unsigned char * UDPCtrlbuffer = NULL;
UDPCtrlbuffer = (unsigned char*) __builtin_alloca (( size_t )
UDPCtrl_PACKET_LENGTH );
UDP_socket = UDP_RegisterSocket( 0xffffffff , 1024 ,
UDPCtrl_PACKET_LENGTH , UDPCtrlbuffer);
while (1) {
if ( UDP_GetSocketState( UDP_socket ) == UDP_SOCKET_BUSY ) {
unsigned char buff_len=UDP_GetByteInBuffer ( UDP_socket );
if (bit_is_set(PORTB,PB0)) PORTB &= ~_BV(PB0); else PORTB |=
_BV(PB0);
UDP_SendPacket( UDP_socket, UDPCtrl_PACKET_LENGTH, UDPCtrlbuffer);
UDP_FreeBuffer( UDP_socket );
}
but on Host Computer I recive garbage in packet body.
But if I make so:
UDP_SendPacket( UDP_socket, 9, "Some Text");
All work fine.
hi dirk, du machst da ja gewaltig schnell vorwärts ;) Da bin ich ja noch
weeeeiiit davon entfernt... Naja, was ich fragen möchte, ob ich deine
enc28j60.c so übernehmen kann + eine notiz im header wie zum beispiel
"modified by Dirk Broßwick". Dann läuft mein Code vielleicht ein
wenig stabiler und ich kann mir dann wenigstens sicher sein, dass es
nicht mehr an irgendwelchen mangelnden Errata Implementierungen liegt.
Ich hatte nämlich ziemliche Probleme die ja sehr kurz und knapp
beschriebenen Erratas umzusetzen von daher wäre es schon cool wenn ich
mir da bei dir was abschauen könnte ;)
Nik
Kannst du benutzten, dafür sind die ja da, ich hatte auch einiges zu tun
den fehler bei den Erratas zu suchen. Ich hatte immer den Fehler das
irgntwann nix mehr ging, und hatte einfach den grund nicht gefunden,
bis ich feststellte das der Controller alles machte was er sollte und
der Ethernetchip sich aufgehangen hat. Alleine der Bug mit der
Speicheraufteilung, und wenn der Packetzeiger auf eine
überlappende/ungrade Adresse liegt. hui. Aber so sollte es gehen, denke
mal das es so okay ist wenn ich den REVID abfrage und speichere um sie
beim Packtehandling wieder zu benutzen.
Kleiner tip noch, wenn du irgentwas mit Netzwerk machst, schalte das
Empfangen ab, der haut einfach rein und man findet diesen "Interrupt
fehler" nicht.
Viel Spaß.
@Spider84.
The problem of listen UDP is, the source-port from the client-computer
is not know before the UDP-packet was recieve. The listen socket must
consider this.
abo is a pseudo-code for subscribe this thread, you can use it with
the "Email"-field.
So, eine neue Version steht an :-). Die Revision 79 der Software.
Wie immer einige kleinigkeiten und jetzt Unterstützung für
UDP_ListenOnPort ( An example find in apps/udp-echo.c for a
UDP-Echoserver on UDP-Port 7 ). Als Beispiel ist ein UDP-EchoServer
implementiert auf Port 7 alles zurück sendet was kleiner 128-byte ist.
Wie immer viel spaß.
CA Dirk
Hallo,
ich bins schon wieder. Habe mal wieder eine neue Revision fertig. Die
Revision 84 ist es. Ein Bug beim Interrupthandling wurde behoben und
einige kleine Geschwindigkeitsoptimiereungen. TCP ist ein bischen
kleiner geworden und stabiler.
Unter http://www.neo-guerillaz.de:82 kann man einen kleinen http-server
sehen, nix besonderes, aber es geht.
viel Spaß.
Naja, wen du den sourcecode oder teile davon verwenden tust in einem
projekt, dann muss dieser auch unter GPL gestellt werden. In
deutschland wurde vor einigen tagen auch die gültigkeit der GPL
richterlich bestätigt, also achtung bei der verwendung.
Wollte nochmal nachfragen ob der eine oder andere Probleme mit der
Revision 84 hat ? Weil ich eine Rückmeldung bekommen habe das bei einem
die Rev79 geht und die Rev84 nicht ... also bitte mal ein bischen
Rückmeldung, und wenn möglich mal ein paar Daten über das benutzte
System (AVR-Typ) und die anbindung des ENC28j60 (IRQ/POLL).
THX
Also ich verwende einen Mega32 und eine ziemlich "alte" Revision vom
ENC, und habe z.b. bei einem Ping-Versuch Paketverlust von ca 80%. Ob
es tatsächlich am ENC liegt kann ich aber nicht 100%ig bestätigen, da
ich keine "neue, korrekte" Version vom ENC hab.
IRQ/POLL, egal, ist beidesmal das selbe.
Wenn ich Zeit finde und irgendwo versandkostensparend an einen neuen
ENC komme, werde ich das ganze nochmal testen und eine Rückmeldung
abgeben.
Ansonsten: Bleib dran, dein Projekt ist es absolut wert :)
Ich benutzte auch eine alte Version des ENC28j60, die Revision 0x02,
daran denke mal sollte es icht liegen. Aber es wäre mal schön wenn einr
was zur Revision84 sgen könnte.
Hi
ich bekomme die Rev84 nicht ans laufen, wobei ich auch sehr wild
verschiedene Apps rausgenommen habe (z.B. Telnet).
Problem ist bei mir, dass ich im Moment nur einen ATmega8 zur Verfügung
habe, und dieser das komplette Programm nicht schluckt. Etwas gekürzt
passt es; der ENC wird noch initialisiert, dann kommt aber nichts mehr
durch (PING geht gar nicht -> vorherige Version jedoch immer 100%).
Morgen sollte ich einen ATMega32 erhalten, mit dem Teste ich dann
nochmals.
Beste Grüße
@Thomas
Ich denke mal der Stack/RAM wird zu klein sein ... versuche mal in
hardware/enc28j60.h die größe ( MAX_FRAMELEN ) für die Ethernetframe zu
verkleinern auf 256 oder 128 byte, dann sollte ping gehen, aber der
atmega8 ist ja an sich schon zu klein für dn TCP-Stack denke ich mal
...
CA Dirk
Hi
habe mir heut bei bastelarbeiten meinen ENC28J60 geschossen. Ein neues
Sample ( ;-) ) ist soeben bestellt und sollte die Woche dann ankommen -
ich meld mich wieder, sobald ich die Hardware wieder am laufen habe.
Beste Grüße
Thomas
abo
so weit ich weiß habt ihr anfangs eine modifizierte software version
von ulrich r. benutzt, die ja auf rtl8019 und ne2000 ausgelegt war,...
gibt es jetzt große unterschiede wie man die register anspricht???
Eigentlich haben wir/ich nicht wirklich eine modifizierte version
benutzt von ulrich .r. Der ENC28j60 hat ein komplett anderes
hardwareinterface als der rtl8019 oder eine ne2000. Demzufolge sind die
Unterschiede doch schön etwas größer als "nur" Register anpassen. Ein
blick in die Sourcen sollte das klar stellen. Der Enc28j60 wird per
SPI, also seriell, und die beiden anderen werden parallel angesteuert.
Zum einen vereinfacht sich so der zugriff und man verbraucht weniger
I/O-Ports, der nachteil ist das die geschwindigkeit ein bischen leiden
tut, da parallel ja schneller ist.
ca Dirk
naja, da ist nicht wirklich software benutzten was rtl8019 und ne2000
angeht :-) die Checksummenberechnung benutzte ich auch in abgeänderter
Form. aber der rest ist selber gemacht. :-)
Hallo, anbei eine neue Version. Es wurde ein kleiner Fehler im
DHCP-Client behoben, so das dieser jetzt etwas RFC-konformer laufen
tut, danke nochmal an Nico Wallmeier für den Bugfix. Sonst nur
winzigkeiten geändert :-).
CA Dirk
Hallo alle miteinander,
ich versuche zur Zeit den ENC an einem AT89S8252 via Assembler zum
laufen zu kriegen. Die Schaltung ans laufen zu kriegen war kein
problem, allerdings tue ich mich ein bisschen daten ins Lan
rauszuschicken.
Die LED´s zeigen Link und bei Broadcast auch RX an.
Via SPI kann ich auch in die Register schreiben und lesen.
Beim Start meines Programms setze ich ETXST auf 1A00 h und ETXND auf
1FFF h. ERXST setze ich auf 0000 h und ERXND auf 19FF h.
ERDPT steht auf 0001 h.
MACON1 -> TXPAUS, RXPAUS, MARXEN auf 1
MACON2 -> 00h ! Ich finde keinen Hinweis in meinem Datenblatt, ich
denke es ist Register 01h in Bank 2
MACON3 -> PADCFG0, TXCRCEN, FRMLNEN auf 1
MAMXFL -> 05eeh = 1518 Dez
MABBIPG -> 12h
MAIPGL -> 12h
MAIPGH -> 0ch
Dann Setze ich die MAC Adresse in Bank 3
und in PHCON2 -> HDLDIS auf 1
Dann habe ich mir mit Ethereal ein ARP Packet genommen, die richtige
MAC Adresse und die gewünschten IP Adressen eingesetzt und in den
TX-Buffer geschrieben.
Wenn ich jetzt ECON1 TXRTS auf 1 setze passiert nichts.
Ich sehe nicht mal die LED blinken wenn ich sie auf TX activity setze.
Hat vielleicht noch jemand eine Idee, was ich vergessen haben könnte ?
Ach ja noch eine Frage an Dirk und Nik.
Wieso benutzt ihr die Checksummenberechnung von Ulrich Radig.
Nicht das die Checksummenberechnung nicht ok wäre, aber wenn ich das
datenblatt vom ENC richtig verstanden habe, dann besitzt der ENC ja
schon eine funktion zur berechnung von CRC´s. Es würde sich ja dann
eigentlich anbieten diese Funktion zu benutzen, oder gibt es da andere
Probleme von denen ich noch nichts weiss ?
Gruß
Frank
Hallo,
das ist der Kram, den ich im Moment initialisiere (AVR-Assembler):
.equ ENC_RX_BUF = $0000
.equ ENC_RX_BUF_LEN = $1000
.equ ENC_TX_BUF = $1000
.equ ENC_MAX_FRLEN = 1518
enc_init_tab:
.db ERXSTL,low(ENC_RX_BUF) ; RX-Buffer Start
.db ERXSTH,high(ENC_RX_BUF)
.db ERXNDL,low(ENC_RX_BUF+ENC_RX_BUF_LEN-1) ; RX-Buffer End
.db ERXNDH,high(ENC_RX_BUF+ENC_RX_BUF_LEN-1)
.db ERXRDPTL,low(ENC_RX_BUF+ENC_RX_BUF_LEN-1); RX darf lesen bis...
.db ERXRDPTH,high(ENC_RX_BUF+ENC_RX_BUF_LEN-1)
.db ETXSTL,low(ENC_TX_BUF) ; TX-Buffer Start
.db ETXSTH,high(ENC_TX_BUF)
.db ECON2,(1<<ECON2_AUTOINC)
.db MACON1,(1<<MACON1_MARXEN) ; MAC Receive Enable
.db MACON3,(1<<MACON3_PADCFG2)+(1<<MACON3_PADCFG0) ; Padding 60Byte +
CRC
.db MACON4,(1<<MACON4_DEFER) ; IEEE 802.3
.db MAMXFLL,low(ENC_MAX_FRLEN) ; maximale Framelänge
.db MAMXFLH,high(ENC_MAX_FRLEN)
.db MABBIPG,$12 ; Handbuch 6.5 Seite 36
.db MAIPGL,$12 ; Handbuch 6.5 Seite 36
.db MAIPGH,$0C ; Handbuch 6.5 Seite 36
.db MAADR1,MAC_ADR5 ; MAC-Adress Byte 0
.db MAADR2,MAC_ADR4 ; Byteswap!
.db MAADR3,MAC_ADR3
.db MAADR4,MAC_ADR2
.db MAADR5,MAC_ADR1
.db MAADR6,MAC_ADR0 ; MAC-Adress Byte 6
ist zwar größtenteils auch nur von anderen abgeschrieben und mit dem
Datenblatt verglichen, geht aber so.
Beim Senden muß ETXST gesetzt sein,
EWRPT muß an den Anfang,
Control-Word muß vor die Daten (bei mir 0x00),
Danach die Daten in den TX-Buffer
ETXND setzen auf das Ende,
dann ECON1_TXRTS setzen
und warten, bis er fertig ist.
Hinter dem Writebuffer-Ende sind jetzt die 7Byte TX-Status
abholbereit.
Läuft zwar alles auf einem ATMega16 als Test-Spielerei,
ARP und ICMP (nur Ping) gehen aber, TCP-SYN/ACK inzwischen auch
halbwegs.
Der ENC berechnet die Ethernet-CRC selbstständig, für
IP/TCP/Header-Checksummen bist Du aber selbst zuständig.
Deshalb die Routine...
Kann ich Dir aber fertig nur in AVR-Assembler anbieten.
Gruß aus Berlin
Michael
Japp!
Telnet ist aber nach wie vor nicht implementiert.
Des Weiteren nutze ich das ganze im Polling-Mode.
Ich habe da noch eine Frage, Google gibt nicht wirklich was
"glasklares" her.
Ich habe da noch meine Verständnis-Probleme warum, weshalb und wieso
Pakete so aufgebaut werden, wo welche Checksum hin muss und und und.
Mit Sicherheit ist das irgendwo festgelegt, aber wo? Hast Du vielleicht
noch gute Quellen für mich?
Und dann noch zu einem Problem - meine Traffic-LED will nicht wirklich!
Gut, wenn ich nur einen PONG sende, dann ist der Traffic nicht
Weltbewegend, aber ich bekomme selbst am Oszi nicht regelmäßig eine
Flanke :-/
Ich habe als Informtionquelle "Wireshark" und wikipedia benutzt. Damit
kommt man schon sehr gut weiter. Das mit den LEDs kann man einstellen in
enc28j60.c am ende der INIT für den enc28j60. Für das Register musst du
in die Doku schaun.
MfG Dirk
@Michael
Danke erstmal für deine Hilfe, aber ich habe das ganze projekt jetzt
auf C umgestellt.
Und was soll ich sagen, es läuft. (arp request zumindest)
@All
Ich muss aber trotzdem nochmal die Frage nach der Checksummenberechnung
stellen.
Auf S. 71 im ENC Datasheet steht :
The ENC incorporates a dual purpose DMA controller...
It can also be used to calculate a 16 bit Checksum wich is compatible
with various industry standard protocols, including TCP and IP.
Hat das schon jemand probiert ?
Wenn ich das richtig verstehe, gibt man über EDMAST die Startadresse
und über EDMAND die Endadresse des zu berechnenden Speicherbereichs
an.
Dann muss wohl ECON1.CSUMEN und ECON1.DMAST gesetzt werden.
Die berechnete Checksumme steht dann in EDMACSH und EDMACSL.
Liege ich da richtig ?
Mit freundlichem Gruß
Frank
Hi,
Ich habe mir auch so ein Board zusammengebaut laut dem
Minimalschaltbild.
Ich lege nur Versorgungsspannung an. Jetzt sollte eigentlich ein Link
aufgebaut werden, wenn ich einen PC über ein gekreuztes Kabel
anschließe. Tut es leider nicht.
Jetzt habe ich eine zweite identische Platine aufgebaut. Habe die
Platinen über ein gekreuztes Kabel verbunden und der Link wird
aufgebaut.
Woran kann das liegen?
Ich benutze den MagJack SI-40138.
Ist evtl. deine Netzwerkkarte defekt? ;-)
Kurz zum Schaltplan:
Wo sitzen denn die 100nF? Diese sollten direkt am ENC sitzen! Du darfst
ruhig mehr spendieren ;-)
Die 10pF am Quarz könnten etwas gering sein; je nach Type natürlich
(22pF bei meinem Board!). Sitzt der Quarz direkt am ENC?
Sofern Du die Möglichkeit hast auf ein Oszi zurück zu greifen, so messe
mal am CLK_Out (Zur Not langt auch ein Multimeter ;-) - Du erkennst dann
sofort ob der ENC läuft oder nicht.
Der PC hängt normalerweise im Netzwerk dran.
Das mit den Kondensatoren am Quarz sollte ich mal testen, aber ich kann
wenn ich zwei Boards miteinander verbinde Packete hin und her schicken.
Frank aus Köln wrote:
> @All> Ich muss aber trotzdem nochmal die Frage nach der Checksummenberechnung> stellen.>> Auf S. 71 im ENC Datasheet steht :>> The ENC incorporates a dual purpose DMA controller...> It can also be used to calculate a 16 bit Checksum wich is compatible> with various industry standard protocols, including TCP and IP.>> Hat das schon jemand probiert ?
An sich ist das ja richtig, aber für IP-Checksummenberechnung bringt das
nix, man muss ja z.b. die IP-Pseudoheader ja noch mit einbeziehen in die
Berechnung, aber dazu sollte er im Speicher des ENC28j60 liegen, ud den
jetzt im ENC28j60 auch noch aufbauen ? Also kann man wie gesagt
vergessen, da ist man schneller wenn man es selber berechnen tut.
CA Dirk
Jup ... aber die Frage ist auch gewesen ob man das nicht im enc28j60
machen könnte. Und das ist dann schon wieder kompliziert weil man den
IP-Pseudoheader braucht um eine Checksumme einen IP-Packetes zu
berechnen.
Hallo,
ich bin zwar dabei den ENC per ARM anzusteuern aber das tut ja erstmal
nichts zu sache. Die Checksumme vom IP-Paket berechnet bei mir der ENC,
die von den UDP Paketen noch niemand (0=Checksum deaktiviert).
Allerdings ist es ja möglich, nur den Pseudo-header im uC zu berechnen
und den Rest vom Paket über den ENC laufen zu lassen. Die Addition
beider Werte müsste dann halt wieder im uC stattfinden, aber ok.
Grüße,
Clemens
Jetzt ist nur die Frage was schneller ist. Ich denke mal beim ARM ist
das keine Frage, der macht die Berechnug schneller als das
Datenschaufeln per SPI. Beim AVR denke ich mal ist das in etwa genau so.
Man sollte mal einen Wettbewerb draus machen :-).
CA Dirk
Hallo!
Ich habe ein Problem: Der DHCP-Client "rennt" in den Timeout, obwohl der
DHCP-Server läuft (mein Notebook erhält eine IP).
Und nochwas interessantes:
Nach der Initialisierung muß ich ca. 500ms warten, bis ich z.B. eine
DNS-Anfrage schicken oder die Zeit über NTP holen kann.
Hat jemand eine Idee (also hauptsächlich zum DHCP-Problem)?
Gruß
Markus
Ja, das mit den DHCP kenne ich, aber leider mangels Netze um das zu
testen ist es schwer fehler zu finden ... Bei mir geht der code so wie
er ist. Wäre schick wenn man einen Netzwerk-Mitschnitt bekommen könnte.
MfG
>Ich habe ein Problem: Der DHCP-Client "rennt" in den Timeout, obwohl der>DHCP-Server läuft (mein Notebook erhält eine IP).
Vermutlich moechte der Server einen Eintrag ins Logfile schreiben
und moechte seinerseits den DNS Namen mitloggen. Da macht er eine
Anfrage und kommt in einen Timeout. Gibts einen tcpdump?
Viele Gruesse,
Hans
Am besten Wireshark in verbindung mit einen Hub nicht Switch benutzten
und dann den Traffic mitschneiden und die Datei schicken, und wenn
möglich Debugausgaben vom DHCP-Server.
MfG
Hallo!
Habe die "Situation" nochmal durchdacht.
Leider habe ich nur einen Hardware-Switch. Daher ist leider nichts mit
Server-Log oder einem "Mitschnitt" des Protokolls, da das Notebook ja
nichts mitbekommt an einem anderen Port.
Gruß
Markus
Hallo!
Ich bin noch etwas neu in Ethernet-Technik. Eine kurze Frage:
Was ist eigentlich der "IP Stack" ?
Ist es das was Nik mit seiner .zip Datei hier veröffentlicht hat?
Ich hatte nämlich erst vor, den Lightweigth IP Stack zu benutzen:
http://www.sics.se/~adam/lwip/
Aber wenn auch der hier veröffentlichte Code dasselbe macht, würde ich
zu diesem neigen.
Hallo,
Der IP-Stack ist der Dreh- und Angelpunkt für die eingehenden und
ausgehenden Netzwerkpackete. Hier werden die Packet verarbeitet und
endsprechend reagiert. Das kann dann so aussehen das Daten an eine
Application weiter gereicht werden oder von dieser endgegengenommen. Der
Stack trennt in diesen fall die Anwendersoftware von der Hardware, der
rest fällt schon fast komplett in den Stack (man möge mir diese Aussage
verzeihen). Hier im Forum kreisen einige Stacks die aber meinst auf
bestimmte Netzwerkkontroller zugeschnitten sind. Da hilft dann die suche
weiter.
Nik und ich haben auch einen Entwickelt, zugeschnitten auf den ENC28j60.
Meinen entwickel ich noch weiter, leider nur etwas langsam, da keine
Zeit. Es gibt aber auch nette Stack wie z.b. µIP. Der aber aus meiner
und anderer Leute ansicht einige macken hat, aber zum benutzen "Out of
the Box" vollkommen okay.
CA Dirk
Hi
Mein Projekt ist es eine sehr simple Verbindung µC -> PC aufzubauen.
Zuerst einmal nur:
µC -> PC über UDP
Ich denke mal das ist das einfachste...
Dazu habe ich den Code aus dem ersten Beitrag genommen (enc_basics.zip
19,3 KB). Ich habe noch nichts am Code verändert. Beim Kompilieren kommt
nur:
Hallo nochmal...
ich wollte eine Unabhängigkeit von der existierenden Makefile. Ich habe
sie nun nicht mehr inkludiert. Es kamen einige Fehler wegen dem C99
Zeug. Habe ich behoben indem ich aus den if-Abfragen die Deklarationen
ausgelagert habe. Soweit OK. Auch war wohl der mega8515 zu klein. Habe
jetzt einen mega16 ausgekramt. Dafür das Kompil-Ergebnis:
Warnings sind nicht schön. Ziel sollte 0Errors 0Warnings sein. Oftmals,
während der entwicklung sieht man jedoch über Warnings hinweg - was Du
hier auch gern machen kannst.
wenn ich das richtig verstanden habe, ist der hier veröffentlichte Code
ein kompletter Stack?? Mehr brauche ich nicht für eine Kommunikation??
Kann ich ihn also anstelle des µIP nehmen? Denn den µIP finde ich für
den Einstieg etwas zu Umfangreich.
Bitte, noch diese eine Unklarheit zu beseitigen :-) Danke.
Hallo,
ich plane meine ENC-Platine (wenn ich denn endlich mal Zeit habe) auch
mit der o.g. Firmware zu verwenden. Da stellt sich mir jetzt die Frage,
was habt ihr als "Gegner" verwendet? Habt ihr euch UDP-Programme
geschrieben, um die Kommunikation zu starten? Ihr habt ja bestimmt nicht
gleich mit Firefox o.ä. Anfragen gestellt, sondern die UDP oder TCP erst
mal einzeln in kleinen Schritten getestet?
Ich weiss, Wireshark is ein geniales Tool, um Ethernet zu debuggen (oder
einfach mal den realen Netzwerkverkehr kennen zu lernen). Hat sich schon
mal jemand Gedanken um ein richtiges "Debug" Tool gemacht und hat dieses
vielleicht veröffentlicht? Das würde den Einstieg einfacher machen und
man muss nicht an zwei Fronten gleichzeitig kämpfen - zumal man ja an
der gleichen Front kämpfen muss...
Gruß,
Stefan.
Ich hab mir jetzt mal das Teil von Nik zum experimentieren nachgebaut.
UDP und anpingen klappt auch schon super!
Hab aber trotzdem mal eine Frage, ist es möglich mit der Hardware
(Mega8) einen kleinen http server aufzusetzen??? Er soll garkeine
großartigen funktionen haben nur z.B. "Hallo Welt" im Browser anzeigen.
Ich habe schon ein wenig mit den Sourcen von Dirk rumexperimentiert aber
bekomme das nicht vernünftig zusammengekürzt bzw. Compiliert..
Oder ist das einfach Unmöglich? (speicherproblem)
> Hat sich schon mal jemand Gedanken um ein richtiges "Debug"> Tool gemacht
Was bitteschön verstehst du unter einem "richtigen Tool"? Wo dir
Wireshark offenbar nicht richtig genug ist.
hmm,
da habe ich mich wohl falsch ausgedrückt.
Mit "richtigem Debugtool" meinte ich nicht die Netzwerkseite, sondern
ein Programm auf PC Seite, mit dem ich beliebige Pakete senden kann.
Beispielsweise: Eingabe von UDP oder TCP, Ziel-IP, Ziel-Port, Anzahl der
Datenbytes und den Inhalt der Datenbytes. Also ein einfaches Tool zur
Erzeugung von bekanntem Traffic.
Stefan
Hallo Dirk,
möchte auch einem AVR das Ethernet beibringen :-)
Habe Deinen IP-Stack hier gefunden über Umweg (CCCB) :-)
Das Projekt dort scheint von Dir zukommen?? Oder habe die
bei Dir abgeschrieben?
Nun ja, eine Frage erstmal, ich habe auch den uIP entdeckt.
Du hast geschrieben:
> Es gibt aber auch nette Stack wie z.b. µIP. Der aber aus meiner> und anderer Leute ansicht einige macken hat, aber zum benutzen "Out of> the Box" vollkommen okay.
Aus Neugier, was hat er denn Deiner Meinung nach für "Macken"?
Da ich wenig Erfahrung damit habe, kann ich aus "Leiensicht"
erstmal keine finden. Aber es würde mich interessieren.
Joachim
also ich benutze um packete zu senden ein kleines php script das geht
eigentlich recht einfach (zumindest mit udp packets)
hab aber auch nen kleines c programm geschrieben was auch gut läuft..
ist alles nicht so schwer und gibts viele beispiele im netz...
noch einfacher wenn man linux benutzt :-D
Hallo,
@Stefan & -bjoern-
Unter Linux ist oft netcat dabei - das macht so ziemlich alles, was ich
brauche (den Rest macht die Shell), vielleicht 'nen Blick wert...
root
Hallo,
im Prinzip ist der Stack ein vollständiger Ersatz, habe damit einen
Webserver, Telnetserver, NTP-Client, DHCP-Client und UDP-Echoserver
gebaut, denke mal das das als Liste reichen sollte.
CA Dirk
@Dirk,
Du hast geschrieben:
> Es gibt aber auch nette Stack wie z.b. µIP. Der aber aus meiner> und anderer Leute ansicht einige macken hat, aber zum benutzen "Out of> the Box" vollkommen okay.
Auch wenn ich Deinen Stack verwenden will (ist ja alles fertig für
the ENC28J60 :-)) , würde es mich doch interessieren, was der uIP für
"Macken" (Nachteile) haben soll oder was dort ungünstig gelöst ist?
Falls Du es hier nicht posten möchtest, dann vielleicht per PM?
Was mich auch interessieren würde, wie lange Du gebraucht hast,
um das Grundgerüst zum laufen zu bekommen, so daß z.B. Ping
funktioniert.
Danke schön
Joachim
Hallo,
.... und es funktioniert. Gleich auf Anhieb :-)
Habe den WinAVR-20070122 verwendet. Also falls
das noch nicht bekannt war, mit der Compilerversion
funktioniert es auch.
@Dirk: Klasse Projekt, hab Respekt. Danke schön
für den Source und die Mühe.
Joachim
War doch etwas zu schnell....
DHCP funktioniert nicht. Der AVR bekommt keine Adresse
und dann nimmt er die default.
Mein Router hat aber einen Eintrag in seiner Liste
mit der MAC vom AVR. Also es sieht so aus, als wenn der
AVR die Antwort nicht versteht.
Joachim
@Hans-joachim Borchers
es wäre net wenn du den AVR an einen richtigen hup nicht switch mal
ranhängen könntest und mit wireshark mal einen mitschnitt anfertigst,
dann könnte ich mir das mal ansehen, wäre net. Und das gleiche für einen
PC der mit den router funktioniert.
CA Dirk
Kann man denn schon UDP Datagramme vom AVR aus verschicken?
die funktion void udp(len, *adr) müsste doch genau dies ermöglichen...
Weiter oben hier steht dass es nicht möglich sein. Später steht, es sei
möglich.
Wo ist denn dann die aktualisierte Quellcodedatei?
LG
@Lars,
Man kann mit den Stack UDP-Packete verschicken, und auch auf eingehende
Verbindungen warten und auch Verbindungen aufbauen. Anbei die letzte
Version die es gibt. Im Verzeichnis html/index.html befindet sich die
Dokumentation zum Sourcecode, ich denke mal das sollte reichen.
MfG Dirk
Hallo,
Ich möchte mal meine Anwendung welche ich mit dem Code von Nik laufen
habe vorstellen.
Und zwar ist kann der Code von Nik ja "nur" UDP Packete beantworten. Was
aber für die meißten Anwendungen vollkommen ausreichend ist.
Als erstes habe ich ein kleines C Programm geschrieben, mit dem ich die
UDP Packets senden um empfangen konnte.
Dann habe ich Nik's Firmware etwas erweitert um 3 LED's sowie einen
Temperatur Sensor die man nun per UDP Steuern kann.
Was mich jetzt allerdings störte war, dass ich nur mit diesem extra C
Programm die Sachen abfragen konnte also habe ich ein kleines php Script
geschriebe. Da das Ganze wunderbar funktionierte, habe ich es immer mehr
erweitert. Es ist längst noch nicht fertig aber hat schon einige schicke
Funktionen, wie ich finde. Ihr könnt es ja einfach mal ausprobieren und
sagen was ihr davon haltet.
Die Firmware hänge ich mal nicht an, ich denke die ist zu trivial.
Die UDP Befehle lauten bei mir wie folgt:
- led1on -- schaltet led1 an ;-) und gibt "ok" zurück
- led1off --schaltet sie wieder aus und gibt "ok" zurück
- das Ganze für led2 und led3 nochmal
- test -- gibt nur "ok" zurück
- gettemp -- ließt die aktuelle Temperatur von einem Sensor aus und gibt
sie zurück
In dem zip Archiv ist die Datei test.php die Hauptdatei.
Der Code funktioniert leider nicht auf jedem php fähigen Webspace aber
auf meinem Uni Space läuft das ganze recht gut.
Ein kleines Manko ist auch noch das die LEDs beim Aufrufen der Seite
"gelöscht" werden weil ich noch keine status Abfrage des Ports
implementiert habe.
Um das ganze auf einem externen Server laufen zu lassen muss man seinen
Router natürlich entsprechend konfigurieren. Ich habe ihn so
konfiguriert das er auf dem port nur eine spezielle IP zulässt somit
kann man missbrauch und Hackversuche etwas einschränken, aber trotzdem
von jedem Rechner die gewollten Funktionen ausführen.
@Dirk Broßwick & @Hans-joachim Borchers
Hallo zusammen,
ich hatte bei mir auch Probleme mit dem DHCP-Client.
Ich habe das Problem mit dem mitloggen bei mir so gelöst, das ich bei
mir auf einem Windows Rechner die Software tftpd32
(http://tftpd32.jounin.net/)installiert habe.
tftpd32 ist unter anderem ein DHCP Server. Dann habe ich auf dem selben
Rechner wireshark mitlaufen lassen und schon hat man auch in einem mit
Switches verdrahteten Netzwerk die möglichkeit, "ALLE" DHCP pakete
mitzuloggen. Leider kann ich nicht mehr nachvollziehen was ich an der
DHCP Routine von Dirk geändert habe, aber es läufts zufriedenstellend.
Wenn grosser bedarf besteht dann versuche ich nochmal den code für den
DHCP client zu isolieren.
Ich arbeite hier mit einem AT89C51ED2 und MIDE mit SDCC und daher kann
ich hier nur mit einer Datei arbeiten, was die ganze Software
mittlerweile ein bisschen unüberschaubar macht.
Kennt hier villeicht jemand eine kostenlose IDE die mit mehreren Dateien
umgehen kann und SDCC unterstützt ?
Codeblocks habe ich mir schon angeschaut, ist aber merkwürdig zu
konfigurieren.
Gruß
Frank
Hallo nochmal,
ich habe jetzt mal meine routinen die DHCP betreffen, in eine Datei
gepackt.
Achtung tauscht jetzt bloss nicht Dirks dhcpc Files durch meine aus, das
funktioniert nicht.
Diese codeschnipsel sollen nur die Änderungen aufzeigen.
Der Hauptunterschied ist wohl das ich bei einem DHCP_SendDiscover den
Client_Identifier mitschicke.
Mein Netgear Router wollte mit dem ursprünglichen Code auch keine IP
vergeben.
Bei mir läuft der Code bis jetzt fehlerfrei mit 4 verschiedenen DHCP
Servern. Einige Router sind allerdings etwas störrisch, was das
freigeben einer IP adresse angeht. Da muss DHCP_GetConfig unter
umständen zweimal ausgeführt werden.
Gruß
Frank
@Frank
Danke für den Tip mit tftpd32 und den Sourcefiles.
Ich habe allerdings die Möglichkeit mit einem Hub
zu testen. Das werde ich auch tun in den nächsten
1-2 Wochen. mit tftpd32 kann ich es auch nochmal
probieren um Unterschiede zu entdecken.
Wenn ich das Problem finde, dann gebe ich auch
Dirk die Sourcen oder auch die Wireshark-Aufzeichnungen.
Zu deinem Problem mit SDCC... kann ich im Moment auch nichts
sagen. Evtl. ein Plugin für Eclipse schreiben.
Bis dann
Joachim
irgendwie ist auch was faul an der Definition der Funktion und deren
Prototyp. Der Stern ist einmal an dem Datentyp und anderes Mal am
Datenname:
Wo muss er denn nun hin?
enc28j60.c
Lars wrote:
> irgendwie ist auch was faul an der Definition der Funktion und deren> Prototyp. Der Stern ist einmal an dem Datentyp und anderes Mal am> Datenname:> Wo muss er denn nun hin?
1
unit8_t*a;
2
uint8_t*a;
3
uint8_t*a;
4
uint8_t*a;
Sind für den Compiler exakt dasselbe. Wo man den Stern hinmacht, ist ne
reine Stilfrage.
/Ernst
hallo,
ich habe eine board mit dem enc 28j60 gebaut und programmiere gerade
etwas rum.
den enc28j60 kann ich inzwischen ansteuern und arp , ip und icmp (ping)
funktionieren , mich wuerde mal interessieren welche response zeiten
andere beim ping haben (bei mir 5 - 25ms ; mit arp 40ms).
ghosty203
@ghosty203:
Wenn Du die Debug-Prints alle ausschaltest (define DEBUG),
dann sind die Zeiten sehr kurz.
Bei mir 1-2ms. Mit Debug-Prints ca. 25ms.
Ähhh ja, ich weiß jetzt nicht, ob Du den Stack von Dirk verwendest.
Da ist es so. :-)
@Dirk:
Ich habe jetzt alle Warnungen aus dem Code entfernt.
Funktioniert immer noch :-) Und ich habe ein paar merkwürdige
Dinge im DHCP-Code und DNS-Code gefunden. Im DNS auf jedenfall
einen Fehler. Bei DHCP weiß ich nicht, was der Compiler macht,
aber er spuckt eine Warnung aus und das Ergebnis kann so oder
so sein (je nachdem was der Compiler daraus macht).
Die Tage mehr dazu.
Joachim
@joachim
ich hab meinen eigenen stack programmiert, wenn ich den enc28j60 direkt
mit dem computer verbinde hab ich eine response time von 3 - 5ms . wenn
ich allerdings 4 computer und den enc28j60 an ein hub anschliesse dann
habe ich die besagten 5 -25ms.
ich benutze keinen AtMega sondern einen AT89C51ED2 und da es ein
testaufbau mit teilweise sehr langen draehten ist habe ich auch die
geschwindigkeit auf ca 1.MHz reduziert.
den ganzen aufbau und das programmieren hab ich in 2 wochen (nebenher
noch arbeiten) gemacht
ghosty203
>mich wuerde mal interessieren welche response zeiten>andere beim ping haben (bei mir 5 - 25ms ; mit arp 40ms).
Bei mir sind es ziemlich genau 0.6ms, aber ich verwende einen Atmega168
@ 20Mhz und SPI läuft bei mir mit 10Mhz...das dürfte den Unterschied
erklären :). Weshalb es bei dir mit mehr Computern am HUB langsamer
wird, kann ich mir aber nicht erklären. Ich habe zwar einen Switch, aber
dem ist es egal ob da 2 oder 8 Gerät dran sind, der ist immer gleich
schnell.
Nik
@Hans-joachim Borchers
Würde mich interessieren wo im DNS der Fehler steckt, das DNS-Modul war
eigentlich nur so ein hack, der man eben gehen sollte um ntp zu nutzen,
mehr nicht, habe da auch nicht viel Hirnschmalz rein gehangen, hatte
halt ab und zu den Effekt das es ging, und mal nicht :-).
CA Dirk
@Dirk
hallo,
hab mich mit deinen Code mal etwas näher beschäftigt, und hab ein paar
Sachen gefunden, die ich mir nicht erklären kann. vielleicht kannst du
ja etwas Licht ins Dunkel bringen.
a)warum initialisierst Du den CS des ENC28j60 als Eingang?
b)warum wird in der ISR des Timer1 ein CLI() ausgeführt und das SREG
gesichert? Das geschieht doch automatisch, oder? Oder wird diese
Prozedur auch anderweitig aufgerufen, also nicht über den
Interruptvektor?
Grüße
seacrash
@Andreas Schmidt
zu a) Stimmt, in der spi.c wird der cs/ss als eingang definiert, sollte
aber als ausgang gemacht werden, aber in der enc28j60.c wir er nach dem
spi_init korrekt als ausgang gesetzt. Werde ich mal ändern :-).
zu b) Dadurch erreicht man das alle interrupts gesperrt sind, was ganz
praktisch beim debuggen ist, kann man im prinzip raus nehmen hier, ist
bestimmt noch vom debuggen. Das SREG wird wegen dem I-Bit gesichert,
damit man nach einem ISR-durchlauf wieder den alten zustand inklusive
I-Bit hat.
CA Dirk und THX
mich würde einmal interessieren, woher ihr die Informationen habt, wie
z.B. auf ein Ping geantwortet werden muss, was passiert, wenn eine
Anforderung eingeht - wo und wann welche Checksumme gebildet werden muss
und so weiter...
Das UDP habe ich soweit noch verstanden, aber bei ICMP etc. hörts dann
wirklich auf, bzw. ich find nichts gescheites im netz.
Vielleicht hat jemand einen weiterführenden link
danke
an Dirk, Entwickler des Code
ich versuiche udp in mein Projekt aufzunehmen. ich kopierte mir deine
Funktionen aus udp.c rein. Beim Kompilieren bleibt er immer hier hängen:
Der Error:
../ethernet.c:64: error: dereferencing pointer to incomplete type
Hab rausgefunden, dass er das "IP_packet" nicht zuordnen kann. Ich
konnte es in deinem gesamten Code auch nicht finden. Hast du das
nirgends definiert?
Gibt es einen Grund, warum die IP-Header-Checksumme erst mit Null
geschrieben wird und nach setzen der IP-Adressen erneut berechnet und
geschrieben wird?
jup ... es wird erst ein IP-Pseudoheader erzeugt, und da soll laut RFC
die Checkumme mit 0 beschrieben werden, und dann mit der neuen
Checksumme beschrieben werden. Ist ein Blödes verfahren, ist aber jut in
den RFCs und wikipedia zu erlesen.
CA Dirk
Das hängt mit der Kontrolle der Packete zusammen. Wenn man die
Checksumme über das empfangene Packet macht sollte glaube 0 rauskommen
da die Cheksumme selbst mit drinne ist oder so in der Richtung. (hab bei
mir bisher die empfangene Packete immer ungeprüft verarbeitet.
Ciao
Karsten
> hab bei mir bisher die empfangene Packete immer ungeprüft verarbeitet
wollt ich auch erst, bis ich merkte, dass ein Winsock keine ungeprüften
Frames reinlässt.
Na die ACK und SEQ Nummern müssen schon passen. Ein gutes Tools zum
prüfen was gerade abgeht ist Wireshark (am besten einen Filter mit
tcp.port==80 einstelln, sonst bekommet man zuviel Müll angezeigt).
Bei der Verbindungssquenz wird die ACK=SEQ+1 genommen und eine eigene
SEQ generiert (z.b. die Ticks der Uhr). Danach wird immer hinunsher
getauscht und die Zahl der empfangenen Bytes addiert.
Ganz richtig gehts bei mir aber auch noch nicht. Z.b. muss ich außer bei
dem 10er IP Netz von meine Checksumme immer 2 abziehen. Kein Plan warum.
2 Packete verschicken hab ich auch noch nicht raus (z.b. das ACK nach
dem GET + HTML-Daten)
Karsten
Hi!
Mal was anderes: Woher weiß der ENC eigentlich, in welchem Subnet er
sich bewegt? Ich habe bisher noch in keinem Quelltext Einstellungen
dafür gefunden.
Danke.
µC-Bastler
Hallo
der ENC interessiert sich nur fuer die ziel mac-adresse. Er sollte nur
frames akzeptieren mit ziel mac-adressen , seine eigene , multicast und
broadcast.
Subnet/IP-Adresse sind ihm egal, das IP layer muss der uP verarbeiten.
Gruss
Joerg
Hallo.
Kannst du das bitte noch mal etwas näher erläutern?
Er orientiert sich nur an der MAC-Adresse? Das habe ich noch nicht
verstanden...
Gruß
µC-Bastler
Er nimmt erstmal alle Packete rein. Entweder prüft man dann im AVR ob
einem die MAC usw gefällt oder man lässt den ENC vorher schon alles
rausfiltern was man nicht braucht. (MAC, IP)
Filtern hab ich bisher noch nicht gemacht. (hab den meisten Code von
Pascal Stang und Ulrich Radig genomen und dann erweitert.
Wenn ich bisschen weiter bin veröffentlich dch dann mal meine Sourcen.
Ciao
Karsten
HI,
ich versuche mich grad selbst an dem ENC28J60.
Gibts so ne Art "Beispielpacket", dass ich senden kann um es dann
mit nem EthernetSniffer (WireShark) zu empfangen?
Einfach um zu testen ob das ganze prinzipiell geht. Ich hab
versucht nen ARP-Request Paket zu senden, konnte aber nix empfangen.
lg Daniel
ok, ich hab jetzt den code mal auf meinem atmega644 eingespielt.
Aufbau ist wie der hier im Thread gepostete. Als
Übertrager nutze ich den MagJack SI60062-f.
Registerlesen und Co. klappt - wie auch bei meinem eigenen Code.
Link LED leuchtet, RX/TX Led blinkt ab und an - wenn ich ein ping
mache blinkt es häufiger (logisch, die ARP Requests).
Aber er empfängt NIE ein Paket. Hier bleibt er dann immer hängen
1
// check if a packet has been received and buffered
Hier mal ein Bild des TX-In Pins.
So ein "Bulk" kommt immer an, wenn die LED leuchtet und wenn Ethereal
ein ARP-Request erkennt (vom PC ausgehender ARP-Request).
Wie gesagt, Software ist die Software hier aus dem Thread.
lg Daniel
Einfacher ist auf Packete zu reagieren. (ARP, ICMP/ Ping, UDP).
- ARP geht automatisch (gleiches IP Netz! z.b: 10.10.5.15+10.10.5.14)
- Ping halt über die cmd Zeile
- UDP kannste mit der ATMega IDE senden
als Anfang kann ich dir die Seite empfehlen
http://www.nikbamert.com/index.php?seite=elektronik&subsite=udp
Die Warnungen liegen wohl am Makefile. Ich hab den Code bei mir
eingebaut ohne Warnungen.
Läuft auf nem ATMega 8 direkt und lässt sich leicht an den 168er
anpassen.
Wenn du aber mehr planst, nimm einen mit mehr RAM. 1kB sind eindeuitg zu
wenig. Ein normales TCP Packet kann durchaus 1,5kB werden...
(oder halter externer S-Ram.
Ciao
Karsten
danke für die antwort,
ich kann jetzt empfangen. Allerdings sehe ich schon bei der AbsenderMac
unterschiede zwischen dem was mir Wireshark ausgibt und dem
Bufferinhalt.
Und er antwortet auch nicht auf den Ping (die erste IF-Abfrage
ob was im Buffer steht besteht er, danach die If-Abfrage auf ARP-Request
schon nicht mehr).
lg Daniel
Könnte man Buchse und Überträger nicht aus ner alten LAN Karte
extrahieren?
Ich hab bestimmt noch so 20 Stück zuhause rumliegen, frage nur: wie
identifieziert man den Überträger?
Ich habe eine Buchse und den Übertrager einer Netzwerkkarte genommen,
genauso wie auch den Quarz... Für den Übertrager den ich habe konnte man
Problemlos ein Datenblatt finden. Ansonsten muss mal halt mal Leitungen
verfolgen und schauen wie der angeschlossen ist.
@St. Gr.:
20 Karten = viele freie MACs g
Die MagJack Buchsen sind nicht so teuer und man spart sich bisschen
Löten und auf Platz. Und sieht coller aus g
Bei mir ist der Enc Krahm auf 2,5x5,5cm untergebracht mit DIL und
Streifenraster. Könnte man vielleicht sogar noch minimal reduzieren.
Manchmal hab ich das Problem, das zu viele Packete das ganze abschießen
weil der AVR nicht mehr nachkommt mit der Abarbeitung oder nach dem
Brennen noch alte Packete im ENC oder PC stehen (unsicher).
Das IPv6 sollte man schon erstmal abschalten bei Windows. Nur noch das
IPv4 TCP an lassen für den NIC.
Und ihm erstmal 15s zum eintrudeln geben bevor das erste Ping kommt.
Direkt an einer Fritzbox hab ich auch oft das Problem das dort extrem
viele Broadcasts kommen. Muss wohl am fehlenden DHCP CLient liegen.
Ciao
Karsten
Servus
folgendes Problem: der ENC sendet nur UDP, der PC empfängt diese. Die
Größe des Frames ist konstant, denn due UDP Daten sind konstant lang.
Nur eben die Daten selbst sind veränderlich (um die Sache sinnvoll zu
machen :-)
Bei jedem Senden wird also ein konstanter Overhead plus die Daten
übertragen.
Kann man via SPI auch nur die Daten schicken? Das setzt vorraus das der
Header ständig im RAM des ENC bleibt. Ich will also nur jedes Mal den
Datenbereich updaten.
Probiers doch mal. Anfang dfes Sendepackets legste halt immer auf die
gleiche Stelle. Ich denk nicht das der ENC was am Speicherinhalt macht.
Kenn mich aber mit dem Enc noch nicht so tief aus.
Ciao
Karsten
Hallo,
hat einer von euch meine Sourcen schon mal erfolgreich auf einen
ATmega644 portiert ? Irgendwie bekommen ich das nicht gebackten. Ich
habe es nur teilweise hin bekommen. ARP, ICMP und UDP gehen, aber TCP
bockt rum.
CA Dirk
@Dirk?
genauere Anhaltspunkte? Was heißt "bockt rum?"
Das kann ich mir schlicht nicht vorstellen...bei 4k Ram kann man es ja
eigentlich krachen lassen ;-)
Naja, das Problem sind anscheint die Timer und das IRQ-Handling. Ich
dachte das die eigentlich gleich sein sollten. Also dachte ich einfach
Register anpassen und ab gehts, aber denkste. Wenn ich die TCP-Dienste
abstelle geht alles ganz wunder bar(Ping etc). Aber sobald ich die
Timer/TCP ins spiel bringe kackt der nur noch rum, und ich finde das
Problem nicht wirklich. Aber ich bin soweit es auf den Timerinterrupt zu
beschränken das Problem. Scheinbar geht der nicht richtig, die Uhr geht
nicht und die Counter zählen nicht, so das sich alle Sachen die mit den
Timer zu tun haben nicht gehen wie z.B. die TCP Retransmissiontimeouts,
DHCP-Timeouts, halt überall wo der Timer drin vorkommt. Aber der
TimerIRQ wird aufgerufen, das habe ich gecheckt. Aber vielleicht habe
ich nach drei Tage auch einfach einen Knoten im Kopf :-).
CA Dirk
Servus Dirk,
der Knoten im Kopf kann schon erdrückend wirken.
wenn nix mehr hilft - > zwanzig Minuten auf www.parapluesch.de ;-) das
befreit den Geist und Du bist danach freiwillig kreativ. naja...
Timer klingen plausibel. Ich habe die programme auch haufenweise auf
diversen controllern im einsatz; oft habe ich, also wirklich oft
probleme mit uart und timern, gehabt, so dass ich die interrupts alle
nochmals überarbeitet habe; sie sind nun nicht mehr so flexibel, aber
machen keine probleme.
viel erfolg
@Thomas
Das
Problem befindet sich tätsächlich im tcp modul, obwohl ich nicht ganz
verstehe warum, auf einen Mega32 geht es wunderbar, nur auf den Mega644
nicht. Ich werde die tage, wenn es meine zeit zuläßt, das modul einfach
nochmal neu entwickeln.
CA Dirk
@Dirk
Ich hatte mir mal die Mühe gemacht, nach Absprache mit Dir, den
Code durchzugehen, so daß er ohne Warnings mit dem neuesten WINAVR
compiliert wird. Dieses habe ich Dir dann per Mail zugeschickt,
aber leider hast Du nie darauf reagiert.
Hast Du die Änderungen übernommen? Im SVN hast Du den Source scheinbar
rausgenommen?
Joachim
@hans,
sorry, sollte keine absicht haben. ich bin leider erst jetzt wieder
langsam in der lage was zu machen, so das ich jetzt auch wieder zeit
dafür habe. Ich beschäftige mich gerade mit der protierung auf eine
atmega644 wie du sicher schon gelesen hast, wegen mehr speicher und so,
und weil es ne 20MHZ version gibt davon. Zur zeit verweifel ich gerade
ein bisschen daran, aber langsam habe ich das gefühl das der controller
ne macke hat :-). Eigentlich sollte er ja pinkompatibel sein und so,
aber trotzdem will der code selbst nach anpassungen nicht wirklich, so
überlege ich ob ich den kompletten code noch mal neu entwickle und
modularer aufbaue in den einzelnen schichten.
CA Dirk
Hi Dirk,
aus eigener Erfahrung in solchen Fällen:
1) Tausche den Mega (habe aber wenig Hoffnung, dass es hilft)
2) Das Problem liegt vor dem Bildschirm. Du hast irgendetwas
übersehen, was sich meistens später als ganz simple herausstellt.
Soviel hat sich ja nicht geändert. Nur die Taktfrequenz, wenn
du den 644 mit 20MHz betreibst.
Dazu fällt mir dann Timer (timeouts) und evtl. SPI ein.
Hast Du schon versucht, nur den Chip zu tauschen ohne
die Taktfrequenz zu ändern? Wenn sich die Taktfrequenz ändert,
dann hast Du natürlich auch ein anderes Laufzeitverhalten der SW.
Womit testest du denn? hast Du einen ICE? Oder stocherst du so im
Code herum?
Joachim
@Hans,
ich weis auch das das problem ehr vor den bildschirm zu suchen ist, aber
langsam habe ich keine lust mehr den Fehler zu suchen. Habe alles was
auf Hardware zugreifen tut schon überprüft b.z.w. neu programmiert mir
verbesserungen und so weiter. Es läuft auch alles ganz gut,
ARP,ICMP,UDP, aber sobald tcp dazu kommt ist es glück ob es geht oder
nicht, und den fehler finde ich nicht, zumal dieses modul eigentlich
keine Hardware ansprechen tut, das poblem ist auch das das programm dann
auch an allen möglichen stellen aussteigen tut wo man es nicht erwartet.
Naja, ich werde das board nochmal diskret aufbauen und testen, mit einen
neuen controller, mal sehen. Aber zum <Thema entwickeln, ich sollte dir
mal zugriff auf das svn verschaffen, damit man gemeinsam entwickeln
kann.
CA Dirk
@Dirk:
irgendwie riecht das Problem nach einen Stack Problem.
(kam mir gerade so in den Sinn)
Möglicherweise liegt da das Problem ?
Hast Du Zugriff auf einen ICE um direkt zu sehen was passiert ?
Gruß Sven
Hast Du eine Möglichkeit den Stackpointer zu debuggen?
Sorry, ich kenne die AVR's nicht!
Wenn möglich, dann lasse im Timer (z.B. 1ms) ein Signal ausgeben (LED,
Buzzer etc.) wenn der Stackpointer an eine gewissen Grenze läuft, so
kannst Du kontrollieren, dass der Stack i.O. ist.
Es liest sich so, als wenn Du ein Ram / Stack Problem hast.
@Dirk: Im Moment ist die Zeit etwas knapp. Vielleicht im Winter.
Bis dahin ist alles zu.
@Peter K: Stackproblem ist es auf jedenfall :-) (TCP/IP Stack).
Im Ernst, es könnte am Stack liegen, aber scheint mir
unwahrscheinlich, da die Software auf einem MEGA32 läuft.
Es sei denn durch die höhere Taktfrequenz kommt eine Sequenz
zustande, die den Stack zum überlaufen bringt. Darum fragte
ich Dirk ja, ob er mal mit dem gleichen Quartz, wie auf dem MEGA32
getestet hat.
Schönen Abend
Joachim
@alle,
das mit den stack habe ich auch schon überlegt, aber wieder verworfen,
weil die gleiche software auf einen atmega32 mit wesentlich weniger
FLASH/RAM läuft. Der Quarz den ich benutze ist der gleiche auf beiden
system, da hatte ich auch schon einen fehler vermutet. Ich werde die
tage jetzt noch einen anderen atmega644 ausprobieren um die hardware an
sich auch noch auszuschließen. Leider habe ich keine ICE zum debuggen,
aber ich werde das mit den Stackpointer überwachen mal probieren, eine
recht nette idee :-).
CA Dirk
Ich hab' mir jetzt auch mal ein paar ENCs sowie CP2200s besorgt (CP2200
ist etwa dasselbe wie der ENC, nur mit parallelem Bus, sodass man es als
Memory Mapped betreiben kann).
Vorhin habe ich mich mal etwas in das Thema eingelesen.... Nur aus einem
werd' ich im Moment nicht schlau:
WIE sage ich dem ENC jetzt, welche IP er hat? Und ne MAC braucht er
vorher ja auch noch... Wo bzw. wie kann man sich eine MAC-Adresse
besorgen?
Wenn ich jetzt den ENC am LAN betreibe - kann ihn dann auch über DHCP
automatisch eine IP holen lassen? Und wenn ich jetzt von meinem PC aus
den ENC anpinge - was passiert dann? Irgendwie ist das ganze noch etwas
kryptisch.... nach "rfc" und "icmp" habe ich bereits gegoogelt, aber
nichts gefunden, womit ich als Anfänger in dem Bereich was anfangen
könnte....
Hmmmm.... Du must schon 'ne Weile lesen, mal eben in einer Stunde
hat man das nicht drauf.
Schau mal bei Wikipedia nach TCPIP oder nutze Google mit dem
Suchbegriff. Und dann schön weiter in die Details lesen.
Es ist schon Arbeit, das zu verstehen.
Zum Thema MAC-Adresse: In dem Manual vom ENC lesen.
Die setzt man in seinen Registern.
IP Adresse kannst Du Dir fest eine vergeben oder auch per
DHCP von einem DHCP-Server holen. Du must dann allerdings
erstmal das DHCP-Protokoll in Deiner Software implementieren.
Von alleine kann der ENC das nicht.
Die IP-Adresse wird von der Software geprüft, d.h. sie
nimmt ein empfangenes Paket und prüft dann die IP.
Der ENC ist ein Ethernet-Controller und weiß nichts von TCP/IP,
er sendet und empfängt Ethernet-Frames. Dort baut daann TCP/IP
auf, was in hier Software erledigt wird.
--> Wikipedia: ETHERNET
Zum Ping: PING ist ein ICMP Echo Request.
Frage auch WIkipedia.
Und jetzt hast Du erstmal Tage zu lesen :-)
Joachim
@Tobias
Der ENC und CP2200 bilden nur die physikalische Schnittestelle. Sie
leifern nur das Ethnernetframe und können solche senden. Es obligt den
Programmierer die Protokolle ab Ethernet zu implementieren. Auf das
Ethernetprotokoll setzt z.b. IP, TCP wiederrum setzt auf IP auf und so
weiter. ARP setzt auch auf Ethernet auf. Ein guter anlaufpunkt bildet
wikipedia. Das OSI-Modell verdeutlich das sehr gut wie ich es gemeint
habe http://de.wikipedia.org/wiki/OSI-Modell. Dort kannst du dann auch
weiter ansetzten. Wenn du man wireshark installierst kannst du sehr gut
sehen wie die Protokolle ineinander greifen.
CA Dirk
@Dirk:
Okay, danke erstmal für den Tip mit dem OSI.
Nur um nochmal ganz kurz auf die IP zu sprechen zu kommen: Ein
Ethernet-Frame enthält ja bekanntlich die Absender-MAC als auch die
Empfänger-MAC, sowie eine Präambel und natürlich die Nutzdaten. Aber wo
kommt denn die Empfänger-IP hin? Die wird doch wohl nicht in den
Nutzdaten stehen? Denn um Pakete vom PC an den ENC (oder irgend ein
Ethernet-Gerät) zu senden, muss man ja dessen IP kennen.
Übrigens: In diesem Zusammenhang lese ich immer wieder was von
IP-Stack... Worum gehts bei dem genau?
Grüsse
Tobias
Die IP Adresse steht in den Nutzdaten eines Ethernet-Frames.
|--ETH-Header----|----- Nutzdaten --------------------------------------|
|-- IP Header
-----|-----------------------------------|
In dem IP Header steht die IP Adresse.
IP-Stack: siehe Protokollstapel in Wikipedia.
Joachim
Mist, meine schöne Zeichnung ist versaut. Ist jetzt umgebrochen,
die Lange Zeile. Habe nicht Vorschau benutzt.
|--ETH-Header----|----- ETH Nutzdaten -------------------------------|
|-- IP Header -----|-------IP Nutzdaten-------------|
Joachim
@Tobias
Die zuordnung welche MAC-Adresse zu welcher IP gehört, wird im lokalen
netz per ARP aufgelöst. Damit kann ein Computer erfragen zu welcher IP
denn welche MAC gehört, auch zu finden in Wikipedia.
Um noch ein bisschen auszumalen, wo z.b. TCP hin gehört :-)
|--ETH-Header----|----- ETH Nutzdaten -------------------------------|
|-- IP Header ---|---------IP Nutzdaten-------------|
|--TCP--|------TCP-Nutzdaten-------|
OK, dann noch einen :-)
|--ETH-Header----|----- ETH Nutzdaten -------------------------------|
|-- IP Header ---|---------IP Nutzdaten-------------|
|--TCP--|------TCP-Nutzdaten-------|
|------ FTP ---------------|
|------ HTTP --------------|
|------ .... --------------|
oder für UDP anstatt TCP:
|--ETH-Header----|----- ETH Nutzdaten -------------------------------|
|-- IP Header ---|---------IP Nutzdaten-------------|
|--UDP--|------UDP-Nutzdaten-------|
Und schon ist der IP-Stack (fast) fertig. Ist ja eeigentlich
ganz einfach ;-)
Joachim
Der IP-Stack ist also nur die "Verscgachtelung" der einzelnen Header
ineinander? Also in den Ethernet-Nutzdaten der IP-Header, in den
IP-Nutzdaten der TCP-Header usw. ?
Nicht ganz, den den ETH-Nutzdaten sind er IP-Header + die IP-Nutzdaten.
In den IP-Nutzdaten sind dann der TCP-Header + TCP-Nutzdaten u.s.w.
IP-Stack ist der Protokollstapel. Findest Du auch unter de Stichwort
ganz gut erklärt im Wikipedia.
Joachim
@alle
so, ich habe mir jetzt das wochenende mit den ATmega644 um die ohren
geschlagen, und musste feststellen das der Controller schei*e ist. Ich
betreibe ihn mit 3.3V bei 8MHz, so wie es laut datenblatt okay ist. Ja,
was soll ich sagen, er spielt verrück. Es treten immer zufällige Fehler
auf die nix mit den programm zu tun haben. Ich habe auch mehre
Controller ausprobiert, bei jeden gab es was anderes was mit dem
gleichen hexfile nicht ging. Ich habe schon überlegt ob es die
versorgungspannung ist die da stört, aber auf den Oszi ist nix zu sehen.
Die Krönung war das auf einen Controller das Bit im Statusregister nicht
gesetzt worden ist wenn man eine SPI gestartet hat das diese fertig, wer
soll so ein fehler finden?
Ich werde jetzt mal versuchen ein Board mit 5V für den Controller zu
bauen und 3.3V für den ENC28j60. MAl sehen wie das aussieht. Ob die
ATmega644 sich dann benehmen :-).
CA Dirk
Hi Dirk,
hmmmm..... ohne Dir zu nahe treten zu wollen. Mir fällt es schwer das zu
glauben. Also bei Dir wird es so sein, das glaube ich schon, aber ich
denke, es liegt eher an Deiner Beschaltung und nicht an dem Mega644. Der
Mega32 reagiert evtl. etwas unempfindlicher. Ich habe hier auch schon
sporadische Resets
gehabt. Masseproblem!
Nun ja, viel Glück.
Joachim
@Hajo
werd ich ja morgen sehen, ich habe gerade das <board für zwei spannung
geroutet und bin gespannt. Ich habe den 644 auch mal nur alleine laufen
lassen mit den 3.3V des alten boards, da traten die gleichen fehler auf
ohne das was dran hing. Auf einen Steckbrett mit 5V traten die Probleme
schon nicht mehr auf, was denke ich schon mal für sich sprechen tut.
Im Datenblatt schweigen sie sich auch nen bisschen aus, und haben nur
einen Graphen gezeichnet mit den Spannungen der kennzeichnet was Save
ist und was nicht.
MfG Dirk Broßwick
@Thomas
du wolltest doch wissen wie es mit der portierung aussieht. Bestens, lag
am controller. Bei einem Reset wird auf den ATmega32 der RAM wohl
gelöscht, während sie auf anderen Controllern undef sind. Das hat den
Softwarecounter verwirrt. Bin im endeffekt mit einen JTAG drauf
gekommen. Jetzt läuft der IP-Stack auch auf einen ATmega644 und einen
ATmega2561 mit externen RAM und rock so richtig :-).
CA Dirk
Hallo leute
Ich habe eine Platine mit einem ATmega32 und einem ENC28J60 aufgebaut.
Debuggen und programmen tu ich das ganze mit einem JTAGICE MK2 über
JTAG.
Ich versuche zur Zeit dieses Programm zum laufen zu bringen.
Status LED leuchtet, die andere LED blinkt wenn ich eine Verbindung mit
dem Laptop herstelle über RJ45.
Ich schaffe aber einfach keinen ping. Er meldet das der Zielhost nicht
erreichbar ist. Laptop hab ich im selben Netz hängen.
An was könnte ich scheitern? Hat es vielleicht was mit meinen Fuses zu
tun?
Bitte um Hilfe
mfg
Hannes
Hallo,
hat diesen Stack noch jemand im Einsatz? Ich habe dazu leider nichts
aktuelles gefunden.
Ich versuche gerade, ihn auf dem Pollin Net-IO Board zum laufen zu
bekommen, nur leider funktioniert er nicht so ganz. d.h. der Stack läuft
und antwortet auch, allerdings kann ich mit dem Webbrowser nicht darauf
zugreifen, weil er immer abbricht.
lohnt es sich, mit dem Stack weiter zu machen oder gibt es besseres?
Danke
Bernhard