On 2016-01-29 18:13, Marek wrote:
> On Fri, 29 Jan 2016 17:32:47 +0100, Sebastian Biały<h...@p...onet.pl>
> wrote:
>> A PIC32 to nie jest zwykły MIPS i MC może sobie co najwyżej
> pogrozić
>> paluszkiem?
>
> Ale musieli do gcc dodać parę rzeczy, co natywne gcc do mpisa nie
> wygeneruje w wymikowym pliku bo nie zna "obudowy" arch. pic32 do
> mipsowego core'a a dystrybucja jest binarna.
A czego taki standardowy gcc dla MIPS miałby nie wygenerować? Bo IMO
obudowa core'a to są zasadniczo peryferia, a te są po prostu widoczne
jako zestaw adresów. No chyba że dodali do gcc jakieś swoje builtin
functions, ale to jest do obejścia.

do góry

On 2016-01-29 18:07, JDX wrote:
>> A PIC32 to nie jest zwykły MIPS i MC może sobie co najwyżej pogrozić
>> paluszkiem?
> No PIC32MX to jest niezwykły MIPS bo bez MMU. :-) PIC32MZ już mają MMU.

No to tym lepiej.

do góry

On Fri, 29 Jan 2016 18:31:10 +0100, JDX <j...@o...pl> wrote:
> A czego taki standardowy gcc dla MIPS miałby nie wygenerować? Bo IMO
> obudowa core'a to są zasadniczo peryferia, a te są po prostu
widoczne
> jako zestaw adresów. No chyba że dodali do gcc jakieś swoje builtin
> functions, ale to jest do obejścia.

Nie tylko chodzi o wygenerowanie mipsowych elfów ale gcc musi
rozumieć kod źródłowy chatakterystyczny dla pic32 tj. #pragmy
charakterystyczne dla pic32 (np. bity konfiguracyjne), definicję
priorytetów i przerwań prefix "ISR", itp.
Widzę też microchipowe zmiany w oryginalnym
gcc/gcc/config/mips/mips.c, dot. maskowania przerwań, obsługi cache
oraz CP0.

"Czysty" gcc mips do pic32 używa Sergiejj w swoim projekcie retrobsd
do komoilacji kodu programów uruchamianych w user space.

--
Marek

do góry

On 2016-01-29 22:37, Marek wrote:
[...]
> Nie tylko chodzi o wygenerowanie mipsowych elfów ale gcc musi rozumieć
> kod źródłowy chatakterystyczny dla pic32 tj. #pragmy charakterystyczne
> dla pic32 (np. bity konfiguracyjne)
A to nie można załatwić tego softem programatora albo skryptem linkera?
Przecież to jest wpisanie odpowiednich liczb pod odpowiednie adresy
podczas programowania Flasha. Jestem sceptyczny wobec takich pragm. Z
jednej strony ułatwiają życie, a z drugiej wprowadzają zamieszanie. W
każdym razie IMO można bez nich żyć.

> definicję priorytetów i przerwań
A to nie jest coś w stylu "IPC0SET = 0x00000008;" czyli zwykłe wpisanie
odpowiednich liczb pod odpowiednie adresy które można znaleźć w manualu?

> prefix "ISR", itp.
IMO zbędne rokokoko - atrybut interrupt powinien wystarczyć:
https://gcc.gnu.org/onlinedocs/gcc/MIPS-Function-Att
ributes.html#MIPS-Function-Attributes

> Widzę też microchipowe zmiany w oryginalnym gcc/gcc/config/mips/mips.c,
> dot. maskowania przerwań, obsługi cache oraz CP0.
No, a to już wydaje się być ciekawszym i potencjalnie bardziej istotnym
zagadnieniem.

do góry

On Fri, 29 Jan 2016 23:43:50 +0100, JDX <j...@o...pl> wrote:
> A to nie można załatwić tego softem programatora albo skryptem
linkera?
> Przecież to jest wpisanie odpowiednich liczb pod odpowiednie adresy
> podczas programowania Flasha.

