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
@Dirk, servus :-) Wie schauts denn bei Dir aus zwecks Stack und 644er?
hi ich habe probs mit WinAVR, Kann jemand mal eine fertige HEX hineinstellen ? Danke schon mal im vorraus Mfg Basti
@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
Hi! b>Kann jemand mal eine fertige HEX hineinstellen ? Andrej
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
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.