Kollektives Brainstorming Hive-Cube mit Assimilations Option

[Hauke]

Ich denke es gibt ein paar Missverständnisse.

Ich will mal versuchen Klärung zu schaffen

PIC18F2550 hat geschrieben:
Hi Hauke,
ein klassisches Master/Slave system mit jeder menge optiopnen.
In deinem System ist die Software darauf angewiesen das an dem jeweiligen Chip die entsprechende Hartware angeschlossen ist.
Was einem variabeln Aufbau des Systems nicht zuläßt.
??? Bitte erläutern. Ich versteh grad nicht was du meinst.

Du kannst z.B. den Tastaturtreiber aus Platzgründen nicht einfach auf einen anderen Prop umsetzen (Buchse muß natürlich vorhanden sein).
... neuer Bellatrixcode muß geschrieben werden & .......

Das gezeigte Bellatrix Board hat noch die PS/2 Leitungen. Ich habe lediglich (aus Gründen die ich gleich erläutern werde) die Steckverbinder nicht mit auf das Board gesetzt. Es kann also noch die original Bellatrix Firmware eingesetzt werden.
Erstens hatte mir gedacht, wenn man mehrere Bellatrix-Boards einsetzt, das kann es zu Missverständnissen mit den PS/2 Anschlüssen kommen.
Zum Zweiten hatte ich ja mir das Arachneboard mit diversen Anschlüssen (z.B. PS2, USB-Host Fullspeed, USB-Host lowspeed, usw.) sowie einem Legacy- und einem erweiterten Modus geplant.

• 4. "Arachne" mit 2xPS2 (Tastatur+Maus), USB-Host, RS232(oder FT232 Wandler) und sonstiges (HID, Joystick etc.)

Im erweiterten Modus wird, die am Arachneboard angeschlossene, Peripherie über den I²C-Bus, den P2P-Bus und einen der beiden SPI Busse bereitgestellt. Hier wären auf Reg., Bel. und Adm. angepasste und erweiterte Firmware notwendig.

Im anderen Modus sollten diese in eingeschränkter Form auch von den Props mit Legacy-Firmware verwendet werden können. z.B. USB Maus, USB Tastatur oder Joystick (USB, Digital oder Analog)
Dazu müsste man die PS/2 Pins von Bellatrix per Loopback Kabel mit den PS/2 Pins von Arachne verbinden.
Die eigendlichen HID-Eingaben kommen z.B. über den lowspeed USB-Host von Arachne rein und werden dort "übersetzt" und an den Arachne-PS/2 Pins bereitgestellt.
Arachne "simuliert" in diesem Falle sozusagen eine PS/2 Tastatur und eine PS/2 Maus. Bellatrix merkt Nichts davon, ob die Eingaben von einer echten Tastatur kommen oder von Arachne.

PIC18F2550 hat geschrieben:
Des weiteren ist die Begrenzung auf 4 Props für zukünftige Erweiterungen eher hinderlich.
Wie kommst jetzt auf 4 Props? Weil ich evt. nur 4 Slots eingezeichnet habe?

Up's doch 8

Wie ich schon geschrieben habe eigentlich sind es bis zu 12. Aber wenn Die nicht reichen, dann weiß ich auch nicht weiter.

