Ethernet auf IEEE-488 Gateway

Aeh. Ja. schaut gut aus. Ich bestell mal eins ...

hbloed schrieb:

> Hardware:
>
> ATMega90CAN128
> ENC28J60 Ethernet Controller

Eine schlechte Wahl. Ein 90CAN128 kostet bei Farnell etwa 17 Euro. Dazu 
kommt noch der ENC28J60 für 2-4 Euro je nach Bauform.

Ein TI/Luminary Micro LM3S8930 kostet dort 9.32 Euro und damit etwa die 
Hälfte, hat gleich 10/100 Ethernet inkl Phy(!), 2*CAN, 256k Flash und 
64k RAM eingebaut und ist viel viel leistungsfähiger.

fchk

bei 1mbit can ist ein avr ein wenig zu langsam... der enc ethernet 
controller ist auch steinzeitlich..
sinnvoller wäre ein aktueller 32bit prozessor mit integrierten 
can+ethernet

Ich hab auch so'n Projekt gestartet. Die Hardware existiert schon. 
Serial zu IEEE488. Der Mega32 darf dann den 488 Master spielen. Ich 
wuerd dann etwas hoehere Befehle auf dem Mega installieren, sodass man 
etwas weniger Bandbreite zum PC braucht. Der PC soll sich nicht mehr um 
Listener/Talkener kuemmern, sondern nur noch Anfragen senden.

hbloed schrieb:
> Schoenes Teil aber, Farnell verkauft mir nix,

Dann halt woanders. DIgikey, Segor, etc.

> Den AVR möchte ich verwenden weil der einfacher zu bekommen ist,
> für weniger als 17€. Dafür habe schon reichlich Treiber einen
> Emulator und eine Entwicklungsumgebung.

... und einen passenden Horizont. Bei Dir reichts noch nicht mal für 
einen Olimex oder OpenOCD USB Adapter.

Wer nur einen Hammer hat, für den sieht alles wie ein Nagel aus.

Für den PC gibt es IEEE488 ( oder auch IEC.Bus ) Einsteckkarten oder 
Adapter IEEE488 auf USB mit den erforderlichen Treiber von namhaften 
Firmen wie Agilent, National usw. Auch bieten Diese Firmen IEEE488 auf 
Netzwerk Adapter an. Diese findet man unter anderen gebraucht in der 
Bucht. Es macht eigentlich kein Sinn das Rad neu zu erfinden.

Wer Messgeräte oder ähnliches mit dem IEEE488 Anschluss bauen wille, für 
den bietet National fertige Asics an die sich ähnlich verhalten wie der 
abgekündigte Nec2710. Diese Asics übernehmen das komplette Handshaking 
und noch einiges mehr. Sie werden wie andere 
Mikroprozessorperipheriebausteine
auch über Register angesprochen und besitzen zum Mikroprozessor 
Handshakeleitungen. Somit macht es auch hier keinen Sinn solche 
Schnittstellen komplett selbst zu entwickeln.

Ralph Berres

>Wer keine Ahnung hat sollte sich besser nicht zu Worte melden


Jetzt halte erst mal den Ball flach. Auf diesen Niveau bin ich nicht 
gewillt weiter mit dir zu schreiben.



heinbloed schrieb:
> Nec2710 -> upD7210 oder?

upd 2710 stammt von Nec. Bei National heist er jetzt nat2710

heinbloed schrieb:
> NI verkauft nix an Endverbraucher und auch an Firmen nix in geringen
>
> Mengen

Es gibt Entwicklungsmuster bei National. Die beinhalten 2 Stück. Kosten 
irgendwas an 40 Euro. Ansonsten Mindeststückzajl 10 Stück.

Auch als Privatman kann man die bekommen , wenn man höflich drumm 
bittet, und denen erklärt was man vorhat. Ansonsten kann man sich ja als 
Student ausgeben.

Was das Handshaking betrifft gebe ich dir recht. Es gab von Phillips 
einen Controller der ohne Mikroprozessor auskommt HEF 4738 der hatte ein 
echtes Handshaking.  Den hatte ich in Erinnerung.

Im übrigen ist mir der IEC-Bus schon geläufig, ich steuere an die 20 
Messgeräte darüber.


Ralph Berres

