Czy warto się uczyć 8 bitowców po STM32 i Rassbery Pi?

[dejmieno]

Cześć,

Od kilku tygodni uczę się programować mikroprocesory STM32F1 a w przyszłości zamierzam zabrać się dodatkowo za Rassbery Pi. Chciałem zapytać się was czy warto w takiej sytuacji uczyć się programować 8 bitowce?

Jak to wygląda u was? Czy nadal korzystacie z 8 bitowców?

Dodam jeszcze, że chcę się uczyć nie tylko pod kątem hobbystycznym, ale również zawodowym. Może kiedyś chciałbym zmienić branże z Javy na mikrokontrolery.

[deshipu]

Tak.

[SOYER]

Zdecydowanie tak, kiedyś przed moim arduino jak czytałem artykuły z kursów fpga czy innych, to jakbym czytał o fizyce kwantowej w układach ciemnej materii, położonych w odległej galaktyce z odwróconym biegiem czasu, teraz jeszcze się nie uczę STM(w praktyce), ale staram się czytać na bieżąco i wiem o czym mowa(z grubsza 😅 ). Pewnie w następną zimę, przy większej ilości czasu wezmę się za praktykę....

Pewnie można zacząć od razu wyżej, ale wydaje mi się, że tak jest dużo łatwiej...

[dejmieno]

Czyli rozumiem, że nawet jeśli ogarniacie mocniejsze układy STM32, Rassbery Pi to nadal znajdujecie zastosowanie dla 8 bitowców?

[Polecacz 101]

Produkcja i montaż PCB - wybierz sprawdzone PCBWay!
   • Darmowe płytki dla studentów i projektów non-profit
   • Tylko 5$ za 10 prototypów PCB w 24 godziny
   • Usługa projektowania PCB na zlecenie
   • Montaż PCB od 30$ + bezpłatna dostawa i szablony
   • Darmowe narzędzie do podglądu plików Gerber
Zobacz również » Film z fabryki PCBWay

[SOYER]

Żeby pojechać po bułki wystarczy często rower, ale do skoszenia zboża wybierasz raczej kombajn niż rower...

[GAndaLF]

Zastosowanie dla 8-bitowców na pewno znajdziesz, natomiast jeśli nauczysz się dobrze programowania embedded na jakiejś rodzinie 32-bitowej, nie będziesz się musiał 8-bitowców specjalnie uczyć. Po prostu przeczytasz noty katalogowe, poznasz kompilator, IDE, debugger i sobie poradzisz. Poza peryferiami jest tylko kilka zagadnień specyficznych dla 8-bitowców np. jest mniej pamięci FLASH i RAM, więc musisz brać to pod uwagę przy pisaniu i często nie ma debuggera, bo szkoda na niego nóżek i trzeba sobie z debugowaniem radzić jakoś inaczej. Jednak zdecydowana większość wiedzy zdobytej na jednej rodzinie procesorów przenosi się również na inne rodziny.

[deshipu]

To trochę tak jak mówić, że jak nauczysz się jeździć motocyklem, to na hulajnodze też sobie poradzisz. W zasadzie prawda, jednak większość dzieci z jakiegoś powodu jednak zaczyna od hulajnogi lub roweru.

[dejmieno]

A możecie mi podać jakiś sprawdzony sposób jak skutecznie uczyć się STMa? Podczas nauki AVR człowiek uczy się korzystać z rejestrów więc przy okazji uczy się architektury i jak działa ta "hulajnoga".

A w przypadku STM32, niby coś się umie zakodzić za pomocą HAL jednak gorzej ze znajomością architektury i jak działa STM32. Macie jakiś sprawdzony sposób na wejście w świat STM32 i żeby przy okazji poznać trochę wnętrze tych procków?

[Lukaszm]

Reference manual?

[MirekCz]

1. Pytanie z mojej strony... po co "uczyć się" 8 bitowców?

Jak zrozumiesz jak działa STM F1 i jego peryferia to większość 8bitowców przy tym to bułka z masłem i po przejrzeniu reference manuala będziesz miał pogląd co i po co.

Oczywiście do "optymalnego" wykorzystania tego przyda się nieco praktyki, ale nie żebyś się jakoś musiał tego uczyć specjalnie.

2. Tak jak kolega mówi reference manual wszystko tłumaczy. Dodatkowo jakaś książka przyda się żeby łatwiej w to wejść, ale bez przesady. Oczywiście zakładam, że angielski to nie problem, bo inaczej od tego trzeba zacząć... 🙂

[GAndaLF]

Jeżeli dopiero zaczynasz, na pewno łatwiej Ci będzie najpierw poznać 8-bitowce, a dopiero potem przesiąść się na STM32. Natomiast jeżeli masz zamiar najpierw nauczyć się STM, a potem przesiąść na 8-bitowce to tak jak pisałem wcześniej, nie będziesz musiał się uczyć niczego nowego, przeczytanie dokumentacji wystarczy.

Faktycznie zapomniałem, że każdy na STM pisze na bibliotekach producenta, bo sam nigdy ich nie tykałem tylko zawsze wszystko na rejestrach. Wtedy faktycznie przejście na 8-bitowce i pisanie na rejestrach rozwinie nowe umiejętności. Powinieneś poznać 8-bitowce, albo popróbować cokolwiek z rejestrami na STM32 aby mieć pojęcie co te biblioteki robią pod spodem. Podczas debugowania peryferiów i tak będziesz musiał wiedzieć, czy zapalone bity oznaczają taką konfigurację jaką chciałeś. Najlepiej poznać rejestry po napisaniu kilku pierwszych programów, kiedy już wiesz że umiesz coś zrobić i chcesz to dalej zgłębiać.

