WIDI - Trådløs HDMI ved hjelp av Zybo (Zynq Development Board): 9 trinn (med bilder)

2024 Forfatter: John Day | [email protected]. Sist endret: 2024-01-30 11:24

Har du noen gang ønsket at du kunne koble TV -en til en PC eller bærbar datamaskin som en ekstern skjerm, men ville ikke ha alle de irriterende ledningene i veien? I så fall er denne opplæringen bare noe for deg! Selv om det er noen produkter ute som oppnår dette målet, er et DIY -prosjekt mye mer tilfredsstillende og potensielt billigere.

Dette konseptet er forskjellig fra produkter som chromecast, ettersom det er ment å ta stedet for en HDMI -ledning som kobles til en skjerm i stedet for å være en streaming -enhet.

Prosjektet vårt ble opprettet som et avsluttende prosjekt for et Real Time Operating Systems -kurs ved California State Polytechnic University, San Luis Obispo.

Målet med prosjektet er å bruke to Digilent Zybo-kort til å fungere som det trådløse kommunikasjonsgrensesnittet mellom en HDMI-sender (PC, blu-ray, etc) til en HDMI-mottakerenhet (stasjonær skjerm, projektor, TV, etc).

Den ene Digilent Zybo blir koblet via HDMI til overføringsenheten, og den andre vil bli koblet via HDMI til mottakerenheten.

Den trådløse kommunikasjonen vil skje ved å bruke et trådløst lokalnettverk dedikert til senderen og mottakeren, uten å bli dirigert gjennom en hjemmeruter eller annen slik enhet. Den trådløse modulen som brukes for dette prosjektet er tplink wr802n nanorouter, hvorav den ene fungerer som et tilgangspunkt for å etablere nettverket og den andre for å fungere som en klient for å koble til nettverket. Hver nanorouter blir koblet via ethernet -kabel til et av Zybo -kortene. Når de er koblet til disse ruterne, vil enhetene kommunisere via TCP som om de var koblet til med en enkelt ethernet -kabel (noe som betyr at den eneste konfigurasjonen som trengs for å etablere en tilkobling, er IP -adressen til klienten).

Selv om målet med prosjektet var å legge til rette for en strøm på 1080x720 video @ 60Hz, var dette ikke oppnåelig på grunn av båndbreddebegrensninger i det trådløse nettverket og mangel på sanntids videokomprimering for å redusere dataene som kreves for å sende. I stedet fungerer dette prosjektet som rammen for fremtidig utvikling for å nå dette målet, ettersom det har sterkt begrensede begrensninger i bildefrekvens for å streame HDMI -data på riktig måte etter hensikten.

Prosjektkrav:

2x Digilent Zybo Development Boards (må ha minst en HDMI -port)

2x HDMI -kabler

2x mikrousb -kabler (for å koble Zybo til PC for utvikling)

2x tplink wr802n nanorouters (inkludert adtl. 2x microusb- og vegguttak)

2x ethernet -kabler

*** Merk: Denne opplæringen forutsetter kjennskap til Vivado designsuite og erfaring med å lage et nytt prosjekt og blokkdesign. ***

Trinn 1: Konfigurer Zynq programmerbar logikk for sender

Vår tilnærming til å utvikle den programmerbare logikken til senderen var å utføre en hdmi-til-hdmi-gjennomgang fra PC for å overvåke ved hjelp av to Video Direct Memory Access (VDMA) blokker, en for skrive og en for lesing.

Begge er valgt for frittløpende, 3 rammebuffermodus (0-1-2). Siden videokjernen er optimalisert for 60 bilder per sekund, betyr dette at VDMA vil skrive eller lese for en ny ramme hver 16,67 ms i denne rekkefølgen: 0, 1, 2, 0, 1, 2, 0, 1, 2. DDR -minneplasseringene for hver ramme er forskjellige for de to VDMA -ene fordi de ikke lenger er synkronisert med hverandre. I stedet brukes en maskinvaretimer (TTC1), konfigurert for 60 Hz, for å synkronisere bevegelsen av data mellom de to minnestedene.

