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
Marek
Guest
Guest
Fri Jan 29, 2016 2:14 pm
On Fri, 29 Jan 2016 11:25:47 +0100, Piotr Wyderski
<peter.pan@neverland.mil> wrote:
Quote:
Antyczne 16F miewają niezwykle użyteczne peryferia, a to przecież
dla
nich się stosuje 8-bitowce.
dla
nich się stosuje 8-bitowce.
Co nadal nie zmienia faktu, że corowo są daleko w tyle za atmegą. Mi
chodzi tylko o to, by z nierzetelnyvh porównań nie tworzyć
powszechnie funkcjonującej błędnej oceny. User obeznany z atmega
słyszy "pice mają fajne peryferia".Zaciekawiony zaczyna googlać,
najczęściej trafi w sieci na projekty z archaicznymi 16F (dlaczego -
o tym niżej). No to realizuje swój projekt na 16F. Przyzwyczajony do
architektury z atmegi mocno się rozczaruje napotykając na archaizmy
architektury. Później po rozczarowaniu będzie gadał, że pice
(wszystkie 8bitowe) są do bani. Nie, to 16F są do bani. 18F są od
nich lepsze, nie tylko corowo ale i peryferiami.
Dlaczego 8bitowy pic kojarzy się głównie z 16F? A to już efekt durnej
polityki Mchp. Brak darmowych dobrych narzedzi do programowania 18F
powoduje, że nie ma parcia na ich zastosowanie. A płatne (XC8) w
wersji limitowanej-darmowej generują celowo dummy instructions by
spowolnić kod (!). Starsi przyzwyczajeni do pic tkwią w 16F i przez
to generują powszechną świadomość, że pic 8bitowy to 16F.
--
Marek
JDX
Guest
Guest
Fri Jan 29, 2016 2:49 pm
On 2016-01-29 13:07, Piotr Wyderski wrote:
[...]
Quote:
Microchip jednak robi
No ale MC w DIP28 robi MIPS-y a nie ARM-y. Chociaż z drugiej strony to
No ale MC w DIP28 robi MIPS-y a nie ARM-y. Chociaż z drugiej strony to
prawie "the same shit". :-)
Quote:
i fakt kto kogo kupuje pokazuje, że to oni mają rynkowo rację. 
Znaczy się MC kupuje ARM-a?
Znaczy się MC kupuje ARM-a?
BTW Proszę bardzo, Cortex-M0 w DIP8:
http://www.nxp.com/products/microcontrollers-and-processors/arm-processors/lpc-arm-cortex-m-mcus/lpc-cortex-m0-plus-m0/lpc800-series/32-bit-arm-cortex-m0-plus-microcontroller-4-kb-flash-and-1-kb-sram:LPC810M021FN8
Piotr Wyderski
Guest
Guest
Fri Jan 29, 2016 3:55 pm
Marek wrote:
Quote:
Co nadal nie zmienia faktu, że corowo są daleko w tyle za atmegą.
Owszem, ale chyba nikt poważny nie uważa, że AVR czy 16F to Pentium.
A dzieciarnia niech się podnieca mikroskopijną tak czy inaczej mocą
obliczeniową, uparcie nie chcąc przy tym zauważyć, że nie po to te
mikrokontrolery są.
Quote:
A to już efekt durnej polityki Mchp
A to już mi się w głowie nie mieści, ale cóż... to oni kupują Atmela
mającego port GCC, a nie odwrotnie. :-)
Pozdrawiam, Piotr
Sebastian BiaĹy
Guest
Guest
Fri Jan 29, 2016 4:53 pm
On 2016-01-29 11:28, Atlantis wrote:
Quote:
Tak się zastanawiam, czy ten MCU ma jeszcze jakieś istotne miejsce na
rynku? Ktoś realizuje na nim jakieś projekty?
rynku? Ktoś realizuje na nim jakieś projekty?
Przecież oczywiście! Niby na podstawie czego ostatnio w mediach przelał
się entuzjazm zwiazany z pewna firmą z Bytomia i ich wizjonerskim
procesorem do szybszego migania didoami w projektach z lat 70? Jeszcze
troche i wznowią MCY7880 z zegarem 4GHz. Czekamy.
Marek
Guest
Guest
Fri Jan 29, 2016 5:28 pm
On Fri, 29 Jan 2016 15:55:06 +0100, Piotr Wyderski
<peter.pan@neverland.mil> wrote:
Quote:
A to już mi się w głowie nie mieści, ale cóż... to oni kupują Atmela
mającego port GCC, a nie odwrotnie.
mającego port GCC, a nie odwrotnie.
Mchp popsucie gcc też niestraszne. Przecież do pic32 zrobili port gcc
po czym do kodu gcc dodali licence menager'a aby nie można było bez
opłaty $1000 wywoływać gcc z inną opcją optymalizacyjną niż -O1.
--
Marek
Sebastian BiaĹy
Guest
Guest
Fri Jan 29, 2016 5:32 pm
On 2016-01-29 17:28, Marek wrote:
Quote:
Mchp popsucie gcc też niestraszne. Przecież do pic32 zrobili port gcc po
czym do kodu gcc dodali licence menager'a aby nie można było bez opłaty
$1000 wywoływać gcc z inną opcją optymalizacyjną niż -O1.
czym do kodu gcc dodali licence menager'a aby nie można było bez opłaty
$1000 wywoływać gcc z inną opcją optymalizacyjną niż -O1.
A PIC32 to nie jest zwykły MIPS i MC może sobie co najwyżej pogrozić
paluszkiem?
janusz_k
Guest
Guest
Fri Jan 29, 2016 6:02 pm
W dniu 2016-01-29 o 17:28, Marek pisze:
Quote:
On Fri, 29 Jan 2016 15:55:06 +0100, Piotr Wyderski
peter.pan@neverland.mil> wrote:
A to już mi się w głowie nie mieści, ale cóż... to oni kupują Atmela
mającego port GCC, a nie odwrotnie. :-)
Mchp popsucie gcc też niestraszne. Przecież do pic32 zrobili port gcc po
czym do kodu gcc dodali licence menager'a aby nie można było bez opłaty
$1000 wywoływać gcc z inną opcją optymalizacyjną niż -O1.
Mam nadzieję że tak nie ukatrupią AVR-ów i gcc do nich.
peter.pan@neverland.mil> wrote:
A to już mi się w głowie nie mieści, ale cóż... to oni kupują Atmela
mającego port GCC, a nie odwrotnie. :-)
Mchp popsucie gcc też niestraszne. Przecież do pic32 zrobili port gcc po
czym do kodu gcc dodali licence menager'a aby nie można było bez opłaty
$1000 wywoływać gcc z inną opcją optymalizacyjną niż -O1.
Mam nadzieję że tak nie ukatrupią AVR-ów i gcc do nich.
--
Pozdr
Janusz_K
janusz_k
Guest
Guest
Fri Jan 29, 2016 6:04 pm
W dniu 2016-01-29 o 11:25, Piotr Wyderski pisze:
Quote:
Marek wrote:
Nie. 8bitowiec nie równy 8bitiwcowi. 16F są lata świetlne za atmega.
Wszystkim pic się kojarzy tylko z antycznymi 16F, co teraz pokutuje
przekonaniem, że wszystkie 8bitowce pic są kiepskie.
Antyczne 16F miewają niezwykle użyteczne peryferia, a to przecież dla
nich się stosuje 8-bitowce. Jak ktoś potrzebuje mocy obliczeniowej, to
zastosuje ARM albo coś innego taktowanego 50+MHz, w przeciwnym razie
sam jest sobie winien.
Ale to tylko, cytując kasyka, próby zbudowania "szybszej furmanki",
16F, 18F, AVR, 8051 -- tak czy inaczej będą to wyścigi furmanek.
Nawet sobie nie zdajesz sprawy ile prostych sterowników jest na tym
Nie. 8bitowiec nie równy 8bitiwcowi. 16F są lata świetlne za atmega.
Wszystkim pic się kojarzy tylko z antycznymi 16F, co teraz pokutuje
przekonaniem, że wszystkie 8bitowce pic są kiepskie.
Antyczne 16F miewają niezwykle użyteczne peryferia, a to przecież dla
nich się stosuje 8-bitowce. Jak ktoś potrzebuje mocy obliczeniowej, to
zastosuje ARM albo coś innego taktowanego 50+MHz, w przeciwnym razie
sam jest sobie winien.
Ale to tylko, cytując kasyka, próby zbudowania "szybszej furmanki",
16F, 18F, AVR, 8051 -- tak czy inaczej będą to wyścigi furmanek.
Nawet sobie nie zdajesz sprawy ile prostych sterowników jest na tym
robione, w przemyśle.
--
Pozdr
Janusz_K
JDX
Guest
Guest
Fri Jan 29, 2016 6:07 pm
On 2016-01-29 17:32, Sebastian Biały wrote:
Quote:
On 2016-01-29 17:28, Marek wrote:
Mchp popsucie gcc też niestraszne. Przecież do pic32 zrobili port gcc po
czym do kodu gcc dodali licence menager'a aby nie można było bez opłaty
$1000 wywoływać gcc z inną opcją optymalizacyjną niż -O1.
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.
Mchp popsucie gcc też niestraszne. Przecież do pic32 zrobili port gcc po
czym do kodu gcc dodali licence menager'a aby nie można było bez opłaty
$1000 wywoływać gcc z inną opcją optymalizacyjną niż -O1.
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.Marek
Guest
Guest
Fri Jan 29, 2016 6:13 pm
On Fri, 29 Jan 2016 17:32:47 +0100, Sebastian
Biały<heby@poczta.onet.pl> wrote:
Quote:
A PIC32 to nie jest zwykły MIPS i MC może sobie co najwyżej
pogrozić
paluszkiem?
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. Oczywiście udostępniają
źródła (gpl, wiadomo) ale dla usera windowsowego niezwyczajnego do
kernelowania kompili przekompilowanie gcc 4.* wraz z wymaganymi
zewnętrznymi libami to nie w kij dmuchał.
Na szczęście puścili oko do tych co będą kompilować i w źródłach gcc
licence manager jest dodany w bloku
#ifndef DISABLE_LM
....
#endif
;-)
--
Marek
JDX
Guest
Guest
Fri Jan 29, 2016 6:31 pm
On 2016-01-29 18:13, Marek wrote:
Quote:
On Fri, 29 Jan 2016 17:32:47 +0100, Sebastian Biały<heby@poczta.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
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.
Sebastian BiaĹy
Guest
Guest
Fri Jan 29, 2016 6:55 pm
On 2016-01-29 18:07, JDX wrote:
Quote:
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.
paluszkiem?
No PIC32MX to jest niezwykły MIPS bo bez MMU.
PIC32MZ już mają MMU.
No to tym lepiej.
Marek
Guest
Guest
Fri Jan 29, 2016 10:37 pm
On Fri, 29 Jan 2016 18:31:10 +0100, JDX <jdx@onet.pl> wrote:
Quote:
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.
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
JDX
Guest
Guest
Fri Jan 29, 2016 11:43 pm
On 2016-01-29 22:37, Marek wrote:
[...]
Quote:
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?
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ć.
Quote:
definicję priorytetów i przerwań
A to nie jest coś w stylu "IPC0SET = 0x00000008;" czyli zwykłe wpisanie
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?
Quote:
prefix "ISR", itp.
IMO zbędne rokokoko - atrybut interrupt powinien wystarczyć:
IMO zbędne rokokoko - atrybut interrupt powinien wystarczyć:
https://gcc.gnu.org/onlinedocs/gcc/MIPS-Function-Attributes.html#MIPS-Function-Attributes
Quote:
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
dot. maskowania przerwań, obsługi cache oraz CP0.
No, a to już wydaje się być ciekawszym i potencjalnie bardziej istotnym
zagadnieniem.
Marek
Guest
Guest
Sat Jan 30, 2016 2:18 am
On Fri, 29 Jan 2016 23:43:50 +0100, JDX <jdx@onet.pl> wrote:
Quote:
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.
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ę.
Quote:
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ć.
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.
Quote:
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?
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
elektroda NewsGroups Forum Index - Elektronika Polska - Mikryczip przejmuje Atmela co to oznacza dla branży technologicznej?