July 26th, 2017

Externe Interrupts mit dem AVR leicht gemacht3

Die Unterschiede zwischen Polling und Interrupt sind in einem älteren Beitrag schon aufgelistet. Theorie findet man jedoch sehr oft. Hier findet ihr ein einfaches Beispiel wie man einen Taster per Interrupt eine Aktion ausüben lässt. Das Beispiel ist für einen AT90CAN128 mit folgender Hardwarekonfiguration:

  • - Taster an PORT E, PIN 7
  • - LED an PORT E, PIN 6

Beim Initialisieren aktiviert man die Interrupts und konfiguriert wann dieser ausgelöst werden soll:

//  Init Taster
DDRE  &= ~_BV(7);    // PORT E, PIN 7 als Eingang definieren

EIMSK |= _BV(INT7);  // Interrupt fuer Pin 7 aktivieren
EICRB |= _BV(ISC50); // steigende Flanke erzeugt einen INT
EICRB |= _BV(ISC51);

//  Init LED
DDRE  |= _BV(6);     // PORT E, PIN 6 als Ausgang definieren

sei();    //activate global interrups

In der ISR für Signal 7 kann dann eine Aktion erfolgen oder ein selbst erstelltes Flag (in einer Variablen) gesetzt werden.

//  ISR Taster
SIGNAL(SIG_INTERRUPT7)
{
  // LED an
  PORTE |= _BV(6);

  // entprellen
  delay_ms(100);
}

Die beiden Dateien stehen hier zur Verfügung.

Tags: , , ,


Beispiel CAN Bus Testapplikation für AT90CAN1289

at90can128 Ich habe es in letzter Zeit oft erlebt, dass sich angehende Mikrocontrollerprogrammierer mit dem AT90CAN beschäftigen wollen oder müssen um eine CAN Anwendung zu entwickeln. Dabei stößt man immer auf folgendes Problem: Man wird in den Wald geworfen und weiß nicht welchen Baum man zuerst studieren soll. Wenn man nach einfachen Testanwendungen sucht, dann findet man meist ausgeklügelte Bibliotheken oder Anwendungen wo man zunächst nicht durchsieht. Außerdem sind die meist viel zu umfangreich und können auch beide CAN 2.0 Standards. Diesem Problem mache ich heute ein Ende, hier folgt eine einfache Anwendung für den AT90CAN und eine kleine Einführung in die Software. Es sind alle Derivate des AT90CAN verwendbar (32, 64, 128), man muss selbstverständlich beim Kompilieren darauf achten den Richtigen einzustellen.

Beginnen wir mit der Struktur der Software:

- main.c Hauptdatei, Aufruf der Funktionen
- at90can.c Sourcedatei für CAN-Funktionen, inkl. ISR
- at90can.h Headerdatei für CAN, Definition der Struktur, Geschwindigkeiten
- utils.h Korrekte Definitionen für True/False und nützliche Dinge

Für die Variablen in denen CAN-Nachrichten gespeichert werden sollen wurde eine Struktur CAN_messageType erstellt. Die im Datenblatt empfohlenen Einstellungen für die Geschwindigkeiten sind in einem Feld (array) in der at90can.h hinterlegt. Die Applikation besteht nun darin, dass in der main-Funktion zunächst die Initialisierung aufgerufen wird und anschließend eine CAN-Botschaft testweise gesendet wird. Die Empfangenen Nachrichten werden nur in der globalen Variable recMsg abgespeichert, jedoch nicht weiter verarbeitet. Bei jeder Operation mit MObs muss die CANPAGE auf das entsprechende gesetzt werden.

Wichtig ist zunächst die korrekte Initialisierung. Der CAN-Controller muss zum konfigurieren in den config-mode versetzt werden um Geschwindigkeit und Interrupteinstellungen zu ändern. Die globalen Interrupts sollte man erst nach der Konfiguration aktivieren, denn sonst könnte mitten in der Konfiguration beim aktivieren der einzelnen Interrupts ein kommender die Konfiguration verfälschen. Zur Initialisierung des CAN-Controllers gehört das aktivieren des config-mode, die Einstellungen der Interrupts und das Setzen der Busgeschwindigkeit. Die Konfiguration der einzelnen MObs kann auch in gesonderten Funktionen erledigt werden.

Bei einem Empfang einer Nachricht wird in der entsprechenden Interrupt-Service-Routine (ISR) die CAN-Botschaft aus den Registern ausgelesen und in eine globale Variable gespeichert. Variablen die in einer ISR beschrieben werden sollen, müssen als volatile deklariert werden. Nach dem speichern der Daten muss der Interrupt durch readmodwrite resetet werden. Ebenso muss das Bit CONMOBn gesetzt werden, um erneut Empfangsbereitschaft zu signalisieren.