Bildet ovenfor viser 3 rammer, deres dimensjoner og mengden minne som hver krever (til høyre for rammen). Hvis vi tilordner skrive -VDMA til disse minnestedene, kan vi tilordne de lesede VDMA -minnestedene utover dette settet, si starter med 0x0B000000. Hver ramme består av 1280*720 piksler, og hver piksel består av 8 biter rød, grønn og blå for totalt 24 biter. Dette betyr at en ramme består av 1280*720*3 byte (2,76 MB).

Inne i timeren IRQ, som er beskrevet i VDMA -driveroppsettet, vil håndtere kopiering av data mellom de to VMDA -minnestedene. VDMA gir en peker til gjeldende ramme som skrives til eller leses fra. Rammen er representert med en bestemt grå kode, som konverteres til programvare. De grå kode definisjonene for en 3 rammebuffer konfigurasjon finnes i AXI VDMA produktguide i vedlegg C.

Dette tillater oss å kopiere innholdet som skrives til minnet uten å lese fra en ramme som det for tiden skrives til.

*** Vær oppmerksom på at den avleste VDMA ikke brukes når du sender data over det trådløse nettverket. Det eneste formålet er å kontrollere at kopiering av minne fra skrive -VMDA fungerer som det skal. Les VMDA bør deaktiveres. ***

Her er trinnene for å lage senderblokkens designblokk:

1. Når du oppretter et nytt prosjekt, er det en god idé å tilordne en brikke eller brett til prosjektet. Denne lenken beskriver hvordan du legger til nye brettfiler i Vivado -katalogen og knytter det korrekte kortet til prosjektet ditt. Det vil være nyttig når du legger til Processing System -blokken og overgår fra maskinvare til programvare (SDK -side).

2. Legg til følgende blokker:

   • dvi2rgb
   • Video inn til Axi4-stream
   • Timing Controller
   • axi4-stream for å vide ut
   • rgb2dvi
   • AXI VDMA x2
   • AXI GPIO x2
   • Klokkeveiviser
   • Konstant
   • Zynq -behandlingssystem
3. Når du legger til behandlingssystemet, klikker du på "Kjør blokkautomatisering" fra den øverste grønnfargede linjen og kontrollerer at alternativet "Apply Board Preset" er valgt. La alt annet stå som standard.
4. Bilder av hvert blokkkonfigurasjonsvindu finnes på bildene ovenfor. Hvis du ikke ser et bilde for et bestemt vindu, er det bare å la det stå som standard.

5. Begynn å konfigurere Zynq -behandlingssystemet:

   • I PS-PL-konfigurasjon AXI Non Secure Enable GP Master AXI, aktiver M AXI GP0-grensesnitt
   • I PS-PL-konfigurasjon HP Slave AXI-grensesnitt, aktiver både HP0 og HP1
   • I MIO -konfigurasjonen Sørg for at ENET0 er aktivert under I/O -utstyr, deretter Application Processor Unit, aktiver Timer0
   • I Clock Configuration PL Fabric Clocks, aktiver FCLK_CLK0 og sett til 100 MHz.
   • Klikk Ok
6. Før du klikker på "Kjør tilkoblingsautomatisering", må du koble til videoblokkene som vist i TX -blokkdesignbildet ovenfor. Du vil gi konstanten nytt navn til VDD og sette verdien til 1. Koble videoblokkene tilsvarende.
7. Gjør HDMI TMDS -klokken og datapinnene eksterne på rgb2dvi- og dvi2rgb -blokkene
8. Lag en inngangs- og utgangsport for hot plug detect -signalet (HPD) og koble dem sammen, disse er definert i begrensningsfilen

9. Pikselklokken gjenopprettes fra TMDS_Clk_p, som opprettes i begrensningsfilen. Dette vil være 74,25 MHz i henhold til 720p oppløsning. Det er viktig å koble pikselklokken (fra dvi2rgb -blokken) til følgende pinner:

   • vid_io_in_clk (vid inn til axi stream block)
   • vid_io_out_clk (aksi -strøm til vid ut -blokk)
   • clk (Timing Controller)
   • PixelClk (rgb2dvi)
