Forum

Hallo,
wir haben uns entschlossen, ein intern benutztes Tool frei zur Verfügung
zu stellen. Wir haben das Tool "ChISL" genannt, zu finden auf
http://chisl.io (die Webseite ist noch 'alpha', aber hoffentlich kommt
die Grundidee rüber).

Worum geht es? Beim Programmieren von komplexen Chips, vor allem RF und
Sensoren, via z.B. SPI oder I2C benutzen wir eine Meta-Beschreibung der
digitalen Schnittstelle. Dazu gehören Register Adressen, Bits, Modi
(lesen, schreiben, etc.), Defaults, usw. Der ChISL Parser erzeugt daraus
dann C oder C++ source code (oder ein bisschen exotischer: Python), auf
dem wir dann aufbauen.

Der Vorteil ist, dass die Code-Qualität garantiert ist, weil der Source
Code direkt von der Dokumentation stammt. Dank der Metabeschreibung ist
es auch möglich, diverse Tests laufen zu lassen. Ausserdem ist der
Source Code standardisiert, es gibt keine Namenskonflikte, und wir
können C++ einsetzen. (Die meisten Bibliotheken der Hersteller sind noch
C89 - der kleinste gemeinsame Nenner.) Dann ist die Dokumentation in der
Header Datei integriert, was in IDEs sehr nützlich ist. Apropos
Dokumentation: Mit Hilfe der Metabeschreibung können wir eine
Web-basierte Doku machen, die einfacher zu handhaben ist, als diverse
Pdfs mit datasheet, User-manual, Errata, Application-notes, etc.

Mich würde sehr interessieren, was die Mitglieder des Forums von
ChISL.io halten. Wie gesagt, es ist ein internes Tool, und er erfordert
noch ein bisschen Arbeit, bevor es wirklich präsentabel ist. Und bevor
wir mehr Zeit investieren, würden wir gerne Feedback sammeln, hier im
Forum, oder hier: http://chisl.io/questionnaire

Besten Dank!
Markus

Hi Markus,

netter Auftritt.
Und was darf und wird von den lizenzierten Sources zur Verfügung gestellt, bzw. verraten?
zB für mich, bzw. von meinen...?

Schnell überflogen, - da bin ich dann schon in London, stimmt's?

Grüße
Gerald
---

--
...und täglich grüßt der PC:
"Drück' ENTER! Feigling!"

» Und was darf und wird von den lizenzierten Sources zur Verfügung gestellt,
» bzw. verraten?
» zB für mich, bzw. von meinen...?
Die Idee ist eigentlich, dass Sources öffentlich zugänglich sind (CC Attribute-ShareAlike Lizenz). Diejenigen, die etwas privat halten möchten, sind vermutlich kommerzielle Nutzer, und von denen würden wir wohl einen kleinen Beitrag verlangen.

» » Und was darf und wird von den lizenzierten Sources zur Verfügung
» gestellt,
» » bzw. verraten?
» » zB für mich, bzw. von meinen...?
» Die Idee ist eigentlich, dass Sources öffentlich zugänglich sind (CC

alles klar soweit...

» Attribute-ShareAlike Lizenz). Diejenigen, die etwas privat halten möchten,
» sind vermutlich kommerzielle Nutzer, und von denen würden wir wohl einen
» kleinen Beitrag verlangen.

damit ist es wohl beantwortet.

--
...und täglich grüßt der PC:
"Drück' ENTER! Feigling!"

» Worum geht es? Beim Programmieren von komplexen Chips, vor allem RF und
» Sensoren, via z.B. SPI oder I2C benutzen wir eine Meta-Beschreibung der
» digitalen Schnittstelle. Dazu gehören Register Adressen, Bits, Modi
» (lesen, schreiben, etc.), Defaults, usw. Der ChISL Parser erzeugt daraus
» dann C oder C++ source code (oder ein bisschen exotischer: Python), auf
» dem wir dann aufbauen.
Die Idee an sich finde ich eigentlich recht nice, aber eure DSL liest sich wie Assembler! Beim lesen der Sprache muss man sich mehr auf die Sprache konzentrieren als das was damit gesagt wird. Für ein internes Tool lass ich mir das noch eingehen aber für ein breiteres Publikum - ich weiß ja nicht.

