Hallo, ich möchte einen "TS" Stream der aus einem SAT Empfänger (Modul von ALPS) kommt analysieren. Es geht nicht um eine Video Ausgabe! Ich will an alle Daten ran außer den Video Signalen. Die Ausgabe der Texte erfolgt auf einem Display. Mpeg und ACC Dekodierung (Audio) soll später auch rein. Die Prozessor Leistung kann ich nur nicht abschätzen. Wird wohl was größeres sein müssen und da ist das 2. Problem. Ich will das Teil noch selber Löten können. So ein OMAP3 wäre mit Sicherheit auch in der Lage Video mit zu machen aber, wie soll ich den auflöten? Ob da nun Linux drauf läuft, ein FreeRTOS oder kein OS ist mir egal. Hat da jemand schon mal was in diese Richtung gemacht und kann mir ein paar Tipps geben? Dirk
Wie viele Streams willst du gleichzeitig verarbeitet? Willst du also den kompletten Transponter auswerten order nur 1 aktiven Sender?
Dann sollte eigentlch jeden CPU reichen (erstmal ohne MPEG) denn das sind wirklich nicht viele Daten die da kommen. Wenn du später mit MPEG arbeiten willst, dann solltest du die CPU daran orientieren. Der Rest fällt dann mit ab.
Die angemessene Lösung ist hier ein kleiner bis mittelgroßer FPGA (Spartan 3 S 50 oder 200), der mit einem mittelgroßen Controller (AT mega 128) zusammenarbeiten. Da der TS heftig schnell kommt, machst du die Filterung nach PID im FPGA. Dann im FPGA ein wenig puffern und mit dem Controller zur Anzeige bringen. Für das was du vorhast, sollte diese Konfiguration reichen. Die Datenstruktur des Programmstromes/Transportstromes kennst du?
Was denn nun? Wenig oder viele Daten? Wenn ich mich nur nach dem Mpeg richten brauche, würde ein Cortex M3 ja schon reichen. Glaube ich aber nicht so richtig, wenn ich "Bürovorsteher" glauben darf. Die Lösung mit einem FPGA ist sehr interessant, nur kenne ich mich mit einem FPGA absolut nicht aus. Habe nicht mal eine Idee was ich da wie rein bekommen kann. Ein AVR ist zwar schön, habe auch alle Tools dafür. Aber ich würde dann doch zur Sicherheit lieber einen ARM7 oder grösser nehmen. Die Struktur kenne ich nicht auswendig habe aber passende Dokumente. Fertige Software wäre zwar noch besser, aber man kann halt nicht alles haben. Erst mal die Hardware bauen und wenn ich wirklich einen FPGA nehmen muss dann wird das ein längeres Projekt.
Dirk schrieb: > Was denn nun? Wenig oder viele Daten? das kommt auf das "(Modul von ALPS)" an. Liefert das Modul den kommpletten Transponder oder kann man dem Modul sagen welche PID man haben will. Einmal kommen SEHR viele daten raus einmal nur die gewünschten.
Dirk schrieb: > Es kommt alles raus, da ist kein Daten Filter drin. dann musst die CPU mit ca. 40Mbit/s zurechtkommen. Das ganze in form von 188byte Paketen. Bei jeden Packet steht am Anfang die ID, daran kannst du erkennen ob du das Packet brauchst.
> Fuer ein PID filter fuer ein/zwei/drei PIDs reicht schon ein CPLD. Nein, du brauchst mindestens noch einen Pufferspeicher für die herausgefilterten Blöcke, die du dann ganz geruhsam mit dem Controller auslesen kannst. Ein Spartan XC3S50AN ist außerdem billiger als ein dafür ausreichender CPLD.
Es sieht also so aus das ich mich in die wunderbare Welt der FPGA Programmierung einarbeiten darf. Auf so was war ich jetzt nicht eingestellt, aber wenn es nicht anders geht muss ich da wohl oder übel durch. Hoffe nur das das nicht so teuer wird, ein GCC wird es hierfür wohl nicht geben oder?
Dirk schrieb: > Es sieht also so aus das ich mich in die wunderbare Welt der FPGA > Programmierung einarbeiten darf. > Auf so was war ich jetzt nicht eingestellt, aber wenn es nicht anders > geht muss ich da wohl oder übel durch. warum? wenn die CPU schnell genug ist braucht man dafür keinen FPGA. das ist denn zwar kein µC mehr aber eine ebbended ARM sollte das ohne Probleme schaffen.
Habe selber mal nach gerechnet. 40Mbit/s in Form von 188byte Paketen ist sportlich aber mir einer entsprechenden Hardware (UART SPI ?? ) auch von einem AVR gerade noch empfangbar (nix mit auswerten). Wenn ich jetzt von Atmel einen ARM7 / Cortex M3 nehmen würde, wo könnte ich die Daten rein holen?
Oh im Datenblatt (ALPS) steht die Pin Belegung. Die Daten kommen 8 Bit Parallel raus mit Takt und allem was sonst so gebraucht wird. Da sollte ein DMA Transfer in den Prozessor möglich sein. Muss doch noch mal das komplette Zeug mir ansehen. vielleicht ist ja doch ein Filter drin und ich habe den immer nur übersehen.
Die Tuner, die ich bisher in der Hand hatte, hatten nie einen Filter. Da kommt der ganze Transponder "runter". Man konnte nur umschalten zwischen serieller oder 8-bit paralleler Ausgabe. Das Demuxen und PIDs-filtern hat dann immer der angeschlossene Decoder-Chip gemacht. Das ist wirklich eine nette Aufgabe für ein FPGA. Halt uns bitte auf dem Laufenden! Gruß, Jörg
Das das eine super Aufgabe für einen FPGA ist Glaube ich dir sofort. Nur leider kenne ich mich damit nicht aus. Ich werde somit nicht um ein reines Prozessorsystem herum kommen. Auch wenn die FPGA Lösung mich richtig reizen würde. Aber ich wollte auch irgendwann damit fertig werden und nicht in 1/2 Jahr das Projekt verzweifelt aufgeben. Nur weil ich dann immer noch nicht den FPGA fertig habe. Da kommt lieber ein dicker ARM dran und gut ist. Da kann ich wenigstens was machen und die Tools habe ich auch. Gut fasse ich mal zusammen: - Modul direkt anbinden (Passendes Hardware Interface aussuchen) - Muss über DMA rein kommen - Prozessor muss fix sein Na da habe ich doch schon mal einige Aufgaben die ich abarbeiten muss. Dann das Layout und dann wird es sowieso noch lustig mit der Software. Mal sehen was ich so bei den Dreambox und Linux Herren so finde zu diesem Thema. Aber das kommt erst später dran, erst muss die Hardware auf dem Tisch liegen und die Daten gefiltert rein kommen.
Sag uns doch mal um welchen DVB Chips von ALPS es hier geht. Ich hatte das ganze bis jetzt nur am PC gemacht - dort kommen die Daten von Treiber auch nur aus einem device, nur konnte man dem Treiber die PIDs mitgeben und er hat es schon gefiltert. Keine Ahnung ob das ganze in Hardware oder Software gemacht wurde.
> Ich will das Teil noch selber Löten können.
Wozu löten ?
Es gibt doch ausreichend viele Set-Top-Boxen für kleines Geld
mit ausreichend leistungsfähigem Prozessor und Linux als
modifizierbarem System, ich sag mal DreamBox.
Das ganze hat auch noch den Vorteil, daß man neben dem
Erkennnisgewinn was nützlches draus machen könnte.
Ich habe gestern mich weiter schlau gemacht, weil mit die Idee mit dem FPGA nicht aus dem Kopf gehen wollte. Kann man nicht gleich alles im FPGA machen? Es gibt anscheinend etliche fertige Module die man nur irgendwie zusammen bauen muss. Wie gesagt habe ich davon noch keine Ahnung, aber es wäre schon super wenn die ganzen Zeitkritischen Bereiche sozusagen in Hardware ablaufen. Dann noch ein kleiner AVR mit drauf um das ganze zu steuern. Stellt sich dann nur die Fragen wo das rein passt (Lötkolben kompatibel) und die man das programmiert? Was meint Ihr ist das machbar oder sollte man als noch leihe lieber die Finger lassen. VG, Dirk
> Kann man nicht gleich alles im FPGA machen? Die Auswertung der ganzen Tabellen, wo was im PS/TS zu finden/suchen ist, sollte man besser einem Controller überlassen, schon weil dessen SW einzeln und harwareunabhängig entstört werden kann. Ganz tolle Hirsche (dazu gehöre ich allerdings nicht), implementieren den Controller natürlich im FPGA. > Es gibt anscheinend etliche fertige Module die man nur irgendwie > zusammen bauen muss. Darin besteht im allgemeinen die Tätigkeit des gemeinen Ingenieurs. > Stellt sich dann nur die Fragen wo das rein passt (Lötkolben kompatibel) > und die man das programmiert? Das habe ich dir schon gesagt. Zieh dir als erstes mal die Empfehlung H.222 der ITU-T bzw. ISO/IEC 13818-1 rein. Das ist nur der Anfang. Dann gibt es noch massenweise Empfehlungen der ETSI. Wenn du gut bist und viel Zeit hast, könntest du irgendwann zu irgendwelchen Resultaten kommen. Programmierung, FPGA-Entwurf und parallel dazu Detailkenntnis der Dokumentation halte ich für ein sehr ehrgeiziges Projekt für einen Anfänger. Andererseits - irgendwomit muss man ja anfangen.
Bürovorsteher schrieb: > Zieh dir als erstes mal die Empfehlung H.222 der ITU-T bzw. ISO/IEC > 13818-1 > rein. Vorsicht: Lang und ziemlich unverdaulich!
Habe fast alle wichtigen Dokumente, nur noch nicht alle gelesen. Nun ja, Anfänger bei FPGA bin ich. Aber mache seit 25Jahren Software und Hardware, sollte damit nicht ganz als unerfahren durch gehen. Auf der anderen Seite, ach habt gewonnen, warum sich das leben schwer machen. Die FPGA Sachen laufen mir nicht weg und ist dann für ein privates Spielprojekt zu aufwendig. Wenn alles läuft kann ich immer noch mich daransetzen und was optimieren mit einem FPGA. Melde mich so in ca. 3-5 Monaten wenn ich was vorzuweisen habe. Danke, Dirk
> Aber mache seit 25Jahren Software und Hardware, sollte damit nicht ganz > als unerfahren durch gehen. Sag das gefälligst gleich! Sonst hält man dich für völlig ahnungslos. Ich habe das PS/TS-Fernsehzeugs ziemlich lange (15 Jahre) seit den Ur-anfängen (Anfang der 90er) gemacht und empfinde es in Nachhinein als ziemlich öde. Zumal - am Ende stellst du fest, das im billigsten Fernseher von Aldi bereits alles drin ist. Meine Empfehlung: FPGA! Faszinierend, was du dort mit wenigen Zeilen in VHDL alles für Unheil anrichten kannst.
Das Problem ohne FPGA ist schlicht und einfach, dass man in gängigen Controllern keine dedizierte Hardware-Unit hat, die sich um das Einlesen und buffering der TS-Daten kümmern könnte. D.h. man muss das in Software machen und das geht nicht so einfach, weil der Stream halt so schnell ist, dass dein ganzes TS-Paket fürn Müll ist wenn da irgendwann mal ein Interrupt dazwischenfunkt. Annahme: 40MBit, parallel, 8Bit. Macht 5MHz. Dann gibts da (neben sync) noch den TS_clock vom tuner, den du mit dem controller mit >=10MHz samplen musst um zu entscheiden, wann die Daten gültig sind. Mit einem Cortex-M3 auf 70MHz hast Du da gerade noch 7 Takte zwischen 2 samples für Auswertung/Verarbeitung/etc. - ARM mit 100MHz macht die Sache auch nicht realisierbarer ohne dedizierte Hardware (FPGA).
dvbbla schrieb: > Annahme: 40MBit, parallel, 8Bit. Macht 5MHz. Dann gibts da (neben sync) > noch den TS_clock vom tuner, den du mit dem controller mit >=10MHz > samplen musst um zu entscheiden, wann die Daten gültig sind. > Mit einem Cortex-M3 auf 70MHz hast Du da gerade noch 7 Takte zwischen 2 > samples für Auswertung/Verarbeitung/etc. das vesteht ich nicht, wenn die Daten parallel ankommen mit 5Mhz dann habe ich auch auch mehr als 10Takte zeit für ein byte. und das nur zum ablegen in einem buffer. Auswerten kann ich es ja asyn in der zeit wo man auf das nächste byte wartet. Das mit dem Clock sollte man doch mit externen beschaltung so hinbekommen, das man bei jeden senkrechten Flankte 8bit übernehmen kann. viele Controller haben doch schon einen DMA modus, das muss man sich auch nicht mehr um ein einzelnes byte kümmern.
@Bürovorsteher Man muss ja nicht immer alles gleich verraten. Ohne DMA Eingang klappt das nicht, so viel ist klar. Jedes einzelne Byte selber abholen geht beim besten nicht. Wenn ein Datenblock drin ist den Puffer umschalten und dann hat man wieder etwas Zeit die Daten sich anzusehen. Anders hat man keine Chance das mit einem Prozessor zu machen. Ob ein Cortex 3 dafür reicht wird das Datenblatt und Tests zeigen. Nach oben gibt es zum Glück noch einige Modelle die ich nehmen kann. Vielleicht brauche ich auch 2 Prozessoren um den FPGA in Software zu bauen. Dann hätte ich einen der die Daten Filtert und einen der die Daten auswertet. Ist auch noch eine Möglichkeit. Diesen Bus kann man dann auch auf 32bit bauen um mehr Performance zu bekommen. Es gibt somit noch genug Potenzial.
Ich werde mir doch mal die FPGA Sachen ansehen. Hier gibt es ein nettes Board das ich mir mal aufbauen werde. Beitrag "Meinung zu meinem Spartan 3 Eval Board" Wenn ich merke das ich nicht zurecht komme oder ich keine guten Tools finde oder sonst was damit ist, verfolge ich wieder die 1-2 Prozessor Strategie. VG, Dirk
Was haltet Ihr von diesem Prozessor AT32UC3A0512 für diese Aufgabe? Die Atmel Cortex m3 habe alle kein Ethernet, und einen normalen ARM7 traue ich das Thema nicht zu. Alternativ würde ich einen ARM9 nehmen.
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.