Hallo
Ich beschäftige mich gerade mit zahlreichen AVR's.
Speziell mit den Mega's und Tiny's.
Da ich für diverse typen mir adapterkabel gebaut habe und dies nicht
wirklich komfortabel ist suche ich eine Lösung für einen universellen
Sockel.
Folgende Grundgedanke kam mir dabei in den Sinn:
Jeder AVR besitz seine ganz speziellen Funktionen. Auch sind nicht alle
PORT-Pin der Controller kompatibel.
Ich würde jetzt einen Sockel definieren der sich nach den größten Megas
ausrichtet. D.h. alle Pins auf Stiftleisten herausgeführt.
Somit sind die Pinfunktionen des Sockels festgelegt.
Für jeden AVR existiert jetzt eine Platine die eben genau diese
Pinbelegung besitzt. Die Leitungen bzw. Portfunktionen des eingesetzten
AVRs müssen jetzt mit dem Adapter verbunden werden.
Mein Problem ist jetzt die Doppel- oder Mehrfachbelegung diverser
AVR-Pins, speziell die Tinys.
Ist es nur möglich mittels eines CPLD's die AVR Funktionen auf einen
einheitlichen Sockel zu routen?
Ziel soll es also sein einen Adapter zu entwickeln der aus einer Platine
besteht, die den AVR (SMD Bauform) besitzt und dessen Funktionen auf die
fest definierten Pins des Sockels geroutet werden.
Vielleicht habt ihr ja gute Lösungsansätze für dieses Problem :)
Gruß
Ich frage mich, was der Sinn davon ist, die verschiedenartigen
Controller (gar mit einem CPLD) in eine genormte Form zu bringen. Wenn
es das wäre, was die Welt braucht, würde Atmel nur einen einzigen
Standard-AVR anbieten...
Nun genau so etwas ist gedacht.
Es soll eigentlich nicht für den Standard Bastler was sein. Primär ist
es für eine Entwicklungs und Testumgebung gedacht in der die
verschiedensten AVRs getestet werden sollen.
Kein Mensch hält sich in der Regel so viele verschiedene Controller auf
Lager.
Jedoch benötige ich sowas für meine Testumgebung.
Ist so etwas machbar?
mir bleibt der Sinn des Ganzen völlig verborgen. Wer auf bestimmter
Hardware entwickeln will muss sich diese Hardware auch hinlegen. Wo ist
da das Problem?
Was soll das bringen ? Fuer ein Projekt waehle ich einen controller aus
wie ich ihn brauche. Praktisch waere den naechst groesseren/kleineren
pinkompatibel zu bekommen. Wenn die Serie nicht allzu gross werden wird,
nimm ich lieber gleich den Groesseren. Einen Sockel, der Alles
erschlaegt macht wenig Sinn.
Das hat schon Sinn: Wer sich noch nie einen Adapter für sein
HV-Programmiergerät bauen mußte, weil er verschiedene AVR-Typen damit
"bearbeiten" wóllte, ist gut dran.
MfG Paul
Naja wie am Anfang beschrieben mag das ganze alles sehr unlogisch und
nicht praktisch klingen :)
Jedoch ist es dies für diesen Spezialfall :)
Mirg geht es jetzt auch nich um sinvoll oder nicht, sondern eher um eine
Lösungsfindung für diese Aufgabenstellung:)
Wer kann da mitwirken bzw. kennt sich etwas aus?
Gruß
Ich muss auch sagen, anstatt einfach das Ganze in Frage zu stellen, wäre
es bei Weitem sinnvoller konstruktive Vorschläge zu machen...
Tschuldigung für den Spam
Gruß
CaH
Naja, ich versteh die die das in Frage stellen schon. Ich musste noch
nie nen Controller per HV wiederbeleben. Und wh ichs mir antu Kabel an
die entsprecehnden Beinchen zu löten nehm ich lieber nen nen Controller.
Bei nem atmega2561 macht das dann irgendwann mal sinn die Kabel
anzulöten aber drunter doch net. ISP oder JTAG reicht zum programmieren
und debuggen allemal wenn man wirklich was verhaut was recht selten
passiert schmeisst man halt mal nen Controller weg.
Ich brauche nicht nur ISP oder JTAG.
Ich möchte vom AD-Wandler über ISP, Spannungsversorgung bis hin zur
einfachen Port-Funktion (I/O oder alternative Funktion) herausführen.
Da ich aber bei meiner Zielhardware nicht jedes mal einen speziellen
Adapter für den gerade eingesetzten AVR mir zusammenbauen müchte soll es
jetzt ein "NORM-Adapter" sein.
Deswegen nochmal: Ist dies zu lösen und wenn ja wie? Wie schon erwähnt
habe ich an einen CPLD gedacht, nur leider habe ich selber noch nicht
all zu viel damit gemacht, würde mich aber dahingehend einarbeiten,
falls das eine brauchbare Lösung wäre.
Gruß
Fritz wrote:
> Deswegen nochmal: Ist dies zu lösen und wenn ja wie? Wie schon erwähnt> habe ich an einen CPLD gedacht
Witz, Du bist umzingelt.
Der CPLD kann nicht riechen, wie die DDRx-Register im AVR gesetzt sind
und analog umschalten geht gleich garnicht.
Du müßtest schon ein Kuchenblech voll mit 74HC4066 oder Relais nehmen.
Peter
Das ist ja Wahnsinn, dann musst du ja fast jeden Pin an jede Position
schalten können ? Man nehme also ein array von Analogschaltern und ordne
es so an das man an einem Pin die Anzahl von Kanälen hängt die der MC
als IO Pins hat. Und das ganze für jeden Pin also bei 64 Pins 4096
Analogkanäle ...
Ich denke ne Hand voll Adapter ist bei weitem die bessere Lösung
Wie ich sehe würde diese Aufgabe mich vor einen riesen Aufwand stellen.
Aber wenn ich es mir recht überlege ist es doch "nur" ein logisches
Umschalten der Portfunktionen.
z.B. Mega 8
PC5 (ADC5/SCL)
auf SCL programmiert
jetzt müsste eben der CPLD oder FPGA oder sonst ne Logik wissen wie der
AVR programmiert ist und die Portfunktion SCL auf den entsprechenden Pin
des Sockels routen.
Alle anderen Funktionen (I/O oder ADC5) dann nicht routen.
-> Am Sockel sind dann eben die Pins ADC5 und der normale I/O nicht
beschaltet.
die logik sollte des weiteren biderektional SIgnale routen können.
Über die Software des AVRs würde dann eben jedesmal die Logik neu
programmiert.
@Peter: Ein Kuchenblech an IC's sollte natürlich nicht verbaut werden.
Du willst aber nicht nur 2 verschiedene Controller damit ansteuern wenn
ich dich recht verstehe und damit werden sich die
Kombinationsmöglochkeiten sehr schnell quadrieren.
Also nochmal:
Vom Aufbau her hat jeder Controller seine eigene Platine.
OK also die Platine besitz eben diese "genormte" Pinbelegung mit allen
Funktionen, die ein AVR so haben kann.
AVR -> Logik -> genormter Sockel (bestehend aus Stiftleisten)
d.h. kein Universal sockel! Eben nur ein gemeinsamer Sockel für die
Hauptplatine.
Deswegen denke ich ja auch dass es gehen müsste.
Fritz, ich habe den Eindruck, Du weißt nicht wirklich, wovon Du redest.
Anstatt den ultimativen Maxi-AVR nachbilden zu wollen, solltest Du Dir
einfach einen AVR ausgucken, der für das jeweilige Projekt geeignet ist,
Dich mit seiner Hardware (Features) vertraut machen und mit der Arbeit
beginnen.
Da die AVRs sehr unterschiedlich ausgestattet sind, ist es (bei
effizienter hardwarenaher Programmierung unter Nutzung der verfügbaren
Hardwarefeatures) eh nicht möglich, universellen (portierbaren) Code zu
schreiben, der auf allen AVRs optimal läuft.
Wenn Du nur eine Plattform suchst, die mit mehreren AVR-Typen umgehen
kann, dann schau Dir das STK500 (und seine Aufsetzplatinen) an.
Achja, die Hardwarefeatures sind so unterschiedlich, dass man auch
nichtmal jeden kleinen AVR durch einen großen AVR ersetzen kann. Siehe
PLL bei einigen Tinys. "Viel hilft viel" klappt nicht immer. Weniger ist
manchmal mehr...
...
>Eben nur ein gemeinsamer Sockel für die Hauptplatine.
Gibbet schon. Die Dinger sitzen auf dem STK500 drauf...
Und die Adapterplatinen nennen sich STK50x (x>=1)...
Dann machs doch einfach...
Ansonsten guck dir mal ein STK-500 an. Da gibts auch keinen
Universalsockel.
Andererseits, so eine Sammlung Relais die sich um einen AVR versammelt
würd schon lustig aussehn.
Viel Aufwand, wenig Nutzen...
Also so schlecht find ich die Idee gar nicht, wenn du sagst das so was
für dich hilfreich ist dann will ich das auch nicht anzweifeln, also mal
konkret:
Im Prinzip ist das ST500 ja auch so aufgebaut (nur eben etwas
beschränkt).
Problem sind hier eben die mehrfach belegten IO Pins.
Also ich würd das etwa so machen:
Auf den einen Steckverbinder die Ports als
Pin 1- 8 Port A
Pin 9- 16 PortB
...
und auf den anderen nacheinander die Sonderfunktionen, also z.B.
Pin 1 - UART RxD0
Pin 2 - UART TxD1
...
Zum Thema umschalten:
-Jumper: 3-Reihige Stifteleisten, Mitte AVR, Rechts Port, Links
Sonderfunktion
-Dipschalter, gibts auch in SMD
-Lötbrücken (etwas unflexibel)
-Programmierbare Logic, mit Konfigprogramm am PC, ziemlich aufwändig +
Probleme mit Analogen Signalen
Wenn sie Größe nicht so ganz entscheidend ist würd ich das ganze mit
2,54mm Stifteleisten und Jumpern realisiern, ist wohl am einfachsten und
billigsten. Von z.B. Samtech gibt es auch SMD Steckverbinder mit hoher
Polzahl und Packungsdichte, da kommt man glaub ich auch an kleine
Stückzahlen. Als alternative wenn die das sonst alles zu groß wird.
ABu
Fritz wrote:
> z.B. Mega 8>> PC5 (ADC5/SCL)>> auf SCL programmiert
So und damit hast Du schon ein riesen Problem, SCL ist nämlich
bidirektional.
Woher soll nun der CPLD die Information für die Richtungsumschaltung
nehmen ?
Du mußt also nur das Gehäuse des AVR aufschleifen und die internen
Signale des HW-I2C zum CPLD führen.
Peter
@ABu: im Prinzip ist es das was Du beschreibst.
Jedoch sind Stifteisten mit Jumper sehr platzraubend.
Ist dann eine programmierbare Logik oder digitale Schalter zu
bevorzugen?
Welche Logikbausteine kommen denn mit analogen Signalen zurecht?
Oder welche Möglichkeit könnte man für diese Pins des AVRs nutzen?
Gruß und danke für das rege Interesse
Sorry etwas unglücklich ausgedrückt.
Meinte wenn ich für die rein digitalen Signale die Logikbausteine
verwende, wie dann am besten mit den analogen SIgnalen umzugehen ist.
Fritz wrote:
> Sorry etwas unglücklich ausgedrückt.> Meinte wenn ich für die rein digitalen Signale die Logikbausteine> verwende, wie dann am besten mit den analogen SIgnalen umzugehen ist.
Fang doch mal an, darüber nachzudenken, wie Du mit den
Stromversorgungs-Leitungen umgehen willst. Wie ja allgemein bekannt ist,
braucht jeder Stromversorgungsanschluss seinen Abblock-Kondensator
direkt an den Stromversorgungspins. Aufgrund der unterschiedlichen
Pinouts kommst Du da auf keinen gemeinsamen Nenner. Was meinst Du, warum
das STK500 8 verschiedene Sockel für AVRs im DIL-Gehäuse hat? Und dabei
unterstützt es (ohne Aufsatzplatinen) noch nichtmal alle DIL-AVRs.
> Kein Mensch hält sich in der Regel so viele verschiedene Controller auf> Lager.
Ich halte mir die Controller "auf Lager", mit denen ich arbeiten möchte
und kann. Und einen "Universal-AVR" gibt es nicht, einige kleine AVRs
haben Features, die die Großen nicht haben. Wenn Du es nicht glaubst,
dann vergleiche die Datenblätter (aber nicht nur die Überschriften!).
...
