atmega, xilinx, atmel

er loopt dus toch iets fout nu

C:\Users\fcapri\Documents\AVR>avrdude -c usbasp -p 8515 -u -U flash:w:LEDS.hex -F

avrdude: warning: cannot set sck period. please check for usbasp firmware update
.
avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.05s

avrdude: Device signature = 0x000102
avrdude: Expected signature for AT90S8515 is 1E 93 01
avrdude: NOTE: FLASH memory has been specified, an erase cycle will be performed

         To disable this feature, specify the -D option.
avrdude: current erase-rewrite cycle count is -50462977 (if being tracked)
avrdude: erasing chip
avrdude: warning: cannot set sck period. please check for usbasp firmware update
.
avrdude: reading input file "LEDS.hex"
avrdude: input file LEDS.hex auto detected as Intel Hex
avrdude: writing flash (12 bytes):

Writing | ####                                               | 8% 0.01s ***faile
d;
Writing | ########                                           | 16% 0.11s ***fail
ed;
Writing | #############                                      | 25% 0.21s ***fail
ed;
Writing | #################                                  | 33% 0.30s ***fail
ed;
Writing | #####################                              | 41% 0.40s ***fail
ed;
Writing | #########################                          | 50% 0.50s ***fail
ed;
Writing | #############################                      | 58% 0.59s ***fail
ed;
Writing | #################################                  | 66% 0.69s ***fail
ed;
Writing | ######################################             | 75% 0.79s ***fail
ed;
Writing | ##########################################         | 83% 0.88s ***fail
ed;
Writing | ##############################################     | 91% 0.99s ***fail
ed;
Writing | ################################################## | 100% 1.08s

avrdude: 12 bytes of flash written
avrdude: verifying flash memory against LEDS.hex:
avrdude: load data flash data from input file LEDS.hex:
avrdude: input file LEDS.hex auto detected as Intel Hex
avrdude: input file LEDS.hex contains 12 bytes
avrdude: reading on-chip flash data:

Reading | ################################################## | 100% 0.20s

avrdude: verifying ...
avrdude: verification error, first mismatch at byte 0x0001
         0xc0 != 0x00
avrdude: verification error; content mismatch

avrdude done.  Thank you.


C:\Users\fcapri\Documents\AVR>

Als je een device "gelocked" hebt, mag ie geen informatie prijs geven over de inhoud van de flash. Als je dan "00 00 00 00 ... " door zou geven kan je denken dat je programmer een los draadje heeft. Atmels geven daarom in zo'n geval gewoon het adres terug waar je om gevraagd had. Je vraagt de inhoud van adres X je krijgt het adres x. Geen informatie over de inhoud van de flash, wel de informatie: je programmer doet het.

Ik DACHT dat de signature bytes niet zo konden worden. Maar het lijkt alsof EricP gelijk krijgt!

@fcapri: Dit soort verification errors krijg je als er "iets mis" is. Wat er dan mis gaat is niet altijd duidelijk. Als jij een oude AVR op een "door anderen" gemaakt bordje aan het testen bent, kan er van alles mis gaan op de rest van het bordje. Misschien moet je een extern pootje hoog maken om de andere electronica op het bordje z'n mond te laten houden.

/ik/ heb de ervaring dat het erg vervelend is als de electronica op je PCB interfereert met het programmeren van de MCU. Dus ik probeer bij het ontwerp er voor te zorgen dat dit niet verkeerd kan gaan. Maar soms "moet" je. Op de attiny44 is het zo dat de SCL en SDA (I2C) dezelfde pins zijn als SCK en MOSI (SPI, programming). Dus als I2C is aangesloten kan ik niet programmeren, en als de programmer is aangesloten kan ik niet met I2C communiceren. Lastig. Maar het moest zo.