hbloed schrieb:
>> Es gibt Entwicklungsmuster bei National. Die beinhalten 2 Stück. Kosten
>
>> irgendwas an 40 Euro. Ansonsten Mindeststückzajl 10 Stück.
>
>
>
> Das stimmt so nicht. 9 Stück 249€ + versand + mwst. Für so ne
>
> alte Gummer. Ich hab davon noch 2 Stangen, ich wollte aber was
>
> machen was jeder nachbauen kann.

Schade das ich das schriftliche Angebot von NI nicht mehr habe.

Genau für diese Fälle , wenn jemand nicht eine ganze Stange von den 
Kontrollern kaufen will gibt es ein Entwicklungskit welche 2 Stück von 
diesen ICs beinhaltet. So war es jedenfalls vor 2 Jahren.

NI scheint übrigens mittlerweile der einzige Anbieter solcher Kontroller 
auf dem Markt zu sein. Ines hatte auch mal sowas angeboten. Aber die 
scheinen abgekündigt zu sein.

Ralph Berres

das ist natürlich doof. Ich hatte irgendwann vor , eine IEC-Bus 
Schnittstelle für mein Labornetzteil zu entwickeln.

Siehe
http://www.et.fh-trier.de/diplom/Team/berres/downloadbereich/Bauanleitungen%20Messtechnik/Labornetzteil%200-30V%200-4Amp/

Das wäre dann das Sahnehäubchen gewesen.

Ralph Berres

hbloed schrieb:
> Schoenes Teil aber, Farnell verkauft mir nix,

Klar, über den HBE-Shop.

Ich hatte so ein Projekt auch mal gedanklich eruiert, ich hätte sogar
den zeitkritischen IEEE488-Krams ggf. in ein CPLD gepackt.  Am Ende
war es einfacher und schneller realisiert, mir eine billige ISA-
Karte für IEEE488 zu kaufen und diese in den Bastelrechner zu
stopfen.

Den IEEE488 Bus kann man doch in Software machen wenns den Controller 
nicht mehr gibt. Den IEEE488 in Software war damals bei den Commodore 
Computer recht verbreitet. Und tackerte eine 1MHZ 6502 CPU im inneren.
Ok den maximalen Speed gabe es damals halt nicht. Aber mit den heutigen 
32 Bit Controller sollte es doch schneller gehen. Man koennte alles in 
einen Cortex Prozessor von TI unterbringen (Ethernet , CAN ,RS232) und 
den IEEE488 an den Port per Software emulieren.

Jörg Wunsch schrieb:
> Am Ende
>
> war es einfacher und schneller realisiert, mir eine billige ISA-
>
> Karte für IEEE488 zu kaufen und diese in den Bastelrechner zu
>
> stopfen.

Das Problem ist ja nicht der Rechner, sondern das zu steuernde Gerät was 
man damit ausrüsten will. Aber du hast eigentlich recht. Irgend eine 
alte IECbusKarte aus der Bucht den Controller ausschlachten nebst 
Treiberics.

Helmut Lenzen schrieb:
> Man koennte alles in
>
> einen Cortex Prozessor von TI unterbringen (Ethernet , CAN ,RS232) und
>
> den IEEE488 an den Port per Software emulieren.

Unterschätze den IEC-Bus nicht. Was der Controller alles bewältigen muss 
ist nicht von schlechten Eltern. Sicher kann man ein paar wenige 
Funktionen die Software selbst schreiben, aber schon das drei Draht 
handshaking ist nicht ohne. Wenn man dann noch die ganzen Gerätebefehle 
implementieren will ist das schon eine Herausforderung. Sicher auch für 
einen erfahrenen Programmierer wie du es glaube ich bist.
Nicht umsonst hat es eine ganze Reihe spezieller IEC-Bus Controller 
gegeben, die einen das alles abgenommen hat.

Ralph Berres

Ralph Berres schrieb:
> Wenn man dann noch die ganzen Gerätebefehle
> implementieren will ist das schon eine Herausforderung.

Du must das ein bisschen trennen.
Der Controller setzt einfach Kommandos die ueber die Ethernetbus kommen 
1:1 auf den IEEE um. Die Geraetebefehle koennte man dann in die PC 
Software verlagern. Wenn man sich die Plaene von HP/Agilent mal anschaut 
da haben die das teilweise sogar in TTL Hardware gemacht. Soviel 
Intelligenz kann man aber auch nicht in der damaligen Hardware einbauen. 
Also wurde dort auch der groesste Teil in der Software des Controller 
realisiert. Erst in den etwas neueren Modellen haben die dann einige 
Controller verbaut (unter anderem TI und Motorola).
Ich bin selber am ueberlegen sowas zu bauen um meinen HP Geraetepark an 
meinem PC zu bekommen. Ich koennte dazu eine ARM Prozessorkarte fuer 
verwenden die ich letztens entwickelt habe (allerdings in der Form keine 
IEEE488 Treiber ICs drauf) (LM3S8938 von TI)

