Eigener Bus, aber wie??

[Bender_U22]

Guten Abend!

Ich hatte letztens eine idee und möchte gerne von euch wissen ob es möglich ist, bzw wie Ihr das lösen würdet.

Ich habe mir überlegt eine PLatine mit einem Bussystem ähnlich wie in einem PC zu bauen. Das heisst ich würde mehrere Steckplätze auf der Platine machen in die ich dann "Erweiterungsplatinen" reinstecken kann die miteinander kommunizieren. Es soll auch einen µC auf dieser Platine geben, der den Bus steuern kann, eine serielle Schnittstelle, Funk, LCD... hat. Ich dachte erst an I2C, aber I2C will ich als eigenen Bus auf den Erweiterungskarten haben und es soll nicht wirklich einen fixen Master geben. Währe es mit dem Atmel Mega 23 bzw Mega 16 möglich einen 8 Bit bus relativ einfach zu realisieren? Müsste ich ein eigenes Protokoll schreiben, wenn Ja, wie kann man das mit Bascom machen?

Danke im voraus,

Lg Bender

[askazo]

Ich denke mal, einen parallelen Bus zu realisieren macht wenig Sinn, es sei denn, es kommt wirklich auf hohe Übertragungsgeschwindigkeit an. Zudem müsstest Du Dir dafür ein eigenes Protokoll basteln.
Da Du keinen festen Master haben möchtest, würde sich CAN anbieten. Allerdings brauchst Du dazu entweder einen AT90CAN - die gibts aber nur als SMD - oder einen zusätzlichen CAN-Controller (z.B. MCP2515) und einen CAN-Transceiver (z.B. PCA82C250). Das ganze wäre dann aber sehr flexibel und zudem sehr störunempfindlich. Und es gibt hier im Forum eine Menge Stoff zum Thema CAN mit Bascom.

Gruß,
askazo

[Bender_U22]

Hallo azkazo!

Thx für deine schnelle Antwort! :-) Habe mir gerade das Datenblatt des MCP2515 angesehen. Ich glaube das ist das richtige und mit 1Mbit ist der bus ja auch nicht wirklich langsam... Wenn ich das richtig verstanden habe muss also jede Erweiterungskarte einen MCP2515 und einen Controller haben. Ich kann jeden MCP2515 einen Identifier geben mit dem er angesprochen wird. (sowas wie eine adresse?) In dem Beispiel im Datenblatt ist unter jedem MCP2515 etwas das sich XCVR nennt und dann mit dem eigentlichen Bus verbunden ist. Was genau ist das? Habe mit Google nichts hilfreiches dazu gefunden...

Thx

Lg Bender

[Felix G]

enn ich das richtig verstanden habe muss also jede Erweiterungskarte einen MCP2515 und einen Controller habenJede Karte braucht einen Mikrocontroller, einen MCP2515 und einen CAN-Transceiver.


In dem Beispiel im Datenblatt ist unter jedem MCP2515 etwas das sich XCVR nennt und dann mit dem eigentlichen Bus verbunden ist. Was genau ist das?Das müsste dann der Transceiver sein.



Ich kann jeden MCP2515 einen Identifier geben mit dem er angesprochen wird.Nicht ganz...
bei CAN haben die Geräte eigentlich keine Adressen, sondern die verschickten Nachrichten haben IDs. Empfangen wird erstmal jede Nachricht von jedem Gerät am Bus, ob und wie ein Gerät auf eine bestimmte Nachricht reagiert bleibt aber dem Gerät überlassen.

Wenn ich mich nicht irre kann die ID 11Bit lang sein, es gibt also prinzipiell erstmal 2048 unterschiedliche Nachrichten. Und wenn du die Geräte wirklich explizit adressieren möchtest, könntest du z.B. die ersten 6 Bit der ID als "Geräteadresse" benutzen, so daß du 64 Geräte adressieren könntest, und mit den letzten 5 Bit kannst du dann 32 verschiedene Nachrichten für jedes Gerät definieren.

Genauso könntest du aber die IDs auch so vergeben, daß die ersten paar Bit vielleicht eine ganze Gerätegruppe ansprechen, und die restlichen dann das gewünschte Gerät dieser Gruppe. Oder du benutzt die ID überhaupt nur um Gerätegruppen zu identifizieren und packst die Information darüber welches Gerät gemeint ist dann in die Nachricht selbst (passen ja ein paar Byte Nutzdaten rein).


kurz gesagt:
jede Nachricht hat eine ID, aber wie du die IDs verteilst und den Bus organisierst bleibt im wesentlichen erstmal dir überlassen.


edit:
Falls 2048 Nachrichten nicht ausreichen, kann man übrigens auch eine 29 Bit lange ID verwenden.

[elmar69]

Ich dachte erst an I2C, aber I2C will ich als eigenen Bus auf den Erweiterungskarten haben und es soll nicht wirklich einen fixen Master geben.

Es spricht nichts gegen zwei i2c-Busse.

Das Master-Problem kann man mittels Interrupt-Leitung entschärfen, dann kann der Slave bescheid geben, wenn's was zu tun gibt.

[uwegw]

