Atmel pokazal specyfikacje nowych chipow kompatybilnych z AVR - XMega. Warto przejrzec co maja na pokladzie, bo chyba maja wyszystko co mozna wymyslec. Robilem sobie projekt na ATMega zawierajacy RTC, DAC, ADC, do tego glowkowalem jak sterowac graficznym LCD i wychodzilo mi, ze potrzebny bedzie kontroler. A tu XMega ma wszystko w sobie. I skomplikowana plytka robi sie plytka z jednym scalakiem (dwoma, bo jeszcze external SRAM bedzie).
T.M.F. napisał(a):
Nawet gdyby do tego dodawali gratis cacko z dziurką i beret z antenką, to do ręki nie wezmę, jeśli ma "Atmel" nadrukowane :)
In the darkest hour on Wed, 27 Feb 2008 08:40:41 +0100, M M <no_spa snipped-for-privacy@interia.pl.uk> screamed:
Odp.: Bo zaburza naturalną kolejność czytania. Pyt.: Dlaczego? Odp.: Odpowiadanie na górze listu (top-postowanie). Pyt.: Co jest najbardziej irytujące w Usenecie?
gdzie ty wsrod nich widziales sterownik graficznego LCD?
Powitanko,
Chyba, zamiast wyrzucac, zaczne gromadzic Twoje ulubione procki z uwalonym EEPROMem. Uloze z nich wielki napis "Atmel rzadzi" i Ci dam;-)
Pozdroofka, Pawel Chorzempa
Pawel "O'Pajak" denied rebel lies:
Fabrycznie? Bo ja nie stwierdziłem problemów w mega16 czy 32. Co konkretnie siada, jakaś komórka czy całość?
Zrób makatkę (:)
Pawel "O'Pajak" napisał(a):
Pawełku. Te procki to wina:
Zaprogramowałem więcej tych układów N-razy więcej od Ciebie i MOŻE ze 3 razy mi się coś podobnego zdarzyło i to na trudniejszych do zaprogramowania płytach. Ty zaś masz na koncie całe laski uwalonych scalaków*). Przekonaj mnie, że to przypadek ;P
Myślę, że faktycznie Atmel za którego zapłaciłeś jest bardziej odporny od PIC-a, za którego zapłacił ktoś inny:)
*) Koszt znacznie wyższy niż nowy firmowy programator.Powitanko,
Pisalem o ulubionych prockach Andrzeja, nigdzie nie napisalem o Atmelach, do ktorych jestem bardzo przywiazany.
Pozdroofka, Pawel Chorzempa
Pawel "O'Pajak" denied rebel lies:
A, to w takim razie źle zinterpretowałem.
Dosyc dobrze potwierdzona jest informacja, ze pierwsza komorka EEPROM nie nadaje sie do uzytku, lubi sie kasowac. W swoich projektach tez to zaobserwowalem.
Bezposrednio nie ma, ale sa 4 kanaly DMA, ktore mozna ustawic tak, zeby wypluwaly dane na port do ktorego podlaczony jest LCD. Do tego potrzebny bedzie maly glue logic generujacy stroby dla latchy, to w sumie 2 bramki NAND mi wychodzi i maly programowy supporcik dla sygnalu FRM. Generalnie obsluga LCD nie powinna zajac wiecej niz kilkadziesiat bajtow kodu i ulamki % cza su procesora, w dodatku przezroczyscie bo na przerwaniu.
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.
Spotkalem sie z podobnym problemem tyle, ze dotyczacym programowania 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.
T.M.F. denied rebel lies:
AFAIR zdarzało się to przy niskich napięciach. Brown out detection masz załączony?
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.
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.
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.
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.
masz gdzies jakis Application Note do tego?
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.