TSIC und ATMega

Welche fallende Flanke?

Der TSIC306 sendet (etwa) alle 100 ms für 2,6 ms.

Zu Anfang kann man da auch mal falsch liegen. Na und?
Danach ist 97 ms Ruhe und dann kommt die nächste
komplette Übertragung.

Lass das alles einen IRQ machen...

Willst du es per Interrupt machen, oder etwa im Hauptprogramm
drauf warten?

Geht es um einen TSIC306? Es gibt auch andere ZACWIRE-Sensoren,
denen man sogar mitteilen kann, wie oft sie Daten liefern sollen.

Ich habe es mal mit PINCHANGE-Interrupt am tiny24 gemacht,
dazu brauchte ich noch einen freilaufenden Counter, dessen
Zählerstand jeweils eingelesen wurde, um die Daten-Erfassung im
PINCHANGE-Interrupt mit Hilfe einiger reservierter Register
zu bewerkstelligen. In einem Register wird dem Hauptprogramm
mitgeteilt, wenn ein gültiger Wert fertig vorliegt.

Matthias P. schrieb:
> Ok, so weit so gut, also muss ich im Prinzip nur solange warten bis die
> ersten 97ms der Interrupt Pin auf HIGH war?

Der TSIC macht zwischen den Übertragungen eine Pause. Man sucht eine 
Pause und reagiert auf die nächste fallende Flanke. Da beginnt das 
Startbit.

Im Datenblatt gibt es auch einen anderen Hinweis: Die Synchronisation 
kann durch Schalten der Versorgungsspannung erfolgen.

Suche auf jeden fall mal nach der App-Note für ZAC-Wire!

Egal ob du den µC durch Warten blockierst, oder eine
pfiffige Interrupt-Routine baust: Es werden nicht einfach
alle Datenbits rausgeschoben, die Bits sind auf 2 Gruppen
(mit kleiner Pause und neuem Startbit) verteilt.

Allerdings ist das beigefügte PIC-Beispiel nur tauglich,
wenn der µC sonst nichts zu tun hat. WARTEN mit NOP....

Die Synchronisation durch Schalten der Versorgungsspannung
ist "nett gemeint" - man darf dann 65...85 ms WARTEN (!),
bis die Datenübertragung (< 3 ms) beginnt.

Die Stromersparnis kommt erst zum Tragen, wenn man frühestens
nach einigen Sekunden die Temperatur erneut abruft und wenn
es wirklich auf 50 µA ankommt .

Bernie schrieb:
> Die Synchronisation durch Schalten der Versorgungsspannung
> ist "nett gemeint" - man darf dann 65...85 ms WARTEN (!),
> bis die Datenübertragung (< 3 ms) beginnt.

Mensch Berniechen, sei doch nicht so einfältig. Auch wenn der Sensor 
frei läuft, hast du die knapp 100ms Pause. Nach Reset muss sich der µC 
mit dem Sensor synchronisieren und wieder können es bis knapp 100ms 
werden. Der TSIC ist in einem Kunststoffgehäuse untergebracht. Das ist 
relativ träge. Was meinst du, wäre eine sinnvolle Messfrequenz?

@MSP:

Was hat es mit Einfalt zu tun, wenn ich die Bearbeitung per
Interrupt empfehle, um das WARTEN zu VERMEIDEN?

Die Enrgieeinsparung bei seltenerer "Ablesung" habe ich doch
nicht in Frage gestellt.

Wer einen µC einsetzt, will den aber fast immer noch andere
Sachen erledigen lassen, als "WARTE AUF SENSORSIGNAL"...

65...85 ms kann man kaum als echten Zeitgewinn gegenüber 100 ms
verkaufen!

Oder hast du noch nicht verstanden, dass Interrupts bei Nicht-
Auslösung alle Zeit dem Hauptprogramm, oder anderen Interrupts
überlassen?  ;-)

Bernie schrieb:
> @MSP:
> Wer einen µC einsetzt, will den aber fast immer noch andere
> Sachen erledigen lassen, als "WARTE AUF SENSORSIGNAL"...

Mensch Bernie, jetzt verkaufts du dich noch d...er als oben.

Wo bitte schön habe ich geschrieben, dass keine Interrupts verwendet 
werden sollen???
Der Tipp mit der geschalteten Versorgung erleichtert die 
Synchronisation!!!

> 65...85 ms kann man kaum als echten Zeitgewinn gegenüber 100 ms
> verkaufen!

In meinem Post schrieb ich, dass der TSIC träge ist. Die Auswertung 
mit 100ms Messzyklen ist völlig übertrieben. Es ist also völlig egal, ob 
20ms, 40ms, ..., 100ms. Ich würde den TSIC nur minimal alle 10s 
abfragen. Vorher ist eine Temperaturänderung doch gar nicht im Inneren 
des Sensors angekommen.

Was braucht's eine Synchchronisation, wenn die Interrupt-
Routine von ganz allein meldet: Neuer Wert vorhanden!

@ MSP: Schlaf weiter!
Die geschaltetete Versorgungsspannung spart bei Batterieprojekten
Strom und kostet ansonsten einen µC-Pin.

Außerdem:
Das Gegrantel bringt nix: Der TO hat schon lang nicht mehr
vorbeigeschaut. Gute Nacht!

Bernie schrieb:
> Was braucht's eine Synchchronisation, wenn die Interrupt-
> Routine von ganz allein meldet: Neuer Wert vorhanden!

Du bist ja der wahre Trollmaster. Und wer bitte schön schreibt die ISR? 
Fällt die vom Himmel?

Ein embedded System hat nicht nur den Zustand "run". Es gibt auch 
weitere. Irgendwann musst du schon die beiden ICs synchronisieren.

Dann schlaf mal gut und lass die großen Jungs das machen.

@  MSP (Gast)

Zeig doch mal deine ISR,
ich hab schon eine!

;-)

Bernie schrieb:
> Zeig doch mal deine ISR,
> ich hab schon eine!

Ahhhh, der Obertroll hat also ein Geheimnis. Du kennst den Sinn eines 
Forums?

