W dniu 2017-02-10 o 17:54, J.F. pisze:
> Użytkownik "Piotr Dmochowski" napisał w wiadomości grup
> Taka ta pamiec - poki sie kasuje, to odczytuje nie dane z pamieci, tylko
> rejestr statusu, w ktorym sa dwa "toogle bit".
>
> A jak sie skonczy kasowac, to przestaje migac bitami i petla ma sie
> zakonczyc.
Ok, ale czy to miganie jest zsynchronizowane z odczytem czy nie? Jeżeli
jest to ok, a jeżeli nie jest i nie wstrzelimy się czasem odczytu to
metoda jest taka sobie.

>
>> Może w praktyce jakoś to działa, ale zastanawiam się jaki jest
>> margines błędu w takim rozwiązaniu.
>> Jak najbardziej rozumiem pobranie jednego statusu i sprawdzenie D6,
>> bez XOR to nie pójdzie?
>
> Jak odczytasz raz, to nie wiesz czy bit miga, a wiec nie wiesz czy to
> rejestr statusu czy dane z pamieci.
>
Ja mam nawyki z programowania PC a nie mikrokontrolerów.
W programie pecetowym dałbym zmienną w pętli do zapamiętania stanu i
porównywał stan historyczny z aktualnym.
Podejrzewałem że w tym przypadku musi być jakiś haczyk, że może port
procesora jest zmapowany jako miejsce w pamięci, ale do pełni szczęścia
brakuje mi zapewnienia że odczyt portu jest synchroniczny z danymi
wystawianymi przez pamięć, wtedy takie rozwiązanie ma ręce i nogi.

--
Pozdrawiam
Piotrek

do góry

Użytkownik "Piotr Dmochowski" napisał w wiadomości
W dniu 2017-02-10 o 17:54, J.F. pisze:
> Użytkownik "Piotr Dmochowski" napisał w wiadomości grup
>> Taka ta pamiec - poki sie kasuje, to odczytuje nie dane z pamieci,
>> tylko
>> rejestr statusu, w ktorym sa dwa "toogle bit".
>> A jak sie skonczy kasowac, to przestaje migac bitami i petla ma sie
>> zakonczyc.
>Ok, ale czy to miganie jest zsynchronizowane z odczytem czy nie?
>Jeżeli jest to ok, a jeżeli nie jest i nie wstrzelimy się czasem
>odczytu to metoda jest taka sobie.

Pszemol wie. Dokumentacja nazywa "toogle bit", to chyba jest, bo
inaczej to by sensu nie mialo :-)

>>> Jak najbardziej rozumiem pobranie jednego statusu i sprawdzenie
>>> D6,
>>> bez XOR to nie pójdzie?
>> Jak odczytasz raz, to nie wiesz czy bit miga, a wiec nie wiesz czy
>> to
>> rejestr statusu czy dane z pamieci.
>
>Ja mam nawyki z programowania PC a nie mikrokontrolerów.
>W programie pecetowym dałbym zmienną w pętli do zapamiętania stanu i
>porównywał stan historyczny z aktualnym.

I to IMO i tu jak najbardziej mozna zrobic.
Ale czy trzeba ?
Wychodzi na to, ze Pszemol poprawnie zrobil.

>Podejrzewałem że w tym przypadku musi być jakiś haczyk, że może port
>procesora jest zmapowany jako miejsce w pamięci, ale do pełni
>szczęścia brakuje mi zapewnienia że odczyt portu jest synchroniczny z
>danymi wystawianymi przez pamięć, wtedy takie rozwiązanie ma ręce i
>nogi.

To nie port - to sama pamiec sie tak zachowuje.

Trzeba jakos upchnac funkcje Flash w pinologie zwyklej pamieci
e/ep/rom/ram.

J.

do góry

W dniu 2017-02-10 o 20:05, J.F. pisze:
>
> To nie port - to sama pamiec sie tak zachowuje.
>
> Trzeba jakos upchnac funkcje Flash w pinologie zwyklej pamieci
> e/ep/rom/ram.
>
No i teraz już wszystko jasne, dzięki za objaśnienie.
Przy takim rozwiązaniu sprzętowym faktycznie odczytanie dwukrotnie
pamięci jest OK. Czego to się człowiek może nauczyć :)

--
Pozdrawiam
Piotrek

do góry

Użytkownik "Piotr Dmochowski" napisał w wiadomości grup
dyskusyjnych:589e122c$0$641$6...@n...neostrada.
pl...
W dniu 2017-02-10 o 20:05, J.F. pisze:
>> To nie port - to sama pamiec sie tak zachowuje.
>> Trzeba jakos upchnac funkcje Flash w pinologie zwyklej pamieci
>> e/ep/rom/ram.
>
>No i teraz już wszystko jasne, dzięki za objaśnienie.
>Przy takim rozwiązaniu sprzętowym faktycznie odczytanie dwukrotnie
>pamięci jest OK. Czego to się człowiek może nauczyć :)

