Forum: Mikrocontroller und Digitale Elektronik 1Wire wieviel MHz mindestens?!


von Tom (Gast)


Lesenswert?

Hallo,
nutze Mikroe (Pascal) für meinen Mega32 und 1wire...
Habe das Problem, das er mit 1Mhz keine 1Wire übertragung mehr macht..
Wieviel MHz benötigt 1Wire??Oder woran kann es liegen das er erst mit 
2Mhz anfängt den Sensor richtig auszulesen?

von Tom (Gast)


Lesenswert?

verdammt, der Controller muss wirklich mit 2Mhz laufen..was für eien 
Verschwendung :-(

"Der Master muss einen Takt von mindestens 1.8MHz aufweisen. Zudem muss 
die
Versorgungsspannung beim Master mit einem PullUp-Widerstand auf 5V 
hochgezogen
werden."

von (prx) A. K. (prx)


Lesenswert?

Tom schrieb:
> verdammt, der Controller muss wirklich mit 2Mhz laufen..was für eien
> Verschwendung :-(

Wenn man den 1-Wire Code befehlsgenau hindrechselt, dann geht es wohl 
auch mit 1MHz noch. Nur muss man dann eben Einzelbefehle für Timing 
verwenden, statt automatisch berechneter Delayloops, und dieser Code 
geht dann nur noch mit 1MHz, wird bei 2MHz scheitern.

: Bearbeitet durch User
von Tom (Gast)


Lesenswert?

habe keienrlei Delay loops drin bzw doch 180µs :-) aber auch ohne die 
klappt es bei 1Mhz nicht..also scheint es wirklich unter 1,8MHz nicht zu 
gehen

von Mike A. (Gast)


Lesenswert?

Tom schrieb:
> habe keienrlei Delay loops drin bzw doch 180µs :-) aber auch ohne die
> klappt es bei 1Mhz nicht..also scheint es wirklich unter 1,8MHz nicht zu
> gehen

Dann guck mal, was der Compiler aus deinem Pascal-Code gemacht hat. 
Wahrscheinlich ist da noch Luft drin.

von Tom (Gast)


Lesenswert?

hmmm...könnte sein, habe k.a. von asm...
sieht jedenfalls krass umständlich aus als das es der einfachste Weg 
sein könnte :-)
1
_Check_Temperature:
2
  PUSH       R28
3
  PUSH       R29
4
  IN         R28, SPL+0
5
  IN         R29, SPL+1
6
  SBIW       R28, 1
7
  OUT        SPL+0, R28
8
  OUT        SPL+1, R29
9
  ADIW       R28, 1
10
11
;x.mpas,570 ::     BEGIN
12
;x.mpas,573 ::     Ow_Reset(PORTB, 1);                                  // Onewire reset signal
13
  PUSH       R2
14
  PUSH       R3
15
  PUSH       R4
16
  PUSH       R5
17
  PUSH       R3
18
  PUSH       R2
19
  LDI        R27, 1
20
  MOV        R4, R27
21
  LDI        R27, #lo_addr(PORTB+0)
22
  MOV        R2, R27
23
  LDI        R27, hi_addr(PORTB+0)
24
  MOV        R3, R27
25
  CALL       _Ow_Reset+0
26
;x.mpas,574 ::     Ow_Write(PORTB, 1, 0xCC);                            // Issue command SKIP_ROM
27
  LDI        R27, 204
28
  MOV        R5, R27
29
  LDI        R27, 1
30
  MOV        R4, R27
31
  LDI        R27, #lo_addr(PORTB+0)
32
  MOV        R2, R27
33
  LDI        R27, hi_addr(PORTB+0)
34
  MOV        R3, R27
35
  CALL       _Ow_Write+0
36
;x.mpas,575 ::     Ow_Write(PORTB, 1, 0x44);                            // Issue command CONVERT_T
37
  LDI        R27, 68
38
  MOV        R5, R27
39
  LDI        R27, 1
40
  MOV        R4, R27
41
  LDI        R27, #lo_addr(PORTB+0)
42
  MOV        R2, R27
43
  LDI        R27, hi_addr(PORTB+0)
44
  MOV        R3, R27
45
  CALL       _Ow_Write+0
46
;x.mpas,576 ::     Delay_us(180);
47
  LDI        R16, 120
