AVB in der Theorie super aber die Praxis ist eher bescheiden

  • Also 10 Jahre will ich nicht brauchen :/, bald ist aber ein Jahr vergangen seit dem ich an der Sache dran bin..


    Aber es gibt Fortschritte, die Problematik mit dem Format bei Control und weiteren Kommandos ist gelöst.


    Es bestand ja das Problem die Daten zu entschlüsseln da einige Informationen dazu nicht in der Antwort enthalten sind. Man musste also auch die Descriptoren lesen...


    Das Entfällt und das macht der Controller jetzt für den Client. Voraussetzung das Control Value wurde mit einen Descriptor beschrieben... Sonst kommt es in base64 zurück.


    So kann man das Value per GET auslesen und bekommt das inkl. Präfix im korrekten Format zurück. Das macht es für Clients besonders einfach und sie müssen nicht zwangsweise die Descriptoren auslesen.


  • Hallo,


    ich finde toll was du da machst! Ich hätte nur noch eine Frage: du schreibst immer dass die sache "auf dem Switch läuft". Mir ist nicht klar auf welcher Hardware weiter vorne war vom Netgear GS724 die Rede bzw dass du zugriff aufs Extranet erhalten hattest - jedoch schien mir du hattest den ansatz verworfen.


    Dann ist wieder vom XMOS die Rede hast du hier die Module weiterverwendet die du weiter vorne mal fotografiert hattest?



    Ich hab schon ein wenig erfahrung mit REST-APIs und jSon, hab aber noch keine AVB HW im das ganze nachzustellen (abgesehen von 2 Rechnern mit intel i210).


    Gruß

    Dominik

  • Nunja eine Switch besteht aus zwei teilen. A: den Core der die Datenpakete transportiert. B: Ein System welches den Core steuert. Das System B ist ein normales OS z.Bsp Linux, auf dem man andere Sachen laufen lassen kann. Dort könnte man auch einen AVB Controller laufen lassen.


    Diese China Switch basiert auf einen Marvell in dessen ein ARM mit einer Switch kombiniert wurde. Das Problem ohne die Dokumention über die Register ist das ganze nutzlos und ich hatte trotz alles versuche keinen Zugang zur Buildroot Umgebung um Treiber oder auch Programme für das System zu bauen.


    Xmos ist für mich mittlerweile unten durch. Der Stack ist so etwas von Grausam gebaut und ungepflegt das es sich kaum lohnt den noch weiter an zufassen. Mittlerweile habe ich die schlimmsten Bugs behoben und mir Descriptoren gebastelt um den Controller zu testen.


    Der größte Nachteil ist aber das der Xmos zu wenig Leistung hat. x-core200 hat zwar eine 1Gbit/s PHY macht aber bei ca. 44Mbit/s schlapp. In Channels ausgedrückt alles über 32Ch ist problematisch..


    Ohne Traffic-Shaping kann ich den Controller dazu benutzen den Stream zu stören. Ich sende einfach 100000 AVDECC Pakete an das Gerät.. Um das zu vermeiden muss ich verhindern das ich das Gerät mit Trafic bombardiere. Ich könnte schauen in wie weit Antworten zurückkommen und den Sende Queue dann so steuern... Nächstes Problem ...


    Es gibt immer wieder Ankündigungen das es einen AVB Stack der auf einen ARM läuft veröffentlicht, aber es entsteht ein ähnliches Problem. Zu wenig Leistung, für 1Gbit/s ohne FPGA nicht möglich.

  • Ja von Intel z.Bsp. Aber schon mal etwas für FPGA gemacht ? Wenn du ohne Module auskommen willst kannst du alles aus Gattern zusammen basteln. Willst du dir das ersparen musst du dein Portmonee weit aufklappen das wäre dann auch schon leer nachdem du die nötigen Lizenzen erworben hast um deinen Code zu erzeugen..


    Für Rolf seinen Medienwandler ist das relativ einfach, für AVB schon etwas schwieriger und sehr umfangreich.


    Xmos sollte ja eine alternative zum FPGA darstellen. Da es keine Interrupts gibt, sind zeitkritische Dinge planbar. Es ist aber immer noch ein Mikrocontroller mit mehrenden Kernen. Der auch einen Begrenzten Takt aufweist und wie es somit mal ist mehre Takte benötigt um einen Befehl auszuführen.


    Nachteil sind auch die hohen kosten vom FPGA selbst. Ein ARM kostet ein paar Dollar.. Ein FPGA $40 und mehr..

  • So der stand ist jetzt so das alles zum neuen internen http Service portiert wurde :) Das alte Interface wurde entfernt...


    Bevor was neues hinzu kommt werde ich den Core optimieren und auf Bugs abklopfen.


    Dann kommt erst mal der Dicke Brocken mit der Datenbank um die Trafic aus den Geräten zu nehmen.


    Der zweite Punkt ist der http Service -> File API, Session Management,TSL, Access Konfiguration


    Punkt 3 Firmware Updates der Geräte..


    Schaut mal auf der PLS nach AVB Geräten ;)

  • Nun bin ich doch daran TLV umzusetzen, damit kann man auf den Speicher des entitys direkt zugreifen. Das ist der Mechanismus für Firmware Updates.


    Apple hat sogar Bildchen hinterlegt, und vergessen die Adressen zu prüfen. Sie prüfen sie schon reichen mir aber den Inhalt trotzdem durch. 8| autsch.. ich kann also im Speicher des Prozesses munter herum rutschen.


    Ein dummes Problem ist das dieses Mechanismus den schreiben,lesen und ausführen mit einen Kommando erlaubt. Dazu bildet man eben mehrere TLV.. Das lässt sich aber in der Rest API nicht abbilden, des wegen kann man nur ein TLV pro Kommando absetzen.

  • Tadaaa es ist ein Bild ein Bild :D..


    Was ist passiert ? Mir ist es gelungen im Memory Deskriptor beschrieben Inhalt auszulesen und als base64 zu encodieren ;) .


    Die Daten decodiert und wir haben ein gültiges Bild eines Apple Entitys. Welches sich im Browser ohne Probleme decodieren lässt. Der Vorteil darin ist das mit einen Request der Inhalt verfügbar ist und nicht noch mal ein extra Request um den Inhalt abzuholen. Man könnte das natürlich auch Binär übertragen, aber dann verlassen wir das Json Konzept.


    Was noch gemacht werden muss -> senden per chunks an den Client und auch das übertragen von Daten zum Entity :)


    Was ich noch überlege das ganze aus den Deskriptor heraus zu machen, somit muss man keine Adressen und Längen angeben.


    Offenbar haben einige den Standard nicht gelesen :/, die Payload ist beim AECP begrenzt und deutlich kürzer als die mögliche.. Das hat einen Grund, man will das diese Pakete im QOS zwischen gequetscht werden. Sind diese zu lang passen sie kaum zwischen den Pausen..


    Die meisten senden trotzdem längere Pakete...