ATMega32 a bluetooth

Přečetl jsem a seznámil se s tím trošku. Pokud by celé to měření zahrnovalo programování knihovny, tak to jsem vskutku v koncích. Jak jsem říkal, jsem nováček a doteď jsem jakž takž držel krok ale teď už jsem slušně pozadu. Zřejmě by se mi hodila nějaká již hotová knihovna, například jako zde:

extremeelectronics.co.in/code-libraries/using-ir-remote-with-avr-mcus/
extremeelectronics.co.in/code-libraries/using-ir-remote-with-avr-mcus-part-ii/

jenže to by zřejmě zahrnovalo pořídit si i displej a kódy vyčíst, navíc DO používané tam je jiné. V podstatě co bych si zjistil kdybych si na PC zobrazil průběh? 0 a 1, jenže s těmi naložit jak? V podstatě nejhorší na tom je, že moje představa je program “zaifovat”, samozřejmě že ne doslova, jen něco na ten způsob, ale nevím jak se data přijímají a co s nimi, když bych na to neměl knihovnu.

Mám prostě jen spoustu otázek a vypadá to že když se jedna zodpoví objeví se další. Zřejmě by se mi hodila nějaká knihovna i se všemi kódy na čip ATMega32 a prostě všechno, co je na to potřeba. Nemyslím přímo nějaký set, klidně návod, ale pokud možno krok po kroku.

:arrow_right: administrator: příspěvek byl upraven

Nechápu proč se mi to nechce poslat. Nechtěl jsem spamovat, jen jsem doufal že další už půjdou. Přitom nevím jestli se odešle aspoň toto.

V tagu URL bylo zalomení řádku. Opravil jsem to.

Ano, keby ten priebeh vidis, videl by si, ako je zakodovana jednotka, ako nula, ako vyzera cely ovladaci kod.
Kniznicu ti odporucit neviem. V tomto dokumente su snad nejake info o tvojom DO. lirc.sourceforge.net/remotes/panasonic/N2QAJB000051
Ma to trocha odlisne oznacenie, ale je to pre DVD, tak by to mohlo byt ono. Mas tam napisane ako vyzera jednicka, nula, header, kolko bitov ma kod. Bohuzial netusim co znamena ptrail, ani pre_data. Mozno sa to vysiela za riadiacim kodom.

V skutocnosti ide z primaca signal negovany. Ked nan DO nevysiela, ide z primacaneustale jednotka. Jednotka, nula a header vyzeraju tak ako v pripojenej priloha. To je podla toho dokumentu. Signal potom vyzera tak, ze pride ti header, za nim 16 bitov kodu a potom pauza 74387 us (ak tam teda niesu pripojene tie pre_data, ktore neviem co znamenaju).

Program mozes potom napisat tak, ze budes cakat, kedy sa ti na pine, na ktorom mas pripojeny primac neobjavi log0. To bude znamenat, ze primac prijal nejaky signal. Budes pocitat, kolko bude ta nula trvat. Potom sa ti signal prepne do log1, zase budes pocitat, kolko trva, az sa ti zas neprepne do nuly. Ak nula trvala cca 3461us a jednotka cca 1822 us, prijal si header, mozes ocakavat prikazove bity. Pokial si header neprijal, bol to plany poplach alebo nejaka ian chyba, musis dalej cakat na header. Kod z DO sa vzdy zacina headerom. Pokial neprimes header, tak o zvysok sa nestaraj. Ked si prijal header, tak mozes rovnakym sposobom zistovat dlzku nasledovnych logickych urovni a podla dlzky vyhodnotit, ci to bola jednotka a ci nula. Jednotlive bity si bude zapisovat do nejakej premennej (pokial sa za headerom vysiela len 16 bitovy prikaz, staci ti uint16_t, co je 16 bitovy unsigned int). Potom prijaty bit porovnas s kodom z toho dokumentu (napr. arrov_up je napisana ako 0xA1AC), a ked ano, vykonas dany pohyb. Alebo na zaciatok rozsvietis/zhasnes led.

Tu kniznicu z linkov, ktore si uviedol pracuje s timerom, s externym prerusenim, ale mozno by sa dala upravit. A nemusis pouzivat display. Namiesto toho, aby si prijaty kod vypisal na disp, tak ho porovnas a ak sa zhoduje tak rozsvietis/zhasnes led.

:arrow_right: administrator: přiloženy externí soubory
Panasonic-N2QAJB000051.txt (3.29 KB)