Der gute Matthias braucht Unterstützung bei der Auswertung eines TSIC. 
Was helfen ihm wohl deine Belobigungen über deinen unveröffentlichen 
Code?

Erklär einmal, wie du synchronisierst. Und zwar bei allen 
Systemzuständen. Dann hätten wir etwas zur fachlichen Diskussion.

Warum sollte ich dir was verraten, wenn du mich als
Obertroll beschimpfst?

Jemand, der fähig ist, daraus zu lernen, mag doch nach deinen
Meckereien nicht mehr weiterlesen.

Trotzdem kleiner Tipp:
- 5..6 der Register 0..15 reservieren und initialisieren.
- INT1: Any logical change on INT1 generates an interrupt request.
- CTR0: freilaufend im Takt von 1 MHz

Flanke an INT1 -> IRQ
Negative Flanke: IRQ testet Overflow-Flag von CTR0 und resettet
ihn und das Overflow-Flag.
Lag ein Overflow vor: Start einer neuen Übertragung!
(Die Abstände innerhalb der Übertragung sind unter 256 µs.)

Bernie schrieb:
> Warum sollte ich dir was verraten,

Mir musst du nichts verraten, aber du beteiligst dich an einer Frage von 
Matthias.


> Flanke an INT1 -> IRQ
> Negative Flanke: IRQ testet Overflow-Flag von CTR0 und resettet
> ihn und das Overflow-Flag.
> Lag ein Overflow vor: Start einer neuen Übertragung!
> (Die Abstände innerhalb der Übertragung sind unter 256 µs.)

Na also, geht doch. Warum nicht gleich so?

Nanu? Warum fragst du nicht "MSP (Gast)"? Der tut doch hier
so oberschlau!

Scherz beiseite, ich schrieb natürlich, dass es eine "schlaue"
Interruptroutine sein muss. Das soll nicht heißen, dass sie
schwer verständlich ist, sondern dass sie einiges - Schritt für
Schritt - bei jedem Pegelwechsel des TSIC bearbeitet.

Unser Verständnisproblem wäre jetzt, dass ich es in ASM
verwirklicht habe - und du es in C machen willst. Da kann ich
dir leider nicht sooo exakt helfen, besonders weil sich das
Tutorial um die Prozessor-Register R0...R31 elegant rumdrückt.

Fangen wir mal mit der Synchronisierung an:
-------------------------------------------
- Mach den mega8 ERST MAL frei von USB- oder sonstigen
  nicht überschaubaren Aufgaben.

- Reserviere einige GLOBALE Variablen nur für diese
  TSIC-Bearbeitung.
  Erst mal eine für COUNT-OLD.

- Sorge dafür, dass einer der zwei 8-Bit-Timer/Counter des
  mega8 mit etwa 1 MHz frei läuft.

- Schließe den TSIC an INT1 an und stelle den INT1 so ein,
  dass er auf positive UND negative Flanken reagiert.

- Wird der INT1 ausgelöst, frage sofort PinD-Bit3 ab.
  (Ist PinD-Bit3 = 0 liegt eine negative Flanke vor.)

- Lese den Zählerstand des Timer/Counters aus.
- Schau nach, ob Timer-Overflow dieses Zählers gesetzt wurde.
- Diesen Timer-Overflow sofort resetten.

- Ist bei negativer Flanke der neue Zählerstand abzüglich
  COUNT-OLD größer als 200 (µs)? (Bei Timer-Overflow kannst du
  diese Differenz um mindestens 256 (µs) erhöhen.)
  Dann bist du am Startpunkt einer neuen Übertragung des TSIC!!!
  Schalte JETZT an irgendeinem Portpin eine LED an!
  Sonst (!) setze diesen Portpin jedes mal auf LED = aus.

- Vor dem Ende der INT1-Routine den neu gelesenen Zählerstand
  in COUNT-OLD speichern.

Nun schau mal, ob die LED immer aufblitzt, wenn am Oszilloskop
gerade eine neue Übertragung abläuft.

Wenn du interessiert bist, melde dich wieder - ES IST MACHBAR!
Der Rest ist eher einfacher.

Bernie schrieb:
> Warum fragst du nicht "MSP (Gast)"?

Du hast mich gerufen Bernie, hier bin ich. Das Thema ist 
Synchronisation? (Hast du das wieder unterm Teppich hergeholt?)

1. per Portpin den TSIC einschalten und Eieruhr mit ca 20ms (Wert ist 
unkritisch, s. Datenblatt) aufziehen: z. B. mit Timer Interrupt.
2. Bei abgelaufener Eieruhr (Timer Interrupt) den Portpin mit TSIC Daten 
auf fallende Flanke Interrupt einstellen
3. Bei fallender Flanke beginnt das Starbit

das war 's :-P

Bernie schrieb:
> Ist bei negativer Flanke der neue Zählerstand abzüglich
>   COUNT-OLD größer als 200 (µs)?

Woher kommt der Zeitwert. Die Bitrate vom TSIC unterliegt sehr starken 
Schwankungen. Feste Werte sind mit Vorsicht zu genießen.

Oh, "MSP (Gast)" ist wieder dabei! Und schreibt falsch ab:
Von 20 ms steht nichts in der App-Note, sondern 65...85 ms.

Welchen Timer mit welcher Zählfrequenz benutzt du denn für die
Decodierung des "TSIC-Telegramms"?

Die Hardware für die "reine" Interrupt-Lösung (INT1 und einen
Timer/Counter) muss man auch bei der langweiligen WARTE-Lösung
für die Code-Erkennung belegen...

Wenn man die Temperatur seltener auslesen will, kann man die
"reine" Interrupt-Lösung natürlich auch Sekunden- oder Minuten-lang
ruhen lassen.

Oh, "MSP (Gast)" verbreitet Furcht vor großen Toleranzen -
machen wir es eben mit REICHLICHST Toleranz!

Nominelle Ausgaberate 10 Hz, Bitdauer 125 µs.
Kennt jemand Exemplare, die langsamer, als 50%, oder schneller,
als 200% sind?

