Guten Abend, ich möchte ein A320 Homecockpit, bzw. vorerst enige Komponenten dazu bauen. Da ich nicht vom Fach bin, nutze ich dass Forum und vor allem die Tutorials um dazu zulernen. Zu meiner Frage habe ich allerdings nichts gefunden. Ich bin bereits soweit, mittels Demultiplexer und 74HC595 16 7-Segment Anzeigen anzusteuern. Ebenso habe ich mich bereits mit Taster, entprellen etc. beschäftigt. Steckbretter sind echt Klasse. Der nächste Schritt ist ein passendes Bus System. Die einzelnen Komponenten möchte ich mittels Bus vernetzen, wobei eine Masterplatine, die Kommunikation mit dem Flugsimulator PC übernehmen soll. Dabei scheint mir der CAN Bus am besten, zum einen wegen der Länge und weil er mit einem Multimaster System zurecht kommt. Allerdings habe ich jetzt einen Knoten im Hirn. Als Can Controller ist der MCP2515 wohl eine gute Wahl. Aber ich habe ja, z.B.: am FMCU(Autopilot) auch 8 kaskadierte Schieberegister (4x595 und 4x165) am SPI. Wie kann ich jezt auch noch den CAN Controller am SPI betreiben? Als uC spiele ich zur Zeit mit aTmega8, demnächst mit einen aTmega32. Oder habt Ihr noch andere Anregungen bzgl. Bus? RS485 hat da doch gewisse Einschränkungen (nicht vollduplexfähig). Freue mich konstruktive Beiträge. Brauche keine fertigen Lösungen, mir geht es darum es am Ende selbst zu verstehen. Gruß fkott
Jens K. schrieb: > Allerdings habe ich jetzt einen Knoten im Hirn. Als Can Controller ist > der MCP2515 wohl eine gute Wahl. Äh. Nö. Für nur wenig mehr bekommst Du auch den PIC18F26K80, der eine verbesserte(!!!) Version des MCP2515 plus ein kompletter Mikrocontroller ist. Auf die CAN-Register kannst Du hier natürlich direkt zugreifen, der Umweg über SPI ist unnötig. Wenn der Dir zu klein ist, darf es auch ein dsPIC33FJ128GP802 (80 MHz) oder dsPIC33EP512GP502 (140 MHz) sein - auch alles DIL28. fchk
Hallo Frank, danke für den Tipp, aber ich habe momentan mit AVR angefangen und PIC noch nicht direkt auf der Liste. Wenn ich da nich rum komme, werde ich mich intensiver damit beschäftigen. Gruß fkott
MCP2515 ist ne gute Wahl, wenn du mit mit einem bekannten System auch per CAN kommunizieren willst. Mag sein, dass eine andere Lösung theoretisch sinnvoller ist, optimal ist aber die lösung, die schnell zu Ergebnissen führt. Es gibt auch etliche AVR mit integriertem CAN Zu deiner ursprunglichen Frage: natürlich kannst du das kombinieren - mit wem die SPI redet, bestimmt das CS-Signal. Gesamt-SPI-Datenrate verteilt sich natürlich, dass ist aber i.a. kein Problem.
Hallo Joachim, ich denke natürlich auch an die CS Geschichte. Allerdings ist dies bei den Schieberegistern nicht möglich. Die haben doch keinen CS Pin. Oder bin ich da falsch. Oder kann man die MISO und MOSI Leitung mittels Transistor oder Logic Baustein umschalten? Gruß fkott
die 74HC595 haben ein CS. Der heißt bei denen nur anders. Im NXP 74HC595 Datenblatt heißt der OE "Output Enable". Hier auf der Seite gibt es auch einen Artikel wie du den 74HC595 an die SPI anschließt. Im Artikel Schieberegister glaube ich.
Hallo Florian, meiner MEinung nach, ist der OE (Low active) dazu da, die parallelen Ausgänge frei oder hochohmig zu schalten. Hat jedoch nichts mit dem DS bzw. Chip Select zu tun. Gruß fkott
Das sollte aber kein Problem sein. Beim HC595 hat man ein "Schattenregister" welches direkt durch die serielle Datenübertragung gefüllt wird. Durch das oe sollte es dann an die Ausgänge übernommen werden. Wenn die nicht übernommen werden kannst du ja in den Schattenregistern tun und lassen was du willst. Es muss nur vor der Übernahme das gewünschte Bitmuster in das Register geschoben werden (CS vom MCP dann natürlich inaktiv).
Jens K. schrieb: > danke für den Tipp, aber ich habe momentan mit AVR angefangen und PIC > noch nicht direkt auf der Liste. Wenn ich da nich rum komme, werde ich > mich intensiver damit beschäftigen. PICs haben eine größere Auswahl an Peripherie, die dann oft auch mehr kann. Wenn Du unbedingt bei den AVRs bleiben musst, würde ich zu RS485 greifen. Da musst Du zwar mehr implementieren, was bei CAN die Hardware macht, aber Du ersparst Dir Schaltungsaufwand, und das Debuggen ist dann auch einfacher. Für die Entwicklung hast Du es am einfachsten, wenn Du einen JTAG Debugger und einen AVR mit JTAG (AVR> mit 40 Pins und mehr, zB Mega 644p) verwendest. Dann kannst Du Dir auch Variablen und Speicherinhalte im Chip anschauen. Das ISP ist wirklich nur zum Flashen gut, und ein Mega 8 hat nichts anderes. Auch das ist bei den PICs besser: Hier kannst Du alle modernen PICs nicht nur flashen, sondern auch debuggen, und das benötigte PICKIT3 ist auch sehr bezahlbar (20€ als China-Nachbau, 50€ als Original), und es funktioniert mit 8, 16 und 32 Bit PICs. Es gibt auch große AVRs mit 100 Pins. Wenn Du so einen nimmst, brauchst Du Deine Schieberegister nicht mehr. fchk
Hallo Frank, ich werde vorerst bei AVR bleiben. Daher beschäftige ich mich nun mit RS485. Mir ist klar, das ich das Protokoll selbst erstellen muss. Im Moment habe ich nur keine Ahnung, wie ich die Arbitrierung realisieren soll. Multimaster ist aber wichtig, um Verzögerungen zwischen Tasterdruck und LED ein zu vermeiden. Ich habe Arbitrierung schon gegoogelt und hier im Forum nachgeschaut, aber es bringt mich nicht weiter. Das Protokoll soll in etwa wie folgt aufgebaut werden. 1. Startbyte 2. Adressbyte 1.Byte - Gruppe oder Panel 2.Byte - Klasse 3.Byte - Variable 4.Byte - Länge der Information (Anzahl Bytes) 5.- X.Byte - Information 3. Checksumme 3. Stoppbyte Das Protokoll zu relisieren, kriege ich hin. Allerdings muss ja der Slave gepollt werden, um die Übertragung zu bestätigen. Es ist noch jede Menge zu lernen. Ich verstehe dass nur mit der Implementation der Arbitrierung nicht. Danke für jede Hilfe, auch Links. fkott
Die RS485-Treiberbausteine haben alle ein !RE (Receiver Enable) und DE (Driver Enable) Eingänge, wobei einer invertiert ist. Damit kann man beide zusammenklemmen und zwischen Senden und Empfangen umschalten. DAS MACHST DU NICHT. Statt dessen lässt Du den Receiver ständig aktiv und schaltest nur den Sender ein und aus. Damit empfängst Du alles, was Du sendest. Und damit weißt Du, ob das, was Du gesendet hast, auch wirklich auf dem Bus zu sehen war. Wenn zwei Teilnehmer gleichzeitig senden, werden sie Müll empfangen. Dann müssen sie sofort aufhören zu senden, eine zufällige Zeit warten und es erneut versuchen. So macht es Ethernet auch. Statt R485-Treibern kannst Du auch CAN oder LIN-Treiber nehmen. Das erspart Dir das Ansteuern des DE-Signals. Ist dann zwar kein Standard mehr, wird Dich aber wohl nicht stören. Beachte, dass LIN nur bis 20000bps spezifiziert ist und mit 12V-Pegeln arbeitet. fchk
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.