In the darkest hour on Mon, 9 Mar 2009 19:13:30 +0100,
Nimitz <N...@o...eu> screamed:
>> Zartujesz? AVR moge taktowac zegarem 20MHz, minimalny czas trawania
>> impulsu dla tego wariantu to 100ns, zadna '51 nie odczyta portu z taka
>> rozdzielczoscia. A XMega maja juz taktowanie 32MHz/32 MIPSy.
>
> Wszyscy wiemy, że zwykły 8051 dzieli zegar przez 12, więc jakie to ma
> znaczenie dla programisty? Porównuj 8051 12MHz z AVR 1MHz. Owszem, w
> konsekwencji możemy uzyskać znacznie szybszy AVR, ale do rzetelnego
> porównania muszą być zachowane podobne warunki.
>

Tu odrobinę poniosła Cię fantazja. Skoro miał coś robić szybciej to
powinieneś liczyć to w realnej jednostce czasu.


--
[ Artur M. Piwko : Pipen : AMP29-RIPE : RLU:100918 : From == Trap! : SIG:239B ]
[ 22:51:02 user up 12007 days, 10:46, 1 user, load average: 0.63, 0.04, 0.09 ]

You don't have to know how the computer works, just how to work the computer.

do góry

>> z 51' to znam uPSD 10MIPsów z 40MHz....
> To ciagle 3x mniej.

A ile dokładnie MIPsów potrzebujesz?


> A znasz ARMa w obudowie SO08? Albo SO16?

SO16 to bardzo duża powierzchnia obudowy choć mało nóżek, zamiast tego
zmieszczę bez problemu LFBGA 144piny, albo innym razem TFBGA 64pin
(5mm x 5mm) albo jak wolisz mało nóżek VFQFPN 36 pin (6mm x 6mm)


> Nikt, tylko ze to bez sensu. Ponosisz koszty poznania dwoch rodzin, jesli
> korzystasz z komercyjnych narzedzi to tez musisz za wszystko placic 2x,
> dwie rozne elektroniki, przy komercyjnych narzedziach praktycznie
> nieprzenoszalny kod, czyli piszesz wszystko 2x.

- 2-rodziny to ja już znam a nawet więcej,
- narzędzia nie są aż tak drogie,
- kod bez problemu przenoszalny, i nie piszę "2x"; ale swoją drogą to
ja nie powielam całe życie tego samego produktu w nowych odsłonach,
więc w zasadzie to piszę częściowo kod od nowa


> Owszem, tylko, ze ARMa wszedzie nie wsadzisz, chociazby dlatego, ze
> najmniejsza wystepujaca obudowa jest TQFP64?

patrz wyżej


> Oczywiscie znajomosc jest nie do przecenienia. Tylko, ze ja majac c/C++ z
> libc dla AVRa jestem w stanie napisac program szybciutko z minimalnym
> tylko zaglebianiem sie do datasheeta. Co wiecej ten program latwo
> przeniose np. na ARMa.

> Pytanie czy dla '51 istnieje libc dla kazdego modelu '51? Pliki naglowkowe
> chociazby tylko ze standardowymi definicjami rejestrow?

Jak najbardziej na 51 jest C i też skompiluje się na ARM


z.

do góry

zbyszek pisze:
>>> z 51' to znam uPSD 10MIPsów z 40MHz....
>> To ciagle 3x mniej.
>
> A ile dokładnie MIPsów potrzebujesz?

Skad mam wiedziec ile bede potrzebowal w nastepnym projekcie?

>> A znasz ARMa w obudowie SO08? Albo SO16?
>
> SO16 to bardzo duża powierzchnia obudowy choć mało nóżek, zamiast tego
> zmieszczę bez problemu LFBGA 144piny, albo innym razem TFBGA 64pin
> (5mm x 5mm) albo jak wolisz mało nóżek VFQFPN 36 pin (6mm x 6mm)

Jasne, tylko, ze to juz nie na 2-warstwowy tani laminat. A jaki jest
sens isc w koszty jesl mozna to zrobic na 2- lub nawet 1-warstwowym
laminacie za grosze.

>> Nikt, tylko ze to bez sensu. Ponosisz koszty poznania dwoch rodzin, jesli
>> korzystasz z komercyjnych narzedzi to tez musisz za wszystko placic 2x,
>> dwie rozne elektroniki, przy komercyjnych narzedziach praktycznie
>> nieprzenoszalny kod, czyli piszesz wszystko 2x.
>
> - 2-rodziny to ja już znam a nawet więcej,
> - narzędzia nie są aż tak drogie,
> - kod bez problemu przenoszalny, i nie piszę "2x"; ale swoją drogą to
> ja nie powielam całe życie tego samego produktu w nowych odsłonach,
> więc w zasadzie to piszę częściowo kod od nowa

