Atrakcyjne procesory DIL8 z UART i wbudowanym generatorem zegara - jakie wybrać?
UART i maly procesorek
From: Administrator <tmf_at_nospam_wizzard.one.pl>
Subject: UART i maly procesorek
Date: Fri, 07 Nov 2003 16:51:52 +0100
Witam!
Poszukuje procesorka w obudowie najchetniej DIL8 lub jak najmniejszej w
wbudowanym ukladem generowania sygnalu zegarowego i posiadajacego UART.
Niestety wszystkie ATMELE sa albo male, albo maja UART, a ja nie chce
pakowac kostki DIL20 do czegos co ma sie komunikowac z kompem i oprocz
tego potrzebuje jeszcze jeden port wyjsciowy.
Pozdrawiam,
T.M.F.
========
Path: news-archive.icm.edu.pl!mat.uni.torun.pl!news.man.torun.pl!news2.icm.edu.pl!news.nask.pl!newsfeed.gazeta.pl!topaz.icpnet.pl!not-for-mai
From: "Sebasto" <sebastorCUT_at_nospam_wp.pl>
Subject: Re: UART i maly procesorek
Date: Fri, 7 Nov 2003 17:40:51 +0100
Poszukuje procesorka w obudowie najchetniej DIL8 lub jak najmniejszej w
wbudowanym ukladem generowania sygnalu zegarowego i posiadajacego UART.
Niestety wszystkie ATMELE sa albo male, albo maja UART, a ja nie chce
pakowac kostki DIL20 do czegos co ma sie komunikowac z kompem i oprocz
tego potrzebuje jeszcze jeden port wyjsciowy.
Najprosciej napisac samemu obsluge uarta :)
Sebasto
========
Path: news-archive.icm.edu.pl!mat.uni.torun.pl!news.man.torun.pl!news.man.poznan.pl!pwr.wroc.pl!panorama.wcss.wroc.pl!ict.pwr.wroc.pl!lublin.pl!news.onet.pl!newsfeed.tpinternet.pl!atlantis.news.tpi.pl!news.tpi.pl!www.wizzard.one.pl!new
From: "T.M.F." <tfrancuz_at_nospam_nospam.mp.pl>
Subject: Re: UART i maly procesorek
Date: Fri, 07 Nov 2003 18:50:06 +0100
Sebasto wrote:
Poszukuje procesorka w obudowie najchetniej DIL8 lub jak najmniejszej w
wbudowanym ukladem generowania sygnalu zegarowego i posiadajacego UART.
Niestety wszystkie ATMELE sa albo male, albo maja UART, a ja nie chce
pakowac kostki DIL20 do czegos co ma sie komunikowac z kompem i oprocz
tego potrzebuje jeszcze jeden port wyjsciowy.
Najprosciej napisac samemu obsluge uarta :)
Niby mozna, ale po co jesli byc moze najda sie gotowe rozwiazania ?
Tak wiec moze ktos mi poradzi ?
========
Path: news-archive.icm.edu.pl!mat.uni.torun.pl!news.man.torun.pl!news.man.poznan.pl!news.internetia.pl!newsfeed.tpinternet.pl!atlantis.news.tpi.pl!news.tpi.pl!not-for-mai
From: Kaldachar <kaldachar_at_nospam_gazeta.pl>
Subject: Re: UART i maly procesorek
Date: Fri, 07 Nov 2003 18:50:46 +0100
Niby mozna, ale po co jesli byc moze najda sie gotowe rozwiazania ?
Tak wiec moze ktos mi poradzi ?
Poszukaj gotowych bibliotek dla obsługi UART i wklej je do programu .
========
Path: news-archive.icm.edu.pl!mat.uni.torun.pl!news.man.torun.pl!news2.icm.edu.pl!newsfeed.tpinternet.pl!atlantis.news.tpi.pl!news.tpi.pl!www.wizzard.one.pl!new
From: "T.M.F." <tfrancuz_at_nospam_nospam.mp.pl>
Subject: Re: UART i maly procesorek
Date: Fri, 07 Nov 2003 20:59:31 +0100
Kaldachar wrote:
Niby mozna, ale po co jesli byc moze najda sie gotowe rozwiazania ?
Tak wiec moze ktos mi poradzi ?
Poszukaj gotowych bibliotek dla obsługi UART i wklej je do programu .
Moze to i racja. Chyba tak zrobie.
========
Path: news-archive.icm.edu.pl!news.rmf.pl!agh.edu.pl!news.agh.edu.pl!news2.icm.edu.pl!news.pw.edu.pl!not-for-mai
From: BLE_Maciek <i80c586_at_nospam_cyberspace_NO_SPAM_.org>
Subject: Re: UART i maly procesorek
Date: Mon, 10 Nov 2003 14:40:57 +0100
Fri, 07 Nov 2003 20:59:31 +0100 jednostka biologiczna o nazwie
"T.M.F." <tfrancuz_at_nospam_nospam.mp.pl> wyslala do portu 119
jednego z serwerow news nastepujace dane:
Niby mozna, ale po co jesli byc moze najda sie gotowe rozwiazania ?
Tak wiec moze ktos mi poradzi ?
Poszukaj gotowych bibliotek dla obsługi UART i wklej je do programu .
Moze to i racja. Chyba tak zrobie.
Sprobuj www.avrfreaks.com
PS: Przepraszam, kto wymyslil aby AVRy nazywac RISCami ??? Po lekturze
listy instrukcji cus mi sie nie wydaje zeby takie byly ... :-)
Ech kiedy wreszcie w powszechnym obiegu (czyt. "w sklepiku za rogiem")
pojawia sie tanie uC na rdzeniu x86 ?
========
Path: news-archive.icm.edu.pl!news.rmf.pl!agh.edu.pl!news.agh.edu.pl!news.onet.pl!not-for-mai
From: J.F. <jfox_nospam_at_nospam_poczta.onet.pl>
Subject: Re: UART i maly procesorek
Date: Mon, 10 Nov 2003 19:18:35 +0100
On Mon, 10 Nov 2003 14:40:57 +0100, BLE_Maciek wrote:
PS: Przepraszam, kto wymyslil aby AVRy nazywac RISCami ??? Po lekturze
listy instrukcji cus mi sie nie wydaje zeby takie byly ... :-)
Ale wiesz - tez cykl na instrukcje.
Ech kiedy wreszcie w powszechnym obiegu (czyt. "w sklepiku za rogiem")
pojawia sie tanie uC na rdzeniu x86 ?
w ok 1990 lat ?
Am186, Am 386 ..
J.
========
Path: news-archive.icm.edu.pl!news.rmf.pl!poznan.rmf.pl!news.man.poznan.pl!newsfeed.tpinternet.pl!atlantis.news.tpi.pl!news.tpi.pl!not-for-mai
From: Michal Baszynski <mbaszyns_at_nospam_ga.ze.ta.pl.>
Subject: Re: UART i maly procesorek
Date: Tue, 11 Nov 2003 00:08:53 +0100
On Mon, 10 Nov 2003 14:40:57 +0100, BLE_Maciek
<i80c586_at_nospam_cyberspace_NO_SPAM_.org> wrote:
PS: Przepraszam, kto wymyslil aby AVRy nazywac RISCami ??? Po lekturze
listy instrukcji cus mi sie nie wydaje zeby takie byly ... :-)
to po co ja czytasz? C nie masz ? ;-)
(Atmel ponoc twierdzi ze architektura byla opracowywana pod jezyki
wyzszego poziomu..)
Ech kiedy wreszcie w powszechnym obiegu (czyt. "w sklepiku za rogiem")
pojawia sie tanie uC na rdzeniu x86 ?
taki sam archaizm jak 8051 ;-)
Pozdr
Michal
========
Path: news-archive.icm.edu.pl!mat.uni.torun.pl!news.man.torun.pl!news.man.poznan.pl!newsfeed.gazeta.pl!news.internetia.pl!mimuw.edu.pl!news.mimuw.edu.pl!uw.edu.pl!news.pw.edu.pl!not-for-mai
From: BLE_Maciek <i80c586_at_nospam_cyberspace_NO_SPAM_.org>
Subject: Re: UART i maly procesorek
Date: Wed, 12 Nov 2003 16:23:41 +0100
Tue, 11 Nov 2003 00:08:53 +0100 jednostka biologiczna o nazwie Michal
Baszynski <mbaszyns_at_nospam_ga.ze.ta.pl.> wyslala do portu 119
jednego z serwerow news nastepujace dane:
PS: Przepraszam, kto wymyslil aby AVRy nazywac RISCami ??? Po lekturze
listy instrukcji cus mi sie nie wydaje zeby takie byly ... :-)
to po co ja czytasz? C nie masz ? ;-)
Mam i wole C niz assembler, ale czasem zastanawiam sie nad
zastosowaniami w ktorych niestety program w C nie wyrobi czasowo,
chyba ze nie na AVRrze tylko na TMS320... :-) Np. taki generator
sygnalu TV. Niestety na rysowanie jednej lini sa tylko 52us ... :-)
(Atmel ponoc twierdzi ze architektura byla opracowywana pod jezyki
wyzszego poziomu..)
Faktycznie, chodzilo im o maksymalne zaciemnienie tego co jest w
programie jezeli korzysta sie z asm a nie C :-)
Ech kiedy wreszcie w powszechnym obiegu (czyt. "w sklepiku za rogiem")
pojawia sie tanie uC na rdzeniu x86 ?
taki sam archaizm jak 8051 ;-)
No wiesz co :-/ ;-) 86-tka ma IMO najsympatyczniejsza architekture z
prockow ktore widzialem. Fajnie by bylo moc np. za 10zl kupic uC na
rdzeniu 86 (oczywiscie "full wypas": ISP, 32KBFLASH (co najmniej),
watchdog, ADC, koprocesor, ze 24 linie I/O (trojstanowe oczyw :-)),
przynajmniej 2 UARTy i... ech chyba wystarczy :-) )
========
Path: news-archive.icm.edu.pl!news.rmf.pl!agh.edu.pl!news.agh.edu.pl!news.onet.pl!newsfeed.tpinternet.pl!atlantis.news.tpi.pl!news.tpi.pl!not-for-mai
From: Michal Baszynski <mbaszyns_at_nospam_ga.ze.ta.pl.>
Subject: Re: UART i maly procesorek
Date: Wed, 12 Nov 2003 18:47:38 +0100
On Wed, 12 Nov 2003 16:23:41 +0100, BLE_Maciek
<i80c586_at_nospam_cyberspace_NO_SPAM_.org> wrote:
No wiesz co :-/ ;-) 86-tka ma IMO najsympatyczniejsza architekture z
prockow ktore widzialem.
a Motke 68k widziales?
szkoda ze TO u nas nie wyszlo.. (jak kazda motka zreszta)
Pozdr
Michal
========
Path: news-archive.icm.edu.pl!news.rmf.pl!poznan.rmf.pl!news.man.poznan.pl!news.supermedia.pl!news.nask.pl!uw.edu.pl!news.pw.edu.pl!not-for-mai
From: BLE_Maciek <i80c586_at_nospam_cyberspace_NO_SPAM_.org>
Subject: Re: UART i maly procesorek
Date: Thu, 13 Nov 2003 09:38:40 +0100
Wed, 12 Nov 2003 18:47:38 +0100 jednostka biologiczna o nazwie Michal
Baszynski <mbaszyns_at_nospam_ga.ze.ta.pl.> wyslala do portu 119
jednego z serwerow news nastepujace dane:
No wiesz co :-/ ;-) 86-tka ma IMO najsympatyczniejsza architekture z
prockow ktore widzialem.
a Motke 68k widziales?
szkoda ze TO u nas nie wyszlo.. (jak kazda motka zreszta)
A nie, nie widzialem jak bede mial czas to poogladam. Faktycznie taka
rewelacyjna ?
========
Path: news-archive.icm.edu.pl!news.rmf.pl!agh.edu.pl!news.agh.edu.pl!news.onet.pl!newsfeed.gazeta.pl!fu-berlin.de!uni-berlin.de!glubsche.ukbf.fu-berlin.DE!not-for-mai
From: Waldemar Krzok <waldemar.krzok_at_nospam_ukbf.fu-berlin.de>
Subject: Re: UART i maly procesorek
Date: Thu, 13 Nov 2003 10:41:27 +0100
BLE_Maciek:
No wiesz co :-/ ;-) 86-tka ma IMO najsympatyczniejsza architekture z
prockow ktore widzialem.
a Motke 68k widziales?
szkoda ze TO u nas nie wyszlo.. (jak kazda motka zreszta)
A nie, nie widzialem jak bede mial czas to poogladam. Faktycznie taka
rewelacyjna ?
do programowania w assemblerze świetna. Na studiach dłubałem programy na
M68K i 80(2)86 i było to niczym niebo i ziemia. Rejestry "do
wszystkiego", nie trzeba się było wściekać z jakimś mapowaniem,
segmentami i podobnym badziewiem. Jak coś zapisałeś pod adres 4711 to
tam było, czy kod, czy program. A było co robić: mały system operacyjny
multi tasking z loaderem, obsługą drukarki, terminala, czytnika i
dziurkarki kart i taśmy (hehe, wirtualnych, bo prawdziwych już nie
mieliśmy) na zaliczenie. No i wszystko w assemblerze.
Waldek
========
Path: news-archive.icm.edu.pl!news.rmf.pl!agh.edu.pl!news.agh.edu.pl!news2.icm.edu.pl!news.pw.edu.pl!not-for-mai
From: BLE_Maciek <i80c586_at_nospam_cyberspace_NO_SPAM_.org>
Subject: Re: UART i maly procesorek
Date: Thu, 13 Nov 2003 10:57:07 +0100
Thu, 13 Nov 2003 10:41:27 +0100 jednostka biologiczna o nazwie
Waldemar Krzok <waldemar.krzok_at_nospam_ukbf.fu-berlin.de> wyslala do portu 119
jednego z serwerow news nastepujace dane:
do programowania w assemblerze świetna. Na studiach dłubałem programy na
M68K i 80(2)86 i było to niczym niebo i ziemia. Rejestry "do
[...]
dziurkarki kart i taśmy (hehe, wirtualnych, bo prawdziwych już nie
mieliśmy) na zaliczenie. No i wszystko w assemblerze.
Wow. Nie no wiesz ja generalnie wole assemblera unikac, ale czesto
jest taka sytuacja ze trzeba pisac w assemblerze chocby z tego powodu
ze uC ma 2KB FLASHa i program w C to ie tam zbyt rozbudowany nie
miesci :-( Ale nawet jak mam w C pisac to wole znac architekture i
assembler procka chociazby na wypadek debugowania.
========
Path: news-archive.icm.edu.pl!news.rmf.pl!agh.edu.pl!news.agh.edu.pl!news2.icm.edu.pl!newsfeed.tpinternet.pl!atlantis.news.tpi.pl!news.tpi.pl!not-for-mai
From: "Piotr Wyderski" <piotr.wyderskiREMOWE_at_nospam_wp.pl>
Subject: Re: UART i maly procesorek
Date: Sat, 15 Nov 2003 18:45:15 +0100
Waldemar Krzok wrote:
do programowania w assemblerze świetna.
Zdecydowanie potwierdzam i podpisuje sie pod tym stwierdzeniem
wszystkimi konczynami. Przed 10. laty pisalem na 68K w asemblerze
jak huragan i ani mi sie snilo slyszec o jezykach wysokiego poziomu.
Na te ostatnie przeszedlem dopiero po marcu 96 r., gdy to za jeden
z moich motorolniczych programow [puszczony na wczesnej wersji
UAE :-)))] Optimus przyznal mi pierwsza nagrode w postaci peceta.
Asembler IA-32 tez szybko opanowalem, ale pod wzgledem wygody
niezwykle daleko mu do 68K. W sumie nie jest on jednak najgorszy,
ostatnio przetrawilem asembler AVR, lecz ciagle mi sie po nim odbija. ;-)
Z tego powodu nieustannie w kontekscie Atmela przypominaja mi sie
slowa Goryszewskiego: "co by tu jeszcze spieprzyc, panowie?"...
Rejestry "do wszystkiego"
Bardzo brakowalo instrukcji operujacych na bitach, w rodzaju
"znajdz indeks pierwszego zapalonego bitu". IA-32 je ma.
nie trzeba się było wściekać z jakimś mapowaniem
No, od mapowania rece precz; pamiec wirtualna to jeden
z najgenialniejszych w swojej prostocie znanych mi wynalazkow.
Co prawda na IA-32 jej implementacja jest taka sobie; chcieli
dobrze, wyszlo jak zwykle...
segmentami
Segmentacja pamieci to tez bardzo dobry pomysl, ale zdecydowanie
nie w tej formie, jak na IA-32. Zacznijmy od tego, ze segmenty nie
powinny byc w ogole widoczne, a selektory dostepne z poziomu trybu
uzytkownika. Sa procesory, ktore tak wlasnie maja, np. Alpha oraz
Itanium. Tam segmenty widzi tylko jadro, aplikacje maja wrazenie
pamieci liniowej.
Pozdrawiam
Piotr Wyderski
========
Path: news-archive.icm.edu.pl!news.rmf.pl!agh.edu.pl!news.agh.edu.pl!news.onet.pl!not-for-mai
From: J.F. <jfox_nospam_at_nospam_poczta.onet.pl>
Subject: Re: UART i maly procesorek
Date: Sat, 15 Nov 2003 20:57:23 +0100
On Sat, 15 Nov 2003 18:45:15 +0100, Piotr Wyderski wrote:
Przed 10. laty pisalem na 68K w asemblerze
jak huragan i ani mi sie snilo slyszec o jezykach wysokiego poziomu.
ostatnio przetrawilem asembler AVR, lecz ciagle mi sie po nim odbija. ;-)
Z tego powodu nieustannie w kontekscie Atmela przypominaja mi sie
slowa Goryszewskiego: "co by tu jeszcze spieprzyc, panowie?"...
A to nie byl Mlynarski ?
Rejestry "do wszystkiego"
Bardzo brakowalo instrukcji operujacych na bitach, w rodzaju
"znajdz indeks pierwszego zapalonego bitu". IA-32 je ma.
Malo uzyteczne w jezykach wyzszego poziomu. Nie napiszesz zrodla zeby
takowe wykorzystac. Przy 8 bitach mozna zastapic tablica.
nie trzeba się było wściekać z jakimś mapowaniem
No, od mapowania rece precz; pamiec wirtualna to jeden
z najgenialniejszych w swojej prostocie znanych mi wynalazkow.
Do motek dalo sie dolozyc w zewnetrznej kosci.
Co prawda na IA-32 jej implementacja jest taka sobie; chcieli
dobrze, wyszlo jak zwykle...
Co sp* ? Na pierwszy rzut oka nie zauwazylem wad.
segmentami
Segmentami nie trzeba sie przejmowac - plaski tryb 32-bit i po
segmentach. Ale mozna je wykorzystac.
O ile pamietam unixy na motorolkach robily segmentacje sztucznie -
wykorzystujac najstarsze bity adresu.
Segmentacja pamieci to tez bardzo dobry pomysl, ale zdecydowanie
nie w tej formie, jak na IA-32. Zacznijmy od tego, ze segmenty nie
powinny byc w ogole widoczne, a selektory dostepne z poziomu trybu
uzytkownika.
Hm, polemizowalbym. Jawne segmenty maja swoje zalety.
Szczegolnie jak pomyslisz o nowych zastosowaniach - np
zamapowanie kilku plikow do pamieci, o reszte niech sie martwi
driver pamieci wirtualnej ..
J.
========
Path: news-archive.icm.edu.pl!news.rmf.pl!agh.edu.pl!news.agh.edu.pl!news2.icm.edu.pl!newsfeed.tpinternet.pl!atlantis.news.tpi.pl!news.tpi.pl!not-for-mai
From: "Piotr Wyderski" <piotr.wyderskiREMOWE_at_nospam_wp.pl>
Subject: Re: UART i maly procesorek
Date: Sat, 15 Nov 2003 22:56:05 +0100
J.F. wrote:
A to nie byl Mlynarski ?
Na pewno Goryszewski z trybuny sejmowej, ale byc moze
faktycznie cytowal Mlynarskiego, tego juz niestety nie wiem. :-)
Malo uzyteczne w jezykach wyzszego poziomu. Nie napiszesz
zrodla zeby takowe wykorzystac.
W GCC jest dostepny wspanialy mechanizm wstawek asemblerowych,
wiec z wykorzystaniem nie ma problemu. Za pomoca wstawienia BSF
w kodzie w C++ zrobilem kolejke priorytetowa, uzyskujac kod
o olbrzymiej wydajnosci, nieosiagalnej za pomoca jakakolwiek innej
metody. To bylo dokladnie to, czego potrzebowalem -- za pomoca
pojedynczego zapytania od razu wiedzialem skad pobierac nowe dane.
Nie trzeba bylo lookup-tabelek ani drzewek decyzyjnych; cud instrukcja. :-)
Przy 8 bitach mozna zastapic tablica.
I stracic duzo niezwykle cennej pamieci podrecznej na jej pamietanie.
Poza tym ja mialem priorytety ustalane przez zawartosc 32-bitowego
slowa bez znaku, wiec tu lookup-tabelka bylaby cokolwiek duza... ;-)
Co sp* ? Na pierwszy rzut oka nie zauwazylem wad.
1. Elementy asocjacyjnej pamieci podrecznej translacji adresu
wirtualnego TLB sa indeksowane wylacznie adresem wirtualnym.
Dziala to dobrze, gdy procesor wykonuje jeden program, ale
w srodowisku wielozadaniowym to jest kula u nogi. Aby uniknac
interferencji z innymi procesami podczas przelaczania CPU do
innego procesu TLB musi zostac oproznione i nastepnie ponownie
wypelnione, co jest bardzo kosztownym zadaniem. Monolitycznym
mamutom w rodzaju systemow uniksowych albo Windows to malo
przeszkadza, bo przelaczaja one zadania ~100 razy na sekunde.
Dla moich ulubionych nowoczesnych systemow operacyjnych
opartych na mikrojadrze jest to jednak gigantyczny problem. One
w wiekszosci przypadkow sa niezwykle stabilne, bo wszystkie
sterowniki zostaly przeniesione do trybu uzytkownika, wiec
w zasadzie nic nie jest w stanie uszkodzic jadra. Ta forma obslugi
sprzetu wymaga jednak _bardzo czestego_ przelaczania CPU
miedzy roznymi zadaniami; w zasadzie podczas kazdego przerwania.
Dokladajac do tego wspoldzialanie calosci oparte na przekazywaniu
komunikatow, a nie wywolywaniu funkcji systemowych czestotliwosc
zmian kontekstu rzedu 50.000 na sekunde nie jest niczym dziwnym.
Nowoczesniejsze procesory uzupelniaja elementy TLB
o identyfikator procesu, do ktorego naleza i dzieki temu
absolutnie niczego nie trzeba uniewazniac, wiec zmiana
przestrzeni adresowej jest darmowa. Podsystem translacji
adresu po prostu sprawdza, czy znaleziony element moze
byc uzyty przez biezacy proces.
2. Proces translacji adresu wirtualnego odbywa sie na zasadzie
przegladania tablic odwzorowan (tj. tablic i katalogu stron w trybie
32-bitowym oraz dodatkowo katalogu katalogow stron w trybie
36-bitowej pamieci fizycznej). Stad:
a) algorytm wyboru odwzorowania jest okreslony przez projektanta,
wiec ja nie mam mozliwosci scislego dopasowania go do konkretnego
zastosowania ani implementacji technik adaptacyjnych.
b) tablice odwzorowan musza rezydowac w pamieci fizycznej,
a jednyny dostep do nich jest mozliwy jedynie przez pamiec
wirtualna. Z tego powodu na poziomie jadra trzeba robic takie
wygibasy z ich odwzorowaniami, ze glowa mala; w przypadku
systemow wieloprocesorowych krotko mowiac jest horror. :-(
c) bardzo duze zuzycie pamieci fizycznej, jesli wykorzystywany
obszar pamieci wirtualnej jest bardzo rozproszony.
d) prosty, dwupoziomowy mechanizm ochrony typu system
-uzytkownik. To jest wielki problem dla systemow SAS (Single
Address Space OS), bo uniemozliwia implementacje wydajnego
mechanizmu bezpiecznego dzielenia pamieci miedzy procesami.
e) w systemach wieloprocesorowych bardzo trudno zrealizowac
prywatne obszary pamieci fizycznej dla poszczegolnych procesorow,
odwzorowane pod tym samym adresem wirtualnym (aby uzyskac
pelna symetrie systemu). W praktyce kazdemu procesowi trzeba
wiec przydzielic kilka katalogow stron, opisujacych _prawie to
samo_, po jednym dla kazdego aktywnego procesora. To prowadzi
do koniecznosci zapewnienia synchronizacji ich zawartosci, co
jest bardzo niemile widziane, zarowno pod wzgledem kosztu, jak
i mozliwosci wprowadzenia nowych, bardzo trudnych do wykrycia
bledow.
Dziela madrzejszych projektantow nie korzystaja ze sprzetowych
tablic stron, sa wiec pozbawione powyzszych wad (poza (d)).
Jezeli nie maja potrzebnego odwzorowania w TLB, generuja
wyjatek, kazac policzyc potrzebny wynik systemowi i nastepnie
umiescic go w TLB. Te najlepsze CPU korzystaja z poprzedniej
metody, ale uzupelniaja ja o dodatkowe mechanizmy. Po pierwsze,
mechanizm ochrony stron jest nie jedno-, lecz 16--24 bitowy
(tzw. protection keys) i mozna wydajnie bez ryzyka dzielic pamiec.
Proces dostaje pewien zbior kluczy i moze w jego ramach korzystac
nawet (lub scislej: zwlaszcza...) z pamieci innych procesow. Po drugie
wiedza, ze translacja via tablica stron jest szybsza niz tlumaczenie
programowe, wiec pozwalaja systemowi wybrac, czy dany kawalek
ma byc tlumaczony przez tablice, czy przez podystsem VMM.
Tak ma m.in. Itanium. Jesli Cie ta tematyka interesuje, to duzo
informacji znajdziesz m.in. w doktoracie Kevina Elpinstone'a;
powinienem gdzies miec kopie, w razie potrzeby moge udostepnic.
Segmentami nie trzeba sie przejmowac - plaski tryb 32-bit i po
segmentach. Ale mozna je wykorzystac.
Alez ja sie nimi nie przejmuje, wprost przeciwnie, zamierzam
bardzo intensywnie z nich korzystac. Tylko chce by to byly
normalne, przezroczyste dla uzytkownika segmenty, a nie
wynalazek na ksztalt IA-32... Niejawne segmenty to wspaniale
narzedzie podczas przekazywania komunikatow miedzy
procesami; przypomina to pamiec wirtualna "drugiego poziomu".
O ile pamietam unixy na motorolkach robily segmentacje sztucznie -
wykorzystujac najstarsze bity adresu.
Co prawda nic nie wiem o takich szczegolach implementacji VMM
na Motorolkach, ale tak to wlasnie sie robi na Alphie i Itanium oraz
IIRC na MIPSie. Tzn. tam nie ma sztucznej symulacji, najstarsze
3 bity adresu wirtualnego to selektor segmentu, nie ma osobnych
rejestrow selektorow, jak na IA-32.
Hm, polemizowalbym.
Chetnie podyskutuje, bo ta dzialka to hobby w ramach zawodu :-)
Jawne segmenty maja swoje zalety.
Wymien je wiec. :-)
Szczegolnie jak pomyslisz o nowych zastosowaniach - np
zamapowanie kilku plikow do pamieci, o reszte niech sie martwi
driver pamieci wirtualnej ..
Przeciez to sie praktycznie od zawsze robi w pamieci wirtualnej,
a nie logicznej, a wiec nie ma nic wspolnego z segmentacja.
Plik A jest odwzorowany pod adresami (4096,8191), plik B
pod adresami (16384,65535) itd. -- tu _nie ma_ segmentacji.
Pozdrawiam
Piotr Wyderski
========
Path: news-archive.icm.edu.pl!news.rmf.pl!agh.edu.pl!news.agh.edu.pl!news.onet.pl!not-for-mai
From: J.F. <jfox_nospam_at_nospam_poczta.onet.pl>
Subject: Re: UART i maly procesorek
Date: Sun, 16 Nov 2003 11:12:13 +0100
On Sat, 15 Nov 2003 22:56:05 +0100, Piotr Wyderski wrote:
J.F. wrote:
A to nie byl Mlynarski ?
Na pewno Goryszewski z trybuny sejmowej, ale byc moze
faktycznie cytowal Mlynarskiego, tego juz niestety nie wiem. :-)
http://www.bohosiewicz.ip.pl/html/co.html
Myslalem ze to moze jakis teksciarz Mlynarskiego, ale jak z trybuny,
to cytowal :-)
[...]
Hm, polemizowalbym.
Chetnie podyskutuje, bo ta dzialka to hobby w ramach zawodu :-)
No, musialbym odswiezyc wiadomosci, bo szczegoly czytalem jak 386
wchodzilo :-)
[...]
Dziela madrzejszych projektantow nie korzystaja ze sprzetowych
tablic stron, sa wiec pozbawione powyzszych wad (poza (d)).
Jezeli nie maja potrzebnego odwzorowania w TLB, generuja
wyjatek, kazac policzyc potrzebny wynik systemowi i nastepnie
umiescic go w TLB.
Ale to jest kamyczek w to co lubisz - przerywamy proces na dlugi czas.
Hardware w Intelu robi to szybciej.
O ile pamietam unixy na motorolkach robily segmentacje sztucznie -
wykorzystujac najstarsze bity adresu.
Co prawda nic nie wiem o takich szczegolach implementacji VMM na Motorolkach,
Chyba wszystkie Unixy. Zauwaz ze tam wiele procesow uzywa tych samych
adresow logicznych, a obszary danych sa dynamicznie zmienne w
dlugosci. Musi byc jakas segmentacja.
Jawne segmenty maja swoje zalety.
Szczegolnie jak pomyslisz o nowych zastosowaniach - np
zamapowanie kilku plikow do pamieci, o reszte niech sie martwi
driver pamieci wirtualnej ..
Przeciez to sie praktycznie od zawsze robi w pamieci wirtualnej,
a nie logicznej, a wiec nie ma nic wspolnego z segmentacja.
Plik A jest odwzorowany pod adresami (4096,8191), plik B
pod adresami (16384,65535) itd. -- tu _nie ma_ segmentacji.
A co zrobic jak plik A sie rozrosnie z 4KB do 20KB ? Trzeba zmienic
adres bazowy, bo obszar od 16K jest juz zajety.
Zobacz jakie liczby wymieniles. Male. A jak bede chcial miec 200MB ?
i np 20 plikow ? Przestrzen logiczna 32-bit sie zuzyla. I co teraz
zrobic jak trzeba powiekszyc jeden z obszarow - zadanie
przeorganizowania robi sie trudne ..
Oczywiscie mozna uzyc procka 64 bit, podzielic sobie przestrzen w
miare dowolnie - na pare lat starczy. 32-bit obecnie jest za malo.
A to co oferuje intel [nie napisze "rozwiazanie Intela", bo to
zaszlosc historyczna a nie rozwiazanie :-)] jest stopniem posrednim -
adres logiczny robi sie 48 bitow, program jest efektywniejszy bo uzywa
danych 32bit, dostep do innych segmentow jest dosc efektywny
[szczegolnie w jakis nowszych Pentium, gdzie instrukcje
zmieniajace segment i adresy sa liczone rownolegle i wyprzedzeniem].
J.
========
Path: news-archive.icm.edu.pl!news.rmf.pl!agh.edu.pl!news.agh.edu.pl!news2.icm.edu.pl!newsfeed.tpinternet.pl!atlantis.news.tpi.pl!news.tpi.pl!not-for-mai
From: "Piotr Wyderski" <piotr.wyderskiREMOWE_at_nospam_wp.pl>
Subject: Re: UART i maly procesorek
Date: Sun, 16 Nov 2003 13:23:29 +0100
J.F. wrote:
Ale to jest kamyczek w to co lubisz - przerywamy proces na dlugi czas.
No, niestety nie ma niczego za darmo. :-( Powszechnie uzywane
algorytmy sa bardzo szybkie w srednim przypadku , wiec wiekszosc
kosztu zalezy od czasu wygenerowania i obslugi wyjatku. Jesli
calosc zmiesci sie, powiedzmy, w 200 cyklach, to problemu nie ma.
Hardware w Intelu robi to szybciej.
Oczywiscie, jak to hardware. Z tak szybkoscia to jednak tez nie jest
tak rozowo, ze wzgledu na nietrzymanie tablic odwzorowan w pamieci
podrecznej to cos okolo IIRC 30 cykli.
Chyba wszystkie Unixy. Zauwaz ze tam wiele procesow uzywa tych samych
adresow logicznych, a obszary danych sa dynamicznie zmienne w
dlugosci. Musi byc jakas segmentacja.
Hm, dobrze znam budowe wewnetrzna systemow uniksowych, ale
nie bardzo rozumiem co masz na mysli. Czy chodzi o to, ze pod tym
samym adresem kazdy proces moze widziec rozne dane? To sie
robi za pomoca pamieci wirtualnej. Na przyklad ani Linuks ani NT
nie korzystaja z segmentacji (w stopniu wiekszym, niz wymaga tego
budowa procesora). No, w NT4 TLS bylo implementowane za
pomoca osobnego segmentu, ale w tym kontekscie to sie nie liczy.
A co zrobic jak plik A sie rozrosnie z 4KB do 20KB ? Trzeba zmienic
adres bazowy, bo obszar od 16K jest juz zajety.
Ale adres bazowy odwzorowania pliku (tj. offset od poczatku),
a nie bloku pamieci wirtualnej. Po prostu przesuwa sie strony
w pamieci, NT ma do tego funkcje IIRC ZwMapViewOfSection().
Ze wzgledu na ograniczenia adresu wirtualnego odwzorowuje sie
okienko, a nie caly plik.
Zobacz jakie liczby wymieniles. Male.
To byl przyklad, w rzeczywistosci zostawia sie troche miejsca na
wzrost pliku (pare MiB jesli dobrze pamietam lekture "Inside
Windows NT", ale glowy nie dam).
A jak bede chcial miec 200MB ? i np 20 plikow ?
To bedziesz musial suwac strony. :-) Plik zawsze musi rezydowac
w pamieci wirtualnej, nawet jesli uzywasz segmentacji (bo translacja
adresu logicznego to w koncu jest glownie dodanie bazy). Jak Ci
sie nie zmiesci w pamieci wirtualnej, to tym bardziej w logicznej.
"Praw fizyki Pan nie zmienisz". :-)
Przestrzen logiczna 32-bit sie zuzyla. I co teraz zrobic jak trzeba
powiekszyc jeden z obszarow - zadanie przeorganizowania robi sie trudne ..
Bo jest dosc trudne, ale od ukrycia tego smutnego faktu jest API. :-)
Oczywiscie mozna uzyc procka 64 bit, podzielic sobie przestrzen w
miare dowolnie - na pare lat starczy. 32-bit obecnie jest za malo.
Tak, o wiele za malo... Itanium ma adres wirtualny 64 bity, logiczny
80 bitow (sic!).
Pozdrawiam
Piotr Wyderski
========
Path: news-archive.icm.edu.pl!news.rmf.pl!agh.edu.pl!news.agh.edu.pl!news.onet.pl!not-for-mai
From: J.F. <jfox_nospam_at_nospam_poczta.onet.pl>
Subject: Re: UART i maly procesorek
Date: Sun, 16 Nov 2003 22:22:30 +0100
On Sun, 16 Nov 2003 13:23:29 +0100, Piotr Wyderski wrote:
J.F. wrote:
Chyba wszystkie Unixy. Zauwaz ze tam wiele procesow uzywa tych samych
adresow logicznych, a obszary danych sa dynamicznie zmienne w
dlugosci. Musi byc jakas segmentacja.
Hm, dobrze znam budowe wewnetrzna systemow uniksowych, ale
nie bardzo rozumiem co masz na mysli. Czy chodzi o to, ze pod tym
samym adresem kazdy proces moze widziec rozne dane? To sie
robi za pomoca pamieci wirtualnej.
Nie - chodzi o to ze masz logiczne segmenty pamieci: kod programu,
stos, dane, ewentualnie biblioteki dzielone, pamiec jadra itp.
I do de facto powinny byc wlasnie segmenty, tylko czesto sie je po
partyzancku zalatwia stalymi obszarami adresowymi.
A co zrobic jak plik A sie rozrosnie z 4KB do 20KB ? Trzeba zmienic
adres bazowy, bo obszar od 16K jest juz zajety.
Ale adres bazowy odwzorowania pliku (tj. offset od poczatku),
a nie bloku pamieci wirtualnej. Po prostu przesuwa sie strony
w pamieci, NT ma do tego funkcje IIRC ZwMapViewOfSection().
O cos innego mi chodzi - chcesz powiekszyc okienko. Nie miec na raz
4KB, tylko 10, no niech bedzie 12KB. Niby nic trudnego ..
ale wtedy to okienko bedzie pod adresem logicznym powiedzmy od 0 do
12cos. I tu maly pech - obszar od 8192 przydzielilismy innemu okienku.
Teraz trzeba jedno z okienek przestawic pod inny adres, co nie jest
wielkim problemem, ale w programie trzeba zmienic adresy okienka we
wszystkich wystapieniach - a to juz moze byc wiekszy problem.
Uzycie segmentacji IA32 problem by rozwiazalo.
Nastepny problem - fragmentacja przestrzenii adresowej [logicznej].
Moze nie przy okienkach plikow, bardziej przy przydziale pamieci.
Alokujemy 100MB, alokujemy 1MB, zwalniamy 100MB, alokujemy 102MB.
I tak 10 razy, biorac coraz wiekszy blok - ale w sumie to 120MB nie
przekroczymy. I bryndza - pamieci rzeczywistej jest powiedzmy 512MB,
a przydzielic nie ma gdzie, bo dany system na dane procesu przeznacza
obszar logiczny od 40000000 do 7fffffffh. Zreszta niech nie ma tego
ograniczenia, a i tak szybko sie wyczerpie.
J.
========
Path: news-archive.icm.edu.pl!news.rmf.pl!news.ipartners.pl!news.nask.pl!uw.edu.pl!news.pw.edu.pl!not-for-mai
From: BLE_Maciek <i80c586_at_nospam_cyberspace_NO_SPAM_.org>
Subject: Re: UART i maly procesorek
Date: Sun, 16 Nov 2003 14:55:04 +0100
Sat, 15 Nov 2003 18:45:15 +0100 jednostka biologiczna o nazwie "Piotr
Wyderski" <piotr.wyderskiREMOWE_at_nospam_wp.pl> wyslala do portu 119
jednego z serwerow news nastepujace dane:
niezwykle daleko mu do 68K. W sumie nie jest on jednak najgorszy,
ostatnio przetrawilem asembler AVR, lecz ciagle mi sie po nim odbija. ;-)
Z tego powodu nieustannie w kontekscie Atmela przypominaja mi sie
slowa Goryszewskiego: "co by tu jeszcze spieprzyc, panowie?"...
Racja, ja sie wlasnie zaczalem ostatnio bawic assemblerem i AVR i
wniosek mam jeden - bez kompilatora C nie podchodzic :-))))
========
Path: news-archive.icm.edu.pl!news.rmf.pl!news.ipartners.pl!newsfeed.tpinternet.pl!atlantis.news.tpi.pl!news.tpi.pl!not-for-mai
From: Michal Baszynski <mbaszyns_at_nospam_ga.ze.ta.pl.>
Subject: Re: UART i maly procesorek
Date: Sun, 16 Nov 2003 18:00:01 +0100
On Sun, 16 Nov 2003 14:55:04 +0100, BLE_Maciek
<i80c586_at_nospam_cyberspace_NO_SPAM_.org> wrote:
Racja, ja sie wlasnie zaczalem ostatnio bawic assemblerem i AVR i
wniosek mam jeden - bez kompilatora C nie podchodzic :-))))
wreszcie rozsadny wniosek :-)
ja na avr w asemblerze napisalem moze ze dwa prosciutkie programiki i
szybko przeszedlem na C :-)
Pozdr
Michal
========
Path: news-archive.icm.edu.pl!news.rmf.pl!agh.edu.pl!news.agh.edu.pl!news.onet.pl!newsgate.onet.pl!newsgate.p
From: zielpro_at_nospam_poczta.onet.pl (ziel)
Subject: RE: UART i maly procesorek
Date: 18 Nov 2003 10:27:13 +0100
On Behalf Of BLE_Maciek
Racja, ja sie wlasnie zaczalem ostatnio bawic assemblerem i AVR i
wniosek mam jeden - bez kompilatora C nie podchodzic :-))))
Manualnie to jest do bani. szczegolnie po przesiadce z '51.
Ale po treningu przyspieszania BASCOM'a, to zaczyna byc
zrozumialy ;-)
pzdr
Artur
PS
jak z czasem?
Bo u mnie krucho :-(
--
Zaloz prywatne forum:
http://forum.onet.pl
========
Path: news-archive.icm.edu.pl!news.rmf.pl!poznan.rmf.pl!news.man.poznan.pl!news.nask.pl!uw.edu.pl!news.pw.edu.pl!not-for-mai
From: BLE_Maciek <i80c586_at_nospam_cyberspace_NO_SPAM_.org>
Subject: Re: UART i maly procesorek
Date: Tue, 18 Nov 2003 20:27:06 +0100
18 Nov 2003 10:27:13 +0100 jednostka biologiczna o nazwie
zielpro_at_nospam_poczta.onet.pl (ziel) wyslala do portu 119
jednego z serwerow news nastepujace dane:
Racja, ja sie wlasnie zaczalem ostatnio bawic assemblerem i AVR i
wniosek mam jeden - bez kompilatora C nie podchodzic :-))))
Manualnie to jest do bani. szczegolnie po przesiadce z '51.
Ale po treningu przyspieszania BASCOM'a, to zaczyna byc
zrozumialy ;-)
Pozyjemy, zobaczymy ;-)
jak z czasem?
Bo u mnie krucho :-(
Aaa tak sobie ... :-/ A co znowu jakies chlani^H^H^H^H^H^Hspotkanie
planujecie ?
========
Path: news-archive.icm.edu.pl!news.rmf.pl!agh.edu.pl!news.agh.edu.pl!news.onet.pl!newsfeed.tpinternet.pl!atlantis.news.tpi.pl!news.tpi.pl!not-for-mai
From: Michal Baszynski <mbaszyns_at_nospam_ga.ze.ta.pl.>
Subject: Re: UART i maly procesorek
Date: Thu, 13 Nov 2003 11:46:01 +0100
On Thu, 13 Nov 2003 09:38:40 +0100, BLE_Maciek
<i80c586_at_nospam_cyberspace_NO_SPAM_.org> wrote:
A nie, nie widzialem jak bede mial czas to poogladam. Faktycznie taka
rewelacyjna ?
rewelacja to nie jest, bo swoje lata ma ;-)
Typowa Motorola, czyli prosta i logiczna, bez cyrkow typu segmentacja
pamieci jak w x86.
Ale na bazie MC68000 powstalo wiele jednoukladowcow, do niedawna
powszechnie stosowanych np. w telefonach komorkowych.
Pozdr
Michal
========
Path: news-archive.icm.edu.pl!news.rmf.pl!agh.edu.pl!news.agh.edu.pl!news.onet.pl!newsgate.onet.pl!niusy.onet.p
From: "Marcin Stanisz" <mstanisz_at_nospam_WYTNIJTOpoczta.onet.pl>
Subject: Re: UART i maly procesorek
Date: 18 Nov 2003 20:35:56 +0100
a Motke 68k widziales?
szkoda ze TO u nas nie wyszlo.. (jak kazda motka zreszta)
Ja przepraszam, że tak między wódkę i zakąskę ;-), ale z tym nie wyjściem,
to letka przesada. Mam kolegę, który tłucze oprogramowanie do terminali
(gry, L***OMATY :-), zakłady na odległość itp.). I to wszystko na 68k...
Ostatnio ciężko go było od ściany odróżnić - z DES-em walczył ;-))
Pozdrawiam
Marcin Stanisz, kończący właśnie projekt na mega32 ;-)
--
Wysłano z serwisu OnetNiusy: http://niusy.onet.pl
========
Path: news-archive.icm.edu.pl!news.rmf.pl!agh.edu.pl!news.agh.edu.pl!news.onet.pl!newsfeed.tpinternet.pl!atlantis.news.tpi.pl!news.tpi.pl!not-for-mai
From: jerry1111 <stop_this_spam_jerry1111_remove_at_nospam_remove.wp.pl>
Subject: Re: UART i maly procesorek
Date: Tue, 11 Nov 2003 00:52:33 +0100
PS: Przepraszam, kto wymyslil aby AVRy nazywac RISCami ??? Po lekturze
listy instrukcji cus mi sie nie wydaje zeby takie byly ... :-)
-)
Ech kiedy wreszcie w powszechnym obiegu (czyt. "w sklepiku za rogiem")
pojawia sie tanie uC na rdzeniu x86 ?
A po kiego grzyba? Toz to paskudna architektura...
Trza bylo byc na pizzy, to bym powiedzial jak sie prosto
dzisiaj procki dobiera :-)
--
Jerry
========
Path: news-archive.icm.edu.pl!news.rmf.pl!agh.edu.pl!news.agh.edu.pl!news.onet.pl!not-for-mai
From: J.F. <jfox_nospam_at_nospam_poczta.onet.pl>
Subject: Re: UART i maly procesorek
Date: Tue, 11 Nov 2003 12:27:58 +0100
On Tue, 11 Nov 2003 00:52:33 +0100, jerry1111 wrote:
Ech kiedy wreszcie w powszechnym obiegu (czyt. "w sklepiku za rogiem")
pojawia sie tanie uC na rdzeniu x86 ?
A po kiego grzyba? Toz to paskudna architektura...
Czemu ? 8086 ma nienajgorsza architekture 16-bit,
386 nienajgorsze 32 bit :-)
J.
========
Path: news-archive.icm.edu.pl!news.rmf.pl!news.ipartners.pl!newsfeed.gazeta.pl!news.onet.pl!newsgate.onet.pl!newsgate.p
From: zielpro_at_nospam_poczta.onet.pl (ziel)
Subject: RE: UART i maly procesorek
Date: 12 Nov 2003 00:35:20 +0100
On Behalf Of J.F.
Czemu ? 8086 ma nienajgorsza architekture 16-bit,
386 nienajgorsze 32 bit :-)
No. I semi-sprzetowe sprzezenie do ko-procesora.
Po 8-bitowcach, sam miodzik ;-)
pzdr
Artur
PS
A ile softu wala sie po internecie ;-D
--
Zaloz prywatne forum:
http://forum.onet.pl
========
Path: news-archive.icm.edu.pl!news.rmf.pl!agh.edu.pl!news.agh.edu.pl!news2.icm.edu.pl!news.pw.edu.pl!not-for-mai
From: BLE_Maciek <i80c586_at_nospam_cyberspace_NO_SPAM_.org>
Subject: Re: UART i maly procesorek
Date: Wed, 12 Nov 2003 16:31:46 +0100
Tue, 11 Nov 2003 00:52:33 +0100 jednostka biologiczna o nazwie
jerry1111 <stop_this_spam_jerry1111_remove_at_nospam_remove.wp.pl> wyslala do
portu 119 jednego z serwerow news nastepujace dane:
Ech kiedy wreszcie w powszechnym obiegu (czyt. "w sklepiku za rogiem")
pojawia sie tanie uC na rdzeniu x86 ?
A po kiego grzyba? Toz to paskudna architektura...
Ale user ...ehm... programmer friendly :-)
Trza bylo byc na pizzy, to bym powiedzial jak sie prosto
dzisiaj procki dobiera :-)
A jak sie dobiera ? ;-) (oprocz tego ze prosto ;-))
BTW: Wygrzebalem cus na ten ksztalt u Nationala, ale takie zabawki to
nie w "sklepiku za rogiem" i nie za 5-10 zl :-(
Jak kogos interesuje to jest to NS486SXL i ... ech wkleje tutaj co
ciekawsze bajery:
Features
- Intel486 instruction set compatible (protected mode only)
with optimized performance
- Operation at 25 MHz with 5V supply
- Industry standard interrupt controller, timers, and real
time clock
- Protected WATCHDOG? timer
- Optimized DRAM Controller (supports two banks, up to
8 Mbytes each)
- Up to nine versatile, programmable chip selects
- Up to eight external interrupts directly supported, and
additional interrupt expansion through an external PIC
interface
- Glueless interface to ISA-type peripherals
- Support for External Bus Masters, allowing them to
access DRAM and on-chip Peripherals
- UART with IrDA v1.0 (Infrared Data Association) port
- Reconfigurable I/O: Up to 28 I/O pins can be used as
general purpose bidirectional I/O lines
Chcialoby sie taka zabawke ... :-/
========
Path: news-archive.icm.edu.pl!news.rmf.pl!agh.edu.pl!news.agh.edu.pl!news.onet.pl!lublin.pl!uw.edu.pl!news.pw.edu.pl!news.itl.waw.pl!not-for-mai
From: "Jacek R. Radzikowski" <jacek_at_nospam_piranet.org>
Subject: Re: UART i maly procesorek
Date: Wed, 12 Nov 2003 18:24:04 +0000 (UTC)
BLE_Maciek <i80c586_at_nospam_cyberspace_no_spam_.org> wrote:
[...]
Jak kogos interesuje to jest to NS486SXL i ... ech wkleje tutaj co
ciekawsze bajery:
Z czemu nie jakis malutki ARM, np. phillipsowski LPC210x (to tylko
fragment listy ficzerow):
o 16/32 bit ARM7TDMI-S processor.
o 16/32/64 kB on-chip Static RAM.
o 128 kB on-chip Flash Program Memory. 128 bit wide
interface/accelerator enables high speed 60 MHz operation. In-System
Programming (ISP) and In-Application Programming (IAP) via on-chip
boot-loader software. Flash programming takes 1 ms per 512 byte line.
o Vectored Interrupt Controller with configurable priorities and vector
addresses.
o Multiple serial interfaces including two UARTs (16C550), Fast I?C
(400 kbits/s) and SPI.
o Two 32-bit timers (7 capture/compare channels), PWM unit (6 outputs),
Real Time Clock and Watchdog.
o Up to thirty-two 5 V tolerant general purpose I/O pins in a tiny
LQFP48 (7 x 7 mm2) package.
o 60 MHz maximum CPU clock available from programmable on-chip
Phase-Locked Loop.
o On-chip crystal oscillator with an operating range of 10 MHz to 25
MHz.
A do tego pobor pradu rzedu 30mA przy zasilaniu napieciem 1.8V (rdzen).
Ceny jakis znalazlem na sieci to ok. $7-$9, ale przy zamowieniu palety
250 szt :( No i nie w "sklepiku za rogiem" :(
j.
========
Path: news-archive.icm.edu.pl!news.rmf.pl!poznan.rmf.pl!news.man.poznan.pl!newsfeed.tpinternet.pl!atlantis.news.tpi.pl!news.tpi.pl!hs001.slackware.pl!new
From: Jan Dubiec <jdx_at_nospam_slackware.pl>
Subject: Re: UART i maly procesorek
Date: 12 Nov 2003 22:43:30 +0100
On Wed, 12 Nov 2003 18:24:04 +0000 (UTC), "Jacek R. Radzikowski" <jacek_at_nospam_piranet.org> wrote:
[.....]
Z czemu nie jakis malutki ARM, np. phillipsowski LPC210x (to tylko
fragment listy ficzerow):
ARM-y to bardzo modny temat na c.a.embedded, a ostatnio w/w Philipsy.
Jak dla mnie największą zaletą jest duża ilość wewnętrznego SRAM-u
i przyzwoita ilość Flash-a - IMO ciężko jest znaleźć taki uC. Wiesz
może czym różni się rdzeń ARM7TDMI-S od ARM7TDMI? Chodzi mi po prostu
o to, czy będzie do niego pasować standartowe ARM-owe gcc & co..
[.....]
A do tego pobor pradu rzedu 30mA przy zasilaniu napieciem 1.8V (rdzen).
Ceny jakis znalazlem na sieci to ok. $7-$9, ale przy zamowieniu palety
250 szt :( No i nie w "sklepiku za rogiem" :(
Czy w PL można wogóle gdzieś kupić próbki tej kostki?
Regards,
/J.D.
--
Jan Dubiec, jdx_at_nospam_slackware.pl, mobile: +48 602 101787
Głęboka wiara wymaga płytkiego rozumu i nikłej wiedzy.
========
Path: news-archive.icm.edu.pl!news.rmf.pl!news.ipartners.pl!news.nask.pl!uw.edu.pl!news.pw.edu.pl!news.itl.waw.pl!not-for-mai
From: "Jacek R. Radzikowski" <jacek_at_nospam_piranet.org>
Subject: Re: UART i maly procesorek
Date: Thu, 13 Nov 2003 02:00:15 +0000 (UTC)
Jan Dubiec <jdx_at_nospam_slackware.pl> wrote:
On Wed, 12 Nov 2003 18:24:04 +0000 (UTC), "Jacek R. Radzikowski" <jacek_at_nospam_piranet.org> wrote:
[.....]
Z czemu nie jakis malutki ARM, np. phillipsowski LPC210x (to tylko
fragment listy ficzerow):
ARM-y to bardzo modny temat na c.a.embedded, a ostatnio w/w Philipsy.
Jak dla mnie największą zaletą jest duża ilość wewnętrznego SRAM-u
i przyzwoita ilość Flash-a - IMO ciężko jest znaleźć taki uC. Wiesz
może czym różni się rdzeń ARM7TDMI-S od ARM7TDMI? Chodzi mi po prostu
o to, czy będzie do niego pasować standartowe ARM-owe gcc & co..
Niestety kostki nie znam. O samych armach slyszalem juz wczesniej, ale
o ich popularnosci i wszechstronnosci dowiedzialem sie czytajac wlasnie
c.a.e. Z tego co widze to ktos nawet zaprojektowal prosta plytke
ewaluacyjna dla tej kostki i udostepnil caly projekt.
Nie wiem niestety czym roznia sie te architektury, ale z tego co sie
doczytalem to dzialaja standardowe narzedzia GNU.
Zerknij sobie na http://www.geocities.com/leon_heller/lpc2104.html,
tam jest opis projektu.
[.....]
A do tego pobor pradu rzedu 30mA przy zasilaniu napieciem 1.8V (rdzen).
Ceny jakis znalazlem na sieci to ok. $7-$9, ale przy zamowieniu palety
250 szt :( No i nie w "sklepiku za rogiem" :(
Czy w PL można wogóle gdzieś kupić próbki tej kostki?
tego niestety nie wiem:( moze bedzie miala elfa czy ktos podobny.
A tak w ogole to chetnie bym pobawil sie jakims armem. Ale niestety
na tak czasochlonne hobby na razie nie moge sobie pozwolic :(
(a i tak zakolejkowanych mam kilka innych projektow w roznym stadium
realizacji:)
pzdr.
j.
========
Path: news-archive.icm.edu.pl!news.rmf.pl!agh.edu.pl!news.agh.edu.pl!news.onet.pl!not-for-mai
From: Artur Lipowski <LAL_at_nospam_pro.onet.pl>
Subject: Re: UART i maly procesorek
Date: Thu, 13 Nov 2003 08:23:17 +0100
Jan Dubiec wrote:
...
i przyzwoita ilość Flash-a - IMO ciężko jest znaleźć taki uC. Wiesz
może czym różni się rdzeń ARM7TDMI-S od ARM7TDMI? Chodzi mi po prostu
o to, czy będzie do niego pasować standartowe ARM-owe gcc & co..
Będzie pasować.
Literka S oznacza tylko "synthesizable" i sprowadza się do tego, że
rdzeń ARM-a jest w jakiś sposób dostosowany do reszty mikrokontrolera
przez producenta tegoż mikrokontrolera, ale ARM wyraźnie stwierdza, że:
"Code written for ARM7TDMI-S is binary-compatible with other members of
the ARM7 Family and forwards compatible with ARM9, ARM9E and ARM10
families".
IMHO ARM to "miodzo" w programowaniu (szczególnie jak się niedawno
pisało na ADSP21xx ;-) Ma parę b. ciekawych pomysłów wziętych z procków
DSP i możliwość efektywnego używania rozkazów 16-bitowych (tzw. thumb mode).
Czy w PL można wogóle gdzieś kupić próbki tej kostki?
Tej to nie wiem, ale np. małe ARM-y z Atmela AT91 są w miarę dostepne.
Niestey nie mają wbudowango FLASH-a.
Pozdrawiam,
--
Artur Lipowski
========
Path: news-archive.icm.edu.pl!news.rmf.pl!agh.edu.pl!news.agh.edu.pl!news.onet.pl!lublin.pl!uw.edu.pl!news.pw.edu.pl!news.itl.waw.pl!not-for-mai
From: "Jacek R. Radzikowski" <jacek_at_nospam_piranet.org>
Subject: Re: UART i maly procesorek
Date: Thu, 13 Nov 2003 08:52:04 +0000 (UTC)
Artur Lipowski <LAL_at_nospam_pro.onet.pl> wrote:
Jan Dubiec wrote:
...
i przyzwoita ilość Flash-a - IMO ciężko jest znaleźć taki uC. Wiesz
może czym różni się rdzeń ARM7TDMI-S od ARM7TDMI? Chodzi mi po prostu
o to, czy będzie do niego pasować standartowe ARM-owe gcc & co..
Będzie pasować.
[...]
No prosze, milo wiedziec ze ktos zajmuje sie czyms innym niz ubostwiane
tutaj AVRki ;)
j.
========
Path: news-archive.icm.edu.pl!news.rmf.pl!agh.edu.pl!news.agh.edu.pl!news.onet.pl!newsfeed.tpinternet.pl!atlantis.news.tpi.pl!news.tpi.pl!not-for-mai
From: Michal Baszynski <mbaszyns_at_nospam_ga.ze.ta.pl.>
Subject: Re: UART i maly procesorek
Date: Wed, 12 Nov 2003 23:49:34 +0100
On Wed, 12 Nov 2003 18:24:04 +0000 (UTC), "Jacek R. Radzikowski"
<jacek_at_nospam_piranet.org> wrote:
Z czemu nie jakis malutki ARM,
a czemu nie :-)
tyko problem polega na tym, ze te co maja FLASH-a sa jak na razie
zwykle w obudowie typu BGA :-(
np. phillipsowski LPC210x
nigdy..
z calym szcunkiem dla Philipsa, ale polityke
informacyjno-dokumentacyjna maja do d...
Zwykle w momencie zaprzestania produkcji cala dokumentacja znika i
jest juz nie do dostania :-(
Pozdr
Michal
========
Path: news-archive.icm.edu.pl!news.rmf.pl!poznan.rmf.pl!news.man.poznan.pl!news.nask.pl!uw.edu.pl!news.pw.edu.pl!news.itl.waw.pl!not-for-mai
From: "Jacek R. Radzikowski" <jacek_at_nospam_piranet.org>
Subject: Re: UART i maly procesorek
Date: Thu, 13 Nov 2003 02:10:44 +0000 (UTC)
Michal Baszynski <mbaszyns_at_nospam_ga.ze.ta.pl.> wrote:
On Wed, 12 Nov 2003 18:24:04 +0000 (UTC), "Jacek R. Radzikowski"
<jacek_at_nospam_piranet.org> wrote:
Z czemu nie jakis malutki ARM,
a czemu nie :-)
tyko problem polega na tym, ze te co maja FLASH-a sa jak na razie
zwykle w obudowie typu BGA :-(
Akurat ten maluch jest w LQFP48 :)
np. phillipsowski LPC210x
nigdy..
z calym szcunkiem dla Philipsa, ale polityke
informacyjno-dokumentacyjna maja do d...
Zwykle w momencie zaprzestania produkcji cala dokumentacja znika i
jest juz nie do dostania :-(
Hm, dobrze wiedziec. Ale na razie, jakby co, mozna sobie poczytac.
Zreszta zerknij sobie na http://www.geocities.com/leon_heller/lpc2104.html
i http://www.semiconductors.philips.com/pip/LPC2104.html.
W porownaniu do innych armow jest dosc tani i jak na te cene prezentuje
sie calkiem niezle.
Najwieksza wada to to, ze ucLinuxa raczej na nim sie nie ruszy i trzeba
wszystko samemu pisac od zera:)
pzdr.
j.
========
Path: news-archive.icm.edu.pl!news.rmf.pl!agh.edu.pl!news.agh.edu.pl!news2.icm.edu.pl!news.pw.edu.pl!not-for-mai
From: BLE_Maciek <i80c586_at_nospam_cyberspace_NO_SPAM_.org>
Subject: Re: UART i maly procesorek
Date: Thu, 13 Nov 2003 09:40:07 +0100
Wed, 12 Nov 2003 18:24:04 +0000 (UTC) jednostka biologiczna o nazwie
"Jacek R. Radzikowski" <jacek_at_nospam_piranet.org> wyslala do portu 119
jednego z serwerow news nastepujace dane:
Z czemu nie jakis malutki ARM, np. phillipsowski LPC210x (to tylko
fragment listy ficzerow):
o 16/32 bit ARM7TDMI-S processor.
[...]
o On-chip crystal oscillator with an operating range of 10 MHz to 25
MHz.
No fajne, fajne tylko ze i tak poza naszym zasiegiem :-(
========
Path: news-archive.icm.edu.pl!news.rmf.pl!news.ipartners.pl!newsfeed.tpinternet.pl!atlantis.news.tpi.pl!news.tpi.pl!hs001.slackware.pl!new
From: Jan Dubiec <jdx_at_nospam_slackware.pl>
Subject: Re: UART i maly procesorek
Date: 12 Nov 2003 22:16:23 +0100
On Wed, 12 Nov 2003 16:31:46 +0100, BLE_Maciek <i80c586_at_nospam_cyberspace_NO_SPAM_.org> wrote:
Tue, 11 Nov 2003 00:52:33 +0100 jednostka biologiczna o nazwie
jerry1111 <stop_this_spam_jerry1111_remove_at_nospam_remove.wp.pl> wyslala do
portu 119 jednego z serwerow news nastepujace dane:
Ech kiedy wreszcie w powszechnym obiegu (czyt. "w sklepiku za rogiem")
pojawia sie tanie uC na rdzeniu x86 ?
A po kiego grzyba? Toz to paskudna architektura...
Ale user ...ehm... programmer friendly :-)
Nie żartuj. :-) O x86 można powiedzieć wszystko, tylko nie to że jest
programmer friendly. :-)
Trza bylo byc na pizzy, to bym powiedzial jak sie prosto
dzisiaj procki dobiera :-)
A jak sie dobiera ? ;-) (oprocz tego ze prosto ;-))
BTW: Wygrzebalem cus na ten ksztalt u Nationala, ale takie zabawki to
nie w "sklepiku za rogiem" i nie za 5-10 zl :-(
Jak kogos interesuje to jest to NS486SXL i ... ech wkleje tutaj co
ciekawsze bajery:
Że tak powiem: phi, też mi cudo. :-) Cudo to by było gdyby rzeczywiście
można to było kupić w każdym sklepie za rogiem za 10PLN. :-)
--
Jan Dubiec, jdx_at_nospam_slackware.pl, mobile: +48 602 101787
Głęboka wiara wymaga płytkiego rozumu i nikłej wiedzy.
========
Path: news-archive.icm.edu.pl!mat.uni.torun.pl!news.man.torun.pl!news.man.poznan.pl!news-fra1.dfn.de!eusc.inter.net!newsfeed01.sul.t-online.de!t-online.de!newsfeed.tpinternet.pl!atlantis.news.tpi.pl!news.tpi.pl!not-for-mai