Met welke AVR's kan ik best beginnen?

atmega168? Lekker groot, veel geheugen, DIP, snel..

Ik ben zelf met een ATtiny2313 begonnen, simpel dingetje, kan wat jij opnoemt. Is niet groot, heeft niet veel geheugen, maar voldoet prima aan het begin.

Ik heb zo ooit eens wat atmega8's gekocht, maar zeker in het begin had voor de meeste dingen had ik al snel veel meer IO's nodig. Een 40-pins exemplaar met veel IO's en genoeg flash voor de wat grotere projectjes (atmega16 of 32) werkt prima. Voor de prijs hoef je 't niet te laten.

Met een ATtiny, ATtiny2313 (geen ADC) of een kleinere ATtiny13 / ATtiny45 (met ADC), na ervaring bijv. overgaan op de ATtiny861 (met ADC) en daarna op de ATmega's, bijv. de ATmega88 (nog altijd redelijk kleine behuizing in DIP)

Koop twee kleintjes, twee middelgrote, en twee grote. Dan zit je gebeiteld voor een maand of drie.

Bedankt voor de tips, ik zal eens kijken naar de verschillende mogelijkheden.

Nog even een aanvullend vraagje, als ik nu ineens een µC koop met meer mogelijkheden, is deze dan ook moeilijker om te programmeren, of maakt dat niet veel uit?

Dat is het leuke van Atmel. Als dezelfde peripherals aanwezig zijn, is het een kwestie van de code opnieuw compileren / assembleren. Er worden wel eens extensions in peripherals aangebracht, echter, als jij je netjes aan de datasheet gehouden hebt, is dat doorgaans compatible.

Het wil wel eens gebeuren dat een register een andere naam gekregen heeft. Als je bijvoorbeeld begint op een AVR met 1 uart en je volgende heeft er 2, dan wil er wel eens een volgnummertje bij komen.

Complexiteit: meer peripherals betekent meestal dat je meer I/O doet (en dus waarschijnlijk een wat complexer 'iets' probeert te doen). Daar ligt je toename in complexiteit.

Verder ga ik met kif mee. Ga er eerst eens mee spelen en als je 'echt' aan het werk gaat, koop dan de controller die je nodig hebt.

Overigens is het best handig om voor development een 'grote' te nemen (met meer RAM / flash dan je denkt nodig te hebben) en als je code eenmaal 'af' is te kijken wat de goedkoopste is waar het op draait. Het is best naar als je een inschattingsfoutje maakt en voor de laatste 10 bytes code moet gaan 'pielen' om het er in te krijgen.
_{*denkt nog wel eens aan een week rommelen om 261 bytes 6502 assembly 5 bytes kleiner te krijgen... Levert mooie write-only code op *}

Mijn policy is: Ik werk met de atmega168. Die is lekker groot, heeft voor mijn toepassingen vaak voldoende pins etc etc.

IK had ook meteen een paar "tiny" dingen gekocht. Uiteindelijk gebruik ik die weinig. Ik heb dan m'n eigen arduino achtig bordje gemaakt. En in de eerste instantie ook met een "tiny" controller. Maar blijkt dat je dan kwa kosten EUR 15 aan onderdelen voor het bordje uitgeeft, en dan EUR 1,- bespaart door er een 8x kleinere CPU op te zetten. Da's niet effectief.

Verder wil ik nog kwijt: Atmel heeft het heel goed voor mekaar. Dingen die je niet gebruikt hoef je niet te initializeren. Dus als je nog niks met de ADC wilt doen, dan laat je dat hoofdstuk van de datasheet gewoon links liggen, en doe je niks daarmee. Dan interfereert dat hele ding gewoon niet met wat je WEL wil doen, ook al zit ie op dezelfde pins.

Op 12 december 2010 03:11:05 schreef warddr:

Nog even een aanvullend vraagje, als ik nu ineens een µC koop met meer mogelijkheden, is deze dan ook moeilijker om te programmeren, of maakt dat niet veel uit?

Nee, maar sommige adressen zitten nog wel eens op een andere plek, en als je een uc gebruikt die drie timers heeft en je gebruikt net de derde omdat die pin zo handig zat in je schema*, en die op de kleine variant niet aanwezig is.

* tip: kies je pinnen zodanig dat ze handig te routen zijn en pas je software daarop aan.

