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

[Matze]

Vielen Dank für die Antworten.

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).
Und stimmt, das Display könnte auch ein Vollgrafisches sein und nur für alphanumerische Zeichen verwendet wird.

Dass 50 Hz eng werden ist schlecht. Wenn ich an einige Messkarten denke, die 300€ kosten, aber mit 200 kHz Daten erfassen und digital filtern können, müsste das doch in dem günstigen Preissegment mit 50 Hz gehen.

Ich mache mir heute ein paar Gedanken zu dem Vorhaben. Vielleicht ist das auch zu komplex, wobei es eine nette Herausforderun wäre ...

Erst gestern habe ich gelesen, dass man sich für 200€ einen Quadrocopter bauen kann (inkl. 4 Motoren + Motorregler, gyro etc). Und dagegen ist meines eine eher "einfache" Anwendung.

[Alloc]

Naja, die 50 Hz an sich sind sicher in dem Preissegment machbar. Aber der konkret genannte µC ATmega32 (bzw. generell die AVR8) sind halt mit deinen Anforderungen zumindest nach meiner Einschätzung überfordert, *insbesondere* durch die Skript-Sache. Ohne dies wäre es sicher locker machbar
Nachträgliches anbringen von USB/Ethernet etc ist natürlich machbar, dann muss man dies aber dennoch vorab schon relativ konkret einplanen, damit man die entsprechenden Schnittstellen rausführt und nicht später feststellt, dass man für die parallele Busanbindung des Ethernetcontrollers ja noch die IOs 33-48 vom µC bräuchte (alles Beispielhaft)

Grüße,
Chris

[jfheins]

Zitat von Matze:

Vielen Dank für die Antworten.
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).

Dann kannst du es auch direkt einbauen statt nur die Möglichkeit dafür vorzuhalten
Wenn du z.B. die COM-Ports nicht magst, kannst du auch einen USB-zu-RS232 Chip auf die Platine löten, dann ists nach außen hin ein schicker Mini-USB Port - nur am PC wird dann spezielle Software nötig, um zu kommunizieren. (z.B. HyperTerminal, irgendwas was mit inem COM Port kommunizieren kann)

Zitat:

Dass 50 Hz eng werden ist schlecht. Wenn ich an einige Messkarten denke, die 300€ kosten, aber mit 200 kHz Daten erfassen und digital filtern können, müsste das doch in dem günstigen Preissegment mit 50 Hz gehen.

Diese Messkarten haben auch nur einen speziellen Einsatzzweck, auf den sie optimiert wurden. Du möchtest ja aber so eine Art Interpreter da rein integrieren:

Zitat:

Später möchte ich Abläufe über die Tastatur und das Display eingeben können. Also etwas wie "Ausgang x auf 10 mA setzen, warten bis der Eingang y auf 15 mA steigt, dann digitale Ausgänge a, b und c schalten ...". Diese müssen gespeichert und wieder geladen werden können.

Das ist einfach mehr Rechenaufwand als 200000 mal in der Sekunde einen Wert zu wandeln und abzuspeichern. (A/D Wandler sind bei viele Mikrocontrollern ja schon auf dem Chip integriert)

Idee:
Wenn du den Anschluss der zum flashen des µC verwendet wird, rausführst kannst du das Skript am PC zu Quellcode verarbeiten, den Quellcode dann mit dem avr-gcc (oder so) kompilieren und das Ergebnis flashen Die Kompilate ließen sich dann auch am PC verwalten und jederzeit wieder auf den µC aufspielen.
Dann brauchst du aber noch einen PC in der Nähe

[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.