ervaring mening in avr gezocht

Op 12 januari 2005 11:43:49 schreef stefan haesen:
Is dit volgens jullie ervaring mogelijk qua snelheid.

Ja hoor, makkelijk. Ik heb onlangs nog een topic op CO gehad over een 16 kanaals PWM looplicht. Alle kanalen kunnen dan onafhankelijk van elkaar aan/uit en je hebt ook nog genoeg tijd over voor effecten zoals random, looplicht, enz.

in welke taal?

Dat is een beetje afhankelijk van wat je bent gewend. C is een zeer goede taal voor iets dergelijks, maar als je alleen assembler aardig kan dan zal dat sneller gaan

Triacs aansturen is gelukkig niet zo moeilijk. ik denk dat het laten faden van 16 lampen zelfs met een AT90S1200 makkelijk kan (maar dan moet je wel pinnen multiplexen).

Ideaal voor deze klus is een ATMega8, die is snel, makkelijk te programmeren in C en heeft geen externe klok nodig.

Semi-random is trouwens makkelijker!

Stefan,

De AVR is een ontzettend geschikte controller voor nagenoeg alle vermogen en industriële elektronica toepassingen. Helaas is de AVR naast de Scenix SX van Ubicon ook één van de meest complexe 8 Bit controllers die je op de markt vindt.
Ondanks de vrij lage Xtal frequenties 8 a 16 MHz voor de Mega's is de AVR samen met alweer de Scenix SX de snelste op de markt. Een Mega geklokt op 8Mhz heeft een instructie cycle van 125 ns dat is bijna 4 keer sneller dan een PIC16F84 op 20Mhz, En ruim 8 keer sneller dan de laatste generatie MCS51 controllers op 12Mhz. Bovendien heeft de laatste vaak 2 of 3 cycli nodig om één enkele instructie af te werken.
Helaas heeft dit alles ook een prijs... een AVR is ontzettend gevoelig aan ruis, een degelijk ontkoppelde voeding is een absolute must! Ga gerust eens wat verder dan de klassieke 100nF... enkele spoeltjes zijn absoluut nodig als je naast de controller (ruisbron 1°klas) nog eens wat faseaansijding (ruisbron 1°klas) gaat gebruiken.
Wat de software betreft... Een AVR is ontwikkeld voor C, sterker nog de C compiler was klaar voor het eerste masker klaar was, maw. Atmel heeft bij de ontwikkeling van de AVR zeer nauw samengewerkt met een gekend software huis (de naam ontsnapt me).
Hierdoor is de instructielijst van de controller zo samengesteld dat "Jan en klein Pierke" een compiler voor een hogere programmeertaal kunnen maken voor de AVR, ik zal geen namen noemen maar je zal met google tal van exotische compilers vinden voor de AVR, voor de PIC of MCS51 controllers ligt dit heel anders.
Mijn persoonlijke bescheiden maar niettemin deskundige mening: de gratis AVR-GCC heeft de allerbeste prijs kwaliteitsverhouding maar als je kleine programmaatjes wil kan je best investeren in ImageCraft. GCC past de C standaard namelijk zeer strikt toe, daardoor wordt een programma al snel vrij groot als je sommige functies gebruikt. Pas op: groot NIET traag.

KK

GCC kun je ook laten optimaliseren op code size meen ik, dat kun je in de makefile aangeven (-Os optie).

Ik heb zelf al vaker fase aansnijding met een AVR gedaan. Zelf heel erg smerig, ik heb een paar 2A slak ventilatoren met fase aansnijding gedimd. Alles zonder stabiliteitsproblemen! Als je print goed ontworpen is en het IC is ontkoppeld met 100N verwacht ik geen problemen.

Zet wel een RC netwerkje (470 Ohm, 100N 630V) over elke inductieve belasting die je dimt. Voor gloeilampen hoeft dat niet eens tenzij je een ontstoorspoel in serie hebt. Zorg ook voor een degelijk filtertje voor je voedingstrafo!

Op 12 januari 2005 14:18:13 schreef Wiz:
Helaas is de AVR naast de Scenix SX van Ubicon ook één van de meest complexe 8 Bit controllers die je op de markt vindt.

Hoe kom je tot deze mening/uitspraak? En wat bedoel je met complex, qua leercurve, mogelijkheden of toepassing?

GCC past de C standaard namelijk zeer strikt toe, daardoor wordt een programma al snel vrij groot als je sommige functies gebruikt.

Dat vind ik persoonlijk juist fijn, zo'n standaard is er niet voor niks, laat hem het dan maar volgen ook

Hoe kom je tot deze mening/uitspraak? En wat bedoel je met complex, qua leercurve, mogelijkheden of toepassing?