Also Annahme: Bitdauer 62...250 µs (Ausgaberate 5...20 Hz).

Nehmen wir bei 8 MHz µC-Clock den Timer1 mit Prescaler 1/32.
Wenn wir seinen Zählerstand UND sein Overflow-Flag bei jeder
negativen INT1-Flanke auslesen und danach auf Null setzen, können wir
Zeiten von 0...1 ms mit 4 µs Auflösung erfassen.
Zeiten länger als 1 ms zeigen sich durch das Overflow-Flag.
Mehr Sicherheit für die Erkennung der Pause vorm Startbit, ohne
Langeweile beim µC, geht garnicht!

Erkennung von Logisch 1 und 0:
Bei positiver Flanke lesen wir nur den Zählerstand aus.
Das Startbit hat 50% duty cycle bei 62...250 µs Bitdauer: 31...125 µs.
=> Timer1-Stand nach der positive Flanke = 7...32. (Referenzwert!)

Somit lassen sich locker die duty cycle von 25% und 75% unterscheiden.
Logisch 0 / 1 bei Zählerstand  < Referenzwert / > Referenzwert.

Auch bei Timer0 mit Prescaler 1/64 (Auflösung nur 8 µs) gäbe es keine
Probleme! Logisch 0 / 1 bei Zählerstand < 3 / > 3 ... < 16 / > 16.


@  Matthias P.:
Bei Interesse gibts dann auch Hinweise zur Auwertung.

Bernie schrieb:
> Und schreibt falsch ab:
> Von 20 ms steht nichts in der App-Note, sondern 65...85 ms.

