Elektroda.pl
Elektroda.pl
X
Elektroda.pl
Computer 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 14 Sty 2019 22:25 2529 121
  • #91 14 Sty 2019 22:25
    Freddie Chopin
    Specjalista - Mikrokontrolery

    simw napisał:
    Ż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 :)

    Jeśli Cię to faktycznie ciekawi, to załóż po prostu nowy wątek. W tym wątku jest to nie na temat, a do tego jeśli ktokolwiek będzie takich informacji szukał w przyszłości, to z pewnością nie zajrzy w tej sprawie do wątku "STM32F410RB lista rozkazów". Jak Ci się nie chce zakładać nowego, to może być tu - https://www.elektroda.pl/rtvforum/topic1313509.html

  • Computer Controls
  • #93 15 Sty 2019 11:30
    kogiel
    Poziom 16  

    Widzę, że w czasie kiedy ja rozgryzam C, tutaj temat poszedł w trochę innym kierunku ;-)
    A ja mam kolejne pytanie, bo jeśli wpisuje w programie:

    Kod: c
    Zaloguj się, aby zobaczyć kod

    to program podczas debugowania przeskakuje do stm32f4xx_rcc.c i robi takie coś:
    Kod: c
    Zaloguj się, aby zobaczyć kod

    Wydedukowałem, że on tutaj sprawdza czy nie było DISABLE
    i jeśli nie to włącza zegar dla GPIO

    Ja żeby przyspieszyć działanie programu napisałem bespośrednio w programie:
    Kod: c
    Zaloguj się, aby zobaczyć kod

    bo stwierdziłem, że niema potrzeby, aby program skakał po jakichś IF'ach

    I tu moje pytanie, czy podczas kompilacji te wszystkie podprogramy są usuwane i zastępowane
    właściwą instukcją, czy też program sobie skacze od pliku do pliku ?

  • Computer Controls
  • #94 15 Sty 2019 11:59
    Freddie Chopin
    Specjalista - Mikrokontrolery

    kogiel napisał:
    I tu moje pytanie, czy podczas kompilacji te wszystkie podprogramy są usuwane i zastępowane
    właściwą instukcją [...]?

    Zasadniczo nie (pomijam tutaj istnienie LTO).

    kogiel napisał:
    czy też program sobie skacze od pliku do pliku ?

    Tak właśnie robi.

    kogiel napisał:
    Ja żeby przyspieszyć działanie programu napisałem bespośrednio w programie:

    Gwarantuję Ci, że zrobiłeś to błędnie. Jeśli działa, to tylko przypadkiem dlatego, że interesujący Cię bit jest w tym rejestrze pierwszy.

    W każdym razie widzę, że nie znając jeszcze ani języka, ani układu, przeszedłeś już do optymalizowania programu żeby działał szybciej. Nie tędy droga, naprawdę nigdzie w ten sposób nie dojdziesz...

  • #95 15 Sty 2019 12:11
    AndrzejKor
    Poziom 12  

    Dziędobry

    Nie ma pojęcia pliku w wykonywalnym programie. To znaczy, pliku w Twoim (w tej chwili) o pliku mniemaniu.
    Poczytaj chwilę K&R, to się o tym przekonasz. W trakcie wykonywania programu (załóżmy na chwilę, że program
    jest lub zostanie załadowany (przez system operacyjny) do pamięci w całości)) procesor wykonuje instrukcje umieszczone
    w pewnym obszarze pamięci przeznaczonej na program (to jest ten Twoj plik). Na etapie linkowania wszystkie Twoje
    różne pliki zostały (po translacji) połączone w jeden obiekt (plik) wykonywalny, którego wykonywanie rozpocznie się od
    pewnego adresu. Niech to będzie adres 0x1000. Rejestr odpowiedzialny za wykonywanie programu zostanie załadowany
    wartością 0x1000 i stamtąd procesor pobierze pierwszą instrukcję. Jeżeli to będzie instrukcja jednobajtowa, to po pobraniu
    i zinterpretowaniu jej, że to nie jest skok, zawartość rejestru zostanie powiększona o 1, gdy inna ilość bajtów, to o tę właśnie ilość.
    W 32 bitowych STMach będzie to zwykle 4. Jeżeli to będzie instrukcja skoku gdzieś, to adres tego gdziesia będzie załadowany
    do tego rejestru w celu pobrania następnej instrukcji. Tak to z grubsza wygląda, przy tłumaczeniu na palcach.
    Ale instrukcja RCC>AHB1ENR |= ENABLE najprawdopodobniej nie zadziała, bo ENABLE ma najprawdopodobniej wartość 1
    i to spowoduje ustawienie bitu 0 w rejestrze AHB1ENR zegara RCC. Do jakiego peryferiału podasz zegar to możesz wyczytać
    w RM Twojego procesora, a dokładniej na stronie 147 RM0008 Rev 16. I chyba nie o to chodziło.

    Z ukłonami
    Andrzej Korycki

    EDIT
    No i w trakcie pisania kol. FCh odpowiedział i nasze odpowiedzi są nieco sprzeczne, ja napisałem, że nie skacze z pliku do pliku
    a kol. FCh, że tak. Widać się różnimy, ale jak pięknie.

  • #96 15 Sty 2019 12:22
    stmx
    Poziom 25  

    kogiel napisał:
    bo stwierdziłem, że niema potrzeby, aby program skakał po jakichś IF'ach
    Zgadzam się nie ma żadnej potrzeby. Po co skakać?

    Twoja niechęć do nauki jest przerażająca.

    Potwierdza się to co napisałem wcześniej:
    stmx napisał:
    To się nigdy nie stanie bez książki w ręku. To co robisz to "arduinowanie" czyli pseudonauka pseudowiedzy. Po takiej nauce nie dość że nic nie będziesz rozumieć, to co gorsze będziesz rozumieć większość rzeczy opacznie.


    IMO temat do zamknięcia, staje się wręcz szkodliwy.

  • #97 15 Sty 2019 12:35
    Freddie Chopin
    Specjalista - Mikrokontrolery

    AndrzejKor napisał:
    FCh odpowiedział i nasze odpowiedzi są nieco sprzeczne, ja napisałem, że nie skacze z pliku do pliku
    a kol. FCh, że tak. Widać się różnimy, ale jak pięknie.

    Zależy na jakim poziomie je rozpatrywać. Moja odpowiedź była "tak, będzie skakał z funkcji do funkcji", Twoja odwołała się do tego jak realnie wygląda wykonywanie programu. Która z nich jest właściwa (bo obie są poprawne) to już zależy o co dokładnie pytał autor wątku.

  • #98 15 Sty 2019 21:42
    kogiel
    Poziom 16  

    Cytat:
    IMO temat do zamknięcia, staje się wręcz szkodliwy.

    Nie rozumiem, dlaczego staje się szkodliwy, przecież ja nikomu nic nie doradzam, a jedynie się pytam jako laik
    Cytat:

    Ale instrukcja RCC>AHB1ENR |= ENABLE najprawdopodobniej nie zadziała, bo ENABLE ma najprawdopodobniej wartość 1
    i to spowoduje ustawienie bitu 0 w rejestrze AHB1ENR zegara RCC.


    Rzeczywiście wszystko działało, bo akurat używałem potu A, więc przez przypadek ENABLE które się równało 1 załączyło właściwy port

    Czyli prawidłowo to będzie tak ?
    Kod: c
    Zaloguj się, aby zobaczyć kod



    Cytat:
    W każdym razie widzę, że nie znając jeszcze ani języka, ani układu, przeszedłeś już do optymalizowania programu żeby działał szybciej


    Uczę się od początku optymalizacji, bo jak kiedyś się bawiłem ESP8266 który ma zegar 160MHz i napisałem program w LUA, to okazało się, że był wolniejszy od Atmegi z zegarem 16MHz

  • #99 15 Sty 2019 21:49
    LChucki
    Poziom 29  

    kogiel napisał:
    Uczę się od początku optymalizacji, bo jak kiedyś się bawiłem ESP8266 który ma zegar 160MHz i napisałem program w LUA, to okazało się, że był wolniejszy od Atmegi z zegarem 16MHz

    Mieszasz pojęcie systemu (w ESP jest RTOS), który nie wiadomo co robi, ile czasu zajmuje, z uC nad którym całkowicie panujesz. Przy okazji co to był za program? Co działało wolno? Może nie używałeś sprzętu i wykorzystałeś programowe protezy SPI, I2C, UART? Może użyłeś bibliotek, które były nieoptymalne (choćby GPIO z Arduino)?

  • #100 15 Sty 2019 22:01
    kogiel
    Poziom 16  

    Cytat:
    Przy okazji co to był za program? Co działało wolno? Może nie używałeś sprzętu i wykorzystałeś programowe protezy SPI, I2C, UART? Może użyłeś bibliotek...


    Używałem modułów, bo jak wcześniej wspomniałem pisałem w LUA
    Program miał za zadanie jedynie odczytać ADC i porównać z zadaną wartością, a następnie tak ustawić PWM, aby napięcie na wyjściu było równe temu zadanemu (PWM było podłączone do ADC, oczywiście przez filtr)

    Cytat:
    Mieszasz pojęcie systemu (w ESP jest RTOS), który nie wiadomo co robi, ile czasu zajmuje, z uC nad którym całkowicie panujesz

    Dlatego właśnie staram się zapanować od początku nad C, bo jak on będzie mi coś robił o czym nie mam pojęcia, to też może się okazać, że program wykonuje się zbyt długo i nie będę wiedział dlaczego (tak jak Bascomowcy)

  • #101 15 Sty 2019 22:03
    Freddie Chopin
    Specjalista - Mikrokontrolery

    kogiel napisał:
    Czyli prawidłowo to będzie tak ?

    Prawidłowo jest tak:

    RCC->AHB1ENR |= RCC_AHB1ENR_GPIOCEN;

    Nie jest to przypadek, że poszczególne człony nazw odpowiadają sobie po obydwóch stronach.

    kogiel napisał:
    Uczę się od początku optymalizacji, bo jak kiedyś się bawiłem ESP8266 który ma zegar 160MHz i napisałem program w LUA, to okazało się, że był wolniejszy od Atmegi z zegarem 16MHz

    Zacznij od poznania języka. Potem od poznania algorytmów. Potem trzeba się zapoznać z różnymi architekturami. Takimi sztuczkami jak pominięcie wywołania funkcji i zastąpienie tego przypisaniem, choć wszystko dotyczy jednorazowej inicjalizacji po starcie, nic nie osiągniesz. Prawdziwa optymalizacja tkwi w architekturze systemu (np. system zdarzeniowy, RTOS, automaty stanów, ...), a nie w takich mikropoprawkach. Tym sposobem zyskasz może 5%, gdy na błędnym algorytmie stracisz np. 1000%.

    Generalnie samo programowanie jest proste, ale dobre programowanie to już inna sprawa.

  • #102 15 Sty 2019 22:04
    stmx
    Poziom 25  

    kogiel napisał:
    Uczę się od początku optymalizacji, bo jak kiedyś się bawiłem ESP8266 który ma zegar 160MHz i napisałem program w LUA, to okazało się, że był wolniejszy od Atmegi z zegarem 16MHz
    najpierw się naucz języka. To co piszesz to żadna optymalizacja.

    A program tak Ci chodził bo pewnie równie dobrze opanowałes sprzęt i lua co teraz C. To po prostu wynika z braku podstaw.

    LChucki napisał:
    (w ESP jest RTOS), który nie wiadomo co robi, ile czasu zajmuje, z uC nad którym całkowicie panujesz.
    Tu również proponuje nie pisać o czymś, o czym się nie ma pojęcia.

  • #103 15 Sty 2019 22:18
    LChucki
    Poziom 29  

    stmx napisał:
    Tu również proponuje nie pisać o czymś, o czym się nie ma pojęcia.

    FreeRTOS, uRTOS, nie ważne, coś nad czym się nie panuje.

  • #104 15 Sty 2019 22:28
    kogiel
    Poziom 16  

    Cytat:

    A program tak Ci chodził bo pewnie równie dobrze opanowałes sprzęt i lua co teraz C.


    ESP LUA jest tak samo prosty i wydajny jak BASCOM, więc niema tam czego opanować, tak jak napisał kolega LChucki
    Cytat:
    (w ESP jest RTOS),który nie wiadomo co robi


    Dodano po 7 [minuty]:

    Cytat:

    Prawidłowo jest tak:

    RCC->AHB1ENR |= RCC_AHB1ENR_GPIOC;

    Nie jest to przypadek, że poszczególne człony nazw odpowiadają sobie po obydwóch stronach.


    Nie wiem co jest przyczyną, ale u mnie to nie działa:-( , natomiast
    Kod: c
    Zaloguj się, aby zobaczyć kod

    działa, bo sprawdziłem co się zapisuje do rejestru AHB1ENR i przy zmianie portu są ustawiane odpowiednie bity

    I tu wracamy do początku dlaczego u jednych działa tak, a u innych inaczej ?
    Czy to zależy od tego co jest napisane w pliku stm32f4xx.h ?

  • Pomocny post
    #105 15 Sty 2019 22:39
    BlueDraco
    Specjalista - Mikrokontrolery

    Powinno być:

    RCC->AHB1ENR |= RCC_AHB1ENR_GPIOCEN;

    Nie mieszaj stałych pochodzących z różnych miejsc i różnych plików tylko z tego powodu, że mają nieco podobne nazwy. Mogą one oznaczać coś zupełnie odmiennego.

    A sekret wydajności Lua jest bardzo prosty - to interpretowany język skryptowy, co skutkuje tym, że proste dodawanie wymaga wykonania przez procesor setek albo raczej tysięcy instrukcji - takie operacje są w Lua setki razy wolniejsze niż w C. Za to w Lua możesz dodać liczbę do tekstu, a w C nie. ;)

  • #106 15 Sty 2019 22:49
    kogiel
    Poziom 16  

    To też działa prawidłowo ;-)

    BlueDraco napisał:

    RCC->AHB1ENR |= RCC_AHB1ENR_GPIOCEN;

    Tylko nadal nie wiem dlaczego u jednych działa tak, a u innych inaczej ?
    Cytat:

    A sekret wydajności Lua jest bardzo prosty - to interpretowany język skryptowy, co skutkuje tym, że proste dodawanie wymaga wykonania przez procesor setek albo raczej tysięcy instrukcji - takie operacje są w Lua setki razy wolniejsze niż w C. Za to w Lua możesz dodać liczbę do tekstu, a w C nie. ;)

    Zapomnij o tym ESP LUA, już dawno sobie dałem z nim spokój

  • #108 15 Sty 2019 22:57
    Freddie Chopin
    Specjalista - Mikrokontrolery

    BlueDraco napisał:
    Powinno być:

    RCC->AHB1ENR |= RCC_AHB1ENR_GPIOCEN;

    Ups (; Poprawiłem posta [;

  • #109 15 Sty 2019 23:05
    kogiel
    Poziom 16  

    Czyli mam rozumieć, że taki zapis:

    Kod: c
    Zaloguj się, aby zobaczyć kod

    będzie działał zawsze ?

    Natomiast ten którego ja użyłem
    Kod: c
    Zaloguj się, aby zobaczyć kod

    nie zawsze będzie działał?, czy ta różnica wynika z "zainkludowanych" plików?

    Sprawdziłem ten "mój" zapis i działa prawidłowo, dlaczego jest niepoprawny?

  • #111 15 Sty 2019 23:55
    kogiel
    Poziom 16  

    @stmx Jeśli będę przyjmował odpowiedzi "to tak jest" to będzie pseudo nauka, pseudo języka, a ja nie chciałbym bezmyślnie przepisywać przykładów, tylko zrozumieć dlaczego te zapisy są równoznaczne, lub nie.
    I nie przejmuj się, nie będę tak pytał do końca życia, wystarczy ,że zrozumiem na tym jednym przykładzie migania diodą

  • #112 15 Sty 2019 23:56
    Freddie Chopin
    Specjalista - Mikrokontrolery

    kogiel napisał:
    Sprawdziłem ten "mój" zapis i działa prawidłowo, dlaczego jest niepoprawny?

    Zapis przedstawiony przeze mnie i BlueDraco korzysta tylko i wyłącznie z nagłówków CMSIS. Definitywnie jest on "zawsze poprawny", choć zależy co rozumiesz przez "zawsze". Np. jak spróbujesz go skompilować dla STM32F1, to oczywiście nie zadziała.

    Zapis którego ty próbujesz użyć jest niby tożsamy, ale:
    1. makro RCC_AHB1Periph_GPIOC zostało stworzone jako argument dla funkcji z SPLa, to że ma akurat taką samą wartość jak RCC_AHB1ENR_GPIOCEN można spokojnie traktować jako "zbieg okoliczności", bo równie dobrze mogłoby mieć zupełnie inną, zależnie od tego co akurat pasowało gościom piszącym SPLa
    2. SPL jest martwy
    3. używasz w takim przypadku makr z jednego nagłówka z rejestrami z zupełnie innego nagłówka - to po prostu nie ma żadnego sensu, żadnych zalet i żadnych korzyści, za to kilka wad

  • #113 16 Sty 2019 00:09
    kogiel
    Poziom 16  

    Cytat:
    Definitywnie jest on "zawsze poprawny", choć zależy co rozumiesz przez "zawsze". Np. jak spróbujesz go skompilować dla STM32F1, to oczywiście nie zadziała.


    @Freddie Chopin dzięki za konkretna odpowiedz, to ,że nie zadziała dla STM32F1, to już wiem z poprzednich postów, dlatego na razie skupiłem się wyłącznie na rejestrach dla STM32F410RB i obserwuje jego zachowanie
    I o ile wiem skąd się biorą nazwy rejestrów, to nadal nie wiem skąd się bierze np. GPIOAEN
    Przecież to nie jest jakiś ogólny zapis w C
    Wiem też, że równie dobrze mógłbym napisać RCC->AHB1ENR |= 2; (dla portu B) , ale skąd się wzięło GPIOAEN to nie mam pojęcia

    Moderowany przez Marek_Skalski:

    Lenistwo i obniżanie poziomu. Proszę, aby Kolega się skupił na lekturze. To wszystko jest opisane w dokumentacji układu. Ostatnie ostrzeżenie z mojej strony.
    3.1.17. Nie wysyłaj pytań bardzo podstawowych, na które odpowiedzi można znaleźć w instrukcji obsługi lub ogólnie dostępnych źródłach. Nie prezentuj postawy, że mi się należy. Dbaj o poziom pytań i dyskusji. Dziękujemy.

  • Pomocny post
    #114 16 Sty 2019 00:14
    LChucki
    Poziom 29  

    kogiel napisał:
    I o ile wiem skąd się biorą nazwy rejestrów, to nadal nie wiem skąd się bierze np. GPIOAEN

    Z tego samego miejsca, plików nagłówkowych.

    Ten wątek przypomina mi inny, gdzie też pytający nie znał i nie chciał poznać podstaw. Zadawał coraz więcej niedorzecznych pytań zamiast zapoznać się ze zrozumieniem z podstawami, np. słynnym poradnikiem Sczywronka.

  • #115 16 Sty 2019 00:32
    kogiel
    Poziom 16  

    @LChucki ja akurat nazwy rejestrów brałem z Reference manual (bo tak mi radzili koledzy wcześniej),
    O plikach nagłówkowych nikt nie wspominał
    Teraz już widzę, że w stm32f4xx.h jest wszystko :-)

    Niestety o poradniku Sczywronka ani ja, ani wujek Google nic nie wie :-(

  • #117 16 Sty 2019 00:40
    kogiel
    Poziom 16  

    stmx napisał:
    @kogiel A iesz co naczy RCC->AHB1ENR? Co to za tajemnicze "->"

    To akurat wiem, bo na samym początku zaznajomiłem się z tymi (dla mnie na początku ) dziwnymi znaczkami ;-)
    Z innych języków znałem np. OR AND, NOT, (||,&&,!) , ale ten mnie zaciekawił i jeszcze kilka innych
    Najbardziej mnie zdziwiło, że w C jest coś takiego jak LSR i LSL, po "waszemu" to >> i << ;-)

  • #119 16 Sty 2019 01:16
    kogiel
    Poziom 16  

    No więc zgodnie z definicją "operator wyboru składnika AHB1ENR przez wskaźnik do zmiennej RCC" (wybiera składnik ze struktury gdy używamy wskaźnika do struktury zamiast zwykłej zmiennej)
    A po mojemu, to mamy sobie jakieś #define RCC_AHB1ENR_GPIOAEN ((uint32_t)0x00000001) i wpisując RCC->AHB1ENR |= RCC_AHB1ENR_GPIOAEN;
    "nadpisujemy" bity w rejestrze, ale nie zmieniamy tych które były wcześniej ustawione lub wyzerowane( w tym przypadku ustawiamy bit 0)

  • #120 16 Sty 2019 01:19
    tplewa
    Poziom 38  

    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


    Ale tak tylko w Era jak ktoś już wspomniał, nawet w poczciwych AVR-ach to się zmieni bo Microchip uznał ten ośmiobitowy rdzeń za lepszy niż ten w PIC i będzie przenosił zapewne powoli różne ciekawe peryferia jakie mają PIC-e ;) więc się nie zdziw jak kiedyś będziesz mógł np. podpiąć pin GPIO bezpośrednio pod 230V i sprzętowo odpalić sobie detekcję przejścia przez zero.

    Inna sprawa że STM32 to tylko seria różnych procesorów opartych o 32 bitowe z różnymi rdzeniami ARM więc nie są to takie same procesory :)

    Jak piszesz w ASM to spokojnie i ARM-y ogarniesz w ASM choć jak ktoś już wspomniał kod będzie trochę dłuższy niż na AVR bo trochę więcej trzeba skonfigurować. To nie jest prawda że nie da się pisać w ASM bo sam czasem dla jaj piszę, problem jest bardziej taki że nie ma to z praktycznego punktu widzenia większego sensu. Ot bardziej sztuka dla sztuki - co nie zmienia faktu że ASM ARM-ów się przydaje aby czasem zobaczyć co nam tam kompilator stworzył podglądając po kompilacji kod czy czasem zrobić jakąś wstawkę w ASM...

    Inna sprawa sprawa ciągnięcie tego tematu z SPL nie ma sensu bo to tylko pogarsza sprawę, jak już ktoś chce się tak bawić to obecnie popularne CubeMX i HAL - dalej to nie jest coś super ale w przeciwieństwie do SPL-a nawet coś na tym można zrobić...

    Co nie zmienia faktu że koledze kurs C się przyda i jak już bawi się w AVR-y w ASM to może i na nich zacząć coś pisać w C (będzie łatwiej). Zwłaszcza że jest na ten temat sporo literatury.

    kogiel napisał:
    @LChucki ja akurat nazwy rejestrów brałem z Reference manual (bo tak mi radzili koledzy wcześniej),
    O plikach nagłówkowych nikt nie wspominał
    Teraz już widzę, że w stm32f4xx.h jest wszystko :-)


    i właściwie RM np. ten wystarcza https://www.st.com/content/ccc/resource/techn...df/jcr:content/translations/en.DM00180366.pdf

    od biedy jak masz czas to nagłówki z tym wszystkim możesz sobie sam stworzyć na podstawie RM jak masz czas i chęci... a może i nawet coś takiego na dobre ci wyjdzie bo trochę poznasz procek robiąc coś od zera ;)

    ...i złota zasada na koniec. Zabierając się za procka zaczynamy od czytania erraty bo czasem można się zdziwić że coś nie do końca działa jak powinno ;)