Tak w nawiązaniu do jednej ze wcześniejszych dyskusji:

Naukę programowania MCU zaczynałem od AVR, w międzyczasie przyjrzałem
się trochę Arduino i ESP8266, teraz eksperymentuję z PIC32. W każdym
przypadku korzystam z C/C++.

Po zapoznaniu się z tymi kilkoma przykładami odnoszę coraz większe
wrażenie, że tak naprawdę nie ma wielkiej przepaści. Oczywiście - trzeba
nauczyć się rzeczy charakterystycznych dla danej rodziny (taktowanie,
timery, system przerwań, obsługa GPIO i interfejsów komunikacyjnych) ale
tutaj można podeprzeć się datasheetami i podręcznikami. Potem na dobrą
sprawę wygląda to całkiem podobnie - nawet biblioteki są te same albo
opierają się na podobnych schematach - co najwyżej trzeba im tylko
dostarczyć kilka niskopoziomowych funkcji.

Tak się zastanawiam - czy w przypadku korzystania z kompilatora C
(załóżmy, że w ogóle nie bierzemy pod uwagę nauki asemblera) w pewnym
momencie mogą pojawić się jakieś mocno specyficzne, sprzętowe różnice?
Pomijam kwestię podstaw, np. wyrównywania zmiennych w pamięci albo
rozmiarów typów. Czy jednak programowanie AVR, PIC, ARM7/ARM9 (od
różnych producentów) czy STM32 nie różni się aż tak bardzo między sobą,
gdy używa się C/C++?

do góry

Użytkownik "Atlantis" napisał w wiadomości grup
dyskusyjnych:56b49564$0$642$6...@n...neostrada.
pl...
>Tak w nawiązaniu do jednej ze wcześniejszych dyskusji:
>Naukę programowania MCU zaczynałem od AVR, w międzyczasie przyjrzałem
>się trochę Arduino i ESP8266, teraz eksperymentuję z PIC32. W każdym
>przypadku korzystam z C/C++.

>Po zapoznaniu się z tymi kilkoma przykładami odnoszę coraz większe
>wrażenie, że tak naprawdę nie ma wielkiej przepaści. Oczywiście -
>trzeba
>nauczyć się rzeczy charakterystycznych dla danej rodziny (taktowanie,

Na poziomie C ? Istotnie, nie ma. Moze poza rodzina 8051 i jej
obszarami danych :-)

Na poziomie assemblera ... z jednej strony sa olbrzymie, z drugiej -
jak zrozumiales jak dziala jeden, to reszta dziala analogicznie.

>Tak się zastanawiam - czy w przypadku korzystania z kompilatora C
>(załóżmy, że w ogóle nie bierzemy pod uwagę nauki asemblera) w pewnym
>momencie mogą pojawić się jakieś mocno specyficzne, sprzętowe
>różnice?
>Pomijam kwestię podstaw, np. wyrównywania zmiennych w pamięci albo
>rozmiarów typów.

To, plus wszystkie peryferia. Zegary, liczniki, przerwania, maski itp.
A dalej roznice w bibliotekach - jak programujesz od zera to nie masz
zadnych, jak korzystasz z dostarczonych przez kogos innego - wszelkie
cuda mozliwe.

Zajrzyj chocby w zrodla jakiegos uni/linuxowego programu, ile tam
roznych #if aby to dzialalo.

Obszary pamieci, zarzadzanie pamiecia - drobnych roznic jest pelno.

J.

do góry

oho Kolega dobił do momentu "wielka racjonalizacja donalda t." [R]

do góry

On 2016-02-05 13:28, Atlantis wrote:
> Tak się zastanawiam - czy w przypadku korzystania z kompilatora C
> (załóżmy, że w ogóle nie bierzemy pod uwagę nauki asemblera) w pewnym
> momencie mogą pojawić się jakieś mocno specyficzne, sprzętowe różnice?

Tak. Harvard vs von Neumann. De facto język C nie jest gotowy na
operowanie w przestrzeni adresowej charakterystycznej dla Harvarda.
Każde rozszerzenie załatwiające ten temat jest specyficzne dla
konkretnego kompilatora i konkretnej arch. Były próby uwspólnienia tego
w gcc ale wyszło jak zwykle.

Przy czym zaznaczam że czasami harvardowatość jest ukryta przed kodem
usera. Mówimy o procesorach gdzie jest to widoczne, jak na przykład AVR.
Tam jezyk C z definicji bedzie musiał być wspierany w mało przenośny
sposób aby wydajnie programować.

do góry

W dniu 2016-02-05 o 18:47, Sebastian Biały pisze:

> Przy czym zaznaczam że czasami harvardowatość jest ukryta przed kodem
> usera. Mówimy o procesorach gdzie jest to widoczne, jak na przykład AVR.
> Tam jezyk C z definicji bedzie musiał być wspierany w mało przenośny
> sposób aby wydajnie programować.

Hmm... O jakich aspektach kodu pod AVR tutaj mówimy?

do góry

W dniu 05.02.2016 o 21:22, Atlantis pisze:
> W dniu 2016-02-05 o 18:47, Sebastian Biały pisze:
>
>> Przy czym zaznaczam że czasami harvardowatość jest ukryta przed kodem
>> usera. Mówimy o procesorach gdzie jest to widoczne, jak na przykład AVR.
>> Tam jezyk C z definicji bedzie musiał być wspierany w mało przenośny
>> sposób aby wydajnie programować.
>
> Hmm... O jakich aspektach kodu pod AVR tutaj mówimy?
>

AVR ma oddzielną pamięć programu i danych co powoduje, że np do
odczytania bajtu z pamięci programu (która ma szynę 16-bitową) służy
inny rozkaz procesora niż do czytania bajtu z pamięci danych z szyną
8-bitową. Czyli jeśli z poziomu języka wyższego poziomu chcesz np.
wyświetlić jakiś napis, to masz dwie różne definicje łańcucha
określające w jakiej pamięci ma być umieszczony i dwie różne procedury
do wyświetlania tego łańcucha w zależności gdzie był umieszczony. W
AVRGCC jest specjalny typ wskaźnikowy do stałych umieszczonych w pamięci
programu.
Przy architekturze von Neumanna nie ma rozdzielenia pamięci danych od
pamięci programu. O tym czy procesor widzi pamięć w danej chwili kostkę
RAM, EPROM czy rejestr jakiegoś I/O decyduje dekoder adresów. Procek
może wykonywać rozkazy umieszczone w dowolnym obszarze przestrzeni
adresowej. Z punktu widzenia języka wysokiego poziomu w rodzaku C taki
sam wskaźnik char* może wskazywać na jakiś fragment kodu programu, daną
czy rejestr układu I/O.

--
Pozdrawiam
Grzegorz

do góry

On 2016-02-06 00:08, Grzegorz Kurczyk wrote:
[...]
> AVR ma oddzielną pamięć programu i danych co powoduje, że np do
Tak dla uściślenia: MCU oparte o architekturę von Neumanna również mają
oddzielne pamięci programu i danych ponieważ ta pierwsza jest zazwyczaj
pamięcią nieulotną, a ta druga jest RAM-em. Chodzi o to, że w
(zmodyfikowanej bądź nie) architekturze harwardzkiej pamięci danych i
programu znajdują się w różnych przestrzeniach adresowych, a w
architekturze von Neumanna te pamięci znajdują się w jednej, wspólnej
przestrzeni adresowej. Z tego wynikają różne zady i walety tych
architektur. W każdym razie rzeźbienie w C na MCU o architekturze
harwardzkiej to trochę ból w dupie.

do góry

W dniu 2016-02-06 o 00:08, Grzegorz Kurczyk pisze:

> Czyli jeśli z poziomu języka wyższego poziomu chcesz np. wyświetlić
> jakiś napis, to masz dwie różne definicje łańcucha określające w jakiej
> pamięci ma być umieszczony i dwie różne procedury do wyświetlania tego
> łańcucha w zależności gdzie był umieszczony.

To jest oczywiste i faktycznie - jeśli biblioteka pisana pod AVR często
korzysta z PROGMEM, to potem jej przeniesienie na PIC32 (albo nawet
ośmiobitowe PIC-e, z uwagi na inną obsługę stałych we flashu) potrafi
być nieco kłopotliwe. Niemniej nie jest to czymś, co wymagałoby jakiejś
długiej nauki i zrozumienia skomplikowanych treści. ;)

do góry

On Sat, 6 Feb 2016 08:22:32 +0100, Atlantis <m...@w...pl>
wrote:
> To jest oczywiste i faktycznie - jeśli biblioteka pisana pod AVR
często
> korzysta z PROGMEM, to potem jej przeniesienie na PIC32 (albo nawet
> ośmiobitowe PIC-e, z uwagi na inną obsługę stałych we flashu)
potrafi
> być nieco kłopotliwe.

Dlaczego? Wystarczy zrobić
#define PROGMEM
i atrybut będzie zignorowany. Zobacz w Compiler.h jak to jest
zrobione, ten sam kod w MLA może być kompilowany przez kompilatory
8/32 bit.Dla pic32 tego typu atrybuty stają się wtedy przezroczyste.

--
Marek

do góry

On 2016-02-06 10:48, Marek wrote:
> Dlaczego? Wystarczy zrobić
> #define PROGMEM

A co zrobisz z pgm_read_float, pgm_read_byte i okolicą?

do góry