HC-SR04 Sensor am Nanoboard 3000 betreiben und Entfernung messen

[Alex (Gast)]

Moin zusammen!

In meinem Studium zur Medizintechnik sollen wir im Praktikum zur 
Programmierung von Mikroprozessoren ein eigenes kleines Projekt mit 
Hilfe des Nanoboard 3000 und Altium Designer auf die Beine stellen. Mein 
Kommilitone und ich haben uns dazu entschlossen, mittels HC-SR04 
Ultraschallsensors die Entfernung zu messen. Wahrscheinlich ganz simpel, 
aber wir hängen irgendwie fest und kommen nicht weiter.


Anbei findet ihr die Schaltung, welche wir mit Hilfe unseres Professors 
(von ihm so auch abgesegnet) erstellt haben sowie den Programmcode in C. 
Wir sind beide keine erfahrenen Programmierer, also immer her mit 
konstruktiver Kritik :)


Der US-Sensor ist direkt mit dem Nanoboard verbunden. PortA im Programm 
deckt sowohl den Trigger (Pin HA19 auf dem Nanoboard) auf als auch das 
Echo (Pin HA17 auf dem Nanoboard) ab.


Zunächst setzen wir einen High Pegel auf PortA, damit der Trigger mit 
Spannung versorgt wird. Nach einem Delay von 12 µs geht PortA wieder auf 
Low, was gleichzeitig auch das Startzeichen für unser Echo ist, welcher 
dann auf High geschaltet werden soll.


Der US-Sensor schickt Ultraschallwellen hinaus und wartet auf den 
Eingang selbiger nach der Reflexion an einem Objekt. Der Eingang der 
Reflexion soll einen Interrupt auslösen, wenn unser Echo auf Low geht.


Im gleichen Augenblick möchten wir einen (laut Prof willkürlichen) 
Bitwert vom 32 Bit Zähler (CB32CEB) abholen und irgendwie als unsere 
Laufzeit nutzen, um dann so letztendlich die Entfernung zu erhalten. 
Inverter invertiert die fallende Flanke des Echos und setzt so CLR vom 
Flipflop auf High, wodurch der Zähler einen Reset erfährt und die ganze 
Prozedur wieder von vorne beginnt.


Wird unser Programm auf das Nanoboard übertragen, erhalten wir keine 
richtigen Werte. Stets kommen 0 cm heraus oder das Programm bricht 
mitten im Ablauf ab.


- Die Fragen, die wir uns stellen, haben wir den Sensor korrekt ins 
Schematic integriert?

- Sind Trigger und Echo tatsächlich "nur" PortA?

- Ist der Interrupt korrekt eingebunden?

- Wie können wir den Bitwert in einen Zeitwert umrechnen? Geht das 
überhaupt?


Wir hoffen, Ihr habt vlt. eine Idee oder Tipps, wie wir dieses Projekt 
endlich ans Ziel bringen können!

Vielen Dank schon mal!

Alex

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Alex schrieb:
> Der US-Sensor schickt Ultraschallwellen hinaus
Tut er das? Wird der Sender angesteuert?

> Der Eingang der Reflexion soll einen Interrupt auslösen,
> wenn unser Echo auf Low geht.
Tut es das?

> C-Programm_US_Messung.PNG
Poste Sourcecode doch bitte wie in der Bedienungsanleitung über jeder 
Eingabebox beschrieben mit [c] Tags eingerahmt oder als C-Datei im 
Anhang...

[Gustl B. (-gb-)]

Muss das mit CPU und C abgefeiert werden? Für mich sieht das nach 
wenigen Zeilen VHDL aus. Eigentlich muss doch nur der Dutycycle einer 
PWM erkannt werden.

[Burkhard K. (buks)]

Gustl B. schrieb:
> Für mich sieht das nach
> wenigen Zeilen VHDL aus.

Nicht nur für Dich :-) Aber der TO schreibt, dass es im Praktikum um 
Mikroprozessortechnik geht.

Wenn die Laufzeit immer als 0 ms gemessen wird, dann gibt es die 
folgenden grundsätzlichen Fehlermöglichkeiten:

 - Signal "Echo" ist nicht oder falsch verdrahtet: mit Oszi oder DMM 
messen
 - der Interrupt wird nicht korrekt konfiguriert, erzeugt oder 
verarbeitet: Handbuch TSK300A konsultieren
 - das Timing stimmt nicht, siehe nächsten Absatz.

Zum Timing siehe: 
http://www.mikrocontroller-elektronik.de/ultraschallsensor-hc-sr04. 
Demnach dauert es nach dem Trigger-Puls nochmal 250 us, bis der US-Burst 
ausgelöst wird, dieser dauert dann 200 us, danach geht der Echo-Pegel 
solange auf High, bis das Echo eintrifft ist oder 200 ms überschritten 
wurden. Diesen Ablauf finde ich im C-Code nicht wieder - möglicherweise, 
weil ich mit dem verwendeten MC nicht vertraut bin.

[Basti (Gast)]

Die Treiber die für den HC-SR04 im Netz kursieren sind wirklich schlimm 
geschrieben. kA, wie die Leute es schaffen 300 Zeilen Quellcode dafür zu 
investieren.

Versuch mal meine Variante, habe alles erklärt mit der Timer-Konfig und 
die nötigen Funktionen, musst du nur auf deine Zielhardware ummünzen:

https://sebastianfoerster86.wordpress.com/2016/10/22/hc-sr04-driver/

