July 22nd, 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: , , ,


Einstellungen im EEPROM eines AVR speichern2

Es gibt kaum eine Anwendung in der man keine Einstellungen speichern möchte. Doch wenn man sich schon den Aufwand macht Einstellungen zu speichern, sollten diese nach dem Reset auch wieder abrufbar sein. Daher wird so etwas im EEPROM gespeichert und ausgelesen. Wie man das ganz sinnvoll programmieren kann folgt hier:

Am sinnvollsten überlegt man sich vorher was zu speichern ist, dann erstellt man gesondert dafür eine Sourcedatei mit deren Header. Im Header erfolgt die Definition der Benötigten Bytes:

#define EEPROM_SECTION  __attribute__ ((section (".eeprom")))

/*
** this global variables are stored in EEPROM
*/
uint16_t  dummy          EEPROM_SECTION  = 0;  // avoid using lowest addresses

//——————————————————————————
// section 1: default settings
uint8_t   eeprom_def_brightness EEPROM_SECTION  = 1;  // EEPROM address 0002
uint16_t  eeprom_def_TempID     EEPROM_SECTION  = 2;  // EEPROM address 0003
uint8_t   eeprom_def_TempUnit   EEPROM_SECTION  = 3;  // EEPROM address 0005
uint16_t  eeprom_def_Filter     EEPROM_SECTION  = 4;  // EEPROM address 0006
uint8_t   eeprom_def_CANspeed   EEPROM_SECTION  = 5;  // EEPROM address 0008

// placeholder
uint16_t  eeprom_def_dummy1     EEPROM_SECTION  = 6;  // EEPROM address 0009
uint16_t  eeprom_def_dummy2     EEPROM_SECTION  = 7;  // EEPROM address 000B
uint8_t   eeprom_def_dummy3     EEPROM_SECTION  = 8;  // EEPROM address 000D
uint8_t   eeprom_def_dummy4     EEPROM_SECTION  = 9;  // EEPROM address 000E
uint8_t   eeprom_def_dummy5     EEPROM_SECTION  = 10; // EEPROM address 000F

//——————————————————————————
// section 2: user settings
uint8_t   eeprom_usr_brightness EEPROM_SECTION  = 11;  // EEPROM address 0010
uint16_t  eeprom_usr_TempID     EEPROM_SECTION  = 12;  // EEPROM address 0011
uint8_t   eeprom_usr_TempUnit   EEPROM_SECTION  = 13;  // EEPROM address 0013
uint16_t  eeprom_usr_Filter     EEPROM_SECTION  = 14;  // EEPROM address 0014
uint8_t   eeprom_usr_CANspeed   EEPROM_SECTION  = 15;  // EEPROM address 0016

// placeholder
uint16_t  eeprom_usr_dummy11    EEPROM_SECTION  = 16;  // EEPROM address 0017
uint16_t  eeprom_usr_dummy12    EEPROM_SECTION  = 17;  // EEPROM address 0019
uint8_t   eeprom_usr_dummy13    EEPROM_SECTION  = 18;  // EEPROM address 001B
uint8_t   eeprom_usr_dummy14    EEPROM_SECTION  = 19;  // EEPROM address 001C
uint8_t   eeprom_usr_dummy15    EEPROM_SECTION  = 20;  // EEPROM address 001D

Anschließend werden in der Sourcedatei die entsprechend der Reservierung benötigten Funktionen erstellt um die Werte zu lesen/schreiben.

#include <stdbool.h>
#include <stdint.h>
#include <avr/io.h>
#include <avr/eeprom.h>
#include "eeprom_access.h"

// returns the dataset from eeprom
uint16_t get_eeprom_word(uint8_t setting)
{
  uint16_t   eeprom_word;

  switch (setting)
  {
    case 12:
      eeprom_word = eeprom_read_word( &eeprom_usr_TempID );
      break;
    case 14:
      eeprom_word = eeprom_read_word( &eeprom_usr_Filter );
      break;
    default:
      break;
  }
  return eeprom_word;
}

// save data to eeprom
void set_eeprom_word( uint16_t eeprom_word, uint8_t setting )
{
  switch (setting)
  {
    case 12:
      eeprom_write_word( &eeprom_usr_TempID, eeprom_word );
        break;
    case 14:
      eeprom_write_word( &eeprom_usr_Filter, eeprom_word );
        break;
    default:
      break;
  }
}

// returns the dataset from eeprom
uint8_t get_eeprom_byte(uint8_t setting)
{
  uint8_t   eeprom_byte;

  switch (setting)
  {
    case 15:
      eeprom_byte = eeprom_read_byte( &eeprom_usr_CANspeed );
        break;
    default:
      break;
  }

  return eeprom_byte;
}

