Fragen zu Interrupt und AVRGCC & Atmega644

[stekohl]

Ich habe aktuell folgendes Problem.
Wie in einem anderem Thread beschrieben, versuche ich eine bestehende (fast fertige) Bascom Anwendung in C zu übernehmen.

Zugegeben als C Neuling keine leichte Aufgabe.
Nun habe ich folgendes schon hin bekommen:
a.) Holger Klabunde's SD LIB ( Mit leichten Änderungen für die ATMEGA644 Spezialitäten und viel Schweis mit falsch formatierten Karten) läuft.
b.) Eigene Lib für MCP23S17 (Porterweiterung 2 x 8 BIT, preiswert und wirklich universell, per SPI anzusteuern mit Interruptausgangje Port)
c.) SD-Karte und MCP an einem SPI BUS mit zwei verschiedenen CS.

Was mir noch fehlt ist die Interruptroutine.
Ich benötige den Interrupt, um damit ein Interruptereignis von einem MCP abzufangen. Den MCP23S17 habe ich so konfiguriert, dass bei Änderung eines Eingangs ein Int ausgelößt wird. Wird der Interrupt ausgelößt lese ich die beiden Ports auf dem Portexpander aus.
Die eigene Interruptroutine ließt also den Port aus und danach einen Datensatz von der SD Karte.


Ich will den INT2 nutzen. Der Interrupt soll ausgelößt werden wenn INT2 LOW ist.
Später soll dann INT0 oder INT2 noch genutzt werden, um ein paar Integerwerte im EEMEM zu sichern. Dieser Interrupt soll praktisch bei Netzausfall aktiv werden.
1.) Wie muß ich die Register setzten und welchen Registerflags muß ich setzten, damit der Interruptvektor auf meine ISR Routine aufläuft?
2.) Muß ich Register vorher sichern?

Wäre nett, wenn mir jemand auf die Sprünge helfen würde.

Ach ja, ich habe ein paar schöne Stunden verbracht mit folgendem Fehler.
Beim Senden der SPI Befehle habe ich die Adressen der Bausteine per ODER mit den Steuerflags verbunden.
Sah so aus:

• SPI_WRITE((addr <<1) || 0x40);

Wahrscheinlich muß ich niemandem sagen wie lange ich dafür gebraucht habe um zu merken, dass || kein bitweises ODER sondern eine Oderverknüpfung ganzer Variablen ist. Tja dumm gelaufen.
Nach ein paar Stunden und einer glorreichen Seite im C Buch (Übersicht aller Operatoren) habe ich dann per | (Bit-OR) alles ans laufen bekommen.

Ein Satz noch zum Thema C: Vom LED Blinker mal abgesehen, war bis jetzt in C die Entwicklungzeit mit gleichzeitigen "learning by doing" um mindestens Faktor 5 geringer als in Bascom. Gut, ich muß zugeben, zum Teil weiß ich jetzt wonach ich suchen muß. Für mich hat sich auf jeden Fall der Umstieg gelohnt. Gerade alle Bitoperationen und boolschen Variablenmanipulationen sind in C besser abzubilden.
Wollte damit nur alle "Wankelmütigen" einen kleinen Motivationsschub geben.

Gruß,

Stephan

[McJenso]

Hallo,

Ich will den INT2 nutzen. Der Interrupt soll ausgelößt werden wenn INT2 LOW ist.

Ich nehme jetzt mal an, du möchtest die fallende Flanke detektieren.

Wichtig ist erst einmal das Register EICRA(S.63). Hier wird festgelegt, bei welchem Zustand bzw. Zustandswechel der Interrupt ausgelöst wird (Tabelle S.64).
Jetzt noch den Interrupt für INT2 im EIMSK (S.64) freigeben.
Unter der Voraussetzung, dass du eh mit sei(), die Interrupts grundsätzlich erlaubst, war es das.
Die Seiten beziehen sich auf das Datenblatt. Bitte schau dir Passagen an.