Und Bernie stellt sich wieder d... an. Denn ich schrieb
MSP schrieb:
> ca 20ms (Wert ist unkritisch
und warum? Es handelt sich um die Zeit, die ich dem TSIC gönne, damit er 
sich nach Power On stabilisiert. Die Werte im Datenblatt werden nicht 
immer eingehalten. Probier das ruhig einmal aus.

Bernie schrieb:
> Welchen Timer mit welcher Zählfrequenz benutzt du denn für die
> Decodierung des "TSIC-Telegramms"?
>
> Die Hardware für die "reine" Interrupt-Lösung (INT1 und einen
> Timer/Counter) muss man auch bei der langweiligen WARTE-Lösung
> für die Code-Erkennung belegen...
>
> Wenn man die Temperatur seltener auslesen will, kann man die
> "reine" Interrupt-Lösung natürlich auch Sekunden- oder Minuten-lang
> ruhen lassen.
???
Keine Ahnung wo ich dir hier helfen kann. Es ging doch um 
Synchronisation.
und ich schrieb
MSP schrieb:
> Bei abgelaufener Eieruhr (Timer Interrupt)

Bernie schrieb:
> Furcht vor großen Toleranzen -
> machen wir es eben mit REICHLICHST Toleranz!
Zacwire ist ein Protokoll mit Übertragung der Baudrate. Feste Werte für 
Zeiten sind nicht sinning und auch nicht erforderlich.

Bernie schrieb:
> Also Annahme: Bitdauer 62...250 µs
Wie lang sind die Stop Bits zwischen den Daten? Aber nicht nach 
Datenblatt sondern selbst gemessen.

Man merkt, dass dir meine Synchronosation gefällt. Sie hat ja Vorteile:
- unabhängig von der Baudrate
- schlank und kurz
- funktioniert in jedem Fall, denn es gibt nur einen Fall. Mit der 
ersten fallenden Flanke beginnt das Startbit

@ MSP (Gast)

Hast du wieder keine Antwort, außer "Warteschleife"?

Das ist DEINE BESTE Lösung: Schlanke kurze WARTESCHLEIFEN.

Wer AHNUNG hat, kann andere Vorgehensweisen VERSTEHEN.
Kannst du das nicht?

Es ist wohl nicht mal DEINE Lösung, da du keine Auskunft
geben kannst, welche µC-Resourcen du dafür und für die
Dekodierung benutzt hast.

Bernie schrieb:
> Wer AHNUNG hat, kann andere Vorgehensweisen VERSTEHEN.

Na Bernie, dann bemühe dich doch endlich. Denn das

Bernie schrieb:
> Hast du wieder keine Antwort, außer "Warteschleife"?
>
> Das ist DEINE BESTE Lösung: Schlanke kurze WARTESCHLEIFEN.

zeigt, dass du den Text nicht gelesen oder nicht verstanden hast.

Bernie schrieb:
> welche µC-Resourcen du dafür und für die
> Dekodierung benutzt

Für Synchronisation und Datenempfang werden
   Ausgang für ON/OFF TSIC
   Eingang für Daten (interruptfähig)
   Timer
benötigt.

Der TSIC ist Master der Übertragung. Es braucht eine Synchronisation mit 
dem Slave. Und das muss in allen Fällen funktionieren. Den Master 
kontrolliere ich über die Spannungsversorgung. Und die erste fallende 
Flanke ist garantiert das Startbit. Für die Synchronisation wird keine 
Rechenleistung benötigt.
Ich hoffe, jetzt hast du es verstanden.

Und da dir die Verschwendung von Rechenleistung wichtig ist:
Bei deiner Variante führt jede Flanke zu einer Berechnung und das können 
über 30 Flanken sein.

Für die Synchronisation benötigt deine Variante nur die fallenden 
Flanken. Das lässt sich später auf beide Flanken umkonfigurieren.

Die absoluten Zeiten wurden schon angesprochen.

@ MSP (Gast)
Hast du den ganzen Abend gewartet, dass dich jemand lobt?
Gibt leider nichts loben:


  Ein µC in Warteschleife braucht keine Rechenleistung?
- Falsch:
In Warteschleifen steht die Rechenleistung nicht zur
Verfügung, die vielleicht anderswo gebraucht wird.


  30 Flanken?
- Falsch:
Es sind genau 40 Flanken (20 neg, 20 pos.) pro Messwert.
Bis zur Startflanke braucht meine Variante nur ein paar
µC-Takte für die Initialisierung. Deine steht mindestens
160.000 (eher 680.000) µC-Takte dumm rum.

Falls du überhaupt schon mal daran gedacht hast, die
Datenbits zu dekodieren, musst du die auch bearbeiten.

Wenn meine Interruptlösung in der Pause auf das
Startbit wartet, wird der µC überhaupt nicht belastet.
Es kommt doch nichts - da kann man auch gleich beide
Flanken des INT1 aktivieren.


  Du willst dekodieren, ohne auf die positiven
  Flanken zu reagieren?
- Falsch:
Die Zeit von negativer zu positiver Flanke wird benötigt,
um beim Startbit die "Baudrate" zu bestimmen. Danach, um
den Bitwert (0/1) zu bestimmen.


Für mich erscheinst du einfach ignorant.
Das Wort kannst du bei WIKI nachlesen. Bei dir ist es aber
keine Absicht! - Dazu würde ja ein Mindestmaß an Wissen
gehören...

Nun Bernie, was ist mit dir los?
Weist du nicht, wie Interrupts in einer CPU verarbeitet werden? Oder 
bist du ignorant und enttäuscht, weil deine mühsamm und mit viel Einsatz 
gestrickte SW noch Verbesserungspotenial besitzt?

Aber ich will dir gerne helfen.

Bernie schrieb:
> Ein µC in Warteschleife braucht keine Rechenleistung?
Wie kommst du immer wieder auf Warteschleife? Bei meiner Variante gibt 
es keine Warteschleifen. Es wird ein Portpin gesetzt und der Interrupt 
für eine negative Flanke aktiviert. Das war es. Jetzt kann der µC machen 
was er will.

Bernie schrieb:
> 30 Flanken?
MSP schrieb:
> das können
> über 30 Flanken sein
Wenn du beim µC die Interrupts aktiviertst, weisst du nicht, was der 
TSIC gerade macht. Im ungüstigen Fall passiert das genau im ersten 
Startbit. Dann springst du bei jeder der über 30 Flanken in deine ISR 
und rechnest.
Ob das kritisch ist, musst du selbst entscheiden. Dir war aber die 
Verschwendung von Rechenleistung wichtig, oder?

Bernie schrieb:
> Wenn meine Interruptlösung in der Pause auf das
> Startbit wartet, wird der µC überhaupt nicht belastet.
> Es kommt doch nichts - da kann man auch gleich beide
> Flanken des INT1 aktivieren.
Doch, du benötigst Rechenleistung, siehe oben.

Bernie schrieb:
> Du willst dekodieren, ohne auf die positiven
>   Flanken zu reagieren?
MSP schrieb:
> Für die Synchronisation benötigt deine Variante nur die fallenden
> Flanken. Das lässt sich später auf beide Flanken umkonfigurieren.
Für die Synchronisation braucht man keine positiven Flanken. Wenn man 
sie für die Datenbits braucht, konfiguriert man nach der Synchronisation 
die Flanken um.

@ MSP (Gast)
Von klugen Menschen lass ich mich ungern "d... " nennen.

Von Menschen, wie dir, die nicht verstehen, worum es geht,
schon garnicht.

Bei meiner Lösung kostet der sichere (!) Empfang bei 8 MHz
mit Einschalten des TSIC 200 µs,
sonst (worst case) 400 µs.

Viel Spaß in deiner Warteschleife!

Biete was besseres, oder hasta la vista, Baby!

Bernie schrieb:
> Viel Spaß in deiner Warteschleife!
> Biete was besseres, oder hasta la vista, Baby!
Ok, es ist also dein angekratzter Stolz.

Deine Oberflächlichkeit bei Erkennung der Systemzustände lässt auf einen 
Hobby Bastler schließen. Im industriellen Umfeld muss eben mehr beachtet 
werden.

Bernie schrieb:
> mit Einschalten des TSIC
Aber schön, dass du doch andere Ideen annimmst. Auch wenn es einen 
weiteren Portpin kostet, hat es noch weitere Vorteile.

@ MSP (Gast) Mein Stolz? Deine Professionalität?

- Warum lauerst du denn hier tagelang auf ein bisschen
  Anerkennung?

- Warum bist du so "d... " und kannst nicht über deine
  einmal (abgekupferte?) Lösung hinausblicken?

Bei mir ist es eher die Freude, mit der Verbreitung von
Wissen über resourcensparende, sonst mindestens
gleichwertige Denkansätze, anderen bei der Problemlösung
zu helfen. - Darum antworte ich dir überhaupt noch.

Hab ich das Einschalten des TSIC abgelehnt?
- Nein, deine alberne Warteschleife dabei!
- Und dass man einen Portpin gegen << 0,1 mA Strom-
  erparnis abwägen muss. Das sollten "Profis im
  industriellen Umfeld" schon mal können!

Wer für triviale Probleme gleich zum nächstgrößeren µC
greift, hat noch nie Kostendruck gespürt. Das kostet
nicht nur die paar Cent des größeren Chips...

Weitere Vorteile?
Deine (zeitliche) µC-Belastung?
- Da kommt mal wieder nix. (Woher denn auch...)

Bernie schrieb:
> Hab ich das Einschalten des TSIC abgelehnt?
> - Nein, deine alberne Warteschleife dabei!
Und wenn du es 100mal wiederholst, wird es nicht realer. Tja, wenn 's 
fachlich fehlt, dann ...

Bernie schrieb:
> Bei mir ist es eher die Freude, mit der Verbreitung von
> Wissen
Bernie, Bernie, dann fang doch bitte an. Von dir kommt nichts als 
Selbstbelobing. Welche wissenwerte Dinge hast du denn verbreitet?

Den TSIC zu koppeln ist nicht gerade der höchste Schwierigkeitsgrad. Das 
haben schon Hunderte gemacht. Und zu 99% nach einer der beiden 
Möglichkeiten:
a) Zeit des Low-Pegel messen und mit der halben Bitzeit vergleichen
b) in der Mitte des Bits den Pegel abfragen (wie beim UART)

