- 12V Akku mit 280 Ah bauen         
Ergebnis 1 bis 10 von 66

Thema: RAM-Baustein

Hybrid-Darstellung

Vorheriger Beitrag Vorheriger Beitrag   Nächster Beitrag Nächster Beitrag
  1. #1
    Erfahrener Benutzer Robotik Einstein
    Registriert seit
    18.03.2018
    Beiträge
    2.650
    Dass man Bits einzeln übertragen kann, über zwei Leitungen ist mir auch klar. Das Prinzip ist ja auch dasselbe, wenn ich 8 Bit auf den Datenbus gebe und ein Signal sende, dass die Daten bereit stehen. Daraufhin bekomme ich eine Quittierung, ob sie abgeholt wurden. Man kann das auch stur nach Zeit machen, wenn man weiß in der Zeit schafft es die Gegenstelle die Daten abzuholen. Bis zu einer gewissen Taktrate, die hardwareabhängig ist, funktioniert das dann sogar. Aber hier ist es etwas anders. Ich muss jederzeit sichergehen, dass die Kommunikation einwandfrei verläuft. Weil ich hantiere ja hier mit mehreren Mikrokontrollern, die sich synchronisieren müssen.

    Was ich mit Nettodatenrate meine ist: Die Daten kommen von egal woher. Aber um sie im Programm zu verwerten, muss man sie auch irgendwo abholen. Sie kommen zunächst in einem Puffer (SPI oder was anderes) an. Da muss ich prüfen, ist was im Puffer? - Ja, dann nimm das Byte raus und gib es zur Verarbeitung zum Programmcode zurück, der das Byte angefordert hat. Dieser Vorgang dauert ja auch Zeit, weil mit bestimmten Befehlen verbunden. Problem jetzt: ist die Schnittstelle schneller, als das Programm die Daten aus dem Puffer abholen kann, habe ich dort den Flaschenhals. Einerseits habe ich zwar eine enorme Übertragungsgeschwindigkeit, aber andererseits nur eine beschränkte Verarbeitungsgeschwindigkeit. Ich habe bspw. 8 Operationen inkl. Portzugriffe, je 8 Bit, Brutto, um zwei Byte Netto zu übertragen. Wenn mir das mit 125000Word/s gelingt, sind das theor. etwa 1MByte/s Brutto, die tatsächlich übertragen werden. Das ist auf jeden Fall schwierig zu ermitteln (weil bei der Ausführung der Software noch Unbekannte dabei sind - wie Unterbrechungen für Sachen die der Kontroller nebenbei noch tut: Interrupts, Zähler behandeln ..) und da muss man irgendwann mal das Endergebnis realistisch betrachten und nachmessen wie lange dann große Datenmengen zur Übertragung benötigen. Aber zum Abschätzen, auf was man da hinarbeitet - mit dem Konzept, finde ich es wichtig, dass man das ab und an reflektiert, was da überhaupt möglich ist oder wäre und wie man mit den Hindernissen umgeht.

    Das Konzept mit der SPI-Schnittstelle ist auf jeden Fall bestens, wenn es darum geht, eine bekannte Menge Daten auszulagern und wiederzuholen. Ohne dass man die verfügbare Menge ext. Speicher überschreitet.

    Ein Problem entsteht dann, wenn die Datenmengen unbekannt sind. Bzw. wenn die Datenmenge auf ein nicht vorher bestimmbares Maß anwachsen kann, wobei man sicher weiß, dass gewisse Größenordnungen (1GB) auch wieder nicht überschritten werden. In solchen Fällen ist immer gut, wenn man davon ausgehen darf, dass man "unbegrenzt" Speicher zur Verfügung hat. Zur Not eben durch Auslagerung. Das dauert zwar sehr viel länger, aber bringt nicht den Verarbeitungsprozess zum Erliegen.
    Zurzeit kann ich noch gar nicht abschätzen, ob ich SPI sinnvoll einsetzen könnte. In der ersten Überlegung ja - könnte das Adressieren des Speichers vereinfachen. Ich kenne nur noch nicht alle Schwächen meines Konzepts, weil ich mit der Programmierung noch nicht fertig bin. Evtl. gibt es da auch gar keine. Ich habe einen Kontroller, der sich um den Speicher kümmert. Einen Weiteren, der die SD-Karte bedient. Drum herum habe ich D-Latches zur Abgrenzung zwischen dem Kontroller der Daten verarbeitet (Sender) und den anderen beiden (Empfänger), die sich um die Beschaffung etc. kümmern. Sender und Empfänger laufen in gewissen Grenzen asynchron und können das auch mit unterschiedlichen Geschwindigkeiten. Hat der Sender Daten zum Speichern abgegeben, dann nehmen die Empfänger das entgegen und der Sender macht sich auf den Weg, weitere Daten zu holen. Während dieser Zeit können die Empfänger die abgegebenen Daten verarbeiten (speichern). Beim Lesen dasselbe Prinzip in andere Richtung. Einige Verarbeitungszyklen laufen damit parallel, bei Sender und Empfänger und kosten damit keine zusätzliche Zeit. Vorgänge werden damit zeitlich verkürzt - so die Idee. Jede Datenverarbeitung kann man auch nur zu einem gewissen Teil parallelisieren, weil manche Vorgänge einfach nacheinander stattfinden müssen, weil voneinander abhängig.

    MfG
    Geändert von Moppi (05.10.2018 um 05:39 Uhr)

  2. #2
    Erfahrener Benutzer Robotik Einstein Avatar von Searcher
    Registriert seit
    07.06.2009
    Ort
    NRW
    Beiträge
    1.715
    Blog-Einträge
    133
    Zitat Zitat von Moppi Beitrag anzeigen
    ...
    Das übersteigt meine Ambitionen dann doch etwas Inzwischen habe ich aber noch eine Teilaufgabe für mich entdeckt, die ich mir nochmal ansehen möchte. Die USART kann beim Mega88 (Mega328 ) auch als SPI Schnittstelle verwendet werden.

    Da im Gegensatz zur SPI von double Buffer beim Transmitter geschrieben wird: Geht der schneller?
    Kann man den parallel zur "normalen" SPI-Schnittstelle betreiben und hat man dann zwei SPI Schnittstelle mit schneller Übertragung zur Verfügung? Je schneller die Daten übertragen sind, desto mehr Zeit gibt es für andere Dinge.

    Bin neugierig, wie es bei Dir weitergeht und vielleicht schreibst Du irgendwann mal, was es geworden ist oder was es mal werden sollte.

    Gruß
    Searcher
    Hoffentlich liegt das Ziel auch am Weg
    ..................................................................Der Weg zu einigen meiner Konstruktionen

  3. #3
    Erfahrener Benutzer Robotik Einstein
    Registriert seit
    18.03.2018
    Beiträge
    2.650
    Zurzeit brauche ich ewig für ein paar Codezeilen. Ich hab's gerade mal durchgezählt. Ohne RAM sind es 8 Steuersignale, mit denen die gesamte Beschaltungslogik koordiniert wird. Viele laufen immer über ein Byte, also einen Port. Vertue ich mich irgendwo mit einem Bit, kann es passieren, dass ich Ausgang auf Ausgang schalte oder Daten nicht rüberkommen, weil D-Latch-Ausgänge deaktiviert sind. Echte Gehirnakrobatik, zu jedem Zeitpunkt bei der Programmierung zu wissen, in welchem Zustand die Schaltung sich gerade befindet.

    Na was es werden soll, ist Datenverarbeitung. Ich hatte schon geschrieben, dass ich mich von der Softwareebene (hier ist das vornehmlich Javascript und PHP) lösen möchte. Daten lesen, verarbeiten, Daten schreiben, Daten verändern (Stringoperationen allgemein, z.B.: indexOf, replace, split), Daten vergleichen. In Größenordnungen bis einige Megabyte. Um es kurz und knapp zu beschreiben: Assistenz in der Datenverarbeitung. Oder: softwarebasierte Assistenten.

    Ich habe schon überlegt, ob es dann nicht sinnvoll ist ein extra Board zu bauen und hiermit eine Basis für die Integration mehrerer (vieler) Kontroller zu schaffen. Ich würde das vielleicht Borg Board nennen. Angelehnt an die bekannte Serie. So: erweitere einen bestehenden Verbund durch Assimilation weiterer Kontroller und/oder Speicher und mache ihn damit leistungsfähiger. - na ja, visionär

    MfG
    Geändert von Moppi (05.10.2018 um 09:42 Uhr)

  4. #4
    Erfahrener Benutzer Robotik Einstein Avatar von Searcher
    Registriert seit
    07.06.2009
    Ort
    NRW
    Beiträge
    1.715
    Blog-Einträge
    133
    Zitat Zitat von Searcher Beitrag anzeigen
    Da im Gegensatz zur SPI von double Buffer beim Transmitter geschrieben wird: Geht der schneller?
    Ich mußte mich doch noch an dem USART als SPI-Master im Mega88 versuchen.

    Hab die ASM Initialisierungs- und Datensendebeispiele aus dem Datenblatt angepaßt und drei Bytes in 7,7µs, also knapp 400000 Bytes/s bei 8MHz Systemtakt abschicken können. Gemessen mit Oszi an dem, zusätzlich in die ASM-Routinen aufgenommenen SS Pin.

    Auch der Master SPI-Takt am USART läßt sich auf halben Systemtakt einstellen indem man nur im Register UCSR0A das U2X0 Bit setzt. Der Geschwindigkeitsvorteil gegenüber der, ich nenn sie mal nativen HW SPI Schnittstelle kommt durch das "double buffering". Beim USART kann das Senderegister schon neu beschrieben werden während das vorhergehende byte noch rausgetaktet wird. Beim nativen SPI muß gewartet werden, bis das byte rausgetaktet wurde. Im Oszillogramm tauchen beim nativen SPI Pausen im Takt zwischen den gesendeten Bytes auf, die es beim USART nicht gibt.

    Die Entgegennahme der Daten in den 74HC595 stellt kein Problem dar. Vermutlich eher die Bereitstellung der Daten aus der Anwendung heraus. Wenn man die native HW-SPI auch noch parallel betreibt dürfte das den Flaschenhals doch noch relativ enger machen

    Gruß
    Searcher
    Hoffentlich liegt das Ziel auch am Weg
    ..................................................................Der Weg zu einigen meiner Konstruktionen

  5. #5
    Erfahrener Benutzer Robotik Einstein
    Registriert seit
    18.03.2018
    Beiträge
    2.650
    Den Flaschenkörper nicht so groß wählen, der Inhalt muss dann alles durch den engen Hals!

    --------------------------------------------------------------------------
    Nachtrag:

    Nachdem ich einiges an meiner Schaltung durchprobiert habe, habe ich gedacht, ich kann es hier mal mit reinstellen, nachdem wir schon so viel darüber geschrieben haben. Funktionell ist es wohl fehlerfrei. Die Notizen zum Komm.-Protokoll: ändert sich während der Programmierung, das war nur ein erster Anhaltspunkt - aber so in etwa geht es.

    Klicke auf die Grafik für eine größere Ansicht