Ehrlich gesagt bin ich da tatsächlich ein wenig überfordert, das zu 
verstehen, wie das funktioniert. Der IEC Bus unterscheidet ja zwischen 
den
 übermittelten Daten und Gerätebefehle. Die unterscheiden sich ja in dem 
eine der Leitungen auf 1 gesetzt wird. ( Ich weis jetzt auswendig nicht 
gerade welche, könnte das ATN sein ? ). Die Gerätebefehle sind ja für 
den IEC Bus allgemeingültige Befehle wie SPD, GTL und so weiter. Dafür 
muss glaube ich ATN gesetzt sein. Die Daten sind dann die Befehle die 
der Mikroprozessor des Gerätes decodieren und ausführen muss. Beides 
sind allgemein Ascibefehle. Die Datenbefehle können aber auch binär 
sein.

Wie man das aus dem Ethernetprodokoll auseinander klabüstert, habe ich 
nie gerafft, sondern immer nur erstaunt zur Kenntnis genommen, das sowas 
offensichtlich funktioniert. Ebenso das Handshaking auf dem IEC Bus was 
ja auch nicht so ganz trivial ist. Ich hatte mal Wochen damit verbracht 
einen Hänger auf dem IEC-Bus mit dem Logiganalyzer zu finden.

Ich selbst benutze noch eine alte HP82335 Karte unter Win3.11, weil ich 
von HP einen Basic Interpreter besitze, was einen das Steuern der 
Messgeräte ungemein erleichtert. Ich hab das mal mit Visualbasic 
versucht, und nach 4 Wochen entnervt aufgegeben.

Ralph Berres

Ralph Berres schrieb:
> Aber du hast eigentlich recht. Irgend eine
> alte IECbusKarte aus der Bucht den Controller ausschlachten nebst
> Treiberics.

Dummerweise haben die neueren (selbst ISA-)Karten zwar noch die
"klassischen" Treiber-ICs, aber die Logik ist dort schon als
(offenbar) Makrozelle in ein dickes ASIC gewandert, statt separat
als µPD7210/NAT7210 vorzuliegen.  Du könntest dann höchstens gleich
die ganze ISA-Karte nutzen, am Ende ist ISA ja ein relativ
Microcontroller-freundlicher Bus.

Als ich das letzte Mal geguckt habe, gab's noch irgendein TNTxxx
von NI, das explizit dafür gedacht war, in Geräte integriert zu
werden.  Im Vergleich zu den ICs, die auf den PC-Karten verbaut
werden (derzeit TNT5004), fehlt diesem IC die Fähigkeit, Controller
am Bus zu werden, es kann nur Listener oder Talker werden.  Allerdings
siehe oben, NI war noch nie billig, und der Devkit dafür wird sicher
eine gute Stange Geld kosten.

ATN heist jetzt kommt einen Addresse.

Im Ethernetprotokoll sind ja weitere Protokolle versteckt.
Wenn du zum Beispiel eine WEB Seite aufrufst dann geschieht das ueber 
das HTTP Protokoll das ist wiederum in das TCP Protokoll verschachtelt. 
Das TCP wiederum im IP Protokoll und das wiederum im Ethernetprotokoll.

Ich habe da schon selber unter TCP/IP eigene Protokolle aufgesetzt um 
mit Geraeten uebers I-Net zu kommunizieren. Man muss sich halt ein 
Protokoll einfallen lassen das die Ansprueche an die 
Geraetefernbedienung unterstuetzt.
Das ist aber mehr eine Definitionsfrage b.z.w. Fleisarbeit.
Wenn man dann die Verbindung zu einem Geraet aufgebaut hat braucht man 
ja nur noch die ASCII Befehle zu schicken und los gehts. Dann koennte 
man uebers I-Net deinen Geraetepark fernbedienen. Im PC setzt man dann 
nur noch auf die Netzwerksachen auf. Was dann kommt sind halt 
Anwenderprogramme.
Also zum Beispiel die Fernsteuerung einens Skopes. Das Anwenderprogramm 
mit der Oberflaeche setzt seine Kommandos an das Netzwerkinterface des 
PC ab. Der geht ueber Ethernet/I-net an den Controllerchip. Der setzt 
dann auf IEEE488 um und fragt das Skope ab. So kann man dann auf dem PC 
ein virtuelles Skope nachbilden. Man muss die Aufgaben nur verteilen.