Welchen Vorteil hat der generierte Code eigentlich gegenüber einer fertigen lib?

» Die Idee ist eigentlich, dass Sources öffentlich zugänglich sind (CC Attribute-ShareAlike Lizenz)
Welche Sourcen? Die generierten Sourcen, oder (nur) die Definition in eurer DSL oder der Code des Generators?
CC ist für Sourcecode eher ungeeignet, sucht euch lieber eine speziell für Software entworfene (GNU/GPL, MIT, Apache, AGPL, ...) - die Verwendete Lizenz hat einen nicht unerheblichen Einfluss auf die Akzeptanz der darunter stehenden Software.

Oh und es fehlen noch die Backends für Ruby und Java

» Die Idee an sich finde ich eigentlich recht nice, aber eure DSL liest sich wie Assembler!
Wir haben lange damit herumprobiert. Am Schluss musste es etwas sein, dass sich schnell tippen lässt, und sich gut lesen lässt.
Jetzt sieht es aus, wie eine Mischung aus yaml und Assembler. Die meisten Leute kommen damit zurecht.

» aber für ein breiteres Publikum - ich weiß ja nicht.
Vermutlich konsumiert das breite Publikum nur den Output (also source code C, C++ usw.)
Ich hoffe aber, dass Fehler, Verbesserungsvorschläge, usw. zurückfliessen. Und sei es nur, indem jemand ein ticket löst (z.B. auf github - TBD) oder einen Kommentar im Forum abliefert.

» Welchen Vorteil hat der generierte Code eigentlich gegenüber einer fertigen
» lib?
- garantierte Qualität
- Standardisierung
- die Möglichkeit, von C auf C++ auf Python und wieder auf C zu gehen, ohne jedesmal Bits kodieren zu müssen
- automatisierte Tests
- Lesbare Dekodierung der Nachrichten zwischen Chip und MCU/MPU
- Doku ist im C/C++/etc source code integriert (-> man kann in der IDE die Doku sehen)

» CC ist für Sourcecode eher ungeeignet, sucht euch lieber eine speziell für
» Software entworfene (GNU/GPL, MIT, Apache, AGPL, ...) - die Verwendete
» Lizenz hat einen nicht unerheblichen Einfluss auf die Akzeptanz der
» darunter stehenden Software.
Ah diese Lizenzfragen... Die Metabeschreibung (``DSL'') und alle Foreneinträge und dgl. sollen CC 4 BY-SA sein, wo möglich. Der generierte C/C++/etc source code wird am besten MIT oder BSD lizensiert, wo möglich. (Das ist was für Rechtsanwälte, der Inhalt der DSL ist aus den Datenblättern kopiert, und dann ein bisschen editiert. Ich muss hier "cover-my-ass" machen.)

» Oh und es fehlen noch die Backends für Ruby und Java
und Haskell... Mal im Ernst. Die Zeiten für ANSI C sind vorbei. Leider sind die meisten Bibs noch ANSI C - der kleinste gemeinsame Nenner. Das ist zwar verständlich, aus Sicht der Hersteller, aber ANSI C ist einfach veraltet. Ausnahme ist Arduino und mbed.org, aber dort ist die Qualität bunt gemischt zwischen 1A und mittelmäßig.

» » Oh und es fehlen noch die Backends für Ruby und Java
» und Haskell... Mal im Ernst. Die Zeiten für ANSI C sind vorbei. Leider sind
» die meisten Bibs noch ANSI C - der kleinste gemeinsame Nenner. Das ist zwar
» verständlich, aus Sicht der Hersteller, aber ANSI C ist einfach veraltet.
» Ausnahme ist Arduino und mbed.org, aber dort ist die Qualität bunt gemischt
» zwischen 1A und mittelmäßig.

Die Zeiten fuer C sind sicherlich nicht vorbei. Solange die Software noch eine Hardware braucht, braucht es Konstrukte wie Pointer fuer z.B. Low-Level Speicherverwaltung.. Diese bieten andere Sprachen - zurecht - dann nicht mehr direkt und muessen eben auf die low-level libs zurueck greifen. Besonders wenn man in Richtung Bare-Metal Programmierung schaut, wird C uns noch lange erhalten bleiben.

