Hallo,Ich verzweifle gerade am ds18s20. Ich weiß es gibt viel funktionierenden code und viele Beiträge aber das richtige habe ich nicht gefunden. Ich bekomme immer 0XF0 angezeigt.Programm hängt nirgends. Ich wollte auch nicht einfach was kopieren. Ich lese in temp1 und gebe das auf LCD aus. Ich häng mal meinen code an.
Ich hab leider kein Speicheroszi,aber die timings müssten stimmen, vielleicht auch nicht,habe ich eine Chance ohne Speicheroszi???? Alle anderen Zeitfunktion stimmen scheinbar. Der Atmega läuft mit 16MHZ. Ich verstehe nicht warum ich immer nur 0xF0 bekomme,scheinbar läuft die reset prozedur durch ,da die led Leuchtet(PORTC,0). Ich habe vergessen zu sagen das ich wenig Programmierkenntnisse habe und die auch nur in Assembler.
Hallo Andre, schau Dir das mal an: http://www.nord-com.net/thomas.neveling/Elektronik_Basteln/LED_Thermometer/led_thermometer.html ist ebenfalls in Assembler, nur auf die Grundfunktion beschränkt und recht gut kommentiert. Vielleicht hilft dir das.
andre schrieb: > Ich habe vergessen zu sagen das ich wenig Programmierkenntnisse habe und > die auch nur in Assembler. Auch wenn Moby das jetzt nicht gerne hört. Aber gerade weil du wenige Programmierkentnisse hast, ist Assembler nicht das richtige. Es gibt viel zu viele Nebenschauplätze, die du berücksichtigen musst. Wo ist Moby eigentlich? Auch wenn unsere militanten Assembler Verfechter meistens bei Assembler Fragen konsequent durch Abwesenheit glänzen, ist er schon des längeren nicht mehr hier aufgetaucht. 'Optimiert' er wieder irgendeinen 10-Zeiler?
:
Bearbeitet durch User
andre schrieb: > habe ich eine Chance ohne Speicheroszi???? Ein kleiner Logikanalysator für weniger als 10€ würde dir genauso gut weiter helfen. Eine Ebay-Suche nach "8CH 24MHz" hilft dir weiter ;-)
Karl H. schrieb: > Auch wenn Moby das jetzt nicht gerne hört. Aber gerade weil du wenige > Programmierkentnisse hast, ist Assembler nicht das richtige. Es gibt > viel zu viele Nebenschauplätze, die du berücksichtigen musst. Bullshit. Gerade genau das Gegenteil ist der Fall. Bei Assembler kann man sich (meistens) darauf verlassen, daß genau das passiert, was man hingeschrieben hat. Man muß dazu nur die relativ wenigen und relativ leicht verständlichen Assemblerinstruktionen der Zielarchitektur kennen. Bei C hingegen muss man den ganzen Schwachsinn einer schon beim Entstehen recht perversen Programmiersprache kennen und dazu noch all die "Verbesserungen" die sie in den letzten 30 Jahren erfahren hat. Und als wäre das nicht schon genug: man muß auch noch die spitzfindigen Häkeleien des konkret verwendeten Compilers in seine Überlegungen einbeziehen. Alles zusammen Stoff für viele hundert Seiten gedruckten Materials. Nur leider nicht alles für lau zu haben. Manches (z.B. die Interna des unsäglichen avr-gcc) gibt es nichtmal für viel Geld als Druckwerk. Man darf sich das teilweise abstruse Verhalten aus den Quelltexten selber zusammensuchen. Was nur möglich ist, wenn man die C-Grundlagen aus dem FF beherscht UND obendrein einigermaßen erfahren ist im Umgang mit der ganzen fürchterlichen C-Misere. Die Komplexität ist ganz sicher um ein Vielfaches höher als zur Beherrschung desselben Problems in Assembler. Denn dort hat man effektiv nur damit zu tun, die Hardware zu meistern. Das muß man aber auch in C. Und zwar ZUSÄTZLICH zu dem ganzen, völlig nutzlosen C-Rotz...
Karl H. schrieb: > Auch wenn unsere militanten Assembler Verfechter meistens bei Assembler > Fragen konsequent durch Abwesenheit glänzen, ist er schon des längeren > nicht mehr hier aufgetaucht. 'Optimiert Also weder bin ich Moby, noch militant. Aber als jemand der gerne Assembler "verfechtet", da wo es Sinn macht fühle ich mich schon angesprochen. Ich gehöre aber auch zu denen die keine Lust haben unentgeltlich für jemanden kompletten Code zu analysieren. Sei es C, oder Assembler. Ich denke schon das jeder sein Problem selber auf einige Zeilen Code einkreisen können sollte. Zumal es gerade im Zusammenhang mit nicht völlig unkomplexer und timing kritischer HW Anbindung und selbstgebastelter HW nicht damit getan ist sich lediglich mal den Code anzuschauen. Die Fehlerquellen sind da einfach zu zahlreich.
Also ich besorge mir einen logikanalyzer und werde weiter probieren. Ich habe in der zwischenzeit einen Arduino sketch getestet der funktioniert,also muß die Hardware soweit in Ordnung sein. Ich kann verstehen das hier nicht unentgeltlich weitergeholfen werden will,aber ich bin reiner hobbyist und lerne mit microcontroller umzugehen.Mit Hardware hab ich kein Problem aber Software.....
> keine Lust ... kompletten Code ...
Selbst wenn man Lust hätte, wäre es nicht möglich, denn das vorgestellte
Programm ist ja mitnichten komplett, es ist nur ein Fragment, in welchem
z.B. die Warte-Routinen fehlen, dann nützt auch die Angabe des
Systemtaktes nichts; desgleichen fehlen sämtliche Definitionen der Pins.
Und schlecht lesbar ist das Ganze obendrein, eingerückt wie Kraut und
Rüben, Groß- und Kleinschreibung nach Belieben. Etwas mehr Mühe könnte
sich auch ein "reiner Hobbyist" geben.
Was aber den Beitrag von Karl Heinz Buchegger betrifft - na, da habe ich
schon bessere von ihm gelesen.
andre schrieb: > Ich kann verstehen das hier nicht unentgeltlich weitergeholfen werden Keine Sorge. Es wird hier in der Regel immer unentgeltlich geholfen. Ich persönlich tue das nicht bei langen Quelltexten. Es gibt aber genügend Leute hier denen die Profilierung Lohn genug ist. Also vielleicht analysiert ja noch jemand den Code und sagt dir wo der Fehler ist.
S. Landolt schrieb: > sämtliche Definitionen der Pins. > Und schlecht lesbar ist das Ganze obendrein, eingerückt wie Kraut und > Rüben, Groß- und Kleinschreibung nach Belieben. Etwa ....ich gebe zu, ich lese nicht mal wirklich was da steht, wenn mir der erste Blick zeigt dass da mehr als 10 Zeilen stehen und es wie Kraut und Rüben aussieht....
> Leute hier denen die Profilierung Lohn genug ist
Mag sein. Ich persönlich verspreche mir eher Erkenntnisgewinn; ein
Fehler, den ich heute für einen Anderen analysiere, könnte in naher
Zukunft mein eigener sein.
Ich habe nochmal überarbeitet.Nur zum schöner lesen und den rest angehängt. Funktioniert aber immer noch nicht.
1 | ldi temp1, HIGH(RAMEND) |
2 | out SPH, temp |
3 | ldi temp1, LOW(RAMEND) ; Stackpointer initialisieren |
4 | out SPL, temp |
Nanu: temp1 <-> temp Spielt wohl keine Rolle, aber delay_1us dauert (bei 16 MHz) incl. Aufruf 1.8125 us.
1 | ONE_WIRE_DATA_READ_BIT: |
2 | ... |
3 | cbi DS_DDR,DS18b20 ; AUF EINGANG |
4 | rcall delay_15us |
5 | ... |
Sind die 15 us nicht zu lang? Ich hätte eher 5 us erwartet, Zitat Datenblatt: "Therefore, the master must release the bus and then sample the bus state within 15 us from the start of the slot."
c-hater schrieb: > Karl H. schrieb: > >> Auch wenn Moby das jetzt nicht gerne hört. Aber gerade weil du wenige >> Programmierkentnisse hast, ist Assembler nicht das richtige. Es gibt >> viel zu viele Nebenschauplätze, die du berücksichtigen musst. > > Bullshit. Quatsch nicht. Analysier den Code und such ihm das Problem.
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.