Bernielein hat Variante a) gewählt und glaubt damit das Ei des Columbus 
gefunden zu haben. lol

Aber wie ich schon schrieb, ist das nur ein Teil der Systemzustände. Da 
gibt es noch etwas darum herum.

He, hier gibts ja grade einen aktiven Thread fürn TSIC-Tempratursensor.
Ist der schwer einzuprogrammieren? Oder streitet ihr aus Spaß?

Bin an einer Steuerung mit AVR4313 und soll noch einen TSIC ranhängen, 
weil man für einiges Temperaturkompensieren muss. 3 Ports sind noch 
frei, USART aber nicht. Geht das und ohne Interrupt? Die Tempratur kommt 
doch 10 mal die Sekunde.

danke J. Knetling

Schwer ist das nicht. Beim 4313 kann ja fast jeder Port-Pin
einen Interrupt auslösen - das brauchst du für die Erfassung
des Telegramms. Hast du noch einen Timer frei, oder einen
der durchgängig zählt?

Streiten? Man kann es auf verschiedene Weisen machen.
Manche Leute meinen, es gibt nur EINEN Weg. Aber wenn du
schon Steuerung kannst, wirst du schon sehen, was bei dir
am besten passt.

Machst du es in ASM oder C?

Ich verstehe den ganzen Thread nicht. ihr macht hier einen Popanz um 
eines der einfachsten protokolle, die es überhaupt gibt:

Jedes Bit beginnt mit einer fallenden Flanke, das Startbit hat einen DC 
von 50%, ist also leicht von den anderen Bits zu unterscheiden.

Hier gibt es fertige Codes für AVR und PIC 
http://www.mikrocontroller.net/articles/Temperatursensor#TSic, einem 
Beispiel für den PIC habe ich die folgende Erklärung entnommen:

1

;                       Duty-Cycle:

2

; Startbit                   50%

3

; Daten-/Parity-Bit logic 0: 25%

4

;                   logic 1: 75%

5

; typ. Länge eines Bits: 125 usec

6

;

7

; Messprinzip:

8

; Die Bitlänge ist temperaturabhängig, deshalb bestimmt man die Bitlänge bei jedem Byte durch Messung des Startbits

9

; dieses hat einen Duty-Cycle von 50%. Wenn das halbe Startbit rum ist (LO), wird die Zeit t_strobe gemessen.

10

; Diese Zeit wartet man vom Start eines jeden Daten-Bytes, und nimmt dann den Zustand des Daten-Pins auf. Ist er

11

; LO, dann ist das Daten-Bit 0 (25% Duty-Cycle), ist er HI, dann ist das Daten-Bit 1 (75% Duty-Cycle)

Absolut easy, oder ...

Knetling schrieb:
> Ist der schwer einzuprogrammieren?
Nein, keine große Nummer.

Knetling schrieb:
> weil man für einiges Temperaturkompensieren muss
Was für Reaktionszeiten bei Temperaturänderung benötigst du? Der TSIC in 
seinem Kunststoffgehäuse muss ja der Änderung folgen können. Evtl. kann 
das durch Kopplung mit einer Wärmeleitfläche (Kühlkörper) verbessert 
werden.

Knetling schrieb:
> Die Tempratur kommt
> doch 10 mal die Sekunde.
Aber so schnell wird sie sich im TSIC (also am Messpunkt) nicht 
ändern. Also brauchst du nicht jeden Datenrahmen empfangen und bei 
knappen Resourcen solltest du das auch nicht.

Bernie schrieb:
> Schwer ist das nicht.
Da hatte ich bei dir einen anderen Eindruck. Ich dachte du hättest eine 
Doktorarbeit über den TSIC geschrieben.

bingo schrieb:
> eines der einfachsten protokolle, die es überhaupt gibt
bingo schrieb:
> Absolut easy, oder ...
full agree

Voll super, wird schon klar!

Geht das gut mit Versorgung ausm Portpin?
Also den TSIC alle Sekunden von einem Port eingeschalten, und einen 
PCINT für die Daten aktivieren.
Timer0 muss dann für die Zeitgeschichten ran.

PCINT kommt bei jeder Flanke, da kommt mal keine bis zum Start-Bit. Dann 
kommt die 50% Zeit, mess ich mit Timer0. Damit die andern Bits nach 
fallende Flanke vergleichen.

Worauf muss ich 20ms warten?

Und wieso ist die Bitlänge tempraturabhängig? Dachte die Temperatur ist 
in den 2 Datenbytes.
( Steht so im Datenblatt. )

Knetling schrieb:
> Geht das gut mit Versorgung ausm Portpin?
Ja, aber Spannung anhand der Datenblätter kontrollieren.

Knetling schrieb:
> Flanke, da kommt mal keine bis zum Start-Bit
Ja, aufm Labortisch. Besser ist es dem TSIC ein wenig Zeit zum 
Stabilisieren zu geben. Die Zeit ist unkritisch, Bsp. 2ms ... 20ms.

Knetling schrieb:
> Worauf muss ich 20ms warten?
Gar nicht, der Floh kommt von "Ich kann nicht lesen Bernie".

Knetling schrieb:
> Und wieso ist die Bitlänge tempraturabhängig?
Intern im TSIC gibt es eine Takterzeugung. Die ist nicht 
temperaturstabil. Das ist aber völlig egal, da die Bitzeit vom Startbit 
abgeleitet wird.

Knetling schrieb:
> Damit die andern Bits nach
> fallende Flanke vergleichen.
oder ab dem halben Startbit bei den nächsten vollen Bitlängen auf den 
Pegel gucken.
Für Bernie: Das dürften ein paar Maschinenbefehle weniger sein. Aber 
eigentlich egal, wenn man die Zeit damit vergeudet, alle 100ms Daten zu 
lesen.    Klick?

Ich habe mal meinen LA angeworfen und das Protokoll aufgezeichnet. 
Daraus kann man sehr schön sehen, dass es sehr wohl Sinn macht, die 
Versorgung des TSIC über einen zusätzlichen Port ein und aus zu 
schalten.

