Dnia Tue, 14 Mar 2017 21:03:03 +0100, Atlantis napisał(a):
> W dniu 2017-03-14 o 19:48, J.F. pisze:
>> Atlantisie - na moj gust, jak bedziesz takie ambitne struktury robil ...
>> to ci pamieci zabraknie :-)
> Pilnuję zawartości pliku .mem i na razie mieszczę się w wyznaczonej
> normie.

A tam masz program czy RAM ?
Ja sie o (I)RAM martwie - 128 bajtow to tyle co nic :-)

>> 89c51 czy 89c52 ?
>> Bo tu chyba jest pies pogrzebany
>> http://www.8052.com/tutaddr.phtml
>
> 89c51

>> Swoja droga on tak to napisal, jakby pod 8051 bylo tak samo ... prawde
>> mowiac nie pamietam, wydaje mi sie, ze mozna bylo adresowac porty @Rn.
>
> Innymi słowy: da się jakoś dostać do tego portu z poziomu C? ;)

Dajac staly adres.

J.

do góry

On 15.03.2017 01:42, J.F. wrote:

> Za to oczywiscie w przerwaniu mozna duzo sp* - wiec moze wylacz i
> zobacz czy lepiej dziala.

Właśnie uświadomiłem sobie, że przyczyna nie może tutaj leżeć.
Jeszcze przed ustawieniem flagi globalnego zezwolenia na przerwania
(EA=1) próbuję skonfigurować DS1307 tak, aby na pinie SQW pojawił się
sygnał 1Hz.

Write_Byte_To_DS1307_RTC(0x07, 0x10);

Nie przynosi to jednak żadnego efektu.

do góry

On 15.03.2017 01:46, J.F. wrote:

> A tam masz program czy RAM ?

Jedno i drugie.


> Ja sie o (I)RAM martwie - 128 bajtow to tyle co nic :-)

To mniej-więcej tyle, co we współczesnych ATTiny. :)

Zawartość pliku poniżej. Nie wygląda to źle zważywszy na fakt, że
program jest prawie gotowy. Pewnie dałoby się odzyskać jeszcze parę
bajtów. :)

Jedyne co mnie zastanawia, to te "PAGED EXT. RAM" i "EXTERNAL RAM".
Powinienem to jakoś wyłączyć, skoro nie korzystam z zewnętrznej pamięci?
Jeśli tak, to gdzie?


Internal RAM layout:
0 1 2 3 4 5 6 7 8 9 A B C D E F
0x00:|0|0|0|0|0|0|0|0|a|a|b|b|b|b|b|b|
0x10:|b|c|c|c|c|c|c|c|c|c|c|c|c|c|c|c|
0x20:|c|c|c|c|c|c|c|d|d|d|d|e|e|e|e|e|
0x30:|e|e|e|e|e|e|e|e|e|e|e|e|e|e|e|e|
0x40:|e|e|Q|Q|Q|Q|Q|Q|S|S|S|S|S|S|S|S|
0x50:|S|S|S|S|S|S|S|S|S|S|S|S|S|S|S|S|
0x60:|S|S|S|S|S|S|S|S|S|S|S|S|S|S|S|S|
0x70:|S|S|S|S|S|S|S|S|S|S|S|S|S|S|S|S|
0x80:| | | | | | | | | | | | | | | | |
0x90:| | | | | | | | | | | | | | | | |
0xa0:| | | | | | | | | | | | | | | | |
0xb0:| | | | | | | | | | | | | | | | |
0xc0:| | | | | | | | | | | | | | | | |
0xd0:| | | | | | | | | | | | | | | | |
0xe0:| | | | | | | | | | | | | | | | |
0xf0:| | | | | | | | | | | | | | | | |
0-3:Reg Banks, T:Bit regs, a-z:Data, B:Bits, Q:Overlay, I:iData,
S:Stack, A:Absolute

Stack starts at: 0x48 (sp set to 0x47) with 56 bytes available.

Other memory:
Name Start End Size Max
---------------- -------- -------- -------- --------
PAGED EXT. RAM 0 256
EXTERNAL RAM 0 1024
ROM/EPROM/FLASH 0x0000 0x0b4a 2891 4096

do góry

W dniu 2017-03-15 o 01:46, J.F. pisze:

> A tam masz program czy RAM ?
> Ja sie o (I)RAM martwie - 128 bajtow to tyle co nic :-)
>
Obecnie nic, ale kiedyś to było bardzo dużo :-)
W PiccoGALu w tych 128 bajtach mieściły nam się:
- stos procesora,
- stos danych FORTH,
- bufor danych programowania/odczytywania EEPROMów / GALi
- cały program w FORTH konkretnej (odczyt, zapis, weryfikacja...)
obsługi danej kostki.

Może mieściły to nie dokładne określenie, bo bufor danych zachodził
zazwyczaj na początek programu, ale był używany już po wykonaniu tego
początku programu i dojściu do głównej pętli.
P.G.

do góry

Użytkownik "Piotr Gałka" napisał w wiadomości grup
dyskusyjnych:oaavl5$ilc$...@n...chmurka.net...
W dniu 2017-03-15 o 01:46, J.F. pisze:
>> A tam masz program czy RAM ?
>> Ja sie o (I)RAM martwie - 128 bajtow to tyle co nic :-)
>
>Obecnie nic, ale kiedyś to było bardzo dużo :-)
>W PiccoGALu w tych 128 bajtach mieściły nam się:
>- stos procesora,
>- stos danych FORTH,

Ale w Forth nie miales takich ambitnych struktur danych :-)

>- bufor danych programowania/odczytywania EEPROMów / GALi

Dobrze ze z RS czy Centronicsa, bo juz z dyskietka mialbys problem :-)

J.

do góry

