Próbowałem już kilku środowisk do STMów (AC6, Keil, Coocox), ale najfajniej używa mi się Atollica. Chętnie bym przy nim został - jest dopracowany i cenię sobie interfejsy eclipse'owe - jednak momentami używanie go jest strasznie toporne. W ciągu około półtorej roku pracy uzbierałem listę irytujących problemów których nijak nie mogę obejść:

1. konieczność ręcznego dodawania folderów do includów
Często dzielę projekty na mniejsze foldery w celu poprawy ogólnej przejrzystości, jednak foldery te nie dodają się automatycznie do listy przeszukiwania podczas kompilacji. Jest to mocno irytujące, bo nawet drobna zmiana w strukturze wymaga grzebania w ustawieniach projektu, podawania ścieżek itp. Ponadto, importując taki projekt na innym komputerze, muszę jeszcze raz podawać te ścieżki, bo z niewiadomych powodów zostają zapisane jako bezwzględne.

2. brak automatycznej opcji wgrywania bez debugu
Domyślnie program można przesłać tylko w trybie debugu, który chwilę się jednak uruchamia. Gdy wprowadzam drobne poprawki zależy mi na szybkości aktualizacji, a nie na debugu jako takim, jednak wygląda na to że Atollic nie wspiera domyślnie takiego trybu wgrywania softu. Na chwilę obecną obchodzę to przez skopiowanie konfiguracji debugu i usunięcie z niej ostatnich linijek w skrypcie startupowym (jest tam load, a później od razu disconnect). Działa to całkiem dobrze, ale znów - z każdym nowym projektem muszę to robić samemu, ręcznie.

3. niewygodne użycie bibliotek STD
O ile dla STM32F103 biblioteka jest domyślnie ładowana przy tworzeniu projektu, o tyle dla takiego STM32F030 ładowany jest HAL. Próbowałem podpinać bibliotekę ściągniętą wprost ze strony ST, jednak koniec końców nie udało mi się tego uruchomić. Na chwilę obecną kod na F0 piszę w Coocoxie, jednak w moim odczuciu jest strasznie niedopracowany, brak mu podstawowych funkcjonalności i ogólnie chętnie wróciłbym do Atollica. Z tego względu zastanawia mnie czy jest jakaś przyjemna metoda ładowania "niestandardowej" biblioteki dla konkretnego procesora. To samo tyczy się zresztą F103, w sytuacji gdybym chciał np. użyć innej wersji STD, a nie tylko standardowo podpiętej.

Tak jak wspomniałem, z samego interfejsu jestem mega zadowolony, jednak mozolna walka z powyższymi problemami skutecznie mnie zniechęca. Są to rzeczy z którymi męczę się przy każdym projekcie i zajmują mi niepotrzebnie czas na nieistotne operacje, przez co napisanie choćby migania LEDem masakrycznie się wydłuża. Byłbym wdzięczny za wszelkie rady w jaki sposób mógłbym to nieco usprawnić.

_________________
Więcej dziwactw na: www.youtube.com/user/mopsiok

W atollicu masz coś takiego jak perspektywa CMSIS pack manager. Jeżeli nie jest domyślnie włączona, w pasku Quick Acces wpisz Pack i powinna Ci się pokazać na liście do wyboru zielona ikonka z Podpisem CMSIS Pack Menager. W tej perspektywie kliknij sobie na niebieską strzałkę do odświeżania. Powinny Ci się po jakims czasie pojawić dostępne biblioteki CMSIS dla różnych mikrokontrolerów z rdzeniami Coretex M. Z listy zainstaluj sobie CMSIS 5.01 Core oraz biblioteki do różnych STMów jakie posiadasz. Następnie, po instalacji, tworząc nowy projekt wybierasz CMSIS project, podajesz jego nazwe, następnie wybierasz na jakiego proca, później czy ma byc debug czy realase czy może oba i finnish. Przenosi Ci do okienka konfiguracji CMSIS, wybierasz sobie z listy jakie drivery mają być w Twoim projekcie np UART, SPI, GPIO, RCC itp. Klikasz zapisz i się Ci wszystko updatetuje. Masz już wszystko fajnie pokonfigurowane. Zostaje wypełniać strukturki i klepać koda

------------------------ [ Dodano po: 5 minutach ]