10. *** Merk: For øyeblikket for å aktivere gjenoppretting av pikselklokker, må HDMI rx- og tx -kontaktene kobles til en aktiv kilde/vask. En vei rundt dette er å skille video rx og tx blokker til forskjellige klokkedomener (med andre ord, generer en ny klokke på 74,25 MHz for å mate til tx -blokken). ***
11. Sett deretter opp klokkeveiviseren slik at du har en 100 MHz inngang (global bufferkilde) og 3 utgangsklokker @ 50 MHz (AXI-Lite klokke), 150 MHz (AXI4-Stream klokke), 200 MHz (dvi2rgb RefClk pin).
12. Koble FCLK_CLK0 -behandlingssystemnålen til klokkeveiviserinngangen
13. Klikk på "Kjør tilkoblingsautomatisering" fra den grønne linjen øverst i designvinduet. Det er en god idé å gjøre dette for en blokk om gangen og følge TX -blokkdesignbildet ovenfor.
14. Verktøyet vil prøve å legge til AXI Interconnect, som fungerer som master/slave-sammenkoblingen for blokkene som bruker AXI-Lite-bussen (VDMA og GPIO).
15. Det vil også legge til AXI SmartConnect, som fungerer som master/slave-sammenkoblingen for AXI4-Stream- og High Performance-prosessorgrensesnittene som brukes av VDMA (Stream to Memory Map og vice versa).
16. Verktøyet vil også legge til en prosessorsystemtilbakestilling. Sørg for at dette bare er koblet til VDMA, GPIO og prosessorelaterte blokker. Ikke koble den til noen videoblokker (dvs. dvi2rgb, timing -kontroller, video til å streame etc.)
17. Når tilkoblingsautomatiseringen er fullført, må du kontrollere at tilkoblingene samsvarer med TX -blokkens designbilde. Du vil legge merke til en ekstra System ILA -blokk som ikke har blitt nevnt. Dette er bare for feilsøking og er ikke nødvendig for nå. Den bruker 150M Prosessor Reset, så det er heller ikke nødvendig. Uansett hvor du ser små grønne "bugs" på busser, er det på grunn av ILA og kan ignoreres.
18. Det siste trinnet er å høyreklikke på blokkdesignen i prosjektkildetreet og velge "Create HDL Wrapper." Hvis du planlegger å legge til logikk i innpakningen, blir den overskrevet hver gang dette velges.
19. Se delen VDMA Driver Setup for informasjon om SDK -siden.

Klokker og tilbakestillinger

Jeg har funnet ut at de viktigste aspektene ved ethvert programmerbart logisk prosjekt er nøye vurdering av klokkedomener og tilbakestillingssignaler. Hvis de er riktig konfigurert, har du et godt forsøk på å få designet til å fungere.

Pixel Clock og Timing låst

For å bekrefte at visse signaler er aktive, er det en god idé å knytte disse signalene til lysdioder (klokker, tilbakestillinger, låser osv.). To signaler som jeg syntes var nyttige å spore på senderkortet var pikselklokken og det "låste" signalet på AXI4-Stream til video ut-blokken, som forteller deg at videotimingen har blitt synkronisert med tidskontrolleren og videokilden data. Jeg har lagt til en viss logikk i designblokkomslaget som sporer pikselklokken ved hjelp av PixelClkLocked -signalet på dvi2rgb -blokken som en tilbakestilling. Jeg har lagt ved filen som hdmi_wrapper.v her. Begrensningsfilen er også vedlagt her.

Trinn 2: Konfigurer Zynq programmerbar logikk for mottaker

Den programmerbare logikkblokken for mottakeren er enklere. Hovedforskjellen, bortsett fra de manglende hdmi -inngangsblokkene, er fraværet av en gjenopprettet pikselklokke. Av den grunn må vi lage vår egen fra klokkeveiviseren. Denne designen bør gjøres i et eget prosjekt fra senderen. For vårt formål fulgte mottakerprosjektet Zybo 7Z-20-kortet mens senderen fulgte Z7-10-kortet. FPGA -ene på brettene er forskjellige, så vær forsiktig.

Her er trinnene for å lage mottakerens designblokk:

