Allgemeine Fragen zu STK 500

[Holzauge]

Hallo Leute,
ich habe nach sehr langer Zeit mein STK500 Board mal wieder herausgeholt.
Ich bin Zwischenzeitlich aber auf MAC umgestiegen.
-Gibt es die AVR Studio 4 version auch für OSX?
-Ich habe sonst immer den AT90S2313 benutzt, den es zu meinem erstaunen nicht mehr gibt. Kann ich dort einfach einen ATtiny2313 verwenden(mit dem gleichen Program File und der gleichen include datei)?
-Ich habe das Programm vorerst für einen AT90S8515 umgeschrieben.
Auf dem AVR Studio Simulator läuft das auch einwandfrei. Auf dem Board gibt es da denn doch Probleme, da die Taster und LED`s nicht das machen, was ich will. Um Kontaktprobleme mit meinem Sockel zu kontrollieren habe ich den Durchgang von den IC-Beinen zu den Port-Pfostenstecker mal kontroliert.Da kommt aber PB0 vom AVR nicht unbedingt auf PB PB0 des Pfostensteckers an.
Ist das normal?

 

[Oskar01]

Hallo, @holz...,
habe mal das Pdf-File vom STK-Board nachgeblättert.
Auf Seiten 13 bis 20 ist da etwas über die Pins und zugehörigen Sockel/Fassungen beschrieben, die auch bestimmten AVR-MCUs zugeordnet werden.

Kann natürlich auch sein, daß gerade Dein verwendeter AVR etwas abweicht im Pinout zum STK500-Board.

Also, Datenblatt vom tatsächlich verwendeten AVR MC nachschauen und
mit dem Pinout des STK-Boardes vergleichen.

Hoffentlich klappt es mit dem Download.
Das File kann heruntergeladen werden von URL:

www.atmel.com/atmel/acrobat/doc1925.pdf

Dann, natürlich überprüfe nochmal, ob das passendste Include-File benutzt wird,
bei mir hakte es nämlich, da ich statt

"m8515def.inc"

"8515def.inc"

verwendete, mit der Folge, daß
die UART-16-Bit-Suite nicht ging.

Gruß von Oskar01

P.S: Hier noch einige Portzuweisungen bei den verschiedenen, oben erwähnten
MCUs:

;* Number :AVR000
;* File Name :"2313def.inc"
;* Title :Register/Bit Definitions for the AT90S2313
;* Date :99.01.28
;* Version :1.30
;* Support E-Mail :avr@atmel.com
;* Target MCU :AT90S2313

.equ PB7 =7
.equ PB6 =6
.equ PB5 =5
.equ PB4 =4
.equ PB3 =3
.equ PB2 =2
.equ PB1 =1
.equ PB0 =0
----
.equ PD6 =6
.equ PD5 =5
.equ PD4 =4
.equ PD3 =3
.equ PD2 =2
.equ PD1 =1
.equ PD0 =0
----

;* Number :AVR000
;* File Name :"8515def.inc"
;* Title :Register/Bit Definitions for the AT90S8515
;* Date :99.01.28
;* Version :1.30
;* Support E-mail :avr@atmel.com
;* Target MCU :AT90S8515

----
;PORTA
.equ PA7 =7
.equ PA6 =6
.equ PA5 =5
.equ PA4 =4
.equ PA3 =3
.equ PA2 =2
.equ PA1 =1
.equ PA0 =0
----
;PORTB
.equ PB7 =7
.equ PB6 =6
.equ PB5 =5
.equ PB4 =4
.equ PB3 =3
.equ PB2 =2
.equ PB1 =1
.equ PB0 =0
----
;PORTC
.equ PC7 =7
.equ PC6 =6
.equ PC5 =5
.equ PC4 =4
.equ PC3 =3
.equ PC2 =2
.equ PC1 =1
.equ PC0 =0
----
;PORTD
.equ PD7 =7
.equ PD6 =6
.equ PD5 =5
.equ PD4 =4
.equ PD3 =3
.equ PD2 =2
.equ PD1 =1
.equ PD0 =0
Bei include file "m8515def.inc" kommt noch ein
reduzierter PortE hinzu
;PORTE
.equ PE2 =2
.equ PE1 =1
.equ PE0 =0

Noch ein Hinweis:
Das sind natürlich nicht die Pinne am IC-Sockel, sondern die Bit-Zuweisungen an den jeweiligen Ports.
Das korrekte Pinout findest Du dazu in den jeweiligen Datenblättern. Da sind auch neueste Abweichungen noch vermerkt.

Anhand dieser Infos kannst Du dann bei Bedarf die Portsteckverbindungen noch auf Deine speziellen Bedürfnisse hin "umlöten".

 

[Oskar01]

Austausch ATMega8515 mit ATiny2313

Hallo @Holz....,
konnte mich nicht bremsen, und wollte mal sehen, was passiert, wenn ich statt des ATMega8515 spaßeshalber den ATTiny2313 in den 20-poligen Sockel direkt neben dem 40-poligen für den ATMega reinstecke. (Den ATMega natürlich vorher rausgezogen, sonst gibt es doch wohl Fehler-))

Komisch,
bei mir klappen die von mir ausprobierten Programme auf Anhieb, die eigentlich für den ATMega8515 geschrieben worden waren.

Da habe ich ja noch meine "Androhung" wahr gemacht, die Proggis auf den ATTiny rüberbeamen zu wollen.

Es wurden an Fuses nur der Prescaler von 8 rausgenommen und die ungültigen Register rausgeremt. (Stack/serielle Schnittstelle)
Bingo.

Also der Port B scheint eins zu eins auf dem STK500-Board genauso mit den Portpins des ATTiny2313 verbunden zu sein, wie beim ATMega8515.

LCD läuft, Timer läuft, nur serielle Schnittstelle noch nicht, weil ich das noch abändern muß auf 8-Bit-Registersatz.

Da scheint an Deinem Board wohl eine Unterbrechung an PortB Bit 0 vorzuliegen, könnte eventuell auch nur der Pfostenstecker sein.

Probiers noch mal, bitte.....Nimmst Du auch den Sockel direkt neben dem 40-poligen? Den rot unterlegten?

Also, bin echt von den Socken, das Ganze war 'ne Aktion von ca. 5 Minuten.
Also, sooo einfach hatte ich mir das wirklich nicht vorgestellt.
Das STK500-Board mit der Studio-Software gewinnt immer mehr Sympathie dazu, obwohl ich es am Anfang ja ziemlich in die Pfanne gehauen hatte.

Gruß von Oskar01

 

[Maik15]

Hallo ich hab auch ein Problem mit den Tastern vom STK500.

Irgend wie gehen die beim ATmega644 nicht.
kann es sein das Standardmäßig beim Mega644 die Pull Down Wiederstände Aktiviert sind.
Und sich dadurch die internen mit den Externen nicht vertragen?

Auf jeden fall kommt immer eine Logische Null an und das obwohl am Pin 5V anliegen.

Kennt das einer?

Gruß
Maik

 

[dino03]

Hallo zusammen,

-Ich habe sonst immer den AT90S2313 benutzt, den es zu meinem erstaunen nicht mehr gibt. Kann ich dort einfach einen ATtiny2313 verwenden(mit dem gleichen Program File und der gleichen include datei)?
-Ich habe das Programm vorerst für einen AT90S8515 umgeschrieben.
Auf dem AVR Studio Simulator läuft das auch einwandfrei. Auf dem Board gibt es da denn doch Probleme, da die Taster und LED`s nicht das machen, was ich will. Um Kontaktprobleme mit meinem Sockel zu kontrollieren habe ich den Durchgang von den IC-Beinen zu den Port-Pfostenstecker mal kontroliert.Da kommt aber PB0 vom AVR nicht unbedingt auf PB PB0 des Pfostensteckers an.
Ist das normal?

