Jak umieścić funkcję main pod adresem 100h w SDCC dla DSM51?

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.

Witam

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

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

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

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

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

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.

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

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

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

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 )

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ę ))))))

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



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