Dies ist eine alte Version des Dokuments!


Fermenter

Hier gären Ideeën.


Proptuberanzen

Eine Propeller-Grundausrüstung zum Breadboarden und die am häufigsten wiederkehrend gebrauchten Baugruppen als Breakoutboards oder wo es noch stabiler sein muß als externe Komponenten die per (Flachband-)Kabel mit den experimentellen Aufbauten verbunden werden.

Dies bietet mehere Optionen:


Proptuberanzen-DIY

Eine Einführung ins Propellern begleitet den Einsteiger sowohl beim Zusammenstellen und Aufbau dieses Baukastensystemes aus einfachen Zutaten wie Punktrasterplatinen für die Breakout-Boards sowie bei der Erkundung der Komponenten und bietet so auch nebenbei die Einführung in die Programmierung.

Proptuberanzen-ReadyToGo(-Kit)

Ein Starterkit aus Propeller, Breadboard, Breakouts und ein paar weiteren losen Bauteilen wird definiert, zusammengestellt und en bloc verteilt.

Dieser Starterkit wird aus den durch Proptuberanzen-DIY gewonnenen Erfahrugen entstehen.

Als Zielgruppe kämen somit auch die nichtlötenden Propellerneugierigen in Frage, was mir schon genug Existenzberechtigung für diese Idee scheint.

Optional kann dies aus den Bauteilen und nackigen Platinen bestehen für die die zwar selber löten mögen aber lieber schöne Breakout-Boards möchten statt der nicht ganz so schmucken Selbstbauten die bei Proptuberanzen-DIY entstehen oder aber als ein wirklichliches Fertigprodukt daherkommen.

Vielleicht findet sich ja wer, der nach den Erfahrungen mit Proptuberanzen-DIY dies für eine gute Idee hält und es mal wagt. Dafür sollten die Lizenzbedingungen gleich offen genug gehalten werden, aufdaß der Mutige dann nicht auch noch zum unternehmerischen Risiko einen Anwalt braucht zur Klärung dessen was er damit machen darf oder nicht darf…


Propeller-Labor

Mit…

…stehen offensichtliche Beispiele bereit die zeigen daß man den Propeller auch auf der anderen Seite der Projekte einsetzen kann, also nicht als Objekt der Bastelei sondern als Meßgerät oder Werkzeug in anderen Projekten.

Weitere Ideeën wie z.B. V/A/F/H/…-Messung liegen nahe genug um sie hier demonstrativ unerwähnt lassen zu können! :D

Zunächst sollte man mal überlegen was davon sinnvoll vereint werden kann und was unbedingt ein eigenständiges Gerät bleiben muß oder ob sich mit einem Labor-Bussystem und einer komfortablen Bedienung über ein steuerndes Terminal sogar mehr Vorteile ergeben…

Ich hab immer ein Platzproblem und wenn viele nützliche Helferlein in einem Gehäuse dennoch gleichzeitig nutzbare Werkzeuge (Prommer & Co) und Meßgeräte bieten würden, könnte ich evtl schneller voran kommen als in meinem bisherigen Chaos bzw. teils auch Meßgerätemangel…

Damit steh ich wohl auch nicht so ganz alleine da…


SPI-zu-Parallelbus-Interface

Im Umfeld von Meßdatenerfassung ist schnell sequentiell schreibbarer Speicher von Nöten und im Unfeld der Emulatoren (ZiCog, ZOG, MoCog, qz80, …) sind größere Adreßräume möglichst schnell adressierbaren Speichers als der Propeller selbst zu bieten hat auch unverzichtbar um mehr als eine Proof-of-Concept-Implementierung abzuliefern.

Im Meßdatenerfassungsbereich herrscht das sequentielle Schreiben vor und im Umfeld von Emulationen der wahlfreie Zugriff (random Access).

Ich vermute daß die Schaltung so aufwendig wird, daß ein einer eigener Microcontroller zum Einsatz kommen sollte und es letztlich dann kaum noch einen Unterschied in der Komplexität macht ob man die beiden folgenden Fälle getrennt betrachtet, denn die Umsetzung würde sich nur in der Programmierung des zu Hilfe gerufenen Microcontrollers unterscheiden.

