W dniu 2014-04-06 00:42, AlexY pisze:
> Użytkownik Pszemol napisał:
>> "AlexY" <a...@i...pl> wrote in message
> [..]
>>> Przesiadkę na "coś większego" robię jeśli to co mam jest za małe, nie
>>> widzę innego sensownego uzasadnienia. Argument finansowy tak dość
>>> średnio do mnie przemawia, poza ceną scalaka dochodzi koszt osprzętu,
>>> oprogramowania i konieczność nauki czegoś nowego.
>>
>> Nie o to mi chodziło abyś przesiadał się dziś na coś większego...
>>
>> Chodziło mi o to, że w kontekście przesiadki o którą OP zapytał,
>> nie warto się przesiadać dziś z procka 8 bitowego na inne procki
>> 8-bitowe. Inwestujesz czas i pieniądze w nowe narzędzia, naukę
>> nowej rodziny tak czy inaczej, a zatem warto raczej zapoznać się
>> z rodziną procesorów która ma przyszłość i pułap możliwości
>> znacznie wyżej niż jakikolwiek 8-bitowy procesor jaki sobie wymyślisz.
>
> To też zależy, np przesiądę się na PIC'e bo mają wbudowany eeprom czego
> mi coraz częściej w 89Cxx brakuje, robiąc termostat obszedłem to
> zapisując nastawy do czujnika, akurat 2 wolne bajty ma. Przesiadka
> niejako z jednego 8-bitowca na innego, żaden postęp, ale mi wystarczy.
> Zresztą nie wyobrażam sobie programować ARM w assemblerze a póki co
> tylko to uznaję.

A tego to nie rozumiem. Może chciałeś napisać "tylko to znam"?
Jaka jest korzyść z pisania w asemblerze? Tylko nie pisz o tym, że w
asemblerze łatwiej ci się uda napisać program, który będzie
wystarczająco szybki i zwarty żeby sobie poradzić z ograniczeniami
sprzętowymi 8-bitowca.

--
pozdrawiam
MD

do góry

W dniu 2014-04-06 13:56, janusz_k pisze:

>>> Że w armach jest coś takiego jak event-system lub coś o podobnej
>>> funkcjonalności, z zastrzeżeniem, że nie szukałem tego, traktuję na
>>> razie jako cechę rodziny XMega.
>>
>> Ja widzisz nie znam tej xmega, nie wiem o czym mówisz jeśli chodzi
>> o te "eventy", ale podejrzewam że to tak hucznie nazwali system
>> przerwań który wybudza procesor ze stanu uśpienia lub stymuluje
>> niezależne od procesora DMA aby pobrało dane z urządzenia zgłaszającego
>> przerwanie i jak transmisja danych się skończy to obudziły procesor do
>> obliczeń...
> Nie, ewenty to są przerwania ale nie od wyróżnionych wejść jak w starych
> ale od wszystkich z detekcją 0,1 zbocza narastającego i opadającego oraz
> wielopoziomowy dekoder przewań do tego.


To tak jak w ARMach :)




--
pozdrawiam
MD

do góry

Użytkownik Pszemol napisał:
> "AlexY" <a...@i...pl> wrote in message
[..]
>> Zresztą nie wyobrażam sobie programować ARM w assemblerze
>> a póki co tylko to uznaję.
>> Niemniej rozumiem Twoją logikę.
>
> Programujesz w asemblerze bo musisz wycisnąć siódme poty z 8-bitowca
> co ma 2k romu i 2k ramu pracującego przy 40MHz...
> Tymczasem za podobne pieniądze możesz dziś kupić 32-bitowca z 64k
> romu i 16k ramu pracującego z zegarem 200MHz i pisać szybszy kod w C
> kończąc pisanie w 10% czasu jaki spędzasz na cyzylowanie kodu w ASM.

1. Chcę wiedzieć co program robi a nie analizować i poprawiać błędy
kompilatora, zwłaszcza że co kompilator to inaczej program złożony.
2. ASM rozumiem, C C++ i pochodne to dla mnie sieczka stworzona żeby
wyrwać kasę na szkolenie specjalistów, bardzo lubiłem basic'a, jest
przejrzysty, nie można było go rozbudować?
3. Gdybym miał przesiąść się na coś pokroju ARM to prędzej byłby to
gotowiec typu raspberry.
4. Czas pisania programu, to najbardziej mnie załamuje, prawda że asm
zajmuje dużo czasu, ale błędy są wtedy moje a nie kompilatora. Załamka
polega na tym że w imię przyśpieszenia programowania poświęca się jakość
ale to niestety normalne w obecnych czasach, program napisany ze 3 razy
szybciej wychodzi 2 razy większy i 5 razy wolniejszy, a do tego mimo że
napisany prawidłowo zawiera błędy kompilatora, znane i nieznane.