1. Legg til følgende ip -blokker i designet ditt:

   • Timing Controller
   • AXI4-Stream til Video Out
   • RGB til DVI
   • AXI VDMA
   • AXI GPIO
   • Behandlingssystem
   • Klokkeveiviser
   • Konstant (VDD satt til 1)
2. Følg det samme mønsteret for å konfigurere disse blokkene som senderen. Bilder for de bemerkelsesverdige forskjellene i konfigurasjon har blitt inkludert her. De andre forblir de samme som senderen.
3. Konfigurer VDMA for dette designet som bare lesekanal. Deaktiver skrivekanalen.

4. Klokkeveiviseren bør konfigureres for følgende utganger:

   • clk_out1: 75 MHz (pikselklokke)
   • clk_out2: 150 MHz (strømklokke)
   • clk_out3: 50 MHz (axi-lite klokke)
5. Koble til videoblokkene som vist i RX -blokkdesignbildet.
6. Kjør deretter tilkoblingsautomatiseringen, som vil legge til AXI Interconnect, AXI SmartConnect og System Reset -blokker og prøve å gjøre de riktige tilkoblingene. Gå sakte her for å sikre at den ikke utfører uønskede tilkoblinger.
7. Gjør HDMI TMDS -klokken og datapinnene eksterne på rgb2dvi -blokken
8. Du trenger ikke noe hot plug -signal på dette designet.

Trinn 3: Konfigurer VDMA -driver

Oppsett for de forskjellige blokkene som er konfigurert via AXI-Lite-grensesnittet, gjøres best ved å bruke demoprosjekter som følger med BSP som referanse. Etter å ha eksportert designmaskinvaren og lansert SDK fra Vivado, vil du legge til en ny brettstøttepakke og inkludere lwip202 -biblioteket i BSP -innstillingsvinduet. Åpne system.mss -filen fra BSP, og du vil se de eksterne driverne som er tilstede fra blokkdesignet ditt. Alternativet "Importer eksempler" lar deg importere demoprosjekter som bruker disse eksterne enhetene og dermed vise deg hvordan du konfigurerer dem i programvare ved hjelp av de tilgjengelige Xilinx -driverne (se vedlagt bilde).

Dette var metoden som ble brukt for å konfigurere VDMA, Timer & Interrupt og GPIO. Kildekoden for både overføring og mottak er inkludert her. Forskjellene er nesten utelukkende i main.c.

*** MERK: Siden systemet ikke er fullt funksjonelt når vi skriver denne opplæringen, inkluderer ikke kildekoden i denne delen den trådløse nettverkskoden. Flere feil må adresseres som et resultat av å kombinere videokjerneoverførings-/mottaksprosjekter med prosjekter for overføring/mottak av nettverk. Derfor behandler denne opplæringen dem separat for øyeblikket. ***

TX Interrupt Handler Function (IRQHandler)

Denne funksjonen leser de grå kodene fra både lese- og skrive -VDMA -ene via GPIO -blokkene. De grå kodene konverteres til desimal og brukes til å velge rammebase -minneplassering for gjeldende ramme. Rammen som er kopiert er den forrige rammen til den som VDMA skriver til (f.eks. Hvis VDMA skriver til ramme 2, kopierer vi ramme 1; hvis vi skriver til ramme 0, pakker vi inn og leser fra ramme 2).

Funksjonen tar bare opp hver 6. ramme for å redusere bildefrekvensen til 10 Hz i stedet for 60 Hz. Den øvre grensen for nettverket er 300 Mbps. Ved 10 bilder per sekund kreves en båndbredde på 221,2 Mbps.

Hvis du kommenterer/fjerner kommentarer til to linjer i denne funksjonen, kan brukeren bytte til HDMI-passthru-modus for feilsøkings-/testformål (koden kommenteres for å indikere de riktige linjene). Den kopierer for øyeblikket rammen til et minnested som brukes av ethernet -koden.

RX Interrupt Handler -funksjon (IRQHandler)

Denne funksjonen er veldig lik TX -funksjonen, men den kopierer fra en 2 -buffer FIFO som brukes av ethernet til å skrive innkommende data til. Ethernet -koden indikerer hvilken ramme det skrives til i FIFO, data blir kopiert fra den motsatte rammen. Dataene kopieres til rammen rett bak den som leses av VDMA for å unngå å rive.