In Image1 wird der TSIC eingeschaltet (Vdd geht HI und wenige ns danach 
auch Data), etwa 35 ms später kommen die 2 fast zusammenhängenden Blöcke 
mit den Daten. Diese sind in Image 2 dargestellt: je ein Startbit (S), 8 
Datenbits (0/1) und ein Paritybit (P). Wenn man per Timer die LO-Phase 
des Starbits ausmisst (hier sind es etwa 62µs) und dann nach jeder 
fallenden Flanke genau diese Zeit abwartet, braucht man nur den Zustand 
von Data (0/1) aufzunehmen und hat das Datenbit.

In Image 3 ist der Verlauf aufgezeichnet, den man im frei laufenden 
Modus hat: etwa alle 100 ms zwei fast zusammenhängende Datenblöcke.

Der Modus mit ein/aus geht also wesentlich schneller (nach 35 ms hat man 
die Daten) als der frei laufende Modus (im Mittel dauert es 50 ms, bis 
der Datenblock da ist). Da man im ein/aus-Modus sicher sein kann, dass 
als erstes ein Startbit kommt, kann man die Daten einfach per Polling 
aufnehmen, das sind nur wenige Befehle in ASM oder C. Im frei laufenden 
Modus muss man erst mal auf eine Pause von einer gewissen Länge warten 
(z.B. 60-80 ms) und dann pollen oder man nimmt per Interrupt auf und 
muss entscheiden, ob ein Start- oder ein Daten-Bit vorliegt.

Zudem fällt die Erwärmung des Dies im TSIC weg, die angesichts des 
geringen Stromverbrauch nur gering, aber messbar ist.

bingo schrieb:
> etwa 35 ms später kommen
Aha, und was steht im Datenblatt? Ich kann die größeren Abweichungen 
bestätigen.

bingo schrieb:
> dann nach jeder
> fallenden Flanke genau diese Zeit abwartet, braucht man nur den Zustand
> von Data (0/1) aufzunehmen und hat das Datenbit.
oder du nimmst einen Timerinterrupt mit der doppelten Zeit (also von 
einem ganzen Bit) den du nach dem halben Startbit (steigende Flanke) 
scharf schaltest. Dann reicht der Zustand beim Timer-Ereignis.

bingo schrieb:
> Der Modus mit ein/aus geht also wesentlich schneller
> als der frei laufende Modus
das stimmt so nicht. Das hängt davon ab, wann die Auswertung startet. 
Das kurz vor dem Satartbit sein, dann geht es schneller, oder während 
oder kurz nach der Datenübertraguzng, dann dauert es länger.

bingo schrieb:
> dass als erstes ein Startbit kommt, kann man die Daten einfach per Polling
> aufnehmen
buhhh!

bingo schrieb:
> Zudem fällt die Erwärmung des Dies im TSIC weg, die angesichts des
> geringen Stromverbrauch nur gering, aber messbar ist.
da wäre ich an Daten interessiert.

BINGO! bingo!  ;-)

Mit deinen Bildern schnall ich auch wie das 2. Byte kommt. In der 
Zackwire-PDF sieht man das nichtso richtig.

0000001011010111 = 727
727 * 1000 / 1024 = 709
709 - 500 = 209
Braucht man keine Fließkommas, super. Hast du 20,9°C in der Bude? ;-)

Denk mal, ich geh so vor:
Ich werf alle Sekunde den TSIC an, und lass ab kurz danach den PCINT mit 
dem Timer von fallende bis steigende Flanke die Bits bestimmen. Erster 
Wert ist Refferenz, die andern vergleich ich auf länger-kürzer. Lässt 
sich bestimmt leichter programmiern, als die Portabfrage nach 
Refferenzzeit.

Wenn ich die Bilder seh, geht es 20 mal runter und 20 mal rauf. Sind 20 
Bits. Kann ich ja nach 20 Bits im PCINT den TSIC wieder ausschalten.

Nächste Sekunde hol ich mir die Bits und lass das Ganze wieder losgehen.

Wirklich easy!


So schnell soll die Tempraturmessung ja nicht sein, wenn MSP da recht 
hat. Kann mans bestimmt sein lassen, das zweite Startbit als Reffernz zu 
nemen. Schmeiß ich hinterher raus.

Noch paar Fragen.
Komisch daß in der Zackwire-PDF 65-85ms nach einschalten steht. Auf den 
Bildern sinds ja nur schlappe 40 ms. Na Egal, ist viel kleiner als meine 
Sekunde und der PCINT hat solange nichts zu tun.

Sind die 125µs so ungenau? 8MHZ /64 = 125kHz = 8µs beim Timer0 müssten 
doch reichen.

Muss ich 40 mal im PCINT kurz kucken welche Flanke war und Timer0 
auslesen und vergleichen oder reseten. Was für 30 Berechnungen im PCINT 
machen MSP Angst?
Das berechnen mach ich im Hauptprogramm, hat noch Reserve dafür.


Schönen Dank schon mal,
meld mich morgen wies klappt.
Sonnabens ist ja Zeit zum probiern.

Oha, die 39 ms Reaktionszeit bei "bingo (Gast)" sind überraschend, das 
Bild sieht aber überzeugend aus. Habe dem Datenblatt mit 65...85 ms 
vertraut.

Die Bilder sind wirklich gut fürs Verständnis! - Danke, "bingo (Gast)"!
Wie "Knetling" schreibt, liest man das ZacWire.PDF und ist danach noch 
etwas unsicher...

Die Reaktionszeit hat bei mir aber keinen Einfluss, da der Interrupt vom 
TSIC solange nicht stört. Nur doof, wenn eine Warteschleife zu lange 
wartet...

Was macht ihr da für umständliche Sachen mit Polling, oder 
Timerinterrupt nach jeder Flanke starten und nach irgendwelchen Zeiten 
scharfschalten?

Ich gehe da etwas praktischer ran:

Der Interrupt fürs TSIC-Signal und der freilaufende Timer sind sowieso 
im Geschäft, also:

TSIC-negative Flanke: Timer-Reset,
TSIC-positive Flanke: Timer auslesen.

Startbit erkennen: Nach Einschalten kein Problem, sonst lange Pause 
(Timer-Overflow) auswerten.
Zur Not auch noch 3..4 Befehle für Plausibilität in den Interrupt 
einbauen (1/2 µs @ 8 MHz).

Startbit - positive Flanke: Zeit als T-Referenz erfassen.
Weitere Bits - positive Flanke: Vergleich mit T-Referenz und als logisch 
0, oder logisch 1 in 2..3 reservierte Bytes reinschieben.

(Hab ich alles schon vor einer Woche geschrieben...)

GENAU SO ist es "voll easy"!


"Knetling" hat offenbar einen ähnlichen Weg eingeschlagen.
Schaun wir mal...


Für die, die keine DÜNNBRETTBOHRER sind:

Man könnte sich noch überlegen, ob überhaupt 3 Bytes für die erfassten 
Bits nötig sind.

Nur 2 Bytes: Es würden nur 5 Bit vom Hi-Byte, Hi-Parity, das 2. 
Startbit, 8 Bits vom Lo-Byte und Lo-Parity erfasst. Vom Hi-Byte sind 
aber nur 3 Bit aktiv, davor sind 5 konstante NULL-Bits.

Wenn ich die Parity-Bits auswerte, muss ich einfach die 3 fehlenden 
oberen Hi-Bits als empfangene NULLen annehmen. Die Parity-Auswertung 
wird da leicht "beschummelt". Das Parity-Bit geht aber auch davon aus, 
dass diese Bits NULL sind - und kann sowieso nie sagen, welches Bit 
fehlerhaft ist. Nach meiner Einschätzung hat diese Einsparung keinen 
Einfluss auf die Datensicherheit. Weiß es jemand besser?

> Oha, die 39 ms Reaktionszeit bei "bingo (Gast)" sind überraschend, das
> Bild sieht aber überzeugend aus. Habe dem Datenblatt mit 65...85 ms
> vertraut.

Die Zeit zwischen Einschalten und dem ersten Startbit ist tatsächlich 
nur etwa 30-45 ms. Ich habe in den letzten Jahren mehr als 20 TSIC 
verbaut (Hygrosens), alle getestet, alle lagen zwischen 30 und 42 msec. 
Zeiten wie in den Datenblättern habe ich nie erlebt, ich habe allerdings 
nicht unter -10°C oder über +50°C gemessen.

Jau, läuft schon!

Tausend Dank schon mal!

Hab es nach Bernies Tip mit nur zwei Emfänger-Bytes gemacht.
Und noch die Tempratur auf die Anzeige, passt gut zum Thermometer.
Die Steuerung klappt wie vorher - naja die muss auch nur alle 8ms 
reagiren und der PCINT braucht immer viel weniger wie 10µs.

Benützt ihr die Paritys? Ich schieb die und das 2. Startbit einfach 
raus.

Läuft superstabil, hab aber noch die Woche bißchen Zeit. Hey MSP, wie 
brauchst du nur ein Interupt für jedes Bit? Mein PCINT kommt aber immer 
auf jede Flanke. Und den USART brauch ich aber schon um für die 
PC-Verbindung.

Freut mich, dass du fast von allein, zu einer ähnlichen recht effektiven 
Lösung gekommen bist. Bin aber nicht sehr überrascht: Es bietet sich 
doch einfach an, wenn man das TSIC-Protokoll verstanden hat und es 
resourcensparend umsetzen will.

Wir verschwenden allerdings zwei Interrupts pro Bit!

Wenn ich den einen kryptischen Beitrag von "MSP (Gast)" richtig 
entschlüsselt habe, macht er es recht umständlich, um nur einen 
Interrupt pro Bit zu brauchen:

1) Irgendwie das Startbit abwarten,
2) dessen Low-Zeit (halbe Bitdauer) mit Timer messen,
3) schnell den Timer umdefinieren, dass er mit der doppelten Zeit einen 
Interrupt liefert, der dann hoffentlich (!) immer die Bitmitte trifft.

Wäre mir zu unsicher: Die Erfassung (mit 1 MHz) kann leicht 1,5 µs 
danebenliegen. Macht 3 µs pro Bit, die sich aufsummieren. Nach 19 
weiteren Bit sind das 57 µs = fast eine halbe Bitzeit. Totaler Murks!

Also den ganzen Aufwand für das zweite Byte nochmal! Selbst dann ist es 
für die erforderliche Genauigkeit von 1/4 Bitdauer HOFFENTLICH nur nah 
der Grenze. Aufwändig, aber unsicher!

Vielleicht komm ich nicht drauf und er hat das Ei des Kolumbus gefunden? 
- Aber "MSP (Gast)" bevorzugt leider die Kritik an anderen, gegenüber 
eigenen nachprüfbaren Vorschlägen.


Zum Temperatureinfluss habe ich mir ein paar überschlägige Gedanken 
gemacht:

Mit der Einschaltung 1 mal pro Sekunde sieht es gut aus!

Typische TO92-Transistoren haben einen R_th von 0,2 K/mW zu ruhender 
Luft.
Wird beim TSIC mit dieser Bauform ähnlich sein.

Datenblatt TSIC: < 0,1 mA bei 3,3 V  ->  < 0,33 mW.
Macht < 0,33 mW * 0,2 K/mW = < 0,07 K

Also knapp 0,1 °C zu viel bei Dauerbetrieb an 3,3 V.
Bei 1/10 Einschaltzeit < 0,01 °C. (Das sieht der TSIC nicht.)

Eine pessimistische Schätzung für 5 V sei 0,2 mA = 1 mW.
Ich messe 15 mV an den vorgeschlagenen 220 Ohm (+ 100 nF nach Masse), 
etwa 0,07 mA...

Also wahrscheinlich unter 0,2 °C Fehler bei Dauerbetrieb an 5 V.
Bei 1/10 Einschaltzeit unter 0,02 °C. (Jenseits der Auflösung des TSIC.)

