RC-Steuerung: Instabiler Betrieb

JuWi · 17. August 2017, 17:58

Hallo,

ich versuche gerade, mit einem der µC von Atmel ein paar Funktionen für meine RC-Modelle (Schiff) zu realisieren. Für meine ersten (Geh-)Versuche habe ich mir die Beleuchtung eines kleinen Kutters vorgenommen. Da geht es erst einmal nur um 4 Schaltzustände:

Ankerlicht (wenn Boot vor Anker liegt)
Decksbeleuchtung (zusätzlich zum Anker-Licht, aber nicht während der Fahrt)
Positionslichter bei Fahrt
Suchscheinwerfer (zusätzlich zu Positionslichtern)

Auf dem Experimentierbrett klappte das nach einiger Zeit, so dass ich eine passende Platine fürs Modell gemacht habe. Auch da läuft alles bestens in der Werkstatt. Im realen Betrieb tritt nun das Problem auf, dass der Controller ab und an ganz verrückte Signalbilder schaltet, die ich so gar nicht vorgesehen habe. Das Verhalten ist insofern recht gut (aber nicht immer) reproduzierbar, wenn ich den Drehzahlsteller dazu bringe, seine Überlastsicherung zu aktivieren (der Drehzahlsteller erzeugt auch die 5V-Versorgungsspannung für Empänger und µC). Ich stelle dann den Motor auf Null, der Steller startet neu und die Fahrt kann weitergehen (aber eben mit merkwürdigen Beleuchtungseffekten).
Da ich vermutet habe, dass diese Spannungseinbrüche den Controller aus dem Tritt bringen, habe ich noch einen 220 µF-Kondensator in die 5V-Versorgung eingebaut (ist im Schaltplan noch nicht eingezeichnet). Aber auch das brachte nicht die gewünschte Lösung.

Deshalb nun meine Frage an euch: Wie kann ich dem Controller beibringen, ordnungsgemäß wieder am Anfang des Programms zu starten? Meine erste Idee war, den brown-out Detektor zu aktivieren. Wenn ich das richtig verstanden habe, wird dieser mit regelmäßigen Befehlen zurückgesetzt, d.h. das würde mich auch nicht weiterbringen, da das Programm ja noch läuft, allerdings eben fehlerhaft.

Damit ihr wisst, um was es genau geht, füge ich den Schaltplan sowie mein Programm bei und hoffe, dass ihr mir einen Tipp geben könnt, wie ich zu einem stabilen Betrieb kommen kann.

Beste Grüße
Jürgen

Beleuchtung.JPG

Quellcode