Overigens, Ericp begint over 'ontwikkeling' en 'productie'; bij hobbyisten is dat gelijk. Maar zelfs als dat niet zo zou zijn zou ik ervoor kiezen om voor ontwikkeling en productie dezelfde uc te nemen (omdat je anders kans hebt op allerlei bugs die je nooit bent tegengekomen in je ontwikkelsysteem, en die je dan d'r uit moet testen in je productiesysteem.)

Waarom zou een andere controller opeens bugs (die blijkbaar toch al in je code zaten?!?) aan het licht brengen? Dat zou een reden te meer zijn om het spul op verschillende controllers te laten lopen! Maar goed, de praktijk is een stuk vriendelijker: Atmel heeft dat met die peripherals best goed voor elkaar. Enige wat ik me nog voor kan stellen is dat je met een timing gerelateerde counter ofzo de mist in gaat als je met de clock rommelt.

Overigens ben ik het niet met je eens dat je engineering model altijd hetzelfde is als 'productie' als je hobbyist bent. Heb jij nooit van een bepaald 'project' 20 exemplaren gemaakt? Noem dat geen productie, maar toch 'productie' genoeg om er even over na te denken - vooraf weet ik vaak niet hoe groot de code gaat worden, als het min of meer klaar is wel. Tevens is een prototype op broodplank nog wel eens de moeite waard, terwijl het ding als het 'af' is (en er een PCBtje gemaakt wordt) volledig SMD wordt.

Die tip is een goede. Let wel op dat dat soms side-effects kan hebben als je met libraries werkt die onderscheid maken tussen bits setten en een complete port setten. Meen dat oa. de LCD lib van Peter Fleury zoiets doet.

Op 12 december 2010 12:01:56 schreef EricP:
Waarom zou een andere controller opeens bugs (die blijkbaar toch al in je code zaten?!?) aan het licht brengen?

Je hebt in potentie twee verschillende codebases die je moet gaan onderhouden. Geheid dat dingen uitelkaar gaan lopen.

Da's dus het mooie van een AVR: controller type veranderen, compile, klaar. Niks aan code om te trekken... Het enige wat dat doet is de defines voor de adressen van de registers en evt. stacksize, memsize ed. veranderen. Argument van codebase gaat dus niet op.
Wellicht heb je in uitzonderlijke gevallen gelijk als je iets op een XMEGA schrijft en op een 8-poot tiny wilt gaan draaien. Maar ik neem aan dat wel allemaal begrijpen dat we het daar niet over hebben hier...

Mocht je dat gaan willen (bijvoorbeeld code voor een 8051 en een AVR op 1 stuk software baseren), dan heb je een fatsoenlijk SCM nodig. Dan is het wel te doen. Maar da's al snel geen hobby meer...

Op 12 december 2010 11:35:11 schreef rew:
Mijn policy is: Ik werk met de atmega168. Die is lekker groot, heeft voor mijn toepassingen vaak voldoende pins etc etc.

net wat atmega168 besteld. als ik dan kijk naar de attiny2313 (als die al leverbaar zou zijn) zijn die zelfs duurder (bij RS)

een 8 poter is leuk maar voor de hobby heb ik liever wat meer poten. dan is het bord maar wat groter

Op 12 december 2010 13:17:47 schreef EricP:
Da's dus het mooie van een AVR: controller type veranderen, compile, klaar. Niks aan code om te trekken... Het enige wat dat doet is de defines voor de adressen van de registers en evt. stacksize, memsize ed. veranderen. Argument van codebase gaat dus niet op.

Voor een andere (kleinere) pinout zit je al snel met 't feit dat je pinnen moet gaan verhuizen. Dat kun je natuurlijk allemaal wegwerken in defines, maar dat wordt al snel knap lelijk. Daarnaast meen ik me te herinneren dat de registers van verschillende avr's weliswaar een heel eind op elkaar leken, maar dat d'r hier en daar toch wat kleine verschillen waren (met name in de hoek van timers etc).

Maar dan nog: 20 tot 40 euro uitsparen omdat je naar een kleiner ic gaat lijkt 'fors', maar je moet daar wel een ander bordje voor ontwikkelen (andere pinout), je moet je software aanpassen (want andere pinout), en je moet zeker weten dat je niet alsnog een paar honderd euro aan printjes verkloot.

Tsja.

Bedankt voor de reacties.
Ik zal eens kijken dat ik met een aantal mensen samen wat AVR's kan inkopen, dat kan de prijs toch wat drukken.

Over code die het op de ene doet, en op de andere CPU niet, dat kan een bug in de code zijn die gemaskeerd werd door de ene CPU. Voor mijn part is het een default die in de ene CPU net anders is dan op de andere. De

De "code management" moet je m.i. goed doen. Dan hou je 1 codebase bij die met een define in de twee richtingen gestuurd wordt.

Zo is er "kapteinkuk" die een stuk software heeft gemaakt die een quadcopter kan besturen (een heli met 4 wentelwieken). Maar ook in "X" configuratie (in tegenstelling tot "+" configuratie. Bij plus-configuratie dus 1 motor voor, bij X 2 motoren voor: 45 graden gedraaid). Maar ook voor "tricopter" (drie wieken), en Hexcopter (6 wieken). Dus? Hij houdt nu diverse bestandjes bij waarin iedere variant van de code zit. Gevolg: Als er een update is, duurt het weken voordat de mensen met de minder populaire combinaties die update kunnen gebruiken: Hij moet met de hand de boel updaten.

Dat is dus slecht. Als je met defines werkt zou je 1 source hebben en a-la-minute dus een aangepaste versie kunnen maken. Kom je dan een keer een probleempje tegen, kan je dus een define maken om tussen de twee CPUs heen en weer te switchen.

Wat ik persoonlijk een voordeel van de tiny serie vindt is dat je de SMD versies is SOIC kan krijgen. Dat maakt het zelf etsen een stuk eenvoudiger. Ook als je echt weinig ruimte hebt kunnen de "tinies" van pas komen.

Op het gebied van prijs ontlopen ze elkaar weinig, een mega48 is vergelijkbaar in prijs met een tiny2313, maar die mega48 is wel iets uitgebreider.

Het grootste probleem met AVRs is tegenwoordig de leverbaardheid. Ik zou gewoon de AVR kopen die op dat moment op voorraad is.

[Bericht gewijzigd door Gyrbo op zondag 12 december 2010 22:33:21 (15%)]

Op 12 december 2010 22:32:23 schreef Gyrbo:
Het grootste probleem met AVRs is tegenwoordig de leverbaardheid. Ik zou gewoon de AVR kopen die op dat moment op voorraad is.

Precies. En later overstappen op waar het inpast.

@rew: ben jij die verschillende defaults bij een AVR wel eens tegen gekomen? Ben wel benieuwd... Week of 2 hadden we wel een kleine discrepantie in een topic hier tussen de datasheet en de hardware (waarbij de simulator de datasheet volgde ). Maar verder?

@alex: je lijkt weinig met ontwikkeling gedaan te hebben. Zoekt elke keer een ander argument... Eerst waren het vermeende bugs, toen waren het adressen die ander zitten, code die je separaat bij moest houden, nu pins die anders zitten... (nog nooit een stel datasheets naast elkaar gelegd??) Maar jij je zin hoor. Gaan wij ondertussen verder met zoals de rest van de wereld het doet...

@ts: beetje shoppen loont. Vooral in Duitsland (kijk eens bij Reichelt; wel op een Duits adres laten bezorgen!, maar er zijn er meer). Op samenkopen.net is weer een actie van Niels waarin je oa. AVRs kunt kopen. Neem aan dat dat geen klonen zijn, dus wellicht voor jou interessant. Aan de andere kant... als je net begint... maken die paar euro wellicht ook niet zoveel uit (je zult er niet gelijk 1000 kopen zeg maar).

Op 13 december 2010 07:48:33 schreef EricP:
@rew: ben jij die verschillende defaults bij een AVR wel eens tegen gekomen? Ben wel benieuwd... Week of 2 hadden we wel een kleine discrepantie in een topic hier tussen de datasheet en de hardware (waarbij de simulator de datasheet volgde ). Maar verder?

Ehh, nee, dat was een, ik zou me kunnen voorstellen dat... Zoals eerder in deze thread gezegd. Atmel heeft z'n zaakjes heel goed voor mekaar: De defaults zorgen er voor dat je direct met alle randapparatuur waar je in geinteresseerd bent kunt werken, zonder je over de rest zorgen te maken.

Op 13 december 2010 07:48:33 schreef EricP:
Op samenkopen.net is weer een actie van Niels waarin je oa. AVRs kunt kopen. Neem aan dat dat geen klonen zijn, dus wellicht voor jou interessant.

Door de slechte leverbaarheid heeft Niels nog maar 2 AVR's in z'n gamma zitten, die dan nog in SMD uitgevoerd zijn en waarvan ie slechts een kleine voorraad heeft...
Koester je collectie AVR's dus maar goed, ze zijn goud waard...

Ik ben wat aan het zoeken gegaan, en heb gevonden dat als je met een aantal mensen koopt dat je rond deze prijzen zit:

atmega88-20pu €2,20

ATtiny2313-20PU €1,40

ATTINY13A-PU €1

556-A89S51-24PU €1,2

(allemaal in stock)

Ik zal er eens een samenkopen actie van maken, dan heb ik ze ineens zelf ook een heel stuk goedkoper.

Op 13 december 2010 07:48:33 schreef EricP:

@alex: je lijkt weinig met ontwikkeling gedaan te hebben.

Als je perse gelijk *moet* hebben dan kun je het best krijgen hoor.

@TS: goedkoop duits shopje waar je ook zonder samenkoopacties terecht kunt is deze. Ooit eens gevonden via ebay.de, d'r zullen er vast nog wel meer zijn.

Op 13 december 2010 10:23:06 schreef alex278:
Als je perse gelijk *moet* hebben dan kun je het best krijgen hoor.

Het enige waar je mee komt zijn non-argumenten. Kom dan eens met iets substantieels... Maar joh, jij lekker prutsen, doen wij het zoals de rest van de wereld...

@ts: waar ga je die IA doen? Shopje van Alex is wellicht goedkoper (heb er ook wel eens besteld, duurde toen lang). Doe wellicht wel mee.

Futurlec heeft anders voldoende op voorraad :

http://www.futurlec.com/ICAtmel.shtml

Groeten, Bram