C++ macht den Atmega sicher nicht kaputtIch 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.
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
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.
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
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
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)
Das ist im Prinzip schon richtig.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.
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.
Berechtigungen
Zitieren
Lesezeichen