• 28.04.2024, 18:52
  • Registrieren
  • Anmelden

  • Sie sind nicht angemeldet.

 

Wieder einmal ein (noob)-Problem... (Attiny13 / GCC) *gelöst*

Freakmaster

Senior Member

Beiträge: 1 791

Wieder einmal ein (noob)-Problem... (Attiny13 / GCC) *gelöst*

Donnerstag, 27. August 2009, 14:32

Tach zusammen!

Ich hab da leider wieder einmal ein (noob)-Problem:

Hier erstmal der Schaltplan
Zur Erklärung:

SJ1 (Lötbrücke) ist geschlossen und der Reset-Pin ist per Fusebit als I/O definiert.

Über die 3 DIP-Switches kann ich einen Mode von 0-7 einstellen (Wertigkeiten 1/2/4).
Wenn an "Bremskontakt" 12V anliegen blinkt eine LED die an "Bremslicht" angeschlossen ist, entsprechend der eingestellten Modis mit unterschiedlichen Frequenzen.
Soweit funktioniert alles problemlos.

Wenn ich nur an "Race-Mode" meine 12V anlege wird der Mode "8" aktiviert und die LED blinkt mit 1Hz. <- funktioniert auch soweit
Hier das Problem:
Wenn der Race-Mode aktiviert ist und an "Bremskontakt" 12V angelegt werden (Im Prinzip nur eine Brücke zwischen "Bremskontakt" und "Race-Mode") soll die Blinkfrequenz von 1Hz auf 3Hz umgeschalten werden. Teilweise funktioniert das ganze problemlos.
Leider hängt sich der Controller meistens beim Umschalten auf und lässt entweder die LED aktiviert oder schaltet sie einfach aus.
Der Controller "erhohlt" sich auch im Normalfall nicht mehr sondern es muss die Versorgungsspannung getrennt werden.

Den Watchdog habe ich auch schonmal aktiviert und an einer Stelle reseten lassen an die der Controller nur gelangt, wenn das Programm sauber läuft.

Codeschnipsel (GCC) könnte ich erst heute Abend liefern. Aber im Grunde schaut die main so aus:

Quellcode

 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

while ( 1 )
{
	get_mode();
	
	if ( race_mode )
	{
		if ( active )
		{
		[blink_mit_3_hz]
		}
		else
		{
		[blink_mit_1_hz]
		}
	}
	else
	{
	[blink_mit_eingestelltem_mode]
	}
}


"get_mode" liest die 3 DIP-Schalter aus
"active" und "race_mode" fragen über die "standard-entprellfunktion" aus dem GCC-Tutorial von mikrocontroller.net die Pins ab.

Jemand nen zündenden Hinweis?

Dieser Beitrag wurde bereits 3 mal editiert, zuletzt von »Freakmaster« (27. August 2009, 18:58)

Da steht nix :-P

Freakmaster

Senior Member

Beiträge: 1 791

Donnerstag, 27. August 2009, 17:44

GNARF -.-

Fehler gefunden...
Wenn man zum "passenden" Zeitpunkt den Taster betätigt hat ist mein Zähler für die Blinkfrequenz über die entsprechenden Abfragewerte hinaus hochgezählt worden und siehe da die LED ist so lange an oder aus geblieben, bis die integer-Variable "übergelaufen" ist...

Der Watchdog-reset war natürlich doch nicht an der 100% richtigen Stelle platziert...
Da steht nix :-P

LotadaC

God

Beiträge: 2 345

Donnerstag, 27. August 2009, 19:56

könntest Du Dir das Blinken nicht vereinfachen, indem Du Timer0 als PWM verwendest? Der Kleine hat doch sowas, oder? (Ich hab mir jetzt das DB nicht angesehen, aber PB0/PB1 läßt doch mit OutputCompare0A bzw B darauf schliessen. Dann brauchst Du Dich um die Überläufe nicht mehr zu kümmern, sondern mußt nur noch den PWM-Wert in dem entsprechenden Register (->Datenblatt) verändern. (oder ist der Timer trotz aller prescaler zu schnell?)

Edit: *Klammer zu*

Freakmaster

Senior Member

Beiträge: 1 791

Donnerstag, 27. August 2009, 22:17

Beim Tiny13 kann der Timer0 für PWM genutzt werden ja - Ich habe mir allerdings die Möglichkeiten die man damit hat ehrlich gesagt nicht angeschaut.

Ich lasse derzeit einfach den Timer im "Timer Overflow Interrupt" laufen und zähle die Interrupts.
Somit kann ich hald auch problemlos 3 sec verstreichen lassen...

Aber der Code ist ja schließlich noch nicht endgültig fertig, da man da bestimmt noch vieeeeeeeeeeeeeeeel optimieren kann...
Da steht nix :-P

LotadaC

God

Beiträge: 2 345

Donnerstag, 27. August 2009, 23:33

ok... dachte halt nur, daß die PWM komplett im Hintergrund (unabhängig vom Programm) läuft - die Timer-Überlauf-ISR unterbricht ja quasi jedesmal das Programm (und verschluckt ggf irgendwelche Ereignisse)

Edit:

Zitat von »Freakmaster«

SJ1 (Lötbrücke) ist geschlossen und der Reset-Pin ist per Fusebit als I/O definiert


Zitat von »Freakmaster«

Aber der Code ist ja schließlich noch nicht endgültig fertig, da man da bestimmt noch vieeeeeeeeeeeeeeeel optimieren kann...


Programmierst Du den dann jedesmal "high voltage", oder wie?

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »LotadaC« (27. August 2009, 23:40)

Freakmaster

Senior Member

Beiträge: 1 791

Freitag, 28. August 2009, 08:42

Jein. Ich habe natürlich den Code soweit es ging getestet ohne die RSTDISBL Fuse zu setzen.
Wenn sonst nochmal eine Änderung gemacht werden muss setze ich per HV die Fuse zurück und progge wieder per ISP bis ich meine, dass es jetzt laufen könnte...
Da steht nix :-P

Ähnliche Themen