myślę, że jak poczytasz to co podaję ci w tym linku poniżej a później sięgniesz po jakąś książkę to będziesz już wszystko wiedział czego początkujący potrzebuje
zwrócę tylko uwagę, żeby ew zrobić sobie lub kupić prosty programatorek do tych miłych scalaczków AVR - a mianowicie STK200 (koszt gotowego, sprawdzonego i uruchomionego to przeważnie ok 15zł - więc czasem nie opłaca się go nawet samemu robić)
Chodzi mi tutaj o coś więcej, niż patrzenie na sprawy z punktu widzenia hobbysty. Ja uważam, że dobrze jest znać kilka rodzin mikrokontrolerów, a to z racji, że niektóre firmy, szukając pracowników, stawiają wymogi, znajomość tego czy tamtego, więc zawsze wiedzieć więcej nie zaszkodzi. Po drugie, może i np ten PIC16F84 o którym mówiłem wcześniej jest i słaby, ale może za to mocniejsze wersje tych PIC-ów są lepsze od AVR. Chcę zasięgnąć rady tych osób, które używają uC PIC, aby naświetlili sprawę. I nie chodzi mi tutaj o żaden spór, że te są fuj, a tamte cacy.
Pisałem to w czasach kiedy byłem zafascynowany PIC-ami. Lubię je za to że są w wersji OTP. Inna sprawa że PICe lepiej niż AVRy znoszą "nieprzyjemne" środowisko - zakłócenia itp.
Z tą znajomością to bym nie przesadzał, są to proste uC 8-bitowe i praktycznie w jeden dzień można je poznać.
Na moje oko ATMega8 to strzał w 10. Ja mam już ze 30 i żadnego innego nie narzekam. Maja przetworniki ADC, dużo Timrów i innych bajerów i mi sie podobają. ATMega16 czy inne w niczym nie są lepsze oprócz wiekszych pamięci danych i programu. Mi to nie przeszkadza bo potrafię mocno optymalizowac programy.
Do kpitan
Uważam, że najpierw powinieneś przeczytać od początku ten post. Pytanie typu "jaki uC dla początkującego" przewijało się kilka razy, i często padała odpowiedź ATmega8. Przeczytanie od początku zapobiegnie niepotrzebnemu rozrastaniu się tego posta, przez co większość osób zdecyduje się jednak przeczytać go od początku, zanim zada pytanie. I zapewne po przeczytaniu, nie będzie potrzeby zadawania takiego pytania. Po drugie nie trzeba czekać na odpowiedź :]
Chciałbym poprosić o radę : czy warto próbować korzystać z mikrokontrolerów tylko do obliczeń powiedzmy matematycznych? Chodzi mi o budowe wieloprocesorowej składanki (powtarzalne komunikujące się ze sobą moduły łączone w pierścienie lub siatki) rozwiązujące zadania matematyczne metodami sztucznej inteligencji (wykorzystując np. sieci neuronowe czy algorytmy genetyczne). Jeśli tak, to jakie procesory mogłyby się do tego nadawać (myślałem o ATmega64/128, ale nie będę przecież wykorzystywał ani ADC, ani PWM itd.)?
Szukam darmowego środowiska programistycznego do serii M68HC..
CodeWarrior to droga rzecz. Podobno istnieją programy "free"??
Wczesniej zauważyłem przyjmniej trzy wypowiedzi odnośnie procesorków Freescale (m o t o r o l a).
Pozdrawiam.
Dla 68HC11 i 68HC12 jest gcc: http://www.gnu.org/software/m68hc11/m68hc11_pkg_zip.html IDE chyba trzeba by sobie samemu poskładać. Jako edytor polecałbym Programmer's Notepad, albo Notepad++. Debuger nie wiem jaki, w zasadzie nie używam. Może gdb?
Szukam darmowego środowiska programistycznego do serii M68HC..
CodeWarrior to droga rzecz. Podobno istnieją programy "free"??
Wczesniej zauważyłem przyjmniej trzy wypowiedzi odnośnie procesorków Freescale (m o t o r o l a).
Pozdrawiam.
Do HC08 kompilator SDCC, programator z firmy pemicro.
Dodano po 1 [minuty]:
PitersonX wrote:
Witam Wszystkich
Chciałbym poprosić o radę : czy warto próbować korzystać z mikrokontrolerów tylko do obliczeń powiedzmy matematycznych? Chodzi mi o budowe wieloprocesorowej składanki (powtarzalne komunikujące się ze sobą moduły łączone w pierścienie lub siatki) rozwiązujące zadania matematyczne metodami sztucznej inteligencji (wykorzystując np. sieci neuronowe czy algorytmy genetyczne). Jeśli tak, to jakie procesory mogłyby się do tego nadawać (myślałem o ATmega64/128, ale nie będę przecież wykorzystywał ani ADC, ani PWM itd.)?
Dziękuję za odpowiedź, Fantom. Chciałem dodać, że bawiłem się do tej pory tylko z prostymi uC typu '51 (np. AT89C4051) a chciałbym "w miarę łagodnie" przeskoczyć do czegoś dysponującego większą wydajnością obliczeniową (dlatego najpierw pomyślałem o AVR, pewnie błędnie rozumując). Czy do procesorów DSP też istnieją takie "przystępne" tutoriale jak do AVR (nie udało mi się takich znaleźć, pewnie dlatego, że to wyższa szkoła jazdy)? A jak wygląda w takiej sytuacji porównanie DSP z np. AVR32?
Dziękuję za odpowiedź, Fantom. Chciałem dodać, że bawiłem się do tej pory tylko z prostymi uC typu '51 (np. AT89C4051) a chciałbym "w miarę łagodnie" przeskoczyć do czegoś dysponującego większą wydajnością obliczeniową (dlatego najpierw pomyślałem o AVR, pewnie błędnie rozumując). Czy do procesorów DSP też istnieją takie "przystępne" tutoriale jak do AVR (nie udało mi się takich znaleźć, pewnie dlatego, że to wyższa szkoła jazdy)?
'51 i AVR to ta sama klasa jesli chodzi o mozliwosci obliczeniowe wiec chyba nei ma sensu sie na to "przesiadac". Na twoim miejscu sprobowal bym jakis 16 a jeszcze lepiej 32 bitowcow. Ocziwscie DSP to juz bardziej zaawansowana sprawa, tutoriale sa ale duzo gorzej z narzedziami (darmowych raczej nie ma a profesjonalne za grube $$$)
Quote:
A jak wygląda w takiej sytuacji porównanie DSP z np. AVR32?
Jak dzien do nocy. Nie znam dokladnie rodziny AVR32 (od razu przeskoczylem na ARM-y) ale do zaawansowanych obliczen matematycznych (szczegolnie zmiennoprzecinkowych) tylko DSP.
Witam, mam zamiar zacząć zabawę z procesorami. Przeczytałem trochę postów z tego tematu, ale chcę się dowiedzieć jaki model najbardziej będzie się nadawał na początek i aby zrobić zegarek. I w jakim języku, chyba odpuszczę sobie bascoma. Wybrać C czy asemblera ?
Do PitersonX:
Jeśli chodzi Ci o zabawę w sieci neuronowe, to owszem można popodpinać ze sobą nawet kilkadziesiąt uC, ale wydajności obliczeniowej to nie osiągniesz zbyt wielkiej z racji powolnej komunikacji między sobą tych procesorów. W większości przypadków uzyskasz większą wydajność uzywajac 32bitowy procesor takze w architekturze RISC
'51 nie są wcale szybsze jesli chodzi o obliczenia na liczbach wielobajtowych.
Jeśłi chodzi o sposób połączenia wielu uC to sprzętowo mogą one pracować w topologii gwiazdy. Oczywiście zawsze mozana opracowac własny protokół komunikacji
mam nadzieję, że troszkę Ci przyblizyłem to zagadnienie
Pozdrawiam
witam,
nie wiem, czy powinienem udawać, że pytając odpowiadam,
chyba konstrukcja tego tematu ("jaki mikrokontroler").. jakoś mi nie leży
przepraszam, jeśli wkurzę
chciałem zapytać o uc spełniający następujące wymogi:
-niskie zuzycie energii w trybie uspienia
-tryb uspienia programowany czasowo - kilka, ew max 24 godziny
-1 wejście analogowe z adc (do pomiaru napięcia z mostka z Rtemp)
-rx/tx ? choc nie wiem, czy tu juz kosmosu mi sie nie zachciewa
-oraz "albo-albo" pamiec mogąca pomiescic od 8880 do 370 pomiarow z adc albo dostatecznie duzo nog, by obsluzyc pamiec zewnetrzna
-jesli to nie problem - AI oraz pamięci może być np kilka razy więcej - będę mierzył z kilku rezystorów
-brak jakiejs podejrzanej zwiechy, ma dzialac przez rok bez awarii, potem moze sie zawiesic, ale jesli odpale na kolejny - znowu nie ()
muszę/chcę/potrzebuję zrobić rejestrator temperatury co najmniej zewnętrznej (byc moze takze kilku wewnętrznych) w naszych realiach, sztuk urządzenia- co najmniej kilka, docelowo moze i kilkadziesiąt
doswiadczenie - kilka atmeg32 oprogramowanych z peryferiami, ale niewiele więcej, stąd brak rozeznania, taka atmega wydaje mi się niepotrzebnie wielka, dlatego dopytuję
oglądałem ds1820 oraz inne, takze ten któryś rejestrator 9b dallasa/maxima, ale wydaje mi się to nazbyt drogie - mylę się? (kupowałbym pewnie maksymalnie 10 sztuk tych rejestratorów)
a moze są jakieś nowsze rozwiązania?
(i jeszecze moze cichaczem, ale za to bezczelnie dopytam, alkaliczne 9v bez problemu przeżyje rok takiej pracy? - np. spimy przez 4h-sekunda - wykonujemy pomiarow serię, usredniamy, zapisujemy w tablicy, czekamy do konca sekundy, spimy dalej
gdzies ktos na forum pisal o pojemnosci baterii 9v rzedu 100mAh,
prad uzywany przy pelnym uspieniu to <uA jakkolwiek mam to rozumiec, przy maksymalnym watchdogu kolo 2s (czytam z attiny, 5V), musialbym sie co chwila wlaczac, inkrementowac cos w wewn eepromie (malo go), i dzialac jak wyzej kiedy wylicze wartosc = np. 4h/2s [s], ale zapisywac do zewnetrznej pamieci (flash resetu z watchdoga nie przetrwa?!), co znowu trwa i kosztuje..
stąd zapytam - czego uzyć)
(licząc dalej - 1Mhz wewn osc, 4 pomiary/24h, 5v zasilania, na podstawie doca attiny
odpalam watchdoga (dziala niby rowno 1.9s) x 6h/1.9s = ca 3157.9 razy
(potem koryguje gdzieś jakos)
kazde odpalenie + inkrementacja i nie wiem co jeszcze to gora np. 20 rozkazow, czyli 20*10^-6 s, ??
czyli dzialam 370x24h - x[s] = ca 8880h na powerdown (=niby <1uA) ŹLE, wyczytalem wlasnie, 9-15uA, czyli tracę nie 9mAh, a 133,2 mAh, czyli padłem?, taaak? (jakos i tak nie wierze, na taka alkaliczna to przezyje (moze 300mAh), zwlaszcza, ze baterie same brać lubią w łeb,
te xs to działanie normalnie obiążające bat, czyli przy zasilaniu 3v, bo co do 5v nie podają, x[s] = [20*10^-6 * 3157.9 +1s (na pomiary)]*370*4 {??} = 1480 * (1+0.063158) = 93.47384 s
x * 2.2 mA = ca 220 mAs, czyli niby nic, w co też nie wierzę
ten stabilizator potrzebowal niejednego kondensatora, z których pewnie przez rok ładunek jakoś wywędruje.. ale o tym pojęcia nei mam, - coś podpowiecie?
a moze na stronie np. atmela jest jakis automat doborowy/zestawienie tabelkowe.. choc spore to to musialo by być, ://, ??
serdecznie dziekuję za pomoc
dodam - dzięki wielkie
azee
Bateria alkaliczna bez problemu wytrzyma rok, problemem pozostaje tylko jej pojemność. Może by tak użyć nie baterii 9V, a 3 razy po 1.5V, taniej wyjdzie, a pojemność większa. Nie trzeba by też żadnego stabilizatora, który będzie prąd zżerał. Pojemność ogniw alkalicznych w znacznej mierze zależy od prądu jakim są obciążone. Ty jesteś w sytuacji komfortowej akurat, bo im mniejszy prąd tym pojemność większa. Na angielskiej wikipedii piszą, że pojemność baterii (wcale nie baterii, tylko ogniwa, ale mniejsza o to ) AA moze dochodzić nawet do 3Ah.
Mało prądożerne AVRy to seria V. W kamami.pl widzę że mają ATtiny2313V-10SI, ale z tego co kojarzę, to nie ma on przetwornika A/C.
W seguro.pl mają ATmega169V, ale to z kolei dość duże. Atmel produkuje dość sporo mikrokontrolerów z serii V, tylko widocznie mało u nas popularne są.
Jako pamięci zewnętrznej można użyć szeregowego flasha. Kilka złotych kosztuje, a roziary nawet w megabajtach: http://seguro.pl/sklep/?podkat=2
Co do działąnia bez zawieszania - dużo zależy od warunków. Jeżeli rejestrator ma zapisywać dane pomiarowe co ściśle określony czas, to wskazany był by zewnętrzny zegar, bo mikrokontroler po zawieszeniu "zapomni" jaki był aktualny czas. Zewnętrzne RTC pobierają bardzo mało prądu.
to attiny za słabe, potrzebny mi uart, tj.. znacznie wygodniej byłoby
pamięć wewnętrzna chyba zawsze będzie za mała
(być może zatem takie coś - at24c16-10PI sprawia dostatecznie dobre wrażenie
http://seguro.pl/sklep/?zobacz=2592&producent= (6 pomiarow na dobe z 4 termistorow przejdzie)
)
sam procek - dotarłem do atmegi48 - dopiero to ma uart, uspienie, isp, adc, wersje zasilaną od 2.7V, watchdoga (to chyba wsio posiada)
jak miałby mi pomóc ten rtc ? wyzwala się po jakimś czasie, ja mam to zliczać? nie potrzebowałbym watchdoga? - 8x mniej prądu na uspieniu?
i co z tymi zwiechami, problemami, cokolwiek - zostawiam urządzenie na rok i nie ma kto sprawdzić, czy działa, ://
stąd myslalem, ze do epromu pisalbym id petli watchdoga
gdybym korzystal z paluszkow/akumulatorow - jak ustabilizuje napięcie na stalym poziomie przez rok?
oczywiscie moge sprawdzic jakosc pomiaru na początku i po 12 miesiącach, i potem przeskalowywać liniowo, ale co to za pomiar????
a inaczej jeszcze patrząc, 3xakku - 30/50zł, pamiec i procek - 10, rtc zaś 20zl ?? czemu tak?
jak miałby mi pomóc ten rtc ? wyzwala się po jakimś czasie, ja mam to zliczać? nie potrzebowałbym watchdoga? - 8x mniej prądu na uspieniu?
i co z tymi zwiechami, problemami, cokolwiek - zostawiam urządzenie na rok i nie ma kto sprawdzić, czy działa, ://
Nie wiem co chcesz rejestrować. Jeżeli ma to być wartość, z której potem sporządzisz zależność od czasu, to stosowanie watchdoga nie zapewni Ci dużej dokładności, chociaż w zasadzie można by to jakoś skompensować, znając dokładny czas początku i końca pomiarów, oraz ilość zebranych próbek wyliczyć średnią częstotliwość zegara watchdoga (a co za tym idzie czas między próbkami). Częstotliwość ta zależy zarówno od napięcia zasilania, jak i od temperatury, więc należy sie spodziewać jej wachań w czasie pracy urządzenia.
Zewnętrzny RTC był by wskazany gdyby konieczne było wykonywanie pomiaru dokładnie co na przykład godzinę.
A z tymi zawieszeniami się procesora, to w wypadku gdybyś czas odmierzał programowo, to mógł by być problem (zatrzymany pomiar czasu aż do resetu). Ale jeżeli odmierzasz czas watchdogiem, to właściwie wszystko jedno czy się zawiesi czy nie, bo i tak się zresetuje.
Zewnętrzny RTC daje Ci jeszcze jedną możliwość - może pracować jako układ "budzący" uC. Większość RTC ma alarm. ustawiasz alarm, procka usypiasz, a wyjście alarmu do wejścia reset, obyło by się wtedy bez watchdoga.
azee wrote:
gdybym korzystal z paluszkow/akumulatorow - jak ustabilizuje napięcie na stalym poziomie przez rok?
Procesor i EEPROM z serii 24Cxx nie potrzebują stabilizowanego napięcia.
Inna sprawa z czujnikiem temperatury.
Możliwości jest sporo, niektóre scalone czujniki nie potrzebują napięcia stabilizowanego, inne tak. Niektóre pobierają bardzo mało prądu w stanie "czuwania", a inne przez cały czas tyle samo.
Termistor z kolei pobiera prąd przez cały czas i do tego wymaga napięcia o znanej (aczkolwiek niekoniecznie stałej) wartości. Drugą kwestię można dość łatwo obejść ustalając napięcie odniesienia dla ADC na poziomie napięcia zasilania i z tego samego napięcia zasilać układ pomiarowy z termistorem. Pozostaje jednak problem poboru prądu. Termistor można by odłączać od zasilania za pomocą jakiegoś (MOS)FETa sterowanego z uC. Nie wiem, jak dokładnie wygląda wejście ADC w AVR, a konkretniej to jak zachowuje się gdy w stanie uśpienia napięcie na nim jest różne od napięcia zasilania lub masy. Z tego co kojarzę, to w ATtiny jest możliwość programowego odłączenia od pinu części cyfrowej, a rezystancja wejściowa ADC jest bardzo duża, więc raczej za dużo prądu tędy nie popłynie. Nie wiem tylko co z wejściem napięcia odniesienia, ale z tego co kojarzę, to można je odłączyć wewnętrznym multiplekserem. Zresztą nawet jak nie da się tak, to można odłączać z zewnątrz (MOS)FETami, czy kluczami analogowymi (CD4066 na przykład, bardzo prądooszczędne). Można tak, a można by też mieć źródło napięcia odniesienia dla termistora i cały układ pomiarowy (razem z tym źródłem) odłączać od zasilania. Takie rozwiązanie z termistorem + odłączanie na CD4066 będzie chyba najmniej prądożerne, a do tego bardzo tanie, tylko miejsca więcej zajmie.
azee wrote:
a inaczej jeszcze patrząc, 3xakku - 30/50zł, pamiec i procek - 10, rtc zaś 20zl ?? czemu tak?
Czemu aku? Bateria alkaliczna. Akumulatorki się nie nadają ze względu na efekt samorozładowania. Dobra bateria alkaliczna nawet kilka lat wytrzyma, podobnie ogniwa litowe (nie akumulatorki!, chociaż te i tak są lepsze od Ni-xx).
3 baterie alkaliczne AA będą tańsze od jednej 9V i mają dużo większą pojemność. 3xAA alkaliczne = 6-12zł.
Ogniwa litowe: http://seguro.pl/sklep/?zobacz=2136&producent= Tanio i pojemność już w miarę przyzwoita (220mAh). Do nabycia praktycznie wszędzie.
ATtiny13 (akurat ten, bo mam notę pod ręką) przy 3V z włączonym watchdogiem pobiera ok. 4uA. Zakładając średni prąd rzędu 5uA i tak starczyło by na 5 lat. EEPROM 24Cxx pobiera 1.6uA przy zasilaniu 2.7V, to i tak zostaje dużo więcej niż wymagany rok. Pozostałe peryferia powiedzmy odłączane kluczami CMOS.
Napięcie 3V powinno w zupełności wystarczyć, nie ma potrzeby łączenia szeregowo dwóch ogniw.
Zresztą ogniwo litowo-manganowe (to CR2032) przy rozładowaniu małym prądem (rzędu uA) od napięcia nominalnego, tj.3V do napięcia 2.7V tj. takiego przy którym może jeszcze poprawnie pracować EEPROM oraz powszechnie dostępna wersja chyba dowolnego AVRa (czyli z literką L) to będzie i tak ponad 90% nominalnej pojemności (100% jest do 2.0V).
RTC w sumie nie trzeba, niech już ten watchdog zostanie, a potem się średnią policzy. Widzę, że przez ten rok nie zamierzasz zbyt dużo próbek zebrać, więc zakładam, że dokładność rzędu sekund Cię nie interesuje ;].
Dzięki za info, ale wchodząc w szczegóły mój problem nie tyle polega na "przyśpieszaniu" obliczeń, ile na wykorzystaniu możliwości równoległego ich prowadzenia z migracją pomiędzy procesorami najlepszych wyników (równoległe algorytmy genetyczne). Problem polega na wielopunktowym poszukiwaniu rozwiązania, a efektywność jest mierzona jakością rozwiązania uzyskanego po ustalonym czasie. Nie chcę tu przynudzać, ale potrzebuję poprostu "dużo" "małych" komputerków Ponieważ DSP to dla mnie za wysokie progi, próbuję z ARMami.
Kiedyś dosyć aktywnie programowałem w asemblerze procki 80x86. Teraz chciałbym nauczyć się programowania w asm mikrokontrolerów. Problem w tym że nie wiem która architetura jest najbardziej przyszłościowa ?
Wielu wspomina jako plus że klasyczy rdzeń 8051 jest dostępny w największej liczbie odmian. Inne opinie z jakimi się spotkałem to takie że AVR to nowsza (bardziej dopracowana?) architektura. Z tego co szukałem to o AVR jest wiele więcej stron z źródłami i poradami niż na 8051 - albo się mylę ? Jeśli chodzi o ARM - to już zupełna tajeminca dla mie.
Zdaję sobie sprawę, że może nie istnieć jednoznaczna odpowiedź na pytanie która architektura jest najlepsza ale może byłby ktoś w stanie podać do jakich zastosowań dana architetura się sprawdza lepiej ?
Przy założeniu że językiem programowania będzie asm.
Post scaliłem, proszę zapoznać się najpierw z przyklejonymi tematami. [c_p]
AVR - fajny 8 bitowiec do małych projektów (można wszystko pisać w assemblerze)
ARM - raczej zbyt poteżny procesor, żeby był sens klepać więcej niż małe wstawki kodu w assemblerze. Tutaj zdecydowanie język wysokiego poziomu.
A co do samego assemblera na poszczególnych procesorach to:
8051 - jeżeli znasz 80x86 to znasz >50% 8051.. ogólnie b.upierdliwy - bardziej niż 80x86
ARM - bajecznie prosty, nauczysz się w jeden dzień
AVR - prosty chociaż jest sporo funkcji.
Ogólnie rzecz biorąc b.dobrze jest znać assembler, jednak pisanie programów w 100% w assemblerze to tylko hobby lub wielkoseryjna produkcja (gdzie procek o 10centów tańszy oznacza tysiące dolarów).
Nie wiem do czego ma to tobie służyć.. generalnie AVR dobrze sobie radzi w bardzo wielu sytuacjach - wszędzie tam, gdzie nie trzeba robić skomplikowanych obliczeń w krótkim czasie. Poza tym masz b.dużo odmian i b.przyjemne obudowy jak DIP - więc łatwo zacząć.
Stosowane w b.wielu miejscach jako układy kontrolne, pomiarowe, różne małe urządzenia i moduły.
ARM to większa bestia i często lepsze odmiany mają trudne do polutowania obudowy.
Stosowany prawie wszędzie.. w domu masz pewnie kilka procesorów ARM i nawet o tym nie wiesz. Obecnie ARMy są niezwykle popularne na wszystkich PDA, Smartphoneach itp, ale to tylko skrawek rozległego rynku.
Z rdzeniem w wersji podstawowej faktycznie przeżytek.
Ale przecież istnieją wersje udoskonalone posiadające takie wyposażenie, że rodzina AVR wypada przy nich słabo.
ale z pewnością nie są tańsze od avr...przecież zawsze o kase chodzi
Jeśli porównywać cenę w sposób "naiwny" to oczywiście są droższe.
Ale jeśli wziąć pod uwagę peryferia wbudowane standardowo to okazuje się, że albo są tańsze albo łatwo wykonać coś, co na AVR byłoby do wykonania trudne/niemożliwe lub miało duże rozmiary (z czym również wiążą się wyższe koszty). Istnieją takie aplikacje, do których nic z rodziny AVR się nie nadaje, a da się znaleźć jakiś model z rdzeniem C51 (ulepszonym lub nie), który sobie poradzi.
no i znowu zaczęła się dyskusja na temat wyższością świąt Bożego narodzenia nad świętami Wielkanocnymi (czytaj: wyższości jednej rodziny procków nad inną rodziną) - totalne bzdury! każda rodzina jest dobra do odpowiednich zastosowań a argumenty typu:
Quote:
"istnieją takie aplikacje, do których niz z rodziny AVR się nie nadaje..."
to już okrutne stwierdzenie (tym bardziej jeśli ktoś zaczyna się tego uczyć i potrzebuje podłączyć jedną diodę LED jeden klawisz i zrobić pierwsze testy - do tego nadaje się procek z każdej rodziny) , szkoda tylko, że wciąż trzeba o tym ludziom przypominać aby takich bzdur nie wypisywali i sprzeczali się która rodzina jest lepsza. Przez to początkujący, którzy tu zaglądają - nie dziwię się że nie mogą żadnego sensownego wniosku wyciągnąć z tego typu co jakiś czas pojawiąjących się przekomarzań
ja każdemu początkującemu poleciłbym jedno:
zacznijcie bez żadnych uprzedzeń przygodę od dowolnej rodziny AVR, PIC, '51 . Dobrze jest poznać przynajmniej z opisów możliwości wszystkie, bo różnią się one pomiędzy sobą i dzięki temu mamy do dyspozycji różne narzędzia a nie tylko jedno. A zakładając, że programuje się w językach wyższego rzędu to naprawdę różnice sprowadzają się tylko do poznania szczegółowych możliwości poszczególnych procków. Dzięki poznaniu tych rodzin łatwiej sobie później wybierać co potrzebne jest do docelowych układów a nie mieć klapki na oczach i na siłę próbować rozwiązywać problemy za pomocą tylko jednego narzędzia
no i znowu zaczęła się dyskusja na temat wyższością świąt Bożego narodzenia nad świętami Wielkanocnymi (czytaj: wyższości jednej rodziny procków nad inną rodziną) - totalne bzdury! każda rodzina jest dobra do odpowiednich zastosowań a argumenty typu:
Quote:
"istnieją takie aplikacje, do których niz z rodziny AVR się nie nadaje..."
to już okrutne stwierdzenie (tym bardziej jeśli ktoś zaczyna się tego uczyć i potrzebuje podłączyć jedną diodę LED jeden klawisz i zrobić pierwsze testy - do tego nadaje się procek z każdej rodziny) , szkoda tylko, że wciąż trzeba o tym ludziom przypominać aby takich bzdur nie wypisywali i sprzeczali się która rodzina jest lepsza. Przez to początkujący, którzy tu zaglądają - nie dziwię się że nie mogą żadnego sensownego wniosku wyciągnąć z tego typu co jakiś czas pojawiąjących się przekomarzań
Jeśli to, co napisałem to dla Ciebie bzdury, to wskaż mi, proszę, coś z rodziny AVR, co ma choćby 12bitowy przetwornik A/C i przetwornik C/A o rozdzielczości choćby i tylko 10bitów. Nie ma takiego modelu w rodzinie AVR? I nadal twierdzisz, że napisanie "są aplikacje, do których AVR się po prostu nie nadaje" jest bzdurą? Owszem, to jest okrutne stwierdzenie, ale zgodne z prawdą! Nie ma jednego dobrego rozwiązania dla wszystkich problemów i rodzina AVR nie jest tu wyjątkiem. W swoich projektach używam różnych mikrokontrolerów (C51, PIC, AVR, ARM) i zawsze dobieram mikrokontroler do konkretnego zastosowania, więc Twój zarzut, że mam klapki na oczach jest chybiony.
Poza tym sam sobie przeczysz:
mirekk36 wrote:
każda rodzina jest dobra do odpowiednich zastosowań a argumenty typu:
Cytat:
"istnieją takie aplikacje, do których niz z rodziny AVR się nie nadaje..."
to już okrutne stwierdzenie
Skoro według Ciebie każda rodzina nadaje się do odpowiednich zastosowań, to przecież jesteś świadomy, że istnieją takie zastosowania do których AVR się nie nadaje? Jeśli tak, to cóż Cię tak wzbudziło w mojej wypowiedzi? Może to, że tak lubiana przez Ciebie rodzina AVR została tak okrutnie potraktowana? Stosujesz inne rodziny, czy tylko AVR (jak to wynika z postów na elektrodzie)? Piszesz w asemblerze, C, C++, Bascomie czy tylko w Bascomie? Stosujesz różne systemy czasu rzeczywistego w swoich projektach? W skrócie: jesteś obiektywny?
I żeby była jasność: uważam, że mikrokotroler powinien być dobrany do zastosowania, a wpychanie wszędzie na siłę tylko i jedynie AVR, bo niby najlepsze (dyskusyjne), najtańsze (zależy od aplikacji), jest chybioną decyzją. Dla amatora rozpoczynającego przygodę z mikrokontrolerami każda rodzina jest równie dobra - gdzie napisałem, że jest inaczej?
.
)
) AA moze dochodzić nawet do 3Ah.
I nadal twierdzisz, że napisanie "są aplikacje, do których AVR się po prostu nie nadaje" jest bzdurą? Owszem, to jest okrutne stwierdzenie, ale zgodne z prawdą! Nie ma jednego dobrego rozwiązania dla wszystkich problemów i rodzina AVR nie jest tu wyjątkiem. W swoich projektach używam różnych mikrokontrolerów (C51, PIC, AVR, ARM) i zawsze dobieram mikrokontroler do konkretnego zastosowania, więc Twój zarzut, że mam klapki na oczach jest chybiony.
