mikrocontroller.net

Forum: Projekte & Code Comvisu für Linux


Autor: Est Est Est (comvisu)
Datum:
Angehängte Dateien:

Bewertung
1 lesenswert
nicht lesenswert
Es gibt nun auch eine Linux-Version meines Programms Comvisu zur 
Visualisierung von Mikrocontrollerdaten über COM und IP/UDP. Die 
Funktionsweise und Features im Vergleich zur Windowsversion sind die 
gleichen.

Es gibt momentan folgende Instrumente:
- Numerische Anzeige
- Numerische Ausgabe
- Analoganzeige/-schieber
- Balkenanzeige
- Zeitdiagramm
- Mehrfachzeitdiagramm
- Fernanzeige
- Zeichenausgabe
- Taster
- Schalterleiste
- LED-Anzeige
- Bild-Anzeige
- E/A-Kanal
- Dateirekorder

In diesem Thread bitte nur Probleme/Anregungen posten, die speziell die 
Linuxversion betreffen, für allgemeine Anregungen, Instrumenten-Wünsche 
etc. bitte im Ur-Thread schreiben:
Beitrag "Serielle Visualisierung mit Comvisu"

Linux-Versionen werd ich immer hier reinstellen (wenn Bedarf da ist~)

Es gilt das gleiche wie für die Windowsversion: Frei zur privaten 
Nutzung; Kommerzielle Nutzung ist nicht gestattet.

Die Installation ist einfach: Es müssen lediglich die beiden Dateien im 
Unterordner "QtBinding32bit" in das Verzeichnis /usr/lib/ kopiert 
werden. Die Programmdatei Comvisu kann dann aus einem beliebigen 
Verzeichniss heraus gestartet werden. Eventuell muss noch das Attribut 
'ausführbar' gesetzt werden.
Damit die (serielle) Schnittstelle verbunden werden kann, müssen dem 
Benutzer in Linux Rechte zugewiesen werden. Wer mit Schnittstellen 
arbeitet weiß das ja:
$ sudo adduser username dialout

Bisher konnte ich leider nur auf dem Rechner testen, wo ich auch 
kompiliert habe. D.h. ich hoffe jetzt das Beste, dass es bei euch auf 
Anhieb läuft.

Viele Grüße

[Datei auf Wunsch des TE ausgetauscht. - Mod]

: Bearbeitet durch Moderator
Autor: Jonas G. (jstjst)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

schön das es eine Linuxversion gibt allerdings funktioniert es bei mir 
schon mal nicht.
Ich bekomme bei Start folgende Fehlermeldung:
./ComvisuV045: error while loading shared libraries: /usr/lib/libQt4Pas.so.5: file too short

Die beiden Dateien hab ich kopiert.
Ich nutze Linux Mint 17.3

Gruß Jonas

Autor: Est Est Est (comvisu)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Es scheint daran zu liegen, dass ich die Dateien in Windows kopiert habe 
(Eines ist ein Symlink). Im Anhang die original-gezippten Dateien. Unten 
der Link, wo man sie auch direkt bekommt.

Es sind nur die Dateien libQt4Pas.so.5 und libQt4Pas.so.5.2.5 notwendig, 
der Speicherort müsste schonmal stimmen.

http://users.telenet.be/Jan.Van.hijfte/qtforfpc/V2...

Autor: Jonas G. (jstjst)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also ich hab jetzt alle Dateien aus dem 2. Archiv nach /usr/lib kopiert 
und dann ging es. Mehr hab ich noch nicht ausprobiert aber ich freu 
mich, dass es jetzt eine Linux Version gibt.

Gruß Jonas

Autor: Harry L. (mysth)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Kleiner Tip:
Dzie Libs die man selbst händisch in eine Distribution einfügt gehören 
in /usr/local/lib ;)

Autor: Est Est Est (comvisu)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Neue Version V0.5

Neuerungen siehe "Hauptthread":
Beitrag "Re: Serielle Visualisierung mit Comvisu"


Harry L. schrieb:
> in /usr/local/lib ;)
Das habe ich ausprobiert, funktioniert bei mir allerdings nicht (k.A. 
warum). Also lieber in /usr/lib/ packen~

Autor: Est Est Est (comvisu)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Version V0.51:
- Fehler beim Ändern der Größen behoben, betroffene Instrumente:
Fernanzeige, Zeichenausgabe, Mehrfachzeitdiagramm.
- Tasterinstrument kann nun optional auch einen frei definierbaren
Text/Zahl senden

Autor: Petr (Gast)
Datum:

Bewertung
4 lesenswert
nicht lesenswert
Schade, dass man es nicht als Quellcode runterladen kann. Ich bin zu 
paranoid um fremde binaries einfach mal so auf meinem PC laufen zu 
lassen...