I2C ist übrigens auch Multimaster-fähig...

[Bender_U22]

Hallo!

Danke für eure Antworten! Ich habe mir jetzt mal die Chips bestellt, und werd mir das alles auf eine Platine löten wenn Sie da sind. Habe auch im Forum hier ein bischen nach Can Bus Projekten gesucht. Irgendwie hatte ich den Eindruck das solche sachen mit Bascom schwer zu programmieren sind... Ich bin mit Bascom noch ziemlicher Anfänger, wie schwer wird das werden, bzw gibt es villeicht irgendwo ein Tutorial für Bascom + Can bus??

Ist es villeicht einfacher das mit i2c zu lösen? Wo sind die Vorteile/Nachteile gegenüber dem CAN Bus? Später soll der Bus auch Erweiterungskarten automatisch erkennen, und merken wenn eine bestimmte Karte nicht mehr da ist. Neue Karten sollen erkannt werden und sie sollen dem Bus irgendwie mitteilen könne wie er sie zu Steuern hat bzw was sie für Daten senden. Ist sowas möglich?

Thx im voraus,

Bender

[Felix G]

Der wohl größte Nachteil von I2C gegenüber dem CAN Bus ist die geringere Störfestigkeit.


Später soll der Bus auch Erweiterungskarten automatisch erkennen, und merken wenn eine bestimmte Karte nicht mehr da ist. Neue Karten sollen erkannt werden und sie sollen dem Bus irgendwie mitteilen könne wie er sie zu Steuern hat bzw was sie für Daten senden. Ist sowas möglich?Was du da beschreibst entspricht ziemlich genau dem Funktionsumfang von CANopen, einem auf CAN basierenden Protokoll.

Leider ist CANopen relativ komplex, und du müsstest das Protokoll wohl selbst programmieren, denn ich möchte mal bezweifeln daß es das schon fertig für Bascom gibt.


Bei CANopen hat jedes Gerät ein sog. Objektverzeichnis, was im wesentlichen eine Liste ist mit allen Befehlen die das Gerät versteht, und noch ein paar anderen Kleinigkeiten.

Außerdem hat jedes Gerät eine NodeID, also eine eigene Adresse (ohne CANopen ist das beim CAN-Bus ja nicht der Fall)

Und dann gibt es verschiedene festgelegte Nachrichtentypen die zwischen den Geräten ausgetauscht werden können, nur daß die nicht Nachrichten genannt werden, sondern Objekte...

Die wichtigsten Objekte sind dabei PDOs (Process Data Object) und SDOs (Service Data Object), wobei erstere hauptsächlich für kurze Befehle mit wenig Daten genutzt werden die aber möglichst schnell am Ziel ankommen müssen, und letztere dienen eher zum Transport größerer Datenmengen bei denen es nicht so schlimm ist wenn es mal länger dauert.


kurz gesagt:
alles ein bischen kompliziert, aber vom Funktionsumfang her exakt das was du suchst

[PicNick]

Geht auch mit Bascom und etwas Hilfe
https://www.roboternetz.de/wissen/index.php/TWI_Praxis_Multimaster

[Bender_U22]

Hallo!

Hatte jetzt länger keine Zeit, bin jetzt aber wieder dazugekommen an meiner "Bastelarbeit" weiterzumachen. Habe jetzt eine Platine mit Mega32, LCD, RS232... Fertig mit der man später die verschiedenen Geräte am Bus steuern kann. Das Problem: Ich möchte gern Daten im EEprom des AVR speichern. (Einstellungen,...) Leider hab ich keine Ahnung wie man den EEprom mit Bascom beschreibt oder Daten wieder lesen kann... Finde auch mit Google nichts. Kennt jemand zufällig ein gutes Tutorial dafür?? Kann ich auch die Baudrate während der Ausführung des Programms ändern und im EEprom speichern, damit er beim nächsten einschalten die neue Einstellung übernimmt??

Werde übrigens bei diesem Projekt CAN und I2C verwenden, ich möchte sehen mit welchem ich besser zurechtkomme, bzw was für dieses Projekt am besten geeignet ist. Hatte ja noch mit keinem der beiden wirklich viel zu tun.

Thx für eure Hilfe

Bender_U22

[Vitis]

dim variable_bla as eram byte und schon wird das Byte ins eeprom
gespeichert

variable_bla = 10 ' geht genauso wie
variable_palaver = variable_bla

TWI hat halt den Vorteil bei atmega schon hardwaremäßig drin zu sein,
für CAN brauchste noch mindestens 1, besser 2 Bausteine dazu.
innerhalb einer Baugruppe für relativ kurze Strecken würde
ich TWI bevorzugen. Geht auch schnell und ist einfach im Umgang.
Klar kannste mit Bascom auch den MCP verwenden, aber so ganz
trivial ist das eben nicht und in dem Fall vermutlich auch nicht besonders
schneller.
Mit dem TWI kannste auch schon gut in die 400KHz Takt, u.U. auch höher.
In einem Projekt hab ich mit 800KHz getaktet, das ging auch noch
absolut zuverlässig auf kurze und mittlere Distanzen.