TauLabs/PicoC: Scripting
- Themenstarter cGiesen
- Beginndatum
@ernieift,
ich würde den Buzzer Ausgang vom Quanton gerne in Betrieb nehmen, siehe auch: https://github.com/TauLabs/TauLabs/issues/1621
Ich hab schon nen branch aufgemacht für die Änderungen am Quanton, und einen für die in PicoC.
Ich habe mich dabei versucht an deiner I2C Implementierung zu orientieren. Könntest du da evtl. mal nen Blick drauf werfen ob das so funktionieren könnte: https://github.com/Trex4Git/TauLabs/commit/969b4f41c407a5828ec4f91ce44eed3864555e99
Bei dem PicoC habe ich noch nicht so 100% den durchblick wie das alles funktioniert.
ich würde den Buzzer Ausgang vom Quanton gerne in Betrieb nehmen, siehe auch: https://github.com/TauLabs/TauLabs/issues/1621
Ich hab schon nen branch aufgemacht für die Änderungen am Quanton, und einen für die in PicoC.
Ich habe mich dabei versucht an deiner I2C Implementierung zu orientieren. Könntest du da evtl. mal nen Blick drauf werfen ob das so funktionieren könnte: https://github.com/Trex4Git/TauLabs/commit/969b4f41c407a5828ec4f91ce44eed3864555e99
Bei dem PicoC habe ich noch nicht so 100% den durchblick wie das alles funktioniert.
Da ich morgen für eine Woche in den Urlaub fahre nur kurz. Die Implementierung in picoC stimmt soweit. Ich würde allerdings temp weglassen, da die PIOS_GPIO-Funktionen void sind. Also würde die Library nichts wichtiges zurückgeben können. Also mach' sie doch auch void. Ich habe zwar gerade keine Zeit zum testen, nur soviel:
Ich glaube du solltest nicht mit GPIO_On/Off arbeiten. Der Pin geht nur von 0..15 und Du hast keinen Einfluss auf den verwendeten Port (A..G). Die ganze Funktion wird nur mit PIOS_INCLUDE_GPIO eingebaut. Das ist auf dem Quanton glaube ich gar nicht drin.
Für einen besseren Zugriff kannst Du GPIO_ReadInputDataBit() und GPIO_WriteBit() benutzen. Dazu musst Du die Struktur für den Port in der Funktion ausfüllen. Beim Quanton ist der Buzzer "A4" und wird beim Hochlauf als Ausgang mit Zustand 0 programmiert.
Wenn Du die Funktion ohne Sicherheit einbaust, kann das ziemlich schief gehen. Da Du Dir ja schon die I2C-Funktion angeschaut hast, kommen die PIOS_I2C_ADAPTER_X aus den jeweiligen Targets. Also entweder führst Du noch einen "#define GPIO_PIN_X" im Target ein, oder sicherst das ganze über die security()-Funktion wenigstens etwas ab. Dann könntest Du auch den Pin für Input oder OutPut programmieren.
Ein bisschen prüfen vor dem Aufruf ist immer sinnvoll, sonst laufen Dir einige Funktionen in assert() und das Betriebsystem stoppt!
Gruss
Jörg
Ich glaube du solltest nicht mit GPIO_On/Off arbeiten. Der Pin geht nur von 0..15 und Du hast keinen Einfluss auf den verwendeten Port (A..G). Die ganze Funktion wird nur mit PIOS_INCLUDE_GPIO eingebaut. Das ist auf dem Quanton glaube ich gar nicht drin.
Für einen besseren Zugriff kannst Du GPIO_ReadInputDataBit() und GPIO_WriteBit() benutzen. Dazu musst Du die Struktur für den Port in der Funktion ausfüllen. Beim Quanton ist der Buzzer "A4" und wird beim Hochlauf als Ausgang mit Zustand 0 programmiert.
Wenn Du die Funktion ohne Sicherheit einbaust, kann das ziemlich schief gehen. Da Du Dir ja schon die I2C-Funktion angeschaut hast, kommen die PIOS_I2C_ADAPTER_X aus den jeweiligen Targets. Also entweder führst Du noch einen "#define GPIO_PIN_X" im Target ein, oder sicherst das ganze über die security()-Funktion wenigstens etwas ab. Dann könntest Du auch den Pin für Input oder OutPut programmieren.
Ein bisschen prüfen vor dem Aufruf ist immer sinnvoll, sonst laufen Dir einige Funktionen in assert() und das Betriebsystem stoppt!
Gruss
Jörg
Schon mal danke für deine schnelle Antwort.
Ich habe auch gerade die Entwicklungsumgebung scheinbar halbwegs zum laufen bekommen, dann kann ich demnächst auch mal selber testen.
So wie du es beschreibst hatte ich es auch zuerst überlegt, hatte dann aber im PIOS schon Ansätze gesehen, z.B. beim Copter Control, die ich dann weiter verfolgen wollte, und nicht zu viel neu/doppelt implementieren.
Meine angedachten Änderungen fürs quanton: https://github.com/Trex4Git/TauLabs/commit/b1c9fea4fc8f9839bda0b37a78c3419696094172
Diese defines in pios_board.h müssen natürlich stimmen, aber die Funktionen in pios_gpio.c scheinen mir darauf ausgelegt zu sein.
In Pico C wird mit der pin Nummer nicht direkt der Pin an einem zufälligen Port angesprochen, sondern die Position in dem mit define aufgestellten Array. Die Pios GPIO Funktionen holen sich dann aus den Arrays die zugehörigen wirklichen Port und Pin Nummern.
Da muss natürlich die Firmware stimmen, aber in pico C kann man dann nicht dynamisch eine Fehleingabe machen, die man sonst mit security funktionen verhindern müßte (zumindest F1 und F3/F4 haben da andere Strukuren und müssten sinnvollerweise wieder abstrahiert werden, wenns prinzipiell auf allen Tragets laufen soll).
Das ist zumindest mein aktueller Plan für die Implementierung.
Edit: Link geändert
Ich habe auch gerade die Entwicklungsumgebung scheinbar halbwegs zum laufen bekommen, dann kann ich demnächst auch mal selber testen.
So wie du es beschreibst hatte ich es auch zuerst überlegt, hatte dann aber im PIOS schon Ansätze gesehen, z.B. beim Copter Control, die ich dann weiter verfolgen wollte, und nicht zu viel neu/doppelt implementieren.
Meine angedachten Änderungen fürs quanton: https://github.com/Trex4Git/TauLabs/commit/b1c9fea4fc8f9839bda0b37a78c3419696094172
Diese defines in pios_board.h müssen natürlich stimmen, aber die Funktionen in pios_gpio.c scheinen mir darauf ausgelegt zu sein.
In Pico C wird mit der pin Nummer nicht direkt der Pin an einem zufälligen Port angesprochen, sondern die Position in dem mit define aufgestellten Array. Die Pios GPIO Funktionen holen sich dann aus den Arrays die zugehörigen wirklichen Port und Pin Nummern.
Da muss natürlich die Firmware stimmen, aber in pico C kann man dann nicht dynamisch eine Fehleingabe machen, die man sonst mit security funktionen verhindern müßte (zumindest F1 und F3/F4 haben da andere Strukuren und müssten sinnvollerweise wieder abstrahiert werden, wenns prinzipiell auf allen Tragets laufen soll).
Das ist zumindest mein aktueller Plan für die Implementierung.
Edit: Link geändert
Zuletzt bearbeitet:
Ich habe nochmal nachgesehen. Also Du könntest wohl PIOS_INCLUDE_GPIO benutzen. Dazu müsstest Du es erstmal für das Quanton aktivieren und dann noch in der pios_board.h etwas in der Art einfügen:
Damit wäre der Pin 0 auf A4 definiert. Inputs gehen auf diese Weise aber nicht.Um PIOS_GPIO_Enable() kommst Du auch nicht rum.
Code:
//-------------------------
// GPIO
//-------------------------
#define PIOS_GPIO_PORTS { GPIOA }
#define PIOS_GPIO_PINS { GPIO_Pin_4 }
#define PIOS_GPIO_NUM 1
Zuletzt bearbeitet:
Schon mal Danke Jörg für deinen Input, ich wünsche dir schon mal nen schönen Urlaub.
Mal schaun was ich so hinbekomme.
Zumindest habe ich die beiden commits (PicoC und Quanton) mal zusammen in einen branch gemerged, und es scheint auch zu kompilieren.
Genau das habe ich ja in meinem Commit fürs Quanton drinne (hatte ich zumindest versucht), oder hattest du das noch nicht gesehen?
PIOS_GPIO_Enable() macht ja nichts anderes als die Initialisierung, die wird doch aber in pios_board.c auch jetzt schon für den buzzer pin des Quanton gemacht , nur halt ohne dies Funktion, sondern "von Hand".
Und ja, Inputs gehen damit erstmal nicht.
GPIO Inputs hatte ich in meinen ersten überlegungen auch angedacht, aber als ich dann die bisher angelegten GPIO Funktionalitäten in PIOS gesehen habe, wollte ich versuchen die zu benutzen bevor ich was neues implementiere.
Wenn man eine andere Implementierung sauber machen wollte, zumindest so wie ich die guidelines für taulabs verstanden habe, würde ich security checks, Unterscheidung zwischen Input oder Output,... als Treiber ansehen und dann eher pios_gpio überarbeiten, als das alles in Pico C reinzupacken.
Aber bisher habe ich noch keine Anfragen zu nem GPIO input gesehen, das Thema Buzzer dagegen ist schon mehrfach aufgetaucht.
Mal schaun was ich so hinbekomme.
Zumindest habe ich die beiden commits (PicoC und Quanton) mal zusammen in einen branch gemerged, und es scheint auch zu kompilieren.
Genau das habe ich ja in meinem Commit fürs Quanton drinne (hatte ich zumindest versucht), oder hattest du das noch nicht gesehen?
PIOS_GPIO_Enable() macht ja nichts anderes als die Initialisierung, die wird doch aber in pios_board.c auch jetzt schon für den buzzer pin des Quanton gemacht , nur halt ohne dies Funktion, sondern "von Hand".
Und ja, Inputs gehen damit erstmal nicht.
GPIO Inputs hatte ich in meinen ersten überlegungen auch angedacht, aber als ich dann die bisher angelegten GPIO Funktionalitäten in PIOS gesehen habe, wollte ich versuchen die zu benutzen bevor ich was neues implementiere.
Wenn man eine andere Implementierung sauber machen wollte, zumindest so wie ich die guidelines für taulabs verstanden habe, würde ich security checks, Unterscheidung zwischen Input oder Output,... als Treiber ansehen und dann eher pios_gpio überarbeiten, als das alles in Pico C reinzupacken.
Aber bisher habe ich noch keine Anfragen zu nem GPIO input gesehen, das Thema Buzzer dagegen ist schon mehrfach aufgetaucht.
Morgen,
den zweiten Link habe ich nicht angesehen. Ich dachte es wäre noch der erste. Du brauchst es nicht aufzuteilen, da es für sich allein nicht funktioniert. Wenn Du es mit PIOS_INCLUDE_GPIO und den Erweiterungen für picoC und Quanton in einem Branch hältst, ist es ok. Für mich sieht es schon ganz gut aus. Das Ausprobieren überlasse ich Dir - Wird schon laufen
.
Da der Buzzer auf dem Quanton wenigstens schon mal als Output definiert wird, kannst Du Dir dafür die Initialisierung sparen. Die GPIO_Enable-Funktion würde ich für andere Targets trotzdem einbauen. Es finden sich bestimmt Lötwütige, die freie Pins auf den Boards (FlyingF4) nutzen und da noch eine Weihnachtsbaumbeleuchtung anbauen wollen. Wenn die Pins über die GPIO-Arrays festgelegt sind, kann man sich auch die Securitystufen sparen, da der Programmierer nicht aus dem picoC-Gefängnis kommt.
den zweiten Link habe ich nicht angesehen. Ich dachte es wäre noch der erste. Du brauchst es nicht aufzuteilen, da es für sich allein nicht funktioniert. Wenn Du es mit PIOS_INCLUDE_GPIO und den Erweiterungen für picoC und Quanton in einem Branch hältst, ist es ok. Für mich sieht es schon ganz gut aus. Das Ausprobieren überlasse ich Dir - Wird schon laufen
.Da der Buzzer auf dem Quanton wenigstens schon mal als Output definiert wird, kannst Du Dir dafür die Initialisierung sparen. Die GPIO_Enable-Funktion würde ich für andere Targets trotzdem einbauen. Es finden sich bestimmt Lötwütige, die freie Pins auf den Boards (FlyingF4) nutzen und da noch eine Weihnachtsbaumbeleuchtung anbauen wollen. Wenn die Pins über die GPIO-Arrays festgelegt sind, kann man sich auch die Securitystufen sparen, da der Programmierer nicht aus dem picoC-Gefängnis kommt.
Wenn das "dynamisch" aus PicoC raus gemacht wird, können aber wieder Probleme auftauchen wenn evtl. was falsch konfiguriert wird, oder auf einen anderweitig genutzten Pin zugegriffen wird. Da wären dann auch einige Sicherheits Prüfungen sinnvoll, denke ich.
Da habe ich bisher noch keine Idee wie man das kurz und elegant lösen kann, aber ich habe auch noch nicht so 100% den Überblick über Taulabs, evtl. gibts da ja schon was.
Wenn die Initialisierung jedoch fest in der Firmwaer erfolgt, hat sich hoffentlich der Entwickler was dabei gedacht und es getestet. Da müßten dann aber für die verschiedenen Targets Output Pins ausgewählt und implementiert werden.
Genau das habe ich als Vorteil gesehen, als ich auf PIOS GPIO funktionalität gestoßen bin.
Da habe ich bisher noch keine Idee wie man das kurz und elegant lösen kann, aber ich habe auch noch nicht so 100% den Überblick über Taulabs, evtl. gibts da ja schon was.
Wenn die Initialisierung jedoch fest in der Firmwaer erfolgt, hat sich hoffentlich der Entwickler was dabei gedacht und es getestet
. Da müßten dann aber für die verschiedenen Targets Output Pins ausgewählt und implementiert werden.Genau das habe ich als Vorteil gesehen, als ich auf PIOS GPIO funktionalität gestoßen bin.
Mach dir bitte keine Hektik daraus, bisher hats ja scheinbar noch niemand außer mir vermisst, und ich kanns ja auch schon testen
Ob der Pull request noch was länger gebraucht wird bis er gemerged wird, dürfte ja kein großes Problem sein.
Ich hatte ihn nur schon mal eingereicht, um die Diskussion auf Github weiter zu führen, und nicht hier das Forum voll zu spammen.
Wenns es dann mal gemerged ist, würde ich dann auch noch ein paar Skripte (z.B. BeepX, SoftPWM) dazu posten, wenn ich sie auch getestet habe.
Aber wie bereits gesagt bin ich offen für Änderungen, habe das bisher nur erstmal außer meine beschränkten Sicht implementiert.
Aber wenn hier oder auf Github Wünsche genannt werden implemetiere ich das auch gerne, soweit ich weiß was zu tun ist. So wird das ganze dann auch für mehr Leute nutzbar/interessant.
Ob der Pull request noch was länger gebraucht wird bis er gemerged wird, dürfte ja kein großes Problem sein.
Ich hatte ihn nur schon mal eingereicht, um die Diskussion auf Github weiter zu führen, und nicht hier das Forum voll zu spammen.
Wenns es dann mal gemerged ist, würde ich dann auch noch ein paar Skripte (z.B. BeepX, SoftPWM) dazu posten, wenn ich sie auch getestet habe.
Aber wie bereits gesagt bin ich offen für Änderungen, habe das bisher nur erstmal außer meine beschränkten Sicht implementiert.
Aber wenn hier oder auf Github Wünsche genannt werden implemetiere ich das auch gerne, soweit ich weiß was zu tun ist
. So wird das ganze dann auch für mehr Leute nutzbar/interessant.Mal ne Frage zu den Picoc Skripten ansich.
Wie kann man in einer Unterfunktion am besten ein "Gedächtnis" nutzen?
Mit globalen Variablen an sich ja kein Problem, aber die haben ja auch so ihre Nachteile.
Und eine Variablendeklaration mit static in der Unterfunktion scheint zwar erstmal zu gehen, aber nach kurzer Zeit wird das Skript beendet. Ich vermute mal das da evtl. irgendow ein Speicherleck aufrtitt. Irgendwo bezüglich PicoC hatte ich auch gelesen das static nicht unterstüzt wird.
Wie kann man in einer Unterfunktion am besten ein "Gedächtnis" nutzen?
Mit globalen Variablen an sich ja kein Problem, aber die haben ja auch so ihre Nachteile.
Und eine Variablendeklaration mit static in der Unterfunktion scheint zwar erstmal zu gehen, aber nach kurzer Zeit wird das Skript beendet. Ich vermute mal das da evtl. irgendow ein Speicherleck aufrtitt. Irgendwo bezüglich PicoC hatte ich auch gelesen das static nicht unterstüzt wird.
Hallo,
ich wollte hier mal kurz Bescheid geben das meine GPIO und PicoC Änderungen gemerged wurden und in aktuellen next builds dann zur Verfügung stehen sollten.
Zunächst sind GPIO Pins nur für das Quanton definiert.
Damit kann man z.B. dann den Buzzer Pin in Betrieb nehmen.
Hier sind PicoC Beispiel Skripte um auf dem Buzzer eine PMW mit 50% DutyCycle, oder eine PWM mit variablen DutyCycle, oder beliebige Sequenzen auszugeben: http://forum.taulabs.org/viewtopic.php?f=17&t=715#p5959
Dazu eine kurze Übersicht welche Pins für GPIO Nutzung auf dem Qunaton definiert sind: http://forum.taulabs.org/viewtopic.php?f=17&t=715#p5971
In dem Thread finden sich sonst auch ein paar zusätzliche Infos, ansonsten sieht man die Implementireung im PR: https://github.com/TauLabs/TauLabs/pull/1628
Ich denke es ist auch sinnvoll den PicoC Eintrag im taulabs Wiki dahingegehn anzupassen. Braucht man dafür irgendwelche speziellen Rechte?
ich wollte hier mal kurz Bescheid geben das meine GPIO und PicoC Änderungen gemerged wurden und in aktuellen next builds dann zur Verfügung stehen sollten.
Zunächst sind GPIO Pins nur für das Quanton definiert.
Damit kann man z.B. dann den Buzzer Pin in Betrieb nehmen.
Hier sind PicoC Beispiel Skripte um auf dem Buzzer eine PMW mit 50% DutyCycle, oder eine PWM mit variablen DutyCycle, oder beliebige Sequenzen auszugeben: http://forum.taulabs.org/viewtopic.php?f=17&t=715#p5959
Dazu eine kurze Übersicht welche Pins für GPIO Nutzung auf dem Qunaton definiert sind: http://forum.taulabs.org/viewtopic.php?f=17&t=715#p5971
In dem Thread finden sich sonst auch ein paar zusätzliche Infos, ansonsten sieht man die Implementireung im PR: https://github.com/TauLabs/TauLabs/pull/1628
Ich denke es ist auch sinnvoll den PicoC Eintrag im taulabs Wiki dahingegehn anzupassen. Braucht man dafür irgendwelche speziellen Rechte?
Du meinst die Beschreibung die schon existiert oder den zukünftigen Wiki eintrag?
Bezüglich es Wiki dachte ich daran erstmal nur kurz die neunen Funktionen in die library Beschreibung einzupflegen, und gegebenfalls zu den Beispielen im Forum linken.
In dem thread da ging es auch um Fragen die die Implementierung angehen, also ob spezielle aber potentiell gefährliche Funktionen reinsollen. Da aber keine Nachfrage bestand, sind erstmal nur einfache Lese und Schreibe Funktionen geworden für fest definierte und freigegebene Pins.
Aber eine zusammenfassung wie es benuzt werden kann, kann ich gerne auch hier im Thread, oder in einem neuen nochmal geben.
Bezüglich es Wiki dachte ich daran erstmal nur kurz die neunen Funktionen in die library Beschreibung einzupflegen, und gegebenfalls zu den Beispielen im Forum linken.
In dem thread da ging es auch um Fragen die die Implementierung angehen, also ob spezielle aber potentiell gefährliche Funktionen reinsollen. Da aber keine Nachfrage bestand, sind erstmal nur einfache Lese und Schreibe Funktionen geworden für fest definierte und freigegebene Pins.
Aber eine zusammenfassung wie es benuzt werden kann, kann ich gerne auch hier im Thread, oder in einem neuen nochmal geben.