Autor: Est Est Est (comvisu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Petr schrieb:
> Schade, dass man es nicht als Quellcode runterladen kann. Ich bin zu
> paranoid um fremde binaries einfach mal so auf meinem PC laufen zu
> lassen...
Das versteh ich schon. Aber deswegen meinen Quellcode freigeben möchte 
ich auch nicht.
Ist halt ein Hobbyprojekt, wo nicht ein großer Name dahinter steht der 
Vertrauen schafft.
Wenn ich eine Version hochlade, bin ich hier immer angemeldet. Das 
Vertrauen muss eben mit der Zeit kommen.
Es ist auch keine Installation notwendig und damit auch keine 
Superuser-Rechte (Für die Fremdbibliothek, welche in das Dateisystem 
kopiert werden muss, sind Sourcen verfügbar).
Natürlich versichere ich, keinen Blödsinn zu treiben. Das Programm 
versucht auch nicht "rauszutelefonieren" o.ä.

Autor: Weinga Unity (weinga-unity)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich bekomme unter Ubuntu 16.04 folgende Fehlermeldung noch:

./ComvisuV051: error while loading shared libraries: libQtWebKit.so.4: 
cannot open shared object file: No such file or directory

libqtWebKit4 habe ich installiert...

Hast du eine Idee wo das Problem sein könnte?

Danke.

Autor: Weinga Unity (weinga-unity)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
OK, Problem gefunden.

32bit Version von libqtwebkit verwenden, dann läuft das Programm auch.

Autor: Est Est Est (comvisu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Weinga U. schrieb:
> OK, Problem gefunden.
> 32bit Version von libqtwebkit verwenden, dann läuft das Programm auch.
Das ist ein Pronblem, das mir auch schon aufgefallen ist. Die 
Bibliotheken für 32bit und für 64bit heißen unglücklicherweise auch 
genau gleich. Falls jemand zwecks anderen Abhängigkeiten die 32bit 
Bibliothek nicht verwenden kann, kann ich auch eine 64bit Version der 
Comvisu bereitstellen. Da es aber sonst keinen Vorteil bietet (ist nur 
zusätzlicher Kompilieraufwand) und den Nutzer vor die Frage stellt, ob 
er jetzt die 32 oder 64bit-Version verwenden soll, würde ich gerne 
darauf verzichten.

Autor: Carl Drexler (jcw2)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Auf welchen modernen PC mit Linux läuft denn noch 32bit?
Im 64Bit Mode hat so eine Kiste einen anderen Befehlsatz, der weniger 
Altlasten enthält.
Z.B. 16-General-Purpose-Register z.B., dazu sinngemäß Herb Sutter, Chef 
der C++-Compiler-Truppe von Microsoft (um das nicht als rein Linux ab zu 
tun): "mit den 8-(nicht ganz)-Universalregistern im 32bit Mode, ist eine 
vernüftige Optimierung durch den Compiler kaum hin zu bekommen". Und 
Register sind die schnellsten Caches überhaupt.

Wozu also überhaupt auf PC-Linux in 32bit entwickeln? Und wenn es die 
Tools nicht erlauben, dann hat das Problem auch schon einen Namen.

Und 64bit Software ist mit nichten doppelt so groß. Eine Ubuntu 12.04 
Installation (danach hab ich's nie mehr mit 32bit versucht) belegt in 
der 64Bit Version spürbar weniger Platz als die 32bit Variante der exakt 
selben Distribution. Und schneller ist sie auch. Dank Befehlssatz, den 
AMD ohne Rücksicht auf alte 8080-Kunden entwerfen konnte.

Wenn man aber tatsächlich mit 32bit Software konfrontiert wird, deren 
Sourcecode man nicht hat, dann kann man mit geringem Aufwand die 
I386-Laufzeitumgebung installieren. Oh, ich sehe gerade, Ubuntu 16.04 
ist noch nicht so weit, also bitte nur 64Bit.

BTW, daß Herb sich nicht durchsetzen konnte, sieht man im 
Windows-Taskmanager. Leider!

Autor: Dennis X. (debegr92)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
HAMMER!
Probiere ich ähhh nach den Klausuren direkt aus ;-)

Autor: Est Est Est (comvisu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Carl D. schrieb:
> Auf welchen modernen PC mit Linux läuft denn noch 32bit?
Keine Ahnung, es scheint aber schon noch Leute zu geben, die 32bit Linux 
verwenden.

> Im 64Bit Mode hat so eine Kiste einen anderen Befehlsatz, der weniger
> Altlasten enthält.
> Z.B. 16-General-Purpose-Register z.B., dazu sinngemäß Herb Sutter, Chef
> der C++-Compiler-Truppe von Microsoft (um das nicht als rein Linux ab zu
> tun): "mit den 8-(nicht ganz)-Universalregistern im 32bit Mode, ist eine
> vernüftige Optimierung durch den Compiler kaum hin zu bekommen". Und
> Register sind die schnellsten Caches überhaupt.
>
> Wozu also überhaupt auf PC-Linux in 32bit entwickeln? Und wenn es die
> Tools nicht erlauben, dann hat das Problem auch schon einen Namen.
Ich kompilier sowieso auf einem 64bit Linux, für mich macht das keinen 
Unterschied ob ich 64bit oder 32bit anbiete. Nur beides ist halt ein 
Zusatzaufwand.

> Und 64bit Software ist mit nichten doppelt so groß. Eine Ubuntu 12.04
> Installation (danach hab ich's nie mehr mit 32bit versucht) belegt in
> der 64Bit Version spürbar weniger Platz als die 32bit Variante der exakt
> selben Distribution.
Der Hauptgrund für ein 32bit Linux ist sicherlich, dass man es eben 
schon hat und keinen Grund für eine Neuinstallation sieht.

> Wenn man aber tatsächlich mit 32bit Software konfrontiert wird, deren
> Sourcecode man nicht hat, dann kann man mit geringem Aufwand die
> I386-Laufzeitumgebung installieren.
Bei mir musste ich nichts installieren (LinuxMint 17, 64bit). Ich war 
auch der Meinung, das die 32bit Version auf allen gängigen 64bit Linux 
(PC) läuft.

Mal die Frage in die Runde: 32bit oder 64bit?

Autor: Carl Drexler (jcw2)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bei Ubuntu 14.04 mußte ich ia32-Libs nachinstallieren. Und für 16.04 ist 
es aktuell noch nicht fertig.

Autor: Bernd D. (bernd_d56) Benutzerseite
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Est Est E. schrieb:
> Mal die Frage in die Runde: 32bit oder 64bit?

Also gesetzt den Fall, man plant eine Anwendung auf einen Raspberry Pi, 
wird man 32 Bit benötigen.
Ein alter 15" Monitor mit dahinter geklebten Raspberry könnte eine Prima 
Kontrolltafel für ein Labor, Heizungszentrale, Wetterstation, usw. sein

Autor: Est Est Est (comvisu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
OK, dann belasse ich es zunächst bei der 32bit Version. Wenn es jemand 
wirklich nicht zum Laufen bekommt, kann ich auch eine 64bit Version 
erstellen.

Autor: Est Est Est (comvisu)
Datum:
Angehängte Dateien:

Bewertung
1 lesenswert
nicht lesenswert
Neue Version V0.6

Neuerungen siehe Hauptthread:
Beitrag "Re: Serielle Visualisierung mit Comvisu"

Ich hab jetzt auch eine Homepage eingerichtet, wo man die Comvisu 
alternativ runterladen kann:
http://www.comvisu.de

Vielleicht erhöht das ja die Seriösität~

Petr schrieb:
> Schade, dass man es nicht als Quellcode runterladen kann. Ich bin zu
> paranoid um fremde binaries einfach mal so auf meinem PC laufen zu
> lassen...

Autor: Carl Drexler (jcw2)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Est Est E. schrieb:
> Ich hab jetzt auch eine Homepage eingerichtet, wo man die Comvisu
> alternativ runterladen kann:
> http://www.comvisu.de

Dann mach besser noch ein Impressum dran, bevor dich ein "freundlicher" 
Anwalt dazu auffordert. Web und anonym geht leider nicht zusammen.

: Bearbeitet durch User
Autor: Est Est Est (comvisu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Carl D. schrieb:
> Dann mach besser noch ein Impressum dran,
Hast du es mittlerweile gefunden?
Hab die Seite (nur) im Firefox und IE getestet, es wird jeweils sauber 
angezeigt.

Autor: Dennis X. (debegr92)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Moby A. schrieb im Beitrag #4696061:
> Carl D. schrieb:
>> Dann mach besser noch ein Impressum dran
>
> Dann schau besser noch genauer hin.

Ich hab es gefunden ;-)
BTW: Aus Schorndorf, ist ja witzig. direkt um die Ecke! Da komm ich doch 
mal rum! :D

Autor: Est Est Est (comvisu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
:-)

Und plötzlich ist das Impressum die meistbesuchte Seite~~

Autor: Est Est Est (comvisu)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Neue Version V07.

Neuerungen siehe Hauptthread:
Beitrag "Re: Serielle Visualisierung mit Comvisu"

Autor: Est Est Est (comvisu)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Neue Version V0.80 natürlich auch für Linux:-)

Neuerungen siehe Hauptthread:
Beitrag "Re: Serielle Visualisierung mit Comvisu"

Das neue Instrument Tongeber funktioniert (bisher) allerdings unter 
Linux nicht.

Download auch direkt unter Comvisu.de

Autor: Est Est Est (comvisu)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Neue Version V0.90

Neuerungen (Details siehe Hauptthread):
- Neue Schnittstellenart: URL-Request
- Neues Instrument Lookup-Tabelle
- Neue Funktionen (speicherwertig): COUNT,LAST,Z,SEQMIN,SEQMAX,FLOATAVG
- Neue Funktionen ANS und NULL
- Zeitdiagramm löst nun bei jeder Abtastung eine Berechnung aus
- Fehler in XYTimeChart beseitigt

Autor: Weinga Unity (weinga-unity)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

zur Info: der Link zum Linux-File funktioniert auf deiner Web-Site 
nicht.

Jetzt werde ich HTTP probieren weil ich es wirklich brauche :-)

Lg

Autor: H. S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
und ?

Autor: Est Est Est (comvisu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich hatte scheinbar die Linuxversion nicht eingestellt, der Download 
sollte jetzt wieder funktionieren!

Grüße

Autor: R. Manfred B. (pwgdrx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

läuft das Teil auch auf dem raspberry (wheezy)?

Gruß

Autor: Est Est Est (comvisu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Manfred,

auf dem Raspberry läuft es nicht, ist ja ein anderer Befehlsatz (ARM 
statt x86). Lazarus kann zwar auch dafür kompilieren, aber da ich keinen 
Raspi habe, kann ich das nicht testen. Und ohne gewisse Anpassungen 
funktioniert es auf Anhieb nie.

Viele Grüße

Autor: OQ (Gast)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Est Est E. schrieb:
> Hallo Manfred,
>
> auf dem Raspberry läuft es nicht, ist ja ein anderer Befehlsatz (ARM
> statt x86). Lazarus kann zwar auch dafür kompilieren, aber da ich keinen
> Raspi habe, kann ich das nicht testen. Und ohne gewisse Anpassungen
> funktioniert es auf Anhieb nie.
>
> Viele Grüße

Eben: Quellcode bitte.
Dann steigt die Chance SCHLAGARTIG dass Du auch Unterstützung bekommst 
f. HW welche Du nicht hast.

32bit: RasPi (armhf), SPARC, MIPS, 68k
64bit: UltraSPARC, AXP, PPC

Autor: alf42 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hi,

wie schaut es aus, wenn du den source nicht zur verfügung stellen 
möchtest,
würdest du eventuell eine 64bit version bauen ???

Autor: Est Est Est (comvisu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

Das kann ich machen. Ich muss nur schauen, wie ich das mit den 
(gleichnamigen) QT-Bibliotheken dann mache. Also etwas Geduld~

Autor: Est Est Est (comvisu)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Neue Version V0.95. Es gibt nun auch eine 64bit Version. Zu beachten 
ist, dass sich die mitgelieferte QT-Bibliothek für die 32 und 
64bit-Version unterscheidet, es muss die passende installiert sein.

Neuerungen siehe Hauptthread:
Beitrag "Re: Serielle Visualisierung mit Comvisu"

Downloads auch unter http://Comvisu.de

Autor: GPL (Gast)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Est Est E. schrieb:
> Petr schrieb:
>> Schade, dass man es nicht als Quellcode runterladen kann. Ich bin zu
>> paranoid um fremde binaries einfach mal so auf meinem PC laufen zu
>> lassen...
> Das versteh ich schon. Aber deswegen meinen Quellcode freigeben möchte
> ich auch nicht.
> Ist halt ein Hobbyprojekt

Sehr interessante Einstellung. Normalerweise ist genau das Gegenteil der 
Fall.

Autor: Markus Simon (blackwatcher)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe heute versucht ComVisu unter Xubuntu 32 Bit Version zu 
installieren.
Habe mir das Archiv runtergeladen und die beiden Dateien nach /usr/lib 
entpackt und die ComVisu Datei habe ich ausführbar gemacht.
Wenn ich draufklicke passiert garnichts. Die ComVisu Datei liegt in 
einem eigenen Verzeichnis unterhalb meines Home Verzeichnises.
Hat jemand eine Idee woran das liegen könnte?

Autor: Est Est Est (comvisu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Markus,

das hört sich an, als ob eine falsche Bibliotheksversion installiert 
ist. QT muss auch installiert sein, ich weiß nicht, ob das auf allen 
Linuxen schon dabei ist.

Starte die Comvisu mal über die Shell: ./ComvisuV095
Wenn was mit der Bibliothek nicht stimmt, sollte in der Shell dann eine 
Fehlermeldung angezeigt werden.

Viele Grüße

Autor: Markus Simon (blackwatcher)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dankeschön. Daran hat es gelegen. Es war unter meinem Xubuntu 
tatsächlich kein QT Framework installiert.Jetzt startet die Software 
einwandfrei!

Beitrag #5006142 wurde von einem Moderator gelöscht.
Beitrag #5006290 wurde von einem Moderator gelöscht.
Autor: Est Est Est (comvisu)
Datum:
Angehängte Dateien:

Bewertung
1 lesenswert
nicht lesenswert
Neue Version Comvisu V1.0
Neuerungen siehe Hauptthread:
Beitrag "Re: Serielle Visualisierung mit Comvisu"

Downloads auch unter Comvisu.de

Viele Grüße

Autor: Georg B. (georgb)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
Ich wollte mal fragen, ob sich inzwischen in Richtung Comvisu für 
RaspberryPi etwas getan hat? Wäre ja eigentlich prädestiniert für sowas.
Hier im Forum gäbe es sicherlich genügend Leute zum Testen ;-)

Grüße,
Georg

Autor: Est Est Est (comvisu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Georg,

es hat sich in dieser Richtung nichts getan, es mangelt mir immernoch an 
einem Raspi.

Viele Grüße

Autor: Est Est Est (comvisu)
Datum:
Angehängte Dateien:

Bewertung
1 lesenswert
nicht lesenswert
Testweise hier eine Version für den RASPBERRY PI, bzw. für ARM Linux mit 
dem Befehlssatz ARMV6. Getestet habe ich es lediglich auf einer 
Emulation eines Raspi I. Sollte aber auf allen Raspis laufen. Zur 
Performanz kann ich nichts sagen, die Emulation war sehr träge. Ich 
bitte also um Rückmeldung. Die Installation funktioniert in gleicher 
Weise wie bei der Linux-PC-Version. Eine Kurzanleitung ist beiliegend.

Nach meinem Verständnis sollte das Programm auch auf Nicht-Raspis 
laufen, wie dem Beagle Bone bspw. Das wäre auch zu testen, bzw. 
vielleicht kennt sich jemand genauer aus.

Wenns nicht startet empfiehlt sich immer der Start über die Shell, dort 
sind dann evtl. Hinweise/Fehlermeldungen.

Viele Grüße

Autor: H. S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bekomme Ich mit dem Programm auch USB-Geräte dran?

Autor: Est Est Est (comvisu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich hatte jetzt die Möglichkeit die Comvisu auf einem Raspberry 2 B 
(Raspbian) zu testen, läuft! Die serielle Schnittstelle und 
Netzwerkverbindungen funktionieren auch.

Auf Raspbian muss noch das Webkit für Qt4 installiert werden, sonst 
startet die Comvisu nicht:
 sudo apt-get install libqtwebkit4


@multiprogger
USB-Seriell-Wandler funktionieren, ich hab bei mir am Rechner gar keine 
Seriellen mehr. "Echte" USB-Geräte werden nicht unterstützt.

Autor: Günter R. (galileo14)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Est Est Est,

ich habe mir jetzt einen Raspberry Pi 3 Mod. B zugelegt. Super Teil. 
Jetzt will ich die Comvisu für ARM zum Laufen bringen. Die libqtwebkit4 
habe ich installiert wie oben beschrieben. Benötigt man hier auch die 
beiden Dateien libQt4Pas.so.5 und libQt4Pas.so.5.2.5? Enthalten diese 
Binärcode, sodaß spezielle ARM-Versionen notwendig sind, oder sind die 
normalen Linux-Versionen hier auch verwendbar?

Als serielle Schnittstellen habe ich ein RS232/USB-Teil (Renkforce) bei 
Conrad gekauft (kostet um die 10 Euro), das funktioniert super und 
stellt zwei RS232 zur Verfügung (ttyUSB0 und ttyUSB1), benötigt keine 
extra Treiber und wird vom Raspbian sofort erkannt.

Günter

Autor: HimboKusPokus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Benötigt man hier auch die
> beiden Dateien libQt4Pas.so.5 und libQt4Pas.so.5.2.5?
I.A. schon, *.so.* steht für Shared Objekts d.h. ähnlich wie 
*.o-Dateien aus den Compilern, nur eben für dynamic linking (also zur 
Laufzeit d. Programms, nicht at build time )

Die Idee ist dass solche *.so.* gemeinsam für mehrere Programme sind, 
gerne auch für Programme unterschiedlicher Herkunft, in verschiedenen 
Programmiersprachen geschrieben.

Natürlich gibt es auch SW-Pakete welche darauf bestehen nur ihre 
eigene *.so.* zu verwenden; das ist dann aber... "unsorgfältig" gemachte 
SW. (vulgo: Pfusch, ohne Sachverstand)

> Enthalten diese
> Binärcode, sodaß spezielle ARM-Versionen notwendig sind, oder sind die
> normalen Linux-Versionen hier auch verwendbar?
Ja: binärcode.
Nix speziell, nur passend zur CPU die den Code ausführen soll und dem BS 
das gerade läuft.
Genau so speziell/normal wie ein ausführbares Binärprogramm.

Autor: Est Est Est (comvisu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Günter,

gute Entscheidung~

Die beiden Dateien libQt4Pas.so.5 und libQt4Pas.so.5.2.5 sind Binaries 
(ARMv6), sie sind zusätzlich zum libqtwebkit4 erforderlich. Die 
Zip-Datei mit der Comvisu-Raspberry-Version enthält die entsprechenden 
Dateien. Wenn beides installiert ist, muss man evtl. noch dem User 
(Standard: pi) die Rechte zum Ausführen der Comvisu geben (Rechte 
Maustaste/Eigenschaften).

Viele Grüße

Autor: Günter R. (galileo14)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Est Est Est,

ich habe einige Probleme, Comvisu auf dem RaspberryPi zum Laufen zu 
bringen. Die libqtwebkit4 hatte ich ja schon installiert wie oben 
beschrieben. Nun hatte ich die beiden Dateien libQt4Pas.so.5 und 
libQt4Pas.so.5.2.5 (zunächst aus dem Comvisu-ZIP-File) in einen Ordner 
/usr/lib kopiert, ihnen die Berechtigungen "Jeder" für alle 
Eigenschaften gegeben (mit dem Dateimanager) und dann das 
Comvisu-Programm in einen eigenen Ordner /opt/Comvisu/ kopiert und ihm 
den kürzeren Namen "CV" und auch die Berechtigungen "Jeder" für alle 
Eigenschaften gegeben und das Comvisu-Programm CV nun aus dem 
MidnightCommander heraus gestartet.

Nun erscheint die Fehlermeldung "./CV: error while loading shared 
libraries: /usr/lib/libQt4Pas.so.5: file too short".

Was mag falsch sein? Vielen Dank für einen Hinweis.

Günter

Autor: Sheeva Plug (sheevaplug)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Günter R. schrieb:
> ich habe einige Probleme, Comvisu auf dem RaspberryPi zum Laufen zu
> bringen. Die libqtwebkit4 hatte ich ja schon installiert wie oben
> beschrieben. Nun hatte ich die beiden Dateien libQt4Pas.so.5 und
> libQt4Pas.so.5.2.5 (zunächst aus dem Comvisu-ZIP-File) in einen Ordner
> /usr/lib kopiert, ihnen die Berechtigungen "Jeder" für alle
> Eigenschaften gegeben (mit dem Dateimanager) und dann das
> Comvisu-Programm in einen eigenen Ordner /opt/Comvisu/ kopiert und ihm
> den kürzeren Namen "CV" und auch die Berechtigungen "Jeder" für alle
> Eigenschaften gegeben und das Comvisu-Programm CV nun aus dem
> MidnightCommander heraus gestartet.
>
> Nun erscheint die Fehlermeldung "./CV: error while loading shared
> libraries: /usr/lib/libQt4Pas.so.5: file too short".

Die vermutlich bessere Variante ist, herauszufinden, in welchem Paket 
die betreffenden Bibliotheken enthalten sind -- libqt4pas-dev oder 
libqt4pas5 -- und dann eines dieser Paket zu installieren, damit sind 
dann auch deren Abhängigkeiten befriedigt. Ich habe darum jetzt mit 
"sudo apt-get install libqt4pas-dev" auf meinem RasPi unter Raspbian 
GNU/Linux 8.0 (jessie) die entsprechenden Bibliotheken mit ihren 
Abhängigkeiten installiert, dann die Zip-Datei ausgepackt, dem Programm 
mit "chmod u+x ComvisuV101ARMV6Linux" Ausführrechte gegeben und siehe 
da: läuft. Den im Zip-Archiv enthaltenen Tarball mit den Linux-Libraries 
habe ich nichtmal ausgepackt.

Ansonsten sollten libQt4Pas.so, libQt4Pas.so.5 und libQt4Pas.so.5.2 nur 
symbolische Links zu libQt4Pas.so.5.2.5 sein, und manuell ausgelieferte 
Versionen sollten nicht in /usr/lib, sondern in /usr/local/lib kopiert 
werden. Dabei sollte nur die Datei libQt4Pas.so.5.2.5 in das Verzeichnis 
kopiert und die symbolischen Links idealerweise durch einen Aufruf von 
/sbin/ldconfig erzeugt werden. Aber grundsätzlich ist es immer eine sehr 
schlechte Idee, Libraries am Paketmanagement vorbei zwischen 
verschiedenen Linux-Installationen zu kopieren, ihre Abhängigkeiten zu 
ignorieren und sie dann obendrein auch noch in Systemverzeichnissen 
abzulegen, die exklusiv für die Verwaltung durch den Paketmanager 
vorgesehen sind. ;-)

Autor: Est Est Est (comvisu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Günther,

es kam gar keine Mitteilung an mich, hab deinen Beitrag erst jetzt 
gesehen.
Deine Vorgehensweise müsste eigentlich funktionieren.
In einer früheren Linuxversion hat es beim Zippen der Symlinks unter 
Windows diese irgendwie zerstört, vielleicht ist das hier auch passiert. 
Die Fehlermeldung könnte dazu passen.

Die Hinweise von Sheeva Plug hören sich gut an. Am Besten du versuchst 
die Bibliothek über den Paketmanager zu installieren (händisch 
installierte natürlich vorher wieder löschen). Mit Linux kenn ich mich 
nicht so aus, ich habe eben die Anleitung gegeben, wie es bei mir 
funktioniert hat. Problem ist auch, ich kanns nicht so einfach testen, 
da ich ja die Entwicklungsbibliotheken installiert habe, bzw. auch 
kompiliert.

Hoffe es klappt!

Autor: Günter R. (galileo14)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Sheeva P. schrieb:
> Ich habe darum jetzt mit
> "sudo apt-get install libqt4pas-dev" auf meinem RasPi unter Raspbian
> GNU/Linux 8.0 (jessie) die entsprechenden Bibliotheken mit ihren
> Abhängigkeiten installiert, dann die Zip-Datei ausgepackt, dem Programm
> mit "chmod u+x ComvisuV101ARMV6Linux" Ausführrechte gegeben und siehe
> da: läuft.

Hallo Sheeva Plug,

sehr herzlichen Dank! Habs jetzt genauso gemacht: funktioniert!


Est Est E. schrieb:
> Die Hinweise von Sheeva Plug hören sich gut an. Am Besten du versuchst
> die Bibliothek über den Paketmanager zu installieren (händisch
> installierte natürlich vorher wieder löschen).

Hallo Est Est Est,

ja, jetzt hats geklappt. Kenne mich mit Linux auch nicht besonders gut 
aus, die Hinweise von Sheeva Plug haben es voll gebracht. Jetzt kann ich 
die Schnittstellen testen und mein Beispielprojekt auf den RP bringen. 
Melde mich wieder. Evt. könntest Du die Hinweise von Sheeva Plug in die 
nächste Ausgabe von CV für RP bzw. Linux einpflegen.

Jedenfalls Euch beiden (und allen anderen natürlich auch) noch Frohe 
Weihnachten!

Günter

Autor: Est Est Est (comvisu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Günther,

gut dass es geklappt hat.
Ich werde die Anleitung anpassen. Hast du das Paket libqt4pas-dev oder 
libqt4pas5 installiert?

Viele Grüße

Autor: Sheeva Plug (sheevaplug)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Est Est E. schrieb:
> Deine Vorgehensweise müsste eigentlich funktionieren.

Leider nicht. Unter Windows kannst Du .DLL-Dateien oft problemlos hin- 
und herkopieren, das funktioniert unter Linux aber meistens nicht.

In allen Linux-Distributionen (meines Wissens mit Ausnahme von Slackware 
Linux) gibt es einen Paketmanager, der Pakete installiert und dabei 
deren Abhängigkeiten auflöst, und das gesamte Ökosystem der Distribution 
sowie alle seine Infrastrukturen sind auf die Benutzung dieses 
Paketmanagers ausgelegt. Obendrein bietet Linux über die Symlinks zu den 
Libraries die Möglichkeit, unterschiedliche Versionen derselben Library 
gleichzeitig zu installieren, darum müssen die Symlinks unbedingt 
korrekt erzeugt und können daher oft nicht einfach kopiert werden, weil 
sie dann eventuell neuere Versionen der Bibliothek überschreiben würden.

> Die Hinweise von Sheeva Plug hören sich gut an. Am Besten du versuchst
> die Bibliothek über den Paketmanager zu installieren (händisch
> installierte natürlich vorher wieder löschen). Mit Linux kenn ich mich
> nicht so aus, ich habe eben die Anleitung gegeben, wie es bei mir
> funktioniert hat. Problem ist auch, ich kanns nicht so einfach testen,
> da ich ja die Entwicklungsbibliotheken installiert habe, bzw. auch
> kompiliert.

Der Trick ist eigentlich ganz einfach: mit "ldd <executable>", also hier 
"ldd ComvisuV101ARMV6Linux" bekommst Du eine Liste der dynamischen 
Libraries, die das Programm laden will. Auf einem System ohne libQt4Pas 
sieht diese Liste bei mir auf dem obengenannten Raspbian so aus:
linux-vdso.so.1 (0x7edae000)
/usr/lib/arm-linux-gnueabihf/libarmmem.so (0x76f12000)
libpthread.so.0 => /lib/arm-linux-gnueabihf/libpthread.so.0 (0x76edb000)
libdl.so.2 => /lib/arm-linux-gnueabihf/libdl.so.2 (0x76ec8000)
libQt4Pas.so.5 => not found
libX11.so.6 => /usr/lib/arm-linux-gnueabihf/libX11.so.6 (0x76db2000)
libc.so.6 => /lib/arm-linux-gnueabihf/libc.so.6 (0x76c73000)
/lib/ld-linux-armhf.so.3 (0x54ae8000)
libxcb.so.1 => /usr/lib/arm-linux-gnueabihf/libxcb.so.1 (0x76c54000)
libXau.so.6 => /usr/lib/arm-linux-gnueabihf/libXau.so.6 (0x76c49000)
libXdmcp.so.6 => /usr/lib/arm-linux-gnueabihf/libXdmcp.so.6 (0x76c3d000)

In Zeile 5 siehst Du: die Bibliothek "libQt4Pas.so.5" wurde nicht 
gefunden.  Deine Aufgabe als Entwickler bzw. Distributor der Software 
ist es jetzt, herauszufinden, welches Softwarepaket diese Bibliothek 
bereitstellt. Auf Deinem Entwicklungssystem ist das ein Leichtes, das 
Kommando
find / -name 'libQt4Pas.so.5' -exec dpkg -S {} \;

sucht systemweit nach der Datei und schaut dann mit dem Kommando dpkg(1) 
in der Datenbank installierter Pakete, zu welchem Paket die gefundene 
Datei gehört. Und dann sagst Du Deinen Anwendern, daß sie das 
betreffende Paket installieren sollen, zum Beispiel mit "sudo apt-get 
install <paketname>", hier also:
sudo apt-get install libqt4pas5

Bei dem "apt-get install" werden auch noch die Abhängigkeiten 
automatisch installiert, bei mir waren das die Pakete
libaudio2 libmng1 libqt4-network libqt4-xml libqt4-xmlpatterns libqtcore4 libqtdbus4 libqtgui4 libqtwebkit4 qtcore4-l10n

Diese Pakete werden von der Bibliothek libqt5pas5 zwingend benötigt. Du 
siehst: es reicht meist nicht, einfach ein paar dynamische Bibliotheken 
hin- und her zu kopieren, weil dann deren Abhängigkeiten nicht 
befriedigt werden und das Programm deswegen trotzdem nicht funktionieren 
würde.

Wie dem auch sei, nach der Installation zeigt ein erneuter Aufruf von 
"ldd ComvisuV101ARMV6Linux" nun folgende Ausgabe:
linux-vdso.so.1 (0x7ef94000)
/usr/lib/arm-linux-gnueabihf/libarmmem.so (0x76f34000)
libpthread.so.0 => /lib/arm-linux-gnueabihf/libpthread.so.0 (0x76efd000)
libdl.so.2 => /lib/arm-linux-gnueabihf/libdl.so.2 (0x76eea000)
libQt4Pas.so.5 => /usr/lib/arm-linux-gnueabihf/libQt4Pas.so.5 (0x76d3f000)
libX11.so.6 => /usr/lib/arm-linux-gnueabihf/libX11.so.6 (0x76c29000)
libc.so.6 => /lib/arm-linux-gnueabihf/libc.so.6 (0x76aea000)
/lib/ld-linux-armhf.so.3 (0x54b9c000)
libQtWebKit.so.4 => /usr/lib/arm-linux-gnueabihf/libQtWebKit.so.4 (0x75086000)
libQtGui.so.4 => /usr/lib/arm-linux-gnueabihf/libQtGui.so.4 (0x74795000)
libQtNetwork.so.4 => /usr/lib/arm-linux-gnueabihf/libQtNetwork.so.4 (0x74667000)
libQtCore.so.4 => /usr/lib/arm-linux-gnueabihf/libQtCore.so.4 (0x743c6000)
libstdc++.so.6 => /usr/lib/arm-linux-gnueabihf/libstdc++.so.6 (0x7427e000)
libm.so.6 => /lib/arm-linux-gnueabihf/libm.so.6 (0x741ff000)
libgcc_s.so.1 => /lib/arm-linux-gnueabihf/libgcc_s.so.1 (0x741d0000)
libxcb.so.1 => /usr/lib/arm-linux-gnueabihf/libxcb.so.1 (0x741b1000)
libz.so.1 => /lib/arm-linux-gnueabihf/libz.so.1 (0x7418a000)
libXrender.so.1 => /usr/lib/arm-linux-gnueabihf/libXrender.so.1 (0x74179000)
libjpeg.so.62 => /usr/lib/arm-linux-gnueabihf/libjpeg.so.62 (0x74124000)
libpng12.so.0 => /lib/arm-linux-gnueabihf/libpng12.so.0 (0x740f4000)
libgstapp-1.0.so.0 => /usr/lib/arm-linux-gnueabihf/libgstapp-1.0.so.0 (0x740d9000)
libgstpbutils-1.0.so.0 => /usr/lib/arm-linux-gnueabihf/libgstpbutils-1.0.so.0 (0x740a6000)
libgstvideo-1.0.so.0 => /usr/lib/arm-linux-gnueabihf/libgstvideo-1.0.so.0 (0x74057000)
libgstaudio-1.0.so.0 => /usr/lib/arm-linux-gnueabihf/libgstaudio-1.0.so.0 (0x74000000)
libgstbase-1.0.so.0 => /usr/lib/arm-linux-gnueabihf/libgstbase-1.0.so.0 (0x73f98000)
libgstreamer-1.0.so.0 => /usr/lib/arm-linux-gnueabihf/libgstreamer-1.0.so.0 (0x73e92000)
libgobject-2.0.so.0 => /usr/lib/arm-linux-gnueabihf/libgobject-2.0.so.0 (0x73e38000)
libglib-2.0.so.0 => /lib/arm-linux-gnueabihf/libglib-2.0.so.0 (0x73d35000)
libsqlite3.so.0 => /usr/lib/arm-linux-gnueabihf/libsqlite3.so.0 (0x73c7b000)
libfontconfig.so.1 => /usr/lib/arm-linux-gnueabihf/libfontconfig.so.1 (0x73c39000)
libQtXmlPatterns.so.4 => /usr/lib/arm-linux-gnueabihf/libQtXmlPatterns.so.4 (0x73894000)
libaudio.so.2 => /usr/lib/arm-linux-gnueabihf/libaudio.so.2 (0x7386f000)
libfreetype.so.6 => /usr/lib/arm-linux-gnueabihf/libfreetype.so.6 (0x737d7000)
libSM.so.6 => /usr/lib/arm-linux-gnueabihf/libSM.so.6 (0x737c8000)
libICE.so.6 => /usr/lib/arm-linux-gnueabihf/libICE.so.6 (0x737aa000)
libXext.so.6 => /usr/lib/arm-linux-gnueabihf/libXext.so.6 (0x73789000)
librt.so.1 => /lib/arm-linux-gnueabihf/librt.so.1 (0x73772000)
libXau.so.6 => /usr/lib/arm-linux-gnueabihf/libXau.so.6 (0x73767000)
libXdmcp.so.6 => /usr/lib/arm-linux-gnueabihf/libXdmcp.so.6 (0x7375b000)
liborc-0.4.so.0 => /usr/lib/arm-linux-gnueabihf/liborc-0.4.so.0 (0x736db000)
libgsttag-1.0.so.0 => /usr/lib/arm-linux-gnueabihf/libgsttag-1.0.so.0 (0x73696000)
libgmodule-2.0.so.0 => /usr/lib/arm-linux-gnueabihf/libgmodule-2.0.so.0 (0x73682000)
libffi.so.6 => /usr/lib/arm-linux-gnueabihf/libffi.so.6 (0x73672000)
libpcre.so.3 => /lib/arm-linux-gnueabihf/libpcre.so.3 (0x735ff000)
libexpat.so.1 => /lib/arm-linux-gnueabihf/libexpat.so.1 (0x735cb000)
libXt.so.6 => /usr/lib/arm-linux-gnueabihf/libXt.so.6 (0x73575000)
libuuid.so.1 => /lib/arm-linux-gnueabihf/libuuid.so.1 (0x73561000)       

Wenn Du es richtig machen wolltest, würdest Du ein Raspbian-Paket (eine 
.deb-Datei) Deiner Software bauen und es in einem eigenen 
Paket-Repository für den Paketmanager anbieten. Die Benutzer würden Dein 
Paket-Repository einfach als Paketquelle hinzufügen (zum Beispiel in 
/etc/apt/sources.list oder besser in einer eigenen Datei 
/etc/apt/sources.list.d/comvisu.list), danach den lokalen Cache 
verfügbarer Pakete mit "sudo apt-get update" aktualisieren, und könnten 
Dein Programm danach einfach mit "sudo apt-get install comvisu" 
installieren. Dabei kannst Du in dem Paket dann auch gleich die 
benötigten Abhängigkeiten festlegen, die der Paketmanager dann gleich 
automatisch mit installiert. Eine Beschreibung, wie das mit dem 
Paketbauen und dem Repo geht, würde hier vermutlich das Forum sprengen, 
aber im Internet findest Du viele gute Anleitungen dazu. Tipp: Du 
würdest ein "Binary Package" bauen wollen, solange Du Deinen Sourcecode 
nicht veröffentlichen magst. ;-)

Autor: Sheeva Plug (sheevaplug)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Est Est E. schrieb:
> gut dass es geklappt hat.
> Ich werde die Anleitung anpassen. Hast du das Paket libqt4pas-dev oder
> libqt4pas5 installiert?

Die "*-dev"-Pakete sind Entwicklungspakete und enthalten die Header für 
die betreffende Bibliothek, damit interessierte Programme dagegen linken 
können. Dabei sind die "*-dev"-Pakete üblicherweise ziemlich klein und 
ziehen ihre Binärbibliotheken automatisch als Abhängigkeiten an. Eine 
Installation von "libqt4pas-dev" mit apt-get installiert also 
automatisch auch "libqt4pas5". Für Dein Programm wird das 
Entwicklungspaket allerdings nicht benötigt, es reicht daher aus, das 
Paket "libqt4pas5" zu installieren.

Autor: Est Est Est (comvisu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Sheeva Plug,

danke für deine detaillierte Erklärung!
Die Installation mit
 "sudo apt-get install libqt4pas-dev"
ist natürlich elegant, das werde ich auf jeden Fall in die Dokumentation 
aufnehmen. Wenn ich das richtig sehe muss dann die QT-Installation auch 
nicht mehr getrennt aufgerufen werden, weil das ja in der Abhängigkeit 
beinhaltet ist, oder?

> In allen Linux-Distributionen [...] gibt es einen Paketmanager,
Die Pakete sind aber linuxabhängig, oder? D.h. ein Raspbian benötigt 
andere Pakete wie bspw. Pidora? Für die QT-Bibliotheken seh ich da kein 
Problem, aber die QT-Pascal-Bibliothek könnte auf einigen Plattformen 
nicht verfügbar sein. Meine Frage (wenn das so ist) wäre also wie man es 
händisch richtig installieren kann, also ohne den Paketmanager.


Hast du die Comvisu mal auf dem Sheevaplug getestet? Ich weiß nicht ob 
der Befehlssatz kompatibel ist.

Autor: HimboKusPokus (Gast)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
>> In allen Linux-Distributionen [...] gibt es einen Paketmanager,
> Die Pakete sind aber linuxabhängig, oder? D.h. ein Raspbian benötigt
> andere Pakete wie bspw. Pidora? Für die QT-Bibliotheken seh ich da kein
> Problem, aber die QT-Pascal-Bibliothek könnte auf einigen Plattformen
> nicht verfügbar sein. Meine Frage (wenn das so ist) wäre also wie man es
> händisch richtig installieren kann, also ohne den Paketmanager.

Nun, es gibt tatsächlich kaum ein Linux OHNE Paketmanager - an dieser 
Untugend hält wohl nur noch jene Hinterhofklitsche in Redmond fest...

Du willst ein Anbieter von "Binary Package(s)"? sein?
Na dann obliegt es einzig DIR ALLEINE, für alle möglichen Kombinationen 
von CPU-Architekturen UND Linux-Kernel-ABIs (vulgo: Linuxversionen) UND 
Bibliotheks-ABIs (vulgo: Bilbiotheksversionen) Deine Kompilate bereit zu 
halten.

Alternative: QUELLCODE BEREITSTELLEN.
Damit kann jeder mit mehr make-mojo als Du fuer beliebeige -sprich: 
auch künftige- Plattformen deine Anwendung übersetzen.
Nebenbei erhöht sich GANZ DRASTISCH das Potential, dass jemand 
Korrekturen, Verbesserungen, Erweiterungen (hier z.B. 
Schnittstellenvielfalt) u.v.m. zu Deinem Programm beitragen kann.

Autor: Sheeva Plug (sheevaplug)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Est Est E. schrieb:
> Hallo Sheeva Plug,
>
> danke für deine detaillierte Erklärung!
> Die Installation mit
>  "sudo apt-get install libqt4pas-dev"
> ist natürlich elegant, das werde ich auf jeden Fall in die Dokumentation
> aufnehmen. Wenn ich das richtig sehe muss dann die QT-Installation auch
> nicht mehr getrennt aufgerufen werden, weil das ja in der Abhängigkeit
> beinhaltet ist, oder?

Ja, so sollte das sein. Aber, wie gesagt, das -dev-Paket brauchst Du 
eigentlich nur zum Übersetzen, für Endanwender reicht libqt4pas5.

>> In allen Linux-Distributionen [...] gibt es einen Paketmanager,
> Die Pakete sind aber linuxabhängig, oder? D.h. ein Raspbian benötigt
> andere Pakete wie bspw. Pidora? Für die QT-Bibliotheken seh ich da kein
> Problem, aber die QT-Pascal-Bibliothek könnte auf einigen Plattformen
> nicht verfügbar sein. Meine Frage (wenn das so ist) wäre also wie man es
> händisch richtig installieren kann, also ohne den Paketmanager.

Naja, "richtig" wäre es eben, dem Paketmanager Pakete bereitzustellen, 
die die korrekten Abhängigkeiten anziehen. Und ja, Raspbian ist ein 
Derivat von Debian und verwendet, wie dieses, dpkg(1) und apt(8), 
während Pidora ein Redhat- bzw. Fedora-Derivat ist und daher RPM und yum 
benutzt.

Angesichts der Tatsache, daß Raspbian nun einmal die "offizielle" 
Distribution für den RasPi ist, die Verbreitung von Pidora nach meiner 
Wahrnehmung verschwindend gering ist, und Du Deine Software eventuell 
für Pidora auf einem Pidora -- je nach Bibliotheksversionen -- noch 
einmal gesondert übersetzen oder eventuell sogar anpassen müßtest, sehe 
ich es allerdings als durchaus fraglich, ob dieser Aufwand sich lohnt. 
Auf der anderen Seite kann man mit dem Programm "alien" Debian-Pakete in 
RPMs und umgekehrt wandeln -- dabei sollten zwar auch die Abhängigkeiten 
etc sauber gewandelt werden, aber ob das funktioniert, müßte man testen.

> Hast du die Comvisu mal auf dem Sheevaplug getestet? Ich weiß nicht ob
> der Befehlssatz kompatibel ist.

Leider hab' ich im Moment keinen SheevaPlug zur Verfügung. ;-)

Autor: Günter R. (galileo14)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Est Est E. schrieb:
> Hallo Günther,
>
> gut dass es geklappt hat.
> Ich werde die Anleitung anpassen. Hast du das Paket libqt4pas-dev oder
> libqt4pas5 installiert?
>
> Viele Grüße

Hallo Est Est Est,

ich hatte "libqt4pas-dev" installiert gemäß dem Ratschlag von 
SheevaPlug, aber er schrieb ja oben, daß für meine Anwendung 
"libqt4pas5" genügt hätte.

Mittlerweile treten aber auch schon Probleme zutage. Ich hatte den RP 
zunächst über HDMI an meinem TV dran (Panasonic), jetzt wollte ich einen 
älteren VGA-TFT-Monitor verwenden und hatte von PiHut den 
"HDMI-VGA-Adapter" bezogen und die TV-Parameter in "/boot/config.txt" 
auf

hdmi_group=2  (CEA-Modes)  und
hdmi_mode=11  (800*600  75 Hz)

umgestellt. Der Monitor könnte im Prinzip auch 1280*1024 auflösen, aber 
alle höher aufgelösten Modi als 800*600 bringen den Monitor zum Flackern 
und sind nicht stabil; aber das ist wohl ein anderes Problem als 
unseres.

Wenn ich nun Comvisu in einer Konsole starte, öffnet Comvisu zwar, aber 
im Konsolenfenster ergeben sich jede Menge Meldungen der Art

"QImage::setPixel: coordinate(35,24) out of range

mit unterschiedlichen Koordinaten (ca. 20 solcher Meldungen), und das 
Comvisu-Fenster ist größer als der Monitor-Bildschirmbereich; d.h. ich 
muß oben die blaue Comvisu-Leister erstmal nach links schieben, damit 
das Vergrößern-Icon erscheint, auf das ich dann klicke, sodaß Comvisu 
nun den gesamten Monitor-Bildschirm einnimmt, wie man es haben möchte, 
sodaß alle seine Element erreichbar sind. Trotzdem stehen die zwei 
Buttons "Kanalliste" und "Hintergrund" nach rechts aus dem Bild raus, 
aber das stört erstmal nicht.

Nun kann ich mit "Schnittstelle" die "/dev/ttyUSB1" auswählen, auf 9600 
bps umstellen und unter "Terminal" den Haken bei "Terminal aktiv" setzen 
und "Verbinden" (wird dann grün); nun sehe ich Zeichen, die ich an 
meinem ZOC-Terminal (Notebook) eintippe, im linken Fenster der Rohdaten. 
Tippe ich einen Befehl wie z.B. "#4F12.7;", dann sehe ich zusätzlich 
diesen Befehl im Fenster "Empfangene Befehle". Comvisu funktioniert also 
grundsätzlich.

Nun möchte ich eine Visualisierung definieren und klicke auf 
"Bearbeiten". Jetzt schließt sich Comvisu und ist weg; in der Konsole 
erscheint die Meldung "Runtime error 120 at $xxxxxxxx ... $xxxxxxxx 
QPixmap: It is not safe to use pixmaps outside the GUI thread
QPainter ::begin: Paint device returned engine == 0, type: 2"

Für xxxxxxxx stehen insgesamt 7 32-Bit-Hex-Werte. Kann sie gerne 
abschreiben, wenns etwas bringt.

Kann jetzt nicht sagen, ob das auch am TV mit voller Auflösung passieren 
würde; das kann ich gerne testen, wenn Du möchtest (muß halt den ganzen 
Kram runter ins Wohnzimmer tragen, wäre aber kein Problem).

Das hat wohl mit Bereichsüberschreitungen des Pixel-Zeichnens zu tun 
wegen meiner geringen VGA-Auflösung?

Günter

Autor: Frank Lorenzen (florenzen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe vor 2 Tagen Comvisu-Linux64 mal zur Probe installiert und den 
Out-Of-Range-Fehler habe ich auch. Das kann man triggern, indem man mit 
aktivem Reiter "Ausführen" oder "Bearbeiten" den Mauszeiger aus dem 
Bereich der Reiter nebst zugehörigen Buttons (in einer beliebigen 
Richtung) heraus, oder in den Bereich hineinbewegt. An zu geringer 
Monitorauflösung liegt das bei mir mit Sicherheit nicht.
Nach einer Weile zerlegt einem dieses Verhalten recht Zuverlässig die 
Console und man sollte selbige mit "reset" wieder Aufräumen.


Gruß,
f

Autor: OQ (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
es ist aber auch soo schade dass man ohne Quellcode nicht wirklich 
beim Fehler analysieren, beheben und allgemein Verbessern weiterhelfen 
kann...

Autor: Est Est Est (comvisu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Sheevaplug: OK, dann wird es erstmal so bleiben. Mit dem Hinweis auf 
das "libqt4pas5"-Packet eben. Danke nochmal!

@Günther:
Der "Out of range" Fehler ist mir bekannt, ich dachte dass es ein 
Problem in QT ist (da unter Win nicht vorhanden) und dieser keinen 
Einfluss auf die Stabilität hat. Vor ein paar Wochen habe ich im 
Zusammenhang mit ein paar Experimenten unter Android festgestellt, dass 
diese Fehlermeldungen doch mit meinem Code zu tun haben. Das werde ich 
auch genauer untersuchen, dieses Jahr aber nicht mehr~ Ob der Absturz 
damit zu tun hat, bin ich mir auch nicht sicher. Ist das Verhalten bei 
dir reproduzierbar, oder sporadisch? Ich nehme an die Buttons Kanalliste 
und Hintergrund liegen außerhalb vom Fenster und nicht dass das Fenster 
über den Bildschirmrand rausragt, oder? Ist das Verhalten das gleiche 
wenn du die Comvisu nicht über die Shell sondern per Doppelklick 
startest? Zumindest eine Überlastung der Shell könnte dadurch evtl. 
vermieden werden. Die Fehlermeldungen hören sich aber nach einem anderen 
Problem an. Die Hex-Werte helfen mir erstmal nicht weiter.

@Frank: Siehe oben, ich habe bei diesem Problem schon eine Spur 
aufgenommen.

Viele Grüße

Autor: Frank Lorenzen (florenzen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Est Est Est,

wenn du ohnehin gerade am Code herumschraubst, könntest du vielleicht 
einen kleinen Fehler beheben. Nix wichtiges, es ist mir nur aufgefallen:
Wenn man unter Linux mit einer Projektdatei startet und einen 
relativen Pfad angibt, also so:
$ ./ComvisuV100Linux64 Anzeige.visu
dann expandierst Du das zu einem absoluten Pfad $WorkingDir\$FileName. 
Da gehört natürlich kein Backslash hin sondern ein Slash, ansonsten wird 
die Datei nicht gefunden. Gibt man einen Pfad mit start in CWD an, also 
./Anzeige.visu gehts genauso schief. Nur unter Angabe des absoluten 
Pfades läd er die Projektdatei.

Gruß,
f

Autor: Sheeva Plug (sheevaplug)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Günter R. schrieb:
> Mittlerweile treten aber auch schon Probleme zutage. Ich hatte den RP
> zunächst über HDMI an meinem TV dran (Panasonic), jetzt wollte ich einen
> älteren VGA-TFT-Monitor verwenden und hatte von PiHut den
> "HDMI-VGA-Adapter" bezogen und die TV-Parameter in "/boot/config.txt"
> auf
>
> hdmi_group=2  (CEA-Modes)  und
> hdmi_mode=11  (800*600  75 Hz)

Möglicherweise ist die Bildwiederholfrequenz zu hoch. Vor allem ältere 
TFTs, aber auch einige Adapter schaffen nicht mehr als 60 Hz. Ansonsten 
kann sowas auch an der Qualität der Kabel liegen. YMMV.

> Nun möchte ich eine Visualisierung definieren und klicke auf
> "Bearbeiten". Jetzt schließt sich Comvisu und ist weg; in der Konsole
> erscheint die Meldung "Runtime error 120 at $xxxxxxxx ... $xxxxxxxx
> QPixmap: It is not safe to use pixmaps outside the GUI thread
> QPainter ::begin: Paint device returned engine == 0, type: 2"

Leider kann ich den Fehler bei mir nicht nachstellen, habe aber auch 
kein Serielles Gerät an meinem RasPi3. Um etwas genauer schauen zu 
können, was diese Probleme verursacht, könntest Du ComVisu mit strace(1) 
starten. Was macht das? strace(1) verfolgt das Programm und gibt dabei 
alle Systemcalls aus, die es aufruft. Mit "-o <dateiname>" schreibt 
strace(1) die Syscalls dann in die angegebene Datei, mit deren Hilfe 
sich Fehler häufig schnell gefunden werden können. Dein Aufruf sähe also 
so aus:
strace -o syscalls.txt ./ComvisuV101ARMV6Linux

Nicht verwundert sein: das Programm wird nicht gravierend, aber dennoch 
spürbar langsamer, wenn es unter strace(1) läuft.

strace(1) hat noch einen Freund für Library-Calls namens ltrace(1), der 
hier vermutlich noch hilfreicher wäre. Leider scheint ltrace(1) auf ARM 
noch einen ungefixten Fehler zu haben.

Einen kompletten Abzug von strace(1) und den Ausgaben von Comvisu kannst 
Du haben, indem Du es folgendermaßen aufrufst (drei Befehle):
script
strace ./ComvisuV101ARMV6Linux
exit

Dabei startet script(1) die Aufzeichnung der Ausgabekanäle und schreibt 
alle Ausgaben in eine Datei, die defaultmäßig "typescript" heißt; man 
kann das durch Angabe eines anderen Dateinamens ändern. strace(1) 
schreibt die aufgerufenen Systembefehle auf Stderr, solange man ihm 
keinen Dateinamen mitgibt, und exit beendet das Programm script(1) 
wieder.

Est Est Est: ich weiß nicht, ob Du Dein Programm einmal als OpenSource 
veröffentlichen möchtest, und es ist natürlich Deine freie Entscheidung, 
das zu tun oder eben nicht. Mich würden die Gründe dafür interessieren, 
warum Du es nicht tust, aber das ist reine Neugierde meinerseits und am 
Ende natürlich Deine Privatsache, die ich respektiere. Allerdings möchte 
ich Dich daran erinnern, daß Schwierigkeiten wie die oben beschriebenen 
natürlich leichter gefunden und behoben werden können, wenn auch noch 
andere interessierte Entwickler daran mitwirken könnten.

Autor: Günter R. (galileo14)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Sheeva P. schrieb:
> Einen kompletten Abzug von strace(1) und den Ausgaben von Comvisu kannst
> Du haben, indem Du es folgendermaßen aufrufst (drei Befehle):
> script
> strace ./ComvisuV101ARMV6Linux
> exit

Hallo zusammen,

ich habe das jetzt mal gemacht. Da kommt unheimlich viel zusammen, die 
typescript-Datei ist ca. 4 MByte groß und ca. 45.000 Zeilen lang. Wer 
will das analysieren? Ich habe mal die ersten 5000 Zeilen angehängt (nur 
so zum Anschauen). Bringt das wirklich etwas?

Das Programm "ComvisuV101ARMV6Linux" hatte ich umbenannt in "CV", damit 
ich nicht soviel tippen muß.

Günter

Autor: Sheeva Plug (sheevaplug)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Günter R. schrieb:
> ich habe das jetzt mal gemacht. Da kommt unheimlich viel zusammen, die
> typescript-Datei ist ca. 4 MByte groß und ca. 45.000 Zeilen lang. Wer
> will das analysieren? Ich habe mal die ersten 5000 Zeilen angehängt (nur
> so zum Anschauen). Bringt das wirklich etwas?

Ja -- ich würde das nicht erwähnen, wenn es nichts bringen würde. So 
eine Datei liest man natürlich nicht zeilenweise, sondern filtert sie 
etwa mit grep(1). Außerdem stehen die sinnvollsten Informationen bei 
einem Absturz natürlich meist irgendwo kurz vor dem Ende der Datei... 
;-)

Autor: Günter R. (galileo14)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das habe ich mir schon auch gedacht.

Frage an die Moderatoren: darf ich eine so große Datei (ca. 4 MByte) 
hier überhaupt hochladen?

Autor: Think different. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Günter R. schrieb:
> Das habe ich mir schon auch gedacht.
>
> Frage an die Moderatoren: darf ich eine so große Datei (ca. 4 MByte)
> hier überhaupt hochladen?

Danke f. die Nachsicht. Andere laden Bilder mit mehr als 5MB... 
(technisch also keine Limits)

Wie wär's aber mit den letzten 45'000 Zeilen?
$ tail -45000 typescript1 > AnhangZumHochladen

Sorry, bin kein Moder

Autor: Sheeva Plug (sheevaplug)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Think different. schrieb:
> Wie wär's aber mit den letzten 45'000 Zeilen?

Wie wär's mit einer gezippten Datei? Wenn das Paket "zip" installiert 
ist, kannst Du die Arbeit gleich dem RasPi überlassen:
zip typescript.zip typescript

Ansonsten kann ich viele komprimierten Formate lesen: gzip, bz2, rar, 
aber auch das antiquierte compress und das neuerdings beliebte 7zip. 
Feel free.

> Sorry, bin kein Moder

??ß?

Autor: Est Est Est (comvisu)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Sorry, dass es es von meiner Seite gerade nicht weiter geht. Zeitlich 
komm ich momentan einfach nicht hin.

Grüße

Autor: Günter R. (galileo14)
Datum:
Angehängte Dateien:

Bewertung
1 lesenswert
nicht lesenswert
Sheeva P. schrieb:
> Wie wär's mit einer gezippten Datei? Wenn das Paket "zip" installiert

Ich war wohl im Dornröschenschlaf ... natürlich, das ist die Lösung. 
Zippen. Hier ist die gesamte Datei. Mit TotalCommander das einfachste, 
das es gibt.

Autor: Günter R. (galileo14)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Est Est E. schrieb:
> Sorry, dass es es von meiner Seite gerade nicht weiter geht. Zeitlich
> komm ich momentan einfach nicht hin.
>
> Grüße

Kein Problem. Eilt ja überhaupt nicht.

Günter

Autor: Sheeva Plug (sheevaplug)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Günter R. schrieb:
> Sheeva P. schrieb:
>> Wie wär's mit einer gezippten Datei? Wenn das Paket "zip" installiert
>
> Ich war wohl im Dornröschenschlaf ... natürlich, das ist die Lösung.
> Zippen. Hier ist die gesamte Datei. Mit TotalCommander das einfachste,
> das es gibt.

Schade, leider enthält der Systrace nur die Syscalls des Hauptprozesses. 
Aber ich sehe, daß dort mehrere Kindprozesse erzeugt werden, deren 
Syscalls leider nicht miterfaßt werden. Könntest Du dasselbe bitte 
nochmal wiederholen, dabei dem strace(1)-Befehl aber den Parameter "-f" 
mitgeben? Danke!

Autor: Günter R. (galileo14)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Klar, mache ich heute Abend.

Was bedeutet eigentlich das "(1)", das Du im Kommentar jeweils an die 
Befehlsnamen hängst? Das kenne ich nicht. Verweist das auf irgendetwas? 
Mit eingetippt wird es ja nicht?

Autor: Kommandozeile für Alle vor dem Frühstück! (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
> Was bedeutet eigentlich das "(1)", das Du im Kommentar jeweils an die
> Befehlsnamen hängst? Das kenne ich nicht. Verweist das auf irgendetwas?

Eine gängige Notation im *nix Umfeld.
Das ist ein Hinweis in welcher Sektion der man pages die 
Dokumentation dazu zu finden ist.

Aus Wikipedia:
"""
(1) User Commands and Daemons („Anwender-Kommandos und 
Hintergrunddienste“)

(2) System Calls and Kernel Services („Systemaufrufe und -dienste“)

(3) Subroutines („Unterprogramme“)

(4) Special Files, Device Drivers and Hardware („Geräte“)

(5) Configuration Files („Konfigurationsdateien“)

(6) Games („Spiele“)

(7) Miscellaneous Commands („Verschiedenes“)

(8) Administrative Commands and Daemons („Verwaltung“)
"""

Dann gibt es noch interne Befehle der Kommandointerpreter: diese sind 
z.B. unter bash(1) ( also mit man bash ) im Abschnitt BUILTINS 
nachzuschlagen.

Diese Notation hilft bei Mehrdeutigkeiten: z.B. hostname(1) und 
hostname(5), printf(3) und printf bei bash(1), echo(1) und echo bei 
bash(1), usw.


> Mit eingetippt wird es ja nicht?
Korrekt.

Autor: Günter R. (galileo14)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Okay, wieder etwas gelernt.

Vielen Dank!

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.