Hi,
wir planen gerade in einer kleinen Gruppe eine "universelles"
Frontend für Logic Analyser zu entwickeln. Universell soll heißen,
durch Plugins/Module an nahezu beliebige Hardware anzupassen und zu
erweitern, so plattformunabhängig wie möglich, skalierbar und als
OpenSource völlig frei :-)
Wie seht ihr den Bedarf an einer solchen Software? Was würdet ihr euch
von so einer Software wünschen?
Siehe dazu auch den Thread in PC-Programmierung:
http://www.mikrocontroller.net/forum/read-8-128949.html#new
Ich freue mich über jeden konstruktiven Kommentar zur Idee
Christian
Wollt Ihr euch nur auf Logic Analyzer beschränken?
Die Idee mit den Erweiterungen klingt eher nach LabView
http://www.ni.com/labview/ (man beachte die Preise).
Und genau sowas würde ich mir auch wünschen. Ich hab auch schon
überlegt, so was selbst zu versuchen, aber das ist (wenn es gut werden
soll) sehr viel Aufwand.
Markus
Der Logic Analyser ist der Ansatz. Sich direkt auf die Implementation
einer eierlegende Wollmilchsau wie LabView zu stürzen, halte ich schon
fast für vermessen. Vor allem in Hinblick auf die Zeit bis zum ersten
Release.
Die Idee mit der Erweiterung ziehlt natürlich auch darauf ab, später
möglichst einfach anderes Equipment, wie analoge Datenerfassung á la
Oszi einbinden zu können. Allerdings werden wir zuerst sehen, dass wir
die LA-Version hinbekommen, wie wir uns das vorstellen. Danach ist
abzuwarten, wie und ob sich das Projekt mit ensprechender Dynamik
weiterentwickelt (hoffentlich nicht nur von uns). Und wenn das Programm
von einem solchen Paket "assimiliert" wird oder mutiert... auch gut,
eigentlich sogar noch besser...
Wir werden hoffentlich schon bald unseren Planungsstand (inkl.
Schnittstellen etc.) veröffentlichen, leider (?) kommt da noch ein
bisschen Weihnachten & Urlaub zwischen ;)
Natürlich muß da nicht als erstes Release ein ernsthafter
Labview-Konkurrent rauskommen (und ich bin auch nicht so der Fan von
grafischer Programmierung). Mir scheint nur die Beschränkung auf
Logikanalyser etwas einseitig. Wenn die Darstellung nur ein
Modul/Plugin ist, dann sollte sich das ziemlich einfach zu einem
Oszilloskop umbauen lassen.
Du hast aber natürlich völlig recht damit, daß man bei der Entwicklung
nichts überstürzen darf. Es gibt auf sourceforge bereits zu viele
ambitionierte aber tote Projekte.
Markus
Das wäre interessant. Aber bitte klein anfangen, damit was bei raus
kommt! LAbview kann keiner gebrauchen - viel zu kompliziert!
Meine Anforderungen für einen LA:
- Adaption an virtuelle Datenformate, die von anderen LAs geschrieben
wurden.
- Ein- und Ausblenden von unbelegten Bereichen ohne Signalwechsel mit
+/- Symbolik wie bei Dateiordnern
- Rekompression der Daten (Elimination von Leerinformation)
- Automatische Zoom und Scrollfunktionen
- Interpreterinterface für Daten in C/c++, damit man eigene Funktionen
realsieren und compilieren kann
- Grafische Auswertung von binären Datenströmen, z.B. Dezimation und
Summation, Integrale und Differenziale von Signalen
- Zomm von ausgewählten Bereichen und Speicherung nur DIÉSER Daten im
Sichtfenster
- Speicherung in diversen Formaten, idealerweise als input anderer
Analyzersoftware
Wie plant ihr die Anbindung an vorhandene Systeme ?
Ich plane den Kauf des Logic Port.
> Und ganz wichtig, bitte kein Java benutzen.
Wieso? Sicher gibt es viele, die sich ohne große Ahnung vom
Programmieren irgend einen Haufen Binärschrott zusammenklicken, aber das
kann dir bei anderen Programmiersprachen auch passieren. Vielleicht sind
es bei Java ein paar mehr davon, weil jeder WI'ler das im Studium
aufgetischt bekommen hat und sich jetzt für den größten Programmierer
hält, aber da kann Java ja nichts für.
Und in Zeiten wo alleine schon das Betriebssystem mehr Leistung braucht
wie der beste Ego-Shooter vor 2 Jahren lasse ich das Argument der
Ressourcenverschwendung auch nicht mehr gelten.
PS: Ich nutze Eclipse auf nem alten Laptop der <1GHz-Klasse unter Linux,
das tut wunderbar. Übrigens nicht zur Java-Programmierung ;-)
Grundsätzlich sollte man die Frage der zu verwendeten Programmiersprache
nach der Analyse/Design Phase stellen. Globale aussagen wie "Bitte kein
Java" sind dabei wenig hilfreich.
@HolgerB das mit dem Java ist schon berechtigt. Vergleich mal
OpenOffice mit Microsoft Office allein nur die geschwindigkeit...
Alle Java Apps sind ziemlich Träge und in Echtzeit bereichen nicht zu
gebrauchen.
Selbiges gilt aber auch z.b. für .net
Halbwissen und Vorurteile...
Openoffice ist natürlich NICHT in Java geschrieben. Java ist aber für so
Dinge wie eine LA-Software wunderbar geeignet, da die Software so ohne
Anpassung auf allen Plattformen läuft.
@Andreas Schwarz
Das Projekt ist zwar echt gut, nur wenn man das Board kaufen muß und
dann noch alles andere extra, lohnt es nicht.
Gibt's nichts anderes an Logikschaltungen, welche mit DIL-Fassungen?
Tatsählich Sorry ich dachte immer der kern sei auch in Java geschrieben
aber es sind tatsächlich nur teile. Entschuldigt diese Falschaussage.
The following areas of OpenOffice.org 2.0 depend on a JRE being present:
* The media player on Unix-like systems
* All document wizards in Writer
* Accessibility tools
* Report Autopilot
* JDBC driver support
* HSQL database engine, which is used in OpenOffice.org base
* XSLT filters
* BeanShell, the NetBeans scripting language and the Java UNO bridge
* Export filters to the Aportis.doc (.pdb) format for the Palm OS or
Pocket Word (.psw) format for the Pocket PC
* Export filter to LaTeX
Trotsdem bin ich der Meinung man muss gerade in solch zeitkritischen
Gebieten nicht unbedingt Java nutzen. Plattformunabhängigkeit erreicht
man auch anders günstig. Warum die Geschwindigkeit einschränken ?
So, ich bekomm den Gedanken jetzt auch nicht aus dem Kopf. Es wird jetzt
sicherlich stimmen geben die sagen, der Ulrich spinnt die vm ist
mittlerweile genau so schnell. Wie wärs damit hier auch mal was
produktives rauskommt mit nem kleinen Wettbewerb die paar Stunden würd
ich mal opfern. Allein schon um mal zu sehn wie wiet java wirklich in
Sachen Geschwindigkeit ist. Ich würd als Ziel eine einfach LA Software
sehen Hauptkriterium ist Portabilität und Geschwindigkeit. Zielsysteme
mind. Windows und Linux. Hardware würd ich sagen einfach Paralellport
ist man dann halt erstmal auf 0 oder 5V eingeschränkt und hat 8 Kanäle
zur verfügung. Für Hobby und lau sicherlich durchaus akzeptabel.
Features würd ich erstmal nur Datenaufzeichnung und anzeige sehen. Was
meint ihr ? Findet sich noch ein java Programmierer der mitmacht ?
Wo ist denn eine Logic Analyzer-Software zeitkritisch? Das Aufnehmen der
Daten macht das Gerät, die Software ist nur für die Darstellung und
Auswertung zuständig.
Ich würd das allein aus Interesse mal machen, jedoch bin ich erst am
Dienstag wieder zuhause, deswegen kann ich noch nicht anfangen.
Mich interessiert in wie weit Java da mithalten kann.
PS: Java kann nicht von sich aus auf den Parallelport/die Serielle
schnittstelle zugreifen. Dort werden binarys benötigt. Deswegen ists
schon mal nicht alleine mit Java zu lösen.
Hauke Radtki wrote:
> PS: Java kann nicht von sich aus auf den Parallelport/die Serielle> schnittstelle zugreifen. Dort werden binarys benötigt. Deswegen ists> schon mal nicht alleine mit Java zu lösen.
Da hätten wir schonmal genug Gründe die gegen Java sprechen...
Was mir an Java auch nicht gefällt: Die Programme sind schlecht
Transportierbar. Schreibe ich ein Programm in C(++) dann erstelle ich
eien EXE, kopiere diese auf eine CD o.ä. und starte das Programm auf
einem anderen PC.
Bei Java wird immer das JRE oder wie das heißt benötigt. Man kann die
Software also nicht auf Rechnern verwenden auf denen man nichts
installieren kann/darf.
Aber bevor jetzt wieder ein Java/C Streit ausbricht: Solange die
Software läuft, kann die Logic-Analyser Software von mir aus auch in
Java geschrieben sein. Sowas suche ich nämlich auch schon lange. Mein
selbstgeschriebenes Programm ist nämlich ziemlicher Mist. Da läuft sogar
Windows stabiler..
Das wichtigste daran ist meiner Meinung nach eine leicht anzupassende
und flexible Schnittstelle zur Hardware.
Wie ich vorher schon geschrieben habe würde mich so ein Projekt auch
interessieren und das ganze ist natürlich eine gute Möglichkeit Java
Kenntnisse zu erweitern. Habe zwar schon EINIGES mit Java gemacht aber
noch nie mit der GUI oder mit externer Hardware zu tun gehabt.
Wenn man sich nur mal ansehen will wie so ein LA in Java aussehen kann,
dem empfehle ich http://de.sump.org/projects/analyzer/.
Das mit dem Parallel Port hört sich natürlich erst mal schön + günstig
an. Bei genauerer Betrachtung bin ich jedoch der Meinung das er sich aus
verschiedenen Gründen nicht eignet:
- Der Parallel Port ist ein Drucker Port und wird auch vom
von Java nicht direkt unterstützt. Wer hier jetzt gleich schreit
"Wieder ein Java nachteil" dem sei gesagt:
Windows XP + .NET und Konsorten können auch nicht von Hause aus auf den
direkt auf die Hardware des Parallel Port zugreifen. Hier werden auch
spezielle Treiber benötigt (PortIO, ...).
- Der Parallel Port müsste dauernd "gepollt" werden. Das würde
den PC auch mit jeder anderen Programmiersprache lahm legen.
- Wegen Interrupt latenzen würde das Ergebnis trotzdem nicht genau
sein.
Also wäre mein Vorschlag das mit einem AVR/PIC zu machen und die Daten
in das interne RAM zu schreiben. Dann könnte man das ganze seelenruhig
über UART /USB an den Rechner schicken.
Und für die Hartgesottenen unter uns wäre es auch kein Problem das ganze
mit einem FPGA zu machen. Da wären dann Samplingraten >100 MHZ auch kein
Problem.
Ein paar Stunden würden für so ein Projekt jedoch sicher nicht reichen
wenn das ganze was hermachen soll. (Auch weil ich schon im Hinterkopf
einen LA + Oszi + Freq. Generator habe :-) )
Man könnte ja die schnittstelle zur Hardware in C(++) oder so schreiben
und die eigentliche Anwendung inkl. darstellung und vielleicht auch
interpretation Java überlassen. So hätte man einen kleinen Teil, der
beliebig austauschbar ist, und so an jede Hardware/jedes Betriebssystem
anpassbar ist.
Benedikt K. wrote:
> Hauke Radtki wrote:>> PS: Java kann nicht von sich aus auf den Parallelport/die Serielle>> schnittstelle zugreifen. Dort werden binarys benötigt. Deswegen ists>> schon mal nicht alleine mit Java zu lösen.>> Da hätten wir schonmal genug Gründe die gegen Java sprechen...>
Da würdes du aber auch gegen so ziemlich jede andere Programmiersprache
sprechen.
Auch C / C++ VB und was es da sonst noch so gibt können nicht auf
die Serielle / Parallele Schnittstelle zugreifen. Das macht man immer
über OS APIs (zumindest in zeiten von Windows XP Vista Linux).
Und diese kann mann natürlich auch (wenn auch nicht so komfortabel wie
mit C) in Java ansprechen (Stichwork JNI).
Mit externer Hardware gibt es natürlich auch keine so grossen
kritikpunkte an Java mehr. Ich bin jedoch davon ausgegangen das man das
auch ohne externe Hardware lösen möchte. Genauigkeit ist in niederen
Frequenzen auch erreichbar. Bis 500 khz dürfte das auch mit dem
Paralellport+Rechner zu machen sein und um I2C oder SPI oder um ein LCD
Display zu überwachen so die Standart Hobby Sachen zu machen reicht das.
Man könnte das mit nem Pluginsystem machen so das man später auch eigene
Hardware oder Fremdhardware einfach anbinden kann. Das war mein
hauptargument gegen Java. Ich wollte diese ohne Hardware Möglichkeit
nicht verbauen. Es gibt 2 Möglichkeiten die dort sinn machen. Eine
Zeitlich garantierte niederfrequente Darstellung so bis 300 oder 500 khz
und eine Darstellung in der sooft es geht gepollt wird aber die Zeiten
nicht garantiert werden können weil eben das Betriebssystem
dazwischenfunken kann. Kann auch Sinn machen wenn es rein um den
Signalverlauf geht und nicht um die Zeit.
Würd mich auch bereiterklären das mal zu machen... werden halt vorerst
nicht allzuviele Features dran sein.