--
AlexY
http://faq.enter.net.pl/simple-polish.html
http://www.pg.gda.pl/~agatek/netq.html

do góry

Użytkownik Mario napisał:
> W dniu 2014-04-06 00:42, AlexY pisze:
[..]
>> niejako z jednego 8-bitowca na innego, żaden postęp, ale mi wystarczy.
>> Zresztą nie wyobrażam sobie programować ARM w assemblerze a póki co
>> tylko to uznaję.
>
> A tego to nie rozumiem. Może chciałeś napisać "tylko to znam"?

Nie, nie tylko, ASM, pascal, basic. Tych potrzebowałem to się nauczyłem,
zrobiłem podejście do C i C++ ale chyba już za stary jestem bo mi się
odechciało, może to kwestia braku odpowiedniej literatury napisanej w
sposób dla mnie zrozumiały.

> Jaka jest korzyść z pisania w asemblerze? Tylko nie pisz o tym, że w
> asemblerze łatwiej ci się uda napisać program, który będzie
> wystarczająco szybki i zwarty żeby sobie poradzić z ograniczeniami
> sprzętowymi 8-bitowca.

Nikt nigdy nie wmówi mi że asm jest łatwy, jego podstawowa zaleta to
wiedza co w danym momencie się dzieje z każdym bitem, całkowita kontrola
sprzętu, zawsze, wszystkie procedury bez skrępowania mogę okroić z
funkcji których nie użyję, nie wiem czy tak samo można grzebać w
bibliotekach C. np obsługa LCD HD44780 wyciąć obsługę 8bitowej
transmisji i odczyt stanu wyświetlacza.

Nikogo nie zamierzam przekonać do swoich racji wiem że rynek wymusił
pisanie szybko bo na chlebek nie zarobisz, ale czy to jest rzeczywiście
dobre?

--
AlexY
http://faq.enter.net.pl/simple-polish.html
http://www.pg.gda.pl/~agatek/netq.html

do góry

W dniu 2014-04-06 14:28, AlexY pisze:
> Użytkownik Pszemol napisał:
>> "AlexY" <a...@i...pl> wrote in message
> [..]
>>> Zresztą nie wyobrażam sobie programować ARM w assemblerze
>>> a póki co tylko to uznaję.
>>> Niemniej rozumiem Twoją logikę.
>>
>> Programujesz w asemblerze bo musisz wycisnąć siódme poty z 8-bitowca
>> co ma 2k romu i 2k ramu pracującego przy 40MHz...
>> Tymczasem za podobne pieniądze możesz dziś kupić 32-bitowca z 64k
>> romu i 16k ramu pracującego z zegarem 200MHz i pisać szybszy kod w C
>> kończąc pisanie w 10% czasu jaki spędzasz na cyzylowanie kodu w ASM.
>
> 1. Chcę wiedzieć co program robi a nie analizować i poprawiać błędy
> kompilatora, zwłaszcza że co kompilator to inaczej program złożony.

O jakich błędach mówisz? Używam gcc od bodajże 2009 roku i nie musiałem
poprawiać żadnych błędów kompilacji. No chyba, że za błąd uważasz to co
Sylwek opisał w swojej analizie kodu w sąsiednim wątku. Czyli, że
kompilator zastosował w kodzie wynikowym operacje na bajtach zamiast na
słowach. No i jak taki błąd wpływa na prawidłowe działanie kodu?

> 2. ASM rozumiem, C C++ i pochodne to dla mnie sieczka stworzona żeby
> wyrwać kasę na szkolenie specjalistów, bardzo lubiłem basic'a, jest
> przejrzysty, nie można było go rozbudować?

