ATNEL tech-forum

Re: ARM od czego zacząć?

2014-09-24T22:41:34+01:00

Jado napisał(a):

Ja u siebie mam w tym miejscu zestaw makr np. takich:
Składnia: [ Pobierz ] [ Ukryj ]
język c

#define m_GPIOH_PIN_SET(pin) GPIOH->BSRRL = (1 << (pin))
#define m_GPIOH_PIN_CLR(pin) GPIOH->BSRRH = (1 << (pin))

a potem:

#define VS1053_xCS 10 // numer pinu do ktorego bedzie podlaczony pin xCS VS1053
#define VS1053_xCS_PIN_LOW m_GPIOH_PIN_CLR(VS1053_xCS) // uklad VS1053 wybrany (SPI)
#define VS1053_xCS_PIN_HIGH m_GPIOH_PIN_SET(VS1053_xCS) // uklad VS1053 zwolniony (SPI)

GeSHi

Przy czym pod te makra można sobie podpinać "wszelkie rodzaje odwołań", które pozwalają używać tego samego kodu przy różnych rodzajach i rodzinach procków (np. ARM i PIC32) - podmienia się tylko w odp. pliku lokalnym makro odwołujące się do konkretnych rejestrów.
Warstwa wyższa pozostaje ta sama.

Zrobiłem coś takiego (wkleiłem akurat dla avr ale to nieważne):

[syntax=c]#define SPORT(port) (PORT ## port)
#define SDIR(port) (DDR ## port)
#define SPIN(port) (PIN ## port)
#define PIN(port) SPIN(port)
#define DIR(port) SDIR(port)
#define PORT(port) SPORT(port)
#define SET_PIN(port,pin) SPORT(port) |= (1 << pin)
#define RESET_PIN(port,pin) SPORT(port) &= ~(1 << pin)
#define SET_INPUT(port,pin) SDIR(port) &= ~(1 << pin)
#define SET_OUTPUT(port,pin) SDIR(port) |= (1 << pin)[/syntax]
i teraz jakie już zdefiniowane symbole mogę wykorzystać, żeby automatycznie dołączać fragment odpowiedni dla danego procesora/architektury przy pomocy [syntax=c]#if defined( symbol )[/syntax]? Dla avr wydaje mi się, że będzie to "__AVR__", co np z STM32?

Statystyki: Napisane przez Federerer — 24 wrz 2014, o 22:41

Re: ARM od czego zacząć?

2014-09-22T20:28:30+01:00

Kliknij prawym klawiszem na przekreślonym pliku i wybierz Resource Configurations - > Exclude from Build... i odznacz ptaszka.

Statystyki: Napisane przez Krauser — 22 wrz 2014, o 20:28

Re: ARM od czego zacząć?

2014-09-20T17:24:34+01:00

Trafiłem na mały problemik, nie wiem z której strony ugryźć
Korzystam CMSIS i mam problem z niektórymi plikami.

Jak użyć te przekreślone?

Strukturę programu mam taką:
W pliku main.c jest #include "stm32f4xx_hal.h"
W pliku stm32f4xx_hal.h jest #include "stm32f4xx_hal_conf.h"
Natomiast w stm32f4xx_hal_conf.h jest
[syntax=c]#define HAL_MODULE_ENABLED
#define HAL_ADC_MODULE_ENABLED
#define HAL_CAN_MODULE_ENABLED
#define HAL_CRC_MODULE_ENABLED
#define HAL_CRYP_MODULE_ENABLED
#define HAL_DAC_MODULE_ENABLED
#define HAL_DCMI_MODULE_ENABLED
#define HAL_DMA_MODULE_ENABLED
#define HAL_DMA2D_MODULE_ENABLED
#define HAL_ETH_MODULE_ENABLED
#define HAL_FLASH_MODULE_ENABLED
#define HAL_NAND_MODULE_ENABLED
#define HAL_NOR_MODULE_ENABLED
#define HAL_PCCARD_MODULE_ENABLED
#define HAL_SRAM_MODULE_ENABLED
#define HAL_SDRAM_MODULE_ENABLED
#define HAL_HASH_MODULE_ENABLED
#define HAL_GPIO_MODULE_ENABLED
#define HAL_I2C_MODULE_ENABLED
#define HAL_I2S_MODULE_ENABLED
#define HAL_IWDG_MODULE_ENABLED
#define HAL_LTDC_MODULE_ENABLED
#define HAL_PWR_MODULE_ENABLED
#define HAL_RCC_MODULE_ENABLED
#define HAL_RNG_MODULE_ENABLED
#define HAL_RTC_MODULE_ENABLED
#define HAL_SAI_MODULE_ENABLED
#define HAL_SD_MODULE_ENABLED
#define HAL_SPI_MODULE_ENABLED
#define HAL_TIM_MODULE_ENABLED
#define HAL_UART_MODULE_ENABLED
#define HAL_USART_MODULE_ENABLED
#define HAL_IRDA_MODULE_ENABLED
#define HAL_SMARTCARD_MODULE_ENABLED
#define HAL_WWDG_MODULE_ENABLED
#define HAL_CORTEX_MODULE_ENABLED
#define HAL_PCD_MODULE_ENABLED
#define HAL_HCD_MODULE_ENABLED[/syntax]

