Grüß euch! Ich stehe hier vor einem, etwas verwirrenden, Problem. Ich hab hier mehrer Controller vom Typ Mega88PA. Wenn ich nun die selbe Software auf unterschiedliche Controller (vom selben Typ natürlich) brenne bekomme ich unterschiedliche Verhalten oO! Ein Mal wacht er nicht mehr auf, das andere Mal funktioniert eine Berechnung nicht oder die zweite PWM geht nIcht mehr. Das ist doch sehr verwirrend für mich. Woran kann das liegen? Weiß nicht ob es wichtig ist aber ich compiliere mit -0S. Lg
Ist dein Programm vom intenen Takt abhängig? Wenn du Code postest, ist es für alle einfacher, dein Problem zu lösen.
Kk schrieb: > Wenn ich nun die selbe Software auf unterschiedliche Controller (vom > selben Typ natürlich) brenne bekomme ich unterschiedliche Verhalten oO! Dann bekommen deine µCs wohl unterschiedliche Eingangssignale.
Wahrscheinlich unterschiedliche Schaltungen... Oder Schwankungen in der Spannungsversorgung... Oder ein Programmfehler... Oder kaputte uCs... Oder..... Oder.. Kk schrieb: > Weiß nicht ob es wichtig ist aber ich compiliere mit -0S. Ein Operating System braucht doch sowieso jeder PC. BTW: welchen Compiler verwendest du?
Geist schrieb: > Wenn du Code postest, ist > es für alle einfacher, dein Problem zu lösen. Wurde nun beigefügt. µC-Bastler schrieb: > Kk schrieb: > Dann bekommen deine µCs wohl unterschiedliche Eingangssignale. Nicht das ich wüsste. MitLeser schrieb: > vielleicht unterschiedliche Fuses ? Sollten die selben sein. Das einzige was an den Fuses verändert wurde war die CKDIV, mit er mit den vollen 8Mhz läuft. Die hab ich bei allen anderen µCs auch dementsprechend gesetzt. 42er schrieb: > Schon der erste Osterwochened-Rätsel-Thread ... Sry, sollte eig. kein Rätsel-Thread werden :(. Aber ich wollte die Sache sehr allgemein halten. Anscheinend, kann nicht so allgemein auf das Problem geschlossen werden. @Lothar: Nein die äußeren Bedingung sind alle gleich. Es wird lediglich der Prozessor getauscht. Lothar Miller schrieb: > Ein Operating System braucht doch sowieso jeder PC. > BTW: welchen Compiler verwendest du? Also mit -0S meinte ich die Optimierungsstufe. Die ist auf -0S eingestellt. IDE verwende ich AVR Studio 4 und den GCC Compiler. Lg
kk schrieb: > Also mit -0S meinte ich die Optimierungsstufe. Die ist auf -0S > eingestellt. Und die gibts halt nicht. Aber es gäbe -Os.
Zu hohe oder zu niedrige Spannung? Starke Störungen auf der Versorgunsleitung? Fehlende Abblock-Kondensatoren? Fehlende RESET-Beschaltung? Nicht alle Versorgungsleitungen korrekt beschaltet? > Also mit -0S meinte ich die Optimierungsstufe. Die ist auf -0S > eingestellt. Optimierung schaltet man mit -O, nicht mit -0 ein. Und eine Optimierungsstufe S gibt es auch nicht. Es gäbe höchstens s. Keine Ahnung, was passiert, wenn man -0S angibt...
> Optimierung schaltet man mit -O, nicht mit -0 ein. Und eine > Optimierungsstufe S gibt es auch nicht. Es gäbe höchstens s. > Keine Ahnung, was passiert, wenn man -0S angibt... Ok, tut mir Leid. Dann also -Os. Hab das aus dem Kopf geschrieben^^. Rolf Magnus schrieb: > Zu hohe oder zu niedrige Spannung? Starke Störungen auf der > Versorgunsleitung? Fehlende Abblock-Kondensatoren? Fehlende > RESET-Beschaltung? Nicht alle Versorgungsleitungen korrekt beschaltet? Wie gesagt. Es wird nur der Prozessor getauscht (Sockel zum wechseln). Also denk ich mir das die äußeren Bedingung die Selben sind. Lg
Hi >Wie gesagt. Es wird nur der Prozessor getauscht (Sockel zum wechseln). >Also denk ich mir das die äußeren Bedingung die Selben sind. Dann überprüfe mal, ob du wirklich das gleiche Programm geflasht hast. MfG Spess
kk schrieb: > Also denk ich mir das die äußeren Bedingung die Selben sind. Das mag ja sein, daß die immer die selben sind, aber wenn die außerhalb der Spezifikationen liegen, kann es durchaus passieren, daß die einzelnen Prozessoren aufgrund von Fertigungstoleranzen unterschiedlich darauf reagieren. Es gibt da eigentlich nur zwei Möglichkeiten: Entweder die Umgebunsbedingungen passen nicht, oder deine Prozessoren sind alle kaputt.
Rolf Magnus schrieb: > Es gibt da eigentlich nur zwei Möglichkeiten: Entweder die > Umgebunsbedingungen passen nicht, oder deine Prozessoren sind alle > kaputt. Also wenn das wirklich alle Möglichkeiten sind, dann bin ich etwas verwirrt.... Ich bilde mir so etwas doch nicht ein^^. Nächste Woche kann ich der Sache noch ein Mal genauer auf den Grund gehen. Danke für eure Hinweise. Ich dachte, dass das ev. mit der Optimierungsstufe zusammenhängt. Ist eig. ungeschickt wenn ich mit -Os komiliere. Also welche Vorteile würde mir eine Optimierung bringen? Danke für eure Hinweise.
kk schrieb: > Rolf Magnus schrieb: >> Es gibt da eigentlich nur zwei Möglichkeiten: Entweder die >> Umgebunsbedingungen passen nicht, oder deine Prozessoren sind alle >> kaputt. > > Also wenn das wirklich alle Möglichkeiten sind, dann bin ich etwas > verwirrt.... Es könnte höchstens noch ein defekter Programmer sein, der jedesmal ein paar Bytes fehlerhaft in den Prozessor schreibt, bzw. Versorgungsspannungs-Probleme während des Programmiervorgangs. Also bist du dir absolut 100% sicher, daß alle Sachen, die bisher im Thread genannt wurden, definitiv korrekt sind? > Ich dachte, dass das ev. mit der Optimierungsstufe zusammenhängt. Dann würde der Fehler aber nicht vom Prozessor abhängen. Die einzelnen Prozessoren können nicht unterschliedlich auf einen Fehler durch Optimierungen reagieren, schließlich ist es ja überall das gleiche Programm. > Ist eig. ungeschickt wenn ich mit -Os komiliere. Nö, warum sollte es? Es ist sogar die empfohlene Einstellung. > Also welche Vorteile würde mir eine Optimierung bringen? Daß der Code kleiner und schneller ist als ohne.
Rolf Magnus schrieb: > Es könnte höchstens noch ein defekter Programmer sein, der jedesmal ein > paar Bytes fehlerhaft in den Prozessor schreibt, bzw. > Versorgungsspannungs-Probleme während des Programmiervorgangs. Ich verwende das STK500 als Programmer. Wie kann ich denn sicherstellen, dass das Programm richtig übertragen wurden? Hilft es die Option "Verify" zu verwenden? Obwohl ich mir fast nicht vorstellen kann, das da ein Fehler vorliegt. > Also bist du dir absolut 100% sicher, daß alle Sachen, die bisher im > Thread genannt wurden, definitiv korrekt sind? Naja, 100% ist relativ :D! Was genau meinst du? Ich beschreib es noch ein mal kurz. Ich hab eine Schaltung vor mir die den dementsprechenden Sockel hat. Dann wird der erste Controller geflashed und auf den Sockel gesteckt und geschaut ob es funktioniert. Wenn es nicht funktioniert lass ich den Controller meistens noch weiter in der Schaltung um zu sehen wie er sich verhält. Also such ich den Bug, wenn ich ihn gefunden hab nimm ich einen zweiten Controller, vom gleichen Typ, flashe den und steck diesen dann auf den Sockel. Nun geht aber ein anderer Teil des Programmes nicht der mit dem 1. Controller aber wunderbar funktioniert hat. Deswegen bin ich so verwirrt^^. Rolf Magnus schrieb: > Nö, warum sollte es? Es ist sogar die empfohlene Einstellung. >> Also welche Vorteile würde mir eine Optimierung bringen? > Daß der Code kleiner und schneller ist als ohne. Uppps. Ich befürchte ich hab dann doch -O0 verwendet. Micht hat die Aussage "ist die empfohle Einstellung" etwas stutzig gemacht, da ich wusste das ich eine andere Verwende :D! Sry für die Verwirrung. Lg
kk schrieb: > Ich verwende das STK500 als Programmer. Wie kann ich denn sicherstellen, > dass das Programm richtig übertragen wurden? Hilft es die Option > "Verify" zu verwenden? Ja. Genau dazu ist sie da. >> Also bist du dir absolut 100% sicher, daß alle Sachen, die bisher im >> Thread genannt wurden, definitiv korrekt sind? > > Naja, 100% ist relativ :D! > Was genau meinst du? > Ich beschreib es noch ein mal kurz. Ich hab eine Schaltung vor mir die > den dementsprechenden Sockel hat. Die Frage war jetzt, ob diese Schaltung korrekt aufgebaut ist.
Hi!
1 | OSCCAL = 0x5F; // Manually adjusting the Internal Oscialator |
Damit überschreibst du die interne Kalibrierung des RC-Oszillators. Jeder µC läuft dann mit einer anderen Geschwindigkeit - eventuell auch übertaktet. http://www.atmel.com/Images/doc8161.pdf Seite 37 Noch ein Tipp:
1 | DDRB |= (1 << PB1) | (1 << PB2)| (1 << PB3) | (1 << PB4); // ... |
2 | ...
|
Beim ersten Beschreiben der Register solltest du nicht mit "oder" verknüpfen sondern direkt beschreiben. Das verhindert den beliebten Fehler, eine init() Funktion während des Programms nochmals aufzurufen und sich zu wundern, warum die Register danach nicht korrekt eingestellt sind. Besser:
1 | DDRB = (1 << PB1) | (1 << PB2)| (1 << PB3) | (1 << PB4); // ... |
2 | ...
|
Noch ein Tipp (Geschmackssache): Wenn du defines wie Full_Hour komplett groß schreibst, also FULL_HOUR, ist beim Überfliegen des Codes sofort ersichtlich, dass es sich um ein define und keine Variable handelt. Ansonsten: Schön formatiert und gute Variablennamen gewählt!
kk schrieb: > Also such ich den Bug, wenn ich ihn gefunden hab nimm ich einen zweiten > Controller, vom gleichen Typ, flashe den und steck diesen dann auf den > Sockel. Nun geht aber ein anderer Teil des Programmes nicht der mit dem > 1. Controller aber wunderbar funktioniert hat. Versuch doch mal den Controller der in der Schaltung war mit dem Programm mit behobenen Fehler zu beschreiben. Kanns sein dass du beim Fehler ausbessern einen anderen Programmteil beeinflusst/zerschießt?
Hm, jetzt wo Thomas es sagt, klingt das: kk schrieb: > Also such ich den Bug, wenn ich ihn gefunden hab nimm ich einen zweiten > Controller, vom gleichen Typ, flashe den und steck diesen dann auf den > Sockel. Nun geht aber ein anderer Teil des Programmes nicht der mit dem > 1. Controller aber wunderbar funktioniert hat. als würde doch nicht, wie im ersten Posting behauptet, das selbe Programm auf allen Controllern probiert, sondern immer ein anderes. Da wäre es natürlich sehr wichtig, was nun tatsächlich der Fall ist.
Wow, hier ging ja was weiter. Sry, war bei Bekannten. Ostern unso :)! Danke für die viele Vorschläge! Schaltung werde ich nachliefern. Stefan Zimmermann schrieb: > Damit überschreibst du die interne Kalibrierung des RC-Oszillators. Hey! Ja, dass wollte ich auch so. Da ich die Zeit messe hab ich den Oszillator versucht anzupassen. Die sind alle ein wenig unterschiedlich. Ich muss 55 Sekunden messen. Jedenfalls stoppe ich die Zeit mit und wenn er vor oder nach 55 Sekunden die LED blinkt, dann korrigiere ich dementsprechend. Da ich mir die Zeit für 55 Sekunden und 8MHz ausgerechnet und die 55 Sekunden dann so gut wie möglich einstelle, hab ich mir gedacht, dass ich dadurch Nahe an 8MHz liege. Wenn du verstehst was ich meine^^. Deine anderen Verbesserungsvorschlag hab ich einfließen lassen. Stefan Zimmermann schrieb: > Schön formatiert und gute Variablennamen gewählt! Danke. Stefan Zimmermann schrieb: > Wie hoch ist die Betriebsspannung? 5V Stefan Zimmermann schrieb: > Noch ein Tipp (Geschmackssache): Hast natürlich recht. @letzten beiden Post: Da könnt ihr natürlich auch recht haben. Ich hoffe das ich mir das Morgen oder Übermorgen wieder genauer anschauen kann. lg
kk schrieb: > Hey! Ja, dass wollte ich auch so. Da ich die Zeit messe hab ich den > Oszillator versucht anzupassen. Die sind alle ein wenig unterschiedlich. > Ich muss 55 Sekunden messen. Jedenfalls stoppe ich die Zeit mit und wenn > er vor oder nach 55 Sekunden die LED blinkt, dann korrigiere ich > dementsprechend. Da ich mir die Zeit für 55 Sekunden und 8MHz > ausgerechnet und die 55 Sekunden dann so gut wie möglich einstelle, hab > ich mir gedacht, dass ich dadurch Nahe an 8MHz liege. Wenn du verstehst > was ich meine^^. Ja, das verstehe ich. Allerdings musst du das für jeden Controller (also jeden einzelnen IC) extra machen. In der Fertigung haben die Controller Toleranzen. Bei dir würde der Ablauf so aussehen: Der Controller lässt eine LED für 55 Sekunden leuchten. Da sein interner Oszillator nicht genau ist, werden es wahrscheinlich nicht genau 55 Sekunden sein. Du misst also die Zeit mit ner Stoppuhr. Je nachdem, ob die Zeit zu lang oder zu kurz ist, musst du OSCCAL für diesen Controller verkleinern oder vergrößern. Das musst du bei jedem Controller machen. Das ganze gilt aber nur, wenn das unterschiedliche Verhalten in deinem Controller auch mit einem ungenauen Oszillator zusammen hängt.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.