W jaki sposób je dodajesz? I jaką masz wersję Trup Studio? Najnowsza to 8.00... Ja klikam prawym na projekt, New -> Folder i tworze nowy folder, następnie tworze w nim pliki nagłówkowe .h i źródłowe .c czy tam .cpp i tyle. wszystko Później normalnie się inkluduje.

Właśnie dzisiaj odkryłem CMSIS-packi, i działa to całkiem spoko dla F103 - jedyny minus to fakt że trzeba kombinować z plikiem startupu i skryptem linkera.
Jednak nie mogę się dogadać dla F030, ponieważ nie znajduje żadnych "użytecznych" driverów. Zainstalowałem paczkę Keil.STM32F0xx_DFP (odpowiednik F103 który faktycznie działa), jednak poza rdzeniem i startupem pod Keila niczego więcej mi nie znajduje. Poniżej podgląd na paczkę.


Na chwilę obecną znalazłem w plikach STD jakiś template dla Atollica, spróbuję go uruchomić.

------------------------ [ Dodano po: 4 minutach ]


Wczoraj zainstalowałem wersję 8.0.0, wcześniej używałem bodajże 6.0.0, ale w zasadzie robię tak samo jak ty. Uruchomiłem przykładowy projekt, w main.c odwołuję się do stm32f1xx_it.h i w takiej konfiguracji dostaję błąd, ponieważ Tmp nie jest dołączony do listy includowanych folderów. Staram się znaleźć jakieś sposób na automatyczne załączanie katalogów podczas ich tworzenia, na razie bezskutecznie.

_________________
Więcej dziwactw na: www.youtube.com/user/mopsiok

Hmm.. u mnie drzewo projektów wygląda tak:


a inkludowanie tak:


------------------------ [ Dodano po: 13 minutach ]

Ogólnie jeżeli bawisz się STMami to zainstaluj sobie STM32CubeMX

Ach, myślałem że jest szansa na automatyczne includowanie folderów, ale wygląda na to że ty po prostu ręcznie poruszasz się po katalogach. Ja u siebie mam zwykłe:

No nic, jeśli nie ma innej opcji to będę używać pełnych ścieżek.


Mam natomiast problem z uruchomieniem template'a dostarczonego wraz z STD. Robiąc tak jak jest napisane w readme, tzn. import -> existing projects into workspace, faktycznie bez problemu ładuję i kompiluję projekt. Problem jest natomiast taki, że nie tworzę nowego projektu na podstawie szablonu, tylko odwołuję się do szablonu, przez co szablon jest de facto jednorazowego użytku. Niby jest opcja copy projects into workspace, ale kopiowane są same pliki projektu, a źródła dalej są jako odwołania. Takie coś nawet się nie kompiluje, bo po skopiowaniu plików projektu przestaje się zgadzać odwołanie do źródeł.
Stąd moje pytanie, czy jest jakaś opcja żeby każdorazowo przy przy imporcie projektu kopiować również pliki biblioteki i zapisywać je wewnątrz katalogu projektu? Dokładnie tak jak ma to miejsce w zwykłym tworzeniu New -> C Project.

_________________
Więcej dziwactw na: www.youtube.com/user/mopsiok

a dlaczego w opcjach projektu nie dodasz swojego folderu z bibliotekami do includ ??
i w tedy masz w projekcie wszystkie swoje libsy dodane

Project --> Properities -->C/C++ Build --->Setings
i tu wybiersz

C Compilers ---> Directories i dodajesz ścieżkę ...