Wszystkie są ENABLED, pliki nagłówkowe dołączone, natomiast przy próbie kompilacji mam "undefined reference"
Pliki ".c" są ale środowisko ich nie kompiluje i nie linkuje, jak te pliki odblokować?

Statystyki: Napisane przez PROTON — 20 wrz 2014, o 17:24

Re: ARM od czego zacząć?

2014-09-10T20:53:17+01:00

AndreAs napisał(a):

FRDM-KL25Z

jest bardzo fajnym zestawem ten mały Cortex-M0+ jest naprawdę porządny i warto od niego zacząć.

AndreAs napisał(a):

FRDM-K64F

Jej ekscelencja to potęga, powoli będzie o niej sporo na kinetis.pl i możliwe że i u mnie
niemniej na początek nie warto się rzucać na tego potworka. Bo możesz szybko się zniechęcić
Powoli małymi kroczkami zacznij od tańszego , prostszego i mniejszego rdzenia ale z pazurkiem , a w miarę jedzenia albo weźmiesz dokładkę , albo się nasycisz , a tak ... czeka cię roztrój żołądka z przejedzenia i wymioty

Statystyki: Napisane przez SunRiver — 10 wrz 2014, o 20:53

Re: ARM od czego zacząć?

2014-09-10T20:44:22+01:00

Jeżeli chodzi o zestaw to decyzję już pojąłem jakiś czas temu i ze względu na sunduino i kinetis.pl wybiorę jakiś kinetis , fajny jest FRDM-K64F , ale większość przykładów jest na FRDM-KL25Z i FRDM-KL46Z . Chyba że koledzy pomożecie mi pojąć decyzję za co byłbym bardzo wdzięczny. Pozdrowienia .

Statystyki: Napisane przez AndreAs — 10 wrz 2014, o 20:44

Re: ARM od czego zacząć?

2014-09-10T19:44:51+01:00

kod zawarty w iniialize jest wstawiany po prostu podczas kompilacji we właściwe miejsce

Statystyki: Napisane przez SunRiver — 10 wrz 2014, o 19:44

Re: ARM od czego zacząć?

2014-09-10T19:31:41+01:00

Ja nie narzekam, jak już zacząłem i pierwsze miganie diodami mam za sobą to samo idzie do przodu.
GPIO opanowałem, próbowałem z bibliotekami SPL i CMSIS, bardziej intuicyjne jest dla mnie pracowanie bezpośrednio na portach GPIO.
Teraz jestem na etapie testowania sprzętowego SPI z SSD1306.
Z książek nie korzystam, wystarczająco dużo jest materiałów w sieci.

Statystyki: Napisane przez PROTON — 10 wrz 2014, o 19:31

Re: ARM od czego zacząć?

2014-09-10T18:32:20+01:00

Cicho mi tu panowie , jest cienko cienko z dokumentacjami ...
dlaczego ??

1. Trzeba je przeczytać

Statystyki: Napisane przez SunRiver — 10 wrz 2014, o 18:32

Re: ARM od czego zacząć?

2014-09-10T09:33:21+01:00

AndreAs napisał(a):

Bo sam zestaw to nie wszystko , liczy się jeszcze wsparcie jakie dany zestaw posiada a z tym jest naprawdę cienko , ba nawet bardzo cienko .

Polemizował bym, do FRDM masz książkę, co prawda na środowisku CW, ale nowy KDS praktycznie to to samo, są szczegóły, ale autor obecny na tym forum (SunRiver) pomoże.