Uważasz, że żeby nauczyć się c to trzeba się odpłatnie szkolić u
specjalistów? No to może w tym jest twój problem. Ja po nastu latach
rzeźbienia w asm wziąłem się ze sporą niechęcią za c - przymuszony
koniecznością przejścia na coś mocniejszego od 51. Po zrobieniu kilku
projektów na AVRach w AVR-gcc, uznałem, że to nie tędy droga i
przeszedłem na ARMy. I nie żałuję. Nie muszę wiedzieć co program robi na
poziomie pojedynczych komend kodu maszynowego. Ważne czy robi to co
zapiszę w c i jakby co mogę to podejrzeć w debuggerze.
Rozumiem też twój sentyment do BASICa. Przy przesiadce tez żałowałem, że
nie mogę się przestawić na BASIC, czy Fortran lub Algol. C w porównaniu
do nich wydawał mi się jakiś zawiły. Ale uwierz nawet
pięćdziesięciolatek jest w stanie się go nauczyć bez pomocy specjalistów.

> 3. Gdybym miał przesiąść się na coś pokroju ARM to prędzej byłby to
> gotowiec typu raspberry.

To oczywiście jest jakaś opcja. Ale raczej dla programisty linuksowego,
który chce sobie zrobić sterownik do domu czy drona. Nie wyobrażam sobie
dawanie Raspberry czy innych gotowych modułów do moich komercyjnych
produktów.

> 4. Czas pisania programu, to najbardziej mnie załamuje, prawda że asm
> zajmuje dużo czasu, ale błędy są wtedy moje a nie kompilatora.

Napisz coś konkretnego o tych błędach kompilatora. I w czym są gorsze od
błędów własnych?

> Załamka
> polega na tym że w imię przyśpieszenia programowania poświęca się jakość
> ale to niestety normalne w obecnych czasach, program napisany ze 3 razy
> szybciej wychodzi 2 razy większy i 5 razy wolniejszy,

I wrzuca się go na 10 razy szybki procek. W efekcie czas realizacji
zadania jest mniejszy, koszt zarazem też niższe, a wydajność procka wraz
z oprogramowania wyższa.

> a do tego mimo że
> napisany prawidłowo zawiera błędy kompilatora, znane i nieznane.

Z błędami kompilatora jest tak jak z błędami w architekturze procka. Są
znane i nieznane. Jak masz pecha to możesz na nie trafić.
Jak siedzisz w temacie i korzystasz z wiedzy zawartej w dużej
społeczności masz duże szanse dowiedzieć się o tych błędach i ich
unikać. A największe społeczności są teraz zgromadzone wokół ARMów i gcc.


--
pozdrawiam
MD

do góry

W dniu 2014-04-06 14:39, AlexY pisze:
> Użytkownik Mario napisał:
>> W dniu 2014-04-06 00:42, AlexY pisze:
> [..]
>>> niejako z jednego 8-bitowca na innego, żaden postęp, ale mi wystarczy.
>>> Zresztą nie wyobrażam sobie programować ARM w assemblerze a póki co
>>> tylko to uznaję.
>>
>> A tego to nie rozumiem. Może chciałeś napisać "tylko to znam"?
>
> Nie, nie tylko, ASM, pascal, basic. Tych potrzebowałem to się nauczyłem,
> zrobiłem podejście do C i C++ ale chyba już za stary jestem bo mi się
> odechciało, może to kwestia braku odpowiedniej literatury napisanej w
> sposób dla mnie zrozumiały.

No to chyba młodszy jesteś ode mnie bo ja uczyłem się Algolu i Fortranu.
DO nauki c wystarczył mi Kernighan Ritchie oraz kieszonkowy leksykon c z
serii O'Reilly.

>> Jaka jest korzyść z pisania w asemblerze? Tylko nie pisz o tym, że w
>> asemblerze łatwiej ci się uda napisać program, który będzie
>> wystarczająco szybki i zwarty żeby sobie poradzić z ograniczeniami
>> sprzętowymi 8-bitowca.
>
> Nikt nigdy nie wmówi mi że asm jest łatwy,

Nie piszę, że łatwy tylko, że większe ma się szanse na to, że program
będzie wystarczająco mały i wystarczająco szybki aby zmieścić się w
osmiobitowcu i maksymalnie wykorzystać jego słabą wydajność. Czyli
ciężką pracą kodera, bohatersko zwalcza się problemy wynikające ze
słabej architektury.

> jego podstawowa zaleta to
> wiedza co w danym momencie się dzieje z każdym bitem, całkowita kontrola
> sprzętu,

