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.
:
Bearbeitet durch User
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
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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.
Wenn der UART das Timing erledigen kann, weshalb dann SPI nehmen? In der App-Note von Maxim ist das wunderbar erklärt...
@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 SVN http://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.
:
Bearbeitet durch User
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.