Edit: Die Interruptfunktion für INT2 lautet ISR(INT2_vect){}
Die jeweiligen Vektoren findest du in der WIN-AVR Datei iomxx4.h


Gruß

Jens

[stekohl]

Danke McJenso für die Antwort.

Die Register habe ich gesetzt.

Habe aber meinen Fehler gefunden. Da ich ja eher in Pascal gearbeitet habe, ist mir Groß und Kleinschreibung ja eher Wurst.

Man sollte auch ISR(INT2_vect) schreiben, statt ISR(INT2_VECT).
Hatte mal irgentwo gelesen, man solle in C Variablen klein und Konstante groß schreiben. Na für mich war das eine Konstante.
Leider bin ich da natürlich von Delphi verwöhnt. Da mach man keinen Tippfehler ohne einen Schlag auf die Finger zu bekommen.
Werde in Zukunft mehr auf sowas achten, damit ich das Forum nicht mit blödsinns Fragen zumüllen.

Wenn ich für jeden dummen Tippfehler nen Euro bekommen würde, könnte ich mittlerweile Winterurlaub in St. Moritz machen.


Gruß,

Stephan

[thewulf00]

...war bis jetzt in C die Entwicklungzeit ... um mindestens Faktor 5 geringer als in Bascom.

Hey Stephan, das ist interessant zu hören, sagen doch die meisten Umsteiger das Gegenteil.
Ich persönlich habe mit ASM angefangen und bin dann auf C umgestiegen. In Bascom habe ich noch nie programmiert.

[stekohl]

Ich denke das Hauptproblem bei C ist die Struktur und der eigenwillige Syntax.
Also in meinem Fall ist es so, dass ich für bestimmte log. Operationen oder Abfrage in Bascom mehr Quelltext gebraucht habe.
Beispiel: Ich habe eine Adresse mit 3 Bit länge, die um 1 Bit links verschoben wird und dann per Oder mit HEX40 verknüft wird.
Habe in Bascom für jede Bitmanipulation eine Quelltextzeile benötigt, in C habe ich das so gelößt

• ((adr & 0x7)<<1) | 0x40 MCP_CS_OFF()

.
Ich finde die Operatoren, wenn man sie kennt, viel einfacher und eindeutiger in der Bedeutung und der Benutzung.

Ja sicher habe ich auch schon Stunden vor Syntaxfehler gehockt, die nur zur Laufzeit ihr "schädliches" Ich zeigten. Es wird einem mehr Struktur abverlang.
Andere Sprachen und Compiler helfen da doch etwas besser.

Jetzt aber noch ein Frage:
Ich habe am SPI Bus einmal die SD-Karte und den Portexpander.
Die SD Karte wird einfach nur per Widerstand an den MC angeschlossen und die Portexpander arbeiten sowieso mit 5 Volt.
Nun läuft das alles zwar getrennt, oder besser gesagt. Der 5 Volt Part ist ok, nur alles was mit 3,3 Volt Pegel läuft ist Mist.
Jetzt die Frage: Wenn ich den SD-Karten Pegel sauber wandle (mit Pegelwandler) kann ich dann damit rechnen, dass das alles zuverlässiger läuft?

Gruß,

Stephan

[thewulf00]

Wobei mein Kumpel sagt, dass er den C-Syntax viel zu umständlich findet, gerade, wenn man nur einen Pin setzen/ändern/löschen möchte.

BASCOM: Portb.2 = 1;

C: PORTB |= _BV(2);
oder
C: PORTB |= (1 << 2);
oder
C: PORTB |= 0b00000010

usw.

[stekohl]

Tja bei einer Manipulation mag das sein aber bei komplexeren Algorithmen finde ich es sehr übersichtlich, alles in eine Zeile packen zu können. Also für mich ist ein Verschieben um ein Bit nach Links per "x<<1" einfacher zu merken als "Shift X , Left , 1".


