Jak wykorzystać GPIO w mikrokontrolerach 8051 z SDCC do obsługi przycisków?

Tue Feb 14, 2017 8:30 am   

Wiem, że mikokontrolery oparte na 8051 powoli wychodzą z mody, ale
obecnie muszę napisać nowy wsad do istniejącego urządzenia. Nie mam
zamiaru uczyć się assemblera tej rodziny ani bawić się w BASCOM-ie, więc
skorzystam z C. W czasach świetności tych MCU powszechnie korzystano z
kompilatora Keil, ja jednak postawię na SDCC - z tego co widzę,
podobieństwa są dość spore, przynajmniej na pierwszy rzut oka. Proste
projekty przykładowe się kompilują.

Mam jednak kilka pytań:
1) Widzę, że możliwy jest dostęp do pinów GPIO za pomocą konstrukcji w
rodzaju Px_y, gdzie x oznacza numer portu, a y numer pinu w porcie.
Można dzięki temu przypisywać wartość bezpośrednio do pinu, (np.
P0_1=1). Czym jest taka konstrukcja? Można zdefiniować jakąś zmienną
wskaźnikową, która umożliwi mi dostęp do tak zdefiniowanego pinu?
Chciałbym przeportować pewną prostą bibliotekę do obsługi przycisków.
Dobrze by było, gdybym mógł przekazać informację o pinie właśnie w ten
sposób, jako argument funkcji, a potem trzymać ją w strukturze
opisującej przycisk.
2) Czy możliwe jest korzystanie z portów w sposób taki, jak w AVR-ach?
To znaczy coś w rodzaju P0 |= (1<<2).
3) Dobrze rozumiem, że te mikrokontrolery nie posiadają żadnych
rejestrów konfiguracyjnych, jeśli chodzi o kierunek pinu i działają
podobnie do prostych ekspanderów I2C?

Tue Feb 14, 2017 9:31 am   

-- Wiadomość oryginalna (wysłana 14.02.2017 08:30) --

Podstawowa różnica: inna kolejność bajtów w liczbach wielobajtowych.

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


Oczywiście, dokładnie tak samo.


Tu już nie jestem taki pewny, daawno nie programowałem AT89.
Ale chyba faktycznie nie ma żadnej konfiguracji, stan niski
to twarde 0, stan wysoki to wysoka impedancja.

Pozdrowienia,
MKi

Tue Feb 14, 2017 10:03 am   

Broń Boże. Porty mają do dyspozycji tylko jeden rejestr, który jest
wejściem (przy odczycie) i wyjściem (przy zapisie). Kompilator może to
przetłumaczyć na instrukcję bitową albo na odczyt, modyfikację i zapis.
I wtedy jak z wejścia odczytasz 0 to 0 zapiszesz na wyjście.

Albo korzystasz tylko z instrukcji bitowych do manipulowania I/O, albo
musisz dołożyć do tego maskę ustawiającą na 1 bity, które są wejściami.

P0 |= P0_INPUTS_MASK | (1 << 2);
P0 = (P0 | P0_INPUTS_MASK) & ~(1 << 2);


Stan wysoki to słaby pullup, co ciekawe wiele '51 na jeden albo dwa
cykle zegarowe włącza silny pullup przy zmianie stanu z 0 na 1, żeby
szybciej przeładować pojemności na linii.

Tue Feb 14, 2017 10:55 am   

Użytkownik "MKi" napisał w wiadomości grup
dyskusyjnych:58a2c045$0$15193$65785112@news.neostrada.pl...

Maja taki specjalny tryb adresacji - dla wybranych rejestrow i kawalka
pamieci dostepny jest tryb bitowy.
Zapisujesz odpowiedna instrukcja i bit sie zmienia.
Ale ... kompilator musi wiedziec, ze tu jest potrzebna specjalna
instrukcja.


Przy czym jak tych przyciskow wiecej, to moze byc jednak lepiej
oblsugiwac to calymi bajtami.


Ostroznie, tam sa rozne tryby adresacji, i znow trzeba uwazac co
kompilator z tym zrobi.
Raczej zrobi dobrze, ale instrukcja
ORL P0, #01h
odczytuje rejestr portu wyjsciowego, ustawia najmlodszy bit i zapisuje
ponownie.

Instrukcja
MOV A, P0
odczytuje stanu pinow portu.
Jak potem zrobisz
ORL A,#01h
MOV P0,A

To to nie bedzie to samo (patrz nizej).


Dokladnie - rejestry sa jednoczesnie wejsciowe i wyjsciowe.
tranzystor wyjsciowy "dolny" jest silny, "gorny" slabiutki, a w
zasadzie to stale pull-up (+ te 2 cykle).
Jesli ustawisz bit na "0", to wyjscie bedzie na 0, i nie nalezy
podawac z zewnatrz stanu wysokiego.
Jesli ustawisz bit na "1", to wyjscie bedzie w stanie wysokim, ale
slabym (~1mA), mozna z zewnatrz wymusic zero.

