Piotr Dmochowski <i...@p...onet.pl> wrote:
> W dniu 2017-02-08 o 20:31, Pszemol pisze:
>>
>> Zerknij proszę jeszcze raz na deklarację wskaźnika pStatus oraz zmiennych
>> Status1 i Status2.
>> To są obiekty 32-bitowe a więc obie kostki pamięci odpowiedzialne są za ich
>> zapis.
>>
>
> while(Status1 = *pStatus, Status2 = *pStatus, (Status1 ^ Status2) & (1
> << 2))
> Przepraszam że zawracam głowę, ale jaki jest sens robienia XOR na
> zmiennych pobierających wartość z tego samego adresu?
> Tam (praktycznie) zawsze będzie false, chyba że procesor akurat trafi na
> zmianę statusu drugiej kostki między jednym a drugim odczytem *pStatus,
> ale z takim szczęściem to lepiej kupony wypełniać niż babrać się w kodzie ;)
>

Piotrze, świetne pytanie.
Bo to jest ciekawy fragment procesu kasowania pamieci flash i zapisu do
niej.

Taka pamięć ma wewnątrz sterownik ktory kontroluje te procesy niejako z
wewnątrz kostki. Obsługujesz go przez wspólną magistralę danych i adresów -
scalak pracuje w dwu trybach: odczyt danych (wtedy działa jak klasyczny
ROM) oraz kasowanie/zapis: wtedy uzyskujesz dostep do wewnetrznego
sterownika umówioną sekwencję bajtôw w roli "sezamie otwórz się!" I wtedy
możesz wydawać sterownikowi polecenia kasowania/zapisu konkretnych
lokalizacji pamięci... A sterownik informuje Cie o postepie operacji
kasowania i o błedach ustawiajac stan bitow szyny danych. Miedzy innymi
zmienia on stan bitu D6 gdy operacja jest wciaz w toku. Stad w kodzie dwa
kolejne odczyty i stad użycie sugestii "volatile" do kompilatora aby tych
dwu odczytów nie "zoptymalizowal" myslac ze są bez sensu, tak jak Ty
pomyślałes :-))

Nawiasem mówiąc zmiana testu bitu D2 na bit D6 w czasie kasowania pomogla -
nie mam juz błędów o ktorych pisałem wcześniej.
Muszę jeszcze raz się przyjrzeć tym flołczartom z dataszyta :-) i
przypomnieć sobie dlaczego pisząc ten kod uznałem że testowanie D6 będzie
dobre w czasie zapisu flash a powinienem testować D2 w czasie kasowania...