48
L__Check_Temperature241:
49
  DEC        R16
50
  BRNE       L__Check_Temperature241
51
;x.mpas,578 ::     Ow_Reset(PORTB, 1);
52
  LDI        R27, 1
53
  MOV        R4, R27
54
  LDI        R27, #lo_addr(PORTB+0)
55
  MOV        R2, R27
56
  LDI        R27, hi_addr(PORTB+0)
57
  MOV        R3, R27
58
  CALL       _Ow_Reset+0
59
;x.mpas,579 ::     Ow_Write(PORTB, 1, 0xCC);
60
  LDI        R27, 204
61
  MOV        R5, R27
62
  LDI        R27, 1
63
  MOV        R4, R27
64
  LDI        R27, #lo_addr(PORTB+0)
65
  MOV        R2, R27
66
  LDI        R27, hi_addr(PORTB+0)
67
  MOV        R3, R27
68
  CALL       _Ow_Write+0
69
;x.mpas,580 ::     Ow_Write(PORTB, 1, 0xBE);                            // Issue command READ_SCRATCHPAD
70
  LDI        R27, 190
71
  MOV        R5, R27
72
  LDI        R27, 1
73
  MOV        R4, R27
74
  LDI        R27, #lo_addr(PORTB+0)
75
  MOV        R2, R27
76
  LDI        R27, hi_addr(PORTB+0)
77
  MOV        R3, R27
78
  CALL       _Ow_Write+0
79
;x.mpas,582 ::     temp :=  Ow_Read(PORTB, 1);
80
  LDI        R27, 1
81
  MOV        R4, R27
82
  LDI        R27, #lo_addr(PORTB+0)
83
  MOV        R2, R27
84
  LDI        R27, hi_addr(PORTB+0)
85
  MOV        R3, R27
86
  CALL       _Ow_Read+0
87
  STS        _temp+0, R16
88
  LDI        R27, 0
89
  STS        _temp+1, R27
90
;x.mpas,583 ::     temp := (Ow_Read(PORTB, 1) shl 8) + temp;
91
  LDI        R27, 1
92
  MOV        R4, R27
93
  LDI        R27, #lo_addr(PORTB+0)
94
  MOV        R2, R27
95
  LDI        R27, hi_addr(PORTB+0)
96
  MOV        R3, R27
97
  CALL       _Ow_Read+0
98
  POP        R2
99
  POP        R3
100
  MOV        R19, R16
101
  CLR        R18
102
  LDS        R16, _temp+0
103
  LDS        R17, _temp+1
104
  MOVW       R20, R16
105
  ADD        R20, R18
106
  ADC        R21, R19
107
  STS        _temp+0, R20
108
  STS        _temp+1, R21

von Peter D. (peda)


Lesenswert?

Relevant ist der Code für bit_write und bit_read, der fehlt.
Alles andere ist unkritisch, zwischen den Bits dürfen beliebig lange 
Pausen sein.

von Tom (Gast)


Lesenswert?

hmm, k.a. von Bit_read sehe ich nichts.
Das ist die komplette Funktion soweit ich das überblicken kann

von Tom (Gast)


Lesenswert?

ich hätte gedacht das ist das
 LDI        R27, #lo_addr(PORTB+0)
  MOV        R2, R27
  LDI        R27, hi_addr(PORTB+0)

von Peter D. (peda)


Lesenswert?

Tom schrieb:
> CALL       _Ow_Write+0
> CALL       _Ow_Read+0

Diese Calls müssen ja irgendwo hingehen.
Und da müssen dann wiederum Calls zu den Bitfunktionen stehen.

von Uwe K. (ukhl)


Lesenswert?

Das ganze sollte auch mit 1 MHz klappen.
Ich habe es mit einem ATtiny13 mit 1,2MHz problemlos zum Laufen 
bekommen.
Auch auf einem ATmega8 klappt es auch hervorragend mit 1 MHz.

Allerdings habe ich es mit dem Atmel Studio mit GCC gemacht.

