Zbych pisze:
> Mario pisze:
>
>> 3,60? Od 2051 każdy jest mocniejszy - nawet 2313. Już sam fakt
>> taktowania cykli rozkazowych F/12. Niższe częstotliwości I/O. Brak
>> EEPROMa i malutki RAM.
>
> A co jeśli nie potrzebujesz prędkości, eepromu i wystarczy ci 128B RAM?
> Zresztą sprawdziłem i w tej chwili 2313 kosztuje mniej niż 2051, więc
> argument jest "trochę" nietrafiony i muszę się z niego wycofać :-]
>

Ja sprawdzałem w TME w 2313 - 3,99, 2051 - 3,62. Ale to że bywają
zadania w których da się zastosować 51 nie jest argumentem za
stosowaniem 51. Jeśli robisz na AVR to w zależności od potrzeby
zastosujesz ATMEGA128 lub ATMEGA8. Zapewne możesz też łatwo zmigrować na
AVR32. No i nie ma też problemu z przejściem na ARM. Ja właściwie z 51
przeskoczyłem włąśnie na ARMa a potem dla mniejszych rzeczy na AVR. I
nie odczuwam jakoś tej różnicy że ARM to jedna z platform obsługiwanych
przez gcc a avr-gcc to osobny port.
W przypadku 51 jesteś skazany na realizację takich zadań które da się
zrobić na 51 albo dorzucać peryferia które odciążą ci procka.
A jeśli chodzi o soft to na 51 zdaje się nie ma gcc a sdcc jakoś nie
wzbudziło mojego zaufania.

--
Pozdrawiam
MD

do góry

Ghost pisze:

>
>>> Gdyby nie to, nie byloby juz 51 na rynku.
>>
>> Z '51 to tak jak z 8086. I to i to szit. Ale szity zwyczajowo
>> wygrywaja w wyscigu technologicznym. Na szczescie w przypadku '51 w
>> pore przyszedł ratunek w postaci RISCów.
>
> No wlasnie gdzie jest 8086?

W pecetach. Platforma 586 i 686 to RISC emulujący 86. A w
mikrokontrolerach niestety dali ciała. Trzymali zaporowe ceny na 186 i
się nie upowszechniło. Za duzo chcieli zarobić.

--
Pozdrawiam
MD

do góry

Zbych pisze:
> Mario pisze:
>
>> No i to jest argument za stosowaniem uC za którym stoi silne community
>> i współpracujący z nim producent.
>
> Co mi po procesorze z silnym community jak nie ma wystarczających
> peryferiów albo cena jest nieodpowiednia?

System mikroprocesorowy core i peryferia oraz kompilator biblioteki i ew
debugger. Jeśli komercyjny soft gwarantuje ci że masz system bez błędów
to ekstra. Jeśli jednak jest bardzo drogi lub dają soft z błędami i
nie poczuwają się do ich usuwania to fakt, że masz procek z ciekawymi
peryferiami przestaje być taką zaletą. Może lepiej wejść w coś do czego
jest silne wsparcie a do procka dorzucić FCPGA or sth.

--
Pozdrawiam
MD

do góry

Zbych pisze:
> 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.

Bo kwestia jest jak te bledy sa usuwane. W komercyjnych produktach
zwykle poprzez kupno nowej wersji. Tu masz niezly support za darmo.

>> Jesli piszesz o bledach portu na AVR to przejrzyj chociazby liste
>> AVRFreaks.
>
> Nie pisałem o AVR. Błędy, o które się obiłem były strasznie
> szmaciarskie: brak kontroli zakresu skoków przez gas, wysypywanie się
> (coredump) g++ po dodaniu atrybutu z sekcją do danej const itp.

Piszesz o wersji gcc z ktorego roku? Bo mam wrazenie, ze o jakiejs
prehistorycznej.

>> Piszesz o dziwnych niekompatybilnych rozszerzeniach gcc. Tak sie
>> sklada, ze pisze sobie GUI w c++ na AVR i symulator na PC.
>
> Pisałem o rozszerzeniach niespotykanych u innych producentów
> kompilatorów, a nie o gcc na avr i x86.

Kazdy kompilator ma jakies niespotykane rozszerzenia. Zwykle definiowane
przez #pragma. Tu masz zaleta taka, ze ten sam kompilator (gcc) masz na
wszystkich platformach. Jesli piszesz w ANSI C to takze nie ma problemu
z przenoszeniem kodu do innego kompilatora, chociazby microsoftowego
(vide zarabiscie wielka biblioteka Qt, ktora sie kompiluje na obu).
Natomiast jak masz cos w stylu kompilator jezyka C PICC to juz nawet po
nazwie sugeruje niekompatybilnosc z zadnym standardem.

do góry

T.M.F. pisze:

> Piszesz o wersji gcc z ktorego roku? Bo mam wrazenie, ze o jakiejs
> prehistorycznej.

2008.

> Kazdy kompilator ma jakies niespotykane rozszerzenia. Zwykle definiowane
> przez #pragma. Tu masz zaleta taka, ze ten sam kompilator (gcc) masz na
> wszystkich platformach.

Nie rozumiem po co mi to piszesz. To był czyjś argument przeciwko
komercyjnym kompilatorom. Ja tylko przypomniałem, że gcc też ma swoje
niestandardowe rozszerzenia.