Zum Senden einer Nachricht werden die gewünschten Daten und ID in einer Variable gespeichert und die Funktion can_tx aufgerufen werden. Diese kopiert die Daten in die Register des Controllers und setzt das Bit CONMOBn des als Sender konfigurierten MOb.

Fragen, Anregungen oder Verbesserungsvorschläge können gerne als Kommentare erfolgen!

Tags: , , ,


CANlogger mit Temperaturmessung0

Vor einiger Zeit hatte ich das Konzept der Projektarbeit schon einmal vorgestellt. Nun wurde Version 1.0 fertig gestellt.

Features:

  • - Temperaturmessung mit Thermoelement und MAX6675
  • - ISP Stecker nach ATMEL Standard
  • - Schutz zum CAN durch DC-DC und Optokoppler
  • - CAN Stecker ist CAN-CiA konform
  • - Stromversorgung wählbar zwischen CAN und extern
  • - zusätzlich I²C EEPROM auflötbar für große Bilder
  • - Einstellmöglichkeit mit Drehgeber für CAN-Speed, ID und Filter
  • - Anzeige von empfangenen CAN-Nachrichten auf dem TFT
  • - 65k Farb-TFT mit 176×132 Pixel von display3000

Hier eine kleine Demo des Moduls:

Tags: , , , , ,


Projektarbeit, CANlogger mit Temperaturmessung9

Lange habe ich gewartet, aber nun soll es soweit sein. Ich hatte ja schonmal am Rande erwähnt, dass ich mit dem 2,1″TFT von display3000 einen Temperatur- und CANlogger bauen werde. Nun die versprochene Vorstellung der Idee und Hardware.

Es geht an sich nur um meine Projektarbeit im Rahmen des Diploms Fahrzeuginformatik. Das Projekt soll für mich gleichzeitig ein Vortest sein ob man Display und andere Elemente für eine MFA V2.0 für den Golf einsetzen könnte.

In dem Projekt geht es darum mit einem MAX6675 die Umgebungstermperatur über ein Thermoelement zu messen und durch den Controller (AT90CAN128) auf dem Display darzustellen und auf die CAN Schnittstelle zu senden. Gleichzeitig soll es möglich sein CAN-Nachrichten zu empfangen. Damit das Ganze etwas flexibel bleibt sollen auch Einstellungen möglich sein wie z.B. CAN ID, Temperatureinheit, Helligkeit des Displays, etc. Das wird von dem Modul selbst bewerkstelligt. Zu dem Projekt gehört außerdem eine Software, die auf einem PC mit Windows XP mit PCI-CAN-Karte von Peak System, laufen wird. Diese Software stellt die auf den CAN gesendete Temperatur dar und ermöglicht es dem Benutzer CAN-Nachrichten mit beliebiger ID (außer der, der Temperaturnachricht) zu versenden. Das Modul wird diese dann aufgrund der Logging-Funktionalität darstellen. Die CAN-Stecker sind in SUB-D 9 nach CiA DS102-1 ausgeführt.

Die Hardware und 30% der Firmware sind bereits fertig gestellt (13.11.2008, 01:23). Hier ein aktuelles Bild des Moduls:

Die fertige Platine hatte ich HIER schon einmal präsentiert. Des Weiteren ein kleiner Vorgeschmack aus meinem Konzeptbuch:

Tags: , , ,


Evaluationboard für AT90CAN TQFP641

Mit freundlicher Unterstützung von Mark C. konnte ich am Wochenende ein sehr praktisches Evaluationboard für den AT90CANxx aufbauen. Ursprünglich wollte ich einen Adapter für den Chip bauen um ihn auf mein Steckbrett stecken zu können, das erwies sich allerdings schnell als unhandlich.

Da der AT90CANxx einer der wenigen AVRs ist, die per PDI und PDO programmiert werden (siehe hier), ist das Board speziell für diesen TQFP64 AVR entwickelt. Wenn man diese Pininkompabilität ausmärzt kann man theoretisch jeden AVR damit betreiben. Jedoch muss er aufgrund der Bauform direkt aufgelötet werden.

Features:

ISP Programmierung, CAN treiber onboard, MAX208 onboard, zwischen 5,0V und 3,3V Betriebsspannung (AVR und Ports getrennt) wählbar, Betriebsspannungen an extra klemmen abgreifbar, an jedem Port-Wannenstecker Port-Betriebsspannung und GND verfügbar, RTS und CTS lines per Jumper trennbar, 2 RS232 Schnittstellen

Schaltplan evboard_tqfp64

Tags: , ,


Imhotep theme designed by Chris Lin. Proudly powered by Wordpress.
XHTML | CSS | RSS | Kommentare-RSS