Name:	RAM Plan 4.jpg
Hits:	11
Größe:	84,5 KB
ID:	33684
    Klicke auf die Grafik für eine größere Ansicht

Name:	Plan 4 ICs.jpg
Hits:	6
Größe:	66,1 KB
ID:	33685

    MfG
    Miniaturansichten angehängter Grafiken Miniaturansichten angehängter Grafiken Temp Plan.jpg  
    Geändert von Moppi (07.10.2018 um 20:38 Uhr)

  6. #6
    Zitat Zitat von Moppi Beitrag anzeigen
    Den Flaschenkörper nicht so groß wählen, der Inhalt muss dann alles durch den engen Hals!

    --------------------------------------------------------------------------
    Nachtrag:

    Nachdem ich einiges an meiner Schaltung durchprobiert habe, habe ich gedacht, ich kann es hier mal mit reinstellen, nachdem wir schon so viel darüber geschrieben haben. Funktionell ist es wohl fehlerfrei. Die Notizen zum Komm.-Protokoll: ändert sich während der Programmierung, das war nur ein erster Anhaltspunkt - aber so in etwa geht es.

    Klicke auf die Grafik für eine größere Ansicht

Name:	RAM Plan 4.jpg
Hits:	11
Größe:	84,5 KB
ID:	33684
    Klicke auf die Grafik für eine größere Ansicht