'----- Titel -------------------------------------------------------------------
' Module.......: LightControl
' Purpose......: Reads RC signal using interrupt 0 on PB2
' Switches LED's
' 1: Anchor light (Ankerlicht)
' 2: Anchor light + deck light (Ankerlicht + Decklicht)
' 3: Head light (Fahrlicht)
' 4: Head light + search light (Fahrlicht + Suchscheinwerfer)
' Measures RC signal in main loop
' Needed.......: Either adjust minimum and width of pulse in transmitter settings
' or adjust values in constant definitions below
' MCU..........: ATTiny 45-20SU
' Bascom.......: V2.0.7.9
'-------------------------------------------------------------------------------
'----- Settings ----------------------------------------------------------------
$regfile = "ATtiny45.DAT"
'Frequency 1 MHz
$crystal = 1000000
$hwstack = 48
$swstack = 48
$framesize = 40
' 76543210
DdrB = &B00011011 'PinB0,1,3,4 output, PinB2,5-7 input
' 76543210
Portb = &B11100100 'PullUp PinB2,5-7 active
'----- Variables ---------------------------------------------------------------
dim wPulse as word 'stores current reading of RC signal
dim wPulseLow as word : dim wPulseHigh as word
dim wActionBias as word 'stores pulse length difference
dim wSearch as word : dim wSearchLow as word : dim wSearchHigh as word
dim wHead as word : dim wHeadLow as word : dim wHeadHigh as word
dim wDeck as word : dim wDeckLow as word : dim wDeckHigh as word
dim wAnchor as word : dim wAnchorLow as word : dim wAnchorHigh as word
dim iCount as byte 'used as loop counter
dim RC_Read as bit 'used to identify rising or falling pulse edge
Anchor alias portb.0
Deck alias portb.1
Head alias portb.3
Search alias portb.4
const PulseMin = 125 'minimum pulse length
const PulseWidth = 113 'pulse width
const PulseTolerance = 5 'range to define valid switch bias
const ReadRepeat = 5 'necessary pulse readings before switches change
wActionBias = PulseWidth / 3 'ActionBias = PulseWidth devided by number of functions to switch
wSearch = wActionBias * 3
wSearch = wSearch + PulseMin
wSearchLow = wSearch - PulseTolerance : wSearchHigh = wSearch + PulseTolerance
wHead = wActionBias * 2
wHead = wHead + PulseMin
wHeadLow = wHead - PulseTolerance : wHeadHigh = wHead + PulseTolerance
wDeck = wActionBias
wDeck = wDeck + PulseMin '
wDeckLow = wDeck - PulseTolerance : wDeckHigh = wDeck + PulseTolerance
wAnchor = PulseMin
wAnchorLow = wAnchor - PulseTolerance : wAnchorHigh = wAnchor + PulseTolerance
'----- Initialization ----------------------------------------------------------
config timer0 = timer , prescale = 8
config int0 = change
on int0 GetPulse
waitms 2000 'allows pulse reading
config watchdog = 1024
wPulse = 0
RC_Read = 1
timer0 = 0
'===== Program =================================================================
enable timer0
enable int0
enable interrupts
start watchdog
do
iCount = 0
wPulseLow = wPulse - PulseTolerance
wPulseHigh = wPulse + PulseTolerance
do 'repeat pulse readings
if wPulse > wPulseLow and wPulse < wPulseHigh then
incr iCount
waitms 25
wPulseLow = wPulse - PulseTolerance
wPulseHigh = wPulse + PulseTolerance
end if
Loop until iCount = ReadRepeat
select case wPulse
case wSearchLow to wSearchHigh
Search = 1
Head = 1
Deck = 0
Anchor = 0
case wHeadLow to wHeadHigh
Search = 0
Head = 1
Deck = 0
Anchor = 0
case wDeckLow to wDeckHigh
Search = 0
Head = 0
Deck = 1
Anchor = 1
case wAnchorLow to wAnchorHigh
Search = 0
Head = 0
Deck = 0
Anchor = 1
case else
Search = 0
Head = 0
Deck = 0
Anchor = 0
end select
loop
end 'end program
'===== End of program ==========================================================
'----- Interrupts --------------------------------------------------------------
GetPulse:
if RC_Read = 1 then 'start Timer1 if positive signal on input
start timer0
RC_Read = 0
Else 'stop Timer1 if no positive signal
stop timer0
wPulse = timer0
RC_Read = 1
timer0 = 0
end if
reset watchdog
return

Alles anzeigen

tschoeatsch · 17. August 2017, 18:03

Hi, der Fehlerbeschreibung nach und nach Einsicht in den Schaltplan: es fehlen die Abblockkondensatoren und ein kleiner Stützelko. Die Mindest-/Grundbeschaltung ist an jedem VCC-pin 100nF gegen Gnd, und das möglichst nah am Kontroller.

Michael · 17. August 2017, 18:28

JuWi schrieb:

wPulseLow = wPulse - PulseTolerance

das fällt mir gleich ins Auge.
WPulseLow ist ein Word
wPulse hat zu Anfang den den Wert 0 und PulseTolerance ist 5
wPulseLow sollte also den Wert -5 haben.
Da es aber ein Word ist, kommt vor der 0 der Wert 65535.
Statt - 5 steht da also 65531 drin

JuWi · 17. August 2017, 19:01

tschoeatsch schrieb:

...und ein kleiner Stützelko...

Ich habe 220 µF an 5V eingebaut (aber noch nicht im Schaltplan eingezeichnet). Reicht das?

djmsc · 17. August 2017, 19:04

JuWi schrieb:

Reicht das?

Nein es muss direkt am Controller zwischen VCC und GND ein 100nF Abblockkondensator rein.

JuWi · 17. August 2017, 19:19

Michael schrieb:

JuWi schrieb:

wPulseLow = wPulse - PulseTolerance

das fällt mir gleich ins Auge.WPulseLow ist ein Word...Statt - 5 steht da also 65531 drin

Danke für den Hinweis, das hatte ich nicht so auf dem Schirm.
Also wäre es am Anfang des Programms besser, wPulseLow auf 0 zu setzen. Nach dem ersten gemessenen Impuls der Fernsteuerung (der in jedem Fall positiv und größer 5 ist) habe ich dann ja einen gültigen Wert.

Michael · 17. August 2017, 19:26

if wPulse > wPulseLow
wird also erstmal auch nicht wahr werden, das gibt sich aber möglicherweise mit dem Eintreffen erster Pulse.