Dieser Bus ist ja auch schon vorhanden. Such mal nach "RS232 & P2P Bus".
Je nach dem wie man die Slaveboard jumpert, hat man entweder einen normalen TTL-RS232 Bus um mit dem Prop-Plug zu programmieren.
Oder in der anderen Jumperstellung einen Seriellen Prop-to-Prop (P2P)Bus (wie in http://hive-project.de/board/viewtopic.php?f=15&t=877
Angeschlossen wird er über P24, P30 und P31 (Heartbeat, TX und RX).

<-- das ist kein RS232 system und kein P2P das ist ein 1-Wire Netzwerk mit umlaufenden Statusbit.

Ok, nochmal um die Verwirrung zu lichten.
P30 und P31 sind normalerweise die Pins für TTL-RS232. Diese werden für die Firmware Programmierung gebraucht. Richtig?
So, nach der Programmierung und dem Abziehen des Prop-Plugs werden die Jumper auf der Karte wieder gesetzt.
Dann sind die Karten wie folgt verbunden. (die Pin-Zuordnung untereinander könnte noch angepasst werden)

Code: Alles auswählen

--->P31 P24--->P31 P24--->P31 P24-..>P31 P24--->zu Card1      Steuerleitung rotations Bit
     |   |      |   |      |   |  ..  |   |
     Card1      Card2      Card3  ..  Cardx
       |          |          |    ..    |
      P30        P30        P30   ..   P30
-------+----------+----------+----..----+---------------       Datenleitung 1-Wire

Das ist im Prinzip nichts anderes als was du vorgeschlagen hast, nur halt mit Pins, die nach der Programmierung nicht mehr gebraucht werden.
Und Prop-to-Prop Bus habe ich es genannt, weil für die Verwendung ein Propeller auf der Karte notwendig ist.

Die MMU und der Speicher sind nicht anderes als jeweils einer der oben angesprochenen 16 möglichen Busteilnehmer.

also willst du keinen Speicher auf Regnatix? und kann dieser auch von den Slaves angesprochen werden (DMA)?

Nur zu Klarstellung, der Speicher war niemals auf Regnatrix drauf, sondern höchstens an Regnatrix angeschlossen. Genauso wie gesamte Rest vom IO-Bus (Ich rede hier vom Originalhive).
Wie sieht denn ein Speicherzugriff aus?

• Reg setzt Adressport (AH)
  Reg schreibt auf Addresslatch (Puls auf ALE)
  Reg setzt Adressport (AL)
  Reg setzt Datenport
  Reg setzt /wr
  Reg schreibt auf Speicher (Puls auf RAM_x_enable)

Wobei die Unterscheidung zwischen Daten und Adressport für Regnatrix eigentlich unnötig ist.
Genauso gut kann man die beiden auf einen 16bit Port zusammenfassen.
(bzw. 19bit wenn man alle Adressleitungen nimmt)

Dann sähe ein Speicherzugriff so aus:

• Reg setzt Adresse auf Port (in 19bit)
  Reg schreibt auf Addresslatch (Puls auf ALE)
  Reg setzt Daten auf Port (in 16bit oder 8 bit)
  Reg setzt /wr
  Reg schreibt auf Speicher (Puls auf RAM_enable)

Ein Zugriff Slaveprop würde lediglich den Handshake zusätzlich haben.

PIC18F2550 hat geschrieben:
Bei so vielen Steuerleitungen kommt aber ein ganz schöner Verwaltungsaufwand auf dich zu.
Da ich nur 3 Leitungen verwende bleibt der Hardware aufwand sehr gering.
Naja, wenn du 5 Steuerleitung an denen ein 4-line to 16-line Demultiplexer hängt, aufwändig findest?

Ich meine nicht nur den Decoder sondern auch die Software die die Steuerung von den 8 Props unter einen Hut bringen muß.

Moment mal, grade eben sagtest du noch "Da ich nur 3 Leitungen verwende bleibt der Hardware aufwand sehr gering."??? Was denn nun? Hardware oder Software?
Egal, der Softwareaufwand sollte nicht größer sein als beim 1-Wirebus.

und nicht zu vergessen wenn gebraucht die /CS und /AB Steuerungen der Bustreiber.

Ich denke der Parallelbus hat hier Vorteile.

• eindeutige separate Chipselect Signale
  eindeutige Signale für die Datenrichtung (/wr)
  Bandbreite bei niedrigerem Bustakt
  separate Handshake Leitungen
  synchroner Bus möglich, da Taktsignal verfügbar

Beim 1-Wire Bus hingegen

• kein Chipselect, Busteilnehmer müssen sich Gegenseitig über dem Bus Adressieren
  der 1-Wire bus ist bidirektional ohne externes Datenrichtungssignal, Sektionierung ist ähnlich schwierig wie bei I²C
  hoher Bustakt für Bandbreite notwendig
  Handshake nur im Datenstrom möglich
  Asynchroner Bus

Die RTC ist ja auf entweder nur von Administra erreichbar.(Legacy-Kompatibel).
Oder Alternativ über das Arachneboard von jedem Hive aus erreichbar.

Oh Der RTC wird von verschiedenen Baugruppen benötigt z.B. SD-Karte, Regnatix, Netzwerk, .... und sollte deshalb von allen Props lesbar sein.

Siehe oben.
Wenn die RTC auf den I²C-Bus-D (Common) gejumpert ist, dann kann Arachne auf diese zugreifen.
Da Arachne gleichzeitig auch mit allen anderen I²C-Bussen verbunden ist, kann sie die RTC-Daten auch auf diesen Bussen anbieten, und dabei Zugriffskollisionen (wenn zwei Props zufällig gleichzeitig auf die RTC zugreifen wollen) abfangen. Wenn man will könnte man auch bsw. die RTC automatisch per DCF77 kompensieren oder ein vereinfachtes Datenformat für die Slaveprops anbieten.

Gedacht hatte ich mir einen PCF8574 "Remote 8-bit I/O expander" am Adm-I²C-Bus.
Dieser steuert ein paar P-Kanal-FET(Hi=FET leitend) und die Bustreiber an(Hi=Bus gesperrt).
Die Ausgänge des PCF8574 sind nach Power-on und Reset auf logisch 1, also in diesem Falle legacy-kompatibel.
Erst wenn eine erweiterte Administra Firmware eingreift, können Power abgeschaltet, oder die raus gehenden SPI-Busse zugeschaltet werden.

Wo willst du den Bus- sinnvoll trennen und wie willst du die Steuerkommunikation der Props aufrecht erhalten?

Ich denke hier ist wieder ein Missverständnis. Es hier um die SPI Busse.
Diese sind im Originalhive nur an Administra angeschlossen. Es gibt dort keine Prop nach Prop Kommunikation über SPI.
Es ging hierbei lediglich um das Abschalten der Stromversorgung für den Netzwerkchip und die SD-Karte. Sowie um die Abtrennung/Abschaltung der SPI-Busse zu Legacyzwecken.

Soll das alles über den Langsamen I2C Bus gehen?

Ich hoffe doch sehr, das du nicht der SD-Karte mehrere hundert Male pro Sekunden den Strom zuschalten und wieder abschalten willst

Da muß doch immer eine COG als slave laufen oder die I2C-Software muß im multimaster Modus laufen wenn mehrere Props den Bus Steuern sollen.

Administra steuert ihren I²C-Bus immer nur als Master an. Andere Props sind auf diesem Bus entweder nur als Slave (Arachne) oder gar nicht vorhanden.(Regnatrix, Bellatrix)
Einen COG als I²C Slave bereitzuhalten oder irgendwelche Multimastergeschichten anzufangen ist also unnötig. Nur bei Bedarf (beim Zu- und Abschalten von Komponenten auf dem Administra-Board) wird mal ein COG als I²C-Master benötigt.

http://www.conrad.de/ce/de/product/1557 ... ggest=true[/url]

Das ist SMD (So28) und damit nach Zielvorgaben tabu.

cu
Hauke

P.S.
Wow was für ein Monster Post

[PIC18F2550]

bereinigt.

[Hauke]

Arachne "simuliert" in diesem Falle sozusagen eine PS/2 Tastatur und eine PS/2 Maus. Bellatrix merkt Nichts davon, ob die Eingaben von einer echten Tastatur kommen oder von Arachne.

Warum quer über die Bords eine Verbindung ziehen und ein Emulator wenn allein durch änderung einer Nummer das selbe erreichen werden kann.
Das einzige was in Trios angepasst werden muss ist "reg-ios.spin".
Das die abgebuntenen Programme noch einmal neu Compiliert werden müssen ist dabei selbstverständlich.

Also so langsam weiß ich nicht mehr was du willst. Erst beschwerst du dich das man die Software anpassen muss weil ein Baustein wo anders ist, jetzt ist auf einmal kein Problem mehr.

Wenn ich dich richtig verstehe dienen die Bustreiber nur der Hardwarekonfiguration der verschiedenen Varianten und nicht dem dynamischen Signalaustausch der Komponenten.
(Hardwareanpassung)

Sorry, den Zusammenhang dieses Kommentars verstehe ich grad nicht.

Wie willst du den gleichzeitigen zugriff eines 2. Props verhindern und wie soll die Kommunikation zwischen diesen Aussehen

Also Regnatrix ist und bleibt Master auf dem IO-Bus. Die Slaveprops können lediglich auf einem der anderen Busse (idealerweise P2P) eine Anfrage an Regnatrix senden, damit Diese dann den IO-Bus freigibt.

Ich denke der Parallelbus hat hier Vorteile.

Über die Vorteile lässt sich streiten. Bedenke das der Bus im HIVE vom SPIN gesteuert wird und das die Ausführungszeit erheblich reduziert.
Das Absenden der Selectadresse ist schon beendet da ist SPIN noch gar kein Chip Ausgewählt.

??? Satzbau?
Du willst vermutlich folgendes damit sagen:
Den Ausgangszustand von 5 Pins einmal zu ändern dauert lang.

Und folgender Vorgang ist dagegen schnell.
- Zwei Pins ständig sampeln bis auf einem der beiden Busse ein Freigabetoken angekommen ist
(Dieses muss statistisch gesehen ja erst mal durch die Hälfte der Props durch)
-dann den Bus Reservieren (Sprich Ausgangstreiber aktivieren)
-und dann eine 8bit Datenwert mit Start und Stopbits Seriell per Software auf einem Pin ausgeben.
(das ganze mit einer begrenzten Datenrate damit die Samplerate auf dem empfangenden Prop nicht überschritten wird)

Sorry das glaub ich dir nicht, oder das ist extrem seltsam auf Spin programmiert

Des weiteren wenn der 8BitBus belegt ist kann keine weitere Anwendung darauf zugreifen.
Für Datenintensive systeme kann ein 2. Bus Aktiviert werden

Bei mir hast du auch zwei Busse per default: 8bit-IO und P2P.

eindeutige separate Chipselect Signale -> Chip/Karte kann dumm sein (einfacher Hardware /CS)
[eindeutige Treiberselect Adresse] -> Karte muss Eigenintelligenz mitbringen und den Bus aktiv abhören und analysieren

eindeutige Signale für die Datenrichtung (/wr) -> sind hilfreich für bidirektionale Bustreiber (für lange Busse mit vielen Teilnehmern)
[wozu ist doch alles open collector aufbau] -> elektrisches Busverhalten wird mit Jedem weiteren lauschenden Busteilnehmer schlechter. Teilnehmerzahl begrenzt Bustaktfrequenz oder umgekehrt.

Bandbreite bei niedrigerem Bustakt [PASM ist schneller als SPIN]
Das ist egal. Einen Pin 8 mal hin und her springen zu lassen dauert einfach länger aus eine 8bit breite Gruppe von Pins einmal hin oder her springen zu lassen. Da ist es egal ob du in Spin oder PASM progst.

separate Handshake Leitungen [wird nicht benötigt] -> Na ja irgendwie ist es schon von Vorteil wenn der Sender eine Rückmeldung bekommt ob sein Datenpaket angekommen ist oder ob der Empfänger grade besetzt ist.

synchroner Bus möglich, da Taktsignal verfügbar [Wo zu selbst bei sehr hohen übertragungsraten keine Lesefehler]
Was heißt hohe übertraqgungsrate? Alle 10 CPU Takte ein Datenbyte übertragen?

kein Chipselect, Busteilnehmer müssen sich Gegenseitig über dem Bus Adressieren [nicht busteilnehmer sondern Treiber] Das ist Haarspalterei, nehmen die Treiber etwa nicht an der Buskommunikation teil?

der 1-Wire bus ist bidirektional ohne externes Datenrichtungssignal, Sektionierung ist ähnlich schwierig wie bei I²C [wird nicht benötigt da 2 Bussysteme möglich] -> Das würde bedeuten das nicht-mehr jeder Prop für jeden anderen Prop erreichbar ist. Oder es müssten aufwändige Busbrücken eingebaut werden, welche dann wieder Flaschenhälse darstellen würden.
Evt. verstehst du es auch falsch. Es geht hierbei (Wie oben schon gesagt) nicht um eine Sektionierung um die Datenrate zu erhöhen, sondern darum, die elektrischen Leitungskapazitäten im einzelnen Segment zu begrenzen.
Jeder Ausgangstreiber kann halt nur so und so viele Eingangsstufen treiben. (Stichwort: Fan-out und Fan-in) Und hier gilt nun mal, wie oben schon gesagt, je höher die Frequenz desto ungünstiger ist dieses Verhältnis. Bis es dann irgenwann nur noch eine Point 2 Point Verbindung ist.

hoher Bustakt für Bandbreite notwendig -> [PASM ist schneller als SPIN] siehe oben
Handshake nur im Datenstrom möglich [Treiber werden wie call(Treibernummer)-ret Befehle aufgerufen wo ist da ein Handshake] -> siehe oben
Asynchroner Bus [kein nachteil] -> Bei Aynchronen Bussen ist eine höhere Anzahl von Samples pro Bit notwendig. Und bei gleichbleibender maximaler Samplefrequenz sinkt dadurch die mögliche Datenrate.

Übrigens syncronisiert der treiber den Datenstrom mit dem internen Takt von 80Mhz.Und da die Datenpackete maximal 1-256 bytes betragen passiert da noch nichts.
Auserdem kommt dann auch mal ein anderer an die Reihe (Multitaskbetrieb).

Trotzdem sind pro Bit mindestens 3-4 Sampletakte am Empfänger notwendig, um die Bits vernünftig auseinander halten zu können.
Weiterhin braucht man Startbits, Stopbits, Pausen oder andere Verfahren (wie MFM oder GCM) welche die Nettodatenrate verringern.

Arachne soll also den RTC auslesen und die Daten dann über I2C-Bus an die anderen weiterleiten wenn diese das wollen.? Ist das nicht etwas umständlich?

Alles in allem wird es dadurch ein wenig einfacher.
Ich vermeide dadurch das Regnatrix, Bellatrix und Administra I²C Multimasterfähig sein müssen (ist nicht ohne).
Arachne kann hingegen (als Slave) alle Drei gleichzeitig bedienen. Weiterhin könnten unterschiedliche RTC verwendet werden. Es braucht dann nur der Arachnecode angepasst zu werden. nicht alle drei anderen.

Warum die anderen Props als Slave auf dem I2C da must du ja einen COG-Verbraten der da mithorcht?

Es ist genau anders herum. Regnatrix, Bellatrix und Administra sind auf ihrem jeweiligen I²C Bus der alleinige Master. Also:
Regnatrix ist alleiniger Master auf I²C-Bus-A hat aber keinen Kontakt zu I²C-Bus-B, I²C-Bus-C und I²C-Bus-D
Bellatrix ist alleiniger Master auf I²C-Bus-B hat aber keinen Kontakt zu I²C-Bus-A, I²C-Bus-C und I²C-Bus-D
Administra ist alleiniger Master auf I²C-Bus-C hat aber keinen Kontakt zu I²C-Bus-A, I²C-Bus-B und I²C-Bus-D
So jetzt kommts:
Arachne ist Master auf I²C-Bus-D. Alles andere auf I²C-Bus-D ist Slave.
(Bitte beachten:Regnatrix, Bellatrix und Administra haben keinerlei Verbindung zu I²C-Bus-D)
Weiterhin ist Arachne Slave (und wirklich nur Slave) auf I²C-Bus-A, I²C-Bus-B und I²C-Bus-C
(Sollte die Notwendigkeit bestehen könnte aber auch ein Multimaster System auf I²C-Bus-D laufen)

Es wird also nur auf Arachne ein COG verbraten der mit horchen muss.

[TuxFan]

Moin moin!
Mit dem 10nS schnellen Speicherbausteinen hab ich gelogen meine Quelle hat keine mehr. Nur noch SMD.
Die 256-Farben-Geschichte gibt es hier : http://propellerpowered.com/forum/index.php?board=5.0
Mal ein bisschen in den Ressourcen (Links oben rechts auf der Seite) wühlen. Hab im Moment leider keine Zeit der Diskussion weiter intensiv zu folgen.
Gruß
TuxFan

[Hauke]

Moin moin!
Mit dem 10nS schnellen Speicherbausteinen hab ich gelogen meine Quelle hat keine mehr. Nur noch SMD.

Ok.
Es sei dir vergeben.
Dafür habe ich schnellen SRAM für die CLUT gefunden.
Das sind zwar leider 5V Typen, aber dafür alle in PDIP.

CY7C 164-15PC
16Kx4 S-RAM 15ns DIP22!
4,70€

CY7C 166-15PC
16Kx4 S-RAM 15ns DIP24.3
3,00€

CY7C185-20PXC
8kx8 SRAM 20ns 5V DIP28.3
3,40€

Lieferant Segor in Berlin
http://www.segor.de (sehr kompetenter Laden)

Und wenn ich mich jetzt nicht verrechnet habe, dann müsste folgende Sachen jeweils schnell genug sein:
die 20ns Typen sind ok bis
VESA 640x480@100Hz (43,16 MHz Pixeltakt)
VESA 768x576@ 75 Hz (45,51 MHz Pixeltakt)
SVGA 800x600@ 75 Hz (49,5 MHz Pixeltakt)
VESA 800x600@ 72 Hz (50,0 MHz Pixeltakt)

Die 15ns Typen gehen zusätzlich noch bis
VESA 768x576@100Hz (62,57 MHz Pixeltakt)
SXGA 800x600@ 85 Hz (56,25 MHz Pixeltakt)
XGA 1024x768@ 60 Hz (65,0 MHz Pixeltakt)
entnommen aus http://tinyvga.com/vga-timing

Das soll nicht heißen das Bellatrix die Auflösungen generieren kann.
Sondern nur, dass das CLUT-RAM für diese Auflösungen schnell genug wäre.

[PIC18F2550]

bereinigt.

[Hauke]

Also werden sie doch zum Busmaster? oder Senden Sie die Daten an den Busmaster damit er die dann in den RAM-Schreibt?

Also nochmal von Vorn. Quasi DMA von einem Slaveprop:

• Slaveprop signalisiert Regnatrix das er auf den Buszugreifen möchte. (Auf welchen Weg er dieses signalisiert ist hier noch egal)
  Regnatrix gibt Bus frei, und signalisiert das dem Prop.
  Slaveprop überträgt Zieladresse (RAM oder anderer Prop) direkt an MMU oder an Regnatrix.
  Regnatrix oder MMU selektieren das Ziel als wenn sie selber der Master wären
  Slaveprop ist jetzt Busmaster und steuert selber die Kommunikation mit dem Ziel
  Ab hier ist erst DMA, Regnatrix hat mit der eigentlichen Datenübertragung nicht mehr zu tun
  Slaveprop oder Regnatrix signalisieren das Ende des DMA Burst.
  Regnatrix ist wieder Busmaster

Ich glaub nicht das SPIN mit 19 PASM Befehlen ein Byte auf dem Bus übertragen kann.

...

OK devinitiv Fehlerhaft zusammengeschustert.
Das Absenden der Selectadresse ist schon beendet da ist in SPIN erst die Anforderung an den Slave auf dem Bus.

Code: Alles auswählen

{{Regnatix}}
  outa := M1                                            '/prop1=0, /wr=0, busclk=0
  dira := db_out                                        'datenbus auf ausgabe stellen
  outa[7..0] := c                                       'daten --> dbus
  outa[busclk] := 1                                     'busclk=1
  waitpeq(M4,M5,0)                                      '/hs=0?
  dira := db_in                                         'bus freigeben
  outa := M3                                            '/prop1=1, /wr=1, busclk=0

Code: Alles auswählen

{{Bellatrix}}
  outa := M2                                            '/prop1=0, /wr=1, busclk=1
  waitpeq(M4,M5,0)                                      'hs=0?
  wert := ina[7..0]                                     'daten einlesen
  outa := M3                                            '/prop1=1, /wr=1, busclk=0

Wieviele Takte sind das?

In ersterem Beispiel mindestens 30 Takte und im Zweiten mindestens 18 aber dein Vergleich hinkt, und das gewaltig.

Ne~e aller 800ns eins ca. 19 CPU Takte.
Praktisch 1MB/sec.

Ähm irgendwie komme ich da auf andere Ergebnisse.
Für 800ns bei 80 MHz komme ich auf 64 Takte, aber egal das soll mich nicht kratzen.

Wie ich oben schon sagte die Bedingungen unterscheiden sich völlig.
Im Parallel-Bus Beispiel hast du eine vollständige Übertragung eines einzelnen Bytes

• mit Adressierung/Auswahl des Empfängers
  Inbeschlagnahme des Busses
  Bestätigung dass das Byte angekommen ist
  und anschließender Freigabe des Busses

Bei deinem Rechenbeispiel mit 8,42MBaud oder ca 1MB/s hast du:

• nur die Übertragung eines Datenburst von vier Byte
  ohne den Empfänger zu adressieren/auszuwählen
  ohne Inbeschlagnahme des Busses
  ohne Bestätigung dass das Byte angekommen ist
  ohne anschließender Freigabe des Busses

Wollen wir mal unter gleichen Bedingungen vergleichen.
Es wird nur ein einziges Datenbyte seriell übertragen
- Dies dauert zusammen mit dem Overhead 1400ns.
- Da bleiben auf einmal nur noch 5,71 MBaud oder 0,71 MB/s übrig.
Aber Moment das ist ja noch nicht alles.
- Das ganze muss ja zweimal geschehen.
- Einmal um den Empfänger zu adressieren und einmal für das eigentlich Datenbyte.
- Also halbiert sich die Datenrate auf knapp 0,36MB/s.
Aber wollen wir mal nicht so sein.
Sagen wir mal die Adressierung und das Datenbyte können in einem Rutsch gesendet werden.
- Das wären 2200ns bzw. 3,64MBaud oder 0,455MB/s.

Und hierbei ist immer noch nicht die Wartezeit auf das Sende-Token mit dabei.
Oder die Inbeschlagnahme des Busses
Oder die Bestätigung dass das Byte angekommen ist
Oder die anschließender Freigabe des Busses

Unter vergleichbaren Bedingungen wirst du (je nach Teilnehmeranzahl im Token-Ring) für ein einzelnes Datenbyte vermutlich nicht über umgerechnet 250kB/s kommen.

Jetzt drehen wir mal den Spieß um:
In deinem zu oberst genannten Beispiel ging ja um die reine Übertragung eines Datenbursts von einem Longword, ohne Handshake, Adressierung und sonstigem Beiwerk.

Code: Alles auswählen

{{Regnatix}}
  outa[7..0] := c                                       'daten --> dbus
  outa[busclk] := 1                                     'busclk=1
  waitpeq(M4,M5,0)                                      '/hs=0?
  outa[7..0] := c                                       'daten --> dbus
  outa[busclk] := 0                                     'busclk=0           (DDR verfahren)
  waitpeq(M4,M5,1)                                      '/hs=1?
  outa[7..0] := c                                       'daten --> dbus
  outa[busclk] := 1                                     'busclk=1
  waitpeq(M4,M5,0)                                      '/hs=0?
  outa[7..0] := c                                       'daten --> dbus
  outa[busclk] := 0                                     'busclk=0
  waitpeq(M4,M5,1)                                      '/hs=1?
 

Zusammen 56 Takte oder 700ns (bei 80MHz) = 45,7MBaud oder knapp 5,71MB/s
Wenn man dann noch davon ausgeht, das auf dem Slaveprop ein COG ständig auf hereinkommende Kommunikation lauscht (wie auch auf dem 1-Wirebus notwendig) dann könnte man alle "waitpeg" bis auf das Erste weglassen.
Es blieben dann nur noch 38 Takte. Das ergibt 475ns (für 32bit) bzw. 67,3Mbaud bzw. 8,42MB/s
Aber letzteres würde ich für sehr übertrieben und unsicher ansehen.
Da sieht die serielle Datenübertragung kein Land gegen.

Bustereiber die gesteuert werden müssen gibt es nicht. Wenn die Last am Ausgang zu groß wird, wird txt und rxt auf verschiedene Pins gelegt

Also sind wir jetzt schon bei 4 Pins Pro Kanal.

Hinter dem Stop-Bit sendet der Empfänger ein L-Bit zur Bestätigung.
Alle Busteilnehmer Lesen am BUS Paralel mit und nur der richtige Quittiert. Damit ist das System syncron.

Du verstehst offensichtlich nicht was mit einem synchronen System gemeint ist.

Es wird also nur auf Arachne ein COG verbraten der mit horchen muss.

Also eine COG die 3Slaves gleichzeitig beinhaltet. Sowas hatte ich schonmal gesucht.

Es ist nur ein ein Slave gleichzeitig bearbeitet werden.
Selbst auf einem Multimaster I²C System kann immer nur einer gleichzeitig kommunizieren. Die anderen potentiellen Master habe zu warten bis der Bus wieder frei ist.

Es sol so laufen:
Der COG lauscht lediglich auf den drei Bussen auf die Start Bedingung
Wenn eine Startbedingung erkannt wird, dann wird das Lauschen auf die anderen Busse eingestellt.

entweder
eine der eigenen Adressen wird erkannt, Kommunikation startet
Anfragen von den anderen beiden Bussen werden mit einem nAck auf Diesen ignoriert.
Nach Ende der Kommunikation per Stop Bedingung wird das Lauschen auf die anderen Busse wieder fortgeführt.

oder
es wird keine der Eigenen Adressen erkannt
es wird kein Ack auf die Adresse erkannt
COG lauscht wieder auf allen drei Bussen auf die Start Bedingung

oder
es wird keine der Eigenen Adressen erkannt
es wird ein Ack auf die Adresse erkannt
dieser Bus wird als in Gebrauch markiert
auf diesem Bus wird alles ignoriert bis eine Stop Bedingung auftritt.
auf den anderen beiden Bussen wird weiter auf eine Start Bedingung gelauscht.

[PIC18F2550]

bereinigt.

[Hauke]

Leider vergist du eins das was du Adresse nennst ist bereits der Befehl und der beträgt bei mir 16Bit das entspräche 65535 Call Ziele.

Dein ach so einfache System wird von mal zu mal komplizierter. Und egal wie du Befehl und Adressat mit ein einander verquirlst, das Übertragen der Adresse des Kommunikationsziels geht von deiner Bandbreite ab.

Das hatte ich schon vorher erläutert.

Wo?

Anscheinent hast du vergessen das ich unter beachtung der Hartware jeden Prop Jeden Treiber aufspielen kann.

Und was soll dir das bringen wenn du nicht x mal die Gleiche Karte einbauen willst?

Dein DMA sieht bei mir ganz einfach aus.
Irgend ein PROP sendet den 16Bit-Befehl DMA von Treiber $243 nach Treiber $FE0.
Da die beiden Treiber beide den Befehl mitlesen wissen sie anhand des Befehles was zu machen ist.

Ein dritter Prop sagt zwei anderen was sie zu tun haben. Aha. Und was bringt das?

Code: Alles auswählen

Aufbau BYTE-Strucktur
Bef    Arg.1  Arg.2  Arg.3  Arg.4  Arg.5
0FFA   0243   0FE0   0000   0000   07FF   entspricht Umladen des gesamten hRam-Speichers.

Da du so auf die zusätzlichen Funktionen pochst rechne doch mal dein Verwaltungsaufwand mit hinein.
Während dein System noch untersucht ob es weitere Daten empfangen muss, werden bei mir die nächsten Daten schon gepuffert.
Die gesamte Puffer, Multiplexer und Adressverwaltung gibt es bei mir nicht

Ahh. Dann hast du also anscheinend RAM Bausteine mit eingebautem 1-Wirebus. Schön für dich.

Du vergleichst Birnen mit Äpfel.

Brauche ich nicht, das machst du ja schon.

Ich kann mit einem Befehl komplexe Abläufe über mehrere COGs in völlig verschiedenen Props steuern. Das ist ein hoch flexiebeles system.

Ich würde es eher höchst unübersichtlich nennen.

Overhead? ich starte keinen extracog oder beende diesen nach der Übertragung auch nicht, das währe eine Katastrophe!

Den Begriff Overhead wurde in der Beschreibung der seriellen Verbindung genannt, und meint die Zeit welche nicht mit der Übertragung von Nutzdaten verbracht wird. Und von einem Abschalten und Zuschalten von COGs habe ich nie geredet. Ich meinte das Umschalten der Treiberbausteine (im Prop) vom Lese in den Schreibbetrieb und umgekehrt. (welches in deinem Codebeispiel auch in die Zeitberechnung einfloss)quote]Das Sende-Token rottiert bei freien Bus mit ungefähr 1Mhz bei 4 Props.[/quote]
Du meinst bei nur vier Cogs am Bus. Bissl wenig.

