Ultraschall - Entfernunsmessung mit Ultraschall Interface aus RN

[Thegon]

Hallo allerseits,

Ich werkle schon seit längerem an einer Ultraschall Enfernunsmessung und bin im Roboterwissen auf die Schaltung des Ultraschall - Interfaces von Manf gestoßen, bzw. hat mich besserwessi darauf aufmerksam gemacht. Diese Schaltung hat mir gleich zugesagt und ich habe es einmal ausprobiert, nur leider funktioniert es nicht so richtig.
Das stoppen der Zeit übernimmt ein ATmega48, der zuerst in einer Schleife 16 Perioden des US - Bursts erzeugt, die dann in den Start in Eingang der Ultraschall - Interface Schaltung gehen. Warum kein Timer? Das habe ich schon einmal in einen Thread gepostet, der Timer schafft in Bascom keine 40 kHz.
Dann beginnt das Stoppen der zeit, die dann in der isr des interruptpins umgerechnet und ausgegeben wird.
Das ganze soll starten, wenn per UART ein "go" eintrifft.
So weit so gut.

Nun kommt zwar etwas per UART herein, nur das ist ziemlich unbrauchbar.
Die Erste zahl ist total verrückt, die ist manchmal riesengroß, dann im minus und ich habe bemerkt, dass es einen unterschied macht, wie lange ich mir zwischen dem Go - Schreiben zeit lasse.
Darauf folgen konstant (fast immer, um genau zu sein) 16 Zahlen, die alle fast gleich groß sind, etwa um die 20 - 30, manchmal aber auch größer als 100.
Der Witz an der sache ist, dass dies per UART hereinkommt, egal, ob der Sendewandler angeschlossen ist oder nicht.


Ich habe lange herumprobiert, aber leider ohne erfolg.
Der Code des Atmels hier:

$regfile "M48def.dat"
$crystal = 1000000
$hwstack = 100
$swstack = 100
$framesize = 100
$baud = 2400

Dim Endtime As Long
Dim Countperoverflow As Integer
Dim Stringuser As String * 10
Dim Countperiodes As Byte

Config Timer0 = Timer , Prescale = 1
On Timer0 Isrtimer
Enable Interrupts

Config Int0 = Rising
Enable Int0
Enable Interrupts
On Int0 Isr_interrupt

Config Portd.3 = Output
Portd.3 = 1

Do
Input Stringuser
If Stringuser = "go" Then
'################# den Sendebrust generieren +++++++++
Countperiodes = 0
Do
Portd.3 = 0
Waitus 8
Portd.3 = 1
Waitus 8
Countperiodes = Countperiodes + 1
Loop Until Countperiodes > 16
Countperiodes = 0
Portd.3 = 1
'######################################################
'Warum nur acht us warten? Ich habe das einfach ausprobiert und so kommt man ungefähr auf 42 kHz

Enable Timer0
Stringuser = ""
End If
Loop
 

'###############TimerIsR##################
Isrtimer:
Countperoverflow = Countperoverflow + 1
Return
'#########################################

'#########Interrupt################
Isr_interrupt:
Disable Timer0
Endtime = Countperoverflow * 256
Endtime = Endtime + Timer0
Print Endtime
Endtime = 0
Countperoverflow = 0
Return

Wäre sehr dankbar, könnte mir jemand sagen, was ich anders machen sollte bzw. wo der Fehler liegt.
Dass die Schaltung des US - Interfaces fehler aufweist, glaube ich eher nicht, ich habe sie durchgeprüft und gemessen, wo es etwas zu messen gibt. Ich kann mich aber natürlich auch täuschen.

[Richard]

Das habe ich schon einmal in einen Thread gepostet, der Timer schafft in Bascom keine 40 kHz.

1e6÷40e3 = 25, 256-25 = 231. Warum sollte der Timer es nicht schaffen alle 25 µs einen über lauf zu produzieren? Zur Not kann man auch eine höhere Takt Frequenz wählen. Sehe Dir auch einmal die Bascom Funktion pulsout/pulsin oder sound an, gearbeitet habe ich damit aber auch noch nicht

Gruß Richard

[Thegon]

Hallo Richard,
der Thread ist hier:
https://www.roboternetz.de/community...hlt-zu-langsam
Ich kann leider kein ASM, und die versuche einer Fastpwm bzw. CTC modus des timers haben leider nicht funktioniert.
Ich bin jetzt noch drauf gekommen, dass man das US - Modul mit der Schaltung völlig weglassen kann, man muss nur start in und pulse out verbinden und erhält genau das gleiche Resultat. Da kann doch etwas nicht ganz stimmen ...
Ich habe dann noch einen AVR so programmiert, dass er sozusagen eine virtuelle laufzeitverzögerung von 5000 us erzeugt, und es hat funktioniert, die zeit zu stoppen, mit genau diesem Code. Es muss also doch an der Hardware liegen.
Noch eine Frage: Ich habe Disable Timer0 geschrieben, nur irgentwie kommt mir vor, dass der timer weiterzählt und auch überläufe erzeugt. Kann das sein?

Ich habe auch auf dem US-Modul mit der schaltung zwischen START IN und PULSEOUT gemessen (Widerstand), doch der war zu groß, um ihn zu erfassen, es kann sich also nicht um einen Kurzschluss handeln. Hat jemand eine Idee, wie ein solch seltsames Ergebnis entstehen kann? Ich werde wohl noch alles durchmessen und berichten.
Mfg Thegon

[Searcher]

Hallo,
im anderen thread gab es Unstimmigkeiten mit der $crystal und tatsächlicher Prozessorfrequenz.

Hier hast Du 1MHz eingestellt. Wenn der Prozessor mit 8MHz läuft, könnten da die Probleme mit der UART liegen?

Gruß
Searcher

[Thegon]

Also jetzt läuft der prozessor mit 1 MHz, der 8 fach teiler ist aktiv. UART macht eigentlich keine Probleme, ich sende einfach "go" und der AVR sendet mir ein Paar zahlen, mit denen ich leider nichts anfangen kann
Ich habe aber vorher auch schon text ans terminal gesendet und es hat ohne probleme funktioniert.
Mfg Thegon

[Searcher]

Noch eine Frage: Ich habe Disable Timer0 geschrieben, nur irgentwie kommt mir vor, dass der timer weiterzählt und auch überläufe erzeugt. Kann das sein?

Nochmal Hallo ,

DISABLE TIMER0 unterdrückt Interrupts vom Timer0. Der Timer läuft aber weiter. Zum Anhalten: STOP TIMER0.

Es könnte sein, das noch das OVF0 Flag gesetzt ist, wenn der letzte Interrupt noch nicht abgearbeitet wurde. Könnte man sicherheitshalber nach Disable Timer0 mit SET TIFR0.OVF0 löschen oder TIFR0.OVF0 = 1

Gruß
Searcher

[Thegon]

Kann es sein, dass das register TIFR0.TOV0 heißt, denn OVF0 steht nicht im Datenblatt und wird von Bascom nicht erkannt?

EDIT: Das Problem ist nämlich, dass die erste gesendete zahl umso größer wird, um so länger ich mir zeit lasse und das nächste mal go schreibe.
Wenn ich mir sehr viel zeit lasse, wird sie sogar negativ, ich nehme an, sie ist dann zu groß für long und es fängt dann alles von vorne an.
Ich habe stop geschrieben, dann auch Start timer0, aber es hat sich leider am resultat nichts getan.
Mfg Thegon

[Searcher]

Ja, ist TOV0. Hab mich verguckt. Bin mir nicht sicher, ob das hilft. Schaden kann es nicht.

Gruß
Searcher

[Searcher]

Hab noch mal eine Frage: Wie soll das Programm funktionieren?

1. Go kommt
2. mit 40kHz werden 16 Impulse erzeugt
3. in der INT0 ISR soll die Zeit vom Begin der 40kHz bis Auslösen des INT0 über UART mit Print ausgegeben werden.

Print braucht so seine Zeit. Der INT0 ist die ganze Zeit aktiv. Deshalb die 16 Zahlen über UART?
Vielleicht die gestoppte Zeit in Array speichern und nicht in der ISR ausgeben sondern im Hauptprogramm?


EDIT Wenn ich richtig sehe, ist INT0 auf PD2. Der ist nirgends konfiguriert. Kann es sein, das der floatet und von dem danebenliegenden Ausgabepin PD3 mitgezogen wird? Internen Pullup einschalten?

Gruß
Searcher

[Thegon]

Hallo Searcher,
du hast recht, der interrupt pin hat gefloatet, dauerhaft, am anfang. Dann habe ich einen Externen pulldown von 10k gegen masse angehängt und er hat Ruhe gegeben, nur dass er eben immer 16 zahlen zu viel sendet. Meine Theorie: am ausgang werden 17 impulse des US - bursts ausgegeben, diese kommen über einen Fehler auf der Platine an den Interruptpin, das würde auch von der zeit etwa zusammenstimmen. Wenn der letzte impuls kommt, wird der timer wieder resettet, da aber kein interrupt mehr kommt, läuft er weiter, bis das nächste mal go geschrieben wird, dann ist die zahl natürlich riesig.
Ich habe die Platine aber schon mitdestens fünf mal durchgeprüft und keine Fehler gefunden, leider will mein oszi nicht, und so stehe ich jetzt einmal an. Ich hatte an einen Fehler im Flipflop gedacht, sodass am ausgang immer das ausgegeben wird, was am eingang anliegt, aber ich kann beim besten willen nichts finden. Das verrückte ist ja, dass es nichts mit Ultraschall zu tun hat, mein seltsames ergebnis. Ich habe den sendewandler ausgelötet und : genau das gleiche.

Sonst: du hast das prinzip meines programmes völlig richtig erfasst, in deinm beitrag eins weiter oben.

Ich befürchte, die einzige möglichkeit, hier noch etwas zu machen, ist das oszi in gang zu bekommen und einmal zu schauen, was sich in der Schaltung wirklich abspielt, nachdem go gesendet wurde. Ich werde schreiben, wenn ich neue Erkenntnisse gemacht habe.
Mfg Thegon