Vorteile:
- nicht blockierend
- Rechenzeit schonend
- Fehlertolerant, falls mal ein Signal nicht zurück kommt (fehlt bei so 
vielen Treibern)
- leicht zu portieren

VG

Basti

[Alex (Gast)]

Moin!

Danke für die schnellen Reaktionen :)

Lothar M. schrieb:
>> C-Programm_US_Messung.PNG
> Poste Sourcecode doch bitte wie in der Bedienungsanleitung über jeder
> Eingabebox beschrieben mit [ c ] Tags eingerahmt oder als C-Datei im
> Anhang...

Hier ist der C-Code im korrekten Format:

//============================================================================
// C-Programm zur Ultraschallentfernungsmessung
//============================================================================

#include <stdio.h>
#include <stdint.h>
#include <drv_ioport.h>
#include <swplatform.h>
#include <interrupts.h>
#include <timing.h>
#include <time.h>

#define PortA 0                                                                 // Echo und Trigger
#define PortB 1                                                                 // Clear
#define EXT_INT0 0                                                              // Interruptquelle

//============================================================================
// Interrupt
__INTERRUPT_NATIVE void ISR_ENTFERNUNG(void);
//============================================================================

     ioport_t   *ptrPIO;
     bool       Int_Flag;
     void       *context;
     uint32_t   Laufzeit;


void main (void)
{
     double Entfernung = 0.0;
     int Laufzeit = 0;
     int Mess;

     ptrPIO =  ioport_open(DRV_IOPORT_1);   // Öffnen der I/O Port-Treiber

     interrupts_disable();

     ioport_set_value(ptrPIO, PortA, 1);    // Trigger auf High setzen
     delay_us(12);
     ioport_set_value(ptrPIO, PortA, 0);    // Trigger auf Low setzen

     context = interrupt_native_context(EXT_INT0);
     interrupt_register_native(EXT_INT0, context, ISR_ENTFERNUNG);
     interrupt_configure(EXT_INT0, EDGE_FALLING);
     interrupt_enable(EXT_INT0);

     interrupts_enable();

for (Mess = 1; Mess <= 10; Mess++)
{
     Entfernung = (343.5*0.5*Laufzeit);     // Berechnen der Entfernung

     printf("Entfernung = %f cm\n", Entfernung); // Ausgabe des Messwertes
}
}

//============================================================================
// Interrupt-Service-Routine
//============================================================================
__INTERRUPT_NATIVE void ISR_ENTFERNUNG(void)
{
    Laufzeit = ioport_get_value(ptrPIO, PortA); // Laufzeit-Wert vom PIO erhalten
    ioport_set_value(ptrPIO, PortA, Laufzeit);  // Laufzeit-Wert PortA übergeben

    ioport_set_value(ptrPIO, PortB, 1);         // Clear auf High setzen
    ioport_set_value(ptrPIO, PortB, 0);         // Clear auf Low setzen

    interrupt_acknowledge(EXT_INT0);
}

Burkhard K. schrieb:
> Wenn die Laufzeit immer als 0 ms gemessen wird, dann gibt es die
> folgenden grundsätzlichen Fehlermöglichkeiten:
>
>  - Signal "Echo" ist nicht oder falsch verdrahtet: mit Oszi oder DMM
> messen

- Die Verdrahtung haben wir mehrmals überprüft. Die Kontrolle per Oszi 
haben wir nur am Anfang des Projekts gemacht. Zu dem Zeitpunkt war aber 
alles korrekt. Trigger und Echo waren klar zu erkennen. Werden die 
Verbindungen noch mal per Oszi prüfen.

> - der Interrupt wird nicht korrekt konfiguriert, erzeugt oder
> verarbeitet: Handbuch TSK300A konsultieren

- Davon gehe ich auch aus. Der Interrupt soll bei fallender Flanke 
auslösen für PortA. Da über PortA sowohl Trigger als auch das Echo 
Signal läuft, woher weiß mein Interrupt, dass ich die fallende Flanke 
vom Echo Signal meine? Die Handbuch-Lektüre werde ich nochmal genauer 
konsultieren.

> - das Timing stimmt nicht, siehe nächsten Absatz.

- Wir waren der Meinung, dass der Delay von 250 µs bis zum Echo Burst 
nicht im Programmcode behandelt werden braucht. Läuft es nicht quasi in 
der internen Steuerung vom Sensor praktisch automatisch ab? Wir haben 
uns da an diversen Arduino Projekten orientiert mit dem gleichen 
Sensortyp. In den entsprechenden Programmcodes finden die 250 µs auch 
keine Erwähnung. Siehe bspw. hier: 
https://developer-blog.net/ultraschall-sensor-software/

Basti schrieb:
> Versuch mal meine Variante, habe alles erklärt mit der Timer-Konfig und
> die nötigen Funktionen, musst du nur auf deine Zielhardware ummünzen:

- Danke dafür, das werden wir machen:)

Nächste Woche Mittwoch sind wir wieder im Labor und können versuchen, 
eure Ratschläge umzusetzen!

VG Alex

[Marlin (Gast)]

Oh

Alex schrieb:
> Moin!
>
> Danke für die schnellen Reaktionen :)
>


Hey Alex
Ich glaube wir sind einer deiner Nachfolger und stehen vor dem gleichen 
Problem. Ist es möglich, dass du den vollständigen und richtigen C-Code 
für das Nanoboard 3000 hier nochmal reinstellen könntest?

Mit freundlichen Grüßen Marlin