Wiznet W5500 init

Johannes S. schrieb:
> nach dem Reset ist die MAC wieder weg und
> ein folgender DHCP request schlägt fehl.

Du sollst ja auch den Controller nicht dauernd resetten.

Das macht man einmal vor der Initialisierung und dann
"nie mehr". Alles andere ist Käse.

mache ich ja auch nur einmal, und da wird das init und dann reset 
aufgerufen. Reset soll nötig sein weil der keinen POR hat.
https://forum.wiznet.io/t/topic/1224

Johannes S. schrieb:
> und da wird das init und dann reset aufgerufen.

Macht aber keinen Sinn. Erst Reset und dann Init.

das ist aber nicht auf meinem Mist gewachsen, das ist Code vom 
Hersteller. Und 'eigentlich' sollte der wissen wie es richtig ist.
Wenn das Ding mit dem Schreiben des MAC Registers diese behält macht das 
ja auch Sinn, deshalb frage ich.

Johannes S. schrieb:
> und nach dem Reset ist die MAC wieder weg

Also folglich tut doch der Reset doch so wie er tun soll,
nicht wahr? Wo bleibt deine Logik?

Entweder die Rgisterinhalte bleiben nach dem Reset, oder
man muss sie durch Initialisierung neu schreiben.

Also:

OMG schrieb:
> Erst Reset und dann Init.

Nachtrag:

Ich habe noch nie eine solch doofe Hardware in den Händen gehabt
die erst initialisiert werden will und dann einen Reset verlangt.
Und ich habe schon einige Chips "in den Händen gehabt".

Das kann im GIT Archiv stehen was will ....

A. H. schrieb:
> Schö wenn man den auch sehen könnte.

habe ich doch im ersten Post verlinkt.
es wird
im init

1

    _wiznet.setmac();

2

    _wiznet.reset();  // reset chip and write mac address

aufgerufen. setmac() schreibt in die Wiznet Register 0x0009...0x000e die 
MAC. reset() toggelt einen gpio und löst damit einen HW Reset im Wiznet 
aus. Wenn ich danach die MAC auslese ist die 0:0:0:0:0:0:0. Also macht 
sowas nur Sinn wenn setmac() die persistent machen würde. Sehe ich aber 
nicht, also warum bietet der Hersteller so einen Code an?

Johannes S. schrieb:
> also warum bietet der Hersteller so einen Code an?

OMG schrieb:
> Da kann im GIT Archiv stehen was will ....

die Reihenfolge habe ich geändert, dann wurde der DHCP aufgerufen und 
der hat brav eine IP geliefert. Beim Setzen jedoch wird wieder ein 
reset() aufgerufen... Das kommt davon wenn man kategorisch Debugger 
ablehnt.
Als nächstes ist der Code kaum für Multitasking geeignet, ständig wird 
in Polling Schleifen blockiert. Warum setzt man einen eigenen Prozessor 
für Ethernet ein wenn der Haupt µC mit Polling ausgebremst wird?
Jetzt hänge ich im accept(), aber nach reproduzierbar 7-8 s stoppt die 
SPI Kommunikation. Ist das evtl. ein Zyklus wo noch ARP oder irgendwas 
bei dem Ding gemacht wird?

Johannes S. schrieb:
> Als nächstes ist der Code kaum für Multitasking geeignet, ständig wird
> in Polling Schleifen blockiert.

Was lernt man daraus?

--> selbst programmieren <--

Der W5500 hat auch eine IRQ-Leitung, wenn man die benutzt
wird man nichts mehr pollen müssen.

Aber auch das Pollen kann man zeitsparend machen indem
man das Statusregister von einem Timer (bzw den SYSTICK)
zyklisch per Interrupt auslesen lässt. Das SPI ist beim
W5500 affengeil schnell sodass da auch keine grössere
zeitliche Belastung auftritt.

Johannes S. schrieb:
> wenn der Haupt µC mit Polling ausgebremst wird?

Das muss ja nicht der Weisheit letzter Schluss sein.
Ist halt eine Demo dass es (gerade so) funktioniert ....

OMG schrieb:
> Was lernt man daraus?
>
> --> selbst programmieren <--

Da kann ich dir versichern das ich genug selber programmiere und 
mittlerweile >40 Jahre Erfahrung mit verschiedensten Sprachen und 
Plattformen habe.

In diesem Fall ging es mir nur um Resteverwertung und Weiterbildung in 
Mbed. Der Wiznet ist heute eigentlich obsolet, es gibt genügend µC mit 
integriertem NIC. Der W5500 kann kein TLS, was heute aber wichtig wäre 
wenn ein Device am Internet hängt. Und schnell, naja, ich habe die 
gleiche Software auf einem F407 mit 168 MHz und integriertem NIC und der 
liefert die gleiche HTML Seite mehr als 10x so schnell, gegenüber W5500 
an einem F411 mit 100 MHz. Habe da allerdings noch kein detailiertes 
Profiling betrieben, am SPI alleine hängt es in dem Fall aber nicht. Der 
HTTP Server Code ist dabei identisch, dank der einheitlichen Ethernet 
Treiberschicht.

