Diskuzní fórum Elektro Bastlírny

Jen pouhým vnějším pozorováním činnosti MCU řízeného programem - viz příloha. Na sledování stavu registrů nemám ani dost.znalosti ani tech.vybavení. Možná, že je to jen zdání, zaviněné mou omezenou schopností vnímat fyzikální děje, na druhé straně, oči mně jakž takž slouží a vidím jak blikají test. LEDky po HW resetu a jak po stop-startu napájení.
Jinak, jak jsem zjistil, problematičnost funkce programu spočívá hlavně ve funkci Man_Receive_Init(), která provádí jakousi synchronizaci příjmače s vysilačem. Bohužel, pokud vysílač nevysílá užitečný signál, fce se klidně "zasynchronizuje" na jakýkoliv i jiný rušivý signál a příjmač pak příjímá bludy. Vložený WatvhDog celkem pomohl, ale je to celé vhodné, tak akorát, pro ovládání slimáků.
Pokud by někoho napadla nějaká lepší koncepce programu, tak díky za ní.
S pozdravem[/b]

Netuším, jak fungují ty funkce Man_xxx, ale nikdy jsem s vysíláním a příjmem signálu kódovaného manchesterem problém neměla. Teď jsem dokonce dělala vysílání i příjem souběžně a na jiných rychlostech a taky to funguje bez problémů. Je třeba mít vhodně navržený formát rámce i jednotlivých bytů a samozřejmě zabezpečení pomocí CRC, pak je falešný příjem prakticky vyloučený.

Pokud ti program dělá něco jiného po zapnutí napájení a po resetu, pak nejspíš závisí na nedefinovaných hodnotách registrů.
Jo a zápis stylem wdtcr=0b00011010; není zrovna moc vhodný, nejen, že není jasné co se vlastně nastavuje, ale pak ten program použiješ někdy jindy na jiný procesor s jinak řazenými bity v registrech a ono to najednou nebude fungovat.

Andrea píše:Netuším, jak fungují ty funkce Man_xxx, ale nikdy jsem s vysíláním a příjmem signálu kódovaného manchesterem problém neměla. Teď jsem dokonce dělala vysílání i příjem souběžně a na jiných rychlostech a taky to funguje bez problémů. Je třeba mít vhodně navržený formát rámce i jednotlivých bytů a samozřejmě zabezpečení pomocí CRC, pak je falešný příjem prakticky vyloučený.

Nemohla bys být, prosím, trochu sdílnější, pokud to není výrobní tajemství.

Andrea píše:Pokud ti program dělá něco jiného po zapnutí napájení a po resetu, pak nejspíš závisí na nedefinovaných hodnotách registrů.

No jo, ale jakých??

Andrea píše:Jo a zápis stylem wdtcr=0b00011010; není zrovna moc vhodný, nejen, že není jasné co se vlastně nastavuje, ale pak ten program použiješ někdy jindy na jiný procesor s jinak řazenými bity v registrech a ono to najednou nebude fungovat.

Máš zcela pravdu, nakonec, jako všechny příslušnice něžnější poloviny populace.


[/quote]

Je to tajemství, občas i něco vynese.

A jsem zase tam, kde už jsem mockrát byl.
V každém případě díky, Andreo!
S pozdravem

Můžu ti prozradit, že paket používám takovýhle:

Hlavička:
24 bitů střídavě 1 a 0
9 bitů 1 (nikde jinde se nemohou vyskytovat - data mají stop bit 0)

Data:
8 bitů data
1 bit 0 (stop bit)
Většinou max. 8 bytů.

Na konci dat je CRC-8.
Přijímám pomocí capture funkce 16-bit timeru, vysílám pomocí libovolného timeru v režimu CTC. Rychlost co zvládá přenosový kanál (zatím nikdy víc jak 4kb/s).

Mám dojem, že třeba na PICu je registr, který ten procesor při resetu nastaví tak, že je možné z něj pak vyčíst příčinu resetu. Pokud simuluješ reset skokem na adresu 0, zbyde tam zřejmě poslední hodnota. Pokud ten program takový registr čte a řídí se podle něj, může být samozřejmě zmaten. Nebo pokud spoléhá na to, že některé registry jsou nějak inicializované, jak psala Andrea.

Jinak ten skok na adresu 0 jde v céčku popsat takhle, ale nezkoušel jsem to na jednočipech:Každopádně, pokud tam můžeš vkládat assembler, použil bych asi spíš něco jako:Stejně to bude závislé na typu procesoru a je to čitelnější.