AVR'y to badziewie ?

U¿ytkownik "Tomaszek" snipped-for-privacy@opus.chelm.pl> napisa³ w wiadomo¶ci news:cm81l8$cej$ snipped-for-privacy@nemesis.news.tpi.pl...

Do czasu wprowadzenia broun-outu stosowali¶my zewnêtrzny reset (scalak), teraz ju¿ nie stosujemy. Ale eksperymentów tego typu nie robili¶my. P.G.

jak zwał tak zwał, ale Atmel uczciwie o tym ostrzega i pisze co zrobić, żeby do tego nie dopuścić. włącz BOD, powinieneś mieć problem z głowy.

w.

kiedy wewnetrzny reset jest wylaczony zabawa zasilaniem (wlacz-wylacz) natychmiastowo powoduje zamazanie eeprom w roznych miejscach przypadkowymi wartosciami kiedy wewnetrzny reset jest wlaczony sprawa wyglada duzo lepiej bo zeby zamazac eeprom trzeba sie troche napracowac :)

fakt moze zle napisalem zamiast reset powinno byc wewnetrzny uklad kontroli nap

Użytkownik Tomaszek napisał:

No pięknie! Konstruktor używający Atmeli ma się skupiać na maskowaniu błędów producenta procesora?! I Wy uważacie, że samo ostrzeżenie o tym, że E2ROM mnoże byc zamazany jest OK? TOŻ TO ZWYKŁY BUBEL, NADAJĄCY SIĘ NA SKŁADNIK NAWIERZCHNI ASFALTOWEJ, A NIE PROCESOR.

U¿ytkownik "A.Grodecki" <ag.usun snipped-for-privacy@modeltronik.com napisa³:

Nie krzycz, nie krzycz. Na niczym siê nie trzeba skupiaæ, wystarczy ustawiæ odpowiednie fuse-bity. Nie wszystkie zastosowania potrzebuj± BOD, niektóre potrzebuj± natychmiastowego startu, dlatego jest wybór.

Darek ¯o³na

Użytkownik Dariusz Zolna napisał:

Ja Ciebie rozumiem, ale nie rozumiem dlaczego przy niektórych aplikacjach część peryferiów układu jest nie do użycia, bo nie działa poprawnie. Jakiś czas temu Atmel wynienił poczciwy 89C51 (rżnięty z 87C51) na autorski 89S51. W wyniku tego musieliśmy zrobić projekt na nowym (zupełnie innym) procesorze, bo 89S51 w naszym układzeie startował, tyle że nie zawsze... A ponieważ trudno jest klientowi (tak jak Ty mi próbujesz) wytłumaczyć, że tak jest dobrze i w razie czego musi na chwilę wyciągnąć kabel zasilania & try again, więc nastąpiło "pożegnanie z Atmelem". Widzę, ze problem jest bardziej złożony - nie jeden procesor jest do bani a jego producent.

Użytkownik entroper napisał:

Tak czytam, sam mialem problemy z AVRami, i narzuca sie pytane wiec czym sie bawic w zamian PIC od Microchipa a moze MSP430 Texasa.

ASFALTOWEJ, A

potwierdzam. Sprawdzone na kilku przykladach.

pozdrawiam entrop3r

Eee - wystarczy ze nie potrzebujesz eepromu i juz ci zostaje dobry procesor.

A jak innemu prockowi zaczniesz mieszac zasilaniem to tez wszelkie rzeczy moga sie zdarzyc :-)

J.

NIBY tak. Tyle, ze taki np. 2051 kasuje sie (nie eeprom, pamiec programu) po "zamieszaniu" zasilaniem (klapnieciu przekaznika itp.), a taki np. PIC16F73 mozna wkladac/wyjmowac z/do podstawki pod zasilaniem (nie mowie, ze polecam :D), a jeden egzemplarz (przyznaje, 16C73, a wiec epromowy) przezyl nawet zweglenie najblizszych okolic plytki przez prad piorunowy (zostawilem sobie na pamiatke - caly okopcony).

pozdrawiam entrop3r

To jeszcze się oburz, że jak wykorzystasz wszystkie wbudowane w PICa peryferia, to Ci GPIO prawie nie zostanie... Zazwyczaj coś jest kosztem czegoś...

AVR to nie ideał, ale miesznie z błotem wygląda mi na Twoje hobby...

Mi zdazylo sie kilka razy 2051 po zaporgramowniu odwrotnie wsadzic, przezyl kazdy moj blad. Teraz walcze z AVR, eeprom nie wykasowal mi sie ani razu a mam czesto spadki zasilania. Jedyne problemy jakie spotykam wynikaja z uzycia bascoma i jego maskowania procesow, zeby nie straszyc uzytkownika. Ale co tam, kilka ladnych aplikacji powstalo przy uzyciu bascoma. Dal mi podstawy aby zrozumiec jaki kolwiek jezyk programowania. Treaz mam zamiar zaczac z C/C++. A wracajac do Atmela, ciezko znalesc produkt pozbawiony jakis wad. Co powiecie jak Mercedes zrobil tego pyrtka co sie wywracal przy delikatnych przechylach. Dlaczego uzywac windowsa jak posiada miliony wad.(MS o nich informuje dopiero jak wszyscy im to udowodnia) Przyklady mozna mnozyc. Ale po co, szkoda czasu na to, trzeba kolekcjonowac mocne wraznia. (pozatym to co zauwazasz jak reaguja niektore uklady na okreslone sytuacje, nazywa sie doswiadczeniem, czyms bardzo cennym, a nó¿ kiedys bedziesz projektowal w wielkiej firmie procesor i zrobisz taki bez wad, z blokada odczytu nie do ominiecia, a wszytko to przy cenie 0,5E przy jednej sztuce. Ide juz cos robic bo filozuje:-) Pozdrawiam slychaczy, Micha³

