AVR 500, ATmega8515L tips för nybörjare

PIC, AVR, Arduino, Raspberry Pi, Basic Stamp, PLC mm.
payam
Inlägg: 9
Blev medlem: 15 oktober 2006, 17:25:17

AVR 500, ATmega8515L tips för nybörjare

Inlägg av payam »

Hej, jag är helt ny på mikroprocessorprogrammering. Jag har köpt en AVR 500 med ATmega7515L från skolan, och tänkte börjar lite lätt inför fördjupningsarbetet i mekatronik nästa år, då vi ska lära oss de vi behöver om mikroprocessorer mm.

Jag har lyckats skriva en kod som tänder och släcker dioder och hämta in input från knapparna i C, och så har jag bara testat ett assembler program som följde med handboken.

Så nu undrar jag om ni har några bra tips på C eller assembler guider där de går igenom mikroprocessorprogrammering, samt om ni har tips på program som jag ska göra för att lära mig mer.

Jag har tittat runt lite i forumet och sätt att många skriver att mycket av mikroprocessorprogrammering är att hitta i datablad, vilka av pdf filerna på denna sida bör man börja med att kolla i http://www.atmel.com/dyn/products/produ ... rt_id=2006 ?
jensa
Inlägg: 149
Blev medlem: 28 oktober 2003, 18:16:49
Ort: Umeå

Inlägg av jensa »

http://www.avrfreaks.net/ är mångas första steg in i AVRs magiska värld :)
Användarvisningsbild
Zyxel615
EF Sponsor
Inlägg: 1839
Blev medlem: 9 november 2005, 21:20:43
Ort: Kiruna

Inlägg av Zyxel615 »

Användarvisningsbild
Stinrew
Inlägg: 954
Blev medlem: 20 augusti 2006, 03:14:41
Ort: Motala
Kontakt:

Inlägg av Stinrew »

AVR 500, betyder det STK500???
payam
Inlägg: 9
Blev medlem: 15 oktober 2006, 17:25:17

Inlägg av payam »

tack för alla svar, ska ta och gå igenom Umeås filmer först, verkar vara en ganska bra nivå på dem för en nybörjare.
Användarvisningsbild
DeVille
Inlägg: 2359
Blev medlem: 29 mars 2004, 15:04:22
Ort: Dalsländska skogen.
Kontakt:

Inlägg av DeVille »

Längst ner på denna sidan finns material som är väldigt bra också.

Länk till en Wiki-sida


Även här finns tonvis av information när du kommit in litegrann i AVR´s
AVR Freaks


Lycka till
Användarvisningsbild
bengt-re
EF Sponsor
Inlägg: 4829
Blev medlem: 4 april 2005, 16:18:59
Skype: bengt-re
Ort: Söder om söder
Kontakt:

Inlägg av bengt-re »

AVR ?
Användarvisningsbild
Icecap
Inlägg: 26219
Blev medlem: 10 januari 2005, 14:52:15
Ort: Aabenraa, Danmark

Inlägg av Icecap »

bengt-re: äsch... i brist på bättre vettu! ;-)
Användarvisningsbild
bengt-re
EF Sponsor
Inlägg: 4829
Blev medlem: 4 april 2005, 16:18:59
Skype: bengt-re
Ort: Söder om söder
Kontakt:

Inlägg av bengt-re »

Jo... Jag vet inte bara - gick på från en bekant en gång att det skulle vara bra, men jag reagerade på deras datablad vilka jag uppfattade som oseriösa och har sedan dess tittat snett på allt som heter AVR...

Verkar också vara lite märklig assambler, men tja - ääähh... SAAB finns ju kvar som biltillverkare trots att de gör gammalmodiga dyra bilar av dålig kvallité... Antar att smaken är lite olika...

En intressant sak är att så vitt jag vet har inte atmel någon procesor som har DNV-ceritifikat... Behöver inte betyda något, men betyder i min värld att man inte litar på sin produkt.... Iaf inte till system där fel kan leda till ond bråd död för dyr maskin eller än dyrbarare människa...
Användarvisningsbild
Swech
EF Sponsor
Inlägg: 4700
Blev medlem: 6 november 2006, 21:43:35
Ort: Munkedal, Sverige (Sweden)
Kontakt:

