logo elektroda
logo elektroda
X
logo elektroda
REKLAMA
REKLAMA
Adblock/uBlockOrigin/AdGuard mogą powodować znikanie niektórych postów z powodu nowej reguły.

Bascom - błędne działanie programu a długość kodu

jacekbosacki 04 Mar 2021 11:48 603 9
REKLAMA
  • #1 19296263
    jacekbosacki
    Poziom 8  
    Witam
    Mam bardzo dziwny problem z działaniem programu napisanym w Bascom. Program jest napisany na AT90CAN128 i po skompilowaniu zajmuje 58% pamięci programu.
    Program kompiluje się prawidłowo - bez błędów, ale podczas działania program się sypie - błędy na wyświetlaczu graficznym, a nawet restart procesora.
    Wystarczy jednak że usunę kilka linii kodu w programie np. klika linii DATA na końcu programu (dane dla grafiki wyświetlacza), które nie mają znaczenia (program z nich nie korzysta w danej chwili) i wtedy wszystko działa OK. Dodam że nie ma to znaczenia jakie to będą dane DATA.
    Żeby było ciekawie efekt poprawy uzyskuję również np. przez dopisanie kliku linii kodu (tak tylko aby coś było) co nie zmienia działania programu np. jakiś IF który nigdy nie będzie spełniony.
    Kombinowałem już z różnymi ustawieniami $hwstack ; $swstack ; $framesize ale to nic nie daje.
    Wygląda to tak jakby długość programu miała wpływ na jego działanie i nie chodzi tu nawet o RAM bo linie kodu DATA są ładowane do pamięci programu.
    Nie bardzo wiem jak to naprawić - może ktoś miał podobny problem ?
  • REKLAMA
  • #2 19296488
    Karlos12
    Poziom 16  
    A czy są dodawane biblie xxx.inc w środku programu, bo jeśli tak to one powodują takie dziwne rzeczy.
    Proponuję zamienić jeśli takowe są biblioteki na suby i to do nich się odwoływać.
    Ja miałem ten sam problem na xmedze256 i po przekroczeniu 50% wsadu na lcd ili9325 przedziwne rzeczy się działy.
    Urywało czcionki, grafike i inne krzaki.
    Miałem kilka napisanych bibliotek do obsługi procesora audio i to właśnie te biblioteki umieszczone w różnych miejscach kodu powodowały takie dyrdymały.
    Zrobiłem suby, a w nich wsadziłem to co zawierało się w bibliach i po kłopocie. Bascom 2.0.8.3 licencja nawet nie był w stanie sobie poradzić z takimi dziwactwami.
    A jak możesz to zapodaj kod będzie łatwiej coś rozkminić.
  • REKLAMA
  • #3 19296537
    bart-projects
    Poziom 29  
    Być może problem z RAMPZ.
    Wszystkie grafiki i stałe tekstowe są umieszczane na końcu programu. Pamięć AVR może być adresowana tylko dwoma bajtami więc do 64KB. Żeby móc dostać się do pamięci >64KB używany jest specjalny znacznik kolejnych stron RAMPZ a niektóre biblioteki do wyświetlaczy były pisane na stare mniejsze uC i nie uwzględniają RAMPZ więc program może źle adresować po czym się wysypuje.
  • #4 19296559
    jacekbosacki
    Poziom 8  
    Karlos12 napisał:
    A czy są dodawane biblie xxx.inc w środku programu, bo jeśli tak to one powodują takie dziwne rzeczy.

    Nie dodawałem żadnych bibliotek. Biblioteki do obsługi grafiki napisałem sam. Ale błędy są takie jak opisałeś.

    Dodano po 4 [minuty]:

    bart-projects napisał:
    Być może problem z RAMPZ.
    Wszystkie grafiki i stałe tekstowe są umieszczane na końcu programu. Pamięć AVR może być adresowana tylko dwoma bajtami więc do 64KB. Żeby móc dostać się do pamięci >64KB używany jest specjalny znacznik kolejnych stron RAMPZ a niektóre biblioteki do wyświetlaczy były pisane na stare mniejsze uC i nie uwzględniają RAMPZ więc program może źle adresować po czym się wysypuje.

    Tego nie przerabiałem - mam na myśli RAMPZ i nie bardzo wiem co tu mogę ustawić. Nie korzystam z bibliotek do wyświetlacza (sam napisałem). Trop jest ciekawy - przekroczyłem 50% procent pamięci procesora. Jeśli można to proszę o wskazówki co i jak z tym RAMPZ.
  • #5 19306094
    kamyczek
    Poziom 38  
    Bascom i wszystko jasne ....albo raczej nie jasne po kilku doświadczeniach podobnych do twoich pożegnalem to środowisko i nauczylem sie asemblera , mozna też nauczyć się C ( bardziej uniwersalne i popularne ) można też zrobić wycieczkę na arduino które zbliżone jest do C . Bascom potrafi kompilować się losowo a w dużych programach powyzej 8k to już prawie reguła że coś nie dziaĺa albo działa źle . Ja więc proponuje po hello world kolejny napis zrobić by by bascom ...
  • REKLAMA
  • #6 19306255
    bart-projects
    Poziom 29  
    To jakieś farmazony. Programy po 200KB które piszę często a Ty jeden pisałbyś w ASM do końca życia działają bezbłędnie.

    Problemem może być źle napisany driver wyświetlacza. Na przykład możesz mieć dodany font/czcionkę 16x16 to są dwa bajty na dwa bajty czyli każda kolejny znak to jego kod w ASCII x 4 a może ktoś sięga po znak którego w tym zestawie nie ma. Wtedy czesto tylko artefakty, ale można też pojeździć po zmiennych przepełniając jakąś inną.
    Czasem brakuje zwykłego Return i program jedzie dalej do kolejnego Sub. Nie widać tego na pierwszy rzut oka bo program traktuje taki Sub bez Return jako Label. Dlatego preferuję pisanie Subów w nowszej konwencji Config Submode = New więc najpierw piszesz suby u góry przed kodem a potem dopiero ich używasz.
    A może używasz Nosave a nie odkładasz potrzebnych rejestrów...a może używasz w przerwaniach Single i trzeba tez odłożyć R30 i R31 co jest opisane w Helpie.
    Przyczyn może być wiele, ale najczęściej to jest błąd programisty, nie Bascom`a.
  • REKLAMA
  • #7 19306484
    kamyczek
    Poziom 38  
    Pisałeś może coś w C czy asemblerze żeby mieć porównanie ? Ja też pisząc w bascomie myślałem że , złapałem byka za rogi jednak po pewnym czasie i zasmakowaniu innych języków przy okazji kilku nieudanych prób realizacji projektu przejrzałem na oczy . Jeśli będziesz szukał pracy jako programista w poważnej firmie i zapytany o to jaki język znasz powiesz C spotkasz się z aprobatą , asembler zaskoczy , ale bascom po prostu rozbawi . Co do 200k to w bascomie nie jest to problemem bo biblioteki są często tak optymalizowane , że gdy inny język wymaga 20k kodu bascom generuje go 200.
    W moim przypadku gorycz przelało prędkość odświeżania wyświetlacza KS108 na którym miałem problem żeby osiągnąć 10Hz . Może teraz jest lepiej bo sporo lat minęło od kiedy zakosztowałem bascoma , ale złe wrażenie pozostało , realia z użyciem go komercyjnym dalej przytłaczają , a ja wracać na te wody raczej nie zamierzam . Dla amatora na początek jest prosty , szybki i nie zniechęca , ale dziś wolał bym już zacząć od arduino , a dla komercji na C . Ja dla własnej satysfakcji piszę w asemblerze , jest to czasochłonne i może mało praktyczne ale po prosty to lubię i robię hobbystycznie. Jeśli ktoś jednak liczy się z tym że w jakiejś pracy może potrzebować czy wykorzystać znajomość języków programowania nie powinien skupiać się nad bascomem bo to czas stracony .
  • #8 19306624
    jacekbosacki
    Poziom 8  
    Dziękuję za sugestię i wyjaśnienia. Jestem jednak przekonany że problem jest z rejestrem RAMPZ. Wszystko co sugerowałeś sprawdziłem. Dane zawarte w DATA są prawidłowe (sprawdziłem wyświetlanie grafiki korzystając z tych danych między innymi fonty). Program po usunięciu linii z danymi Data - tak aby program nie przekraczał 64KB - działa prawidłowo. Usunięcie DATA nie wpływa na strukturę programu tylko wielkość zajmowanej pamięci FLASH. Niestety dane DATA są częściowo poniżej adresów FFFF ale część powyżej. Tyle doczytałem że Rejestr RAMPZ dla odwołań do danych powyżej FFFF powninien by ustawiony (na wartość 1 - tak mi się wydaje) aby pobierać dane z adresów powyżej FFFF. Podobno trzeba to ustawić samemu w programie. Tylko nie bardzo wiem jak i kiedy to umiejscowić w programie. Może po ustawieniu wskaźnika przez RESTORE ?. W tym temacie proszę o pomoc i wyjaśnienie.
  • #9 19306929
    kamyczek
    Poziom 38  
    Możesz spróbować dane umieścić na początku kodu albo blisko części w której je wywołujesz . Możliwe że błąd jest w samej bibliotece . Tak żeby skok do nich był mniejszy . Nie wiem jakich bibliotek tam używasz więc trudno mi ocenić powód
    Generalnie jeśli autor biblioteki wykorzystał instrukcje asemblera rcall czy rjmp to efektem są skoki w krzaki dla układów o większej pojemności gdzie używany jest właśnie rejestr rampz . Po prostu przy skoku nie ładuje on na stosie i powrót bywa obarczony przesunięciem o jego wartość. Moja ocena dotyczyła raczej wczesnych wersji programu i pewnie z czasem wykluczono część błędów ,które występowały .
  • #10 19307252
    bart-projects
    Poziom 29  
    Bascom nie jest taki głupi i nie pozwoli skompilować jeśli Relative Call or Jump jest zbyt daleki. Wywali błąd.
    Przykładem jest biblioteka hexval.lib autorstwa MWS. Nie jest to biblioteka MCS i użyto w niej RJMP i RCALL. Jest pomocna bo sprawdza czy wartości HEXstringów zawierają tylko dozwolone znaki A-F 0-9, jednak dla większych programów np. z obsługą WIZ5500 i do tego AVR-DOS Bascom zgłosi błąd. Wtedy wystarczy w bibliotece zamienić RCALL na CALL a RJMP na JMP i po kłopocie.

    @jacekbosacki - który to Bascom? Pytam bo np. w 2081 był problem z funkcją Fusing która używa tablicy i mogła powodować problem z RAMPZ -naprawiono. W 2082, tylko dla Xmega, był problem z instrukcją Out - często używana w driverach ;) -naprawiono

    Samych tablic nigdzie nie umiejscowisz bo Bascom sam je układa na końcu programu. Za to obsługa wszystkich przerwań zawsze jest w pierwszej stronie.

    Nie wiemy więc który to Bascom. Może podeślij ten driver do wyświetlacza na priv to się spojrzy i może coś wymodzimy ;)

    Ogólnie wiele można się nauczyć z czytania innych gotowych bibliotek. To zwykłe pliki tekstowe. Możesz to otworzyć w notatniku, ale lepiej w Notepad++ i wybrać kolorowanie Asm.
    Można je otwierać w Bascom, ale najpierw trzeba w ustawieniach dopisać by nie formatował automatycznie plików o rozszerzeniu LIB (zobacz screen). Pisze DAT RPT i trzeba dopisać LIB.

    Bascom - błędne działanie programu a długość kodu
REKLAMA