Pamięć at89c2051

-- Wiadomość oryginalna (wysłana 21.03.2017 09:09) --

Pamięć: Zapewne obszar zmiennych jednego modułu (jednego pliku .c) musi być ciągły, a obszar "bbbb" jest za duży, aby się zmieścił od 0x0D do 0x1F. Używasz też zmiennych bitowych, które zaczynają się zawsze od 0x20. Rozwiązanie: rozdziel zmienne modułu "bbbb" na dwa moduły.

Dane we FLASH: Jak najbardziej, całe kombinowanie to dyrektywa const lub code.

Pozdrowienia, MKi

W dniu 2017-03-21 o 09:09, Atlantis pisze:

to jest antyczny? spróbuj 8049, 8085, a dla hardcorów - 8080.

Zapoznać się z mapą pamięci?

a w asemblera bym może zajrzał... podpowiedź: "architektura Harvard" oraz "instrukcja MOVC"

a.

Użytkownik "Atlantis" napisał w wiadomości grup dyskusyjnych:58d0dfa8$0$651$ snipped-for-privacy@news.neostrada.pl...

Poczatek RAM to sa rejestry R0-R7. 4 banki takich rejestrow sa, ktore mozna sobie przelaczac ... albo uzywac jako normalna pamiec, jesli nie przelaczasz. Kompilator z tego co widac ominal tylko jeden bank.

uC musi te dane odczytywac innym rozkazem (MOVC), wiec kompilator musi wiedziec, ze to jest inna pamiec, i ze trzeba uzyc innego rozkazu.

Nie mozesz sobie napisac funkcji np void funkcja(char * ptr) {...} i przekazywac jej adresy do roznych obszarow

(Wyjatkiem byl tu Keil, ale to bylo obciazone gorsza wydajnoscia).

Atlantisie - przeczytaj jakas ksiazke o 8051, albo go wyrzuc, szkoda zycia.

J.

-- Wiadomość oryginalna (wysłana 21.03.2017 11:16) --

Ale można! SDCC tworzy trzybajtowy wskaźnik, w pierwszym bajcie jest informacja, na jaki obszar pamięci wskazują pozostałe dwa bajty. Chyba tak samo, jak w Keil.

Oczywiście wydajniej będzie kwalifikować jawnie wskaźnik.

Pozdrowienia, MKi

bezpośrednio,

Tak, wystarczy deklaracja const. Dodatkowo sdcc nie odróżnia wskaźników do flash/ram (z pkt. widzenia programisty oczywiście). Można je zamiennie stosować np. jako argumenty standardowych funkcji z libc. Niestety na tym chyba się kończą zalety sdcc...

no pięknie rodzi się na grupie nowa nauka, co za maniane zrobi/ł kompilator...

W dniu 2017-03-21 o 11:52, Marek pisze:

Ok, wielkie dzięki. :) Jeszcze jedno pytanie. Ktoś z was ma pomysł jak debugować niedziałającego UART-a w at89c2051?

Software'owy UART działa ok. Hardware'owego nie mogę odpalić, chociaż mogłoby się to wydawać banalnym zadaniem.

Procedura inicjująca wygląda następująco:

void uart_init (void) { TMOD &= ~0xF0; TMOD |= 0x20; SCON = 0x50; TH1 = 0xFD; TL1 = 0xFD; ES = 1; TR1 = 1; }

a w pętli głównej umieściłem następujący zestaw instrukcji:

if (RI) { RI = 0; c = SBUF; SBUF = c; }

Niestety, znaki wysyłane na przejściówkę USB-UART nie wracają do komputera. Analizator stanów logicznych też nie widzi żadnego ruchu na linii TX MCU.

Kierunki linii chyba też są ustawione właściwie we wstępnej konfiguracji (P3 = 0x01;).

Może coś jeszcze przeoczyłem?

Użytkownik "Atlantis" napisał:

To nie kierunki, tylko ustawiłeś 0 do wszystkich linii portu P3, oprócz RXD to jak ma działać?

Alojzy

W dniu 2017-03-22 o 18:39, Alojzy pisze:

Chwilę, a to przypadkiem nie jest tak. że jeśli ustawię 0, to tam jest dosłownie 0 - pin jest na poziomie masy i nawet jeśli podłączyłbym zewnętrznego pull-upa, to i tak po stronie pinu będzie on na potencjale masy i próba odczytania czegokolwiek da zawsze 0. Natomiast jeśli wpiszę 1, to włącza się słaby, wewnętrzny pull-up. Przy odczycie normalnie będzie zwracało jedynkę - chyba, że coś z zewnątrz zewrze pin z masą - wtedy będzie zero.