Dopóki ten sprzęt jest wystarczająco prosty aby go ogarnąć.

> zawsze, wszystkie procedury bez skrępowania mogę okroić z
> funkcji których nie użyję, nie wiem czy tak samo można grzebać w
> bibliotekach C. np obsługa LCD HD44780 wyciąć obsługę 8bitowej
> transmisji i odczyt stanu wyświetlacza.

Możesz to zrobić. Jeśli biblioteka ma dużo kodu, a wykorzystujesz tylko
małą część to możesz wyciąć te funkcje, wkleić wprost do swojego kodu
albo zapisać jako inną bibliotekę. Tu ograniczeniem może być licencja.
Często się korzysta z dorobku innych zawartego w domenie publicznej.
Dołączenie czyjegoś kodu np. na GPL wprost do twojego kodu powodowałoby
wymóg opublikowania twojego kodu. Często jest jednak tak, że licencja
zezwala na używanie zamkniętego kodu twojego własnego programu, a
publikować trzeba jedynie zmiany w środowisku jak funkcje biblioteczne
czy sterowniki. Wtedy lepiej zmianę jakiejś biblioteki zapisać jako nową
bibliotekę i ewentualnie opublikować w razie potrzeby.

> Nikogo nie zamierzam przekonać do swoich racji wiem że rynek wymusił
> pisanie szybko bo na chlebek nie zarobisz, ale czy to jest rzeczywiście
> dobre?

Czy pisanie w c pod linuksa czy systemy BSD jest twoim zdaniem
niewłaściwe, bo nie panuje się nad efektem kompilacji? Superkomputery,
routery, duża część serwerów internetowych, systemy dowodzenia i
prowadzenia ognia. Lepiej i bezpieczniej byłoby gdyby to wszystko pisać
w asemblerze?


--
pozdrawiam
MD

do góry

"Sylwester Łazar" <i...@a...pl> wrote in message
news:lhrgpt$quv$1@mx1.internetia.pl...
>> Programujesz w asemblerze bo musisz wycisnąć siódme poty z 8-bitowca
> Nie musi, ale chce.
>> co ma 2k romu i 2k ramu pracującego przy 40MHz...
>> Tymczasem za podobne pieniądze możesz dziś kupić 32-bitowca z 64k
>> romu i 16k ramu pracującego z zegarem 200MHz i pisać szybszy kod w C
>> kończąc pisanie w 10% czasu jaki spędzasz na cyzylowanie kodu w ASM.
> I potem premiera WINDOWS9.

Myślę że Gates udowodnił swoim portfelem który model biznesu się sprawdza.
Ty masz satysfakcję że Twoja pętla ma tylko 40 instrukcji a on ma miliardy
dolarów i nie wie co z nimi zrobić...

do góry

"AlexY" <a...@i...pl> wrote in message
news:lhrhae$j9a$1@speranza.aioe.org...
> Użytkownik Pszemol napisał:
>> "AlexY" <a...@i...pl> wrote in message
> [..]
>>> Zresztą nie wyobrażam sobie programować ARM w assemblerze
>>> a póki co tylko to uznaję.
>>> Niemniej rozumiem Twoją logikę.
>>
>> Programujesz w asemblerze bo musisz wycisnąć siódme poty z 8-bitowca
>> co ma 2k romu i 2k ramu pracującego przy 40MHz...
>> Tymczasem za podobne pieniądze możesz dziś kupić 32-bitowca z 64k
>> romu i 16k ramu pracującego z zegarem 200MHz i pisać szybszy kod w C
>> kończąc pisanie w 10% czasu jaki spędzasz na cyzylowanie kodu w ASM.
>
> 1. Chcę wiedzieć co program robi a nie analizować i poprawiać błędy
> kompilatora, zwłaszcza że co kompilator to inaczej program złożony.

Jakie błędy kompilatora chcesz poprawiać?? To jakieś mity.

> 2. ASM rozumiem, C C++ i pochodne to dla mnie sieczka stworzona żeby
> wyrwać kasę na szkolenie specjalistów, bardzo lubiłem basic'a, jest
> przejrzysty, nie można było go rozbudować?

