XMega od Atmela: Wszystko, czego potrzebujesz w jednym chipie dla projektu RTC, DAC i LCD

Wed Feb 27, 2008 4:30 pm   

T.M.F. napisał(a):


A ja zaobserwowałem, że w jednych programach działa bez problemu latami
a w innych nie. Wnioski nasuwają się same
Natomiast zauważyłem, że gów..y programator potrafi uszkodzić wewnętrzny
eeprom, i wtedy są juz realne problemy nieusuwalne programowo.
Ale i tu wniosek jest dość prosty - nie uzywać jupiców i innego
badziewia. Po drugie unikac programowania płyt bez podłączonego
zasilania głównego.

--

Pozdrawiam,

A. Grodecki

"Wszystkie zwierzęta sa równe.
Ale te, które mają futerko w trzykolorowe pasy, są równiejsze."

Wed Feb 27, 2008 5:00 pm   

A. Grodecki wrote:

FLASH. Pare razy mi sie zdarzylo, ze po programowaniu przez ISP procek
nagle zdycha tak, ze nie daje sie odczytac, na nic nie reaguje. Nie
chodzi o przestawienie fusebitow, bo to zwykle robie tylko raz. Po
prostu po ktorymstam wgraniu Flasha proc zdycha. I bynajmniej nie jest
to 10000 raz po ktorym zgodnie z dokumentacja ma prawo sie dziac cos
zlego Moze to programator, moze kosmici, nie wiem.
Natomiast w projektach jak juz zadziala to dziala ok, poza problemem z
ta pierwsza komorka EEPROM nie spotkalem sie z przykrymi doswiadczeniami.

--
Inteligentny dom - http://idom.wizzard.one.pl
Teraz takze forum dyskusyjne
Zobacz, wyslij uwagi, dolacz sie do projektu.

Wed Feb 27, 2008 5:36 pm   

T.M.F. denied rebel lies:


AFAIR zdarzało się to przy niskich napięciach. Brown out detection masz
załączony?