do góry

Zbych pisze:
> T.M.F. pisze:
>
>> Piszesz o wersji gcc z ktorego roku? Bo mam wrazenie, ze o jakiejs
>> prehistorycznej.
>
> 2008.

Pokazesz mi bug report? Bo jakos nie wierze w to co piszesz. Osobiscie
uzywam atrybutow sekcji w stalych C++ do definiowania np. fontow i nie
mam z tym najmniejszego problemu.

>
>> Kazdy kompilator ma jakies niespotykane rozszerzenia. Zwykle
>> definiowane przez #pragma. Tu masz zaleta taka, ze ten sam kompilator
>> (gcc) masz na wszystkich platformach.
>
> Nie rozumiem po co mi to piszesz. To był czyjś argument przeciwko
> komercyjnym kompilatorom. Ja tylko przypomniałem, że gcc też ma swoje
> niestandardowe rozszerzenia.

Bo co innego rozszerzenia do standardu, a co innego cos co z zadnym
standardem nie jest zgodne, w szczegolnosci z ANSI C. W tej chwili gcc
jest najbardziej zgodnym ze standardem ANSI kompilatorem C.

do góry

Ghost wrote:
> Zara, zara - ale procesor to nie tylko jezyk.

A co jest w nim innego? Parę bitów w paru rejestrach? W 90% będziesz
mial peryferia pokroju USART w ktorym z ustawieniem tych paru bitow
poradzis sobie nawet hex-dziobak '51. Jak mowa o bardziej wypasionych to
i tak zazwyczaj nie są w cpu, a przynajmniej nie w takiej skali cpu wiec
z wiekszymi peryferiami masz taki sam problem wszedzie.

>> Z '51 to tak jak z 8086. I to i to szit. Ale szity zwyczajowo
>> wygrywaja w wyscigu technologicznym. Na szczescie w przypadku '51 w
>> pore przyszedł ratunek w postaci RISCów.

> No wlasnie gdzie jest 8086?

W twoim pececie. Kompatybilnośc z aplikacjami dosowymi święta rzecz.

do góry

Mario wrote:
> Platforma 586 i 686 to RISC emulujący 86. A w
> mikrokontrolerach niestety dali ciała.

Dziekujmy opatrzności. Inaczej grupa była by zawalana pytaniami "mam 4Mb
RAM a pokazuje 640k, pomocy", albo "jestem w trybie rzeczystistym, jak
przełączyć się w chroniony w przerwaniu i zmienić segment pamięci?" itd
podobne problemy nieznane na innych normalnych architekturach. Cale
szczęście że nie zdobyły popularności w uC.

do góry

T.M.F. pisze:

> Pokazesz mi bug report? Bo jakos nie wierze w to co piszesz.

Czyli zakładasz z góry, że twój rozmówca jest kłamcą? Nieładnie.
Tu masz linka niedowiarku :-)
http://www.kpitgnutools.com/bt/bug_view_advanced_pag
e.php?bug_id=02668

> Bo co innego rozszerzenia do standardu, a co innego cos co z zadnym
> standardem nie jest zgodne, w szczegolnosci z ANSI C.

Czyli podsumowując rozszerzenie "do" standardu jest zgodne ze
standardem, w przeciwieństwie do rozszerzeń, które nie są zgodne ze
standardem :-). Sam bym tego lepiej nie ujął.

do góry

>> Pokazesz mi bug report? Bo jakos nie wierze w to co piszesz.
>
> Czyli zakładasz z góry, że twój rozmówca jest kłamcą? Nieładnie.

A nazwalem cie klamca? Napisalem, ze nie wierze.

> Tu masz linka niedowiarku :-)
> http://www.kpitgnutools.com/bt/bug_view_advanced_pag
e.php?bug_id=02668

Niestety nie da sie tego przegladnac, login i halso potrzebne. Numer
bledu z id tez nie istnieje.
Poza tym to nie jest strona gcc, wiec jesli mozesz daj linka lub nr
bledu do bugzilli na gcc.gnu.org.

>> Bo co innego rozszerzenia do standardu, a co innego cos co z zadnym
>> standardem nie jest zgodne, w szczegolnosci z ANSI C.
>
> Czyli podsumowując rozszerzenie "do" standardu jest zgodne ze
> standardem, w przeciwieństwie do rozszerzeń, które nie są zgodne ze
> standardem :-). Sam bym tego lepiej nie ujął.

Celowo nie rozumiesz subtelnosci polegajacej na rozszerzeniu w stosunku
do standardu ANSI C, a niezgodnosci ze standardem ANSI C i tworzenu
wlasnych udziwnien?

Jeszcze raz - bardzo duze projekty takie jak KDE czy framework Qt z
Nokii kompiluja sie na gcc (zarowno pod linuxem jak i windowsem) oraz za
pomoca kompilatora microsoftu bez problemow. Co jednak swiadczy o sporej
kompatybilnosci i zgodnosci ze standardem.
Nawet jesli korzystam z rzeczy niestandardowych to w przypadku gcc
problem jest maly, gdyz ten kompilator istnieje na praktycznie kazdej
platformie sprzetowej, wiec ew. niekompatybilnosci nie zauwaze. Jesli
korzystam z rosrzerzen IAR dla AVR to juz na niczym innym tego nie
skompiluje.

do góry