STM32 - IDE, jakie?

[Sławek5]

Cześć.
Pewnie już cos podobnego sie pojawiło, ale nie mogę sie pozbierać z tym.

Chciałbym zaczać swoj przygodę z STM32, ale nie wiem jakie środowisko mam zainstalować i jaki programator wybrać?

Myślałem o pakiecie RIDE7 bo nie ma ograniczenia kodu, ale nie wiem jaki Debugger mozna do niego kupić w miarę tani.

możecie mi poradzic co Wy używacie?

[radzio]

Do Ride debugger nie jest najtańszy : http://www.kamami.pl/index.php?ukey=pro ... tID=103181 pozatym przy debugu jest ograniczenie do 64kB, za wersję unlimited trzeba zapłacić znacznie więcej.
Jedynym ekonomicznym wyjściem jest Eclipse + debugger na FT2232 : http://www.kamami.pl/index.php?ukey=pro ... tID=137783 ale jest to troszkę wyższy stopień skomplikowania obsługi.

[Sławek5]

Tak na dobra sprawę to pomyślałem sobie że jedynym wyjściem będzie (chyba?) uzywanie RIDE7 i symulatora programowego. Nie tworzę skomplikowanych programów wiec powinno wystarczyć.

Przy okazji zapytałbym sie o sekcje pamieci. W Ride7 po kompilacji pojawia się taki wykaz txt, data i bss. Czy to oznacza to samo co było w kompilatorze dla AVR? Przecież Ride7 nie korzysta z GCC?

[radzio]

Oznacza to mniej więcej to samo. Ride przez dłuższy czas korzystało z GCC, teraz korzysta z innego kompilatora, co nie znaczy jednak że sekcje w pamięci muszą być nazwane inaczej niż to miało miejsce w gcc.

[Sławek5]

A czy jest to gdzieś wpost napisane co dokładnie oznaczają w Ride7 poszczególne sekcje? Przeszukałem Helpa Ride7 i nie doszukałem się informacji.
Z domysłów wychodzi mi że text to kod programu, data to dane w RAM inicjowane, a bss to dane w RAM nieinicjowane. Czy to się zgadza? Ale to są moje domysły, czy prawdziwe?

[radzio]

Myślę, że Twoje domysły są prawdziwe, z tym że w bss są raczej zmiennie inicjowane zerem.
Text to kod programu (we flashu), data trafia i do flasha i do ramu (zawartość sekcji data jest kopiowana z flasha do ramu), natomiast bss trafia do ramu i jest zazwyczaj zerowana. Tak więc zajętość pamięci flash to suma text + data, natomiast zajętość ramu to data + bss. No i oczywiście stos, ale tu jego zużycie zmienia się w trakcie działania programu.

[Sławek5]

Chciałbym się o jeszcze dość ważna sprawę zapytac i prosze o wyrozumiałość bo nie do końca to rozumiem.
Chodzi mi o tzw. pliki startowe zarówno w Keil'u jak i w Ride7 (choć w WinARM też są)
Moje pytania dotyczą tego dlaczego w ARMach są tak powrzechne? W AVRach tego nie sotosowano.
A naważniejsze skąd dane środowisko "wie" że na pierwsze co ma się wykonać to właśnie kod w pliku startup? Podstwa języka C to kod zawarty w fukcji main() a startup wykonuje się jeszcze przed main(). A co dla mnie dziwne że jak usune plik startup (oczywiście róznie nazwany co też ciekawe że można go dowolnie nazwać) to i tak się kompiluje a co co on powinien robić można "umieścić" w main().
Gdzie jest ten "haczyk"

[radzio]

To, że w WinAVR plików startowych nie widać, nie oznacza że ich tam nie ma. Po prostu AVRy są jedne, a ARMów są "tysiące a nawet setki". Dzięki temu, że AVRy są jedne, i robione przez jednego producenta to ich konfiguracja pamięci jest spójna i wszelkie niezbędne procedury startowe dołączono do WinAVR i "wprost" ich nie widać. Natomiast każdy producent ARMów może sobie umieszczać pamięci pod róznymi adresami, co komplikuje przygotowanie jednego uniwersalnego zestawu plików startowych. Pomijam juz fakt, że co tydzień na rynku pojawiają się coraz to nowe ARMy, w których znowu dany producent może sobie zrobić coś po swojemu.
Zazwyczaj z plikiem startowym połączona jest tablica wektorów przerwań, i to ona definiuje tak naprawdę co jest wykonywane jako pierwsze. W przypadku STM32 (i ogólnie Cortexów) drugi element tej tablicy jest adresem prodcedury obsługi przerwania od resetu, i dopiero w ramach tej procedury następuje (po zainicjalizowaniu zmiennych) skok do funkcji main(). Ponadto w startupach dostarczanych przez STMicroelectronics przed wywołaniem funkcji main() wywoływana jest jeszcze funkcja SystemInit, której nieuwzględnienie w projekcie objawi się błędem na etapie linkowania programu.

[Sławek5]