Hi

>Wäre mir zu unsicher: Die Erfassung (mit 1 MHz) kann leicht 1,5 µs
>danebenliegen. Macht 3 µs pro Bit, die sich aufsummieren. Nach 19
>weiteren Bit sind das 57 µs = fast eine halbe Bitzeit. Totaler Murks!

Unsinn. Mit jeder fallenden Flanke beginnt das Spiel vorn. Da summiert 
sich nichts.

MfG Spess

Hey Spess, von dir bin ich aber klügere Beiträge gewohnt!

Hier geht es um die benötigten Interrupts pro Bit bei ZacWire.
"MSP (Gast)"  behauptet, dass man es mit EINEM Interrupt pro Bit 
schafft.

Um die fallende Flanke zu erfassen, brauch ich einen Interrupt, oder
zeitintensives Polling.

Um den Bitwert (den duty cycle) zu erfassen, brauche ich einen 
Timer-Interrupt, oder einen Interrupt von der positiven Flanke, oder 
zeitintensives Polling.

Wenn Polling nicht in Frage kommt, weil der µC noch anderes zu erledigen 
hat, verbleiben ohne Hexerei immer ZWEI Interrupts pro Bit.

Hab noch gegrübelt, ob es mit Timer-Capture oder so besser wird. Wird 
nur mehr Aufwand.

Die Software UART so ungenau laufengelassen, ist mir zu 
fehlerfreundlich. Und die wie Spess53 auf jedes Bit zu synchronisieren, 
kostet gleichen Aufwand wie die Messung von fallende auf steigende 
Flanke.

was meckert MSP nur immer rum? Und die eigene Idee müssen ihm noch 
andere hinschreiben.

Was solls! Es funktoniert sauber, jetzt auch mit Paritys.

Danke Jungs!

Evtl. hilft es ja jemanden weiter oder kann es wer gebrauchen..
Hab mir mal ein mit Thermometer zusammen gebaut, funktioniert immernoch 
einwandfrei... Habe für die Anzeige Schieberegister mit 7 Segmentanzeige 
verwendet. Der Mega lief glaub ich mit meinen Code auf 4Mhz. Wenn man 
die Frequenz verändert muss man glaub ich ein wenig an der Stelle zum 
messen der Strobe-Zeit herumbasteln...
Nicht schimpfen, war mein erstes Lernprojekt. Hatte vorher 0 Ahnung vom 
Programmieren und hatt das in 3 Wochen fertig...
Evtl. ist das eine oder andere nicht so optimal, aber fürs erste mal...
Und es funktioniert :)

Hier mal der Code:

1

.include "m8def.inc"

2

3

4

.def  temp1      = r16

5

.def  temp2      = r17

6

.def  temp3      = r18

7

.def  tsicwert_low  = r19

8

.def  tsicwert_high  = r20

9

.def   Digit1        = r21

10

.def   Digit2        = r22

11

.def   Digit3        = r23

12

.def  null      = r24

13

.def  portstatus    = r25

14

15

16

.equ SCHIEBE_DDR  = DDRD

17

.equ SCHIEBE_PORT = PORTD

18

.equ Rclock       = 2

19

.equ Clock        = 1

20

.equ Data         = 0

21

22

23

24

25

; Die Port Pins auf Ausgang konfigurieren

26

27

    ldi   temp1, (1<<Rclock) | (1<<Clock) | (1<<Data) ; Anm.1

28

    out   SCHIEBE_DDR, temp1

29

30

31

    ldi   temp1, HIGH(RAMEND)

32

    out   SPH, temp1

33

  ldi   temp1, LOW(RAMEND)    ; Stackpointer initialisieren

34

    out   SPL, temp1

35

36

37

38

  ldi  temp1,0b00000000    

39

  out  ddrc,temp1          ; Port C als Eingang Initialisieren

40

41

42

;___________________________________________________________________________

43

;___________________________________________________________________________

44

45

main:

46

47

;  rcall read_tsic

48

;  rcall calc

49

;  rcall convert

50

;  rcall write_data

51

;  rjmp  main

52

53

54

;___________________________________________________________________________

55

;___________________________________________________________________________

56

57

read_tsic:

58

59

daten:

60

61

  clr digit1

62

  clr digit2

63

  clr digit3

64

  clr tsicwert_high

65

  clr tsicwert_low

66

67

  ldi    temp2, 8        ;Wieviele Bits müssen gelesen werden?

68

  ldi    temp3, 0b00000010

69

  ldi    null,    0b00000000

70

  rjmp   warten

71

72

73

74

75

76

77

;____________________________________________________

78

79

;                     warten

80

81

82

warten:

83

    ldi    temp1, 100

84

    sbis   pinC, 0

85

    rjmp   warten

86

87

count:

88

89

    dec   temp1

90

    brne   control

91

    rjmp  start

92

93

control:    

94

95

    sbic  pinC, 0

96

    rjmp   count

97

    rjmp   warten

98

99

;____________________________________________________

100

101

;             start Byte1

102

103

start:

104

105

    sbic   pinC, 0      ;warten bis fallende Flanke bei Startbit kommt

106

    rjmp   start

107

108

strobe:

109

110

    out   tccr0, temp3    ;timer bei fallender Flanke von Startbit einschalten

111

112

strobe2:

113

    sbis  pinC, 0

114

    rjmp  strobe2      ;Strobe-Zeit messen

115

    in    temp1, tcnt0

116

    push  temp1

117

    out   tccr0, null

118

    out    tcnt0, null

119

120

strobe3:

121

122

    sbic  pinC, 0

123

    rjmp  strobe3      ;warten bis fallende Flanke kommt

124

125

strobecount:

126

    dec    temp1

127

    nop

128

    nop

129

    nop

130

    brne  strobecount

131

132

    in    portstatus, PinC    ;Portstatus nach abgelaufener Strobezeit abfragen

133

    ror    portstatus

134

    brcs  bitcount1

135

    rjmp  bitcount0