C++ Macht Atmega16 Kaputt?

[crabtack]

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

[crabtack]

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

[schorsch_76]

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.

[wkrug]

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.

[shedepe]

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

[crabtack]

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:

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

[shedepe]

Kleiner Tipp. Zeit intensive Sachen wie LCD schreiben haben in einem Interrupt eigentlich ncihts zu suchen. Man legt sich damit den Controller nur Ewigkeiten lahm.