Rozumiem, że trudno i nawet nie jest możliew aby kompilator mógł obsłużyć wszystkie wersje ARMów i te pliki startup są wygodne. Ale gdzie jest wskazane, że jako piewszy ma się wykonac kod zawarty w pliku startup? Mogą one mieć dowolną nazwę a i tak kod w nich zawarty wykonuje sie jako pierwszy?
Klasycznie to funkcja main() wywołuje poszczególne podprogramy ale startup wykonywany jest przed nią?

[radzio]

Konkretnie jest to wskazane w tablicy wektorów przerwań.

Kod: Zaznacz cały

.section .isr_vector,"a",%progbits .type g_pfnVectors, %object .size g_pfnVectors, .-g_pfnVectors g_pfnVectors: .word _estack .word Reset_Handler // <<<<<<<<<<<<<<<<< TO ZOSTANIE WYKONANE JAKO PIERWSZE! .word NMI_Handler .word HardFault_Handler .word MemManage_Handler .word BusFault_Handler .word UsageFault_Handler .word 0 .word 0 .word 0 .word 0 .word SVC_Handler .word DebugMon_Handler .word 0 .word PendSV_Handler .word SysTick_Handler .word WWDG_IRQHandler .word PVD_IRQHandler .word TAMPER_IRQHandler .word RTC_IRQHandler .word FLASH_IRQHandler .word RCC_IRQHandler .word EXTI0_IRQHandler .word EXTI1_IRQHandler .word EXTI2_IRQHandler .word EXTI3_IRQHandler .word EXTI4_IRQHandler .word DMA1_Channel1_IRQHandler .word DMA1_Channel2_IRQHandler .word DMA1_Channel3_IRQHandler .word DMA1_Channel4_IRQHandler .word DMA1_Channel5_IRQHandler .word DMA1_Channel6_IRQHandler .word DMA1_Channel7_IRQHandler .word ADC1_2_IRQHandler .word USB_HP_CAN1_TX_IRQHandler .word USB_LP_CAN1_RX0_IRQHandler .word CAN1_RX1_IRQHandler .word CAN1_SCE_IRQHandler .word EXTI9_5_IRQHandler .word TIM1_BRK_IRQHandler .word TIM1_UP_IRQHandler .word TIM1_TRG_COM_IRQHandler .word TIM1_CC_IRQHandler .word TIM2_IRQHandler .word TIM3_IRQHandler .word TIM4_IRQHandler .word I2C1_EV_IRQHandler .word I2C1_ER_IRQHandler .word I2C2_EV_IRQHandler .word I2C2_ER_IRQHandler .word SPI1_IRQHandler .word SPI2_IRQHandler .word USART1_IRQHandler .word USART2_IRQHandler .word USART3_IRQHandler .word EXTI15_10_IRQHandler .word RTCAlarm_IRQHandler .word USBWakeUp_IRQHandler .word 0 .word 0 .word 0 .word 0 .word 0 .word 0 .word 0 .word BootRAM /* @0x108. This is for boot in RAM mode for STM32F10x Medium Density devices. */

Zamiast Restet_Handler możesz wstawić dowolną funkcję, ale po co? Lepiej wywołać ją z funkcji Reset_Handler.

[Sławek5]

Przepraszam ale znowu utknąłem tym razem z przerwaniami.
W AVRach było tak że po wystąpieniu przerwania np INT0 przerywany był główny program, następował skok pod adres 0x001 a tam pod tym adresem był adres procedury związanej z przerwaniem. Proste.
Natomiast zupełnie się pogubiłem w STM32. Niby program jest po resecie wykonywany od adresu 0 bo zeruje się licznik programu a po Restet_Hendler jest cała lista przerwań to wychodzi z tego że wektory tych przerwań powinny być w pamięci Flash od adresu zero. A tu widzę że adres wektorów przerwań zaczyna się od liczby 0x08000000 a jeszcze w innym miejscu pojawia mi się jeszcze wyższy adres tych wektorów zaczynający się prawie na końcu przestrzeni adresowej 0xE00...

Jak to w końcu działa i dlaczego takie są dziwne adresy?

[radzio]

No więc tak : tablica wektorów przerwań zawiera adresy prodcedur obsługi przerwań, z małym wyjątkiem iż pierwszy (o indeksie zero) element tej tablicy jest początkową wartością wskaźnika stosu. Każdy element tej tablicy (za wyjątkiem elementu o numerze zero) jako że jest adresem, może wskazywać dowolne miejsce w pamięci, a więc dowolną procedurę. Jedna procedura może być wskazywana przez wiele elementów tablicy wektorów przerwań. W AVR natomiast każde przerwanie miało stały adres, pod którym musi znajdować się procedura obsługi przerwania, tzn pod adresem danego przerwania, muszą znajdować się instrukcje, zazwyczaj jest to instrukcja skoku w dalsze miejsce w pamięci programu, gdyż przerwanie ma do dyspozycji zaledwie miejsce na jedną instrukcję asemblera.

