LED-snurra: Hur göra för att uppdatera bild i realtid.

[netrunner]

Hepp...

Jag funderar på att bygga en LED-snurra. En av dom saker jag vill kunna göra är att låta LED-snurran visa text och bilder från en PC. Tex, så skulle den kunna visa villken låt som winamp spelar, eller väder från SMHI.

Snurran ska således vara en ren display. 12bit hög och kanske 100bit lång, således 150byte.

Informationen överför man med IR, men hur ska programet seut?

Det kommer att finnas inkommande IR-data samtidigt som det finns data som ska skickas ut.

Måste man ha två PIC för att detta ska fungera, en för IR-data in och en som visar data på LED:sen. Finns det något smart knep för att både taemot data och samtidigt visa data på led:sen?

En fördröjning på 1sekund är kanske ok, men inte att snurran ska göra "start och stopp".

[sodjan]

> Finns det något smart knep för att både taemot data och samtidigt visa data på led:sen?

Samtidigt kan du inte göra någonting. Alla mikrokontrollers gör en sak i taget.

Däremot får du se till att den vid varje tilfälle gör rätt sak. D.v.s uppdaterar
snurran när det behövs och läser IR data när det behövs.

Det är svårt att säga något generellt, du får räkna på tider för olika
saker och processorcykler och försöka få ihop det hela.

Om det behövs en eller flera processorer beror helt på.
En "normal" enfärgad snurra bör klara sig med en processor, men jag
vet en RGB snurra som har 3 st dsPIC30 för beräkning av RGB värden
i realtid.

> En fördröjning på 1sekund är kanske ok,...

En fördröjning av vadå ?

[$tiff]

Problemet är överföringshastigheten för ett IR-baserat gränssnitt (vi snackar 38 kHz va?). Du kan glömma att överföra annat än stillbilder, det kan t.ex. mullemeck bekräfta (han överför data via IR i sin snurra). Vad du behöver är en seriellt kanal med lite större kaliber.

[sodjan]

Jag måste ha missat något, men jag såg inget om rörliga bilder i första inlägget...

[$tiff]

Jag har vild fantasi på kvällarna

Hursomhelst, enligt mullemecks apparat kan man vänta sig att en bild lätt tar över sekunden att överföra i råformat.

[Icecap]

Rörliga bilder visas med min. 18FPS (stumfilmskvalitet), med 150 * 8 * 18 blir det en kommunikationshastighet om 21600 baud. Då ett serieord egentligen är 10 bit (start + data + stopp) blir det egentligen 27K baud. Till detta ska du tänka på synkroniseringssignaler osv så den reella hastighet ska upp en del.

Med tanke på att du vill ha 12 bit måste det läggas till en del "arbetstid" för att låta µC'n lägga bitsen på plats.

Till detta ska du lägga till scanningen som ju tar en del arbetstid också....men visst är det möjligt, det kräver bara en del processorkraft och (nog det svåraste) en säker kommunikation.

[jack]

Hur var det med radio och LED-snurror egentligen? Har för mig att någon testade utan att få det att fungera?

[Icecap]

Radio skulle nog duga.....men på vilket sätt hjälpar det?

Jag skulle tro att de kommer att bli ända svårare med radio.

Det enklaste sätt att greja kommunikationen tror jag skulle vara att ha 2 spolar, 1 fast i bottenplattan och 1 på snurran. De sitter paralellt och ganska nära, därmed kan man "pulsa" signaler fram och tillbaka (simplex) och om man då tar en schmitt-trigger på mottagande sidan kan man överföra ett klockrent signal.

Metoden används på videobandspelare....

[netrunner]

Grejen är ju den att det skulle vara så otroligt mycket mer användbart. Förlåt om jag nämner sådanna fula ord.

Som jag serdet skulle ett program ha dessa arbetsuppgifter:

1. Visa data från minne på lysdioderna.
2. Fånga ny data att lägga i minnet.

Kan man få en PIC att fånga en byte på den tid tid det tar att invänta nästa nya skrivning till lysdioderna, dvs ett steg i matrisen.

Hur gör man med ljusskyltar?

[netrunner]

Jag svarar lite på min egen fundering, jag har inte någon PIC att prova på men har bestält ett gäng från USA nu...

Kan man programera PIC:en att bara tamot ex. 2 byte (16bit), flytta dom till 16 lysdioder. Därefter åter tamot 2byte och flytta dom till ... osv

Har man en överföringsastighet på 57600 så borde man få ganska hög fps.

Men ... "tappar" man en byte när programet hoppar för att skriva till lysdioderna?

Nu har man vissligen bara fått en "puckad display" av LED-snurran. PC:n måste hålla koll på när det ska bli ett nytt varV (eller så man snurra med mycket hög nogranhet)...

Men man skulle kunna buffra allt och låta en kontroll bit visa att "nu kommer en ny bild": börja lagar denna byte först i listan. Har även den fördelen att snurran fortsätter att visa den senaste bilden tills det kommer en ny. PC:n behöver bara skicka ny info om det ska förändras någon. Även bra om man vill ha en "fler armad" LED-snurra för att minska vartalet om snurran är stor.

Några funderingar?

[mullemeck]

På min ledsnurra lyckades jag inte med överföringshastighet över 2400 baud,

Ifall man kodar sig en teckengeneratior i snurran så skulle det funka att skicka ren text till den i realtid men att få över några bilder kan nog bli svårt.

allternativet är väll då kanske radio eller att man på nått finurligt sätt fixar flera kanaler ir som man kan skicka över samtidigt och få bättre hastighet.

[Maze]

Upptäckte när jag byggde min RGB snurra för ett år sen att en PIC inte han med det jag ville göra på långa vägar. SKulle jag bygga en ny version så skulle jag sätta dit en FPGA eller CPLD istället. Bygg ett logikblock som driver didoderna hela tiden från ett dubbelportsram och sen ett annat block som uppdaterar minnet när det kommer ny data.

[netrunner]

mullemeck:

Fick du max 2400 över IR för att det är en begränsning i tekniken med IR, eller för att snurran fick svårt att få en "bra singal" när den snurrade.

I det senare fallet så borde man kunna fläska på med fler IR-dioder på sändare och mottagare.

Det skulle kanske gå att köra data över släpringar...

[mullemeck]

inte säker var begränsningen ligger men även om snurran stod stilla så gick det inte högre.

[sodjan]

Om länken använde standard IR ("fjärr") mottagare, så har man ju en viss
timing att följa, och då hamnar man nog kring 1-2000 baud...