Announcement: there is an English version of this forum on Dieser Beitrag wurde auf Wunsch des Autors geloescht.
Hi, ich wuerde gern zwei bis drei Platinen nehmen. Zur RTC muss ich sagen, dass es vll. geschickter ist, da einen NTP (network time protocol)-Clienten per Software zu implementieren. Dann hat man immer gleich eine mit den anderen Rechnern synchronisierte Zeit. Natuerlich hat man mit einer RTC auch die Moeglichkeit einen NTP-Server zu betreiben, aber auch eine Quarz-RTC hat halt ihre Gangungenauigkeiten. Die PoE Option ist natuerlich nett, aber ich denke die wenigsten besitzen dazu passende Switchs oder Injektoren. Wenn es aber nicht zuviel Platz auf der Platine nimmt bin ich auch dafuer. Ansonsten finde ich die Idee natuerlich Klasse. Frohe Weihnachten noch. Gruß Tobias
Hi, also ich hätte auch interesse an so ner platine .... lass mir noch durch den kopf gehen was man noch gebrauchen könnte. mfg Moritz
Ein USB-Host-Controller wär richtig fett. Dann könnte man diese billich Webcams anschließen.
Hi. Also, ich hab zwar kein Interesse an einer Platine, aber da ich selbst gerade ein Ethernet Board mit nem ATMega128 baue, interessiert mich dein Projekt natürlich! Du schreibst ja: "Da ich mir die Platine alleine nicht leisten kann, habe ich andere Leute hier ausm Forum schon gefragt, was sie z.B. noch gerne auf der Platine haben wollten, wenn sie eine mitbestellen würden." Ahm... wenn du z.B. bei Olimex bestellst, dann kostet dich eine Eurokarte von vornherein "nur" 31 USD inkl. Versand (vielleicht 36 USD, wennst viele Bohrungen hast). Und wenn deine Platine eh nur ne halbe Eurokarte benötigt, dann kommt dir eine Platine sogar unter 15 Euro (was für Einzelstücke bzw. Prototypen sehr günstig ist, oder?!). Soviel nur dazu... Ich hab auch überlegt, ob ich ein Compact Flash Interface draufmachen soll, hab mich dann aber für ein Flash mit 1MByte Speicher entschieden. Ist vielleicht auch eine Anregung für dich. Außerdem hab ich statt eines RS232 Anschlusses ein USB Interface (mit FTDI Chip - FT232BM) aufs Board gegeben. Was mir bei deinem Board besonders gefällt, ist, dass es in dieses Gehäuse passt. Kleine Eckdaten zu meinem ATEthernet Board: * ATMega128 * 32kByte SRAM * 1MByte Flash * USB * 10Mbit Ethernet * RTC (Counter am ATMega) mfg Andreas
Hallo Guido, ich würde auch ein oder zwei Platinen nehmen. Das PoE werden die meisten nicht brauchen. Daher könnte man daß vielleicht als optionale Huckepack- Platine vorsehen ? Dann kann man es bei Bedarf nachrüsten und es nimmt keinen Platz weg. Dafür wäre ein Anschluss für ein alphanumerisches Display nicht schlecht. Das wird doch recht oft gebraucht. Eine Atmel Dataflash Chip wäre noch ne Idee für eine Option. Da kostet der Chip warscheinlich weniger als ein MMC-Sockel. Ein Dallas/Maxim DS2502-E48 (TO-92 Gehäuse / 1-Wire IF) der eine feste MAC-Adresse enthält bräuchte auch kaum Platz. (Muster über Maxim) Gruß Andreas
Hi Guido, Kurz du deinem Dataflash. Also, wie gesagt hab ich ja auch ein Flash auf meinem Board drauf. Ich verwende eins von Atmel mit SPI Interface. Heisst AT45DB081 (1MByte). Das Flash wird mit 3,3V versorgt und hat 5V tolerante Eingänge. Wenn du es mit 3,3V versorgst, kannst den seriellen Ausgang des Flash problemlos an den Mega anschließen - der Mega erkennt 3V als High-Pegel und das Flash gibt laut Datenblatt mindestens VCC-0,2V als High-Pegel aus. mfg Andreas
Hallo Guido, ich wäre an folgender Platine interessiert: - ATmega128 - 64..512 kByte banked SRAM - RTC - ISA-Steckplatz für RTL8019AS/NE2000-Karten - MMC Sockel - (optional) Adressdekoder für Zusatzhardware 100x160 wäre für mich OK. Ich habe auch noch eininge Karten, und möchte den RTL8019AS nicht herunterlöten... Gruß Fiffi
Hi, also 100*160 + nen ISA-Slot ist ja wohl totale Platzverschwendung. So schwer kannes auch nicht sein, den RTL von der Platine zu bekommen und ihn dann wieder auf eine Industrie gefertigte Platine zu loeten. Beim Speicher bin ich auch eher fuer fuer eine MMC. Da kann man danna uch mal problemlos den Speicherausbau variieren bzw. ganz weglassen ohne etwas zu loeten. Ein Display duerfte sich wohl auch relative leicht ueber die Porterweiterungen anschließen lassen. Da es ein sichtabres Teil ist, hat da eh jeder eine andere Vorstellung was er da verwenden will. Wenn PoE Huckepack geht waere das auch nicht schlecht, aber ich glaube, dass das Gehaeuse das nicht zulaesst. Gruß Tobias
Hallo, Also iuch hätte auch an einer PLatine interesse, wenn der Preis so um die 15 Eur rum hinkäme. Ich persönlich würde die MMC dem Data Flash vorziehen. Auf PoE kann ich verzichten Schöne Feiertage noch Steffen
@Guido Ich weiss, es passt nicht zu deiner Frage, aber kannst du mir vieleicht deine EAGLE3D Libary zukommen lassen. Besonders bin ich an der RJ45 Buchse und dem CF Adapter interessiert. Hoffe es macht keine dir keine grossen Umstände. Ansonsten noch ein restliches frohes Fest und danke im voraus... Gruss der Schlumpf
@Der Schlumpf: Bezüglich des CF Adapters kann ich dich gleich auf die bei Eagle enthaltene Library "con-3m" verweisen. Dort sind 2 Versionen eines CF Slots drinnen! @Guido: Wegen Bezugsquelle für ein Dataflash. Ich hab meins von RS-Components. 1MByte kostet dort etwa 5-6 Euro. Falls jemand was billigeres weiß, nur her damit! mfg Andreas
@Guido Danke, die Eagle Bauteile hab ich ja auch... Ich meinte für Eagle 3D und PovRay die Render Daten, um diese Bauteile erzeugen zu lassen. Die sind in der aktuellen Version von Matthias (Matwei) nicht erhalten. Hab sie halt nur in deinem PDF gefunden. Also, falls du diese zukommen lassen könntest, wäre super. Der Schlumpf
@Guido: Das Gehäuse heisst glaub ich TSOP28. So gibt es das Flash zumindest bei RS-Components. Wenn du willst stell ich meine Eagle Lib hier rein! mfg Andreas
Hi der Die des Flash ist schon relativ groß. Der paßt rein mechanisch schon in kein SO8 mehr rein. Matthias
Sehe ich das richtig: Di Platine hat eine voll Funktionsfähige RS232 Schnittstelle?
Hallo Guido, der Dataflash läuft laut Datenblatt von 2,7 bis 3,6 V Also Betrieb an 3,3 V. Die Eingänge sind 5 V tolerant also direkt mit dem M128 zu verbinden. Der Mega128 hat laut Datenblatt einen min. High-Pegel von 0,6 x VCC also 3 Volt. Der Dataflash liefert als High-Pegel VCC - 0,2 V also 3,1 Volt. Sollte also auch direkt passen. Atmel beschreibt zwar in dieser AppNote die Anpassung an ein 5V System, geht aber von 0,7 x VCC für CMOS aus und empfiehlt für den Ausgang einen Pegelwandler. http://www.emesystems.com/pdfs/parts/AT45DB041-3volt-5volt.pdf Grüße Andreas
Wenn wir uns beim Dataflash auf 4MBit also 512 Kilobyte beschränken, wäre es nur ein kleines 8-poliges Gehäuse. Das dürfte für sehr viele Anwendungen mehr als genug sein. Für mehr Speicher dann eben MMC. Kosten hier 3 Euro das Stück : http://www.elektro-nix.de/pd-1521253076.htm?categoryId=14
Hallo Guido, wenn Du statt des separaten Übertragers für das LAN einen RJ-45 Connector mit intergriertem Übertrager vorsehen würdest, würde dass einiges an Platz sparen und auch nicht viel mehr kosten. Ausserdem gibt es die RJ-45 Buchsen auch mit integrierten LED´s, sodaß man auch den Status von aussen sieht ohne noch Löcher ins Gehäuse bohren zu müssen. Wär vielleicht eine Idee. Grüße Andreas
Dann such dir eine Alte PCI / ISA Karte die das alles schon hat ;) Was anderes.. wenn man das ganze als reinen Webserver nutzen moechte um ein Paar bildchen etc anzeigen zu lassen meinst du sowas koennte man relativ flexibel realisieren? Mit verlinkten Dateinamen etc?
Hallo Guido, ich hab mir gerade mal die Daten auf deiner Homepage angesehen. in der 3 darstellung der Webserverplatine sieht man rote Buchsen, an denen die Ports des AVRs anliegen. Hat es nen bestimmten rund, das du diese spezial Buchsen verwendest? Ansonsten wären vllt 10pol Wannenstecker sinnvoller. Gruss, und Respekt für die Arbeit die du dir machst Steffen
@DB1Ulm >Wegen der geringen Höhe des Alugehäuse verwende ich hier die Tyco >Micromatch Verbinder, die dank Schneidklemmausführung für normales >Flachbandkabel geeignet und wesentlich flacher, als die Molex Wannen >sind. ;)
darum meinte ich ja auch PCI / ISA =) zumindest fuer die LEDs das mit dem Filter war mir neu, dass es sowas gibt die Karten, die ich bisher kenne haben alle den Externen Filter?? ich dachte immer, das waer auch eine Galvanische Trennung nunja =) Gruss Jens
Okay Asche auf mein Haupt :-) Das mit der größe ist einleuchtend :-) steffen
ok ok ok =)
Alles klar ;)
Zu dem Webserver hast du dir schon gedanken gemacht ueber eine
eventuelle allgemeine Firmware, die einige Spezifische Seiten einlesen
kann zB. dateien, wie das mit dem PHP funktioniert??
<html>
<head>
</head>
<body>
<?µc
ldi temp1, "h";
ldi temp1, "a";
ldi temp1, "l";
ldi temp1, "l";
ldi temp1, "o";
µC?>
</body>
</html>
weist, was ich meine??
Das man ueber die MMC Karte diverse Seiten in den Webserver einbinden
koennte, in denen dann noch etwas an ausfuehrbarem Code drin steckt..
Supi =) Tia das is tdas Problem mit em Code aus dem Flash :( daher evtl kleinere InLine Commands villeicht bekommt man damit was zustande.. oder aber man bekommt das ganze ueber inline assambler hin leider keine idee im momennt aber sowas mit dem ausfuehrbarem code hatte ihc schonmal als idee gehabt
Hi Bezüglich ausführbaren Code aus dem Flash... also der Mega128 kann leider keinen Code aus einem externen Speicher ausführen. Das geht leider architekturbedingt nicht! Wenn man Code aus dem externen Flash ausführen will, dann braucht man schon sowas wie nen Interpreter, was aber alles andere als schnell sein dürfte! mfg Andreas
Das befuerchte ich auch... Also ist nix mit Dynamischen Seiten auf dem Controller.. koennte schwer werden sowas zu realisieren
Was ich aber schon gesehen habe, ist, dass ein AVR als Webserver am Internet hängt und seine IOs per Internet geschaltet werden können. Also das funktioniert auf jedenfall. Und für die Interpretation einiger Zeilen in einer HTML Datei wird der AVR sicher auch in der Lage sein! Falls jemand sich so nen Webserver ansehen will. Bei eBay wird so einer versteigert. In dem Angebot ist auch ein Link wo angeblich dieser Webserver antwortet und wo dann IOs gesetzt werden können! Hier der Link: http://cgi.ebay.at/ws/eBayISAPI.dll?ViewItem&category=12949&item=5737803909 Mal kurz was anderes. Holt ihr euch alle die RTL8019AS Chips von alten ISA Karten runter?? Ich bin nämlich auf der Suche nach 2 Stück dieser Chips und trau dem ganzen runterlöten nicht so ganz. Will mir meine Platine ja nicht unbedingt versauen! mfg Andreas
Hallo Guido, /WP (Schreibschutz) ist laut Datenblatt mit einem internen Pullup versehen, also abgeschaltet wenn nicht verbunden. /RESET kannst Du ja mit dem Reset des M128 verbinden. Der Dataflash hat zwar einen Power On Reset, aber man will ja definierte Zustände haben, wenn man aufs Reset-Knöpfchen drückt. BUSY kann man auch einsparen, da man dieses Signal auch per Software über SPI abfragen kann. Grüße Andreas
@Andreas den RTL8019 gibt es bei Egnite zu kaufen. Kostet allerdings 10 Euro bei unter 10 Stück. http://www.egnite.de/
@Jakob Ja, das hab ich schon gemerkt. 10 Euro wären so auch nicht das Problem. Aber der Versand kostet nach Österreich 15 Euro oder so ähnlich. mfg Andreas
@all Ich hab im Forum unter Markt auch schon meinen Beitrag bezüglich der RTL8019AS Chips hineingestellt. Falls hier noch jemand so nen Chip sucht, weil er ihn auch nicht von ner Platine runterföhnen will oder kann, kann sich ja mal melden. Bei 10 Stück kostet das Ding dann "nur" noch 6,38 Euro. mfg Andreas PS: Hoffe, dass dieses Posting jetzt nicht ganz unter SPAM fällt!
Hallo Für denn WP-Pin: Wie wäre es mit einem Jumper? Auszuwählen wäre dann entweder 1. nach masse oder 2. zu einem Portpin. Ich würde mir noch mindestens einen Mcp2515 Cancontroller wünschen, besser 2. oder einen speziellen Erweiterungssockel wo die SPI drauf liegt und 2x CS. Gruß Topsoft Achso: Ich würde 5 Platinen nehmen. Und @Andreas 5 x RTL8019AS Chip wären interessant.
Angehängte Dateien:
-
CanNavi.jpg
42 KB
Hallo, der MCP2515 und ein Bustreiber müssten dann aufs Board. Anbei habe ich dir mal eine Ausführung meines TV-Tuner Dummys angehängt der bei mir den RGB-Eingang am Navi freischaltet. Angeschlossen werden müßten dann CS, SO, SI, SCK. Den Reset vieleicht mit auf den Prozessorreset, und der Int wäre natürlich dann noch anzuschließen. Wenn du dich aber für die Buchse entschließt müßten dort die Signale Reset, Cs1, Cs2, SO, SI, SCK, Int1, Int2 zur verfügung stehen. Eigentlich müßte der CanBusTreiber auch von Board galvanisch getrennt sein, was dann ja eher für die externe Lösung spricht. Der 82C251 ist besser als der 82C250 und den gibt es auch wie den MCP2515 bei Reichelt. Gruß Topsoft
anstelle der seriellen schnittstelle can-option Pin-belegung sub-d: 1 NC 2 CAN L 3 GND 4 NC 5 Drain 6 GND 7 CAN H 8 NC 9 NC
Also wenn schon CAN, dann aber bitte galvanisch getrennt. Bei Reichelt gibts schöne kleine DC/DC Wandler 11 x 6 mm. z.B. SIM1-0505 SIL4 8,80 Euro Die kosten übrigens beim Hersteller nur 4 Euro, ganz schöne Gewinnspanne hat Reichelt da :-)
hi hab hier en schaltplan gefunden. allerdimgs mit einem anderen bustreiber. http://www.mikrocontroller.net/attachment.php/139738/busk1_2.pdf
die Sd-card sitzt ja ganz am rand. wenn man den sockel auch drehen könnte. könnte man die karte vielleicht auch im gehäuse wechseln, wenn man in die seitenwand einen schlitzt fräst. bräucht halt meher platz.
vieleicht auf die unterseite. den Speiche kann man ja verschieben. Hast recht an die kurtzen karten hab ich garnicht gedacht. P.S. Ne Einerlegendewollmilchsau wär zwar toll aber, aber halt nicht machbar.
Hi zum Schaltplan: Ich würde an den ADC-Kanälen noch jeweils einen C im 0805 gegen Masse vorsehen. Verbessert das Verhalten des ADC's bei hochohmigen Quellen deutlich. Matthias
Hi @Topsoft Hab deinen Beitrag nicht übersehen ;-). Du würdest also 5 Stück brauchen. Ich selbst bräuchte auf jedenfall 2. Hätten wir schon 7. Bei egnite kostet der RTL8019AS + Transformer (6,38 + 1,25) 7,63 Euro (ab 10 Stück). Falls niemand mehr Chips bzw. Übertrager braucht, dann würde ich notfalls auch 5 Stück nehmen, damit wir auf 10 Stück kommen! Wenn jemand noch welche will, dann bitte auch unter Markt in meinen Thread posten. Dann wird dieser stark frequentierte Thread nicht auch noch belastet und es werden auch nicht so leicht Beiträge übersehen! Thanks. mfg Andreas
Hi du könntest eine USB-Mini-B Buchse (bei Reichelt USB BWM SMD bzw. USB BWM) Für die SMD-Buchse existiert auch schon ein 3D-Modell. Der FT245BM hat keinen CS und eine etwas eigenwillige Auswertung von RD/ und WR. RD/ ist Low-aktiv und WR high-aktiv. Ich würde den FTDI nicht in den Speicher einblenden (den Ethernet-Chip genausowenig) sondern nur parallel anschließen. Die Steuerleitungen für Ethernet und USB kommen dann an einen extra Port. Zum Zugriff wird dann das Speicherinterface mittels MCUCR abgeschaltet und die Ports per Software so geschaltet das ein gültiger Zugriff bei rauskommt. Das ist nicht wirklich viel langsamer spart dir aber die ganze CS Logik die bei den kurzen Buszyklen des Mega128 bei 16MHz eh kritisch ist. Matthias
Morgen, also RS232 oder Can ist natürlich nicht das anzustrebende. Da auch wenn der Can genutzt wird man sehr oft RS232 braucht. Und wenn es nur zum Debuggen ist. Könnte man den Can nicht auf einen 2 poligen Stecker(Jumper) legen? Da nimmt er doch kaum Platz weg. Gruß Topsoft
HaLLO Guido, ich verfolge mit Interesse Dein Ethernetboard. Wenn ich das richtig in Erinnerung habe, ist CAN doch ein 2 Draht System. Wäre es also nicht möglich, zwei der unbenutzen seriellen Ports als CAN Ausgang zu benutzen? Den Kabelbaum kann sich doch jeder notfalls selber bauen. Gruß Marcus
Hallo Jo, Markus das ist eine Superidee. Kostet keinen weiteren Platz und 2 Anschlüsse am SubD sind ja auch frei. Auf das einfachste kommt man meist nicht. Wäre schön wenn Guido das so machen könnte. Gruß Topsoft
Der SubD stecker ist genormt. ich bin dagegen can_high und low auf einen nicht genormten pin zu legen. Ich würde noch ne platz für stiftpins einbaun und notfals wenn man can und Rs braucht muss man mit en schleifer die zwei can leitungen durchtrennen und an den stiften abnehmen.
Hi warum nicht einfach Lötbrücken für wahlweise CAN und RS232? Beides zusätzlich auf Stiftleisten verfügbar und gut. Dann ist die SubD entweder CAN oder RS232 und das jeweils andere ist per Stiftleiste verfügbar. @Guido Ich würd auch so ne Platine nehmen wenn sie nicht zu teuer ist. BTW: Das umschalten des Analogschalters mittels Pin3 des isp-Steckers ist eher uneschickt da viele Programmierdongle (STK200, STK500, AVRisp, mein USBips) diesen Pin garnicht beschalten. Verwende doch einfach das Reset-Signal dazu. Matthias
Hallo, Also gegen RJ45 hätte ich nichts einzuwenden. Was spricht gegen die Einblendung des RTL in den oberen Adressbereich des Ram´s? Gruß Topsoft
Hi ich persönlich hätte ein Problem mit RJ45. Da kann man nicht mal schnell einen eigenen Stecker anbauen der dann auch noch nach was aussieht. Matthias
Hallo Guido, ich persönlich hätte nichts gegen eine RJ45 Buchse. Warum nimmst Du eigentlich zwei? Hast Du vielleicht mal über RJ11 nachgedacht? Die Buchse ist kleiner und du kannst ja die drei linken Leiter für RS232, die drei rechten für CAN benutzen. Ansonsten wäre noch die Option 3x2 Pinheader. Gruß Marcus
Hallo Guido, auch wenn ich bis jetzt nur mitlesen und nichts konstruktives beigetragen habe: Ich habe verbindliches interesse an 3 Platinen. Gruss Volker
Hi, hab grade erst den Thread gefunden. Ich wäre (noch unverbindlich) an einer Platine interessiert. Aber: ich bin kein berufsmäßiger Elektronikentwickler. Daher: - das ganze "optional" klingt gut, das meiste bräuchte ich nämlich nicht. Ich suche eigentlich nur Ethernet - AVR - freie Pins für Sensor. Freie Pins für Display, USB und MMC wäre nice to have. Wichtig wäre aber auf jeden Fall eine Doku, die ausreichend ist, um das nicht benötigte weglassen zu können. Ich denke da vor allem an die vorgeschlagenen Brücken um z.b. CAN/RS232 mal hier und mal da abzugreifen usw. - das Ethernet sollte schon eine Buchse haben, um ein normales Patchkabel anzuschließen, also RJ45 oder? (RJ11 kenn ich nicht). - Ebenso würde mir ein 9 pol. Sub-D Stecker für RS232 besser gefallen als eine RJ45 hierfür. RS232 müßte doch eigentlich jeder brauchen zwecks debugging, und ein RJ45/Sub-D Kabel hab zumindest ich nicht hier rumliegen. - Vielleicht bin ich der einzige, der das nicht weiss*g* Wo kriege ich denn dieses proMa Gehäuse? Und was kostet es? Btw: Hat jemand eine mehr oder weniger grobe Abschätzung was die größeren Bauteile kosten? R und C sind natürlich egal. Jochen
@jochen: die Frage mit dem Gehäuse würde mich auch interresieren*g* Bin auch für den 9 pol. Sub-D Stecker ....
Was die diverse Logik wie z.B. Adressdekodierung angeht, empfiehlt sich ein CPLD, z.B. ein 36er oder 72er von XILINX. Die lassen sich (als TQFP44) prima löten und lösen das Platzproblem. Ausserdem ist so noch ein bisschen Raum offen für diverse Konfigurationen, falls jemand mehr RAM braucht, etc.
Hi So wie ich das alles bisher kapiert habe, wird das die Eierlegende Wollmilsau die ich mir schon immer gewünscht habe! USB, RS232, Ethernet, CAN - was will man mehr? Ich werd mir wenns nicht zu viel kosten wird so ein Teil auch anschaffen, aber mir ist da noch etwas unklar mit den ICs. 74hct30D, HY628100B2, 74AC573D, AT45DB041B, AT45DB081 - was machen diese ganzen ICs? Ich kenn mich schon ein wenig mit den AVRs aus aber diese Bauteile sind mir noch unbekannt. Die Datenblätter laden schon, aber wie ich mich kenne werd ich daraus wohl auch nicht so schnell schlauer werden. :\ mfg
Hallo, an so einem Board wäre ich auch interessiert. Aber eher wie es Jochen gesagt hat. Einfach ein paar Sensoren(z.B TC77 am I2C) abfragen und per Browser abfragen. Später vielleicht noch als Datenlogger. Das wäre ideal. @Jochen proMa gibt es z.B. bei Reichelt(glaube Guido meint EFG 1A(LxBxH 165x114x31). Oder hier http://www.proma-technologie.com/deutsch/rundum_l/index.html Malte
@Guido Fischer: "Wer hat den FT254BM schon mal verbaut und kann mir sagen, ob der überhaupt "Bus" tauglich ist und mir die datenleitungen zu den andern IS in Ruhe lässt?" Der 245 ist bustauglich. Es gibt kein CS, aber wenn WR# und RW# beide auf Hi sind, ist der Port Hochohmig. Darüber hinaus gibt es zwei Handshake Leitungen RXF# und TXE#, einer zeigt an, dass Daten gelesen werden können, der andere, das man welche senden darf. In JEDEM FALL das Handshaking verwenden!!! Gruß, Bernd
@Guido Fischer: FT245BM und FT254BM. Sprechen wir vom gleichen chip? Zahlendreher? Ich FTDI hat keinen FT254BM, oder? Ich habe nur den FT245BM getestet.
@Guido Fischer: "Wenn er sich so verhält wie der 245 ist es ok" ????? Es ist doch der 245'er!!!???? "Ich mein den kleinen Käfer hier: http://www.ftdichip.com/Products/FT245BM.htm"; Und "die Frage zu der Bustauglichkeit habe ich selber schon weiter oben gestellt und keine Antwort erhalten." Das war keine Frage, sondern die Antwort:-) Gruß, Bernd
Danke für die erhellenden Gehäuse Antworten:o) Hab ich das auch richtig verstanden, dass die Hardware (Pinbelegung usw.) insoweit mit dem Webserver Projekt von ulrichradig.de identisch ist, dass dessen Webserver SW auch hier läuft? Gruß, Jochen
Hallo Guildo,
zu dem Thema CAN / RS232:
zuerstmal finde ich Deine Lösung prima, beides an zu bieten.
Vielleicht schaust Du Dir mal diese Pinheader an:
Reichelt - SL 1X10G SMD2,00
Damit könntest Du dann die Sub-D Buchse je nach gewünschter Beschaltung
jumpern.
o --- CAN-LOW
TX ----o
o --- RS-TX
o --- CAN-HIGH
RX ----o
o --- RS-RX
Du brauchst also nur ein Board und hast automatisch die Abnahme vir PIN
geschafft.
Gruß Marcus
Hi Nochmal kurz zum FT245BM. Bin jetzt mal kurz etwas verwirrt. @bernd Du schreibst, dass WR und RD# high sein müssen, damit die Datenleitungen hochohmig sind. Sollte es nicht so sein, dass nur RD# high und WR low sein muss, da ja WR high-aktiv ist?? Nicht, dass hier blödsinn im Layout rauskommt (vielleicht fehlt dann ja ein Inverter)! @Adressdekoder Ich hab mich in letzter Zeit ein bisschen mit den XILINX CPLDs 9536XL und 9572XL beschäftigt. Zur Programmierung wird ein JTAG Kabel benötigt, das mit 4 Pins + GND mit dem Baustein verbunden wird. Das Kabel ist im Prinzip nichts besonderes... 1 oder 2 Treiberbausteine und eine handvoll Widerstände! Wie gesagt, müssten 4 Pins + Masse (vielleicht auch noch Versorgungsspg für das Kabel) auf eine Steckerleiste geführt werden. Das Progamm könnte einfach mal jemand schreiben und es dann auf ne Homepage online stellen! Dann braucht es im Prinzip nur jeder auf den CPLD laden. Die Programmierung ist im Prinzip sehr einfach. Das lässt sicher sicher mal auf die schnelle machen! Ich kenn nur die XL-Serie der CPLDs von Xilinx. Die sind relativ günstig (36XL kostet bei Reichelt auf Anfrage etwa 1,90 Euro; bei eBay werden außerdem auch immer 10 Stück im SMD Gehäuse für 12 Euro oder so ähnlich angeboten). Vorteil bei der Verwendung eines CPLDs ist, dass man ihn auch so verwenden könnte, um z.B. 512KB SRAM zu verwenden (ähnlich wie bei Ethernut 2.x). Die Frage ist eben, ob jemand wirklich soviel mal braucht!?!? Außerdem ist es Arbeit, was das Layout betrifft! mfg Andreas
Hallo, wenn der CPLD auf Layout kommt und die Adressdekodierung übernimmt ist dann nicht noch so viel Platz in dem Ding das er die Arbeit des 74**573 mit übernimmt? Gruß Topsoft
@Andeas: kennst du dich mit den dingern aus? habe mir gestern das ispLever von Lattice geladen, habe auch "Das isp-Buch" von Elektor. Aber begreifen tu ich das nicht was die von mir wollen, bin ich zu blöd für. Gibt es da gute Seiten am besten in deutsch? Das Thema interesiert mich doch schon sehr. Gruß Topsoft
Die Lattice Dinger kenn ich leider nicht. Ich hab mir mal ein Board für die Xilinx XC9536XL und XC9572XL gebaut (falls es dich interessiert auf www.mikrocontroller.at.tt steht mehr übers Board). Ich kenn mich ein bisschen mit der Programmiersprache Verilog aus und schreib meine Programme immer darin. Ist vom Syntax her relativ ähnlich zu der von C. Es gibt eben ein paar sprachspezifische Ding (also wie man auf Taktflanken reagiert usw.). Xilinx hat auch eine kostenlose Software auf der Homepage. Damit kann man rumprobieren und "Hardware-Programme" simulieren. Vorallem gibts massig Programmbeispiele, von denen man einiges Lernen kann. Auf der Homepage www.xess.com gibts auch einige Tutorials. Viel mehr kenn ich leider auch nicht. Ich hab Verilog in der Uni mal ein Semester lang gelernt (war aber trotzdem nur oberflächlich). mfg Andreas
Hallo Andreas, sorry wenns jetzt ziemlich ot ist, aber würdest Du mir mal kurz Deine Erfahrung mit dem Nordic nf905 im real Life schildern und was der wo kostet. Ist die Leistung regulierbar? Gruß Marcus
Da ich leider einige Probleme mit meinem Layout für den nrf905 habe, hab ich die Module (noch) nicht testen können. Außerdem weiß ich nicht, ob die nrf905 Chips auch wirklich Kontakt mit den Leiterbahnen (der Chip ist in so nem komischen halb BGA Gehäuse) haben. Das dauert also bis ich da irgendwann mal was vorlegen kann. mfg Andreas
@Andreas Auer: "Du schreibst, dass WR und RD# high sein müssen" Das mit dem WR und RW war auswendig geschrieben. Ich wollte damit nur sagen, dass diese beiden Leitungen für den Ansteuerung sind. **** aus dem Datenblatt Seite 8 ************************** "16 RD# IN Enables Current FIFO Data Byte on D0..D7 when low. Fetches the next FIFO Data Byte ( if available ) from the Receive FIFO Buffer when RD# goes from low to high. ( *** Note 1 )" **** aus dem Datenblatt Seite 8 **** "15 WR IN Writes the Data Byte on the D0..D7 into the Transmit FIFO Buffer when WR goes from high to low. ( *** Note 1 )" ********************************************************* Lesen: Also, die Daten können gelesen werden, wenn RD Low ist (Seite 10 in der Doku). Ist RD High, so ist der Port hochohmig. Schreiben: Wenn man nach Seite 10 in der FTDI Doku geht, muss WR im Ruhezustand Low sein. Geht dann auf High und übernommen/geschrieben wird bei negativer Flanke. Gruß, Bernd
@Bernd Genau das meinte ich ja... damit muss WR low sein, wenn es inaktiv sein soll, oder?! Wenn du dir z.B. das Datenblatt des Atmel noch zur Hand nimmst, dann siehst du dort auch, dass das RAM zum Beispiel die Daten bei der steigenden Flanke übernimmt. D.h. vom Atmel aus gesehen, dass WR erst low geht und dann bei der steigenden Flanke die Daten übernommen werden. Genau das selbe nur mit den umgekehrten Pegeln passiert beim FT245BM. Damit muss doch WR auf low und RD auf high sein, wenn es inaktiv sein soll! (meine Ansicht) mfg Andreas
@Andreas Auer: "Damit muss doch WR auf low und RD auf high sein, wenn es inaktiv sein soll!" - JA Gruß, Bernd
CPLD fänd ich auch cool :-) Aber nur wenn die ungenutzten I/O´s auf Stiftleisten zur Verfügung stehen. Aber ob dass noch auf die kleine Platine passt ...
@Guido: Deine Angaben glaub ich passen schon (Pins usw.) Am CPLD sind aber einige IOs auch für spezielle Zwecke ausgelegt. Müsste man mal genauer schauen, ob trotzdem noch genügend zur Verfügung stehen. Wegen dem machen... das "Programm" für den CPLD kann ich im Prinzip schon schreiben (ich hab nur jetzt im Jänner einige Prüfungen und deshalb wahrscheinlich auch nicht viel Zeit). Falls sich jemand anderes findet, gern! Es gibt da aber ein kleines Problem. Ich hab zwar JTAG Kabel bzw. ein Xilinx Board zur Programmierung von CPLDs, aber wie SMD IC's ohne Einlöten programmieren. Und Sockeln dafür sind ja schweineteuer. Falls da jemand Erfahrung hat, bzw. ne gute Idee hat, immer her damit!! mfg Andreas
Hi die zur programmierung nötigen Pins auf eine Stiftleiste führen? Matthias
Hallo, nehm doch das XC9572-7PC84C, hat 69 Pins und damit ist sichergestellt,das Du genug ausgänge hast. Gruß Marcus
Hi PLCC ist riesig und was viel schlimmer ist: Es stirbt aus. Die CPLD's sind ganauso IS programmierbar wie die AVR's auch. Wozu also einen sockelfähigen Chip? Mein Vorschlag: XC95{36,72}{XL}. Das Adresslatch würde ich nicht über den CPLD laufen lassen sondern die freien Pins eher an einen zusätzlichen Stecker führen. Würde das Board flexibler machen. Aber so langsam wirds dann doch die eierlegende Wollmilchsau die nie fertig wird. Matthias
>>Das Adresslatch würde ich nicht über den CPLD laufen lassen sondern >> die freien Pins eher an einen zusätzlichen Stecker führen. Würde >> das Board flexibler machen. Das macht aber weniger Sinn da der CPLD zur Addressdekodierung ja auch einige Addressleitungen benötigt. Anbei mal mein Memory Mapped Bank Controller zur Ansteuerung von 512Kb SRAM und zwei beliebigen Memory Mapped Geräten. Das ganze passt in einen XC9536XL benötigt alle 34 verfügbaren Pins und verbraucht 27 Makrozellen von den 36 verfügbaren. Da der MMB aber intern selber zwei Register speichert und demzufolge auch die komplette Addresslogic des AVR's benötigt kann für euer Projekt einiges eingespart werden. Gruß hagen
Hi aus dem Adresslatch kommen aber die unteren Adressen. Für die Dekodierung werden üblicherweise die oberen Adressen hergenommen. Matthias
@Matthias, ja das stimmt natürlich. Ich bezog mich da eher darauf das beim CPLD noch viele Pins frei blieben. Addressdekoder benötigt A8-A15 = 8 Eingänge, Chipselects für SRAM, USB, Realtek = 3 Ausgänge. Das NAND und Inverter sind dann weg. Das sind 12 Pins am CPLD von 34 verfügbaren, bleiben 23. Der MUX könnte auch über den CPLD laufen, das wären dann 10 Pins, bleiben 34 - 12 - 10 = 12. Man bräuchte aber 8+8+1=17 für den Latch. Stellt sich nun die Frage wie man sich entscheidet. Entweder Addressdekodierung + Latch macht 34 - 11 - 17 = 6 freie Pins am CPLD für zusätzliche Aufgaben. Oder Addressdekoder + MUX macht 34 - 11 - 10 = 13 freie Pins für zusätzliche Aufgaben. Ich vermute das von den freien Pins noch die Ansteuerlogik für den FT254BM gemacht werden kann, sprich WR\,RD\ == 4 Pins. Eines steht aber fest, ohne den CPLD gäbe es keine Addressdekodierung. (ich meine um zu Ulrichs Lösung kompatibel zu bleiben). Die Addressdekodierung kann wahlweise mit oder ohne ALE gemacht werden. Da die Addressleitungen A8-A15 im Gegensatz zu AD0-AD7 laut Datenblatt immer stabil sind. Denoch bevorzuge ich die Addressdekodierung synchron zum ALE zu machen. Falls der Latch im CPLD ist hat man ja ALE eh zur Verfügung. Ach und nochwas, die XC9500 gibts als 5V und 3.3V Versionen. Die 5V Versionen sind meistens um mehrfaches teuerer als die XL == 3.3V Versionen. Auf alle Fälle sind sie besser verfügbar als die MAX7000 Serie. @Guido, gib mir doch mal die genauen Addressen zur Addressdekodierung wie du sie dir vorgestellt hast. Gruß Hagen
Morgen, einen Teil der unteren 8 Bit braucht mann schon, ansonsten würde sich jedes cs über mindestens 255 Adressen erstrecken üblich sind da ja meistens weniger ausgennommen mal den rtl und z.b ein sja1000. Topsoft
Naja, aber 3 * 256 Bytes weniger SRAM von fast 64Kb ? Ich würde, falls Pins übrig bleiben, sowas dann nachträglich verfeinern. Allerdings benötigt man dann ALE auf alle Fälle, da AD0-AD7 nicht stabil die unteren Addressbits halten. Wobei wir somit zu meinen Hinweis kommen das es eventuell sinnvoller wäre den Latch in den CPLD zu pressen, da hat man dann für eine genaue Addressdekodierung auch AD0-AD7 und ALE inklusive am CPLD. Gruß Hagen
Hi dann hat man halt Blöcke von 256 Byte. Ist doch egal. Aufs Byte genau muß man ja nun wirklich nicht ausdekodieren. Ich würde z.B. die unteren 32k des SRAM dauerhaft (ab 0x8000) einblenden und alles anderen in 16k-Blöcken (ab 0x4000 bis 0x7FFF) per Config-Byte im CPLD umschaltbar machen. Alles andere (RTL, FTDI, CPLD-Config Byte(s)) wird dann ab 0x2000 in 256 Byte großen Fenstern eingeblendet. So spart man sich das TTL-Grab für die Adressdekodierung und es bleiben noch ein paar Pins und Makro-Zellen für extra Hardware im CPLD frei. Ich denke da z.B. an extra PWM, schnelle CRC-Berechnung oder sowas. Matthias
>Ich würde z.B. die unteren 32k des SRAM dauerhaft (ab 0x8000) > einblenden und alles anderen in 16k-Blöcken (ab 0x4000 bis 0x7FFF) > per Config-Byte im CPLD umschaltbar machen. Alles andere (RTL, FTDI, > CPLD-Config Byte(s)) wird dann ab 0x2000 in 256 Byte großen Fenstern > eingeblendet. So ähnlich geht der obige MMB Source vor. Wenn ich Guido aber richtig verstanden habe so möchte er das Memory Mapping unterhalb 0xFFFF haben. >So spart man sich das TTL-Grab für die Adressdekodierung und es > bleiben noch ein paar Pins und Makro-Zellen für extra Hardware im > CPLD frei. Ich denke da z.B. an extra PWM, schnelle CRC-Berechnung > oder sowas. Hm :) das dürfte dann aber mit einem kleinen und preiswerten CPLD nicht mehr drinn sein. Was ich noch nicht ganz verstanden habe ist die Logik beim FTDI Chip. Wenn mir einer diese nochmal genauer erklären könnte + gewünschte Addressbereiche so würde ich mich ans Xilinx WEBPack machen und das VHDL samt Timing/Functionale Analyse umsetzen. So schwer ist das nicht. Bliebe für Guido das leidige Pinning des CPLD übrig (ist im WEBPack ein grafisches GUI). Dieses sollte man auf die Bedürfnisse des Routings im Layout anpassen. Gruß Hagen
*liest interessiert mit, versteht aber immer weniger:o)* Wollte nur mal anmerken, dass ein NAND vielleicht jemand rumliegen hat, von CPLD hab ich keine Ahnung, und da auch noch einsteigen, Kabel/Programmer bauen usw ist zumindest für mich ein bischen oversized. Ich bin zwar sicher nicht der Massstab hier, da noch Atmel Anfänger, aber vielleicht geht's ja noch mehreren so. Mir jedenfalls nutzen freie Pins/Zellen in einem Ding von dem ich keine Ahnung habe nix:o) Da wär mir ein bischen TTL, das ich teilw. schon rumliegen habe und bei dem ich verstehe was ich mache schon lieber. Will euch aber nicht reinreden, dafür bin ich ein zu kleines Licht:o) Ich schau mir einfach mal an, was nachher rauskommt, und wenn ich's nicht mehr kapier fährt der Zug halt ohne mich. Jochen
Geht ja hier Schlag auf Schlag:o) >Wer danach mit einer größeren Version und >somit mit SRAM weitermachen >möchte, kann auch ein CPLD bestücken, oder? Das Bestücken ist nicht das Problem. Eher die Beschaffung. Stellt das einer programmiert zur Verfügung, und was kostet das dann ungefähr? Jochen
Hi einen Parportadapter wird wohl jeder selber basteln können. avrdude unterstützt den Xilinx-Dongle übrigens auch zur AVR-Programmierung. Matthias
Hallo Leute, mal ne vielleicht blöde Anmerkung, aber wenn ich den Atmel ISP programmieren kann, kann der Mega128 nicht vielleicht anschließend vi Can USB Seriell / MMC o.ä. das CLPD programmieren? Sind doch IMHO auch nur ein paar Pine. Gruß Marcus PS: So gut kenne ich mich mit der Programmierlogik der CLPDs nicht aus, denn ich hab noch nie ne Software zu programmieren von den Dingern gebaut.
@Guido: > Blieben noch 224 Adressen fei für USB, CAN und ggf. - so hab ich > mir gestern noch überlegt - auch die MMC Card nebst Flash und die > gewünschten CSs für den externen SPI. Die hängen zwar nicht am > Datenbus aber die verschwendeten Portpins würden damit wieder frei, > ist aber nur so ne Idee. Das mit dem CAN verstehe ich nicht, unterstützt der Memory Mapping ? Die MMC Karte + SPI würde ich nicht über den CPLD laufen lassen. Man müsste dann immer den CPLD korrekt vorprogrammiert haben um auf die MMC zugreifen zu können. Aber, mal als Vorschlag, was wäre wenn man den AVR + CPLD von MMC flashen will ? Dann beist sich aber die Katze in den Schwanz, denn die FAT Library benötigt ca. 1Kb an Buffern, ohne CPLD kein externes SRAM, ohne externes SRAM keine FAT Buffer, ohne diese keine SD/MMC FAT, ohne diese kein flashen von MMC möglich. Deshalb würde ich die MMC/SD/SPI nicht abhängig vom CPLD machen. Zur MMC/SD Karte noch einige Bemerkungen: Ich habe auch mit den Spannungsteilern rumexperimentiert und meine Erfahrungen sind eher schlecht als gut. Besonders wenn man mit SnaDisk Karten und hohem Takt arbeiten will. Desweiteren (ich habe deinen Schaltplan jetzt nicht genauer daraufhin unersucht) sollte Vcc der MMC Karte per P-Channel MOSFET über den AVR zuschaltbar sein. Bei meiner MMC/SD Library musste ich nämlich feststellen das es einige SD Karten gibt die nur mit einem harten RESET über das Abschalten von Vcc zurückgesetzt werden konnten. Auch wäre es sinnvoll wenn als SD Karten Slot einer mit Schalter genommen wird. Somit kann man das Einfügen der Karte zur Laufzeit detektieren. Bei der MMC/SD Software tritt ein generelles Problem mit der FAT Software auf. Normalerweise ist es effizient über zwei 512 Bytes Buffer jeweils die FAT und den Dateibuffer zu realisieren. Wird nun in eine Datei geschrieben so ändert man vorerst die zugehörigen FAT Informationen im SRAM-FAT-Buffer. Dies birgt aber ein Risiko wenn man die SD/MMC Karte entfernt bzw. ein RESET durchführt bevor man diesen FAT Buffer zurückgeschrieben hat. Arbeitet man aber ohne diesen Schreibbuffer so werden sehr viele unnötige Schreiboperation inimmer die gleichen FAT Sektoren auf der Karte nötig. Das kann sehr leicht und schnell dazu führen das man diese Sektoren auf der Karte zerstört. Nun, meine derzeitige Lösung mit den SD/MMC Karten sieht so aus: - Vcc über P Channel MOSFET vom AVR ausschaltbar - Kartenslot mit Schalter um das Einfügen einer Karte durch AVR zu erkennen - Extra Taster zur Signalisierung das die SD Karte entfernt werden soll - Extra LED um Status anzuzeigen, dabei wird über diese LED der Zugriff auf die SD Karte angezeigt (Schreib/Lese blinken) und falls der FAT Buffer noch nicht zurückgeschrieben wurde. Vor einem Ausschalten des Gerätes oder RESETs muß also falls die LED leuchtet der Auswurf-Taster der SD Karte gedrückt werden. Nicht schön ich weis, aber nur so konnte ich das Problem lösen. About Speicheraufteilung: Ich stimme eigentlich den Vorstellungen vom Matthias zu und würde auch von der herkömmlichen Aufteilung im oberen Addressbereich abweichen. Der ATmega128 hat im Addressbereich von 0x0000 bis 0x10FF seinen internen Addressbreich. Ab 0x1100 würde ich also die Memory Mapped Devices legen. Das hätte nur einen Schwachpunkt falls eben einer seinen MCU-Stack in das externe SRAM auslagern möchte (warum auch immer er dies möchte). Bei meinem ATmega162 Projekt ging ich grundsätzlich davon aus das der Stack immer im internen SRAM liegen wird. Das hat aber dann den Vorteil das man oberhalb der Memory Mapped Devices eben linear den kompletten externen SRAM einblenden kann. Nun zum SRAM: reichen wirklich die 64Kb aus ? Heutzutage ist es scon fast schwierig 32kb-64Kb SRAM's preiswert zubekommen. 128Kb sind meistens preiswerterund verfügbarer. Der Vorschlag vom Matthias zielt primär darauf ab eben solche größeren SRAM's am AVR zu betrieben und dabei sogar noch zusätzliche Vorteile zu bekommen.Denn über das Variable Banking kann man nun viel schneller bis zu 16Kb große Speicherblöcke im SRAM schnell kopieren. Desweiteren bekommt man Zugriff auf das Shaddow-SRAM im externen SRAM. Das wäre der Bereich von Addresse 0x0000-0x1FFF der ja vom internen SRAM + Memory Mapped Devices überdeckt wird. Über die variablen Bankregister kann man nämlich diesen Bereich intern auf die Addressen oberhalb 0x8000 einblenden. Auch aus diesem Grunde funktioniert mein obiger MMB exakt so. Desweiteren stimme ich Matthias auch mit den zusätzlichen Funktionen im CPLD zu. Wenn ich alles richtig gerechnet habe dann bleiben ca. 4 Pins am CPLD ungenutzt. An Makrozellen schätze ich mal das 36 für die kompllete Logik ausreichen werden. Man könnte also die kleinsten XC9536XL's im TQPF44 nutzen falls man Kosten spare will.Oder aber man nimmt den Pinkompatiblen XC9572XL der nur unwesentlich "teuerer" ist und hätte dann 36 Makrozellen zusätzlich frei um diese 4 Pins mit komplizierterer Logik zu füllen. Eine Addressdekodierung auf Bytegrenze exakt finde ich ebenfalls übertrieben, das würde zwar keine Pins zusätzlich kosten aber auf alle Fälle Makrozellen verbrauchen. Grundsätzlich würde das aber mit 36 Makrozellen möglich sein. Nur, wegen 3*256 Bytes sich streitenzu wollen ?? Wichtiger wäre es das man über Header an die unteren gelatchten Addressleitungen, die 8 Datenleitungen + Chipselects herankommt. Denn über diese lassen sich dann weitere externe Geräte leicht anschließen. Ich denke das an IDEATA. Die Addressdekodierung im finalen VHDL im Addressbereich zu verschieben ist weiter kein Problem. Das mit dem CAN musst du nochmal genauer erklären. Gruß Hagen
Hi Zum SRAM: Warum überhaupt ein 32k SRAM vorsehen? 32k sind bei Reichelt teurer als 128k. Ich würde eher 128k/512k als Option vorsehen. Das führt zu keinen Problemen mit dem DRC und ist auch nicht teurer wenn man die 128k Option wählt. Im Anhang mal mein Vorschlag für die Buslogikgeschichte. Ich hab nur mal das entscheidende gezeichnet. Irgendwie sollte man noch einen Takt an den CPLD bringen wenn dieser keinen internen Generator hat. Matthias
@Guido: Ah, ok jetzt verstehe ichs. Statt Pins am AVR für diese Chipselects -> CAN + MMC, willst du das der CPLD sozuagen als Porterweiterung fungiert. Gut das schöne am CPLD ist ja das man solche "Hardware" per Software macht. Bei den XL Typen handeltes sich um 3.3V Typen, das ist dir schon klar oder ? @Mattias: Warum Takt an CPLD ? Ich habe die Erfahrung gemacht das taktbasierte Systeme immer anfälliger und komplizierter sind als ganz normale. Zumindestens hat mein taktbasiertes CPLD Projekt bis heute nicht 100%'tig exakt funktioniert und ich weis nicht warum. Schaudir mal obigen MMB VHDL Code an, der arbeitet auch ohne Takt und kann im Grunde alles das was wir suchen. Allerdings, bei 512Kb SRAM wirds mit den Pins eng. Obiger MMBC unterstützt auch 512Kb SRAM + Latch + 3 Chip Selects und schwups sind die 34 Pins weg. Bei einem 256Kb SRAM benötigen wir AD0-AD7, WR\, RD\, ALE, A8-A15 als Input. AL0-AL7, AH15-AH17, CS0-CS3 als Outputs, macht auch 34 Pins. In diesem Falle stehen 4 statt 3 externe memory mapped devices zur Verfügung. Würde man das Bank_Register NUR writeonly machen so kann man auf RD\ verzichten. Verzichtet man auf den Latch im CPLD so bringt das nicht viel da wir trotzdem alle Leitungen bis auf AL0-AL7 benötigen. Besonders AD0-AD7,ALE,WR\,RD\ sind nötig um die internen Bankregister programmieren zu können. Wir hätten also nur 8 Pins eingespart würden dafür den externen Latch aber benötigen. Nimmt man einen 64Kb SRAM ohne Banking aber mit Latch so braucht man AD0-AD7, ALE, A8-A15, AL0-Al7, CS0-CS3 also 29 Pins, bleiben 5 Pins für den Rest. Es sieht wohl so aus als reicht ein TQPF44 nicht aus. Der XC9572XL TQ100 kostet bei Reichelt 4.50 Euro und hätte 72 verfügbare Pins. Vielleicht der ? Ist schon blöde das von einem TQFP44 nur 34 Pins zur Verfügung stehen. Gruß hagen
Hi Takt am CPLD war gedacht für zusätzliche Hardware im CPLD. Die braucht irgendwoher einen Takt. Evtl. kann man den einfach von XTAL-Out am AVR klauen. Die Buslogik würde ich auch asynchron machen. Natürlich brauchen wir noch AD0..7 am CPLD für das Config-Register. Mist. Im Anhang neue Blockstruktur. Ich bin gegen ein TQFP100. Das ist wieder so ein riesen Brummer. Dann lieber Adresslatch und QFP44. Matthias
Hi man müßte mal die In-High-Pegel der beteiligten Chips am Bus messen ob die mit 3,3V High klarkommen. Wenn ja wären die XL-Typen ne Option da die billiger sind. Die Eingänge der Chips sind 5V tolerant. Man müßte mal die Pinbelegung der 3,3V und 5V Typen checken. Evtl. kann man dann die Versorgung für den CPLD wählbar machen. Matthias
Ok, kein VQ100 aber was ist mit VQPF64 ? Die Dimensionen sind so groß wie TQPF44 aber statt 0.80 Raster eben 0.50 Raster. Bei Xilinx kostet der XC9572XL in VQPF64 $2.25 das Stück. Dieser hat dann 52 verfügbare Pins, 18 mehr. Die 5V Teile sind bei weitem teuerer. Ansonsten stimme ich Matthias zu, es geht dann nur mit externem Latch. Oder man beschränkt sich auf das Wesentliche ohne den CPLD für zukünftige Erweiterungen überzudimensionieren. Wie gesagt bei maximal 128Kb SRAM und Latch im CPLD braucht man AD0-AD7, ALE, WR\, RD\, A8-A15, CS0-CS3, AL0-AL7, AH15-AH16 + ~WR\ für den FTDI, macht 34 Pins. Der SRAM wird in 32Kb Bänke geteilt und deshalb benötigt man nur noch A15 und A16. Intern kann man also die 4 SRAM Bänke jeweils in die unteren oder oberen 32Kb mappen. ChipSelects stehen 4 zur Verfügung, für SRAM, FTDI, USB und noch ein zusätzlicher. Ausbaufähig wäre dies dann nicht mehr, aber was soll's man kann ja einen weiteren CPLD für die Spezialaufgaben an den Bus dranhängen. Diese Lösung würde den Latch, NAND und INV einsparen, hätte 4 memory mapped Devices, und sogar noch für den 128Kb SRAM eine Bank Logik. Die Addressausgänge A15 und A16 werden durch die 2 internen 2Bit Bankregister gesteuert abhängig von der Addresse auf dem AVR Addressbus. Darum muß man sich also nicht im AVR kümmern. Bei Zugriff auf die anderen Memory Mapped Devices kann man das 2 Bit Bank_register_0 zusätzlich so befüllen das an A15,A16 für diese Geräte zwei Steuerleitungen zur Verfügung stehen. Der XC9536 VQ44 5Volt kostet bei Reichelt 5.25 Euro statt wie der XL Typ nur 1.80 Euro. Tja, ich weis auch nicht. Denn wird der Latch extern umgesetzt dann würde der CPLD ja nur noch das NAND und die 4 INV ersetzen. Dazu wäre der nötige Mehraufwand eventuell nicht gerechtfertigt. Andererseits stünden dann 8 Pins mehr zur Verfügung da AL0-AL7, die gelatchten Addressen, wegfallen. Wie's Matthias eben sagte. Gruß hagen
@Matthias: > man müßte mal die In-High-Pegel der beteiligten Chips am Bus messen > ob die mit 3,3V High klarkommen. Wenn ja wären die XL-Typen ne > Option da die billiger sind. Nicht nur das, ich glaube das sogar die 3.3V SRAM's billiger als die 5V Typen sind. Müsste ich aber nochmal abchecken. @Guido: sagt mir wie ich's machen soll. Ich baue dann das VHDL und Matthias kann es ja eventuell querchecken. Gruß Hagen
Hi Kurz noch was anderes... es war ja mal die Rede von den RJ45 Buchsen mit integriertem Übertrager. Wo gibts die denn?? Weiß da vielleicht jemand Bezugsquellen? mfg Andreas
@Guido, beim WEBPack und VHDL kann ich dir helfen. Ich würde dir per EMail das komplette Projekt mailen mit vielen Bemerkungen. Mit ein bischen Anleitung habe ich es selber innerhalb von Tagen gelernt. Ich maile dir auch noch par PDF's mit deutschen Kurzanleitungen. Aber mit dem Schematik-Editor würde ich erst garnicht anfangen, VHDL ist einfacher. 3.3V <> 5V: der AVR und Realtek laufen weiterhin mit 5V. Der CPLD mit 3.3V der aber 5V tolerante Inputs hat. Wichtig ist halt nur ob der CPLD H-Pegel für die Ansteuerung der 5V Chips ausreicht. Allerdings kann ich eben da auch nicht mit praktischen Erfahrungen helfen. Ich habe hier irgendwo im Forum gelesen das das mit den Xilinx CPLDs zu Problemen führen kann. (war aber widersprüchlich). Falls VQFP64 kein Problem wäre dann müsste man nur noch in Erfahrung bringen wo's den XC9572XL in VQFP64 zu kaufen gibt. Das Memory Banking ist im Grund einfach. In WinAVR zb. definiert man sich einfach eigene Sections für jede Bank und jede Variable kann man nun in diese Sections legen. Die restliche Aufteilung in den Speicher macht dann der Compiler. Man versucht natürlich mit möglichst wenige Bankswitch's auszukommen. Die Steuerung des Bankswitchselber ist ein einfacher Schreibzugriff in den Speicherbereich des CPLD. Das könnte in WinAVR so aussehen: #define CPLD_MM_ __attribute_ ((section (".cpldmm"))) #define FTDI_MM_ __attribute_ ((section (".ftdimm"))) #define USB_MM_ __attribute_ ((section (".usbmm"))) #define BANK0_ __attribute_ ((section (".bank0"))) #define BANK1_ __attribute_ ((section (".bank1"))) im Makefile müssen nun die Addressen zu den obigen Sections stehen: LDFLAGS += -Wl,--section-start=.cpldmm=0x801100 LDFLAGS += -Wl,--section-start=.ftdimm=0x801200 LDFLAGS += -Wl,--section-start=.usbmm=0x801300 LDFLAGS += -Wl,--section-start=.bank0=0x802000 LDFLAGS += -Wl,--section-start=.bank1=0x808000 Der Addressbereich des CPLD's startet also physikalisch an Addresse 0x1100. Im Source kann nun eine Memory-gemappte Variable zu diesem Addressbeeich definiert werden. uint8_t CPLD[256] CPLD_MM; Beim Zugriff auf diese 256 Char Array wird nun physikalisch in die Addressen 0x1100 bis 0x11FF gemappt. Will man nun das Bankregister schreiben so macht man das so: CPLD[0] = 0; Oder der FTDI: uint8_t FTDI[256] FTDI_MM; mit FTDI[0] = 0x55; schreibt man also ins erste Register des FTDI den Wert 0x55. Gruß Hagen
@Andreas: Die RJ-45 Buchsen mit Übertrager gibt es zum Beispiel bei Segor, Bestellnummer HFJ11-2450E-L12 Kosten 7 Euro pro Stück und haben außerdem noch zwei LEDs integriert. Gruß Torsten
Hallo Guido, ich bin prinzipiell an einer Platine interessiert. Allerdings möchte ich erst die Ergebnisse sehen, also eine laufende EileVollmiSau. Ich persönlich würde das CLPD nehmen, da Du sicher sein kannst, das nicht die Ansteuerung des CLPD's sondern auch des RTL, CAn und USB für 95% der Leute schon eine MII bedeutet. Ich selber hab ziemlich respekt von dem RTl, werde ihn aber warsch. selbst in nicht zu ferner Zukunft einsetzen. In wie weit Dein System Leute abschreckt hängt in erster Linie davon ab, ob Du eine gute APi hast, die ich relativ leicht ansteuern kann. Z.B für den RTL: void set_IP(); void send_Byte(); char Recv_Byte)(; usw. Alles andere geht zu sehr ins Detail und dann will ich das Ding auch selber entwickeln, anstatt auf eine vorgefertigte Lösung zurück zu greifen. Ich würds drauf lassen! GRuß MArcus
Nabend Also ich würde den CPLD drauf lassen. Wenn man dann mit den Ramabschnitten nicht klar kommt lässt man es halt denn der erst Bereich ist ja immer beim Start aktiv. Aber so wie ich das verstanden habe schreibt man auf eine bestimmte Speicherstelle als wäre es externes Ram. Dort wird die aktuell einzublendende Bank angegeben. Danach ein weiterer Zugriff aufs externe Ram und fertig. In Assembler etwa so denke ich: (ich mag kein C) ldi r16, zuAktivierendeBank sts Bankingregister, r16 ldi r16, Datenbyte sts startRam, r16 Oder liege ich da völlig daneben? Gruß Topsoft
Wenn man mit RAM-Banking und solchen Späßen anfangen muss, lohnt es sich dann nicht vielleicht gleich einen Controller zu nehmen der mit einem größeren Speicherbereich umgehen kann? Die zwei Bereiche für ROM und RAM sind beim AVR schon lästig genug.
@TopSoft: du liegst richtig. Aber statt diese Speicherstelle umständlich über Addresszeiger anzusprechen definiert man sie wie oben einfach mit uint8_t CPLD CPLD_MM; Damit liegt sie zb. immer an Addresse 0x1100 in Section CPLD_MM, also im memory mapped Bereich des CPLD's, was über das Makefile konfigurierbar ist. Nun kann man die externen SRAM Bänke auswählen indem man zB. CPLD = 0x10; setzt. In diesem Moment würde der externe Speicher ab Addresse 0x0000 bis 0x7FFF im internen an Addresse 0x0000 bis 0x7FFF liegen. Dann noch die zweite Bank vom externen Speicher 0x8000 bis 0xFFFF im internen an Addresse 0x8000 bis 0xFFFF. Man hat also die ersten 64Kb linear gemappt. Bei CPLD = 0x23; würde an Addresse 0x0000-0x7FFF der externe SRAM ab 0x18000-0x1FFFF, und an Addresse 0x8000-0xFFFF eben 0x10000-0x17FFF. Man hat also die zweiten 64Kb gemappt aber diesmal umgedreht. Bei CPLD = 0x00; würde an Addresse 0x0000-0x7FFF der externe SRAM ab 0x0000-0x7FFF liegen, und an Addresse 0x8000-0x7FFF ebenfalls 0x0000-0x7FFF vom externen eingeblendet. Also doppelt und man hat nun über Addresse 0x8000 Zugriff auf den Shaddow RAM der normalerweise über das Registerfile + internes SRAM verdeckt wird. Man hat nur die ersten 32Kb gemappt dafür zweimal. Und so könnte man auch die externe RAM Bank 0 mit der externen Bank 2 oder 3 oder 1 usw. einblenden. Dadurch würden Kopieroperationen zum großen Teil direkt von einer Bank zu einer anderen Bank möglich ohne das man zwischenbuffern müsste. @Guido: wieviele globale Variablen erwartest du denn ? Ich meine das wenn man viel RAM benötigt der meistens für große Buffer draufgeht. Du kannst aber auch bei so viel RAM eine dynamische Speicherverwaltung nutzen. Wer selber auf PC's programmiert weiß was für viele Vorteile so eine Veraltung nach sich zieht, Klassen, echte PChars, C++ usw. WinAVR hat schon eine integriert und wenn ich richtig informiert bin brauch man dieser nur die Start + Stop Addresse des verfügbaren Bereiches mitteilen. Der obige Weg war nur ein Vorschlag um die Sache bzw. Zugriffe zu vereinfachen. Allerdings lässt es sich nicht bestreiten das ein Memory Banking immer wie eine Speicher-Segmentierung auch Nachteile haben kann. Im einfachsten Falle würde man die Section .noinit per Makefile umdefinieren, zb. in den festen SRAM Bereich von 0x1200 bis 0x7FFF. Alle globalen Variablen würde der Compiler dann automatisch dort ablegen. Der interne SRAM von 0x1000 Bytes wäre dann komplett für den Stack frei. Normalerweise müsste man ja zu jeder globalen Variable die im externen SRAM gespeichert werden soll eine absolute Addresse vergeben. Der Compiler durch unsere Vorschriften keine Möglichkeit diese Variablen selber im Speicher zu verteilen. Nun obige Methode ist der Weg wenn man dem Compiler mitteilen möchte das es einen Speicherbreich mit Namen XYZ im Addressbereich von X bis Y gibt. Nun brauch man nur noch dem Compiler mitteilen das er Variable Z im Speicher XYZ ablegen soll. Alle Variablen die dort abgelegt wurden werden aber weiterhin vom Compiler selber organisiert. Nun, das Gleiche kann man aber auch für die Speicherbreich die die Memory Mapped Devices enthalten machen. Auch das habe ich oben mit CPLD_MM gezeigt. Diese Form der Programmierung lässt es nun zu das man im Makefile die Speicherorganisation dynamisch anpassen kann. Also nochmal genauer: > Z.B. Frage ich mich gerade, was mit stink normalen Variablen > passiert? Liegen die im Ram des AVR oder liegen sie extern? Ich gehe von WinAVR aus. Alle globalen Variablen wie uint8_t i; char Name[12]; liegen in der Section .noinit da sie nicht intialisert wurden. Diese Section .noinit wird vom Compiler automatisch auf den maximal verfügbaren internen SRAM ausgelegt. Der Linker weis aber, da es statische Variablen sind, wieviel Bytes sie insgesamt benötigen. Die Section .noinit endet also an Addresse 0x10FF beim ATMega128 und beginnt bei 0x10FF - SizeOf alle Variablen im SRAM. Davor legt der Compiler den Stack an. Somit reduzieren solche globalen statischen Variablen den verfügbaren Stackspace. Alle initialisierten globalen Variablen wie uint8_t i = 0; werden ebenfalls im .noinit abgelegt, allerings Topdown im SRAM gruppiert als erstes. Man bezeichnet das zwar des öfteren als .bss Segment das ist aber nicht ganz korrekt. Denn WinAVR legt im .bss, der im Flash liegt, die Initialwerte dieser Variablen an. Im .init0 Code wird nun die .bss Section automatisch in den Bereich der .noinit Section kopiert und somit die globalen und preinitialisierten Variablen eingerichtet. So ich hoffe das ich da jetzt nichts falsches geschwätzt habe. So jedenfalls habe ich den Startupcode den WinAVR generiert verstanden. Es ist nun ohne weiteres möglich diese Sections selber im Makefile für den Linker vorzugeben. Auf alle Fälle hat man im WinAVR die Freiheit eigene Sections anzulegen, ihnen einen Namen zu geben und dann eine Variable per Zuweisung mit attribute() in dieser Section abzulegen. Alle Variablen in der gleichen Section werden aber immer noch vom Compiler organisert, d.h. der Linker hat die Freiheit wie er sie in dieser Section addressbezogen speichert. Andererseits sollten nur die Anforderung des angestrebten Zieles die eingesetzten Mittel bestimmen. Damit meine ich ob ein WEB Server auf einem AVR, der zusätzlich noch bis zu 1Gb an SD/MMC Flash zur Verfügung hat um dort unveränderliche Bilder, HTMLS usw. zu speichern, überhaupt 512Kb an SRAM benötigt. Oder ob eben 64Kb nicht ausreichen würden. Auch ich würde mit 64Kb SRAM bei weitem auskommen und sehe eigentlich nicht die Notwendigkeit für einen WEB Server auf'm AVR das er mehr bräuchte. Wichtig wäre dann das die SD/MMC Library + zugehöriger FAT Library möglichst hoch effizient ist um auf die externen Daten schnell zugreifen zu können. Im Falle eines HTML Servers ist es glaube ich wichtiger das die rauszusendenen HTMLs möglichst effizient geparsed werden können. Die einkommenden HTMLs um Interaktionen zu ermöglichen sind meistens nur 1-2 Kb groß. Klar einen SSL Client für Verschlüsselungen wird man da eh nicht reinkriegen. In diesem Falle würde ein kleiner Xlinix ausreichen um alles unterzubekommen. Wie gesagt, falls du dich für den CPLD entscheidest bin ich gerne bereit meinen Beitrag zu leisten. Ich kann aber deine Bedenken durchaus nachvollziehen und weis selber was es heist Support leisten zu wollen ;) Gruß Hagen
Ich denke es gibt da zwei unterschiedliche Richtungen: entweder mit AVR und alles möglichst einfach halten, oder gleich ein richtig dickes Ding mit ARM-Controller und RAM so weit das Auge reicht. Ein Hybrid mit AVR, gebanktem RAM und CPLD ist weder Fisch noch Fleisch: zu aufwändig und umständlich für's Hobby, zu leistungsschwach für größere Anwendungen.
Hi Andreas, normalerweise würde ich dir zustimmen, zumindestens stimmt das im übertragenem Sinne in meiner Arbeit als professioneller Programmierer. Allerdings habe ich's auch erleben dürfen das man mit unglaublich kleinen Mitteln denoch was Großes aufbauen kann :) Das wurde aber nur möglich weil sich Enthustiasten nicht an die "Norm" gehalten haben und experimentierten. Ich denke da nur an Igor und die vielen anderen Leute wie hier im Forum. Und im grunde ging es Guido ja nur darum den Latch, die NANDs und INV's wegzubekommen um die Platine übersichtlicher zu machen. Und falls es nur das sein sollte dann wäre ein CPLD schon eine Möglichkeit. Die Wünsche der Einzelnen sind halt nur ein bischen abgeschweift :) Gruß Hagen
Hi. Mir scheint, dass das ganze jetzt langsam immer mehr in eine endlose Diskussion ausartet. Ich will mich ja nicht unbedingt einmischen, da ich ja mein eigenes Projekt habe, aber naja... irgendwie treten die selben Probleme auf wie Linux teilweise hat. Viele Leute, die als Entwickler helfen wollen, haben zwar gute Ideen und sind auch gut, um Fehler in Layouts zu finden und überall dort wo mehr Augen mehr sehen als zwei, aber leider kommt es dabei auch oft zu einer Schwierigkeit: jeder möchte seinen Hardware-Teil dabei haben (auch verständlich) und damit kommt es zu vielen Änderungen am Layout und das Ding wird im Prinzip nie fertig. Ich kann da Andreas zwar teilweise zustimmen, muss aber trotzdem sagen, dass auch die relativ "kleinen" AVRs sehr leistungsfähig sein können! Mal etwas projektbezogener: Wenn man den CPLD verwendet, dann sollte auf jedenfall - wie es schonmal angesprochen wurde - die Programmierung auch über den AVR laufen, damit Änderungen leicht ohne zusätzliche Schnittstelle bzw. Kabel gemacht werden können. Sind ja auch nur 4 Leitungen, die mit dem AVR verbunden werden müssen! Falls kein CPLD verwendet werden soll, weil den die wenigsten zu Hause rumliegen haben, ist für die Chipselectgenerierung vielleicht ein 74HC138 interessant. Dann könnte man z.B. 32kByte SRAM auf Adresse 0x8000 - 0xFFFF legen und 8 CS-Signale mir A14,A13,A12 machen. Man könnte dann auch eine Schnittstelle definieren, wobei 8 CS-Signale, die 8 Datenleitung, 16 Adressleitungen, WR, RD, 5V, 3.3V und GND draufliegen. Damit könnte man extern noch bis zu 8 weitere Devices anschließen. So könnte sich jeder noch seine eigenen Sachen (IDE, USB Host, ...) anschließen und so wird das Board langsam wirklich zur absoluten eierlegenden Wollmilchsau. mfg Andreas
Hi ach so hätte auch interesse an ner platine ev auch nur am layout zum platine selber machen Gruss Flo
Hi guido Als Levelshifter könnte ich nen max3000 empfehlen hab ich auch schon verwendet und geht gut. Den gibts bei maxim als sample ;) Gruss Flo (auch wenn du mich hasst ;) )
Hallo Guido, ich hätte Interesse an drei Stück von den Platinen. Gruß Torsten
Hi ich muß zwar meine Zusage für eine Platine zurückziehen (bin an ein anderes Board mit aVR und Ethernet gekommen) aber trotzdem würde ich den 74LVX125 als Levelshifter vorschlagen. http://www.fairchildsemi.com/ds/74/74LVX125.pdf Auf irgendwelche Bauteile die nur als Muster zu beschaffen sind würde ich verzichten. Matthias
Hallo Guildo, wie sieht der CMOS 4041 aus? Ich benutze den zwar zum Hochshiften eines VFD; aber der kann IMHO auch inver arbeiten. Gruß Marcus
Sehr interessanter Tread werde ich weiter beobachten. @Guido super Leistung cu Fred
mich würde auch eine oder zwei kaufen wenn möglich danke oe6kug kern helmut bitte um info
hab die seiten schon im archief und wie gehts weiter wo bekommt mann die platinen danke
Hallo, habe mir die Sachen angesehen, gefällt mir gut. Passt da noch ein RS485 Treiber mit drauf, anstatt RS232 ???
Hallo, Lediglich der RS232 Treiber müsste durch einen RS485 Treiber ersetzt werden (Bestückungsoption oder Jumper) + 100Ohm Terminator. Der Ausgang kann auf die Sub-d Buchse gehen. Tschau
jetzt mal langsam, mit großem Interesse habe ich diesen Thread verfolgt. Solch eine Platte hatte ich auch schon mal designt. Bin aber inzwischen von der eierlegendenden Wollmilchsau (EWMS) abgekommen. Habe mich auf ATMega128 Takt Reset ISP JTAG + Stromversorgung + SRAM + EEPROM + 10BT Ethernet + RS232 + Addressdecoder beschränkt. So eine EWMS braucht man nicht, schließlich ist ein Mikrokontroller. Beim Experimentieren stört die überflüssige Peripherie nur. Für besser halte ich, dass man die grundlegende Schaltung erweitern kann, eine Art BUS-System und das sie auf ein Steck-Board paßt, dh Abstand der IO-Pins im Steck-Board Raster. Für Erweiterungen kann man dann Module aufstecken. Eine EWMS wird zu teuer, nie werden alle Schnittstellen benötigt. Es geht auch mal was kaputt beim Experimentieren, dann löte mal so einen Tausenfüßler ohne Verluste (wenn auch nur optisch) raus. Ich komme aus dem Bereich KFZ-Technik, hätte dann gern noch MOST, FlexRay, LIN, K-Bus, I-Bus... Also, ich fände es besser, ein Grundmodul ATMega128 Takt Reset ISP JTAG + Stromversorgung + SRAM + ggf. EEPROM + Addressdecoder zu bauen. Links und rechts einreihige Stiftleisten, die zum Stapeln der Module dienen und die im Raster eines Steckbretts liegen. Ich glaube solche Module gibt es schon massenhaft, wenn man sich den Arbeitsaufwand überlegt sind die auch recht preiswert. Gruß G.
Ja, RS485 würde das ganze Schnittstellenmäßig abrunden :-) Die Treiber sind leicht erhältlich und preiswert. Und ein bis zu 1,4 Kilometer langer Bus ist ja eine schöne Option :-) Gruß Andreas
Hallo Guido, hab mir mal das Layout angeschaut. Werden das 2 oder 4 Layer? Mit 2 Layern wirst du das nicht schaffen. Ich spendiere 150 Euro, wenn du das fehlerfrei mit 2 Layern, wenigen Brücken und allen geplanten Eigenschaften hinbekommst... Gruß
Hallo super Thread. Falls die Sache was wird, hätte ich da auch Interresse an ner Platine. Ist bei diesen tollen Schnittstellen auch an einen I2C BUS-Treiber bzw. Multiplexer oder 1-Wire Bustreiber gedacht? Ich möchte damit Temperaturen erfassen. Nin leider ein Hardwarnobody. Viele Grüße Achim
Hallo Achim, so wie das bisher sehe - Guido bitte korrigiere mich falls ich falsch liege - werden die I2C Ports nach aussen weitergeführt. @Guido: der RS485 kan doch IMHO per VIA auf die Unterseite verbannt werden oder? GRuß Marcus
Der dient der Richtungsumschaltung und braucht einen Portpin, wenn die Richtung vom MC geschaltet werden soll. Du willst doch Senden und Empfangen, oder? Wieder eine Leitung mehr für 2-seitige Layout... Gruß
Hi, ich verfolge diesen Thread schon einige Zeit und hatte mich fuer 2 Platinen bei Guido gemeldet. Die RS485 Schnittstelle wurde in meinen Augen durch den Can Bus abgeloest. Es ist somit in meinen Augen ein bischen Oversized jeden denkbaren Bus zu implemetieren. Zum Schluss muss Guido noch GPIB, Bluetooth , Firewire und IRDA mit auf die Platine quetschen. Ich moechte niemanden auf den Schlips treten , deshalb würde es mich interessieren wieso die RS485 Schnittstelle noch mit eingebunden werden soll. Mfg Dirk
Hallo Guido, wenn Werner 150 Euro spendiert, haben wir ja die Einmalkosten für eine Kleinserie zusammen :-) Dann kostet jede Platine noch vielleicht 6-7 Euro. Ich duck mich schonmal wenn ich das jetzt frage :-) Meinst du man könnte noch über die Farbe der Platine abstimmen, ich finde das blaue Basismaterial einfach optisch genial. Dann noch ein gelber Bestückungsdruck :-) ... Ich weiss, das Layout ist ja noch nichtmal fertig, aber kann ja nichtmehr lange dauern. Grüße Andreas
Und ich habe den CPLD soweit fertig. Eventuell könnte ja mal jemand mit mehr Erfahrung da reinschauen. Guido möchte bei 5 Volt und VQPF44 bleiben was die Wahl auf den XC9536 VQPF44 beschränkt hat. Der CPLD wurde voll ausgelastet, d.h. es stehen keine freien Pins und nur noch 1 Makrozelle zur Verfügung, leider. Diese Entscheidung hatte mehrere Gründe. Die meisten die das Board aufbauen werden haben keine Ahnung von VHDL und CPLDs. Die Leute die aber Ahnung haben können die Funktionalität an ihre Wünsche anpassen. Aus dem gleichen Grund wurde auch auf die Programmierung des CPLD's per AVR verzichtet. Man kann ja immernoch über die Header und eine spezielle Software auf dem AVR das so verdrahten das man den CPLD Onboard programmieren kann. Die Funktionalität sieht so aus: bis zu 512Kb externer SRAM wird per 32Kb Memory Bänke angesprochen. Dabei können immer eine/zwei der maximal 16 Bänke in den AVR Speicherbereich eingeblendet werden. Es gibt insgesamt 5 Memory Mapped Geräte in den Addressbereichen: 0x0000-0x10FF ATMega128 Register + interner SRAM 0x1100-0x11FF CPLD.Memory Controller 0x1200-0x12FF CPLD.externer 8 Bit Port 0x1300-0x13FF FTDI 0x1400-0x14FF Realtek 0x1500-0xFFFF externer SRAM Der CPLD hat einen 8 Bit breiten Ausgabe Port, sozusagen eine Memory Mapped Port Erweiterung des ATMega128. An diesem Port sind bis jetzt 4 SPI Chip Selects vorgesehen. D.h. die Chip Selects für MMC/CAN/seriell Dataflash usw. Desweiteren übernimmt der CPLD die Ansteuerung der RD# und WR# Signale des FTDI Controllers. Diese Signale werden abhängig von der Addresse (0x1300-0x13FF) und von WR\ und RD\ erzeugt. Sozusagen eine implizite Addresdekodierung über die WR# , RD# Signale am FTDI Chip. Im ZIP File findet sich ein Jpeg -> "Simulation.JPG" in dem man sich die simulierten Signale anschauen kann. Je nach Ausbaustufe des Boards kann das VHDL wieder "gestutzt" werden. Wer zb. nur 64Kb SRAM anschließt kann 4 Pins freimachen und eine Menge an Makrozellen einsparen. Wer keinen FTDI lötet kann 2 zusätzliche Pins freimachen. Wer mehr Memory Mapped Geräte benötigt kann den 8 Bit Port auf 7 Bit verkleinern usw. usw. Denoch, auf die Festlegung auf 5 Volt und VQPF44 ist die Wahl des CPLD's sehr beschränkt, mehr als 36 MM's sind nicht drinnen. Gruß Hagen
Nein ist es nicht. Beide, RD und WR, sind am FTDI Low-Aktiv alles andere wäre auch irgendwie nicht so Standardkonform. In allen Schaltbildern ist zwar nur RD ein invertierter Eingang, wenn man aber im Datenblatt genau nachliest so findet man schon auf den ersten Seiten einen Text indem WR# statt WR geschrieben wurde. Ich habe dann einige Schaltbilder mit dem FTDI analysiert -> Jasper,und dort ist WR low aktiv, auch wenn das Schaltbild anderes suggeriert. Allerdings, dreifach hält besser, es wäre also schön wenn du auch nochmal ins Datenblatt schauen könntest. Viel dir sonstnochwas am VHDL auf was geändert werden muß ? Gruß Hagen
Warum RS485: Einfach und billig, kaum Overhead bei der Hardware (8pol. IC).
Hi http://www.ftdichip.com/Documents/DataSheets/ds245b15.pdf <Zitat> Writes the Data Byte on the D0..D7 into the Transmit FIFO Buffer when WR goes from high to low. </Zitat> Zusätzlich das Timing-Diagramm auf Seite 11. Zeit T9. Data Setup Time before WR inactive. Sollten mind. 20ns sein. http://www.atmel.com/dyn/resources/prod_documents/doc2467.pdf Seite 330. Zeit 13. Data Setup to WR Low. Sind hier 0.5*tclcl-20. Das sind 11ns bei fosz=16MHz. Wenn du WR invertierst passt das Timing wunderbar. Matth*schoneinigFT245BMverbauthabend*ias
@Matthias: Ok, nochmal um die Sache 100%'tig richtig zu machen: >Writes the Data Byte on the D0..D7 into the Transmit >FIFO Buffer when WR goes from high to low. das heist für mich wenn WR = Low dann wird geschrieben, ergo WR# ist Low Active. Zweitens: Ich gehe davon aus das der FTDI bei WR# = High und RD# = High seinen Datenbus auf High-Z setzt. Das muss er da ansonsten Buskonflikte mit anderen Geräten zu erwarten sind. Demzufolge darf der CPLD FTDI_WR# und FTDI_RD# nur solange auf Low ziehen wie AVR_RD# oder AVR_WR# auf Low sind UND auf A8-A15 der Addressbereich des FTDI's anliegt. Würde ich nun das FTDI_WR# Signal invertiert zum AVR_WR# Signal gestalten dann würde der FTDI ja alles was am Datenbus anliegt,unabhängig von A8-A15 in seinen FIFO schreiben. Ok, ich weis er ist Flankengetriggert. Ich ging bei meinem Design aber von einem ganz anderem Timing aus. Im Datenblatt des ATMega128 auf Seite 27 ist das Bustiming grafisch dargstellt. Wenn ich das richtig interpretiere ist es auf Grund des asynchonen Konzeptes notwendig das am Datenbus schon vorher und auch nach den Flanken auf WR# und RD# ein korrektes Signal anliegt. Ergo: FTDI_WR# geht par ns später auf Low wenn AVR_WR# auf Low fällt und nur dann wenn A8-A15 die Memory Mapped Addresse vom FTDI enthält. Eigentlich müsste dann mein VHDL korrekt sein. Hast du dir mal "Simlation.jpeg" im ZIP angeschaut ? Ich bin mir aber eben unsicher in diesen Punkten, eben weil ich so'nen Ding noch nicht praktisch verbaut habe. Von daher, wenn du sagst es ist definitiv besser das Signal zu invertieren dann mache ich das auch. Ich möchte halt sicher gehen und Guido unnötige Fehlersuchen ersparen. Gruß Hagen
Hi es ist definitv besser denn wenn du das Signal nicht invertierst wird das Timing bei 16MHz nicht mehr in den Spezifikationen sein. WR ist, wenn mans mal genau nimmt weder High- noch Low-aktiv. Es ist flankengetriggert. Wenn also eine negative Flanke auf WR kommt wird das was gerade an D0 bis D7 ansteht in den FIFO geschrieben. Wird das Signal jetzt nicht invertiert reicht die Setup-Zeit die D0-D7 vor der negativen Flanke brauchen nicht mehr aus. Bei CMOS ist Eingang == HighZ. Da gibt es keinen Unterschied. Beim WR wird also der Port nicht kurz niederohmig. Matthias
@Matthias: >Wenn also eine negative Flanke auf WR kommt wird das > was gerade an D0 bis D7 ansteht in den FIFO geschrieben. > Wird das Signal jetzt nicht invertiert reicht die Setup-Zeit die > D0-D7 vor der negativen Flanke brauchen nicht mehr aus. Ok, ich habe jetzt nochmal die FTDI Timings genauer angeschaut. Im Datenblatt Seite 11 -> T9 und T10. Vor der Pegeländerung an WR# von High nach Low müssen die Daten min. 20ns auf dem Datenbus stabil liegen == T9. T10, die Haltezeit dieser Daten nach der Pegeländerung ist 0 ns. Die Vorhaltezeit der Daten durch den AVR beträgt 0.5 * Tclcl -20ns == 11ns bei 16 Mhz. Der Skew des CPLD von AVR_WR + AVR_AH zum FTDI_WR beträgt minimal 5ns, ergibt 16ns. Das ist zu kurz. Das Problem düfte es also sein das der AVR die Daten nicht 20 ns vor dem Schalten von FTDI_WR# anlegt. Man müsste einen Delay für FTDI_WR definieren, nur wie geht das mit'm XC9500. Ok, wenn ich jetzt das FTDI_WR# invertiere gibt es aber keine Probleme falls bei FTDI_WR# == Low zusätzlich noch FTDI_RD# auf Low geht oder ? In meinem VHLD war's bis jetzt so: FTDI_RD <= '0' when (AVR_RD = '0' and AVR_AH = "00010011") else '1'; FTDI_WR <= '0' when (AVR_WR = '0' and AVR_AH = "00010011") else '1'; Wie soll ich jetzt diese Logik ändern ohne das ich AVR_WR als Taktsignal definiere ? Gruß Hagen
@Mattihas: Ich habe jetzt das Signal invertiert. Der Geist sträubt sich zwar aber die Timing Simulation sagt das es richtig ist. Der AVR hält nach AVR_WR von Low auf High bei 16 MHz die Daten noch für 47ns auf dem Bus. Der Skew von AVR_WR nach FTDI_WR ist maximal 15ns. Somit haben wir die komplette AVR_WR Zeit + den CPLD Skew als Setuptime für die Datenleitungen am FTDI. Sonst noch was zu beachten ? Gruß Hagen
@Guido: Auch ich gehöre zu denjenigen die diesen Thread verfolgen und (spätestens durch die Integration des CPLDs) Interesse an ein paar Platinen haben. @Hagen: Ich habe mir Dein VHDL mal angeschaut. Meine Erfahrungen sind zwar schon ein paar Tage (oder besser Jahre?) her, hätte aber dennoch die eine oder andere Anmerkung. Prinzipiell scheint es ja zu funktionieren, doch frage ich mich, warum Du die CS-Signale für den RTL8019 und das SRAM innerhalb eines Prozesses definierst. Ich würde die Definition auseinanderziehen, so wie Du es auch unten für den FTDI gemacht hast. Auch würde ich die Adressbereiche zentral definieren, dann ist es für diejenigen übersichtlicher, die Änderungen vornehmen wollen (auch wenn es eigentlich schon recht übersichtlich ist). Volkmar
@Volker: das hatte ich schon alles so gemacht gehabt. Seltsamerweise verbrauchte das dann beim Fitten mehr Makrozellen als jetzt. Es waren um einiges mehr Makrozellen als inden 36'er reingehen. Insgesamt habe ich wohl 12 verschiedene VHDL's entwickelt und ausprobiert. Nimmt man das obige VHDL und compiliert es für einen MAX7000 unter Quartus II Free Edition, dann verbraucht es 65 Makrozellen. Auch dies ist seltsam. > Prinzipiell scheint es ja zu funktionieren, doch frage ich mich, > warum Du die CS-Signale für den RTL8019 und das SRAM innerhalb eines > Prozesses definierst. Ich würde die Definition auseinanderziehen, > so wie Du es auch unten für den FTDI gemacht hast. Das ist prinzipiell richtig. Nur dachte ich schon ein bischen weiter, denn so, mit den separaten Processen, ist es für die Zukunft möglich gezielt MMD_CS zu erweitern, zb. A18 und A17 fallen weg da nur ein 128 Kb SRAM benutzt wird oder der 8 Bit Port wird auf 6 Bit verkleinert. Man hat so 2 zusätzliche CS's in MMD_CS zur Verfügung. Deren Dekodierung würde dann im separaten 1. Process programmiert werden. Die beiden Prozesse zum Lesen/Schreiben der internen Register des CPLD's habe ich so gebaut damit man diese so umprogrammieren kann das sie Flankengesteuert auf AVR_WR und AVR_RD reagieren können. Pro Prozess kann es aber nur ein Clock Eingangssignal geben. Die globale Definition der einzelnen Addressen per Konstanten habe ich nicht gemacht weil es unter Umständen vorkommen kann das man die Adressauswertung, nicht so wie jetzt, sondern Bitorientiert und zerlegt durchführt. Dann würden uniforme globale Konstanten den VHDL nur schwerer lesbar machen da ja dann diese Konstanten ebenfalls im Source per Masken zerlegt werden müssen. @Guido: da fällt mir doch ein, du solltest AVR_WR und AVR_RD beim Pinning auf GCLK Pins (globale clock's) legen. Gruß Hagen
Ich habe verschiedene Konfigurationen für den CPLD getestet. Zb. eben das man AVR_RD und AVR_WR als Clocksignale betrachtet und intern Flankengetriggert auswertet. Dies hat keine Änderungen im Resourcenverbrauch gebracht (sprich weniger Makrozellen), aber es hat das Timing im CPLD verbesster. Falls wir nun feststellen das das jetzige Timing zu kritisch ist hätten wir somit die Möglichkeit das VHDL ohne neues Layout anzupassen. Desweiteren habe ich zB. den 8 Bit SPI_CS Port auf 7 Bit reduziert und das freie Signal SPI_CS(7) als zusätzliches MMD_CS(2) umdefiniert. Somit hätte man ein zusätzliches Memory Mapped Gerät verfügbar, zB. CF Karte, IDE Fetsplatte oder parallele ADC/DAC die alle am Bus angeschlossen werden könnten. Dieses geänderte VHDL beötigt dann 31 Makrozellen und passt somit ohne Probleme rein. Das gleiche habe ich dann noch mit A18 des SRAM's gemacht. Wenn man also statt 512Kb nur 256Kb SRAM's anschließen möchte so bliebe ja A18 ungenutzt. Nun das geänderte VHDL nutzt diese A18 als zusätzliches MMD_CS(2). Auch diese Konfiguration habe ich getestet und sie benötigt 32 Makrozellen. Somit habe ich verschiedene gänderte CPLD Konfigurationen ausgetestet und versucht das Pinning so zu gestalten das es ohne Layoutänderungen mit verschiedenen Konfigurationen funktioniert. Ergo: ich habe geprüft ob es flexibel ist. Zb. habe ich mal testweise den SPI_CS Port in zwei getrennte 4 Bit Ports zerlegt. Der eine Port wird als 2 zu 4 Dekoder angesprochen, für die SPI CS Signale. Der andere Port ist ein 4 Bit paralleler Port. Bei dieser Konfiguration werden denoch 33 Makrozellen verbraucht obwohl ich annahm das es weniger benötigen könnte. Somit ist das jetzige Design mit einem 8 Bit parallelen Port wesentlich flexibler. Allerdings, mehr als "Anpassungen" sind bei einem XC9536 eben nicht drinnen. Gruß Hagen
@Hagen: > Zb. habe ich mal testweise den SPI_CS Port in zwei getrennte 4 Bit > Ports zerlegt. Der eine Port wird als 2 zu 4 Dekoder angesprochen, für > die SPI CS Signale. Der andere Port ist ein 4 Bit paralleler Port. Bei > dieser Konfiguration werden denoch 33 Makrozellen verbraucht obwohl ich > annahm das es weniger benötigen könnte. Somit ist das jetzige Design mit > einem 8 Bit parallelen Port wesentlich flexibler. Hast Du den 2zu4 Dekoder 'hinter' den Speicher für die 2 Bits gebaut? Ich habe mich zwar noch nicht mit Xilinx beschäftigt (damals war Altera und Lattice an der Reihe), aber es könnte sein, das Du etwas einsparst, wenn Du den 2zu4 Dekoder vor die Zellen baust. Aber ich fürchte, wir schweifen hier etwas vom Thema ab. Volkmar
Hallo Leute, ich muß jetzt dochmal etwas zu dem "so flexibel wie möglich sagen": Prinzipiell finde ich das ja alles supter, wenns so flexibel ist. Aber bedenkt auch, dass hierdurch noch mehr Probleme entstehen und zwar für die Leute, die ein CLPD weder kennen noch programmieren können. Zudem wernn ich jetzt da noch mehr Devices anbauen würde, würde die Firmware irgendwann so komplex, dass es diese Leute wieder abschreckt. Also bitte irgendwann macht mal einen Punkt und dann solltet ihr das mit dem Vorschlaghammer durchziehen und zwar ohne Kompromisse, sonst wid dat nüs, jeschweige denn irgendwat bruchbahres - wie der Rheinländer zu sagen pflegt. So, in diesem Sinne, mir fehlt da so langsam mal Schlußstrich. Gruß Marcus
Das Port Register wurde von 8 auf 6 Bits reduziert. 2 Bits dienen dann als Input für den 2 zu 4 Dekoder. Man spart 2 FF's für die 2 Bits ein, man benötigt aber wieder zusätzliche Makrozellen für den Dekoder. Sogesehen habe ich den 2 zu 4 Dekoder "hinter" die 2 Bits gebaut. Auch aus dem Grunde um deren Inhalt wieder aus dem CPLD durch einen Lesezugriff aulesen zu können. Auf diese "Lesefähigkeit" wollte ich von Anfang an nicht verzichten. Ich sollte denoch mal testen was ein Port + Memory Banking im writeonly Mode bringen könnte. Gruß Hagen
Hallo Guido, erstmal Respekt vor deinen Routingkünsten, ich hätte da warsch. irgendann die Lust dran verloren! Ich mahce mir bzgl. des CPLD's keine Sorgen, wollte lediglich die PRoblematik aufzeigen. Wie da noch ein RS485 Treiber drauf kommen soll ist mir wirklich ein Rätsel ;) Gruß Marcus
Hallo Guido, erfahrungsgemäß dauern bei solchen Projekten 90% Fertigstellung 10% der Zeit und die restlichen 10% duern dann 90% der Zeit. Ich stehe zum Sponsoring, wenn ... siehe Text weiter oben du das fehlerfrei mit 2 Layern, wenigen Brücken und allen geplanten Eigenschaften hinbekommst...
Hallo Guido, da ich (leider) nur die Freeware-Version von Eagle habe, kann ich vom Schaltplan leider nur die erste Seite sehen. Kannst Du zB eine PDF-Version des Schaltplans bereitstellen? Danke Volkmar
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.