"J.F." <j...@p...onet.pl> wrote in message
news:5b2b856d$0$614$65785112@news.neostrada.pl...
> Użytkownik "Janusz" napisał w wiadomości grup
> dyskusyjnych:pgfpiq$kht$...@n...news.atman.pl...
> W dniu 2018-06-20 o 20:22, Pszemol pisze:
>>>> Czy w czasie tego inkrementowania nie ma chwili, kiedy obie kości
>>>> walczą ze sobą na liniach danych (na przykład w czasie równym czasowi
>>>> propagacji negatora na linii A0).
>>
>>> Jedna kość obsługuje przecież D0..D15, druga obsługuje D16..D31.
>>Ale sam pisałeś że jest w trybie 16b i czyta na jednej szynie dwa flasze.
>
> Nie, flashe sa rownolegle i daja 32 bit.
>
> Tyle ze procek skonfigurowany (omylkowo) na 16-bit, wiec slowo czyta na
> dwa razy.

Dokładnie tak. CPU omyłkowo czyta dwa razy 16bit z jednego
chipa flash zamiast czytać oba na raz na pełnej szynie 32-bit.

> Oczywiscie w obu cyklach "gorny flash" tez podaje dane, ktore procek
> powinien ignorowac, ale widac jest tam jeszcze jakis konflikt na
> magistrali danych.
> Jak rozumiem - na pewno nie z dolnym flashem, bo ten na innych bitach D
> polaczony.

Dokładnie tak.

> Swoja droga - ze to w ogole działa ?
> Puste te flashe ?
> Przypadkiem dobrze sie programuja mimo omylki ?

Ten górny jest pusty, bo w czasie programowania CPU też "myśli" że
ma jedną kostkę 16 bit, więc nic nie wystawia do zapisu na D16..D31.
A więc górny flash podczas odczytu forsuje FFy ale CPU pewnie
chce ustawiać 00 bo mam jakieś 1.5V tak na oko :-)