Ralph Berres schrieb:
> Wie man das aus dem Ethernetprodokoll auseinander klabüstert, habe ich
> nie gerafft, sondern immer nur erstaunt zur Kenntnis genommen, das sowas
> offensichtlich funktioniert.

Das sieht auf dem ersten Blick da muss ich dir recht geben sowas von 
Kompliziert aus. Aber wenn es einmal funktioniert dann laeuft es recht 
zuverlaessig. Da habe ich frueher schon mehr Zeit mit der RS232 
vertroedelt. Besonders da hat fast jeder Hersteller sein eigens 
Sueppchen gekocht.

hbloed schrieb:
> Ich hab einen ganzen Keller
>
> von HP Geräte, da drin werkelt wenn es hoch kommt mal ein 8048 oder
>
> ne UPI also Teile aus der Steinzeit. Meistens können die Geräte
>
> sowieso keine Daten in einer höhren Rate senden.

Naja gerade die älteren Geräte wenn Sie nicht gerade vor 1975 gebaut 
sind, verfügen in der Regel eine IEC-Bus Schnittstelle. Ich weis nicht 
ob es sich wirklich lohnt ein Interface zu bauen , welches die IEC-Bus 
schnittstelle in USB EThernet oder ganz gleich welche Norm umsetzt.

In der Regel bekommt man relativ preiswert fertige IEC Bus karten für 
den PC von Agilent oder NI in der Bucht zu kaufen. Da lohnt der Aufwand 
meines Erachtens nicht, sowas selbst zu stricken.

IECbus kabel bekommt man oft in der Bucht auch für 10 euro oder manchmal 
noch weniger. Treiber für die IECbuskarten gibt es meist beim Hersteller 
der Karten für alle möglichen Programmiersprachen.

Ralph Berres

@ hbloed

Du hast auch einen Keller voll von HP ?
Na soviel ist es bei mir nicht.

Aber wie ich schon geschrieben hatte. Bei den meisten Geraeten war das 
mit einer Handvoll TTL und einem langsamen Prozessor realisiert.
Die ersten Homecomputer von Commodore hatte auch einen IEEE488 Bus fuer 
Drucker und Diskettenlaufwerke.

>Deshalb ist die
>ganze Diskussion um 100Mbit Ethernet, 32Bit Risc, Armcore sowieso
>"oversized".

Das mag schon sein, aber das ist heute alles in einem Chip mitdrin.
Und die Teile kosten fast nichts warum soll man das den nicht nutzen.

Um SMD wirst du heute kaum noch rumkommen. Bei mir wird zu fast 100% nur 
noch SMD eingesetzt.

Helmut

Hatten die Commodore nicht eine serielle IEC Bus schnittstelle?

Wie haben die das dann mit den ganzen Mehrdrahtbefehle realisiert? und 
wie haben die das Handshaking gemacht, das auch mehrere Geräte an einen 
Bus betrieben werden konnte?

Aber ich mus zugeben das ich nicht der geborene Softwarespezialist bin.

Ralph Berres

Ralph Berres schrieb:
> Hatten die Commodore nicht eine serielle IEC Bus schnittstelle?

Die kleinen Commodore  C64 , VC20  hatten einen Seriellen IEC Bus.
Die grossen CBM 2xxx,4xxx,8xxx hatten einen parallel IEC-BUS

Ralph Berres schrieb:
> Wie haben die das dann mit den ganzen Mehrdrahtbefehle realisiert? und
> wie haben die das Handshaking gemacht, das auch mehrere Geräte an einen
> Bus betrieben werden konnte?

Wie gesagt das hatten die alles in Software realisiert. Als 
Schnittstelle hatten die nur die normalen IEC-Bus Treiber ICs (MC3446) 
und eine PIA 6520 zum Prozessor hin.

Hier die IEC Bus Anbindung vom 2001

http://www.zimmers.net/anonftp/pub/cbm/schematics/computers/pet/2001/320130-1.gif

Hier die vom 8032

http://www.zimmers.net/anonftp/pub/cbm/schematics/computers/pet/8032/8032029-02.gif

Und hier die von einer 4040 Floppy

http://www.zimmers.net/anonftp/pub/cbm/schematics/drives/old/4040/320806-1.gif