Ok, to teraz uzasadnij po co tak robic. Po co ponosic koszty na
poszikawania kogos kto zna dwie rodziny, koszty zdublowania sprzetu i w
sumie niemale koszty licencji na komercyjne oprogramowanie, skoro mozna
to zalatwic jednym procesorem. Nie mowie, ze nie mozna, po prostu sens
ma to niewielki.

>> Owszem, tylko, ze ARMa wszedzie nie wsadzisz, chociazby dlatego, ze
>> najmniejsza wystepujaca obudowa jest TQFP64?
>
> patrz wyżej

Tylko uzasadnij mi prosze po co mam ladowac np. 36 nozkowy procesor i
inwestowac w drozsze wykonanie plytki jesli wystarczy mi cos w SO08?

>> Oczywiscie znajomosc jest nie do przecenienia. Tylko, ze ja majac c/C++ z
>> libc dla AVRa jestem w stanie napisac program szybciutko z minimalnym
>> tylko zaglebianiem sie do datasheeta. Co wiecej ten program latwo
>> przeniose np. na ARMa.
>
>> Pytanie czy dla '51 istnieje libc dla kazdego modelu '51? Pliki naglowkowe
>> chociazby tylko ze standardowymi definicjami rejestrow?
>
> Jak najbardziej na 51 jest C i też skompiluje się na ARM

A na PC? Na AVR32?

Ile bedziesz mial sekcji #ifdef __ARM__, albo #ifdef specific_compiler ?

do góry

>>>> z 51' to znam uPSD 10MIPsów z 40MHz....
>>> To ciagle 3x mniej.
>> A ile dokładnie MIPsów potrzebujesz?
> Skad mam wiedziec ile bede potrzebowal w nastepnym projekcie?

Skoro nie wiesz to bierzemy Intela C2D 3GHz - tak na zapas aby na pewno
starczyło

>>> A znasz ARMa w obudowie SO08? Albo SO16?
>> SO16 to bardzo duża powierzchnia obudowy choć mało nóżek, zamiast tego
>> zmieszczę bez problemu LFBGA 144piny, albo innym razem TFBGA 64pin
>> (5mm x 5mm) albo jak wolisz mało nóżek VFQFPN 36 pin (6mm x 6mm)
>
> Jasne, tylko, ze to juz nie na 2-warstwowy tani laminat. A jaki jest sens
> isc w koszty jesl mozna to zrobic na 2- lub nawet 1-warstwowym laminacie
> za grosze.

C2D nie posadzisz na 2-warstwach - zapomnij

>>> Nikt, tylko ze to bez sensu. Ponosisz koszty poznania dwoch rodzin,
>>> jesli korzystasz z komercyjnych narzedzi to tez musisz za wszystko
>>> placic 2x, dwie rozne elektroniki, przy komercyjnych narzedziach
>>> praktycznie nieprzenoszalny kod, czyli piszesz wszystko 2x.
>>
>> - 2-rodziny to ja już znam a nawet więcej,
>> - narzędzia nie są aż tak drogie,
>> - kod bez problemu przenoszalny, i nie piszę "2x"; ale swoją drogą to
>> ja nie powielam całe życie tego samego produktu w nowych odsłonach,
>> więc w zasadzie to piszę częściowo kod od nowa
>
> Ok, to teraz uzasadnij po co tak robic. Po co ponosic koszty na
> poszikawania kogos kto zna dwie rodziny, koszty zdublowania sprzetu i w
> sumie niemale koszty licencji na komercyjne oprogramowanie, skoro mozna to
> zalatwic jednym procesorem. Nie mowie, ze nie mozna, po prostu sens ma to
> niewielki.

Ale jak inaczej robić? Bo ja nie rozumiem, dobieram elektronikę do projektów
a nie
projekty do jedynego procesora który znam. Ja siebie nie muszę szukać :). A
jeśl
zatrudnisz dwie osoby zajmujące się uP to i tak komercyjne to 2-licencje
kupisz -
chyba że na lewo robisz - ale wtedy to nie ma i tak problemu ...

>>> Owszem, tylko, ze ARMa wszedzie nie wsadzisz, chociazby dlatego, ze
>>> najmniejsza wystepujaca obudowa jest TQFP64?
>> patrz wyżej
> Tylko uzasadnij mi prosze po co mam ladowac np. 36 nozkowy procesor i
> inwestowac w drozsze wykonanie plytki jesli wystarczy mi cos w SO08?

Policz wszelkie koszty projektu - jeśli mała seria to cena elektroniki nie
gra
żadnej roli.
Skoro zajmujesz się tylko i wyłacznie jednym uP i to tylko w obudowie SO08
to masz problem - ja nie, dla mnie nie robi różnicy wsadzić raz pica albo 51
albo arm albo cokolwiek innego.

