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
Ich wäre das hier mal wieder auf, ist daraus irgendwas geworden? ich hätte großes Interesse.
Dazu kann ich (leider) nichts sagen... Wäre aber an einem entsprechenden Projekt gerne beteiligt...
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.
Wenn daraus was geworden wäre hätte man hier sicher etwas mit bekommen oder ?
Und ganz wichtig, bitte kein Java benutzen.
> 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.
Bitte kein Java! Bitten sollten geäußert werden können.
Aber weiter bringen tut es die Sache an sich nicht... schade...
@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
Also ich hab letzte woche Vista gesehen - ich glaub das ist auch in Java geschrieben :-)
BTW - Weder OpenOffice noch Microsoft Office sind in Java geschrieben ?!
Allenfalls sind das Basicinterpreter, in Java geschrieben.
Natürlich ist OpenOffice in Java geschrieben. Microsoft Office natürlich nicht das hab ich als Geschwindigkeitsvergleich dagegen gestellt.
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.
Wobei ich mich jetzt hier jetzt schon irgendwie hab dazu hinreisen lassen das ganze in Java machen zu wollen :-) Systemanalytisch natürlich absolut 6-
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.
OK, damit hat sich das dann wohl gegessen.
Hallo! Hier auch ein LA-Projekt mit AT89C2051. Die wichtigste Idee ist hier die Datenkompremierung. http://wwwiti.cs.uni-magdeburg.de/~buchmann/privat/logger.htm mfg W.K.
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.