NOWY TEMAT
elektroda NewsGroups Forum Index - Elektronika Polska - Jak wykorzystać GPIO w mikrokontrolerach 8051 z SDCC do obsługi przycisków?
Goto page Previous 1, 2, 3, 4 Next
Zbych
Guest
Guest
Thu Feb 23, 2017 9:07 pm
W dniu 23.02.2017 o 10:20, Piotr Gałka pisze:
Quote:
W dniu 2017-02-16 o 08:33, Atlantis pisze:
On 14.02.2017 09:31, MKi wrote:
Zerknij do plików nagłówkowych SDCC, np:
__sbit __at (0x87) P0_7
Jak widać, to jest po prostu liczba, tylko z atrybutami __sbit __at
Może to pytanie zabrzmi głupio, ale jak powinna? wyglądać definicja
wskaźnika na coś takiego?
Chcę mieć funkcję inicjującą strukturę, która będzie przyjmowała jako
jeden z argumentów adres pinu (np. &P0_2).
Potem ten adres byłby przechowywany właśnie jako zmienna wskaźnikowa
wewnątrz struktury.
Nigdy nie programowałem w assemblerze.
Nigdy nie programowałem w C mikrokontrolerów.
Wydaje mi się, że skoro P0_7 jest już samo w sobie adresem pinu (czyli
wskaźnikiem na pin) to może uda Ci się obejść bez wskaźników na ten
wskaźnik.
Warunkiem jest żeby C potrafiło korzystać z rozkazów assemblera z
adresowaniem bitowym.
On 14.02.2017 09:31, MKi wrote:
Zerknij do plików nagłówkowych SDCC, np:
__sbit __at (0x87) P0_7
Jak widać, to jest po prostu liczba, tylko z atrybutami __sbit __at
Może to pytanie zabrzmi głupio, ale jak powinna? wyglądać definicja
wskaźnika na coś takiego?
Chcę mieć funkcję inicjującą strukturę, która będzie przyjmowała jako
jeden z argumentów adres pinu (np. &P0_2).
Potem ten adres byłby przechowywany właśnie jako zmienna wskaźnikowa
wewnątrz struktury.
Nigdy nie programowałem w assemblerze.
Nigdy nie programowałem w C mikrokontrolerów.
Wydaje mi się, że skoro P0_7 jest już samo w sobie adresem pinu (czyli
wskaźnikiem na pin) to może uda Ci się obejść bez wskaźników na ten
wskaźnik.
Warunkiem jest żeby C potrafiło korzystać z rozkazów assemblera z
adresowaniem bitowym.
Adresowanie bitowe w '51 wymaga podania numeru bitu od razu w rozkazie,
nie ma trybu adresowania pośredniego przez rejestr.
Spójrz na przykłady użycia:
http://www.keil.com/support/man/docs/is51/is51_setb.htm
http://www.keil.com/support/man/docs/is51/is51_clr.htm
Piotr GaĹka
Guest
Guest
Fri Feb 24, 2017 11:01 am
W dniu 2017-02-23 o 21:07, Zbych pisze:
Quote:
Wydaje mi się, że skoro P0_7 jest już samo w sobie adresem pinu (czyli
wskaźnikiem na pin) to może uda Ci się obejść bez wskaźników na ten
wskaźnik.
Warunkiem jest żeby C potrafiło korzystać z rozkazów assemblera z
adresowaniem bitowym.
Adresowanie bitowe w '51 wymaga podania numeru bitu od razu w rozkazie,
nie ma trybu adresowania pośredniego przez rejestr.
Całkiem być może, że nie ogarnąłem sedna zagadnienia.
wskaźnikiem na pin) to może uda Ci się obejść bez wskaźników na ten
wskaźnik.
Warunkiem jest żeby C potrafiło korzystać z rozkazów assemblera z
adresowaniem bitowym.
Adresowanie bitowe w '51 wymaga podania numeru bitu od razu w rozkazie,
nie ma trybu adresowania pośredniego przez rejestr.
Całkiem być może, że nie ogarnąłem sedna zagadnienia.
Rozumiałem, że:
Atlantis chce przechowywać wskaźniki na piny. A ponieważ we
wcześniejszych jego pracach (z innymi procesorami) wymagało to użycia
jakichś wskaźników w C to teraz też myśli jak zrobić sobie wskaźniki na
te numerki określające bitowe adresy pinów.
Z jego wypowiedzi rozumiałem, że dotychczas przechowywał wskaźniki na
piny, a nie wskaźniki na wskaźniki na piny.
---- koniec opisu jak ja to rozumiałem ----
Chciałem jedynie zwrócić uwagę, że _być_może_ szuka czegoś co ma gotowe,
że _być_może_ wystarczy posłużyć się (i przechowywać) te bitowe adresy
pinów.
Quote:
Spójrz na przykłady użycia:
http://www.keil.com/support/man/docs/is51/is51_setb.htm
http://www.keil.com/support/man/docs/is51/is51_clr.htm
http://www.keil.com/support/man/docs/is51/is51_setb.htm
http://www.keil.com/support/man/docs/is51/is51_clr.htm
W latach 90-tych napisałem assembler dla 51-ki. Niedawno mnie zmuszono
aby go przekompilować aby pod Win10 działał. Miałem z tym trochę
zaskakujących problemów ale się udało.
Nie pamiętałem oczywiście jak ten adres pinu jest podawany do rozkazu,
ale nie rozumiem jakie to ma znaczenie.
Nigdy nie używałem C dla żadnego mikrokontrolera. Wyobrażałem sobie, że
C musi być trochę rozszerzane pod dany procesor.
Czyli zakładałem, że w C dla 51-ki powinna być jakaś funkcja
biblioteczna typu setbit() przyjumująca jako parametr jego adres i
potrafiąca przetłumaczyć to na assembler nawet jak nie ma adresowania
przez rejestr.
P.G.
Zbych
Guest
Guest
Fri Feb 24, 2017 11:28 am
W dniu 24.02.2017 o 11:01, Piotr Gałka pisze:
Quote:
Nigdy nie używałem C dla żadnego mikrokontrolera. Wyobrażałem sobie, że
C musi być trochę rozszerzane pod dany procesor.
Czyli zakładałem, że w C dla 51-ki powinna być jakaś funkcja
biblioteczna typu setbit() przyjumująca jako parametr jego adres i
potrafiąca przetłumaczyć to na assembler nawet jak nie ma adresowania
przez rejestr.
C musi być trochę rozszerzane pod dany procesor.
Czyli zakładałem, że w C dla 51-ki powinna być jakaś funkcja
biblioteczna typu setbit() przyjumująca jako parametr jego adres i
potrafiąca przetłumaczyć to na assembler nawet jak nie ma adresowania
przez rejestr.
Napiszę najprościej jak potrafię. Numer bitu w setb i clr musi być na
sztywno wpisany w rozkaz, nie ma możliwości zrobienia z niego parametru.
Jak chcesz parametryzować, to wracasz do opisywanego wcześniej
rozwiązania "adres portu + maska bitowa".
Piotr GaĹka
Guest
Guest
Fri Feb 24, 2017 11:38 am
W dniu 2017-02-24 o 11:28, Zbych pisze:
Quote:
W dniu 24.02.2017 o 11:01, Piotr Gałka pisze:
Nigdy nie używałem C dla żadnego mikrokontrolera. Wyobrażałem sobie, że
C musi być trochę rozszerzane pod dany procesor.
Czyli zakładałem, że w C dla 51-ki powinna być jakaś funkcja
biblioteczna typu setbit() przyjumująca jako parametr jego adres i
potrafiąca przetłumaczyć to na assembler nawet jak nie ma adresowania
przez rejestr.
Napiszę najprościej jak potrafię. Numer bitu w setb i clr musi być na
sztywno wpisany w rozkaz, nie ma możliwości zrobienia z niego parametru.
Dzięki. W końcu dotarło do mnie
Nigdy nie używałem C dla żadnego mikrokontrolera. Wyobrażałem sobie, że
C musi być trochę rozszerzane pod dany procesor.
Czyli zakładałem, że w C dla 51-ki powinna być jakaś funkcja
biblioteczna typu setbit() przyjumująca jako parametr jego adres i
potrafiąca przetłumaczyć to na assembler nawet jak nie ma adresowania
przez rejestr.
Napiszę najprościej jak potrafię. Numer bitu w setb i clr musi być na
sztywno wpisany w rozkaz, nie ma możliwości zrobienia z niego parametru.
Dzięki. W końcu dotarło do mnie
Jakoś nie zauważyłem, że to wymagałoby dynamicznego dopasowywania kodu
programu w czasie jego pracy
P.G.
J.F.
Guest
Guest
Fri Feb 24, 2017 12:06 pm
Użytkownik "Piotr Gałka" napisał w wiadomości grup
dyskusyjnych:o8p09b$l8c$1@news.chmurka.net...
W dniu 2017-02-23 o 21:07, Zbych pisze:
Quote:
Wydaje mi się, że skoro P0_7 jest już samo w sobie adresem pinu
(czyli
wskaźnikiem na pin) to może uda Ci się obejść bez wskaźników na
ten
wskaźnik.
Warunkiem jest żeby C potrafiło korzystać z rozkazów assemblera z
adresowaniem bitowym.
Adresowanie bitowe w '51 wymaga podania numeru bitu od razu w
rozkazie,
nie ma trybu adresowania pośredniego przez rejestr.
Całkiem być może, że nie ogarnąłem sedna zagadnienia.
Rozumiałem, że:
Atlantis chce przechowywać wskaźniki na piny. A ponieważ we
wcześniejszych jego pracach (z innymi procesorami) wymagało to użycia
jakichś wskaźników w C to teraz też myśli jak zrobić sobie wskaźniki
na te numerki określające bitowe adresy pinów.
Z jego wypowiedzi rozumiałem, że dotychczas przechowywał wskaźniki na
piny, a nie wskaźniki na wskaźniki na piny.
---- koniec opisu jak ja to rozumiałem ----
Chciałem jedynie zwrócić uwagę, że _być_może_ szuka czegoś co ma
gotowe, że _być_może_ wystarczy posłużyć się (i przechowywać) te
bitowe adresy pinów.
(czyli
wskaźnikiem na pin) to może uda Ci się obejść bez wskaźników na
ten
wskaźnik.
Warunkiem jest żeby C potrafiło korzystać z rozkazów assemblera z
adresowaniem bitowym.
Adresowanie bitowe w '51 wymaga podania numeru bitu od razu w
rozkazie,
nie ma trybu adresowania pośredniego przez rejestr.
Całkiem być może, że nie ogarnąłem sedna zagadnienia.
Rozumiałem, że:
Atlantis chce przechowywać wskaźniki na piny. A ponieważ we
wcześniejszych jego pracach (z innymi procesorami) wymagało to użycia
jakichś wskaźników w C to teraz też myśli jak zrobić sobie wskaźniki
na te numerki określające bitowe adresy pinów.
Z jego wypowiedzi rozumiałem, że dotychczas przechowywał wskaźniki na
piny, a nie wskaźniki na wskaźniki na piny.
---- koniec opisu jak ja to rozumiałem ----
Chciałem jedynie zwrócić uwagę, że _być_może_ szuka czegoś co ma
gotowe, że _być_może_ wystarczy posłużyć się (i przechowywać) te
bitowe adresy pinów.
Ale wlasnie nie mozesz.
Mozesz napisac w C np
P0_7 = 1
i miec nadzieje, ze kompilator skompiluje z uzyciem wlasciwych
rozkazow.
Ale nie mozesz napisac
wskaznik = P0_7 ;
.....
*wskaznik = 1 ;
bo ... nie ma takiego rozkazu, ktory moglby kompilator uzyc, aby
potrafil zaadresowac bit o numerze w jakims rejestrze podanym.
wiec nie da sie np zrobic funkcji ktora poczeka na nacisniecie
klawisza,
cos w rodzaju
void function wait_for_key(int keynr)
{
.....
}
(zadziala jako macro)
Nie da sie tez zrobic petli sprawdzi bity po kolei itp ...
Quote:
Nigdy nie używałem C dla żadnego mikrokontrolera. Wyobrażałem sobie,
że C musi być trochę rozszerzane pod dany procesor.
Czyli zakładałem, że w C dla 51-ki powinna być jakaś funkcja
biblioteczna typu setbit() przyjumująca jako parametr jego adres i
potrafiąca przetłumaczyć to na assembler nawet jak nie ma adresowania
przez rejestr.
że C musi być trochę rozszerzane pod dany procesor.
Czyli zakładałem, że w C dla 51-ki powinna być jakaś funkcja
biblioteczna typu setbit() przyjumująca jako parametr jego adres i
potrafiąca przetłumaczyć to na assembler nawet jak nie ma adresowania
przez rejestr.
No i zakladam, ze C jest rozszerzone (w odpowiednio ambitnym
kompilatorze), i kompilator potrafi to skompilowac ... o ile adres
jest znany w czasie kompilacji.
Inaczej, to pozostaja dwie mozliwosci:
1) przygotowujemy sobie odpowiedni rozkaz w pamieci i wykonujemy go.
cos typu
setbit: ; A zawiera nr bitu
mov setbitr+1, A
setbitr: setb 0
ret
ha, ha - zycze powodzenia na 8051, z jej rozdzielonymi pamieciami
ale jesli system zawiera dodatkowy RAM, ktory bedzie widoczny jako
pamiec zewnetrzna i programu jednoczesnie, to moze by sie nawet udalo
(np na tym DScostam z bateryjka).
2) przygotowujemy sobie siec rozkazow:
setb 0
ret
setb 1
ret
setb 2
ret
....
i wyliczamy sobie to ktorego adresu skoczyc ... imo - niemal
niedopuszczalne, ale jak trzeba, to trzeba :-)
J.
AlexY
Guest
Guest
Fri Feb 24, 2017 9:00 pm
Piotr Gałka pisze:
Quote:
W dniu 2017-02-24 o 11:28, Zbych pisze:
W dniu 24.02.2017 o 11:01, Piotr Gałka pisze:
Nigdy nie używałem C dla żadnego mikrokontrolera. Wyobrażałem sobie, że
C musi być trochę rozszerzane pod dany procesor.
Czyli zakładałem, że w C dla 51-ki powinna być jakaś funkcja
biblioteczna typu setbit() przyjumująca jako parametr jego adres i
potrafiąca przetłumaczyć to na assembler nawet jak nie ma adresowania
przez rejestr.
Napiszę najprościej jak potrafię. Numer bitu w setb i clr musi być na
sztywno wpisany w rozkaz, nie ma możliwości zrobienia z niego parametru.
Dzięki. W końcu dotarło do mnie
Jakoś nie zauważyłem, że to wymagałoby dynamicznego dopasowywania kodu
programu w czasie jego pracy
W dniu 24.02.2017 o 11:01, Piotr Gałka pisze:
Nigdy nie używałem C dla żadnego mikrokontrolera. Wyobrażałem sobie, że
C musi być trochę rozszerzane pod dany procesor.
Czyli zakładałem, że w C dla 51-ki powinna być jakaś funkcja
biblioteczna typu setbit() przyjumująca jako parametr jego adres i
potrafiąca przetłumaczyć to na assembler nawet jak nie ma adresowania
przez rejestr.
Napiszę najprościej jak potrafię. Numer bitu w setb i clr musi być na
sztywno wpisany w rozkaz, nie ma możliwości zrobienia z niego parametru.
Dzięki. W końcu dotarło do mnie
Jakoś nie zauważyłem, że to wymagałoby dynamicznego dopasowywania kodu
programu w czasie jego pracy
Pamięci programu sam program nie może modyfikować więc też nie tak. Jak
musisz gasić/zapalać różne bity to będziesz musiał skakać w różne
miejsca programu z odpowiednim dla danego bitu poleceniem. Jeszcze
takiej potrzeby nie miałem ale do zrobienia.
--
AlexY
http://faq.enter.net.pl/simple-polish.html
http://www.pg.gda.pl/~agatek/netq.html
Atlantis
Guest
Guest
Sun Feb 26, 2017 11:32 am
On 23.02.2017 08:38, MKi wrote:
Quote:
Model large - obiekty te są alokowane w pamięci XRAM
(zazwyczaj do 64KB). Dostęp do każdej zmiennej poprzedzany
jest załadowaniem jej adresu do DPTR.
Stos też jest w XRAM, co bardzo wydłuża jego obsługę.
ły
(zazwyczaj do 64KB). Dostęp do każdej zmiennej poprzedzany
jest załadowaniem jej adresu do DPTR.
Stos też jest w XRAM, co bardzo wydłuża jego obsługę.
ły
Zapytam z czystej ciekawości, bo dzisiaj oczywiście dużo prościej
wykorzystać dowolny, potężny 32bitowy mikrokontroler z dużą ilością ramu
i flasha...
Niemniej jak wyglądała współpraca układów w rodzaju AT89C51 albo AT89C52
z zewnętrzną pamięcią? W przypadku RAM-u jak rozumiem dwa porty robiły
za multipleksowaną szynę adresową/danych, którą łączyło się z układem
pamięci poprzez 74LS573. W ten sposób można było zyskać całkiem sporą
ilość pamięci operacyjnej, ciągle przy dość małej pamięci stałej.
Możliwe było jeszcze dorzucenie jakiegoś EPROM-a i zapisanie w nim hex-a
z programem? Jeśli tak, to jak duże projekty w ten sposób tworzono?
Czy do takiej szyny można było podpiąć równocześnie jakiś wyświetlacz
alfanumeryczny HD44780 albo nawet jakiś kontroler Ethernetu?
AlexY
Guest
Guest
Sun Feb 26, 2017 1:47 pm
Atlantis pisze:
[..]
Quote:
Niemniej jak wyglądała współpraca układów w rodzaju AT89C51 albo AT89C52
z zewnętrzną pamięcią? W przypadku RAM-u jak rozumiem dwa porty robiły
za multipleksowaną szynę adresową/danych, którą łączyło się z układem
pamięci poprzez 74LS573. W ten sposób można było zyskać całkiem sporą
ilość pamięci operacyjnej, ciągle przy dość małej pamięci stałej.
Możliwe było jeszcze dorzucenie jakiegoś EPROM-a i zapisanie w nim hex-a
z programem? Jeśli tak, to jak duże projekty w ten sposób tworzono?
z zewnętrzną pamięcią? W przypadku RAM-u jak rozumiem dwa porty robiły
za multipleksowaną szynę adresową/danych, którą łączyło się z układem
pamięci poprzez 74LS573. W ten sposób można było zyskać całkiem sporą
ilość pamięci operacyjnej, ciągle przy dość małej pamięci stałej.
Możliwe było jeszcze dorzucenie jakiegoś EPROM-a i zapisanie w nim hex-a
z programem? Jeśli tak, to jak duże projekty w ten sposób tworzono?
Szyna adresowa jest 16 bitowa, jak trzeba więcej to konieczne jest
bankowanie pamięci.
Quote:
Czy do takiej szyny można było podpiąć równocześnie jakiś wyświetlacz
alfanumeryczny HD44780 albo nawet jakiś kontroler Ethernetu?
alfanumeryczny HD44780 albo nawet jakiś kontroler Ethernetu?
Jeśli HD jest w przestrzeni adresowej to czemu nie, nie może blokować
ani reagować na nie swoje adresy i musi wyrabiać się z timingami, albo
trzeba mu zrobić bufor.
--
AlexY
http://faq.enter.net.pl/simple-polish.html
http://www.pg.gda.pl/~agatek/netq.html
Dariusz Dorochowicz
Guest
Guest
Sun Feb 26, 2017 3:48 pm
W dniu 2017-02-26 o 13:47, AlexY pisze:
Quote:
Atlantis pisze:
[..]
Niemniej jak wyglądała współpraca układów w rodzaju AT89C51 albo AT89C52
z zewnętrzną pamięcią? W przypadku RAM-u jak rozumiem dwa porty robiły
za multipleksowaną szynę adresową/danych, którą łączyło się z układem
pamięci poprzez 74LS573. W ten sposób można było zyskać całkiem sporą
ilość pamięci operacyjnej, ciągle przy dość małej pamięci stałej.
Możliwe było jeszcze dorzucenie jakiegoś EPROM-a i zapisanie w nim hex-a
z programem? Jeśli tak, to jak duże projekty w ten sposób tworzono?
Szyna adresowa jest 16 bitowa, jak trzeba więcej to konieczne jest
bankowanie pamięci.
Czy do takiej szyny można było podpiąć równocześnie jakiś wyświetlacz
alfanumeryczny HD44780 albo nawet jakiś kontroler Ethernetu?
Jeśli HD jest w przestrzeni adresowej to czemu nie, nie może blokować
ani reagować na nie swoje adresy i musi wyrabiać się z timingami, albo
trzeba mu zrobić bufor.
[..]
Niemniej jak wyglądała współpraca układów w rodzaju AT89C51 albo AT89C52
z zewnętrzną pamięcią? W przypadku RAM-u jak rozumiem dwa porty robiły
za multipleksowaną szynę adresową/danych, którą łączyło się z układem
pamięci poprzez 74LS573. W ten sposób można było zyskać całkiem sporą
ilość pamięci operacyjnej, ciągle przy dość małej pamięci stałej.
Możliwe było jeszcze dorzucenie jakiegoś EPROM-a i zapisanie w nim hex-a
z programem? Jeśli tak, to jak duże projekty w ten sposób tworzono?
Szyna adresowa jest 16 bitowa, jak trzeba więcej to konieczne jest
bankowanie pamięci.
Czy do takiej szyny można było podpiąć równocześnie jakiś wyświetlacz
alfanumeryczny HD44780 albo nawet jakiś kontroler Ethernetu?
Jeśli HD jest w przestrzeni adresowej to czemu nie, nie może blokować
ani reagować na nie swoje adresy i musi wyrabiać się z timingami, albo
trzeba mu zrobić bufor.
Przypomnę jeszcze, że w zasadzie można szynę adresową określić jako
17-bitową. Była tam selekcja I/O i pamięci osobnymi liniami, ale
szczegółów to już nie pamiętam. W sumie to była selekcja I/O i pamięci,
ale selekcja pamięci programu też gdzieś tam się pętała, w sumie to już
mnie pamiętam szczegółów.
Pozdrawiam
DD
AlexY
Guest
Guest
Sun Feb 26, 2017 4:26 pm
Dariusz Dorochowicz pisze:
[..]
Quote:
Przypomnę jeszcze, że w zasadzie można szynę adresową określić jako
17-bitową. Była tam selekcja I/O i pamięci osobnymi liniami, ale
szczegółów to już nie pamiętam. W sumie to była selekcja I/O i pamięci,
ale selekcja pamięci programu też gdzieś tam się pętała, w sumie to już
mnie pamiętam szczegółów.
17-bitową. Była tam selekcja I/O i pamięci osobnymi liniami, ale
szczegółów to już nie pamiętam. W sumie to była selekcja I/O i pamięci,
ale selekcja pamięci programu też gdzieś tam się pętała, w sumie to już
mnie pamiętam szczegółów.
To jest właśnie bankowanie pamięci, nie ma poleceń adresujących 17-bitowo.
--
AlexY
http://faq.enter.net.pl/simple-polish.html
http://www.pg.gda.pl/~agatek/netq.html
Dariusz Dorochowicz
Guest
Guest
Sun Feb 26, 2017 5:17 pm
W dniu 2017-02-26 o 16:26, AlexY pisze:
Quote:
Dariusz Dorochowicz pisze:
[..]
Przypomnę jeszcze, że w zasadzie można szynę adresową określić jako
17-bitową. Była tam selekcja I/O i pamięci osobnymi liniami, ale
szczegółów to już nie pamiętam. W sumie to była selekcja I/O i pamięci,
ale selekcja pamięci programu też gdzieś tam się pętała, w sumie to już
mnie pamiętam szczegółów.
To jest właśnie bankowanie pamięci, nie ma poleceń adresujących 17-bitowo.
[..]
Przypomnę jeszcze, że w zasadzie można szynę adresową określić jako
17-bitową. Była tam selekcja I/O i pamięci osobnymi liniami, ale
szczegółów to już nie pamiętam. W sumie to była selekcja I/O i pamięci,
ale selekcja pamięci programu też gdzieś tam się pętała, w sumie to już
mnie pamiętam szczegółów.
To jest właśnie bankowanie pamięci, nie ma poleceń adresujących 17-bitowo.
Bankowaniem raczej określa się rozszerzenie standardowej przestrzeni
adresowej, a ja piszę że "w zasadzie" ;)
Pozdrawiam
DD
Atlantis
Guest
Guest
Sun Feb 26, 2017 8:21 pm
W dniu 2017-02-26 o 16:26, AlexY pisze:
Quote:
To jest właśnie bankowanie pamięci, nie ma poleceń adresujących 17-bitowo.
Czyli rozumiem, że teoretycznie w tych mikrokontrolerach możliwe jest
np. jednoczesne zastosowanie 64kB pamięci RAM i 64kB EPROM? Będą one
widoczne jako dwie osobne przestrzenie adresowe?
Możliwe było uruchamianie programu z zewnętrznego EPROM-a, czy też
pamięci tego rodzaju był wykorzystywane do przechowywania dodatkowych
zasobów, a kod należało upchnąć w tych kilku kB wewnętrznego flasha?
AlexY
Guest
Guest
Sun Feb 26, 2017 8:43 pm
Atlantis pisze:
Quote:
W dniu 2017-02-26 o 16:26, AlexY pisze:
To jest właśnie bankowanie pamięci, nie ma poleceń adresujących 17-bitowo.
Czyli rozumiem, że teoretycznie w tych mikrokontrolerach możliwe jest
np. jednoczesne zastosowanie 64kB pamięci RAM i 64kB EPROM? Będą one
widoczne jako dwie osobne przestrzenie adresowe?
To jest właśnie bankowanie pamięci, nie ma poleceń adresujących 17-bitowo.
Czyli rozumiem, że teoretycznie w tych mikrokontrolerach możliwe jest
np. jednoczesne zastosowanie 64kB pamięci RAM i 64kB EPROM? Będą one
widoczne jako dwie osobne przestrzenie adresowe?
Nie, przynajmniej jeśli dobrze zrozumiałem PDFa od 89c51/2.
Quote:
Możliwe było uruchamianie programu z zewnętrznego EPROM-a, czy też
pamięci tego rodzaju był wykorzystywane do przechowywania dodatkowych
zasobów, a kod należało upchnąć w tych kilku kB wewnętrznego flasha?
pamięci tego rodzaju był wykorzystywane do przechowywania dodatkowych
zasobów, a kod należało upchnąć w tych kilku kB wewnętrznego flasha?
"External Access Enable. EA must be strapped to GND in
order to enable the device to fetch code from external program
memory locations starting at 0000H up to FFFFH."
Jeśli dobrze zrozumiałem można podpiąć pamięć programu albo danych, nie
widzę mix'u, może jest jakiś kruczek.
--
AlexY
http://faq.enter.net.pl/simple-polish.html
http://www.pg.gda.pl/~agatek/netq.html
Dariusz Dorochowicz
Guest
Guest
Sun Feb 26, 2017 8:50 pm
W dniu 2017-02-26 o 20:43, AlexY pisze:
Quote:
Atlantis pisze:
W dniu 2017-02-26 o 16:26, AlexY pisze:
To jest właśnie bankowanie pamięci, nie ma poleceń adresujących
17-bitowo.
Czyli rozumiem, że teoretycznie w tych mikrokontrolerach możliwe jest
np. jednoczesne zastosowanie 64kB pamięci RAM i 64kB EPROM? Będą one
widoczne jako dwie osobne przestrzenie adresowe?
Nie, przynajmniej jeśli dobrze zrozumiałem PDFa od 89c51/2.
Możliwe było uruchamianie programu z zewnętrznego EPROM-a, czy też
pamięci tego rodzaju był wykorzystywane do przechowywania dodatkowych
zasobów, a kod należało upchnąć w tych kilku kB wewnętrznego flasha?
"External Access Enable. EA must be strapped to GND in
order to enable the device to fetch code from external program
memory locations starting at 0000H up to FFFFH."
Jeśli dobrze zrozumiałem można podpiąć pamięć programu albo danych, nie
widzę mix'u, może jest jakiś kruczek.
W dniu 2017-02-26 o 16:26, AlexY pisze:
To jest właśnie bankowanie pamięci, nie ma poleceń adresujących
17-bitowo.
Czyli rozumiem, że teoretycznie w tych mikrokontrolerach możliwe jest
np. jednoczesne zastosowanie 64kB pamięci RAM i 64kB EPROM? Będą one
widoczne jako dwie osobne przestrzenie adresowe?
Nie, przynajmniej jeśli dobrze zrozumiałem PDFa od 89c51/2.
Możliwe było uruchamianie programu z zewnętrznego EPROM-a, czy też
pamięci tego rodzaju był wykorzystywane do przechowywania dodatkowych
zasobów, a kod należało upchnąć w tych kilku kB wewnętrznego flasha?
"External Access Enable. EA must be strapped to GND in
order to enable the device to fetch code from external program
memory locations starting at 0000H up to FFFFH."
Jeśli dobrze zrozumiałem można podpiąć pamięć programu albo danych, nie
widzę mix'u, może jest jakiś kruczek.
Pewnie że jest. EA to tylko wybór pamięci programu, a na PSEN procek
wystawia czy chce dostępu do pamięci programu czy danych. Tyle, że
niekoniecznie da się w ten sposób dostać do całej pamięci, bo zdaje się
że na początku są mapowane rejestry.
Pozdrawiam
DD
Atlantis
Guest
Guest
Sun Feb 26, 2017 9:02 pm
W dniu 2017-02-26 o 20:50, Dariusz Dorochowicz pisze:
Quote:
Pewnie że jest. EA to tylko wybór pamięci programu, a na PSEN procek
wystawia czy chce dostępu do pamięci programu czy danych. Tyle, że
niekoniecznie da się w ten sposób dostać do całej pamięci, bo zdaje się
że na początku są mapowane rejestry.
wystawia czy chce dostępu do pamięci programu czy danych. Tyle, że
niekoniecznie da się w ten sposób dostać do całej pamięci, bo zdaje się
że na początku są mapowane rejestry.
Pytam, bo wydaje mi się, że kiedyś widziałem schemat na którym do MCU
jednocześnie podłączony był RAM i EPROM. Jeśli dobrze pamiętam, piny
sterujące były podłączone przez jakąś bramkę. Na 90% jestem pewien, że
to właśnie dotyczyło czegoś w stylu AT89C51/52, jednak mogę się mylić.
Dlatego właśnie pytam. ;)
Innymi słowy:
1) Mogę korzystać albo z wewnętrznej pamięci programu, albo zewnętrznej
- w zależności od sposobu podłączenia pinu EA.
2) Zewnętrzna pamięć RAM ma wspólną przestrzeń adresową z wewnętrzną, a
więc jej pewna ilość na początku (128 bajtów?) będzie niewykorzystana.
Dobrze to rozumiem?
I jeszcze jedno pytanie: jak w tej rodzinie wygląda kwestia korzystania
ze stałych definiowanych w pamięci programu? Istnieje coś takiego, jak
PROGMEM w AVR-ach, czy też jedynym wyjściem jest zwykłe tworzenie kopii
tych stałych w pamięci RAM? Bo chyba nie jest tak dobrze, że wystarczy
zdefiniować zmienną jako "const", jak we współczesnych mikrokontrolerach
32-bitowych?
elektroda NewsGroups Forum Index - Elektronika Polska - Jak wykorzystać GPIO w mikrokontrolerach 8051 z SDCC do obsługi przycisków?