Dokładnie tak, jak w przypadku PCF8574.

Czyżbym nie miał racji?

Dnia Wed, 22 Mar 2017 21:55:45 +0100, Atlantis napisał(a):

Jesli chodzi o piny dzielone, to nie. Tzn opis powyzszy jest prawdziwy, ale taka np TxD/P3.1: Jesli do P3.1 wpiszesz 0, to pin bedzie zawsze w stanie 0. Jesli wpiszesz 1, to UART bedzie sterowal pinem.

Gdzies tam w srodku jest bramka OR, laczaca rejestr portu i funkcje specjalna.

J.

Bardzo bym się zdziwił. To, co jest w const char[], musi być w RAM-ie nie bez powodu - te adresy muszą być dostępne dla funkcji, które operują na RAM-ie. Przykładowo jak wywołasz memcpy(), to ona zakłada, że dostała adres do RAM-u i używa instrukcji czytających z RAM-u.

Dla AVR to odpowiednio instrukcje LD i LPM, dla 8051 - MOV i MOVC. Funkcje operujące na pamięci muszą wiedzieć, z których instrukcji korzystać dla danego adresu.

Co do reszty - nie pomogę, dla 8051 pisałem coś ostatnio 15 lat temu :(

Czyli "bardzo bym się zdziwił" zmieniam na "bardzo się zdziwiłem" ;)

Doczytałem resztę wątku, odszczekuję :) Nie wiedziałem że SDCC robi takie sztuczki.

Już coraz więcej kompilatorów wychodzi z tej paranoi odróżniania wskaźników ram/flash. XC8 też już odpuszcza ten problem programiscie i sam wew. rozwiązuje ten problem.

Jak dla mnie to dobrze - po to są języki wysokopoziomowe, żeby ukrywać szczegóły architektury platformy. Z drugiej strony nie chciałbym, żeby było to obowiązkowe, bo czasem zależy nam jednak na tym, żeby kod był tak szybki, jak to możliwe...

Ten problem rozwiazuje, a rodzi nowe.

Potem sie okazuje program jest wolny, oraz wielki, w pamieci sie nie miesci.

Jesli chodzi o 8051, to najlepiej po prostu o nim zapomniec. Byl, teraz jest przestarzaly, do C sie nie nadaje :-)

J.

W dniu 2017-03-24 o 18:14, J.F. pisze:

Nie przesadzajmy. ;) Attiny posiadające mniej zasobów programuje się w C.

Kluczową kwestią są zastosowania. Kiedyś lepszych mikrokontrolerów zwyczajnie nie było. Jeśli nie chciało się podpinać zewnętrznych pamięci RAM i EPROM przy większych projektach, trzeba było wszystko ręcznie optymalizować tak bardzo, jak to tylko możliwe.

Gdybym potrzebował więcej zasobów, wykorzystałbym nowocześniejszy mikrokontroler. Ponieważ jednak już zetknąłem się z tą platformą (napisanie nowego wsadu do instniejącego urządzenia) i mam prosty programator, a w szufladzie poniewiera się parę sztuk starych AT89C51 i AT89C2051 pewnie wykorzystam je w jakichś prostszych projektach. Właśnie takich, które wymagałyby Attiny.

Nawet konieczność wyjmowania MCU z podstawki celem jego zaprogramowania nie jest jakoś szczególne uciążliwa przy tak małych ilościach kodu.

J.F. chodziło zapewne o to, że takie skamieniałości nie mają architektury przyjaznej C. Były projektowane do programowania w asamblerze. Robienie kompilatora w C do takich archtektur jest trochę na siłę, bo efekt kompilacji często nie będzie zoptymalizowany.

W dniu 2017-03-25 o 10:17, Marek pisze:

Nie zmienia to faktu, że przy małych projektach ten argument nie ma wielkiego znaczenia. Do dużych użyję zupełnie innego MCU, tudzież jakiegoś Arduino albo nawet Raspberry Pi.

A co do optymalizacji, to darmowe wersje kompilatorów XC8/XC32 też mają ograniczone możliwości w zakresie generowania najbardziej optymalnego kodu. ;)