[Bericht gewijzigd door rew op zaterdag 10 mei 2014 08:25:20 (45%)

ik ben al een stap verder.

die 'debugging' connector op de pcb is iets verschillend met de connector van de usbasp.

 usbasp connector:
pin 1 = MOSI    pin2 = VCC
pin 3 = GND     pin4 = TX
pin 5 = RESET   pin6 = RX
pin 7 = SCK     pin8 = GND
pin 9 = MISO    pin10= GND

die heeft dus bljkbaar 3 keer ground, alleen is pin 3 en pin8-10 NIET aan elkaar verbonden. als ik de asp uitmeet, komt pin 8 en 10 wel degelijk aan massa, maar pin 3 lijkt niet aangesloten te zijn. daar loopt het dan wel fout want ik had pin 3 als massa gezet (lekker handig, 5 pinen op 1 rij die ik doorverbind en enkel de eerste pin van rij 2 (VCC).
op mijn pcb zijn er een heleboel massa's, maar pin 3 is NC. ipv kabels heb ik nu dus een header op de pcb gesoldeerd en kan men programmer rechtstreeks inpluggen daar

 AVR PCB connector:
pin 1 = MOSI    pin 2 = VCC
pin 3 = NC      pin 4 = GND
pin 5 = RESET   pin 6 = GND
pin 7 = SCK     pin 8 = GND
pin 9 = MISO    pin10 = GND
pin11 = NC      pin13 = NC
pin13 = RXD     pin15 = VCC
pin15 = TXD     pin17 = GND
pin17 = INT1    pin18 = GND

als ik nu uitlees, krijg ik

D:\raspberry>avrdude -p 8515 -y -c usbasp -e -F

avrdude: warning: cannot set sck period. please check for usbasp firmware update
.
avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.05s

avrdude: Device signature = 0x000102
avrdude: Expected signature for AT90S8515 is 1E 93 01
avrdude: erasing chip
avrdude: warning: cannot set sck period. please check for usbasp firmware update
.
avrdude: erase-rewrite cycle count is now -50462976
avrdude: WARNING: can't write memory for cycle count, rc=-6

avrdude done.  Thank you.

ik krijg nog altijd die signature fout, maar de cycle count is er wel nu

erase van de chip:

C:\Users\fcapri\Documents\AVR>avrdude -p 8515 -c usbasp -e -F

avrdude: warning: cannot set sck period. please check for usbasp firmware update.
avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.05s

avrdude: Device signature = 0x000102
avrdude: Expected signature for AT90S8515 is 1E 93 01
avrdude: current erase-rewrite cycle count is -50462977 (if being tracked)
avrdude: erasing chip
avrdude: warning: cannot set sck period. please check for usbasp firmware update
.

avrdude done.  Thank you.

[Bericht gewijzigd door fcapri op zaterdag 10 mei 2014 09:03:33 (15%)

Ik DACHT dat de signature bytes niet zo konden worden. Maar het lijkt alsof EricP gelijk krijgt!

Uit de datasheet van de AT90S8515: Note: 1. When both Lock bits are programmed (lock mode 3), the signature bytes cannot be read in Serial Mode. Reading the signature bytes will return: $00, $01 and $02.

ik heb zo wat verder gelezen, en wat ik eruit verstaan heb ik het volgende:
die chips hebben lock mode 3 aanstaan. kan je dus ook niet meer uitlezen. een erase helpt niet veel, de cycle count gaat omhoog, maar de locks blijven aanstaan. ofwel doe ik iets fout in het erasen.

als die daadwerkelijk serieel niks wil doen, zou mogelijk de SPIEN afstaan. dan zit er niks anders op dan parallel te programmeren

Je kunt serieel wel degelijk een chip erase doen. Alleen als serial programming disabled is, kun je niks meer.
Ik verwacht dat echter niet, omdat ze die lijntjes nou specifiek naar een debug connector hebben gebracht en het lijkt ook goed te gaan met je signature read (je zou alleen maar 0 of 0xff verwachten als serieel niks meer doet).

Maar je zit nu dus precies in de situatie waar ik je voor waarschuwde: programmer die je niet vertrouwen kan en een stuk target hardware waar je niet zoveel van weet.

Vergeet het hele hoofdstuk uitlezen. Ook dat kun je parallel / HV niet (anders zouden die lock bits ook niet zoveel zin hebben).

dat teruglezen heb ik al geschrapt. word niks als dat een hoop machine code is. zal later dat display aansturen zelf mogen uitdokteren dan.

ik had je waarschuwing vorige keer gelezen over dat usbasp ding, dus was direct gaan kijken voor eentje waar dat niet bij stond en had die direct besteld en betaald.
bij aankomst, bleek dat dus ook dat usbasp ding te zijn.

ik kan communiceren met de chip, das al goed.
die error die ik overal krijg van "cannot set sck period" vind ik op internet ook overal terug. daar raden ze firmare upgrade van de atmega op de usbasp aan.
probleem: je met een werkende AVR programmer hebben dan om die usbasp te herprogrammeren. je moet dan ook een jumper herzetten. aangezien ik geen andere AVR programmer heb, lukt dat dus ook niet.
budget ga ik van de vrouw niet meer krijgen deze maand (heb al een raspberry gekocht, grote usb stick, SD kaart voor raspberry, avr programmer, 2 oldtimervelgen gekocht op de meeting vorige week. (ook net terug van 3weken china, was ook een grote hap uit het budget. daar dus ook speelgoed gekocht: 18650 power bank, 2 'fake' usb sticks)

Die clock period is alleen van belang als die AVR langzaam loopt. De clock van de serial programming mag in relatie tot de system clock niet te hoog zijn (zie datasheet; ken de details niet uit m'n hoofd). Aangezien je wel response terug krijgt, lijkt het er op dat daar je probleem niet zit.

Verder is er vast wel iemand zo vriendelijk die (als jij het spul aanlevert) jouw programmer wil programmeren. Dit is wat ik je ook aanraadde (2nd best na een 'echte' ). Het is een modernere versie van de variant die ik zelf heb (die ziet er zo uit), de prijs is ook iets hoger geworden.
Het leuke van dat ding is dat je er een linux live CD bij krijgt. De FTDI USB-serial controller kan ook nog wat bitbangen en de firmware wordt er vanaf je PC in gefrut (je moet geen haast hebben). Je kunt zo dus ook updaten (en zo wordt het kip&ei probleem opgelost).

Concreet zou ik me eens richten op de chip erase. En daarna signature byte read. Als dat werkt, kun je verder kijken.

[edit]
Vroeger, heel lang geleden, toen ik nog jong was, heb ik zelf een AVR programmer gebakken. 2nd source was er nauwelijks en duur. USB ook niet echt. STK500 buiten budget. Het werd dus bitbangen onder DOS op de centronics poort. Eerst eens een lijntje togglen en met de scoop kijken hoe hard dat gaat (om evt. delays uit te kunnen rekenen). Daarna signature bytes lezen. Als dat werkt, eens een byte in EEPROM zetten en terug lezen. Daarna IP onder DOS optuigen (ja, dat kon echt) om bij de data op de Win95 doos te kunnen (waar winavr draaide). Dan een interpreter bakken voor het fileformat. En uiteindelijk kunnen programmeren.

Op 10 mei 2014 09:03:12 schreef EricP:
When both Lock bits are programmed (lock mode 3), the signature bytes cannot be read in Serial Mode. Reading the signature bytes will return: $00, $01 and $02.[/i]

Ik heb even getest of een AVR (een ATmega32 in dit geval) hetzelfde doet als je de signature wil uitlezen zonder voorafgaande handshake.
Maar in dat geval krijg ik 0xFFFFFF terug.

ik ben al wat verder, nu blijkt die usbasp chinese namaak 1 grote bug te hebben. VERKEERDE addressen

een gewone echte usbasp van fischl:
#usbvid = 0x03EB;
#usbpid = 0xC7B4;

de mijne
id = "usbasp-clone";
desc = "Any usbasp clone with correct VID/PID";
type = usbasp;
usbvid = 0x16C0; # VOTI
usbpid = 0x05DC; # Obdev's free shared PID

door ff avrdude.conf aan te passen en een usbasp-clone toe te voegen, omzeilt ge dit.
ik krijg nu dit

C:\WINAVR~1\bin>avrdude -p 8515 -y -c usbasp-clone -U lfuse:r:-:h -U hfuse:r:-:h
 -U lock:r:-:h -F

avrdude: warning: cannot set sck period. please check for usbasp firmware update
.
avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.05s

avrdude: Device signature = 0x000102
avrdude: Expected signature for AT90S8515 is 1E 93 01
avrdude: current erase-rewrite cycle count is -50462977
"lfuse" memory type not defined for part "AT90S8515"

Het is even geleden dat ik met AVRdude gespeeld heb (als in: ik heb wat 'default commandlines' die doen wat ik wil), maar... De fuses kun je ook niet meer lezen als de boel gelocked is. En het lijkt erop dat je dat aan het doen bent.

Op 10 mei 2014 09:03:12 schreef EricP:
[...]Uit de datasheet van de AT90S8515: Note: 1. When both Lock bits are programmed (lock mode 3), the signature bytes cannot be read in Serial Mode. Reading the signature bytes will return: $00, $01 and $02.

Nou! Zie je wel dat je gelijk krijgt!

Op 99,9% van de commerciële producten waar ik AVR uC vanaf gehaald heb waren de fuse bits gelockt.

Als je geen gegevens van het display hebt kun je beter de uC met rust laten en via een logic analyzer het aansturen van het display achterhalen. Omdat vervolgens te programmeren in je eigen programma.

Het is allemaal veel werk echter. Vaak haal ik de uC eraf en knoop deze via een eigen printje en bekend display aan elkaar.

ok, we hebben natuurlijk 1 piste vergeten... die displays van in mijn openingspost zijn in principe afgeschreven wegens defect.
mogelijk is die AVR gewoon omzeep en reageerde die niet meer op commando's van de printer (kan ook basic fouten zijn als toesten die happeren of display die geen beeld gaf).

de eerste die ik al de hele morgen test, geeft bij aansluiten van de voeding soms een zwart beeld, soms een grijs, soms niks. af en toe springt de verlichting van scherm aan en voor de rest niks.

daarom dacht ik nu, laat ik eens een andere print nemen uit de hoop.
de volgende is een atmega8515 (hehe, das diegene die wel in alle softwares staat ipv de oudere AT90S8515 die nergens ondersteund wordt). en deze geeft me dit antwoord:

D:\raspberry\AVR\AVR>avrdude -c usbasp-clone -p m8515

avrdude: warning: cannot set sck period. please check for usbasp firmware update
.
avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.05s

avrdude: Device signature = 0x1e9306

avrdude: safemode: Fuses OK

avrdude done.  Thank you.

Nou, dan lijkt je programmer te draaien
Overigens zit er niet zoveel verschil tussen een 90S8516 en een mega8515. Ik zou daar niet direct een probleem verwachten. Maar ja, assumptions are the mother of...

verschil zal niet zoveel zijn, maar die extreme burner ondersteund wel atmega8515 en niet de AT90S serie.
ik gebruik dus die GUIom uit te lezen:
flash gelezen en gesaved: OK
eeprom gelezen en gesaved: OK
lockbits kan ik ook lezen. bij het uitlezen maakt hij wel een buzzer geluid (print heeft ook buzzers zitten). erase is gelukt, en bij teruglezen met die software heb ik overal FFFF FFFF... nu.

onze eerste software erin en het ledje gaat branden

; My Very First AVR Project

.include "8515def.inc" ;Includes the 8515 definitions file 
 
.def Temp = R16 ;Gives "Defines" Register R16 the name Temp 
 
.org 0x0000 ;Places the following code from address 0x0000 
 rjmp RESET ;Take a Relative Jump to the RESET Label 
 
RESET: ;Reset Label 
 ldi Temp, 0xFF ;Store 255 in R16 (Since we have defined R16 = Temp) 
 out DDRD, Temp ;Store this value in The PORTB Data direction Register 
 
Loop: ;Loop Label 
 out PORTD, Temp ;Write all highs (255 decimal) to PORTB 
 dec Temp ;Decrement R16 (Temp) 
 rjmp Loop ;Take a relative jump to the Loop label

leuke toevoeging, heb het defect aan deze print gevonden. af en toe spring de schermverlichting aan. flatcable van display gescheurd. aan deze AVR zal dus NIKS mis geweest zijn, alleen geen beeld meer. ff ander scherm ingeplugt en daar is de verlichting

[Bericht gewijzigd door fcapri op zaterdag 10 mei 2014 11:54:09 (11%)

Tsja... gui... tsja...
Waarschijnlijk lust die GUI de fuses niet. Dat zal het voornaamste verschil zijn. Wellicht nog wat met mem sizes. Maar vergelijk de datasheet maar. Voor de programmer maakt het niet veel uit of het een tiny, mega of 90S is.

kent er iemand goeie boeken of pdf's om de taal van het programmeren te leren?

ik heb nu al wat assembler gedaan, maar das sterk verouderd (nog op school gezien), ben dan over gegaan op C en dit schrijft wel iets vlotter, maar de logica zie ik er niet in.
if (PINA & (1<<PA2))
PORTD |= (1<<PD5);

C++ geprobeerd in atmel studio 6, maar die begint al gek te doen dan _delay_ms niet bestaat en kreeg het niet draaiend.
als ik naar examples zoek, kom ik 10verschillende codes tegen, die allemaal hetzelfde zouden doen???
bv een uitgang omschakelen (waarom hoog zetten nergens te vinden is weet ik niet):

PORTD |= (1<<PD6);

of

PORTD ^= _BV(PD6);

of

tbi(PORTB,PB0);

stuk voor stuk totaal verschillende delen, niks logisch uit te halen, allesinds toch niet dat ik vlot zou kunnen onthouden.
waar is de tijd dat je gewoon pd6 := 1; kon doen heen???

ook voor uitgangen te definieren
DDRB=0xff;
OF
DDRD |= _BV(DDD5);

als ik dan de verklaringen van bovenstaande instructies zoek, kom je niks duidelijks tegen. ik heb een programma proberen maken die de led op het printje rood en groen laat knipperen, en als je een knop indrukt dat het scherm zou oplichten. afzonderlijk lukt, maar samen gecodeerd, begint met rode led snel te knipperen, gaat het scherm aan zolang je indrukt en direct weer los...

daarom zoek ik iets waar de instructie set instaat, en hoe toe te passen. zomaar iets overtypen van het internet zonder te weten wat de code uitvoerd is ook onzin

Waarom je _BV() moet gebruiken en niet (1<< .. ):
http://nongnu.org/avr-libc/user-manual/FAQ.html#faq_use_bv

Instructieset staat bij Atmel

Verder moet je bedenken dat alles in een AVR gestuurd wordt via de IO registers. En alle IO registers kun bereiken als een geheugenadres (er zijn soms andere, snellere methoden maar dat lost de compiler voor je op).
PORTD is zo'n register. De namen van alle registers vind je in de Atmel datasheet van je part.

Verder wil je de C operator-table erbij houden:
http://en.wikipedia.org/wiki/Operators_in_C_and_C%2B%2B

C++ kan wel, maar ik zou het effe simpel houden als ik jou was. Enige makkelijke manier om met C++ te beginnen is Arduino.

Assembly is zeer zeker niet sterk verouderd - zeker niet in combinatie met een μC. (solderen heb ik ook op school nog gedaan... en daarmee is het niet meteen verouderd).
C++ ... Tsja... Hork van een taal die vanalles voor jou wil gaan doen waarvan je je af moet vragen of je dat wel wilt (zeker op een μC). Dan kom je toch uit bij C (goh, zou er een reden zijn dat dat op controllers zoveel gebruikt wordt??).

Delays op μC? Not done. (alhoewel het uiteraard wel kan als het moet). Maar eh... Heb je wel een compiler geïnstalleerd?

Voor wat betreft de voorbeelden: zo onlogisch is het niet. Maar eerst even kruipen voordat je gaat hardlopen.
Poorten zijn 8 bits registers. Als je daar wat in wilt veranderen, dan is het niet meer dan logisch dat je het hele register leest, omharkt naar wat jij leuk vindt en dan weer schrijft (en nee, voor rmw problemen moet je in de pic-ding hoek zijn). Dus, als ik PB3 hoog wil maken (aangenomen dat DDR goed staat):

PORTB=PORTB | (1 << PB3);

Dat levert hetzelfde op als

PORTB=PORTB | _BV(PB3);

Daar houdt het bij mij meestal op. Echter, het kan in C korter door wat dingen weg te laten.

PORTB|=_BV(PB3);

doet precies hetzelfde. Of je het moet willen... Dat is een andere discussie. Zoals gezegd... Ik schrijf het meestal uit - het levert dezelfde assembly code op. Daar heb ik 1 uitzondering op. Dat is als ik counter 1 wil verhogen. Voluit wordt dat

counter=counter+1;

In de korte vorm:

counter++;

En nou maar uitzoeken wat jij een handige schrijfwijze vindt. En eh... in C++ laat maar.

Voor wat betreft die tbi: het is ongetwijfeld een macro die waarschijnlijk iets als 'toggle bit' ofzo moet voorstellen (dat kan de hardware van een AVR ook door (hoe krom ook) een 1 naar die plaats van het input register te schrijven).

Voor die delay: Ik neem aan dat je het betreffende header file included hebt? Anders houdt het natuurlijk snel op...

Op 10 mei 2014 11:40:07 schreef fcapri:
verschil zal niet zoveel zijn, maar die extreme burner ondersteund wel atmega8515 en niet de AT90S serie.

Atmel komt er wel eens achter dat de naamgeving van hun processoren niet handig is. Ze hadden ooit: at89xxx 8051 compatible microcontrollers en at90xxxx hun eigen AVR architectuur. Toen die laatsten wat groter werden wilden ze die een eigen naam gaan geven. Zo zijn toen een zwik at90 chips hernoemd naar attiny of atmega. at90S2313 -> attiny2313, at90USB162 -> atmega16u2 en AT90S8515 -> atmega8515. Soms hebben ze een nieuw datasheet gemaakt, en de specs iets aangepast. Dingen als: max clock op 3.3V: 8MHz, max clock op 4.5V: 20MHz. En dat eerste: max 8MHz gold dan eigenlijk ook voor 4.4V. Tegenwoordig zeggen ze: tussen 3.3 en 4.5V mag je lineair van 8mHz naar 20MHz. De oudere chips konden dat ook wel, maar het stond niet in de specs dat je halverwege de 3.3 en de 4.5 (i.e. 3.9V) op 14MHz (i.e. halverwege 8 en 20) mocht draaien.

Voor de upgrade AT90S8515 -> atmega8515 hebben ze de specs iets vernieuwd. Clock frequentie van 4/8 naar 8/16 en het signature byte2 van 01 -> 06.

compiler heb ik wel, heb ondertussen een 5tal programmas staan waardoor nu zowat alles draait.
als ik commandline avr-gcc in tik, is dat een C compiler (C-> ELF file -> HEX file).
als ik in atmel studio op rebuild solution druk, compiled die ook alles, maar in 1 keer (EEP, ELF, HEX... files. stuk of 6).

die zet ik dan over met avrdude op de atmega en dat lukt goed.

1 ledje laten knipperen, is geen probleem. t is een 2kleurige led met slechts 2 aansluitingen. en dan begint het.
voor groen moet ik PD6 hoogmaken en PD7 laag, voor rood moet ik PD6 laag maken en PD7 hoog, voor oranje... moet ik een hele hoge schakelfrequentie nemen en moet ze dan afwisselend gaan.
tot daar toe lukt alles.
op mijn pcb zit ook een display met achtergrond verlichting (groen of witte led). die wordt aangestuurd door PD5 (enkel laag maken, de leds hangen aan VCC).

door een combinatie te maken van knipperende leds, loopt het soms al fout. ik wil slechts 1 ingang laten veranderen en soms wordt HEEL het register getoggled.
stel: ik laat de rode led branden, en wil het display aansturen met een drukknop. als ik de drukknop indruk, lukte het me om het display licht te laten branden, maar mijn rode led veranderde naar groen (heel het register dus getoggled).

ik schreef nu de volgende code (en maakte een copy paste fout)

int main (void)
{
	DDRD |= _BV(DDD6);
	while(1)
	{
		PORTD=PORTD | (1 << PD3); // rode led brand
        }
}

en daar loopt het fout, pd3 hangt totaal niet aan de rode led, en toch brand deze. ik verander nu de code naar dit:

int main (void)
{
        DDRD |= _BV(DDD5);
	DDRD |= _BV(DDD6);
	while(1)
	{
		PORTD=PORTD | (1 << PD5); // verlichting scherm
        }
}

nu zou dus de verlichting van het scherm moeten gaan branden, maar het scherm licht op (OK), alsook de rode led brand (vroeg ik niet).
ik dacht dan: als ik uitgangen selecteer, worden die automatisch hoog. en doordat ik PD7 niet defineer zal die als ingang stroom naar massa toelaten en daarbij brand de led, dus ik voeg DDRD |= _BV(DDD7) toe waardoor de led aan 2 uitgangen hangt, en nu brand de led oranje.
DWZ: de uitgangen switchen HEEL SNEL tussen aan en uit.
het display daarentegen op PD5 blijft gewoon uit.

@ REW: ik vond op internet ook al dat de atmega de opvolger was van de AT90S8515, maar als ik de AT90 aan de programmer hang en selecteer de atmega8515 krijg ik gewoon een fout dat de chip niet correct is. uitlezen resulteerd gewoon in code
0102 0304 0506 0708 090A .....
erasing lukte niet. atmega eraan en alles ging perfect.
ik had 1x AT90S8515 pcb staan, 2x ATMEGA8515 en een stuk of 6 XILINX XC9536XL chips. allemaal met hetzelfde display en ook eenzelfde debugger connector. bij de xilinx processoren zit er nog een HC14AG IC tussen

Zo maar eens wat gezeur in de marge, niet direct prijs schieten op jouw probleem:

• Je tags staan tussen 'bascom' code. Probeer eens 'c'
• In je main begin je met DDRD te or-en. Het ding heeft een default, dus het zou wel goed moeten gaan. Ik houd er niet van om op defaults te vertrouwen (al heb ik Atmel er nog niet op betrapt daar ellende in te veroorzaken) --> de eerste keer set ik hard in het register wat *ik* erin wil hebben. Dan heb ik een gedefinieerde uitgangssituatie.
• Je zegt dat je LED aan PD6 en PD7 hangt. Terwijl ik nergens zie dat je daar outputs van maakt.
• Houd er rekening mee dat inputs pull-up kunnen hebben (dat zet je aan & uit in het port register). Een input is prima in staat om 'hi Z' te zijn: als input zetten en de output pin laag (als ik het wel heb).
• Een open deur: wat denk je dat er aan het einde van de main gaat gebeuren? Juist, die start opnieuw. Zou het kunnen dat je LED het in RESET ofzo ook iets doet en dat je daar naar zit te kijken? Als je wilt dat de boel niks meer doet (en voor het moment wil je dat), dan eindig je met een

  c code:

  while(1);

Ik kan je probleem zo even niet plaatsen. Het zou natuurlijk kunnen dat er rottigheid op de PCB zit. Teken eens een (stukje) schema; maakt het voor zowel jou als mij duidelijker (en wellicht het 'a-ha effect' ).
Verder zou je de RESET eens hard aan GND kunnen hangen. I/O is dan in principe Hi Z. Je kunt dan zelf eens wat dingen hoog & laag trekken en kijken wat er gebeurt. Het zou mij niet verbazen als daar een hardware-iets uit komt.

Alhoewel ik het alleen een keer met een tiny22 heb meegemaakt... Zou die AVR natuurlijk rot kunnen zijn. Alhoewel het best taaie beestjes zijn die tot op heden alle mishandelingen die ik er op los heb gelaten hebben doorstaan...

Die mega & tiny varianten zijn vaak wat doorontwikkeld: peripherals met meer mogelijkheden, extra 'iets' erin. Ze zijn wel backward compatible: de defaults zijn zo gekozen dat als je niks doet, het ding zich zoals z'n voorganger gedraagt. Ik denk zelfs dat ze binairy compatible zijn (als in: alle registers zitten op hetzelfde plekje enzo), alhoewel je dat na zou moeten kijken. Ik heb wel eens code voor een 90S2313 in een tiny2313 gedouwd (binair) en dat liep zonder problemen. Maar dat kan ook mazzel geweest zijn.

het schema is heel basic.
de atmega staat op een stuk print. dat printje heeft 6 drukknoppen. die hangen met een weerstand aan +VCC en de andere kant aan massa. pull up dus. alle knoppen zitten op PA0 tot PA6.
dan hangt er een bicolor led aan tussen PD6 en PD7 via 2 weerstandjes. (EDIT: deze led is klein SMD en is dus blijkbaar toch een 3poot bicolor led met de gemeenschappelijke pin aan VCC, vond de 2 weerstandjes al zo raar. door de multilayerprint zag ik dat d3de spoor niet).
er hangt een LCD display op de uitgangen van port B,C en D. daarvan vond ik al dat PD5 de 2 leds op het display aansturen. andere kant van die leds hangt aan VCC met een weerstand.
er hangt een debugging connector op de mosi,reset,sck,miso,rxd,txd en int ingangen. ook voed deze de VCC en massa.
op de atmegaprint zitten 2 buzzers die zoemen als ik schrijf of lees naar de atmega. deze zitten niet op mijn gedemonteerde print dus kan niet kijken waar ze aanhangen (multilayer print).
verder nog wat weerstandjes en transistors die naar een 10polige connector leiden waarmee deze print en de printer ooit communiceerden.

PD5 laag maken = schermverlichting brand
PD6 en PD7 sturen de bicolor led aan

als eerste een programma schrijven die de led laat knipperen met een _delay_ms lukt goed. ook de led in 2 kleuren laten knipperen, lukte ook... soms (kan wel te maken hebben dat ik niet wist dat die 3poten had. rood en oranje zijn nogal moeilijk te onderscheiden.

het probleem dat zich voordoet is: elk voorbeeld op internet om een led te laten knipperen werkt met PD0 en de led aan +5V via een weerstand. de mijne hangt via 2 weerstanden op PD6 en PD7. moet ik telkens wat code veranderen.

dit vond ik op internet:

    // Turn on LED output pin 
    DDRB   |= _BV(DDB0); 

maakt dit nu outputs van die PB0 of niet?

Aangenomen dat je de juiste AVR meegeeft aan je compiler, maakt dit een output van PB0 (let wel: 1 pin, enkelvoud dus!). Het zegt niks over de andere pinnen op die port.