» Die Zeiten fuer C sind sicherlich nicht vorbei. Solange die Software noch
» eine Hardware braucht, braucht es Konstrukte wie Pointer fuer z.B.
» Low-Level Speicherverwaltung.. Diese bieten andere Sprachen - zurecht -
» dann nicht mehr direkt und muessen eben auf die low-level libs zurueck
» greifen. Besonders wenn man in Richtung Bare-Metal Programmierung schaut,
» wird C uns noch lange erhalten bleiben.
Ich denke mit ANSI C bezieht er sich nicht auf die Programmiersprache C als solche sondern die Standardisierung C89.

» » Die Idee an sich finde ich eigentlich recht nice, aber eure DSL liest
» sich wie Assembler!
» Wir haben lange damit herumprobiert. Am Schluss musste es etwas sein, dass
» sich schnell tippen lässt, und sich gut lesen lässt.
» Jetzt sieht es aus, wie eine Mischung aus yaml und Assembler. Die meisten
» Leute kommen damit zurecht.
Für meinen Geschmack ist es zu Assemblerig aber ich bin auch davon ausgegangen die Metabeschreibung/DSL soll als Dokumentation dienen - hab übersehen, dass die Dokumentation auch aus der Beschreibung generiert und in die Zielquellcode-Dateien eingebunden werden soll. Dann kann es dem Verwender des generierten Codes wirklich egal sein wie die DSL aussieht.

» » Welchen Vorteil hat der generierte Code eigentlich gegenüber einer fertigen lib?
» - garantierte Qualität
Von was? Der generierte Code ist auch nur so gut wie der Generator und die Ausgangsquellen.

» - Standardisierung
Im Rahmen des Codegenerators - mit der Einschränkung lass ich das gelten

» - die Möglichkeit, von C auf C++ auf Python und wieder auf C zu gehen, ohne jedesmal Bits kodieren zu müssen
Man beschreibt einmal den Chip und kann das dann in verschiedenen Zielsprachen ohne Mehraufwand verwenden. Soweit hatte ich das schon verstanden, genauer Prototyp in Python und die richtige Anwendung dann in C/C++ ohne dass man den Aufwand für die Chip-Anbindung doppelt hat. Oder kommt es bei euch vor, dass man mal eben während der Implementierung die Sprache wechselt?

» - automatisierte Tests
Sehr gutes Argument!

» - Lesbare Dekodierung der Nachrichten zwischen Chip und MCU/MPU
Ich hab gehört, dass man das in der Embedded-Welt anscheinend braucht - kann ich nicht beurteilen.

» - Doku ist im C/C++/etc source code integriert (-> man kann in der IDE die
» Doku sehen)
Auch gut.

» Der generierte C/C++/etc source code wird am besten MIT oder BSD lizensiert, wo möglich.
Das ist das interessanteste für den Anwender eures Generators, was zählt ist die Lizenz für den Code der dann wirklich in das eigene Projekt compiliert wird. MIT/BSD sind da sehr Entwicklerfreundlich.

» (Das ist was für Rechtsanwälte, der Inhalt der DSL ist aus den
» Datenblättern kopiert, und dann ein bisschen editiert. Ich muss hier
» "cover-my-ass" machen.)
Klar, und einen Fachanwalt zu konsultieren macht hier auf jeden Fall Sinn.

» Leider sind die meisten Bibs noch ANSI C - der kleinste gemeinsame Nenner. Das ist zwar
» verständlich, aus Sicht der Hersteller, aber ANSI C ist einfach veraltet.
Ok, aber so lange ich den Code nicht pflegen muss (da fertig vom Hersteller geliefert) kann es mir doch egal sein so lange er kompiliert und fehlerfrei läuft - die ganzen alten C-Standards werden doch auch von neueren noch unterstützt. So ganz kann ich das noch nicht nachvollziehen - für µCs programmiere ich aber auch nur als Hobby.