// save data to eeprom
void set_eeprom_byte( uint8_t eeprom_byte, uint8_t setting )
{
  switch (setting)
  {
    case 15:
      eeprom_write_byte( &eeprom_usr_CANspeed, eeprom_byte );
        break;
    default:
      break;
  }
}

In der main-Datei (oder wo man die Funktion aufrufen möchte) muss anschließend definiert werden wie die Einstellungen heißen und die externen Funktionen deklariert werden.

//——–
// EEPROM
//——–
// settings
#define CAN_Speed 15
#define CAN_Filter 14
#define Temp_ID 12

extern void set_eeprom_byte( uint8_t eeprom_byte, uint8_t setting );
extern uint8_t get_eeprom_byte(uint8_t setting);
extern void set_eeprom_word( uint16_t eeprom_word, uint8_t setting );
extern uint16_t get_eeprom_word(uint8_t setting);

Der Aufruf aus der main-Datei könnte dann wie folgt aussehen:

CANspeed = get_eeprom_byte(CAN_Speed);

set_eeprom_byte(CANspeed, CAN_Speed);

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: , , , , ,


Inkrementalgeber Auswertung6

Die Zeit der Taster oder sogar Bedienkreuze ist schon lange vorbei. IMG_5950Seit vielen Jahren werden in Radios, Navis, Handys,etc. so genannte Inkrementalgeber (encoder) eingesetzt. Mit Knopf oder ohne (Taste). Immer öfter werden diese kleinen Dinger auch im Hobbybereich interessant und verwendet. Die Ansteuerung in der Firmware ist zwar recht einfach, jedoch möchte ich euch den Weg erleichtern, so dass keiner das Rad zweimal erfinden muss.

Es ist empfehlenswert die im Datenblatt angegebene Beschaltung mit Entprellung und Strombegrenzung aufzubauen, falls keine vorhanden ist: 10k gegen Vcc, 10k zum µC-Pin und 100nF gegen GND. Die Abfrage gestaltet sich per Interrupt am sinnvollsten, denn wenn man den Flankenwechsel detektiert hat sollte sofort der Level des anderen Signals abgefragt werden. Meist bekommt man vom Hersteller nur so ein winziges Diagramm:

phase_diag

Es ist ja schon aussagekräftig, allerdings dauert es ein paar Minuten bis man mit der richtigen Sichtweise darauf schaut. Es gibt vier Fälle, je zwei pro Drehrichtung. Man lässt Signal A per Levelchange Interrupt Triggern und fragt danach Signal B ab. Hier ein Beispiel: Signal A steigende Flanke. Wenn dann Signal B low ist, dann war es eine ClockWise Rotation. (Zeitpunkt zwischen T2 und T3, C.W.) Hier die ISR:

code_a Immer daran denken: Variablen auf die in der ISR zugegriffen werden soll als volatile deklarieren!

Tags: , ,


CAN Spezifikation2

Mit der Zeit kommen bei mir so die Projekte zusammen, in letzter Zeit gehäuft mit CAN. Temperatureinheit, Grafikeinheit, CANtoRS232 oder Mainboard für den Jugend forscht Truck. Aktuellestes Projekt ist ein CAN-/Temperaturlogger.

Gerne greift man später mal in den Schrank und möchte ein Modul mit einem Anderen zu Testzwecken verbinden. Damit das möglich ist, müssen alle mindestens eine bestimmte CAN-Baudratenkonfiguration unterstützen die bei allen gleich ist. Mehrere Geschwindigkeiten sind natürlich möglich, aber prinzipiell nicht erforderlich. Um das zu gewährleisten, damit man in 3 Jahren nicht ein Modul nur deswegen neu flashen muss habe ich eine CAN-Spezifikation definiert. Sie ist in erster Linie für mich, jedoch möchte ich sie euch nicht vorenthalten. Man muss ja nicht jedes Rad neu erfinden.

can_spezifikation

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: , , ,


Zweiter Test des 2,1″TFT0

Wiedereinmal muss ich euch mit dem Display nerven. Aber ihr werden sehen..es hat seinen Grund!

Ich habe nach dem erfolgreichen Test1 mit Linien nun eine Vollgrafik in den Controller geladen und dargestellt. Das Ergebnis ist….ja, mir fehlen die Worte! Einfach unglaublich, seht selbst!

Nochwas: Es steht nicht umsonst in dem Programmierhandbuch, man solle es unbedingt komplett lesen bevor man anfängt. Der Grafikkonverter ist zwar sehr hilfreich, aber die Ausgabe dessen muss hinterher angepasst werden!

Tags: , , ,


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