V jednom příspěvku jste mi říkal o toleranci, ale to při zjišťování protokolů. Když znám konkrétní DO, tak toleranci dělat nemusím?

Ohledně uint16_t, to mi zní hezky, ale jedna otázka. Ať hledám co hledám, práci s ním nedokážu najít. Myslím tím nějaký příkaz, který by mi například po tom, co přečtu všechny 1 a 0 a vyčtu například F, přidal k proměnné právě to F například na první místo, tedy nultý bit, při dalším přečtení přidám na první bit atd… Řekněme že bych ještě vymyslel nějak to časování, to se mi v hlavě rýsuje a s nějakými nepřesnostmi bych se na vás dyštak obrátil. Jde mi jen právě o tohle. Nejsem si zrovna jistý, jestli jsem to uvedl správně a srozumitelně. Je dost možné, že takto to ani nefunguje. Jinak bych chtěl velice poděkovat za ten obrázek.

nejaku toleranciu musis brat do uvahy. To urcite. napr 10us. V tej kniznici z linku ktory si sem dal sa pouziva tolerancia ± 10 percent. Casovanie nebude nikdy presne, keby nepouzijes nejaku toleranciu, tak na 99,9 percenta nebudes schopny vyhodnotit prijaty udaj.

Co sa tika toho prevodu z bin do hex: V gcc nemusis robit prevod, ak chces porovnavat dve cisla. Ked si budes ukladat tie prijate bity do typu uint16_t, mozes to rovno porovnat s hex hodnotou. Napriklad uz spominany kod pre arrov_up, ktory je 0xA1AC, vyzera v binarnom tvare takto: 0b1010000110101100 (snad som sa pri opisovani nepomylil :smiley:).

[code]//deklaracia premennej
uint16_t prijatyKod = 0;