Bity, ktore maja byc wejsciowe, musisz najpierw ustawic na 1.

J.

Tue Feb 14, 2017 11:24 am   

czy jest jakiś tutorialek do SDCC?

Wed Feb 15, 2017 6:16 am   

Ok, wielkie dzięki za informacje.
Mam jeszcze jedną prośbę. Zauważyłem, że MCU8051IDE samo z siebie nie
potrafi obsługiwać projektów z wieloma plikami. Każdy plik jest
kompilowany z osobna i przy próbie skompilowania czegoś z funkcjami
pomocniczymi wyskakuje błąd informujący o braku funkcji main.
Z tego co wiem, do projektu można jednak podpiąć makefile.
W najgorszym razie będę go sobie ręcznie kompilował przez make.

Ktoś z was ma może działający, przykładowy makefile pod sdcc i mcu z
serii at89cxxxx?

Wed Feb 15, 2017 9:56 am   

-- Wiadomość oryginalna (wysłana 15.02.2017 06:16) --


Nie używałem SDCC z AT89, więc precyzyjnie Ci nie pomogę,
ale może coś moje informacje wprowadzą.

Kompilowałem SDCC na procesorki SiLabs, przy użyciu Silabs IDE,
do bezpłatnego pobrania ze strony silabs.com
Cześć dotycząca programowania i debugowania jest oczywiście
dedykowana do tych procesorów, ale można w tym kompilować
programy na inne procesory, wystarczy wskazać ścieżkę do SDCC.

Jakbyś nie chciał walczyć z nowym środowiskiem, to poniżej
przykład - jakie polecenia wygenerowało IDE dla dwuplikowego
programu, może ułatwi tworzenie makefile:

C:\Programy\SDCC\BIN\sdcc.exe -c --debug --use-stdout -V -I"sciezka"
"sciezka\plik1.c"

C:\Programy\SDCC\BIN\sdcpp.exe -nostdinc -Wall -std=c99 -I"sciezka"
-obj-ext=.rel -DSDCC_MODEL_SMALL -DSDCC=260 -DSDCC_mcs51 -D__mcs51
-I"C:\Programy\SDCC\BIN\..\include\mcs51"
-I"C:\Programy\SDCC\BIN\..\include" "sciezka\plik1.c"

C:\Programy\SDCC\BIN\asx8051.exe -plosgffc "plik1.asm"

C:\Programy\SDCC\BIN\sdcc.exe -c --debug --use-stdout -V -I"sciezka"
"sciezka\plik2.c"

C:\Programy\SDCC\BIN\sdcpp.exe -nostdinc -Wall -std=c99 -I"sciezka"
-obj-ext=.rel -DSDCC_MODEL_SMALL -DSDCC=260 -DSDCC_mcs51 -D__mcs51
-I"C:\Programy\SDCC\BIN\..\include\mcs51"
-I"C:\Programy\SDCC\BIN\..\include" "sciezka\plik2.c"

C:\Programy\SDCC\BIN\asx8051.exe -plosgffc "plik2.asm"

C:\Programy\SDCC\BIN\sdcc.exe --debug --use-stdout -V -I"sciezka"
-o"sciezka\plik.hex" "sciezka\plik1.rel" "sciezka\plik2.rel"

C:\Programy\SDCC\BIN\aslink.exe -nf "sciezka\plik.lnk"

SDCC jest zainstalowane w C:\Programy\SDCC, projekt w sciezka,
pliki źródłowe to plik1.c i plik2.c, pliki wynikowe plik.*.

Pozdrowienia,
MKi

Wed Feb 15, 2017 1:27 pm   

On Wed, 15 Feb 2017 06:16:31 +0100, Atlantis <marekw1986NOSPAM@wp.pl>
wrote:

Ten co Ci wysłałem do pic32 jest uniwersalny, zdefiniuj tylko LD i
CC.

--
Marek

Thu Feb 16, 2017 8:33 am   

On 14.02.2017 09:31, MKi wrote:


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.

Powinienem zdefiniować jakąś specjalną zmienną wskaźnikową, czy
wystarczy jawne rzutowanie np. na unsigned char *?

Będę mógł za pomocą takiej konstrukcji sterować pinem?

Thu Feb 16, 2017 8:40 am   

W dniu 16.02.2017 o 08:33, Atlantis pisze:


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

Thu Feb 16, 2017 9:18 am   

On 16.02.2017 08:40, Zbych wrote:


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?

Mon Feb 20, 2017 6:36 pm   

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?

Mon Feb 20, 2017 7:04 pm   

Użytkownik "Atlantis" napisał w wiadomości grup
dyskusyjnych:o8f9ee$on6$1@news.icm.edu.pl...

kompilowac czy dzialac ?


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.

Thu Feb 23, 2017 8:38 am   

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

Thu Feb 23, 2017 10:20 am   

W dniu 2017-02-16 o 08:33, Atlantis pisze:

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.