Guten Tag, es wurde inzwischen die Generierung des Taktes und das verfahren der Datenablage diskutiert (Wikiartikel). Vielleicht ist es sinnvoll den CPLD vom Mikrocontroller aus programmierbar zu machen (ja, dann ist ein externer Takt für den µC nötig). Dadurch könnte man aus Softwareupdates einfach aufspielen und nicht jeder braucht einen CPLD-Programmierer. Ein Atmel-ISP würde reichen. Ich kann leider nichts zur Implementation der Software im µC sagen, da ich nicht weiss, wie ein CPLD programmiert wird, doch ich denke, dass sich das mit einer Hochsprache wie C in vertretbarem Aufwand lösen lässt. Ich habe nicht den gesamten Thread gelesen (das ist mir zu viel). Schlagt mich bitte nicht, wenn dieses Thema schon diskutiert wurde. Schöne Grüße und viel Erfolg (ich will auch einen haben!), Clemens
@ope:ich sehe dein problem nicht... der user wird doch wissen was er da an hardware hat oder??? also sagst du das ist hardware xyz... die controller-soft muss sowieso irgendwann eingespielt werden => dort die ref-clock hardcoded rein..oder im eeprom speichern... pc hardware holt sich einfach vorm capturen die ref-clock bzw die möglichen sample rates an und der user sagt was er will.. fertig.. und falls sich beir der hardware was grobes ändert wird einfach ein plugin geändert/neu gemacht und die software kann wieder richtig umgehn.. ich hab mir das mit den input plugins (die eigentlich sowas wie ein treiber sind) schon recht genau überlegt und ich bastle gerade am plugin manager ;) der data-manager wird wieder was ganz dummes.. der will vom input plugin eigentlich nur ein byte-array haben und wissen wieviele bytes/sample und wie hoch die sample rate ist... die view plugins holen nun diese daten und zeigen sie an,.... sprich ich bastle da etwas möglichst modulares, das eigentlich sogar von einem parallelport samplen könnte G 73
@Clemens Helfmeier Hier bist Du der Diskussion bereits vorraus :-) Ich hing da auch schon mal - mit JTAG soll so etwas gehen - konkret habe ich aber (noch) keine Ahnung. Der AVR soll ja auch ein JTAG Interface haben, allerdings sind damit die gängigen Programmer dann überfordert - bitte korrigiert mich hier, wenn ich falsch liege. So wo Du es vorgeschlagen hast, sollte es letzlich auch sein - CPLD und AVR per USB Firmware Updates. Über genauere Hinweise sind wir dankbar, bitte mit Quellen/URLs. Offenbar hat sich dann damit auch das Problem des uC Clocks/Quarz erledigt: Der ATMega8L kann lt.DB nur bis 8MHz heizen, das würde bei einem Masterclock von 25MHz einen Teiler von 3 bedeuten und somit keinen 50/50 Cycle mehr und leichtes Übertakten - oder 4:1 Teiler mit 6.25MHz. Nehmen wir also einfach einen 8MHz Quarz - einfacher wird's nimmer. @Hans: Problem war: verschiedene Master Clocks bei verschiedenen Usern aufgrund irgendwelcher Unwägbarkeiten bei gleicher Hardware + Firmware und Desktop Software. > der user wird doch wissen was er da an hardware hat oder??? Yep, aber alle haben verschiedene Sample rates letzlich, da der max. Multiplier runter gesetzt werden musste. > also sagst du das ist hardware xyz... die controller-soft muss > sowieso irgendwann eingespielt werden => dort die ref-clock > hardcoded rein..oder im eeprom speichern... Im Prinzip ja, aber alle haben dann verschiedene Sample rates -> verschiedene Firmware (auch wenn sie sich wohl nur in ein byte unterscheidet). > pc hardware holt sich einfach vorm capturen die ref-clock bzw die > möglichen sample rates an und der user sagt was er will.. fertig.. Korrekt, so soll es sein. Evtl. löst sich das Problem von ganz alleine. Wie Benedikt schon vorschlug -> SPI/TWI. Das Problem entstand ja dadurch, dass ich nachträglich dem uC sagen muss, was ich von Standard herändern musste, aufgrund des Multiplier Coding Schemas des ICS502. Man kann den Spies auch umdrehen: Dreh-Codierschalter (KDR10 bei Reichelt für 1,95) am Port des uC auslesen - per SPI gibt er dem ClockChip den Multiply-Faktor und damit den Master Clock vor (der IC ist ja dem uC bekannt mit seinen Multipliern). Damit kann bei der Inbetriebnahme der maximal mögliche Multiplier festgelegt werden, nicht mehr änderbar durch die Firmware, sprich ein "Anschlag". Dieser kann durch die SW ausgelesen werden und ggf. verringert werden, aber mehr als hardwaremäßig begrenzt geht eben nicht. Du darfst nicht vergessen, der maximale Masterclock ist noch unbekannt (zu viele unbekannte Faktoren) und wahrscheinlich auch von User zu User verschieden. Nicht alle haben beim Löten auch ein goldenes Händchen :) Also, wer kennt einen preiswerten, erhältlichen ClockChip per SPI programmierbar, geringer Jitter und Temp.abhängigkeit mit Quelle und Datenblatt? Viele Grüße Olaf
@ope > > also sagst du das ist hardware xyz... die controller-soft muss > > sowieso irgendwann eingespielt werden => dort die ref-clock > > hardcoded rein..oder im eeprom speichern... > Im Prinzip ja, aber alle haben dann verschiedene Sample rates -> > verschiedene Firmware (auch wenn sie sich wohl nur in ein byte > unterscheidet). also wenn ich das im eeprom abspeicher .. wo liegt dein problem.. das byte schiebst du gemütlich über ein kommando zum avr und der schreibs in den eeprom... und ganz hab ich das ganze refclock zeugs nicht begriffen... der capture-cpld hat einen master clock.. den lassen wir vom avr über den teiler einstellen.. gut und wo zum teufel liegt das problem?????????? da schieb ich einfach das kommando "set-masterclk blah" zum avr und der tut das dann ... bzw ich frage ihn "get multiplicatorlist" und er schiebt mir die möglichkeiten... der muss ja nicht wissen wie schnell die clock ist.. und wenn man das trotzdem am avr haben will sagst halt "set refclk blah" und der schreibt das in seinen eeprom... ähnlich beim flashen... irgendwo auf der platine ist ein jumper..den setzt man .. schaltet ein und schiebt die firmware rüber.. jumper weg und neu starten fertig.. irgendwas begreif ich glaub ich ned richtig ;) @cpld firmware... im arthernut-thread wurde das mal aufgegriffen und sofort wegen extrem aufwengigen code wieder fallen gelassen... 73
Hi, >ähnlich beim flashen... irgendwo auf der platine ist ein jumper..den >setzt man .. schaltet ein und schiebt die firmware rüber.. jumper weg >und neu starten fertig.. Jumper ist unnoetige Geldverschwendnung. Nach einsschalten wartet der AVR auf ein Kommandozeichen nach der Auswertung des Zeichens geht er in Bootloader Mode. Anonsten wird im Hauptprogramm weiter gemacht. Mfg Dirk
@Hans Yep, Du hast recht - irgendwie hatte ich eine lange Leitung - der max Multiplier kann ja im EEPROM abgespeichert werden und wird per Firmware Update i.A. nicht überschrieben. Mein PROM wäre der Dreh-Codierschalter gewesen ... und wieder ein Teil (Drehschalter) weniger. Nur im Konfigbereich des EEPROM darf keiner (auch keine irregelaufene Firmware) wild rumschreiben. Was ich so über verloren Device ID (habe Thread verloren) und veränderte Fuses gelesen habe, verschafft mir allerdings nicht viel Vertrauen in diese Lösung. Thema cpld firmware: Schade, gibt's Alternativen? Ein CPLD Xilinx/JTAG Stecker ist nicht so toll. Thema Clocking: Definieren wir mal: Quarz Oszillator wird festgelegt auf 25MHz. Nennen wir ihn mal MasterOszillator | \|/ ° Clock Multiplier, Type ????, uC gibt Multiplier per SPI vor, es wird der MasterClock bis zu ~100 MHz erzeugt. | \|/ ° Damit wird der CPLD getaktet. Der generiert die einzelnen Clocks für - Adresszähler (noch namelos) - uC, oder auch nicht bei Quarz (MCUClock) - CPLD Input-Port Sampling (SampleClock) Viele Grüße Olaf
@ope für den Clock ist der IDT5V9885 zwar etwas übern Ziel, aber man kann den mit I2C programmieren. Kostet etwa $8,00 USD. Der ICD2053B schaut auch nicht schlecht aus und man kann den mit SPI programmieren. Einen Preis habe ich dafür leider nicht.
Hallo, für die Programmierung eines CPLD benötigt man ziemlich viel Speicher; ein FPGA dagegen wird normalerweise über ein EEPROM nach dem Reset programmiert. Das FPGA benötigt ungleich weniger Speicher für die Konfiguration. Stephan.
die ganze Clock-Problematik wäre gelöst, wenn man ein FPGA verwenden würde. Auch wenn für CPLD und AVR Clocks von einem Clock-IC kommen, heisst das noch lange nicht, dass sie synchron sind. Auch das laden der Firmware wäre beim FPGA kein Problem, niemand bräuchte eine spezielle Programmer-Hardware, ein Firmware-File im Programmverzeichnis der Software - das wärs. Wann seht ihrs endlich ein, dass die Multi-IC-Multi-Layer- Multi-Bastelstunden-Version einfach zu aufwändig ist und zuviel Spielraum für Diskussionen lässt ?
@Stephan seit wann brauche ich zur Konfiguration einiger, simpler Macrozellen im CPLD mehr Speicher als zum füllen der zig-tausend Look-Up-Tables und der vielen MBits RAM im FPGA? Also ich kenne FPGAs, die brauchen mehrere MBits an Config-Daten, und auch das Laden wird oft mit einem Controller gemacht, nicht nur mit Config-Proms !
@ope wenn man den avr so behandelt wie man es sollte vergisst er nix und das mit config neu rüberspieln ist alleinschon wegen versions und damit struktur-änderung der im eeprom abgelegten daten sinnvoll.. btw mein plugin handler scheint zu funktionieren und sollte komplett portabel sein dank wxWidgets ;) falls es sich ausgeht werd ich morgen meine linux box anwerfen und dort mal compilieren... wenn sich das so weiterentwickelt hab ich den datamanager nächste woche fertig und am nächsten we kommt dann mal eine einfache view dazu... also auch auf der software seite tut sich schon was... 73
Hallo nochmal, hier ist der Link zu Xlinix' Embedded Programming von CPLDs/FPGAs/PROMs: http://direct.xilinx.com/bvdocs/appnotes/xapp058.pdf im folgenden Thread wurde darüber einiges diskutiert: http://www.mikrocontroller.net/forum/read-1-138024.html#156050 Ich muss dazusagen, dass ich nicht alles gelesen habe, doch wenn man (fast) unbegrenzt (Speicher-) Resourcen zur Verfügung hätte, dürfte es laufen (meiner Einschätzung nach). Einen schönen Abend, Clemens
Habe grad nochmal nachgeguggt: für den 95144XL ist die benötigte XSVF-Datei etwa 80kByte groß. Also entweder direkt vom USB in den CPLD oder externer speicher mit memory-map.
oder aber der avr holt sich die daten vom usb und schickt sie weiter ;) man muss aber mal wissen wie man die daten reinschieben muss... 73
Kurz zusammengefasst steht in der Introduction der XApp, das man über JTAG den Xilinx per uC programmieren kann. Auf ftp://ftp.xilinx.com/pub/swhelp/cpld/eisp_pc.zip kann man sich den Xilinx code zur AN runterladen. @Clemens: Ist das nicht der Teil, worüber Hans geschrieben hat: "im ethernut-thread wurde das mal aufgegriffen und sofort wegen extrem aufwengigen code wieder fallen gelassen..." ?? Immerhin muss der AVR ja JTAG sprechen können, ein einfaches memcopy wird wohl nicht ausreichen imo. An sich ist es ja bestechend. Bei einem schnellen Überfliegen der AN und des sources ich bin ich mir nicht ganz sicher, ob ich einen kompletten 8 Bit Port am uC frei machen muss, oder ob die 4 JTAG Leitungen (wie in der AN Fig#1), also PortNibbel ausreichen würde (src/port.c). Immerhin scheint's loader binaries für alle gängigen OS zu geben. Noch mehr On-Board Speicher für den XC zu verbraten wäre kontraproduktiv. Unabhängig vom Ausgang - wir haben > 4 I/O am CPLD übrig, so dass wir uns einen Fall Back per Stiftleiste und Serial Prog. Cable problemlos leisten können :) Viele Grüße Olaf
@Harry >die ganze Clock-Problematik wäre gelöst, wenn man ein >FPGA verwenden würde. Auch wenn für CPLD und AVR Clocks >von einem Clock-IC kommen, heisst das noch lange nicht, >dass sie synchron sind. Muss es denn zwingend synchron sein? TWI bietet imo eine asynchrone Möglichkeit - alle zeitkritischen Teile sind im CPLD vereint. Viele Grüße Olaf PS: Der Thread wird zum Fulltime Job :)
Guten Tag, soweit ich die Sache mit dem CPLD-Programmieren überblicke, ist das XSVF-Format nur eine Anweisungsansammlung. Also muss der Mikrocontroller nur diese Anweisungen befolgen, die dort enthalten sind. Da nur 4 Leitungen für den JTAG gebraucht werden, denke ich, man könnte das auch mit nur 4 von 8 Portleitungen realisieren (nur eine Frage der Codegröße?). Dass die Datei ganze 80kByte groß ist, dürfte weniger zum Problem werden, da man sie ja in "echtzeit" in den µC spielen kann, der braucht dann nur ein paar Byte Puffer. Soweit ich die Sourcen überblicke, läuft es etwa so ab: Für diesen speziellen Anwendungsfall muss die readByte() Funktion in ports.c angepasst werden, um immer das nächste Byte zu lesen. Die ports.h verlangt noch einige Funktionen zum Setzen/Löschen und Lesen der Leitungen. -------------------------------------------------------------------- Es kann sein, dass ich mit der obigen Annahme total falsch liege. Ich habe noch keine C-Erfahrung (und schon garnicht mit µCn) und habe (leider) auch noch keinen CPLD programmiert oder benutzt. Bitte korrigiert mich, falls nötig! -------------------------------------------------------------------- Schöne Grüße, Clemens
unter umständen wird einfach ein programmer-emulator geschrieben und passt.. aber das muss ich mir noch durch den kopf gehn lassen und mich genauer einlesen in das ganze... in der 1. revision wäre es glaubich sinnvoll einfach einen jtag header für den cpld noch vorzusehen und mit brücken eine verbindung auf ein avr port zu legen... jtag ist beim avr über den spi port möglich => da könnts probleme geben.. also entweder umgehen wir das problem mit einer reihe jumper mit denen man den avr mit dem jtag connector verbinden kann und den rest vom spi abtrennt... oder wir nehmen einen größeren avr, der die datenpins nicht am spi-port sondern woanders hat... das problem ist übrigens nur beim 1. programmieren existent.. danach kommen die daten einfach per boot-loader auf den chip... da gibts also noch einige kleinigkeiten zu bedenken... 73
@Hans: > in der 1. revision wäre es glaubich sinnvoll einfach einen jtag > header für den cpld noch vorzusehen und mit brücken eine > verbindung auf ein >avr port zu legen... Sehe ich auch so => Fall Back So könnte man die sichere und die unbekannte Möglichkeit ausprobieren; der 5er PinHeader des JTAG wird aber teuerer als ein Jumper :) @Clemens: > Da nur 4 Leitungen für den JTAG gebraucht werden, denke ich, man > könnte das auch mit nur 4 von 8 Portleitungen realisieren (nur > eine Frage der Codegröße?). Ich hatte mir wie gesagt den Code von Xilinx noch nicht intensiv angesehen, aber in ftp://ftp.xilinx.com/pub/swhelp/cpld/eisp_pc.zip src/ports.c wird eine {in|out}PortUnion benutzt, die anscheinend alle 8 Bits verbrät (Konkret outPortUnion Bit0-Bit3, inPortUnion Bit4 haben Namen)! Imo im Widerspruch zu JTAG mit einem Nibble (4Bit). Wenn ich doch bloß einen Drucker hätte :( BTW: Ich habe gestern einen Thread in http://www.mikrocontroller.net/forum/read-9-207389.html#new aufgemacht, Thema Programmierung CPLD über AVR. Hagen hat dort über das Speicherinterface philosophiert - das muss ich erstaml verdauen und Kästchen malen :-) Interessanter Weise hat er die synchronen SRAM stärker ins Feld geführt! Viele Grüße Olaf
Hi, zum Thema DAC wuerde ich gerne einen anderen Vorschlagen. Der LTC1257 (12Bit , SPI Bus) ist bei Reichelt erhaeltlich. Leider ist der Preis sehr hoch knapp 5 Euro. Mfg Dirk
ich wäre stark für einen typen mit interner referenz.... => weniger bauteile... wegen ic werd ich nach der arbeit bzw in der pause schaun... 73
was ich bei AD gefunden habe, war ja schon toll, aber entweder kein Dual-DAC oder keine interne Reference. Imo sind 8-Bit ausreichend, dass sind 32.25mV Auflösung bei 5V max. Schnelligkeit ist eher untergeordnet. Immerhin sind die TWI/i2c über 8,10,12 Bit je nach Serie pinkompatibel und was ich so gesehen habe, auch "Protokoll" kompatibel, da das LSB mit Nullen entsprechend aufgefüllt wird. Viele Grüße Olaf
BTW, der LTC1257 hat 4.75V to 15.75V und passt somit schlecht in das 3.3V Konzept. Apropos, meist haben die internen Referenzen ja so 1V oder 2.5V - nicht das wir doch noch 5V und/oder einen OPV mit Verstärkung 2 benutzen müssen. Ich hoffe, das ich den Thread zum Eingangsteil noch heute eröffnen kann. Übrigens, den Thread in "Programmierbare Logik"/"CPLD und AVR Kombo (Logic Analyzer)" hab ich doch schon erwähnt, oder? Viele Grüße Olaf
ich hab da mal so einen lustigen dac gehabt den man auf der ref-versorgung nur min 12V geben musste und den ref-out pin auf ref-in legen musste(lagen nebeneinander ;)... problem : 16bit => teuer und parallel anzusteuern ;) aber sowas sollte es doch auch günstig geben.. der war immerhin für dds-anwendungen gedacht... 73
Hallo Alle, Ich wollte schon immer einen Logic Analyzer bauen. Wenn ihr einen FPGA benutzen wollt: Xilinx Spartan XCS40XL-4 Ich habe 40 stück davon auf lager und bin bereit diese zu verfügung zu stellen, nur die versandt kosten sollten bezahlt werden. Grüße Mark de Jong,
also wenns 'n FPGA wird wäre ich bereit, einen Teil des Designs in VHDL zu machen, z.B. die Trigger-Logik oder einen RS232-Core
Hallo Torsten, Der Spartan ist der XCS40XL-4 PQ208C, also 208 pins mit 0,5 mm abstand. Grüße Mark,
@Mark de Jong (Mark_de_Jong) Das wäre super! Das Gehäuse ist wegen der I/O etwas größer als die CPLD Lösung, aber wer sich den XC9500 im TQ144 Gewand zutraut, dem dürfe dies auch kein Problem bereiten, siehe http://www.xilinx.com/bvdocs/packages/pq208.pdf Wie Du sicher gelesen hast, war ja der Preis ausschlaggebend für den CPLD. Dies ist allerdings ein Angebot, das man nicht ablehnen kann. Zumal es den VHDL Designern des Projektes einfacher gemacht wird, da sie anscheinend an den geringen Macrozellen ihre Probleme haben. An den bisherigen Gesamtkonzept würde sich imo ja nichts bzw. nichts größeren ändern. Man könnte sogar über eine (optionale) 3./4. Speicherbank nachdenken dank Hagens ausgebufften Speicheralgo. Wie denken die anderen aktiven Teilnehmer darüber? Viele Grüße Olaf
@Thorsten: Ich kann das nur machen wenn die nicht fürs LA projekt benutzt werden. Die 40 Stücks sind schon reserviert, bis die entscheidung gefallen ist. Grüße Mark,
muss ich mir, um mit den Spartan arbeiten zu können, den "ISE Classics" neben mein ISE 7.1 installieren bzw. integriert sich das Teil selber oder ist es besser das ISE WebPACK v. 3.3 - v. 6.1 zu installieren? Auf http://www.xilinx.com/webpack/classics/spartan_4k/index.htm steht weiterhin, das ich bei "ISE Classics" auf 3rd Party Tools angewiesen bin: Synthesis can be accomplished by using Synopsys FPGA Compiler-II, Synplicity Synplify, or Mentor Graphics LeonardoSpectrum. The Spartan and XC4000 series device families were never supported by Xilinx Synthesis Technology. Viele Grüße Olaf
@Mark Sollten am Ende doch zwei Spartans abfallen, kannst ja mal an mich denken. Ich will die auch nicht geschenkt haben :)
Hallo Thorsten, Kein Problem, aber frage bitte irgendwann mal wieder nach, vergesslich, du weisst schon. Grüße Mark,
Hallo Mark, nochmals vielen Dank für Dein Angebot. Allerdings sind die FPGA wirklich nur mit "Spezial" Software zu bearbeiten. Da der LA nun recht breit getreten ist und auch ein breites Interesse herrscht (trotz der Diskussionflaute derzeit) und nicht aus jedem Interessierten ein Schwarzes Schaf werden soll (mal abgesehen von dem unterschiedlichen "Organisiationstalent"), ist es besser zu verzichten - so reizvoll es auch ist. Derzeit wird an der Input Stage gegrübelt, aber auch das CPLD Konzept ist wegen der erforderlichen Anzahl an Macrozellen (wieder) auf dem Prüfstand, da anscheinend ein XC95144 nicht ausreicht und wohl ein XC95288 her muss. Viele Grüße Olaf
Hallo Ope, Was meinst Du mit "Spezial" software zum programieren? Ich glaube das der Prozessor doch das programieren machen kann, oder sehe ich das falsch? Ich werde selbst ein modulares system aufbauen, ziel ist ein ersatzt für mein HP 16500A system mit USB/Ethernet anbindung. - digital 16-kanal LA module(n). - digital 16-kanal logik generator module(n). - analog 2-kanal DSO module. - analog DA 1-kanal module(n) - steuer module mit USB / Ethernet und grafik (640x400) LCD. untergebracht in ein 19" module gehause. Grüße Mark,
mit Spezial Software meine ich Mentor Graphics LeonardoSpectrum http://www.mentor.com/products/fpga_pld/synthesis/leonardo_spectrum/index.cfm zB. oder die anderen FPGA Synthese Tools gegen Geld, worauf man dann angewiesen ist. Sicher gibt es (schwarze) Wege, aber wenn ich mir schon den eagle load error thread ansehe ... In einem Jahr kommen dann Änderungen/Erweiterungen/BugRemovement und dann geht die Jagd ggf. nach Flexlm licences wieder los etc. Xilinx scheint für ihre Spartan I alles in fremde Hände gelegt zu haben. Leider kam zu diesem Theme nicht viel Infos hier, nur kurz im Parallelthread Prog.Logik. Aber ich hatte auch um chat kurz darüber diskutiert. Was meintest Du mit "Ich glaube das der Prozessor doch das programieren machen kann, oder sehe ich das falsch?" konkret?? Mit dem obigen Projekt hast Du Dir viel vorgenommen. Ich versuche das in kleineren Häppchen zu verarbeiten, da viele Probleme des Elektronikers Tot sind. Irgendwann kommt ein fettes FPGA, das das alles kann. Viele Fragen tauchen aber am Rande auf, die mit dem eigentlichen LA nichts zu tun haben. Viele Grüße Olaf
Hi, auf der leidigen Suche nach SRAM ist mir die Idee gekommen: Warum kompliziert, wenn es auch einfach geht! :) Soll heissen: Das bisherige Konzept sah ja 2x 16Bit breite SRAM Module vor, welche im Interleave angesprochen werden und am gleichen Adressbus liegen. Nach DB Studien einiger SRAM, insbesondere Pinbelegung TQ100, und Angstanfällen vor künftiger Routerorgien - imo sind die Pins beschissen (sorry) in einem Bus routebar - kam mir die Idee, warum nicht gleich einen 32 Bit breiten SRAM benutzen. Die Ansteuerung im Interleave bleibt davon ja im Prinzip unberührt. Es werden zwei 16bit Samples zu 32bit "gepackt" und geschrieben/gelesen. Kennt jemand Quelle/Preis/Verfügbarkeit von 128k/256k x 32/36Bit synchrone (ggf. asynchrone) SRAM? Tja, das wollte ich mal loswerden und damit auch von dem LA Projekt ein Lebenzeichen geben ;-) Viele Grüße Olaf
zB. CY7C1327B-133AC TQFP100, 4M, 256Kx18, 3,3V, 4ns, 375mA, 0 bis 70 für sagenhafte 11,60 oder CY7C1360A-150AJC TQFP100, 8M, 256Kx36, 3,3V, 3,5ns, 460mA, 0 bis 70 unglaubliche 21,65 . Any comments? Viele Grüße Olaf
hallo, hab grad ein fehlendes datenblatt im wiki ergänzt: CY7C1327B : http://www.datasheetarchive.com/semiconductors/download.php?Datasheet=598266 außerdem gefunden: CY7C1360A-150AJC : http://www.datasheetarchive.com/semiconductors/download.php?Datasheet=598712 dort findet man sehr viele datenblätter: http://www.datasheetarchive.com gruß, jános naumann
Als Clock Chip eignet sich der Cy22150 anscheinend recht gut (http://www.cypress.com/portal/server.pt?space=CommunityPage&control=SetCommunity&CommunityID=209&PageID=259&fid=22&rpn=CY22150) Ihn gibt es zumindest bei R&S für knapp 5. Er ist allerdings als i2c ausgeführt (im DB reden die immer von SPI und meinen, er hat eine Adresse ... letzlich also doch i2c) und hat 6 Ausgänge, kann von einem Quarz oder ext. Reference getrieben werden. Allerdings ist es nicht so einfach möglich, durch ihn auch den uC Takt generieren zu lassen. Zum einen, da zB. 12MHz aufgrund des internen Aufbaus inkompatibel zu den anderen Möglichen (konkret Samplefreq) ist. Zum anderen (vorrangig), da im unprogrammierten (i.A. ausgelieferten) Zustand alle internen Bits zu 0 gesetzt sind und die Clock Ausgänge highZ haben - damit hat der uC keinen Clock und kann auch nicht per i2c diesen einstellen. Zum Glück kostet der eine uC Quarz nicht die Welt, allerdings wird es ggf. asynchron, was wieder durch Register ausgeglichen werden muss. Man kann den Cy22150 auch programmieren per JEDEC, aber das Gerät CY3672 dazu kostet ca. $300 (nicht gerade erschwinglich für den einmaligen Gebrauch). Daher mein Vorschlag, alle 6 clocks an den CPLD legen und intern per MUX selectieren, per uC eine Grobauswahl treffen, da die Clocks auch nur auf jeweilige verschiedene Freq.bereiche zu gebrauchen sind. Damit kann man sich den CPLD internen Teiler schenken und hat wieder ein paar MC für die Triggerlogik/SRAM übrig. BTW, Cypress liefert ein Programm mit, Cyberclocks, da kann man schon die Einstellungen probieren (http://www.cypress.com/portal/server.pt?space=CommunityPage&control=SetCommunity&CommunityID=209&PageID=418&r_folder=Software%20and%20Drivers&r_title=CyberClocks%20R3%2010%2000). Viele Grüße Olaf
Ha, mit den 6 Ausgänge auf den CPLD knallen war quatsch. Der CPLD XC95xxx hat ja drei Clock Eingänge GCL{0,1,2}. Damit stellt sich (die nicht forengerechte Frage), wie diese dynamisch im CPLD verbunden werden können....
Hi, ich hab mir heute mal die neue Elektor angeschaut. Es wurden USB Oszilloskope verglichen. Recht positiv war das Ergebnis fuer das BitScope. Die Schematic's sind frei, vielleicht kann man was fuer die Probe's da abschaun. Gruß, Dirk
ich habe mir bitscope schon 'mal angesehen vor einiger Zeit, allerdings bin ich mir über das Teil nicht so ganz schlüssig beim (nochmaligen schnellen) übersehen, lasse mich aber gerne korrigieren. Im Schaltbild bs-sch-03.zip/bs300-3.pdf wird ein D-Latch 74HC573 vom POD (LA-Eingang) mit Samples "geladen". Mir kommt es vom Konzept her vor, als ob es mehr ein extension Port ist, der hier als LA missbraucht wird. Irritiert bin ich zB. an Postion B7, da der Out1 des DAC TLC7524 an den Out des OP-072 geknippert ist u.a. ... Vielleicht soll man es ja kaufen und nicht nachbauen ... Viele Grüße Olaf
Hallo, habe hier noch ein fertiges Teil gefunden was ist davon zu halten? http://www.pctestinstruments.com
Hallo,
> habe hier noch ein fertiges Teil gefunden was ist davon zu halten?
wens interessiert, ich hab so ein Teil in Benutzung.
Kurz gesagt: sein Geld wert, definitiv die beste Alternative am Markt,
wenn man für kleines Geld schnell und viel messen will.
Wer fragen dazu hat, kann sich gerne bei mir melden.
Michael
und wo hab ihr das gekauft aus Amiland bestellt? Braucht man eine Kreditkarte dazu, Vorabüberweisung oder wie hab ihr das gemacht?
Hallo alle, wie schaut es eigentlich mit diesem Projekt aus? Da ich großes Interesse an so einem Gerät hätte, hoffe ich, daß es nicht nur bei einem Planspiel bleibt.
Hi, ja, das Projekt lebt noch und ist auch aktiv. Derzeitiger Realisierungsstand: - VHDL Design: notwendig, um einen konkreten CPLD fest zumachen. Auch wurde in div. AN darauf hingewiesen, durch XST die I/O festzulegen, damit der Speed optimal verlegt werden kann. Daher hat ein konkretes PCB Design erst danach Sinn. Fertig ist zumindest ein bit pattern und edge trigger mit Testbench und kleinere generic Components. An komplexeren triggern arbeite ich gerade. Es dauert deswegen so lange, da VHDL für mich total neu ist (entgegen C/C++) und so einige "sprachliche" Barrieren überwunden werden müssen ;) Es fehlt der konkrete SPI Slave (eine Umsetzung existiert Dank Jörn, aber noch nicht eingebunden/verifiziert) zur Anbindung des AVR, Dirk macht einen neuen Versuch für seine SRAM Ansteuerung :-) - Das "Literaturstudium" ist soweit eigentlich abgehackt, gelegentlich kommen kleine Infos halt hinzu, da es eben immer konkreter wird. - Die Eingangsstage ist ebenfalls bei Dirk in Arbeit; konkret habe ich ein PCB in eagle mit MX864 entworfen, welches er aufbauen, testen und seine Kommentare dazu geben wird - ich habe schlichtweg das Testequipment nicht (ausser Scope ist nicht's da, dass sind meine nächsten Projekte...). - ansonsten wächst auch gedanklich das Konzept weiter, http://www.mikrocontroller.net/articles/Logic_Analyzer#Datenbl.E4tter.2C_Bezugsquellen_und_Preise_.28allg..29 ist nicht mehr ganz 100% aktuell, die updates stehen in diesem Thread. - über den konkreten Stand der Software von Hans kann ich leider nichts sagen. Aus diesen und dem Nachbarthread http://www.mikrocontroller.net/forum/read-1-225498.html#new besteht da aber auch von anderen Konzepten ein dringender Bedarf. Ich werde mich da nicht aktiv einbringen, da ich sonst zu viele "Baustellen" habe. Was fehlt sind sachdienliche, konkrete Hinweise zur Inputstage Gestaltung, preiswertere Teile/Bezügsmögl., also da, wo eigentlich wieder viele mitmachen könnten. Teilweise sind die Threads in einen Monolog verfallen :-( ZB. gefällt mir der CY22150 nicht so recht, da evtl. Overkill mit seinen beiden 2 PLL-Bänken - oder gerade recht, da so neben dem Samples vom LA auch ein PRBS Signal als Pattern Generator mit einer komplett anderen Taktfreq. generiert werden kann. Dies hängt vom konkreten Platzbedarf des LA im CPLD ab. Leider fahre ich Mitte dieser Woche in den Urlaub, so dass es von meiner Seite erst Ende September weiter gehen kann. Realistisch geschätzt könnte zur Weinachtzeit der LA stehen - dann steht aber auch die Frage, gleich einen Satz PCB fertigen zu lassen oder eben nicht. Hintergrund: 2 seitiges PCB mit (möglichst ununterbrochenen) Bottom Gnd Layer, welcher aber auch viele Durchkontaktierungen zum Top Layer Gnd benötigt aufgrund des High Speed Designs (teilweise hier schon diskutiert). Ein 4-Layer PCB wäre sinnvoll, aber da kostet dieses wohl schon mehr als 100 Euro. Einen Entwurf werde ich aber hier zur Diskussion rein stellen, um die Entscheidung zu erleichtern. Viele Grüße Olaf PS: Es freut mich zu lesen, dass trotz der anfänglichen Euphorie noch immer Interesse besteht, auch wenn es so lange dauert und einige ungeduldig sind! ;-)
@ope: Für wieviel Kanäle ist im Moment das LA Design ausgelegt? Kannst du mir mal deine Emailadresse geben? oder eine kurze Email an Joern@Joernline.de schicken. Ich hab noch was, das ich dir geben kann. Gruß Jörn
Hallo, >- Die Eingangsstage ist ebenfalls bei Dirk in Arbeit; konkret habe > ich ein PCB in eagle mit MX864 entworfen, welches er aufbauen, > testen und seine Kommentare dazu geben wird - ich habe schlichtweg > das Testequipment nicht (ausser Scope ist nicht's da, dass sind > meine nächsten Projekte...). Ich warte ihmo noch auf die als Sample bestellten Max864. Ich hoffe diese kommen bald. Die Platine kann ich erst am Freitag aetzen und hoffe das ich somit in der 36. KW die ersten Ergebnisse liefern kann. Gruß, Dirk
> Für wieviel Kanäle ist im Moment das LA Design ausgelegt?
Derzeit versuche ich soviel wie es geht generic zu machen, aber 16-18
Channel sind geplant. Dieses kommt auch der Umfrage im Wiki am
nächsten. Der erwähnte bit/edge Trigger ist komplett generic.
Hintergrund: Ich versuche eine Transitional Timing Analysis
durchzuführen, d.h. das "Datum" wird mit Zeitstempel und Wert
abgespeichert.
Dies heisst indirekt, dass SRAM mit 36 Bit breiten DB (4 bit werden
normalwerweise für Parität verwendet) eingesetzt werden sollen/müssen.
Damit ist nur ein SRAM auf dem PCB, und es können zB. 18 Bit breite
Samples mit 262k Sample Timestamps gespeichert werden. Somit spielt es
auch keine Rolle mehr, wie schnell sich zB. der Bus ändert sondern nur
noch wie oft - einige Kommerzielle nennen das wohl Datenkompression ;-)
dabei hat das schon einen Namen...
Wesentlich mehr Kanäle wären nur mit einem 2tem SRAM möglich.
Eine Frage steht aber bei den 36Bit SRAM noch aus: kann ich über die
Paritätsbits des SRAM selber frei verfügen oder wird dieses im SRAM
selbst berechnet; oder ist dies wieder SRAM Typ abhängig? Ich habe mich
mit den 11,25 des CY7C1351F-100AC schon angefreundet :)
Viele Grüße
Olaf
Hi, das SRAM Modul ist gestern abend fertig geworden. Ich habe dieses Modul verifiziert mit der Timing Analyse. Alle Prozesse laufen wirklich synchron. Eine Anbindung an ein synchrones SRAM waere nun vom Vorteil. Eine Umwandlung auf Generic sollte weniger das Problem sein. Ich frage mich nur wozu ich mir die Arbeit dafuer mache. Im Endeffekt wolltest du (Ope) selbst nochmal die SRAM Anbindung schreiben. Aus diesem Grund ueberlege ich seit gestern wozu ich die Inputstage bauen soll und vermessen soll. Die Kosten / Zeitaufwand waeren somit umsonst, weil anscheinend du das Projekt komplett im Solobetrieb meistern moechtest. Theoretisch koennte ich mich nun zuruecklegen und auf ein fertiges VHDL Prg warten. Gruß, Dirk
@Dirk, dass ich das Projekt nicht als Solo durchführen möchte, sollte aus den vorhergehenden Beiträgen eigentlich klar hervorgekommen sein. Mir geht es nur darum, aus zB zwei Entwürfen mit ihren Aspekten/Erfahrungen, unabhängige Ideen zu sammeln, so dass letzlich sich beide Entwürfe treffen und es eine bessere Merged-Version gibt. Du darfst dabei auch nicht vergessen, dass wir beide als VHDL Anfänger (zumindest ich) Sicherheit benötigen - diese lernt man nicht beim Durchlesen, erst wenn man es selber schreiben/coden muss. Wenn ich am SRAM schreibe, bin ich mir sicher, stosse ich auf die gleichen Probleme wie Du - beim durchlesen Deines Sources werde ich nicht begreifen, warum Du es genau so gelöst hast. Also, neben dem LA sehe ich auch einen imo sehr wichtigen Lerneffekt dabei. Viele Grüße Olaf
Hallo Olaf, Dirk und alle anderen Aktiven hier, schön zu lesen, daß es weiter geht. Leider kann ich mich nicht beteiligen, bin zwar Berufselektroniker, aber das hier übersteigt dann doch meine Fähigkeiten. @Olaf: daß Du Urlaub machst, ist doch kein Hinderungsgrund, weiter zu machen. Laptop mitnehmen! I-Net Anschluß findet sich schon irgendwo. Nee, war Spaß. Schönen Urlaub, Andreas
Hi, vom Lerneffekt her hast du recht, aber vom nutzen her muss ich Dir leider wiedersprechen. Das Projekt dauert somit laenger und feststellen kann man vielleicht nur das einer effektivieren Vhdl Code schreibt. Mit effektiver meine ich jetzt nur weniger Makrozellen. Ein richtiges Gemeinschaftprojekt ist es normal so nicht. Wozu ein Gemeinschaftprojekt wenn z.B. 20 People irren eigenen LA entwerfen? Jede Person hat einen anderen Schwerpunkt z.B. Person 1 will 8 Mybte Speichertiefe , Person 2 will 16 Eingaenge , Person 3 will 100 Mhz Samplerate und schon kocht jeder seine eigene Suppe. Gruß, Dirk
> und schon kocht jeder seine eigene Suppe.
Dann muß man sich halt einigen und dann geziehlt die Aufgaben je nach
Fähigkeiten vergeben.
>> und schon kocht jeder seine eigene Suppe. davon kann eh keiner abgehalten werden, weder von uns beiden noch andere. >Dann muß man sich halt einigen und dann geziehlt die Aufgaben je nach >Fähigkeiten vergeben. Auf das einigen kommt es an! Bisher gab es auch keine Kollisionen oder Überschneidungen ... !! Sicher hat auch jeder andere Projekterfahrungen, bei beruflichen wie auch privaten Projekten, als Projektleiter oder "Mitmacher". Möchtest Du alles straff organisieren, kategorisieren, modularisieren, ... wirst sehr schnell feststellen, dass es ein Fulltime Job wird, die Zeit dürften wir beide/andere nicht haben. Auch beim Festlegen von Schnittstellen vergeht verdammt viel Zeit, teilweise wird dann doch festgestellt: es passt dennoch nicht zusammen, da der Gesamtüberblick fehlte. Bei den allg. Softwareproj. zumindest sind imo keine an irgendwelchen Gerangel gescheitert, schlimmstenfalls kam es zur Spaltung, samba e.g. Konkret hier muss erstmal der Core stehen, um zu sehen, was mit einem CPLD gemacht werden kann oder ob eben doch (letzlich auch aus preislichen Gründen, bei http://www.Darisus.de kostet der XC2S50-5PQ208 ungefähr genauso viel wie ein XC95288XL) ein FPGA her muss, der den AVR überflüssig machen würde und andere Möglichkeiten/Lösungen offenbart/bedingt. > kann man vielleicht nur das einer effektivieren Vhdl Code schreibt. > Mit effektiver meine ich jetzt nur weniger Makrozellen. Ein Optimierungen dauern lange ..., zB habe ich bei meinem Trigger 5 MC dank einer (komplexen) logischen Verknüpfung mehr als erwartet - das bleibt erst mal wie es ist und kommt (hoffentlich) später weg. Das ist zumindest meine Strategie. > richtiges Gemeinschaftprojekt ist es normal so nicht. Wozu ein > Gemeinschaftprojekt wenn z.B. 20 People irren eigenen LA entwerfen? Bisher müssen hauptsächlich wir beide uns nur einigen (evtl. gibt es ja hier noch einige anonymous Ghostwriter). Evolutionen wird es geben mit all ihren Konsequenzen. Bzgl. der LA Lösung bzw. "Typ Bestimmung" (ja, genau da hängen wir derzeit/noch immer!) bin ich Opportunist, wie es evtl. auch hier im Forum schon 'rausgeschaut hat; egal ob FPGA und 2 USB Buchsen (nach einem Hinweis von Jörn auf http://sus.ti.uni-mannheim.de/Uxibo/) oder sonstiges, solange es eben zweckdienlich ist. > Jede Person hat einen anderen Schwerpunkt z.B. Person 1 will 8 Mybte > Speichertiefe , Person 2 will 16 Eingaenge , Person 3 will 100 Mhz > Samplerate und schon kocht jeder seine eigene Suppe. mit dem generic kann man schon viel machen (bis auf unconstrained records anscheinend). Allerdings macht es ein gutes Programm aus, anpassbar zu sein! Bisher ist es egal, ob 8,16,...64 Kanäle, 1 oder N SRAM Speicher - die 100 Euro Marke und der Aufwand im PCB steht im Raum. Über konkretes können wir uns nicht sinnvoll unterhalten, da der Core nicht steht .... Morgen ist der letze Tag in De, dann geht es zu den Minensuchern und Bombenlegern nach Ägypten. Ich werde vorsichtshalber ;-) die bisherigen Projektfiles forenfremd hier 'rein stellen - entweder noch heute Abend oder morgen. Viele Grüße Olaf
da sind sie, musste noch etwas aufräumen. Heute schaffe ich es wohl nicht mehr, einen grossen Fortschritt zu erzielen. Ein Großteil der Files ist auf "Vorrat" geschrieben, interessant ist das trigger.vhd mit tb_trigger. Evtl. sollte dieser Core Teil wirklich in's andere Forum verschoben werden, sonst gibt's Ärger. Leider explodiert die Argumentliste so langsam, so dass ich sie in einen record packen würde; leider ist das generic nicht möglich (so einfach zumindest). Viele Grüße Olaf PS: selbst wenn es X verschiedene Cores geben würde, Hauptsache sie passen zur Hardware und sind im API für die PC Software (halbwegs) kompatibel. Daher ist Board/Firmware Rev. Info gar nicht so verkehrt, imo auch guter Stil.
Hallo, wenn der CPLD vom AVR aus programmiert werden soll -> http://www.mikrocontroller.net/forum/read-4-228557.html#new schöne grüße, Clemens
Hi, bin wieder (in ganzen Stück) aus Ägypten angekommen, es geht jetzt also von meiner Seite wieder weiter. Allerdings werde ich einen neuen Thread unter "Programmierbare Logik" anlegen für den LA Core, da dieser Teil dann doch zu speziell für dieses Forum ist; also Augen auch dorthin richten, wer es noch nicht tat. Viele Grüße Olaf
nach dem Monolog manchmal zu urteilen ja; dann würde ich aber Dirk - shazter(at)web.de und Clemens Helfmeier (sum) Unrecht tun - wir treffen uns des öfteren im chat room. Gelegentlich kommen dann auch von anderen einige Hinweise oder Fragen.
Idee ist nicht schlecht die Daten über die CPU Port´s einzulesen und dann abzulegen... aber das dauert. Andere Lösung es gibt durchaus die Mgl die daten direkt in das Ram zu lesen CPU legt nur die Adressen an das CMOSRAM die Datenleitungen selbst sind die Eingänge, mit einer Vorbeschaltung Tristate Bustreiber und so. Dann erschließt sich der nanosekundenbereich. Die ganze Datenbaggerei fällt weg. Paul
Hi, leider kann ich im moment nicht soviel Zeit investieren wie ich gerne möchte, aber bis Sonntag sollten schon von meiner Seite aus ein paar Sachen fertig sein. Der Monolog tritt hier nur im Forum auf, weil Ope, Sum und ich besser/schneller im IRC Chat Probleme diskutieren/lösen können. Es wurde wieder die Hardware abgeaendert was natuerlich wieder ein zeitlicher Rückschlag ist, aber persönlich bin ich mit dieser Lösung zufriedener. Das Projekt insgesamt schläft nicht, aber man sollte nicht vergessen das dieses Projekt in der Freizeit gemacht wird und einige nebenbei auch in der Freizeit was zutun hat. Bis zum Winter ist noch viel Zeit und die Einschaetzung von Ope sollte einzuhalten sein. >CPU legt nur die Adressen an das CMOSRAM die Datenleitungen selbst >sind die Eingänge, mit einer Vorbeschaltung Tristate Bustreiber und >so. Die verschienden Triggermöglickeiten wuerden bei dieser Variante entfallen und der CPLD schafft locker 100Mhz zu sampeln. Die Nanosekundengrenze ist nicht wirklich das Problem eher die Hardwareanforderungen am Platinenlayout. Im grossen und ganzen kann ich von meiner persoenlichen Einschaetzung hersagen das jeder ihmo was zutun hat an dem Projekt. Gruß, Dirk
so, heute mal 'ne Frage wegen des sram und dem cpld. Wie Dirk sagte, ist es mit dem Layout nicht so einfach. Da der sram ja random access ist, sollte die konkrete Zuordnung der Adressen, die aus dem CPLD kommen und an den SRAM gehen, willkürlich sein bzw. einem guten PCB geschuldet sein. Das gleiche trifft ja auch auf die Daten zu. Der SRAM ist ja assoziative - das was ich auf im CPLD auf Adresse X ausgebe, auf Adresse Y im SRAM speichere, und da pcb zeitinvariant, ja auch wieder auf CPLD Adresse C wieder einlese. Ich muss lediglich per ucf sagen, wo ich den AB/DB/CB des SRAM am CPLD angeknotet habe, oder? Viele Grüße Olaf
kennt ihr das? http://www.circuitcellar.com/dl2001/avr-r206.htm hab ich gleich an euch gedacht, und stell's mal so hin. ich suche aber was einfachereres. tschüss!
So, für alle die den LA schon der Versenkung gesehen haben: JA, ER LEBT NOCH .... der LA ;-) Nachdem festgestellt wurde, dass die 74LVC425 + CPLD + AVR + SRAM + FT245 + EEPROM + Spg.regler ungefähr auf Europa Format kommt, haben wir diesen Entwurf erstmal delayed. Derzeit ist eine reine FPGA (XC2S100) Lösung + ext. SRAM Option(?) + 74LVC425 + FT2232 + EEPROM im Gespräch, aber noch immer nicht konkret ausgegoren bzw. Aufbau-/Nachbaufertig. Viele Grüße Olaf
Guten Abend zusammen (wer ist noch da?), ich wurde darauf angesprochen, mich dochmal wieder zu melden: Hier bin ich! :) Kurze Zusammenfassung des derzeitigen Standes: Wie schon erwähnt, ist die FTDI-Lösung zu unflexibel und zu großflächig. Also steht der zeit eine SAM7-Lösung zur Diskussion: USB -> AT91SAM7S321/64 -> XC2S100/200 -> 3x 74LVC4245 Es werden 3 Levelübersetzer benötigt, um auch Clock, Trigger, etc. synchron am FPGA zu erhalten (sonst geht der ext. synchrone Clock verloren weil die Datenleitungen zu langsam wären). Die Direction-Pins der Level-shifter werden mit in den FPGA geführt. Der AT91SAM7S wird per USB (nur Buchse und Widerstände erforderlich) über ein bisher noch in der Diskussion stehendes Interface (UART/SPI/Parallel) an den FPGA angebunden. Für den FPGA haben wir derzeit das PQ208-Gehäuse im Auge, dort ist der FPGA etwa 2/3 so teuer wie im TQ144 und kann noch nach oben erweitert werden - für die, die mehr Speicher brauchen. Das externe SRAM ist auch entfallen, da die größeren FPGAs ausreichend interne Speichermöglichkeit haben und das Platinenlayout durch einen externen SRAM um ein vielfaches komplizierter werden würde. Wir merken das mal für Version 2 vor. Ich bin derzeit dabei (soweit ich Zeit finde - leider sehr wenig :(), die variable Versorgung für die Level-Shifter zu organisieren. Diese soll vom ARM gesteuert werden und möglichst wenig Bauteilaufwand haben. Mehr als nur eine einstellbare Ausgangsspannung wäre durchaus praktisch. Für Anregungen bin ich dankbar. Schöne Grüße, Clemens
vielleicht über ein kleines Wiederstandsnetzwerk einen D/A-Wandler nachbilden oder man nimmt gleich nen kleinen D/A Wandler. Die High Ausgangspegel der verschiedenen Bausteine betragen ja je nach Typ 2,7V(LS,ALS) und 4,5V(HC,HCT) jeweils bei 5V Versorgungsspannung, deswegen wird doch nicht viel mehr nötig sein. (Was sagen hier die Praktiker) die öfters mit LA's arbeiten? Was haltet ihr von einer einschaltbare Pulldown-Wiederstandsreihe(10 oder 20kOhm) um sichere Lowpegel zu bekommen?
Hallo Thomas, die Idee mit dem DA-Wandler ist mir auch gestern gekommen. Da wir aber nur 5V zu Verfügung haben (USB-Spannung), wird sich die Umsetzung ein wenig schwierig gestalten. Was meint ihr zum folgenden Plan: der µC benutzt einen PWM um eine Spannung zwischen 0 und 3,3V zu erzeugen (über RC-Glied, braucht ja nicht schnell zu sein). Diese Spannung wird mit 5/3 von einem OP verstärkt. Der OP hat einen Rail-to-Rail Ausgang und versorgt sofort den Levelshifter. Ich bräuchte jetzt nur Erfahrungswerte, welchen Strom der LVC4245 verbraucht. Im Datenblatt von Phillips steht (-40..85°C) 10µA + 0.5mA/Pin. Folglich würden etwa 5mA anfallen. Reicht das? Als OP könnte man z.B. den OPA353 von TI nehmen (Reichelt hat ihn). Dieser liefert bei 10mA Vcc-0.2V. Damit wären für einen Levelshifter ein ganzer OPA353 nötig. Alternativ könnte man auch noch den OPA2340 nehmen, der enthält 2 und es würden somit 2 OPs reichen. Hinzu kommen pro OP noch ein RC-Glied und ein R/R-Spannungsteiler für die Rückkopplung Was meint ihr zu dieser Idee? Schöne Grüße, Clemens
also ich persönlich würde nach Möglichkeit auf einen OP verzichten. Hier ist mal kurz eine Seite wo die einzelenn Level aufgeführt sind und beim Empfang der Highlevel liegt die Grenze/Toleranz ja auch schon ein ganzen Stück unter dem Sendepegel. Siehe http://www.fh-sw.de/sw/fachb/et/halbl/stdlogik.htm#Kombination%20unterschiedlicher Und wenns um möglichst wenig Bausteine geht würde ichs mit ein paar Wiederständen machen so das man mit 4 Pins 16 Stufen selektieren kann bzw. die Versorgungsspannung der Comperatoren steuern kann. Wie sind die High Eingangspegel eigentlich bei dem FPGA oder was jetzt zum Einsatz kommt wenn dieser schon sehr empfindlich ist würde ja ne Abschwächung über Wiederstandsnetzwerke(Pulldowns) wo man die Masse schaltet reichen, Also z.b. 2 Wiederstandsnetztwerke mit 10k 20k die man dann je nach bedarf gegen Masse schaltet.
Angehängte Dateien:
-
FPGA_LA.jpg
68 KB
Hallo zusammen, ich schiebe auch mal ein Update von meinen Bemühungen einen reinen FPGA LA zu bauen ein. Die Platine ist inzwischen bestückt und zum Teil in Betrieb genommen, siehe Bild. Das FPGA läßt sich über den USB programmieren und Daten können zwischen PC und FPGA ausgetauscht werden. Mein 8-Bit LA ist schon erfolgreich im FPGA gelaufen. Was noch fehlt ist der Umbau auf 16 Bit, das Testen des externen ASRAMs und eine Software für das Setzen der Trigger bzw. die Auswertung der aufgenommen Daten. Gruß Jörn
Hallo an alle, ich suche schon seit einiger Zeit nach einen µC für höhere Ansprüche. Mein Vorschlag für diese Projekt ist AT91SAM7S128 von Atmel. Vorteil USB2.0 auf den Chip und über USB programmierbar SAM Boot Assistant (SAM-BA) User Guide http://www.atmel.com/dyn/resources/prod_documents/doc6132.pdf bis 60Mhz Taktfrequenz 7,98 EUR bei spoerle.de Er ist ein bischen komplizierter (ARM7TDMI Architektur) doch für diese Projekt eingentlich die beste Wahl. Gruß Hubert
wiki update. Letztens schrie ich noch: Er lebt noch. Inzwischen würde ich sagen, er steckt fest und ist in einem Dämmerzustand. Viele Grüße Olaf
Tut sich beim Projekt noch was oder hat schon einer das Teil am laufen oder macht noch was dran?
Na, ich würde sagen (aus meiner Sicht), das Projekt hält einen Dörnröschenschlaf :-) Es ist eingeschlafen aus mehreren Dingen; u.a. wegen verschiedener Ansichten (war aber nicht der Hauptgrund), vielmehr musste ich mich auf die Fertigstellung meiner Dissertation kümmern (nein, das ist kein Protzen - eher eine Entschuldigung bzgl. der Prioritätensetzung) und dann kam mein Junior zur Welt. Z.Zt. habe ich ein 1/2 Jahr Probezeit, so dass während dieser Zeit auch nichts ernsthaftes passieren wird. Aus den Augen verloren habe ich es nie ganz, nur ist es eben bei mir Hobby && Freizeit! Grüße Olaf
Vielleicht wichtig f"ur interessierten : Der logic analyser von www.pctestinstruments.com (LogicProbe) habe ich gekauft. Sehr schones instrument, er benutzt FPGA con Altera : Cyclone EP1CYF324C6 und FT245 Patrick
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.