Tez mi sie niespecjalnie podoba, ale czy program bylby
lepszy/czytelniejszy, gdybysmy zrobili z jedna zmienna historyczna ?
Niewiele, zmienne i tak trzeba by dwie.

J.

do góry

Piotr Dmochowski <i...@p...onet.pl> wrote:
> W dniu 2017-02-10 o 17:54, J.F. pisze:
> Ok, ale czy to miganie jest zsynchronizowane z odczytem czy nie? Jeżeli
> jest to ok, a jeżeli nie jest i nie wstrzelimy się czasem odczytu to
> metoda jest taka sobie.

Tak, wartosc tego bitu zmienia sie przy kolejnych odczytach z pamieci.

do góry

J.F. <j...@p...onet.pl> wrote:
> Użytkownik "Piotr Dmochowski" napisał w wiadomości grup
> dyskusyjnych:589e122c$0$641$6...@n...neostrada.
pl...
> W dniu 2017-02-10 o 20:05, J.F. pisze:
>>> To nie port - to sama pamiec sie tak zachowuje.
>>> Trzeba jakos upchnac funkcje Flash w pinologie zwyklej pamieci
>>> e/ep/rom/ram.
>>
>> No i teraz już wszystko jasne, dzięki za objaśnienie.
>> Przy takim rozwiązaniu sprzętowym faktycznie odczytanie dwukrotnie
>> pamięci jest OK. Czego to się człowiek może nauczyć :)
>
> Tez mi sie niespecjalnie podoba, ale czy program bylby
> lepszy/czytelniejszy, gdybysmy zrobili z jedna zmienna historyczna ?
> Niewiele, zmienne i tak trzeba by dwie.

Stan zmiennej Status1 wskazuje na historyczną wartość zmiennej Status2
:-))))))

do góry

Piotr Dmochowski <i...@p...onet.pl> wrote:
> W dniu 2017-02-10 o 20:05, J.F. pisze:
>>
>> To nie port - to sama pamiec sie tak zachowuje.
>>
>> Trzeba jakos upchnac funkcje Flash w pinologie zwyklej pamieci
>> e/ep/rom/ram.
>>
> No i teraz już wszystko jasne, dzięki za objaśnienie.
> Przy takim rozwiązaniu sprzętowym faktycznie odczytanie dwukrotnie
> pamięci jest OK. Czego to się człowiek może nauczyć :)

Podobnie się zachowują inne kostki pamięci flash - w odróżnieniu od pamięci
RAM (sram, dram) pamięci flash i eeprom można kasować tylko całymi
sektorami (np po 64kbajty) a zapis może się odbywać tylko po wcześniejszym
"odblokowaniu" funkcji zapisu z użyciem wewnętrznego kontrolera w kostce
pamięci.

Jak chcesz więcej poczytać o tej pamięci to tu jest to dokladniej rozpisane
co który bit rejestru statusowego ma znaczyć:

Toggle Bit (DQ6)
The toggle bit can be used to identify whether the program/erase controller
has suc- cessfully completed its operation or if it has responded to an
erase suspend. The toggle bit is output on DQ6 when the status register is
read.
During PROGRAM and ERASE operations, DQ6 changes from 0 to 1 to 0,
and so forth, with successive bus READ operations at any address. After
successful completion of the operation, the memory returns to read
mode.
During erase suspend mode, DQ6 will output when addressing a cell
within a block be- ing erased. DQ6 will stop toggling when the
program/erase controller has suspended the ERASE operation.
The Data Toggle
Flowchart gives an example of how to use DQ6 and the toggle and al-
ternative toggle waveforms describe toggle bit timing.

Alternative Toggle Bit (DQ2)
The alternative toggle bit can be used to monitor the program/erase
controller during ERASE operations. It is output on DQ2 when the status
register is read.
During CHIP ERASE and BLOCK ERASE operations, DQ2 changes
from 0 to 1 to 0, and so forth, with successive bus READ operations from
addresses within the blocks being erased. A protected block is treated the
same as a block not being erased. After the oper- ation completes, the
memory returns to read mode.
During erase suspend, DQ2 changes from 0 to 1
to 0, and so forth, with successive bus READ operations from addresses
within the blocks being erased. Bus READ operations to addresses within
blocks not being erased will output the memory cell data as if in read
mode.
After an ERASE operation that causes DQ5 to be set, DQ2 can be used
to identify which block or blocks have caused the error. DQ2 changes from 0
to 1 to 0, and so forth, with successive bus READ operations from addresses
within blocks that have not erased cor- rectly. DQ2 does not change if the
addressed block has erased correctly.

https://www.micron.com/~/media/documents/products/da
ta-sheet/nor-flash/parallel/m29w/m29w640g.pdf

do góry