Użytkownik "Atlantis" napisał w wiadomości grup
dyskusyjnych:58c8e468$0$5160$6...@n...neostrada
.pl...
On 15.03.2017 01:42, J.F. wrote:
>> Za to oczywiscie w przerwaniu mozna duzo sp* - wiec moze wylacz i
>> zobacz czy lepiej dziala.

>Właśnie uświadomiłem sobie, że przyczyna nie może tutaj leżeć.
>Jeszcze przed ustawieniem flagi globalnego zezwolenia na przerwania
>(EA=1) próbuję skonfigurować DS1307 tak, aby na pinie SQW pojawił się
>sygnał 1Hz.

>Write_Byte_To_DS1307_RTC(0x07, 0x10);
>Nie przynosi to jednak żadnego efektu.

Wywolywac to w petli to powiedzmy 10ms ... i oscyloskop w dlon :-)
Chyba, ze masz dobrego cyfraka/analizator i zlapiesz pierwsze
operacje na I2C do spokojnej analizy.
Pamietaj, ze i2c nie moze byc zbyt szybkie - 100kHz powinny wszystkie
kosci akceptowac, powyzej jest niepewnosc.


J.

do góry

W dniu 2017-03-15 o 10:21, J.F. pisze:
>
>> - bufor danych programowania/odczytywania EEPROMów / GALi
>
> Dobrze ze z RS czy Centronicsa, bo juz z dyskietka mialbys problem :-)
>
Nie za bardzo rozumiem.
RS czy Centronics to sposób komunikacji, a dyskietka to inny świat.
Masz na myśli urządzenie, które miałoby zapisywać/odczytywać dane na
dyskietkach, czy może urządzenie podłączane jakoś zamiast dyskietki
(sposób komunikacji).
P.G.

do góry

Użytkownik "Piotr Gałka" napisał w wiadomości grup
dyskusyjnych:oab2oh$jpv$...@n...chmurka.net...
W dniu 2017-03-15 o 10:21, J.F. pisze:
>>> - bufor danych programowania/odczytywania EEPROMów / GALi
>> Dobrze ze z RS czy Centronicsa, bo juz z dyskietka mialbys problem
>> :-)
>
>Nie za bardzo rozumiem.
>RS czy Centronics to sposób komunikacji, a dyskietka to inny świat.
>Masz na myśli urządzenie, które miałoby zapisywać/odczytywać dane na
>dyskietkach, czy może urządzenie podłączane jakoś zamiast dyskietki
>(sposób komunikacji).

Dyskietka to tez sposob komunikacji - komputer nagrywa dane na
dyskietke, dyskietke sie wsadza w programator, programator czyta i
programuje kosc.

Tylko ta cholera ma sektor 512 bajtow :-)

Dyskietka to moze niezbyt szczesliwy przyklad, ale nawet na magnetofon
dane sie czesto blokami nagrywalo ..

J.

do góry

W dniu 2017-03-15 o 11:16, J.F. pisze:
> Użytkownik "Piotr Gałka" napisał w wiadomości grup
> dyskusyjnych:oab2oh$jpv$...@n...chmurka.net...
> W dniu 2017-03-15 o 10:21, J.F. pisze:
>>>> - bufor danych programowania/odczytywania EEPROMów / GALi
>>> Dobrze ze z RS czy Centronicsa, bo juz z dyskietka mialbys problem :-)
>>
>> Nie za bardzo rozumiem.
>> RS czy Centronics to sposób komunikacji, a dyskietka to inny świat.
>> Masz na myśli urządzenie, które miałoby zapisywać/odczytywać dane na
>> dyskietkach, czy może urządzenie podłączane jakoś zamiast dyskietki
>> (sposób komunikacji).
>
> Dyskietka to tez sposob komunikacji - komputer nagrywa dane na
> dyskietke, dyskietke sie wsadza w programator, programator czyta i
> programuje kosc.
>
> Tylko ta cholera ma sektor 512 bajtow :-)
>
Gdyby programator miał czytnik dyskietek (jak dla mnie to egzotyczny
pomysł) to tez jakoś można by sobie poradzić - procedura czytaj n-tą
16-kę bajtów z m-tego sektora.
P.G.

do góry

Użytkownik "Piotr Gałka" napisał w wiadomości grup
dyskusyjnych:oabn9j$rgj$...@n...chmurka.net...
W dniu 2017-03-15 o 11:16, J.F. pisze:
>> Dyskietka to tez sposob komunikacji - komputer nagrywa dane na
>> dyskietke, dyskietke sie wsadza w programator, programator czyta i
>> programuje kosc.
>
>> Tylko ta cholera ma sektor 512 bajtow :-)
>
>Gdyby programator miał czytnik dyskietek (jak dla mnie to egzotyczny
>pomysł)

Egzotyczny od czasu pecetow - a jak przygotowac eprom do pierwszego
peceta ? :-)

Mialem kiedys na uczelni taki programator - klawiatura hex i
komunikujemy sie.
Chyba nie uzywalem, z oczywistych wzgledow :-)

Za dyskietke bym ozlocil, za czytnik tasiemki perforowanej tez - o ile
mialbym perforator :-)

>to tez jakoś można by sobie poradzić - procedura czytaj n-tą 16-kę
>bajtów z m-tego sektora.

Istniejace kosci raczej nie mialy, ale moze daloby sie jakos obejsc i
faktycznie tak obsluzyc.
A co z zapisem ?
Odczyt epromu i zrzut do pliku uzyteczna funkcja :-)

W kazdym badz razie w miare rozwoju apetyt rosnie i 128 bajtow staje
sie niewystarczajace.
Szczegolnie jak sie komus marza jakies ambitne struktury w C, po 10
bajtow na klawisz :-)

J.

do góry