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

bleeding-edge-toolchain - kolejny toolchain dla ARM

10 Lut 2013 12:50 35859 219
  • Specjalista - Mikrokontrolery
    Witam!

    Na swojej stronie zamieściłem nowe paczki z toolchainem dla ARM, który nazwałem sobie bleeding-edge-toolchain (; Dłuższy opis całej idei i motywacji można przeczytać tutaj - http://www.freddiechopin.pl/pl/artykuly/35-arm/87-bleeding-edge-toolchain-o-co-chodzi Jak napisałem gdzieś jakąś głupotę lub jakby komuś coś nie działało (choć "u mnie działa" (; ) to piszcie!

    EDIT: Info da osoby zgłaszającej do moderatora - oto znacznik dla tego tematu - "ARM". Za mało? No to "ARM7, Cortex-M0, Cortex-M0+, Cortex-M3, Cortex-M4, Cortex-M4F, Cortex-R4". Teraz znów za dużo? Jaki mają sens tagi w przypadku tematu który nie jest "problemem z czymś konkretnym", a informacją o czymś ogólnym dla całej gamy mikrokontrolerów ARM?

    4\/3!!
  • IT SerwisIT Serwis
  • Poziom 26  
    No dobra, to pytanie takie - to zadziała dobrze przy korzystaniu z SPL'a? Nie żebym był fanem, ale jestem na etapie przepisywania kodu z SPL na rejestry+bb. Testuję toto po kawałku, no i właśnie CoIDE wypluło mi to:
    Code:

           [cc] arm-none-eabi-gcc -mcpu=cortex-m3 -mthumb -Wall -ffunction-sections -g -Os -c -DSTM32F103VC -DSTM32F10X_HD -DUSE_STDPERIPH_DRIVER -D__ASSEMBLY__ -IE:\Alagner\Dokumenty\CooCox\TouchPanel\hdr -IE:\Alagner\Dokumenty\CooCox\TouchPanel\cmsis_boot -IE:\Alagner\Dokumenty -IE:\Alagner\Dokumenty\CooCox\TouchPanel\STM32F10x_StdPeriph_Lib_V3.4.0\inc -IE:\Alagner\Dokumenty\CooCox\TouchPanel\SysTick -IE:\Alagner\Dokumenty\CooCox\TouchPanel\STM32F10x_StdPeriph_Lib_V3.4.0 -IE:\Alagner\Dokumenty\CooCox\TouchPanel\cmsis -IE:\Alagner\Dokumenty\CooCox\TouchPanel\TouchPanel -IE:\Alagner\Dokumenty\CooCox -IE:\Alagner\Dokumenty\CooCox\TouchPanel -IE:\Alagner\Dokumenty\CooCox\TouchPanel\GLCD E:\Alagner\Dokumenty\CooCox\TouchPanel\cmsis\core_cm3.c
           [cc] C:\Users\Alagner\AppData\Local\Temp\cc58u4nJ.s: Assembler messages:
           [cc] C:\Users\Alagner\AppData\Local\Temp\cc58u4nJ.s:508: Error: registers may not be the same -- `strexb r0,r0,[r1]'
           [cc] C:\Users\Alagner\AppData\Local\Temp\cc58u4nJ.s:533: Error: registers may not be the same -- `strexh r0,r0,[r1]'


    Póki co mam tam niezły mix, jak przepiszę wszystko do postaci bez SPL i zadziała na linaro dobrze, to będzie można dokładniej szukać co nie chce zagrać. Ew. CooCox coś miesza, spróbuję do Eclipse'a wszystko przerzucić, ale najpierw chcę się tego SPLa pozbyć.

    pzdr.
  • Specjalista - Mikrokontrolery
    To jest błąd w CMSIS - pisałem o tym tutaj - http://www.freddiechopin.info/pl/artykuly/35-...tm32f10x-standard-peripherals-library?start=4 Generalnie możesz więc sobie to poprawić ręcznie albo skombinować nową wersje CMSIS/SPL (w nowszych wydaniach z tego co wiem błąd jest poprawiony).

    Generalnie taki sam błąd wykryje też toolchain linaro (i zapewne CodeSourcery - w sumie to każdy [; ), ale jego pojawienie się (lub nie) jest dziwnym trafem okoliczności zależne w jakiś sposób od poziomu optymalizacji...

    4\/3!!
  • Poziom 26  
    No właśnie dziwne jest to, że jak przestawię w CooCox'ie toolchain path na ten wskazujący linaro, to błąd się nie pojawia. Reszta ustawień jest ta sama.

    pzdr.
  • IT SerwisIT Serwis
  • Specjalista - Mikrokontrolery
    U mnie ten błąd pojawiał się właśnie na linaro [; No ale musisz mi uwierzyć - to jest błąd w bibliotece. Żeby nie być gołosłownym, oto fragment dokumentacji tych rozkazów z dokumentacji ARM (przyznam że jego zrozumienie może być problematyczne):

    Cytat:
    STREX<c> <Rd>,<Rt>,[<Rn>{,#<imm8>}]
    ...
    d = UInt(Rd); t = UInt(Rt); n = UInt(Rn); imm32 = ZeroExtend(imm8:'00', 32);
    if BadReg(d) || BadReg(t) || n == 15 then UNPREDICTABLE;
    if d == n || d == t then UNPREDICTABLE;


    4\/3!!
  • Specjalista - Mikrokontrolery
    Widzę, że z tym toolchainem tez masz coś wspólnego. Mają te dwa toolchainy coś wspólnego ze sobą?
  • Poziom 26  
    Przy flash+load na LM4F120 wywaliłem Twoje gdb:
    Code:

    /home/freddie/bleeding-edge-toolchain/win-x64/src/gdb/gdb/linespec.c:2329: internal-error: decode_line_full: Assertion `state->canonical_names[i] != NULL' failed.
    A problem internal to GDB has been detected,
    further debugging may prove unreliable.

    This application has requested the Runtime to terminate it in an unusual way.
    Please contact the application's support team for more information.


    Przy linaro problem nie występuje. Jak chcesz mogę Ci dołączyć problematycznego elfa/projekt.

    pzdr.
  • Specjalista - Mikrokontrolery
    Za każdym razem taki problem wychodzi? U mnie na STM32 i LPC17xx problemu nie ma /; No ale - poszukałbym w google czy taki błąd nie jest zgłoszony w bugzilli GDB, jeśli nie to warto zgłosić, jeśli tak to będzie wiadomo czy już rozwiązany... Mnie Twój problematyczny elf wiele nie pomoże, chyba że występuje nawet gdy w niepołączonym z OpenOCD w konsoli ładujesz ten plik poleceniem "load"...

    4\/3!!
  • Poziom 26  
    no właśnie nie za każdym razem, z tego co zauważyłem póki co - jedynie przy próbie wgrania z niepoprawną konfiguracją PLL (a swoją drogą manual od TI chyba ma zachęcić do używania ich PeriphLib i zniechęcić do rejestrów - bo jak otwarłem jej dokumentację to jest całkiem przyjemnie napisana. A datasheet w porównaniu do ST prezentuje niskie stany średnie - tzn. można się kiedyś czegoś doczytać).
    Pobawię się tym jeszcze, ew. zaciągnę wersję na Win32 zamiast x64.
  • Specjalista - Mikrokontrolery
    Dziś w końcu skompilowałem nową wersję, z najnowszymi dodatkami do newliba od ARM + kilka ciekawych opcji z mojej własnej inwencji. Wersja bazuje na GCC ARM Embedded 4.7-2013-q1-update

    Pliki tym razem dostępne są na stronie sourceforge, na mojej stronce w dziale Download są odpowiednie linki.

    http://www.freddiechopin.info/pl/download/category/11-bleeding-edge-toolchain
    https://sourceforge.net/projects/bleeding-edge/files/130503/

    4\/3!!
  • Poziom 17  
    Freddie Chopin napisał:
    [...] najnowszymi dodatkami do newliba od ARM [...]


    Skąd bierzesz dodatki do newliba od ARMa? ARM (jako organizacja) ma jakiegoś swojego brancha newliba jak dla gcc (ARM/embedded)?
  • Specjalista - Mikrokontrolery
    leoha napisał:
    Skąd bierzesz dodatki do newliba od ARMa? ARM (jako organizacja) ma jakiegoś swojego brancha newliba jak dla gcc (ARM/embedded)?

    Te same osoby które pracują nad toolchainem określanym kiedyś jako "linaro" - czyli nad paczkami "GCC ARM Embedded" na których bazuję - pracują też nad modyfikacjami newliba. Ostatnimi czasy dodali 3 patche z następującymi opcjami:
    --disable-newlib-fvwrite-in-streamio disable iov in streamio
    --disable-newlib-fseek-optimization disable fseek optimization
    --disable-newlib-wide-orient Turn off wide orientation in streamio

    Do tego "od siebie" dorzuciłem jeszcze:
    --disable-newlib-atexit-alloc disable dynamic allocation of atexit entries
    --enable-newlib-reent-small enable small reentrant struct support
    oraz wywaliłem
    --enable-newlib-register-fini enable finalization function registration using atexit

    4\/3!!
  • Poziom 17  
    OK, dzieki.

    Możesz rozważyć jeszcze:
    Code:
    --enable-target-optspace

    Cytat:
    allows certain functions to use algorithms designed for space rather than speed. It also compiles the whole library with -Os.
  • Specjalista - Mikrokontrolery
    Ta opcja nie jest zbyt ciekawa akurat, bo ona raczej działa tak "wywal wszystkie zoptymalizowane funkcje i zastąp je tępymi" - przykłady to np strlen() czy strcpy(). Poza tym ona oszczędza tylko rozmiar kodu, a nie RAMu, więc jak dla mnie gra nie warta świeczki.

    EDIT: krótkie info - wszystkie pliki przeniosłem na sourceforge, na mojej stronce w dziale Download są zewnętrzne odsyłacze

    4\/3!!
  • Specjalista - Mikrokontrolery
    Wrzuciłem nową kompilację, szczegóły i przyczyny w artykule na stronce, nie ma sensu kopiować (; http://www.freddiechopin.info/pl/artykuly/34-...enocd-070-oraz-bleeding-edge-toolchain-130503

    4\/3!!
  • Specjalista - Mikrokontrolery
    Zebrałem się w sobie i wrzuciłem nową kompilację - z istotnych zmian (poza nowymi komponentami oczywiście), warto chyba wymienić następujące rzeczy:
    - newlib-nano i "size optimized libstdc++" są też zawarte w tym toolchainie, podobnie jak w oryginalnym linaro (hasło-klucz: nano.specs) - nie są pomijane jak w poprzednich wersjach,
    - toolchain zawiera też oryginalne przykłady z paczki linaro - nie są kasowane jak w poprzednich wersjach,
    - nowa opcja w newlib - --disable-newlib-unbuf-stream-opt - to taki cud techniki, dzięki któremu zapis do niebuforowanego strumienia (np. fiprintf(stderr, ... )) nie kończy się piękną alokacją 1kB na stosie w ramach przyspieszenia działania kodu.

    Poniżej "release notes" (;

    Cytat:
    GNU Tools for ARM Embedded Processors / bleeding-edge-toolchain
    version: 130810
    build date: 10.08.2013
    package date: 10.08.2013
    build system: Linux 3.10.5-1-ARCH #1 SMP PREEMPT Mon Aug 5 08:04:22 CEST 2013 x86_64 GNU/Linux
    host systems:
    - 32-bit Windows (i686-w64-mingw32)
    - 64-bit Windows (x86_64-w64-mingw32)
    - 64-bit Linux (x86_64-unknown-linux-gnu)
    target system: bare-metal ARM (arm-none-eabi)
    compiler: GCC 4.8.0 for Windows (mingw32-w64; rubenvb 130323), GCC 4.8.1 for Linux

    Based on original linaro release GCC ARM Embedded 4.7-2013-q2-update
    https://launchpad.net/gcc-arm-embedded/4.7/4.7-2013-q2-update

    Components used:
    - gcc, ARM/embedded-4_7-branch, r200056 (13.06.2013 03:30:17), svn://gcc.gnu.org/svn/gcc/branches/ARM/embedded-4_7-branch
    - binutils, commit 297552c5b758d1544964e9f761188c25c5da6f91 (10.08.2013 00:00:05), git://sourceware.org/git/binutils.git
    - newlib, commit 6e8a1660b54f32f96be51b94b5fd5eb861fa8a79 (08.08.2013 15:17:09), git://sourceware.org/git/newlib.git
    - gdb, commit e6cace300d7d3e09fc2256104cbc89b8c09f9170 (10.08.2013 00:00:05), git://sourceware.org/git/gdb.git
    - cloog-ppl 0.15.11, ftp://gcc.gnu.org/pub/gcc/infrastructure/cloog-ppl-0.15.11.tar.gz
    - expat 2.0.1, http://space.dl.sourceforge.net/project/expat/expat/2.0.1/expat-2.0.1.tar.gz
    - gmp 5.0.5, ftp://ftp.gmplib.org/pub/gmp-5.0.5/gmp-5.0.5.tar.bz2
    - libelf 0.8.13, http://www.mr511.de/software/libelf-0.8.13.tar.gz
    - libiconv 1.14, http://ftp.gnu.org/pub/gnu/libiconv/libiconv-1.14.tar.gz
    - mpc 1.0.1, http://www.multiprecision.org/mpc/download/mpc-1.0.1.tar.gz
    - mpfr 3.1.2, http://www.mpfr.org/mpfr-current/mpfr-3.1.2.tar.xz
    - ppl 0.11, ftp://gcc.gnu.org/pub/gcc/infrastructure/ppl-0.11.tar.gz
    - zlib 1.2.8, http://zlib.net/zlib-1.2.8.tar.gz

    Differences from original linaro release:
    - the most recent components used where possible, core components directly from HEADs of repositories
    - compiled with recent toolchain, which results in much better performance on host system
    - libstdc++ with disabled exceptions (as in size-optimized libraries that come in "nano" set)
    - newlib with different configure options (--enable-newlib-register-fini removed, --enable-newlib-io-c99-formats,
    --disable-newlib-atexit-dynamic-alloc, --enable-newlib-reent-small, --disable-newlib-fvwrite-in-streamio,
    --disable-newlib-fseek-optimization, --disable-newlib-wide-orient, --disable-newlib-unbuf-stream-opt)
    - all libraries are not stripped - debugging them is possible
    - lack of some text files and documents

    Build commands used:
    ./build-prerequisites.sh
    ./build-toolchain.sh

    This package and info about it can be found on Freddie Chopin's website:
    http://www.freddiechopin.info/


    4\/3!!
  • Poziom 14  
    Czy źródła newliba są te same co linaro? Czy dodałeś jakieś łatki od siebie?
    Bo tak w ogóle to wiesz czemu znak "\b" zawiesza scanf()? Wszystko inne działa, a jak wcisnę backspace, to w ogóle już nie wchodzi do _read() i scanf() wisi.
  • Specjalista - Mikrokontrolery
    Źródła newliba są inne - linaro używa starej wersji + jakieś swoje back-fixy, ja zaś używam najnowszej wersji wprost z repozytorium, bez żadnych poprawek. Na ile "inne" one są to już inna sprawa, bo jeśli tych back-fixów jest sporo, to mają prawie nową wersję (;

    Czemu użycie \b powoduje problem - no idea. W starszych wersjach działało? Bo jak rozumiem w linaro działa Ci to bez problemów? Możesz zawsze spróbować sprawę trochę zdebuggować (w końcu biblioteki nie są okrojone z symboli dla debuggera, wiec wystarczy pobrać źródła i wskazać je w Eclipse gdy o to poprosi), albo ograniczyć sprawę używając np sscanf() - żeby pominąć read() - i potem samego read() - żeby pominąć scanf().

    Generalnie jakiś czas temu parsowałem stringi z backspace'm przy użyciu bleeding-edge-toolchaina, ale chyba akurat bez użycia scanf(), bodajże parsowanie było ręczne, przez fgets() i strtok() + inne funkcje.

    4\/3!!
  • Poziom 14  
    Z linaro też nie działa, może to robię coś źle.
    Mam tak:

    W syscall.c
    Kod: c
    Zaloguj się, aby zobaczyć kod


    później mam tak:
    Kod: cpp
    Zaloguj się, aby zobaczyć kod

    i dopóki nie wcisnę \b wszystko jest OK, a jak wcisnę \b to _read() już nie jest wywoływana a scanf() zwraca -1 .
  • Specjalista - Mikrokontrolery
    No ale jak wyślesz to '\b', to musisz je w końcu odczytać chyba, bo ono będzie siedziało w buforach cały czas... scanf() zwraca -1, bo '\b' nie pasuje do wzorca - oczekujesz liczby, a backspace liczbą nie jest. Tak więc read() nie jest wywoływane, bo aktualnym znakiem w buforze jest '\b' i dopóki go nie odczytasz to nie ma potrzeby wywoływać read()...

    A przynajmniej ja bym tak to rozumiał, co wydaje się potwierdzać kod newliba - jeśli scanf() natrafi na coś czego nie oczekuje, wykonuje coś na styl funkcji ungetc() (jakaś przycięta wersja tej samej funkcjonalności), więc nieodczytany znak ląduje w priorytetowej kolejce znaków "odłożonych" na później.

    4\/3!!
  • Poziom 14  
    Coś nie bardzo rozumie :( wydawało mi się że scanf() już sam zrobi porządek i umie zinterpretować backspace i że jest bardziej idiotoodporny (na mnie się wyłożył ;) ).
    Ale dodanie tego kodu pomogło:

    Kod: c
    Zaloguj się, aby zobaczyć kod
  • Specjalista - Mikrokontrolery
    imarszi napisał:
    Coś nie bardzo rozumie wydawało mi się że scanf() już sam zrobi porządek i umie zinterpretować backspace i że jest bardziej idiotoodporny (na mnie się wyłożył ).

    Nadmiar optymizmu [; Wg mojej wiedzy '\b' nie jest interpretowany jako backspace przez żadną funkcję biblioteczną C.

    Swoją drogą Twoja implementacja _read() nie do końca jest poprawna - funkcja ta nie powinna czekać w nieskończoność na zadaną liczbę bajtów, jeśli nie są one dostępne. W Twoim przypadku to chyba nie ma akurat znaczenia, bo skoro buforowanie masz wyłączone (IONBF), to _read() jest wywoływane z długością 1, ale jakbyś zrobił np. buforowane do linii (IOLBF), to już Ci to w ogóle nie zadziała. Wydaje mi się, że to powinno działać następująco:
    - w przypadku PIERWSZEGO bajtu odbieranego przez _read() funkcja powinna być blokująca
    - każdy kolejny bajt powinien być nieblokujący - tzn. wyciągasz tylko to co jest dostępne w buforach, jeśli nie ma nic więcej, to zwracasz tyle ile odebrałeś, jeśli funkcja nadrzędna potrzebuje więcej, to _read() zostanie wywołane ponownie i patrz wyżej.

    http://pubs.opengroup.org/onlinepubs/009695399/functions/read.html

    Cytat:
    When attempting to read a file (other than a pipe or FIFO) that supports non-blocking reads and has no data currently available:

    If O_NONBLOCK is set, read() shall return -1 and set errno to [EAGAIN].

    If O_NONBLOCK is clear, read() shall block the calling thread until some data becomes available.

    The use of the O_NONBLOCK flag has no effect if there is some data available.


    Ta sama zasada (wg mnie) odnosi się do funkcji write().

    4\/3!!
  • Poziom 23  
    Witam!
    Wyskoczył mi taki błąd przy próbie użycia spintf:
    Code:

    undefined reference to `_sbrk'   vfo      line 58, external location: \home\freddie\bleeding-edge-toolchain\src\newlib\newlib\libc\reent\sbrkr.c   C/C++ Problem

    Użycie ma na celu zamianę liczby na string do wyświetlenia:
    Code:

    sprintf(bufpomocniczy, "%d",Frequency );
        for(y=0;y<9;y++)buf[y]=bufpomocniczy[y];


    Jak to ugryźć?
  • Specjalista - Mikrokontrolery
    Dodać syscalls, a przede wszystkim _sbrk_r(), które są wymagane dla malloc(), który zaś jest wymagany dla funkcji z rodziny printf(). Przykładowe syscalls (w zasadzie tzw. "stuby") z faktycznie działającym _sbrk_r() (dostosowanym do kodu z moich szablonów-przykładów) - do pobrania z mojej strony (Download > ARM > Różne > syscalls)

    4\/3!!
  • Poziom 23  
    Jak Ci można podziękować za wszystko?? Pomagasy dawno się pewnie znudziły, punktów do garka nie włożysz... Wsparcie lepsze niż w niejednej komercyjnej jednostce.
    Po prostu dzięki wielkie!

    Wracając na ziemię-ten sprintf tak musi flasha "żreć"? Bez niego bin-a było 5kb a z nim 30kb! Jakaś optymalizacja go ucywilizuje czy nie?

    Poszło po samym dodaniu syscalls.c.

    Jeszcze takie warningi:
    Code:

    Description   Resource   Path   Location   Type
    implicit declaration of function 'sprintf' [-Wimplicit-function-declaration]   main.c   /vfo   line 431   C/C++ Problem
    incompatible implicit declaration of built-in function 'sprintf' [enabled by default]   main.c   /vfo   line 431   C/C++ Problem

    Ważne są i da się je jakoś naprawić?
  • Specjalista - Mikrokontrolery
    Bruum napisał:
    Wracając na ziemię-ten sprintf tak musi flasha "żreć"? Bez niego bin-a było 5kb a z nim 30kb! Jakaś optymalizacja go ucywilizuje czy nie?

    No niestety, zbyt wiele nie poradzisz, wszelakie printfy są spore, szczególnie te które muszą obsługiwać liczby zmiennoprzecinkowe - bo jest jeszcze cała rodzina niestandardowych iprintf(), tyle że one NIE obsługują float i double, a widzę że właśnie to Ci jest potrzebne.

    O ile flashem specjalnie bym się nie przejmował (; , to większym problemem jest RAM, którego wywołanie takiej funkcji potrafi "zużyć" koło kilobajta...

    Jeśli nie potrzebujesz "pełnej mocy" tej funkcji (czyli wszystkiego co można dopisać do specyfikatora %d), to zawsze możesz napisać swoją funkcję lub spróbować skorzystać z którejś z niestandardowych dostępnych z newlib (przejrzyj dokumentację - sekcja o stdlib.h - funkcje takie jak ecvt(), gvcvt(), ecvtbuf(), ...).

    Bruum napisał:
    Ważne są i da się je jakoś naprawić?

    Wbrew pozorom tego typu warningi są niesamowicie istotne! Naprawienie ich jest zaś wyjątkowo proste - w tym wypadku wystarczy przypomnieć sobie, że istnieje coś takiego jak "#include <stdio.h>" (;

    4\/3!!
  • Poziom 23  
    Skoro warningi są istotne to zaatakuję takiego:
    Code:

    Description   Resource   Path   Location   Type
    Unused static function '__Default_Handler'   vectors.c   /vfo   line 22   Code Analysis Problem

    Faktycznie nigdzie w kodzie nie wywoływana funkcja.
    Przy okazji, czy to jest źle napisane?
    Code:

    #define TIMenc                        TIM2

      TIMenc->CCMR1 |= TIM_CCMR1_CC1S_0;  //CC1S= 01(TIMx_CCMR1 register, TI1FP1 mapped on TI1)
        TIMenc->CCMR1 |= TIM_CCMR1_CC2S_0;  //CC2S= 01(TIMx_CCMR1 register, TI2FP2 mapped on TI2)
        TIMenc->CCER &= ~TIM_CCER_CC1P;     //CC1P=0 (TIMx_CCER register, TI1FP1 noninverted, TI1FP1=TI1)
        TIMenc->CCER &= ~TIM_CCER_CC2P;     //CC2P=0 (TIMx_CCER register, TI2FP2 noninverted, TI2FP2=TI2)

    Bo tak jakby nie dawało rezultatu. A tak na marginesie-czy w eclipse z "dodatkami" jest możliwość podglądu rejestrów takich jak np. TIM2->CCMR1 czyli konfiguracyjnych? Istnieje odpowiedni guzik czy coś trzeba więcej kombinować?
  • Specjalista - Mikrokontrolery
    Bruum napisał:
    Skoro warningi są istotne to zaatakuję takiego:

    Zacznijmy od tego, że to nie jest ostrzeżenie kompilatora, tylko statycznego analizatora z Eclipse ("Code Analysis Problem").

    Bruum napisał:
    Faktycznie nigdzie w kodzie nie wywoływana funkcja.

    Wywoływana faktycznie nie jest, za to wszystkie nieużywane przerwania są do niej przypięte, więc jest jednak potrzebna (; Obecnie - zamiast takich kombinacji - robię po prostu tak, że każde przerwanie ma domyślnie swój handler, oczywiście pętlę nieskończoną, więc takiego problemu nie ma. Jeśli ten problem Ci przeszkadza, to możesz sobie tak przerobić plik vectors.cpp i będzie po sprawie.

    Bruum napisał:
    Bo tak jakby nie dawało rezultatu.

    Wygląda poprawnie składniowo (;

    Bruum napisał:
    A tak na marginesie-czy w eclipse z "dodatkami" jest możliwość podglądu rejestrów takich jak np. TIM2->CCMR1 czyli konfiguracyjnych? Istnieje odpowiedni guzik czy coś trzeba więcej kombinować?

    Trzeba sobie zainstalować wtyczkę "embsysregview", a następnie sobie ją skonfigurować (wybrać układ) i "pokazać".

    4\/3!!
  • Poziom 23  
    Jak zwykle bingo!
    Dzięki!
    Nie miałem rezultatu bo o taktowaniu timera zapomniałem...
    Wystarczy tej zabawy na dzisiaj-
    Wesołych świąt Bożego Narodzenia!