Toto:
GPIOB->ODR &= ~( 1 << 9 ); // nastavenim 0 na pinu PB9 aktivujeme SharpINT
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.
Dale by se mozna dal pouzit rezim open-drain (OTYPER registr).
Mimochodem, co to je za registr CRH? V RM0090 pro STM32F4xx jsem ho nenasel...
Hynek Sladky
GPIOB->ODR &= ~( 1 << 9 ); // nastavenim 0 na pinu PB9 aktivujeme SharpINT
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.
Dale by se mozna dal pouzit rezim open-drain (OTYPER registr).
Mimochodem, co to je za registr CRH? V RM0090 pro STM32F4xx jsem ho nenasel...
Hynek Sladky
Dne 9.7.2014 15:46, Michal Hucik -
ORDOZ napsal(a):
Mate pravdu. Podle DS je 74LS03 skutecne open-collector. V tom pripade se musim omluvit autorum HD patche.
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.
Detailneji jsem to zacal zkoumat, kdyz mi Horava nepravidelne vratil chybu pri formatovani stopy:
ld c,#__FDC_DATA
im 1
ei
out (#__FDC_CMD),a ; WRITE_TRACK
4$:
in a,(#__FDC_STS)
rra
jr c,4$ ; cekame, dokud nezacne byt BUSY
5$:
in a,(#__FDC_STS)
rra
jr nc,5$ ; cekame, dokud neprestane byt BUSY
di
rla
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.
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.
Je to jedine misto, kde se v Unikarte saha na GPIOB->CHR.
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.
/*
*
* Zrusit /INT signal na sbernici MZ-800
*
*
*/
void hal_ResetSharpINT ( void )
{
GPIOB->CRH = 0xB8B33444; // prepneme pin /INT do input rezimu
}
/*
*
* Poslat /INT signal na sbernici MZ-800
*
*
*/
void hal_SetSharpINT ( void )
{
GPIOB->ODR &= ~( 1 << 9 ); // nastavenim 0 na pinu PB9 aktivujeme SharpINT
GPIOB->CRH = 0xB8B33434; // prepneme pin /INT do output rezimu
}
Vlákno · 8 zpráv
- [SharpMZ] Upraveny FDC Horava - BUG
- Re: [SharpMZ] Upraveny FDC Horava - BUG
- Re: [SharpMZ] Upraveny FDC Horava - BUG
- Re: [SharpMZ] Upraveny FDC Horava - BUG
- Re: [SharpMZ] Upraveny FDC Horava - BUG
- Re: [SharpMZ] Upraveny FDC Horava - BUG
- Re: [SharpMZ] Upraveny FDC Horava - BUG
- Re: [SharpMZ] Upraveny FDC Horava - BUG