ft:pedia 2/2025 ist da!

[tintenfisch]

Im Computing-Bereich gibt es inzwischen eine Unzahl von Controllern - man könnte auch Wildwuchs sagen...

Jeroens Plan, die Bedienung mehrerer Shields durch eine C++Bibliothek zu vereinheitlichen, geht auf jeden Fall in die richtige Richtung!

Dem kann ich mich anschließen. Ich hatte mal begonnen, ein einheitliches API für die div. Controller (TX-Pi, Didacta Boards, ftDuino, …) für Python zu entwickeln, was aber dann wieder ins Hintertreffen geraten ist. Vielleicht wär's nett, das Vorhaben wieder aufzugreifen oder aber am Ende des Jahres einen Wrapper um Jeroens C++ Lib zu bauen. Wobei letztere meist "unpythonic" ausfallen. Zudem kann Python auf einigen Boards (bspw. ftDuino) nicht direkt, auch nicht in der Micro Python Variante, laufen; hier müsste er dann im "online" Mode laufen, d.h. es wäre immer ein Rechner notwendig, der das Board instruiert. Das wird mit einem reinen Wrapper um den C++ Code vermutlich nicht ohne weiteres abzubilden sein, somit wäre eh eine weitere Abstraktion notwenig, so dass man das evtl. auch gleich alles in Python schreiben könnte.

Ich freue mich auf Jeroens API!

[steffalk]

Tach auch!

Vielleicht kann man die Ideen aus https://www.ct-systeme.com/Infrastruktu ... /index.htm ja auch in C++ umsetzen, um von der konkreten Hardware weg zu abstrahieren?

Gruß,
Stefan

[tintenfisch]

Vielleicht kann man die Ideen aus https://www.ct-systeme.com/Infrastruktu ... /index.htm ja auch in C++ umsetzen, um von der konkreten Hardware weg zu abstrahieren?

Danke für den Link, kannte ich noch nicht. Wenn ich das richtig sehe, bietet das Framework weitgehend eine Abstraktion unter Verwendung des Builder-Pattern mit einer Fluent-API und fokussiert sich eher auf die Aktoren, Sensoren etc.

Ich hatte von einer anderen Seite her gedacht und die Boards in den Vordergrund gestellt.

Jedes Board sagt "ich habe x Motorausgänge, y Inputs, etc" und der Code wird dann dynamisch zur Laufzeit erstellt. Anhand der Spezfikation bekommt jedes Board, welches einen Motorausgang hat, bspw. Methoden wie m1_left(pwm), m1_right(pwm), m1_stop(), … Etwas ähnliches für die Eingänge. Das API ist ziemlich low-level und eliminiert nur bspw., dass man sich über GPIO Gedanken machen muss und alles heißt einheitlich m1, m2.., i1…, o1...

Über dieses low-level API wurde dann optional ein weiteres, wenn man so möchte, eher OOP-API, gestülpt, welches konkrete Aktoren und Sensoren anbot:

Code: Alles auswählen

motor = board.motor(1) # bindet Motor Object an M1
motor.left(255)
motor.right(255)
led = board.led(1)
led.brightness = 255
led.brightness = led.brightness // 2
# […]

Finde die Idee, weniger die Boards, sondern die Aktoren etc. in den Vordergrund zu stellen, aber auch interessant.

[ski7777]

Im Computing-Bereich gibt es inzwischen eine Unzahl von Controllern - man könnte auch Wildwuchs sagen...

Jeroens Plan, die Bedienung mehrerer Shields durch eine C++Bibliothek zu vereinheitlichen, geht auf jeden Fall in die richtige Richtung!

Dem kann ich mich anschließen. Ich hatte mal begonnen, ein einheitliches API für die div. Controller (TX-Pi, Didacta Boards, ftDuino, …) für Python zu entwickeln, was aber dann wieder ins Hintertreffen geraten ist. Vielleicht wär's nett, das Vorhaben wieder aufzugreifen oder aber am Ende des Jahres einen Wrapper um Jeroens C++ Lib zu bauen. Wobei letztere meist "unpythonic" ausfallen. Zudem kann Python auf einigen Boards (bspw. ftDuino) nicht direkt, auch nicht in der Micro Python Variante, laufen; hier müsste er dann im "online" Mode laufen, d.h. es wäre immer ein Rechner notwendig, der das Board instruiert. Das wird mit einem reinen Wrapper um den C++ Code vermutlich nicht ohne weiteres abzubilden sein, somit wäre eh eine weitere Abstraktion notwenig, so dass man das evtl. auch gleich alles in Python schreiben könnte.

Ich freue mich auf Jeroens API!

Auch wenn wir hier jetzt ein wenig von der ft:pedia abdriften:
Nachdem Torsten damals ftrobopy für den TXT entwickelt hat, habe ich ja fttxpy für den TX entwickelt (siehe ein alter ft:pedia-Beitrag). Was es mittlerweile auch gibt ist ein Aufsatz auf Defiants libroboint namens ftroboint. Diese sind alle bis auf das Extension-Handling API-kompatibel.
ft selbst hat für den TXT4.0 ja eine Python-lib veröffentlicht und AFAIK ist diese ftrobopy-kompatibel.