Elektroda.pl
Elektroda.pl
X
CControls
Proszę, dodaj wyjątek www.elektroda.pl do Adblock.
Dzięki temu, że oglądasz reklamy, wspierasz portal i użytkowników.

programowanie w C i DSM51

romsik 14 Wrz 2007 14:19 2025 11
  • #1 14 Wrz 2007 14:19
    romsik
    Poziom 14  

    Witam wszystkich !
    Chcę nauczyć się programować 51 w języku C.
    Mam opanowanego asemblera i dysponuję DSM51.
    Jak zmusić kompilator (sdcc) żeby program główny (main) umieścił pod konkretnym adresem (100h) i jak robic wstawki asemblerowe.

    0 11
  • CControls
  • #2 16 Wrz 2007 19:41
    mreq
    Poziom 21  

    Witam

    Przyłączam się do prośby o jakiś porządny manual do sdcc lub keila dla 51.

    0
  • CControls
  • Pomocny post
    #3 16 Wrz 2007 20:21
    aster11
    Poziom 19  

    romsik;
    Wstawki asemblerowe (str. 44 dokumentacji pdf):

    Code:
    _asm
    
       ...
    _endasm;

    Bezwzględne pozycjonowanie kodu funkcji - na pewno jest to Tobie potrzebne?
    Rzut oka na dokumentację pokazuje, że można bezwzględnie lokować zmienne oraz można wybierać adres początkowy całego kodu (poprzez opcję linkera). Dość dawno zapoznawałem się z SDCC i chyba nie było tam mowy o możliwości absolutnej lokacji indywidualnych funkcji, jest to z resztą bardzo nietypowy zabieg przy programowaniu w C. Jeżeli chodzi Ci o wywoływanie funkcji C z poziomu asemblera i odwrotnie, to jest to możliwe bez potrzeby wymuszania ich adresów, jest to opisane w dokumentacji.

    mreq:
    Cytat:
    jakiś porządny manual do sdcc lub keila dla 51

    Te dwa środowiska są na pewno rozbieżne pod względem możliwości, jakości dokumentacji, wygody obsługi (i ceny :P ). Dla SDCC istnieje jednoplikowa dokumentacja (w pdf lub html), dostępna na stronie www programu, a potem w zainstalowanych zbiorach. Czy jest "porządna" może być dyskusyjne, mnie wystarczyła do opanowania tego środowiska. Mniej na uwadze, że opisuje ona tylko specyficzne właściwości tego oprogramowania. Jeżeli chcesz zapoznawać się z językiem C jako takim, musisz szukać gdzie indziej.
    Dokumentacja dla Keil'a to zupełnie inna bajka. Jest wiele kilkusetstronicowych dokumentów, oddzielnie dla kompilatora, linkera, asemblera, itd. Pewnie można powiedzieć, że jest "porządna", ale pełne zapoznanie się z jej treścią, to nielada wyzwanie. Na początek może lepsze byłyby jakieś "wersje skrócone".

    0
  • #4 17 Wrz 2007 14:00
    Jdsoul
    Poziom 23  

    Po kolei, z czego ma wynikać alokacja programu :)

    czy przypadkiem nie z budowy zestawu i wykorzystania niższej pamięci programu dla procedur systemowych:)

    Do alokacji kodu programu na sztywno służy opcja linkera
    --code-loc <Value>

    Domyślnie Wartość = 0.
    Uwaga kiedy ta opcja jest użyta Tablica Vectorów podąża za wskazanym adresem :)

    Przykładowo: --code-loc 0x8000 lub --code-loc 32768

    Podobnie jest z Ramem -

    Domyślnie linker 8051 umieszcza stack za ostatnią zmienną .
    Opcja --stack-loc pozwala na sztywno określić początek stosu

    To samo dotyczy pamięci zewnętrznej opcja --xdata-loc
    ustawia początek pamięci xdataxdata oraz --xram-size określa wielkość tej pamięci.

    i jeszcze

    Opcja linkera --code-size określa wielkość pamięci kodu

    Aby skorzystać z istniejących procedur będziesz musiał stosować wstawki asemblerowe z adresowaniem niejawnym - wyliczonym {skok ljmp, ajmp } , ponieważ podciągnięcie zapisanych na sztywno w ROMie bibliotek będzie w SDCC raczej niemożliwe :)

    Proponowałbym dać sobie z nimi spokój i zbudować odpowiedniki w C.

    Problem z sztywną alokacją w C jest dość krytyczny, bo zarówno tworzone przez ciebie jak i przez kompilator zmienne i tablice są alokowane w miarę powstawania programu i mogą ci się pokryć z zadeklarownym na sztywno początkiem stosu :)

    Dodano po 13 [minuty]:

    Zazwyczaj programując w C starasz się nie bazować na asemblerze w celu uniwersalności tworzonego kodu i przenośności [mam na pyśli szkielet programu sprzętowo niezależny], ale jeśli mimo wszystko chcesz używać wstawek, nie znając budowy wewnętrzenej procedury C będziesz musiał zrzucać stan rejestrów na stos oraz przełączać banki rejestrów, a to przygniecie strukturę programu i przyspieszenie jakie ci dawał ASM :)

    Pytanie jest prostej natury kiedy użyć a=dana; , a kiedy mov a,dana :)

    Oczywiście trywializuję i rozumiem, że masz kupę sprawdzonych procedur w asm:).

    Sdcc pozwala na odczyt listingu kompilatu w asmie :) więc tam możesz podejrzeć co poszcególne optymalizacje wnoszą do kodu :)

    0
  • #5 18 Wrz 2007 17:57
    romsik
    Poziom 14  

    Wielkie dzięki Jdsoul za wyczerpującą odpowiedź. Niestety wynika z niej, że w zasadzie DSM nie za bardzo nadaje się do C (tak jak myślałeś alokacja jest potrzebna do ominięcia wewnętrznych procedur zestawu). Cały problem polega na przesunięciu wektora przerwań. Pozdrawiam i zamykam temat. DZIĘki

    0
  • #6 19 Wrz 2007 14:04
    Jdsoul
    Poziom 23  

    Romsik nie tak prędko :) nie ma co się załamywać :)

    W końcu to przecież tylko elektronika :)

    Właściwie to po ci są potrzebne te procedury w C :) do napisania znaku , odczytu klawisza czy do czego ??

    Fizyczne wyłączenie ROM w DSM51 nie stanowi przecież problemu :)
    odetnij zasilania i wyjmij układ z płytki :) ;)

    A procesor podstawowy spokojnie sobie bez tego ROM poradzi :)

    Sprzęt to sprzęt - weź schemat DSM51 , przeanalizuj adresy poszczególnych składników , porty, zakresy komórek etc. i do roboty :)

    Klawiatura jak sądzę przemiatana, obok RTC najczęściej I2C, dalej LCD myślę że 8 bitowo na jakimś adresie komendy na innym dane do wysłania.

    Jeszcze raz mówię sprzęt to tylko sprzęt :)

    A w C masz tą przewagę, że jak raz się pogłowisz na implementacją printf w swoim systemie to później bierzesz już w swoim programie tylko
    podłączenie zrobionej przez siebie biblioteki i

    np. printf ('jak to fajnie DSM51 się daje programować ')

    powodzenia.

    0
  • #7 19 Wrz 2007 15:09
    romsik
    Poziom 14  

    ja się nie załamuję i nad C pracuję, bo trzeba iść do przodu. Po prostu nie obsłużę przerwań w DSMie i tyle:)

    0
  • #8 19 Wrz 2007 15:37
    aster11
    Poziom 19  

    Tak jak napisał Jdsoul, trzeba się zapoznać dokładniej ze sprzętem i wszystko powinno się dać zrobić. Zamiast procedur wywoływanych z ROM-BIOS, stworzysz sobie własne procedury w C (dość szybko to się robi) i będziesz z nich korzystał.
    Nie pamiętam już struktury DSM51 (kiedyś czytałem o tym książkę Gałków, ale nigdy nie miałem tego w rękach), jeżeli "ROM-BOOTLOADER-BIOS" przesuwa obszar wektorów przerwań w inny adres, to najprawdopodobniej nie zmienia struktury (kolejności i odstępów) w tym obszarze, można zatem początek całego kodu programu, wraz z adresami przerwań "wycelować" pod odpowiedni adres, za pomocą właściwej opcji linkera. No chyba, że DSM51 nie mapuje wektorów przerwań do obszaru "kodu RAM'owego", ale to chyba niemożliwe.
    Ostatecznie, w akcie desperacji, możesz zaprojektować sobie swój własny zestaw prototypowy, z jakąś nowszą odmianą '51 - nawet złożyć coś na uniwersalce na początek - obecnie koszt nie jest jakiś ogromny, tylko trzeba chcieć trochę podłubać w kablach :)

    0
  • #9 19 Wrz 2007 16:57
    Jdsoul
    Poziom 23  

    O ile dobrze kojarzę, to żeby się dostać do DSM51 potrzeba było wgrać coś do portu COM :) za pomocą dołączonego programu i dalej do pamięci SRAM podłączonej do 8051 w układzie pamięci Danych. Potem się procka resetuje i dopiero wtedy ta pamięć jest widziana jako pamięć programu :).

    Czyli system opiera się na takim małym oszustwie wykorzystania procesorka Embeded jako systemu mikroprocesorowego , z pamięcią programu użytkownika stąd te: org 100h: i w tym trybie w C raczej będzie ci trudno coś z tej maszynki wykrzesać :)

    Można to ominąć stosując kontroler z SPI i dając EA do masy - wtedy będziesz pracować z pamiecią wewnętrzną kontrolera 8 kB i blokując funkcje wykorzystania pamięci SRAM jako pamięci Kodu będziesz miał kupę zewnętrznego Ramu xdata do dyspozycji :) na własny buffor etc.

    Już mi się to podoba

    0
  • #10 20 Wrz 2007 09:12
    romsik
    Poziom 14  

    OOOOOOOO to jest pomysł, ale i tak będę próbował "normalnie" jak mi się uda to napiszę hej:) ( ale na rzie tochę mało czasu :( )

    0
  • #11 21 Wrz 2007 14:49
    romsik
    Poziom 14  

    Hura Hura Hura zadziałało. Na bez przerwań ale działa.
    Metoda wręcz od siekiery, ale działa.
    1. umieszczam swój programw c od adresu 0x0100
    2.piszę program w asemblerze LJMP 0x0100 i go asebluję.
    3. kopiuję pierwszą linię hexa programu w asemblerze i wklejam jako pierwszą linię do hexa z programem w C i działa Cieszę się :)))))))

    0
  • #12 24 Wrz 2007 09:45
    Jdsoul
    Poziom 23  

    Hehe :) to jeszcze napisz mały programik w pascalu :) co to otwiera skompilowany plik Hex z c i na sztywno wstaw rozkaz :)

    wówczas piszesz prostego bata

    Code:
    plik. bat
    
    ##############
    echo off

    echo "Kompiluje w C"

    sdcc --code 0100h twój_plik.c

    przesuwacz twój_plik.hex

    Ładuje do DSM51 gotowy program :)
    ##########################


    Tylko uważaj bo możesz mieć jeszcze mały problemik z tablicami znakowymi w kodzie :( mogą się nie zgadzać wyliczone na sztywno przez kompilator położenia znaków w obszarze , ale to łatwo sprawdzić :)

    Dodano po 1 [minuty]:

    sdcc --code-loc 0x0100 twój_plik.c

    Oczywiści :)

    0