Posts by DG4FCO

    Also nun konnte ich schon mal ein "Testboard" zusammenlöten und an einen Arduino Uno anschliessen.

    Als Testprogramm habe ich die Samples von EA genommen.

    Da funktionieren schon mal beide Displays einwandfrei und die Werte an den Pins 15-19 des Displays stimmen mit den Messwerten überein.


    Die Cs auf der Platine des Microsolfs habe ich getauscht, es funktioniert jedoch immer noch nicht.

    Der Code im ATMega ist jetzt nicht in dem Sinne "Original"

    Ich habe mittels MiniPro Programmer die Microsolf Software sowie den Bootloader eingespielt.

    Meinst Du, das könnte ein "Kontrast" oder "initialisierungsproblem" sein?

    Die Initialisierungsroutine müsste doch in allen Softwareversionen enthalten sein?


    Die nächsten Schritte bei mir sind:

    a) Kontrolle der Platine auf defekte (Leiterbahnen, Unterbrechungen oder Brücken)

    b) "Ältere" Software nutzen

    c) Wenn ich das hinbekomme, mein "Testboard" mit dem Arduino auf dem Microsolf-Board koppeln

    Kann man das Abschleifen auch "Nass" machen? Also mit Nass-Schleifpapier? Das würde das Problem der in die Haut eindringenden Mini-Splitter doch verringern?


    Und jetzt zur "Todsünde": Muss man das wirklich ganz ordentlich abschleifen? Bei anderen, neu zu lackierenden Sachen, wird das ausserhalb des Amateur- und Hobbybereich nie so extrem gemacht. Das wäre auch sehr zeitaufwendig und damit zu teuer für die Kunden.

    Also ich warte noch auf neue Eingebungen und Tips.

    Leider habe ich vergessen, bei der letzten Bestellung noch nen neues Display dazu zu bestellen. Evtl. sind ja wirklich *beide* kaputt. So genau kann ich das jedoch nicht sagen.

    Ob es dafür einen "Test" gibt? Oder einen Mini-bausatz, der nur Zeugs auf genau so einem Display anzeigt, damit man weis, ob es ganz ist?

    Hihi,

    also den Unterschied habe ich, glaube ich, gefunden.

    Luna-AVR macht beim compilieren aus dem Bootloader folgendes:


    Ein jmp <Bootloader-Adresse> auf Stelle 0x00, dann Füllbytes (nop) bis zum Bootloader und dann den Bootloader.

    Das ergibt für den Bootloader mal eben "flash (used) : 124498 bytes"


    Den Satz "Ab sofort darf man sein Anwenderprogramm nun nicht mehr mit z.Bsp. AvrDude auf den Controller hochladen, da sonst der Bootloader gelöscht/überschrieben würde." verstehe ich auch nicht ganz,

    da der Bootuploader ja auch nur *das Anwendungsprogramm* (also beim Micro-Solf die Firmware) ab der Stelle 0x00 hochlädt! Und das ist so klein, dass es eben *nicht* in den Bootloader schreibt.

    Evtl. muss man bei avrdude ein paar Parameter richtig setzten, damit nicht "erase before write" passiert.


    Es ist eher umgekehrt, das ein neues aufspielen des Bootloaders das Anwendungsprogramm im ATMega löscht!


    Wie gesagt: Ich hab das auch compiliert und mir im Hex-Editor angeschaut (Opcodes musste ich nachschlagen) :whistling:

    Jupp. Ist aber so. Ich habe es hier an diesem Rechner probiert.

    Ein Asus M5A78L-M/USB3. An USB3 und USB2. Durchgereicht an Windows 7 in der VM (QEMU).

    An USB2 geht der FTDI, an USB3 nicht.


    Dann an dem "Afu"-Laptop probiert. Ein Fujitsu Lifebook E734. Hat (scheinbar) nur USB3.

    Mit Windows 10 drauf. Mit keinen der 3 Ports "funktioniert" der FTDI.


    Leider habe ich auch ausser dem "bootuploader" zu dem Microsolf keine andere Testmöglichkeit für den USB-Seriell Wandler da.


    Vieleicht ist es ja "nur" die Kombination, die Probleme mit dem Anschluss an USB3 hat.

    Jedoch sollte es doch egal sein, welche Art von USB-Port "gewandelt" wird?


    Vieleicht sollte ich mal einen "Seriell-Port"-Tester basteln :D Mit variabler Baud-Rate :D


    Hat da jemand was?

    Hach, schön :D

    Ich habe von einem alten IBM Laptop noch einen USB zu COM/LPT Wandler, wo genau dieser "PHASED OUT SINCE 2012" Chip drinne ist.

    Den wollte ich auch mal probieren. Geht natürlich nicht.


    Evtl. ist es einfacher, ich nehm eine weitere SSD und installier auf dem Laptop dann ein frisches Windows 7.

    Dann ist a) Im Bios auf USB2 gestellt und b) die Betriebssystem-Treiber "frisch"

    Evtl. funktioniert es dann?

    Uh, Oh.

    Das hört sich alles sehr aufwändig an.

    Ich möchte eigentlich nichts über Windows lernen ;)

    Das war beim Laptop dabei und hat seine eigene SSD.

    Leider gibt es einiges an Afu-Software nur in Windows resp. lässt sich dort einfacher Bedienen.

    Und da ich im Hobby nicht meinem Beruf (IT) nachgehen möchte,

    habe ich nun mal eine SSD mit Windows 10 und eine SSD mit Linux für den Afu-Laptop.


    @Tom: Was ist den daran "quasi propitär"? Ich habe mir Bootloader Quellcode in Luna und C angeschaut.

    Grob sieht das gleich aus. Was mich bei Luna "irritiert", ist die Angabe der Prozessor-Taktfrequenz.


    Wenn das andere Problem gelöst ist, kann ich ja mal schauen, ob ich das gleiche, was ich mit dem "bootuploader" Programm hinbekomme, auch mir dem MiniPro oder mit dem Diamex Programmer hinbekomme.


    Dann bleibt "nur noch" das Problem, dass ich zur Kommunikation mit einigen Funkequipment (wie meinen Micro-Solf) nun mal einen USB-Seriell Wandler brauche. Und der sollte mit dem vorhandenen Afu-Laptop funktionieren. Der hat nun mal nur noch USB3.

    Jetzt "mal eben" nen alten(!) gebrauchten kaufen, damit ich SIO ∧v USB2 habe, naja.

    So,


    also den Tipp von Peter, DB6ZH habe ich mal ausprobiert.

    Das war mir gar nicht bewusst, dass es da im BIOS so einen Punkt gibt!

    Ich habe mal die auf "OFF" (USB3-Aus) und damit laut Bios auf USB2 gestellt.


    Leider hatte das noch keine Auswirkung (Windows 10, FTDI geht nicht am Port).


    Da ich normalerweise nur mit Unix/Linux/BSD arbeite und mich nicht mit Windows auskenne:

    Muss ich danach irgenwelche Treiber neu installieren oder hätte das auch so funktionieren sollen?


    Danke vorab!