Zostaw na chwilę C++, bo to trochę inna bajka, rzeczywiście, ale C,
stare dobre C, to właściwie asembler jest. To nie jest język wysokiego
poziomu. Jest właśnie bardzo krytykowany za "bliskość sprzętu".

Poza specyficznymi przypadkami pisanie dziś w asemblerze to jakieś
hobby tylko, hardcore zupełnie niepraktyczny.

C/C++ to nie jest "sieczka" do wyrywania kasy - miliony programistów
go rozumie i używa na codzień. I wcale nie są geniuszami, więc może
nie dołuj się i po prostu poczytaj trochę podstaw od C a przekonasz się
że trochę wprawy i poradzisz sobie. Dużo Ci to pracy zaoszczędzi.

> 3. Gdybym miał przesiąść się na coś pokroju ARM to prędzej byłby to
> gotowiec typu raspberry.

Każdy ma inne oczekiwania - gotowiec to jakiś tam start i dobrze
służy do poznania rodziny procesorów, zrobienia pierwszych kroków,
ale potem warto pójść dalej - implementacja ARMa na własnej płytce
nie jest jakimś wyczynem do którego wymagana jest znajomość
prowadzenia wysokomegaherzowych magistral pamięci DDR3...
Tu też masz do czynienia z mikrokontrolerami gdzie wszystko masz
zamknięte wewnątrz kostki, jak w AVR czy 8051 czy PICu...
Nie bardzo więc widzę gdzie Ty widzisz trudność że w AVR zrobisz
płytkę samemu a do ARMa musisz mieć jakiegoś gotowca...

> 4. Czas pisania programu, to najbardziej mnie załamuje, prawda że asm
> zajmuje dużo czasu, ale błędy są wtedy moje a nie kompilatora. Załamka
> polega na tym że w imię przyśpieszenia programowania poświęca się jakość
> ale to niestety normalne w obecnych czasach, program napisany ze 3 razy
> szybciej wychodzi 2 razy większy i 5 razy wolniejszy, a do tego mimo że
> napisany prawidłowo zawiera błędy kompilatora, znane i nieznane.

Te Twoje mityczne "błędy kompilatora" to chyba błędy programisty
piszącego nieumiejętnie w C... Na codzień piszę programy w C i C++
i z błędami kompilatorów nie mam do czynienia wcale.

do góry

"janusz_k" <J...@o...pl> wrote in message news:op.xdv8rwspn0u1o8@moj...
>>> 128A1/A1U. Ma też np. 4 I2C. I trochę ADC, parę DAC i jeszcze trochę.
>>> Nawet magistralę dla zewnętrznej pamięci, niestety tylko w wersji z
>>> dodatkowym rejestrem.
>>
>> OK, czyli nic nadzwyczajnego czego nie miałby typowy
>> 32-bitowy Cortex M3 czy M4 z ARMa do kupienia za 20zł.
> Mylisz się, nie każdy arm ma np 2Ms ADC, mają lpc a stm-y nie.
> tak sama z dac-ami np 1Ms.

Nie każdy ARM ma wszystko... zgoda.
Wybierasz takiego ARMa który ma to, co potrzebujesz.
I co się zwykle okazuje, że ma wydajność 10 razy większą
niż 8-bitowiec w tej samej cenie.

Zrozum, ceny procesorów 8-bitowych dzisiaj są nadmuchane.
Dlaczego są nadmuchane? Bo producenci trzymają Cię w garści.
Płacisz jak za zboże bo musisz. Musisz, bo tylko te znasz...
Tylko tego proca zastosujesz jak mniejszy Ci okaże się za mały.
Producent wie, że przesiadka na inną rodzinę to koszty zaporowe
i dlatego ustawia takie ceny na procki 8-bitowe bo jeszcze jest
na nie jako taki popyt.

To jest analogia jak z pamięciami DDR czy starymi prockami do
pecetów... Ceny DDR2 o tej samej pojemności sa WIĘKSZE niż
ceny szybszych DDR3 - Ceny szybszych procków i3 są takie same
lub niższe jak wolniejszych, starszych procków LGA775 dlaczego?
Bo DDR2 czy procek LGA775 wstawia się jako retrofity do starszych
maszyn, aby robić upgrade... Rynek zdyskontował fakt, że aby
przesiąść się na inna platformę trzeba wydać więcej: nowa płyta,
nowy ram, nowy proc, często nowy zasilacz itp, itd... Więc Cię rypią
bez mydła za stary procek czy pamięć więcej niż za nowe...