Trinn 4: Konfigurer Nanorouter -nettverket

For å opprette et nettverk ved hjelp av TPlink nanoroutere, slå dem på individuelt og koble til standard wifi SSID for enhetene. Du finner mer informasjon om konfigurasjonsinnstillingene for denne enheten gjennom brukerhåndboken for enheten.

Sett opp en av enhetene som et tilgangspunkt, dette vil fungere som den primære tilkoblingen for nettverket. Sørg for å gi nettverket et navn, og noter navnet, og deaktiver DHCP (vi vil ikke at ruteren skal konfigurere IP -adressene dynamisk, vi vil at tanksender og mottaker Zybo -kort skal sette sine IP -adresser selv slik at de er konsistente). Etter konfigurering må du kontrollere at enheten starter på nytt og etablerer dette nettverket.

Sett opp den andre enheten som en klient, og sørg for at den kobles til nettverks -SSID -en du konfigurerte med den første nanorouteren. Sørg nok en gang for at DHCP er deaktivert for klienten.

Når klienten er ferdig og startet på nytt, bør den koble til tilgangspunktet nanorouter (hvis den ikke gjør det, er det sannsynligvis et problem i konfigurasjonen av en av enhetene). Du vil legge merke til at LED -lyset på klienten vil være fast når den har koblet seg til tilgangspunktet.

Tilgangspunktet nanorouter LED vil trolig fortsette å blinke på dette tidspunktet, dette er greit! Det blinkende lyset betyr at den ikke er koblet til en annen enhet fra sin ethernet -port, og når den er koblet til en konfigurert Zybo, vil LED -lampen forbli konstant for å indikere en vellykket nettverkstilkobling.

Nå som vi har våre nanorouters -oppsett, har vi et trådløst nettverk som lar oss kommunisere gjennom. En viktig merknad er at vår konfigurasjonsmetode for nanorouterne (som tilgangspunkt og klient) lar oss kommunisere fra det sendende Zybo -kortet til det mottakende Zybo -kortet som om de to var koblet til med en enkelt ethernetledning. Dette gjør vårt nettverksoppsett mindre vanskelig, ettersom alternativet sannsynligvis vil inneholde konfigurering av Zybo -kortene for å koble til serveren eksplisitt sammen med den tiltenkte tilkoblingen.

Når begge enhetene er konfigurert, er nanorouterne konfigurert og klare til å bli implementert i ditt WIDI -nettverk. Det er ingen spesifikk sammenkobling mellom nanorouterne og Zybo -kortene, ettersom enten tilgangspunktet eller klienten vil fungere for enten overførings- eller mottaksenheten.

Trinn 5: Sett opp Zynq -behandlingssystem for dataoverføring via Ethernet

For å overføre HDMI -dataene fra det ene Zybo -kortet til det andre, må vi inkludere en Ethernet -protokoll sammen med vår VDMA -driver. Målet vårt her er å streame individuelle videorammer gjennom Ethernet -periferienheten i behandlingssystemet, til en bestemt hastighet som er i samsvar med nettverksbåndbredden. For prosjektet vårt brukte vi TCP levert av bare metall LwIP API. Siden begge prosjektmedlemmene er relativt uerfarne med nettverksverktøy, ble dette valget gjort uten å fullt ut innse implikasjonene og begrensningene som er forbundet med TCP. Det største problemet med denne implementeringen var den begrensede båndbredden og det faktum at den egentlig ikke er designet for å dampe store datamengder. Alternative løsninger for å erstatte TCP og forbedre tbe i dette prosjektet vil bli diskutert senere.

