Różnice w programowaniu mikrokontrolerów AVR, PIC, ARM7/ARM9 i STM32 w C/C++

Sat Feb 06, 2016 8:19 pm   

On Sat, 6 Feb 2016 11:18:29 +0100, Sebastian
Biały<heby@poczta.onet.pl> wrote:

Po co to, nie można tam wskaźnikiem lub tablicą?

--
Marek

Sat Feb 06, 2016 8:48 pm   

On 2016-02-06 20:19, Marek wrote:

Obsluga pamięci ROM i RAM wymaga dwóch różnych instrukcji maszynowych.
Dlatego istnieją makra i funkcje, ktore wymuszają traktowanie pointera
do ROM a nie RAM. W harvardach ktore mają jeden typ wskaźnika (wiele
ARMów) to zadanie wykonywane jest przez hardware dekodera adresów. W AVR
nie ma takiego dekodera i kod sam decyduje czy wskaźnik jest do ROM czy
RAM. To powoduje że sprawy nie da się łatwo załatwić makrem przy
deklaracji pointera. Trzeba również w miejscu użycia wskazać do czego
ten pointer jest.

Sun Feb 07, 2016 2:20 am   

On Sat, 6 Feb 2016 20:48:17 +0100, Sebastian
Biały<heby@poczta.onet.pl> wrote:


Ale to ja wiem, odpowiedz nie na temat.
Pytam po co te pgm_costam?
Jak user chce tabklice we flash to ustawia, jej specjalny atrybut
przy definicji/deklaracji i to wszystko. A dalejj czyta ją przez
tab[ndex] lub przez wskaźnik.
Wewnetrznie kompilator wie z jakim rodzajem pamięci ma do czynienia
i stosuje odpowiednie instrukcje.
A jak chce się skompilować czymś co nie odróżnia atrybutów flash/ram
robi się #define atrybut , który go "znika".
Tak jest w picach. W ten sposób można swobodnie kompilować kod na
architekturę, która nie odróżnia fkash/ram (np. z pic18 na pic32}.

--
Marek

Sun Feb 07, 2016 8:28 am   

On Sat, 6 Feb 2016 00:08:06 +0100, Grzegorz Kurczyk
<grzegorz.skasuj@control.usun.slupsk.pl> wrote:

Intel x86 też ma oddzielnie segmenty kodu i danych. I co? I jakoś z
tym żyjemy.


Intel x86 też ma oddzielne instrukcje mov i in.

Sun Feb 07, 2016 10:20 am   

On 2016-02-07 08:28, slawek wrote:

Nie. Mówisz o tym że x86 ma idiotyczny sposób uzywania wskaźników. Ale
mimo tego idiotyzmu wskaźnik 0x1234:5678 jednoznacznie wskazuje na
konkretna dana w konkretnej pamięci.

W przypadku AVR posiadanie wskaźnika 0x1234 uniemozliwia zgadnięcie czy
to jest wskaźnik do ROM (adresowane od 0) czy do RAM (adresowane od 0).
Dopiero fizyczna instrukcja ładowania danej określa jak go traktować.


Ale dotyczą one mało użytecznego mechanizmu I/O odziedziczonego jeszcze
po 8080 gdzie niezwykle rzadko mówi się o "wskaźniku na rejestr IO".
Raczej o ideksie. Pomińmy milczeniem wygłupy firmy Intel z okolic 8080
które miały zaoszczędzić na mmu po stronie implementacji. To głupie
było. Inne procki z tamtych lat (np 6502) nie miały oddzielnej "pamięci
IO" i świat się kręcił.

PS. Podpieranie się że x86 to von Neumann to troche zabawne jest, bo to
procesor który nie da się chyba sklasyfikować z powodu swoich
idiotyzmów. Weź 680x0 jako bardziej wzorcowy

Sun Feb 07, 2016 10:43 am   

On 2016-02-07 02:20, Marek wrote:

Ponieważ o ile pamietam dla gcc pointer jest tylko "wartością" i nie
zawiera innych znaczeń. To ogranieczenie pochodzi z faktu że developing
gcc odbywał się na w miarę normalnych architekturach gdzie nie był to
kłopot i tak zostało.

Problem tak naprawde nie jest w gcc tylko w C/C++ (np wskaźnik na
funkcje nie jest kompatybilny z void* [1] co jest zrobione m.in. z
powodu jakiś dziwacznych architektur).


