И аз си вземам единични броики от там. и ATmega16 i ATmega64 за АТmega128 чаках 2 седмици но ми ги доставиха. Сериозни са.

Аз определено не съм меродавна личност, обаче преглеждам чат-пат avrfreaks и някои руски форуми, и никой никъде не се оплаква от бъгове по АВР-а.

...

Цецо
"Не съм врачка. Работя с Микрочип от много години"

Тези документи съм ги посочил за напреднали и за начинаещи.

Едва ли някой от напредналите не се е докосвал до 16F84 , 16C63/73/74 или тяхна модификация. И вероятно някой от тях не са обърнали внимание на написаните бележки към фунционалните блокове които са използвали. На мен ми се е случвало често.

За начинаещите да не разчитат само на написаното в един документ и ако все пак пропуснат нещо да не правят генерални изводи че друг им е виновен.

Абе не знам що ги браниш толкоз пламеннo. Както казах имам прилично голям опит с пиклювци, убил съм си месеци в търсене на проблеми от тоя тип дето сега го разискваме. И вече определно ми писва. Далеч съм от идеята че има безгрешни неща. Уважавам фирмите които си признават грешките, и го правят с големи букви, та да не те вкарат в беля. Микрочип правят точно обратното - до последно отричат и като видят че няма на къде - с две три думи се обяснява "някъде", че проблема всъщност е елементарен и не опасен. И като отшуми, се приключва по темата.
Тъй като темата е как да избягваме проблеми с Микрочип, мисля да прекратим по тоя и да наблегнем на други проблеми.

Всъщност мойте най-големите проблеми с Микрочип са:

1. Скапаната инструкция LFSR в 18C442. Уби ми седмица, заедно с първата и много бъгава версия на MPLAB - C18. Официалното обяснение от Микрочип, след много отричане беше - инструкцията не работи, води до непредсказуем резулатат. Заобиколка - да не се ползва!!!!. Отговора ми беше нецензурен.

2. 18F452 - След повече от година на пазара изведнъж се оказа че при преход от първата половина на паметта към втората и обратно (просто goto, call, tblrd, tblwr), процесора просто се побърква. Пак много отричаха. После казаха че това се получавало само на определни бройки при много специфични условия. След като ги заринаха колеги с писма с проблеми, всъщност се оказа че няма гаранция за никой процесор от тая серия. Може да се случи на всеки, при неустановени условия. Не се плашете, последните серии май нямат тоя проблем - така поне твърдят.

3. PIC18F6620 (6720, 8620, 8720) - след като беше вече 7,8 месеца на пазара изведнъж се оказа че горния бъг съществува и при него. Отначало пак ми отричаха. Пращах им код. Други колеги също пропищяха. Е оказа че проблема го има. После обаче един ден установих че имам проблем и само в първата половина на паметта. Пак се почна кореспонденцията - нямало такова нещо - да си проверя за мои грешки. Напсувах ги цветущо (тоя път съвсем без цензура). Три месеца по късно излезе официалната ерата според която тия ядра не работят стабилно на висока честота. Първо беше 40MHz, свалиха я на 20Mhz, а накрая се оказа че не могат да гарантират работоспособност на повече от 4Mhz ( а аз съм купил 40MHz procesor). Да се обърна към дистрибутора да ми смени бройките. В Комет казаха че няма такова нещо и си продаваха келявите бройки. Не ми се разправяше (нямах нерви) и си набавих отвън. После официално получих писмо с извинение и препоръка да ползвам 6621 или 8621, понеже проблема в старите бил твърде голям и било по добре да пуснат нов процесор.

Убий ме, но няма да пробвам DSPIC. Правят го 5 години, пуснаха първите бройки, ератите им са колкото datasheet-овте. Изглежда добре, ама "парен - каша духа". Бях си набавил семпъли имах идеи за него, но след тоя последния проблем, мисля да огранича използването на Microchip за нови проекти.

Апропо никога не съм пипал 16F84, да не говорим за 16C54. Почнал съм направо с 873. Но явно това ми е била грешката. За да съм в крак с технологиите им, трябва да проверя и старателно изуча продуктите им от преди войната (в залива).

...

Ами основно са 3 - IAR, CodeVision и gcc. Последното ми е любимо, освен всичко е free. Само дето няма free IDE за него, но аз ползвам кракнат Atman AVR и повече не ми трябва. За симулация/дебъг ползвам AVRStudio, който също е free.
Интерфейсите са 2 - SPI и JTAG, като програматора за първото е много елементарен, процесора е ISP. Паметта е софтуерно програмируема, така, че можеш да си направиш какъвто искаш програматор.
Цените ги има на сайта на футурел.
Това с тока не го разбрах.

Имах предвид, ако дадено краче го програмираш като изход, токът който можеш черпиш или вкарваш през този изход. Спомням си, че навремето можеше да влезне ток до 20mA, когото изхода е в 0V, но когато е в 5V, можеш да черпиш много по-малко.