Jeżeli chodzi o sposób nauki, to nie ma tutaj nic odkrywczego - praktyka czyni mistrza. Przykładowy plan może wyglądać tak:

1. Proste programy obsługujące poszczególne peryferia dokładnie jak w kursach.

2. Łączenie kilku peryferiów w jednym programie np. ADC wyzwalane timerem i wynik zapisywany do bufora przez DMA.

3. Jakiś własny projekt np. prosty robot. Przy okazji nauczysz się wtedy projektowania całej aplikacji i zdobędziesz wiedzę z tematów pokrewnych typu silniki, sensory elektronika. Nie da się programować embedded bez tej wiedzy.

4. Zdobywanie wiedzy ogólnej o programowaniu embedded (artykuły, książki itp) - mając trochę doświadczenia powinieneś uzupełnić podstawy teoretyczne. Dzięki temu będziesz wiedział np. dlaczego nie wołać printfa w przerwaniach, co się dzieje między uruchomieniem zasilania a wejścia procka do funkcji main, jak dobrze wykorzystywać przerwania itp. Oczywiście w międzyczasie nową wiedzę warto stosować w praktyce.

A jak chcesz dokładnie wiedzieć co się dzieje pod spodem to polecam najpierw programowanie rejestrów, a jak chcesz wiedzieć więcej to możesz pobawić się z assemblerem. Wtedy dowiesz się jakie rejestry CPU do czego są używane, jakie są tryby adresowania, jak się korzysta ze stosu i różne inne niskopoziomowe rzeczy.

[dejmieno]

@GAndaLF dzięki wielkie za rade 🙂.

Postanowiłem, że będę się uczył StdPeriph ponieważ jest bliżej sprzętu i powoli będę migrować na rejestry. Na początek sterowanie GPIO i małymi kroczkami powoli do przodu 🙂.

W ramach lekcji z ADC już część sterowania GPIO zrobiłem na rejestrach, ale kod wygląda dość brzydko 😉. Masz jakieś rady co do dobrych praktyk żeby kod wyglądał ładnie i czytelnie przy rejestrach?

Mój aktualny kod wygląda tak:

#include "stm32f10x.h"
#include "usart/usart.h"
#include "adc/adc.h"
#include <stdio.h>

#define LED_1 GPIO_ODR_ODR8
#define LED_2 GPIO_ODR_ODR6

void LED1_GPIOC_PIN8_OUT_PP_2MHZ()
{
GPIOC->CRH &= ~(
		GPIO_CRH_CNF8_1 |
		GPIO_CRH_CNF8_0 |
		GPIO_CRH_MODE8_0);

GPIOC->CRH |= GPIO_CRH_MODE8_1;
}

void LED2_GPIOC_PIN6_OUT_PP_2MHZ()
{
GPIOC->CRL &= ~(
		GPIO_CRL_CNF6_1 |
		GPIO_CRL_CNF6_0 |
		GPIO_CRL_MODE6_0);
GPIOC->CRL |= GPIO_CRL_MODE6_1;
}

int main(void)
{
RCC_APB2PeriphClockCmd(
		RCC_APB2Periph_AFIO |
		RCC_APB2Periph_GPIOA |
		RCC_APB2Periph_GPIOB |
		RCC_APB2Periph_GPIOC |
		RCC_APB2Periph_ADC1, ENABLE);

RCC_APB1PeriphClockCmd(RCC_APB1Periph_USART2, ENABLE);

USART2_Init();
ADC_InitModule();

LED1_GPIOC_PIN8_OUT_PP_2MHZ();
LED2_GPIOC_PIN6_OUT_PP_2MHZ();

while (1)
{
	uint16_t conv1 = ADC_GetValue(0);
	uint16_t conv2 = ADC_GetValue(1);
	if (conv1 > conv2) {
		GPIOC->ODR = 0;
		GPIOC->ODR |= LED_1;
	} else {
		GPIOC->ODR = 0;
		GPIOC->ODR |= LED_2;
	}
}
}

PS. super blog.

[GAndaLF]

Przy zwiększaniu czytelności kodu pisanego na rejestrach niestety nie masz zbyt wiele pola manewru. Twoimi przyjaciółmi powinny być #define i komentarze. Możesz też inicjalizację pojedynczych peryferiów zwijać w oddzielne funkcje. Moje moduły hw operujące na rejestrach wyglądają na przykład tak jak tutaj:

https://github.com/ucgosupl/mm_legend_v2/blob/dev/src/hw/adc/adc.c

W powyższym kodzie można jeszcze define niektórych wartości bitowych przenieść oddzielnych headerów z zestawem wszystkich define dla danego peryferium tworząc uzupełnienie bibliotek procka. Tak naprawde powinien to dla nas zrobić producent, a te definy były tylko dostępne jako część StdPeriph pod nieintuicyjnymi nazwami. Być może STM już wydał jakieś nowe headery.

[dejmieno]

A ciekawi mnie jeszcze jak sprawa wygląda w kontekście programowania zawodowego mikrokontrolerów. Czy stawia się bardziej na wydajność i pisanie na rejestrach? Czy podobnie jak w branży języków wysokopoziomowych stawia się na szybkość developmentu, czystość kodu i co za tym idzie korzysta się z bibliotek jak HAL, generatorów kodu CubeMX?

[deshipu]

Stawia się i na jedno i na drugie. Jak robisz prototyp, to chcesz mieć szybko efekt. Jak robisz produkt, który ma być produkowany w milionach egzemplarzy, to starasz się oszczędzić każdy grosz. Trzeba umieć i jedno i drugie.