ich versuche gerade meinen DIAMEX USB ISP-Programmer für Atmel AVR zum Laufen zu bringen. leider scheitert es beim "Device Signature - Read", "Device Information - Read", "Fuses" und "Lock bits" im Microchip Studio 7 unter Windows 10.
Folgender Aufbau:
Windows 10 64Bit
COM Port 11 (DIAMEX)
Baud Rate 115200 Bits/s
COM Port 5 (Arduino Klon)
DIAMEX zu Arduino
Grüne LED leuchtet konstant
Alle DIP Schalter auf OFF (da ich über USB eine externe Versorgung habe)
Zu einer vollständigen Anschluss-Liste gehört auch ein
Masseanschluss. Übliche Programmieradapter möchten auch
eine Verbindung Vtg (V Target) abgesättigt haben.
Zu einer vollständigen Anschluss-Liste gehört auch ein
Masseanschluss. Übliche Programmieradapter möchten auch
eine Verbindung Vtg (V Target) abgesättigt haben.
Masse habe ich testweise angeschlossen, es erscheinen die gleichen Fehlermeldungen. Außerdem wird im Microchip Studio 7 unter "Taget Voltage" 0V angezeigt. Ohne die Masse-Verbindung werden die korrekten 5V angezeigt.
Was heißt denn testweise? Die muss IMMER angeschlossen sein! Alle 4 IPS-Signale + Masse + VCC müssen angeschlossen sein. Und der IC braucht eine Stromversorgung, wenn der Programmieradapter keine liefert (Standard).
Masse habe ich testweise angeschlossen, es erscheinen die gleichen
Fehlermeldungen. Außerdem wird im Microchip Studio 7 unter "Taget
Voltage" 0V angezeigt. Ohne die Masse-Verbindung werden die korrekten 5V
angezeigt.
Masse "testweise"?
Klingt wie ein Aprilscherz, sorry. Masse ist das erste, was man anschließt.
Wenn dann "Target voltage 0" rauskommt, weißt du mit an Sicherheit grenzender Wahrscheinlichkeit, dass irgendwas mit der Verdrahtung foul ist. Was genau, das musst du nun ermitteln. Kontrolliere nochmal alle Anschlüsse.
Ggf. poste hier Fotos, aus denen die Verbindung von Diamex zu Arduino erkennbar ist.
Masse habe ich testweise angeschlossen, es erscheinen die gleichen
Fehlermeldungen. Außerdem wird im Microchip Studio 7 unter "Taget
Voltage" 0V angezeigt. Ohne die Masse-Verbindung werden die korrekten 5V
angezeigt.
Da stimmt ganz grob was nicht. Zeige ein hochauflösendes Foto
von deinem Aufbau (Controller mit Diamex angeschlossen).
Was heißt denn testweise? Die muss IMMER angeschlossen sein! Alle 4
IPS-Signale + Masse + VCC müssen angeschlossen sein. Und der IC braucht
eine Stromversorgung, wenn der Programmieradapter keine liefert
(Standard).
Miss die Spannung zwischen GND und VCC an deinem IC, dort müssen 3,3-5V
anliegen.
Fehlermeldungen. Außerdem wird im Microchip Studio 7 unter "Taget
Voltage" 0V angezeigt. Ohne die Masse-Verbindung werden die korrekten 5V
angezeigt.
Unsinn. Bist du ein Troll?
In Der Anleitung stand unter "AVR Controller Verbinden" nichts von VCC oder GND. Ich nahm an, dass durch eine externe Spannungsversorgung , in meinem Fall der normale USB Anschluss diese Verbindung überflüssig macht.
Die Fehlermeldungen kann ich anhängen, das hat nix mit Troll zu tun. Aber ich bin ja hier um Hilfe zu suchen, deswegen bin ich ja gerne offen für alles!
Masse habe ich testweise angeschlossen, es erscheinen die gleichen
Fehlermeldungen. Außerdem wird im Microchip Studio 7 unter "Taget
Voltage" 0V angezeigt. Ohne die Masse-Verbindung werden die korrekten 5V
angezeigt.
Masse "testweise"?
Klingt wie ein Aprilscherz, sorry. Masse ist das erste, was man
anschließt.
Wenn dann "Target voltage 0" rauskommt, weißt du mit an Sicherheit
grenzender Wahrscheinlichkeit, dass irgendwas mit der Verdrahtung foul
ist. Was genau, das musst du nun ermitteln. Kontrolliere nochmal alle
Anschlüsse.
Ggf. poste hier Fotos, aus denen die Verbindung von Diamex zu Arduino
erkennbar ist.
Foto hab ich angehängt... hoffe das ist gut genug.
In Der Anleitung stand unter "AVR Controller Verbinden" nichts von VCC
oder GND. Ich nahm an, dass durch eine externe Spannungsversorgung , in
meinem Fall der normale USB Anschluss diese Verbindung überflüssig
macht.
Ist natürlich dahingehend erstmal passend, dass auf diese Weise tatsächlich eine (allerdings störanfällige) GND-Verbindung entsteht.
Eine Verbindung von Vtarget (Versorgungsspannung deines Controllers) zum Programmer entsteht aber damit nicht. Je nach Programmer kann dies nun ein Problem sein oder nicht. Gerade die Atmel-eigenen Programmer erwarten an Pin 2 die tatsächlich am Target benutzte Spannung, weil sie davon die Pegelwandler betreiben für die Signale zwischen Programmer und Target. Wie der Diamex das handhabt, weiß ich gerade nicht, aber die "0 V" klingen danach, als würde er das ebenfalls erwarten.
(Pin 2 bezieht sich dabei auf den von Atmel genormten 6-Pin-Verbinder. Welcher Pin das beim von dir benutzten 10-Pin-Verbinder ist, müsstest du selbst recherchieren.)
Foto hab ich angehängt... hoffe das ist gut genug.
Hmmm. Warum hast du so ein Ding mit 10pol Kabel gekauft? Mit 6 pol wäre es deutlich einfacher, denn das passt direkt auf den Stecker ISCP! Augen auf beim Programmieradapterkauf! Dort ist doch auch ein 6pol Anschluß drauf! Der ist vermutlich der Richtige! Besorg dir ein passendes 6pol Kabel.
Und siehe da, der hat auf dem 6pol Anschluß die Standardbelegung! Plug & Play!
Warum willst du den Arduino mit einem externen Programmieradapter programmieren? Das kann man machen, braucht man aber nicht, wenn man die Arduino-IDE nutzt. Oder hast du den Bootloader gelöscht? Oder willt du nur den Programmieradapter testen?
avrdude.exe: ser_open(): can't open device "\.\COM11": Zugriff
verweigert
Also ist COM11 offenbar falsch oder durch ein anderes Programm belegt. Im Gerätemanager von Windows siehst du die richtige Port Nummer, wenn du das Gerät absteckst und wieder einsteckst, und dabei beobachtest, welches Gerät darauf reagiert.
Die Einstellung der Baudrate (und der anderen Parameter) in Windows ist irrelevant, weil dein Steuerprogramm sich selbst darum kümmert.
Also die richtigen Pins sind angeschlossen, ob alle Verbindungen stimmen müsste man noch prüfen. +5V ist jedenfalls nicht verbunden.
es gibt auch keine zwischengeschalteten Widerstände, wie bei der seriellen Schnittstelle, das hätte noch ein Problem sein können.
avrdude.exe: ser_open(): can't open device "\.\COM11": Zugriff
verweigert
Also ist COM11 offenbar falsch oder durch ein anderes Programm belegt.
Im Gerätemanager von Windows siehst du die richtige Port Nummer, wenn
du das Gerät absteckst und wieder einsteckst, und dabei beobachtest,
welches Gerät darauf reagiert.
Es kann durchaus sein, daß die Schnittstellennummer sogar korrekt ist, aber Reste alter Treiber und Schnittstellenzuweisungen Windows hier gründlich durcheinanderbringen.
Das kann man glücklicherweise entmisten, mit dem "COM Name Arbiter" von Uwe Sieber ist leicht ein sauberer Ausgangszustand wiederhergestellt.
Erstaunlich, daß gut 12 Stunden dauerte, bis jemandem der Zugriff-verweigert-Fehler auffiel, aber offenbar hat der Threadstarter noch viele andere lustige Fehler gesammelt ...
Eine Verbindung von Vtarget (Versorgungsspannung deines Controllers) zum
Programmer entsteht aber damit nicht. Je nach Programmer kann dies nun
ein Problem sein oder nicht. Gerade die Atmel-eigenen Programmer
erwarten an Pin 2 die tatsächlich am Target benutzte Spannung, weil sie
davon die Pegelwandler betreiben für die Signale zwischen Programmer und
Target. Wie der Diamex das handhabt, weiß ich gerade nicht, aber die "0
V" klingen danach, als würde er das ebenfalls erwarten.
(Pin 2 bezieht sich dabei auf den von Atmel genormten 6-Pin-Verbinder.
Welcher Pin das beim von dir benutzten 10-Pin-Verbinder ist, müsstest du
selbst recherchieren.)
Ich hab jetzt kein 6-poliges Kabel da, aber ich werde einfach weiblich-weiblich Steckbrücken hernehmen, solltle ja im Prinzip das gleiche Ergebnis bringen
Und siehe da, der hat auf dem 6pol Anschluß die Standardbelegung! Plug &
Play!
Warum willst du den Arduino mit einem externen Programmieradapter
programmieren? Das kann man machen, braucht man aber nicht, wenn man die
Arduino-IDE nutzt. Oder hast du den Bootloader gelöscht? Oder willt du
nur den Programmieradapter testen?
Korrekt, ich hab noch die Bedienungsanleitung angehängt. Warst leider etwas schneller.
Ich habe leider über eBay gekauft und da gab es nicht das 6 polige Kabel dazu wie im DIAMEX Shop. habe ich übersehen, dachte es wäre dabei... :(
Ich möchte im nächsten Schritt die Atmega328P Chips programmieren, weswegen ich es jetzt erstmal mit einem UNO testen möchte. Wenn das klappt würde ich mich ein Paar Chips bestellen.
Also ist COM11 offenbar falsch oder durch ein anderes Programm belegt.
Im Gerätemanager von Windows siehst du die richtige Port Nummer, wenn
du das Gerät absteckst und wieder einsteckst, und dabei beobachtest,
welches Gerät darauf reagiert.
Die Einstellung der Baudrate (und der anderen Parameter) in Windows ist
irrelevant, weil dein Steuerprogramm sich selbst darum kümmert.
Ich hab jetzt kein 6-poliges Kabel da, aber ich werde einfach
weiblich-weiblich Steckbrücken hernehmen, solltle ja im Prinzip das
gleiche Ergebnis bringen
Sicher. Und funktioniert es jetzt? Hier im Dokument sieht man die Pins uns Signale.
Solange der Port nicht geöffnet werden kann, kannst du dir jede Fummelei an den Kabeln zum AVR und den Avrdude Parametern sparen. Dieses Problem muss zuerst gelöst werden.
Solange der Port nicht geöffnet werden kann, kannst du dir jede Fummelei
an den Kabeln und den Avrdude Parametern sparen. Dieses Problem muss
zuerst gelöst werden.
Microchip Studio erkennt das Ding doch! Das Gefrickel mit avrdude braucht man nicht.
Microchip Studio erkennt das Ding doch! Das Gefrickel mit avrdude
braucht man nicht.
Dennoch funktioniert es auch mit dem Microchip Studio nicht. Ich bin es leider gewohnt, von grafischen Windows Anwendungen irreführende Fehlermeldungen zu erhalten.
Deswegen würde ich erst mal versuchen, den Port mit einem anderen Programm zu öffnen. Wenn ich avrdude nicht vertrauen würde (was nicht zutrifft), dann würde ich zur Probe ein Terminalprogramm versuchen.
"Es hilft, behutsam und ohne viel Aufhebens neutrale Begrifflichkeiten einzuführen – „Controller“ und „Peripherie“ sind schon mal ein brauchbarer Ansatz, weil sie keinen Bezug auf Menschen und unrühmliche Ereignisse nehmen. Allzu lautes Säbelrasseln jedoch wird nur wieder jene Kleingeister auf den Plan rufen, die bei Facebook „Teile diesen Negerkuss, um linksgrünversiffte Gutmenschen zu ärgern!“ posten. "
In der Tat! Ich wär dabei (als alter, weißer, CIS-Mann) ;-)
Also nach der Anleitung zu folge ist die Belegung anders. Siehe
beigefügten Ausschnitt.
Du scheinst noch nicht verstanden zu haben dass man auf
Steckverbinder von oben oder von unten draufschauen kann und
dadurch je nach Sichtweise ein ganz anderes Bild der Pin-
zuordnung entstehen kann.
Übliche Steckverbinder werden in Dokumentationen "von oben"
dargestellt, heisst eine Stiftleiste betrachtet man wie sie
von obem auf der Platine zu sehen ist. Das Gegenstück der
Stiftleiste (der Buchsenkörper) weist naturgemäss eine
"andere" Pinzuordnung auf.
Deine Verschaltung erzeugt einen Kurzschluss zwischen VCC-Pin vom Diamex und dem Gnd vom Arduino, überkreuzt MOSI und MISO und versorgt den Arduino nicht mit dem SPI-Clock vom Diamex. Das solltest du erstmal beheben und dabei hoffen, dass sowohl der Programmer als auch der Arduino das alles überlebt haben.
Was hast du aktuell als Bootloader auf dem Arduino Board?
Du scheinst noch nicht verstanden zu haben dass man auf
Steckverbinder von oben oder von unten draufschauen kann und
dadurch je nach Sichtweise ein ganz anderes Bild der Pin-
zuordnung entstehen kann.
Der Pin 1 am Stecker vom 10-pol Kabel ist normalerweise nun wirklich eindeutig und unverwechselbar mit dem Dreieck gekennzeichnet. Da gibt es wenig Spielraum für Diskussionen?
Ich hab jetzt kein 6-poliges Kabel da, aber ich werde einfach
weiblich-weiblich Steckbrücken hernehmen, solltle ja im Prinzip das
gleiche Ergebnis bringen
Sicher. Und funktioniert es jetzt? Hier im Dokument sieht man die Pins
uns Signale.
Super funktioniert!!!! Vielen Dank an Alle!!! Der Spruch "Augen auf beim Programmer Kauf" hat sich wohl wieder bewahrheitet!
Mit dem 6poligen Anschluss kann ich nun auf den China Klon zugreifen.
Witzigerweise wird der billige China Klon (wahrscheinlich ein LGT8F328P) als Atmega328P erkannt, aber ein Funduino (Arduino kompatibel) mit einem richtigen ATMEGA328P U Chip drauf als ATmega16U2 erkannt. Was soll man davon halten??
Witzigerweise wird der billige China Klon (wahrscheinlich ein LGT8F328P)
als Atmega328P erkannt, aber ein Funduino (Arduino kompatibel) mit einem
richtigen ATMEGA328P U Chip drauf als ATmega16U2 erkannt. Was soll man
davon halten??
Daß du beim 2. den falschen ISP-Stecker erwischt hast. Denn dort sind 2 drauf, einer für den "richtigen" AVR, der als Arduino arbeitet und einer für den "unsichtbaren" AVR, der nur als USB-UART Wandler arbeitet.
Ich korrigiere meine Aussage, am Arduino sind die richtigen Pins verdrahtet, aber am Diamex-Stecker spiegelverkehrt.
Zusätzlich sind MOSI/MISO gekreuzt, daher muss auch noch weiß mit grün gekreuzt werden.
Diese Bezeichnungen sind immer etwas verwirrend.
Wenn man am SPI "Rx/Tx" oder "Data-in/Data-out" schreibt, müssen die über Kreuz verbunden werden, auf beiden Seiten Data-out raus und Data-in rein.
Die Bezeichnungen MOSI und MISO sind nicht eindeutig, es kommt darauf an, ob der Arduino und der Programmer als Master oder Slave geschaltet sind. Diamex hat sie so bezeichnet, dass identische Namen verbunden werden, oder wie ein Kollege gern sagte "Pin auf Pin - das haut hin".
Die Bezeichnungen MOSI und MISO sind nicht eindeutig, es kommt darauf
an, ob der Arduino und der Programmer als Master oder Slave geschaltet
sind.
Für mich klar, dass der Programmieradapter der Master ist, und dass diese Pins immer 1:1 miteinander verbunden werden müssen (egal wer jetzt der Master ist).
Diamex hat sie so bezeichnet, dass identische Namen
verbunden werden
So ist es richtig. Verwechsele das bitte nicht UART Schnittstellen, die über Kreuz verbunden werden.
Witzigerweise wird der billige China Klon (wahrscheinlich ein LGT8F328P)
als Atmega328P erkannt, aber ein Funduino (Arduino kompatibel) mit einem
richtigen ATMEGA328P U Chip drauf als ATmega16U2 erkannt. Was soll man
davon halten??
Daß du beim 2. den falschen ISP-Stecker erwischt hast. Denn dort sind 2
drauf, einer für den "richtigen" AVR, der als Arduino arbeitet und einer
für den "unsichtbaren" AVR, der nur als USB-UART Wandler arbeitet.
Stimmt, da ist noch ein kleinerer ATMEGA16U2 auf dem Board... deswegen hat er auch zwei ICSP Anschlüsse, hab mich schon gewundert.
Was ist daran verwirrend?
Master/Controller ist bei SPI derjenige, der den Takt ausgibt. Damit ist klar, wer auf COPI und CIPO der Sender ist.
Besser als "RX" und "TX", wo nie klar ist, ob das aus der Sicht des Datenverbindung oder aus Sicht des Gerätes bezeichnet ist. Und ganz spaßig wird es mit TX/RX bei bidirektionalen Signalen (z.B.RS485 Bus)
Stimmt, da ist noch ein kleinerer ATMEGA16U2 auf dem Board... deswegen
hat er auch zwei ICSP Anschlüsse, hab mich schon gewundert.
Wenn du den jetzt umprogrammiert hast, ist dein USB-UART Adapter auf dem Board, weil das nämlich die Aufgabe dieses Chips ist. Die Firmware müsste irgendwo im Arduino Verzeichnis liegen, falls du sie mit deinem ISP Adapter wieder herstellen willst.
Stimmt, da ist noch ein kleinerer ATMEGA16U2 auf dem Board... deswegen
hat er auch zwei ICSP Anschlüsse, hab mich schon gewundert.
Wenn du den jetzt umprogrammiert hast, ist dein USB-UART Adapter auf dem
Board, weil das nämlich die Aufgabe dieses Chips ist. Die Firmware
müsste irgendwo im Arduino Verzeichnis liegen, falls du sie mit deinem
ISP Adapter wieder herstellen willst.
Ich hab nichts programmiert, nur immer "READ" gewählt.
Irgendwie krieg ich's nicht gebacken.
der ATMEGA328P vom China-Klon ist lesbar, aber beim Funduino (Arduino Kompatibel) kann ich den ATMEGA16U2 auslesen, aber beim Atmega328P kommen wieder Fehlermeldungen. Obwohl ich gleiche PIN-Belegung übernommen habe.
Kann da ein Defekt vorliegen, oder ein Schreibschutz drauf sein?
Kann da ein Defekt vorliegen, oder ein Schreibschutz drauf sein?
Unwahrscheinlich. Das Board aber schon eine externe Stromversorgung (bzw. via USB), oder etwa nicht?
Wobei... wegen deinem vorherigen Kurzschluss ist genau der Teil jetzt vielleicht kaputt. Messe mal am ISP Stecker nach, hat der AVR noch 5V? Kontrolliere auch die Reset Leitung, die sollte im Ruhezustand ebenfalls 5V haben.
Kann da ein Defekt vorliegen, oder ein Schreibschutz drauf sein?
Unwahrscheinlich. Das Board aber schon eine externe Stromversorgung
(bzw. via USB), oder etwa nicht?
Korrekt!
Wobei... wegen deinem vorherigen Kurzschluss ist genau der Teil jetzt
vielleicht kaputt. Messe mal am ISP Stecker nach, hat der AVR noch 5V?
Kontrolliere auch die Reset Leitung, die sollte im Ruhezustand ebenfalls
5V haben.
Kann nicht sein, ersens hab ich keinen Kurzschluss verursacht, da ich die PINS gar nicht genutzt habe noch falsch gesteckt habe. Außerdem habe ich die ersten Versuche mit dem China-Klon gemacht, dass ja funktioniert. Das Arduino Kompatible Board habe ich jetzt zum Schluss angesteckt.
Nichtsdestotrotz messe ich mal nach, ob ich einen Kurzschluss verursacht habe. Wäre ja nicht das erste mal ;)
Nachtrag:
Der Fehler ist gefunden, ich hab den IC das letzte mal falsch rum eingesetzt. Jaja, ich kann euer Lachen hören... Man muss halt immer vom DAU ausgehen und das habe ich in meinem Fall auch gemacht, selbst wenn man es selbst ist, ne?
Super! Ich bin zufrieden! Ziel für dieses WE erreicht. Danke für die zahlreiche Hilfe. Bin ich sehr begeistert von, vorallem kein Unterbuttern sondern konstruktiv.
Kann nicht sein, ersens hab ich keinen Kurzschluss verursacht
Warum sollte die Spannung sonst zusammengebrochen sein?
Dein Foto zeigt eine Verbindung von VCC des Diamex mit Gnd des Arduino.
Je nach Schalterstellung kann das wahrscheinlich durchaus zu einem Kurzschluss führen.
Masse habe ich testweise angeschlossen, es erscheinen die gleichen
Fehlermeldungen. Außerdem wird im Microchip Studio 7 unter "Taget
Voltage" 0V angezeigt.
„Controller“ und „Peripherie“
Die Bezeichnungen helfen auch nicht weiter wie Master/Slave, Datenendeinrichtung/Datenübertragungseinrichtung (RS232) oder Host/Device (USB).
Bei RS232 war die Bezeichnung für ein Telefonmodem am Computer noch klar. Wenn man aber eine Drucker seriell anschloss war der plötzlich das Endgerät, in dem die Daten verschwanden.
Dafür hat die Adapterindustrie das Nullmodem erfunden, und um sicherzugehen noch den Zwischenstecker mit mehreren LED zur Kontrolle.
Dann ersetzte IBM irgendwann den DSub25 durch DSub9, wieder ein Geldsegen für die Adapter/Kabelhersteller. Von den Variationsmöglichkeiten der verbliebenen fünf Handshakeleitungen nicht zu reden, RTS CTS DSR DTR RI.
Den parallelen Druckerport hatte man ebenfalls mit DSub25 "genormt". Um Verwechslungen zu vermeiden eine Buchse im PC statt Stiften.
Was einen Kollegen nicht hinderte, einen Dongle auf den falschen Port zu stecken. Der Softwarelieferant ließ sich wenigstens überzeugen, nur einen neuen Dongle zu berechnen, statt die ganze Software.
Beim USB-Bus versuchte man durch unterschiedliche Stecker Typ A/B die Verwirrung zu verhindern.
Und so hat heute ein Oszilloskop eben zwei USB-Anschlüsse unterschiedlichen Typs, zum Drucker und zum PC hin.
Und so hat heute ein Oszilloskop eben zwei USB-Anschlüsse
unterschiedlichen Typs, zum Drucker und zum PC hin.
Es dürfte nicht mehrl allzulange dauern, bis das nicht mehr der Fall ist, und USB-C auch in Oszilloskopen auftaucht. Die werden dann aber selbst rausfinden können, was angeschlossen ist, ein USB-Host oder ein USB-Device.
Das schaffen andere Geräte mit USB-C auch schon, ja, das ging sogar schon zu Zeiten der lausigen Micro-USB-Stecker, aus der Zeit nämlich stammt USB OTG.
Ich sehe das in mehrfacher Hinsicht als großen Fortschritt gegenüber den vielen Interpretationen von RS-232 an, die oft auch auf schierem Nichtwissen seitens der Anwender, aber auch der Gerätehersteller selbst ruhten.
Denn leider haben es auch viele Hersteller nicht hinbekommen, Stecker und Buchsen auf die richtige Art und Weise (DCE und DTE) zu verwenden, sondern haben nur zu oft ihre eigenen wirren "Werksstandards" entwickelt, für die man dann entweder einen "Gender-Changer" (darf man das heute eigentlich noch sagen?) oder gar ein individuell angefertigtes Adapterkabel brauchte. Das hübscheste, dem ich mal begegnete, war eine an sich korrekt belegter DTE-Buchse, aber mit vertauschtem Rx/Tx.
Das sollte auch nur Mirkos Verdrahtungsfehler relativieren, das passiert schon seit vielen Jahren immer wieder.
Steckverbinder von oben oder von unten draufschauen
Einen Flachkabelstecker kann man in vier Richtungen auf ein (farbmarkiertes) Flachkabel aufcrimpen, nur eine stimmt. Zwei sind spiegelverkehrt und einer hat den Kabelabgang nach der falschen Seite.
Wenn dann noch der Steckerhersteller die Nase weggelassen hat, kann man den beliebig oft wieder falsch aufstecken. Das Dreieck für Pin1 fehlt auch gerne mal aus Rationalisierungsgründen. shit happens!
USB OTG
ja der Fortschritt wurde damals gepriesen. Endlich kann der Fotoapparat direkt auf den Drucker drucken, ohne PC dazwischen.
USB OTG
ja der Fortschritt wurde damals gepriesen. Endlich kann der Fotoapparat
direkt auf den Drucker drucken, ohne PC dazwischen.
Ja toll...
Ich habe noch so einen Drucker (weil: letzte Generation mit nicht verdongelten Tintenpatronen), konkret Canon i560x.
Die PC-lose Funktionalität konnte man aber wirklich voll in der Pfeife rauchen.
Zum einen kam nach Einstöpseln des Mediums erstmal zwingend ein (oder mehrere bis viele) Blätter mit Thumbs raus. Die einzelnen Thumbs natürlich viel zu klein, um bei mehrfach aufgenommenen Motiven zu entscheiden, welches man davon tatsächlich drucken will. Also völlig nutzlos, aber: schonmal ordentlich Tinte verbraucht...
Und dann der eigentliche Bilddruck: keinerlei Eingriffsmöglichkeiten. Bedruckt wird immer eine möglichst große Fläche des Papiers. Es wird immer das Bild-Ratio gewählt, was dieses Primärziel sicher stellt. Wenn also das Ziel das (unveränderlich standardmäßig gesetzte) A4-Papier ist und das Bild im 16:9-Querformat aufgenommen ist, wird das Bild um 90° gedreht. EXIF-Information zur Aufnahmelage? Völlig unwichtig, Hauptsache: ordentlich Tinte verbraucht...
Nun, man braucht sich wohl nicht zu wundern, dass diese Scheiße sich nicht so richtig durchsetzen konnte...
Geraetemanager.PNG
(13 KB)
Device_Programming.PNG
(7,2 KB)
Device_Programming_-_Applied.PNG
(17 KB)
Device_Signature_-_Failure.PNG
(29 KB)
Device_Information_-_Failure.PNG
(29 KB)
Fuses_-_Failure.PNG
(45 KB)
Lock_bits_-_Failure.PNG
(42 KB)
