On 2013-09-26 08:17, Zbych wrote:
>> Rozwiązania oparte o AVR bedą miały taką wadę, że będą "pływać" na
>> ekranie w zakresie jednego cyklu zegarowego. Kiedyś robiłem z tym
>> eksperymenty i to jest upierdliwe zjawisko.
> Sam nie robiłem, ale widziałem gotowca i nic nie pływało.
> Podejrzewam, że program był tak napisany, żeby usypiał się tuż przed
> spodziewanym wywołaniem przerwania.

Też usypiałem żeby ilośc cykli przy odbieraniu przerwania była stała.
Tylko że dalej problem jest taki, że impuls synchronizacji poziomej
przychodzi niekoniecznie synchronicznie z zegarem taktujacym (który u
mnie podawany był z generatora z innych przyczyn). To drganie powodowało
ciekawe efekty na LCD bo logika w TV myślała że to interlace i próbowała
ten ruch przewidywać generując ciekawe efekty graficzne.

Wróce do tematu bo link z youtuba nie wygląda źle i może wystarczy
jednak taka jakość.

do góry

W dniu 26.09.2013 17:20, Sebastian Biały pisze:
> On 2013-09-26 08:17, Zbych wrote:
>>> Rozwiązania oparte o AVR bedą miały taką wadę, że będą "pływać" na
>>> ekranie w zakresie jednego cyklu zegarowego. Kiedyś robiłem z tym
>>> eksperymenty i to jest upierdliwe zjawisko.
>> Sam nie robiłem, ale widziałem gotowca i nic nie pływało.
>> Podejrzewam, że program był tak napisany, żeby usypiał się tuż przed
>> spodziewanym wywołaniem przerwania.
>
> Też usypiałem żeby ilośc cykli przy odbieraniu przerwania była stała.
> Tylko że dalej problem jest taki, że impuls synchronizacji poziomej
> przychodzi niekoniecznie synchronicznie z zegarem taktujacym (który u
> mnie podawany był z generatora z innych przyczyn). To drganie powodowało
> ciekawe efekty na LCD bo logika w TV myślała że to interlace i próbowała
> ten ruch przewidywać generując ciekawe efekty graficzne.

Tak licząc na szybko, to przy czasie wyświetlania linii 52us (+12us na
powrót plamki) i max. 720 pikselach w poziomie wychodzi zegar dla
pikseli ~14MHz. Przy takiej częstotliwości taktowania uC będziesz miał
jitter porównywalny z czasem rysowania 1 piksela. Jestem ciekawy czy
faktycznie będzie to tak bardzo widoczne.

do góry

użytkownik Sebastian Biały napisał:

> Wróce do tematu bo link z youtuba nie wygląda źle i może wystarczy
>
> jednak taka jakość.

Na pierwszym miejscu radze zapoznac sie z czestotliwoscia taktowania atmegi, ludziska
podkrecali zegar do ponad 28MHz.

do góry

On Thu, 26 Sep 2013, l...@g...com wrote:

> użytkownik Sebastian Biały napisał:
>
>> Wróce do tematu bo link z youtuba nie wygląda źle i może wystarczy
>>
>> jednak taka jakość.
>
> Na pierwszym miejscu radze zapoznac sie z czestotliwoscia taktowania atmegi,
ludziska podkrecali zegar do ponad 28MHz.

A później im działa, albo i nie.
Widziałem stabilne osd taktowane z 24MHz (e-osd, g-osd).
Natomiast w innym projekcie (eleres) układ ma czasami problem ze startem
przy 16MHz i zasilaniu 3.3V.

Generalnie nie ma większych problemów z generowaniem obrazu. Schody się
zaczynają dopiero jak w międzyczasie trzeba jeszcze coś bardziej
skomplikowanego policzyć (np. azymut/odłegłość między obecną pozycją, a
punktem docelowym) albo generować grafikę na którą brakuje pamięci w AVR.
Ale tu niewiele daje przetaktowanie procka - bardzie trzeba się skupić na
dobrym przemyśleniu jak to zrobić niż liczyć na MHz.