Sequentieller Zugriff

Hier mag man auf die Idee zu kommen doch einfach einen z.B. 64MBit SPI-Flash Chip zu nehmen, aber nach der 10000sten Messung des selbstgebauten Speicheroszilloskopes ist dann eventuell der Flash-Chip schon abgenutzt. Ein Blick auf die Preise und die Zeitspanne in der man für sich erwartet 10000 Messungen zu erledigen relativiert das Problem vielleicht und man bevorzugt billigen Flash-Speicher auf einer schnell wechselbaren Steckkarte statt mittels eines komplexen Interfaces z.B. SDRAM auf SPI abzubilden? Technisch bietet ein Anschluß größerer SPI-Speicherchips (heute nunmal überwiegend FLASH) bis auf den Ausfall durch Abnutzung schon eine vielleicht manchmal akzeptable Lösung.

Universalbus

Ansteuerung sovieler Leitungen dieses Busses wie möglich direkt oder in gelatchten Gruppen aus Propellerpins ist bisher der übliche Weg größere Mengen externen Speichers zu adressieren. Man verliert nur tendenziell alle Propellerpins wenn man auf Geschwindigkeit fokussiert. Die nichtsequentielle Reihenfolge des Zugriffes steht mehr als nur quasi im Widerspruch zu den Vorteilen des Zugriffs per SPI wegen der wiederholt anfallenden Übertragung neuer Read/Write-Kommandos und der zugehörigen Adressen. Hier bieten sich Experimente mit VMCog an um ein lokales Cache zu schaffen und außerdem ist eine Hardwareunterstützung im noch zu definierenden SPI-Interface denkbar, die z.B. 2^n Adressregister umfaßt um die wiederholte Übertragung langer Adressen auf eine Registernummer 0…n und gegebenenfalls einen Offset dazu zu verkürzen. Mit auf Geschwindigkeit getrimmten SPI-Routinen, einem geeigneten Befehlssatz im Bus-Controller und als allerletze Maßnahme (wenn dann überhaupt noch nötig) VMCog als Cache im Hub-RAM einen 32bittigen ECBus schaffen würde die Tür zur parallell ansteuerbaren Welt jedenfalls weit öffnen.

Nachtrag 2012-01-31:

Es scheint per Atmega8515 oder Atmega162 gar nicht so schwer umzusetzen sein. Diese Atmegas sind im hobbyistenfreundlichen DIP40-Gehäuse verfügbar und haben das sogenannte XMEM-Interface mit dem sie externen Adreßraum nutzen können. Bei beiden µCs sind das fast 64kBytes, denn etwas Überlapp mit internem Speicher ist nicht direkt nutzbar. Dieser Verschnitt oder Mehraufwand läßt sich durch Bereitschaft in Bänken zu adressieren (32k oder kleiner) aber leicht umgehen. Auf diesem Umweg wäre ein fast-64k-Adreßraum oder im gebankten Fall sogar noch reichlich mehr leicht auf SPI abbildbar.

Über die reine Bereitstellung des parallelen Busses per SPI hinaus sind auch die Speicherverwaltung unterstützende Routinen denkbar (ähnlich Blitter des Atari-ST), Der Atmega ist damit sicherlich noch nicht an seine Leistungsgrenzen getrieben, ein USBStick- oder Festplatten-Interface, das das ganze Speiuchermedium als linearen Adreßraum darstellt wäre ebenso denkbar.

Weitere Ideeën hierzu werden schon noch ausgären…


users/yeti_fermenter.1328008405.txt.gz · Zuletzt geändert: 31.01.2012 12:13 (Externe Bearbeitung)
 
Falls nicht anders bezeichnet, ist der Inhalt dieses Wikis unter der folgenden Lizenz veröffentlicht: GNU Free Documentation License 1.3
Recent changes RSS feed Donate Powered by PHP Valid XHTML 1.0 Valid CSS Driven by DokuWiki