Użytkownik Marek Lewandowski napisał:

Eeeee..

Użytkownik Michał napisał:

Czyli ma walory... edukacyjne. Dobre i to.

Dałeś same przykłady firm znanych z bubli i ich produktów. Są też firmy znane z solidnośći i ich produkty też: i procesory, i samochody i soft.

Praca konstruktora czy programisty nie polega na lawirowaniu między wadami komponentów których używa. To dopiero byłaby prawdziwa strata czasu! Po wykryciu elementu nieprzewidywalnego, eliminuje się go z projektu a nie pisze książkę o jego błedach i sposobach ich ominięcia.

U¿ytkownik "A.Grodecki" <ag.usun snipped-for-privacy@modeltronik.com napisa³ w wiadomo¶ci news:cm8nmp$s7o$ snipped-for-privacy@nemesis.news.tpi.pl...

"po¿egnanie

My po¿egnali¶my siê na amen z PICami. Stracili¶my 3 miesi±ce nie mog±c uruchomiæ naszego programu (przerwanie ginê³o raz na kilka tysiêcy razy). Znale¼li¶my 3 b³êdy w procesorze (nawet narysowali¶my sobie nasz± wersjê portu - jak to jest faktycznie w ¶rodku). Wys³ali¶my do Microchipa FAXa - internetu wtedy jeszcze nie by³o (u nas) - zero odpowiedzi. Jaki¶ rok pó¼niej by³a jaka¶ prezentacja Microchipa w W-wie. Tam siê okaza³o ¿e jest jaka¶ errata, ale jej nie ma w ¿adnych materia³ach. Obiecali przys³aæ - po kilku tygodniach przys³ali - 6 b³êdów, w tym 3 rozpracowane przez nas. Jeden z pozosta³ych wyja¶nia³ jaki uk³adzik trzeba dorobiæ na zewn±trz, aby przerwanie nie ginê³o. To jest dopiero przyk³ad paranoi. Ju¿ nie wspomnê ¿e ich w³asny programator (mamy go do tej pory) pali³ ka¿dy w³o¿ony do niego procesor (samo Blank-check ju¿ go za³atwia³o). Kapnêli¶my siê po 5 sztukach. Przerobili¶my programator i na pozosta³ych 5 sztukach wojowali¶my jeszcze 3 miesi±ce - ale to przerwanie uda³o nam siê tylko obej¶æ przez zaniechanie (czyli programow± kontrolê pinu).

A na atmele przerzucili¶my siê gdzie¶ tak w 1996 i nie mamy ¿adnych zastrze¿eñ. No mo¿e jedno - tak siê ludzi na nie rzucili, ¿e zniknê³y z rynku - terminy dostaw rzêdu 42 tygodni. Ale to by³o kilka lat temu.

P.G.

A je¿eli nie Atmel to co Waszym zdaniem ? ( 8-bit / 16-bit / 32-bit ) :) ?

Pozdrawiam, Grzegorz Kêpiñski

Użytkownik Piotr Gałka napisał:

jak widać każdy ma inne doświadczenia...

Z tego co słyszałem, to nie był problem popytu na AVR-y, bo i innych scalaków Atmela tez zaczęło brakować. Po prostu Atmel dorwał jakiś kontrakt na układy do komórek i OLAŁ "drobnych" klientów przestawiając linie produkcyjne tamte układy.

Na pewno to byl PIC a nie czolg T34 tylko z nozkami zamiast gasienic?? ;-) Ludziska psiacza na atmela, ale niech ktos pokaze alternatywny procek w wersji przemyslowej za 5,5PLN (odpowiednik AT89C52). Chetnie sie przerzuce.

Pozdrawiam Tomek

Dnia 2004-11-02 14:18, Użytkownik Tomaszek napisał:

Co do resetu to moj reset w atmega32 tak wlasnie wygladal :) Procek nigdy nie stracil danych z EEPROM... nawet mimo tego ze byl do niego przypiety przez bufor silnik ze zle odfiltrowanym zasilaniem wiec sialo po procku az milo. Jedyne co procek robil to czasowe resety... ale to byla ewidentnie moja wina. Dalem kondensatory odsprzegajace tam gdzie sie dalo i nagle chodzil idealnie. A w instrukcji do AVR-ow pisze ze przed osiagnieciem odpowiedniego napiecia zasilania nie wolno ruszac EEPROM. W praktyce w zaleznosci od wydajnosci Twojego zasilania ukladu i pojemnosci kondensatora na wejsciu 7805 ten czas moze sie wydluzyc albo skrocic. Ja nie potrzebowalem dobierac sie do EEPROM wczesniej niz 2..3 sekundy po uruchomieniu ukladu i nie mialem zadnego problemu. Dobre odsprzeganie napiecia zasilania tez jest wazne jak diabli w AVR. Mialem takie sytuacje ze procek nagle dostawal przerwanie ktorego tak naprawde nie bylo, resetowal sie, zmienial wypelnienie w generatorze PWM (sam z siebie !!!) a to wszystko bylo wina braku kondensatorka 10n na nogach zasilania procka no i oczywiscie tego ze zasilanie bylo zasmiecone.

pozdr, mavs