kontrolery
Masz problem? Zapytaj na forum elektroda.pl z bramką pl.misc.elektronika!
From: Piotr Laskowski <Piotr.Laskowski_at_nospam_f117.n480.z2.fidonet.org>
Date: Sun, 16 Aug 98 10:50:40 +0200
Subject: kontrolery
Cześć Jaroslaw !
>> Wybieram kontroler do swojego sortownika fasoli. [...]
JL> Nie wiem jakie masz na mysli algorytmy przetwarzania tego obrazu, ale
JL> jak na moj gust nie tedy droga. Chocby ten RAM - starczy Ci 256B,
JL> jesli jedna linia obrazu ma 64 ?
Co do algorytmu, to zle ziarno jest ciemniejsze (zielone, albo splesniale),
albo ma ciemne plamki. Na poczatek probowalbym okreslac kolor (odcien szarosci)
pixela, ewentualnie szybkosc zmiany koloru pomiedzy sasiednimi pixelami. Jaka
bedzie dokladnosc i powtarzalnosc takiego sortowania to juz pokaze praktyka.
Odnosnie zapotrzebowania pamiec, to mam trzy mozliwosci:
1. obrabiam kazdy pixel osobno, mam kilka licznikow pixli o okreslonych
przedzialach jasnosci. Po zeskanowaniu calego ziarna porownuje ile jest zlych
punktow. Zapotrzebowanie na pamiec do obrobki rzedu 20B
2. obrabiam cala linijke obrazu - moge okreslic szerokosc ziarna (krawedzie),
rozmiar ciemniejszej plamki, dopuszczalna monotonicznosc zmian barwy.
Zapotrzebowanie na pamiec rzedu 200B
3. obrabiam cale ziarno- moge pokusic sie o okreslenie ksztaltu porownujac ze
wzorcem (stosunek wysokosci do szerokosci), moge przeleciec sie po pixlach
pionowo, a nie tylko poziomo. Zapotrzebowanie na RAM rzadu 20 kB
Mysle ze zostane przy pierwszych 2 wariantach, potem zobaczymy...
JL> Sugeruje bardziej solidny komputer na jakims chipie DSP, 186, Am386,
JL> transputer, 68332, H8 .. nie bedzie problemu z RAM, ewentualnym DMA,
JL> trybami adresowania w dostepie do pamieci, itp.
JL> Albo od razu peceta postawic.
Obawiam sie o koszty, jak rowniez o wlasne mozliwosci. Nie wiem czy w tej
chwili jestem w stanie cos takiego wykonac i oprogramowac. Wydaje mi sie ze
gorna poprzeczka bedzie na wysokosci 16 bitowego kontrolera.
Chociaz z tym PCtem to nie jest zly pomysl. Przemyslowy, jednoplytkowy P200
daje duze mozliwosci eksperymentowania...
>> Nazwa T konw MIPS cykl/konw Vskan
>> PIC16C76 15.2 20 304 12.9
>> PIC17C752 16 33 528 12.2
JL> Hm - tych nowych picow nie sledze, ale jak na moj gust to to sa nie
JL> MIPS a MHz. Instrukcja zajmowala 4 cykle, lub wiecej.
Opss.. zmylilo mnie stwierdzenie o tym ze prawie wszystkie instrukcje wykonuja
sie w jednym cyklu. Rzczywiscie MIPS = MHz/4
JL> A mozesz sobie pozwolic na taki rezim pracy? Czy tez jest to moze
JL> kamera linijkowa, musisz skanowac linie ciagle, a czas masz miedzy
JL> liniami ? jedno generuje problem pamieci, drugie znalezienie czasu na
JL> przetwarzanie.
Przetwornik obrazu jest to "linear array 1x64" odczyt jest sekwencyjny calego
wiersza, taktowany przebiegim zegarowym. Na wyjsciu pojawia sie napiecie
proporcjonalne do natezenia swiatla, podaje to ma przetwornik A/D i dalej juz do
konprolera. Przebieg taktujacy przetwornik wezme z jakiegos timera, dostosuje
jego czestotliwosc do szybkosci przetwarzania przetwornika A/D i do predkosci
przemieszczania sie fasoli. Tak wiec czas moge miec zarowno pomiedzy odczytem
pojedynczych pixeli (kilka-kilkadziesiat cykli), czas pomiedzy wierszami bedzie
zalezal od predkosci ziarna, a czas pomiedzy kolejnymi ziarnami zalezy od tego
jak je bede podawal.
Mysle ze przy tak rozbitym czasie, w przypadku szybkiego kontrolera nie powinno
byc problemow ani z czasem, ani z pamiecia.
>> Jak myslicie, czy warto zajmowac sie wewnetrznymi przetwornikami, czy
>> zastosowac jakis szybki zewnetrzny?
JL> W architekturze '51 to radze uwazac na zewnetrzny. Zaraz sie okazuje
JL> ze dostep do niego jest okupiony sporym narzutem. Chyba ze przez DMA,
JL> ale dostep do pameici zewnetrznej jest jeszcze gorszy..
Dalczego dostep mialby byc z narzutem? Przetwornika ma czesto linie zgloszenia
konca konwersji (EOC), moge podac to na przerwanie, albo moge precyzyjnie
wyliczyc sobie ile cykli uplynie od startu konwersji do uzyskania wyniku i ten
czas zagospodarowac na obrobke obrazu. Sam odczyt to przeciez tylko MOV A,Px
Piotrek.
÷:)