NOWY TEMAT
elektroda NewsGroups Forum Index - Elektronika Polska - Różnice w programowaniu mikrokontrolerów AVR, PIC, ARM7/ARM9 i STM32 w C/C++
Goto page Previous 1, 2, 3, 4 Next
Zbych
Guest
Guest
Sun Feb 07, 2016 8:49 pm
W dniu 2016-02-07 o 20:39, Sebastian Biały pisze:
Quote:
On 2016-02-07 20:06, Zbych wrote:
GCC jakiś czas temu nauczyło się rozróżniać przestrzenie adresowe:
https://gcc.gnu.org/onlinedocs/gcc/Named-Address-Spaces.html
To nie wystarczy. Np. w przypadku AVR każda funkcja przyjmująca wskaźnik
musiala by się generować osobno dla każdej kombinacji typów
wskaźnikowych jakie w programie wystąpią. Dlatego nalezy użyć __flash
przy wskaźnikowym argumencie funkcji, czyli znowu wychodzi na to że bez
rękodzieła ani rusz.
GCC jakiś czas temu nauczyło się rozróżniać przestrzenie adresowe:
https://gcc.gnu.org/onlinedocs/gcc/Named-Address-Spaces.html
To nie wystarczy. Np. w przypadku AVR każda funkcja przyjmująca wskaźnik
musiala by się generować osobno dla każdej kombinacji typów
wskaźnikowych jakie w programie wystąpią. Dlatego nalezy użyć __flash
przy wskaźnikowym argumencie funkcji, czyli znowu wychodzi na to że bez
rękodzieła ani rusz.
To jest raczej oczywiste, tyle że nie trzeba ręcznie wstawiać
pgm_read_cośtam.
Marek
Guest
Guest
Sun Feb 07, 2016 9:25 pm
On Sun, 7 Feb 2016 20:39:36 +0100, Sebastian
Biały<heby@poczta.onet.pl> wrote:
Quote:
To nie wystarczy. Np. w przypadku AVR każda funkcja przyjmująca
wskaźnik
musiala by się generować osobno dla każdej kombinacji typów
wskaźnikowych jakie w programie wystąpią. Dlatego nalezy użyć
__flash
przy wskaźnikowym argumencie funkcji, czyli znowu wychodzi na to że
bez
rękodzieła ani rusz.
wskaźnik
musiala by się generować osobno dla każdej kombinacji typów
wskaźnikowych jakie w programie wystąpią. Dlatego nalezy użyć
__flash
przy wskaźnikowym argumencie funkcji, czyli znowu wychodzi na to że
bez
rękodzieła ani rusz.
A sdcc testowałeś? O ile pamiętam ają port avr. Port pic16 (układy
18F) daje radę z mieszaniem wskaźników ram/flash (nie odróżnia os
strony programisty), więc może i port avr podobnie.
--
Marek
Sebastian BiaĹy
Guest
Guest
Sun Feb 07, 2016 9:29 pm
On 2016-02-07 21:25, Marek wrote:
Quote:
A sdcc testowałeś?
A obsługuje C++? Bo jak nie to jest *bezużyteczny*.
J.F.
Guest
Guest
Sun Feb 07, 2016 10:03 pm
Dnia Sun, 7 Feb 2016 12:22:29 +0100, Sebastian Biały napisał(a):
Quote:
On 2016-02-07 11:30, J.F. wrote:
Dlaczego? Wystarczy zrobić
#define PROGMEM
A co zrobisz z pgm_read_float, pgm_read_byte i okolicą?
#define na najprostsza konstrukcje "zwyklego C" ?
Pytanie co zrobisz gdy portujesz harvard->harvard i obie implementacje
radośnie wymysliły własny lepszy sposób na grzebanie w rom.
Dlaczego? Wystarczy zrobić
#define PROGMEM
A co zrobisz z pgm_read_float, pgm_read_byte i okolicą?
#define na najprostsza konstrukcje "zwyklego C" ?
Pytanie co zrobisz gdy portujesz harvard->harvard i obie implementacje
radośnie wymysliły własny lepszy sposób na grzebanie w rom.
Nadal #define moze problem rozwiazac.
A jesli nie ... no coz, za cos ci programsci musza brac pieniadze :-)
J.
J.F.
Guest
Guest
Sun Feb 07, 2016 10:15 pm
Dnia Sun, 7 Feb 2016 13:03:39 +0100, janusz_k napisał(a):
Quote:
W dniu 2016-02-07 o 08:28, slawek pisze:
On Sat, 6 Feb 2016 00:08:06 +0100, Grzegorz Kurczyk
AVR ma oddzielną pamięć programu i danych co powoduje, że np do
Intel x86 też ma oddzielnie segmenty kodu i danych. I co? I jakoś z tym
żyjemy.
To kompilator ma a nie procek, x86 od zawsze miały wspólną przestrzeń
danych i programu.
On Sat, 6 Feb 2016 00:08:06 +0100, Grzegorz Kurczyk
AVR ma oddzielną pamięć programu i danych co powoduje, że np do
Intel x86 też ma oddzielnie segmenty kodu i danych. I co? I jakoś z tym
żyjemy.
To kompilator ma a nie procek, x86 od zawsze miały wspólną przestrzeń
danych i programu.
Przestrzen wspolna, adresacja jedna, ale i tu moze segmentacja
namieszac. Ktos jeszcze pamieta te modele pamieci w C - tiny, small,
huge .. 6 ich bylo :-(
od x386 sie troche zmienilo
Quote:
Te segmenty są na siłę robione i to dopiero ostatnimi
czasy jak się pojawiły wirusy korzystające z przepełnienia
stosu.
czasy jak się pojawiły wirusy korzystające z przepełnienia
stosu.
No, nawet w pelnej adresacji 32 bit te segmenty maja pewien sens -
pozwalaja rozszerzyc przestrzen wirtualna, dynamicznie zarzadzac
rozmiarem ... i oszczedniej to robic niz w 64 bit :-)
Quote:
Intel x86 też ma oddzielne instrukcje mov i in.
Łaskawco rozrózniaj instrukcje dostępu do pamięci "mov" od instrukcji
we/wy "in", bo jak na razie to mieszasz pojęcia.
Łaskawco rozrózniaj instrukcje dostępu do pamięci "mov" od instrukcji
we/wy "in", bo jak na razie to mieszasz pojęcia.
Poniekad ten sam problem, tylko w jeszcze innym miejscu.
taki 8080 nie mial np adresacji in/out posredniej czy przez rejestr,
tylko wpisany w rozkaz, - co uniemozliwialo zadanie adresu parametrem
- musial byc z gory okreslony.
J.
Marek
Guest
Guest
Sun Feb 07, 2016 11:15 pm
On Sun, 7 Feb 2016 21:29:41 +0100, Sebastian
Biały<heby@poczta.onet.pl> wrote:
Quote:
A obsługuje C++? Bo jak nie to jest *bezużyteczny*.
Broń Boże :)
--
Marek
janusz_k
Guest
Guest
Mon Feb 08, 2016 9:28 pm
W dniu 2016-02-07 o 22:15, J.F. pisze:
Quote:
Dnia Sun, 7 Feb 2016 13:03:39 +0100, janusz_k napisał(a):
W dniu 2016-02-07 o 08:28, slawek pisze:
On Sat, 6 Feb 2016 00:08:06 +0100, Grzegorz Kurczyk
AVR ma oddzielną pamięć programu i danych co powoduje, że np do
Intel x86 też ma oddzielnie segmenty kodu i danych. I co? I jakoś z tym
żyjemy.
To kompilator ma a nie procek, x86 od zawsze miały wspólną przestrzeń
danych i programu.
Przestrzen wspolna, adresacja jedna, ale i tu moze segmentacja
namieszac. Ktos jeszcze pamieta te modele pamieci w C - tiny, small,
huge .. 6 ich bylo
Pewnie, pisałem na nie. Co nie zmienia faktu że można było wpisać
W dniu 2016-02-07 o 08:28, slawek pisze:
On Sat, 6 Feb 2016 00:08:06 +0100, Grzegorz Kurczyk
AVR ma oddzielną pamięć programu i danych co powoduje, że np do
Intel x86 też ma oddzielnie segmenty kodu i danych. I co? I jakoś z tym
żyjemy.
To kompilator ma a nie procek, x86 od zawsze miały wspólną przestrzeń
danych i programu.
Przestrzen wspolna, adresacja jedna, ale i tu moze segmentacja
namieszac. Ktos jeszcze pamieta te modele pamieci w C - tiny, small,
huge .. 6 ich bylo
Pewnie, pisałem na nie. Co nie zmienia faktu że można było wpisać
dowolny adres i pobrać dane czy zapisać z całej pamięci RAM, dopiero
w nowych teraz prockach jest blokada na poziomie jądra procka, tylko
procesy systemowe w ringu 0 mają całkowity dostęp.
Quote:
Intel x86 też ma oddzielne instrukcje mov i in.
Łaskawco rozrózniaj instrukcje dostępu do pamięci "mov" od instrukcji
we/wy "in", bo jak na razie to mieszasz pojęcia.
Poniekad ten sam problem, tylko w jeszcze innym miejscu.
taki 8080 nie mial np adresacji in/out posredniej czy przez rejestr,
tylko wpisany w rozkaz, - co uniemozliwialo zadanie adresu parametrem
- musial byc z gory okreslony.
Łaskawco rozrózniaj instrukcje dostępu do pamięci "mov" od instrukcji
we/wy "in", bo jak na razie to mieszasz pojęcia.
Poniekad ten sam problem, tylko w jeszcze innym miejscu.
taki 8080 nie mial np adresacji in/out posredniej czy przez rejestr,
tylko wpisany w rozkaz, - co uniemozliwialo zadanie adresu parametrem
- musial byc z gory okreslony.
Jarku sprawdz zanim napiszesz, cytuję:
"Other Instructions
IN Port Data from Port placed in A register.
OUT Port Data from A register placed in Port."
http://fms.komkon.org/comp/CPUs/8080.txt
--
Pozdr
Janusz_K
J.F.
Guest
Guest
Tue Feb 09, 2016 12:53 am
Dnia Mon, 8 Feb 2016 21:28:14 +0100, janusz_k napisał(a):
Quote:
W dniu 2016-02-07 o 22:15, J.F. pisze:
Intel x86 też ma oddzielnie segmenty kodu i danych. I co? I jakoś z tym
żyjemy.
To kompilator ma a nie procek, x86 od zawsze miały wspólną przestrzeń
danych i programu.
Przestrzen wspolna, adresacja jedna, ale i tu moze segmentacja
namieszac. Ktos jeszcze pamieta te modele pamieci w C - tiny, small,
huge .. 6 ich bylo
Pewnie, pisałem na nie. Co nie zmienia faktu że można było wpisać
dowolny adres i pobrać dane czy zapisać z całej pamięci RAM,
Intel x86 też ma oddzielnie segmenty kodu i danych. I co? I jakoś z tym
żyjemy.
To kompilator ma a nie procek, x86 od zawsze miały wspólną przestrzeń
danych i programu.
Przestrzen wspolna, adresacja jedna, ale i tu moze segmentacja
namieszac. Ktos jeszcze pamieta te modele pamieci w C - tiny, small,
huge .. 6 ich bylo
Pewnie, pisałem na nie. Co nie zmienia faktu że można było wpisać
dowolny adres i pobrać dane czy zapisać z całej pamięci RAM,
W modelu small byl jednak segment kodu, segment danych, a
adres/wskaznik tylko 16 bitow liczyl.
Quote:
Intel x86 też ma oddzielne instrukcje mov i in.
Łaskawco rozrózniaj instrukcje dostępu do pamięci "mov" od instrukcji
we/wy "in", bo jak na razie to mieszasz pojęcia.
Poniekad ten sam problem, tylko w jeszcze innym miejscu.
taki 8080 nie mial np adresacji in/out posredniej czy przez rejestr,
tylko wpisany w rozkaz, - co uniemozliwialo zadanie adresu parametrem
- musial byc z gory okreslony.
Jarku sprawdz zanim napiszesz, cytuję:
"Other Instructions
IN Port Data from Port placed in A register.
OUT Port Data from A register placed in Port."
http://fms.komkon.org/comp/CPUs/8080.txt
Łaskawco rozrózniaj instrukcje dostępu do pamięci "mov" od instrukcji
we/wy "in", bo jak na razie to mieszasz pojęcia.
Poniekad ten sam problem, tylko w jeszcze innym miejscu.
taki 8080 nie mial np adresacji in/out posredniej czy przez rejestr,
tylko wpisany w rozkaz, - co uniemozliwialo zadanie adresu parametrem
- musial byc z gory okreslony.
Jarku sprawdz zanim napiszesz, cytuję:
"Other Instructions
IN Port Data from Port placed in A register.
OUT Port Data from A register placed in Port."
http://fms.komkon.org/comp/CPUs/8080.txt
No - dane byly w rejestrze A, a adres portu ?
W drugim bajcie rozkazu.
Jesli miales w systemie np dwa porty szeregowe (UART), to nie mogles w
systemie napisac jednej procedury ich obslugi, do ktorej bys przekazal
adres bazowy sterownika portu. Adres byl staly.
Podobnie w C nie mogles napisac funcji, ktora by dostala adres portu
jako parametr. Musial byc staly i znany juz w czasie kompilacji.
Tzn mogles - jesli program byl w RAM a nie ROM, to program mogl sobie
zmienic bajt pamieci odpowiedniego rozkazu.
Cos mi chodzi po glowie, ze podobna zmiana kodu musiala byc stosowana
takze w x86, ale to jeszcze jakis inny rozkaz musial byc, bo IN/OUT
mialy mozliwosc adresowania DX.
A jak uwzglednic kolejki i cache, to sprawa przestaje byc prosta :-)
J.
slawek
Guest
Guest
Tue Feb 09, 2016 10:30 am
On Sun, 7 Feb 2016 13:03:39 +0100, janusz_k <Janusz_kk@o2.pl> wrote:
Quote:
To kompilator ma a nie procek, x86 od zawsze miały wspólną
przestrzeń
danych i programu. Te segmenty są na siłę robione i to dopiero
ostatnimi
czasy jak się pojawiły wirusy korzystające z przepełnienia
przestrzeń
danych i programu. Te segmenty są na siłę robione i to dopiero
ostatnimi
czasy jak się pojawiły wirusy korzystające z przepełnienia
Ciekawe. Rejestry DS i CS to w x86 pojawiły się jakieś 30 lat temu...
J.F.
Guest
Guest
Tue Feb 09, 2016 11:05 am
Użytkownik "slawek" napisał w wiadomości grup
dyskusyjnych:almarsoft.479110229799051561@news.v.pl...
On Sun, 7 Feb 2016 13:03:39 +0100, janusz_k <Janusz_kk@o2.pl> wrote:
Quote:
To kompilator ma a nie procek, x86 od zawsze miały wspólną
przestrzeń
danych i programu. Te segmenty są na siłę robione i to dopiero
ostatnimi
czasy jak się pojawiły wirusy korzystające z przepełnienia
Ciekawe. Rejestry DS i CS to w x86 pojawiły się jakieś 30 lat temu...
przestrzeń
danych i programu. Te segmenty są na siłę robione i to dopiero
ostatnimi
czasy jak się pojawiły wirusy korzystające z przepełnienia
Ciekawe. Rejestry DS i CS to w x86 pojawiły się jakieś 30 lat temu...
Ale pamiec i przestrzen byla jedna.
Jak sie do DS i CS wpisalo to samo, to mozna bylo kod traktowac jak
dane.
Zreszta wskaznik zawieral i segment, wiec mozna bylo jednolicie
adresowac, chyba, ze ktos sie uparl przy modelu small ...
J.
slawek
Guest
Guest
Tue Feb 09, 2016 11:40 am
On Sun, 7 Feb 2016 11:28:05 +0100, "J.F."
<jfox_xnospamx@poczta.onet.pl> wrote:
Quote:
Osobna pamiec programu ... program w C
FYI Microsoft Windows od wersji 1.0 pozwala określić kod jako
DISCARDABLE, co umożliwia wywalenie go z RAM.
Ogólnie mylicie teoretyczne koncepcje architektury (HarVard wow!) z
tym że komputery są jakie są (np. pamięć slow i fast w Amidze) i nie
zawsze w praktyce jest tak prosto.
Język C ma standard. I ten standard jest po to aby nie trzeba było
zgłębiać architektury procesora, znać rozkazy czy wiedzieć czy dysk
jest magnetyczny czy SSD. Jeżeli w programie będzie const int, to
kompilator ma się zatroszczyć o to co z tym zrobić.
slawek
Guest
Guest
Tue Feb 09, 2016 11:45 am
On Tue, 9 Feb 2016 00:53:13 +0100, "J.F."
<jfox_xnospamx@poczta.onet.pl> wrote:
Quote:
Podobnie w C nie mogles napisac funcji, ktora by dostala adres portu
jako parametr. Musial byc staly i znany juz w czasie kompilacji.
jako parametr. Musial byc staly i znany juz w czasie kompilacji.
Bo nie można było użyć switch ew. zwykłego if ???
J.F.
Guest
Guest
Tue Feb 09, 2016 12:29 pm
Użytkownik "slawek" napisał w wiadomości grup
dyskusyjnych:almarsoft.6844744209820844352@news.v.pl...
On Tue, 9 Feb 2016 00:53:13 +0100, "J.F."
<jfox_xnospamx@poczta.onet.pl> wrote:
Quote:
Podobnie w C nie mogles napisac funcji, ktora by dostala adres
portu
jako parametr. Musial byc staly i znany juz w czasie kompilacji.
Bo nie można było użyć switch ew. zwykłego if ???
portu
jako parametr. Musial byc staly i znany juz w czasie kompilacji.
Bo nie można było użyć switch ew. zwykłego if ???
Mozna bylo, ale nadal adres musial byc znany z gory i tylko kilka
dostepnych do wyboru.
No chyba, ze chcesz switch na wszystkie mozliwe 256 adresow :-)
A tak prawde mowiac ... kto wie, czy nie efektywniej bylo skopiowac
tych kilka procedur niz dorabiac switcha w srodku ...
J.
mk
Guest
Guest
Wed Feb 10, 2016 7:14 pm
W dniu 2016-02-06 00:08, Grzegorz Kurczyk pisze:
Quote:
W dniu 05.02.2016 o 21:22, Atlantis pisze:
W dniu 2016-02-05 o 18:47, Sebastian Biały pisze:
Przy czym zaznaczam że czasami harvardowatość jest ukryta przed kodem
usera. Mówimy o procesorach gdzie jest to widoczne, jak na przykład AVR.
Tam jezyk C z definicji bedzie musiał być wspierany w mało przenośny
sposób aby wydajnie programować.
Hmm... O jakich aspektach kodu pod AVR tutaj mówimy?
AVR ma oddzielną pamięć programu i danych co powoduje, że np do
odczytania bajtu z pamięci programu (która ma szynę 16-bitową) służy
inny rozkaz procesora niż do czytania bajtu z pamięci danych z szyną
8-bitową. Czyli jeśli z poziomu języka wyższego poziomu chcesz np.
wyświetlić jakiś napis, to masz dwie różne definicje łańcucha
określające w jakiej pamięci ma być umieszczony i dwie różne procedury
do wyświetlania tego łańcucha w zależności gdzie był umieszczony. W
AVRGCC jest specjalny typ wskaźnikowy do stałych umieszczonych w pamięci
programu.
W dniu 2016-02-05 o 18:47, Sebastian Biały pisze:
Przy czym zaznaczam że czasami harvardowatość jest ukryta przed kodem
usera. Mówimy o procesorach gdzie jest to widoczne, jak na przykład AVR.
Tam jezyk C z definicji bedzie musiał być wspierany w mało przenośny
sposób aby wydajnie programować.
Hmm... O jakich aspektach kodu pod AVR tutaj mówimy?
AVR ma oddzielną pamięć programu i danych co powoduje, że np do
odczytania bajtu z pamięci programu (która ma szynę 16-bitową) służy
inny rozkaz procesora niż do czytania bajtu z pamięci danych z szyną
8-bitową. Czyli jeśli z poziomu języka wyższego poziomu chcesz np.
wyświetlić jakiś napis, to masz dwie różne definicje łańcucha
określające w jakiej pamięci ma być umieszczony i dwie różne procedury
do wyświetlania tego łańcucha w zależności gdzie był umieszczony. W
AVRGCC jest specjalny typ wskaźnikowy do stałych umieszczonych w pamięci
programu.
Wstępnie zaznaczę, że nie znam kompletnie AVRGCC...
Jeśli tak jest, że w AVRGCC *nie da się* zmienną wskaźnikową wskazać raz
na obiekt w pamięci programu, a potem na obiekt w pamięci zmiennych, to
jest to tylko ułomność owego AVRGCC. MCS-51 miał jeszcze bardziej
porypany model pamięci i do każdej z nich trzeba było się odwoływać
innymi instrukcjami maszynowymi. Niemniej kompilator Keila bez problemu
sobie z tym radził i standardowe wskaźniki C były implementowane w taki
sposób, że takim wskaźnikiem do woli można skakać pomiędzy różnymi
rodzajami pamięci MCS-51. Standard C nie wymusza, że wskaźnik musi być
li tylko adresem. Wskaźnik jak najbardziej może przechowywać dodatkowe
informacje pozwalające na dobranie się do wskazywanego obiektu bez
żadnych dwuznaczności.
W kompilatorze Keila na MCS-51 wskaźnik zajmował trzy bajty -- jedno
pole 8-bit typu pamięci + 16-bitowy adres. Oczywiście były też
niestandardowe wskaźniki służące do pokazywania tylko w wybranym typie
pamięci -- to dla tych co lubią/potrzebują optymalizować kod.
Quote:
Przy architekturze von Neumanna nie ma rozdzielenia pamięci danych od
pamięci programu. O tym czy procesor widzi pamięć w danej chwili kostkę
RAM, EPROM czy rejestr jakiegoś I/O decyduje dekoder adresów. Procek
może wykonywać rozkazy umieszczone w dowolnym obszarze przestrzeni
adresowej. Z punktu widzenia języka wysokiego poziomu w rodzaku C taki
sam wskaźnik char* może wskazywać na jakiś fragment kodu programu, daną
czy rejestr układu I/O.
pamięci programu. O tym czy procesor widzi pamięć w danej chwili kostkę
RAM, EPROM czy rejestr jakiegoś I/O decyduje dekoder adresów. Procek
może wykonywać rozkazy umieszczone w dowolnym obszarze przestrzeni
adresowej. Z punktu widzenia języka wysokiego poziomu w rodzaku C taki
sam wskaźnik char* może wskazywać na jakiś fragment kodu programu, daną
czy rejestr układu I/O.
Napomnę o Modified Harvard Architecture, współcześnie
najpopularniejszej, łączącej wspólną przestrzeń adresową i korzyści
posiadania dwóch (a może i jeszcze więcej) magistral.
pzdr
mk
janusz_k
Guest
Guest
Wed Feb 10, 2016 9:09 pm
W dniu 2016-02-09 o 00:53, J.F. pisze:
Quote:
Dnia Mon, 8 Feb 2016 21:28:14 +0100, janusz_k napisał(a):
W dniu 2016-02-07 o 22:15, J.F. pisze:
Intel x86 też ma oddzielnie segmenty kodu i danych. I co? I jakoś z tym
żyjemy.
To kompilator ma a nie procek, x86 od zawsze miały wspólną przestrzeń
danych i programu.
Przestrzen wspolna, adresacja jedna, ale i tu moze segmentacja
namieszac. Ktos jeszcze pamieta te modele pamieci w C - tiny, small,
huge .. 6 ich bylo
Pewnie, pisałem na nie. Co nie zmienia faktu że można było wpisać
dowolny adres i pobrać dane czy zapisać z całej pamięci RAM,
W modelu small byl jednak segment kodu, segment danych, a
adres/wskaznik tylko 16 bitow liczyl.
Ale segment mogłes zmienić, oczywiście nie było to atomatyczne, trzeba
W dniu 2016-02-07 o 22:15, J.F. pisze:
Intel x86 też ma oddzielnie segmenty kodu i danych. I co? I jakoś z tym
żyjemy.
To kompilator ma a nie procek, x86 od zawsze miały wspólną przestrzeń
danych i programu.
Przestrzen wspolna, adresacja jedna, ale i tu moze segmentacja
namieszac. Ktos jeszcze pamieta te modele pamieci w C - tiny, small,
huge .. 6 ich bylo
Pewnie, pisałem na nie. Co nie zmienia faktu że można było wpisać
dowolny adres i pobrać dane czy zapisać z całej pamięci RAM,
W modelu small byl jednak segment kodu, segment danych, a
adres/wskaznik tylko 16 bitow liczyl.
Ale segment mogłes zmienić, oczywiście nie było to atomatyczne, trzeba
było załadować rejestr segmentu ale się dało.
Quote:
Intel x86 też ma oddzielne instrukcje mov i in.
Łaskawco rozrózniaj instrukcje dostępu do pamięci "mov" od instrukcji
we/wy "in", bo jak na razie to mieszasz pojęcia.
Poniekad ten sam problem, tylko w jeszcze innym miejscu.
taki 8080 nie mial np adresacji in/out posredniej czy przez rejestr,
tylko wpisany w rozkaz, - co uniemozliwialo zadanie adresu parametrem
- musial byc z gory okreslony.
Jarku sprawdz zanim napiszesz, cytuję:
"Other Instructions
IN Port Data from Port placed in A register.
OUT Port Data from A register placed in Port."
http://fms.komkon.org/comp/CPUs/8080.txt
No - dane byly w rejestrze A, a adres portu ?
W drugim bajcie rozkazu.
A tak masz rację, pomyliło mi się z innym prockiem
--
Pozdr
Janusz_K
elektroda NewsGroups Forum Index - Elektronika Polska - Różnice w programowaniu mikrokontrolerów AVR, PIC, ARM7/ARM9 i STM32 w C/C++