Książki z BTC może nie powalają, ale by zacząć są wystarczające. Dokumentacja do Kinetisa i STMa jest naprawdę przejrzyście napisana, nie ma problemu z zrozumieniem.
Przykładów na stronie STM32.eu, czy Kinetis.pl i wielu innych polskich stronach jest zatrzęsienie.

Jedynie na co można narzekać, to iż do zestawów nie dodają "chęci do nauki" w gratisie. Tu niestety trzeba samemu zadbać o systematyczność.
Nie ma co narzekać, kupić najtańszego FRDM, czy STMa i działać, migać diodą, odczytywać dane z accelerometru w zestawie by coś się działo. Do wszystkich komponentów są gotowe biblioteki.
Po za tym darmowe środowiska i debuger na pokładzie, czego więcej chcieć ?

Statystyki: Napisane przez Gość — 10 wrz 2014, o 09:33

Re: ARM od czego zacząć?

2014-09-09T20:55:03+01:00

No właśnie ja też od dłuższego czasu zadaje sobie to pytanie od czego zacząć przygodę z ARM ??? . I moja konkluzja jest taka , że na rynku jest dosłownie za trzęsienie zestawów różnych firm , i..... właściwie na tym się kończy cała zabawa . Bo sam zestaw to nie wszystko , liczy się jeszcze wsparcie jakie dany zestaw posiada a z tym jest naprawdę cienko , ba nawet bardzo cienko .

Statystyki: Napisane przez AndreAs — 9 wrz 2014, o 20:55

Re: ARM od czego zacząć?

2014-09-06T00:55:41+01:00

Przyda się, bo do teraz robiłem tak, że tworzyłem projekt z szablonu a potem usuwałem wszystkie niepotrzebne rzeczy

Statystyki: Napisane przez Federerer — 6 wrz 2014, o 00:55

Re: ARM od czego zacząć?

2014-09-05T19:57:02+01:00

Ja w ogóle nie używam tych plików, jeżeli przy tworzeniu projektu wybierzecie konfigurację pod konkretną rodzinę procesora np. STM32F1x... to eclipse wrzuca mnóstwo niepotrzebnych plików. Polecam użyć opcji Cross GCC i powrzucać tylko to co się potrzebuje

http://promikro.com.pl/wp-content/uploa ... images.pdf

Od strony 22 potem trzeba wejść w system_stm32f.....c i zakomentować/odkomentować odpowiednie definicje tak aby procek śmigał na wymaganej przez nas częstotliwości.

Potem do maina SystemCoreClockUpdate(); i powinno chodzić np, na 168 Mhz

Statystyki: Napisane przez ps19 — 5 wrz 2014, o 19:57

Re: ARM od czego zacząć?

2014-09-05T19:44:58+01:00

Dokładnie, też do tego doszedłem, wystarczy w _initialize_hardware.c zaremować configure_system_clock(); i widać że układ działa na 8 MHz.
Skonfigurowany jest też SysTick, bez pustej funkcji void SysTick_Handler(void){} układ się zatrzymuje.

Pytanie, gdzie i jak on się wykonuje przed main?

Statystyki: Napisane przez PROTON — 5 wrz 2014, o 19:44

Re: ARM od czego zacząć?

2014-09-05T18:09:25+01:00

Zawartość tego pliku jest wykonywana przed mainem, nie wiem tylko w jaki sposób jest ona wywoływana. Podejrzewam, że jest to zawarte w pliku startowym, ale przydałoby się potwierdzenie przez kogoś bardziej doświadczonego.

Statystyki: Napisane przez Federerer — 5 wrz 2014, o 18:09

Re: ARM od czego zacząć?

2014-09-05T15:52:29+01:00

Nie trzeba includujesz tylko stm32f10x.h (zależy od rodziny procka)

Statystyki: Napisane przez ps19 — 5 wrz 2014, o 15:52

Re: ARM od czego zacząć?

2014-09-05T13:42:38+01:00

SunRiver napisał(a):

popatrz u mnie na stronie , masz keplera i LUnę oraz opis co jak ustawić , masz też darmowy CoIDE wystarczy pokopac u mnie na stronie w dziale arm

Zainstalowałem keplera.
Po utworzeniu nowego pustego projektu typu STM32F4xx C/C++ Project, toolchain Cross ARM GCC
pojawiają się dwa pliki src:
main.c
__initialize_hardware.c

