Universelles Programmiergerät - ZIF-Sockel-Beschaltung

[Martin Lenz]

Am Wed, 19 Jan 2005 16:16:29 +0100 hat Joerg Schneide
<JSchneide@t-online.de> geschrieben:

Andreas Fester schrieb:

So ähnlich würde ich mir auch eine Relais-basierte Lösung vorstellen (1
Umschaltkontakt), und als Low-Cost-Lösung könnte man die von MaWin
favorisierte Steckkontakt-Variante realisieren indem statt
Analogschalter
oder Relais eben Jumper zum manuellen Umschalten verwendet werden.

Ich würde eher von der Jumperlösung abraten, dann lieber die
Zwischenplatinenlösung mit devicespezifischem Routing.
Es kann sonst schnell sehr ärgerlich werden wenn mal "mal eben schnell"
was brennen will und hat einen Jumper vergessen/falsch gesteckt oder
Wackler, womöglich noch bei einem OTP-Chip.
Man müsste es halt jedesmal an vielen Punkten genau richtig machen, im
Gegensatz zu einmal ein richtiges Layout und einmal die richtige Platine
einsetzten. Es wäre dann auch möglich bauteilnahe Komponenten wie Cs
unterbringen. Wenn man im Standardraster bleibt kann sich auch jeder
relativ schnell selbst was auf Lochraster fädeln.

Das ideale wäre natürlich eine niederohmige 40x40 Switchmatrix, aber
sowas gits wohl nicht in Silizium.

Switchmatrix gibt es schon in Silizium, nennt sich FPGA So niederohmig

braucht die auch nicht zu sein, weil die max. 3..4 nötigen
Versorgungsspannungen eh über andere Schalter als die Logik geroutet
werden können. Für die Logik ist wiederum die Matrix unnötig, es muß nur
sichergestellt werden, daß der Prozessor jeden Pin als Ein- und Ausgang
ansprechen kann. Er muß halt die richtigen Bits an die richtigen Pins
schreiben. Wenn du keinen Prozessor auf dem Programmer verwenden willst,
dann kannst du die Bits in einem FPGA sortieren, falls du das nicht in der
PC-Software machen willst.

Für Audio geeignete 16*16 Switchmatrizen gibt (gab?) es von AD, hat ein
Freund in einer Art Vorverstärker verbaut.

--
Martin

 

[Rafael Deliano]

Rottmerhusen ... hatte als Prozessor einen M16C62 vorgesehen,
Ich vermute für den Einplatinencomputer wäre ein antiker

CMOS-x86 mit 8 Bit ( V20 ? ) oder 16 Bit Bus günstiger.
* man kriegt Betriebsysteme/Programmiersprachen/Treiber für
x86 leichter.
* viele Leute haben schonmal auf x86 rumprogrammiert und
adoptieren ihnen bekannte CPU deshalb leichter.
* kein Cache, man kann Verzögerungsschleifen einfach
in Software programmieren. Das spricht z.B. gegen ARM
und andere CPUs mit komplexem Timing.
* man braucht nichtnur Portpins sondern langfristig auch
Schnittstellen a la USB/Ethernet oder CF-Karte.
Microcontroller reicht weder von Schnittstellen,
noch von verfügbarem Speicher.
* alte DIL-Gehäuse sind leichter einlötbar und 2lagig
routbar. In einer "Pagode" mit gestapelten Boards
kann das unterste ohnehin recht groß sein.
* relativ langsamer Bus paßt besser für Peripherie-ICs.
Die ICs für die Portpins will man ja sockeln, da
sie beschädigt werden können.
* obsolete Oldtimer die mal in Massen produziert wurden sind
langfristig bessere verfügbar. Die meisten komplexen
Controller sind Papiertiger.

Ein "offenes System" ist natürlich nur relevant wenn jemand
Grundboards in Kleinserie fertigen und andere Anwender abgeben
will. Da der "Hersteller" nicht alle Adapter selber entwickeln
kann müssten die dann von den interessierten Anwendern erstellt
werden und es sollte ein Rückfluß von Stromläufen und
dokumentierter Treibersoftware erfolgen.
Es gibt da durchaus einen kleinen Markt für sowas bei Leuten
denen Galep zuwenig und Data I/O ( pekuniär ) zuviel ist.

MfG JRD

 

[Andreas Fester]

Hallo Martin,

Martin wrote:

Am Tue, 18 Jan 2005 22:22:19 +0100 schrieb Andreas Fester
Andreas.Fester@gmx.de>:

Hallo,

ich habe mir aufbauend auf Euren Anregungen nochmals ein
paar Gedanken in Verbindung mit dem Analogschalter-Ansatz gemacht.
[...]

Danke für Deine Hinweise (auch an alle anderen natürlich vielen Dank )
Ich werde jetzt mal in dieser Richtung weitermachen, sprich ein
Analogschalter pro Pin an dem VCC/VPP geschaltet werden muss.

Analogschalter oder FETs erscheinen mir hier die beste Variante, da würde
ich mich eher mit V_var <=15V bescheiden und 4066er verwenden, um zu
sparen, anstatt ein Steckbrett zu bauen.

