Post subject: Re: Physikalische Grundlagenfrage...
Posted: 2003-07-15 08:13:31
Replies: 11 Views: 2042
Moritz Erbsloeh wrote:
> Die es prallen chaotisch gegen die Atomrümpfe und folgen tendentiell
dem von
> außen auferlegten E-Feld, am Verzweigungspunkt gibts ein
stärkeren Gradienten
> im Feld, und das e was weiter links ist geht dann nach links, z.B.
Das ist nicht ganz richtig so. Der Tunneleffekt erlaubt es z.B.
durchaus einem Elektron, das sich "weiter links" befindet, dennoch
spaeter im "rechten" Widerstand gefunden zu werden.
Ich habe die Tage beim Kramen in meiner Bastelkiste ein Bauteil ge-
funden, ueber dessen Funktion ich mir nicht ganz im klaren bin.
Es sieht aeusserlich aus wie eine Fotowiderstand, aehnlich dem hier: http://www.conrad.de/IMS Docs/D5/D564953E444A79AEE10000000A010251.JPG,
nur das es drei Anschluesse und eine doppelte rote "Schlangenlinie"
auf seiner Oberflaeche besitzt.
Der Widerstand des Bauteils aendert sich bei Lichteinfall, und zwar
zwischen allen Paaren von Anschluessen.
Handelt es sich hierbei um eine Art integrierte Reihenschaltung von
zwei LDRs? Weiss jemand genaueres ueber so ein Bauteil?
Nachdem ich nun schon stundenlang Googel gequaelt und die Webseiten
aller mir bekannten Halbleiter-Hersteller durchforstet habe, bin ich
langsam der Meinung, dass sich "Highspeed" und "Low power"
offenbar
prinzipell gegenseitig ausschliessen...
Oder kann mir jemand von Euch einen Tip geben?
Ich suche ein SRAM, 512kx16 mit 12ns Zugriffszeit und einem
Stromverbrauch im Betrieb von moeglichst deutlich unter 100mA. Preis
spielt keine Rolle.
>> Oder kann mir jemand von Euch einen Tip geben?
>> Ich suche ein SRAM, 512kx16 mit 12ns Zugriffszeit und einem
>> Stromverbrauch im Betrieb von moeglichst deutlich unter 100mA.
> der Platine umzuladen. Was produziert die Daten mit dieser
> Geschwindigkeit? Ein Mikrokontroller oder DSP? Ist es möglich
> eine Variante desselben mir genügend internem RAM aufzutreiben?
Das RAM wird von nem Microcontroller verwendet. Ich glaub, ich muss
an der Stelle ein Bisserl ausholen:
Es geht darum, in ein internationales Forschungsprojekt eigene Sen-
soren einzubauen, die an unserem Institut entwickelt werden. Von der
Kollaboration haben wir die Erlaubnis dazu erhalten, unter der Be-
dingung, dass wir am restlichen Detektordesign nichts (bzw. nur mar-
ginalst) was veraendern. Der Microcontroller steuert nun einen be-
stimmten Teil dieser Sensoren, der leider die unangenehme Ei-
genschaft besitzt, dass der Rest des Detektor mehr oder weniger
steht, solange der uC aktiv ist. Diese Tatsache liegt leider im De-
sign des Detektors begruendet und ist nicht aenderbar. Darum soll
der uC das was er tut moeglichst schnell tun - daher die 12ns. :-)
> Warum muß es eigentlich so sparsam sein? Die (Wasser-)kühlung
> sollte bei euch doch kein Problem sein? ;-)
An der scheiterts nicht, noe :-)
Es ist kein Problem der Kuehlung sondern es liegt schlicht daran,
dass nicht mehr Strom zur Verfuegung steht.
> Das muß aber ein recht schneller uC (mit entsprechendem
Stromverbrauch)
> sein wenn der das RAM tatsächlich mit 80MHz ansprechen kann?
OK, 12ns sind vllt. a bisserl uebertrieben. Der uC laeuft mit bis
zu 50MHz und ist dabei relativ sparsam ("STR710" von ST).
> Hast du Zugriff auf den uC? Dann kann man die seltsame Programmierung
> ändern die beim Speicherzugriff sonst alles blockiert?
Aeh, ne, da hast was falsch verstanden. Das ganze liegt nicht an der
"seltsamen Programmierung" des uC. Den programmieren wir schon sel-
ber so, wie wirs brauchen. Das ganze liegt am Design der Kommunika-
tion zwischen Detektor und Kontrollzentrum. Die ist einfach so ge-
baut, dass die Datenerfassung steht, sobald (wirklich im physikali-
schen Sinn) die Leitungen benutzt werden, die zu unserem uC fuehren.
Und daran koennen wir nix aendern.
>> Es ist kein Problem der Kuehlung sondern es liegt schlicht daran,
>> dass nicht mehr Strom zur Verfuegung steht.
> Wenn der Strom nicht aus einem Akku kommt, liegt der max Strom am
> Netzteil oder sind die 100mA nur eine Definition?
Es liegt am "Netzteil". Das liefert nur einen maximalen Strom. Und
abzueglich all dem, was von den Sensoren und der Datenerfassungs-
und auswertelektronik verbraten wird, bleiben grad noch so in der
Gegend von 90-100mA fuers RAM uebrig.
Es handelt sich uebrigens nicht um ein "Netzteil" im herkoemm-
lichen Sinn, sondern ebenfalls um eine relativ komplizierte Strom-
verteilungsapparatur innerhalb des Detektors. Also nix mit "einfach
ein groesseres Netzteil anschliessen". :-)
> Das RAM braucht den Strom nur wenn man tatsächlich so schnell
> taktet. Anscheinend greifst du nur hin und wieder darauf zu,
> dann sinkt natürlich der mittlere Stromverbrauch.
Die Arbeit des uC besteht aus zwei Teilen:
- RAM mit Daten auffuellen: das geht (vermutlich) relativ langsam
- RAM wieder auslesen: das geht (vermutlich) mit full speed und
genau hier liegt dann das Problem.
Aber mal guggen, vllt. krieg ichs softwaremaessig doch so hin, dass
der zweite Teil auch a Bisserl langsamer ablaufen darf.
Ich hab schon gegoogelt, aber nix brauchbares gefunden (vllt. warens
auch die falschen Suchbegriffe...)
Ich muss zur Zeit zwei Microcontrollern beibringen, sich ueber I2C
zu unterhalten. Leider besitzt nur einer von beiden einen eigenen
I2C Controller, so dass ich auf dem zweiten das Protokoll in Soft-
ware nachbauen muss.
Daher bin ich nun auf der Suche nach einer einfachen I2C Testumge-
bung. Ich denke da z.B. an ein Programm, das I2C meinetwegen ueber
den Parallelport realisiert und dann auf dem Monitor einfach
empfangenen Daten als Hexcode oder aehnlich anzeigt.
Gibts sowas? Am Besten fuer Linux oder i386-Solaris, noch viel
Besser natuerlich Open Source. Wonach sollte ich suchen?
> Selber schreiben. i2c parport für die Hardware, dann /dev/i2c-0 mit
> read()/write() beackern. Gibt schöne Dokumentation und Sourcen im
> i2c-Paket, das es auf der gleichen Seite wie lm sensors gibt.
Ah, das hoert sich richtig brauchbar an. Werd ich mir anguggen.
Vielen Dank!
"Stefan Bröring" wrote:
> Ist zwar nicht die Antwort auf deine Frage, aber trotzdem ein Hinweis:
Jau, bin auch fuer ungefragte Hinweise dankbar :-)
> Deshalb
> ist es wahrcheinlich sinnvoll, den Controller, der einen Hardware I2C-Bus
> Controller hat als Slave zu betreiben. Der andere, d.h. der auf dem deine
> Softwarelösung läuft ist dann der Master.
Ja, so ist das auch geplant. Allerdings eher aus Bequemlichkeits-
gruenden (so muss ich nicht auch noch auf die Clock hoeren sondern
kann sie selber vorgeben) anstatt aus Gruenden der Spezifikation.
Daran haett ich wirklich nicht gedacht, danke!
> -> s.o. Das Timing des Slaves ist kritisch, deshalb ist eine
> PC-Parallelportlösung als Testumgebung ungeeignet
Jo, duerfte auch irgendwas anderes sein, meinetwegen auch eine extra
Mess-/Test-/Rumspiel-Karte, sofern sie nicht allzuviel kostet.
> Mit nem PC-Parallelport läßt sich allerdings sehr einfach ein
I2C Master
> realisieren, vieleicht hilft das ja auch weiter. Ich müsste mal
nachsehen,
> ob ich noch irgendwo ein par Schnipsel Turbo-Pascal zu dem Thema finde....
Dafuer waere ich sehr dankbar.
> Die Frage wäre noch, ob es unbedingt I2C sein muss, oder ob es andere
> bessere oder einfachere Lösungen gibt. Benötigst du ein System
mit mehr als
> einem Master und einem Slave, oder müssen nur zwei Prozessoren
miteinander
> kommunizieren? Wieviele Daten willst/must du denn transportieren?
Es sind insgesamt vier Prozessoren, von diesen hat einer die Rolle
des "Masters", jetzt nicht nur in Bezug auf I2C sondern auch wort-
woertlich, im Sinne von "er sagt den anderen drei, was sie zu tun
haben". Dieser Master ist auch derjenige, der keinen eigenen I2C-
Controller besitzt. Die Wahl fiel unter anderem auf I2C, weil zur
Kommunikation zwischen den Chips nur zwei Leitungen zur Verfuegung
stehen. Dies kann dummerweise auch nicht geaendert werden, da das
Design der Master-Platinen "von oben" vorgegeben ist und ich in
das System nur zusaetzliche Funktionalitaet einbauen soll (die von
Anfang an nicht vorgesehen war).
Die Menge der Daten reicht von "einfachen Kontrollanweisungen" im
Bereich von ein paar Bytes bis hin zu groesseren Datensaetzen.
Hierfuer wurde bereits ein Uebertragungsprotokoll designed, das
dann auf I2C als "Link Layer" aufsetzt.
"Stefan Bröring" wrote:
> Muss der Master nur senden, oder auch empfangen?
Beides. Wie gesagt, es werden ab und zu auch groessere Datenmengen
uebertragen, wofuer ein Uebertragungsprotokoll designed wurde, und
zwar eine Art "abgespecktes TCP". Es muessen also zumindest die
ACKs und Fehlermeldungen zurueck zum Master gelangen.
> Frage. Beim I2C Protokoll gebe ich ja neben der Slaveadresse noch eine
> Speicheradresse und so an. Das muss nicht unbedingt sinnvoll sein für
die
> Kommunikation zwischen Prozessoren.
Hu? Also das ist mir neu, dass man da eine Speicheradresse angeben
muss und ich find dazu auch grad in der Spec. nix.
> Es gibt viele Möglichkeiten, wie man soetwas mit nur zwei, oder auch
nur
> einer Leitung realisieren kann.
Jups. Die Sache ist halt die, dass die anderen drei uCs ja eigene
I2C-Controller besitzen. Und wieso soll ich mirs schwerer ma-
chen als es ist, wenn ich diese Controller einfach verwenden kann.
> Hier erstmal ein paar Fragmente aus einem 8031 Programm, mit einem I2C
> Uhrenchip PCF85?? Ich hoffe, der Code ist selbsterklärend...
> das Nachbauen sollte eigentlich kein Problem sein.
> Es Gibt App-Notes und beispiele der Microcontroller und Compiler
hersteller.
Jo, das Programmieren ist auch nicht das Problem, sondern das De-
buggen. Prinzipiell koennte man das natuerlich auch mit nem Oszi und
viel Geduld machen, aber ich glaub, die Software die Alexander er-
waehnt hat ist da doch geeigneter. :-) Werd ich am Montag gleich mal
testen.
> Welchen Microcontroller möchtest Du verwenden, welche Sprache
> (Assembler, C,...)?
Der uC ist ein Motorola MPC860. Der hat zwar prinzipiell einen I2C
Controller on board, aber dummerweise ist der mir nicht zugaenglich,
da die entsperchenden Leitungen nicht von der Platine herausgefuehrt
sind. Darum muss ich das Protokoll ueber I/O Ports simulieren.
Und um die Frage gleich mal vorwegzunehmen: Nein, das Design kann
nicht geaendert werden. (Die Begruendung hierfuer wuerde etwas
zu weit fuehren, belassen wirs bei einem "es geht nicht").
Die Software, die bisher darauf laeuft, ist in C++ geschrieben.
Aus Konsistenzgruenden sollte es daher der I2C-Code auch sein (wo-
bei mir persoenlich C wesentlich lieber waere...).
> mal doch mal nicht den Teufel an die Wand.
> Wenn Du auf vorgefertigte Programme zurückgreifst, dann ist die
Chanche
> gross, dass alles zusammenspielt.
Jo, das is schon klar. Dennoch waers mir lieber, wenn ich eine Moeg-
lichkeit zum Debuggen haette. Ich sag ja net, dass es nicht funktio-
niert, nur dass es ggf. nicht funktionieren koennte , und dann sind
entsprechende Werkzeuge ueberaus sinnvoll.
> Überleg dir, ob Du das I2C wirklich benötigst.
> Wenn Du nur zwei Microcontroller verbinden willst, dann kannst Du das auch
> vereinfachen. Adressen sind nicht notwendig. Wahrscheinlich kannste auch
auf
> Start-Stop-Bit verzichten.
Wie schonmal gesagt: es sind insgesamt vier Microcontroller. Davon
haben drei einen I2C-Controller eingebaut (der vierte zwar auch, nur
komm ich an den eben nicht ran). Also nehm ich I2C, denn dann muss
ich mich nur um den einen kuemmern, net um alle vier.
Ich habe zwei Steuerleitungen A und B, die ich logisch verknuepfen
will, und zwar A and (not B). Ich habe dies bereits "kanonisch"
probiert, mittels Inverter und AND-Gate, was auch problemlos funk-
tioniert hat. Leider ist aber der Stromverbrauch in meinem Pro-
jekt ein sehr limitierender Faktor, so dass es mir wesentlich lieber
waere, wenn ich anstatt zwei ICs (von denen jeweils nur ein einzi-
ges Gatter verwenet wird) mit einem einzigen auskommen wuerde.
Ich dachte daher daran, anstatt dem Inverter-AND-Aufbau ein Tristate
mit invertiertem Steuereingang zu verwenden, und den Ausgang mittels
Pulldown-Widerstand auf Low zu ziehen. Nun weiss ich aber, dass
man bei Logik-Bausteinen i.d.R. die Ausgaenge nicht mit Pullup/downs
verschalten darf, weil die Dinger sonst abrauchen. Ist dies bei
Tristates auch der Fall oder darf man das hier machen, um im hoch-
ohmigen Zustand doch einen definierten Pegel zu erhalten (ja, ich
weiss, dass sie eigentlich dazu da sind, um genau dies NICHT zu
machen)?
Oder hat jemand eine Alternative fuer mein Problem?
>> Leider ist aber der Stromverbrauch in meinem Pro-
>> jekt ein sehr limitierender Faktor, so dass es mir wesentlich lieber
>> waere, wenn ich anstatt zwei ICs (von denen jeweils nur ein einzi-
>> ges Gatter verwenet wird) mit einem einzigen auskommen wuerde.
> Was fuer ICs verwendest du ? ECL ?
Die Wahl der geeigneten Bausteine ueberlasse ich den Experten
der institutseigenen Elektronikwerkstatt. Ich designe nur die
Logik.
> Ein HCMOS-IC braucht praktisch keinen Strom wenn er nicht schaltet.
> Andererseits tut ein 74HC00 genau was du willst in Form von 1 IC,
> du musst halt mit dem Vorhandenen denken.
*patsch*
Auf die Idee ein paar NANDs geeignet zu verschalten bin ich na-
tuerlich nicht gekommen...
Danke fuers Mit-der-Nase-draufstossen! :-)
>> Oder hat jemand eine Alternative fuer mein Problem?
> Minigates Einzelgatter ? Wie MC74HC1G04 und MC74HC1G08 ?
Interessant, wusste nicht, dass es die auch einzeln gibt. Wie ge-
sagt, ich bin kein Elektronik-Experte und designe nur die Logik
an sich.
>> Um nochmal an den Anfang zurückzukommen: falls Du kein Akademiker
>> bist, wollte ich Dir damit nicht zu nahe treten.
> Wärst Du seinem Link gefolgt, hättest Du gesehen, daß er
Diplom-Physiker
> ist.
> Einem Physiker wollen wir das mal durchgehen lassen, das ist ja nicht sein
> Spezialgebiet. ;-)
Hehe, kein Problem, ich stehe dazu, dass ich von Elektronik nicht
wirklich grosse Ahnung hab. :-)
Ich bin eigentlich mit der Softwareentwicklung fuer unser Projekt
beschaeftigt (Microcontroller in einem Teilchendetektor) und mach
nebenbei ein bisserl die Logikschaltungen, die den uC mit dem Rest
des Detektors verbinden - ist ja sozusagen "Programmieren in Hard-
ware". :-) Um die Realisierung in echter Elektronik kuemmern sich
dann zum Glueck schon richtige Experten.
You can post new topics in this forum You can reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot post attachments in this forum
Login
Search
![New posts [ Popular ]](images/topic_unread_hot.gif "New posts [ Popular ]"){kind=small}
![No new posts [ Popular ]](images/topic_read_hot.gif "No new posts [ Popular ]"){kind=small}
![New posts [ Locked ]](images/topic_unread_locked.gif "New posts [ Locked ]"){kind=small}
![No new posts [ Locked ]](images/topic_read_locked.gif "No new posts [ Locked ]"){kind=small}
