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.
No to tym lepiej.
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.
On 2016-01-29 22:37, Marek 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. 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 to nie jest coś w stylu "IPC0SET = 0x00000008;" czyli zwykłe wpisanie odpowiednich liczb pod odpowiednie adresy które można znaleźć w manualu?
IMO zbędne rokokoko - atrybut interrupt powinien wystarczyć:
No, a to już wydaje się być ciekawszym i potencjalnie bardziej istotnym zagadnieniem.
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ę.
A jak zdefinjujesz ramfunc? Coś czego mips i C "nie widzi". Chciałbyś przez attribute? Prawdopodobnie by się dało.
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.
On 2016-01-30 02:18, Marek wrote: [...]
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);
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:)
On 2016-01-30 11:36, Marek wrote: [...]
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.
Zgadza się.
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ę.
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.
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.
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.
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.
A możesz zapodać diff-a? Bo chętnie rzuciłbym okiem, ale nie chce mi się zasysać źródeł i porównywać.
Hę???
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ę.
Używam na codzień mchp tcpip, nie narzekam więc niem mam parcia na IwIP. Co interesującego ma IwIP w porównaniu do mchp?
Nie widzę nigdzie tam otwartych toolsów do pic32 mogących być alternatywą.
Diffa wyślę wieczorem.
Nie wiem bo nie używam TCP/IP Microchipa. :-) LwIP zacząłem używać w
2006 r., a o stosie MC mało kto wtedy słyszał. O ile w ogóle był wtedy dostępny, bo coś mi się wydaje, że nie był.Nie ma tam toolsów dla PIC32, są tylko dla MIPS-a:
No czym i czym się różnią te z mentora od GNU gcc na target mips?
Diff mips.c gnu gcc 4.5.2 vs Mchp gcc 4.5.2 (xc32 1.33): http://83.220.108.211/bins/gnumipsVSmchp.diff.gz
Uwagi na szybko:
1) duza czesc zmian to inne formatowanie kodu, czyli nic faktycznie nie zmienia 2) gcc 4.5.2 to stara wersja, ze slabym wsparciem dla 16 bitowych instrukcji MIPS. Diff dodaje lepsze wsparcie, podobne zmiany sa w nowszych wersjach gcc 3) jest kosmetyczna zmiana: wersja Microchipa definiuje architekture pic32mx, ten sam efekt daje architektura m4k obecna w oryginalnym gcc 4) inna kosmetyczna zmiana: Microchip pisze 'longcall' jako nazwe atrybutu zamiast 'long_call' 5) wersja Microchipa uzywa inne koszty instrukcji, jesli koszty sa dobrze dobrane to moze dac lepsza optymalizacje 6) wyglada ze Microchip dodal jakies optymalizecje ktorych nie ma w gcc-5.3W porownaniu z gcc-4.5.2 zmiany sa raczej istotne, ale wyglada ze wiekszosc jest w nowszych wersjach gcc. W porownaniu z nowszymi wersjami gcc nie jest jasne czy wersja Microchipa dodaje cos wartosciowego.
Tak a propo: jest normalne ze specjalnie przygotowane wersje zawieraja kod ktory pojawia sie pozniej w oficjalnym gcc. Czasami dzieje sie to dlatego ze autorzy zmian umieszczaja je najpierw w specjalnej wersji a dopiero potem laduja one w glownej wersji. Ale czesto jest tez tak ze wersje specjalne maja kod ktory jest w fazie testowania w wersji oficjalnej (testowanie zwykle trwa okolo roku).
A propo 2: 'diff -bu' pominolby wiekszosc nieistotnuch zmian.
AFAIK to same kompilatory niczym się nie różnią - nie znalazłem żadnych informacji na ten temat. Natomiast otoczka kompilatora jest trochę inna, tzn. Mentor dostarcza własną, zamkniętą niskopoziomową bibliotekę zwaną CodeSourcery Common Startup Code Sequence (w skrócie CS3) oraz odpowiednie skrypty linkera. Biblioteka wspiera "standardowe" zestawy uruchomieniowe Malta i SEAD-3
Dzięki za analizę.
Tak z ciekawości sprawdziłem czy działa -march=pic32mx w mentorowym gcc
5.2. Nie działa. :-)
Znaczy się są testowane na klientach? :-)
Ciekawe jak znalazły się te zmiany w oficjalnym gcc, bo patrząc przez pryzmat polityki jaką stosuje Mchp na pewno nie jest to im na rękę.
Raczej nie: w oficjalnym gcc zmian jest duzo i z wydaniem czeka sie az wszystko w miare dziala. Zmiany dla konkretnej achitektury to maly procent tego. Zmiany w wersjach specjalnych to zwykle "pewniaki" ktore w oficjalnej wersji musza czekac na reszte.
Najprawdopodobniej wiekszosc zmian jest zrobiona przez innych (np. MIPS), a Microchip tylko je uzywa. Choc jest tez mozliwe ze Microchip uznal ze prosciej jest zrobic zmiany w oficjalnym gcc niz bawic sie modyfikowanie kolejnych wersji. W ktoryms momencie gcc 4.5.2 bedzie zupelnie przestarzaly i beda potrzebowali nowej wersji. Jak poczekaja dlugo to zmiany w gcc beda spore i bedzie duzo roboty zeby sie dopasowac. Jak zmiany wyladuja w wersji oficjalnej to developerzy gcc zrobia co trzeba pracujac nad nowymi wersjami...
Co do polityki: licencja Gnu oznacza ze musza wraz z kompilatorem dostarczyc zrodla. To czy ich zmiany trafia do oficjalnego gcc nie zmienia specjalnie sytuacji z oplata za ich wersje.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.