Dann, natürlich überprüfe nochmal, ob das passendste Include-File benutzt wird,
bei mir hakte es nämlich, da ich statt

"m8515def.inc"

"8515def.inc"

......
..
.
...
.......

;* File Name :"2313def.inc"
;* Title :Register/Bit Definitions for the AT90S2313
;* Date :99.01.28
;* Version :1.30
;* Support E-Mail :avr@atmel.com
;* Target MCU :AT90S2313

konnte mich nicht bremsen, und wollte mal sehen, was passiert, wenn ich statt des ATMega8515 spaßeshalber den ATTiny2313 in den 20-poligen Sockel direkt neben dem 40-poligen für den ATMega reinstecke. (Den ATMega natürlich vorher rausgezogen, sonst gibt es doch wohl Fehler-))

Komisch,
bei mir klappen die von mir ausprobierten Programme auf Anhieb, die eigentlich für den ATMega8515 geschrieben worden waren.

Achtung ! Aufpassen !
Ihr schmeißt hier mit den alten und neuen MCUs in der Gegend rum.
ATmega8515 => Neu! m8515def.inc
ATtiny2313 => Neu! t2313def.inc
AT90S8515 => Alt! 8515def.inc (Nachfolger ATmega8515)
AT90S2313 => Alt! 2313def.inc (Nachfolger ATtiny2313)

Bei Atmel steht drin was man bei der Migration auf die neuen Typen beachten
muß. Seht mal nach "mature devices" auf der 8Bit-Liste nach. Es gibt bei
einigen Befehlen Unterschiede (wie ich erfahren mußte) zB der LPM-Befehl
um Daten aus dem Flash zu laden. Der ist zB bei älteren nicht vorhanden oder
eingeschränkt auf bestimmte Register. Pinkompatibel sind die soweit aber im
Inneren hat sich ein wenig geändert.