_________________
Zbuduj swój system [url=https://helion.pl/ksiazki/w-labiryncie-iot-budowanie-urzadzen-z-wykorzystaniem-ukladow-esp8266-i-esp32-andrzej-gromczynski,wlablo.htm#format/d]IOT[/url]

Tak zawsze robiłem, ale było to dość męczące przy przenoszeniu na inny komputer (ogólnie do innego workspace'a), ponieważ ścieżki nagle stawały się bezwzględne = nie były poprawne w nowej lokalizacji.

Całe szczęście po kilku dniach walki udało się uzyskać to co chciałem . Przede wszystkim w wersji 8.0.0 poprawili kwestię includów, dzięki czemu można podawać ścieżki względne i po przeniesieniu wciąż będzie ok.
Po długiej walce udało mi się uruchomić STD dla STM32F030. Było mnóstwo problemów po drodze, w skrócie:
- komponenty od Keila zawierają tylko CMSIS, nie ma STD jako takiego
- paczka STD dla F030 na stronie STM zawiera co prawda template'y do Atollica dla konkretnych procków, ale akurat dla wersji F030F4 skrypt linkera był nieprawidłowy (po nazwie podejrzewam że niechcący wkleili dla wersji F030R8) - przez to skompilowany program nie mógł się wgrać na procka (część programu poza zakresem pamięci w tej konkretnej wersji stma)
- tworzenie projektu dla F030F4 wprost z Atollica: program się kompiluje i wgrywa na stma, można go bez problemu debugować. Jednak struktura CMSIS w tym projekcie dostosowana jest już do HALa, przez co nie można jej wprost użyć z STD (STD w swoim kodzie odwołuje się do wszystkich peryferiów dostępnych w linii F0, natomiast CMSIS dostosowane do HALa ładuje konkretny plik .h w zależności od wybranego procka, zawierający tylko jego peryferia; STD się pod czymś takim nie kompiluje, bo brakuje mu nazw wszystkich pozostałych peryferiów).


W zaistniałej sytuacji postanowiłem zrobić nowy projekt przy pomocy Atollica, po czym zastąpić jego domyślne CMSIS wersją wprost z paczki STD. Następnie dopisałem odpowiednie include path dla wymaganych folderów i zedytowałem domyślne symbole w projekcie tak by pasowały do obecnej wersji bibliotek:
- wywaliłem symbol STM32F030X6 i zastąpiłem go STM32F030
- dodałem USE_STDPERIPH_DRIVER (domyślnie był odpowiednik dla HALa)
Plik startupu (.s) i linkera (.ld) zostawiłem nieruszone, ponieważ tak jak wcześniej testowałem działały bez zarzutu, w przeciwieństwie do odpowiedników z paczki STD.
Natomiast pozostałe pliki zostały już wzięte z paczki, trochę je tylko zedytowałem żeby dało się tego jako-tako używać.
Opcjonalnie, plik system_stm32f0xx.c można zastąpić - STM udostępnia plik Excela w którym można w łatwy sposób wygenerować odpowiednią konfigurację zegarów.

Ponieważ tak jak wspomniałem żadne z "gotowych" rozwiązań nie pozwoliło od razu używać procka z STD, załączam tutaj projekt który udało mi się wymodzić. Można go załadować poprzez file -> import -> existing projects into workspace. Projekt zawiera poprawne pliki startupu i linkera (wprost z Atollica), działające ze sobą CMSIS i STD z paczki ze strony STM, plik system_stm32f0xx.c wygenerowany w Excelu do pracy na HSI z częstotliwością 8MHz, a także dodane include paths i symbole.
Projekt przygotowany jest dla wersji F030F4P6, jednak powinno się go móc bez problemu dostosować do dowolnej wersji F030 - należy utworzyć w Atollicu nowy projekt dla danej wersji, skopiować z niego pliki .s i .ld, a następnie zmienić symbol STM32F030 na odpowiedni (wylistowane w pliku stm32f0xx.h)

Może załączona paczka oszczędzi komuś dni męczenia się .

_________________
Więcej dziwactw na: www.youtube.com/user/mopsiok

Wiesz .. ja nie mam z tym problemu łącznie z przenoszeniem , może dlatego że używam TrueStudio PRO nie Lite , może dlatego że manipuluję zmienną
patch w systemie ... ale niogdy nie miałem kłopotu ze ścieżkami do swoich makr i includ bibliotek ....

rozwiązanie twoje jest ok , ale jedno małe ale ...
po co się cofać do std_pherips ?? to już zabytek niewspierany zresztą, obecnie zastąpiły std_p znacznie lepsze i nowsze HAL ,
zmiany w kodzie są kosmetyczne -- a używanie std to trochę tak jakbyś .... nie ważne ...

_________________
Zbuduj swój system [url=https://helion.pl/ksiazki/w-labiryncie-iot-budowanie-urzadzen-z-wykorzystaniem-ukladow-esp8266-i-esp32-andrzej-gromczynski,wlablo.htm#format/d]IOT[/url]

Kwestia przyzwyczajenia i czasu . Mam gotowy kod pod STD i wolę go użyć zamiast przepisywać wszystko na HALa. Niemniej docelowo mam w planach nauczyć się HALa chociażby żeby zrobić porównanie. Zdecydowanie na plus jest też generowanie kodu w Cubie, do tej pory używam go tylko do projektowania pinoutu i generowania define'ów.

_________________
Więcej dziwactw na: www.youtube.com/user/mopsiok