.
.
.
//niekde v kode, ked su uz prijate vsetky bity je premenna prijatyKod = 0b1010000110101100;
.
.
.
//niekde dalej v kode
if (prijatyKod == 0xA1AC) { //rozsviet led[/code]
ako vidis, porovnavam typ uint16_t s hex cislom. A je to v poriadku.
Ak by si chcel predca len z toho uint16_t vidiet to hexa cislo, tak to 16 bitove cislo si rozdel na skupiny po styroch. Kazdu tu skupinu si potom mozes premenit na hexa cislo. Alebo si spusti windows kalkulatr, nastav si ho na programatorsky, a tam si zapis to binarne cislo. On ti ho prevedie na hexa.
Pri porovnavani v programe to ale nepotrebujes, a ak by si to chcel v hexa tvare pisat na display, tak myslim ze si to spravi fprintf funkcia (alebo taka nejaka, neviem, nepouzivam…)

Tak aspoň že se to nemusí převádět, i když to by byl jen menší problém :slight_smile: .
V předchozím dotazu jsem měl spíše na mysli to, že řekněme mám kód nějak takhle ( a doufám že nevadí že tam nebudou příkazy ) :

uint16_t prijatyKod = 0; 
.
.
.
program čeká dokud se na pinu neobjeví log0
když objeví, očekávej zhruba 3461us log0 a 1822us log1, jinak si nepřijal header a čekáš znova
v případě že header přijme, očekávej nuly a jedničky, které se skládají z intervalů logických nul a jedniček podle obrázků
**zapiš 1 či 0 do proměnné prijatyKod**
.
.
.
if (prijatyKod == 0xA1AC) {

}

předem se hned chci omluvit, jestli to jak jsem toto napsal se nedělá, já jen že takhle si učitel na programování v assembleru rozepisoval programy a stejně tak nám zadával testy, mě se to líbilo

Každopádně jde mi o to, že až přečtu na pinu 0 či 1, jak ji mám zapsat do proměnné prijatyKod? Předpokládám, že nejdřív se pošle nultý bit a poté další až do 15., jde jen o to že až přijmu nultý bit tak ho musím zapsat na správné místo, stejně tak ostatní.

Co se týče zbytku programu, podle toho co jsem tu všechno vyčetl se tento kód kromě toho if dá zřejmě do přerušení. Kousíčky kódu už bych měl :slight_smile:, jen co se týče počítání času v us, existuje takový příkaz, nebo musím využít časovač?

Cau, vzhledem k tomu ze asi zacinas tak bych zacal jednoduse a nemichal do toho zatim zadny preruseni a casovace…atd
nastrel kodu [code]
cekej dokud ir_in==0
cekej 1000us //1ms
je ir_in==1 ? ano -pryc z podprogramu , neni 1/2 header,chyba
ne cekej 1000us //2ms
je ir_in==1 ? ano -pryc z podprogramu , neni 1/2 header,chyba
ne cekej 1000us //3ms
je ir_in==1 ? ano -pryc z podprogramu , neni 1/2 header,chyba
ne cekej 400us //3.4ms
je ir_in==1 ? ano -pryc z podprogramu , neni 1/2 header,chyba
ne cekej 50us //3.45ms
je ir_in==1 ? ano -pryc z podprogramu , neni 1/2 header,chyba
ne cekej 5us //3.455ms
je ir_in==1 ? ano - pokracuj dal , 2/2 header
ne cekej 5us //3.46ms
je ir_in==1 ? ano - pokracuj dal , 2/2 header
ne cekej 5us //3.465ms
je ir_in==1 ? ano - pokracuj dal , 2/2 header
ne cekej 5us //3.47ms
je ir_in==1 ? ano - pokracuj dal , 2/2 header
ne pryc z podprogramu, neni 2/2 header,chyba

pokracujem dal
cekej 500us //0.5ms
je ir_in==0 ? ano -pryc z podprogramu , neni 2/2 header,chyba
ne cekej 500us //1ms
je ir_in==0 ? ano -pryc z podprogramu , neni 2/2 header,chyba
ne cekej 500us //1.5ms
je ir_in==0 ? ano -pryc z podprogramu , neni 2/2 header,chyba
ne cekej 315us //1.815ms
je ir_in==0 ? ano -pryc z podprogramu , prijata 2/2 header,vporadku
ne cekej 5us //1.820ms
je ir_in==0 ? ano -pryc z podprogramu , prijata 2/2 header,vporadku
ne cekej 5us //1.825ms
je ir_in==0 ? ano -pryc z podprogramu , prijata 2/2 header,vporadku
ne cekej 5us //1.830ms
je ir_in==0 ? ano -pryc z podprogramu , prijata 2/2 header,vporadku
ne pryc z podprogramu, neni 2/2 header,chyba
[/code]
takle se da napsat program pouze s if + else,
a odfiltrujes i ruseni ,na zacatek staci prijmout jen ten header za nej si dat rozsviceni ledky treba na 100ms, vyskousej …uvidis , pak muzes zacit dekodovat zbytek

Použít čekání může být jen na první pokusy, ale pak je třeba použít hw časovač. Při dlouhých prodlevách se nevychytají krátké impulsy a při krátkých prodlevách (jednotky us) se zas naopak uplatní zpoždění a nepřesnost kódu.

Možnosti:

  1. Asi nejsprávnější (nejpřesnější) řešení je vyvolávat přerušení časovače změnou hodnoty portu. Čtením hodnoty časovače se zjistí uběhlý čas. Současně je třeba obsluhovat i přerušení při přetečení čítače (time-out impulsu).

  2. Použít hw 16bitový čítač (nejlépe 1 tik = 1 us, ale může být jinak). Pro měření šířky pulsu se použije čekací smyčka, která si na začátku uchová hodnotu čítače, pak čeká (s opakovaným čtením portu) na příchod opačné hodnoty vstupu, znovu přečte časovač a rozdíl hodnot = uběhlý čas. Vzhledem k tomu, že při dlouhé prodlevě může nastat přetečení hodnoty časovače, tak buď se čte časovač i během čekání a při dlouhé prodlevě se skončí s time-outem, nebo časovač vyvolá přerušení a nastaví flag, že nastalo přetečení.

  3. Použije se inline assembler s kalibrovanou čekací smyčkou - je to jen pár instrukcí, lze snadno spočítat kolik která instrukce zabere času. Pak stačí jen čekat v loop smyčce na změnu portu, čítat registr a z jeho koncové hodnoty určit uběhlý čas. Je nutné opět řešit přetečení, např. že se registr dodekrementoval k nule. Inspirací může být zdrojový kód funkcí _delay_us z knihovny gcc-avr. Během čekání by nemělo nastati přerušení, vznikla by nepřesnost.

  4. Kompromis je kalibrovaná čekací smyčka v C. Ve smyčce se čeká na změnu pulsu, přitom se čítá proměnná (opět se sledováním přetečení) a z její koncové hodnoty se zjistí uběhlý čas - převodový koeficient se zjistí zkusmo měřením impulsu známé délky (nebo jednodušeji volat opakovaně s timeoutem). Je třeba počítat s tím, že jiné nastavení optimalizace překladače může kalibraci změnit a že případná obsluha přerušení může měření znepřesnit.

Organizace programu - v jedné proměnné uchovávat aktuální stav a impulsy načítat jednou univerzální funkcí (resp. 2 - pro 1 a 0), která měří šířku impulsu. Např. (jen náznakově):

[code]enum STAV {
STAV_ERR, // chyba nebo neznamy stav, cekani na 1
STAV_DELAY, // oddelovaci 1, mereni minimalni delky prodlevy
STAV_START, // ceka se na startovaci 0
STAV_SYN0, // probiha startovaci 0
STAV_SYN1, // probiha startovaci 1
STAV_DATA0, // probiha datova 0
STAV_DATA1, // probiha datova 1
STAV_OK // prijem kodu ukoncen
};

STAV stav;
int kod;
int maska;
int bity;

void Restart() // restart prijmu, ceka se na startovaci 0
{
stav = STAV_ERR;
kod = 0;
maska = 1;
bity = 0;
}

#define DELTA 10 // rozliseni citace v us (zvolit co nejmensi)
#define TIMEOUT 30000/DELTA
// Kalibrace - na portu nastavit stabilni hodnotu, funkci
// volat 50000x opakovane ve smycce s blikajici LED,
// dokalibrovat cekani ve funkci tak, aby blikalo presne po 1 sekunde
short Zmer0() // mereni delky 0 v desitkach us, cekani na 1
{
short citac = 0;
while ((port != 1) && (citac < TIMEOUT))
{
_delay_us(5); // prodleva se zkusmo doladi na DELTA
citac++;
}
return citac;
}
short Zmer1() // mereni delky 1 v desitkach us, cekani na 0
{
short citac = 0;
while ((port != 0) && (citac < TIMEOUT))
{
_delay_us(5); // prodleva se zkusmo doladi na DELTA
citac++;
}
return citac;
}

#define TIMESYN0MIN 3000/DELTA // minimalni delka syn0
#define TIMESYN0MAX 4000/DELTA // maximalni delka syn0
atd.

short delka;
Restart(); // restart prijmu
while (stav != STAV_OK)
{
switch(stav)
{
case STAV_ERR:
delka = Zmer0();
if (delka != TIMEOUT) stav = STAV_DELAY;
break;

case STAV_DELAY:
delka = Zmer1();
if (delka >= TIMEDELAY)
stav = STAV_START;
else
Restart();
break;

case STAV_START:
  delka = Zmer1();
  if (delka != TIMEOUT) stav = STAV_SYN0;
  break;

case STAV_SYN0:
  delka = Zmer0();
  if ((delka < TIMESYN0MIN) || (delka > TIMESYN0MAX))
    Restart();
  else
    stav = STAV_SYN1;
  break;

…atd.

 case STAV_DATA0:
   delka = Zmer0();
   if (delka == TIMEOUT)
     Restart();
  else
  {
     if (delka > TIME1) kod |= maska; // je to datovy bit 1
     maska <<= 1; // posun masky
     bity++;  // zvyseni citace prijatych bitu
     if (bity == 16) // jsou jiz vsechny datove bity
       stav = STAV_OK; // kompletni
     else
       stav = STAV_DATA1;
   }
   break;

[/code]

rek bych ze tohle je prvni pokus :wink:

Sleduji tuhle diskuzi a nestačím se divit. Adame, snažíš se programovat nebo jenom lepit cizí kódy dohromay ? Měl bys začít programovat. Co se IR ovladačů týká, tak čtení kódu sice není úplně triviální jako například snímání rotačního kodéru, nicméně není to ani žádná divočina. Napsal jsem si ovladač, který využívá 16-ti bitový čítač (Timer/Counter 1) v režimu CTC a používá přerušení pro Input Capture (je na něj připojen TSOP přijímač a používá se jako externí přerušení), Timer Comapre B (timeout pro zápis kódu z DO) a Timer Compare A (timeout pro konec vysílání z DO). Celý kód má po překladu něco málo přes 600 bytů (psáno v asm) a jde z něj 8-bitový status (příznak požadavku zpracování kódu z DO a čítání počtu opakování vysílaného kódu z ovladače) a 48-bitová hodnota vyslaného kódu (s málokterým ovladačem vystačíš jenom s 16 bity). Pokud se chceš něco naučit, popíšu Ti tady, co které přerušení dělá, ostatní je na Tobě :

Input Capture provádí :
Načtení hodnoty ICR1. Pokud je nula, znamená to, že čítač stojí = 1. impulz z ovladače.
Pokud ICR1 není nula, zkontroluje se hodnota ICR1 na délku bitu. Pokud je menší, než 1,7 ms, zapíše se 0, pokud je menší, než 2,7 ms, zapíše se 1. Pokud je delší, než 2,7 ms, nezapisuje se nic = start pulz nebo repeat pulz.
Zápis probehně tak, že 46.-0. bit se odroluje doleva (tím se 46. bit posune na 47. a 0. bit se posune na 1.) a na 0. bit se uloží načtený bit.
Hodnota kódu se načítá na dočasnou pozici.
Vynuluje a spustí se časovač.

Compare Match A provádí :
Vynulování dočasné pozice a hodnoty načteného kódu DO, zastavení čítače, vynulování počtu opakování a nastavení bitu pro zpracování ve statusu. Čítač se v CTC módu sám vynuluje.

Compare Match B provádi :
Kontrolu dočasné pozice na 00 00 00 00 00 00.
Pokud je 00 00 00 00 00 00, přišel z DO jenom repeat pulz. Kód zůstane původní, zvětší se ve statusu počet opakování.
Pokud není 00 00 00 00 00 00, může jít buď o opakování nebo o nový kód. Zkontroluje se dočasný kód s minulým načteným. Pokud souhlasí, jenom se zvětší ve statusu počet opakování. Pokud kódy nesouhlasí, jedná se o nový kód - přepíše se minulý kód novým, ve statusu se nastaví počet opakování na 1.
Nastaví se příznak pro zpracování
Vynuluje se dočasný kód.

Inicalizace :
Nastavit Timer 1 na CTC režim a ICP na reakci na sestupnou hranu - čítač nespouštět
Nastavit OCR1A na 128 ms - nejdelší čas pro repeat kódu je NEC kód = 110 ms. Něco je ponecháno jako rezerva. Pokud čítač dočítá až sem, znamená to konec vysílání ovladače.
Nastavit OCR1B na 15 ms - Timeout pro uložení kódu. Pokud do 15 ms nepřijde další impulz z DO, bere se kód jako ukončený
Zapnout přerušeni pro ICIE1, OCIE1A a OCIE1B.

V programu pak s “ovladačem” pracuješ takto : Zkontroluješ status byte. Pokud je příznak zpracování nastaven, znamená to, že je načtený nový kód a ještě nebyl obsloužený. Vynuluješ příznak, uložíš status byte zpět a podle 48-bitového kódu provedeš, co potřebuješ.

Máš tady přesné instrukce, co a jak máš naprogramovat, abys dostal kód IR ovladače do kontroleru. Co s kódem DO uděláš (zobrazit na LCD, poslat přes UART do PC) je Tvoje věc. Pokud začínáš, tak to ber jako cvičení nebo domácí úkol.

A mimochodem, pokud nemáš v NB sériový port, co třeba tohle : aukro.cz/pl2303hx-usb-rs232-ttl- … 89061.html ? Používám ho u svého NB s Win7 64bit a šlape parádně.

Na kódu už pracuji, jsem jen začátečník a měl jsem jen spoustu otázek do začátku :slight_smile:, avšak zatím nemůžu psát přesné hodnoty, jelikož neznám kódy, k mému ovladači jsem našel jedině toto:

m.uloz.to/xg8NxC1/panasonic-rx-es23-5326-ir

Netuším co znamenají tyto údaje - shead=“1822” pone=“432” sone=“1281” pzero=“432” szero=“438” - číst umím takže mě asi dochází co to znamená, jen mi nejde do hlavy to p a s. . hledal jsem kódy i jinde ale v tabulce jsem je nenašel - mimochodem predata budu muset přijímat při každém stisku tlačítka?

Porozhlídnu se ještě po zbytku co máme doma, jestli bych nenašel nějaký jiný DO. Zatím mám jasno takže do té doby než to sesmolím a vyzkouším se na nic ptáti nebudu.

:arrow_right: administrator: příspěvek byl upraven
Odkaz byl vyjmut z code.

:arrow_right: administrator: přiloženy externí soubory
Panasonic_RX-ES23_5326.zip (527 Bytes)

Zrovna DO Panasonic mají délku kódu 48 bitů, takže Ti 16-bitová proměnná na kód nebude stačit …

Délky kódů ovladačů od některých zařízení :
VCR Daewoo - 8 bitů
DVD Hyundai - 32 bitů
Repro Genius - 32 bitů
DVD Technika - 24 bitů
VCR, TV, DVD, BD, Hifi věž Panasonic - 48 bitů
PVR Universe - 32 bitů

Jaki vidíš, tak u většiny ovladačů Ti 16 bitů opravdu nestačí. Výše popsaný SW přijímače DO je umí všechny. Kvůli dálkovému ovládání rolet a dalších věcí jsem si právě postavil zobrazovač kódů dálkových ovladačů, takže vím, co tento SW zvládne přijmout.

Také tuto diskuzi sleduji ze zvědavosti. Teď mě vrtá hlavou poslední příspěvek, koukal jsem na některé kódy z linků, které tu někdo poslal na první stránce, ale ty měly bitů jen 16, ne 48, jak to tedy je?

Kódy v tomto linku (remotecentral.com/cgi-bin/codes/philips/r24080_0/) jsou 32-bitové, lépe řečeno posílá se 8+8 bitů inv. adresa, 8+8 bitů inv. data = 16bitů, s inverzema 32bitů. Jednotlivá čísla znamenají rozestupy mezi jednotlivými změnami vstupu od přijímače. To není dekódovaný signál, ale v podstatě jenom časové značky jednotlivých změn na pinu. Bitové délky kódů, které jsem zde napsal jsou délky reálně načtených kódů ovladačů nasnímaných pomocí softwaru, který jsem popsal o něco výše.

Jo, a teď mi došlo, co Ti vrtá hlavou. Ovladače, které vysílají (např. NEC protokol) 8 bitů + 8 bitů invertovaných adresu a za tím 8 bitů + 8 bitů negovaných data sice posílají jenom 16 bitů, ale v rámci jednoduchosti a univerzálnosti je ovladač bere jako 32-bitový kód. Protože například zmíněný ovladač DVD Technika posílá 8 bitů adresy a 8+8(inv.) bitů data = 24 bitů. Panasonic třeba odešle řetězec adresa+data a pak teprve pošle inverzi tohoto řetězce. Tímto způsobem se jednak příjem zjednoduší a kódy ovladačů není nutné rozdělovat podle protokolu. Prostě tento SW zvládne přijmout data víceméně univerzálně i když na úkor toho, že počítá s délkou kódu 48 bitů. Rozlišení protokolu a detekci chyb (díky přijatému bytu a jeho negaci) lze udělat potom při zpracování kódu. Na druhé straně - přijmu-li data AAh 56h (s chybou) a v programu mám uloženo, že budu reagovat na AAh 55h (data, negace), tak přijatý AAh 56h neodpovídá uloženému kódu a nic se nestane.

Nebo neřešit přesné kódy, ale jen v módu učení zaznamenat do EEPROM sekvenci šířek pulzů pro jednotlivé povely (např. 1 puls = 1 bajt s rozlišením 20 us, nebo relativně k nejkratšímu impulsu) a pak je s určitou povolenou tolerancí vyhledávat.

To mi připadá celkem složitý a především náročný na paměť. Místo 6 bytů porovnávat minimálně 16 hodnot (pro 16-tibitový kód) a to ještě s tolerancí. Z Panasonic ovladačů mi leze 48 bitů kódu (celých 6 bytů) - to by bylo minimálně 48 hodnot + k tomu přidat nějaké hodnoty pro start pulz a repeat pulzy. Takhle z “driveru” vypadne 6 bytů včetně počtu opakování kódu a zbytek je na softwaru. Driver pokud nepřijímá žádný kód, tak je latentní a nezabírá kontroleru vůbec žádný strojový čas, protože se aktivuje prvním pulzem dálkáče a 128 ms po ukončení vysílání z dálkáče zastaví časovač a čeká na další impulz z dálkáče.

A v módu učení můžu načtených 6 bytů kódu uložit do EEPROM a pak načtený kód s uloženým(a) porovnávat.

Já to vidím tak že zadavatel by se měl nejdřív naučit trochu programovat MCU (asm,c)…

Tak on i ten univerzální driver by šel samozřejmě dost zoptimalizovat - adaptovat se na šířky pulzů a uchovávat jen bity 0/1, ale jasně že to už je hodně mimo rámec tazatele.

Pokud se ti místní serva zdají drahý, tak zkus sice ne extra kvalitní, nicméně funkční objednat na eBay za cca 50Kč/ks - poštovný zadarmo. Sám mám doma pár podobných a na silově nenáročný použití mě bohatě dostačují.