Der Rest ist bei denen Software gewesen. Waere auch sonst zu teuer 
geworden.

Helmut Lenzen schrieb:

>>Deshalb ist die
>>ganze Diskussion um 100Mbit Ethernet, 32Bit Risc, Armcore sowieso
>>"oversized".
>
> Das mag schon sein, aber das ist heute alles in einem Chip mitdrin.
> Und die Teile kosten fast nichts warum soll man das den nicht nutzen.

eben.

> Um SMD wirst du heute kaum noch rumkommen. Bei mir wird zu fast 100% nur
> noch SMD eingesetzt.

Zumal der Originalvorschlag auch einen LQFP64 Controller beinhaltet, bei 
dem der übliche Bastler auch schon die weiße Fahne schwenkt. Da gleich 
was vernünftiges in aktueller Technik zu nehmen, kostet (a) eher weniger 
als mehr und ist (b) genauso viel bzw eher weniger Aufwand beim Nachbau, 
weil einfach weniger Komponenten benötigt werden.

Für die von mir vorgeschlagenen TI/Luminary Cortex M3 Controller gibts 
fertige Bibliotheken für die Peripherie 
(http://focus.ti.com/mcu/docs/mculuminarymodules.tsp?sectionId=625&tabId=2494&familyId=1755) 
und IP-Stacks. Ist also auch alles da.

Die GPIOs sind 5V-tolerant, d.h. die 75160/161 Treiber können direkt 
angeklemmt werden.

Wieso dann noch was schlechteres nehmen?
Nur, weil man es nicht kennt und nicht kennen lernen will?

fchk

Hier noch einer mit 75160/161 Treibern

http://www.zimmers.net/anonftp/pub/cbm/schematics/computers/b/4256041-10of15.gif

Frank K. schrieb:
> Für die von mir vorgeschlagenen TI/Luminary Cortex M3 Controller gibts
> fertige Bibliotheken für die Peripherie
> (http://focus.ti.com/mcu/docs/mculuminarymodules.ts...)
> und IP-Stacks. Ist also auch alles da.
>
> Die GPIOs sind 5V-tolerant, d.h. die 75160/161 Treiber können direkt
> angeklemmt werden.

So seh ich das auch. So in etwa saehe auch meine Schaltung aus.
Die Teile von TI sind nicht schlecht. Hatte letztens mit dem LM3S8938 
ein Testboard aufgebaut um damit mal rumzuspielen. Da hatte ich fast 
jede Schnittstelle mal rausgefuehrt. Mit ein bisschen weglassen / anders 
anschliessen koennte man das Teil dafuer schon fast nehmen.

Ralph Berres schrieb:

> Helmut Lenzen schrieb:
>> Man koennte alles in
>>
>> einen Cortex Prozessor von TI unterbringen (Ethernet , CAN ,RS232) und
>>
>> den IEEE488 an den Port per Software emulieren.
>
> Unterschätze den IEC-Bus nicht. Was der Controller alles bewältigen muss
> ist nicht von schlechten Eltern. Sicher kann man ein paar wenige
> Funktionen die Software selbst schreiben, aber schon das drei Draht
> handshaking ist nicht ohne. Wenn man dann noch die ganzen Gerätebefehle
> implementieren will ist das schon eine Herausforderung. Sicher auch für
> einen erfahrenen Programmierer wie du es glaube ich bist.
> Nicht umsonst hat es eine ganze Reihe spezieller IEC-Bus Controller
> gegeben, die einen das alles abgenommen hat.
Bei uns in der Firma haben letztens 3 Praktikanten einen GPIB Controller 
mit PSoC Controller komplett in SW realisiert. Und das waren welche die 
vorher noch nie C Programmiert haben. Hab denen natürlich ein wenig 
weiter geholfen, aber sooo kompliziert war das nicht.
Wichtig war nur was genaueres über die GPIB Funktionen zu finden. Ohne 
ein Buch (IEC - Bus / Anton Piotrowski) wäre das wirklich schwierig 
geworden.

Ansonsten gibt es hier auch schon ein Projekt für AVR:
http://spurtikus.de/basteln/gpib.html

Also von mir ist schon ein Schaltplan gekommen.
Da braechte man nur einen Port einen IEEE488 Treiber anzuschliessen.
Allerdings habe ich noch andere Projekte laufen womit ich meine 
Broetchen verdiene und die gehen vor.

@hbl

Anstatt zu moppern kannst du ja selber aktiv werden.