Ich weis ja nicht wie du auf Zusammen 56 Takte oder 700ns (bei 80MHz) = 45,7MBaud oder knapp 5,71MB/s kommst?
(80Mhz/56=1,42MB)

56 Takte für die Übertagung von einem Longword.
Also 80MHz/56*4Byte=5991862Byte/s oder wie gesagt ca. 5,71MB/s

Soviel wie ich weis ist der zugriff eines COGs auf den hRam wo der Spinn Code liegt zwischen 7...22 Takte lang und selbst wenn der Spinnbefehl im günstisten Fall nur 7 takte bräuchte währen es immernoch 12x7 = 84 Takte = 0,952MBit und im ungünstisten Fall 12x22 = 264 Takte = 0,303Mbit

Wer redet denn von hRAM ??? Und wie kommst du auf Mbit/s??? Offensichtlich kannst du nicht Longword in Byte oder in Bit umrechnen.

Lach dich doch lieber selber aus.

hattest du nicht 4x I2C-BUS vorgesehen?

Du willst mich offensichtlich nur falsch verstehen.
Drei Busse auf den Arachne nur Slave sein kann, und einen eigenen Bus auf dem Sie Master ist.

Sollte nicht

Arachne kann hingegen (als Slave) alle Drei gleichzeitig bedienen.

