Nach längerer Zeit habe ich es endlich mal wieder geschafft, ein Projekt fertig zu dokumentieren und auch zu veröffentlichen. Kernstück des "Baukastensystems" ist ein zentraler Controller mit einem Mega8 (später auch Mega88 oder anderen), Siebensegmentanzeige, sechs universellen Anschlüssen und zwei Servoausgängen. Dazu gibt es eine grafische Programmieroberfläche (nur Linux), die komplett ohne Tastatur und irgendwelche Menüs auskommt. Auch die Slider habe ich soweit angepasst, daß das Programm auch mittels Touch bedienbar sein dürfte. Über die Webseite http://www.jcwolfram.de/projekte/lblocks/main.php kommt man dann auch zum Download der X86 und ARM-Binaries (Raspberry Pi), Dokumentation und Sourcen) Jörg
Angehängte Dateien:
-
lblocks-screenshot.png
58 KB
:
Bearbeitet durch User
Hallo Joerg, deine Programmiersprache sieht interessant aus. Es erinnert mich ein wenig an "Scratch": http://de.wikipedia.org/wiki/Scratch_%28Programmiersprache%29 Aus dem Source-Code sehe ich, dass Du "C" verwendet hast. Welche Graphik-Bibliothek nutzt Du ?
Hallo Chris, Scratch mag durchaus ein bisschen Einfluß gehabt haben, das "ursprüngliche" Projekt (grafische Prgrammieroberfläche für den AT89C2051) ist eigentlich schon fast 10 Jahre alt aber nie fertig geworen. Dieser Ursprung ist auch einer der Gründe, dass ich noch GTK+ 1.2 als Toolkit benutze. Jörg
Supersache und wie immer gut erklärt. Respekt und vielen Dank !! Gruß Helmut
Apropos... Die Schaltfläche "Controller Einrichten" dient dazu, bei neuen Controllern die Fuses richtig zu setzen. Das muss ich noch in der Dokumentation ergänzen. Jörg
Hallo Jörg, wie wäre es, wenn Du auch Code für einen Arduino erzeugen würdest? Dann könnte sich der Nutzerkreis Deiner Software extrem vergrößern. Es gibt recht viele Leute, die zu Hause ein Arduino-Board rumliegen haben. Vielleicht kann man es auch damit kombinieren: Beitrag "Projekt: Virtuelle Instrumente an serielle Schnittstelle" Dann hätte man eine Art Mini-LabView. Ob man mit der Arduino IDE ein Hex-File flashen kann weis ich nicht, aber Du könntest auch ein C-File erzeugen, welches von der IDE kompiliert wird. Der Vorteil wäre dann, dass es auf vielen Arduino Boards läuft. Gruß, chris_
Auch wenn es vielleicht so aussieht, das LBlocks-Programm generiert keinen AVR-Code. Vielmehr läuft auf dem Controller ein Interpreter, der eines der 4 "Programme", die in der Realität nur Tabellen ähnlich dem .lblocks Format sind. Dadurch ist es auch kein Problem, diese "Programme" auch aus dem Controler zurückzulesen. Mit C-Code, der dann auch noch mit einer anderen IDE übersetzt werden muß ist so etwas dann aber nicht mehr möglich. Zwischenzeitlich gab es auch mal eine Variante, die via USB (CDC) oder Bluetooth angesteuert wurde. Auch mit Remote-Möglichkeit und Messwertübertragung und einem Simulator. Das Ganze ist dann aber ein funktionstechnisches Monster geworden, bei dem die Schlichtheit der Grundidee völlig untergegangen war. Aus diesem Grunde habe ich das dann auch Mitte des Jahres wieder verworfen. Theoretisch sollte es aber möglich sein mittels eines anderen Codegenerators, der z.B. durch das Programmierscript aufgerufen wird, auch C-Code zu erzeugen. Was einfacher realisierbar ist, wäre wohl ein auf den Arduino angepasster Interpreter. Und wenn das Board einen ISP-Anschluss hat, kann der Rest ja dann wie beim "originalen" LBlocks-Controller ablaufen. Jörg
Auf den meisten Arduinos sind ATmega's drauf, daher läuft das da direkt. Die Arduino IDE verwendet einfach nur den avrdude, mit dem kann man folglich auch einfach die hier generierten .hex Files draufflashen. Also muss er nichts extra entwickeln um das für Arduino umzusetzen...
Ich habe mir mal den Schaltplan vom Arduino Uno angesehen und festgestellt, daß die verfügbaren Pins nicht ausreichen. Beim LBlocks-Controller sind an den Pins PB6/PB7 der Start- und Stopptaster sowie die RUN-LED, beim Arduino hängt an diesen Pins aber der Quarz. Eventuell ließe sich das lösen, indem die beiden Taster auf die ISP/SPI Schnittstelle umverlegt werden. Den Code für 16MHz und andere Pinbelegung umzuschreiben sollte dann kein großes Problem sein, das ließe sich als zusätzliche Option beim Programmstart auch leicht mit einbinden. Programmierung wäre dann wie gehabt über ICSP, den USB-Controller vom Arduino kann man nicht nutzen. Um den zweiten Teil, die Hardware, müsste sich aber jemand anderes kümmern. Also die Widerstandskombinationen an den I/Os, LED-Anzeige und Taster. Wenn man dafür einen Shield entwickelt, kann man auch gleich noch den Mega8 mit draufsetzen und ist dann unabhängig vom Arduino ;-) Wobei sich dann auch noch die Frage stellt, wieviele Leute das dann auch nutzen würden und ob der Aufwand dafür sinnvoll wäre. Denn die Schnittmenge aus [LBlocks nutzen],[Arduino verwenden] und [Linux-User] wird wahrscheinlich nicht besonders groß sein. Jörg
>[Linux-User]
Kann man GTK+ nicht auch unter Windows kompilieren? Damit würde sich
wieder eine größere Nutzergemeinde erschließen.
Der große Vorteil Deiner tastaturlosen Programmierung würde ich aber auf
den Tablets sehen. Ich habe selbst auch eines, aber die
Tastaturbedienung über den Touchscreen finde ich ziemlich nervig, ich
benutze es nur um irgende etwas zu lesen.
Was die Arduino Nutzung anbelangt, wäre warscheinlich nur der
Standardweg der USB-Programmierung nützlich, weil vermutlich die
wenigsten Leute eine ISP-Programmierer haben.
Gruß,
chris_
>Ich habe mir mal den Schaltplan vom Arduino Uno angesehen und >festgestellt, daß die verfügbaren Pins nicht ausreichen. Brauchst Du alle Pins, oder kann man ein paar davon ausblenden?
chris_ schrieb: > Kann man GTK+ nicht auch unter Windows kompilieren? Seit 1 Woche gibts wieder offizielle Windows Binaries vom Gtk+: http://www.gtk.org/download/win32_tutorial.php http://article.gmane.org/gmane.comp.gnome.gtk+.general/25494
Sicherlich kann man das auch irgendwie unter Windows compilieren, viellleicht findet sich auch jemand, der es macht (ich boykottiere propietäre Software wo ich kann). Allerdings wird man wohl auch das modifizierte GTK+1.2 mit compilieren müssen oder das Programm an eine andere verfügbare Version anpassen. Ich hatte das Programm auch schon mal dynamisch gegen GTK2.x gelinkt, aber da funktionierten einige Sachen nicht so wie sie sollten. Mit dem VMware Player oder Virtualbox und einem minimalen Linux-Image wäre es aber viel einfacher, zum Ziel zu kommen. Die ARM-Variante könnte bestimmt auch auf einem Tablet laufen, wahrscheinlich müsste man sich mit Linux für Android als Unterbau helfen. Letztendlich ist das Programm auch schon in dieser Hinsicht entwickelt worden (große Schaltflächen, breite Scrollbalken). Allerdings braucht es dann wohl auch eine andere Verbindung zum Controller, z.B. über Bluetooth. Da ich aber keinen sinvollen Verwendungszweck für ein Tablet habe, habe ich auch keins und kann es somit auch nicht ausprobieren. Um Pins einzusparen, könnte man die LED-Anzeige über ein Schieberegister ansteuern und könnte damit 4 Pins einsparen. Dazu müsste dann halt die Software im Controller angepasst werden. Ebenso müsste man wahrscheinlich den Bootloader anpassen. Die Schnittstelle im PC-Programm ist ja schon vorhanden, denn das Programmieren und Zurücklesen wird über Hexdateien und externe Scripte realisiert. Im Schaltplan habe ich jetzt noch 6 Kondensatoren eingefügt. Die waren in der ursprünglichen Version nicht enthalten, sind aber gerade beim Fototransistor sinnvoll. Jörg
Tolle Sache, so was schwebte mir auch schon immer mal vor. Mein Sohn ist auch 7, ich sollte wirklich mal die Interessen in die richtige Richtung lenken :)
>Sicherlich kann man das auch irgendwie unter Windows compilieren, >viellleicht findet sich auch jemand, der es macht (ich boykottiere >propietäre Software wo ich kann). Bei mir laufen auch alle Rechner mit Linux. Meistens versuche ich aber in einer Sprache zu programmieren, die überall läuft ( Java, Python ). Eigentlich will ich auch keine propietären System unterstützen, aber gleichzeitig auch niemanden ausschließen. >Die ARM-Variante könnte bestimmt auch auf einem Tablet laufen, ... Allerdings >braucht es dann wohl auch eine andere Verbindung zum Controller, z.B. >über Bluetooth. Eventuell könntest Du den Audiobootloader nehmen: http://www.hobby-roboter.de/forum/viewtopic.php?f=4&t=127 Die letzte Version mit der differentiellen Manchestercodierung sollte funktionieren. Hier hat mal jemand eine Browser-Orientierte Programmiersprache versucht, welche direkt das Audiosignal für den Code erzeugt. http://tadpol.org/projects/AvrianJump.html Leider hat er noch nicht die differentielle Manchestercodierung verwendet, so dass nur die Hälfte der Geräte funktionieren dürfte.
chris_ schrieb: > Eventuell könntest Du den Audiobootloader nehmen: Wie waere es mit USBaspLoader? USB hat heute jeder Computer und duerfte einfacher/bequemer als Audio sein. https://github.com/baerwolf/USBaspLoader/tree/testing Es gibt auch ein Demoboard dazu, was sogar ATmega8 als Default benutzt: http://matrixstorm.com/avr/tinyusbboard/ Kommt ggf. auch AT-X-mega als MCU in Frage? Dann haette ich nocheinen vermutlich perfekten Vorschlag. MfG
:
Bearbeitet durch User
Ich denke nicht, dass ich jemanden ausschließe. Ich verlange ja auch nicht, dass es von allen Programmen eine Linux-Version geben muß. Außerdem ist das Projekt Open Source. Vielleicht findet sich ja jemand, der es für Windows compilert damit es dort auch nativ läuft. Bis dahin gibt es virtuelle Maschinen (und CoLinux). Nur um der Kompatibilität willen neue Programmiersprachen zu lernen sehe ich nicht ein, da gibt es viele andere Dinge die mich mehr interessieren. Letztendlich zeigt das Projekt ja, dass es auch mit C geht. Was ist so schlimm an Bluetooth? Die meisten Tablets und Laptops sollten das heute haben und man kann es sowieso nicht allen recht machen. Gut, so ein BTM112 ist teurer als der ganze Rest. Was den Audio-Bootloadern aber fehlt, ist der Rückkanal. Ohne den lassen sich aber die im Controller gespeicherten Programme nicht vom PC-Programm auslesen und man weiß nicht, welches Programm man denn eigentlich überschreibt. Zum USBASPLoader: Wie bekommt der mit wenn ich den Controller auslesen oder beschreiben will, während das LBlocks-Programm läuft? Und jedesmal dafür einen Schalter zu schließen und den Controller zu resetten halte ich für wenig zielführend. Da ist es meiner Meinung nach besser, einen USB-Programmer als zweiten Chip mit draufzupacken (und den Reset bei abgesteckten USB automatisch zu trennen) womit wir eigentlich wieder beim Status Quo sind... Jörg
Joerg Wolfram schrieb: > Zum USBASPLoader: Wie bekommt der mit wenn ich den Controller auslesen > oder beschreiben will, während das LBlocks-Programm läuft? Hallo Joerg. Ich habe mir lblock noch nicht detailiert genug angesehen - aber es duerfte doch moeglich sein den Code bereits derartig zu generieren, das auch in der User-Firmware selbst immer USB-Funktionalitaet enthalten ist. Diese Subfunktion "lauscht" dann immer auf einen "Reset"-Befehl und springt dann zurueck in den Bootloader. Der Bootloader selbst (testing stage) unterstuetzt soetwas (um per Software-Befehl zurueck zu Applikation zu wechseln) bereits seit commit: https://github.com/baerwolf/USBaspLoader/commit/46cd9d4a9468b30ee8e456eadee7aed61e6830c1 Fuer Fragen stehe ich gern zur Verfuegung.
Hallo Stephan, ich glaube nicht, dass das so einfach ist. Zum einem müsste man den AVR-Teil von Assembler nach C umschreiben oder den USB-Code nach Assembler portieren. Oder das Ganze irgendwie mischen wobei die Datensätze für die 4 Programme im Flash ab 0x100 liegen. Derzeit werden insgesamt ca. 5200 Bytes benötigt (Interpreter+Daten+Routinen), wenn man die USB-Funktionalistät 2 mal braucht, wird man wohl auf den nächst größeren Controller wechseln müssen. Dann gleich einen mit mehr Pins, da für USB ein Quarz und zwei zusätzliche Leitungen (D+,D-) benötigt werden. ISP braucht man trotzdem, um den Bootloader überhaupt in den AVR zu bekommen. Und dann gibt es noch einen Timer-Interrupt der mit ca. 25,6KHz aufgerufen wird und für die LED-PWM, Tonausgabe und Anzeige-Multiplexing zuständig ist. Ich halte es für eher unwahrscheinlich, dass der sich mit der USB-Funktionalität verträgt. Wenn man sich nicht einen fertig programmierten Chip oder Bausatz von irgendwoher kaufen will, braucht man sowieso einen Programmer. Und da die Fuses aus dem LBlocks-Programm heraus gesetzt werden können, sehe ich da auch kein Problem für Leute die sich nicht damit auskennen. Jörg
>ich glaube nicht, dass das so einfach ist. Zum einem müsste man den >AVR-Teil von Assembler nach C umschreiben oder den USB-Code nach >Assembler portieren. Du könntest eine VM verwenden, wenn es Dir nicht zu sehr auf Geschwindigkeit ankommt: http://www.hobby-roboter.de/forum/viewtopic.php?f=4&t=145 Da ich lange mit LabView gearbeitet habe, mach ich mir auch schon seit längerem Gedanken zur Realisierung einer eigenen graphischen Programmiersprache. Da ich nicht Controllerabhängig sein will, wird diese VM-Code erzeugen.
Es ist ja schon eine Art VM, denn im AVR läuft ein Interpreter, der einfach die Blöcke der Reihe nach abarbeitet. Das ist eine einfache Tabelle, die in ähnlicher Form auch die Datenstruktur im LBlocks-Programm ist und sich in den .lblocks Dateien wiederfindet. In dieser Tabelle steht für jedes der pro Box möglichen 32 Elemente der Elementetyp (255 für nicht belegt), Der Elemente-Wert, die Position des Elementes auf der Arbeitsfläche sowie der horizontale und der vertikale Nachfolger und die laufende Nummer der Verbindung (Route). Die Position und die Routennummer braucht der AVR eigentlich nicht, aber damit kann nach dem Zurücklesen der Tabelle das Programm komplett rekonstruiert werden. Den AVR habe ich deswegen gewählt, weil die Programmer dafür am leichtesten beschaffbar sind. Es hätte meinetwegen genausogut ein Freescale- oder Renesas-Controller sein können, ich denke das würde den Nachbau nur unnötig erschweren. Der AVR-Code (bis auf die Segment-Tabelle) wird bei jedem Schreiben auf den Controller durch den bei der Compilierung des PC-Programmes erzeugten Code ersetzt, dadurch lässt sich das System auch um weitere Elementetypen erweitern, ohnd dass die Controller dazu inkompatibel werden. Ich schreibe AVR-Programme generell in Assembler, also müsste ich meinen Assemblercode daraufhin trimmen, dass er mit dem C-Code des USB-Teils zusammenarbeitet. Und es bliebe immernoch das Problem mit der Interrupt-Routine. Wer will, kann sich ja ein eigenes Programm schreiben, welches durch das Progrscript aufgerufen wird. Dieses könnte dann die relevanten Datenbereich aus dem Hexfile kopieren und an den Bootloader schicken. Und vice versa mit dem Readscript. Und wer es nicht so umständlich mag, nimmt halt weiterhin einfach einen ISP-Programmer... Jörg
Hallo Joerg Wolfram schrieb: > Es ist ja schon eine Art VM, denn im AVR läuft ein Interpreter Koennte man das nicht ganz einfach in eine Art Compiler umbauen? Indem die verwendeten Bloecke als Unterprogramm mit fester Adresse im Flash abgelegt werden? MfG
Es scheint immer mehr graphische Programmiersprachen zu geben: Beitrag "Firefly + Arduino + Code Generator?"
@Stephan Was hätte ein Compiler für einen Vorteil? Der Code dürfte auch so schnell genug sein. Denn es wird aus dem Blocktyp die Adresse für einen ICALL zum entsprechend Block-Code bestimmt. Machbar ist ein Compiler schon, allerdings wird dann das Zurücklesen aus dem Chip etwas aufwändiger, da man dann einen Decompiler braucht. @chris Es wird sicherlich noch mehr grafische "Programmieroberflächen" geben. Von daher halte ich es auch für wenig sinnvoll den Aufwand einer Portierung auf Betriebssysteme die ich selbst nicht nutze zu treiben. Es ist halt bei mir ein Projekt unter mehreren aktiven, vornehmlich wird es (neben Bugfixes) nur Erweiterungen bei den Experimenten geben. Und da habe ich noch jede Menge Ideen... Jörg
Mir ist noch eine Idee gekommen: Wenn man die LED-Anzeige durch ein z.B. 16x1 LCD tauscht, könnte man PD0 und PD1 (RXD/TXD) freibekommen. Dann noch die beiden Taster mit dem ICSP "sharen" und das Ganze sollte auch auf einem Arduino (ich hab mir nur den Schaltplan vom Uno angesehen) laufen können. Da die Text-LCDs meist eine identische Schnittstelle haben, ließe sich so auch leichter ein allgemeines Layout realisieren. Code für serielle Ansteuerung gab es schon mal, das ließe sich wahrscheinlich recht einfach "reaktivieren". Jörg
Hier gibt es eine graphische Oberfläche für den Browser, die Code erzeugt: http://forums.parallax.com/showthread.php/152499-FlowBlocks Das könnte auch als Anregung dienen.
Vielleicht bin ich da etwas schwer von Begriff, aber mir fällt einfach kein Vorteil einer browserbasierten Lösung ein. Außer dass man es sich unnötig schwer macht, mit der externen Hardware zu kommunizieren. Bei LBlocks braucht man nichts zu installieren und auch die Anzahl der direkten Abhängigkeiten ist überschaubar (X11, libpng). Und dass das Programm nicht unter Windows läuft, ist letztendlich ja auch für mich ein angenehmer Nebeneffekt. Jörg
chris_ schrieb: > Hier gibt es eine graphische Oberfläche für den Browser, die Code > erzeugt: Vielen Dank chris_. Das werde ich mir einmal fuer mein frisches Bastelprojekt (http://matrixstorm.com/avr/avrstick/) genauer ansehen! Fuer vollstaendige Plattformanhabhaengigkeit baestel ich derzeit an einem neuen Board. Da ist noch nichts final und alles in einem prototypischen Zustand - funktioniert aber schon ziemlich gut. Das primaere Feature des Boards soll sein, das es unter modernen Betriebssystemen (Linux, Windows, ...) weder Treiber noch Programmiersoftware (wie z.B. AVRDUDE) benötigt: Standardmäßig ist meine Bootloader Eigenwicklung installiert, welche das Board als USB-Stick enumeriert und die Speicher des AVRs sowie zusätzliche Informationen (FUSES, Production- und Usersignatur) als Dateien "einblendet". Ändern/Überschreiben einer Datei entspricht der Programmierung des entsprechenden Speichers. Die Webkomponente (Mitwirkende sind gern willkommen) muss noch ausgebaut werden (ASM geht aber schon), aber die Idee ist mit dem default Bootloader ohne die Installation irgendeiner Software auch direkt aus dem Browser zu programmieren. Die erstellte Firmware wird dann einfach auf den "Stick" "gedownloaded". Der Bootloader kann (auch hier ohne Programmiergeraet) über seine USB-Schnittelle upgedatet / ausgetauscht werden. So sind spaetere Verbesserungen kein Problem. Auch kann der "MassStorage Bootloader" durch den von Atmel bereitgestellten DFU Bootloader "Flip" ersetzt werden (siehe Seite). Joerg Wolfram schrieb: > mir fällt einfach > kein Vorteil einer browserbasierten Lösung ein Ueberhaupt keine Installation notwendig - damit einfach und auch keine Adminrechte um mindestens den Treiber eines Boards oder Programmers zu installieren. (Mann kann auch mal schnell einen oeffentlichen/fremden Rechner benutzen.) Plattform uebergreifend - nicht nur Windows und Linux mit ggf. noch Mac. Alles was HTML5 hat geht - damt auch TVs und andere Unterhaltungselektronik (XBOX? PS4?). MfG und Frohes Fest
Die Idee mit dem USB-Memory-Device hatte ich auch schon, aber nach meinen Erfahrungen mit dem MBED wieder verworfen. Man muss nämlich dafür sorgen, dass das Device immer synchron gemounted wird oder nach jedem Schreiben per Script syncen, was ich nicht unbedingt als der Weisheit letzten Schluß ansehe. Außerdem lässt sich der "Rückkanal" auf diese Weise nur schwer implementieren. Momentan bin ich dabei, serielle (USB+BT) Kommunikation einzubauen und eine Art Debug-Modus zu realisieren. Damit sollen dann das gerade aktive Element farbig hervorgehoben die Variablen angezeigt werden. Das barucht allerdings dann einen neuen Controller. Da nicht sonderlich großes Interesse besteht und mir die aktuelle Lösung eigentlich ausreicht, hat das Ganze eher niedrige Priorität. Jörg
Thread beobachten
Seitenaufteilung abschaltenBitte 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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.