Hallo Besucher, der Thread wurde 135k mal aufgerufen und enthält 277 Antworten

letzter Beitrag von marty am

arm2iec [Neue Hardware]

  • Du kannst noch einen rudimentären Test machen ob die Kommunikationsstrecke bis zum Xpressomodul OK ist.
    Dazu ziehst du das Modul ab und steckst eine Drahtbrücke in Pin 21 und Pin 22 des leeren Sockels, siehe Bild.
    arm2iec_serial_test.jpg


    Dann schliesst du die Platine am kleinen USB Port an und startest auf dem Rechner Hyperterminal und stellst eine Verbindung über COM5 oder was auch immer bei dir für ein Comport eingerichtet wurde her.


    Parameter so wie im Bild einstellen:
    _com1.png


    Wenn die Kommunikation über den USB/Seriell Wandler bis zum Xpresso Modulsockel OK ist dann sollten die Zeichen die du eingibst im Terminalfenster erscheinen.

  • also ich hab die neue die Hardware nicht, aber wenn ein so simpler loopback-test nicht geht, dann liegt die Ursache meist am USB nach seriell Wandler bzw. seinem Treiber. Die Hardware ist daran eher nicht Schuld. Das sagt mir meine langjährige leidvolle (Berufs-)Erfahrung mit diesen USB nach seriell Dingern.


    Bitte schau mal im Gerätemanager bei den seriellen ports, welcher Port überhaupt zum arm2iec gehört. Dazu im Gerätemanager die COM-Ports öffnen und dann das USB-Kabel zum arm2iec abziehen. Der Port, der jetzt im Gerätemanager verwschwindet, ist derjenige mit dem das Ding geflasht werden muss. Jetzt mal schauen, Ob Windows bei dem Treiber dieses Ports irgend ein Problem meldet bzw. welcher Treiber überhaupt geladen wurde (Version etc). Geht alles mit rechter Maustaste auf den entsprechenden COM-Port im Gerätemanager.
    Mir ist es schon sher oft vogekommen, wenn ich ein neues USB nach seriell Konverterdings an Windows angestöpselt habe, dass dann irgend ein bereits installierter älterer Treiber dafür verwendet wurde, welcher dann allerdings nicht zuverlässig funktionierte. Eventuell kann man ja mal die Treiberversion mit der Version bei anderen Leuten hier vergleichen... Man kann Windows auch explizit bitten eine bestimmte Treiberversion zu verwenden.
    Ach ja, manchmal hilft es auch alle anderen möglicherweise verbundenen USB-nach-seriell Dinger abzustöpseln.

  • Hier noch eine neue Beobachtung von mir, bzgl. Bustreiber und Betrieb mit abgeschaltetem arm2iec. In einer Kette C64-1541-arm2iec-sd2iec(sw2) konnte ich bei abgeschalteter 1541 und arm2iec nicht auf das sd2iec zugreifen. Bushänger! Wenn die 1541 an war, war es zumindest instabil, z.B. die CTRL-D Devicefindefunktion von Jiffydos fand nicht immer alle Laufwerke. Manuelles Wechseln und Zugriff ging dann aber.


    Ich hatte erst den 74LS07 des arm2iec im Verdacht. Diesen habe ich testweise gegen einen 7407 getauscht. Keine Verbesserung. Beim Wechsel sah ich, dass anstatt eines 74LS14, wie im Schaltplan eingezeichnet, ein 74HCT14 verbaut war. Diesen habe ich gegen einen 74LS14 getauscht - Problem behoben! Den 74LS07 habe ich wieder zurückgebaut, ohne negative Auswirkungen.


    Das ganze mit einem arm2iec 1.0 und 1.1 identisch. Nun tragen beide 74LS14 und können auch ohne Strom am Bus bleiben :)

    Code: Floppy Fehlerkanal abfragen - Ausserdem kann ich bei "drive not ready" den I: und N: Befehl verwenden und notfalls den Kopf manuell zurückschieben. Und Finger weg vom Stepper!
    1. 10 open1,8,15 : rem 8 ist die Geräteadresse und das kann man bei Bedarf natürlich anpassen
    2. 20 get#1,a$:?a$;:ifst<>64goto20 : rem Das CLOSE 1 am Ende kann man sich sparen, weil beim RUN automatisch ein CLOSE ALL ausgeführt wird.
    3. RUN
  • für das arm 2iec wird beim anstecken mit dong geräuschder com port 5 geöffnet. wenn ich es abziehe wieder dong und es verschwindet aus dem geräte manager. ich habe kein konflikte im geräte manager.


    wenn das arm angesteckt wird wird für com 5 der aktuelle microchip technology inc treiber vom 28.8.2012 verwendet.
    er hat die revision 5.1.2600.3.


    diverse usb kabel habe ich auch schon durchprobiert.


    in einem anderen projekt habe ich die usb zo serial von ftdi verwendet,die funktionieren einwandfrei, haben noch nie probleme gemacht.



    edit.


    so mal dieser versuch:


    mcp.JPG

  • und weiter gehts


    am zweit system bekomme ich jetzt Get adapters info error 232 (01574 C18,0)


    Nach Stundenlanger recherche weiss ich jetzt das das LPC1769 einen ganz schlechten ruf hat.


    der Microchip 2200 als Usb converter im gegensatz zu den ftdi s und den prolific grosse probleme macht.


    Kohle zum fenster rausgeworfen. Vergebene Mühe

  • Nach Stundenlanger recherche weiss ich jetzt das das LPC1769 einen ganz schlechten ruf hat.


    Nach stundenlanger Recherche wirst Du das gleiche über alles und jeden rausfinden können.


    der Microchip 2200 als Usb converter im gegensatz zu den ftdi s und den prolific grosse probleme macht.


    Hier nicht.

  • Zitat

    der Microchip 2200 als Usb converter im gegensatz zu den ftdi s und den prolific grosse probleme macht.


    Ich weiss, es hilft Dir jetzt nicht viel, aber hier rennt der Microchip einwandfrei unter XP, W2003 und Windows 7.
    Dafuer hatte ich schon des oefteren Probleme mit FTDI und Proliffic auf diversen Systemen. Ist halt alles relativ.

  • yo dann bilde ich mir das ein.


    Hat ja keiner behauptet.


    Dein PC hat halt eine Driver Unverträglichkeit mit der USB-Bridge. Da kann das arm2iec an sich nix für. Ist ein bedauerlicher Einzelfall, wenn es bei 40 Leuten funktioniert und bei dir nicht.

  • Dein PC hat halt eine Driver Unverträglichkeit mit der USB-Bridge.


    wenn du alle posts von mir gelesen hättest wüstest du auch das ich an min 2 verschiedenen systemen dran war.
    heute nacht kam mein laptop noch dazu , und vorhin der werkstatt pc.


    ich glaube nicht das das problem an mir liegt.


    aber so ist das halt mit den microcontrollern, wie hütchen spielen in der fussgängerzone.

  • Wie viele ARM2ICEC gibt es? Und bisher hast nur du als einziger dieses Problem? Und das an allen von dir getesteten Rechnern?


    Rein statistisch sollten mehr Leute dieses Problem haben, wenn es allgemein an diesem Modul liegt. Und dass ein Treiber wirklich bei jedem läuft und nur bei dir ein Problem macht aber da gleich bei allen Rechnern ist auch ehr unwahrscheinlich. Das wäre aber vielleicht noch zu erklären, dass du vielleicht auf all deinen Rechnern einen ganz bestimmten Treiber oder sonst eine Software oder Virus hast (den hier sonst keiner hat) der sich mit diesem Treiber beißt. Das wäre zumindest eine mögliche Erklärung, warum es nur auf deinen Rechnern nicht geht.
    Wie gesagt: Rein statistisch klingt es am ehesten nach einem Hardwaredefekt! Ob es jetzt ein Lötfehler ist oder ein defekt durch elektrostatische Entladung oder was auch immer ist dabei zweitrangig. Zumindest weiß ich nicht, warum du zu über 99,9% sicher sein kannst, dass es nicht dein Löten war?!



    PS: Grrrrrr! Da war ich doch heute beim blauen C und hab ganz vergessen mir einen 74LS14 mitzunehmen. :(

  • In einer Kette C64-1541-arm2iec-sd2iec(sw2) konnte ich bei abgeschalteter 1541 und arm2iec nicht auf das sd2iec zugreifen.


    In einer Konfiguration mit abgeschalteten Laufwerken garantiere ich auch nicht für Funktion.


    (genaugenommen garantiere ich in keiner Konfiguration für Funktion ;) )


    Zitat

    Beim Wechsel sah ich, dass anstatt eines 74LS14, wie im Schaltplan eingezeichnet, ein 74HCT14 verbaut war. Diesen habe ich gegen einen 74LS14 getauscht - Problem behoben!


    Im Schaltplan steht LS weil ich zu faul war das nochmal anzupassen, die Wahl fiel auf HCT weil die Chips etwas billiger zu beschaffen waren als LS. Wenn Signale an den Eingängen hängen ohne dass der Chip mit Strom versorgt wird ist das bei beiden ausserhalb der Spezifikation, möglicherweise ändert sich das Verhalten auch je nach Hersteller.