Forum: Compiler & IDEs FreeRTOS - esp_err_t


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von W3ll S. (w3llschmidt)


Bewertung
0 lesenswert
nicht lesenswert
Mal als Laie, frage man bei JEDEM Befehl in seinem Programm den 
Errorcode/Returncode ab?

https://github.com/espressif/esp-idf/blob/7d75213/components/driver/include/driver/i2s.h
 * @param i2s_num i2s port index
 * @return
 *     - ESP_OK                Success
 *     - ESP_ERR_INVALID_ARG   Parameter error
 *     - ESP_ERR_INVALID_STATE Driver state error
 */
esp_err_t i2s_adc_enable(i2s_port_t i2s_num);

von PittyJ (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Bei den meisten schon.
Manchmal kann man danach nicht weiter machen.
Und man möchte auch gerne wissen, ob ein Fehler aufgetreten ist, und 
z.B. die Ursache dann finden.

von mIstA (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Ich würde mal sagen; das kommt darauf an…

Während der Programmentwicklung und erst recht als Anfänger sollte man 
das wirklich sehr konsequent durchziehen und im Fehlerfall möglichst 
sinnvolle Debug-Meldungen z.B. über 'ne serielle Konsole ausgeben.

Wenn die fertig entwickelte Firmware dann produktiv in einer Umgebung 
läuft, in der man kaum Möglichkeiten hat, detailierte Fehlermeldungen zu 
kommunizieren und auch nicht innerhalb der Firmware nicht sinnvoll auf 
den Fehler reagieren kann, dann muß man wohl nicht unbedingt jeden 
Rückgabewert prüfen.

Wenn beispielsweise eine dynamische Speicheranforderung scheitert und 
ohnehin ein Reset die einzige sinnvolle Möglichkeit ist darauf zu 
reagieren, dann kann man sich die Fehlerprüfung ggf. sparen, jedenfalls 
wenn ein NULL-Pointer Zugriff ebenfalls zu einem Systemneustart führt.
In der Entwicklungsphase wird man allerdings schon wissen wollen,wo 
welche Speicheranforderung schiefgegangen ist.

von Til S. (Firma: SEGGER) (til_s)


Bewertung
0 lesenswert
nicht lesenswert
Die Frage ist auch, ob es nicht ein besseres Konzept gibt. Wenn ich mit 
API Funktionen arbeite, die einen Return Wert zurückliefern, muss ich 
den, wie vom Vorredner erklärt, zumindest während der Entwicklung jedes 
Mal auswerten.
Das macht den Code nicht schöner und ist einiges an Aufwand.

Mir gefällt das Konzept im embOS eigentlich besser. Es wird kein 
derartiger Return Wert zurückgeliefert sondern der Debug Code in den API 
Funktionen ruft eine Funktion OS_Error() mit einem bestimmten Fehlercode 
auf. D.h. während der Entwicklung kann ich im Debugger in OS_Error() 
einen Breakpoint setzen und sehe mit Hilfe des Call Stacks und des Watch 
Windows sofort wo der Fehler und welcher Fehler aufgetreten ist. Ich 
kann mir stattdessen natürlich auch eine Fehlermeldung per Uart ausgeben 
lassen. Wer möchte kann diesen Debug Code auch in der fertigen Firmware 
nutzen und im OS_Error() die Hardware neu starten. Alternativ lässt sich 
der Debug Code über ein Define deaktivieren.

Ich denke das Konzept würde auch für andere Software gut funktionieren 
auch wenn das natürlich nicht für jeden Fall passt.

von W3ll S. (w3llschmidt)


Bewertung
0 lesenswert
nicht lesenswert
mIstA schrieb:
> Wenn die fertig entwickelte Firmware dann produktiv in einer Umgebung
> läuft, in der man kaum Möglichkeiten hat, detailierte Fehlermeldungen zu
> kommunizieren und auch nicht innerhalb der Firmware nicht sinnvoll auf
> den Fehler reagieren kann, dann muß man wohl nicht unbedingt jeden
> Rückgabewert prüfen.

Hmm, guter Punkt ...

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.