Spara i minnet!

[Samot]

På portb ben 1 kan det vara antingen nolla eller en etta. Detta vill jag spara i minnet. Sedan en tid senare vill jag sampla ett nytt värde på samma ben och spara in det i minnet. Jag har 4´a sekvenser som jag vill spara. Hur många sample kan jag då ha per sekvens? Och hur gör man för att räkna upp minnet och spara det. Sedan vill jag kunna spela upp sekvensen igen så att den blir likadan som när det samplades?
Tacksam för tips och idéer!! Jag har en p16f84a!

[Rollo]

Det är väl bara att sätta en variabel på 1 eller 0 beroende på förutsättningarna.

typ nåt sånt här i picbasic...

Kod: Markera allt

b1 var bit

if portb.1 = 1 
    then b1 = 1 
       else b1 = 0

[Samot]

Alltså, om sekvensen [1 0 1 1 0 1] kommer på portb vill jag spara undan det i minnet på något sätt. För att sedan kunna skicka ut samma sekvens på ett annat ben. Sekvensen ska även vara sparad när picen är avstängd.

[evert2]

har du tänkt att ha någon klocksignal....så att PIC:en vet NÄR den skall läsa av värdet..........

[Samot]

Har tänkt att använda första pulsen som ska sparas som trigg signal, och sedan över sampla signalen, detta pga att signalen jag ska spara har olika frekvens varje gång och annars måste jag spara tiden mellan varje puls också. Och eftersom jag bara behöver kunna spara 4 sekvenser så borde minnet räcka.

[Schnegelwerfer]

Hur vet du om första pulsen är en 0:a då?
Det krävs nog något slags sync-sekvens hursomhelst om du ska läsa in data asynkront.

[Samot]

Om första puslen är låg så spelar det ju ingen roll när jag spelar upp den
Blir ju exakt samma resultal, så visstt funkar det att trigga på första ettan. Frågan är hur man sparar sekvensen i minnet????

[Schnegelwerfer]

Ok, men du måste ju ändå starta inspelningen ungefär när data kommer in (hur du nu ska veta det?)

PIC har du ju inte direkt obegränsat med minne heller, speciellt som du blir tvungen att översampla brutalt mycket (teoretiskt med 2ggr högsta inkommande frekvensen, i realiteten antagligen snabbare) om du inte har någon bitsynk. Har du bitsynk behöver du inte översampla överhuvud taget.

Det är ju inte för inte som ett asynkront protokoll som RS232 använder syncbitar och känd bitrate.

[Samot]

När jag ska spela in en sekvens går jag in i 'spela in' mode, dvs ligger i en loop och väntar. När etta upptäcks så börjar jag sampla, som jag tänkt översampla för att bara behöva ta hänsyn till högst förekommande frekvens. Bäst vore ju givetvis att ha frekvens på inkommande data.
Alt. spara på positiv flank och spara tiden på etta och nolla, men känns som ett betydligt större projekt. Förstår att det är det bästa, men eftersom jag ska spara max fyra sekvenser borde minner räcka till att översampla den?
Men, hur sparar man i minnet?

[$tiff]

Du överför variblerna till EEPROMet.

Vilket språk kör du?
Om du använder PICBasic blir det busenkelt
Write [minnesplats],[variabel]
(utan hakparanteser)

PIC16F84A har 64 minnesplatser á en byte.

[Schnegelwerfer]

Antar att du menar EEPROM-minnet?
Har aldrig gjort det själv, men det finns en hel del trådar om det.

Jag antar att du ska spela in något slags fjärrkontrollkoder eller dylikt, och jag kan lova dig att det protokoll du ska "spela in" garanterat använder sig av någon synk-sekvens.

Vad är högsta/lägsta bitraten på datat du kommer att spela in?

[Samot]

Om man skriver i assambler då?
Jag tänkte spara in en sekvens från en fjärrkontroll oberoende av vilken fjärr det rör sig om.
Någon som vet hur många protokoll det finns? Finns det typ 5 stora och ett uppsjö mindre?
Ett alternativ är ju att lägga in de största så den sänder ut alla protokoll för tex volym upp, men det känns ju lite B.
Bäst är ju om det går att läsa in.

[Schnegelwerfer]

Det finns ett gäng olika protokoll för fjärrkontroller, men det finns några riktigt stora som tex. RC-5 och REC-80.

Jag har precis byggt en fjärr till min TV som använder sig av följande modulering:

1= 234us 38kHz bärvåg följt av 8397us tystnad, följt av 234us 38kHz bärvåg
0= 234us 38kHz bärvåg följt av 5516us tystnad, följt av 234us 38kHz bärvåg

Varje kontrollmeddelande inleds också med ett 5-bitars synkord, där en bit _togglas_ varannan gång kommandot utförs. Din inspelningsidé faller på det, den skulle bara fungera första gången du försökte byta kanal.

Jag tror att din idé blir svår att realisera, det är nog bättre att lagra lite olika protokoll i PIC:en, och lägga krutet på att identifiera vilket protokoll som används av fjärren du "spelar in" ifrån. Det är nog inte särskilt svårt.

Kolla in http://lirc.sourceforge.net för info om vilket protokoll som används till olika apparater. Jag hittade mina koder där.

[Samot]

Jag har byggt en sändare med rc5 protokollet som fungerar bra, där finns också en toggle bit som jag hela tiden har ett ställd, den är till för att tvn ska veta om man håller inne knappen eller om det är första pulståget som kommer.
Men det spelar ingen roll när man ska sampla, för sparar man första pulståget med togglebiten ett ställd tror bara tv att man inte håller nere knappen när man spelar upp sin sekvens.
Så borde det inte då gå att spara undan??

[Schnegelwerfer]

Min TV fungerar inte på det sättet, utan där händer det ingenting om inte togglebiten är rätt.

Jag var inne på din linje först att "spela in" signalen, men gav upp dom planerna när jag insåg svårigheterna. Det tycker jag att du också borde göra!

Jag är ganska säker på att de "inspelningsbara" fjärrkontroller som man kan köpa enbart identifierar protokollet, för att sedan känna igen vilken kod som tas emot.