<html>
<head>
<meta content="text/html; charset=ISO-8859-2"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<font face="Helvetica, Arial, sans-serif">Toto:<br>
</font> GPIOB->ODR &= ~( 1 << 9 ); // nastavenim 0
na pinu PB9 aktivujeme SharpINT<br>
je potencialne nebezpecna operace, protoze neni atomicka. Muze se
stat, ze mezi ctenim a zapisem se zmeni hodnota portu v preruseni...
Doporucoval bych pouziti BSRR registru.<br>
Dale by se mozna dal pouzit rezim open-drain (OTYPER registr).<br>
<br>
Mimochodem, co to je za registr CRH? V RM0090 pro STM32F4xx jsem ho
nenasel...<br>
<br>
Hynek Sladky<br>
<font face="Helvetica, Arial, sans-serif"><br>
<br>
</font>
<div class="moz-cite-prefix">Dne 9.7.2014 15:46, Michal Hucik -
ORDOZ napsal(a):<br>
</div>
<blockquote cite="mid:53BD47B4.3000102@ordoz.com" type="cite">
<meta content="text/html; charset=ISO-8859-2"
http-equiv="Content-Type">
<div class="moz-cite-prefix"><br>
<br>
Mate pravdu. Podle DS je 74LS03 skutecne open-collector. V tom
pripade se musim omluvit autorum HD patche. <br>
<br>
Ovsem potom je zahadou, proc kdyz je na sbernici soucasne s
Horavou pripojena i Unikarta, ktera ma switchem posunute FDC
porty, tak obcas zkolabuje cp/m 4.1.<br>
<br>
Detailneji jsem to zacal zkoumat, kdyz mi Horava nepravidelne
vratil chybu pri formatovani stopy:<br>
<br>
ld c,#__FDC_DATA<br>
<br>
im 1<br>
ei<br>
<br>
out (#__FDC_CMD),a ; WRITE_TRACK<br>
<br>
4$:<br>
in a,(#__FDC_STS)<br>
rra<br>
jr c,4$ ; cekame, dokud nezacne byt BUSY<br>
<br>
5$:<br>
in a,(#__FDC_STS)<br>
rra<br>
jr nc,5$ ; cekame, dokud neprestane byt
BUSY<br>
<br>
di<br>
<br>
rla <br>
<br>
<br>
Pomerne casto, avsak naprosto nepravidelne se mi stava, ze tato
cekaci rutina skonci, ale Sharp pritom nezaznamenal ani jeden
prichozi interrupt. Nasledne mam vsak ve statusu hned za tim
"rla" priznaky LOST_DATA a DRQ.<br>
<br>
Z unikarty si nechavam z STM32 vypsat na terminal info kdykoliv
je v hal.c volana funkce pro nastaveni, ci resetovani /INT. Po
celou dobu, kdy pracuji s Horavou je interrupt z Unikarty v
klidovem stavu, nicmene firmware Unikarty v tomto klidovem stavu
neustale vola hal_ResetSharpINT(), cimz nastavuje ten pin do
input rezimu. <br>
Je to jedine misto, kde se v Unikarte saha na GPIOB->CHR.<br>
<br>
Zkusil jsem tedy upravit firmware Unikarty tak, aby si pamatoval
predchozi stav /INT signalu a aby nesahal na nastaveni toho
portu ve chvili, kdy se pozadovany stav nezmenil. Je to
zajimave, ale po teto uprave se mi zatim nepodarilo
zreprodukovat tu chybu s Horavou. Zatim bych vsak nejasal,
protoze moc nerozumim tomu, jak by opakovane volani toho
hal_ResetSharpINT() melo ovlivnit signal, ktery jde z Horavy.<br>
<br>
<br>
/*<br>
*<br>
* Zrusit /INT signal na sbernici MZ-800<br>
* <br>
* <br>
*/<br>
void hal_ResetSharpINT ( void )<br>
{<br>
GPIOB->CRH = 0xB8B33444; // prepneme pin /INT do input
rezimu<br>
}<br>
<br>
/*<br>
*<br>
* Poslat /INT signal na sbernici MZ-800<br>
* <br>
* <br>
*/<br>
void hal_SetSharpINT ( void )<br>
{<br>
GPIOB->ODR &= ~( 1 << 9 ); // nastavenim 0 na
pinu PB9 aktivujeme SharpINT<br>
GPIOB->CRH = 0xB8B33434; // prepneme pin /INT do output
rezimu<br>
}<br>
<br>
<br>
</div>
</blockquote>
<br>
</body>
</html>