Servus, kennt sich jemand mit dem genannten LAN Controller aus bzw hat damit schon gearbeitet? Ich kann Prima damit Daten Senden aber eben nicht empfangen egal was ich einstelle
Ge E. schrieb: > Ich kann Prima damit Daten Senden aber eben > nicht empfangen egal was ich einstelle Bei der un-überschaubaren Menge an Informationen wird es schwierig werden eine Lösung zu finden.
Wastl schrieb: > wird es > schwierig werden eine Lösung zu finden. Er will keine Lösung finden, er sucht jemanden der den Controller kennt 😄
Niklas G. schrieb: > Er will keine Lösung finden, er sucht jemanden der den Controller kennt > 😄 Ein Fall für Parship? Oder Julia Leischik?
:
Bearbeitet durch User
Servus.. ich gehe erst ins Detail wenn sich hier jemand findet der schon mit diesem Controller gearbeitet hat.. Externe können hier sowieso nicht helfen weil das Thema zu speziell ist.
Hui, 600 Seiten Datenblatt. Das Teil ist etwas schon etwas komplexer und als Ethernet Switch mit SPI auch etwas exotisch. Ich an deiner Stelle würde ja mal sagen was schon geht und was nicht. Ethernet können hier einige und SPI auch. Damit lassen sich bereits sehr viele der Probleme eingrenzen.
Benjamin K. schrieb: > Hui, 600 Seiten Datenblatt. Das Teil ist etwas schon etwas komplexer und > als Ethernet Switch mit SPI auch etwas exotisch. > Nein, isser nicht. Als managed Switch haben sie alle eine (Quad)-SPI. Denn da kommt üblicherweise das Eprom dran, wo die Firmware rein kommt. Oder eben die Schnittstelle, wo der MuC für das Management dran kommt. Dass er nur zwei Ports hat, ist dann schon exotischer. Damit ist er quasi nur dazu da, um zwei Netzwerke zu trennen. PS: Die Gigabit-Brüder kommen mal ganz nebenher mit 4..8kSeiten Handbuch und Appnotes. Um solche Knödel zu verwenden, sollte man zumindest in Grundzügen einen Überblick haben, was TCP/IP auf den unteren Layern so macht. Sonst wird das schnell ein Martyrium. PPS: Daten senden aber nicht empfangen klingt etwas nach einer verkorksten Filter/NAT Geschichte im Switch.
:
Bearbeitet durch User
Roland E. schrieb: > Dass er nur zwei Ports hat, ist dann schon exotischer. Damit ist er > quasi nur dazu da, um zwei Netzwerke zu trennen. Genau genommen 3, der Host hängt ja auch als Port mit dran. Im Embedded-Bereich ist das praktisch fürs Daisy Chaining von Geräten, ohne dass die CPU mit softwaremässigem Bridging belastet wird. IP-Telefone sind auch eine typische Anwendung dafür, aber heutzutage eher mit GbE.
:
Bearbeitet durch User
Benjamin K. schrieb: > Hui, 600 Seiten Datenblatt. Das Teil ist etwas schon etwas komplexer und > als Ethernet Switch mit SPI auch etwas exotisch. > > Ich an deiner Stelle würde ja mal sagen was schon geht und was nicht. > Ethernet können hier einige und SPI auch. Damit lassen sich bereits sehr > viele der Probleme eingrenzen. Hallo, also ich nutze kein SPI sondern den 16 Bit Paralell Bus und die Kommunikation funktioniert. Ich kann alle Register beschreiben und lesen und ich kann auch Datenpakete über das Ethernet senden aber ich kann eben keine Pakete auf dem Kontroller empfangen. Dazu lese ich das RX_FIFO_INF (unteren 16Bit) und das ist immer 0 (sollte größer 0 sein wenn ein Paket empfangen wurde) RX an sich ist aktiviert und auch so konfiguriert das ich alle Pakete empfangen müsste
Roland E. schrieb: > PPS: Daten senden aber nicht empfangen klingt etwas nach einer > verkorksten Filter/NAT Geschichte im Switch. ja das denke ich auch, aber wie gesagt ich habs eigentlich so konfiguriert das ich alles auf Port 0 (der Interne Port an dem mein PIC hängt) empfangen sollte
Hmmm schrieb: > Im > Embedded-Bereich ist das praktisch fürs Daisy Chaining von Geräten Exakt das ist der Grund für den zweiten (dritten) Port.. es soll nur weitergeleitet werden
Ge E. schrieb: > ich habs eigentlich so > konfiguriert das ich alles auf Port 0 (der Interne Port an dem mein PIC > hängt) empfangen sollte Was sagen die Counter-Register? Schuss ins Blaue: Die eingehenden Pakete landen in einem VLAN, in dem Port 0 nicht hängt.
ein Auszug der gesetzten Konfiguration: (ich habe übertrieben viel Aktiviert um zu provozieren das ich überhaupt irgendwas empfange, später will ich natürlich filtern) HMAC_CR= Receive All Mode (RXALL) Disable Receive Own (RCVOWN) Full Duplex Mode (FDPX) Pass All Multicast (MCPAS) Promiscuous Mode (PRMS) default set Hash/Perfect Filtering Mode (HPFILT) Transmitter enable (TXEN) Receiver Enable (RXEN) hier noch ein interessanter Satz ausm Datenblatt zum Verständniss: (HMAC_CR) Bits 19-15, 13, and 11 determine if the Host MAC accepts the packets from the switch fabric. The switch fabric address table and configuration determine which packets get sent to the Host MAC. Der erste Teil ist damit erfüllt (HMAC_CR), es sollten also alle pakete die vonm switch fabric kommen empfangen werden. Allerdings habe ich das Gefühl das keine Pakete überhaupt vonm switch fabric gesendet werden weil sie vorher schon rausgefiltert wurden. Ich gehe davon aus das mit "switch fabric address table" die "ALR" gemeint ist ?? Dort habe ich entsprechend die Broadcast MAC eingetragen und meine Port0 MAC. Aber bringt alles nix
Hmmm schrieb: > Was sagen die Counter-Register? gute Frage ich check das eben mal.. VLAN müsste glaube ich standartmäßig aus sein
Ge E. schrieb: > Ich gehe davon aus das mit "switch fabric address table" die "ALR" > gemeint ist ?? Dort habe ich entsprechend die Broadcast MAC eingetragen > und meine Port0 MAC. Eigentlich sollte der Switch das alleine machen: Wenn eine MAC-Adresse nicht in der Address Table steht (oder es ein Broadcast ist), geht das Paket an alle zum VLAN gehörigen Ports. Wenn sie drinsteht, nur an den passenden.
ich habe als Beispiel das MAC_RX_256_TO_511_CNT_1 gelesen und das Zeigt 4 Bytes an Das MAC_RX_256_TO_511_CNT_0 (wo ich nix empfange) zeigt hingegen wie erwartet 0
ich habe sogar die Snooping funktion getestet: SWE_PORT_MIRROR= Enable RX Mirroring Filtered Sniffer Port 0 Mirrored Port 1 Enable RX Mirroring aber die Pakete die auf Port 1 eintreffen werden nie auf Port 0 weitergeleitet. Wie gesagt senden kann ich was ich will das klappt immer und er sendet es auch auf beiden Ports raus (wie zu erwarten).
:
Bearbeitet durch User
Ge E. schrieb: > ich habe als Beispiel das MAC_RX_256_TO_511_CNT_1 gelesen und das Zeigt > 4 Bytes an > > Das MAC_RX_256_TO_511_CNT_0 (wo ich nix empfange) zeigt hingegen wie > erwartet 0 Die sollten dort eher im TX-Counter auftauchen, das sind schliesslich die Switch-MACs. Beim Host-MAC ist es dann wieder die RX-Seite.
Hmmm schrieb: > Die sollten dort eher im TX-Counter auftauchen, das sind schliesslich > die Switch-MACs. Beim Host-MAC ist es dann wieder die RX-Seite. mm nee das passt schon so es sind ja eingehende pakete. Ich habe aktuell mein PC am Switch Port 1 hängen und die Fritzbox an Port 2 In den TX countern steht natürlich auch was (in allen dreien) weil senden vom Port 0 aus ja funzt
:
Bearbeitet durch User
Ge E. schrieb: > Hmmm schrieb: >> Die sollten dort eher im TX-Counter auftauchen, das sind schliesslich >> die Switch-MACs. Beim Host-MAC ist es dann wieder die RX-Seite. > > mm nee das passt schon so es sind ja eingehende pakete. Wenn ein Paket auf Port 1 empfangen wird und auf Port 0 landet, würde ich folgendes erwarten: - Switch-MAC 1: RX-Counter zählt hoch (Paket kommt dort in den Switch rein) - Switch-MAC 0: TX-Counter zählt hoch (Paket verlässt dort den Switch) - Host-MAC: RX-Counter zählt hoch (Paket kommt dort an) Zum Testen würde ich mit unterschiedlichen Paketgrössen arbeiten (z.B. Embedded Device schickt immer kleine Pakete, Test-Gegenstellen grosse), damit Du an den Countern erkennen kannst, woher sie ursprünglich kamen. Evtl. musst Du übrigens auch noch den Virtual PHY konfigurieren, damit überhaupt Pakete zwischen Host-MAC und Switch Fabric fliessen können.
:
Bearbeitet durch User
Port 0 ist die Host MAC - desshalb landen eingehende Pakete beim RX counter 0 0 - virtuell / host mac 1 und 2 sind die Physischen
:
Bearbeitet durch User
Hmmm schrieb: > Evtl. musst Du übrigens auch noch den Virtual PHY konfigurieren, damit > überhaupt Pakete zwischen Host-MAC und Switch Fabric fliessen können. hast du spontan das Register bzw die Datenblatt Seite dazu?
Ge E. schrieb: > Port 0 ist die Host MAC Das Datenblatt sagt nein, siehe Figure 2-1. Demnach ist MAC_RX_256_TO_511_CNT_0 der Counter auf Switch-Seite.
Ge E. schrieb: > hast du spontan das Register bzw die Datenblatt Seite dazu? Seite 304, Kapitel 12.3.3.
MAC_TX_256_TO_511_CNT_0 = 3 das verwundert mich.. da ich von port 0 nichts gesendet habe.. oder aber es sind irgendwelche automatischen negotiation packete die er beim start sendet das könnte schon sein
VPHY_BASIC_CTRL habe ich so gelassen wie es ist VPHY_ID_MSB - damit kann ich nichts anfangen ich denke da muss ich nichts einstellen ?? Rest auch auf default gelassen
auf port 1 empfange ich 50 Broadcast packete, die erwarte ich eigentlich zeitgleich auch auf port 0 aber dort kommen die nie an.. irgendwo fehlt mir noch ein Bit welches verhindert das Port 0 Teil des Switches ist, zumindest wenn es um das empfangen von Packeten geht
:
Bearbeitet durch User
Ge E. schrieb: > MAC_TX_256_TO_511_CNT_0 = 3 > > das verwundert mich.. da ich von port 0 nichts gesendet habe.. Ich wiederhole es nochmal: Die Counter für MAC 0 bis 2 beziehen sich auf die Switch-Seite, d.h. der Switch hat 3 Pakete dorthin (an den Host) geschickt. Ge E. schrieb: > oder aber > es sind irgendwelche automatischen negotiation packete die er beim start > sendet das könnte schon sein Für STP-BPDUs klingen die recht gross. Sind das evtl. die verlorenen Pakete?
wie kommst du darauf das es von switch Seite und nicht von port Seite zu sehen ist ? aber sei es drum auf Port 0 kommt nix an und der Promiscuous Mode und Receive All Mode aufm vphy ist aktiv so das alles durchgelassen werden müsste
:
Bearbeitet durch User
Ge E. schrieb: > wie kommst du darauf das es von switch Seite und nicht von port Seite zu > sehen ist ? Weil das die übliche Logik in Switches ist und der Switch im Blockschaltbild auch als abgegrenzte Einheit ("Switch Fabric") gezeigt wird. Im Host-MAC scheint es leider keine Counter zu geben. Ge E. schrieb: > Ich habe aktuell > mein PC am Switch Port 1 hängen und die Fritzbox an Port 2 Können die eigentlich über den Switch miteinander kommunizieren? Und landen Deine gesendeten Pakete bei beiden?
Hmmm schrieb: > Im Host-MAC scheint es leider keine Counter zu geben die heisen dort nicht direkt counter aber man sieht wie viele pakete empfangen/gesendet wurden und auch wie gros die sind. RX_FIFO_INF und RX_STATUS_FIFO
Hmmm schrieb: > Können die eigentlich über den Switch miteinander kommunizieren? Und > landen Deine gesendeten Pakete bei beiden? sorry das habe ich überlesen. Ja die Kommunikation über den Switch klappt reibungslos. Wie gesagt ich habe mein PC an Port 1 und den Router an Port 2 während der Testphase
:
Bearbeitet durch User
das ist echt zum verzweifeln.. MAC_TX_PKTOK_CNT_0 und MAC_RX_PKTOK_CNT_0 zählt empfangene und gesendete Pakete aber bei der Host Mac kommt angeblich nichts an (RX_FIFO_INF 15:0 == 0), obwohl sie so konfiguriert ist das sie alles durch lassen soll. Irgendwas übersehe ich
Ge E. schrieb: > MAC_TX_PKTOK_CNT_0 und MAC_RX_PKTOK_CNT_0 > zählt empfangene und gesendete Pakete aber bei der Host Mac kommt > angeblich nichts an (RX_FIFO_INF 15:0 == 0), obwohl sie so konfiguriert > ist das sie alles durch lassen soll. Was sagt der RX Status FIFO, und zählt evtl. RX_DFC hoch, wenn Pakete reinkommen?
Hmmm schrieb: > Was sagt der RX Status FIFO, und zählt evtl. RX_DFC hoch, wenn Pakete > reinkommen? beides 0 leider :/
Ge E. schrieb: > beides 0 leider :/ Vielleicht findest Du hier Anregungen: https://lore.kernel.org/all/20160219201415.GA9884@lunn.ch/t/
Hmmm schrieb: > https://lore.kernel.org/all/20160219201415.GA9884@lunn.ch/t/ hab ich schon gesehen.. aber ich kanns mir ja nochmal anschauen
MC support hat sich endlich gemeldet, wenn der Fehler gefunden ist werde ich es hier mitteilen vielleicht hilft es irgendwann mal jemanden ^^
Ge E. schrieb: > wenn der Fehler gefunden ist werde ich es hier mitteilen vielleicht > hilft es irgendwann mal jemanden ^^ Würde mich auf jeden Fall interessieren.
OMG was findet hier für ein up und downvote Wahnsinn statt mach einer scheint nichts besseres zutun zu haben. Aber back to topic - der MC support ist sehr träge, ich habe denen die Situation möglichst Ausführlich geschildert und ich rechne im laufe der nächsten Woche mit einer Lösung
Es gibt Neuigkeiten. Ich habe es durch Zufall wie es manchmal so ist selbst herausgefunden. Ich darf im Register "MAC_WUCSR" nichts setzten. Jetzt kann ich Pakete empfangen
Ge E. schrieb: > Ich darf im Register "MAC_WUCSR" nichts setzten. Dass Du nichts empfängst, wenn Du den Host-MAC in einen WOL-Schlaf schickst, ist allerdings naheliegend und auch so dokumentiert, hier z.B. für PFDA_EN: "In this mode, normal data reception is disabled, and detection logic within the MAC examines the destination address of each received frame." Aber danke für die Rückmeldung, das IC klingt insgesamt interessant.
Hmmm schrieb: > In this mode, normal data reception is disabled, and detection logic > within the MAC examines the destination address of each received frame. ganz genau! Dieser Satz ist mir ins Auge gesprungen und ich habe daraufhin meine Config überprüft und tatsächlch hatte ich dieses Bit gesetzt. Jetzt habe ich das nächste Problem. Ich empfange ein Paket mit 58 Byte Größe RX Status sagt 64 Byte (was ok ist wegen padding) Allerdings ist mein 16. DWORD immer 0xC5C80253, ich erwarte aber 0x00000000
:
Bearbeitet durch User
Ge E. schrieb: > Allerdings ist mein 16. DWORD immer 0xC5C80253, ich erwarte aber > 0x00000000 Hängt das evtl. mit PADSTR im HMAC_CR zusammen?
das gilt nur für Frames unter 46 bytes.. ich habe hier 58 byte. Außerdem ist es nicht aktiviert Das komische ist auch das ich anschließend keine weiteren pakete mehr empfangen kann (RX Error Flag ist nicht gesetzt).
:
Bearbeitet durch User
ok nevermind, ich kann jetzt auch weitere Pakete empfangen das war ein Fehler in meinem code.
jetzt muss ich mich noch mit PTPv2 auseinandersetzen in zusammenhang mit RTP.. kennst dich da zufällig aus ? Im RTP pakt habe ich ja einen Timestamp (32 Bit) aber das ist nicht der Selbe wie im PTP Paket - wie ist da die Realtion zu einander
:
Bearbeitet durch User
Ge E. schrieb: > Im RTP pakt habe ich ja einen > Timestamp (32 Bit) aber das ist nicht der Selbe wie im PTP Paket - wie > ist da die Realtion zu einander Da gibt es gar keine direkte Relation. Bei RTP ist das ein Timestamp innerhalb des laufenden Streams, gemessen in Samples. Der RTP-Sender kann natürlich per PTPv2 synchronisiert werden, aber so genau will man es wohl höchstens im Broadcast-Bereich haben, wo man dann eher den Studiotakt als Referenz nehmen würde.
jup genau ich will den RTP audio stream mit PTPv2 syncen Stichwort AES67 - Multicast. Eine Einspeise Einheit habe ich, die sendet im 4tel oder 8tel Sek Takt PTPv2 Sync, Anncounce und Follow up messages. Die müsstre ich iwi erstmal in dem Controller auffangen der hat ja volle PTPv2 Unterstützung.
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.