To samo jest z prockami 8-bitowymi w stosunku do procków ARM.

>>>>> nie wiem jak jest z systemem eventów w ARMach,
>>>>> ale raczej wątpię.
>>>>
>>>> Ale w co wątpisz? :-)
>>>
>>> Że w armach jest coś takiego jak event-system lub coś o podobnej
>>> funkcjonalności, z zastrzeżeniem, że nie szukałem tego, traktuję na
>>> razie jako cechę rodziny XMega.
>>
>> Ja widzisz nie znam tej xmega, nie wiem o czym mówisz jeśli chodzi
>> o te "eventy", ale podejrzewam że to tak hucznie nazwali system
>> przerwań który wybudza procesor ze stanu uśpienia lub stymuluje
>> niezależne od procesora DMA aby pobrało dane z urządzenia zgłaszającego
>> przerwanie i jak transmisja danych się skończy to obudziły procesor do
>> obliczeń...
> Nie, ewenty to są przerwania ale nie od wyróżnionych wejść jak w starych
> ale od wszystkich z detekcją 0,1 zbocza narastającego i opadającego oraz
> wielopoziomowy dekoder przewań do tego.

No to samo masz w ARMach... nie widze tu żadnej rewelacji.

>>>>> Co nie zmienia faktu, że mówimy o zupełnie innych urządzeniach.
>>>>
>>>> Ja widzę same podobieństwa, Ty różnice... :-)
>>>
>>> ARMy można traktować od strony elektrycznej (dostępnych wyprowadzeń)
>>> jak rozwinięcie procesorów starszych. XMegi też są rozwinięciem, ale w
>>> inną stronę. Pozostawiono 8 bitów, za to dodano trochę MHz i przede
>>> wszystkim mocno rozbudowano i usystematyzowano peryferia. Popatrz na
>>> rozkład nóg w obudowie TQFP (bo BGA to inna bajka i regularność nie
>>> jest już taka ważna) i na ich funkcje, szczególnie dla portów C, D, E i
>>> F, ale też nawet A i B.
>>
>> Dokładnie tak samo można powiedzieć o ARMach - usystematyzowano
>> peryferia i taki Cortex M3 od ST będzie miał prawie to samo co Cortex M3
>> z NXP, nawet kod w C z jednego proca Ci się skompiluje pod drugi bo
>> peryferia są ustandaryzowane... A peryferiów jest w ciul i trochę.
>> Aczkolwiek proca z 8 uartami nie widziałem w stajni ARMa, ale nie
>> widziałem wszystkiego - może taki jest.
>> Wydaje się że jakiś znawca ARMów dopowie
> Nie przesadzałbym z tym ustandaryzowaniem.
> Jest burdel, prawie każdy producent nma swoje.

Co ma swoje?
Ja mówię o standardowej bibliotece CMSIS:
http://www.arm.com/products/processors/cortex-m/cort
ex-microcontroller-software-interface-standard.php

>> Przekładanie GOTOWEGO projektu z jednej rodziny proców na drugą
>> to oczywiście inna klasa zagadnień. Ja mówię w temacie: znam 8-bitowce,
>> widzę że mają pułap bardzo nisko i się zwyczajnie kończą... Czas poznać
>> coś nowego: tu miejsce dla ARMów. Przesiadka z PIC czy 8051 na AVR
>> nie ma sensu dzisiaj, bo przy cenach kostek 32-bitowych z rdzeniem ARMa
>> na pokładzie czas AVRów jest policzony
> Mylisz się, wcale nie jest policzony. Dla początkujących to s ą idealne
> procki stosunkowo proste do opanowania i zaprogramowania.

Dla początkujących... i potem co? Zainwestujesz czas w naukę
a potem zmiana i od nowa będziesz się uczył od początku?
To jest bez sensu - jak już robisz inwestycję czasu i gromadzisz wiedzę
to lepiej uczyć się procesorów z dużej rodziny i dziś popularnej a nie
procesorów popularnych 20-30 lat temu wychodzących dziś z użycia.

To coś tak jak byś powiedział że docelowo chcesz się nauczyć języka
niemieckiego i wyemigrować do Berlina... Ale ponieważ jesteś początkujący
to na początek nauczysz się języka ruskiego, bo jest dla Ciebie, Polaka,
łatwiejszy niż niemiecki, "na początek"... Widzisz bezsens w tej logice? :-)