Will noch jemand nen AT90S4433 haben ? Nachfolger ATmega8 (nur nen
Scherz - aber ich hab noch welche )

Gruß
Dino

 

[Maik15]

Danke für die Antwort.
Wenn Ich dich richtig verstanden hab soll man alte Chips nicht mit Neuem Code programmieren.

Aber ich bin mir sicher das dich das nicht gemacht hab.
Als alles versagt hat hab ich mal das hier ausprobiert.

Sollte eigentlich bei Eingabe von
Null auch Null anzeigen
Bei 1 auch 1 Anzeigen
Und ansonsten FF Anzeigen.

Die LED's funktionieren aber sind halt LOW aktiv aber daran kann man sich ja gewöhnen.
Und die Taster schalten auch durch so das ein Saubere Signal am Pin anliegt.

Hier ist mal mein Programm.
Vielleicht hab ich ja auch nur etwas vergessen.

#include <avr/io.h>				// Datei für Ein und Ausgänge
//===============================================================
int k = 0x00;
//===============================================================
int main(void)
{
	DDRA = 0x00;				//PortA als Eingang
	DDRB = 0xFF;				//PortB als Ausgang
	DDRD = 0x00;				//PortD als Eingang

	while (1) 							// Endlosschleife
	{
		k=PORTA;
		if (k<=1)
		{
			PORTB=k;
		}
		else
		{
			PORTB=0xFF;
		}	
	}
return 0;
}

Gruß
Maik

 

[dino03]

Hi Maik,

Wenn Ich dich richtig verstanden hab soll man alte Chips nicht mit Neuem Code programmieren.

Jein ... Den Binärcode (die Datei die man flasht) auf keinen Fall, den
Quellcode kann man aber zum größten Teil wiederverwenden.

So wie icch das unten sehe programmierst du in C. Da hab ichh relativ wenig
Erfahrung mit. Das sollte aber alles der Compiler anpassen. Dürfte also kein
Problem sein. Wenn er beim compilieren keinen Fehler meldet müßte das
so passen. In Assembler ist das natürlich etwas ganz anderes.

Aber ich bin mir sicher das dich das nicht gemacht hab.
Als alles versagt hat hab ich mal das hier ausprobiert.

Sollte eigentlich bei Eingabe von
Null auch Null anzeigen
Bei 1 auch 1 Anzeigen
Und ansonsten FF Anzeigen.

Die LED's funktionieren aber sind halt LOW aktiv aber daran kann man sich ja gewöhnen.
Und die Taster schalten auch durch so das ein Saubere Signal am Pin anliegt.

Die richtigen Steckbrücken/Kabel hast du wohl auch gesteckt (nehme ich
jetzt mal so an) ...

Hier ist mal mein Programm.
Vielleicht hab ich ja auch nur etwas vergessen.

#include <avr/io.h>				// Datei für Ein und Ausgänge
//===============================================================
int k = 0x00;
//===============================================================
int main(void)
{
	DDRA = 0x00;				//PortA als Eingang
	DDRB = 0xFF;				//PortB als Ausgang
	DDRD = 0x00;				//PortD als Eingang

	while (1) 							// Endlosschleife
	{
		k=PORTA;  // PINA !!! ist das Eingangsregister !!!
		if (k<=1)
		{
			PORTB=k;
		}
		else
		{
			PORTB=0xFF;
		}	
	}
return 0;
}

Gruß
Maik

Ich glaube du hast dich da mit PORTA und PINA verzettelt
Sonst scheint es soweit ok.
Mit PORTA=0xFF könntest du bei DDRA=0x00 höchstens die PullUps setzen
aber einlesen geht bei dem Eingang dann nur mit PINA. Wenn du PORTA
einliest dann liest du nur den Status der PullUps

Schau dir mal bei den FAQa die MiniFAQ von mir über die Register DDRx,PORTx,PINx an.
So und nun geh ich ins Bett. Ist schon wieder länger geworden als es
sollte. Gute Nacht ...

Gruß
Dino

 

[Maik15]

Danke für den Tipp mit dem PINA
Manchmal sieht man das offensichtliche nicht.
Dabei hab ich es mir sogar Unterstrichen.

Allerdings hab ich im Augenblick so viel Papier um mich herum das ich gar nicht weiß was ich zuerst lesen soll oder wo ich überhaupt das richte suchen soll.

Aber leider geht es Trotzdem nicht.
Was kann es denn jetzt noch sein.

Ist echt sch....e sich in das Thema einzuarbeiten.

gruß
Maik

 

[Maik15]

Ich hab eine Gute Nachricht.

Es geht

