Hallo,
Hier das Protokoll der Philips DC - 3840 Handycam.
Die DC - 3840 arbeitet mit 921600 Baud. Das Protokoll entspricht soweit
der C328. Komando ID6 und ID7 werden nicht unterstützt! Der
Kommandoheader ist hier nicht AAh sondern FFh FFh FFh. Also sieht das
Synckommando wie folgt aus FFh FFh FFh AAh 0Dh 00h 00h 00h anstelle wie
bei der C328 AAh 0Dh 00h 00h 00h 00h. Interessant ist noch der Inhalt
des EEProms zu debuggen, um z.B. die RS232 Schnittstelle etwas langsamer
zu betreiben.
Gruß
Uli
Hallo,
Hier mal ein kleiner DC-3840 Kameratreiber für einen ATmega644. Wichtig
ist dabei dass der Quarz mit 14,7456Mhz schwingt!! Die Kamera wird dabei
direkt an den USART des Prozessors angeschlossen. An Pin D.5 stehen die
Daten seriell zur Verfügung (Softuart, 1 Startbit, 8 Datenbits, 1
Stoppbit, 38400Baud).
Gruß
Ulrich
Äußerst genial, Uli!
Ist es möglich die Kamera bei weniger als den 921600 Baud laufen zu
lassen? Beispielsweise bei ganz schnarchlangsamen 9600 Baud? Bei dieser
anderen Handy-Cam ging das ja.
Hintergrund ist, dass mein Miniwebserver nur mit 12,5 MHz läuft (25MHz
des ENC28J60/2).
Und die Geschwindigkeit wäre in dem Falle eigentlich egal.
Ok, habs gefunden.
Dass man sich im Shop erst anmelden muss, um die Versandkosten zu
erfahren, finde ich prinzipiell schlecht. Kannst Du das nicht ändern?
Hi Uli!
Feine Sache! Wird es auch noch einen Code für den Mega32 mit den Quarzen
der Webserver-Schaltung geben oder schafft der das nicht?
Frohe Weihnachten,
Bernd
Hallo,
Der aktuelle Source Code auf meiner HP schaft es auch mit einem Mega32!
Der Testserver auf meiner HP arbeitet mit einem Mega32 und der Kamera.
Allerdings habe ich hier die kleinste Auflösung gewählt (160 x 120).
Gruß
Ulrich
Hallo Uli,
kannst Du eine ungefähre Hausnummer sagen, wie groß einzelne Bilder in
der Auflösung 160 * 120 werden?
Sind die Bilder in dieser Auflösung noch einigermassen erkennbar?
Vielen Dank, Stefan
Hallo,
Die Bilder mit einer Auflösung von 160x120 haben eine größe von 5kB.
Bilder bei 320x240 etwa 15kB und Bilder mit 640x480 etwa 30 kB. Ob ich
auf den Bildern was erkennen kann? Meine doch, Bilder auf meinem
Handydisplay sind nicht größer. Aber wer mag kann ja die Auflösung noch
etwas vergrößern 320x240 oder 640x480. Wobei sich 320x240 bei mir als
optimale Auflösung herrausstellte.
Gruß
Ulrich
Vielen Dank Uli!
Mal schauen, ob ich die Kamera in mein Hausbus-System integrieren kann
(um zu sehen, wer an der Türe geklingelt hat). Weil ich eine relativ
geringe Baudrate fahre, kommt es sehr auf die Größe der Bild-Dateien an.
5kb sind aber zienlich problmlos.
Viele Grüße, Stefan
> Nein!
Ok, man wird ja wohl noch fragen dürfen...
> Desweiteren ist dies nicht mein Shop sondern der von meiner Frau.
Ein paar Beiträge weiter oben hast Du noch geschrieben:
"Schau mal in meinen Shop auf meiner HP!"
SCNR
Hey Ulrich, das kenne ich irgendwoher!
Ihr habt euch im letzten Jahr Idealismus und Gewinn redlich miteinander
geteilt, du darfst den Idealismus auch im kommenden Jahr behalten!
:-D
Kann die Kamera eigentlich auch unkomprimierte Bilder liefern ? Diese
könnte man leichter mit einem µC weiterverarbeiten um so z.B. erst mal
eine Bewegungserkunnung zu machen, ehe das eigentliche Photo gemacht
wird ?
Hallo,
Ja die Kamera kann auch unkomprimierte Bilder liefern, mit einem
Propeller und der Kamera kam ich auf 6 Frames in der Sekunde. Das lag
aber auch nur an der langsamen Geschwindigkeit der RS232 Schnittstelle
;-)
Ulrich
Der OV528 besitzt einen 8051 µC, dessen Software im externen EEPROM
steht. Ich habe den EEPROM Inhalt mal durch einen Disassembler laufen
lassen: Teilweise macht der Coder sogar Sinn. Da ich leider (noch) keine
solche Kamera habe, kann ich nicht ausprobieren, was passiert wenn man
die Werte ändert. Dem Code nach werden einigen Werte aus dem ROM gelesen
und an irgenwelche Register geschrieben. Im EEPROM steht also
vermutliche die Grundinitialisierung.
Leider nicht. Das ganze steht auf der News Seite von Omnivision, die nur
noch im google Cache ist (1. Ergebnis der google Suche nach OV528):
"The OV528 can be programmed by mobile device manufacturers with
proprietary protocols to customize the interface between the camera and
the host. Protocols are the communications standards used between
electronic devices to exchange information. The OV528 has a built in
8051 micro-controller to process the program, which can be stored in an
EPROM on the camera or downloaded directly from the host."
Wenn man den Code mal ordentlich debuggt, könnte man rausfinden, welche
Werte wohin geschrieben werden (welche Bytes im EEPROM also Daten und
welche Code sind). Das würde es leichter machen, durch Ausprobieren z.B.
die Baudrate anzupassen.
Hier ist ein kleines Datenblatt einer Kamera, die auch den OV528
benutzt.
Dort sind einige Commands beschrieben.
www.electronics123.net/amazon/datasheet/C328R_UM.pdf
Ich hätte mal eine Frage zur Software:
Wenn ich das richtig verstehe, dann antwortet die Kamera nach einem Get
Picture Befehl mit einem Ack, und danach mit dem Data Befehl, der
mitteilt wie groß das Bild ist.
Dieser muss dann mit Ack beantwortet werden, danach wird das erste
Datenpaket übertragen, das wiederrum mit Ack bestätigt werden muss.
Die Ack Meldungen der Kamera werden beim Empfangen direkt in den
cam_cmd_buffer geladen, und die Daten danach in den cam_dat_buffer.
Was mich jetzt wundert: Du sendest nirgends ein Ack zur Kamera, oder
habe ich etwas übersehen ?
Hallo,
Bei der DC-3840 gibt es den Befehl für die Packetgröße nicht, alle Daten
werden hintereinander gesendet! Das Bild bleibt aber im Speicher und
kann so oft wiederholt gesendet werden wie man will.
Gruß
Ulrich
Danke, jetzt habe ich es verstanden:
Es wird jedesmal das komplette Bild gesendet, aber nur der gewünschte
512Byte Block wird im AVR gespeichert, die restlichen Daten werden
verworfen.
Hallo,
Ich habe 14,7456 gewählt weil sonst ein Mega32 übertacktet wird.
18.4320Mhz könnte auch klappen evt. die Warteschleifen verlängern. Hatte
den SourceCode nur mal in der schnelle geschrieben.
Gruß
Ulrich
Ok ich werde es heute testen.
Die Platine und die Kamera sind von deiner Frau da:-)
Der Stecker auf der Kamera ... was ist das für ein Stecker?
Ist das eine ganz normale Sterio Klinge?
uii da haste aber für nen guten preis eingekauft g (vermute ich
einfach mal)
http://cgi.ebay.at/Philips-350-VGA-Ansteckkamera-P-N-DC-3840-100-Stueck-neu_W0QQitemZ110201473298QQihZ001QQcategoryZ57528QQcmdZViewItem
Ich wär vorsichtig mit dem posten von Bildern aus derm Datasheet auf
deiner Website (noch dazu ohne Quellenangabe)
Das könnte teuer werden wenn irgendsoein Abmahnanwalt das entdeckt o.ä.
:-X
Weißt du zufällig was da für ein Bildsensor verbaut ist ?
Hast du mal unter die Linse geguckt ? Bzw wenn überhaupt steht das
meistens auf der Rückseite vom
Bildsensor (haste nicht zufällig mal einen abgelötet oder ? )
Hallo,
Jo die Kameras waren relativ billig aber ich habe 500 Stück, für nur
hundert mache ich mir nicht die ganze Arbeit. Wenn ich die aber für 1€
abgebe, dann würde mir die irgend ein Geschäftsmann alle abkaufen und
für mehr verhökern. Ausserdem ist es mir überlassen für wieviel ich die
Kameras verkaufe. Ich will ja auch neue Projekte damit finanzieren und
Frau beruhigen oder besser bestechen ;-). Erstmal hatte ich des Risiko,
diese mussten auch entschlüsselt werden, desweiteren benötigte ich auch
halt das passende Handy, und die nötigen Gerätschaften waren auch nicht
ganz billig. Beste Beispiel ist die MCA-25 die habe ich noch für 1€
bekommen. Die bekomme ich dafür nimmer.
Unter die Linse habe ich auch schon geschaut. Allerdings kommt man an
den Sensor alleine nicht dran ist nur ein Siliziumplätchen.
Gruß
Ulrich
>Unter die Linse habe ich auch schon geschaut. Allerdings kommt man an>den Sensor alleine nicht dran ist nur ein Siliziumplätchen.
Also der Sensor (Siliziumplätchen) sollte in so einem Glasgehäuse
stecken.
Das ist dann mit der Platine verlötet (SMD). Und unter dem Gehäuse steht
manchmal die genaue Bezeichnung des sensors.
Mit ein bisschen Geschick könnte man dann uU das Datenblatt finden.
(Ich tippe mal auf einen Micron Sensor, da findet man auch die
Datenblätter recht einfach)
Dann könnte man den Chip ggf einzeln nutzen ;)
Eine Direktansteuerung halte ich nicht für sinnvoll. Da das auslesen des
Photoarrays zeitlich kritisch ist. Desweiteren müsste ich dann auch noch
den Speicher bereitstellen 640x480x8Bits (332). Und wer den Chip gesehen
hat wird es sein lassen ;-)
Es gibt ja noch mehr als Atmega CPUs da draußen ;)
Zeitkritisch für nen Atmega ja, nen FPGA machts mit links...
Hast du Fotos von dem Chip ?
Aufgrund deiner Anmerkung wegen der Größe vermute ich die haben nen 1/4"
Sensor drunter ?
ok damit hatte ich nicht gerechnet gg
Auslöten geht ja noch (bügeleisen/heissluft von der rückseite)
aber das wars dann auch schon gg
Danke fürs Pic ;)
Wo hast du die Werte her ?
Ausprobiert oder aus irgendeiner Beschreibung ?
Funktionieren eigentlich die ganzen Farbmodi (2bpp, 4bpp, 8bpp, 12bpp,
16bpp) aus der Beschreibung der C328 ?
Hallo,
Farbmodis habe ich noch nicht alle durchgetestet. Ich habe den
Datenstrom von Handy und Kamera aufgezeichnet. Und gesendete Register
(Kommandos) durchgetestet.
Gruß
Ulrich
Heute kamen endlich meine Kameras. Erstmal bin ich erschrocken, denn die
Bilder waren alle rosa/grün. Grund: Ich hatte die Kamera nur mit 3,3V
betrieben. Mit 5V geht es besser...
Hier noch ein paar Befehle:
0x10,i,0x00,0x00,0x00 i=0..2, JPEG Kompression. 0 ist die beste, 2
die schlechteste
0x17,i,0x00,0x00,0x00 i=0..3, 0=Farbbild, 1=Graustufen, 2=blau,
3=braun
Wenn man die Bilder unkomprimiert anfordert, scheint die Kamera diese
auch JPEG zu komprimiert haben, man sieht nämlich deutlich die
Kompressionsartefakte.
Hallo,
Ja die Kameras arbeiten mit 5V haben einen kleinen Stabi! Intern
arbeiten diese aber mit 3,3V ich finde eine 5V Versorgung besser als
eine 3,3V ;-)
Gruß
Ulrich
Ich hab noch ein paar Befehle durchprobiert:
0x13 (Lichtfrequenz) wird nicht unterstützt, zumindest bekomme ich da
immer ein NAK.
0x21 und 0x22 gibt es noch, aber was diese bewirken konnte ich nicht
herausfinden.
Ich hätte da noch eine Frage, und zwar hierzu:
Ulrich Radig wrote:
> mit einem Propeller und der Kamera kam ich auf 6 Frames in der Sekunde.
Wie hast du das gemacht ?
Ich kommt mit viel Glück auf 1fps bei 160x120@8bpp. Die Kamera ist
einfach nicht schneller.
Oder verwendest du den Preview Modus ?
Ab und zu liefert die Kamera bei mir auch anstelle des Bildes bei dem
Get Picture Befehl ein NAK. Den genauen Grund habe ich noch nicht
rausgefunden, aber ich vermute es liegt an der zu kurzen Wartezeit
zwischen dem Snapshot und dem GetPicture Befehl.
Gibt es dazu irgendwelche Infos, Erfahrungswerte o.ä. wie lange man
warten muss ?
Das ist auch eine nette Lösung. Es geht zumindest irgendwann nach dem 5.
bis 15. Befehl.
Meine Erfahrung bisher: Wenn die Kamera ein NAK sendet, bzw. garnichts
sendet, dann habe ich zuletzt irgendwas falsches geschickt bzw.
irgendein Ack vergessen zu senden.
Wenn ich normale Bilder mache, dann sendet die Kamera (außer beim Sync)
nie ein NAK bzw. garnichts.
Noch eine letze Frage:
In welchem Format werden die Bilder im Preview Modus ausgegeben ?
Ich erhalte immer 18432Bytes, egal was ich einstelle.
Die Bilder haben eine Auflösung von 192x96, es scheint allerdings kein
8bpp Graustufenformat zu sein.
Hallo zusammen!
Frage an diejenigen, die die Cam an den AVR MCU bereits angeschlossen
haben:
Hat auch der MCU in euerer Schlatung die 3,3V Versorgung? (da TX-RX pins
der Cam anscheinend 3,3V pins sind)
Wenn man doch direkt 5V vom uC's TX und Reset einspeist, wird davon die
Cam nicht defekt?
Und wenn die nicht defekt wird, ist die Bildquali dann i.O? Ich denke an
die MCA25... was man da nicht alles vorschalten musste an den TX und
Reset pins....
Ganz andere Frage. Dem Datenblatt von AVR zufolge gibt's keine Baudrate
von 921600 Bits/sec (bei Fehler von 0%) wenn man den 18,432 Mhz Oszi
verwendet (mein MCU ist Atmega644-20). Der relative Fehler wird dann so
groß, dass er in dem Datenblatt nicht mal angeführt wird (- Zeichen in
der Spalte).
Frage ist ob einer schon den 18,432 Mhz Quarz getestet hat und ob es
funktionierte?
Vielen Dank für euere Infos im Voraus!
Hallo,
Ich habe keine Probleme mit der DC-3840 an einem AVR mit 5V. Man
benötigt keine weitere externe Beschaltung. Die MCA25 benötigte eine
stabilisierte 3,3V Spannung die DC3840 hat ihren eigenen Stabi.
Allerdings wenn man sichergehen will, kann man ja am TX Pin des
Prozessors den Pegel auf 3,3 V herrabgeteilten.
Gruß
Ulrich
Hallo,
> die Befehle 0x21 und 0x22 gibt es noch,
kann mir jemand sagen was diese Befehle ausloesen ?
Ulrich benutzt den 0x21 auch in cam.c:
in cam_picture_store(char mode)
cam_command_send (0x21,0x03,0x00,0x00,0x00);
Gruesse
horst
Interessant. Theoretisch sollte man jetzt in der Lage sein, das EEPROM
anzupassen: Die Register sind ja jetzt nun bekannt, der verwendete
Controller im OV528 ist ein 8051, die Initialisierung geschieht dadurch,
dass aus einer Tabelle im EEPROM Werte gelesen und in die OV528 Register
geschrieben werden.
Jetzt muss man nur noch die Startadresse von dieser Tabelle ermitteln
und kann dann die Register beliebig anpassen.
Die Daten in dem EEPROM sind reiner 8051 Programmcode. Die ersten
32Bytes müssen entfernt werden, danach beginnt der Code an Adresse 0.
Dass es wirklich passt, zeigt das angehängte Bild von einem
Dissassembler.
Insgesamt gibt es mehrere Tabellen, und der Befehl um Daten aus dem
Programmspeicher zu lesen wird sehr oft genutzt, was die Suche nach der
richtigen Tabelle schwer macht.
Die erste Tabelle ist 192Bytes lang, und sitzt an Adress 0x0030. Ab
0x0200 kommt der eigentlich Programmcode und vermutlich ab 0x159D kommt
dann eine weitere Tabelle, die in folgender Form aufgebaut ist:
00 00
01 80
02 80
03 60
06 60
07 00
0C 22
0D 22
11 01
usw.
Dies geht bis 0x1614
Wenn man die Werte mit den Registern vergleicht, dann passen die nicht
(die Werte ergeben in den entsprechenden Registern keinen Sinn). Danach
kommen nochmal >1kByte an Tabellendaten. Irgendwo in diesem Bereich
liegen also vermutlich die Registereinstellungen.
Das ganze zu simulieren ist sehr aufwendig, da die Software immer wieder
an irgendwelchen Abfragen hängen bleibt.
Die Geschwindigkeit der RS232 Schnittstelle kann doch nun direkt an die
richtige Adresse geschrieben werden. Allerdings werden die Werte nur
nicht dauerhaft gespeichert.
Das ist leider das Problem: Man benötigt erstmal die dumme Baudrate, um
diese umzustellen. Es wäre schön wenn man mit einer verträglicheren
anfangen könnte.
Ich habe herausgefunden, wie man die Baudrate anpasst:
Falls jemand den Code debuggen möchte (oder gar eine eigene Firmeware
schreiben), hier ein paar Infos:
Die OV528 Register sind als XRAM in den Speicherbereich des 8051
eingeblendet, und zwar im Bereich 0xFFxx.
Wie bereits gesagt, die ersten 32Bytes der EEPROM Daten wegwerfen, dann
hat man den reinen Programmcode. In diesem steht die Funktion zum
Beschreiben des Baudratenregisters an Adresse 0x0333. Diese wird genau
2x aufgerufen. Einmal wenn der Befehl 0x01 (INITIAL) gesendet wird.
Dessen erster Parameter ist die Baudrate als 2^x Teilerfaktor.
Standardmäßig ist hier 1 eingestellt, also 2^1 = 921kBaud. 4 ergibt
z.B. 115,2kBaud.
Der nächste Aufruf ist die Initialisierung mit dem Standardwert: 0x01.
Dies ergibt den Teilerfaktor 2, also 921kBaud. Hier kann man also den
Startwert einstellen. Ich habe hier 0x0F für 115200Baud hingeschrieben.
Die Adresse ist 0x0308 im Programmcode bzw. 0x0328 im EEPROM. Die Formel
zur Berechnung des Wertes lautet: (1,8432MHz / Baudrate)-1
Es gibt nur ein Problem: Ich habe keine Ahnung wie man den Wert am
besten ins EEPROM bekommt. Es gibt zwar so nette Befehle wie SAVE DATA,
aber wie man die Daten genau sendet, steht nirgends.
Also habe ich das EEPROM per Hand (also per AVR) direkt programmiert:
Die Adresse ist 0xAC und den Writecontrol Pin muss man auf Low legen, um
Daten schreiben zu können.
Super Sache :-)
Ich habe herrausgefunden die Baudrate kann über das Kommando ffffff01
geändert werden allerdings benötigt man am Anfang 921600Baud. Derzeit
versuche ich das EEPROM über ein serielles Kommando dauerhaft zu
beschreiben.
Gruß
Uli
Ja, das habe ich auch schon probiert. Der Befehl um Programmcode zu
laden wird zumindest anscheinend nicht unterstützt.
Im Moment versuche ich gerade den ffffff01 Befehl so umzuschreiben, dass
man nicht nur 2^n Teilerfaktoren, sondern beliebige Faktoren senden
kann. Die Standardbaudrate habe ich auf 19200 gestellt, das sollte
maximale Kompatibilität bieten. Erhöhen kann man ja immer noch. Momentan
habe ich nur noch das Problem, dass es irgendwo in der Software einen
Vergleich gibt: Ist der 1. Parameter beim ffffff01 Befehl >9 wird ein
NAK zurückgeliefert. Das muss ich noch entfernen. Dann lade ich hier
fertige Hex Datei hoch, die nur noch irgendwie ins EEPROM kommen muss.
Wie versprochen, hier ist die Hex Datei für das EEPROM. Geändert ist
folgendes:
- Baudrate auf 19200 eingestellt
- Parameter 1 von Befehl FFFFFF01 ist der Baudratenteiler, also
(1,8432MHz / Baudrate)-1
Die Baudrate wird übrigends erst nach dem Ack auf diesen Befehl
geändert.
Benedikt K. wrote:
> Wie versprochen, hier ist die Hex Datei für das EEPROM. Geändert ist> folgendes:> - Baudrate auf 19200 eingestellt> - Parameter 1 von Befehl FFFFFF01 ist der Baudratenteiler, also> (1,8432MHz / Baudrate)-1> Die Baudrate wird übrigends erst nach dem Ack auf diesen Befehl> geändert.
Genial. :-) Man bräuchte nur noch ne tolle Schnittstelle um das EEPROM
zu programmieren :|
Seltsam.
Bei mir reagiert die Kamera danach auch nicht wieder. Nach einem Sync
geht es wieder. So wie ich das verstanden habe, beschreibt dieser Befehl
nur den Programmcode RAM im OV528, nicht das EEPROM.
Das EEPROM müsste man mit SAVE DATA 0A, 03 beschreiben können. Ich denke
mal mit Serial Flash ist das EEPROM gemeint. Die nächsten 3 Paramter
sind die Länge, aber wo kommen jetzt die Daten ?
Hi, wie gut das ich das Datenblatt besorgt habe (Habe übrigens direkt
beim Hersteller angefragt und innerhalb von 5 Minuten haben die mir das
zugemailt!)
Das man die Baudrate mit dem x01 Befehl ändert hatte ich ja auch schon
raus, es steht ja so im Datenblatt.
Mein bisheriges vorgehen war auch erst einmal mit der hohen Baudrate
connecten und dann runterschalten.
Habt ihr dann bei der Übertragung mit 115200 auch ein vernünftiges Bild
im Browser bekommen ? Meins sah leider etwas "zerzaust" aus ...
Nächste Woche habe ich endlich Urlaub und kann mich dann auch etwas
näher mit dem Eeprom-Beschreiben beschäftigen, aber auch nur wenn ihr
das bis dahin das Problem nicht schon gelöst habt ;-)
Mmhh.
Hast Du schon die Werte im eeprom geändert, oder hast Du es vorerst noch
"softwaremäßig" die baudrate in der cam geändert ?
Ich bekomme unterhalb von 115,2 gar keine Verbindung zur Kamera.
Vielleicht hat sie ja schon einen Tick weg, von der ganzen probiererei.
Bei mir ist auch immer das erste Bild nach einem reset immer 1A und wird
dann von Bild zu Bild immer schlechter..
Ich habe ein modifiziertes EEPROM, (die Version die ich hier hochgeladen
habe). Die startet mit 19200 und danach stelle ich per (modifiziertem)
INITIAL Befehl auf die andere Baudrate um.
Das Verhalten klingt danach, als wenn noch irgendwo alte Daten im Puffer
rumfliegen, die von Bild zu Bild einen größer werdenden Offset
verursachen.
Benedikt: Perfekt. Mit 19200 Baud kann ich die Kamera (auch wenn
langsam) an meinen mit 12MHz getakteten AVR hängen.
Ich glaub ich muss mir mal so eine Kamera bestellen. Hast du schon eine
gute Methode gefunden um das ROM-Image zu flashen? (Außer das schon
angesprochen mit dem AVR Programmieren).
Bei 19200Baud sollten immerhin noch 1,875kByte/s möglich sein. Sprich
~10Sekunden für ein 320x240 Bild. Akzeptabel würde ich sagen.
PS: Ob der ENC28J60 auch noch mit 24,576 MHz funktioniert? Weiß da
jemand wie genau die Toleranzen sind?
Im Datenblatt steht auf Seite 81 etwas von 25MHz +/- 50ppm, was
natürlich somit nicht möglich wäre.
Wäre ja auch zu schade gewesen mit nur einem Quarz so weit zu kommen ;)
> Es gibt noch eine Kamerahandy, die gleiche Chipsatz hat: SYN0547A von> Motorola. Wen ihr Interesse habt, kann ich mitgeschnittene protocol> Posten. Die läuft übrigens mit 115200.
Das wäre prima, wenn Du das Protokoll mitschneiden könntest.
Michael wrote:
> Das wäre prima, wenn Du das Protokoll mitschneiden könntest.
Was soll das bringen ? Es ist doch bekannt, wie man die Kamera
ansteuert, und wie man im Datenblatt sieht, ist das Protokoll komplett
willkürlich wählbar, je nach Firmware des µCs.
@Ulrich:
Ich hab nochmal eine Frage. Wenn ich jetzt über HTerm und meinen
High-Speed USB-RS232 Wandler das Bild ausgelesen habe, wie füge ich dann
am einfachsten JPEG-Header hinzu um mir das Bild direkt anschauen zu
können?
Beziehungsweise: Welchen JPEG Header hast du den Bilddaten
vorangestellt?
Ulrich Radig wrote:
> Hallo,>> Es muß nichts mehr hinzugefügt werden, nur die ersten Längenbytes> entfernen und fertig. Ich meine das waren die ersten 16Bytes.>> Gruß> Uli
Ich glaube ich habe mich etwas unverständlich ausgedruckt. Ich meinte,
welchen JPEG Header ich voranstellen muss, um die Datei auf dem PC
anschauen zu können.
Ich glaube ja mal nicht, dass man einfach die von HTerm aufgenommenen
Daten als .jpg umbenennt und das dann funktioniert (Okay, abgezogen von
den Längenbytes)
Simon K. wrote:
> Ich glaube ja mal nicht, dass man einfach die von HTerm aufgenommenen> Daten als .jpg umbenennt und das dann funktioniert (Okay, abgezogen von> den Längenbytes)
Du glaubst es vielleicht nicht, aber es ist genau so !!!
Benedikt K. wrote:
> Simon K. wrote:>>> Ich glaube ja mal nicht, dass man einfach die von HTerm aufgenommenen>> Daten als .jpg umbenennt und das dann funktioniert (Okay, abgezogen von>> den Längenbytes)>> Du glaubst es vielleicht nicht, aber es ist genau so !!!
Alles klar, dann kommt also das PC-JPEG kompatible Bild (mit allen
Informationen zur Farbspeicherung und so weiter) direkt aus der Kamera.
Danke! :D
Hm. Ich hab hier den Wandler von Pollin. Die sind in der Regel alle
gleich aufgebaut. Also entweder Prolific Chipsatz oder ein FTDI
Chipsatz. Blöderweise ist bei dem Pollin Wandler direkt die RS232
Schnittstelle (ohne Umsetzer von TTL auf RS232 Pegel) aus dem Chip
herausgeführt, sodass ich einen Pegelwandler brauche.
Jedoch sind alle Versuche einen solchen zu bauen fehlgeschlagen. 1MHz
sind nicht zu unterschätzen.
Probiert habe ich es mit einem BC549 und unterschiedlich großen Pullup
und Basiswiderständen. Keine Chance für einen Analog-Laien :-)
Dann bastel ich mir erstmal eine kleine Platine für einen AVR und dann
seh ich mal weiter.
PS: Man kann übrigens auch ein 4poliges (Flachband-)Kabel an die
Kameraplatine löten.
Das Problem bei solchen Wandlern ist der RS232 Teil: MAX232 usw. sind
meist nur bis 115kBaud spezifiziert. Es gibt zwar einige die auch mehr
können, aber die sind eher selten.
Jup, sag ich ja. Ich war zuerst zuversichtlich und hab meinen RS232
drangehangen und mich nur gewundert, was denn da zurückkommt. Kamera
kaputt? Aber irgendwann hats dann auch Klick gemacht und dann ist es mir
aufgefallen.
Naja, Pegelwandler in der Geschwindigkeit für RS232 sind selten,
richtig.
Ulrich hat die Kamera an einen AVR angeschlossen und übertragt das Bild
anschließend mit einer niedrigeren Geschwindigkeit zum PC :D
@Ulrich: Mir sind in der Zwischenzeit noch ein paar Fragen gekommen.
EDIT: Hat sich schon weiter oben erledigt. Wer lesen kann ist klar im
Vorteil ;) Ignoriert den Rest des Postings.
in deinem Code wartest du immer in der Empfangs-Routine für ein Zeichen
über das USART solange, bis du den entsprechenden 512Byte "Block" aus
dem Picture-DatenStream herausgeholt hast. Wird dann ein Byte
angefordert, dass zur Zeit nicht im Buffer liegt, dann wird erneut das
Image abgerufen und wieder solange gewartet, bis der relevante
Code-Block hereinkommt.
Allerdings sagt das Datenblatt des C328 etwas anderes zu dieser
Vorgehensweise:
Man kann die Daten mit Get Picture anfordern, daraufhin sendet die
Kamera, dass die Daten bereit zum senden sind und weiterhin noch die
Länge der Daten.
Anschließend kann man mit ACK Befehlen gezielt die Pakete anfordern.
Bis man irgendwann die Paket-ID 0x5050 sendet. Dann hört die Kamera wohl
auf.
Warum hast du das nicht so gemacht? Ist das etwa in der DC3840 nicht
implementiert? Schickt die DC3840 sofort ~15kB (Bei 320x240px) an Daten
über ihren TxD Draht nach draußen ohne Rücksicht auf Verluste?
Ich kann diese Vorgehensweise nur bei dem Uncompressed Picture finden.
(Vermutlich weil der RAM der Kamera zu klein ist, um es
zwischenzuspeichern)
>Also entweder Prolific Chipsatz
Mein USB-Seriell Kabel mit dem Chipsatz macht auch nur 115.200 max.
>Ich habe meinen USB nach RS232 TTL Wandler genommen zu finden auf meiner>HP unter Projekte.
Ha, prima das Du das erwähnt hast. Mir ist gerade eingefallen, das ich
auch noch so ein Modul im Bastelkeller habe. Manchmal geht einen schon
der Überblick bei seinen Sachen verloren...
Jetzt kann ich wenigstens auch per PC die Kamera ansteuern.
Simon K. wrote:
> Allerdings sagt das Datenblatt des C328 etwas anderes zu dieser> Vorgehensweise:>> Man kann die Daten mit Get Picture anfordern, daraufhin sendet die> Kamera, dass die Daten bereit zum senden sind und weiterhin noch die> Länge der Daten.> Anschließend kann man mit ACK Befehlen gezielt die Pakete anfordern.
Der Befehlssatz ist nur ein Beispiel (steht auch dabei). In der Kamera
läuft ein µC, der diesen Befehlssatz ausführt. Und der ist von
Hersteller zu Hersteller der fertigen Kamera mehr oder weniger
unterschiedlich, je nach Software im EEPROM.
Mit direktem Zugriff auf die Register, sollte man das umstellen können.
Ich habe dies aber noch nicht ausprobiert
Danke Benedikt. Das konnte ich nach dem gründlichen kompletten Lesen des
Threads hier auch schon erfahren :-)
Übrigens, der MAX3225 ist ein 2/2 RX/TX 1MBaud Wandler für RS232
verfügbar im DIP Gehäuse.
Bezüglich Firmeware ändern:
Ich habe ein Firmware-Update Tool, anbei im Anhang, für eine
C328-ähnliche Kamera (CAM-UCAM100) aus dem Netz geladen und mal den
Vorgang für den Firmware-Download des Tools mit einen Com-Port-Sniffer
"mitgesnifft" (Siehe auch den Anhang). So wie es aussieht lädt das
Programm eine Software in die Kamera (Befehl FF FF FF 0C 05 40 16 00).
Ich habe mal ein bischen herumgespielt und die Ack_befehle durch die der
Phillips ersetzt und mit dem Hammer-Terminal (Super Teil !) zur Kamera
geschickt, aber leider reagiert die cam danach nicht mehr und spuckt
leider nicht denn eeprom-Inhalt aus :-(
Mann muß sie erst wieder neu initialisieren bevor wieder eine Reaktion
kommt.
Was mich noch interessieren würde ist, was das Firmwartool in die Kamera
schreibt. Es ist ja wohl auch 8051 Assembler, hab da aber mit einem
Disassembler nix entschlüsseln können. Vielleicht kann da jemand anderes
was entschlüsseln.
Meine Hoffnung ist ja immer noch das wir es hinbekommen den EEpom Inhalt
Softwaremäßig zu ändern ;-)
Michi Müller wrote:
> Ich habe mal ein bischen herumgespielt und die Ack_befehle durch die der> Phillips ersetzt und mit dem Hammer-Terminal (Super Teil !) zur Kamera> geschickt, aber leider reagiert die cam danach nicht mehr und spuckt> leider nicht denn eeprom-Inhalt aus :-(> Mann muß sie erst wieder neu initialisieren bevor wieder eine Reaktion> kommt.
Ja, genau das passiert bei mir auch.
> Was mich noch interessieren würde ist, was das Firmwartool in die Kamera> schreibt. Es ist ja wohl auch 8051 Assembler, hab da aber mit einem> Disassembler nix entschlüsseln können. Vielleicht kann da jemand anderes> was entschlüsseln.
Wenn ich das richtig sehe, wird nach dem 0C Befehl das Register 0x0C mit
0x1F beschrieben. Und danach hängt sich die Software auf !!!
05EF A1 EF ajmp 5EFh
Das ist genau das Verhalten, das man auch sieht. Anscheinend gibt es
irgendeinen Watchdog o.ä. der nach einer bestimmten Zeit oder Anzahl
nicht beantworteten Anzahl an Bytes den 8051 neu startet.
Ich vermute also, der Download Befehl wurde auf diese Art entfernt.
Ich habe die Geschwindigkeit mal auf 115.200b runtergeschaltet
(inspiriert durch deinen Watchdog) und das File nochmal durchgejagt.
Jetzt gibt er auf die Daten wenigsten schon mal Errors aus und hängt
sich nicht direkt auf danach.
Hallo Josef,
vielen Dank für die Einstellung des Protokolls der IQP-500. Verstehe ich
das richtig, dass für die Kommunikation mit der Kamera RTS immer 1 sein
muss? Was ist mit CTS? Kann man beide (RTS und CTS) permanent auf 1
setzen?
Hast Du vielleicht schon die Kommunikation in einem Programm umgesetzt?
Gruß
Martin
So, ich habe jetzt mal die Kamera an einen Webserver gefriemelt,
allerdings habe ich ein paar Probleme.
Sende ich
- Reset
- Initial
- Snapshot
- 200ms warten
- GetPicture
dann läuft alles glatt.
Aber wenn ich zu einem beliebigen Zeitpunkt nochmal
- GetPicture
sende, dann dauert es 7 Sekunden bis die Kamera die JPEG Daten
rausschmeißt. Ist das ein bekannter Bug? Oder ist das korrekt? Ich
glaube ja mal kaum.
Ich habs sogar auf dem Speicheroszilloskop mir angeschaut. ~7sekunde
nachdem das GetPicture Paket kommt, kommt das große Datenpaket.
Jemand eine Idee dazu?
Was mich übrigens ein bischen stutzig macht, ist, dass du in deinem
Sourcecode die serielle Schnittstelle vom Mega644 nur mit 5 Bit
betreibst..?
Für eine 8Bit Schnittstelle muss 3<<UCSZ00 ins UCSRC Register
geschrieben werden, wenn ich mich nicht irre.
Und warum fügst du der Länge, die im DATA Befehl von der Kamera kommt 1
hinzu?
Steht im Datenblatt auf Seite 185 im 02/07 Datasheet vom Mega644 (Jaja,
etwas antiquitiert):
UCSZ01 und UCSZ00 müssen auf 1 sein für einen 8-Bit Transfer. Übrigens
hast du auf dem Bild von der Kamera auf deiner Seite auch stehen, dass
die Kamera keine Stoppbits braucht. Aber du meintest vermutlich
Paritätsbits.
EDIT: Ich seh schon, der Defaultwert von UCSRC setzt die beiden Bits
automatisch, najo.
Ok, habe nun herausgefunden woran es lag: Ich habe die SendCommand
Funktion etwas abgeändert, sodass der Befehl erneut geschickt wird,
solange bis ein ACK kommt. (So wie in deinen Sourcen)..
Gut, geht nun. Zugegeben eine etwas frickelige Kamera ;)
Mahlzeit,
ich hab mir den Cam-Treiber mal nach Pascal übersezt,
nun habe ich folgendes Problem:
Init klappt,
dann sende ich cam_picture_store:
1
cam_send_cmd(0x08,0x01,0x00,0x00,0x00);
2
cam_send_cmd(0x10,0x01,0x00,0x00,0x00);
3
cam_send_cmd(0x12,0x00,0x00,0x00,0x00);
4
cam_send_cmd(0x18,0x01,0x00,0x00,0x00);
5
cam_send_cmd(0x17,0x00,0x00,0x00,0x00);
6
cam_send_cmd(0x21,0x03,0x00,0x00,0x00);
7
cam_send_cmd(0x01,0x01,0x07,0x19,0x13);
8
cam_send_cmd(0x05,0x00,0x00,0x00,0x00);
9
cam_send_cmd(0x04,0x01,0x00,0x00,0x00);
Die Cam antwortet bis einschließlich 0x05 mit ACK,
auf 0x04 antwortet sie mit NAK aber ohne Fehlernummer:
FF FF FF 0F 00 00 00 00 00 00 00 00 00 00 00 00
Hat jemand eine Vorstellung, woran das liegen könnte?
Gruß
Marco
Hallo,
mein letztes Problem habe ich gelöst,
war ein Fehler in der Int-Routine.
Jetzt versuche ich die Baudrate zu senken,
aber bisher ohne Erfolg.
Wie genau muss der Befehl für die Baudrate aussehen?
Laut Benedikt in 2 Aufrufen FFFFFF0104
Und dann FFFFFF0101
Das soll 115200 Baud bewirken.
Sehe ich das richtig?
Hat evtl Jemand das richtige Datenblatt zur Cam?
Ich finde hier immer nur das Datenblatt zur C328.
Grüße
MArco
Marco Bajerski wrote:
> Das soll 115200 Baud bewirken.> Sehe ich das richtig?
Ja.
> Hat evtl Jemand das richtige Datenblatt zur Cam?> Ich finde hier immer nur das Datenblatt zur C328.
Ein Datenblatt zu dem Chip gibt es hier:
http://www.mikrocontroller.net/attachment/30805/OV528_DS_1.3.pdf
Der Rest ist kundenspezifische Software. Dazu wird man eher nichts
finden.
Danke für die Info!
Wenn ich die Baudrate mit:
cam_send_cmd (0x01,0x04,0x07,0x09,0x05);
cam_send_cmd (0x01,0x01,0x07,0x09,0x05);
umstelle dann erhalte ich auf den ersten Aufruf von der cam ein ACK,
auf den 2. Aufruf antwortet sie dann mit:
80 80 80 00 00 80 00 80 80 00 00 00 00 00 00 00
Es ist also etwas passiert, wenn ich anschließend den UART auf 115200
Baud umstelle, passiert aber garnix mehr.
Was mache ich falsch?
Hallo,
kann mir vllt jemand sagen wie es mit der Infrarot Empfindlichkeit der
Kamera aussieht? Sieht man Fernbedienungen damit, ist da ein Filter
drinn der IR rausfiltert?
Hintergrund wäre die Kamera mit einem Tageslichtfilter zu verwenden um
ein Objekt mit einem Infrarot Sender zu Tracken.
gr
thomas
Hallo,
danke, jetzt klappts ;-)
Aber auch mit geringerer Baudrate kommen immer noch fehlerhafte Bilder,
die Cam treibt mich in den Wahnsinn.
Gruß
Marco
Hallo,
beides 014.745600.
Hardwareproblem kann ich ausschließen, denn Ulis Version läuft 1A,
nur mit meiner Pascal-Übersetzung haperts.
Ungewöhnlich ist, dass ab und zu auch ein brauchbares Bild bei raus
kommt.
Allerdings, bin gerade dahinter gekommen warum das so ist.
Mein Pascal Compiler kann Longint weder multiplizieren noch dividieren,
er rechnet dann mit integer, anstatt einen Fehler auszuspucken.
Moin Leute
Ich hab da ein Problem.
Meine Kamera Hängt an einem ARM der mit dem PC verbunden ist. Ich möchte
gerne ein Preview Bild mit dem C++ Builder darstellen. Nur wird dieses
nicht richtig Dargestellt.
In welchen Format ist das Preview Bild. Im Moment stelle ich jeden
ankommenden Wert(s/w(8-Bit)) von links oben Zeile für Zeile nach rechts
unten dar. Das ist offensichtich falsch.
Gibt es eine bestimmte Struktur wie die Pixel angezeigt werden müssen
bzw Format.
Zum besseren verständnis hier mal ein Pic. Das aufgenommene Bild ist zur
hälfte Schwartz und zur Hälfte Weiß. Idealerweise hätte ich eine Klare
Trennlinie Zwischen diesen bereichen.
Hat jemand die gleiche erfahrung gemacht.
Ok der Buffer aud der PC seite des UART war zu klein bzw schlecht
programmiert.
Wenn es jemanden interessiert.
Wenn ein Grau Skala Bild gemacht wird, können die Daten Zeile für Zeile
von Links nach Rechts Dargestellt werden.
Tolles Bild
moin. ich bin jetzt auch gerade am rumexperimentieren mit der camera und
habe das bsp programm von uli versucht zu verwenden. ich lese am com
port im moment folgendes aus :
was mir immerhin nicht komplett falsch erscheint. das "JFIF" in den
ersten paar bytes scheint mir fuer einen jpg header typisch zu sein. ich
las dass ich die ersten 16 bytes loeschen sollte ... habe ich auch
probiert, das erste bis inc dem 16. das hat alles nicht dazu gefuehrt,
dass diese daten als jpg interpretiert werden koennen.
hat jemand eine ahnung wo der fehler liegen koennte ?
mir erscheint der ganze datensatz auch relativ klein. ich habe jetzt
noch nicht ueberprueft in welchem modus das programm von uli sdtmaessg
ein bild aufnimmt. evtl ist es ja eine sehr geringe aufloesung.
ich habe auch schon versucht die ersten paar bytes aus einem der anderen
bilder die hier mit der camera gemacht und gepostet wurden zu ersetzen,
das hat aber nur dazu gefuehrt, das irfan view sagte : "jpg datastream
contains no image" ob das nun aber bei einem ersetzten header
irgendwelche aussage hat weiss ich leider nicht. es kann ja sein, das
der header aus dem funktionierendem bild den ich verwendet habe bei dem
bild das ich gemacht habe einfach der falsche ist, weil andere
farbeinstellungen/aufloesung oder was auch immer. ich verwendete "ÿØÿà
JFIF" statt meinen ersten bytes.
evtl hat sich ja schon jemand mit aehnlichen problemen konfrontiert
gesehen. vielen dank fuer eure zeit.
Hallo,
soweit ich weiß, werden die ersten 16 Bytes beim aktuellen Beispiel
schon von der Software gelöscht.
Lass dir das mal mit hterm im hex-Format ausgeben und dann speicher das
ganze im RAW-Format, dann sollte es klappen.
Die JPEG Files beginnen übrigens mit FF D8.
Gruß
Marco
aha. danke, das ist schonmal ein guter tip. jo ich habe das auch so wie
von dir beschrieben mit hterm gemacht. aber leider kein erfolg. ich bin
mittlerweile der meinung, das die daten schlicht nicht in dem bild
vorhanden sind. ich habe aus ulis programm den softuart ausgetauscht
gegen einen normalen uart (atmega 162 mit 2 uarts) und dabei ist mir
wohl ein fehler unterlaufen. das nicht funktionieren unten beschriebener
codezeile würde auch dazu passen, dass in meinem bild scheinbar keine
daten vorhanden sind, sondern nur header und drumherum. ich habe jetzt
um dem nachzugehen den modus der bildaufname auch mal von 160*120 auf
640*480 geschaltet. die erhaltenen daten bleiben in etwa gleich gross.
das kann schonmal nicht angehen.
UCR=(1<<RXC1);//<-- hier bin ich mir nicht sicher.
15
16
cam_command_send(0x04,0x01,0x00,0x00,0x00);
17
for(unsignedlonga=0;a<100000;a++){asm("nop");};
18
}
19
byte=byte%DAT_BUFFER_SIZE;
20
21
return(cam_dat_buffer[byte]);
22
}
die eine zeile von uli habe ich mal auskommentiert. die hatte ich
bishher noch nicht ersetzt durch eine fuer den normalen uart passenden
zeile (uart1 in meinem fall fuer die camera). nun weiss ich nicht, was
nach ulis softuart mit diesem D6 da eigentlich gemacht wird. der D5
scheint ja der über software emulierte TX pin zu sein. ist der D6 dann
als RX pin geplant ? das steht da so explizit leider nirgends. oder aus
welchem grund wird hier D6 gesetzt ? wie muesste das für einen normalen
uart ausschauen ?
wer 7 statt 8 databits einstellt, der darf sich ueber datenmuell nicht
wundern.... ich poste den code fuer 2 uart controller an einem atmega
spaeter sobald ich ihn bereinigt habe. es laeuft jetzt. danke.
Moin.
Mein aktuelles Problem ist nun, dass ich 2 Bilder hintereinander machen
möchte und zwar in Graustufen. Diese beiden Bilder möchte ich dann pro
Pixel in Ihren Helligkeitswerten auf einem AVR voneinander abziehen. Die
daraus Resultierende Matrix aus Grauwerten soll dann weiter verarbeitet
werden. Es ist in diesem Fall nicht wichtig, dass diese Matrix noch
irgendein Bildformat hat. Dazu stellt sich jetzt die Frage wie ich das
am besten machen.
A) ich verwende jpg Dekomprimierungsbibliotheken für c um an die
Grauwerte der einzelnen Pixel zu kommen
B) ich lasse mir von der Kamera direkt ein Bild übertragen welches
unkomprimiert die Grauwerte in einer Matrix enthält.
zu B habe ich leider noch keine möglichen Kameraeinstellungen gefunden.
Ist da jemand schon weiter? ich habe es bisher mit
probiert, bin mir aber bei der interpretation der Daten nicht sicher. Es
werden viel weniger Bytes bei gleicher Auflösung zurückgegeben als bei
einem komprimierten Bild, das kann ja schonmal nicht sein....
zu A) fehlt mir im Moment eine Bibliothek zum dekomprimieren von .jpg
Dateien. Diese finden sich zwar haufenweise für c++ aber so gut wie
nicht fuer c.
Hat jemand ähnliches Probiert oder einen Tip ?
Danke für Eure Zeit
Moin Forum
Mir ist einiges bei der C328R noch nicht Klar deshalb stelle ich mal ein
paar Fragen.
1-Was ist genau der Unterschied zwischen Snapshot und Preview?
2-Ich bekomme maximal 3 Bilder/s bei uncompressed preview 115200baut
80*60(UM Seite12). Geht da noch mehr ohne jpeg?
3!!!!-Nochmal zu 2.
Nach der Initialisierung habe ich 2 bis 3 sec Zeit um das Get Picture
Com abzusetzen mache ich das nicht ist die Kamera Praktisch tot. d.h.
Ich kann nicht neu Initialisieren und das Get picture com erneut
absetzen.
Bleibe ich beim get picture innerhalb der 2-3s kann ich auch 1000 bilder
machen. Hat oder besser hatte jemand auch dieses Problem und kann
helfen.
Ich hoffe ich habe das halbwegs verständlich ausgedrückt
Moin Matatron.
Mich würde gerade mal brennend interessieren wie du es hinbekommst die
bilder unkompressed zu empfangen, das funktioniert bei mir naemlich
derzeit ueberhauptnicht. kannst du mir bitte die commands die du in
folge sendest posten und evtl nen kleinen commentar geben. ich bin mir
recht sicher, dass ich das datenblatt richtig verstanden habe, aber bei
mir will es einfach nicht. ausserdem wuesste ich gerne wie die
unkompressed daten dann zu interpretieren sind. aus dem hterm in eine
.jpg datei kopieren wird ja dann vermutlic nicht mehr möglich sein oder?
ich suche immer noch nach einer möglichkeit ein farb oder grauwertbild
so von der camera anzufordern, dass mir in folge fuer jeden pixel die
farbwerte uebertragen werden, statt das ein komprimiertes bild ankommt,
dessen dekomprimierung auf dem avr zu rechen/speicher-intensiv wird.
zur uebertragungsrate :
80*60 pixel = 4800 pixel
4800 * 8 = 38400; angenommen jeder pixel hat 8bit information. farbwerte
gibts glaube ich bis 12bit rauf ?
da haste du bei 115200 baud also noch 115200/38400 = 3 pro sekunde.
was dabei nicht bedacht ist sind natuerlich saemtliche rechenoperationen
auf den mCs - die werden aber nicht so sehr ins gewicht fallen vermute
ich (es sei denn du rufst jeden pixel einzelnd ab, statt alle am stueck
als stream ausgeben zu lassen) und erkannte uebertragungsfehler/resends
usw. also liegst du mit deinen 3 bildern pro sekunde etwa da wo man es
erwarten wuerde. der flahscenhals sind halt die 115200 baud. die kamera
liefert ja irgendwo im 900.000er bereich an den mC. also koenntest du
den mC einfach ueber eine andere schnittstelle auslesen (usb ist
schneller als der serielle port vermute ich). da muesste man sich
informieren in wieweit ein com zu usb adapter diese geschwindigkeit
nutzen koennte (um weiteres loeten zu vermeiden).
ich habe anstelle das ttl zu rs232 auf den comport noch eine
funkuebertragung ueber zigbee dazwischen und die laeuft stabil mit guten
19200 baud (das ist etwa die geschwindigkeit in der meine oma schreiben
kann), also kopf hoch :) - das ist dann auch der grund warum ich die
bilder nicht am pc dekodieren will, sondern auf dem mC - um nicht
unnoetig sachen zu uebertragen die ich eh nich brauche.
sorry Mad Tulip hab nur auf der Arbeit Internet.
also: Uncompressed Preview 80*60
1.Initialisierung
AA 01 00 02 01 00
AA01=ID
00 =immer
02 =4 bit grau scale für 8 bit grau scale 03 eintragen
01 =80*60
00 =immer
dann bekommst du wenn alles gut geht den ACK
2. Get Pic
AA 04 02 00 00 00
AA04=ID
02 =Preview
00 = immer
" "
dann wieder ACK & große der Daten
Jetzt kannst du die 4800 punkte direkt von oben Zeile 1 von links nach
rechts darstellen dann Zeile 2 usw.
das geht im c++ Builder ganz gut. Das ganze steht im User M auf seite 12
ganz gut erklärt.
ps: bei 4 bit Grau Scale sind in einem Byte 2 Pixel untergebracht für
die Schnelligkeit
Hallo
Ich habe mir bei Ulrich eine Philips DC-3840 gekauft.
Ich habe mir nun das Datenblatt für den OV528 angesehen und mache mir
darüber Gedanken ob und wie man die „serielle 4 Draht Übertragung“ (“4
wire serial interface”) nutzen kann.
Leider sind die Daten über die Vierleiterschnittstelle mehr als dürftig.
Handelt es sich in beiden Fällen um die gleiche UART? Nur einmal mit und
einmal ohne Hardware Handshake und wo kommt da die Leistungssteigerung
von 920kbps auf 2Mbps her?
Das Layout zeigt das der SXIN (Pin 12) Eingang mit dem UCLK (Pin 16)
Ausgang verbunden ist.
Die Berechnung der Baudrate sollte dann folgendermaßen aussehen.
Der Systemtakt fXIN von 14,7456MHz wird durch einen Frequenzteiler auf
den RS-232-Master-Takt fUCLK herunter geteilt. Es besteht dabei die
Möglichkeit den Systemtakt ungeteilt zu übernehmen oder im Register UDIV
das Teilungsverhältnis einzustellen.
Im Datenblatt angegeben ist folgende Gleichung: UCLK = XIN 2
(UDIV+1) ODER UDIV = 80h => UCLK = XIN.
Ist damit eigentlich UCLK = (XIN / 2) / (UDIV+1) gemeint?
Der Mastertakt fUCLK speist dann über den SXIN Pin den
Baudratengenerator.
Die Baudrate BaudR berechnet sich nach folgender Formel
Baudrate = (fUCLK /2) / (UBR+1),
wenn ich die im Datenblatt angegebene Formel
Baudrate = SXIN 2 (UBR+1)
richtig interpretiere.
Mit UDIF =1 und UBR=1 folgt dann
Baudrate = ((((14,7456MHz /2) /2) /2)/2) = 921.600bps.
Wenn ich dann UDIV=80h setze und UBR=0 käme man auf eine Baudrate =
((14,7456MHz/2)/1) = 7.372.800bps.
Könnte man aus dem Datenblatt schließen das mehr als 2Mbps nicht drin
sind?
Treiberfähigkeiten der IO-Pins?
Seite 4 sagt „4-wire serial bus: 1~2M bps for transferring JPEG still
pictures or SIF (320x240) preview @4 bpp with 6~8 fp“
Für die Signale RTS_ (Pin17) und CTS_ (Pin 20) finde ich in den
Registern irgendwie keine direkte Abbildung mit den man deren Pegel via
Software steuern kann.
Ich vermute das diese Leitungen per Hardware über die FIFO - Zustände
gesteuert werden?
Diese werden im Register CSS (Chip select & status)
Bit 7: Serial bus received FIFO empty status. Read only
Bit 6: Serial bus received FIFO full status. Read only
Bit 5: Serial bus transmitted FIFO empty status. Read only
Bit 4: Serial bus transmitted FIFO full status. Read only
für das Betriebsprogramm zur Auswertung bereitgestellt.
Das ganze Datenblatt scheint mir nicht alle Informationen zu enthalten?
Vielleicht gab es weitere „Datenblätter“ zum OV528?
Auch zum EEprom stellen sich mir noch ein paar Fragen. Wird das Programm
bei Power Up einmal in der OV528 eingelesen und dann intern in einem RAM
gehalten? Und falls das so ist wäre es möglich das EEprom mit einem MC
zu simulieren? Das würde ein spielen mit dem Anwendungsprogramm
wesentlich vereinfachen?
Und dann hab ich da noch eine Befürchtung, es handelt sich nicht nur um
eine doppelseitige Platine, sondern und mindestens eine 4 Lagen
Multilayerplatine?
Würde mich über jeden Kommentar freuen.
Grüße Dirk
@Matatron:
Kann es sein das Du statt "FF" "AA" geschrieben hast?
1.Initialisierung
AA 01 00 02 01 00
...
Sollte das nicht FF 01 00 02 01 00 heißen?
Ist noch nicht verifiziert, bin noch am Anfang...
Gruß
Ralf
Hallo
Ich versuche gerade die DC-3840 an einen PIC18F2550 zu hängen
und Bilder über die USB-Schnittstelle zum PC zu übertragen.
Der USB Stack läuft und ich kann bereits mittels MPUSBAPI Daten
im Burstmode vom PC zum PIC und zurück übertragen.
Momentan versuche ich das Kameraprotokoll in eine State-Maschiene
zu packen. Diese soll in einer Endloschleife gepollt werden.
Jetzt frage ich mich wann die Kamera genau mit einem ACK antwortet?
??? ??? sind die Stellen bei denen ich mir nicht sicher bin.
Bei der Synchronisation scheint es klar zu sein.
PIC->CAM : SYNC solange bis ACK von CAM
CAM->PIC : ACK
CAM->PIC : SYNC
PIC->CAM : ACK
Dann die Initalisierung
PIC->CAM : RESET
??? CAM->PIC : ACK ???
PIC->CAM : INIT
??? CAM->PIC : ACK ???
Dann Bilder abrufen
PIC->CAM : SNAPSHOOT
??? CAM->PIC : ACK ???
PIC->CAM : Get Picture
Bilddatenübertragung
CAM->PIC : Data
CAM->PIC : Bilddaten [x Bytes]
??? PIC->ACK : ACK ???
Dann zurück nach Bild abrufen.
Grüße und vielen Dank
Dirk
PS: Nachdem ich mir das Datenblatt noch einmal angesehen
habe, beschäftigen mich die Fragen in meinem obrigen
Post [[Beitrag "Re: Protokoll DC-3840 Handycam"]]
immer noch.
Dirk F. wrote:
> Jetzt frage ich mich wann die Kamera genau mit einem ACK antwortet?> ??? ??? sind die Stellen bei denen ich mir nicht sicher bin.
Nach jedem Befehl entweder mit einem ACK oder NACK.
Du musst darauf achten, wann genau Du und wann die Kamera den
Baudratenwechsel durchführt.
Evtl. muss Du noch auf den Ack warten, bevor Du umschaltest.
Ich weiß jetz nicht, ob die Senderoutine mit einem Fifo arbeitet, d.h.
die Routine wird beendet, bevor alle Bytes rausgesendet sind, wird die
Baudrate schon während des Sendens umgeschaltet. Das geht natürlich
schief.
Hallo, ich fange auch gerade mit der Cam an, nur leider bekomme ich als
antwort auf den Sync immer nur "0C 80 80 80". Momentan hängt mein Aufbau
an einem MAX3225 und darüber am PC, am PC lese ich mit HTerm.
Ich schicke "FF FF FF 0D 00 00 00 00" zur Cam, mehrmals, und erhalte
iwann genauso oft "0C 80 80 80" als Antwort, wie ich zuvor "FF FF FF 0D
00 00 00 00" gesendet hab.
Dass es immer bisschen dauert liegt iwie an der Verbindung HTerm mit
meiner RS232 Karte, Windows Hypterterminal geht einandfrei, da empfange
ich alles sofort, nur leider kann ich da keine Hex-Eingaben machen.
Ne Idee an was es liegen könnte? Loopback nach dem MAX3225 zurück zum PC
zeigte eine einwandfreie Übertragung. Kamera läuf wie der MAX an 5V.
MFG
µLuxx
Hi, mich beschäftigt das Thema auch schon 'ne ganze Weile und verstanden
habe ich dieses Ding noch nicht so ganz. Das, was du da schilderst, habe
ich auch so erlebt, als ich die Kamera mal direkt an einen PC
durchgereicht habe. Mit Hterm habe ich im Übrigen auch gute Erfahrungen
gemacht, das Bray-Terminal hat ein Datendurchsatzproblem und verschluckt
gerne etliche Bytes.
Ich benutze mittlerweile einen virtuellen COM-Port via USB (FTDI 245),
damit man überhaupt über 115200 hinaus kommt. Was ich bislang
festgestellt habe ist, dass das Timing schon sehr scharf ist und
entsprechend bedient werden muss. Man kann sehr leicht asynchron werden.
Und dann klappt einfach nix.
Zudem kann ich die Ausführungen hier im Thread als auch die von Ulrich
auf seiner Homepage nicht alle so ganz nachvollziehen. Ich habe es
bislang z.B. noch nicht hinbekommen, dass die Kamera mit weniger als
230400 Baud sauber funktioniert. Dann scheint es 18 Bytes und nicht 16
Bytes nach Senden des Get-Pic-Befehls zu dauern, bis das JPG-Bild kommt
- so ist es jedenfalls bei mir.
Ich frage mich mittlerweile, ob diese Kamera es wert ist, soviel Zeit
damit zu verbringen. Gibt's nicht noch was Besseres?
Hallo
@µluxx
Möglicherweise liegt das Problem an der Datenleitung von der Kamera zum
PC.
Bei mir erreicht die Spannung für den High Pegel der Kamera ca. 2,6V.
Für den Input-Pin der UART in meinem PIC ist das zu wenig. Die UART hat
CMOS-Schmitttrigger Eingangsstufen (Highpegel = 5V * 0,7) und keinen
TTL-Eingang, da wäre der High-Pegel 2V. Deshalb scheint es auch mit
einem
MEGA zu funktioniern.
Ich habe zwei 74 HCT 04 Inverter (nicht HC) in Reihe an den Ausgang der
Kamera gelegt. Die haben TTL-Inputs und CMOS Outputs.
Beim MAX3225 ist der Input Logic Threshold High (bei Vcc = 5V) = 2,4V.
Je nach dem wäre es vielleicht ratsam den Baustein mit 3,3V zu
betreiben,
da sind es dann 2V. Je nachdem was für ein Spannungsabfall auf den
Leitungen dazu kommt und sich die Sache bei 900kbit verhält.
Grüße Dirk
das problem ist aber dass der max3225 nur bei 5V für 1Mbaud spezifiziert
ist.
andererseits habe ich mit dem bis 250k spezifierten max232 auch 460k
ohne probleme hinbekommen...mal schaun, aber danke für den Tipp!
also daran lag es nicht, ich habe eher den verdacht dass es iwie an
meiner rs232 karte liegt, ich hab mir jetzt nen MBaud USB-RS232 wandler
gekauft, mal schaun was der bringt...
Hallo,
die letzten Nächte habe ich mit der Kamera von Ulrich Radig und einem
ATmega32 auf dem STK500 verbracht und sind schon fast Freunde :-)
0) Was geht...
JPEG-Snapshot und Übertragung mit der SoftUART zum Windows-PC,
allerdings nur mit 34800 Baud. Habe dazu die alte CAM_Testsoftware
(01/2008) mit dem Code aus dem aktuellen Webserver-Projekt aktualisiert.
Empfang und Anzeige des JPEG-Bildes auf dem PC mit einem kleinen
selbstgeschriebenen Tool:
-> ca. 6s/Frame (0.17fps) bei JPEG@320x240 color low_compression
Ich dachte es läge an der SoftUART.
Wenn ich aber die Daten nicht übertrage, sondern nur ins Leere laufen
lasse, dann braucht die Schleife mit cam_data_get(a) aber trotzdem noch
ca. 4 Sekunden. Das ist nicht unbedingt das was ich erwartet hatte.
Woran kann das liegen? STK500? SoftUART? Kamera defekt?
Oder ist das Auslesen eines Snapshots immer so langsam?
1) max. sinnvolle Baudrate der SoftUART
Ist vermutlich nicht die Lösung zu obigem Problem, aber welche max.
Baudrate konntet Ihr bei Euch einstellen?
2) Unterschied Preview vs. Snapshot
Ich habe es noch nicht geschafft ein Preview richtig auszulesen.
Wozu braucht man es? Was ist der Unterschied zum Snapshot?
Ich vermute beim Preview wird kein Bild im Speicher der Kamera abgelegt
wie beim Snapshot. Ist der Datenstrom fortlaufend oder nur ein Bild?
Ist die Qualität schlechter? Ist die Übertragung schneller, siehe Punkt
0)?
3) Preview, uncompressed 8Bit gray (kein JPEG!)
Habe ich noch nicht geschafft auszulesen. Der Datenstrom über die
SoftUART ist sehr lang. Zunächst dachte ich, dass fortlaufend Previews
gesendet werden, aber nach etlichen Sekunden ist es vorbei. Ich bastel
mir das was ich empfange in eine PGM-Datei. Manchmal sieht es so aus als
wären dort Bruchstücke eines Bildes drin. Ist die SoftUART zu langsam?
Vielen Dank
Gruß Jörg
Hallo nochmal,
habe es geschafft ein 8Bit Gray Preview 160x120 zu empfangen.
Aber das Empfangen der Daten dauert ca. 17 Sekunden.
Ich übertrage die Daten nicht sofort, um Wechselwirkungen mit der
SoftUART auszuschließen.
Vielmehr speichere ich die Daten zunächst in ein Array[40*30], mache
also eine (einfache) 4-fach Unterabstastung (ich benutze den internen
RAM des ATmega32!). Aber warum frage ich mich, dauert es so lange die
1200Bytes über 921600 Baud zu empfangen?????
Mein Code:
1) Anforderung des Previews
weg, so ist es sehr schnell (ca. 1 s) aber die Daten sind nicht korrekt
(siehe Anhang). Wofür ist dieses nochmalige Anfordern gut?
Ich hoffe, mir kann jemand weiterhelfen.
Anscheinend kann es ja auch anders gehen, wie ich hier im Thread gelesen
habe. Vielen Dank für Eure Hilfe.
Gruß
Jörg
Hallo,
man merkt, dass Herbstferien sind :-)
Ein 160x120 Preview (8Bit Grey) mit cam_data_get() zu holen benötigt
leider immer noch ca. 17 Sekunden. Ich verwende
cam_command_send (0x01,0x01,0x03,0x03,0x03);
Heute konnte ich die Kommunikation der UART auf einem Oszilloskop
verifizieren: es scheinen wirklich 921600Baud zu sein, daran liegt es
also nicht.
@Uli et. al.
Da hier im Forum noch viele Fragen unbeantwortet blieben und auch sonst
im www kein HowTo gefunden habe, wäre es super, wenn jemand folgende
Aussagen bestätigt oder kommentiert:
A) Ein Preview wird nicht im Kameraspeicher abgelegt, sondern sofort
übertragen?
B) Was ist ein uncompressed snapshot picture? Unkomprimiertes JPEG oder
Rohdaten?
C) Unkomprimierte Bilder (Rohdaten, z.B. (Bit Gray) können nur als
Preview übertragen werden? (siehe B)
C) Ein Preview wird nicht als einzelne Pakete gesendet, sondern am
Stück?
D) Ist es möglich, wie in dem C328 User Manual beschrieben, auch bei der
DC-3840 eine Paketgröße mit Kommando
cam_command_send (0x06,0x08,0x00,0x0X,0x00);
anzufordern und dann die einzelnen Paket zu quittieren? Wenn ja, geht
das auch mit unkompressed Daten (z.B. 8Bit Gray)?
E) Die cam_get_data(a) Funktion schaut, ob das angeforderte Byte a
aktuell im Buffer cam_dat_buffer[] vorhanden ist? Wenn a bereits von der
Kamera gesendet worden ist (aber nicht mehr im Buffer vorhanden) oder
noch nicht gesendet wurde, dann wird ein neues Bild angefordert.
F) Warum war in früheren Code-Versionen von Uli CMD_BUFFER_SIZE 16,
aktuell sind 17 eingestellt?
Fragen über Fragen.
Bisher habe ich die Kamera nur ausgeliehen, aber es sollte schon laufen
bevor ich solche Kameras kaufe.
Vielen Dank nochml. Für irgendeine Antwort wäre ich immer dankbar.
Gruß
Hallo
@ Jörg
zu D. Wenn ich es richtig verstanden habe, wird nicht wie bei
der C328 Blockweise übertragen, sondern immer das ganze Bild.
Daraus wird dann je nach Größe des Pufferspeichers ein Teil
herausgegriffen und anschießend versandt. Der Rest der Über-
tragung wird ignoriert.
Also Datenmenge = (Bildgröße / Puffergröße) * Bildgröße
Daher die langen Übertragungsdauern.
Grüße Dirk
Hallo,
so ist es bei meinem SourceCode da ich im AVR leider nicht mehr Speicher
habe. Habe ich natürlich noch externen Speicher oder was ähnliches würde
es auch anders gehen.
Gruß
Uli
Hallo
und vielen Dank für die Antworten.
Das hatte ich vor, morgen mal am Oszilloskop mir anzuschaun, aber ich
hatte schon vermutet, dass das Bild komplett kommt.
@ Uli
Das wußte ich nicht, ich dachte auch auf dem AVR-WebServer hättest Du
mehr als 1 frames per second erreicht.
Dann ist es also davon abhängig, wie schnell man die Daten (Bytes)
ausliest, respektive welches Byte man gerade haben möchte. Falls das
Byte schon von der Kamera gesendet wurde, wird das Bild erneut
angefordert. So, jetzt habe ich es verstanden. Vielen Dank.
@ Uli
Du überträgst dann aber die Daten per HTTP (bzw. in der Testsoftware per
SoftUART), was natürlich langsamer ist. Ich hatte vermutet, dass in
meinem Beispiel, selbst wenn ich die Daten ins Leere laufen lasse
1
for(unsignedlonga=0;a<max_bytes;a++)
2
{
3
test=cam_data_get(a);
4
}
es dann schneller geht, aber hier dauert es trotzdem in etwas so lange.
Kann es sein, dass ich dann zu schnell bin und cam_data_get() auch ein
neues Bild anfordert, wenn dieses betreffende 'a' noch nicht gesendet
wurde? Hier werde ich morgen mal näher hinschaun.
Vielen Dank nochmal
und vielleicht weiß ja noch jemand auf die anderen Fragen Rat.
Grüße an alle
Jörg
Hallo allerseits,
so, viele Nächte sind vorüber...
Es läuft mittlerweile ganz gut.
Die Funktion cam_data_get() gibt es bei mir allerdings nicht mehr.
In der ISR speichere ich nun die einkommenden Daten in 2 Zeilenbuffer
(immer abwechselnd). Im main() kann ich dann auf das fertige
Zeilenbuffer zugreifen, natürlich hat man da nur soviel Zeit wie die
Zeile gültig ist. Das reicht z.Zt. für ein einfaches Downsampling mit
arithm. Mittelwert oder aber auch für 2 einfache Sobel-Kantenoperatoren,
also d/dx bzw. d/dy.
Durch diese Einschränkung (kein externes SRAM, keine 2. UART) schaffe
ich dann allerdings auch das ganze Bild in einem Rutsch zu verarbeiten,
d.h. das was die 921600 kBaud hergeben (
Was mir allerdings noch aufgefallen ist: beim Preview ist die
Belichtungssteurung doch sehr am Schwingen. Habt Ihr das auch
beobachtet?
Das war auch unschön bei der cam_data_get(), da die Helligkeit der
Teilbilder (wenn Daten neu angefordert werden) variiert. Vielleicht war
das auch das Problem bei Marco Bajerski (earlyperl).
Grüße
Jörg
Hi,
sry das ich den alten thread nochmal ausgrabe, aber ich habe Probleme
aus dem Empfangenem ein jpg zu machen. Ich habe die DC-3840 an einen
FT232RL an den USB angeschlossen und die Kommunikation läuft auch super.
Ich weiß bloß nicht, wie ich aus dem Empfangenem ein jpg mache. Kann mir
das jemand alles Schritt für Schritt genau erklären?
Also ich weiß schonmal, dass ich die ersten 16byte entfernen muss, und
das ich das ganze als RAW speichern muss, aber wie bekomme ich die
ersten 16Byte weg? Welche Tasten muss ich klicken :D ? Ich kann das
Hterm einfach nicht bedienen.
mfg, jtag
Hi,
kann mir keiner helfen? Ich bin schon am verzweifeln. Ich will endlich
mal Bilder anschauen können :P , aber ich kanns nicht, weil ich es nicht
richtig abspeichern kann. Wie macht ihr das? Ihr könnt das doch alle als
Bild anschauen, dann wisst ihr auch wie das geht. Bitte erzählt es mir
doch.
mfg
Hi,
ich kam mit HTerm nicht zurecht, aber das war eher ein Problem der
Übertragung selbst. Versuch mal SerialWatcher ...
Noch eine Sache. Ich habe die 16Byte (oder 17?) einfach nicht
übertragen, sondern mir die reinen Bilddaten in einen Buffer
geschrieben. Dann brauchst Du auch nichts ausschneiden...
Gruß
Hi,
"Noch eine Sache. Ich habe die 16Byte (oder 17?) einfach nicht
übertragen, sondern mir die reinen Bilddaten in einen Buffer
geschrieben. Dann brauchst Du auch nichts ausschneiden...
"
Da ich das Ding direkt an den PC angeschlossen habe, kann ich die ersten
16 Byte nicht weglassen. Wie hast du das gemacht, mit welchem Programm?
Hast du selber was programmiert? Ich bin leider nicht in der Lage sowas
selber zu programmieren, dazu fehlen mir die Kenntnisse.
mfg
Hallo,
ich will die Kamera zum laufen bringen. Bevor ich mich an den AVR
ranmache, möchte ich die Kamera am PC auf Funktionstüchtigkeit prüfen.
Da ich hier gelesen habe, dass der ein oder andere bereits ein Programm
in einer Hochsprache verfasst hat, möchte ich fragen und bitten ob sich
dieser bereit erklärt sein Programm oder auch Quelltext, mit mir / uns
zu teilen.
Ich wäre sehr dankbar.
Hallo Karsten,
ist bei mir schon lange her.
Wüßte aber nicht, dass es ein Windows-Programm gibt, was das kann, was
Du willst.
Ich habe ein Tool geschrieben, was per (2.) UART des ATMEL kommuniziert.
Aber das hilft Dir nicht...
Im Prinzip müßte man aber ein Tool schreiben können, was mit der Kamera
direkt spricht...
Grüße
Ja, genau dass ist nötig.
Habe vermutet dass: Matatron
Beitrag "Re: Protokoll DC-3840 Handycam"
und Marco Bajerski Beitrag "Re: Protokoll DC-3840 Handycam"
bereits eine Implementierung vorgenommen haben.
Der Beitrag ist wohl schon zu alt...
Ich danke Dir für Deine Antwort. Mglw. meldet sich noch jemand der eine
winzige selbst geschriebene Anwendung in der Schublade hat.
Hi nochmal,
meine Kamera steht schon fast 1 Jahr auf meinem Werktisch.
Daneben das STK500.
Mich wundert es, dass die Kinder noch nicht an den Kabeln gezogen haben
:-)
Ich hoffe, dass ich irgendwann wieder Zeit habe dafür.
Wenn es Tool gibt, wäre ich natürlich auch interessiert...
Ich habe den Thread in meiner Benachrichtungsliste, d.h. ich bekomme
eine email, wenn es einen neuen Beitrag gibt.
Ansonsten noch schöne Feiertage und einen guten Rutsch!
Grüße
Jörg
Hi nochmal,
hier ist ein kleiner codeschnipsel, mit dem man die empfangenen hex
daten in ein jpg umwandeln kann. Einfach compilieren und dann die hex
datei per drag and drop auf die exe ziehen
Hi,
gibt es auch die moeglichkeit die cam an zwei normale I/O pins zu
haengen .. oder muss es zwingen uart sein .. hab naemlich kein uart :-(
gruesse dominique
Hallo Dominique,
theoretisch könntest Du das vielleicht auch mit einer Soft-UART
hinbekommen.
Ich schätze aber, dass Du so keine 9xx kBit/s hinbekommst.
Ansonsten dauert der Datentransfer halt wirklich lange...
Ich bin mir jetzt nicht sicher, ob es nicht sogar eine Mindest-Rate für
die Cam gibt, oder eine Default-Rate (9xx kBit/s ?), die man dann
runtersetzen kann. Ist schon so lange her...
Grüße
Jörg