Du kannst die serielle Schnittstelle doch wie eine Datei ansprechen. Aber welche Klasse du stattdessen nutzt würde mich auch interessieren :cheesy:
Druckbare Version
Du kannst die serielle Schnittstelle doch wie eine Datei ansprechen. Aber welche Klasse du stattdessen nutzt würde mich auch interessieren :cheesy:
erklär das einmal "Du kannst die serielle Schnittstelle doch wie eine Datei ansprechen. "
ich benutze die "com.jar und die win32com.dll"
Unter Windows können manche Schnittstellen (wie z.B. die seriellen Schnittstellen ComX) wie Dateien angesprochen werden (Unter Linux müsste das auch gehen, ich weiß aber nicht wie die Pfade dort heißen).Zitat:
Zitat von pebisoft
Das Bedeutet, du kannst in einem Java-Programm ein Objekt für den Zugriff auf das Dateisystem des Rechners anlegen, wobei du allerdings keine Datei referenzierst, sonders das anzusprechende Gerät.
Der Vorteil ist, dass du keine extra Bibliotheken brauchst. Nachteilig ist wiederum, das du keinen Einfluss auf die Statusleitungen, sowie das Übertragungsprotokoll hast.
Da liefert das Betriebssystem allerdings wieder entsprechende Programme mit, die diese Aufgaben übernehmen können.
Das Programm mode.com dient dabei zum setzen aller Einstellungen, welche aus dem Javaprogramm selbst nicht vorgenommen werden können.
Beispiel-Klasse:
Unter WindowsXP liefs bei mir einwandfrei. Auf nem Schulrechner konnte ich leider nicht auf die mode.com zugreifen(Lag vieleicht an der Rechtevergabe oder einfach an Windows2000).Code:import java.io.*;
public class SerialIO{
private RandomAccessFile ComFile; //serielle Schnittstelle die angesprochen werden soll
public SerialIO(){ //Konstruktor
configComPort(); //initialisiert die serielle Schnittstelle
}
public void destroy(){ //Destruktor
try{
ComFile.close(); //versucht die serielle Schnittstelle zu schließen
}catch(Exception e){ e.printStackTrace(); };
}
public boolean configComPort(){
String[] cmd = {"c:\\WINDOWS\\system32\\cmd.exe /c start /min", //Konsole öffnen
"c:\\WINDOWS\\system32\\mode.com COM1:", //COM1 soll konfiguriert werden
"baud=9600",
"parity=n",
"data=8",
"stop=1"};
try{
Process p = Runtime.getRuntime().exec(cmd); // Befehlszeile ausführen
if( p.waitFor() != 0 ) { //Falls der Prozess nicht gestartet werden kann
System.out.println("Fehler bei der Ausführung: " + cmd );
return false; //Fehler
}
ComFile = new RandomAccessFile("COM1:","rws"); //COM1 öffnen
}catch(Exception e){e.printStackTrace();};
return true; //alles hat geklappt
}
public void sendByte(byte b){ //Gibt ein Datenbyte auf die serielle S. aus
byte[] bytes = new byte[1]; //ByteArray der Länge 1
bytes[0] = b; // Daten einfügen
try{ ComFile.write(bytes); // und in die Datei schreiben
} catch(Exception e){ e.printStackTrace(); };
}
public byte receiveByte(){ //Liest ein Datenbyte aus der seriellen S.
byte[] b = new byte[1]; //Daten-Puffer
try{
ComFile.readFully(b); //Lese-Status bis ein Byte ankommt
} catch(Exception e) { e.printStackTrace(); };
return b[0]; //Byte zurückgeben
}
}
Hmm... Deine Bibliothek ist aber eleganter. Ist nur blöd, das man auf jedem Rechner die .jar-Datei einbinden und die .dll-Datei mitliefern muss.
Ich hätte noch ne Frage zur GB-Cam. Den Artikel zur ansteuerung der Kamera hab ich von www.cyblord.de
Und zwar ist mein Problem folgendes:
Ich schreibe hier gerade die Software in ASM und bin am überlegen, ob ich nach dem Startsignal mit dem Impuls auf dem Start- und dem CLK-Pin die Kamera weiter mit CLK-Impulsen versorgen muss.
Im Diagramm ist die expsure-time rot markiert, wobei auch hier ein Taktsignal abgegeben wird. Aber ist das zwingend erforderlich?
Wie habt ihr das gemacht. Habt ihr den Takt weiterlaufen lassen oder angehalten?
----Edit----
Ahh.. schon klar.. hab ne Zeile überlesen ...-sry- 8-[ 8-[
ja, Du musst den Takt weiter laufen lassen.
Moin, gibts eigentlich nen aktuelles, unglaublich gutes kontrastreiches Bild zum anschauen? Oder am besten gleich mehrere? Ich würde nämlich gerne mal wieder ein paar Erfolge mit der Cam sehen (bevor ich mich auch wieder an die Areit damit begebe :D )
Gruß
Timo
ps. der Java-Code ist interessant! Ich werde das mal ausprobieren :)
hi
ich hab zwar jetzt nicht alles hier gelesen aber hier
http://www.kreatives-chaos.com/index.php?seite=gbcam
gibt es meinermeinug nach echt gute sachen zu diesem und anderen themen.
Sorry, dass ich das Thema wieder auffrische...
Ich habe mir eine GBCam zugelegt, das alles wie in bekannten Links mit einem Atmega8 verbunden und versucht ans Laufen zu bekommen.
Dabei habe ich mich teilweise an hier gesendeten Code-Fragmenten orientiert (Dank va an Kijon).
Die GBCam betreibe lese ich mit dem internen AD Wandler aus und sende jeden Pixelwert direkt per Uart an den PC.
Ich bekomme ein vernünftiges Bild, wenn ich bei geschlossenen Rollläden und Kunstlicht fotographiere. Dabei ist die Belichtungszeit sehr gering, gerade so groß, dass das ganze Bild belichtet wird (das geschieht von rechts nach links).
Parameter:
0 000 0x80
1 001 0x09
2 010 0x00!!!!<-- kurze Belichtungszeit!
3 011 0x10!!!!<-- kurze Belichtungszeit!
4 100 0x01
5 101 0x00
6 110 0x01
7 111 0x07
Mein Problem:
Die Kamera nimmt auch während des Ausleseprozesses auf! D.h. wenn ich ein Bild gemacht habe und dann Pixel für Pixel an den PC gehen, wird jede Bewegung, die das Motiv macht, erfasst. Es entsteht also effektiv doch wieder eine sehr hohe Belichtungszeit.
Außer mit der sehr kurzen Belichtungszeit und den "Nachtaufnahmen mit Kunstlicht" ist das Bild immer weiß (stark überbelichtet).
Damit kann man zwar lustige Effekte machen, allerdings würde ich auch gern am Tag fotographieren;-)
Frage:
Wie kann ich diese "Dauerbelichtung" während der Übertragung abschalten. Mechanisch mit einer Klappe ist mir zu unelegant.
Kann es sein, dass mein Problem durch den langen Übertragungsprozess entsteht (etwa 30s)?
Viele Grüße,
Joboter
Wie kann ich diese "Dauerbelichtung" während der Übertragung abschalten.....
spannungsversorung abklemmen oder mechanische sperre/abschirmung, sonst nichts.
mfg
welchen code habt ihr verwendet der auch eiwandfrei funktioniert?
ich such wenn es gibt ein bascom code