Archiv verlassen und diese Seite im Standarddesign anzeigen : RAM-Baustein
Hallo,
ich suche nach RAM, der sich mit jeder beliebigen Taktrate steuern lässt. Es gibt verschieden RAM-Typen. Bausteine, die mit 133MHz betrieben werden. Manche benötigen den Takt glaub ich auch, um in regelmäßigen Abständen die Speicherzellen aufzufrischen. Dann wäre die richtige Taktfrequenz u.U. auch wichtig. So genau blicke ich da irgendwie noch nicht durch. Jedenfalls müsste es ein RAM sein, dass sich auch in Zeitlupe Lesen und Beschreiben lässt. Ich weiß auch noch nicht, ob so ein RAM dann mehrere Clock-Eingänge hat. Meinetwegen einer zum Auffrischen und einer zum Schreiben/Lesen. Was ich schon gefunden habe, ist statisches RAM. Allerdings mit einer Max-Größe von 512kB. Ein Megabyte könnte man mit 2*512kByte erreichen. 2 Mbyte mit 4 solchen Bausteinen. Ab Größe 1 GByte habe ich was Vergleichbares nicht gefunden. Da geht es dann gleich mit PC-Speicherriegeln weiter. Das würde mich auch zunächst, zum Probieren, nicht stören. Bloß weiß ich nicht, wie man diese Teile genau ansteuert und welche Zusatzbeschaltung die brauchen. In dieser Sphäre bin ich basteltechnisch noch nicht unterwegs gewesen. Deshalb ist das die Herausforderung.
Vielleicht kann mir jemand Tips geben?
SD-Karte habe ich in Betracht gezogen, wäre aber glaube ich vergleichsweise langsam, weil man Daten nur seriell lesen/schreiben kann. Und anfälliger für Ausfälle. Kann mich auch täuschen und die Datenrate wäre vergleichsweise identisch, von SD-Karte zu extern angeschlossenem RAM (weil das auch in mehreren Taktzyklen angesteuert werden müsste). Wenn das Adressieren eines externen RAM, mit einem Controller, zu lange dauern würde (begrenzte I/O-Kanäle), könnte man noch mehrere Controller parallel betreiben, die dann gemeinsam das RAM ansteuern.
Gruß, Moppi
Nach langem Suchen habe ich mich nun erst einmal zu 512 KB statischem RAM durchgerungen, der kein Taktsignal benötigt. 1 MB wäre auch noch möglich gewesen, als TSOP II-Ausführung. Weil ich dafür aber zunächst eine Adapter-Platine benötige, die für sich schon teurer war, als der RAM-Baustein, komme ich bei 2 x 512 KB zunächst günstiger weg; zumal das dann normales Lochrastermaß ist und so auch auf einem Bread Board verstöpselt werden kann.
Die Antwort auf deine Frage kann man nur beantworten: Was für einen Controller hast du und mit welcher Datenrate/ Latenz willst du schreiben. Dazu kommt dann noch: Wie viele Daten willst du schreiben.
Wie du selbst festgestellt hast: Wenn du keinen Takt verwenden willst brauchst du dazu SRAM. Bei DRam brauchst du einen Takt. Kannst du aber ganz gut auf Wikipedia nachlesen.
Für beide Typen gibt es z.B. bei ARM Controllern häufig spezielle Hardware Einheiten um den Speicher anzusprechen und direkt in den normalen Speicherbereich reinzumappen. Allerdings gibt es dort auch für SD Karten HIghspeed interfaces. (SD Karten unterstützen in der Regel zum einen ein Interface via SPI, und ein Highspeed Interface mit mehreren Datenleitungen).
Sobald du aber Hohedatenraten erreichen willst ( = Hoher Takt) wirst du nicht um ein richtiges Layout drum herumkommen. Das kann unter Umständen auch gar nicht so einfach sein.
In dieser Sphäre bin ich basteltechnisch noch nicht unterwegs gewesen. Deshalb ist das die Herausforderung.
Vielleicht kann mir jemand Tips geben?
Vergiss es. Das ist mein Tip.
Basteltechnisch bewegt sich da gar nichts. Selbst die wirklich uralten (so 40 Jahre her) 64k*1 dynamischen RAMs waren eine Herausforderung und erforderten einen erfahrenen Hardwareentwickler. Heutige SD-RAMs sind High-Speed Design. Da gehts z.B. um Leiterbahnen mit kontrollierter Länge, vierlagiges Design etc. Und die kann man nicht so einfach irgendwo dran hängen. Dazu braucht man einen passenden Controller, der in manchen Prozessoren schon eingebaut ist. Von der erforderlichen Messtechnik um auftretende Probleme zu finden und zu beseitigen will ich gar nicht reden.
MfG Klebwax
Was für einen Controller hast du und mit welcher Datenrate/ Latenz willst du schreiben. Dazu kommt dann noch: Wie viele Daten willst du schreiben.
Zunächst habe ich den Arduino Uno, Atmega328. Über SPI könnten das max. 8 MHz sein für die Schnittstelle - denke ich. Lesen und Schreiben: 8 Bit.
Das/die Schieberegister bekommen den vollen Takt ab, der Speicher nur noch max. ein 24tel, weil ja erst alle Adressbits übertragen sein müssen. Der Speicher wird parallel adressiert und geschrieben bzw. gelesen. Die Schieberegister würden min. 20MHz vertragen., wenn sie mit 4.5V betrieben werden.
Na mal schauen....
Der Speicher ist angekommen. Nun kann's ans Probieren gehen.
Searcher
21.09.2018, 13:06
Der Speicher ist angekommen. Nun kann's ans Probieren gehen.
Hallo,
wie heißt er denn?
Gruß
Searcher
habe jetzt auch mehr RAM und Flash:
512 KB flash, 192 KB RAM
auf einem ARM Cortex M4: Adafruit Feather M4 für Arduino IDE, 120MHz mit single-fpu 8)
Preis 23 EUR, was auch nicht die Welt ist.
Aber mannomann, was ein Geschoss! :shock:
Ganz abgesehen vom Programm- und Variablenspeicher, auch die Rechenleistung ist immens:
int und double sind hier schon irre schnell, aber float schießt echt den Vogel ab!
Der Feather M4 hat etwa Nano-Größe, gibts aber auch etwa wie Micro (Itsybitsy M4) und auch wie Uno-Board-Größe (Metro M4).
Da lohnt sich der Speicher! 8)
:cool: So. Funktionieren tut das jetzt mit dem Speicher, am Arduino. Adressierung über Schieberegister 74595. Da sich der Uno bzw. ATmega328P-PU mit 20 I/O-Leitungen konfigurieren lässt, habe ich jetzt parallele Dateneingabe realisiert und kann die Geschwindigkeit bei der Adressierung noch etwa verdoppeln, indem ich jedes Schieberegister extra mit Daten beschicke. So kann man die Daten an 3 Registern gleichzeitig anlegen und muss insgesamt nur neun mal takten, um die 19 Bit-Adressdaten am Ausgang zu haben. Das Schieben der Adressbits über die 74595 nimmt mit am meisten Zeit in Anspruch. Leider muss man beim Verknüddeln der Leitungen höllisch aufpassen. Trotzdem ich mir sehr viel Mühe gab, habe ich dennoch zwei benachbarte Steuerleitungen am CMOS-RAM vertauscht, was zu unerwartetem, nicht erklärbaren Verhalten führte. Aber sonst funktioniert das ganz respektierlich, bis jetzt - letzter Stand - problemlos.
kannst du auf deinem Speicher dann Variablen zwischenspeichern und damit int-, float-, shift- und sort-Rechenoperationen durchführen, so als wären diese Variablen im "normalen" RAM abgelegt, insb. dann, wenn das on-board-RAM mit anderen Dingen bereits belegt ist?
Und wie sieht es mit Programm-Code aus?
Die Anforderung ist ein Bussystem, an das mehrere Kontroller angebunden sind. Einer schaufelt Daten in einen Zwischenspeicher, die andern Kontroller bearbeiten die Daten gemeinsam und möglichst gleichzeitig. Die Ergebnisse sollen möglichst wieder in einem Zwischenspeicher abgelegt werden. Da ich noch 5 Datenleitungen übrig habe, könnte ich theor. 31 x 512KB Speicher-Module installieren. Ich hätte auch noch eine sechste Datenleitung, das wären dann theor. 63 RAM-Module oder bis 31MB Speicher. Wenn ich die übrigen 5 Adressleitungen einfach verwende, könnte man auf 5 Module zurückgreifen, oder 2.5MB Speicher.
Programmcode ist fest in den Kontrollern hinterlegt.
Ich suche aber noch, wie ich das tatsächlich umsetzen will und letztlich muss (richtet sich nach den Möglichkeiten). Der RAM war der erste Schritt dazu. Weil ich eigentlich Speicher bräuchte, den ich ständig beschreiben kann, ohne dass der nach ein paar Wochen Schaden nimmt und ausfällt.
ach soooo....! RAM Baustein klang für mich so als wenn du deinen Arbeitsspeicher (Rechen-, Programmspeicher) für einen kleinen AVR Arduino aufrüsten willst, daher mein Vorschlag, doch gleich einen leistungsfähigeren ARM Arduino mit von vornherein mehr RAM und Flash zu verwenden, ganz abgesehen von der vielfach größeren Rechenleistung.
Aber als Pufferspeicher für ein Netzwerk - das ist ntl was anderes... 8)
Was wäre eigentlich besser zu handhaben, sicherer in der Kommunkiktion und schneller: I2C-Bus oder die asynchrone serielle Schnittstelle?
Oha, da habe ich was gefunden: https://tronixstuff.com/2010/10/20/tutorial-arduino-and-the-i2c-bus/
UART ist schneller als i2c bei gleichem Bustakt, da bei i2c u.a. für die Daten immer noch zusätzlich Schreibaktionen für die Adressierug des/der Slaves nötig ist. Außerdem arbeitet i2c immer nur in 1 Richtung, also quasi half-duplex; UART kann hingegen prinzipiell full-duplex.
Weiterhin sind die Message-Puffer begrenzt, bei Arduino für i2c auf 32 Bytes, bei UART auf 64bytes, was für UART ebenfalls vorteilhafter ist.
Aber nicht alle Taktraten sind immer beiderseits möglich, so wird z.B. nicht überall ein hoher synchroner UART Takt von z.B. 400kHz-1MHz zwischen verschiedenen Geräten erreicht, und wenn auch meist 400kHz (full-speed) i2c Takt möglich ist, gilt dies auch nicht überall auf allen Plattformen auch für 1Mbit/s (Fast i2c) oder 3,2 Mbit/s (Highspeed I2C).
Die ARM-Prozessoren können z.B. locker Fast-i2c mit 1MHz, für AVRs gilt dies meist nicht.
Sieht man sich aber die schnelleren Standard-Taktraten für UART an:
115200 230400, 460800, 500000, 576000, 921600, 1000000, 1152000, 1500000, 2000000, 2500000, 3000000, 3500000, 4000000
so sind die auf einem Due auf deutlich unter 400kHz begrenzt ("230.4k just barely, maybe works, sometimes"),
auf AVRs geht es wegen der geeigneteren UART clock devider deutlich höher, da deren cpu-clock von 16MHz besser mit geringeren Fehlern heruntergeteilt werden kann als die 84MHz des Due oder die 48MHz des M0.
Mehrere Geräte mit multi-slave und auch multi-master sind dagegen eher mit i2c möglich.
Je höher die Taktraten und je länger die Kabel sind, entstehen aber exponentiell mehr Übertragungsfehler, die in jedem Falle duch Fehlerkontrolle wie checksums etc geprüft und die Daten dann ggf. verworfen werden müssen.
Nach meiner Erfahrung mit Raspis, ARMs und AVRs funktionieren zwischen allen (!) Plattformen gerade noch akzeptabel:
UART 115200 bis 230400 kHz, auf AVRs und Raspi auch bis mind. 1MHz
i2c mit AVRs bis 400 kHz, auf ARMs und Raspi auch bis mind. 1 MHz
- mit jew. Geschwindigkeitsvorteil für UART per full-duplex, ansonsten bei half-duplex (UART per Handshake) fast gleichwertig.
Danke für die Infos, HaWe!
Searcher
26.09.2018, 09:45
Die Anforderung ist ein Bussystem, an das mehrere Kontroller angebunden sind. Einer schaufelt Daten in einen Zwischenspeicher, die andern Kontroller bearbeiten die Daten gemeinsam und möglichst gleichzeitig. Die Ergebnisse sollen möglichst wieder in einem Zwischenspeicher abgelegt werden.
Ich suche aber noch, wie ich das tatsächlich umsetzen will und letztlich muss (richtet sich nach den Möglichkeiten). Der RAM war der erste Schritt dazu. Weil ich eigentlich Speicher bräuchte, den ich ständig beschreiben kann, ohne dass der nach ein paar Wochen Schaden nimmt und ausfällt.
Hallo Moppi,
ich habe noch mehrere W24M257AK-15 RAM Bausteine hier rumliegen. Ist ein 32K X 8Bit RAM und wird im Prinzip so angesteuert wie Dein 512kByte RAM.
Ich weiß zwar noch nicht wofür aber die Aufgabe mehrere Controller auf den RAM zugreifen zu lassen fand ich interessant und hat mich veranlaßt mit den 32kByte RAMs über die Realisierung nachzudenken.
Ich gehe davon aus, daß die Controller asynchron auf den RAM zugreifen können sollen. Und da bin jetzt soweit, daß ich glaube ohne einen bus arbiter, der den Aufbau komplexer macht, nicht auskommen zu können.
Hast Du auch einen eingebaut oder wie löst Du das Problem möglicher gleichzeitiger Buszugriffe?
Gruß
Searcher
Das Mehrere Bausteine an denselben Bus angeschaltet sind, blieb mir auch nicht erspart. Ich musste Adress- und Datenbus zusammenlegen (nicht genug I/Os am Atmega328P-PU). Aber ich denke, die Programmierung richtet es dann. Meine Bausteine haben alle einen HIGH-Z-Zustand. Die Atmegas wohl auch, wenn man die auf Input schaltet. Ob sich da was stört weiß ich noch nicht. Nach einigem Probieren mit der seriellen Kommunikation, um Adressen zu übermitteln, habe ich das neu entworfen. Weil seriell zu langsam wäre. Funktioniert hatte das schon, mit einem Atmega328. Zu Anfang hatte ich nur einen Atmega, mit getrenntem Daten und Adressbus zum Speicher. Das war mir aber auch zu langsam, weil ich die Adressierung über Schiebregister machen musste. Dann habe ich versucht, 3 Schieberegister auf einmal zu laden, was auch ging, aber dann - erstaunlicher Weise - vom Programmcode her langsamer wurde, weil ich Adressen umrechen musste (das Schieben über die Schieberegister ging vom Code her dann schneller). Ich wollte gerne unter 1500 bis 2000 Millisekunden kommen, zum Lesen und Schreiben von 102400 Bytes. Als zentraler Speicher an einem Datenbus ist eine Beschaltung mit einem Atmega328 wegen begrenzter I/Os auch nicht tauglich, daher mein Versuch der ser. Schnittstelle, zur Adressübertragung. Außerdem hatte ich zu wenige I/Os, weil ich gerne noch SD-Karte einbinden möchte. Zwecks Ein- Auslagerung, wenn der physische SRAM zu wenig ist, weil höhere Adressen angefordert werden. Deshalb bin ich bei 2 Atmegas328 angekommen, die sich das dann teilen. Leider kann ich aber auch den Adressbus nicht vom Datenbus trennen (eben wegen der begrenzten I/Os), so dass dann das Umschalten der Pins zwischen Ein- und Ausgang nochmal Zeit kosten wird. Ich warte noch auf eine Lieferung meiner bestellten D-Latches, die ich eingeplant habe, dann fange ich mit dem Aufbau nochmal von vorne an.
Asynchroner Zugriff auf normales RAM ist nicht möglich. Dafür gibt es spezielle RAM-Bausteine, die das können. RAM-Zugriffe müssen in eine Warteschlange, bzw. muss jedes Modul, dass den RAM benötigt, warten. Hier kann man eine Hirarchielogik ausarbeiten. Da hatte ich gedacht, könnte man wenigstens einen RAM-Baustein spiegeln, damit man zwei Zugriffe gleichzeitig durchführen kann. Darum hatte ich an eine Schaltung gedacht, die am Atmega328 vorbei arbeitet und die Daten direkt von RAM zu RAM kopieren kann, so dass zwei Bausteine immer denselben Inhalt haben. Ich bin irgendwie auf eine Datenrate von ca. 16MByte/s gekommen - weiß nicht ob das richtig war, aber ich denk schon, da ein RAM nur 55ns Zugriffszeit hat. Nur das war mir zu aufgeblasen - ich hätte locker eine E100-Platine vollbekommen. Weshalb ich darauf zunächst verzichte. Verschiedene Arbeitsbereiche können natürlich ein eigenes RAM-Modul haben. So hat man verschiedene Scopes. Um Daten lokal zu verarbeiten und global auszutauschen. Das verringert die Wartezeiten.
Searcher
26.09.2018, 13:05
Mit asynchronem Zugriff meinte ich Controller, die frei entscheiden, wann sie Daten zum RAM senden bzw vom RAM holen wollen. Es könnte also zufällig passiern, daß gleichzeitig von verschiedenen Controllern auf die die Steuer/Adressleitungen des RAMs bzw der Schieberegister oder D-Latches? zugegriffen wird.
Um das zu verhindern dachte ich daran, den Controllern ein Zeitfenster zuzuordnen, in dem sie RAM Operationen durchführen dürfen. Aus Performancegründen verworfen, da eine ungenutzte reservierte Zeit einem anderen Controller verloren geht, der sie vielleicht gerade benötigt. Einen Arbiter, der den Buszugriff regelt in den Controllern selbst zu implementieren. Oder einen eigenen µC oder eine HW als Arbiter zu installieren - kleiner µC wie ATtiny24 meine favorisierte Lösung zur Zeit.
In etwa die"c) Independent request" Methode von dieser Seite (http://www.ques10.com/p/8794/what-is-bus-arbitration-explain-any-two-techniques/)
Über Datentransferrate habe ich noch gar nicht nachgedacht. Ein Mega328 kann mit 20Mhz getaktet werden. Ein ein Cycle Maschinenbefehl wird dann in 1/20MHz=50ns ausgeführt. zB ein OUT PORTB,r16. Die Daten müssen aber erst nach r16 gebracht werden. Ein zweiter Befehl ist da notwendig und noch weitere ...
Ich kann gar nicht abschätzen, wie schnell ein compilierter Arduino sketch ist. Ich nutze BASCOM und da wo es schnell gehen soll oder es zeitkritisch wird mache ich Assembler Routinen.
Bin gespannt, wie es weitergeht und was das mal werden soll. Viel Erfolg!
Gruß
Searcher
8-Bit programmierbare Zähler wären sinnvoll. Ich finde aber keine.
Das Problem mit dem Beschicken von Daten und Abholen von Daten, ist - finde ich - ein organisatorisches Problem. Auf die Verarbeitungsstruktur kommt es an. Das könnte man auf verschiedene Weise regeln, denke ich. Aber so weit bin ich noch nicht.
MfG
ich würde ein sternförmiges Netzwerk wählen, bei denen 1 "Server" das RAM samt aller Zugriffe allein verwaltet.
Der Server kann dann per i2c rundrum alle "clients" abfragen, was sie zu melden haben, und dann die aktuellen r/w requests abarbeiten; dann kommt der nächste client dran.
Aus Performancegründen wäre dann aber sicher ein Server mit hohem Takt und großem onboard-RAM die beste Lösung, also ein M4 oder gar ein Raspi.
Sollten die Datenmengen deutlich größer sein oder werden oder auch erforderlicherweise nicht-flüchtig, könnte ein Raspi auch einen USB-Stick oder eine SSD etc. per USB verwenden.
Searcher
26.09.2018, 20:18
8-Bit programmierbare Zähler wären sinnvoll. Ich finde aber keine.
Es gibt 74HC161 (presetable 4-Bit binary counter), die kaskadiert werden können:
Wird im Datenblatt erwähnt und auch in https://forum.allaboutcircuits.com/threads/chaining-binary-counters.110498/#post-853339
Bin dort nicht registriert und bekomme den dortigen Schaltplan deswegen nicht in lesbare Größe :-(
Ich vermute, daß Du den Zähler für die Adresseneingabe verwenden möchtest um nicht für jede Speicherstelle immer eine komplette Adresse vom Controller übertragen zu müssen, sondern einfach per Taktimpuls an den Zähler die Adresse erhöhen möchtest um damit den RAM sequenziell beschreiben/lesen zu können?
Wäre noch ein Stück mehr HW, die aber das Ding ein Stück schneller machen würde.
Gruß
Searcher
Mit einem Zähler macht das durchaus Sinn. Denn das ist das, was man in der Regel bei der Datenverarbeitung macht: Adressen hintereinander auslesen.
Ich bin aus den 4 Bit Countern bisher nicht schlau geworden. Die ich gefunden hatte, waren Abwärtszähler. Man muss eine Andresse anlegen können und mit einem Taktimpuls den Zähler laden, der Stand erscheint am Ausgang und wird mit jedem Zähltakt erhöht - so sollte das sein.
Scheint so mit den 74HC161 zu funktionieren. Nur dass es hier 4-Bit Zähler sind. Macht dann bei 20 Adressleitungen 5 ICs. Da muss man dann schauen, wie der bautechnische Aufwand ist. Der Vorteil von Zähler-ICs ist, dass die um ein Vielfaches schneller zählen können und die Adresse muss nicht extra über Zwischenspeicher zum RAM übertragen werden, weil alles in einem Baustein schon drin ist.
Dann werde ich jetzt mal schauen, ob das Austauschen eines Atmega328 und zwei 8-Bit-Puffern, den Aufwand von zwei zusätzlichen ICs rechtfertigt.
Vielen Dank so weit, dafür!
MfG
8-Bit programmierbare Zähler wären sinnvoll. Ich finde aber keine.
Wenn solche gemeint sind:
https://www.google.com/search?client=firefox-b-ab&ei=EoisW-D2FJLCwQKNuZ-ACA&q=presettable+8-bit+binary+up%2Fdown+counter&oq=+bianry+counter+presettable+8-bit&gs_l=psy-ab.1.0.0i8i13i30k1.200374.206418.0.211726.2.2.0.0. 0.0.223.333.0j1j1.2.0....0...1c.1.64.psy-ab..0.1.109....0.3wnNNmUjr8o
http://www.ti.com/lit/ds/symlink/sn54as869.pdf
Ich habe mal was zum 74HC161 zusammengebastelt. Zwecks Beschaltung und Verhalten:
33662
Das war das erste brainstorming heute am Morgen. Ich weiß noch noch nicht, ob es so korrekt ist.
MfG
Nachtrag:
@Manf, gerade habe ich eine Bestelllung für die 4-Bit Counter getätigt ;) - menno!
Allerdings Reichelt hat die 8-Bit Counter gar nicht. Conrad leider auch kein Treffer. Oder ich suche falsch..
@searcher, was die Koordination der Zugriffe angeht, habe ich mir gestern Abend noch Gedanken gemacht. Das Einfachste wird sein, wenn sich alle "Teilnehmer" bei einem "Schaffner" mit einem Signal (Pin log. 1 / log. 0) anmelden und von dem "Schaffner" dann eine Signalrückmeldung kommt, dass sie mit dem Bus fahren dürfen (Signal log. 1) oder noch nicht (Signal log. 0). Wenn ein "Teilnehmer" mit dem Bus gefahren ist, meldet der sich beim "Schaffner" mit log. 0 und der "Schaffner" geht dann zum nächsten "Teilnehmer", der sich angemeldet hat und erteilt ihm dann die Erlaubnis, mit dem Bus zu fahren. Je nach Konzept könnte der "Schaffner" auch eine gültige Fahrkarte verlangen, bevor er jemanden mit dem Bus fahren lässt.
wenn du nicht den "Schaffner" (Server) selber auch schreiben lassen willst, sondern der nur dazu da ist, eine "Fahrkarte" (Token) für die Zugriffsrechte zu vergeben und weiterzureichen, kann man auch einen "Token Ring" ohne Schaffner aufbauen. Hier reicht dann jeder Client, wenn er dran war und wenn er dann fertig ist, seinen Token an den nächsten im Netwerk-"Ring" weiter, sodass immer nur max. 1 den Token als Schreibberechtigung hat.
Aber ein Server, der die Tokens verwaltet, ist tatsächlich sicherer gegen Ausfälle und Störungen, das stimmt: es ist dann eine abgepeckte Variante meines oben skizzierten sternförmigen Server-Client-Netzes.
Beide Systeme können sich aber dennoch leicht aufhängen:
Der Token Ring, wenn irgendein beliebiger Client im Ring irgendwo ausfällt,
und im Stern, wenn der Server ausfällt.
Nur TCP/IP-Netze mit multiplen Knoten sind da ausfallsicherer.
Die Teilnehmer untereinander zu verbinden, das wäre natürlich gut, weil man theor. beliebig viele miteinander verketten kann. Daran gefiel mir aber nicht, dass sich jeder Teilnehmer noch um die Absprache kümmern muss. Max. würde ich 2 Signalleitungen dafür verwenden, Eine rein und Eine raus, zum Nächsten. Bevor hier eine Entscheidung gefallen ist, muss das Signal alle Teilnehmer passiert haben. Außerdem kann man nicht ermitteln, ob ein im Ring weiter entfernter Teilnehmer, eher dran sein müsste, als andere.
Diese serielle Kommunikation gefällt mir irgendwie auf dieser Ebene nicht, ob I2C oder was anderes. Ich möchte möglichst kurze Latenzzeiten im System, sonst macht das für mich keinen Sinn - nur wenn ich eine bestimmte Datenverarbeitungsrate erreichen würde.
ich fürchte fast, da hast du falsche Vorstellungen über die Geschwindigkeitsproblematik, denn ein Token hin oder her oder weiter zu reichen, das geht weit schneller als dann die Daten selber über ICs und GPIO Pins in dein externes RAM zu schreiben.
Da würde ich mal einen Geschwindigkeitstest machen, verschiedene große Datenpakete 1000x lesen und schreiben, mit chksum-Überprüfung!
PS,
du kannst auch 2x UART zur Kommunikation bei kleinen AVRs verwenden, einmal Serial() und einmal SoftwareSerial(), auch z.B. das eine für den Vorgänger und das andere für den Nachfolger im Ring (im Stern sicher eher i2c mit 400k) !
Das Maximum bei paralleler Datenübertragung, mit einem 16MHz Atmega328 konnte ich mit etwa 25 bis 27kByte pro Sekunde bestimmen
Wieviel ist es denn bei I2C mit einem 16MHz Atmega328?
habe ich mit Bytes noch nicht exakt getestet, aber als Hausnummer (!) bei 100kHz mit chksum Test auf master und slaves:
32byte-arrays jew. ca. alle 5ms, also 32*1000/5=6.4kB/s, bei 400kHz oder einzelnen Bytes sicher noch schneller (aber ntl. nicht mehr bytes, wenn du einzeln sendest).
Aber da gibt es sicher verlässliche, validierte Tests, wenn du es genau wissen willst. (Der Prozessortakt ist ja dafür nicht ausschlaggebend, nur i2c Bus-Takt.)
Ich meinte aber auch nicht nur die reine parallele Datenübertragung, sondern auch getestete physikalische Lese-/Schreibaktionen auf dem RAM, auch mit chksum Test.
Per I2C: 27kByte / Sekunde. Von daher wäre das gleich oder sogar etwas schneller, als mit einem Atmega328 parallel Daten zu übertragen.
sondern auch getestete physikalische Lese-/Schreibaktionen auf dem RAM
Der RAM benötigt ca. 55 bis 70ns, je nach Ausführung, dann ist es gelesen oder geschrieben, dann ist er damit fertig, inklusive allem, was er benötigt, um Daten abzulegen oder hervorzugraben und stabil zur Verfügung zu stellen.
Aber wenn ich Dich richtig verstehe, möchtest Du dann gerne zusätzlich noch einen Zusatz-RAM für Prüfbits dazupacken, bzw. am besten ganze Checksummen berechnen, beim Auslesen und Schreiben, und das dann überprüfen?
Bei einer Geschwindigkeit von unter 20MHz? Bei SRAM? Dann nehme ich an, wirst Du sicher auch bei andern Datenträgern immer ein Raid-System installiert haben?
Searcher
27.09.2018, 16:14
@searcher, was die Koordination der Zugriffe angeht, habe ich mir gestern Abend noch Gedanken gemacht. Das Einfachste wird sein, wenn sich alle "Teilnehmer" bei einem "Schaffner" mit einem Signal (Pin log. 1 / log. 0) anmelden und von dem "Schaffner" dann eine Signalrückmeldung kommt, dass sie mit dem Bus fahren dürfen (Signal log. 1) oder noch nicht (Signal log. 0). Wenn ein "Teilnehmer" mit dem Bus gefahren ist, meldet der sich beim "Schaffner" mit log. 0 und der "Schaffner" geht dann zum nächsten "Teilnehmer", der sich angemeldet hat und erteilt ihm dann die Erlaubnis, mit dem Bus zu fahren. Je nach Konzept könnte der "Schaffner" auch eine gültige Fahrkarte verlangen, bevor er jemanden mit dem Bus fahren lässt.
Ja, so oder so ähnlich würde ich das auch machen. Das ist der Fall c auf der Seite, die ich vorher schon mal verlinkt hatte: http://www.ques10.com/p/8794/what-is-bus-arbitration-explain-any-two-techniques/
Da gibt es noch einen gemeinsame Bus Busy Leitung. Ist mir im Augenblick unklar, ob die wirklich gebraucht wird.
Schade wg. den chip Vorschlägen von Manf. Als Versender fand ich bei einen für mehr als 8€ :-( das Stück. Wird anscheinend kaum noch verwendet.
Gruß
Searcher
So, nun hatte ich mich auf hohe Übertragungsraten gefreut und nun das:
Bei Byteweiser Übertragung mit I2C, sinkt die Übertragungsrate auf ca. 11.5KByte/s. Wo ich bei paralleler Übertragung über die I/O-Ports schon mit 22kByte rechnen könnte. Für I2C muss dann das Prozedere geändert werden. Denn eigentlich könnte man jetzt die 8-Bit-Daten über 2 Pins übertragen. Aber beim Steuerbus bin ich der Meinung, dass die Anbindung über dig. I/O-Ports schneller ist, weil man da nur einzelne Bits als Informationen benötigt. Über I2C würde man dafür eine Datenrate von schätzungsweise über 200kByte/s benötigen, um die relevanten Informationen in der selben Zeit zu übertragen.
@searcher, diese 8-Bit-Zähler sind schwer zu bekommen. Übrigens gab es bis vor kurzem noch 1MByte SRAM bei Reichelt. Das ist eine gute Woche her. Die sind auch vorerst ausgestorben. RS Components hat die momenatn auch nicht.
Ich habe mir das so genau nicht angesehen, was Du verlinkt hattest. Aber ein Busy-Signal ist schon notwendig, wenn man Aufgabenteilung betreibt. Der eine muss ja wissen, ob der andere schon fertig ist, damit z.B. die gemeinsam erarbeiteten Daten auf den Bus gelegt werden können. Oder auch, wenn man Sender und Empfänger synchronisieren möchte.
Aber wenn ich Dich richtig verstehe, möchtest Du dann gerne zusätzlich noch einen Zusatz-RAM für Prüfbits dazupacken, bzw. am besten ganze Checksummen berechnen, beim Auslesen und Schreiben, und das dann überprüfen?
Bei einer Geschwindigkeit von unter 20MHz? Bei SRAM? Dann nehme ich an, wirst Du sicher auch bei andern Datenträgern immer ein Raid-System installiert haben?
Kein Zusatz-RAM, aber bei sensitiven Daten einen Check mindestens nach jedem Lesen, ggf auch Rückmeldung an den Sender wenn Daten fehlerhaft sind zum erneuten schreiben/senden.
Bei i2c, UART und BT habe ich immer ein Startbyte (255), dann ein chksum-Byte (sum ab 3.byte), by i2c dann die Slave-Addr, der Rest Datenbytes. Bei ungeschirmten, längeren Kabeln oder WL kommen oft unerwartete Fehler zustande.
Bei jedem Lesevorgang wird die chksum neu berechnet und mit der mitgeschickten chksum verglichen, erst dann weiterverarbeitet oder verworfen.
Fürs Schreiben wird nur die chksum berechnet und ins 2. byte hineingeschrieben, dann verschickt (geschrieben), der Empfänger prüft dann ja auf Konsistenz (bei dir notfalls immer zusätzliches zurücklesen zum Check, wenn es sensitive Daten sind).
Beruflich hatte ich aber tatsächlich ein hot-swap RAID System bei mir, das stimmt schon, hat aber vor allem was mit Ausfallsicherheit zu tun.
Dass paralleles Senden aber grundsätzlich schneller ist als serielles (bei gleichem Takt und gleich großen Datenpaketen), ist eigentlich doch kein Wunder, die Frage ist nur auch, wieviele Bytes einzeln oder gemeinsam bewegt und gecheckt werden müssen.
Wenn ich mit meinem Raspi allerdings auf SD Karte weniger sensitive Daten schreibe oder auch auf USB-HD, dann allerdings mache ich keine extra file-checks, das überlasse ich stillschweigend Linux.
Also der RAM wird mit 5 Volt betrieben, nicht mit 1.5 oder 2.3 oder 3.3 oder so. Die Kabel zu den Pins sind so dick, dass sie völlig überdimensioniert sind. Der Spannungsabstand zwischen High- und Low-Pegel so groß, die Leitungen kurz. BIs jetzt hatte ich noch keine größtmögliche Freuqenz beim Auslesen und Beschreiben. Ich hatte schon damit gerechnet, dass Bit-Fehler auftreten würden. Deswegen habe ich einen Memory-Check gebaut. Wenn Fehler auftraten, dann weil ich Programmierfehler gemacht habe oder Leitungen aus Versehen gezogen; manchmal wackeln welche mit den Steckverbindern. Aber bis jetzt bin ich erstaunt dass das gut funktioniert hat. Aber ob das Fehlerfrei bleibt, wird sich rausstellen, bin noch am experimentieren und haufenweise Zeichnungen erstellen (um mir über Vor und Nachteile bestimmter Schaltungen klar zu werden, weil auf einem Bild kann man viele Dinge doch besser erfassen und durchspielen). Bei den SD-Karten bin schon auf die Idee gekommen, schlussendlich mehrere zugleich zu betreiben, um Kartenausfälle durch Vergleichen der Daten frühzeitig zu erkennen. Aber jetzt werde ich erst mal demnächst Einiges löten. Für ein vorläufiges Schaltungskonzept habe ich mich erst mal entschieden, denke ich. Beim Vergleichen sind mir da auch Dinge aufgefallen, auf die ich von Anfang an hätte kommen können, weil sie eigentlich logisch sind. Deshalb hier nochmal etwas mehr:
Der RAM liefert 8 Bit parallel anliegend Daten. Die können nicht seriell übertragen werden, da er keine serielle Schnittstelle hat.
Die Daten müssen ausgelesen werden, indem eine Adresse gebildet und angelegt wird und dann die Steuerleitungen gesetzt werden, damit
die Daten am Ausgang anliegen oder vom Eingang geschrieben werden. Das geht nicht per serieller Schnittstelle.
Wenn die Daten beim Lesen anliegen, ist das oberste Ziel, Verzögerungen durch Folgekommunikation möglichst gering zu halten, bis dass
der eigentliche Datenempfänger die Daten abgeholt hat. Um eine serielle Schnittstelle dazwischen zu schalten, müssen die Daten
nochmal gelesen und zur ser. Schnittstelle geschickt werden. Dabei spielt keine Rolle, ob die Daten im Anschluss mit einer
womöglich höhren Geschwindigkeit weitergeschickt werden. In jedem Fall erhöht sich durch das Umlegen auf eine serielle Schnittstelle
die Bearbeitungszeit, bis die Daten beim Empfänger angekommen sind. Denn zu dem Zeitpunkt, wo die Daten umgeformt und verschickt
werden könnte sie der eigentliche Empfänger auch bereits abholen, indem er einen Portzugriff ausführt. Die Daten können physikalisch
nicht schneller beim Empfänger ankommen, als sie am Ursprung gewonnen werden können. Sie können allenfalls länger unterwegs sein, das
sind Verzögerungen, die sich summieren und ein System insgesamt ausbremsen.
Die Alternative wäre, auf einen großen Datenspeicher seriell zuzugreifen. Das kann ich mit meinem Netzwerkserver machen. Der hat die
entsprechende Leistung und Speicherkapazität und könnte sogar Berechnungen übernehmen oder sonst Daten verarbeiten. Mit ein wenig Java
lässt sich so etwas wunderbar lösen. Um Daten schnell zu übertragen, könnte ich auch nodeMCUs nehmen. Ich habe noch 5 Stück hier liegen.
Pro Board mit 80MHz getaktet, könnten sie parallel vom Netzwerk Daten laden, selbst be- oder verarbeiten oder hin übertragen.
Auch mit Java auf dem Netzwerkserver so weit kein Problem. Aber die Frage ist: ist das das Ziel, dass ich verfolge? Ist dies das, was mich interessiert? - Da ich solche
Sachen schon hier und da ausprobiert habe, fehlt mir dort an der Stelle die Herausforderung.
Oder nimmt man direkt ein Mehrprozessorboard, wo meinetwegen 10 Stück Intel Core i7 Extreme mit 3,4 GHz Taktrate drauf betrieben werden
- jeder Prozessor mit sechs Kernen, zwölf Threads und 15 MB Cache?
Dagegen bekomme ich für 150 Eur, 100 Stück Atmega328P-PU. Insgesamt eine Portzahl von 2000 Stück, bei 100 eigenständigen CPUs.
Also erstmal viel zum Ausprobieren ... was auch nicht zwangsweise jeder verstehen muss :)
Klingt äußerst ambitioniert... ;)
Was und wieviel in welcher Zeit um alles in der Welt aber willst du denn da eigentlich speichern?
Bis jetzt hatte ich keine Datenblöcke größer 8MB. Bei komplexeren Zusammenhängen könnten es aber auch mehr werden. Es geht erst mal nur um String-Verarbeitung: Splitten, Ersetzen, Suchen. Theoretisches Beispiel: Damit könnte man, in jeder beliebigen Sprache, Sätze bilden. Damit könnte man dann wiederum gespeicherte Daten, die untereinander zusammenhängen, in Sätzen beschreiben. Was man dabei als Sprache definiert, ist der Fantasie überlassen. Ist im Grunde erst mal nur eine Aneinanderreihung beliebiger Zeichen, die einem Muster oder Regeln folgt. Als Software habe ich fertig. ;) Aber jetzt will ich wissen, ob ich das als Hardware bauen kann. Einfach der Unabhängigkeit von bestehenden Betriebssystemen und anderer Software wegen. Geschwindigkeit: weiß ich noch nicht. Erstmal sehen, wie schnell welche Einheit am Ende sein muss, um im Verbund, der ja noch gar nicht da ist, eine brauchbare Geschwindigkeit zu erzielen. Aber ich sag mal so: wenn mein PC einige Sekunden oder Minuten benötigt und die Gesamtschaltung dann ein paar Stunden oder Tage, dann stimmt was mit der Geschwindigkeit nicht.
kann mir ehrlich gesagt daraus jetzt noch nichts genaues für die spätere Anwendung vorstellen.... :confused:
Das ist gut so. ;)
Nimm als Sprache beispielhaft Text, den wir Menschen lesen können.
was eine Sprache ist, weiß ich, sowohl aus der Linguistik als auch aus der Mathematik bzw. der Informatik-Theorie (Stichworte Alphabet, Kleensche Hülle, Chomsky-Grammatiken).
Was du damit als Anwendung willst, das ist mir schleierhaft.
Dann hast Du das mit der Sprache richtig verstanden. Ein Beispiel hatte ich ja schon gegeben. :o Nochmal anders: aus einer Fülle gespeicherter Informationen Zusammenhänge und Dinge zu erklären, bzw. dieses tun zu lassen.
Irgendwie kommst du nicht richtig rüber mit der Info - wieso?
sprechen soll wer?
In welcher Sprache?
Wovon wird gesprochen?
Wer soll was erklären?
Wer generiert die Sprachphoneme samt Syntax?
Wer analysiert sie mit welcher Spracherkennungssoftware?
Wozu dient der Speicher?
Wer schreibt was drauf, und wer liest es?
Wieviel Wörter/Sätze in welcher Zeit sind zu verarbeiten?
Und um welche Aufgabe geht es insgesamt genau?
Willst du die web- und KI-basierte Google Spracherkennung oder Alexa mit AVRs für eine Hausautomatisierung oder Bestellwesen lokal selber bauen oder wie oder was?
Du denkst schon zu kompliziert, das Wichtigste ist:
Es geht erst mal nur um String-Verarbeitung: Splitten, Ersetzen, Suchen.
Falls das ausreichend schnell wäre, was ich noch gar nicht weiß, aber versuchen will, käme als nächster Schritt das Interpretieren von Strings (Zeichenketten). Falls das auch ausreichend schnell wäre, folgt komplexere Verarbeitung. Ergibt unterm Strich autonome Datenverarbeitung. Der Inhalt ist völlig undefiniert. Das Anwendungsfeld deshalb vielseitig. Stellt dann erst mal ein leeres Konstrukt dar, das in sich aber funktionstüchtig ist. Was man damit tun will, hängt dann von den eingegebenen Daten und Strukturen ab und den Zielsetzungen. Wenn Ziele definiert sind, wird es auch Ergebnisse geben. Auf dem Weg zum Ziel aber auch jede Menge offene Fragen / fehlende Daten, die nachzutragen wären, bis das erwartete Ziel erreicht wird.
MfG
String-Verarbeitung für "Splitten, Ersetzen, Suchen" gibt es doch schon, per cstrings und ANSI C Funktionen
und per Arduino String class (einer abgespeckten, nicht ganz std::string kompatiblen Klasse)
Das kann doch kein Problem sein?
aber was bedeutet "Interpretieren von Strings (Zeichenketten)" ?
was soll beispielhaft als was "interpretiert" werden?
oder willst du Audiosignale speichern und sie später als Wörter wiedererkennen?
Natürlich gibt es alles, läuft ja auch bei mir. Ich muss das nicht neu ausdenken, das habe ich die letzten Jahre gemacht. Allerdings interessiert mich jetzt, in wie weit ich das mit den gedachten Mitteln auf Hardware vielleicht umsetzen kann. Ob so eine Art Schwarmintelligenz machbar wäre, wenn man so will. Diesen Vorschlag von Dir damals mit den Atmegas fand ich gar nicht schlecht, macht vom Prinzip her in kleinster Einheit das, was ich bräuchte. Jetzt ist bloß die Frage, ob das zum Erfolg führen könnte, aufgrund der Geschwindigkeit?
Es gibt Leute, die bauen aus Legosteinen ganze Häuser oder Tiere oder Fahrzeuge, obwohl es das alles schon in anderer Ausführung gibt. So weit zum Sinn, irgend etwas bauen zu wollen.
Parser? Compiler? Linker? ... Interpreter?
Interpreter: https://www.google.com/search?q=Interpreter
Morgen kommen noch Bauteile, dann kann ich sehen, wie sich die erste Stufe so angehen lässt. Vielleicht scheitert das ja auch schon auf den ersten Metern, mal sehen. Aber dazu muss ich erst mal was bauen. Falls es dann Probleme gibt, muss ich in meinem Softwarependant nachschauen, ob das dann an dieser Stelle schon zum Scheitern verurteilt ist oder ob ich es anders organisieren kann, um weiter zu kommen. Ziel ist es eine bestehende Software auf Hardware umzumünzen. Wäre toll, wäre mal was anderes! :-)
ok, ich sehe, dass ich noch nichts sehe.... ;)
Grundsätzlich halte ich nach meinen bisherigen KI Versuchen (weil du von "Intelligenz" sprachst) die mini-AVRs vom UNO Typ für absolut ungeeignet allein schon wegen dem 2- 2.5kB Micker-RAM. Schon SPI und die seriellen Puffer auch für UART und i2c brauchen ja schon knapp 1 kB, was bleibt da noch für Programm und Daten?!
Ein Mega2560 mit 8kB muss es mindestens sein, damit habe ich immerhin schon einen autonomen Schach-Zuggenerator am Laufen und auch eine Fast-Fourier-Transformation zur Tonsignalerkennung ist damit gerade eben extrem simplifiziert machbar (2 komplexe arrays zu je 256 fp Elementen = 4kB) - auch das ist aber eigentlich immer noch zu schwach auf der Brust.
KI, FFT und fuzzy logic erfordern zwangsweise leistungsstarke MCUs mit viel RAM und hohem Takt für fp math, mit int kommst du keinen müden Steinwurf weit. Diese 8bit-2.5kB-Mini-AVRs taugen höchstens was für Katzen- oder Hühnerklappen.
Man sieht, das sieht dass Du nicht mit 8 Bit auskommen kannst. Geht aber trotzdem, mathematisch komplexe Sachen in 8 Bit-Rechenoperationen zu erledigen, wenn es denn sein müsste.
Aber jetzt schweifst Du vom Thema ab. Über KI und Assistenzsysteme will ich doch jetzt hier gar nicht streiten. Viel wichtiger ist, dass heute die andern Teile kamen. Steuerbus ist fertig aufgebaut. Und dann bin ich gespannt, ob mein kleines Vorhaben, dass machen wird, was es soll! Nämlich Speicherinhalt schnellstmöglich transferieren und Speicher auslagern :-) Die nächste anstehende Frage ist dann, ob ich 256 Byte breite Spalten und 2048 Zeilen nehme oder lieber gleich 1024 Zeilen und dafür 512 Byte je Spalte. Für kleine Variablen sind 256 Byte noch zu viel, für Große 512 Byt aber noch bei weitem zu wenig. Bis jetzt habe ich es so geplant, dass ich 1024 Zeilen adressiere, bei 256 Byte pro Zeile. Mit dem Carry-Flag, des zweiten 4-Bit-Zählers erweitere ich die 256 Byte, mit der zweiten RAM-Hälfte, auf 512 Byte. Hinsichtlich dessen, dass ein Sektor auf einer normalen Festplatte auch 512 Byte groß ist.
Achso, im Übrigen: die Beschaltung der zwei 4-Bit-Zähler, die ich vor kurzem skizziert hatte, funktioniert in der Tat.
Also bis dahin...
---------------------------------------------------------------
Nachtrag:
33664
Dass Du auch immer so neugierig sein musst! Ich sehe was, was Du nicht siehst ;)
Searcher
30.09.2018, 07:35
Steuerbus ist fertig aufgebaut. ...
Achso, im Übrigen: die Beschaltung der zwei 4-Bit-Zähler, die ich vor kurzem skizziert hatte, funktioniert in der Tat.
Man, Du legst aber ein Tempo vor :shock: Ich versuche gerade den Steuerbus (mit zwei Leitungen zu jedem Busteilnehmer) auf einem ATtiny44A als Buscontroller zu programmieren. Busteilnehmer sollen auf der Request Leitung mit einem low anfordern und bekommen Zugriff vom Bus Controller mit einem low auf der Grant Leitung. Die Busteilnehmer sollen die Request Leitung so lange auf low halten bis sie den Bus wieder freigeben. Danach nimmt der Bus Controller das low von der Grant Leitung weg und kann den Bus dem nächsten Teilnehmer zuordnen. Die Requests sollen der Reihe ihres Eingangs nach behandelt werden. Gibt der erste den Bus frei, der zweite den Bus belegt und der dritte wartet, während der erste schon wieder anfordert, sollen Prioritäten vergeben werden bzw eine Warteschlange aufgebaut werden um den dritten vor dem ersten den Bus zuzuteilen. Das in Code zu bringen bei diesem Superwetter draußen braucht bei mir anscheinend mehr Zeit als Dein ganzes Projekt :-)
Gruß
Searcher
Hallo!
@ Moppi
Man sieht, das sieht dass Du nicht mit 8 Bit auskommen kannst. Geht aber trotzdem, mathematisch komplexe Sachen in 8 Bit-Rechenoperationen zu erledigen, wenn es denn sein müsste.
Natürlich, ist aber nicht simpel: https://rn-wissen.de/wiki/index.php?title=PIC_Assembler#Hex_Dec_Wandlung. ;)
Hallo!
Natürlich, ist aber nicht simpel: https://rn-wissen.de/wiki/index.php?title=PIC_Assembler#Hex_Dec_Wandlung. ;)
Es ist nicht nur nicht simpel, es ist auch nicht sinnvoll, wenn man zuhauf float- und double-Berechnung braucht, zusammen mit den ebenfalls nötigen reellen und transzendenten trigonometrischen und Exponential-Funktionen, die wiederrum intern mit Taylorreihen oder Produktentwicklungen etc. nachbildet werden und dafür intern irrsinnig viele fp-Divisionen durchführen.
Tatsächlich rechnet aber ja jede MCU IMMER nur mit integer-Werten, nämlich binär kodierten bytes (=integer-Werten), tut also nichts anderes, als wenn man das auf 8bit-Prozessoren umständlich selber mit int nachbilden will - es ist nur hochoptimiert seitens C/C++ und MCU für Geschwindigkeit und Genauigkeit. Gerade die C/C++-Compiler sind auch optimiert auf Probleme, die durch den Vergleich zweier fp-Variablen auf Gleichheit oder Ungleichheit betrifft u.v.m., was durch minimalste Rundungsfehler der Rechen-Zwischenschritte bei der Konvertierung von fp in ihre binären Repräsentationen angeht.
Dabei muss man auch wissen, dass floats oder deren int16-Repräsentationen oft nicht genau genug sind, um bestimmte Berechnungen zu lösen (wie z.B. Matrix-Determinanten) und dadurch extremst falsche Ergebnisse liefern, daher muss man dann zwingend double verwenden.
Ich hatte schon oft bei meinen ersten Gehversuchen mit Matrizen mit dem Mega2560 (8bit-AVR, kann nur float, kein double) das "unerklärliche" Ergebnis, dass oft Determinanten einen Wert von deutlich größer null hatten (z.B. ein- oder zweistellig positiv), per float berechnet, obwohl die Matrizen antisymmetrisch waren oder ihre Zeilen nicht linear unabhängig, also die det(M) Null hätten sein müssen. Man kann eine Matrix mit Determinante Null aber nicht invertieren (genausowenig wie man durch Null dividieren darf), und die linearen Gleichungssysteme sind bei det(M)=0 nicht lösbar, und das falsche Ergebnis mit floats hätte dies fälschlich erwarten lassen.
Erst double-fp auf 32-bit ARMs erbrachte dann die korrekten Ergebnisse.
Es geht also bei float vs. double vs. int-Arithmetik nicht (nur) um Genauigkeit des Endergebnisses, sondern sogar u.U. tatsächlich darum, ob das Problem überhaupt grundsätzlich lösbar ist.
Fazit: wer 8bit AVRs mit floats braucht, soll mit floats rechnen, wenn es nicht zeitkritisch ist und die Genauigkeit ausreicht;
wer höhere Genauigkeit oder Geschwindigkeit braucht, soll ARM Cortex verwenden, entweder mit single- oder falls erforderlich double-fp, im Extremfall auch mit fpu (M4 oder SoC).
Alles andere ist Murks.
Wer also weiß, dass später vielfach fp zeitintensiv benötigt wird, soll besser gleich mit ARMs anfangen (my2ct).
@searcher
War eine gute Idee mit den 74HC161. Erst war ich skeptisch, mit der Reihenschaltung. Das funktioniert aber erstaunlicher Weise sehr gut. Schnell zählen die Dinger auch. Hatte bis jetzt noch keinen Zählfehler. Allerdings komme ich mit einem Atmega328 (16MHz Takt) auch nicht weit über 160KHz Taktfrequenz raus. Mitmachen soll der HC161 lt. Datenblatt 63MHz.
Busteilnehmer sollen auf der Request Leitung mit einem low anfordern und bekommen Zugriff vom Bus Controller mit einem low auf der Grant Leitung. Die Busteilnehmer sollen die Request Leitung so lange auf low halten bis sie den Bus wieder freigeben. Danach nimmt der Bus Controller das low von der Grant Leitung weg und kann den Bus dem nächsten Teilnehmer zuordnen.
richtig, war der einfachste Gedankengang
Die Requests sollen der Reihe ihres Eingangs nach behandelt werden. Gibt der erste den Bus frei, der zweite den Bus belegt und der dritte wartet, während der erste schon wieder anfordert, sollen Prioritäten vergeben werden bzw eine Warteschlange aufgebaut werden um den dritten vor dem ersten den Bus zuzuteilen.
Wenn ich das richtig verstehe, nimmst Du nur 2 Leitungen, an die Du alle Teilnehmer anschaltest? - Oder doch mehrere parallele? Sonst müsstest Du ja mit jedem Teilnehmer dieselbe Leitung abhören und dann müssen die raten, ob noch jemand anders gerne möchte oder ob sie zurzeit alleine am Bus horchen? Nicht, dass man Kollisionen nicht auflösen könnte. Einer wird der Erste sein, der zu irgendeinem Zeitpunkt sagt: ich belege die Leitung, vorher war sie frei.
Aber da gehst Du von einer anderen Seite ran, als ich. Da bin ich noch gar nicht.
MfG
Searcher
30.09.2018, 14:28
Wenn ich das richtig verstehe, nimmst Du nur 2 Leitungen, an die Du alle Teilnehmer anschaltest? - Oder doch mehrere parallele?
Nein, nein. Ich nehme parallele. Also von jedem Busteilnehmer zwei Leitungen (kein Bus) zum Buscontroller. Bei mir sind im Augenblick drei Busteilnehmer vorgesehen - also kommen von denen sechs Leitungen beim Buscontroller an. Die Fall c) Verdrahtung von der Arbiter Internetseite ohne Bus-busy Leitung. Die Busteilnehmer sind bei mir noch LEDs an denen ich die Zustände der Busleitungen betrachten kann. Ein, noch auf dem Steckbrett steckender Mega88 dient als Testmustererzeuger für die Requestleitungen. Die Muster schalte ich mit einem Taster weiter.
Wenn das Programm auf dem Buscontroller mal steht, versuche ich mit nur 74HC595 ohne 74HC161 weiterzumachen, da ich die Binärzähler nicht habe. Gleich geht es aber erst mal zum Radeln :Strahl
Gruß
Searcher
@searcher
Und schon weiter gekommen?
Schieberegister funktionieren auch als Zähler, bloß nicht in richtiger Reihenfolge der Zählerstände. Pro Takt kann man einen neuen, einmaligen Zählerstand erzeugen. Mit einem 8-Bit-Register sind das 256 Verschiedene. Eine gesamte 8-Bit-Adresse dort reinzuschieben dauert seine Zeit - wesentlich länger.
Ich bin noch bei der Steuerlogik. Die Hardware auf die Beine zu stellen, geht noch relativ flott. Dann muss aber die Softwaresteuerung zur Hardwarelogik passen. Gestern habe ich eine extra Steuerleitung eingeführt, um bessere Kontrolle über die Kommunikation zu haben. Eigentlich aus dem Grund, weil ich mir dachte, dass den Zähler rücksetzen und takten gemeinsam keine gute Idee wäre. Denn immerhin soll der Zähler bei Takt zählen, was aber direkt schon nach dem Rücksetzen passiert. Allerdings habe ich heute Morgen rausgefunden, dass der Zähler, wenn er während des Rücksetzens getaktet wird, nicht darauf reagiert. Also wenn das Rücksetzen aktiv ist und das Taktsignal auf LOW und beides zur selben Zeit umgeschaltet wird (Reset-Signal weg und Taktsignal auf HIGH). Ich meine auch gelesen zu haben dass der Zähler nur bei steigender Flanke zählt. Wenn die steigende Flanke vom Reset überlagert ist, zählt er wohl tatsächlich nicht.
Zurzeit bin ich doch erstaunt, welche Bruttodatenrate über die IO-Ports zu erreichen wäre. Bei der Adressierung habe ich z.Z. um die 125kByte/s netto. Allerdings ist das erst mal nur die Segmentadressierung. Einen Offset will ich später eigentlich auch noch einführen, dann sinkt die Nettodatenrate nochmal etwas. Dafür wird das Lesen und Schreiben schneller gehen; wenn nicht ständig die Adresse wahllos geändert wird. Dann werden wesentlich weniger Zyklen für Portoperationen benötigt. So dass ich damit rechne, in die Nähe der 200kByte/s netto zu kommen. Wenn ich über 160kByte/s käme, wäre ich fürs Erste auch zufrieden. Kommt die SD-Karte ins Spiel, sinkt die Datenrate nochmals, nach allem was ich probiert hatte auf max. 25kByte/s. Mal sehen. Bleibt noch spannend - vor allem aber kniffelig Hard-und Softwarelogik zusammen zu bekommen.
MfG
Searcher
04.10.2018, 12:48
Und schon weiter gekommen?
Ich bin kaum weiter :-(
Ich hatte mich zu lange beim Buscontroller/Arbiter aufgehalten. Da gab es immer wieder Fälle, die nicht in meine Vorstellung paßten. zB brachte ein Controller, der eine BUsanforderung stellte und vor der Zuteilung wieder zurücknahm, die Reihenfolge der Übrigen durcheinander. Nachdem solche Bugs durch Flicken im Code entfernt waren, sah das Programm recht übel aus und muße nochmal neu geschrieben werden. Jetzt steht es aber, braucht jedoch, getaktet mit internem 8MHz Oszillator auf ATtiny44A, etwa 35µs von Entgegennahme der Anforderung bis Zuteilung des Busses, wenn natürlich kein anderer Controller den Bus belegt hat.
Dann hab ich die 74HC595 aufs Steckbrett gebracht und an den ersten Controller (ATMega88PA, 8MHz interner Oszillator) an die HW-SPI Schnittstelle angeschaltet. Deren Parallelausgänge sollen ja die Adresse am RAM setzen. Hier unterscheidet sich mein AUfbau schon von Deinem. Ich habe keine 74HC161 zur Verfügung (vielleicht besorg ich mir noch welche) Auch brauche ich für mein 32KiByte Speicher mit 15 Adressleitungen nur zwei 74HC595, die ich hintereinander geschaltet habe.
Nach Kampf mit den SPI Parametern wie CPOL und CPHA kommen die Bits richtig im Schieberegister an und der der SPI Takt läuft mit halbem Systemtakt also mit 4MHz. Ich benutze BASCOM Befehle und brauche pro Adressbyte etwas mehr als 5µs zur Übertragung, also 10,2µs für eine 15(16)Bit Adresse. Gemessen mit Oszilloskop am Slave Select Pin, der auch von BASCOM gesetzt wird. An der Stelle gibt es wahrscheinlich Optimierungsmöglichkeiten weil der SS sich nach Übertragung reichlich Zeit bis Rückkehr nach idle läßt. Erst soll aber der Rest noch funktionieren.
Heute möchte ich den Mega88 an den Buscontroller anschalten und anfangen die Busschnittstelle darauf zu programmieren. Der RAM Baustein ist noch tief in einer Schublade vergraben.
Ich meine auch gelesen zu haben dass der Zähler nur bei steigender Flanke zählt
Ja, "Table 3 Function table" im NXP Datenblatt bestätigt das ;-) - Mit /MR auf high! :-)
Zurzeit bin ich doch erstaunt, welche Bruttodatenrate über die IO-Ports zu erreichen wäre. Bei der Adressierung habe ich z.Z. um die 125kByte/s netto. Über HW-SPI und Schieberegister liege ich bei 200kByte/s mit 8MHz Controllertakt. Allerdings kann ich bei folgendem Datentransfer keine Zeit durch Adresserhöung mit einfachem Takt sparen. Und ich rechne noch nichts sondern lese einfach nur Bytes aus einem Array und schreibe sie per HW-SPI raus.
Bleibt noch spannend - vor allem aber kniffelig Hard-und Softwarelogik zusammen zu bekommen.
Das gefällt mir auch.
Gruß
Searcher
PS Auf die Sache mit den Schieberegistern als Zähler komme ich später vielleicht noch mal zurück.
Ich muss gestehen, dass ich einem Rechenfehler unterlegen war. Denn ich habe dieselben Daten ermittelt: ca. 10µs für eine 15(16)Bit Adresse. Ich kann es auf evtl ca. 8µs drücken. Da bin ich mit Deinen Werten erst mal ins Straucheln gekommen. Allerdings ist es schon so, dass ich in dieser Zeit schon 2mal 8 Bit übertrage. Daher kann man nicht von kByte sprechen, weils ja Worte sind. :rolleyes: Also in kByte wär's ja schon das Doppelte (250kByte). Wundern tu ich mich jetzt etwas über diese SPI-Anbindung. Ist dem Atmega dort jegliche Rückmeldung egal? Einfach nur Daten drauf und Takt? - Bemerkenswerter Ansatz. :-) Dann bekommst Du die Daten über SPI auch rein? Kannst Du den Atmega nicht höher takten, nicht mit 20MHz? Wenn Du auf SPI 250KByte/s Daten übertragen willst, muss der Takt per SPI ja th. irgendwo bei 250*1024*8 liegen = 2048kHz.
Mit dem Aufbau ist es in der Tat bei mir etwas anders. Ich übertrage in etwa: 1 Byte, für den Modus (Lesen/Schreiben/Adressieren) und warte noch eine Rückmeldung ab, ob die Daten bereit stehen, bzw. übernommen wurden. Da geht schon einiges hin und her, bevor ein Byte übertragen ist.
MfG
PS: Deine Sammlung meiner "Werke" finde ich echt stark! Simple aufgebaute Dinge, die funktionieren. Wenn man sich dann anschaut, womit Du das gebaut hast ... Du kannst Spielzeugentwickler werden und viel Reichtum damit in den USA machen, Haua-ha! :-) Ich seh schon ... "Searcher-Toys" und die Kinder laufen die Bude ein. ;-)
Searcher
04.10.2018, 18:18
Wundern tu ich mich jetzt nur noch etwas über diese SPI-Anbindung. Ist dem Atmega dort jegliche Rückmeldung egal? Einfach nur Daten drauf und Takt? - Bemerkenswerter Ansatz. :-)
:-) Ja, genau. Es sei denn BASCOM macht noch irgend etwas, das ich nicht weiß. Der SPI Master teilt doch nur mit SS dem Slave mit, daß da was kommt. Das Byte, das gesendet werden soll, sollte im Senderegister stehen und wird dann durch die Hardware rausgetaktet. Vielleicht programmiere ich das irgendwann auch noch zu Fuß aber im Augenblick läuft das mit den unten stehenden BASCOM Befehlen. Ob der Slave Daten zurückgibt ist in diesem Fall egal. Es soll ja nur die Adresse des zu übertragenden Datenbytes zu den 74HC595ern gelangen. Wenn der RAM Baustein eingebaut ist, soll vom Mega88 über einen Port das Datenbyte angelegt werden und mit einer WRITE Signal/Leitung in den RAM übernommen werden.
Meine Schaltung ist von hier abgekupfert: https://rn-wissen.de/wiki/index.php?title=Portexpander_am_AVR#Schaltplan
mit einem zweiten 74HC595 in Reihe. (und ohne die Widerstände - kommt noch, wenn ich Probleme entdecke - bis jetzt geht es ohne)
Messung mit Oszi zur Adressübertragung mit diesem Programm. Bei Tastendruck werden zwei Byte übertragen.
$regfile = "m88pdef.dat"
$framesize = 32
$swstack = 32
$hwstack = 32
$crystal = 8000000
Config Spi = Hard , Interrupt = Off , Data_order = Msb , Master = Yes , Polarity = Low , Phase = 0 , Clockrate = 4 , Noss = 0
Spsr.spi2x = 1 'double spi speed for master
Spiinit
Ddrb.2 = 1 'SS as output
Portb.0 = 1 'activate pullup for button
Dim A(8) As Byte
Dim Counter_a As Byte
Counter_a = 1
A(1) = &B0000_0001
A(2) = &B0000_0010
A(3) = &B0000_0100
A(4) = &B0000_1000
A(5) = &B0001_0000
A(6) = &B0010_0000
A(7) = &B0100_0000
A(8) = &B1000_0000
Do
Debounce Pinb.0 , 0 , Shift_byte_out , Sub 'waits for button activation
Loop
End 'end program
Shift_byte_out:
Spiout A(counter_a) , 2 'sends two bytes of array A out of SPI Interface
If Counter_a > 6 Then Counter_a = 1 Else Counter_a = Counter_a + 2
Return
Dann bekommst Du die Daten über SPI auch rein?
Nein. Daten sollen direkt über den Datenbus von einem Port am µC zum RAM gehen und über den gleichen PORT vom RAM gelesen werden. Nur die Schreib/Leseadresse geht bei mir per SPI über die Schieberegister zum RAM.
Kannst Du den Atmega nicht höher takten, nicht mit 20MHz?
Ich könnte auch höher takten allerdings muß ich dann noch 'nen Quarz/e rauskramen und anbauen. Zum Testen reicht mir erstmal der interne Oszillator. Ich habe ja keine konkrete Anwendung wie Du, sondern schaue mal, wie weit ich komme.
Es kann auch sein, daß ich irgendwo einen fatalen Konzeptfehler habe, da ich erst baue und nicht so weit denke :-)
PS: Deine Sammlung meiner "Werke" finde ich echt stark! Simple aufgebaute Dinge, die funktionieren. Wenn man sich dann anschaut, womit Du das gebaut hast ... Du kannst Spielzeugentwickler werden und viel Reichtum damit in den USA machen, Haua-ha! :-) Ich seh schon ... "Searcher-Toys" und die Kinder laufen die Bude ein. ;-)
:-) Danke! :Strahl
Wo der über die Banane fährt (oder nur die Schale) find ich echt zum schreien, sieht irre aus, wie der schnurgerade drüberfährt.
Ja, die SPI-Schnittstelle hatte ich noch gar nicht im Hinterkopf, die habe ich noch nicht mal ausprobiert. Wenn ich das richtig nachgelesen habe, kann die auch mit einigen MHz arbeiten. Das ist schon interessant! Weil damit Parallel-Seriell und andersrum kein Thema ist. Wie sieht das denn dann mit den max. Kabellängen bei SPI aus? Letzten Endes müssen die Daten ja aber auch wieder irgendwo abgeholt werden, womit wir dann wieder zum Thema Netto-Datenrate kommen, eben das, was an einem bestimmten Punkt im Programm ankommt, dass es auch verarbeitet werden kann.
Searcher
04.10.2018, 21:19
Wo der über die Banane fährt (oder nur die Schale) find ich echt zum schreien, sieht irre aus, wie der schnurgerade drüberfährt.
:-) :-) :-) Bei Youtube kann man ja nachsehen, von wo aus es die meisten Zugriffe gab. Da war "Ein erster Linienfolger ohne µC" in Indien sehr populär. Keine Ahnung wie der da hin kam :-)
Ich hatte in den Blogs auch mal ein Bitbanging (falls die Bezeichnung hier zutrifft) Protokoll einer seriellen Datenübertragung im Zwangslaufverfahren über zwei Adern entwickelt. Da wird jedes Bit einzeln quittiert. Ist also nicht vom Takt abhängig. Die Übertragung kann unterbrochen und wieder aufgenommen werden. Erreichte, glaube ich nur 400000 Bit/s bei 16MHz Systemtakt da nicht HW unterstützt. Keine Ahnung ob Du das brauchen kannst. Hier der Link (https://www.roboternetz.de/community/entries/317-Steppender-Linienfolger-SW-serieller-Transfer-im-Zwangslaufverfahren-mit-zwei-Adern)
Ja, die SPI-Schnittstelle hatte ich noch gar nicht im Hinterkopf, die habe ich noch nicht mal ausprobiert. Wenn ich das richtig nachgelesen habe, kann die auch mit einigen MHz arbeiten.
Ja. Der SPI Takt läst sich auf halben Systemtakt konfigurieren. 20MHz Systemtakt - 10MHz SPI Master Takt.
Wie sieht das denn dann mit den max. Kabellängen bei SPI aus?
Keine Ahnung. 10 oder 20cm sollten bei 10MHz kein Problem sein!?
Letzten Endes müssen die Daten ja aber auch wieder irgendwo abgeholt werden, womit wir dann wieder zum Thema Netto-Datenrate kommen, eben das, was an einem bestimmten Punkt im Programm ankommt, dass es auch verarbeitet werden kann.
Wo die zu verarbeitenden Daten von außerhalb diesen Systems eigentlich herkommen weiß ich (noch) nicht? Kann über UART, die laut Datenblatt auch SPI kann oder I2C oder ... oder.. USB? eingespeist werden.
Die Gesamtgeschwindigkeit, mit der das System die Daten über den RAM hin und her verarbeitet, ist wahrscheinlich nur grob abschätzbar. Da hab ich überhaupt keine Ahnung. Ist für mich das erste Mal, das ich an so etwas brüte.
Da unsere Aufbauten doch anscheinend etwas auseinander laufen, habe ich meinen (geplanten) mal versucht aufzuzeichnen.
33676 Anklicken zum Vergößern
Die µCs holen sich vom Bus-Control die Erlaubnis die nach unten führenden Busleitungen zu den Schieberegistern und zum RAM zu benutzen. Die µCs, die keine Erlaubnis haben, müssen ihre Busleitungen auf Input schalten (hochohmig schalten).
Jeder µC hat drei SPI Leitungen (MOSI(serielle Adress Daten), SS und Clock) zu den Schieberegistern. Die Datenleitung ist zum zweiten Schieber in Reihe geschaltet.
Jeder µC hat einen 8 Bit breiten PORT über den RAM-Datenbus an den Daten I/Os des RAMs. Ob der RAM gelesen oder beschrieben werden soll wird bei meinem RAM über zwei/drei Leitungen /OE bzw /WE und eventuel CS (Output Enable, Write Enable, Chip Select) gesteuert.
Grober noch zu testender Ablauf:
µC holt sich Buserlaubnis.
µC schiebt Adressdaten über Schieberegister zum RAM
Bedient /OE und /WE (CS) des RAMs
legt oder entnimmt Daten über den RAM-Datenbus
µC gibt Bus beim Bus Controler wieder frei
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
Searcher
05.10.2018, 09:34
...
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
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
Searcher
05.10.2018, 21:11
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
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.
33684
33685
MfG
markpireus
17.10.2018, 17:25
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.
33684
33685
MfG
Interssanter Schaltplan.
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:
33721
Powered by vBulletin® Version 4.2.5 Copyright ©2024 Adduco Digital e.K. und vBulletin Solutions, Inc. Alle Rechte vorbehalten.