-         
Seite 1 von 2 12 LetzteLetzte
Ergebnis 1 bis 10 von 12

Thema: C++ Macht Atmega16 Kaputt?

  1. #1
    Erfahrener Benutzer Roboter-Spezialist
    Registriert seit
    22.09.2009
    Ort
    Geilenkirchen
    Beiträge
    419

    C++ Macht Atmega16 Kaputt?

    Anzeige

    Nabend!

    Ich habe ein sehr Seltsames Problem.
    Da ich demnächst mit dem CAN Bus arbeiten werde, wollte ich mir erstmal eine kleine Testschaltung aufbauen.
    Früher habe ich immer Atmegas in reinem C programmiert, dann bin ich auf ATxmegas und C++ umgestiegen.
    Da ich für die Testschaltung nicht extra eine Platine fertigen lassen möchte, habe ich einen ATmega16 verwendet, den ich per Fädeltechnik verdrahten kann.
    Ich habe das Programm nun in C++ geschrieben, damit ich später die Klassen, die zur Steuerung des CAN-Bus benötigt werden auch auf dem Xmega verwenden kann.

    Das Problem ist, wenn ich das Programm auf den Atmega spiele, lässt er sich im Anschluss nicht mehr programmieren.
    Bevor ich ein Programm aufspiele kann ich so oft ich will die Signatur auslesen, Fusebits auslesen oder auch Fusebits verändern.
    Nachdem ich ein Programm aufgespielt habe ist gar keine Kommunikation mehr möglich.
    Um dies zu erkennen mussten 3 Atmegas dran glauben

    Ich kann mir das nicht erklären, sowas ist mir bisher immer nur passiert, wenn ich fusebits falsch gesetzt habe, aber noch nie nur durch das Programm an sich.

    Danach habe ich probiert, ein Programm in C zu schreiben und es aufzuspielen, das funktioniert fehlerfrei.

    Warum gibt es also nur Probleme wenn ich das Programm in C++ schreibe?
    Auf github ist mein Programm hier zu finden:
    https://github.com/crabtack/CAN-Bus

    Ich kann mir das einfach nicht erklären?
    Hat jemand eine Idee, woran es liegen kann oder ein ähnliches Problem schon einmal gehabt?

    Ich verwende Atmel Studio 6.1 und den DIAMEX All AVR Programmer.

    mfg
    Olaf

  2. #2
    Erfahrener Benutzer Roboter-Spezialist Avatar von schorsch_76
    Registriert seit
    25.03.2012
    Ort
    Kurz vor Neuschwanstein
    Alter
    41
    Beiträge
    407
    C++ macht den Atmega sicher nicht kaputt Ich selbst nutze auf dem Atmega C++ und er steuert meine Heizung

    Das Problem liegt eher Richtung Fusebits/Takt/Quarz.
    Siehe bsp. https://www.roboternetz.de/community...hlight=Verfust

    Es ist auch möglich das deine IRQs so häufig auftreten, das der µC auf nichts mehr reagiert. Ich hatte so ein ähnliches Problem. Das IRQ Handling bei meinem I2C war nicht richtig und der IRQ hat alles lahm gelegt.

  3. #3
    Erfahrener Benutzer Roboter Genie
    Registriert seit
    02.11.2005
    Alter
    42
    Beiträge
    1.145
    Interessant wäre jetzt, die Unterschiede des C-Progamms und des C++-Programms zu sehen.

    Abgesehen davon - es macht nicht viel Sinn Klassen zu benutzen, wenn man keine Objekte erstellt... dann kann man auch bei C bleiben.

    Gruß,
    askazo
    - Das Leben ist zu kurz, um in C zu programmieren -

  4. #4
    Erfahrener Benutzer Robotik Einstein Avatar von wkrug
    Registriert seit
    17.08.2006
    Ort
    Dietfurt
    Beiträge
    1.935
    Hast Du noch andere Chips auf den Programmierpins MISO MOSI SCK angeschlossen?
    Ich hatte das Problem auch schon mal.
    Die Fusebits verstellten sich während des Programmiervorganges, weil der angeschlossene Chip Bits auf die Leitungen gegeben hat.
    Das hatte dann zur Folge, das sich immer wieder mal die Takteinstellungen geändert haben und der Controller somit keinen gültigen Takt mehr hatte.
    Dadurch war dann auch kein ISP mehr möglich.
    Mit externem Takt konnte ich die Fuses dann wieder umstellen.
    Nachdem der Reset Pin des angeschlossenen Chips per Pulldown Widerstand aktiviert wurde ( der externe Chip also abgeschaltet war), trat das Problem nie mehr auf.
    Absteckbare Jumper könnten auch ne Lösung sein.
    Poste doch bitte mal den Schaltplan deiner Entwicklung.

  5. #5
    Erfahrener Benutzer Roboter-Spezialist
    Registriert seit
    22.09.2009
    Ort
    Geilenkirchen
    Beiträge
    419
    Hi!
    Danke, für die Antworten!

    Ich denke, das wird das Problem sein.
    Ein Schaltplan ist nicht nötig (existiert auch nur in meinem Kopf), es ist einfach ein Atmega16 mit MSP2515 über SPI, Textdisplay, UART, Taster und Piezo mit Transistor, also nichts wildes.
    Habe einen MCP2515 über SPI dran.
    Da werde ich mal den Reset pin über nen Jumper auf Low legen, während des Programmierens.
    Kann das aber erst morgen ausprobieren, ich werde dann davon berichten.

    mfg
    Olaf

  6. #6
    Erfahrener Benutzer Roboter-Spezialist
    Registriert seit
    22.09.2009
    Ort
    Geilenkirchen
    Beiträge
    419
    Mahlzeit!

    Ich habe den Reset Pin vom MCP2515 per Jumper auf low gelegt, das brachte keine Besserung, selbst wenn ich das IC komplett entferne habe ich immer noch das gleiche Problem.
    Ich denke auch, dass es an den Fusebits liegt.
    Aber irgendwie muss man ja verhindern können, dass die gesetzt werden.
    Das ergibt einfach keinen Sinn, dass die gesetzt werden.

    Im Moment habe ich keine Anwendung für Objekte, da ich nur ein paar Funktionen zum Senden und Empfangen habe.
    Erst wenn das Projekt größer wird, brauche ich Objekte.
    Daher verwende ich C++.

    mfg
    Olaf

  7. #7
    Erfahrener Benutzer Roboter-Spezialist Avatar von schorsch_76
    Registriert seit
    25.03.2012
    Ort
    Kurz vor Neuschwanstein
    Alter
    41
    Beiträge
    407
    Wenn nichts anderes an den Pins hängt, wird es ziemlich sicher eine IRQ Geschichte sein die dir dann den Atmega lahm legt.

    mach einfach ein "Hello LED blink" Programm mit c++ und lass das laufen. Dann langsam schritt für Schritt die IRQ geschichte rein. Hier ist mit SPI/I2C wirklich ganz enorm wichtig das die Schritte zur Behandlung des IRQ richtig sind.

    Das mit dem IRQ: Auch wenn du keine Hardware am Pin drann hast, schiebt bei SPI das Schieberegister Daten "raus" und löst IRQs aus.
    Geändert von schorsch_76 (23.06.2015 um 08:00 Uhr)

  8. #8
    Erfahrener Benutzer Robotik Einstein Avatar von wkrug
    Registriert seit
    17.08.2006
    Ort
    Dietfurt
    Beiträge
    1.935
    Das mit dem IRQ: Auch wenn du keine Hardware am Pin drann hast, schiebt bei SPI das Schieberegister Daten "raus" und löst IRQs aus.
    Das ist im Prinzip schon richtig.
    Allerdings wird während des Programmierens mittels ISP der Reset Pin an GND gelegt, der Controller selber also Lahm gelegt.
    Nur wenn das nicht sicher klappt könnte da was reinspucken.

  9. #9
    Erfahrener Benutzer Roboter Genie
    Registriert seit
    22.06.2009
    Beiträge
    1.297
    Wie wäre es anstatt herum zuraten, wenn der Threadersteller endlich Programmcode + Schaltplan posten würde. Einen Schaltplan kann man ja auch aus der bestehenden Schaltung reverse engineeren und findet dabei oftmals auch selber noch den ein oder anderen Fehler.

    PS. Entschudigung. Habe erst jetzt gesehen dass der Programmcode auf github ist. Jedoch wäre Schaltplan und Fuse Konfiguration sowie das funktionierende C Programm doch interessant

  10. #10
    Erfahrener Benutzer Roboter-Spezialist
    Registriert seit
    22.09.2009
    Ort
    Geilenkirchen
    Beiträge
    419
    Nabend!


    Danke, für die Antworten

    Im Moment habe ich leider nicht so viel Zeit für das Projekt, da ich noch an einem anderem, wichtigerem Projekt arbeite (Werde ich vorstellen, wenn es fertig ist.).


    Ein Schaltplan ist wirklich nicht nötig, die Hardware ist mit Sicherheit in Ordnung.
    Ich bin mal dem Vorschlag nachgegangen, mit einem LED Blinken anzufangen und mich bis zum Interrupt hochzuarbeiten.
    Und es liegt wirklich am Interrupt....
    Dabei ist der Interrupt Teil nicht mehr als das hier:


    Code:
    void InterruptInit()
    {
        MCUCR |= (1 << ISC01); //Fallende Flanke an INT0
        GICR  |= (1 << INT0);
         
    }
    
    
    ISR(INT0_vect)
    {
        mcp2515::GetMessage(&receivedMessage);
        lcd_clrscr();
        lcd_putc(receivedMessage.data[0]);
        lcd_putc(receivedMessage.data[1]);
        lcd_putc(' ');
        lcd_putc(receivedMessage.lenght + 48); //Länge ausgeben
        
        UART::Transmit((uint8_t)(receivedMessage.ID >> 8));
        UART::Transmit((uint8_t)(receivedMessage.ID & 0x00FF));
        
        UART::Transmit(receivedMessage.lenght);
        UART::Transmit(receivedMessage.data[0]);
        UART::Transmit(receivedMessage.data[1]);
    }
    Abgesehen davon klappt übrigens Alles bestens, wenn ich anstelle vom Interrupt durch Polling abfrage.
    Dann kann ich eine Nachricht vom PC per UART senden, die wird dann an den mcp2515 gesendet, der sie (momentan noch im loopbackmode) wieder zurücksendet.
    Die Nachricht wird dann auf dem LCD angezeigt.
    Jetzt muss nur noch das Interrupt Problem gelöst werden und ich bin glücklich.

    EDIT:
    Habe den Interrupt Teil einfach nochmal neu geschrieben.
    Jetzt funktioniert alles Fehlerfrei, keine Ahnung wo jetzt genau der Fehler war, aber Hauptsache es läuft

    mfg
    Olaf
    Geändert von crabtack (28.06.2015 um 21:24 Uhr)

Seite 1 von 2 12 LetzteLetzte

Ähnliche Themen

  1. [ERLEDIGT] RP6 Kaputt ??
    Von Mr.Deepbass im Forum Robby RP6
    Antworten: 17
    Letzter Beitrag: 24.05.2012, 11:39
  2. LCD kaputt?
    Von skyscater im Forum Elektronik
    Antworten: 34
    Letzter Beitrag: 12.01.2012, 00:03
  3. [ERLEDIGT] RN-Control macht komische Piepstöne. - Kaputt??
    Von robonooby im Forum Schaltungen und Boards der Projektseite Mikrocontroller-Elektronik.de
    Antworten: 19
    Letzter Beitrag: 28.10.2011, 12:01
  4. Atmega16 macht nicht was er soll.....
    Von Pollin im Forum Assembler-Programmierung
    Antworten: 4
    Letzter Beitrag: 28.01.2007, 14:22
  5. mc kaputt?
    Von pat88 im Forum AVR Hardwarethemen
    Antworten: 2
    Letzter Beitrag: 28.03.2005, 14:45

Berechtigungen

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