On 16.02.2017 08:40, Zbych wrote:

> W c nie ma wskaźników na bity. Musisz to rozbić na adres portu (w
> przestrzeni adresowej __data) i maskę bitową.

Czyli innymi słowy nie ma możliwości na przekazanie do funkcji, a potem
przechowanie w strukturze konstrukcji takiej jak P0_2?
Będę musiał to zrobić tak, jak w AVR-ach? Czyli innymi słowy:

init(&struktura, &P0, 2);

wewnątrz tej funkcji adres portu zostanie zapisany w zmiennej
wskaźnikowej, numer pinu w porcie w zmiennej unsigned char. A potem już
standardowa operacja:

key_pressed = !(*port & (1<<pin))

O to chodzi?

do góry

Mam jeszcze jedno pytanie, dotyczące pamięci RAM w tych MCU.
Po pierwsze o co dokładnie chodzi o z modelami pamięci (--model-small,
--model-large) ustalanymi za pomocą flag kompilatora?
Natknąłem się też na dziwny objaw - po przekroczeniu 128 bajtów w wyniku
zdefiniowana kilku dodatkowych zmiennych program przestał się
kompilować, chociaż w tej chwili w makefile mam ustawiony iram na 256
bajtów (eksperymentuję z AT89C52). Mam rozumieć, że ta druga połowa
pamięci nie jest bezpośrednio dostępna?

do góry

Użytkownik "Atlantis" napisał w wiadomości grup
dyskusyjnych:o8f9ee$on6$...@n...icm.edu.pl...
>Mam jeszcze jedno pytanie, dotyczące pamięci RAM w tych MCU.
>Po pierwsze o co dokładnie chodzi o z modelami pamięci
>(--model-small,
>--model-large) ustalanymi za pomocą flag kompilatora?
>Natknąłem się też na dziwny objaw - po przekroczeniu 128 bajtów w
>wyniku
>zdefiniowana kilku dodatkowych zmiennych program przestał się
>kompilować, chociaż w tej chwili w makefile mam ustawiony iram na 256

kompilowac czy dzialac ?

>bajtów (eksperymentuję z AT89C52). Mam rozumieć, że ta druga połowa
>pamięci nie jest bezpośrednio dostępna?

Tak sobie bezposrednio.
51 ma 8-bit adresu danych, a gorna polowa przestrzeni zajeta na
rejestry.

w 8052 inststrukcje adresujace posrednio (czyli @R0, @R1) dobieraja
sie do calej pamieci,
pozostale tryby z adresami 80-FF - do rejestrow.

http://www.8052.com/tut8052

MOV R0,#90h ;Set the indirect address to 90h
MOV A,@R0 ;Read the contents of Internal RAM pointed to by R0

MOV A,90h ;Reads the contents of SFR 90h (P1)

Kompilator C musi to jakos respektowac, albo glupoty zrobi :-)

J.

do góry

> Mam jeszcze jedno pytanie, dotyczące pamięci RAM w tych MCU.
> Po pierwsze o co dokładnie chodzi o z modelami pamięci (--model-small,
> --model-large) ustalanymi za pomocą flag kompilatora?

Model small - wszystkie zmienne, parametry funkcji są alokowane
w podstawowej pamięci RAM (masz na to 128 bajtów).
O ile dobrze pamiętam, stos jest w IRAM (czyli górnych 128 bajtach).

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ę.
Pozdrowienia,
MKi

do góry

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.
P.G.

do góry

W dniu 23.02.2017 o 10:20, Piotr Gałka pisze:
> 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.

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.h
tm

do góry

W dniu 2017-02-23 o 21:07, Zbych pisze:
>> 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.

> 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.h
tm

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.

do góry

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.

Jak chcesz parametryzować, to wracasz do opisywanego wcześniej
rozwiązania "adres portu + maska bitowa".

do góry

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 :(
P.G.

do góry

Użytkownik "Piotr Gałka" napisał w wiadomości grup
dyskusyjnych:o8p09b$l8c$...@n...chmurka.net...
W dniu 2017-02-23 o 21:07, Zbych pisze:
>>> 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.

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 ...

>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.

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.

do góry