RAM-Baustein

[HaWe]

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?

[Moppi]

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!

[HaWe]

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.

[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.

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:



Dass Du auch immer so neugierig sein musst! Ich sehe was, was Du nicht siehst

[Searcher]

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 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

[PICture]

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?...x_Dec_Wandlung.

[HaWe]

Hallo!
Natürlich, ist aber nicht simpel: https://rn-wissen.de/wiki/index.php?...x_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).

[Moppi]

@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