Den W5500 gibt es jetzt schon viele Jahre und da hatte ich angenommen 
das die Software PnP ist. Normalerweise läuft sowas in 1-2 h, je nachdem 
wieviel der gcc wieder neu anmeckert und was in Mbed wieder geändert 
wurde. Das ist in der Entwicklung sehr dynamisch und das Ethernet 
Interface wurde vor einigen Monaten noch überarbeitet. Eine ältere 
Version für Mbed2 lief ad hoc, aber das Interface passte nicht zum 
neueren Mbed5. Wiznet wirbt mit Mbed Unterstützung und hat einen 
offizielen Userspace auf mbed.org und auch auf github. Der neueste 
Treiber vom 2019/01 wurde aber definitv richtig geschreddert. An einem 
Fork wurde noch 2019/09 gearbeitet.
Ich helfe auch gerne mit sowas zu verbessern, aber wenn es schon keinen 
Issue Button auf github gibt dann hat der Hersteller wohl doch kein 
richtiges Interesse oder keine Ressourcen für die Wartung. Immerhin 
haben die ein auch ein aktives Forum, vielleicht gibts da Antwort.

IRQ Nutzung ist natürlich auch sinnvoll. Dazu habe ich allerdings auch 
schon Beiträge gefunden nach denen auch bei IRQ noch einiges gepollt 
werden muss. Ob das stimmt weiß ich nicht, habe mich erst zwei Tage mit 
dem Chip beschäfftigt und dafür läuft doch schon einiges.
IRQ in Kombi mit dem Mbed Event System wäre eine gute Lösung. Und gleich 
einen ganzen HTTP Server Eventbasiert statt mit Threads.

Nachtrag zum eigentlichen Problem:
beim vielen Testen und Probieren hatte ich die HTTP Instanz in einen 
else Zweig von einem if (success) verschoben. Das war natürlich ein 
Eigentor, weil der Server erzeugt aber beim Verlassen des Blocks gleich 
wieder zerstört wurde. Ja, nach vielen Stunden Fehlersuche sollte man 
erstmal Pause machen. Eine lange bekannte aber gerne ignorierte 
Erkenntniss :)

Johannes S. schrieb:
> und
> mittlerweile >40 Jahre Erfahrung mit verschiedensten Sprachen und
> Plattformen habe.

So so .....

(So hemdsärmelig kann man eigentlich nicht sein)

... und dann muss ich dir mit all deiner Erfahrung solche
Basics erzählen wie

OMG schrieb:
> Also folglich tut doch der Reset doch so wie er tun soll,
> nicht wahr? Wo bleibt deine Logik?
>
> Entweder die Registerinhalte bleiben nach dem Reset, oder
> man muss sie durch Initialisierung neu schreiben.

Mit deinen ">40 Jahre Erfahrung" sollte dann aber auch deine
Vertrauensseligkeit / Gutgläubigkeit zumindest auf einen
deutlich kritischeren Level abgesunken sein.

OMG schrieb:
> ... und dann muss ich dir mit all deiner Erfahrung solche
> Basics erzählen wie

so so, welche Basics?

Und wenn jemand einen eigen Ethernet Chip entwickelt dann masse ich mir
nicht an nach 2h alles besser zu wissen. Software und Hardware die in
vielen Produkten arbeitet sollte erstmal besser sein als das was ich mir
auf die Schnelle ausdenke.

[c]
int WIZnetInterface::init(uint8_t * mac, const char* ip, const char* 
mask, const char* gateway)
{
    _dhcp_enable = false;
    //
    for (int i =0; i < 6; i++) _wiznet.mac[i] = mac[i];
    //
    _wiznet.ip = str_to_ip(ip);
    strcpy(ip_string, ip);
    ip_set = true;
    _wiznet.netmask = str_to_ip(mask);
    _wiznet.gateway = str_to_ip(gateway);
    _wiznet.reset();

    // @Jul. 8. 2014 add code. should be called to write chip.
    _wiznet.setmac();
    _wiznet.setip();
    init_socks();

    return 0;
}
[\c]

Und wo genau wird jetzt erst geschrieben, dann reset gezogen?

Ich sehe setzen von properties, reset, schreiben von Mac und IP..

das ist für den Fall das man init mit mac und ip aufruft, beim Aufruf 
von ini nur mit mac sieht es anders aus, siehe Link vom ersten Post.
Wenn man das nur mit statischer Adresse benutzt fällt der Fehler 
vielleicht nicht auf.