Nur ein Kleiner Einwurf zum mit freuen. Ich weiß nicht ob das auch schon mal jemand Probiert hat. Mir ist es gelungen mit nur 11 Bauteilen aus einem ATMega8 ein Schwartz-Wieß CRT-Controller bauen. Zur Zeit hat die Software zwar noch keine Schnittstelle nach außen, aber Zeichen sind schon darstellbar.
Angehängte Dateien:
-
IMG_0307.JPG
890 KB
Sieht doch gut aus. Zeig mal die Schaltung und das Programm dazu, bitte. guude ts
Die Schaltung ist super simpel. Grundaufbau ATMega8 mit 16MHz-Quarz und den üblichen Kondensatoren (Quarz und Betriebsspannung (5V)). Sonst Pin 14 mit Pin 17 verbinden und daran ein 270 Ohm Widerstand an Pin 15 ein 620 Ohm Widerstand (z.Z. 150 + 470 Ohm) an Masse ein 120 Ohm Widerstand Die zweiten Anschlüsse aller Widerstände miteinander verbinden und dazu noch ein 220µF Kondensator mit der positiven Seite schalten. Das BAS Signal kann man dann an dem negativen Anschluß des Kondensators und Masse abnehmen. Mit der Freigabe des Quellcods habe ich noch so meine Bedenken. Da muß ich noch mal drüber schlafen.
ähnliche Geschichten: über SCART auch farbig http://www.tvterminal.de/index.html Philips ARM Design Contest 2005 TV based Oscilloscope 160 kSps 512 x 240 pixel http://www.jandspromotions.com/philips2005/Winners/AR1755.htm
Angehängte Dateien:
-
IMG_0309.JPG
870 KB
Wenn es sowas schon gibt, dann kann ich ja demnächst mein Quellcode veröffentlichen. Hier nochmal ein Bildchen.
Ich habe nur 10 Bauteile gebraucht, einschließlich RS232 Interface mit 115,2kBaud um die Textdaten zu laden. Eines würde mich an deiner Schaltung aber doch mal interessieren: Das SPI Interface gibt im Ruhezustand einen High Pegel aus. Wie hast du es geschafft, da schwarze Pixel hinzubekommen ? Ich muss bei meiner Schaltung das Signal vom MOSI Pin Invertieren.
@Läubi Theoretisch kann man damit Grafik darstellen, aber das braucht viel RAM. So wie ich das sehe, hat können hier 40x25 Zeichen = 1000Bytes dargestellt werden. Für Grafik wären 16kByte notwendig, also mega8515 + SRAM oder so.
Wie in dem letzten Bild zusehen, gibt es zwischen den Zeichen Leerspalten und Leerzeilen,damit ist es nicht möglich eine geschlossene Graphicfläche zu zeichnen. Die Leerzeilen kann man wieder rausprogrammieren. Die Spalten ergeben sich aus dem von Benedikt erwähnten Problem. (PB3 kurz als Input schalten und PB0 mit Low vorbelegen und gleichzeitig als Output schalten.) @Benedikt 10 Bauteile incl. Quarz, Blockkondensatoren und Signalaufbereitung ?
so etwas gibt es schon mehrfach hier und im anderen forum. bloss jeder hat eine andere progweise. der eine macht es in c und der andere in asm. es wäre schön, wenn man aus dem programm die zeiten für die darstellung lokalisieren kann. dieses ist bei den anderen nicht so ersichtlich und ich tue mich darum schwer damit, so etwas zu machen. drum stelle deine code einmal rein.
Hallo Leute, Ich habe mal den RC5-Decoder aus dem ATMEL Applet AVR410 dazu gewurschtelt. Der IR-Empfänger(TFMS5360) wird an PIN 18 angeschaltet. Auf dem Bildschirm wird der Systemcode und der Commandocode in HEX ausgegeben. Ich war verblüfft, dass das auf anhieb geklappt hat.
Hat jemand zufällig irgendwo so etwas mit einem ATMega in Farbe rumliegen? Hätte Lust mal ein "Digger" aus meiner Homecomputer-Zeit zu basteln ;)
Ulrich Radig hat an soetwas mal gebastelt. http://www.mikrocontroller.net/forum/read-4-161349.html#new
Es müsste aber möglich sein, das Timing für sync und Bildwiedergabe so anzupassen, das es TV-RGB compatibel ist, zur FBAS-Abmischung kannst du dann die folgende Schaltung verwenden. http://www.elv-downloads.de/service/manuals/RFK100/353-12.htm
FBAS ist nicht ganz ohne. Aber viele moderne TV (seit mitte der 90'er) haben RGB Eingänge.
abo Ist FBAS nicht einfacher man muss nur ein Signal erzeugen. Als bei RGB wo es 3 Signal gleichzeitig und syncron sein muss.
Das FBAS-Signal hat zugegebenermaßen nur eine Bandbreite von 5MHz, dass würde bedeuten, dass man mit einer Samplingrate von 10MHz und einer Auflösung von 8Bit ein brauchbares Farbbild erzeugbar wäre. Das funktioniert sogar wenn man ein vorhandenes Bild in FBAS digitalisiert und einfach wieder ausgibt. Aber jeder mir bekannter µ-Controller wäre nicht in der Lage die analoge Farbträgermodulation in echtzeit Digital zu simuliren, um geziehlt einen Bildpunkt z.B orange werden zu lassen. Du darft nicht vergessen, das ein Bildpunkt z.B. gelb wird hängt nicht vom momentanen Spannungswert des Signals ab, sonern von der Phasenlage des Farbträgers.
Angehängte Dateien:
-
IMG_0331.JPG
860 KB
Es geht doch ! - Graphikelemente ohne die Senkrechtelücke darzustellen. Ich lasse das Bit 7 des nachfolgenden Zeichens in der Lücke ausgeben. Das Bit 7 hat dann doppelte Länge aber die Lücke verschwindet.
So machten es auch die EGA/VGA Karten früher bei den Blockzeichen im ASCII. Gruß Hagen
Mal wieder ein Zwischenstand. Die Bilder sind leider etwas Unscharf. Ich habe bis jetzt folgendes realisiert: -Darstellung 40x25 Zeichen -Statische Graphik-Hadline 320x36 Bildpukte -Uhr/Datum mit Schaltjahr und Wochentagsberechnung -Einstellungs Menü mit belibige IR-RC5-Fernbedinung bedienbar Das Menü enthält: -Einstellung der Bildlage für engen und weiten Zeilenabst. -Wahl eines engen oder weiten Zeilenabstands -Festlegung der Menü Aufruftaste -Festlegung eines Fernbedinungs Systemcods -Einstellung Datum/Urzeit (unsinnige Eingaben sind noch möglich) -Speichrung der Einstellungen im EEPROM Es fehlt noch: -TWI-Schnittstelle (I2C) -Schittstellenprotokoll -Automatische Sommer-/Winterzeitumstellung Wer sich das mal live anschauen möchte, im Anhang liegt die passende Hex und Epp Datai. Die Schaltung lässt sich schnell auf einem Steckbrett zusammen stecken. Zur Beschaltung: Sie ist für den TV-Teil auch auf den Bildern zu erkennen. In Text: Grundaufbau ATMega8 mit 16MHz-Quarz und den üblichen Kondensatoren (Quarz und Betriebsspannung (5V)). Beim Progen etsprechend Fusen ! Sonst: Pin 14 mit Pin 17 verbinden und daran ein 270 Ohm Widerstand. an Pin 15 ein 620 Ohm Widerstand (z.Z. 150 + 470 Ohm). an Masse ein 120 Ohm Widerstand. Die offenen Anschlüsse aller Widerstände miteinander verbinden und dazu noch ein 220µF Kondensator mit der positiven Seite schalten. Das BAS Signal kann man dann an dem negativen Anschluß des Kondensators und Masse abnehmen. An Pin 18 einen RC5 tauglichen 5Volt IR-Empfänger gemäß dessen Datenblatt anschließen. z.B. TFMS 5360 oder TSCP1136. Mega8 progen - Fernseher anschleißen - Einschalten - Und mit der Fernbedienung spielen.
Das Ding gehört in die Codesammlung! (Zu den anderen Fernsehbildgeneratoren). meld mal beim Admin
Für eine Farbausgabe gibts bei Reichelt noch den TDA8501 für 2,90 Euro: http://www.nxp.com/pip/TDA8501_CNV_2.html leider "discontinued", aber recht einfach zu beschalten, ähnlich dem MC1377 ( ebenfalls Reichelt, 2,30 Euro), RGB rein , PAL raus
Könnte man auch ein Bild ausgeben, wenn es in den speicher des Atmega passt? Zb 3-3-2 codiert? wieviel pixel pro zeile könnte man da darstellen!?
@Richard Meinst du Farbbild ? Es müssten etwa 120-130 Pixel pro Zeile möglich sein, wenn man den Code per Schleife macht. Ohne Schleife kommt man auf etwa 210-220 Pixel pro Zeile, verschwendet aber rund 850-900Bytes. Wenn man von 200x200 Pixeln ausgeht, benötigt man rund 40kByte für ein Bild, und das passt somit nicht in die meisten AVRs. Allerdings kommt mir da gerade so eine Idee, wie das ganze doch funktionieren könnte. Vielleicht taucht ja in den nächsten Tagen ein FarbTV-Bildgenerator mit 220x256 Pixel von mir in der Codesammlung auf...
Ohne schleife heisst dass du evtl das bild as source in asm ausgibst oder so? Quasi ein riesen spagetti-code? aber da würde ja nur 1/4 des code im prinzip für pixel zur verfügung steht, also ldi+out=4 bytes.
Ja, ansonsten wird das ganze zu langsam. Ich arbeite aber gerade an einer anderen Lösung die zu funktionieren scheint, die besser ist und mit wenig Code ein 8bit Bild mit 250*250 Pixeln erzeugt. Ob man daraus jetzt 256 Graustufen oder 256 Farben macht ist egal.
wie machst du das? daten aus dem avrflash laden? anders geht es ja nicht, allerding bei 256 farben/graustufen hättest du ja 62,5kan daten
Angehängte Dateien:
-
tv_farbe.jpg
51 KB
Hier das erste Testbild. Auflösung: 256x252 bei 256 Farben. Die Bilddaten stehen in einem externen 64kByte SRAM, und können zur Laufzeit verändert werden. Da ganze läuft sogar im Hintergrund (ca. 70% CPU Auslastung) und ist in ein C Programm einbindbar. Von den internen 512Byte SRAM werden dann nur <5Byte für die Pixel/Zeilenzähler benötigt. Der RAMDAC macht nur noch Probleme (die Streifen oben und unten im Bild), da dieser ein recht altes Design ist und einen kontinuierlichen Pixeltakt haben möchte.
ah ein ramdac. dh dem gibst du den takt und der macht den rest?
Angehängte Dateien:
-
tv_farbe2.jpg
64 KB
Nein, der RAMDAC ist nur ein DAC, er hat halt zusätzlich eine Tabelle mit 256 Einträgen, um jedem Eintrag eine Farbe zuzuordnen. So kann man den DAC per Software entweder auf 256 Graustufen, oder aber auch auf RGB, mehr rottöne usw. eben so wie man gerade die Farbpalette braucht umstellen. Dieser RAMDAC bekommt vom AVR pro Pixel ein Byte zugeschoben. Um schnell genug auf den RAM zugreifen zu können, kommt nur der mega8515 in Frage, da der ein Speicherinterface hat. Wenn man mit einer festen Farbpalette zufrieden ist, dann kann man den RAMDAC auch durch ein 8bit Latch (HC574) und einen DAC aus Widerständen ersetzen. Dann benötigt man nur den mega8515 mit 64kB SRAM und das Latch.
AAHH. ok cool. also machst du im prinzip nichts anderes als daten empfangen und in sram schreiben, und dann einfach nur zyklisch auslesen und an den dac geben. schreibst du die sync daten mit in den sram?
Nein, die Sync Daten erzeuge ich mittels Timer im PWM Modus. Über den Timer Interrupt werden die Daten synchron zum Sync Impuls ausgegeben.
okay. timer im pwm modus? kannst du das mal näher erklären? du erzeugst ne pwm am ausgang?
Ja, die Periodendauer beträgt 1024 Takte, das macht bei 16MHz genau 15625Hz. Die Impulsbreite beträgt 75Takte, während dieser Zeit ist der Ausgang low. Das ergibt genau 4,7uS, genau passend für den HSync Impuls.
Das ist ja mal geil. auf so ne idee zu kommen. das heisst du gibst nur zum richtigen moment die bilddaten aus.. das hsync kommt wegen der hardware immer zum richtigen zeitpunkt
Ja. Und der VSync Impuls wird durch Invertieren des PWM Signals erzeugt: Dazu ändere ich nur das COM1A0 bit im Timer Register. Die Einstellung wird synchron mit dem nächsten Impuls übernommen.
Also Benedikt, du wirst mir langsam unheimlich, hast du eine Zeitmaschine ? Um 9:44 postest du "Ich habe da eine Idee" und genau 7 Stunden später präsenentiers du ein sauberes Farbbild mit einer Frau, die von einem Felsen springt. In der Zeit habe ich nichteinmal meine Gedanken sortiert. In 7 Stunden Hardware aufbauen, Sourcecode erstellen und Debugen. Ich werde gerade blas vor Neid.
Noch 'ne Frage: Benutzt du den RGB Eingang des Fernsegeräts. Oder hast du da eine kompakte (einfache) Schaltung zur FBAS modulation. Ich kenn da nur den Aufbau von ELV gibt es da etwas weniger aufwendiges.
Ich verwende einen AD725, der benötig außer einem Quarz nur noch Widerstände als Beschaltung. Leider ist dieser nichtmehr erhältlich. Am Eingang bekommt dieser RGB + H/V Sync, am Ausgang erhält man Y/C und FBAS, je nach Pinbelegung in PAL oder NTSC. Die Software konnte ich großteils aus meinem 640x480 LCD Controller und dem TV Terminal zusammenkopieren. Die Software war nach etwa 2h fertig, das längste hat der Aufbau der Schaltung gedauert.
Guten Morgen, sag mal wenn man angenommen nen Mega128 nehmen würde, könnte das Bild auch im Flash stehen, anstelle des Sram? oder benötigt asm da mehr zyklen als zurgriffszeit?
Hey die idee ist klasse, ich bastel grad an meinem Bild aus dem Flash-Projekt aber meine Teile die beim C bestellt habe lassen auf sich warten.. Wenn Man das in nem Flash vom COntroller ablegen könnte dann könnte ich mir das TTL-Grab sparen... :-))
Flash benötigt länger, da man den Pseudo DMA Modus nicht nutzen kann: Der RD\ Impuls der den externen RAM aktiviert, dient auch als Pixeltakt, d.h. die Pixeldaten laufen garnichterst durch den AVR, sondern direkt vom RAM zum DAC Latch. Die Bildausgabe besteht aus 256x ld dummy, Z+ Das verschwendet zwar 512Bytes Flash, aber das ist noch akzeptabel. Würde man das Bild im Flash ablegen, würde der Befehl so aussehen: lpm r16, Z+ out portd, r16 Und das etwa 210 mal. Da hier immer 4 Takte pro Pixel benötigt werden, kommt man so nur auf etwa 210Pixel pro Zeile. Wenn man wirklich viel Flash verschwenden möchte, kann man auch ldi r16, Pixelwert out portd, r16 verwenden. Und das 256x pro Zeile und 256x pro Bild. Allerdings benötigt man dann 256kByte Flash für ein 256x256 Bild. Dafür ist aber eine theoretische Auflösung von 432x288 Pixeln möglich.
mmhh assembler ist immer der krampf für mich... woher kommt das bild, dass du anzeigst? das könnte man doch aus dem flash laden, oder?
Ja, das wäre möglich. Im Moment lade ich das Bild vom PC per UART. Wenn ich das ganze außreichend stabil hinbekomme, packe ich das ganze in eine Assembler Datei (.S) die man in ein C Programm einbauen kann und dann ganz bequem mit Funktionen wie setpixel(x,y,farbe) oder writetext(x,y,farbe,*text) das Bild beschreiben kann.
kann man dich dabei irgendwie unterstützen? evtl mit hardware?? ich hätte noch ein mega128 board über, das würde ich spendieren, dann könnte man ein default-hintergrundbild im flash ablegen..
Ich habe die Software jetzt in einen recht stabilen Zustand gebracht: http://www.mikrocontroller.net/forum/read-4-430587.html#new Für den mega128 sind aber noch kleine Modifikationen notwendig da dieser weniger externen Speicher adressieren kann. Damit sind dann "nur" 256x240 Bilder möglich.
Mal ne frage. du gibst beim vsync nur 3 impulse invertiert aus, ich hab schonmal ne grafik gesehen, wo das 4 impulse sind. Wo ist der unterschied?
Das sind 4 Bildzeilen. Bei einem PAL Signal dauert der VSync Impuls 5/2 also 2,5 Zeilen. Der VSync Puls ist also sogar länger als orginal.
okay da ist die grafik die ich hatte nicht richtig... danke dir. übrigen super projekt. werd ich wenn meine frau mir mal zeit gibt :-)) mal nachbauen
Hallo Benedikt, Habe da eine bischen Crazzy Idee, Du bist ja so ein Turboentwickler. Wenn man einen 128kByte RAM nimmt und anstatt dem Adress-Latch ein schnelles Register verwendet, dass auf die fallende Flanke von ALE reagiert und dazu eine Logig aufbaut, Die mit der Steigenden Flanke von RD eine 1 bringt und mit der fallenden Flanke von ALE eine 0 bring, und das Signal als weiteres Adressbit nutzt, dann hätte man 512 Bildpunkte pro Zeile. Naturlich mus dises Aressbit auch über ein IO-Pin ansteuerbar sein um das RAM Pageweise laden zu können.
Die Idee ist eigentlich nichtmal so schlecht, allerdings wird das Timing äußerst kritisch, da zu diesem Zeitpunkt die A0-7 noch nicht gelatched wurde. Vermutlich wird das ganze aber sehr aufwendig mit dem ganzen Bit umgeschalte. Bei meiner jetzigen Schaltung war mein Ziel mit möglichst wenig Aufwand und Standardbauteilen ein Farb-TV Bild zu erzeugen. Bei mehr Auflösung würde ich eher einen CPLD nehmen, da ich faul bin und gerne wenig Löte. Mit diesem habe ich schon 512x288 mit 2 Seiten Bildspeicher erreicht (512kByte SRAM). Hier reicht dann auch das SRAM, der CPLD und der AVR als High-Level Controller. Alternative: LCD Controller wie der S1D13504, der mit 2MByte DRAM 800x600 unterstützt, und sogar ein Interface für einen RAMDAC besitzt. Dieser bietet eigentlich das beste Preis/Leistungsverhältnis (15 + DRAM) aber 0,4mm Pinraster sind echt übel zu löten.
+5V
|
_
_4,7kOhm
100pF |
ALE ---||-------|<|------ A17
|
RD ---||-------|>|---
| 4,7 kOhm
-====-- GND
Wenn der Speicher ein C-Mos ist hat er eine Eingangskapazität von
ca.5pF und einen Eingangswiederstand >10MOhm. Das heißt, wenn man den
Pin mit einem Pegel "anschießt" so hält er diesen Pegel für eine
ausreichende Zeitdauer. Das A17 könnte dann mit der obenstehenden
Schaltung erzeugt werden. Die Dioden müssen nur Schnell genug sein.
Um auf A17 mit den AVR zugreifen zu können könnte man einen 74AHC153
einschleifen.
Was auch gehen könnte XOR von ALE und RD und damit ein FlipFlop mit Set
und Reset Eingängen Takten. Über Set und Reset könnte man die Page beim
Schreiben wählen. Mit dem XOR kann man auch das Ausgangsregister
Ansteuern.
Der Speicher braucht eine Zugriffszeit kleiner 30nS und wärend der
Ausgabe muß RD vom Speicher Daueraktiv sein und der Datenbus muß vom
AVR getrennt sein 74HC254.
Nun bin ich bei der TWI (I2C) Schnittstelle angekommen. Ich stelle mir
das follgende Protokoll vor. Wäre das aus Anwendersicht so O.K. oder
könnte das zu größeren Problemen führen.
Host zu CRT (Host als Master)
TWI-Initialisierung:
{0,W},'R','-','T','R','O','N','/','C','R','T',CRT_Adr,Host_ADR
Sollen mehrere CRT an einem Bus betrieben werden, so muss die Resetline
des CRT vom Host gesteurt werden.
Bilddaten:
{CRT_Adr,W}, Y_POS,|cNT_9&8|X_POS|,CNT_7-0, (CNT+1)*Data
Y_POS: 0 bis 24 (Wenn Uhr (RTC) aktiv beeinflußt die Zeile 24
Uhrzeit und Datum.)
X_POS: 0 bis 39
CNT_9&8|CNT_7-0:0 bis 999
Nach der Übertragung darf der Host erst Daten an den CRT senden, wenn er
ein TWI-Start sendet.
Einstellungen setzen:
{CRT_Adr,W},
|1|E_RTC|E_ENG|E_Y_Weit_Oben|E_Y_ENG_Oben|E_X_Links|E_IR_SYSTEM|E_IR_MEN
Ü|,
|N.C.|RTC|ENG|Y_Weit_Oben|,Y_ENG_Oben,X_Links,IR_SYSTEM,IR_MENÜ_SYS,IR_M
ENÜ_COM
E_???: Wenn gesetzt, wird der Wert geändert, nicht gesetzte Werte
dürfen nicht übertragen werden,
RTC,ENG und Y_Weit_Oben fällt nur weg, wenn alle drei auf 0 gesetzt.
RTC: Wenn gesetzt Uhr aktiv
ENG: Wenn gesetzt enger Zeilenabstand
Y_Weit_Oben: 0 bis 30 Zeilenabstand von oben bei weitem Zeilenabstand
Y_ENG_Oben: 0 bis 55 Zeilenabstand von oben bei engem Zeilenabstand
X_Links: 0 bis 103 Spaltenabstand von Links
IR_SYSTEM: 0 bis 31 RC5-Systemcode der als Match gekenzeichnet werden
soll
IR_MENÜ_SYS: 0 bis 31 RC5-Systemcode für dem Menü Aufruf
IR_MENÜ_COM: 0 bis 63 RC5-Commandcode für dem Menü Aufruf
Systemstatus lesen:
{CRT_Adr,W}, |0|0|1|E_Zeit|E_Datum|E_Wochentag|E_Bildpos|E_IR|,{R},
|0|RTC|SS,MinMin,|0|RTC|TT,MM,JhJh,JlJl,|0|RTC|WTag,|0|0|ENG|Y_Weit_Oben
|,Y_ENG_Oben,X_Links
,IR_SYSTEM,IR_MENÜ_SYS,IR_MENÜ_COM
E_???: Wenn gesetzt werden die entsprechenden Daten-Blöcke vom CRT
gesendet
RTC: Wenn gesetzt Uhr aktiv (Nur dann ist Datum,Uhrzeit und Wochentag
gültig)
SS: StundeStunde im BCD-Format
MinMin: MinuteMinute im BCD-Format
TT: TagTag im BCD-Format
MM: MonatMonat im BCD-Format
JhJh,JmJm: JahrJahrJahrJahr im BCD-Format
Rest wie oben erleutert.
CRT zu Host (CRT als Master)
TWI Stop:
Teilt dem Host mit, dass der CRT seine TWI deaktiviert
{Host_ADR,W}, CRT_ADR|0|, 0
TWI Start:
Teilt dem Host mit, dass der CRT wieder empfangsbereit ist.
{Host_ADR,W}, CRT_ADR|1|
Bild Neuaufbau anfordern:
Der CRT benötigt eine Neuübertragung aller Bilddaten
{Host_ADR,W}, CRT_ADR|0|, 1
IR-RC5 Daten:
Überträgt den letzten IR-Code
{Host_ADR,W}, CRT_ADR|0|, |1|IR_SYSTEM, IR_COMMAND
Hallo, ich habe eine Idee wie man auch langsame Speicher verwenden kann: Man liest eine information aus dem Speicher und zeigt sie an, dann kommt ein schwarzes Pixel. Im nächsten Durchlauf werden die anderen Pixel dunkel getastet und die vorher dunklen Pixel bekommen die Information aus dem Speicher.
Im Prinzip geht das, aber das Bild dürfte sehr unruhig werden, Um hier keine Verwirrung aufkommen zu lassen, bei dem TWI-Protokoll geht es um den BW-CRT-Controller.
gibt es SRAMs wie den 628512 mit 15ns zugriffszeit oder kürzer? aber eben mit mehr als 32kB kapazität?
@stefan ist vielleicht oversized und schwer beschaffbar, aber es gibt von ISSI sehr schnelle SRAMs in allen erdenklichen größen und konfigurationen. auf meinem Spartan3 sitzen 2 256K*16 Bit 10ns Speicher. Das Teil heißt dann IS61LV25616AL. Sind aber nicht leicht zu bekommen (habe die nur bei Farnell gefunden, und das für 10 Euros, in einem nicht schön zu lötenden gehäuse) würde mich aber auch mal interessieren was es für schnelle (und vor allem günstige) rams gibt (15-20ns wär voll ok). gruß rene
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.