Although each I/O port can sink more than the test conditions (20 mA at VCC = 5V, 10 mA at VCC = 3V) under steady state
conditions (non-transient), the following must be observed:
1] The sum of all IOL, for all ports, should not exceed 200 mA
2] The sum of all IIOL, for port D0 - D5 and XTAL2 should not exceed 100 mA.
3] The sum of all IOL, for ports B0 - B7 and D6 should not exceed 100 mA.
If IOL exceeds the test condition, VOL may exceed the related specification. Pins are not guaranteed to sink current greater
than the listed test condition.
4. Although each I/O port can source more than the test conditions (3 mA at VCC = 5V, 1.5 mA at VCC = 3V) under steady state
conditions (non-transient), the following must be observed:
1] The sum of all IOH, for all ports, should not exceed 200 mA
2] The sum of all IOH, for port D0 - D5 and XTAL2 should not exceed 100 mA.
3] The sum of all IOH, for ports B0 - B7 and D6 should not exceed 100 mA.
If IOH exceeds the test condition, VOH may exceed the related specification. Pins are not guaranteed to source current
greater than the listed test condition.


//едит
при по-големи количества цената спада доста като за AT90S2313 можеда стигне до 1.13-1.15 евро.
аз лично купувам AVR от Комет
за симулация и дебъг върши много добра работа и протеус
повечето контролери могат да се програмират и с bootloader

Относно проблема с F452 (F252) до колкото ми е известно съществуваше до B4 ревизия. От C0 нагоре май беше оправен. Проблема го няма при F442, F242, поне така е официалната версия.
Провери ератите, там е най сигурно. А като повдигнахме проблема с ревизиите. Още една отвратителна страна на Микрочип. Ревизията не е написана върху корпуса. Само няква дата. А в ератите не се говори за дати, а за ревизии. А за да провериш ревизията трябва да го закачиш на програматор, и то по висок клас (например ICD2). A как да го еба, да стане това в магазина като купувам паяк 80 крака ситен растер. Естествено жената зад щанда от ревизии нищо не отбира.

Цецо
"Абе не знам що ги браниш толкоз пламеннo.... инструкцията не работи, ...води до непредсказуем резулатат. Заобиколка - да не се ползва!!!!. "

В случая напълно те разбирам. Не защитавам MICROCHIP. Въпросът по скоро е принципен: кое да приемем за BUG, и кое не. Може да не се съгласите с мен но моето разбиране е следното: хардуера на процесора е работещ, когато всички реакции водещи евентуално до непредвидим резултат, могат да бъдат софтуерно овладяни.
Случая с GIE може да бъде софтурно овладян и аз не го квалифицирам като BUG.
Например когато изпълним:
BSF PORTB,0
BSF PORTB,1

и се окаже след това PORTB,0 =0, PORTB,1=1 не казваме, че имаме BUG в процесора.

...

Ами мойте наблюдения са че новото поколение контролери на Микрочип, са по сензитивни откъм ресета. Под нови разбирам PIC16F-A и PIC18F. Аз лично го забелязах когато устройство работещо с PIC18C442 се опитах да го подкарам с 18F442, че ми беше по лесно да бъзикам софта. При работа имах едни шамари по захранването които не правеха проблем на OTP версията. Флаш версията се рисетваше. Когато погледнах с скопа на пина за ресет видях че имам един неприлично голям пик, който явно се приемаше като ресет. Интересното е че пина се менажира от външен чип. Имах резистор 1к между него и входа на пика. Когато сложих пак OTP то пика беше там но беше много по малък. Което ме наведе на мисълта че MCLR -а не е просто обикновен високоомен вход.
После се сетих че на Flasha може би е бил активиран BOR. Което обаче не обяснява защо пина за ресет се държеше като изход - за да дърпа нивото надолу, при положение че от другата страна на резистора монитора на ресета го държи високо.
Както и да е оправих софта и пекнах го на ОТП и го върнах обратно.
Та може би и това е разликата между PIC16 и PIC16A - BOR схемата. Със сигурност обаче има разлика в ресета при чиповете пройзведени през последните 2 години. Естествено такива неща Микрочип не коментират.

Lino, аз не споря дали това е BUG или е "core specific effect". Не ми пука. Проблема е, че на такъв важен проблем не се набляга в документацията. Колко ли софтуер е на пазара без да взима мерки срещу това, понеже Микрочип са решили, че няма нужда да тръбят излишно за една подобна "особенност" на ядрото.

Но да не писваме на хората с тъпи спорове. Проблема (особенността) съществува - пазете се.

Тия PIC-ове наистина са от най големите мистерии
Преди време имах следния проблем с 16F876A - LCD свързано по 4 битова шина никак не искаше да зацепи. Убих се няколко дни да търся грешки в програмата или проблеми по платката. Като поставих на негово място 16F876 БЕЗ А, всичко тръгна както трябва. Накрая този PIC16F876А тръгна само като свързах един резистор 10к от 4-та шина към маса. И досега си работи така без грешка. Защо стана така - един бог знае (а може и той да не знае...). И в никой документ не съм срещнал описано нещо такова! С други 16-ки без А не е имало такъв проблем.
Друг проблем наскоро пак на 876А - както и да му казвам да установи някой пин на вход, той упорито си държи всичко на изход, независимо на кой порт. Става вход единствено ако му кажа да е Analog Input. А като Digital I/O не ще и не ще Грешки в програмата няма. Всичко е според примерите в документацията.........
Ползвал съм и AVR и не съм имал такива ядове с тях.