sehe ich genauso. In einem anderen Posting wurde ja auch von der
Jumperlösung abgeraten, mein Ziel war eigentlich von Anfang an den
Bausteintyp komplett softwaremässig auswählen zu können.

Wie machst du die restliche Logik? Schieberegister? Ein kleines FPGA, was
je nach Chip reprogrammiert wird? das wäre recht elegant, da könnte man
auch die Verriegelung der Pintreiber (Logik/Power) reinbauen, dann kann
die ľC Software keinen Mist bauen. Oder eine ľC mit vielen Pins/externen
Latches?

Momentan besteht die Logik aus einem 80552-board (hat mehr "historische"
Gründe, da ich das noch rumliegen hatte), einer Europaplatine mit vielen
Latches und den Bustreibern (244/125) und einer Platine mit der Ansteuerung
des ZIF-Sockels. Der Aufbau ist hier zu sehen, leider ist im
zusammengebauten Zustand von den einzelnen Platinen recht wenig sichtbar:

http://littletux.homelinux.org/images/pict0001.jpg

Im "Platinenstapel" links ist ganz oben die Platine mit dem ZIF-Sockel
und den Schalttransistoren für GND/VPP/VCC, diese Platine ist huckepack
auf einer weiteren Platine mit den Logik-ICs montiert und ganz unten
ist die Platine mit dem Controller mit EPROM, RAM etc.

Das schöne daran ist dass ich jetzt z.B. nur die oberste Platine mit der
neuen Ansteuerung für den ZIF-Sockel neu verdrahten muss Die ganzen
Widerstände und die Dioden fallen ja dann weg....

Der nächste Schritt ist dann in der Tat die TTL-ICs durch einen FPGA zu
ersetzen, aber erst wenn die Pintreiber richtig funktionieren ;-)

Gruss,

Andreas

--
Andreas Fester
mailto:Andreas.Fester@gmx.de
WWW: http://littletux.homelinux.org

 

[Joerg Schneide]

Rafael Deliano schrieb:

Rottmerhusen ... hatte als Prozessor einen M16C62 vorgesehen,

Ich vermute für den Einplatinencomputer wäre ein antiker
CMOS-x86 mit 8 Bit ( V20 ? ) oder 16 Bit Bus günstiger.

Wer sagt das der M16 keinen Bus hat?

* man kriegt Betriebsysteme/Programmiersprachen/Treiber für
x86 leichter.
* viele Leute haben schonmal auf x86 rumprogrammiert und
adoptieren ihnen bekannte CPU deshalb leichter.

Das ist ein Argument, wenn man denn ein Betriebssystem und komplexe
Treiber braucht. Ich denke mit C und Assembler ist man aber gut bedient.

* kein Cache, man kann Verzögerungsschleifen einfach
in Software programmieren. Das spricht z.B. gegen ARM
und andere CPUs mit komplexem Timing.

Also wenn ich es denn quick and dirty mache nehme ich auch schonmal ein
paar NOPs, das Timing scheint nicht so komplex und der Compiler nicht so
blöd das es Probleme machen würde. Aber Timer hat das Teil wirklich genug.

* man braucht nichtnur Portpins sondern langfristig auch
Schnittstellen a la USB/Ethernet oder CF-Karte.
Microcontroller reicht weder von Schnittstellen,
noch von verfügbarem Speicher.

Ähem, reichen bis zu 512k Flash und 31k Ram (bis 4MB extern) nicht?
Das Teil hat diverse Erweiterungsmodi, schau es Dir mal an.
128 Pins (abzüglich denen für den Bus, wenn man ihn nur zur
Speichererweiterung nutzt) sollten reichen, wenn nicht nimmt man den mit
100 und packt ein CPLD oder Latches dran. USB und Konsorten müsste man
auch an einen x86 extern dranstricken. Ob jemand einen Programmer mit
Ethernet braucht lass ich mal dahingestellt. Wenn man sowas um einen
alten PC-Prozessor herumbaut, könnte doch auch gleich ein "dummes"
Interface an einen PC hängen.

* relativ langsamer Bus paßt besser für Peripherie-ICs.
Die ICs für die Portpins will man ja sockeln, da
sie beschädigt werden können.

Wie wäre es mit einem Bus bei dem man dynamisch den Takt verändern,
und 0-4 Waits durch ein paar Registereinstellungen ändern kann.
Oder meinst Du Flankensteilheit?

* obsolete Oldtimer die mal in Massen produziert wurden sind
langfristig bessere verfügbar. Die meisten komplexen
Controller sind Papiertiger.

Ich denke das nimmt sich nicht viel, das Risiko das Teil plötzlich nicht
mehr oder nur teuer und mit Aufwand zu bekommen hat man immer und ob in
5-10 Jahren noch jemand sowas nachbauen will?

Aber bevor das noch in einen "Systemkrieg" ausartet: Letzlich muss der
entscheiden der die Kiste baut und programmiert. Ich bin aber
grundsätzlich bereit was beizusteuern. Und da ich mich gerade mit den
versch. M16 befasse würde es halt passen. So flexibel das Teil auch ist,
an machen Stellen muss man eben auch aufpassen.

