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.

Niewidoczny step w symulatorze w MplabX

poldi 07 Wrz 2013 18:12 2289 8
  • #1 07 Wrz 2013 18:12
    poldi

    Poziom 16  

    Mam problem z MplaX. Mianowicie gdy chcę użyć debugera hardware
    krzyczy że nie mam break pointów sprzętowych. Nie wiem jak to się ustawia.
    A w symulatorze nie pokazuje skoków po lini programu a jest gdzieś poza.
    Launching
    Initializing simulator
    User program running
    No source code lines were found at current PC 0x30e
    User program stopped
    Też nie wiem o co chodzi.

    0 8
  • CControls
  • #2 07 Wrz 2013 20:01
    Marek_Skalski
    Moderator Projektowanie

    Jaki kontroler (PIC 8-bit, PIC-16bit, dsPIC, PIC32), jaki język (asm, C)?
    1. Pokaż program.
    2. Jaki masz programator/debugger? Najwyraźniej jest to tylko programator i nie możesz w nim ustawiać breakpoint'ów.
    3. Skoro program dotarł pod adres 0x30e, a środowisko (MPLAB X) nie widzi tam programu (np. domyślnie aplikacje dla dsPIC startują od 0x200), to wstrzymuje wykonywanie dalszych instrukcji. Jeżeli programujesz w asm, to pewnie sam sobie jesteś winny. Jeżeli w C, to znaczy, że nie potrafisz się dogadać z kompilatorem albo linkerem.
    4. W kwestii obsługi symulatora (step into, step over...) zalecam lekturę instrukcji obsługi dołączonej do Mplab X. Wszystko jest tam klarownie opisane. A żelazną regułą jest ustawianie breakpoint'a na początku funkcji main, jeżeli piszesz w C.

    0
  • #3 07 Wrz 2013 20:53
    94075
    Użytkownik usunął konto  
  • CControls
  • #4 08 Wrz 2013 00:26
    poldi

    Poziom 16  

    Porcek 16f77 programator Pickit3 kompilator xc8

    początek kodu do testów wyswietlacza isterowania po ISP.


    Kod: c
    Zaloguj się, aby zobaczyć kod

    #include <xc.h>
    #include <stdio.h>
    #include <stdlib.h>
    #include "KS0108.h"
    //#include "mplabcert_bmp.h"
    //__PROG_CONFIG(1,0X1F71);
    __CONFIG(WDTDIS & HS & UNPROTECT);
    unsigned char tab[]={"HALO"};


    unsigned char kbhitt(void);
    unsigned char kbhitenc(void);
    void putch(char znak);
    void WriteWiper(unsigned char proc);

    #define encoder1_V PORTBbits.RB0
    #define encoder2_V PORTBbits.RB1
    #define step_klaw PORTBbits.RB2
    #define right 0xAA
    #define left 0x55
    #define SCK PORTCbits.RC6
    #define SI PORTCbits.RC5
    #define CS PORTCbits.RC7
    #define Alarm PORTBbits.RB3
    unsigned char encV=0;
    unsigned char kbhit_enc;
    unsigned char keyhit;
    unsigned int czas2,czas1;
    unsigned char key;



    void main(void) {
    // PORTE=0x00;
    // PORTA=0x00;
    // __delay_ms(1000);
    TRISB=0xff;
    TRISC=0x00;
    ADCON1bits.PCFG1=1;
    ADCON1bits.PCFG2=1;
    OPTION_REGbits.nRBPU=0;

    PIE1bits.TMR1IE=1; // enable interrupt TMR1
    T1CONbits.TMR1ON=1;
    T1CONbits.T1CKPS1=0; // Timer1 Input Clock Prescale Select bits
    T1CONbits.T1CKPS0=1; // Timer1 Input Clock Prescale Select bits
    T1CONbits.T1OSCEN=0; //Timer1 Oscillator Enable Control bit
    T1CONbits.TMR1CS=0;

    INTCONbits.PEIE=1; // pryferia interrupt
    INTCONbits.GIE=1; //global interrupt
    CS=1;
    SCK=0;
    SI=0;

    [/syntax]

    0
  • #5 08 Wrz 2013 01:20
    Marek_Skalski
    Moderator Projektowanie

    1. Piszesz w C, a jakbyś pisał w asemblerze. Zakładam, że funkcja main() jest domknięta. W programie powyżej jest otwarta, ale wtedy nie powinna się kompilować.
    2. PicKit to tylko programator. Debugger, niestety nie jest obsługiwany przez Mplab X, a jedynie w starym MPLAB. Programator z debuggerem to ICD3. Ale też niewiele warty, bo ma całe 6 sprzętowych brakepointów :/ I chociaż oferuje 999 programowych, to każda zmiana wymaga przeprogramowania uC.
    3. Uruchom program w symulatorze, włącz okno zdeasemblowanego programu (Window -> Debugging -> Disassembly) i zobacz co się dzieje w pełnym programie. To co tutaj wstawiłeś to tylko jakiś init, więc nawet nie ma czego testować.
    4. Nadal aktualne.
    5. Niestety, też aktualne.

    Pytanie: dlaczego uparłeś się na PIC w 8 bitach? Od dłuższego już czasu męczysz się z nimi. Nie szkoda Ci życiowej energii?

    0
  • #6 08 Wrz 2013 08:47
    poldi

    Poziom 16  

    Mam chęć przejść na 32bitowce ale tam na 3V wszystko się opiera.
    Nie przywykłem do takiego VCC. Możesz powiedzieć jaki tools programator-debuger
    byłby najleprzy do tego środowiska. Zastanawiam się też nad ARMami.
    Znajomy co więcej robi wszystko na nich opiera, picków nie uznaje.

    0
  • Pomocny post
    #7 08 Wrz 2013 12:15
    Marek_Skalski
    Moderator Projektowanie

    Poldi, przynajmniej raz w tygodniu pojawia się na Forum pytanie w stylu "co wybrać?", "jak zacząć?" albo "który jest najlepszy?" i za każdym razem temat jest rozwijany na 2 lub 3 strony. Spokojnie poczytaj i wnioski wyciągnij sam.
    I to nie jest tak, że ARM jest ok, a cała reszta do kosza.
    Jeżeli chcesz znać moje zdanie (na początek), to aktualnie najłatwiej zacząć z ARM od ST w postaci płytki STM32xxDiscovery. xx to F0..F4, L, VL. Każda z tych płytek nie powinna kosztować więcej niż $18 USD, a masz na pokładzie procka z pełnym zasilaniem i programatorem/debuggerem, kilka układów dodatkowych (w F4: sensory, audio), jakieś ledy, przycisk do interakcji. Na początek dość dobre, a jak już się oswoisz i polubisz, to możesz poszukać zestawów od Waveshare - Link, albo robić płytki sam. Zwracam uwagę, że prg/dbg możesz wykorzystywać do innych urządzeń. I to wszystko w cenie grubo poniżej startu z xmega, PIC czy LPC (ARM od NXP). Lubię też dsPIC, ale nie rozumiem polityki MCP w zakresie utrudniania życia użytkownikom i wprowadzania idiotycznych ograniczeń czy usuwania tego co dobre z nowszych wersji softu; vide slidery i wykresy realtime w Mplab v8.xx w Mplab X już nie występują.
    Co do zasilania 3,3V. Tego już raczej nie unikniesz. Karta pamięci - 3,3V albo 1,8V, TFT - 3,3V i mniej, rosnąca liczba czujników i modułów radiowych z 5V->3,3V i mniej, układy audio 3,3V i mniej. A ogólnie sprowadza się to do zamontowania stabilizatora 3,3V zamiast 5V i wszystko działa tak samo, ponieważ nadal są tylko 2 stany dozwolone: 0 i 1. Inna rzecz, STM32Fxxx mają sporo pinów wykonanych jako 5V tolerant, więc chociaż same nie wystawią 5V, to można im przypiąć takie napięcie z innego urządzenia bez obawy uszkodzenia. Kolejne ograniczenie znika. I tylko remapowanie pinów nadal jest chyba najlepiej rozwiązane w nowszych (ds)PIC.
    Tutaj znajdziesz informacje o całej rodzinie. Zalecam ostrożność, bo te lepsze nadal nie są do kupienia.
    To co w zupełności zastąpi PIC16F77, to np. STM32F051R8. Kosztuje 2x mniej niż PIC, a dostajesz więcej peryferiów, zużywa mniej prądu przy tej samej częstotliwości nominalnej, a pracuje i tak szybciej. Znajdziesz go też na płytce STM32F0Discovery. Płytka jest dość biednie wyposażona, ale dzięki temu możesz dowolnie podłączać swoje elementy. Discovery

    0
  • #8 08 Wrz 2013 13:39
    poldi

    Poziom 16  

    W końcu ktoś życzliwy na forum co udziele nie mało informacji.
    Muszę się przestawić na te 3.3V nie mam inej rady. Dotychczas robiłem na 5V.
    Ten 16f77 to stare moje zasoby. Obecnie jak robie coś używam nowszych
    układów. Ogólnie rzecz biorąc do wielu projektów nie ma potrzeby używać
    16 cz 32 bitowców tym bardzie że producent rozwija dalej tą technologie.
    Lubię wykorzystywać maksymalnie możliwości procka a przy skromnych projektach rozbudowane ukałady mam wrażenie że się marnują. Fakt że cenowo to bywa różnie.
    To zleży jak kto na to patrzy. Bierze się to pod uwagę przy masowej produkcji.
    Co do środowiska MplabX to mam pewne zastrzeżenia. Wolno to chodzi a i zdarzało się że stawał przy building .

    0
  • Pomocny post
    #9 09 Wrz 2013 07:30
    94075
    Użytkownik usunął konto