Pozdrawiam

Marek
--
"If you want something done...do yourself!"
Jean-Baptiste Emmanuel Zorg

do góry

On 2013-09-27 12:37, Marek Wodzinski wrote:
> Generalnie nie ma większych problemów z generowaniem obrazu. Schody się
> zaczynają dopiero jak w międzyczasie trzeba jeszcze coś bardziej
> skomplikowanego policzyć

Mogę wziąść np. małego SAM7S, nie ma problemu, tam jest dma i port
wypluwający bajty szeregowo. Gdyby nie absurdalne ceny tych procesorów.
To może inaczej: jaki mały arm7 będzie miał DMA które wyrzuci mi
szeregowo bajty na jakąś nogę? A może XMEGA? Tam też jest DMA i cena
poniżej 10zł.

do góry

W dniu 2013-09-27 19:56, Sebastian Biały pisze:

> Mogę wziąść np. małego SAM7S, nie ma problemu, tam jest dma i port
> wypluwający bajty szeregowo. Gdyby nie absurdalne ceny tych procesorów.
> To może inaczej: jaki mały arm7 będzie miał DMA które wyrzuci mi
> szeregowo bajty na jakąś nogę? A może XMEGA? Tam też jest DMA i cena
> poniżej 10zł.

popatrz raczej na coś z rodziny STM32 lub LPC - Cortexy (M0) kupisz już
od 3zł..

--
Pozdr.
Michał

do góry

On 2013-09-27 23:05, Michał Baszyński wrote:
> popatrz raczej na coś z rodziny STM32 lub LPC - Cortexy (M0) kupisz już
> od 3zł..

Małe LPC chyba nie mają DMA. Musiałbym więc machać ręcznie. Jesli już
wziąść coś większego to z dma.

do góry

W dniu 27.09.2013 19:56, Sebastian Biały pisze:
> On 2013-09-27 12:37, Marek Wodzinski wrote:
> > Generalnie nie ma większych problemów z generowaniem obrazu. Schody się
> > zaczynają dopiero jak w międzyczasie trzeba jeszcze coś bardziej
> > skomplikowanego policzyć
>
> Mogę wziąść np. małego SAM7S, nie ma problemu, tam jest dma i port
> wypluwający bajty szeregowo. Gdyby nie absurdalne ceny tych procesorów.
> To może inaczej: jaki mały arm7 będzie miał DMA które wyrzuci mi
> szeregowo bajty na jakąś nogę? A może XMEGA? Tam też jest DMA i cena
> poniżej 10zł.

https://www.seguro.pl/sklep/?zobacz=5569
http://kamami.pl/index.php?ukey=product&productID=20
4621

do góry

W dniu 28.09.2013 09:46, Zbych pisze:
> W dniu 27.09.2013 19:56, Sebastian Biały pisze:
>> On 2013-09-27 12:37, Marek Wodzinski wrote:
>> > Generalnie nie ma większych problemów z generowaniem obrazu. Schody
>> się
>> > zaczynają dopiero jak w międzyczasie trzeba jeszcze coś bardziej
>> > skomplikowanego policzyć
>>
>> Mogę wziąść np. małego SAM7S, nie ma problemu, tam jest dma i port
>> wypluwający bajty szeregowo. Gdyby nie absurdalne ceny tych procesorów.
>> To może inaczej: jaki mały arm7 będzie miał DMA które wyrzuci mi
>> szeregowo bajty na jakąś nogę? A może XMEGA? Tam też jest DMA i cena
>> poniżej 10zł.
>
> https://www.seguro.pl/sklep/?zobacz=5569
> http://kamami.pl/index.php?ukey=product&productID=20
4621

Nawet Cortex-M0 od ST ma DMA:
http://kamami.pl/index.php?ukey=product&productID=20
7211

do góry