Czy w main.c trzeba includować __initialize_hardware.c, żadnego połączenia pomiedzy plikami nie widzę, ale chyba się inicjalizuje.

Statystyki: Napisane przez PROTON — 5 wrz 2014, o 13:42

Re: ARM od czego zacząć?

2014-09-03T15:46:35+01:00

Federerer napisał(a):

Mogę napisać tylko:

[syntax=c]GPIOx->BSRRx = GPIO_Pin;[/syntax]

licząc się z ewentualną dodatkową robotą przy zmianie procesora na inny.
Mam nadzieję, że teraz wszystko dobrze rozumiem?

Ja u siebie mam w tym miejscu zestaw makr np. takich:
[syntax=c]#define m_GPIOH_PIN_SET(pin) GPIOH->BSRRL = (1 << (pin))
#define m_GPIOH_PIN_CLR(pin) GPIOH->BSRRH = (1 << (pin))

a potem:

#define VS1053_xCS 10 // numer pinu do ktorego bedzie podlaczony pin xCS VS1053
#define VS1053_xCS_PIN_LOW m_GPIOH_PIN_CLR(VS1053_xCS) // uklad VS1053 wybrany (SPI)
#define VS1053_xCS_PIN_HIGH m_GPIOH_PIN_SET(VS1053_xCS) // uklad VS1053 zwolniony (SPI)[/syntax]

Przy czym pod te makra można sobie podpinać "wszelkie rodzaje odwołań", które pozwalają używać tego samego kodu przy różnych rodzajach i rodzinach procków (np. ARM i PIC32) - podmienia się tylko w odp. pliku lokalnym makro odwołujące się do konkretnych rejestrów.
Warstwa wyższa pozostaje ta sama.

Wtedy nie musisz szukać po całym kodzie odwołań do portów - masz wszystko w jednym miejscu i wystarczy tam podmienić.

Statystyki: Napisane przez Jado — 3 wrz 2014, o 15:46

Re: ARM od czego zacząć?

2014-09-03T15:13:37+01:00

Ja to wszystko wiem i rozumiem, tylko błędnie zakładałem, że funkcje zawarte w HAL-u są oparte bezpośrednio na kodzie SPL-a. Zajrzałem sobie do źródeł i widzę różnice. Wygląda na to, że wszystko zostało napisane w większości od nowa. Np w SPL-u przy inicjalizacji GPIO nie ma w ogóle konfiguracji funkcji alternatywnych, a HAL jest kompletny.

Czyli zasadniczo dzięki standaryzacji, biorąc mikrokontroler od innego producenta nazwy funkcji i struktury pozostają zawsze te same, jedynie zawartość funkcji obsługujących peryferia, która jest dostarczana przez producenta danego układu jest różna. Plusy tego rozwiązania są oczywiste - przenośność kodu. Minusy też - marnujemy czas procesora i flash. Ale przy aktualnych pojemnościach flasha i uwzględniając fakt, że inicjalizację peryferiów przeprowadza się zwykle tylko raz na początku, ma to wszystko sens. Jedynie w miejscach bardziej krytycznych czasowo można pokusić się o bezpośrednie odwołania do rejestrów. Np zamiast wywoływać funkcję:

[syntax=c]void HAL_GPIO_WritePin(GPIO_TypeDef* GPIOx, uint16_t GPIO_Pin, GPIO_PinState PinState)
{
/* Check the parameters */
assert_param(IS_GPIO_PIN(GPIO_Pin));
assert_param(IS_GPIO_PIN_ACTION(PinState));

if(PinState != GPIO_PIN_RESET)
{
GPIOx->BSRRL = GPIO_Pin;
}
else
{
GPIOx->BSRRH = GPIO_Pin ;
}
}[/syntax]

Mogę napisać tylko:

[syntax=c]GPIOx->BSRRx = GPIO_Pin;[/syntax]

licząc się z ewentualną dodatkową robotą przy zmianie procesora na inny.

Mam nadzieję, że teraz wszystko dobrze rozumiem?

Statystyki: Napisane przez Federerer — 3 wrz 2014, o 15:13

Re: ARM od czego zacząć?

2014-09-03T11:50:27+01:00

Na początek, całkowity mogę śmiało polecić FRDM KL25Z na mbed.org
Do zapoznania z platformą starczy, potem można iść w KDSa.
ewentualnie Nucleo, bo też jest zgodne z shieldami ardunio .

