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

STM32F4 - FreeRTOS - utworzenie zadania

bkdi 30 Mar 2013 13:02 3489 17
  • #1 30 Mar 2013 13:02
    bkdi
    Poziom 12  

    Witam,

    przejrzałem na forum podobne tematy, ale mimo wszystko nie umiem sobie poradzić z uruchomieniem zadania mającego na celu miganie diodą.

    FreeRTOSConfig.h - zapożyczony z przykładu z archiwum z FreeRTOS

    Kod: c
    Zaloguj się, aby zobaczyć kod



    Plik main.c:
    Kod: c
    Zaloguj się, aby zobaczyć kod


    Co powinienem jeszcze ustawić?

    0 17
  • #2 30 Mar 2013 13:25
    Smashing
    Poziom 20  

    Witam,
    Może jeszcze to:

    Kod: c
    Zaloguj się, aby zobaczyć kod

    0
  • #3 30 Mar 2013 13:52
    bkdi
    Poziom 12  

    Próbowałem też z tą planistą - nie pomaga.

    0
  • #4 30 Mar 2013 14:11
    mickpr
    Poziom 39  

    A jakieś błędy sprawdzasz? Np. czy task został utworzony?
    Trochę w ciemno piszesz - bo tego nie wiesz (chyba, że debuggerem sprawdzasz i jesteś pewny).

    0
  • #5 30 Mar 2013 14:59
    bkdi
    Poziom 12  

    Generalnie to wygląda to trochę tak jakby po wejściu do funkcji xTaskCreate program się zawieszał i z niej nie wychodził.

    0
  • #6 30 Mar 2013 15:17
    mickpr
    Poziom 39  

    Masz debugger, albo choć podłączony UART?
    Jeśli tak, to sprawdź dokładnie gdzie się zatrzymuje.
    P.S.
    Ja używam np. taką formę taką wywołania:

    Kod: c
    Zaloguj się, aby zobaczyć kod

    0
  • #7 30 Mar 2013 15:31
    Freddie Chopin
    Specjalista - Mikrokontrolery

    Nie no, wiem że to offtopic, ale jak widzę te nazwy z FreeRTOSa i to jeszcze zarażające innych to po prostu nie mogę się powstrzymać...

    Cytat:
    Most arguments against Hungarian notation are against Systems Hungarian notation, not Apps Hungarian notation. Some potential issues are:
    The Hungarian notation is redundant when type-checking is done by the compiler. Compilers for languages providing type-checking ensure the usage of a variable is consistent with its type automatically; checks by eye are redundant and subject to human error.
    All modern integrated development environments display variable types on demand, and automatically flag operations which use incompatible types, making the notation largely obsolete.
    Hungarian Notation becomes confusing when it is used to represent several properties, as in a_crszkvc30LastNameCol: a constant reference argument, holding the contents of a database column LastName of type varchar(30) which is part of the table's primary key.
    It may lead to inconsistency when code is modified or ported. If a variable's type is changed, either the decoration on the name of the variable will be inconsistent with the new type, or the variable's name must be changed. A particularly well known example is the standard WPARAM type, and the accompanying wParam formal parameter in many Windows system function declarations. The 'w' stands for 'word', where 'word' is the native word size of the platform's hardware architecture. It was originally a 16 bit type on 16-bit word architectures, but was changed to a 32-bit on 32-bit word architectures, or 64-bit type on 64-bit word architectures in later versions of the operating system while retaining its original name (its true underlying type is UINT_PTR, that is, an unsigned integer large enough to hold a pointer). The semantic impedance, and hence programmer confusion and inconsistency from platform-to-platform, is on the assumption that 'w' stands for 16-bit in those different environments.
    Most of the time, knowing the use of a variable implies knowing its type. Furthermore, if the usage of a variable is not known, it cannot be deduced from its type.
    Hungarian notation strongly reduces the benefits of using feature-rich code editors that support completion on variable names, for the programmer has to input the whole type specifier first.
    It makes code less readable, by obfuscating the purpose of the variable with needless type and scoping prefixes.[2]
    The additional type information can insufficiently replace more descriptive names. E.g. sDatabase does not tell the reader what it is. databaseName might be a more descriptive name.
    When names are sufficiently descriptive, the additional type information can be redundant. E.g. firstName is most likely a string. So naming it sFirstName only adds clutter to the code.
    It's harder to remember the names.


    http://en.wikipedia.org/wiki/Hungarian_notation

    Pewnego dnia naprawdę chyba zrobię fork tego projektu i zmienię te głupawe nazwy, bo przecież tego się nie da używać! Te wszystkie "pv", "x", "tsk" i tym podobne bezsensowne przedrostki niczemu nie służą... A już najgenialniejszą rzeczą jest fakt, że napisy muszą być "signed", tak jakby to była jakaś różnica (wynik niewolniczego przywiązania do jakichś narzędzie kontroli semantycznej typu lint czy coś takiego).

    4\/3!!

    0
  • #8 30 Mar 2013 16:20
    mickpr
    Poziom 39  

    Freddie Chopin napisał:
    Pewnego dnia naprawdę chyba zrobię fork tego projektu i zmienię te głupawe nazwy, bo przecież tego się nie da używać! Te wszystkie "pv", "x", "tsk" i tym podobne bezsensowne przedrostki niczemu nie służą.
    Dlaczego tak myślisz?
    Ja przykładowo - jak pisze program (dajmy na to w VB) zawsze oznaczam sobie formularze przedrostkiem frm, buttony - przedrostkiem btn, pola tekstowe - przedrostkiem txt, etykiety - przedrostkiem lbl itd....
    To BARDZO ułatwia operowanie potem na takich cudach podczas pisania aplikacji. Wiem, że nazwa raportu zaczyna się od rpt - przez co wpisując 'rpt' intelisense ogranicza mi podpowiadanie składni.
    Czy to źle?
    Jak spotykam czasem napisane przyciski powiedzmy "Button1" - nie mam pojęcia "o co kaman", co on robi, ale jak będzie "btnCloseApp" - nawet nie muszę sprawdzać - co to jest, prawda?
    Również nazwy w stylu "raportDrukujacyZadluzenieKontrachentaNaPodanyDzien" jest bzdurny - nie prawda?
    Co cię razi w tych przedrostkach? Możesz wyjaśnić?

    0
  • #9 30 Mar 2013 16:37
    bkdi
    Poziom 12  

    Sprawdzając debugerem zawiesza się w tej linijce.

    Kod: c
    Zaloguj się, aby zobaczyć kod


    Rozumiem, że mam coś ze stosem, ale za bardzo nie wiem co mogę z tym zrobić. W pliku ld są jakieś parametry odnośnie stosu, ale nie wiem na co miałbym zwrócić uwagę?

    0
  • #10 30 Mar 2013 17:02
    mickpr
    Poziom 39  

    bkdi napisał:
    Rozumiem, że mam coś ze stosem
    Mógłbym zaryzykować stwierdzenie, że 99% problemów w FreeRTOS, to problemy ze stosem.

    Jak masz wyrównany stos ?
    (w pliku portmacro.h wpis #define portBYTE_ALIGNMENT xx <- co tutaj jest?)

    Jaki sposób zarządzania pamięcią wybrałeś (który plik heapxx.c?)

    0
  • #11 30 Mar 2013 17:31
    bkdi
    Poziom 12  

    #define portBYTE_ALIGNMENT 8

    I wybrałem heap_1.c.

    0
  • #12 30 Mar 2013 18:18
    Sparrowhawk
    Poziom 21  

    mickpr napisał:
    Co cię razi w tych przedrostkach? Możesz wyjaśnić?

    Pewnie razi kolegę Freddiego to samo co wszystkich przeciwników notacji węgierskiej. Freddie podał link - warto przeczytać. Ja osobiście nie mam nic przeciwko tej notacji i również używam jej w przypadku pisania jakiś aplikacji na PC w Visual C++, czy WinApi. Ale z drugiej strony ten przykład mówi sam za siebie:
    Cytat:
    a_crszkvc30LastNameCol: a constant reference argument, holding the contents of a database column LastName of type varchar(30) which is part of the table's primary key.

    0
  • #13 30 Mar 2013 18:29
    mickpr
    Poziom 39  

    Sparrowhawk napisał:
    Ale z drugiej strony ten przykład mówi sam za siebie
    Jest takie określenie - (bodajże Sokratesa) :"Złoty środek".

    bkdi napisał:
    #define portBYTE_ALIGNMENT 8
    I wybrałem heap_1.c.

    W jakim środowisku masz ten projekt. Tak się składa, że mam STM32F4 (Discovery). Mogę sprawdzić w działaniu - bo z takiego "szukania na oślep" - to nic nie będzie.

    0
  • #15 30 Mar 2013 18:36
    mickpr
    Poziom 39  

    bkdi napisał:
    Atollic
    No to nie pomogę.. :(
    Może znajdź jakiś działający "example". To jakaś "developer board" , czy własna PCB?

    0
  • #16 30 Mar 2013 18:40
    bkdi
    Poziom 12  

    Discovery, gdzieś znalazłem jakiś przykład pod F4, ale też coś nie działało.

    0
  • #18 30 Mar 2013 20:08
    bkdi
    Poziom 12  

    Przekopiowałem od nowa pliki FreeRTOS'a, bo nie znalazłem różnic w przykładzie i teraz działa.
    Dzięki za pomoc!

    0