--
<:> Roger, MoonWolf Out <:>|Just because you're a dragon
(: (:|doesn't mean you can push ME around
( JID:moonwolf@jabberpl.org(| http://karakkhaz.prv.pl

Wed Feb 27, 2008 5:55 pm   

T.M.F. napisał(a):


Takie efekty jak opisujesz zdarzają się w następujących przypadkach:
- niewłaściwe zasilanie procesora (niektóre procesory przy zasilaniu
niskonapięciowym programują się trudno albo wcale)
- zakłócenia na tasiemce programator - układ (przesłuchy, przepięcia)
- źle dobrany hardware po stronie procesora (oporniki do masy i vcc,
przydługie ścieżki obciążające linie ICSP)
- konflikt z programem procesora na pinach (zwykle załatwia to dodatkowy
poprzedzający impuls kasujący).

Niektóre procesory wymagają szczególnego traktowania przy programowaniu
icp, ale jest to opisane w helpie do ICD.
Generalnie trzymanie się zaleceń Microchipa pozwala na unikniecie
miażdżącej większości problemów zwykle przypisywanych krasnoludkom lub
UFO :)

Są tez pewne niuanse o których po prostu trzeba wiedzieć. Najbardziej
krytyczny jest moment "wstawania" struktury z uśpienia albo przy
pojawieniu się zasilania. Mogą się wtedy dziać pozornie dziwne rzeczy z
eepromem a nawet ze stanami rejestrów SFR. Jednak wszystko jest
fizycznie wytłumaczalne.

--

Pozdrawiam,

A. Grodecki

"Wszystkie zwierzęta sa równe.
Ale te, które mają futerko w trzykolorowe pasy, są równiejsze."

Wed Feb 27, 2008 6:14 pm   

MoonWolf wrote:

Mam, znacznie pomaga, ale ciagle przy zasilaniu 4.5-5V na kilkadziesiat
prockow czasami ktoremus sie zdarzy zmienic EEPROM. Ale poza pierwsza
komorka nie zaobserwowalem, zeby inne byly tym problemem dotkniete. Byc
moze rozwiazaniem jest ustawianie rejestroe EEADRH i L na adres inny niz 0.

--
Inteligentny dom - http://idom.wizzard.one.pl
Teraz takze forum dyskusyjne
Zobacz, wyslij uwagi, dolacz sie do projektu.

Wed Feb 27, 2008 6:18 pm   

Progrmauje przy 5V, zasilanie z ukladu.


To mozliwe, uzywam tasmy, dl. ok. 50cm.


Zwykle ISP nie wykorzystuje w projekcie do niczego innego, wiec
interferencji z reszty ukladu sie nie spodziewam.


Ustawiam piny jako wejscia.
Ale to rzeczywiscie moze byc problem z programatorem/tasma. Bo np.
ATMega8 na plytce konwertera usb-rs485 z mojego projektu, ktora
programowana jest poprzez chip ftdi pomimo kilkuset programowan nigdy
nie padla. Podobnie nigdy mi si enie zdarzylo, zeby padl procesor
podczas programowania za pomoca bootloadera.

--
Inteligentny dom - http://idom.wizzard.one.pl
Teraz takze forum dyskusyjne
Zobacz, wyslij uwagi, dolacz sie do projektu.

Wed Feb 27, 2008 6:28 pm   

T.M.F. napisał(a):


Ja nigdy dłuższej niż 30cm. Empiryczne próby z dłuższą taśmą (tego
samego rodzaju) powodowały problemy.


Ale i tak oporniki zdecydowanie powinny być, inaczej jest ruletka. A
jeśli piny deklarujesz jako wejścia, to być MUSZĄ bezwzględnie.

--

Pozdrawiam,

A. Grodecki

"Wszystkie zwierzęta sa równe.
Ale te, które mają futerko w trzykolorowe pasy, są równiejsze."

Wed Feb 27, 2008 7:14 pm   

Wed Feb 27, 2008 7:15 pm   

Hmm, ciekawe, nigdy sie z tmy nie spotkalem. Mozesz napisac cos wiecej?



--
Inteligentny dom - http://idom.wizzard.one.pl
Teraz takze forum dyskusyjne
Zobacz, wyslij uwagi, dolacz sie do projektu.

Wed Feb 27, 2008 7:24 pm   

T.M.F. napisał(a):


A co tu pisać? Wejść wysokiej impedancji wolnych zostawiac nie wolno -
oczywista oczywistość.
Linie icp pracują podobnie jak w i2c - muszą być podciągnięte do
właściwego poziomu, bo może być problem z detekcją poziomów.

Zostawienie linii wolnych jest "złą praktyką", za to zostawienie wejść
wolnych - poważnym błędem. Powinieneś deklarowac je wtedy jako WYJŚCIA.

--

Pozdrawiam,

A. Grodecki

"Wszystkie zwierzęta sa równe.
Ale te, które mają futerko w trzykolorowe pasy, są równiejsze."

Wed Feb 27, 2008 8:46 pm   

czasie programowania. Zbierałem przez całe 2 lata.
Co prawda przyczyną był g...niany programator - samodziejka STK200, ale w
końcu nie wytrzymałem i zmieniłem kontroler na inny tej samej firmy tyle że
z flashem. Na firmowym programatorze mam teraz uzysk rzędu 95% a pozostałe
5% można powtórnie przeprogramować.

--
Piotrek.
http://www.pitlab.pl

Wed Feb 27, 2008 9:25 pm   

Piotr "PitLab" Laskowski napisał(a):


Powinieneś mieć 99.7% conajmniej. Coś tam jest nie jak trzeba.


--

Pozdrawiam,

A. Grodecki

"Wszystkie zwierzęta sa równe.
Ale te, które mają futerko w trzykolorowe pasy, są równiejsze."

Wed Feb 27, 2008 10:17 pm   

niektóre egzemplarze mają zbyt duża odchyłkę częstotliwości pracy, tak że
zaczynają się pojawiac problemy z transmisją. Próbowałem z tym walczyć, ale
poległem na braku łopatologicznej informacji jak to zrobić w 10F200. Niby
pisze że trzeba odczytać kalibrację przed kasowaniem, ale za CHRL nie udało
mi się zaprogramować kalibracji ponownie. Odpuściłem i mam kilka wersji
programu z różnymi wartościami timera taktującego transmisję.

Dla porównania Atmeli przerobiłem trochę mniej, ale tylko raz udało mi się
zablokować układ, tak że trzeba było go popędzić zewnętrznym zegarem do
programowania. Ponad setka układów z megą8 i 16 pracuje z
kilkudziesięciometrowymi kablami w warunkach budki stojącej na praktycznie
otwartym powietrzu (burze i szeroki zakres temperatur) od 2-3 lat i jak
narazie nic nie wróciło do tatusia z powodu uszkodzenia elektroniki. :-)

--
Piotrek.
http://www.pitlab.pl

Wed Feb 27, 2008 11:42 pm   

No nie, to taki moj pomysl. Ale patrzac na datasheet do XMegi powinien
zadzialac. Puszczasz jeden kanal DMA w kolko w trybie czytania/zapisu do
pamieci ( chodzi o wykorzystanie strobu zapisu jako zegara do taktowania
zatrzaskow w LCD), tak, zeby po zakonczeniu transakcji (czyli przeslaniu
calej ramki) generowal przerwanie w ktorym robisz programowo sygnal FRM.
DMA odczytuje pamiec i wysyla gdzies pod adres XRAM, XMega ma 16MB
zewnetrznej pamieci, czyli najstarczy bit adresu (niesadze, zebym
potrzebowal wiecej niz 8MB do swoich celow) razem ze strobem zapisu WR
moga posluzyc do generowania strobu dla latcha w LCD. W ten sposob mam
juz zalatwiony automatyczny transfer linii. Teraz moge reszte robic na
przerwaniu, nie jest juz tak zle, bo procesor tylko raz na linie bedzie
zaangazowany w generowanie sygnalu przejscia do kolejnej linii. Ew.
dodac licznik popedzany zegarem dla latcha ktory mi ten sygnal
wygeneruje automatycznie. Nie mam rozpiski pinow do XMegi ale
niewykluczone, ze bedzie mozna w tym celu wykorzystac ktorys z timerow w
trybie pobierania zegara z pinu. Taki timer po zliczeniu zaprogramowanej
ilosci impulsow (czyli bajtow na linie) wygeneruje sam sygnal przejscia
do nowej linii. Problem sie pojawia w przypadku kolorowych LCD majacych
wejscia po 24 bity na raz. Wykorzystanie 3 DMA nie wchodzi w gre, bo nie
da sie ich zsynchronizowac w zaden sposob (chyba). Wiec pozostaje
rozwiazanie typu 3x8-bitowy latch wybierany z multipleksera podlaczonego
do bitow A0-A2 adresu pamieci. Ale to juz zakrawa na jakies male CPLD za
pare zlotych Co i tak w sumie moze byc korzystne, bo nie wiem jak w
tym procku bedzie wygladalo podlaczenie XRAM, ale jesli tak jak w
ATMega128 to i tak potrzebujesz 1 zatrzask. To w sumie mozna jakies male
CPLD wlozyc.
Co o tym myslisz?

--
Inteligentny dom - http://idom.wizzard.one.pl
Teraz takze forum dyskusyjne
Zobacz, wyslij uwagi, dolacz sie do projektu.

Thu Feb 28, 2008 1:26 am   

Piotr "PitLab" Laskowski napisał(a):


Akurat w tych procesorach nie wiem. PIC-e maja różne konstrukcje
oscylatorów. Niektóre sa całkowicie zadowalająco stabilne i dokładne (np
16f6xx) ale zazwyczaj nie sa ani stabilne ani dokładne.
W transmisja asynchronicznej trzeba robić króciutką pauzę między bajtami
i to załatwia sprawę - błąd 2-3% nie czyni różnicy.
Natomiast nie spotkałem się NIGDY z problemem programowania układów
10fxxx przez icsp.


To żadna mecyja.

--

Pozdrawiam,

A. Grodecki

"Wszystkie zwierzęta sa równe.
Ale te, które mają futerko w trzykolorowe pasy, są równiejsze."