Guten Abend, versuche gerade mit einem Dallas 1820 zu reden und habe damit keinen Erfolg. Die Timeslots werden dabei mit _delay_us(xx) generiert und ich frage mich langsam ob das überhaupt zu Ziel führt. Ein Interrupt im µs-Bereich ist zu schnell, unter C und GCC ist der Atmega dann nur noch in der ISR und hängt da fest. Vielleicht ist ja auch etwas ganz anderes an meinem Ansatz falsch, hab mal die .c & .h angehangen. Atmega32, GCC, Geany, AvrDude, DS1820(nicht 18x20!) werden verwendet. Jens
:
Verschoben durch Moderator
P.S.: Versuche den RomCode auszulesen bekomme aber nur 8x255
Ich habe gerade vor einer Woche die Lib von Falk Brunner ausprobiert und sie ging! Siehe: Beitrag "Re: Onewire + DS18x20 Library" Da ist alles dabei, was man braucht. Habe sie als Grundlage für einen WS2000-Wetterstationssensor hergenommen. Hast du die CPU-Frequenz richtig definiert? #define F_CPU 16000000UL
:
Bearbeitet durch User
Um die Ausgangsfrage zu beantworten: die Delay-Funktionen funktionieren mit Assemblerschleifen, nicht mit Interrupts, und sind auf einen CPU-Zyklus genau. Oliver
Jens N. schrieb: > versuche gerade mit einem Dallas 1820 zu reden Wenn du dir dabei soviel Mühe gegeben hast wie bei der Auswahl der Rubrik hier im Forum (Markt), dann wundert mich nichts. ;)
Abend, die F_CPU ist definiert. Vor dem Zugriff auf den 1820 schalte ich die Interrupts mit cli() aus. Die Lib von Falk Brunner ist leider in cpp, das kann und verstehe ich nicht, eigentlich schade, hätte auch gern mal ein Bier mit Falk getrunken...
Ja, Rubrik Markt ist natürlich falsch, kann das wer verschieben?
Hast du das hier beachtet, steht als Note in der Beschreibung der Funktion delay_us: In order for these functions to work as intended, compiler optimizations must be enabled, and the delay time must be an expression that is a known constant at compile-time. If these requirements are not met, the resulting delay will be much longer (and basically unpredictable), and applications that otherwise do not use floating-point calculations will experience severe code bloat by the floating-point library routines linked into the application. Ach ja, die delay Funktionen funktionieren in der Regel sehr genau.
:
Bearbeitet durch User
Hey, die Optimierung ist an und ich übergebe an _delay_us() nur Zahlenwerte also weder eine Variable noch sonst irgentwas. Die _delay-Funktion geht bei mir auch sonst, allerdings habe ich damit noch nie ein so genaues Timing herstellen müssen. Ich dachte der GCC verfälscht da vielleicht etwas und man weis es nicht, so wie er ja wohl auch durch das speichern vom Statusregister vor ISRs die Interruptzeit verlängert ohne das man das sieht, mann muss es halt wissen.
Jens N. schrieb: > Die Lib von Falk Brunner ist leider in cpp, du bist ja richtiges talent - vielleicht doch besser briefmarken sammeln? der code ist mehr in c als alles andere!
Jens N. schrieb: > Die Timeslots werden dabei mit _delay_us(xx) generiert und ich frage > mich langsam ob das überhaupt zu Ziel führt. Hast du einen UART oder eine SPI frei? Da dann Pullup an RX/MISO und TX/MOSI über Schottky an RX/MISO. Das Verfahren ist in einer AppNote von Dallas/Maxim beschrieben, wie auch Falk hier Beitrag "Re: Onewire + DS18x20 Library" schrieb. Damit bist du dann komplett ohne Delays unterwegs. Die Statemachine für komplette Transfers (und Trigger für das Umschalten der Baudrate für den 'langen' Reset) müsste in der bisherigen Implementierung eh schon vorhanden sein. mfg mf
:
Bearbeitet durch User
Hallo, ja, SPI hätte ich abgesehen vom ISP noch frei, der USART muss nur empfangen. Aber es muss doch auch einfacher gehen und bei einer Temperaturwandlung einmal in der Minute stört es mich auch nicht wenn der Controller mal im Delay hängt.
Jens N. schrieb: > Die Lib von Falk Brunner ist leider in cpp, das kann und verstehe ich > nicht, Wenn ich das schaffe, die Lib nach C zu portieren, kannst du es auch schaffen. Ich habe da kein c++ drin gefunden. Oh doch, ich glaub, ich hab's durch "c=c+1" ersetzt ;-).
:
Bearbeitet durch User
Jens N. schrieb: > Die Lib von Falk Brunner ist leider in cpp, das kann und verstehe ich > nicht, > eigentlich schade, hätte auch gern mal ein Bier mit Falk getrunken... Da is nix in C++, nur olles C. Einzig und allein die Anwendung ist als Arduinocode geschrieben, aber auch dort ist praktisch kein C++ drin. Ja, die Dateien haben die Endung .cpp, es sind aber normale C-Dateien. Warum? Weil ich keine Ahnung von C++ und Arduino hatte und meine normalen .c Dateien nicht korrekt compiliert wurden. Also hab ich sie in .cpp umbenannt. Heute bin ich etwas schlauer und weiß, wie man .c Dateien in ein C++ Projekt einbindet.
:
Bearbeitet durch User
Jens N. schrieb: > Vor dem Zugriff auf den 1820 schalte ich die Interrupts mit cli() aus. Das is zwar prinzipiell richtig, aber nicht nötig, denn das machen die Funktionen schon selber.
Jens N. schrieb: > Aber es muss doch auch einfacher gehen Gibt es überhaupt Mikrocontroller mit nativer 1-wire Schnittstelle? Sonst eben so, in aufsteigender Reihenfolge der Einfachheit und Berücksichtigung, dass SPI noch frei: * (DS28E18 1-wire to SPI/I²C Bridge) Quark, ist falsch herum... rolleyes * LM74 SPI temperature sensor * NTC mit Pullup (umrechnen) * LM35 analog temperature sensor(10mV/°C) mfg mf
:
Bearbeitet durch User
Achim M. schrieb: > Gibt es überhaupt Mikrocontroller mit nativer 1-wire Schnittstelle? Ja! alle neuen ATtiny haben UART mit one-wire half-duplex Operation z.B. ATtiny412. Allerdings kann man auch mit jeder! UART im asynchron mode one-wire simulieren, dazu wird die Baudrate so gewählt, dass das Start/Stop Bit ins Protokoll Timing passt! Nur muss man, wenn kein OC IO-Port vorhanden ist, die Tx/Rx Ports extern "zusammenlegen".
Apollo M. schrieb: > Allerdings kann man auch mit jeder! UART im asynchron mode one-wire > simulieren [Loriot]Ach![/Loriot]
:
Bearbeitet durch User
Jens N. schrieb: > versuche gerade mit einem Dallas 1820 zu reden und habe damit keinen > Erfolg. Da du allerdings doch nicht der erste bist, der so etwas versucht, hilft vielleicht das hier weiter: https://www.informatik.htw-dresden.de/~beck/Atmel/USBDS1820/ Oliver
:
Bearbeitet durch User
https://www.mikrocontroller.net/index.php?title=AVR-GCC-Tutorial/Assembler_und_Inline-Assembler&action=edit§ion=6 Man muss nur in der .h Datei das hier einfügen. #ifdef __cplusplus extern "C" { #endif ... Dateiinhalt // Abschluss der Funktionsdeklaration in C++, z.B. für Arduino #ifdef __cplusplus } #endif Dann kann man die .cpp Dateien wieder in .c umbenennen und sie compilieren auch in der Arduino-IDE sauber. Oder man benutzt sie dann als normale C-Dateien in anderen IDEs bzw. Compilern.
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.