Tablica wektorów musi się oczywiście znajdować na początku pamięci flash, która w przestrzeni adresowej STM32 jest położona pod adresem 0x08000000. Oczywiście, po resecie program startuje od adresu 0x0000 0000 - to znaczy ładuje do licznika programu adres umieszczony pod adresem 0x0000 0004.
I teraz, w zalezności od stanu wyprowadzeń BOOT0 i BOOT1 pod adresem 0x0000 0000 mogą znajdować się różne rzeczy : albo jest tam zmapowana pamięć Flash albo systemowa pamięć ROM z bootloaderem umożliwiającym programowanie po RS232. Oczywiście w przypadku, gdy pod adresem 0x0000 0000 zmapowana jest pamięć Flash, dostępna jest ona pod dwoma adresami : 0x0000 0000 oraz oryginalnym 0x0800 0000. Program powinno się jednak przygotować tak, aby jego oryginalnym początkiem był adres 0x0800 0000.

a jeszcze w innym miejscu pojawia mi się jeszcze wyższy adres tych wektorów zaczynający się prawie na końcu przestrzeni adresowej 0xE00...

Możesz wskazać to miejsce?

[Sławek5]

Zaczyna się od strony 25 w pliku PM0056 "STM32F10xxx Cortex-M3 programming manual" w sekcji Memory Map. Z niego wynika że cały kontroler NVIC jest w ostatnich adresach przestrzeni adresowej. A jeszcze na stronie 35 o wektorach

To co napisałeś jest logiczne, ale gdzie tak fizycznie "skacze program" po wystąpieniu przerwania? Rdzeń musi mieć przecież stały adres skoku do tablicy wektorów i stamtąd dopiero pobiera adres procedury przerwania. Ja to rozumiem tak, że każde przerwanie ma swój stały adres np IRQ1 0x0040 - tam skacze. Natomiast to co napisałeś o mapowaniu pamięci wiąże się z tym, że pisząc program należy stosować adres mapowania czyli te 0x08000000. Ale pewnie coś źle rozumiem?

[radzio]

Zaczyna się od strony 25 w pliku PM0056 "STM32F10xxx Cortex-M3 programming manual" w sekcji Memory Map. Z niego wynika że cały kontroler NVIC jest w ostatnich adresach przestrzeni adresowej. A jeszcze na stronie 35 o wektorach

Ale NVIC to kontroler przerwań (sprzęt), który ma tam jakeś swoje rejestry konfiguracyjne itp. Nie ma to związku z położeniem tablicy wektorów przerwań, pozatym że możesz ją przesunąć o jakiś zdefiniowany offset (np gdy chcesz, aby Twój program startował od innego miejsca pamięci programu - ma to miejsce przy tworzeniu własnych bootloaderów na przykład).

To co napisałeś jest logiczne, ale gdzie tak fizycznie "skacze program" po wystąpieniu przerwania?

Program "skacze" pod adres pobrany z tablicy wektorów przerwań dla odpowiedniego przerwania, które wystąpiło.

Rdzeń musi mieć przecież stały adres skoku do tablicy wektorów i stamtąd dopiero pobiera adres procedury przerwania. Ja to rozumiem tak, że każde przerwanie ma swój stały adres np IRQ1 0x0040 - tam skacze.

No więc na stronie 35 masz tabelkę, gdzie podany jest offset dla każdego przerwania (pąta kolumna). I tylko ten offset jest stały. Natomiast możesz w pewnym zakresie zmienić początek tablicy wektorów. I po wystąpieniu przerwania, NVIC (a raczej System Controll Block - SCB) sobie dodaje do początku tablicy offset danego przerwania i stamtąd pobiera adres, pod który skacze.

Natomiast to co napisałeś o mapowaniu pamięci wiąże się z tym, że pisząc program należy stosować adres mapowania czyli te 0x08000000. Ale pewnie coś źle rozumiem?

Chodziło mi o to, aby podać linkerowi informację o tym, że pamięc programu zaczyna się od adresu 0x0800 0000. Można to zrobić za pomocą skryptu linkera, w opcjach IDE, np. Keila czy RIDE (tu zazwyczaj jest to robione domyślnie i nie musisz sobie tym głowy zawracać).

[Sławek5]

Wszystko jest OK.
Tylko chodzi raczej o to skąd rdzeń ma wiedzieć gdzie jest ta tablica tzn. skąd ma pobrać adres funkcji obsługi przerwania? Jest przerwanie, linker tablice wektorów umieścił pod adresem pod 0x08000000 + 0x0040 (ten ofset przewiania IRQ1) spod tego adresu pobiera adres funkcji obsługi przerwania i tam skacze wykonując je. Przenosimy początek Flash do innego miejsca (strzelam np 0x09000000) występuje przerwanie i czy pobranie wektora przerwania też jest spod adresu tzn 0x08000040 czy spod nowego tj. 0x09000040. Jeśli nowego to skąd wiedział?

[radzio]

Zmiany lokalizacji tablicy wektorów przerwań dokonuje się za pomocą rejestru VTOR układu SCB (strona 134). Tzn musisz zapisać tam offset do tablicy.