Peter hat Recht:
Prüfe man das Timing beim Lesen und Schreiben der Bits.
Ich vermute das die Delays bei langsamen Takt zu ungenau (länger) 
werden.
Kürze doch mal die Delays und zeige uns doch mal das Pascal-Programm.
Beim Lesen muss das Sampeln innerhalb von maximal 15 uS erfolgen. Aber 
mache es so schnell wie möglich (1 uS). Nicht unnötig herauszögern.
Bei Peters Library wird auch beim lesen 15 uS gewartet. Das klappt 
meistens, ist aber immer an der Grenze und sollte vermieden werden 
(sorry Peter, ansonsten eine super Library).

: Bearbeitet durch User
von GCC (Gast)


Lesenswert?

Eventuell kann der GCC auch wirklich optimieren. Das abgedruckt 
Pascal-Compilat dürfte State-of-the-Compiler-Art sein, nur eben von vor 
20..25 Jahren. Einzig um den Bit Datentypen beneide ich die Besitzer 
dieses Tools.

von D. V. (mazze69)


Lesenswert?

@Tom, die Standard-Libs von mikroE sind neben dem Compiler selbst auch 
Schrott. Ich nutze unter anderem auch mikroPascal, habe aber aufgrund 
der Unzulänglichkeiten des Compilers (er optimiert kaum bis garnicht) 
zumindest alle meine units selbst geschrieben. Wenn du magst, melde dich 
mal via PM, oder melde dich hier im Forum an.

von Tom (Gast)


Lesenswert?

Ja leider ist bei mikroe nicht alles Gold was glänzt, nur leider 
schränktmich e-lab zu sehr ein, als das ich berit währe so viel Geld für 
einen Compiler auzugeben, den ich dann alle X JAhre wieder für sehr viel 
Geld upgraden muss  :-(
Desweiteren ist daas E-Lab Forum das allererste überhaupt aus dem ich 
jemals gelöscht/rausgeworfen wurde vom Co Moderator..seit dem haben die 
bei mir verschissen.
Wenn der Rolf von ELab mal nicht mehr ist, ist das ganze Teil wertlos 
daher kommt E-Lab leider auch nicht in Frage, also gibt es leider nichts 
besseres als Mikroe..cool wäre wennn Freepascal mal voll Atmel oder ARM 
unterstüzuen würde un sich dort eine entsprechende Community bilden 
würde mit regen Austausch an Units...
Ich beschäftige mich zwar auch immer wieder mal mit C kann aber bis 
heute nicht so recht den Sinn für 90% der Anwender erkennen..die 
Fehlersuche ist haarsträubend in C.
Und auch da würde ich gerne weider auf mikroe setzen als auch die ganzen 
freien Versionen..somit bleibt man so oder so immer wieder bei Mikro e 
hängen :-( Aber portabler geht es halt nirgends anders

von Peter D. (peda)


Lesenswert?

Tom schrieb:
> verdammt, der Controller muss wirklich mit 2Mhz laufen..was für eien
> Verschwendung :-(

Was ist denn überhaupt Dein Problem, kommt die Netzsicherung bei 2MHz 
oder wie?

Du willst an was rumdockern, was doch völlig nebensächlich ist.

Du kannst ja auf den ATmega324 upgraden, da kannst Du zur Laufzeit den 
CPU-Prescaler ändern.

von Tom (Gast)


Lesenswert?

?!?
Das Problem ist das der Controller mit 2MHz laufen muss und nicht wie 
geplant mit 1Mhz, mit den zusätzlichen Stromsparmodi muss ich mich 
ebenfalls noch beschäfitgen!

von Peter D. (peda)


Lesenswert?

Tom schrieb:
> Das Problem ist das der Controller mit 2MHz laufen muss und nicht wie
> geplant mit 1Mhz

Dem MC ist das egal, der kann bis 16MHz.
Die Frage ist, warum ist es für Dich ein Problem?

Und ob der leicht geringere Stromverbrauch überhaupt merkbar ist, kann 
man erst am Gesamtverbauch zusammen mit der restlichen Schaltung 
erkennen.
Z.B. ein Spannungsregler 7805 zieht allein schon 5mA, ein ATmega32 
@2MHz/5V im Idle aber nur 1,5mA.

von Tom (Gast)


Lesenswert?

ist es...

von Peter D. (peda)


Lesenswert?

Die Frage ist, warum ist es für Dich ein Problem?

Bitte 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
Noch kein Account? Hier anmelden.