• De assembler (instructies)
• Nagenoeg alle geïntegreerde periferie

Ook ik hou ervan dat de standaard strikt wordt toegepast één C handboek volstaat...

KK

Voor wat nie bascom.
Is ook gemakkelijk.

rt

Ik gebruik op dit moment ook een Atmega8 en loopt op 16 Mhz.
Zelf programmeer ik de AVR's in basic. (www.mcselec.com)
Ik programeer hem via de STK200 van ponyprog.(www.lancos.com)

Succes,

EDIT: Volgens mij gebruikt Robint91 dezelfde compiler als mij.

[Bericht gewijzigd door Sjaak Boomschaak op woensdag 12 januari 2005 15:47:23 ]

Zelf ben ik onder de indruk geraakt van ICC AVR al omgeving om in te code en ponyprog om te programmeren. Ik heb tot op heden alles kunnen wat ik heb willen doen, al dan niet met hulp van mensen hier op CO, maar dat is voorop op het gebied van elektro geweest.

Als gisteren je eerste led is gelukt, weet je dus hoe je poorten moet aansturen, verder is het in C niet zo spannend om de rest te maken. Gezien de goede community's van de AVR gebruikers en de nette datasheet zou je de basis altijd terug moeten kunnen lezen als je vast loopt.

@ Johan v. Althuis
ja, soms gebruik ik die http://www.fastavr.com ook.
ik heb thuis een stk500 handig om te testen

Op 12 januari 2005 14:18:13 schreef Wiz:
een AVR is ontzettend gevoelig aan ruis, een degelijk ontkoppelde voeding is een absolute must! Ga gerust eens wat verder dan de klassieke 100nF... enkele spoeltjes zijn absoluut nodig als je naast de controller (ruisbron 1°klas) nog eens wat faseaansijding (ruisbron 1°klas) gaat gebruiken.

een atmel storings gevoelig, mijn eravring is juist dat een PIC vaker gekke dingen doet dan een AVR. Geef wel toe komt meestal niet door ruis, maar door straling van buitenaf

Omtrent je C verhaal, je kan idd de source optimaliseren

Nou moet ik toegeven dat ik alleen bij de ADC de spanning ontkoppel.
Maar verder heb ik nergens last van
RS232 gaat ook perfect, en de interrupts doen ook wat ze moeten doen.

Op 12 januari 2005 17:16:58 schreef Johan v. Althuis:
Nou moet ik toegeven dat ik alleen bij de ADC de spanning ontkoppel.
Maar verder heb ik nergens last van
RS232 gaat ook perfect, en de interrupts doen ook wat ze moeten doen.

Same hier..

Ik programeer zelf in Bascom omdat ik niet thuis ben in de hogere talen..

BTW moet je niet ff met 0 doorgang detectie gaan werken om 'veel' storing af te nemen die anders ontstaat..

Op 12 januari 2005 17:16:58 schreef Johan v. Althuis:
Nou moet ik toegeven dat ik alleen bij de ADC de spanning ontkoppel.
Maar verder heb ik nergens last van
RS232 gaat ook perfect, en de interrupts doen ook wat ze moeten doen.

ik zeg RTFD; want daar staat ok in beschreven dat je dat moet doen voor iig de ADC

Voor de duidelijkheid; een eenvoudig programmaonderdeel in GCC zou kunnen zijn;

char i;

i <<=1;

Dat zou vertalen in één enkele assembler instructie, maar niets is minder waar in GCC, want de standaard schrijft voor dat alle bit bewerkingen worden gepromoveerd tot integer bewerkingen ongeacht het datatype van de bron en doel variabele...
BASCOM, ImageCraft, nemen het hiermee niet zo nauw en leveren dus kleinere code af dan GCC.

Wat de storingsgevoeligheid betreft, de AT90S**** reeks heeft er niet zoveel last van maar de Mega's en de Tiny's durven al eens gekke bokkesprongen maken als je de voeding niet goed ontkoppeld, vooral tijdens EEPROM schrijf en lees bewerkingen. Geloof me jongens, ik heb al een duizendtal AVR's verwerkt in diverse toepassingen, zorg dat geen enkele spanningspiek - dip aan het massavlak van de controller raakt!!! Een goed printontwerp is de basis, 100nF op elke voedingspin en een goed PI filter op de voeding.

KK

Op 12 januari 2005 18:58:18 schreef High met Henk:
[...]

Ik zeg RTFD; want daar staat ok in beschreven dat je dat moet doen voor iig de ADC

Ik heb het uit de datasheet en dat is dus het enige wat ontkoppelt moet worden.
vandaar dat ik het nog even meldde.