W Mchp konfiguracja "fuse bitów" zawsze była w kodzie progranu, nigdy
na zewnątrz. De facto ta pragrama robi to co opisałeś, deklaruje
wpisanie odpowiedbich wartości pod odpowiednie adresy.
Kiedyś w sdcc/pic konfigurowało się fuse bity nie przez pragmę ale
przez def. tablicy allokowanej pod zafixowanyn adresem. Później
zmieniono to na zgodne z "Mchp way" (z C18) czyli przez pragmę.

> Jestem sceptyczny wobec takich pragm. Z
> jednej strony ułatwiają życie, a z drugiej wprowadzają zamieszanie.
W
> każdym razie IMO można bez nich żyć.

A jak zdefinjujesz ramfunc? Coś czego mips i C "nie widzi". Chciałbyś
przez attribute? Prawdopodobnie by się dało.


> A to nie jest coś w stylu "IPC0SET = 0x00000008;" czyli zwykłe
wpisanie
> odpowiednich liczb pod odpowiednie adresy które można znaleźć w
manualu?

To jest określenie priorytetu w kontrolerze przerwań danego źródła.
Musi być jeszcze przypisany vector z tym priorytetem i odpowuednim wg
priorytetu zestawem shadow registers, tego przez (pseudo)rejestr nie
zrobisz. To musi wygenerować kompilator gdy napotka definiicję
pezrwania wraz z jej atrybutami.

--
Marek

do góry

On 2016-01-30 02:18, Marek wrote:
[...]
> A jak zdefinjujesz ramfunc? Coś czego mips i C "nie widzi".
> Chciałbyś przez attribute? Prawdopodobnie by się dało.
Nie bardzo rozumiem co masz na myśli ponieważ AFAIK ramfunc jest właśnie
atrybutem który można przypisać funkcji. Ewentualnie można to chyba
zrobić w ortodoksyjny sposób, tj. za pomocą section:
__attribute__((section(".ramfunc"))) int foo(void);


> Musi być jeszcze przypisany vector z tym priorytetem i odpowuednim
> wg priorytetu zestawem shadow registers, tego przez (pseudo)rejestr
> nie zrobisz. To musi wygenerować kompilator gdy napotka definiicję
> pezrwania wraz z jej atrybutami.
Również nie bardzo rozumiem. Przecież to właśnie robi atrybut interrupt
i powiązane z nim inne atrybuty.

do góry

On Sat, 30 Jan 2016 09:07:36 +0100, JDX <j...@o...pl> wrote:
> Również nie bardzo rozumiem. Przecież to właśnie robi atrybut
interrupt
> i powiązane z nim inne atrybuty.

Nie bądź teraz taki cwany, po co wcześniej proponowałeś priorytet
przez rejestr, skoro około się teraz nagle, że jednak _wiesz_, że do
tego też są potrzebne i tak atrybuty??

Ja piszę z głowy i nie pamietam takich szczegółów czy to się robiło
przez pragme czy atrybuty. Dyskusja była po co patche Mchp do mipsa.
Po coś jednak są. Jak się ne podoba zawsze możesz używać do pic32
natywnego gcc do mipsa, wolny wybór:)

--
Marek

do góry

On 2016-01-30 11:36, Marek wrote:
[...]
> Nie bądź teraz taki cwany, po co wcześniej proponowałeś priorytet
> przez rejestr, skoro około się teraz nagle, że jednak _wiesz_, że do
> tego też są potrzebne i tak atrybuty??
Ustawienie priorytetu przerwania i wygenerowanie odpowiedniego kodu
procedury obsługi tego przerwania to zupełnie inne sprawy. To pierwsze
to najzwyklejsza instrukcja przypisania języka C, a to drugie to
używanie niestandardowych rozszerzeń języka C w celu poinformowania
kompilatora aby ten wygenerował odpowiedni entry/exit code ISR-a. I IMO
problem jest w tym, że MC w swojej wersji gcc uczynił je jeszcze
bardziej niestandardowymi niczego nowego przy tym nie wnosząc.

> Dyskusja była po co patche Mchp do mipsa.
Zgadza się.

