| Ich nutze: C-Control II Unit, C164CI-ControllerBoard, C-Control II Station, CC2-Application-Board, CC2-StarterBoard, CC2-ReglerBoard, OSOPT V3.1 |
> ich habe meine Steuerung derzeit im Versuchsaufbau und benutze den i2C Bus mit CCTools-Reglerboard
> zur Ansteuerung von
> a.) 1 x i2c Tranceiver und dahinter 2 x i2C Transceiver mit 2x i2C Terminal auf LCDs
> b.) 1 x i2C Terminal auf LCD
> c.) 1 x i2C RAM-Device
> d.) 2 x i2C Relaisplatine
> e.) 2 x i2C 1-Wire Bridge (mit insgesamt 15 Sensoren)
>
> Thread 1 bedient a.) und b.)
> Thread 2 bedient c.) und e.)
> Thread 3 bedient d.)
Wenn die Thread die überwiegende Zeit auf dem I²C-Bus arbeiten(d.h. mehr als 2/3)
und gleichzeitig die Threads (oder zumindest einer) nicht sehr lang sind,
kann es sein, da� der Threadwechsel innerhalb eines I²C-Captures erfolgen soll.
Da aber die anderen Threads dann auf die Freigabe warten, wirt die Rechenzeit von diesen
sofort wieder abgegeben, so daÃ? der erste Thread wieder die Rechenzeit bekommt, und
im ungünstigsten Fall wieder zu einem I²C-Capture kommt, bvor die Rechenzeit wieder
abgegeben wird.
Ein solcher Kandidat wäre bei Dir Thread 1, da ich vermute, da� dieser, au�er Ausgaben
auf den Terminals und das Einlesen der Tasten, nicht viel au�erhalb von I²C betreffenden
Routinen macht.
Wenn das der Fall ist, wäre ein Abbremsen mit sleep oder zumindest ein paar verteilte
yields sinnvoll.
Displayausgaben mu� man nicht ständig durchführen. Je nach Anwendung reicht
eine Ausgabe im Halb-oder Einsekundenintervall bzw. sogar nur bei Ã?nderung.
Tastaturen an den Terminals sollten nicht per Polling abgefragt werden.
Besser ist es, alle Interruptleitungen der Terminals auf einen I/O-Port zu legen
(Pull-Up nicht vergessen), und nur bei einem Low-Pegel alle Terminals abzufragen,
solange das auslösende Terminal gefunden wurde.
Dein Thread 2, denke ich, wird bereits sleeps enthalten?
Ich gehe davon aus, daÃ? auf das RAM-Device in einem bestimmten Intervall, und
auf die 1W-Sensoren max. im Sekundentakt zugegriffenwird.
�hnliches wird wahrscheinlich beim Thread 3 für die Relaisplatinen sein.
Welcher Thread übernimmt eigentlich die Regelungsaufgaben?
Ich gehe mal davon aus, daÃ? es Thread 3 ist.
Um etwas zu veranschaulichen, hier die Aufteilung der Threads meiner Heizungsregelung:
Es sind derzeit 12 Threads:
1. Thread rbports.main{} Portansteuerungen inkl. Multiplexer(ReglerBoard)
2. Thread sync{} in pcf8583.c2 (I²C-Bus-Zugriffe)
3. Thread watchdog{} in pcf8583.c2 (I²C-Bus-Zugriffe)
4. Thread temp.gettemp{} (I²C-Bus-Zugriffe)
Einlesen aller Temperaturwerte: 17 analoge Sensoren und 5 One-Wire-Sensoren
5. Thread com.com{}
Kommunikation über RS232/XPort
6. Thread anzeige.beep{}
Soll nur ein Signal über den Piezo ausgeben, ohne den eigentlichen Anzeigethread
auszubremsen. :-) Der Thread hält sich nach einem Durchlauf selbst an.
7. Thread screen.keyb{}
Thread für Touchdisplay an SWCOM. (Displayausgaben, Toucheingaben)
8. Thread regelung.HK1{}
Mischerregelung Heizkreis 1 (gestartet über regelung.regelung{})
9. Thread regelung.HK2{} (I²C-Bus-Zugriffe (Relais))
Mischerregelung Heizkreis 2 (gestartet über regelung.regelung{})
10. Thread regelung.regelung{} (I²C-Bus-Zugriffe (Relais))
Komplette regelung, steuerung der Threads HK1 und HK2. Ausführungsintervall 1sec..
11. Thread main.beeb{}
Startmelody bei Programmstart. :-)
12. Thread main.main{} (I²C-Bus-Zugriffe(Inits))
Initialisierungen, starten von Threads, CAN-Kommunikation
mit CC2-Station V1.1(Advanced, BHKW-Steuerung)
MfG André H.
Antworten bitte nur ins Forum!
Fragen per EMail auf Forum-Postings werden nicht beantwortet!
Das macht meine Heizung gerade
Antwort schreiben
Antworten:
Re: I2C-Terminal friert ein (von Mexx - 13.08.2008 12:36)