Ok das "Gleichzeitig" war eine unglückliche Wortwahl.

Aber das kann er nur wenn er an ihren I2C bus als slave Teilnimmt?
1 slave = 1 Bus und wo bleibt der rest?
Das erkennen der eigenen Adresse bedarf doch schon einer I2C kommunikation und Schlimmstenfalls muß er 2 gleichzeitig bedienen.

Eine Start-Bedingung kommt auf einem der drei Busse, auf denen Arachne Slave sein kann, an.
Die Slave Routine prüft ob auf diesem Bus die eigene Adresse kommt. Die anderen Busse werden solange ignoriert, oder (sofern frei, per SCL geblockt).
Da ist Nichts mit "zwei gleichzeitig bedienen". Arachne ist auf den I²C-Bussen A-C ein einfacher Slave. Und Slaves können eine Nichtbereitschaft einfach dadurch anzeigen, das sie kein Ack senden.

So langsam bin ich echt genervt.
PIC, es kommt mir so vor, dass du aus Prinzip gegen alles bist was andere an Ideen vorbringen.
Alles muss exakt so werden wie du es möchtest. Ich bin dir, mit dem Einbau des P2P Busses, entgegen gekommen (welcher exakt deinem 1-Wire Bus entspricht).
Aber du vertrittst anscheinend den Standpunkt, dass es keine anderen Systemlayouts als dein eigenes geben darf. Ideen werden tot geredet. Statt konstruktiven Beiträgen gibt es von dir nur noch destruktives herum kritteln.

Da ich auf diesen Scheiß schlichtweg keine Lust mehr habe, ziehe ich mich nun hiermit offiziell aus diesem Thread zurück. Interresenten an meinen Ideen möchten mich bitte per PM anschreiben.

Herzlichen Glückwunsch PIC. Du hast wahrscheinlich diesen Thread und damit das Projekt Modul-Hive getötet. Du kannst jetzt meinetwegen alleine weitermachen.

P.S.
Es wäre echt Rücksichtsvoll von dir PIC, wenn du mal ein winziges Bisschen auf Rechtschreibung achten würdest.

An alle anderen
cu
macht es gut
bis dann
Hauke