Ich will ja auch eigentlich keinen Grundsatzkrieg vom Zaun brechen, nur davon schreiben, daß für mich der Umstieg ein lohnende Sache ist.
Und wenn ich das schreibe heißt das, dass jemand der sich selbst vor obj. orientierter Programmierung jahrelang gewährt hat nun doch langsam in C einsteigt.
Ich halte Bascom für einen sehr leistungsfähigen Basic Compiler, der einen enormen Wortschatz und Funktionsumfang hat. Nun waren meine Projekte immer sehr übersichtlich und so hatte ich nie Probleme damit Aufgrund von Fehler den Quellcode entsprechend zu ändern.
Erst jetzt, wo ich das Ram und Flash ausnutzen will und auf versch. SPI Komponenten zugreife komm ich mit Bascom nicht weiter. Da selbst bei 16 MHZ Taktfrequenz langsam Latenzprobleme anfangen.

Kurzum, das ist der Wechselgrund für mich.

Viel mehr als von meinem in 1 1/2 Wochen angelesenen C Wissen kann ich auch nicht zum besten geben.
In der Windows Welt werde ich mit Sicherheit noch lange in Delphi arbeiten. Da habe ich mittlerweile gelernt, dass mein Wunsch nur noch in C zu arbeiten relativ optimistisch war.

Schluß mit meinem Gelaber.
Hat denn Jemand eine Idee zu meiner vorherigen Frage?
Also:
a.) Wie bau ich einen SPI-Bus auf, in dem 5V und 3,3 V Komponenten hängen? Reichen Pegelwandler? oder zusätzlich noch schaltbare Bustreiber?
b.) Wie lang dürfen die Leitungen sein? Könnten so in etwa 30 cm werden, ist das noch ok oder muß ich da schon einen vernünftigen Busabschluß machen? Busfrquenz so ca. 4-8MHZ

Gruß,

Stephan

[Viktor]

...also ich habe genau für diesen Zweck einen Levelshifter(MAX3378E) verwendet.
Ich habe auch am SPI Bus verschiedene IC "hängen", einen ATmega8, Touchscreendigitizer, und die SD Karte.

[wkrug]

Wobei mein Kumpel sagt, dass er den C-Syntax viel zu umständlich findet, gerade, wenn man nur einen Pin setzen/ändern/löschen möchte.

BASCOM: Portb.2 = 1;

C: PORTB |= _BV(2);
oder
C: PORTB |= (1 << 2);
oder
C: PORTB |= 0b00000010

In CodeVision AVR "C" gehts auch mit PORTB.2=1;
Es kommt also doch auch auf den Compiler an.

Wenn man sich an die etwas eigenwillige Syntax von C gewöhnt hat gehts damit wirklich flott.
Für mein letzten Stoppuhr Projekt hab ich für die Grundfunktion inklusive Displaymultiplexing gerade mal 3 Stunden für ein lauffähiges Programm gebraucht.
Das debuggen einer "C" DCF 77 Routine aus dem I-Net hat mich dann aber 6 Stunden gekostet!!
Ich hab wirklich manchmal den Eindruck, da werden Codes veröffentlicht, die noch nie real auf einem Controller gelaufen sind.
Die Einbindung von Assembler Code ist meiner Meinung nach in C auch einfacher als in BASCOM.

Ein Fehler, der mir immer wieder passiert ist der:
if (uc_i>3);
{
uc_a=2;
};

uc_a wird immer 2 warum wohl ??? - Aber der Compiler meckert nicht!

Persönliche Meinung an!:
Bascom ist so lange gut, wie man mit dem Befehlssatz auskommt.
Hat man eine Aufgabe die nicht unbedingt im Befehlssatz enthalten ist wird es schnell kompliziert.
Persönliche Meinung aus!

OK - Genug geschimpft, es geht hier ja eigentlich um ein ganz anderes Thema...