En kort beskrivelse av TCP med LwIP: Data sendes over nettverket i pakker med størrelse tcp_mss (TCP maksimal segmentstørrelse), som vanligvis er 1460 byte. Å ringe tcp_write vil ta noen data referert av en peker og konfigurere pbufs (pakkebuffere) for å lagre dataene og gi en struktur for TCP -operasjonene. Maksimal datamengde som kan stå i kø på en gang er satt til tcp_snd_buf (TCP -senderbufferplass). Siden denne parameteren er et 16 -biters nummer, er vi begrenset til en sendebufferstørrelse på 59695 byte (det er noe nødvendig utfylling i sendebufferen). Når dataene har stått i kø, kalles tcp_output for å begynne å overføre dataene. Før du sender det neste datasegmentet, er det avgjørende at alle de tidligere pakkene har blitt overført. Denne prosessen utføres ved hjelp av recv_callback -funksjonen, da dette er funksjonen som kalles når kvitteringen er sett fra mottakeren.

Å bruke eksempelprosjektene i Vivado SDK er veldig nyttig for å lære hvordan LwIP TCP -operasjonen er, og er et godt utgangspunkt for å starte et nytt prosjekt.

Fremgangsmåten for WiDi -overføringsenheten er som følger:

1. Initialiser TCP-nettverket ved hjelp av bare metall-LWIP-driverfunksjonsanrop.
2. Angi eventuelle tilbakeringingsfunksjoner som er nødvendige for nettverksoperasjoner.
3. Koble til WiDi -mottakeren ved å koble til dens IP -adresse og port (vår konfigurasjon: Mottakerens IP er 192.168.0.9, koble til port 7).
4. Når VDMA -drivertimeren utløper, angir du TX ISR.
5. Bestem gjeldende rammebuffer for tilgang basert på den grå VDMA -koden
6. Sett det første datasnittet i kø i TCP -sendingsbufferen
7. Legg ut dataene, og oppdater lokale variabler for å holde oversikt over hvor mye data som er sendt av gjeldende ramme.
8. Når du har mottatt den mottatte tilbakeringingen (funksjonsanrop foretatt etter at senderen har mottatt en bekreftelse på datahenting), må du sette det neste datasegmentet i kø.
9. Gjenta trinn 7 og 8 til hele rammen er sendt.
10. Gå tilbake til inaktiv tilstand for å vente på neste timeravbrudd for å indikere at en ny ramme er klar (Tilbake til trinn 4).

Sørg for å sette opp LwIP -innstillingene for brettstøttepakken som vist på bildet ovenfor. Alle verdiene er standard bortsett fra tcp_snd_buf, tcp_pueue_ooseq, mem_size, memp_n_tcp_seg. Vær også oppmerksom på at detaljert feilsøking kan oppnås ved å endre BSP -parameterne for debug_options -gruppen.

Trinn 6: Sett opp Zynq Processing System for datamottak via Ethernet

Zybo -utviklingsbordet som vil fungere som den trådløse mottakeren vil fungere på samme måte som overføringsenheten. Brettstøttepakkeinnstillingene for LwIP vil være identiske med dem i forrige trinn.

Enheten vil ta inn pakker som inneholder videorammesegmentene fra nanorouteren, og den vil kopiere videorammedataene til trippelrammebufferplassen for den mottakende VDMA. For å unngå å overskrive data, brukes en dobbel databuffer (vi vil referere til som nettverksbufferen) når du samler inn data fra nanorouteren, slik at nettverkstrafikk kan fortsette å strømme inn mens den forrige hele videorammen kopieres inn i VDMA -buffer.

Prosedyren for WiDi -mottaksenheten krever to oppgaver, hvorav den ene mottar ethernet -data, og den andre er å kopiere videorammer fra nettverksbufferen til VDMAs trippelrammebuffer.

Ethernet -mottaksoppgave:

1. Initialiser TCP-nettverket ved hjelp av bare metall LWIP-driverfunksjonsanrop (oppsett med IP-adresse som senderen vil koble til, 192.168.0.9 i vår)
2. Angi eventuelle tilbakeringingsfunksjoner som er nødvendige for nettverksoperasjoner.
3. Etter mottatt ethernet -pakke, kopierer du pakkedata til gjeldende nettverksbuffer, øker nåværende akkumulerte data.
4. Hvis pakken fyller nettverksrammebufferen, fortsetter du til trinn 5 og 6. Ellers går du tilbake til trinn 3 fra denne oppgaven.
5. signal om at VDMA triple frame buffer -oppgaven skal kopiere fra den nylig ferdige nettverksbufferen.
6. Bytt til den andre nettverksbufferen og fortsett å samle inn data via ethernet.
7. Inaktiv til ny ethernet -pakke er mottatt (trinn 3).

