Mikrokontrolery ATMEL dla początkujących: Książki, zestawy i zasoby do automatyki domowej

Sun Mar 08, 2009 5:29 pm   

Zbych pisze:

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

Sun Mar 08, 2009 5:32 pm   

Ghost pisze:


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

Sun Mar 08, 2009 5:42 pm   

Zbych pisze:

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

Sun Mar 08, 2009 5:53 pm   

Zbych pisze:

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


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


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.

Sun Mar 08, 2009 6:05 pm   

T.M.F. pisze:


2008.


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.

Sun Mar 08, 2009 7:20 pm   

Zbych pisze:

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.


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.

Sun Mar 08, 2009 7:37 pm   

Ghost wrote:

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.


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

Sun Mar 08, 2009 7:42 pm   

Mario wrote:

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.

Sun Mar 08, 2009 7:49 pm   

T.M.F. pisze:


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


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ął.

Sun Mar 08, 2009 8:28 pm   

A nazwalem cie klamca? Napisalem, ze nie wierze.


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.


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.

Sun Mar 08, 2009 8:34 pm   

T.M.F. pisze:


Zarejestruj się. To nic nie kosztuje.



nie mam.

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...

nima

Sun Mar 08, 2009 8:46 pm   

Ghost wrote:

A na bazie jakiego cpu masz pc ?

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...

Taki quadratowy

Sun Mar 08, 2009 8:57 pm   

Ghost wrote:

Takie sa najgorsze, gorsze nawet od zgodnych z 8086