NOWY TEMAT
elektroda NewsGroups Forum Index - Elektronika Polska - Mikryczip przejmuje Atmela co to oznacza dla branży technologicznej?
Goto page Previous 1, 2, 3, 4, 5 Next
JDX
Guest
Guest
Sat Jan 30, 2016 9:07 am
On 2016-01-30 02:18, Marek wrote:
[...]
Quote:
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
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);
Quote:
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
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.
Marek
Guest
Guest
Sat Jan 30, 2016 11:36 am
On Sat, 30 Jan 2016 09:07:36 +0100, JDX <jdx@onet.pl> wrote:
Quote:
Również nie bardzo rozumiem. Przecież to właśnie robi atrybut
interrupt
i powiązane z nim inne atrybuty.
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
JDX
Guest
Guest
Sat Jan 30, 2016 12:20 pm
On 2016-01-30 11:36, Marek wrote:
[...]
Quote:
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
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.
Quote:
Dyskusja była po co patche Mchp do mipsa.
Zgadza się.
Zgadza się.
Quote:
Po coś jednak są.
Otóż to! Tak naprawdę to po co one są?
Bo IMO z punku widzenia
Otóż to! Tak naprawdę to po co one są?
Bo IMO z punku widzeniakodera 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ę.
Quote:
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ć
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.
Marek
Guest
Guest
Sat Jan 30, 2016 1:27 pm
On Sat, 30 Jan 2016 12:20:41 +0100, JDX <jdx@onet.pl> wrote:
Quote:
No właśnie. Ja twierdzę, że do programowania PIC32 można śmiało
używać
standardowego gcc.
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.
Quote:
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
JDX
Guest
Guest
Sat Jan 30, 2016 1:57 pm
On 2016-01-30 13:27, Marek wrote:
Quote:
On Sat, 30 Jan 2016 12:20:41 +0100, JDX <jdx@onet.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
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.
Quote:
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ę
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ć.
Quote:
Co to jest Mentor?
Hę??? https://www.mentor.com
Hę??? https://www.mentor.com
Quote:
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
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ę.
Marek
Guest
Guest
Sat Jan 30, 2016 2:44 pm
On Sat, 30 Jan 2016 13:57:20 +0100, JDX <jdx@onet.pl> wrote:
Quote:
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.
mikroczipowy stos TCP/IP zaburaczony jest/był. A z drugiej strony
np. ja
mam dobre doświadczenia z lwIP.
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?
Quote:
Hę??? https://www.mentor.com
Nie widzę nigdzie tam otwartych toolsów do pic32 mogących być
alternatywą.
Diffa wyślę wieczorem.
--
Marek
JDX
Guest
Guest
Sat Jan 30, 2016 3:13 pm
On 2016-01-30 14:44, Marek wrote:
Quote:
On Sat, 30 Jan 2016 13:57:20 +0100, JDX <jdx@onet.pl> wrote:
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.
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 wiem bo nie używam TCP/IP Microchipa. LwIP zacząłem używać w
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.
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 wiem bo nie używam TCP/IP Microchipa.
LwIP zacząłem używać w2006 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ł.
Quote:
Hę??? https://www.mentor.com
Nie widzę nigdzie tam otwartych toolsów do pic32 mogących być alternatywą.
Nie ma tam toolsów dla PIC32, są tylko dla MIPS-a:
Nie widzę nigdzie tam otwartych toolsów do pic32 mogących być alternatywą.
Nie ma tam toolsów dla PIC32, są tylko dla MIPS-a:
https://sourcery.mentor.com/GNUToolchain/subscription3537?lite=MIPS
Marek
Guest
Guest
Sat Jan 30, 2016 6:59 pm
On Sat, 30 Jan 2016 15:13:10 +0100, JDX <jdx@onet.pl> wrote:
Quote:
Nie ma tam toolsów dla PIC32, są tylko dla MIPS-a:
https://sourcery.mentor.com/GNUToolchain/subscription3537?lite=MIPS
https://sourcery.mentor.com/GNUToolchain/subscription3537?lite=MIPS
No czym i czym się różnią te z mentora od GNU gcc na target mips?
--
Marek
Marek
Guest
Guest
Sat Jan 30, 2016 11:14 pm
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
--
Marek
Waldek Hebisch
Guest
Guest
Sun Jan 31, 2016 5:44 am
Marek <fake@fakeemail.com> wrote:
Quote:
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
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.3
W 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.
--
Waldek Hebisch
JDX
Guest
Guest
Sun Jan 31, 2016 11:39 am
On 2016-01-30 18:59, Marek wrote:
Quote:
On Sat, 30 Jan 2016 15:13:10 +0100, JDX <jdx@onet.pl> wrote:
Nie ma tam toolsów dla PIC32, są tylko dla MIPS-a:
https://sourcery.mentor.com/GNUToolchain/subscription3537?lite=MIPS
No czym i czym się różnią te z mentora od GNU gcc na target mips?
AFAIK to same kompilatory niczym się nie różnią - nie znalazłem żadnych
Nie ma tam toolsów dla PIC32, są tylko dla MIPS-a:
https://sourcery.mentor.com/GNUToolchain/subscription3537?lite=MIPS
No czym i czym się różnią te z mentora od GNU gcc na target mips?
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
(https://community.imgtec.com/developers/mips/resources/development-platforms/)
oraz symulator QEMU. W każdym razie nie ma obowiązku używania tej
biblioteki - w końcu startup code na platformę "bare metal" to nie jest
jakieś wielkie aj-waj i samemu można to napisać (a może nawet nie ma
innej możliwości jeśli sprzęt jest bardzo "zkustomizowany").
JDX
Guest
Guest
Sun Jan 31, 2016 12:01 pm
On 2016-01-31 04:44, Waldek Hebisch wrote:
Quote:
Marek <fake@fakeemail.com> wrote:
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:
Dzięki za analizę.
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:
Dzięki za analizę.
Quote:
Tak a propo: jest normalne ze specjalnie przygotowane wersje
zawieraja kod ktory pojawia sie pozniej w oficjalnym gcc.
Tak z ciekawości sprawdziłem czy działa -march=pic32mx w mentorowym gcc
zawieraja kod ktory pojawia sie pozniej w oficjalnym gcc.
Tak z ciekawości sprawdziłem czy działa -march=pic32mx w mentorowym gcc
5.2. Nie działa. :-)
Quote:
Ale czesto jest tez tak ze wersje specjalne
maja kod ktory jest w fazie testowania w wersji oficjalnej
(testowanie zwykle trwa okolo roku).
Znaczy się są testowane na klientach?
maja kod ktory jest w fazie testowania w wersji oficjalnej
(testowanie zwykle trwa okolo roku).
Znaczy się są testowane na klientach?
Marek
Guest
Guest
Sun Jan 31, 2016 12:15 pm
On Sun, 31 Jan 2016 03:44:54 +0000 (UTC), Waldek Hebisch
<hebisch@math.uni.wroc.pl> wrote:
Quote:
W 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.
ze wiekszosc jest w nowszych wersjach gcc. W porownaniu z
nowszymi wersjami gcc nie jest jasne czy wersja Microchipa
dodaje cos wartosciowego.
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ę.
--
Marek
Waldek Hebisch
Guest
Guest
Sun Jan 31, 2016 3:13 pm
JDX <jdx@onet.pl> wrote:
Quote:
On 2016-01-31 04:44, Waldek Hebisch wrote:
Ale czesto jest tez tak ze wersje specjalne
maja kod ktory jest w fazie testowania w wersji oficjalnej
(testowanie zwykle trwa okolo roku).
Znaczy si? s? testowane na klientach?
Ale czesto jest tez tak ze wersje specjalne
maja kod ktory jest w fazie testowania w wersji oficjalnej
(testowanie zwykle trwa okolo roku).
Znaczy si? s? testowane na klientach?
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.
--
Waldek Hebisch
Waldek Hebisch
Guest
Guest
Sun Jan 31, 2016 3:53 pm
Marek <fake@fakeemail.com> wrote:
Quote:
On Sun, 31 Jan 2016 03:44:54 +0000 (UTC), Waldek Hebisch
hebisch@math.uni.wroc.pl> wrote:
W 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.
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?.
hebisch@math.uni.wroc.pl> wrote:
W 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.
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?.
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.
--
Waldek Hebisch
elektroda NewsGroups Forum Index - Elektronika Polska - Mikryczip przejmuje Atmela co to oznacza dla branży technologicznej?