Hallo zusammen, im Rahmen der Vorlesungen habe ich ein großes Interesse für die technische Informatik entwickelt und würde gerne im Selbststudium meine Erkenntnisse diesbezüglich vertiefen. Ich habe jedoch bisher nur die theoretischen Grundlagen erworben, das heißt an technischen Grundlagen mangelt es! Ich habe mit vorgenommen, GAL Bausteine (22V10 von Lattice) zu programmieren. Habe auch 4 ICs und bereits einen GAL Assembler auf einem Debian Betriebssystem. Weiß auch schon, wie der funktioniert, kompiliert und Daten auf einen GAL lädt. Meine Frage ist hier: Ich habe nun diese 4 nackten ICs in der Hand. Ich nehme an, die müssen auf eine Steckplatine zusammen mit anderen Komponenten (wie etwa LED Leuchten, Taster, Schalter, 7-Segment-Anzeigen, ...). Wie kann ich das bewerkstelligen? Mit welcher Art Kabel verbinde ich meinen Rechner mit der Platine? Brauch ich einen extra Programmer? (was auch immer das ist...) Ihr seht schon, ich bin etwas durcheinander. Im Internet habe ich leider keine (wirklich verständliche oder brauchbare) Anleitung gefunden. Ich hoffe das hier ist keines der eher sinnlosen oder dämlichen Forenbeiträge. Danke für Euer Verständnis und Beste Grüße
Thomas Berner schrieb: > Brauch ich einen extra Programmer? Naja, auf irgendeine magische Weise wirst Du dem GAL schon mitteilen müssen, was es tun soll. Ein bisschen widerspricht das dieser Aussage hier: > Weiß auch schon, wie der (...) Daten auf einen GAL lädt.
Thomas Berner schrieb: > die müssen auf eine Steckplatine zusammen mit anderen > Komponenten (wie etwa LED Leuchten, Taster, Schalter, > 7-Segment-Anzeigen, ...) Bist du sicher, dass du da in der Abteilung GAL richtig bist? Das sind keine Prozessoren, die ein Programm ausführen, sondern Logikbausteine wie 74er TTL oder CMOS Gatter, nur mehr davon in einem Chip. Ich frage, weil du von Tastern, Anzeigen usw. schreibst, das ist eher das übliche für Prozessorsysteme. So oder so, zuerst musst du dir einen Zweck ausdenken, was soll das fertige Gerät tun - zählen, messen, Daten senden und/oder empfangen usw. Dann kannst du dir überlegen wie und mit welchen Mitteln. Georg
Thomas Berner schrieb: > wie etwa LED Leuchten, Taster, Schalter, 7-Segment-Anzeigen, ...). Wie > kann ich das bewerkstelligen? Entweder ein GAL Development Board http://www.sh-elektronik.de/produkte/ispgds.html oder ein Steckbrett in das du die Bauteile selbst steckst https://www.projektlabor.tu-berlin.de/menue/onlinekurs/testaufbau/wie_funktioniert_ein_steckbrett/ > Mit welcher Art Kabel verbinde ich meinen > Rechner mit der Platine? Wenn er noch ein LPT Parallelport hat: Mit einem alten Druckerkabel oder Flachbandkabel. Bei USB siehts schwieriger aus. > Brauch ich einen extra Programmer? (was auch > immer das ist...) Ja, brauchst du, http://www.armory.com/~rstevew/Public/Pgmrs/GAL/_ClikMe1st.htm oder einen Universalprogrammer wie GALEP oder ALL03.
Hallo nochmal, dass ich weiß, wie Daten auf den GAL kommen, bezog sich auf die Software. Ich weiß, welche Befehle ich in meinen Liux Terminal reinhacken muss, dass des Ding, vorausgesetzt, es hängt am Rechner, meinen Code annimmt. Softwaretechnisch brauch ich also nicht mehr viel zu machen. Mit dem Programmieren des GALs würde ich gerne Kenntnisse bzgl. kombinatorischer Logik erweitern. Ich will also keinen Assembler Code schreiben, sondern dem GAL mitteilen, welche Pins er wie verknüpfen soll (mittels DNF). Taster und Lämpchen dienen dazu, dass ich auch ein Resultat sehen will. Hauptsächlich soll es einfach kleinen Spielereien dienen. Ansteuerung eines Segments oder ein Code Schloss oder ähnliches. Einfach um rum zu probieren. Grüße Nachtrag: Das Angebot von SH-Elektronik habe ich auch schon entdeckt, ist jedoch nicht mehr aktuell. Nur den Assembler haben sie noch. Danke trotzdem.
:
Bearbeitet durch User
Hallo Thomas. Thomas Berner schrieb: > Meine Frage ist hier: Ich habe nun diese 4 nackten ICs in der Hand. Ich > nehme an, die müssen auf eine Steckplatine zusammen mit anderen > Komponenten (wie etwa LED Leuchten, Taster, Schalter, > 7-Segment-Anzeigen, ...). Wie kann ich das bewerkstelligen? Auf eine Steckplatine? Würd ich Stecken. Mit welcher > Art Kabel verbinde ich meinen Rechner mit der Platine? Um GALs/PAls zu prgrammieren brauchst Du einen Programmer mit dem Du die GALs außerhalb der Platine programmierst. InSystemProgramming ist nicht. Brauch ich einen > extra Programmer? (was auch immer das ist...) > > Ihr seht schon, ich bin etwas durcheinander. Nein, worst case hast Du noch keine Ahnung, Best Case fehlt Dir noch 'ne Menge Wissen. Was du in ein 16V8 reinbekommst ist etwa ein 8-bit Zähler mit ein bischen Sonderfunktionen Thomas Berner schrieb: > Ich weiß, welche Befehle ich in meinen Liux Terminal > reinhacken muss, dass des Ding, vorausgesetzt, es hängt am Rechner, > meinen Code annimmt. Softwaretechnisch brauch ich also nicht mehr viel > zu machen. Um ein GAL zu programmieren brauchst Du so etwas wie einen Assembler, einen PALASM z.B. Dem gibst Du ein Sourcefile und der macht ein Bin/Hex-file zum Prgrammieren des GALs. ImSourcefile steht dann die LOGIK die Du im GAL haben willst. Z.B. einen Decoder oder eine Zähler oder ... Thomas Berner schrieb: > Taster und Lämpchen dienen dazu, dass ich auch ein Resultat sehen will. > Hauptsächlich soll es einfach kleinen Spielereien dienen. Ansteuerung > eines Segments oder ein Code Schloss oder ähnliches. Einfach um rum zu > probieren. Für die 7 Segmente eine Decoders brauchts Du dann so ein GAL. Wenn Du wirklich Logik in größerer Komplexität implementieren willst, lerne VHDL und arbeite mit CPLDs oder LogikArrays. GALs waren seinerzeit - so vor 20Jahren - gut und sauschnell für Adressdecoder und kleine GlueLogic. Heute sind sie antiquiert. rgds
6A66 schrieb: > Um GALs/PAls zu prgrammieren brauchst Du einen Programmer mit dem Du die > GALs außerhalb der Platine programmierst. InSystemProgramming ist nicht. Wenn es sich aber um ispGALs handelt? Thomas: Die Teile sind wirklich nicht mehr aktuell. Vor "einigen" Jahren habe ich mal eine Software geschrieben mit der unsere Studenten die ersten Versuche mit einfachster programmierbarer Logik ( ispGAL22v10 ;-) machen konnten. Die "Entwicklungssoftware" (leider Windows) besteht aus einer graphischen Darstellung der Matrix und der konfigurierbaren Logikzellen. Durch simples Anklicken mit der Maus kann man Verbindungen einfügen oder löschen und die Ausgangszellen konfigurieren. Die Grundlage dafür waren mittels KV-Diagrammen per Hand optimierte Gleichungen ;-) Aus der Matrix kann man aber auch ein Jedec File erstellen oder auch Jedec Files, die von einem Assembler generiert wurden, einlesen und darstellen. Die Programmierung des PLDs erfolgt dann aus der Matrix über USB. (ein PIC18F4550 als HID) Wenn es dich wirklich interessiert und dich keiner überzeugen kann etwas aktuelleres zu nehmen, kann ich am Montag mal schauen ...
:
Bearbeitet durch User
Carsten R. schrieb im Beitrag #3991324: > Für gewöhnlich sind die Dinger nur einmal beschreibbar, dank > Antifuse-Technik. Wenn man von GALs keine Ahnung hat, einfach mal... Volker SchK schrieb: > Die Teile sind wirklich nicht mehr aktuell Nun ja, wenn man nicht mehr braucht, als in ein GAL passt, braucht man kein grösseres CPLD (mehrere GALs in einem Gehäuse), und Atmel stellt die alle noch her (Lattice nicht mehr). http://www.atmel.com/products/Other/spld-cpld/spld-industry_standard.aspx
Darum habe ich den Beitrag nach einer Minute zurückgzogen weil ich das mit PAL vertauscht habe. GAL ist eine wiederbeschreibbare Sonderform von PAL, abgesehen davon sehr ähnlich. Typisch MaWin, Du wartest nur darauf daß ich einmal einen Buchstaben flüchtig vertausche und schon bist du da und pöbelst herum. Ein Flüchtigkeitsfehler von mir der nach einer Minute bereits korrigiert wurde und Du bist schon da um darauf herumzureiten. Was sagt das über dich aus?! MaWin schrieb: > Wenn man von GALs keine Ahnung hat, einfach mal... Völlig anmaßend, typisch von Dir. Aus !einem! Buchstaben diesen Schwachsinn an den Haaren herbeizuziehen entspricht mal wieder völlig deinem Stil, ebenso der Ton. @ Thomas Berner: Welche Variante hast Du den genau? Es gibt die Dinger in elektrisch löschbar und welche die per UV-Licht gelöscht werden. Ich gehe davon aus daß es Erstere sind.
:
Bearbeitet durch User
Carsten R. schrieb: > typisch von Dir. Typisch von dir ist, daß du was schreibst, was einfach falsch ist, weil du vor dem Schreiben nicht das Gehirn einschaltest, mal nachschlägst, dir Mühe gibst, und so andere Leser in die Irre leitest. Pflaum nicht die an, die dich korrigieren müssen, du weisst, daß du selbst das Problem bist.
Für einen umgehend korrigierten falschen Buchstaben... Ich leite niemanden in die Irre! Wenn mal was falsch ist korrigiere ich es auch, im Gegensatz zu Dir wie jeder weiß der Dich kennt. Der Ton macht die Musik.
Hallo zusammen, danke schonmal für die vielen Antworten. Und ja: Ich weiß, dass ich mit CPLDs viel mehr machen könnte. Ich hatte mir auch schon FPGA Starter Kits von Xilinx angesehen, bis mich meine Kommilitonen davon abhielten, als sie hörten, welch einfache Dinge ich vorhatte grins Tatsächlich will ich nichts wirklich sinnvolles mit dem Zeug unternehmen, sondern nur "spielen" und dabei dazu lernen. Ich weiß, dass ich da pure Logik reinprogrammiere. Sieht dann ungefähr so aus: PIN 1 x PIN 2 y PIN 17 z z = x * y # Kommentar... Anklickbare Tools finde ich jetzt nicht wirklich reizvoll. Ich bin bereits davon ausgegangen, dass ich ein Steckbrett zusammenstellen muss. Nur welche Bauteile sind dafür nötig? Wenn es elektrotechnisch wird, betrete ich mit unbekanntes und unvertrautes Terrain... Ich habe hier vor mir 4 GAL Bausteine: 1. GAL22V10D 25LP D208JJ08 2. GAL22V10D 25LP D004J17 3. P9306 GAL22V10 25LNC 4. P9252 GAL22V10 25LNC Viele Grüße
Thomas Berner schrieb: > Nachtrag: Das Angebot von SH-Elektronik habe ich auch schon entdeckt, > ist jedoch nicht mehr aktuell. Es gibt auch keine Hersteller von GALs mehr. Das sollte dir unbedingt zu denken geben.. Thomas Berner schrieb: > Tatsächlich will ich nichts wirklich sinnvolles mit dem Zeug > unternehmen, sondern nur "spielen" und dabei dazu lernen. Damn steig in FPGAs ein. Denn das, was du bei GALs "lernst" ist unnötiges Wissen, weil GALs ausgestorben und aktuelle Designprozesse für CPLDs und FPGAs komplett anders sind. > Trotzdem will ich... Wenn du "Kommilitonen" schreibt, dann solltest du inzwischen schon abschätzen können, dass "Ich will!" keine geeignete Lernstrategie ist... Kurz: kauf dir für 50Euro ein FPGA-Evalboard. Da ist dann sogar der Programmer drauf, du kannst gleich richtig loslegen und lernst Zeug, das du auch in 10 Jahren noch verwenden kannst...
Hallo zusammen, mir ist klar, dass GALs am aussterben (oder bereits tot) sind. VHDL ist etwas, womit ich mir Zeit lassen wollte. Ich wollte zuerst etwas weiter auf Gatterebene hinab. Ich merke schon, dass es nicht besonders intelligent ist, mit GALs zu probieren. Vielleicht hole ich mir einfach einen Mikrocontroller und versuche mich da ein wenig. Mal sehen... Viele Grüße
Thomas Berner schrieb: > VHDL ist etwas, womit ich mir Zeit lassen wollte. Ich wollte zuerst > etwas weiter auf Gatterebene hinab. Du bist mit VHDL näher an den "Gattern", als so mancher denkt. Und der Einstieg ist auch nicht allzu kompliziert. Auf jeden Fall wesentlich unkomplizierter, als heute mit (lauter unterschiedlichen) GALs anzufangen. Sieh dir das mal kurz an: http://www.lothar-miller.de/s9y/archives/80-Hello-World!.html > Vielleicht hole ich mir einfach einen Mikrocontroller und versuche mich > da ein wenig. Das ist auf alle Fälle sinnvoller, denn dort baust du sogar mit einem alten Urgestein wie den 8051 Wissen auf, das du leicht auf aktuelle uC übertragen kannst.
:
Bearbeitet durch Moderator
Thomas Berner schrieb: > Anklickbare Tools finde ich jetzt nicht wirklich reizvoll. Ooooohhhhh, und ich war mal so stolz darauf ;-) Das war allerunterste Ebene. Eine Darstellung wie auf Seite 5 in diesem Datenblatt: http://www.latticesemi.com/~/media/Documents/DataSheets/GAL/ispGAL22V10DataSheet.PDF Klicken kann man auf die Kreutzungspunkte und die OLMCs um Verbindungen zu setzen oder Konfigurationen der OLMCs durch zu schalten.
Hallo, also ich bin immer gut mit MaWin's Programmer Galblast gefahren. Hat einwandfrei funktioniert und konnte eben auch GAL6002. Danke MaWin! Ist eben schon eine Weile her. Das Teil ist aber auch nicht ganz unkompliziert wegen der notwendigen Anpassung der Höhe der Programmierspannung. Das ist aber notwendig lt. Programmiervorschrift, die man nur manchmal von Lattice bekommen hat, als das Zeug alles schon veraltet war. :-) Beste Programmierumgebung für mich war damals WIN98 und die Software ispLever von Lattice. ispLever (wenn ich mich nicht irre) lief ein Jahr. Den Freischaltcode gab es aber unproblematisch immer wieder von Lattice per email. Ist lange her.... Grüße
Die GALs sind am Aussterben, nur Atmel stellt die noch her. Ein ATF22V10 enthält 10 FFs, damit kann man keine großen Sprünge machen. Nimm wenigstens CPLDs. Ein Xilinx XC9572 enthält 72 FFs und ist noch im handlichen PLCC-44 Format. Bis Windows-XP konnte man die noch direkt vom (echten) LPT aus programmieren.
JK schrieb: > ispLever (wenn ich mich nicht irre) lief ein Jahr. Den Freischaltcode > gab es aber unproblematisch immer wieder von Lattice per email. So unproblematisch ging das leider nicht, die sind so paranoid mit ihrer Software wie andere auch, obwohl das bei einem kostenlosen Tool komplett sinnlos ist. Ich habe Lattice daher gelöscht, nachdem es nach dem 1. Jahr Probleme gab und nach dem 2. die Software selbst meldete, eine Verlängerung der Lizenz könnte nicht mehr angefordert werden. Was ich aber besonders unverschämt fand, vom Moment des Ablaufens an kann man auf die eigenen Projekte überhaupt nicht mehr zugreifen, auch nicht nur lesend, um nach nachzuschauen, was da genau programmiert wurde. Also seit gewarnt, mit mehr als 1 Jahr kann man nicht sicher rechnen. Übrigens, für die alten GALS, die vielleicht noch gepflegt werden müssen, habe ich nach Jahren den guten alten PALASM wieder installiert. Die Tools von Lattice, Altera usw. unterstützen sie inzwischen nicht mehr. Georg
Georg schrieb: > So unproblematisch ging das leider nicht ... Bei mir schon. Hatte eigentlich nie ein Problem. (mit den Lizenzen) Ich denke die Lizenz Geschichte kommt auch hauptsächlich von den verwendeten Tools anderer Firmen. Es bestand allerdings immer ein gewisser Zwang neuere Versionen zu installieren. Ich nehme mal an die hatten einfach keine Lust ewig uralte Versionen zu supporten. Neuere Tools wie Diamond, welches ispLever bei den nicht ganz kleinen CPLDs abgelöst haben, bieten meist eine Importfunktion für die alten Projekte. Wenn das nicht klappt, dann muss man das Projekt eben aus den alten Sourcen neu zusammenbasteln :-(
Richtig, moderne Tools kann man nicht nehmen, und alte Tools laufen dank Microsofts Schrottberübssystemen nicht auf neuen Rechnern, also braucht mal alte Rechner mit alter Software, auch wegen Parellelport etc. ispSynarioStarter von Lattice (auf CD vom Buch Schaltungstechnik mit GALs von Franzis) konnte alle GALs und ist unbegrenzt lizensiert.
MaWin schrieb: > alte Tools laufen dank > Microsofts Schrottberübssystemen nicht auf neuen Rechnern Der gute alte PALASM4 läuft bei mir noch unter Vista, moderneres habe ich noch nicht probiert, aber da es sich um reine Datenverarbeitung ohne I/O handelt, kommt er notfalls in eine virtuelle Maschine. Man muss nur die 8.3-Dateinamen beachten. Georg
Selbst die Ansteuerung des Frickelports durch DOS-Programme ist unter Windows 8.1 x64 nach wie vor möglich, wie ich anhand eines EPROM-Programmiergerätes hier Beitrag "[Anleitung] DOS-Parallelport-EPROMer unter Windows 8.1 (x64)" beschrieben habe.
Georg schrieb: > Die Tools von Lattice, Altera usw. unterstützen sie inzwischen nicht > mehr. Dann nimm CUPL von Atmel.
Hallo zusammen, okay, bevor dieser Thread etwas ausartet, vielleicht noch die abschließende Frage: Was fange ich jetzt mit den 4 GAL ICs an, wenn nicht programmieren? Die liegen jetzt in ESD Schaumstoff in der Schublade. Ich werde fürs Erste vermutlich mit einem AVR Mikrocontroller anfangen. Danke trotzdem für die vielen Hilfen. Vielleicht kann ich ja eines Tages einen GAL im Mokrocontroller simulieren... wenn die Zeit reif genug dafür ist... Beste Grüße
Thomas Berner schrieb: > Was fange ich jetzt mit den 4 GAL ICs an, wenn > nicht programmieren? Die liegen jetzt in ESD Schaumstoff in der > Schublade. Das selbe, was ich mit ein paar Dutzend 2708, 2716 und 2732 EPROM's mache - reifen lassen! :-)
Als 1993 Atmel die Flash-8051 rausbrachte, haben sie im Datenblatt ausführlich den Programmieralgorithmus offengelegt. Ich hab mir daraufhin ein Programmiergerät selber gebastelt. Für die GAL, PALCE, ATF usw. ist es aber schwierig daran zu kommen.
Thomas Berner schrieb: > Was fange ich jetzt mit den 4 GAL ICs an, wenn > nicht programmieren? Was hindert dich jetzt dran, sie zu programmieren ? Du hast genug Infos bekommen wie das geht. Ob du nun einen 7-Segment-Decoder in einen brennst, eine Ampelsteuerschaltung in den anderen (der dazu einen Taktgeber braucht, NE555) oder einen schnellen Adressdecoder für einen zu bauenden Computer, liegt doch bloss an deiner Phantasie (und ggf. konkreten Aufgaben). Übrigens kennt GALBlast noch keine 22V10D, bei der Gelegenheit könnte man also gucken ob er damit klar kommt, vermutlich haben die eine andere ID und sind sonst wie 22V10C.
Thomas Berner schrieb: > Ich habe mit vorgenommen, GAL Bausteine (22V10 von Lattice) zu > programmieren. Habe auch 4 ICs und bereits einen GAL Assembler auf einem > Debian Betriebssystem. Weiß auch schon, wie der funktioniert, kompiliert > und Daten auf einen GAL lädt. Soso. Du weißt also bereits alles. Also: Ein GAL-Assembler kompiliert nicht, sondern assembliert. Das ist was dezent ANDERES - und Daten auf ein GAL lädt der gewiß nicht. Dazu brauchst du einen GAL-Brenner und den hast du vermutlich nicht. Die Algorithmen wurden damals nicht offengelegt und ich bekam auf meine Anfragen lediglich "you shold buy a quality programmer form DataIO". Ea gab mal einen GAL-Brenner von der C'T, als iese noch ne ernstzunehmende Gazette war, aber mit den späteren PALCE's konnte der auch nix anfangen. Also: verabschiede dich lieber von deinen 4 Gals und wende dich anderen Gefilden zu. Wenn du unbedingt was programmieren willst, dann arbeite dich in irgend einen verdammten Mikrocontroller ein. Welcher ist fast egal. Und wenn du irgend welche wirklich schnellen Dinge machen willst, die man mit nem µC nicht hinbekommt, dann ist ein CPLD angesagt. Und wenn es dabei noch komplexer werden soll, dann ein FPGA. Aber das sind für dich alles Sphärenklänge, von denen du noch meilenweit entfernt bist. Also lies für den Anfang. Das kostet nix und bildet. Gut Nacht. W.S.
Thomas Berner schrieb: > Was fange ich jetzt mit den 4 GAL ICs an Ein Nachteil, der hier noch garnicht erwähnt wurde: ein 22V10 braucht 55 bis 140 mA bei 5 V, das ist wahrscheinlich mehr als alle deine Elektronikbasteleien der nächsten Jahre zusammen. Einer der Gründe, warum es die Dinger nicht mehr gibt. Georg
Georg schrieb: > Ein Nachteil, der hier noch garnicht erwähnt wurde: ein 22V10 braucht 55 > bis 140 mA bei 5 V Es gab mal die Z-Serie, da hatte jeder Ein-/Ausgang ein CMOS-Latch. Die Eingangslatche waren über ein großes EXOR mit den Eingängen verknüpft. Sobald ein Eingang sich änderte, wachte er auf, machte die Logik und ging wieder schlafen. Statisch brauchten die nur wenige µA. Und von Philips gabs die Coolrunner CPLDs, die waren echt CMOS. Die hat dann Xilinx übernommen, dann von 5V auf 3,3V runtergesetzt, dann auf 2,5V und aktuell nur noch 1,8V. Sind also nicht mehr gut für Bastler geeignet. Ach das waren noch Zeiten, wo ich den Fitter auf nem 166MHz Pentium die Nacht über durchrechnen lassen mußte.
Hallo nochmal, das ich alles weiß habe ich nicht behauptet. Klar bin ich kein langjährig studierter und gebildeter Mensch, sondern noch ein Neuling in diesem Gebiet. Lediglich die Theorie kenne ich in den Grundzügen. Entschuldigt also, dass ich irrtümlicherweise von "compilieren" und "laden" gesprochen habe. Ich habe mir fürs Erste nun auch vorgenommen, mich in einen AVR Mikrocontroller einzuarbeiten. Es stimmt, dass ich hier viele Informationen zur GAL Programmierung erhalten habe, danke also zuletzt noch dafür! Die ICs werde ich noch aufheben und vielleicht eines Tages doch noch zusammenstecken und programmieren. Beste Grüße
Hast du zuviel Geld? Der Einstieg mit avr ist viel teurer als bei anderen. Und es gibt die Klinke mit den Fuses. Da stolpern viele Anfänger und es führt unnötig zu Frust.
Immer diese fanatischen Pauschalaussagen -.- Die Fuses sind ein Feature welches man nicht Nutzen muß. Es gibt da ein paar sehr gängige Konfigurationen. Wenn man davon abweicht weil es nötig ist, ist an auch schon soweit de Fuses zu verstehen. Wer vorher mit den Fuses spielt sollte das Datenblatt ebenfalls vorher lesen. Wenn man das Kapitel nicht versteht sollte man nicht damit herumspielen. Kosten: So sehr unterscheiden sich die Plattformen nicht. Für alle gängigen Architekturen gibt es Einstiegslösungen für deutlich unter 50 €, und das ist noch hoch angesetzt. Dabei ist das ist nur ein Aspekt. Dadurch relativieren sich diese Kostendifferenzen die sich in der unter 50 € Klasse noch ergeben können. Bei den im Hobbybereich üblichen Stückzahlen ergeben sich nur geringe Kostendiferenzen. Die sollte man auch mal in Relation zum Zeitaufwand betrachten. Dann kann man auch die letzten paar Euros Differenz hinnehmen und das nehmen womit man gut klar kommt. (Das muß nicht unbedingt dann AVR sein.) Es fährt ja auch nicht jeder 20 Kilometer täglich mit dem Rad zur Arbeit, obwohl es billiger ist. Oft unterschätzt wird der Support und der Wissensaustausch. Ich unterstelle jetzt keine allgemeine Überlegenheit der AVR-Architektur, aber wer sich stark auf dieses Forum stützt fährt hier mit AVR nicht schlecht. Das hängt stark von der hiesigen Community ab. Entscheidend für die Eignung ist natürlich auch die zu lösende Aufgabe. Aber davon wurde hier icht gesprochen, weil noch nicht entschieden ist was damit gemacht werden soll. @Thomas Deine Neuorientierung ist sehr gut. Denn mit einem µC kann man viel machen. Damit verglichen sind die Möglichkeiten von GALs begrenzt. Wenn Du dann mal etwas sogenannte Glue-Logic benötigst erinnere dich an die Schublade. Denn dann bist du in einem Bereich für den die GALs gemacht wurden.
:
Bearbeitet durch User
Carsten R. schrieb: > (Das > muß nicht unbedingt dann AVR sein.) Es fährt ja auch nicht jeder 20 > Kilometer täglich mit dem Rad zur Arbeit, obwohl es billiger ist. Das Lustige ist nur, dass der avr das Fahrrad und trotzdem teurer ist. ;-)
LaunchDisco schrieb: > Carsten R. schrieb: >> (Das >> muß nicht unbedingt dann AVR sein.) Es fährt ja auch nicht jeder 20 >> Kilometer täglich mit dem Rad zur Arbeit, obwohl es billiger ist. > > Das Lustige ist nur, dass der avr das Fahrrad und trotzdem teurer ist. > ;-) Tja, es gibt halt auch Karbonräder :-)
Naja, der AVR hat den Charme, daß er auch in Assembler leicht zu verstehen ist. Z.B. braucht er keine ständigen Bankumschaltungen, wie beim PIC für RAM und IO-Zugriffe. Und der Support ist auch nicht zu verachten. Stell mal hier ne Frage zum AVR und zum PIC/ARM/8051/MSP usw., wirst Du zum AVR deutlich mehr und bessere Antworten bekommen.
Peter Dannegger schrieb: > zum AVR deutlich mehr und bessere Antworten bekommen Hmmmhh, dann wirf einen Blick in vorhanden Beiträge. Zum avr gibt es mehr, aber fast immer die gleichen: Fuses, Fuses, Fuses, ... ;-) Bei den anderen Architekturen sieht es von der Qualität nicht schlechter aus. Die Probleme werden gelöst.
LaunchDisco schrieb: > Zum avr gibt es mehr, aber fast immer die gleichen: Fuses, Fuses, Fuses, > ... ;-) Dann ist es ja kein Problem: es gibt ja nur eine kleine Hand voll. Die passen auf wenige Datenblattseiten.
Lothar Miller schrieb: > LaunchDisco schrieb: >> Zum avr gibt es mehr, aber fast immer die gleichen: Fuses, Fuses, Fuses, >> ... ;-) > Dann ist es ja kein Problem: es gibt ja nur eine kleine Hand voll. Die > passen auf wenige Datenblattseiten. .. und werden von jedem Anfänger nicht verstanden und lenken unnötig ab.
LaunchDisco schrieb: > Der Einstieg mit avr ist viel teurer als bei anderen. Das ist dein erster Beitrag bei mikrocontroller.net, aber musst du gleich so einen Unsinn schreiben ? > Und es gibt die Klinke mit den Fuses. Bei Microchips PIC Prozessoren wohl nicht, LOL. Ja, ich fand damals die 68HC11 auch sehr gut, ran an die serielle Schnittstelle und losprogrammieren, aber die AVR haben sich nicht ohne Grund bei den Hobbyisten so weit verbreitet: Sie sind billig und einfach zu erstehen und einfach handhaben, und gerade in der Form von Arduinos besonders einfach zu handhaben. Da musst du jetzt nicht herkommen, und glauben, der Rest der Welt liegt falsch. Fuses sind das simpelste der Welt, einfacher als Special Function Register. Auch wenn du damit Probleme hast: Andere kommen damit klar. LaunchDiso schrieb: > Na ja, der avr ist eher ein Stahlross. Du widerspricht dir, gerade eben war er noch teuer.
MaWin schrieb: > musst du gleich so einen Unsinn schreiben Nix Blödsinn, vergleich die Preise für die Einsteigerboards und das notwendige Zubehör. MaWin schrieb: > Auch wenn du damit Probleme hast Habe ich nicht, aber die Einsteiger: Lies die Beiträge hier im Forum. MaWin schrieb: > Du widerspricht dir, gerade eben war er noch teuer. Ne, ne, das ist doch gerdae der Punkt: ein teurer Stahlesel. MaWin schrieb: > verbreitet: Sie sind billig und einfach zu erstehen und einfach > handhaben ... im Vergleich mit den anderen angestaubten: Ja Aber heute gibt es noch einfachere und günstigere Lösungen für Einsteiger. Das Rad dreht sich weiter, und irgendwann sind die dann auch nur noch zweite Wahl. ;-) Die Diskussion hatten wir hier schon sehr oft. Das müssen wir nicht wieder durchkauen. Der Hinweis auf Alternativen sollte aber erlaubt sein.
LaunchDisco schrieb: > Der Hinweis auf Alternativen sollte aber erlaubt sein. Du hast keine geliefert, typisch. Du weisst, dass man sie sofort widerlegen könnte.
LaunchDisco schrieb: > Die Probleme werden gelöst. So sieht es nämlich aus. die meisten Dinge hier haben nicht direkt eine AVR-Spezifische Probemstellung, sondern werden nur mit AVR gelöst. Architekturspezifische Probleme sind im Vergleich dazu selten. Bei den Einen hat man einen verhackstückten Speicher, bei den Anderen hat man Fuses und dann hat man... Und dann gibt es noch sehr spezielle Problemchen wie Timingfragen. Dabei ist es dann hilfreich wenn man im richtgen Forum ist. ;-) Bei den Fuses sind es oft die selben Fehler mit den selben Lösungen und dazu gibt es auch hier einen schönen Artiel. http://www.mikrocontroller.net/articles/AVR_Fuses Wer stumpf drauf losklickt ohne sich vorher durchzulesen welche Funktionen man eigentlich benutzt.... Sie sind nur so prominent weil sie separat gesetzt werden und man den Fehler da genau lokalisieren kann. Andere Fehler im Quelltext aufgrund unübersichtlicher Architektur etc. sind nicht so einfach mit einer allgemeinen Kategorie zu benennen. LaunchDisco schrieb: > Das Lustige ist nur, dass der avr das Fahrrad und trotzdem teurer ist. > ;-) Den Zwinkersmilie hab ich zwar gesehen, aber dazu sollte man noch sagen, daß die meisten Mikrocontroller in der Preisklasse eines einfachen Bustickets liegen. Folglich sind die Differenzen die sich ergeben können bei hobbyüblichen Stückzahlen in Euro gesehen minimal, auch wenn es Prozentual anderes suggerieren mag. Diese Preisdifferenzen gehen oftmals im Kotext des jeweiligen Projektes unter, nicht nur weil sie geringfügig sind, sondern auch weil projektspezifische Eignungsvorteile den Unterschied kompensieren können! Sollte dann doch mal eine Vorteil übrig bleiben wird das Thema auch erst bei nennenswerter Stückzahl interessant. Ohne Kontext ist deine Aussage also Substanzlos. Höherpreisige Chips (zweistellig) sind hier thematisch deutlich seltener anzutreffen. Wenn Du dich auf Programmer beziehst, so gibt es für alle Plattformen mal teure und mal billige Produkte. So gesehen ist die Behauptung "teuer" auch hier nicht sinnvoll. Wer höherpreisiges (semi)professionelles Werkzeug anschafft interessiert sich oft aus gutem Grund weniger für diese Einmalkosten. Du nennst ja nicht einmal ein einziges Beispiel für diese leere Behauptung. Bei den hier üblichen Sückzahlen steht die mögliche Preisdifferenz weit, weit, weit hinter der individuellen Handhabarkeit. Wer es anders macht betreibt sehr schnell viel Aufwand bei einem Stundenlohn im ein bis zweistelligen Centbereich.
:
Bearbeitet durch User
Carsten R. schrieb: > Bei den Fuses sind es oft die selben Fehler mit den selben Lösungen Und Keiner stellt sich die Frage, warum die selben Fehler immer wieder gemacht werden?
LaunchDisco schrieb: > Wirf einen Blick auf den Nick. ;-))) Damit spielst Du auf ein sehr spezielles Produkt an, welches auch nicht in jedem Kontet DIE preiswerte Lösung ist. Das ist weder Fisch noch Fleisch. Das sind weder Microcontroller noch Programmer, sondern eine eigene Produktkategorie die auch nicht immer optimal ist ist.
Ein Evaluationboard mit Programmer, Debugger, USB, UART und vielen Erweiterungsmöglichkeiten ist für einen Einsteiger perfekt. Das Steckbrett und viele externe Adapter sind Murks.
Thomas Berner schrieb: > Entschuldigt also, dass ich irrtümlicherweise.. Nein! Du brauchst dich nicht zu entschuldigen und andererseits hat dich auch keiner be-schuldigt. Es ist nur so, daß deine Worte jemandem wie mir klar sagen, daß du vom konkreten Thema noch VIEL ZU WENIG Ahnung hast - und das ist etwas, was du nur selber ändern kannst. Deshalb mein Rat: Lies! GAL's sind theoretisch auch heute noch benutzbar und so viel Strom, wie weiter oben geschrieben wurde, ziehen sie auch nicht. Aber sie sind praktisch den Bach runter gegangen, Historie eben. Du kriegst sie nicht mehr programmiert (also das Jedecfile in's Silizium hineiengebrannt). Irgend eine Quelle (ABEL und so) zum Jedecfile zu übersetzen geht sicherlich noch, aber dann ist Ende angesagt. Das ist das Problem. Und wozu auch? Guck z.B. bei Reichelt, da kriegst du für wenig Geld diverse CPLD's und mit denen kannst du wesentlich mehr anfangen als mit den 4 ollen IC's in deiner Kiste. Meine Präferenz wären die CPLD's von Xilinx, weil man deren freie Entwicklungsumgebung (Webpack) ohne Probleme geladen und betrieben kriegt. Es gibt dafür keinerlei Serial oder Keyfile oder Lizenzfile. Das ist bei allen anderen Anbietern (Altera, Lattice,..) nicht ganz so. Bislang war das bei denen so, daß man ne kostenlose Lizenz zwar kriegt, aber die lief dann nur 1 Jahr oder so und mußte dann erneuert werden. Aber eines noch lege ich dir ans Herz: Gehe in dich und mache dir zu allererst klar, WAS du eigentlich dir als Bastel- Entwicklungsziel stellen willst. Bloß so herumzudaddeln ("ich beschäftige mich mit..") ist albern und eher sinnlos. Einen Zweck, ein Ziel soll es haben und damit soll es auch anfangen. Da kommt vermutlich recht schnell bei heraus, daß so ein Bastelziel eher einen Mikrocontroller nahelegt als ein Stück programmierbare Hardware. Hier geht inzwischen der altbekannte Krieg der Atmel-Anhänger gegen den Rest der Welt los. Deshalb hat es wohl wenig Sinn, diesen Thread weiter zu verfolgen. Mei Rat wäre es in diesem Falle, dich entweder in die Arm-Cortex-Controller einzulesen, wobei ich wieder mal die von NXP bevorzuge, weil deren Doku nicht ganz so verwirrend ist wie die von ST oder Nuvoton. Oder du beliest dich erstmal mit den ganz kleinen PIC16Fxxx von MicroChip, um die Grundlagen der Mikrocontroller zu verstehen. Für alles Weitere braucht es in jedem Falle Hardware, die gekauft oder gebastelt sein will. Deshalb (noch einmal) zuerst eines: LESEN. W.S.
LaunchDisco schrieb: > Und Keiner stellt sich die Frage, warum die selben Fehler immer wieder > gemacht werden? Weil die Antwort schon unzählige Male kam, so auch hier. Und diesen konkreten Fehler macht man auch nur ein oder zwei mal. Es ist ein klassischer Amateur- / Grundsatzfehler dem man sonst auch im Quelltext begegnet, nur dort nicht mit einem einzelnen Wort so einfach zu benennen. Bevor man eine Funktion nutzt sollte man lesen was sie macht. Diesen Fehlertyp begehen auch die Nicht-AVR-Einsteiger und kostet sie auch viel Zeit, aber sie haben dafür kein so prominentes und eigentlich auch unpassendes Schlagwort. Eine weiterere Eigenat besteht darin daß diese spezielle Inkarnation des "Ich lese keine Dokumentation"-Fehlers in der Regel ein äußerst einfaches Muster hat, schnell identifiziert wird und nach eindeutigem Schema behoben wird. Darum sind betreffende Threads meistens eher kurz. Fuses sind nicht das Problem, sondern im Kotext Fehler nur ein Indikator für ungeduldige und unsystematische Arbeit! Das ist etwas dem sich jeder mit Disziplin stellen muß, wenn er sinnvoll im Hard- und/oder Softwarebereich produktiv sein will. Jeder der ohne system arbeitet wird damit Probleme bekommen, nur wird er sie oft anders benennen, wenn er überhaupt ein Muster erkennt. Ich will die Probleme mit Fuses nicht als Feature darstellen. Sie sind was sie sind, eine von mehreren möglichen Implentierungsvariante bestimmter Features. Aber sie verursachen keine Probleme. Es fällt dort nur immer wieder auf daß man ein anderes Grundsatzproblem in der Arbeitsweise hat. Wer das nicht einsieht hat ein Verständnisproblem und wird sich schwer tun seine Arbeitsweise den allgemeinen Notwendigkeiten auf diesem Gebiet anzupassen. Man fliegt bei Fuses unter Umständen früher auf die Nase, aber dafür auf übersichtlichem Terrain. Die Anzahl der Problemchen bei der Realisierung steigt dadurch nicht notwendigerweise. Vielleicht setzt dann auch der Lerneffekt früher ein. ;-) Ohne Disziplin, Systematik und dem Lesen der Dokumentation wird man mit der Mehode Versuch macht Klug einen überdurchschnittlichen Teil der Arbeit auf die Fehlersuche verwenden müssen.
Carsten R. schrieb: > Ich will die Probleme mit Fuses nicht als Feature darstellen. Doch, das ist der Inhalt des Beitrags. :-( W.S. schrieb: > Krieg der Atmel-Anhänger avr ist Atmel, aber Atmel hat viel mehr als avr! Die haben auch moderne Sachen. ;-)
LaunchDisco schrieb: > Ein Evaluationboard mit Programmer, Debugger, USB, UART und vielen > Erweiterungsmöglichkeiten ist für einen Einsteiger perfekt. Das > Steckbrett und viele externe Adapter sind Murks. Jetzt drehe ich den Spieß mal um. :P Hast Du zuviel Geld daß du jedesmal ein Evaluationsboard, wenn auch relativ günstig, besorgst, anstatt auf deinem projektspezifischen Peripherieträger den Platz vorzusehen um einfach nur den programmierten Controller draufzusetzen? Mit den Dingern bist du in einer ähnlichen Sparte wie Arduino unterwegs. Und ja, sie haben auch ihren Markt und ihre Berechtigung. Ja, sie sind billiger als Arduino. Dafür gibt es dort Shields, ein Konzept daß wohl ausreichend überzeugend ist für seinen Zielmarkt, daß es zunehmend Verbreitung findet. Falls es noch nicht bei den Discos angekommen ist wird das vermutlich in absehbarer Zeit kommen. Es kommt halt darauf an was man damit machen will und welche Strategie man dafür fährt. Macht man alles selbst oder ist man eher der Lego-Typ etc.
LaunchDisco schrieb: > Carsten R. schrieb: >> Ich will die Probleme mit Fuses nicht als Feature darstellen. > > Doch, das ist der Inhalt des Beitrags. :-( Nein! Das ist auch sehr, sehr deutlich herauszulesen in den Sätzen unmittelbar um jenes Zitat herum. Carsten R. schrieb: > Fuses sind nicht das Problem, sondern im Kotext Fehler nur ein Indikator > für ungeduldige und unsystematische Arbeit! Carsten R. schrieb: > Aber sie verursachen keine Probleme. Es fällt > dort nur immer wieder auf daß man ein anderes Grundsatzproblem in der > Arbeitsweise hat. Wer Funktionen benutzt die er nicht kennt, weil er die Dokumentation nicht liest, wird nicht immer das bekommen was er erwartet. Der wesentliche unterschied besteht darin daß die Fuses einen eigenen Namen haben. Wenn ich auf einem Discovery arbeite und eine lib nutze die ich nicht kenne und ch weigere die Doku zu lesen, schimpfe ich auch nicht auf STM. Und wenn doch, wird sich in ein paar Wochen kaum einer an den Speziellen Namen jener lib erinnern. Hier wird ja auch nur Fuses geschrien ohne zu ewähnen bei welchen Fuses welche Fehler mit welchen aAuswirkugen gemacht werden.
:
Bearbeitet durch User
Carsten R. schrieb: > Hast Du zuviel Geld daß du jedesmal ein Evaluationsboard, wenn auch > relativ günstig, besorgst, anstatt auf deinem projektspezifischen > Peripherieträger den Platz vorzusehen um einfach nur den programmierten > Controller draufzusetzen? Hhhääää? Zum Einstieg nimmt man das Evaluationboard. In den Porjekten gehört der Chip ins Design. Das hat aber mit der Art des µC nichts zu tun. :-((( Die modernen Evaluationboards können aber als Programmer und Debuginterface genutzt werden. Beim avr zückst dafür wieder ein paar Scheinchen. :-((( Carsten R. schrieb: >> Doch, das ist der Inhalt des Beitrags. :-( > Nein! Doch, genauso liest es sich. Aber egal, wie du es begründest, die Einsteiger machen immer die gleichen Fehler und das ist unnötig!
LaunchDisco schrieb: > Ein Evaluationboard mit Programmer, Debugger, USB, UART und vielen > Erweiterungsmöglichkeiten ist für einen Einsteiger perfekt. Das > Steckbrett und viele externe Adapter sind Murks. Mein Gott wie peinlich. Du hast nicht im geringsten verstanden, warum sich AVRs unter Hobbyisten so etabliert haben. Die löten ungern BGA ein. Von 475 ArmM4 uC hat STM keinen in DIL und kaum ein Eval-Board welches in ein Steckbrett passt. Während die alte Methode AVR zu programmieren, mit einer handvoll Kabeln vom Parallelport, heute mangels Parallelport oft nicht mehr geht, haben sich Arduinos durchgesetzt über USB, zu chinesischen Preise unterbieten sie die STM Eval Boards. Und mit fuses hat man da auch nichts zu tun, und die Programmier-Libraries sind kindereinfach. Immer wenn du dich wundern magst, warum andere nicht dasselbe gut finden wie du, solltest du merken, dass du offenbar nicht genug um die Entscheidung der Anderen zu verstehen.
MaWin schrieb: > Die löten ungern BGA ein. Dann nimm doch DIL oder SO. Man, bist du peinlich. ;-) MaWin schrieb: > Während die alte Methode AVR zu programmieren, mit einer handvoll Kabeln > vom Parallelport, heute mangels Parallelport oft nicht mehr geht Aha, alt und verstaubt, da sind wir uns jetzt einig. MaWin schrieb: > haben > sich Arduinos durchgesetzt avr ist jetzt nur noch Arduinos? Gleich wird es spannend. Ich hole mir jetzt Popcorn und Cola. Bei Arduino lernt man aber nicht viel über µCs. Nimm doch gleich Lego Mindstorms. ;-)
Eine Diskussion mit Missionaren ist sinnlos, denn sie wollen nicht verstehen.
LaunchDisco schrieb: > Aber egal, wie du es begründest, die Einsteiger machen immer die > gleichen Fehler und das ist unnötig! Und die armen Einsteiger auf ARM erst, die vergessen die richtige Clock zu aktivieren, einen falschen Teiler einstellen und ähnliches... sowas von unnötig :(
Hallo nochmal, dieser Thread ist ein kleines Bisschen entartet :/ Die GALs werde ich wohl fürs Erste in der Schublade liegen lassen. Ich meine: sie rennen mit ja nicht weg. Wenn die Zeit und meine Muße reif genug für sowas ist, kann ich das immer noch anpacken. Fürs erste werde ich mich in Mikrocontroller einarbeiten. Gibt schließlich viele Tutorials dazu im Netz und Handbücher in der Unibib... Ich nehme mir das bisher geschriebene zu Herzen und bedanke mich vielmals für die Hilfen! Beste Grüße
rüdiger schrieb: > Und die armen Einsteiger auf ARM erst, die vergessen die richtige Clock > zu aktivieren Aber damit sperrt man sich nicht aus. ;-) (ARM ist nur einer der modernen Vertreter.)
LaunchDisco schrieb: > Doch, genauso liest es sich. Das behauptest Du während ich das exakte Gegenteil schreibe, sogar in dem von Dir zitierten Satz. Es ist einfach nur eine relativ spezifische Implementierungsvariante. Nicht mehr und nicht weniger. Ich bevorzuge keine Controllerfamilie, auch wenn ich derzeit AVR nutze. Das liegt aber eher daran, daß alle am Markt befindlichen Lösungen brauchbar sind ohne schwerwiegende Nachteile und ich daher keinen Zwang zum umsatteln habe. Und wenn man sich bewußt weigert die Doku einer Funktion zu lesen kommt es zu Überraschungen, nur daß man sich hier an den generischen Oberbegriff erinnert. Genauso könnte ich sagen, daß Architektur X Grundsätzlich Sch*** ist, weil man mit libs ständig Probleme hat (wenn man die Docs nicht liest). Nur ist das derart allgemein und libs betrifft alle Architekturen, daß da noch jeder merkt daß solch eine Aussage etws verquer ist. LaunchDisco schrieb: > Hhhääää? > Zum Einstieg nimmt man das Evaluationboard. In den Porjekten gehört der > Chip ins Design. Das hat aber mit der Art des µC nichts zu tun. :-((( > Die modernen Evaluationboards können aber als Programmer und > Debuginterface genutzt werden. Beim avr zückst dafür wieder ein paar > Scheinchen. :-((( Und hier wird es absurd. Du führst die Discos als allgemeines Argument gegen AVR und sagst gleichzeitg daß die Platinen nichts mit den µC zu tun haben. Diese Unterscheidung mache ich doch schon die ganze Zeit und Frage dich die ganze Zeit ob du diesen allgemeinen Satz LaunchDisco schrieb: > Hast du zuviel Geld? Der Einstieg mit avr ist viel teurer als bei > anderen. auf die Boards, die Chips oder beides beziehst Richtig ist nur daß viele AVR-Gegenstücke zu jenen Platinen meist teurer sind als die Discos. Aber daß hat auch nichts mit der AVR-Architektur zu tun. Es gibt auch billige Programmer, machmal sogar mit Sockel für den zu programmierenden Chip, und billige Eval-boards für AVR und zudem kauft man sich das nur ein mal. Ich könnte auch sagen: Bei Arduino kommt man auch mal ohne Lötkolben aus und darum ist das andere viel zu teuer (wegen dem Lötkolben). Das ist natürlich kaum allgemeingültig. Ein Programmer ist ein einmal Anzuschaffendes Werkzeug und in beiden Fällen nicht unbedingt teuer, auch wenn es ebenfals teure gibt. Daß du das Evalboard als Programmer für andere Chips nutzen kannst mag nett sein, aber das geht prinzipiell mit nahezu jedem Evalboard. Das gibt es bei AVR auch. Jenen Kombovorteil hat man zudem nur beim ersten Evalboard. Wir reden gerade über eine Summe die die gerade aufgewendete Zeit nicht rechtfertigt, was mal wieder ein Beispiel dafür ist das die Architektur für die man sich entscheidet und Forum welches man zu nutzen gedenkt und dessen Community sinnvoll zueinander passen sollten. An dieser Stelle bin ich raus, weil es darauf hinausläuft daß die Argumentation gegen eine ganze Controllerfamile nach zig mal nachfragen nur daraus besteht, daß man beim Disco vielleicht beim Programmer Geld sparen kann das kaum für einen Kinobesuch reicht. Kurios ist dabei, daß man sich gegen AVR ausspricht, und dann Disco als Gegenargument bringt. Was soll denn das für eine Controllerfamilie sein? ;-) LaunchDisco schrieb: > avr ist jetzt nur noch Arduinos? Gleich wird es spannend. Ich hole mir > jetzt Popcorn und Cola. Wie interessant das das ausgerechnet von dir kommt. ;-)
:
Bearbeitet durch User
LaunchDisco schrieb: > Aber damit sperrt man sich nicht aus Wir ahnen, was dem Disco-Spross passiert ist: Sein AVR liegt jetzt gelockt in der Schublade weil er sich beim fuses-Einstellen vertan hat und die Anschaffung eines high voltage Programmers sein Taschengeld überschreitet, so ist er nun mit dem ST Disco Board glücklich und hasst seine früheren Fehler - die er auf den Prozessor und nicht seine Unaufmerksamkeit schiebt.
LaunchDisco schrieb: > Aber damit sperrt man sich nicht aus. ;-) Man kommt aber auch wieder rein ;-) Gut das kostet etwas Zeit. Aber das gilt generell für die Fehlersuche. Und da es sich um einen Fehler mit äußerst festem Schema handelt ist die Lösung vorhersagbar. Daraus folgen zwei Möglichkeiten. - Man ist sehr lernresistent oder schlampig und wiederholt den Fehler immer wieder. Dann kann man sich die Lösung nach Schema-F parat legen. -Man lernt daraus und liest die Docs bevor man etwas nutzt. Es ist ja nicht so daß das Kapitel besonders komplexe Kernphysik enthielte. Bei ersterem bleibt das eigentliche Problem beim Programmieren bestehen. Solche Leute werden ungeachtet der Architektur immer wieder Probleme dieses Typs haben. Lösung 2 besteht aus einer Arbeitsweise die man sich grundsätzlich aneignen sollte.
:
Bearbeitet durch User
MaWin schrieb: > Wir ahnen ... Wenn 's sachlich nicht mehr reicht, bedient man sich der unteren Schublade. Aber das kennt man ja von dir. :-((( Carsten R. schrieb: > Man kommt aber auch wieder rein ;-) > Gut das kostet etwas Zeit ... und man muss was drumherum basteln. :-( An die modernen µCs kommst du immer ran. :-))) Carsten R. schrieb: > sagst > gleichzeitg daß die Platinen nichts mit den µC zu tun haben Carsten R. schrieb: >> Hast du zuviel Geld? Der Einstieg mit avr ist viel teurer als bei >> anderen. > > auf die Boards, die Chips oder beides beziehst Es geht um den Einstieg. Mit einem Evaluationboard kann ich für kleines Geld die ersten Gehversuche machen. Und das mit viel Komfort wie bei den Profis. Das kostet bei avr ein vielfaches mehr. Aber das hatten wir hier schon und in vielen anderen Threads. Nutz die SuFu. :-(
LaunchDisco schrieb: > Es geht um den Einstieg. Mit einem Evaluationboard kann ich für kleines > Geld die ersten Gehversuche machen. Aha, du bist also ein Einsteiger. Als solcher solltest du nicht so viel unqualifizierten Mist von dir geben. Deine Beiträge sind einfach nur Quark, nutzlos und peinlich!
Werner H. schrieb: > du bist also ein Einsteiger Ne, sondern schon sehr lange dabei. Und habe schon viele µCs in den Fingern gehabt, auch avr.
Die Preise bei Atmel sind deutlich gesunken. Programmer+Debugger für Atmels Cortex-M0+, Cortex-M3, Cortex-M4, megaAVR, tinyAVR, XMEGA (31,34 €): http://de.farnell.com/atmel/atatmel-ice-pcba/debugger-atmel-arm-avr-pcba-kit/dp/2407171 Zum Einstieg reicht auch ein vorprogrammierter ATmega238 mit Arduino Bootloader (4,57 €): http://de.farnell.com/arduino/a000048/mcu-atmega328-mit-uno-bootloader/dp/1848694 Geht bestimmt noch günstiger, als bei Farnell.
LaunchDisco schrieb: > Carsten R. schrieb: >> auf die Boards, die Chips oder beides beziehst > > ... Aber das hatten wir hier > schon und in vielen anderen Threads. Nutz die SuFu. :-( Sorry, aber das ist doch Unfug. -.- Die Suchfunktion im Forum nützt gar nichts wenn ich dich Frage worauf du deine allgemeine pauschale Aussage beziehst. Der Kontex ist dieser Thread und die Aussage stammt von dir, allgemein, ohne zusätzliche Angaben. Da kann ich doch nicht fremde Aussagen und auch noch aus anderen Threads dranbasteln und dir das dann unterschieben. Die Discoverys sind nicht schlecht. Darum ist das aber noch kein Argument allgemein gegen AVR. Und auch andere Mütter haben hübsche Töchter. Nur mal so auf die schnelle der erste Treffer der mir über den Weg lief wenn es billig sein soll: http://www.ebay.de/itm/like/251176689263?lpid=106&chn=ps Billige Eval-Boards gibt es für so ziemlich jede Plattform. Es kommt halt darauf an was man noch gern dabei hätte an Funktionen. Und mal im Ernst: Wie oft hast Du schon einen AVR verfust. Oder wie viele Leute kennst Du die das einmal gemacht haben und wieviele kennst du die das mehr als einmal gemacht haben?
:
Bearbeitet durch User
Hallo Thomas, mehr wie 25 Jahre ist es her, daher vage aus der Erinnerung unter Zuhilfenahme meines GAL-Leitzordner. Ich habe mir damals einen GAL-Programmer fuer meinen MC6809 auf Basis folgender Artikel zusammengestrickt und es war nicht besonders anspruchsvoll: Programmierbare Logikbausteine, Thomas Schlenger-Klink, MC Januar 1988, 66--72 (Teil 1) Programmierbare Logikbausteine, Teil 2: Basic-EMUF programmiert GALs, Thomas Schlenger-Klink, MC Februar 1988, 102--107 spaeter: GALanter Brenner, Bernd Hipp und Dr.~Christian Siemers, ELRAD 1998, Heft 5, 60--64 Ich hatte noch ein GAL-Datasheet von Lattice, welches die Programmiersequenz beschrieben hat, das habe ich wohl entsorgt... Macht nichts, denn eine Eingabe "Lattice GAL Handbook" in die beliebte Suchmaschine bringt ein als pdf eingetifftes Buch zum Vorschein. Mit obigen Angaben sollten die Referenzen in einer guten Uni-Bibliothek recht schnell zu finden sein. Viel Glueck und Erfolg!
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.