Op 12 januari 2005 19:13:21 schreef Wiz:
Wat de storingsgevoeligheid betreft, de AT90S**** reeks heeft er niet zoveel last van maar de Mega's en de Tiny's durven al eens gekke bokkesprongen maken als je de voeding niet goed ontkoppeld, vooral tijdens EEPROM schrijf en lees bewerkingen. Geloof me jongens, ik heb al een duizendtal AVR's verwerkt in diverse toepassingen, zorg dat geen enkele spanningspiek - dip aan het massavlak van de controller raakt!!! Een goed printontwerp is de basis, 100nF op elke voedingspin en een goed PI filter op de voeding.

KK

wij zijn juist overgestapt van de 90S naar de mega omdat ze dus minder last hebben van storingen, wij gebruiken de PWM in een automotive omgeving met een verwarmingselement en levert nooit fouten op.

Op 12 januari 2005 14:18:13 schreef Wiz:
En ruim 8 keer sneller dan de laatste generatie MCS51 controllers op 12Mhz. Bovendien heeft de laatste vaak 2 of 3 cycli nodig om één enkele instructie af te werken.

effe een update op 8051 vlak : de laatste generatie 8051 zij scheurijzers die 100 mips lopen op hun sokken en 1 of max 2 cycles nodig per instruktie. Daarboven werken ze ook nog eens pipelined en kunnen ze in hardware vermenigvuuldigen en delen. Sommigen hebben zelfs DSP instrukties (multiply-accumulate) waarmee fft kinderspel worden.

niet dat ik de AVR wil afbreken hoor. is een prima processor. Ben hem ondertussen ook aan't bestuderen omdat ie hier regelmatig opduikt.

Maar k'heb de indruk dat de meesten alleen de 8051 van atmel en philips kennen en dat zijn van de traagsten uit !

www.cygnal.com . allen daarheen.

Op 12 januari 2005 15:11:25 schreef Wiz:

• De assembler (instructies)
• Nagenoeg alle geïntegreerde periferie

Meer instructies betekend flexibeler. Kortere programma's Meer periferie betekend flexibeler. Meer mogelijkheden.
Begin niet meteen met een ATmega128-16MI, dan is het pittig en lastig. Ondanks dat kan je toch een LED laten knipperen.

Bedankt voor de vele reacties.
ontstoren is dus een belangrijk punt.
Wat compilers betreft? blijkbaar zijn ze aan mekaar gewaagd en heeft iedereen zo zijn eigen voorkeur.
Of is er iemand die ervaring heeft met die verschillende basic en c compilers? prijzen? Ik ken C niet. Wordt er bij deze compilers zuiver met C of met C++ gewerkt?

Kan je met een compiler de tijdskritische faseaansnijding wel nauwkeurig proggen of moet hiervoor een stukje assembler voor worden gebruikt(want ik meende gelezen te hebben dat je deze 2 ook kunt combineren?)

O ja DJD xtreem: wat bedoel je met: BTW moet je niet ff met 0 doorgang detectie gaan werken om 'veel' storing af te nemen die anders ontstaat..
Voor faseaansnijding heb je toch een nuldoorgangsdetectie nodig, or is me stupid?

Je hebt inderdaad een nuldoorgangsdetectie nodig om te bepalen wanneer je de triacs schakelt. Bij dimmen krijg je echter altijd storing, dus moet je filteren.

Ik denk dat DJD EXTREEM met schakelende triac toepassingen in de war is. Als je gaat schakelen op de nuldoorgang is de storing altijd minimaal. Maar dan dim je dus niet meer!

Atmel AVR storingsgevoelig???

Tja, euh... heb ik nog nooit last van gehad (en ik werk met zeer hoge di/dt's en du/dt's).
Maar dat komt dan vast omdat ik altijd zeer veel aandacht besteedt aan de routing van mijn board en een goede ontkoppeling (de woorden: "experimenteerprint" en "breadboard" komen niet in mijn woordenboek voor).
Misschien dat die C en ASM goeroes hun layout maar moeten uitbesteden aan een hardware goeroe

Op 12 januari 2005 15:11:25 schreef Wiz:
[...]

• De assembler (instructies)
• Nagenoeg alle geïntegreerde periferie

Ook ik hou ervan dat de standaard strikt wordt toegepast één C handboek volstaat...

KK

Wat betreft de assembler, ik heb hier stagieres die net zo snel een proggie maken op de AVR als op de PIC.
Het is gewoon ff anders, maar om nou te zeggen moeilijker...
Ik vindt wel dat de datasheet van microchip completer en duidelijker is dan die van atmel.
De perriferie is niet complexer dan die van microchip.