Forum: Compiler & IDEs FreeRTOS - esp_err_t


von Welle 🧐 S. (w3llschmidt)


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
1
 * @param i2s_num i2s port index
2
 * @return
3
 *     - ESP_OK                Success
4
 *     - ESP_ERR_INVALID_ARG   Parameter error
5
 *     - ESP_ERR_INVALID_STATE Driver state error
6
 */
7
esp_err_t i2s_adc_enable(i2s_port_t i2s_num);

von PittyJ (Gast)


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)


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)


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 Welle 🧐 S. (w3llschmidt)


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 ...

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.