Foren-Übersicht

Liebe Wheelie-Fahrer, Tester, Programmierer und Mitstreiter!

Hiermit wird dazu aufgerufen die folgende Firmware als Community Projekt zu optimieren.

Zur Geschichte: Es war einmal eine Firmware in der Version 2.6, erstellt von Chris Krohne in Zusammenarbeit mit dem Elektor-Labor. Mit dieser Firmware wird der Wheelie-Bausatz ausgeliefert. Da die Sache ja ein offenes Projekt ist und der Source Code in Bascom frei zur Verfügung steht, dauerte es nicht lange, bis sich erste Leute daran machten, die FW zu optimieren.
Den Startschuss zu dieser Entwicklung legte Günter Gerold.
Er rupfte den Code, vereinfachte ihn und versah ihn mit Kommentaren, sodass er jetzt im wesentlichen nachvollziehbar sein müsste. Sogar ich verstehe ihn jetzt.


Open Firmware: Da es aber vermutlich nicht so klug ist, wenn nur ein einziger Mensch den Code weiterentwickelt oder schlimmer noch: viele Menschen viele Code-Versionen entwickeln, über deren Feinheiten man schnell den Überblick verliert, war schnell klar, dass es sehr viel sinnvoller ist, wenn sich mehrere Leute an einer Entwicklung beteiligen. Da mehr Programmierer mehr Bugs fixen und mehr Ideen zusammen kommen, wird es dem Code und damit dem Wheelie gut tun, wenn die weitere Fortentwicklung von einer Community kooperativ erledigt wird.

Koordination: Damit dieses Vorhaben nicht aus dem Ruder läuft, schlage ich vor, dass in diesem Thread Code und Ideen diskutiert vorgestellt und diskutiert werden und dass dann ab einem bestimmten Punkt es Sache von Günter ist, weiteren Code in die Firmware einzubringen und eine neue Version des Source Codes und der zugehörigen Hex-Datei hier in diesem Thread zu posten. Kooperative Entwicklung erfordert auch etwas an Disziplin und Organisation.
Was meint ihr? Machen wir es so oder gibt es bessere Vorschläge?

Was geht: Es können sich also Wheelie-Fahrer mit Programmier-Ambitionen beteiligen und sich gegenseitig dabei helfen, aus dem Wheelie ein besseres Wheelie zu machen. Was man dazu braucht ist eine volle Version von Bascom. Man kann natürlich auch mitdiskutieren, ohne Bascom auf der Platte zu haben. Der Source Code ist auch mit jedem Text-Editor problemlos einsehbar. Man kann den Source Code auch mit der kostenlosen Demo-Version von Bascom laden und inspizieren - lediglich das kompilieren von so viel Code ist damit nicht möglich. Außerdem könnte man ja gerade an so einem Beispiel in das Programmieren von Mikrocontrollern einsteigen. So schwer ist das nicht. Bascom ist gut verständlich.
Wer nicht programmieren möchte, der kann sich auch einfach hier die aktuellste Hex-Datei herunter laden und auf seinen ATmega32 mit einem handelsüblichen AVR-Programmer schieben. Es ist sicher auch hilfreich, wenn Leute quasi als Beta-Tester bestimmte Features ausprobieren und dann hier ihren Eindruck schildern.

Internationalität: Damit Menschen weltweit mitmachen können, sind die Kommentare im Source Code konsequent in englischer Sprache gehalten. Naja, vielleicht auch ein bisserl Denglisch. Doch Günter ist daran unschuldig. Zuckerbrot & Peitsche für besonders gelungene (d)englische Formulierungen bitte an mich!


Regeln: Vielleicht der besseren Kommunikation wegen noch folgender Vorschlag: Wenn Code-Schnipsel gepostet werden, dann dabei die Zeilennummerierung von Bascom einschalten und sich auf Zeilennummern beziehen, damit man gleich weiß, wo im Quelltext man suchen muss.


And now!
Here comes!

EWOF100 - Elektor Open Firmware Version 1.0.0

Tusch!

Wer würde es wagen, einem großen Mann das Mitspielen zu verwehren?

Spaß beiseite: Willkommen im Club.
Du kannst ja erst mal die Demoversion von Bascom laden und Dir die Sache anschauen. Ist echt nicht so gefährlich, auch wenn die Zählweise für die 40 Beine des ATmega32 tatsächlich etwa so geht: 1, 2, 3, viele, tausend!

Dass die Motoren hochgebockt schnell loslaufen, das ist nichts Besonderes. Das liegt daran, dass Du die Plattform nicht absolut waagrecht hälst und die Lenkstange auch nicht in der Mitte.
Ohne Last reicht ja etwas Leistung auf den Motoren und schon legen sie los.
Ich kriege das hochgebockte Wheelie auch kaum ausbalanciert, nur so in etwa. Aber ich habe auch eine Spezial-Hochbock-Konstruktion: Eine Mineralwasserkiste. Da reichen ja fast µm an Abweichung. Außerdem driften die Sensoren und so kommen schnell ein paar Watt an die Motoren, was dann wieder ohne Last für Drehzahl sorgt.
Immerhin sehe ich, dass die Räder auf Lenkung reagieren.

Aber wenn man drauf steht ist das ja alles weg...

Beim Flashen kann man eigentlich kaum was falsch machen, solange man nicht an den Fuses rumspielt. Außerdem sorgt ein Verify (hast Du doch eingestellt) für Übereinstimmung von Datei und Controller-Speicher. Das motzt ja, falls sich Abweichungen ergeben haben sollten.

o oh,

hallo ihr beiden, toll daß ihr euch schon mit dem Code beschäftigt. Genau so soll es sein!

Also bevor Thomas den Code veröffentlicht hat, habe ich eine kurze Runde gedreht, ohne einen Unterschied zu merken. Jedoch habe ich keine aufgebockten Versuche unternommen, sondern bin einfach losgefahren.
Theoretisch könnte der Code noch ein bisschen aggressiver sein als die 3.3er Version. Das würde sich natürlich im aufgebockten Zustand bemerkbar machen. Wenn bei einer winzigen Korrektur der Räder sich an der Lage nichts ändert (ist ja aufgebockt) dann holt der Controller gleich den dicken Hammer raus und jagt die Motoren hoch
Das mit dem Lenker stimmt, das habe ich gerade ausprobiert.
Herzlichen Glückwunsch zum ersten gefundenen Bug!

Das wird natürlich umgehend abgestellt

Günter

Hallo auch Meister der Code Snipsel

leider ist es jetzt ein bisschen dunkel

außerdem hat sich heute bei mir während der Fahrt der Radbolzen (Sechskant) gelöst und mir einen Granatensturz beschert.

Die Flansche lassen sich mit den Bolzen nur schlecht richtig fest anziehen, da als einziger Gegenhalt die Nietschrauben herhalten können und die nicht besonders stabil sind. Habe die Bolzen jetzt erst mal mit Lock behandelt und hoffe das hält den Belastungen etwas länger stand.

Morgen bin ich unterwegs mal sehen vielleicht komme ich trotzdem dazu die Motoren hoch zu jagen