- Akku Tests und Balkonkraftwerk Speicher         
Ergebnis 1 bis 7 von 7

Thema: [NiboBee] ATmega32

  1. #1
    Neuer Benutzer Öfters hier
    Registriert seit
    27.12.2009
    Beiträge
    19

    [NiboBee] ATmega32

    Anzeige

    E-Bike
    Hi,
    da ich mal wieder eine größere Bestellung bei nem Online Elektronikhändler hatte hab ich mal einen ATmega32 mitbestellt. Den wollte ich heute in meine Biene einbauen. Hätte das funktioniert würde ich wahrscheinlich nicht hier schreiben...

    was habe ich gemacht?
    AVR Burn-O-Mat (GUI Frontend für avrdude) angeworfen, meine Biene angeschlossen und die FuseBits des alten ATmega16 ausgelesen. -> hfuse=D1; lfuse=EF

    Die Biene aus - den alten ATmega raus - den neuen rein. Spannung auf die Biene

    Fusebits mit AVR Burn-O-Mat auslesen und feststellen das sie anders gesetzt sind. Auf http://www.engbedded.com/fusecalc gegangen - und geschaut wie ich meine fusebits für den ATmega32 setzen müsste damit ich die gleichen Einstellungen habe. Rausgefunden das ich die gleichen Einstellungen gebrauche wie für den ATmega16 -> hfuse=D1; lfuse=EF

    Fusebits geschrieben. Avrdude meldet alles ok.

    Was funktioniert?
    Die mit der nibebeelib gelieferten Programme Programm1.hex, Programm2.hex, lassen sich mit avrdude aufspielen und die Programme lassen schön die LEDs der Biene blinken.

    Was funktioniert nicht?
    calibration.hex lässt sich übertragen sorgt aber für keine einzige Reaktion (LEDs sollten bei Fühlerbetätigung Sensoren auslesen und LEDs blinken lassen)
    Meine fertigen Projekte mit dem BGX1 lassen sich zwar aufspielen aber auch bei denen gibts keine einzige Reaktion weder von der Biene noch vom BGX1...

    habe ich was übersehen? Vermutlich... über Hilfe würde ich mich freuen.

  2. #2
    shedepe
    Gast
    Kompilier die Programme noch mal für einen Atmega32. Es kann gut sein, dass gewissen Speicheradressen beim Atmega32 anders sidn als bei Atmega16

  3. #3
    Neuer Benutzer Öfters hier
    Registriert seit
    27.12.2009
    Beiträge
    19
    Sorry, das habe ich vergessen zu erwähnen, aber ich hatte meine Projekte in Eclipse umgestellt auf ATmega32. Damit ich nicht irgend einen ominösen Schalter vergessen habe hab ich aber noch mal ein neues Projekt erstellt, und ein Minimalbeispiel zusammengestellt.
    Mein Beispiel schaut volgendermaßen aus:
    Code:
    	//nibobee standard
    #include <nibobee/iodefs.h>
    #include <nibobee/led.h>
    #include <nibobee/delay.h>
    #include <nibobee/line.h>
    #include <nibobee/motpwm.h>
    #include <nibobee/odometry.h>
    	//bgx1
    #include <nibobee/i2cmaster.h>
    #include <nibobee/bgx1.h>
    
    
    int main(){
    	led_init();
    	led_set(0, 1);
    
    		// initialisieren
    	i2c_init();
    	line_init();
    	motpwm_init();
    	odometry_init();
    	led_set(1, 1);
    //	while(!bgx1_init());
    	bgx1_init();
    	led_set(2, 1);
    
    	bgx1_termClear();
    	bgx1_termGoto(0,1);
    	bgx1_termPrint("hallo welt");
            led_set(3, 1);
    }
    Der code wird ohne Fehlermeldungen für den ATmega32 compiliert. Was sollte passieren?
    nachdem die LEDs initialisiert sind (die funktionieren ja immerhin schon mal) wird LED0 angesteuert. Nach dem initialisieren von I2C, Liniensensoren und Odometry wird LED1 angesteuert. Danach wird das Modul zur kommunikation mit dem gbx1 initialisiert und LED2 wird angesteuert. Danach wird dem gbx1 ein ``hallo welt`` per I2C gesendet und LED3 wird eingeschaltet.

    Was pasiert? LED0 und LED1 werden sauber angesteuert. Danach bleibt das Programm hängen. kommentiere ich den ``bgx1``-Teil aus läuft mein Programm durch (alle 4 LEDs leuchten)

    So wie es ausschaut sind die Routinen für das gbx1- Modul das Problem. Zu dumm nur das der Code dafür kein bisschen kommentiert ist, da habe ich nicht die geringste Lust drauf mich durchzuwühlen. Ich werde morgen erst mal versuchen die Quellen in mein Projekt mit einzubinden und komplett zu Kompilieren - ich glaube zwar nicht das mir das helfen wird, aber was anderes fällt mir momentan nicht ein.

    Weitere Vorschläge? So langsam bin ich ratlos...
    waschtl

  4. #4
    Neuer Benutzer Öfters hier
    Registriert seit
    27.12.2009
    Beiträge
    19
    Ok,
    ich habe mal Probeweise die C- Dateien und die Header aus der nibobeelib die für die Kommunikation sind in mein Projekt mit eingebunden und verwende nicht mehr die vor-kompilierten Versionen. Zusätzlich eingebunden habe ich nun:

    bgx1_protocol.h
    bgx1.h
    bgx1.c
    i2cmaster.h
    i2cmasternc

    kompilieren und binden unter Eclipse mit der AVR- Toolchain funktioniert so weit. Mein obiges Testprogramm wird anstandslos kompiliert und übertragen - läuft genau so weit wie gestern. Da mir nichts anderes eingefallen ist als den Code Stück für Stück nachzuvollziehen habe ich mich auf die Suche gemacht und mit den LEDs als Rückmeldung ein wenig getestet.
    Die Funktion``bgx1_init()`` läuft zumindest bis zu dem return- Statement durch. Bei dem Statement
    Code:
    return (i2c_status() == I2C_SUCCESS) && (HIBYTE(version) == HIBYTE(BGX1_VERSION));
    Hängt es sich auf. Unterteile ich den Code in 3 Schritte.
    Code:
      
      uint8_t var1 = i2c_status() == I2C_SUCCESS;
      uint8_t var2 = HIBYTE(version) == HIBYTE(BGX1_VERSION);
      return (var1 && var2)
    kommt er aus dem Schritt in dem die Versionen für das ``HIBYTE`` Verglichen werden sollen nicht mehr heraus. Das Makro dafür sieht folgendermaßena aus
    Code:
    #define HIBYTE(x)        (uint8_t)(((uint16_t)x)>>8)
    Allerdings hört hier mein Verständnis so langsam auf. Der Code ist in keinster Weise kommentiert, und meine Kenntnisse in C ist sind leider nicht mehr berauschend. Hinzu kommt das ich mich mit I2C nicht so weit auskenne das ich die Kommunikation selber programmieren könnte. Auch das nachvollziehen fällt mir nicht gerade leicht.
    Für mich sieht es so aus als ob die Kommunikation mit dem I2C nicht richtig initialisiert wird. Zumindest kann ich keine Kommunikation mehr auf den LEDs des bgx1- Moduls erkennen. Normalerweise ist das möglich.
    Auch die Datenblätter der beiden ATmega habe ich mal überflogen, aber die Register sehen mir ziemlich gleich aus. Habe ich evtl. etwas übersehen?

  5. #5
    Erfahrener Benutzer Fleißiges Mitglied
    Registriert seit
    22.05.2007
    Ort
    Stolberg
    Beiträge
    111
    Hallo waschtl,

    auch die Lib muss für den Ziel-Controller compiliert werden! Zur Zeit gibt es diese nur fertig-compiliert für:
    ATmega16 mit 15MHz (m16-15)
    ATmega644 mit 15MHz (m644-15)
    ATmega1284 mit 20MHz (m1284-20)

    Ich kann aber bei der nächsten Version die Libs für den ATmega32 miterzeugen...

  6. #6
    Erfahrener Benutzer Fleißiges Mitglied
    Registriert seit
    22.05.2007
    Ort
    Stolberg
    Beiträge
    111
    Ich sehe gerade, dass Du die Interrupts nicht aktiviert hast:
    Ruf mal die Funktion enable_interrupts() vor der Initialisierung des BGX1 auf...

  7. #7
    Neuer Benutzer Öfters hier
    Registriert seit
    27.12.2009
    Beiträge
    19
    Moin workwind,
    das ich nicht selber drauf gekommen bin das auszuprobieren. Ich meine mal gelesen zu haben, das der ATmega32 mit ATmega16 Code Benutzt werden kann. Die einfachen Standard-Programme haben dummerweise ja auch noch funktioniert.
    Sei es drum, ich habe die kompletten Quellen in mein Projektverzeichnis gepackt, die Header eingebunden, die Verweise auf die fertig compilierten libs rausgeworfen, und den Compiler mal machen lassen. Was soll ich sagen? Die Anbindung per I2C läuft. ``enable_interrupts()`` muss ich übrigens nicht extra aufrufen, ich vermute mal das das irgendwo beim Aufruf von ``bgx1_init()`` passiert falls notwendig.

    Allerdings muss ich mich wohl noch ein wenig einlesen in die Doku von Eclipse wie ich denn die libs erzeugen kann. Ich habe zwar kompilierte *.o -Dateien in meinem Release- Ordner, aber das sind nicht die Packete die ich gebrauche. Falls du die so nebenbei mal mit erzeugen könntest würde ich die natürlich auch nehmen

    Noch einmal ein dickes Danke für deine Hilfe
    waschtl

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •  

12V Akku bauen