Fragt mich nicht wieso.
Aber ich hab das Projekt neu angelegt und es geht.

DION DANKE für die Hilfe.
Und die FAQ ist auch gut beschreiben mit der Grafik wird das gut verständlich.

gruß
Maik

 

[dino03]

Hallo Maik,

DINO DANKE für die Hilfe.
Und die FAQ ist auch gut beschreiben mit der Grafik wird das gut verständlich.

freut mich das es läuft.

Die MiniFAQ ist von Nomis3000 seiner GPIO-FAQ inspiriert. Nur das ich es bei
der Hardware noch etwas ausführlicher gezeichnet habe.

Gruß
Dino

 

[Markus]

Hmmm, darf ich zusammenfassen sagen, dass es jetzt funktioniert und wir nciht wissen warum?

Theorie ist, wenn man alles weiß und nichts klappt.
Praxis ist, wenn alles funktioniert und keiner weiß, warum.

Ich dachte das würde sich bisher nur auf Windows beschränken. Dass aber nun die AVR-Welt auch davon betroffen sein soll läßt micht bagen.

@Maik;könnte es sein, das erst bei dem Neuanlegen des Projekt der SourceCode wirklich für den neuen Prozessor nochmals sauber compiliert wurde und das deshalb die Programmroutine funktioniert hat.
Vieleicht wurde vorher ja immer nur ein Build aber kein Rebuild gemacht. Dabei wurden die Objektfiles übernommen und nur neu gelinkt und somit gab es doch Probleme mit der PIN/PORT-Verwechslung.

Grüße,
Ma

 

[Maik15]

Kann ich dir nicht genau sagen da deine Beschreibung meine Vorstellungskraft etwas übersteigt

Aber ich hatte noch die Datei
#include <stdint.h>
mit eingebunden und etwas mit Altem Code rumprobiert
Aber sbi und cbi wird nicht mehr unterstütz.
Aber um das raus zu bekommen hat auch gedauert.

Jetzt ist wieder alles rauskommentiert und es geht trotzdem.

gruß
Maik

 

[dino03]

Hallo,

ich hab mir jetzt auch mal den WinAVR installiert. Mal sehen ob ich auch mal
ein wenig C programmiere. Ich laß mich mal überraschen wie gut ich damit
zurecht komme

Gruß
Dino

 

[Maik15]

Was hab ich so einen Negativen Einfluss auf andere

gruß
Maik

 

[Markus]

@Maik; neeeee, ich glaube ichfach nur, dass auch Moderatoren ihre Herausforderungen brauchen ..... gell Dino :hello:

Und ihr wisst ja, für was C steht? C = "C"haos

Aber egal, ich habs auch viele viele Jahre auf digitalen Signalprozessoren betrieben

Grüße,
Markus

 

[dino03]

Hallo Maik,

ich muß sowieso demnächst zusätzlich ne Hochsprache einsetzen wegen
Berechnungen usw. Ich war nur am schwanken zwischen C und Bascom.
In Bascom kann man Assembler-Routinen einfacher einfügen. Darum wollte
ich normalerweise auch Bascom machen. Aber wer weiß ... evtl sogar
beides

Gruß
Dino

 

[Maik15]

Na dann viel spaß beim einarbeiten.

Willst noch ein paar C Tutorials haben.
Ich kann mich damit Tod werfen.

Aber was uint16_t ist finde ich trotzdem nicht raus.

Aber ich geh einfach mal davon aus das es nur die Abkürzung für unsigned int ist und umgehe so meine Unwissenheit.

gruß
Maik

 

[dino03]

Hi Maik,

Aber was uint16_t ist finde ich trotzdem nicht raus.

Aber ich geh einfach mal davon aus das es nur die Abkürzung für unsigned int ist und umgehe so meine Unwissenheit.

darf ich dir weiterhelfen ? ...
types.h File Reference
typedef unsigned short int uint16_t

Google hilft ...

Gruß
Dino

 

[Maik15]

Danke

Ich hab beim Google nix brauchbaren gefunden.
Und Wiki wusste auch nix.
Aber da war mein Bauchgefühl ja mal richtig.

gruß
Maik

 

[Dirk]

Hallo Maik,

Ich hab beim Google nix brauchbaren gefunden.
Und Wiki wusste auch nix.
Aber da war mein Bauchgefühl ja mal richtig.

schau dir mal stdint.h an (unten Zeile 7) ...


CodeBox C

typedef signed char int8_t;



typedef unsigned char uint8_t;



typedef signed int int16_t;



typedef unsigned int uint16_t;



typedef signed long int int32_t;



typedef unsigned long int uint32_t;



typedef signed long long int int64_t;



typedef unsigned long long int uint64_t;

dort stehen auch noch mehr Typendefinitionen.

Gruß,
Dirk