1Wire wieviel MHz mindestens?!

Tom Gast #3993854
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?
Beitrag melden Bearbeiten Thread verschieben Thread sperren Anmeldepflicht aktivieren Anpinnen Thread löschen Thread mit anderem zusammenführen Markierten Text zitieren Antwort Antwort mit Zitat
(prx) A. K. #3993879
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.
Beitrag melden Bearbeiten Löschen Markierten Text zitieren Antwort Antwort mit Zitat
Tom Gast #3993945
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
Beitrag melden Bearbeiten Löschen Markierten Text zitieren Antwort Antwort mit Zitat
Uwe K. #3994160
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).
Beitrag melden Bearbeiten Löschen Markierten Text zitieren Antwort Antwort mit Zitat
Tom Gast #3996024
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
Beitrag melden Bearbeiten Löschen Markierten Text zitieren Antwort Antwort mit Zitat
Peter D. #3996087
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.
Beitrag melden Bearbeiten Löschen Markierten Text zitieren Antwort Antwort mit Zitat
Peter D. #3996219
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.
Beitrag melden Bearbeiten Löschen Markierten Text zitieren Antwort Antwort mit Zitat
Thread beobachten

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

Bestehender Account

oder

Mit Google-Account einloggen

Noch kein Account?

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren