Hallo Hoesslin,

danke für die kompetente Antwort, das erklärt einiges.
Wirkt sich das mit der Pegelwandlung nur auf den Flashvorgang bei FSBUS aus, oder auch auf den Betrieb ?
Ich habe nämlich den, erfolgreich geflashten Ad-Converter wieder an meinen 'normalen' PC angeschlossen, habe einem angeschlossenen Poti die Schubsteuerung eines Triebwerkes zugewiesen und das hat funktioniert.
Inzwischen habe ich mit dem Laptop auch erfolgreich die LED Controllerkarte geflasht, diese scheint aber an meinem 'normalen' PC nicht zu funktionieren, hier leuchten die angeschlossenen LED's, egal an welcher Stelle und egal mit welcher Funktion; sie lassen sich also nicht schalten.
Daher nochmal die Frage: Ist mein PC nur zum Flashen ungeeignet, oder auch zum Betrieb des FS-BUS Systems ?

Danke für eure Geduld
Torsten

Hallo Thorsten,

die Schnittstellen - "Problematik" wirkt sich nur beim Flashen aus, weil die Kommunikation mit dem PIC im "Spielbetrieb" ja über den MAX verläuft, und der ja quasi als Schmitt-Trigger auch "ungewöhnliche" Pegel sauber wandelt.

D.h. Dein PC ist nur zum FLASHEN "ungeeignet".

Das Problem ist in der bisherigen Schaltung der (FLASH) Transistor TR1, der in der aktuellen Beschaltung nicht an einem TTL-Pegel hängt, sondern direkt an der RS232. (Ich hatte bereits einen Änderungsvorschlag gemacht)

Gruss

Thomas

Hallo Thomas,

ich habe mir deine Beiträge nochmal durchgelesen. Mich nervt ja auch, das es PC's gibt, die einfach nicht flashen wollen.
Du beschreibst ja zielsicher den TR1 als "Übeltäter", da er nicht an TTL hängt.

Ich hatte mir auch schon mal überlegt, ob unterschiedliche RS232 Pegel die Ursache sind, bin aber nicht weitergekommen.
Kannst du das, was deiner Meinung nach schiefläuft, noch genauer beschreiben ?

Mit der Meinung, das es PC's mit 5V TTL Schnittstelle als COM gibt, bin ich nicht so ganz einverstanden. Die habe ich noch nie gesehen.
Es stimmt aber, das die Spannung sehr schwankt, was sie von der Norm her aber darf. Der Bereich geht von +3V bis +15 und von -3 bis -15V.

Gruss Dirk

Hallo,

ich möchte noch auf eine weitere Darstellung eingehen:

Der Satz:

>>Diskrete Elektronik ohne Pegelwandlung (unser MAX ist eben ein >>Pegelwandler) hat da eben verloren ... im FSCOM der Transitor TR1, ->> zuständig für den "FLASH Takt"...

Auch ein MAX besteht aus Transistoren, genau wie Tr1. Tr1 mit dem Widerstand und der Diode wandelt den RS232 Eingang (-12, +12) sehr wohl in TTL Pegel um.

Insofern ist die Meinung, man erkennt ein gutes Motherboard daran, das FSBUS nicht flasht, nicht haltbar.

Gruss Dirk

Ich habe die Erkenntnis über "abartige" RS232 Schnittstellen aus diversen praktischen Erfahrungen, Foren und zuletzt als Referenz aus dem Buch "PC-Schnittstellen unter Windows" von Kainka + Berndt, Seite 23 ...

Der "Überltäter" muss letztendlich nur TR1 aus folgender Logik sein (ohne das Oszi auszupacken ;) ):

- Spielbetrieb funktioniert mit allen PCs
- Flashen geht nur mit manchen PCs
=> MAX geht => Flashen dreht sich um TR1 => variable Pegel sind bekannt => es kann nur TR1 sein :-)

Gruss

Thomas

P.S.: Meinen Änderungsvorschlag schon ausprobiert ...?

Vollkommen korrekt.

Nur ist der MAX ein in sich geschlossenes und abgestimmtes System und hat keine normalen "nur" NPN oder "nur" PNP als Eingänge, sondern symetrische Eingänge;

Hallo Thomas,

dein Vorschlag kann nicht funktionieren, da der MAX alle Signale invertiert. Wenn du den Basiswiderstand anstatt am Eingang des MAX an den Ausgang klemmst, wird das Signal invertiert.
Das kann ohne Softwareänderung nicht laufen.

Hast du das denn jemals ausprobiert ?

Zum Flashbetrieb. Beim Flashen wird der serielle Teil der COM Schnittstelle nicht genutzt. Die Signale (auch Tx) werden rein
per Software ein und ausgeschaltet.
Eigentlich bräuchte man dafür ein realtimefähiges Betriebssystem, was unser geliebtes Windows leider nicht ist. Ein Timing im Mikrosekundenbereich ist nur annähernd hinzubekommen.
Leider gibt es beim PIC ein paar Zeiten die nicht unterschritten oder
überschritten werden dürfen.
Da vermute ich die Problematik mit unterschiedlichen PC's.

Da die asynchrone Übertragung (im Spielbetrieb) von der Hardware übernommen wird, ist dieser Modus unkritisch.

Ich müsste mal einen nicht funktionierenden PC in den Händen haben um das zu analysieren.


Gruss Dirk

Guten Morgen ihr Lieben,

also hatte auch probs mit dem Flashen und habs auch nur mit nem alten Notebook der scheinbar die richtige Rechnergeschwindigkeit hat hinbekommen und auch nur mit der alten FSBus-Version, ist ja egal da sich der Code ja nicht geändert hat.

gruss Peter :) :)

Hallo Dirk,


wo Du Recht hast, hast Du Recht ! Das mit dem Invertieren hab ich in meiner grenzenlosen Theorie einfach übersehen, war wohl der Mund(Finger) schneller als das Hirn :confused: - ein Beweis wie schnell ein unschuldiger (TR1) verurteilt werden kann :confused: - peinlich für einen Elektroniker :confused:

Damit ist nun auch Deine Frage beantwortet :rolleyes:

Das ist natürlich ein weiteres erschlagendes Argument. D.h. Du taktest Tx nicht über den UART sondern direkt per SW ? Hm, korrekt, sehr schwierig hier ein Timing auf die Beine zu stellen. Hier beim PIC kann ich nicht mitreden, ich benutze ATMELs die über SPI geflasht werden (oder über Bootloader auch per normalem RS232) und das kann ich normal in VB über MScomm im Binärmodus.

Dirk, ich nehme meine FALSCHE "Anklage" zurück.

Ist ja kein Problem.
Wenn wir über eine Diskussion dem wahren Übeltäter der Flashprobleme auf den Grund kommen, um so besser.

Der Grund, warum ich den Flasher mit aufgenommen hatte, ist die Einsparung der 200€ für einen echten Flasher.

Man findet im Internet eine Menge solcher "Low budget" Flasher Bauvorschläge. Momentan versuche ich übrigens den 16F627 mit dem COM Flasher ans flashen zu kriegen. Das ist auch wieder "Fummelskram".

Schönen Sonntag noch!

Dirk