Hier gibt es aber einen Stolperstein:
if RC_Read = 1 then
Sollte der AVR während des Pulses neu starten, so misst er hier den Low-Puls, RC_Read ist ja Anfangs auf 1 gesetzt.
die Low Pulse sind aber um einiges länger als der High Puls und so gibt es Überläufe und das Ergebnis ist unbestimmt.
Frage im Int0 besser den Zustand des Pins ab

JuWi · 17. August 2017, 19:58

Michael schrieb:

Frage im Int0 besser den Zustand des Pins ab

O.k. ich denke da gerade an

Quellcode

RC_In alias portb.2
....
GetPulse:
if RC_In = 1 then 'start Timer1 if positive signal on input
start timer0
Else 'stop Timer1 if no positive signal
stop timer0
wPulse = timer0
timer0 = 0
end if
reset watchdog
return

Alles anzeigen

Ich habe mir auch noch einmal die Details zur brown-out Detektion durchgelesen. Da habe ich wohl etwas verwechselt. Wenn ich das fuse bit auf z.B. 4V stelle, sollte der µC doch den Betrieb unterhalb dieser Spannung einstellen und oberhalb davon wieder am Programmanfang starten. Das würde dann ja helfen. Ist das so richtig?

Michael · 17. August 2017, 20:01

RC_In alias Pinb.2
nicht portb.2

JuWi schrieb:

Wenn ich das fuse bit auf z.B. 4V stelle, sollte der µC doch den Betrieb unterhalb dieser Spannung einstellen und oberhalb davon wieder am Programmanfang starten. Das würde dann ja helfen. Ist das so richtig?

Für was sollte es helfen?

JuWi · 18. August 2017, 11:27

Hallo Michael,
nach der Beschreibung dieser brown-out Detektion stoppt der µC den Betrieb unterhalb der eingestellten Schwelle und startet neu, wenn die Schwelle überschritten ist. Falls ich mit meiner Vermutung weiter oben Recht habe (was ich aber nicht messen kann) und der Controller wegen kurzzeitiger Spannungseinbrüche aus dem Tritt kommt, dann bekäme ich in diesem Fall wieder einen sauberen Start hin.
Aber erst einmal werde ich mich jetzt ans Testen mit den anderen Vorschlägen machen...

tschoeatsch · 18. August 2017, 12:07

JuWi schrieb:

kurzzeitiger Spannungseinbrüche

Wenn du so starke Spannungsschwankungen hast, dann kannst du in der 5V-Leitung zum attiny eine Diode zwischen schalten und nach der Diode den 200µF + 100nF. Dann bist du auf der sicheren Seite.

Michael · 18. August 2017, 12:16

JuWi schrieb:

Aber erst einmal werde ich mich jetzt ans Testen mit den anderen Vorschlägen machen...

Das wird zumindest das Problem der merkwürdigen Beleuchtungseffekte lösen.

JuWi schrieb:

der Controller wegen kurzzeitiger Spannungseinbrüche aus dem Tritt kommt, dann bekäme ich in diesem Fall wieder einen sauberen Start hin.

Der Start eines AVRs ist für gewöhnlich sauber durch interne Mechanismen wie Reset-Pullup und SUT.
Der Grund für den Spannungseinbruch muss beseitigt werden, das Problem kann nicht mit dem AVR gelöst werden.
Es wurden schon Kondensatoren genannt.
Ich trage noch ein paar Erfahrungen über Störgründe bei: Sternförmige Versorgung, ausreichender Querschnitt, Abstand zwischen Signal- und Versorgungsleitungen, Motorentstörung, ausreichende Leistung der Spannungsversorgung.

fredred · 18. August 2017, 14:23

Hallo,
Eine saubere und stabile Spannungsversorgung ist ein MUSS.
In deinem fall würde ich es auch so machen.

tschoeatsch schrieb:

Wenn du so starke Spannungsschwankungen hast, dann kannst du in der 5V-Leitung zum attiny eine Diode zwischen schalten und nach der Diode den 200µF + 100nF. Dann bist du auf der sicheren Seite.

Sollte aber eine Schottkydiode sein.

Ist mir schon langsam peinlich aber da muss ich wiedersprechen.

Michael schrieb:

Der Start eines AVRs ist für gewöhnlich sauber durch interne Mechanismen wie Reset-Pullup und SUT.
Der Grund für den Spannungseinbruch muss beseitigt werden, das Problem kann nicht mit dem AVR gelöst werden.

