Hallo! Ich will einen DS18S20 temp. sensor via 1-Wire an einen MSP430 anschließen. Gibt es jemanden, der 1-Wire mit nem MSP schon realisiert hat? Danke für Antwort nebenbei: MSP430 und Manchaster?
Gast
#1336788
Ne mit einem MSP430 nicht aber über I2C mit einem TMS320F28335
Ich hab 1-Wire gemacht, spreche da die DS2482 EEPROMS an, klappt bestens. leider darf ich dir den Quelltext nicht geben, war halt auf Arbeit. Ist aber nicht sonderlich schwer. Ich hab mir eine Delay-Routine geschrieben, mit mit Timer-Ticks arbeitet, so bekommt man die Zeiten vernünftig hin. Manchester musst du schon selbst kodieren, die Hardware USART kann das nicht.
Hab schon mal ein DS18B20 mit MSP gemacht. Quelltext müsste ich erst suchen. Aber wie Christian schon geschrieben hat, ist es nicht sonderlich schwer. DS18B20 an MSP430F149 war damals mein Einstieg in die µC Programmierung :)
Gast
#1337522
Wenn wir vom gleichen Schaltkreis reden, dann ist der DS2482 ein Brückenschaltkreis von I²C auf 1-wire und kein EEPROM. Vorteilhaft finde ich den Einsatz des DS2482 zur Anbindung eines DS18B20, weil man die 1 wire Verbindung nicht programmieren muss, da das gesamte Zeitregime vom DS2482 erzeugt wird. Trotzdem würde mich der Quellcode von Jörg interessieren, da dadurch dann der zusätzliche IS DS2482 entfallen könnte. MfG
Oha, da hab ich die Nummern durcheinander geworfen. Diese Brücke war in einem anderen Projekt (aber auch am MSP430). Den DS2431 haben wir direkt am MSP430 betrieben. Das ist ja alles keine Hexerei, das hat man auch ohne Quelltext Vorlage in 2 Stunden zusammen.
Der Source-Code für DS18B20 an MSP430. Die Rückgabe der Temperatur ist etwas "eigenwillig". Müsste man sich anpassen wenn einem das nicht passt. War damals für eine Applikation bei der das Format so günstig war.
Und die h-Datei.. Edit: Mir ist aufgefallen das einige Kommentare der Parameter in der C-Datei nicht stimmen, ich hoffe das ist zu verschmerzen :)
Danke erst mal für die Antworten. @Jörg: gibt es auch ein main-Programm, was die Routinen aufruft? (um mal zu verdeutlichen, wie solch eine Abfrage der Temperatur in Gang gesetzt wird.) ps: der code ist für einen ds18b20 wenn ich einen ds18s20 nehmen will, geht das auch ohne große Anpassung oder?
Im einfachsten Fall (ohne Adresse):
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
>ps: der code ist für einen ds18b20 wenn ich einen ds18s20 nehmen will, >geht das auch ohne große Anpassung oder? Ich kenn den Unterschied nicht. Aber großartig werden die sich wohl nicht unterscheiden.
Gast
#1337996
@Jörg Danke für den Quelltext Als nicht allzu stark bewanderter „Programmierer“ noch einige Fragen dazu: Wie schon in meinem vorigen Beitrag angedeutet, bereitet mir die exakte Erzeugung von Zeitabständen (delay) Probleme. Was bedeutet /* Delay (SMCLK @ 4MHz) */ // diese Zeile habe ich verstanden #define DELAY_500_US 500u #define DELAY_75_US 70u #define DELAY_60_US 58u #define DELAY_15_US 5u #define DELAY_SHORT 1u Wie kommt man zu den angegeben Zeiten? was bedeutet 1u, 5u, Bei Schleifen, wie z. B. void delay (unsigned int time); muss ich dann immer den Oszi nehmen, um die Impulslänge zu bestimmen. Deshalb wäre ich mal an einer programmiertechnischen Lösung interessiert. MfG
Wolfgang-G schrieb: > /* Delay (SMCLK @ 4MHz) */ // diese Zeile habe ich verstanden > #define DELAY_500_US 500u > #define DELAY_75_US 70u > #define DELAY_60_US 58u > #define DELAY_15_US 5u > #define DELAY_SHORT 1u > > was bedeutet 1u, 5u, Das u bedeutet einfach nur 'unsigned'
Wolfgang-G schrieb:
> Wie kommt man zu den angegeben Zeiten?
Im Code ist das ja1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
Er wird sich das entweder so wie du mit dem Oszi ausgemessen haben oder aber er hat sich den Assembleroutput des Compilers angesehen, Taktzyklen gezählt und die Zahlenwerte bei 4Mhz festgelegt. Wobei: Jeder halbwegs gute Compiler wird in dieser Schleife den Sinn vermissen und seiner obersten Pflicht nachkommen: "Aus einem gegebenen Quelltext das Maximum an Laufzeit herauszuholen" und die Schleife einfach wegoptimieren, da sie ausser Laufzeit verbrutzeln nichts Sinnvolles macht. Das genau das, Laufzeit verbrutzeln, der eigentliche Sinn der Sache ist, erkennen Optimizer nicht. Tja und dann kommt das nächste Problem: Selbst wenn der Optimizer die Schleife drinnen lässt (zb weil er ausgeschaltet ist), hast du keine Gewähr, dass der Compiler in der nächsten Compiler-Release die Schleife exakt gleich umsetzt. Derartige Warteschleifen gehen daher nur dann zuverlässig, wenn man exakt den gleichen Compiler in exakt der gleichen Version mit den exakt gleichen Aufrufparamtern hat wie der Autor.
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.