|
Anzeige
|
UpdateLoader: Benutzeroberfläche für FastBoot AVR-Bootloader
Gast
#3398190
Für den AVR Bootloader FastBoot von Peter Dannegger, Version 2.1 Das Programm ist komplett in Free Pascel (Lazarus) erstellt, die Quelltexte und eine kleine Anleitung sind im Archiv enthalten. Viel Spaß damit!
Angehängte Dateien:
Gast
#3443076
Neue Version 2.2.3: - Verbesserter Verbindungsaufbau, synchronisiert stabiler - Unterstützung für kleine Sendepuffer, z.B. Attiny, Minimum 8 Byte - Fehlerkorrektur am Einlesepuffer (Dateilänge wurde falsch gezählt) Ältere Versionen (ab 2.2.0 von 2012) gibt es auf meiner Seite: http://www.leo-andres.de/2012/09/updateloader-benutzeroberflache-fur-avr-bootloader/ Wie immer viel Spaß damit, ich freue mich über Rückmeldungen!
Gast
#3655640
Neue Version 2.2.4: - Vollständige Anzeige langer Port-Bezeichnung (z.B. Bluetooth) - Konfiguration speichert die tatsächliche Port-Nummer - Längere Timeouts für langsame Adapter Mit dieser Version läuft das Update auch über ein RN42 Bluetooth UART Modul fehlerfrei durch (ATmega238/16MHz, Windows 7). Hallo Leo, ich nutze PEDAs bootloader schon länger und hab mich über die begrenzungen des Command-Line-Tools geärgert. Also max. Com4 und kurze Verzeichnisse. Mit deinem Tool klappt das Flashen hervorragend. Danke! Als Hardware nutze ich den Arduino Nano (... clone mit FTDI Chip). VG! Sebastian Danke Leo für das nützliche Tool. Nur so an Rande: Hunderte laden das Tool runter und nur eine Handvoll findet es nötig sich für die kostenlose Software zu bedanken. Genau diese Erfahrung mache ich auch mit meinen Freeware Programmen. Nun habe ich mich lange genug über die Ignoranz und Oberflächlichkeit der Leute geärgert und werde in Zukunkt Gegenmassnahmen ergreifen. Dazu kann ich nur Empfehlen: http://www.enigmaprotector.com/ , habe ich inzwischen gekauft, koster zwar paar Euro, aber damit hat das Ärgern demnächst ein Ende. Dir wünsche ich noch schöne Ostertage! Gruss Ulrich Albert
Gast
#4078452
Wer an die Reaktionen seiner Freeware-Anwender Ansprüche stellt und diese dann nicht eingelöst werden soll seine Software kostenpflichtig machen. So hat der Autor was von- und der interessierte Anwender bleibt nicht mit dem ohnmächtigen Gefühl zurück, vor lauter Dankbarkeit für den geschenkten Gaul nichts erwarten/einfordern/kritisieren zu dürfen. Albert M. schrieb: > Nur so an Rande: > Hunderte laden das Tool runter und nur eine Handvoll findet es nötig > sich für die kostenlose Software zu bedanken. von den Hunderten verwenden es aber auch nur ein paar. Sehr viele Downloads schaut man sich kurz an und löscht sie gleich wieder weil sie einem nicht taugen Und ansonsten: wer seine Software nicht verschenken will muss sie einfach verkaufen
Gast
#4080061
Als Softwerker ist fühlt man sich mit seiner (aufwendigen) Software natürlich allzu schnell als Nabel der Welt. Da wird dann jeder einzelne Download ohne Rückmeldung schnell zum (undankbaren) Anwender. Wie eine Software wie der Enigmaprotector diese vermeintliche "Ignoranz und Oberflächlichkeit" bekämpfen soll bleibt für mich ein Geheimnis.
Gast
#4080127
Max schrieb: > Wie eine Software wie der Enigmaprotector diese vermeintliche "Ignoranz > und Oberflächlichkeit" bekämpfen soll bleibt für mich ein Geheimnis. Da hilft Nachdenken
Gast
#4080157
memo schrieb: > Da hilft Nachdenken Dann klär mal auf
Gast
#4080386
Albert M. schrieb: > Nur so an Rande: > Hunderte laden das Tool runter und nur eine Handvoll findet es nötig > sich für die kostenlose Software zu bedanken. Mist, ich nutze Linux. Muss ich jetzt Millionen Dankes-Mails schreiben an jeden, der zu dem ganzen OpenSource- und Freewaresystem beigetragen hat, welches es mir erspart, mich mit Windows rumzuärgern? Selten so einen Blödsinn gelesen.
Gast
#4080605
Andreas schrieb: > Mist, ich nutze Linux. > Muss ich jetzt Millionen Dankes-Mails schreiben an jeden, der zu dem > ganzen OpenSource- und Freewaresystem beigetragen hat, welches es mir > erspart, mich mit Windows rumzuärgern? > Selten so einen Blödsinn gelesen. Du gehörst genau zu den Ignoranten und Oberflächlichen die oben gemeint waren. Der Lohn der prof. Softwerker ist harte Währung für ihr Produkt und der Lohn der Freeware Ersteller Anerkennung, Zuspruch und Diskussion. Wer das nicht versteht, gehört auch genau zu der Gruppe die am lautesten aufheult, wenn die Freeware plötzlich nur noch gegen Euro zu haben ist, weil der Freewerker irgendwann von der Ignoranz die Nase voll hat. Aber Du brüstest Dich ja mit Deinem Linux und erwartest das andere für Dich für immer für lau arbeiten. Arbeitest Du umsonst? Nein? Dann solltest Du wenigsten die Arbeit derer Anerkennen dies dies für Dich machen. Und genau dies ist Deiner gedankenlosen Antwort oben nicht im geringsten anzumerken.
Gast
#4080622
memo schrieb: > und der Lohn der Freeware Ersteller Anerkennung, Zuspruch und > Diskussion. Darauf besteht Null Anspruch, hör doch auf zu jammern. Der Lohn ist zunächst mal weitestmögliche Verbreitung, sofern denn das Programm was taugt. Daraus lässt sich dann immer noch dieser oder jener Nutzen ziehen. > am lautesten aufheult, wenn die Freeware plötzlich nur noch gegen Euro > zu haben ist Das wird erstens nicht passieren und zweitens heult auch keiner wegen käuflicher Software- ist doch klar daß niemand seine Arbeit für lau anbieten muß. Wenn es doch getan wird dann gibts dafür nach wie vor genügend Gründe, z.B. s.o.
Gast
#4103873
Hallo, ich finde der "UpdateLoader" ist wirklich tolle Sache. Ebenfalls wie "PD bootloader" - vielen Dank dafür! Habe nun eine Frage: wird bei "UpdateLoader" auch Atmega64 unterstützt? Und zwar ich programmiere mein Gerät mit fboot von PD ohne Probleme (aus Kommandozeile) Wenn ich mit dem "UpdateLoader" versuche dann kommt Meldung "Unbekannte Signatur..." obwohl die angezeigte Signatur 1E9602 dem Atmega64 gehört. Wenn ich trotzdem fortfahre dann wird Chip zwar programmiert aber bootloader ist weg. Was mache ich falsch?
Gast
#4103927
Wie ist eigentlich der Ablauf beim Programmieren? Programmiervorgang starten und dann am Controller Reset drücken? Oder umgekehrt? Lässt sich das Reset drücken irgendwie einsparen? Markus
Gast
#4104298
Hallo Markus, ein Bootloader, wie Fastboot 2.9, ist nach einem Reset nur kurze Zeit 1/3s aktiv, dann übergibt er an das Userprogramm. Wie sollte man eine Reset einsparen können, wenn das Userprogramm läuft? Idee gab es, man hört immer im Userprogramm auf eine serielle Befehlsfolge und springt dann den Bootloader an.
Gast
#4105850
Hallo, erstmal vorweg: Natürlich erwarte ich keine Dankes-Mail nach jedem Download. In meiner Umgebung läuft das Programm gut, deswegen kann ich es ohne Fehlermeldungen oder Vorschläge von anderen Benutzern nicht verbessern. Auch wird der UpdateLoader bestimmt nicht "verdongelt". Das wäre gegenüber Peter Dannegger unfair, ohne seinen freien Bootloader gäbe es das Programm überhaupt nicht. Dim schrieb: > Meldung "Unbekannte Signatur..." [...] bootloader ist weg Die Signatur ist im UL noch nicht hinterlegt. Die Flash-Größe usw. wird direkt vom Bootloader abgefragt, abgesehen von der Meldung sollte das also kein Problem sein. Wird der Bootloader tatsächlich überschrieben? Das sollte nicht passieren, hast du mal den Flash ausgelesen und nachgesehen was da genau passiert? Markus schrieb: > Programmiervorgang starten und dann am Controller Reset drücken? Genau so. Falls der UL zu schnell abbricht kannst du im Erweitert-Reiter die Anzahl Verbindungversuche erhöhen.
Gast
#4115062
Leo-andres H. schrieb: > Mit dieser Version läuft das Update auch über ein RN42 Bluetooth UART > Modul fehlerfrei durch (ATmega238/16MHz, Windows 7). Also mit einem Mega88 bei 8Mhz (wegen 3V) via RN42 habe ich mir heute die Zähne ausgebissen. Der gleiche Controller mit natürlich identischem FastBoot und gleichen RX/TX Pins, 5V Versorgung, direkt an der seriellen Schnittstelle angesteuert- kein Problem, das läuft bestens! Das RN42 ist an 4 Pins (GND,VCC,RXD,TXD) an den Controller angebunden. Die Baudrate habe ich sowohl mit 115000 als auch 9600 an Modul + entsprechende Programmeinstellung probiert- nichts zu machen. Daß die Übertragung via BT selbst funktioniert sehe ich an der RXTX Daten-LED. Leuchtet diese (Phase: Gerät einschalten) bewirkt der sicher funktionierende Reset-Taster aber leider: Nichts. Dann Abbruch über Timeout.
Gast
#4115090
So, Beitrag geschenkt- eine winzige Lötbrücke war schuld :-(( Ok, dann nutze ich die Gelegenheit mich herzlich für das Programm zu bedanken! So ein drahtloses Fernupdate ist wirklich eine tolle Sache!
Gast
#4161714
Hallo Leo, für eine Firmware bei der ein Kommando Interpreter implementiert ist währe es eine feine Sache, wenn vorab ein String gesendet werden würde. Der Interpreter erkennt die Aufforderung zum flashen und erzeugt einen Reset. Kein unnötiges rumfummeln am HW-Reset, alles geht in einem Flutsch. Unter "Bootloader-Passwort" ein Feld mit "Firmware-Passwort" mit Häkchenkästchen hinten drann ? btw. besten Dank an alle Entwickler, feine Sache. Gruß Holger...
Gast
#4161981
ähmm... ich noch mal, evt. mit einstellbarer Stringterminierung ? BIG :-) . Gruß Holger...
Gast
#4322036
Hi, seit heute gibt es eine neue Version: http://luani.de/blog/news/updateloader-2-2-5-release/ Zum Testen hatte ich nur einen ATmega8 hier, deswegen bin ich jetzt mal ganz besonders auf die Berichte gespannt :) Danke Leo. Ich hoffe sie mindert etwas die häufigen Portfehler bei der Kontaktierung via Bluetooth.
Gast
#4324209
Was meinst du genau mit Portfehler? Kannst du den Port nicht auswählen, öffnen, oder bricht die Verbindung ab? Schick mir bitte mal die genaue Meldung, vielleicht kann ich das nachstellen (hab ein RN42 Modul hier). Schickt dein Controller Daten während dem Verbindungsaufbau? Danke Leo schrieb: > Was meinst du genau mit Portfehler? Siehe angehängte Meldung error1.jpg. Der Fehler tritt recht willkürlich, unvorhersehbar und leider immer noch recht häufig unter V2.2.5 auf. Konkurrierende Programme um den Port gibt es keine. Mein Controller (M88) ist ganz normal mit Peter Danneggers Fastboot bestückt (über nur dafür verwendeten Portpins PD3/4, auf denen keine weitere Kommunikation stattfindet). Via direkter serieller Anbindung gibt es keine Probleme, nur mit RN42-BT. Wie schaut es eigentlich mit der Möglichkeit der Programm"installation" im normal vorgesehenen C- Programmverzeichnis aus? Leider gibt es beim Aufruf von hier (offensichtlich die berüchtigten Rechte-) Probleme, siehe error2.jpg. Ansonsten möchte ich hier noch loswerden, daß mir das Programm auch mit den jetzigen BT-Unzulänglichkeiten von allergrößtem Nutzen für die drahtlose Firmwareprogrammierung meiner oft recht unzugänglichen AVR-Gerätschaften ist! Leider arbeitet der Bootloader nicht mit den Xmegas, aber man kann eben nicht alles haben ;-)
Angehängte Dateien:
Gast
#4325954
Danke, das hilft mir weiter! Die Meldung von error1 bekomme ich nur wenn das Bluetooth Modul nicht in Reichweite ist, bzw. wird die Meldung "Semaphore..." von Windows oder dem Bluetooth Treiber erzeugt und nur angezeigt. Kannst du z.B. mit hterm oder Putty den Port immer zuverlässig öffnen? Könntest du einen anderen Bluetooth Stick testen? Das Programm gibt es bewusst ohne Installer, ist eine Vorliebe von mir. Der error2 wird tatsächlich durch die fehlenden Schreibrechte verursacht, mein Programm hält sich da nicht an die Vorgabe von MS. Du könntest das Programm mit einem Pfad für die Konfiguration aufrufen, z.B. per Verknüpfung oder Batch. "C:\Programm\updater.exe D:\meineKonfig.ini" Beim Beenden werden die Einstellungen dann auch in D:\meineKonfig.ini zurückgeschrieben, das sollte zulässig sein. http://luani.de/projekte/updateloader/#kommandozeilen-parameter MSDN empfiehlt ab Vista(?) die Konfiguration unter %User/AppData/Roaming zu versenken. Das könnte ich so machen und müsste dann auch eine Konfigurations-Verwaltung einbauen. Bisher lege ich mir in jedes Projekt eine Updater.exe + passende Konfiguration rein. Das funktioniert dann nicht mehr so einfach. Vorschläge dazu? Leo-andres H. schrieb: > Die Meldung von error1 bekomme ich nur wenn das Bluetooth Modul nicht in > Reichweite ist, Reichweite ist hier bei mir kein Thema, das sporadische Funktionieren/Nichtfunktionieren des Updatens tritt auch in 1m Entfernung auf. > Kannst du z.B. mit hterm oder Putty den Port immer zuverlässig öffnen? Nein. Ist auch unzuverlässig! > Könntest du einen anderen Bluetooth Stick testen? Mit einem anderen Notebook inklusive Atheros-BT (statt meines Dell mit 1702er BT) das gleiche Bild. Offensichtlich also ein grundsätzliches Problem mit den seriellen BT Ports ?! Gibt es da noch irgend eine Einstellung an der man drehen kann? > Das Programm gibt es bewusst ohne Installer, > Du könntest das Programm mit einem Pfad für die Konfiguration aufrufen Von einer anderen Location als von C aus funktioniert das Programm problemlos, danke, das langt mir.
Gast
#4328704
Moby A. schrieb: > Offensichtlich also ein grundsätzliches Problem mit den seriellen BT > Ports ?! Vermutlich, ja. Google liefert dazu auch nur die üblichen Verdächtigen, Treiberupdate, Reset, anderer Port usw. Ich habe hier ein Notebook mit Intel BT und einen Asus USB-BT211 mit Atheros Chipsatz, das läuft gut. Wie hast du das RN42 konfiguriert? Bei mir läuft: SA,2 (SSP “just works” mode) SQ,16 (16 This option configures the firmware to optimize for low latency) S~,3 (MDM SPP With modem control signals) Firmware ist die 4.7xxx Leo-andres H. schrieb: > Wie hast du das RN42 konfiguriert? Gar nicht. So wie geliefert angeschlossen, allenfalls extern noch auf 9600Baud gezogen. Für weitere Konfigurationen müsste ich noch eine Software-UART implementieren, dafür und für weitere Versuche ist mir angesichts der vorhandenen Erfolgsrate die Zeit zu schade (und auch der Flash der Controller ;-) Ich bilde mir aber ein, seitdem ich testweise eine weitere, permanente serielle BT(M222) Verbindung stillgelegt habe ist die Erfolgsrate signifikant gestiegen. Es gibt noch einigen Funkverkehr mehr im Raum- vielleicht beeinträchtigt der ja den BT-Funk. Sei es wie es sei, danke für Deine Rückmeldungen. Am Programm selber scheints wohl nicht zu liegen. Mit mehr als ca. 560 Bytes tritt nun leider bei der Übertragung via BT/RN42 reproduzierbar der Fehler siehe Bild auf.
Angehängte Dateien:
Gast
#4347540
Hallo Leo, habs erst jetz mitbekommen dass Du Dich nochmals drangesetzt hast und habs sofort mit dem ausprobiert, was ich gerade zur Hand habe. Mit einem BT HC-06 Modul funktioniert Dein UpdateLoader bei mir nicht. Habe die Zeit im Bootloader auf 2s hochgesetzt, um den Verbindungsaufbau vom System (XP) zum Modul zu gewährleisten. Folgendes passiert, egal ob die Hardware reseted wurde oder nicht: nach ca. 1s signalisiert die StatusLED vom BT-Modul: connect. Anschliessend kommt vom UpdateLoader die Fehlermeldung: Unzul?ssige Funktion, COM-Port konnte nicht geöffnet werden..... Solange diese Melung dargestellt wird ist aber laut StatusLED vom HC-06 die Verbindung hergestellt. Nach betätigen des Button "OK" kommt die Meldung: Communication error 1: Unzulässige Funktion.., die Verbindung zum HC-06 wird unter brochen, die StatusLED blinkt wieder. Werde morgen alles mit einem USB-TTL Konverter testen, mit dem hats bei mir ja funktioniert. Btw. mit dem Uploader: "AVRFlash21" funktioniert der Upload über HC-06 problemlos. Gruß Holger... HolgerS schrieb: > mit dem Uploader: "AVRFlash21" funktioniert der Upload über HC-06 > problemlos Das gilt auch für mein (auf 9600 Baud festgelegtes) RN42 Modul ! Der Flashvorgang dauert aber deutlich länger, unabhängig jedweder Baudraten- Einstellung im Programm. Möglicherweise überlastet ja beim UpdateLoader die größerer Datenmenge (pro Zeiteinheit?) irgendwie mein "langsam" konfiguriertes RN42? Die viel höhere Geschwindigkeit ist genauso unabhängig davon, was man nun just als Baudrate einstellt. Leo-andres H. schrieb: > Mit dieser Version läuft das Update auch über ein RN42 Bluetooth UART > Modul fehlerfrei durch (ATmega238/16MHz, Windows 7). D.h. es existiert (ab V2.2.4) irgend eine neue Anpassung an BT-Übertragung? Darin scheint dann wohl der Wurm zu stecken- denn die drahtgebundene Übertragung (auch über USB-Interface) läuft weiterhin bestens.
Gast
#4352762
Hallo Leo, mit einem USB-V24 Konverter laufen beide Modi auf meinem XP System. Win7 check ich morgen (auch hier funktioniert BT nicht). Gruß Holger...
Gast
#4353295
gerade mit Win7 und USB-V24 Konverter getestet. Zunächt war der USB-V24 Konverter auf COM-Port#15. Gleiche Fehlermeldung wie bei Moby AVR vom 08.11 ! Es kommt gar keine Verbindung zustande. AVRFlash21 funktioniert bei mir auf Com-Port#15 auch nicht. USB-V24 Konverter auf COM-Port#1 gesetzt und der Progvorgang wurde zumindest gestartet, bricht dann aber ab. Gruß Holger...
Angehängte Dateien:
Gast
#4354256
ok, nochmal ich zur Anmerkung: unter XP funktioniert der USB-V24 Konverter bei mir mindestens auf COM-Port#14. Meine Zusammenfassung: XP: kein BT, USB-V24 klaglos. Win7: kein BT, USB-V24 nur in den unteren Rängen. Hey Leo, der Weihnachtsurlaub, indem man Dinge aufarbeiten kann, rückt immer näher ;-) . ääähm, bitte keine X kiB sondern X kB. Beste Grüße Holger...
Gast
#4355266
Hmm da muss ich mal in die SynaSer Bibliothek schauen, die öffnet letztlich den Port und wirft die Fehler. Werden denn die Ports korrekt aufgelistet oder sind die Namen abgeschnitten o.ä.? Wer möchte kann sich auch gerne dir Lazarus IDE holen und selbst testen, im Archiv ist auch eine Debug-Konfig drin. @Holger was ist an kiB falsch? Der rechnet mit /1024 Leo schrieb: > Hmm da muss ich mal in die SynaSer Bibliothek schauen, die öffnet > letztlich den Port und wirft die Fehler. Hmm, gibts da schon ein Ergebnis? Bis der Fehler korrigiert ist kann man den UpdateLoader leider nur als eingeschränkt BT-tauglich bezeichnen und muß auf den AVRFlash21 zurückgreifen. Schade. Moby A. schrieb: >> Kannst du z.B. mit hterm oder Putty den Port immer zuverlässig öffnen? > > Nein. Ist auch unzuverlässig! Da möchte ich nach Wechsel von win7/64 auf Win8.1/64 noch ergänzen: Leider keine Änderung der Problematik. @Leo:
Habe heute ein bisschenZeit mit deinem UpdateLoader zugebracht, ist ja
doch deutlich komfortabler als die Kommandozeilenversion, insbesonders
die COM-Ports > 4 sind recht nützlich.
Mit reset bzw power-on klappte das auch bestens. Ich wollte das jedoch
auch aus der Applikation heraus starten können.
Peters fboot sendet "Peda\FF", du jedoch "Peda\xFF\0x0d"
Und ich habe gerade das fehlende \x0d als Kennzeichen genommen
("normale" Kommandos enden bei mir mit 0x0d und wurde direkt in der
Rx-ISR gezählt (FrameReceived++).
if (FrameReceived)
{
}
if ((RxCounter0 > 48) && !FrameReceived)
{//suche "Peda" in RxBuffer
//starte Bootlader
}
Das ging dann natürlich daneben :-).
Gibts einen Grund, warum du das 0x0d eingefügt hast?
Und steht das irgendwo?
Dankeschön für das ansonsten tolle Programm.
zu spät für edti: ich hatte die 2.2.4 verwendet, 2.2.5. gerade noch mal getestet, verhält sich gleich.
Gast
#4657861
@Crazyhorse Die 0x0D werden vor dem Passwort gesendet, vielleicht verschluckt sie dein seriell Adapter beim ersten Anlauf. So soll es sein: 0x0D + Passwort + 0xFF Das löst die Autobaud Funktion im Bootloader aus, damit auch Passwörter ohne "a" bzw. die nötige Bitfolge funktionieren. Steht irgendwo im Quelltext, nicht in der Doku, ist leider auch nicht abschaltbar oder du müsstest es in protocol.pas auskommentieren (AutobaudLeader). Schau dir mal die Funktion "Firmware Passwort" an, die ist seit 2.2.5. dazu gekommen. Damit kannst du ein Reset Kommando vor oder während dem Verbindungsaufbau schicken. Eingabe ist in ASCII oder Hex möglich, bei Hex mit $ getrennt. Davor oder danach - das ist relativ egal, wenn es ständig wiederholt wird :-) Verschluckt wird da nichts. Das Problem war einfach, dass ich nicht wusste, dass das 0x0d dabei ist. Und weil es dabei ist, wurden von meiner Software alle Anfragen in den Papierkorb entsorgt (ungültiges Format), siehe oben. Ich will da auch auch gar nichts ändern oder geändert haben, funktioniert ja jetzt. Ich bin nur drüber gestolpert, weil es mit fboot funktioniert hatte und mit deinem Programm nicht mehr.
Gast
#5099123
Hallo zusammen, Habe mich (leider ohne finalen Erfolg) mit dem Fastboot Loader beschäftigt. Beitrag "Re: Peter Danneggers Bootloader (fastboot) für AVR-GCC-Toolchain" Für meine Tests verwendete ich den UpdateLoader, den ich leicht modifiziert habe und möchte dies nun hier zürückgeben. Basis war die Version 2.2.5, dazugekommen sind, Erkennung der Signaturen für: - ATmega644p : 1E 96 0A - Atmega2560 : 1E 98 01 Sowie ein paar Anpassungen, damit ich es auf meinem Lazarus Build compilieren konnte (Bereich VersionInfos). Es grüsst, Markus Hallo Nutze den Bootloder von Peter seit langem, läuft prima danke Peter. Problem ist nur das Update Loader Programm, das zeigt sich bei mir leider mit verkrüppelter Oberfläche (siehe Bild). Das ist wohl Windows7 geschuldet das mitunter bei hoher Bilschirmauflösung Teile eines Fensters nicht darstellt (auch bei einigen Profiprogrammen ist das so). Habe ein Set mit 2xDellP2815 3840x2160 an NVIDIA Quadro4800 und konnte noch keine sinnvolle Einstellung finden wo das nicht auftritt. Nur beim Start im Vollbildmodus klappt es bei einigen Programmen. Leider funktioniert es mit dem Updateloader nicht da immer nur im kleinen Fenster gestartet wird. Kennt jemand eine Möglichkeit wie das Programm korrekt angezeigt wird. Auf meinem kleinen Laptop geht es nur auf Rechnern mit hoher Grafikauflösung nicht.
Angehängte Dateien:
Gast
#5109462
Steffen W. schrieb: > Das ist wohl Windows7 geschuldet das mitunter bei hoher Bilschirmauflösung > Teile eines Fensters nicht darstellt. Eher nein, liegt vermutlich an deiner DPI Einstellungen. Diese beeinflussen die Grösse der Texte in Fenstern, Programmen usw. Programme welche die DPI Einstellungen nicht berücksichtigen, bieten dann uu. zuwenig Platz um die Texte korrekt anzuzeigen (wie in deinem Screenshot). Weiss nicht wie es unter Win 7 ausschaut, unter Win 10 gibt es unter den Kompatipilitätseinstellungen (Rechtsklick auf EXE und Eigenschaften), einige Punkte mit denen dieses Verhalten übersteuert werden kann. Leider bringen einen die Kompatibilitätseinstellungen da auch nicht weiter, die Einstellungen dort ändern nichts an der Darstellung. Die Bildschirmauflösung will ich nicht reduzieren wollen, wozu habe ich denn dann einen hochauflösenden Monitor. Was ich mich frage ist nur warum dieses Problem heutzutage wo doch oft hochauflösende Bildschirme zum Einsatz kommen dies bei einigen Programmen (offenbar sind die meist VB) auftritt, die meisten zeigen ja korrekt an, geht also sollte doch bei allen möglich sein. Besonders ärgert mich immer wenn die Fenstergröße nicht änderbar ist.
Gast
#5126721
Hat den jemand schon mit Fastboot von P.D. getestet.
Gast
#5126723
Ich meine die Version V14 von P.D.
Gast
#5131054
Frankl schrieb: > Version V14 von P.D. Wo bekommt man die her? Aktuell ist 2.1 Wie funktioniert das verify eigentlich? Scheinbar nicht aus dem flash zurücklesen? Heute hat ein Kollege 400 Platinen (Tiny25, one-wire) mit Software versehen, funktionierten aber allesamt nicht. Ok, Fehler liegt beim Bestücker (der hat den Bootlader vorm Bestücken draufgemacht). Wie auch immer das passiert ist - selfprog war nicht gesetzt. Sollte nicht passieren, passiert aber eben doch. Das wirklich blöde - der UpdateLoader (2.2) hat immer erfolgreich gemeldet, Überprüfen war aktiviert. Das verify überträgt auch das Program auf den AVR, aber der Bootloader schreibt es nicht, sondern vergleicht es mit den Daten im Flash. Zurücklesen kann man mit dem Bootloader nicht. Antwort schreibenBitte melde dich an, um einen Beitrag zu schreiben. |
Anzeige
|