>>> Oczywiscie znajomosc jest nie do przecenienia. Tylko, ze ja majac c/C++
>>> z libc dla AVRa jestem w stanie napisac program szybciutko z minimalnym
>>> tylko zaglebianiem sie do datasheeta. Co wiecej ten program latwo
>>> przeniose np. na ARMa.
>>
>>> Pytanie czy dla '51 istnieje libc dla kazdego modelu '51? Pliki
>>> naglowkowe chociazby tylko ze standardowymi definicjami rejestrow?
>>
>> Jak najbardziej na 51 jest C i też skompiluje się na ARM
>
> A na PC? Na AVR32?
Na PC też się kompiluje - tak często uruchamiałem programy.

> Ile bedziesz mial sekcji #ifdef __ARM__, albo #ifdef specific_compiler ?
To nie ma znaczenia - ja nie piszę pracy naukowej pod tytułem : jak napisać
program
tak aby był bez #ifdef albo #define i np kompilował sie pod wszystkimi
kompilatorami C/C++ jakie istnieją i jeszcze z wszystkich platform na
wszystkie inne
platformy i systemy operacyjne itd - nie mam na to czasu.

do góry

zbyszek pisze:
>>>>> z 51' to znam uPSD 10MIPsów z 40MHz....
>>>> To ciagle 3x mniej.
>>> A ile dokładnie MIPsów potrzebujesz?
>> Skad mam wiedziec ile bede potrzebowal w nastepnym projekcie?
>
> Skoro nie wiesz to bierzemy Intela C2D 3GHz - tak na zapas aby na pewno
> starczyło

Zastanawiam sie nad przyczyna tak idiotycznej odpowiedzi.
Niezrozumienie, czy glupota?

>>>> A znasz ARMa w obudowie SO08? Albo SO16?
>>> SO16 to bardzo duża powierzchnia obudowy choć mało nóżek, zamiast tego
>>> zmieszczę bez problemu LFBGA 144piny, albo innym razem TFBGA 64pin
>>> (5mm x 5mm) albo jak wolisz mało nóżek VFQFPN 36 pin (6mm x 6mm)
>> Jasne, tylko, ze to juz nie na 2-warstwowy tani laminat. A jaki jest sens
>> isc w koszty jesl mozna to zrobic na 2- lub nawet 1-warstwowym laminacie
>> za grosze.
>
> C2D nie posadzisz na 2-warstwach - zapomnij

Glupota.

>>>> Nikt, tylko ze to bez sensu. Ponosisz koszty poznania dwoch rodzin,
>>>> jesli korzystasz z komercyjnych narzedzi to tez musisz za wszystko
>>>> placic 2x, dwie rozne elektroniki, przy komercyjnych narzedziach
>>>> praktycznie nieprzenoszalny kod, czyli piszesz wszystko 2x.
>>> - 2-rodziny to ja już znam a nawet więcej,
>>> - narzędzia nie są aż tak drogie,
>>> - kod bez problemu przenoszalny, i nie piszę "2x"; ale swoją drogą to
>>> ja nie powielam całe życie tego samego produktu w nowych odsłonach,
>>> więc w zasadzie to piszę częściowo kod od nowa
>> Ok, to teraz uzasadnij po co tak robic. Po co ponosic koszty na
>> poszikawania kogos kto zna dwie rodziny, koszty zdublowania sprzetu i w
>> sumie niemale koszty licencji na komercyjne oprogramowanie, skoro mozna to
>> zalatwic jednym procesorem. Nie mowie, ze nie mozna, po prostu sens ma to
>> niewielki.
>
> Ale jak inaczej robić? Bo ja nie rozumiem, dobieram elektronikę do projektów
> a nie
> projekty do jedynego procesora który znam. Ja siebie nie muszę szukać :). A
> jeśl
> zatrudnisz dwie osoby zajmujące się uP to i tak komercyjne to 2-licencje
> kupisz -
> chyba że na lewo robisz - ale wtedy to nie ma i tak problemu ...

Owszem, dobiera sie elektronike do projektu. Ale rodzina AVR jest na
tyle bogata, ze pokrywa mi wiele roznych potrzeb. Ma sens poznac np. AVR
i ARM/AVR32, bo te rodziny istotnie sie roznia i sluza po prostu do
innych zastosowan. A jaki jest sens poznawac AVR/'51, skoro ta druga nie
ma zadnej przewagi nad AVR? Bezsensowne dublowanie.

