bleeding-edge-toolchain - kolejny toolchain dla ARM

Question

bleeding-edge-toolchain - kolejny toolchain dla ARM

Freddie Chopin 10 Lut 2013 12:50 33822 208

1
2
3
...
5
6
7

Odpowiedz | Nowy temat

#1 10 Lut 2013 12:50

Freddie Chopin Freddie Chopin

Specjalista - Mikrokontrolery

#1 10 Lut 2013 12:50

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!!

:: distortos - C++11 RTOS ::
:: JTAG-lock-pick Tiny 2 - ARM JTAG/SWD @ USB 2.0 ::
:: distortec.com :: distortec@facebook :: freddiechopin.info ::

Promuję tematy:
07.03.2015 [C++11][Cortex-M3/M4] - distortos - obiektowy RTOS dla mikrokontrolerów w C++
10.02.2013 bleeding-edge-toolchain - kolejny toolchain dla ARM

Odpowiedz | Nowy temat

1
2
3
...
5
6
7

alagner · Answer 1 · 2013-02-10T15:17:20+01:00

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.

Freddie Chopin · Answer 2 · 2013-02-10T15:27:54+01:00

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!!

alagner · Answer 3 · 2013-02-10T15:35:09+01:00

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.

Freddie Chopin · Answer 4 · 2013-02-10T15:40:15+01:00

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!!

michalko12 · Answer 5 · 2013-02-10T20:15:46+01:00

Widzę, że z tym toolchainem tez masz coś wspólnego. Mają te dwa toolchainy coś wspólnego ze sobą?

Freddie Chopin · Answer 6 · 2013-02-10T23:46:11+01:00

#7 10 Lut 2013 23:46

Freddie Chopin Freddie Chopin

Specjalista - Mikrokontrolery

#7 10 Lut 2013 23:46

To jest właśnie linaro (;

4\/3!!

:: distortos - C++11 RTOS ::
:: JTAG-lock-pick Tiny 2 - ARM JTAG/SWD @ USB 2.0 ::
:: distortec.com :: distortec@facebook :: freddiechopin.info ::

Promuję tematy:
07.03.2015 [C++11][Cortex-M3/M4] - distortos - obiektowy RTOS dla mikrokontrolerów w C++
10.02.2013 bleeding-edge-toolchain - kolejny toolchain dla ARM

alagner · Answer 7 · 2013-02-25T13:49:13+01:00

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.

Freddie Chopin · Answer 8 · 2013-02-25T15:02:37+01:00

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!!

alagner · Answer 9 · 2013-02-25T23:01:25+01:00

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.

Freddie Chopin · Answer 10 · 2013-05-03T20:05:26+02:00

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!!

leoha · Answer 11 · 2013-05-03T22:31:29+02:00

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

Freddie Chopin · Answer 12 · 2013-05-03T22:54:05+02:00

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!!

leoha · Answer 13 · 2013-05-03T23:15:21+02:00

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.

Freddie Chopin · Answer 14 · 2013-05-04T20:55:47+02:00

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!!

Freddie Chopin · Answer 15 · 2013-05-11T09:39:23+02:00

#16 11 Maj 2013 09:39

Freddie Chopin Freddie Chopin

Specjalista - Mikrokontrolery

#16 11 Maj 2013 09:39

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!!

:: distortos - C++11 RTOS ::
:: JTAG-lock-pick Tiny 2 - ARM JTAG/SWD @ USB 2.0 ::
:: distortec.com :: distortec@facebook :: freddiechopin.info ::

Promuję tematy:
07.03.2015 [C++11][Cortex-M3/M4] - distortos - obiektowy RTOS dla mikrokontrolerów w C++
10.02.2013 bleeding-edge-toolchain - kolejny toolchain dla ARM

Freddie Chopin · Answer 16 · 2013-08-10T21:56:20+02:00

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!!

imarszi · Answer 17 · 2013-08-11T11:50:08+02:00

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.

Freddie Chopin · Answer 18 · 2013-08-11T19:24:06+02:00

Ź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!!

imarszi · Answer 19 · 2013-08-11T22:11:51+02:00

Z linaro też nie działa, może to robię coś źle.
Mam tak:

W syscall.c

Zaloguj się, aby zobaczyć kod

później mam tak:

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 .

Freddie Chopin · Answer 20 · 2013-08-11T22:24:10+02:00

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!!

imarszi · Answer 21 · 2013-08-11T22:45:13+02:00

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:

Zaloguj się, aby zobaczyć kod

Freddie Chopin · Answer 22 · 2013-08-11T23:01:14+02:00

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!!

Bruum · Answer 23 · 2013-12-23T23:22:49+01:00

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źć?

Freddie Chopin · Answer 24 · 2013-12-23T23:41:41+01:00

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!!

Bruum · Answer 25 · 2013-12-24T00:43:26+01:00

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ć?

Freddie Chopin · Answer 26 · 2013-12-24T08:12:03+01:00

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!!

Bruum · Answer 27 · 2013-12-24T09:40:24+01:00

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ć?

Freddie Chopin · Answer 28 · 2013-12-24T10:00:51+01:00

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!!

Bruum · Answer 29 · 2013-12-24T15:32:59+01:00

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!