Goto page Previous 1, 2, 3 ... 6, 7, 8 ... 10, 11, 12 Next
Mario
Guest
Sun Mar 08, 2009 5:29 pm
Zbych pisze:
Quote:
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
Mario
Guest
Sun Mar 08, 2009 5:32 pm
Ghost pisze:
Quote:
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
Mario
Guest
Sun Mar 08, 2009 5:42 pm
Zbych pisze:
Quote:
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
T.M.F.
Guest
Sun Mar 08, 2009 5:53 pm
Zbych pisze:
Quote:
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.
Quote:
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.
Quote:
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.
Zbych
Guest
Sun Mar 08, 2009 6:05 pm
T.M.F. pisze:
Quote:
Piszesz o wersji gcc z ktorego roku? Bo mam wrazenie, ze o jakiejs
prehistorycznej.
2008.
Quote:
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.
T.M.F.
Guest
Sun Mar 08, 2009 7:20 pm
Zbych pisze:
Quote:
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.
Quote:
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.
Sebastian Biały
Guest
Sun Mar 08, 2009 7:37 pm
Ghost wrote:
Quote:
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.
Quote:
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.
Sebastian Biały
Guest
Sun Mar 08, 2009 7:42 pm
Mario wrote:
Quote:
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.
Zbych
Guest
Sun Mar 08, 2009 7:49 pm
T.M.F. pisze:
Quote:
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_page.php?bug_id=02668
Quote:
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ął.
T.M.F.
Guest
Sun Mar 08, 2009 8:28 pm
Quote:
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.
Quote:
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.
Quote:
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.
Zbych
Guest
Sun Mar 08, 2009 8:34 pm
T.M.F. pisze:
Quote:
Niestety nie da sie tego przegladnac, login i halso potrzebne. Numer
bledu z id tez nie istnieje.
Zarejestruj się. To nic nie kosztuje.
Quote:
Poza tym to nie jest strona gcc, wiec jesli mozesz daj linka lub nr
bledu do bugzilli na gcc.gnu.org.
nie mam.
Ghost
Guest
Sun Mar 08, 2009 8:39 pm
Użytkownik "Sebastian Biały" <heby@poczta.onet.pl> napisał w wiadomości
news:gp139c$o8u$1@achot.icm.edu.pl...
Quote:
Ghost wrote:
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.
nima
Sebastian Biały
Guest
Sun Mar 08, 2009 8:46 pm
Ghost wrote:
Quote:
No wlasnie gdzie jest 8086?
W twoim pececie. Kompatybilnośc z aplikacjami dosowymi święta rzecz.
nima
A na bazie jakiego cpu masz pc ?
Ghost
Guest
Sun Mar 08, 2009 8:54 pm
Użytkownik "Sebastian Biały" <heby@poczta.onet.pl> napisał w wiadomości
news:gp17a8$ue5$1@achot.icm.edu.pl...
Quote:
Ghost wrote:
No wlasnie gdzie jest 8086?
W twoim pececie. Kompatybilnośc z aplikacjami dosowymi święta rzecz.
nima
A na bazie jakiego cpu masz pc ?
Taki quadratowy
Sebastian Biały
Guest
Sun Mar 08, 2009 8:57 pm
Ghost wrote:
Quote:
No wlasnie gdzie jest 8086?
W twoim pececie. Kompatybilnośc z aplikacjami dosowymi święta rzecz.
nima
A na bazie jakiego cpu masz pc ?
Taki quadratowy
Takie sa najgorsze, gorsze nawet od zgodnych z 8086
Goto page Previous 1, 2, 3 ... 6, 7, 8 ... 10, 11, 12 Next