Elektronik mit digitalen und analogen I/O und Display u.ä.

[Alloc]

Zitat von Matze:

Boah das klingt ganz schön heftig. Auf Ethernet und USB kann ich auch vorerst mal verzichten. Es wäre nur schön, wenn es nachträglich realisiert werden könnte (ohne alles über den Haufen zu werfen).

Achja, gäbe natürlich noch nen Mittelweg: Schaltung konkret auf bestimmte Bauteile für diese Aufgaben Auslegen, aber die Bauteile auf der Platine erst mal noch nicht bestücken. Oder zwar bestücken, aber noch nicht nutzen

[Matze]

Kurz zu der Skriptsprache:
Vielleicht geht das auch anders.

Ein einfacheres Beispiel wäre ein Akkuladegerät. Bei den besseren kann man verschiedene Akku-Programme anlegen (NiMH, LiPo, LiIo, ...). Zu jedem Akku kann man Daten wie die Zellenanzahl, Kapazität etc. einstellen und entsprechend wird das Ladeprogramm gestaltet.

D.h. es gibt ein paar Parameter, die als Programm anzuspeichern sind. Diese müssen natürlich auch wieder geladen (interpretiert) werden können.
Mit einer Skriptsprache geht das sicher, aber vielleicht geht's auch anders.

[Alloc]

Zitat von Matze:

Ein einfacheres Beispiel wäre ein Akkuladegerät. Bei den besseren kann man verschiedene Akku-Programme anlegen (NiMH, LiPo, LiIo, ...). Zu jedem Akku kann man Daten wie die Zellenanzahl, Kapazität etc. einstellen und entsprechend wird das Ladeprogramm gestaltet.

Naja, hier wird halt kein Programm verändert. Das Ladegerät hat hier fest einprogrammierte Programme, du änderst lediglich einzelne Parameter, die dann zB die Variable "Vout" oder so ändern würden, damit das Programm die Ausgangsspannung der Zellenzahl anpasst. Das ändert aber nichts am eigentlichen Programm.

[WM_CLOSE]

hm, vielleicht ist es tatsächlich etwas aufwändig, das Timing mit AVR8 hinzukriegen.

Man könnte überlegen, ob man auf ein ARM-Board umsteigt. Und zwar mit von Neumann Architektur, dann kann man beliebige Kompillate z.B. von einer SD-Karte ausführen ohne den µC kaputzuflashen. Das wird etwas Teurer und man braucht erst recht etwas externe IOs, aber das ist eine skalierbare Umgebung wie der PC.
PS: Ich würde ein fertiges ARM-Board einem Eigenbau vorziehen, da es dann doch komplizierter ist als ein 8-Bitter.


Das mit dem ATmega hat übrigens schon jemand gemacht. Es ist eben ein gewisser Aufwand, das so zu optimieren, dass man mit 50Hz noch messen kann

[Robotiker]

Der Knackpunkt ist meiner Meinung nach die Scriptsprache (die kostet viel Rechenleistung) und die Forderung sie auf dem Gerät editieren zu können (das macht das Programm komplex).

Lässt man das weg und stöpselt zum Ändern des Scripts einen Laptop über USB an, kann man die ganze Geschichte mit ein paar Komponenten erschlagen.

Beispiel:

Man nehme eine Conrad C-Control Mega128 mit Project-Board (nicht Application Board), dazu aus gleichem Hause den RS232-USB Konverter und das SD-Karten Interface. Alles zusammen knapp 100 Euro. Die Programmiersoftware gibts kostenlos zum Download und kann eine Art VB-Script, ein abgespecktes C und Assembler. Im Controller läuft ein vorinstallierter Bytecodeinterpreter.

Auf dem Board ist eine halbe Europakarte als Lochraster frei, da kann man die 24 V und 4..20 mA Interfaces verbauen.

Optimal wären dazu eine Tastatur und ein Display mit I2C-Bus, ansonsten muss man schauen, ob noch genug Ports frei wären, um etwas anderes anzuschliessen.


Ansonsten bleibe ich bei meiner Analyse: Bis auf die Scriptsprache ist das gewünschte Teil nichts anderes als eine SPS. Die ganze Hardware und die zyklische Programmausführung kauft man da gleich mit, Modelle mit Display, die auf Speicherkarten schreiben können, gibt es da auch. Auch hier gilt: Will man auf dem System eine eigene Scriptsprache implementieren, muss man bei Prozessor, Speicherplatz und Programmierfähigkeit ein paar Stufen höher greifen ...

[Matze]

Hallo,

konfigurierbar müssen die Programme sein. Der Ablauf selbst ist jedoch immer sehr ähnlich.
Ich denke, dass ich das auch ohne Skriptsprache hinbekommen kann. Nur konfigurieren (Messzeiten, ...) muss sein und zwar so, dass das auch gespeichert wird. Evtl. auf der genannten Speicherkarte.

Wenn das mit einem Etmel-MC geht, wäre das praktisch, da ich damit schon gearbeitet habe.
Die Skriptsprache ist für mich doch etwas zu komplex.

[BUG]

Zitat von Matze:

Wenn das mit einem Etmel-MC geht, wäre das praktisch, da ich damit schon gearbeitet habe.

Atmel?

Da "Skriptsprache" gesagt wurde und bei Lua angeblich bei jedem Feature überlegt wird, ob es auch auf einer Mikrowelle laufen würde, habe ich mal danach gesucht:

Lua on Atmel http://www.eluaproject.net/

Keine Ahnung wie gut das funktioniert, aber vom kurzen Überfliegen her sieht es ganz cool aus.