Kopier nettverksbuffer til VDMA triple frame buffer:

1. Når VDMA -drivertimeren utløper, angir du RX ISR.
2. Bestem gjeldende rammebuffer for tilgang basert på VDMA grå kode.
3. Bestem hvilken nettverksbuffer som skal kopieres til VDMA -bufferen, og kopier dataene

Trinn 7: Koble Zybo -kortene til HDMI -kilden og HDMI -vasken

Koble nå til hdmi -kablene for både mottakeren og senderen, programmer FPGA -ene og kjør behandlingssystemet. Bildefrekvensen vil trolig være veldig treg, på grunn av den enorme overhead i LwIP -operasjonen og begrenset båndbredde. Hvis det er problemer, kobler du til via UART og prøver å identifisere advarsler eller feil.

Trinn 8: Alternative ideer for forbedring

Et stort problem for dette prosjektet var mengden data som trengs for å sende over wifi. Dette var forventet, men vi undervurderte virkningen dette ville ha og resulterte i mer av en serie bilder på en skjerm i stedet for en videofeed. Det er flere måter å forbedre dette prosjektet på:

• Videokomprimering i sanntid. Komprimering av den innkommende videomating ramme for ramme vil i stor grad redusere mengden data som må sendes over nettverket. Ideelt sett vil dette bli gjort i maskinvare (som ikke er en lett oppgave), eller det kan gjøres i programvare ved å bruke den andre ARM -kjernen til å kjøre en komprimeringsalgoritme (dette vil trenge ytterligere analyse for å sikre at timingen fungerer). Det er noen åpen kildekomprimeringskomponenter i sanntid vi fant på nettet, men de fleste er IP.
• Implementere Ethernet -strømmen i maskinvare, i stedet for programvare. Det var massevis av overhead på grunn av mangel på plass til å stå i kø for utgående data i senderen, på grunn av begrensningen på segmentstørrelsen. En mye mer effektiv prosess er å bruke AXI Ethernet IP med en FIFO -buffer eller DMA for å mate data inn i den. Dette vil redusere den ekstra bagasjen fra LwIP TCP og muliggjøre mer dataflyt.

Trinn 9: Tilgjengelighet

Det resulterende produktet av dette WiDi -prosjektet bør være et fullt integrert, kompakt par enheter som en bruker kan koble til en hvilken som helst HDMI -kilde og deretter senke videomaten til en skjerm med HDMI -funksjon trådløst. Enhetene vil inneholde Zynq-7000 SoC som finnes på Zybo-referansekortet og innlemme nettverksmaskinvaren som finnes i TP-Link nano-ruterne. Ideelt sett vil brukeren kunne kontrollere sendemodulen fra et diskret sted i måloperativsystemet, med lite behov for betydelig teknisk evne.

Sikkerhet og tilkobling

Enhetene bør også inneholde Transport Layer Security (TLS) og ha begrenset mulighet for automatisk tilkobling, både for personvern. Det er designernes hensikt å gjøre tilkoblingen med en skjerm over et trådløst grensesnitt til en bevisst handling på vegne av brukeren for å unngå feilaktig kringkasting av sensitivt materiale.

Nåværende status

Frem til dette punktet er prosjektets tilstand fremdeles veldig pågående. For at den nåværende sluttbrukeren skal ha nytte av denne opplæringen, må han eller hun ha en sterk teknisk forståelse av innebygd systemdesign og ha litt kjennskap til programmerbar maskinvare og innebygd programvare som fungerer sammen.

Dataene som sendes over nettverket er ikke kryptert på dette tidspunktet og antas å være en rå overføring av TCP/IP -pakker.

Videokjerneprosjektet ble vellykket testet for både overføring og mottak. På den annen side ble den trådløse forbindelsen mellom to zybo -kort opprettet og testrammedata ble sendt. Det er imidlertid fortsatt nødvendig å kombinere nettverkskoden til hvert videokjerneprosjekt og teste overføringen av faktiske videorammer.