>>>> Owszem, tylko, ze ARMa wszedzie nie wsadzisz, chociazby dlatego, ze
>>>> najmniejsza wystepujaca obudowa jest TQFP64?
>>> patrz wyżej
>> Tylko uzasadnij mi prosze po co mam ladowac np. 36 nozkowy procesor i
>> inwestowac w drozsze wykonanie plytki jesli wystarczy mi cos w SO08?
>
> Policz wszelkie koszty projektu - jeśli mała seria to cena elektroniki nie
> gra
> żadnej roli.
> Skoro zajmujesz się tylko i wyłacznie jednym uP i to tylko w obudowie SO08
> to masz problem - ja nie, dla mnie nie robi różnicy wsadzić raz pica albo 51
> albo arm albo cokolwiek innego.

Widze, ze nie rozumiesz. AVRy mam w kazdej mozliwej obudowie. ARMy nie.
Wiec ten sam rdzen moge wykorzystac w roznych projektach nie zmieniajac
ani narzedzi, ani softu. ARMy sluza po prostu do czegos innego, jesli
tego nie rozumiesz to trudno.

>>>> Oczywiscie znajomosc jest nie do przecenienia. Tylko, ze ja majac c/C++
>>>> z libc dla AVRa jestem w stanie napisac program szybciutko z minimalnym
>>>> tylko zaglebianiem sie do datasheeta. Co wiecej ten program latwo
>>>> przeniose np. na ARMa.
>>>> Pytanie czy dla '51 istnieje libc dla kazdego modelu '51? Pliki
>>>> naglowkowe chociazby tylko ze standardowymi definicjami rejestrow?
>>> Jak najbardziej na 51 jest C i też skompiluje się na ARM
>> A na PC? Na AVR32?
> Na PC też się kompiluje - tak często uruchamiałem programy.
>
>> Ile bedziesz mial sekcji #ifdef __ARM__, albo #ifdef specific_compiler ?
> To nie ma znaczenia - ja nie piszę pracy naukowej pod tytułem : jak napisać
> program
> tak aby był bez #ifdef albo #define i np kompilował sie pod wszystkimi
> kompilatorami C/C++ jakie istnieją i jeszcze z wszystkich platform na
> wszystkie inne
> platformy i systemy operacyjne itd - nie mam na to czasu.

Znowu nie rozumiesz. Wlasnie wybierajac gcc wiem, ze program sie bez
problemu skompiluje na wszystkie platformy. Mam to gratis bez wysilku.
Wprowadzanie sekcji #ifdef/#endif tylko podraza koszty, bo musisz
program niezaleznie testowac z kazdym mozliwym warunkiem.

Na koncu pytanie kontrolne - jestes wlascicielem firmy, czy pracownikiem?

do góry

Jerry1111 wrote:
> Zbych wrote:
>> T.M.F. pisze:
>>
>>> Jak dla mnie to populistyczny argument. Bledy sa wszedzie.
>>
>> Nie musisz mi tego tłumaczyć. Wytłumacz to tym, którzy używają tego
>> jako argumentu przeciwko komercyjnym kompilatorom.
>
> Nikt nie zabroni Ci w gcc wybrac _dowolnej_ wersji kompilatora. W IAR...
> ekhm... za ile wersji zaplaciles?

I jeszcze jedno odnosnie 'platnych' kompilatorow. Mozna nagle znalezc
taki email w swojej skrzynce (ja dzis znalazlem):

Dear HI-TECH Customer,

We are pleased to inform you that HI-TECH Software has joined Microchip
Technology as a fully owned subsidiary! This is the natural progression
of our long-standing, friendly relationship.

In order to provide the best possible products for Microchip
microcontrollers and digital signal controllers, we will focus our
energies exclusively on Microchip-related products. Of course, support
agreements for other products will be honored for the duration of those
agreements.

No i co? No i jak masz kompilator na cos innego niz PICe to dupa blada -
poprawek nie bedzie, nowych wersji nie bedzie, inwestycja nie za bardzo
udana.

Jedyny plus, ze moze w koncu bedzie znosny kompilator do PICow za darmo.


--
Jerry1111

do góry

zbyszek napisal(a):

>A ja kupiłem "profesjonalny" kompilator C IAR do procków 51 chyba w 1999
>roku (albo rok wcześniej). Błedów było sporo, pamiętam że czasem polecenia
>if
>źle się kompilowały i coś innnego robiły niz powinny, a kiedy do funkcji
>przekazało
>się jakiś element struktury to niekoniecznie on był brany pod uwagę w
>obiliczeniach :)

Taaa, pamietam, ze musialem studiowac pliki wyjsciowe z kompilatora
IAR-C, zeby wylapac jego bledy. Frustrujace zajecie, ale przynajmniej
sie dowiedzialem jak nieefektywny jest kod wynikowy z IAR.

--
Pozdrowienia, Marcin E. Hamerla

"Every day I make the world a little bit worse."

do góry