A jak wygląda kwestia układów ARM od różnych producentów? Istnieje jakiś
standaryzowany sposób obsługi peryferiów, czy każdy producent narzuca
swoje własne rozwiązania, w związku z czym nazwy i zawartość
rejestrów/struktur są różne?
Obsługa GPIO (z punktu widzenia kodu C) będzie podobna w takim LPC2000 i
AT92SAM7, czy też będzie się całkowicie różnić?

do góry

On 2016-02-06 13:26, Atlantis wrote:
> A jak wygląda kwestia układów ARM od różnych producentów?

Mają zbliżoną architekturę CPU i zupełnie różne peryferia.

> Istnieje jakiś
> standaryzowany sposób obsługi peryferiów

Nie. W miarę standardowy masz w jakiejś rodzinie. Bywa że wersja binarna
kodu nie wymaga zmian po przeniesieniu na sąsiada. To głównie zasługa
faktu że przestrzeń adresowa jest na tyle spora że nie trzeba co nową
wersję pakować po nowemu IO.

do góry

A jak wygląda kwestia programatorów?
STM32, STR91x, LPC2000, LPC1000, AT91SAM7, ATM91SAM9 i inne MCU na
rdzeniach ARM/Cortex można programować i debugować jakimś jednym,
standardowym JTAG-iem, czy też każdy producent/rodzina ma swoje własne,
unikalne narzędzie?

do góry

W dniu 2016-02-06 o 13:26, Atlantis pisze:
> A jak wygląda kwestia układów ARM od różnych producentów? Istnieje jakiś
> standaryzowany sposób obsługi peryferiów, czy każdy producent narzuca
> swoje własne rozwiązania, w związku z czym nazwy i zawartość
> rejestrów/struktur są różne?
> Obsługa GPIO (z punktu widzenia kodu C) będzie podobna w takim LPC2000 i
> AT92SAM7, czy też będzie się całkowicie różnić?
>

Cortexy mają taką próbę standaryzacji - Cortex(R) Microcontroller
Software Interface Standard (CMSIS).

--
pozdrawiam
MD

do góry

W dniu 2016-02-06 o 15:29, Atlantis pisze:
> A jak wygląda kwestia programatorów?
> STM32, STR91x, LPC2000, LPC1000, AT91SAM7, ATM91SAM9 i inne MCU na
> rdzeniach ARM/Cortex można programować i debugować jakimś jednym,
> standardowym JTAG-iem, czy też każdy producent/rodzina ma swoje własne,
> unikalne narzędzie?
>

Różnie. Każdy producent ma jakąś swoją firmę softwarową, która robi
środowisko deweloperskie, zestawy uruchomieniowe i programatory dla
danego producenta ARMów. Oprócz tego jest kilka firm robiących robiących
takie rzeczy dla różnych producentów, ale podejrzewam ze nie mają
jednego uniwersalnego programatora. Oprócz tego masz OpenOCD który
współpracuje z różnymi programatorami, z których znaczna część to klony
JtagKey Amonteca.
Polecam OpenOCD. Ja dzięki niemu używam Jtag-Lock_Pick (Freddiego) do
programowania Armów NXP i FPGA Xilinxa.

--
pozdrawiam
MD

do góry

On Sat, 6 Feb 2016 11:18:29 +0100, Sebastian
Biały<h...@p...onet.pl> wrote:
> A co zrobisz z pgm_read_float, pgm_read_byte i okolicą?

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

--
Marek

do góry

On 2016-02-06 20:19, Marek wrote:
>> A co zrobisz z pgm_read_float, pgm_read_byte i okolicą?
> Po co to, nie można tam wskaźnikiem lub tablicą?

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.

do góry

On Sat, 6 Feb 2016 20:48:17 +0100, Sebastian
Biały<h...@p...onet.pl> wrote:
> Obsluga pamięci ROM i RAM wymaga dwóch różnych instrukcji
maszynowych.

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

do góry

On Sat, 6 Feb 2016 00:08:06 +0100, Grzegorz Kurczyk
<g...@c...usun.slupsk.pl> wrote:
> AVR ma oddzielną pamięć programu i danych co powoduje, że np do

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

> 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ą

Intel x86 też ma oddzielne instrukcje mov i in.

do góry

On 2016-02-07 08:28, slawek wrote:
>> AVR ma oddzielną pamięć programu i danych co powoduje, że np do
> Intel x86 też ma oddzielnie segmenty kodu i danych. I co? I jakoś z tym
> żyjemy.

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ć.

>> 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ą
> Intel x86 też ma oddzielne instrukcje mov i in.

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 ;)

do góry