Nie wie. Byly próby aby się dowiedział w postaci propozycji zmiany.
Zdaje się że nie udało się wpuscić tego do mainstream, spodziewam się że
takie ficzery trafią wcześniej do clang. Nie mogę teraz znaleźć pdfa
który tą zmianę prezentował, jak znajdę to go tu wrzucę.

[1]
http://stackoverflow.com/questions/12358843/why-are-function-pointers-and-data-pointers-incompatible-in-c-c

Sun Feb 07, 2016 11:28 am   

Dnia Sat, 6 Feb 2016 00:08:06 +0100, Grzegorz Kurczyk napisał(a):

Przy czym zauwaz, ze to jest luzno zwiazane z "harvardowoscia".

Osobna pamiec programu ... program w C w zasadzie programu nie rusza,
a tam gdzie rusza (adres funkcji), tam kontekst jest z gory ustalony.

Problemem sa dane przechowywane w pamieci programu.
Cos w zasadzie sprzeczne z harwardowoscia :-)

C sie z tym boryka od dawna - byl chocby segment danych
niezainicjowanych i zainicjowanych czy nawet stalych.

Oczywiscie w uC przez dlugi czas bylo malo pamieci, co zachecalo do
uzycia ROM, z drugiej strony ROM jest wolny, a RAM szybki, co zacheca
do przepisania programu do RAM. Nawet jesli to specjalny RAM,
wydzielony tylko na program :-)


Harvard Harvardem, ale w co bardziej uniwersalnych systemach jest
potrzeba aby program tworzyl program do wykonania w RAM, czy nawet
zaczytywal go z dysku. I dostep do pamieci programu musi byc, nawet
jesli to pamiec specjalna.

J.

Sun Feb 07, 2016 11:30 am   

Dnia Sat, 6 Feb 2016 11:18:29 +0100, Sebastian Biały napisał(a):

#define na najprostsza konstrukcje "zwyklego C" ?

J.

Sun Feb 07, 2016 11:39 am   

Dnia Sun, 07 Feb 2016 02:20:45 +0100, Marek napisał(a):

No przeciez wiesz - zeby program w C wiedzial, gdzie czytac


No w zasadzie tak. Moze to poklosie wczesniejszych czasow, gdy
kompilator byl glupszy ?
A moze jednak ma zalety, takie bezposrednie podkreslenie, ze tu jest
cos inaczej, a nie - zdefiniowane trzy strony wczesniej.

J.

Sun Feb 07, 2016 12:22 pm   

On 2016-02-07 11:30, J.F. wrote:

Pytanie co zrobisz gdy portujesz harvard->harvard i obie implementacje
radośnie wymysliły własny lepszy sposób na grzebanie w rom.

Sun Feb 07, 2016 12:57 pm   

W dniu 2016-02-07 o 02:20, Marek pisze:

pgr_read_xxx(tab[index]), to jest konsekwencja innego dostępu do pam
programu która pokrywa się adresami z pamięcią ram.





--
Pozdr

Janusz_K

Sun Feb 07, 2016 1:03 pm   

W dniu 2016-02-07 o 08:28, slawek pisze:

To kompilator ma a nie procek, x86 od zawsze miały wspólną przestrzeń
danych i programu. Te segmenty są na siłę robione i to dopiero ostatnimi
czasy jak się pojawiły wirusy korzystające z przepełnienia
stosu.


we/wy "in", bo jak na razie to mieszasz pojęcia.

--
Pozdr

Janusz_K

Sun Feb 07, 2016 1:05 pm   

On Sun, 7 Feb 2016 12:57:03 +0100, janusz_k <Janusz_kk@o2.pl> wrote:

Pisałem ogólnie o kompilatorach, np. sdcc umie, stąd nie widziałem,
że gcc-avr ma z tym problem, ale już Sebastian wyłuszczył dlaczego.

--
Marek

Sun Feb 07, 2016 8:06 pm   

W dniu 2016-02-07 o 10:43, Sebastian Biały pisze:

GCC jakiś czas temu nauczyło się rozróżniać przestrzenie adresowe:
https://gcc.gnu.org/onlinedocs/gcc/Named-Address-Spaces.html

Sun Feb 07, 2016 8:39 pm   

On 2016-02-07 20:06, Zbych wrote:

To nie wystarczy. Np. w przypadku AVR każda funkcja przyjmująca wskaźnik
musiala by się generować osobno dla każdej kombinacji typów
wskaźnikowych jakie w programie wystąpią. Dlatego nalezy użyć __flash
przy wskaźnikowym argumencie funkcji, czyli znowu wychodzi na to że bez
rękodzieła ani rusz.