Mit sauberen Start okay. JuWi schreibt aber

JuWi schrieb:

dass diese Spannungseinbrüche den Controller aus dem Tritt bringen

Also hat der Spannungseinbruch kein Reset gemacht. Somit war die Vermutung

Michael schrieb:

if wPulse > wPulseLow
wird also erstmal auch nicht wahr werden, das gibt sich aber möglicherweise mit dem Eintreffen erster Pulse.

Hier gibt es aber einen Stolperstein:
if RC_Read = 1 then
Sollte der AVR während des Pulses neu starten, so misst er hier den Low-Puls, RC_Read ist ja Anfangs auf 1 gesetzt.
die Low Pulse sind aber um einiges länger als der High Puls und so gibt es Überläufe und das Ergebnis ist unbestimmt.
Frage im Int0 besser den Zustand des Pins ab

schon plausibler und da würde ich auch ansetzen. Es reicht ja in deinem Fall das eine Sprungadresse zerstört wird.
Versuch erst mal die Fehlerquelle einzukreisen. Schreib einfach mal ein minimalen Testcode(LED- blinken oder so) und vor Do auch eine LED um zu erkennen ob es ein Reset gab. Kommt dieser Code nicht aus dem „Tritt“ dann solltest du deine Code überarbeiten.
Da möchte ich mich aber raushalten.
Gruß

JuWi · 24. August 2017, 16:58

Hallo,
für mein geschildertes Problem sind einige Lösungsvorschläge gemacht worden, erst einmal vielen Dank dafür. Ich habe das Programm wie weiter oben geschrieben modifiziert (wPulseLow ist jetzt minimal 0 und läuft nicht mehr in den hohen Word-Zahlenbereich, die Signalflanke wird jetzt mit Pin.B2 gemessen, der µC hat noch einen 100 nF Kondensator an seine Versorgnugnsspannunganschlüsse bekommen). Damit war auf jeden Fall schon einmal das fallweise "wilde" Blinken weg, ab und an (beim Test zumindest) ist aber noch das Programm "hängen " geblieben, soll heißen Schalten der verschiedenen Lichter ging nicht mehr. Ich habe dann doch noch die brown-out Detektion aktiviert (bei 4,3 V), danach lief in der Testphase alles so wie es sollte. Am Wochende werde ich das bei einem Modell-Treffen noch über einen längeren Zeitraum testen können, aber ich bin mal verhalten optimistisch, dass das jetzt laufen wird.

Bascom hat diese Zeile in das Programm eingefügt:

Quellcode

$PROG &HFF,&H62,&HDF,&HFF ' generated. Take care that the chip supports all fuse bytes.

Bisher bin ich immer davon ausgegangen, dass die fuse bits nur einmal gesetzt werden müssen und bis zur nächsten Änderung der eingestelle Zustand beibehalten wird. Muss diese Zeile bei einer Änderung im Programm an anderer Stelle noch im stehen bleiben?

djmsc · 24. August 2017, 17:03

JuWi schrieb:

Bisher bin ich immer davon ausgegangen, dass die fuse bits nur einmal gesetzt werden müssen und bis zur nächsten Änderung der eingestelle Zustand beibehalten wird.

Das ist ja auch so und die Zeile im Code kannst du entweder auskommentieren oder löschen nach dem du dein Programm geflasht hast.

stefanhamburg · 25. August 2017, 01:44

Die Zeile könnte beispielsweise interessant sei, wenn Du Dein Programm an jemand anders gibst, der es auf einen (ggf. leeren)Mikrocontroller brennen/flashen möchte.
Oder wenn Du das Programm in drei Jahren wieder von Deiner Festplatte holst und auf einen (anderen) Mikrocontroller brennen möchtest. In beiden Situationen ist es ergänzend zum eigentlichen BASCOM-Programm gut, die Fuse-Einstellungen zu haben.
Vielleicht arbeitest Du auch einmal gleichzeitig an verschiedenen Projekten, die unterschiedliche Mikrocontroller/Fusebits erfordern.

JuWi · 29. August 2017, 20:13

@djmsc, stefanhamburg: Danke für die Erklärung. Ich lasse die Zeile im Programm, kommentiere sie aber aus.

@all: Der Test am Wochenende war insofern erfolgreihc, dass trotz ca. 1,5 h Betrieb die Lichtsteuerung keine Mucken zeigte. Insofern stimmt der Titel dieses Themas jetzt nicht mehr - nun läuft's stabil. Danke noch einmal für die Ratschläge.