> Po coś jednak są.
Otóż to! Tak naprawdę to po co one są? :-D Bo IMO z punku widzenia
kodera niewiele pomagają, a wprowadzają niepotrzebne zamieszanie. Być
może to wprowadzenie "nowej jakości" (w połączeniu z dodaniem licence
manager-a) to po prostu próba naciągnięcia klientów na dodatkową kasę.

> Jak się ne podoba zawsze możesz używać do pic32 natywnego gcc do
> mipsa, wolny wybór:)
No właśnie. Ja twierdzę, że do programowania PIC32 można śmiało używać
standardowego gcc. Budowanego samodzielnie lub ściągniętego np. od Mentora.

do góry

On Sat, 30 Jan 2016 12:20:41 +0100, JDX <j...@o...pl> wrote:
> No właśnie. Ja twierdzę, że do programowania PIC32 można śmiało
używać
> standardowego gcc.

Chyba softu do migania ledami. Mchp udostępnia kupę softu (stos usb,
stos tcp) , który nie opłaca się pisać od nowa, bo to by móc
skompilować go native gcc mips (a soft ma cechy umożliwiające
skompilowanie go tylko mchp gcc).
Podalem przykład, ze Mchp zmodyfikował target mpis.c dziwnymi
zmianami. Więc coś hardwerowego jest na rzeczy.

Ale chętnie obejrzę przykłady działających (bin)toolsów z native gcc
do pic32, z porządnym i kompletnym libc, umożliwiających oczywiście
wygenerowanie hexa.

> Budowanego samodzielnie lub ściągniętego np. od Mentora.

Co to jest Mentor? Jedyny projekt jaki znam tworzony z native gcc to
retrobsd i to wcale nie jestem pewien czy 100% nie było użycia mchp
gcc gdzieś na jakimś etapie.
Ale efekt jest taki, że powastał os sztuka dla sztuki, o zerowej
przydatności praktycznej o ekonomicznej nie wspominając. Przepraszam,
jest jeden uboczny pożytek z tego, pic32prog dla pickit2.

--
Marek

do góry

On 2016-01-30 13:27, Marek wrote:
> On Sat, 30 Jan 2016 12:20:41 +0100, JDX <j...@o...pl> wrote:
>> No właśnie. Ja twierdzę, że do programowania PIC32 można śmiało
> używać
>> standardowego gcc.
>
> Chyba softu do migania ledami. Mchp udostępnia kupę softu (stos usb,
> stos tcp) , który nie opłaca się pisać od nowa, bo to by móc skompilować
> go native gcc mips (a soft ma cechy umożliwiające skompilowanie go tylko
> mchp gcc).
Bez przesady, jestem przekonany, że nie byłoby specjalnie trudnym
przeportowanie tych bibliotek na standardowe gcc. O ile ktoś chciałby
ich używać. Bo kiedyś słyszałem, chociaż nie w kontekście PIC32, że
mikroczipowy stos TCP/IP zaburaczony jest/był. A z drugiej strony np. ja
mam dobre doświadczenia z lwIP.

> Podalem przykład, ze Mchp zmodyfikował target mpis.c dziwnymi zmianami.
> Więc coś hardwerowego jest na rzeczy.
A możesz zapodać diff-a? Bo chętnie rzuciłbym okiem, ale nie chce mi się
zasysać źródeł i porównywać.

> Co to jest Mentor?
Hę??? https://www.mentor.com

> Ale efekt jest taki, że powastał os sztuka dla sztuki, o zerowej
> przydatności praktycznej o ekonomicznej nie wspominając.
Przypomnę, że ta dyskusja zaczęła się od tego, że MC zrobił swoje gcc i
w darmowej wersji tego kompilatora wprowadził pewne ograniczenia i czy
nie dałoby się zastąpić tego kompilatora standardowym gcc dla MIPS-a.
Czytaj: w zastosowania amatorskich. A tak BTW to owa "sztuka dla sztuki"
ma IMO duże znaczenie edukacyjne. Co IMO przekłada się też na kasę.

do góry