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
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.
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.