Naprawdę nie ma się czego bać ARMów.
To jest dzisiaj procesor do nauki dla początkującego.
Masz całą rodzinę Cortexów do poznania: M0, M1, M3 a nawet
M4 z koprocesorem zmiennoprzecinkowym... Do wyboru do koloru.
Najmniejsze, najtańsze M0 w małych obudowach kosztować Cię
będą DUŻO, DUŻO MNIEJ niż 8-bitowce dzisiaj...

do góry

W dniu 2014-04-06 13:17, Pszemol pisze:
> "Dariusz Dorochowicz" <_...@w...com> wrote in message
>> 128A1/A1U. Ma też np. 4 I2C. I trochę ADC, parę DAC i jeszcze trochę.
>> Nawet magistralę dla zewnętrznej pamięci, niestety tylko w wersji z
>> dodatkowym rejestrem.
>
> OK, czyli nic nadzwyczajnego czego nie miałby typowy
> 32-bitowy Cortex M3 czy M4 z ARMa do kupienia za 20zł.

Oczywiście :)
Tyle, że za taką XMegę płacę jednak sporo mniej, szczególnie biorąc pod
uwagę "dodatki" typu wielkie złącze JTAGa w ARMie (koszt PCB, a raczej
zajmowanego miejsca też jest ważny). Tak, wiem że nie musi być aż tak
duże bo połowa to masy, a i resztę można ograniczyć.

>> Że w armach jest coś takiego jak event-system lub coś o podobnej
>> funkcjonalności, z zastrzeżeniem, że nie szukałem tego, traktuję na
>> razie jako cechę rodziny XMega.
>
> Ja widzisz nie znam tej xmega, nie wiem o czym mówisz jeśli chodzi
> o te "eventy", ale podejrzewam że to tak hucznie nazwali system
> przerwań który wybudza procesor ze stanu uśpienia lub stymuluje
> niezależne od procesora DMA aby pobrało dane z urządzenia zgłaszającego
> przerwanie i jak transmisja danych się skończy to obudziły procesor do
> obliczeń...

Bo o to chodzi, żeby było coś, czego inni nie mają itd - trzeba dobrze
nazwać. Ale to jest jednak więcej niż system przerwań. Raczej coś w
stylu prostego FPGA nałożonego okrakiem "na procek".
http://www.atmel.com/Images/Atmel-8385-8-and-16-bit-
AVR-Microcontroller-ATxmega64A1U-ATxmega128A1U_datas
heet.pdf
strona 18
Nie to, żeby się z tego często korzystało, ale można i trochę ułatwia
pewne rozwiązania.

> Przekładanie GOTOWEGO projektu z jednej rodziny proców na drugą
> to oczywiście inna klasa zagadnień. Ja mówię w temacie: znam 8-bitowce,
> widzę że mają pułap bardzo nisko i się zwyczajnie kończą... Czas poznać
> coś nowego: tu miejsce dla ARMów. Przesiadka z PIC czy 8051 na AVR
> nie ma sensu dzisiaj, bo przy cenach kostek 32-bitowych z rdzeniem ARMa
> na pokładzie czas AVRów jest policzony i dziś nie ma sensu się ich uczyć
> jako czegoś nowego - co nie oznacza że taki gość jak Ty, co już masz z nimi
> doświadczenie, powinien je rzucić w czambuł i zająć się czymś nowym :-)

Ale z tym nie dyskutuję - też tak uważam, chociaż na koniec 8-bitowców
jeszcze trochę trzeba poczekać.

>> Oczywiście jest miejsce dla jednej jak i drugiej rodziny procesorów,
>> zresztą sama moc procesorów jest zupełnie inna. Bardzo bym się
>> ucieszył z ARMa, który byłby zrobiony jak XMega128A1, najlepiej gdyby
>> była również wersja z np 144 nogami, bo 208 to już trochę spory układ
>> (fizycznie).
>
> Wśród ARMów są też układy z małą ilością nóg.

:)
Marzy mi się ARM 8-16 nóg. Dostępny oczywiście u nas i programowany
"byle czym", w sensie kompilatora i programatora ;)
Z tym, że nóg może mieć więcej.

Pozdrawiam

DD

do góry