AVR är seriöst

Inlägg av Swech »

Måste bara försvara AVR.
Företaget jag konstruerar för har 40-50 produkter baserade på AVR, de största är levererade i mer än 15.000-20.000 exemplar. Worldwide
I dyra maskiner med höga krav på säkerhet.

Processorerna fungerar alldeles utmärkt, och är konsekvent uppbyggda.
Och vad gäller assembler.. om någon familj har märklig assembler
så är det PIC... inte AVR.
Vi har fasat ut alla PIC i nykonstruktioner sedan 3-4 år tillbaka och kör
endast AVR.. Så det är inte skräp... tvärtom. :)

Jonas
Användarvisningsbild
Stinrew
Inlägg: 954
Blev medlem: 20 augusti 2006, 03:14:41
Ort: Motala
Kontakt:

Inlägg av Stinrew »

Jag ställer mig bredvid Swech.

Jag läste en kurs i PIC-programmering på universitetet(bara för att prova på). Det var en 'C'-baserad kurs. Och jag som är van vid AVR, där gcc används tyckte att den kompilatorn som användes i PIC-kursen sög. Vi använde MPLAB med CCS-kompilator. Dom flesta elektrostudenter som jag känner här i Luleå är använder AVR, men han som förestår kursen älskar PIC. Han hade ett argument en gång om att någon stor PIC(jag tror att det var 18F452) hade 8 eller om det var 16 I/O med inbyggda pull-up motstånd, varpå jag skrattade. Känner inte till någon AVR som inte har pull-up på samtliga I/O. Ni som kan PIC stämmer det, har inte alla PIC pull-up på samtliga I/O???
Användarvisningsbild
bengt-re
EF Sponsor
Inlägg: 4829
Blev medlem: 4 april 2005, 16:18:59
Skype: bengt-re
Ort: Söder om söder
Kontakt:

Inlägg av bengt-re »

C hör inte hemma på små uC. Skall man köra C så bör man upp i storleken 18F, Blackfin, Renansas R8C. Småttingar mår och går bäst med assambler.

EDIT:
Om ATMEL gör bra prylar, varför certifierar de sig inte hos något klassningssällskap? Nej, små saker:PIC med assambler, större saker så välj något seriösare - troligen är Renansas den mest prisvärda och mest lämpliga controllern på marknaden idag för midrange prylar.
Användarvisningsbild
exile
EF Sponsor
Inlägg: 496
Blev medlem: 21 oktober 2005, 23:32:07

Inlägg av exile »

Varför skulle skulle ATMEL vara så oseriösa om jag får fråga? (ISO/TS 16949 certification)
Varför skulle C inte passa en μC?
Användarvisningsbild
bengt-re
EF Sponsor
Inlägg: 4829
Blev medlem: 4 april 2005, 16:18:59
Skype: bengt-re
Ort: Söder om söder
Kontakt:

Inlägg av bengt-re »

Nej, såå oseriösa är de väl inte. Vad jag säger är att Renansas och Microchip är bättre på att skriva datablad och låter fler oberoende godkänna deras kvallité. Detta gör att hela produkten (utvecklingsmiljö, kretsar, support, kvallité, dokumentation samt rena datablad) är överlag mer genomarbetat, sen att det finns bra och dåliga saker med allt som finns på marknaden är en annan sak.

C är inte så lyckat till små uC. Det är långsamt, utnyttjar processorn dåligt, slösar minne och finns stor risk att kompilatorbuggar ger svårlösta problem. Små uC måste man ändå läsa så mycket datablad för att utnyttja så att att finessen med standardkod försvinner. C koden går inte fortare att skiva och absoult inte fortare att debugga eller i slutändan exekvera...

När man går upp i storlek/hastighet/minne/komplexitet så blir C en absolut nödvändighet istället, men detta är en helt annan sak. I ett mellanläga så kan kombinationen högnivåspråk med inlineassambler vara bästa lösningen för att både spara energi på att skriva "enkla" saker i C och ändå behålla snabbheten i tidskritiska rutiner.
Skriv svar