Jörg.

 

[Robert Rottmerhusen]

Joerg Schneide wrote:

Noch ein Tip:
Ein gewisser Robert Rottmerhusen hat auch mal so ein Projekt gestartet,
vielleicht lohnt es sich ihn zu kontaktieren, er hatte eine Menge
Datenblätter und vermutlich auch schon eine Zuordnung ID-Codes zu
Parametern.

Ja, und ich bin auch da ;-))

Er hatte als Prozessor einen M16C62 vorgesehen, was ich für eine gute
Wahl halte, hat ne Menge Pins, verträgt etwas höhere Spannung
(6,5VCCabsmax/+0,3ViH), läuft bis herunter zu 2,7V, und hat so ziemlich
alles was man an Peripherie braucht.
Es gibt auch eine neue Variante (M16/62P) mit zwei getrennten VCCs, so
kann man z.B. externe 5V und 3V Peripherie ohne Probleme betreiben.

So hatte ich das mal geplant. Die Bauteile liegen hier auch noch alle.

Falls ich es doch noch mal schaffen sollte nen Programmer in Angriff zu
nehmen wird es wohl was mit nem ATMega, FPGA, USB und Relais/Codierstecker
werden.
Es sollte sich auch noch Datenlogger eignen.

FPGAs haben den Vorteil, dass die I/O Spannung extern variiert werden kann
und sich spezielle Schieberegister auch mal eben implementieren lassen.

Die ATMegas sind gross geworden und AVR-GCC taugt inzwischen auch.

Relais lösen das Problem mit den Pintreibern, Alternative wären
Codierstecker.

Der Aufbau wäre wie geplant modular. D.h.:

Sockel
------------- Adapterplatine mit Relais/Codiermöglichkeit
| |
------------- Prozessorboard mit USB + Power

Es wäre auch eine Adapterplatine mit mehreren Sockeln denkbar.

Meine mail-Adresse ist auf meine Homepage zu finden.

Grüsse
Robert

 

[Andreas Fester]

Hallo Robert,

Robert Rottmerhusen wrote:

Joerg Schneide wrote:

Noch ein Tip:
Ein gewisser Robert Rottmerhusen hat auch mal so ein Projekt gestartet,
vielleicht lohnt es sich ihn zu kontaktieren, er hatte eine Menge
Datenblätter und vermutlich auch schon eine Zuordnung ID-Codes zu
Parametern.

Ja, und ich bin auch da ;-))

wir hatten ja vor einiger Zeit schon mal Kontakt, und inzwischen
bin ich immer wieder ein Stück weitergekommen; immerhin funktioniert
der Prototyp inzwischen (eben bis auf die Probleme die diesen Thread
zum Auslöser hatten...)
Ich werde jetzt mal mit den Tips die ich hier erhalten habe weitermachen,
insbesondere was die Analogschalter anbelangt. Falls Du immer noch
an Erfahrungsaustausch interessiert bist, meine Mail-Adresse hat sich nicht
geändert....

Gruss,

Andreas

--
Andreas Fester
mailto:Andreas.Fester@gmx.de
WWW: http://littletux.homelinux.org

 

[Rafael Deliano]

Aber bevor das noch in einen "Systemkrieg" ausartet ...
Wie andere Teile des Threads zeigen sind die Vorstellungen

bezüglich CPUs recht unterschiedlich.
Bei mir lief das bisher auf 6502 was für PIC16Cxx mit ihren
4k Speichern gangbar war. Bei den 68HC908 reicht der 6502
sowohl von der der 64k MemoryMap als auch von der
Geschwindigkeit nichtmehr, sodaß der nächste Schritt eine
16 Bit CPU samt CF-Karte ist.

Schnittstellen a la USB/Ethernet
Ob jemand einen Programmer mit Ethernet braucht
Wer Software auf PC compiliert braucht ein Kabel zum

Programmiergerät. Der übliche Parallelport scheint nicht so
üppig. Eventuell ist Ethernet leichter programmierbar als
USB, probiert hab ichs allerdings noch nicht.

M16C62
Ich denke mit C und Assembler ist man aber gut bedient.
Da ich FORTH und Assembler verwendet müsste ich das FORTH erst

portieren, was aber prinzipiell möglich ist. Soweit ausreichend
Programmspeicher ( d.h. zusätzlich 20 - 32kByte ) verfügbar sind
kann man es unschwer neben C installieren. Funktionsaufrufe
von Unterprogrammen unterschiedlicher Programmiersprachen sind
normalerweise auch machbar, wenn die Schnittstellen dokumentiert
sind.

Bezüglich der Hardware ist der Aufwand natürlich im Einplatinen-
computer maximal, während aufsteckbare Anschaltungen recht simpel
sind. Der 16 Bit Einplatinencomputer hat aber wenig Anforderungen
die ihn von üblichem Einplatinencomputer für andere Anwendungen
unterscheiden.

MfG JRD