Name:	Plan 4 ICs.jpg
Hits:	6
Größe:	66,1 KB
ID:	33685

    MfG
    Interssanter Schaltplan.

  7. #7
    Erfahrener Benutzer Robotik Einstein
    Registriert seit
    18.03.2018
    Beiträge
    2.650
    Da gab's drei Modi, für Mode A + B: 0+0 = Adressieren, 0+1 = Lesen, 1+0 Schreiben, 1+1 = Bestätigung/Quitt.

    Obwohl, den gab es nochmal anders:

    Klicke auf die Grafik für eine größere Ansicht

Name:	RAM Plan 5.jpg
Hits:	3
Größe:	98,4 KB
ID:	33721

Ähnliche Themen

  1. PLL Baustein 4046
    Von hacker im Forum Elektronik
    Antworten: 41
    Letzter Beitrag: 14.01.2009, 15:14
  2. LED Matrix Baustein
    Von karlmonster im Forum Elektronik
    Antworten: 3
    Letzter Beitrag: 07.04.2008, 19:57
  3. Suche RAM Baustein
    Von robin im Forum Elektronik
    Antworten: 10
    Letzter Beitrag: 02.01.2008, 23:16
  4. Baustein zur Echtzeitübertragung
    Von chrisse 7 im Forum Elektronik
    Antworten: 30
    Letzter Beitrag: 11.01.2006, 16:41
  5. WAS ZUM "§$?`* ist das für ein baustein ?
    Von Roll_. im Forum Elektronik
    Antworten: 4
    Letzter Beitrag: 02.09.2005, 07:57

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •  

fchao-Sinus-Wechselrichter AliExpress