Statystyki: Napisane przez Gość — 3 wrz 2014, o 11:50

Re: ARM od czego zacząć?

2014-09-03T08:16:49+01:00

http://ep.com.pl/files/2736.pdf

Quote:

"Biblioteka STM32F10x Standard Peripherals Library V3.1.0 wykorzystuje standard CMSIS, a więc warto się nieco z nim zapoznać. Standard CMSIS (Cortex Microcontroller Software Interface Standard) jest to uniwersalny interfejs programowy, stworzony przez firmę ARM, który umożliwia komunikację z peryferiami i rdzeniem Cortex za pomocą ustandaryzowanych funkcji i definicji. CMSIS dostarcza mechanizmów do obsługi układów peryferyjnych, systemów operacyjnych czasu rzeczywistego oraz aplikacji wykorzystujących interfejsy komunikacyjne: Ethernet, UART oraz SPI."

Napisane jest że SPL wykorzystuje standard CMSIS ale nie jest napisane że jest z nim zgodne, stąd te subtelne różnice.

Statystyki: Napisane przez PROTON — 3 wrz 2014, o 08:16

Re: ARM od czego zacząć?

2014-09-02T21:24:01+01:00

Hmm, w sumie nie zaglebialem sie w to nigdy. Funkcje po nazwach wygladaly mi tak samo, to myslalem ze w srodku jest to samo. Podpowie ktoś gdzie popełniam błąd?

Statystyki: Napisane przez Federerer — 2 wrz 2014, o 21:24

Re: ARM od czego zacząć?

2014-09-02T18:51:40+01:00

Federerer napisał(a):

To jest generalnie to samo, tylko aktualnie nazywa się HAL, a kiedyś było SPL-em

a cóż to za herezje ??

Statystyki: Napisane przez SunRiver — 2 wrz 2014, o 18:51

Re: ARM od czego zacząć?

2014-09-02T15:14:08+01:00

To jest generalnie to samo, tylko aktualnie nazywa się HAL, a kiedyś było SPL-em

Statystyki: Napisane przez Federerer — 2 wrz 2014, o 15:14

Re: ARM od czego zacząć?

2014-09-02T15:01:55+01:00

Już znalazłem tą subtelną różnicę

pierwszy przykład wymaga biblioteki STM32F4xx_StdPeriph_Driver
[syntax=c]#include "stm32f4xx_gpio.h[/syntax]

drugi wymaga biblioteki CMSIS
[syntax=c]#include "stm32f4xx_hal.h"[/syntax]

Statystyki: Napisane przez PROTON — 2 wrz 2014, o 15:01

Re: ARM od czego zacząć?

2014-09-02T14:27:44+01:00

PROTON napisał(a):

Może mo ktoś wyjaśnić skąd się biorą subtelne różnice w przykładowych kodach ARM?

Kod niedziałający
[syntax=c]GPIO_InitTypeDef GPIO_InitStructure;
/* LED_GPIO Periph clock enable */
RCC_APB2PeriphClockCmd(LED_GPIO_RCC, ENABLE);

/* Configure LED pin in output pushpull mode */
GPIO_InitStructure.GPIO_Pin = LED_Pin;
GPIO_InitStructure.GPIO_Speed = GPIO_Speed_50MHz;
GPIO_InitStructure.GPIO_Mode = GPIO_Mode_Out_PP;
GPIO_Init(LED_GPIO, &GPIO_InitStructure);[/syntax]

Kod działający
[syntax=c]GPIO_InitTypeDef GPIO_InitStructure;
/* LED_GPIO Periph clock enable */
RCC->AHB1ENR |= RCC_AHB1ENR_GPIOBEN;

/* Configure LED pin in output pushpull mode */
GPIO_InitStructure.Pin = LED_Pin;
GPIO_InitStructure.Speed = GPIO_SPEED_FAST;
GPIO_InitStructure.Mode = GPIO_MODE_OUTPUT_PP;
GPIO_InitStructure.Pull = GPIO_PULLUP;
HAL_GPIO_Init(LED_GPIO, &GPIO_InitStructure);[/syntax]

Chyba tego nikt nie odgadnie dlaczego. Pokaż cały kod inkludy, na jakich płytkach lub ewentualnie schemat, założyć osobny wątek.

Statystyki: Napisane przez xbary — 2 wrz 2014, o 14:27