Hallo,
Ich habe den DS1820 Temperatur Sensor mit einem SMT32 zum Laufen
bekommen. Für das Bit Timing benötigt man ja delays. Dafür kann man
delay_us() benutzen oder mit Interrupts die Wartezeiten realisieren.
Meine Frage ist, ob man da prinzipiell drauf verzichten kann? Also dass
ich eine Funktion "start_temp_conversion()" aufrufe, die an sich fast
keine Zeit benötigt und nur den ganzen Ablauf antriggert. Das Senden und
Empfangen kann ja im "Hintergrund" über Interrupts ablaufen. So habe ich
den Vorteil, dass ich im Code was anderes machen kann und später - nach
der erfolgreichen Konversion - einfach die Temperatur aus eine Art
Buffer lesen kann.
Leider weiß ich nicht, wie man da am geschicktesten vorgeht. Gibt es da
Beispiele zu? Oder hat jemand Quellen, wo ich mich dazu schlau machen
kann? Ist das überhaupt eine übliche Vorgehensweise oder gibt es da noch
einen besseren Weg?
Hallo,
vom Prinzip geht das schon, du musst halt mal prüfen/ausrechnen ob sich
das Timing des 1W mit Timerinterrupts einhalten lässt (max. Verzögerung
zw. auslösen des INT und Ausführung der entsprechenden Routine).
Wenn das geht musst du in Variablen den Zustand festhalten wo du beim
letzten INT warst damit du beim nächsten weißt wo's weitergeht und wann
du fertig bist.
Sascha
Da bei onewire die Zeiten recht kritisch sind, wird es wahrscheinlich
schwierig das auf Interrupt umzustellen. Hast Du ein Oszilloskop zur
Hand?
Wie oft fragst Du denn Deine Tempeartur ab?
Und von welchen Delays reden wir? Von den 'Bitdelays' oder den
Verzögerungen zwischen zwei Tranfers.
Letztere lassen sich mit einem Scheduler oder einem RTOS ganz gut
anderweitig nutzen...
Per Interrupt gesteuertes Timing von wenigen µs dürfte zwar machbar
sein, aber da muss man dann schon ein wenig drauf achten, wann man
Interrupts wie lange sperrt. Der betreffende Interrupt sollte höchste
Priorität haben und Interrupts sperrt man besser nicht global, sondern
per Priorität (siehe BASEPRI_MAX).
Allerdings kann man Kompromisse eingehen. So kann man die kritische Zeit
eines 1-Wire Bits mit aktiven Delays abwickeln, also im 1-16µs Bereich,
und den Rest per Interrupt. Ich habe das bei einem AVR so gemacht, auf
dem ein RTOS mit 10 kHz getaktet wird. Zwischenbit- und Reset-Delays
erledigt das RTOS. Der Bitabstand liegt dann bei mindestens 100µs, aber
das stört weder mich noch 1-Wire.
Nochmal: UART. Kostet halt 2 Pins, dafür kann aber alles im Hintergrund
durch Interrupts erfolgen ohne dass man sich um das Timing sorgen machen
müsste.
Ich gehe mal davon aus, dass der STM32 sich in dieser Hinsicht nicht
negativ von den PIC(16..32) unterscheidet.
https://www.maximintegrated.com/en/app-notes/index.mvp/id/214
1N 4. schrieb:> Nochmal: UART. Kostet halt 2 Pins, dafür kann aber alles im Hintergrund> durch Interrupts erfolgen ohne dass man sich um das Timing sorgen machen> müsste.
Ja genau deswegen ist mir auch die Idee gekommen, dieses Prinzip bei dem
1-wire Protokoll anzuwenden. Da ich jetzt aber die DS1820 Sensoren
verwenden möchte, fällt die Lösung leider weg.
Mike schrieb:> Ja genau deswegen ist mir auch die Idee gekommen, dieses Prinzip bei dem> 1-wire Protokoll anzuwenden. Da ich jetzt aber die DS1820 Sensoren> verwenden möchte, fällt die Lösung leider weg.
Wohl Missverständnis. Man kann mit einer UART das 1-Wire Protokoll
implementieren. 0xFF ausgeben ist ein kurzes Bit, 0x00 ausgeben ein
langes, oder so in der Art. Gegenrichtung ähnlich.
Ein PIC18 klappert hier per UART ~40 DS18B20 Sensoren ab und langweilt
sich.
2 Pins, 1 Diode, 1 Pullup. Wenn man einen Strong Pull Up für Parasite
Power will, brauchts halt noch einen GPIO.
@Mike (Gast)
>> Nochmal: UART. Kostet halt 2 Pins, dafür kann aber alles im Hintergrund>> durch Interrupts erfolgen ohne dass man sich um das Timing sorgen machen>> müsste.>Ja genau deswegen ist mir auch die Idee gekommen, dieses Prinzip bei dem>1-wire Protokoll anzuwenden. Da ich jetzt aber die DS1820 Sensoren>verwenden möchte, fällt die Lösung leider weg.
Er meint, den UART über Tricks als Hardwaremodul für Onewire zu nutzen,
so wie es auch echte Hardwaremodule für UART, SPI, I2C, CAN etc. gibt.
Ich würde SPI nehmen, denn dort kann man einen Transfer starten, der ein
Datensignal zum rechten Zeitpunkt abtasten kann, ganz ohne CPU Arbeit
und delays. Aber auch dann wird man um kleine Delays im 2stelligen us
Bereich nicht herum kommen, dazu braucht man ein echten OneWire
Hardwaremodul.
@1N 4148 (1n4148)
>Wenn der UART das Timing erledigen kann, weshalb dann SPI nehmen? In der>App-Note von Maxim ist das wunderbar erklärt...
Hast recht, hab ich aber erst jetzt gelesen ;-)
A. K. schrieb:> Wohl Missverständnis. Man kann mit einer UART das 1-Wire Protokoll> implementieren. 0xFF ausgeben ist ein kurzes Bit, 0x00 ausgeben ein> langes, oder so in der Art. Gegenrichtung ähnlich.
Daran habe ich garnicht gedacht. Danke Dir! Ich habe dazu gerade ein
Application Note von maxim gefunden. Sieht sehr vielversprechend aus.
Für die, die es interessiert:
https://www.maximintegrated.com/en/app-notes/index.mvp/id/214
Stm32 Uart kann Half-Duplex und Open-Drain. Damit langt der eine UART TX
Pin fuer OWI. Ebenso kann man auch einen der 2-Kanal Timer nehmen und
braucht auch nur einen Pin. Beispiele in Ethernut SVNhttp://www.ethernut.de/en/download/index.html und dann nut/app/owibus
Eine Möglichkeit ist auch, das 1-wire als Statemaschine zu
programmieren.
D.h. je State macht man nur Reset bzw. ein Bit.
Dann hat man max 480µs/60µs Delay je Mainloop-Durchlauf.
Und die kritischen 15µs macht man unter Interruptsperre.
