Ideen-Sammel-Pool

[TuxFan]

Hallo liebe Propellianer,

Ich mach hier mal einen Thread als Sammeltopf für Ideen für, mit und über den Propellerchip auf.
Da ich meistens mehr Ideen als Zeit habe, werde ich hier einige meiner Ideen veröffentlichen, für die ich wahrscheinlich keine Zeit habe diese umzusetzen. Vielleicht greift diese Idee ja jemand auf und versucht diese dann zu verwirklichen. Gleichzeitig möchte ich auch andere Löter und Programmierer einladen auch Ihren Ideen-Senf beizusteuern für den sie keine Zeit haben.

In diesem Sinne
Gruß
TuxFan

[TuxFan]

So, damit dieser Thread nicht leer bleibt gleich zwei Ideen, die mit einem Propellerchip zu verwirklichen sind.

Tastatur-Heimcomputer

Idee 1:
Beim Nachdenken über eine Tastaturanbindung an den GBP hatte ich zuerst die Idee einen Propellerchip mit einem Funkmodul RFM12B in eine PS/2 Tastatur einzubauen. Eine ganze CPU nur für diese eine Aufgabe d.h. Perlen vor die Säue werfen..... Warum nicht gleich einen SPI-Bus (Übernahme z.B.vom C3 oder GBP) inclusive der Peripherie dranhängen und dann ein SD-Funkmodul einschieben. Dann noch eine AV-Ausgabe und fertig ist der Tastaturcomputer mit Anbindung an den GBP.

und
Epson HX20 ähnlicher Nachbau

Idee 2:
Nach diesem An- oder Einfalll fiel mein Augenmerk auf den GBP der neben meiner Keysonic Minitastatur lag........
Was wäre wenn man solche kleine Tastatur mit einer LCD-Anzeige versieht und in ein Gehäuse einbaut ?
Da fiel mir der legendäre Epson HX20, dem Urvater der Notebooks, und ähnliche Computer aus der Zeit Anfang der 80'er ein. Mit der Leistung dieser Geräte könnte der Propeller eigentlich locker mithalten. Mich reizt es außerordentlich so ein Gerät zu bauen aber im Moment hat mich der GBP voll im Griff.......

Gruß
TuxFan

[yeti]

Y.1. 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:

Y.1.1 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.

Y.1.2 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...

[yeti]

Y.2. Propeller-Labor

Mit...

• http://forums.parallax.com/showthread.p ... Hz-now-!!!
• http://forums.parallax.com/showthread.p ... cilloscope
• http://forums.parallax.com/showthread.p ... Programmer

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

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

-----8<-----

Edit:

• [2011-08-11] Capacitance Meter demo on VGA
  [2011-08-11] Learning Project: Full on transistor/fet curve tracer

[drohne235]

Die Idee von einem Propellerlabor für Experimente finde ich super!

µHive

Ein Minihive, bestehend aus einem Propellerchip, Tastaturschnittstelle, Videoausgang, Sound, SD-Card UND externem RAM (512KB sollten reichen).

Das besondere an dieser Idee: Auf einer COG läuft ein einfaches Forth als OS, Compiler und Interpreter. Allerdings kein Propforth, welches ja den halben Hub-RAM belegen würde, sondern ein spezielles Forth, welches sein Wörterbuch vollständig im externen RAM verwaltet und auch von dort abarbeitet. So bleibt der Hub-RAM und die restlichen sieben COG's frei für Video, Sound und SD-Card. Nebenbei wären 512 KB für ein Forth genug Speicher auch für umfangreichere Programme. Denkbar wäre natürlich auch ein Basic welches den externen RAM nutzt.

RAM: Mit zwei Adresslatches bekommt man 24 Adressbits und es sind noch 12 Ports für IO frei:

4 Bit SD + 2 Bit Sound + 3 Bit Video + 2 Bit PS/2 + 1 Bit RAM/IO = 12 Bit

Erweiterungen können über Daten/Adressbus eingebunden werden - also ganz klassisch. Außerdem wäre noch der I2C-Bus am EEPROM nutzbar.

[yeti]

Y.3. 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.

Y.3.1. 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.

Y.3.2. 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.

----------8<----------
Edit 20120131:

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 werden schon noch ausgären...

[drohne235]

Etwas für das gut ausgerüstete Nerdlabor - das propellergetriebene Widerstandsmessgerät mit Sprachausgabe:

http://youtu.be/g77z0EQTDPE