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

Dlaczego program w Bascom 1.11.8.7 działa wolno na ATmega8515 8MHz?

seba_x 19 Lip 2007 14:24 1797 6
REKLAMA
  • #1 4095270
    seba_x
    Poziom 31  
    Posty: 2071
    Pomógł: 29
    Ocena: 112
    witam

    mam urządzonko które pracowało ponad rok z programem skompilowanym w bascomie 1.11.7.4 (uP 90s8515 @ 8Mhz) , ostatnio potrzebowałem zmienić dosłownie jedną linijkę kodu , skompilowałem nową wersją bascoma 1.11.8.7 i program zaczą bardzo wolno działać , zamieniłem uP na mega8515 i ustawiłem zewnęczny rezonator 8MHz a program dalej działa ospale , ponowna kompilacja programu w starej wersji nic nie pomaga , dalej jest wolno , co się mogło stać ? mieliście takie przypadki ?

    obydwie wersje mam na jednym komputerze czy to ma znaczenie ?
  • REKLAMA
  • #2 4095728
    janek1815
    Poziom 38  
    Posty: 4513
    Pomógł: 372
    Ocena: 1060
    podaj fusebity. Tam jest problem . Po zmianie procka zmieniles pierwsza linijke programu polecenie $regfile ?
  • REKLAMA
  • #3 4095855
    seba_x
    Poziom 31  
    Posty: 2071
    Pomógł: 29
    Ocena: 112
    janek1815 napisał:
    podaj fusebity. Tam jest problem . Po zmianie procka zmieniles pierwsza linijke programu polecenie $regfile ?



    tak mam regfile , zmieniłem kwarc z 8mhz na 11.059200 i bez różnicy , program skompilowany w wersji 1.11.7.4 działa szybciej , jednak nie tak szybko jak było wcześniej . zauważyłem że jak wsadzę mega8515 zamiast 90s8515 i wtyczka programatora jest wpięta w urządzonko to program działa powoli i poprawnie lecz gdy wyjmę wtyczkę program wykonuje jakieś dziwne żeczy reaguje na przyciski które nie były nacisnięte , przeskakuję do podprogramów .. ogólnie głupieje . z 90s8515 tak się nie dzieje . ściągnełem najnowszą wersję bascoma 1.11.8.8 i bez zmian , mój program dużo korzysta z i2c (eeprom) i pomyślałem że może ustawienia i2cdelay trzeba zmienić , niestety nie pomaga , program reaguje na przyciski dość szybko , z wyświetlaniem informacji na lcd graficznym też jest dość szybko tylko obsługa i2c strasznie się wlecze
    Załączniki:
    • Dlaczego program w Bascom 1.11.8.7 działa wolno na ATmega8515 8MHz? fusy.jpg (37.22 KB) Musisz być zalogowany, aby pobrać ten załącznik.
  • #4 4095898
    janek1815
    Poziom 38  
    Posty: 4513
    Pomógł: 372
    Ocena: 1060
    8515 nie ma fusebitow poza lockbitami . Wywnioskowalem z twego postu ze rzecz dzieje sie tylko po zamianie procka na atmega. i2c jest podciagniete do plusa zasilania?
  • REKLAMA
  • #5 4095923
    seba_x
    Poziom 31  
    Posty: 2071
    Pomógł: 29
    Ocena: 112
    janek1815 napisał:
    8515 nie ma fusebitow poza lockbitami . Wywnioskowalem z twego postu ze rzecz dzieje sie tylko po zamianie procka na atmega. i2c jest podciagniete do plusa zasilania?


    tak , podciągnięte do plusa (urządzenie działało prawidłowo i bardzo szybko przez ponad rok do momentu malutkiej zmiany w programie , zamiast printbin dałem print ale to nie ma znaczenia) , atmęgą nie zawracajmy sobie głowy ponieważ dałem ją tylko żeby sprawdzić czy na innym procku też tak "anemiczy" program . zauważyłem że jak niższa wersja bascoma to program chodzi szybciej , spróbowałbym wersji 1.11.6.8 tylko nie wiem z kąd ją ściągnąć (nie znalazłem na www.mcselec.com)
  • REKLAMA
  • #6 4096176
    crazy_phisic
    VIP Zasłużony dla elektroda
    Posty: 2244
    Pomógł: 278
    Ocena: 130
    Jeśli program działał w sztywnych ramach czasowych to zmiana printbin na print jest już bardzo znaczną zmianą. Wiąże się to z wysyłaniem nie tylko tego co chcesz wysłać ale dodawaniem dodatkowych "elementów". Niestety nie mam możliwości aby w tym momencie pokazać Ci jak wygląda transmisja dla prinbin i print ale różnią się one dość znacznie ilością przesyłanej informacji.
  • #7 4097484
    seba_x
    Poziom 31  
    Posty: 2071
    Pomógł: 29
    Ocena: 112
    crazy_phisic napisał:
    Jeśli program działał w sztywnych ramach czasowych to zmiana printbin na print jest już bardzo znaczną zmianą. Wiąże się to z wysyłaniem nie tylko tego co chcesz wysłać ale dodawaniem dodatkowych "elementów". Niestety nie mam możliwości aby w tym momencie pokazać Ci jak wygląda transmisja dla prinbin i print ale różnią się one dość znacznie ilością przesyłanej informacji.


    zgadza się , w przypływie desperacji zmieniłem tą linię tak jak było poprzednio i dalej nic , "anemia" , napisałem nowy programik który zapisuje 255 pajtów do 24c16 a potem je odczytuje , zapis bardzo wolny , odczyt szybszy ale i tak dużo wolniej niż miałem wcześniej , podejżewam że w nowszych wersjach bascoma coś jest skopane .

    mój program w orginale odczytywał zawartość całej pamięci 24c16 i wysyłał przez rs do PC , trwało to dosłownie 2-3 sekundy a teraz 2-3 minuty :cry:

    dodano po kilkunastu minutach...
    ------------------------------------------------------------------------------------

    problem rozwiązany , brakowało mi w programie :

    Config Scl = Portd.6
    Config Sda = Portd.7


    pisząc ten program ponad rok temu nie dodałem tych lini do kodu tylko ustawiłem w Options/Compiler/i2c , po instalacji nowej wersji nie ustawiłem tego (zwykłe przeoczenie)

    dziekuję wszystkim za chęć pomocy mi w tym jak się okazało błachym broblemie

Podsumowanie tematu

✨ Program napisany w Bascom 1.11.7.4 działający na mikrokontrolerze 90s8515 przy 8 MHz zaczął działać znacznie wolniej po skompilowaniu go w nowszej wersji Bascom 1.11.8.7 i zamianie procesora na ATmega8515 z zewnętrznym rezonatorem 8 MHz. Problem objawiał się zwłaszcza wolną obsługą magistrali I2C (EEPROM 24c16), podczas gdy wyświetlanie na LCD i reakcja na przyciski były względnie szybkie. Po wymianie procesora i podłączeniu programatora program działał wolno i niestabilnie. Okazało się, że w nowej wersji Bascom konieczne jest jawne zadeklarowanie pinów SCL i SDA w kodzie za pomocą dyrektyw Config Scl = Portd.6 oraz Config Sda = Portd.7, co wcześniej było ustawiane w opcjach kompilatora. Brak tych deklaracji powodował znaczne spowolnienie komunikacji I2C i błędne działanie programu. Po dodaniu tych linii program wrócił do pierwotnej szybkości działania. Fusebity nie miały wpływu na problem, a zmiana polecenia printbin na print nie rozwiązała go.
Podsumowanie wygenerowane przez AI na podstawie treści dyskusji.
REKLAMA