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

STM32F410RB lista rozkazów

kogiel 12 Sty 2019 17:23 2967 121
  • Pomocny post
    #61
    tmf
    Moderator Mikrokontrolery Projektowanie
    kogiel napisał:
    Cytat:
    ... efekt faktu, że ktoś gdzieśtam zdefiniował, że PORT jest wskaźnikiem na adres, który reprezentuje określony zasób MCU, a cośtam, to wartość, która wpisana pod ten adres akurat powoduje, że jakieś tam piny stają się wyjściami...

    I właśnie tego nie rozumiem, dlaczego ktoś gdzieś tam zdefiniował to inaczej, przecież mógł tak samo zrobić dla obu procesorów


    Nie mógł, skoro w obu procesorach ta sama funkcja jest realizowana w inny sposób i wynika z projektu procesora. Ponieważ błąd popełniono gdzieś na etapie projektu sprzętu, to trudno go ukryć programowo. Zakładając, że dana funkcja wymaga w obu przypadkach ustawienia jednego bitu, ale jest on na różnych pozycjach w różnych rejestrach, to pojawia się problem. Można w C w obu przypadkach użyć tej samej definicji tego bitu, ale rodzi to więcej problemów niż korzyści. Bo program pozornie skompiluje się poprawnie, ale już jego działanie poprawne nie będzie.
    Wyobraź sobie taki oto przykład:
    Procesor A: rejstr RRR1 zawiera dwa bity konfiguracyjne - jeden włącza prysznic (nazwijmy go B1) i drugi, powodujący, że jesteś szczęśliwy (nazwijmy go HAPPY1).
    Procesor B: mądry inzynier bit B1 umieścił w rejestrze RRR1, a bit HAPPY1 w rejestrze WELLNESS.
    Załóżny, że masz program, który ustawia oba bity i działa on dla procesora A:
    RRR1 = B1 | HAPPY1;
    Teraz ten program kompilujesz na procesor B i co? I robi się kiszka, bo na tym procesorze ten sam efekt wymaga dwóch instrukcji:
    RRR1 = B1;
    WELLNESS = HAPPY1;
    Niestety, program z procka A się świetnie kompiluje na procku B, tyle, że nie działa. Co więc robi softwarowiec? Ano zmienia definicję bitów i na procku B i zmienia nazwę bitu HAPPY1 na WELL_HAPPY1. W efekcie program się nie kompiluje poprawnie, ale za to programista widzi co ma naprawić. Ale mu się to nie podoba. Więc firma robi tak - niech ci programiści nam po tych rejestrach nie grzebią, damy im za to HAL. I tworzą funkcję np. SetWellnessAndShower(), która ustawia oba bity, ale na każdym z procesorów ma inną definicję.
  • Computer ControlsComputer Controls
  • #62
    LChucki
    Poziom 31  
    Marek_Skalski napisał:
    Największy problem jaki tutaj widzę, to przyzwyczajenie Autora do AVR, gdzie port I/O jest tak banalnie prosty, że nie ma czego wybierać. W tej sytuacji zderzenie z konfiguracją portu I/O w Xmega również będzie problemem

    Zgadzam się w całej rozciągłości. Peryferiom Xmega bliżej do peryferii ARM niż AVR. AVR ma peryferia dość proste, można je porównać do 6820/21/22, 6522/26, Intel8253/4 a może raczej Z-80 CTC, SIO, PIO bo miały wektoryzowany układ przerwań i stosunkowo skomplikowaną budowę.

    Rozpoczynający swoją przygodę z ARM zniechęca skomplikowane ustawienie rejestrów konfiguracyjnych zegara. Trzeba pamiętać, że można nic nie konfigurować.. Wtedy, zależnie od uC, wszystko poza ADC jest taktowane 8 lub 16MHz. Do migania diodą nie trzeba zegara 168 czy 240MHz. UART, SPI też nie musi działać na max zwłaszcza, jak jest się przyzwyczajonym do powolnych AVR.

    Marek Skalski: Usunąłem uwagi nie związane z tematem.
  • Computer ControlsComputer Controls
  • #63
    tmf
    Moderator Mikrokontrolery Projektowanie
    Marek_Skalski napisał:
    Teraz kwestia sprzętowa. Porównanie dotyczy F1 oraz F4, a to dość różne epoki. STM32F103, to jeden z pierwszych uC ze rdzeniem ARM Cortex-M3, jakie zostały opracowane i wprowadzone na rynek przez STMicroelectronics. To było w 2007 roku i możliwości technologiczne, dostępne w latach 2004-2005 określiły wiele parametrów. Kiedy rozpoczęto implementację rdzenia Cortex-M4 (~2010-2014 dla rodziny F4), były już trochę inne warunki oraz inne wymagania techniczne/technologiczne dla rdzenia. To wymusiło odejście od AFIO na rzecz GPIO, które do dzisiaj są stosowane w takiej postaci. Pod względem programowym zmieniło się niewiele. To jest raczej kwestia nazewnictwa rejestrów oraz bitów, które zostały uporządkowane i ujednolicone w relacji do pozostałych układów peryferyjnych. Proponuję porównać F410 z L415 lub F765 czy H753. Wszystkie mają taką samą organizację GPIO.


    Może nie wyraziłem się wystarczająco jasno, ale miałem na myśli wyłącznie sprzęt, czyli fragment twojej wypowiedzi, który powyżej zacytowałem.
    Oczywiście masz rację, ale IMHO jeśłi przejrzysz opisy rejestrów procesorów tego samego producenta to są między nimi różnice, których nie da się wytłumaczyć inaczej jak robionym ad hoc projektem. Może się ze mną nie zgodzisz, ale nawet 40 lat temu porty IO działały tak jak obecnie w podstawowym zakresie. Oczywiście obecnie mamy wiele różnych opcji dodatkowych, ale nie kłócą się one z podstawową funkcjonalnością. To, że jest tak namieszane to w całości wina inżynierów (może producenta). Zresztą na podanym przez ciebie przykładzie AVR to doskonale widać - pierwsze konstrukcjje miały bity porozkładane zupełnie chaotycznie, w Megach ten chaos się utrzymywał, bo firma się szybko rozwijała i zapewne ważniejszy był time-to-market niż kombinowanie jak to sensownie zrobić. W nowszych AVR już tak nie jest i jakoś dało się zrobić chyba z 10 rodzin XMEGA, dla których programy są praktycznie w 100% przenoszalne, a nawet kompatybilne wstecznie z Mega, gdyż dodatkowe funkcje portów umieszczono w innych rejestrach, sensownie pogrupowano itd. Mam wrażenie, że na choroby wieku dziecięcego obecnie cierpią ARMy, bo rozwijają się tak szybko, że po prostu nie ma czasu na uporządkowanie tego bałaganu i przemyślenie jak to sensownie zorganizować. Bo przecież pomiędzy wymienionymi przez ciepbie procesorami nie ma żadnych fundamentalnych różnic, które przekładałyby się na olbrzymie różnice w deklaracjach bitów i rejestrów.
  • #64
    AndrzejKor
    Poziom 12  
    Ponowne dziędobry.

    Nie, żebym się kłócić chciał zara z kolegą FCh ale ...
    Zajrzałem do RM0091(DocID018940 Rev9) (STM32F0x1/....) na stronę 163
    oraz
    do RM0316 (DocID022558 Rev 8) ( STM32F303xB/C/D/E, ...) na stronę 242 i ...
    GPIO register map jest bardzo podobna, no identyczna nie jest, ale bardzo podobna.
    Nie widzę przeszkód (możem ślepy), aby nazwy bitów były identyczne w plikach ?????????.h,
    ale nie są. Oczywiście niektóre peryferiały mają więcej rejestrów ale i tam są identyczne rejestry
    i różne nazwy bitów.

    Z ukłonami
    Andrzej Korycki
  • #65
    Freddie Chopin
    Specjalista - Mikrokontrolery
    AndrzejKor napisał:
    Nie widzę przeszkód (możem ślepy), aby nazwy bitów były identyczne w plikach ?????????.h,
    ale nie są.

    Które nie są?

    AndrzejKor napisał:
    Nie, żebym się kłócić chciał zara z kolegą FCh ale ...
    Zajrzałem do RM0091(DocID018940 Rev9) (STM32F0x1/....) na stronę 163
    oraz
    do RM0316 (DocID022558 Rev 8) ( STM32F303xB/C/D/E, ...) na stronę 242 i ...

    Zauważ tylko, że w wątku jest mowa o przejściu z F1 na F4, a właśnie w F1 są inne GPIO niż w każdym innym STM32.
  • #66
    LChucki
    Poziom 31  
    AndrzejKor napisał:
    O register map jest bardzo podobna, no identyczna nie jest, ale bardzo podobna.
    Nie widzę przeszkód (możem ślepy), aby nazwy bitów były identyczne w plikach ?????????.h,

    Ja też nie widzę przeszkód, tylko dlaczego pytasz na forum a nie autora plików *.h?
  • #67
    Freddie Chopin
    Specjalista - Mikrokontrolery
    Tak BTW to ST ma to mniej-więcej gdzieś (żeby nie napisać gdzie dokładnie), bo sam nawet podniosłem kiedyś taką kwestię na ich forum.

    https://community.st.com/s/question/0D50X0000...msis-headers-to-be-consistent-across-families

    Jak widać dokładnie zero odpowiedzi, a w plikach od tego czasu nic się nie zmieniło <:

    Pisałem to wielokrotnie, że "A" w nazwie HAL na pewno znaczy coś innego niż "abstraction" (choć jeszcze nie wymyśliłem co dokładnie), a cały ten HAL (i SPL oraz każdy inny kod od ST) to jest jeden wielki "vendor lock-in", żeby jak najtrudniej było potem zmienić układ na coś od konkurencji. ST nie ma ŻADNEGO interesu, aby ich kod był abstrakcyjny czy uniwersalny, a co za tym idzie faktycznie łatwo przenośny - wręcz ma interes aby było ODWROTNIE.
  • #68
    kogiel
    Poziom 16  
    Pobrałem ten program na ARM z http://www.freddiechopin.info/pl/download/category/6-przyklady
    Troszkę go próbowałem przeanalizować, jak już wiedziałem mniej więcej co jest co, postanowiłem go skompilować, ale Eclipse pokazuje mi takie coś:
    STM32F410RB lista rozkazów

    Jak widać na załączonym obrazku ten plik istnieje, wie ktoś może gdzie leży problem?
  • #69
    Użytkownik usunął konto
    Poziom 1  
  • #70
    Freddie Chopin
    Specjalista - Mikrokontrolery
    Paczka zawiera kompletny projekt. Zaimportuj go przy pomocy opcji "import > existing projects into workspace" (czy jakoś tak), a nie twórz nowy projekt rozwalając wszystkie jego ustawienia. Projekt oparty jest o Makefile.
  • #71
    kogiel
    Poziom 16  
    Po zaimportowaniu niby wszystko ok, ale nadal wyświetla się mały czerwony krzyżyk
    STM32F410RB lista rozkazów

    a w Problems taki oto tekst:
    Cannot run program "sh" (in directory "C:\STM32\kurs\BLINK"): CreateProcess error=2, Nie można odnaleźć określonego pliku
  • Pomocny post
    #72
    Freddie Chopin
    Specjalista - Mikrokontrolery
    http://distortos.org/documentation/arm-toolchain-windows/

    Rozdział "MSYS2 and make" oraz "Add tools to PATH environment variable". Po tych krokach profilaktycznie proponuję reset systemu albo przynajmniej samego Eclipse'a.
  • #73
    kogiel
    Poziom 16  
    Tak jak radziłeś zainstalowałem tego pacmana, dodałem zmienne środowiskowe i teraz mam

    Error 127 occurred while running autoreconf BLINK -1 Configure Problem
  • #74
    Freddie Chopin
    Specjalista - Mikrokontrolery
    Hmm... No to chyba jakoś niebardzo zaimportowałeś ten projekt, skoro próbuje Ci zrobić na nim "autoreconf"... Na pewno zrobiłeś File > Import > General > Existing Project into Workspace?

    STM32F410RB lista rozkazów
  • Pomocny post
    #75
    Użytkownik usunął konto
    Poziom 1  
  • #76
    kogiel
    Poziom 16  
    Ja importowałem to przez C/C++/Existing Code as Makefile Projekt
    Zmyliło mnie
    Cytat:
    Projekt oparty jest o Makefile.


    Teraz już niema błędów, ale nie wiem jak to wrzucić do procka,
    bo jak robię nowy projekt to ustawiam:
    STM32F410RB lista rozkazów
    i potem tylko klikam Run,
  • #77
    Freddie Chopin
    Specjalista - Mikrokontrolery
    kogiel napisał:
    Teraz już niema błędów, ale nie wiem jak to wrzucić do procka

    Nie używam Atollica czy tego co masz zainstalowane, więc tu Ci nie odpowiem. Ja sobie prywatnie wrzucam przy okazji debuggowania albo przez OpenOCD, co chyba jest opisane w tym starym artykule o toolchainie.
  • #78
    Janusz_kk
    Poziom 26  
    kogiel napisał:
    Teraz już niema błędów, ale nie wiem jak to wrzucić do procka,
    bo jak robię nowy projekt to ustawiam:

    Złą drogę obrałeś, zostaw te arm-y na razie w spokoju wróć do avr-ów które ponoć znacz, zainstaluj
    atmel studio 7 i spróbuj na tym się nauczyć C, tam masz wszystko, ide, kompilator i programowanie
    a potem bierz się za większe procki, bo jak czytam twoje posty to Cię to przerasta.
  • #79
    LChucki
    Poziom 31  
    Ja bym zaproponował ARM ale narzędzia KEIL-a. Na początek, ograniczenie 32kB nie będzie problemem a KEIL jest wygodny. Generuje projekt z CubeMX, otwiera się KEIL, F7 i kod jest skompilowany. Żadnego wskazywania ścieżek, podłączania debugerów itp.
  • #80
    simw
    Poziom 23  
    LChucki napisał:
    Ja bym zaproponował ARM ale narzędzia KEIL-a. Na początek, ograniczenie 32kB nie będzie problemem a KEIL jest wygodny. Generuje projekt z CubeMX, otwiera się KEIL, F7 i kod jest skompilowany. Żadnego wskazywania ścieżek, podłączania debugerów itp.

    Ślepa ulica dla hobbysty, zupełnie ślepa.
    Są obecnie dwa dojrzałe środowiska, które pozwolą na wygodne podejście do tematu.
    Oba po instalacji są gotowe do pracy po 5 minutach, nawet zainstalują sterowniki i narzędzia do programatora-debuggera, a po zainstalowaniu CubeMx pozwalają na szybkie przejście do sedna, czyli pisania kodu, z aktualnymi bibliotekami CMSIS. Do tego poradnik Szczywronka, RM i nic więcej na początek nie potrzeba.

    A taki Keil, po kilku projektach zabraknie tych 32KB i co wtedy?
    Taki użytkownik, jeszcze początkujący, nabierze "złych nawyków" a potem będzie musiał wszystkiego na nowo się uczyć, bo przecież za kilkanaście tys. zł nie kupi nowego środowiska, żeby tylko wrzucić kilka większych tablic.

    Jest obecnie kilka wątków na elektrodzie, jak niniejszy, które wg mnie są zupełnie źle prowadzone, wprowadzają niepotrzebne zamieszanie dla amatorów, są wręcz szkodliwe, bo zamiast zachęcać do programowania to oferują protezy w postaci środowisk DIY, drogich środowisk jak Keil, to zupełnie zła droga dla początkującego.

    Uważam tak z perspektywy amatora programowania, z rocznym stażem w STM32, który nie musi pytać, żeby opanować proste podstawy jakiegoś tematu. Nie pytam o podstawy, bo jestem tam jakimś "geniuszem", tylko prozaicznie, te podstawy są zawarte w wymienionych przez mnie narzędziach i materiałach.
    Te zdania kieruję oczywiście do innych początkujących, żeby się zastanowili zanim zabrną w złą ulicę.

    Część zaawansowanych użytkowników to widać, że już dawno zatraciła dystans, a porady dla początkujących to są chyba dobre tylko dla radzących.

    Jak już niejednokrotnie pisano, żeby zrobić kompilujący się szkielet projektu wystarczy zrobić to w kilku krokach
    1. Zainstaluj Atollic
    2. Stwórz nowy projekt
    3. C project->Embedded project C (konieczna nazwa projektu)
    4. Wybierz model procesora MCUs - uwaga na podobne nazwy w rodzinie procesora
    5. Kliknij dalej,
    6. Wybierz programator-debugger z listy,
    7. Kliknij FINISH.
    8. Kliknij "Build" na pasku, po kilku sekundach masz skompilowany szablon, z domyślnym zegarem - można go podejrzeć w CubeMx, albo w RM.
    Dalej już baw się programowaniem, nie trać czasu na niepotrzebne działania.

    Do każdego projektu zaglądnij do jego właściwości, do zakładek:
    C/C++ Build oraz C/C+ General, szczególnie ważne są zakładki:
    Settings->Tool Settings,
    Path and Symbols.
    Przeglądnij, doczytaj o ścieżkach, symbolach, opcjach kompilatora czy linkera, poeksperymentuj na projektach. Pamiętaj, że na początku nie musisz tego robić - to tak rada na zaś.

    Attolic ma tę zaletę dla początkującego, odkryłem to nie dawno, że również ma w sobie kompilator PC c, tak że można w Atollic'u, programować w powłoce Windows czy Linux - często pada tutaj porada, żeby tak zaczynać programować, warto na pewno wspomagać się tym "fiuczerem" i bez konieczności instalacji dodatkowych narzędzi np. rozwiązywać zadania z C, z jakiejś dobrej książki czy kursu.
  • #81
    Freddie Chopin
    Specjalista - Mikrokontrolery
    simw napisał:
    protezy w postaci środowisk DIY

    Nie no... Jestem w stanie zrozumieć, że "środowisko DIY" nie jest może najlepsze dla początkującego, ale że "awansowało" już do kategorii "protezy" to jakaś nowość. Protezą to jest Atollic i SW4STM32, bo ciekawe co zrobisz jak dostaniesz za zadanie napisać kod na jakiś układ od NXP, Freescale (obecnie NXP), Atmela (obecnie Microchip), Nordic, DowolnyProducentRobiącyCortexy. Jak nie wiesz co, to sparafrazuję dla Ciebie Twój własny post:

    Cytat:
    A taki Atollic, po kilku projektach w STM32 nie wyczaruje nic na LPC1xxx i co wtedy?
    Taki użytkownik, jeszcze początkujący, nabierze "złych nawyków" a potem będzie musiał wszystkiego na nowo się uczyć, bo przecież za kilkanaście tys. zł nie kupi nowego środowiska, żeby tylko wrzucić kilka projektów na innym układzie niż STM32.


    ST jest może i największym obecnie producentem mikrokontrolerów z rdzeniem Cortex-M, ich układy zapewne są obecnie najpopularniejsze, ale trzeba pamiętać że po pierwsze nie jest, nigdy nie był i nigdy nie będzie jedyny, a po drugie historia już pokazała kilkukrotnie że takie środowiska jak Atollic potrafią zniknąć równie szybko jak się pojawiły, a po trzecie nie wiadomo co będzie popularne za kilka lat i nikt nie zagwarantuje, że będą to STM32.

    Jako że jesteś "amatorem programowania, z rocznym stażem w STM32", to zapewne nie pamiętasz, że Atollic ma trochę dłuższą historię niż ta obecna. Kiedyś była to zupełnie niezależna firma, która produkowała IDE dla wielu różnych Cortexów, z tym że było to IDE _KOMERCYJNE_. Potem pojawiły się darmowe paczki, ale tylko dla STM32 (z ograniczeniem rozmiaru? już nie pamiętam - może ograniczenie rozmiaru dotyczyło wszystkich wersji demo, ale w STM32 było zniesione?). A potem darmowe wersje znikły i nie było ich przez kilka lat (jedynie wersja w pełni komercyjna). Dopiero ostatnimi czasy ST kupiło tą firmę i jest teraz IDE dla STM32. Dla Ciebie korzyść. Wszyscy którzy kupili sobie to IDE w wersji komercyjnej dla (na przykład) LPC1xxx z pewnością nie są już tak szczęśliwi. Za rok czy dwa ST może kupi inną firmę i Atollic podzieli los SW4STM32 i CooCoxa, który też miał być lekiem na całe zło tego okrutnego świata DIY.

    Żeby nie było że zmyślam -> https://atollic.com/truestudio/target-support/nxp-formerly-freescale/

    simw napisał:
    Attolic ma tę zaletę dla początkującego, odkryłem to nie dawno, że również ma w sobie kompilator PC c, tak że można w Atollic'u, programować w powłoce Windows czy Linux - często pada tutaj porada, żeby tak zaczynać programować, warto na pewno wspomagać się tym "fiuczerem" i bez konieczności instalacji dodatkowych narzędzi np. rozwiązywać zadania z C, z jakiejś dobrej książki czy kursu.

    Nie no błagam. Przecież IDE dla C działających pod destkopa jest na pęczki, a pierwszym z brzegu jest... czyste Eclipse! Tak się składa, że czyste Eclipse perfekcyjnie dobrze działa jako IDE dla desktopa i nie trzeba wtedy w ogóle grzebać w jakichkolwiek ustawieniach ani dodawać do niego jakiejkolwiek wtyczki (; Jak musi być zintegrowane z kompilatorem i koniecznie na Windowsa to Qt Creator (oczywiście można robić projekty konsolowe), Visual Studio od Microsoftu (być może w wersji Express czy jakoś tak, zależy jak sobie to teraz nazwali) czy naprawdę cokolwiek innego.

    Dodano po 7 [minuty]:

    simw napisał:
    Do tego poradnik Szczywronka

    Może mnie coś ominęło, ale czy ten poradnik nie dotyczy właśnie środowiska DIY? (;
  • #82
    Użytkownik usunął konto
    Poziom 1  
  • #83
    BlueDraco
    Specjalista - Mikrokontrolery
    Z rzekomymi ograniczeniami Keila też bym nie przesadzał - ograniczenie 32 KiB jest na rozmiar binarnego obrazu Flash, czyli bez wliczania w to danych niezainicjowanych i inicjowanych na 0. Mam kilka projektów pod Keilem, które mają zadeklarowane dane po ponad 300 KiB i mieszczą się w wersji darmowej Keila.

    Podpisuję się pod zdaniem przedpiszcy - na początek zdecydowanie polecam Keila, i to bynajmniej nie żeby Freddiemu na złość zrobić, a po to, żeby łatwo i bezproblemowo zacząć zabawę z Cortexami.
  • #84
    Freddie Chopin
    Specjalista - Mikrokontrolery
    stmx napisał:
    Tak, że Ty patrzysz na problem z punktu widzenia osoby, dla której żaden z tych punktów nie jest problemem, a jak coś nie będzie Ci działać to sobie w parę minut poradzisz. Ci, którzy zadają te podstawie pytania tego nie wiedzą i sobie nie poradzą.

    IMO dla początkujących DIY jest praktycznie nie do przejścia - co zresztą widać po postach. W tym wątku nawet import gotowego projektu do gotowego środowiska stwarza problemy, a Ty chciałbyś żeby jeszcze sobie to środowisko stworzyć z elementów składowych i skonfigurować.

    Ale ja się z tym właśnie z grubsza zgadzam (choć dałbym większy kredyt zaufania ludziom - trochę zależy też od tego jakie kto ma ogólne obycie z komputerem i softem, nawet jak w mikrokontrolerach jest początkujący, bo jak wszędzie i tu rozwiązania 99,666% problemów można wyguglować albo RTFM), ale że od razu "proteza"?
  • #85
    Użytkownik usunął konto
    Poziom 1  
  • #86
    simw
    Poziom 23  
    Freddie Chopin napisał:
    simw napisał:
    protezy w postaci środowisk DIY

    Nie no... Jestem w stanie zrozumieć, że "środowisko DIY" nie jest może najlepsze dla początkującego, ale że "awansowało" już do kategorii "protezy" to jakaś nowość.


    "Proteza" to właściwie tylko figura retoryczna i to w kontekście początkującego, ale jak widać po wątku, autor po niej tylko "kuleje". Zagrzebał, a na końcu nic nie wyszło, po tym jak się narobił, zatem sam nawet potwierdziłeś, że to słaby pomysł, należałoby więc nie polecać tego rozwiązania początkującym i tyle - przyczyna - skutek.


    Freddie Chopin napisał:
    A taki Atollic, po kilku projektach w STM32 nie wyczaruje nic na LPC1xxx i co wtedy?

    A taki amator to po ilu dniach, miesiącach obcowania z STM32 będzie już musiał przestawiać się na LPC?
    Przyznam, że po roku sam doznałem takiej pokusy, ale tylko z powodu 80MSPS w jednym z LPC i być może w takim przypadku dobrze byłoby mieć już coś gotowego do innej platformy, ale to tylko wyjątek potwierdzający regułę.

    Freddie Chopin napisał:

    Jako że jesteś "amatorem programowania, z rocznym stażem w STM32", to zapewne nie pamiętasz, że Atollic ma trochę dłuższą historię niż ta obecna.

    A to akurat pamiętam, bo historii trochę liznąłem. Nie trzeba być specjalistą, żeby takich szczegółów się dowiedzieć. Nie ma potrzeby też wytykać "ułomności" - dla mnie wystarczą argumenty - z tym na razie słabo.

    Freddie Chopin napisał:

    Kiedyś była to zupełnie niezależna firma, która produkowała IDE dla wielu różnych Cortexów, z tym że było to IDE _KOMERCYJNE_. Potem pojawiły się darmowe paczki, ale tylko dla STM32 (z ograniczeniem rozmiaru? już nie pamiętam - może ograniczenie rozmiaru dotyczyło wszystkich wersji demo, ale w STM32 było zniesione?). A potem darmowe wersje znikły i nie było ich przez kilka lat (jedynie wersja w pełni komercyjna). Dopiero ostatnimi czasy ST kupiło tą firmę i jest teraz IDE dla STM32. Dla Ciebie korzyść. Wszyscy którzy kupili sobie to IDE w wersji komercyjnej dla (na przykład) LPC1xxx z pewnością nie są już tak szczęśliwi. Za rok czy dwa ST może kupi inną firmę i Atollic podzieli los SW4STM32 i CooCoxa, który też miał być lekiem na całe zło tego okrutnego świata DIY.

    Powyższe szczegóły mają się nijak do tu i teraz. Może za pół roku albo za rok to ten Początkujący już może stracić zainteresowanie - nie zasadne jest na tym etapie specjalnie wyrokować.
    Jeśli początkujący zrobi środowisko DIY to po reinstalacji systemu znowu będzie z ręką w nocniku, jeśli nie zrobi kopii bezpieczeństwa.
    Atollic jak padnie to przecież również nie wykasuje wszystkich instalacji z komputerów użytkowników. Ile lat ma wtyczka do Eclipse AVR? Jest nieaktualizowana od lat. Nadal można z powodzeniem "duże" rzeczy robić na starszych prockach, to że są nowe i trzeba iść do AS7 niczemu nie przeszkadza.
    To samo będzie być może z Atollic, ale przypomnij sobie - AC6 już tez dawno miało umrzeć co nie? Jakoś nie umiera, a wątki z elektrody o rychłej jego śmierci też dobrze pamiętam.

    Freddie Chopin napisał:

    simw napisał:
    Attolic ma tę zaletę dla początkującego, odkryłem to nie dawno, że również ma w sobie kompilator PC c, tak że można w Atollic'u, programować w powłoce Windows czy Linux - często pada tutaj porada, żeby tak zaczynać programować, warto na pewno wspomagać się tym "fiuczerem" i bez konieczności instalacji dodatkowych narzędzi np. rozwiązywać zadania z C, z jakiejś dobrej książki czy kursu.


    Nie no błagam. Przecież IDE dla C działających pod destkopa jest na pęczki, a pierwszym z brzegu jest... czyste Eclipse! Tak się składa, że czyste Eclipse perfekcyjnie dobrze działa jako IDE dla desktopa i nie trzeba wtedy w ogóle grzebać w jakichkolwiek ustawieniach ani dodawać do niego jakiejkolwiek wtyczki (; Jak musi być zintegrowane z kompilatorem i koniecznie na Windowsa to Qt Creator (oczywiście można robić projekty konsolowe), Visual Studio od Microsoftu (być może w wersji Express czy jakoś tak, zależy jak sobie to teraz nazwali) czy naprawdę cokolwiek innego.


    Ale czysty Eclipse nie instaluje kompilatora, musisz go samemu zainstalować, a jeszcze potem ścieżki podać.

    Chyba nie za bardzo zrozumiałeś co chciałem przekazać. Atolic ma już kompilator skonfigurowany, żeby "exeki" tworzyć, bez żadnej dodatkowej instancji kompilatora. Dajesz nowy projekt na PC i po chwili masz w konsoli uruchomiony wynik.
    Mój przekaz był taki, że "na goły system" dajesz tylko Atollica i już piszesz w "powłoce" albo na "procka".
    Wg Ciebie nie jest to zaleta?

    Freddie Chopin napisał:

    Może mnie coś ominęło, ale czy ten poradnik nie dotyczy właśnie środowiska DIY? (;

    Kulą w płot. Wystarczy przedmowę poradnika przeczytać tam jest napisane, że ten poradnik się środowiskiem nie zajmuje, to że z jakiegoś korzysta nie ma znaczenia. Zresztą kiedy był pisany...
  • #87
    Freddie Chopin
    Specjalista - Mikrokontrolery
    simw napisał:
    "Proteza" to właściwie tylko figura retoryczna i to w kontekście początkującego, ale jak widać po wątku, autor po niej tylko "kuleje". Zagrzebał, a na końcu nic nie wyszło, po tym jak się narobił, zatem sam nawet potwierdziłeś, że to słaby pomysł, należałoby więc nie polecać tego rozwiązania początkującym i tyle - przyczyna - skutek.

    Daleko idący wniosek... Autor porwał się z przysłowiową motyką na przysłowiowe słońce, wpadając na pomysł jednoczesnego poznania języka C, STM32 i bardziej skomplikowanego IDE w wersji DIY. Obawiam się, że przy użyciu Atollica dalej może to być ciężkie, bo wciąż są co najmniej dwa stopnie swobody (STM32 i C), a to wciąż więcej niż liczba którą można z powodzeniem ogarnąć podchodząc do czegoś nowego, która wynosi dokładnie jeden.

    Wracając do meritum problemu. Osobiście nauczyłem się programować w C i C++ na PC. Bynajmniej nie chodzi o jakieś superdogłębne poznanie języka czy w ogóle jakiegoś paradygmatu, tylko po prostu o to, żeby wiedzieć że program ma wyglądać tak czy siak, składać się z tego i owego, a wymagane do kompilacji i uruchomienia jest to i tamto. Absolutne podstawy. Moim zdaniem bez takich podstaw ani rusz z STM32, IDE nie ma tu nic do rzeczy.

    simw napisał:
    A taki amator to po ilu dniach, miesiącach obcowania z STM32 będzie już musiał przestawiać się na LPC?
    Przyznam, że po roku sam doznałem takiej pokusy, ale tylko z powodu 80MSPS w jednym z LPC i być może w takim przypadku dobrze byłoby mieć już coś gotowego do innej platformy, ale to tylko wyjątek potwierdzający regułę.

    Piszesz jakby STM32 było jedynym wyjściem w każdej sytuacji. Co to w ogóle za pytanie "po ilu dniach"? Po tylu, po ilu wymyli projekt który bardziej będzie pasował do czegoś innego niż STM32. Ot choćby niech będzie to coś z wbudowanym Bluetooth, do czego definitywnie bardziej pasuje nRF51 niż absolutnie dowolny STM32. Równie dobrze mógłbym odwrócić to pytanie i spytać po co w ogóle Ty używasz STM32 i ile dni/miesięcy potrzebowałeś żeby na nie przejść z czegokolwiek-używałeś-wcześniej? Skoro zmieniłeś na STM32, to czemu zakładasz, że to już finał i nie zmienisz nigdy?

    simw napisał:
    Jeśli początkujący zrobi środowisko DIY to po reinstalacji systemu znowu będzie z ręką w nocniku, jeśli nie zrobi kopii bezpieczeństwa.

    Jest dokładnie odwrotnie.

    Kopię zapasową projektów chyba każdy ma, bo jak nie ma, to znaczy że jest to osoba niepoważna i w ogóle nie ma o czym gadać. Importujesz projekty i gotowe. Co więcej - akurat środowisko DIY można sobie przenosić między komputerami do woli bez żadnej instalacji, jedyne co trzeba zrobić na nowym kompie to dodanie odpowiednich ścieżek do PATH. Tak w zasadzie to można nawet to zrobić w opcjach projektu Eclipse'a (albo przez Makefile - jak kto woli), więc i tego nie trzeba robić po takich przenosinach. Wręcz kopiuj-wklej.

    Poza tym z czego wynika ta cała niechęć do DIY i nazywanie tego "protezą"? Przecież to "środowisko DIY" to są 3 czy 4 paczki, które wystarczy sobie gdzieś rozpakować i wrzucić je do systemowego PATH. Czy to umiejętności godne jedynie najlepszych h4x0rów, a nie zwykłych śmiertelników? Jeśli ktoś nie jest tego w stanie ogarnąć, to i tak programisty z niego nie będzie, a jak widać w temacie obok te pół-komercyjne twory wcale nie są takie bezproblemowe i również można w nich trafić na problem trudny do przeskoczenia.

    Na koniec największa zaleta. Moje projekty na "protezę DIY" sprzed 10-ciu lat (teraz nawet już 11 i nie jest to żadna hiperbola) dziś rozpakowuję, importuję i wszystko działa. Pomimo tego, iż w międzyczasie pojawiło się z 10 nowych wersji wszystkich narzędzi których wtedy użyłem, a ja sam zmieniłem przyzwyczajenia z Windowsa na Linuxa (zresztą nawet jakbym nie zmienił, to tak czy siak było to 3 czy 4 wersje Windowsa temu). Czy jesteś pewien, że za 10 lat to samo będziesz mógł powiedzieć o projektach zrobionych na tych "nie-protezach"?

    simw napisał:
    Ale czysty Eclipse nie instaluje kompilatora, musisz go samemu zainstalować, a jeszcze potem ścieżki podać.

    Czy to naprawdę nie do przeskoczenia dla osoby która chce być programistą 32-bitowych mikrokontrolerów z rdzeniem ARM Cortex-M3? Sam muszę uderzyć w ton "teraz sam jestem dziadkiem" (choć generalnie mnie to irytuje zawsze) - jak byłem w liceum i stawiałem pierwsze kroki z programowaniem, to jakoś dałem radę, a było to wtedy z pewnością trudniejsze niż teraz, kiedy na stronie www.google.pl można w 10 sekund znaleźć odpowiedź na każde pytanie (żeby nie było, że jestem taki stary, to oczywiście nie jestem, ale jednak teraz jest to prostsze niż wtedy). Jak byłem w podstawówce to każde dziecko na osiedlu ogarniało "nortona" i "rara" żeby gry na dyskietkach przenosić. Mamy 2019 rok i instalacja programu pod Windowsem jest naprawdę jakimś problemem? Przecież z 90% osób tu piszących ma wyższe wykształcenie techniczne, a argumenty jakbyśmy mówili o hobby adresowanym do przysłowiowego "statystycznego Polaka".

    simw napisał:
    Wg Ciebie nie jest to zaleta?

    Niezbyt, bo jak ktoś nie jest w stanie zainstalować osobno IDE i kompilatora, to i tak nic nie będzie z jego programowania.

    Żeby było jasne - używaj czego chcesz, radź innym co tylko chcesz, mi nic do tego. Ale nie nazywaj czegoś czego nie znasz i nie używasz "protezą", tylko dlatego że sam wybrałeś inaczej. Inaczej to niekoniecznie znaczy lepiej. Nawet jeśli jest to "lepiej dla Ciebie", to już niekoniecznie "lepiej dla innych", a już z pewnością nie "lepiej dla wszystkich". Określenie "proteza" definitywnie jest pejoratywne i tylko o to mi chodzi.
  • #88
    Użytkownik usunął konto
    Poziom 1  
  • #89
    Freddie Chopin
    Specjalista - Mikrokontrolery
    stmx napisał:
    Zadam Ci proste pytanie: jak sądzisz ile osób czytających forum ARM na elektrodzie jest w stanie "z palca" napisać prosty makefile ("z palca" rozumiem bez przerabiania jakiegoś gotowca albo zrzynania z sieci)?

    Nie wiem, ale sam z pewnością się do nich nie zaliczam <: Ja zawsze robię kompilację tego co mam i tego co znajdę w necie <: Jak widać bez dogłębnej znajomości make da się go używać z powodzeniem. Choć spoko, teraz przerzucam się na CMake.

    stmx napisał:
    Ja twierdzę że może kilka procent. I taka mniej więcej liczba może robić DIY. Reszta sobie rady nie da.

    Może tak jest. Ale mi nie o to chodzi. Po prostu jest rozwiązanie A (Atollic), B (Keil), C (cośtam), D (DIY), itd. Jedni wolą A, inni B, jeszcze inni C, D ma swoją grupę wyznawców itd. Naprawdę kompletnie mnie nie interesuje czego używa simw, czego użyje autor wątku, ani to czy w grupie D jestem sam czy może jest "nas" więcej. Ale niech Ci z grupy A nie nazywają rozwiązania z grupy D "protezą".

    Tylko tyle i aż tyle.
  • #90
    simw
    Poziom 23  
    Freddie Chopin napisał:

    Może tak jest. Ale mi nie o to chodzi. Po prostu jest rozwiązanie A (Atollic), B (Keil), C (cośtam), D (DIY), itd. Jedni wolą A, inni B, jeszcze inni C, D ma swoją grupę wyznawców itd. Naprawdę kompletnie mnie nie interesuje czego używa simw, czego użyje autor wątku, ani to czy w grupie D jestem sam czy może jest "nas" więcej. Ale niech Ci z grupy A nie nazywają rozwiązania z grupy D "protezą".

    Tylko tyle i aż tyle.

    Żeby już nie pisać elaboratów, chciałbym tak po ludzku dowiedzieć się jakie to cechy ma to DIY, chodzi mi o te pozytywne głównie. Jedną negatywną znam - bardziej czasochłonna instalacja, która może powodować dodatkowe problemy początkującym.

    Poznałem też jedna pozytywną, jeśli dobrze zrozumiałem, to wielo-platformowość, dzięki czemu od startu mogę działać na np. LPC, tak? Jeśli coś pomyliłem poprawcie mnie.
    A inne zalety? Jest coś co wybija się szczególnie nad taki atollic (choć z innych wątków wiadomo, że używam zwykle AC6 - bo tak, atollic to tylko przykład i przeciwwaga dla DIY :)

    Przepraszam też za tę "protezę" ta tzw "figura retoryczna" była niepotrzebna, nawet w kontekście problemów początkującego - nie chciałem dyskredytować wysiłków w propagowaniu rozwiązania DIY.