Re: Typowe przyczyny nadmiernego grzania się układów pamięci i cpu?

eGospodarka.pl › Grupy › pl.misc.elektronika › Typowe przyczyny nadmiernego grzania się układów pamięci i cpu? › Re: Typowe przyczyny nadmiernego grzania się układów pamięci i cpu?

Path: news-archive.icm.edu.pl!news.icm.edu.pl!news.nask.pl!news.nask.org.pl!news.unit
0.net!eternal-september.org!feeder.eternal-september.org!reader02.eternal-septe
mber.org!.POSTED!not-for-mail
From: "Pszemol" <P...@P...com>
Newsgroups: pl.misc.elektronika
Subject: Re: Typowe przyczyny nadmiernego grzania się układów pamięci i cpu?
Date: Thu, 21 Jun 2018 21:48:53 -0500
Organization: A noiseless patient Spider
Lines: 2
Message-ID: <pgho3h$e5q$1@dont-email.me>
References: <pfcopg$2on$1@dont-email.me> <pfdmsb$b0n$1$PiotrGalka@news.chmurka.net>
<5b27884f$0$596$65785112@news.neostrada.pl> <pg8ok8$1ea$1@dont-email.me>
<5b28e0e9$0$685$65785112@news.neostrada.pl> <pgdf3m$eiq$1@dont-email.me>
<5b2a4408$0$612$65785112@news.neostrada.pl> <pgdgla$oip$1@dont-email.me>
<pgdqr4$clv$1$PiotrGalka@news.chmurka.net> <pge60o$8dd$1@dont-email.me>
<pgfpiq$kht$1@node1.news.atman.pl>
Reply-To: "Pszemol" <P...@B...com>
Mime-Version: 1.0
Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=response
Content-Transfer-Encoding: 8bit
Injection-Date: Fri, 22 Jun 2018 02:49:21 -0000 (UTC)
Injection-Info: reader02.eternal-september.org;
posting-host="c42c96bef1226b11a5d89742bf37daa9";
logging-data="14522";
mail-complaints-to="a...@e...org";
posting-account="U2FsdGVkX1981+RVXd9zaXbB3WzEMZPM"
Cancel-Lock: sha1:/QuInRgAoJ/qAV95o6JRa2iYNms=
X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8117.416
In-Reply-To: <pgfpiq$kht$1@node1.news.atman.pl>
X-Newsreader: Microsoft Windows Live Mail 14.0.8117.416
Importance: Normal
X-Priority: 3
X-MSMail-Priority: Normal
Xref: news-archive.icm.edu.pl pl.misc.elektronika:733226
[ ukryj nagłówki ]
"Janusz" <j...@o...pl> wrote in message
news:pgfpiq$kht$1@node1.news.atman.pl...
> W dniu 2018-06-20 o 20:22, Pszemol pisze:
>> "Piotr Gałka" <p...@c...pl> wrote in message
>> news:pgdqr4$clv$1$PiotrGalka@news.chmurka.net...
>>> W dniu 2018-06-20 o 14:17, Pszemol pisze:
>>>> Procek jest błędnie ustawiony aby myślał, że ma tylko jedną
>>>> kostkę flash, i odczyt 32-bitowego słowa robi na dwa takty:
>>>> najpierw wystawia "dolny" adres, OE, CE i odczytuje dolną
>>>> połówkę danych, potem, niezmieniając stanu OE i CE inkrementuje
>>>> adres i odczytuje górną połówkę danych na liniach D0..D15.
>>>
>>> Wytłumacz jak to jest zrobione.
>>> Skoro OE i CE się nie zmieniają a zmienia się adres o 1 to A0 powinno
>>> robić za CE do jednej kości i zanegowane A0 za CE do drugiej.
>>>
>>> Ale piszesz, że CE się nie zmienia.
>>>
>>> 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 rozumiem Twojego pytania.
> My też nie, może daj kawałek schematu z oscylogramami.

Płyta jest zaprojektowana tak jak na obrazku 9.14.1 pod tytułem
"32-bit wide memory bank connection" wersja b. pod tytułem
"32 bit wide memory bank interfaced to two 16 bit memory chips".
https://www.nxp.com/docs/en/user-guide/UM10562.pdf

CPU jest skonfigurowany tak jakby miał 9.14.2 pod tytułem
"16-bit wide memory bank connection"

Niestety nie znalazłem w tym manualu co się dzieje z górną
połówką szyny danych podczas 16-bitowych odczytów... :-(